開発端末上のCodexから、AWSの認証とモデル推論へ接続する構成を紹介しました。直接接続とGateway経由を必要な統制で選びます。 新しい認証基盤を増やす前に、既存のIAM、地域、監視体制との接続を確認します。モデル利用権限とローカル操作の権限は別に残ります。 開発端末を残して推論経路をAWSへそろえる AWSは11月11日、CodexとAmazon Bedrockを組み合わせる導入ガイドを公開しました。Codexは開発者の端末で動作し、対応するOpenAIモデルへの推論要求をBedrockへ送ります。企業がすでに持つ認証、IAM、地域、監視の運用へ接続する構成です。原文の例はGPT-5.6 Solを使います。利用前に、選ぶモデルと地域、推論経路が対象アカウントで使えるかを確認するよう説明しています。単にAWSへログインすれば全モデルを使えるという発表ではありません。まず少人数の最小権限の試行を行い、直接のモデル呼び出しとCodexの設定を順に検証する流れです。 直接接続と中継基盤で統制の置き場所が変わる 標準の出発点はNative AWS Accessです。既存の従業員向け認証とIAM Identity Centerから一時的なAWS認証情報を取得します。AgentCore Gatewayは、管理されたルーティングやBedrock Guardrailsを使いたい場合の経路です。組織が要求の途中で独自の制御を行う場合は、LLM Gatewayも選択肢になります。ガイドはそれぞれの構成で、誰が認証、経路、方針、記録を担当するかを分けています。開発チームには使えるモデルと地域の範囲が影響します。基盤チームには利用量の割り当て、監視先、許可するMCPサーバーやスキルの管理が影響します。推論の入口をそろえても、開発端末で読めるファイルや実行できるコマンドを自動的に制限するものではないと考える必要があります。 試行の停止と記録の範囲を先に決める 導入判断では、非本番のリポジトリと試行対象者を明確にすることが論点です。最初にAWSの直接呼び出しを確認すれば、認証や地域の問題とCodexの設定問題を分けられます。設定は利用者向けか管理された場所へ置き、リポジトリが推論先を変更しないようにする説明もあります。運用上は、誰が何を利用したかに加え、記録へソースコードや機密情報が入るかを確認する必要があると見られます。Gatewayを追加すると管理できる項目が増える一方、運用と費用も増える可能性があります。必要な制御を満たす経路を選び、試行の権限を外す担当者と手順を定めます。モデル利用の停止と端末上の変更の取り消しを別々に確認することが、展開前の重要な判断点になります。共有する設定の変更履歴を保ち、対象者を増やす前に記録の閲覧権限も確かめます。試行を終える際の認証情報と接続設定の整理も、運用の担当範囲になります。