3行まとめ
`model_provider`や`base_url`の変更は、コードとプロンプトを送る経路の変更です。
custom providerは`base_url`、`env_key`、`wire_api`などを定義できますが、project local configだけではproviderを固定できません。
APIキー、プロキシログ、費用配賦、切り戻し、sandboxやMCPとの責任範囲を先に決めます。
モデル選びではなく、送信経路と責任範囲の設計として扱うのが安全です。
Codex CLI/IDEでmodel_providerやbase_urlを変える作業は、モデル選びというより「コードとプロンプトをどの経路へ送るか」を変える作業です。
2026年6月16日にOpenAI公式Docsを確認した範囲では、custom model providerはbase_url、env_key、wire_api、追加ヘッダー、認証コマンドを設定できます。一方で、project local configだけではmodel_providerやmodel_providersを上書きできません。
チーム導入では、接続先より先にAPIキーの所有者、プロキシログの閲覧者、費用配賦、切り戻し手順、sandbox/approval/MCPとの責任範囲を決めるのが安全です。
この記事でわかること
OpenAI互換API、Azure OpenAI、OpenRouter、社内LLMプロキシを使う条件を確認します。
`model_provider`、`model_providers`、`base_url`、`env_key`、`wire_api`をどのレイヤーで管理するかを分けます。
APIキーの所有者、プロキシログの閲覧者、保存期間、データ保持を確認します。
sandbox、approval、MCP権限を、モデル接続先とは別の安全装置として見ます。
需要シグナルではなく、公式情報と運用上の確認項目を軸に判断します。
- Codexのcustom model providerで何を設定できるか
base_url差し替えを、モデル比較ではなくデータ経路として見る理由- ユーザー設定とプロジェクト設定で管理できる範囲の違い
- OpenAI互換API、provider直結、LLMプロキシ経由を選ぶ前の確認項目
- APIキー、認証コマンド、ログ、費用上限、切り戻しの設計ポイント
- sandbox、approval、MCP権限を
model_provider設定と混同しないための分け方
直近のX/Twitter検索では、複数のAI Codingツールを共通の入口で扱う話題や、Codexを別プロバイダへ接続する話題が見えていました。ただし、Xの投稿本文はログインなしでは安定して検証できないため、この記事では需要シグナルとしてだけ扱います。技術的な根拠は、OpenAI、OpenRouter、Microsoftの公式情報に限定します。
前提知識：接続先・ローカル実行・MCPを分ける
`base_url`を変えても、外部providerやLLMプロキシのデータ取り扱いは別に確認が必要です。
Codexは、ローカルのCLIやIDE拡張からモデルへリクエストを送り、選択した作業ディレクトリのコードを読んだり変更したりするAIコーディングエージェントです。OpenAI公式Docsでは、CLIとIDE拡張は設定レイヤーを共有し、~/.codex/config.tomlや信頼済みプロジェクトの.codex/config.tomlを使って動作を調整できると説明されています。
ここで混同しやすいのが、次の3つです。
- モデル接続先: どのAPI endpointへプロンプトやコード断片を送るか
- ローカル実行権限: Codexがどのファイルを編集し、どのコマンドを実行できるか
- 外部ツール権限: MCP serverなどを通じて、GitHub、ブラウザ、DB、社内SaaSへ何ができるか
base_urlを変えるのは、1つ目の「モデル接続先」を変える操作です。sandboxやapprovalを強くしても、外部providerやLLMプロキシへ送ったプロンプトの保存、閲覧、削除、学習利用の扱いまでは自動では決まりません。
なお、この記事は2026年6月16日にCodex CLI 0.140.0でcodex --versionを確認し、同日に公式Docsを読み直して書いています。料金、モデル名、provider固有の互換性は変わりやすいため、具体的な価格表の転載ではなく、確認すべき判断項目に絞ります。
結果：base_url差し替えは経路設計から始める
- 1開発者がCodexへ依頼する
作業依頼と対象リポジトリの文脈がCodexに渡ります。
- 2Codexが文脈を持つ
コード、エラー、差分、実行結果などがリクエストの材料になります。
- 3`model_provider`が接続先を選ぶ
`base_url`、wire API、認証、追加HTTPヘッダーの定義に沿って送信先が決まります。
- 4providerまたはLLMプロキシが処理する
認証、ログ、モデル選択、課金、レート制限がこの層に入ります。
- 5Codexへレスポンスが戻る
ローカルの編集やコマンド実行は、sandboxやapprovalで別に管理します。
経路の3と4が`base_url`差し替えで変わり、ローカル実行やMCP権限は別の台帳で管理します。
最初の結論はシンプルです。チームでCodexのcustom model providerやOpenAI互換APIを使うなら、設定値を配る前に「どのデータが、誰の管理する経路を通るか」を書き出してください。
OpenAI公式DocsのAdvanced Configurationでは、custom model providerはCodexがモデルへ接続するための定義として説明されています。そこにはbase_url、wire API、認証、追加HTTPヘッダーなどが含まれます。つまり、model = "..."だけを変える話ではありません。接続先、認証方法、リクエストの通し方をまとめて変える話です。
model_providerとmodel_providersで何を切り替えるのか
Codexのcustom provider設定では、概念として次の要素を分けて見ます。
確認項目
| 項目 | 何を決めるか | チームで確認すること |
|---|---|---|
model_provider | どのprovider定義を使うか | 開発者ごとに変えてよいか、チーム標準にするか |
[model_providers.<id>] | providerの接続情報 | 管理者、変更手順、レビュー手順 |
base_url | APIの送信先 | 直結か、外部providerか、社内プロキシか |
env_key | APIキーを読む環境変数 | 発行者、失効方法、漏えい時の影響範囲 |
wire_api | Codexとprovider間のAPI形式 | Responses APIか、provider側で互換性があるか |
http_headers / env_http_headers | 追加ヘッダー | 固定値に秘密情報を入れていないか |
auth.command | token取得コマンド | 実行権限、出力、失敗時の扱い |
OpenAI公式Docsでは、custom providerは予約済みのbuilt-in provider IDを再利用できないと説明されています。openai、ollama、lmstudioのような予約済みIDに似せて上書きするのではなく、company_proxyやteam_gatewayのように、管理主体がわかるIDにした方が事故が減ります。
設定値より先にデータ経路を書く
設定レビューでは、次のような経路図を文章で説明できる状態にします。
評価基準
- 開発者がCodexへ依頼する
- Codexが必要なコード、エラー、差分、実行結果を文脈として持つ
model_providerで選ばれた接続先へリクエストが送られる- providerまたはLLMプロキシが認証、ログ、モデル選択、課金、レート制限を処理する
- レスポンスがCodexへ戻り、Codexがローカルで編集やコマンド実行を提案する
このうち、3と4がbase_url差し替えで変わる部分です。5のローカル実行権限は、sandboxやapprovalで別に管理します。MCP serverで外部SaaSを触る場合は、さらに別の権限台帳が必要です。
Codexの設定レイヤーで守れる範囲と守れない範囲
プロジェクト単位で標準化しやすいものと、ユーザー設定側で管理すべきものを分けます。
チームでよくある誤解は、「プロジェクトに.codex/config.tomlを置けば、全員の接続先を固定できる」というものです。2026年6月16日に確認したOpenAI Codex Configuration Referenceでは、project-scoped configが読み込まれるのは信頼済みプロジェクトの場合であり、さらにproject-local configでは上書きできないキーがあると説明されています。
その制限の中に、model_providerとmodel_providersが含まれます。ここはかなり重要です。
project local configだけでproviderを固定しない
プロジェクト配下の.codex/config.tomlは便利ですが、provider設定の統制には限界があります。モデル接続先のようなmachine-local providerやauthに近い設定は、ユーザー設定側で管理する前提に寄せられています。
条件
チームで接続先をそろえたいなら、次を組み合わせます。
- オンボーディング手順で
~/.codex/config.tomlの置き方を明示する - provider ID、環境変数名、切り戻し手順を社内テンプレート化する
- APIキーは個人発行かチーム発行かを決める
- 端末管理やsecret managerで環境変数の配布と失効を扱う
- CIやレビューで、プロジェクト内に危険なサンプル設定が混ざっていないか見る
.codexはプロジェクトルールの置き場として使えますが、providerの最終統制をそこへ丸投げしない方が安全です。
プロジェクトで標準化しやすいものを別に持つ
provider接続先とは別に、プロジェクト単位で標準化しやすいものがあります。
確認項目
| 領域 | プロジェクト側で決めやすいこと | provider設定と分ける理由 |
|---|---|---|
| AGENTS.md | テスト手順、禁止操作、レビュー基準 | モデル接続先に関係なく守る作業ルール |
| sandbox/approval | どこまで自動実行するか | ローカル操作の境界であり、送信先ログの境界ではない |
| MCP | 使ってよいserver、scope、owner | 外部SaaS権限はproviderとは別に漏えい面がある |
| テスト | 変更後に必ず走らせるコマンド | provider変更では品質保証にならない |
| 監査 | 実行ログ、承認ログ、PR証跡 | LLMプロキシログだけでは作業全体を追えない |
この切り分けをしておくと、「モデルは変えたが、承認フローは同じ」「MCP serverを増やしたので、providerとは別に権限レビューが必要」のように会話できます。
OpenAI互換APIとLLMプロキシを選ぶ前の比較軸
セキュリティや運用要件が絡むため、単純な勝敗ではなく条件差として比較します。
OpenAI互換APIやLLMプロキシは、うまく設計すれば便利です。モデル選択、予算、ログ、provider failover、チーム単位のキー管理を集約できる場合があります。OpenRouterのCodex CLI向けDocsでも、Codex用の設定例に加えて、組織の予算管理や利用可視化といったprovider側の利点が説明されています。
ただし、これは「どのproviderを使っても安全」という意味ではありません。便利になる場所と、監査対象が増える場所を分けて見ます。
3つの構成で変わるもの
比較軸
| 構成 | 向いている場面 | 注意点 |
|---|---|---|
| OpenAI直結 | まずCodex標準の挙動で試す | ChatGPT sign-inかAPI keyかで管理者制御とデータ取り扱いが変わる |
| provider直結 | Azure OpenAIやOpenRouterなど、公式設定例がある接続先を試す | provider側の認証、対応API、請求、ログ保存を別途確認する |
| LLMプロキシ経由 | チームのモデル選択、コスト上限、監査ログを集約したい | プロキシがコードやプロンプトを保存する可能性、障害点、権限集中を設計する |
Azure OpenAIのCodex向けMicrosoft Learnでは、model_provider = "azure"、Azureのbase_url、AZURE_OPENAI_API_KEYを参照するenv_key、wire_api = "responses"の例が示されています。トラブルシューティングでは、env_keyにAPIキー文字列を直接書くのではなく、環境変数名を指す必要がある点も説明されています。
このようなprovider側の公式例は、設定の形を理解するには有用です。ただし、providerの品質比較や料金比較へ短絡せず、自社のデータ管理要件に合うかを見る方が実務では大事です。
APIキーを渡す相手を最初に決める
env_keyは、APIキーの値そのものではなく、キーを入れた環境変数名を指します。ここを雑に扱うと、設定ファイルに秘密情報が残ったり、退職者のキーが使われ続けたり、誰の請求なのかわからなくなったりします。
確認項目
導入前に、最低限次を決めます。
- APIキーは個人ごとに発行するか、チーム単位で発行するか
- 漏えい時に誰が失効できるか
- 退職、異動、外部委託終了時の無効化手順はあるか
- APIキー利用は個人実験、通常開発、CI、自動投稿などで分けるか
- LLMプロキシを使う場合、プロキシの管理者は元providerのAPIキーを閲覧できるか
- 認証コマンドを使う場合、そのコマンドはどのcredential helperからtokenを取るか
OpenAI Codex Authenticationでは、OpenAIモデル利用時にChatGPT sign-inとAPI key sign-inの2つがあり、どちらを使うかで適用される管理者制御やデータ取り扱いが変わると説明されています。API key利用はローカルCodex workflowやCI/CDのようなプログラム実行に向いている一方、信頼できない公開環境にCodex実行を露出しないよう注意されています。
sandbox、approval、MCP権限とは責任範囲を分ける
何をどのモデル接続先へ送るかを決めます。
ログ粒度、マスキング、閲覧者、保存期間、課金、レート制限を確認します。
ローカルで何を読めるか、書けるか、どの操作で人間の承認を求めるかを制御します。
GitHub、Slack、DB、社内APIなど外部機能へのscope、token保管、tool allowlistを管理します。
信頼できるproviderを使っていても、ローカル実行やMCPの権限レビューは別に必要です。
base_urlを変えたあとに、もう1つ見落としやすいのが安全装置の責任範囲です。sandbox、approval、MCP、LLMプロキシは、それぞれ守る対象が違います。
モデル接続先は「何を送るか」の問題
モデルproviderの設定でまず見るのは、送信される情報です。
送信対象
- 指示文
- 対象ファイルの抜粋
- エラーやテストログ
- 差分
- 実行計画
- ユーザーの追加入力
- 場合によってはtool callや実行結果の要約
LLMプロキシが間に入るなら、プロキシ側でこれらがどの粒度で記録されるかを確認します。全文ログか、metadataだけか、マスキングされるか、管理者が閲覧できるか、保存期間はどれくらいか。ここを確認せずに「プロキシでコストが見えるから便利」とだけ考えると、コードレビューより前にセキュリティレビューで止まります。
sandbox/approvalは「ローカルで何を実行できるか」の問題
OpenAI Codexのapprovals/securityとsandboxingのDocsでは、sandbox modeとapproval policyは別の層として説明されています。sandbox modeは技術的に何ができるか、approval policyはどの操作で人間の承認を求めるかです。
注意点
たとえばworkspace-writeなら、Codexは作業ディレクトリ内で読み書きし、ローカルコマンドを実行できますが、境界外の編集やネットワークアクセスには承認が必要になる構成があります。read-onlyなら調査中心にできます。danger-full-accessは制限が外れるため、隔離された環境で必要性が説明できる場合にだけ使うべきです。
重要なのは、sandboxを強くしても、モデルproviderへ送ったプロンプトやコード断片の扱いは別問題だということです。逆に、信頼できるproviderを使っていても、ローカルで危険なコマンドを自動実行してよいことにはなりません。
MCPは「どの外部機能を呼べるか」の問題
MCP serverは、モデル接続先とは別の外部権限です。GitHub、Google Drive、Slack、DB、ブラウザ、社内APIなどに接続するMCP serverがあれば、provider設定とは別にscope、token保管、tool allowlist、監査ログを見ます。
この点は、既存記事の<a href="https://ai-dev.blog.mo-gmo.com/mcp-tools-resources-prompts-permission-design/">MCPとは何か：Tools・Resources・Promptsと権限設計</a>でも扱っています。Codexのprovider設定を変える時も、MCPの権限台帳は別に保つのが現実的です。
base_url、sandbox、MCPを同じ表で管理するなら、列を分けてください。
| 観点 | 管理するもの | 代表的な事故 |
|---|---|---|
base_url / provider | モデル送信先、認証、ログ | 機密コードが想定外のproviderやプロキシに残る |
| sandbox/approval | ローカル編集、コマンド、ネットワーク | 破壊的コマンドや外部通信が自動実行される |
| MCP | 外部SaaSやDBの操作 | read-onlyのつもりが書き込みscopeを渡す |
CodexのネットワークアクセスやMCP通信の扱いは、<a href="https://ai-dev.blog.mo-gmo.com/codex-network-access-allowlist-web-search-mcp-security/">Codexの外部通信、allowlist、web search、MCP通信の分け方</a>も合わせて読むと整理しやすいです。
設定例：安全に見せる最小のconfig.toml
管理主体がわかるprovider IDを使い、予約済みbuilt-in IDに似せた上書きを避けます。
社内URLや本番proxy名を不用意に公開せず、送信先としてレビューします。
APIキー文字列ではなく、キーを入れた環境変数名を参照します。
Codexが期待するAPI形式に合うかをprovider側の公式例で確認します。
接続障害や互換性問題に備えて、戻し先と確認手順を同じ場所に置きます。
認証コマンドを使う場合も、便利さよりcredential helperの管理責任を先に決めます。
ここでは、設定の「形」だけを示します。実在のAPIキー、社内URL、本番proxy名は入れません。
# ~/.codex/config.toml
model = "gpt-5-codex"
model_provider = "team_proxy"
[model_providers.team_proxy]
name = "Team LLM Proxy"
base_url = "https://llm-proxy.invalid/v1"
env_key = "TEAM_LLM_PROXY_API_KEY"
wire_api = "responses"
request_max_retries = 2
stream_idle_timeout_ms = 300000この例で確認したいのは、モデル名よりも管理点です。
team_proxyというIDを誰が命名し、誰が変更できるかbase_urlが社内プロキシなのか、外部providerなのかTEAM_LLM_PROXY_API_KEYを誰が発行し、どこで失効するかwire_api = "responses"が接続先で本当にサポートされるか- retryやtimeoutが過剰な再試行コストを生まないか
認証コマンドを使う場合
OpenAI公式Docsでは、providerが外部credential helperからbearer tokenを取る必要がある場合に、command-backed authenticationを使う例も示されています。これを使う場合は、便利さよりも運用管理が先です。
[model_providers.team_proxy]
name = "Team LLM Proxy"
base_url = "https://llm-proxy.invalid/v1"
wire_api = "responses"
[model_providers.team_proxy.auth]
command = "/usr/local/bin/fetch-codex-token"
args = ["--audience", "codex"]
timeout_ms = 5000
refresh_interval_ms = 300000認証コマンドは、誰の権限で実行されるか、どのcredential storeを読むか、失敗時にどんなエラーを返すかを確認します。stdoutにtoken以外の余計なログを出す設計も避けます。
切り戻し手順を同じ場所に置く
設定例を配るなら、切り戻し手順も同じドキュメントに置きます。
model_providerを元のproviderへ戻す- 新しい環境変数をshell profileやsecret managerから外す
- LLMプロキシ側のAPIキーを無効化する
- 直近のリクエストログに機密情報が含まれていないか確認する
- 影響があったrepository、ユーザー、時間帯を記録する
切り戻しが説明できない設定は、チーム標準にするにはまだ早いです。
失敗点とハマりどころ
wire API、streaming、tool calling、reasoning関連の挙動、エラー形式まで確認します。
project-local configには上書きできないキーがあるため、ユーザー設定や端末管理も必要です。
ローカルコマンド、ファイル編集、人間承認、MCP呼び出しは別ログとの突合が必要です。
API単価だけでなく、修正回数、レビュー工数、再試行、プロンプト長を含めて見ます。
provider接続の問題とローカル実行権限の問題を分け、`read-only`や`workspace-write`で切り分けます。
接続できたかどうかより、実務コードで説明できる状態になっているかを確認します。
1. 「OpenAI互換」だけでCodex互換だと思う
OpenAI互換APIと書かれていても、Codexが期待するwire API、streaming、tool calling、reasoning関連の挙動、エラー形式、長時間接続の扱いまで同じとは限りません。Provider側のCodex向け公式Docsがある場合は、その手順を優先して確認します。
2. project .codex/config.tomlでproviderを統制できると思う
前述の通り、project-local configには上書きできないキーがあります。チーム標準のproviderを使わせたいなら、ユーザー設定、端末管理、オンボーディング、監査の組み合わせで設計します。
3. LLMプロキシのログを「監査ログ」と呼びすぎる
プロキシログは便利ですが、Codexの作業全体を説明するには足りません。ローカルでどのコマンドを実行したか、どのファイルを編集したか、人間がどこで承認したか、MCPでどの外部APIを呼んだかは、別のログと突合する必要があります。
4. 安いモデルへ変えて総コストが上がる
単価が低いモデルへ切り替えても、修正回数、レビュー工数、テスト失敗、再試行、プロンプト長が増えれば総コストは上がります。AIコーディングのコストは、API料金だけでなく、人間のレビュー時間とやり直し回数まで含めて見ます。
5. danger-full-accessをprovider検証の近道にする
Provider接続の問題と、ローカル実行権限の問題は別です。接続確認のためにsandboxを外す必要が本当にあるのか、先にread-onlyやworkspace-writeで切り分けます。
実務で使うなら
- Phase 0：個人のダミーリポジトリ
機密コードを含まない小さなリポジトリで、接続、認証、ログ、切り戻しを確認します。
- Phase 1：read-onlyの実務タスク
PR要約、エラーログ説明、設計メモレビューなど、自動編集やMCP writeを入れない範囲に限定します。
- Phase 2：限定編集
小さなbugfix、ドキュメント更新、テスト修正に絞り、sandboxとapprovalを組み合わせます。
- Phase 3：チーム標準
provider、APIキー、プロキシログ、費用配賦、MCP、切り戻しのownerを決めます。
ownerが決まらないままLLMプロキシだけ入れると、事故時に説明しにくい構成になります。
Phase 0：個人のダミーリポジトリで試す
最初は、機密コードを含まない小さなリポジトリで試します。ここでは、モデル品質ではなく接続、認証、ログ、切り戻しを確認します。
codex --versionを記録する- provider公式Docsの手順を読む
- ダミーの
base_urlではなく、検証用providerの正式endpointを使う - APIキーは検証専用に発行する
- ログ保存と削除方法を確認する
- 失敗時に元設定へ戻せるか試す
Phase 1：read-onlyの実務タスクに限定する
次に、実務コードでもread-onlyに近いタスクへ限定します。たとえば、PRの要約、エラーログの説明、設計メモのレビューです。まだ自動編集やMCP writeは入れません。
この段階で見るのは、回答品質だけではありません。
- 送信されるコード量は想定内か
- プロキシやproviderのログに何が残るか
- レート制限やtimeoutで作業が止まらないか
- 失敗時のエラーが開発者に理解できるか
- 請求や利用量をプロジェクト別に追えるか
Phase 2：限定編集へ進む
read-onlyで問題が見えたら、次は限定編集です。対象を小さなbugfix、ドキュメント更新、テスト修正に絞り、sandboxとapprovalをworkspace-write、on-request相当の運用で始めます。
ここで必要になるのは、provider設定よりも作業ルールです。AGENTS.mdに、禁止操作、テスト手順、レビュー観点、外部通信の扱いを書きます。AIコーディング権限全体の整理は、<a href="https://ai-dev.blog.mo-gmo.com/enterprise-ai-coding-permission-design-api-keys-private-repos-human-approval/">法人導入前のAIコーディング権限設計</a>も参考になります。
Phase 3：チーム標準にする前に責任者を置く
チーム標準へ進むなら、次のownerを決めます。
| owner | 責任 |
|---|---|
| Provider owner | model_provider、base_url、wire API、切り戻し |
| Key owner | APIキー発行、失効、退職者対応 |
| Cost owner | 予算、上限、プロジェクト配賦 |
| Security owner | ログ閲覧、保持期間、マスキング、インシデント対応 |
| MCP owner | MCP server、scope、OAuth、tool allowlist |
| Workflow owner | AGENTS.md、テスト、レビュー、承認フロー |
ownerが決まらないままLLMプロキシだけ入れると、便利な入口はできますが、事故時に誰も説明できない構成になります。
セキュリティ・コスト注意
送信先、ログ、保存期間、学習利用、閲覧者を確認します。
APIキーを設定ファイルへ直書きせず、環境変数参照にします。
provider統制をproject-local configだけで完結できる前提にしません。
ローカル実行の制御として見て、外部providerのデータ取り扱いとは分けます。
provider設定とは別の外部権限として、read-only開始、scope台帳、失効手順を持ちます。
promptやコード断片を含む可能性があるため、閲覧権限を狭くします。
安いモデルへの変更は、レビュー工数や再試行を含めて評価します。
切り戻し手順を設定例と同じ場所に置きます。
セキュリティとコストは単独の設定値ではなく、運用全体で確認します。
送信先とキー
確認項目
base_urlは送信先の変更です。設定レビューでは、endpointだけでなく、ログ、保存期間、学習利用、閲覧者まで確認します。- APIキーは
env_keyで環境変数参照にし、設定ファイルへ直書きしません。 - project-local configだけでprovider統制できる前提にしません。ユーザー設定、端末管理、オンボーディングで補います。
実行権限と外部権限
注意点
- sandbox/approvalはローカル実行の制御です。外部providerのデータ取り扱いとは別に確認します。
- MCPはprovider設定とは別の外部権限です。read-only開始、scope台帳、失効手順を持ちます。
- LLMプロキシのログは便利ですが、promptやコード断片を含む可能性があります。閲覧権限を狭くします。
費用と切り戻し
評価基準
- 安いモデルへの切り替えは、レビュー工数や再試行を含めて評価します。
- Provider障害時の切り戻し手順を、設定例と同じ場所に置きます。
利害関係
この記事は特定providerの広告、アフィリエイト、無償提供を受けた検証ではありません。
FAQ
provider側の公式例は有用ですが、社内標準にする前の確認項目は別に持ちます。
CodexでOpenAI以外のproviderを使うべきですか
「使うべき」とは一律には言えません。社内のデータ取り扱い、予算管理、モデル選択、監査ログ、障害時の切り戻しを説明できるなら選択肢になります。個人検証なら小さなダミーリポジトリから始め、実務コードへ広げる前にログとAPIキーの扱いを確認してください。
.codex/config.tomlにmodel_providerを書けばチームで固定できますか
それだけでは足りません。2026年6月16日に確認したOpenAI Codex Configuration Referenceでは、project-local configがmodel_providerやmodel_providersを上書きできないことが説明されています。チーム標準にするなら、ユーザー設定、端末管理、手順書、監査を組み合わせます。
LLMプロキシを入れればコスト管理は解決しますか
解決ではなく、管理点が増えると見る方が正確です。プロキシで利用量や予算を見やすくできる場合はありますが、プロキシ自体のログ、閲覧権限、障害、追加料金、provider互換性を確認する必要があります。
sandboxをread-onlyにすれば外部providerへコードは送られませんか
いいえ。read-onlyはローカルの編集や実行を制限する考え方です。モデルへ送る文脈にコード断片やログが含まれるかどうか、providerやプロキシがそれをどう扱うかは別に確認します。
Azure OpenAIやOpenRouterの設定例はそのまま社内標準にできますか
Provider側の公式例は、接続形を理解する材料として有用です。ただし、そのまま社内標準にする前に、契約、データ保持、認証方式、ログ、費用、障害時の切り戻し、Codex側の最新仕様を確認してください。
次に読むなら
AI Dev Lab Japanでは、AIコーディング導入時の権限設計、MCP設計レビュー、チーム向けAGENTS.mdや設定テンプレート整備も扱っています。この記事のチェック項目を自社用に埋めるところから始めると、provider選定の議論がかなり楽になります。
参照した主な情報源
- https://developers.openai.com/codex/config-advanced
- https://developers.openai.com/codex/config-reference
- https://developers.openai.com/codex/config-basic
- https://developers.openai.com/codex/auth
- https://developers.openai.com/codex/agent-approvals-security
- https://developers.openai.com/codex/concepts/sandboxing
- https://openrouter.ai/docs/cookbook/coding-agents/codex-cli
- https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/codex
更新履歴
- 2026年6月16日
OpenAI Codex公式Docs、OpenRouter Codex CLI integration、Microsoft Azure OpenAI Codex guideを確認し、Codex CLI `0.140.0`で`codex –version`を確認したうえで初稿を作成。
料金、モデル名、provider固有の互換性は変わりやすいため、確認日を残します。
- 2026年6月16日: OpenAI Codex公式Docs、OpenRouter Codex CLI integration、Microsoft Azure OpenAI Codex guideを確認し、Codex CLI
0.140.0でcodex --versionを確認したうえで初稿を作成。