複雑すぎるのは問題ではない, 脳の限界を設計に変える方法

Hatched by naoya

Aug 04, 2026

1 min read

2 views

84%

いちばん危険なのは、難しいことではなく、追えるはずだと思い込むこと

ソフトウェアの世界では、計算量が増えると何が起きるかを私たちはよく知っています。O(N)なら追える。O(N²)になると、挙動を直感だけで把握するのが急に難しくなる。O(2^N)に至っては、もはや現実的ではない。

ところが、同じことはコードの中だけで起きているわけではありません。人間の脳そのものにも、計算量の爆発が起きるのです。問題は、複雑な対象を前にして知識が足りないことではない。むしろ、理解しようとする入力のつながり方が増えすぎて、脳の側が破綻することです。研究の読み方、書き方、発表の仕方を体系化する試みが重要なのは、才能を高めるためだけではありません。認知負荷を制御するための設計だからです。

この視点に立つと、進歩を阻むものの正体が見えてきます。多くの人は「もっと集中しよう」「もっと勉強しよう」と考えます。しかし実際には、集中力の問題より先に、複雑性を扱える形に変換できていないことがボトルネックになっていることが多いのです。

研究も仕事も、脳にとってはアルゴリズムである

学ぶこと、考えること、伝えることは、すべて情報処理です。論文を読むとは、散らばった主張の中から構造を復元する作業です。書くとは、自分の頭の中にある曖昧な塊を、他人が辿れる順序に変換する作業です。発表するとは、相手の認知資源を壊さずに、必要な変化だけを起こす作業です。

ここで重要なのは、これらが単なるコミュニケーション技術ではないという点です。よい研究の進め方とは、脳の計算量を下げる方法でもあります。優れたノート、図解、要約、プレゼン資料は、見栄えを整えるための装飾ではありません。複雑な対象を、脳が一度に扱えるサイズへと分割するための道具です。

たとえば、新しい論文を読むとき、本文を最初から最後まで丁寧に追うと、しばしば疲れ果てます。なぜなら、各段落を理解するたびに文脈を保持し、関連研究を思い出し、数式の意味を解釈し、図表を照合し続けるからです。これは、入力が少ないように見えて実は高コストな処理です。まるで巨大なグラフを、メモリに全部載せたまま探索しているようなものです。

一方で、先に「この論文は何を一文で言いたいのか」「どの仮説を検証しているのか」「どの図が結論を支えているのか」を先に把握できれば、以後の読解は急に軽くなります。ここで起きているのは、理解の魔法ではありません。問題空間の圧縮です。

複雑なものを理解する力とは、複雑さをそのまま抱える力ではなく、複雑さを圧縮して保持する力である。

認知負荷が増える瞬間は、コードが増えたときではない

人はしばしば、要素数が増えると難しくなると考えます。しかし本当に脳を壊すのは、要素の数そのものではなく、相互依存の数です。部品が100個あっても、それぞれが独立していれば扱えます。10個でも、それぞれが全員と結びついていれば、急激に手に負えなくなります。

これはソフトウェアの複雑性と同じです。バグの温床になるのは、単純な処理が大量にあるときより、状態遷移が絡み合い、例外処理が例外を呼び、局所的な変更が全体に波及する設計です。頭の中でも同じことが起きます。論点が増えるのではなく、論点同士の結びつきを同時に保持しようとする瞬間に、認知負荷が爆発します。

たとえば、研究発表でよくある失敗は「情報が足りないこと」ではありません。むしろ、背景、先行研究、課題設定、方法、結果、限界、今後の展望をすべて詰め込み、聞き手がどこを主軸にすればよいか分からなくなることです。情報は多いのに、構造がない。これは高密度な説明ではなく、高い結合度を持つ混雑です。

書き方でも同じです。書きながら考えようとすると、しばしば文章が苦しくなります。なぜなら、構想、段落の順序、語尾、引用、論理の飛躍の検査を同時に行うからです。これは一つの脳内で、設計者、編集者、批評家、発表者が同時に喋っている状態です。人間のワーキングメモリにはそんな余裕はありません。

だからこそ、優れた研究者やエンジニアは、思考を一気に完結させようとしません。分解して、外部化して、再結合するのです。メモ、図、見出し、箇条書き、スライド。これらは単なる整理術ではなく、脳内のO(N²)をO(N)に近づけるための装置です。

進歩する人は、理解力が高いのではなく、圧縮がうまい

ここで一つ、少し逆説的なことを言えます。進歩が速い人は、必ずしも最初からよく理解しているわけではありません。うまく圧縮できるから、早く前に進めるのです。

圧縮とは、単に短くすることではありません。重要な差異を残しながら、不要な複雑さを捨てることです。例えば、ある論文を読むときに、毎回すべての定義を暗記する必要はありません。代わりに、「この論文は何を前提にして、どこで新規性を出しているのか」という骨格を掴めばよい。これは、全枝葉を保持するのではなく、木の構造を保持することです。

研究の読み方、書き方、発表の仕方が別々の技術に見えるのは表面的な話です。本質的にはすべて同じ問題を解いています。それは、複雑な知を、他者と自分の脳が扱える形へ変形することです。読むときは他人の圧縮を解読し、書くときは自分の圧縮を作り、発表するときはその圧縮を相手に適した形へ再圧縮します。

このとき大切なのは、圧縮率を上げすぎないことです。圧縮しすぎると意味が失われ、圧縮が弱すぎると脳が壊れます。よい研究コミュニケーションは、その中間にあります。聞き手が少し努力すればたどり着けるが、努力の大半は理解ではなく、構造の復元に向けられている。そんな状態です。

具体例を挙げましょう。発表スライドで、1枚に3つの主張と5つの図を詰め込むと、聴衆は各要素を個別に理解する前に、関係の再構成に脳を使ってしまいます。逆に、1枚1メッセージに絞り、図の役割を明示し、前後のつながりを段階的に示すと、聴衆は理解ではなく納得にエネルギーを使えます。理解コストを下げることは、説得力を上げることでもあるのです。

では、どう設計すれば脳は壊れにくいのか

ここまでの話を実践に落とすなら、鍵は「頑張ること」ではなく複雑性の配置換えです。対象を小さくするのではなく、扱い方を変えます。設計の原則は三つあります。

第一に、一度に保持する変数を減らすこと。これは「覚えない」ことではなく、「外に置く」ことです。図にする、表にする、見出しを立てる、仮説と結果を分けて書く。脳の中に載せる前に、紙や画面に退避させるだけで、計算量は激減します。

第二に、依存関係を明示すること。何が何を前提にしているのか、どの結論がどのデータに支えられているのかを可視化すると、全体の構造が見えます。理解できない説明の多くは、情報不足ではなく依存関係の非表示です。

第三に、段階を分けて処理すること。読む段階、まとめる段階、書く段階、発表する段階を雑に同時進行させると、脳の負荷は跳ね上がります。まず粗く掴む。次に詳細を確認する。そのあとに比較する。最後に伝える。この順序だけで、難しさの体感は大きく変わります。

ここで役立つのは、研究や技術的な仕事を「センスの問題」と見なさないことです。むしろ、どこで脳が爆発しているのかを診断する問題として扱うべきです。理解できないと感じたら、自分の能力を疑う前に、情報構造を疑う。情報が線形に並んでいるか、依存関係が露出しているか、どの層で圧縮されているか。こうした問いを持つだけで、仕事の質は変わります。