本記事は 2026 年 8 月 12 日 に公開された「 Introducing Oracle Exadata on Exascale for Oracle AI Database@AWS 」を翻訳したものです。 Oracle AI Database@AWS 向けに Oracle Exadata Database Service on Exascale Infrastructure (ExaDB-XS) が一般提供開始となりました。ExaDB-XS は、従量課金モデルで Exadata クラスのパフォーマンスと可用性を提供します。コンピューティングとストレージを小さな単位で個別にスケールでき、使用した分だけを支払います。専用インフラストラクチャを事前にプロビジョニングする必要はありません。AWS Marketplace のパブリックオファーまたはプライベートオファーで、最小 8 Elastic CPU (ECPU)、ストレージ 300 GB から始められます。 Oracle AI Database@AWS では、AWS アベイラビリティゾーン内で Oracle Exadata インフラストラクチャをネイティブに実行できます。AWS Marketplace から購入し、他のワークロードと並べて管理できます。Oracle Exadata や RAC のワークロードを再アーキテクチャなしで移行し、Oracle データベース資産を統合して、AWS の分析、AI、運用サービスに直接接続できます。データベースが AWS リージョン内で動作するため、AWS の幅広いサービスに低レイテンシーでアクセスできます。生成 AI と検索拡張生成 (RAG) には Amazon Bedrock、モニタリングとガバナンスには Amazon CloudWatch、AWS KMS、AWS IAM、AWS CloudTrail を利用できます。 お客様からは、専用インフラストラクチャのコストとコミットメントという壁なしに Exadata の機能を使いたいという声が寄せられていました。専用インフラストラクチャでは、開始時にデータベースサーバー 2 台とストレージサーバー 3 台が最低構成として必要で、初期投資は決して小さくなく、すべてのワークロードに見合うわけではありません。ExaDB-XS はこのコストとコミットメントの壁に直接応えます。RAC、Smart Scan、Hybrid Columnar Compression (HCC) を含む Exadata と同じパフォーマンス、可用性、セキュリティを、プールされた共有モデルで提供します。ECPU 単位、ギガバイト単位という小さな増分でスケールし、コンピューティングとストレージを個別に追加できます。大規模な初期インフラストラクチャのコミットメントなしに始めたい場合、新しい AWS リージョンへコスト効率よく拡張したい場合、容量効率の高い 高速なデータベースクローニング を活用したい場合、Exadata Database Service on Dedicated (ExaDB-D) のクロスリージョン災害対策スタンバイをコスト効率よく運用したい場合に適しています。 Oracle AI Database@AWS ポートフォリオにおける ExaDB-XS の位置づけ ExaDB-XS は Oracle AI Database@AWS ポートフォリオをあらゆる規模のワークロードに広げ、専用インフラストラクチャの下に空いていた領域を埋めます。同一の Exadata ハードウェア上で、Oracle のデプロイメント選択肢が一通り揃いました。 サービス モデル お客様にとってのメリット ExaDB-XS (新規) — Exadata on Exascale Infrastructure 共有・プール型の Exadata コンピューティングとストレージ上で、お客様が管理する VM クラスター コミットメントが必要な最低構成インフラストラクチャなしに、Exadata のパフォーマンスと機能をフルに利用できる OS とデータベースの制御は ExaDB-D と同じなので、移行時も勝手が変わらない 従量課金 — 小さく始めて、コンピューティングとストレージを個別にスケールし、使用した分だけ支払う Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D) 専用 Exadata インフラストラクチャ上で、お客様が管理する VM クラスター 最大規模かつ最も要求の厳しいワークロードに向けた Exadata のパフォーマンスとシングルテナント分離 OS とデータベースをフルに制御し、必要なとおりに Oracle を運用できる パッチ適用とバージョン更新のタイミングを自社で管理し、変更管理を完全にコントロールできる Oracle Autonomous AI Database on Dedicated Exadata (ADB-D) 専用 Exadata インフラストラクチャ上のフルオートノマスデータベース 専用環境による分離と最小の運用工数 — パッチ適用、チューニング、スケーリングは Oracle がオートノマス機能で処理 日々の DBA 作業から解放され、アプリケーションに集中できる メンテナンスウィンドウは自社のビジネスカレンダーに合わせて制御できる Oracle Autonomous AI Database Serverless (ADB-S) フルオートノマス、サーバーレス、マルチテナント フルマネージドかつサーバーレスで、運用負荷は最小限。オートノマス機能を備える エラスティックなサーバーレススケーリングで、使用した分だけ支払う 管理するインフラストラクチャをゼロにしたい場合に最適 ExaDB-XS では、共有・プール型インフラストラクチャ上で ExaDB-D と同等の制御性とデータベース管理の使い勝手が得られます。Exadata の価値を支える機能を諦めることなく、小規模ワークロードまでスケールダウンできる Exadata の経済性を利用できます。 ExaDB-XS の新機能 ExaDB-XS は、Oracle Cloud Infrastructure (OCI) で利用できる Oracle Exascale の全機能と、Oracle AI Database@AWS がサポートする AWS 統合をリリース時点から備えています。つまり初日から本番ワークロードを ExaDB-XS に移行でき、最も重要な Oracle データベースに求められるセキュリティ、運用、コンプライアンスの機能もそのまま利用できます。以下の 3 つのセクションでは、ExaDB-XS が Oracle AI Database@AWS に追加する主な新機能を説明します。 コンピューティングとストレージのエラスティックなスケーリング ExaDB-XS はインフラストラクチャレベルでコンピューティングとストレージを分離します。まず、Exadata インテリジェントストレージを共有する単一の論理プール、Exascale Storage Vault をプロビジョニングします。次に 1 つ以上の VM クラスターをプロビジョニングし、Exadata のデータベース最適化コンピューティングの共有プールからコンピューティングを、Storage Vault からストレージを割り当てます。専用デプロイメントで使う Automatic Storage Management (ASM) ディスクグループとは異なり、Storage Vault は自動的にスケールし、オブジェクト単位で高冗長性を自動適用するため、ディスクグループの設計や容量分割は不要です。1 つの Storage Vault が複数の VM クラスターに対応できるので、ストレージはコンピューティング間で共有しつつ、ワークロード間の分離は保たれます。 コンピューティングは ECPU、ストレージは GB を単位とします。VM クラスターは 8 ECPU、ストレージ 300 GB から開始でき、その後はワークロードの変化に応じて各項目を個別に調整できます。スケーリングは AWS マネジメントコンソール、AWS Command Line Interface (AWS CLI)、AWS API から実行できます。 即時シンクローニング ExaDB-XS では、Oracle AI Database@AWS でシンクローニングが使えるようになります。redirect-on-write 技術により、ストレージを複製せずにデータベースの即時コピーを作成できます。クローンを作成すると、Storage Vault 内の元のデータブロックへのポインタが作られます。クローンは完全に独立したデータベースとして見え、そのように動作しますが、作成直後は追加のストレージを消費しません。ストレージを消費するのは、クローン内のデータがソースから変化した分だけです。シンクローニングは、読み取り/書き込みデータベース、読み取り専用データベース、プライマリおよびスタンバイデータベース、プラガブルデータベース、さらには既存クローンのクローンでも機能します。 本番データに対して 10 本の開発ブランチを並行して動かすチームは、フルコピー 10 個分ではなく、データベース 10 個分の変更量に対して支払います。自動化された継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインの一部として新しいデータベースクローンをプロビジョニングし、テスト完了後に破棄することもできます。 初日から使える AWS サービス統合と AI 対応 ExaDB-XS は、Oracle AI Database@AWS で利用できる AWS サービス統合をリリース時点からすべて備えています。データベースの自動バックアップは Amazon Simple Storage Service (Amazon S3) に保存されます。AWS KMS がカスタマー管理キーによる暗号化を担います。Amazon CloudWatch と Amazon EventBridge がメトリクスとイベントのモニタリングを提供します。AWS IAM がアクセスを制御し、AWS CloudTrail が API 監査ログを記録します。ネットワーク接続の選択肢には AWS Transit Gateway、Amazon VPC Lattice、AWS Cloud WAN があります。ExaDB-XS は AWS Secrets Manager とも統合されており、作成/更新操作時にデータベースと Oracle Database Vault のパスワードをマネージドシークレットから安全に渡せます。機密性の高い認証情報をスクリプトや設定ファイルに置く必要がなくなります。 ExaDB-XS では、次世代の AI アプリケーションやエージェント型アプリケーションの中心に Oracle データベースを据えられます。Oracle AI Database 26ai では、AI Smart Scan が AI Vector Search を Exadata インテリジェントストレージにオフロードします。ベクトル検索と検索拡張生成 (RAG) は、分析やオンライントランザクション処理 (OLTP) を高速化するのと同じストレージ側のインテリジェンスを使い、運用データ上で動作します。データベースが AWS リージョン内で動作するため、生成 AI やエージェント向けの Amazon Bedrock、Amazon Bedrock AgentCore といったサービスをすぐ隣で利用できます。AI エージェントやアプリケーションは、最も価値あるビジネスデータを移動も複製もせずに低レイテンシーで利用できます。 ExaDB-XS を使い始める ExaDB-XS は AWS Marketplace から、セルフサービス調達のパブリックオファーまたは個別交渉のプライベートオファーで利用できます。License Included (全オプション付きの Oracle Enterprise Edition) と Bring Your Own License (BYOL) の両方に対応しています。以下では AWS マネジメントコンソールで最初の ExaDB-XS 環境を作成する手順を説明します。AWS CLI と CloudFormation の手順は Oracle AI Database@AWS のドキュメントを参照してください。 ステップ 1: ODB ネットワークを作成する Oracle AI Database@AWS を初めて使う場合は、まず ODB ネットワークを作成します。ODB ネットワークは、AWS アベイラビリティゾーン内で Oracle インフラストラクチャをホストするプライベートで分離されたネットワークです。AWS マネジメントコンソールで Oracle AI Database@AWS に移動し、[ODB Networks]、[Create ODB network] の順に選択します。アベイラビリティゾーン、クライアント接続とバックアップ接続用の Classless Inter-Domain Routing (CIDR) 範囲を指定し、必要に応じて Amazon S3 バックアップと Amazon Redshift ゼロ ETL 接続をネットワーク上で設定します。既存の Exadata Dedicated デプロイメントの ODB ネットワークがある場合は、その同じネットワークに ExaDB-XS リソースをプロビジョニングできます。 図 1: クライアントサブネットとバックアップサブネットの範囲を指定して ODB ネットワークを作成する 図 2: ODB ネットワークのサービス統合を設定する ステップ 2: Exascale Storage Vault を作成する Storage Vault は、VM クラスターが容量を割り当てて使うプール型ストレージリソースです。コンソールで [Exascale Storage Vaults] に移動し、[Create Storage Vault] を選択します。初期ストレージ容量を GB で指定し、Storage Vault を ODB ネットワークに関連付けます。作成後はいつでも容量を拡張できます。 図 3: Exascale Storage Vault を作成しストレージ容量を設定する ステップ 3: Exascale VM クラスターを作成する Storage Vault を用意したら、[VM Clusters] に移動して [Create VM Cluster]、[Exascale] の順に選択し、VM クラスターを作成します。ECPU 数 (VM あたり最小 8)、GB 単位のストレージ割り当て (合計最小 300 GB)、Oracle Database のバージョン (19c または 26ai)、ライセンスタイプを指定します。あわせて ODB ネットワークを選択し、VM へのアクセスに使う Secure Shell (SSH) キーペアを指定します。 図 4: Exascale VM クラスターの一般設定と構成を確認する 図 5: 作成前に VM クラスターの接続設定と診断設定を確認する ステップ 4: Oracle データベースを作成する VM クラスターの準備ができたら、AWS マネジメントコンソールで VM クラスターの詳細ページに移動し、[Manage in OCI] を選択します。OCI コンソールが開き、そこで Oracle データベースを作成、管理します。Oracle Database のバージョンを選択し、Amazon S3 バケットへの自動バックアップを設定して、データベースを作成します。インフラストラクチャリソース (Storage Vault、VM クラスター、ODB ネットワーク) は AWS マネジメントコンソールと AWS API の両方から引き続き参照、管理できます。 図 6: OCI コンソールで VM クラスターから Oracle データベースを作成する 料金 ExaDB-XS の料金は従量課金です。VM クラスターが消費した ECPU とストレージに対して支払い、最低インフラストラクチャコミットメントはなく、1 秒あたりの I/O 操作数 (IOPS) への個別課金もありません。License Included と Bring Your Own License の両方が利用できます。料金は OCI 上の Oracle Exadata Database Service on Exascale Infrastructure と同じです。最新の単価は Oracle AI Database@AWS の料金ページ を参照してください。 知っておきたいこと 提供リージョン。 ExaDB-XS は、Oracle AI Database@AWS が利用可能な 22 の AWS リージョンすべてで利用できます。米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、米国西部 (北カリフォルニア)、カナダ (中部)、南米 (サンパウロ)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (ミラノ)、欧州 (パリ)、欧州 (スペイン)、欧州 (ストックホルム)、欧州 (チューリッヒ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (ムンバイ)、アジアパシフィック (大阪)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (東京)、オーストラリア (メルボルン)、オーストラリア (シドニー) です。 Storage Vault の容量。 Exascale Storage Vault は 1 つあたり最大 100 TB のインテリジェントストレージに対応します。それ以上の専用容量が必要な場合は、同じ ODB ネットワーク内で Oracle Exadata Database Service on Dedicated Infrastructure も併用できます。 データベースバージョン。 リリース時点では Oracle Database 19c と 26ai をサポートしています。対応バージョンは今後追加していく予定です。 モニタリング。 ExaDB-XS のリソースは AWS/ODB 名前空間で Amazon CloudWatch にメトリクスを発行します。AWS CloudTrail は API 呼び出しを記録します。Amazon EventBridge のルールを設定して、プロビジョニング完了、パッチ適用、スケーリング操作といったデータベースのライフサイクルイベントに対する自動応答をトリガーできます。 今日から始める ExaDB-XS は、世界中の Oracle AI Database@AWS 対応 22 リージョンすべてで本日から利用できます。 Oracle AI Database@AWS のサービスページ を確認するか、AWS マネジメントコンソールで Oracle AI Database@AWS に移動し、 [Create Storage Vault] を選択して始めてください。 詳細は Oracle AI Database@AWS ドキュメントの Exascale セクション、または以下のリソースを参照してください。 Oracle AI Database@AWS ドキュメント Oracle Exadata on Exascale ドキュメント (OCI) Oracle AI Database@AWS の料金 著者について Karthik Gopalakrishnan Amazon Web Services のシニアプロダクトマネージャーです。Oracle AI Database@AWS のプロダクトマネジメントを担当しています。 Jobin Joseph Jobin はトロントを拠点とするシニアデータベーススペシャリストソリューションアーキテクトです。リレーショナルデータベースエンジンを専門とし、お客様のデータベースワークロードの AWS への移行とモダナイゼーションを支援しています。Oracle Certified Master であり、Oracle データベースの経験は 25 年以上に及びます。 この記事は Solutions Architect の 矢木 覚が翻訳しました。

本記事は 2026 年 7 月 23 日 に公開された「 Evaluating AI Agents: A production blueprint with Strands and AgentCore 」を翻訳したものです。 本記事は、Motorway および AWS Prototyping and AI Customer Engineering (PACE) チームと共同で執筆しました。 英国を拠点とするオンライン中古車マーケットプレイスの Motorway は、最大 8,000 のディーラーが最大 2,500 台の車両に入札する日次オークションを運営しています。Motorway は AWS Prototyping and AI Customer Engineering (PACE) と協力し、AI を活用したディーラー向け在庫検索エージェントを構築しました。このエージェントによって、ディーラーの車両の探し方は大きく変わり、何時間もかかっていた手作業のフィルタリングが自然言語での問い合わせに置き換わりました。 課題 エージェントは自信ありげな応答を返します。しかし、実際のお金がかかっている状況で、それが確実に機能すると、どうやって証明すればよいのでしょうか。 ツール選択の誤り は誤った検索結果を招き、ディーラーの信頼を損ないます。 セマンティック検索の誤解釈 は、無関係な結果を返します。「5 年落ちまでのガソリン車、ハイブリッド車、電気自動車」のような問い合わせでは、エージェントが複数の条件を正しく解釈する必要があります。 複数ターンの会話での コンテキストのずれ は、ディーラーが絞り込んだ条件を失わせます。 非決定的な出力 は、1 回だけのテストを信頼できないものにします。 解決策 Motorway と AWS は共同で、エンドツーエンドの評価パイプラインを構築しました。その結果、誤った結果は 8 件に 1 件から 50 件に 1 件へと減り、問題の検知にかかる時間は数時間から数分に短縮されました。 このパイプラインは、Strands Agents SDK と Amazon Bedrock AgentCore を組み合わせています。AgentCore は、AI エージェントを大規模にデプロイして運用するためのフルマネージドサービスです。本記事では、自分のエージェント向けにこのパイプラインを構築する方法を紹介します。 2 段階の評価戦略 。ビルド時のテスト (Strands Agents 向けのオープンソース評価ライブラリ strands-agents-evals を使用) と、本番環境での監視 ( Amazon Bedrock AgentCore Evaluations を使用) にまたがります。 ツールの使い方、推論、出力品質を評価する 3 層のフレームワーク 。 品質ゲートを備えた 5 段階のデプロイパイプライン 。指標がしきい値を下回るとリリースをブロックします。 付属のリポジトリ には、自分のエージェントに合わせて調整できる、デプロイ可能な設計図が含まれています。この設計図は AWS のサービスを使っていますが、その中核となる原則は、本番運用に耐える AI エージェントであればどのようなシステムでも必要となる、システムに依存しない要件です。原則には、3 層の評価フレームワークと、一貫性を測る pass^k 指標の利用が含まれます。 前提条件 本記事の手順を進めるには、次の前提条件を満たす必要があります。 Amazon Bedrock 、 AWS Lambda 、 Amazon Simple Storage Service (Amazon S3) 、 Amazon DynamoDB 、 Amazon EventBridge 、 Amazon CloudWatch 、 Amazon Simple Notification Service (Amazon SNS) の権限を持つ AWS アカウント 。 インストールおよびブートストラップ済みの AWS Cloud Development Kit (AWS CDK) v2。 Python 3.14 以降。 Amazon Bedrock のモデルアクセス を通じた、Anthropic Claude モデルと Amazon Titan モデルへのアクセス。 Python、AWS CDK、およびエージェントの概念 (ツール呼び出し、複数ターンの会話) に関する知識。 所要時間: 初回デプロイに 30〜45 分、自分のドメインに合わせたカスタマイズに 2〜3 時間。 想定コスト: サンプルの評価スイートの実行には、Amazon Bedrock の推論料金として約 5〜10 USD かかります。本番環境の監視コストは、サンプリングレートによって変わります。 セキュリティに関する注記: 付属のリポジトリは、最小権限の AWS Identity and Access Management (IAM) ロールを実装し、API キーを (環境変数ではなく) AWS Systems Manager Parameter Store に保存し、型付きパラメータを使ってインジェクション攻撃を防ぎやすくしています。詳細は リポジトリの README を参照してください。 実例: ディーラー向け在庫検索エージェント Motorway は、ディーラー向け在庫検索エージェントを Strands Agents SDK と Amazon Bedrock AgentCore の上に構築しました。このエージェントは 8 つのツールを公開しており、89 を超える車両属性にわたる構造化フィルタリングと、 LanceDB および Amazon Titan Text Embeddings V2 によるベクトル類似検索を組み合わせています。 これまでディーラーは、CSV と融通の利かないフィルターを使って、何時間もかけて在庫リストを見て回っていました。対話型の AI エージェントの導入により、ディーラーはエージェントに話しかけられるようになりました。たとえば「近くのディーラーにある 2 万 5,000 ポンド以下のディーゼル SUV を探して」や「家族向けのスポーティなオートマ車」のように問いかけます。 ピーク時には約 1,500 人が同時に利用するため、エージェントの挙動を正しくすることは避けて通れません。ツール選択の誤りやセマンティック検索の誤解釈は、ユーザーの信頼に直接影響します。図 1 は、エンドツーエンドのリクエストの流れを示しています。ディーラーは Web インターフェイスから自然言語の問い合わせを送信し、それが Amazon Bedrock AgentCore Runtime にルーティングされます。ランタイムは、Amazon Bedrock のモデル (推論には Claude、埋め込みには Amazon Titan) を使いながら、8 つの異なるツールへの呼び出しを調整します。ツールからの応答はランタイムを経由して戻り、ディーラーに提示する最終的な結果を生成します。 エージェントの評価が異なる理由 大規模言語モデル (LLM) の評価は、テキスト生成の品質、つまり一貫性、事実の正確さ、応答の関連性に注目します。一方、エージェントの評価は、それとは根本的に異なるものを見ます。こう考えるとわかりやすいでしょう。LLM の評価はエンジンの性能を調べるものです。エージェントの評価は、渋滞のなか、雨のなか、あるいは後部座席が乗客でいっぱいのときに、車全体がどう走るかを見るものです。 従来の LLM の指標では、Motorway のエージェントが「グレード 1 の Suzuki のモデル」に対して正しい検索ツールを呼び出したかどうかはわかりません。エージェントが LanceDB に正しいフィルターパラメータを渡したかどうかも明らかになりません。さらに、前のターンの結果を絞り込むディーラーが正しい応答を得られたかどうかも見落とします。 評価の観点 エージェントにとって重要な理由 タスクの完了 エージェントは複数ステップのワークフローを実行し、部分的な完了がよく起こる ツール使用の正確さ 誤ったツールや不正なパラメータは、ワークフロー全体を狂わせる 推論の一貫性 推論に欠陥があると、条件が変わったときに予測できない失敗につながる 信頼性と一貫性 非決定性により、同じ入力でも異なる結果が生じうる 安全性とコンプライアンス 自律的なエージェントは、現実に影響を与える行動をとりうる コストと効率 1 タスクあたり 50 回の API 呼び出しを要するエージェントは、経済的に成り立たないことがある 「7〜12 年落ちの Volkswagen Golf」のような正確な問い合わせは完璧に動くかもしれません。しかし、「古めの VW を探している」のような口語的な言い回しは、セマンティック検索の層が適切に評価されていないと失敗することがあります。 strands-agents-evals でデプロイ前に問題を検出する この設計図は、 GenAIOps のライフサイクルに対応する 2 つのフェーズで評価を実装します。ビルド時の評価はデプロイ前に問題を検出し、本番環境での評価は合成テストが見落とすものを捉えます。次の図 (図 2) は、ツールの使い方、推論、出力品質の各層が、デプロイ前にすべて合格しなければならないことを示しています。このフレームワークは、エージェントを 3 つの層で評価します。 レイヤー 1 (ツールの使い方) は、正しいツール選択とパラメータの受け渡しを、95% 超のしきい値で検証します。 レイヤー 2 (推論) は、論理的な意思決定を、85% 超のしきい値で評価します。 レイヤー 3 (出力品質) は、応答の有用性と正確さを、90% 超のしきい値で測定します。デプロイを進めるには、3 つの層すべてが合格する必要があります。 開発時、および継続的インテグレーションと継続的デプロイ (CI/CD) の際、パイプラインは strands-agents-evals フレームワークを使ってデプロイ前に問題を検出します。このフレームワークは、出力の検証、軌跡 (trajectory) の評価、複数ターンの会話のシミュレーション、実験の自動生成を提供します。いずれも、Strands Agents SDK 上に構築されたエージェントとネイティブに連携するよう設計されています。フレームワークは、3 つの基本要素 (プリミティブ) を提供します。 Experiment : エージェントに対して実行するテストケースの集まり。 Case : 入力の問い合わせ、期待される出力、期待されるツールの軌跡。 Evaluator : 採点ロジック (決定的、または LLM ベース)。 テストは層に分けて構成します。レイヤー 1 では、ツール選択の正確さを測る決定的なコードベースの採点器を実行します。レイヤー 2 と 3 では、推論と出力品質のために LLM-as-judge の評価器 (LLM を使ってエージェントの出力を採点する方式) を使います。 独自の Evaluator サブクラスは、ドメイン固有の関心事に対応します。Motorway のエージェントの場合、データの鮮度、ディーラー単位のスコープ、安全性のガードレールをカバーします。あなたのエージェントには、それ独自のドメイン制約があるはずです。 3 種類の採点器 評価フレームワークは 3 種類の採点器を使い、それぞれ異なる評価ニーズに適しています。 採点器の種類 レイヤー 測定する対象 トレードオフ コードベースの決定的採点 レイヤー 1 ツール選択、パラメータの受け渡し、軌跡の順序 高速、低コスト、再現可能 LLM-as-judge (Claude Sonnet 4.6) レイヤー 2〜3 推論の品質、出力の有用性、目標の達成 柔軟だが非決定的 (pass^k で制御) 人によるレビュー キャリブレーション エッジケースと安全性 コストが高く、LLM 判定のプロンプトの調整に使う 実際には、エージェントがたどった経路を採点するよりも、エージェントが生成した結果を採点する方が、多くの問題を見つけられます。重要なのは、ユーザーが関連性の高い結果を得られたことであって、エージェントが最初にどのツールを呼び出したかではありません。 3 層の評価フレームワーク ビルド時の評価は、3 つの異なる層で動作し、それぞれに固有の合否しきい値があります。 レイヤー 1: ツールの使い方 (しきい値 95% 超)。 エージェントは正しいツールを、正しいパラメータで呼び出したか。 「7,000〜20,000 ポンドのディーゼル車」は、型付きフィルター ( fuel_type=diesel 、 min_price=7000 、 max_price=20000 ) を指定して search_vehicles を使うべきです。 「走行距離の少ない新しめのハッチバック」は、セマンティックな埋め込みと構造化フィルターを組み合わせた hybrid_search を呼び出すべきです。 これは決定的に測定できます。 ToolSelectionGrader がどのツールを呼び出したかを確認し、 TrajectoryOrderGrader が呼び出しの順序を検証します。 レイヤー 2: 推論 (しきい値 85% 超)。 意思決定のプロセスは論理的だったか。strands-agents-evals の HelpfulnessEvaluator と TrajectoryEvaluator は、LLM-as-judge による採点を使い、エージェントの推論が筋の通ったものかを評価します。論理的でない推論で正しい応答にたどり着くエージェントは、条件が変わると予測できない形で失敗します。 レイヤー 3: 出力品質 (しきい値 90% 超)。 応答は有用で、正確で、実行に移せるものだったか。strands-agents-evals の OutputEvaluator と GoalSuccessRateEvaluator は、LLM-as-judge による評価を使い、ユーザーが有用で整った形式の応答を得られたかを評価します。 3 つの層は、デプロイ前にすべて合格する必要があります。いずれかの層で失敗すると、パイプラインはブロックされます。 非決定性への対処 LLM の出力は実行のたびに変わるため、1 回だけの試行の結果は誤解を招くことがあります。付属リポジトリの run_all_layers() 関数は、これに対処するために num_trials パラメータを受け取ります。コード生成の研究コミュニティ発の 2 つの指標が、信頼性の測定に役立ちます。 pass@k は、k 回の試行で少なくとも 1 回成功する見込みを測ります。正しい解を 1 つ見つければ十分な場合に役立つ指標です。 pass^k (pass の k 乗) は、k 回連続で成功する確率を測ります。ユーザーが毎回信頼できる挙動を期待する場合に役立つ指標です。 顧客向けのエージェントでは、pass^k が最も重要です。1 試行あたりの成功率が 75% のエージェントは、3 回連続で合格する確率がわずか 42% (0.75³) しかありません。ユーザーは、やり取りのたびに一定の品質を期待します。 付属のコードでは、 run_all_layers(task_fn, registry, num_trials=5) が複数試行に対応して評価の各層を実行し、pass^k でデプロイをゲートします。 実装の全体 を参照してください。 テストケースの管理 テストケースはカテゴリ別に整理します。 ハッピーパス : 成功するはずの一般的な問い合わせ。 エッジケース : 曖昧な問い合わせ、スラング、複数ターンでの絞り込み。 安全性/ガードレール : エージェントが拒否または誘導し直すべき問い合わせ。 本番環境の監視で問題を検出すると、そのやり取りが新しいテストケースになります。Motorway のスイートは、当初の 50 ケースから 3 か月で 150 ケースに増え、いずれも実際のユーザーの行動に基づいています。まずは 20〜50 ケースから始め、本番データでスイートを育てていきましょう。 エージェントが特定のツールを呼び出す べきでない ネガティブケースも含めます。たとえば、プロフィールの問い合わせは、検索ツールではなくプロフィールツールを呼び出すべきです。構造化された問い合わせは、生の SQL へのフォールバックではなく構造化検索を使うべきです。一方向だけの評価は、一方向だけの最適化を生みます。 複数ターンの会話のテスト 単一ターンの評価は、重要な観点、すなわち会話の一貫性を見落とします。ディーラーは、複数のターンにわたって自然に検索を絞り込んでいきます。 ターン 1: 「ディーゼルの SUV を探して」 ターン 2: 「次は、オートマだけを見せて」 ターン 3: 「かわりにステーションワゴンはどう?」 strands-agents-evals フレームワークは、現実的な複数ターンのやり取りを生成する ActorSimulator と、ターンをまたいだコンテキストの保持を採点する InteractionsEvaluator  を提供します。複数ターンのテストは、単一ターンのテストが見落とす、コンテキストのずれ、フィルターの累積エラー、代名詞の解決の失敗を捉えます。 AgentCore Evaluations で本番環境の挙動を監視する Strands Agent を Amazon Bedrock AgentCore Runtime にデプロイすると、 AgentCore Evaluations が継続的な監視を提供します。OpenTelemetry の計装 (業界標準の可観測性フレームワーク) を通じて Strands Agents と統合します。図 3 は本番環境でのアーキテクチャを示しており、可観測性のトレースは 1〜5% でサンプリングされ、指標は Amazon CloudWatch に集約されます。 2 つの監視アプローチ AgentCore Evaluations は、互いに補完し合う 2 つのモードを提供します。 オンデマンド評価 は、Amazon CloudWatch のログからスパンを選択して、特定のエージェントのやり取りを分析します。問題のデバッグや修正の検証に役立ちます。 オンライン評価 は、稼働中のトラフィックを自動的にサンプリングし、バックグラウンドで評価器を適用します。サンプリングレートを設定し (1〜5% を推奨)、最大 10 個の評価器を選んで、あとは実行させておきます。 組み込みの評価器とカスタム評価器 AgentCore は、一般的なシナリオ向けにあらかじめ構成された評価器を提供します。次の表は、組み込みの評価器と、それぞれが測定する対象を示しています。 評価器 レベル 測定する対象 Builtin.Helpfulness TRACE エージェントの応答がどれだけ有用か (7 段階で 0〜1 のスコア) Builtin.GoalSuccessRate SESSION ユーザーの全体的な目標が達成されたかどうか Builtin.ToolSelection TOOL_CALL エージェントが適切なツールを選択したかどうか Builtin.Correctness TRACE 応答の事実としての正確さ ドメイン固有の要件には、LLM-as-a-judge の構成を使ってカスタム評価器を作成できます。どのエージェントにも、組み込みの評価器がカバーしないドメイン制約があります。たとえば、データの鮮度、アクセスのスコープ、禁止された行動、レイテンシーの予算、コストの上限などです。 付属のリポジトリには、調整して使える 5 つのカスタム Evaluator サブクラスが含まれています。 評価器 検証する対象 DataFreshnessEvaluator オークションサイクルのタイムスタンプを検証し、エージェントが古い在庫を提示しないようにする SafetyGuardrailEvaluator エージェントが自動入札の操作を試みるのをブロックする DealerDataScopingEvaluator データ分離のために、ディーラー単位にスコープされた問い合わせを強制する LatencyEvaluator と CostEvaluator の例は、 付属のリポジトリ を参照してください。 追跡すべき主要な指標 付属のリポジトリには、CloudWatch のダッシュボードとアラームをプロビジョニングする AWS CDK スタックが含まれています。エージェントの健全性を監視するために、次の指標を追跡してください。 指標 目標 アラートのしきい値 タスク完了率 >95% <80% ツール選択の正確さ >95% <90% 有用性スコア (0〜1) >0.83 <0.58 応答レイテンシー P50 / P99 <2s / <10s >5s / >15s ハルシネーション率 <2% >5% やり取りあたりのコスト 傾向を監視 ベースラインの 2 倍超 品質チェックをデプロイのゲートにする 評価は、後回しにするものではなく、デプロイパイプラインの品質ゲートにすべきです。図 4 は、評価ゲートを備えたデプロイパイプラインを示しており、ビルド時の評価、ステージングでの検証、シャドウモード、A/B テスト、本番環境へのロールアウトにまたがります。失敗するとデプロイはブロックされます。 デプロイパイプラインは、5 つのフェーズで進みます。 ビルド時の評価 : ユニットテスト、ツールの正確さ ( ToolSelectionGrader 95% 超)、軌跡のテスト、LLM-as-judge による採点 ( HelpfulnessEvaluator 85% 超)。 ステージングでの検証 : ステージングデータに対する合成トラフィックを使った、オンデマンドの AgentCore 評価。 シャドウモード : 実際の本番トラフィックを、ユーザーに影響を与えずに並行して処理します。2% の乖離しきい値を設定し、少なくとも 4 時間実行します。 A/B テスト : 稼働中のトラフィックの 5% を候補のエージェントにルーティングし、実際の結果を測定します。 本番環境へのロールアウト : 継続的なオンライン評価と監視のもとで、トラフィックの 100% を移行します。 各フェーズにしきい値を定義します。ツール選択の正確さが 95% を下回るか、タスク完了率が 80% を下回ると、デプロイはブロックされます。大きなリリースでは、 num_trials=5 による複数試行の評価が pass^k でゲートし、非決定的な失敗を捉えます。 シャドウモード ステージングと本番環境の間で、候補のエージェントを、ユーザーに影響を与えずに実際の問い合わせに対して実行します。 シャドウモード は、本番トラフィックの複製を受け取り、候補のエージェントで並行して処理し、結果を比較します。A/B テストに進む前に、シャドウモードを少なくとも 4 時間実行してください。デプロイを自動的に一時停止する乖離しきい値 (2% が良い出発点です) を定義します。 シャドウモードは、ほかの段階が見落とす問題を捉えます。 同時負荷のもとでのタイムアウト処理。 合成テストに含まれていないドメイン用語。 実際のトラフィックパターンのもとでレイテンシーの急増を引き起こす、ツール呼び出しの順序。 始め方: 段階的なアプローチ フェーズ 1: テストスイートを作る。 実際のユーザーの問い合わせから抜き出した 20〜50 個のテストケースから始めます。ポジティブケースとネガティブケースの両方を含めます。エージェントが行うべきことと、拒否すべきことの両方をテストします。 フェーズ 2: ビルド時の評価を構成する。 採点器の種類を、測定する対象に合わせます。ツール選択には決定的な採点を、推論と出力品質には LLM-as-judge を使います。 フェーズ 3: 本番環境の監視を有効にする。 AgentCore Evaluations を 1〜5% のサンプリングレートで構成します。低めから始め、評価器のコストが許容範囲だと確認できたら引き上げます。 フェーズ 4: フィードバックループを閉じる。 本番環境の失敗をテストケースに変えます。失敗がリグレッションテストになると、このフィードバックループは、複数のチームで一貫して評価品質を高めてきました。 成果とインパクト この評価パイプラインを導入する前、エージェントのツール選択の正確さは 87% でした。つまり、ディーラーの問い合わせ 8 件に 1 件は誤った結果を返していたことになります。本番環境のインシデントは月に 12 件発生しており、ディーラーに影響が出始めてから問題を検知するまで、平均 4 時間かかっていました。 パイプラインを導入した後の結果は次の通りです。 指標 導入前 導入後 ツール選択の正確さ 87% 98% タスク完了率 82% 96% コンテキストの保持 (複数ターン) 71% 94% 本番環境のインシデント (月次) 12 2 問題検知までの平均時間 数時間 数分 ビジネス面のインパクトとして、ディーラーは車両の検索を数時間ではなく数分で完了できるようになり、結果が正確で最新であるという確信も得られています。 トラブルシューティング 軌跡の採点器の失敗、LLM-as-judge のばらつき、評価結果が空になる問題、コストしきい値の調整など、よくある問題の解決策は、 付属リポジトリの README を参照してください。 重要なポイント 評価パイプラインを構築するときは、次の原則を念頭に置いてください。 評価を層に分ける : ツールの使い方 (95% 超)、推論 (85% 超)、出力品質 (90% 超) は、それぞれ異なる失敗パターンを捉えます。 単一試行ではなく pass^k でゲートする : 1 試行あたりの成功率が 75% でも、3 回連続では信頼性が 42% しかありません。 本番環境の失敗をテストケースに変える : 実際のユーザーの行動で評価スイートを育てましょう。 シャドウモードは合成テストが見落とすものを捉える : 実際のトラフィックは、タイムアウト処理、まれな用語、レイテンシーのパターンを明らかにします。 監視は 1% のサンプリングから始める : 評価器のコストを管理するために、少しずつ拡大します。 まとめ ここまで、Motorway のディーラー向け在庫検索エージェントを実例として、AWS 上で本番運用の AI エージェント向けの評価パイプラインを構築する方法を見てきました。 核心となる教訓は、流暢な応答は、エージェントが正しいことをした証拠にはならないということです。ツールの選択、パラメータの正しさ、推論の一貫性、そして繰り返し実行したときの安定性を検証する必要があります。strands-agents-evals によるビルド時のテストと、AgentCore Evaluations による本番環境の監視を組み合わせることで、エージェントが設計通りに動くという裏付けを持ってデプロイできます。 これらのパターンは、複数のツールを使う顧客向けエージェントの多くに当てはまります。ナレッジベースやチケットシステムに問い合わせるカスタマーサービスのエージェント、ポートフォリオデータや市場フィードを取り込む金融アドバイザリーのエージェント、患者記録やスケジュール調整ツールにアクセスするヘルスケアのトリアージエージェントなど、いずれにも適用できます。 まずは次の手順から始めます。 付属のリポジトリをクローンします。 git clone https://github.com/aws-samples/sample-evaluating-agents-on-aws-with-strands-and-agentcore CDK プロジェクトのディレクトリに移動します。 cd sample-evaluating-agents-on-aws-with-strands-and-agentcore/examples/vehicle-auction-agent/cdk サンプルのインフラをデプロイします。 リポジトリの README のデプロイ手順 に従って、サンプルのインフラをデプロイします。デプロイが完了したら、AWS CloudFormation コンソールですべての AWS CloudFormation スタックが CREATE_COMPLETE の状態になっていることを確認し、インフラを検証します。CloudWatch のダッシュボードと Lambda 関数が、それぞれのコンソールに表示されているはずです。 サンプルの評価スイートを実行します。 付属のテストケースに対して実行し、3 層のフレームワークが動く様子を確認します。成功したかどうかは、レイヤー 1 (ツールの使い方) の合格率が 95% 超、レイヤー 2 (推論) が 85% 超、レイヤー 3 (出力品質) が 90% 超になっていることで確認します。いずれかの層が失敗した場合は、CloudWatch のログで詳細なエラーメッセージを確認してください。 評価器を自分のドメインに合わせてカスタマイズします。 DataFreshnessEvaluator と SafetyGuardrailEvaluator をテンプレートとして始めます。 さらに深く知るには、 Amazon Bedrock AgentCore のドキュメント と、GitHub 上の Strands Agents SDK を調べてみてください。 リソースのクリーンアップ 継続的な課金を避けるために、このチュートリアルで作成したリソースを削除します。 CDK プロジェクトのディレクトリに移動します。 cd sample-evaluating-agents-on-aws-with-strands-and-agentcore/examples/vehicle-auction-agent/cdk デプロイしたすべてのスタックを削除します。 cdk destroy --all プロンプトが表示されたら、削除を確定します。 AWS マネジメントコンソールで、Lambda 関数、S3 バケット、DynamoDB テーブル、CloudWatch のロググループとダッシュボード、EventBridge のルール、SNS トピックを含むすべてのリソースが、クリーンアップ処理で削除されたことを確認します。 注意: オブジェクトが入っている S3 バケットは、手動での削除が必要な場合があります。保持したい評価データやログがある場合は、クリーンアップを実行する前にエクスポートしてください。 参考資料 Evaluating AI agents for production: A practical guide to Strands Evals 。 Strands Agents SDK 。 strands-agents-evals 。 Amazon Bedrock AgentCore Evaluations 。 Evaluating AI agents: Real-world lessons from Amazon 。 著者について Amit Deol Amit は、AWS Prototyping and Cloud Engineering (PACE) のシニアプロトタイピングアーキテクトです。AWS のお客様と協力して新しいアイデアを試し、生成 AI、データ分析、リアルタイムストリーミングにわたる本番運用対応のソリューションを構築しています。プロトタイピングをしていないときは、森の中を長く散歩している姿が見られます。 Hin Yee Liu Hin Yee は、AWS のシニアプロトタイプエンゲージメントマネージャーです。AI のプロトタイプから本番運用までの道のりを速める顧客エンゲージメントを率い、チームが AWS 上で生成 AI ワークロードを構築・運用するためのベストプラクティスを取り入れられるよう支援しています。 Ryan Cormack Ryan は、Motorway のプリンシパルエンジニアであり、AWS Community Builder です。ディーラー向けの AI 活用ツールの開発を率いており、AWS Summit London で Motorway のエージェント型 AI の採用について講演しました。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

本記事は 2026 年 8 月 10 日 に公開された「 Configure AWS Advanced JDBC Wrapper connection pooling with the assistant 」を翻訳したものです。 本記事では、Amazon Aurora および Amazon Relational Database Service 上で AWS Advanced JDBC Wrapper のコネクションプーリングを設定する方法を紹介します。ラッパーの外部プーリングと内部プーリングの違い、選択基準、JDBC-WRAPPER-CONFIGURATION-ASSISTANT による設定構築の方法も解説します。 AWS Advanced JDBC Wrapper は、コミュニティ JDBC (Java Database Connectivity) ドライバーの上に配置されるラッパーで、ドライバーを置き換えることなく Amazon Aurora、Amazon Relational Database Service (Amazon RDS)、AWS クラウドの機能を追加します。アプリケーションと実際のドライバーの間に単一のレイヤーを挿入し、すべての JDBC 呼び出しをインターセプトして Amazon Aurora や Amazon RDS 向けの機能を提供します。既存の SQL コードやツールを変更せずに、高速フェイルオーバー、Enhanced Failure Monitoring (EFM)、IAM 認証、リード/ライトスプリッティングなどの機能をプラグインとして有効化・無効化できます。 プラグインベースのアーキテクチャ ラッパーのすべての機能はプラグインとしてパッケージ化されており、各 JDBC 呼び出しはプラグインチェーンを通過してから実際のドライバーに到達します。以下の図は、アプリケーションが connection.prepareStatement(...) のような JDBC メソッドを呼び出したときの動作を示しています。 図 1: JDBC メソッド呼び出しがラッパーのプラグインチェーンを通過してコミュニティドライバーに到達する流れ 設計上の重要なポイントをいくつか紹介します。 コネクションごとに専用のインスタンス : 各 Connection オブジェクトは、固有のプラグインマネージャー、プラグインサービス、プラグインインスタンスを保持します。 サブスクリプションベースの実行 : プラグインは getSubscribedMethods() を通じて関心のある JDBC メソッドのみをサブスクライブします。関心のないメソッドはチェーンをバイパスしてドライバーに直接渡されるため、オーバーヘッドを最小限に抑えられます。 チェーンの末端は常に DefaultConnectionPlugin : このプラグインが実際のコネクション作成を担当し、 ConnectionProvider が呼び出されるポイントです。コネクションプーリングはここでフックされます。 デフォルトで有効なプラグインは initialConnection 、 auroraConnectionTracker 、 failover2 、 efm2 です。これら以外にも、リード/ライトスプリッティング、AWS Identity and Access Management (IAM) 認証、AWS Secrets Manager、Blue/Green デプロイメント、Limitless など、さまざまなプラグインが用意されています。 コネクションプーリングとは データベースへの新しいコネクションの確立にはコストがかかります。TCP ハンドシェイク、TLS ネゴシエーション、認証、セッション初期化などを含めると、1 つのコネクションで数十～数百ミリ秒かかることがあります。リクエストごとに新しいコネクションを開閉すれば、毎回同じコストが発生します。 コネクションプールは、あらかじめ一定数のコネクションを作成して再利用する技術です。アプリケーションはプールからコネクションを「借り」、使い終わったらクローズする代わりにプールに「返却」します。返却されたコネクションは物理的にはクローズされず、次のリクエストで再利用されます。以下の図は、アプリケーションがプールからコネクションを借りて使用後に返却する流れを示しています。 図 2: アプリケーションがプールからコネクションを借りて返却する仕組み コネクションプーリングのメリット リクエストごとに新しいコネクションを開くのではなく再利用することで、次のようなメリットが得られます。 レイテンシの低減: コネクション確立コストがなくなり、リクエストのレスポンスタイムが改善します。 スループットの向上: コネクション作成に消費されていた CPU やネットワークリソースを、実際のクエリ処理に使えるようになります。 リソース保護と上限制御: コネクションはサーバー上のメモリと CPU を消費するため、インスタンスが維持できるコネクション数には限りがあります。オープンなコネクション数を制限してデータベースの過負荷を防ぎます。 負荷の平滑化: トラフィックスパイク時でもプールサイズが上限として機能し、データベースへの負荷を安定させます。 コネクション状態の管理: アイドルタイムアウト、最大ライフタイム、ヘルスチェック (バリデーション) によって無効なコネクションが除外されます。 ラッパーにおける外部プーリングと内部プーリングの動作 ラッパーのプーリングを理解するカギは、プラグインチェーンのどちら側にプールが位置するかです。以下の図は、外部プールと内部プールのプラグインチェーンに対する位置を示しています。 図 3: プラグインチェーンに対する外部プールと内部プールの配置 外部プーリング プールの起動時に N 個のラッパーコネクションが作成されます。各ラッパーコネクションは、専用のプラグインマネージャーとプラグインサービスを持つ完全な論理コネクションです。 アプリケーションがプールからコネクションを借りると、1 つの ConnectionWrapper を受け取ります。 その上で実行されるすべてのクエリはプラグインチェーンを通過し、実際のドライバーに転送されます。 アプリケーションが処理を完了してコネクションをクローズしても、物理的にはクローズされません。 ConnectionWrapper がプールに戻り、次の借り出しで再利用されるため、同じ論理コネクションが複数のリクエストにまたがって存続します。 フェイルオーバーが発生すると、ラッパーは同じ ConnectionWrapper 内で基盤となる物理コネクションを新しいインスタンスに再接続し、フェイルオーバー例外を発生させます。プールが保持するラッパーオブジェクト自体は変わらず、即座に再利用可能です。ただしプール側は例外しか認識しないため、例外をキャッチしつつコネクションを破棄せず、ラッパーが再接続済みのコネクションをそのまま保持するようプールに指示する必要があります。 フェイルオーバー例外を適切に処理してください。コネクションを無条件に破棄してはいけません。 08S02 (トランザクション外でのフェイルオーバー成功) では同じコネクションが再接続済みで再利用可能です。ラッパーはデフォルトで追跡中のセッション状態 ( autoCommit 、 readOnly 、 isolation など) を新しいコネクションに転送する ( transferSessionStateOnSwitch=true ) ため、最後のステートメントを再実行すれば済みます (実行中の処理はロールバックされます)。 08007 (トランザクション内での失敗) の場合も同様にしたうえで、トランザクション全体をやり直してください。コミット状態が不明なためです。 08001 (フェイルオーバー失敗) の場合のみコネクションが真に使用不可となるため、破棄して新しいものを開いてください。これらを汎用の SQLException としてキャッチし、 finally/catch ブロックでコネクションをクローズするのが、高速フェイルオーバーを無効にしてしまう典型的なミスです。 内部プーリング プールの分割方法。ラッパーは内部的に複数のコネクションプールを保持し、「接続先のインスタンス」と「接続ユーザー」の両方で区別します。デフォルト設定では、接続先インスタンスのアドレスとユーザー名を組み合わせてプールを分離します。同じインスタンスでもユーザーが異なれば別のプールになり、同じユーザーでもインスタンスが異なれば別のプールになります。実質的に、インスタンスとユーザーの組み合わせごとに 1 つのプールが作成されます。 コネクションの貸し出し方法。アプリケーションがコネクションを要求すると、ラッパーは毎回新しい物理コネクションを作成するのではなく、該当する組み合わせのプールを探します。プールが存在すればアイドルコネクションを取り出して貸し出し、存在しなければ新規作成してからコネクションを渡します。使用後にクローズされたコネクションは実際には切断されず、プールに戻って再利用されます。 未使用プールのクリーンアップ。一定期間 (デフォルト 30 分) コネクションのリクエストがないプールは クリーンアップ候補 としてマークされます。ただし候補になっても即座にクローズされるわけではありません。貸し出し中のコネクションがすべて返却されて初めて、プールが実際にクローズされリソースが回収されます。つまり、そのプールからまだコネクションを使用中のクライアントがいれば、有効期限を過ぎてもプールは存続し、使用中のコネクションが突然切断されることはありません。 内部プーリングのメリットが得られるケース 内部プーリングが最も効果を発揮するのは、いくつかの特定のシナリオで、最も重要なのがリード/ライトスプリッティングです。 リード/ライトスプリッティング: 内部プーリングの最大のメリットは、リード/ライトスプリッティングプラグインと組み合わせたときに現れます。 setReadOnly(true/false) の呼び出しに応じて、リード/ライトスプリッティングプラグインは 1 つの論理コネクションの接続先をライターとリーダーの物理コネクション間で切り替えます。 内部プールなしの場合: setReadOnly(true) が初めて呼び出されるたびにリーダーへの新しい物理コネクションが開かれ、そのコネクションは論理コネクションの存続期間中のみキャッシュされます。他の論理コネクションからは再利用できません。 内部プールありの場合: 各インスタンス (ライター/リーダー) への物理コネクションがプールに蓄積され、複数の論理コネクションが setReadOnly での切り替え時にこれらを再利用します。 @Transactional(readOnly = true) のようにリーダーとライターを頻繁に行き来する Spring ワークロードでは特に効果的です。 JDBC-WRAPPER-CONFIGURATION-ASSISTANT とは JDBC-WRAPPER-CONFIGURATION-ASSISTANT は、AWS Advanced JDBC Wrapper 4.0 以降で利用できる生成 AI ベースの設定アシスタントです。ラッパーの設定選択、既存設定のレビュー、設定の問題診断を支援します。ラッパーのソースコードや公式ドキュメントに基づいた回答を生成し、プラグインの動作、パラメータ名、デフォルト値、排他的な組み合わせなどの詳細を含みます。 Kiro を例にすると、JDBC-WRAPPER-CONFIGURATION-ASSISTANT スキルを有効化した後、会話の開始時に 3 つのエントリーポイントが提示されます。状況に最も合ったものを選択できます。 Greenfield – 達成したいゴールを説明します。例: 「HikariCP を使用した Aurora PostgreSQL クラスターのフェイルオーバーを設定したい」。アシスタントがフォローアップの質問をし、段階的に設定を絞り込みます。 Review – 現在の設定を貼り付けるか、スタックを説明します。アシスタントがレビューして改善点を提案します。 Skip the interview – 動作する設定を直接リクエストします。例: 「デフォルトの Aurora PostgreSQL + HikariCP 設定をください」。アシスタントが使用可能な設定を返し、前提条件を明示します。 内部プーリングの設定オプションと例 内部プーリングを有効にする方法は 2 つあります。 オプション A — 組み込み設定パラメータ (connectionPoolType) 最も直接的な方法です。コネクションプロパティで connectionPoolType を指定し、プール固有の設定は cp- プレフィックスで渡します。以下に例を示します。 # HikariCP 内部プールの有効化 + プールパラメータ connectionPoolType=hikari&cp-MaximumPoolSize=20&cp-MinimumIdle=1 # c3p0 内部プール connectionPoolType=c3p0&cp-MaxConnectionAge=3600&cp-MaxPoolSize=15 指定可能な値: hikari 、 c3p0 cp- の後の名前は com.zaxxer.hikari.HikariConfig または com.mchange.v2.c3p0.ComboPooledDataSource のプロパティに直接マッピングされます。例: cp-MaximumPoolSize は HikariConfig.maximumPoolSize に対応します。 内部的には InternalConnectionPoolService が clusterId ごとに PooledConnectionProvider を作成してキャッシュします。つまり、異なる clusterId を持つクラスターは別々のプールを使用します。 JDBC-WRAPPER-CONFIGURATION-ASSISTANT の使用例 質問: connectionPoolType=hikari のみ有効にしました。プールサイズなどの詳細設定はどこに記述すればよいですか？ 回答: 詳細なプール設定は cp- プレフィックスで渡します。プレフィックスの後のキーは HikariCP の HikariConfig プロパティと 1 対 1 で対応します。例えば、最大 20 コネクション、アイドル 2 コネクションを維持する場合は以下のように設定します。 connectionPoolType=hikari&cp-MaximumPoolSize=20&cp-MinimumIdle=2 内部プールは clusterId で分離・キャッシュされるため、1 つのアプリケーションが複数のクラスターに接続する場合は、プールの混在を避けるため各クラスターに一意の clusterId を割り当ててください。プールサイズは控えめに設定してください。内部プーリングではインスタンスごとに複数のプールが作成される可能性があるため、プール全体の最大値の合計がデータベースインスタンスの max_connections 制限を超えないようにしてください。 オプション B — カスタム HikariPooledConnectionProvider より細かい制御が必要な場合に使用します。プール設定関数 ( HikariPoolConfigurator ) と、オプションでプールキー関数 ( HikariPoolMapping ) を提供します。 // 1) プール設定関数 private static HikariConfig getHikariConfig(HostSpec hostSpec, Properties props) { HikariConfig config = new HikariConfig(); config.setMaximumPoolSize(10); config.setMinimumIdle(1); config.setIdleTimeout(60_000); return config; } // 2) プールキー関数 --- インスタンス URL + ユーザー + カスタム値の組み合わせでプールを分離 private static String getPoolKey(HostSpec hostSpec, Properties props) { final String user = props.getProperty(PropertyDefinition.USER.name); final String somePropertyValue = props.getProperty("somePropertyValue"); return hostSpec.getUrl() + user + somePropertyValue; } // 3) 登録 final HikariPooledConnectionProvider connProvider = new HikariPooledConnectionProvider( MyApp::getHikariConfig, MyApp::getPoolKey); Driver.setCustomConnectionProvider(connProvider); // 4) アプリケーションシャットダウン時 ConnectionProviderManager.releaseResources(); プールを正しく動作させるため、ラッパーは以下の 4 つの設定を自動的にオーバーライドします: jdbcUrl (ホスト/ポート/データベースを含む)、 exceptionOverrideClassName 、ユーザー名、パスワード。そのため、 HikariPoolConfigurator でこれらの値を指定しても無視されます。コンストラクタは、プールキー、クリーンアップ、適格性を制御するいくつかのオプションパラメータも受け付けます。以下の表にまとめます。 パラメータ 型 意味 hikariPoolConfigurator HikariPoolConfigurator (必須) プール設定を返す関数。追加設定がない場合は空の HikariConfig を返します。 mapping HikariPoolMapping (オプション) プールキーを生成する関数。キーが一意になるたびに新しいプールが作成されます。デフォルトはユーザー名です。 acceptsUrlFunc AcceptsUrlFunc (オプション) どのコネクションに内部プールを適用するか決定します。デフォルトはインスタンスエンドポイントのみです。 poolExpirationNanos long プールがクリーンアップ候補になるまでのアイドル時間 (デフォルト 30 分)。 poolCleanupNanos long 期限切れプールをクリーンアップする間隔。 外部プーリングと内部プーリングの違い 以下の表は、配置、トポロジー認識、設定、シャットダウン動作の観点で両方のプーリングアプローチの主な違いをまとめたものです。 観点 外部プーリング (HikariCP など) 内部プーリング (ラッパー) プールの配置 ラッパーの上 (アプリケーションとラッパーの間) ラッパーの内部 (ラッパーとターゲットドライバーの間) プール対象 論理コネクション ( ConnectionWrapper ) 物理コネクション (インスタンスごと) トポロジー認識 なし (接続先インスタンスを認識しない) あり (インスタンスごとにプールが分離) プールキー 通常は単一のデータソース (エンドポイント) (インスタンス URL、ユーザー/カスタムキー)。プールプロバイダーは clusterId ごとにキャッシュ クラスターエンドポイント そのままプールされる (注意が必要) プールされない (インスタンスエンドポイントのみプール) 設定の記述場所 プールライブラリ + AwsWrapperDataSource connectionPoolType または HikariPooledConnectionProvider setReadOnly 切り替え プールは切り替えられたリーダーコネクションを認識しない → オブジェクト間での共有が限定的 インスタンスプールから再利用 → オブジェクト間で共有 leastConnections 戦略 利用不可 利用可能 シャットダウンのクリーンアップ プールライブラリの close ConnectionProviderManager.releaseResources() が必要 外部プーリングと内部プーリングの長所と短所 外部プーリングの長所 外部プーリングにはいくつかの利点があり、フレームワーク駆動のアプリケーションで特に効果的です。 フレームワークとの親和性: Spring Boot などのフレームワークはデフォルトで外部プールを管理します。 アプリケーションレベルでの合計同時コネクション上限 ( maximumPoolSize ) を直感的に制御できます。 チューニングのノウハウやトラブルシューティングのリソースが豊富です。 外部プーリングの短所 一方で、フェイルオーバーやリード/ライトスプリッティングではトレードオフがあります。 setReadOnly ベースのリード/ライトスプリッティングでは、プールレベルでのリーダーコネクション再利用が難しくなります。 フェイルオーバー直後、プール内の多くのコネクションが無効化され、プール枯渇や再接続の急増を招くことがあります。 leastConnections のようなプール対応のホスト選択戦略は使えません。 内部プーリングの長所 内部プーリングには独自の利点があり、多くはトポロジー認識に関連しています。 トポロジー認識: インスタンスごとにプールを保持するため、リード/ライトスプリッティングでリーダーへの切り替えコストが大幅に削減され、複数の Connection オブジェクトがプールを共有します。 クラスターエンドポイントプーリングの落とし穴を構造的に回避します (インスタンスエンドポイントのみプール)。 leastConnections のようなプール対応戦略でリーダー負荷をより均等に分散します。 フェイルオーバー時にラッパーがインスタンスプールを直接管理するため、切り替えがスムーズです。 内部プーリングの短所 一方で、運用上のトレードオフもいくつかあります。 設定と運用の概念が増えます ( HikariPoolConfigurator 、 HikariPoolMapping 、 releaseResources() )。 プールキーからユーザー名を省略すると権限分離が壊れ、キャッシュされたプールコネクションがパスワードを再検証しません。 プール数が インスタンス × ユーザー で増加するため、メモリとコネクションのオーバーヘッドに注意が必要です。 外部プーリングと内部プーリングのプラグイン互換性の違い 以下の表は、外部プーリングと内部プーリングで各プラグインや機能がどう動作するかを示し、推奨事項を記載しています。 プラグイン / 機能 外部プーリング 内部プーリング 備考 Read/Write Splitting ( readWriteSplitting ) 動作するがリーダーの再利用は限定的 推奨 内部プールがオブジェクト間でリーダーコネクションを再利用 @Transactional(readOnly=true) (Spring) 非推奨 (切り替えごとにオーバーヘッド) 推奨 内部プールと組み合わせた場合のみ推奨 leastConnections ホスト選択戦略 利用不可 利用可能 プールのアクティブコネクション数の読み取りが必要なため、内部プールが必須 lowestLoad / highestLoad / roundRobin / weightedRandom / random 利用可能 (戦略による) 利用可能 内部プールプロバイダーが直接サポート Failover / Failover2 利用可能 (プール側で例外処理が必要) 利用可能 EFM / EFM2 利用可能 利用可能 Amazon RDS Proxy エンドポイントとは互換性なし (監視対象のインスタンストポロジーがないため) IAM / Secrets Manager 認証 利用可能 利用可能 (キャッシュされたコネクションがパスワード再検証をスキップする可能性あり) ユーザーをプールキーに含める必要あり Blue/Green 利用可能 利用可能 スイッチオーバー時に Blue コネクションを切断 外部プーリングと内部プーリングの選択時の考慮事項 選択はどちらが普遍的に優れているかではなく、ワークロードと運用環境への適合度で決まります。以下のセクションでは主な判断ポイントをまとめ、Greenfield モードでアシスタントを活用する方法を示します。 ワークロード / 機能の観点 リード/ライトスプリッティングを使用するかどうか: setReadOnly ベースの R/W スプリッティングを多用する場合 → 内部プールが有利です。使用せず、シンプルな単一インスタンス/単一エンドポイント構成の場合は、外部プールで十分です。 リード負荷分散戦略: leastConnections でリーダーを分散したい場合 → 内部プールが必須です。 フェイルオーバーの頻度と感度: フェイルオーバーが頻繁に発生する場合や高速リカバリが重要な場合、内部プールならラッパーがインスタンスプールを直接管理するため切り替えがスムーズです。外部プールでは、古いコネクションの処理やプール枯渇への対策が必要です。 トランザクションパターン: @Transactional(readOnly=true) を多用する Spring アプリケーションでは、内部プール + R/W スプリッティングの組み合わせが推奨されます。 JDBC-WRAPPER-CONFIGURATION-ASSISTANT の使用例 (Greenfield) 質問: Spring アプリケーションで @Transactional(readOnly = true) を頻繁に使用しています。どちらのプーリングアプローチを使うべきですか？ 回答: リード/ライトスプリッティングのユースケースですね。まず 2 点確認させてください。(1) 対象は Aurora クラスターですか？ (2) リードモードの切り替えはフレームワーク経由で @Transactional(readOnly = true) を使用していますか？ 質問: 両方 Yes です。Aurora PostgreSQL を使用しています。 回答: その場合、 readWriteSplitting プラグインとラッパーの 内部プール を組み合わせてください。内部プーリングがないと、論理コネクションでリードモードが初めて有効化されるたびに新しい物理リーダーコネクションが開かれ、コネクションチャーンが増加しインスタンスのコネクション上限を圧迫します。まず以下の設定をベースにしてください。 data-source-properties: wrapperPlugins: initialConnection,readWriteSplitting,failover2,efm2 wrapperDialect: aurora-pg readerHostSelectorStrategy: random connectionPoolType: hikari cp-MaximumPoolSize: 20 cp-MinimumIdle: 2 この構成では auroraConnectionTracker を追加しないでください。内部プールが既に clusterId によってインスタンスコネクションを追跡・無効化するため、トラッカーは冗長になります。また、トレースログで @Transactional(readOnly = true) が実際にラッパーまで伝播されているか検証することをお勧めします。 エンドポイント / トポロジーの観点 接続 URL の種類: クラスター/リーダークラスターエンドポイント経由で接続する場合、外部プールは古い DNS のリスクがあるため、 initialConnection プラグインとバリデーション設定が重要です。内部プールはインスタンス単位で動作するため、この問題を構造的に回避します。 マルチクラスター接続: 1 つのアプリケーションが複数のクラスターに接続する場合、クラスターごとに異なる clusterId を割り当てる必要があります。内部プールは clusterId でプールを分離するため、この設定は特に重要です。 カスタムドメイン/IP/プロキシ: 非標準の URL では、 clusterId と clusterInstanceHostPattern の設定を確認してください。 JDBC-WRAPPER-CONFIGURATION-ASSISTANT の使用例 (Greenfield) 質問: 1 つのサービスが 2 つの Aurora クラスターに接続しています。プールをどう分離すべきですか？ 回答: マルチクラスター構成では、プーリングアプローチに関係なく各クラスターに一意の clusterId を割り当ててください。両方のクラスターがデフォルト値を共有すると、トポロジーキャッシュが衝突し、間違ったクラスターへのフェイルオーバーやモニター間の干渉が発生する可能性があります。内部プーリングでは、 clusterId がプール分離の境界にもなります。 a.addDataSourceProperty("clusterId", "cluster-a-prod"); b.addDataSourceProperty("clusterId", "cluster-b-prod"); 質問: クラスターライターエンドポイント経由で接続し、外部プーリングを使用する場合、何に注意すべきですか？ 回答: フェイルオーバー直後、古い DNS によりクラスターエンドポイントが一時的に旧ライターに解決される場合があります。外部プーリングのみを使用する場合は、 initialConnection プラグインを含めることで最初のコネクションが実際のインスタンスエンドポイントに着地するようにしてください。EFM がクラスターエンドポイントではなくインスタンスエンドポイントを監視するためにも有効です。内部プーリングはインスタンスエンドポイントのみをプールするため、この問題を構造的に回避します。 セキュリティの観点 マルチユーザーの権限分離: HikariPoolMapping にユーザー名を必ず含めてください (省略すると、異なる権限を持つユーザー間でプールが共有されるリスクがあります)。 IAM トークン認証: トークン TTL とプールコネクションのライフタイムの関係を考慮してください。内部監視ワーカーが IAM プラグインを失わないように ConfigurationProfile の設定が推奨されます。 JDBC-WRAPPER-CONFIGURATION-ASSISTANT の使用例 (Greenfield) 質問: HikariCP で IAM 認証を使用していますが、15 分あたりから一部のコネクションが失敗し始めます。どう対処すべきですか？ 回答: 直感的な対処法は HikariCP の maxLifetime を短くすることですが、ここでは効果がありません。 iam プラグインがサブスクライブするのは connect と forceConnect のみで、トークンはハンドシェイク時に一度だけ提示され、以降の呼び出しにフックはありません。認証に成功したコネクションがトークンの経過時間によって失敗することはありません。 maxLifetime はプールの衛生管理の観点で設定し、トークンとは切り離して考えてください。 重要なのは iamExpiration です。ラッパーはトークンを (region, host, port, user) ごとにキャッシュし、 iamExpiration はそのキャッシュの TTL で、デフォルトは 870 秒 (サーバー側のトークンウィンドウ 15 分に対して) です。900 を超える値は設定しないでください。ドライバーは値をクランプせずに読み取るため、大きな TTL を設定するとキャッシュが RDS によって既に無効化されたトークンを配信します。プラグインのドキュメントでは 600 を例として使用しています。 hikari: max-lifetime: 1800000 data-source-properties: wrapperPlugins: initialConnection,auroraConnectionTracker,iam,failover2,efm2 iamRegion: us-east-1 iamExpiration: 600 キャッシュされたトークンが拒否された場合、プラグインはトークンを再生成して接続を1回リトライするため、完全な障害にはなりません。ただし、影響を受けるコネクションはそれぞれ最初のハンドシェイクが一度失敗するため、間欠的な接続遅延やエラーとして症状が現れます。 コンテナや Lambda 環境では、 iamRegion を明示的に設定するほうが安全です。内部プーリングを使用し、ユーザーごとに権限が異なる場合は、キャッシュされたコネクションがユーザー間で再利用されないよう、プールキーにユーザーを含めてください。 運用 / フレームワークの観点 フレームワーク標準: Spring Boot のようなフレームワークはデフォルトで外部プールを管理します。チーム標準が外部プールで R/W スプリッティングを使用しない場合、外部プールのほうが運用がシンプルです。 プールサイジング: 内部プールは インスタンス × ユーザー の数だけプールが増える可能性があり、合計コネクション数が増加します。各インスタンスの maximumPoolSize を控えめに設定し、データベースの max_connections 制限内に収まるようにしてください。 メモリ/スレッドコスト: プール数が増えるほど、アイドルコネクションやヘルスチェックスレッドのコストが増加します。有効期限/クリーンアップ間隔 ( poolExpirationNanos 、 poolCleanupNanos ) と minimumIdle を適切にチューニングしてください。 コネクションライフタイムの制御: リーダーのキープアライブ ( cachedReaderKeepAliveTimeoutMs ) をプールの maxLifetime / idleTimeout ポリシーと合わせて設計してください。 JDBC-WRAPPER-CONFIGURATION-ASSISTANT の使用例 (Greenfield) 質問: チーム標準は Spring Boot + HikariCP です。リード/ライトスプリッティングは使用していません。内部プーリングは必要ですか？ 回答: いいえ。リード/ライトスプリッティングを使用しないシンプルな単一エンドポイントの Spring アプリケーションでは、おなじみの外部 HikariCP プールで十分で、運用もシンプルです。ただし、HikariCP + フェイルオーバーで 1 つ重要な設定があります: exception-override-class-name に software.amazon.jdbc.util.HikariCPSQLException を設定し、ラッパーがフェイルオーバー後に再接続済みのコネクションを HikariCP が破棄しないようにしてください。 hikari: maximum-pool-size: 30 exception-override-class-name: software.amazon.jdbc.util.HikariCPSQLException data-source-properties: wrapperPlugins: initialConnection,auroraConnectionTracker,failover2,efm2 wrapperDialect: aurora-pg 質問: リードデータソースとライトデータソースを完全に分離すれば、内部プーリングを避けられますか？ 回答: はい。リードがリーダークラスター URL、ライトがライタークラスター URL を使い、2 つの別々のデータソースを構成する場合、リード/ライトスプリッティングプラグインと内部プーリングの両方を回避できます。各データソースに固定のロールを付与し、 failoverMode を strict-reader または strict-writer に設定してください。リーダーデータソースに readWriteSplitting を追加しないでください。切り替えるロールがないためです。 判断のまとめ (クイックガイド) シンプルな単一エンドポイント + 標準的な Spring アプリ、R/W スプリッティングなし → 外部プール (HikariCP)。フェイルオーバー SQLState マッピングに注意。 リード/ライトスプリッティング + リーダー負荷分散 ( leastConnections ) が必要 → 内部プール。 データソースを分離してリードはリーダークラスター URL、ライトはライタークラスター URL を使える場合 → R/W プラグインと内部プールの両方をスキップし、2 つの外部プールで対応可能。 まとめ AWS Advanced JDBC Wrapper のコネクションプーリングを理解するカギは、「 プールがラッパーの上 (外部) か下 (内部) か 」という位置関係です。 外部プーリング は 論理コネクション をプールします。ツールが成熟しておりフレームワークとの親和性が高い一方、リード/ライトスプリッティングには制約があります。 内部プーリング は 物理コネクション をインスタンス単位でプールします。トポロジーを認識するため、リード/ライトスプリッティング、リーダー負荷分散 ( leastConnections )、フェイルオーバー切り替えに優れています。その代わり、クラスターエンドポイントはプールされず (インスタンスエンドポイントのみ)、プールキー、パスワード再検証、リソースクリーンアップなどの運用概念が追加されます。 最終的に、ラッパーのプラグインアーキテクチャとプーリングアプローチは別々の選択ではなく、一体として設計すべきものです。まず JDBC-WRAPPER-CONFIGURATION-ASSISTANT を開いてワークロードを説明し、アプリケーションにそのまま組み込める初期設定を提案してもらいましょう。ワークロードの読み書き比率、フェイルオーバー感度、セキュリティ要件、運用標準を総合的に検討すれば、Aurora の高可用性とプーリングによるパフォーマンス向上の両方を活用できます。 プールがラッパーのどちら側に位置すべきか迷ったら、ワークロード (エンジン、エンドポイント、フレームワーク、読み書きパターン) を JDBC-WRAPPER-CONFIGURATION-ASSISTANT に伝えてください。初期設定の提案に加え、内部プールなしでリード/ライトスプリッティングプラグインを使用している、HikariCP の例外オーバーライドが不足しているなど、よくあるアンチパターンも指摘してくれます。 著者について Dave Cramer Dave は、Amazon Web Services のプリンシパルソフトウェアエンジニアです。PostgreSQL JDBC ドライバーのメンテナーとして PostgreSQL にも大きく貢献しています。クライアントインターフェースとクライアントとの連携に情熱を注いでいます。 Youngdong Lee Youngdong は、データベースを専門とするソリューションアーキテクトです。Amazon データベースサービスに関する技術的な問い合わせや課題の分析を支援し、データとインフラストラクチャの安定した導入・運用に取り組んでいます。 この記事はSolutions ArchitectのShinya Sugiyama が翻訳を担当しました。

本記事は 2026 年 8 月 11 日 に公開された「 How GPU acceleration builds billion-scale vector indexes on Amazon OpenSearch Service 」を翻訳したものです。 生成 AI アプリケーションが急速に増えるなか、いまの検索には高性能なベクトルインデックス作成とスケーラビリティが求められます。データセットが数十億件規模に達すると、従来の CPU ベースのインデックス作成がボトルネックになりがちで、生産性やイノベーションのスピードを鈍らせてしまいます。 GPU で高速化したベクトル (k-NN) インデックス作成が Amazon OpenSearch Service と Amazon OpenSearch Serverless で 利用できるようになり 、数十億件規模のベクトルにも効率よくスケールできます。この機能は、GPU アクセラレーションによるベクトル検索向けのオープンソースライブラリ NVIDIA cuVS を基盤としており、計算負荷の高いベクトルインデックスの構築を専用の GPU ワーカーにオフロードします。その間、既存の CPU インフラは検索の処理を続けられます。結果として、クエリ性能を犠牲にすることなく、大規模なベクトルインデックスをより速く、より低コストで構築できます。 以前の記事 では、性能とコスト面のメリットを詳しく紹介しました。本記事では、この機能の仕組みをさらに掘り下げます。まず、その土台にある分離型アーキテクチャを見ていきます。次に、GPU で構築したインデックスが、品質を落とすことなく CPU データノードで検索可能な形式に変換される過程を説明します。さらに、10 億件の 1024 次元ベクトルを使ったベンチマークで、大規模環境でもこの方式が通用することを示します。最後に、本番環境で GPU アクセラレーションによるインデックス構築を運用する際に推奨するベストプラクティスを紹介します。 ユースケースとメリット さまざまな業界の企業が、より豊かな顧客体験を提供するために AI やエージェント型のアプリケーションを構築しています。ベクトルインデックス作成の GPU アクセラレーションは、こうした幅広いユースケースで役立ちます。いくつか例を挙げます。 新しい埋め込みモデルへの移行を速める: より新しい埋め込みモデルにアップグレードすると、すべてのベクトルを生成し直してインデックスを作り直す必要があります。数億から数十億件規模になると、CPU での再構築には数日から数週間かかることもあります。GPU アクセラレーションなら再構築を数時間に短縮できるため、より高品質なモデルへ移行しつつ、再インデックスにかかる時間と可用性へのリスクを大幅に減らせます。 大規模な再インデックスを高速化する: 数十億件の商品リスト、カスタマーレビュー、行動シグナルを扱うグローバルな e コマースアプリケーションでは、新しい商品や埋め込みが追加されるたびに、ベクトルインデックスを素早く作り直す必要があります。GPU アクセラレーションは限られた運用時間内で再インデックスを完了し、検索の関連性を常に最新に保ちます。 急増する書き込みや高い持続書き込みを吸収する: ワールドカップやオリンピックといった大規模スポーツイベントを扱うメディア企業では、数百万件のリアルタイム埋め込みを同時にインデックスする必要があります。これらの埋め込みは、試合のハイライト、解説クリップ、選手のプロフィール、ファンが投稿したコンテンツにまたがり、同時に数百万人の視聴者が関連コンテンツを検索します。GPU ワーカーはこのインデックス作成の急増を吸収し、ライブ検索トラフィックを処理する CPU ノードと競合しません。そのため、大量書き込みにつきものの遅延の急増を避けられます。 読み書き混在のワークロードに合わせてクラスターを最適化する: 小売システムでは従来、カタログ更新時のピーク時のインデックス負荷と、同時に発生する検索トラフィックの両方に対応するため、CPU クラスターを過剰にプロビジョニングし、ピーク時の容量分を常時支払っていました。インデックス作成を GPU にオフロードすれば、CPU クラスターを検索専用に適正なサイズへ調整でき、性能を落とさずにインフラコストを削減できます。 セマンティック検索や OpenSearch への移行を速める: テキストベースのコーパスを初めてベクトル埋め込みに変換する場合でも、既存のベクトルワークロードを別のデータベースから Amazon OpenSearch Service へ移行する場合でも、GPU アクセラレーションによるインデックス作成なら、数日かかるインデックス構築を数時間に短縮できます。GPU による上流の埋め込み生成のスピードに歩調を合わせ、切り替え時のリスクも最小限に抑えられます。 GPU アクセラレーションはいつ有効になるのか GPU アクセラレーションは、オプトインすれば自動的に有効になります。OpenSearch Service ドメインでは、Vector Acceleration オプションをオンにするだけで有効になり、それ以降はコードや API フラグを変更する必要はありません。OpenSearch Serverless では、NextGen ベクトル検索コレクションで GPU によるインデックス構築の高速化がデフォルトで有効です。図 1 はインデックス構築のワークフローを示しています。OpenSearch はセグメントのサイズに応じてベクトルインデックス作成の処理を GPU と CPU に自動で振り分け、性能を最適化します。問題が発生した場合は CPU にフォールバックします。 OpenSearch がセグメントをフラッシュまたはマージするとき、そのセグメントのベクトルデータサイズを、 index.knn.remote_index_build.size.min と index.knn.remote_index_build.size.max で区切られた 設定可能な範囲 と比較します。下限のデフォルトは 50 MB です。下限を超えるセグメントはリモートの GPU ワーカーにオフロードされ、それより小さいセグメントはローカルの CPU で構築されます。セグメントのベクトルサイズは次の式で計算します。 segment_vector_size = num_vectors × dimensions × bytes_per_element そのため、ドキュメント数が同じ 2 つのワークロードでも、セグメントサイズが異なることがあります。 ベクトル数 次元数 エンコーディング セグメントのベクトルサイズ 100,000 1536 Float32 約 586 MB 100,000 768 Byte 約 74 MB どちらの例もデフォルトの下限 50 MB を超えているため、デフォルト設定では両方のセグメントが GPU ワーカーにオフロードされます。 図 1: インデックス構築の簡略化したフロー 分離型のインデックス作成アーキテクチャ OpenSearch のインデックスは内部的にセグメントに分割され、各セグメントが独自のベクトルグラフを持ちます。このセグメント単位の構造こそが、GPU へのオフロードを実用的にしています。各セグメントのグラフは、インデックス全体で調整をとらなくても、GPU ワーカー上で独立して構築できます。これを土台にした、アーキテクチャ上の重要な着想が、ベクトルをインデックスする場所と検索する場所を分離することです。既存の CPU データノードは、取り込み、検索、ベクトル以外のワークロードの処理を続けます。セグメントがベクトルインデックスの構築段階に入ると、負荷の高いグラフ構築の作業が専用の GPU ワーカーにオフロードされ、完成したインデックスがデータノードに返されて検索に使われます。 インデックス構築のワークフロー 取り込み – ベクトルフィールドを持つドキュメントは、通常どおり OpenSearch Service ドメインまたは OpenSearch Serverless コレクションに取り込まれます。ベクトルは CPU データノード上のセグメントに蓄積されていきます。 オフロード – セグメントがフラッシュまたはマージされ、そのベクトルデータが GPU の有効化範囲に収まると、データノードは元のベクトルを Amazon Simple Storage Service (Amazon S3) にアップロードし、構築リクエストを送信します。 構築 – マネージドなウォームプールの GPU ワーカーがジョブを受け取り、ベクトルを読み込んで、NVIDIA cuVS の GPU ネイティブなグラフアルゴリズムである CAGRA (CUDA ANN Graph) を使ってインデックスを構築します。できあがった CAGRA グラフは、その後 CPU ベースの検索と互換性のある Hierarchical Navigable Small World (HNSW) グラフに変換されます。 受け取り – 完成した HNSW インデックスは Amazon S3 に書き戻され、データノードがダウンロードします。データノードはそのインデックスを使って検索クエリに応答します。 フルマネージドな GPU インデックス構築 Vector Acceleration を有効にする だけで、あとは Amazon OpenSearch Service が処理します。 自動スケーリング – GPU ワーカーは、待機中の構築ジョブ数に応じて自動でスケールアップ・スケールダウンします。一括取り込みや再インデックスの際には、負荷に対応するために GPU ワーカーが増えます。キューが空になると、ゼロまで縮小します。 自動インスタンス選択 – サービスがセグメントサイズに基づいて、構築ジョブごとに適切な GPU インスタンスタイプを選びます。ユーザー側でキャパシティプランニングやインスタンスの選択を行う必要はありません。 アクティブな構築時のみ課金 – 課金されるのは GPU が実際にインデックスを構築している間だけで、アイドル状態のときは課金されません。ドメインやコレクションで Vector Acceleration を有効にしていても、OpenSearch Compute Unit (OCU) で計測される GPU の料金は、セグメントが有効化のしきい値に達してインデックス構築が始まったときにのみ発生します。GPU インフラを常時保有するコストはかかりません。 したがってコストは、インデックス作成の量に応じて直接増減します。急増する再インデックスのワークロードは構築が続く間だけ GPU 容量を消費し、次の構築まで GPU コストはゼロに戻ります。 図 2 は分離型の GPU ワークフローを示しています。Amazon S3 がデータノードと GPU ワーカーの仲介役となり、両者が独立して動作できるようにします。データノードは元のベクトルを Amazon S3 にアップロードし、GPU ワーカーが CAGRA グラフを構築して HNSW に変換します。完成したインデックスはデータノードに返されて検索に使われ、その間も検索は中断なく動き続けます。 図 2: GPU インデックスフローのアーキテクチャ CAGRA から HNSW への変換の中身 前のセクションでは、GPU ワーカーがベクトルインデックスを構築してデータノードに返す流れを説明しました。では、GPU で構築したグラフはどうやって CPU で検索可能になるのでしょうか。そして、この変換で品質は落ちるのでしょうか。結論から言うと、落ちません。 CAGRA アルゴリズム GPU ワーカーは、 Facebook AI Similarity Search (Faiss) ライブラリの cuVS GPU バックエンドを通じて統合された CAGRA アルゴリズムを使います。CAGRA は、GPU アクセラレーションを前提に一から設計されたグラフベースのインデックス作成手法です。まず、 Inverted File with Product Quantization (IVF-PQ) や Nearest Neighbor Descent (NN-Descent) といった別の近似最近傍探索の手法を使って k-NN グラフを構築します。次に、近傍間の冗長な経路を取り除き、探索しやすいグラフに整えます。 図 3: CAGRA グラフの構築フロー 出典: CAGRA: Highly Parallel Graph Construction and Approximate Nearest Neighbor Search for GPUs GPU ワーカーによるインデックス構築の流れ GPU ワーカーがベクトルインデックスの構築リクエストを受け取ると、そのリクエストにはセグメント固有のベクトルインデックスを構築するために必要なパラメータが含まれています。ベクトルインデックス構築コンポーネントは、まず Amazon S3 からベクトルファイルを取得して CPU メモリに読み込み、処理を開始します。読み込んだベクトルを使って、Faiss で CAGRA インデックスを構築します。GPU 上で CAGRA インデックスを構築したあと、CPU ベースの検索処理と互換性を持たせるために HNSW グラフ形式へ変換します。できあがったインデックスを Amazon S3 にアップロードして、構築リクエストが完了します。 CAGRA グラフを HNSW に変換する 一般的な HNSW インデックスは、複数の層からなる階層型グラフです。グラフの 最下層 (レイヤー 0) がベクトルを保持し、上位の層はナビゲーションだけに使われる疎なサブセットです。上位の層は、検索アルゴリズムが最下層への適切な入口を見つけるのを助けます。ただし、今回の HNSW 実装では CAGRA グラフを最下層として使い、CAGRA の検索手法と同じように、グラフへのランダムな入口から探索を始めます。そのため上位の層はまったく必要ありません。 つまり、基盤となる層のグラフを構築する重い処理は GPU が担います。そのグラフを HNSW の基盤層としてそのまま再利用することで、CPU で作り直す必要がなくなり、変換の負荷を低く抑えられます。図 4 のように、CAGRA グラフがそのまま基盤層になります。クエリの実行時には、グラフ内のノードをランダムに選び、最近傍へのリンクをたどってグラフを探索します。これは貪欲探索 (greedy search) と呼ばれる方法です。 図 4: HNSW に変換した CAGRA グラフの検索 同じ再現率で、より速い構築 これまでの ベンチマーク で、GPU で構築したインデックスが、 CPU で構築した HNSW と同じ再現率 を、品質を落とさずに達成することが確認されています。これは、CAGRA が生成する最下層のグラフ構造が、接続性と検索品質の点で、HNSW が CPU 上で構築するものと同等だからです。異なるのは構築の方法だけです。 GPU メモリを超える規模へのスケール GPU メモリに収まらないデータの構築 従来の GPU インデックス作成では、データセット全体を GPU メモリに載せる必要があり、利用できるハードウェアによってインデックスサイズに明確な上限が生まれていました。CAGRA は、データセット全体を一度に GPU メモリへ載せずに k-NN グラフを構築する方式 ( アウトオブコア構築 ) によって、この制約を取り除きます。CAGRA の初期 k-NN グラフの構築に IVF-PQ を使う場合、データはシステムメモリから GPU へバッチ単位でストリーミングされるため、データセット全体を一度に GPU メモリへ収める必要がありません。その一方で、計算負荷の高い距離計算やグラフの最適化は引き続き GPU が担います。 量子化 GPU アクセラレーションによるインデックス作成は、OpenSearch で利用できる量子化レベル (2 倍、8 倍、16 倍、32 倍の圧縮) に対応しています。量子化は、ベクトルを GPU に送る 前に 適用されます。これにより、GPU ワーカーへのデータ転送量と、グラフ構築時のメモリ使用量の両方を削減できます。その結果、より大きなセグメントに対してインデックスを構築でき、コスト効率が高まります。 GPU で 10 億件の 1024 次元ベクトルをインデックスする データセットの準備 現実的な大規模ワークロードを評価するために、1024 次元のベクトルを 10 億件含むデータセットを使いました。一様なランダムベクトルは、インデックス構築と再現率のどちらでも誤解を招く結果になるため、実世界の埋め込みの構造を保ったデータが必要でした。このデータセットは、 cuvs-bench に含まれる cuVS の合成データセットジェネレーターで作成しました。このジェネレーターは、Common Crawl から得た実際の埋め込みデータセットの分布を模した合成データを出力します。この方法を使えば、機微な元データを公開したり配布したりせずに、現実的なデータセットを用意できます。ジェネレーターは、10 億件のベクトルデータセット一式と 10,000 件のクエリベクトル、および対応する正解ラベルを、1 台の Amazon Elastic Compute Cloud (Amazon EC2) g6e.16xlarge インスタンス上で、約 2 時間で生成できます。 クラスター構成 ベンチマーク用のクラスターは、OpenSearch のベクトル検索のパフォーマンスチューニングの ベストプラクティス に従って OpenSearch Service 上に設計し、 OpenSearch Benchmark フレームワーク を使ってベンチマークを実施しました。 設定項目 値 理由 データノード 24 × r8g.4xlarge 大規模なベクトルインデックス向けのメモリ最適化インスタンス プライマリシャード 48 シャードサイズを扱いやすく保ち、並列性を最大化する レプリカ 0 インデックス作成のスループットを最大化する。レプリカは構築後に追加する GPU ワーカー 10 (事前スケール) 測定中のコールドスタートの影響を避ける 一括クライアント 160 24 ノードにわたって取り込みパイプラインを飽和させる 一括サイズ 500 ドキュメント/リクエスト リクエストごとの負荷とメモリ圧迫のバランスをとる リフレッシュ間隔 -1 (取り込み中) 小さなセグメントの生成を防ぐ。取り込み後に強制マージを実行する マージの自動スロットリング 無効 ベンチマーク中の人為的なボトルネックを避ける 適用した主なベストプラクティス メモリ最適化インスタンス – r8g.4xlarge は、構築後の HNSW グラフを読み込むのに十分なヒープとネイティブメモリを備えています。 一括取り込み中はリフレッシュを無効化 – 小さなセグメントが多数生成され、それぞれが個別の GPU 構築を発生させるのを防ぎます。 多数の一括クライアント – ノード全体で取り込みを飽和させ、GPU がインデックス構築で常に稼働している状態を保ちます。 HNSW の構築と検索の設定 ( m や ef_construction など) は OpenSearch のデフォルト値を使いました。ほとんどのユーザーがデフォルト値から始めるため、ベンチマークを実態に即したものに保てます。 ベンチマーク結果 データセット インデックス構築 (分) 再現率 @k =100 再現率 @1 P50 (検索) P90 (検索) P99 (検索) 使用した Vector Acceleration OCU 1024D 1B 274 0.93 0.93 26.47ms 32.5ms 66.6ms 44 構築時間はデータ量に比例してスケールする 以前の OpenSearch Service でのベンチマーク では、10 億件の 128 次元ベクトル (BigANN SIFT データセット) を約 35.5 分でインデックスしました。最新のベンチマークでは、次元数を 8 倍の 1024 次元に拡大し、274 分でインデックス構築を完了しました。これはデータ量の増加におおむね比例した結果です。GPU アクセラレーションが、次元数が増えても一貫したスループット効率を保つことを示しています。構築時間は固定的な起動コストではなくデータ量に応じてスケールするため、データセットのサイズからインデックス構築時間をあらかじめ見積もれます。この規模でも検索のレイテンシーは低いままだったため、できあがったインデックスは、構築の速さを犠牲にすることなく応答性の高いクエリに対応できました。 GPU アクセラレーション向けに一括取り込みを最適化する 大量のベクトルデータを読み込むとき、インデックスの動作を一時的に調整すると、GPU の処理負荷を大幅に減らせます。この方法は、ユースケースがデータの一時的な鮮度低下を許容できる場合に有効です。インデックス全体を構築している間は、新しく取り込んだベクトルはリフレッシュを再度有効にするまで検索対象にならないため、通常は問題ありません。一括取り込み中にリフレッシュを無効にする ( "index.refresh_interval": "-1" ) と、小さなセグメントが連続して生成されるのを防げます。そうしないと、小さなセグメントのそれぞれが個別の GPU 構築ジョブを発生させてしまいます。取り込みが完了したら、リフレッシュ間隔を有効に戻してリフレッシュを実行し、セグメントを検索可能にします。この方法により、GPU は多数の小さなセグメントに対して繰り返しインデックスを構築するのではなく、大きく密に詰まったセグメントに対して一度だけ構築するため、全体としてインデックス作成のスループットが速くなります。 GPU アクセラレーションを有効にしたあとは、 Amazon CloudWatch メトリクス (クラスターレベル) と OpenSearch k-NN Stats API (ノードごと) で構築状況を監視できます。GPU での構築が失敗した場合、システムは自動的に CPU ベースのインデックス構築にフォールバックするため、データは引き続きインデックスされます。 今後の最適化 現在は、完成した HNSW インデックス (グラフ構造とベクトル) が、GPU ワーカーから Amazon S3 を経由してデータノードに転送されています。データノードは元のベクトルをすでにローカルに保持しているため、今後の最適化ではグラフ構造 (近傍リスト) だけを転送するようにします。これにより、Amazon S3 への書き戻し量とデータノードへのダウンロード時間を大幅に削減できます。 まとめ GPU アクセラレーションによるインデックス作成を使うと、Amazon OpenSearch Service 上で 10 億規模のベクトルインデックスを、数日ではなく数時間で構築できます。しかも、OpenSearch Service ドメインと OpenSearch Serverless コレクションのどちらでも、クエリの処理方法を変える必要はありません。本記事では、OpenSearch Service が対象となるインデックス構築を GPU ワーカーにオフロードし、Faiss の NVIDIA cuVS バックエンドを通じて CAGRA グラフを構築し、それを CPU で検索可能な HNSW インデックスに変換する仕組みを紹介しました。さらに、10 億件の 1024 次元ベクトルで大規模にこの方式を実証し、一括取り込みの最適化や、構築状況と OCU 使用量の監視についてのベストプラクティスを共有しました。 使ってみる GPU アクセラレーションによるベクトルインデックス作成を試してみませんか。対応している AWS リージョンでは、OpenSearch 3.1 以降を実行する OpenSearch Service ドメインを作成または更新する際に、GPU アクセラレーションを有効にできます。設定には、AWS マネジメントコンソール、AWS Command Line Interface (AWS CLI)、または AWS SDK を使います。OpenSearch Serverless を新しくデプロイする場合は、 NextGen ベクトル検索コレクション を作成してください。このコレクションでは GPU によるインデックス構築の高速化がデフォルトで有効になっており、インデックスごとに制御できます。Classic ベクトルコレクションの場合は、コレクションレベルで GPU アクセラレーションを有効にします。 謝辞 著者一同、本記事への貢献に対し、NVIDIA の Ben Gardner、Manas Singh、Zack Meeks、Jiahong Liu、James Yi、Jinsol Park の各氏に感謝します。 著者について Navneet Verma Navneet は、 Navneet は AWS のプリンシパルソフトウェアエンジニアで、OpenSearch のコアなベクトル検索に取り組んでいます。スケーラビリティ、性能、そして大規模な AI ワークロードに向けたベクトル検索の発展に情熱を注いでいます。 Vamshi Vijay Nakkirtha Vamshi は、 Vamshi は、OpenSearch Project と Amazon OpenSearch Service に携わるソフトウェアエンジニアリングマネージャーです。分散システムに関心があります。 Gowri Balasubramanian Gowri は、 Gowri は、Amazon Web Services でデータスペシャリストソリューションアーキテクトチームを率いるシニアマネージャーです。AWS のデータベースサービスと分析サービスの導入を推進するとともに、リファレンスアーキテクチャからベストプラクティスまでの実践的なガイダンスを整備し、企業のデータと AI の変革を後押ししています。スケーラブルな分散データシステムに情熱を注いでいます。 Kshitiz Gupta Kshitiz は、 Kshitiz は NVIDIA のシニアソリューションアーキテクトで、クラウドのお客様が GPU 上で大規模な AI ワークロードを最適化できるよう支援しています。GPU アクセラレーションによるデータ処理、ベクトル検索、LLM の推論と幅広く手がけ、AWS や Amazon のチームと緊密に連携して、これらの機能を本番環境に届けています。仕事以外では、音楽、ヨガ、ハイキングを楽しんでいます。 Corey Nolet Corey は、 Corey は NVIDIA でベクトル検索、データマイニング、古典的な機械学習ライブラリを担当するディスティングイッシュトエンジニアで、極めて大きなデータ負荷を高速に処理するためのアルゴリズムの構築とスケールに注力しています。2018 年に NVIDIA に加わる前は、防衛業界のビッグデータや HPC 環境で、大規模な探索的データサイエンスとリアルタイム分析のプラットフォームを長年にわたり構築してきました。Corey はコンピューターサイエンスの博士号を持ち、データを使って世界をよりよく理解することに情熱を注いでいます。 Rajeshwari Devaramani Rajeshwari は、 Rajeshwari は NVIDIA のソリューションアーキテクトです。ジョージア工科大学で計算科学工学の修士号を取得しています。GPU プログラミング、ハイパフォーマンスコンピューティング、ディープラーニングを専門としてきました。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

この記事は、”One year. 4.5 billion lines of code. 1.6 million hours saved. Here’s what we learned.” を翻訳したものです。 1 年前、私たちは AWS Transform を立ち上げました。その使命は、ただ 1 つです。それは、世界のインフラストラクチャとアプリケーションをモダナイズすることです。 AWS Transform の一般提供開始から 12 ヶ月が経過した今、これまでに 45 億行を超えるコードが処理され、数十万台のサーバーが移行され、160 万時間を超えるお客様を節約できたこと、そして移行、モダナイゼーション、そしてこの作業が待った無しの状態である理由がわかりました。 モダナイゼーションが何故これまで以上に重要なのか 企業は今でもインフラストラクチャのかなりの部分をオンプレミスで運用しています。世界のソフトウェアの大部分は 20 年以上前のものです。今でも給与計算を行っています。まだ請求処理が行われています。お客様のビジネスが日常的に依存しているシステムが引き続き稼働しています。そして今、経営陣は、その上にエージェンティック AI を組み込むことを望んでいます。15 年間手が入っていないメインフレームでは、エージェンティック AI ワークロードを実行することはできません。退職したエンジニアが開発した継ぎ接ぎだらけの .NET Framework アプリケーションに AI エージェントを投下することはできません。皆さんが先送りし続けているモダナイゼーションが、今や CEO が前四半期に発表した AI 戦略とあなたとの間に立ちはだかっているのです。 その一方で、技術的負債はどんどん膨れ上がっています。米国だけでも、技術的負債は年間 1.52 兆ドルに上ると見積もられており、AI コーディングエージェントは、その山を小さくするのではなく、むしろ大きくしています。彼らは現在出荷されているコードを生成しますが、明日の標準には従わないでしょう。企業リーダーからのシグナルは、「モダナイズすべき」から「モダナイズしなくてはならない」に変わりました。しかし、モダナイゼーションは技術的に難しく、ビジネスが複雑になり、そして重要なのは、モダナイゼーションは決して終わらないということです。今日のモダナイゼーションは明日の遺産です。だからこそ、モダナイゼーションはプロジェクトではなく、継続的なプロセスでなければならないのです。 これが AWS Transform を構築した理由です。 お客様が実際に求めたこと アーキテクチャではありません。フレームワークではありません。他のツールでもありません。 彼らが求めたのは「スピード」という結果でした。精度。継続性。彼らは行き詰まったものを終わらせたかったのです。彼らのプロジェクトのいくつかは何年も手つかずのまま放置されていました。AWS では 20 年間にわたり、数十万件に上るプロジェクトでお客様を支援し、移行ツールを自社で構築してきました。何がうまくいくのか、規模を拡大するには何が必要か、どこにギャップがあるのかはわかっていました。 これが 1 年前、AWS Transform が誕生した経緯です。私たちは学んだことのすべてを数十個の専門的な AI エージェントにまとめ、エージェント型のワークフローで結び付けました。これらのエージェントは、ゴール駆動型のオーケストレーションを使用して end-to-end の自動化を実行しています。ディスカバリー、計画、トランスフォーメーション、テストはすべて相互に関連しています。共同作業者間のシームレスな引き継ぎ。ステージ間でコンテキストが失われることはありません。20 年にわたる移行の専門知識を AI 支援サービスとして提供し、イテレーションを重ねるごとに改善されていきます。 この取り組みは、3 つのユースケース (VMware インフラストラクチャーの移行、IBM z/OS COBOL アプリケーションのモダナイゼーション、.NET のアップグレード) を立ち上げることから始めました。これらのワークロードは、お客様がモダンなワークロードを実行するのを嘗て妨げており、現在はエージェント型のワークロードの実行を妨げているからです。re:Invent 2025 では、広範に技術的負債を削減するべく、あらゆるコード、言語、API、フレームワークのアップグレードに合わせて独自のカスタムトランスフォームを定義できる機能を追加しました。 12 ヶ月で何が起こったか AWS Transform の利用を通じて、45 億行を超えるコードを処理し、数十万台の VM を移行しました。 速度の違いは小さくはありません。25 万行のメインフレームアプリケーション全体のトランスフォーメーションとテストを 6 週間で完了したお客様がいらっしゃいます。以前は、同じ作業に何年もかかっていました。現在、数千台のサーバーを数週間ではなく数時間で移行することを計画しているインフラストラクチャーチームも居ます。これらのお客様による評価では、AWS に移行することでコンピューティングが平均 35%、ライセンスが 45% 節約され、クラウドに移行することでコストを 60% 削減できることが一貫して明らかになっています。Windows と .NET のモダナイゼーションにより、ライセンスコストが 40% 削減され、プロジェクトのスケジュールが 4 倍短縮されたケースもあります。 これらの数字の背景にある顧客リストには、より大きな物語があります。CSL 社は、数千台のサーバの移行を数日で計画しました。これは、以前のアプローチの 10 倍のスピードです。ADP 社は Transform のメインフレームとカスタム機能を使用して複雑なメインフレームをモダナイズし、Kiro と連携して新しいコードの構築を完了しました。現在、110 万のクライアントに対応できるようになり、その成果は数年ではなく数週間で完了しています。Signaturit Group は、Windows .NET から Linux への移行期間を 6~8 ヶ月から数日間に短縮しました。Air Canada は Node.js ランタイムを数日でアップグレードし、90% の効率化と 80% のコスト削減を実現しました。その後、Transform を社内標準にしました。また、何千ものお客様を対象に、過去からの技術的負債を修復するのではなく、将来のためのイノベーションに投資することで、すでに 810 人年分に相当する開発者の工数を節約しています。 しかし、最も強いシグナルは、どの指標にもありません。5 人中 4 人の顧客が AWS ツールに戻ってきて、より多くのプロジェクトを行っているということです。現在、約半数が複数のトランスフォーメーション機能を利用しています。顧客は価値を見出さない限りツールに戻りません。 パートナーと ISV は複合的な効果を生み出します。30 を超えるパートナー組織が Transform をベースにソリューションとデリバリープラクティスを構築しています。ISV も Transform と統合して事業を拡大しています。Wavicle 社は、AWS Transform による BI モダナイゼーションを AWS Marketplace を通じて提供することを発表しました。AWS のフィールドエンジニアは、お客様が直面するパターンに応じてトランスフォームを行っています。つい先週、あるフィールドメンバーが規制対象の顧客のニーズをサポートするためにインフラのアセスメントを拡大しました。 私たちが学んだ 4 つのことと、それがロードマップをどのように進化させたか 今年、数千のお客様と数十のパートナーと協力してきた結果、私たちのアプローチとロードマップは、次の 4 つの重要な洞察から導き出されました。 1. ユーザーが作業しているところで会うこと。 まず、プログラムマネージャーやアーキテクト向けの専用ウェブアプリを開発しました。しかし、アーキテクトはダッシュボードの中で生きています。開発者とプラットフォームエンジニアは IDE と CLI で生活しています。パートナーはそれぞれ独自の配信環境に住んでいます。誰もが、誰かが中断したところから再開したいと思っています。私たちの答えは、「ユーザーが作業しているところで出会う」という選択へのこだわりを引き継いでいます。 現在、MCP サーバーを介して、エージェントにバンドルされていないアクセスを提供しています。この MCP サーバーは、Kiro powers や Claude Code、Cursor、Codex などのエージェントプラグインなど、新しいアクセスサーフェスを強化します。顧客やパートナーは、これらを既存のワークフローにさらに簡単に統合したり、エージェントを召喚して新しいワークフローを構築したりできます。CLI を使用すると、コードのモダナイゼーションパターンを繰り返し実行できます。すべてのサーフェスは同じコンテキストを共有し、再入力や進行状況の損失はありません。 2. ガードレール付きのフェデレーテッド開発。 私たちのチームは、お客様からのフィードバックを取り入れてあらゆるトランスフォームを構築しています。そして、それを何千人ものプラクティショナーに送り、彼らは私たちが計画していなかった場所にそれを導入します。AWS のフィールドチームはお客様と協力して、問題をその場で解決します。パートナーは独自の視点をもたらします。AI はチームのイノベーションのハードルを下げました。フェデレーテッドモデルはクローズドモデルよりも速く合成されます。しかし、品質と運用の一貫性を保ちながらこの機能を活用することは容易ではありません。だからこそ、お客様、パートナー、ISV、そして当社のフィールドチームがパーソナライズして独自の特製ソースを追加できるように、私たちは初日からコンポーザビリティを備えた Transform を設計に組み込んでいます。 本日 ※ 、エージェントビルダーツールキットを Kiro powers として提供を開始しました。これにより、AgentCore でエージェントを構築して Transform に組み込むことがさらに簡単になります。このコンポーザビリティサービスでは、カスタムエージェントを構築し、それらを AWS Transform 内の機能と組み合わせることができます。 (※) 訳注: 本ブログ(原文)の公開日である 2026/05/14 3. エンタープライズモダナイゼーションはマルチプレイヤーです。 エンタープライズポートフォリオのモダナイゼーションは、開発者が単独で行う作業ではありません。アーキテクトが目標状態を定義します。開発者が実行します。リーダーはレビューと承認を行います。パートナーは大規模に提供します。ボトルネックは、オーケストレーション、ガバナンス、そして社内のセキュリティ境界内のチーム間のコラボレーション能力です。だからこそ、私たちはまず、ソースからターゲットまでの完全なトレーサビリティ、実行するユーザーに依存しない一貫性、既存の IT システムへのコネクターなど、Transform を共同のエンタープライズ基盤として構築しました。 そして本日、新しい S3 コネクタを追加し、IAM ロールをサポートする権限を拡張し、human-in-the-loop とのやりとりを複数の領域に拡大しようとしています。ユーザーはチーム全体でジョブサマリーを見ることができ、次のステップをどの面からでも簡単に通知できます。 4. 聞いて、作って、出荷して、繰り返す。 お客様が初期のユースケースで Transform を使い始めたとき、私たちは彼らが必要としている新しい機能について学びました。移行を行う際には、サーバーを移動するだけではなく、その過程でモダナイズしたいと考えていました。メインフレームでは、顧客は新しいコードを生成するために、言語を増やし、コーディングエージェントとの統合を強化したいと考えていました。Windows ワークロードをモダナイズする際、専門家はトランスフォーメーションの実行方法やプランの編集方法をより細かく制御したいと考えていました。また、お客様は当初の出荷目的以外にも、他の種類の技術的負債を是正したいと考えていました。全体的に見て、お客様はより複雑な移行に取り組むにつれて、反復による制御を強化し、精度と再現性が必要な場合に決定論的アプローチを使用するオプションを求めていました。 本日、私たちは、お客様が Transform でできることをさらに深める機能をすべてのユースケースに導入しています。移行については、VM のコンテナ化やネットワークの再構築など、移行中にお客様がモダナイズできるようになりました。メインフレームのモダナイゼーションでは、PL/I への拡張と Kiro や Claude などのコーディングエージェントとの統合も提供しています。双方向性を高めるため、専門家によるガイダンスと自律的な変革を組み合わせる機能により、Windows のモダナイゼーション機能を強化しました。さらに、組織全体で大規模な技術的負債を是正できる新しいカスタムトランスフォームが数十種類追加されました。 さらに詳しく: 各ユースケースがどのように進化しているか インフラの移行については 、引き続き計画と実施を強化します。あらゆる形式のインベントリをアップロードし、ビジネスコンテキストを追加し、仮説シナリオを検討して、最適化された TCO を数分で算出できます。そして、技術的な制約とビジネス上の制約の両方を考慮して、数千台のサーバーにわたる移行ウェーブを数時間で計画できます。ネットワークやセキュリティ設定を移動すると、プロジェクトが脱線することが多いことがわかりました。オンプレミスネットワークを AWS と同等のネットワークに移行する機能を提供していますが、今回、VPC の最適化、CIDR の適切なサイジング、セキュリティグループの強化、命名の修正など、ネットワークを再構築するための拡張を行っています。これにより、数週間にわたる手作業によるレビューなしにネットワークの移行準備が整います。安全なターゲット環境のプロビジョニングを簡単にするために、ランディングゾーンを自動的に作成して AWS Control Tower と統合するようになりました。また、VMware 以外にも Hyper-V、ベアメタル、クラウドベースのサーバーをサポートするようになりました。モダナイズを希望するお客様は、アプリケーションをコンテナ化して ECS または EKS に移行できます。また、従来の移行ツールである MGN を、プロジェクト指向のアプローチで AWS Transform から手軽に使用できるようにしました。移行後は、構成、検証、コンプライアンスの実施を自動化できるため、何日にもわたる手動のランブックから移行を確定的で繰り返し可能なイベントに変えることができます。また、複数のターゲットアカウントにまたがる、あらゆる商用 AWS リージョンと GovCloud に移行できます。また、発見からデプロイ、移行後の検証まで、すべてのステップが統合され、コンテキストが共有されます。 メインフレームアプリケーションのモダナイゼーションでは 、パイプライン全体でパフォーマンスを向上させ続けました。ファクト生成エージェントは、コード、ランタイムの動作、ビジネスルール、データリネージを分析して詳細な実行グラフを構築し、レガシーコードの意図をビジネスルールとして抽出し、トランスフォーメーション後のコードのすべての機能を元のルールにマッピングして、これまで数ヶ月または数年停滞していたプロジェクトを数週間で完了させます。決定論的分析と AI 駆動の生成を組み合わせることで、これまでベンチマークした中で最も正確で幅広い結果が得られます。私たちは IBM COBOL、VSAM、IMS、Db2 から始め、現在は PL/I にまで拡大しています。PL/I は金融サービス、保険、公共部門で一般的な言語であり、ポインター演算と動的ストレージ割り当てのために歴史的にモダナイゼーションが困難でした。同じ reimagine パターンを使用して、Transform は PL/I ビジネスロジックを構文に依存しない仕様に抽出し、Kiro がインタラクティブに引き継ぎます。開発者は、モダナイズされたアプリケーションがクラウドネイティブなイベント駆動型パターンにデプロイされるまで、生成されたサービス仕様のレビュー、アーキテクチャに関する意思決定の改良、コードとインフラストラクチャの反復など、会話形式でエンジニアリングを進めます。 Windows アプリケーションのモダナイゼーションは 、.NET のアップグレードにとどまりません。エンタープライズ Windows 環境は単なるコードではありません。コード、データベース、アプリケーションの依存関係が絡み合っています。Transform はこれを自律的に処理します。複雑さを評価し、作業を段階的に実行し、トランスフォーメーションを end-to-end で実行します。しかし、アーキテクトが意思決定の指導 (トランスフォーメーションプランの調整、特定の選択肢の上書き、最も複雑な変更の完成) を望む複雑なプロジェクトも見てきました。今では、自律的な流れを断つことなく、いつでも介入し、一歩下がることができます。また、ASP.NET ウェブフォームから Blazor への UI のモダナイゼーションや SQL Server から Aurora PostgreSQL への移行など、フルスタックのモダナイゼーション機能も拡張してきました。拡張されたデータベースモダナイゼーション機能は現在ベータ版で、スキーマ、ストアドプロシージャ、アプリケーションデータアクセスコードなど、スタック内のすべてのオブジェクトをまとめて変換します。始めるのは簡単です。仮想ソースを使用すれば、本番環境データベースへの直接アクセスを待つ必要がなくなります。このワークフローは反復型です。つまり、ある程度の労力で評価を受け、データベース管理者がレビューして承認し、Transform が実行します。構文検証、セマンティック等価性、合成データによる機能検証という 3 段階の検証により、本番データが移動する前に正確性が確認されます。 コードのモダナイゼーションについては 、企業規模で技術的負債をなくすというビジョンに向けて拡大しています。フレームワークの老朽化、EOL (end-of-life) を迎える SDK、依存関係の積み重なりなど、技術的負債は加速しています。また、エージェントが新しいコードを作成するスピードがかつてないほど速くなっているため、顧客は 1 回限りのプロジェクトで可能になるよりも迅速に行動する必要があります。彼らは私たちの既存の Java、Python、Node.js、SDK のアップグレードを使用してきており、お客様の要望により、私たちは何十もの新しいパターンに引き込まれました。現在、Vue.js アップグレード、Scala/Glue アップグレード、Spring Boot アップデート、Log4j から SLF4J、Angular から React へ、Angular から Flutter へ、Progress 4GL から Java へ、PHP リプラットフォームへ、ColdFusion から React/Java へ、Datadog から CloudWatch Monitors へ、JBoss から Spring Boot へ、すぐに使えるトランスフォームを出荷しています。これらはすべて、個々の専門家の手腕に頼ることなく、組織全体やリポジトリ全体に適用できます。そして今、私たちは 3 つの新しいコード評価機能を導入しています。技術的負債の評価は、お客様の優先順位付けに役立ちます。コードリポジトリを指定するだけで、フレームワークの脆弱性、サポート終了後の依存関係、修正すべき重要度など、ポートフォリオレベルの完全な分析が数分で得られます。エージェント対応状況評価では、ドキュメント、パイプライン、テストの完全性をチェックすることで、アプリケーションが実際にどの程度エージェント対応状態にあるかがわかります。モダナイゼーション評価は、クラウドネイティブの成熟へのステップを理解し、AWS ベストプラクティスへの道筋を特定するのに役立ちます。これらの新機能を強化するために、基盤となるエージェントを再設計し、最大 2 倍のパフォーマンスを実現しました。 これから進む道 私たちの使命は、世界のレガシーソフトウェアとインフラストラクチャを継続的にモダナイズすることです。あるワークロードが次に引き込まれます。ある顧客が VM を移行し、トランスフォーメーションが必要な Windows アプリケーションを発見してモダナイズし、コードベースにフレームワークの負債が蓄積されていることに気付きます。このサイクルは決して終わりません。歩調を合わせているサービスは、学習を止めることはありません。 2026 年末までに私たちが実現したい目標はシンプルです。エージェンティックになりたいすべての企業が、専用のプログラムや複数年にわたるロードマップなしで、継続的に Transform を使用してインフラストラクチャとポートフォリオを使える状態できるようにすることです。 モダナイゼーションはプロジェクトではなくバックグラウンドプロセスになります。1 つのワークロードから始めます。サービスはコンテキストを引き継ぎます。次に何をモダナイズするかはあなた次第です。 PS: 5 社の顧客のうち 4 社はすでに事業を拡大しています。次はあなたの番です。 著者 Dr. Asa Kalavade Dr. Asa Kalavade は AWS Transform をリードし、お客様のインフラストラクチャ、アプリケーション、コードの移行とモダナイゼーションを支援しています。以前は、AWS の go-to-market ツールのトランスフォーメーションをリードし、最初の大規模な生成 AI 機能をリリースしました。また、ハイブリッドストレージとデータ転送サービスのマネジメントも担当していました。2016 年に AWS に入社する前、Asa はベンチャーキャピタルによる支援のもと 2 つのスタートアップを設立し、現在もボストンのスタートアップのメンタリングに積極的に取り組んでいます。Asa は、カリフォルニア大学バークレー校で電気工学とコンピューターサイエンスの博士号を取得し、40 件以上の特許を取得しています。 この投稿の翻訳は Mainframe Modernization Specialist Solutions Architect の皆川が担当致しました。原文記事は こちら です。 2026/09/17(木) AWS Mainframe Modernization Day Tokyo 2026 開催のお知らせ メインフレーム基幹系システムの AWS 移行を真剣に検討中のお客様向けの対面イベントを 2026 年 9 月 17 日 (木) に麻布台ヒルズで開催します。参加費は無料です。 詳細・お申し込みは ブログ をご覧ください。

本記事は 2026年7月6日に公開された「 Turn Your Amazon CloudWatch Alarms into Actionable Signals 」を翻訳したものです。 午前2時にアラームが鳴ります。スマートフォンを手に取り、目を細めて通知を見ると、こう書いてあります： 「ALARM: my-service-alarm が ALARM 状態に遷移しました。」 コンテキストなし。アプリケーション名なし。200台のインスタンスのうちどれが問題なのか、そもそもそれが重要なのかすら分かりません。 私もそうでした。誰もがこの経験をしたことがあるはずです。 アラームに対する不満は、「何かがおかしい」と「何をすべきか分かっている」の間のギャップから生まれることが多いです。メトリクス名と閾値しか得られないとき、コンテキストは自分で補うしかありません。どのリソースか、どのアプリケーションか、このサービスはどれくらい重要か？ Amazon CloudWatch アラームは、AWS 環境の問題を検知する最初の防衛線です。このブログ記事では、そのギャップを埋める CloudWatch アラームの設計方法を紹介します。適切なものを監視し、必要なコンテキストを含み、適切な対応をトリガーするアラームです。 適切なデータ – 重要なリソースとメトリクスを監視するようにアラームのスコープを設定し、環境の変化に自動的に適応させ、実際の問題を反映する閾値を設定します。 適切なコンテキスト – 通知に必要な情報を含めます。何が影響を受けているか、どこか、どう対処するか。 適切なアクション – 「メールを送る」を超えて、自動修復、情報を付加した通知、複数ツールが連動し一体化されたインシデント対応へ。 前提条件 この記事に沿って進めるには以下が必要です： Amazon CloudWatch にアクセスできる AWS アカウント 監視対象の既存 AWS リソース（Amazon EC2 インスタンス、AWS Lambda 関数、Application Load Balancer など） CloudWatch アラーム、メトリクス、ダッシュボードを作成・管理する権限 （オプション）タグベースのフィルタリング用に AWS リソースに適用されたリソースタグ 注意：CloudWatch アラーム、ダッシュボード、Amazon EventBridge には AWS 料金が発生します。詳細は Amazon CloudWatch の料金 を参照してください。継続的な課金を避けるため、使い終わったらこれらのリソースを削除してください。 適切なデータ：アラームの対象を重要なものに絞る 次のケースを考えてみましょう。特定の Amazon EC2 インスタンスの CPUUtilization メトリクスに CloudWatch アラームを作成します。問題なく動作します。しかし Amazon EC2 Auto Scaling グループが新しくインスタンスを3台起動すると、新しいインスタンスにはアラームカバレッジがない状態となってしまいます。フリートの75%について監視が欠落した状態です。 あるいは、動的なリソースがあるため、Application Load Balancer の全ターゲットの 平均 レイテンシメトリクスにアラームを作成します。平均は問題なく見えますが、1つのターゲットは5秒のレスポンスを返し、他は50ミリ秒です。平均が問題を隠してしまいます。 単一メトリクスおよび単一集計値に対するアラームは作成・管理が簡単ですが、単一メトリクスに対するアラームは動的な環境でギャップを残し、単一集計値に対するアラームでは平均値により問題が埋もれてしまいます。 動的リソースへの対応 CloudWatch Metrics Insights を使うと、SQL ライクなクエリを書いて、リソース全体のメトリクスを動的に検出・集計できます。インスタンスごとに1つのアラームを作成する代わりに、環境の変化に自動的に適応するクエリで複数リソースにまたがる単一のアラームを作成します： SELECT AVG(CPUUtilization) FROM SCHEMA("AWS/EC2", InstanceId) この Metrics Insights クエリは全ての EC2 インスタンスを自動的にカバーし、手動更新は不要です。EC2 Auto Scaling グループが3台から30台にスケールしても、アラームは適応します。30個の個別アラームを作成・管理する代わりに、1つのアラームだけを管理すれば済みます。 サーバーレスワークロードの場合、 AWS Lambda 関数全体の Duration に対する Metrics Insights クエリを作成することもできます： SELECT AVG(Duration) FROM SCHEMA("AWS/Lambda", FunctionName) コンセプトは同じです。このクエリは Lambda 関数が3個でも30個でもカバーします。 この記事の例では Metrics Insights を使用していますが、 PromQL を使ってメトリクスをクエリ し、クエリにラベルを含めて同じ効果を得ることもできます。 適切なリソースへの絞り込み アラームが動的なリソースに適応するようになりましたが、おそらく特定のアプリケーションや環境をターゲットにしたいはずです。InstanceId のような生のディメンション値では、リソースが何をしているか、どれくらい重要かは分かりません。 カスタムメトリクスの場合、ディメンションを自分で制御できます。Application や Environment などのコンテキストを含め、直接クエリします： SELECT AVG(ProcessingTime) FROM SCHEMA("Custom/PaymentService", Application, Environment) WHERE Application = 'PaymentService' AND Environment = 'Production' Amazon EC2 や AWS Lambda などの AWS サービスは、事前定義されたディメンション（例：InstanceId、FunctionName）でベンダーメトリクスを自動的に発行します。独自の追加ディメンションを追加することはできません。代わりに、 テレメトリ用のリソースタグ でビジネスコンテキストを追加します。 テレメトリでリソースタグを有効にする と、Amazon CloudWatch は既存のリソースタグを Metrics Insights のディメンションとして公開します。リソースに既に適用されているタグ（例：Amazon EC2 インスタンスの Environment=Production や Application=PaymentService）は、WHERE 句や GROUP BY 句で使用可能になります。 SELECT AVG(CPUUtilization) FROM SCHEMA("AWS/EC2", InstanceId) WHERE tag.Environment = 'Production' AND tag.Application = 'PaymentService' これで、アラームは PaymentService アプリケーションに属する本番インスタンスを監視します。それらのタグを持つ新しいインスタンスが起動すると、自動的にアラームに含まれます。死角は生まれず、午前2時に開発環境でアラームが鳴ることもありません。 1つのアラーム、複数のリソース アラームは動的に適応し、適切なリソースをターゲットにするようになりました。しかし、もう1つの問題である問題が平均に埋もれてしまう件を思い出してください。ここで GROUP BY の出番です。クエリに GROUP BY を追加すると、 マルチ時系列アラーム を作成できます。Amazon CloudWatch はクエリ結果の各時系列に対して独立に閾値を評価します。いずれかの時系列が閾値を超えると、フリート平均が正常に見えてもアラームが発火します。 SELECT AVG(CPUUtilization) FROM SCHEMA("AWS/EC2", InstanceId) WHERE tag.Environment = 'Production' AND tag.Application = 'PaymentService' GROUP BY InstanceId GROUP BY を使うと、グラフには複数の時系列（マッチする EC2 インスタンスごとに1つ）が表示されます。これがなければ、単一の集計ラインだけが表示されます。アラーム用のクエリを確認するには、「メトリクスと条件の指定」ステップのグラフで、1つの集計ではなく複数の時系列を評価していることを確認してください。クエリの下にある「Order By」オプションに注意してください。マルチ時系列アラームには必須です。 図1：Metrics Insights クエリが複数のメトリクス時系列を返すアラーム作成画面。 適切なリソースを監視し、それぞれを独立に評価しています。では、どの値でアラームを発火させるべきでしょうか？ 適切な閾値を選ぶ 閾値は「適切なデータ」の最後のピースです。実際の問題をキャッチするアラームと、頻繁に発火しすぎたり、顧客が影響を受けている間も沈黙したままのアラームとの違いを生みます。 静的閾値のアラーム は、ハードリミットのあるメトリクスに適しています。ディスク使用率が100%に近づく、キュー深度が際限なく増大する、常にゼロであるべきエラーカウントなどです。「悪い」値が分かっていれば、設定すればそれで完了です。 しかし、多くのメトリクスには自然な変動があります。ピーク時の CPU 使用率70%は正常かもしれませんが、午前2時の同じ70%は懸念材料です。月曜日に200ミリ秒で正常なレイテンシが、静かな日曜日には異常に高いかもしれません。これらの場合、静的閾値は「敏感すぎる（アラート疲れ）」か「寛容すぎる（インシデント見逃し）」のどちらかを選ぶことを強います。 異常検出 はこの問題を解決します。Amazon CloudWatch はメトリクスのベースラインパターン（日次・週次のトレンドと期待される範囲）を学習し、その学習プロファイルからメトリクスが逸脱したときにアラームを出します。数値ではなく感度を設定します。「閾値をいくつにすべきか分からない」シナリオや、「正常」が時間とともに変化するメトリクスに最適です。異常検出の仕組みの詳細は「 CloudWatch 異常検出の使用 」を参照してください。 適切なコンテキスト：通知をアクション可能にする 「何かがおかしい」と「何をすべきか分かっている」のギャップを思い出してください。コンテキストがそれを埋めます。通知が伝える情報が多いほど、対応は速くなります。十分なコンテキストがあれば、対応を完全に自動化できます。 アラームの種類に関係なく、通知には常にアラーム名と説明、状態変更、変更理由、閾値が含まれます。このうち、名前と説明は完全にコントロールできる2つの要素であり、対応者が最初に見るものです。適切に書かれた名前と説明は多くのコンテキストを伝えることができます。アラーム名は素早いシグナルを与えます：本番、決済、CPU。説明にはドキュメント、ランブック、ダッシュボード、エスカレーションパスへのリンクを記載します。 Alarm Details: - Name: prod-payments-cpu - Description: Alarm on payments service CPU. Impact: Payment processing may slow. Runbook: https://wiki.example.com/runbooks/payment-cpu Dashboard: https://console.aws.amazon.com/cloudwatch/... Escalation: #payments-oncall - State Change: OK -> ALARM - Reason for State Change: Threshold Crossed: 1 out of the last 1 datapoints [3.0705 (15/06/26 12:49:00)] was more than the threshold (90.0) (minimum 1 datapoint for OK -> ALARM transition). - Timestamp: Monday 15 June, 2026 12:54:30 UTC - AWS Account: xxxxxxxxxxxx - Alarm Arn: arn:aws:cloudwatch:us-east-xxxxxxxxxxxx:alarm:prod-payments-cpu ダッシュボード：問題の全体像を見せる アラームは単一の時点で発火します。値は分かりますが、どれくらい速く変化しているか、より広い影響は分かりません。ダッシュボードはより大きな絵を見せることができます。メトリクスの時間的な挙動（スパイクか、徐々に劣化しているか？ いつ変化し始めたか？）に加え、そのアラームが発火したときに関連する情報の表示、つまりアプリケーションの RED メトリクス（Requests、Errors、Duration）と関連リソースです。対応者が簡単にアクセスできるよう、アラームの説明にダッシュボード URL を含めてください。 メトリクスクエリからコンテキストを得る 名前と説明は自分で追加するコンテキストであり、全てのアラームタイプの通知イベントにはアラーム詳細が含まれます。しかし、アラーム通知は自動的にコンテキストも運びます。何が含まれるかはアラームの構築方法に依存します。 単一メトリクスアラーム ：メトリクス名前空間、名前、ディメンション、統計、メトリクス値。 マルチ時系列アラーム（GROUP BY 付き Metrics Insights） ：Metrics Insights クエリ、およびどの時系列が閾値を超えたかを特定する Contributor Attributes。 単一メトリクスアラーム通知は、どのメトリクスが閾値を超えたかを伝えます： Monitored Metric: - MetricNamespace: AWS/EC2 - MetricName: CPUUtilization - Dimensions: [InstanceId = i-xxxxxxxxxxxxxxxxx] - Statistic: Average 例えば、Amazon EC2 CPUUtilization のアラームは InstanceId ディメンションを表示し、Lambda Duration のアラームは FunctionName を表示します。ここで表示される内容は、アラーム作成時に選択したメトリクスとディメンションに依存します。 Metrics Insights クエリで作成されたアラームでは、特定のインスタンスの情報を得る唯一の方法は、クエリで GROUP BY 句を使用することです。通知には Contributor Attributes セクションが含まれ、クエリのどの時系列が閾値を超えたかを正確に示します： Contributor Attributes: - InstanceId i-xxxxxxxxxxxxxxxxx - tag."Environment" Production - tag."Application" PaymentService Threshold: - The alarm is in the ALARM state when the metric is GreaterThanThreshold 90.0 for at least 1 of the last 1 period(s) of 300 seconds. Monitored Metrics: - MetricExpression: SELECT AVG(CPUUtilization) FROM SCHEMA("AWS/EC2", InstanceId) GROUP BY InstanceId, tag.Environment, tag.Application ORDER BY AVG() DESC GROUP BY に InstanceId、tag.Environment、tag.Application を含めたため、Contributor Attributes は3つの値全てを表示します。これが「あるインスタンスが高負荷」と「本番環境の決済アプリに問題がある」の違いです。 複合アラームによる影響レベルのシグナル化 個々のアラームは個々の症状を伝えます。 複合アラーム は複数の症状を単一のヘルスシグナルに要約します。 複合アラームは、ブール論理を使って複数の子アラームの状態を組み合わせます。例えば、エラーレートアラームとレイテンシアラームの 両方 が ALARM 状態のときのみ発火する複合アラームは、エンジニアに2つの別々のアラームではなく影響レベルのシグナル（「サービスが劣化している」）を与えます。 複合アラームはノイズも削減します。10個の子アラームがあり、3個以上が同時に発火しているときだけページしたい場合、複合アラームがそのロジックを処理します。 適切なアクション：通知から解決へ アラームが発火しました。適切なリソースにスコープを合わせ（適切なデータ）、通知は何が影響を受けているかを伝えます（適切なコンテキスト）。そのコンテキスト（アプリケーション、環境、特定のリソース）があるため、通知以上のことができます。自動化できます。 多くの場合、アラームアクションは「誰かにメールが届く」です。しかし、問いかける価値のある質問があります： このアラームが発火したとき、実際に何が起こるべきでしょうか？ アクションを自動化する 一部のアラームは人間が調査、判断、調整する必要があります。これらには、GROUP BY、タグ、ディメンションを使い、迅速な対応に十分なコンテキストを通知に含めてください。 しかし、対応が決定論的な場合（タスクの再起動、フリートのスケール、障害インスタンスの復旧など）、アラームをそのアクションに直結します。Amazon CloudWatch は EC2 アクション（停止、再起動、復旧）、 Amazon EC2 Auto Scaling ポリシー、または AWS Lambda 関数を呼び出せます。人間の介入は不要です。 AWS Well-Architected フレームワーク はこれを明示的に述べています。人間が毎回同じ方法で同じランブックに従うなら、それは自動化の候補になります。 複雑な対応を連動させる Amazon CloudWatch は アラームの状態変更時に Amazon EventBridge にイベントを送信 します。Amazon EventBridge を使えば、これらのイベントを複数のターゲットに送信できます。アラームが発火したとき、同時に以下を実行できます： PagerDuty 経由でオンコールエンジニアにページする チケット管理ツールでインシデントを作成する コンテキストを付加した専用 Slack チャンネルに投稿する 単一のアラームイベントが、インシデント管理ワークフロー全体にわたる連携した対応を開始します。 計画メンテナンス中のアクション抑制 新バージョンのデプロイ、ロードテストの実行、インフラの更新中に、アラームが自動修復を呼び出したり、予期された動作でエンジニアにページしたりすることは望ましくありません。 CloudWatch アラームミュートルール を使えば、事前定義された時間ウィンドウ中にアラームアクションを一時的に抑制できます。 アラームアクションの無効化 （誰かがアラームを再度有効にすることを覚えている必要がある）とは異なり、ミュートルールは特定の時間ウィンドウ用です。アラームは評価と状態変更を続けますが、ミュートウィンドウ中はアクションを呼び出しません。ミュートルールは特定のアラームにスコープできます。デプロイ対象のサービスのアラームをミュートしながら、残りの監視は完全にアクティブのままです。 ミュートルールがなければ、デプロイは不要なアラームノイズを生みます。予期された動作でアラームが発火し、対応者はそれを無視するようになり、アラームシステムへの信頼が損なわれます。 実践的なパターン：CI/CD パイプラインでデプロイ前にミュートルールを作成し、デプロイと安定化の時間をカバーする有効期限ウィンドウを設定します。ウィンドウの期限切れ後にアラームが発火すれば、デプロイノイズではなく実際の問題だと分かります。 全要素の統合 午前2時のアラームに戻りましょう。適切なデータ、適切なコンテキスト、適切なアクションを組み合わせるとこうなります： アラームは GROUP BY とリソースタグによるフィルタリングを使った Metrics Insights クエリを使用するため、フリート全体を自動的にカバーし、適切な環境とアプリケーションにスコープを合わせます。 通知は特定のインスタンス、環境、アプリケーション名を含み、さらに影響の説明とランブックおよび RED メトリクスを表示するダッシュボードへのリンクを含むアラーム説明があります。 アラームアクションは既知の問題に対する自動復旧を呼び出します。復旧に失敗した場合、または自動化できない場合、コンテキストを付加してインシデント管理プロセスにエスカレーションします。 午前2時にアラームが発火します。インスタンスは自動復旧されます。アラームは OK に戻ります。誰もページされません。 まとめ CloudWatch アラームは、適切なリソースを監視し、必要なコンテキストを含み、適切な対応をトリガーするときに最も効果的です。GROUP BY 付き Metrics Insights クエリを使用し、タグと説明で通知を充実させ、可能な場合は対応を自動化することで、アラームをノイズからアクション可能なシグナルに変えることができます。 さっそく始めましょう 実践的なスタートパスを示します： 主要サービスの Amazon CloudWatch 設定で テレメトリでリソースタグを有効にします 。 既存リソースの AWS 推奨アラーム をレビューします。 最も価値の高い静的アラームを GROUP BY と タグベースのスコープ 付き Metrics Insights クエリ に変換します。 明確な静的閾値がないメトリクスに 異常検出 を追加します。 有用なリンク付きの 意味のあるアラーム説明 を書きます。 重要なサービスの ダッシュボード を作成し、アラーム説明にリンクします。 デプロイウィンドウと計画メンテナンス用の アラームミュートルール を設定します。 重要なサービスの 複合アラーム を作成します。個々の症状ではなく影響レベルのシグナルを表面化させます。 既知の解決策に対して 自動アクションを実装 します。人間の判断が必要な問題のために、人間の注意力を温存します。 全てを一度にやる必要はありません。1つのサービスから始め、パターンを正しく構築し、そこから拡張してください。午前2時のあなたが感謝するはずです。 クリーンアップ CloudWatch アラーム、ダッシュボード、EventBridge ルールには AWS 料金が発生します。詳細は Amazon CloudWatch の料金 を参照してください。継続的な課金を避けるため、使い終わったらこれらのリソースを削除してください。 TAGS: Amazon CloudWatch , Best Practices , Management & Governance , Management Tools , Monitoring , observability Helen Ashton Helen Ashton は AWS のシニアカスタマーサクセススペシャリストであり、オブザーバビリティを専門としています。お客様のビジネス課題の解決とクラウドジャーニーの推進を支援することに情熱を注いでいます。仕事以外では、音楽、サイクリング、ガーデニングを楽しんでいます。 Gagandeep Singh Gagandeep Singh は AWS のシニアテクニカルアカウントマネージャーであり、エンタープライズのお客様のクラウドジャーニーを支援しています。18 年以上の IT 経験を持ち、AI とセキュリティに情熱を注いでいます。仕事以外では、写真撮影、旅行、好きなスポーツチームの観戦を楽しんでいます。 翻訳は Technical Account Manager の 桜山 陽平 が担当しました。

本ブログは 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 の統合 は近日提供予定です。 本記事に関するフィードバックがある場合は、以下の コメント セクションからコメントを送信してください。 著者について Chet Kapoor Chet は、Amazon Web Services の Search, Security, and Observability 担当バイスプレジデントです。エンタープライズテクノロジーで 20 年以上、API からクラウド、AI に至るプラットフォームシフトの中で、急成長や買収、IPO を通じて事業を構築・拡大してきました。ビルダー思考と運用経験、お客様志向で、新しいテクノロジーの安全かつ大規模な導入を支援しています。 翻訳は Security Solutions Architect の 松崎 博昭 が担当しました。

本記事は 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 で最初のプラグインをインストールしたりしてみてください。 著者について Libby Clark Libby Clark は AI に注力するプリンシパルオープンソースストラテジストです。 James Ward James Ward は AWS のプリンシパルデベロッパーアドボケイトです。James は世界を飛び回りながら、エンタープライズ開発者が信頼性の高いシステムを構築する方法を学ぶのを支援しています。現在は、Spring AI、Embabel、Strands Agents、Amazon Bedrock、MCP、A2A を用いた AI エージェントシステムを開発者が構築できるように支援することに注力しています。 翻訳は Solutions Architect の吉村が担当いたしました。

本記事は 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 の宇賀神が担当しました。 Jishnu Dasgupta Jishnu Dasgupta は、製造業と自動車業界を専門とする AWS のシニアソリューションアーキテクトです。AWS 上でのアプリケーションの構築、移行、モダナイゼーションを専門としています。その専門知識と経験を活かし、AWS のお客様が最適化された、スケーラブルで目的に適したアーキテクチャを AWS 上で構築できるよう支援しています。 Chetan Dharma Chetan Dharma は、大規模なグローバル企業の技術変革を推進してきた 20 年以上の経験を持つ、シニア AI ソリューションアーキテクトです。投資銀行、物流、自動車、デジタルネイティブ企業といった分野で、現場のエンジニアリングからアーキテクチャ、そして AI 変革のアドバイザーへとキャリアを重ねてきました。

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊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 の商用リージョンで利用できます。 それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon Quick です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

本記事は 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 パネルを開いて、すでにインストールできるものを確かめてみてください。そして、あなた自身の何かをパッケージ化し、何を作ったのかをぜひ教えてください。

みなさん、こんにちは。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 エージェント、つまりテクノロジーランドスケープ全体のツールやデータソースに安全に接続し、ライブのビジネスデータをもとに推論し、自律的にアクションを実行できるエージェントの構築にますます注目しています。世界中のお客様がこのニーズを肌で感じています。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 基盤に合わせた認証フローを設計でき、大規模な入れ替え（リップ&amp;リプレース）は不要です。 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 &amp; Head of IT and the Transformation Office (PLDT &amp; 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 ワークロードをモダナイズし拡張できるよう支援することを専門としています。 <!-- '"` -->

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 に注意してください。そのディレクトリは、このセッションの共有ファイルシステムです。 &nbsp; ステップ 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 &nbsp; のランタイムインスタンスにアクセスし、最初の容量プロバイダーを作成してください。 – seb 原文は こちら です。

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 と入力して、検索範囲を米国のマーケットプレイスに限定します。&nbsp; インラインフィルター属性を拡張し 、 カテゴリ を フットウェア と同じに設定して、検索をフットウェア製品のみに絞り込みます。最後に、 実行 を選択します。 DynamoDB は、フットウェアカテゴリ内で意味的に最も類似している5件の商品を、類似度スコアの高い順に返します。また、そのレスポンスには、商品名や価格などの通常の運用データ属性もあわせて含まれます。類似度スコアの意味は、インデックスに選択した距離関数によって異なります。コサイン距離関数とユークリッド距離関数では、類似度スコア値が低いほど類似度が高く、スコアが 0 の場合はベクトルが同一であることを示します。点積距離関数では、類似度スコアの値が高いほど類似度が高くなります。 API の呼び出しやドキュメントの検索など、ベクトル検索をプログラムで操作するには、お好みの AI コーディングツールで AWS MCP サーバー と プラグイン を試してください。&nbsp;詳細については、 Amazon DynamoDB 開発者ガイドをご覧ください 。 今日から始めよう Amazon DynamoDB のベクトル検索は、一般的に AWS GovCloud (米国) リージョンを含むすべての商用 AWS リージョンで利用できます。リージョンごとの提供状況や今後のロードマップについては、 AWS のリージョン別提供機能 にアクセスしてください。料金の詳細については、 Amazon DynamoDB 料金表ページ をご覧ください。 ぜひ 8 月 5 日から DynamoDB のベクトル検索をお試しください。ご意見やご要望は、 Amazon DynamoDB の AWS re:Post 、または通常ご利用の AWS サポート窓口までお寄せください。 – Esra 原文は こちら です。

統合されたアーキテクチャの「幅広さ」こそが、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 エージェント) &nbsp;── オーケストレーターであり推論エンジンでもあるこのエージェントは、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 の日本語訳です。この記事はソリューションアーキテクトの梅田裕義が翻訳しました。

現在、FinOps プラクティショナーは増え続ける AI ツール群を利用できるようになりました。しかし、それぞれのユースケースに適したツールを組み合わせることこそが、プラクティスを加速させるか、不要な複雑さを持ち込むかの分かれ目になります。AWS は、AI ラインナップの各ツールを、それぞれ異なるコンテキストと異なる種類の作業に向けて設計しています。このブログでは、5 つのツールについての実践的な整理、それぞれをいつ使うべきか、そしてなぜそれが FinOps にとって重要なのかを説明します。 ここで重要なのは、ある仕事をこなせるツールと、専用のツールとの間には意味のある違いがあるという点です。 AWS FinOps Agent は、Cost Optimization Hub および AWS のコストと使用状況データとのネイティブなインテグレーションを備えたフルマネージドソリューションであり、精選され、検証されたインサイトを提供します。このブログで説明されている他のアプローチは、追加の設定やデータ接続が必要であり、マネージドソリューションが持つ深さ、精度、運用面での即応性には及ばない場合があります。最適な選択肢を選ぶ際には、これらのトレードオフを自社の要件と照らし合わせて評価することが重要です。 FinOps プラクティショナーはどのような AI ツールを利用できるか？ AWS FinOps Agent Amazon Quick Kiro Amazon Q （In Console） AWS DevOps Agent それぞれのツールについて、その中核となる目的と理想的なユースケースを見ていきます。 AWS FinOps Agent AWS FinOps Agent とは：コスト異常を根本原因まで調査し、組織全体のコストに関する質問に答え、すでに使用している&nbsp;Jira や Slack&nbsp;などのツール上に直接インサイトを届ける、エージェント型&nbsp;AI&nbsp;ソリューション（現在パブリックプレビュー中）です。 FinOps Agent をいつ使うのか： コスト異常調査： コストのスパイクを関連付けて根本原因と責任者を特定し、オーナーチーム宛の Jira チケットまたは Slack メッセージを作成するのに役立ちます。 自然言語によるコスト問い合わせ： エンジニアが「先月支出が増えたのはなぜですか？」といった質問をして、FinOps チームの関与を必要とせずに、実際の AWS Cost Explore r データに基づいた回答を得られるようにします。 定期的なコストレポート ：ステークホルダーごとに内容を調整したレポートを、そのままプレゼンテーションに使える形式（HTML、PDF、PPT）で、設定したスケジュール（日次／週次／月次）に従って生成します。 最適化の推奨事項 ： AWS Cost Optimization Hub と AWS Compute Optimizer から節約機会を取得し、エンジニアリングチームがすぐに着手できる Jira チケットとしてまとめます。 Amazon Quick Amazon Quick とは：既存のデータソースやツールに接続する、AI&nbsp;を活用したデスクトップおよび&nbsp;Web&nbsp;サイトのコンパニオンです。FinOps&nbsp;にとっての価値は、プラクティショナーがターミナルに触れることもコードを書くこともなく、コストデータ、ダッシュボード、ワークフローに対する会話型のインターフェースを得られる点にあります。 コストデータに接続する方法は 2 つあります。Billing Cost Management MCP (Model Context Protocol) を介して AWS Cost Explorer やその他の請求 API に接続すると、状況に応じたリアルタイムの回答が得られます。一般的なチャットボットの応答ではありません。自社のアカウント、自社のデータ、自社の数値です。あるいは、複数の Payer を持つ組織で Amazon Quick dashboards (CUDOS/CID) を導入している場合は、 Quick Spaces を使用してそこから支出データをクエリできます。CUDOS と組み合わせて Quick を使用する方法については、こちらの ガイド を参照してください。結果が得られたら、それを Slack、メール、その他の ツール に接続して、テキスト、PPT、または必要な形式で関連付けて共有できます。 Quick は、再利用可能なスキル（平易な言葉で記述できる、自動化された多段階のワークフロー）、インタラクティブなアプリ（計算ツール、モデリングツール、数秒で作成できるダッシュボード）、そしてスケジュール実行される監視（毎日のコスト異常ダイジェストを毎朝フィードに配信）をサポートしています。 FinOps で Amazon Quick をいつ使うのか： 「X&nbsp;はいくらかかりますか？」という質問にその場で回答 （料金の確認、サービス比較、影響のモデリング） 複数の Payer をまたいだクエリ： 実際の AWS コストデータに会話形式で問い合わせ（「今月と先月のコスト要因の上位 5 つ」） 手動で掘り下げる代わりに、 Amazon Quick&nbsp;のダッシュボード上の数値について「なぜ」を質問 スキル作成： アカウントのビジネスコンテキストを使用して、チームメイトからのコストに関する質問への回答を自動化 定期的なレポートの自動化： エグゼクティブサマリー、タグ付けコンプライアンス、チャージバックの配分 その場で軽量 アプリ を構築 （Savings&nbsp;Plan&nbsp;の損益分岐点計算ツール、予算バーンレートトラッカー） ステークホルダー向けコミュニケーションのドラフト作成： 責任追及しないコスト通知、エグゼクティブサマリー、トレーニング資料 Kiro Kiro とは：ユーザーと並んで自律的にコードの記述、読み取り、変更を行うエージェント型&nbsp;IDE&nbsp;です。FinOps&nbsp;にとっての価値は、コーディングを高速化できることだけではありません。何かをデプロイする前に、開発ワークフローにコスト意識を組み込めることです。Kiro は、実装の時点でコストの問題を捉えてシフトレフトすることを支援します。そのために&nbsp; Kiro Cost Optimization Power &nbsp;が役立ちます。Kiro&nbsp;Power は、MCP、コストのベストプラクティスを含むステアリングファイル、最適化の機会を自動化するためのフックをまとめたものです。詳細は、動画「 Kiro for Cost Optimization: Agentic AI for&nbsp;FinOps 」をご確認ください。 FinOps で Kiro をいつ使うのか： Infrastructure as Code&nbsp;の構築または変更： Terraform&nbsp;または&nbsp;CDK&nbsp;で構築する際、作業を進めるうちに Kiro が高価なリソースの選択肢にフラグを立て、より安価な代替案（適切なサイズのインスタンス、Graviton、gp2 ではなく gp3）を提案します。 コスト見積もりの生成： Kiro に IaC を分析させ、デプロイ前に毎月の予測コスト内訳を作成してもらうと、計画段階で想定外の出費に気づけます。 Cost Optimization Hub の推奨事項をコードに変える： 推奨事項を取得し、Kiro に変更（インスタンスのサイズ変更、ライフサイクルポリシーの追加、アイドルリソースの削除）をリポジトリへ直接実装させ、レビュー用にプルリクエストを作成させます。 コード全体のリソースに一括タグ付与： ファイルを手動で編集する代わりに、コードベース内のすべてのリソースに一貫したコスト配分タグ付け戦略（コストセンター、プロジェクト、環境）を 1 回で適用できます。 出力がコード、設定、またはデプロイメントアーティファクトであるあらゆる技術的な FinOps タスクの自動化： タグ付けを強制するポリシー、コストガードレールとなるSCP、予算アラーム、または未使用リソース用のスケジュール実行されるクリーンアップスクリプトを作成します。 1&nbsp;つのプロジェクトについて複数アカウントにまたがるコストをクエリ： Cost&nbsp;Explorer&nbsp;の請求ビューを使用して、支出を&nbsp;1&nbsp;つのプロジェクトに絞り込み、Kiro&nbsp;に数値の取得と要約、およびその数値に基づく対応を依頼します。 Amazon Q Amazon Q （in the AWS Console）とは：AWS&nbsp;マネジメントコンソールに直接組み込まれた、生成&nbsp;AI&nbsp;によるコスト管理アシスタントです。AWS&nbsp;への支出について自然な言葉で質問すると、分析、可視化、実行可能な推奨事項が得られるため、複数のツールを行き来する時間を削減できます。主な利点は、Amazon Q がお客様のアカウント内で動作するため、ワークロードのすべての要素とそれらの相互作用を把握できることです。 FinOps で Amazon Q をいつ使うのか コンソール内での根本原因のコスト調査： 「先週、コストが増えたのはなぜですか？」と聞くと、Q が複数のソースから自律的にデータを収集し、仮説を検証し、変化の背後にある特定のサービス、アカウント、および使用量の要因を特定します。 節約機会の発見： Cost Optimization Hub と Compute Optimizer から、サイズ適正化、アイドルリソース、コミットメントベースの割引に関する推奨事項を 1 つの会話で明らかにします（例：「コスト最適化の機会として上位のものは何ですか？」）。 オンデマンドのコスト見積もり： 「ダブリンの&nbsp; Amazon Simple Storage Service &nbsp;(S3) に 1 PB&nbsp;を保管するにはどれくらいの費用がかかりますか？」といった料金と予測に関する質問に答えます。コンソールから離れずに構築前のコストモデリングを行えるため、この機能が役立ちます。 セルフサービスのコスト可視化： Amazon Q が Cost Explorer のフィルターを自動更新できるようになったため、チャートやテーブルなどを動的に作成することも、Cost Explorer&nbsp;経由で作成することもできます。 AWS DevOps Agent AWS DevOps Agent とは：いつでも対応できるチームメイトとして機能するフロンティア&nbsp;AI エージェントです。本番環境のインシデントを自律的に調査し、オブザーバビリティスタック、デプロイパイプライン、コードリポジトリにまたがるシグナルを相互に関連付けることで根本原因を特定し、将来の問題を防ぐための改善を積極的に推奨します。現在は GA で、2 か月の無料トライアルがあります。DevOps Agent は FinOps にとどまりませんが、スキルとデータへのアクセスを提供することで、コストを意識した状態を保たせることができます。動画「 AWS DevOps Agent for FinOps 」をご確認ください。 FinOps で AWS DevOps Agent をいつ使うのか 自動インシデント調査： CloudWatch&nbsp;のアラームが発生すると、エージェントはすぐに調査を開始できます。そのため手動でのトリアージが不要になり、エージェントがログ、メトリクス、トレース、最近のデプロイを相互に関連付けて、根本原因を数時間ではなく数分で特定します。インフラストラクチャにサイズ適正化の変更を加えている場合は、DevOps Agent に使用状況への影響を監視してもらうことで、問題が起きていないかを確認できます。 ダウンタイムのコスト削減： インシデントを 3〜5 倍速く 解決することで、停止による収益や生産性への影響を軽減できます。これは多くの場合、組織内で追跡されていない最大のクラウドコストです。 インフラストラクチャの推奨事項についてコストを念頭に置く： エージェントは過去のインシデントを毎週分析して改善を提案します。DevOps Agent&nbsp;に、コストも考慮すべき要素であると伝えておけば、最適化された改善案を探し、事後対応型から計画的な最適化作業へと支出をシフトするのに役立ちます。 まとめ：FinOps ペルソナに合った適切なツールを選ぶ それぞれのツールが何をするのかを知ることと、特定の場面でどのツールを使うべきかを知ることは別のことです。下のグリッドは、6 つの FinOps ペルソナ （行）と 5 つの AI ツール（列）をマッピングしています。各セルには、適切なデータ接続を前提として、そのツールで使用するサンプルプロンプトが各ペルソナの視点から書かれています。クイックリファレンスガイドとして活用してください。自分の役割を見つけ、行を横に見ていき、各ツールが日常業務にどのように役立つかを確認しましょう。一部のツールは機能が重複していることに気づくでしょう。どのツールが最適かは、どこで作業しているか、何を作ろうとしているのか、そしてどれだけ深く掘り下げる必要があるのかによって決まります。 ペルソナ別の FinOps AI ツールのプロンプト ペルソナ AWS FinOps Agent Amazon Quick Kiro Amazon Q AWS DevOps Agent FinOps Practitioner 「CRON&nbsp;自動化を使用して、いずれかのチームの&nbsp;1&nbsp;日の支出が&nbsp;30&nbsp;日間の移動平均を&nbsp;25%&nbsp;超えたら通知してください。根本原因分析を行い、オーナーチーム向けの&nbsp;Jira&nbsp;チケットを作成してください。」Jira&nbsp;インテグレーションが必要です 「フレームワークの進捗状況を追跡するために、タグ付けコンプライアンス、コミットメントカバレッジ率、およびチームレベルの導入指標を含む FinOps 成熟度の概要を作成してください。」 「毎週すべてのアカウントをスキャンし、チームの FinOps 成熟度を評価し、改善アクションプランを生成するタグ付けコンプライアンスの自動化を構築してください。」 「コミットメントカバレッジが最も低く、無駄が最も多いチームはどれですか？今四半期の FinOps 支援の重点分野を優先的に決めるのを手伝ってください。」 「チームが FinOps のベストプラクティスに従わなかったことが原因で発生した前四半期のインシデントを分析してください。FinOps 文化への投資のビジネスケースを構築するのを手伝ってください。」 Engineering 「過去 3 か月で最大のコスト要因は何でしたか？アーキテクチャを大きく変更せずにコストを節約するにはどうすればいいですか？」 「リソーストラッカーを構築してください。サービス別のデプロイあたりのコスト、環境別のアイドルリソースインベントリ、オートスケーリングの効率指標を含めてください。」 「コスト最適化の機会について、この Terraform モジュールをスキャンしてください。サイズが大きすぎるインスタンス、オートスケーリングが設定されていないもの、コスト配分タグが付いていないリソースにフラグを付けてください。タグ付けを自動修正し、コスト削減のためのアーキテクチャ変更を提案してください。」 「us-east-1&nbsp;のどの&nbsp;Amazon EC2&nbsp;インスタンスが&nbsp;10% の CPU&nbsp;使用率を下回っていますか？サイズ適正化による推定月間節約額はどれくらいですか？」 「オートスケーリンググループは、オフピーク時にオーバープロビジョニングになっています。CloudWatch のメトリクスを分析し、SLO の目標を維持しながら、スケジュールベースまたは予測に基づくスケーリングポリシーを推奨してください。」 Finance 「標準テンプレートを使用して、CFO 向けの PowerPoint ファイナンスレポートを生成してください。Slack 経由で毎月第 1 月曜日の午前 8 時に配信をスケジュールしてください。」Slackインテグレーションが必要です 「ファイナンスレポートを設計してください：事業部別の毎月の実績対予算、予測精度の追跡、チャージバック／ショーバックビュー、請求書の照合状況。」 「毎月の CUR／FOCUS ファイルに基づいて、コストセンター、環境、ビジネスユニットごとにグループ化されたコスト配分レポートを生成してください。」 「第 1 四半期と第 2 四半期のサービス別の前月比コスト差異を、連結アカウント別に表示してください。20% を超える差異を強調表示し、承認された予算基準を超える差異があればフラグを付けてください。」 「インフラ支出をサービスの信頼性指標と関連付けてください。投資不足による財務リスクを定量化してもらえれば、インシデント関連の費用に備えて正確な予算準備金を積むことができます。」 Product 「今月、ML 推論コストが 40% 増加した理由は何ですか？支出が当社の戦略的投資の優先事項と一致しているかどうかを判断できるように、製品機能とユーザーセグメントごとに分類してください。」 「アクティブユーザー 1 人あたりのコストの傾向を、6 か月にわたって製品ラインごとにビジュアライゼーションで示してください。ユーザー 1 人あたりの収益と重ね合わせ、ユニットエコノミクスの観点でどの製品が改善または悪化しているかを示してください。投資の優先順位付けに役立てます。」 「新機能リリースのコストモデルを作成してください。1 万人、5 万人、10 万人のユーザー規模でのインフラストラクチャコストを見積もり、各規模での ROI を示すビジネスケース文書を生成してください。」 「過去 90 日間で product:ProdA とタグ付けされたリソースの総費用はいくらですか？ユーザーあたりのコストを計算してください。当社の価格モデルがビジネスケースを裏付けていることを検証できます。」 「ProdA&nbsp;のコストパフォーマンス比を評価してください。コンピューティングに&nbsp;20%&nbsp;多く投資した場合、信頼性の向上はどのくらい見込まれますか？」 Procurement 「月額 5,000 ドル以上の節約額で絞り込んだ最適化の推奨事項を見せてください。次のベンダー契約交渉に使用できる調達概要を作成してください。」 「ベンダーコミットメントのポートフォリオダッシュボードを作成してください。すべてのテクノロジーカテゴリにわたって追跡できるようにしてください。」 「MCP&nbsp;で現在の&nbsp;Savings Plans と RI ポートフォリオを問い合わせてください。90&nbsp;日後に期限が切れる契約を特定し、更新シナリオをモデル化し、レバレッジポイントを含む交渉概要を作成してください」AWS Billing and Cost Management MCP&nbsp;サーバーインテグレーションが必要です 「現在のコミット済み支出レートをオンデマンド料金と比較してください。ベンダー交渉に役立つ情報として、当社が過剰にコミットしている箇所とカバレッジにギャップがある箇所を特定してください。」 「特定されたリソースに基づいてインスタンスの一覧を作成してください。Graviton または Spot インスタンスの恩恵を受けるインスタンスファミリーとリージョンはどれですか？」 Leadership 「毎日午前 8 時に Slack のメッセージを送り、昨日の支出と戦略的予算、そして経営陣の注意が必要な異常を含めてください」 「すべての&nbsp;BU&nbsp;のクラウド ROI、コスト効率比、単価の傾向を示すエグゼクティブスコアカードを作成してください」 「自動化された経営層向けアラートシステムを構築してください。予算の 80% に達したときにマネージャーに通知を送り、どの取り組みが支出に影響を与えているかを伝えてください。」 「戦略的な概要を教えてください。12 か月間の AWS 総支出の傾向、次の四半期の予測、成長を牽引する上位 3 つのサービス、そしてクラウドへの投資と収益の伸びの相関関係です。」 「戦略的リスクレポートを生成してください。当社のインフラ投資がビジネスの優先事項と一致していない箇所に焦点を当ててください。」 結論 最も成果を上げている FinOps プラクティショナーは、AI ツールの機能を成果に合わせて選び、ビジネス価値が確実に提供されるようにしています。今いるところから始めましょう。コストのスパイクを手動で調査するのに何時間も費やしている場合は、AWS FinOps Agent を試してみてください。ステークホルダーからの「X はいくらかかりますか？」という場当たり的な質問に追われているなら、コンソールの Amazon Q を案内するか、Amazon Quick を設定してください。開発者がコストガードレールなしでリソースをデプロイしている場合は、Kiro から始めてもらいましょう。そして、既製の選択肢のどれも自社独自のワークフローに合わない場合、それがまさに Amazon Bedrock の出番です。 FinOps&nbsp;を取り巻く&nbsp;AI&nbsp;の状況は急速に進化しています。早い段階で実験に取り組むプラクティショナーこそが、人員を増やさずに影響力を広げられるようになります。これらのツールはすべて価格体系が異なるため、使い始める前に必ず確認してください。完璧なタイミングを待たないでください。小さく始めて、早く学び、繰り返してください。まずは、このブログの各所でリンクしているツールを見てみてください。また、より実践的なコスト最適化のガイダンスについては、「The Keys to AWS Optimization」を参照してください。 翻訳はテクニカルアカウントマネージャーの加須屋 悠己が担当しました。原文は こちら です。 Steph Gooch Steph は Sr. Optimization Solutions Architect Advocate&nbsp;です。現在および将来の&nbsp;AWS 支出を最適化する方法についてお客様を導く、当該分野の専門家です。お客様が請求データや使用状況データを整理して解釈し、そのデータから実用的なインサイトを特定し、コストを企業文化に組み込むための持続可能な戦略を策定できるよう支援しています。以前のキャリアでは、ビッグ 4 の 1 社で FinOps チームを率いていました。 Jenny Shen Jenny&nbsp;は、AWS&nbsp;で通信・メディア・エンターテインメント分野を担当するソリューションアーキテクトです。お客様が本番環境に対応したシステムを構築できるよう支援し、チームによるクラウドワークロードの運用を簡素化する方法を見つけることに情熱を注いでいます。以前のキャリアでは、ビッグ 4 の 1 社の FinOps プラクティスで働いていました。

Amazon DynamoDB を運用データに使用しているアプリケーションの多くは、ベクトル類似性検索も必要としています。これまでは、別途ベクトルデータベース、同期パイプライン、そしてそれらに伴うアーキテクチャの複雑さとコストの増加が必要でした。DynamoDB は ネイティブベクトル検索をサポート するようになりました。ベクトル埋め込み (embedding) をアプリケーションデータと一緒に保存し、DynamoDB で直接類似性検索を実行できます。これにより、単一のテーブルが運用データストアとベクトルストアの両方の役割を果たします。 この記事では、DynamoDB のネイティブベクトル検索を紹介し、研究論文のアブストラクトに対するセマンティック検索アプリケーションを構築します。 Amazon Bedrock で埋め込みを生成し、DynamoDB に保存し、セマンティックに検索します。また、コストを見積もり、コントロールできるように、ベクトル検索がどのように課金されるかについても説明します。 なぜ DynamoDB にベクトルを保存するのか 運用データを 1 つのデータベースに、ベクトル埋め込みを別のベクトルストアに維持することには、次のような課題があります。 データ同期 – ベクトルをソースデータと同期させ続けることは運用オーバーヘッドを増やし、古い結果を返すリスクがあります。 高いレイテンシー – ベクトルストアで最近傍を見つけた後、実際のアイテムデータを取得するためにプライマリデータベースへのラウンドトリップが必要になります。 コスト増加 – 1 つで両方の目的を果たせるところを 2 つのデータベースを実行して料金を払う必要があります。 アーキテクチャの複雑さ – サービスが増えると障害モードも運用も増えます。 DynamoDB ベクトル検索では、ベクトルをアイテムの属性として保存でき、これらの課題に対処できます。ベクトルインデックスで類似性検索を実行すると、DynamoDB は結果と一緒にアイテムデータを返します。他の場所で ID を検索する必要はありません。 主なメリット サーバーレスかつフルマネージド – プロビジョニング、パッチ適用、スケーリングするインフラストラクチャはありません。ベクトルインデックスと検索は自動的にスケールします。 ワークロードに応じてスケール – ベクトル検索は、DynamoDB が運用ワークロードをスケールするのと同様に水平方向にスケールするため、インデックス内で数兆のベクトルを保存および検索できます。 予測可能な低レイテンシーのパフォーマンス – データセットとスループットが増加しても、類似性検索は一貫したレイテンシーで実行されます。 既存データで動作 – 既存のテーブルにベクトルインデックスを追加し、DynamoDB にすでに保存されているアイテムにベクトル属性を追加します。あとは DynamoDB が処理します。 組み込みのフィルタリング – インデックスの検索スキーマで定義された属性でフィルタリングと組み合わせてベクトル類似性を利用できます。 使用量に応じた支払い – DynamoDB の課金モデルに合わせて、使用した分だけ支払います。 ユースケース DynamoDB のネイティブベクトル検索は、すでに DynamoDB をプライマリデータストアとして使用しており、アーキテクチャのオーバーヘッドを追加せずにデータをセマンティックに検索したいアプリケーションに適しています。一般的なユースケースには次のようなものがあります。 セマンティック検索 – データに正確なキーワードが現れない場合でも、意味に基づいて自然言語クエリと一致するアイテムを見つけます。 レコメンデーションエンジン – 説明、画像、またはユーザーの行動のベクトル的な近さに基づいて類似アイテムを提案します。 検索拡張生成 (RAG) – 大規模言語モデル (LLM) にとって最も関連性の高いコンテキストを取得し、応答の品質を向上させ、ハルシネーションを減らします。 エージェント記憶 – 会話の要約、学習した事実、過去の決定を埋め込みとして保存し、ベクトル検索で最も関連性の高いものを取得することで、AI エージェントに長期記憶を与えます。 異常検知と不正検知 – ベクトルを比較して、通常のクラスターから大きく外れているトランザクションや行動、または既知の不正パターンに近いものをフラグ付けします。 ソリューション概要 このウォークスルーでは、Hugging Face ウェブサイトの arxiv-abstracts-2021 データセット と、埋め込みを生成する Bedrock を使用して、研究論文のアブストラクトに対するセマンティック検索アプリケーションを Python で構築します。結果は、 「ブラックホール合体からの重力波の検出」 のようなクエリに応答できる DynamoDB テーブルとなります。論文本文に該当の単語が現れない場合でも、最も関連性の高い論文を返します。 以下の図はアーキテクチャを示しています。データを投入するために、アプリケーションは Bedrock で各アイテムの埋め込みを生成します。次に、アイテムをその埋め込みと共に、ベクトルインデックスを持つ DynamoDB テーブルに保存します。検索するには、アプリケーションは Bedrock を使用して自然言語クエリの埋め込みを生成し、その埋め込みでベクトルインデックスをクエリして、最も関連性の高い論文を返します。 図 1: Amazon Bedrock からの埋め込みで DynamoDB ベクトルインデックスにデータを投入して検索する 大規模な一致を素早く見つけるために、ベクトルインデックスは近似最近傍 (ANN) 検索を使用します。データセットが大きくなるにつれて、格納されているすべてのベクトルに対してクエリを比較することは非常に高価で遅くなります。ANN は代わりに、少しの正確性を大幅な速度向上と引き換えにします。真の最近傍に近い結果を返しつつ、検索を高速に、コストを予測可能に保ちます。 ウォークスルーは 3 つのステップで構成されます。 ベクトルインデックスを持つ DynamoDB テーブルを作成する。 Bedrock で埋め込みを生成し、テーブルにデータを投入する。 自然言語クエリでベクトルインデックスを検索する。 このウォークスルーの完全に実行可能なコードは、 GitHub リポジトリ で入手できます。 前提条件 このウォークスルーには以下が必要です。 AWS アカウント。 Python 3.12 以降。 環境用に設定された AWS 認証情報で、DynamoDB および Bedrock API を呼び出す権限を持つもの。 AWS リージョンでの Bedrock と Amazon Titan Text Embeddings V2 モデルへのアクセス。モデルへのアクセスをリクエストする手順については、 Bedrock ドキュメント を参照してください。 DynamoDB ベクトル検索のサポートを追加する AWS SDK for Python (Boto3) バージョン 1.43.64 以降。 ステップ 1: ベクトルインデックスを持つ DynamoDB テーブルを作成する ベクトルインデックスはテーブル作成の一部として定義できます。ベクトルインデックスは、埋め込みを保持する属性、次元数、および距離関数を指定します。DynamoDB の他のセカンダリインデックスタイプと同様に、インデックスに射影する属性も指定します。 UpdateTable API で既存のテーブルにベクトルインデックスを追加することもできます。すでに保存されているデータでベクトル検索を使用するためにテーブルを再作成する必要はありません。 以下のコードはテーブルとそのベクトルインデックスを作成します。 import boto3 dynamodb = boto3.client('dynamodb') # ベクトルインデックスを持つテーブルを作成する dynamodb.create_table( TableName='Papers', AttributeDefinitions=[ {'AttributeName': 'paper_id', 'AttributeType': 'S'}, ], KeySchema=[ {'AttributeName': 'paper_id', 'KeyType': 'HASH'}, ], VectorIndexes=[ { 'IndexName': 'VectorIndex', 'VectorAttribute': {'AttributeName': 'embedding'}, 'Dimensions': 1024, 'DistanceFunction': 'DOT_PRODUCT', # COSINE | DOT_PRODUCT | EUCLIDEAN 'Projection': { 'ProjectionType': 'ALL', # ALL | KEYS_ONLY | INCLUDE } } ], BillingMode='PAY_PER_REQUEST' ) print("Table 'Papers' created with vector index. The table will be ready shortly.") 以下の設定の選択肢を検討してください。 Dimensions – インデックス内のベクトルの長さ。この値は埋め込みモデルの出力と一致する必要があります。DynamoDB は最大 4,096 次元のベクトルをサポートします。 Distance function – DynamoDB がベクトルを比較し、類似性で結果をランク付けするために使用する尺度。この例では、埋め込みが生成時に単位ベクトルに正規化されるため (ステップ 2 参照)、 DOT_PRODUCT を使用します。単位ベクトルの場合、ドット積はコサイン類似度と等しくなるため、 DOT_PRODUCT は COSINE と同じランキングを提供しつつ、コサインの内部正規化ステップをスキップします。ベクトルがまだ正規化されていない場合は COSINE を使用します (内部で正規化するため)。マグニチュードが重要な場合は EUCLIDEAN を使用します。 COSINE と EUCLIDEAN では、スコアが低いほど類似性が高いことを示します。 DOT_PRODUCT では、スコアが高いほど類似性が高いことを示します。 Projection – この設定は、どの属性がインデックスにコピーされ、したがって検索結果として返せるかを決定します。ベクトルとベーステーブルのキー属性は含まれます。 INCLUDE はリストされた属性を追加し、 ALL はすべてを追加し、 KEYS_ONLY は何も追加しません。この例では ALL を使用しており、検索が単一の呼び出しでタイトル、アブストラクト、著者を含む完全な論文レコードを返します。多数または大きな属性を持つワークロードでは、必要なもののみを射影する INCLUDE を検討してください。これにより、インデックスが小さくなり、検索が安くなります。 インラインフィルター (オプション) – ベクトル検索は、検索中に射影された属性の組み合わせでフィルタリングできます。この例ではインラインフィルタリングを使用しません。これは別のブログ記事で扱います。 パーティションキー (オプション) – ベクトルインデックスの全体的なスループットをスケールし、大規模なデータセットの検索あたりのコストを削減します。ベクトルインデックスは分散されているため、パーティションキーを定義するかどうかに関係なく水平方向にスケールします。インデックスのパーティションキーを定義すると、すべてのベクトル検索でその値を提供する必要があります。DynamoDB はその後、その値を持つアイテムを保持するインデックスの部分に検索を制限します。これにより、DynamoDB が応答するために処理するデータが少なくなるため、検索のコストが削減されます。スループットのクォータはパーティションキーの値ごとに適用され、パーティションキーの各異なる値には独自のクォータが与えられます。したがって、パーティションキーを定義することで、インデックスが維持できる書き込みおよび検索の全体的なスループットも上がります。この例ではパーティションキーを使用しないため、すべての検索がインデックス全体をカバーします。パーティションキーの使用は別のブログ記事で扱います。 テーブルとベクトルインデックスの作成は非同期で行われます。データをロードする前に、 DescribeTable API を使用して、テーブルとインデックスが ACTIVE であり、バックフィルが完了していることを確認します。 import time def wait_until_active(table_name, index_name): while True: table = dynamodb.describe_table(TableName=table_name)['Table'] table_status = table['TableStatus'] # 対象のベクトルインデックスを検索 index_status = None backfilling = False for vi in table.get('VectorIndexes', []): if vi['IndexName'] == index_name: index_status = vi['IndexStatus'] backfilling = vi.get('Backfilling', False) break print(f"Table: {table_status} | Vector index: {index_status} | Backfilling: {backfilling}") if table_status == 'ACTIVE' and index_status == 'ACTIVE' and not backfilling: print("Table and vector index are ready.") return table time.sleep(5) table = wait_until_active('Papers', 'VectorIndex') テーブルの準備ができると、テーブルとインデックスは ACTIVE を報告し、 Backfilling: False となります。 Table: CREATING | Vector index: CREATING | Backfilling: False Table: ACTIVE | Vector index: ACTIVE | Backfilling: False Table and vector index are ready. ステップ 2: 埋め込みを生成してテーブルにデータを投入する 次のステップでは、データセットから最初の 1,000 件の論文を読み込み、Bedrock (Amazon Titan Text Embeddings V2) でベクトル埋め込みを生成し、すべてを DynamoDB に保存します。 import boto3 import gzip import json import requests DATASET_URL = 'https://huggingface.co/datasets/gfissore/arxiv-abstracts-2021/resolve/main/arxiv-abstracts.jsonl.gz' SAMPLE_SIZE = 1000 # 最初の 1K 論文のみを含める def clean(text): """空白と改行を単一のスペースに折りたたむ""" return ' '.join((text or '').split()) def load_papers(): """データセットをストリームし、最初の SAMPLE_SIZE 論文のみを読み込む ファイルは gzip 圧縮された JSON Lines コーパス (約 940 MB) です。ストリーミングは、 すべてをダウンロードするのではなく、SAMPLE_SIZE レコードに必要なバイト数のみを読み込みます。 """ papers = [] headers = {'User-Agent': 'aws-dynamodb-vector-search-sample'} with requests.get(DATASET_URL, stream=True, headers=headers) as resp: resp.raise_for_status() # Hugging Face は不透明な .gz ボディを提供するため、明示的に解凍します。 resp.raw.decode_content = False with gzip.GzipFile(fileobj=resp.raw) as gz: for _, line in zip(range(SAMPLE_SIZE), gz): papers.append(json.loads(line)) return papers # クライアントを初期化 bedrock = boto3.client('bedrock-runtime') dynamodb = boto3.client('dynamodb') def generate_embedding(text): """Amazon Bedrock Titan Embeddings V2 を使用してベクトル埋め込みを生成する""" response = bedrock.invoke_model( modelId='amazon.titan-embed-text-v2:0', contentType='application/json', accept='application/json', body=json.dumps({ # Titan の入力上限 8,192 トークン以下に収めるために切り詰めます。 # 20,000 文字は安全なマージンを残します。 'inputText': text[:20000], 'dimensions': 1024, # ベクトルインデックスの設定と一致させる 'normalize': True }) ) result = json.loads(response['body'].read()) return result['embedding'] papers = load_papers() print(f"Loaded {len(papers)} papers. Generating embeddings and writing to DynamoDB...") # 埋め込み付きで論文を DynamoDB に書き込む for i, paper in enumerate(papers): title = clean(paper.get('title')) abstract = clean(paper.get('abstract')) # 豊かな埋め込みのためにタイトルとアブストラクトを結合 text_to_embed = f"{title}. {abstract}" embedding = generate_embedding(text_to_embed) # 埋め込みを数値のリストとして保存 embedding_list = {'L': [{'N': str(v)} for v in embedding]} dynamodb.put_item( TableName='Papers', Item={ 'paper_id': {'S': paper['id']}, 'title': {'S': title}, 'abstract': {'S': abstract}, 'authors': {'S': clean(paper.get('authors'))}, 'embedding': embedding_list, # ベクトル属性 } ) if (i + 1) % 100 == 0: print(f" Processed {i + 1}/{len(papers)} papers...") print(f"Done! {len(papers)} papers stored with embeddings.") この例では、論文のタイトルとアブストラクトを一緒に埋め込むことで、論文の内容をキャプチャするテキスト表現を作成します。「画像を認識するためにコンピュータを訓練する」という検索クエリは、画像分類や物体検出に関する論文にマッチします。意味が近ければ、タイトルにその正確な単語が現れなくてもマッチします。タイトルとアブストラクトを埋め込むのは、それらが一緒に論文の核心的な意味を持つからです。著者はアイテムに引き続き保存されるため、各結果と一緒に返されます。 このスクリプトは論文を一度に 1 つずつ処理するため、1,000 件すべての論文をロードするのに約 2〜4 分かかります (1 論文あたり数百ミリ秒)。その時間のほとんどは Bedrock の埋め込み呼び出しに費やされます。 ベクトルインデックスにデータを投入する各書き込みは、ベクトル書き込み容量も消費します。 PutItem の呼び出しに ReturnConsumedCapacity='INDEXES' を設定して、ベクトル書き込みのコストを確認します。応答の ConsumedCapacity オブジェクトは、テーブル自身の書き込み容量と並んで、 VectorIndexes マップの下に各ベクトルインデックスで消費された VectorWriteRequestBytes を報告します。 TOTAL はテーブルの書き込み容量のみを返しベクトルインデックスのコストは省略されるため、 TOTAL ではなく INDEXES を使用してください。 ReturnConsumedCapacity='INDEXES' を設定すると、返される ConsumedCapacity は次のようになります。 { "TableName": "Papers", "CapacityUnits": 5.0, "Table": { "CapacityUnits": 5.0 }, "VectorIndexes": { "VectorIndex": { "VectorWriteRequestBytes": 4820.0 } } } テーブル自身の書き込み容量とベクトルインデックスの書き込みコストは別々に報告されるため、書き込みのコストのどれだけがベクトルインデックスの維持から発生しているかを確認できます。このコストの課金方法と価格設定については、 Amazon DynamoDB の料金ページ をご覧ください。 ステップ 3: ベクトルインデックスを検索する データがロードされると、テーブルはセマンティック検索の準備が整います。以下のコードでは、ステップ 2 の generate_embedding 関数を使用して自然言語クエリを埋め込み、 SearchVectors API を呼び出して最も類似する論文を見つけます。 import boto3 import json bedrock = boto3.client('bedrock-runtime') dynamodb = boto3.client('dynamodb') def search_papers(query_text, top_k=5): """セマンティック類似性を使用して論文を検索する""" # 検索クエリの埋め込みを生成 query_embedding = generate_embedding(query_text) # 検索ベクトルは数値のリストで、保存された属性と同じ形状 search_vector = [{'N': str(v)} for v in query_embedding] # ベクトル検索を実行 response = dynamodb.search_vectors( TableName='Papers', IndexName='VectorIndex', SearchVector=search_vector, TopK=top_k, ReturnConsumedCapacity='INDEXES', ) return response # サンプル検索 queries = [ "detecting gravitational waves from black hole mergers", "improving the efficiency of solar cells", "quantum error correction for fault-tolerant computing", ] for query in queries: print(f"\nQuery: \"{query}\"") print("-" * 50) response = search_papers(query, top_k=3) for rank, result in enumerate(response['SearchResults'], 1): item = result['Item'] score = result.get('Score', 'N/A') title = item['title']['S'] print(f" {rank}. {title} (score: {score})") # 応答は、クエリが処理したベクトル検索のバイト数を報告する consumed = response.get('ConsumedCapacity', {}) print(f" VectorSearchRequestBytes: {consumed.get('VectorSearchRequestBytes')}") SearchVectors の応答には SearchResults リストが含まれます。各要素は 2 つの部分を持ちます。 Item – ベクトルインデックスから一致したアイテムの射影された属性。 Score – インデックスの距離関数に基づいて、結果がクエリベクトルにどれだけ近いかを示す類似性スコア。 ReturnConsumedCapacity を INDEXES または TOTAL に設定すると、応答には、クエリが処理した VectorSearchRequestBytes を報告する ConsumedCapacity オブジェクトも含まれます。デフォルトの NONE は、これを省略します。ベクトル検索はベクトルインデックスからのみ読み取るため、内訳を出す別のベーステーブル容量はありません。ここでは、 INDEXES と TOTAL は同じ数値を返します。これは、書き込みとは異なります。書き込みでは、 INDEXES のみがベーステーブルの書き込みに加えてベクトルインデックスのコストを露出します。 デフォルトでは、ベクトル属性はアイテムと一緒に返されません。その理由と、リクエストする方法については「知っておくべきこと」パートをご覧ください。 ベクトルインデックスの使用量はどのように課金されるか ベクトルインデックスは、アイテムを保持する基礎となるテーブルに対する標準の DynamoDB 課金に加えて、3 つの次元で課金されます。インデックスに書き込むデータ、検索時に処理されるデータ、および保存するデータに対して料金が発生します。3 つすべてがバイトごとに計測され、GB ごとに課金されるため、プロビジョニングする容量ユニットはなく、各オペレーションが実行する作業に比例してコストがスケールします。 ベクトル書き込みリクエスト – ベクトルインデックスに書き込まれたデータに対して料金を支払います。これには、ベクトル自体とインデックスに射影された非ベクトル属性が含まれます。ベクトル属性や射影された属性に触れない書き込みは、ベクトル書き込みとして課金されません。これらの料金は、ベーステーブルの標準書き込み料金に加えて発生します。 ベクトル検索 – 類似性検索に応答するために処理されたデータに対して料金を支払います。インデックスがパーティションキーを定義している場合、検索は検索されたパーティションキーの値を持つアイテムを保持するインデックスの部分に制限されます。これにより、処理されるデータが減少し、したがって検索コストが削減されます。 ストレージ – ベクトルインデックスに保存されているデータに対して、GB-月あたりの料金を DynamoDB テーブルストレージと同じレートで支払います。 各オペレーションは、応答の ConsumedCapacity オブジェクトで消費されたベクトル容量を報告するため、コストを特定の書き込みや検索に帰属させることができます (ステップ 2 とステップ 3 を参照)。ベクトル使用量はバイトごとに計測されるため、これらの値は各オペレーションが処理したバイト数を追跡します。各ベクトル書き込みと各ベクトル検索には、最小課金サイズが 1 KB あります。1 KB を下回るオペレーションは 1 KB として計測され、それを超える場合はバイトごとに計測されます。これは、書き込みでインデックスに書き込まれたデータと、類似性検索に応答するために処理されたデータの両方に適用されます。 Standard または Standard-Infrequent Access テーブルクラスを使用するテーブルでベクトルインデックスを使用できます。GB あたりの料金については、 Amazon DynamoDB の料金 を参照してください。 コストを最適化するには、以下のプラクティスを検討してください。 ユースケースが最大の精度を必要としない場合は、256 または 512 などのより低い次元を使用します。これにより、ストレージ、書き込みごと、検索ごとのコストが同時に削減されます。 射影されたアイテムのサイズがストレージと検索が処理するバイト数の両方を左右するため、必要な属性のみをインデックスに射影します。 デフォルトでは埋め込みが結果に含まれないので、そのバイト数が検索料金にカウントされないようにしてください。必要なときにのみベクトルを射影します。 アクセスパターンに合う場合は、パーティションキーを持つインデックスを使用します。検索は検索された値を持つアイテムを保持するインデックスの部分のみをカバーし、より少ないバイトを処理します。 知っておくべきこと アプリケーションを設計する際に、DynamoDB ベクトル検索の以下の特性を念頭に置いてください。 オンデマンド容量モード – ベクトルインデックスは、オンデマンド ( PAY_PER_REQUEST ) 容量モードを使用するテーブルでのみサポートされます。 アイテムは必要な属性を持つ場合にのみインデックス化される – アイテムは、ベクトル属性を含む場合にのみベクトルインデックスに追加されます。インデックスがパーティションキーを定義している場合、アイテムはインデックスに含まれるためにそのパーティションキー属性も含む必要があります。 結果整合性 – ベクトルインデックスはアイテムがテーブルに書き込まれると非同期に更新されるため、ベクトル検索は結果整合性です。新しく書き込まれたか更新されたアイテムは、すぐに検索結果に表示されないかもしれませんが、インデックスが追いついた直後に検索可能になります。 ベクトルはデフォルトでは返されない – 埋め込みはインデックスに保存されていますが、 SearchVectors は結果から除外します。これにより、処理されるバイト数、したがって検索コストが増大しないようにします。必要な場合は、検索の ProjectionExpression で明示的にリクエストします。 ベクトル次元 – DynamoDB は最大 4,096 次元のベクトルをサポートし、インデックスの次元は埋め込みモデルの出力と一致する必要があります。 追加料金なしのバックフィル – UpdateTable API で既存のテーブルにベクトルインデックスを追加すると、DynamoDB は無料でインデックスをバックフィルします。バックフィルは、テーブルのアイテムにすでに保存されているベクトル属性を使用します。 インデックス設定は不変 – ベクトルインデックスの設定は、インデックスが作成されたときに設定され、その後変更できません。これには、次元、距離関数、射影、インラインフィルター属性、およびパーティションキーが含まれます。これらのいずれかを変更するには、必要な設定で新しいベクトルインデックスを作成します。前述のように、DynamoDB は新しいインデックスを無料でバックフィルします。1 つのテーブルは、デフォルトで最大 5 つのベクトルインデックスを持つことができます。 セカンダリインデックスのベクトル属性 – アイテムにベクトル属性を追加すると、すべての属性を射影するセカンダリインデックスに影響します。 ProjectionType: ALL で作成されたグローバルセカンダリインデックス (GSI) またはローカルセカンダリインデックス (LSI) は、新しいベクトル属性を自動的にインデックスにコピーします。これにより、インデックスのストレージ、書き込み、および読み取りのコストが増加する可能性があります。インデックスがベクトルを必要としない場合、そのインデックスが使用する属性のみを射影します。既存のすべての属性の GSI を、ベクトルを除外する特定の属性セットを射影するものに置き換えることができます。ただし、LSI はテーブルが作成されたときに固定され、その後追加または削除できないため、テーブル作成時に事前にその射影を計画してください。 パーティションキーごとのスループットクォータ – ベクトルインデックスの書き込みおよび検索のスループットは、パーティションキー値ごとに適用されるクォータの対象となります。現在の制限については、 DynamoDB のクォータ を参照してください。パーティションキーのないインデックスは、単一のクォータの対象となります。パーティションキーを持つインデックスは、パーティションキーの値ごとに個別のクォータを取得し、これによりインデックスが維持できる合計スループットが向上します。 クリーンアップ 将来の料金が発生しないように、このウォークスルーで作成したリソースを削除してください。DynamoDB テーブルを削除すると、そのベクトルインデックスも削除されます。 import boto3 dynamodb = boto3.client('dynamodb') dynamodb.delete_table(TableName='Papers') print("Table 'Papers' deletion initiated. The table will be removed shortly.") Bedrock のオンデマンド埋め込み呼び出しはリクエストごとに課金されるため、このウォークスルーで削除する常設の Bedrock リソースはありません。 まとめ DynamoDB のネイティブベクトル検索を使用すると、すでに運用データに使用しているデータベースで類似性検索を実行できます。別のベクトルストアなしで、よりシンプルなアーキテクチャ、より少ない運用オーバーヘッド、より低いレイテンシー、より低いコストを得ながら、DynamoDB のサーバーレススケーリングと予測可能なパフォーマンスを維持できます。 この記事では、ベクトルインデックスを持つ DynamoDB テーブルを作成し、Bedrock で埋め込みを生成し、DynamoDB にロードし、自然言語クエリでセマンティック検索を実行しました。セマンティック検索、レコメンデーションエンジン、または RAG アプリケーションを構築する場合でも、運用データとベクトルワークロードの両方に単一のサーバーレスサービスを使用できます。 始めるには、 DynamoDB ベクトル検索のドキュメント と GitHub の完全なコードサンプル を確認し、ベクトルインデックスを持つテーブルを作成してください。 論文のメタデータは arxiv-abstracts-2021 データセットからのもので、 CC0 1.0 Universal (パブリックドメイン) の下でライセンスされています。 本記事は 2026 年 08 月 05 日 に公開された “Build semantic search with native vector support in Amazon DynamoDB” を翻訳したものです。 原文: https://aws.amazon.com/blogs/database/build-semantic-search-with-native-vector-support-in-amazon-dynamodb/ 著者について Leonid Koren Leonid は AWS のプリンシパル NoSQL ソリューションアーキテクトで、既存のアプリケーションの近代化や NoSQL データベースを使用した新規アプリケーションのアーキテクチャ設計をお客様に支援しています。AWS に入社する前、Leonid は 2000 年代初頭からバックエンドシステムの設計と開発を行っていました。 Mo Kamioner Mo はイスラエルのエルサレムを拠点とする AWS のシニア DynamoDB ソリューションアーキテクトです。あらゆる規模のワークロードで 10 年以上 DynamoDB に携わり、世界中のお客様が DynamoDB の実装を設計、最適化、スケールすることを支援しています。Mo は複雑な問題に対するシンプルな解決策を見つけることに情熱を持っており、オフの時間には子供たちと IoT や Lego をいじっている姿が見られます。 &nbsp;

2026 年 5 月 22 日、金融庁と日本銀行は 「フロンティア AI による脅威変化を踏まえた金融機関等の短期的な対応」に係る要請 (金総政第 3245 号ほか) を公表し、経営トップを含めた経営層の直接関与の下で、短期的な対応に取り組むよう金融機関等に要請しました。 要請では、いわゆる「フロンティア AI」により、脆弱性の発見・修正等のサイバーセキュリティ性能の急速な向上が見込まれることを踏まえ、これに対応する取組が必要不可欠とされています。フロンティア AI を用いてソフトウェアの脆弱性を発見・修正する取り組みとしては、2026 年 4 月に Anthropic が発表した Project Glasswing と、その中核となる新クラスのモデル Claude Mythos があります。AWS はこの取り組みのローンチパートナーの一社であり、AWS Blog 「AI を活用した大規模なセキュリティ防御の構築 – 脅威が出現する前に」 で自らの取り組みを公開しています。 本記事では、金融庁・日本銀行の要請が求める 9 つの短期的対応のそれぞれについて、AWS のサービスと機能がどう役立つかを整理します。本記事で取り上げるサービスや機能は代表的な例であり、利用可能な選択肢のすべてを網羅するものではありません。また、AWS の利用だけで要請への対応が完了するものではなく、最終的な評価・統制・意思決定は各金融機関が行うものです。実際の対策の選定にあたっては、自組織のリスク特性やシステム構成を踏まえてご検討ください。 要請が指摘する脅威の変化 要請では、フロンティア AI により、従来は発見が困難だった脆弱性が短期間に発見され得ることに加え、脆弱性の発見から攻撃に至るまでの期間が大幅に短縮され得ることが指摘されています。規模の目安として、次の数字があります。2025 年の 1 年間に公開された CVE (共通脆弱性識別子) は 48,185 件 (前年比約 20% 増) でした。一方、Anthropic が公表した 経過報告 (Project Glasswing: An initial update) によれば、Project Glasswing では約 50 のパートナー組織が Claude Mythos Preview を使い、開始から約 1 か月で深刻度 High または Critical の脆弱性を 1 万件超発見しています。さらに Anthropic 自身も 1,000 以上のオープンソースプロジェクトをスキャンし、モデルの推定を含め 23,019 件 (うち High/Critical は推定 6,202 件) の脆弱性候補を発見しました。Anthropic は発足時に、プロジェクトで得られた知見を 90 日以内に公に報告すると表明し、上記の経過報告として公開しました。また、発見された個々の脆弱性は、協調的脆弱性開示 (CVD) ポリシーに沿って、独立した検証とメンテナーへの通知、修正のための開示猶予期間を経て順次公開されています。これらの数字は、公開済みの CVE 件数とは期間・対象・検証状況が異なるため直接比較はできないものの、発見の後に続く検証・開示・修正の工程の処理能力が課題になり得ることを示しています。 ここで課題になるのが、パッチ適用までの時間差です。脆弱性が公表されパッチが公開されても、それを適用し終えるまでは脆弱性が残ります。この、公表から N 日が経過した既知の脆弱性を狙う攻撃は「N デイ攻撃」と呼ばれます (未知の脆弱性を狙うゼロデイ攻撃と対になる用語です)。Amazon の脅威インテリジェンスチームは、攻撃者が公開されたエクスプロイトを開示から数時間～数日で攻撃に転用する状況を観測しています。しかもこの速度は国家支援型のグループに限りません。公開された PoC や生成 AI の活用により、高度な技術を持たない攻撃者にも広がりつつあります。「四半期ごとに」「十分なテストを経てから」パッチを当てるという従来モデルでは、対応が間に合わない可能性があります。金融庁・日本銀行の要請でも、短期的に脆弱性やパッチが集中的に発見・提供される可能性を踏まえ、「経営トップを含めた経営層の直接関与」の下で迅速かつ適切に対応できる態勢の点検・強化が求められています。 一方で、英国 AI Security Institute (AISI) の 評価報告 (Our evaluation of Claude Mythos Preview’s cyber capabilities) では、現時点のフロンティア AI は十分に防御された IT システムに対しては攻撃を達成できるとは言えないとされています。つまり、金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」に基づく基本的な対策を、より迅速かつ確実に実行していくことが、引き続き最も重要な出発点になります。 9 つの短期的対応に AWS サービスがどう役立つか 要請は 9 つの短期的対応を挙げています。これらは IT・サイバーセキュリティ担当部署のみで完結するものではなく、経営トップの正確な理解と危機意識の下で必要なリソース (予算・人員) を確保することが不可欠、というのが要請全体を貫く前提です。以下、各項目について AWS のサービスと機能でできることを整理します。 ① フロンティア AI への対応を経営課題として扱う この脅威は IT・サイバーセキュリティ部門にとどまらず、各業務所管部門・リスク管理・財務部門が横断的に連携すべき全社的な経営課題です。AWS では、サポート階層にかかわらず無料で利用できる Security Health Improvement Program (SHIP) や、 AWS セキュリティ成熟度モデル を通じて、自組織の現状を客観的に把握し、経営として優先順位とリソース配分を判断するための材料を提供しています。セキュリティ成熟度モデルは過去 1 年間で世界の 50,000 を超えるお客様に利用されています。 ② 優先的に対応すべきサービス/IT システムを特定する どのシステムが重要業務を支えているか、その業務影響の評価はお客様自身にしかできない判断です。技術面で支援できるのは、その判断の前提となる資産の把握です。 AWS Config や AWS Systems Manager のインベントリ機能を使うと、AWS 上のリソース構成や導入ソフトウェアを継続的に記録でき、「どこに何があるか」を洗い出す作業を支援します。そのうえで、 Amazon Inspector がワークロードを継続的に監視し、新しい脆弱性が公開されるとニアリアルタイムで再スキャンして、CVSS (共通脆弱性評価システム) のスコアだけでなくネットワーク到達性や悪用可能性を加味したリスクスコアを算出するため、インターネットバンキング等を支える外部公開システムから優先的に対処する、といったリスクベースの絞り込みに役立ちます。さらに、後述する AWS Continuum (限定プレビュー) は、インフラ・アクセス許可・ネットワーク構成に加え、ドキュメントやビジネス上の優先事項といった組織のコンテキストを取り込み、IT 資産の重要度を考慮した対応の優先順位付けを支援します。 ③ 特定した資産の技術負債を解消しておく 優先対象について、ソフトウェア構成・ネットワーク構成を再確認し、脆弱性発見時に即座にパッチ適用対象を特定できる状態を確保します。不要なネットワークポートの閉塞、特権 ID の削除、サポート終了製品のサポート対象バージョンへの更新が重要です。Amazon Inspector は監視対象リソースのソフトウェア部品表 (SBOM) を CycloneDX/SPDX 形式でエクスポート でき、サプライチェーンを含む構成の可視化に役立ちます。また、スタンドアロンツールの Amazon Inspector SBOM Generator を使うと、CI/CD パイプラインの中でコンテナイメージ等の SBOM を生成し、デプロイ前の脆弱性検出に活用できます。加えて、後述のマネージドサービスへの移行そのものが、OS・ミドルウェア層の技術負債を構造的に減らす有効な手段になります。 ④ パッチ適用に係る人的リソースを追加する / ⑤ ベンダーとの維持保守契約を確認する 人的リソースの追加やベンダー契約 (SLA/SLO、夜間・休日対応、責任分担) の確認は、まず組織・契約面の課題です。技術面からは、2 つの時間軸で補完できます。 短期的には、今あるサーバーのパッチ作業自体の自動化です。 AWS Systems Manager Patch Manager は、パッチベースラインとメンテナンスウィンドウを定義して、Amazon EC2 上のサーバーだけでなくオンプレミスのサーバーも含めてパッチの適用状況の確認と適用を自動化できます。手作業の適用・確認に費やしている時間を減らすことは、人的リソースの追加と同じ方向の効果を持ちます。 中長期的には、パッチ適用の対象そのものを減らすという考え方があります。 AWS Lambda 、 Amazon API Gateway 、 AWS Fargate 、 Amazon Aurora Serverless 、 Amazon DynamoDB などのサーバーレス・マネージドサービスを活用すると、責任共有モデルのもとで、基盤となるインフラストラクチャや AWS が管理するランタイムのパッチ適用が AWS の責任範囲となり、お客様はアプリケーションコード、コンテナイメージ、およびそれらの依存関係など、お客様の責任範囲に集中できます。 マネージドサービスへの移行に際して、AWS 側で行われる基盤メンテナンスが業務に影響しないか、気になるかもしれません。この点は、AWS がマネージドサービスをどのような構造で提供しているかという、責任共有モデルの AWS 側の設計から説明できます。 ホワイトペーパー「 AWS 障害分離境界 」が説明するとおり、Amazon DynamoDB や Amazon SQS などのマネージドサービスの多くは「リージョンサービス」として提供されます。リージョンサービスは、AWS が物理的に分離された複数のアベイラビリティーゾーン (AZ) の上に構築したサービスであり、お客様が複数 AZ の活用方法を設計する必要はありません。たとえば Amazon S3 はリクエストとデータを複数の AZ に分散し、1 つの AZ の障害から自動的に回復するように設計されています。この冗長な構造が、基盤の一部を更新しながらサービス全体は稼働を続ける、という運用の土台になっています。各サービスには、月間稼働率のサービスコミットメントと未達時の取り扱いを定めた SLA (サービスレベルアグリーメント) が公開されています。 その更新のプロセスについて、AWS は CSA (Cloud Security Alliance) の Consensus Assessments Initiative Questionnaire (CAIQ) への回答 の中で、本番環境へのすべての変更が「中断を最小化するための実装・ロールバック計画」「非本番環境でのテスト」「ピアレビュー」「承認」を経て、可能な限り手動ステップを排した継続的デプロイのパイプラインで実施されることを説明しています。個別のサービスにもこの設計は表れており、 Amazon DynamoDB はバージョンやメンテナンスウィンドウという概念自体を持たず「アップグレードやダウンタイムを必要とせず、可用性、信頼性、パフォーマンス、セキュリティ、機能を継続的に改善」し、Amazon Aurora の ダウンタイムのないパッチ適用 (ZDP: Zero-Downtime Patching) はエンジンのアップグレード中もクライアント接続の維持を試みます。実例として、Log4Shell (CVE-2021-44228) の際には、 稼働中の JVM にライブでパッチを当てるホットパッチ を AWS が開発してオープンソースとして公開し、AWS Fargate や AWS Lambda などのマネージドサービスの基盤には、お客様のアクションを必要とせず数日で展開しました。なお、要請ではクラウド事業者により提供される IT システムについて、パッチ適用に関する SLA/SLO の内容や適用状況が適切に報告される契約内容となっていることの確認が求められており、上記のホワイトペーパー・CAIQ 回答・SLA は、その確認の際の参考になります。 ⑥ パッチ適用プロセスをリスクベースにする CVSS スコアが高くない脆弱性でも実際の攻撃に使われる実態があり、この傾向はフロンティア AI によりさらに加速する可能性があります。Amazon Inspector は EPSS スコアや CISA の Known Exploited Vulnerabilities カタログ、公開された攻撃コードの有無、推奨パッチ適用期間といった脅威インテリジェンスを取り込み、攻撃が成立する蓋然性を踏まえた優先順位付けを可能にします。アプリケーションのテストとデリバリーについては、 AWS CodePipeline を中心とした CI/CD パイプラインで自動ビルド・自動テスト・段階デプロイ・自動ロールバックを構成することで、テスト不足によるシステム障害リスクを抑えつつパッチ適用期間を短縮できます。 ⑦ パッチ適用以外の対策も強化する 多層防御は、単一の対策の突破を前提に複数の防御層を重ねる、すべてのセキュリティ対策の基本です。パッチ適用も防御層の 1 つであり、適用そのものが困難な場合や適用までに時間を要する場合でも、他の層が攻撃の成立を防ぎ、被害を抑えます。要請では、こうした対策の例として、クラウド型の WAF 等を用いた「仮想パッチ」(個々の脆弱性に対応した侵入防御ルールにより、本来のパッチを早急に適用することが難しい場合に攻撃通信をブロックする暫定的なソリューション) の適用が挙げられています。AWS では、ウェブアプリケーションの層は AWS WAF が WAF 機能を提供し、既知の脆弱性を悪用する通信パターンをブロックするルールをまとめたマネージドルールが AWS により更新・提供されています。ネットワークの経路上では AWS Network Firewall が Suricata 互換の侵入防止システム (IPS) 機能を提供し、脆弱性を悪用する通信をシグネチャで検知・遮断するルールをまとめたマネージドルールグループが AWS により更新・提供されています。いずれも、アプリケーションやサーバーを修正するまでの間の防御層として利用できます。なお要請の脚注にあるとおり、こうした対策は恒久的な対応ではなく、パッチ適用までの暫定措置と位置づけることが重要です。このほか、ネットワーク分離、特権 ID への多要素認証、端末での不正検知・対応 (EDR) などがあります。要請が挙げる内部侵入後の横展開への対策としては、検知の層も必要です。 この多層防御の各層で活用できるのが、AWS の脅威インテリジェンスです。AWS は 1 日あたり 400 兆を超えるネットワークフローを分析し、 ハニーポットシステムの MadPot と、その脅威インテリジェンスをもとに悪意のあるアクティビティを自動的に制限する Sonaris を核とする アクティブディフェンス を運用しています。2025 年だけで Amazon S3 上のファイルへの不正暗号化の試み 3 億件超をブロックしました。この脅威インテリジェンスは AWS 内部の防御にとどまらず、お客様が利用できるサービスにも組み込まれています。 Amazon GuardDuty は AWS とサードパーティーの脅威インテリジェンスを機械学習と組み合わせてアカウントとワークロードのログを継続的に分析し、既知の脅威アクターとの通信や認証情報の悪用など、侵入後の横展開の兆候を検出します。 AWS Network Firewall のアクティブ脅威防御 は、MadPot が追跡するマルウェア URL やボットネットの C&amp;C サーバー等の攻撃インフラを、マネージドルールグループ「AttackInfrastructure」として提供し、これらとの通信を自動的にブロックします。前述の AWS WAF マネージドルールも、この脅威インテリジェンスの還元先の 1 つであり、パッチ適用までの防御層として機能します。実例として、 React2Shell (CVE-2025-55182) では公開から数時間以内に国家支援型グループの悪用試行を MadPot で観測 し、Sonaris・AWS WAF マネージドルール等による多層の自動保護を展開したことをブログで公開しています。 ⑧ 優先サービス/IT システムの停止に備える 各種対策を徹底してもサイバー攻撃を防ぎきれない可能性を前提に、事業継続計画 (BCP) の有効性や緊急時の連絡体制、能動的なサービス停止の判断基準を明確にしておくことが求められます。これは共同運営形態やクラウド事業者が提供する IT システムについても同様です。マネージドサービスを活用している場合、基盤の可用性は AWS の責任範囲に含まれますが、業務要件に応じた構成、復旧目標、依存関係の整理、停止判断はお客様が設計・検証します。業務停止時の顧客対応手順も、引き続きお客様側で整備しておく必要があります。停止後の復旧の備えとしては、 AWS Backup の論理的にエアギャップされたボールトへのバックアップ保管が、ランサムウェア等でデータが侵害された場合の復旧手段の 1 つになります。 ⑨ 外部との連携を維持・強化する フロンティア AI に関する情報は短期間に多数公開されるため、自組織のみでの網羅的な把握は困難です。金融 ISAC や各業界団体・当局からの情報に積極的にアクセスするとともに、AWS からは AWS Security Bulletins や、 Amazon の脅威インテリジェンスチームによる注意喚起ブログ を通じた情報を継続的に提供しています。 AI の活用で脆弱性の発見を早める 要請への対応は「公開されるパッチにいかに追いつくか」が中心です。一方で Anthropic は、 Project Glasswing の拡大発表 の中で、6～12 か月以内に他の多くの AI 企業も Mythos クラスのモデルを持つと予想され、悪用を防ぐセーフガードなしにリリースされる可能性があると述べています。同様の能力が広く利用可能になれば、パッチが存在しない未知の脆弱性を突くゼロデイ攻撃への備えも重要性を増します。その 1 つとして、お客様自身が AI を活用して脆弱性を発見・修正するアプローチがあります。 AWS Security Agent (現在は AWS Continuum の一部) は、一般提供が開始されたオンデマンドペネトレーションテストにより、24 時間 365 日稼働する自律型のテストを手動テストと比べてわずかなコストで提供します。潜在的な脆弱性を特定した後に実際にエクスプロイトを試み、正当なリスクであることを検証したうえで、CVSS スコア・再現手順・修正提案付きでレポートします。設計ドキュメントや設計・ソースコードからの脅威モデリング (STRIDE 形式、プレビュー)、プルリクエストごとの自動スキャンとリポジトリ全体の深い分析の両方に対応するコードレビュー (プレビュー)、数時間で完了するペネトレーションテストと、設計からデプロイまでの開発ライフサイクル全体をカバーします。ペネトレーションテストは、AWS 上の環境だけでなく、他社クラウド上で稼働するシステムやオンプレミス、SaaS 環境にも対応します。新規のお客様は 2 か月間の無料トライアルを利用できます。 さらに、脆弱性を「見つけた後」の工程をマシンスピードで処理するのが AWS Continuum です。フロンティア AI により脆弱性の発見は速く・安価になった一方、どの脆弱性が自社のビジネスにとって重要かを判断し、実際に悪用可能かを検証し、修正までつなげる後工程は、人手による判断と部門間の調整に依存したままでは追いつきません。Anthropic 自身も、Project Glasswing の教訓として「制約は脆弱性を見つける速さではなく、検証・開示・修正の速さに移った」と述べています。Continuum for code vulnerabilities (限定プレビュー) はこの工程を対象とし、発見・優先順位付け・検証・緩和と修復という 4 つのフェーズを、脅威が生まれるのと同じマシンスピードで継続的に実行します。既存ツールの検出結果と独自スキャンを取り込み、インフラ・アクセス許可・ネットワーク構成などのコンテキストからビジネス影響を評価して優先順位付けし、隔離されたサンドボックス内で再現可能なエクスプロイトの構築を試みることで、悪用可能性が確認された問題に絞り込んだうえで、コードパッチやポリシー変更を提案します。これは、発見された脆弱性について「攻撃が成立する蓋然性も踏まえた評価」と「リスクベースの優先順位付け」を求める要請⑥の趣旨に沿ったアプローチです。動作は人間が推奨内容を確認して承認する learn モードから始まり、お客様の判断で自動修復 (enforce モード) へ段階的に引き上げる設計です。なお Continuum for code vulnerabilities は限定プレビューの段階にあり、金融サービス業界のお客様のフィードバックとともに形作られています。 独自のセキュリティワークフローを構築したい組織には、 Amazon Bedrock 上で複数のプロバイダーの最新フロンティアモデルから用途に合ったものを選ぶ選択肢があります。AWS PrivateLink の VPC エンドポイントを介して、インターネットを経由せずお客様の VPC から Bedrock に接続できます。ポリシー適用型のアクセス制御、モデルの検出効果を測る組み込みの評価ツール、お客様が定義したポリシーやドメインルールとの論理的一貫性を形式的手法で検証する自動推論チェック (AWS が公表した評価の範囲で最大 99% の検証精度)、カスタマイズ可能なガードレールを備え、自社のソースコードのスキャンを支援するワークフローの構築に活用できます。Amazon Bedrock は、日本政府のクラウドサービス評価制度である 「政府情報システムのためのセキュリティ評価制度 (ISMAP)」 の対象範囲に含まれています。また、Amazon Bedrock Marketplace を除き、Payment Card Industry Data Security Standard (PCI DSS) の対象範囲にも含まれています。これらの情報は、お客様が自組織のセキュリティ・コンプライアンス要件への適合性を評価する際の参考資料として利用できます。 まとめ – 今すぐ着手すること、中長期で取り組むこと フロンティア AI による脅威変化への対応は、2 つの観点から整理できます。 Project Glasswing 以降のパッチ公開ペースの変化に対しては、 今すぐパッチ適用を日常業務化し、インシデント対応体制を変革すること。中長期では、マネージドサービスを多用した IT システムのモダナイズにより、基盤レイヤーのパッチ運用の一部を AWS に委ね、お客様の運用負荷を軽減していくこと。 フロンティア AI の一般化により攻撃の高度化やゼロデイ攻撃のリスクが高まる可能性に対しては、 今すぐ AI を活用した脆弱性スキャンとセキュリティレビュー (AWS Security Agent、Amazon Bedrock + 最新モデル) で発見を早めること。中長期では、侵害を前提とした多層防御を徹底し、攻撃の影響を最小化すること。 いずれも、金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」に基づく基本的な対策を確実に実行することが土台です。まずは自組織の現状把握から始めることをお勧めします。無料アセスメントプログラムの SHIP と AWS セキュリティ成熟度モデルをご活用いただけますので、担当の AWS アカウントチームにお気軽にお声がけください。 早見表 – 金融庁・日本銀行の要請と AWS サービスの活用 金融庁・日本銀行が求める 9 つの短期的対応について、AWS のサービス・機能がどう役立つかを一覧に整理しました。 # 金融庁・日本銀行の要請 AWS サービスの活用 (主なサービス・機能) ① フロンティア AI への対応を経営課題として扱う SHIP (無料) と AWS セキュリティ成熟度モデルで現状を客観評価し、経営としての優先順位付けとリソース配分の判断材料を提供 ② 優先的に対応すべきサービス/IT システムを特定する AWS Config / Systems Manager インベントリで資産を把握。Amazon Inspector が CVSS・ネットワーク到達性・悪用可能性を相関したリスクスコアを算出し、外部公開システムからの優先対処を支援。AWS Continuum (限定プレビュー) は組織のコンテキストから IT 資産の重要度を考慮した優先順位付けを支援 (業務影響の最終評価はお客様の判断) ③ 特定した資産の技術負債を解消しておく Amazon Inspector の SBOM (CycloneDX/SPDX) エクスポートで構成を可視化。Inspector SBOM Generator で CI/CD 内の SBOM 生成も可能。マネージドサービス移行で OS・ミドルウェア層の技術負債を構造的に削減 ④ パッチ適用に係る人的リソースを追加する 短期: Systems Manager Patch Manager でパッチ作業を自動化 (オンプレミス含む)。中長期: サーバーレス/マネージドサービス (Lambda、Fargate、Aurora Serverless、DynamoDB 等) で、責任共有モデルのもと、基盤インフラと AWS が管理するランタイムのパッチ適用を AWS の責任範囲に (コンテナイメージや依存関係はお客様責任)。マネージドサービスの多くは複数 AZ 上に構築されたリージョンサービスで、月間稼働率のサービスコミットメントを定めた SLA を公開 ⑤ ベンダーとの維持保守契約の内容を確認する AWS 全体の変更管理は CAIQ 回答で公開 (中断最小化・ロールバック計画・継続的デプロイ)。DynamoDB はメンテナンスウィンドウなし、Aurora は ZDP によりエンジン更新時のクライアント接続の維持を試みる (例: Log4Shell の稼働中 JVM ホットパッチ )。SLA/SLO・報告内容の確認の参考に ⑥ パッチ適用プロセスをリスクベースにする Amazon Inspector が EPSS・CISA KEV・攻撃コードの有無を取り込みリスクベースで優先順位付け。AWS Continuum (限定プレビュー) が悪用可能性をサンドボックスで検証し、確認された問題から修正を提案。AWS CodePipeline で自動テスト・段階デプロイ・自動ロールバック ⑦ パッチ適用以外の対策も強化する AWS WAF と AWS Network Firewall (IPS 機能) の各マネージドルールによる脆弱性悪用通信の遮断 (パッチ適用までの暫定措置)、ネットワーク分離、多要素認証、EDR 等の多層防御。脅威インテリジェンスを活用した防御として、Amazon GuardDuty (侵入後の兆候検知)、AWS Network Firewall アクティブ脅威防御 (攻撃インフラとの通信ブロック)。 AWS のアクティブディフェンス (MadPot/Sonaris) が観測した脅威を各サービスにフィードバック ⑧ 優先サービス/IT システムの停止に備える マネージドサービスの基盤の可用性は AWS の責任範囲。業務要件に応じた構成・復旧目標・停止判断の設計と検証、BCP・顧客対応手順の整備はお客様側で実施。AWS Backup の隔離バックアップが復旧手段の 1 つに ⑨ 外部との連携を維持・強化する AWS Security Bulletins と脅威インテリジェンスに基づく情報提供。金融 ISAC 等との連携を補完 加えて、公開されるパッチへの追随の先にある、AI による攻撃の高度化やゼロデイ攻撃への備えとして、 AWS Security Agent (一般提供のペネトレーションテストに加え、脅威モデリングとコードレビューはプレビューで提供)、 AWS Continuum (限定プレビュー。脆弱性の発見から優先順位付け・検証・修復までのライフサイクル全体をマシンスピードで自律処理)、 Amazon Bedrock + 最新フロンティアモデル (ソースコードのセキュリティレビューを支援するワークフローの構築。VPC エンドポイント経由で接続可能) をご活用いただけます。 関連情報 「フロンティア AI による脅威変化を踏まえた金融機関等の短期的な対応」に係る要請について (金融庁) AI を活用した大規模なセキュリティ防御の構築 – 脅威が出現する前に AWS Continuum のご紹介: マシンスピードで実現するセキュリティ AWS Security Agent のオンデマンドペネトレーションテストの一般提供を開始 FISC 安全対策基準・解説書に関する AWS の情報 本記事は、金融庁・日本銀行 「フロンティア AI による脅威変化を踏まえた金融機関等の短期的な対応」に係る要請 (2026 年 5 月 22 日) および AWS の公開情報に基づいて作成しています。本記事で紹介するサービス・機能は代表的な例であり、すべての選択肢を網羅するものではありません。また、特定の対策の実施により被害の防止を保証するものではありません。記載のサービス仕様・提供状況・料金は変更される場合があります。最新情報は各サービスの公式ドキュメントをご確認いただき、具体的な対策の選定は自組織の環境に応じてご判断ください。 著者 能仁 信亮 (Shinryo Nonin) – 金融ソリューション本部 プリンシパルソリューションアーキテクト 中島 章博 (Akihiro Nakajima) – パブリックセクター技術統括本部 シニアセキュリティソリューションアーキテクト

2026 年 7 月 27 日週、7 歳の息子と一緒に Amazon の「子供を仕事に連れて行く日」に参加できてよかったです。私たちはニューヨーク市にあるオフィスまで一緒に通勤しました。息子にとって、ラッシュ時に電車に乗ったのはこれが初めてでした。その日は一日かけて、Amazon が AI、機械学習、ロボティクスをどのように使用して世界中の顧客に荷物を届けるかを見て回りました。ロボットがフルフィルメントセンターをナビゲートしているのを見る息子の目が輝いていました、それを見て、私たちの多くがそもそもなぜテクノロジーに夢中になったのかを思い出しました。何か複雑なことが腑に落ちたときに感じるあの驚きに勝るものはありません。 今週のローンチにも、同じエネルギーが注入されました。AI 価格設定、オブザーバビリティ、マルチクラウドネットワーク、およびデータ管理に関する最新情報をお届けします。では、早速見ていきましょう! 見出し Amazon Bedrock、OpenAI GPT‑5.6 モデルの価格を最大80%引き下げることを発表 — Amazon Bedrock を通じて OpenAI の GPT‑5.6 ファミリーを使用している場合、コストが大幅に下がることになりました。7 月 30 日より、GPT‑5.6 Luna のオンデマンド推論価格は 80%、GPT‑5.6 Terra 料金は 20% 引き下げられます。Luna は現在、100 万個の入力トークンあたり 0.20 ドル、出力トークン 100 万個あたり 1.20 ドルで、入手可能な最も手頃なフロンティアクラスモデルの1つとなっています。これらの値下げは自動的に適用されるため、ユーザー側でのアクションは必要ありません。 もっと読む &nbsp;7 月 27 日週のローンチ 7 月 27 日週のローンチのうち、私が注目したリリースをいくつかご紹介します: Amazon CloudWatch がマネージド Prometheus コレクターを発表 — Amazon CloudWatch は、フルマネージドコレクターを使用して、AWSインフラストラクチャから Prometheus メトリクスを収集できるようになりました。これにより、エージェントをデプロイまたは管理することなく、Amazon EKS、Amazon EC2、Amazon ECS、Amazon MSK、および Amazon OpenSearch Service のワークロードをモニタリングできるようになりました。Prometheus スクレイピングインフラストラクチャを自社で管理している場合、これにより運用上の大きな負担が軽減されます。 もっと読む AWS Interconnect — Oracle Cloud Infrastructure によるマルチクラウド接続が一般に利用可能になりました 。AWS Interconnect は、この種のマルチクラウド接続を目的とした最初の製品であり、AWSと他のクラウドプロバイダー間で、回復力がありスケーラブルなプライベート接続を迅速にプロビジョニングできます。今回の Oracle Cloud Infrastructure（OCI）向けの GA ローンチにより、パブリックインターネットを経由せずにプライベート・クロスクラウド・ネットワーキングを確立できるようになり、ワークロードに必要なセキュリティとパフォーマンスを備えたマルチクラウドアーキテクチャを簡単に実行できます。 もっと読む AWS IAM Identity Center は、マルチリージョンのサポートを Identity Center ディレクトリにまで拡張しました 。Identity Center ディレクトリをアイデンティティソースとして使用すると、プライマリAWS リージョンから他のリージョンに IAM Identity Center をレプリケートできるようになりました。IAM Identity Center がプライマリリージョンの障害の影響を受けた場合でも、ユーザーは他のリージョンのプロビジョニングされたエンタイトルメントを使用して、AWS アカウントに引き続きアクセスできます。この機能は、以前は外部 ID プロバイダーに接続されたインスタンスでのみ使用できました。 もっと読む Amazon S3 Tables が Apache Iceberg V3 のバリアントデータ型をサポートするようになりました 。Amazon S3 Tables では、Apache Iceberg V3 テーブルフォーマット仕様で導入されたバリアントデータ型のサポートが追加されました。Variant は、JSON BLOB に頼ることなく、データレイク内の半構造化データ (IoT センサーデータ、アプリケーションログ、その他のスキーマフレキシブルペイロードなど) を管理するための高性能なネイティブソリューションを提供します。 もっと読む その他の AWS ニュース 興味深いと思われる追加の記事やリソースをいくつかご紹介します: 単一行のコマンドによる AWS CLI のインストールと更新 — 開発者ツールチームによる新しいブログ投稿では、1 行のコマンドでプラットフォーム間の AWS CLI のインストールと更新を簡単にしています。CLI バージョンをチーム間または CI パイプラインで管理する場合、これは使い勝手の向上としてうれしい変更です。 Amazon SageMaker HyperPod と &nbsp; Amazon EKSに Kimi K3 をデプロイ — SageMaker HyperPod と Amazon EKS を使用して、Moonshot AI の Kimi K3 モデルを AWS インフラストラクチャにデプロイするためのステップバイステップガイド。大規模なモデルデプロイオプションを検討している場合、このチュートリアルでワークフロー全体を説明します。 &nbsp; Amazon MSK Express ブローカーを使用して Apache Kafka データを Apache Iceberg のストリーミングテーブルに配信 — Amazon MSK Express ブローカーを使用して Apache Kafka から Apache Iceberg テーブルにデータをストリーミングする方法を学びましょう。Amazon S3 Tables で Apache Iceberg に配信する際に最大 10 GB/s のスループットがサポートされています。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summits – AWS Summits は、クラウドや AI のコミュニティが一堂に会し、つながり、学び、そして最新のテクノロジーを探求するための無料のイベントです。カレンダー全体をご覧になって、2026 年後半にお近くで開催されるサミットを見つけてください。 AWS Community Days – コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンス。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有、および開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。 2026 年 8 月 3 日週のニュースは以上です。8月10日週に再びアクセスして、新たな 1 週間のまとめをぜひお読みください! 原文は こちら です。