Amazon Connect AIエージェント オーケストレーションで利用できる3つのツールの選定方法を整理してみた
はじめに
Amazon ConnectのAIエージェント（オーケストレーションタイプ）では、LLMが自律的に情報を取得したりアクションを実行したりするための「ツール」を利用できます。
現在、利用できるツールは主に以下の3種類です。
- Out-of-the-boxツール（標準搭載ツール）
- フローモジュールツール（Connectのフローモジュールをツール化）
- サードパーティーの MCP ツール（Bedrock AgentCore Gateway経由）
これらの中で、ケース情報の取得など標準機能で済む場合は「Out-of-the-boxツール」、Connectの標準ブロックだけで完結する処理なら「フローモジュールツール」と、用途が明確で迷わないケースもあります。
しかし、要件が複雑になり「AWS Lambda経由でAPI（AWSサービスや外部システム）を呼び出すカスタム処理」を実装しようとした場合、どちらのアプローチでもAWS Lambdaを呼び出してAPIを叩くことができるため、「フローモジュールツール」と「サードパーティーの MCP ツール」のどちらを選択すべきか迷うことがよくあります。
- フローモジュールの場合： AIエージェント → フローモジュール →
AWS Lambda 関数を呼び出すブロック → API - サードパーティーの MCP ツールの場合： AIエージェント → Bedrock AgentCore Gateway → Lambda等 → API
このように機能が重複する部分があるため、本記事では、要件に応じてこれら3つのツール全体をどのように使い分け、選定していくべきか、その考え方を「7つのステップ」として整理してみました。
なお、本記事で紹介する選定フローは、公式ドキュメントの仕様を踏まえた上での筆者の個人的な見解・考察に基づくものです。実際のプロジェクト要件に合わせて柔軟に判断するためのひとつの目安として参考にしてください。
ステップ1：すでに実装済みの「フローモジュール」資産があるか？
選定において、真っ先に確認すべきは、フローモジュールの既存資産の有無です。
すでにConnect上で共通処理として利用している「フローモジュール（Lambda呼び出しや属性の設定など）」が存在し、それをそのままAIエージェントのツールとして流用できる場合は、フローモジュールツールを採用します。既存のConnect資産を有効活用するのが最も効率的です。
なお、ツールとして公開するフローモジュールでは「プロンプトの再生」や「顧客の入力取得」といった対話型のブロックはサポートされていません。バックエンド処理（Lambda呼び出し、属性の設定など）を中心としたモジュールである必要があります。
ステップ2：「Out-of-the-boxツール」で要件を満たせるか？
ステップ1と並行して検討すべきなのが、Out-of-the-boxツールです。
これはAmazon Connectに標準で組み込まれているツールで、追加の設定なしですぐに利用できます。用途が非常に明確であり、以下のような一般的なタスクを実行する場合に使用します。
- 問い合わせ属性の更新（
UpdateContactAttributes） - ケース情報の取得（
GetCase）
これら標準機能の範囲内で要件が満たせるのであれば、Out-of-the-boxツールを選択します。
ツール内容は以下にまとめられていますので、参考にしてください。
ステップ3：Lambdaを使わず、Connectの標準ブロックのみ（ノーコード）で完結するか？
既存資産がなく、Out-of-the-boxツールでも要件を満たせない（新規でツールを作成する）場合、次に考えるべきは「その処理は標準ブロックのみ（ノーコード）で実装できるか？」です。
ここで注意が必要なのは、API呼び出しにはSalesforceなどの外部システムだけでなく、Amazon SNSなどのAWSサービスのAPIも含まれるという点です。Lambdaを使ってこれらを呼び出す場合は「ノーコード」ではありません。
もしLambdaを一切使わず、Connectの標準フローブロックの組み合わせのみで完結する場合は、フローモジュールツールが最適です。
例えば、以下のような処理をAIエージェントに実行させたい場合に非常に手軽です。
- 「Eメールの送信」ブロックを使って、お客様に受付完了メールを送信する
- 「タスクの作成」ブロックを使って、オペレーターへの折り返し対応（タスク）を登録する
- 「キューのステータスの確認」ブロックを使って、現在の待ち人数や営業時間を取得する
ステップ4：AWS Knowledge Baseなどの「リモートMCPサーバー」を利用したいか？
ここからは「フローモジュール内でLambdaを呼ぶか」「サードパーティーの MCP ツールを使うか」の2択になります。まず、要件として「リモートMCPサーバー」との統合が含まれているかを確認します。
公式ドキュメントには以下のように記載されています。
Amazon Bedrock AgentCore Gateway を使用して、サードパーティーの統合を使用できます。 AWS マネジメントコンソールに AgentCore Gateway を登録することで、現在サードパーティーアプリケーションが Amazon Connect に登録されている方法と同様に、リモート MCP サーバーなど、それらのサーバーで使用できる任意のツールにアクセスできます。
例えば、「AWS Knowledge Base MCPサーバー」を利用して社内ドキュメントを検索（RAG）させたい場合や、世の中に公開されている様々なリモートMCPサーバーをConnectのAIエージェントに統合したい場合は、必然的にサードパーティーの MCP ツールを選択することになります。
ステップ5：API連携の手段として「Bedrock AgentCore Gateway」が利用できる環境か？
「独自のカスタム処理（API呼び出しなど）」を実装する場合、ここで「前提条件（システム上の制約）」を確認します。
サードパーティーの MCP ツールをAPI呼び出しの手段として利用するには、アーキテクチャ上「Bedrock AgentCore Gateway」との関連付けが必須となります。
そのため、セキュリティ要件やリージョン制約でBedrock AgentCore Gateway自体が利用できない場合や、連携したいバックエンドがAgentCore Gatewayのターゲット対象外である場合は、サードパーティーの MCP ツールは使えません。
この場合は必然的に、もう一つの手段であるフローモジュールツール（Lambda呼び出し）一択となります。
ステップ6：すでに別のシステムで「Bedrock AgentCore Gateway」を利用しているか？
もし、すでに社内の別のシステム（社内チャットボットなど）でBedrock AgentCore Gatewayが使われており、そこにツール（Action Groupなど）の資産がある場合、Connect側から関連付けるだけでその資産をそのまま流用できます。
すでにBedrock AgentCore Gatewayを利用している環境であり、既存のツール資産を活かせるのであれば、サードパーティーの MCP ツールを採用するのが自然な流れになります。
ステップ7：新規開発において、処理はシンプル（単一のLambda呼び出し等）か？
ステップ1〜6のどれにも該当しない場合（＝AgentCore Gatewayは使える環境だが、既存資産もなく、リモートMCPサーバーも使わない新規開発の場合）、最終的な判断基準は「アーキテクチャの複雑性とコスト」になります。
例えば、「Lambdaを1回呼び出してAmazon SNSでSMSを送信するだけ」といったシンプルな処理であれば、フローモジュールツールをおすすめします。
サードパーティーの MCP ツールを採用すると「Bedrock AgentCore Gateway」というリソースが追加で必要になり、管理対象が増えるだけでなく、ランニングコストも余分にかかってしまうためです。シンプルな処理はシンプルに実装するのが望ましいです。
逆に、複数のAPIをオーケストレーションするような複雑な処理が必要な場合は、バックエンドに処理を切り離して管理しやすいサードパーティーの MCP ツールの採用を検討します。
まとめ
ここまでの考え方をまとめると、以下のような選定フローになります。
上から順番に確認し、最初に該当したツールを採用していく形がスムーズです（※あくまで筆者の個人的な見解に基づく推奨フローです）。
| 確認順 | 確認内容（要件・環境） | 採用すべきツール | 採用の理由・ポイント |
|---|---|---|---|
| 1 | すでにツールとして使いたいフローモジュールがあるか？ | フローモジュールツール | 既存のConnect資産を有効活用するため |
| 2 | ケース取得や属性更新など、標準機能で要件を満たせるか？ | Out-of-the-boxツール | 追加設定なしですぐに利用できるため |
| 3 | Lambdaを使わず、Connectの標準ブロックのみ（ノーコード）で完結するか？ | フローモジュールツール | 手軽にConnectの機能をAIに持たせられるため |
| 4 | AWS Knowledge Baseなどの「リモートMCPサーバー」を利用したいか？ | サードパーティーの MCP ツール | リモートMCPサーバーとの統合に必須なため |
| 5 | 連携先は「Bedrock AgentCore Gateway」のターゲット対象外（または利用不可）か？ | フローモジュールツール (Lambda呼び出し) |
サードパーティーの MCP ツールを利用するための前提条件を満たせないため |
| 6 | すでに別のシステムでBedrock AgentCore Gatewayを利用しており、流用できるツール資産があるか？ | サードパーティーの MCP ツール | 既存のBedrock資産を有効活用するため |
| 7 | 新規開発において、処理がシンプル（単一のLambda呼び出し等）か？ | フローモジュールツール | リソース追加を避け、コストを最適化するため |
| - | 上記すべてに該当しない（複雑なAPIオーケストレーション等が必要な新規開発） | サードパーティーの MCP ツール | 複雑な処理をバックエンドに切り離して管理するため |
「フローモジュールでもMCPでもLambdaを呼び出せる」という機能の重複があるからこそ迷いがちですが、この表の順番で要件と制約を整理していくことで、最適なツールを迷わず選定できるはずです。
AIエージェントのアーキテクチャ設計の際、ひとつの目安として参考になれば幸いです。
参考
