【ITニュース解説】From Coding to Lead Agents

システムエンジニアを目指す皆さんにとって、AI、特に大規模言語モデルは、将来の仕事に深く関わる技術だ。この記事では、AIと協力してソフトウェアを開発するアプローチがどのように進化してきたか、そしてその中で人間の役割がどう変わっていくのかが語られている。初期のAIとの付き合い方から、より高度な協業の形へと変化する過程を追ってみよう。

かつてAIとの開発は、非常にシンプルだった。コードを生成してほしいとAIに頼み、出てきた結果を読んで修正し、また依頼する、という繰り返しだ。これは「プロンプト駆動開発」とも呼ばれるが、実際には、AIが過去に何を生成したか、どんな修正があったか、どこで方向性がずれたか、そして「これで完成」と判断するのは全て人間だった。AIはただ指示されたことに対し反応するだけで、全体の進行管理は人間が担っていたのだ。

しかし、この方法にはいくつかの問題があった。開発に関する重要な決定事項が全てチャット履歴に埋もれてしまい、AIの記憶領域（コンテキスト）が長くなると、以前に合意した内容をAIが「忘れてしまう」ことが頻繁に発生した。さらに、初期のコード生成の段階で問題があったとしても、その後の修正が積み重なることで、次第にコード全体が複雑になり、AIが新しい機能やテストを作成する際に、最初の要求ではなく、すでに存在している問題のあるコードに合わせてしまう傾向があった。AIは自信満々に「完成した」と報告しても、それが本当に要求を満たしているかの客観的な証拠は乏しかった。これは、AIに要件分析、設計、開発、テスト、レビューといった多様な役割を同時に押し付けており、AIが全ての状況を記憶し、完璧にこなすのは困難であったためだ。

この状況を改善するため、まず「仕様駆動開発（SDD）」というアプローチが導入された。これは、ソフトウェア開発のプロセスを明確な段階に分け、それぞれの段階で特定の成果物（ファイル）を作り出す方法だ。具体的には、仕様策定、明確化、計画、タスク洗い出し、分析、実装、検証といったフェーズに分けられる。

このSDDの導入で、特に重要な二つのルールが生まれた。一つ目は、「状態はチャットではなくファイルを通じて管理する」というものだ。各フェーズを実行する前に、AIのコンテキストは一度完全にクリアされる。そして、次のフェーズでは、直前のフェーズで作成され、承認されたファイルのみを読み込む。例えば、計画フェーズでは、承認された「spec.md」という仕様書ファイルだけを読み込む。これにより、各フェーズは、チャットの中で曖昧に積み重ねられた半端な決定ではなく、実際に書かれた明確な情報に基づいて作業を進めることができる。「ファイルに書かれていないことは、存在しない」という厳格な原則が適用されることで、情報の正確性と一貫性が保たれるようになった。

二つ目のルールは、「実装担当者はテストを書かない」というものだ。このルールでは、コードを実装するフェーズは純粋にプロダクトコードのみを作成し、テストコードは一切書かない。テストは、その後の「検証」フェーズで、仕様書に記載されている受け入れ例に基づいて、そして実装されたプロダクトコードを一切読まない別のAIエージェントが作成するのだ。なぜこのような手法をとるのかというと、実装コードを見たAIは、そのコードに合わせてテストを書いてしまう傾向があるからだ。これでは、本来の要求ではなく、現存するコードの振る舞いを追認するテストになってしまう。しかし、実装コードを見ずに仕様書からテストを作成するAIは、純粋に要求を満たしているかを客観的に検証するテストを作り出すことができる。このルールは、各フェーズ間でAIのコンテキストを完全にクリアすることで機能する。

新しい機能の開発だけでなく、既存のバグ修正もこのSDDパイプラインに組み込まれる。バグが発生した場合、まずそのバグがどのような入力で再現され、どのような出力になるのかを明確にし、期待される正しい動作が既存の契約や製品の決定事項と一致するかを確認する。判断できない場合は人間の介入を求める。そして、そのバグが本当に自身のコードベースに起因するものなのかも確認する。このように、AIに「いつ作業を停止するか」を教えることは、「何をすべきか」を教えることと同等に価値があることがわかった。

SDDを導入しても、各フェーズを手動で実行し、AIのコンテキストをクリアし、結果を確認して次のフェーズに進むという作業は、まだ人間が「非常に注意力のある繰り返し処理」として行っていた。そこで次の段階として、この一連の繰り返し処理自体をAIに任せるという発想が生まれた。これが「オーケストレーター」と呼ばれるAIエージェントの登場だ。

オーケストレーターは、自ら作業を行うのではなく、全体のプロセスを指揮する役割を担う。これは、各フェーズを順番に実行し、各フェーズの作業を行うために新しく独立したサブエージェントを作成し、そのサブエージェントに特定のスキル（フェーズの指示）を実行させる。また、各フェーズの前に進捗ファイルを読み込み、完了後にはその結果を記録し、サブエージェントは簡潔な報告を行う。もしフェーズが失敗したりブロックされたりした場合は、そこで停止し、その理由を報告するといったルールに基づいて動作する。

この仕組みの肝は、フェーズごとに新しいサブエージェントを作成する点だ。これにより、以前手動で行っていた「フェーズ間のコンテキストクリア」が自動的に行われる。各サブエージェントは、そのフェーズの目標、指示、関連する成果物、制約、受け入れ基準といった、必要最低限の情報しか与えられない。過去の会話履歴や推論は一切与えられないため、常にまっさらな状態で与えられたタスクに集中できる。オーケストレーター自身も、次のアクションを決定するために必要な最小限の状態のみを保持し、複雑な作業空間にはならない。

各サブエージェントは、作業完了時に決められた形式で短いレポートを返却する。ステータス（成功、失敗、ブロック）、概要、作成・変更されたファイル、実行された検証とその結果、ブロックされている事項、または無し、次に推奨されるアクションといった内容だ。特に重要なのは、PASS（成功）は受け入れ基準が実際にチェックされた場合にのみ有効とされ、エラーが報告されなかっただけでは成功とは認められない点だ。

オーケストレーターの「記憶」となるのが「進捗ファイル」だ。現在のフェーズ、完了したフェーズ、成果物、検証結果、ブロック事項などがこのファイルに構造化されて記録される。これにより、もし途中でセッションが中断しても、新しいAIエージェントがこのファイルを読み込むことで、作業を中断したところから再開できる。

さらに、このプロセスには「レビュー」の仕組みも組み込まれている。開発フェーズが完了した後、別の新しいサブエージェントが変更されたコード全体をレビューする。もし問題が見つかれば、別のサブエージェントがそれを修正し、関連するテストと検証が再度実行され、再び独立したレビューエージェントがその結果を確認する。このレビューには、最大3回のラウンドという厳しい制限がある。3回を超えても問題が解決しない場合、プロセスは停止し、成功とはみなされない。また、AIが自分自身の問題を解決したと判断する「自己認証」は許されず、常に客観的な証拠が求められる。

最終的な完了の条件も明確だ。レビューで指摘事項がなく、関連するテストが全て合格し、検証レポートも通過し、仕様書とコードとテストが一致しており、意図しない変更がなく、何もブロックされていない場合にのみ、プロセスは完了とみなされる。その上で、適切なターゲットブランチへのコミット、プッシュ、プルリクエストの作成が行われる。もしターゲットブランチを確実に特定できない場合は、AIは推測せず停止し、人間の指示を求める。

このオーケストレーターによる自動化が進むと、今度は「計画」そのものが弱点として浮上してきた。人間が理解できる「モジュールをリファクタリングする」とか「テストを修正する」といった曖昧な計画では、履歴を持たない孤立したコンテキストで作業するAIエージェントには実行不可能だったのだ。

そこで、今度は「オーケストレーターが実行できる計画」を生成するためだけの別のプロンプトを作成するようになった。このプロンプトによって生成される計画の各タスクには、正確な目標、このタスクに必要なファイルと成果物、変更を許可される範囲と超えてはならない境界、アプローチと制約、先行して完了すべきタスク、完了を判断するための観測可能な条件、実行すべきコマンドやテスト、次の担当者への簡単なサマリーといった情報が含まれる。さらに、タスクの依存関係マップや、作業が中断しても再開できるための実行状態チェックポイントも同時に生成される。計画が良いものであるかを判断する基準は、「別のAIエージェントが、その計画の仕様と参照されたファイルだけを使って、元の調査内容を知らなくてもタスクを実行できるか」というものだ。それができなければ、まだ計画は完成していないと判断される。

このような進化を経て、ソフトウェア開発のプロセスと、その中での人間の役割は大きく変化した。以前はAIにリクエストを書き、チャットが状態を保持し、AIの意見が「完了」の判断基準だった。人間は間違いを見つけるために全てを読んでいた。しかし今では、人間はプロセスを書き、ファイルが状態を保持し、役割ごとに最小限のコンテキストを持つAIエージェントが協業する。「完了」は検証された条件のリストによって定義され、人間は全ての成果物をレビューするが、間違いはゲート、制限、レビューの仕組みが捕らえる。

この経験から得られた教訓は非常に重要だ。まず、「コンテキストは管理すべき資源」であり、制約のあるシステムにおけるメモリのように、必要なものだけをロードし、それ以外は永続化して管理すべきだ。次に、「AIエージェントに停止することを教える」こと。問題を抱えながら推測して作業を進めるAIよりも、ブロックされたり、規定回数を超えたりしたら停止し、その理由を説明できるAIの方がはるかに信頼できる。そして、「構築者と検査者を分離する」という原則。実装担当者がテストを書かず、コードを見ないテスターがテストを作成するように、チェックする側は構築者の推論を知らない方が、客観的で信頼性の高い検証が可能となる。さらに、「自信ではなく証拠を要求する」こと。AIは簡単に「成功した」と報告するため、プロンプトに具体的な証拠を求める指示を組み込む必要がある。最後に、「最終的な責任はまだ人間にある」ことだ。AIエージェントに多くの仕事を委譲しても、仕様、計画、最終的な変更内容をレビューするのは人間の役割だ。AIをリードすることは、その場を離れることではないのだ。

システムエンジニアを目指す皆さんにとって、このAIとの協業の進化は、将来の働き方を考える上で非常に示唆に富んでいる。単にAIにコードを生成させるだけでなく、AIを「エージェント」として組織し、信頼性の高い開発プロセスを自動化していくことが、これからのエンジニアリングの重要なスキルとなるだろう。