OWN NEWS GATHER
← 戻る
AWS ML Blog

AWS、Amazon ECS上のLiteLLMを通じてOpenAI CodexとBedrockを連携するエンタープライズ構成を公開

要点

  • 米Amazon Web Services（AWS）は、Amazon ECS上のLiteLLMゲートウェイを経由してOpenAIのコーディングエージェント「Codex」とAmazon Bedrockを接続する構成ガイダンスを公開した。

  • 開発者端末での安全なローカルツール実行を維持しながら、モデルのアクセス制御や予算管理、レート制限を一元化する仕組みを提供する。

  • 通信経路は5つのステップに整理されており、ロードバランサーやWeb ACLを組み合わせた安全なリクエストフローが定義されている。

  • 設定や利用履歴を保存するRDS for PostgreSQLなどを含むリファレンス実装が、GitHub上でオープンソースとして提供されている。

  • 米Amazon Web Services（AWS）は2026年9月3日（現地時間）、公式ブログ「AWS Machine Learning Blog」にて、Amazon Elastic Container Service（ECS）上で動作するLiteLLMゲートウェイを利用し、OpenAI ChatGPT CodexとAmazon Bedrockを連携させるアーキテクチャの解説記事を公開した。

  • 組織内でAIコーディングエージェントを本格導入する際に課題となる、アクセス権限の集中管理や利用量・予算の統制を実現するための実践的な手法が示されている。

組織導入で求められるAIエージェントの統制

OpenAIの「Codex」などの生成AIコーディングエージェントは、リポジトリ全体の構造を把握し、コードの記述やテストの実行、複数ステップにわたる開発タスクを自律的に支援するツールとして活用が進んでいる。
しかし、個人による試用から組織全体での運用へと移行するにつれて、モデルへのアクセス権限の制御や利用実績の適切な帰属、予算管理、レート制限（短時間での過剰なリクエストを防ぐ上限設定）、そして通信経路全体の可観測性（テレメトリ）を確保する仕組みが必要になるとAWSは説明している。

ローカル実行と中央制御を両立する仕組み

今回提案されたアーキテクチャでは、開発者の作業端末と推論基盤の間にオープンソースのLLMプロキシ「LiteLLM」を配置する。
Codex自体は開発者のローカル環境で動作し続け、ローカルのサンドボックス（隔離された安全な実行環境）と承認ポリシーに従ってローカルファイルの読み取りやツールの実行を行う。
一方で、AIモデルへの推論処理は利用者のAWSアカウント内に構築されたインフラを通過し、Amazon Bedrock（複数の基盤モデルをAPI経由で利用できるフルマネージドサービス）へとルーティングされる。これにより、LiteLLMが認証やルーティング、予算管理の共通コントロールポイントとして機能するという。

5段階で処理されるリクエストフロー

記事では、開発者の端末からBedrockに至る1回のモデル処理（ターン）が、以下の5つのステップで処理される構成が解説されている。

  1. タスク送信: Codexが現在のタスクコンテキストと利用可能なツール定義を、LiteLLMの「/v1/responses」エンドポイントへ送信する。
  2. ネットワーク保護と転送: Application Load Balancer（ALB）およびAWS WAF（Webアプリケーションファイアウォール）が通信を検査・制御した上で、AWS Fargate（コンテナ向けサーバーレス実行基盤）上のLiteLLMへリクエストを転送する。
  3. 認証とモデル呼び出し: LiteLLMが呼び出し元を認証し、設定されたモデルと利用ポリシーを確認した上で、ECSタスクロールの権限を用いてAmazon Bedrock上の承認済みモデルを呼び出す。
  4. 応答の返却: Amazon Bedrockからのテキスト応答、または関数呼び出し（ファンクションコーリング：外部ツールの実行要求）がLiteLLMを経由して端末側へ戻る。
  5. ローカル実行とループ継続: モデルがツールの実行を求めた場合、Codexはローカルのサンドボックスと承認設定の下でツールを実行する。その結果を次回のResponsesリクエストに含めてLiteLLMへ送信し、タスク完了まで処理を継続する。

構成を支えるAWSサービスと機能検証

本構成では、運用性とセキュリティを担保するために複数のAWSマネージドサービスが組み合わされている。
LiteLLMの状態管理、使用量、予算データの保持には「Amazon Relational Database Service (RDS) for PostgreSQL」が利用され、APIキーなどの機密情報や暗号化キーの管理には「AWS Secrets Manager」および「AWS Key Management Service (KMS)」が用いられる。
また、ログ収集やコンテナの監視には「Amazon CloudWatch」および「CloudWatch Container Insights」が指定され、コンテナイメージの保管には「Amazon Elastic Container Registry (ECR)」が使われている。

記事では環境構築後の動作確認として、ストリーミング出力やセマンティック継続（文脈を維持した応答の継続）、ファンクションコーリングが正常に機能するかを検証する手順も紹介されている。

代替アーキテクチャの選択肢と実装の公開

AWSは、すべての要件で今回の構成が最適とは限らない点にも言及している。直接的なAWS IAM Identity Centerによるアクセス制御や、Portkeyをはじめとするマネージドゲートウェイサービスを採用した方が適しているシナリオについても比較・解説している。

今回の構成を再現するためのリファレンス実装コードおよび手順は、GitHubの「openai-on-aws/guidance-codex」リポジトリ（feat/enterprise-gateway-readinessブランチ）で公開されており、クイックスタートガイドに従ってデプロイを試すことができる。

元URL