AI、ロケット、そしてハードコントラクトの復活（前編）

本稿は、AI支援によるソフトウェア開発の経済的現実を分析する。「AIはソフトウェアを安くする」という一般的な主張は、重要な点で誤りである。AIが安くするのは実装、すなわち意思決定を動作可能なコードに変換する行為である。しかし、その周辺の全て（システムが何をすべきかの決定、部品の統合方法の定義、セキュリティ境界の設定、生成物が実際に動作するかの判断）は従来通りのコストがかかる。AIはコードを高速に生成できるが、判断、センス、経験は依然として高価である。このミスマッチがAI支援開発の中心的な経済事実である。

代替案を模索するため、著者は意外な領域、すなわちロケットエンジンに目を向ける。米国アポロ計画は、膨大な予算と人員を投入し、打ち上げ前に信頼性を構築する「アポロモデル」を採用した。一方、ソ連のN1ロケットのエンジン工房は、資源不足の中で、頻繁な実機テストと破壊的な反復を活用した。アポロは事前解析と審査に規律を集中させたが、エンジン工房はテスト環境の質、失敗の計測、ループの速度、そして破棄する勇気に規律を置いた。

しかし、ソフトウェアには物理学のような外部の判定者が存在しない。コードはコンパイルできても無意味かもしれない。サービスはAPI契約を満たしても誤ったビジネスルールを実装しているかもしれない。テストスイートがグリーンでも、コードと同じ誤った仮定をエンコードしているかもしれない。したがって、大量のコードを生成して圧力をかけても、現実が自動的に正しい実装を選択してくれるとは限らない。

そこで著者は、既存の「ハードな判定者」を活用することを提案する。コンパイラ、型チェッカ、データベース制約、トランザクション、インターフェース定義、ステートマシン、パーミッション境界、リソース制限、サンドボックスなどだ。これらは、人間が読まなくても機械的に誤った実装を拒否できる。また、サンドボックスやケイパビリティ境界は「防爆壁」として機能し、判定者が見逃したエラーの被害を限定する。

AIを従来のワークフローに導入すると、テスト失敗、課題登録、AIによるパッチ生成、人間によるレビューという流れになる。AIがパッチを人間のレビュー速度の10倍以上で生成すると、レビューキューが全体のスループットボトルネックとなる。しかもAIの出力はもっともらしく見えるため、人間はAIの前提を再構築し、省略されたエッジケースを探し、密かに弱められた制約に気づく必要があり、レビューはより困難になる。

結論として、著者は「生成は自由に、選択は厳格に」という原則を提唱する。高価な確実性は意味と統合が求められる場所に集中させ、それ以外の場所では安価な破壊的イテレーションを活用すべきだ。