原文: Nobody knows how the whole system works
著者: Lorin Hochstein
日付: 2026-02-08
アーカイブ日: 2026-02-09
現代のソフトウェア開発において、システム全体の仕組みを完全に理解している人間は誰もいない――これは危機なのか、それとも必然なのか？
Lorin Hochsteinが、LinkedIn上で交わされた3つの投稿（Simon Wardley、Adam Jacob、Bruce Perens）と、1994年のMIT教授Louis Bucciarelliの洞察を通じて、「理解」の限界について考察。AI時代において「仕組みを知らずに作ること」の是非を問う、ソフトウェア工学の根源的なジレンマに迫る。
TwitterからLinkedInへの人材流出は、意外な副作用をもたらした――技術的に深い議論が、より真剣に交わされるようになったのだ。この記事は、そんなLinkedIn上の議論から生まれた。
Wardleyは、AI（特にコード生成AI）が引き起こす未来に対して警鐘を鳴らす：
「私が魅了され、恐怖を感じているのは、AIを使って『仕組みを理解せずに物を作る』能力を手に入れたこと。これは危険だ。」
彼の懸念は、単なる技術的スキルの喪失ではない。根本的な動作原理を理解しないまま複雑なシステムを構築すること の危険性だ。バグが出たとき、パフォーマンスが悪化したとき、セキュリティホールが見つかったとき――誰がそれを修正できるのか？生成されたコードの背後にある「なぜそう動くのか」を誰も説明できない世界。
この懸念は、業界で「魔法（magic）」という言葉が軽蔑的に使われる理由と重なる。魔法とは、下層の仕組みを意図的に隠蔽するフレームワークのこと。Ruby on Railsが典型例だ。Railsは「設定より規約」でコードを劇的に減らしたが、その代償として「裏で何が起きているか」を見えなくした。Wardleyが恐れるのは、AIがこの「魔法」を極限まで推し進めることだ。
Adam Jacob（ChefとSystem Initiativeの創業者）は、Wardleyの懸念を認めつつも、現実的な立場を取る：
「AIは確かに新しい能力だ。そして、その利益は明らかにリスクを上回る。私たちはさらに根本的な仕組みから遠ざかるが、それは避けられない変化だ。」
彼の主張は2つの前提に基づく：
Jacobは、Wardleyの懸念を「新しい問題」としてではなく、「既存の問題の延長線」として捉える。私たちは常に、完全には理解していないレイヤーの上で開発してきた。JVMの最適化、TCP/IPスタックの実装、ARMプロセッサのメモリモデル――どれだけのエンジニアが、これらを本当に理解しているだろうか？
AIは確かに「理解と実装の距離」をさらに広げる。しかし、その代償として得られる生産性は、リスクを上回る――それがJacobの結論だ。
Bruce Perens（Open Source Initiativeの共同創設者）は、Wardleyの懸念を別の角度から覆す：
「Wardleyが恐れるシナリオはすでに起きている。現代のCPUやOSは非常に複雑で、多くの開発者は実際の仕組みを知らない。彼らはメンタルモデルを持っているが、そのモデルは根本的に間違っている。」
Perensの指摘は辛辣だ。多くのエンジニアは「自分はシステムを理解している」と信じているが、実際にはその理解は根本的に不完全だ。例えば：
Perensの主張は明確だ：私たちはすでに、理解していないシステムの上で開発している。AIはこの状況を悪化させるのではなく、単に顕在化させるだけだ。
MIT工学部の教授Louis Bucciarelliは、1994年の著書『Designing Engineers』で、「技術リテラシー」についての会議での経験を記している：
ある社会学者が発表した：「アンケート調査の結果、アメリカ人の80%は電話の仕組みを知らない。我々は技術的に無知な国民だ。」
Bucciarelliは不安になった。自分は電話の仕組みを知っているだろうか？
彼は自問する：
そして結論する：誰も電話の仕組み全体を知らない。
「電話の仕組みを知っている」とは、どのレベルの理解を指すのか？物理？アルゴリズム？インフラ？経済？規制？――複雑な技術システムは、本質的に誰一人として全体を理解できないように設計されている。
著者Hochsteinは、古典的な技術面接質問を引用する：
「URLをブラウザに入力してEnterを押すと、何が起きるか？」
この質問は、候補者の知識の深さを測るためのものだ。しかし、その深さに底はない：
どこまで答えられるか？
Hochsteinは、元同僚のBrendan Gregg（Netflixでのパフォーマンスエンジニア、『Systems Performance』著者）の面接手法を紹介する：
「私が興味を持っていたのは、候補者の知識の限界を見つけること。そして、その限界に達したときの反応を観察すること。」
Greggのアプローチ：
この面接哲学は、ある前提に基づいている：
誰もシステムの底まで理解していない。
重要なのは「どこまで知っているか」ではなく、「知らないことを認められるか」「知らないことをどう学ぶか」だ。
一見対立する4つの視点は、実は異なる側面から同じ真実を指している：
下層の仕組みを理解しないままシステムを構築することには、明確なリスクがある：
「魔法」に頼りすぎると、魔法が壊れたときに対処できない。
しかし、抽象化は避けられない：
AIは新しいレイヤーだが、その価値は明白だ。
Wardleyが恐れるシナリオは、すでに現実：
多くのエンジニアは、これらに対して間違ったメンタルモデルを持っている。そして、それでも仕事はできている。
電話、インターネット、OS、CPU――これらは本質的に、誰一人として全体を理解できない：
これは欠陥ではなく、複雑な技術システムの本質的な性質だ。
Hochsteinの結論は明快だ：
「AIはこの状況を悪化させる。しかし、それは新しい問題ではない――私たちはずっとこの状況の中にいた。」
AI時代に変わるのは：
しかし、根本的な構造は同じだ：
私たちは常に、完全には理解していないシステムの上で、部分的な知識を組み合わせて、何かを作ってきた。
AI時代に必要なのは：
そして何より：「理解」の限界を前提に設計すること。
テスト、監視、ロギング、デバッグツール――これらは全て、「誰もシステム全体を理解していない」という前提の上に成り立つ安全装置だ。
この記事が提示するのは、ソフトウェア工学の根本的なトレードオフ だ：
Wardleyは「魔法（magic）」を危険な存在として扱う。しかし、魔法なしでは現代のソフトウェア開発は成り立たない。
Ruby on Railsの「魔法」が可能にしたこと：
問題は「魔法を使うこと」ではない。問題は：
健全な「魔法」との付き合い方：
「AIが書いたコードを人間が理解できない」――この恐怖は新しく聞こえるが、構造は古い。
私たちはすでに、完全には理解していないシステムの上で開発している：
AIは「生成者と理解者の分離」を加速させる。しかし、その分離自体は新しくない。
すでに分離していた例：
AIは単に、この「制御の喪失」を一段階進めただけ。
Bucciarelliの洞察は深い：「知っている」とは何か？
電話を例にとると：
| レイヤー | 知識の内容 | 専門家 |
|---|---|---|
| ユーザー | ダイヤルの仕方 | 全員 |
| 物理デバイス | 振動板、コイル、磁場 | 電気工学者 |
| 信号処理 | エコー除去、ノイズ抑制 | DSPエンジニア |
| ルーティング | 長距離電話の経路選択 | ネットワークエンジニア |
| 衛星通信 | 信号の送受信、遅延補償 | 通信工学者 |
| インフラ保守 | 電柱の修理、ケーブル敷設 | 保守作業員 |
| 経済・規制 | 設備投資、企業間調整 | 経営者・政策立案者 |
誰が「電話の仕組みを知っている」と言えるのか？
全レイヤーを理解している人間は存在しない。システムは、本質的に分散した知識で成り立っている。
従来の前提：「システムを理解してから作る」
新しい前提：「誰も全体を理解できないシステムを、どう作るか」
必要なアプローチ：
“Nobody knows how the whole system works”
これは諦めではなく、設計の前提条件だ。
その前提の上で：
AI時代のエンジニアは、「全てを理解できない」という現実と共生する技術 を身につけなければならない。
それは新しいスキルではない――ただ、今まで目を背けてきた現実を、直視するだけだ。
この記事は個人ブログからのサマリーです。全文は原文をご覧ください。