Azure でCodexを使う方法｜Microsoft Foundryでのデプロイや料金、設定フローを解説

Microsoft Foundry上のCodexは、OpenAIのコーディングエージェント「Codex」をAzure OpenAIデプロイメントから呼び出す利用形態で、OpenAI直接版と同じ開発体験をエンタープライズ向けのセキュリティ境界・プライベートネットワーク・RBACのもとで実行できる選択肢です。
2026年2月24日にはMicrosoft Foundryで最新世代のgpt-5.3-codexが追加され、先行してGAされたgpt-5.2-codex（2026-01-14）、gpt-5.1-codex系、gpt-5-codex、codex-miniと合わせたラインナップが揃い、既存のAzure OpenAIリソースを起点に本番利用へ移行できる環境が整いました。

本記事では、Microsoft Foundry上のCodexの基本概念から主要モデル（gpt-5.3-codex／gpt-5.2-codex／gpt-5-codex／codex-mini）の特徴、Microsoft Foundryでのデプロイ手順、Codex CLIとVS Code拡張の接続設定、GitHub Actionsでの自動化、対応リージョンの制限、料金体系、そして活用シーンまでを一気通貫で解説します。

Microsoft Foundry上のCodexの全体像

Microsoft Foundry上のCodexは、OpenAIのコーディングエージェント「Codex」をMicrosoft Foundry（旧Azure AI Foundry）上のAzure OpenAIデプロイメント経由で利用する形態です。

ChatGPT上のCodexやCodex CLIと同じコアエンジンを使いながら、Azureが提供するエンタープライズ向けのセキュリティ境界・プライベートネットワーク・ロールベースアクセス制御のもとで動作させられる点が特徴です。

利用できるのはOpenAIのコーディング専用モデル群（gpt-5.3-codex・gpt-5.2-codex・gpt-5.1-codex系・gpt-5-codex・codex-mini）で、Microsoft Foundryのモデルカタログから直接デプロイできます。

最新のgpt-5.3-codexは2026年2月24日に追加され、Microsoft Learnの公式ドキュメントでもCodex CLI・VS Code拡張で選択できる推論モデルとして列挙されています。各モデルの位置づけと使い分けは次章で整理します。

Microsoft FoundryでCodexを利用するメリット

OpenAI直接版のCodexを使うと、コードやプロンプトがOpenAI側のクラウドに渡ります。

社内ポリシー上、顧客情報を含むソースコードを外部SaaSに渡せない企業にとっては、そのままでは本番導入が難しいケースが少なくありません。

Microsoft Foundry上のCodexは、この課題を次の3点で解決します。

• データをAzure側のコンプライアンス境界内に留められる
  Microsoft Foundryにデプロイしたモデルを経由するため、推論はAzureインフラストラクチャ上で実行され、指定した地理（geography）やデータゾーン、コンプライアンス境界内にデータを留めた運用ができます。
  
  
• プライベートネットワーク・VNet統合が使える
  Azure OpenAI側のネットワーク制御がそのまま適用でき、社内からのアクセスだけに絞る運用が可能です。
  
  
• 課金・監査がAzureの枠組みに載る
  既存のAzure請求・コスト管理・監査ログの仕組みに統合できるため、ガバナンス担当が新しいベンダー管理を増やさずに済みます。
  
  

Microsoft Foundry上のCodexで使える主要モデル

実際にデプロイできるCodex系モデルは、Microsoft Foundryの「Azureが直接販売するFoundryモデル」に含まれるOpenAI製コーディングモデル群です。

用途と規模によって選ぶモデルが変わるため、まずは選択肢の全体像を押さえます。

gpt-5.3-codex（最新世代のエンタープライズコーディング向け）

gpt-5.3-codexは、2026年2月24日にMicrosoft Foundryへ追加された最新世代のCodex系モデルです。

Microsoftのモデルカタログでは、コンテキストウィンドウ400,000トークン（入力272,000・出力128,000）、Responses APIおよび構造化出力・関数呼び出し・画像入力に対応し、Codex CLIとVS Code拡張向けに最適化された推論モデルと位置づけられています。

主な用途

gpt-5.3-codexは、gpt-5.2-codexと同等の400Kコンテキスト（入力272K／出力128K）を維持しつつ、OpenAIのGPT-5.3-Codex発表で示された通り、エージェント精度とレスポンス速度（約25%高速）を改善することで、エンタープライズ領域の長時間タスクをより快適に回すことを狙ったモデルです。

• 長期化・多工程のコーディングタスク（非同期エージェント前提）
• 大規模リポジトリの横断的な依存関係分析
• セキュアコーディングパターンを前提にしたAI支援コードレビュー
• 業務ロジックを含むレガシー基盤のモダナイゼーション

Microsoftのモデル退役ガイドでも、gpt-5.2-codexの後継としてgpt-5.3-codexが案内されており、新規のCodexワークロードは原則gpt-5.3-codexから検討するのが今後の基本線になります。

gpt-5.2-codex（前世代・安定運用向け）

gpt-5.2-codexは、2026年1月14日に一般提供が開始された前世代の主力Codexモデルです。Microsoftのモデルカタログでは、コンテキストウィンドウ**400,000トークン（入力272,000・出力128,000）**と記載されており、gpt-5.3-codexと同じ大規模入力を扱えます。

TechCommunityの告知では「エンタープライズのコードベース・大規模リポジトリ・進化する要件・セキュリティ制約」のために設計されたと位置づけられています。

主な用途

gpt-5.2-codexは、既に本番運用で安定しているワークロードや、gpt-5.3-codexへの段階的な移行を見据えた並行運用に適しています。

• 既存のCodexワークフローの継続運用
• レガシーシステムのモダナイゼーション
• 複数モジュールにまたがる大規模リファクタリング
• 脆弱性分析と修正提案を含むセキュリティワークフロー

MicrosoftのFoundryブログでは、約10万行規模のコードベースを一度にコンテキストとして扱える点を、gpt-5.2-codexの実務的な価値として紹介しています。

gpt-5-codex / gpt-5.1-codex系（中間グレード）

gpt-5-codex・gpt-5.1-codex・gpt-5.1-codex-mini・gpt-5.1-codex-maxは、gpt-5.2-codex／gpt-5.3-codexより前に提供開始された標準的なCodex系モデル群で、2026年4月時点でもモデルカタログから選択可能です。

いずれもコンテキストウィンドウは**400,000トークン（入力272,000・出力128,000）**で揃っており、公式ドキュメントでもconfig.tomlのモデル指定例として「gpt-5-codex」が使われています。既存環境を急に最新世代へ切り替える必要がなく、リリース影響を段階的に評価したい組織にとって使いやすい中間グレードです。

codex-mini（CLI中心の高速処理向け）

codex-miniは、o4-miniをベースにCLIワークフロー向けにチューニングした軽量モデルです。

Microsoftのモデルカタログでは入力200,000・出力100,000トークンに対応し、Microsoft Foundryの解説記事では「リポジトリ全体の取り込みやリファクタリングに十分な入力サイズに対応し、GPT-4.1と比較して約25%のコスト削減を実現する」と記載されています。

主な用途

codex-miniは、次のような「数をこなす」ワークロードに向いています。

• コミット前のスタイル修正・Lint警告の自動解消
• PRテンプレートの自動生成
• 定型的なテストコードの雛形生成
• 大量のスクリプトファイルへのヘッダー追加など反復作業

精度重視のリファクタリングや設計判断にはgpt-5.3-codexやgpt-5.2-codexを、繰り返し実行する軽いタスクにはcodex-miniを充てる、といった使い分けが基本線になります。

4モデルの使い分け

まずは主要4モデルの特性を1枚で俯瞰できるように整理します。

以下の表はMicrosoft Foundryのモデルカタログと各発表記事をもとに、Microsoft Foundry経由でCodexを使う利用者が判断の起点にすべき主要項目をまとめたものです。

実務で選ぶ際のポイントは、「1回のタスクで渡すコードの量」と「実行頻度」、そして「最新世代の性能向上がどれだけ効くか」のバランスです。

長時間のエージェント実行や最新精度が必要ならgpt-5.3-codex、すでに動いているパイプラインの安定運用はgpt-5.2-codex、短いコマンドを1日に何百回走らせるならcodex-miniが費用対効果で優位になります。

Microsoft Foundry上のCodexのエンタープライズ機能とOpenAI直接版との違い

Azure経由でCodexを使う最大の理由は、Azure OpenAIに組み込まれたエンタープライズ向けの統制機能を、そのままコーディングエージェントに適用できる点にあります。

ここではOpenAI直接版との違いを整理し、どちらを選ぶべきかの判断基準を示します。

Azure側で追加されるエンタープライズ機能

公式ドキュメントでは、Microsoft Foundry上のCodexの利点を「エンタープライズレベルのセキュリティ、プライベートネットワーク、ロールベースのアクセス制御、予測可能なコスト管理の利点を加え、コンプライアンス境界内にデータを保持しながらAzureインフラストラクチャ上で完全に実行できる」と説明しています。

具体的には、以下のような仕組みがそのまま使えます。

• プライベートネットワーク（VNet統合・プライベートエンドポイント）
  社内ネットワークからのみAzure OpenAIエンドポイントにアクセスできるように制御できます。
  
  
• Microsoft Entra ID連携によるIDガバナンス
  Azure OpenAIリソースへのアクセス自体はEntra IDで管理でき、リソース単位・リソースグループ単位の権限設計が可能です。
  
  
• Azure Monitor・診断ログによる監査
  呼び出し履歴・スロットリング・エラー傾向を既存のAzure監視基盤から確認できます。
  
  
• コストの予測可能性（PTU含む）
  従量課金に加えて、Provisioned Throughput Unit（PTU）でスループットを予約する方式も選べます。
  
  

OpenAI直接版との比較

判断を早めるため、どちらを選ぶべきかの目安を表にまとめます。以下の比較は、社内でAzureが既に標準化されている企業がCodexを本格導入する際の典型的な検討軸です。

実務での使い分けとしては、個人の検証やMVP構築はOpenAI直接版が最短で動かせますが、本番の社内プロジェクトで顧客コードを扱う段階ではMicrosoft Foundry経由のCodexに切り替える、という二段構えが現実的です。

支援先の事例でも、PoCはOpenAI直接版、運用移行時にAzureへ寄せるパターンが多く見られます。

現時点で残っている制約

一方で、2026年4月時点ではAzure側に寄せると諦める必要がある機能もあります。公式ドキュメントには、Codex CLIからのEntra ID認証は現時点でサポートされていないことが明記されています。

また、最新モデルがOpenAI本家でリリースされてから、Microsoft Foundryに登場するまでには数週間〜数か月のタイムラグが発生することがある点も事前に理解しておくべき制約です。新機能を即日試したい場面ではOpenAI直接版を併用する、といった判断が必要になります。

Microsoft Foundry上のCodexの導入手順

ここからは、Microsoft Foundry上のCodexを実際に動かすまでの具体的な手順を解説します。

大まかな流れは「Microsoft Foundryでモデルをデプロイ → Codex CLIをローカルにインストール → 「~/.codex/config.toml」にAzure情報を記述 → 環境変数にAPIキーを設定」の4ステップです。

事前準備

公式ドキュメントで示されている前提条件は次のとおりです。

• Azureサブスクリプション（未作成の場合は無料アカウントから作成）
• Microsoft Foundryへの共同作成者（Contributor）以上のアクセス権
• Node.js＋npm、またはmacOSの場合はHomebrew（Codex CLIをインストールするため）
• Windowsの場合はWSL2（CLIはWSL2経由で動作）
• Git 2.23以上（PRヘルパー機能を使う場合）
• RAM 4GB以上（推奨8GB）

クライアント側のOSはmacOS 12以降、Ubuntu 20.04以降／Debian 10以降、またはWindows 11＋WSL2がサポート対象です。

1.Microsoft Foundryでモデルをデプロイ

最初に、Microsoft Foundry上でCodex系モデルをデプロイします。

Microsoft Foundryのプロジェクト一覧画面を表示している画面

1. Microsoft Foundryにサインインし、新しいプロジェクトを作成する

新規プロジェクト作成ダイアログでプロジェクト名とリージョンを入力している画面

2. モデルカタログからgpt-5.3-codex・gpt-5.2-codex・gpt-5-codex・codex-miniのいずれかを選択する

モデルカタログで「codex」と検索し複数のcodex系モデルが一覧表示されている画面

3. 「このモデルを使用する」または「Azure OpenAI Deploymentsペイン」から「Deploy model」をクリックする

gpt-5.3-codexのモデル詳細画面を表示している画面

4. デプロイ名（例：gpt-5.3-codex）と容量を指定し、デプロイ完了を待つ（通常は数分程度だが、リージョン・容量・クォータ状況により変動する）

Deploy modelダイアログでデプロイ名と設定を入力している画面

5. 完了後、エンドポイントURLとAPIキーをコピーしておく

デプロイ済みモデルのエンドポイントURLとAPIキーが表示されている画面

ここで設定するデプロイ名は、あとで「config.toml」の「model」値として使う重要な識別子です。チーム内で命名規則を決めておくと、将来さらに新しい世代のCodex系モデルに差し替える際にも混乱を避けられます。

2.Codex CLIのインストール

続いてローカル環境にCodex CLIを導入します。macOSとLinuxで選べる方法が少し違うため、環境に合わせて選択します。

npmを使う場合は、次の1行でグローバルインストールが完了します。

npm install -g @openai/codex
codex --version # インストール確認

macOSでHomebrewを使いたい場合は、以下のコマンドを使います。

brew install --cask codex
codex --version # インストール確認

codex --version を実行しバージョン番号が表示されている画面

インストール後、Homebrewのパッケージがうまく見つからない場合は、Codex CLIの公式リポジトリに掲載されている最新手順に従ってください。

3.APIキーを環境変数に設定

Codex CLIはAPIキーを環境変数経由でのみ参照します（「config.toml」に直接書くとエラーになります）。手順2でコピーしたAzure OpenAIのAPIキーを、シェルの環境変数として登録します。

# macOS / Linux / WSL
export AZURE_OPENAI_API_KEY="<your-api-key>"

永続化したい場合は、「~/.zshrc」や「~/.bashrc」などシェルの設定ファイルに同じ行を追記します。WSL2環境では、WSL側だけでなくWindowsホスト側にも同じ環境変数を設定しておくと、VS Code拡張機能からの呼び出しで認証エラーが出にくくなります。

Codex CLIとVS Code拡張のAzure接続設定

インストールが終わったら、Codex CLIに「OpenAI直接版ではなくAzure OpenAIを使う」という設定を教える必要があります。中心となるのは「~/.codex/config.toml」という1ファイルです。

config.tomlの基本構成

公式ドキュメントで推奨されているv1 Responses API向けの設定テンプレートは次のとおりです。「model」の値は手順1で作成したデプロイ名と一致させる必要があります。

model = "gpt-5-codex"  # Azureのデプロイ名に置き換える
model_provider = "azure"
model_reasoning_effort = "medium"

[model_providers.azure]
name = "Azure OpenAI"
base_url = "https://YOUR_RESOURCE_NAME.openai.azure.com/openai/v1"
env_key = "AZURE_OPENAI_API_KEY"
wire_api = "responses"

VS Codeでconfig.tomlを開きAzure OpenAI向けの接続設定を記述している画面

設定のポイントは次の3点です。

• base_urlの末尾に/v1を必ず含める
  v1 Responses APIを使うとAPIバージョンの明示が不要になる代わりに、URLのパスで/v1を指定する必要があります。
  
  
• env_keyには環境変数名を書く
  APIキーの文字列を直接書くとCodex CLIが起動に失敗します。「env_key = "AZURE_OPENAI_API_KEY"」のように変数名のみ指定します。
  
  
• wire_apiは新しいモデルならresponses
  gpt-5.3-codex・gpt-5.2-codex・gpt-5-codex・codex-miniはいずれもResponses APIに対応しており、「wire_api = "responses"」を指定するとCodex側が自動で「/responses」パスを付与します。
  
  

動作確認コマンド

設定ファイルを保存したら、以下のコマンドで接続を確認します。TUI（対話型ユーザーインターフェース）が立ち上がり、Azure上のモデルから応答が返ってくれば成功です。

codexコマンド実行後に対話型TUIが起動し入力プロンプトが表示されている画面

対話型TUIでは、Codexが生成するDiffやコマンド実行を1ステップずつ承認しながら進められるため、最初の動作確認にはまず「codex」単体で起動する方が安全です。

Codex CLIのサンドボックスと承認ポリシー

Codex CLIでは、エージェントが触れる範囲を「--sandbox」オプションで、作業ごとの人間承認を「--ask-for-approval」オプションで制御します。

公式ドキュメントおよびCodex CLIリポジトリで示されている主なサンドボックスは次のとおりです。

承認ポリシー側は、「on-request」（必要時のみ承認）と「never」（承認を求めない）の2つが現在の推奨選択肢です。

「on-failure」（コマンドが失敗したときだけ承認）も指定できますが、OpenAIが公開するconfig.schema.jsonではdeprecatedとして扱われており、対話利用は「on-request」、CI/非対話自動実行は「never」に寄せるのが現行仕様に沿った運用です。実務では「workspace-write × on-request」を基準に据え、danger-full-accessは隔離環境だけで使うのが原則です。

いきなりフルアクセスでプロダクションリポジトリを触ると、Gitコミット・ファイル削除までエージェント判断で走る可能性があり、事故につながります。

VS Code拡張機能でCodexを使う手順

OpenAIが公式提供するCodex VS Code拡張機能を使うと、Codex CLIと同じ「config.toml」を参照しながら、エディタ内から直接エージェントを呼び出せるようになります。導入手順はシンプルですが、環境変数の引き継ぎに注意が必要です。

1. VS Codeをインストールする
2. OpenAI Codex拡張機能をマーケットプレイスからインストールする

VS Codeの拡張機能タブでOpenAI Codex拡張機能を検索している画面

3. 「~/.codex/config.toml」の「env_key」で指定した環境変数（上記の例では「AZURE_OPENAI_API_KEY」）をエクスポートしたターミナルから、「code .」でVS Codeを起動する

4. 拡張機能のサイドパネルから、後述の3つの承認モードを切り替えて使う

VS Code内でCodex拡張機能のサイドパネルを表示している画面

GUIランチャー経由でVS Codeを起動すると環境変数が読み込まれず、拡張機能からAPIキーが認識できないケースが多発します。

必ずターミナルから「code .」で起動してください。

なお、公式ドキュメントの同一ページ内でもCLI節の例では「AZURE_OPENAI_API_KEY」、VS Code節の例では「OPENAI_API_KEY」と表記が揺れているため、config.tomlの「env_key」に指定した変数名と、実際にエクスポートする環境変数名を必ず一致させるのが確実です。

WSL環境の場合は、Windowsホスト側にも同じ環境変数を設定しておくとより安定します。

VS Code拡張の3つの承認モード

公式ドキュメントでは、VS Code拡張のUIで切り替えられる3つの承認モードが次のように整理されています。

いずれもCLIの「--sandbox」／「--ask-for-approval」を拡張側でラップしたもので、GUI上からワンクリックで切り替えられる点が特徴です。

Codex拡張機能で承認モードを切り替えている画面

実務では「Default permission」を基準に据え、Full accessモードは隔離環境でだけ使うのが原則です。

CLI側のworkspace-write/danger-full-accessと対応関係にあると理解しておくと、GitHub Actionsなど非対話環境への移行時に設計がぶれません。

AGENTS.mdで永続的なガイダンスを与える

プロジェクト固有の規約（命名規則、使用ライブラリ、テスト方針など）をCodexに覚えさせたい場合は、「AGENTS.md」というファイルを使います。

Codexは以下の順でファイルを読み込み、トップダウンでマージしてコンテキストに含めます。

• 「~/.codex/AGENTS.md」（個人グローバル）
• リポジトリルートの「AGENTS.md」（プロジェクト共有）
• 作業ディレクトリの「AGENTS.md」（機能別・サブフォルダ別）

例えば、Azure AI Agents SDKを使った開発プロジェクトであれば、AIProjectClientの初期化方法や「DefaultAzureCredential」の使い方をAGENTS.mdに書いておくことで、Codexが毎回プロジェクト規約に沿ったコードを生成するようになります。

詰まりポイントとトラブルシューティング

Microsoft Foundry上のCodexの初回セットアップでよく遭遇するエラーと対処を整理しておきます。公式ドキュメントに記載された代表的な症状を、実装者の視点で読み替えたものです。

どれも原因を掴めば即解決できる項目ですが、事前に把握しておかないと設定ファイルのタイプミス探しに数時間を溶かすパターンが多い箇所です。

GitHub ActionsによるMicrosoft Foundry上のCodexの自動化

Microsoft Foundry上のCodexは、ローカルのCLIからの対話的な利用だけでなく、CI/CDパイプラインから非同期に呼び出すことを前提に設計されています。

ここではGitHub Actionsでの組み込み方と、代表的な自動化シナリオを紹介します。

基本的なワークフロー例

公式ドキュメントでは、リリース前にCHANGELOGを自動更新するジョブのサンプルが示されています。同じ構造を応用すれば、PRごとのドキュメント更新やテスト追加も自動化できます。

GitHub ActionsのSecretsにAZURE_OPENAI_KEYを登録している画面

jobs:
  update_changelog:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Codexでチェンジログを更新
        run: |
          npm install -g @openai/codex
          export AZURE_OPENAI_API_KEY="${{ secrets.AZURE_OPENAI_KEY }}"
          codex -p azure exec --full-auto "次のリリース向けにCHANGELOGを更新"

このワークフローのポイントは、APIキーをリポジトリのSecretsに保存し、「${{ secrets.AZURE_OPENAI_KEY }}」として注入している点です。

また、「codex -p azure」で「~/.codex/config.toml」のazureプロファイルを明示的に選択し、「exec --full-auto」で非対話の自動実行モードに入ります。

応用シナリオ

GitHub Actionsと組み合わせることで、開発パイプライン全体にMicrosoft Foundry上のCodexを埋め込むことが可能です。実運用で導入しやすい代表的なシナリオは次のとおりです。

• PR作成時のレビューコメント自動生成
  Pull Requestが作成されたタイミングで、Codexが差分をレビューし懸念点をコメントとして投稿するジョブを組む。
  
  
• テスト未作成ファイルの自動検出と雛形生成
  カバレッジレポートを入力に、テストコードが不足している関数だけをcodex-miniに渡してユニットテスト雛形を生成する。
  
  
• 依存関係アップデート時の互換性チェック
  Dependabotが作成したPRに対して、Codexが変更を影響範囲まで読み込み、破壊的変更の可能性をサマリ化する。
  
  
• セキュリティスキャン結果の修正案生成
  静的解析ツールが検出した脆弱性箇所を入力に、gpt-5.3-codexやgpt-5.2-codexに修正案を生成させる（適用は人間が判断）。
  
  

運用時の設計ポイント

CI/CDでCodexを使うときに最も気をつけるべきは、「非対話モードでの暴走を防ぐこと」です。実装系のSIerとして支援経験から得た設計上の推奨を挙げておきます。

• ジョブごとにコンテキストを絞る
  「codex exec」に渡すプロンプトに、対象ファイルや対象関数を明示してスコープを限定する。
  
  
• 書き戻しはPRを介して行う
  Codexが生成した変更を直接mainブランチにコミットせず、自動生成PRを経由してレビューを挟む。
  
  
• APIキーは最小権限のリソースに紐づける
  CI専用のAzure OpenAIリソースを分け、社内機密コード用のリソースと分離する。
  
  

Microsoft Foundry上のCodexの対応リージョンと制限事項

Microsoft Foundry上のCodexを本格運用する前に、対応リージョンと現時点での制約事項を押さえておく必要があります。

国内拠点の開発チームが使うケースでも、採用するモデルとデプロイメントタイプでリージョン可用性が変わるため、Microsoft Learnの最新一覧に照らしてリージョン選定を行うのが出発点になります。

主要モデルの対応リージョン

Codex系モデルの対応リージョンは、Azureが直接販売するFoundryモデルのページでモデルごと・デプロイメントタイプごとに細かく更新されています。Global Standard／Data Zone Standard／Global Provisioned managedなど、同じモデルでも選ぶデプロイメントによって利用可能リージョンが異なる点が大きな特徴です。

• gpt-5.3-codex／gpt-5.2-codex
  Global StandardとGlobal Provisioned managedの両方で、japaneastを含む複数リージョンに展開されています（Microsoft Learnの可用性表で最新状況を確認してください）
  
  
• gpt-5-codex／gpt-5.1-codex系
  同じくGlobal Standard中心に広く展開されており、japaneastを含むアジア太平洋リージョンでも利用可能なケースがあります
  
  
• codex-mini
  Global StandardでEast US 2／Sweden Centralのみ記載されており、他モデルよりも提供リージョンが絞られます

選ぶモデルとデプロイメントタイプによって利用可能リージョンが異なるため、採用前にMicrosoft Learnの最新リージョン表をモデル単位・デプロイメントタイプ単位で必ず確認してください。

国内拠点で低遅延を重視するプロジェクトでも、多くのCodex系モデルはjapaneastで選択できますが、codex-miniのように限定的なモデルもあります。アプリケーション用途と推論拠点の距離は、モデル選定とあわせて設計段階で整理する必要があります。

認証・セキュリティの制約

公式ドキュメントに明記されているように、2026年4月時点のCodex CLIはEntra ID認証をサポートしていません。現状はAPIキー認証が前提になるため、次のような運用設計が必要です。

• シークレットをAzure Key VaultやGitHub Secretsで一元管理する
• APIキーのローテーションを自動化し、漏洩時の影響を短時間で封じ込める
• Azure OpenAIリソース側でIPアドレス制限・プライベートエンドポイントを併用し、キー漏洩時の二重防御を確保する

Entra ID認証への将来対応については公開一次ソース上で明確なロードマップが示されていないため、当面はAPIキー運用を前提に設計するのが現実的です。

Microsoft Learnの案内が更新された時点で、マネージドIDやユーザー認証への移行可否を再検討する運用にしておきましょう。

クォータとスロットリング

Azure OpenAIのリソースにはモデルごとに1分あたりのトークン上限（TPM：Tokens Per Minute）と1分あたりのリクエスト上限（RPM：Requests Per Minute）が割り当てられます。

Codex CLIを複数人で同時に使うと、意外と早くこの上限に到達するため、チーム利用を前提にする場合は早めにクォータ引き上げ申請を行うことを推奨します。

安定したスループットを担保したい場合は、Provisioned Throughput Unit（PTU）を予約する選択肢もあります。

月次のコード生成量が読めるチームであれば、従量課金からPTUへの移行でコストを予測可能にできます。

Microsoft Foundry上のCodexの活用シーンとユースケース

Microsoft Foundry上のCodexをどの業務に最初に適用するかは、多くの企業が悩む論点です。
ここではCodex全体のエンタープライズ活用事例を参考にしつつ、Azure経由で導入する際に効果が出やすいシナリオを紹介します。

エンタープライズでのCodex活用の広がり

OpenAI公式のScaling Codex to enterprises worldwide（2026年4月21日付）では、この時点でCodexの週次アクティブユーザーが400万人を超えたと報告されています。

また、先行する同社発表（2026年3月19日）では、週次200万人超のアクティブユーザー、年初から3倍のユーザー数・5倍の利用量という指標が示されており、企業領域での採用が急速に広がっていることが読み取れます。同記事では、導入企業の具体例として以下のような事例が挙げられています。

• Virgin Atlantic: テストカバレッジの拡大とチームの開発速度向上
• Ramp: コードレビューの加速
• Notion: 新機能開発のスピードアップ
• Cisco: 大規模で相互依存するリポジトリの理解と推論
• Rakuten: インシデント対応での活用

これらの事例はCodex全体での活用ですが、自社が規制業種・金融・公共領域であれば、同等のユースケースをMicrosoft Foundry経由のCodexで実装することでコンプライアンス要件を満たせます。OpenAI直接版では手が出せなかった社内コード資産に対しても、Azure側でリソースを閉じることで適用範囲を広げられる、というのが実務的な価値です。

Microsoft Foundry上のCodexで効果が出やすいユースケース

支援先のプロジェクトから整理した、Microsoft Foundry上のCodexの適用が早期に効果を出しやすい4つのユースケースを紹介します。

レガシーシステムのモダナイゼーション

古いフレームワークで書かれた大規模コードベースを読み解き、現行技術スタックへの移行計画を立てるタスクは、gpt-5.3-codex／gpt-5.2-codexの400Kコンテキストウィンドウ（入力272K）と深いコンテキスト理解が効いてきます。

Microsoft Foundryの発表でも、レガシーモダナイゼーションはgpt-5.2-codex／gpt-5.3-codexの主要ユースケースとして位置づけられています。

AI支援のコードレビュー

PR単位でgpt-5.3-codexまたはgpt-5.2-codexに差分を渡し、既知のセキュアコーディングパターンとの整合性を確認させることで、レビュー担当者の負荷を下げられます。

人間のレビューを置き換えるのではなく、人間レビューの前段に入れる設計が実務では安定します。

定型コードの自動生成

テストコードの雛形、APIクライアントラッパー、マイグレーションスクリプトなどは、codex-miniで十分まかなえます。
トークン単価が低いため、1日に数百〜数千回呼び出すワークロードでもコストインパクトが限定的です。

段階的リファクタリング

「どこから手をつければいいか分からない」巨大コードベースに対して、Codexにリポジトリ全体を読ませて優先度付きのリファクタリング提案を出させる使い方があります。
Azure環境で閉じているため、社内ポリシー上の制約が少ないのが強みです。

導入を本番運用までつなぐための論点

自社のAzureテナントにCodexを載せるところまではドキュメントどおりに進みますが、「開発エージェントが使える」状態から「業務に組み込まれている」状態に進めるには、もう一段の設計が必要になります。

よく詰まる論点は次の3つです。

• 開発者ごとのAPIキー管理と費用按分
  チーム規模が大きくなるほど、誰がどれだけトークンを消費したかの可視化が必要になる。
  
  
• 生成物の品質保証プロセス
  Codexが生成したコードをそのままマージしない体制づくり（人間レビュー、自動テスト、静的解析の組み合わせ）。
  
  
• 生成結果の学習素材化
  Codexのプロンプト・生成結果・採用有無をログ化し、AGENTS.mdや社内ガイドにフィードバックする運用。
  
  

Microsoft Foundry上のCodexの料金体系

最後に、Microsoft Foundry上のCodexのコスト構造を整理します。

2026年4月時点の情報であり、最新の数値は必ずAzure OpenAI Service Pricingの公式ページで確認してください。

トークン従量課金の基本

Microsoft Foundry上のCodexで使用するモデルは、入力トークン・キャッシュ済み入力トークン・出力トークンのそれぞれに対して1Mトークン単位の単価が設定されます。

参考として、前世代にあたるgpt-5.2-codexの価格は、発表記事で以下のように公表されています。最新世代のgpt-5.3-codexについてはMicrosoft Foundry Pricingで必ず最新値を確認してください。

注目すべきはキャッシュ済み入力の単価が通常の10分の1になっている点です。

同じシステムプロンプトや長大なコンテキストを繰り返し送るCodex系の使い方とは特に相性が良く、プロンプト構造を工夫するだけでコストを大きく抑えられます。

codex-miniはGPT-4.1比で約25%低コストであり、大量の軽量タスクをさばく用途ではgpt-5.2-codexよりはるかに費用対効果が高くなります。

モデルごとの最新単価はMicrosoft Foundry Pricingで確認できます。

価格例（2026年4月時点）

イメージをつかむため、gpt-5.2-codexを使った典型的な1タスクのコスト感を試算します。入力20万トークン・出力1万トークンの大規模リファクタリングを1回走らせる場合、おおよそのコストは次のとおりです。

• 入力コスト: 200,000 × $1.75 / 1,000,000 = $0.35
• 出力コスト: 10,000 × $14.00 / 1,000,000 = $0.14
• 合計: $0.49／1タスク

同じリポジトリに対して1日20タスク走らせても、従量課金ベースで月間$300前後。人間のエンジニアの工数と比較すれば、コード品質を保ったまま工数を削減できる投資対効果は明確です。

大量処理を予定する場合はPTU（Provisioned Throughput Unit）を検討してください。なお、gpt-5.3-codexの最新単価はMicrosoft Foundry Pricingで必ず事前に確認してください。

PTU（予約方式）の位置づけ

安定したスループットが必要な場合、従量課金ではなくProvisioned Throughput Unit（PTU）を選択することで、1時間あたり固定料金でスループットを確保できます。PTUは次のような状況に向いています。

• 1日のコード生成量がほぼ一定で読める
• スロットリングで開発が止まることを絶対に避けたい
• コストを月次予算に合わせて固定化したい

逆に、利用量が日次で大きく変動する段階ではPTUはオーバーコストになりがちです。PoC期間は従量課金、本番運用が安定したらPTUへ移行、という順序が現実的です。

Codexをテナント内で業務運用までつなぐ

Microsoft Foundry上のCodexでAIコーディング環境が整った次は、「生成したコードを業務システムに組み込み、開発以外の業務プロセスまでAIで自動化する」という段階に関心が移ります。

開発基盤とビジネス基盤をつなぐレイヤーこそが、AI活用のROIを押し上げる鍵になります。

このレイヤーを担うのが、自社のAzureテナント内で動くエンタープライズAIエージェント基盤です。

AI総合研究所のAI Agent Hubは、Azure Managed Applicationsとして顧客テナント内に構築され、Microsoft Teamsから呼び出せる複数の業務特化ユースケース（経費精算・請求書処理・設計製図・見積作成・FAQ対応・Excel操作・CRM連携・人事業務・在庫管理・データ分析など）をAgentの組み合わせで実現できる設計です。

• Azureテナント内で完結するAIエージェント運用
  Codexが活かすAzure OpenAIと同じテナントでAgent実行基盤を構築。データが外部SaaSに出ず、AIの学習対象からも完全除外されます。
  
  
• どこで構築したAgentも管理は1つ
  Codexで内製した開発補助Agent、Copilot Studioで作った業務Agent、Microsoft Foundryで構築したAgentを1つのダッシュボードで一元管理。実行ログ・権限・セキュリティスキャンを横断的に制御できます。
  
  
• Fabric × Agentで業務データをAIアクションに直結
  Microsoft FabricのOneLakeでZero ETLのデータ仮想統合を前提に、AgentがSAP ConcurやDynamics 365の業務データへ直接アクセスし、承認・申請・報告までを自動実行します。
  
  

AI総合研究所の専任チームが、600社以上のAI導入相談実績とMicrosoft MVP／Solution Partnerの知見をもとに、Codex導入の設計から業務プロセスへの組み込みまで伴走します。
まずは無料の資料で、自社のAI導入ロードマップにどう組み込めるかをご確認ください。

Codexをテナント内で業務運用までつなぐ

コード生成だけでなく業務プロセスのAI化へ

Azure OpenAIでCodexを動かす基盤が整っても、コード生成の先にある業務自動化まで接続するには、データ連携・権限設計・実行管理を含めたAIエージェント基盤が必要です。AI総合研究所のAI Agent Hubは、自社Azureテナント内で動くAI Agent内製化プラットフォームとして、Codex活用の次のフェーズを支援します。

▶ 無料で資料をダウンロード

まとめ

本記事では、Microsoft Foundry上のCodexの概要から主要モデルの違い、Microsoft Foundryでのデプロイ手順、Codex CLIとVS Code拡張機能のAzure接続設定、GitHub Actionsでの自動化、対応リージョンと制限事項、料金体系、そして活用シーンまでを解説しました。

改めて整理すると、Microsoft Foundry上のCodexを選ぶ判断は以下の3点で決まります。

• データとコードを指定したAzureのコンプライアンス境界内に留めたいなら、OpenAI直接版ではなくMicrosoft Foundry経由のCodexが第一候補
• 最新世代の大規模リファクタ・長時間タスクはgpt-5.3-codex、安定運用中のワークロードはgpt-5.2-codex、CLI中心の軽量自動化はcodex-miniという使い分けを前提に、Foundryでのデプロイを設計する
• 本番運用ではAPIキー管理・リージョン選定・クォータ設計を初期段階で詰めておけば、CI/CDや業務システム連携まで無理なく拡張できる

Microsoft Foundry上のCodexは、個人開発者の「コード補完ツール」から、エンタープライズの「社内標準AIコーディング基盤」までを同じ仕組みでスケールさせられる点が強みです。まずはMicrosoft Foundryでgpt-5.3-codex（または検証用にgpt-5-codex）をデプロイし、「~/.codex/config.toml」のmodel_providerをazureに切り替えるところから始めてみてください。