Amazon ECS と Amazon Bedrock で OpenAI ChatGPT Codex を LiteLLM と共にセットアップする

生成 AI コーディングエージェントが個人での試用から企業での本格運用へ移行するにつれ、モデルアクセスの制御、利用コストの帰属、予算とレート制限の適用、そしてモデルアクセス経路の可観測性を一貫して管理する仕組みが必要になります。OpenAI Codex は開発者のワークステーション上でタスクループを実行し、ローカルのサンドボックスと承認設定のもとでファイルを読み取り、承認済みツールを実行します。その一方で、モデル推論のリクエストは顧客の AWS アカウント内のインフラストラクチャへルーティングすることが可能です。本記事では、顧客が運用する LiteLLM ゲートウェイを Amazon ECS 上にデプロイし、Amazon Bedrock 上の OpenAI モデルへ接続して、Codex がゲートウェイの Responses API を使うように設定する手順を説明します。あわせて、セマンティック継続、ストリーミング、関数呼び出しの検証方法や、直接 AWS IAM Identity Center へアクセスする方法、Portkey のようなマネージドゲートウェイが適しているケースも扱います。完全な実装は guidance-codex リポジトリで公開されています。

このソリューションの全体像は、Codex と Amazon Bedrock の間に LiteLLM を配置するというものです。LiteLLM はモデル認証、ルーティング、予算、レート制限、ゲートウェイのテレメトリーを担う共有コントロールポイントになります。Codex 側はローカルのタスク実行とツール実行ループに引き続き責任を持ちます。一連のリクエストフローは次の 5 つのステップで構成されます。まず Codex が現在のタスクコンテキストと利用可能なツール定義をゲートウェイの /v1/responses エンドポイントへ送信します。次に Application Load Balancer と AWS WAF がネットワーク層および Web 層の制御を適用し、AWS Fargate 上で動く LiteLLM へ転送します。LiteLLM は呼び出し元を認証し、設定済みのモデルと消費ポリシーを確認したうえで、ECS タスクロールを使用して Amazon Bedrock 上の承認済みモデルを呼び出します。Amazon Bedrock はテキストまたは関数呼び出しの結果を LiteLLM 経由で返します。もしモデルがツールを要求した場合、Codex は自身のサンドボックスと承認ポリシーの下でローカルにツールを実行し、その結果を次の Responses リクエストで LiteLLM を通じて送信します。このループが続くことで、ゲートウェイは各モデルターンごとに制御を適用できます。ゲートウェイが AWS アカウント内で汎用的なシェルを受け取ることはなく、Codex のローカル承認を置き換えることもありません。

参照デプロイメントは他にも、LiteLLM の状態・使用量・予算データを保存する Amazon RDS for PostgreSQL、ゲートウェイキーとスコープ付きキーを保管する AWS Secrets Manager と AWS KMS、CloudWatch Logs・Container Insights・アラーム・デプロイメントヘルス、不変のゲートウェイイメージを保持する Amazon ECR、オプションの AWS WAF マネージド保護と送信元 IP レート制限を利用します。

LiteLLM を使う理由として、Amazon Bedrock への直接アクセスは、ネイティブの AWS IAM ポリシーと CloudTrail ログで要件を満たせる場合には最もシンプルです。一方、システムチームが開発者やチーム、あるいはモデルプロバイダーを横断して追加の統制を必要とする場合にはゲートウェイが有効です。LiteLLM が適しているのは、承認済みモデルエイリアスのみを許可したい場合、ユーザーまたはチーム単位のスコープ付きゲートウェイキーを発行したい場合、ハードな予算や 1 分あたりのリクエスト数・トークン数の制限を適用したい場合、ルーティングとフォールバックポリシーを一元管理したい場合、上流モデルが共有 ECS タスクロールを使うときにゲートウェイレベルの ID を保持したい場合、そしてゲートウェイ・データベース・ネットワーク・ログ・アップグレードプロセスを自社の AWS アカウントで運用したい場合です。主なトレードオフは運用責任であり、可用性、データベースのライフサイクル、バージョンアップグレード、インシデント対応、キャパシティプランニングを自チームで担う必要があります。

デプロイ手順では、まずリポジトリをクローンし、feat/enterprise-gateway-readiness ブランチへ切り替えます。その後、.env.deploy.example を .env.deploy としてコピーし、AWS プロファイル、リージョン、送信元 CIDR、DNS または証明書の情報を設定します。make litellm-check は読み取り専用のプリフライトチェックを実行し、AWS CLI v2、AWS アイデンティティ、Docker、不変イメージ参照、リージョン整合性、CIDR 制限、TLS 入力、CloudFormation 構文を確認します。CONFIRM_AWS_WRITE=1 make litellm-build は、ダイジェスト固定の LiteLLM ベースイメージを使い、ビルドしたイメージを Amazon ECR へプッシュし、CloudFormation が可変のタグではなく不変の ECR ダイジェストを受け取るようにします。make litellm-plan は実行を伴わない CloudFormation チェンジセットを作成し、レビュー可能な状態にします。確認後、CONFIRM_AWS_WRITE=1 make litellm-deploy を実行してデプロイし、make litellm-status でスタックの状態を確認できます。ECS サービスにはデプロイメントサーキットブレーカーのロールバックと ALB のヘルスチェックが設定され、テンプレートにはターゲット追跡型オートスケーリング、ログとデータの暗号化、RDS バックアップ、ALB アクセスログ、運用アラームも含まれます。本番環境では ENABLE_TLS=true を維持し、信頼できる DNS 名と ACM 証明書を使用し、ALB を承認済みの企業 CIDR または VPN CIDR に制限し、ECS タスクと RDS をプライベートサブネットに配置して、ポート 4000 や 5432 を公開しないようにします。

LiteLLM のマスターキーを開発者に配布しないために、デプロイメントファイルにはユーザーまたはチームの ID とポリシーを定義します。CODEX_API_SECRET_ID、CODEX_KEY_ALIAS、CODEX_KEY_USER_ID、CODEX_KEY_MODELS、CODEX_KEY_MAX_BUDGET、CODEX_KEY_BUDGET_DURATION、CODEX_KEY_TPM_LIMIT、CODEX_KEY_RPM_LIMIT などを設定したうえで CONFIRM_AWS_WRITE=1 make litellm-provision-key を実行すると、ヘルパースクリプトが子プロセス内でマスター資格情報を解決し、LiteLLM の /key/generate API を呼び出して、生成されたキーを KMS 暗号化された Secrets Manager のシークレットに直接書き込みます。資格情報がコマンド引数やターミナルに出力されることはありません。エンタープライズ展開では、各開発者プロファイルが自分の担当シークレットだけを読み取り、スタックの KMS キーで復号できるように IAM ポリシーを設定します。

Codex の設定は make litellm-codex-config で生成できます。ヘルパーは CloudFormation からゲートウェイエンドポイントを読み取り、provider 設定を出力しますが、自動的にユーザー設定へ書き込むことはありません。出力された設定はユーザーレベルの ~/.codex/config.toml に追加します。プロバイダーと認証設定はユーザーレベルに置く必要があり、プロジェクトローカルの .codex/config.toml では無視されます。設定例では model = "gpt-5.5"、model_provider = "litellm-gateway"、wire_api = "responses" が使われます。認証セクションでは aws-secret-auth.py スクリプトを起動し、指定した AWS プロファイルを使用して Secrets Manager から現在のキーを取得し、標準出力へトークンを出力します。Codex はこのコマンドを標準入力なしで実行し、標準出力からベアラートークンを読み取るため、トークンは config.toml に保存されません。

最後に、LiteLLM の管理 UI にある Models + Endpoints 画面では、開発者が利用できる安定したエイリアスと、そのアップストリームの Amazon Bedrock モデルの対応関係を確認できます。直接アクセスが適するのは、IAM Identity Center で ID 管理と監査が完結する場合です。また、インフラ運用を外部に任せたい場合は、Portkey のようなマネージドゲートウェイの導入も検討できます。自運用の LiteLLM とマネージド型ゲートウェイのどちらを選ぶかは、制御要件と運用リソースのバランスで決まります。