あなたは、家を建てるのを手伝ってもらうために、非常に優秀で動きの速い弟子を雇ったと想像してください。この弟子はAIコーディングエージェントです。かつては、ただ「壁を作れ！」と叫んで、あとは成り行き任せにしていたかもしれません。時には素晴らしい壁ができあがることもあれば、時には歪んでいたり、間違ったレンガで作られていたり、あるいは間違った場所に建てられたりすることもありました。

この論文は、単に指示（プロンプト）を叫ぶだけでは、もう不十分であることを主張しています。私たちは、これらのAIの弟子を導くためのフレームワーク——つまり、詳細なルールブック、設計図、そして管理システムのようなもの——を必要としています。著者であるサンダーソン・オリベイラ・デ・マセド（Sanderson Oliveira de Macedo）は、業界で使用されている6つの代表的な「ルールブック」を調査し、それらがどのように作業を整理しているかを分析しました。

以下は、この論文の知見を簡単な比喩を用いて分解したものです。

1. 問題点：「叫ぶ」ことから「管理する」ことへ

昔は、AIに対して一文ずつ話しかけていました。それは、メッセージが途中で失われてしまう「伝言ゲーム」をしているようなものでした。AIは5分前に言ったことを忘れてしまったり、事実を捏造（ハルシネーション）したりすることがありました。

論文によれば、私たちは新しい時代へと移行しています。AIは単にチャットをするのではなく、**「働く」**のです。AIは計画を立て、ファイルを編集し、テストを実行し、自らの間違いを修正します。しかし、マネージャーがいなければ、この自律的な労働者は混沌とした状態になってしまいます。論文が研究している「フレームワーク」とは、AIに対して以下を伝える「マネージャー」なのです。

• 何を作るのか（仕様：Specification）
• プロジェクトについて既に何を知っているのか（コンテキスト：Context）
• 誰が何をすることになっているのか（役割：Roles）
• どのように作るのか（実行：Execution）
• それが正しいかどうかをどう確認するか（検証：Validation）
• 異なる建設現場でも作業できるかどうか（移植性：Portability）

2. 6つのルールブック（フレームワーク）

著者は比較のために、6つの特定の「ルールブック」を選びました。これらを異なる管理スタイルと考えてください。

• GitHub Spec Kit & OpenSpec: これらは建築家のようなものです。AIがレンガを一つ積む前に、完璧な設計図（仕様書）を書くことを要求します。彼らは計画を重視しており、多くの異なるAIツールと連携できます。
• BMAD Method: これは企業の人事部のようなものです。作業を特定の役割（プロダクトマネージャー、設計者、開発者、QA）に分解し、AIにこれらの異なる役割を演じさせます。非常に構造化されていますが、重厚な仕組みです。
• Get Shit Done (GSD): これは、特定のボス（特定のAIツール）のためだけに働くパーソナルアシスタントのようなものです。AIのメモリや集中力を整理することには長けていますが、ボスを替えたい場合には柔軟性に欠けます。
• Spec Kitty: これは建設現場の安全フェンスのようなものです。AIの作業を別のエリア（「ワークツリー」）に隔離することで、メインの建物を誤って壊さないようにします。人間が作業を検査してから統合することを強制します。
• Reversa: これはリバースエンジニアリングです。ゼロから新しい家を建てるのではなく、古くなって崩れかけた建物（レガシーコード）を観察し、元の設計図を解明して、AIが修理できるようにします。

3. 大きな発見：「ノーフリーランチ（無料の昼食はない）」のトレードオフ

この論文の最も重要な発見は、完璧なルールブックは存在しないということです。

著者は、これらのフレームワークを採点するためのスコアリングシステム（ルーブリック）を作成しました。ここでの比喩は以下の通りです。

• あるフレームワークは**「十徳ナイフ（スイスアーミーナイフ）」**のようです。軽く、持ち運びやすく、どこでも使えますが、あらゆる仕事に対応できる深く専門的なツールは備わっていません。計画には優れていますが、作業のチェックには弱いです。
• 他のフレームワークは**「大型建設クレーン」**のようです。非常に強力で、厳格な安全チェックと深いプロセスを備えていますが、移動させるのが難しく、特定の場所でしか機能しません。

トレードオフ： フレームワークがプロセスを深く管理しようとすればするほど（すべてのステップをチェックしたり、役割を割り当てたりすればするほど）、そのフレームワークを別のAIツールへ移行させることは難しくなります。現在のツールでは、極めて深いプロセスを持つことと、極めて高い移植性を同時に持つことはできないのです。

4. 隠れた危険（リスク）

論文はまた、これらのフレームワークがまだ完全に解決できていない「建設現場のハザード（危険）」についても警告しています。

• ドリフト（乖離）： 設計図（仕様）には「赤レンガ」と書いてあるのに、AIが勝手に「青い壁」を建ててしまい、手遅れになるまで誰も気づかないといった現象です。
• 盲信： 私たちは、AIが作った「完成品」を信じすぎてしまうかもしれません。見た目は良くても、その内部は壊れている可能性があるからです。
• 脆弱な拡張機能： これらのフレームワークは多くの場合、コミュニティ製のアドオンに依存しています。もしそのアドオンを作った人が更新をやめてしまったら、システム全体が壊れてしまう可能性があります。
• ロックイン： 一部のフレームワークは特定のAIツールに強く結びついているため、そのツールがルールを変更すると、あなたのプロセス全体が崩壊してしまいます。

5. 次なるステップ（研究課題）

論文は、現在は「ワイルド・ウエスト（無法地帯）」の段階にあると結論づけています。クールなツールはありますが、どれが長期的に本当にうまくいくのかを知るためのデータが不足しています。

著者は、単にクールなデモを見せるだけでなく、**「真の科学」**を行う必要があると示唆しています。

• 中間ステップを測定する： 最終的なコードが機能するかどうかだけでなく、AIの計画や設計図が適切であったかを確認すること。
• メモリをテストする： AIが実際に正しいファイルを読み込んでいるのか、それとも推測しているだけなのか。
• チームを観察する： 数日間ではなく、数ヶ月にわたって、実際の人間チームがどのようにパフォーマンスを発揮するかを観察すること。

まとめ

この論文は、現在のAIソフトウェアツールの風景を描いた地図です。私たちは「AIとチャットする」段階から「AIチームを管理する」段階へと移行しましたが、まだ完璧なマネージャーは見つかっていません。柔軟で移動しやすいツールを選ぶか、あるいは深く厳格だが切り替えが難しいツールを選ぶか、私たちは選択を迫られています。未来は、これらのツールが単にソフトウェアを速く作るだけでなく、本当にソフトウェアを良くしているのかを測定する、より良い方法を構築できるかどうかにかかっています。