Amazon Web Services ブログ
AI Agent は “つながり” で進化する ─ Amazon Connect Customer × Salesforce MCP 連携
統合されたアーキテクチャの「幅広さ」こそが、AI エージェントの能力を左右する ── その理由。
はじめに
エージェンティックな統合（agentic integration）による自律的な問題解決が、コンタクトセンターの運用のあり方を再定義しつつあります。AI の推論能力の進化、オープンな統合標準、そしてコンポーザブル（組み合わせ可能）なサービス設計が一つに収束したことで、これまで実現不可能だったことが実用的なものになりました。 すなわち、複数システムにまたがる複雑なお客様の課題を、AI エージェントがリアルタイムに自律的に解決できるようになったのです。 Model Context Protocol（MCP）を通じて接続された Amazon Connect Customer と Salesforce は、この変化の最先端を象徴しています。
エージェンティックな統合は、これを実現するためのアーキテクチャの考え方です。あらかじめすべての判断パターンをコンタクトフローに作り込んでおくのではなく、大規模言語モデル（LLM）を基盤とするオーケストレーター AI エージェントが、「どのシステムを、どの順番で呼び出すか」をその場で判断し、処理の途中で得られた結果を見ながら進め方を柔軟に見直していきます。AI エージェントはお客様の意図をくみ取り、Salesforce のようなシステムオブレコード（顧客情報などを蓄積する中核システム）、運用系のサービス、ナレッジベースにまたがる一連の処理をつなぎ合わせ、複雑な課題を最初から最後まで一貫して解決します。
本記事では、Amazon Connect Customer（システムオブエンゲージメント：お客様との対話を担う中核）と Salesforce（システムオブレコード）を例に、エージェンティックな統合の設計原則、プロトコル層、そしてそれが持つ戦略的な意味を見ていきます。まず、自律的に課題を解決する仕組みである推論ループを紹介し、続いて「乗数効果（multiplier effect）」によって、つなぐシステムの幅広さがなぜ AI の力を何倍にも高めるのかをひもときます。最後に、複数システムを自由に組み合わせて動かす仕組みをエンタープライズ規模で実用化するオープン標準として、Model Context Protocol を紹介します。
構造的制約から、AI エージェント主導のオーケストレーションへ
図: フロー主導の API 統合から、AI エージェント主導のオーケストレーションへのアーキテクチャの転換。左側は、Amazon Connect Customer とバックエンドシステムの間でハードコードされた API 呼び出しを行う直線的なフロー。右側は、中心に位置する AI エージェントが MCP を通じて複数システムを動的にオーケストレーションする様子。
何十年もの間、企業のシステム統合は「システム同士をつなぐことは、機械的な単純作業にすぎない」という一つの思い込みのもとで進められてきました。コンタクトセンターは、この考え方が最もはっきりと表れてきた領域です。IVR（自動音声応答）のメニューは、あらかじめ決められた分岐に沿ってお客様をルーティングし、API は決まった順番で呼び出され、それまでのやり取りの文脈は、担当や処理が切り替わるたびに捨てられてしまいます。
システムオブレコードとしての Salesforce は、お客様に関する完全なストーリー（対話履歴、サービスの嗜好、ロイヤルティ会員ランク、未解決のケース）を保持しています。システムオブエンゲージメントとしての Amazon Connect Customer は、リアルタイムの会話を担います。しかしながら、両者をつなぐ統合層の多くは依然としてトランザクション的なものにとどまっています。定型的な API 呼び出し、静的なデータ参照、そして情報を表示することはできても、その情報について推論したり、それに基づいてインテリジェントに行動したりはできない従来型のコネクタです。
こうしたやり方がもたらす弊害は小さくありません。新しいバックエンドシステムを一つ導入するだけでも、統合を一から作り直す必要があります。ワークフローを少し変えるにも、数か月の開発を要します。その結果、お客様に提供される体験（カスタマーエクスペリエンス）は、断片的でぎこちないものになってしまいます。課題を解決するために必要なデータが、すでに社内の各システムにそろっているにもかかわらず、です。
エージェンティックな統合は、複雑な問題解決のロジックを、あらかじめコード化された判断経路から、動的で AI エージェント主導のオーケストレーションへと移行させます。
Amazon Connect Customer は、AI エージェントをお客様との対話におけるアーキテクチャの中心に、すなわち主たる推論エンジンとして配置します。この AI エージェントは計画を立案し、結果を評価し、到達可能なあらゆるシステムをまたいでオーケストレーションを行います。そこには、以下のようなアーキテクチャ上の違いがあります
フロー主導の統合は決定論的（deterministic）です。各 API 呼び出しはあらかじめコード化されています。あらかじめ定められた経路(主たる経路)が失敗すると、システムは処理を終了するか、エスカレーションします。コンテキストはステップごとにリセットされます。
AI エージェント主導のオーケストレーションは適応的（adaptive）です。AI エージェントは意図を評価し、ツールを選択し、アクションを動的に連鎖させます。最初のアプローチが失敗しても、お客様に中断を感じさせることなく、代替手段を推論します。Salesforce、予約システム、ナレッジベース──これらはすべて、単一の会話コンテキストの中でコンポーザブルなツールとなります。
従来の API ベースの統合が時代遅れになったわけではありません。推論が不要で、入出力が固定的な高頻度の処理においては、依然として正しい選択肢です。しかし、複雑で文脈に依存するお客様との対話においては、エージェンティックなオーケストレーションが、その土台となる考え方そのものを塗り替えます。すなわち、「インフラ（基盤）としての統合」から「インテリジェンス（知性）としての統合」へ、という転換です。
推論のアーキテクチャ：理解・推論・実行・記憶
図: エージェンティックな推論ループ。相互に接続された 4 つの段階を示す：Understand（理解：意図の解析とコンテキストの読み込み）、Reason（推論：ゴールの分解とツールの選択）、Act（実行：MCP のツール呼び出しの実行と結果の評価）、Remember（記憶：状態の維持とパターンの保持）。矢印は、1 回の会話ターンの中で継続的に反復が行われることを示す。
Amazon Connect Customer の AI エージェントを従来の自動化と分けるのは、その推論アーキテクチャです。それは、あらゆる会話のターンの中で反復的に実行される、相互に依存し合う 4 つの機能から成る連続的なループです。
Understand（理解）── お客様の発話を解析し、意図（インテント）を特定し、エンティティを抽出したうえで、Salesforce のケース履歴、顧客プロファイルの属性、過去の対話記録を含む会話コンテキスト全体を読み込みます。
Reason（推論）── リクエストをサブゴールに分解し、どのツールが必要かを見極め、実行する順序を決め、どのツールの結果が別のツールの前提になるか（依存関係）を特定します。
Act（実行）── バックエンドシステムに対して MCP のツール呼び出しを実行します。各アクションは構造化された結果を返し、AI エージェントはその結果について推論したうえで次のアクションを決定します。実行は「投げっぱなし（fire-and-forget）」ではなく、「評価しながら適応する（evaluate-and-adapt）」方式です。
Remember（記憶）── 会話の状態を完全に維持し、セッションのコンテキストを保持し、問題解決のパターンを記憶します。
ここで一番大切なのは、このループが「逐次的（sequential）」ではなく「連続的（continuous）」である、という点です。1 回のターンの中で、AI エージェントは「推論・実行・推論・実行」を何度も繰り返すことがあります。Salesforce に問い合わせ、空き状況を確認し、ケースを作成し、レコードを更新し、確認通知を送信する ── これらすべてを、AI エージェントが一貫して指揮する、ひと続きの流れとして実行します。
相乗の原則：統合の乗数効果
図: 乗数効果──システムを 1 つ追加するごとに問題解決力が高まる。段階的な能力の向上を示す積み上げ図：1 システムで「情報提供」、2 システムで「パーソナライズ」、3 システムで「自律的なアクション」、4 システム以上で「ドメインをまたいだエンドツーエンドの問題解決」が可能になる。
エージェンティックなシステムを特徴づけるアーキテクチャ上のインサイトは、次のとおりです。すなわち、あらゆる AI エージェントの自律的な問題解決能力は、その AI エージェントがオーケストレーションできるシステムの「幅広さ」によって大きく決まる、ということです。
これが「乗数効果」です。統合するシステムが 1 つ増えることは、単に機能が 1 つ増えるだけにとどまりません。それは、これまでアーキテクチャ上できなかった「組み合わせによる新たな可能性」を生み出します。システムが 1 つなら、AI エージェントが使えるツールも 1 つだけです。しかしシステムが 3 つになれば、そのときどきの状況（リアルタイムのコンテキスト）に応じて、必要なツールを好きな順番で、条件に合わせて組み合わせながら次々に呼び出せます。こうしてできるアクションの組み合わせのパターンは、システムを 1 つ繋ぐごとに大きく増えていきます。
これは、最もシンプルな形で表れた「相乗的に高まる能力（compounding capability）」です。接続するシステムはどれもが、すでに接続されているすべてのシステムの問題解決力を掛け算のように増幅させます。航空便の運航トラブルのシナリオを考えてみましょう。
- システムなし（ゼロ）: 「お客様の便は欠航となりました。当社ウェブサイトをご確認ください。」
- 1 システム（ナレッジベース）: 「お客様は 72 時間以内の再予約が可能です。」
- 2 システム（+ Salesforce CRM）: 「ゴールド会員のお客様ですので、再予約は無料で、優先搭乗もご利用いただけます。」
- 3 システム（+ 予約システム）: 「14:00 発の SL-404 便、座席 12A に再予約いたしました。確認通知をお送りしました。」
- 4 システム以上（+ 地上交通手配）: 「18:00 にマンハッタンでのお打ち合わせがございますね。ニューアーク空港着の便を予約し、お荷物の経路を変更し、お打ち合わせ先までのお車を手配いたしました。」
「アドバイザー（助言者）」から「自律型 AI エージェント」への進化は、統合アーキテクチャと、それが生み出す乗数効果によって決まります。それぞれの層が、他の層の価値を掛け算のように高めていきます。
プロトコル層：Model Context Protocol
図: MCP のランタイムシーケンス──単一のツール呼び出しが、AI エージェントから AgentCore Gateway を経由して Salesforce へと流れ、再び戻ってくる。認証とプロトコル変換は、意識させることなく（透過的に）処理される。
組み合わせ自在なエージェンティック統合を、実際に使えるものにするアーキテクチャ上の構成要素が、Model Context Protocol（MCP）です。MCP は、誰でも自由に使える共通の仕様（オープン標準）で、AI エージェントが外部システムのさまざまな機能を見つけ出し、接続し、呼び出すための統一されたインターフェースを定めています。
MCP は、個別に作り込む統合（bespoke integration）を、たった一つの原則に置き換えます。すなわち、「コネクタは一度作れば、MCP に対応したどの AI エージェントも、それをすぐに見つけて呼び出せる」という原則です。AI エージェントは MCP サーバーに問い合わせて、そのサーバーが提供する機能の一覧（利用できるツール、必要な入力の形式、返ってくる出力の形）を受け取り、必要に応じてそれらを呼び出します。多くの実装では、これによって AI エージェントとバックエンドシステムをつなぐための専用コードや、個別に埋め込んだ接続設定が不要になります。
例えるなら、MCP は、対応するどの AI エージェントも、対応するどのシステムにも、標準化されたインターフェースを通じて接続できる汎用プロトコルを提供します。これは、ハードウェアの世界における汎用コネクタによく似ています。
リファレンスアーキテクチャ：エージェンティックなオーケストレーション
図: 全体アーキテクチャの概要。中心に Amazon Connect Customer と AI エージェント（オーケストレーター）を配置。上方向には LLM による推論のために Amazon Bedrock、外側には AgentCore Gateway を経由して外部の MCP サーバー（Salesforce ほか）に接続。左側には内部ツール（ナレッジベース、フローモジュール、Note Taker）、そして Amazon CloudWatch がすべての層にわたってオブザーバビリティ（可観測性）を提供する。
エージェンティックな統合をエンタープライズ規模で実現するには、以下のアーキテクチャ構成要素が必要であり、これらはすべて AWS クラウド内で動作します。図は、これらの構成要素が統一されたオーケストレーションアーキテクチャの中でどのように連携するかを示しています。
Amazon Connect Customer(システムオブエンゲージメント) ── 音声・チャット・メッセージングにまたがってお客様との対話を担う、会話型 AI サービスです。AI エージェントを支える以下の機能を提供します。ルーティングとチャネル管理を担うコンタクトフロー、本人確認とコンテキストのための Amazon Connect Customer Profiles、段階的な問題解決手順を導く Step-by-step Guides、そして対話からのインサイトを得るための 会話分析(Conversational Analytics) です。
AI Agent with Guardrails(ガードレール付きの AI エージェント) ── オーケストレーターであり推論エンジンでもあるこのエージェントは、Amazon Connect Customer の中心に位置し、安全性・コンプライアンス・ポリシーの境界を守らせるガードレールに囲まれています。エージェントは「理解・推論・実行・記憶」のサイクルを継続的に回し、お客様の課題を自律的に解決します。
Internal Tools(内部ツール) ── AI エージェントが直接呼び出す、Amazon Connect Customer ネイティブのツール群です。これには、Retrieval Augmented Generation（RAG）を用いてポリシーや製品情報を検索するナレッジベース、あらかじめ定義したアクションを起動する フローモジュール、そして対話の要約を生成する Note Taker が含まれます。
Amazon Bedrock（基盤モデル）── AI エージェントを支える推論エンジンであり、Amazon Connect Customer の外部、ただし AWS クラウド内に位置します。意図の理解、計画立案、応答生成を駆動する LLM 機能を提供します。
Amazon Bedrock AgentCore Gateway ── AI エージェントのツール呼び出しを外部の MCP サーバーへとルーティングする、セキュアな接続レイヤーです。OAuth 2.0 による認証、ポリシーの適用、プロトコル変換を担います。これにより、AI エージェントは個別に作り込む統合なしに、あらゆる MCP 準拠システムへ到達できます。
External MCP Servers(外部 MCP サーバー) ── 主たるシステムオブレコードとの接続を担う Salesforce MCP サーバー（ケースの作成、顧客情報の照会、レコードの更新）に加え、他の外部システム向けに任意の数の MCP サーバーを追加できます。AI エージェントはすべての MCP サーバーを同一に扱います。すなわち、発見可能で、呼び出し可能で、コンポーザブルなものとして扱います。
Amazon CloudWatch(オブザーバビリティ) ── すべての層（Amazon Connect Customer、Amazon Bedrock、AgentCore Gateway）にわたってロギング、メトリクス、モニタリングを提供し、エージェンティックなシステムの運用状況を可視化します。各構成要素は、MCP のプロトコル境界によって疎結合となっており、それぞれ独立して進化していきます。
収束点：Amazon Connect Customer と Salesforce の MCP 連携
業界はいま、それぞれ独立して成熟してきた 3 つの能力が一つに合わさろうとしている、まさにその局面にあります。すなわち、連続的に推論し続ける仕組みを備えた AI エージェント、あらゆるシステムを自由に組み合わせられるようにするオープンプロトコル（MCP）、そして AI エージェントを対話の設計上の中心に置くサービス群です。
MCP を通じた Amazon Connect Customer と Salesforce の連携は、この収束をいち早く形にした実装例です。システムオブエンゲージメントが、標準化され組み合わせ自在なプロトコル層を通じて、システムオブレコードに接続します。
動作の仕組み
Salesforce は、ホスト型の MCP サーバーを通じて自らの機能を公開します。これは、MCP プロトコルを Salesforce ネイティブの操作へと変換する、ベンダー（Salesforce）自身が構築したインターフェースです。Amazon Connect Customer の AI エージェントは、OAuth 2.0 による認証とアクセスポリシーの適用を担う Amazon Bedrock AgentCore Gateway を通じて接続します。
実行時（ランタイム）には、AI エージェントが MCP のツール呼び出しを発行します。AgentCore が OAuth で認証を行い、リクエストを転送します。Salesforce MCP サーバーはそれを適切な Salesforce API 操作へと変換します。構造化された結果は同じ経路をたどって返され、AI エージェントはその結果について推論したうえで、次のアクションを決定します。
AI エージェントにできること
Salesforce MCP サーバーを通じて、AI エージェントは Salesforce の各種操作をコンポーザブルなツールとして利用できるようになります。エージェントは、本人確認やコンテキスト把握のために、Contact（取引先責任者）・Account（取引先）・カスタムオブジェクトを照会し、顧客履歴・嗜好・利用権限（entitlements）を取得できます。会話の流れの中でケースを作成・更新・エスカレーション・クローズし、ケースのライフサイクル全体を管理します。また、公開されている任意の Salesforce オブジェクトに対して、リアルタイムで読み取り・作成・更新・照会といったレコード操作を実行します。さらに、対話の要約、解決に関するメモ、フォローアップタスクを Salesforce に書き戻すことで、アクティビティのログ記録も行います。
なぜこれがアーキテクチャ上において重要なのか
Runtime discovery(ランタイムでの発見) ── AI エージェントは Salesforce の機能を実行時に発見します。Salesforce が MCP サーバーに新しいツールを追加した際も、オーケストレーション層のコードを変更することなく、AI エージェントはそれらを利用できます。
Bidirectional context flow(双方向のコンテキストフロー) ── AI エージェントは推論に役立てるために Salesforce から情報を読み取り、実行したアクションを記録するために書き戻します。システムオブレコードは、手作業でのデータ入力なしに、常に最新の状態に保たれます。
Composable with other systems(他システムとのコンポーザビリティ) ── 同じ MCP のパターンは、準拠したあらゆるシステムへと拡張できます。AI エージェントは、Salesforce、予約システム、内部ツールを、まったく同一の仕組みでオーケストレーションします。
Decoupled evolution(疎結合な進化) ── Salesforce の組織側の変更は MCP サーバーに反映され、AI エージェント、コンタクトフロー、ゲートウェイの設定を変更する必要はありません。
MCP を通じて連携する Amazon Connect Customer と Salesforce は、一つの成果を生み出します。すなわち、システムオブレコードの持つ情報の深さを余すことなく活用しながら、お客様の課題をエンドツーエンドで自律的に解決するシステムオブエンゲージメントです。
統合はもはや単なるインフラではありません。それは、AI エージェントが「アドバイザー」として機能するのか、それとも「自律的な問題解決エンジン」として機能するのかを決定づける、戦力を倍増させる要因（フォースマルチプライヤー）なのです。
インパクトのモデル：ビジネス、体験、そして戦略的な意味合い
ビジネスへのインパクト
システムオブエンゲージメントが、システムオブレコードをまたいでリアルタイムに、自律的なオーケストレーションを行うようになると、カスタマーサービスにかかるコスト構造そのものが変わります。従来は何度も転送を重ね、オペレーターが数分がかりで対応していた複雑で多段階のリクエストも、自動化されたオーケストレーションによってより速く解決できるようになります。転送や折り返し（コールバック）なしに、システムをまたいで必要な処理を次々につなげて実行できるため、1次解決率（FCR）が高まります。人へのエスカレーションは、本当に人の判断が必要なケースだけに絞り込まれていきます。
カスタマーエクスペリエンスへのインパクト
お客様は、ストレスや手間が仕組みとして取り除かれていることを実感します。転送されることもなく、本人確認を何度も求められることもなく、保留で待たされることもありません。AI エージェントが顧客記録のすべてを活用するため、あらゆる対応がその文脈に合わせてパーソナライズされます。これは、その場限りの「取引的（トランザクショナル）」な関係から、継続的な「関係性重視（リレーショナル）」な関係への転換です。
リーダーにとっての戦略的な意味合い
この領域における差別化要因は、コモディティ化しつつあるモデルそのものの能力ではありません。それは、統合アーキテクチャの「広さ」と「コンポーザビリティ（組み合わせやすさ）」です。統合の広さこそが、AI 戦略における重要な差別化要因なのです。
リーダーは、フロー（flows）ではなくオーケストレーションを前提とした設計を行うべきです。重要なのは、発見可能で、呼び出し可能で、コンポーザブルなシステムを構築することです。着目すべき指標も変わります。すなわち、（有人対応をどれだけ回避できたかを示す）ディフレクション率を測るのではなく、AI エージェントがどれだけ多くの複雑な課題を、エンドツーエンドで自律的に解決したかを測るべきです。
顧客関係管理（CRM）は、最初に統合すべき自然な対象です。その基盤を起点に、外へと広げていきます。新たな接続はどれもが、それ以前の接続を相乗的に高めていきます。Amazon Connect Customer が AI オーケストレーション層として自然な選択肢となるのは、それがリアルタイムの顧客との関係を担い、推論エンジンをネイティブに組み込み、AgentCore Gateway を通じた MCP によってあらゆるシステムに接続できるからです。
はじめよう：エージェンティック統合ワークショップ
本記事で解説したアーキテクチャを実装いただけるよう、参加者がエンドツーエンドのエージェンティックな問題解決システムを構成・接続・テストするハンズオン形式の「Agentic Integration Workshop（エージェンティック統合ワークショップ）」をご用意しています。
注意：本ワークショップにはクリーンアップ（後片付け）の手順が含まれています。プロビジョニングしたリソースを削除し、継続的な課金を避けるために、クリーンアップの手順に従ってください。
まとめ
本記事では、エージェンティックな統合のアーキテクチャ原則、推論ループ、そして Amazon Connect Customer と Salesforce が MCP を通じてどのように接続されるのかを考察しました。乗数効果が示すのは、AI エージェントに接続されるシステムが 1 つ増えるごとに、アーキテクチャ全体の問題解決能力が相乗的に高まるということです。これにより、統合は運用上のインフラから、戦略的なインテリジェンスへと変貌を遂げます。
本記事は、Amazon Connect Customer、Salesforce の MCP サーバー、Amazon Bedrock、そして Model Context Protocol を用いた、エージェンティックな統合のアーキテクチャパターンと戦略的な意味合いを考察したものとなっています。
著者について
Chintan Gandhi は、AWS の Amazon Connect Customer Integrations における Applied AI Leader です。お客様がエージェンティックなシステムを導入し、スケールさせることを支援しています。仕事以外では、家族と過ごす時間、チェスやクリケット、読書を楽しんでおり、ときにはアマチュア小説の執筆もしています。
この記事は Chintan Gandhi によって書かれた Integration as Intelligence: Amazon Connect Customer Integrates with Salesforce via MCP の日本語訳です。この記事はソリューションアーキテクトの梅田裕義が翻訳しました。