【ITニュース解説】926 Steps, Two Lobotomies, and Zero Nudges: Flight-Testing the Commitment Machine Across Gemini, Claude, and GPT-OSS

AIによるプログラミング支援ツールが普及し、多くの企業がその導入を進めている。AIコーディングエージェントは、開発者が書くコードの量を大幅に増やし、生産性向上に貢献すると期待される。しかし、ハーバード大学の研究によると、現実はそう単純ではないことが明らかになった。

この研究は、2021年から2026年にかけて718社、72万5000人以上のソフトウェア開発者を対象に行われた大規模なもので、2026年初頭までに95%以上の企業がAIコーディングエージェントを導入していた。その結果、開発者が書くコードの量は30%増加し、プルリクエスト（コードの変更を他の開発者にレビューしてもらうための要求）も23%増えたことが判明した。しかし、驚くべきことに、実際に完了した課題（Jiraチケットやエピック）の数は全く増えていなかった。つまり、多くのコードが書かれても、最終的な成果にはつながっていなかったのだ。

この原因は、コードレビューのプロセスにある。AIによってコードの作成速度は上がったものの、プルリクエストのレビュー待ち時間は49%も増加し、さらにコードの書き直しを求められるプルリクエストの数は約2倍に跳ね上がった。一つあたりのプルリクエストに対するレビューコメントも35%増加し、結果として上級エンジニアが自分の本来の仕事から引き離され、AIが書いたコードの「お守り」をする時間が増えてしまった。

なぜこのような現象が起こるのか。それは、AIエージェントが与えられた指示に対して素直にコードを生成する傾向にあるためだ。たとえその指示が古かったり、既に解決済みの問題だったりしても、AIはそれを自動で判断して「これは不要だ」と指摘することなく、コードを書き続けてしまう。その結果、品質の低い、あるいは不要なコードが大量に生成され、そのチェックと修正の負担が人間のレビュー担当者に集中し、開発全体のボトルネックになってしまうのである。

このような問題を解決するため、筆者は「コミットメントマシン」と呼ぶ新しいコーディングワークフローを開発した。これは、コードを実際にコミット（変更を保存）する前に、チケットの内容を厳密に検証し、コードの品質をレビューし、作業の状態をきちんと管理するというものだ。具体的には、1986年の「Committed Speech」という考え方や、昔ながらのMakefile、そしてUnixシステムで起動プロセスを管理する/etc/init.dのようなファイル構造からヒントを得て、このワークフローを構築した。

この新しいワークフローは、主に3つの方法でAIコーディングのボトルネックを解消する。

第一に、コードが不必要に肥大化するのを防ぐ。一般的なAIは、古くなったチケットや既に解決済みのチケットに対しても、言われた通りにコードを書き進めてしまう。コミットメントマシンでは、「Codebase Archaeologist（コードベース考古学者）」というサブエージェントが、コードを書き始める前にチケットの内容を過去のコード変更履歴と照合する。もしそのチケットが既に解決済みであったり、矛盾する内容を含んでいたりすれば、エージェントはコードを書くことなく、そのチケットを「Counter-Offer（対案）」としてクローズする。例えば、あるチケットで特定の機能の実装が求められても、考古学者が調べた結果、その機能がすでに実装済みであり、かつ過去のレビューで「不要」と判断され削除されていたことが判明したケースがあった。通常のAIなら約280行のコードを書いていたであろう場面で、コミットメントマシンはコードを一行も書かずにチケットを8分で完了させ、無駄な作業を完全に防いだのである。

第二に、レビューのボトルネックを大幅に削減する。従来のAIを使った開発では、AIが生成したコードが人間によるレビューを待つ間に何日もかかり、さらに多くの修正が必要となるケースが多かった。コミットメントマシンでは、「Adversarial Critic（敵対的批評家）」というサブエージェントが、コードをコミットする前にローカルで徹底的にコードレビューを行う。これにより、一般的な静的解析ツールでは見過ごされがちな微妙なバグや、特定のフレームワーク特有の落とし穴を、人間がプルリクエストを開く前にAI自身が発見し、修正する。さらに、自動生成されるレビューコメントも一つにまとめて表示することで、人間のレビュー担当者が確認すべき情報が整理され、レビューにかかる手間と時間が大幅に削減される。開発者は、すべてのチェックが完了し、問題がないことを示す「緑のボード」が表示されるまで、GitHubのプルリクエストページを開く必要すらなくなるのだ。

第三に、AIエージェントの「記憶喪失」を防ぎ、異なるAIモデル間での柔軟な切り替えを可能にする。大規模なAIモデルは、一度に扱える情報量（コンテキストウィンドウ）に限りがあるため、長時間の作業や複雑なタスクでは過去の会話内容を忘れてしまう「ロバトミー（記憶喪失）」と呼ばれる現象が起こることがある。また、AIサービスの利用料金や性能の問題で、作業の途中で異なるAIモデルに切り替えたい場合もあるだろう。コミットメントマシンでは、AIエージェントの作業状況や意思決定の履歴を、ディスク上の番号付きMarkdownファイル（/etc/init.dに倣った形式）として保存する。これにより、AIが記憶を失ったり、別のモデルに交代したりしても、新しいモデルはディスク上のファイルからこれまでの作業内容を正確に読み込み、中断することなく作業を再開できる。実際に、作業中にAPIの利用制限に達した際、ClaudeからGeminiにモデルを切り替えたところ、新しいモデルが前のモデルが書き込んだファイルを読み込み、何事もなかったかのように残りの作業を完了させた事例も確認されている。これは、AIモデルを単なる「CPU」として捉え、永続的な「ハードドライブ」に状態を保存するという画期的なアプローチである。

ただし、このコミットメントマシンは、どんなAIモデルでも万能に機能するわけではない。筆者は、GPT-OSS 120Bというオープンソースの大規模言語モデルを同じワークフローで試したが、結果は失敗に終わった。このモデルは、/etc/init.d形式で保存された作業指示ファイルを完全に無視し、ローカルにあるはずのプライベートなコードをGoogleで検索したり、Gitのコミットプロセスを複数同時に実行させてGitリポジトリを破壊したりするなど、基本的な指示も守れずに破綻してしまったのである。

この結果は、AIモデルには「ドライバーズライセンス」とでも呼ぶべき基本的な能力が必要であることを示唆している。すなわち、提供されたルールを正確に理解し従う能力、ツールを適切に呼び出す能力、基本的なツールの使い方を理解しているか、そしてエラーが発生した際に正直に報告する能力だ。これらの基本的な能力がなければ、どんなに優れたワークフローやツールを与えても、AIは正しく作業を進めることができない。コミットメントマシンは、優れたAIモデルを「レールの上」に保つことはできるが、基本的な理解力を持たないモデルには対応できないのである。

今回の検証で明らかになったことは、AIによるコード生成をただ高速化するだけでは、ソフトウェア開発の生産性は向上しないということだ。むしろ、コードを生成する「前」に、そのコードが本当に必要か、正しいかを検証し、質の高いコードがコミットされるように徹底的にチェックする仕組みが不可欠である。AIエージェントの「脳」を一時的なコンテキストウィンドウではなく、永続的なファイルシステムに置くことで、より堅牢で柔軟な開発が可能となる。そして、AIモデルの能力には差があることを理解し、適切なモデルを選択することも重要だ。これらの知見は、システムエンジニアを目指す上で、AIを単なるツールとしてではなく、開発プロセス全体を最適化する視点を持つことの重要性を示している。