はじめに

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。今週も生成 AI に関する 1 週間のアップデートをお届けします。 8 月 18 日（火）から、5 年目を迎える「 AWS デジタル社会実現ツアー 」が全国 8 都市（北海道・新潟・静岡・愛知・広島・愛媛・福岡・宮城）を約 2 週間で巡ります。注目の AI エージェント技術をデモを交えて解説するセッションに加え、地域企業の AI/クラウド活用事例を当事者が語るパート、社会課題に挑んだ学生コンテスト入賞者のプレゼンテーション、自治体・地銀・大学・AWS パートナーによる産学官金パネルディスカッション、経済産業省「GENIAC PRIZE」の懸賞金企画の最新情報までを 1 日で体感できます。参加無料・事前登録制です。お近くの会場にてご参加ください。 それでは 8月 3日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「 2枚のピザを囲んで語る業務変革 — 35社62名が参加した大阪開催 Claude・Kiro実践ワークショップの記録 」 2026 年 7 月 2 日に AWS 大阪オフィスで開催された「Claude , Kiro実践ワークショップ」の開催報告です。参加者は 35 社 62 名、満足以上の回答率は 98% でした。参加企業の OSP ホールディングス様 IT 企画課 桒原様が 15 分間の事例登壇を行い、4 月のワークショップをきっかけに 3 ヶ月で 30 名規模の Kiro 利用体制を構築した過程を共有しています。メールアーカイブ作業が 514 時間から 3 時間、受注分析が 1 週間から 3 時間になった成果に加え、ワークショップ参加から社内勉強会、実務伴走へと段階的に広げた進め方も紹介されました。ツールを配るだけでは組織は変わらず、現場の担当者が推進役となることが業務変革につながる実例です。 ブログ記事「 dSPACE と AWS で実現する自動運転 AI 開発の効率化 ～MLOps によるデータ駆動型開発の実践～ 」 dSPACE Japan 様とアマゾン ウェブ サービス ジャパン合同会社の共同執筆記事です。自動運転 AI 開発には、1 時間あたり 1 テラバイトを超えるカメラデータやセンサーデータの管理、クラウドで学習したモデルと実車両環境での挙動の乖離、再現性・説明責任の確保といった課題があります。記事では dSPACE 製品と AWS サービスを統合した MLOps アーキテクチャを解説しています。RTMaps でデータを収集し、 dSPACE IVS（Intempora Validation Suite） で自動タグ付けやデータセット定義の証跡管理を行い、Amazon SageMaker AI で学習、SIL/HIL での検証結果をデータ準備フェーズへ戻す構成です。Kiro でスクリプト生成や品質チェックを自動化する例も示されています。 ブログ記事「 フロンティア AI による脅威変化への備え – 金融庁・日本銀行から金融機関等への要請と AWS サービスの活用 」 2026 年 5 月 22 日に金融庁と日本銀行が公表した「フロンティア AI による脅威変化を踏まえた金融機関等の短期的な対応」に係る要請について、9 つの短期的対応それぞれに AWS のサービスがどう役立つかを整理した記事です。要請は経営層の直接関与の下で取り組むことを求めています。2025 年に公開された CVE（共通脆弱性識別子）は 48,185 件（前年比約 20% 増）で、Anthropic の Project Glasswing では約 50 のパートナー組織が約 1 か月で深刻度 High または Critical の脆弱性を 1 万件超発見したことも挙げられています。資産の把握、EPSS や CISA のカタログを加味した優先順位付け、パッチ自動化などを要請項目に対応づけた早見表が、自組織の点検の出発点になります。 ブログ記事「 どの AI ツールをどの FinOps ユースケースに使うか？ 」 FinOps プラクティショナーが使える 5 つの AI ツール——AWS FinOps Agent、Amazon Quick、Kiro、Amazon Q（in Console）、AWS DevOps Agent——の目的といつ使うべきかを整理した翻訳記事です。AWS FinOps Agent（パブリックプレビュー）は Cost Optimization Hub などとネイティブに連携し、コスト異常の原因調査からチケット作成、定期レポート生成までを担います。Amazon Quick は MCP（Model Context Protocol）経由で会話形式にコストを扱い、Kiro は構築時点で高価な構成にフラグを立てるシフトレフトを支援します。6 ペルソナ × 5 ツールのグリッドに具体的なサンプルプロンプトが載っており、自分の役割の行を読むだけで適用先が見つかります。 ブログ記事「 AI Agent は “つながり” で進化する ─ Amazon Connect Customer × Salesforce MCP 連携 」 Amazon Connect Customer と Salesforce を Model Context Protocol（MCP）で接続する「エージェンティックな統合」の設計原則を解説する翻訳記事です。判断パターンをコンタクトフローに作り込む代わりに、LLM を基盤とするオーケストレーター AI エージェントが呼び出すシステムと順番をその場で判断します。中核は Understand・Reason・Act・Remember の 4 機能から成る推論ループです。航空便の欠航シナリオでは、ナレッジベース、CRM、予約システムとつなぐ先が増えるごとに応対が具体化する「乗数効果」が示されます。Amazon Bedrock と AgentCore Gateway を中心とした構成で、固定的な高頻度処理には従来の API 統合が適するという切り分けも示されています。 ブログ記事「 ランタイムインスタンス: Amazon Bedrock AgentCore 上の本番環境の AI エージェント用のパーシステントコンピューティング 」 Amazon Bedrock AgentCore Runtime の新しい補完的なコンピューティングオプション「ランタイムインスタンス」を紹介する翻訳記事です。既存の microVM は最大 8 時間の呼び出し環境を提供しますが、複数日間継続して稼働させたい場合や GPU・OS へのアクセス、同じホスト上での複数エージェントの連携が必要な場合には専用の大容量環境が向いています。エージェントは最大 14 日間持続する共有セッション内で同じホストで共同作業でき、記事ではコードを生成するエージェントとレビューするエージェントが共有ファイルシステムを介して連携するデモが示されます。CrewAI や Strands などを持ち込め、パッケージは @app.entrypoint と zip またはコンテナイメージだけです。東京リージョンを含む米国・アジア太平洋・ヨーロッパのリージョンで提供されます。 ブログ記事「 エージェンティックエンタープライズを AWS for SAP MCP Server on Amazon Bedrock AgentCore で実現 」 Amazon Bedrock AgentCore 上での AWS for SAP MCP Server の一般提供開始を受けて、その仕組みと主要機能を解説する記事です。SAP が API を標準化するために使用している Open Data Protocol（OData）を基盤に、SAP ERP のビジネスデータとプロセスをファーストクラスの MCP ツールへ変換します。現在のリリースは OData V2 をサポートし、AWS はコンテナイメージとして無償で提供、AgentCore Runtime にデプロイすればセッションの分離やプライベート接続、AgentCore Identity による認可が任せられます。カタログ検出はリモートとローカルの 2 モードから選べ、SAP BTP API Management 経由や AWS 上の SAP といった複数のトポロジーに対応します。デプロイは AWS CloudFormation で自動化できます。 ブログ記事「 1 つのエージェントで、あらゆるクライアントに: Kiro エージェントハーネスをどう構築したか 」 Kiro IDE、CLI、Web でそれぞれ別々に開発されていた 3 つのエージェントハーネスを 1 つに統合した過程と設計判断を解説する翻訳記事です。当初は IDE は TypeScript、CLI は Rust、Web は Python で個別に構築していたため、権限の構文やコンパクション戦略が分岐し、新機能は 3 回作って 3 回保守する必要がありました。重要な判断は、ハーネスをライブラリではなく独立したサーバープロセスとして構築したことです。境界には Agent Client Protocol（ACP）を採用し、Kiro 固有の機能は「Kiro-ACP」として拡張しています。権限はポリシー言語 Cedar に支えられたケイパビリティベースのモデルに統一され、仕様駆動開発は CLI や Web でも動くようになりました。 ブログ記事「 Kiro Crew の紹介 」 セッションをまたいで作業を進めるエージェントワークスペース Kiro Crew のオープンソース公開を紹介する翻訳記事です。実際の業務はリポジトリやツール、何日もの時間にまたがるのに、それらをつなぐのは結局人間であり席を離れれば作業が止まる、という課題から始まったプロジェクトです。Amazon 社内の MeshClaw が出発点で、6 か月足らずで 39,000 人を超えるビルダーに採用されました。OS レベルのサンドボックス、デフォルト拒否のコマンド制御、署名付き監査ログなどの多層防御を初日から備え、計画から並列サブエージェントの起動、承認ゲートまでを Activity ビューで追えます。定期ジョブやハートビートで不在時も作業が進み、既存の .kiro 設定をそのまま読み込みます。 ブログ記事「 Kiro の powers が Agent Plugins に対応 」 Kiro の powers が、エージェント拡張のパッケージ化に関するオープンでベンダーニュートラルな仕様「Agent Plugins 1.0.0」に対応しました。AWS は Cursor、Microsoft、OpenAI、Vercel と並ぶ Technical Steering Committee の創設メンバーで、この標準に沿って公開されたプラグインは Kiro では power としてインストールできます。従来は作者が利用者のクライアントごとに同じ知識を再パッケージする必要があり、開発者側では有用なプラグインが自分のツールで読み込めないという問題がありました。今回の変更で power はスキルを第一級の構成要素として扱えるようになり、 skills/ 配下に SKILL.md や scripts/ を持つ複数のスキルを含められます。既存の power も引き続き読み込まれます。 サービスアップデート Amazon Cognito が Agent Toolkit for AWS のスキルとして利用可能に Amazon Cognito が Agent Toolkit for AWS のコアスキル（ aws-auth ）として利用できるようになりました。このツールキットを使う AI コーディングエージェントが、ベストプラクティスに沿ったワークフローで Amazon Cognito のセットアップ、設定、セキュリティ確保、トラブルシューティングを行えるため、ユーザー・AI エージェント・マイクロサービス向けの安全なサインインフローをより速く実装できます。スキルはユーザープールとアプリクライアントの設定、マネージドログインと OAuth 2.0 フロー、トークン管理、JWT オーソライザー、パスキー / WebAuthn の登録、脅威保護、Lambda トリガーの接続、ID プールをカバーします。AWS MCP Server と組み合わせると、IAM ベースのガードレールと CloudTrail の監査ログ記録のもとで AWS CLI コマンドを実行します。 Amazon Bedrock AgentCore のTemporal policiesとレート制限が発表 Amazon Bedrock AgentCore に、ステートフルなエージェント認可のための Temporal policies と、AI トラフィック向けのレート制限という 2 つの新しいコントロールが追加されました。単一のツール呼び出しはそれ自体では安全でも、その前に何が起きたかを踏まえると有害になり得ます。Temporal policies はセッション内の過去のアクションという文脈で各リクエストを評価し、ワークフローの順序の強制、引数が先行する呼び出しの出力と一致することの要求、特権的なアクション前の人間による承認、データの鮮度の強制を可能にします。レート制限は OAuth または AWS IAM でスコープを絞ったルールで、リクエスト数、推論ターゲットのトークン数、同時接続数に上限をかけられます。 AgentCore ランタイムインスタンスが一般提供開始 Amazon Bedrock AgentCore の新機能であるランタイムインスタンスが一般提供されました。インフラストラクチャを管理せずに、自分の Amazon EC2 インスタンス上でエージェントを実行できます。既存の microVM ベースのオプションを補完するもので、プロビジョニング、パッチ適用、スケーリング、ライフサイクル管理は AgentCore が担います。コンソールや CLI、SDK、API から必要な EC2 インスタンスタイプを指定した容量プロバイダーを作成し、エージェントを紐付けます。最大 14 日間の長時間セッションに対応し、デフォルトの microVM ベースのランタイムは高速な起動を必要とする最大 8 時間のセッション向けです。東京リージョンを含む米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）、アジアパシフィック（ムンバイ、シンガポール、シドニー、東京）、欧州（フランクフルト、アイルランド）で利用できます。 Amazon Bedrock が OpenAI GPT モデル向けの Web Search を提供開始 Amazon Bedrock の Web Search が一般提供されました。AWS 内で完結して Web 検索を実行する組み込みのサーバーサイドツールで、OpenAI モデル（GPT-5.4、GPT-5.5、GPT-5.6 Sol / Terra / Luna）が最新の Web の知識で応答をグラウンディングでき、データはセキュアな AWS 環境内にとどまり外部へのデータ送信は発生しません。これまで必要だったサードパーティ検索プロバイダーのオンボーディングや API キー管理、独自のオーケストレーション構築が不要になり、既存の API 呼び出しにパラメータを 1 つ追加するだけで有効になります。Amazon 運用の Web インデックスとナレッジグラフを組み合わせ、セマンティックなスニペット抽出で引用付きの応答を返します。提供リージョンは米国東部（バージニア北部）、米国東部（オハイオ）、米国西部（オレゴン）です。 Amazon Bedrock AgentCore が AWS GovCloud (US-West) でメモリ、ポリシー、ハーネスを追加 Amazon Bedrock AgentCore が AWS GovCloud（US-West）で新しい機能を提供開始しました。規制のある環境で運用するチームが、コンテキストを認識するエージェントを構築し、組織全体へスケールさせるためのコントロールを備えた形でプロトタイプから本番環境へより速く進められます。AgentCore memory は、目前の会話コンテキストのための短期記憶と、セッションをまたいでインサイトや嗜好を抽出する長期記憶を与えます。Policy はエージェントのコードの外側で動作する集中管理されたコントロールで、自然言語で書いたポリシーが AWS のオープンソースポリシー言語 Cedar に自動変換され、gateway が各リクエストを評価します。マネージドハーネスは、モデル・ツール・指示を設定として宣言し、オーケストレーションのコードなしで実行できます。 AWS Transform の継続的モダナイゼーションが一般提供開始 AWS Transform の継続的モダナイゼーションが、AWS Transform がサポートされるすべての AWS リージョンで一般提供されました。エンジニアリングチームがソースコードリポジトリ全体の技術的負債を大規模に分析し、修正していくための機能です。GitHub の organization、GitLab の group、Bitbucket の workspace を接続し、オンデマンドまたは定期スケジュールで分析を実行して、技術的負債、セキュリティ、エージェント対応の準備状況、モダナイゼーションの準備状況、カスタム基準にまたがって検出結果に優先順位を付けられます。修正が紐付いた検出結果ではブランチを作成し、検証済みのコード変更を含むプルリクエストを作成します。分析と修正はお客様のアカウント内で実行され、ソースコードは管理下にとどまります。 OpenAI GPT-5.6 Sol、Terra、Luna が Amazon Bedrock で 100 万トークンのコンテキストウィンドウに対応 GPT-5.6 Sol、Terra、Luna が Amazon Bedrock で 100 万トークンのコンテキストウィンドウに対応しました。コードベース全体、長い文書、マルチターンのエージェント履歴を 1 回のリクエストで処理でき、チャンク分割や情報の欠落なしに、より広いコンテキストにわたって推論できます。コードレビューやマイグレーションのためのリポジトリ全体の分析、長文の法務・規制文書の処理、複数ステップのワークフローでの会話履歴の保持が挙げられています。明示的なキャッシュブレークポイントを使ったプロンプトキャッシュも適用されます。Sol は米国東部（バージニア北部、オハイオ）、Terra と Luna はこれに米国西部（オレゴン）を加えたリージョンで、 bedrock-mantle エンドポイントの Responses API から利用できます。 AWS Security Agent がペネトレーションテストでメールベースの MFA に対応 AWS Security Agent（現在は AWS Continuum の一部）が、ログインフローの一部としてメールベースの多要素認証（MFA）を使うアプリケーションのペネトレーションテストに対応しました。これまで、メールで送られるワンタイムコードや検証リンクを必要とするアプリケーションは、エージェントがそれらのメッセージを受け取る仕組みを持たないため自動ペンテストの対象外でした。この機能では認証情報ごとに一意の転送用アドレスが生成されるので、既存のメールプロバイダーの転送ルールで MFA メールをエージェントに直接ルーティングできます。エージェントは転送されたメッセージを自動的に読み取って認証を完了させ、メールアカウントの認証情報は保存されません。既存の TOTP サポートを補完し、サポートされているすべての AWS リージョンで利用できます。 Amazon SageMaker Studio ノートブックが G7 インスタンスタイプに対応 NVIDIA RTX PRO 4500 Blackwell Server Edition GPU を搭載した Amazon G7 インスタンスが、Amazon SageMaker Studio のノートブックで使えるようになりました。G7 インスタンスは前世代の G6 インスタンスと比べて最大 4.6 倍の AI 推論性能を発揮します。最大 8 基の GPU と 700 Gbps の EFA 対応ネットワーク帯域幅を備え、AI 推論、グラフィックス、データ分析のワークロードをより効率的に実行できます。カスタム Intel Xeon 6 プロセッサ、G6 の 7 倍の EFA 対応帯域幅、1.5 倍高い FP16 Flops により、会話型アシスタント、コンテンツ生成ツール、レコメンデーションエンジンといったアプリケーション向けに、より低いレイテンシーでモデルをデプロイできます。提供リージョンは米国東部（バージニア北部、オハイオ）と米国西部（オレゴン）です。 Amazon SageMaker AI のサーバーレスモデルカスタマイズがフルファインチューニングに対応 Amazon SageMaker AI のサーバーレスモデルカスタマイズが、25 を超えるオープンソースモデルのフルファインチューニングに対応しました。対象には gpt-oss、Gemma、Llama、Nemotron、Qwen といったモデルファミリーの人気モデルが含まれます。モデルの重みのごく一部だけを更新する LoRA のような手法に加えて、ユースケースが求める場合にはすべてのパラメータを更新して、より深く適応させられます。専門的な推論パターンの習得や複雑な出力フォーマットの採用、大規模な独自データセットからのドメイン知識の内在化といった能力を獲得させたい場合に特に有効です。インフラの用意や管理なしにジョブを実行でき、使った分だけの料金です。東京リージョンを含む米国東部（バージニア北部）、米国西部（オレゴン）、アジアパシフィック（東京）、欧州（アイルランド）で利用できます。 Kiro IDE 1.0.288 : Agent Plugin 対応とセッションのピン留め 2026 年 8 月 7 日にリリースされた Kiro IDE 1.0.288 では、オープンな Agent Plugin フォーマットで作られた powers に対応し、Agent Focus Mode のセッションレールが作り直されました。powers はローカルフォルダーまたは GitHub の URL からインストールでき、スキルと MCP をまとめたプラグインに対応するため、互換性のあるエージェントツール間で持ち運べます。Agent Focus Mode では「Pin Session」でセッションをそのセクションの先頭に固定でき、「Open with Kiro CLI」で既存のセッションを CLI で再開できます。あわせて Code OSS が v1.109.5 に更新され、仕様のホバー表示と MCP のインストールが信頼されていないワークスペースのコンテンツを扱う際の挙動が強化されました。 生成 AI の活用を検討されている企業の皆様に向けて、AWS ジャパンでは「 AWS ジャパン生成 AI 実用化推進プログラム 」をご用意しています。ぜひご活用ください。また次回の「生成 AI Frontier Meetup」が、2026 年 8 月 末に開催予定ですのでチェックしておいてください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近燻製づくりにハマってます。

統合されたアーキテクチャの「幅広さ」こそが、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（エージェンティック統合ワークショップ）」をご用意しています。 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 の日本語訳です。この記事はソリューションアーキテクトの梅田裕義が翻訳しました。