本記事は 2026 年 4 月 2 日に公開された Nima Kaviani による “ MiniMax M2.5 and GLM-5 are now in Kiro ” を翻訳したものです。 Kiro のオープンウェイトモデルへのネイティブサポートを拡充してきました。最近では MiniMax M2.5 に続き、GLM-5 も Kiro IDE および CLI から直接利用できるようになりました。Kiro はすでにコスト・コンテキスト長・速度のバランスが異なる多様なモデルをサポートしています。今回の 2 つの追加により、その幅がさらに広がり、開発者やチームが目の前の作業に応じてモデルを選択できる余地が増えました。 モデルの詳細 各モデル が持つ特徴と、得意とする用途について詳しく見ていきましょう。 MiniMax M2.5 （クレジット乗数 0.25x）— クエリごとに 100 億パラメーターを活性化するスパース MoE (Mixture of Experts) モデルです。わずか 4 分の 1 のクレジットコストで、SWE-Bench Verified において 80.2% のスコアを記録しており、Claude Sonnet を超えた初のオープンウェイトモデルとして、Claude Opus 4.6（80.8%）に次ぐ位置につけています。Kiro の中でも最もコスト効率の高いモデルの一つです。MiniMax M2.1 と比較して複雑なエージェントタスクを 37% 高速に完了します。コードを書く前に機能を分解して構造をマッピングするため、マルチステップの実装作業や長時間のエージェントセッションに優れています。また、10 以上の言語（Go、C、C++、TypeScript、Rust、Kotlin、Python、Java、JavaScript など）にわたる強力な多言語サポートを提供し、Web、Android、iOS、Windows にまたがるフルスタックプロジェクトにも対応しています。継続的なコーディングセッションや反復的な実装作業に対して、高速かつコスト効率の高いモデルをお求めであれば、MiniMax M2.5 は有力な選択肢です。 GLM-5 （クレジット乗数 0.5x）— 200K コンテキストウィンドウを備えた大規模 MoE モデルです。GLM-5 は長期的なエージェントワークフローに最適化されています。リポジトリ規模のコンテキストを処理し、大規模なコードベースにわたるマルチステップのツール使用において一貫性を維持することに優れています。クロスファイルのマイグレーション、フルスタックの機能開発、あるいはモデルが全体像を把握する必要があるレガシーリファクタリングなどのユースケースが該当します。深いコンテキストが求められる複雑なアーキテクチャ変更に取り組んでいる場合は、GLM-5 を試してみる価値があります。 IDE と CLI で試してみましょう これらのモデルは現在、 IDE のモデルセレクター および Kiro CLI から実験的サポートとして利用できます。MiniMax M2.5 は AWS US-East-1（バージニア北部）および AWS EU-Central-1（フランクフルト）リージョンで利用可能です。GLM-5 の推論は AWS US-East-1（バージニア北部）リージョンで実行されます。 また、Kiro にすでに搭載されているオープンウェイトモデルへのアクセスも拡大しました。MiniMax M2.1、Qwen3 Coder Next、Deepseek V3.2 は、IAM Identity Center（IdC）経由で認証しているユーザーを含む全ユーザーが利用できるようになりました。推論をワークロードに近づけるため、MiniMax M2.1 と Qwen3 Coder Next は AWS US-East-1（バージニア北部）に加えて AWS EU-Central-1（フランクフルト）リージョンでも利用可能です。 設定不要、ルーティング不要、追加セットアップ不要でモデルを選んですぐに作業を始められます。モデルを切り替えたり、特定のプロジェクトタイプにデフォルトを設定したり、Auto に任せたりと、ワークフローに合わせてご利用ください。エンタープライズチームの場合、管理者は モデルガバナンス を使用して、利用可能なモデルをコンプライアンスおよびデータレジデンシーの要件に合わせることができます。いつものように、ぜひ試してみて、 使い心地をお聞かせください 。どのモデルが好評で、どのような課題が残っているかを注視しています。次にサポートしてほしいモデルがあれば、 ぜひご要望をお寄せください 。 翻訳は Solutions Architect の吉村 が担当いたしました。

皆さんの多くと同じく、私も親です。そして、皆さんと同じように、自分の子どもたちのために築いている世界について考えています。これが、私たちの多くにとって 2026 年 3 月 31 日のリリースが重要な理由の 1 つです。同日、 AWS Sustainability コンソール のリリースを発表いたしました。これは、すべての AWS サステナビリティレポートとリソースを 1 か所に統合するスタンドアロンサービスです。 2019年、Amazon は The Climate Pledge (クライメイト・プレッジ) により、2040 年までに事業全体でネットゼロカーボン (温室効果ガス排出量実質ゼロ) を達成するという目標を設定しました。この取り組みが、AWS によるデータセンターとサービスの構築方法を形作っています。さらに、AWS は、お客様が自身のワークロードの環境フットプリントを測定し、削減できるよう支援することにも努めています。AWS Sustainability コンソールは、その方向への最新の 1 歩です。 AWS Sustainability コンソールは、 AWS 請求コンソール 内にある Customer Carbon Footprint Tool (CCFT) に基づいて構築されており、お客様からご要望のあった新しい機能セットを取り入れています。 これまで、二酸化炭素排出量データにアクセスするには請求レベルのアクセス許可が必要でした。その結果、実際的な問題が生じていました。サステナビリティの専門家や報告チームが、コストや請求データにアクセスできない (またアクセスすべきではない) ことがよくあったのです。適切な人が適切なデータにアクセスできるようにするには、持続可能性のワークフローを念頭に置いて設計されていない許可構造とうまく折り合いをつける必要がありました。AWS Sustainability コンソールには、請求コンソールから独立した独自のアクセス許可モデルがあります。サステナビリティの専門家が排出量データに直接アクセスできるようになったため、請求へのアクセス許可の付与も必要ありません。 コンソールには、お客様の AWS の使用状況に起因する スコープ 1、2、3 の排出量 が含まれており、AWS リージョンやサービス ( Amazon CloudFront 、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Simple Storage Service (Amazon S3) など) 別の内訳が表示されます。基盤となるデータと手法は、今回のリリースで変わっていません。これらは CCFT が使用しているものと同じです。変更したのは、データへのアクセス方法と操作方法です。 サステナビリティ報告の要件がますます複雑になるにつれ、チームには排出量データへのアクセスと操作をより柔軟に行う必要が生じています。これを受け、コンソールに Reports ページを追加しました。このページでは、市場ベースの手法 (MBM) とロケーションベースの手法 (LBM) の両方のデータを対象とする、事前設定済みの月次および年次の炭素排出量レポートをダウンロードできます。含めるフィールド、時間粒度、およびその他のフィルターを選択し、カスタムのカンマ区切り値 (CSV) レポートを作成することも可能です。 組織の会計年度が暦年と一致しない場合は、レポート期間に合わせてコンソールを設定できるようになりました。これを設定すると、すべてのデータビューとエクスポートに会計年度および四半期が反映され、財務チームとサステナビリティチームが並行して作業する際の共通の摩擦点がなくなります。 新しい API または AWS SDK を使用して、排出量データを独自のレポートパイプライン、ダッシュボード、またはコンプライアンスワークフローに統合することもできます。これは、データエクスポートを設定せずに多数のアカウントにおいて特定の月のデータを引き出す必要があるチームや、既存の AWS Organizations 構造と一致しないカスタムアカウントグループを確立する必要がある組織に役立ちます。 リリースされた最新の機能や手法の更新については、 [詳細] タブの「 リリースノート 」ページをご覧ください。 実際の動作を見てみましょう Sustainability コンソールをお見せするために、 AWS マネジメントコンソール を開き、画面上部の検索バーで「サステナビリティ」を検索しました。 [炭素排出量] のセクションでは、二酸化炭素換算量 (MTCO2e) をメートルトン単位で推定できます。これは MBM と LBM で表されたスコープ別の排出量を示しています。画面の右側では、日付範囲を調整したり、サービスやリージョンなどでフィルターしたりできます。 なじみのない方のために説明すると、スコープ 1 には所有または管理されている発生源からの直接排出 (データセンターの燃料使用など) 、スコープ 2 には購入したエネルギーの生産による間接排出 (MBM はエネルギー属性証明書を考慮し、LBM は地域の平均グリッド排出量を使用する)、スコープ 3 にはサーバー製造やデータセンター建設など、バリューチェーン全体にわたるその他の間接排出が含まれます。詳細については、サードパーティーのコンサルタントである Apex が独自に検証 した 当社の手法に関するドキュメント をご覧ください。 API または AWS コマンドラインインターフェイス (AWS CLI) を使用して、プログラムで排出量データを取得することもできます。 aws sustainability get-estimated-carbon-emissions \ --time-period='{"Start":"2025-03-01T00:00:00Z","End":"2026-03-01T23:59:59.999Z"}' { "Results": [ { "TimePeriod": { "Start": "2025-03-01T00:00:00+00:00", "End": "2025-04-01T00:00:00+00:00" }, "DimensionsValues": {}, "ModelVersion": "v3.0.0", "EmissionsValues": { "TOTAL_LBM_CARBON_EMISSIONS": { "Value": 0.7, "Unit": "MTCO2e" }, "TOTAL_MBM_CARBON_EMISSIONS": { "Value": 0.1, "Unit": "MTCO2e" } } }, ... ビジュアルコンソールと新しい API の組み合わせにより、引き続き利用可能な データエクスポート に加えて、データを操作する方法が 2 つ追加されました。コンソールでホットスポットを調べて特定し、ステークホルダーと共有したいレポートを自動化できるようになりました。 Sustainability コンソールは成長するように設計されています。お客様とともにコンソールの機能を拡張し、引き続き新機能をリリースする予定です。 今日から始めよう AWS Sustainability コンソールは、追加費用なしで本日からご利用いただけます。AWS マネジメントコンソールからアクセスしてください。履歴データは 2022 年 1 月まで記録されているため、すぐに排出量の傾向を調べることができます。 今すぐ コンソール の使用を開始しましょう。持続可能性に対する AWS の取り組みについて詳しく知りたい場合は、「 AWS の持続可能性 」ページをご覧ください。 – seb 原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。4 月は新年度のスタートということで、新入社員として新たにクラウドや生成 AI の世界に飛び込まれた方も多いと思います。そうしたみなさんが最新のトレンドや実践的な活用例をキャッチアップする一助として、このブログを日々の情報収集や学習に役立てていただければ幸いです。日本のお客様向けに、生成 AI の実用化を支援する各種プログラムや事例も増えてきており、「どのように始めるか」だけでなく「どうスケールさせるか」「どう安全に運用するか」といった観点でのベストプラクティスも見え始めています。新しくご入社された方も、すでにクラウドに取り組まれている方も、ぜひご自身のプロジェクトやキャリアの文脈に引き寄せながら読んでいただければと思います。 それでは 3月 30 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「 大成株式会社様の AWS 生成 AI 活用事例「Amazon Bedrock と Amazon Q Developer で非エンジニアが実現する契約書管理 AI エージェントの構築」のご紹介 」 ファシリティマネジメントや不動産投資事業を展開する大成株式会社様が、社内にエンジニアを擁さない状況の中、Amazon Bedrock と Amazon Q Developer を活用して契約書管理 AI エージェントを構築した事例です。非エンジニアのプロジェクトマネージャーが中心となり、Amazon Q Developer の自然言語によるコード生成支援と Amazon Bedrock 上の Claude による高度な PDF 文書解析を組み合わせることで、従来数十分かかっていた契約書からの情報抽出を数分に短縮（作業時間を約 70〜80% 削減）することに成功しました。「社内にエンジニアがいない」「開発リソースが限られている」という企業が抱えがちな課題に対して、業務を最もよく知る現場の担当者自身が AWS の生成 AI サービスを組み合わせて実用的なシステムを作り上げたこの事例は、スモールスタートで業務改善の成果を出すアプローチとして参考になります。 ブログ記事「 Agentic AIの運用化 Part 1: ステークホルダー向けのガイド 」 AWS Generative AI Innovation Center（GenAIIC）が 1,000 社以上の AI 本番移行支援から得た知見をもとに、Agentic AI を実業務に定着させるためのフレームワークを解説した記事です。多くの企業が AI パイロットを立ち上げながら実運用に至らない根本原因は「テクノロジーのギャップ」ではなく「オペレーティングモデルの欠如」にあるとし、成功している組織に共通する「仕事の詳細定義」「エージェントの自律性の境界設定」「継続的な改善の習慣化」という 3 つの要素を示しています。エージェント化に適した業務の見極め方（明確な開始・終了・目的、複数ツールを横断した判断、成功の測定可能性、安全な失敗モード）も具体的に説明されており、経営陣からビジネスオーナーまで幅広いステークホルダーが今日から取れるアクションをすぐに実践できる内容で、Agentic AI を活用している・これから活用を検討しているすべてのユーザーにとって、PoC 止まりを防ぎ本番稼働へと踏み出すための実践的な道標となる一記事です。 ブログ記事「 Agentic AIの運用化 Part 2: ペルソナ別のガイダンス 」 Part 1 で示した「Agentic AI の障壁はテクノロジーではなくオペレーティングモデルにある」という知見を受けて、AWS Generative AI Innovation Center（GenAIIC）が事業部門オーナー・CTO・CISO・CDO・Chief AI Officer・コンプライアンス責任者それぞれの役割に応じた実践的なガイダンスを提示しています。事業部門オーナーにはエージェントを KPI に直結させるジョブディスクリプション作成、CTO にはスケーラブルなエージェント基盤設計、CISO にはエージェントを「同僚」として扱うアイデンティティとポリシー管理、CDO にはデータの一貫性とガバナンス整備、Chief AI Officer には評価システムこそが真のプロダクトであるという考え方、コンプライアンス責任者には監査を想定した設計など、それぞれの責任に即した具体的なアクションが示されており、Agentic AI を「実験」から「本番稼働」へと引き上げるために誰が何をすべきかを職責ごとに明確に整理した内容は、生成 AI 活用を組織全体で推進しようとしているあらゆるステークホルダーにとって、今すぐ行動に移せる実用的なロードマップになっています。 ブログ記事「 AWS DevOps Agent の一般提供開始のお知らせ 」 AWS やオンプレミス環境を横断してインシデントの自律的な調査・解決・予防を行う AI エージェント「AWS DevOps Agent」が一般提供（GA）を開始し、東京リージョンを含む世界 6 リージョンで利用できるようになりました。GA にあわせて、Triage Agent による重複インシデントの自動検出、コードリポジトリのインデックスを活用したコードレベルの根本原因特定、PagerDuty・Grafana・Azure DevOps などの新規インテグレーション、プライベート接続やカスタマーマネージドキーによるエンタープライズ対応機能、そしてブラウザのロケール設定に応じてエージェントの応答を日本語を含む各言語に翻訳するローカライゼーション機能も追加されています。 ブログ記事「 「Physical AI on AWS 勉強会 #1」を開催しました 」 AWS ジャパンが「フィジカル AI 開発支援プログラム」の採択企業向けに開催した勉強会 の内容をまとめた記事で、ロボットなどの物理世界で動く AI（Physical AI）を AWS 上で開発するためのリファレンスアーキテクチャと、すぐに使えるサンプルコード集「Physical AI Scaffolding Kit（PASK）」が紹介されています。シミュレータでの合成データ生成から Amazon SageMaker HyperPod による分散学習、AWS IoT Greengrass を活用したエッジへのモデル配信までの一気通貫な開発サイクルを AWS 上で構築する方法が具体的に解説されており、ロボティクスや自動化システムの開発に取り組む企業・エンジニアにとって、Physical AI 開発の全体像と AWS 活用の実践的な出発点を得られる内容です。また、VLA（Vision-Language-Action）モデルという新しい AI アーキテクチャへの理解を深めたい生成 AI ユーザーにとっても、言語・視覚・行動を統合したモデルが実際にどのようなインフラで学習・運用されるのかを把握できる参考事例となっています。 ブログ記事「 Amazon OpenSearch Service のエージェント AI でオブザーバビリティとトラブルシューティングを効率化 」 Amazon OpenSearch Service の OpenSearch UI に、オブザーバビリティとトラブルシューティングを大幅に効率化する 3 つのエージェント AI 機能（エージェントチャットボット・調査エージェント・エージェントメモリ）が組み込まれました。エージェントチャットボットは現在表示中のコンテキストを理解して自然言語でクエリを自動生成し、調査エージェントは複数のインデックスをまたぐシグナルを plan-execute-reflect 方式で自律的に相関分析して仮説駆動型の根本原因レポートを生成します。複雑なログ分析に多大な時間を費やしてきた運用チームにとってアラートから根本原因の特定までを短時間で到達できるようになります。 ブログ記事「 Kiro のエンタープライズガバナンス: MCP サーバーとモデルを管理する 」 AI コーディング IDE「Kiro」に 2 つの新しいエンタープライズガバナンス機能が追加されました。管理者が承認済み MCP サーバーを JSON 形式のレジストリでホワイトリスト管理できる「MCP サーバーレジストリ」と、組織内の開発者が利用できる AI モデルを制限できる「モデルガバナンス」です。MCP レジストリは起動時・24 時間ごとに同期され、未承認サーバーへの接続を防止します。モデルガバナンスはデータレジデンシー要件への対応にも有効で、実験的モデルを承認完了まで無効化できます。これらの機能は Kiro IDE 0.11.28 / CLI 1.23 以降のエンタープライズユーザー向けに提供されます。 ブログ記事「 MiniMax M2.5 と GLM-5 が Kiro に追加 」 AI コーディング IDE「Kiro」に、新たにオープンウェイトモデルの MiniMax M2.5 と GLM-5 が追加され、Kiro IDE および Kiro CLI から利用できるようになりました。MiniMax M2.5 はクレジット消費が 0.25 倍という低コストながら SWE-Bench Verified で 80.2% を達成（オープンウェイトモデルとして初めて Claude Sonnet を超えた性能）した高速なモデルで、複数ステップのエージェントタスクや繰り返しの実装作業に強みを持ちます。米国東部（バージニア北部）と欧州（フランクフルト）リージョンで利用可能です。GLM-5 は 200K のコンテキストウィンドウを持つ大規模 MoE モデルでリポジトリ規模の長期的なエージェントワークフローに最適化されています。こちらは米国東部（バージニア北部）リージョンで利用可能です。 サービスアップデート Amazon Bedrock AgentCore Evaluations が一般提供を開始 AI エージェントの品質を自動評価する「Amazon Bedrock AgentCore Evaluations」が一般提供（GA）を開始し、アジアパシフィック（東京）を含む 9 リージョンで利用できるようになりました。本番トラフィックをサンプリングしてリアルタイムにスコアリングするオンライン評価と、CI/CD パイプラインや開発ワークフローに組み込めるオンデマンド評価の 2 種類を提供しており、応答品質・安全性・タスク完了率・ツール使用状況をチェックする 13 種類の組み込み評価器に加え、期待値との比較（Ground Truth）や Python・JavaScript による完全カスタム評価ロジックにも対応しています。AI エージェントを本番稼働させているユーザーにとっては品質劣化をいち早く検知できる仕組みが整い、生成 AI を活用しているエンジニアにとっても AgentCore Observability との統合によって評価・監視を一元管理できるようになる点は、Agentic AI を信頼性高く運用していく上で欠かせないアップデートです。 Amazon Bedrock Guardrails がクロスアカウントセーフガードの一般提供を開始 Amazon Bedrock Guardrails に、組織内のすべての AWS アカウントにセーフガードを一元適用できる「クロスアカウントセーフガード」が一般提供（GA）となりました。管理アカウントで設定したガードレール ID を Amazon Bedrock ポリシーに指定するだけで、組織内のすべてのメンバーアカウントや組織単位（OU）に対するすべての基盤モデル呼び出しに自動的にコントロールが適用されるため、アカウントごとに個別設定する運用負荷を削減できます。 Amazon OpenSearch Service がログ分析向けエージェント AI 機能を提供開始 Amazon OpenSearch Service に、エンジニアリングチームや運用チームが自然言語でログデータを分析できるエージェント AI 機能が追加され、東京 を含む 9 リージョンで追加費用なし（トークン使用量の制限あり）で利用できるようになりました。自然言語で質問して PPL クエリを自動生成・修正する「エージェントチャット」、根本原因を自律的に仮説立案・検証・ランク付けして報告する「調査エージェント」、セッションをまたいで会話を継続できる「エージェントメモリ」の 3 機能が提供されており、複雑なクエリ言語を書かなくてもインシデント調査を効率化することができます。 Amazon S3 Vectors が 17 の追加リージョンに拡張 クラウドオブジェクトストレージとして初めてベクトルのネイティブな保存・クエリをサポートする「Amazon S3 Vectors」が、大阪 を含む17のリージョンに拡張され、合計 31 リージョンで利用可能になりました。1 つのベクトルインデックスに最大 20 億ベクトルを保存でき、インフラのプロビジョニング不要で最大 1 万のベクトルインデックスに弾力的にスケール、頻繁なクエリでは 100 ミリ秒という低レイテンシも実現します。Amazon Bedrock Knowledge Bases とネイティブ統合されているため、RAG（検索拡張生成）やセマンティック検索に大規模なベクトルデータを低コストで活用したい生成 AI ユーザーにとっては、今回の拡張でデータレジデンシー要件を満たしながらより身近なリージョンで運用できるようになった点が嬉しいアップデートです。 GLM-5 が Kiro に追加 Kiro に、200K のコンテキストウィンドウを持つ大規模 MoE（Mixture of Experts）モデル「GLM-5」のサポートが追加され、Kiro IDE および Kiro CLI からエクスペリメンタルサポートとして利用できるようになりました。GLM-5 はリポジトリ規模の大量コンテキストを処理しながら複数ステップのツール利用にわたって一貫性を維持することに長けており、クロスファイルマイグレーション・フルスタック機能開発・レガシーコードのリファクタリングといった「全体像をモデルに把握させながら進める」複雑な作業に適しています。推論は米国東部（バージニア北部）リージョンで実行され、クレジット消費は 0.5 倍で、モデルセレクターから利用するには IDE または CLI の再起動が必要です。長いコンテキストを扱う生成 AI ユーザーにとっては、大規模コードベースを丸ごと扱う用途で Claude 系モデルとの使い分けを検討できる新たな選択肢が加わったことになります。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近天ぷらを(食べるのではなく)揚げるほうにハマってます。

本記事は 2026 年 3 月 23 日に公開された Phill Shaffer, Doug Clauson の “ A new look for the Kiro CLI ” を翻訳したものです。 私たちはターミナルが大好きです。この記事を読んでいるあなたも、きっとそうでしょう。CLI には、スピード、集中力、そして直接性という独特の魅力があります。速く、反応が良く、即座に結果が返ってくる。Kiro CLI はすでに、エージェントとの直接チャット、計画の作成、複数ステップにわたる処理の実行といった機能を通じて、エージェント型コーディングの力をターミナル環境にもたらしています。そして、さらに良い体験を追求した結果、新しいデザインへの刷新が必要だという結論に至りました。 本日、Kiro CLI の刷新された UX をご紹介します。いつでも以前の体験に戻せる「実験的モード」として提供するので、ぜひフィードバックをお聞かせください。 Kiro CLI をインストール して、コマンドラインで kiro-cli --tui と入力するだけで試せます。 なぜ実験的モードなのか？ 私たちは自分たちの成果を誇りに思っていますが、毎日使ってくれる方々の声を聞きながら、より良いものに仕上げていきたいと考えています。既存の体験と並行して提供することで、現在の作業の流れを妨げることなく新しい UX を試せます。両方が並行して動作し、コミュニティから「準備ができた」という声が上がったタイミングでデフォルトに切り替えます。移行はシームレスで、ユーザー側での追加作業は一切不要です。試してみた感想は、 Discord の #kiro-cli-v2-ux-feedback チャンネル、または CLI 内の /feedback コマンドでお寄せください。 なぜ UX を刷新するのか？ 最初の CLI（Kiro CLI の前身）をリリースした当時、私たちは AI エージェントをターミナルに持ち込んだ最初期のエージェント型開発体験のひとつでした。CLI とエージェントを組み合わせるというアイデアは未開拓の領域であり、動くプロダクトを素早くユーザーの手に届けるため、1 行ずつ出力する方式を採用しました。それは機能し、高速でもありましたが、バイブコーディングや計画立案、サブエージェントの活用など、さまざまな用途で Kiro を使う開発者が増えるにつれ、そのアプローチの限界を感じるようになりました。 エージェントとのやり取りをストレスなく行えるようにしたい。エージェントが作業中でも、割り込んだり、方向を変えたり、主導権を握り続けられるようにしたい。モダンなターミナルユーザーインターフェイス（TUI）に期待される / コマンドや @ コンテキストといった便利な機能を提供したい。そして、サブエージェントやマルチエージェントチームといった、より複雑な処理を見据えたとき、それらの野心に応えられる基盤が必要だと確信しました。 そこで、表示レイヤーだけでなく、ターミナル上でエージェントと対話するための新しいデザイン言語として、ゼロから作り直しました。ターミナルは上から下へと出力されます。私たちはその自然な流れを大切にしたいと考えました。統合ターミナルのような制約のある環境にも適応できるよう、画面スペースを尊重した設計にしています。その結果、CLI らしさをそのままに、エージェント型コーディングの可能性を最大限に引き出す本格的な TUI が完成しました。 何が変わるのか 新しい体験では、以下の機能が利用できます。 ライブ統合ステータス :  Kiro エージェントと作業しているとき、エージェントの応答に合わせてリアルタイムで更新されるステータスバーが表示されます。ツールの実行状況、進行中の会話、さらには行単位の差分まで、すべてが統一された一貫性のある UX に統合されています。断片的な表示はもうありません。エージェントがファイルを読んでいるのか、コードを書いているのか、bash コマンドを実行しているのかにかかわらず、今まさに何が起きているのか、そしてセッション内で何が行われたのかを常に把握できます。 常時表示の入力エリア :  入力エリアは常に利用可能です。次のメッセージを入力したり、Escape キーで割り込んだり、エージェントの方向を変えたりと、待つことなく操作できます。エージェントがツールの実行許可を求めるとき、入力エリアのすぐ上にスナックバーが表示され、「許可」「拒否」「常に信頼」といった明確な選択肢が示されます。ターミナルをあちこち探し回る必要はありません。エージェントが作業中でも、あなたが主導権を握り続けられます。 スラッシュコマンドと @ コンテキスト :  `/` と入力するとドロップダウンで利用可能なコマンドが表示されます。`@` を使えば会話にコンテキストを追加できます。従来の GUI に期待されるような便利な機能を、慣れ親しんだターミナル環境を離れることなく利用できます。 コンテキストオーバーレイ: コンテキストウィンドウの管理や使用状況・クレジットの確認が必要なときは、新しいパネルシステムがプロンプトエリア内にオーバーレイ表示されます。GUI のサイドパネルのような感覚で、ターミナルにネイティブに統合されています。 ご意見をお聞かせください 皆さんのフィードバックが、CLI のさらなる UX 向上に欠かせません。良かった点、改善してほしい点、次に見たい機能など、何でもお聞かせください。皆さんからのご意見をお待ちしています！ ターミナルで kiro-cli --tui を実行してみてください。感想は Discord の #kiro-cli-v2-ux-feedback チャンネル、または CLI 内の /feedback コマンドでお寄せください。詳細については、 ドキュメント もご覧ください。 翻訳はApp Dev Consultantの宇賀神が担当しました。

本記事は 2025 年 8 月 14 日 に公開された「 How to use 3ds Max with service-managed fleets on AWS Deadline Cloud 」を翻訳したものです。 AWS Deadline Cloud のマネージドインフラストラクチャを活用しつつ、 Autodesk 3ds Max をワークフローで使い続けたいスタジオやアーティストにとって、両立は難しい課題となる場合があります。本記事では、 設定スクリプト（host config script） を使ってサービスマネージドフリート ( SMF ) 上で 3ds Max を有効にする方法を紹介します。これによってマネージドインフラストラクチャの利便性と 3ds Max の機能を組み合わせ、レンダーノードを自前で管理する負荷を軽減しながら、レンダリングパイプラインの柔軟性を高めることができます。 前提条件 開始前に、以下を準備してください。 AWS Deadline Cloud を使用するための AWS アカウント。 Windows インスタンスを使用する SMF が 1 つ関連付けられたキューを持つ Deadline Cloud ファーム。既存環境への影響を避けるため、3ds Max 専用のキューを新規作成することを推奨します。 Deadline Cloud モニター がインストール済みで、ファーム用のプロファイルが作成済みであること。 Autodesk からダウンロードした 3ds Max 2024 のインストールファイル (フォルダのルートに Setup.exe があることを確認してください)。 3ds Max 2024 がインストールされた Windows ワークステーション 3ds Max 用 Deadline Cloud サブミッター 注意 : Autodesk 3ds Max には AWS とは別のライセンス要件があります。作業を進める前に、適切なライセンスを保有していることを確認してください。詳細は Autodesk Cloud Rights for 3ds Max を参照してください。 3ds Max インストールパッケージの準備 まず、フリートワーカーにデプロイするための 3ds Max インストールファイルを準備します。 3ds Max 2024 のインストールフォルダを 3ds_max_2024_full.zip という名前の zip パッケージに圧縮します。 図 1: 3ds Max インストールフォルダを zip ファイルに圧縮する。 AWS Deadline Cloud コンソールに移動し、 Farms and other resources に進みます。 ファーム を選択し、次に キュー を選択します。 キューの詳細ビュー で、 Job Attachments を選択します。 バケット名 をクリックして S3 コンソールでバケットを開きます。 バケット内に resources という新しいフォルダを作成します。 作成した resources フォルダに 3ds_max_2024_full.zip ファイルをアップロードします。 図 2: 3ds Max インストール zip ファイルを S3 バケットにアップロードする。 S3 バケットの権限設定 設定スクリプトはフリートの IAM ロール で実行されます。フリートワーカーが 3ds Max インストールファイルにアクセスできるよう、フリートの IAM ロールに適切な S3 バケット権限を付与する必要があります。 AWS Deadline Cloud コンソール に移動し、ファームおよび他のリソース（ Farms and other resources ） に進みます。 ファーム を選択し、次に フリート を選択します。 フリートの詳細画面内から 、 Fleetサービスロールへのリンク をクリックします。 ロールの許可ポリシーに以下のインラインポリシーを追加します。<your-bucket-name> と <your-account-id> 部分の記述を実際の値に置き換えてください。 { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": [ "arn:aws:s3:::<your-bucket-name>", "arn:aws:s3:::<your-bucket-name>/resources/*" ], "Condition": { "StringEquals": { "aws:ResourceAccount": "<your-account-id>" } } }] } 図 3: フリート IAM ロールに S3 権限を追加する。 ワーカー設定スクリプトの作成 次に、フリートワーカーの起動時に 3ds Max をインストールするワーカー設定スクリプトを作成します。 AWS Deadline Cloud コンソールに移動し、ファームおよび他のリソース（Farms and other resources）に進みます。 ファーム を選択し、次に フリート を選択します。 フリートの詳細画面内 で、 設定 （ Configurations） タブを選択します。 「ワーカー設定スクリプト（Worker configuration script）」セクションで、 スクリプトを作成（Create） または 編集（Edit）  をクリックします。 図 4: フリート設定でワーカー設定スクリプトにアクセスする。 スクリプトエディタに以下の PowerShell スクリプトを貼り付けます。 <your-bucket-name> を S3 バケット名に置き換えてください。 mkdir C:\3dsmax_setup Write-Host " --- Downloading from S3 --- " aws s3 cp --no-progress s3://<your-bucket-name>/resources/3ds_max_2024_full.zip C:\3dsmax_setup\3dsmax.zip Write-Host " --- Expanding Archive --- " Expand-Archive C:\3dsmax_setup\3dsmax.zip C:\3dsmax_setup\ Write-Host " --- Starting Install --- " Start-Process -FilePath "C:\3dsmax_setup\3dsMax2024\Setup.exe" -ArgumentList "-q" -Wait -PassThru Write-Host " --- Post install setup --- " [Environment]::SetEnvironmentVariable("Path", "C:\Program Files\Autodesk\3ds Max 2024;" + [Environment]::GetEnvironmentVariable("Path", "Machine"), "Machine") & "C:\Program Files\Autodesk\3ds Max 2024\Python\python.exe" -m ensurepip & "C:\Program Files\Autodesk\3ds Max 2024\Python\python.exe" -m pip install deadline-cloud-for-3ds-max [Environment]::SetEnvironmentVariable("3DSMAX_EXECUTABLE", "C:\Program Files\Autodesk\3ds Max 2024\3dsmaxbatch.exe", "Machine") [Environment]::SetEnvironmentVariable("PYTHONPATH", "C:\Program Files\Autodesk\3ds Max 2024\Python;C:\Program Files\Autodesk\3ds Max 2024\Python\Scripts", "Machine") [Environment]::SetEnvironmentVariable("Path", "C:\Program Files\Autodesk\3ds Max 2024\Python;C:\Program Files\Autodesk\3ds Max 2024\Python\Scripts;" + [Environment]::GetEnvironmentVariable("Path", "Machine"), "Machine") 図 5: 3ds Max インストールコマンドでワーカー設定スクリプトを編集する。 重要: 3ds Max のインストールが完了するまで十分な時間を確保するため、スクリプトのタイムアウトを 1200 秒 (20 分) に更新してください。 スクリプトを作成（Create）、または保存（Save） をクリックして変更を適用します。 図 6: スクリプトのタイムアウトを 1200 秒に設定する。 注意: スクリプトはフリートワーカーの起動時に実行されます。フリート内に既に実行中のワーカーがある場合、新しく設定したスクリプトは実行しないでください。 キュー環境（Queue environments）の設定 デフォルトのキュー環境は、サブミットされたジョブに必要なソフトウェア依存関係をインストールする仕組みです。サブミッターはデフォルトのキュー環境の定義を認識し、いくつかのソフトウェア依存関係を自動設定します。3ds Max の場合、Condaのサポートがないため、サブミッターが利用できないソフトウェア依存関係を誤って設定してしまいます。 設定スクリプトが必要な依存関係のインストールを処理するため、これ自体は問題ありませんが、ジョブ定義が存在しないCondaなどの依存関係を要求すると、ジョブが失敗します。 この問題を回避するため、デフォルトのキュー環境（Conda）を削除します。 フリートの詳細 ビューで、 Associated queues タブを選択し、 キュー を選択します。 キューの詳細 ビューで、 Queue environments タブを選択します。 デフォルトのキュー環境が存在する場合、 デフォルトのキュー環境（Conda） を選択して 削除（Delete） をクリックします。 図 7: デフォルトのキュー環境が存在する場合は削除する。 注意: デフォルトのキュー環境が必要な場合はそのまま引き続き使用できますが、サブミッターの値が自動で設定されるため、 サブミッター内の Conda Packages プロパティを手動で上書きします 。これはジョブをサブミットするたびに操作が必要です。 3ds Max レンダリングジョブのサブミット フリートが 3ds Max をサポートするよう設定できたので、レンダリングジョブをサブミットできます。フルレンダリングジョブをサブミットする前に、設定が正しく動作しているか検証することを推奨します。 ワークステーションで 3ds Max を開き、最小限の 3ds Max シーン (基本的なシーンの 1 フレームをレンダリングするなど) でテストジョブを準備します。 3ds Max 用 Deadline Cloud サブミッターを使用して、設定済みのフリートに関連付けられた キュー にジョブをサブミットします。 図 8: 3ds Max から Deadline Cloud にレンダリングジョブをサブミットする。 Deadline Cloud モニターを開き、ジョブモニター（ Job Monitor） 画面に移動してジョブの進捗を確認します。 図 9: Deadline Cloud モニターで 3ds Max レンダリングジョブを監視する。 メリット 設定スクリプトを使って AWS Deadline Cloud で 3ds Max レンダリングを実装すると、クラウドのスケーラビリティと既存の 3ds Max ワークフローを両立できます。パフォーマンス、コスト効率、運用の効率化をバランスよく実現でき、現在のプロセスを大きく変更する必要はありません。 AWS Deadline Cloud の柔軟性を活かし、マネージドサービスの恩恵を受けながら、レンダリング環境を要件に合わせてカスタマイズできます。 このアプローチのメリットは以下のとおりです。 レンダーノードを自前で管理する運用負荷が削減。 需要に応じたレンダリングキャパシティの自動スケーリング。 既存の 3ds Max ワークフローとの互換性の維持。 トラブルシューティング 3ds Max レンダリングジョブで問題が発生した場合の一般的なトラブルシューティング手順を紹介します。 インストールの失敗 : Deadline Cloud コンソールの ワーカーログを確認 し、3ds Max のインストールプロセスでエラーが発生していないか確認してください。 依存関係の不足 : 3ds Max のプラグインや機能によっては、追加の依存関係が必要な場合があります。ワーカー設定スクリプトを変更して、必要な依存関係をインストールします。 タイムアウトの問題 : タイムアウトによりインストールが繰り返し失敗する場合は、スクリプトのタイムアウトを 1200 秒以上に増やしてください。失敗しなくなるか、1 時間の上限に達するまで 300 秒ずつ増やしてみてください。 権限エラー : フリートの IAM ロールに S3 バケットと 3ds Max インストールファイルへのアクセスに必要な権限が正しく設定されているか確認してください。 まとめ 本記事では、設定スクリプトを使って AWS Deadline Cloud のサービスマネージドフリートで Autodesk 3ds Max を有効にする方法を紹介しました。このアプローチにより、マネージドインフラストラクチャの利便性を活かしつつ、レンダリングパイプラインで 3ds Max を使用できます。 ビジネスの加速を支援する方法については、 AWS の担当者 にお問い合わせください。 関連リソース 3ds Max 向け設定スクリプトの最新の活用方法は、 Deadline Cloud Samples リポジトリ で確認できます。 さらに詳しく知りたい場合は、以下のリソースを参照してください。 AWS Deadline Cloud ドキュメント SMF の設定スクリプト Autodesk 3ds Max ドキュメント Deadline Cloud for 3ds Max GitHub リポジトリ Jair Ruiz Jair Ruiz is a Software Engineer building products for digital content creation at AWS. 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語)  AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は Visual Compute SSA 森が担当しました。原文は こちら をご覧ください。

本記事は 2026 年 4 月 3 日 に公開された「 Introducing OpenTelemetry & PromQL support in Amazon CloudWatch 」を翻訳したものです。 Kubernetes やマイクロサービスのワークロードを AWS で実行している場合、メトリクスには namespace、pod、container、node、deployment、replica set、カスタムのビジネスディメンションなど、多数のラベルが付いているでしょう。環境全体を把握するために、メトリクスパイプラインを分割しているケースも多いはずです。AWS メトリクスには Amazon CloudWatch を使い、高カーディナリティ (多数のラベルの組み合わせを持つ) なコンテナやアプリケーションのメトリクスには別の Prometheus 互換バックエンドを使う、といった具合です。さらに進んだチームでは、Prometheus CloudWatch エクスポーターで GetMetricData API を呼び出し、AWS リソースメトリクスを Prometheus バックエンドに取り込んでいることもあります。運用負荷とコストは増えますが、すべてを一箇所でクエリできるようになります。 Amazon CloudWatch で OpenTelemetry メトリクス のネイティブ取り込みと、 Prometheus Query Language (PromQL) によるクエリがサポートされました。このプレビュー機能では、メトリクスあたり最大 150 ラベルをサポートする高カーディナリティメトリクスストアが導入され、ラベルの多いメトリクスを変換や切り捨てなしで CloudWatch に直接送信できます。AWS Vended メトリクスの自動エンリッチメントと組み合わせることで、CloudWatch がインフラストラクチャ、コンテナ、アプリケーションメトリクスの一元的な送信先になり、すべて PromQL でクエリできるようになりました。 本記事では、以下の内容を説明します。 AWS アカウントで OpenTelemetry メトリクスの取り込みと AWS リソースの自動エンリッチメントを有効化する方法 Amazon Elastic Kubernetes Service (Amazon EKS) クラスターに Amazon CloudWatch Container Insights をデプロイする方法 Amazon CloudWatch と Amazon Managed Grafana で PromQL を使ってインフラストラクチャと AWS リソースのメトリクスをクエリする方法 OpenTelemetry SDK でカスタムアプリケーションメトリクスを作成し、AWS コンテキストで自動エンリッチメントされる様子 CloudWatch における OpenTelemetry サポートが何を意味するか OpenTelemetry Protocol (OTLP) は、OpenTelemetry (OTel) プロジェクトの標準ワイヤープロトコルです。メトリクス、トレース、ログを含むテレメトリデータのエンコードとコンポーネント間の転送方法を定義しています。このプレビューにより、CloudWatch は OpenTelemetry 互換のコレクターや SDK がメトリクスを送信できるリージョナル OTLP エンドポイントを公開します。 CloudWatch はメトリクスを受信し、新たな高カーディナリティのメトリクスストアに保存します。カウンター、ヒストグラム、ゲージ、アップダウンカウンターなどの OpenTelemetry メトリクスタイプは変換なしでそのまま保持されます。今回のリリースで、CloudWatch はオブザーバビリティの 3 本柱すべてで OpenTelemetry をサポートするようになりました。CloudWatch はすでに OTLP エンドポイント 経由でトレースとログを受け付けており、ネイティブ OTLP メトリクス取り込みが加わったことで、すべてのテレメトリをオープンスタンダードで、単一のプロトコルを通じて CloudWatch に送信できるようになりました。3 つの機能がこのことを重要にしています。 拡張されたラベルとカーディナリティのサポート OTLP で取り込まれたメトリクスは最大 150 ラベルをサポートし、CloudWatch カスタムメトリクスの 30 ディメンション制限を超えています。Kubernetes、マイクロサービス、OpenTelemetry ワークロードでフィルタリングや集計に高カーディナリティラベルを使う際の主要な制約が解消されます。制限は今後も進化するため、最新情報は クォータページ をご確認ください。 PromQL クエリのサポート OTLP 経由で取り込んだメトリクスを PromQL でクエリできます。すでに Prometheus を使っている場合、同じクエリ言語を CloudWatch や Amazon Managed Grafana で直接使えます。新しい構文を覚える必要はありません。 AWS リソースの自動エンリッチメント この機能により、AWS インフラストラクチャ全体でメトリクスをクエリ・フィルタリングする方法が根本的に変わります。CloudWatch は取り込んだすべてのメトリクスに AWS リソースコンテキスト (アカウント ID、リージョン、クラスター Amazon Resource Name (ARN)、AWS Resource Explorer からのリソースタグ) を付与します。このエンリッチメントは追加の計装なしで自動的に行われます。Container Insights、カスタムアプリケーション、AWS サービスのいずれから来たメトリクスでも、AWS アカウント、リージョン、環境タグ、アプリケーション名でフィルタリングやグループ化ができます。エクスポーター不要、カスタムラベル不要、追加の API 呼び出し不要です。 図 1: Amazon CloudWatch における OpenTelemetry メトリクスの取り込みとエンリッチメントアーキテクチャ OTLP 取り込みと AWS リソースエンリッチメントの有効化 OTLP メトリクスを取り込んでクエリする前に、2 つのアカウントレベルの設定を有効にします。1 つ目は、AWS Resource Explorer で確認できるものと同じリソースタグをテレメトリに伝播させる設定です。2 つ目は、CloudWatch の OTLP 取り込みを有効にする設定です。 両方のエンリッチメント設定は、Amazon CloudWatch コンソールまたは AWS CLI から有効にできます。 コンソールを使用する場合 CloudWatch コンソールでエンリッチメントを有効にする手順は以下のとおりです。 Amazon CloudWatch コンソールを開きます。 ナビゲーションペインで 設定  を選択します。 リソースタグのテレメトリへの伝播を有効にします。 AWS メトリクスの OTel エンリッチメントを有効にします。 両方の設定を有効にすると、アカウントでリージョナルエンドポイントへの OTLP メトリクス受信の準備が整います。 図 2: CloudWatch コンソール設定での OTel エンリッチメントとリソースタグの有効化 AWS CLI を使用する場合 AWS CLI で両方のエンリッチメントレイヤーを有効にすることもできます。以下のコマンドを実行します。 # Enable resource tags on telemetry aws observabilityadmin start-telemetry-enrichment # Enable OTel enrichment for CloudWatch aws cloudwatch start-o-tel-enrichment 両方のエンリッチメント設定がアクティブであることを確認するには、以下のコマンドを実行します。 aws cloudwatch describe-o-tel-enrichment-status エンリッチメントを有効にすると、OTLP エンドポイント経由で取り込まれたすべてのメトリクスに AWS リソースコンテキストが自動的にタグ付けされます。CloudWatch が追加する属性は以下のとおりです。 Attribute 説明 例 @aws.account AWS アカウント ID 123456789012 @aws.region AWS リージョン us-west-2 cloud.resource_id EKS クラスターの完全な ARN arn:aws:eks:us-west-2:123456789012:cluster/prod k8s.cluster.name EKS クラスター名 production-cluster k8s.namespace.name Kubernetes namespace karpenter k8s.container.name コンテナ名 controller @instrumentation.name 計装ソース cloudwatch-otel-ci リソースタグ AWS Resource Explorer からのタグ (@aws.tag.Application、@aws.tag.CostCenter、@resource.ec2.tag.ManagedBy など) env=production これらの属性は CloudWatch によって追加され、手動の計装は不要です。カスタムパイプラインの構築やエクスポーターの実行なしに、AWS アカウント、リージョン、リソースタグをまたいでクエリできるのはこのためです。 OpenTelemetry メトリクスを使った Amazon CloudWatch Container Insights OpenTelemetry と CloudWatch の連携を実際に確認するため、Container Insights から始めましょう。Amazon EKS 向け Amazon CloudWatch Container Insights で Prometheus と OpenTelemetry メトリクスが サポートされました 。コンテナメトリクスが OpenTelemetry attribute で標準化され、PromQL でクエリできるようになります。Container Insights は、コンソールまたは AWS CLI から Amazon EKS アドオンを使って 有効化 できます。 Container Insights ダッシュボード Container Insights をデプロイすると、CloudWatch は CPU 使用率、メモリ使用量、Pod 数などのクラスターレベルのメトリクスを表示するダッシュボードを自動的に作成します。ダッシュボードを表示するには、CloudWatch コンソールを開き、ナビゲーションペインから Container Insights を選択し、ドロップダウンからクラスターを選択します。クラスター、namespace、Pod レベルのビューを切り替えて、特定のワークロードを詳しく確認できます。 図 3: Amazon CloudWatch Container Insights ダッシュボード CloudWatch Query Studio で PromQL を使ってメトリクスをクエリする OTLP で取り込んだメトリクスは、CloudWatch コンソール、Amazon Managed Grafana、または PromQL と AWS Signature Version 4 (SigV4) をサポートするクエリインターフェースで PromQL を使ってクエリできます。 CloudWatch Query Studio には、コンソールで直接メトリクスを探索・可視化するための PromQL エディターが組み込まれています。PromQL クエリモードを選択して開始します。 図 4: PromQL クエリモードの Amazon CloudWatch Query Studio インターフェース エンリッチされた AWS リソースコンテキストを使ったクエリ エンリッチメントが有効になっているため、CloudWatch が自動的に追加するタグを使って AWS リソースの境界を越えてクエリできます。エクスポーター不要、カスタムラベル不要です。 # AWS Lambda function duration for functions tagged with application "order-pipeline" Duration{"@aws.tag.appname"="order-pipeline"} # Amazon EC2 CPU utilization for production delivery workloads CPUUtilization{"@aws.tag.Environment"="production", "@aws.tag.Application"="delivery"} # Running pods grouped by AWS account and namespace sum by (aws_account_id, k8s_namespace_name) (kube_pod_status_phase{phase="Running"}) 最後のクエリは、カスタム計装なしで AWS アカウントと Kubernetes namespace ごとにグループ化された実行中の Pod 数を返します。 aws_account_id ラベルはエンリッチメントレイヤーによって自動的に追加されます。 図 5: Lambda duration メトリクスをクエリする CloudWatch Query Studio Grafana で PromQL を使ってメトリクスをクエリする Amazon Managed Grafana で OTLP 取り込みメトリクスを可視化するには、CloudWatch PromQL エンドポイントを指す Prometheus データソースを追加します。このセクションでは、AWS Signature Version 4 (SigV4) 認証でデータソースを設定する手順を説明します。 Amazon Managed Grafana ワークスペースを開きます。 Data Sources を選択します。 Add data source を選択します。 データソースタイプとして Prometheus を選択します。 URL には、リージョンの CloudWatch PromQL エンドポイントを入力します: https://monitoring.<AWS Region>.amazonaws.com/v1/metrics Authentication で SigV4 を選択します。 SigV4 認証用の適切な IAM ロールを設定します。 Save & Test を選択して接続を確認します。 Save & Test が成功すると、「Data source is working」という確認メッセージが表示されます。失敗した場合は、IAM ロールに cloudwatch:GetMetricData と cloudwatch:ListMetrics の権限があること、SigV4 署名が正しく設定されていることを確認してください。 データソースを設定すると、Grafana ダッシュボードで同じ PromQL クエリを使用できます。 図 6: CloudWatch PromQL を使った Grafana Explore カスタムアプリケーションメトリクス CloudWatch OTLP 取り込みはカスタムアプリケーションメトリクスもサポートしています。OpenTelemetry SDK で計装されたアプリケーションは、クラスターで実行中の CloudWatch エージェント経由でメトリクスを送信でき、計装コードの変更は不要です。 実際の動作を確認するため、 aws-otel-community リポジトリからサンプル Python アプリケーションをデプロイします。このアプリケーションは OpenTelemetry Python SDK を使用して、カウンター、ヒストグラム、ゲージ、アップダウンカウンターなど、すべての OTel メトリクスタイプをカバーするカスタムメトリクスを出力します。例えば、アプリは API レスポンス時間を測定する latency_time ヒストグラムを定義しています。 from opentelemetry import metrics meter = metrics.get_meter(__name__) # Histogram --- measures API latency distribution latency_time = meter.create_histogram( name="latency_time", description="Measures latency time", unit="ms", ) サンプルアプリケーションのデプロイ サンプルアプリケーション とすべてのデプロイマニフェストは、GitHub の aws-otel-community リポジトリにあります。先ほどデプロイした Container Insights アドオンには、OpenTelemetry コレクターとして機能する CloudWatch エージェントが含まれています。 OTEL_EXPORTER_OTLP_ENDPOINT 環境変数を設定して、サンプルアプリをエージェントに向けます: http://cloudwatch-agent.amazon-cloudwatch.svc.cluster.local:4317 このウォークスルーでは CloudWatch エージェントを使用していますが、OTLP/HTTP をサポートする任意の OpenTelemetry 互換コレクターや SDK を使用して、CloudWatch OTLP エンドポイントに直接メトリクスを送信できます。 PromQL でアプリケーションメトリクスをクエリする アプリケーションをデプロイしたら、CloudWatch Query Studio を開くか、Amazon Managed Grafana ワークスペースで Explore に移動し、CloudWatch PromQL データソースを選択します。 以下のクエリは、Amazon Managed Grafana でデモアプリの p99 レイテンシーを、自動エンリッチされた @aws.region ラベルでグループ化して表示します。 histogram_quantile(0.99, sum by (le, aws_region) (rate(latency_time_bucket{resource_service_name="python-demo-app"}[5m])))` 図 7: Amazon Managed Grafana でのサンプルアプリケーションの P99 レイテンシー エンリッチメントが有効になっているため、すべてのアプリケーションメトリクスに AWS リソースコンテキストが自動的に付与されます。例えば、 cpu_usage をクエリすると、追加の計装なしで以下のラベルが返されます。 図 8: カスタム OTel 計装からのエンリッチされた全ラベルの表示 料金 OTLP 取り込み機能と PromQL クエリは、プレビュー期間中は追加料金なしで利用できます。現在の料金の詳細については、Amazon CloudWatch の 料金ページ をご覧ください。 このウォークスルーで使用した Amazon EKS と Amazon Managed Grafana のリソースは、標準料金で課金されます。継続的な課金を避けるため、ウォークスルー終了後は次のセクションのクリーンアップ手順に従ってください。 クリーンアップ サンプルアプリケーションを削除します。 kubectl delete -f demo-app.yaml EKS クラスターから Amazon CloudWatch Observability アドオンを削除します。 aws eks delete-addon \ --cluster-name \ --addon-name amazon-cloudwatch-observability Grafana ワークスペースから Prometheus データソースを削除します (Grafana コンソールにログインし、Data Sources に移動して、設定した CloudWatch PromQL データソースを削除します)。 Amazon Managed Grafana ワークスペースを削除します (このウォークスルー用に作成した場合のみ)。 aws grafana delete-workspace --workspace-id Amazon EKS クラスターを削除します (このウォークスルー用に作成した場合のみ)。 aws eks delete-cluster --name OTel エンリッチメントを無効にします (アカウントで不要になった場合)。 # Disable OTel enrichment aws cloudwatch stop-o-tel-enrichment # Disable telemetry enrichment aws observabilityadmin stop-telemetry-enrichment このウォークスルー用にアタッチした IAM ポリシーをデタッチします。 aws iam detach-role-policy \ --role-name \ --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy まとめ 本記事では、Amazon CloudWatch でのネイティブ OpenTelemetry メトリクス取り込みについて説明しました。エンリッチメントレイヤーの有効化、Amazon EKS への Container Insights のデプロイ、OpenTelemetry SDK でのカスタムアプリケーションメトリクスの送信、PromQL でのクエリを紹介しました。 このプレビュー機能により、メトリクスパイプラインを CloudWatch に統合できます。拡張されたラベル制限を持つ高カーディナリティメトリクス、PromQL クエリ、AWS リソースの自動エンリッチメントが連携し、インフラストラクチャメトリクス、コンテナメトリクス、アプリケーションメトリクスがすべて同じパイプラインを流れ、同じ AWS リソースコンテキストを持つようになります。別々のバックエンド、エクスポーター、AWS メトリクスを統合ビューに取り込むための追加 API 呼び出しは不要です。 OpenTelemetry を使ったアプリケーションレベルの計装の実践例については、以下のリソースをご覧ください。 AWS Observability Best Practices Guide:  OpenTelemetry SDK でアプリケーションを計装するパターン One Observability Workshop : AWS でのメトリクス、トレース、ログのハンズオンラボ AWS Observability Accelerator: テレメトリ収集とクエリを自動化する CDK パターンと Terraform モジュール プレビューは、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー) で追加料金なしで利用できます。開始するには、アカウントでエンリッチメントレイヤーを有効にし、Amazon EKS クラスターに CloudWatch Observability アドオンをデプロイしてください。 翻訳はソリューションアーキテクトの大西朔が担当しました。原文は こちら です。 著者について Rodrigue Koffi AWS のオブザーバビリティ担当スペシャリストソリューションアーキテクトです。オブザーバビリティ、分散システム、機械学習に情熱を持っています。DevOps とソフトウェア開発のバックグラウンドがあり、Go でのプログラミングを好みます。仕事以外では、水泳や家族との時間を楽しんでいます。LinkedIn: /grkoffi

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 4/14（火）にオンラインセミナー「 これから始める AWS のコンテナサービス活用 」を開催します。Amazon ECS や Amazon EKS をはじめとする AWS のコンテナ関連サービスの全体像をご紹介します。初めてコンテナを利用される方はもちろん、既にご利用中で最新機能をキャッチアップしたい方にもおすすめの内容です。ぜひ事前登録のうえご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年3月30日週の主要なアップデート 3/30(月) AWS Direct Connect が BGP 監視用の CloudWatch メトリクスを追加 AWS Direct Connect で BGP セッションを監視できる CloudWatch メトリクスが 3 つ追加されました。これまでカスタム Lambda 関数やオンプレミスのネットワーク管理ツールが必要だった BGP 監視が、CloudWatch で実現できるようになります。セッション状態やプレフィックス数を追跡し、障害検知や設定変更の検証が可能です。全ての商用リージョンで利用でき、CloudWatch アラームやダッシュボードと統合して Direct Connect の正常性を確認するためのモニタリング環境を構築できます。 Amazon SageMaker Data Agent が Amazon SageMaker Unified Studio Query Editor で利用可能になりました Amazon SageMaker Unified Studio の Query Editor で Data Agent が利用できるようになりました。これまではノートブックでのみ使えていた AI による会話型データ分析機能が SQL 分析ワークフローでも利用が出来るアップデートです。「2025年の製品カテゴリ別四半期売上成長率を計算して」のような自然言語の質問 (英語) から SQL クエリを自動生成し、エラーが発生した際は AI が修正案を提示してくれます。複雑な結合や集計処理を手動で書く必要がなくなり、データ分析の効率が大幅に向上します。詳細は こちらのドキュメントをご参照ください。 Amazon Athena が追加リージョンで Capacity Reservations を開始 Amazon Athena で Capacity Reservations が新たに、大阪を含めた 19 のリージョンで利用可能になりました。この機能は Athena の裏側のリソースを一定容量を確保でき、他のクエリの影響を受けずに安定したパフォーマンスを実現しやすくなります。同時実行クエリ数も制御できるため、予測可能な処理時間でデータ分析を行えます。詳細は こちらのドキュメントをご参照ください。 3/31(火) Amazon CloudFront が VPC IPAM 統合を通じて IPv6 の BYOIP をサポート開始 Amazon CloudFront で IPv6 の BYOIP (Bring Your Own IP) がサポートされました。これまでは IPv4 のみでしたが、VPC IPAM を利用して、IPv6 (/48) も BYOIP が利用できるようになりました。これにより、既存の IP アドレス空間を維持したまま CloudFront に移行でき、パートナーや顧客への IP アドレス提供がしやすくなります。セキュリティ強化とネットワーク管理の効率化が期待できます。詳細は こちらのドキュメントをご参照ください。 AWS Outposts での Amazon RDS for Oracle の発表 Amazon RDS for Oracle が AWS Outposts で利用可能になりました。これまでデータ所在地やコンプライアンス要件でクラウド移行が困難だった企業も、Outposts 上で管理された Oracle データベースを利用できます。自動バックアップやパッチ適用、CloudWatch 監視などクラウド同等の機能を提供し、マルチ AZ 配置で高可用性も実現します。詳細は こちらのドキュメントをご参照ください。 AWS Transform custom が自動化されたコードベース分析の一般提供開始 AWS Transform custom で自動コードベース分析機能が一般提供開始しました。Python や Java などの言語で書かれたコードを深く解析し、アーキテクチャや技術的負債を自動でドキュメント化します。これまで手作業で行っていたコードの現状把握や移行計画に役立ち、大規模なモダナイゼーションのための時間を短縮できます。100 万行を超える大規模アプリケーションにも対応し、古いコンポーネントを特定して優先度をつけた改善提案も行います。バージニア北部リージョンとフランクフルトリージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 Amazon CloudWatch Logs がルックアップクエリコマンドをサポート Amazon CloudWatch Logs Insights で新しい lookup コマンドが利用可能になりました。このコマンドにより、ログに含まれる ID や IP アドレスなどの機械的な文字列を、CSV ファイルから参照した意味のある情報 (顧客名やチーム名など) に変換して、クエリ結果をみやすくできます。これまでは前処理が必要でしたが、クエリ実行時に直接データを結合できるため、ログ分析がやりやすくなります。全商用リージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 AWS Backup が Amazon Redshift Serverless のサポートを 7 つのリージョンに拡大 AWS Backup が Amazon Redshift Serverless のサポートを大阪、ハイデラバード、台北、クアラルンプール、オークランド、ミラノ、ケープタウンの 7 つのリージョンに拡張しました。これまでこれらのリージョンでは利用できなかったポリシーベースの自動バックアップ機能が使えるようになり、データウェアハウスの保護と復旧が簡単になります。詳細は こちらの製品ページをご参照ください。 AWS Security Agent オンデマンドペネトレーションテストが一般提供開始 AWS Security Agent のオンデマンドペネトレーションテストが一般提供開始されました。従来は手動で定期的に実施していたセキュリティテストを、AI エージェントが 24 時間 365 日自動実行できるようになり、コストも大幅削減されます。脆弱性の発見から修復提案まで包括的にサポートし、マルチクラウド環境にも対応しています。東京リージョンなど 6 リージョンで利用可能で、2 ヶ月の無料トライアルも提供されます。 AWS Direct Connect が AWS CloudFormation をサポート開始 AWS Direct Connect が AWS CloudFormation に対応しました。これまで手動で構築していた Direct Connect のネットワーク環境を、コードで管理できるようになります。CloudFormation テンプレートで接続設定や仮想インターフェース、Direct Connect ゲートウェイなどを定義し、他の AWS リソースと一緒に自動デプロイが可能です。全リージョンで利用可能で、ネットワーク運用の効率化が期待できます。詳細は こちらのドキュメントをご参照ください。 AWS DevOps Agent が一般提供開始 AWS DevOps Agent が一般提供開始となりました。このサービスは AI を活用して障害の調査や解決を自動化する仕組みです。従来は手動で行っていた障害対応を自動化することで、平均復旧時間 (MTTR) を数時間から数分に短縮できる場合があります。AWS だけでなく Azure やオンプレミス環境にも対応し、カスタムレポート機能やスキル拡張も可能になりました。AWS Support を利用しているお客様には月次クレジットが提供され、多くの場合コストを大幅に削減できます。詳細は こちらの Blog 記事をご参照ください。 Amazon ECS Managed Instances が Amazon EC2 インスタンスストアをサポート Amazon ECS Managed Instances が EC2 instance store ボリュームに対応しました。これまでは Amazon EBS データボリュームを使う必要がありましたが、今回のアップデートで instance store ボリュームを選択できるようになりました。これによりストレージコストの削減と I/O パフォーマンスの向上を実現でき、特にレイテンシに敏感なワークロードでメリットがあります。詳細は こちらのドキュメントをご参照ください。 AWS が End User Messaging Notify を発表 AWS が新サービス AWS End User Messaging Notify を発表しました。従来、ワンタイムパスコード (OTP) の送信には電話番号取得が必要で、時間がかかる場合がありました。新しいサービスの AWS End User Messaging Notify では、AWS が所有する電話番号を利用できるため、素早く実現できるうれしさがあります。 200 以上の国に SMS や音声で OTP を送信でき、詐欺防止機能も標準搭載されています。ブランド名やコード形式のカスタマイズも可能で、利用制限設定により予想外のコスト発生も防げます。詳細は こちらのユーザーガイドをご参照ください。 Amazon S3 Vectors が 17 の追加 AWS リージョンに拡張 Amazon S3 Vectors が新たに 17 リージョンで利用可能になり、合計 31 リージョンで提供開始となりました。S3 Vectors は AI アプリケーション向けのベクトルデータを効率的に格納・検索できるサービスで、従来のベクトルデータベースと異なり S3 の高い可用性と耐久性を活用できます。RAG (検索拡張生成) やセマンティック検索などの AI 用途で、最大 20 億ベクトルを 100 ミリ秒の低レイテンシで処理可能です。詳細は こちらのドキュメントをご参照ください。 Amazon OpenSearch Service がログ分析のためのエージェント AI を導入 Amazon OpenSearch Service で agentic AI 機能が利用開始となりました。従来はログ分析にクエリ言語の習得が必要でしたが、今回のアップデートで自然言語での質問やインシデント調査の自動化が可能になります。チャット機能では PPL クエリを自動生成し、調査エージェントが根本原因分析を自律的に実行して仮説を提示します。会話履歴も保持されるため、継続的な分析作業が効率化されます。追加料金なしで東京リージョンを含む 9 リージョンで提供中です。詳細は こちらのドキュメントをご参照ください。 4/1(水) Oracle Database@AWS が高性能アプリケーション向けにサブミリ秒のネットワークレイテンシを提供開始 Oracle Database@AWS でサブミリ秒のネットワークレイテンシを提供開始しました。支払い処理や証券取引など、低遅延が求められるアプリケーションで特にメリットがあります。EC2 インスタンスの配置を最適化することによってこの仕組みを実現しました。追加料金は不要です。オハイオ、カナダ中部、フランクフルト、ダブリン、東京、シドニーリージョンで利用可能で、今後拡大予定です。詳細は こちらのドキュメントをご参照ください。 Amazon SES Mail Manager がセキュリティ強化とメール処理のための新機能を追加 Amazon SES Mail Manager でセキュリティに関する機能にアップデートがあります。これまで、SES Mail Magaer を利用する際に TLS (STARTTLS) の利用が必要でしたが、TLS の利用がオプションになり、これまで難しかったレガシーシステムから利用しやすくなります。また、クライアント証明書を利用した相互認証の mTLSが利用できるようになりました。中東 (UAE・バーレーン) を除く全リージョンで利用可能です。詳細は こちらをご参照ください。 4/2(木) Amazon WorkSpaces Applications がマルチセッションフリート管理を改善 Amazon WorkSpaces Applications で multi-session fleet のドレインモード機能が追加されました。この機能により、既存のユーザーセッションを中断することなく、新しいセッション受付を停止できるようになります。従来はメンテナンスやアップデート時に、既存のセッションを強制終了する必要がありましたが、今回のアップデートでユーザーの作業を妨げずにシステム管理をしやすくなりました。管理者は計画的にインスタンスを空にでき、新しい接続は他のインスタンスに自動転送されます。詳細は こちらのドキュメントをご参照ください。 Amazon ElastiCache Serverless が IPv6 およびデュアルスタック接続をサポート Amazon ElastiCache Serverless が IPv6 とデュアルスタック接続に対応しました。従来は IPv4 のみでしたが、今回のアップデートで IPv4、IPv6、デュアルスタックの 3 つのネットワークタイプから選択できるようになりました。デュアルスタック接続では IPv4 と IPv6 の両方を同時に利用でき、IPv6 移行時も既存アプリケーションとの互換性を保ちながら段階的な移行が可能です。IPv6 専用サブネットも使用でき、コンプライアンス要件にも対応できます。全 AWS リージョンで追加料金なしで利用可能です。詳細は こちらのドキュメントをご参照ください。 4/3(金) Amazon CloudWatch が Query Studio プレビューで PromQL クエリを導入 Amazon CloudWatch で Query Studio がパブリックプレビューとして提供開始されました。これまで CloudWatch では PromQL クエリが利用できませんでしたが、今回のアップデートで利用できるようになり、PromQL と CloudWatch Metric Insights を統一インターフェースで使用できるようになりました。例えば EC2 上で動作するアプリケーションの OpenTelemetry メトリクスと AWS 標準メトリクスを横並びで分析し、スタック全体の問題を素早く特定できます。バージニア北部、オレゴン、シドニー、シンガポール、アイルランドリージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

はじめに 分散ワークロードを運用するチームは、根深い運用上の課題に直面しています。障害が発生した際、解決に必要な情報はログ、デプロイパイプライン、設定変更履歴、サードパーティの監視ツールなど、あちこちに散在しています。深夜2時にアラートで呼び出された Site Reliability Engineer (SRE) は、複数のソースからテレメトリを手動で突き合わせ、サービス間の依存関係をトレースし、仮説を立てなければなりません。この作業には通常、数時間を要します。システムの複雑さが増すにつれ、AI を活用した運用チームメンバー、すなわち SRE 支援エージェントの必要性がますます明確になっています。 自前で構築する (DIY) アプローチとその限界 この領域を模索するチームは、まず普段使いの AI コーディングツールを調査中に活用することから始めることが多いでしょう。大規模言語モデル (LLM) に薄くインターフェースを被せただけのツールです。オンコールエンジニアは起床後、インシデントの詳細やチケットを確認し、コーディングツールにログや監視ツールへのアクセスを与えて調査を開始させます。このアプローチは単純なシナリオでは価値を発揮しますが、実際の大規模アプリケーションアーキテクチャでは、複数アカウント、監視システム、アプリケーショントポロジーにまたがるコンテキストの把握、ガバナンスとアクセス制御の適用、過去のインシデントからの学習の蓄積が必要であり、本格的なインシデント管理には力不足です。環境が拡大するにつれ、限られたコンテキストしか持たないシンプルなコーディングツールと、本番環境レベルの運用エージェントとの差は広がる一方です。 フルマネージド型の代替ソリューション AWS DevOps Agent は、常に利用可能な運用チームメンバーです。インシデントの解決とプロアクティブな 予防 を行い、アプリケーションの信頼性とパフォーマンスを最適化し、AWS、マルチクラウド、オンプレミス環境にわたる オンデマンド SRE タスク を処理します。DevOps Agent は包括的なエージェント型 SRE パラダイムを提供し、チームをリアクティブな消火活動からAI を活用したプロアクティブな運用改善へと導きます。 では、AWS DevOps Agent はSRE が個人でコーディングエージェントを使う場合と何が違うのでしょうか？この記事では、AWS 上のサーバーレス URL 短縮サービスアプリケーションを例に、DevOps Agent が トポロジーインテリジェンス 、3 階層のスキル体系、クロスアカウント調査、継続的学習を基盤として、単純な LLM ラッパーでは再現できない能力を発揮し、平均復旧時間 (MTTR) を数時間から数分に短縮する真の運用チームメンバーとして機能する様子をご紹介します。 前提条件 DevOps Agent を使い始める前に、以下を確認してください。 対応する AWS サポートプランが有効な AWS アカウント (サポート対象のティアについては AWS アカウントチームにお問い合わせください) クロスアカウントオブザーバビリティを設定するための適切な IAM 権限 サポート対象リージョン にデプロイされた AWS サービス Amazon CloudWatch と AWS CloudTrail (デフォルトで有効) 機能強化のための追加 インテグレーション : チケット管理用の ServiceNow 、チーム通知用の Slack 、オンコール管理用の PagerDuty アプリケーション概要 あなたは、AWS 上にデプロイされた URL 短縮サービスを提供する SaaS 企業の SRE です。このアプリケーションは完全な サーバーレスアーキテクチャ を採用しており、ショートコードの作成、元の URL へのリダイレクト、アナリティクスの追跡を行います。 Amazon CloudFront が Amazon S3 バケットから静的アセットを配信 Amazon API Gateway が API リクエストを AWS Lambda 関数にルーティング Amazon DynamoDB が Lambda 関数からアクセスされる URL マッピングを保存 図 1. URL 短縮サービスアプリケーション このアーキテクチャの構築は簡単ですが、トラブルシューティングは複雑です。リダイレクト関数のレイテンシスパイクは、DynamoDB のスロットリング、Lambda のコールドスタートの劣化、API Gateway の設定変更、CloudFront のキャッシュ無効化など、さまざまな原因が考えられます。しかも、それぞれのシグナルは異なるロググループ、メトリクス名前空間、トレーススパンに存在します。このような状況こそ、DevOps Agent が 自律的 な運用チームメンバーとしての価値を発揮するポイントです。 調査の実際の流れ このワークフローでは、DevOps Agent が人間の介入なしにわずか 4分で本番インシデントを自律的に検出・診断する様子を示しています。CloudWatch アラームが 5xx エラーの増加により発報されると、順を追って仮説を検証し、最近のコードデプロイに起因する DynamoDB の書き込みスロットリングを特定します。その後、DevOps Agent は問題のあるコミットを含む完全な根本原因分析と具体的な緩和策の推奨事項 (オンデマンドキャパシティへの切り替えまたはロールバックの提案) を自律的に Slack に投稿します。初回アラームから実行可能な解決策の提示まで、すべてが 5分以内に完了します。 図 2. 論理的な調査ワークフロー 図 3. AWS DevOps Agent の調査ワークフロー: 初期インシデント検出から根本原因分析、実行可能な緩和策の推奨までの自動化フロー DevOps Agent が異なる理由 DevOps Agent は大規模言語モデルの上にチャットインターフェースを被せたものではありません。 Amazon Bedrock AgentCore 上に構築されており、メモリ、ポリシー、評価、オブザーバビリティのための専用インフラストラクチャを備えています。以下では、DevOps Agent を次世代の完全な運用チームメンバーたらしめる 6 つの主要な能力「6 つの C」を解説します。 1. Context (コンテキスト) 運用コンテキストを持たない LLM は、一般的な提案しかできません。DevOps Agent は Agent Spaces によってこの課題を解決します。Agent Spaces は、クラウドリソース、テレメトリソース、コードリポジトリ、CI/CD パイプライン、チケットシステムへのクロスアカウントアクセスを提供する、分離された論理コンテナです。各 Agent Space 内で、DevOps Agent はリソース (コンテナ、ネットワークコンポーネント、ロググループ、アラーム、デプロイメント) を自動検出し、AWS、 Azure 、オンプレミス環境にまたがる相互接続をマッピングすることで、アプリケーションリソーストポロジーを構築します。バックグラウンドでは 学習エージェント が稼働し、インフラストラクチャ、テレメトリ、コードを分析して、推定されたアプリケーションとサービス間のトポロジーを生成します。DevOps Agent は Amazon Elastic Kubernetes Service (EKS) などのサービスとの深い AWS ネイティブ インテグレーション を維持しており、パブリックおよび プライベート 環境の Kubernetes クラスター、Pod ログ、クラスターイベントへのイントロスペクションを提供します。これは外部ツールにはない特権アクセスを必要とする機能です。DevOps Agent はリソーストポロジーだけでなく、テレメトリ、デプロイタイムライン、インフラストラクチャおよびアプリケーションコードも把握しています。リソース、アラーム、メトリクス、ロググループ間の関係を検出・把握します。レイテンシスパイクを検出すると、 GitHub 、 GitLab 、Azure DevOps の最近のマージを自動的にチェックし、デプロイのタイムスタンプとメトリクスの異常を相関させ、コード変更が原因である可能性を判断します。URL 短縮サービスの例では、エージェントは DynamoDB のバッチ書き込みを追加するコミットがスロットリング開始の 47 分前にデプロイされたことを特定します。これは人間の SRE なら発見に 30 分かかってもおかしくない相関です。 URL 短縮サービスの場合 、DevOps Agent は CloudFront から API Gateway を経由して各 Lambda 関数、さらに DynamoDB テーブルまでの依存関係チェーンをマッピングします。URL リダイレクト関数でレイテンシスパイクが発生すると、エージェントは関係グラフをトレースして、根本原因が DynamoDB の読み取りスロットリングなのか、Lambda の同時実行数制限なのか、API Gateway のタイムアウト設定なのかを判断します。CloudWatch メトリクス、Lambda トレース、DynamoDB の消費キャパシティを単一の調査で相関させます。 2. Control (制御) コンテキストだけではガバナンスなしにリスクが生じます。Agent Spaces は、エージェントがアクセスできる範囲と動作方法を一元的に制御します。管理者は、各 Agent Space 内で利用可能な AWS および Azure アカウント、テレメトリおよびコードインテグレーション、 MCP サーバー を、きめ細かい IAM 権限 を使用して定義します。これにより、個々の開発者が独自のツールチェーンを設定する際の不整合 (徹底的に設定する人、部分的にしか設定しない人、まったく設定しない人) が解消され、新しいチームメンバーのためのアドホックなオンボーディングプロセスも不要になります。すべての推論ステップとアクションは、エージェントが記録後に変更できない不変の監査ジャーナルに記録され、意思決定の完全な 透明性 を提供します。AWS DevOps Agent は初日からセキュリティが確保されており、すべての推論ステップとツール呼び出しを記録する不変の監査証跡、AWS CloudTrail との統合、きめ細かい権限を持つ IAM Identity Center 認証、調査データを分離し組織の セキュリティ 設定を尊重する Agent Space レベルのデータガバナンスを備えています。 URL 短縮サービスの場合 、管理者は本番アカウントの CloudWatch ログ、DynamoDB テーブルメトリクス、GitHub リポジトリ、インシデント調整用の Slack チャンネルへの読み取りアクセスを持つ単一の Agent Space を設定します。チームのすべての SRE がこの一貫した制御された設定を継承し、個別のセットアップは不要です。 3. Convenience (利便性) Agent Space が設定されると、チームのすべての開発者と SRE は、トポロジー、テレメトリ、コードリポジトリ、チケットインテグレーションといったエージェントの完全な運用コンテキストに、追加のセットアップなくすぐにアクセスできます。これは、各エンジニアが個別にコーディングエージェントを CloudWatch、オブザーバビリティツール、ソースリポジトリ、チケットシステムの Model Context Protocol ( MCP ) サーバーに接続する従来のアプローチとは大きく異なります。実際には、セットアップを完了するエンジニアもいれば、部分的にしか設定しないエンジニアもおり、まったく設定しないエンジニアもいます。結果として、チーム全体でツールの不整合が生じ、新入社員のたびにオンボーディングの負担が発生します。DevOps Agent では、管理者が Agent Space を一度設定すれば、エンジニアは オペレーター Web アプリ にログインするか、Slack を通じてやり取りするだけです。エージェントはコンテキストを考慮した応答を提供し、会話履歴を維持し、ユーザーごとのセットアップなしでアプリケーショントポロジーに対する自然言語クエリをサポートします。 URL 短縮サービスチームの場合 、オンコールローテーションに新しく参加する SRE は、3 つの Lambda 関数のロググループ、DynamoDB メトリクスダッシュボード、GitHub リポジトリへのアクセスを設定するのに丸一日費やす必要はありません。Agent Space にログインして「この DynamoDB テーブルに接続されているすべての Lambda 関数を表示して」と聞くだけで、トポロジー、テレメトリアクセス、コードコンテキストがすでに揃っています。 図 4. AWS DevOps Agent の MCP サーバーおよびコミュニケーションインテグレーション 図 5. AWS DevOps Agent のテレメトリインテグレーション 図 6. AWS DevOps Agent のマルチクラウドおよびパイプラインインテグレーション 4. Collaboration (コラボレーション) DevOps Agent は受動的な Q&A ツールではなく、自律的なチームメンバーです。CloudWatch アラーム、PagerDuty アラート、Dynatrace Problem、ServiceNow チケット、または Webhook で設定したその他のイベントソースを通じてインシデントがトリガーされると、エージェントは人間のプロンプトなしに即座に調査を開始します。仮説を生成し、テレメトリおよびコードデータソースにクエリを実行して検証し、コラボレーションチャネル全体で調整を行います。Slack に調査タイムラインを投稿し、ServiceNow チケットを更新し、関係者に調査結果をルーティングします。MCP による拡張性と、CloudWatch、 Datadog 、 Dynatrace 、 New Relic 、 Splunk 、 Grafana 、GitHub、GitLab、Azure DevOps との 組み込みインテグレーション により、チームの運用データがどこにあっても、エージェントはシグナルを取得できます。エージェントはまた、週次で予防的な改善提案も行い、最近のインシデントを分析して、コード最適化、オブザーバビリティカバレッジ、インフラストラクチャのレジリエンス、ガバナンスプラクティスにわたる具体的な改善を提案します。さらに、DevOps Agent はより広範なフロンティアエージェントエコシステム内で動作し、調査結果には Kiro が修正を実装するためのエージェント対応の指示を含めることができます。 URL 短縮サービスで深夜3時に DynamoDB スロットリングイベントが発生した場合 、DevOps Agent はアラームを検出し、自律的に調査を行い、トラフィックスパイクがテーブルのプロビジョンドキャパシティを超えたことを特定し、緩和策を Slack に投稿します。これらすべてが、オンコールエンジニアがページの内容を読み終える前に完了します。週次の予防評価では、オンデマンドキャパシティモードへの切り替えと、将来のスパイクを早期に検出するための ConsumedWriteCapacityUnits に対する CloudWatch アラームの追加を推奨します。 図 7. AWS DevOps Agent の Slack 調査通知 図 8. AWS DevOps Agent の Ops Backlog における予防推奨 5. Continuous Learning (継続的学習) ここが AWS DevOps Agent がLLM を薄くラップしただけのツール (LLM ラッパー) と最も明確に差別化されるポイントです。エージェントは洗練された 3 階層の スキル体系 を実装しています。 AWS 提供スキル – AWS のエンジニアとサイエンティストが開発した組み込み機能で、実証済みの運用アプローチを反映し、内部で継続的にメンテナンスされています。 ユーザー定義スキル – 組織固有のコンテキストやワークフローに合わせてエージェントをより効果的に動作させるために定義するカスタムスキルです。 学習済みスキル – バックグラウンドで継続的に動作する AWS DevOps Agent の学習サブエージェントは、2 つの重要な機能を実行します。第一に、クラウドインフラストラクチャ、テレメトリデータ、コードリポジトリをスキャンして、アプリケーショントポロジーを継続的に学習・更新します。リソースとその関係を理解し、特定のアラームに関連する重要なログを絞り込むのに役立ちます。第二に、過去の調査を分析してパターンを特定し、将来のトラブルシューティングワークフローを最適化することで、時間とともにより効果的になります。 URL 短縮サービスの場合 、DevOps Agent が 1 か月間に 3 件の DynamoDB スロットリングインシデントを解決した後、学習エージェントは繰り返しパターンを特定し、同じクラスの将来の調査を加速する学習済みスキルを生成します。次にスロットリングが発生した際、エージェントは探索的な仮説をスキップし、プロビジョンドキャパシティと消費キャパシティを即座にチェックすることで、調査時間をさらに短縮します。SRE チームはカナリアデプロイプロセスを記述したランブックもアップロードでき、エージェントは最近のデプロイがインシデントと相関するかどうかを評価する際にこれを参照します。 図 9. AWS DevOps Agent のユーザー定義スキルと学習済みスキル 6. Cost Effective (コスト効率) 独自のエージェントを構築することもできますが、消費するモデルトークンの費用はかかります。さらに重要なのは、エージェントとそのインテグレーションの開発、保守、運用を行うチームを配置する必要があることです。基盤モデルの変更に伴い、モデルの品質、レイテンシ、コストを定期的に評価する必要もあります。AWS DevOps Agent では、これらすべてを AWS のエンジニアとサイエンティストのチームが代行します。 DevOps Agent は使用量ベースの料金体系を採用しており、エージェントがタスクに積極的に取り組んでいる時間に対してのみ課金されます。シートごとのライセンス料やアイドルインフラストラクチャのコストはありません。エージェントはマシンスピードで動作し、人間のエンジニアが数時間かかる調査を数分で完了し、実際のアクティブな計算の秒数に対してのみ課金されます。 内部的には、DevOps Agent はコストを削減しながら精度を向上させる大幅なデータ取得最適化を採用しています。ツール全体にわたるクエリ最適化技術により、AWS 固有のアクセスパターンとデータ特性を活用して、大規模データセット全体で最大 15 倍高速なクエリを実現します。これらの最適化により、エージェントは調査ごとの計算消費を抑えながら、より正確な結果を提供します。これは、汎用的な LLM ラッパーでは再現できない、深い AWS インテグレーションの直接的なメリットです。 URL 短縮サービスの場合 、SRE が 3 つの Lambda 関数のロググループにわたって CloudWatch Logs Insights を手動でクエリし、DynamoDB メトリクスと相関させるのに 2 時間費やす代わりに、DevOps Agent は最適化されたクエリを使用して同じ調査を数分で完了します。エンジニアリング時間のコストのほんの一部で済みます。 実証済みの実績 プレビューで AWS DevOps Agent を使用しているお客様やパートナーは、MTTR の最大 75% 削減、調査の 80% 高速化、根本原因の特定精度 94%を報告しており、3〜5 倍のインシデント解決速度を実現しています。 Western Governors University(WGU) は、191,000 人以上の学生にサービスを提供する大手オンライン大学であり、Amazon DevOps Agent を本番環境にデプロイした最初の組織の一つです。re:Invent でのプレビュー開始よりも前にデプロイを行いました。大規模な Dynatrace ユーザーである WGU は、DevOps Agent のネイティブ Dynatrace インテグレーションを活用し、Dynatrace Intelligence が問題レコードを自動的にエージェントにルーティングして調査を行い、充実した調査結果を Dynatrace に直接返すことを可能にしています。 最近の本番調査では、WGU の SRE チームが AWS DevOps Agent を使用してサービス中断シナリオを分析し、推定 2 時間の解決時間をわずか 28 分に短縮しました。MTTR が 77% 改善されたことになります。AWS DevOps Agent は AWS Lambda 関数の設定内の根本原因を迅速に特定し、それまで発見されていなかった社内ドキュメントにのみ存在していた重要な運用知識を表面化させました。 Zenchef は、レストランが予約、テーブル運営、デジタルメニュー、決済、ゲストマーケティングを手数料無料の単一システムから管理できるレストランテクノロジープラットフォームです。少数精鋭の DevOps チームが複数のビジネスユニットにわたる複数の本番環境を管理する中、社内ハッカソン中にダウンストリームパートナーに影響する API インテグレーションの問題が浮上しました。エンジニアはイベントに参加しており、監視では問題の方向性を示す重要な兆候は見られませんでした。 ハッカソンからエンジニアを引き抜く代わりに、チームは問題を AWS DevOps Agent に持ち込みました。エージェントは体系的に問題に取り組み、認証を原因から除外し、調査の焦点を Amazon Elastic Container Service (Amazon ECS) のデプロイメントに移し、最終的にデータベース内の認識されない enum 値を新バージョンが処理できなかったコードリグレッションに根本原因をトレースしました。調査全体は 20〜30 分で完了し、手動で行った場合の 1〜2 時間と比較して約 75% の削減となりました。調査結果は担当エンジニアに直接共有されました。 まとめ AWS DevOps Agent は、アーキテクチャ的に LLM ラッパーとは異なります。その トポロジーインテリジェンス サービスは AWS サービスの関係をマッピングし、アプリケーションの依存関係を理解します。検証ベースの学習エージェントを備えた 3 階層のスキル体系は、各顧客環境に固有の複合的な運用知識を生み出します。クロスアカウント調査機能、ガバナンス付き自律モデル、不変の監査証跡は、外部ラッパーでは満たせないエンタープライズ要件に対応します。 6 つの C「Context (コンテキスト)、Control (制御)、Convenience (利便性)、Collaboration (コラボレーション)、Continuous Learning (継続的学習)、Cost Effective (コスト効率) 」 はマーケティング上のカテゴリではありません。これらは具体的なエンジニアリング投資を表しています。分離のための Agent Spaces、トポロジー、パフォーマンスのための最適化されたログクエリ、クロスアカウントアクセスのためのフェデレーテッド認証情報管理、そして調査のたびに学習し改善するスキルアーキテクチャです。AWS 上で分散型の複雑なアーキテクチャアプリケーションを運用するすべてのチームにとって、DevOps Agent はインシデント対応の運用負荷を軽減しながら、将来のすべての調査をより迅速かつ正確にする組織的知識を構築します。 始める準備はできましたか？ AWS DevOps Agent ドキュメント でセットアッププロセスを確認し、 AWS DevOps Agent ワークショップ でハンズオン体験を行い、AWS アカウントチームに連絡して最初の Agent Space を設定してください。 著者について Tipu Qureshi Tipu Qureshi は AWS Agentic AI の Senior Principal Technologist で、運用エクセレンスとインシデント対応の自動化に注力しています。AWS のお客様と協力して、レジリエントでオブザーバブルなクラウドアプリケーションと自律的な運用システムを設計しています。 Bill Fine Bill Fine は AWS の Agentic AI Product Management Leader で、AWS DevOps Agent の製品戦略と顧客エンゲージメントを統括しています。 Joe Alioto Joe Alioto は、オブザーバビリティと AWS 上の一元化された運用管理に焦点を当てたクラウドオペレーションの World Wide Senior Specialist Solutions Architect です。20 年以上のハンズオン運用エンジニアリングとアーキテクチャの経験を持っています。仕事以外では、家族との時間を楽しみ、新しいテクノロジーの学習や PC ゲームを趣味としています。 Janardhan Molumuri Janardhan Molumuri は AWS の Principal Technical Leader で、20 年以上のエンジニアリングリーダーシップ経験を持ち、クラウドと AI の導入戦略や生成 AI を含む新興技術についてお客様にアドバイスしています。ソートリーダーシップ、講演、執筆に情熱を持ち、大規模な課題解決のためのテクノロジートレンドの探求を楽しんでいます。 本ブログは 2026 年 3 月 31 日に公開された Leverage Agentic AI for Autonomous Incident Response with AWS DevOps Agent  の日本語訳です。翻訳はテクニカルアカウントマネージャーの日平が行いました。

2026 年 03 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS Black Belt Online Seminar 一覧 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 Amazon SageMaker 基礎編 Amazon SageMaker は、分析と AI との統合エクスペリエンスを提供し、統合開発環境の Amazon SageMaker Unified Studio、オープンなレイクハウスアーキテクチャ、データと AI のガバナンスから構成されます。 本セミナーでは、Amazon SageMaker 基礎編として、Amazon SageMaker の全体像と、Amazon SageMaker Unified Studio の各種機能とガバナンスについて解説しています。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS クラウドを活⽤したデータ基盤、AI 基盤を担当する方 生成 AI の本格活用に備えてデータ活用、分析環境の整備を検討されようとしている方 Amazon SageMaker に関心のある、ご利用予定の方 本 BlackBelt で学習できること Amazon SageMaker の全体像、および Amazon SageMaker Unified Studio の各種機能とガバナンス スピーカー 平井 健治、北里 知也 ソリューションアーキテクト、クラウドサポートエンジニア AWS re:Invent 2025 re:Cap Compute 編 AWS re:Invent 2025 で発表された Compute 関連の主要アップデートをまとめて解説するセッションです。AWS Graviton5 搭載の M9g インスタンスや、新たに発表された Nitro Isolation Engine など、AWS のコンピューティング基盤における最新の進化をキャッチアップできます。AWS re:Invent 2025 の Compute セッションを効率よく振り返りたい方におすすめの内容です。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon EC2 の基本的な概念（インスタンスタイプなど）を理解されている方を対象としています。AWS Graviton や Nitro System といったキーワードを聞いたことがある程度の前提知識があるとスムーズに理解いただけます。 本 BlackBelt で学習できること AWS Graviton5 や新たに発表された Nitro Isolation Engine について学ぶことができます。また、AWS re:Invent 2025 の Compute 関連セッションの全体像を把握し、さらに深掘りしたいテーマへの導線を得ることができます。 スピーカー 池田 優 ソリューションアーキテクト AWS re:Invent 2025 re:Cap HPC on AWS 編 2025 年 12 月に開催された AWS 最大のカンファレンス re:Invent で発表されたアップデートを HPC on AWS の観点からご紹介します。re:Invent で発表された HPC ワークロードでお使いいただける新しい Amazon EC2 インスタンス、HPC 関連サービスのアップデート、関連する事例セッションについてご紹介します。また、まだ HPC on AWS を利用されたことがない方に向けて、その概要についてもご説明しています。 資料（ PDF ） | 動画（ YouTube ） 対象者 re:Invent 2025 の HPC on AWS 関連アップデート・セッションを知りたい方 HPC 環境を AWS 上で構築したいと考えている方 AWS 上の HPC 環境をより効果的に活用したい方 本 BlackBelt で学習できること HPC on AWS 概要 HPC 関連 re:Invent 2025 アップデート HPC 関連 EC2 インスタンス 2025 年のアップデート HPC 関連サービス 2025 年のアップデート スピーカー 杉山 遼子 ソリューションアーキテクト Amazon ECS マネージドインスタンス 2025 年9月に発表された Amazon Elastic Container Service マネージドインスタンスについて、基本的な仕組みと使い方をまとめています。起動タイプの第３の選択肢として、マネージドインスタンスをぜひご活用ください。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon ECS の概要を理解されている方 Fargate の運用容易性と EC2 の柔軟性のトレードオフに直面している方 既存ワークロードのコンテナ化を検討している⽅ 本 BlackBelt で学習できること Fargate と EC2 の利点を兼ね備えた、第3の選択肢となるマネージドインスタンスの概要及び特徴が学べます。 スピーカー 桐生 宜昭 テクニカルアカウントマネージャー AWS Organizations 基礎編 AWS Organizations を利用することで無償で複数の AWS アカウントを一元管理することができます。本セミナーでは AWS Organizations の機能機能や他の AWS サービスとの連携についてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS Organizations をご利用でない方 AWS Organizations の一部の機能のみご利用中の方 本 BlackBelt で学習できること AWS 環境におけるマルチアカウント構成のメリットを理解する AWS Organizations の機能概要を把握する 他の AWS サービスとの連携について知る スピーカー 神原 滉一 クラウドサポートエンジニア AWS DevOps Agent(Preview) – 運用チーム編 – 本資料は、AWS Black Belt Online Seminar「AWS DevOps Agent (Preview) – 運用チーム編」の資料です。AWS DevOps Agent は、インシデントを自律的に解決・予防するフロンティアエージェントです。運用チームがどのように AWS DevOps Agent を活用できるかを、具体的なシナリオを交えながら解説します。 資料（ PDF ） 対象者 システムの保守・運用(インシデント/障害対応など)の業務を担当されている方。AWS DevOps Agent に関心がある、またはご利用予定の方 本 BlackBelt で学習できること 本 AWS Black Belt Online Seminar では、AWS DevOps Agent を活用した運用チームによるインシデント対応・予防の実践方法を学習できます。サーバーレスアプリケーション、GitHub Actions を用いた CI/CD パイプライン、Amazon EKS といった代表的な構成での障害調査・復旧シナリオを通じて、MTTR（平均復旧時間）の短縮や再発防止策の立案方法を習得できます。また、運用チーム向け Web App の操作方法についても理解を深めることができます。 スピーカー 古野 俊広 クラウドサポートエンジニア Amazon Connect Customer Profiles による C360 の実現とマーケティング活動での活用 Amazon Connect Customer Profiles は、複数のシステムに分散した顧客情報を統合し、360 度の顧客ビュー（C360）を実現するサービスです。 本セミナーでは、EC サイトやコンタクトセンターなど様々なデータソースから顧客情報を統合し、パーソナライズされたマーケティング活動に活用する方法を、実際のデモを交えてご紹介します。 アイデンティティ解決機能による重複レコードの統合、計算属性による自動的なビジネス指標の算出、Amazon Bedrock を活用した AI 支援セグメンテーションなど、実践的な機能を詳しく解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 本セミナーは、IT マーケティングの検討・実装を担当される方、カスタマーセンターのシステム構築に携わる方を対象としています。 特に、サイロ化された顧客情報の統合に課題を感じている方や、Amazon Connect を既に利用しているが Customer Profiles はまだ活用していない方に最適な内容です。 顧客データの統合やパーソナライゼーション施策に関する基本的な知識があると、より理解が深まります。 本 BlackBelt で学習できること 本セミナーでは、Amazon Connect Customer Profiles を使った顧客 360 度ビューの実現方法を学習できます。 具体的には、オブジェクトタイプマッピングによる外部データの統合手法、ルールベースおよび機械学習を用いたアイデンティティ解決による重複顧客レコードの統合、購買総額や問い合わせ頻度などのビジネス指標を自動計算する計算属性の活用方法を習得できます。 さらに、Amazon Bedrock を活用した自然言語ベースの顧客セグメント作成とトレンド分析、Amazon AppFlow、Amazon Kinesis、Amazon EventBridge を使ったデータ統合アーキテクチャの設計についても理解を深めることができます。 スピーカー 松本和久・髙橋 伸幸 ソリューションアーキテクト AWS re:Invent 2025 re:Cap インダストリー編 – 流通小売・消費財業界からみた注目サービス AWS re:Invent 2025 で発表された Agentic AI サービスの中から、流通小売・消費財業界の業務に変革をもたらすサービスをピックアップして紹介します。店舗運営・分析企画では Amazon Quick による分析業務の統合・効率化、コンタクトセンターでは Amazon Connect AI agents によるリアルタイム支援とコールサマリー自動生成、基幹業務では Amazon Bedrock AgentCore による AI エージェントの本番運用基盤について、具体的なユースケースとともに解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 流通小売・消費財業界で Agentic AI サービスの導入や業務効率化を検討されているビジネスリーダーおよび技術担当者の方を対象としています。AWS re:Invent 2025 で発表された注目サービスのポイントを効率的にキャッチアップしたい方にもおすすめです。前提知識として、Amazon Quick、Amazon Connect、Amazon Bedrock などの AWS サービスの概要を把握されていると、より理解が深まります。 本 BlackBelt で学習できること 流通小売・消費財業界の主要業務（店舗運営・分析企画、コンタクトセンター、基幹業務）において、Agentic AI サービスがどのような変革をもたらすかを具体的なユースケースとともに学ぶことができます。Amazon Quick の Spaces ・ Quick Flows ・ Quick Research ・ Chat Agents による分析業務の統合・効率化、Amazon Connect AI agents によるコールセンターの一次対応自動化やコールサマリー自動生成、Amazon Bedrock AgentCore の Gateway ・ Runtime ・ Observability ・ Policy ・ Evaluations による AI エージェントの本番運用に必要な機能を体系的に理解できます。 スピーカー 櫻井良 ソリューションアーキテクト AWS re:Invent 2025 re:Cap インダストリー編 – 流通小売・消費財業界向け NRF 2026 現地レポート NRF 2026（全米小売業協会カンファレンス）の現地レポートをお届けします。 AI Agent が社内業務から顧客接点まで全領域に浸透するトレンドを、顧客事例セッションや AWS ブースのデモを交えて解説します。 AWS ブースでは Amazon Bedrock と Amazon Bedrock AgentCore を活用したマルチエージェントシステムのデモとして、製品イノベーション（Luggage Lab）、サプライチェーン障害対応、Agentic Commerce、コスメ提案エージェントなどが展示されました。 資料（ PDF ） | 動画（ YouTube ） 対象者 流通小売・消費財業界で AI 活用やデジタルトランスフォーメーションを検討されている方を対象としています。 Agentic AI やマルチエージェントシステムといった最新の AI トレンドに関心のあるビジネス・技術担当者にもおすすめです。 本 BlackBelt で学習できること NRF 2026 で見られた流通小売・消費財業界における AI Agent 活用の最新トレンドを学べます。 Amazon Bedrock や Amazon Bedrock AgentCore を活用したマルチエージェントシステムの具体的なアーキテクチャやデモ事例を通じて、サプライチェーン障害対応の自動化、ERP 例外処理のエージェント化、Agentic Commerce の仕組みを理解できます。 スピーカー 堀内 保大 ソリューションアーキテクト AWS re:Invent 2025 re:Cap インダストリー編 – 流通小売・消費財業界向け 事例セッションから見る​流通小売消費財業界のトレンド AWS re:Invent 2025 で発表された流通小売・消費財業界の事例セッションを基に、AI エージェント活用の 3 つの共通パターンを解説します。Manchester Airports Group や Grainger における Amazon Bedrock AgentCore を活用したマルチエージェント構成、Alexa+ や Petco での Amazon Connect による顧客体験向上、VF Corporation でのクリエイティブ生成・コンテンツ最適化の事例を通じて、業界における AI 活用の最新トレンドをお伝えします。 資料（ PDF ） | 動画（ YouTube ） 対象者 流通小売・消費財業界で AI 活用や DX 推進を検討されているビジネスリーダーおよび技術担当者の方を対象としています。AWS re:Invent 2025 の業界別セッションのポイントを効率的にキャッチアップしたい方にもおすすめです。前提知識として、AWS の基本的なサービス（Amazon Bedrock、Amazon Connect 等）の概要を把握されていると、より理解が深まります。 本 BlackBelt で学習できること AWS re:Invent 2025 の流通小売・消費財業界における事例セッションから抽出した、AI マルチエージェントの活用、AI サービスによるカスタマーエクスペリエンス向上、クリエイティブ生成・コンテンツ最適化の 3 つの共通パターンを学ぶことができます。各事例では、Amazon Bedrock AgentCore や Amazon Connect などの AWS サービスを活用した具体的なアーキテクチャと、導入によるコスト削減・業務効率化の成果を確認できます。また、AI 導入を成功させるための「明確な ROI が見込めるユースケースから着手する」「内部プロセスから開始する」といった実践的なアプローチも学ぶことができます。 スピーカー 山下 智之 ソリューションアーキテクト

本記事は 2026 年 3 月 31 日 に公開された「 Announcing the AWS Sustainability console: Programmatic access, configurable CSV reports, and Scope 1–3 reporting in one place 」を翻訳したものです。 多くの皆さんと同じように、私も一人の親です。子どもたちにのためにどんな世界を築いているか、いつも考えています。だからこそ、今日の発表は多くの方にとって意味があると思います。本日、AWS のサステナビリティに関するレポートとリソースを一か所に集約したスタンドアロンサービス、 AWS Sustainability コンソール の提供開始をお知らせします。 Amazon は 2019 年に The Climate Pledge を通じて、2040 年までに事業全体でネットゼロカーボンを達成する目標を掲げました。この取り組みは、AWS のデータセンターやサービスの構築方針にも反映されています。さらに AWS は、お客様自身のワークロードに対する環境フットプリントの測定と削減も支援しています。AWS Sustainability コンソールは、こうした取り組みの最新のステップです。 AWS Sustainability コンソールは、 AWS Billing コンソール 内の カスタマーカーボンフットプリントツール (CCFT) を基盤として、お客様からのご要望に応じた新機能を導入しています。 これまで、カーボンフットプリントデータにアクセスするには、請求レベルの権限が必要でした。しかし、サステナビリティ担当者やレポートチームは、コストや請求データへのアクセス権を持っていない（また、持つべきでもない）ことが一般的です。そのため、必要な担当者にデータアクセスを提供するには、サステナビリティのワークフローを考慮していない既存の権限構造に対応する必要がありました。AWS Sustainability コンソールは Billing コンソールとは独立した権限モデルを備えており、サステナビリティ担当者は請求権限なしで排出量データに直接アクセスできるようになりました。 このコンソールには、AWS の利用に起因する スコープ 1, 2, 3 の排出量 が含まれ、AWS リージョンや Amazon CloudFront 、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Simple Storage Service (Amazon S3) といったサービスごとの内訳を確認できます。基となるデータと算定方法は今回のローンチでは変更されておらず、 CCFT と同じです。変わったのは、データへのアクセスと活用方法です。 サステナビリティレポートの要件が複雑化する中、排出量データへのより柔軟なアクセスが求められています。コンソールにはレポートページが追加され、マーケットベース方式 (MBM) とロケーションベース方式 (LBM) の両方のデータを含む月次およびの年次の二酸化炭素排出量レポートをダウンロードできます。また、含めるフィールド、時間粒度、その他のフィルターを選択してカスタム CSV レポートを作成することもできます。 組織の会計年度が暦年と一致しない場合、コンソールをレポート期間に合わせて設定できるようになりました。設定すると、すべてのデータビューとエクスポートに会計年度と四半期が反映されるため、財務チームとサステナビリティチームが並行して作業する際の摩擦が解消されます。 また、新しい API や AWS SDK を用いて、排出量データを独自のレポートパイプライン、ダッシュボード、コンプライアンスワークフローに統合することもできます。これは、データエクスポートを設定せずに多数のアカウントにまたがる特定月のデータをを取得したい場合や、既存の AWS Organizations 構造と一致しないカスタムアカウントグループを作成する必要がある場合に効果的です。 リリースされた最新の機能や算定方法の更新については、 詳細はこちら タブの リリースノート ページで確認できます。 実際に見てみましょう Sustainability コンソールを紹介するため、 AWS マネジメントコンソール を開き、画面上部の検索バーで “Sustainability” と検索しました。 二酸化炭素排出量 セクションでは、二酸化炭素換算トン (MTCO2e) で表された二酸化炭素排出量の推定値を確認できます。MBM と LBM の両方でスコープ別の排出量が表示されます。画面右側では、日付範囲の調整やサービス、リージョンなどによるフィルタリングが可能です。 補足すると、スコープ 1 は自社が所有または管理する排出源からの直接排出 (例えば、データセンターの燃料使用によるもの) を指します。スコープ 2 は購入したエネルギーの生産に伴う間接排出で、マーケットベース方式 (MBM) では再生可能エネルギー証書などのエネルギー属性証書を考慮し、ロケーションベース方式 (LBM) では地域の平均グリッド排出量を使用します。スコープ 3 はサーバー製造やデータセンター建設など、バリューチェーン全体のその他の間接排出を含みます。これらの算定方法の詳細については、第三者機関である Apex による独立した検証 を受けた ドキュメント をご覧ください。 API や AWS Command Line Interface (AWS CLI) を使って、排出量データをプログラムで取得することもできます。 aws sustainability get-estimated-carbon-emissions \ --time-period='{"Start":"2025-03-01T00:00:00Z","End":"2026-03-01T23:59:59.999Z"}' { "Results": [ { "TimePeriod": { "Start": "2025-03-01T00:00:00+00:00", "End": "2025-04-01T00:00:00+00:00" }, "DimensionsValues": {}, "ModelVersion": "v3.0.0", "EmissionsValues": { "TOTAL_LBM_CARBON_EMISSIONS": { "Value": 0.7, "Unit": "MTCO2e" }, "TOTAL_MBM_CARBON_EMISSIONS": { "Value": 0.1, "Unit": "MTCO2e" } } }, ... ビジュアルコンソールと新しい API により、引き続き利用可能な データエクスポート に加えて、データの活用手段が 2 つ増えました。コンソールでホットスポットを特定し、ステークホルダー向けレポートの作成を自動化できます。 Sustainability コンソールは今後も機能を拡充していきます。お客様とともにコンソールの機能を拡充しながら、新しい機能を引き続きリリースしていきます。 今すぐ始めましょう AWS Sustainability コンソールは、追加費用なしで本日からご利用いただけます。AWS マネジメントコンソールからアクセスできます。2022 年 1 月までさかのぼる過去のデータも利用可能なため、排出量の傾向をすぐに確認し始めることができます。 今すぐ コンソール をお試しください。AWS のサステナビリティへの取り組みについて詳しくは、 AWS Sustainability ページをご覧ください。 — seb 著者について Sébastien Stormacq Seb は 80 年代半ばに初めて Commodore 64 に触れて以来コードを書き続けています。情熱、好奇心、お客様視点、創造性を独自に組み合わせた彼のスタイルで、ビルダーの皆さんが AWS クラウドの価値を引き出せるよう支援しています。ソフトウェアアーキテクチャ、開発者ツール、モバイルコンピューティングに関心があります。彼に何かを売り込みたいなら、それにAPIがあることを確認してください。Bluesky、X、Mastodon などで @sebsto をフォローしてください。 翻訳は Technical Account Manager の 石渡 が担当しました。

本記事は 2026 年 3 月 12 日に公開された Ryan Yanchuleff, Kartik Rao, Arnab Satpati による “ Enterprise governance: control your MCP servers and models ” を翻訳したものです。 AI コーディングツールを評価するエンタープライズのセキュリティおよびコンプライアンスチームは、一貫して 2 つの機能を優先しています。MCP サーバー接続の一元管理と、組織全体で使用される AI モデルのガバナンスです。 どちらも、企業が新しいカテゴリの開発者ツールに対してどう向き合うかを表しています。MCP サーバーはデータベース、ドキュメント、API、内部ツールに接続することで IDE を拡張し、実際の生産性向上をもたらします。AI モデルは定期的にリリースされ、それぞれデータ処理の特性と推論リージョンが異なります。エンタープライズ規模では、組織は開発環境の他の部分と同様に、これらに対してもポリシー主導の管理を期待しています。 コンプライアンス要件が高い組織にとって、これらの管理機能は広範な導入の前提条件となることが多いです。セキュリティチームは、MCP サーバーへのアクセスが組織のポリシーに沿っていること、そしてモデルの使用が承認された範囲内に収まっていることを、エンジニアリングチーム全体へのロールアウトを承認する前に確認する必要があります。 本日、Kiro に 2 つの新しいエンタープライズガバナンス機能を提供します。管理者が承認済み MCP サーバーを許可リストで管理できる MCP サーバーレジストリと、組織が開発者が使用できるモデルを定義できるモデルガバナンス管理です。Kiro はこれらのポリシーを IDE と CLI の両方で確定的に適用します。 問題: ガードレールのない MCP MCP は AI コーディングツールが外部システムに接続するための標準的な方法となっています。Kiro はローンチ以来 MCP をサポートしており、まず ローカルサーバー 、次に リモートサーバー に対応しました。開発者は MCP サーバーを使用して、Kiro をドキュメントシステム、データベース、チケットツール、クラウドインフラなどに接続しています。 MCP の導入が組織全体に拡大するにつれ、エンタープライズのセキュリティチームは開発環境内の他の統合ポイントに適用するのと同じ一元的な監視を求めるようになります。何百人もの開発者が MCP を通じて外部システムに接続している場合、管理者はパッケージレジストリ、CI/CD プラグイン、API アクセスを管理するのと同じように、使用が承認されているサーバーを定義して適用する方法が必要です。 これはエンタープライズのお客様から最も一貫して寄せられたリクエストの 1 つでした。個々の開発者の裁量に任せるのではなく、ポリシーを通じて MCP サーバーへのアクセスを管理する方法を管理者に提供してほしいというものです。組織は、セキュリティチームが求めるガバナンス体制を維持しながら、MCP の導入を迅速に進めたいと考えていました。 仕組み: MCP レジストリ Kiro の MCP ガバナンスは管理者に 2 つの管理機能を提供します。MCP を無効にする MCP のオン/オフトグルと、管理者が Kiro 用の承認済み MCP サーバーの JSON 許可リストを設定できる MCP レジストリです。どちらの管理機能も、エンタープライズユーザー向けに作成される Kiro プロファイル の一部であり、そのアカウントのすべてのサブスクライバーに対してアカウントレベルで設定できます。 レジストリ自体は JSON ファイルで、Amazon S3、nginx、内部 Web サーバーなど任意の HTTPS エンドポイントに作成してホストします。Kiro 管理コンソールのプロファイルに URL を追加すると、Kiro が確定的な方法で残りの処理を行います。すべての Kiro クライアントは起動時にレジストリを取得し、24 時間ごとに再同期します。ローカルにインストールされた MCP サーバーがレジストリに存在しなくなった場合、Kiro はそれを終了させ、開発者が再追加できないようにします。レジストリがサーバーの新しいバージョンを指定している場合、Kiro はそのサーバーを更新後のバージョンで自動的に再起動します。 開発者が Kiro CLI で /mcp add を実行すると、レジストリのサーバーのみが表示されます。レジストリで定義されたサーバーパラメーター（URL、パッケージ識別子、ランタイム引数）は読み取り専用です。開発者は独自の環境変数（認証キーやローカルパス用）と HTTP ヘッダーを追加できますが、リストにないサーバーには接続できません。 レジストリはリモートとローカルの両方の MCP サーバーをサポートしています。 リモートサーバー : streamable-http または sse トランスポートで接続し、エンドポイント URL と HTTP ヘッダーを設定可能です。 ローカルサーバー : npm、PyPI、OCI レジストリのパッケージとして定義され、 stdio トランスポートで動作します。Kiro は npx 、 uvx 、または docker を使用してダウンロードおよび実行します。適切なパッケージランナーが開発者のマシンにインストールされている必要があります。 MCP レジストリオープン標準に基づく構築 Kiro のレジストリファイル形式は、 MCP レジストリ標準 の一部を採用しました。これは MCP サーバーの検出と配布のためのオープンソース仕様で、MCP プロジェクト（元々は Anthropic が作成し、現在はオープン標準として管理されています）によって維持されています。これにより、MCP ガバナンスへの投資が特定のサービスプロバイダーに縛られることはありません。レジストリ仕様は、MCP サーバーのカタログ化、バージョン管理、検出方法の標準化されたデータモデルを定義しています。 Kiro のレジストリ定義は、JSON 形式の仕様から サーバースキーマ の一部に従っています。各サーバーエントリには、名前（ファイル内で一意）、説明、バージョン（セマンティックバージョニング推奨）、および remotes 配列（HTTP ベースのサーバー用）または packages 配列（ローカル stdio サーバー用）のいずれかが含まれます。簡略化した例を以下に示します。 { "servers": [ { "server": { "name": "my-remote-server", "description": "My server description", "version": "1.0.0", "remotes": [ { "type": "streamable-http", "url": "https://acme.com/my-server" } ] } }, { "server": { "name": "my-local-server", "description": "My server description", "version": "1.0.0", "packages": [ { "registryType": "npm", "identifier": "@acme/my-server", "transport": { "type": "stdio" } } ] } } ] } 完全な JSON スキーマと属性リファレンスについては、 Kiro MCP ガバナンスドキュメント を参照してください。 モデルガバナンス: 開発者が使用できるモデルを管理する Kiro は オープンウェイトモデル や Anthropic の最新モデル（ Opus 4.6 や Sonnet 4.6 など）のような新しいモデルオプションを追加し続けています。選択肢が増えることは開発者にとって良いことです。しかし、モデル承認プロセスを持つ企業にとって、新しいモデルが登場するたびに、誰かが使用できるようになる前に回答が必要なコンプライアンス上の問題が生じます。 本日、Kiro エンタープライズのお客様向けにモデルガバナンスも提供します。Kiro の管理者は、未承認のモデルを無効にすることで、開発者が利用できるモデルを制限できるようになりました。 明確にしておくと、これは「独自モデルの持ち込み」ではありません。モデルガバナンスは Kiro にモデルを追加するものではありません。すでに利用可能なリストからモデルを削除するものです。組織がまだモデルを承認していない場合、レビュープロセスが完了するまで開発者にオプションとして表示されないよう無効にできます。 なぜこれが重要なのか エンタープライズのモデル承認プロセスには正当な理由があります。モデルによってトレーニングデータの出所、ライセンス条件、データ処理の特性が異なります。新しいモデルを使用する前に法的レビューを必要とする組織もあります。数週間かかる技術評価プロセスを持つ組織もあります。 モデルガバナンスがなければ、Kiro が新しいモデルをリリースするたびに、組織内のすべての開発者がすぐに利用できるようになります。管理者は承認プロセスを適用する方法がなく、IDE でモデルを選択する前に開発者がポリシードキュメントを確認することに頼ることになります。それでは組織規模には対応できません。 データレジデンシーと実験的モデル これは特にデータレジデンシー要件を持つお客様にとって重要です。Kiro の一般提供モデルはリージョナルなクロスリージョン推論を使用しており、データは選択した地域（米国またはヨーロッパ）内に留まります。しかし、 実験的サポート でリリースされた新しいモデルはグローバルなクロスリージョン推論を使用する場合があり、リクエストが選択した地域外の AWS リージョンで処理される可能性があります。 データレジデンシー要件が高い組織にとって、この区別は重要です。グローバルに推論をルーティングする実験的モデルは、モデル自体が技術的に優れていても、コンプライアンス義務と互換性がない場合があります。 モデルガバナンスは管理者にこれを処理するための簡単な方法を提供します。データレジデンシー要件に対してレビューが完了するまで実験的モデルを無効にします。モデルが実験的段階からリージョナル推論を備えた一般提供段階に移行したら、有効にします。開発者は Kiro のタイムラインではなく、組織のタイムラインで新しいモデルにアクセスできます。 仕組み 管理者は AWS マネジメントコンソールの Kiro 管理設定を通じてモデルの可用性を設定します。インターフェースには Kiro がサポートするすべてのモデルと、その現在のステータス（GA または実験的）および推論スコープが表示されます。管理者はモデルのオン/オフを切り替えられます。無効にされたモデルは、IDE と CLI の両方で組織内のどの開発者のモデルセレクターにも表示されません。 Kiro が新しいモデルをリリースすると、管理者は準備が整うまで簡単にオフにできます。開発者は組織が承認したモデルのみを見ることができます。 今すぐ始めましょう MCP ガバナンスとモデルガバナンスは、 AWS IAM Identity Center 、 Okta、または Microsoft Entra ID を通じて認証する Kiro エンタープライズのお客様向けに、Kiro IDE 0.11.28 または Kiro CLI 1.23 以降で利用可能です。 Kiro 管理設定コンソール で MCP レジストリとモデルポリシーを設定してください。 翻訳は Solutions Architect の吉村 が担当いたしました。

2026 年 3 月 23 日週の出来事で私が最も心を躍らせたのは、AWS Agentic AI バイスプレジデントである Swami Sivasubramanian が開始した 2026 年 AWS AI & ML Scholars プログラム です。これは、世界中の学習者最大 100,000 人に AI 教育を無料で提供するプログラムで、基本的な生成 AI スキルを学ぶチャレンジフェーズと、その後で上位 4,500 名の成績優秀者に提供される 3 か月間の Udacity NanoDegree (授業料全額支給) という 2 つのフェーズがあります。AI または機械学習の経験がなくても、18 歳以上であれば誰でも応募できます。応募締め切りは 2026 年 6 月 24 日です。詳細を確認して応募するには、 AWS AI & ML Scholars ウェブページ をご覧ください。 私は AWS Summit シーズンの開幕もとても楽しみにしています。今シーズンの皮切りは AWS Summit Paris (4 月 1 日)、その後に AWS Summit London (4 月 22 日) が続きます。AWS Summit は無料の対面式イベントで、ビルダーとイノベーターがクラウドと AI について学び、大きく考え、新しいつながりを築くことができる場です。お近くで開催される AWS Summit を調べて 、ぜひご参加ください。 それでは、2026 年 3 月 30 日週の AWS ニュースを見ていきましょう。 2026 年 3 月 23 日週のリリース 2026 年 3 月 23 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 数秒で行える Amazon Aurora PostgreSQL サーバーレスデータベース作成の発表 – Amazon Aurora PostgreSQL がエクスプレス設定の提供を開始しました。これは、事前設定済みのデフォルト値を使用する効率化されたセットアップで、データベースの作成と接続を数秒で行えるようにします。2 回クリックするだけで、Aurora PostgreSQL サーバーレスデータベースを起動できます。作成中または作成後に特定の設定を変更することもできます。 AWS 無料利用枠での Amazon Aurora PostgreSQL の提供開始 – AWS 無料利用枠で Amazon Aurora PostgreSQL を利用できるようになりました。AWS を初めてご利用になる場合は、サインアップ時に 100 USD 相当の AWS クレジットが付与され、Amazon Relational Database Service (Amazon RDS) などのサービスを使用することで、さらに 100 USD 相当のクレジットを追加獲得できます。 Agent Plugin for AWS Serverless の発表 – 新しい Agent Plugin for AWS Serverless を使用すると、Kiro、Claude Code、Cursorn といった AI コーディングアシスタントを使って、サーバーレスアプリケーションを簡単に構築、デプロイ、トラブルシューティング、管理できます。このプラグインは、スキル、サブエージェント、モデルコンテキストプロトコル (MCP) サーバーを 1 つのモジュラーユニットにパッケージ化することにより、構造化された機能で AI アシスタントを拡張します。AWS で本番環境対応のサーバーレスアプリケーションを構築するための開発過程全体を通じて、必要なガイダンスと専門知識を自動的に読み込みます。 Amazon SageMaker Studio がリモート IDE としての Kiro および Cursor IDE のサポートを開始 – Kiro IDE と Cursor IDE から、Amazon SageMaker Studio にリモートで接続できるようになりました。この機能により、Amazon SageMaker Studio のスケーラブルなコンピューティングリソースにアクセスしながら、Kiro および Cursor の既存のセットアップ (仕様主導の開発、会話型コーディング、自動機能生成など) を利用することが可能になります。 AWS マネジメントコンソールでのビジュアルカスタマイゼーション機能の導入 – アカウントの色といった視覚的設定で AWS マネジメントコンソールをカスタマイズし、表示するリージョンとサービスを管理できるようになりました。使用していないリージョンやサービスを非表示にすることで認知負荷と不必要なスクロール動作が低減し、集中力の向上と作業の迅速化に役立ちます。 Ruby アプリケーションの構築を簡素化するための Aurora DSQL コネクタの発表 – Ruby 用 Aurora DSQL コネクタ (pg gem) を使用して、Aurora DSQL で Ruby アプリケーションを簡単に構築できるようになりました。Ruby 用コネクタは、接続ごとにトークンを自動生成することで認証を簡素化し、セキュリティを強化するため、従来のパスワードに起因するリスクが排除されるとともに、既存の pg gem 機能との完全な互換性も維持されます。 AWS Lambda が Lambda Managed Instances で実行される関数のファイル記述子に対する上限を緩和 – AWS Lambda が、Lambda Managed Instances (LMI) で実行される関数のファイル記述子の上限を 1,024 から 4 倍の 4,096 に引き上げました。今後は、同時実行性が高いウェブサービスやファイルを多用するデータ処理パイプラインなどの I/O 集約型ワークロードを制限範囲内で実行できるようになります。 AWS Lambda が Lambda Managed Instances で最大 32 GB のメモリと 16 個の vCPU のサポートを開始 – Lambda Managed Instances 上の AWS Lambda 関数で、最大 32 GB のメモリと 16 個の vCPU がサポートされるようになりました。インフラストラクチャを管理しなくても、データ処理、メディアトランスコーディング、科学的シミュレーションなどのコンピューティング集約型ワークロードを実行できます。また、メモリと vCPU の比率 (2:1、4:1、または 8:1) をワークロードに合わせて調整することも可能です。 Amazon Polly の双方向ストリーミング API の発表 – 従来のテキスト読み上げ API はリクエスト/レスポンスパターンを使用します。Amazon Polly の新しい双方向ストリーミング API は、大規模言語モデル (LLM) レスポンスなど、テキストや音声を段階的に生成する会話型 AI アプリケーション用に設計されており、テキスト全文が提供される前に音声の合成を開始できます。 AWS からの発表の一覧は、 ニュースブログ チャネルと「 AWS の最新情報 」ページでご覧いただけます。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – 先ほどお勧めした 2026 年の AWS Summit にぜひご参加ください。AWS Summit は、クラウドおよび AI 関連の新興テクノロジーを探求し、ベストプラクティスについて学び、業界の同業者や専門家とつながることができる無料の対面イベントです。近日開催予定の AWS Summit には、パリ (4 月 1 日)、ロンドン (4 月 22 日)、バンガロール (4 月 23〜24 日)、シンガポール (5 月 6 日)、テルアビブ (5 月 6 日)、ストックホルム (5 月 7 日) などがあります。 AWS Community Day – コミュニティリーダーたちがコンテンツを計画、調達、提供し、テクニカルディスカッション、ワークショップ、ハンズオンラボが行われるコミュニティ主導のカンファレンスです。近日開催予定のイベントには、サンフランシスコ (4 月 10 日) およびルーマニア (4 月 23～24 日) があります。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。今後開催される AWS 主導の対面および仮想イベント、スタートアップイベント、デベロッパー向けのイベントについては、 AWS イベントとウェビナー をご覧ください。 2026 年 3 月 30 日週のニュースは以上です。2026 年 4 月 6 日週にお届けする次回の Weekly Roundup もお楽しみに! –  Prasad この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。

本記事は 2026 年 4 月 2 日 に公開された「 Agentic AI for observability and troubleshooting with Amazon OpenSearch Service 」を翻訳したものです。 Amazon OpenSearch Service は、組織のオブザーバビリティワークフローを支えるサービスです。Site Reliability Engineering (SRE) チームや DevOps チームは、テレメトリデータを集約・分析する統合ビューとして活用できます。しかしインシデント発生時、シグナルの相関分析や根本原因の特定には、ログ分析の深い専門知識と何時間もの手作業が必要です。根本原因の特定は依然として手動に頼る部分が大きく、多くのチームにとってサービス復旧の遅延やエンジニアリングリソースの消耗を招くボトルネックとなっています。 以前のブログ記事では、 オブザーバビリティエージェントの構築方法 を Amazon OpenSearch Service と Amazon Bedrock を使って紹介し、平均復旧時間 (MTTR) の短縮を実現しました。今回、Amazon OpenSearch Service はこれらの機能の多くを OpenSearch UI に直接組み込みました。追加のインフラストラクチャは不要です。MTTR の短縮を加速する 3 つのエージェント AI 機能を提供します。 エージェントチャットボット — 表示中のコンテキストと基盤データにアクセスし、エージェント推論を適用してツールでデータをクエリし、インサイトを生成します。 調査エージェント — 仮説駆動型の分析でシグナルデータを深掘りし、各ステップで推論過程を説明します。 エージェントメモリ — 両エージェントを支え、使うほど精度と速度が向上します。 本記事では、各機能が連携してエンジニアがアラートから根本原因まで数分で到達する方法を紹介します。また、調査エージェントが複数のインデックスにまたがるデータを自動的に相関分析し、根本原因の仮説を導き出すサンプルシナリオも解説します。 エージェント AI 機能の連携 AI 機能は OpenSearch UI の Ask AI ボタンからアクセスできます。次の図のように、 エージェントチャットボット のエントリポイントとなります。 エージェントチャットボット チャットボットを開くには、Ask AI を選択します。 チャットボットは現在のページのコンテキストを理解しているため、質問する前から表示中の内容を把握しています。データに関する質問、調査の開始、概念の説明を依頼できます。リクエストを理解すると、チャットボットはツールを使ってデータにアクセスし、Discover ページでクエリを生成・実行して、データに基づいた回答を生成します。Dashboard ページでも使用でき、特定のビジュアライゼーションから会話を開始して、次の画像のようにサマリーを取得できます。 調査エージェント 多くのインシデントは 1〜2 回のクエリでは解決できないほど複雑です。調査エージェントを活用できます。調査エージェントは plan-execute-reflect エージェント を使用します。反復的な推論と段階的な実行が必要な複雑なタスク向けのエージェントです。プランナーとして Large Language Model (LLM) を 1 つ、エグゼキューターとしてもう 1 つの LLM を使用します。エンジニアがエラーレートの急上昇やレイテンシーの異常を発見した場合、調査エージェントに調査を依頼できます。調査エージェントの重要なステップの 1 つが再評価です。各ステップの実行後、エージェントはプランナーと中間結果を使ってプランを再評価します。プランナーは必要に応じてプランを調整したり、ステップをスキップしたり、新しい情報に基づいてステップを動的に追加したりできます。プランナーを使って、エージェントは最も可能性の高い仮説と推奨事項を中心とした根本原因分析レポートを生成します。すべての推論ステップ、発見事項、最終仮説を裏付ける根拠を含む完全なエージェントトレースも提供されます。フィードバックの提供、独自の発見事項の追加、調査目標の反復、エージェントの推論の各ステップの確認と検証が可能です。経験豊富なインシデント対応者の作業を模倣しつつ、数分で自動的に完了します。チャットボットから「/investigate」スラッシュコマンドを使って、進行中の会話を基に調査を開始したり、別の調査目標で新たに開始したりもできます。 エージェントの動作 自動クエリ生成 SRE や DevOps エンジニアとして、主要サービスでレイテンシーが上昇しているというアラートを受け取った状況を考えてみましょう。OpenSearch UI にログインし、Discover ページに移動して Ask AI ボタンを選択します。Piped Processing Language (PPL) クエリ言語の専門知識がなくても、「レイテンシーが 10 秒を超えるリクエストをすべて検索」と入力できます。チャットボットはコンテキストと表示中のデータを理解し、リクエストを検討して適切な PPL コマンドを生成し、クエリバーを更新して結果を取得します。クエリでエラーが発生した場合も、チャットボットはエラーを学習して自己修正し、クエリを反復して結果を取得します。 調査と調査管理 通常であれば複数のログを手動で分析・相関して根本原因を探る必要がある複雑なインシデントでは、 Start Investigation を選択して調査エージェントを起動できます。調査の目標と、指示したいコンテキストや仮説を提供できます。例えば、「サービス全体で広範囲に発生している高レイテンシーの根本原因を特定してください。低速スパンの TraceID を使用して、関連するログインデックスの詳細なログエントリと相関させてください。影響を受けたサービス、オペレーション、エラーパターン、インフラストラクチャまたはアプリケーションレベルのボトルネックをサンプリングなしで分析してください」のように指定します。 エージェントは会話の一部として、デバッグしようとしている問題の調査を提案します。 エージェントはインデックス、関連する時間範囲などの関連情報とともに目標を設定し、調査用の Notebook を作成する前に確認を求めます。Notebook は OpenSearch UI 内でリッチなレポートを作成する機能で、ライブかつコラボレーティブです。調査の管理に役立ち、後日の再調査も可能です。 調査が開始されると、エージェントはまずログシーケンスとデータ分布の簡易分析を行い、外れ値を検出します。次に、調査を一連のアクションに計画し、特定のログタイプと時間範囲のクエリなど各アクションを実行します。各ステップで結果を振り返り、最も可能性の高い仮説に到達するまでプランを反復します。エージェントの作業中は中間結果が同じページに表示され、推論をリアルタイムで追跡できます。調査エージェントがサービストポロジーを正確にマッピングし、調査の重要な中間ステップとして活用している様子を確認できます。 調査が完了すると、調査エージェントは最も可能性の高い仮説として不正検出のタイムアウトを結論付けます。関連する発見事項として、決済サービスのログエントリ「currency amount is too big, waiting for fraud detection」が示されます。これは、高額取引が不正検出の呼び出しをトリガーし、トランザクションのスコアリングと評価が完了するまでリクエストをブロックするという既知のシステム設計と一致します。エージェントは 2 つの別々のインデックス（元の期間データを格納するメトリクスインデックスと、決済サービスのエントリを格納する関連ログインデックス）のデータを相関させてこの発見に至りました。トレース ID を使ってインデックスを紐付け、レイテンシーの測定値とその原因を説明する特定のログエントリを結び付けました。 仮説と裏付けとなる証拠を確認すると、ドメイン知識や過去の類似問題の経験と合致する妥当な結果だと判断できます。仮説を承認し、仮説調査で提供された影響トレースのリクエストフロートポロジーを確認できます。 最初の仮説が有用でなかった場合は、レポート下部の代替仮説を確認し、より正確なものがあれば選択できます。追加の入力や前回の修正を加えて再調査を開始し、調査エージェントに再検討させることも可能です。 使い始めるには エージェント AI 機能（制限あり）は OpenSearch UI で無料で利用できます。アカウントの OpenSearch Service ドメインで AI 機能を無効にしていない限り、OpenSearch UI アプリケーションですぐに利用可能です。AI 機能の有効化・無効化は、AWS マネジメントコンソールで OpenSearch UI アプリケーションの詳細ページに移動し、AI 設定を更新します。 registerCapability API で AI 機能を有効化、 deregisterCapability API で無効化することもできます。詳細は Agentic AI in Amazon OpenSearch Services を参照してください。 エージェント AI 機能は、ログインユーザーの ID と権限を使用して接続先データソースへのアクセスを認可します。ユーザーがデータソースへのアクセスに必要な権限を持っていることを確認してください。詳細は Getting Started with OpenSearch UI を参照してください。 調査結果は OpenSearch UI のメタデータシステムに保存され、サービスマネージドキーで暗号化されます。カスタマーマネージドキーを設定して、すべてのメタデータを独自のキーで暗号化することもできます。詳細は Encryption and Customer Managed Key with OpenSearch UI を参照してください。 AI 機能は Amazon Bedrock の Claude Sonnet 4.6 モデルで動作します。詳細は Amazon Bedrock Data Protection を参照してください。 まとめ Amazon OpenSearch Service に追加されたエージェント AI 機能は、コンテキストを理解するエージェントチャットボット、完全な説明可能性を備えた仮説駆動型の調査、コンテキストの一貫性を保つエージェントメモリを提供し、平均復旧時間の短縮を支援します。エージェント AI 機能により、エンジニアリングチームはクエリの作成やシグナルの相関分析に費やす時間を減らし、確認された根本原因への対応により多くの時間を充てられます。ぜひ各機能を試して、アプリケーションで活用してみてください。 著者について Muthu Pitchaimani Amazon OpenSearch Service の Search Specialist です。大規模な検索アプリケーションとソリューションを構築しています。ネットワーキングとセキュリティに関心があり、テキサス州オースティンを拠点としています。 Hang (Arthur) Zuo Amazon OpenSearch Service の Senior Product Manager です。OpenSearch UI プラットフォームと、オブザーバビリティおよび検索ユースケース向けのエージェント AI 機能をリードしています。エージェント AI とデータプロダクトに関心があります。 Mikhail Vaynshteyn Amazon Web Services の Solutions Architect です。ヘルスケアおよびライフサイエンスのお客様を担当し、データ分析サービスを専門としています。幅広いテクノロジーとセクターにわたる 20 年以上の業界経験があります。 この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。

2026 年 3 月 24 日、アマゾン ウェブ サービス ジャパン合同会社（以下、 AWS ジャパン）は、「フィジカル AI 開発支援プログラム by AWS ジャパン」の採択企業向け勉強会を東京の AWS 目黒オフィスにて開催しました。勉強会では、 Physical AI on AWS リファレンスアーキテクチャ と Physical AI Scaffolding Kit の 紹介 、参加企業向けの個別相談会を開催しました。 本プログラムについては、過去のブログも参照してください。 「フィジカル AI 開発支援プログラム by AWS ジャパン」の応募受付を開始 「フィジカル AI 開発支援プログラム by AWS ジャパン」キックオフイベントを開催しました Physical AI on AWS リファレンスアーキテクチャ Physical AI の開発における全体構成とそれを実現するための AWS 構成及び活用いただける AWS サービスを AI Specialist Solutions Architect の飯塚より紹介しました。 Physical AI の開発は「データ生成・収集 → モデル学習 → モデル配信・推論」の 3 ステップを繰り返すサイクルで進みます。シミュレータでの大量データ生成、 GPU クラスタでの分散学習、エッジデバイスへのモデル配信と実環境での評価 ― これらを一気通貫で回す開発環境をいかに構築するかが、 Physical AI 開発の生産性を大きく左右します。 まずデータ生成・収集のステップでは、 NVIDIA Isaac Sim などのシミュレータ を用いて、ロボットの動作データを大量に生成します。実ロボットで収集できるデータ量には物理的な限界があるため、シミュレータによる合成データ生成が不可欠です。 AWS 上では Amazon EC2 の GPU インスタンスに Amazon DCV でリモートデスクトップ接続し、 Isaac Sim を操作する構成が推奨されます。生成したデータは Amazon S3 に格納し、後続の学習ステップで利用します。 次にモデル学習のステップでは、収集したデータを使って Vision-Language-Action Model （ VLA ）をファインチューニングします。学習規模に応じた構成の使い分けが重要で、 LoRA ファインチューニングのような軽量な学習であれば EC2 の GPU インスタンス単体で完結しますが、フルファインチューニングでは Amazon SageMaker HyperPod や AWS ParallelCluster による GPU クラスタ構成が必要になります。 SageMaker HyperPod は GPU 故障時にノードを自動置換しチェックポイントからジョブを再開する機能を備えており、長時間の学習ジョブでも安定した実行を支えます。ストレージには Amazon FSx for Lustre を採用することで、 S3 と透過的にデータを連携しながら、分散学習に求められる高速 I/O を実現できます。 GPU 確保も実践上の大きな課題です。 AWS では用途に応じた予約の仕組みが用意されており、 EC2 Capacity Blocks for ML では 1 〜 182 日の短期間で GPU を予約でき、需給に応じたダイナミックプライシングが適用されます。 SageMaker HyperPod 環境では Flexible Training Plans による予約が可能です。いずれも AWS マネジメントコンソールからキャパシティの空き状況を確認し、利用開始日と終了日を指定して予約する流れになります。 最後にモデル配信・推論のステップでは、学習済みモデルをエッジデバイスや実ロボットにデプロイし、実環境で動作を評価します。 AWS IoT Greengrass を使うことで、クラウドからエッジデバイスへのモデル配信をマネージドに管理できます。なお、ロボットのアクション生成に使う VLA モデルはリアルタイム性が求められるためエッジ側での推論が基本ですが、長期的な行動計画を担う LLM についてはクラウド側での推論も選択肢になります。評価結果は次のデータ収集にフィードバックされ、開発サイクルが回り続けます。 このアーキテクチャを俯瞰すると、 Physical AI の開発には ML 、 HPC 、 IoT 、ストレージ、ロボティクスと多様な技術領域が交差していることがわかります。単一の専門領域だけではカバーしきれない複合的な課題を、クラウド上で統合的に扱えるアーキテクチャの重要性がますます高まっています。 AWS 上で統合的に扱うことができ、またそういったアーキテクチャの重要性がますます高まっています。 スライド資料 Physical AI Scaffolding Kit VLA モデルのトレーニング環境を簡単に AWS 上に構築できるアセット「 Physical AI Scaffolding Kit (PASK) 」の紹介を Senior IoT Prototyping Solutions Architect の市川と ML Prototyping Solutions Architect の石橋より紹介がありました。 Github リポジトリ : https://github.com/aws-samples/sample-physical-ai-scaffolding-kit PASK の概要 PASK は、 Physical AI のモデルトレーニングに必要なサービスを AWS 上に簡単に構築できる CDK コードと学習実行用のサンプルスクリプトをまとめたアセットです。このアセットを使用することで、以下のような環境を数コマンドで構築できます。 アーキテクチャ Amazon SageMaker HyperPod : スケーラブルなクラスター環境です。 Amazon FSx for Lustre : SageMaker HyperPod 内 Node 間共有ストレージ（ S3 バケットとリンク）です。 SageMaker HyperPod クラスター環境の構築 まず、 AWS CDK を使用した SageMaker HyperPod クラスターの構築方法を紹介しました。 詳細な手順につきましては、 こちら をご確認ください。 クラスター構成 : Controller Group : クラスター管理ノードです Login Group : ユーザーがログインし作業するためのノードです Worker Group : モデル学習などが実際に行われるノードです デプロイの流れ : CDK のセットアップと関連ライブラリをインストールします cdk.json で環境設定を行います（クラスター名、インスタンスタイプなど） cdk deploy で一括デプロイを実行します（数十分で完了） SSH 接続を設定します（ AWS Systems Manager Session Manager 経由） Worker Group を追加します 実行前に適宜 GPU インスタンスの上限緩和申請や、 Amazon SageMaker HyperPod flexible training plans によるインスタンスの確保などが必要になります。 ストレージ構成 : 各ノードが共通の Lustre ストレージを /fsx にマウントします。 /fsx/s3link ディレクトリが S3 にリンクされ、トレーニングデータなどを該当バケットにアップロードするだけで各 Node 間でデータが自動連携されます。 VLA モデルのトレーニング実行例 ここでは、 2 つの代表的な Vision-Language-Action (VLA) モデルのトレーニング方法を解説しました。 こちらのアセットでは、 GR00T / openpi で用意されているサンプルデータセットを使って学習を行っていますが、 S3 にデータをアップロードいただくことで、独自データセットでの学習も可能です。 1. NVIDIA Isaac GR00T のファインチューニング GR00T は NVIDIA が開発する VLA モデルで PASK 環境上で以下のワークフローでトレーニングを実行します： 詳細な手順につきましては、 こちら をご確認ください。 事前準備 : Login Node で Git LFS インストール、 GR00T リポジトリのクローン などを実行します Docker ビルド : Docker イメージのビルドと ECR へのプッシュを行います（ Slurm ジョブとして実行） Enroot 実行 : Enroot による Docker イメージの SquashFS 形式への変換を行います 学習実行 : Slurm でファインチューニングジョブを投入します 2. OpenPI の LoRA ファインチューニング OpenPI (Pi0 モデル ) は Physical Intelligence が開発する VLA モデルで、 LoRA ファインチューニングを上記同様の環境で実行できます： 詳細な手順につきましては、 こちら をご確認ください。 開発環境 : Docker イメージのビルドと ECR へのプッシュを行います SageMaker HyperPod (Login Node) 環境 : セットアップスクリプト /Enroot 実行による環境準備を行います 正規化統計の計算 : 学習データの統計情報を取得します（初回のみ実行） 学習実行 : Worker Node (GPU インスタンス ) へ LoRA ファインチューニングジョブを投入します 今後のスケジュール 時期 内容 2026 年 4 月 9 日 基盤モデル開発勉強会 : LLM/VLM 開発の知見共有。 Data Parallel でマルチノードクラスターへスケールさせることを見越した内容 2026 年 4 月 14 日 NVIDIA Robotics Solutions 勉強会 2026 年 4 月中 ロボット勉強会 : AI 開発者がロボット業界に入っていく上で知っておくべき知識の共有（内容・日程調整中） 2026 年 5 月下旬 コミュニティイベント 2026 年 6 月 25-26 日 Demo Day （中間報告会） at AWS Summit Tokyo 2026 （幕張メッセ） 2026 年 7 月下旬 最終成果報告会（ AWS 麻布台ヒルズ オフィス 予定） おわりに 勉強会 #1 では、 AWS のサービスを利用して、フィジカル AI に関係してくるサービスや、スケーラブルなトレーニング環境についての基本的な知識を共有することができました。参加された企業の皆様は、既存の環境と合わせて活用いただくことで、より開発を加速させることができる様に、 AWS ジャパンとしても引き続き支援をさせていただきます。 AWS ジャパンは、本プログラムを通じて日本のフィジカル AI エコシステムの発展に貢献してまいります。採択企業の皆さまの挑戦と、成果発表会をどうぞご期待ください。 関連リンク : – フィジカル AI 開発支援プログラム by AWS ジャパン（発表ブログ）

本記事は 2026 年 3 月 31 日 に公開された「 Announcing General Availability of AWS DevOps Agent  」を翻訳したものです。 本日、 AWS DevOps Agent の一般提供開始をお知らせします。AWS DevOps Agent は、いつでも対応可能な運用チームメイトです。インシデントの解決とプロアクティブな予防を行い、アプリケーションの信頼性とパフォーマンスを最適化し、そして AWS、マルチクラウド、オンプレミス環境をまたいでオンデマンドの SRE タスクをこなします。 運用チームはインシデント調査、複数ツールにわたるデータの相関付け、アラートの手動トリアージに膨大な時間を費やしています。この運用負荷がエンジニアをイノベーションや戦略的な業務から遠ざけています。AWS DevOps Agent は、経験豊富な DevOps エンジニアのようにインシデントを調査し、この負担を解消します。アプリケーションとその関係性を学習し、オブザーバビリティツール、ランブック、コードリポジトリ、CI/CD パイプラインと連携して、それら全てのテレメトリ、コード、デプロイデータを横断的に相関付けます。プレビュー期間中、AWS DevOps Agent を使用したお客様とパートナーからは、MTTR が最大 75% 削減、調査時間が 80% 短縮、根本原因特定精度が 94% を達成し、インシデント解決が 3〜5 倍速くなったと報告されています。 プレビュー開始以降、さまざまな業界の組織が AWS DevOps Agent を運用ワークフローに統合しています。彼らは AWS DevOps Agent を Amazon CloudWatch と、 Datadog 、 Dynatrace 、 New Relic 、 Splunk 、 GitHub 、 GitLab 、 ServiceNow 、 Slack のようなパートナーツールと接続しています。今回の GA リリースでは、 Azure 、 Azure DevOps 、 PagerDuty 、 Grafana などの組み込みサポートを追加しました。 AWS DevOps Agent の仕組み AWS DevOps Agent は、 フロンティアエージェントという新しいクラスのエージェントです。目標達成のために自律的に動作し、大規模な並行タスクに対応して、人間の常時監視なしで継続的に稼働します。AWS DevOps Agent は、検知から調査、復旧、予防まで、インシデントライフサイクル全体を通じて運用チームと連携します 。 自律的なインシデント対応 AWS DevOps Agent は、深夜 2 時でもピーク時間帯でも、アラートを受信した瞬間から調査を開始します。平均復旧時間 (MTTR) を短縮し、アプリケーションを最適なパフォーマンスに迅速に復旧します。 AWS DevOps Agent のインシデント対応調査記録 プロアクティブなインシデント予防 AWS DevOps Agent は、チームをリアクティブな消火活動からプロアクティブな運用改善へと導きます。過去のインシデントパターンを分析し、的確な推奨事項を提供します。推奨事項は将来のインシデントを予防し、プロセスとシステムのレジリエンスを強化します。 カテゴリ別の推奨事項を表示する予防ダッシュボード オンデマンド SRE タスクの処理 AWS DevOps Agent はあなたの環境を深く理解しています。単に質問するだけでなく、アプリケーション環境をより深く掘り下げられます。カスタムチャートやレポートを作成、保存、共有できます。 インフラストラクチャをクエリするための会話型 AI アシスタントを備えたオンデマンド SRE チャットインターフェース 一般提供での新機能 GA リリースでは、お客様のフィードバックに基づいて AWS DevOps Agent の機能を拡張しました。多様な運用環境でインシデント対応をよりスケーラブルで、柔軟に、インテリジェントにするようになりました。 ユースケースの拡大 Azure サポート: AWS DevOps Agent は AWS 環境を超えて Azure ワークロードのインシデント調査にも対応するようになりました。マルチクラウドデプロイメント全体のデータを相関付けて、アプリケーションが AWS、Azure、またはその両方で実行されていても一貫したインシデント対応を実施します。 オンプレミスサポート: AWS DevOps Agent は Model Context Protocol (MCP) を使用してオンプレミスアプリケーションのインシデント調査にも対応するようになりました。メトリクス、ログ、コードを分析してオンプレミスリソースを検出し、包括的なトポロジを構築します。AWS、Azure、オンプレミス環境全体で一貫したインシデント対応を実施します。 オンデマンド SRE タスク: 会話型 AI アシスタントを使用して、AWS、 マルチクラウド 、オンプレミス環境全体でアプリケーションアーキテクチャについてのクエリやシステムヘルスの分析を自然言語で行えるようになりました。リソース、システムメトリクス、アラームステータス、デプロイ履歴、インシデントパターンについて質問できます。即座にコンテキストに応じた回答を取得し、カスタムチャートやレポートを作成してチームと保存・共有できます 。 Triage Agent : Triage Agent はインシデントの重大度を自動評価し、重複チケットを特定します。重複を検出すると、メイン調査に「LINKED」ステータスでリンクします。リンクされたタスクは自動開始されないため、ノイズを減らしてチームの取り組みを主要インシデントに集中できます。 インテリジェンスの強化 学習済みスキル: AWS DevOps Agent は組織の調査パターン、ツール使用、トポロジから学びます。チームが特定タイプのインシデントを解決する方法に基づいてスキルを構築します。時間とともに、組織固有の運用課題への対応力が向上します。 カスタムスキル: システム固有の調査手順、ベストプラクティス、組織のナレッジを追加できるようになりました。ワークフローを一度作成すれば、関連するすべての調査で自動的に使用されます。スキルは特定のエージェントタイプ (On-demand、Incident Triage、Incident RCA、Incident Mitigation、Evaluation) に設定できます。コンテキスト消費を削減し、フォーカスを向上させます。 コードインデックス: エージェントはアプリケーションコードリポジトリをインデックス化できるようになりました。コード構造を理解し、調査中に潜在的なバグを特定し、緩和計画の一部としてコードレベルの修正を提案できます。 新しいインテグレーション Datadog、Dynatrace、New Relic、Splunk、GitHub Actions、GitLab CI/CD、ServiceNow との既存インテグレーションに加え、以下のインテグレーションを追加しました: PagerDuty : PagerDuty アラートによる自動インシデント対応のネイティブインテグレーション Grafana: 組み込みの Grafana MCP サーバーは、セルフマネージド、Grafana Cloud、Amazon Managed Grafana を含むあらゆる Grafana インスタンスに接続できます。接続後、エージェントは Prometheus、Loki、OpenSearch などのインスタンスに設定されたすべてのデータソースにアクセスできます。オープンソースのテレメトリモニタリングとシステムイントロスペクションを実現します。 Azure DevOps : Azure 環境でのデプロイとコード変更を追跡する Azure Pipelines とのインテグレーション Amazon EventBridge : カスタム自動化ワークフロー用に Amazon EventBridge 経由で調査イベントが利用可能になりました。 新しい API : AWS CLI 、 AWS SDK 、 AWS MCP Server のサポートを更新 これらのインテグレーションにより、AWS DevOps Agent は既存の運用ツールチェーンとシームレスに連携できます。 エンタープライズ対応機能 リージョン拡大: AWS DevOps Agent は本日から一般提供を開始し、世界中の6つのリージョンで利用できます。北米では米国東部 (バージニア北部) と米国西部 (オレゴン)、欧州ではフランクフルトとアイルランド、アジアパシフィックではシドニーと東京で利用可能です。ワークロードがどこで実行されていても、エージェントをより近くに配置できます。この地理的分散により、データレジデンシー要件を満たしながら運用チームのレイテンシーを削減できます。 プライベート接続: AWS DevOps Agent のプライベート接続によって、あなたの Agent Space は VPC や内部ネットワークで実行されているサービスへ、パブリックインターネットにさらされることなく安全に接続できるようになりました。プライベート接続は、MCPサーバー、セルフホストのGrafanaまたはSplunkインスタンス、ソース管理システムなど、プライベートエンドポイントに到達する必要のあるあらゆるインテグレーションと連携します。プライベート接続の仕組みについては、「 VPC 内のプライベートサービスに AWS DevOps Agent をセキュアに接続する 」を参照してください。 セキュリティ: AWS DevOps Agent はカスタマーマネージドキーと、オペレーターポータルアクセス用の Okta および Microsoft Entra ID との直接 ID プロバイダー (IdP) 統合をサポートするようになりました。 ローカライゼーション: AWS DevOps Agent はブラウザのロケール設定に応答し、エージェントの応答を翻訳するようになりました。グローバルチームが好みの言語で AWS DevOps Agent とやり取りできます。 お客様の成功事例 早期に導入いただいたお客様はすでに大幅な運用改善を実現しています。 Western Governors University Western Governors University (WGU) は 191,000 人以上の学生にサービスを提供するオンライン大学のリーダーであり、AWS DevOps Agent を本番環境に導入した最初の組織の 1 つです。大規模な Dynatrace ユーザーとして、WGU は AWS DevOps Agent のネイティブ Dynatrace インテグレーションを活用し、Dynatrace Intelligence が問題レコードを自動的にエージェントにルーティングして調査し、充実した調査結果を Dynatrace に直接返します。 最近の本番調査では、WGU の SRE チームが AWS DevOps Agent を使用してサービス中断シナリオを分析し、総解決時間を推定 2 時間からわずか 28 分に短縮しました。これは MTTR が 77% 改善したことを示しています。エージェントは Lambda 関数設定内にある根本原因を迅速に特定し、以前は埋もれていた内部ドキュメントにのみ存在していた重要な運用知識を発掘しました。 「エージェントは決定的な証拠を提供し、Lambda が原因であることを特定しました。調査はフロントエンドで確認した内容とほぼ完璧に一致するメトリクスを示しました。昨日は大きな勝利でした。発見を加速し続けられれば、組織にとってどれほどの勝利になるか言葉では表せません」と Angel Marchena 氏 (技術運用ディレクター) は述べています。 AWS DevOps Agent Skills 機能を活用する計画により、WGU は調査時間をさらに短縮する軌道に乗っています。 Zenchef Zenchef は、レストランが予約、テーブル運営、デジタルメニュー、決済、ゲストマーケティングを手数料なしの単一システムで管理できるレストランテクノロジープラットフォームです。少人数の DevOps チームが部門間で共有の本番環境を管理しているため、彼らは実際の試練に直面しました。社内ハッカソン中に顧客向けの問題が発生したのです。ほとんどのエンジニアはイベントに集中しており、また、モニタリングには解決への正しい方向を示すような重要な情報は何も表示されていませんでした。 エンジニアをハッカソンから引き離す代わりに、チームは問題を AWS DevOps Agent に入力しました。エージェントは体系的に問題に取り組みました。認証を手がかりとして除外し、ECS デプロイメントの調査に方向転換し、最終的に GitHub をホストする EC2 インスタンスの IAM 設定ミスが根本原因であることを突き止めました。調査全体は 20〜30 分で完了し、手動で行った場合の 1〜2 時間と比較して約 75% の削減でした。調査結果は担当エンジニアに直接共有され、スムーズな引き継ぎが行われました。 「ハッカソン中、調査する余裕はほぼありませんでしたが、調査をする必要もありませんでした。私たちは常に数手先を読もうとしていますが、このようなプロアクティブな調査は通常は不可能です。DevOps Agent は我々のプラットフォームの動作を理解する新しい方法になっています。」と Theo Massard 氏 (プラットフォームエンジニアリングマネージャー) は述べています。 T-Mobile T-Mobile US, Inc. は米国を代表するワイヤレスキャリアの 1 つであり、全米で 1 億 4,000 万人以上の加入者にモバイル音声、メッセージング、データサービスを提供しています。 「AWS が AWS DevOps Agent を発表したとき、T-Mobile は初日からテーブルについていました。設計のパートナーとして、AWS DevOps Agent が本番環境全体で根本原因分析を大幅に改善できることを確認しました。私たちの実際のフィードバックが製品の進化に直接影響を与えました。私たちのインフラストラクチャは複数のクラウドとオンプレミス環境にまたがり、アプリケーションログはオンプレミスの Splunk デプロイメントに集約されています。AWS DevOps Agent がこれらの多様な環境全体で Splunk とシームレスに統合してログを分析できる能力は、ソリューションの試験運用を続ける中で大きな影響を与えています」と Aravind Manchireddy 氏 (SVP、テクノロジーオペレーション) は述べています。 Granola Granola は、文字起こしと要約の重労働を処理する AI 搭載のメモ帳であり、お客様は手動でメモを取ることに気を取られることなく完全に集中できます。AWS DevOps Agent は Granola の AI 搭載インシデント管理ワークフローにシームレスに統合され、根本原因分析を加速し、平均解決時間を短縮します。 「AWS DevOps Agent をインシデント対応プロセスに直接統合し、重大度の高い CloudWatch アラームで自動的に調査をトリガーしています」と Granola の Eddie Bruce 氏は述べています。「AWS DevOps Agent のデータベース調査機能、特に PostgreSQL ログの分析と RDS パフォーマンスインサイトの表示は、評価した他のツールを一貫して上回っています。SRE 機能を拡張する中で、AWS DevOps Agent はインシデント管理ツールキットの一翼を担っていることが証明されています」と Eddie Bruce 氏 (プロダクトエンジニア) は述べています。 その他のお客様の成功事例は AWS DevOps Agent の お客様 ページをご覧ください。 Getting Started AWS DevOps Agent は本日から利用可能です。すぐに価値を実感する方法を紹介します: クイックウィンから始める Agent Space を作成: AWS マネジメントコンソール で AWS DevOps Agent に移動し、最初の Agent Space を作成します。 オブザーバビリティツールを接続: 既存のツール (Datadog、Grafana、Dynatrace など) をリンクして、エージェントがテレメトリデータにアクセスできるようにします。 最初の調査を実行: 自動インシデント対応を設定するか、Web アプリを使用してアラートを手動で調査します。エージェントの調査結果を確認し、学習済みスキルを改善するためのフィードバックを提供します。 最近のインシデントを再調査: 過去 30 日間にチームが調査した本番インシデントを選択します。AWS DevOps Agent を使用して同じ問題を調査し、結果を比較します。時間短縮と精度向上をすぐに実証できます。 成功を加速する 本番ベストプラクティスに従う: エージェントを運用ワークフローに統合するガイダンスについては、 AWS DevOps Agent を本番環境にデプロイするためのベストプラクティス をご覧ください。 影響を測定する: MTTR の改善、調査時間の短縮、正解率を追跡して、AWS DevOps Agent が組織にもたらす価値を定量化します。 体系的に拡大する: 1 つのチームまたはサービスから始め、価値を実証してから、追加のチームとユースケースに拡大します。 料金 AWS DevOps Agent では、エージェントが運用タスクに費やした時間に対して秒単位で課金されます。前払いのコミットメントはありません。いつでもエージェントの使用を開始および停止できます。AWS サポートのお客様は、AWS サポート支出総額の一定割合に基づいて、AWS DevOps Agent 使用量に対する月額クレジットを受け取ります。割合はサポートプランによって異なります。料金の詳細については、AWS DevOps Agent の 料金ページ をご覧ください。 まとめ 詳細については、 AWS DevOps Agent をご覧いただき、 ユーザーガイド をご確認ください。ご質問や AWS DevOps Agent が組織にどのように役立つかについては、AWS アカウントチームにお問い合わせください。今すぐ サインアップ しましょう。 翻訳はソリューションアーキテクトの大西朔が担当しました。原文は こちら です。 著者について Madhu Balaji AWS のシニア WW Agentic Development スペシャリスト SA として、お客様のクラウドソリューションの設計と実装を支援しています。開発とアプリケーションアーキテクチャで 20 年以上の経験を持ち、エージェント AI と AI 搭載開発者ツールを専門としています。AI コーディングアシスタント、開発者生産性プラットフォーム、AWS でのソフトウェア構築とデプロイ方法を変革する自律型 AI エージェントに関する専門知識を持っています。

はじめに 本稿は、2026 年 03 月 20 日に公開された “ Migrate Amazon CloudFront public origins to private VPC origins ” を翻訳したものです。 この記事では、さまざまな戦略を使用して  Amazon CloudFront  のパブリックオリジンを  Amazon Virtual Private Cloud  (Amazon VPC) オリジンに移行する方法を紹介します。また、 クロスアカウント で  VPC オリジン を使用することで、セキュリティを最優先としたアーキテクチャをサポートすることもできます。 CloudFront ワークロードのネットワークアーキテクチャを設計する際、集中型モデルと分散型モデルのいずれかを選択する必要があります。集中型アーキテクチャでは、専用のネットワーキングアカウントがすべての CloudFront ディストリビューションをホストし、複数のリソースアカウントにまたがるオリジンに接続します。各リソースアカウントは、Application Load Balancer (ALB)、Network Load Balancer (NLB)、Amazon Elastic Compute Cloud(Amazon EC2) インスタンスなどのオリジンインフラストラクチャをホストします。分散型アーキテクチャでは、各リソースアカウントが独自の CloudFront ディストリビューションとオリジンインフラストラクチャをそれぞれ管理するため、他のアカウントから独立したワークロード環境が構築されます。 VPC オリジンは、集中型と分散型のどちらのアーキテクチャモデルでも使用できます。アプリケーションをプライベートにしてパブリックインターネットから分離することで、セキュリティ体制が強化されます。 VPC オリジンを使用して CloudFront レイヤーでアクセス制御を管理することで、アプリケーションをパブリックインターネットから分離できます。また、オリジンインフラストラクチャに対する DDoS 攻撃のリスクも軽減されます。既存のワークロードで CloudFront VPC オリジンを有効にする方法はいくつかあります。適切な移行アプローチの選択は、現在の構成、ビジネスニーズ、運用要件によって異なります。ここからは、さまざまな移行戦略を紹介し、お客様の環境に最適な方法を選択するための主要な考慮事項とベストプラクティスについて説明します。 前提条件 CloudFront のパブリックオリジンをプライベート VPC オリジンに移行する前に、以下の準備が必要です： AWS アカウントと権限  CloudFront および Amazon VPC リソースを管理するために必要な Amazon Web Services (AWS) Identity and Access Management (IAM) 権限 AWS Resource Access Manager (AWS RAM) (クロスアカウント共有の場合) リソースが配置されている AWS リージョンとアベイラビリティーゾーン (AZ) で VPC オリジンがサポートされている ことを確認 リソース設定  プライベートアプリケーションリソースのネットワーク要件を確立。 CloudFront VPC オリジンの前提条件 のドキュメントを参照してください。セキュリティグループを使用してオリジンを保護し、CloudFront からのインバウンド接続のみに制限からのインバウンド接続のみに制限 Amazon VPC のプライベートサブネット内に必要な ALB、NLB、または EC2 インスタンスを作成。これらのリソースを VPC オリジンとして設定 CloudFront とオリジン間で HTTPS 通信を行うための、有効な SSL/TLS 証明書と適切な暗号化設定の構成 Amazon VPC Block Public Access (BPA) の設定  BPA を使用している場合は、Amazon VPC 全体または特定のプライベートサブネットに対する Amazon VPC BPA 除外設定の作成。設定手順については、 Amazon VPC BPA の基本 のドキュメントを参照 VPC オリジンの設定 CloudFront  コンソール または  API  を使用した VPC オリジンの 作成 。プライベートアプリケーションリソースを作成したリソースオーナーアカウントを使用 VPC オリジンのデプロイには最大 15 分かかる場合あり テストと検証  プライベートアプリケーションリソース (ALB、NLB、または Amazon EC2 インスタンス) が本番環境へアクセス可能な状態であり、Amazon VPC 内からアクセス可能であることの確認 同じ Amazon VPC 内のテストインスタンスからプライベートオリジンへの接続をテストし、アプリケーションへのアクセスの確認 アプリケーションがパフォーマンスベンチマークを満たし、期待どおりにコンテンツを配信していることの検証 モニタリングメトリクス  Amazon CloudWatch メトリクス ：4xxErrorRate、5xxErrorRate、OriginLatency を追跡し、オリジン接続の問題やパフォーマンス低下の特定 CloudFront ログ ：アクセスログを確認し、オリジン接続の失敗、タイムアウトエラー、VPC オリジンからの予期しないレスポンスコードの確認 Amazon VPC フローログ ：CloudFront から VPC オリジンへのトラフィックフローの確認。セキュリティグループルールで必要な接続が許可されていることの確認 アプリケーションログ ：オリジンアプリケーションログを監視し、CloudFront との統合に問題があることを示すエラーやパフォーマンスの問題の確認 移行戦略 このセクションでは、CloudFront でパブリックオリジンからプライベート VPC オリジンへ移行するための戦略について説明します。これらの戦略を実施する前に、前提条件を完了しておく必要があります。 戦略 1：CloudFront 継続的デプロイの使用 (推奨) CloudFront 継続的デプロイ を使用すると、設定の変更を安全にテスト・検証でき、ステージング環境を本番環境に昇格させる前に変更内容をテストできます。このブルー/グリーンデプロイメントアプローチが推奨される移行戦略である理由は、ダウンタイムゼロの移行とロールバック機能が組み込まれているためです。また、本番トラフィックに影響を与える前に、VPC オリジンの接続性、パフォーマンス、機能を安全にテスト・検証できます。この戦略を図 1 に示します。 継続的デプロイメントでは、本番 (プライマリ) ディストリビューションをミラーリングするステージングディストリビューションが作成されます。ステージングディストリビューションに新しい VPC オリジンを設定できます。プライマリディストリビューションはパブリックオリジンからのトラフィック配信を継続します。ヘッダーベースまたは重みベースの方式で継続的デプロイメントポリシーを作成し、ステージングディストリビューションにトラフィックを振り分けることができます。 まず、特定のヘッダーでトラフィックをタグ付けしてテストを行うには、ヘッダーベースタイプでポリシーを有効にします。これにより、テストフェーズ中に発生する可能性のある問題を迅速に解決できます。Amazon VPC、ネットワーク、アプリケーションのパフォーマンスが検証され、問題が解決したら、ポリシーを重みベースタイプに更新します。 重みベースポリシーでは、本番トラフィックの特定の割合 (0%〜15%) をステージングディストリビューションにルーティングできます。最初は小さい割合から始め、徐々に増やしていくことができます。重みベースポリシータイプを使用する場合、セッションの維持を有効にできます。これにより、特定のユーザーセッションは、ビューワーセッションが閉じられるまで特定のディストリビューションに維持されます。検証が完了したら、1 回の操作でステージング設定を本番環境に昇格させます。詳細な手順については、「  Use CloudFront continuous deployment to safely validate CDN changes  」を参照してください。 図 1：CloudFront 継続的デプロイメント機能を使用したプライベート VPC オリジンへの移行 戦略 1 の考慮事項  キャッシュ ：プライマリディストリビューションとステージングディストリビューションはキャッシュは別管理。CloudFront がステージングディストリビューションに最初のリクエストを送信した時点ではキャッシュは空であり、ビヘイビア設定に基づいてキャッシュを開始 トラブルシューティング ：移行中に問題が発生した場合は、継続的デプロイメントポリシーでトラフィックの重みを 0% に削減。問題を調査・解決してから、トラフィックの割合を徐々に増加 セッション状態 ：継続的デプロイメントポリシーを無効または有効にすると、CloudFront はすべてのセッション (アクティブなセッションを含む) をリセットし、すべてのリクエストを新規として処理。セッションスティッキネスの無効化・有効化時にも同様 プロトコルサポート ：現在、HTTP3 は継続的デプロイメントポリシーでは未サポート ポリシー ：重みベースポリシーを使用する場合、重みは 0〜15 の数値で指定 戦略 2：CloudFront エッジ関数の使用  既存の CloudFront ディストリビューションに、作成したプライベート VPC オリジンをオリジンとして追加します。次に、viewer-request トリガーを使用した  CloudFront Function  (サンプルコードは以下) を作成し、カスタムヘッダーまたはパブリックオリジンとプライベート VPC オリジン間の重み付けトラフィック分割に基づいて、トラフィックを VPC オリジンに振り分けます。その他の例については、GitHub の  amazon-cloudfront-functions サンプル を参照してください。 import cf from 'cloudfront'; const kvsHandle = cf.kvs(); // Configuration: Update these values to match your CloudFront distribution origins const PUBLIC_ORIGIN_DOMAIN = 'your-public-origin.example.com'; // Replace with your public origin domain const PRIVATE_ORIGIN_ID = 'your-private-origin-id'; // Replace with your private VPC origin ID async function handler(event) { const request = event.request; try { const config = await kvsHandle.get('routing_mode', { format: 'json' }); if (config.mode === 'header') { const routeHeader = request.headers['x-route-origin']; if (routeHeader && routeHeader.value === 'public') { cf.updateRequestOrigin({ domainName: PUBLIC_ORIGIN_DOMAIN }); } else if (routeHeader && routeHeader.value === 'private') { cf.selectRequestOriginById(PRIVATE_ORIGIN_ID); } } else if (config.mode === 'weighted') { const hash = simpleHash(event.viewer.ip); if (hash % 100 < config.weight_percentage) { cf.selectRequestOriginById(PRIVATE_ORIGIN_ID); } else { cf.updateRequestOrigin({ domainName: PUBLIC_ORIGIN_DOMAIN }); } } } catch (error) { console.log('Routing error: ' + error); } return request; } function simpleHash(str) { let hash = 0; for (let i = 0; i < str.length; i++) { hash = ((hash << 5) - hash) + str.charCodeAt(i); hash = hash & hash; } return Math.abs(hash); } リクエストのルーティングモードは KVS で定義し、キーを「routing mode」、値を  {"mode": "weighted", "weight_percentage": 70}  または  {"mode": "header"}  に設定します。テストを開始するには、パブリックオリジンにトラフィックを転送する対象のビヘイビアに CloudFront Function を関連付けます。 まず、KVS の値を  {"mode": "header"}  に設定します。カスタムヘッダー  x-route-origin  の値を  public  または  private  に指定したリクエストを CloudFront に送信してテストを開始します。テストフェーズ中に発生する可能性のある問題を迅速に解決できます。 設定、ネットワーク、アプリケーションのパフォーマンスメトリクスを検証します。明らかな問題を解決した後、KVS を更新して重み付けでトラフィックをルーティング  {"mode": "weighted", "weight_percentage": 5}  します。まずトラフィックの  5%  をプライベートオリジンに送信し、 weight_percentage  を徐々に  100%  まで増加させます。プライベートオリジンがトラフィックを受信し、期待どおりに動作していることを確認したら、キャッシュビヘイビアを更新して、現在のパブリックオリジンの代わりにプライベートオリジンを使用するように変更します。その後、トラフィックがプライベート VPC オリジンにルーティングされていることを検証します。エラーがないことを確認したら、キャッシュビヘイビアから CloudFront Function を削除します。他のキャッシュビヘイビアについても同じプロセスを繰り返します。 図 2：CloudFront エッジ関数を使用したプライベート VPC オリジンへの移行 戦略 2 の考慮事項  キャッシュ ：ディストリビューションは、設定されたキャッシュビヘイビアに基づいてリクエストをキャッシュ トラブルシューティング ：移行中に問題が発生した場合は、トラフィックの重みを 0% に削減。問題を調査・解決してから、トラフィックの割合を徐々に増加 オリジン設定 ：CloudFront Function でオリジン固有の設定を追加する場合は、 オリジン変更のヘルパーメソッド を参照。特に指定がない限り、すべての設定はオリジン設定または関連するキャッシュビヘイビア設定から継承 CloudFront Function ：ビヘイビアに既存の CloudFront Function が関連付けられている場合は、オリジン選択ロジックをサブ関数として実装し、メイン関数から呼び出す形で統合 KVS ：関数コードの複雑さを軽減し、コード変更のデプロイなしでデータを更新可能。詳細な手順については、「 CloudFront Functions 用の低レイテンシーデータストア、Amazon CloudFront KeyValueStore の紹介 」を参照 戦略 3：既存ディストリビューションの更新 (インプレース移行)  このインプレースアップグレード戦略は、既存の CloudFront ディストリビューションを直接変更して、パブリックオリジンを VPC オリジンに置き換える方法です。このアプローチは最も迅速な移行方法ですが、サービスの中断を最小限に抑えるために、慎重な計画とメンテナンスウィンドウが必要です。この戦略を図 3 に示します。 まず、既存の CloudFront ディストリビューションに新しい VPC オリジンを作成し、キャッシュビヘイビアを更新してパブリックオリジンの代わりに新しいプライベートオリジンにトラフィックをルーティングします。すべてのビヘイビアの更新と検証が完了したら、古いパブリックオリジンの設定を削除できます。このアプローチは、プリプロダクション環境やテスト環境で VPC オリジンをテストする場合に最適です。本番環境では、戦略 1 に従うことを推奨します。本番ディストリビューションにインプレースで変更を行う場合は、アプリケーションに十分なメンテナンスウィンドウを確保してください。また、切り替え中にワークロードが中断に許容できることを確認してください。 図 3：キャッシュビヘイビアの更新によるプライベート VPC オリジンへの移行 (インプレース移行) 戦略 3 の考慮事項  CloudFront ディストリビューションの更新 ：新しい設定が更新されると、CloudFront はすべてのエッジロケーションへの変更の伝播を開始。エッジロケーションで設定が更新された後、CloudFront はそのロケーションから新しい設定に基づいてコンテンツの配信を即座に開始。それまでは、CloudFront は古い設定でコンテンツを配信 サービスの中断 ：ビヘイビアの更新プロセス中に、新しく作成したリソースでネットワークやアプリケーションに関連する問題が発生する可能性があるため、トラブルシューティング用に十分なメンテナンスウィンドウを確保 ロールバックの複雑さ ：ロールバックにはビヘイビアの変更を元に戻す必要があり、パブリックオリジンの再作成が必要になる場合あり。変更を行う前に元の設定を記録しておくこと。 テスト要件 ：本番環境でインプレースアップグレードを実施する前に、非本番環境で VPC オリジンの接続性を十分にテスト ビヘイビアの依存関係 ：複雑な設定を持つ複数のビヘイビアがある場合は、体系的に更新し、各変更を個別に検証 戦略 4：マルチテナントディストリビューションのプライベート VPC オリジンへの移行 マルチテナント CloudFront ディストリビューションは、パスベースまたはホストベースのルーティングを使用して、単一のディストリビューションで複数のアプリケーション、顧客、またはビジネスユニットにコンテンツを配信します。これらのディストリビューションを VPC オリジンに移行するには、分離とセキュリティ境界を維持しながら、どのテナントにも影響を与えないよう慎重な計画が必要です。この戦略を図 4 に示します。 マルチテナントディストリビューションでは、各テナントは親ディストリビューションから設定を継承し、独自のドメインを持ちます。オリジンはメインディストリビューション上で作成・設定され、テナントへのトラフィックルーティングのテンプレートとして使用されます。そのため、インプレース移行を行うと、オリジンがテナント間で共有されているため、すべてのテナントに影響を与える可能性があります。 推奨されるアプローチは、VPC オリジンを使用した新しいマルチテナントディストリビューションを作成し、各テナントを新しいディストリビューションに関連付けることです。これにより、各テナントを個別にテストし、テナントを 1 つずつ VPC オリジンを使用した新しいディストリビューションに移行できます。 図 3：キャッシュビヘイビアの更新によるプライベート VPC オリジンへの移行 (インプレース移行) 戦略 4 の考慮事項  ビヘイビアの整理 ：移行中の混乱を避けるため、テナントごとにビヘイビアがパスパターンまたはホストヘッダーで明確に整理されていることを確認 クロスアカウントの複雑さ ：異なるテナントのオリジンが異なる AWS アカウントに存在する場合は、AWS RAM を使用して各アカウント間で VPC オリジン共有を適切に設定 テナントごとのテスト ：次のテナントに進む前に、各テナントの移行を個別に検証 ロールバック計画 ：他のテナントに影響を与えずに個別のテナントをロールバックする必要がある場合に備え、テナントごとにロールバック手順を個別に文書化 コミュニケーション ：各テナントまたはアプリケーションオーナーと調整し、希望するメンテナンスウィンドウ中に移行をスケジュール その他の考慮事項 Origin Shield ：パブリックオリジンで Origin Shield を使用していた場合、プライベート VPC オリジンでも引き続き使用可能。 オリジングループ ：現在の CloudFront ディストリビューションでオリジングループを使用している場合は、新しいオリジングループを作成し、ビヘイビアをオリジングループにマッピングするよう設定が必要 レイヤー 7 の保護 ：AWS Shield Standard は、幅広い DDoS 攻撃から CloudFront ディストリビューションを保護。AWS では、プライベート VPC オリジンをレイヤー 7 の標的型攻撃から保護するために、AWS Shield Advanced および AWS WAF のインテリジェントな脅威緩和メカニズム (レイヤー 7 DDoS 緩和ルール、Bot Control など) によるディストリビューションの保護を推奨 クォータ ：CloudFront のクォータを確認し、必要に応じて移行前に VPC オリジンに関連するクォータを引き上げ クリーンアップ 継続的な課金を避けるため、トラフィックルーティングとテスト用に作成した未使用のリソースを削除してください。CloudFront ディストリビューションを削除する前に、すべてのトラフィックが移行済みで、DNS レコードが更新されていることを確認してください。移行テスト用にテスト ALB、NLB、または EC2 インスタンスを作成した場合は、不要であれば削除してください。 継続的デプロイ (戦略 1) を使用した場合は、ステージング設定をプライマリディストリビューションに昇格させます。エッジ関数 (戦略 2) を使用した場合は、CloudFront Function とその KVS の関連付けを解除して削除します。インプレース移行 (戦略 3) を使用した場合は、古いパブリックオリジンの設定を削除します。マルチテナントアーキテクチャ (戦略 4) を移行した場合は、すべてのテナントの移行完了後に古いマルチテナントディストリビューションを無効化して削除します。 クリーンアップが完了したことを確認するには、CloudFront コンソールでテスト関数と未使用のディストリビューションが削除されていることを確認します。さらに、 AWS Cost Explorer  を 24〜48 時間モニタリングし、一時リソースへの課金が停止していることを確認します。 まとめ VPC オリジンへの移行は、パブリックエンドポイントを排除することでセキュリティ体制を強化します。アクセス制御は CloudFront レイヤーで管理できます。CloudFront のパブリックオリジンからプライベート VPC オリジンへ移行するための 4 つの移行戦略は、それぞれ移行速度、リスク軽減、運用の複雑さの間で異なるトレードオフを持っています。最適な移行アプローチは、既存の構成、ビジネスニーズ、および運用要件によって異なります。 移行を始める準備はできましたか？ 最初のステップは、現在のディストリビューション構成を十分に理解することです。それにより、ご自身の環境に最適な戦略を選択するために必要な知識が得られます。詳細な設定ガイダンスとベストプラクティスについては、 CloudFront VPC オリジン のドキュメントをご覧ください。 CloudFront の機能やベストプラクティスに関する最新情報については、 AWS Networking and Content Delivery Blog  をフォローしてください。フィードバックがある場合は、コメントセクションにコメントを送信してください。質問がある場合は、 Amazon CloudFront re:Post  で新しいスレッドを開始するか、 AWS Support  にお問い合わせください。 著者 Kartik Bheemisetty Kartik Bheemisetty は US-ISV のお客様を担当するシニアテクニカルアカウントマネージャーであり、お客様が AWS クラウドサービスを活用してビジネス目標を達成できるよう支援しています。AWS のネットワークおよびコンテンツ配信サービスに関する専門知識を持っています。ベストプラクティスに関する専門的なガイダンスの提供、分野別専門家へのアクセスの促進、AWS の支出、ワークロード、イベントの最適化に関する実用的なインサイトの提供を行っています。 LinkedIn で彼とつながることができます。 Ravi Avula Ravi はエンタープライズアーキテクチャに注力する AWS のシニアソリューションアーキテクトです。ソフトウェアエンジニアリングにおいて 20 年の経験を持ち、決済業界でソフトウェアエンジニアリングおよびソフトウェアアーキテクチャの複数のリーダーシップ職を歴任してきました。 翻訳は Solutions Architect の長谷川 純也が担当しました。

本記事は 2026 年 3 月 16 日 に公開された「 Agentic AI in the Enterprise Part 2: Guidance by Persona 」を翻訳したものです。 これは、AWS Generative AI Innovation Center (以下「GenAIIC」)による2部構成シリーズのPart IIです。Part Iをご覧になっていない方は、「 Agentic AIの運用化 Part 1: ステークホルダー向けのガイド 」をご参照ください。 Agentic AIへの最大の障壁は、テクノロジーではありません。オペレーティングモデルです。Part 1では、エージェントから実際の価値を生み出している組織には3つの共通点があることを確認しました。仕事を詳細に定義すること、エージェントの自律性に明確な境界を設けること、そして改善を単発のプロジェクトではなく継続的な習慣として扱うこと。また、真に「エージェント向き」である仕事の4つの要素も紹介しました。仕事の目的および開始と終了が明確に定義可能、複数のツールを横断した判断が必要、仕事の成功が観察可能で測定可能、そして問題発生時の安全モードの存在。これらの基本的な要素がなければ、どれほど洗練されたエージェントでも研究室から出られません。 ここで、より難しい疑問が発生します。 誰が 、 どのように エージェントを機能させられるのでしょうか？ Part IIでは、共有された基礎的な情報を実際の行動に移す必要があるリーダーに直接語りかけます。各リーダーの役割には、それぞれ異なる責任、リスク、影響力のポイントがあります。P&Lを所有している、エンタープライズアーキテクチャを運営している、セキュリティをリードしている、データのガバナンスを定めている、またはコンプライアンスを管理しているかにかかわらず、このセクションはそれぞれの職務に合わせた言葉で書かれています。Agentic AIが成功するか、静かに消えていくかは、リーダーの理解と行動によって決まるからです。 Part II – ペルソナ別のガイダンス 事業部門オーナーへ：エージェントをKPIに紐づける P&Lを所有している方にとって、必要なのは新しいテクノロジーのおもちゃではありません。必要なのは、未解決のチケット数の削減、キャッシュコンバージョンサイクルの短縮、カート放棄率の低下、コンプライアンス例外の減少など、実際のビジネス指標への寄与です。エージェントが有用なのは、これらのビジネス指標に直接結び付けられる場合のみです。 最初のステップは、新しい従業員を採用するときと同じように、エージェント向けのジョブディスクリプションを作成することです。「エージェントは、Xを受け取り、Yを確認し、Zを実行し、完了したらこのチームに引き継ぐ」。運用上の言葉で完了が何を意味するかを明文化してください。たとえば、応答時間、品質基準、エスカレーションのトリガー、顧客向けのコミットメントなどが該当します。 2番目のステップは、ビジネスケースを自分のチームがすでに追跡している数字に結び付けることです。このワークフローを通過する案件は週に何件ありますか？各案件は、人件費、手戻り、棄却のそれぞれにどれくらいのコストがかかりますか？待ち行列で滞留している時間はどれくらいですか？何かが欠けているか誤っているために差し戻される頻度はどれくらいですか？今日これらの質問に答えられない場合、最初にやるべきことはエージェントの構築ではありません。ワークフローの可視化です。 3番目のステップは優先順位付けです。取り組みの初期段階では、最も有用なエージェントは、引き継ぎを削減するものであることが多いです。受信したリクエストを読み取り、複数のシステムからコンテキストを収集し、計画を提案し、すべてが準備された状態でその計画をチームに渡します。エージェント自体がループを完結させることはないかもしれませんが、何時間、何日もの往復作業を削減できます。このようなコスト削減の成果は、CFOとの信頼関係を構築し、後により野心的な収益重視のユースケースを追求するための政治的リソースを与えてくれます。 事業部門オーナーは、モデルやプロンプトを理解する必要はありません。必要なのは、自分の指標に直接結び付いたエージェント業務の小さなポートフォリオを所有すること、そしてすべての取り組みが表面的な企画書ではなく、明文化された業務契約から始まることを主張することです。 CTOまたはチーフアーキテクトへ：必要なエージェントは10個なのか100個なのかを決める CTOにとって、最大のリスクの1つは成功です。最初のエージェントがうまく機能すると、他のチームも欲しがります。各チームが独自のスタック（独自のフレームワーク、独自のコネクタ、独自のアクセスモデル）を構築すると、見た目も異なり、テスト方法も異なり、全体として監視することが不可能なエージェントの動物園になってしまいます。 アーキテクチャの問いは「言うは易く、行うは難し」です。必要なのは、10個の優秀だが単発のエージェントなのか、それとも100個のエージェントを安全にサポートできるシステムか？ システム構築のアプローチには、早期にいくつかの困難な作業が求められます。すべてのエージェントが顧客データを読み取ったり、チケットを更新したり、支払いを予約したりする必要があるときに、同じインタフェースを呼び出すように、ツールの公開方法を標準化する必要があります。また、ワークフロー全体の設計において「思考」と「実行」を分離する必要があります。1つのコンポーネントが計画し、別のコンポーネントがツールを呼び出し、別のコンポーネントがコンプライアンスをチェックし、別のコンポーネントがユーザーに決定を説明する…といった設計が求められます。観察可能性とデバッグがユースケース全体で機能するよう、一貫した形式で意思決定の痕跡を記録することも必要です。 また、エージェントを単発で実行されるスクリプトではなく、長期運用されるサービスとして考えることも求められます。エージェントには、アイデンティティ、権限、ローテーション、ライフサイクル管理、そして利用者に影響を与えずにアップグレードする方法が必要です。初期段階から着手が必要な作業は増えますが、これにより、エージェントが必要な10番目のチームに対して、ゼロから始めることなく「はい」と言えるようになります。 CTOの仕事は、一人で最高のエージェントフレームワークを選ぶことではありません。多くのチームが安全に、迅速に、一貫してエージェントを提供できるようにする堅牢な基盤（アイデンティティ、ポリシー実施、ロギング、コネクタ、評価機能）を構築することです。 CISOへ：エージェントをソフトウェアではなく同僚とみなす セキュリティに責任を持つ人は、アセット（例：システム、データストア、認証情報）の単位で考えることに慣れています。エージェントは、脅威モデルに新たな要素を追加します。瞬時に意思決定を行い、アクションを実行できる権限を有するエンティティです。 エージェントを単なる別のアプリケーションとして扱ってはいけません。エージェントは同僚に近い存在です。アカウントがあり、役割を持ち、使用できるツールを持っています。間違いを犯したり、誤った設定がされていたりすることもあります。 実用的なアプローチは、人間に適用するのと同じ真剣さで、エージェントのアイデンティティを設定することです。各エージェントには、独自の認証情報、独自の権限、そして独自の監査証跡が必要です。実行されるサービスアカウントのすべての権限を継承すべきではありません。エージェントが機密データを読み取ったり、高リスクのツールを呼び出したりする場合、チームが認識できる形でログに記録される必要があります。 エージェントを適切に停止する方法も必要です。設計ドキュメントの一行として記すのではなく、実際に機能する停止スイッチです。「このクラスのアクションには常に人間の承認が必要」と定め、エージェントのプロンプトだけでなく、ツールレベルでそれを実施するポリシーを実装する必要があります。また、通常から逸脱したエージェントの挙動を監視することも意味します。通常よりもはるかに頻繁にツールを呼び出したり、以前は必要としなかったデータを読み始めたりする挙動などを指します。 Agentic AIにうまく適応するCISOは、エージェントの自律性を完全にブロックしようとはしません。自律性が許容される場面、信頼するために必要な証拠、そしてその信頼が破られたときに何が起こるかを定義します。設計の議論に早期に参加し、ポリシーを最後のゲートとして適用するのではなく、エージェントの設計の一部として組み込みます。 チーフデータオフィサーへ：データを「退屈」にする エージェントは、すでに持っているデータ基盤を増幅します。データが断片化され、古く、文書化されていない場合、エージェントはこれらの問題をすぐに顕在化します。データに一貫性があり、適切なガバナンスが施され、理解しやすい場合、エージェントはその価値を倍増させます。 エージェント時代におけるCDOの仕事は、良い意味でデータの扱いを「退屈」にすることです。たとえば、エージェントが「このしきい値を超えるすべての未解決のクレームを表示」と尋ねたとき、どの地域や事業部門で動作しているかに関係なく、一貫した答えが得られることです。また、「顧客健全性スコア」の定義が1つ存在し、人間とエージェントの両方が使用できるほど十分に文書化されていることも含みます。さらに、何かがうまくいかなかったとき、意思決定の根拠となるメトリクスや特徴量を通じて、ソースシステムまで追跡できるような明確なデータリネージの実現も重要です。 また、現実に照らし合わせた判断も必要です。ワークフローの中には、依存するデータが不完全もしくは矛盾を含んでいるため、エージェントによる自律的な意思決定の準備ができていないものもあります。優れたCDOはこの現実を受け入れます。ただし、単純に「エージェントをサポートできない」とは言いません。「現状では、この類の業務をサポートできます。別の業務を自動化したいのであれば、その前に必要なデータ改善はこれです」などといった助言を行うことができます。 CDOがエージェントの議論に対して提供できる最も価値のある貢献の1つは、どの領域が本番化可能なデータを持っているか、どれが進行中か、そして地雷がどこにあるかを示すマップ作りです。このマップがあれば、エージェントの実装の途中でデータ負債を発見する状況に陥らず、最初のエージェント適用業務の堅実な選択が可能です。 チーフデータサイエンスまたはAIオフィサーへ：評価こそが真のプロダクト データサイエンスまたはAIをリードする立場にいる場合、ついモデルに注目しがちです。どの基盤モデルを選び、どのファインチューニング手法を適用し、どのベンチマークスコアを目指すかなどの決定は確かに重要です。しかし、真に目指すべきプロダクトは、モデルを中心に構築された評価システムです。 エージェントは、ベンチマークが測定できない形で失敗する可能性があります。ループに陥ったり、ツールを誤って呼び出したり、もっともらしく見えるが誤った方法でタスクを中途半端に完了したりします。クリーンなテストデータではうまく動作しますが、誰もテストに含めることを想定していなかったエッジケースで崩壊します。効果的な評価システムは3つのことを行います。 第一に、実際の業務のテストへの変換です。エージェントが本番環境で間違いを犯した場合、そのシナリオは継続的に拡充される評価テストスイートの一部になります。時間の経過とともに遭遇する最も困難なケースが、エージェントの劣化を防ぐガードレールになります。 第二に、自動的な実行です。プロンプト、モデル、ツール、または検索インデックスに変更があった場合、その変更が公開される前に評価をトリガーします。このような仕組みの導入により、抜き取りチェック（と運）に頼るのではなく、変更を迅速に繰り返す自信を与えてくれます。 第三に、ビジネスが重視することの測定です。レイテンシやツール成功率などの技術的メトリクスも重要ですが、タスク完了率、エスカレーション率、意思決定あたりのコスト、人間がエージェントの推奨をそのまま受け入れる割合なども計測しましょう。これらの数字が可視化され、改善されると、事業部門からの信頼が生まれます。 エージェントの評価に早期に投資すると、モデルの選択という困難な課題がよりシンプルになります。実際のタスクでモデルがどのように動作するかを確認できるようになれば、「どのモデルが最適か？」という議論は、哲学的なものではなく、根拠に基づいた比較になります。 コンプライアンスまたは法務責任者へ：監査を想定した設計 コンプライアンスまたは法的リスクに責任を持つ方にとって、Agentic AIはおそらく動く標的のように見えます。規制は常に進化している一方、ベンダーのマーケティング施策はその規制よりも先に行っています。すべての基準が確定するまで組織を凍結することはできませんが、「ガバナンスは後で考える」を容認することもできません。 実用的なアプローチは、監査から逆算することです。規制当局または内部監査委員会が「この日に、なぜこのエージェントはこのアクションを取ったのか？」と尋ねることを想像してください。そして、その質問に明確かつ迅速に答えるために必要な証拠をすぐに決定してください。 これはいくつかの設計上の選択を意味します。すべてのエージェントは入力された情報、呼び出したツール、検討したオプション、選択したもの、適用したルール、などといった証跡を残す必要があります。与信審査、保険引受、雇用関連のアクションなどのリスクが高い業務領域では、人間が判断のループに留まり、エージェントの役割は助言的または準備的である必要があります。このような場合、データの収集、証拠の整理、アクションの提案などといったエージェントのログに加え、人間による承認も記録の一部に含める必要があります。 また、エージェントのユースケース案は全て許可すべきではありません。フレームワークと統制が成熟するまで、規制のレッドゾーンに存在するユースケースはあります。あなたの仕事は、これらの境界線を早期に明確にすることです。明確な条件で一部の案に「はい」と言い、特定の前提条件で他のものに「後で」と言い、別のものには明確な根拠に基づいて「いいえ」と言えるとき、あなたはブロッカーではなく推進者になることができます。 リーダーシップチームの他のメンバーに対してあなたができる最も役立つことの1つは、「責任あるAIが必要」のような抽象的な心配を、提案された各エージェントを活用する前に適用できる具体的なチェックリストに変えることです。 次のアクション ここまで説明したパターンに聞き覚えがあれば、あなたは決して遅れていません。ほとんどの企業が同じような立ち位置にいます。前進する企業を分けるのは、Agentic AIを技術的な実験ではなく、オペレーティングモデルの課題として扱う決断ができるかです。まず初めにできる5つのアクションを示します： 適切なメンバーを招集する。 事業部門オーナー、CTO、CISO、CDO、AI/データサイエンスリーダー、コンプライアンスリードを集めてください。デモを作る・見せるためではなく、実用化につながる作業セッションが目的です。そして、各人に1つの質問に答えてもらいます：「実際のワークフローでエージェントを本番環境に投入することを妨げている最大の障害は何か？」 1つのユースケースではなく、1つの業務を選ぶ。 明確な開始点、明確な終了点、定義されたツール、チーム外の誰かが検証できる成功指標を持つ、1つの具体的な業務を特定します。エージェントのためのジョブディスクリプションを一緒に作成します。選択した業務の「完了」状態がどのようなものかについて合意できない場合、解決すべき最初の問題を見つけたことになります。 準備状況マップを作成する。 CDOとCISOに、現状どのデータドメインとシステムが自律的な意思決定の本番化のための準備ができているか、どこを先に改善する必要があるのか、そしてどこに絶対的な制約があるかを共同で描いてもらいましょう。この1ページのマップで、何か月もの無駄な努力を省くことができます。 定期的な検証にコミットする。 部門横断チームがエージェントの振る舞い、うまくいったこと、うまくいかなかったこと、調整すべきことを検証する定期的なレビュー（週次または隔週）を設定します。エージェントのローンチ時にのみ評価するのは、デモを構築するときです。継続的な検証を通じてのみ、組織のエージェント活用能力を構築することができます。 ガバナンスを起動ゲートではなく、設計インプットにする。 監査人が6か月後に「なぜこのエージェントはこれを行ったのか？」と尋ねた場合に必要な証拠を今決定してください。その証拠を、最初のコード行が書かれる前にアーキテクチャに統合します。 Agentic AIから実際の価値を生み出している企業は、業務を正確に定義し、自律性に意図的な境界を設け、評価に執拗に投資し、共有されたオペレーティングモデルの周りでステークホルダーを調整するといった地道な作業を行うことでその領域に到達していることを覚えておきましょう。 Generative AI Innovation Centerとの協働 上記のジャーニーを一人で進む必要はありません。最初のエージェントパイロットを計画している場合でも、企業全体の能力への拡張を図っている場合でも、AWS Generative AI Innovation Center にご連絡いただければ、お客様のワークフロー、データ、ビジネス成果に基づいた対話を始めることができます。 著者について Nav Bhasin は、AWS Generative AI Innovation Centerのシニアデータサイエンスマネージャーです。エンタープライズのお客様がAgentic AIのコンセプトから本番展開へと進む過程を加速させています。産業、エネルギー、ヘルスケア分野でAI製品を構築してきた10年以上の経験を持ち、AWSでは6年間、GenAIアーキテクトと科学者のグローバルチームを率い、Amazon Bedrock、Amazon SageMaker、AgentCoreなどの製品を本番採用へと導く中心的な役割を果たしてきました。GenAIICへの着任前は、AWSの生成AIプロダクトポートフォリオのGTMアーキテクチャおよびデータサイエンスチームを率いていました。AWS入社前は、Utopus InsightsでHead of Data Science and Engineeringを務め、HoneywellではEngineering and Architectureを統括していました。NavはMBAと電子工学の修士号を保有しています。 Sri Elaprolu は、AWS Generative AI Innovation Centerのディレクターです。エンタープライズおよび政府組織向けの最先端AIソリューションを実装するグローバルチームを率いています。AWSでの13年間の在職中、グローバル企業や公共部門組織と協働するMLサイエンスチームを率いてきました。AWS入社前は、Northrop Grummanで製品開発およびソフトウェアエンジニアリングのリーダーシップ職を14年間務めました。Sriは工学修士とMBAを保有しています。

本記事は 2026 年 3 月 6 日 に公開された「 Operationalizing Agentic AI Part 1: A Stakeholder’s Guide 」を翻訳したものです。 Agentic AIは、単にオンにする機能ではありません。仕事の定義、担当者、意思決定の方法そのものを変革するものです。 多くの企業が、これを痛感しています。Agentic AIのパイロットプロジェクトを立ち上げても、実際の業務プロセスやシステム、ガバナンスに直面した途端に行き詰まってしまうのです。曖昧なユースケース、実際のデータに対応できないプロトタイプ、統制を超えた自律性、リリースを阻むコンプライアンス要件、自律的な意思決定には不十分なデータセットなど、同じパターンが幾度も繰り返されます。これらの根底には、共通の問題があります。それは、成功の定義についてステークホルダの合意が得られていないということです。 AWS Generative Innovation Center (以下「GenAIIC」) は、1,000社以上のお客様のAI本番環境への移行を支援し、生産性向上において数百万ドルの成果を実現してきました。サイエンティスト、ストラテジスト、機械学習のエキスパートから構成されるGenAIICの部門横断チームは、生成AI活用アイデアの創出から実用化まで、お客様と協働しています。そして近年、GenAIICが支援するプロジェクトではエージェントの活用が増えています。 本記事では、CTO、CISO、CDO、Chief Data Science/AI責任者といったC-suite全体のリーダー、さらにはビジネスオーナーやコンプライアンスリーダーに向けたAgentic AIの実運用に関するガイダンスをお届けします。我々が得ている核心的な知見とは、Agentic AIがうまく機能する場合、それは魔法のようなソフトウェアというよりも、適切に運営されているチームに似ているということです。うまく機能しているAgentic AIには、各エージェントに明確な役割、監督者、プレイブック、そして継続的な改善の仕組みが与えられています。 本記事は2部構成シリーズのPart Iです。 この記事は、Agentic AIの実運用に関する基本的な理解の確立を目的とします。なぜビジネス価値の理想と現実とのギャップが主に実行の問題なのか、どのようにすれば実業務をエージェント向きにできるのかについて解説します。Part IIの記事では、各C-suiteのペルソナに対し、それぞれの責任に即した言葉で直接語りかけます。 企業が直面する共通の課題 ビジネス価値のギャップは主に働き方の問題です。 経営会議で「AIへの投資は十分ですか？」という質問への答えはほぼ必ず「はい」です。しかし、「AIエージェントによって実質的に改善された具体的なワークフローは何で、それをどう把握していますか？」と尋ねると、会議室は静まり返ります。 この2つの答えの間にあるのは、基盤モデルやベンダーの問題ではありません。欠けているのはオペレーティングモデルです。エージェントが目に見える価値を生み出している組織では、次の3つが共通して見られます。 仕事が詳細に定義されている。 何が入力され、何が起こり、仕事の「完了」が何を意味するかを、ステップごとに説明できます。また、問題が発生したときに何が起こるかも説明できます。 エージェントの自律性に境界がある。 エージェントには、明確な権限の範囲、明示的なエスカレーションルール、そして人間が意思決定を確認し上書きできる仕組みが用意されています。 改善が習慣化されている。 プロジェクトとしてではなく、定期的な習慣として、チームが前週のエージェントの振る舞い、役立った点、摩擦を生んだ点、次に変更すべき点を確認しています。 これらが欠けている組織では、AIプロジェクトの頓挫でよく見られる現象が発生します。すなわち、研究フェーズから抜けられない概念実証、数か月後に静かに終了するパイロット、そして「次に何ができるか？」と尋ねることをやめ、「なぜこれほどのコストをかけているのか？」と問い始めるリーダー、といった現象です。 エージェントに適した仕事とは 多くの組織は「どこでエージェントを使えるか？」という問いから始めます。しかし、より良い出発点は「どこに、すでにエージェントが担える仕事のように構造化された業務があるか？」です。実際には、それは次の4つの要素を意味します。 第一に、仕事に明確な開始、終了、目的があること。 クレームが届く、請求書が届く、サポートチケットが起票される。エージェントは、作業を開始するのに十分な情報が揃っているか、どの目標に向かって作業すべきか、タスクが完了したとき、または引き継ぎが必要なときを認識できます。これは単なるトリガーとゴールではありません。エージェントは、個別の指示なしに妥当なバリエーションに対応できるよう、仕事の背後にある意図を十分に理解する必要があります。チームが、例外やエッジケースの処理方法を含めて、特定のタスクの適切な完了がどのようなものかを明確に説明できない場合、その仕事はまだエージェント化の準備ができていません。 第二に、仕事に複数のツールを横断した判断が必要であること。 エージェントは固定されたスクリプトに従うものではありません。必要な情報について推論し、どのシステムに問い合わせるかを決定し、得られた情報を解釈し、コンテキストに基づいて適切なアクションを判断します。従来の自動化との違いは、業務プロセスがハードコーディングされていない点です。エージェントはアプローチを適応させ、バリエーションに対応し、状況が自身の能力の範囲外であることを認識します。また、エージェントはツールを通じて行動するため、それらのツールはエージェントより先に存在している必要があります。組織のシステムには、エージェントによるデータの読み取り、更新の書き込み、トランザクションの開始、コミュニケーションの送信のための呼び出しが行える、明確に定義された安全で信頼性の高いインタフェースが必要です。現状の業務プロセスが、メールやスプレッドシートに基づいて人間が推論を行う前提となっている場合、エージェントのユースケースを実行する前に、プロセス設計とツール整備の両方が必要です。 第三に、成功の観察と測定が可能であること。 チームに所属していない人がエージェントからの出力を見て、憶測なしで「正しい」または「修正が必要」と判断できる必要があります。これは、たとえばチケットが時間内に解決されたか、フォームが完全で一貫しているか、トランザクションがバランスしているか、顧客が必要な回答を得たかを確認することを意味します。しかし、この観察可能性（オブザーバビリティ）は出力の抜き取りチェック以上のものである必要があります。すなわち、エージェントがどのように答えに到達したか、その際に使用したデータ、呼び出したツール、検討したオプション、そしてなぜ特定の選択をしたのかを見なければいけません。エージェントによる推論を評価できなければ、エージェントを改善することはできません。また、エージェントの判断に問題が発生した際の対応も困難です。 第四に、問題発生時の安全モードがあること。 初期のエージェント候補として最適なのは、ミスが迅速に発見可能であり、低コストで修正でき、不可逆的な損害を生まないタスクです。エージェントがサポートチケットを誤分類した場合、再ルーティングできます。不正確な回答のドラフトを生成した場合、送信前に人間が編集できます。しかし、エージェントが支払いを承認したり、取引を実行したり、法的拘束力のあるコミュニケーションを行ったりする場合の誤りに対するコストは根本的に異なります。アクションが可逆的な業務、またはエージェントの出力が人手のアクションの推奨事項となる業務から始めてください。エージェントに対する信頼、統制、評価がこなれてくれば、エージェントが自律的にループを完結させる、よりリスクの高い仕事への移行もしやすくなります。 これら4つの要素が揃っている業務は、エージェントの仕事になり得ます。他方、これらの要素が欠けている場合、エージェント活用に関する議論は 「アシスタント」「コパイロット」「自動化」 といった、各ステークホルダーにとって異なる意味を持つ曖昧な内容に陥ってしまいます。 次のアクション 実行ギャップを埋める準備はできていますか？ Part I（本記事）で説明したパターンは仮想的なものではありません。あらゆる規模の組織、あらゆる業界で実際に起きていることです。幸い、現在地と目指す場所の間のギャップは、テクノロジーのギャップではなく、実行のギャップです。そして、実行のギャップの多くは解決可能です。 今すぐにできる3つのこと： 仕事を明確に決める。 開始と終了の定義が明確に決まっており、「完了」状態が測定可能なワークフローを、組織内から1つ選んでください。それがエージェント活用の最初の候補です。 本質的な議論をする。 次のリーダーシップミーティングで、「AIへの投資は十分ですか？」と安直に尋ねるのではなく、「AIエージェントによって実質的に改善された具体的なワークフローは何ですか？ なぜそうだと判断できるのですか？」と尋ねてください。その後に続く沈黙が、自社が進むべきロードマップを示している可能性があります。 ジョブディスクリプションを作る。 技術的な意思決定を行う前に、エージェントが何をするか、どのようなツールが必要か、成功とは何か、失敗したときに何が起こるかを書き出してください。そのページを埋められない場合、エージェントを構築する準備はできていないと言えます。これは、組織にとって貴重な情報となりえます。 Part IIの予告：ペルソナ別のガイダンス Agentic AIが実行の問題であることを知ることと、それを解決する上での自身の役割を知ることは別のことです。 Part IIでは、実務でAgentic AIを機能させる必要があるリーダーに直接語りかけます。KPIに紐づいたエージェントを必要とするビジネスオーナー、10個の単発エージェントもしくは100個のエージェントに対応可能なプラットフォームの要否を決定するCTO、エージェントをソフトウェアではなく同僚として扱う必要があるCISO、データを最良の方法で「退屈」にする必要があるCDO、エージェントに対する評価こそが製品であるChief AI Officer、そして監査が発生する前に監査のための設計をしなければならないコンプライアンスリーダーなどが該当します。 各ペルソナがそれぞれ負うべき責任、そして具体的なアクションを指し示します。 Generative AI Innovation Centerとの協働 上記のエージェントジャーニーを一人で進む必要はありません。最初のエージェントパイロットを計画している場合でも、企業全体の能力への拡張を図っている場合でも、 AWS Generative AI Innovation Center にご連絡いただければ、お客様のワークフロー、データ、ビジネス成果に基づいた対話を始めることができます。 著者について Nav Bhasin は、AWS Generative AI Innovation Centerのシニアデータサイエンスマネージャーです。エンタープライズのお客様がAgentic AIのコンセプトから本番展開へと進む過程を加速させています。産業、エネルギー、ヘルスケア分野でAI製品を構築してきた10年以上の経験を持ち、AWSでは6年間、GenAIアーキテクトと科学者のグローバルチームを率い、Amazon Bedrock、Amazon SageMaker、AgentCoreなどの製品を本番採用へと導く中心的な役割を果たしてきました。GenAIICへの着任前は、AWSの生成AIプロダクトポートフォリオのGTMアーキテクチャおよびデータサイエンスチームを率いていました。AWS入社前は、Utopus InsightsでHead of Data Science and Engineeringを務め、HoneywellではEngineering and Architectureを統括していました。NavはMBAと電子工学の修士号を保有しています。 Sri Elaprolu は、AWS Generative AI Innovation Centerのディレクターです。エンタープライズおよび政府組織向けの最先端AIソリューションを実装するグローバルチームを率いています。AWSでの13年間の在職中、グローバル企業や公共部門組織と協働するMLサイエンスチームを率いてきました。AWS入社前は、Northrop Grummanで製品開発およびソフトウェアエンジニアリングのリーダーシップ職を14年間務めました。Sriは工学修士とMBAを保有しています。

みなさん、こんにちは。AWS ソリューションアーキテクトの古屋です。 日々のお客様との会話の中で、「業務課題を解決するために新たな機能やシステムの開発が必要ではあるが、外部リソースを確保する余力もなく、自社に十分なエンジニアもいないため実現が難しい」というお声をいただきます。同様のお悩みをお持ちの方も少なくないのではないでしょうか。 近年、そういった状況に対して、 Amazon Bedrock や Amazon Q Developer をはじめとする AWS の生成 AI サービスの登場により、限られた開発リソースの中でも、業務を最もよく知る現場の担当者自身が課題解決の仕組みを構築できる環境が整いつつあります。 今回は、まさに生成 AI を活かし、非エンジニアのメンバーが中心となって契約書管理 AI エージェントを構築された大成株式会社様の事例をご紹介します。本事例では、Amazon Q Developer によりプログラミング経験が限られたメンバーでも AWS 上でのシステム構築が可能となり、さらに Amazon Bedrock を利用することでインフラ構築や運用管理なしに Claude のような高性能な基盤モデルを API 一つで呼び出せるため、従来手作業で数十分かかっていた情報抽出を数分に短縮する仕組みを短期間で実現いただきました。 お客様の状況と経緯 大成株式会社様（以下、大成様）は、「ビルトータルソリューション」を掲げ、ファシリティマネジメント、プロパティマネジメント、不動産投資事業、修繕工事や改修工事などの建築事業を展開する総合サービス企業です。 大成様のプロパティマネジメント業務では、ビルオーナー様やテナント様との間で締結される多数の契約書が業務の根幹をなしています。しかしながら、従来の契約書管理では、以下の課題が存在していました。 契約書の検索が手作業に依存しており、必要な情報を見つけるために複数の PDF を開いて目視で確認する必要がある テナント様ごとに契約内容の仕様が異なるため、ビル名やテナント名だけでは目的の契約書にたどり着けない場合がある ビルオーナー様からの問い合わせに対し、契約書の特定から情報確認、回答までに多くの時間を要し、迅速な顧客対応の妨げとなっている これらの課題を解決するため、業務改善やシステム利活用を担当している IT 戦略推進室が本取り組みに参加しました。大成様では社内 SE、内製開発を行うエンジニアを擁していないため、同部にて生成 AI を活用した契約書管理システムの構築を検討されることになりました。 ソリューション／構成内容 本プロジェクトでは、非エンジニアのプロジェクトマネージャーが中心となり、Amazon Q Developer の支援を受けながらシステムを構築しました。Amazon Q Developer は自然言語での指示に基づいてコードを生成する AI アシスタントであり、プログラミング経験が限られた担当者でも実用的なシステムを構築できます。 本システムでは、Amazon Bedrock、 AWS Lambda 、 Amazon S3 、 Amazon DynamoDB を組み合わせて活用しています。Amazon Bedrock は生成 AI の中核を担い、Anthropic 社の Claude AI モデルを通じて契約書 PDF の解析と重要情報の抽出を実行します。 Amazon Bedrock + Claude を採用したポイントとして、Claude の高度な文書理解能力が挙げられます。契約書は法的な専門用語を含む複雑な文書であり、テナント様ごとにフォーマットが異なりますが、Claude は PDF などの非構造化データから文脈を理解した上で必要な情報を正確に抽出できます。また、AWS Lambda を中心としたサーバーレスアーキテクチャにより、非エンジニアが中心のチームでもインフラ管理に煩わされることなくシステムを運用できる点、そして日常的に使用している Slack との統合が容易で導入時の移行障壁を低く抑えられる点も、AWS を選択された理由です。 導入効果 実際にご利用いただいた結果、以下のような効果が得られています。 契約書からの情報抽出にかかる作業時間を 約 70〜80% 削減 。従来 1 件あたり数十分を要していた作業が数分で完了 将来的には、CSV 形式でのデータ出力機能を実装し、契約書情報の一括管理および分析を可能とする仕組みの構築を検討 AI による解析で情報抽出の精度と一貫性が向上し、人手による見落としや誤読のリスクを低減 Slack 上のシンプルなワークフローにより、従業員の受け入れがスムーズに また、非エンジニアでも Amazon Q Developer の支援により AWS の各種サービスを組み合わせた実用的なシステムを構築できることが実証されたことにより、他の業務領域でも生成 AI を活用した業務改善の取り組みが始まるきっかけとなっています。 大成様では今回の成功を踏まえ、契約書の自動要約機能や自然言語での高速検索機能の追加を検討されています。さらに、施設管理報告書の自動生成やメンテナンス記録の分析など、プロパティマネジメント業務全般での AI 活用拡大も計画されています。 お客様の声 大成株式会社 IT 戦略推進室 石川 静華様からは、「AWS のサービスを使うことで非エンジニアでも実業務の課題を自らの手で解決できる喜びを実感しました。」とのコメントをいただいています。 まとめ 今回は大成様が Amazon Bedrock と Amazon Q Developer を活用し、非エンジニアの手で契約書管理 AI エージェントを構築された事例をご紹介しました。Claude の高度な文書理解能力とサーバーレスアーキテクチャの組み合わせにより、専門的な開発リソースがなくても実用的な業務改善システムを実現されています。スモールスタートで確実に成果を出すアプローチは、これから生成 AI 活用を検討される企業にとっても参考になる取り組みです。 生成 AI を活用した業務改善にご興味をお持ちのお客様は、ぜひ AWS までお問い合わせください。 大成様 IT 戦略推進室 推進課 課長　田島 宏美 IT 戦略推進室 戦略課 主任　石川 静華 IT 戦略推進室 推進課 主任　鎌倉 由佳 Account Team： ソリューションアーキテクト　森   瞭輔 アカウントマネージャー　植木　輝 記事執筆： ソリューションアーキテクト　古屋　楓

本記事は、2025 年 12 月 10 日に公開された Games Industry Lens update for the well-architected framework を日本語に翻訳したものです。翻訳はソリューションアーキテクトの安藤怜央が担当しました。 ゲーム業界とライブサービスゲームが成長を続ける中、クラウドサービスは何百万ものプレイヤーに没入型の体験を提供する上で重要な役割を果たしています。世界中のゲーム開発チームは、Amazon Web Services (AWS) のインフラストラクチャを活用してゲームを構築、テスト、成長させています。彼らは分析を構築し、プレイヤーインサイトを獲得することで、開発を推進し、シームレスで低レイテンシーの体験を世界中に提供することに努めています。 本日、 AWS for Games チームは、AWS Well-Architected Games Industry Lens および ホワイトペーパー (Games Lens) のアップデート版 のリリースを発表できることを嬉しく思います。Games Lens は、クラウドでゲームを構築および運用する際の固有の特徴に対処することを目的としたベストプラクティスで構成されています。これらの推奨事項は、ゲーム業界の開発者、パブリッシャー、そして私たち自身の AWS for Games チームとの協働経験に基づいており、アップデートされた Games Lens に反映されています。Games Lens は、クラウドでゲームを構築および運用する際の特有の課題に対処するために設計されたベストプラクティスによって Well-Architected Framework を補完します。 以下は、Games Lens でカバーされている詳細なユースケースとパターンです。これには、スケーラブルなゲームバックエンドの開発、 Amazon GameLift を使用したマルチプレイヤーサーバーのオーケストレーションの効率化が含まれます。また、負荷テストの実施、開発および運用上の意思決定を行うためのデータのリアルタイム分析の実行も強調されています。 Games Industry Lens を使用する理由 新しい Games Industry Lens は、ゲーム固有の要件に沿った情報に基づいた設計上の意思決定を行うためのガイダンスを提供します。このレンズで詳述されているテクニックを適用することで、ゲームのインフラストラクチャの回復性、セキュリティ、効率性を検証できます。 Games Lens は、さまざまなゲームワークロードに共通する評価および改善領域を強調しています。また、AWS Well-Architected Framework の柱に沿って設計されており、以下の分野にわたる洞察を提供します： 運用上の優秀性 – あらゆる規模でクラウドベースのゲームを、デプロイおよび運用するためのベストプラクティスに焦点を当てています。これには、開発のサポート、効果的なワークロードの実行、運用に関するインサイトの獲得が含まれます。また、ビジネス価値を提供するためのサポートプロセスと手順を継続的に改善する能力も含まれます。 セキュリティ – リスク評価と軽減を通じてビジネス価値を提供しながら、情報、システム、資産を保護する能力が含まれます。 信頼性 – インフラストラクチャまたはサービスの中断から回復し、需要を満たすためにコンピューティングリソースを動的に取得し、設定ミスや一時的なネットワーク問題などの中断を軽減するシステムの能力をカバーします。 パフォーマンス効率 – 要件を満たすためのコンピューティングリソースの効率的な使用と、需要の変化やテクノロジーの進化に応じてその効率を維持することに関するガイダンスを提供します。 コスト最適化 – 最初の概念実証の初期設計から本番ワークロードの継続的な運用まで、コストを最適化するためのライフサイクル全体にわたるシステムの改良と改善の継続的なプロセスが含まれます。 持続可能性 – AWS ワークロードで持続可能性目標を達成するための設計原則、運用ガイダンス、ベストプラクティス、改善計画を提供します。 Games Industry Lens の更新点 Games Lens の各柱は、最新のガイダンスを組み込み、ゲーム開発者が利用できる新しい AWS サービスを取り入れるために更新されています。具体的には、レンズの新バージョンは以下の分野で既存の内容を強化しています： AWS でのゲームワークロードの設計。Games Lens に含まれる更新されたシナリオには以下が含まれます： サーバーレスバックエンドと組み合わせたセッションベースのゲームサーバーホスティング 低レイテンシーゲームのためのマルチリージョンおよびハイブリッドアーキテクチャ コンテナベースのゲームバックエンド サーバーレスベースのゲームバックエンド ゲーム分析パイプライン ゲームワークロードを運用化するための実装ガイダンスとベストプラクティス プレイヤー認証とバックエンドのセキュリティガイダンス 負荷テストガイダンス Amazon EC2 Graviton インスタンス を使用したパフォーマンスの最適化 Amazon GameLift を使用したゲームサーバーデプロイメントの管理 複数の AWS リージョンでゲームを運用するためのディザスタリカバリガイダンス AWS でのゲーム開発およびホスティングコストを最適化するためのベストプラクティス Games Industry Lens を使用すべき対象者 Games Industry Lensは、ゲームを構築する、またはゲーム会社にサービスを提供するすべての AWS のお客様を対象としています。これには、スタートアップゲームスタジオ、AAA ゲーム開発者、パブリッシャー、ゲーム開発またはホスティングソリューションを提供する企業が含まれます。Games Lens は、開発中、ローンチ準備中、または AWS でのライブ運用のスケーリングや最適化など、ゲーム制作のあらゆる段階で価値があります。 AWS Well-Architected Tool でレンズを使用する AWS Well-Architected Tool （AWS WA Tool）は、AWS のベストプラクティスを使用してアーキテクチャを測定するための一貫したプロセスを提供するクラウド内のサービスです。AWS WA Tool を使用して、AWS Well-Architected Framework で定義されたベストプラクティスに対してワークロードを文書化および測定できます。AWS WA Tool には、ワークロードに適用できるドメイン固有のレンズもあります。レンズは、業界のベストプラクティスに対してアーキテクチャを一貫して評価し、改善領域を特定するのに役立つドメイン固有のガイダンスを提供します。 AWS Well-Architected Framework レンズは、ワークロードが定義されると自動的に適用されます。ワークロードには 1 つ以上のレンズを適用できます。各レンズには、固有の質問、ベストプラクティス、メモ、改善計画のセットがあります。 ワークロードに適用できるレンズには 2 種類あります： レンズカタログ： ゲームワークロードのレビューを開始するには、公開されている AWS Well-Architected カスタムレンズの GitHub リポジトリ から、 Games Industry Lens をダウンロードして AWS Well-Architected Tool にインポートします。 カスタムレンズ： AWS の公式コンテンツではない、ユーザー定義のレンズです。 （訳者注：ここでの「カスタムレンズ」は、レンズカタログに含まれていないレンズを指します。Games Lens は AWS が公式にサンプルとして提供するカスタムレンズであり、GitHub からダウンロードしてインポートする形式で利用できます。） カスタムレンズの質問を特定のテクノロジーに合わせてカスタマイズしたり、組織内のガバナンスのニーズを満たすのに役立てたり、Well-Architected Framework と AWS レンズによって提供されるガイダンスを拡張したりできます。既存のレンズと同様に、マイルストーンを作成して時間の経過とともに進捗を追跡し、レポートを生成して定期的なステータスを提供できます。カスタムレンズは、AWS 提供のレンズを適用するのと同じ方法でワークロードに適用します。作成したカスタムレンズを他の AWS アカウントと共有することもでき、他の人が所有するカスタムレンズの共有を受けることもできます。 Games Lens は、 AWS Samples GitHub にカスタムレンズとして公開されています。 まとめ 既存のアーキテクチャに Games Industry Lens を適用することで、設計の安定性と効率性を検証し、特定されたギャップに対処するための推奨事項を提供できます。 Games Industry Lens を使用して独自の Well-Architected システムを構築する方法の詳細については、 AWS Well-Architected ウェブサイト の Games Industry Lens ホワイトペーパー をご覧ください。 新しいレンズを使用してワークロードを評価する方法については、 Well-Architected Tool および レンズカタログ のまとめをご覧ください。追加の専門家によるガイダンスが必要な場合は、AWS アカウントチームに連絡して AWS for Games ソリューションアーキテクトとの連携を依頼してください。 Adam Hatfield Adam Hatfield は、7 年以上にわたりお客様の AWS でのスケーリングを支援してきたシニアソリューションアーキテクトです。彼はゲームローンチの準備に注力しており、スタートアップゲームスタジオが成功するローンチを実現できるよう支援しています。