コーディングエージェントを、個人の試しから会社の道具に広げると、誰がどのモデルをどれだけ使ったかが見えなくなる。AWS の公式ブログ（2026年10月21日に日本語版）が、これを LiteLLM のゲートウェイで一元管理する構成を紹介していた。新サービスの発表ではなく、構成の手引きだが、実務で導入を考える人には判断の材料になる。
この記事の結論
- Codex と Amazon Bedrock の間に、自社の AWS アカウントで動かす LiteLLM のゲートウェイを置き、認証・ルーティング・予算・レート制限・テレメトリを一か所に集める構成。
- マスターキーは配らず、ユーザーやチームごとに、許可モデル・予算・TPM・RPM を設けたキーを発行する。
- 便利になる代わりに、ゲートウェイの運用が自社の責任に加わる。
何が起きたか
公式ブログは、OpenAI の Codex（コーディングエージェント）を、LiteLLM を介して Amazon Bedrock につなぎ、ECS 上で動かす手順を示している。構成要素は、前段の ALB と AWS WAF、Fargate 上の LiteLLM、状態と利用量を保存する RDS for PostgreSQL、シークレットを持つ Secrets Manager と AWS KMS、監視の CloudWatch、イメージを置く ECR。流れは次のとおり。
- Codex が
/v1/responsesにリクエストを送る。 - ALB と WAF を通って、LiteLLM に届く。
- LiteLLM が呼び出し元を認証し、ポリシーを確かめて、ECS のタスクロールで Bedrock を呼ぶ。
- Bedrock の応答（テキストか関数呼び出し）が返る。
- ツールの実行は開発者のマシン上の Codex が行い、結果を次のリクエストで送る。
ブログの検証は us-east-1 のリージョンと gpt-5.5 のエイリアスで行われている。対象のリージョンで Bedrock の OpenAI モデルが使えるかは、自分で確かめる必要がある。公式ブログ（日本語）
仕組みとして何が変わったか
ポイントは、鍵の持ち方が変わること。各自がモデルへの認証情報を持つ形から、ゲートウェイが認証を受け持ち、人ごとのキーで入口を分ける形になる。
BEFORE / AFTERCodex × Bedrock
モデルへの入口を、ゲートウェイに集める
これまで
各自がモデルを直接呼ぶ
- 認証情報が、使う人ごとに散らばる誰が使ったかが見えにくい
- 使い過ぎを止める手段が弱い分かるのは請求の後
これから
LiteLLM ゲートウェイ
- 人やチームごとにキーを発行する許可モデル・予算・TPM・RPM
- 上限を超えた呼び出しは拒否される運用は自社の責任
キーごとに設けるのは、許可するモデル、予算の上限と期間、TPM（トークン毎分）の上限、RPM（リクエスト毎分）の上限。キーは LiteLLM の API で作られ、KMS で暗号化した Secrets Manager に置かれる。Codex は認証コマンドで都度シークレットから取り出すので、設定ファイルに平文のトークンが残らない。使った量と支出は、LiteLLM の画面で確かめられ、上限を超えたリクエストが拒否されることも検証できる。
責任の動きも整理する。モデルの利用の統制（誰が、どれを、どこまで）は、自社の決める仕組みに集まる。一方で、ゲートウェイの可用性、DB、アップグレード、インシデント対応、キャパシティの計画は、自社の運用の責任になる。
どんなものに活用できそうか
- チームごとに上限を持たせて試す。 開発チームごとにキーを発行し、月の予算とレート制限を設ける。使い過ぎを早い段階で止められる。
- 利用の帰属先をはっきりさせる。 誰がどのくらい使ったかを、人やチームの単位で見られる。社内の費用の割り当てに使える。
- モデルの選択肢を絞る。 キーごとに許可するモデルを決め、承認していないモデルへの呼び出しを防ぐ。
使わない方がよい場面もある。数人が試すだけなら、ゲートウェイの運用の負担のほうが大きい。公式ブログも、ゲートウェイが要らない場合の代替として、IAM Identity Center による直接のアクセスなどを挙げている。
導入するなら、公式ブログが挙げている注意点を先に確認する。
- ALB の接続元は、社内ネットワークや VPN の CIDR に絞り、ECS と RDS はプライベートに置く。
- テキストの応答が通るだけでは足りない。継続（
previous_response_id）、ストリーミング、関数呼び出しまで、Responses API の互換性を確かめる。 - プロンプトと応答をログに残すかを先に決める。Bedrock Guardrails の併用も勧められている。
- 片付けた後も、RDS の最終スナップショット、KMS キー、シークレット、ログ、ECR のイメージが残ることがある。
- プロバイダーの設定は、ユーザーレベルの
config.tomlに書く。プロジェクトローカルの設定は無視される。
立場ごとに何が変わるか
- 未経験: いまは関係ない。コーディングエージェントを会社で統制する話は、AWS の基本のサービスを知ってからで間に合う。
- 学習中: Bedrock、ECS、Secrets Manager、KMS が一つの構成で組み合わさる例として読める。生成 AI 関連の試験（AIP など）の範囲とどう重なるかは、試験ガイドで確かめる。
- 実務: 社内でコーディングエージェントを展開する担当には、予算とレート制限の具体的な作り方の手引きになる。
- プロ: ゲートウェイを自前で持つか、IAM Identity Center の直接のアクセスのような代替で済ますかが、設計の分かれ目になる。運用責任とログの扱いを含めて判断する。
まとめ
エージェントの利用を会社に広げるなら、使う量と使う人を見える形にする入口が要る。LiteLLM のゲートウェイは、その一つの作り方で、キーごとの上限が決め手になる。代わりに運用の責任が増えるので、規模が小さいうちは代替も比べる。
CHECK 1ここまでの確認
この構成で、予算とレート制限を人やチームごとに管理できるのは、何を発行するからか?
答えと解説
答え: 1. ユーザーごとに、許可するモデルと上限を設定したスコープ付きのキー
「仕組みとして何が変わったか」を読み直す。マスターキーは配らず、キーごとに許可モデル・予算・TPM・RPM を設ける。
CHECK 2ここまでの確認
LiteLLM のゲートウェイを自社で動かすとき、運用の責任が残るのはどれか?
答えと解説
答え: 1. ゲートウェイの可用性、DB、アップグレード、インシデント対応
「使わない方がよい場面」の節を参照。ゲートウェイは自分のアカウントで動かす部品で、運用は利用者の責任になる。
参照ソース
- Amazon Bedrock と LiteLLM による OpenAI ChatGPT Codex の予算・レート制限管理（AWS 公式ブログ）（2026年10月時点）
- Amazon Bedrock の製品ページ（2026年10月時点）
