草の根AI：ムーンショットを超えて

人工知能の分野では、誰もが「ムーンショット」を追い求めているように見える——コードを自律的・信頼性高く・持続可能に、そして何より安価に記述できる魔法の組み合わせだ。これは新しいアイデアではなく、うまくいっていない。

ムーンショットの魅力は理解できる：新境地を開拓し、新たなパラダイムを創造し、タイムズ誌の表紙を飾る英雄になること。結局、業界を破壊しなければ、何をしていると言えるのか？誰も見ていないところでコードを書くシステムを作れたら、それは大きな勝利だろう。しかし、ソフトウェアの伝承にある無数の警告事例を考慮すれば、そのような試みを許容することはほとんどできない。

「もうコードを見る必要はない」の歴史

XMLは1998年に公開された。当時、それは革命とされ、XSL、XPath、XSLTなど様々なツールを伴っていた。XMLで書かれたドキュメントは構成可能であるとされ、インターネット上の全てのドキュメントが相互接続された情報景観を形成するというビジョンがあった。その時、セマンティックウェブについて語り始めた。未来はバラ色だった。

実際にはXMLは扱いづらく、誰も本当に好きではなかった。しかしそれは問題ではなかった。なぜなら人間向けではなく、機械向けだったからだ。XML文書を読んだり書いたりする必要はなく、XMLコンテンツを解釈・修正するグラフィカルインターフェースだけを扱えばよかった。数十年後、XMLはよりプログラマフレンドリーなJSONやYAMLに大部分が置き換えられた。人々はファイルを直接読み書きすることを好むことが判明したのだ。

ほぼ同時期に、KDevelopやEclipseといった最初のグラフィカルIDEが登場した。これらには多数のプラグインと、プロジェクトの複数ビューを表示するグラフィカルインターフェースがあった。Antコマンド用のパネル、利用可能なメソッド一覧用のパネルなど。当時の小さな画面と低解像度と相まって、コードパネルは中央の小さなウィンドウで、せいぜい15～20行しか表示できなかった。しかしそれでよかった——コードを見ることは想定されておらず、グラフィカル要素とのみ対話すればよかったからだ。メソッドを作成するには、File -> Add -> Method（またはそれに類する操作）を行い、ダイアログボックスで名前やパラメータなどを入力した。Mavenに依存関係を追加するにも独自のダイアログがあった。コードと対話するのではなく、UIと対話していたのだ。

初期のEclipse IDE。コードのスペースはほとんどなく、気にする必要もなかった。

今日のIDEはコードパネルを可能な限り大きくし、2つ以上のコードパネルを並べて表示することもある。Sublimeのように、グラフィカル要素をすべて排除してコードに完全集中できるミニマリストな選択肢もある。

同じ頃、Poseidonが登場した。UMLが全盛で、OOPが台頭していた。Poseidonはこれらを組み合わせ、新たな約束を掲げた：あなたはUMLを使ってプログラムを構成するエンティティを描き、関係性と属性を示し、私がコードを生成する。あなたは高価値のエンジニアであり、コードを書くことに時間と才能を浪費すべきではない。

海神はどうやらプログラミングが非常に得意だったらしい。

言うまでもなく、それは定着しなかった。擁護者たちは「ジュニアエンジニアはコードを読み、シニアエンジニアは図を読む」などと言った。彼らは自分たちを、レンガではなく青写真を扱う建築家に例えた。しかし結局、私たちはコードに戻った。

ETL、ローコード、ノーコード……数え上げればきりがない。夢は常に同じだった：もうコードを見る必要はない。私のような終末論者が「以前にも試した」と呟くたびに、「今回は違う」と聞かされた。そして毎回、それはまた別の打ち砕かれた夢になった。そして毎回、私たちはコードに戻った。

実際、歴史が教えているのは、コードを直接操作することを諦めるどころか、さらに強化したということだ！従来は設定やUIで管理されていた活動もコードに変え、Infrastructure as Code、GitOps、そして最終的にはEverything as Codeを生み出した。

コードが仕様である

今日の「でも今回は違う」陣営では、必要なものの詳細な仕様を書き、AIがコードを生成するという理論がある。人々はAI仕様をコンパイラに例え、単なる抽象化の別の層だと言う。AI生成コードの批判者は、高水準言語を嫌いアセンブリを使い続けた初期のプログラマーと同じだと主張する。しかし、この類推は吟味するとすぐに崩れる。

プログラミング言語は通常、BNF文法で記述され、構文が正しいか検証できる。また、ソース言語をターゲット言語に数学的な精度で変換するコンパイラを持つ。「数学的」という言葉は誇張ではない。コンパイラはまさに、入力を出力に明確かつ予測可能な方法で変換する数学的関数として記述できる。実際、この特性はソフトウェア特許の概念そのものを脅かしてきた。すべてのソフトウェアはラムダ計算を使って数式に書き換えられ、数式は特許を取得できないからだ。話が逸れたが、重要なのは、ソースコードをコンパイルするとき、何が得られるか（少なくとも何が得られるはずか）を正確に知っているということだ。

AI、特にLLMには同じことが言えない。自然言語は形式的に定義できない。自然言語は乱雑で曖昧で、最悪なことに、その意味は時間、場所、文化によって変化する。あるいはウィトゲンシュタインが言ったように、「言葉の意味は言語におけるその使用法である」。だから弁護士は後々問題にならないような契約書を作成するのに苦労するのだ。理論上は、自然言語で欲しいものを示す仕様を書けるはずだ。実際には、その仕様は誤解される可能性があり、暗黙の知識を見落とす可能性があり、伝えられていない前提に基づく可能性がある。AIは従順に仕様に合ったプログラムを生成しようとするが、幻覚、欠落、逸脱は避けられない。さらに、LLMは設計上非決定的であり、同じ入力を連続して2回呼び出すと異なる出力が得られる。全体的な振る舞いは維持されるかもしれないが、微細なずれが随所に導入される。そしてここで人間の期待と衝突する：ボタンがまったく同じように機能していても、ランダムに移動されるのは誰も好まない。

解決策は、伝えられるところによれば非常に簡単：仕様にすべての関連詳細、すべての要件、すべてのエッジケース、すべての知識を含めること。曖昧さの余地を残さないように書くこと。潜在的な誤解を明示的に排除すること。すべての利害関係者がレビューし承認すること。要するに、仕様が明確に定義されていることを確認すること。もちろん、フライドポテトもお願いします。明確に定義された仕様は、ソフトウェア開発が産業として始まって以来の聖杯である。そしてそれは実現したことがない。明確に定義された仕様は、ソフトウェアにおける球形の牛に相当する。

しかし、仮にプロジェクトの細部を含む明確に定義された仕様を作成できると仮定しよう。すると今度は完全地図パラドックスに直面する：コードがすべきことを誤りなく指定する唯一の方法は、コード自体と同じ詳細さで指定することだ。地図はそれが記述しようとする領土と同じ大きさになる。仕様はコードの抽象化ではなくなり、コードのコピーになる。そしてそのために、私たちはすでに実際のコードを持っている。

結局、コードが唯一の真実の情報源である。

結局のところ、これは基本的なエントロピーの問題であり、プラトンのイデア論に完全に体現されている：個別から抽象を envision することはできても、抽象から個別を創造することは常に不完全である。

AIで仕様を作成する

予想される「AIですべてを」のスタイルで、新たなSpec-Driven Developmentの擁護者たちは、すべてのビジネスインタラクションにAIを組み込めば仕様が自動的に書かれると主張する（聞き覚えがある？）。会議があるか？AIノート作成を有効にして、会議の結論を自動的に利用可能にする。ユーザー調査セッションを録画したか？AIに主要ポイントを抽出させる。今や処理しきれないほどの文書があるか？AIに全体を分析させ、主要ポイントを蒸留させる。この情報がまばらで矛盾し、潜在的に間違っているか？AIが修正してくれる。

ここで、数十年にわたって潜在的に信頼性の低いデータを扱ってきた組織——諜報コミュニティ、すなわちCIA、NSA、SISなど——から学ぶ必要がある。まず、データ、情報、インテリジェンスの3つの概念を区別する必要がある。

データ：判断や分析を伴わない事実。「バーニスがXと言った」や「3月に200個のおもちゃが売れた」など。

情報：特定の文脈や目的に関連するように構成・整理・フィルタリングされたデータ。「おもちゃの売上が着実に減少している」など。

インテリジェンス：目標、価値観、環境の観点から情報を分析し、実行可能な指示を生成すること。「競合他社がより効果的なマーケティングにより市場シェアを侵食している」など。

AIは簡単に多くの表面的なデータを提供でき、そのほとんどは正しい。AIはデータから情報を生成するのに役立つかもしれないが、文書化されていない集合的・暗黙の知識（共通の前提、組織の慣性、文化的合図など）に属する重要なニュアンスを見落とすことが多い。AIを使ってさらに次のステップに進もうとすると、すべての小さな誤りが積み重なり、表面的には問題なさそうだが、十分な不正確さを含んで使用不能なインテリジェンスが生成される。一種のコピーのコピーのコピーのようなものだ。

「信仰の薄い者たちよ！それには簡単な解決策がある。AIが生成したすべてのコンテンツを人間がレビューし、必要に応じて修正すればよい。会議後、人々は議事録をレビューし承認する。AIが統合した後、人々は要約をレビューし承認する。そして仕様が書かれるときには……」

続けてくれ。自分で反論を書いてもいいぞ。

でも暗い工場は？

ああ、暗い工場。聞いたことがないかもしれないが、暗い工場（または消灯工場）は、非常に自動化されているため人間が不要になった工場だ。そして人間が不要なので、灯りをつける必要もなく、暗闇で稼働する。とてもクールだ。このアイデアは一部の人々の興奮を呼び、次のSF的類推を生んでいる：AIは暗い工場であり、エージェントを放ち、人間の介入なしにコードを作成させる。「犬の散歩中に暗号通貨取引プラットフォームを作った」といった類だ。

少し立ち止まって考えよう。まず、時間スケールの問題がある。産業革命は約250年前に始まり、今ようやく人間が関与しない完全自動化工場について語り始めている。ソフトウェア産業全体の歴史はせいぜい70年、AIはそれよりも短い。高度に手動の仕事をこれほど短期間で完全自動化できると考えるのは過度に楽観的だ。

第二に、製造業とソフトウェアの間には根本的な違いがある。製造業では同一のコピーを大量生産するが、ソフトウェアでは毎回ユニークな構築が行われる。