はじめに AWS DevOps Agent の調査において、最初の課金対象クエリを実行する前に、どれくらいの費用がかかるかを確認の上、利用するかどうかを判断できます。Investigation Cost Guardrail スキルは、 AWS DevOps Agent にコスト意識をもたらし、調査の開始前にどこまで調べるかをチームが把握・制御できるようにします。 本記事では、オープンソースの AWS DevOps Agent スキルである Investigation Cost Guardrail を紹介します。このスキルは、Amazon CloudWatch、AWS X-Ray、Amazon Athena、Amazon DynamoDB、Amazon S3、AWS CloudTrail といった設定済みの AWS サービスや、サードパーティーツール、エージェント自身のネイティブツールをまたいでエージェントが実行するオペレーションを分類します。そのうえで、見積もり時点における対象リージョンの最新料金を取得します。本記事では、仕組みを説明し、具体的なシナリオを示しながら、自律型 AI にとってコスト意識がセキュリティガードレールと同じくらい重要になりつつある理由を解説します。 DevOps の考え方は、開発と運用の間にあるサイロを取り除くことです。AWS DevOps Agent も同じ原則を体現しています。アプリケーションに関する知識と運用の専門知識の隔たりを埋め、両方の領域を横断してデバッグできる、チームのもう一人の SRE のように機能します。DevOps の考え方が文化とプラクティスをもたらすのに対し、エージェントは自律的な実行をもたらします。 「You build it, you run it（作った人が運用する）」が説明責任を意味していたのに対し、AWS DevOps Agent が目指すのは、大規模環境における持続可能性です。チームの専門知識を 24 時間 365 日利用できるように拡張することで、システムが成長し、単一のチームだけでは監視しきれなくなっても、このオーナーシップモデルを維持できるようになります。 本記事のシナリオとコストの数値はあくまで例です。実際のコストと結果は、リージョン、データ量、現在の AWS 料金によって異なります。 安心して任せるための原則：場数で培われるコスト感覚 あるアクションにどれくらいの費用がかかるかを見積もることは、クラウドで身につけるのが最も難しい感覚の一つです。広範なクエリやテーブル全体のスキャンから学び、実行前にスコープを絞ることが自然にできるようになるまで、時間をかけて身につけていくものです。 AWS DevOps Agent は、シニア SRE が持つ自律性と高度な調査能力をもたらします。このガードレールを使うことで、エージェントは初日から同じコスト意識を備え、実行する各アクションに一貫して適用します。経験豊富なエンジニアが本能的に実践するのと同じ規律で、実行前にスコープとコストを見積もります。 AI ガードレールを取り巻く状況 AI ガードレールとは、AI システムが安全かつ責任を持って、定義された境界内で動作し続けるための安全装置です。AI モデルがどのように出力を生成し、アクションを実行するかを統制するポリシー、技術的な制御、監視の仕組みが含まれます。 ガードレールに関する議論の多くは、コンテンツの安全性、プロンプトインジェクションの防止、意図しない情報開示に焦点を当てています。これらは重要ですが、AI エージェントが「考える」段階から「行動する」段階に移った瞬間、もう一つの側面が極めて重要になります。それは、アクションを実行する前に、そのアクションのコストを把握することです。 従来のソフトウェアのコストは決定論的です。API コールのコストは、呼び出す前にわかります。一方、自律型エージェントは、どの API を呼び出すか、何回呼び出すか、どのスコープを対象にするかを動的に判断します。このスキルにより、こうした動的なコスト構造を事前に可視化し、調整できるようになります。これにより、コストは調査において明示的に考慮される判断材料になります。 AI エージェントの責任共有モデル AWS DevOps Agent では、責任共有モデルを自律型エージェントにまで拡張できます。 AWS DevOps Agent は、調査機能と、それを統制するためのエージェント指示やスキルなどの制御手段を提供します。 利用者はガードレールを設定し、しきい値を決め、エージェントが動作する境界を定義します。 実際の運用で定着するガードレールには、次の 3 つの共通点があります。 必要に応じて有効・無効を切り替えられる（オプトインまたはオプトアウト） 理解するための専門知識が不要 介入時に明確なガイダンスを提供する これが、このガードレールの設計思想です。クラウド料金の専門家にならなくても、コストの透明性を得られます。 AWS DevOps Agent スキルとは コストガードレールの詳細に入る前に、スキルとは何か、そしてエージェントインストラクションとどう違うのかを理解しておくと役立ちます。 スキルは、調査手順と運用ナレッジをまとめた再利用可能なパッケージです。現在のタスクに関連する場合、エージェントによってオンデマンドで読み込まれます。これにより、AWS DevOps Agent は汎用アシスタントから、利用者のインフラストラクチャに精通したスペシャリストへと変わります。 最もシンプルな形では、スキルは SKILL.md とオプションの参照ファイルを含むディレクトリです。 SKILL.md ファイルには、次の内容が含まれます。 フロントマター：名前と説明 エージェントが調査中に従う段階的なインストラクション description フィールドは非常に重要です。エージェントはこのフィールドを使って、そのスキルを読み込むかどうかを判断します。調査が始まると、エージェントは利用可能なすべてのスキルの説明を読み、関連するものを選択します。複数のスキルを同時に読み込むこともできます。 スキルとインストラクション：スーパーパワーと基本命令 AWS DevOps Agent には、運用ナレッジを注入するための 2 つの仕組みがあります。   スキル エージェントインストラクション（AGENTS.md） 読み込まれるタイミング オンデマンド（エージェントが説明と現在のタスクを照合） 常時（無条件、すべてのセッション） コンテンツ形式 Markdown、または補助ファイルを含む ZIP バンドル Markdown のみ、補助ファイルなし 適用範囲 特定のイベントタイプに特化 セッションをまたいで適用されるグローバルポリシー 例えるなら 必要なときにエージェントが発動するスーパーパワー エージェントが常に従う基本命令 ユースケース 調査手順、トラブルシューティングのプレイブック セキュリティポリシー、コーディング標準、組織のガイドライン エージェントインストラクションは、すべてのセッションで無条件にエージェントのコンテキストへ注入されるシステムプロンプトです。常に適用しなければならない常設ポリシーには、インストラクションを使用します。 スキルは、関連するときにだけオンデマンドで読み込まれるスーパーパワーです。参照ファイル、メトリクステーブル、複数ステップの手順を含めることができ、必要のないセッションに読み込むと無駄になるような、深く専門的な能力を表現します。 重要な違いは、インストラクションがエージェントにどのように振る舞うかを教えるのに対し、スキルは特定の問題をどのように調査するかを教える点です。 ソリューション概要：調査コストガードレールのワークフロー 次の図は、調査におけるコストガードレールの位置を示しています。エージェントが調査対象リソースを特定した後、課金対象クエリを実行する前という、可能な限り早い段階でワークフローに介入します。 図 1：AWS DevOps Agent における Investigation Cost Guardrail スキルの仕組み 仕組み：4 層アーキテクチャ 各 AWS サービスの各操作について課金対象かどうかをハードコードするのではなく、このスキルは上の図 1 に示した 4 層アーキテクチャを使用します。これらの層は連携して、レジストリに登録されていないサービスやエージェント自身のネイティブツールも含め、AWS サービス全体の操作を分類します。 Layer 0：ネイティブツールの分類 エージェント自身の各ツールには、課金対象か非課金対象かが明示されています。PromQL（ get_prometheus_metrics ）、 use_splunk とその他のサードパーティー統合、shell、サブエージェントの起動はすべて分類されます。 use_aws もこれらと同様ですが、後続のレイヤーでさらに詳細に分類されます。 Layer 1：ヒューリスティックルール 動詞に基づく分類は、レジストリに記載されていないサービスも含め、サービスを横断して機能します。Describe、List、Get、Lookup、Check、Validate、Tag、Untag はメタデータを返すもので、通常はデータスキャンの料金が発生しません。Query、Scan、Execute、Invoke、Insights などの動詞はデータを処理またはスキャンするため、課金対象として扱われます。多数のページにわたるページネーションを伴う広範な List や Describe の呼び出しには、注意フラグが付けられます。 Layer 2：既知の有料操作レジストリ 有料操作について、レジストリは、正確な計算式と、料金を取得するために使用する AWS Price List API のフィルターを保持しています。レジストリ自体は料金を保持しません。 Amazon CloudWatch （Logs Insights、GetMetricData、GetInsightRuleReport、Live Tail、スキャンされた PromQL サンプルを含む）、 AWS X-Ray 、 Amazon Athena 、 Amazon DynamoDB 、 Amazon S3 のリクエストが対象です。運用担当者は独自のエントリーでレジストリを拡張できます。 Layer 3：自己学習型のレスポンス検証 操作の実行後、スキルは BytesScanned 、 ConsumedCapacity 、 TracesProcessedCount など、課金対象の使用量を示すフィールドがレスポンスに含まれていないかを確認します。以前は未分類だった操作がこれらのフィールドのいずれかを返した場合、スキルは調査の残りの期間、その操作を課金対象として分類します。これにより、調査が進むにつれてカバレッジが向上します。 これらのレイヤーが連携することで、レジストリに記載されていないサービスの操作も含め、ほとんどの操作を動詞に基づいて分類できるように設計されています。レスポンス検証は、ルールが見落とした操作を検出するのに役立ちます。 リージョンごとのライブ料金 料金は AWS リージョンによって異なるため、基準料金を保持せず、見積もり時に AWS Price List API を使用して、ワークロードのリージョンの料金をリアルタイムで取得します。 リージョンはリソース ARN から取得されます。 各料金は pricing:GetProducts で検索され、ワークロードのリージョンを使って一致する料金が選択されます。 その結果、ワークロードが実行されるリージョンの現在の定価に基づくコスト見積もりが得られます。 クロスリージョンへの対応 対象リージョンが Agent Space のリージョンと異なる場合、スキルはデータ転送コストを追加します。特定の送信元から送信先までの経路に対応する料金をリアルタイムで取得し、経路ごとにキャッシュします。リージョン間の料金は地域によって大きく異なるため、一律の料金を仮定せず、その経路に対応する正確な料金を検索します。 判定ゲート 計画された呼び出しの分類、料金の取得、予算との照合が完了すると、ガードレールは次の 3 つの方法のいずれかで判定します。番号は、上の図 1 に示した結果に対応します。 Proceed（続行） ：見積もりが残りの予算内に収まっています。呼び出しは中断なく実行され、調査タイムラインにはステップごとの見積もりと累計額の両方が記録されます。 Warn（警告） ：呼び出しは予算内ですが、非効率の兆候が見られます。たとえば、広範な PromQL クエリ、単一サービスに対する 200 回以上の呼び出し、リージョン間の転送などです。ガードレールは呼び出しの実行を許可しつつ、時間枠の短縮、ラベルフィルター、ステップ間隔の拡大など、コスト効率の高い代替案を添えます。 Halt（停止） ：見積もりが残りの予算を超える場合、時間枠が指定されずにスキャンが要求された場合、またはライブ料金検索で料金を取得できなかった場合、呼び出しは実行されません。ガードレールは最悪ケースの見積もりを提示し、データをスキャンする前に指示を求めて一時停止します。 ガードレールが停止した場合は、必ず次に進むための方法を提案します。 正確なタイムスタンプ、またはより短い時間枠を指定する 特定の 1 つのサービスまたはロググループを対象にする 既知のエラーメッセージを指定する。これにより、エージェントは Logs Insights クエリの代わりに、GB 単位のスキャン料金が発生しない FilterLogEvents API で検索できる リージョン間の転送料金を避けるため、クエリを同一リージョンのソースに限定する シナリオ例 次のシナリオは、同じ決済ワークロードに対する 3 つのリクエストを示しています。いずれもエンジニアが DevOps Agent コンソールに入力したものです。課金対象の呼び出しを実行する前に、ガードレールは必ずライブ料金を取得し、コストを見積もり、調査ごとの予算 $10.00 と照合します。異なるのは結果だけです。見積もりは定価に基づいており、AWS 無料利用枠の適用分は含まれません。 シナリオ A：対象を絞り、時間枠を指定したリクエスト（続行） SRE は次のように依頼します。 「今日の 13:57～14:27 UTC に us-east-1 の payments-prod-alb で発生した 5xx エラーを調査してください」 30 分の時間枠が指定されているため、スキルは Amazon CloudWatch Logs Insights のスキャン量を算出できます。スキャン量は 1.34 GB で、ライブ料金は $0.005/GB なので、コストは $0.0067 です。$10.00 の予算内なので、クエリは実行され、調査が続行されます。 図 2：最初の課金対象呼び出し前にライブ料金、スキャン見積もり、予算チェックが実施され、その後、実際のコストを検証。実際のコストはリージョン、データ量、現在の料金によって異なります。 シナリオ B：1 か月分のデータを対象とする広範なリクエスト（停止して確認） クラウドアーキテクトは次のように依頼します。 「9 月全体の payments-api のすべての 5xx エラーと DynamoDB のスロットリングを相関分析してください」 スキャン対象は 2,673 GB、コストは $13.37 になるため、エージェントは開始前に停止し、料金付きの選択肢を提示します。追加の $3.37 を承認する、対象期間を 7 日間（$3.74）、24 時間（$0.54）、またはインシデントの時間枠（$0.007）に短縮する、データスキャン料金のないメトリクス相関を使用する、あるいはここで終了する、という選択肢です。この時点では、データは一切スキャンされていません。 図 3：エージェントは予算超過時に停止し、エンジニアが続行するための選択肢を料金付きで提示。実際のコストはリージョン、データ量、現在の料金によって異なります。 シナリオ C：有料スキャンを行わないよう指示したリクエスト（スキャン料金のない API に切り替え） DevOps エンジニアは次のように依頼します。 「02:45～03:15 UTC に payments-worker が payments-events-dlq へイベントを送信している理由を調べてください。今回は有料のスキャンを一切実行しないでください」 2 つの有料呼び出しについて料金が算出されます。ワーカーのロググループに対する Amazon CloudWatch Logs Insights クエリ（38.37 GB、$0.19）と、12 個のメトリクスを取得する GetMetricData バッチ（$0.004）です。どちらも予算内ですが、エンジニアが有料スキャンを除外したため、エージェントはデータスキャン料金のない代替手段に切り替えます。エラーが既知の文字列であるため FilterLogEvents を使用し、GetMetricData の代わりに、メトリクスを 1 つずつ取得する GetMetricStatistics を使用します。後者は AWS 無料利用枠の CloudWatch API リクエスト数に計上されます。その結果、checkout-api の新しいリリースによってイベントスキーマが変更されたことが判明しました。 図 4：予算内でもエンジニアの指示に従ってスキップし、Logs Insights クエリと GetMetricData バッチの代わりとなる、データスキャン料金のない呼び出しを表示。 より広いパターン：トークン予算からアクション予算へ このガードレールは、従量課金 API を呼び出す自律型 AI エージェントの設計パターンを示しています。エージェントは行動する前に、その行動にどれくらいの費用がかかるかを把握できます。 これは、AI エージェントの経済性を、トークン予算（推論のコスト）からアクション予算（実行のコスト）へと捉え直すものです。エージェントがツールへアクセスできる場合、真の価値が生まれるのは、エージェントが実行する下流のアクションです。その価値を事前に可視化することで、意図的かつ利用者が承認した予算へと変えることができます。 クラウドアーキテクトや SRE は、何年もかけてこの感覚を身につけます。コストガードレールにより、エージェントは初日からこの感覚を備え、一貫して適用します。午前 3 時のインシデント対応を含め、プレッシャーのかかる状況でも、この規律を維持できるように設計されています。 技術的な実装 このスキルは、コアエージェントを変更することなく、エージェントの既存のスキル階層へ組み込まれます。各調査の前に、次の手順で事前チェックとして実行されます。 エージェントによる探索結果（クエリを実行する予定のロググループ、メトリクス、トレース）を読み取る 計画された各操作を 4 つのレイヤーで分類する AWS Price List API からリージョンごとのライブ料金を取得する コストの完全な内訳とともに、構造化された判定（続行または一時停止）を返す 一時停止する場合は、スコープを絞るための具体的なガイダンスを提供する AWS DevOps Agent は、すべてのセッションに権限のガードレールを適用します。常時適用されるポリシーであるエージェントインストラクションと、オペレーターに明示的な承認を求めるダイレクテッドアクションを組み合わせることで、利用者が定義した境界内でエージェントを運用し続けることができます。 開始方法 Investigation Cost Guardrail は、AWS の GitHub 組織にあるオープンソースリポジトリ aws/tools-for-devops-agent で公開されており、AWS DevOps Agent サービスチームが管理しています。このリポジトリには、インポートしたり独自にカスタマイズしたりできる、コミュニティ作成のスキル、カスタムエージェント、MCP サーバーが含まれています。 前提条件 少なくとも 1 つの AWS アカウントが接続された AWS DevOps Agent の Agent Space Agent Space が引き受ける IAM ロールを更新する権限 手順 1：IAM 権限を付与する このスキルは、見積もり時に AWS Price List Query API を使用してすべての料金を取得します。接続されている各アカウントで、Agent Space が引き受ける IAM ロールに、次のポリシーをアタッチします。権限の詳細については、スキルの README にある Required IAM permissions を参照してください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "ResolveLivePricing", "Effect": "Allow", "Action": "pricing:GetProducts", "Resource": "*" } ] } 手順 2：スキルをインストールする 次の 2 つの方法のいずれかで、スキルを Agent Space に追加します。 オプション A：GitHub 統合（チームに推奨） ： aws/tools-for-devops-agent をフォークするか、 skills/investigation-cost-guardrail/ ディレクトリを自分で管理するリポジトリにコピーし、Agent Space の GitHub 統合を通じてインポートします。これにより、スキルをバージョン管理下に置き、コミットを固定し、プルリクエストで SKILL.md の変更をレビューし、独自の検索パターンで references/pricing-reference.md を拡張できます。 オプション B：直接アップロード ：リポジトリからスキルを .zip としてダウンロードし、Agent Space コンソールでユーザー定義スキルとしてアップロードします。アーカイブでは、スキルディレクトリのルートに SKILL.md を置き、その隣に references/ フォルダーを配置する必要があります。 investigation-cost-guardrail/ ├── SKILL.md └── references/ └── pricing-reference.md 手順 3：スペースレベルの指示を追加する スキルは、説明とのマッチングに基づいてオンデマンドで読み込まれます。各調査でコストガードレールが読み込まれるようにするためには、Agent Space のインストラクションに次の内容を追加します。 “Before executing any tool call that interacts with AWS or third-party services, ALWAYS consult the cost guardrail skill to estimate cost and check budget. Never skip cost evaluation” 日本語訳：「AWS またはサードパーティーサービスとやり取りするツール呼び出しを実行する前に、コストの見積もりと予算の確認のため、必ずコストガードレールスキルを参照してください。コスト評価を決して省略しないでください」 これは、前述した 2 つの仕組みを組み合わせたものです。指示は常設命令であり、スキルはその命令によって呼び出される能力です。 手順 4：環境に合わせてしきい値を調整する このスキルには、調査ごとに $10.00 という保守的なデフォルト予算が設定されています。Agent Space の設定に自然言語の指示を追加するか、 SKILL.md ファイルを直接編集することで上書きできます。たとえば、「調査ごとの予算を $25.00 にしてください」と指定します。 スキルファイルを編集せずに、既知の有料操作レジストリを拡張したり、特定の操作に対する制御を強化したりすることもできます。 opensearch:Search を、1,000 リクエストあたり $0.01 の有料操作として扱う Athena クエリを実行する前に必ず承認を求める 手順 5：検証する ガードレールが有効であることを確認するため、2 つの調査を実行します。 最初に、データ量の多いロググループに対して時間枠を指定せず、たとえば「order-service のエラーを調査してください」という調査を開始します。エージェントは logs:StartQuery を実行する前に停止し、ロググループに保持されている全データ量から算出した最悪ケースの見積もりを提示し、時間枠または既知のエラー文字列を求めるはずです。 次に、時間枠を限定して繰り返します。「今日の 14:00～14:30 UTC に order-service で発生したエラーを調査してください」と入力します。調査タイムラインには、最初の課金対象呼び出しの前に予算ステータスブロックが表示され、各料金には、その料金がどのリージョン向けに取得されたかが明記され、調査が続行されるはずです。 COST CHECK Budget: $10.00 | Spent: $0.00000 | Next: 1 × logs:StartQuery (6.4 GB × $0.005/GB) → $0.03200 | Projected: $0.03200 WITHIN BUDGET Proceeding 最初の調査が一時停止せずに進んだ場合は、手順 3 のスペースレベルの指示が存在することを確認してください。2 つ目の調査が料金取得エラーで停止した場合は、 pricing:GetProducts のアクセス許可とツールポリシーにおける us-east-1 の許可を再確認してください。 クリーンアップ ガードレールと、それを支える設定を削除するには、セットアップ手順を元に戻します。 手順 3 で追加したスペースレベルの指示を Agent Space の指示から削除する Agent Space が引き受ける IAM ロールから、 pricing:GetProducts のインラインポリシー（および追加した読み取り専用のサイジングポリシー）を削除する Agent Space から Investigation Cost Guardrail スキルを削除する まとめ AWS DevOps Agent は自律的なイベント対応を実現します。その自律性にコスト意識を加えることで、チームは運用成熟度の次の段階へ進むことができます。つまり、利用者が定義した透明性のある予算内でインシデントを迅速に解決できます。 Investigation Cost Guardrail は、経験豊富なエンジニアが本能的に理解している原則、すなわち実行前にコストを評価するという原則を適用します。サービスを横断して操作を分類し、AWS Price List API からリージョンごとの現在の料金を取得して、調査コストを透明性があり、利用者が管理できる予算へと変えます。エージェントの速度を低下させるものではありません。エージェントにコスト判断力を与えるものです。 開始するには、GitHub の tools-for-devops-agent から Investigation Cost Guardrail スキルをクローンし、AWS DevOps Agent の設定に追加して、調査にコストを意識した事前チェックを導入してください。 新しいコスト分類や料金パターンについてアイデアがありますか。このガードレールは自由に拡張できます。 investigation-cost-guardrail をフォークし、チームが最も頻繁に実行する操作を追加して、独自の料金モデルを参照するようにしてください。構築したものを共有するには、Issue を作成するか、プルリクエストを送信してください。 Ines Attia Ines は AWS のテクニカルアカウントマネージャーです。エンタープライズのお客様と協力し、スケーラブルでレジリエントかつ Well-Architected なワークロードを設計しています。クラウドアーキテクチャに関する専門知識を生かし、オブザーバビリティと AIOps を運用上の優秀性の向上に適用し、技術上の選択をビジネス成果へ結び付けています。 Tipu Qureshi Tipu は AWS のシニアプリンシパルエンジニアで、DevSecOps 向けエージェンティック AI システムのフルスタック設計と実装を率いています。最先端の AI モデル、専門スキル、MCP ツールを活用する自律型エージェントを構築し、クラウド運用、開発者ワークフロー、カスタマーサポートを変革しています。15 年以上にわたり、運用上の優秀性への情熱を持って、多様な分散システムを大規模に設計、運用、構築してきました。 本ブログは、2026 年 10 月 6 日に公開された「 Control investigation costs before they start with AWS DevOps Agent 」の日本語訳です。翻訳はテクニカルアカウントマネージャーの日平が行いました。

こんにちは、ソフトクリエイトでエンジニアをしているＫです。 以前、 こちらのブログ で「AI Challenge Day」へ参加した感想を投稿した以来、久しぶりの投稿になります！ 最近は、主にAIエージェント周りの開発や検証に取り組んでいます。 はじめに

本ブログは 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 の 中島 章博 が翻訳しました。