本記事は 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 週間のまとめをぜひお読みください! 原文は こちら です。

本記事は 2026 年 7 月 20 日 に公開された「 Introducing KNFSD File Cache: Extending your NFS storage into the clouds 」を翻訳したものです 長年にわたり、 Amazon Web Services (AWS) はコンピューティングインフラをスケールアップ、スケールアウト、そして広域展開する手段を提供してきました。一方、ストレージ面、特に Network File System (NFS) を基盤とし、オンプレミスやハイブリッド環境にデータを持つ組織にとっては、同じペースで進化が進んでいませんでした。コンピューティング負荷の高いワークロードでより高いスループットが必要な場合、並列ジョブ向けに高速な共有アクセスが必要な場合、あるいはデータを複製せずに別の AWS リージョンやアベイラビリティーゾーンにコンピューティングを配置したい場合でも、課題は共通しています。移行やクライアント側の変更なしに、弾力的なコンピューティングに見合ったデータアクセスのスケールを実現することは、依然として難しい問題でした。 KNFSD File Cache (KNFSD) はその課題を解決します。 Amazon Elastic Compute Cloud (Amazon EC2) 上で動作するオープンソースの NFS キャッシングプロキシソリューションで、既存の NFS サーバーを透過的に AWS へ拡張します。クラウドインスタンスのすぐ近くに高性能なキャッシュ層を配置することで、ワークロードの実行場所を問わず、共有データへの高速アクセスを実現します。 本記事では、KNFSD の仕組みと、オンプレミスのファイラー、サードパーティ製品、 Amazon FSx などの AWS サービスを含む NFS 準拠のストレージとの組み合わせ方を説明します。また、単一の Terraform モジュールで本番環境向けのオートスケーリングクラスターをデプロイする方法と、100 Gb/秒の合計スループットを 1 時間あたり 6 ドル未満で実現する方法についても解説します。 「AWS との共同作業で行った初期の KNFSD プロトタイプにより、極めて長距離でも高性能なキャッシングがクラウドレンダリングで実用的であることが証明されました。KNFSD File Cache 向けの新しい AWS Solution Guidance の採用を楽しみにしています。これは、私たちが手作業で構築しなければならなかった機能をまさに製品化したものです。」 – Kimball Thurston、CTO、Wētā FX 対象となるユーザー KNFSD は、クラウド上の NFS データへの高性能かつ読み取り中心のアクセスと、ソースへの書き戻しが必要なあらゆる組織を対象に設計されています。ユースケースには以下が含まれますが、これらに限りません。 読み取り I/O が多いコンピューティング集約型の業界: 既存の NFS インフラに保存された大規模データセットへの高速な共有アクセスを必要とするワークロード全般。メディア &amp; エンターテインメント (レンダーファーム)、ハイパフォーマンスコンピューティング、金融サービス、ヘルスケア &amp; ライフサイエンス、エネルギー、気象 &amp; 気候科学などが含まれます。 ハイブリッドクラウドおよびマルチクラウド: オンプレミスのファイラーや他のクラウドプロバイダーから、データの移行や複製なしに既存の NFS インフラを AWS へ拡張したい組織。 マルチリージョンおよびマルチ AZ : AWS リージョンまたはアベイラビリティーゾーン をまたいでコンピューティングを分散させるスタジオや研究チーム。KNFSD がデータをローカルにキャッシュすることで、中央の NFS ソースへのレイテンシーを解消します。 「KNFSD キャッシングソリューションは期待を上回る結果をもたらしました。開発中に AWS と協力し、本番環境でのスケール運用に必要な重要な内部メトリクスが確実に公開されるようにしたことで、独自ツールの構築が不要になりました。この取り組みのおかげで、不確実な状態から脱却し、複数のプロジェクトにわたって本番環境でこのソリューションを効果的に運用できるという確信を持てるようになりました。」 – Greg Newman、シニアマネージャー、プロダクションエンジニアリング &amp; デジタルリソース、Industrial Light &amp; Magic (ILM) KNFSD File Cache とは KNFSD は、ハイブリッドおよびバーストコンピューティングのユースケース向けに設計された高性能 NFS キャッシングプロキシを提供する、オープンソースの AWS Solution Guidance です。既存のオープンソースプロジェクトをフォークし、AWS との統合機能を加えて拡張しています。AWS 上での動作最適化 ( AWS Graviton を含む)、開発環境および本番環境向けのコンテナサポート、OpenTelemetry と Amazon CloudWatch を活用した包括的なメトリクスダッシュボード、そして Common Vulnerabilities and Exposure (CVE) 対策による強化されたセキュリティを備えています。 KNFSD File Cache は、実績ある Linux カーネル技術を基盤としています。 nfs-kernel-server – NFS マウントの再エクスポートをサポートする Linux カーネルネイティブの NFS サーバーです。プロキシがソースの NFS エクスポートをマウントし、まるで元のファイラーであるかのように下流のクライアントへ提供します。 cachefilesd (FS-Cache) – ネットワークファイルシステムのデータをローカルディスクに永続的にキャッシュする Linux カーネルモジュールです。同じファイルへの再リクエスト時は、ソースから取得するのではなく、キャッシュから直接提供されます。 KNFSD は kernel NFS daemon の略で、ソリューションを支えるカーネル空間コンポーネントへの敬意を込めた名称です。独自エージェント、ベンダー固有のプロトコル、特定のストレージソリューションへの依存は一切ありません。既存のファイラーに対して NFSv3 または NFSv4 で通信できる NFS クライアントであれば、変更なしに KNFSD と連携できます。 2 段階のキャッシュ KNFSD は、各プロキシインスタンスに 2 層のキャッシュ階層を提供します。 レイヤー 技術 媒体 特性 L1 Linux ブロックキャッシュ RAM 超低レイテンシー、インスタンスメモリ量に依存 L2 FS-Cache (cachefilesd) ローカル NVMe 高スループット、再起動後もデータが保持され、テラバイト級の容量 クライアントがファイルをリクエストすると、プロキシはまず L1 (RAM) を確認します。RAM からデータが退避されている場合は、L2 (NVMe ディスク) がローカルストレージの速度で提供します。完全なキャッシュミスが発生した場合のみ、プロキシはソースファイラーからデータを取得します。ファイルの取得後、そのプロキシに接続しているクライアントからの後続の読み取りはキャッシュから提供されます。 “EngineLab では、Barnstorm VFX などのスタジオ向けクラウドバーストレンダリングアーキテクチャの中核として KNFSD を導入しています。オンプレミスのコンピューティングリソースが枯渇した瞬間に AWS 上でレンダリング容量をスケールでき、KNFSD が限られた帯域幅接続でテクスチャなどの共通アセットを効率的にキャッシュします。レンダリング中はコンピューティングの料金のみを支払い、不要な時はゼロにスケールダウンできます。私たちが目指しているのはまさにこれです。インフラの制約を取り除くことで、お客様がクリエイティブな作業に集中し、より野心的なプロジェクトに挑戦でき、レンダーファームの規模によって締め切りが左右されることのない環境を実現することです。” – Sam Reid、CEO/Co-Founder、EngineLab 仕組み アーキテクチャはシンプルです。次の図は、コンピューティングが低レイテンシー・高帯域幅で NFS データにアクセスできるよう、KNFSD を使って再エクスポートされた NFS データへのローカルアクセスを提供するデプロイ構成を示しています。 図 1: KNFSD アーキテクチャ図 この構成には以下の機能が含まれています。 ソースマウント – 各プロキシインスタンスは、オンプレミスのファイラー、NFS 対応の Amazon FSx サービス、別のアベイラビリティーゾーンやリージョン、または他のクラウドプロバイダーなど、ソース NFS デバイスのエクスポートをマウントします。 接続 – KNFSD は、 AWS Site-to-Site VPN 、 AWS Direct Connect 、 AWS Interconnect (マルチクラウド) など、他の AWS インフラと同じ接続方式をサポートし、オンプレミスストレージへの安全で低レイテンシーなアクセスを提供します。 負荷分散 – Amazon EC2 Auto Scaling グループ が複数の KNFSD インスタンスを管理します。クライアントトラフィックは DNS ラウンドロビンまたは Elastic Load Balancing (Network Load Balancer) で分散されます。 クライアントへの透過性 – NFS クライアントは、通常の NFS 共有と同じ方法で KNFSD のエクスポートをマウントできます。特別なドライバー、エージェント、設定は不要です。 利用 – Amazon EC2 インスタンスはワークロードの処理に合わせてスケールし、変更なしに KNFSD 経由でソースデータにアクセスし、必要に応じて結果を書き戻します。また、スループット要件の増加に応じて KNFSD インスタンスのスケールアップを促すシグナルを提供します。 “NFS キャッシュは、長年にわたってお客様から繰り返しご要望いただいてきた機能です。自信を持ってお客様に提案できる AWS サポート付きのソリューションが登場したことを嬉しく思います。” – Paul Judkins、VP Cloud Services、Integrated Media Technologies (IMT) Global KNFSD File Cache の位置づけ AWS は幅広いストレージサービスを提供しています。耐久性の高いオブジェクトストレージと分析向けの Amazon Simple Storage Service (Amazon S3) 、フルマネージドの高性能ファイルシステム向けの Amazon FSx、そして弾力的なサーバーレス NFS 向けの Amazon Elastic File System (Amazon EFS) などがあります。これらはいずれも、対象ワークロードのプライマリストアとして設計されています。 データを移行したりクライアントのマウントパスを変更したりすることなく、既存の NFS ソースからバーストスケールのスループットを必要とするワークロードには、透過的なアクセラレーションレイヤーが必要です。 Amazon File Cache や Amazon FSx for NetApp ONTAP FlexCache などのマネージドオプションはこれらのシナリオの一部に対応していますが、Amazon EC2 上で動作するシンプルで低コストなオープンソースのキャッシュレイヤーが最適なケースも多くあります。特に、チューニングの完全な制御、透過的な NFS 再エクスポートのセマンティクス、そして柔軟なスケールアップ・スケールアウトが必要な場合に適しています。 KNFSD が埋めるのはこのニッチです。リポジトリには、強化された AMI、ルート Terraform モジュール (複数の子モジュールと独立したデータベース・メトリクスモジュールを含む)、組み込みのオブザーバビリティ、ヘルスチェック、オートスケーリング、ファンアウトトポロジーが含まれています。 キャッシュは KNFSD 層に保持されるため、ダウンストリームのコンピューティングインスタンスを Amazon EC2 スポットインスタンス (AWS が短い通知で回収できる、大幅に割引された中断可能なキャパシティ) として実行しても、データ損失や再取得のリスクはありません。スポットインスタンスが回収されて新しいインスタンスに置き換えられた場合も、新しいインスタンスはすぐにウォームキャッシュの恩恵を受けられます。 “『Avatar: The Way of Water』では、オンプレミス設備の 250% の規模のクラウドレンダーファームを運用し、AWS と共同開発した NFS キャッシュがショーのデータへのアクセスをスケールさせる上で不可欠な役割を果たしました。Avatar 後に改善点として挙げていた領域 (弾力的なスケーリング、ロードバランシング、階層型キャッシング) は、まさに AWS が KNFSD File Cache に組み込んだ機能です。ハイブリッドレンダーパイプライン全体への導入と、オープンソースプロジェクトへの貢献を楽しみにしています。” – Andy Wright、Head of Pipeline、Wētā FX 主な機能 KNFSD は、迅速なデプロイ、シンプルな運用、初日からのオブザーバビリティを実現するよう設計されています。このセクションでは、本番環境で特に重要な機能を説明します。 事前構築済み AMI リポジトリには Packer ビルドスクリプトが含まれており、Ubuntu ベースの最適化された Amazon Machine Images (AMI) を生成します。従来の x86 Intel・AMD プロセッサと、AWS Graviton Processors (ARM64) などの ARM ベースプロセッサの両アーキテクチャに対応しています。 Packer ビルドで作成されるイメージには以下が含まれます。 NFS 再エクスポートと FS-Cache を有効化したチューニング済み Linux カーネル CloudWatch と OpenTelemetry を使用したオブザーバビリティ向けの KNFSD メトリクスエージェント ヘルスチェックとステータス確認用の KNFSD HTTP エージェント ビルド検証用のスモークテスト AWS はストレージ最適化された Amazon EC2 インスタンス (L2 層向けのローカル NVMe 搭載) を幅広く提供しており、各パイプラインステージのアクセスパターンに合わせて KNFSD インスタンスを選択できます。数百万件の小さなファイル読み取りが中心のワークロードには、最新の i7ie および i8g ファミリーの低レイテンシー NVMe が適しており、大きなシーケンシャル読み取りには im4gn および i3en ファミリーの高スループットと大容量キャッシュが有利です。 AWS Graviton の優位性は特に注目に値します。NFS 再エクスポートとディスクキャッシングは、高いシングルスレッド性能を必要とせず複数コアに並列化しやすいため、AWS Graviton のアーキテクチャと自然に適合します。im4gn.16xlarge は i3en.24xlarge と同等の毎秒 10〜12 GB のスループットを、オンデマンドの時間単価でおよそ半分のコストで実現します。次の表は比較のための Amazon EC2 インスタンスタイプの一例です。最新のインスタンスタイプとリージョン別料金については、 Amazon EC2 インスタンスタイプ のドキュメントをご参照ください。 インスタンス アーキテクチャ ネットワーク ローカルNVMe $/時間 ** 用途 im4gn.16xlarge ARM 100 Gbps 30 TB $5.82 高スループット、GB/sあたりのコスト効率が最適 i8g.16xlarge ARM 50 Gbps 15 TB $5.49 最新世代NVMe、小規模ファイルのIOPSワークロード i3en.24xlarge x86 100 Gbps 60 TB $10.85 大容量キャッシュ、KNFSDの主力インスタンス i7ie.48xlarge x86 100 Gbps 120 TB $24.95 NVMeレイテンシが65%改善、レイテンシに敏感な読み取り処理 ** 執筆時点の US-East-1 (バージニア北部) の料金 ファンアウトアーキテクチャ 多数のクライアントが同じ大規模データセットを読み取るワークロードに対して、KNFSD はオプションの 2 層ファンアウトデプロイをサポートしています。単一の高メモリプロキシ (Tier 1) がソースファイラーとの通信をすべて処理することで、各ファイルが広域ネットワーク (WAN) を通過するのを 1 回のみに抑え、高レイテンシー・低帯域幅の環境にも対応します。2 つ目の小規模プロキシクラスター (Tier 2) がファンアウトして数百のクライアントを提供します。これにより、キャッシュソリューションは実質的に 2 つの役割に分かれます。プライマリの Tier 1 KNFSD インスタンスによる初回の長距離転送と NFS 再エクスポート、そしてクライアントに直接 NFS を提供するセカンダリ Tier 2 KNFSD インスタンスの仕様と最適化です。この構成により、セカンダリ KNFSD インスタンスはクラウド側のキャッシュ充填を維持しながらスケールアップ・ダウンおよびスケールイン・アウトが可能となり、初回の長距離転送の繰り返しを防ぎ、インフラ変更後も迅速に再キャッシュできます。次の図は基本的なファンアウトアーキテクチャを示しています。 図 2: 2つのティアの例, KNFSD ファンアウトアーキテクチャ この構成には以下の機能が含まれています。 ソースマウント – データのキャッシュ元となり、処理済みデータの書き戻し先となるソース NFS ファイルサーバーです。 長距離転送 – データはプライマリの Tier 1 KNFSD インスタンスにキャッシュされ、低帯域幅・高レイテンシー環境に対応します。 Tier 1 KNFSD インスタンス – このプライマリ層のインスタンスは、長距離トラフィックのキャッシュを一元的に担い、書き込みをソースファイラーに返します。 キャッシュ間転送 – KNFSD の Tier 1 と Tier 2 インスタンス間のデータ転送は、 Amazon Virtual Private Cloud (Amazon VPC) 内で行われます。 Tier 2 KNFSD インスタンス – スループット要件に対応するためにファンアウト構成を取るインスタンスです。ワークロードの性能特性に合わせてインスタンスタイプを選択でき、ローカルの Amazon VPC を活用した高速転送が可能です。 コンピュート・キャッシュ間転送 – コンピュートインスタンスは、同じ低レイテンシー・高帯域幅のローカル Amazon VPC 接続を使用して Tier 2 KNFSD インスタンスにマウントします。 エラスティックコンピュート – Amazon EC2 インスタンスはワークロードの処理に合わせてスケールし、変更なしに Tier 2 KNFSD インスタンス上の依存ソースデータにアクセスします。必要に応じて結果を書き戻し、スループット要件を満たすために Tier 2 のスケールアップを促すシグナルも提供します。 オブザーバビリティとメトリクス 従来の NFS インフラはクローズドなシステムとして運用されることが多く、ストレージが遅いと感じていても、その原因を診断したり、キャパシティに関する適切な判断を下したりするための詳細情報が不足しがちです。KNFSD は、CloudWatch Agent と OpenTelemetry ベースの KNFSD メトリクスエージェントを使用して、70 以上のカスタムメトリクスを CloudWatch に公開します。これらのメトリクスはキャッシュインフラの各層を包括的に可視化し、インフラのパフォーマンスをデータに基づいて深く理解するための基盤を提供します。以下の図は、ダッシュボードに表示されるメトリクスの例を複数示しています。 図 3: KNFSDで利用可能な複数の指標ビュー メトリクスのカテゴリ 公開されているメトリクスは、次の 5 つの主要領域をカバーしています。 NFS 接続数とクライアント数 – クラスターの使用率を追跡し、KNFSD インスタンスのスケールアウトが必要なタイミングを把握できます。 読み取り/書き込みスループットとレイテンシー (RTT および EXE) – クライアントがローカル速度に近いパフォーマンスを得られているかを確認し、劣化を早期に検出できます。 FS-Cache のヒット率/ミス率、LRU (least recently used) アクティビティ、ストレージ使用率 – ソースからデータを取得するのではなく、キャッシュがホットデータをどれだけ効果的に提供できているかを把握できます。 NFS スレッドおよびソケットのキュー深度 – プロキシのリクエスト処理パイプラインの飽和を、クライアントに影響が出る前に検出できます。 マウント別・エクスポート別の内訳 – 負荷の原因となっている特定のエクスポートやソースサーバーを特定し、ピンポイントでチューニングできます。 これらのメトリクスを組み合わせることで、プロキシの健全性、キャッシュの有効性、クライアント側の体感を総合的に把握でき、キャパシティ、パフォーマンスチューニング、コスト最適化に関する適切な判断が可能になります。 「AWS がメトリクスと直接連携し、実際の状況をリアルタイムで把握できるソリューションを提供してくれたことは、非常に大きな意味を持ちます。ダッシュボードは完成度が高く、ほとんどのチームがレンダーファームのデータについて持ち得ないレベルの可視性を提供してくれます。」 – Rob Dueckman、シニアソリューションアーキテクト、Integrated Media Technologies (IMT) Global 構築済み CloudWatch ダッシュボード 標準のインフラストラクチャーアズコードデプロイの一環として、構築済みの CloudWatch ダッシュボードがクラスターと同時にデプロイされます。手動でメトリクスを設定することなく、すぐに可視化を開始できます。ダッシュボードにはキャッシュヒット率、アクティブオブジェクト数、読み取り/書き込み帯域幅、IOPS、プロキシごとのトラフィック分散など、運用上重要なメトリクスが一目で確認できる形で表示されます。 Prometheus および Grafana へのエクスポート メトリクスエージェントは OpenTelemetry ベースのため、必要に応じてテレメトリを Prometheus や Grafana にエクスポートすることも可能です。 インフラのサイジングとコスト管理 最も重要なメトリクスであるキャッシュヒット率は、プロキシがオリジンサーバーへの読み取り負荷をどれだけ効果的に吸収できているかを直接示します。LRU エビクション率やスレッド・ソケットのキュー深度と組み合わせることで、適切な対応策が明確になります。接続が飽和しているがヒット率が良好な場合はスケールアウト (KNFSD インスタンスの追加)、エビクションが増加してヒット率が低下している場合はキャッシュディスクのスケールアップが必要です。 これらのメトリクスはパフォーマンス問題が発生した際の推測作業も不要にします。ネットワークの制約、キャッシュディスクの飽和、プロキシの過負荷を素早く切り分け、やみくもにキャパシティを追加するのではなく、適切な対処を取ることができます。 開発者体験とデプロイ このプロジェクトは、リポジトリのクローンから稼働クラスターまでの手順を最小限の手間で完了できるよう設計されています。リポジトリには Visual Studio Code Dev Container が同梱されており、Terraform、Packer、Go、Python、 AWS Command Line Interface (AWS CLI) 、各種リンティング・テストツールを含む開発環境がすぐに使える状態で提供されます。ローカルへのインストールは不要で、リポジトリを開いてコンテナを起動すれば、すぐに AMI のビルドやクラスターのデプロイを開始できます。 デプロイは単一の Terraform モジュールで完結し、Amazon VPC サブネット、AMI ビルド、ソース NFS エクスポートを指定するだけで開始できます。KNFSD インフラ (Amazon EC2 Auto Scaling グループ、セキュリティグループ、ヘルスチェック、DNS レコード、オプションのロードバランサー、FSID データベースなど) は宣言的に作成・管理されます。リリースタグでバージョンを固定し、標準の Terraform ワークフローで任意のタイミングでアップデートできます。 同じ Dev Container 環境が開発ライフサイクル全体をサポートします。Packer による AMI ビルド、パフォーマンスの実行とプロファイリング、テストクラスターのデプロイ、Terratest 統合によるスモークテストの実行まで対応しています。コントリビューター環境とデプロイ環境に差異はなく、両者は同一の環境です。 オートスケーリング NFS キャッシュのオートスケーリングは、標準的なメトリクスではうまく機能しません。CPU 使用率はプロキシの負荷を適切に反映しないため、NFS 接続が飽和していても CPU 使用率が 40% にとどまるケースがあります。KNFSD では代わりに、インスタンスごとのアクティブ NFS 接続数というカスタム CloudWatch メトリクスを基にスケーリングします。接続数が設定したしきい値を超えると、クラスターは自動的にキャパシティを追加します。スケーリングポリシーはスケールアップのみに設定されています。スケールダウンすると、構築に時間を要したウォームキャッシュデータが失われるだけでなく、より重大な問題として、アクティブな NFS マウントが切断され、クライアントで I/O ストールが発生するためです。ワークロードが落ち着いた後のスケールダウンは、任意のタイミングで手動で行います。 はじめに KNFSD は Apache 2.0 ライセンスのオープンソースプロジェクトとして、 GitHub で公開されています。 リポジトリには以下が含まれています。 開始するための詳細な 前提条件 ソース NFS サーバー、KNFSD プロキシ、NFS クライアントのエンドツーエンドのデプロイ手順を解説したステップバイステップの チュートリアル すべての機能、設定変数、運用上の考慮事項を網羅した包括的な ドキュメント Amazon FSx for NetApp ONTAP、Amazon FSx for OpenZFS、サードパーティの NFS ゲートウェイデバイス向けのすぐに使える サンプル 質問、機能リクエスト、フィードバックは以下からお寄せください。 GitHub Issues メールでのお問い合わせ まとめ NFS インフラはデータセンターの壁で止まるように設計されたものではありません。KNFSD を使えば、その必要もなくなります。 数千コアにわたる計算負荷の高いタスクを実行する場合でも、パイプラインを再設計せずにハイブリッドワークフローを AWS に拡張する場合でも、KNFSD はコンピュートがすでに AWS で享受しているのと同じ弾力性を、透過的かつ高性能に、ストレージのロックインなしでデータにもたらします。 今すぐ KNFSD File Cache から始めましょう。 参考資料 AWS HPC コミュニティによる NFS 再エクスポートの詳細: Accelerating file reads with a storage caching server (AWS HPC Blog) Avatar 2: Way of Water で Wētā FX が NFS 再エクスポートを使用して AWS 上でスケールした方法: How Wētā FX scaled NFS for Avatar: The Way of Water (DigiPro 2023) TAGS: amazon ec2 , Media &amp; Entertainment , storage Andy Hayes Andy は、AWSのVisual Computing担当シニアソリューションアーキテクトです。 DJ Rahming DJ は、AWSのVisual Computing担当シニアソリューションアーキテクトです。 Mike Owen Mike は、AWSのVisual Computing担当プリンシパルソリューションアーキテクトです。 Sean Wallitsch Sean は、AWSのVisual Computing担当シニアソリューションアーキテクトです。 &nbsp; 参考リンク AWS Media Services AWS Media &amp; Entertainment Blog (日本語) AWS Media &amp; Entertainment Blog (英語) AWS のメディアチームの問い合わせ先:&nbsp; awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は Visual Compute SSA 森が担当しました。原文は こちら をご覧ください。

本記事は Kiro ブログの記事「 Introducing Kiro Crew 」（2026年8月4日、著者: Bolin Chen、Zejiang (Joe) Guo、Zezhen Xu）を翻訳したものです。 気持ちのいい金曜日の午後。そろそろ仕事を切り上げて、外の天気を楽しもうとしています。ちょうど片付けを始めたところで、チームメイトから緊急のレイテンシー急増について助けてほしいと連絡が入ります。あなたは似たようなインシデントを覚えています。どのメトリクスを調べればいいか、どの診断を走らせるか、前回ログがどこを指し示していたか。問題の切り分け自体は、それほど難しくありません。ただ、いくつものツールをまたいで動く必要があるのに、あなたは一度に一箇所にしかいられないのです。 これが現実のエンジニアリング業務の姿です。それは決して「1 つのセッションで 1 つのタスク」ではありませんでした。リポジトリ、ツール、レビュー、そして何日もの時間にまたがります。たとえ 1 つのタスクが自走していても、それを支えているのは結局あなたです。コンテキストをつなぎ直し、ハンドオフを調整し、手持ちのツールを縫い合わせて、動き続ける何かに仕立てる。気づけばあなた自身が、自分のツール同士をつなぐ統合レイヤーになっています。そしてあなたが席を離れた瞬間、すべては止まり、あなたが戻るのを待ち始めます。 Kiro Crew は、その仕事を代わりに引き受けます。Crew にメッセージを 1 通投げれば、前回どう対応したかを探し出し、まとめ、同僚に送るところまでを、あなたが再び手を入れることなく進めてくれます。あなたはその日の仕事を終えて外に出て、「問題は解決しました」というチームからのメモを目にするだけです。 チケットのキューを渡せば、Kiro Crew はトリアージして振り分け、オーナーを特定し、あなたの判断が必要なものにフラグを立てます。複数リポジトリにまたがるインシデントを指し示せば、あなたが修正に集中している間に調査を進めます。マイグレーションを開始すれば、あなたが会議中でも眠っている間でも、チェックポイントとリトライを通じて前進し続けます。すでにあなたが使っているツールをつなぎ、セッションをまたいで作業を調整するので、戻ってきたときに待っているのは「やり直すべきワークフロー」ではなく「進んだ結果」です。 Kiro Crew の始まり Kiro Crew は、Amazon 社内の MeshClaw という個人プロジェクトとして始まりました。私たち 3 人は、社内には存在しなかったシンプルなものを求めていました。タスクを投げて、その場を離れ、戻ってきたらレビューする価値のある成果ができている。そして 1 つのプロンプトに付き添い続けるのではなく、複数のタスクを同時に走らせられる。そんな仕組みです。私たちは OpenClaw や、自己学習するエージェントで AI 開発を担う各種ツールの勢いに刺激を受けていましたが、社内開発のセキュリティ要件を満たすものが必要でした。日常的に使っているコーディングツールが Kiro だったので、CLI 経由で Kiro のハーネスの上に構築するのが自然な選択でした。 私たちはまず自分たちのために作りました。やがて Amazon 社内の他のビルダーたちが使い始め、そこで起きたことこそが、これをオープンに公開する理由そのものです。さまざまなバックグラウンドを持つビルダーたちは、単に使うだけでなく、自分の必要に合わせて拡張していきました。誰かが自分のワークフローで穴に気づけば、必要なピースを足し、それはその人自身にも、後から来る全員にも残りました。そうして作られたものの多くは、本来ならバックログに埋もれていたはずの作業です。狭いエッジケース、細かな使い勝手の改善——そのワークフローの中で生きている人だけが思いつくような修正です。6 か月足らずで、Kiro Crew は Amazon 社内の 39,000 人を超えるビルダーに採用され、500 人近いコントリビューターが 597 件の更新を、平均で週 143 コミットのペースで届けてきました。小さく具体的な貢献が積み重なり、個人のサイドプロジェクトは、エンジニアだけに限らない多様な職種のコミュニティによって維持されるものになりました。 この複利的な貢献こそが、オープンソース化を決断させた理由です。あなたのコードとツールにアクセスするワークスペースは、読めて、好きな場所で動かせて、中を検査でき、変更できるべきです。たとえその変更を望んでいるのが自分ひとりだったとしても。この分野は急速に変化しており、オープンソースこそが、すでに有用だと分かっているものを開発者の手に届け、それを使う人たちと一緒に進化させ続けるための手段です。 実務に仕事に耐えるセキュリティ 作業を任せるということは、Kiro Crew にコードや CI への本物のアクセスを渡すということです。だからこそ、最初のコミットから安全であるように作られています。Kiro Crew は初日から多層防御を備えています。OS レベルのサンドボックス、デフォルト拒否のコマンド制御、疑わしいパターンのブロック、入力検証、機密パスのブロック、認証情報のマスキング、そしてすべてのアクションを記録する署名付き監査ログです。オープンソースのエージェントは他にもたくさんあります。Kiro Crew に実務を任せられるのは、それが開発者のために一から作られており、プロダクションコードが要求するセキュリティ姿勢を備えているからです。オープンであるからこそ、すべてのレイヤーをソースと突き合わせて検証し、与えたアクセス権で何をしているかを見張ることができます。 あなたのコードに対して動くワークスペースが、ブラックボックスであってはなりません。Kiro Crew は Agent Client Protocol （ACP）の背後でエージェントをオーケストレーションし、すべてのステップをリアルタイムに観測できます。タスクをどう計画し、並列のサブエージェントをどう起動し、どのツールを呼ぶかをどう決め、各アクションを承認のためにどうゲートし、結果をどう統合し直すのか——そのすべてを見られます。Activity ビューには、各エージェントの推論、すべてのツール呼び出し、そしてその結果が発生順に、ダッシュボード上のエージェントごとのカードとして表示されます。 動かす場所も自分で選べます。デスクトップアプリ、Web ダッシュボード、TUI から Kiro Crew を直接操作でき、会話・ファイル・タスク・承認・メモリ・スケジュール・Apps を横断して扱えます。ローカルでも、自分が管理するリモートマシンでも実行できます。Slack、Telegram、Discord といったツールを接続すれば、ワークスペースやその状態を移すことなく、別のクライアントから同じ作業を続けられます。ダッシュボードはデフォルトでローカルにバインドされ、機密パスと認証情報は実行時に保護され、ツールのリクエストには承認を必須にでき、アクティビティはレビューのために記録されます。 開発者の仕事のしかたに、端から端まで寄り添う Kiro Crew は、複数リポジトリにまたがるインシデントを同時に調査する、あなたが不在の間に数時間かかるマイグレーションを走らせる、あるいはあなたがログインする前にオープンな PR をチェックして flaky なテストを直しておく朝の定期処理など、セッションをまたいで動くように作られています。それを可能にしているのは、いくつかの要素です。 エージェントは自己学習し、自己進化する: メモリが設定・アクティブなプロジェクトのコンテキスト・関連する履歴を新しいセッションへ引き継ぐので、ゼロから始まりません。あなたの訂正は永続的な「教訓」となり、以降の振る舞いを変えます。プロジェクト固有のガイダンス用に、ワークスペース単位の教訓も使えます。繰り返し現れるパターンは、検査・編集・削除ができる再利用可能なスキルになります。メモリ、教訓、スキルはつねに可視化されているので、Crew が何を持ち越すかはあなたが決められます。 あなたのエージェント Crew は、あなたがいないときも働き続ける: 定期ジョブはあなたが定義したスケジュールで動きます。朝のダイジェストがあなたの注意を必要とするものを集め、ハートビートが PR やデプロイの状態が変わるまで見張り、認証付き Webhook が外部イベントの到着をきっかけに作業を開始します。推論を必要としないジョブは、モデル呼び出しなしの素のスクリプトやコマンドとして実行されます。長時間のタスクは、あなたが別の作業をしている間も、チェックポイント・検証・リトライを通じて前進し続けます。 複数のエージェントを協調させる: 複数の会話のほうが向いている作業では、それぞれ独立したコンテキストを持つ会話を同時に走らせることもできますし、独立した調査や実装をサブエージェントに委譲し、その結果を親の会話に返させることもできます。専門エージェントが並列で作業を処理する間、メインの会話はゴールに集中し続けられます。 作業を目的専用のインターフェースへ持ち込む: すべての作業がチャットウィンドウに向いているわけではありません。Kiro Crew はそれを Apps に持ち込みます。Apps は共有可能で目的に特化したインターフェースで、一つひとつの指示をチャットせずに日々の業務を自動化できます。Apps はカスタム UI と、エージェント・スキル・スケジュール・インテグレーション・バックエンドサービスを組み合わせたものです。MCP Apps とプラグインがデータとアクションをその体験に持ち込み、Kiro Crew は受付からレビュー、完了までの作業の流れを整えます。たとえば Issue トリアージ App は、リポジトリのデータをリーディングペイン付きのキューに取り込み、トリアージ用のコントロール、専門エージェント、定期スキャンを備えます。App のストアページで利用できる Apps は今後も拡大していきますが、ローンチ時点ではワークツリー管理の DevFleets 、長時間タスクを実行する Task Runner 、Issue と PR をトリアージする Issue Radar などが含まれます。まだ用意されていないツールやユースケース、あるいは「自分の思い描く形」にするために、App SDK で独自の Apps を作ることもできます。 Launch Darkly アプリは、機能管理（フィーチャーマネジメント）の機能をKiro Crew に直接統合します。開発者はワークスペースを離れることなく、あらゆるプロジェクトや環境にわたって Launch Darkly の機能フラグを閲覧、検索、作成、更新できます。Launch Darkly の MCP サーバーとパブリックAPIを基盤としているため、フラグは AI コーディングセッションのネイティブな一部として機能します。エージェントはコード内のフラグ参照を特定し、フラグを利用した変更を実装した上で、ロールアウト（展開）の制御をユーザーに引き継ぐことが可能です。 自分のものにする Kiro Crew が広がったのは、そのアーキテクチャのおかげではありません。人々が自分の仕事や好みに合わせて曲げられたからです。その同じ可能性が、いまあなたのものになります。あなた専用のエージェントの Crew を組み上げ、あなた固有のツールとワークフローを横断して協調させ、仕事を止めずに進めてください。 今日ローンチする機能は、Kiro Crew を自分の実務で使っていた人たちが作ったものです。次にあなたが必要とする機能は、あなたが作れます。すでに使っているツールを MCP で持ち込み、App を作り、オーケストレーションを形づくり、作ったものを反復し続けてください。すでに持っているスキルもここで動きます。オープンな標準に基づく他のエージェントプラットフォーム向けに作られたものは、Kiro Crew でも変更なしに動くので、ゼロから始め直すのではなく、手元のものを持ち込めます。 プロジェクトの運営方法 私たちは、社内で MeshClaw を育ててきたときと同じ「Kiro Crew で作る楽しさ」を、開発者コミュニティにも体験してほしいと考えています。そのため Kiro Crew はオープンに開発されており、それはガバナンスの進め方も含みます。プロジェクトは MAINTAINERS.md に公開されたメンテナーによるステアリングコミッティが運営し、意図的にミニマルなガバナンスモデルを採っています。提案はプルリクエストとして提出され、リポジトリ上で議論され、決定はそこに記録されて誰でも読めます。どの開発者もその議論に参加できます。コントリビューション、議論、ガバナンス、ロードマップ計画はすべてオープンな場で行われ、次に何が出荷されるかをコミュニティが直接形づくれます。 私たちが言う「オープン」は、信頼に関わる意味でもオープンです。他の AI コーディングツールやプロバイダーとのインテグレーションを含め、あらゆる種類のコミュニティ貢献を歓迎します。開発者の仕事に役立つのであれば、それが Kiro 自身の製品戦略に合致するかどうかに関わらず、ここに置かれるべきです。Kiro はコアプロジェクトを健全に保ち、すべての Issue と PR に対応するためにエンジニアを専任で配置しています。まずは Kiro と AWS のエンジニアがプロジェクトをメンテナンスし、信頼できるコントリビューターが現れるにつれて、私たちのチーム外のメンテナーを含む形へとモデルを拡張していけます。ロードマップは通達ではなく、対話であるべきものです。 Kiro の上に構築 すでに Kiro を使っているなら、設定はそのまま引き継がれます。Kiro Crew はローンチ時点で Kiro CLI の上で動き、既存の .kiro 設定をそのまま読み込むので、ステアリングファイル、スキル、カスタムエージェントは追加設定なしで移行できます。 はじめかた Kiro Crew のページ からダウンロードするか、 GitHub リポジトリ を今日クローンしてください。リポジトリには macOS、Linux、Windows のセットアップ手順と、Slack、Telegram、WeCom を接続するためのガイドが含まれています。 まずは、すでに 1 セッションを超えて広がっている作業から始めてみてください。マイグレーション、定期的なレビュー、監視が必要なプルリクエストなどです。そこから App をインストールし、繰り返しているワークフローからスキルを作り、あるいはあなたの仕事に次に必要なインテグレーションをコントリビュートしてください。Kiro Crew は、開発者が自分にとって効いたものを共有することで育ってきました。オープンソースとしての公開は、これから何になるかを誰もが形づくれるようにするためのものです。あなたがどんなユースケースや機能を作り出すのか、私たちは待ちきれません。そして私たちと同じくらい、遊びながら試すことを楽しんでもらえたら嬉しいです。 ダウンロード | GitHub で見る | ドキュメントを読む | Discord に参加する

本記事は 2026 年 8 月 3 日に公開された Clare Liguori、Romain Dura、Al Harris、Richard Threlkeld による “ One agent, every surface: how we built the Kiro agent harness ” を翻訳したものです。 Kiro の開発初期、私たちは開発者の 1 日のなかでエージェント駆動の開発がどのように感じられるべきかを議論し始めました。繰り返し立ち返ったのは、セッションがラップトップとクラウドサンドボックスの間を摩擦なく行き来する姿でした。1 日の終わりにラップトップを閉じても、Kiro セッションはクラウドで動き続けます。コーヒーを取りに行く合間にスマートフォンから状況を確認できます。翌朝、Kiro IDE を開いて中断したところから作業を再開します。 Web 版 Kiro でプロジェクトを開始し、Kiro IDE でコンテキストを追加し、既にテストとイテレーションを進めているターミナルでは Kiro CLI を使い続け、Slack から進捗を確認します。エージェント駆動の開発とは、作業するあらゆるクライアントを横断する 1 つの連続した会話であるべきです。 今年の初め、私たちはエージェントのアーキテクチャがこのビジョンの実現を妨げていることに気づきました。当時、Kiro IDE、CLI、Web の各クライアントは、それぞれ独自のセッションフォーマット、ツールセット、設定モデルを持つ専用のエージェントを実行していました。セッションと環境の間を容易に移動するには、どのクライアントを使っていても、どこで動作していても同じように振る舞う単一のエージェントが必要です。クライアント専用のエージェントアーキテクチャでは、エージェント同士が十分な共通基盤を持っていなかったため、あるクライアントで開始したセッションを別のクライアントに移すことができませんでした。本記事では、3 つのエージェントのコードベースを 1 つの Kiro エージェントハーネスに統合した過程 (もちろん Kiro 自身を使って構築しました) と、私たちのビジョンを実現可能にしたアーキテクチャ上の決定について解説します。 分岐していった 3 つのハーネス Kiro を作り始めた当初、私たちはスピードと実験を優先しました。各クライアントチームが独自のエージェントハーネスを作ることを推奨しました。エージェントハーネスとは、エージェントループ、ツール実行、サブエージェントへの委譲、セッション管理、設定のロード、モデルとの通信を管理するオーケストレーション層のことです。IDE チームは Code OSS の拡張モデルに合わせて TypeScript で、CLI チームはパフォーマンスを重視して Rust で、Web チームは最新のエージェント研究に近い場所に居るために Python で、それぞれ独自に構築しました。 ハーネスを分けたことで各チームは独立して素早くリリースし、イテレーションできましたが、同時にそれぞれのチームが異なる選択をすることも意味しました。セッションストレージはクライアントごとに動作が異なりました。権限システムは独立して設計されており、互換性のない構文を使っていました。CLI は正規表現ベースの allowedCommands / deniedCommands を使い、IDE は trustedCommands にプレフィックスマッチを、denylist にはサブストリングマッチを使っていました。コンパクション戦略も分岐しました。サブエージェントのコンテキスト共有も異なるモデルに従っていました。カスタムエージェントもクライアントごとに動作が違いました。機能セットも分裂しました。仕様駆動開発と powers は IDE のみで動作し、プランモードとコードインテリジェンスは CLI のみで動作していました。 実装コストは時間とともに複利で膨らみました。新しい機能は 3 回作って 3 回保守する必要があり、その結果としてエージェントの挙動がわずかに異なることもありました。バグも 3 回修正する必要がありました。ユーザーはどのクライアントを選ぶかによって不整合を体験することになりました。セッションがクライアントとコンピュートを横断して移動するという私たちのビジョンは、共有のセッションフォーマット、共有のツールセット、共有の設定モデルが存在しないためアーキテクチャ的に不可能でした。各チームの独立性と個別のスピードを維持するために、クライアント間でエージェントの振る舞いに関する契約を合意し、3 つのハーネスそれぞれで実装するという案も検討しました。しかしインターフェースの整合を取ることも、新機能ごとに増えていく調整コストを生みます。新機能ごとに仕様書、3 つの実装、そして同一の振る舞いを継続的に検証する作業が必要になるのです。 転機となったのは、Web 版 Kiro のパブリックローンチの準備を進めていたときでした。Web 版 Kiro を独自のエージェントとともにローンチし、この複利的な実装コストを払い続けるのではなく、各チームが学んだベストな知見を組み合わせた単一のエージェントハーネスを構築することを決めました。単一のハーネスであればチーム間の重複がなくなり、すべての労力を 1 箇所に集中投資できます。 Kiro エージェントハーネスのアーキテクチャ 私たちが早い段階で下した重要なアーキテクチャ判断は、ハーネスを各クライアントにコンパイルして組み込むライブラリではなく、独立したサーバープロセスとして構築することでした。過去の試みから、共有ライブラリでは十分に強い境界を強制できないことがわかっていました。クライアントコードは公開を意図していない内部メソッドを呼び出し始めるか、ライブラリの上に独自のエージェントロジックを重ねてしまいます。そうなれば実装は再び分岐していきます。独立したプロセスであれば、この分離が現実のものになります。ハーネスとクライアントは同じ言語やランタイムを共有する必要がないため、各クライアントは自分のプラットフォームに適したスタックのまま留まれます。 これにより、3 つの密結合したクライアントとエージェントのペアではなく、 ┌────────────┐ ┌────────────────────────────────┐ │ Kiro IDE ├──────│ IDE agent (TypeScript) │ └────────────┘ └────────────────────────────────┘ ┌────────────┐ ┌────────────────────────────────┐ │ Kiro CLI ├──────│ CLI agent (Rust) │ └────────────┘ └────────────────────────────────┘ ┌────────────┐ ┌────────────────────────────────┐ │ Kiro Web ├──────│ Web agent (Python) │ └────────────┘ └────────────────────────────────┘ クライアントと単一のエージェントハーネスとの間にきれいな分離ができました。 ┌─────────────────────────┐ ┌─────────────────────────────────┐ │ Clients │ │ Kiro agent harness │ │ │ │ │ │ UX and presentation │ │ Agent loop │ │ User interaction │───protocol───│ Tools and sub-agents │ │ Platform-native tools │ │ Session state │ │ (optional overrides) │ │ MCP client │ │ │ │ Configuration and steering │ │ │ │ Permissions │ │ │ │ Telemetry │ └─────────────────────────┘ └─────────────────────────────────┘ Kiro エージェントハーネスはコードベースの隣で動作する軽量なプロセスで、高速に起動し、エージェント側のすべてを所有します。クライアントはユーザーがエージェントとどのようにやり取りするか、エージェントの作業をどのように提示するかを所有します。この境界を越える唯一の方法は、定義されたプロトコルインターフェースです。コンパイルされて組み込まれるライブラリではなく独立したプロセスであるため、あらゆるコンピュート上で動作できます。同じハーネスがラップトップ上でも、クラウド上の VM 内でも、クライアントに意識させることなく起動できます。 サーバーとクライアントの間に明確なインターフェースがあるということは、エージェントのコードがクライアントとは独立して進化することを意味します。ハーネスの変更がプロトコルインターフェースに影響を与えない場合 (たとえば新しいツールの追加、プランニングの改善、エージェントループのチューニング)、クライアント側の変更ゼロですぐにすべてのクライアントにリリースできます。たとえば最近、カスタムエージェントのライブリロード機能を追加しました。セッション中に .kiro/agents/ のファイルを編集すると、ハーネスがすぐに検知し、利用可能なコマンドをクライアントに再度通知します。利用可能なコマンドの通知タイプはすでにプロトコルに存在していたため、クライアントの変更は不要でした。どのクライアントも追加の変更なしにこの機能を手に入れられたのです。 サポート対象のクライアントが多様なため、このハーネスは画一的な設計ではありません。クライアントごとに機能が異なり、一部の操作はクライアントネイティブの機能を使ってクライアント層で実装するほうが理にかなっています。クライアントは独自のツールを提供して組み込みツールを抑制でき、自分のフォームファクター (form factor) に合ったものを使えます。たとえば IDE はファイル操作に Code OSS の API を使い、ファイルシステム上で直接動作するハーネスの組み込みツールではなく、独自のファイル読み書きツールを提供しています。エージェントがこれらのクライアント提供ツールのいずれかを実行する必要があるときは、クライアントに通知し、クライアントがツールを実行して結果を返します。 プロトコル: Agent Client Protocol (ACP) クライアントとハーネスの境界を定義するプロトコルとして、 Agent Client Protocol (ACP) を選びました。ACP はエージェントとクライアントの通信を標準化した仕様で、2026 年 6 月に 1.0 に到達しました。このプロトコルは JetBrains の IDE、Xcode、Zed といった IDE や、Obsidian、Emacs、Neovim といったほかのエディターでもサポートされています。私たちは今年の初めに Kiro CLI で ACP を採用した経験 から、これらのアプリケーション内で直接 Kiro とやり取りできるようにしていました。統一されたハーネスにも ACP を採用することにしたのは、サードパーティ製エディター向けだけでなく、Kiro 自身のクライアントと私たち自身のエージェントの間のインターフェースとして使うためです。ACP の 2 つの性質がこれを可能にしました。カスタムメソッドに対する拡張性と、トランスポートの柔軟性です。 ACP は公式にトランスポートとして stdio をサポートしています。これはハーネスがエディターやターミナルの子プロセスとして動作するローカルクライアントで機能します。Web 版 Kiro や iOS アプリのようなリモートクライアントには、別のトランスポートが必要でした。これらのクライアントがクラウドサンドボックスで動作するハーネスに接続できるように、独自の WebSocket ベースのトランスポートを追加しました。クライアントがどのトランスポートを使うかに関わらず、バイナリ、ツール、エージェントの振る舞いは同一です。 ┌─────────────────────────────────────────────────────────────┐ │ Kiro agent harness │ └──────────┬────────────────┬────────────────┬────────────────┘ │ stdio │ stdio │ WebSocket │ │ │ ┌──────┴──────┐ ┌──────┴─────┐ ┌───────┴──────────────┐ │ Kiro CLI │ │ Kiro IDE │ │ Kiro Web · iOS app │ │ (terminal) │ │ (Code OSS) │ │ (browser · mobile) │ └─────────────┘ └────────────┘ └──────────────────────┘ トランスポートを超えて、私たちは ACP のメソッドセットを Kiro-ACP と呼ぶものに拡張しました。標準の ACP は基本的な部分 (セッションのライフサイクル、メッセージのストリーミング、ツール呼び出しのレポート) を扱いますが、Kiro の機能にはそれ以上のものが必要でした。たとえばライブステアリングを追加しました。ユーザーはエージェントの作業中でもメッセージを送信でき、そのメッセージが次の推論ターンで注入されることで、キャンセルや待機なしにエージェントの方向性を調整できます。ACP はメッセージのキューイングをサポートしていないため、ライブステアリングを実現するために新しいメソッドプロパティと通知で ACP を拡張しました。また Kiro の仕様駆動開発ワークフローを専用のメソッド群としてモデル化し、ACP の基本的なツール承認を豊富なマルチスコープの権限システムへと拡張し、コンテキストウィンドウの使用状況とフック実行に関する通知を追加しました。合計で Kiro-ACP はベースプロトコルに加えて 20 を超えるエージェント呼び出し可能なメソッド、15 のクライアント呼び出し可能なメソッド、20 の通知タイプを追加しています。ACP の拡張モデルはこれをきれいに保ちます。仕様どおり、カスタムメソッドはアンダースコアのプレフィックスを使い、Kiro の拡張はすべて _kiro/ 名前空間の下に配置されています。プロトコルをフォークすることなく、Kiro 固有の機能のために拡張できるのです。 結果として、サードパーティのクライアントはファーストパーティのクライアントと同じ方法で接続できます。ACP 互換のクライアントであれば、ツール、サブエージェント、セッション管理、MCP 接続を含む完全なエージェントを利用できます。ファーストパーティのクライアント (IDE、CLI、Web、iOS) は加えて Kiro-ACP の拡張を利用して、ライブステアリング、仕様、リッチな権限 UI、コンテキスト使用量トラッキングといった機能を提供します。 仕様、エージェント、フックがどこでも使える 単一のハーネスがもたらす直接的なメリットは、これまで 1 つのクライアントに閉じ込められていた機能が、同じ設定フォーマットと同じ振る舞いで、どのクライアントでも使えるようになったことです。 仕様駆動開発 は以前は IDE 限定でした。今では CLI ( /spec new で開始できます) と Web 版 Kiro でも動作します。エージェントは仕様ワークフローを駆動する LLM とのやり取りと自動化された推論 (要件の生成、技術設計の作成、作業のタスクへの分解) を扱い、各クライアントは自分のフォームファクターに合った形でそれを提示します。IDE は仕様のアーティファクトを横並びのペインで表示します。CLI はターミナル内でレンダリングします。Web 版 Kiro はブラウザーでインラインレビューとマルチユーザーコラボレーションとともに表示するので、チームが一緒に仕様をイテレーションできます。エージェントは ACP を話し、クライアントは出力をどう提示するかを決めます。 カスタムエージェント は、どのクライアントでも同じ .kiro/agents/ Markdown フォーマットを使います。エージェントには説明、システムプロンプト、タグベースのツール選択 (個別のツール名ではなく read 、 write 、 shell といったシンプルなタグ)、アクセス可能なサブエージェント、インラインの MCP サーバー定義、インラインの権限ルールを定義できます。カスタムエージェントの設定をバージョン管理にコミットすれば、チームメンバー全員がすべてのクライアントで使えるようになります。 --- description: セキュリティ上の問題を確認するコードレビューエージェント tools: [read, shell, "@github"] permissions: rules: - capability: fs_read effect: allow - capability: shell match: ["git diff *", "git log *", "npm audit"] effect: allow mcpServers: github: url: https://api.githubcopilot.com/mcp/ headers: Authorization: Bearer ${GITHUB_TOKEN} --- あなたはセキュリティに重点を置いたコードレビュアーです。現在の差分を レビューし、脆弱性、認証情報の漏洩、安全でないパターンを確認してください。 依存関係のアドバイザリは npm audit で確認してください。 フック は同じ .kiro/hooks/*.json フォーマットを使い、同じトリガー ( SessionStart 、 PreToolUse 、 PostToolUse 、 FileCreate 、 FileSave ) で、すべてのクライアントで同じように動作します。 機能の可用性を超えて、統一されたハーネスは、正しく作るのが難しい領域でも一貫した振る舞いを提供します。コンテキスト管理、コンパクション、要約は、どのクライアントを使ってもすべて同じように動作します。以前はハーネスごとに独自のコンパクション戦略を持っていたため、IDE、CLI、Web クライアントのどれを使っているかによってセッションが長くなるにつれて振る舞いが変わることがありました。今では 1 箇所で実装、テスト、改善される単一の実装があります。統一されたハーネスをクライアント全体に展開して以来、コンテキスト保持を改善するため、ハーネスにより良いコンパクションプロンプトをすでにリリースしています。またハーネスの深い部分でレジリエンスとパフォーマンスの改善もリリースしました。モデル推論リクエストの改善されたリトライロジック、高速な権限評価、より弾力性のある MCP サーバー接続などです。すべてのクライアントがこれらの変更の恩恵を受けます。結果として、どのクライアントを好むかに関わらず、一貫した品質と信頼性が得られます。 単一のポリシー言語 統一ハーネスが登場する前、各クライアントは異なる構文、異なるセマンティクス、異なる設定場所を持つ独自の権限システムを持っていました。CLI は正規表現パターンによる allowedCommands / deniedCommands を使いました。IDE はプレフィックスマッチによる trustedCommands と、サブストリングマッチによる別の commandDenylist を使いました。どちらのクライアントでも権限はツール単位でした。 .env への読み取りを拒否する といった単一の意図は、ファイルを読める各ツール (read、glob、grep、コードインテリジェンス) に対して個別に設定する必要があります。1 つでも見落とすと、エージェントは別のツール経由でそのファイルにアクセスできてしまうのです。ユーザーはツール呼び出しごとに y を押し続けるか、すべてを信頼するかの二択を迫られ、その中間の実用的な選択肢がありませんでした。私たちが求めていたのは、ケイパビリティレベルで意図を表現でき、永続的かつ組み合わせ可能な同意によって承認疲れ (acceptance fatigue) を減らせる権限モデルでした。 今では、形式的に検証されたポリシー言語である Cedar に支えられた、単一のケイパビリティベースの権限モデルがあります。1 つのルールで、すべてのツールにまたがる同種の操作をまとめて対象にできます。 rules: # Block all tools that read files from accessing secrets - capability: fs_read match: [".env", ".env.*", "secrets/**", "**/*.pem"] effect: deny # Allow specific shell commands without prompting - capability: shell match: ["npm test *", "npm run build", "git status"] effect: allow # Allow an MCP server's tools - capability: mcp match: ["github/*"] effect: allow ケイパビリティはツールを機能ごとにグループ化します。 fs_read 、 fs_write 、 shell 、 web_fetch 、 mcp 、 subagent などです。fs_read の deny は、ファイルを読むすべてのツール ( read_file 、 grep_search 、 file_search 、そして今後追加される read 系ツール) を個別に列挙することなくブロックします。 ポリシーは複数のスコープにまたがって合成でき、deny が常に勝つセマンティクスでマージされます。Kiro 自体は変更不可能なセキュリティ不変条件を適用します (たとえば、エージェントは自身の権限ファイルを変更できません)。エンタープライズ管理者は MDM 経由で制限をプッシュできます。ユーザーは自分のルールをユーザーレベルまたはワークスペースレベルで設定します。エージェントプロファイルはその役割に応じた権限を宣言できます。セッションレベルの判断は、作業しながら積み上がっていきます。事前の設定は不要です。ポリシーは同意の判断を下すにつれて自然に育っていき、意味のあるスコープでそれを永続化できます。 ハーネスがビジョンを解き放つ 新しいエージェントハーネスアーキテクチャの成果はすでに現れています。すべてのクライアントが統一ハーネスに移行して以来、クライアント側の変更ゼロで複数の機能をクライアント横断でリリースしてきました。グローバルフックとポリシープリセットもその一例です。 グローバルフック は ~/.kiro/hooks/ でフックを一度定義するだけで、すべてのワークスペースで自動的に発火するため、保存時のリント実行やコミット前のセキュリティチェックといった横断的な振る舞いをプロジェクトごとに複製する必要がなくなります。 ポリシープリセット は edit-workspace や dev-shell のような合成可能な名前付きルールセットで、一般的なワークフローにおけるプロンプト疲れ (prompt fatigue) を減らします。権限にポリシープリセットを追加すると (たとえば policies: [dev-shell, edit-workspace, read-all] )、ハーネスのポリシーエンジンがロード時にそれらを個別のルールに展開します。どちらの機能もハーネスのアップデートだけですべてのクライアントに提供されました。 本記事の冒頭で述べたビジョンには、まだ構築が必要なエージェントの能力 (ケイパビリティ) がいくつかあります。たとえば、環境間でセッションを移動するためのセッションパッケージングや、ローカルとクラウドの両方のセッションをどのクライアントからも制御できる機能などです。統一されたハーネスなら、新しい能力を一度作るだけで済みます。多くの場合、グローバルフックやポリシープリセットのように、クライアント側の変更ゼロですべてのクライアントに配信できます。統一ハーネスがクライアント側の作業を完全になくしたわけではありませんし、そうしたいわけでもありませんでした。ターミナル、デスクトップの IDE、ブラウザー、スマートフォンは異なるインタラクションモデルを持っており、私たちは画一的な体験を提供するのではなく、各クライアントがそのフォームファクターに合った体験に感じられることを望んでいます。新しいエージェントハーネスアーキテクチャなら、エージェントのロジックはクライアント全体で同一で、各クライアントチームはそれとどうやり取りするのがベストかに集中できます。 Kiro のユーザーとして、新しいエージェントハーネスアーキテクチャは、新しい能力がより速く届き、一貫した振る舞いを示し、あなたが好むクライアントに関わらず同じ設定で動作することを意味します。 新しい Kiro エージェントハーネスを試す 新しい Kiro エージェントハーネスは 4 つの Kiro クライアントすべてでライブ稼働しているので、今日から試せます。 Kiro IDE 1.0 は、ケイパビリティベースの権限、タグベースツールとインライン MCP を備えたカスタムエージェント、並列セッションを指揮するためのエージェントフォーカスモード、ドッキング可能なチャットタブ、セッションエクスポートを提供します。 IDE 1.0 のドキュメントと移行方法 を参照してください。 Kiro CLI v3 (アーリーアクセス) は、仕様駆動開発、permissions.yaml、拡張されたフック、新しいエージェント設定フォーマットを備え、ターミナルで同じ統一ハーネスを実行します。 kiro-cli --v3 で試せます。 CLI v3 のドキュメントと移行方法 を参照してください。 Web 版 Kiro (プレビュー) はクラウドサンドボックスでハーネスを実行し、ブラウザーで仕様を使った自律的な開発、マルチリポジトリセッション、GitHub と GitLab の統合を提供します。 サインイン / サインアップ できます。 iOS 版 Kiro (プレビュー) は Web 版 Kiro と同じクラウドセッションにスマートフォンから接続し、ラップトップを開かずに自律的な作業のキックオフ、差分のレビュー、変更の承認を行えます。 アーリーアクセスをリクエスト してください。 翻訳は Solutions Architect の吉村が担当いたしました。

本ブログは 2026 年 8 月 5 日現在の内容を元に記載しております。記載内容については今後変更される可能性があります。 こんにちは ! テクニカルインストラクターの室橋です。AWS 認定に上位・下位関係があることはご存知の方も多いかと思います。しかし、 「具体的にどの認定を更新すると、どの認定が一緒に更新されるのか」 を正確に把握されている方は意外と少ないのではないでしょうか ? 今回は、この上位・下位関係を図とともに整理してお伝えします。 はじめに AWS 認定には Foundational、Associate、Professional、Specialty の 4 カテゴリがありますが、このうち Specialty 以外の 3 カテゴリには明確な上位・下位関係が定義されています。この記事では、その関係を図で整理しつつ、再認定時の活用方法と注意点を解説します。 上位・下位関係の定義されている AWS 認定の 3 つのカテゴリ 上位・下位関係の定義されている AWS 認定は、以下の 3 つのカテゴリに分かれており、上位カテゴリの認定を取得 (または更新) すると、その下位にあたる認定も自動的に更新されます。 Professional (上級): Solutions Architect Professional、DevOps Engineer Professional など、青緑のバッジのもの Associate (中級): Solutions Architect Associate、Developer Associate など、青いバッジのもの Foundational (基礎): Cloud Practitioner、AI Practitioner など、グレーのバッジのもの ※ 上記に加えて、Specialty (専門) という別カテゴリの認定もあります (後述)。 具体的な上位・下位関係は以下の通りです。 Solutions Architect 系 Solutions Architect Professional (上位) └→ Solutions Architect Associate (中位) └→ Cloud Practitioner (下位) DevOps Engineer 系 DevOps Engineer Professional (上位) ├→ CloudOps Engineer Associate (中位) ├→ Developer Associate (中位) └→ SysOps Administrator Associate (中位) └→ Cloud Practitioner (下位) Generative AI Developer 系 Generative AI Developer Professional (上位) ├→ Data Engineer Associate (中位) └→ Machine Learning Engineer Associate (中位) ├→ Cloud Practitioner (下位) └→ AI Practitioner (下位) つまり、例えば Solutions Architect Professional を更新すれば、Solutions Architect Associate と Cloud Practitioner も一緒に更新されることになります。こちらの内容をまとめたものが下図となります。 ただし、注意点があります。上位認定を更新した場合に下位認定も更新されるのは、 その下位認定をすでに取得している場合に限ります。 上位認定を取得・更新したからといって、まだ取得していない下位認定が自動的に付与される (取得されたことになる) わけではありませんのでご注意ください。加えて、 認定が更新されるのは「そのタイミングで有効な認定のみが対象となる」 点も注意が必要です。上位認定を更新した際に、失効状態の下位の認定が後から再度有効になることはありません。下位の認定を有効にしたい場合は再度認定を取得しなおしていただく必要があります。 この仕組みを活用した再認定戦略 複数の認定を持っている場合、上位・下位関係を理解しておくと、効率的に再認定ができます。 例えば: Cloud Practitioner と Solutions Architect Associate を持っている場合 → Solutions Architect Associate を再認定すれば Cloud Practitioner も更新される Associate 複数と Professional を持っている場合 → Professional の再認定をすればその下位に紐づく Associate と Foundational も更新される さらに、 認定に合格すると「次回以降の試験で使える50%オフのバウチャーコード」が特典として付与されます。 再認定の際にはこちらを活用することで、費用を抑えながら継続的にチャレンジいただけます。 再認定の具体的な方法 (試験の再受験、認定更新プログラムなど) については、こちらのブログ記事で詳しく解説しています: →　 AWS 認定の新しい更新方法についてのブログ記事 Specialty は独立している もう一つ押さえておきたい点は、 Specialty (専門) 認定は、ここまででご案内してきた上位・下位関係に含まれない ということです。 つまり、Specialty 認定は他の認定と上位・下位の関係がないため、Professional を更新しても Specialty は更新されませんし、その逆も同様です。Specialty を維持したい場合は、Specialty 自体を個別に再認定する必要があります。 なお、AWS Certified Advanced Networking – Specialty は 2026 年 8 月 25 日をもってリタイア (廃止) となる予定です。リタイア後は新規受験ができなくなりますのでご注意ください。 まとめ 本ブログをまとめると下記の内容となります。 AWS 認定には Professional、Associate、Foundational、Specialty の 4 カテゴリがある その中の 3 つのカテゴリには Professional → Associate → Foundational という上位・下位関係がある 上位の認定を更新すると、取得している有効な下位の認定も自動的に更新される 複数認定を持っている場合は、上位・下位関係を活用して効率的に再認定が可能 Specialty 認定はこの上位・下位関係に含まれない (独立して再認定が必要) ぜひこの上位・下位関係をうまく活用して、効率的な再認定計画を立ててみてください。皆さまの継続的なスキルアップを応援しています ! 著者について 室橋 弘和 (Hirokazu Murohashi) AWS トレーニングサービス本部 Technical Instructor 兼 Customer Success Manager Cloud Quest とデカ盛りのお店巡りをこよなく愛するマン。老眼鏡が必要になってきました。

本ブログは dSPACE Japan 様と アマゾン ウェブ サービス ジャパン合同会社が共同で執筆いたしました。 1. はじめに 自動車分野で行われている自動運転技術の開発では、データ駆動型アプローチの重要度が高まっています。膨大な実走行データを体系的に整備・活用することで多様な運転環境への対応が可能になり、モデルの汎化性能と信頼性を継続的に向上させることができます。 しかし、自動運転システムが生成するデータ量は膨大であり、その管理と活用には大きな課題が伴います。データ収集から学習、検証、デプロイ、モニタリングまでを統合管理する「MLOps」の導入が不可欠です。 本記事では、30 年以上にわたり車両開発ツールを提供してきた dSPACE 社の製品と、AWS クラウドサービスを統合した MLOps ソリューションをご紹介します。 2. 自動運転開発における課題 自動運転技術の進展に伴い、AI を活用した認識・判断アルゴリズムの高度化が急速に進んでいます。一方で、実際の車両開発・量産適用を見据えると、単なるモデル精度の向上だけでは解決できない、複合的な課題に直面されているのではないでしょうか。 膨大かつ多様なセンサーデータの管理と活用 先進的な自動運転システムでは、1 時間あたり 1 テラバイトを超えるカメラデータに加え、LiDAR、Radar、GPS など多種多様なセンサーデータが生成されます。これらのデータは地理的にも分散して収集されることが多く、効率的な保存・検索、シナリオや条件に基づくデータ抽出、開発・検証フェーズ間での一貫したデータ利用を実現することが大きな課題となっています。 学習精度と車両環境での挙動の乖離 クラウド環境で学習した AI モデルが高い認識精度を示していても、リアルタイム実行制約、センサー同期誤差やノイズ、車載ハードウェア上での実行条件といった要因により、実車両環境では期待通りに動作しないケースが少なくありません。このため、学習結果をそのまま車両に適用するのではなく、車両環境を考慮した検証・評価プロセスを MLOps と連携させることが不可欠となります。 検証と学習の分断による改善サイクルの停滞 自動運転の安全性は、まれなエッジケースや特定シナリオへの対応によって大きく左右されます。しかし多くの開発現場では、クラウドを中心とした AI 開発・MLOps チームと、SIL (Software-in-the-Loop)／HIL (Hardware-in-the-Loop)／実車評価を担う車両開発チームが、異なるツールやプロセスで作業しています。この分断により、どのシナリオで性能低下が発生したのか、その原因となるデータをどのように再学習へ反映させるのかといった情報がチーム間で共有されず、検証結果を効率的に再学習へフィードバックする仕組みが整っていないケースが多く見られます。検証結果と学習データを結び付け、継続的な改善サイクルを回すことが大きな課題です。 再現性・説明責任の確保と検証コストの増大 自動運転 AI の開発では、使用したデータ、学習条件、モデル構成、検証環境を後から正確に説明・再現できることが求められます。しかし、実験管理、検証条件、車両構成情報が個別に管理されることで、結果の再現性やトレーサビリティの確保が困難になり、社内レビューや将来的な認証・法規対応を見据えた際に重大なリスクとなります。さらに、データ駆動型開発ではモデル更新が頻繁に行われるため、そのたびに同等レベルの検証を実施することは大きな負担となります。すべてを再検証するのではなく、モデル変更の影響範囲を見極め、効率的に検証を行う仕組みが必要とされています。 これらの課題を解決するためには、クラウド MLOps のスケーラビリティと、車両開発・検証を熟知したツールチェーンを統合し、データ収集から学習、検証、デプロイ、モニタリングまでを一貫して管理できる基盤が求められます。次章では、こうした課題に対応する dSPACE と AWS による統合 MLOps ソリューションについて詳しく説明します。 3. ソリューション： dSPACE と AWS による自動運転向け統合 MLOps アーキテクチャ 自動運転 AI 開発における効率化を実現するため、dSPACE と AWS はそれぞれの強みを活かし、AI モデルの学習から SIL/HIL での検証、さらに実運用を見据えた評価・改善までをつなぐ統合 MLOps 環境を共同で提供します。本ソリューションでは、データ駆動開発（DDD）で扱うデータ収集・整備・検証の流れ（左側）と、MLOps で扱う学習・追跡・デプロイの流れ（右側）を接続します。これにより、学習と検証が分断されがちな自動運転 AI 開発において、改善サイクルを一貫したパイプラインとして回すことを目指します。 本アーキテクチャの特徴は、dSPACE 製品と AWS サービスがシームレスに連携できる点にあります。 図1: AWS サービスと dSPACE 製品の統合アーキテクチャ Data Collection：後工程で“使える形”を前提にしたデータ収集 本パイプラインの起点は、走行試験、評価ベンチ、シミュレーションなど多様なソースから得られるデータの収集です。自動運転開発ではデータ量の多さだけでなく、どの条件・どのシナリオで取得されたかが重要となるため、後工程での検索・抽出・学習・検証に耐えうる形で蓄積することが求められます。 この Data Collection フェーズでは、 RTMaps を活用することで、カメラ、Radar、LiDAR など複数センサのデータをリアルタイムに扱いながら、システム全体としての振る舞いを意識したデータ取得が可能となります。さらに、RTMaps を用いたデータ収集は、後続の検証や SIL/HIL を含むシステム統合試験でも同一の処理構成を再利用できるため、データ取得と検証の分断を抑えたパイプライン設計につながります。こうして収集されたデータは、次の Data Preparation フェーズにおいて IVS に引き渡され、タグ付けや検索、データセット化といった処理へとスムーズに接続されます。 Data Preparation：IVS によるデータマネジメントとデータセット管理 収集したデータは、学習にそのまま利用できるとは限りません。Data Preparation フェーズでは、 dSPACE IVS (Intempora Validation Suite) を用いて、データの自動タグ付け、検索、変換を行い、学習に適したデータセットとして整理します。 重要なのは、単にデータを整えるだけでなく、どの条件で抽出・加工されたデータセットなのかを後から辿れることです。本パイプラインでは、IVS を介してデータセット定義と証跡（トレーサビリティ）を管理し、以降の学習・検証フェーズと一貫して結び付けます。 Training：AWS を活用した学習の自動化と実験・モデル管理 整備されたデータセットは、AWS のクラウドサービスへシームレスに受け渡され、大規模な学習処理が実行されます。本構成では、 Amazon SageMaker AI を中心とした学習基盤を活用し、必要な計算リソースを柔軟に利用することで、効率的なモデル学習を実現します。 SageMaker Training Jobs は、学習ジョブごとに GPU インスタンスを自動的にプロビジョニングするため、高価な GPU リソースを学習実行時のみ使用でき、コスト効率に優れています。また、学習コードをコンテナイメージとして Amazon ECR に格納し、学習データを Amazon S3 に配置するアーキテクチャにより、「コード・データ・環境」の三要素が分離され、実験の再現性が担保されます。さらに、実験管理には SageMaker AI のマネージド MLflow を用い、学習条件、評価指標、生成されたモデルを一元的に管理します。これにより、モデルの品質担保に必要な履歴情報を体系的に蓄積し、後工程の検証や将来の説明責任に対応します。 Validation / System Integration &amp; Testing（SIL/HIL）：学習成果を車両開発レベルで検証し、信頼性を高める 学習によって得られた AI モデルは、SIL や HIL を活用して、自動運転システムとしての機能検証や統合試験へと進みます。 dSPACE の SIL/HIL ソリューション は、制御ソフトウェアや AI モデルを実車に近い条件で段階的に評価できる点が特長です。SIL では、アルゴリズムやソフトウェアの論理的な正しさや機能挙動を早期に確認でき、モデル更新による影響を効率的に洗い出すことができます。さらに HIL では、実際の ECU (Electronic Control Unit) として AI モデルを接続することで、リアルタイム性やインタフェース、システム全体としての振る舞いを含めた検証が可能となります。 検証フェーズで得られた結果は、データ条件やモデル情報とひも付けて管理され、Data Preparation フェーズへフィードバックされます。これにより、SIL/HIL で顕在化した課題を起点に学習データセットを見直し、再学習へつなげるといった、検証起点の改善サイクルを回すことが可能となります。結果として、モデル開発と車両開発・検証を分断することなく、品質向上と開発効率化の両立を支援します。 4. 開発環境「Kiro」を活用した開発効率化 MLOps 開発プロセスをさらに効率化するためには、AWS が提供する開発環境「 Kiro 」を利用することが考えられます。 Kiro は Spec 駆動開発を特徴とし、要件定義・設計・実装タスクを構造化されたドキュメントとして管理しながら、エージェント機能によるコード生成を行うことで、開発者が本質的なアルゴリズム設計に集中できる環境を提供します (図 2 参照)。 図 2: Kiro による MLOps 開発ワークフローの効率化 ここでは、MLOps 開発において Kiro がどのように活用できるか、いくつかの例をご紹介します。 ハイパーパラメータ最適化スクリプトの生成 エージェント機能に最適化要件を伝えることで、2 フェーズアプローチの最適化スクリプトを生成できます。Phase 1 (粗探索) でパラメータ範囲を広く設定し、ランダムに 20 組をサンプリングして並列・短時間で完了させ、Phase 2 (細探索) で Phase 1 の結果を基に最良パラメータ周辺を詳細に探索するといった、重要なパラメータを体系的に調整するスクリプトの生成が可能です。 学習データ品質チェックの自動化 学習データの品質チェックスクリプトの生成にも活用できます。データセット構造チェックでは必要なディレクトリ構成や設定ファイルを検証し、PIL (Python Imaging Library) を使った画像破損チェック、YOLO フォーマットのラベル形式検証、画像-ラベル対応関係チェックにより、不整合を検出します。破損画像や不正確なアノテーションを学習前に自動検出することで、無駄な学習実行を防止できます。 このほか、train.py や Dockerfile などのボイラープレートコード生成、SageMaker ジョブ投入スクリプトの雛形作成など、MLOps 開発における定型的な作業にも Kiro を活用することで、開発者が本質的なアルゴリズム設計に集中でき、開発サイクルの短縮が期待できます。 5. まとめ 本記事では、自動運転 AI 開発における課題と、dSPACE と AWS による統合 MLOps ソリューションをご紹介しました。RTMaps と IVS によるデータ収集・整備から、Amazon SageMaker AI と MLflow を活用した学習・実験管理、さらに SIL/HIL による車両レベルでの検証までを一貫したパイプラインとして接続することで、学習と検証の分断を解消し、検証起点の改善サイクルを回すことが可能となります。加えて、開発環境「Kiro」を活用することで、ハイパーパラメータ最適化やデータ品質チェックといった定型作業を自動化し、エンジニアが本質的なアルゴリズム設計に集中できる環境を実現します。 自動運転 AI 開発の効率化や継続的改善を検討されている方にとって、本記事がソリューション選定の一助となれば幸いです。ご質問やご相談は、dSPACE および AWS の担当者までお気軽にお問い合わせください。 著者について 丹羽 伸二 AWS Japan のシニアソリューションアーキテクトとして自動車業界のお客様を担当。自動車業界で15年以上の経験を持ち、主にプロダクトエンジニアリング領域におけるモダナイゼーションや AI 活用の取り組みを支援しています。 村山 哲也 dSPACE Japan 株式会社 CX 技術部 Business Prototyping グループリーダー。データドリブン開発や開発環境のプラットフォーム化などのクラウド系ソリューション、および自動車開発に関わる AI 活用に関するプロトタイピング活動とエンジニアリングをリードしています。 宮本 敬丈 dSPACE Japan 株式会社 CX 技術部 Business Prototyping グループ AI チームリーダー。データサイエンティストとして、製造業、自動車領域における AI 活用、MLOps 基盤構築、エンジニアリングプロセスの自動化に従事。AWSを含むクラウドアーキテクチャの構想や生成 AI、RAG、MCP を活用した業務高度化に取り組んでいます。 &nbsp;

大阪開催の経緯 みなさん、こんにちは。AWS アカウントマネージャーの岩上です。 2026年7月2日、AWS 大阪オフィスにて 「Claude , Kiro実践ワークショップ」 を開催しました。参加者35社62名、満足以上の回答率98% という結果を頂きました。 本ワークショップの基本的なプログラム構成や背景については、先行して公開している 麻布台オフィス開催のブログ記事 をご参照ください。本記事では大阪開催の特徴であるOSPホールディングス様のユーザー登壇にフォーカスしてお伝えします。 OSPホールディングス様のユーザー事例登壇 大阪開催では新たな試みとして、ワークショップ参加企業である OSPホールディングス様 に事例登壇いただきました。IT企画課の桒原様が15分間、自社での取り組みと成果を共有してくださいました。 登壇の背景 OSPホールディングス様は、4月にアカウントチームで実施したAIコーディングワークショップをきっかけに、Kiroの全社活用に向けた取り組みを開始されました。わずか 3ヶ月で30名規模の利用体制を構築 されています。 特筆すべきは、IT企画課の桒原様が 自ら社内勉強会を企画・実施し、継続的にアクティブユーザーを増やしていく動き をされている点です。ワークショップをきっかけにお客様自身が推進役となり、組織を動かしていく — まさに理想的な展開です。 登壇内容のハイライト &nbsp; 　生産性向上の実績 (Before→After/効率化倍率) 　・メールアーカイブ作業(514時間→3時間/171倍） 　・会計データの見える化（半年→3日/60倍) 　・受注分析（1週間→3時間/57倍) 　推進のポイント 　・ワークショップ参加（10名）→ 社内勉強会（30名）→ 実務伴走と段階的にスケール 　・ゲーム開発を題材に若手〜ベテランまで楽しく体験 　・4テーマ×計8回の推進リーダーによる伴走支援で実務定着 なぜユーザー登壇が効果的だったのか アンケートでも好評だったように、 実際に推進されたお客様の生の声は説得力が違います。 参加者にとって「自社でもできるかもしれない」という実感につながり、ワークショップ本編のハンズオンに対するモチベーションも高まりました。 OSPホールディングス様は今後、一般業務部門展開 → PoC拡大 → 全社展開へと進んでいかれます。 アプリ発表事例 大阪開催でもハンズオン後に参加者がアプリ発表を行いました。代表的な発表を紹介します。 在宅勤務管理アプリ ：在宅している人が分かりにくいという課題を解決。上司向けにカレンダーや上限チェックのタブを設置 市場・技術動向ニュース配信アプリ ：丸一日かかりそうな調査が5分程度で完了する所感。リンクもクリックして遷移可能 交通費経費精算自動化アプリ ：モバイルICOCAの履歴データをアップロード → 文字読み取り → 精算書PDF保存 マラソン練習メニュー提案アプリ ：レースの種類・目標タイム等を入力するとランニングコースを提案。Google Map連携やシューズDBへの接続まで実装 旅行ルート比較アプリ ：距離やマイルなどかなり正確な結果。指示していないプレミアポイント表示もKiroが自動実装 サカイ引越センター　経営企画部　森田様の旅行ルート比較アプリの発表 大阪開催ならではの工夫 大阪開催ではワークショップ終了後に ピザ懇親会 を実施しました。 Amazonには「2 Pizza Rule（2枚のピザで足りる人数＝6〜8名がチームの理想サイズ）」という考え方があります。小さなチームだからこそ迅速に意思決定でき、オーナーシップを持って動ける — この考え方はAIコーディングツールの社内展開にもそのまま当てはまります。 懇親会ではまさに2枚のピザを囲む規模感のテーブルで、参加者同士が「うちの会社ではこう使い始めた」「こういう課題にぶつかった」という率直な会話を交わしていました。ワークショップ本編では聞けなかった各社の生の悩みや工夫が共有され、 企業の垣根を超えた横のつながりが生まれる場 となりました。 OSPホールディングスの桒原様も「登壇資料を見せてほしい」と声をかけられる場面があり、ユーザー事例登壇と懇親会のセットが参加者間のナレッジシェアを加速させる効果を実感しました。 まとめ 大阪開催では、ユ ーザー事例登壇 という新しい要素を加えることで、単なるツール体験に留まらない 「自社での展開イメージ」 を参加者に提供できました。 OSPホールディングス様のように、ワークショップをきっかけにお客様自身がチャンピオンとなり組織を動かしていく流れは、AIコーディングツールの導入における理想的なモデルです。ツールを配るだけでは組織は変わりません。現場の担当者が「自分ごと」として推進し、成功体験を社内に広げていくことが、継続的な業務変革につながります。 本ワークショップの基本的な設計思想やプログラム構成の詳細については、 麻布台オフィスでの開催記録 をご覧ください。 ワークショップ後の支援 AWS では、ワークショップで「自分でも作れる」と実感いただいた後も、お客様の状況に応じた継続支援をご用意しています。活用方法の共有会、業務課題の深掘り、セキュリティ面の技術説明など、次のステップについては担当のアカウントマネージャーまでお気軽にご相談ください。 本記事公開時点では、当該ワークショップは招待制のイベントとなります。AWS側の担当者がお客様の状況を鑑みてご案内差し上げておりますので、予めご了承ください 。 関連リンク Claude Desktop セットアップガイド（Zenn） Kiro IDE セットアップガイド（Zenn）

本記事は 2026 年 7 月 20 日 に公開された「 Connection pooling strategies in Amazon Aurora DSQL 」を翻訳したものです。 本記事では、Aurora DSQL の接続負荷を減らし、1 秒あたり 100 接続のレート制限を超えず、再接続が一斉に集中する thundering herd を避けるための、具体的な 4 つの戦略を解説します。読み終える頃には、大規模でも安定した性能を発揮する接続プールを構成するための、本番運用に使えるチェックリストが手に入ります。 接続プーリングの戦略次第で、 Amazon Aurora DSQL アプリケーションが安定してスケールするか、負荷で破綻するかが決まります。Amazon Aurora DSQL 独自のアーキテクチャは、接続プーリングの効果をさらに大きくします。トランザクション単位の多重化と AWS Identity and Access Management (IAM) による認証により、Aurora DSQL では適切なプーリング戦略が、従来の PostgreSQL の接続管理では実現できない形で性能を高めます。 注: 本記事は、PostgreSQL の接続管理の概念と基本的な IAM 認証を理解していることを前提としています。Amazon Aurora DSQL を初めて使う場合は、これらの戦略を適用する前に、まず Getting Started ガイド から始めてください。 サーバーレス環境での接続プーリング Amazon Aurora DSQL は運用の複雑さを自動的に処理しますが、それでも接続プーリングは欠かせません。新しい接続のたびに、コストの高い TLS ハンドシェイクと認証情報の交換が発生します。プーリングは確立済みの接続を再利用し、この負荷を抑えてレイテンシーを削減します。また、トラフィックが急増すると、1 秒あたり 100 接続 (バースト時 1,000) のレート制限に達することがあり、既存の接続を再利用すればサービスの制限内に安全に収まります。さらに、Amazon Aurora DSQL には接続の最大有効期間があり、クライアントは 1 時間で切断されます。適切に構成したプールはこの制限に達する前に接続をリサイクルし、セッションを透過的に維持します。 トランザクション単位のプーリング: アーキテクチャに組み込み済み Amazon Aurora DSQL はトランザクションプーリングモデルを採用しています。接続を Query Processor に割り当てるのは、セッション全体ではなくトランザクションの実行中だけです。標準的な PostgreSQL では、接続はバックエンドのサーバープロセスと 1:1 のセッション関係を持続的に維持します。一方 Amazon Aurora DSQL はこの対応関係を切り離すため、少数の Query Processor ではるかに多くの接続を処理できます。 この設計は、接続の使用率が低いこと、つまりほとんどの接続が大半の時間アイドル状態であることを前提としています。使用率が低いほど、接続プールに必要な Query Processor は少なくて済みます。そのため、PgBouncer や pgpool-II のようなデータベース側のプロキシは使うべきではありません。トランザクション単位の接続多重化がデフォルトで組み込まれているため、これらのツールはサービスの接続アーキテクチャと重複します。 さらに、一部の PostgreSQL 機能はサポートされていません。SQL レベルの PREPARE/DEALLOCATE ステートメント (ただし拡張クエリプロトコル経由のプリペアドステートメントは正常に動作します)、WITH HOLD カーソル、セッションレベルのアドバイザリーロックです。 Amazon Aurora DSQL の 4 つの接続プーリング戦略 以下の 4 つの戦略は、それぞれ Amazon Aurora DSQL の接続管理の特定の側面に対応します。組み合わせて適用すれば、アプリケーションがサービスの制限内に収まり、負荷がかかっても安定した性能を保てます。新しいアプリケーションを構築する場合は戦略 1 から始め、既存の PostgreSQL アプリケーションを移行する場合はチェックリストとして活用してください。 戦略 1: 公式の AWS コネクタを使う 公式の Amazon Aurora DSQL コネクタ の利用をお勧めします。トークンの生成、有効期間の 80% でのキャッシュ、透過的な更新など、IAM トークンのライフサイクル全体を自動的に処理します。 表 1: プログラミング言語別の推奨接続プールライブラリと主要な設定パラメータ 言語 プーリングライブラリ 主要な設定 Java HikariCP maximumPoolSize Python psycopg ConnectionPool min_size Node.js node-postgres (pg.Pool) max Go pgxpool MaxConns Java (HikariCP) — Spring Boot、Quarkus、Micronaut のアプリケーションでは HikariCP を使います。 HikariConfig config = new HikariConfig(); config.setJdbcUrl("jdbc:postgresql://&lt;cluster-endpoint&gt;:5432/&lt;db&gt;?ssl=true&amp;sslmode=verify-full&amp;sslrootcert=&lt;path&gt;"); config.setMaximumPoolSize(20); config.setMaxLifetime(55 * 60 * 1000); // 55 minutes config.setIdleTimeout(10 * 60 * 1000); // 10 minutes config.setConnectionTimeout(30 * 1000); // 30 seconds config.setKeepaliveTime(5 * 60 * 1000); // 5 minutes HikariDataSource ds = new HikariDataSource(config); Python (psycopg ConnectionPool) — Django、Flask、FastAPI のアプリケーションでは psycopg ConnectionPool を使います。 from psycopg_pool import ConnectionPool pool = ConnectionPool( conninfo="host=&lt;endpoint&gt; dbname=&lt;db&gt; sslmode=verify-full", min_size=2, max_size=20, max_lifetime=55 * 60, # 55 minutes in seconds max_idle=10 * 60, # 10 minutes idle timeout reconnect_timeout=30, # 30 seconds to reconnect ) Node.js (node-postgres) — Express.js、NestJS、サーバーレスの Node.js 関数では node-postgres の Pool を使います。 const { Pool } = require("pg"); const pool = new Pool({ host: "&lt;cluster-endpoint&gt;", database: "&lt;db&gt;", ssl: { rejectUnauthorized: true }, max: 20, idleTimeoutMillis: 10 * 60 * 1000, // 10 minutes connectionTimeoutMillis: 30 * 1000, // 30 seconds }); Go (pgxpool) — Gin、Echo、AWS Lambda Go ランタイムで構築する Go アプリケーションでは pgxpool を使います。 connStr := "host=&lt;cluster-endpoint&gt; dbname=&lt;db&gt; sslmode=verify-full" config, _ := pgxpool.ParseConfig(connStr) config.MaxConns = 20 config.MinConns = 2 config.MaxConnLifetime = 55 * time.Minute // 55 minutes config.MaxConnIdleTime = 10 * time.Minute // 10 minutes idle pool, _ := pgxpool.NewWithConfig(ctx, config) AWS Lambda: プールはハンドラーの外でインスタンス化する AWS Lambda は Aurora DSQL のワークロードでよく使われるコンピューティングサービスです。Lambda の実行モデルには特有のプーリングパターンが必要です。接続プールをモジュールスコープ (ハンドラー関数の外) で作成し、同じ実行環境のウォーム呼び出し間で保持されるようにします。 Lambda が実行環境を再利用すると、モジュールスコープで作成したプールはアクティブなまま残ります。以降の呼び出しでは TLS ハンドシェイクと IAM トークンの交換を完全にスキップできます。コールドスタート時にはプールが一度だけ初期化され、その環境が存続する間は再利用されます。 同時に実行される各 Lambda 呼び出しはそれぞれ独立した実行環境で動くため、プールも個別に持ちます。多数の同時実行にわたって接続を過剰に確保しないよう、プールサイズは小さく (Lambda インスタンスあたり 1〜3 接続) 保ってください。 Lambda の主なガイドライン: プールはハンドラーの外でインスタンス化する。これが最も重要なルールです。 最大プールサイズを 1〜3 に設定する。各 Lambda インスタンスは (バッファ呼び出しを使わない限り) 一度に 1 リクエストしか処理しないため、大きなプールは無駄になります。 アイドルタイムアウトを設定しない。接続は実行環境が存続する間ずっと維持させます。 Lambda 以外のワークロードと同様に、1 時間のハード制限に達しないよう、最大有効期間を 55 分にしてジッターを加える。 コールドスタートのレイテンシーを考慮する。最初の呼び出しでは TLS と IAM 認証の負荷が発生します。以降のウォーム呼び出しではプールされた接続を再利用します。 Python (psycopg ConnectionPool) — Lambda # pool is created ONCE at module scope, reused across warm invocations from psycopg_pool import ConnectionPool import boto3 pool = ConnectionPool( conninfo="host=&lt;cluster-endpoint&gt; dbname=&lt;db&gt; sslmode=verify-full", min_size=1, max_size=2, max_lifetime=55 * 60, # 55 minutes reconnect_timeout=30, ) def handler(event, context): """Lambda handler — pool is already initialized.""" with pool.connection() as conn: result = conn.execute("SELECT * FROM orders WHERE id = %s", [event["order_id"]]) return result.fetchone() Node.js (node-postgres) — Lambda // Pool is created ONCE at module scope, reused across warm invocations const { Pool } = require("pg"); const pool = new Pool({ host: "&lt;cluster-endpoint&gt;", database: "&lt;db&gt;", ssl: { rejectUnauthorized: true }, max: 2, // small pool per Lambda instance idleTimeoutMillis: 0, // don't close idle connections connectionTimeoutMillis: 30 * 1000, // 30 seconds }); exports.handler = async (event) =&gt; { // Pool is already warm on subsequent invocations const client = await pool.connect(); try { const result = await client.query("SELECT * FROM orders WHERE id = $1", [event.orderId]); return result.rows[0]; } finally { client.release(); } }; Go (pgxpool) — Lambda package main import ( "context" "time" "github.com/aws/aws-lambda-go/lambda" "github.com/jackc/pgx/v5/pgxpool" ) // Pool created at package scope — initialized once per execution environment var pool *pgxpool.Pool func init() { connStr := "host=&lt;cluster-endpoint&gt; dbname=&lt;db&gt; sslmode=verify-full" config, _ := pgxpool.ParseConfig(connStr) config.MaxConns = 2 config.MinConns = 1 config.MaxConnLifetime = 55 * time.Minute config.MaxConnLifetimeJitter = 5 * time.Minute pool, _ = pgxpool.NewWithConfig(context.Background(), config) } func handler(ctx context.Context, event map[string]string) (string, error) { row := pool.QueryRow(ctx, "SELECT name FROM orders WHERE id = $1", event["order_id"]) var name string err := row.Scan(&amp;name) return name, err } func main() { lambda.Start(handler) } ヒント: Lambda 関数の同時実行数が多い場合 (数百の同時実行)、各実行環境がそれぞれプールを作成します。最大プールサイズ 2 で 500 の Lambda が同時実行されると、Aurora DSQL への接続は最大 1,000 になり得ます。接続の総数を監視し、クラスターあたり 10,000 同時接続のクォータ内に収めてください。 重要: クライアント接続には sslmode=verify-full を設定し、証明書を完全に検証して経路上の攻撃 (on-path attack) を防ぎます。Aurora DSQL は verify-ca や require といった弱いモードでも接続を受け付けますが、これらはサーバーの正当性を検証しません。 安定した接続プールを維持するには、IAM トークンのライフサイクルの理解が重要です。 新しい接続ごとに、新しい IAM 認証トークンを生成します。トークンの生成はローカルでの署名操作で、負荷はごくわずかです。公式の AWS コネクタはこれを自動的に処理します。独自のプールを使う場合は、トークンを手動でキャッシュするのではなく、接続ファクトリの beforeConnect フックで generate-db-connect-auth-token コマンドを呼び出してください。 トークンは、基となる IAM 認証情報より長くは有効になりません。1 時間のセッションでロールを引き受けた場合、 --expires-in の値に関係なく、トークンは最大でも 1 時間で失効します。 データベースロールは最小権限に絞る。 IAM 認証は誰が接続できるかを制御しますが、接続後にそのセッションが何をできるかは制限しません。各アプリケーションのデータベースロールには、必要な最小限の権限だけを付与します。たとえば、読み取り専用のサービスには SELECT を付与し、書き込みアクセスは特定のスキーマやテーブルに限定します。アプリケーションの接続プールで管理者ロールを使うのは避けてください。 手順の詳細は、 Authorizing database roles to use SQL in your database を参照してください。 戦略 2: 最大接続有効期間にジッターを設定して接続の失効を防ぐ Amazon Aurora DSQL には、1 時間という接続の最大有効期間のハード制限があります。接続がこの期間に達すると、アイドル中でもトランザクションの途中でも、サービスはその接続を閉じます。プールはそうなる前に接続をリサイクルする必要があります。 ジッターが重要な理由: プール内のほとんどの接続がほぼ同じタイミング (たとえばアプリケーションの起動時) に作成された場合、それらはほぼ同時に失効します。すると新しい接続リクエストが一斉に集中する「thundering herd」が発生し、1 秒あたり 100 接続のレート制限を超えることがあります。最大有効期間にランダムなジッターを加えると、接続のリサイクルが時間的に分散されます。 // Go (pgxpool) — Use native per-connection jitter config.MaxConnLifetime = 55 * time.Minute config.MaxConnLifetimeJitter = 5 * time.Minute // Each connection independently gets a lifetime between 55-60 minutes // Java (HikariCP): maxLifetime already applies per-connection jitter automatically // Python: use max_lifetime with a randomized offset in your pool factory 期待される結果: 接続のリサイクルが個々の接続にわたって時間的に均等に分散し、新しい接続リクエストが 1 秒あたり 100 のレートクォータを十分に下回った状態を保てます。 戦略 3: プールサイズを最適化する Amazon Aurora DSQL は多数の同時接続でも高い性能を発揮しますが、スループット、レイテンシー、リソース消費のバランスをとれるようにプールサイズを設定する必要があります。 表 3: 接続プールのサイズ設定パラメータの推奨初期値 パラメータ 推奨初期値 理由 最小プールサイズ 2〜5 接続 低負荷時にリソースを無駄にせず、プールをウォームに保つ 最大プールサイズ アプリケーションインスタンスあたり 10〜20 控えめに始める。アプリケーションインスタンスを追加してスケールアウトする 接続タイムアウト 30 秒 トラフィックが多いイベント中に、DSQL の接続バーストキュー (100/秒) を消化できるようにする アイドルタイムアウト 無効 (または MaxConnLifetime に合わせる) アイドル接続にコストはかからない。開いたままにしておけば、再接続時の不要な TLS/認証の負荷を避けられる Amazon CloudWatch で DPU (Distributed Processing Unit) の消費を監視し、容量の追加が必要なタイミングを把握します。トラフィックの急増が予想される場合 (スケジュールされたバッチジョブやマーケティングキャンペーンなど) は、事前にプールをウォームアップしておきます。インスタンスあたりの接続数を増やすのではなく、小さめのプールを持つアプリケーションインスタンスを増やして水平方向にスケールアウトします。Amazon Aurora DSQL は、短期的な負荷増加には垂直スケーリングで、長期的な変動にはフリート全体の水平スケーリングで対応します。クラスターあたり 10,000 同時接続のクォータを活用し、必要であれば AWS Support に連絡して上限を引き上げてください。 期待される結果: ワークロードに合わせてプールが適切にサイズ設定され、接続の負荷とプール枯渇エラーの両方を最小限に抑えられます。 戦略 4: マルチリージョンでのプーリングの考慮事項 Amazon Aurora DSQL のマルチリージョン active-active デプロイを使うグローバル分散アプリケーションでは、接続プーリングにもう一段の検討が必要です。 このサービスのマルチリージョンアーキテクチャでは、SQL の実行、読み取り、書き込みのスプーリングをクライアントのリージョン内でローカルに処理します。リージョン間の通信は、コミット時に Adjudicator と Journal のレプリケーションプロトコルを通じてのみ発生します。マルチリージョンモードでも読み取りはローカルなので、読み取り専用トランザクションはリージョン間のレイテンシーなしで完了します。読み書きトランザクションでリージョン間レイテンシーが発生するのは COMMIT 時のみで、実行した SQL ステートメントの数に関係なく、リージョン間のラウンドトリップ約 1〜1.5 回分です。各ステートメントごとにラウンドトリップが発生する転送ベースの設計と比べ、レイテンシーを削減できます。リージョンの選択も重要です。接続性の良いリージョンの組み合わせほどコミットレイテンシーが低く、地理的に離れた組み合わせほどそれに比例して大きくなります。 マルチリージョンでのプーリングでは、リージョンごとに個別の接続プールを作成し、それぞれローカルの Amazon Aurora DSQL エンドポイントを指すようにします。トークン更新のロジックがリージョンごとの IAM エンドポイントを考慮していることを確認してください。アプリケーションは active-active アクセスを前提に設計します。このサービスにはプライマリリージョンという概念がなく、各リージョンは対称的に動作します。 期待される結果: リージョン間レイテンシーはコミット時にのみ発生し、読み取りはローカルリージョンの速度で完了します。 オブザーバビリティ: データベースだけでなく接続プールも監視する Aurora DSQL の CloudWatch メトリクス (TotalTransactions や CommitLatency など) はデータベースレベルの挙動を示しますが、接続プールがボトルネックかどうかまではわかりません。プールの健全性を把握するには、アプリケーション側に計測を組み込む必要があります。次に挙げるクライアント側のメトリクスが、接続プーリングの問題を捉える重要なシグナルです。 アプリケーションに組み込むべきメトリクス メトリクス 示す内容 アラートのしきい値 発生時のアクション プール取得レイテンシー (.get() の所要時間) プールから接続を取得するまでアプリケーションが待つ時間 P95 &gt; 500 ms プールが飽和している。最大プールサイズを増やすか、アプリケーションインスタンスをスケールアウトする アクティブ接続数 現在トランザクションを実行中の接続数 最大プールサイズに張り付いている すべての接続が使用中。プールサイズを増やすか、トランザクションの実行時間を短くする アイドル接続数 プール内で使われていない接続の数 0 のまま張り付いている トラフィックのバーストに対する余裕がない。最小プールサイズを増やすか、急増が予想される前にウォームアップする リクエストの同時実行数 対 プールサイズ 処理中の同時リクエスト数と最大プールサイズの比率 同時実行数が最大プールサイズの 80% を超える プール枯渇に近づいている。スケールアウトするか、プールサイズを増やす プール枯渇イベント 利用可能な接続を待って接続リクエストがタイムアウトした回数 &gt; 0 直ちに対応が必要。プールサイズを増やす、トランザクションの実行時間を短くする、またはアプリケーションインスタンスを追加する 接続作成レート プールが 1 秒あたりに開く新規接続の数 100/秒 に近づく Aurora DSQL のレート制限に達するリスクがある。ジッターを加える、インスタンスの起動をずらす、または最小プールサイズを増やして接続の入れ替わりを減らす ほとんどの接続プールライブラリは、これらの統計をネイティブに公開しています。 Java (HikariCP): HikariPoolMXBean を使って getActiveConnections() 、 getIdleConnections() 、 getThreadsAwaitingConnection() 、 getTotalConnections() にアクセスします。Micrometer 経由で CloudWatch やアプリケーションパフォーマンスモニタリング (APM) ツールにエクスポートします。 Python (psycopg ConnectionPool): pool.get_stats() を使います。 pool_min 、 pool_max 、 pool_size 、 pool_available 、 requests_waiting 、 requests_num を返します。 Node.js (node-postgres): pool.totalCount 、 pool.idleCount 、 pool.waitingCount に直接アクセスします。一定間隔で、またはリクエストごとに出力します。 Go (pgxpool): pool.Stat() を使います。 AcquireCount() 、 AcquiredConns() 、 IdleConns() 、 TotalConns() 、 AcquireDuration() を提供します。 これらはカスタム CloudWatch メトリクスとして発行するか ( PutMetricData API またはログ内の CloudWatch Embedded Metric Format を使用)、既存の APM ツール (AWS X-Ray、Datadog、Prometheus/Grafana など) に送信します。 補足: Aurora DSQL の CloudWatch メトリクス 主要なシグナルはクライアント側のメトリクスであるべきですが、プールサイズを決めるうえで役立つ Aurora DSQL のメトリクスが 1 つあります。 メトリクス プーリングに役立つ理由 TotalTransactions プール取得レイテンシーと関連付けて見ます。トランザクションが増えているのに取得レイテンシーが横ばいなら、プールサイズは適切です。両方が増えているなら、容量の追加が必要です。 よくある接続プールの問題のトラブルシューティング アラートが発生したら、この表を使って最もよくある障害シナリオを診断し、対処してください。 表 5: よくある Amazon Aurora DSQL 接続プール問題のトラブルシューティングガイド 症状 考えられる原因 診断ステップ 対処 プール枯渇 (接続タイムアウトエラー) トラフィックに対して maxPoolSize が低すぎる アクティブ接続とアイドル接続を比較して監視する 最大プールサイズを増やすか、アプリケーションインスタンスを追加する 約 55 分後の認証失敗 トークンの失効が処理されていない トークン更新のログを確認する 公式コネクタを使っているか確認する。MaxConnLifetime の設定を確認する 新規接続レートのエラー 起動時の thundering herd 接続作成のタイムスタンプを確認する MaxConnLifetime にジッターを加える。アプリケーションインスタンスの起動をずらす クイックリファレンス: 主要な制限と設定 接続の有効期間、トランザクションタイムアウト、接続レート、同時実行数などの最新の制限については、 Cluster quotas and database limits を参照してください。 まとめ 本記事では、Amazon Aurora DSQL のトランザクション単位のプーリングモデルが従来の PostgreSQL とどう違うかを解説しました。また、コネクタの選択からマルチリージョンでのプーリングまで、アプリケーションの性能と回復力を保つための具体的な 4 つの戦略も紹介しました。PgBouncer や pgpool-II のようなデータベース側のプロキシは使わないでください。このサービスはトランザクション単位の多重化をネイティブに処理します。マルチリージョンのデプロイでは、リージョン間レイテンシーがコミット時にのみ発生することを覚えておいてください。トランザクションはローカルの読み書きを活かせるように設計しましょう。 これらの戦略に従えば、アプリケーションは Amazon Aurora DSQL の自動スケーリング、強整合性、高可用性を最大限に活用できます。接続の負荷を最小限に抑え、大規模でもレイテンシーを予測可能に保てます。 著者について Tejas Dubey Tejas は、 Tejas は AWS のテクニカルアカウントマネージャーで、エンタープライズのお客様が回復力とセキュリティに優れ、AI 対応のクラウドアーキテクチャを構築できるよう支援しています。新しいテクノロジーを実際のビジネス価値に変えることに情熱を注いでいます。仕事を離れているときは、息子を追いかけたり、ピックルボールをしたり、最新のテクノロジーをいじったりしています。 Dhvani Shah Dhvani は、 Dhvani はテクニカルアカウントマネージャーで、クラウドの回復力、セキュリティ、生成 AI の導入に関する戦略的なガイダンスでエンタープライズのお客様を支援しています。デジタルトランスフォーメーションを加速する、スケーラブルで安全なソリューションの設計を支援しています。仕事以外では、旅行やバドミントン、家族と過ごす時間を楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Arisa Izuno がレビューしました。

AWS メディア業界向け勉強会 #9（2026 年 7 月 10 日開催） 2026 年 7 月 10 日（金）に、メディア業界のお客様向けに AWS 勉強会を開催いたしました。放送局のお客様にご登壇いただき、 AWS の活用事例についてご紹介いただきました。この記事では、カスタムモデルの生成等を通じてリアルタイム翻訳の精度を向上させた事例や、社内の基幹システムをクラウド移行する際の勘所、AI 会話システムの構築、クラウド編集環境の構築、社内ハッカソンにおける Kiro の活用などのメディア業界におけるクラウド活用事例を知ることができます。登壇者の所属部署および肩書きは登壇当時のものとなります。 鳥人間コンテスト Live 配信におけるリアルタイム英語字幕 読売テレビ放送株式会社 クロステック局 放送DXグループ 福岡 一輝 氏 読売テレビ放送株式会社では、毎年夏に琵琶湖で開催される鳥人間コンテストの公式 YouTube ライブ配信において、海外ファンに向けたリアルタイムの英語字幕付与を昨年から実施しています。エンジニア 1 名がわずか 2 か月で AWS 上にフルマネージドサービスを組み合わせた独自システムを構築し運用を開始しています。 リアルタイム字幕生成の流れは、 Amazon Transcribe による文字起こし、生成 AI サービスによる翻訳、番組専用の校正 AI による後処理の 3 段階で構成されています。Amazon Transcribe ではカスタムボキャブラリーやカスタム言語モデルを活用して認識精度を向上させています。校正処理では、 Amazon SageMaker AI を用いてファインチューニングした番組専用モデルを構築し、 Amazon Bedrock にCustom Model Import 機能を用いてカスタムモデルをデプロイしました。これにより、チーム名や専門用語などの固有名詞の補正や、主語の誤変換などを解決しています。独自モデルの構築にあたっては、Amazon SageMaker AI の JumpStart 機能を活用、過去の 10 時間分の配信音声を全て文字起こしし、正解データを手作業で作成するという学習データ整備も行っています。 映像の処理には Amazon Elastic Container Service（Amazon ECS） を採用し、機能ごとにマルチコンテナ設計とすることでリスク分散を図っています。 AWS Fargate の採用により複雑なインフラ管理が不要となり、開発者がアプリケーションロジックに集中できる環境を実現しています。また、字幕と映像のタイミングを一致させるため、映像をバッファリングして音声処理の遅延を吸収する仕組みを実装し、フロントエンドの UI からも微調整が可能な設計としています。YouTube Live への出力には AWS Elemental MediaLive を使用しています。さらに、 AWS SAM による Infrastructure as Code（IaC）でシステム全体を管理しており、環境の再現やアーキテクチャ情報の把握が容易になっています。配信後には海外視聴者からポジティブなコメントが多数寄せられました。 資料のダウンロードは こちら 社内の基幹システムを AWS に移行してわかった勘所と注意点 株式会社毎日放送 デジタルストラテジー局 副部長 田中 淳史 氏 関西テレビ放送株式会社 DX推進局 DX戦略部 主事 石井 克典 氏 読売テレビ放送株式会社 コーポレート局 情報システムグループ 谷 尚大 氏 読売テレビ放送、関西テレビ放送、毎日放送の 3 社は同一の会計パッケージを AWS 上に導入しています。この共通点を活かしてパネルディスカッション形式にて、基幹システムの AWS 移行における勘所と注意点についてお話しいただきました。放送局の基幹システムがクラウドで安定運用できることを 3 社の実例で示していただいた貴重なセッションです。 移行のきっかけについては、長年稼働してきた会計システムのモダナイズに合わせて自然にクラウドを選択した局がある一方、他局の先行事例や構築ベンダーからの推薦が後押しになった局もありました。共通していたのは、クラウドへの移行に対する社内の抵抗感が以前ほど大きくなかったという点です。 構築においては、 AWS Direct Connect の敷設や社内セキュリティ基準の策定など、初めてのクラウド本格利用ならではの苦労もありました。一方で、従来はハードウェアも含めてベンダーに委ねていた領域を自社で理解し運用する体制へと変化したことで、Savings Plans による長期コミット割引やインスタンスの稼働時間調整といったクラウドならではのコスト最適化を主体的に活用できるようになっています。会計システムの稼働後に他のワークロードでも AWS の利用が広がっていることが前向きに語られました。 もう一度やり直すとしたら何を変えるかという問いに対しては、「会計システム単体ではなく将来的なマルチアカウント構成を見据えた全体設計をすべきだった」「関係者間の役割分担を最初に明確にすべきだった」などの声があり、これから移行を検討される方へのアドバイスとして共有されました。 自社のマスコットキャラクターを AI で再現してみた 株式会社CBC Dテック テクニカルセンター プラットフォーム技術部 大石 祐貴 氏 株式会社 CBC Dテックでは、 Amazon Bedrock を用いて CBC テレビの公式マスコットキャラクター「シェアシェア」の AI 会話システムを開発しました。当初は応答速度を重視して Amazon Nova Lite を使用していましたが、回答精度を重視して Amazon Nova Pro に切り替えました。用途に応じて最適な基盤モデルを簡単に切り替えられることが Amazon Bedrock のメリットです。キャラクターの性格や口調はプロンプトエンジニアリングで制御しており、音声合成には外部サービスでオリジナルの音声モデルを作成して使用しています。コーディングエージェントを活用することで、プログラミング経験がほぼない中でもシステムを構築しました。 今年 3 月の自社イベントにて来場者向けに展示し、フリートーク、定型文のポン出し、しりとりなどの機能を提供しました。今後は RAG や Amazon SageMaker AI によるファインチューニングでキャラクターの再現精度を高めることを検討しています。 資料のダウンロードは こちら Amazon AppStream 2.0 を使用したクラウド編集環境の構築 読売テレビ放送株式会社 クロステック局 放送実施グループ 香川 駿貴 氏 読売テレビ放送株式会社では、 Amazon WorkSpaces Applications（旧 Amazon AppStream 2.0） を使用したクラウド編集環境の構築と検証を実施しました。クラウド上に編集環境を構築することで、場所を問わず映像編集が可能になり、物理的な編集機の台数に縛られない柔軟な運用が実現できます。システム構成は、オンプレミスからクラウドストレージに素材を同期し、Amazon WorkSpaces Applications 上で EDIUS を動作させるというものです。3 つのアベイラビリティゾーンにサブネットを作成し、ここに編集機やライセンスサーバーを配置しています。 セッション起動時に証明書とバックグラウンドサービスを再生成するスクリプトを組み込んだマスターイメージを作成することで、当初から動いていた EDIUS 9 に加えて EDIUS 10、EDIUS 11 でも動作に成功しています。使用時間に基づくコストも明確になり、従量課金モデルによる編集環境のコスト可視化という点でも価値のある検証となりました。 資料のダウンロードは こちら Kiro を使ったエンジニアハッカソンをやってみた 株式会社毎日放送 コンテンツ戦略局 プラットフォームビジネス部 村嶋 優吾 氏 株式会社毎日放送では、社内開発人口の増加を目的として、AWS の AI コーディングツール Kiro を使用した 2 日間のエンジニアハッカソンを開催しました。技術職の若手を中心に参加し、全チームが動くプロトタイプのデプロイまで到達しています。成果物の 1 つである新人研修用システムは、現在も開発が継続され実用化を目指しています。Kiro を選定した理由として、社内に AWS の精算フローが確立されており事務コストが低いこと、ターミナル操作や複雑なコマンド入力が少なく参加者層にマッチしていること、そして Kiro の「スペック駆動開発」の設計思想が放送局の技術職の働き方と相性が良いことが挙げられました。スペック駆動開発では仕様を自然言語で言語化してから AI に開発を指示するため、コーディング経験の少ない参加者でも効率的に開発を進めることができます。 運営者としての学びとして 2 つのポイントが共有されました。1 つ目は「仕様の言語化が最短経路」であること。事前にスペックをしっかり定義してから開発を始めたチームは AI の出力精度が高く、開発もスムーズに進みました。従来のハッカソンでは「早く手を動かす」ことが正義でしたが、生成 AI 開発においてはその気持ちを抑えて仕様の言語化に集中することが結果的に最短経路になるという気づきが得られました。2 つ目は「評価の壁」です。生成 AI により実装は容易になった一方で、セキュリティ設定の適切性やテストケースの網羅性など、成果物の品質担保が新たなボトルネックとして浮上しています。実装コストが削減された分、成果物を正しく評価するリテラシーの強化が今後重要になります。 資料のダウンロードは こちら まとめ メディア業界向け勉強会の開催概要をご紹介させていただきました。今回の 5 つのセッションでは、リアルタイム字幕生成、基幹システムのクラウド移行、AI キャラクター、クラウド編集環境、AI 開発ハッカソンと、幅広いテーマが取り上げられました。生成 AI と AWS のマネージドサービスを組み合わせることで、限られたリソースの中でも新しい価値を素早く生み出せることが各社の事例を通じて示されています。内容について詳しく知りたい方は、記事上部より資料のダウンロード及び動画を視聴いただけますのでご確認ください。引き続き業界の皆様に役立つ情報を、セミナーやブログで発信していきますので、どうぞよろしくお願いいたします。 参考リンク AWS Media Services AWS Media &amp; Entertainment Blog (日本語) AWS Media &amp; Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメールマガジンをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 この記事は SA 小南英司が担当しました。