AIエージェントを複数体使って開発チームを組む、という試みが増えてきた。プロダクトオーナー、スクラムマスター、開発者。人間のチーム構成をそのままAIに当てはめるアプローチだ。
これに違和感がある。前回の記事では1体のAIとチームとして動く話を書いたが、複数体に増やすとき、人間のチーム構成をそのまま持ち込んでもうまくいかないと感じている。
実際にAIと業務システムの仕様書を書いた経験から、エージェントチームをどう組むべきか考えたことを書いてみる。
「役割」で分けると何が起きるか
PO役のAI、スクラムマスター役のAI、開発者役のAI。肩書は違うが、中身は同じモデルだ。もちろんプロンプトで振る舞いは変えられる。だが問題は、人間のチームに存在する「役割間のやりとり」まで再現しようとすることにある。
結果として起きるのは、
- エージェント間の「合意形成」にトークンが消費される
- スプリントプランニングの議事録やレトロスペクティブの記録にリソースが割かれる
- 実際の成果物（コード、仕様書）に回るリソースが減る
といったことだ。
プロセスの再現にリソースを割くほど、成果物にかけられるリソースが減る。エージェントの数を増やしたのに生産性が上がらないケースは、このオーバーヘッドが原因だと思っている。
「観点」で分けるとは
AIと勤怠管理パッケージの仕様書を書いたとき、一つのAIに対してこういう問いを順番に投げた。
- 設計観点 「結構なオブジェクト数だけど、プラットフォームの制限的にどう？」
- 法務観点 「いい感じにまとまってきたね。ところで法的な考慮事項ある？」
- アーキテクチャ観点 「これパッケージ分離したほうがいい？ 分離したときの制約は？」
- 運用観点 「レコード数がえらいことになる。アーカイブも視野に入れたほうがいいよね？」
手動で観点を切り替えた例だが、エージェントチームを組むなら、この観点ごとにエージェントを立てればいい。1体に全部聞くとコンテキストが膨れるし、観点ごとに並列で走らせれば時間も短縮できる。
| エージェント | 観点 | 常駐プロンプトの例 |
|---|---|---|
| 設計担当 | データモデルの整合性、パフォーマンス | 「この設計にスケーラビリティ上の落とし穴はあるか？」 |
| 品質担当 | バリデーションの抜け漏れ、エッジケース | 「この状態遷移で考慮されていないパターンはあるか？」 |
| 法務担当 | 法令準拠、データ保持義務 | 「この仕様に法的なリスクや義務の見落としはあるか？」 |
| 基盤担当 | プラットフォーム制約、API制限 | 「対象プラットフォームの制約に照らして実現可能か？」 |
同じ仕様を異なる専門知識で検証することで、品質があげあられる。
エージェントチームの構成パターン
観点ベースのエージェントチームをどう実装するか。いくつかのアプローチがあり、状況に応じて使い分ける。
サブエージェント方式
メインのエージェントが仕様を書き、サブエージェントが各観点で洗い出しを行い、メインが統合する。
人間 → メインエージェント（仕様作成）
├→ 設計サブエージェント（レビュー）
├→ 品質サブエージェント（レビュー）
└→ 法務サブエージェント（レビュー）
← 統合結果を人間がレビュー
スキル組み込み方式
レビュー観点をスキル（再利用可能なプロンプト定義）に組み込み、仕様書を書くたびに自動的にチェックされるようにする。
- 組織のナレッジとして蓄積できる
- プロジェクトを重ねるごとにレビュー精度が上がる
- 属人的な「問い」を仕組みとして外在化できる
シミュレーター方式
エージェントチームの真価は、開発そのものよりもシミュレーションにあるかもしれない。まだ構想段階だが、こういう使い方を考えている。
- 1スプリントを数時間で回して、どんな問題が起きるかを観察する
- 人間は結果を分析し、プロセスを改善する
- 翌日にじっくり「感想戦」をやって、次のシミュレーションに反映する
1日でシミュレーション→分析→改善のサイクルが回るなら、実チームを巻き込む前にプロセスの骨格を検証できる。小さく失敗するための道具として使う。
人間の仕事は「問い」を立てること
20行ぐらいの「やりたいこと」を書いて、AIと壁打ちした結果、1250行超の仕様書になった。
この過程で一番価値があったのは、「あれしたい、これしたい」ではなく、「ところで落とし穴あるか？」という問いかけのほうだった。
- 法定休日の割増賃金率が60時間カウントに含まれない
- 撤回申請の状態遷移が二重承認になる
- 監査証跡を追記専用にしないと任意の時点の状態を再現できない
こうした問題は、要望の列挙からは出てこない。「ところで」の一言から出てくる。AIの出力の質を決めるのは、人間の問いやこだわりだと思う。
エージェントを何体並べても、この原則は変わらない。曖昧な指示からは曖昧な成果物しか出てこないし、精緻な仕様があれば1体でもかなりいい仕事をしてくれる。観点ベースのエージェントは、人間が手動で切り替えていた問いを自動化するものであって、問い自体の設計は人間の仕事だ。
この視点は「AIをツールとして使う」発想からは出てこない。AIとの協働はチーム設計の問題だ。誰が何を担い、どこで相互作用が起き、どういうリズムで回すかを考える必要がある。
まとめ
実践から見えた設計原則を整理すると、
- 役割ではなく観点で分ける。同じ仕様を異なる専門的視点から検証する
- 問いの質が出力を決める。「ところで落とし穴あるか？」が最も価値のある入力
- 人間はステークホルダーとして意思決定する。何を作るか、これでいいかの判断は人間が握る
- レビュー観点をスキルとして蓄積する。属人的な暗黙知を組織のナレッジに変換する
- シミュレーターとして使う選択肢を持つ。開発だけがエージェントチームの用途ではない
結局のところ、エージェントチームの設計は、人間とAIの特性を踏まえたチーム設計の問題だ。人間のチームの形をそのまま持ち込むのではなく、AIが強いところにAIを置き、人間が強いところに人間を置く。向き不向きを見極めて、適切に配置する。言葉にしてしまえばシンプルだが、昔から難しい領域だと思う。