Amazon Web Services ブログ

AI エージェントがチーム横断で使えない理由

Agentic AIAI エージェントがチーム横断で機能しないのは、開発者の頭の中にしかないドメイン知識 (アーキテクチャパターン、ビジネスルール、設計上の制約など) が欠けているからです。他チームのコードをエージェントに変更させると、大抵うまくいきません。エージェントの能力が足りないのではなく、そのチームのコンテキストを知らないためです。

エージェントをもっと丁寧に監督する方法もありますが、自分が理解していないドメインではエージェントを導けません。他チームのエージェントを直接使おうとするチームもありますが、別のボトルネックが生まれるだけです。開発者は相手のドメインを十分に理解していないため、正しいリクエストを出すことも、レスポンスを評価することもできません。

解決策は、自チームのエージェントに他チームのコードのコンテキストを追加することではありません。他チームのコードは、そのチームのエージェントに任せることです。エージェント間連携とは、たとえば決済チームのエージェントが請求チームのエージェントに構造化されたリクエストを送るということ。各エージェントは自分のドメインコンテキスト内で動作するため、チーム間での知識の受け渡しは不要です。ただし、ほとんどの組織はまだこの基盤を整えていません。

仕組みを説明します。

エージェント間連携の仕組み

各チームはコーディネーターエージェントを運用し、プロダクト、開発、テスト、運用の専門エージェントを管理します。コーディネーター同士は構造化リクエストでやり取りします。決済チームのコーディネーターが請求チームのコーディネーターにリクエストを送り、必要な機能、受け入れ基準、ビジネスコンテキストを指定します。

請求チームのコーディネーターエージェントは、受け取ったリクエストをアーキテクチャ上の決定事項やポリシーに照らして確認します。既存のパターンに合致していれば、処理を進めます。専門エージェントにコードの実装、テストの生成、テストスイートの実行、プルリクエスト (PR) の提出を指示します。

請求チームの開発者が PR をレビューします。エージェントがテストを生成し技術的な正確性を検証済みですが、開発者は実装を確認します。アーキテクチャパターンに適合しているか。エッジケースへの対処は十分か。技術的負債にならないか。レビューは数日ではなく数時間で完了します。コードの実装、テスト生成、動作確認はエージェントが担い、開発者はシステムとの整合性に集中する。マージ後、請求チームのコーディネーターエージェントがデプロイの詳細と更新された API ドキュメントを決済チームのエージェントに通知します。

リクエストが不明確だったり制約に違反している場合、請求チームのコーディネーターエージェントが質問を返すか代替案を提示します。アーキテクチャ上の判断やビジネス上の承認が必要なリクエストは、即座にエスカレーションされます。コーディネーターエージェント同士がまず技術的な詳細を詰め、人間は戦略に集中します。調整作業に時間を取られることはありません。

両チームともコード、品質基準、アーキテクチャの完全な管理権限を維持します。

ドメイン固有の知識

エージェント間連携には、ビジネス上の概念、アーキテクチャパターン、設計判断、エスカレーションポリシーを明文化する必要があります。各チームのエージェントがドメインの技術的・ビジネス的制約に沿った判断を下すには、明文化された知識が欠かせません。明文化されていなければ、コーディネーターエージェントはリクエストが妥当かどうかも、どう実装すべきかも判断できません。

ほとんどのチームにはこうしたドキュメントがありません。チームごとに整備すべき内容を説明します。

ビジネスドメインのドキュメント化

各チームは自ドメインの役割と、それを制約するビジネスルールをドキュメント化する必要があります。ドキュメントがなければ、コーディネーターエージェントは他チームからのリクエストを評価することも、変更を正しく実装することもできません。

チームはまずコアとなる概念を整理します。請求チームであれば請求書、支払い条件、督促手続き。決済チームであればカート管理、支払い処理、注文確認。各チームがビジネスルール、ワークフロー、ドメインの境界を一覧にします。

ドメイン駆動設計 (DDD) を実践している組織では、この基盤の多くがすでにあります。境界づけられたコンテキスト、ユビキタス言語、ドメインモデルは、コーディネーターエージェントが必要とする情報そのものです。DDD を実践していない組織では、各チームがゼロからドキュメントを作成する必要があります。AI エージェントを使えばこの作業を加速できます。コードベースを分析してパターンを抽出し、チームメンバーにヒアリングしてビジネスルールを引き出し、ドメインモデルの初期案を人間のレビュー用に作成できます。

アーキテクチャのドキュメント化

各チームのコーディネーターエージェントは、アーキテクチャの一貫性を維持するためにシステム構造を理解する必要があります。チームはシステムコンポーネントとその関係をドキュメント化し、連携パターンを明示し、サービス間のデータの所有権と保管場所をマッピングし、サービス間の通信プロトコルを定義します。

アーキテクチャのコンテキストがなければ、コーディネーターエージェントが非同期イベントを使うべき箇所で同期 API 呼び出しを提案したり、サービス境界に違反する変更を提案したりする恐れがあります。

アーキテクチャ決定の記録

アーキテクチャのドキュメントはシステム構造を記述しますが、アーキテクチャ決定はなぜそう作ったかを説明するものです。コーディネーターエージェントが他チームからの新しいリクエストを評価し、既存の原則に反していないか判断するには、設計の背景を理解する必要があります。

決定ごとに、その判断に至った背景、検討した代替案、受け入れたトレードオフ、影響を与えた制約を記録します。形式としてはアーキテクチャデシジョンレコード (ADR) が適しています。アーキテクチャの選択におけるなぜを記録するドキュメントです。

各チームのコーディネーターエージェントは、受信リクエストを評価する際に自チームの ADR ナレッジベースを参照します。他チームからのリクエストが既存の決定に反している場合、エージェントはそのまま実装せず即座にエスカレーションします。

エスカレーションポリシーの明確化

コーディネーターエージェントには、自律的に処理できる範囲と人間の判断が必要な範囲の明確な線引きが必要です。各チームがコーディネーターにエスカレーションを義務付ける項目を定めます。承認が必要なビジネス上の判断 (新しい決済手段や価格変更など)、認証・認可・データアクセスに関わるセキュリティ上重要な変更、API の変更やスキーマ変更などの破壊的変更です。

エスカレーションポリシーにより、コーディネーターエージェントは他チームからのリクエストを処理する際に各チームの制約の範囲内で安全に動作できます。

運用インフラストラクチャ

エージェント間連携には、ほとんどの組織がまだ構築していないインフラストラクチャが必要です。

エージェントレジストリの構築

マイクロサービスがサービスレジストリで互いを検出するように、チームにも、どのコーディネーターエージェントが存在し、どんな機能を提供しているかを把握できる仕組みが必要です。各コーディネーターエージェントは自身の能力を公開します。担当するドメインの範囲と境界、明示的に対象外とする範囲。リクエスト方法を示すインターフェース仕様。人間の承認が必要な項目を示すエスカレーション要件です。

デリバリーパイプラインの強化

エージェント間連携により、チーム横断のプルリクエストの量が増加します。2025 年の DORA レポートによると、約 77% の組織は 1 日 1 回以下のデプロイ頻度です。手動のテスト、インテグレーション、デプロイでは増加した量に対応できません。変更リクエストの調整コストがデプロイの調整コストに移っただけになります。

エージェント間連携をスケールさせるには、テストの自動化、CI、CD が先に必要です。この基盤がなければ、コード量の増加はスピードアップではなく調整問題を引き起こします。この基盤構築については「Your AI Coding Assistants Will Overwhelm Your Delivery Pipeline: Here’s How to Prepare」で詳しく書きました。チームにこれらの能力が不足している場合は、まずそちらを整備してください。

AI エージェントで基盤構築のコストを下げる

ドキュメントを必要とする AI エージェント自身が、そのドキュメント作成を手助けできます。

エージェントにドメインの概念やビジネスルールについてチームにヒアリングさせ、コードベースを分析してアーキテクチャパターンを抽出し ADR の初期案を生成させ、既存のコードやドキュメントからドメインモデルの草案を作らせる。エージェントが下書きし、人間がレビューして磨き上げるという流れです。

まずは 1 チームのドメインから小さく始めましょう。ドキュメントが充実するにつれエージェントの自律性が高まり、自律的に動くようになったエージェントが、自らの拠りどころであるドキュメントの維持と拡充も担うようになります。

どこから始めるか

エージェントより先に基盤を作ること。まず 1 チームのドメイン知識をドキュメント化し、AI コーディングアシスタントを使った実際のチーム横断リクエストでそのドキュメントをテストします。うまくいかない点を修正し、ドキュメントが安定して機能するようになってから最初のコーディネーターエージェントを構築する。そこからスケールさせます。

この順序で投資リスクを下げられます。ドキュメントと AI アシスタントだけでチーム間が効果的に連携できるかを検証でき、実際の利用を通じて不足点が明らかになる。コーディネーターを構築する段階では、何が必要かを正確に把握できています。

チーム横断の遅延を最も多く引き起こしているチームを 1 つ選びましょう。そのチームに 1 日かけて 4 つのドキュメントを作成してもらいます。(1) コアなビジネス概念を説明するドメインモデル、(2) システム構造を示すアーキテクチャ概要、(3) リクエストテンプレート付きのコントリビューションガイド、(4) 人間の承認が必要な事項を定義するエスカレーションポリシーです。

3〜5 件の実際のリクエストでテストします。リクエスト元のチームにドキュメントと AI コーディングアシスタントを渡し、最初の PR までの時間とレビューサイクルを計測してベースラインと比較します。

不足している点を修正し、2 か月かけて 3〜4 チームに同じプレイブックを展開します。

4〜5 チームのドキュメントが実証されたら、コーディネーターエージェントの構築を検討します。最もリクエスト量が多いチームにコーディネーターを 1 つ構築し、1 種類のリクエストを処理させます。エージェントを介したリクエストが、AI アシスタントを使う開発者と比較して負荷を減らせるか計測する。価値が証明されれば、レジストリを構築して展開する。そうでなければ改善を繰り返します。

参考資料

  1. DORA 2025 Report: State of AI-assisted Software Development
  2. How AI Is Transforming Work at Anthropic
  3. Measuring the Impact of AI Assistants on Software Development
  4. Amazon Bedrock AgentCore adds quality evaluations and policy controls for deploying trusted AI agents