Amazon Web Services ブログ

AWS が Anthropic および OpenAI と協業し、AWS Continuum を開発者ワークフローに統合します

Hiroaki Matsuzaki — Mon, 10 Aug 2026 19:47:06 +0000

本ブログは 2026 年 8 月 5 日に公開された AWS Blog、”AWS partners with Anthropic and OpenAI to bring AWS Continuum into developer workflows” を翻訳したものです。

お客様は、世代を重ねるごとに改善され続けるモデルを利用できます。新しい世代のモデルは、より大きなコンテキストウィンドウ、より強力な推論能力、より低いトークンコストをもたらします。最も強力な AI によるセキュリティは、最も適切なモデルとお客様固有の環境に関する深い知識を組み合わせたツールから生まれます。

AWS Continuum for code vulnerabilities (プレビュー) は、マシンスピードでコードのセキュリティ保護を支援する、まさにそのためのツールとして構築されています。本日、AWS は Anthropic および OpenAI との協業を発表します。これにより、AWS Continuum は、コードが書かれる開発者ワークフローである Anthropic Claude Code、OpenAI Codex、Kiro に直接組み込まれます。開発者はこれらの統合を利用して、既存のワークフローの中で脆弱性の発見、コンテキストに基づく優先順位付け、検証、修復を行うことができます。

モデルは賢くなり続けている

AI モデルは急速に進化しています。世代ごとに新しい能力が加わり、モデルによって得意なタスクも異なります。最新のフロンティアモデルは、人間のセキュリティチームが手作業で追跡すると数週間かかるような多段階の攻撃経路を推論し、脆弱性を特定できるようになっています。

これは検出における真のブレークスルーですが、セキュリティチームには新たな課題をもたらします。検出結果は増え、複雑さも増し、自社の環境でどの問題が最も重要か、どう対処するかを判断する必要が生じます。お客様が直面する次の課題は、これらのモデルを検出から修復までをつなぐ単一のインターフェイスに変えるための、適切なハーネスとオーケストレーションを構築することです。これこそが、私たちが Continuum を作る際に目指したものです。Continuum は多様なモデルを組み合わせ、プロセスの各部分で最も効果的なモデルを使用します。

また、AWS は Frontier Model Forum とも連携しています。これは、共通の安全基準、評価手法、ベンチマークを開発する業界コンソーシアムであり、これらのモデルを共同で効果的に評価できるようにするものです。さらに、モデルプロバイダーとセキュリティ性能の共通ベンチマークにも取り組んでおり、Continuum やその他の AWS セキュリティ製品において、各タスクに最適なモデルを使用できるようにしています。

ハーネス

AI ハーネスとは、モデルを包み込み、ツール、ガードレール、メモリ、ワークフローに接続して成果を生み出すオーケストレーションレイヤーです。モデルをエンジン、ハーネスをその周囲のすべてと考えてください。高性能な車には、その両方が必要です。

ハーネスはますます複雑になっています。チームは複数のモデル、エージェントを呼び出すエージェント、動的なワークフローをつなぎ合わせており、モデル、エージェントフレームワーク、ツール統合の革新がもたらす絶え間ない変化に対応し続けています。

その複雑さの結果として、お客様はモデルとツールにまたがる統合レイヤーを管理するために、シャドーインフラストラクチャを構築しています。状況が変わるたびにセキュリティとガバナンスのコントロールが壊れる可能性があり、チームは見直しと更新を迫られます。

こうした課題はモデルだけにとどまりません。さまざまなモデルや開発環境を、お客様の環境全体にわたるツール、コンテキスト、コントロール、ワークフローと接続するために必要なオーケストレーションにおいても生じます。AWS は、この複雑さの管理を AWS が解決すべき重労働 (heavy lifting) と捉えています。私たちはハーネスをインフラストラクチャとして扱い、AWS のコアインフラストラクチャにおけるアイデンティティ、ディスカバリ、ポリシー適用、可観測性、コンプライアンスに適用しているのと同じ厳格さで取り組んでいます。

Continuum の登場

AWS Continuum for code vulnerabilities は、脆弱性を発見し、お客様のビジネスのコンテキストの中で優先順位を付け、サンドボックスで検証し、マシンスピードで修復を提供します。内部的には、Continuum はエージェントチームによるループアーキテクチャです。適切なモデルの選択、お客様環境への接続、コンテキストの中で検証されたセキュアなコードの提供、そのすべてをオーケストレーションする高度なハーネスです。オーケストレーションがどのように動いているか、最新リリースで何が変わったかを意識する必要はありません。

Anthropic および OpenAI との協業

AWS は Anthropic および OpenAI と協力し、コードが書かれる開発者ワークフローに Continuum を組み込もうとしています。

動作の仕組み:

Claude Code、Codex、Kiro のコーディング環境内で、オンデマンドの脆弱性スキャンが潜在的な問題を特定し、検出結果を Continuum に送信します。Continuum は、お客様の AWS 環境のコンテキスト (設定、AWS Identity and Access Management (IAM) ポリシー、ネットワークトポロジー、露出面) の中でそれらに優先順位を付け、サンドボックスで検証します。その後、優先順位付けされたコンテキスト付きのインテリジェンスをコーディングアシスタントに返し、コーディングアシスタントはそれに応じて提案を調整します。

これにより、従来は複数のステップと複数のチームにまたがっていたプロセス (記述、スキャン、トリアージ、優先順位付け、修正、再スキャン) が、コード提案そのものという単一の成果に集約されます。2 つのモード、1 つの成果:

既存のコードの場合: AWS の Continuum for code vulnerabilities を使用して、環境全体で脆弱性の発見、優先順位付け、検証、修復を行います。
新規のコードの場合: Codex、Claude Code、または Kiro 内の Continuum プラグインを使用して、開発環境でセキュリティ検証済みの提案を受け取ります。

初期のデザインパートナーは、すでに成果を実感しています。

「AWS Continuum はソースコードとエンタープライズナレッジを結び付け、チームがセキュリティ脆弱性を正確に特定し、指摘された問題が本当に意味のあるものかを確認できるようにします。これにより、本当に重要なこと、つまり深刻な脆弱性を修正するまでの時間が短縮されます。」 – Mike Johnson 氏、CISO、Rivian

次のステップ

AWS Continuum for code vulnerabilities は、AWS を通じてプレビューで利用できます。AWS Continuum からサインアップしてアクセスをリクエストしてください。
Claude Code、Codex、Kiro のワークフローへの Continuum の統合は近日提供予定です。

本記事に関するフィードバックがある場合は、以下のコメントセクションからコメントを送信してください。

著者について

翻訳は Security Solutions Architect の松崎博昭が担当しました。

AWS が Agent Plugins をサポート: ポータブルなエージェント拡張のためのオープン標準

吉村弘明 — Mon, 10 Aug 2026 12:31:46 +0000

本記事は 2026 年 8 月 6 日に公開された Libby Clark、James Ward による “AWS Supports Agent Plugins: An Open Standard for Portable Agent Extensions” を翻訳したものです。

MCP サーバーやエージェントスキルを構築したことがある方なら、それをパッケージ化するには 1 つのクライアント向けに調整し、別のクライアント向けに書き直し、チームで使うツールごとにその作業を繰り返すことになるとご存知でしょう。Agent Plugins 1.0.0 は、AI エージェントの拡張機能に共通のパッケージ形式を提供するオープンソースかつベンダーニュートラルな仕様です。拡張機能を 1 度パッケージ化すれば、Kiro、VS Code、Cursor など、この仕様を実装した任意のクライアントに配布できます。

AWS は、Cursor、Microsoft、OpenAI、Vercel と並ぶ Agent Plugins Technical Steering Committee の設立メンバーであり、エージェント間でスキルや MCP のパッケージングにポータビリティをもたらすこの標準を支持できることを嬉しく思います。すでに AWS Agent Toolkit を対応させており、Kiro でも Agent Plugins 仕様のサポートを順次展開しています。

拡張機能とは、スキル、MCP サーバー、フック、サブエージェントのように、AI エージェントに新たな能力を与えたり、外部ツールやデータへ接続したり、エージェントに代わってタスクを自動化したりする再利用可能なコンポーネントのことです。Agent Plugins の初版では、現在最も採用が進んでいる 2 つのコンポーネントタイプ、Agent Skills と MCP サーバーを標準化しています。フックやカスタムエージェントといった追加の拡張機能タイプは、将来のバージョンに向けたロードマップに含まれています。

モデル選択が、どの AI を使うかについての柔軟性を開発者に与えるのに対して、Agent Plugins は、その選択を特定のクライアントやプロバイダーに縛られることなく、AI がどのツールを使うかについての柔軟性を与えます。

エージェント型 AI にとってオープン標準が重要な理由

これまで、エージェント拡張の管理は、パッケージマネージャー登場前のライブラリ配布や、標準的なコンテナ形式が確立する前のアプリケーション配布に少し似ていました。JavaScript が package.json という共通の形式に落ち着いたことで、npm、yarn、pnpm のいずれからも同じパッケージをインストールできるようになり、手作業でのスクリプトダウンロードやコピー&ペーストによる依存関係管理は終焉を迎えました。同様に、OCI がベンダーニュートラルな形式をコンテナイメージにもたらしたことで、1 度ビルドしたイメージが Docker、containerd、Podman、あるいは仕様に準拠した任意のランタイムで実行できるようになり、Docker 独自のイメージ仕様を置き換えました。オープン標準は、その上に築ける共通の土台を全員に提供します。

AWS は、オープンソースとオープン標準による構築こそが AI アーキテクチャの柔軟性と相互運用性を保つと考えています。オープン標準は、開発者に自らの条件でワークロードを組み合わせ、拡張し、移行する自由を与えます。私たちが Model Context Protocol (MCP)、Agent Client Protocol (ACP)、x402、そして Agent Plugins のような標準に投資しているのは、モデル、ツール、クライアントに至るまで、皆さんが選んだいかなる決定も特定のベンダーに縛られないようにするためです。

Agent Plugins とは

Agent Plugins は、ツール間で容易に共有・バージョン管理・インストールできるように、エージェント拡張をどうパッケージ化するかを定義します。内部的には、プラグインはディレクトリであり、その中にプラグインの識別情報とエントリーポイントを宣言する JSON マニフェストと、コンポーネントの固定配置場所を持ちます。互換性のあるクライアントは、ディレクトリ構造をスキャンして内部に何があるかを検出します。skills/ フォルダーがあればスキルを読み込み、MCP 設定があればそれらのサーバーに接続します。

フォーマットは意図的に小さく保たれています。バージョン 1.0.0 では、Agent Skills (エージェント向けの再利用可能な指示およびリソース) と MCP サーバー (外部ツールやデータへの接続) を標準化しています。クライアントがプラグインをどのようにインストール、表示、配布するかは、意図的に仕様の対象外としています。これらは、共通のフォーマットを共有しつつ、クライアントが差別化できる領域だからです。

これは正しい設計思想です。共有フォーマットは、相互運用に不可欠なコンポーネントを定義したうえで、それ以上のことには介入しないべきです。拡張機能の作者は 1 度パッケージ化するだけで、互換性のあるクライアントが同じ構造からコンポーネントを検出して読み込みます。クライアントは、名前空間で分離した拡張機能によってプロプライエタリな機能を追加する自由を保ちつつ、ポータブルなコアを煩雑にしないでいられます。

Agent Plugins はコミュニティによる取り組み

Agent Plugins は、エージェント向けツールを構築するあらゆるチームが独立して直面してきた実務的な課題から生まれました。拡張機能の作者は同じコンポーネントを異なるクライアント向けに調整する冗長な作業を強いられ、開発者は互換性のないパッケージング慣習を渡り歩くことで時間を失っていました。

Vercel が仕様の初期ドラフトを公開し、その後、それぞれのやり方でこの問題を解決してきた各社のチームからなるワーキンググループを結成しました。AWS、Cursor、Microsoft、OpenAI、Vercel の代表者たちは、日々開発者が使うエージェントクライアントを構築してきた自らの経験を持ち寄って、共同で仕様を洗練させました。このグループは、1 社のプロダクトロードマップがフォーマットの方向性を左右することがないようにするガバナンス構造を確立しました。

その結果として得られたのは、拡張機能の作者とクライアント実装者の両方の視点が場に揃っていたからこそ実現できた、両者の実際のニーズを反映した仕様です。Technical Steering Committee には設立 5 社すべてからコアメンテナーが参加しており、プロジェクトのコントリビューションプロセスと技術的な意思決定は完全に公開されています。

これこそが、最良の標準が生まれるあり方です。1 社のビジョンをエコシステムに押し付けるのではなく、共有された課題を各社が共に解決していく中での収束から生まれるのです。ツール連携における MCP、可観測性における OpenTelemetry、そしてそれ以前のコンテナ標準でも、私たちは同じパターンを目の当たりにしてきました。

AWS による Agent Plugins のサポート

私たちは、開発者が AWS 上で AI エージェントを構築・拡張する 2 つの主要なオファリングである Kiro と AWS Agent Toolkit の両方で、Agent Plugins のサポートをローンチと同時に提供します。

Kiro は、開発ライフサイクル全体を通じてエージェントを開発者の意図に沿わせ続けるための spec、フック、自動テストといったステアリング機構を備えたエージェントハーネスです。今回のローンチにより、インストール可能なパッケージによって Kiro を拡張する Kiro Powers が Agent Plugins 仕様をネイティブにサポートするようになりました。開発者は、Skills と MCP サーバーをまとめてバンドルしたプラグインをインストールでき、それぞれのコンポーネントを手動で構成することなく、シームレスに動作する機能を利用できます。

AWS Agent Toolkit は、AI コーディングエージェントが AWS 上で信頼性高く構築できるようにする、公式にサポートされた MCP サーバー、スキル、エージェントプラグインのコレクションです。これらは複数のパッケージング形式で提供され、Lambda、S3、DynamoDB、CDK などのサービスをカバーする 30 以上の厳選されたスキルを、複数のプラグインとしてバンドルしています。新しい Agent Plugins 仕様をサポートすることで、異なるハーネスやコード支援ツールが同じパッケージング形式を利用できるようになり、AWS Agent Toolkit のようなエージェント拡張のパッケージをエージェントがどのように取り込むかに関するフラグメンテーションが最終的に減少します。

今後の展望

Agent Plugins 1.0.0 は出発点です。仕様は、ポータビリティの恩恵を受ける追加のコンポーネントタイプをエコシステムが見出すにつれて進化していきます。Technical Steering Committee では、フック、サブエージェント、その他の拡張機能タイプが将来のバージョンでどのように Plugins に加わりうるかについて、すでに検討が始まっています。

私たちがこの取り組みに真剣に向き合っているのは、オープン標準が開発者の生産性にもたらす効果を見てきたからです。オープン標準は、優れたツールがそれを必要とする人々の手元に届くのを妨げている摩擦を取り除きます。今日、その対象はエージェント拡張ですが、エージェント型 AI エコシステムが進化を続けるにつれて、さらに多くの標準が生まれてくると私たちは考えています。

仕様の詳細は agent-plugins.org でご確認いただけます。GitHub リポジトリを確認したり、Kiro で最初のプラグインをインストールしたりしてみてください。

著者について

翻訳は Solutions Architect の吉村が担当いたしました。

AWS DevOps Agent と Kiro CLI によるインシデント修正の自動化

Mizuki Ugajin (syobochim) — Mon, 10 Aug 2026 07:58:43 +0000

本記事は 2026 年 7 月 14 日に公開された Jishnu Dasgupta と Chetan Dharma の “Automated Incident Remediation with AWS DevOps Agent and Kiro CLI” を翻訳したものです。

はじめに

インシデント修正の自動化、つまり調査結果を人手をかけずにデプロイ済みの修正へとつなげることは、AWS 上で分散ワークロードを運用するオペレーションチームにとって次の課題です。現在、インシデントが深夜 2 時に発生すると、オンコール担当のエンジニアは Amazon CloudWatch、デプロイパイプライン、アプリケーションログをまたいでテレメトリを突き合わせ、その後手動で修正を書いてデプロイする必要があります。これには通常数時間かかります。AWS DevOps Agent は、インシデントを自律的に調査し、根本原因を特定し、数分で修正計画を生成することで、この前半部分を解決します。プレビュー期間中、お客様やパートナーからは MTTR が最大 75% 短縮、調査速度が最大 80% 向上、根本原因の特定精度が 94% という結果が報告されました。

しかし、調査と修正の提案はあくまで半分にすぎません。調査結果を読み、修正を書き、テストし、デプロイする作業は依然として人手が必要です。この後半部分も自動化できたらどうでしょうか。

前回の記事「AWS DevOps Agent によるエージェント型 AI を活用した自律的インシデント対応」では、AWS DevOps Agent を設定してアプリケーションを監視し、自律的な調査をトリガーし、本番デプロイのベストプラクティスに従う方法を紹介しました。また、Amazon CloudWatch アラームが発生した際に調査を自動的にトリガーする仕組みを示すコードサンプルも公開しています。この 2 つの記事により、Amazon CloudWatch アラームをきっかけに AWS DevOps Agent の調査をトリガーし、修正計画を生成できるようになりました。

本記事では、AWS DevOps Agent の修正計画の出力を、AWS CodeBuild 上でヘッドレスモードで動作する Kiro CLI と統合して、修正のループをエンドツーエンドで完結させる方法を紹介します。AWS DevOps Agent が修正分析を完了すると、イベント駆動型のパイプラインが調査結果を自動的に Kiro CLI へルーティングします。Kiro CLI はコードベースに修正を適用し、人によるレビュー用の pull request を作成し、承認後にデプロイをトリガーします。結果として、L1/L2 インシデントは検知からデプロイ済みの修正まで、最小限の人手介入で完了します。唯一人が介在するのは pull request の承認だけです。

サンプルの CloudFormation アプリケーションを使い、インフラのコード、異常発生用のスクリプト、イベントルーティング、そしてすべてを機能させる Kiro CLI の steering 設定を含めた、ソリューション全体を解説します。ソースコードはすべて、付随する aws-samples のリポジトリで公開されています。

ソリューションの概要

AWS 上で稼働する典型的な Web アプリケーションを考えてみましょう。Application Load Balancer の背後にフロントエンドがあり、バックエンドの計算処理は Amazon EC2、データベースは Amazon RDS で構成され、ソースコードと CloudFormation テンプレートは AWS CodeCommit に置かれています。この環境で何か問題が発生すると、本ソリューションは 2 つの AWS フロンティアエージェント — 自律的な調査と修正を行う AWS DevOps Agent、そして自動的なコード修正を行う Kiro CLI — を、完全サーバーレスのイベント駆動型ブリッジでつなぎ、インシデントからデプロイ済みの修正までアプリケーションを進めます。

図 1 – ソリューションアーキテクチャ

仕組み

インシデントの発生 – アプリケーションで問題が発生します。CPU 使用率の上昇、エラー率の上昇、応答速度の低下などです。Amazon CloudWatch アラームが発生します。
DevOps Agent による調査 – アプリケーションが Agent Space にオンボードされている AWS DevOps Agent が、メトリクス、ログ、デプロイ履歴を自律的に突き合わせ、根本原因を特定して修正計画を生成します。
EventBridge による信号のルーティング – Amazon EventBridge のルールが Mitigation Completed イベント（ソース: aws.aidevops）を検知し、AWS Lambda 関数を呼び出します。
Lambda による抽出とキューイング – AWS Lambda 関数が AWS DevOps Agent の API を呼び出して修正の要約と実行計画を取得し、そのペイロードを Amazon SQS キューに送信します。
CodeBuild による Kiro CLI の実行 – Amazon SQS キューにメッセージが届くと、SQS イベントソースマッピングを持つ AWS Lambda 関数が AWS CodeBuild の実行をトリガーし、メッセージの内容を環境変数として渡します。AWS CodeBuild は、修正のペイロードを修正用プロンプトとして使い、ヘッドレスモード（--no-interactive --trust-tools=read,write,grep,shell）で Kiro CLI を実行します。
Kiro CLI による修正の適用 – リポジトリの構成と修正の規約を記述した steering ファイルに従い、Kiro CLI は CloudFormation テンプレートやアプリケーションコードを修正し、フィーチャーブランチにコミットして pull request を作成します。
人による承認とパイプラインによるデプロイ – 開発者が pull request をレビューします。承認されてマージされると、関連するデプロイパイプラインがトリガーされ、変更が実行されます。

前提条件

このウォークスルーを進めるには、以下が必要です。

AWS DevOps Agent へアクセスできる AWS アカウント
設定済みの Agent Space
Pro、Pro+、Power のいずれかのサブスクリプションを持つ Kiro CLI（ヘッドレスモードの API キーに必要）
適切な認証情報で設定済みの AWS CLI
アカウントの AWS CodeCommit リポジトリに push したサンプルリポジトリ

完了したら、Readme ファイルに従って、上記のアーキテクチャを実装・実行するためのコンポーネントをセットアップしてください。以下のセクションでは、このアーキテクチャを支えるために構築されたコンポーネントについて説明します。

修正イベントの取得

AWS DevOps Agent は、調査や修正の状態が変化するたびに、Amazon EventBridge のデフォルトイベントバスへライフサイクルイベントを発行します。各イベントはソース aws.aidevops を使用し、Mitigation Completed、Investigation Completed、Mitigation Failed のように、具体的な内容を示す detail-type を持ちます。本記事では、修正が正常に完了した瞬間という単一の信号に焦点を当てます。

EventBridge のルールと Lambda による抽出

Mitigation Completed の detail-type に一致する Amazon EventBridge のルールが、AWS Lambda 関数を呼び出します。イベントのペイロードには（agent_space_id、task_id、execution_id という）メタデータが含まれており、これにより AWS Lambda 関数は AWS DevOps Agent を呼び出し、修正の要約（どのアクションを取るべきか、その理由）と実行計画（ステップバイステップの手順）という 2 つの重要なオブジェクトを取得できます。この構造化されたペイロードは、後続の処理のために Amazon SQS キューへ発行されます。

Kiro CLI によるヘッドレスな修正

修正のペイロードが Amazon SQS キューに届くようになったので、次はアプリケーションとインフラのリポジトリをチェックアウトし、コードベースに対して Kiro CLI エージェントを実行し、変更を push できるコンピューティング環境が必要です。AWS CodeBuild はこれに適しています。オンデマンドのコンピューティングを提供し、AWS CodeCommit とネイティブに統合され、永続的なインフラを必要としません。

Kiro CLI 2.0 ではヘッドレスモードが導入され、対話的なターミナルなしでデプロイパイプライン内でプログラムから実行できるようになりました。（AWS Secrets Manager に保管された）API キーで認証し、プロンプトを渡すと、Kiro CLI は対話型の体験と同じツール、同じエージェント、同じ機能でエンドツーエンドに実行します。

CodeBuild による修正のオーケストレーション

Amazon SQS キューにメッセージが届くと、トリガー用の AWS Lambda 関数が Amazon SQS のメッセージ本文を環境変数として渡し、AWS CodeBuild の実行を開始します。AWS CodeBuild の buildspec は、次のような単純な手順で構成されています。

インストール: Kiro CLI をインストールし、環境を設定します。KIRO_API_KEY は AWS Secrets Manager から自動的に取得され、ハードコードされることはありません。
プロンプトの生成: Python スクリプトが、構造化された修正のペイロードを自然言語の修正用プロンプトに変換します。内容を検査して、変更がインフラ向けかアプリケーションコード向けかを分類し、アクション、判断理由、具体的な指示を含む、絞り込んだプロンプトを生成します。
フィーチャーブランチの作成: 追跡できるよう、agent space と実行 ID にもとづいて名付けた新しいブランチをチェックアウトします。
Kiro CLI の実行: 生成したプロンプトとともに、Kiro CLI をヘッドレスモードで呼び出します（kiro-cli chat --no-interactive --trust-tools=read,write,grep,shell "生成したプロンプト"）。承認を行う人間がいないため、--trust-tools フラグは最小権限の原則に従って特定のツールカテゴリのみを自動承認します。
検証とコミット: ガードレールが変更を検査します。ファイル数の上限、保護対象ファイルの検出、Python の構文検証（py_compile）、YAML の lint です。すべてのチェックを通過すると、変更がコミットされ push されます。
pull request の作成: 修正のアクションをタイトルとし、AWS DevOps Agent の判断理由を説明文に含めた AWS CodeCommit の pull request を作成します。

steering ファイル

Kiro CLI が修正において効果的なのは、単に一般的なコードを生成するからではなく、steering ファイルによるものです。steering は、リポジトリの構成、コーディング規約、意思決定のフレームワークといった、プロジェクトに関する永続的な知識を Kiro に与えます。

このソリューションでは、steering ファイルが自動修正のガードレールとして機能します。次の内容を定義しています。

リポジトリの構成 – 各ディレクトリをその用途に対応付けます。
意思決定のフレームワーク – 変更をインフラ向けかアプリケーション向けかに分類するルールです。
スコープの制約 – 1 回の修正につき最大 3 ファイルまで、新規ファイルの作成禁止、新規依存関係の追加禁止、削除の禁止です。
保護対象ファイル – buildspec、インフラのパイプラインテンプレート、ブリッジのコード、そして steering ファイル自体は、明示的に変更禁止です。
フェイルセーフ – プロンプトが曖昧であったり、Kiro が何を変更すべきか判断できない場合は、推測するのではなく変更を行いません。

この steering ファイルはリポジトリにコミットされているため、すべての AWS CodeBuild の実行時に自動的に読み込まれます。これにより、Kiro CLI は大規模なリファクタリングではなく、対象を絞った予測可能な変更を行えます。

pull request からデプロイまで

ここまでで、自動化されたパイプラインはその役割を果たしています。Kiro CLI が修正計画を分析し、適切なファイルを変更し、フィーチャーブランチ上に pull request を作成しました。pull request の説明文には、何を変更したか、なぜ変更したか（AWS DevOps Agent の判断理由そのもの）、そして元のインシデントまで完全に追跡できる agent space と実行 ID が含まれています。

ここで、human-in-the-loop によるゲートが機能します。開発者が pull request をレビューし、変更が正しく、適切な範囲に収まっており、デプロイして安全であることを確認します。この承認のステップは意図的なものです。エージェントによる調査、分析、修正の提案は信頼していますが、最終的なデプロイの判断は人が行います。

pull request が承認されメインブランチにマージされると、デプロイパイプラインが承認された変更を対象の環境に反映します。

Amazon CloudWatch アラームからデプロイ済みの修正までの一連のサイクルは、数時間ではなく数分で完了し、唯一の手動ステップは pull request のレビューです。L1/L2 インシデントを大量に扱う組織にとって、これは運用にかかる負担の軽減と復旧の高速化に直結します。

クリーンアップ

継続的な課金を避けるため、このウォークスルーで作成したリソースを削除してください。完全な削除手順については Readme を参照してください。

まとめ

本記事では、AWS DevOps Agent の修正出力を Kiro CLI と統合し、クローズドループのインシデント修正パイプラインを構築する方法を紹介しました。この 2 つのフロンティアエージェントを連携させることで、オペレーションチームはインシデントの検知から、pull request の承認という単一の人的タッチポイントを経て、デプロイ済みの修正までを実現できます。

このアプローチは、エンタープライズのオペレーションに次のような明確な効果をもたらします。

MTTR の短縮 – これまで手動での調査と修正に数時間を要していた L1/L2 インシデントが、数分で解決できるようになります。
オペレーターの生産性向上 – エンジニアは、その場対応の消火作業から、対象を絞った AI 生成の修正をレビューし承認する作業へと移行できます。
一貫した修正 – steering ファイルがチームの規約と意思決定のフレームワークを体系化することで、インシデントの発生時期や頻度にかかわらず、すべての自動修正が同じ基準に従うようになります。

始めてみたい方は、aws-samples のリポジトリから完全な実装を clone し、AWS DevOps Agent のドキュメントで最初の Agent Space を設定し、Kiro CLI のドキュメントで steering ファイル駆動のコード生成についてさらに詳しく確認してください。ご質問や、このパターンをどのように応用したかを共有したい場合は、以下にコメントを残すか、リポジトリで issue を開いてください。

翻訳は App Dev Consultant の宇賀神が担当しました。

週刊AWS – 2026/8/3週

Tadami Nishimura — Mon, 10 Aug 2026 07:19:45 +0000

みなさん、こんにちは。ソリューションアーキテクトの西村です。
今週も週刊AWS をお届けします。

8月中旬から下旬にかけて、AWS デジタル社会実現ツアー 2026 が全国 8 都市で開催されます。2022 年から毎年開催しているイベントで、今年で 5 年目を迎えます。8/18 の北海道を皮切りに、新潟、静岡、愛知、福岡、宮城など各地を約 2 週間で巡ります。AI エージェントの最新動向を、デモを交えて紹介するセッションのほか、地域企業の AI/クラウド活用事例、学生による地域課題解決 AI コンテストの入賞発表、自治体・地銀・大学・パートナーが集う産学官金パネルディスカッションなど、地域ならではのコンテンツが盛りだくさんです。お近くの開催地がありましたら、ぜひ足を運んでみてください。各都市の日程と申し込みはブログをご確認ください。

それでは、先週の主なアップデートについて振り返っていきましょう。

2026年8月3日週の主要なアップデート

8/3(月)
- Amazon SageMaker AI サーバーレスモデルカスタマイズがフルファインチューニングに対応
  Amazon SageMaker AI のサーバーレスモデルカスタマイズ機能が、25 種類以上のオープンソースモデルに対するフルファインチューニング (全パラメータ更新) に対応しました。従来の LoRA などのパラメータ効率の高い手法 (PEFT) に加えて、モデルの全パラメータを更新するより深いモデルの適応（カスタマイズ）が可能になります。インフラのプロビジョニングや管理は SageMaker が行い、利用者は使用した分だけ支払う従量課金です。対応リージョンは米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京)、欧州 (アイルランド) の 4 リージョンです。
- AWS Organizations の最大アカウント数クォータが Service Quotas で確認可能に
  AWS Organizations の「Maximum number of accounts (組織内の最大アカウント数)」クォータとその使用率を、AWS Service Quotas のコンソールおよび GetServiceQuota API から直接確認できるようになりました。従来は現在の上限値を知るために AWS Support やアカウントチームへの問い合わせが必要でしたが、管理アカウントにログインして Service Quotas を参照するだけで確認できます。上限到達前にクォータ引き上げをリクエストできるため、マルチアカウント環境のアカウント増加を計画的に進められます。この可視化機能は米国東部 (バージニア北部) リージョンで利用できます。
- OpenAI GPT-5.6 Sol、Terra、Luna が Amazon Bedrock で 100 万トークンコンテキストウィンドウに対応
  Amazon Bedrock 上の OpenAI GPT-5.6 Sol、Terra、Luna の 3 モデルが 100 万トークンのコンテキストウィンドウに対応しました。コードベース全体、長文の法務・規制文書、マルチターンのエージェント履歴を分割せずに 1 リクエストで処理できます。明示的キャッシュブレークポイントによるプロンプトキャッシュに対応し、キャッシュ読み取りは通常入力比 90% 割引で課金されます。利用は bedrock-mantle エンドポイントの Responses API 経由で、Sol は米国東部 (バージニア北部) と米国東部 (オハイオ) の 2 リージョン、Terra と Luna はこれに米国西部 (オレゴン) を加えた 3 リージョンで利用できます。
8/4(火)
- RDS for SQL Server が SQL Server Audit ログの CloudWatch への発行に対応
  Amazon RDS for SQL Server が、SQL Server ネイティブの監査機能である SQL Server Audit のログを Amazon CloudWatch Logs に発行できるようになりました。従来は Amazon S3 バケットへのアップロードのみに対応していましたが、今回のアップデートで発行先として S3、CloudWatch、またはその両方を選択できます。CloudWatch に発行した監査ログは JSON 形式で保存され、メトリクスフィルターやアラームによるリアルタイム分析に使用できます。本機能はすべての AWS 商用リージョンと AWS GovCloud (US) リージョンで利用できます。
- AWS Application Load Balancer および Network Load Balancer が RFC 9151 準拠のセキュリティポリシーをサポート
  AWS Application Load Balancer (ALB) と Network Load Balancer (NLB) が、RFC 9151 (CNSA 1.0 スイートの TLS プロファイル) に準拠した新しいセキュリティポリシーに対応しました。RFC 9151 は米国 National Security Agency (NSA) が National Security Systems (NSS) 向けに定めた暗号要件を TLS 1.2 / TLS 1.3 に適用するプロファイルです。完全準拠を強制する Strict ポリシーと、非準拠クライアントも受け入れる Interop ポリシーの 2 系統、計 7 種類のポリシーが提供され、移行期間中の接続断を避けながら段階的に準拠を進められます。全 AWS 商用リージョン、AWS GovCloud (US) リージョン、中国リージョンで追加料金なしで利用できます。
- Amazon Bedrock、OpenAI GPT モデル向け Web Search を提供開始
  Amazon Bedrock に組み込みのサーバーサイドツール「Web Search」が一般提供 (GA) されました。OpenAI モデル (GPT-5.4、GPT-5.5、GPT-5.6 Sol/Terra/Luna) が最新の Web 情報で応答をグラウンディングできるようになります。検索は Amazon が運営する Web インデックスとナレッジグラフを使って AWS 内部で完結するため、外部検索ベンダーの契約・API キー管理・追加のセキュリティレビューが不要です。既存の Responses API 呼び出しに web search ツールを 1 つ追加するだけで、引用付きの応答を単一の API コールで取得できます。提供リージョンは米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン) の 3 つで、料金は 1,000 クエリあたり 12.00 USD です。
8/5(水)
- Amazon Aurora Serverless がエージェント型 AI などのバースト性ワークロード向けにスケーリングを高速化
  Amazon Aurora Serverless のスケールアップ時の初期キャパシティが引き上げられ、1 秒以内に最大 12 ACU まで到達し、その後ワークロードの増加に応じて最大 256 ACU までスケールするようになりました。ワークロード終了後は 0 ACU まで自動でスケールダウンします。この改善はプラットフォームバージョン 3 または 4 で稼働するすべての Aurora Serverless クラスターでデフォルト有効となり、設定変更や追加料金は不要です。活動のバーストと長いアイドル期間を繰り返すエージェント型 AI アプリケーションのように、事前のキャパシティ予測が難しいワークロードに適した強化です。
- Amazon DynamoDB がリアルタイムベクトル検索をサポート
  Amazon DynamoDB にネイティブなベクトル検索機能が一般提供 (GA) されました。テーブルに新しいインデックスタイプ「ベクトルインデックス」を作成し、`SearchVectors` API で近似最近傍 (ANN) 検索を実行できます。1 桁ミリ秒のレイテンシと 99% 以上の再現率 (recall) を両立し、数兆規模のベクトルまで対応する設計です。埋め込みベクトルを既存の属性と同じアイテムに格納できるため、別途ベクトルデータベースを立てて同期パイプラインを構築する必要がなくなります。オンデマンドキャパシティモード専用で、すべての AWS 商用リージョンおよび AWS GovCloud (US) で利用できます。詳細はこちらのブログをご確認ください。
- AWS Lambda が VPC 外の関数向けに最大 3,000 Mbps のスケーラブルなネットワーク帯域幅を発表
  AWS Lambda が、VPC に接続していない関数を対象に、メモリ設定に比例してネットワーク帯域幅がスケールする機能を発表しました。従来は実行環境あたり 625 Mbps が上限でしたが、2 GB のメモリで 625 Mbps、10 GB で最大 3,000 Mbps まで帯域幅が引き上げられます。有効化には AWS Service Quotas での申請が必要で、承認後はアカウント内の VPC 外の全関数に自動適用されます。追加料金はなく、すべての AWS 商用リージョンで利用できます。大容量データを転送する処理では実行時間が短縮され、GB 秒課金である Lambda の実行コスト削減につながります。
8/6(木)
- Amazon Bedrock AgentCore で temporal policies と rate limiting を発表
  Amazon Bedrock AgentCore に 2 つの新しい制御機能が追加されました。1 つ目の temporal policies (時系列ポリシー) は、セッション内でエージェントが過去に実行したアクションの履歴を踏まえて各リクエストを許可・拒否するステートフルな認可機能です。「承認が先行していなければ送金を拒否する」「前のツール呼び出しの出力と引数が一致しなければ拒否する」といったルールを、エージェントのコード外 (Gateway 層) で決定的に強制できます。2 つ目の rate limiting は、Gateway に接続されたツール・モデル・エージェントへのトラフィックを、OAuth の JWT クレームまたは AWS IAM プリンシパル単位で制限する機能です。リクエスト数、トークン数、同時接続数の 3 つのメトリクスに対応します。temporal policies は Cedar 互換の新しいオープンソースポリシー言語 Dogwood (Apache 2.0) で記述し、16 リージョンで利用できます。
- Amazon Quick がマルチデータセット分析機能をサポート
  Amazon Quick (旧 Amazon QuickSight を含む Quick Suite) の Topic が、1 つの Topic に最大 12 個のデータセットを追加し、データセット間のリレーションシップを定義できるようになりました。定義したリレーションシップに基づいて Quick がクエリ実行時に JOIN を行うため、従来必要だったデータ準備段階での事前 JOIN や非正規化テーブルの作成が不要になります。この機能はダッシュボード (分析シート) の構築と自然言語 Q&A (チャット) の両方で利用でき、1 つのセマンティックモデルを人と AI エージェントの共通の参照先にできます。行レベルセキュリティ (RLS) / 列レベルセキュリティ (CLS) はデータセットレベルで適用され、ランタイム JOIN 時にも維持されます。Amazon Quick が利用可能な全 AWS リージョンで一般提供が開始されています。
- Amazon Bedrock AgentCore の runtime instances が一般提供開始
  Amazon Bedrock AgentCore に、自分の AWS アカウント内の Amazon EC2 インスタンス上で AI エージェントを実行できる新機能「runtime instances」が追加されました。EC2 インスタンスの選択肢 (GPU、メモリ最適化、コンピューティング最適化) を使いながら、プロビジョニング・パッチ適用・スケーリング・ライフサイクル管理は AgentCore が担当します。セッションは最大 14 日間継続でき、既存の microVM ベースのサーバーレスランタイム (最大 8 時間) を補完します。料金は EC2 利用料に加えて、オンデマンド価格の 12% (GPU 系ファミリーは 7.8%) の管理料が発生します。東京を含む 9 リージョンで利用できます。詳細はこちらのブログをご確認ください。
8/7(金)
- Amazon OpenSearch Service が既存ドメイン向けの追加アップグレード猶予期間と追加バージョンのサポート期限を発表
  Amazon OpenSearch Service は、2024 年 11 月に発表したレガシーバージョン向け Extended Support を 12 か月延長し、2027 年 11 月 7 日までセキュリティパッチと OS パッチの提供を継続します。対象は Elasticsearch 1.5〜7.8 (5.6 を除く)、OpenSearch 1.0〜1.2 および 2.3〜2.9 です。ただし 2026 年 11 月 7 日以降、これらのバージョンのサーチャージはインスタンス料金と同額になり、実質的にインスタンスコストが 2 倍になります。あわせて、Elasticsearch 6.8 / 7.9 / 7.10、OpenSearch 1.3 / 2.11〜2.19 の Standard Support 終了日 (2027 年 11 月 7 日) と Extended Support 期間 (1 年または 3 年) が新たに発表されました。
- AWS IAM Identity Center が新規組織インスタンス向けにワンクリックのマルチリージョンオプションをサポート
  AWS IAM Identity Center で、新規の組織インスタンス作成時にマルチリージョン対応をワンクリックで有効化できるようになりました。従来はカスタマーマネージド KMS キーの作成、キーポリシーの設定、リージョンの手動追加という複数の手順が必要でした。作成時に「シングルリージョン」、「マルチリージョン」、「カスタム」の 3 つの構成オプションから選択でき、「マルチリージョン」を選ぶとマルチリージョン KMS キーの自動作成と追加リージョンへのレプリケーションまでが自動で完了します。プライマリリージョンで IAM Identity Center に障害が発生しても、追加リージョン経由で AWS アカウントへのアクセスを継続できます。本オプションはデフォルトで有効化されている 17 の商用リージョンで利用できます。

それでは、また来週！

著者について

Kiro powers は Agent Plugins のサポートを開始します

稲田大陸 — Mon, 10 Aug 2026 06:59:55 +0000

本記事は 2026 年 8 月 7 日に公開された Clare Liguori、Dan Kiuna による “Kiro powers now support Agent Plugins” を翻訳したものです。

あなたは良いものを作りました。チームが実際にデプロイする手順を落とし込んだスキルと、社内サービスと通信する MCP サーバーです。ちゃんと動きます。そこで、チームが使っているクライアント向けにパッケージ化し、次に隣のチームが使っているクライアント向けに再びパッケージ化し、さらにオープンソースのコントリビューターが好むクライアント向けにもう一度パッケージ化します。同じ知識、同じツールなのに、3 組のドキュメントと、同期を取り続けなければならない 3 つのパッケージができあがります。

拡張機能の作者は、エージェントが拡張機能を受け入れるようになって以来、この「税金」を払い続けてきました。開発者はそのもう半分を負担しています。まさに必要としていたプラグインを見つけたのに、いま使っているツールでは読み込めない、というものです。

Kiro powers を発表したとき、私たちが訴えたのは、エージェントは最初からすべてを知っている必要はない、ということでした。MCP サーバーを、それを正しく使うためのフレームワークの専門知識とバンドルし、関連するときにだけ読み込むことで、ベースラインのコンテキストコストを最小限に保てます。

このモデルは機能します。制約となっていたのは供給でした。power は Kiro で動かすために Kiro 向けに作らなければならなかったからです。

2026 年 8 月 7 日、Kiro powers は、エージェント拡張をパッケージ化するためのオープンかつベンダーニュートラルな仕様である Agent Plugins 1.0.0 のサポートを順次展開します。AWS は、Cursor、Microsoft、OpenAI、Vercel と並ぶ Agent Plugins Technical Steering Committee の設立メンバーです。実際のところ、これは、この標準に準拠して公開されたプラグインが、Kiro で power としてインストールできることを意味します。

Agent Plugins とは

Agent Plugins は、AI エージェントを拡張する再利用可能なコンポーネントについて、相互運用性の最低限の土台を定義する、オープンかつベンダーニュートラルな仕様 (v1.0) です。Agent Skills と MCP サーバーのパッケージ化の方法を標準化し、互換性のある任意のクライアントが一貫した形でそれらを検出・読み込みできるようにします。

my-plugin/ 
├── plugin.json          # Identifies the plugin + the Agent Plugins version it targets
├── skills/              # Agent Skills in the standard format 
│   └── summarize/ 
│       ├── SKILL.md
│       ├── scripts/ 
│       └── references/ 
└── mcp.json             # stdio, Streamable HTTP, or HTTP+SSE MCP servers

my-power/ 
├── POWER.md             # Identifies the power and contains onboarding steps
├── steering/            # Agent steering in the standard format
│   └── summarize.md    
└── mcp.json             # stdio, Streamable HTTP, or HTTP+SSE MCP servers

Agent Plugin は本質的に、マニフェストと、固定された場所に配置されたコンポーネントを持つディレクトリです。

なぜ標準で協働するのか

私たちは、このパターンが繰り返されるのを、見分けがつくほど何度も見てきました。package.json が登場する前、JavaScript ライブラリのインストールとは、手作業でスクリプトをダウンロードし、コピー&ペーストで依存関係を管理することを意味していました。フォーマットが 1 つに収束すると、npm、yarn、pnpm のいずれもが同じパッケージをインストールできるようになりました。Open Container Initiative (OCI) が登場する前、コンテナイメージは Docker の成果物でした。登場後は、同じビルドが containerd、Podman、あるいは仕様に準拠するその他のもので動作します。

エージェント拡張は、まさに同じ地点にあります。コンポーネントは優れているのに、時間が費やされているのはパッケージングの部分なのです。

Agent Plugins は、長く続く標準がたどるのと同じ道のりでここまで来ました。Vercel が最初のドラフトを公開し、その後、それぞれが独自にこの問題を解決してきた各社によるワーキンググループを招集しました。AWS、Cursor、Microsoft、OpenAI、Vercel は共同で仕様を洗練させ、1 社のロードマップがフォーマットの方向性を左右しないようにガバナンスを整備しました。Technical Steering Committee には 5 社すべてからコアメンテナーが参加しており、コントリビューションプロセスと技術的な意思決定は公開されています。power を作成する人にとって、これは実際的な保証となります。仕様が進化すれば power もそれとともに進化し、プロプライエタリな移行を待つ必要はありません。

Skills が Kiro powers の第一級の構成要素に

標準を採用することで、power が何であるかも広がります。Kiro は以前からスキルをサポートしてきましたが、それらを power の中で配布する手段はありませんでした。これまで power は、POWER.md ファイル、目的に応じてパッケージ化された任意の steering ファイル、そして mcp.json から構成されていました。Agent Plugins は、Agent Skills をネイティブなコンポーネントとして取り込みます。power は今や、skills/ 配下に 1 つ以上の構造化されたスキルを持つことができ、それぞれが独自の SKILL.md と、補助的な scripts/、references/ を備えられます。

開発者にとって、これは次のことを意味します。

読むだけでなく、実行される専門知識。 スキルは、その手順とあわせて実行可能なスクリプトや参考資料をバンドルでき、それらは power の一部として実行されます。
1 つの長大なファイルではなく、組み合わせ。 すべてが 1 つのファイルの中で場所を奪い合うのではなく、複数のスキルを 1 つの power にまとめ、それぞれが自分のワークフローに応じて有効化されます。
関心ごとに定められた置き場所。 ツールは mcp.json に、知識は skills/ に、クライアント固有の挙動は名前空間の下に置かれます。構造が前提として決まっていれば、power の作成・読解・拡張のいずれもが容易になります。

今日から何が変わるのか

power をインストールする側にとって、カタログはもはや Kiro 向けに作られたものだけに限られません。

あるチームが自社の内部 API 向けに Agent Plugin を公開します。そのチームのユーザーは、Kiro 固有のパッケージングなしに、それを Kiro にインストールできます。
あるベンダーが、自社サービス向けのプラグインをすでに保守しています。Kiro ユーザーは、移植を待つことなくそれをインストールできます。
コミュニティが作成したプラグインは、最初にどこで公開されたものであっても、powers パネルの候補になります。

power を作成する側にとっては、公開されたスキーマを持つ 1 つの文書化されたフォーマットに対して書けばよく、公開したものは 1 つのクライアントではなく、互換性のあるすべてのクライアント上の開発者に届きます。

既存の power はそのまま動作します

インストール済みのものが壊れることはなく、公開済みのものが動作しなくなることもありません。従来の方法で作られた power は、これまでどおり読み込まれ続けます。ただし、Agent Plugins のレイアウトへの移行は、遅らせるよりも早めに行うことをおすすめします。新しい機能はまずそこに実装されますし、それがあなたの成果物をポータブルにするものだからです。

powers は、プラグインを取り巻く Kiro ならではの体験であり続けます。そして、その部分こそ私たちが引き続き作り込んでいるところです。キュレーション、IDE や kiro.dev からのワンクリックインストール、初回利用時の認証情報の入力プロンプト、そしてキーワード駆動の有効化です。これにより、複数の power をインストールしていても、特定のタスクで必要になったときにだけ一部が有効化されるまでは、利用にかかるコストは実質ゼロで済みます。

ビジョンは変わりません

当初の主張は今も有効です。エージェントが賢くなるのは、最初からすべてを知っているからではなく、必要なときにちょうど適切な専門知識を読み込むからです。今日変わるのは、その専門知識がどこから来られるか、という点です。エコシステムがすでに生み出しているスキルやサーバーが、今やあなたのエージェントが取り込める power になり、そのコレクションは標準が広がるのと同じ速さで増えていきます。

仕様は agent-plugins.org でご確認いただけます。最初の powers ローンチの記事を読み返し、powers パネルを開いて、すでにインストールできるものを確かめてみてください。そして、あなた自身の何かをパッケージ化し、何を作ったのかをぜひ教えてください。

週刊生成AI with AWS – 2026/8/3 週

Aiichiro Noma — Mon, 10 Aug 2026 05:40:41 +0000

みなさん、こんにちは。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 月末に開催予定ですのでチェックしておいてください。

今週は以上です。それでは、また来週お会いしましょう！

著者について

エージェンティックエンタープライズを AWS for SAP MCP Server on Amazon Bedrock AgentCore で実現

Koshi Matsumoto — Fri, 07 Aug 2026 09:26:35 +0000

ビジネスチャンス

組織は、エンタープライズレディな AI エージェント、つまりテクノロジーランドスケープ全体のツールやデータソースに安全に接続し、ライブのビジネスデータをもとに推論し、自律的にアクションを実行できるエージェントの構築にますます注目しています。世界中のお客様がこのニーズを肌で感じています。Harman International、Fortescue、PLDT などの複数のお客様は、従来の自動化の枠を超えて、企業全体でインテリジェントな意思決定を実現しようとしています。これらのお客様は、AI エージェントを SAP システムやその他のエンタープライズワークフローに接続し、財務プロセスにおける例外処理のオーケストレーション、調達ワークフローにおけるインテリジェントな自動化の推進、テクノロジーアップグレード時のデータ管理の最適化、サプライチェーンオペレーションのリアルタイムでの効率化を目指しています。しかし、このようなエージェントを構築するには、エージェントと連携先システムとの密結合が必要となり、それぞれを独立して開発、デプロイ、更新することが困難でした。

堅牢でスケーラブルな AI エージェントエコシステムは、エージェントとエージェントが使用するツールとの間のシームレスな相互運用性を実現する、標準化された通信プロトコルに依存しています。AWS は、真にエンタープライズレディな AI エージェントへの道は、エージェントとツールを疎結合にすることにあると考えています。これを実現するために、AWS は 2 つのオープンスタンダードを採用しました。2024 年に Anthropic がオープンソース化した Model Context Protocol（MCP）は、AI エージェントが外部のツールやデータソースに接続する方法を標準化し、任意の MCP クライアントが任意の MCP サーバーを検出して操作できるようにします。2025 年 4 月に Google が発表した Agent-to-Agent プロトコル（A2A）は MCP を補完するもので、異なるフレームワーク、ベンダー、組織の境界を越えて、独立した AI エージェント間の自律的なコラボレーションを可能にします。この 2 つが組み合わさることで、エージェントとツールを独立して開発、デプロイ、更新できる疎結合アーキテクチャが実現します。

今月初め、AWS は Amazon Bedrock AgentCore 上での AWS for SAP MCP Server の一般提供開始を発表しました。これは、この疎結合なエージェンティックアーキテクチャをお客様の SAP ランドスケープにもたらすために専用に構築されたものです。SAP が財務、調達、ロジスティクスなどの API を標準化するために使用している Open Data Protocol（OData）を基盤として構築された AWS for SAP MCP Server により、MCP クライアントとエージェントは SAP のビジネスデータやビジネスプロセスに接続できます。AWS for SAP MCP Server と Amazon Bedrock AgentCore を組み合わせることで、AI エージェントは SAP のデータとビジネスプロセスを理解し、それらをもとに推論し、リアルタイムでアクションを実行できます。しかも、完全な可視性、エンタープライズグレードのセキュリティ、そして企業のニーズに合わせて成長できるスケーラビリティを備えています。AWS for SAP MCP Server は、SAP Sapphire 2026 での発表を紹介した最近の AWS ブログでも取り上げられています。

AWS for SAP MCP Server とは？

AWS for SAP MCP Server は、SAP ERP のビジネスデータとビジネスプロセスをファーストクラスの MCP ツールへと変換します。Amazon Quick、Strands SDK、SAP Joule Studio でエージェントを構築する場合でも、A2A を使用してマルチエージェントワークフローをオーケストレーションする場合でも、AWS for SAP MCP Server を使えば、エージェントはすぐにライブの SAP データを検出して操作できるようになります。AWS はこの MCP サーバーをコンテナイメージとして無償で提供しており、MCP サーバーを大規模にホスティングするためのフルマネージドサービスである Amazon Bedrock AgentCore Runtime にデプロイできます。Amazon Bedrock AgentCore Runtime は、セッションの分離、SAP リソースへのプライベート接続、そして Amazon Bedrock AgentCore Identity による安全なインバウンドおよびアウトバウンドの認可を担うため、お客様はインフラストラクチャの管理ではなくエージェントの構築に集中できます。

AWS for SAP MCP Server の中核は、OData API として公開された SAP のビジネスデータとビジネスプロセスを MCP ツールとして橋渡しすることです。Amazon Bedrock AgentCore Runtime と組み合わせることで、MCP クライアントは以下のことが可能になります。

ファーストクラスの MCP ツールを通じて利用可能な SAP OData サービスを検出し、エージェントが SAP ERP システムで利用可能なビジネスプロセスおよびデータ API のカタログにアクセスしてオーケストレーションを行えるようにする
受注伝票、購買発注、品目、会計伝票などの SAP ビジネスオブジェクトの作成（Create）、読み取り（Read）、更新（Update）、削除（Delete）
エンタープライズ ID プロバイダーと業界標準の OAuth 2.0 を使用して、ユーザーとエージェントを安全に認証・認可する
SAP Business Technology Platform（SAP BTP）内の API Management を通じて SAP ERP に接続する
エージェントや MCP クライアントによるすべてのツール呼び出しを、さまざまなログレベルで完全に可視化する

AWS for SAP MCP Server とは何か、そして全体像がどのように構成されているかを見てきました。次に、これをエンタープライズレディたらしめている主要な機能を詳しく見ていきましょう。

図 1: SAP BTP 経由の SAP ERP 接続を備えた Amazon Bedrock AgentCore 上の AWS for SAP MCP Server アーキテクチャ

基盤: 主要機能

標準に基づいて構築: OData の利点: SAP は、SAP ERP アプリケーション（SAP S/4HANA および SAP ECC）を含む全製品ポートフォリオにわたって OData を標準の API プロトコルとして採用しており、財務、調達からロジスティクス、人事管理（Human Capital Management）まで、ビジネスのあらゆる側面をカバーする数百の OData サービスをドキュメント化して公開しています。また、SAP が OData サービスの構築と公開のために提供するフレームワークである SAP Gateway を使用して、独自のカスタム OData API を構築・公開することもできます。これにより、コア外のエージェンティックワークフローやカスタム統合といったクリーンコア拡張をサポートし、システムのアップグレード耐性を維持しながら、インテリジェントな自動化を実現できます。これらの API は SAP ERP システム内に存在し、有効化するとお客様のランドスケープまたはネットワーク内でアクセス可能になります。AWS for SAP MCP Server はこの基盤の上に構築されています。AI エージェントはまず、公開されている MCP ツールを使って SAP OData カタログを検出し、サービスメタデータを調査して、どのようなビジネスデータやビジネスプロセスが利用可能かを把握します。その上で、受注伝票の作成、購買発注の更新、会計伝票の読み取りといった SAP ビジネスオブジェクトへのアクションを実行できます。現在のリリースは OData V2 をサポートしており、SAP ERP アプリケーションとの互換性があります。

利用可能なサービスの検出: 動的サービスカタログとヒント: AWS for SAP MCP Server の最も強力な機能の 1 つは、エージェントに提供されるカタログ検出 MCP ツールです。これにより、エージェントはお客様のランドスケープで利用可能な SAP OData サービスを実行時に検出できます。AWS for SAP MCP Server は 2 つのカタログ検出モードをサポートしており、エージェントが利用可能な SAP OData サービスを検出する方法を柔軟に選択できます。

リモートカタログ — MCP サーバーが SAP ERP システムの公開する OData カタログサービスに直接接続し、有効化されている OData サービスのライブでリアルタイムなビューをエージェントに提供します。新しいサービスが有効化されるたびに、SAP システムで利用可能なサービスの最新のビューをエージェントに常に持たせたい場合は、このモードを選択してください
ローカルカタログ — Amazon S3 に保存された独自のカタログ設定ファイルを持ち込むことで、どの SAP OData サービスをエージェントに公開するかを完全にコントロールできます。SAP API が API 管理レイヤー（例: SAP BTP の API Management）を通じて公開されており、ネイティブの SAP OData カタログが利用できない場合は、このモードを選択してください

検出機能に加えて、MCP サーバーはサービスヒント機能を提供しており、特定の SAP OData サービスに関するより深いコンテキストガイダンスを AI エージェントに与えます。OData メタデータがサービスで利用可能なエンティティ、フィールド、リレーションシップを記述するのに対し、サービスヒントはさらに踏み込んで、既知の問題、推奨される回避策、サービス固有のガイダンスをエージェントに提供し、エージェントが SAP データを正しく解釈して操作できるよう支援します。ヒントは JSON 設定ファイルとして Amazon S3 に保存されます。ヒントは、利用可能な SAP OData サービス全体にグローバルに定義することも、パターンによって特定のサービスを対象にすることもできます。MCP サーバーは、エージェントがオンデマンドでサービスヒントをリクエストするためのツールを提供し、エージェントが正確かつ効率的な SAP OData 呼び出しを行うために必要なコンテキストガイダンスを返します。

エンタープライズセキュリティのために構築されたネットワークアーキテクチャ: AI ワークロードとエージェントを SAP に安全に接続することは、エンタープライズデプロイメントにおける重要な要件です。AWS for SAP MCP Server は、お客様自身の VPC 内の Amazon Bedrock AgentCore Runtime にデプロイできるため、MCP ツール呼び出しはプライベートネットワークの境界内にとどまります。MCP クライアントが MCP サーバーにツール呼び出しを行うと、VPC 内で実行されている MCP サーバーが SAP システムに接続してリクエストを実行します。AWS for SAP MCP Server は、SAP ERP システムのホスティング場所と SAP API の有効化方法に応じて、さまざまな接続オプションをサポートしています。各デプロイメントトポロジーのサポート方法は以下のとおりです。

SAP BTP API Management — SAP OData API は SAP BTP API Management レイヤーを通じて有効化することを推奨します。AWS for SAP MCP Server は、OAuth 2.0 認証を用いた HTTPS でこれらの API に安全に接続できます。この場合、トラフィックはインターネットに向けて送出され、TLS 暗号化によりトランスポートレイヤーで保護される点にご注意ください。
AWS 上の SAP cloud ERP private（旧 RISE with SAP） — お客様の VPC 内の Amazon Bedrock AgentCore にデプロイされた AWS for SAP MCP Server は、シンプルな直接接続には VPC ピアリング、複数の VPC や AWS アカウントにまたがる複雑な構成には AWS Transit Gateway を使用して、SAP マネージド VPC に接続します。お客様の VPC と SAP マネージド VPC 間のトラフィックは、AWS バックボーンネットワーク内にとどまります。
AWS 上の SAP ERP — SAP システムがお客様自身の AWS アカウントで稼働している場合、AWS for SAP MCP Server は同一 VPC 内、または同一アカウント内の VPC 間接続で Amazon Bedrock AgentCore にデプロイでき、接続は容易です。すべてのトラフィックは AWS ネットワーク内にとどまります。

すべての接続を保護: アイデンティティと認証: AWS for SAP MCP Server は AgentCore Identity を使用して、インバウンド（MCP クライアントから MCP サーバーへ）とアウトバウンド（MCP サーバーから SAP へ）という 2 つの重要なフローにわたる認証を管理します。この二層アプローチにより、各フローに対して個別の信頼境界が維持され、認証と認可の判断が各境界で独立して検証されます。このアーキテクチャ上の分離により、クライアントアクセスと SAP システムアクセスがそれぞれ独立した監査可能なポリシーで管理される、健全な認証態勢が実現します。組織は、業界標準のプロトコル（OAuth 2.0、OIDC、または SAML）を使用して認証を行い、任意の ID プロバイダーを選択できます。インバウンド認証には、AWS Identity and Access Management (IAM)、Amazon Cognito、または Microsoft Entra ID や Okta などのエンタープライズプロバイダーを使用できます。SAP へのアウトバウンド認証では、SAP に直接接続することも、エンタープライズディレクトリ経由でルーティングすることもできます。この柔軟性により、既存の ID 基盤に合わせた認証フローを設計でき、大規模な入れ替え（リップ&リプレース）は不要です。

AI エージェントのアクションに対する包括的なオブザーバビリティ: ライブの SAP システムに対して本番環境で AI エージェントを実行するには、企業がミッションクリティカルなアプリケーションに求めるのと同レベルのオブザーバビリティが必要です。AWS for SAP MCP Server には、AgentCore Observability による包括的なテレメトリが組み込まれています。AWS for SAP MCP Server を Amazon Bedrock AgentCore Runtime にデプロイすると、AgentCore は MCP サーバー用の Amazon CloudWatch ロググループを自動的に作成し、サーバーへのすべての MCP ツール呼び出しのログをキャプチャします。これにより、エージェントが SAP システムで何を読み取り、作成、更新、削除しているかを完全に可視化できます。AWS for SAP MCP Server は設定可能なログレベルをサポートしているため、環境やニーズに応じてログの詳細度をコントロールできます。すべての MCP ツール呼び出しのサマリーを記録するには INFO を、SAP への OData 呼び出しを含む詳細なリクエストとレスポンスのペイロードを取得するには DEBUG を、認証エラー、認可の問題、SAP から返される OData 固有のエラーなどの障害を記録するには ERROR を使用します。

ここまで AWS for SAP MCP Server の中核機能を説明してきました。次に、Agent-to-Agent プロトコルとあわせて、より広いエージェンティックランドスケープの中でどのように位置づけられるかを見ていきましょう。

マルチエージェントエコシステムにおいて MCP は A2A をどのように補完するのか？

企業がより高度なエージェンティック AI システムを構築するにつれて、複数のエージェントが連携して業務を遂行する必要が出てきます。オープンソースプロトコルはイノベーションを可能にする鍵であり続けてきましたが、エージェンティックの時代も例外ではありません。2024 年に Anthropic がオープンソース化した MCP は、エージェントが SAP のようなツールやデータに接続する能力を提供します。A2A はさらに一歩進んで、構築されたフレームワークやプラットフォームに関係なく、エージェント同士が対話できるようにします。MCP と A2A は、エージェンティックアーキテクチャの相互補完的な 2 つのレイヤーを形成します。

MCP は、エージェントを SAP OData サービスなどのツールやデータに接続するプロトコルであり、ビジネスプロセスとデータをエージェントに広く開放します
A2A は、異なるフレームワークで構築された、異なるベンダーによる、あるいは組織の境界を越えたエージェント同士が通信し、協働できるようにするプロトコルです。

AWS for SAP MCP Server はこの両方の世界に自然に適合し、エージェントが単独で動作する場合でも、より大きなマルチエージェントシステムの一部として動作する場合でも、ライブの SAP データを検出して操作するためのツールを提供します。

数分でデプロイ: CloudFormation による自動化

AWS for SAP MCP Server は、プロビジョニングプロセス全体を数分で自動化する AWS CloudFormation テンプレートを使用してデプロイできます。このテンプレートは、Bedrock AgentCore Runtime に AWS for SAP MCP Server をデプロイするために必要なリソースの作成を担います。これには、アイデンティティのセットアップ、IAM ロールの作成、SAP システムで利用可能な API を検出してファーストクラスの MCP ツールとして公開するために必要な設定が含まれます。

実世界へのインパクト: エージェンティックエンタープライズをリードするお客様

テクノロジーの最も説得力のある証明は、その約束だけでなく、お客様がそれを使って何を構築するかにあります。AWS for SAP MCP Server の早期採用のお客様は、SAP のビジネスプロセスの深さと AWS の AI 機能を組み合わせることによる変革の可能性を、すでに実証しています。

Fortescue: S/4HANA とのエンタープライズスケールの AI 統合 – 「Fortescue は、AWS SAP MCP の一般提供開始を、SAP システムとのエンタープライズスケールの AI 統合を可能にする重要な一歩として期待しています。この機能は、SAP の機能をセキュアで構造化された再利用可能なツールレイヤーを通じて公開するという当社のアプローチをサポートし、強力なガバナンスとコントロールを維持しながら AI ユースケースの提供を加速するのに役立ちます。Fortescue にとってこれは、スケーラビリティ、セキュリティ、サポート性が重要となる S/4HANA 周辺およびクロスシステムの AI アプリケーションに特に関連します。私たちは AWS とのコラボレーション、そしてこの機能が企業全体で実践的かつ本番環境志向の AI 統合を推進する上で果たしうる役割を高く評価しています」
PLDT: エージェンティック AI による Procure-to-Pay の変革 – 「PLDT では、AWS for SAP MCP Server を活用したエージェンティックワークフローを通じて、Procure-to-Pay 業務を変革する旅に乗り出しています。今日、手作業を削減しサイクルタイムを短縮しながら、企業全体にわたるインテリジェントで自己学習型のエージェンティックシステムの基盤を築いています。」- Gilbert Gaw 氏、First Vice President & Head of IT and the Transformation Office (PLDT & SMART)、SMART Communications
Harman International: エージェンティック AI によるテスト管理のモダナイゼーション – 「AWS との戦略的パートナーシップは、エージェンティック AI の領域における新たな可能性を評価する機会を私たちに提供し続けています。現在、AWS for SAP MCP Server を活用してテスト管理戦略を進化させるとともに、当社のモダナイゼーションの取り組みを支援する上での可能性を検討しています」 – Varada Reddy 氏、Director of SAP Platform

始めましょう

Amazon Bedrock AgentCore Runtime 上の AWS for SAP MCP Server は、調達ワークフローの自動化、注文から入金（Order-to-Cash）サイクルの加速、財務の例外処理管理、あるいは SAP システムと非 SAP システムにまたがるマルチエージェントシステムの構築など、どのようなケースにおいても、AI エージェントを SAP のデータとプロセスにセキュアかつスケーラブルでエンタープライズレディな方法でオンボードするためのツールを提供します。AgentCore Runtime がサービスディスカバリ、セキュアな接続、インバウンドとアウトバウンドの認可、完全なオブザーバビリティを担うため、お客様は真のビジネス価値を生み出すエージェントの構築に集中できます。エンタープライズレディな AI エージェントの時代が到来しました。今日から構築を始めましょう。まずは AWS for SAP MCP Server のページをご覧ください。AWS が数千の SAP のお客様に選ばれるプラットフォームであり、イノベーションの場である理由については、AWS for SAP のページをご覧ください。

本ブログはAmazon Bedrockを用いて翻訳を行い、パートナーSA松本がレビューしました。原文はこちらです。

著者について

Rengarajan Sridharan

Renga は AWS の AI and Strategic Partner Engineering 部門の Senior Technical Program Manager として、SAP ワークロードに特化したプログラムを推進しています。エンタープライズリソースプランニング（ERP）ソリューションにおける 20 年以上の経験を持ち、お客様とパートナーがエンタープライズシステムをモダナイズし、ビジネス価値を最大化してデジタルトランスフォーメーションの成果を推進できるよう支援することを専門としています。

Krishnakumar Ramadoss

KK は Amazon Web Services (AWS) の Senior SAP Innovation Solutions Architect で、エンタープライズテクノロジー分野で 20 年の経験を持っています。著書を持つ技術エバンジェリストでもあり、データ分析、アプリケーション統合、生成 AI にわたって、お客様とパートナーが AWS 上で SAP ワークロードをモダナイズし拡張できるよう支援することを専門としています。

ランタイムインスタンス: Amazon Bedrock AgentCore 上の本番環境の AI エージェント用のパーシステントコンピューティング

Sébastien Stormacq — Fri, 07 Aug 2026 08:54:58 +0000

AI エージェントをプロトタイプから本番環境に移行すると、インフラストラクチャの課題は倍増します。エージェントは、数時間または数日間実行される複数ステップのワークフローにわたって状態を維持する必要があります。他のエージェントと調整したり、コンテキストを共有したり、特殊なタスクのために GPU にアクセスしたりする必要があります。Amazon Bedrock AgentCore Runtime microVM は、最大 8 時間実行できる完全マネージド型の呼び出し環境を提供し、マネージドセッションストレージを通じてステートフルワークフローをサポートします。ワークロードによっては、専用の大容量環境のメリットもあります。たとえば、エージェントを複数日間継続して実行したり、GPU や基盤となる OS にアクセスしたり、同じホスト上で複数の連携エージェントを実行したりする必要がある場合などです。

2026 年 8 月 6 日、ランタイムインスタンスを発表できたことを嬉しく思います。これは Amazon Bedrock AgentCore Runtime の新しい補完的なコンピューティングオプションで、複雑なエージェントワークロード向けに構築された永続的でマネージド型のインフラストラクチャをエージェントに提供します。

得られるもの
ランタイムインスタンスは、それぞれが独自の依存関係とアーティファクトタイプを持つ複数のエージェントを 1 つのランタイムにデプロイする AWS マネージド EC2 インフラストラクチャを提供します。エージェントは、最大 14 日間持続する共有セッション内で同じホストで共同作業できます。このサービスは、計算量の多いタスクのための GPU アクセラレーション、アイドル期間中のコスト削減のためのセッション停止/再起動、および独立して出荷したいチーム向けのコンテナ化されたデプロイをサポートします。セッション終了後も存続させる必要のある知識については、ランタイムインスタンスが Amazon Elastic Block Store (Amazon EBS) と AgentCore Memory と自然に組み合わされます。これにより、エージェントはセッションや環境を超えて長期的に思い出すことができます。

これまで、エージェントを何日も稼働させたい場合や、GPU アクセスやマルチエージェントの連携が必要な場合は、そのインフラストラクチャを自分で構築して管理する必要がありました。EC2 インスタンスのプロビジョニング、ネットワーキングの設定、セッション管理のセットアップ、スケーリングの処理、モニタリングの統合を行いました。ランタイムインスタンスは、AgentCore Runtime MicroVM ですでに使用しているのと同じ AgentCore API、ID 制御、およびオブザーバビリティと統合しながら、これらすべてを自動的に処理します。

エージェント開発者を笑顔にするべきことがいくつかあります。それは、エージェントが共有セッション内でお互いをツールと呼び、仕事が完了するまで自律的に反復できることです。どんなフレームワーク（CrewAI、LangGraph、LamaIndex、Strands でもどんなモデルでも持ち込めます。パッケージは最小限で、@app.entrypoint デコレータと zip ファイルまたはコンテナイメージだけです。また、ワークフローが何日にも及ぶ場合は、月曜日の夜に休止状態にして、水曜日の朝にすべてそのままの状態で再開してください。

Runtime MicroVM とランタイムインスタンスは補完的なコンピューティングオプションであり、単独で使用することも、同じ AgentCore Runtime API を使用して一緒に使用することもできます。Runtime MicroVM 上の軽量オーケストレーターエージェントは、インスタンス上で実行されている専用のワーカーエージェントに作業を調整してディスパッチできます。オーケストレーターは Runtime MicroVM の高速スケーリングを使用して API コール、タスクルーティング、結果集約を処理します。一方、インスタンス上のワーカーは、コードのコンパイル、セキュリティスキャン、GUI 自動化など、永続的な状態と OS への直接アクセスを必要とする計算量の多いタスクを実行します。

仕組みを見ていきましょう
このデモ用に 2 つのエージェントを作成しました。1 つは自然言語による記述から Python コードを生成する Code writer エージェントで、もう 1 つは生成されたコードのバグ、セキュリティ問題、スタイルの改善を分析する Code reviewer エージェントです。どちらのエージェントも同じファイルシステムを共有しているため、レビュー担当者はデータ転送や API コールを行わずに、ライターが作成したものをすべて読むことができます。

これがコードライターです（簡略化されており、エラー処理はありません）。

ライター = エージェント (
    model=“us.anthropic.claude-sonnet-4-5-20250929-v 1:0“,
    system_prompt=(
        「あなたはPythonのシニアエンジニアです。」
        「タスクが与えられたら、Python のコードブロックを1つだけ返す。散文は返さない。」
    ),
)

@app.entrypoint
def handler(event, context):
    task = event.get(“task“) or event.get(“prompt“)
    session_id = getattr(context, “session_id“, None) or event.get(“session_id“)
    session_dir = SHARED_DIR / session_id
    session_dir.mkdir(parents=True, exist_ok=True)

    code = str(writer(task))
    (session_dir / ”code.py”).write_text(code)

    return {“agent“: “writer“, “wrote“: str(session_dir / “code.py“), “code“: code}

これが Code reviewer エージェントです（簡略化され、エラー処理はありません）。

レビュアー = エージェント (
    model=“us.anthropic.claude-sonnet-4-5-20250929-v 1:0“,
    system_prompt=(
        「お客様は厳格なPythonコードレビュアーです。」
        「与えられたコードに対して、バグ、スタイル、提案という3つの箇条書きを返す。」
    ),
)

@app.entrypoint
def handler(event, context):
    session_id = getattr(context, “session_id“, None) or event.get(“session_id“)
    code_path = SHARED_DIR / session_id / "code.py"
    code = code_path.read_text()
    review = str(”reviewer(f ”Review this code:\n\n{code}”))

    return {”agent”: ”reviewer”, ”read”: str(code_path), ”review”: review}

各エージェントは、Strands Agents を使用する Python アプリケーションで、@app .entrypoint デコレータとお好みのモデルを備えています。それぞれを zip ファイルとしてパッケージ化します。今回は AWS マネジメントコンソールを使用します。AgentCore CLI、AWS コマンドラインインターフェイス (AWS CLI)、またはインフラストラクチャーアズコード (Infrastructure as Code) を使用することも可能です。

ステップ 1: 容量プロバイダーを作成します。

容量プロバイダーは、エージェントが実行される EC2 インフラストラクチャを定義します。AgentCore コンソールでは、左側のナビゲーションで [ランタイム] を選択し、次に [容量プロバイダー] タブと [容量プロバイダーの作成 ] を選択します。

名前を付けて、Operating system として Linux (64ビットARM) を選択し、許可するインスタンスタイプとして c7g.2xlarge を選択します。これにより、8 個の vCPU と16GiB のメモリが得られ、両方のエージェントを快適に並べて実行することができます。

さらに、ネットワークアクセス用に VPC 、サブネット、セキュリティグループを構成します。ストレージ構成では、デフォルトの gp3 ボリュームのままにします。[サービスアクセス] で [新しいサービスロールの作成] を選択し、私に代わって EC2 インスタンスを管理するインフラストラクチャロールをコンソールに作成させます。

[容量プロバイダーの作成] を選択し、数秒待ちます。ステータスが [アクティブ] に移動します。

容量プロバイダー設定の概要 (オペレーティングシステム、インスタンスタイプ、サブネット、セキュリティグループ、インスタンスプロファイル、インフラストラクチャーロール) に注意してください。作成後は説明のみを編集できるので、先に進む前に設定を確認してください。

ステップ 2: ランタイムを作成し、最初のエージェントをデプロイします。

「ランタイム」ページに戻り、「ランタイムの作成」を選択します。Name を入力し、Compute typeとしてインスタンスを選択し、前のステップで作成した容量プロバイダーを選択します。

[エージェントソース] で [S3 ソース] を選択し、次に [S3 にアップロード] を選択します。エージェントの zip ファイル (ACIDemoWriter.zip) を選択し、言語ランタイムを Python 3.13に設定し、 agent.pyをAgewnt entry pointとして指定します。これは@app .entrypointでデコレートした関数を含むファイルです。[権限] で [デフォルトロールの作成] を選択して、エージェントが必要とする IAM ロールをコンソールにプロビジョニングさせます。

「ランタイムを作成」を選択し、ステータスが「準備完了」になるのを待ちます。

コードレビュー担当者にも同じプロセスを繰り返します。2 番目のランタイムを作成し、同じ容量プロバイダーを選択し、レビューアーエージェントの zip ファイルをアップロードして、Ready になるのを待ちます。両方のエージェントは、基盤となる同じ EC2 インフラストラクチャを共有するようになりました。

コンソールには、エージェントをプログラムで呼び出すためのすぐに使用できる Python、TypeScript、JavaScript のスニペットを含む [呼び出しコードの表示] セクションが表示されます。ただし、このデモでは、組み込みのテスト機能を使用します。ライターエージェントのページで [テスト] を選択します。

ステップ 3: エージェントを呼び出し、コラボレーションを観察します。

ランタイムプレイグラウンドが開きます。上部には、「ランタイムエージェント」、「エンドポイント」、「セッションID」の 3 つのフィールドがあります。コンソールはセッション ID を自動的に生成します。レビュアーエージェントで再利用するのでメモしておきます。

入力フィールドに、ライターエージェントにコードを生成するように要求する JSON ペイロードを入力します。

{”prompt”: ”write a fibonacci suite”}

[実行] を選択します。数秒後、アウトプットパネルにエージェントの応答が表示されます。ライターエージェントは、フィボナッチ数列の 2 つの実装 (リストベースの関数とジェネレーター) を含む Python モジュールを生成し、それを /tmp/agentcore-session/ca5ec24d-07f5-4eeb-add1-5ba416bf9eb2/code.py に書き込みました。ファイルパスにあるセッション ID に注意してください。そのディレクトリは、このセッションの共有ファイルシステムです。

ステップ 4: 同じセッションでレビュー担当者エージェントを呼び出します。

次に、ランタイムエージェントのドロップダウンを ACIDEMoreViewer に切り替えます。重要な部分：同じセッションID（ca5ec24d-07f5-4eeb-add1-5ba416bf9eb2）をセッション ID フィールドに貼り付けます。これが 2 つのエージェントをつなぐものです。

簡単なプロンプトを入力します。

{”prompt”: ”review the code”}

[実行] を選択します。レビュー担当エージェントは、ライターが共有セッションディレクトリから作成したファイルを読み取り、詳細なコードレビューを返します。重大なバグは見つかりませんが、タイプヒントの追加、入力検証、エッジケース処理の簡略化を提案します。

2つのエージェントがメッセージを交換したり、互いの API を呼び出したりすることはありませんでした。彼らは、ランタイムインスタンスがセッション内で提供する共有ファイルシステムを介して共同作業を行いました。このパターンは、コードを実行するテストエージェント、README ファイルを生成するドキュメンテーションエージェント、脆弱性をスキャンするセキュリティエージェントなど、任意の数のエージェントに拡張できます。これらはすべて同じ作業ディレクトリを共有します。

主な詳細
始めるにあたって知っておくべきことがいくつかあります。

サポート対象 OS: ローンチ時はLinux (ARM64およびx86_64)。
セッションの持続性: セッションは最大 14 日間持続します。
ランタイム: ネイティブコードをサポートするPython 3.11-14。コンテナイメージもサポートされています。
GPU: GPU アクセラレーション対応のインスタンスタイプをサポートします。
統合: AgentCore Runtime と同じ AgentCore API、アイデンティティ、オブザーバビリティ、ポリシーコントロールを使用します。
料金: 標準の EC2 料金と AgentCore オーケストレーションの管理料金が加算されます。
地域: 米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、アジア太平洋 (ムンバイ、シンガポール、シドニー、東京)、ヨーロッパ (フランクフルト、アイルランド)

To get started, visit the runtime instance in 開始するには、Amazon Bedrock AgentCore documentation のランタイムインスタンスにアクセスし、最初の容量プロバイダーを作成してください。

– seb

原文はこちらです。

Amazon DynamoDB が、あらゆる規模でリアルタイムのベクトル検索をサポートするようになりました

Esra Kayabali — Fri, 07 Aug 2026 08:22:59 +0000

2026 年 8 月 5 日、 Amazon DynamoDB でのベクトル検索の一般提供についてお知らせします。運用データとともにベクトル埋め込みを DynamoDB に保存し、別のベクトルストアにデータを複製することなく、そのデータに対して直接類似度検索を実行できるようになりました。

DynamoDB は、99%以上の再現率を維持しながら、1桁ミリ秒のレイテンシーでネイティブなベクトル検索をサポートします。また、数兆個のベクトルを含む大規模なデータにも対応できるよう設計されています。サーバーのプロビジョニング、パッチ適用、管理は一切不要で、ソフトウェアのインストール、保守、運用も必要ありません。このサービスにはバージョンの管理がなく、メンテナンスウィンドウも設定されておらず、メンテナンスによるダウンタイムもゼロです。

ベクトルインデックスにはストレージ容量の制限がなく、データの増加に応じて水平方向にスケールします。DynamoDB のネイティブなベクトル検索を利用することで、エージェント型メモリ、検索拡張生成（RAG）、レコメンデーションエンジン、パーソナライズされたエクスペリエンス、異常検知など、セマンティック検索を必要とするアプリケーションを構築できるようになりました。

アプリケーションですでに DynamoDB を使用している場合、これまではベクトル検索を追加するために、データを専用のベクトルデータベースにコピーし、2つのサービス間でデータを同期するパイプラインを維持する必要がありました。これにより、運用上のオーバーヘッド、データ移動コスト、ライセンスコストが増加し、さらに大規模環境で予測可能な低レイテンシーを維持するという課題も生じていました。DynamoDB にベクトル検索が組み込まれているため、ベクトルデータと運用データを同じサーバーレスインフラストラクチャ上で管理し、同じ従量課金（リクエスト単位の課金）モデルを利用できます。

DynamoDB のベクトル検索では、ベクトル埋め込みを格納する属性に対して作成する新しいタイプのインデックスが導入されています。任意のモデル（Amazon Bedrock Titan Text Embeddings、Cohere Embed、OpenAI のテキスト埋め込みモデルなど）を使用して埋め込みを生成し、標準のPutItem呼び出しを使用して、浮動小数点数のリストとしてテーブルに保存できます。次に、その属性に対してベクトルインデックスを作成し、次元数、距離関数、およびクエリ実行時に検索結果を絞り込むためのフィルターとして使用する非ベクトル属性を指定します。SearchVectors API は、クエリベクトル、返される結果の数 (最大 100)、およびオプションのフィルター条件を受け入れます。類似度でランク付けされた結果を返します。

運用データがすでに DynamoDB に存在していて、別のデータベースをプロビジョニングしたり、同期パイプラインを管理したりせずに類似検索を追加したい場合は、DynamoDB のベクトル検索を使用してください。DynamoDB は完全にサーバーレスなので、ベクトル検索はインフラストラクチャを管理しなくても自動的にスケーリングされます。最大 4096 次元、ユークリッド、コサイン、ドット積の距離関数、およびインラインフィルタリングをサポートします。

DynamoDB でのベクトル検索入門
このチュートリアルでは、DynamoDB コンソールを使用して既存の DynamoDB テーブルにベクトル検索を追加する方法を示します。このシナリオには、製品カタログテーブルを備えたオンラインスポーツ用品店が含まれています。各アイテムには、 ProductID 、カテゴリ、説明、マーケットプレイス、名前、価格などの標準的な操作属性があります。目的は、セマンティック検索を追加することで、購入者が完全一致するキーワードではなく、自然言語によるクエリを使って商品を検索できるようにすることです。

1.DynamoDB テーブルを準備する
セマンティック検索を有効にするために、まずテーブルにすでに保存されている商品説明のベクトル埋め込みを生成します。埋め込みとは、機械学習モデルによって生成され、テキストの内容が持つ意味を捉えた数値表現です。説明が似ている2つの項目は、ベクトル空間上で互いに近い位置にある埋め込みを持つため、これによって類似度検索が可能になります。

Amazon Bedrock Titan Text Embeddings やその他の埋め込みモデルを使用して埋め込みを生成し、AWS マネジメントコンソール、AWS コマンドラインインターフェイス (AWS CLI)、AWS SDK、AWS CloudFormation、またはその他の IaC ツールを使用して、それらをテーブルに追加できます。

既存のProductCatalogのようなテーブルでは、UpdateItem呼び出しを使用して、各項目にdescriptionEmbeddingという新しい属性として埋め込みを追加します。DynamoDB は、既存の List データ型を使用してベクトル埋め込みを格納します。リストの各要素は、埋め込みベクトルの単一の浮動小数点数を表す数値です。つまり、既存の運用データの属性と一緒にベクトルを保存するために、新しいデータ型を導入したり、スキーマを変更したりする必要はありません。

2.ベクトルインデックスの作成
DynamoDBコンソールでProductCatalogテーブルを開き、インデックスタブを選択します。ベクトルインデックスを作成 を選択します。ベクトルインデックスを作成ページでは、次のようにインデックスの詳細を入力します。インデックス名としてProductDescriptionIndex、ベクトル属性としてdescriptionEmbeddingを入力します。

埋め込みモデルの出力と一致する次元数を入力し、距離関数としてコサインを選択します。コサインはベクトルの大きさではなく角度を測定する指標であり、そのためテキスト埋め込みの意味的類似性を比較するのに有効です。DynamoDB のベクトル検索では、コサインに加えて、ユークリッド距離 と ドット積の距離関数もサポートされています。

ユークリッド:購入回数などの数値でアイテムをクラスタリングする場合など、ベクトルの大きさが意味のある場合に使用します。
ドット積:方向と大きさの両方が重要な場合に使用します。たとえば、関心の位置合わせと周波数を一緒に重み付けするレコメンデーションシステムの場合などです。原則として、距離関数を埋め込みモデルのトレーニングに使用した関数と一致させると、精度が最も高くなります。

パーティションキーとしてマーケットプレイスに入ります。ベクトルインデックスのパーティションキーは、DynamoDB がベクトルを各パーティションにどのように分散配置するかを制御するものであり、予測可能な低レイテンシーを維持しながら、インデックスを水平スケールアウトできるようにします。各検索は1つのパーティションキー値を対象として実行されます。そのため、複数のマーケットプレイス向けの商品カタログであっても、インデックス全体をスキャンすることなく、特定のマーケットプレイスの在庫のみを検索できます。パーティションキーは必須ではありませんが、大規模なデータセットやクエリスループットが高いワークロードでは、使用することが推奨されます。

インラインフィルター属性を展開し、フィルター属性としてカテゴリを追加します。これにより、クエリ時に検索結果を特定の製品カテゴリに絞り込むことができます。フィルター条件では、完全一致の値のみサポートされます。BETWEEN や BEGINS_WITH のような範囲条件はサポートされていません。検索結果にすべてのテーブル属性が含まれるよう、属性の投影はすべてに設定したままにしています。ベクトルインデックスを作成 を選択し、インデックスのステータスが アクティブ に変わるまで待ちます。

3.ベクトル検索を実行
商品説明に使用したのと同じ埋め込みモデルを使用して、「夏用の軽量ランニングシューズ」などの自然言語検索用語からクエリベクトルを生成します。DynamoDB コンソールでは、左側のナビゲーションペインで 項目を検索を選択し、ProductCatalogテーブルを選択します。

検索を選択してベクトル検索モードに切り替えます。ベクトルインデックスを選択ドロップダウンからProductDescriptionIndex を選択し、クエリベクトルを検索ベクトルフィールドに貼り付け、結果の数 (上位 K) を 5 に設定します。パーティションキー値として US と入力して、検索範囲を米国のマーケットプレイスに限定します。 インラインフィルター属性を拡張し、カテゴリをフットウェアと同じに設定して、検索をフットウェア製品のみに絞り込みます。最後に、実行を選択します。

DynamoDB は、フットウェアカテゴリ内で意味的に最も類似している5件の商品を、類似度スコアの高い順に返します。また、そのレスポンスには、商品名や価格などの通常の運用データ属性もあわせて含まれます。類似度スコアの意味は、インデックスに選択した距離関数によって異なります。コサイン距離関数とユークリッド距離関数では、類似度スコア値が低いほど類似度が高く、スコアが 0 の場合はベクトルが同一であることを示します。点積距離関数では、類似度スコアの値が高いほど類似度が高くなります。

API の呼び出しやドキュメントの検索など、ベクトル検索をプログラムで操作するには、お好みの AI コーディングツールで AWS MCP サーバーとプラグインを試してください。詳細については、 Amazon DynamoDB 開発者ガイドをご覧ください。

今日から始めよう
Amazon DynamoDB のベクトル検索は、一般的に AWS GovCloud (米国) リージョンを含むすべての商用 AWS リージョンで利用できます。リージョンごとの提供状況や今後のロードマップについては、AWS のリージョン別提供機能にアクセスしてください。料金の詳細については、Amazon DynamoDB 料金表ページをご覧ください。

ぜひ 8 月 5 日から DynamoDB のベクトル検索をお試しください。ご意見やご要望は、Amazon DynamoDB の AWS re:Post、または通常ご利用の AWS サポート窓口までお寄せください。

– Esra

原文はこちらです。

AI Agent は “つながり” で進化する ─ Amazon Connect Customer × Salesforce MCP 連携

Hiroyoshi Umeda — Fri, 07 Aug 2026 03:53:57 +0000

統合されたアーキテクチャの「幅広さ」こそが、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 の日本語訳です。この記事はソリューションアーキテクトの梅田裕義が翻訳しました。