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 でのスケーリングを支援してきたシニアソリューションアーキテクトです。彼はゲームローンチの準備に注力しており、スタートアップゲームスタジオが成功するローンチを実現できるよう支援しています。

AWS では、データと AI を活用したイノベーションの推進を支援するため、「 AWS Data & AI イノベーションフォーラム:顧客成功事例から学ぶデータ活用の最前線 」というイベントを4/9,10に開催いたします。本記事では、4/10 の DAY 2 (Database 編) の詳細についてご案内します。 はじめに DAY 2 の見どころは、昨年 5 月に一般提供を開始した Amazon Aurora DSQL について、本番環境で使用中のお客様や検証したお客様をお呼びして、リアルな声をお届けするセッションです。 お客様の経験や課題解決のプロセスを知ることで、皆様のデータベース戦略にも活かしていただけます。 ぜひ会場でご参加ください。 イベント概要 本イベントは 2 日間にわたって開催され、AWS Data & AI 戦略の全体像から、実際のお客様事例まで幅広くご紹介します。 DAY 1 : AIML 、Analytics、Storage (別途お申し込みが必要です) DAY 2 : Database ※本記事でご紹介 DAY 2 では、AWS Director の Mehul Y. Shah による商用データベースの AWS 戦略についてのキーノートセッションから始まり、 DSQL を活用した次世代 DR 戦略の検討している東京海上日動システムズ様のセッション 、 DSQL を本番環境で実際に採用している Japan Digital Design 様による本番導入事例 、 本番環境を想定して DSQL のパフォーマンス検証を実施した Happy Elements 様のセッション 、そして AWS による RDS / Aurora や NoSQL 採用事例などを予定しています。 ※ 1 セッションからでもご参加いただけます。 ご興味のあるセッションのみの参加も歓迎いたします。 開催情報（Day 2） 項目 詳細 開催日時 2026 年 4 月 10 日 9:30 – 17:00 (日本時間) 開催場所 〒 141-0021 東京都品川区上大崎 3 丁目 1-1 目黒セントラルスクエア 17F AWS Startup Loft Tokyo 開催形式 オフライン (会場参加) 参加費 無料 定員 限定人数 (定員になり次第、受付を終了いたします) 申込方法 イベント申込ページ よりお申し込みください ※本イベントは定員に限りがございます。お早めにお申し込みください。 ※ DAY 1 (AIML 、Analytics 、Storage 編) の詳細・お申し込みは こちら からご確認ください。 プログラム詳細 時間 セッションタイトル 概要 登壇者 カテゴリ 09:30 – 09:35 Opening – – – 09:35 – 10:35 Keynote 「商用データベースの re:Invent : AWS が顧客起点で実現するデータイノベーション」 AWS が顧客の課題から出発する「Working Backwards」のアプローチを通じて、Amazon RDS をはじめとする商用データベースのイノベーションをどのように推進しているのかをご紹介します。re:Invent で発表された最新アップデート、パフォーマンス・スケーラビリティ・運用効率の向上、レガシーデータベースの移行からクラウドネイティブかつ AI 活用を見据えたデータ基盤の構築まで、厳選した事例とともにご紹介します。企業がコスト削減やリスク低減にとどまらず、商用データベースを戦略的資産として活用し、ビジネスイノベーションを加速している事例をご理解いただけます。 Mehul Y. Shah (Director for Amazon RDS and Oracle Database@AWS) AWS 戦略 10:45 – 12:00 【お客様登壇】 「DR 戦略の進化～ Amazon Aurora DSQL がもたらす新たな可能性と実践への第一歩～」 前半では、AWS より Aurora DSQL のアーキテクチャと主要な特徴を解説します。後半では、東京海上日動システムズ株式会社様より、既存システムの DR 構成における課題と、DSQL の Active-Active 構成がもたらす DR 戦略の変革の可能性についてお話しいただきます。DSQL 活用の検討段階で見えてきた課題にも触れていただくほか、AWS を戦略的に採用する判断基準についてもご共有いただきます。 山下 裕記 様 (東京海上日動システムズ株式会社 戦略企画部長) 小野 卓人 (AWS 金融ソリューション本部 シニアソリューションアーキテクト) DSQL 検討事例 12:00 – 13:00 昼食休憩 13:00 – 14:00 【お客様登壇】 「Amazon Aurora DSQL の本番導入事例のご紹介」 – 佐藤 慎 様 (Japan Digital Design 株式会社) DSQL 本番採用事例 14:15 – 15:15 【お客様登壇】 「実プロダクトで検証する Aurora DSQL の可能性と制約」 Happy Elements では、運用中のゲームタイトルの実プロダクトを使い、Aurora DSQL のパフォーマンス検証を行いました。検証から見えた Aurora DSQL の性能特性、楽観的同時実行制御や ALTER TABLE 制限などの制約、そしてコスト比較の結果を具体的な数値とともに余すことなく共有します。 長谷川 一輝 様 (Happy Elements 株式会社 チーフエンジニア インフラグループ グループリーダー) DSQL 検証結果 15:30 – 16:45 「AWS Database サービス最新顧客事例集」 AWS は、目的に応じた多様なデータベースサービスを提供しており、お客様のビジネス要件に最適なソリューションを選択いただけます。本セッションでは、実際のお客様事例を通じてデータベース採用の実践的なアプローチをご紹介します。オンプレミスや商用データベースから Amazon RDS / Aurora への移行事例、および NoSQL の効果的な採用事例を通じて、運用負荷削減、性能向上、コスト最適化を実現した事例についてご紹介します。 内山 義夫 (AWS) RDS/Aurora /NoSQL 事例 16:45 – 17:00 Closing こんな方におすすめ 本イベントは、特に以下のような方におすすめです: DSQL に興味があり、実際の本番・検証事例から学びたい方 DSQL の導入を検討されている方 データベースの移行やモダナイゼーションを検討されている方 データベース運用の効率化やコスト最適化を目指している方 他社のリアルな導入経験から具体的なヒントを得たい方 まとめ AWS Data & AI イノベーションフォーラム DAY 2 (Database 編) では、最新データベース戦略の解説から、実際のお客様による DSQL やその他データベースの移行事例まで、データベースに関する幅広い知見を得ることができます。 特に、DSQL について、お客様のリアルな声を直接お聞きいただける場となっております 。定員に限りがございますので、ぜひお早めにお申し込みください。 皆様のご参加を心よりお待ちしております。 今すぐ申し込む

本ブログは株式会社電通総研とAmazon Web Services Japan が共同で執筆いたしました。 電通総研様が開発された リアルタイム 3DCG ソリューション「UNVEIL」 において、「1,000 名の同時接続」と「100〜500ms の低レイテンシー」という厳しい要件を、わずか約 1 ヶ月の準備期間で大規模 GPU 環境を構築し、乗り越えた事例をご紹介します。 まず、「UNVEIL」 についてご紹介します。「UNVEIL」とは電通総研様が開発されているブラウザでのリアルタイム 3DCG メタバース/仮想空間のソリューションで、現実に近い高品質な 3D 体験を、多人数同時参加で提供する商用向けサービスです。 (出展: 株式会社電通総研) お客様の状況と課題 電通総研様は、「UNVEIL」の商用展開に向けた取り組みの一環として、2025 年 12 月に実施された社内イベントでの活用を計画されていました。同イベントでは、1,000 名の同時接続と、レスポンス 100〜500 ms 程度という要件がありました。 課題は、 大規模な GPU 環境（ Amazon EC2 の g4dn 系、g5 系インスタンス）を効率的に構築する ことでした。イベント駆動型のワークロードであるため、コスト効率を保ちながら、必要な規模の環境を短期間で立ち上げる必要がありました。 戦略1: コスト最適化のためのリージョン選択 当初はアジアパシフィック (東京) リージョンで基盤を構築されていましたが、大規模な GPU 環境を構築するにあたり、 コスト効率 の観点から、海外リージョンの活用を検討しました。 Amazon EC2 の料金はリージョンによって異なるため、コスト効率の良い米国東部 (バージニア北部) リージョンと米国西部 (オレゴン)リージョンが候補として浮上しました。また、リージョンに依存しないアプリケーション設計を採用されていた点も、海外リージョンを選択できた大きな理由でした。 リージョン g5.xlarge のオンデマンド料金 ($/Hour) ※ アジアパシフィック (東京) 1.459 米国東部 (バージニア北部) 1.006 米国西部 (オレゴン) 1.006 ※ 2026 年 3 月時点の料金 戦略2: レイテンシーを考慮した実測テスト 海外リージョンを活用する際の最大の懸念は、日本からのアクセスにおけるレイテンシーでした。電通総研様は、 机上の計算だけでなく、実際のアプリケーションで測定する というアプローチを採用されました。 まず 米国東部 (バージニア北部) で検証を実施しましたが、日本からのアクセスでは遅延が大きく、ユーザー体験に影響があることが判明しました。次に米国西部 (オレゴン) で検証した結果、米国東部 (バージニア北部) よりもレスポンスが改善され、目標のレイテンシー数値に抑え、視聴体験を損なわない範囲に収まることを確認できました。この結果から コスト効率とレイテンシーの両面で最適な米国西部 (オレゴン) リージョンを採用 することが決定しました。 テストに向けた環境構築において、AWS の各リージョンで同一のサービスや API が提供されていたため、環境を別のリージョンへ再現することが容易でした。加えて、 Amazon EKS をはじめとするマネージドサービスを活用していたことで、リージョン間の環境移行も約 1 週間で完了し、迅速な検証が可能になりました。 戦略3: 複数回の事前テストによるリスク軽減 イベント本番での失敗を避けるため、 複数回のテスト を実施しました。数百台規模での動作確認を実施することで、以下のような潜在的な問題を事前に発見・対処することができました： 数百台規模のオートスケーリング起動が問題ないことの確認 (スケール起動検証) Service Quota の事前確認と調整 Amazon VPC の IP アドレス設計などインフラ面での考慮事項の確認 リージョンごとのレイテンシー特性の把握 また、大規模な GPU 環境を構築する際のキャパシティ確保の観点から、g4dn 系と g5 系の複数世代の GPU インスタンスタイプを混在させる構成を採用しました。単一のインスタンスタイプに依存せず、複数のインスタンスタイプを組み合わせることで、特定のインスタンスタイプで必要な台数が確保できない場合でも、他のインスタンスタイプで補完できる柔軟な環境を実現しました。 ソリューション概要 UNVEIL は、Amazon EKS を中心としたアーキテクチャで構成されています： フロントエンド: Amazon CloudFront + Amazon S3 による高速コンテンツ配信 アプリケーション層: Amazon EKS 上で動作する MatchMaker（ユーザーと GPU サーバーを割り当てる仕組み）、GPU サーバー、TURN/STUN サーバー 監視層: Amazon CloudWatch による包括的な監視 ユーザーは Amazon CloudFront 経由でアクセスし、MatchMaker が利用可能な GPU サーバーに割り当て、Unreal Engine でレンダリングされた映像を WebRTC 経由で配信します。 導入効果 2025 年 12 月のイベントでは以下の成果を得ることができました： 最大 1,000 台規模 GPU インスタンスを稼働 既存の東京リージョンと比較してコスト効率の良い環境構築を実現 電通総研様からは、「1,000 人規模のスパイクアクセスに対しても、インフラをオートスケーラブルに増減できることを検証できた点が大きな成果でした。未使用時にコスト増となり得る GPU リソースを、利用人数に応じて自動的にスケールできることを確認し、品質とコストの両立の可能性を示せました。また、事前検証によりボトルネックを特定できたことも、商用化に向けた重要な学びとなりました。一方で、アプリケーション面では大規模・多人数同時利用時の考慮が十分でなく、一部挙動が不安定となる課題も確認でき、改善項目として整理できました」とのコメントをいただきました。 大規模 GPU 環境構築の学び 今回のプロジェクトから得られた重要な学びをまとめます： 1. コスト最適化のためのリージョン戦略 海外リージョンの活用により、コスト効率の良い大規模 GPU 環境を構築できます。 2. 実測ベースの意思決定 複数リージョンで実際にレイテンシーを測定し、机上の計算だけでなく実際のアプリケーションでの検証が重要です。 3. 複数回の事前テストの重要性 複数回のテストを実施し、各テストでボトルネックを特定することで、イベント本番のリスクを最小化できます。また、g4dn 系と g5 系など複数世代の GPU インスタンスタイプを混在させることで、大規模環境でのキャパシティ確保の柔軟性を高めることができます。 4. イベント当日の運用設計 イベント開始前に十分な台数を確保し、Amazon CloudWatch による包括的な監視で問題の早期発見を実現します。 まとめ 今回は、電通総研様の UNVEIL において、大規模 GPU 環境を効率的に構築するための戦略的アプローチをご紹介しました。 電通総研様の「まず試してみる」という実践的なアプローチと、事前テストで計測したデータに基づく意思決定が、短期間でのシステム構築を可能にしました。大規模な GPU 環境を構築される際は、ぜひ今回ご紹介した戦略を参考にしていただければ幸いです。 AWS では定期的に技術イベントを開催しております。ぜひご参加ください。 https://aws.amazon.com/jp/events/ 執筆者 株式会社電通総研 事業開発室 姫野 智也氏、孫 辰氏 Amazon Web Services Japan: ソリューションアーキテクト 本多 和幸

本記事は アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 疋田、畠 と、Fivetran による共著です。 はじめに 本記事では、 Fivetran の Managed Data Lake Service 及び CDC 機能を活用して業務システムの RDBMS から Amazon S3 上の Apache Iceberg テーブルへリアルタイムにデータ連携が必要となるユースケースや構成イメージ、実装例を記載します。 本記事では、業務システムの RDBMS からリアルタイムにデータを連携するユースケースを紹介します。また、 Fivetran の Fivetran Managed Data Lake Service 及び CDC 機能を用いて Amazon S3 上の Apache Iceberg テーブルを活用する構成と実装例をご紹介します。 お客様の業務システムには、受注・在庫・会計といった大量のトランザクションデータが蓄積されています。これらのデータを分析やビジネス上の意思決定に活用したいというニーズは年々高まっており、近年では生成 AI の学習データ基盤としてもオープンテーブルフォーマットを活用したデータ基盤へのデータ集約が注目されています。 しかし、業務システムの RDBMS 上で直接分析クエリを実行すると、本来のトランザクション処理に影響を及ぼすリスクがあります。受発注や在庫更新のような日常的なデータの読み書きトランザクション処理は OLTP（Online Transaction Processing） 、大量データの集計や傾向分析などの分析処理は OLAP（Online Analytical Processing） と呼ばれ、それぞれ求められる処理特性が異なります。高スペックな RDBMS を用いて OLTP および OLAP を単一のデータベース基盤で処理する方式の場合、最新のデータを扱えますが、ハードウェアやライセンス等のコストが増大します。夜間バッチで OLAP 基盤へデータを連携する方法では、コストを抑えられますが、データの鮮度がバッチの実行間隔に依存するといったトレードオフが生じます。 こうした課題を解決する手段の一つが、 Change Data Capture（CDC） を用いた業務システムとデータ基盤の連携です。CDC はデータベースの変更をリアルタイムに検知・取得する技術で、業務システムへの負荷を最小限に抑えながらデータを連携できます。 本ブログでは、AWS Data and Analytics コンピテンシーパートナーである Fivetran の Managed Data Lake Service (MDLS) 機能を活用し、業務システムの RDBMS から Amazon S3 上の Apache Iceberg テーブルへデータを連携する方法をご紹介します。Apache Iceberg は大規模な分析データセットを管理するためのオープンテーブルフォーマットで、ACID トランザクションやスキーマ進化、タイムトラベルといった機能を提供します。連携されたデータは AWS Glue データカタログに登録され、 Amazon Redshift 、 Amazon Athena 等からすぐにクエリ・分析が可能です。 業務システムから Iceberg テーブルへの CDC データ連携のユースケース 業務システムで用いられるデータベース基盤から Apache Iceberg テーブルへ CDC でデータを連携するユースケースとして、以下のようなものが挙げられます。 OLTP と OLAP の分離によるデータベース基盤のダウンサイジング オンプレミスの高性能なデータベース基盤では、 OLTP と OLAP の両方を単一の基盤上で実行しているケースが少なくありません。OLAP ワークロードに対応するために基盤のスペックが引き上げられ、結果としてライセンスコストやハードウェアコストが増大しているという状況は、多くのお客様に共通する課題です。 これに対して、CDC を用いて業務データを Apache Iceberg テーブルに連携することで、OLAP ワークロードを Amazon Athena にオフロードできます。Fivetram Managed Data Lake Service が連携したデータは AWS Glue データカタログに自動的に登録されるため、Athena からすぐにクエリを開始できます。これにより、既存のデータベース基盤は本来の OLTP 処理に専念でき、スペックの適正化やダウンサイジングが可能になります。Amazon Athena はサーバーレスサービスであるため、インフラストラクチャの管理が不要で、クエリのデータスキャン量に応じた従量課金で利用できます。 バッチ処理のオフロード 多くの企業では、業務システムのデータを分析用データベースに連携するために、夜間バッチによる定期的なデータ抽出を行っています。この方式では、データの鮮度がバッチの実行間隔に依存するため、日中に発生した変更が分析に反映されるのは翌日以降になる場合も少なくありません。また、バッチ処理自体がデータベースに大きな負荷をかけるため、業務時間外に実行せざるを得ないという制約もあります。 CDC を活用すれば、データベースのトランザクションログから変更データをリアルタイムに取得可能です。これにより、業務システムへの負荷を最小限に抑えながら、データの鮮度を大幅に向上でき、夜間バッチの廃止や実行頻度の削減等を狙えます。また、Fivetran のようなサーバーレスなマネージドサービスを用いることで運用負荷の軽減や、後述の Fivetran Managed Data Lake Service のような多くの機能を素早く利用可能です。 履歴データの保持と分析 業務システムでは、データは常に最新の状態に更新されるため、過去のある時点の状態を参照することが困難です。たとえば、「ある顧客の住所が変更される前の情報」や「商品の価格改定前の単価」といった履歴情報は、通常の RDBMS 上では保持されません。 Fivetran の CDC は データウェアハウスにおける履歴管理手法である Slowly Changing Dimension Type 2（SCD Type 2）に対応しています。SCD Type 2 により、レコードの変更履歴を保持する形式でデータを連携できます。これにより、Apache Iceberg テーブル上に変更の履歴が蓄積され、「いつ、どのように変更されたか」を後から分析することが可能になります。Iceberg のタイムトラベル機能と組み合わせることで、任意の時点のデータスナップショットを参照することもできます。 Fivetranとは？ エンタープライズグレードのCDCとデータ統合の自動化 現代のデータアーキテクチャは、Amazon S3 を核として、オープンで柔軟な基盤へと進化しています。組織がレイクハウス型の分析へと移行するにつれ、Apache Iceberg のようなオープンテーブル形式でデータを取得することが、データのポータビリティと将来への対応を確保する上で不可欠になっています。 エンタープライズグレードのデータ移動: High-Volume Agent（HVA）と Binary Log Reader データエンジニアリングにおける最大の課題は、データの取り込みだけでなく、ミッションクリティカルなワークロードの長期的な信頼性と拡張性を維持することです。Fivetran は 700 を超えるフルマネージドコネクタを提供し、多様なデータソースからの連携をノーコードで実現します。特に Oracle（Oracle Exadata を含む）のような要求の厳しい環境向けには、高度な Binary Log Reader 技術を活用した低レイテンシのログベース CDC に対応しています。Oracle Database 19c 以降に最適化されたこの仕組みは、REDO ログを直接分析することで LogMiner などの従来型ツールのオーバーヘッドを回避します。多くの場合、ソースに近い環境に配置した High-Volume Agent（HVA） を介して REDO ログを読み取ることで、テラバイト規模のデータであっても本番環境への影響を最小限に抑えながらリアルタイムに移動できます。これにより、コアビジネスシステムの安定性を損なうことなく、シームレスな OLAP オフロードが可能になります。 自動化されたガバナンスと将来を見据えたテーブル Fivetran MDLS は、スキーマの変更を自動的に検知・反映することで、スキーマドリフトに自動的に対応します。また、レコードの変更履歴が保持される SCD Type 2 のサポートにより、Iceberg テーブル管理の運用負担を軽減します。これにより、ソーススキーマが変化しても、下流の分析の一貫性と「将来への対応」が確保されます。 検出を効率化するため、Fivetran は AWS Glue データカタログとネイティブに統合されています。Amazon S3 で Icebergテーブルが更新されると共に、メタデータが自動的に同期されます。これにより、Amazon Athena 経由でデータセットを即座に検出及びクエリできるようになります。Fivetran の自動データ移動と AWS のスケーラブルなインフラストラクチャを組み合わせることで、チームはエンタープライズ規模の AI と分析に対応できる、ガバナンスが効いた高性能なデータ基盤を構築できます。 さらに、Fivetran MDLS はデータのロード・更新にとどまらず、Icebergテーブルのパフォーマンスを継続的に維持するための自動管理機能をバックグラウンドで実行します。具体的には、クエリ性能を最適化するための小さなファイルの統合（コンパクション）、不要な孤立ファイルの削除、古いスナップショットの自動期限切れ処理などが含まれます。これらの運用タスクが自動化されることで、チームはインフラ管理ではなくデータ活用に集中できます。 また、Fivetran MDLS を活用することで、各ツールやシステムがデータのコピーを個別に持つ必要がなくなります。データは Amazon S3 上の Iceberg テーブルとして一元管理されるため、ストレージコストを抑えながら「単一の真実のバージョン（Single Source of Truth）」を実現し、組織全体のデータサイロを防ぐことができます。 構成の概要とシナリオ ここでは、PostgreSQL で稼働する業務システムのデータを分析基盤に連携するシナリオを例に、具体的な手順をご紹介します。業務データベースに対して分析用途の集計クエリを直接実行すると本番ワークロードへの負荷が懸念されます。加えて、一部のテーブルについては各レコードの変更履歴を追跡できる形でデータを蓄積する必要があります。 そこで、Fivetran を業務データベースに接続し、Amazon S3 上に Iceberg 形式でデータを蓄積するパイプラインを構築します。これにより、業務システムの OLTP ワークロードと分析の OLAP ワークロードを分離しつつ、両者を継続的に連携できます。S3 に書き込まれた Iceberg テーブルのメタデータは AWS Glue Data Catalog に登録されるため、Amazon Athena から即座にクエリが可能です。 今回の構成は以下の通りです。 ソース: PostgreSQL データベース CDC 処理・データレイク管理: Fivetran MDLS ターゲット: Amazon S3 + AWS Glue Data Catalog（Apache Iceberg 形式） クエリエンジン: Amazon Athena Iceberg 形式のデータは、Amazon Athena 以外にも Amazon Redshift や Apache Spark、Trino など Iceberg をサポートする様々なクエリエンジンからデータをコピーすることなく参照できます。要件の変化に応じて最適なツールを使い分けることが可能です。 サンプルデータ 今回のウォークスルーでは、業務システムを模した以下の 2 つのテーブルを使用します。 orders テーブル（受注データ）は、日々の受注を記録するトランザクションテーブルです。Fivetran MDLS による通常の CDC で連携し、INSERT/UPDATE/DELETE がそのまま Iceberg テーブルに反映される様子を確認します。 カラム名 型 説明 id SERIAL (PK) 受注ID product_id INTEGER 商品ID quantity INTEGER 数量 total_price NUMERIC(10,2) 合計金額 status VARCHAR(20) ステータス（pending / confirmed / shipped / cancelled） ordered_at TIMESTAMP 受注日時 初期データとして、以下の 5 件の受注が登録されています。 id product_id quantity total_price status 1 1 1 128,000 confirmed 2 2 2 90,000 shipped 3 3 1 18,000 pending 4 5 3 10,500 confirmed 5 4 2 17,800 pending products テーブル（商品マスタ）は、商品の基本情報を管理するマスタテーブルです。Fivetran MDLS の SCD Type 2 を使った連携方式を使用し、価格改定などの更新が行われた際に変更前のレコードが履歴として保持される様子を確認します。 カラム名 型 説明 id SERIAL (PK) 商品ID name VARCHAR(100) 商品名 category VARCHAR(50) カテゴリ unit_price NUMERIC(10,2) 単価 is_active BOOLEAN 販売中フラグ updated_at TIMESTAMP 更新日時 初期データとして、以下の 5 商品が登録されています。 id name category unit_price 1 ノートPC 14インチ PC 128,000 2 モニター 27インチ 周辺機器 45,000 3 メカニカルキーボード 周辺機器 18,000 4 ワイヤレスマウス 周辺機器 8,900 5 USBハブ 7ポート アクセサリ 3,500 セットアップ手順 ここからは、実際に環境を構築しながら手順を説明します。全体の流れは以下の通りです。 AWS 側の準備（S3 バケット、IAM ロール、Glue データカタログ） Fivetran のデスティネーション（データレイク）設定 ソースデータベース（Aurora PostgreSQL）の準備 Fivetran のコネクター設定と CDC 連携の開始 AWS 側の準備 S3 バケットの作成 Iceberg テーブルのデータファイルとメタデータを格納する S3 バケットを作成します。詳細は Amazon S3 の開始方法 を参照してください。 IAM ロールの作成 Fivetran が S3 バケットへの書き込みと Glue Data Catalog の操作を行うための IAM ロールを作成します。必要な IAM ポリシーや信頼ポリシーの設定手順は、Fivetran の Managed Data Lake Service セットアップガイド に記載されています。 Fivetran のデスティネーション設定 Fivetran のダッシュボードから、データの書き込み先となるデスティネーションを設定します。今回は S3 Data Lake を選択し、作成した S3 バケットと IAM ロールの情報を入力します。設定の詳細は Fivetran の Managed Data Lake Service セットアップガイド を参照してください。 設定の中で、Update AWS Glue Catalog を有効にすると、Fivetran が Iceberg テーブルのメタデータを Glue Data Catalog に自動登録するようになり、Amazon Athena などからすぐにクエリできる状態になります。 設定が完了すると、以下のようにデスティネーションが登録されます。 ソースデータベースの準備 今回は Amazon Aurora PostgreSQL をソースデータベースとして使用します。論理レプリケーションの有効化やユーザーの作成など、ソース側の設定は Fivetran の Aurora PostgreSQL セットアップガイド に従って進めます。 セットアップガイドに従い、Fivetran 専用のデータベースユーザーの作成と読み取り権限・レプリケーション権限の付与、Publication とレプリケーションスロットの作成を行います。 Fivetran のコネクション設定 Fivetran では、デスティネーションに対してデータソースごとのコネクションを作成することでデータパイプラインを構成します。先ほど作成したデスティネーションに対して、 Amazon Aurora PostgreSQL へのコネクションを追加します。PostgreSQL を選択し、Aurora クラスターのエンドポイントや認証情報を入力します。 データベースへの接続方法は直接接続のほか SSH トンネルや AWS PrivateLink にも対応しています。また、増分同期の方式（Update Method）には Logical Replication と Query-Based の 2 種類があります。Logical Replication は WAL（Write-Ahead Log）から変更を検知する方式で、Aurora PostgreSQL バージョン 10 以降で利用できます。今回はこちらを選択し、先ほど作成した Replication Slot と Publication Name を指定します。 設定が完了すると、以下のようにコネクションが登録されます。 データ連携の設定と同期の開始 コネクションの設定画面では、同期対象のデータや連携方式に関する様々な設定を行うことができます。 コネクションの Schema タブでは、同期対象のテーブルやカラムを個別に選択できます。不要なテーブルを除外したり、機密性の高いカラムを連携対象から外すといった制御が可能です。 また、ソース側でテーブルやカラムが追加された場合の挙動を Schema Change Handling で制御できます。すべて自動で同期する（Allow all）、既存テーブルへのカラム追加のみ同期する（Allow columns）、すべてブロックする（Block all）の 3 つのオプションから選択できます。 「Sync Mode」により、テーブルへの変更履歴の反映方法を設定できます。ソースの変更をそのまま反映したい場合は、「Soft delete mode」(デフォルト)を選択します。SCD Type 2 でデータを連携したい場合は、「History mode」を選択します。 今回は products テーブル の Sync Mode を History mode に変更し、SCD Type 2 での履歴管理を有効にしています。これにより、レコードの変更時に変更前の状態が履歴として保持されます。 同期の頻度は Sync frequency で設定します。プランに応じて最短 1 分間隔から選択できます。 これらの設定を行った上で Start Initial Sync をクリックすると、初回のフルロードが開始されます。ソーステーブルの既存データがすべて Iceberg テーブルに転送されます。 データ連携の確認 初回同期の確認 AWS マネージメントコンソール からGlue カタログを確認してみると、テーブルが連携されていることがわかります。 連携先の Iceberg テーブルは Amazon Athena や AWS Glue、Amazon Redshift などさまざまなエンジンからクエリすることが可能です。Iceberg テーブルへのクエリに対応している 3rd party の製品からのクエリももちろん可能です。 今回は、 Amazon SageMaker Unified Studio の AI エージェントが組み込まれたノートブック から Amazon Athena でクエリを行ってみました。以下の通り、連携された Iceberg テーブルを簡単にクエリすることができました。 ソーステーブルのカラムに加えて、Fivetran が自動的に付与するメタデータカラムが確認できます。 orders テーブル（通常の CDC）では、以下のメタデータカラムが追加されています。 _fivetran_deleted : ソース側で削除されたレコードを示すフラグ。削除が検知されると true になる _fivetran_synced : Fivetran がレコードを同期した日時 products テーブル（SCD Type 2）では、上記に加えて履歴管理のためのカラムが追加されています。 _fivetran_start : そのレコードが有効になった日時 _fivetran_end : そのレコードが無効になった日時。現在有効なレコードは 9999-12-31T23:59:59.999Z _fivetran_active : 現在有効なレコードかどうかを示すフラグ 現時点ではすべてのレコードが _fivetran_active = true で、初回同期時点のスナップショットが格納されている状態です。ここからソースデータベースに変更を加え、CDC による差分連携と SCD Type 2 の履歴管理の動作を確認していきます。 CDC による差分連携の確認 初回同期の完了後、ソースデータベースに対して INSERT、UPDATE、DELETE を実行し、変更が Iceberg テーブルに反映されることを確認します。 -- 新しい受注の追加 INSERT INTO orders (product_id, quantity, total_price, status, ordered_at) VALUES (1, 2, 256000, 'pending', NOW()); -- 受注ステータスの更新 UPDATE orders SET status = 'shipped' WHERE id = 3; -- 受注のキャンセル（削除） DELETE FROM orders WHERE id = 5; Fivetran の次回同期が実行された後、Athena で再度クエリを実行すると、これらの変更が反映されていることを確認できます。 id=6 として新しいレコードが追加されている（INSERT の反映） id=3 の status が pending から shipped に変更されている（UPDATE の反映） id=5 の _fivetran_deleted が true になっている（DELETE の反映） DELETE されたレコードはテーブルから物理的に削除されるのではなく、 _fivetran_deleted = true のフラグで論理削除として管理されます。これにより、削除の履歴を保持しつつ、分析時には WHERE _fivetran_deleted = false でフィルタすることで最新の有効データのみを参照できます。 SCD Type 2 による履歴管理の確認 products テーブルで商品の価格改定と販売終了を行い、SCD Type 2 による履歴管理を確認します。 -- 商品の価格改定 UPDATE products SET unit_price = 138000, updated_at = NOW() WHERE id = 1; -- 商品の販売終了 UPDATE products SET is_active = false, updated_at = NOW() WHERE id = 5; Fivetran の同期後、Amazon Athena で products テーブルをクエリすると、変更前と変更後の両方のレコードが保持されていることを確認できます。 たとえば id=1（ノートPC 14インチ）では、価格改定前の unit_price=128,000 のレコードが _fivetran_active = false として残り、改定後の unit_price=138,000 のレコードが _fivetran_active = true として追加されます。同様に id=5（USBハブ 7ポート）では、is_active が true だった時点のレコードと false に変更された後のレコードがそれぞれ保持されます。 このように、ソース側では単純な UPDATE であっても、 _fivetran_active = false のレコードも含めて参照することで「いつ、どのような値だったか」の履歴を分析できます。また、 _fivetran_active = true のレコードのみを対象にクエリすることで、テーブルの最新の状態を参照することもできます。 以上のウォークスルーで確認した通り、Fivetran MDLS を使うことで Aurora PostgreSQL から Iceberg テーブルへの CDC パイプラインを、コードを書くことなく構築できました。通常の CDC による INSERT/UPDATE/DELETE の即時反映に加え、SCD Type 2 による変更履歴の自動蓄積、テーブル・カラム単位の同期制御やスキーマ変更への対応など、運用に必要な機能が設定画面上で完結しています。連携されたデータは Glue Data Catalog を通じて Athena からすぐにクエリでき、分析基盤としてすぐに活用を開始できる状態になります。 まとめ 本記事では、Fivetran Managed Data Lake Service 及び CDC 機能を活用し、業務システムの RDBMS から Amazon S3 上の Apache Iceberg テーブルへリアルタイムにデータを連携する構成を紹介しました。Fivetran の Binary Log Reader による低負荷な変更データ取得と、AWS Glue データカタログへの自動メタデータ同期により、OLTP/OLAP の分離やバッチ処理のオフロードといったユースケースをシンプルな構成で実現が可能となります。

本記事は 2026 年 3 月 24 日に公開された Cristian Graziano の「 Amazon CloudFront flat-rate pricing plans: new features and expanded capabilities 」を翻訳したものです。 2025 年 11 月、 Amazon CloudFront  の 定額料金プランをリリース しました。リリース以降、お客様からいただいたフィードバックをもとに新しい機能を追加してきました。この記事では、  Lambda@Edge のサポート、 CAPTCHA 、相互 TLS (mTLS) 、そして AI ボットやエージェントのトラフィックを可視化する AI アクティビティダッシュボードなど、最新の追加機能をご紹介します。また、使用量の上限を超えたトラフィックの扱いについても明確化しています。 定額料金プランとは 定額料金プランは、トラフィックのスパイクや攻撃に関係なく、月額固定料金で Web サイトやアプリケーションの配信と保護に必要なすべてを提供します。超過料金は発生しません。 CloudFront CDN 、  AWS WAF  、分散型サービス拒否 (DDoS) 対策、ボット管理、  Amazon Route 53  DNS 、  Amazon CloudWatch  Logs へのログ取り込み、サーバーレスエッジコンピューティング、  Amazon Simple Storage Service (Amazon S3)  のストレージクレジットを、選択したプランティアに応じた月額料金で提供します。 プランは Free ($0/ 月 ) 、 Pro ($15/ 月 ) 、 Business ($200/ 月 ) 、 Premium ($1,000/ 月 )の 4 つのティアで提供されています。各ティアで利用できる機能が異なり、想定されるトラフィック量も異なります。いつでもアップグレードでき、年間契約は不要です。 新機能と対応機能の拡大 プランのリリースから 4 か月で、数十万のお客様がこれらのプランを利用して、予測可能な料金で Web サイトのセキュリティ強化と高速化を実現しています。 AWS のあらゆる機能やサービスと同様に、お客様の声に耳を傾け、新しい機能強化を導入しています。たとえば、定額料金プランに期待しているものの、プランがまだサポートしていない機能を既存の設定で使用しているため導入できないというお客様の声がありました。アプリケーションの動作を変更することなく、予測可能な月額料金を利用したいというご要望です。こうしたお客様のニーズに応えるため、新しい機能を追加しました。 AI アクティビティダッシュボード 。 AWS WAF の新しい AI アクティビティダッシュボードは、アプリケーションに到達する AI ボットやエージェントのトラフィックを可視化します。トラフィックの推移を時系列で確認したり、もっともアクティブなボットや頻繁にアクセスされるパスを特定したり、ボットのカテゴリや検証ステータスごとにリクエストを分析したりできます。このダッシュボードは、 Pro ティア以上のすべての有料プランに含まれています。 AI ボットのトラフィックに対してアクションを実行できるボット管理コントロールは、 Business ティア以上で  AWS WAF Bot Control  を通じて利用できます。 Lambda@Edge と CAPTCHA のサポート 。 Lambda@Edge や AWS WAF ルールで CAPTCHA を使用しているお客様も、定額料金プランを利用できるようになりました。以前は、これらの機能を使用しているディストリビューションはプランに加入できず、プランに加入しているディストリビューションでこれらの機能を有効にすることができませんでした。 AWS WAF ルールで設定した CAPTCHA レスポンスはプラン料金に含まれます。 Lambda@Edge はすべてのプランティアでサポートされるようになり、呼び出しはプラン料金に加えて標準の従量課金制で請求されます。 相互 TLS(mTLS) 。定額料金プランに mTLS のサポートを追加しました。 Business ティア以上で利用できるオリジン mTLS は、許可された CloudFront ディストリビューションのみがアプリケーションに接続できるようにします。これは、署名検証によりアプリケーションへのアクセスを制限する  オリジンアクセスコントロール (OAC)  や、アプリケーションをプライベートサブネットに配置して CloudFront 経由でのみアクセス可能にしパブリックインターネットに公開しない  VPC オリジン  といった既存のセキュリティオプションに加わるものです。これらの機能を組み合わせることで、すべてのトラフィックが CloudFront と AWS WAF のセキュリティルールを経由してからアプリケーションに到達するようにできます。 Premium ティアで利用できるビューワー mTLS では、クライアントがアプリケーションに接続する前に有効な証明書の提示を要求できます。 使用量の上限を超えたトラフィックの扱い 定額料金プランは、超過料金のない月額固定料金を提供します。トラフィックのスパイクが発生しても追加料金は発生せず、コンテンツが拡散した瞬間に請求の心配をする必要もなく、サービスのローンチが成功しても課金のペナルティはありません。各プランには、そのティアで最適なパフォーマンスを発揮するための使用量の上限が設定されています。使用上限はハード制限ではありません。予測可能な料金と安定したパフォーマンスが得られます。使用量が上限の 50% 、80% 、100% に近づくと通知が届き、コンソールからいつでも使用状況を確認できます。 リリース後、月間の使用量の上限を超えたトラフィックがどのように扱われるのか、より明確な説明を求めるお客様の声がありました。上限を超えたトラフィックの扱いについて、以下のように明確化しました。 月間使用量の上限を初めて超えた場合、上限の最大 3 倍までのトラフィックはその月内において問題なく処理されます。それを超える場合には、超過使用量は複数月にわたって評価されます。使用量の上限を大幅かつ長期間にわたって超過した場合にのみ、トラフィックの配信方法が調整される場合があります。ほとんどのお客様はパフォーマンスの調整を経験することはありませんし、いずれの場合においても超過料金は発生しません。また、いつでも上位ティアにアップグレードできます。 既存のディストリビューションを定額料金プランに変更する場合やプランティアを変更する場合、 CloudFront コンソールに各プランティアの使用量の上限に対する過去の使用状況が表示されるため、プランの選択が容易になります。 詳細は 毎月の使用上限 をご覧ください。 はじめ方 新しいアプリケーションを構築する場合でも、すでに  Amazon Web Services (AWS)  上で運用している場合でも、定額料金プランをすぐに利用開始できます。  CloudFront コンソール にアクセスして、新規または既存のディストリビューションをプランに登録してください。定額料金プランと従量課金制を異なるディストリビューションで組み合わせて使用できるため、アプリケーションごとに最適な料金モデルを柔軟に選択できます。 詳細は プランと機能 、または CloudFront デベロッパーガイド をご覧ください。 著者紹介 Cristian Graziano Cristian Graziano は、シアトルを拠点とする Amazon CloudFront のプリンシパルプロダクトマネージャーです。プロダクト、エンジニアリング、 UX の各チームと連携し、初めて AWS を利用するお客様から経験豊富なお客様まで、あらゆる規模のお客様が Amazon CloudFront および関連する AWS サービスを迅速にオンボーディング、設定、管理できるよう支援しています。 翻訳はプロフェッショナルサービスの鈴木 ( 隆 ) が担当しました。

2025 年 8 月に、 AWS User Experience Customization (UXC) 機能を導入しました。これにより、お客様の特定のニーズに合わせてユーザーインターフェイス (UI) を調整し、タスクを効率的に完了できるようになりました。この機能を使用すると、アカウント管理者は AWS マネジメントコンソール の一部の UI コンポーネントをカスタマイズできます。例えば、 AWS アカウントに色を割り当て 識別しやすくすることが可能です。 2026 年 3 月 26 日、UXC に追加されたカスタマイズ機能を発表いたしました。これによりチームメンバー向けに、関連する AWS リージョンとサービスを選択的に表示できるようになりました。未使用のリージョンとサービスを非表示にすることで、認知的な負荷を軽減し、不要なクリックやスクロールを排除できるため、集中力を高め、作業時間を短縮できます。 今回のリリースにより、アカウントの色、リージョン、サービスの表示を一括してカスタマイズできるようになりました。 アカウントを色で分類 アカウントの色を設定して、視覚的に区別できます。開始するには、 AWS マネジメントコンソール にサインインして、ナビゲーションバーでアカウント名を選択します。アカウントの色はまだ設定されていません。色を設定するには、 [アカウント] を選択します。 [アカウント表示設定] で、希望するアカウントの色を選択し、 [更新] を選択します。選択した色がナビゲーションバーに表示されます。 アカウントの色を変更すると、アカウントの目的を明確に区別できます。例えば、開発アカウントにはオレンジ、テストアカウントには水色、本番稼働アカウントには赤を使用できます。 リージョンとサービスの可視性をカスタマイズ リージョンセレクターに表示する AWS リージョン、またはコンソールナビゲーションに表示する AWS サービスを制御できます。つまり、アカウントに関連するリージョンとサービスのみを表示するように設定できます。 はじめに、ナビゲーションバーの歯車アイコンを選択し、 [すべてのユーザー設定を表示] を選択します。管理者ロールの場合は、統合設定に新しい [アカウント設定] タブが表示されます。設定を行っていない場合、すべてのリージョンとサービスが表示されます。 表示されるリージョンを設定するには、 [表示されるリージョン] セクションの [編集] を選択します。表示されているリージョンを選択して [すべての利用可能なリージョン] または [リージョンを選択] を選択し、リストを設定します。 [変更を保存] をクリックします。 表示されるリージョン設定を設定すると、コンソールのナビゲーションバーのリージョンセレクターに選択したリージョンのみが表示されます。 同じ方法で、表示されるサービスを設定することもできます。カテゴリからサービスを検索または選択します。ここでは [人気のサービス] カテゴリを使用してお気に入りを選択しました。選択が終了したら、 [変更を保存] を選択します。 表示されるサービス設定を設定すると、ナビゲーションバーの [すべてのサービス] メニューに選択したサービスのみが表示されます。 検索バーでサービス名を検索する場合、選択できるのは選択されたサービスのみです。 リージョンとサービスの表示設定は、コンソールでのサービスとリージョンの表示のみを制御します。 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDK 、AWS API、または Amazon Q Developer を通じたアクセスは制限されません。 新しい visibleServices パラメータおよび visibleRegions パラメータを使用して、これらのアカウントカスタマイズ設定をプログラムで管理することもできます。例えば、 AWS CloudFormation サンプルテンプレートを使用できます。 AWSTemplateFormatVersion: "2010-09-09" Description: Customize AWS Console appearance for this account Resources: AccountCustomization: Type: AWS::UXC::AccountCustomization Properties: AccountColor: red VisibleServices: - s3 - ec2 - lambda VisibleRegions: - us-east-1 - us-west-2 また、Cloudformation テンプレートをデプロイすることもできます。 $ aws cloudformation deploy \ --template-file account-customization.yaml \ --stack-name my-account-customization 詳細については、「 AWS ユーザーエクスペリエンスのカスタマイズ API リファレンス 」と「 AWS CloudFormation テンプレートリファレンス 」を参照してください。 今すぐ AWS マネジメントコンソール で試し、コンソールの下部にある フィードバック リンクを選択するか、 AWS マネジメントコンソールの AWS re:Post フォーラム に投稿するか、AWS サポートの連絡先にフィードバックをお寄せください。 – Channy 原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 関東では先週から桜が咲いていてとても癒されています。 そんな先週の 3 月 26 日には、 Amazon Quick が東京リージョンにて一般提供開始されました。日本のお客様がより便利に使えるようになりましたので、ぜひお試しいただければと思います。 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。 それでは、3 月 23 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS 生成 AI 国内事例ブログ「キヤノン株式会社イメージング事業本部様にて生成 AI ハッカソンを開催！生成 AI をフル活用し社内課題を解決する 5 つのシステムを開発」を公開 キヤノン株式会社イメージング事業本部様と AWS が共同で生成 AI ハッカソンを実施しました。約 20 名のエンジニアが 5 チームに分かれ、Amazon Bedrock や Amazon Q Developer を活用して社内業務の課題を解決するプロトタイプを開発した取り組みと成果を紹介しています。 AWS 生成 AI 国内事例ブログ「AI 時代に組織はどう変わるか — Jeff Barr が語る開発チームの未来と、三菱電機の挑戦」を公開 三菱電機グループの社内 AWS ユーザーグループ「MAWS」シリーズ第 3 弾です。755 名に成長した MAWS のリーダーたちと AWS VP / Chief Evangelist の Jeff Barr とのセッションを通じて、AI 時代における「2 Pizza チームから 1 Pizza チームへ」の組織変化、生産性向上に伴うダウンストリームのボトルネック、「High Judgment」を軸とした人材育成など、開発組織の未来について議論した内容をレポートしています。 ブログ記事「AWS Security Agent 徹底解説: 自動ペネトレーションテストのためのマルチエージェントアーキテクチャ」を公開 AWS Security Agent に組み込まれた自動ペネトレーションテストコンポーネントのアーキテクチャを技術的に解説しています。専門化された複数の AI エージェントが連携し、認証・ベースラインスキャン・多段階探索・検証という一連のワークフローで脆弱性を検出するマルチエージェントシステムの仕組みや、CVE Bench ベンチマークでの評価結果を紹介しています。 ブログ記事「Kiro で Amazon Connect AI エージェント開発を加速」を公開 AI コーディングアシスタント Kiro を使って、15 のバックエンド API を備えた Amazon Connect AI エージェントをわずか 3 日間で構築した事例を紹介しています。仕様駆動設計、高速なコード生成、CloudWatch Logs の自動分析による 10〜20 分のイテレーションサイクルなど、従来 2〜3 週間かかる開発を大幅に短縮した方法を解説しています。 ブログ記事「エージェンティック AI と AWS Transform でメインフレームアプリケーションを再構想 (reimagine) する」を公開 AWS Transform for mainframe と Kiro を活用し、レガシー COBOL アプリケーションをモダンなクラウドネイティブのマイクロサービスに変換する reimagine パターンを解説しています。リバースエンジニアリング、フォワードエンジニアリング、デプロイとテストの 3 フェーズによるモダナイゼーションアプローチと、Strangler fig パターンによる段階的な移行方法を紹介しています。 ブログ記事「Amazon Quick が AWS アジアパシフィック (東京) リージョンで利用可能になりました」を公開 AI ベースのデジタルワークスペース Amazon Quick が東京リージョンで利用可能になりました。Quick Index、Quick Research、Quick Sight、Quick Flows、Quick Automate の 5 つの機能により、データからのインサイト取得、ダッシュボード生成、ワークフロー自動化を 1 つのプラットフォームで実現します。お客様はデータを日本国内にとどめつつ、低レイテンシ―で AI 分析や自動化機能を利用可能になりました。 ブログ記事「AWS DevOps Agent を本番環境にデプロイするためのベストプラクティス」を公開 AWS DevOps Agent の効果を最大化するための Agent Space の設計・実装に関するベストプラクティスを紹介しています。オンコールの責任範囲に基づいた Agent Space の境界設計、IAM ロールの設定、オブザーバビリティツールとの統合、IaC を活用したデプロイの効率化など、調査能力と運用効率のバランスを取るための実践的なガイダンスを提供しています。 ブログ記事「Claude Code on Amazon Bedrock のデプロイパターンとベストプラクティス」を公開 Claude Code を Amazon Bedrock でエンタープライズ規模にデプロイするための方法を解説しています。認証方式（API キー、SSO、直接の IdP 統合）の比較、専用 AWS アカウントの推奨、OpenTelemetry によるモニタリング戦略、CloudWatch ダッシュボードや分析スタックによるコスト可視化など、安全かつ効率的に運用するためのノウハウを紹介しています。 サービスアップデート Agent Plugin for AWS Serverless で AI 支援開発を加速 AWS が Agent Plugin for AWS Serverless を発表しました。この Plugin により、Claude Code や Cursor などの AI コーディングアシスタントを使って、サーバーレスアプリケーションの開発が格段に簡単になります。従来は手動で行っていた Lambda 関数の作成や EventBridge との連携などの各種サーバーレスサービスの設定が、AI の支援で自動化されます。さらに SAM や CDK を使った Infrastructure as Code の実装、API Gateway の設計まで、ベストプラクティスに従った開発を AI がサポートしてくれます。詳細は こちらの GitHu b をご参照ください。 Writer の Palmyra Vision 7B が Amazon Bedrock で利用可能に Amazon Bedrock で Writer の Palmyra Vision 7B モデルが利用開始されました。このモデルは画像を理解してテキストを生成する AI で、文書分析やチャート解釈、手書き文字の抽出などが可能です。これまで画像内容を理解するには別のツールが必要でしたが、Bedrock 上で簡単に画像理解機能を組み込めるようになります。詳細は こちらのドキュメント をご参照ください。 Amazon Bedrock AgentCore Runtime が永続的なエージェントファイルシステム状態のためのマネージドセッションストレージをサポート開始 (プレビュー) Amazon Bedrock AgentCore Runtime で、エージェントのファイルシステム状態を永続化できる機能がプレビュー開始されました。これまで AI エージェントがコードを書いたりパッケージをインストールしても、セッション終了時に全て失われていました。新機能により、エージェントが作成したファイルやインストールしたパッケージが自動的に保存され、次回のセッションでも継続して作業できるようになります。最大 1GB まで、14 日間データを保持します。詳細は こちらのドキュメント をご参照ください。 AWS Step Functions が Amazon Bedrock AgentCore を含む 28 の新しいサービス統合を追加 AWS Step Functions が 28 の新サービス統合を追加し、Amazon Bedrock AgentCore や Amazon S3 Vectors など 1,100 以上の新 API アクションが利用可能になりました。これにより複雑な統合コードを書かずに、AI エージェントの並列実行やドキュメント取り込みパイプラインの自動化などが簡単に構築できます。詳細は こちらの開発者ガイド をご参照ください。 Amazon SageMaker HyperPod が Slurm オーケストレーションクラスターの継続プロビジョニングをサポート Amazon SageMaker HyperPod の Slurm 環境で連続プロビジョニング機能が利用可能になりました。従来は一部のインスタンスグループでプロビジョニングが失敗すると、クラスター全体の作成や拡張が失敗してロールバックされていました。今回のアップデートにより、利用可能なインスタンスで即座に AI/ML トレーニングを開始でき、バックグラウンドで残りの容量を自動的にプロビジョニングします。失敗したノードは非同期で再試行され、複数のインスタンスグループでの同時スケーリングも可能です。CreateCluster API で NodeProvisioningMode を Continuous に設定することで有効化できます。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker AI が 12 の追加モデルに対してサーバーレス強化学習ファインチューニングをサポート Amazon SageMaker AI で 12 の新しいモデルに対してサーバーレス強化学習ファインチューニングが利用可能になりました。これまではインフラの準備や管理が必要でしたが、今回のアップデートにより Qwen や DeepSeek シリーズなどの最新モデルを手軽にカスタマイズできます。特にコード生成や数学的推論など、従来の教師あり学習では難しかった複雑なタスクに対応可能で、従量課金制のため小規模な実験からでも始められます。バージニア北部、オレゴン、東京、アイルランドリージョンで提供中です。 Amazon SageMaker Studio が Kiro と Cursor IDE をリモート IDE としてサポート開始 Amazon SageMaker Studio で Kiro と Cursor IDE のリモート接続がサポートされました。データサイエンティストや ML エンジニアが、普段使い慣れた Kiro や Cursor IDE の環境を維持しながら、SageMaker Studio のクラウド計算リソースにアクセスできます。AWS Toolkit 拡張機能を使って簡単に接続でき、ローカル IDE とクラウド間のコンテキストスイッチを排除して開発効率が向上します。詳細は こちらのドキュメント をご参照ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 だんだんと春めいてきて、花粉症に悩まされている方も多いのではないでしょうか。私はというと、今年はなぜか症状がほとんど出ず、久しぶりに快適に仕事ができています。 NRF 2026 で注目されたリテール AI の最新動向を扱う流通・小売・消費財むけイベントを 4月20日 に開催します。 「リテールの現場では「AIエージェントが“主”、人間が“従”」に　AWSジャパン・五十嵐氏に聞く小売業界におけるマルチエージェントの台頭」 こちらの記事 をご参照いただき、AWS メンバーへ気軽にお声がけください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年3月23日週の主要なアップデート 3/25(水) Amazon Bedrock AgentCore Runtime が永続的なエージェントファイルシステム状態のためのマネージドセッションストレージをサポート開始 (プレビュー) Amazon Bedrock AgentCore Runtime で、エージェントのファイルシステム状態を永続化できる機能がプレビュー開始されました。これまで AI エージェントがコードを書いたりパッケージをインストールしても、セッション終了時に全て失われていました。新機能により、エージェントが作成したファイルやインストールしたパッケージが自動的に保存され、次回のセッションでも継続して作業できるようになります。最大 1GB まで、14 日間データを保持します。詳細は こちらのドキュメントをご参照ください。 Amazon SageMaker HyperPod が Slurm オーケストレーションクラスターの継続プロビジョニングをサポート Amazon SageMaker HyperPod の Slurm 環境で連続プロビジョニング機能が利用可能になりました。従来は一部のインスタンスグループでプロビジョニングが失敗すると、クラスター全体の作成や拡張が失敗してロールバックされていました。今回のアップデートにより、利用可能なインスタンスで即座に AI/ML トレーニングを開始でき、バックグラウンドで残りの容量を自動的にプロビジョニングします。失敗したノードは非同期で再試行され、複数のインスタンスグループでの同時スケーリングも可能です。CreateCluster API で NodeProvisioningMode を Continuous に設定することで有効化できます。詳細は こちらのドキュメントをご参照ください。 P6-B300 と Slurm 25.11 をサポートした AWS ParallelCluster 3.15 AWS ParallelCluster 3.15 が一般提供開始となり、最新の NVIDIA Blackwell GPU を搭載した P6-B300 インスタンスと Slurm 25.11 をサポートしました。これにより AI/ML や高性能コンピューティング (HPC) ワークロードをより高性能な環境で実行できるようになります。EFA ネットワーク設定の改善や大規模クラスターでの密結合ワークロードの性能向上も実現し、科学技術計算がより効率的に処理できます。詳細は こちらのリリースノートをご参照ください。 AWS Transfer Family Applicability Statement 2 (AS2) が MDN の非同期受信をサポート AWS Transfer Family の AS2 で、非同期での MDN (Message Disposition Notifications) 受信がサポートされました。従来は同期のみでしたが、取引先の処理時間やネットワーク遅延に関係なく AS2 ワークフローを移行できます。ヘルスケアや製造業などでパートナーとの安全なデータ交換が可能になります。詳細は こちらのドキュメントをご参照ください。 Amazon SageMaker AI が 12 の追加モデルに対してサーバーレス強化学習ファインチューニングをサポート Amazon SageMaker AI で 12 の新しいモデルに対してサーバーレス強化学習ファインチューニングが利用可能になりました。これまではインフラの準備や管理が必要でしたが、今回のアップデートにより Qwen や DeepSeek シリーズなどの最新モデルを手軽にカスタマイズできます。特にコード生成や数学的推論など、従来の教師あり学習では難しかった複雑なタスクに対応可能で、従量課金制のため小規模な実験からでも始められます。バージニア北部、オレゴン、東京、アイルランドリージョンで提供中です。 Amazon Aurora PostgreSQL が数秒でのデータベース作成と接続をサポート Amazon Aurora PostgreSQL で Express Configuration という新機能が登場し、サーバーレスデータベースを数秒で作成・接続できるようになりました。従来は VPC やネットワーク設定に時間がかかっていましたが、事前設定済みの構成により初期セットアップが大幅に高速化されています。インターネットアクセスゲートウェイが自動で設定され、 VPN や AWS Direct Connect なしで開発ツールから直接接続可能です。また IAM 認証がデフォルトで有効化されるため、パスワード不要でセキュアにアクセスできます。 AWS Free Tier でも利用可能なので、 PostgreSQL を手軽に試したい開発者には最適です。詳細は こちらの Blog 記事をご参照ください。 Amazon Aurora PostgreSQL が AWS 無料利用枠で利用可能になりました Amazon Aurora PostgreSQL が AWS 無料枠で利用可能になりました。新規ユーザーはサインアップ時に 100 ドルのクレジットを取得でき、追加で 100 ドルのクレジットも獲得できます。従来は有料プランでしか利用できなかった高性能な PostgreSQL データベースを、無料で試すことができるようになったのが大きなメリットです。express configuration を使えば数秒でデータベースを作成・クエリ実行が可能で、学習コストを大幅に削減できます。詳細は こちらをご参照ください。 Amazon Route 53 Profiles がリソースと VPC 関連付けに対する詳細な IAM 権限をサポート Amazon Route 53 Profiles で細かい IAM 権限設定が可能になりました。これまでは Profile 全体への権限管理でしたが、今回のアップデートでプライベートホストゾーンや DNS Firewall ルールなど、特定のリソースタイプごとに権限を制御できます。例えば、特定の VPC への関連付け操作のみを許可したり、特定のドメイン名のルールだけ編集権限を与えるといった細かな権限設定が実現できます。組織内で DNS 管理の責任を分散させつつ、セキュリティを保てるため大規模な環境での運用が格段に楽になります。詳細は こちらのドキュメントをご参照ください。 3/26(木) AWS Advanced JDBC Wrapper が Valkey による自動クエリキャッシュをサポート AWS Advanced JDBC Wrapper が Valkey を使った自動クエリキャッシュ機能をサポートしました。従来は JDBC クエリの結果をキャッシュするために、開発者が手動でコードを書く必要がありましたが、今回のアップデートで数ステップの簡単な設定だけで自動化できるようになりました。Aurora や RDS の PostgreSQL、MySQL、MariaDB データベースのクエリ結果を Amazon ElastiCache for Valkey に保存し、頻繁にアクセスするデータの読み取り遅延を削減できます。これによりデータベースへの読み取り回数が減り、パフォーマンス向上とコスト削減を実現できます。Hibernate や Spring Data といった人気フレームワークにも対応しているため、既存のアプリケーションへの導入も簡単です。詳細は こちらのドキュメントをご参照ください。 AWS AppConfig がフィーチャーフラグロールアウト中の拡張ターゲティングを追加 AWS AppConfig にフィーチャーフラグの段階的ロールアウト中に特定のユーザーやセグメントをターゲットできる新機能が追加されました。従来は段階的デプロイメント中に特定のユーザーグループだけに絞って配信することが難しかったのですが、今回のアップデートにより個別の ユーザー ID やセグメント単位での細かい制御が可能になります。これにより新機能のリリース時のリスクを大幅に削減でき、A/B テストや段階的な機能展開がより安全に実施できるようになります。詳細は こちらのドキュメントをご参照ください。 Writer の Palmyra Vision 7B が Amazon Bedrock で利用可能に Amazon Bedrock で Writer の Palmyra Vision 7B モデルが利用開始されました。このモデルは画像を理解してテキストを生成する AI で、文書分析やチャート解釈、手書き文字の抽出などが可能です。これまで画像内容を理解するには別のツールが必要でしたが、Bedrock 上で簡単に画像理解機能を組み込めるようになります。詳細は こちらのドキュメントをご参照ください。 3/27(金) Amazon GameLift Servers が次世代 EC2 インスタンスファミリーでインスタンスサポートを拡張 Amazon GameLift Servers が EC2 第 5 ～ 8 世代インスタンスに対応しました。これまでより新しい世代の EC2 インスタンスを利用できるようになり、ゲームサーバーのホスティングにおいて価格性能比の向上と効率性が実現されます。汎用 (M シリーズ)、コンピューティング最適化 (C シリーズ)、メモリ最適化 (R シリーズ) の 3 つのインスタンスファミリーから、ゲームの負荷特性に応じて最適な選択が可能です。詳細は こちらのドキュメントをご参照ください。 AWS Management Console でサービスとリージョンの表示を制御する設定をサポート開始 AWS Management Console で、表示するサービスとリージョンを制御できる設定が一般提供開始されました。これまで全てのサービスやリージョンが表示されていましたが、必要なもののみを表示することでナビゲーションが簡素化され、チームメンバーが利用可能なリソースを素早く特定できます。アカウント設定の Unified Settings から設定でき、CLI や SDK からのプログラム設定にも対応しています。詳細は こちらのドキュメント をご参照ください。 AWS Lambda が Lambda マネージドインスタンスで最大 32 GB のメモリと 16 vCPU をサポート AWS Lambda Managed Instances で最大 32 GB のメモリと 16 vCPU がサポートされるようになりました。これまでは 10 GB メモリと約 6 vCPU が上限でしたが、大規模なデータ処理やメディア変換などの計算集約的なワークロードも実行可能になります。メモリ対 vCPU の比率 (2:1、4:1、8:1) も選択でき、ワークロードの特性に合わせて最適なリソース配分を設定できます。詳細は こちらのドキュメントをご参照ください。 Amazon CloudWatch Logs が Infrequent Access 取り込みクラスでデータ保護、OpenSearch PPL、OpenSearch SQL をサポート開始 Amazon CloudWatch Logs の Infrequent Access (IA) クラスで、データ保護機能と OpenSearch PPL / SQL クエリがサポートされました。従来は Logs Insights のみでしたが、今回のアップデートにより SQL ベースの高度な分析が可能になります。また、ログ内の機密情報を自動検出・マスキングできるため、セキュリティ要件を満たしながらコスト効率的にログを統合できます。詳細は こちらのドキュメントをご参照ください。 今週はアップデートの内容に少し偏りがあり、月・火は落ち着いていた一方で、週の後半に多くの更新が集中しました。 Bedrock まわりのアップデートが引き続き活発に行われる中、Webアプリ構築でよく使う基本サービスにも多くの改良がありました。特に、Amazon Aurora PostgreSQL がついに無料利用枠で使えるようになったのは大きな変化で、今後は Aurora を活用したアプリ開発がさらに進みそうだと感じています。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

この記事は 2026 年 3 月 3 日に公開された “The Hidden Price Tag: Uncovering Hidden Costs in Cloud Architectures with the AWS Well-Architected Framework | Amazon Web Services” を翻訳したものです。 AWS とクラウドコンピューティングは、企業の業務運営のあり方を変革しました。組織はクラウド上で大規模にデータを保存、処理、管理できるようになり、コンピューティングリソースをユーティリティとして扱えるようになりました。クラウドアーキテクチャの設計では、それぞれの要件に適したソリューションを見つけるためにトレードオフを検討する必要があります。クラウドアーキテクチャ設計においてベストプラクティスに従わない場合、望ましくない結果や、セキュリティイベントや可用性イベントに伴うコストなどの隠れたコストが発生する可能性があります。 アーキテクチャに関する意思決定の影響は、技術面だけでなく、企業の評判、規制コンプライアンス、市場機会にまで及びます。 IBM と Ponemon Institute の調査 によると、クラウドの設定ミスに関するリスクは過去 10 年間で重要なセキュリティ上の考慮事項として浮上しており、クラウドインフラストラクチャの重要性の高まりを反映しています。このレポートでは、AI の導入が急速に進んでおり、セキュリティとガバナンスのフレームワークを強化する新たな機会が生まれていることが強調されています。調査結果は、AI システムが堅牢なアーキテクチャとガバナンスの実践に基づいて実装された場合に、組織が最も大きな恩恵を受けることを示しています。 クラウドへの移行に際しては、クラウドアーキテクチャのベストプラクティスを優先してください。この記事では、 AWS Cloud Adoption Framework （AWS CAF）と AWS Well-Architected Framework に従うことで、AWS のガイダンスとベストプラクティスを適切に実装し、これらのリスクを軽減する方法について説明します。また、リソースの制約、トレードオフの評価、相反するビジネス上の優先事項など、組織がこれらのベストプラクティスを実装する際に直面する課題についても取り扱います。 背景 AWS CAF は、変革の機会を特定し、クラウドへの準備状況を評価し、AWS のベストプラクティスを活用して変革のロードマップを構築するのに役立ちます。 AWS Well-Architected Framework は、クラウドアーキテクトがアプリケーション向けに安全で高パフォーマンス、回復力があり、効率的で持続可能なインフラストラクチャを構築するのを支援します。このフレームワークは、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性の 6 つの柱に基づくガイダンスを提供します。AWS Well-Architected Framework を活用することで、クラウドでのワークロードのアーキテクチャ設計に関する戦略とベストプラクティスを学び、これらのベストプラクティスに照らしてアーキテクチャを評価し、特定された問題の修正を通じてアーキテクチャを改善できます。 AWS Well-Architected Tool で特定される高リスク問題（HRI）は、お客様のビジネスに重大な悪影響を及ぼす可能性があると AWS が判断したアーキテクチャおよび運用上の選択です。これらの HRI は、組織の運営、資産、個人に影響を与える可能性があります。中リスク問題（MRI）もビジネスに悪影響を及ぼす可能性がありますが、その程度は低くなります。これらの問題は、AWS Well-Architected Tool でのお客様の回答に基づいています。低リスク問題（LRI）は、継続的な監視と評価が必要です。クラウド環境は動的であり、今日低リスクであるものが、アーキテクチャ、アプリケーション、または脅威の状況の変化により、明日にはより高いリスクになる可能性があります。重要なのは、クラウドアーキテクチャを常にレビューし改善して、低リスクプロファイルを維持し、AWS クラウドのメリットを最大化することです。 AWS Well-Architected Lenses は、AWS Well-Architected Framework が提供するガイダンスを、生成 AI などの特定の業界やテクノロジードメインに拡張します。生成 AI は、実験的なプロジェクトからミッションクリティカルなエンタープライズアプリケーションへと急速に進化しています。しかし、多くの組織は大きな課題に直面しています。それは、生成 AI のプロトタイプを、実際のビジネスに大きな価値をもたらす堅牢な本番システムへと移行することです。組織が AI の活用機会を模索する中で、包括的な Well-Architected ガイダンスに基づいた 、安全でコンプライアンスに準拠し、コスト効率の高いソリューションを設計することが、本番環境での成功に不可欠になります。 AWS Generative AI Lens は、AWS 上で 生成 AI ワークロードを設計・運用するためのアーキテクチャのベストプラクティスを提供します。 最適化されていないアーキテクチャが隠れたコストを生み出す 3 つの領域、セキュリティ、可用性、リソース効率について見ていきましょう。 最適化されていないクラウドアーキテクチャの隠れたコスト：セキュリティ、可用性、コスト クラウドセキュリティは資産を保護し、競争上の優位性を生み出します。堅牢なセキュリティアーキテクチャは、ビジネス目標、収益、評判に影響を与える可能性のあるインシデントのリスクを軽減します。データと知的財産を保護し、さまざまな規制要件へのコンプライアンスの強化につながります。この強固なセキュリティ体制は、ビジネス機会を直接的に改善し、セキュリティインシデントに関連する隠れたコストのリスクを軽減します。 適切に設計されたクラウドアーキテクチャは、サービスの信頼性を確保し、中断やダウンタイムのリスクを軽減するのに役立ちます。ダウンタイムに関連する一般的なコストには、生産性と収益の損失、お客様に対するサービスレベルアグリーメント（SLA）の未達成などがあります。可用性の中断は、従業員が業務に必要なシステムやツールにアクセスできなくなるため、生産性の低下につながる可能性があります。これらの懸念は、ビジネスの成果と収益に直接影響を与える可能性があります。SLA を満たせない場合、ペナルティや外部コンサルタントの雇用、新しいインフラの導入といったコストが発生するだけでなく、顧客の不満にもつながる可能性があります。 クラウドプロバイダーは、ストレージ、CPU、メモリリソースなど、幅広いサービスを提供しています。パフォーマンスの問題を回避するためにクラウドリソースを過剰にプロビジョニングすると、不要なコストが発生することがよくあります。ハードウェアの制限がワークロードのパフォーマンスに影響を与えるリスクを軽減できる可能性がありますが、過剰な割り当てにはそれ自体の財務的なデメリットがあります。リソースの需要はワークロードによって大きく異なります。多くのアプリケーションは 24 時間 365 日の継続的な稼働を必要としません。週末は休止状態のものもあれば、月に数日しかアクティブにならないものもあります。季節的なパターンに従い、年間を通じてリソースのニーズが変動するワークロードもあります。クラウド環境における効率的なリソース配分とコスト管理には、これらの多様な使用パターンを理解することが不可欠です。 AWS Well-Architected Framework が不要なコストの回避にどのように役立つか AWS Well-Architected Framework は、安全で信頼性が高く、コスト効率の良いクラウドインフラストラクチャを構築するための堅牢なガイドラインを提供します。フレームワークのベストプラクティスとアーキテクチャパターンに従うことで、組織はセキュリティイベント、可用性の中断、非効率なリソース利用に関連するリスクとコストを最小限に抑え、より成功した収益性の高いクラウドデプロイメントを実現できます。 AWS Well-Architected Framework によるセキュリティリスクの軽減 AWS Well-Architected Framework はセキュリティを重視 しており、6 つの柱の 1 つとして位置付けています。フレームワークに記載されているベストプラクティスに従うことで、ワークロードのセキュリティ体制を改善し、インシデントのリスクとそれに伴う潜在的な隠れたコストを軽減できます。以下にセキュリティのベストプラクティスをいくつか紹介します。 ID とアクセス管理 – フレームワークは、最小権限の原則、多要素認証、アクセスポリシーの定期的な監査など、強力な ID とアクセス管理の実践を推奨しており、クラウドリソースへの不正アクセスの防止に役立ちます。 データ保護 – フレームワークは、保存時および転送時のデータ暗号化の使用を推奨し、機密情報の安全性を確保して不正アクセスや意図しないアクセスのリスクを軽減します。また、 データへの直接アクセスを制限する メカニズムの構築も推奨しています。 インフラストラクチャの保護 – フレームワークのガイドラインに従い、ネットワークセグメンテーション、侵入検知・防止システム、自動パッチ管理を実装して、潜在的なイベントからクラウドインフラストラクチャを保護できます。 モニタリングとインシデント対応 – フレームワークは、AWS 環境の継続的なモニタリング、自動化されたセキュリティアラート、効果的なインシデント対応計画を推奨し、潜在的なセキュリティイベントを迅速に検出して軽減します。 AWS Well-Architected Framework によるダウンタイムの最小化 AWS Well-Architected Framework の信頼性の柱 は、ビジネスのダウンタイムとそれに関連するコストを最小限に抑えるのに役立ちます。例えば： 耐障害性と高可用性 – フレームワークは、冗長性、自動フェイルオーバー、分散システムアーキテクチャなどの手法を使用して、コンポーネントの障害や停止時でも継続的な運用を確保する、耐障害性と高可用性を備えたシステムの設計を推奨しています。 スケーラビリティ – フレームワークは、需要に基づいて自動的にスケールするシステムの設計を推奨しており、ビジネスがピーク負荷に対応し、最適なパフォーマンスを維持できるようにします。 バックアップとディザスタリカバリ – フレームワークは、データ損失やインフラストラクチャ障害から迅速に復旧するために、定期的なデータバックアップと堅牢なディザスタリカバリ計画の実装を推奨しています。バックアップとリカバリ計画の定期的なテストも推奨事項に含まれています。 モニタリングとパフォーマンス管理 – フレームワークは、システムパフォーマンスの モニタリングとオブザーバビリティ 、およびプロアクティブなパフォーマンス管理手法の使用を推奨し、ダウンタイムにつながる前に潜在的な問題を特定して解決します。 AWS Well-Architected Framework による運用コストの最適化 AWS Well-Architected Framework のコスト最適化の柱 は、運用費用を抑えとクラウド投資の効果を最大化します。以下はその例の一部です。 リソース効率 – フレームワークは、クラウドリソースの適正化と統合を推奨し、必要なリソースに対してのみ料金を支払うようにします。 コストを意識したアーキテクチャ – フレームワークは、アーキテクチャの決定がコストにもたらす影響を意識するよう推奨し、パフォーマンスやセキュリティを損なうことなくコスト効率の高いソリューションを特定するのに役立ちます。 モニタリングとコスト管理 – フレームワークは、クラウド支出の定期的なモニタリングと分析を推奨し、無駄な支出を特定・削減してコストを最適化するのに役立ちます。 料金モデルの理解 – フレームワークは、特定のニーズに基づいてコストを最適化するために設計されたさまざまなクラウド料金モデルを理解し活用することを推奨しています。これには、オンデマンド、リザーブドインスタンス、Savings Plans、スポットインスタンスが含まれ、それぞれに独自の利点と理想的なユースケースがあります。これらのモデルとその違いを理解することは、AWS クラウドにおける効果的なコスト最適化に不可欠です。 まとめ 組織は、人的ミス、システムの設定ミス、自然災害、インフラの問題、サイバー攻撃など、さまざまな原因によるサービス中断のリスクに常にさらされています。ビジネス、テクノロジー、セキュリティの各リーダーは、セキュリティ対策を強化し、リソースをより効果的に配分し、 障害に強いシステムを構築する ことで、サービス中断や最適化されていないクラウドアーキテクチャによるリスクを減らすことができます。効果的なクラウド設計と最適化は、コスト削減だけでなく、それ以上の価値をもたらします。例えば： 節約したリソースを再投資することで、イノベーションを加速 セキュリティと運用効率の向上 ビジネスニーズに合わせて拡張・対応できる能力の向上 より良い顧客体験と市場投入までの時間の短縮 Well-Architected の各柱のトレードオフを考慮して、適切なアーキテクチャを判断する能力 障害や需要の急増に自動で対処する仕組みを構築し、エンドユーザーに影響が及ぶ前に中断やレイテンシーの問題を防ぐ クラウド最適化の取り組みを加速するために、AWS はいくつかのツールとリソースを提供しています。 AWS Cloud Adoption Framework – クラウド導入への準備状況を評価 AWS Well-Architected Framework – 6 つの柱すべてにわたる詳細なガイダンス AWS Well-Architected Tool – AWS のベストプラクティスに照らしてワークロードを評価 AWS Well-Architected Lenses – Generative AI Lens といった、特定の業界やテクノロジー領域に対応した AWS Well-Architected の拡張機能 AWS Health – AWS リソースのパフォーマンスと、AWS サービス・アカウントの可用性を可視化して向上 AWS Trusted Advisor – コスト最適化、パフォーマンス改善、セキュリティギャップへの対応 Well-Architected IAC (Infrastructure as Code) Analyzer ツール – AWS CloudFormation や Terraform などの Infrastructure as Code（IaC）テンプレートを AWS Well-Architected Framework に照らして自動評価 AWS では、お客様のクラウドジャーニーの最適化を支援しています。AWS CAF と AWS Well-Architected Framework に記載されているこれらの戦略とベストプラクティスを実践することで、セキュリティと運用上の優秀性を維持しながら、クラウドの可能性を最大限に引き出し、イノベーションと成長を推進できます。 まず、ワークロードに対して AWS Well-Architected Framework Review を実施することから始めましょう。AWS ソリューションアーキテクト、テクニカルアカウントマネージャー、および AWS Well-Architected パートナー のネットワークの活用をご検討ください。これらの専門家が AWS CAF レビューと Well-Architected Framework Review を実施を支援します。これらの専門知識と AWS の柔軟なインフラストラクチャを組み合わせることで、効果的にスケールし、デジタル時代における持続可能な成長のための強固なクラウド基盤を構築できます。 本ブログはテクニカルアカウントマネージャーの井上が翻訳しました。原文は こちら です。 Ryan Dsouza Ryan Dsouza は、AWS の Cloud Optimization 組織に所属する Principal Guidance Lead Solutions Architect です。ニューヨーク市を拠点とし、AWS の幅広い機能を活用して、お客様がより安全でスケーラブル、かつ革新的なソリューションを設計、開発、運用し、測定可能なビジネス成果を達成できるよう支援しています。AWS Cloud Adoption Framework と AWS Well-Architected Framework に準拠し、パフォーマンス、コスト効率、セキュリティ、レジリエンス、運用上の優秀性を最適化するクラウドソリューションのアーキテクチャを支援するための戦略、ガイダンス、ツールの開発に積極的に取り組んでいます。LinkedIn プロフィール： https://www.linkedin.com/in/ryandsouzaaws/ Bradley Acar Bradley Acar は、IT 分野で 20 年以上の経験を持ち、そのうち約 10 年を AWS で過ごしています。お客様がレジリエントでスケーラブルなシステムを設計するのを支援してきた豊富な経験を持ち、技術的な実装とビジネス成果の橋渡しに注力しています。AWS のベストプラクティス、新興テクノロジー、デジタルトランスフォーメーション戦略に関する知見を定期的に発信し、組織がクラウド投資を最大限に活用できるよう支援しています。

2026 年 3 月 24 日に公開された “ Building a modern network for your VMware workloads using Amazon Elastic VMware Service ” を翻訳したものです。 組織がクラウド移行を加速させようとする中で、多くのお客様は既存の VMware ワークロードを Amazon Web Services (AWS) にリフトアンドシフトする方法を求めており、アプリケーションのリファクタリングやスタッフの再トレーニングのオーバーヘッドを避けたいと考えています。 Amazon Elastic VMware service (Amazon EVS) は、VMware Cloud Foundation (VCF) を Amazon Virtual Private Cloud (VPC) 内で直接実行でき、VMware ワークロードを AWS で移行・運用するための最も迅速な方法を提供します。 VMware ワークロードを AWS に移行する際にお客様が課題として挙げるのが、クラウドでのネットワーク接続とアーキテクチャ設計です。Amazon EVS のネットワークモデルは、一般的なオンプレミスの VMware デプロイメントとはいくつかの違いがあります。本稿では、Amazon EVS のネットワークモデルを解説し、実証済みのアーキテクチャパターンをご紹介し、Amazon EVS の計画と導入を成功させるための重要な考慮事項をご説明します。 Amazon EVS ネットワークコンポーネント Amazon EVS は、図 1 に示すように、AWS インフラストラクチャ上で VCF ワークロードをデプロイし、運用するために構築された AWS マネージド自動化フレームワークです。Amazon EVS は、VCF の Software-Defined Data Center (SDDC) スタック (vSphere, vSAN, NSX) を Amazon VPC に完全に統合し、VMware ツールと API を保持しながら、シームレスなハイブリッドクラウド運用を可能にします。Amazon EVS ネットワークは、Amazon VPC ネットワークを分離する 2 層モデルに従い、お客様が VMware NSX Software-Defined Networking を使用できるようにします。 アンダーレイ層 (VPC infrastructure) : Amazon VPC, サブネット, ルートテーブル, およびお客様が選択したサブネット内で実行される ENI 接続 ESXi ホストで構成されます。この層はホストマネジメントトラフィック (vSphere, vSAN) を処理し、デフォルトまたはメイン VPC ルートテーブルを通じて IP 接続を実現します。 オーバーレイ層 (NSX Software-Defined Networking) : NSX Manager はマネジメントワークロードドメイン内にデプロイされ、ロジカルスイッチ (セグメント), T0/T1 ゲートウェイ, およびサービス (NAT, Load Balancing, DHCP) をオーケストレーションします。NSX マイクロセグメンテーションとポータブルネットワークポリシーが有効化され、アンダーレイ VPC ネットワークから抽象化し、お客様のワークロードはオーバーレイセグメント上でのみ実行されます。 図 1: ルートサーバーエンドポイントを使用した Amazon EVS と Amazon VPC の統合 主要コンポーネントの詳細 vSphere クラスター: Amazon EVS は統合された VCF アーキテクチャ (vCenter, NSX Manager, vSAN) をデプロイし、お客様が 1 つ以上のワークロードドメインを作成できるようにします。ESXi ホストは、お客様所有の VPC とサブネット内で Amazon Elastic Compute Cloud (Amazon EC2) ベアメタルインスタンス (例: i4i.metal) として起動されます。SDDC Manager と vCenter は、SDDC と vSphere クラスターコンポーネントの管理を担います。これらのコンポーネントは、管理ドメインとも呼ばれる最初の SDDC クラスター内で実行されます。さらに、3 つのクラスター化された NSX Manager が SDDC クラスター内で実行され、一元化されたネットワークポリシーオーケストレーションを可能にします。コントロールプレーンは、オーバーレイトランスポートゾーン、セグメントプロファイル、ゲートウェイファイアウォールルールを設定します。 NSX Edge ノード: 2 つの Edge ノードが最初のクラスターまたは管理ドメイン内の Edge クラスターにデプロイされます。T0 Gateway は各 AWS アベイラビリティーゾーン (AZ) サブネット内の VPC ルートサーバーエンドポイントと eBGP ピアリングを確立し、オーバーレイ CIDR をアドバタイズします。T1 Gateway (テナント/ワークロードごとに 1 つ) はセグメントを接続し、ステートフルサービスを提供します。NSX Edge はレジリエンシーのためにアクティブ-スタンバイ構成です。 VPC ルートサーバーエンドポイントと BGP ピアリング: Amazon EVS は Amazon VPC ルートサーバー をアンダーレイ BGP ネイバーとして使用します。各 T0 Edge は VPC ルートサーバーエンドポイントに接続し、アンダーレイ ENI 上で eBGP セッションを確立します。VPC のデフォルトまたはメインルートテーブルのみが変更されます。Amazon EVS はアウトバウンドトラフィック用に T0 ENI を指す 0.0.0.0/0 を注入し、オーバーレイプレフィックスをインバウンドに伝播します。この設計により、カスタムルートテーブルの拡散が排除され、自動化が合理化されます。 ネットワークアーキテクチャの計画 Amazon EVS の導入を成功させるには、導入前のネットワーク計画が重要です。特に CIDR 割り当て、サブネット分離、DNS 解決に関する計画が必要です。Amazon EVS では、運用の安定性、スケーラビリティ、他の AWS サービスとの統合を提供するための厳格な制約があります。これらの領域での設定ミスは、導入失敗の主要な原因となっています。 CIDR の計画と制約 Amazon EVS では、インフラストラクチャとワークロードのネットワークに専用の重複しない CIDR ブロックが必要です。AWS では、この情報をまとめるためのツールをお客様に提供しています。 このツール は、アカウント、VPC、CIDR、DNS の情報を含むスプレッドシートで、オンボーディング中の計画に使用し、プロビジョニング前の実現可能性を検証します。 VCF では、図 2 に示すように、用途毎 (マネジメント, vSAN, NSX インターフェース, アプライアンスなど) に異なるサブネットを使用します。Amazon EVS では、適切なサブネットデプロイメントを提供するオーケストレーションを提供します。アンダーレイインフラストラクチャには VPC あたり最小 /24 CIDR が必要で、Amazon EVS マネジメントサブネットではお客様のワークロード (踏み台ホストや監視エージェントを含む) を起動することはできません。これらは VCF コンポーネント専用です。 VCF 以外のサブネットは、同じ VPC 内にデプロイして使用できます。Amazon EVS VPC に他のワークロードを追加する際には、 AWS Well-Architected のベストプラクティスを考慮してください。 Amazon EVS のサブネットの最大サイズは /24 です。host-vtep ネットワークはホストあたり 2 つのアドレスを消費するため、/24 では最大 112 台のホストをホストできます。 図 2: オーバーレイネットワーク用の EVS VLAN サブネット オーバーレイセグメント設計と VM ネットワーク: これらはオーバーレイセグメントに階層的に CIDR を割り当てます (例：アプリケーションティアごとに /24)。成長とワークロード数の増加を想定し、ルートテーブルの効率化のために、ルート集約を検討してください。 CIDR が重複しないこと: すべてのオーバーレイ CIDR は以下と重複してはいけません。 VPC プライマリ CIDR オンプレミスネットワーク ( AWS Direct Connect と AWS Transit Gateway 用) 同じ AWS アカウント内の他の Amazon EVS ワークロードドメイン。Amazon EVS は BGP プレフィックスアドバタイズメントを使用し、重複はサイレントトラフィックブラックホールを引き起こします。 NSX ネットワークセグメント内での重複サブネットは、テスト目的のワークロードを隔離するのに良い方法です。 DNS DNS 解決は Amazon EVS のデプロイメント前に設定と検証を行う必要があります。DNS 解決が適切に行われていない場合やタイプミスがある場合、Amazon EVS (VCF) のデプロイメントは失敗します。 Amazon EVS は DNS 解決に Amazon Route 53 Resolver を使用できます。vCenter と NSX Manager アプライアンスには DNS フォワーダーが事前設定されており、Route 53 Resolver インバウンドエンドポイント (VPC にデプロイ) にクエリを送信できます。 Amazon EVS は Microsoft DNS、Infoblox、その他のサードパーティソリューションなど、他の DNS サービスも使用できます。 Amazon EVS の起動前に外部ホストから nslookup や dig -x でテストを行うことで、時間のかかる潜在的にコストの高いデプロイメント失敗を防ぐことができます。 前提条件 この 前提条件チェックリスト を参照して、デプロイメントを成功させるための情報収集と整理を行ってください。これは、前述した スプレッドシート と併用できます。適切な事前計画により、Amazon EVS ネットワークデプロイメントの問題の 90% を解決できます。このチェックリストでは、以下の項目について触れています。 VPC CIDR Amazon EVS (VCF) サブネット Route 53 Resolver エンドツーエンドで検証された正引き / 逆引き DNS 一般的なネットワークパターン このセクションでは、デプロイメントで検討すべき一般的なアーキテクチャについて説明します。 パターン 1: Transit Gateway と AWS Cloud WAN を使用した Amazon EVS VPC から他の VPC およびオンプレミスネットワークへの接続 図 3: Transit Gateway を使用した Amazon EVS VPC から他のネットワークへの接続 図 3 に示すこのパターンは、Amazon EVS オーバーレイセグメントから複数の VPC、オンプレミス/外部ネットワーク、および他の AWS リージョンへの一貫性のあるスケーラブルな接続が必要な場合に使用します。 このパターンでは以下の点が重要です: 本稿の執筆時点 (2026/3) では、VPC ピアリングはサポートされていません。Amazon EVS VPC から他の VPC への接続には Transit Gateway や AWS Cloud WAN が必要です。 Transit VIF を使用した Direct Connect や AWS Site-to-Site VPN は、Amazon EVS アンダーレイ VPC ではなく、Transit Gateway / AWS Cloud WAN で終端する必要があります。Amazon EVS は Private VIF や VGW ベースの Site-to-Site VPN をサポートしていません。 NSX オーバーレイプレフィックスは BGP を通じて VPC ルートサーバーによって学習され、VPC ルートテーブルに伝播されますが、Transit Gateway と AWS Cloud WAN はこれらのルートを自動的にインポートしません。そのため、各 NSX オーバーレイ CIDR 範囲について、Amazon EVS VPC アタッチメントを指す静的ルートを Transit Gateway/AWS Cloud WAN ルートテーブルに追加する必要があります (図 3 参照)。AWS Cloud WAN の場合、これらの静的ルートはコアネットワークポリシーで設定します。 より多くの AWS リージョンに拡張する際は、モダンなポリシー駆動型のグローバルネットワークを提供するAWS Cloud WAN を検討してください。これにより、手動での Transit Gateway ピアリングが不要になり、AWS リージョンと VPC 間の動的ルーティングが可能になります。 パターン 2: AWS PrivateLink を使用した Amazon EVS から AWS および非 AWS サービスへのプライベート接続 図 4: Amazon EVS VPC から AWS および非 AWS サービスへのプライベート接続 NSX オーバーレイセグメント上のワークロードが、インターネットを経由することなく、AWS サービス ( Amazon Simple Storage Service (Amazon S3) や Amazon DynamoDB など)、お客様が管理するサービス、またはサードパーティ ISV サービスをプライベートに利用する必要があるパターンです。 インターフェースエンドポイント : AWS サービスへの接続には、インターフェース VPC エンドポイントを使用します。インターフェースエンドポイントは、Amazon EVS VPC 内の非 Amazon EVS サブネットに配置するか、 Transit Gateway / AWS Cloud WAN 経由でアクセス可能な別の共有サービス VPC に配置 します。Amazon EVS オーバーレイから T0 を通じてエンドポイントへトラフィックをルーティングします。2026/3 時点では、S3 ゲートウェイエンドポイントは Amazon EVS でサポートされていません。Amazon EVS ワークロードからの Amazon S3 アクセスには、インターフェースエンドポイントを使用する必要があります。 プライベート DNS : VPC DNS 属性を有効にする必要があります。プライベート DNS でインターフェースエンドポイントを使用する場合は、スプリットホライズン DNS シナリオに対して適切な Route 53 Resolver 転送ルールを設定します。 サービスネットワークエンドポイントとリソースエンドポイント : サービス間またはリソース接続でゼロトラストな接続に VPC Lattice を使用したい場合は、サービスネットワークエンドポイントまたはリソースエンドポイントを使用できます。Lattice サービスネットワークエンドポイントとリソースエンドポイントは、T0 を通じて VPC への NSX オーバーレイネットワークからアクセスできます。2026/3 時点では、Lattice サービスネットワーク関連付けは Amazon EVS でサポートされておらず、接続にはエンドポイントの使用が必要です。 ベストプラクティス: Amazon EVS 専用の VPC Amazon EVS VPC は Amazon EVS リソース専用とすることを検討してください。共有サービスやその他の Amazon EVS 以外のワークロードは、Transit Gateway または AWS Cloud WAN を通じて接続された VPC に配置します。このアプローチにより、より明確な障害範囲の境界、より良いコスト配分とチャージバック、コンプライアンスとセキュリティ監査が提供されます。 セキュリティポリシーの適用 Amazon EVS におけるセキュリティには多層防御アプローチが必要で、複数のレイヤーでポリシーを適用します。 NSX Distributed Firewall (DFW) vDefend の DFW は、ハイパーバイザーカーネル内の VM のネットワークインターフェースに直接適用される L2 – L7 ファイアウォール機能を提供します。また、DFW はマイクロセグメンテーションを可能にし、以下のような機能を持っています。 NSX 論理セグメント間の East-West トラフィック制御 タグベースの動的セキュリティグループ vDefend を通じた IDS/IPS 機能や、アプリケーション対応フィルタリングなどのその他のセキュリティ機能 現在の VCF NSX ライセンスオプションについては、Broadcom VMware アカウントチームにご相談ください。 AWS セキュリティコントロール AWS セキュリティグループは Amazon EVS VLAN サブネット上の Amazon EVS ENI には適用されません。ただし、セキュリティグループを使用して、インターフェースエンドポイントや Amazon EVS 以外のサブネット内の他のワークロードへのトラフィックを制御できます。 Amazon EVS VLAN サブネット上でアンダーレイのアクセス制御においては Network ACL (NACL) を使用して、DNS, SSH, オンプレミスへのハイブリッド接続用の Hybrid Cloud Extension (HCX), VPC ルートサーバーピアリング用の BGP などのプロトコルのトラフィックを許可することができます。 以下の用途で、VPC の Ingress / Egress ポイントに AWS Network Firewall またはパートナーファイアウォールソリューション ( Gateway Load Balancer 経由) の導入を検討してください。 North-South トラフィックの検査・制御 Amazon EVS 環境に出入りするトラフィックの IDS/IPS URL フィルタリング, 脅威インテリジェンス, コンプライアンス・監査ログなどのセキュリティ機能 モニタリング VPC Flow logs などの AWS モニタリングサービスは、Amazon EVS ENI のアンダーレイトラフィックのみを確認でき、NSX オーバーレイトラフィックは確認できません。オーバーレイのモニタリングは、Aria operations for Networks、NSX Traceflow などの VMware ツールを使用してください。 考慮事項 NSX トランスポート MTU 設定が Amazon EC2/VPC アンダーレイ機能と一致していることを確認してください。現世代の EC2 インスタンスは最大 9001 バイトのジャンボフレームをサポートし、Transit Gateway は最大 8500 バイト、Direct Connect は Transit VIF で最大 8500 バイトをサポートします。NSX 内の MTU 制限を考慮してください。 NSX Edge T0 ゲートウェイは、サイズが不十分な場合にスループットのボトルネックになる可能性があります。NSX Edge データパスメトリクスを監視し、Edge のサイジングとチューニングに関する VMware のパフォーマンスガイダンスに従ってください。 Amazon EVS では、同一アベイラビリティーゾーン内でのレジリエンシーのために 2 つの VPC ルートサーバーエンドポイントが必要です。2 つの NSX Edge T0 ノードは Active/Standby モードで動作し、各エッジは 1 つの VPC ルートサーバーエンドポイントとピアリングします。 アクティブな T0 エッジがすべての North-South トラフィックを処理します。フェイルオーバー時間を監視し、障害シナリオをテストして、アプリケーションが Edge ノードフェイルオーバーイベントに対応できることを確認してください。 Amazon EVS は IPv4 のみをサポートします。執筆時点 (2026/3) では IPv6 は利用できません。 Amazon EVS は、ピアの生存確認にデフォルトの BGP キープアライブメカニズムをサポートします。Multi-hop Bidirectional Forwarding Detection (BFD) はサポートされていません。 作成時、VLAN サブネットは VPC のメインルートテーブルに暗黙的に関連付けられます。デプロイ後、Amazon EVS VLAN サブネットをカスタムルートテーブルに明示的に関連付けることができます。NSX 接続用にカスタムルートテーブルを作成することをお勧めします。 セキュリティグループは Amazon EVS ENI には適用されません。アンダーレイのアクセス制御には NACL を使用してください。Amazon EVS ワークロードにステートフルなセキュリティポリシーを提供するために、より多くの NSX セキュリティオプションを検討してください。 本稿の情報は、今後の Amazon EVS サービスのアップデートにより変更される可能性があります。 まとめ Amazon Elastic VMware Service (Amazon EVS) は、VMware Cloud Foundation スタックを VPC 内に直接配置し、AWS での VMware テクノロジーの制御と柔軟性を提供します。デプロイメントを成功させるには、事前に十分な計画を立て、適切なルーティングパターンを選択し、適切なレイヤーでセキュリティを実装してください。これらの原則に従うことで、VMware ワークロードを AWS インフラストラクチャ上で実行し、確立されたネットワーク、セキュリティ、運用パターンを適用し、モダナイゼーションとイノベーションのための幅広い AWS サービスを活用することができます。 著者について Victor Babasanmi Victor は AWS のシニアネットワークスペシャリストソリューションアーキテクトです。彼はベストプラクティスを使用したソリューションの計画と構築に関する技術的なガイダンスをお客様に提供し, AWS 環境を運用面で健全に保つことに積極的に取り組んでいます。仕事以外では、サッカーやワークアウト、新しいことに取り組んでいます。 Craig Herring Craig Herring は AWS でシニアスペシャリストソリューションアーキテクトを務めており、インフラストラクチャの移行とモダナイゼーションを専門としています。2021 年に入社して以来、Craig は 35 年にわたる豊富な業界経験を活かして、お客様が AWS ソリューションへの移行とその効果の最大化を支援しています。仕事以外では、Craig は妻の Lindy と 8 人の子供と 3 人の大家族との時間を大切にしています。個人的な興味は友人との交流、ドライブ、アクティブなライフスタイルの維持、オーディオ機器の製作など多岐にわたります。 翻訳はソリューションアーキテクト齋藤が担当しました。原文は こちら です。

本稿は、2025 年 11 月 19 日に AWS Machine Learning Blog で公開された “ Claude Code deployment patterns and best practices with Amazon Bedrock ” を翻訳したものです。 Claude Code は、Anthropic が提供する AI 駆動のコーディングアシスタントで、自然言語による対話を通じて開発者がコードの作成、レビュー、修正を行うのを支援します。 Amazon Bedrock は、主要な AI 企業の基盤モデルに単一の API からアクセスできるフルマネージドサービスです。本記事では、 Claude Code を Amazon Bedrock でデプロイする方法を解説します。認証方式、インフラの選択、モニタリング戦略など、エンタープライズ規模で安全にデプロイするためのノウハウを紹介します。 ほとんどの企業への推奨事項 guidance-for-claude-code-with-amazon-bedrock の利用を推奨します。これは数時間以内にデプロイ可能な実績あるパターンです。 推奨されるスタック構成 認証： AWS IAM フェデレーションを使用した直接の IdP 統合 インフラストラクチャ： 専用 AWS アカウント と Amazon Bedrock のパブリックエンドポイント モニタリング： OpenTelemetry 、 CloudWatch ダッシュボード 、 分析 このアーキテクチャは、ユーザー属性の特定、キャパシティ管理、コストおよび開発者の生産性の可視性を備えた安全なアクセスを提供します。 認証方法 Claude Code のデプロイは、Amazon Bedrock への認証から始まります。認証方法の選択は、セキュリティ、モニタリング、運用、および開発者体験に影響を与えます。 認証方式の比較 機能 Amazon Bedrock API キー　　　　　 aws login IAM Identity Center による SSO 直接の IdP 統合　　　　 セッション期間 無期限 設定可能 （最大12時間） 設定可能 （最大12時間） 設定可能 （最大12時間） セットアップ時間 数分 数分 数時間 数時間 セキュリティリスク 高 低 低 低 ユーザー属性特定 なし 基本的 基本的 完全 MFA サポート なし あり あり あり OpenTelemetry 統合 なし 限定的 限定的 完全 コスト配分 なし 限定的 限定的 完全 運用オーバーヘッド 高 中 中 低 ユースケース 短期テスト テストと限定的なデプロイ 迅速な SSO デプロイ 本番環境デプロイ 以下では、上記の表に示されたトレードオフと実装上の考慮事項について説明します。 Amazon Bedrock API キー Amazon Bedrock は、概念実証（PoC）への最短パスとして API キー をサポートしています。短期（12 時間）および長期（1 日から 1 年、または無期限）の両方のキーを、 AWS Management Console 、 AWS CLI 、または SDK を通じて生成できます。 ただし、API キーは、MFA なしの永続的なアクセス、手動配布の必要性、リポジトリへの誤コミットのリスクなどによりセキュリティの脆弱性を生み出します。コスト配分やモニタリングのためのユーザー特定もできません。Amazon Bedrock の API Key は検証時のご利用を推奨します。 コンソール認証 (aws login) aws login コマンド は、 ブラウザベースの認証フロー を通じてAWS Management Console の認証情報を Amazon Bedrock へのアクセスに使用します。API キーなしで迅速なセットアップをサポートし、テストや小規模なデプロイに推奨されています。 シングルサインオン (IAM Identity Center による SSO) AWS IAM Identity Center は、 OpenID Connect （OIDC）を通じてエンタープライズ ID プロバイダーと統合します。OIDC は、ID プロバイダーがユーザー ID を検証し、アプリケーションと認証情報を共有できるようにする認証プロトコルで、シングルサインオンを可能にします。この統合により、開発者は API キーを配布することなく、企業の認証情報を使用して Amazon Bedrock にアクセスできます。 開発者は aws sso login コマンドを使用して AWS IAM Identity Center で認証を行い、セッション期間を設定可能な一時認証情報を取得します。この認証情報は自動更新されるため、認証情報管理の運用負荷を軽減しつつ、一時的なアクセス権限によってセキュリティを向上させます。 aws sso login --profile=your-profile-name export CLAUDE_CODE_USE_BEDROCK=1 export AWS_PROFILE=your-profile-name AWS アクセスに IAM Identity Center を使用している組織は、このパターンを Claude Code にも拡張できます。ただし、OpenTelemetry の属性抽出のための OIDC JWT トークンを公開していないため、詳細なユーザーレベルのモニタリングは制限されます。 この認証方法は、詳細なモニタリングよりも迅速な SSO デプロイを優先する組織や、包括的なメトリクスがまだ必要とされない初期展開に適しています。 ID プロバイダーとの連携ソリューション ( 直接の IdP 統合 ) 本番環境での Claude Code デプロイメントには、ID プロバイダー（Okta、Azure AD、Auth0、または AWS Cognito User Pools ）との直接的な OIDC 連携を推奨します。 guidance-for-claude-code-with-amazon-bedrock というソリューションでは、企業の ID プロバイダーを AWS IAM と直接連携し、モニタリングのためのユーザーコンテキストを含む一時的な認証情報を生成します。 ソリューションの詳細を一部紹介すると、 プロセス認証情報プロバイダー は、認可コードの傍受を防ぐセキュリティ拡張機能である PKCE を利用した OAuth 2.0 のフローをオーケストレーションします。開発者はブラウザで認証を行い、OIDC トークンを AWS の一時的な認証情報と交換します。ヘルパースクリプトは AWS Security Token Service （STS）のの AssumeRoleWithWebIdentity を使用して、Amazon Bedrock を利用するための InvokeModel と InvokeModelWithStreaming の認証情報を持つロールを引き受けます。直接の IAM フェデレーションは最大 12 時間のセッション期間をサポートし、JWT トークンはセッション全体を通じてアクセス可能なままであるため、OpenTelemetry を通じたモニタリングによってメールアドレス、部署、チームなどのユーザー属性を追跡できます。 本ソリューションでは、Cognito Identity Pool と 直接の IAM フェデレーションの両方のパターンを実装していますが、シンプルさの観点から直接の IAM フェデレーションを推奨しています。このソリューションは、OIDC プロバイダーの統合設定、必要な IAM インフラストラクチャのデプロイ、Windows、macOS、Linux 用の配布パッケージをビルドする対話型セットアップウィザードを提供します。 開発者は、認証情報プロセスを使用するように AWS CLI プロファイルを設定するインストールパッケージを受け取ります。認証は企業の認証情報を通じて行われ、認証情報を更新するためにブラウザが自動的に開きます。認証プロセスはトークンのキャッシュ、認証情報の更新、およびエラーリカバリを処理します。 詳細な使用状況のモニタリング、開発者ごとのコスト配分、および包括的な監査証跡を必要とする組織にとって、IAM フェデレーションを通じた直接の IdP 統合は、後述する高度なモニタリング機能の基盤となります。 導入時の検討事項 認証以外にも、アーキテクチャの決定が Claude Code の AWS インフラストラクチャとの統合方法を形成します。これらの選択は、運用の複雑さ、コスト管理、使用ポリシーの実施に影響します。 パブリックエンドポイント Amazon Bedrock は、最小限の運用オーバーヘッドで利用可能な、管理された パブリック API エンドポイント を複数の AWS リージョンで提供しています。インフラ、スケーリング、可用性、セキュリティパッチはAWSが管理します。開発者は AWS CLI プロファイルまたは環境変数を通じて標準的な AWS 認証情報を使用します。直接の IdP 統合による OpenTelemetry メトリクスと組み合わせることで、パブリックエンドポイントを通じて個々の開発者、部門、またはコストセンターごとに使用状況を追跡でき、AWS IAM レベルで制御できます。例えば、開発者ごとのレート制限を実装するには、CloudWatch メトリクスや CloudTrail ログを監視し、自動的にアクションを実行するインフラストラクチャが必要です。カスタムビジネスロジックに基づいてリクエストレベルで即座にブロックする必要がある組織では、LLM（大規模言語モデル）ゲートウェイパターンなどの追加コンポーネントが必要になる場合があります。Amazon Bedrock のパブリックエンドポイントは、シンプルさ、AWS マネージドの信頼性、コストアラート、適切な制御メカニズムのバランスを提供するため、ほとんどの組織にとって十分です。 LLM ゲートウェイ LLM ゲートウェイは、開発者と Amazon Bedrock の間に中間アプリケーション層を導入し、カスタムインフラを通じてリクエストをルーティングします。 Guidance for Multi-Provider Generative AI Gateway on AWS では、このパターンを説明しており、ロードバランシングと一元化された認証情報管理を備えたコンテナ化されたプロキシサービスをデプロイします。 このアーキテクチャは以下の場合に最適です。 マルチプロバイダーサポート ：可用性、コスト、または機能に基づいて Amazon Bedrock、OpenAI、Azure OpenAI 間でルーティングする場合 カスタムミドルウェア ：リクエストレベルでの独自のプロンプトエンジニアリング、コンテンツフィルタリング、またはプロンプトインジェクション検知を行う場合 リクエストレベルのポリシー適用 ：IAM の機能を超えたカスタムビジネスロジックに基づいて、リクエストを即座にブロックする場合 ゲートウェイは統一された API とリアルタイム追跡を提供しますが、運用オーバーヘッドが追加されます。 Amazon Elastic Container Service (Amazon ECS) / Amazon Elastic Kubernetes Service (Amazon EKS) インフラストラクチャ、 Elastic Load Balancing (ELB) Application Load Balancer 、 Amazon ElastiCache 、 Amazon Relational Database Service (Amazon RDS) の管理、レイテンシーの増加、そしてゲートウェイの問題が Claude Code の使用をブロックする新たな障害点が発生します。LLM ゲートウェイは、LLM にプログラム的に呼び出しを行うアプリケーションにおいて、一元的なモニタリング、ユーザーごとの可視性、統一されたアクセス制御を提供するのに優れています。 従来の API アクセスシナリオでは、組織はモニタリングとユーザー帰属の機能を得るためにゲートウェイをデプロイできます。しかし、Claude Code ガイダンスソリューションには、直接の IdP 認証、OpenTelemetry メトリクス、IAM ポリシー、CloudWatch ダッシュボードを通じたモニタリングと属性特定機能が既に含まれています。ガイダンスソリューションに LLM ゲートウェイを追加すると、既存の機能と重複します。マルチプロバイダーサポート、カスタムミドルウェア、または IAM を超えたリクエストレベルのポリシー制御が必要な場合にのみ、ゲートウェイの使用を検討してください。 専用 AWS アカウント実装 コーディングアシスタントの推論は、開発環境や本番環境のワークロードとは別の単一の専用アカウントに集約することを推奨します。このアプローチには 5 つの主要なメリットがあります。 運用の簡素化：  複数のアカウントにわたって追跡する代わりに、統合されたダッシュボードを通じてクォータを管理し、使用状況をモニタリングできます。クォータの引き上げ要求はアカウントごとではなく一度で済みます。 明確なコスト可視性：   AWS Cost Explorer と コストと使用状況レポート は、複雑なタグ付けなしで Claude Code の料金を直接表示します。OpenTelemetry メトリクスにより、部門やチームレベルの配分が可能になります。 一元化されたセキュリティ： CloudTrail ログはモニタリングとコンプライアンスのために一箇所に集約されます。モニタリングスタックを一度デプロイするだけで、開発者からのメトリクスを収集できます。 本番環境の保護： アカウントレベルの分離により、Claude Code の使用がクォータを使い果たし、本番アプリケーションのスロットリングを引き起こすことを防ぎます。また、本番トラフィックの急増が開発者の生産性に影響を与えません。 実装： クロスアカウントでの IAM 設定により、開発者は制限されたロールにフェデレーションする ID プロバイダーを通じて認証を行い、適切なガードレールを備えたモデル呼び出し権限のみを付与されます。 この戦略は、直接の IdP 認証と OpenTelemetry モニタリングと統合されています。ID プロバイダーは認証を処理し、専用アカウントが推論を処理し、開発アカウントはアプリケーションに集中します。 推論プロファイル Amazon Bedrock 推論プロファイル はリソースへのタグ付けを通じてコスト追跡を提供しますが、開発者ごとの粒度にはスケールしません。コスト配分のためのアプリケーションプロファイルを作成できますが、1000 人以上の個々の開発者のプロファイル管理は運用上の負担となります。推論プロファイルは、10 〜 50 程度の個別のチームで隔離されたコスト追跡を必要とする組織や、マネージドに AWS リージョン間でリクエストを分散するクロスリージョン推論を使用する場合に最適です。包括的なモニタリングよりも、基本的なコスト配分を必要とするシナリオに理想的です。 システム定義のクロスリージョン推論プロファイルは、複数の AWS リージョン間でリクエストを自動的にルーティングし、より高いスループットと可用性のために負荷を分散します。クロスリージョンプロファイル（例： us.anthropic.claude-sonnet-4 ）を呼び出すと、Amazon Bedrock はリクエストを処理するために利用可能なリージョンを選択します。 アプリケーション推論プロファイルは、アカウントで明示的に作成するプロファイルであり、通常はシステム定義のプロファイルやリージョン内の特定のモデルをラップしたものです。アプリケーションプロファイルには team:data-science や project:fraud-detection といったカスタムキーバリューペアをタグ付けでき、これらはコスト配分分析のために AWS コストと使用状況レポートに反映されます。アプリケーションプロファイルを作成するには、以下のコマンドを実行します。 aws bedrock create-inference-profile \ --inference-profile-name team-data-science \ --model-source arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-sonnet-4 \ --tags team=data-science costcenter=engineering タグはコストと使用状況レポートに表示されるため、次のようなクエリが可能です。 "What did the data-science team spend on Amazon Bedrock last month?" 各プロファイルは API 呼び出しで明示的に参照する必要があり、開発者の認証情報設定は共有エンドポイントではなく、独自のプロファイルを指定する必要があります。 推論プロファイルの詳細については、 Amazon Bedrock 推論プロファイルのドキュメント をご覧ください。 モニタリング 効果的なモニタリング戦略は、使用状況、コスト、影響を追跡することで、Claude Code を単なる生産性ツールから測定可能な投資へと変革します。 段階的な拡張パス モニタリングのレイヤーは補完的なものです。組織は通常、基本的な可視性から始め、ROI の要件が追加のインフラストラクチャを正当化するにつれて機能を追加していきます。 各レベルと、それがデプロイに適している状況を見ていきましょう。 注意： インフラコストは段階的に増加します。各レベルは前のレイヤーを維持しながら新しいコンポーネントを追加します。 CloudWatch Amazon Bedrock は自動的にメトリクスを Amazon CloudWatch に発行し、呼び出し回数、スロットリングエラー、レイテンシーを追跡します。CloudWatch グラフは、リクエスト総数、平均レイテンシー、クォータ使用率などの集計傾向を最小限のデプロイ作業で表示します。このベースラインモニタリングは CloudWatch の標準料金に含まれています。呼び出しレートが急増したり、エラー率が閾値を超えたり、レイテンシが悪化したりしたときに通知する CloudWatch アラームを作成できます。 呼び出しログ記録 Amazon Bedrock 呼び出しログ記録は、各 API 呼び出しに関する詳細情報を Amazon S3 または CloudWatch Logs にキャプチャし、呼び出しメタデータと完全なリクエスト / レスポンスデータを含む個々のリクエストレコードを保存します。 Amazon Athena でログを処理したり、データウェアハウスにロードしたり、カスタムツールで分析したりできます。ログには使用パターン、モデルごとの呼び出し、ピーク時の利用状況、および Amazon Bedrock アクセスの監査証跡が表示されます。 OpenTelemetry Claude Code は、アプリケーションテレメトリデータを収集するためのオープンソースオブザーバビリティフレームワークである OpenTelemetry をサポート しています。OpenTelemetry コレクターエンドポイントを設定すると、Claude Code は Amazon Bedrock API 呼び出しと、より高レベルの開発アクティビティの両方について、詳細なメトリクスを出力します。 テレメトリは、Amazon Bedrock のデフォルトログに含まれていない詳細なコードレベルのメトリクスをキャプチャします。これには、追加 / 削除されたコード行数、修正されたファイル、使用されたプログラミング言語、Claude の提案に対する開発者の受け入れ率などが含まれます。また、ファイル編集、コード検索、ドキュメントリクエスト、リファクタリングタスクなどの主な操作も追跡します。 ガイダンスソリューション は Amazon ECS Fargate 上に OpenTelemetry インフラストラクチャをデプロイします。Application Load Balancer が HTTP(S) 経由でテレメトリを受信し、OpenTelemetry コレクターにメトリクスを転送します。コレクターは Amazon CloudWatch と Amazon S3 にデータをエクスポートします。 ダッシュボード ガイダンスソリューション には、主要メトリクスを継続的に表示する CloudWatch ダッシュボードが含まれており、時間、日、週ごとのアクティブユーザーを追跡して、ユーザーごとのコスト計算を可能にする採用と使用の傾向を明らかにします。トークン消費は入力、出力、キャッシュされたトークンに分類され、高いキャッシュヒット率は効率的なコンテキスト再利用を示し、ユーザーごとのビューはヘビーユーザーを特定します。コードアクティビティメトリクスは、追加および削除された行を追跡し、トークン使用量と相関させて効率性と使用パターンを示します。 操作の内訳にはファイルの編集、コード検索、ドキュメントリクエストの分布が表示され、ユーザーリーダーボードにはトークン、コード行数、またはセッション時間ごとのトップ消費者が表示されます。 ダッシュボードはほぼリアルタイムで更新され、メトリクスがしきい値を超えたときに通知をトリガーする CloudWatch アラームと統合されています。ガイダンスソリューションは、複雑な集計のためのカスタム Lambda 関数を備えた CloudFormation を通じてデプロイされます。 分析 ダッシュボードはリアルタイムモニタリングに優れていますが、長期的なトレンドと複雑なユーザー行動分析には分析ツールが必要です。 ガイダンスソリューション のオプションの分析スタックは、 Amazon Data Firehose を使用してメトリクスを Amazon S3 にストリーミングします。 AWS Glue Data Catalog がスキーマを定義し、Amazon Athena を通じてデータをクエリ可能にします。 分析レイヤーは、部門別の月間トークン消費量、プログラミング言語ごとのコード受け入れ率、チーム間のトークン効率のばらつきなどのクエリをサポートします。コスト分析は、トークンメトリクスと Amazon Bedrock の価格を結合してユーザーごとの正確なコストを計算し、部門レベルの課金配賦用に集計することで、コスト分析が高度になります。時系列分析は、予算予測のためにチームの成長に伴うコストの拡大を示します。SQL インターフェイスはビジネスインテリジェンスツールと統合でき、スプレッドシート、機械学習モデル、またはプロジェクト管理システムへのエクスポートを可能にします。 例えば、部署ごとの月次コスト分析を確認するには、以下のようなクエリを使用します。 SELECT department, SUM(input_tokens) * 0.003 / 1000 as input_cost, SUM(output_tokens) * 0.015 / 1000 as output_cost, COUNT(DISTINCT user_email) as active_users FROM claude_code_metrics WHERE year = 2024 AND month = 1 GROUP BY department ORDER BY (input_cost + output_cost) DESC; このインフラストラクチャには、追加コストが発生します。Data Firehose はデータ取り込み、S3 はデータ保存、Athena はスキャンデータのクエリごとにそれぞれ課金されます。 履歴分析、複雑なクエリ、またはビジネスインテリジェンスツールとの統合が必要な場合は分析を有効にしてください。小規模な導入や、主にリアルタイム監視に重点を置く組織であればダッシュボードだけで十分な場合もありますが、Claude Code に本格的な投資を行う企業は、分析レイヤーを実装すべきです。これにより、投資対効果 (ROI) を実証し、長期的に利用を最適化するために必要な可視性が得られます。 クォータ ガイダンスソリューションのクォータを利用すると、個々の開発者やチームに使用制限を設定し、組織としてトークン消費を制御・管理できます。クォータを実装する前に、まずはモニタリングを有効にして、通常の使用パターンを理解することを推奨します。使用状況データからは通常、トークン消費量が多いほど生産性が高くなる傾向があり、ヘビーユーザーがそれに見合った価値を提供していることを示唆しています。 クォータシステムは、以下のような形式で制限値を DynamoDB に保存します。 { "userId": "jane@example.com", "monthlyLimit": 1000000, "currentUsage": 750000, "resetDate": "2025-02-01" } CloudWatch Events によってトリガーされる Lambda 関数が 15 分ごとにトークン消費を集計し、DynamoDB を更新するとともに、しきい値を超えた場合に SNS へ通知を発行します。 モニタリング比較 以下の表は、各モニタリング手法におけるトレードオフをまとめたものです。 機能 CloudWatch 呼び出しログ記録 OpenTelemetry ダッシュボードと分析 セットアップの複雑さ なし 低 中 中 ユーザー属性 なし IAM Identity 完全 完全 リアルタイムメトリクス あり なし あり あり コードレベルのメトリクス なし なし あり あり 履歴分析 限定的 あり あり あり コスト配分 アカウントレベル アカウントレベル ユーザー、チーム、部門 ユーザー、チーム、部門 トークン追跡 集計値のみ リクエストごと ユーザーごと トレンドを含むユーザーごと クォータ適用 手動 手動 可能 可能 運用オーバーヘッド 最小 低 中 中 コスト 最小 低 中 中 ユースケース POC 基本的な監査 本番環境 ROI を重視する企業 実装のまとめ このセクションでは、認証方法、組織アーキテクチャ、およびモニタリング戦略を推奨されるデプロイパターンに統合し、デプロイの成熟度に合わせた実装の優先順位についてのガイダンスを提供します。このアーキテクチャは、セキュリティ、運用のシンプルさ、そして包括的な可視性のバランスをとっています。開発者は企業の認証情報で 1 日 1 回認証を行い、管理者はダッシュボードでリアルタイムの使用状況を確認し、セキュリティチームは CloudTrail の監査ログと OpenTelemetry を通じた包括的なユーザー属性付きメトリクスを取得します。 実装パス このガイダンスソリューションは、インタラクティブなセットアッププロセスを通じて迅速なデプロイをサポートしており、数時間以内に認証とモニタリングを稼働させることができます。まずはパイロットグループにフルスタックをデプロイし、実際の使用データを収集してから、検証されたパターンに基づいて拡大してください。 デプロイ – Guidance for Claude Code with Amazon Bedrock リポジトリをクローンし、対話型の poetry run ccwb init ウィザードを実行します。このウィザードは ID プロバイダー、フェデレーションタイプ、AWS リージョン、およびオプションのモニタリングを設定します。CloudFormation スタックをデプロイし（通常 15 〜 30 分）、配布パッケージをビルドして、ユーザーに配布する前にローカルで認証をテストします。 配布 – 異なるチームから 5 〜 20 人の開発者をパイロットグループとして選定します。このグループが認証、モニタリングを検証し、本格展開の計画に必要な使用データを提供します。モニタリングを有効にしている場合、CloudWatch ダッシュボードにアクティビティが即座に表示されます。トークン消費量、コード採用率、操作タイプを監視することで、必要なキャパシティ要件の見積もり、トレーニングニーズの特定、より広範な展開に向けた価値の実証を行うことができます。 拡大 –  Claude Code の検証が完了したら、チームまたは部門単位で採用を拡大します。履歴トレンド分析のために分析スタックを追加（通常 1 〜 2 時間）し、採用率、高パフォーマンスなチーム、およびコスト予測を確認します。 最適化 – 開発リーダーシップとの定期的なレビューサイクルを通じて、監視データを継続的な改善に活用します。監視データは、価値の実証、トレーニングニーズの特定、キャパシティ調整のガイドに役立ちます。 推奨パターンから逸脱する場合 上記のアーキテクチャは多くのエンタープライズ展開に適していますが、特定の状況下では異なるアプローチが正当化される場合があります。 LLM ゲートウェイの検討 – Amazon Bedrock 以外の複数の LLM プロバイダーが必要な場合、プロンプト処理やレスポンスフィルタリング用のカスタムミドルウェアが必要な場合、またはAWS IAM 機能を超えたリクエストレベルのポリシー適用を必要とする規制環境で運用している場合。 推論プロファイルの検討 – 個別のコスト追跡を必要とするチームが 50 未満であり、テレメトリメトリクスよりも AWS ネイティブの請求配分を好む場合。推論プロファイルはプロジェクトベースのコスト配分には適していますが、開発者ごとの追跡にはスケールしません。 モニタリングなしでの開始を検討 – 10 人未満の開発者による期間限定のパイロット運用で、基本的な CloudWatch メトリクスで十分な場合。スケールさせる前にモニタリングを追加することを計画してください。後からの追加には開発者へのパッケージの再配布が必要になるためです。 API キーの検討 – セキュリティリスクが許容される期間を限定したテスト（1 週間未満）の場合のみ。 結論 Amazon Bedrock で Claude Code をエンタープライズ規模でデプロイするには、認証、アーキテクチャ、およびモニタリングについて慎重な判断が必要です。本番環境に対応したデプロイは明確なパターンに従います。直接の IdP 統合により、ユーザー属性が紐づいた安全なアクセスを提供し、専用の AWS アカウントによりキャパシティ管理を簡素化します。そして OpenTelemetry による監視が、コストと開発者の生産性に対する可視性を提供します。 guidance-for-claude-code-with-amazon-bedrock は、これらのパターンをデプロイ可能なソリューションとして実装しています。まずは認証と基本的なモニタリングから始め、スケールに合わせて機能を追加していってください。 AI 駆動の開発ツールが業界標準になるにつれて、デプロイメントにおいてセキュリティ、モニタリング、運用の優秀さを優先する組織は持続的な優位性を得ることになります。このガイドは、企業全体で Claude Code の可能性を最大化するための包括的なフレームワークを提供します。 開始するには、 guidance-for-claude-code-with-amazon-bedrock  リポジトリにアクセスしてください。 著者について Court Schuett ：プリンシパル・スペシャリスト・ソリューションアーキテクト – GenAI として、AI コーディングアシスタントを活用して他の人々がそれらを最大限に活用できるよう支援する業務に従事しています。仕事以外では、旅行、音楽鑑賞、木工を楽しんでいます。 Jawhny Cooke ：AWSにおける Anthropic の Claude Code のグローバルテックリードであり、エンタープライズがエージェンティックコーディングを大規模に運用するのを支援する専門家です。彼は顧客やパートナーと協力して、自律的コーディングワークフローの設計からマルチエージェントシステムのオーケストレーション、AWS インフラでの運用最適化まで、AI 支援開発の複雑な本番課題を解決しています。彼の仕事は最先端の AI 機能とエンタープライズグレードの信頼性を橋渡しし、組織が本番環境で Claude Code を自信を持って採用できるよう支援しています。 Karan Lakhwani ：Amazon Web Services のシニアカスタマーソリューションマネージャーです。生成 AI テクノロジーを専門とし、AWS Golden Jacket 受賞者でもあります。仕事以外では、新しいレストランの開拓やスキーを楽しんでいます。 Gabe Levy ：ニューヨークを拠点とする AWS のアソシエイトデリバリーコンサルタントで、主にクラウドでのアプリケーション開発に焦点を当てています。Gabe は人工知能と機械学習の副専門を持っています。AWS の顧客との仕事以外では、運動、読書、家族や友人との時間を楽しんでいます。 Gabriel Velazquez Lopez ：AWS の GenAI プロダクトリーダーであり、Anthropic とのパートナーシップで AWS 上 のClaude の戦略、市場投入、製品ローンチを主導しています。 翻訳者について 山澤 良介 ：ソリューションアーキテクトとして、業種業態を問わず様々なお客様を支援させて頂いています。前職では主にネットワーク案件を担当していました。好きなサービスは、Amazon Bedrock と AWS Transit Gateway です。休日はスノーボードが大好きなので、シーズン中は毎週スキー場に行っております。

re:Invent 2025 において、AWS の Vice President of Databases である Colin Lazier は、アイデアのスピードで構築することの重要性を強調しました。これは、コンセプトから稼働中のアプリケーションまでの道のりを迅速に進めることを可能にするものです。お客様は既に、本番対応の Amazon DynamoDB テーブルと Amazon Aurora DSQL データベースを数秒で作成できます。Colin は、同じスピードで Amazon Aurora サーバーレス データベースを作成できることを 事前公開 し、その後、お客様からこの機能への迅速なアクセスとスピードを求める声が寄せられました。 2025 年 3 月 25 日、Amazon Aurora PostgreSQL 向けの新しいエクスプレス設定の一般提供の開始をお知らせします。これは、数秒で使用を開始するのに役立つよう設計された事前設定済みのデフォルト設定を備えた、合理化されたデータベース作成エクスペリエンスです。 わずか 2 回クリックするだけで、Aurora PostgreSQL サーバーレスデータベースを使用する準備が数秒で整います。新しい設定では、データベースの作成中および作成後に、特定の設定を柔軟に変更できます。例えば、作成時にサーバーレスインスタンスのキャパシティ範囲を変更したり、リードレプリカを追加したり、データベースが作成された後にパラメータグループを変更したりできます。 エクスプレス設定を備えた Aurora クラスターは、 Amazon Virtual Private Cloud (Amazon VPC) ネットワークなしで作成され、お気に入りの開発ツールからのセキュアな接続のためのインターネットアクセスゲートウェイを含みます。VPN や AWS Direct Connect は不要です。また、エクスプレス設定では、管理者ユーザーのために AWS Identity and Access Management (IAM) 認証がデフォルトでセットアップされるため、追加設定なしで最初からパスワードレスデータベース認証が有効になります。 作成後、高可用性や自動フェイルオーバー機能のための追加のリードレプリカのデプロイなど、Aurora PostgreSQL サーバーレスで使用可能な機能にアクセスできます。今回のリリースでは、Aurora 向けの新しいインターネットアクセスゲートウェイルーティングレイヤーも導入されました。新しいサーバーレスインスタンスでは、この機能はデフォルトで有効になっています。これにより、幅広い開発ツールから PostgreSQL ワイヤプロトコルを使用して、世界中のどこからでも、アプリケーションがインターネット経由でセキュアに接続できます。このゲートウェイは複数のアベイラビリティゾーンに分散されており、Aurora クラスターと同等の高可用性を提供します。 Aurora の作成と接続が数秒で完了するということは、Aurora の利用を開始する方法は根本的に変わります。弊社は、Aurora を利用したアプリケーションのオンボーディングと実行をサポートするために、連携して動作する複数の機能をリリースしました。Aurora は AWS 無料利用枠 で現在利用可能です。これにより、初期費用なしで Aurora を実際に体験できます。作成後、 AWS CloudShell で Aurora データベースを直接クエリしたり、Aurora 用の新しいインターネットアクセス可能なルーティングコンポーネントを介してプログラミング言語やデベロッパーツールを使用したりできます。 Vercel の v0 などの統合により、自然言語を使用して、Aurora の機能とメリットを活用したアプリケーションの構築を開始できます。 Aurora PostgreSQL サーバーレスデータベースを数秒で作成 利用を開始するには、 Aurora および RDS コンソール にアクセスし、ナビゲーションペインで [ダッシュボード] を選択します。その後、ロケットアイコンの付いた [作成] を選択します。 [エクスプレス設定で作成] ダイアログボックスで、事前構成済みの設定を確認します。必要に応じて、DB クラスター識別子またはキャパシティ範囲を変更できます。 [データベースを作成] を選択します。 また、パラメータ --express-configuration を設定して AWS コマンドラインインターフェイス (AWS CLI) または AWS SDK を使用することで、単一の API コールでクラスターとクラスター内のインスタンスの両方を作成できます。これにより、数秒でクエリを実行できる状態になります。詳細については、「 Creating an Aurora PostgreSQL DB cluster with express configuration 」にアクセスしてください。 クラスターを作成するための CLI コマンドを次に示します: $ aws rds create-db-cluster --db-cluster-identifier channy-express-db \ --engine aurora-postgresql \ –with-express-configuration Aurora PostgreSQL サーバーレスデータベースは数秒で準備完了となります。作成が完了すると成功バナーが表示され、データベースのステータスが [使用可能] に変わります。 データベースの準備が完了したら、 [接続とセキュリティ] タブに移動して、3 つの接続オプションにアクセスします。SDK、API、またはエージェントなどのサードパーティーツール経由で接続する場合は、 [コードスニペット] を選択します。.NET、Golang、JDBC、Node.js、PHP、PSQL、Python、TypeScript など、さまざまなプログラミング言語を選択できます。各ステップのコードをツールに貼り付けてコマンドを実行できます。 例えば、次の Python コードは認証設定を反映するために動的に生成されます: import psycopg2 import boto3 auth_token = boto3.client('rds', region_name='ap-south-1').generate_db_auth_token(DBHostname='channy-express-db-instance-1.abcdef.ap-south-1.rds.amazonaws.com', Port=5432, DBUsername='postgres', Region='ap-south-1') conn = None try: conn = psycopg2.connect( host='channy-express-db-instance-1.abcdef.ap-south-1.rds.amazonaws.com', port=5432, database='postgres', user='postgres', password=auth_token, sslmode='require' ) cur = conn.cursor() cur.execute('SELECT version();') print(cur.fetchone()[0]) cur.close() except Exception as e: print(f"Database error: {e}") raise finally: if conn: conn.close() const { Client } = require('pg'); const AWS = require('aws-sdk'); AWS.config.update({ region: 'ap-south-1' }); async function main() { let password = ''; const signer = new AWS.RDS.Signer({ region: 'ap-south-1', hostname: 'channy-express-db-instance-1.abcdef.ap-south-1.rds.amazonaws.com', port: 5432, username: 'postgres' }); password = signer.getAuthToken({}); const client = new Client({ host: 'channy-express-db-instance-1.abcdef.ap-south-1.rds.amazonaws.com', port: 5432, database: 'postgres', user: 'postgres', password, ssl: { rejectUnauthorized: false } }); try { await client.connect(); const res = await client.query('SELECT version()'); console.log(res.rows[0].version); } catch (error) { console.error('Database error:', error); throw error; } finally { await client.end(); } } main().catch(console.error); コンソールから直接起動する AWS CLI に迅速にアクセスするには、 [CloudShell] を選択します。[ CloudShell を起動] を選択すると、特定のクラスターに接続するための関連情報がコマンドに事前に入力されていることが確認できます。シェルに接続すると、SQL コマンドを実行するための psql login と postgres => prompt が表示されます。 pgAdmin など、ユーザー名とパスワードの認証情報のみをサポートするツールを使用する場合は、 [エンドポイント] を選択することもできます。 [トークンを取得] を選択すると、ユーティリティによって生成された AWS Identity and Access Management (IAM) 認証トークンがパスワードフィールドに使用されます。このトークンは、データベースの作成時にセットアップするマスターユーザー名について生成されます。トークンは 1 回につき 15 分間有効です。使用しているツールが接続を終了した場合、トークンを再生成する必要があります。 Aurora データベースを利用してアプリケーションをより迅速に構築 re:Invent 2025 では、 AWS 無料利用枠プログラムの強化を発表し 、AWS サービス全体で使用できる最大 200 USD 相当の AWS クレジットを提供しました。サインアップ時に 100 USD 相当の AWS クレジットが付与され、Amazon Relational Database Service (Amazon RDS)、AWS Lambda、Amazon Bedrock などのサービスを利用することで、さらに 100 USD 相当のクレジットを獲得できます。さらに、Amazon Aurora は、対象となる一連の幅広い 無料利用枠データベースサービス でご利用いただけるようになりました。 デベロッパーは、自然言語だけで本番対応のアプリケーションを構築できる Vercel などのプラットフォームを採用しています。弊社は、 Vercel Marketplace との統合を発表しました 。これにより、Vercel から AWS データベースを数秒で直接作成して接続できるようになります。また、AI を利用したツールである Vercel の v0 との統合も発表しました。v0 は、数分でアイデアを本番対応のフルスタックウェブアプリケーションに変換します。これには、Aurora PostgreSQL、Aurora DSQL、DynamoDB データベースが含まれています。また、Vercel を利用してエクスプレス設定を通じて作成した既存のデータベースも接続できます。詳細については、「 AWS for Vercel 」にアクセスしてください。 Vercel と同様に、当社はデータベースをそれらのエクスペリエンスとシームレスに統合し、広く普及しているフレームワーク、AI アシスタントコーディングツール、環境、デベロッパーツールと直接統合して、アイデアのスピードで開発を進めることを可能にしています。 さらに、 Kiro powers との Aurora PostgreSQL 統合 も導入しました。デベロッパーはこれを利用して、 Kiro を通じた AI エージェント支援開発を活用することで、Aurora PostgreSQL を利用するアプリケーションをより迅速に構築できます。Aurora PostgreSQL 向けの Kiro power は、 Kiro IDE 内で、または Kiro powers のウェブページ から、ワンクリックでインストールして使用できます。この Kiro Power の詳細については、「 Introducing Amazon Aurora powers for Kiro 」および「 Amazon Aurora Postgres MCP Server 」をお読みください。 今すぐご利用いただけます Aurora PostgreSQL サーバーレスデータベースは、すべての AWS 商用リージョンで数秒で今すぐ作成できます。リージョンごとの利用可否と今後のロードマップについては、「 AWS Capabilities by Region 」にアクセスしてください。 お支払いいただくのは、Aurora Capacity Units (ACU) に基づいて消費したキャパシティについての料金のみであり、キャパシティがゼロの状態から秒単位で課金されます。アプリケーションのニーズに基づいて、キャパシティが自動的に起動、シャットダウン、スケールアップ、スケールダウンされます。詳細については、 Amazon Aurora の料金ページ にアクセスしてください。 Aurora および RDS コンソール でお試しいただき、 AWS re:Post for Aurora PostgreSQL に、または通常の AWS サポート担当者を通じて、フィードバックをお寄せください。 – Channy 原文は こちら です。

インシデント発生時の根本原因分析は、クラウドアプリケーション運用において最も時間がかかり、ストレスの大きい作業の一つです。エンジニアは複数のサービスにまたがるテレメトリデータを迅速に相関づけ、デプロイ履歴を確認し、複雑なアプリケーションの依存関係を把握しなければなりません。しかもそのすべてを、サービス復旧というプレッシャーの中で行う必要があります。AWS DevOps Agent は、運用チームに自律的な調査能力をもたらすことでこのパラダイムを変革し、平均復旧時間 (MTTR) を数時間から数分に短縮します。 ただし、AWS DevOps Agent の効果は、リソースアクセスの境界を制御する Agent Space の設定に大きく左右されます。Agent Space の範囲が狭すぎると、調査中に重要なコンテキストを見逃してしまいます。逆に広すぎると、パフォーマンスのオーバーヘッドや複雑さが増大します。本記事では、調査能力と運用効率のバランスを取る Agent Space のセットアップに関するベストプラクティスを、早期に導入いただいたお客様のオンボーディングや社内チームでの DevOps Agent 活用経験をもとに紹介します。 本記事を読み終えると、最適な調査精度を実現するための Agent Space の構成方法、適切なリソースアクセス範囲の決定方法、そして Infrastructure as Code (IaC) を活用したデプロイの効率化について理解できるようになります。まずは、これらすべてを可能にする基本概念である Agent Space そのものについて理解しましょう。 Agent Space とは何か、なぜ重要なのか Agent Space は、AWS DevOps Agent がアクセスおよび調査できる範囲を定義する論理的なコンテナです。エージェントの運用範囲と考えてください。どのクラウドアカウントをエージェントがクエリできるか、どのサードパーティ統合が利用可能か、誰が調査に関与できるかを決定します。 Agent Space が重要なのは、AWS DevOps Agent が正確な根本原因分析を行うために十分なコンテキストを必要とするからです。 インシデントが発生すると、エージェントは以下の処理を実行します。 アカウント全体のリソースとその関係性を学習します。 ログ、メトリクス、トレースからテレメトリデータを相関分析します。 デプロイや設定変更を含む最近の変更をレビューします。 追加のデータソースにクエリを行い、仮説を生成・検証します。 図1: Agent Space トポロジー Agent Space に重要なアカウントや統合へのアクセスが含まれていない場合、エージェントは根本原因を完全に見逃す可能性があります。逆に、Agent Space が広すぎる場合、調査中にエージェントがより多くのリソースの組み合わせを考慮するため、パフォーマンス上の課題が生じます。 スコープとパフォーマンスのトレードオフを理解することが不可欠です。問いはこうなります。“自組織の運用モデルに適した境界をどのように決めれば良いのでしょうか？“ パート1：Agent Space アーキテクチャの設計 Agent Space の境界は、オンコールの責任範囲と同じように考えることを推奨します。アプリケーションに関連するアカウントへのアクセスを付与しつつ、本番環境と非本番環境は分離します。 このアプローチには以下のメリットがあります。 理解しやすい考え方: 運用チームはすでにオンコールの境界を理解しています。 適切な調査スコープ: 人間のエンジニアがインシデントを調査する方法を反映しています。 Two-way door (可逆的) な決定: 必要に応じて Agent Space のスコープを拡大・縮小できます。 パフォーマンスのバランス: エージェントに過剰な情報を与えることなく、十分なコンテキストを提供します。 Agent Space の境界を決定する まず、アプリケーションアーキテクチャを Agent Space の境界にマッピングし、以下の質問を検討します。 何をもって 1 つの論理的なアプリケーションと見なすか？ チームが複数の独立したアプリケーションを所有している場合は、別々の Agent Space を作成します。ただし、アプリケーションが密結合（例：相互依存するマイクロサービス）で、単一のリゾルバーグループ（オンコール担当グループ）にマッピングされる場合は、グループごとに1つの Agent Space を検討します。 複数のアカウントにまたがるモノリスの場合は、クロスアカウントアクセスを持つ1つの Agent Space が適切です。 オンコールローテーションはどのように編成されているか？ 本番と非本番で別々のチームがある場合は、別々の Agent Space を推奨します。 1つのチームがすべての環境を担当する場合は、アプリケーションごとに1つの Agent Space で対応できます。 調査パターンはどうなっているか？ 本番インシデントで他のアカウントの依存サービスへのクエリが必要な場合は、それらのアカウントを含めます。 環境が完全に分離されている場合は、Agent Space も分離します。 決定ツリーの例: アプリケーション：Eコマースプラットフォーム ├── 本番環境 │ ├── アカウント 111111111111（フロントエンド） │ ├── アカウント 222222222222（API Gateway + Lambda） │ └── アカウント 333333333333（RDS + DynamoDB） ├── ステージング環境 │ └── アカウント 444444444444（全リソース） └── 開発環境 └── アカウント 555555555555（全リソース） 推奨 Agent Space： → "EcommerceProd"（アカウント 111111111111, 222222222222, 333333333333） → "EcommerceNonProd"（アカウント 444444444444, 555555555555） 図2. Agent Spaceの境界はオンコールチームの責任範囲を反映する 一般的な Agent Space パターンと判断ポイント 基本的な単一アプリケーションパターン以外にも、慎重な検討が必要なより複雑なシナリオがあります。以下は、お客様が実際に採用して成功しているパターンです。 パターン1: 複数チームにまたがる調査 大規模な組織で複数のチーム（例：100以上の本番アカウントを管理する3チーム）がある場合、チームAのインフラストラクチャで問題が発生しても、根本原因がチームBのサービスにあるという状況が発生します。問題は、Agent Space 間のコラボレーションをどのように実現するかです。 推奨アプローチ： 共有リソースアカウント（依存先など）への読み取り専用アクセスを含むアプリケーション固有の Agent Space を作成します。明確なオンコールエスカレーション手順を確立し ランブック として追加します。これは根本原因がチームにまたがる場合、効率的なコミュニケーション（例： Slack )に有用です。共有サービスチームのリソースには、どのアプリケーションが使用しているかを識別するタグ（例： app-id: ecommerce-frontend ）を設定します。一貫したタグ付け戦略に従うことで、明確なリソース所有権を維持しながら、共有リソースの調査コンテキストを提供できます。 パターン2: 共有サービスとネットワークオペレーションセンター (NOC) チーム 一部の組織には、組織全体の複数のアプリケーションで使用される共有インフラストラクチャサービス（データベース、ネットワーク、モニタリング、セキュリティ）を提供・サポートする集中型チームがあります。これらの NOC や中央運用チームは、すべてのアプリケーションの Agent Space にアクセスすることなく、自分たちのサービスへの可視性を必要とします。 推奨アプローチ： 共有サービスチーム専用の Agent Space を作成し、チームのインフラストラクチャと運用責任をスコープに設定します： 共有データベース、ネットワークインフラストラクチャ、集中ログ、モニタリングシステムを含む AWS アカウントを含めます。 チームがサポートする特定のリソースへの読み取り専用アクセスを提供する IAM ロールを設定します。 共有サービス固有のランブックと運用手順を含めます。 これは、アプリケーション固有の Agent Space と同じ原則に従います。Agent Space がスコープとして複数のアプリケーションにまたがる場合でも、オンコールチームごとに1つの Agent Space です。 パターン3: 多数のアプリケーションを管理する中央運用チーム 共有サービスチームが特定のインフラストラクチャドメインを管理する一方で、SRE チームはさらに大きな課題に直面することがあります。エンタープライズ規模で数百から数千のアプリケーションに対する運用責任です。運用ツールを担当する中央運用チームは、Infrastructure as Code を使用して Agent Space を大規模に効率的に管理できます。 推奨アプローチ： 出発点として、AWS CDK または Terraform のサンプルを使用します。これらのサンプルにより、チームは以下が可能になります。 組織で必要な IAM ロール、統合、リソース境界を含む標準化された Agent Space テンプレートを定義できます。 アプリケーションオンボーディングワークフローの一部として Agent Space をプログラムでデプロイできます。 AWS Config ルールやサービスコントロールポリシーを通じてコンプライアンスを強制できます。 統合された請求とタグ付け（application-id、team、cost-center、environment）を通じてすべての Agent Space を追跡できます。 中央運用チームがテンプレートとガバナンスポリシーを管理し、アプリケーションチームはそのガードレール内で運用します。このアプローチは、一貫した設定と自動デプロイにより、数千のアプリケーションにスケールします。AWS DevOps Agent は、 AWS アカウント内のエージェントアクセスの制限 と、チームが大規模に Agent Space アクセスを管理するためのオペレーターコンソールへの アクセス制御 を可能にします。 図3: Infrastructure as Code を使用したエンタープライズスケールパターン Agent Space の境界をチーム構造とスケール要件に合わせて設計する方法を理解したところで、これらのアーキテクチャパターンを実現するための実践的な実装手順を見ていきましょう。 パート2: Agent Space アーキテクチャの実装 このセクションでは、最初の Agent Space を作成するための実践的な手順を説明します。前提条件の確認、アカウント間の IAM ロール設定、オブザーバビリティツールの統合、アクセス制御の設定、そして調査に必要なコンテキストが確保されていることを確認するためのテストまでを網羅します。 ステップ1: Agent Space の前提条件 最初の Agent Space をセットアップする前に、以下を確認してください。 AWS アカウント: アプリケーションリソースが稼働する AWS アカウントが少なくとも1つ必要です。 IAM 権限: アカウント間で IAM ロールとポリシーを作成するための十分なアクセス権。AWS DevOps Agent には2つの異なる IAM 権限セットが必要です。 Agent Space ロール権限: AWS DevOps Agent が AWS リソースのクエリ、CloudWatch Logs へのアクセス、トポロジーの検出のために引き受ける IAM ロール。このロールには AIOpsAssistantPolicy マネージドポリシーに加え、AWS Support と拡張機能のための追加権限が必要です。完全なロール設定については CLI オンボーディングガイド を参照してください。 オペレーターアプリロール権限: 人間のオペレーターが AWS DevOps Agent Web アプリケーションで実行できる操作（調査の開始、結果の表示、AWS Support ケースの作成など）を制御する IAM ロール。このロールはエージェントの調査権限とは別です。 サービスコントロールポリシー (SCP): 組織の SCP が AWS DevOps Agent の API アクションを許可していることを確認してください。よくあるトラブルとして、チームが Agent Space のセットアップを完了しても、SCP が aidevops:* アクションや bedrock:InvokeModel アクションをブロックしているために調査が失敗するケースがあります。AWS Organization の SCP を確認し、必要に応じて DevOps Agent の例外を追加してください。なお、DevOps Agent と Amazon Bedrock の推論は、お客様のコンテンツを特定の AWS リージョンに制限するポリシーの影響を受けません。Bedrock は米国東部（バージニア北部）以外の米国リージョンをステートレス推論に使用する場合があります。 オブザーバビリティツール: 最低限、Amazon CloudWatch (IAM ロールが適切に設定されていれば自動的に利用可能) と Amazon CloudTrail を利用します。包括的な調査のためには、Datadog、Dynatrace、New Relic、Grafana、Splunk などのアプリケーションパフォーマンスモニタリングツールを統合してください。サポートされている統合については テレメトリソースの接続 を参照してください。 サードパーティ統合設定の理解: 一部のサードパーティツールには2段階の設定プロセスが必要です。 アカウントレベルの登録 : OAuth を使用するツール（GitHub、Dynatrace など）は、まず DevOps Agent コンソールを通じて AWS アカウントレベルで登録する必要があります。これにより、アカウント内のすべての Agent Space で共有される OAuth 認証情報が確立されます。 Agent Space レベルの関連付け: 登録後、各 Agent Space はそのツールから使用するリソースを個別に指定します。例えば、GitHub を一度登録した後、Agent Space「EcommerceProd」には本番リポジトリのみを関連付ける一方、Agent Space「EcommerceNonProd」には開発リポジトリを関連付ける、ということが可能です。Datadog、New Relic、Splunk などの他のツールは、API キーやトークンを使用して、別途アカウントレベルの登録なしに Agent Space に直接関連付けることができます。CloudWatch は IAM ロール以外の追加設定は不要です。 ソースコントロール: コードコンテキストとデプロイの相関分析のための GitHub または GitLab リポジトリアクセスを推奨します (オプションだが強く推奨)。 IaC ツール: Agent Space デプロイ用の AWS CDK（TypeScript/Python）、Terraform、AWS CLI、または AWS マネジメントコンソール。 前提条件の確認が完了したら、Agent Space を作成し、調査を可能にする IAM 信頼関係を確立する準備が整います。 ステップ2: Agent Space の作成 AWS DevOps Agent は、Agent Space の境界内にある各 AWS アカウントに IAM ロールを必要とします。エージェントはこれらのロールを引き受けて、CloudWatch Logs のクエリ、リソース情報の取得、アプリケーショントポロジーの構築を行います。 AWS DevOps Agent は、設定された Agent Space 内でアクセスを許可したすべての AWS アカウントの複数の AWS リージョンから運用データを取得するように設計されており、地理的なデプロイ場所に関係なく、分散インフラストラクチャとアプリケーションへの包括的な可視性を実現します。複数アカウントのサポートは、セカンダリアカウントで適切な信頼ポリシーと権限を持つ IAM ロールを作成する設定プロセスを通じて行われます。 オプション A: AWS コンソールウィザードを使用する AWS DevOps Agent コンソール に移動し、「Agent Space の作成」を選択して、ガイド付きセットアップに従い、各ターゲットアカウントに IAM ロールを作成します。 図4: コンソールでの Agent Space の作成 セットアップウィザードは、クロスアカウント信頼関係の設定を支援します。 図5: Agent Space の複数アカウント設定 オプション B: Infrastructure as Code を使用する（推奨） Agent Space の作成と複数アカウントへの IAM ロールのデプロイを自動化する CDK および Terraform のサンプルテンプレートを提供しています。 AWS CDK の例（TypeScript）： // 多数のアカウントがある場合はループを使用： const accounts = [ { id: '111111111111', name: 'Prod', role: prodRole, stage: 'prod' }, { id: '222222222222', name: 'Dev', role: devRole, stage: 'dev' }, { id: '333333333333', name: 'Test', role: testRole, stage: 'test' }, ]; accounts.forEach(account => { const association = new devopsagent.CfnAssociation(this, `${account.name}Association`, { agentSpaceId: agentSpace.ref, serviceId: 'aws', configuration: { aws: { assumableRoleArn: account.role.roleArn, accountId: account.id, accountType: 'monitor' } } }); association.addDependency(agentSpace); cdk.Tags.of(association).add('stage', account.stage); }); アカウント間の IAM ロールと権限の設定に関する詳細な手順については、 CLI オンボーディングガイド を参照してください。 Agent Space が作成され、AWS アカウントへのアクセスが確保されたら、次の重要なステップはAWS ネイティブサービス以外の調査コンテキストを提供するオブザーバビリティツールと開発ツールとの接続です。 ステップ3：統合の設定 AWS DevOps Agent は、複数のソースからのデータを相関分析してインシデントを調査します。利用可能なコンテキストが多いほど、根本原因分析の精度が向上します。 推奨される統合 (優先度順) Amazon CloudWatch: AWS サービスからのログ、メトリクス、トレースを提供します。エージェントは調査中に CloudWatch Logs Insights を自動的にクエリします。IAM ロールが適切に設定されていれば、追加の設定は不要です。 オブザーバビリティツール: Datadog、Dynatrace、New Relic、Splunk は、分散トレーシング、ログ、メトリクス、アプリケーションレベルのコンテキストを提供します。AWS コンソールの Agent Space 統合から設定します。 コードリポジトリ: GitHub または GitLab の統合により、エージェントは最近のデプロイとコード変更をレビューできます。OAuth またはパーソナルアクセストークンが必要です。 CI/CD パイプライン: GitHub Actions または GitLab ワークフローにより、エージェントはインシデントとデプロイのタイミングを相関分析できます。コードリポジトリ統合と併せて設定します。 コミュニケーションチャネル: Slack と ServiceNow の統合により、DevOps Agent はチームチャネルにリアルタイムの調査アップデートを投稿し、調査ライフサイクル全体を通じて、調査結果、根本原因分析、推奨される緩和策でインシデントチケットを自動的に更新できます。 高度な統合 組み込みの統合に加えて、AWS DevOps Agent は Webhook トリガーによる調査とカスタム MCP (Model Context Protocol) サーバーをサポートしており、独自のオブザーバビリティツールを持ち込むことができます。 調査トリガーのための Webhook 設定 Webhook により、外部システム (Grafana、Prometheus、PagerDuty、カスタムモニタリングツール) がインシデント発生時に DevOps Agent の調査を自動的にトリガーできます。各 Agent Space は、インシデントを記述する JSON ペイロードを受け付ける一意の Webhook URL を受け取ります。 よくある設定の落とし穴: Webhook 認証: Webhook はセキュリティのために HMAC 署名を使用します。Webhook シークレットは AWS Secrets Manager に保存し、セキュリティポリシーに従ってローテーションしてください。 ペイロード形式: モニタリングツールがタイムスタンプ、影響を受けるリソース、症状の説明を含むインシデントコンテキストを送信するようにしてください。より豊富なコンテキストにより、より正確な調査が可能になります。 Webhook の詳細なセットアップについては、 Webhook を通じた DevOps Agent の呼び出し を参照してください。 独自の MCP サーバーの持ち込み 組み込みの統合以外のオブザーバビリティツール (Grafana、Prometheus、カスタムテレメトリシステム) を使用している場合、MCP サーバーを介して接続できます。MCP サーバーは、DevOps Agent が調査中にクエリする標準化されたプロトコルを通じてツールのデータを公開します。 MCP サーバーの主な要件: パブリックにアクセス可能な HTTPS エンドポイント: MCP サーバーはパブリックインターネットから到達可能である必要があります。VPC でホストされたサーバーは現在サポートされていません。 読み取り専用ツールのみ: セキュリティのため、読み取り操作を実行する MCP ツールのみを公開してください。書き込み操作はプロンプトインジェクションのリスクをもたらします。 ツールの許可リスト: MCP サーバーをアカウントレベルで登録し、Agent Space ごとに特定のツールを選択的に有効にします。すべてのツールへのアクセスを付与せず、調査に関連するもののみを選択してください。 よくある MCP セットアップエラー: 認証の設定ミス: MCP サーバーは OAuth 2.0 または API キー認証をサポートしています。OAuth クライアント認証情報が正しいこと、およびトークン交換 URL が AWS インフラストラクチャからアクセス可能であることを確認してください。 ツール名の長さ: MCP ツール名の最大長は64文字です。それより長い名前は登録に失敗します。 エンドポイント URL の形式: パスを含む完全な HTTPS URL を使用してください。例： https://mcp.example.com/v1/mcp（mcp.example.com だけではありません）。 認証設定を含む包括的な MCP サーバーセットアップについては、 MCP サーバーの接続 を参照してください。 統合のテスト: Webhook または MCP サーバーを設定した後、テスト調査をトリガーして接続性を確認します。 Webhook の場合: モニタリングツールからテストペイロードを送信し、DevOps Agent Web アプリで調査が開始されることを確認します。 MCP サーバーの場合: 手動で調査を開始し、エージェントジャーナル (調査記録)を確認して MCP ツールが正常に呼び出されたことを確認します。 AWS CloudTrail ログでエラーを確認します。CloudTrail は統合の試行を含むすべての DevOps Agent API コールをキャプチャします。 データソースが接続されたら、セキュリティ境界を維持しながら、適切な人が調査に適切にアクセスできるようにする必要があります。 ステップ4: アクセス制御の設定 Agent Space は、認可されたチームメンバーのみが調査に関与できるよう、きめ細かなアクセス制御をサポートしています。 アクセス制御の検討事項: 誰が調査を閲覧すべきか？ 通常はオンコールエンジニア、SRE、DevOps エンジニアです。セキュリティ関連のインシデントにはセキュリティチームの参加も検討してください。 誰が AWS Support ケースを作成すべきか？ 通常はオンコールリードとシニアエンジニアです。過度なケース作成を防ぐため、この権限は制限してください。 誰が Agent Space の設定を変更すべきか？ 通常は中央運用チームまたはインフラストラクチャチームです。日常の調査アクセスとは分離してください。 IAM ベースのアクセス制御: AWS DevOps Agent は、Agent Space へのアクセスを制御するために IAM ポリシーを使用します。IAM ユーザー、グループ、またはロールにポリシーをアタッチします。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "devopsagent:GetAgentSpace", "devopsagent:StartInvestigation", "devopsagent:GetInvestigation", "devopsagent:ListInvestigations" ], "Resource": "arn:aws:devopsagent:us-east-1:123456789012:agentspace/EcommerceProd" } ] } AWS DevOps Agent は、複数のアカウントにまたがる運用データへの特権アクセスを持つ AWS 環境内で動作します。一般的なセキュリティの基盤は適用されますが、Agent Space の設定には固有の考慮事項があります。包括的なセキュリティガイダンスについては、 AWS DevOps Agent セキュリティ のドキュメントを参照してください。 アクセス制御が整ったら、Agent Space の設定が必要な調査カバレッジを提供していることを検証する時です。 ステップ5: テストと反復 Agent Space の設定は後から変更可能です。焦点を絞ったスコープから始め、調査結果に基づいて拡大します。 Agent Space のテスト AWS DevOps Agent Web アプリを使用してテスト調査をトリガーします。 調査を開始し、「/api/checkout エンドポイントの高レイテンシー」などの症状を提供します。 エージェントがどのリソースにクエリするかを観察します。 調査の完全性をレビューします。エージェントは根本原因を特定できましたか？ 調査から欠落しているアカウントやサービスはありませんでしたか？ エージェントは十分なテレメトリデータを持っていましたか？ 結果に基づいて Agent Space の境界を調整します。 調査にコンテキストが不足している場合はアカウントを追加します。 テレメトリのギャップがある場合は統合を追加します。 パフォーマンスが低下する場合はスコープを縮小します。 まとめ AWS DevOps Agent は、インシデント対応を手動で時間のかかるプロセスから、自律的でデータ駆動型の調査へと変革します。ただし、エージェントの効果は適切な Agent Space の設定に依存します。オンコールベースのアプローチ（本番環境と非本番環境を分離しつつ、アプリケーションに関連するアカウントへのアクセスを付与する）に従うことで、不必要な複雑さを導入することなく、正確な根本原因分析のための十分なコンテキストを提供できます。 主なポイント オンコールの境界で考える: Agent Space のスコープは、チームがインシデントを調査する方法を反映すべきです。 Infrastructure as Code を使用する: CDK と Terraform のテンプレートにより、一貫性のある再現可能なデプロイを実現できます。 オブザーバビリティツールを統合する: データソースが多いほど、調査の精度が向上します。 結果に基づいて反復する: 調査パターンの出現に応じて Agent Space のスコープを拡大・縮小してください。 次のステップ 最初の Agent Space を作成しましょう。 AWS DevOps Agent の導入をより容易にし、お客様の問題解決の精度を向上させることに取り組んでいます。Agent Space のセットアップは、迅速で信頼性の高いインシデント解決を実現するための基盤です。ご質問やフィードバックがあれば、以下にコメントをお寄せください。 著者 Tipu Qureshi Tipu Qureshi は AWS Agentic AI のシニアプリンシパルテクノロジストで、運用の卓越性とインシデント対応の自動化に注力しています。AWS のお客様と協力して、回復力があり観測可能なクラウドアプリケーションと自律的な運用システムを設計しています。 Bill Fine Bill Fine は AWS の Agentic AI プロダクトマネジメントリーダーで、AWS DevOps Agent の製品戦略と顧客エンゲージメントをリードしています。 Greg Eppel Greg Eppel は DevOps Agent のプリンシパルスペシャリストで、過去数年間クラウドオペレーションに注力し、AWS のお客様のクラウドジャーニーを支援しています。 本記事は、 Best Practices for Deploying AWS DevOps Agent in Production を翻訳したものです。翻訳は Technical Account Manager の 日平 が担当しました。

本投稿は、 Sagar Desarda と Yutaka Okaによる記事 「 Amazon CloudFront now supports mTLS authentication to origins 」を翻訳したものです。  Amazon CloudFront  は相互TLS（mTLS）機能をカスタマーオリジンに拡張しました。これにより、ビューワーからカスタマーオリジンまでの接続パス全体を通じた、真のエンドツーエンド認証が可能になります。CloudFront はこれまで、ビューワーと CloudFront 間のビューワー mTLS をサポートしており、トラフィックが境界に入る前にクライアントを強力に認証することができました。今回のリリースにより、同じトラフィックが CloudFront からオリジンへも mTLS 経由で継続できるようになり、すべてのホップにわたって暗号化されたアイデンティティと信頼が維持されます。その結果、完全に認証されたリクエストパスが実現し、暗黙の信頼を排除し、エッジでのパフォーマンスを犠牲にすることなくゼロトラストの多層防御アーキテクチャを実現します。 CloudFront とオリジン間の mTLS が重要な理由 エッジからオリジンへ mTLS を拡張することで、リクエストライフサイクル全体にわたって、信頼を境界ベースからアイデンティティベースへと移行させます。お客様はビューワー mTLS とオリジン mTLS を CloudFront で有効にすることで、各層の間の暗黙の信頼を排除し、オリジンで最小権限アクセスを強制できます。これは規制対象および高リスクのワークロードにおいて重要です。そのような環境では、オリジンへのアクセスは検証なしに信頼するのではなく、明示的に認証され、監査可能でなければなりません。ビューワー mTLS で導入された多くの業界固有のメリットが、エンドツーエンドで適用されるようになりました。これには、API の強力なクライアントアイデンティティ、デバイス認証、規制コンプライアンスが含まれ、エンドユーザーから CloudFront を経由してオリジンまでの相互認証によって実現されます。これらのユースケースの業界別の詳細については、ビューワー mTLS に関する以前の ブログ記事 を参照してください。この記事は、エンドツーエンド mTLS がゼロトラスト原則をエッジの先にどのように拡張するかを理解するための前提知識となります。 mTLS の仕組み 標準的な TLS では、証明書管理は一方向です。サーバーが証明書を提示し、クライアントが信頼された認証局（CA）に対してそれを検証する一方、クライアントはトランスポート層では認証されません。運用上、これにより証明書管理はシンプルに保たれます。チームはサーバーの証明書のみをプロビジョニング、ローテーション、監視し、多くの場合、自動化ツールと公的に信頼された CA を使用します。クライアントのアイデンティティが必要な場合は、API キー、OAuth トークン、ヘッダーなどのアプリケーション層のメカニズムに委ねられます。 mTLS はこのモデルを根本的に変更し、双方向認証を導入します。クライアントとサーバーの両方が有効な証明書を提示し、信頼された CA に対してそれらを検証する必要があります。そのため、証明書管理は、小規模で明確に定義されたサーバー証明書のセットの管理から、大規模になりうるクライアント証明書群の管理へと拡大します。これにより、新たな運用上の考慮事項が生じます：証明書の発行と失効、ライフサイクルの自動化、CA 信頼の配布、証明書の侵害やローテーションが必要な場合の影響の局所化です。 mTLS が CloudFront エッジで終端される場合、CloudFront はクライアント認証の証明書検証の実施ポイントとして機能することで、この運用上の複雑さの多くを吸収します。お客様は信頼されたルート証明書とクライアントポリシーを管理し、CloudFront が検証処理をスケーラブルに行います。mTLS がオリジンに拡張された場合も、証明書管理はこのモデルに沿ったままです：CloudFront は独自のクライアント証明書をオリジンに提示し、オリジンの証明書を検証します。これにより、オリジンがすべてのエンドユーザーの証明書を直接管理または信頼する必要なく、相互認証が維持されます。 前提条件 この機能を有効にするには、以下の前提条件があります： ・拡張キー使用法（clientAuth）を持つ X.509v3 クライアント証明書（ PEM 形式）を準備 ・mTLS 認証を要求し、クライアント証明書を検証するように構成されたオリジンサーバー ・ AWS Certificate Manager （ACM）で米国東部（us-east-1）AWS リージョンを選択 設定手順 CloudFront とオリジン間の mTLS 認証の実装には、3つの主要なステップがあります：ACM を通じたクライアント証明書の取得、オリジンサーバーの構成、CloudFront ディストリビューションでの mTLS の有効化です。 ステップ 1：クライアント証明書の構成 CloudFront は2つのソースからのクライアント証明書の導入をサポートしており、それぞれ異なる運用ニーズに適しています： AWS Private Certificate Authority  とサードパーティ CA です。 AWS Private Certificate Authority（推奨） AWS Private Certificate Authority は、ACM とのシームレスな統合による、完全マネージドの証明書ライフサイクルを提供します。このアプローチにより、手動の証明書管理のオーバーヘッドが排除されます。 証明書をリクエストするには： 1. ACM コンソールを開き、米国東部（バージニア北部）リージョンにいることを確認 2. 「証明書のリクエスト」>「プライベート証明書のリクエスト」を選択 3. CA を選択し、ドメイン名を入力 4. 希望するキーアルゴリズムを選択し、更新権限を確認 5. 「リクエスト」を押下 図 1： AWS Certificate Manager からAWS Private Certificate Authorityへの新しい SSL/TLS 証明書リクエストの開始 サードパーティ CA  既存のプライベート CA インフラストラクチャから証明書をインポートして、現在の証明書管理プロセスを維持しながら CloudFront mTLS 機能を利用できます（図2参照） 証明書をインポートするには： 1. ACM コンソールで「証明書のインポート」を選択 2. 証明書本文、秘密鍵、証明書チェーン（すべて PEM 形式）を入力 3. 「証明書をインポート」を押下 クライアント証明書には、mTLS 認証のための拡張キー使用法（clientAuth）が含まれている必要があります。 図 2：AWS Certificate Manager に既存のクライアント証明書と秘密鍵をアップロードして、AWS での mTLS 認証に使用される証明書を登録する画面 ステップ 2：オリジン設定で mTLS を有効化  証明書ベースの検証を必要とする各オリジンに対して mTLS 認証を構成します（図3参照）： 1. CloudFront コンソールで、ディストリビューションの「オリジン」タブに移動 2. 構成するオリジンを選択し、「編集」を選択します。 3. オリジン設定で、「Enable origin mutual TLS」を「オン」に切り替えます。 4. ドロップダウンメニューからクライアント証明書を選択します。 5. 変更を保存します。 図 3：オリジンリクエストに対する mTLS 認証を有効にする CloudFront 設定。CloudFront がオリジンで証明書ベースの認証を強制できるようにします オリジンごとの設定の柔軟性 mTLS はオリジンレベルで構成されるため、同じディストリビューション内の異なるオリジンに異なる証明書を割り当てることができます。これにより、オリジンごとに異なるセキュリティポリシーを適用できます。例えば、API エンドポイントには mTLS を使用し、静的コンテンツ配信オリジンには標準認証を適用できます（図4参照）。 図 4：CloudFront がオリジンとの相互 TLS を確立し、エッジからバックエンドサービスまでリクエストが認証・暗号化される構成 エンドツーエンド mTLS によるセキュリティとパフォーマンスのバランス エンドツーエンド mTLS（エンドユーザーから CloudFront、CloudFront からオリジン）を有効にすると、接続確立時にいくらかのオーバーヘッドが発生します。これは、各セグメントで両者を認証するための証明書検証と暗号化処理が必要なためです。ただし、このオーバーヘッドは主にハンドシェイクフェーズに限定され、その後のアプリケーションデータの転送には影響しません。コネクションプーリングや持続的なキープアライブ接続などのコネクション再利用メカニズムにより、多くのエンドユーザーリクエストにわたってこのコストが削減されます。これにより、ほとんどのワークロードでレイテンシーとスループットへの影響が最小限に抑えられます。CloudFront はトラフィックの大部分をエッジでキャッシュするため、大半のリクエストはオリジンに到達せず、相対的なパフォーマンスへの影響がさらに軽減されます。TLS 1.3 と適切な証明書管理により、わずかに高い接続セットアップコストと強力なエンドツーエンド認証のトレードオフは十分に見合うものです。CloudFront を通じて配信されるアプリケーショントラフィックのセキュリティをさらに強化したい場合は、mTLS の実装が有効な選択肢となります。 証明書管理については、AWS Private CA が完全に自動化されたライフサイクル処理と、45 日、30 日、15 日、7 日、1 日前の更新通知によりプロセスを効率化します。サードパーティの証明書を使用している場合は、mTLS 接続の中断を避けるために、タイムリーな手動更新のプロセスを整備してください。 まとめ Amazon CloudFront とオリジン間の mTLS は、最新のエッジアーキテクチャで最も見落とされがちな信頼のギャップの1つを解消します。 パート1 ではエンドユーザーと CloudFront 間の強力なアイデンティティと認証を確立しましたが、mTLS をオリジンに拡張することで、リクエストパスのすべてのホップが認証、暗号化、認可されることが保証されます。これにより、セキュリティは IP およびネットワークベースのモデルから暗号化ベースの信頼モデルへと移行し、オリジンは CloudFront を経由したことを証明できるトラフィックのみを処理します。アプリケーションが分散エッジ、プライベート API、ゼロトラスト原則にますます依存するようになるにつれ、CloudFront からオリジンへの mTLS は、オプションのセキュリティ強化策ではなく、基盤となるセキュリティ対策となります。エンドユーザー mTLS とオリジン mTLS を組み合わせることで、真のエンドツーエンドのアイデンティティ保証が提供され、攻撃対象領域の削減、コンプライアンスの効率化、回復力のあるアプリケーション境界の構築が実現します。 著者について Sagar Desarda Sagar Desardaは、データ、分析、Gen AI ISV 向けのテクニカルアカウントマネージャー（TAM）およびビジネス開発（BD）組織の責任者です。Sagarのチームは、お客様と協力して AWS アーキテクチャを最適化し、ビジネスクリティカルなアプリケーションのシームレスな運用を確保し、採用を加速し、北米全体で市場投入の成功を推進します。さらに、Sagar は Edge Networking Services Specialist US チームのリーダーとして、新規ビジネスの成長を推進し、技術的なエンゲージメントを促進し、顧客向けの出版物を執筆しています。 Yutaka Oka Yutaka Oka は、東京を拠点とするシニアエッジスペシャリストソリューションアーキテクトです。彼の主な焦点は、AWS Edge Services を使用してコンテンツ配信を最適化および保護することでお客様を支援することです。