同じ組織でAIを使っていても、開発者ごとに依頼の仕方や作業の進め方が異なり、成果物の品質が安定しない。その問題を改善するために、AIに任せる開発作業の手順を共通化しようとしました。
ところが、その仕組みを作る作業自体をAIに任せると、実装とレビューが収束しなくなりました。エージェント間で受け渡す情報の検査が増え、その対応に追われるようになったのです。
共通化したかったのは、開発者ごとのAIの使い方
対象は、障害の原因調査、設計検討と実装、ユニットテスト実装、回帰テストなど、繰り返し行う開発作業です。作業の進め方をAIへの指示としてまとめた「スキル」と、設計・実装・レビューといった役割を持つAI「サブエージェント」を用意し、組み合わせて実行する構想でした。
利用コストも抑えるため、実装には低コストのモデルを使い、設計とレビューには判断能力を重視して選んだモデルを配置しました。図1は、その分業の一例です。
この取り組みには、当時のモデルの組み合わせで、どこまで成果物の品質を高められるかを試す狙いもありました。AIの工程だけで完成を保証する想定ではなく、人間のレビューや回帰テストなどで品質を確認し、必要な修正を加える前提でした。
仕組みを作るAIが、中間情報の検証を増やし始めた
この構想を形にするため、まず役割を仮決めしたサブエージェントを用意し、スキルとサブエージェントの開発を依頼しました。問題が起きたのは、この仕組みを構築している段階です。
構築中の仕組みでは、各エージェントが作業結果と一緒に、次のエージェントへ状態や処理要求を伝える「制御情報ブロック」を出力する構成になっていました。実装とレビューを重ねるうちに、この情報や作業経過の記録に、厳密さを求める指摘が増えていきました。
特に負担が大きかったのは、AIがファイルのハッシュ値を取得し、制御情報に載せて一致を確認する仕組みを追加したことです。ハッシュ値は、ファイルの内容を照合するための値です。AIは版の整合性まで管理し始めていましたが、当初は作業報告を眺めているだけでは、何をしているのか把握できていませんでした。
また、差し戻しを示す制御情報に、受信側が想定していない表現が現れ、検査を通過できないことがありました。これに対応する修正と再レビューでも検査の追加・厳密化が進み、収束しにくくなっていきました。
検査への対応を重ねるうちに、作業の重点は、開発手順の共通化から、仕組みの内部を厳密に管理することへ移っていました。
進行管理を変え、AIに任せる範囲を再確認した
この状況を受け、全体を取りまとめる親エージェントが、自身のコンテキストで進捗や次に行う作業を管理する構成に変えました。
| 観点 | 変更前 | 変更後 |
|---|---|---|
| 進行管理の基準 | 子の出力に含まれる制御情報 | 親が主体的に管理する状態 |
| 次の作業への進み方 | 受け渡す制御情報の形式・内容が検査を通ることに依存 | 親が子の作業結果や報告を参照し、次の作業を指示 |
併せて、プロジェクトの目的と品質要求を再提示しました。目指すのは、当時のモデル構成で可能な限り品質の高い成果物を得ることです。人間やテストによる品質確認を前提に、進行管理のための中間情報に求める不要な厳密さを取り除き、ワークフローを最後まで進めることを優先させました。
変更後は、完成した仕組みで開発タスクを最後まで処理できるようになりました。
この経験から考える、AIへの任せ方
追加された要求を、元の目的に照らして確認する
今回の出来事は、一度きりの実装上の問題として片付けず、AIに作業を委任するときに想定しておきたい失敗だと考えています。複数のエージェント基盤を分析したMAST研究でも、設計、エージェント間の認識の不一致、検証に関する失敗が整理されています。[1]
今回のような逸脱を早めに捉えるため、次の二つの場面で立ち止まりたいと考えています。
- 新しい検査や管理機構を追加するとき：元のどの要求に必要なのか、必須の対応か追加の改善提案かを報告させる。
- 同じ種類の修正が続き、進展が見られないとき：人間が目的と構成を見直し、作業を続けるか、進め方を変えるかを判断する。
低単価のモデルを組み合わせても、安くなるとは限らない
モデルの単価が低くても、レビューと修正の往復が増えれば、完了までの費用と時間は膨らみます。構成を比較した研究では、単一エージェントの能力が高まると協調の追加効果が小さくなる一方、並列に分担しやすい仕事では複数エージェントが有利になる結果が示されています。[2]
モデルを更新するときは、分業の必要性も見直したいと考えています。まず高性能モデルを使う単一エージェントを基準にし、同程度の品質に到達するまでの利用料、所要時間、人間が介入する手間を比べます。分業による節約が、連携や手戻りの負担を上回るかを判断基準にします。単純な構成から始め、必要に応じて複雑さを加える方針は、Anthropicの技術資料でも示されています。[3]
共通の手順は残し、実行構成は固定しない
当初の目的は、組織内のAI活用手順をそろえることでした。その手順は、単一エージェントに実行させることもできます。モデルの進歩によって分業の利点が小さくなっても、整理したスキルや確認手順まで不要になるわけではありません。
残すべきものは、組織として共有する作業手順と品質の基準です。それをどのモデルに、どのように実行させるかは、費用と成果を見ながら変えていきたいと考えています。
参考資料
- Mert Cemri et al. Why Do Multi-Agent LLM Systems Fail? NeurIPS 2025, Datasets and Benchmarks Track（査読論文）。エージェントシステムの失敗を分類したMAST研究。
- Yubin Kim et al. Towards a Science of Scaling Agent Systems arXiv, v3, 2026年4月（プレプリント）。単一・複数エージェントの構成と、タスクとの適合性を比較。
- Anthropic. Building effective agents 2024年12月（公式技術記事）。単純な構成を出発点とし、必要性に応じて複雑さを加える設計方針。