配線図という名の「進化の圧縮」
我々エンジニアが日々向き合っている深層学習モデルは、膨大な計算資源を投じてランダムな重みを最適化する「学習」の産物だ。しかし、2026年9月に発表されたオスのショウジョウバエ中枢神経系全配線図(MaleCNS)は、そのパラダイムに強烈なカウンターパンチを食らわせた。166,700個のニューロンと5,450万個のシナプス。この圧倒的なデータセットを前に、我々は「重みは学習するものではなく、顕微鏡で測るものかもしれない」という、根源的な問いに直面している。
かつて1986年に線虫C. elegansの全配線図が完成した際、それは15年という気の遠くなるような手作業の結晶だった。しかし、2018年にGoogleが発表したflood-filling networksによる自動追跡技術の登場が、この分野のボトルネックを完全に破壊した。人手による校正コストは50分の1にまで圧縮され、FlyWireコンソーシアムによるメスの脳全配線図(2024年)を経て、今回のMaleCNSに至るまで、脳の地図化は指数関数的な加速を見せている。以下の表は、この進化の歴史を物語るスペックの推移である。
| 年 | データセット | 規模 | 特徴 |
|---|---|---|---|
| 1986 | C. elegans | 302ニューロン | 手作業で15年 |
| 2020 | hemibrain | 約25,000ニューロン | ハエの脳の一部、校正50人年以上 |
| 2024 | FlyWire | 139,255ニューロン、5,450万シナプス | メスの脳全体、校正約33人年 |
| 2026 | MaleCNS | 166,700ニューロン | オスの脳・視葉・腹髄、校正約44人年 |
ここで重要なのは、この配線図が単なる静的なグラフではないという点だ。神経伝達物質の推定技術により、どの結合が興奮性で、どれが抑制性かという「符号」まで確定している。我々が普段書いているコードで例えるなら、これは「学習済みモデルの重み」をロードするのではなく、ハードウェアの回路設計図そのものを物理的に抽出したようなものだ。Anthony Zadorが指摘するように、動物の行動の多くはゲノムというボトルネックを通って圧縮された「進化の最適化結果」である。つまり、ハエが生まれた瞬間から狩りや歩行ができるのは、彼らが学習したからではなく、その回路構造自体が生存のためのアルゴリズムを内包しているからに他ならない。この事実は、現在のAIが「汎用的な構造にデータを流し込む」というアプローチに偏りすぎているのではないか、という技術的懸念を抱かざるを得ない。
「91%の再現」が暴く設計の真実
Shiuらによる全脳モデルが、摂食や毛づくろいといった特定の行動予測において91%の一致率を示したことは、衝撃的だった。しかし、ここで冷静になる必要がある。この91%は「仮想のハエが自律的にゲームを遊んだ」という結果ではない。あくまで特定の回路における予測の一致率であり、モデルには空腹や神経ペプチドによる調節といった、生物学的に不可欠な動的要素が欠落している。それでもなお、配線をランダムに入れ替えた瞬間にその予測精度が崩壊するという事実は、振る舞いの本質が「調整可能なパラメータ」ではなく「固定された配線構造」に宿っていることを証明している。
我々エンジニアにとっての教訓は、Lappalainenらの視覚系モデルに見ることができる。彼らは45,669個のニューロンという巨大な構造を維持しつつ、学習させたパラメータはわずか734個に過ぎなかった。これは、強固な構造的制約を与えることで、学習すべき次元を劇的に減らせることを示唆している。現在のAI開発において、我々は「モデルを大きくすれば何でも解決する」というスケーリング則の呪縛に囚われていないだろうか。計算資源を浪費して重みを更新し続けるのではなく、ハエの嗅覚回路を応用したFlyVecのように、構造の工夫によって計算量を削減するアプローチこそが、次世代のAI設計における鍵となるはずだ。
一方で、BeiranとLitwin-Kumarの理論研究が突きつけた「配線図だけではダイナミクスを決定できない」という結論も無視できない。配線は信号が流れる「可能性」を制約するが、時間軸上の振る舞いまでは規定しない。残りの不定性を埋めるのは、わずかな神経活動の記録と、環境との相互作用だ。Eon Systemsのデモが示すように、脳と体のインターフェースをどう設計するかという「配線図の先」にある実装こそが、現在の最大の課題である。我々は、生物の脳を模倣するのか、それとも脳の「構造的知恵」を借りて全く新しい計算機を作るのか。その境界線上で、今まさに設計思想の転換が求められている。読者諸氏には、自身の開発しているシステムにおいて「データで解決すべき部分」と「構造で解決すべき部分」を、今一度厳密に切り分けて考えてみてほしい。明日から取り組むべきは、モデルのパラメータを増やすことではなく、問題の本質を捉えるための「構造の設計」ではないだろうか。


コメント