本ブログは 2026 年 9 月 3 日に公開された AWS Blog “ Set up OpenAI ChatGPT Codex with LiteLLM on Amazon ECS and Amazon Bedrock ” を翻訳したものです。 OpenAI ChatGPT Codex と LiteLLM を組み合わせることで、生成 AI コーディングエージェントに対してエンタープライズ向けの一元的な制御を実現できます。これらのエージェントは、開発者によるリポジトリの理解、コードの記述、テストの実行、複数のステップからなるエンジニアリングタスクの完了を支援します。組織が個人による試験的な利用から、管理体制のもとでの導入へと移行するにつれて、チームにはモデルへのアクセスを制御し、使用量の帰属先を明確にするための一貫した方法が必要になります。また、予算とレート制限を適用し、モデルアクセス経路を監視する必要もあります。 OpenAI Codex (Codex) は、タスクループを開発者のワークステーション上で実行します。ローカルファイルを読み取り、ローカルのサンドボックスと承認設定の範囲内で、承認済みのツールを実行します。その場合でも、モデル推論は、お客様の AWS アカウント内のインフラストラクチャを経由するようにルーティングできます。 この記事では、お客様が運用する LiteLLM ゲートウェイを Amazon Elastic Container Service (Amazon ECS) にデプロイする手順を説明します。ゲートウェイを Amazon Bedrock 上の OpenAI モデルに接続し、ゲートウェイの Responses API を使用するように Codex を設定する方法を紹介します。また、セマンティックな継続 (semantic continuation)、ストリーミング、関数呼び出し (function calling) を検証する方法も紹介します。最後に、AWS IAM Identity Center による直接アクセスや、Portkey のようなマネージドゲートウェイの方が適しているケースについて説明します。 完全な実装は guidance-codex リポジトリ で公開されています。この記事で主に取り上げる構成については、「 LiteLLM on AWS quickstart 」の手順に従ってください。 ソリューションの概要 次のアーキテクチャでは、Codex と Amazon Bedrock の間に LiteLLM を配置します。LiteLLM は、モデル認証、ルーティング、予算、レート制限、ゲートウェイテレメトリを共通で管理するコントロールポイントになります。ローカルのタスクとツール実行のループは、引き続き Codex が担当します。 次の図は、開発者のワークステーションからゲートウェイを経由して Amazon Bedrock に到達し、再び戻ってくるまでのエンドツーエンドのリクエストフローを示しています。番号付きの 5 つのステップで、1 回のモデルターンがインフラストラクチャをどのように通過するかを確認してください。 図 1: Codex はモデルリクエストを LiteLLM 経由で送信し、ローカルのツール実行は引き続き開発者のワークステーション上で行われます リクエストフローは次の 5 つのステップで進みます。 Codex は、現在のタスクコンテキストと利用可能なツール定義を、ゲートウェイの /v1/responses エンドポイントに送信します。 Application Load Balancer と AWS WAF がネットワーク層とウェブ層の制御を適用したうえで、AWS Fargate 上の LiteLLM にリクエストを転送します。 LiteLLM は呼び出し元を認証し、設定されたモデルと利用量ポリシーを確認したうえで、ECS タスクロールを使用して Amazon Bedrock 上の承認済みモデルを呼び出します。 Amazon Bedrock は、テキストまたは関数呼び出しを LiteLLM 経由で返します。 モデルがツールの実行を要求した場合、Codex はサンドボックスと承認ポリシーの範囲内でそのツールをローカルで実行します。Codex は次の Responses リクエストでツールの実行結果を LiteLLM 経由で送信し、ループが続きます。 リファレンスデプロイでは、次のサービスも使用します。 LiteLLM の状態、使用状況、予算データを保存する Amazon Relational Database Service (Amazon RDS) for PostgreSQL ゲートウェイとスコープ付きキーのシークレットを保存する AWS Secrets Manager と、それらのシークレットを暗号化する AWS Key Management Service (AWS KMS) Amazon CloudWatch のログ、CloudWatch Container Insights、アラーム、デプロイのヘルス監視 イミュータブルなゲートウェイイメージを格納する Amazon Elastic Container Registry (Amazon ECR) オプションで利用できる AWS WAF のマネージド保護と、送信元 IP に基づくレート制限 この役割分担が重要です。ゲートウェイに AWS アカウント内の汎用シェルが与えられるわけではなく、Codex のローカル承認を置き換えるものでもありません。ゲートウェイが制御するのは、個々のモデルターンです。 このパターンで LiteLLM を使用する理由 LiteLLM は、API 互換のエンドポイントを通じて、モデルルーティング、仮想キー、予算、レート制限、使用状況テレメトリを提供するオープンソースの AI ゲートウェイです。このパターンでは、お客様が自身の AWS アカウント内で LiteLLM とそれを支えるインフラストラクチャを運用します。 ネイティブの AWS アイデンティティ、AWS Identity and Access Management (IAM) ポリシー、AWS CloudTrail のログでお客様の要件を満たせる場合は、Amazon Bedrock への直接アクセスが最もシンプルな選択肢です。開発者、チーム、モデルプロバイダーをまたいで一貫した追加の制御がシステムチームに必要な場合に、ゲートウェイが役立ちます。 次のような要件がある場合、お客様が自ら運用する選択肢として LiteLLM が有効です。 承認済みのモデルエイリアスのみを許可する ユーザー単位またはチーム単位のスコープ付きゲートウェイキーを発行する 厳格な予算上限と、1 分あたりのリクエスト数または 1 分あたりのトークン数の制限を適用する ルーティングとフォールバックのポリシーを一元化する アップストリームのモデルが共有の ECS タスクロールを使用する場合でも、ゲートウェイレベルでアイデンティティを保持する ゲートウェイ、データベース、ネットワーク、ログ、アップグレードプロセスを自身の AWS アカウント内で運用する 主なトレードオフは運用責任です。ゲートウェイの可用性、データベースのライフサイクル、バージョンのアップグレード、インシデント対応、キャパシティプランニングは、お客様のチームが担います。 Amazon ECS に Codex 用の LiteLLM ゲートウェイをデプロイする このセクションでは、LiteLLM ゲートウェイをデプロイして Amazon Bedrock に接続し、ゲートウェイ経由でリクエストを送信するように Codex を設定する手順を説明します。 前提条件 このウォークスルーには、次のものが必要です。 AWS アカウントと、仮想プライベートクラウド (VPC)、Amazon ECS、Elastic Load Balancing、Amazon RDS、Amazon ECR、AWS WAF、IAM、AWS KMS、Secrets Manager、CloudWatch の各リソースを作成する権限 デプロイ先の AWS リージョンにおける、Amazon Bedrock 上の選択した OpenAI モデルへのアクセス 認証済みプロファイルを設定した AWS コマンドラインインターフェイス (AWS CLI) バージョン 2 Buildx を含む Docker Codex CLI Python 3 HTTPS でデプロイする場合は、パブリックな Amazon Route 53 ホストゾーン、または同じリージョン内の既存の AWS Certificate Manager (ACM) 証明書 このウォークスルーは、米国東部 (バージニア北部) リージョン (us-east-1) で、ゲートウェイエイリアス openai.gpt-5.5 を使用して検証しました。このエイリアスは、LiteLLM の設定で bedrock_mantle/openai.gpt-5.5 にマッピングされています。利用できるモデルはアカウントとリージョンによって異なります。 コストに関する注意: このソリューションでは、Application Load Balancer、Fargate タスク、Amazon RDS、AWS WAF、ログ、モデル推論など、課金対象のリソースが作成されます。サンプルの VPC でもネットワーク料金が発生する場合があります。ご利用のリージョンの最新料金を確認し、ウォークスルーの完了後は「クリーンアップ」セクションの手順に従ってください。 Amazon ECS に LiteLLM をデプロイする リポジトリをクローンし、ローカルのデプロイ環境ファイルを作成します。 git clone https://github.com/openai-on-aws/guidance-codex.git cd guidance-codex git checkout feat/enterprise-gateway-readiness cp deployment/litellm/.env.deploy.example \ deployment/litellm/.env.deploy 実際の .env.deploy ファイルは Git の追跡対象外です。使用する AWS プロファイル、リージョン、送信元 CIDR、DNS または証明書の値を設定します。次の抜粋は、本番環境を想定した設定例です。 AWS_PROFILE=your-profile AWS_REGION=us-east-1 BEDROCK_REGION=us-east-1 ENABLE_TLS=true GATEWAY_DOMAIN_NAME=codex-gateway.example.com ROUTE53_HOSTED_ZONE_ID=Z0123456789EXAMPLE ALB_CERTIFICATE_ARN= ALLOWED_CIDR=203.0.113.10/32 ENABLE_WAF=true DB_MULTI_AZ=true DESIRED_COUNT=2 MIN_TASK_COUNT=2 MAX_TASK_COUNT=10 ALB_CERTIFICATE_ARN を ROUTE53_HOSTED_ZONE_ID の代わりに設定すると、既存の証明書を使用できます。お客様のランディングゾーンにデプロイする場合は、本番デプロイガイドの説明に従って、既存の VPC と、パブリック、プライベートアプリケーション、プライベートデータベースの各サブネットを個別に指定します。 読み取り専用の事前チェック (プリフライト) を実行します。 make litellm-check # Direct helper invocation used by Make: # deployment/scripts/litellm-stack.sh check 事前チェックでは、AWS CLI v2、AWS アイデンティティ、Docker、イミュータブルなイメージ参照、リージョンの一貫性、CIDR の制限、TLS の入力値、ローカルドキュメントのリンクを検証します。cfn-lint が利用可能な場合は、AWS CloudFormation の構文も検証します。 レビュー済みの LiteLLM イメージをビルドし、Amazon ECR にプッシュします。 CONFIRM_AWS_WRITE=1 make litellm-build # Direct helper invocation used by Make: # CONFIRM_AWS_WRITE=1 deployment/scripts/litellm-stack.sh build ビルドでは、ダイジェストで固定された LiteLLM ベースイメージを使用し、生成された ECR ダイジェストを Git の追跡対象外のローカル状態ファイルに記録します。CloudFormation には、変更可能なイメージタグではなく、イミュータブルなダイジェストが渡されます。内部的には、ヘルパーがイミュータブルな Amazon ECR リポジトリを作成または再利用し、Amazon ECR にサインインして docker buildx build --push を実行したうえで、プッシュされたイメージのダイジェストを取得します。 CloudFormation 変更セットを、実行せずに作成します。 make litellm-plan # Direct helper invocation used by Make: # deployment/scripts/litellm-stack.sh plan このコマンドは、ネットワークまたはゲートウェイのテンプレートに対して aws cloudformation deploy --no-execute-changeset を呼び出します。レビュー可能な変更セットが作成されますが、実行はされません。 変更セットをレビューしてから、デプロイします。 CONFIRM_AWS_WRITE=1 make litellm-deploy make litellm-status # Direct helper invocations used by Make: # CONFIRM_AWS_WRITE=1 deployment/scripts/litellm-stack.sh deploy # deployment/scripts/litellm-stack.sh status deploy ヘルパーは、ネットワークスタック、続いて LiteLLM ゲートウェイスタックに対して aws cloudformation deploy を実行します。status ヘルパーは aws cloudformation describe-stacks を実行し、スタックの状態と出力を表示します。 ECS サービスでは、デプロイサーキットブレーカーによるロールバックと Application Load Balancer のヘルスチェックを使用します。リファレンステンプレートでは、ターゲット追跡によるオートスケーリング、ログとデータの暗号化、RDS のバックアップ、ALB アクセスログ、運用アラームも設定されます。 お客様の環境では、 ENABLE_TLS=true を維持し、信頼できる DNS 名と ACM 証明書を使用したうえで、Application Load Balancer へのアクセスを承認済みの社内ネットワークまたは VPN の CIDR に制限してください。ECS タスクと Amazon RDS はプライベートサブネットに配置します。ECS タスクのポート 4000 や PostgreSQL のポート 5432 をパブリックに公開しないでください。 スコープ付きのゲートウェイアイデンティティを作成する LiteLLM のマスターキーを開発者に配布しないでください。代わりに、Git の追跡対象外のデプロイファイルで、ユーザーまたはチームのアイデンティティとポリシーを設定します。 CODEX_API_SECRET_ID=codex-litellm-gateway/alice-key CODEX_KEY_ALIAS=alice@example.com CODEX_KEY_USER_ID=alice@example.com CODEX_KEY_MODELS=gpt-5.5 CODEX_KEY_MAX_BUDGET=50 CODEX_KEY_BUDGET_DURATION=30d CODEX_KEY_TPM_LIMIT=100000 CODEX_KEY_RPM_LIMIT=1000 キーをプロビジョニングします。 CONFIRM_AWS_WRITE=1 make litellm-provision-key # Direct helper invocation used by Make: # CONFIRM_AWS_WRITE=1 deployment/scripts/litellm-stack.sh provision-key ヘルパーは子プロセス内でマスター認証情報を取得し、設定されたモデル、予算、レートのポリシーを指定して LiteLLM の /key/generate API を呼び出します。そのうえで、生成されたキーを AWS KMS で暗号化された Secrets Manager シークレットに直接書き込みます。どちらの認証情報も、コマンド引数に含めたり、ターミナルに出力したりすることはありません。 エンタープライズ規模で展開する場合は、各開発者のプロファイルに、割り当てられたスコープ付きキーのシークレットのみを読み取り、スタックの KMS キーで復号する権限を付与します。チームや環境ごとに、個別のシークレットパスと IAM ポリシーを使用してください。 Codex を設定する プロバイダーブロックを生成します。 make litellm-codex-config # Direct helper invocation used by Make: # deployment/scripts/litellm-stack.sh codex-config ヘルパーは、デプロイされたゲートウェイのエンドポイントを CloudFormation から読み取り、次の Codex プロバイダー設定を出力します。ユーザー設定に自動で書き込むことはありません。 出力内容を、ユーザーレベルの ~/.codex/ config.toml に追加します。プロバイダーと認証の設定は、ユーザーレベルの設定に記述する必要があります。プロジェクトローカルの .codex/ config.toml ファイルに記述しても、Codex はこれらの設定を無視します。 生成される設定は次のような形式です。 model = "gpt-5.5" model_provider = "litellm-gateway" web_search = "disabled" [model_providers.litellm-gateway] name = "LiteLLM Gateway" base_url = "https://codex-gateway.example.com/v1" wire_api = "responses" [model_providers.litellm-gateway.auth] command = "/absolute/path/to/python3" args = [ "/absolute/path/to/deployment/scripts/aws-secret-auth.py", "--aws-cli", "/absolute/path/to/aws", "--region", "us-east-1", "--secret-id", "codex-litellm-gateway/alice-key", "--field", "LITELLM_API_KEY", "--profile", "developer-profile", "print-token" ] timeout_ms = 30000 refresh_interval_ms = 300000 Codex は標準入力なしで認証コマンドを実行し、その標準出力からベアラートークンを読み取ります。ヘルパーは名前付きの AWS プロファイルを使用して最新のシークレットを取得するため、トークンが config.toml に保存されることはありません。 LiteLLM の管理 UI の [Models + Endpoints] には、開発者が利用できる安定したエイリアスと、各エイリアスからアップストリームの Amazon Bedrock モデルへのマッピングが表示されます。これにより、開発者が Codex の設定をプロバイダー固有のモデル ID に直接結び付けるのではなく、ゲートウェイエイリアスを参照していることを、画面上ですばやく確認できます。 次の図は、2 つのモデルエイリアスが設定された [Models + Endpoints] ページを示しています。Codex の設定に進む前に、このリストにゲートウェイエイリアスが表示されていることを確認してください。 図 2: モデル管理ビューには、gpt-5.4 と gpt-5.5 のエイリアスと、それぞれの Amazon Bedrock Mantle へのマッピングが表示されます LiteLLM 経由で Codex をテストする 新しい対話型の Codex セッションを開始し、 /status を使用して、 litellm-gateway がプロバイダーとして選択されていることを確認します。再現可能な非対話型のテストとして、まず最小限のスモークリクエストを実行します。 codex exec --sandbox read-only --ephemeral \ "Reply with exactly LITELLM_GATEWAY_OK and no other text." コマンドが正常に終了し、 LITELLM_GATEWAY_OK が出力されれば成功です。次に、モデル推論とローカルツールの両方が必要なタスクで、エージェントループを動かしてみます。 codex exec --sandbox read-only --ephemeral \ "Read README.md with shell tools and summarize the deployment architecture. Do not modify files." Codex は、タスクとツール定義を LiteLLM 経由で送信します。モデルがファイルの読み取りを要求すると、Codex はそのコマンドをローカルで実行し、同じゲートウェイを通じてツールの実行結果を返します。 LiteLLM の管理 UI で [Logs] を開き、 [Request Logs] を選択して、テストを実施した時間帯で絞り込みます。次の点を確認します。 リクエストのステータスが Success であること キーエイリアスによって、ウォークスルー専用のキーまたは開発者のキーが識別されていること モデルが想定どおり Amazon Bedrock のモデルにマッピングされていること トークン数、リクエストの所要時間、コストが記録されていること Codex が後続の Responses リクエストでツールの実行結果を送信するため、ツールを使用するタスクで複数の行が作成されていること LiteLLM に行が記録される前に 403 レスポンスが返される場合、原因の多くはアップストリームのネットワークまたは AWS WAF によるブロックです。 401 レスポンスは、ゲートウェイの認証情報がないか、無効であることを示します。スクリーンショットには、プロンプト、レスポンス、生のキー、完全なリクエスト ID、実在する従業員を特定できる情報を掲載しないでください。 次の図は、複数の Codex リクエストがゲートウェイを正常に通過した後の LiteLLM の [Request Logs] ページを示しています。このページで、リクエストが Amazon Bedrock に到達していることを確認し、ステータスコードを手がかりにエラーのトラブルシューティングを行います。 図 3: リクエストログには、codex-walkthrough キーエイリアスに帰属する成功した Codex の各ターンが、モデル、コスト、所要時間、最初のトークンが返されるまでの時間とともに表示されます Responses API のコントラクトを検証する テキストプロンプトに正常な応答が返っても、エージェントワークフローとの互換性が証明されたことにはなりません。Codex は、基本的なチャット補完のレスポンスだけでなく、より多くの機能に依存しているためです。リポジトリに含まれている厳格なプローブを実行します。 make litellm-validate # Direct helper invocation used by Make: # deployment/scripts/litellm-stack.sh validate ヘルパーはスコープ付きキーを取得して子プロセスの環境に渡し、デプロイされたゲートウェイに対して deployment/scripts/ validate-responses-contract.py を実行します。 プローブでは、次の項目を検証します。 Responses オブジェクトの必須フィールドと出力の形式 previous_response_id を使用したセマンティックな継続 完了状態の最終レスポンスを含む Server-Sent Events のストリーミング 呼び出し ID を伴う関数ツールの強制呼び出し 継続テストでは、最初のレスポンスに一意のテストマーカーを記録し、後続のレスポンスでそのマーカーを参照できることを検証します。これにより、 previous_response_id を構文上は受け付けるものの、前のレスポンスの状態を保持しないゲートウェイを検出できます。 実際のデプロイ環境は、コントラクト全体の検証に合格しました。CloudFormation は正常に完了し、ECS サービスは必要なタスク数に到達し、デプロイのロールアウトも完了しました。また、ALB のターゲットは正常で、暗号化された PostgreSQL データベースは利用可能かつパブリックにアクセスできない状態でした。 次の図は、実際のウォークスルースタックから取得したエンドツーエンドのデプロイ検証ダッシュボードを示しています。全体の合否ステータスと、インフラストラクチャのヘルス、API コントラクトへの準拠、データ層の設定、セキュリティポスチャを確認する 4 つの詳細パネルに注目してください。 図 4: 検証出力により、AWS のデプロイが正常であることと、Codex が必要とする Responses API の動作を確認できます 検証スクリプトは互換性を確認するためのゲートであり、負荷テストではありません。本番環境に移行する前に、エージェントセッションの同時実行、長時間のストリーム、リクエストのキャンセル、キーの失効、障害からの復旧、想定されるピークトラフィックについてもテストしてください。 エンタープライズ利用に向けて LiteLLM の運用を整備する codex exec とコントラクトテストが成功したことで、Codex がゲートウェイを使用できることは確認できましたが、互換性は出発点にすぎません。開発者のオンボーディングを始める前に、ゲートウェイでモデルアクセスをどのように制御し、使用量の帰属先を明確にし、利用量ポリシーを適用し、各モデルリクエストの運用記録を残すかを定義します。 まず、開発者が使用できるモデルの範囲を決めます。組織が承認したモデルに対してのみ安定したゲートウェイエイリアスを公開し、各アップストリームのマッピングを deployment/litellm/ litellm_config.yaml で固定します。ゲートウェイイメージを再ビルドし、同じ Amazon ECR ダイジェストを各環境に順次昇格させます。これにより、開発者は安定したエイリアスを使い続けることができ、その背後にある Amazon Bedrock モデルはシステムチームが管理し続けられます。 すべてのリクエストの帰属を明確にできれば、モデルポリシーはより効果を発揮します。LiteLLM のマスターキーを配布する代わりに、ユーザー、チーム、ワークロードごとに個別のスコープ付きキーを発行します。アップストリームのリクエストで Amazon Bedrock から見えるのは LiteLLM の ECS タスクロールであるため、リクエスト元のアイデンティティを、スコープ付きキー、LiteLLM のレコード、エクスポートされたテレメトリに引き継ぎます。これにより、ゲートウェイで開発者やチームへの帰属を維持でき、認証情報を記録することなく、リクエスト ID を AWS サービスのログと関連付けられます。 同じスコープ付きアイデンティティで、利用量ポリシーも適用できます。キーをプロビジョニングする際に、 CODEX_KEY_MAX_BUDGET 、 CODEX_KEY_BUDGET_DURATION 、 CODEX_KEY_TPM_LIMIT 、 CODEX_KEY_RPM_LIMIT を設定します。検証専用の一時的なアイデンティティで設定済みのしきい値を意図的に超え、LiteLLM が次のリクエストを拒否することを確かめて、これらの制御を検証します。こうすることで、設定が受け入れられたことを確認するだけでなく、ポリシーそのものが機能するかをテストできます。 ゲートウェイを運用するには、リクエスト経路全体を可視化することも必要です。AWS インフラストラクチャのシグナルからはサービスが正常かどうかがわかり、LiteLLM のレコードからは誰がどのモデルを使用し、リクエストがどれだけのキャパシティや予算を消費したかがわかります。ECS の必要タスク数と実行中タスク数、デプロイのロールバック、Application Load Balancer のターゲットのヘルスとレイテンシー、Amazon RDS のヘルス、LiteLLM のリクエスト数と拒否数、トークン使用量、支出、シークレットへのアクセス、IAM の変更、AWS WAF によるブロックをモニタリングします。 開発者のオンボーディングを始める前に、プロンプトとレスポンスをログに記録してよいかどうかを決めておきます。このコンテンツは機密性の高いお客様のデータを含む可能性があるものとして扱い、それに応じて秘匿化、暗号化、アクセス制御、保持期間を定義します。本番環境のデプロイでは、コンテンツのフィルタリング、拒否トピックの検出、グラウンディングチェックのために、モデルアクセス経路で Amazon Bedrock Guardrails を有効にすることを推奨します。ゲートウェイレベルの制御 (予算、レート制限、ルーティング) は、モデルレイヤーで適用される責任ある AI のセーフガードを補完するものであり、その代わりになるものではありません。 次の図は LiteLLM の [Usage] ページを示しています。このページでは、ゲートウェイを使用するすべての開発者のリクエストとトークンのメトリクスが集計されます。予算やレート制限を調整する前に、このビューで導入状況をモニタリングし、コストの異常を特定し、ユーザーや期間ごとにトラフィックを切り分けます。 図 5: 使用状況ダッシュボードでは、選択した検証期間について、モデル単位のリクエスト、トークン、支出、成功率を可視化できます 図 5 の検証期間には、成功したトラフィックと失敗したリクエストの両方が含まれており、ダッシュボードで通常のアクティビティとエラーの両方を確認できることがわかります。Codex は後続の Responses リクエストでローカルツールの実行結果をモデルに返すため、ツールを使用するタスクではリクエストログに複数の行が記録されることがあります。このように、実行の境界は運用データにも表れます。LiteLLM はモデルリクエストを制御して記録し、Codex は開発者のワークステーション上でツールを実行します。 2 つの代替アクセス経路を検討する このウォークスルーで LiteLLM を主に取り上げたのは、ゲートウェイによる追加の制御をわかりやすく示せるためです。ただし、すべてのお客様に最適というわけではありません。 IAM Identity Center による直接アクセス AWS ネイティブのアイデンティティと監査の制御で十分な場合は、組み込みの amazon-bedrock Codex プロバイダーを使用します。 model_provider = "amazon-bedrock" model = "openai.gpt-5.5" [model_providers.amazon-bedrock.aws] profile = "codex-bedrock" region = "us-east-1" 開発者は、名前付きの IAM Identity Center プロファイルでサインインします。 aws sso login --profile codex-bedrock この経路では、ゲートウェイ、データベース、およびそれらに関連する運用が不要になります。開発者の AWS セッションのアイデンティティは AWS CloudTrail のログに残りますが、ゲートウェイレベルで一元管理する厳格な予算上限やルーティングポリシーは追加されません。 リポジトリの「 IAM Identity Center quickstart 」には、分離されたグループとアクセス許可セットの作成、そのグループの AWS アカウントへの割り当て、クライアント設定の出力、サインインしたプロファイルによる Amazon Bedrock へのアクセス検証を行うための CloudFormation とヘルパーコマンドが含まれています。ゲートウェイを追加する前に、まずこの直接アクセス経路をベースラインとして使用してください。 Portkey によるマネージドアクセスまたはハイブリッドアクセス LiteLLM のリファレンススタックを自ら運用することなく、マネージドのコントロールプレーン、一元化されたルーティングとポリシー、またはサポートが提供されるハイブリッドデータプレーンを利用したい場合は、Portkey が役立ちます。 Codex を Portkey 経由で評価するには、Portkey のワークスペースキー、Amazon Bedrock Model Catalog プロバイダー、Responses ワイヤプロトコルを設定します。 model_provider = "portkey" model = "@bedrock-validation/<approved-model-id>" [model_providers.portkey] name = "Portkey" base_url = "https://api.portkey.ai/v1" env_key = "PORTKEY_API_KEY" wire_api = "responses" 本番環境に昇格させる前に、同じ厳格な Responses プローブを実行します。特に、 previous_response_id によるセマンティックな継続、ストリーミング、関数呼び出し、Amazon Bedrock への正確なルート、IAM ロールと外部 ID の設計を検証してください。製品ドキュメントや認証レスポンスだけでは、意図したモデル経路が Codex のコントラクト全体を満たしている根拠にはなりません。 ゲートウェイ全体を自身の AWS アカウントで運用することよりも、マネージドまたはハイブリッドの運用モデルを重視する場合は、Portkey を選択します。アーキテクチャを決定する際には、ベンダーのライセンス、データの取り扱い、リージョンごとの提供状況、障害モード、サポート範囲も確認してください。 クリーンアップ CloudFormation によって削除されるリソースと保持されるリソースをプレビューします。 make litellm-cleanup-plan # Direct helper invocation used by Make: # deployment/scripts/litellm-stack.sh cleanup-plan このコマンドはスタックを読み取り、何も削除せずに、各リソースが削除されるか保持されるかを一覧表示します。 正確なスタック名を確認したうえで、ゲートウェイを削除します。 CONFIRM_STACK_DELETE=codex-litellm-gateway \ make litellm-cleanup # Direct helper invocation used by Make: # CONFIRM_STACK_DELETE=codex-litellm-gateway \ # deployment/scripts/litellm-stack.sh cleanup ヘルパーは Amazon RDS の削除保護を確認し、 aws cloudformation delete-stack を呼び出して、ゲートウェイスタックの削除が完了するまで待機します。 共有されていないサンプルのネットワークスタックも削除する場合は、オプトインしたうえで個別に確認します。 CONFIRM_STACK_DELETE=codex-litellm-gateway \ DELETE_NETWORKING=1 \ CONFIRM_NETWORKING_DELETE=codex-networking \ make litellm-cleanup # Direct helper invocation used by Make: # CONFIRM_STACK_DELETE=codex-litellm-gateway \ # DELETE_NETWORKING=1 \ # CONFIRM_NETWORKING_DELETE=codex-networking \ # deployment/scripts/litellm-stack.sh cleanup これにより、ゲートウェイスタックに続いて、サンプルのネットワークスタックも削除されます。共有ネットワークにはこのオプションを使用しないでください。 リファレンススタックは Amazon RDS の最終スナップショットを作成し、KMS キー、Secrets Manager のシークレット、CloudWatch のロググループ、ALB のアクセスログ用バケットを保持します。ECR イメージと、プロビジョニングしたスコープ付きキーのシークレットも、スタック削除の対象外です。データ保持ポリシーに従って、保持されたリソースを確認し、削除してください。 まとめ Codex を LiteLLM 経由でルーティングすると、Codex がローカルでタスクとツールを実行する方式を維持しながら、お客様が運用するコントロールポイントで、モデルの選択、スコープ付きアイデンティティ、予算、レート制限、テレメトリを管理できます。本番環境への移行で重要な判断基準は、ゲートウェイがテキストを返せるかどうかではありません。エージェントワークフローに必要な Responses の動作をゲートウェイが維持できるかどうか、そしてシステムチームが追加されたインフラストラクチャを確実に運用できるかどうかです。 AWS ネイティブの制御で要件を満たせる場合は、IAM Identity Center による直接アクセスから始めてください。お客様が運用するゲートウェイのポリシーが運用負荷に見合う場合は、LiteLLM を追加します。マネージドまたはハイブリッドの運用モデルの方が組織に適している場合は Portkey を評価してください。いずれの経路でも、同じコントラクトテストを適用してください。 関連リソース Guidance for Codex on AWS の実装 Amazon Bedrock での OpenAI Amazon Bedrock ドキュメント LiteLLM on AWS quickstart IAM Identity Center quickstart Portkey evaluation quickstart 本番デプロイのガイダンス Codex のカスタムモデルプロバイダー Amazon Bedrock で Codex を使用する方法 AWS Fargate 上の Amazon ECS AWS IAM Identity Center ドキュメント LiteLLM プロキシのドキュメント Portkey の Codex 統合 AWS Pricing Calculator 著者について Nick McCarthy Nick は Amazon Bedrock チームの Senior Generative AI Specialist Solutions Architect で、Amazon Bedrock 上の OpenAI モデルと Codex を専門としています。ヘルスケア、金融、スポーツ、通信、エネルギーなど、幅広い業界の AWS のお客様と協力し、AI と機械学習を活用してビジネス成果の創出を加速できるよう支援してきました。 Sunil Bemarkar Sunil は Amazon Web Services の Sr. Partner Solutions Architect – Gen AI です。大規模言語モデル (LLM) プロバイダーと協力し、お客様が AWS で生成 AI を導入して運用できるよう支援しています。 Sudeesh Sasidharan Sudeesh 氏は OpenAI の Member of Go-to-Market Staff で、OpenAI API と Codex を専門としています。Amazon Bedrock に関して AWS と協力し、組織が OpenAI のフロンティアモデルを導入およびデプロイできるよう支援する活動も行っています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 6 月 16 日に公開された AWS Blog “ Threat tactic spotlight: Subdomain takeover ” を翻訳したものです。 このブログ記事では、サブドメイン乗っ取り (subdomain takeover) を検出して防止する方法を説明します。サブドメイン乗っ取りとは、脅威アクターがダングリング DNS レコード (dangling DNS record) を悪用し、トラフィックを攻撃者が管理するリソースにリダイレクトする手口です。この記事では、この問題の概要と発生する仕組みを説明し、さまざまな AWS の機能やサービスを使用してこの手口の影響を緩和する方法を紹介します。 責任共有モデル では、クラウド内の設定のセキュリティを確保することはお客様の責任です。AWS は、強固なデフォルト設定、 Well-Architected フレームワークのセキュリティの柱 のガイダンス、およびセキュリティサービスを通じて、お客様がその責任を果たせるよう支援しています。また、AWS Customer Incident Response Team (AWS CIRT) は、お客様の特定の設定を悪用するために脅威アクターが使用する新たな手口や流行している手口を監視しています。これにより、お客様は十分な情報に基づいて設計上の判断を下し、対応計画を改善できます。 AWS CIRT は、サブドメイン乗っ取りの機会を狙う脅威アクターが、既に存在しないリソースを指すパブリック DNS の CNAME レコードを積極的にスキャンしていることを確認しています。 注: サブドメイン乗っ取りの手口は、AWS サービスの脆弱性を利用するものではありません。ダングリング DNS レコードを悪用して、トラフィックを攻撃者が管理するリソースにリダイレクトするものです。 DNS の基礎知識 CNAME レコード: CNAME (Canonical Name) レコードは、あるドメイン名を別のドメイン名に向ける DNS エントリです。例えば、api.example.com が api.example.s3-website-us-east-1.amazonaws.com を指すように設定できます。DNS のこの機能により、実際のリソースには機械的に生成された長い AWS ホスト名が割り当てられていても、お客様は覚えやすくわかりやすいドメイン名を設定できます。ただし、ターゲットのリソースを削除した後もそれを指す CNAME レコードが残っていると、「ダングリング」レコードとなり、セキュリティ上の問題が生じます。 ダングリングレコード: リソース (S3 バケットなど) を削除した後もそれを指す DNS レコードが残っている場合、その DNS レコードは存在しないリソースを指す「ダングリング」状態になります。グローバルに共有される名前空間内のリソースの場合、脅威アクターが削除済みのリソース名を取得し、お客様の DNS レコードを通じて悪意のあるコンテンツを配信できる可能性があります。 サブドメイン乗っ取りとは？ サブドメインとは、ドメインの前に付加するプレフィックスで、リソースへのアクセスを整理するために使用します。サブドメイン乗っ取りは、お客様が基盤となるリソースを削除した後、脅威アクターが同じ名前で新しいリソースを作成し、そのリソースを指したまま残っている DNS レコードを悪用することで発生します。 サブドメイン乗っ取りが起こり得るのは、グローバルに共有される DNS 名前空間を使用する AWS リソースを CNAME レコードが指している場合です。このような名前空間では、AWS のお客様であれば誰でもリソース名を選択できます。次の AWS リソースがこの条件に該当します。 Amazon S3 (グローバル名前空間): mybucket.s3.amazonaws.com のようなバケット名はグローバルに一意であり、バケットが削除されると、どのアカウントでもその名前を取得できます。注: アカウントリージョナル名前空間 (2026 年 3 月にリリース) を使用して作成された S3 バケットは、スコープがお客様のアカウントに限定されるため、この問題の対象にはなりません。 Amazon CloudFront: d111111abcdef8.cloudfront.net のようなディストリビューションのドメイン名は AWS によって割り当てられるため、攻撃者が選択することはできません。ただし、お客様がディストリビューションを削除した後、別のお客様が新たに作成したディストリビューションにたまたま同じドメイン名が割り当てられると、ダングリング CNAME を通じて、そのお客様のコンテンツが配信される可能性があります。 AWS Elastic Beanstalk: myapp.elasticbeanstalk.com のような環境名はグローバルに一意であり、環境を終了すると、どのアカウントでもその名前を取得できます。 Amazon VPC、Amazon EC2 インスタンス、プライベートホストゾーンなどのリソースは、グローバルに取得可能な DNS 名前空間を公開していないため、この手口の対象にはなりません。 MITRE ATT&CK では、この手法を T1584.001: Compromise Infrastructure – Domains に分類しています。 シナリオ例の分析 次のシナリオを考えてみましょう。 S3 ウェブサイトエンドポイントを指す DNS CNAME レコードを作成したとします。これにより、サブドメイン subdomain.example.com は subdomain.example.s3-website-us-east-1.amazonaws.com に解決され、subdomain.example という名前の S3 バケットからコンテンツが配信されます。チームがバケットを削除した際に DNS レコードの削除を忘れると、サイトにアクセスしたユーザーには、バケットが存在しないことを示すエラーが表示されます。しかし、この時点で脅威アクターがこのエラーに気付いてそのバケット名を取得すると、独自のサイトを構築できてしまいます。ユーザーが subdomain.example.com サイトにアクセスすると、そのサイトが表示されることになります。 図 1 は、静的ウェブサイトをホストするように設定された subdomain.example という名前の S3 バケット (グローバルに一意なバケット名) と、その S3 ウェブサイトエンドポイント subdomain.example.s3-website-us-east-1.amazonaws.com を示しています。 図 1: 静的ウェブサイトとして設定された S3 バケット 図 2 に示すように、Amazon Route 53 を使用して、Amazon のドメイン名に解決される CNAME レコードを作成します。これにより、ユーザーはわかりやすい名前でアクセスでき、URL に含まれる長い S3 ウェブサイト名を覚える必要がなくなります。 図 2: オリジンバケットを指す CNAME レコードが設定された DNS リゾルバー その後、お客様の AWS 管理者は S3 バケットからのコンテンツ配信を停止することにし、 図 3 に示すようにバケットを削除します。 図 3: CNAME レコードを削除せずにリソースを削除 S3 バケットは削除されたものの CNAME レコードが残っているため、DNS レコードはダングリング状態になります。脅威アクターはこの状況を突き止め、 図 4 に示すように、自身が管理する AWS アカウントで同じグローバル名 subdomain.example を持つ新しい S3 バケットを作成します。これにより脅威アクターは、この新しいバケットからコンテンツを配信できるようになり、その中には悪意のあるコンテンツが含まれる可能性もあります。ユーザーはこの切り替えに気付かず、見覚えのある URL から配信されているように見えるため、コンテンツを信頼して subdomain.example.com へのアクセスを続けます。 図 4: サブドメイン乗っ取りの発生 サブドメイン乗っ取りによって想定される影響 次のような影響が考えられます。 評判へのリスク: DNS レコードが指している脅威アクターのサイトから配信されるコンテンツはお客様が管理できないため、組織の評判が損なわれるリスクがあります。 フィッシングキャンペーンにさらされる可能性: 組織内のユーザーがサブドメインをブラウザにブックマークしている場合、リソースが既に利用できないことを知らないまま、マルウェアをホストしているサイトや、ユーザーの認証情報を詐取するフィッシングに使用されているサイトに、何の疑いもなくアクセスしてしまう可能性があります。 ブロック: サブドメインが悪意のあるアクティビティを理由にセキュリティベンダーからフラグ付けされると、業務に影響が及ぶ可能性があります。 経済的損失: サブドメイン乗っ取りのインシデントに対応する間、サービス提供が中断される可能性があり、経済的な影響が生じる場合があります。 プロアクティブな検出 AWS Config によるプロアクティブな検出 プロアクティブに検出するには、AWS Config を使用して Route 53 の CNAME レコードを継続的に監視し、ターゲットのリソースがアカウント内に存在することを確認します。 前提条件: この方法では、監視対象のリソースタイプ (S3 バケット、CloudFront ディストリビューション、Elastic Beanstalk 環境) に対して AWS Config レコーダーを有効にしておく必要があります。AWS Config で記録されていないリソースタイプは、インベントリチェックに表示されません。詳細については、「 コンソールを使用した AWS Config のセットアップ 」を参照してください。 DNS 解決チェックではなく AWS Config インベントリを使用する理由 一般的な方法は、CNAME が有効なエンドポイントに解決されるかどうかを確認することです。しかし、この方法には重大な欠陥があります。攻撃者が既にリソースを取得している場合、DNS 解決は成功します。ただし、その解決先はお客様のリソースではなく攻撃者のリソースです。応答しているリソースがお客様の所有物ではないことに気付く手がかりはありません。 AWS Config に記録された設定項目をクエリすれば、その DNS 名で単に 何か が応答するかどうかではなく、リソースが お客様の アカウントのインベントリに存在するかどうかを確認できます。この方法なら、乗っ取りが既に発生した後でも、ダングリング CNAME を正しく特定できます。 実装方法: アカウントレベルと組織レベルのスコープ リファレンス実装では、単一のアカウント内の AWS Config インベントリをクエリします。そのため、アカウント A の CNAME レコードが、同じ AWS 組織内のアカウント B に正当に存在するリソースを指している場合でも、ルールはそのレコードを NON_COMPLIANT としてフラグ付けします。 アカウント間でリソースを共有している組織では、AWS Config アグリゲータを使用するようにソリューションを変更できます。AWS Config アグリゲータは、組織内のすべてのアカウントを対象にリソースインベントリをクエリします。これは、IAM Access Analyzer がアカウントレベルと組織レベルの両方のスコープをサポートしているのと同様の考え方です。この方法を使用するには、組織レベルの AWS Config アグリゲータを事前に設定しておく必要があります。また、Lambda 関数の IAM ロールには config:SelectAggregateResourceConfig 権限が必要です。 AWS は、まずはシンプルなアカウントレベルのスコープから始め、環境にクロスアカウントのリソース共有が含まれる場合は組織レベルに拡張することをお勧めします。 基本的な考え方は、Route 53 ホストゾーンの CNAME レコードをクエリするカスタム AWS Config ルールを作成することです。このルールは、各 CNAME のターゲットを解析し、S3、CloudFront、Elastic Beanstalk などの既知の AWS リソースパターンを指しているかどうかを判断します。パターンに一致した CNAME ごとに、ルールはターゲットを AWS Config インベントリと照合し、リソースが実際にアカウント内に存在するかどうかを確認します。リソースが見つからない場合、ルールは CNAME レコードを NON_COMPLIANT としてマークし、レビューが必要なものとして提示します。 AWS Config ルールでは、次の既知の AWS リソースパターンを対象とします。 S3: *.s3.amazonaws.com, *.s3-website-<region>.amazonaws.com 訳注: S3 ウェブサイトエンドポイントは、リージョンによって s3-website.<region>.amazonaws.com (ドット形式) になる場合もあるため、検出パターンではこの形式も考慮してください。参照: Amazon S3 ユーザーガイドの「 ウェブサイトエンドポイント 」 CloudFront: *.cloudfront.net Elastic Beanstalk: *.elasticbeanstalk.com 注: 外部のサードパーティサービスを指す CNAME レコードは、参照先のリソースが AWS Config インベントリに含まれないため、この検出メカニズムの対象外です。 AWS Config ルールによる NON_COMPLIANT の検出結果は、AWS Security Hub に送信して一元的に可視化したり、SNS 通知をトリガーしてセキュリティチームにアラートを送ったりできます。 図 5: ダングリング DNS 検出ソリューション リファレンス実装: AWS は、この検出方法の完全な実装を、 オープンソースのソリューションとして公開 しています。このソリューションでデプロイされる Lambda 関数は、すべての Route 53 ホストゾーンから CNAME レコードを検出し、パターンマッチングを使用して S3、CloudFront、Elastic Beanstalk を指すターゲットを特定します。続いて、AWS Config インベントリをクエリし、各ターゲットリソースがアカウント内に引き続き存在するかどうかを確認します。ダングリングレコードを検出すると、Security Hub で重要度 HIGH の検出結果を生成します。オプションで SNS 通知を送信し、セキュリティチームにアラートを送ることもできます。また、継続的なコンプライアンス追跡のための CloudWatch メトリクスダッシュボードも含まれています。 デプロイ: # Clone the repository git clone https://github.com/aws-samples/sample-dangling-dns-detection cd sample-dangling-dns-detection # Build the Lambda deployment package ./scripts/package.sh # Upload to S3 aws s3 cp dist/dangling-dns-detection.zip s3://YOUR_BUCKET/ # Deploy the CloudFormation stack aws cloudformation deploy \ --template-file infrastructure/template.yaml \ --stack-name dangling-dns-detection \ --parameter-overrides \ LambdaCodeS3Bucket=YOUR_BUCKET \ EvaluationFrequency=TwentyFour_Hours \ --capabilities CAPABILITY_NAMED_IAM このスタックは、指定したスケジュール (デフォルト: 24 時間ごと) で実行される AWS Config カスタムルールを作成します。このルールは、すべての CNAME レコードを評価し、コンプライアンスステータスを報告します。 影響の緩和 サブドメイン乗っ取りを緩和するには、予防のための手順と、発生時の対応能力の両方が必要です。 予防: 標準作業手順 最も効果的な緩和策は、リソースのプロビジョニング解除に関する標準作業手順を定め、基盤となるリソースより先に DNS レコードを確実に削除することです。 DNS ゾーン内で、プロビジョニング解除を予定しているリソースの完全修飾ドメイン名 (FQDN) を指す CNAME レコードを削除します。 DNS の TTL が期限切れになるまで待ってから、リソースを削除します。DNS リゾルバーは TTL の期間中レコードをキャッシュします (例えば、TTL が 3,600 の場合、リゾルバーは最大 1 時間、古いレコードを返す可能性があります)。TTL が期限切れになる前にリソースを削除すると、キャッシュされた CNAME エントリによってトラフィックがまだそのリソースに向けられている間に、脅威アクターがリソース名を取得できてしまう可能性があります。 不要になったリソースをプロビジョニング解除します。 削除した CNAME レコードについて DNS チェックを実行し、その名前がリソースに解決されなくなったことを確認します。 重要な原則: 必ず最初に DNS レコードを削除し、TTL が期限切れになるのを待ってから、リソースを削除してください。この順序を守ることで、ダングリングレコードが悪用される隙をなくすことができます。 予防: S3 のアカウントリージョナル名前空間 前述のとおり、AWS は 2026 年 3 月に Amazon S3 汎用バケットのアカウントリージョナル名前空間 を導入しました。これは S3 固有の乗っ取り経路の緩和に向けた意義のある一歩ですが、運用上の重要な制限事項に注意する必要があります。 既存のバケットには適用されません。 グローバル名前空間で既に作成されたバケットは、アカウントリージョナル名前空間に移行できません。これらのバケット名はグローバルに一意のままであり、バケットを削除すると誰でもその名前を取得できます。 グローバル名前空間が引き続きデフォルトです。 コンソール、CLI、SDK のいずれで新しいバケットを作成する場合も、グローバル名前空間がデフォルトで選択されたままです。新しいオプションを知らないお客様は、今後もグローバルスコープのバケットを作成し続けることになります。 既存の IaC テンプレートは更新が必要です。 アカウントリージョナル名前空間の使用を明示的に選択していない既存の Infrastructure as Code (IaC) テンプレート (CloudFormation、CDK、Terraform) では、引き続きグローバル名前空間でバケットがプロビジョニングされます。CloudFormation の場合は、BucketNamespace プロパティを account-regional に設定します。その他の IaC ツールについては、それぞれのドキュメントで同等の設定を確認してください。組織は、テンプレートを監査し、オプトインするよう更新する必要があります。 こうした理由から、この記事で説明したダングリング DNS の検出方法は引き続き不可欠です。既存の S3 インフラストラクチャを持つ組織や、同等の名前空間のスコープ設定が用意されていない CloudFront および Elastic Beanstalk のリソースについては、特に重要です。 対応: 通知と修復 ダングリング DNS レコードが検出されると、「プロアクティブな検出」セクションで説明したリファレンスソリューションは、AWS Security Hub で重要度 HIGH の検出結果を自動的に作成し、AWS Config で CNAME レコードを NON_COMPLIANT として報告します。デプロイ時に SNS トピック ARN を指定すると、E メール、Slack、その他のチャネルを通じて通知を送信し、セキュリティチームや運用チームにアラートを送ることもできます。本番環境では、ヒューマンインザループのワークフローを検討してください。チームメンバーが通知を確認し、DNS レコードの削除を実行前に承認する仕組みです。これにより、一時的な問題の発生時に正当なレコードを誤って削除することを防げます。 リファレンスソリューションには、コンプライアンスステータスと評価メトリクスを経時的に追跡するための CloudWatch ダッシュボードも含まれています。これにより、チームはホストゾーン全体の DNS の健全性を継続的に可視化できます。 注: 完全に自動化された修復 (DNS レコードの自動削除) にはリスクが伴い、誤検知によって正当なサービスが中断される可能性があります。AWS は、まずは検出と通知から始め、検出精度と運用の成熟度に応じて自動化を検討することをお勧めします。 まとめ サブドメイン乗っ取りは、防止可能な設定ミスでありながら、組織に重大な影響を及ぼす可能性があります。多層防御のアプローチを取ることで、最も効果的に保護できます。 予防: 基盤となるリソースのプロビジョニングを解除する前に DNS レコードを削除する標準作業手順を導入します。 検出: AWS Config カスタムルールを使用して、アカウント内に存在しなくなったリソースを指す CNAME レコードをプロアクティブに特定します。 対応: SNS または Security Hub を通じて通知を設定し、ダングリングレコードが検出されたときにチームが迅速に対応できるようにします。 監視: CloudWatch ダッシュボードを使用して継続的な可視性を確保し、DNS の健全性とコンプライアンスステータスを追跡します。 重要なのは、DNS を適切に管理すること、つまり CNAME レコードが存在しないリソースを指している状況を把握することが、第一の防御策になるという点です。AWS Config による自動検出は、運用手順が機能しなかった場合のセーフティネットになります。さらに、問題を検出したときにすぐ実行できる対応用のプレイブックを用意しておけば、影響を抑え、平均復旧時間を短縮できます。 Matthew Gurr Matthew は、AWS Customer Incident Response Team (AWS CIRT) のアジアパシフィック地域における Senior Incident Response lead です。お客様がセキュリティイベントに事前に備えられるよう支援することに情熱を注いでいます。余暇には、サイクリング、音楽、読書を楽しんでいます。 Luis Pastor Luis は AWS の Senior Security Solutions Architect で、Infrastructure Security and Compliance Technical Field Communities を率いています。金融サービス、ヘルスケア、小売の各業界のエンタープライズのお客様に向けてセキュリティアーキテクチャを推進しており、クラウドセキュリティの変革と規制コンプライアンスフレームワークを専門としています。AWS に入社する前は、ハイブリッドクラウド環境でセキュリティソリューションを設計していました。 Geoff Sweet Geoff は 1990 年代後半からこの業界に携わっています。電気工学の分野でキャリアをスタートし、ドットコムブームの時期に IT 業界に入りました。これまでに、システムアーキテクト、ネットワークアーキテクト、そしてここ数年はセキュリティアーキテクトなど、さまざまな役割を担ってきました。Geoff はインフラストラクチャセキュリティを専門としています。 Ariam Michael Ariam は AWS の Solutions Architect です。Worldwide Public Sector のさまざまなお客様、特に SLG (州政府・地方自治体) および連邦政府の民生機関のお客様を支援してきました。セキュリティ、特にデータ保護に情熱を注いでおり、お客様による暗号化の実装やベストプラクティスの実践を支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 生成 AI を活用したビジネス課題の解決を支援する AWS ジャパン生成 AI 実用化推進プログラム は、通年で応募を受け付けています。戦略プランニング、モデルカスタマイズ、モデル活用の 3 コースがあり、想定コストの 50% を上限とする AWS クレジットや技術支援、勉強会、参加企業間のネットワーキングも用意されています。生成 AI の本番活用を検討されている方は、ぜひご確認ください。 また、このプログラムの 1 コースである 「フィジカル AI 開発支援プログラム by AWS ジャパン」第 2 期 の応募受付が始まりました。VLA をはじめとするロボット基盤モデルや、VLM、世界モデルなどの周辺技術を AWS 上で開発する企業・団体が対象で、スタートアップから大企業、大学・研究機関まで応募できます。フィジカル AI のスペシャリストによる技術支援、コスト最適化、コミュニティ形成、GTM 支援が受けられ、第 1 期に応募した方も再応募が可能です。締切は 11 月 16 日（月）なので、ロボティクス × 生成 AI に取り組んでいる方はお早めにどうぞ。 それでは、10 月 12 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: ソニー銀行株式会社様、勘定系システムの開発に AI エージェントを適用し開発期間を 30% 短縮 ソニー銀行様は、2025 年に勘定系システム全体を AWS へ移行したインターネット銀行です。本番稼働中で顧客の預金や取引を扱う勘定系の開発では、可用性・セキュリティ・監査対応の水準が高く、閉域通信でコーディングエージェントを使うことが条件でした。そこで富士通様とともに、閉域から使える Claude Code on Amazon Bedrock を採用し、Amazon EC2 上の Dev Container で開発環境を統一しました。生成 AI タスクフォースが Skills を作成・配布し、シニアエンジニアの成果物と比べて「One Shot」で基準精度を超えたものから展開、工程間のレビューは人が担う Human in the Loop で進めています。その結果、2026 年 7 月時点で基本設計から結合テストまでの開発工数を 40%、開発期間を 30% 削減しました。 AWS生成AI国内事例ブログ: 日本通運株式会社様、AI 搭載型物流 Web アプリ「DCX」で出荷予測の算出を 1〜2 時間から約 5 分に短縮 日本通運様は、SaaS 型物流ソリューション「DCX」で在庫や入出荷の管理、受注から配送までの可視化を提供している物流事業者です。EC の拡大や商品ライフサイクルの短期化で欠品や過剰在庫を防ぐ意思決定が求められる一方、出荷予測の算出には 1 アイテムあたり 1〜2 時間かかっていました。これを解決するために、時系列予測基盤モデル Chronos-2 を Amazon ECS 上で動かすとともに、Amazon Bedrock Managed Knowledge Base、AgentCore Memory、AgentCore ハーネスを使って、物流データに自然言語で問いかけられるマルチエージェントの「BI LLM Chat」を搭載しました。その結果、出荷予測の算出は約 5 分に短縮され、最大半年先まで日別・週別・月別で予測できるようになりました。 AWS生成AI国内事例ブログ: 株式会社東京会計パートナーズ様、Amazon Bedrock の生成 AI チャットボットで事業承継の提案ができる営業を 3〜5 名から約 20 名全員に拡大 東京会計パートナーズ様は、経営者の事業承継の相談に税務・経営など分野横断でワンストップに伴走している企業です。事業承継の相談に対応できるのはトップ営業 3〜5 名に限られ、そもそも経営者にとって切り出しにくいテーマのため相談の入口がないという課題がありました。そこで ゼネット様 とともに、AI 側から問いかけて対話を進める「経営者のアシスト AI」を構築しました。Amazon Bedrock の Claude と、Amazon Bedrock Knowledge Bases による RAG、Amazon Bedrock Guardrails を組み合わせ、RAG の構築は約 3 営業日で完了しています。その結果、事業承継の提案ができる人が営業部員約 20 名全員に広がりました。今後は同じ仕組みをフレームワーク化し、事業承継以外の経営課題に応えるシミュレーターへの横展開を構想しているそうです。 AWS生成AI国内事例ブログ: 株式会社エナリス様、人の判断を記憶する AI エージェントで ESG 対応の意思決定を支援し LLM コストを約 88% 削減 エナリス 様は、需給管理や電力小売のノウハウをもとに PPA や VPP などの脱炭素ソリューションを展開している企業です。ESG 関連ニュースや規制動向の調査は担当者の手作業頼みで、網羅性や解釈の深さが個人に依存し、「自社として何をすべきか」を考える工程も人に残っていました。そこで KDDI アジャイル開発センター 様とともに、Amazon Bedrock AgentCore と Strands Agents で ESG ダッシュボードを構築しました。ニュースを日次で収集して自社への影響と対応アクションを提示し、担当者の承認・却下とコメントを AgentCore Memory に蓄積して次回以降の生成に反映します。その結果、構築当初と比べて入力トークンを 98% 以上、1 日あたりの LLM コストを約 88% 削減し、2026 年 7 月から社内で活用されています。今後は週次サマリの経営層での活用や、規制・ルール分析機能への展開を目指すそうです。 AWS生成AI国内事例ブログ: 株式会社インフキュリオン様、Amazon Bedrock AgentCore Runtime で請求書カード払いのリモート MCP サーバーを約 1 か月で公開 インフキュリオン様は、決済領域を中心に金融サービスプラットフォームを提供する Fintech 企業で、請求書カード払いの「Winvoice」を運営しています。経理の現場では請求書の受領から支払完了までが複数のツールに分断されており、AI 活用のニーズはあっても、非エンジニアにはローカル環境のセットアップや API 連携が障壁でした。そこで Winvoice の機能を AI エージェントから呼び出せるリモート MCP サーバーを、Amazon Bedrock AgentCore Runtime 上に構築しました。Amazon Cognito のフェデレーションと AgentCore Identity の Token Vault で既存の認証基盤を改修せずに接続し、二段構えの許可リストと人による最終承認で Fintech に求められる統制も確保しています。その結果、企画から約 1 か月で、請求書カード払い領域で国内初（同社調べ）となる MCP 対応を実現しました。 ブログ記事「AI 定着の現在地 ― 先行企業のリアルに学ぶ AWS AI Day in Nagoya 開催報告」を公開 9 月 2 日に名古屋の STATION Ai で開催したイベントの報告です。定員を拡張して 120 名が参加し、神鋼鋼線工業様、東海理化様、タック様、メイテツコム様、東邦ガス情報システム様の 5 社が Kiro や Amazon Bedrock、Amazon Quick を組織に定着させた取り組みを語りました。非 IT 人材から活用コミュニティを広げた話や、AI-DLC で要件・設計品質が上がった話など、導入後の「定着」に悩む方に参考になる内容です。 ブログ記事「【資料公開 & 開催報告】Kiro Meetup #8 ～三菱電機・東海旅客鉄道・オープンアップシステムが語る、Kiro を組織に広げる工夫～」を公開 9 月 24 日に開催した Kiro Meetup #8 の報告で、Kiro の半年分のアップデートと Kiro Crew の解説に加え、3 社のライトニングトークを紹介しています。部門内ユーザー約 900 名の三菱電機様が実装とレビューを別モデルに担わせる工夫や、JR 東海様が研究員自ら実装まで回せるようになった話など、組織展開のヒントが詰まっています。登壇資料も公開されていますのでぜひご覧ください。 ブログ記事「【資料公開 & 開催報告】Kiro ハンズオン「手を動かして実感する、Kiro が変える開発体験」」を公開 同日午後に開催した 3 時間のハンズオンの報告です。Spec、Steering と Agent Skills の使い分け、ハーネスエンジニアリング、MCP、Kiro Crew までを扱い、「Steering が肥大化したら常時不要な部分を Skills に移す」といった実践的なコツも紹介しています。講義資料とワークショップ教材が公開されているので、ぜひご覧ください。 ブログ記事「経済産業省 GENIAC ロボット基盤モデルの研究開発における採択事業者への支援を開始」を公開 経済産業省と NEDO による GENIAC のロボット基盤モデル研究開発で、AWS が採択事業者への支援を始めました。Amazon EC2 P6-B300 / P6-B200 / P5 と Amazon SageMaker HyperPod の計算資源に加え、分散学習環境の構築支援や事業化支援を提供します。アトム様、Highlanders 様、Preferred Networks 様、MW 様、Muso Action 様、メルカリ様の取り組みとコメントも掲載されており、国内のフィジカル AI 開発の最前線がわかります。 ブログ記事「Kimi K3 が Kiro で利用可能になりました」を公開 Moonshot AI のオープンウェイトモデル Kimi K3 が Kiro で使えるようになりました。2.8T パラメーターの MoE モデルで、100 万トークンのコンテキストに大規模なコードベースや仕様書一式を収められるため、Kiro の仕様駆動開発と相性が良いモデルです。us-east-1 の Kiro Pro、Pro+、Pro Max、Power で実験的サポートとして提供され、クレジット倍率は 2.4x です。 ブログ記事「Kiro のローカルサンドボックス: エージェントが実行するコマンドを境界内にとどめる」を公開 Kiro IDE と Kiro CLI で一般提供されたローカルサンドボックスの解説です。エージェントが実行するコマンドのファイルやネットワークへのアクセスを OS カーネルレベルで制限し、シェル経由の迂回も含めて ~/.ssh や ~/.aws の読み取りを拒否します。承認疲れが気になる方や、複数のエージェントを並列で動かしたい方に、仕組みと設定方法を知っておいてほしい機能です。 ブログ記事「エンタープライズ向けサインイン制御を強化しました」を公開 管理者が managed-settings.json で Kiro のサインイン方法を制限できるようになった機能の紹介です。IAM Identity Center のみに限定すれば、個人の Google や GitHub、Builder ID でのサインインを防げます。スタート URL の事前入力やデバイスコードフローの制御もでき、Kiro を全社展開する際のガバナンスを強化したい方に役立ちます。 ブログ記事「AWS Security Agent (now part of AWS Continuum) が新たに公開された実在の CVE 37 件中 33 件のエクスプロイトに成功」を公開 自律型ペネトレーションテストエージェントを、学習データへの混入を抑えた実在 CVE 37 件のベンチマークで評価した結果の報告です。意図した脆弱性でのエンドツーエンドの成功は 33 件（89.2%）で、ターゲットをダウンさせて失敗した事例とその対策まで正直に公開しています。AI によるセキュリティテストの実力とリスクを見極めたい方は必読です。 ブログ記事「AWS Continuum で実現するデプロイごとのペネトレーションテスト」を公開 AWS Continuum for penetration testing を CI/CD のデプロイ後ゲートに組み込み、前回以降の変更点だけを毎デプロイでテストする方法を解説しています。GitHub Actions、GitLab、Bitbucket、Azure DevOps に対応し、重要度のしきい値で本番昇格をブロックできます。既定がフェイルオープンになる設定など運用上の注意点も押さえられています。 ブログ記事「Kiro CLI でセキュリティ調査を迅速化」を公開 AWS セキュリティインシデント対応ガイドのフェーズに沿って、Kiro CLI で Amazon GuardDuty の検出結果を調査するウォークスルーです。承認制でコマンドを実行しながら、封じ込め、EBS スナップショットの取得、CloudTrail 分析、アラート設定まで進め、最後に調査手順をステアリングファイルとして再利用できる形にします。 ブログ記事「Kiro と Amazon Q でセキュリティポスチャを強化する 5 つの方法」を公開 セキュリティ標準をステアリングファイルで永続化したうえで、MCP 経由の Security Hub トリアージ、IaC の修復、Well-Architected レビュー、SCP の生成と検証を AI に任せる方法を紹介しています。設定例やプロンプト例が豊富で、反復的なセキュリティ作業を減らしたいチームにおすすめです。 ブログ記事「Amazon Bedrock を使った AWS Systems Manager Session Manager ログの AI による異常検知」を公開 Session Manager のセッション終了時に、トランスクリプトを Amazon Bedrock で Normal / Suspicious / Critical に分類し、SNS でアラートする仕組みを紹介しています。AgentCore ハーネスとゲートウェイを使えば、SOC アナリストがセッション履歴に自然言語で問い合わせることもできます。CloudFormation テンプレートと GitHub のサンプルですぐに試せます。 ブログ記事「エージェンティック AI システムのための 4 つのセキュリティ原則」を公開 NIST CAISI の情報提供依頼に対する AWS の回答の中核となる 4 つの原則を紹介しています。LLM はセキュリティを強制する仕組みではないため、エージェントの外側に決定論的な制御を置き、自律性は継続的な評価を通じて広げていく、という考え方です。AgentCore の Identity、Gateway、Policy などでの実装例もあり、エージェントの設計指針として役立ちます。 ブログ記事「エージェンティック AI への備え: 金融サービスにおけるセキュリティアプローチ」を公開 金融機関がエージェンティック AI を導入する際に必要な、オブザーバビリティときめ細かなアクセス制御を 7 つの設計原則で整理しています。各国の規制への言及もあり、規制業界でエージェント導入を検討しているアーキテクトやリスク管理部門の方に参考になります。 ブログ記事「AWS で本番 AI エージェントを構築する: 6つの柱によるウォークスルー」を公開 製造業の部品在庫エージェントを題材に、Build / Test / Run / Secure / Observe / Govern の 6 つの柱で本番化に必要な観点を解説しています。AgentCore の各機能や Guardrails、Strands Agents を使ったコード例付きで、デモ止まりのエージェントを本番に乗せたい方にぴったりです。 ブログ記事「SAP ネットワークのトラブルシューティングを数時間から数分へ加速する：エージェント型 AI アプローチ」を公開 Kiro CLI とマネージドな AWS MCP Server で、RISE with SAP を含む SAP 環境のネットワーク障害を自然言語で診断する方法です。504 エラーやクロス AZ レイテンシー、セキュリティグループのドリフト検出など 5 つのユースケースを紹介しており、SAP Basis やネットワーク運用の runbook にそのまま取り入れられます。 ブログ記事「責任ある AI ガバナンス: お客様が ISO/IEC 42005:2025 との整合を図れるよう AWS が支援する方法」を公開 AI システム影響評価の規格 ISO/IEC 42005 を、既存評価への統合方法や再評価のトリガーとともに解説し、AWS Well-Architected Responsible AI Lens との整合点を紹介しています。あわせて ISO/IEC 42001 を AWS 上で設計・運用するためのコンプライアンスガイド の公開も案内されています。AI ガバナンスの体制づくりを担当している方は押さえておきましょう。 ブログ記事「AWS で実現する AI 主権」を公開 データ主権と運用主権に、文化や現地言語の保護を加えた「AI 主権」に対する AWS のアプローチを紹介しています。AWS AI Factories や Outposts、Amazon Bedrock のモデル選択、Nitro System などの選択肢が整理されており、規制業種や公共分野で主権要件を満たしながら生成 AI を導入したい方の論点整理に役立ちます。 サービスアップデート Amazon Bedrock AgentCore の短期メモリが従量制の料金に AgentCore Memory の短期メモリが、イベントごとの定額料金から、エージェントが取り込み・取得・保存するデータ量に応じた従量制に変わりました。小さなイベントを頻繁に書き込むエージェントでも使った分だけの支払いになり、ほとんどのワークロードでコストが下がります。料金は取り込み 1 GB あたり 1.00 USD、取得 1 GB あたり 0.20 USD、ストレージ 1 GB 月あたり 0.10 USD で、長期メモリの料金は変わりません。 Amazon Bedrock AgentCore の Web Search が 4 リージョンに拡大 AI エージェントに Web から最新の情報を提供するフルマネージドツール AgentCore Web Search が、米国東部（オハイオ）、米国西部（オレゴン）、アジアパシフィック（シドニー）、AWS GovCloud (US-West) で使えるようになりました。ユーザーに近いリージョンで検索できるのでレイテンシーが下がり、GovCloud ではコンプライアンス要件のある政府系ワークロードでも利用できます。 AWS Agent Registry がレジストリレコードのカスタムメタデータをサポート 組織内のエージェント、MCP サーバー、エージェントスキルなどを管理する一元カタログ AWS Agent Registry で、所有チームやデータ分類、レビューステータスといった独自の項目をレコードに追加できるようになりました。リソースが数百規模に増えても、人と自動化の両方が同じ基準で検索・統制できます。作成時に必須項目と値を検証する機能もあり、東京リージョンでも利用できます。 Agent Toolkit for AWS の AWS AI/ML スキルで、コーディングエージェントが SageMaker AI を使いこなせるように Agent Toolkit for AWS に AWS AI/ML スキルがコアスキルとして加わり、コーディングエージェントが自然言語のやり取りの中で SageMaker AI のモデル選択、トレーニング、最適化、デプロイまで進められるようになりました。ファインチューニングのガイドや推論最適化、MLflow、JumpStart のモデル推奨にも対応しています。Kiro などの任意のコーディングエージェントで使え、SageMaker Studio の JupyterLab にはプリインストールされています。 NVIDIA Nemotron 3.5 Super VL が Amazon SageMaker JumpStart で利用可能に 画像・動画・テキストを入力できる NVIDIA の視覚言語モデル Nemotron 3.5 Super VL が SageMaker JumpStart に登場しました。120B パラメータ（アクティブ 12B）のハイブリッド MoE で、100 万トークンのコンテキスト、構造化 JSON 出力、ツール呼び出しに対応し、日本語を含む 10 言語をサポートしています。文書理解や GUI 理解、動画の質問応答など、マルチモーダルなエージェントアプリケーションに向いています。 AWS Transform が Azure から AWS へのクラウドネイティブなコード変換を一般提供開始 AWS Transform の .NET モダナイゼーションエージェントが、ソースコード内の Azure SDK を検出して同等の AWS サービスのコードに変換できるようになりました。Azure Functions から AWS Lambda、Blob Storage から Amazon S3、Queue Storage から Amazon SQS への変換が一般提供され、Cosmos DB から Amazon DynamoDB への変換はプレビューです。変換計画を承認・調整してから実行するため、Azure 上の .NET アプリの移行を安心して進められます。東京リージョンでも利用できます。 AWS Transform のフルスタック Windows モダナイゼーションが Aurora PostgreSQL のクロスリージョンデプロイに対応 SQL Server から変換した Amazon Aurora PostgreSQL を、変換計画で指定した別のリージョンにデプロイできるようになりました。データレジデンシーやレイテンシー、ディザスタリカバリーの要件に合わせてデプロイ先を選べます。依存する .NET アプリの接続文字列やデータアクセス部分も同じワークフローで更新され、東京を含む 7 リージョンが新たに対象になりました。 Amazon MWAA が AI エージェントスキルを提供 Amazon Managed Workflows for Apache Airflow が Agent Toolkit for AWS と統合し、ワークフローの作成、デバッグ、テストと、環境のアップグレードを行う 4 つのスキルを提供しました。ETL パイプラインを自然言語で説明すると、タスクの依存関係やエラー処理を含む DAG を AI コーディングアシスタントが生成してくれます。MWAA Provisioned と MWAA Serverless の両方に対応しています。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。