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