3行まとめ
AWSの調達、IAM、Region、請求、監査へCodex利用を寄せたい場合。
最新機能、Fast Mode、OpenAI hosted tools、広いfeature coverageを優先する場合。
料金、Region、supported model、feature availabilityが導入時点で変わり得る場合。
Bedrock経由はCodexの実行場所をAWSへ移す話ではなく、モデルリクエストの経路と管理面をAWSへ寄せる選択です。
Codex on Amazon Bedrockは、Codexの実行場所をAWSへ丸ごと移す機能ではなく、ローカルのCodexからAmazon Bedrockへモデルリクエストを送る選択肢です。
向いているのは、AWSの調達、IAM、Region、請求、既存のクラウド統制にCodex利用を寄せたいチームです。OpenAIの最新機能を最速で使いたい、Fast ModeやOpenAI hosted toolsを前提にしたい場合は、OpenAI直接利用を残す判断も現実的です。
2026年6月12日時点で確認した公式情報では、CodexのBedrock providerは openai.gpt-5.5 と openai.gpt-5.4 を対象にし、認証はBedrock API keyまたはAWS SDK credential chainを使います。料金、Region、feature availabilityは変わりやすいため、公開前と導入前の再確認が必須です。
この記事でわかること
local Codex workflowとBedrockへのモデルリクエストを分けて理解します。
Bedrock API key、AWS SDK credential chain、profile、Regionを確認します。
supported model IDとAWS Regionの提供状況を照合します。
Bedrock pricingをtoken、Region、確認日つきで見積もります。
OpenAI直接利用との差分をfeature availabilityで確認します。
AWSアカウントで実課金を発生させる疎通テストは、読者側の導入前確認として扱います。
この記事では、CodexをAmazon Bedrock経由で使う時に、導入前に確認すべき判断軸を整理します。対象は、すでにCodex CLI、Codex app、IDE extensionのいずれかを使っていて、AWSアカウント側の統制に寄せるべきか迷っている開発チームです。
扱うのは、Bedrock経由にすると何が変わるのか、AWS認証とIAMをどこで切るのか、Regionとmodel accessをどう確認するのか、料金をどの単位で見積もるのか、OpenAI直接利用との機能差をどう評価するのか、という実務の入口です。AWSアカウントで実課金を発生させる疎通テストは行っていません。本文中のコマンドは、読者側の環境で確認するための手順として扱ってください。
Codex側の設定を増やす前提整理は、既存記事のCodex設定を増やす前に決めることも合わせて読むと、config.toml、permissions、AGENTS.md、MCPの分担を切り分けやすくなります。
前提知識
- 1Codex CLI / app
ローカルの作業環境でタスクを実行します。
- 2amazon-bedrock provider
Codexのモデルリクエスト先をAmazon Bedrockへ向けます。
- 3AWS認証
Bedrock API keyまたはAWS SDK credential chainを使います。
- 4Amazon Bedrock
対応するOpenAIモデルへOpenAI-compatibleなResponses API経由で接続します。
- 5機能確認
OpenAI直接利用と同じ機能範囲とは限らないため、feature availabilityを確認します。
Codexの実行環境とモデル推論の経路は別物として扱います。
Codex on Amazon Bedrockは、OpenAIのCodexをAWSの管理面に寄せて使うための経路です。OpenAI公式ドキュメントでは、Codexを amazon-bedrock model providerに設定すると、OpenAI hosted Responses APIではなくAmazon Bedrockへモデルリクエストが送られると説明されています。
ここで混同しやすい点が3つあります。
1つ目は、Codexの実行環境とモデル推論の経路は別だということです。Codex CLIやCodex appのローカルタスクは手元の環境で動き、モデルリクエストだけがBedrockへ行きます。AWSにソースコードを丸ごと配置する設計とは限りません。
2つ目は、認証の主体がOpenAI API keyではなくAWS側になることです。CodexのBedrock providerでは、Bedrock API keyまたはAWS SDK credential chainを使います。ChatGPT sign-inや OPENAI_API_KEY を使う経路とは分けて考える必要があります。
3つ目は、Bedrock経由がOpenAI直接利用の完全な上位互換ではないことです。OpenAIのAmazon Bedrock向けガイドは、Bedrock availabilityはOpenAI APIと異なるため、supported model、AWS Region、feature set、pricing pathを確認してから使うよう求めています。
結果：Bedrock経由にする判断基準
単純な優劣ではなく、管理したい境界がAWS側かOpenAI側かで判断します。
Bedrock経由が合うケース
Bedrock経由が合うのは、AIコーディングの判断をAWSアカウント管理の延長で扱いたいチームです。たとえば、AWS Organizations、IAM Identity Center、CloudTrail、AWS Budgets、既存の請求タグやアカウント分離に合わせて、Codexのモデル利用を説明したい場合です。
OpenAI直接利用が合うケース
OpenAI直接利用が合うのは、最新のCodex機能、OpenAI側のhosted tools、広いfeature coverage、OpenAIの管理画面やChatGPTプランを優先したい場合です。公式ガイドでも、BedrockはAWS-native procurement、identity、regional controlsが必要な時に向き、OpenAI API直接利用は最新のfirst-party platform capabilitiesやBedrockで未提供の機能が必要な時に向く、という分け方が示されています。
判断基準
判断表にすると、最初の分岐はこうなります。
| 判断軸 | Bedrock経由が向く | OpenAI直接利用が向く |
|---|---|---|
| 調達と請求 | AWS契約、AWS commitments、AWS請求へ寄せたい | OpenAI APIやChatGPT側の契約で管理したい |
| 認証 | IAM、AWS SDK credential chain、Bedrock API keyを使いたい | OpenAI API keyやChatGPT sign-inを中心にしたい |
| Region | AWS Regionの選択と制約を運用に入れたい | OpenAI側の提供Regionや機能優先でよい |
| 機能 | ローカルCodex workflow中心でよい | Fast Mode、web search、画像生成などOpenAI側機能を重視する |
| 監査 | AWS側の統制に寄せたい | Codex/OpenAI側の管理機能で十分 |
この判断は、AIコーディングツール全体の費用判断ともつながります。プラン、従量課金、上限、チームの使い方を整理する時は、AIコーディングツール料金改定の見方の観点も役に立ちます。
Codex on Amazon Bedrockで何が変わるのか
- 1ローカルで作業
Codex CLIやCodex appのlocal workflowは手元の環境で動きます。
- 2Bedrockへ送信
モデルリクエストをAmazon Bedrockへ送ります。
- 3AWS管理面
認証、アクセス制御、Region、請求、アカウント管理をAWS側へ寄せられます。
- 4機能差の確認
Fast Mode、画像生成、音声入力、web searchなどはBedrock経由で使えない場合があります。
AWSで請求と認証をまとめたい理由なら筋が通りますが、Codexの全機能を同時に使いたい場合は別途確認が必要です。
ローカルCodexからBedrockへ送る
OpenAI公式ドキュメントの説明では、CodexをAmazon Bedrock providerに設定した場合、Codexはローカルで動き、モデルリクエストをBedrockへ送ります。Bedrockは、対応するOpenAIモデルに対してOpenAI-compatibleなResponses API実装を提供します。
AWS側の統制に寄せられる
この変更で大きいのは、モデル呼び出しの管理面です。AWS側の認証、アクセス制御、Region、請求、アカウント管理を使えるため、すでにAWS中心で開発基盤を運用しているチームでは説明しやすくなります。
注意点
一方で、Codexのすべての機能がそのままBedrock経由で使えるわけではありません。OpenAIのCodex Bedrock docsでは、local Codex workflowsは対象ですが、OpenAI-hosted cloud services、hosted tools、cloud-managed discoveryに依存する機能には未対応または制限があります。2026年6月12日時点で確認したfeature availabilityでは、Fast Mode、画像生成と編集、voice dictation、web searchはBedrock経由では利用不可とされています。Browser Use automationやChrome extension browser controlも、planやRegionによる制限があるものとして扱われています。
ここは導入判断の中心です。Bedrock経由にしたい理由が「AWSで請求と認証をまとめたい」なら筋が通ります。理由が「Codexのすべての新機能を同時に使いたい」なら、Bedrock経由だけに寄せる前に、OpenAI直接利用を残す設計を検討した方がよいです。
Bedrock経由とOpenAI直接利用を比較する
Bedrock経由は管理面をAWSへ寄せる選択であり、OpenAI直接利用の完全な上位互換ではありません。
Bedrock経由で得やすいもの
Bedrock経由で得やすいものは、AWS側の管理面です。AWS What's Newでは、GPT-5.5、GPT-5.4、CodexがAmazon Bedrockで一般提供され、CodexはCodex App、Codex CLI、Visual Studio Code、JetBrains、XcodeのIDE integrationから利用できると説明されています。AWS側は、同じsecurity、governance、operational controlsを使えること、pricingがOpenAI first-party ratesに一致し、usageが既存のAWS commitmentsにカウントされることも示しています。
ただし、この表現を「必ず安い」「必ず安全」と読み替えるのは危険です。AWS commitmentsにカウントされることは、すでにAWS利用額の契約を持つ企業には大きな意味があります。一方で、小さなチームでは、従量課金の上振れやmodel access、Region制限の管理コストの方が気になるかもしれません。
OpenAI直接利用で得やすいもの
OpenAI直接利用で得やすいものは、機能の広さと更新の速さです。OpenAI公式のAmazon Bedrock guideでも、OpenAI API直接利用は、broadest feature coverage、latest first-party platform capabilities、Bedrockで未提供の機能が必要な場合に向くとされています。
評価基準
比較時は、次のように「統制」と「機能」を分けて見ます。
| 項目 | Bedrock経由 | OpenAI直接利用 |
|---|---|---|
| モデル呼び出し | Amazon Bedrockへ送る | OpenAI hosted APIへ送る |
| 認証 | Bedrock API keyまたはAWS SDK credential chain | OpenAI API keyまたはChatGPT sign-in |
| 契約と請求 | AWS側に寄せやすい | OpenAI側に寄せやすい |
| Region | AWS Regionとmodel availabilityの確認が必要 | OpenAI側の提供条件を確認 |
| Codex機能 | local workflow中心、未対応機能あり | first-party機能を使いやすい |
| 導入負荷 | IAM、Region、model accessの確認が増える | OpenAI側の権限と利用上限の確認が中心 |
AWS認証とIAM境界を先に確認する
Bedrock経由にしても、IAMが広すぎれば使わせすぎになります。
認証経路を選ぶ
Codex on Bedrockでは、認証を2通りから選べます。OpenAI docsでは、CodexはBedrock API keyを先に確認し、次にAWS SDK credential chainを見ると説明されています。
Bedrock API keyを使う場合、Codexが読む環境に次のような変数を置きます。
export AWS_BEARER_TOKEN_BEDROCK="<your-bedrock-api-key>"
export AWS_REGION="us-east-2"AWS SDK credential chainを使う場合は、AWS CLIやSDKが参照するcredential sourceを使います。たとえばAWS SSO、環境変数、shared credentials file、instance profileなど、チームで既に使っている認証経路が候補になります。
Codex configでproviderを指定する
Codex側の設定は、公式のAdvanced Configurationに次の形で示されています。
model_provider = "amazon-bedrock"
model = "openai.gpt-5.5"
[model_providers.amazon-bedrock.aws]
profile = "default"
region = "us-east-2"設定の置き場所
profile を省略すると、Codexはstandard AWS credential chainを使います。region は、選んだモデルを扱えるBedrock Regionに合わせます。注意したいのは、providerやcredentialに関わる設定をプロジェクトローカルの .codex/config.toml に任せないことです。公式docsでは、project configはtrusted projectでのみ読み込まれ、model_provider や model_providers などcredentialやproviderに関わるキーはproject-local configからは上書きできないとされています。チーム共通のサンプルは用意しても、実際の認証先はユーザーまたは管理対象の設定に置く方が安全です。
確認項目
最初に確認する表は、これくらいで十分です。
| 実行主体 | credential source | AWS account | Region | model ID | 用途 | 承認者 |
|---|---|---|---|---|---|---|
| 開発者のローカル | SSO profile | sandbox | us-east-2 | openai.gpt-5.5 | 試験導入 | DevEx |
| CI | OIDCまたは専用role | dev | us-east-2 | openai.gpt-5.4 | lint補助、レビュー補助 | Platform |
| 本番関連作業 | 原則なし | production | 未設定 | 未設定 | 使わない | Security |
AIコーディング権限を法人導入の文脈で整理する場合は、法人導入前のAIコーディング権限設計のチェックリストも使えます。
Regionとmodel accessを確認する
Region選択は近さだけでなく、組織ポリシー、データ所在地、運用方針と合わせて確認します。
model IDとRegionを合わせる
OpenAI CodexのBedrock docsでは、対応モデルIDとして次の2つが示されています。
openai.gpt-5.5
openai.gpt-5.4ただし、model availabilityはAWS Regionによって変わります。OpenAI docsは、model support by AWS Regionを確認してから選ぶよう案内しています。AWS What's Newも、GPT-5.5とGPT-5.4のRegional availabilityはAWS Regions pageを見るよう案内しています。
この段階でやることは、モデルを使うかどうかの宣言ではなく、使えるRegionと使わせるRegionを一致させることです。たとえば、us-east-2 で動かす前提なのに、チームのAWS policyが別Regionを禁止しているなら、Codex設定の前にAWS側の方針確認が必要です。
読者側で確認するコマンド
読者側で確認する時は、まず自分がどのAWS identityで見えているかを確認します。
aws sts get-caller-identity
aws configure list次に、対象RegionでOpenAI providerのfoundation model一覧を確認します。AWS CLIのバージョンやBedrock側の提供状況で出力は変わるため、導入時は aws bedrock list-foundation-models help とAWS公式docsを合わせて確認してください。
aws bedrock list-foundation-models \
--region us-east-2 \
--by-provider OpenAI \
--query "modelSummaries[].{id:modelId,name:modelName}" \
--output table下振れリスク
ここで見たいのは、一覧に出るかどうかだけではありません。対象AWS accountでmodel accessが有効か、利用するRegionがチームのデータ所在地や運用方針と矛盾しないか、失敗時にOpenAI直接利用へ戻すのか、別Regionへ切り替えるのかまで決めておきます。
料金はBedrock pricingとして見積もる
価格表は固定値として覚えず、確認日とRegionを見積もり表へ残します。
token単位で見積もる
Bedrock経由のCodex利用は、ChatGPTの席数だけでは見積もれません。AWS Bedrock pricingのOpenAI欄を確認し、モデル、Region、input tokens、cached input tokens、output tokensを分けて見ます。
公開価格は確認日つきで扱う
2026年6月12日にAWS pricing pageで確認したOpenAI frontier modelsの例では、US EastのN. VirginiaとOhioでGPT-5.5が1M input tokensあたり5.50ドル、1M cached input tokensあたり0.55ドル、1M output tokensあたり33.00ドルと掲載されていました。同じ欄でGPT-5.4は1M input tokensあたり2.75ドル、1M cached input tokensあたり0.275ドル、1M output tokensあたり16.50ドルでした。US West OregonではGPT-5.4の価格が同じ金額で掲載され、GovCloud US-WestではGPT-5.4が1M input tokensあたり3.30ドル、1M cached input tokensあたり0.33ドル、1M output tokensあたり19.80ドルと掲載されていました。OpenAI modelsのglobal cross-region inference pricingはcoming soonという注記もありました。
この価格は記事内で固定値として覚えるものではありません。導入前にAWS pricing pageを再確認し、見積もり表へ「確認日」と「Region」を入れてください。
上振れ要因
見積もりでは、少なくとも次の列を分けます。
| 項目 | 例 | 見る理由 |
|---|---|---|
| 1タスクのinput tokens | 50,000 | 大きなコードベースやログで増える |
| 1タスクのoutput tokens | 8,000 | 説明、差分、テスト報告で増える |
| cached inputの効き方 | 要確認 | キャッシュ前提で過小見積もりしない |
| 1日のタスク数 | 20 | 個人利用とチーム利用で大きく変わる |
| 並列実行数 | 3 | subagent、review、CIで同時実行が増える |
| 月額上限 | 予算額 | AWS Budgetsやアラートに接続する |
| 異常検知の担当 | FinanceまたはDevEx | 誰が止めるかを先に決める |
AWS請求に寄ることで変わるもの
Bedrock経由にすると、費用の見え方は「1人いくら」から「どのaccountで何token使ったか」に寄ります。これは法人には便利ですが、上限を決めないまま広げると、チームの利用が増えた時に請求だけが先に伸びます。PoCでは、最初からAWS Budgets、Cost Explorer、タグ付け、アカウント分離、利用ログの見方を決めておくのが現実的です。
機能差とfeature gapsを潰す
ツール名ではなく、チームの作業単位で使えるか、代替案があるかを確認します。
Codex側のfeature availabilityを見る
Bedrock経由の検討で一番危ないのは、認証だけを見て「同じCodexだから同じ機能が使える」と思い込むことです。
OpenAI Codex Bedrock docsのfeature availabilityでは、local Codex workflowsとしてCodex app for local tasks、Codex CLI、IDE extension、Codex SDK、codex exec、scriptable workflowsなどが示されています。一方で、Fast Mode、image generation and editing、voice dictation、web searchはBedrock経由では利用不可とされています。Browser Use automationやChrome extension browser controlはLimited扱いです。
この差分は、日常の作業に直接効きます。たとえば、web searchを使って依存パッケージの最新docsを調べながら修正する運用をしているなら、Bedrock経由だけでは同じ手順にならない可能性があります。画像生成を含むフロントエンド素材作成や、Fast Mode前提の高頻度タスクも同じです。
作業単位で差分を確認する
feature gapを確認する時は、ツール名ではなく「チームの作業単位」で表にします。
| 作業 | Bedrock経由で必要な機能 | 使えるか | 代替案 |
|---|---|---|---|
| ローカルコードレビュー | /review、repo read、diff確認 | 公式表で確認 | OpenAI直接利用も残す |
| CIの軽い修正案作成 | codex exec、scriptable workflow | 公式表で確認 | 小さな権限roleで試す |
| 依存更新の調査 | web search、外部docs参照 | 要注意 | allowlist付きnetwork accessや人間の調査 |
| ブラウザ操作 | Browser Use、Chrome extension | Limitedを確認 | Playwright MCPや手動確認 |
| デザイン素材作成 | image generation | Bedrock経由では不可 | OpenAI直接利用または別ツール |
注意点
Codexに外部通信を許可する話は、Bedrock providerとは別の権限です。MCPやweb search、外部API通信まで含める場合は、Codexにインターネットアクセスを許可する前にのように、network allowlistとモデルproviderを分けて考えてください。
導入前の確認手順
- 1. 公式docs
Bedrock provider、supported model IDs、feature availabilityを確認します。
- 2. 料金
対象RegionのAWS Bedrock pricingを確認します。
- 3. AWS identity
identity、account、Region、model accessを確認します。
- 4. Codex設定
`amazon-bedrock` providerを設定し、`/status` で確認します。
- 5. 最初のタスク
read-onlyのコード説明か小さなローカルレビューから始めます。
- 6. 記録
請求、ログ、失敗理由、OpenAI直接利用との差分を残します。
最初の成功だけでなく、失敗時にどこを見るかまで用意してから試します。
ローカルとCLIの状態を確認する
PoCの最初に見るのは、派手な自動化ではなく、ローカルのCodexとAWSの基本状態です。今回の執筆時には、筆者環境で次のバージョンだけを確認しました。
codex --version
npm view @openai/codex version
aws --version確認結果は、codex-cli 0.139.0、@openai/codex 0.139.0、aws-cli/2.17.54 でした。AWS accountでBedrock model accessや実課金を伴う疎通は行っていません。
AWS accountとmodel accessを確認する
読者側で実際に試す時は、次の順番にします。
- 公式docsでCodexのBedrock provider、supported model IDs、feature availabilityを確認する。
- AWS pricing pageで対象RegionのOpenAI pricingを確認する。
- AWS identityとaccountを確認する。
- 対象Regionでmodel accessを確認する。
~/.codex/config.tomlにamazon-bedrockproviderを設定する。- Codex CLIの
/statusでmodel providerがamazon-bedrockになっているか確認する。 - 最初のタスクは、read-onlyのコード説明か小さなローカルレビューにする。
- 請求、ログ、失敗理由を記録し、OpenAI直接利用との差分を残す。
失敗時の切り分け
失敗した時の切り分けも先に用意します。
| 症状 | まず見る場所 |
|---|---|
| モデルが見つからない | model ID、Region availability、model access |
| 認証に失敗する | AWS_BEARER_TOKEN_BEDROCK、AWS profile、SSO session、有効期限 |
| desktop appやIDEで動かない | ~/.codex/.env に必要な環境変数があるか |
| OpenAI直接利用では動く機能が使えない | feature availability表 |
| 請求が想定より大きい | output tokens、並列実行、キャッシュ前提、失敗再実行 |
失敗点とハマりどころ
統制の置き場所がAWS側へ寄るだけで、権限設計は別に必要です。
モデルIDがあっても、使いたいaccountとRegionで利用できるとは限りません。
Bedrock pricingはtoken単位で、探索、ログ読み、再試行でも増えます。
provider差、Region差、認証差、feature availability差を分けて残します。
再実行や大量PRでtoken消費が読みづらいため、限定roleから始めます。
PoCで見るべきなのはベンチマークだけでなく、失敗時の説明可能性です。
失敗パターンを先に潰す
1. 統制の置き場所を誤解する
1つ目の失敗点は、Bedrock経由を「セキュリティが強い設定」とだけ捉えることです。実際には、統制の置き場所がOpenAI側からAWS側へ寄ります。IAMが広すぎれば、Bedrock経由でも使わせすぎになります。
2. Regionとmodel accessを後回しにする
2つ目は、Regionとmodel accessを後回しにすることです。モデルIDが公式docsに載っていても、使いたいAWS accountとRegionで利用できるとは限りません。PoCで最初に見るべきなのは、ベンチマーク結果よりも、対象Regionで本当に使えるかです。
3. 料金を席数だけで見る
3つ目は、料金をChatGPTプランの感覚で見積もることです。Bedrock pricingはtoken単位です。AIコーディングエージェントは、差分生成だけでなく、探索、ログ読み、テスト失敗の再試行、長い説明でtokenを使います。subagentや並列レビューを組み合わせると、短時間で増えます。
4. feature gapをCodexの品質問題にする
4つ目は、OpenAI直接利用との差分を記録しないことです。Bedrock経由で一部機能が使えない場合、チームは「Codexが弱い」と誤解しがちです。provider差、Region差、認証差、feature availability差を分けて記録してください。
5. CIにすぐ入れる
5つ目は、CIにすぐ入れることです。CIからBedrockへ投げると、失敗再実行や大量PRでtoken消費が読みづらくなります。最初は人間のローカル操作、次に限定roleのCI、最後に自動化という順番が安全です。
実務で使うなら
- 準備
AWS account、Region、model access、Codex設定、予算上限を確認します。
- read-only説明
対象repoを読ませても秘密情報を出さず、説明が妥当かを見ます。
- 小さなレビュー
差分と指摘が追えるか、local workflowとして使えるかを確認します。
- 失敗ログ
失敗理由、再実行回数、token消費、請求見積もりを残します。
- 導入判断
Security、DevEx、Finance、現場レビュアーが同じ表で判断します。
Bedrockへ寄せるか、OpenAI直接利用を残すかは、品質だけでなく運用の列も見て決めます。
最小PoCの進め方
実務導入では、いきなり全員のCodexをBedrock経由に変えない方がよいです。最初は1週間の小さなPoCで、対象タスクと失敗条件を絞ります。
おすすめの最小PoCは、次の3本です。
| タスク | 目的 | 合格条件 |
|---|---|---|
| read-onlyコード説明 | モデル経路と認証の確認 | 対象repoを読ませても秘密情報を出さず、説明が妥当 |
| 小さなローカルレビュー | Codex local workflowの確認 | /review 相当の作業で差分と指摘が追える |
| 失敗ログの切り分け | token消費と再試行の確認 | 失敗理由、再実行回数、請求見積もりが残る |
レビュー表と更新通知
PoCのレビュー表には、品質だけでなく、運用の列を入れます。
| 評価項目 | 見る内容 |
|---|---|
| 初速 | 設定から最初の成功までに詰まった点 |
| コード理解 | repo構造、既存ルール、AGENTS.mdを読めたか |
| 変更品質 | 差分が小さく、レビューしやすいか |
| 機能差 | OpenAI直接利用と比べて困った点 |
| 料金 | 1タスクあたりのtokenと概算コスト |
| 権限 | IAM、AWS account、Regionが適切に分かれているか |
| 監査 | 誰が何を実行し、どう止めるかが残るか |
記事や検証ログの更新通知を受け取りたい場合は、AI Dev Lab Japanのニュースレターも使えます。Bedrock pricingやCodex feature availabilityのように変わりやすいテーマは、公開時点の情報だけでなく、後から見直す前提で追うのが大事です。
チーム導入相談の置き方
チーム導入で相談が必要な場合は、AWS側の権限設計、Codex設定、MCP、レビューゲート、費用上限を1枚の表にまとめるところから始めるのが現実的です。Bedrockへ寄せるべきか、OpenAI直接利用を残すべきかは、セキュリティ部門、DevEx、Finance、現場レビュアーが同じ表を見て決める方が失敗しにくいです。
セキュリティ・コスト注意
Bedrockだから安全、OpenAI直接だから危険、という単純な勝敗ではなく、入力データ、権限、ログ、承認、請求上限を設計します。
情報管理ルールは別に残す
Bedrock経由にしても、社内コード、API key、顧客情報、非公開リポジトリ情報を無制限に扱わせてよいわけではありません。モデルproviderの変更は、情報管理ルールの代替ではありません。
最低限の運用ルール
最低限、次のルールを決めてから試します。
- production accountでは開始しない。
- 最初はread-onlyの作業に限定する。
- Bedrock API keyを使う場合は、有効期限、保管場所、ローテーション、失効手順を決める。
- AWS SDK credential chainを使う場合は、shared profileの使い回しを避ける。
- Codexの承認モード、sandbox、file write権限を別途確認する。
- MCP、browser、web search、外部API通信は、Bedrock providerとは別の許可として扱う。
- 月額上限、アラート、停止担当者を決める。
- 価格表の確認日とRegionを見積もり表に残す。
コストの止め方
コスト面では、Bedrock経由にするとAWSの既存請求に統合しやすくなります。これは便利ですが、AIコーディングの使いすぎが通常のAWS費用に埋もれる危険もあります。PoC段階から、account、tag、project、user、task typeで分けて見えるようにしておくと、あとで説明しやすくなります。
セキュリティ表現の注意
セキュリティ面では、Bedrockだから安全、OpenAI直接だから危険、という単純な話にしない方がよいです。どちらも、入力するデータ、権限、ログ、承認、ネットワーク経路、請求上限を設計しなければ事故ります。違うのは、どの管理面でそれを運用するかです。
FAQ
FAQは、認証、Region、機能、CI化を同じ話に混ぜないための確認表です。
Bedrock経由ならOpenAI API keyはいらないのですか？
CodexのBedrock providerでは、OpenAI API keyではなく、Bedrock API keyまたはAWS SDK credential chainを使います。OpenAI docsは、ChatGPT sign-inや OPENAI_API_KEY はこのproviderの認証に使わないと説明しています。ただし、OpenAI直接利用を併用する場合は、そちらの認証管理が別に必要です。
openai.gpt-5.5 と openai.gpt-5.4 以外も使えますか？
CodexのBedrock docsでsupported model IDsとして示されているのは、2026年6月12日時点では openai.gpt-5.5 と openai.gpt-5.4 です。AWSのOpenAI model docsにはgpt-oss系のOpenAI modelsもありますが、Codex providerのsupported model IDsとは分けて確認してください。
Regionを選べばデータ所在地の要件は満たせますか？
Region選択は重要ですが、それだけで法務やコンプライアンス要件を満たすとは断定できません。AWS Regionのmodel availability、組織のクラウド利用ルール、ログ、請求、アクセス権、データ分類を合わせて確認します。
Bedrock経由ならCodexの最新機能も全部使えますか？
使えません。OpenAI docsのfeature availabilityでは、Fast Mode、image generation and editing、voice dictation、web searchなどがBedrock経由では利用不可とされています。導入前に、普段の作業がそれらに依存していないか確認してください。
最初からCIに入れてよいですか？
おすすめしません。CIは再実行や大量PRでtoken消費が増えやすく、失敗時の権限切り分けも難しくなります。まずローカルのread-onlyタスクでprovider、Region、model access、料金の見え方を確認し、その後に限定roleのCIで小さく試す方が安全です。
次に読むなら
更新履歴
- 2026年6月12日
OpenAI Codex with Amazon Bedrock docs、Amazon Bedrock API guide、Codex changelog、AWS Bedrock pricingを確認して初版を作成しました。
- ローカル確認
`codex-cli 0.139.0`、`@openai/codex 0.139.0`、`aws-cli/2.17.54` を確認しました。
- 未実施
AWS accountでのBedrock model access、IAM権限、実課金を伴う疎通は未実施です。
- 導入前
価格、Region availability、supported model IDs、feature availabilityを公式docsで再確認します。
この記事の数字や提供状況は、導入時点の公式情報で更新してから使います。
- 2026年6月12日：OpenAI Codex with Amazon Bedrock docs、OpenAI Amazon Bedrock API guide、OpenAI Codex changelog、AWS What's New、AWS Bedrock pricing、AWS OpenAI model docsを確認して初版を作成しました。
- 2026年6月12日：ローカルでは
codex-cli 0.139.0、@openai/codex 0.139.0、aws-cli/2.17.54を確認しました。AWS accountでのBedrock model access、IAM権限、実課金を伴う疎通は未実施です。 - 価格、Region availability、supported model IDs、feature availabilityは変わる可能性があります。導入前に公式docsとpricing pageを再確認してください。
参照した主な情報源
- OpenAI Codex: Use Codex with Amazon Bedrock: https://developers.openai.com/codex/amazon-bedrock
- OpenAI API docs: OpenAI models in Amazon Bedrock: https://developers.openai.com/api/docs/guides/amazon-bedrock
- OpenAI Codex changelog: https://developers.openai.com/codex/changelog
- OpenAI Codex Advanced Configuration: https://developers.openai.com/codex/config-advanced
- AWS What's New: GPT-5.5, GPT-5.4, and Codex from OpenAI are now generally available on Amazon Bedrock: https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-bedrock-openai-models-codex-generally-available/
- AWS Amazon Bedrock pricing: https://aws.amazon.com/bedrock/pricing/
- AWS docs: OpenAI models in Amazon Bedrock: https://docs.aws.amazon.com/bedrock/latest/userguide/model-parameters-openai.html