Azure AI Foundry × Codex 接続・設定・運用ガイド【2026年版】──企業向け構成と実装手順

Codex Desktop / CLI から Foundry の GPT-5.5(または GPT-5.4)を使い、Azure Skills Plugin と Azure MCP Server で設計から運用までを横断的に支援する|2026年5月時点

企業導入でぶつかる壁。生成 AI を企業に導入しようとすると、便利さと統制がしばしば衝突する。個人向け SaaS は速いが、データ所有権・監査ログ・退職者管理の観点でガバナンスに弱い。一方で Azure を中心に据えれば安全だが、設計が重く、初動が遅くなりがちだ。本記事は、そのギャップを Codex と Azure AI Foundry の組み合わせでどう埋められるかを、設計・開発・デプロイ・運用・障害対応・構成管理の各フェーズに分けて整理する。専門用語が次々と出てくるが、各章の冒頭に最低限の用語整理を置いた。

本記事の構成

導入:本記事が想定する企業環境と前提
用語と構成要素の定義
背景構造:Codex × Foundry × Azure Skills の三層構造
基盤セットアップ:Codex を Azure に接続する5ステップ
Azure Skills Plugin の導入とスキルカタログの理解
設計フェーズ:アーキテクチャ判断と IaC 生成
- サービス選定・コスト試算・アーキテクチャ図生成
- 既存環境のコンテキスト取得(命名・ネットワーク・タグの整合性)
開発フェーズ:アプリケーションコードと組織標準の遵守
- Azure SDK 連携、コード生成、組織規約への準拠
デプロイフェーズ:azd up を介した3段階パイプライン
- azure-prepare → azure-validate → azure-deploy
- Azure DevOps を中核に据えない理由と回避策
運用・監視フェーズ:Application Insights と KQL
- 可観測性、アラート、ダッシュボード、SLO
障害対応フェーズ:診断・原因特定・復旧
- azure-diagnostics、KQL ログ相関、ポストモーテム
保守・構成管理フェーズ:ドリフト検出・コスト最適化
- 定期スキャン、Automation、ライフサイクル管理
変更前影響分析と Plan モード活用
- Blast Radius 分析の標準プロンプト、Codex CLI Plan モード
- 影響分析・Plan・Hooks の役割分担
本番作業エビデンスとガバナンス:Codex Hooks による監査自動化
- 5つのライフサイクルイベント、危険操作のブロック
- 変更前/変更後のリソース状態スナップショットと差分記録
- Hooks の位置づけ:監査補助の自動化層
実運用ガードレール:本番展開のための運用設計
- RACI、承認境界、本番禁止事項、例外承認フロー
- AGENTS.md の三層構造、入力資料の信頼順位、レビュー観点
- 監視ノイズ抑制と Go / No-Go 判定基準
限界と注意点
まとめ:判断軸と段階的導入
付録:公式 URL 一覧

1. 導入:本記事が想定する企業環境と前提

OpenAI の Codex は、コーディングエージェントとして企業の開発現場でも採用が広がっている。Microsoft の Azure AI Foundry(旧 Azure AI Studio)は、AI モデルを Azure インフラ上で運用し、企業の統制・コンプライアンス境界に乗せやすい統合プラットフォームとして、企業 AI 活用の基盤となりつつある。さらに2026年3月、Microsoft が公開した Azure Skills Plugin は、これら2つを「ただ繋ぐ」段階から「Azure のソフトウェアライフサイクル全体を横断的に支援できる」段階へと押し上げた。複数の Azure 専門スキルと、多数の Azure MCP ツールが標準的に組み込まれ、Codex を単なるコード生成器ではなく、設計判断から運用監視までを横断的に支援する共同作業者として位置づけられるようになった。

本記事は、企業環境でこの3要素(Codex Desktop App / CLI + Azure AI Foundry + Azure Skills Plugin)を組み合わせ、ソフトウェアライフサイクルの各フェーズ ── 設計、開発、デプロイ、運用、監視、障害対応、構成管理 ── で実用に堪える運用を確立するための実装ガイドである。基盤セットアップは必要最小限にまとめ、本論は「各フェーズで Codex に何を依頼でき、その裏で Azure Skills と MCP ツールがどう動くか」に焦点を当てる。

本記事の主読者

本記事は、Codex を企業環境で組織展開する立場にある以下の役割の方を主読者として想定しています。

情シス・IT 統制部門:Codex 導入時のガバナンス・コンプライアンス設計を担う
プラットフォームエンジニアリングチーム:Codex 基盤、Hooks 配布、開発者向け環境整備を担う
Azure 管理者・クラウドセンター・オブ・エクセレンス(CCoE):組織標準の Azure 環境と AI 連携基盤を設計する
セキュリティ・ガバナンス担当:本番作業統制、エビデンス設計、SIEM 連携を担う
技術リード・テックリード:開発チームの Codex 活用ルールを設計し、AGENTS.md を整備する

一般開発者向けの「Codex 入門」「便利な使い方」記事ではない点にご留意ください。実際の現場で Codex を本番運用に乗せるための設計・統制・運用に踏み込んだ実装ガイドとして位置づけています。

本記事が前提とする企業環境

Microsoft Azure 契約:Enterprise Agreement、CSP 経由、または Pay-as-you-go の Azure サブスクリプションを保有していること
Microsoft Entra ID テナント:企業ドメインで検証済みの Entra ID テナントが存在し、Conditional Access による IT 統制が運用されていること
セキュリティ統制方針:従業員個人契約の SaaS アカウントを業務利用することが、データ所有権・監査証跡・退職者管理の観点から許容されていないこと
データ境界要件:業務データを自社の Azure サブスクリプション外のインフラに送信することにコンプライアンス上の制約があること
開発組織規模:5名以上の開発者が同時利用し、SSO・グループ管理・コスト集約を必要とすること

本記事の到達点は以下である。

推論処理を Azure インフラ上で運用し、企業の統制・コンプライアンス境界に乗せやすい構成を取る
Codex Desktop App と CLI から Foundry にデプロイした GPT-5.5(または GPT-5.4)などの統合フロンティアモデルをキー認証経由で安全に利用する
Azure Skills Plugin と Azure MCP Server により、Codex が Azure リソースを「説明する」だけでなく「実際に操作する」状態を作る
設計→開発→デプロイ→運用→監視→障害対応→保守・構成管理の各フェーズで、Codex を自然言語インターフェースとして活用する
監査・コスト管理・ガバナンスのフレームワークを Codex 自身に支援させる

個人利用との位置づけの違い(参考)

個人開発者向けには、ChatGPT Plus 契約と Codex Web(chatgpt.com/codex)を組み合わせる構成が広く解説されている。手軽だが、データが OpenAI のインフラを経由するため、企業のデータ境界要件を満たさないケースが多い。本記事の構成は、この点を構造的に解決するための企業向け実装である。

2. 用語と構成要素の定義

本記事で頻出する用語の早見表

MCP(Model Context Protocol): LLM が外部ツールやデータソースを安全に呼び出すための共通インターフェース仕様。Anthropic が提唱、現在は業界横断で利用される。
MCP Server: MCP を実装したサーバー。LLM に対して「何を実行できるか(ツール群)」を公開する接続口。Azure MCP Server や Foundry MCP Server がある。
Skill / Azure Skills: 「どう判断するか・何を避けるか」の知識を Markdown(SKILL.md)で記述したもの。LLM がプロンプトの意図に応じて自動的にロードする。Azure Skills Plugin は Azure 専門のスキル群と MCP Server をまとめてパッケージ化したもの。
Microsoft Foundry(旧 Azure AI Studio): Azure 上で AI モデルをデプロイ・運用・監視できる統合プラットフォーム。OpenAI モデルを含む多数のモデルが利用可能。
Foundry Hub と Project: Hub は共有リソース(ストレージ、Key Vault、Application Insights など)の集約単位。Project はその下で実際の AI ワークロードを構築する単位。1 Hub に複数 Project がぶら下がる構造。
モデルデプロイメント: Foundry 上に作成したモデルのインスタンス。例えば「GPT-5.5」というモデルを「gpt-5-5-prod」という名前でデプロイし、エンドポイント URL と API キーを得る。
Standard(Pay-as-you-go)と PTU: Standard はトークン単価の従量課金で、検証・小規模利用向け。PTU(Provisioned Throughput Units)は性能保証寄りの専用キャパシティ課金で、本番・常時利用向け。
Codex ハーネス: Codex の「実行環境」を指す。Codex Desktop App、CLI、IDE 拡張、Web、Slack 等の各表面のこと。本記事では企業利用に適した Desktop App / CLI / IDE 拡張を扱う。
azd(Azure Developer CLI): Azure 上でアプリのプロビジョニング・ビルド・デプロイを統合実行する CLI。azd up 一発でインフラ作成からアプリデプロイまで実行できる。Azure Skills Plugin がデプロイ実行に利用する。
Bicep: Azure 公式の IaC(Infrastructure as Code)言語。ARM テンプレートを読みやすく書ける構文として位置づけられる。
AGENTS.md: リポジトリ直下に置く Markdown ファイル。Codex がセッション開始時に必ず読み込み、組織固有の規約や禁止事項を Codex に教える役割を持つ。

2.1 Codex の二層構造

本記事を読み進める上で重要な理解は、「Codex」が2つの異なる対象を指していることである。

区分	具体名(2026年5月時点)	提供形態
Codex モデル(推論エンジン)	統合フロンティアモデル: GPT-5.5、GPT-5.4(コーディング能力を統合した汎用モデル) / 旧来のコーディング特化系列: 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(用途に応じて補助的に利用)	Azure AI Foundry のモデルカタログから自社サブスクリプションにデプロイ可能
Codex ハーネス(エージェント実行環境)	Codex Desktop App、Codex CLI、Codex IDE 拡張、Codex Web、Codex on Slack / iOS	表面によって接続できるモデル提供元が異なる(Desktop / CLI / IDE は Foundry 接続可、Web は OpenAI 直接ホストのみ)

OpenAI のモデル系列は2026年に大きく整理された。GPT-5.3-Codex(2026年2月)で初めて「Codex 訓練データ」と「GPT-5 の推論・汎用知識」が統合され、その後 GPT-5.4 が gpt-5.3-codex を Codex 内で置き換える形でリリース(2026年3月)、さらに GPT-5.5(2026年5月)が現時点で最新の統合フロンティアモデルとなっている。OpenAI 公式の Codex Models ドキュメントでも「ほとんどのタスクは gpt-5.5 から始める。gpt-5.5 が利用できない場合は gpt-5.4 を使う」と明記されており、コーディング業務でも統合モデルを使うのが基本となる。旧来の Codex 特化系列(gpt-5.x-codex)は、特定のエージェント・ループ動作や Cloud Tasks、Code Review といった特殊用途で補助的に利用する位置づけ。利用可能なモデルは時期・リージョン・提供状況により変わるため、本番採用前には Foundry モデルカタログと Azure AI Foundry What's New で最新情報を確認することを推奨する。

2.2 Azure AI Foundry の構成要素

区分	主要サービス	役割
Foundry Hub	共有リソース基盤	ストレージ、Key Vault、Application Insights などをまとめる単位
Foundry Project	Hub 内のワークロード単位	モデルデプロイとアクセス制御の最小単位
モデルデプロイメント	GPT-5.5、GPT-5.4、gpt-5.3-codex 等のインスタンス	SKU により Standard(従量課金)または PTU(専用容量)を選択
認証情報	API キー、エンドポイント URL	Codex Desktop App / CLI から接続するために使用
Content Safety	分類モデル(デフォルト適用)	有害コンテンツの検出と遮断
ネットワーク	Private Endpoint、VNet 統合	閉域網アクセスの制御

2.3 Azure Skills Plugin の構成

Azure Skills Plugin(microsoft/azure-skills)は、Codex に対して以下3つを一括で提供する。

Azure 専門のスキル群(SKILL.md ファイル群):Azure 業務に関する判断ロジックを Markdown でカプセル化したもの。Codex がプロンプトの意図に応じて自動的にロードする。
Azure MCP Server:多数の Azure サービスを操作できる MCP ツール群。Codex がリソース照会、デプロイ実行、ログ取得、診断などを実際に行うための実行レイヤー。
Foundry MCP Server:Microsoft Foundry に特化したツール群。モデル発見、デプロイ、エージェント運用のためのオペレーション。

つまり Azure Skills Plugin は、「Codex に Azure 専門家の判断ロジックを与えるスキル層」と「Codex が実際に Azure を動かす実行層」を、ワンインストールで両立させる構造である。これがあるか無いかで、Codex の Azure 業務への適用範囲が大きく変わる。

3. 背景構造:Codex × Foundry × Azure Skills の三層構造

3.1 企業が個人 SaaS 契約を許容できない4つの理由

個人契約の ChatGPT を従業員に業務利用させる運用は、以下の理由から多くの企業で許容されない。

データ所有権の不明瞭さ:個人契約 SaaS はベンダー側のデータ学習対象となる場合がある。オプトアウト設定はあるが、従業員ごとの徹底は現実的でない。
監査証跡の欠如:個人アカウントは IT 部門の管理外。法人レベルの監査ログが取れず、SOC 2 や ISO 27001 の認証要件を満たしにくい。
退職者管理の難しさ:従業員退職時にアカウントの引継ぎや剥奪が確実に実行できない。
請求と費用管理の煩雑性:個人カード経由の SaaS 契約は企業の経費精算ルールと合わず、消費税や源泉徴収の扱いが複雑化する。

3.2 三層構造の概念図

企業利用における Codex × Azure AI Foundry × Azure Skills の三層構造

ハーネス層(開発者の入口)

開発者が自然言語で指示するインターフェース。タスク管理、並列実行、Git 連携を担う

Codex Desktop App / Codex CLI / Codex IDE 拡張

↓ API キー認証(Azure Key Vault + Entra ID 経由で取得)

専門知識・実行層(Azure 業務の判断と操作)

Azure 業務の判断ロジックと実際の操作を担う。プロンプトに応じて自動発火し連鎖実行する

Azure Skills Plugin(SKILL.md) + Azure MCP Server + Foundry MCP Server

↓ 推論呼び出し(HTTPS)

推論層(Azure インフラ上で運用、企業の統制・コンプライアンス境界内)

コード生成、推論、判断を実行。推論処理は企業の Azure 管理下に置かれる

Microsoft Foundry にデプロイされた GPT-5.5(または GPT-5.4)等の統合フロンティアモデル

この三層構造により、企業はデータ境界・コンプライアンス要件に配慮しつつ、Codex に対して「Azure についてどれだけ自然に依頼できるか」を引き上げられる。

3.3 Foundry を選ぶ企業向けメリット

特性	具体的な効果
Azure インフラ上での運用	推論処理を Azure 上で実行し、監査・統制を効かせやすい構成を取れる
Azure RBAC との統合	部門や役割に応じたモデル利用権限を粒度高く設計できる
Private Endpoint と VNet 統合	企業の閉域網内からのみ利用させる構成が可能
請求の一元化	AI 推論コストが Azure の月次請求書に統合される
監査ログの取得	推論呼び出しを Azure Monitor / Log Analytics に取り込める
PTU(Provisioned Throughput Units)	ピーク時のスループット保証と月額固定コストモデルを選択できる
Customer Copyright Commitment	Azure 経由の利用に Microsoft の知的財産権補償が適用される

4. 基盤セットアップ:Codex を Azure に接続する5ステップ

本セクションでは基盤構築を5ステップに圧縮する。各ステップの詳細は Azure 公式ドキュメントを参照しつつ、必要最小限の操作を示す。

事前準備:アカウント・契約・登録

用途別に Azure サブスクリプションを分離する。最小構成は Production / Non-production / Identity の3サブスクリプション。Azure Landing Zone の考え方に基づく。

事前確認項目:

Entra ID テナントとカスタムドメインの検証済み状態
Conditional Access ポリシーの定義(MFA 必須など)
Entra ID Premium P1 以上のライセンス
GPT-5 / GPT-5.5 を PTU で使う場合の事前登録(aka.ms/oai/get-gpt5、承認まで1〜3週間)

ChatGPT Business / Enterprise 契約は本構成では必須ではない。Codex Desktop App / CLI は OpenAI の ChatGPT 契約なしに Foundry に接続できる。

Foundry プロジェクトとモデルデプロイ

ai.azure.com(Microsoft Foundry portal)で操作する。

新規プロジェクト作成(名前:foundry-codex-prod-001 等)
モデルカタログから対象モデルを検索しデプロイ:OpenAI Codex 公式が推奨する第一候補は GPT-5.5、フォールバックは GPT-5.4。ただし Azure AI Foundry で実際に利用可能なモデルは時期・リージョン・アクセス承認状況により異なるため、Foundry モデルカタログと Microsoft Learn の最新手順で確認の上で選定する。特殊用途では Codex 特化系列(gpt-5-codex、gpt-5.1-codex、gpt-5.2-codex、gpt-5.3-codex 等)を併設
デプロイメント名(例:gpt-5-5-prod)を決定 ── これが Codex 側の model 設定値と一致する必要がある
SKU 選択:検証は Standard(Pay-as-you-go)、本番は Provisioned Throughput(PTU)
エンドポイント URL と API キーを取得

モデル選択の目安:

ほとんどのコーディングタスクの第一選択 → GPT-5.5。OpenAI 公式の Codex Models ドキュメントが「ほとんどのタスクは gpt-5.5 から始める」と明記する標準モデル。コーディング能力に加え、computer-use、長期エージェント作業、長文脈の knowledge work にも優れる
GPT-5.5 が利用できない場合 → GPT-5.4。GPT-5.3-Codex のコーディング能力を統合した一世代前のフロンティアモデル。SWE-Bench Pro で GPT-5.3-Codex と同等以上の性能
軽量サブエージェント・コスト最適化 → GPT-5.4-mini。長時間タスクのサブエージェント、コードベーススキャン、長期会話のコンテキスト圧縮など補助タスクに最適
特殊用途 → 旧来の Codex 特化系列(gpt-5.3-codex 等)。長時間のエージェントコーディングループ、Cloud Tasks、Code Review の特化機能などで補助的に併設するケースに限定

Key Vault による API キーの安全な配布

API キーを各端末に永続保管せず、Entra ID 認証経由で取得する仕組みを構築する。

Key Vault 作成(kv-foundry-prod-jpe-001、RBAC モード)
Foundry API キーをシークレット(foundry-codex-apikey-prod)として保管、90日有効期限
Entra ID で「Codex Developers」グループを作成し、Key Vault Secrets User ロールを付与

各開発者のシェルプロファイルに以下を追加する(macOS / Linux 用):

azure_codex_login() {
  az login --tenant YOUR_TENANT_ID.onmicrosoft.com
  export AZURE_OPENAI_API_KEY=$(
    az keyvault secret show \
      --vault-name kv-foundry-prod-jpe-001 \
      --name foundry-codex-apikey-prod \
      --query value -o tsv
  )
  echo "Codex API キーを環境変数に読み込みました。"
}

Windows PowerShell 用:

function Azure-Codex-Login {
    az login --tenant YOUR_TENANT_ID.onmicrosoft.com
    $env:AZURE_OPENAI_API_KEY = (
        az keyvault secret show `
          --vault-name kv-foundry-prod-jpe-001 `
          --name foundry-codex-apikey-prod `
          --query value -o tsv
    )
    Write-Host "Codex API キーを環境変数に読み込みました。"
}

これにより、API キーは端末に永続化されず、Entra ID 認証(MFA を含む)が認証段階に強制され、退職者管理は Entra ID グループからの削除のみで完了する。

Codex Desktop App / CLI のセットアップ

用途に応じて Codex Desktop App、Codex CLI、Codex IDE 拡張を導入する。3つは同一の設定ファイル ~/.codex/config.toml を共有するため、1度の設定で複数表面に反映される。

インストール手段:

Codex Desktop App:公式ダウンロードページから(macOS Apple Silicon / Intel、Windows)
Codex CLI:npm install -g @openai/codex または brew install --cask codex
Codex IDE 拡張:VS Code Marketplace、Cursor / Windsurf の拡張ストア

Codex Desktop App の初回起動時に「Sign in with API key」を選択(「Sign in with ChatGPT」は個人 ChatGPT アカウントへの依存となるため企業利用では選ばない)。

~/.codex/config.toml(Windows は %USERPROFILE%\.codex\config.toml)に以下を設定:

model = "gpt-5-5-prod"
model_provider = "azure"
model_reasoning_effort = "medium"
preferred_auth_method = "apikey"

[model_providers.azure]
name = "Azure OpenAI / Foundry"
base_url = "https://YOUR-RESOURCE.openai.azure.com/openai/v1"
env_key = "AZURE_OPENAI_API_KEY"
wire_api = "responses"
requires_openai_auth = false

開発者の標準ワークフロー:

朝一番にターミナルで azure_codex_login を実行(MFA 通過)
同じターミナルから Codex Desktop App、CLI、または IDE を起動(環境変数を継承)

環境変数の継承注意:macOS で Spotlight やアプリランチャーから Codex Desktop App を起動するとシェル環境変数が引き継がれない。必ずターミナルから起動するか、launchctl 経由でシステム環境変数を設定する。Windows でも同様で、PowerShell プロファイルを読み込んだ後に Start-Process で起動する。

3表面の使い分けの目安:

Codex Desktop App:長時間タスク、複数並列タスク、Automations による定期実行、Git worktree 活用
Codex CLI:CI/CD パイプライン統合、スクリプト連携、コミットメッセージ生成などの細かい自動化
Codex IDE 拡張:インライン編集、コードレビュー、リファクタリング作業中の即時補助

Private Endpoint と閉域網構成(本番のみ)

本番では Foundry リソースに Private Endpoint を設定し、パブリックアクセスを無効化する。閉域網接続は Azure VPN Gateway、ExpressRoute、または Entra Private Access のいずれかを採用する。検証用サブスクリプションでは Public + IP allowlist で簡略化できる。詳細手順は割愛し、Azure 公式の Private Link ドキュメントを参照する。

5. Azure Skills Plugin の導入とスキルカタログの理解

基盤が整ったら、Azure Skills Plugin を Codex に導入する。本記事の後半すべてのフェーズで使う中核機能である。

5.1 Azure Skills Plugin のインストール

Codex CLI から以下を実行する。Codex Desktop App と IDE 拡張は同じ設定を共有するため、CLI でのインストールが3表面すべてに反映される。

# Codex CLI 内でマーケットプレースを追加(初回のみ)
/plugin marketplace add microsoft/azure-skills

# プラグインをインストール
/plugin install azure@azure-skills

# 有効化されたスキルを確認
/skills

APM(Agent Plugin Manager)を使う場合、複数のエージェントホストに一括展開できる:

# APM をインストール
npm install -g @anthropic-ai/apm

# Codex / GitHub Copilot / Claude Code / Cursor 等に同時展開
apm install microsoft/azure-skills

事前要件:Node.js 18+、Azure CLI(az login 済)、Azure Developer CLI(azd auth login 済、デプロイワークフロー利用時)。

5.2 スキルカタログの全体像

Azure Skills Plugin がインストールするスキルは、大別して以下のカテゴリに分かれる。具体的なスキル数と内訳はバージョンによって変動するため、最新は microsoft/azure-skills リポジトリで確認することを推奨する。

カテゴリ	主なスキル	用途フェーズ
ビルド・デプロイ・進化	azure-prepare、azure-validate、azure-deploy、azure-enterprise-infra-planner、azure-kubernetes 等	設計・開発・デプロイ
トラブルシュート・監視・統制	azure-diagnostics、appinsights-instrumentation、azure-compliance、azure-resource-lookup、azure-quotas、azure-kusto 等	運用・監視・障害対応
コスト最適化	azure-cost-optimization 等	保守・構成管理
セキュリティ・アクセス	azure-rbac、entra-app-registration、azure-compliance 等	全フェーズ
可視化・調査	azure-resource-visualizer、azure-resource-lookup 等	設計・運用
Foundry 専用	microsoft-foundry(オーケストレーター)、azure-ai、azure-aigateway 等	AI 関連全フェーズ

5.3 スキルの動作原理

各スキルは SKILL.md という Markdown ファイルで、「いつ発火するか」「どう振る舞うか」「何を避けるか」が記述される。Codex は2つの方法でスキルを発火させる。

暗黙的発火:プロンプトの意図が SKILL.md の description と一致した場合、Codex が自動的に該当スキルを参照する
明示的発火:プロンプト内で /skills や $skill-name のように直接指定する

つまり、開発者は基本的にスキル名を覚える必要がない。「Azure Container Apps にデプロイしたい」「コスト削減の余地を見つけて」と自然言語で依頼すれば、適切なスキルが自動的に発火し、Azure MCP Server がツールを呼び出す。

5.4 動作確認

Codex Desktop App を起動し、以下を試す。

動作確認用プロンプト

私の Azure サブスクリプションのリソースグループを一覧してください。

Codex の動作

azure-resource-lookup スキルが発火し、Azure MCP Server の azmcp_group_list ツールを呼び出す。az login 済みのアカウントの権限範囲で実際のリソースグループ一覧が返り、Codex はそれを整形してユーザーに提示する。「単に説明する」ではなく「実際にクエリを実行する」段階に達していることが確認できる。

これ以降のセクションでは、各ライフサイクルフェーズで Codex に何を依頼すれば何ができるかを、具体的なプロンプト例とともに見ていく。

Phase 1

6. 設計フェーズ:アーキテクチャ判断と IaC 生成

プロジェクトの初期段階で、Codex が「どの Azure サービスを使うべきか」「初期インフラはどう構成するか」「コストはいくらか」を判断・提案する支援を行う。設計者・アーキテクトの判断補助、または初期構築のドラフト生成として活用できる。

6.1 サービス選定:azure-prepare による分析

プロジェクトのソースコードがあるディレクトリで Codex Desktop App を起動し、以下のプロンプトを与える。

プロンプト例

このプロジェクトを Azure にデプロイしたいです。プロジェクト構造を分析し、推奨される Azure サービス、必要なインフラ、デプロイ計画を提案してください。月額予算は1万円以内を目標とします。

Codex の動作

azure-prepare スキルが発火する。Codex はまずプロジェクトのファイル構造、package.json、requirements.txt、Dockerfile の有無、フレームワーク(Flask / FastAPI / Express / Spring 等)、データベース利用の痕跡を読み取る。次に Azure MCP Server の価格取得ツールを呼び出して各候補サービスの料金を取得し、予算制約と照合する。最終的に「サービス選定の理由」「推奨される構成」「予想コスト内訳」を提示する。

Codex の出力は単なる推奨リストではなく、判断根拠を含んだ意思決定支援文書として返る。例えば「あなたのプロジェクトは Python Flask アプリで、ステートフルなセッションを持たず、HTTP リクエストのみを処理します。データベース利用の痕跡はないため Azure Container Apps が候補に挙がります。理由は1) 最小スケール0までスケールイン可能、2) 月100万リクエスト程度なら無料枠内に収まる、3) 将来的なコンテナ化・マイクロサービス化への移行が容易」といった具合に、サービス選定の論理が明示される。

6.2 既存環境のコンテキスト取得:ゼロから作らない設計

本記事のここまでの説明は、暗黙のうちに「ゼロから新規環境を構築する」前提に寄っていた。しかし実際の企業環境で発生する作業の大半は、既存環境への追加・変更である。新しいアプリを追加する、新規サブシステムをデプロイする、既存ネットワークに新しいサブネットを切る、といったケースで、Codex がゼロから設計してしまうと以下のような重大な問題が起きる。

既存リソース名と重複したリソース名を提案してしまう(Azure ではリソース名のグローバル一意性が要求される種類がある:Storage Account、Key Vault、Container Registry、App Service 等)
組織の命名規則({prefix}-{system}-{env}-{region}-{seq} など)に従っていない
既存 VNet の CIDR と重複するアドレス範囲を提案する(オンプレ ExpressRoute 接続先、ピアリング先の VNet、他部門の VNet との競合)
既存の Network Security Group ルール、Service Endpoint、Private Endpoint と矛盾する設定を生成する
部門・コストセンターのタグ命名が既存のガバナンスと不整合
同じ業務システムで既に承認された SKU・リージョン制約・ベンダー製品標準と異なる選択をする

これらは設計レビューで弾かれるべき問題だが、Codex に毎回人手でレビューさせるのは非効率である。Codex の設計段階で既存環境の文脈を自動的に取り込ませる仕組みが必要となる。

① 情報源の2系統:ドキュメント vs Azure 環境スキャン

既存環境のコンテキストは、大きく2系統の情報源から取得できる。実際の運用では両方を組み合わせる。

情報源	具体例	強み	弱み
ドキュメント系	命名規則 NRD、ネットワーク設計書、IP 管理台帳、タグガバナンス文書(Confluence / SharePoint / Notion / GitHub Wiki)	「あるべき姿」「組織標準」が記載されており、判断根拠として強い。設計レビュー対象	実態と乖離している可能性。更新が後追いになりがち
Azure 環境スキャン	Azure Resource Graph、az resource list、az network vnet list、Azure Policy assignments	「現実の状態」が取れる。最新性が保証される	「なぜそうなっているか」「何が標準か」が分からない。例外的な状態と標準の区別がつかない

結論として、本番品質の設計ではドキュメントを「あるべき姿」の根拠とし、Azure 環境スキャンで「現実との乖離」「重複の有無」を機械的に確認する二段構えが現実的である。Codex にはこの両方を文脈として与える。

② 組織標準ドキュメントを Codex に読ませる仕組み

命名規則やネットワーク設計書を Codex に取り込むには、以下のいずれかの方法を取る。

AGENTS.md への組み込み(推奨、最も簡単):命名規則の本質的なルールを AGENTS.md に転記し、リポジトリで Git 管理する。組織標準が更新されたら AGENTS.md も更新する PR を発行する運用
リポジトリ内のリファレンスファイル:docs/standards/naming-conventions.md、docs/standards/network-design.md、docs/standards/ip-allocation.md をリポジトリに置き、AGENTS.md からこれらへの参照を明記。Codex はセッション内で参照ファイルを読み込む
ドキュメント MCP Server 経由:Confluence、SharePoint、Notion 等の公式 MCP Server(または準公式の OSS 実装)を Codex に登録し、必要時に動的に取得させる。命名規則の変更を Codex に即時反映できるが、MCP Server の運用負荷とアクセス制御が必要
Microsoft Docs MCP Server:https://learn.microsoft.com/api/mcp を Codex に登録すると、Azure のベストプラクティスや CAF(Cloud Adoption Framework)の推奨命名規則を動的に参照できる。組織固有ではないが、業界標準ベースの命名規則を組み込みたい場合に有用

AGENTS.md への組み込み例:

## 9. リソース命名規則(社内標準 NRD v3.2 準拠)

### 9.1 一般原則
- 形式: {type-prefix}-{system}-{env}-{region}-{seq}
  例: rg-billing-prod-jpe-001、kv-billing-prod-jpe-001
- type-prefix の規定:
  - リソースグループ: rg
  - Storage Account: st(ハイフン不可・グローバル一意のため stbillingprodjpe001 形式)
  - Key Vault: kv
  - Container Registry: cr(ハイフン不可・グローバル一意のため crbillingprodjpe001 形式)
  - App Service: app
  - Container App: ca
  - Application Insights: appi
  - Log Analytics Workspace: log

### 9.2 system セグメント
- 必ず既存システム一覧から選ぶ。新規システム追加には IT 統制委員会承認が必要
- 既存システム一覧の最新版は docs/standards/system-registry.md を参照

### 9.3 seq セグメント
- 同一 system / env / region 内で連番。新規追加時は重複しない最小値を選ぶ

### 9.4 重複チェック
- グローバル一意リソース(Storage、Key Vault、ACR、App Service、Front Door 等)は
  実行前に必ず az resource list で重複の有無を確認すること
- ハイフン不可リソース(Storage、ACR)は形式を変えて命名すること

### 10. ネットワーク設計

### 10.1 IP アドレス範囲
- 全社の IP アドレス管理は docs/standards/ip-allocation.md を参照
- 新規 VNet 作成時は既存全 VNet との CIDR 重複を必ず確認
- オンプレ ExpressRoute 接続先の CIDR とも重複しないこと

### 10.2 Hub-Spoke 構造
- 全 VNet は中央 Hub VNet(vnet-hub-prod-jpe-001、10.0.0.0/16)にピアリングする
- Spoke VNet は 10.100.0.0/14 のレンジから割り当て
- DMZ・Public 公開は Hub VNet 経由でのみ可能

③ Azure 環境スキャン用のプロンプト例

新規リソース追加・変更の前段で、Codex に既存環境の調査を依頼する。Azure Resource Graph を活用することで、サブスクリプション横断で高速に情報取得できる。

プロンプト例(命名重複と既存リソースの調査)

これから billing サブシステムの本番環境(env=prod、region=japaneast)に新しい Container App と Key Vault を追加する予定です。実際の Bicep を書く前に、以下を調査してください: 1. AGENTS.md セクション 9 の命名規則に従ったリソース名候補を5パターン提示する(ca-billing-prod-jpe-001 から ca-billing-prod-jpe-005 等) 2. それぞれのリソース名が既存環境で使用済みでないかを az resource list で確認 3. Storage Account や Key Vault などグローバル一意リソースについては、az storage account check-name、az keyvault list で他テナント・他サブスクリプションを含む利用可能性を確認 4. billing system 配下の既存リソースを一覧化し、命名・タグ・リージョンが組織標準と整合しているかを確認 5. 新規追加によって既存リソースに影響する可能性(Storage Account のコンテナ重複、Key Vault のシークレット名空間衝突など)を洗い出す結果を docs/design/billing-add-2026-05.md として保存し、最終的に採用する命名候補を提示してください。

Codex の動作

azure-resource-lookup スキルが Azure MCP Server の Resource Graph 照会ツールを呼び、サブスクリプション全体のリソース一覧を取得する。命名候補ごとに az resource list --name <候補> で重複を確認し、グローバル一意リソースは az storage account check-name / az keyvault list で他テナントを含む可用性を確認する。AGENTS.md セクション 9 が自動参照され、命名規則違反は事前に弾かれる。結果は調査レポートとして出力され、設計レビューの基礎資料になる。

④ ネットワーク設計時の既存環境チェック

VNet・サブネット・Private Endpoint を追加する場合、既存ネットワークとの CIDR 重複は深刻な問題を引き起こす(ルーティング不能、ピアリング失敗、オンプレ接続不可)。Codex に IaC を生成させる前に、既存ネットワーク全体を確認させる。

プロンプト例(ネットワーク設計の事前確認)

billing サブシステム用に新しい Spoke VNet を作成します。AGENTS.md セクション 10 によると Spoke 用レンジは 10.100.0.0/14 です。以下の手順で進めてください: 1. docs/standards/ip-allocation.md を読み、現在割り当て済みの全 CIDR を把握 2. az network vnet list でサブスクリプション内の全 VNet と AddressSpace を取得し、ドキュメントとの整合性を確認(乖離があれば指摘) 3. オンプレ側の既存 CIDR(docs/standards/onprem-networks.md 参照)とも重複がないかを確認 4. 推奨される新規 VNet の CIDR 候補を3つ提示(10.104.0.0/20 等) 5. それぞれの候補について、ピアリング予定先 Hub VNet (vnet-hub-prod-jpe-001) との競合がないことを確認 6. 各候補の利点と欠点(将来拡張余地、サブネット分割の柔軟性、ルーティング複雑度)を比較 7. 最終的に1案を推奨し、その Bicep 定義を生成ネットワーク変更は影響範囲が大きいため、推奨案には必ず根拠を3点以上付けてください。

Codex の動作

Codex は組織標準ドキュメント(docs/standards/ip-allocation.md、onprem-networks.md)と Azure 上の実態(az network vnet list)を両方取得し、両者の差分を抽出する。ドキュメントには載っていないが実在する VNet、逆に台帳上は存在するが Azure には無い VNet を「データ整合性の問題」として報告する。次に新規 CIDR 候補を計算する際は、Spoke レンジ(10.100.0.0/14)内で既存割り当て済みを除外し、十分なサブネット分割余地を確保した候補を提示する。

⑤ 「Azure 全環境を毎回スキャンするのか」という設計判断

Codex に毎回 Azure 環境全体をスキャンさせると、以下の問題が発生する。

大規模組織では数千〜数万のリソースがあり、フルスキャンは数十秒〜数分かかる
Azure Resource Graph のスロットリング(クエリ数制限)に達する可能性
Codex のコンテキストウィンドウを圧迫する(全リソース情報を取り込むとプロンプトが肥大化)
セキュリティ的に、設計者が読み取り権限を持っていないリソースまで意図せず読もうとして失敗する

これを避けるため、組織として以下のいずれかのポリシーを定める。

ポリシー	適用条件	運用
ドキュメント優先	命名・ネットワーク台帳がよく整備されている組織	AGENTS.md と docs/standards/ を主参照源とし、Azure スキャンは命名重複の最終確認のみ
スコープ限定スキャン	サブスクリプション・リソースグループが業務単位で分かれている組織	変更対象のサブスクリプション・リソースグループに限定して Azure Resource Graph をクエリ
キャッシュ + 増分更新	大規模で台帳整備が不十分な組織	定期バッチ(週次等)で Azure 全環境をスキャンし `docs/inventory/current-state.json` としてリポジトリに保存。Codex はこれを参照
ハイブリッド	大半の組織で現実的	ドキュメントを主、スコープ限定スキャンを副、重要な変更時のみフルスキャンを実施

本記事の構成では「ドキュメント優先 + スコープ限定スキャン」のハイブリッドを推奨する。AGENTS.md と docs/standards/ が命名・ネットワーク・セキュリティの「正」であり、Azure 環境スキャンはその裏付けとして変更対象に限定して実行する。

⑥ 既存環境との整合性確認チェックリスト

Codex に IaC を生成させる前に通過すべきチェック項目を、AGENTS.md に組み込んでおく。

## 11. 新規リソース追加時の事前確認チェックリスト

Codex は新規 Azure リソースを追加する Bicep / Terraform を生成する前に、
以下を必ず確認すること。確認結果を生成物の冒頭にコメントとして記載する。

### 11.1 命名規則チェック
- [ ] AGENTS.md セクション 9 の命名規則に従っているか
- [ ] グローバル一意リソース(Storage、KV、ACR、App Service)で名前重複がないか
- [ ] seq セグメントは既存最大値 +1 になっているか

### 11.2 ネットワーク整合性チェック
- [ ] 新規 VNet/Subnet の CIDR が既存と重複していないか
- [ ] AGENTS.md セクション 10 の Hub-Spoke 構造に従っているか
- [ ] オンプレ ExpressRoute 接続先 CIDR との競合がないか
- [ ] Private Endpoint の DNS Zone が既存と整合しているか

### 11.3 タグ・コストガバナンスチェック
- [ ] 必須タグ(env, system, owner, cost-center, data-classification)が全て付与
- [ ] cost-center が経理システムに登録された有効なコードか
- [ ] SKU が部門の承認上限を超えていないか

### 11.4 セキュリティ・コンプライアンスチェック
- [ ] Azure Policy assignments に違反していないか(az policy state list で確認)
- [ ] 業務データの data-classification に応じた暗号化要件を満たすか
- [ ] 必要な RBAC ロール割り当ては最小権限の原則に従っているか

### 11.5 既存システムへの影響チェック
- [ ] 同一 system タグの既存リソースとの依存関係を確認
- [ ] 既存サービスへの負荷影響(共有 App Service Plan 等)を確認
- [ ] 既存の診断ログ送信先(Log Analytics)の容量影響を見積もり

### 11.6 出力時の必須コメント
生成された Bicep / Terraform の冒頭に以下を含めること:
// 命名重複チェック: 実施日時、確認方法、結果
// CIDR 競合チェック: 実施日時、確認した既存 VNet 数、結果
// 影響範囲: 影響を受ける可能性のある既存リソース一覧

⑦ 既存リソースの変更時の追加考慮

新規追加だけでなく、既存リソースの変更(SKU 変更、設定値変更、IAM 再構成等)では、Section 13.6 で示した Before / After スナップショット機構と、本節で示した既存環境チェックの両方が必要になる。Codex に変更系の作業を依頼する場合、以下の流れになる。

変更対象の特定とその現在状態の取得(az resource show)
変更による影響範囲の調査(依存リソース、共有リソース、関連 Azure Policy)
変更案の生成(IaC ファイルの差分として)
変更案の組織標準・既存ネットワーク・既存 IAM との整合性確認
変更管理チケットへの記録、承認取得
Codex Hooks の PreToolUse / PostToolUse で Before / After スナップショットを記録しながら実行

この流れにより、ゼロから作る場合も、既存環境への追加・変更も、同じ品質基準で Codex の支援を受けられる。

6.3 初期 IaC ファイルの生成

6.2 で既存環境のコンテキスト調査と命名・ネットワークの整合性確認が完了している前提で、Bicep または Terraform で IaC ファイルを生成させる。6.2 を経ずに直接生成すると、組織標準に違反したり既存環境と競合したりするリスクがあるため、6.2 と 6.3 は対で実行することを推奨する。

プロンプト例

6.2 で確認した命名・ネットワーク整合性に基づき、以下のリソースを Bicep で定義してください: - リソースグループ: rg-myapp-prod-japaneast(命名確認済み) - Azure Container Apps Environment と Container App(命名確認済み) - Azure Container Registry(Basic SKU、グローバル一意性確認済み) - Application Insights と Log Analytics ワークスペース - Key Vault(RBAC モード、グローバル一意性確認済み) - Managed Identity を Container App に割り当て、Key Vault と Container Registry へのアクセス権限を付与すべてのリソースには AGENTS.md セクション 9 の必須タグを付与してください: env=prod、system=myapp、owner=team-x、cost-center=cc-001、data-classification=internal infra/main.bicep として生成し、azure.yaml も合わせて作成してください。生成された Bicep の冒頭には、AGENTS.md セクション 11.6 に従い、命名重複チェック・CIDR 競合チェック・影響範囲の3点をコメントとして記載してください。

Codex の動作

azure-prepare スキルと azure-resource-visualizer スキルが連動して動く。Codex は Bicep のベストプラクティス(モジュール分割、パラメータ化、出力定義)に従いつつ、Azure MCP Server のスキーマ照会ツールを呼ぶ。AGENTS.md セクション 9 から命名規則、セクション 11 のチェックリストを参照し、6.2 のレポートに記載されたチェック結果を Bicep 冒頭のコメントとして転記する。Managed Identity と RBAC の組み合わせは azure-rbac スキルが補助して、最小権限の原則に沿った定義を生成する。出力されるファイルは infra/main.bicep(主定義)、infra/main.bicepparam(環境ごとのパラメータ)、azure.yaml(azd マニフェスト)の3点となる。

6.4 アーキテクチャ図の生成

非技術者やレビュー担当者への説明資料として、Mermaid 形式のアーキテクチャ図を生成する。

プロンプト例

infra/main.bicep の内容に基づき、Azure リソース間の関係を Mermaid 図で生成してください。Container App から各依存サービス(ACR、Key Vault、Application Insights、Log Analytics)への関係性を矢印で示し、Managed Identity の流れも明示してください。生成した図は docs/architecture.mmd に保存してください。

Codex の動作

azure-resource-visualizer スキルが発火する。Codex は IaC ファイルから依存関係を抽出し、Mermaid の graph LR または flowchart TD 構文で図を生成する。実際にデプロイ済のリソースを対象にする場合は Azure Resource Graph をクエリして関係性を抽出する。生成された図は GitHub やはてなブログでもそのまま表示できる。

6.5 コスト試算と最適化

プロンプト例

infra/main.bicep に定義したリソースの月額コストを Azure Retail Prices API から取得して試算してください。複数のシナリオ(低トラフィック:月10万リクエスト、中トラフィック:月100万リクエスト、高トラフィック:月1000万リクエスト)で比較し、コスト削減の余地があれば提案してください。

Codex の動作

azure-cost-optimization スキルが Azure MCP Server の価格取得ツールを呼び出して、各リソースの単価を取得する。Container Apps のスケーリングを考慮し、トラフィックシナリオごとの実行時間とリクエスト数から月額を試算する。例えば「低トラフィック時は scale-to-zero で月 500 円、中トラフィックでは月 3,500 円、高トラフィックでは月 15,000 円。Application Insights のサンプリング率を下げれば最大40%削減可能」といった具体的な提案を返す。

6.6 セキュリティ・コンプライアンスのプリチェック

プロンプト例

私たちの組織は ISO 27001 認証を取得しており、すべての Azure リソースが以下を満たす必要があります: - データの暗号化が有効(Microsoft Managed Keys 以上) - すべての public エンドポイントが TLS 1.2 以上 - Managed Identity を使った認証(クライアントシークレット禁止) - 監査ログが30日以上保持される infra/main.bicep がこれらに準拠しているか確認し、違反があれば修正案を Pull Request 形式で提示してください。

Codex の動作

azure-compliance スキルが ISO 27001 / SOC 2 / FedRAMP などの一般的なコンプライアンスフレームワークに基づいて Bicep ファイルを検査する。各リソースの暗号化設定、TLS バージョン、認証方式、診断設定を1つずつ評価し、違反箇所と修正パッチを提示する。修正は単なる指摘ではなく、差分ベースの具体的なコード(encryption: { keySource: 'Microsoft.KeyVault' } の追加など)として返る。

Phase 2

7. 開発フェーズ:アプリケーションコードと組織標準の遵守

設計が固まったら、アプリケーションコードを実装する。Codex はコード生成だけでなく、Azure SDK の正しい使い方、組織固有のコーディング規約、テストカバレッジまでを支援する。

7.1 AGENTS.md による組織標準の注入

Azure Skills の公開スキルだけでは、組織固有の慣行は反映されない。リポジトリのルートに AGENTS.md を置くと、Codex はすべてのセッションでこのファイルを参照する。

# AGENTS.md

## 1. プロジェクトのコンテキスト
[会社名] の [プロジェクト名]。
業界:[金融 / 製造 / 医療 等]
規制要件:[該当する規制を明記]

## 2. Azure 環境
- 本番サブスクリプション ID: [GUID]
- 命名規則: {prefix}-{system}-{env}-{region}-{seq}
  例: rg-billing-prod-jpe-001
- リージョン制約: japaneast / japanwest のみ
- 全リソースに必須のタグ:
  env、system、owner、cost-center、data-classification

## 3. コードスタイル
- Python: PEP 8 準拠、Black フォーマット、行幅 100 文字
- TypeScript: ESLint Airbnb 設定、Prettier フォーマット
- すべての関数は型ヒント / 型注釈を必須とする

## 4. Azure SDK 利用ルール
- 認証: DefaultAzureCredential を必須使用
- 接続文字列のハードコード禁止、すべて Key Vault 経由
- API キー方式の利用は明示的な例外申請が必要

## 5. テスト方針
- ユニットテストカバレッジ 80% 以上
- 統合テストは moto / azurite を活用
- すべての PR は CI でテストが通ること

## 6. セキュリティ規約
- 認証情報のハードコード禁止
- すべての secret は Key Vault 経由
- 顧客 PII を含むコードを Codex に与えてはならない

## 7. コードレビュー基準
- すべての変更は PR 経由
- セキュリティ感応な変更はセキュリティチームの追加レビュー必須

## 8. Codex モデル選択ルール
- 既定(ほとんどのタスク): gpt-5-5-prod(OpenAI 公式推奨の第一選択)
- GPT-5.5 が利用できない場合のフォールバック: gpt-5-4-prod
- 軽量サブエージェント・コスト最適化: gpt-5-4-mini-prod
- 特殊用途(長時間エージェント・Cloud Tasks 等)で必要時のみ: gpt-5-3-codex-prod
- モデル切り替えは AGENTS.md の更新を伴うこと(変更履歴を Git に残す)

## 9. リソース命名規則
(Section 6.2 で詳述。社内 NRD v3.2 準拠の命名規則をここに転記する)

## 10. ネットワーク設計
(Section 6.2 で詳述。Hub-Spoke 構造、CIDR 割り当て、オンプレ接続を記載する)

## 11. 新規リソース追加時の事前確認チェックリスト
(Section 6.2 で詳述。命名重複・CIDR 競合・タグ・セキュリティ・影響範囲のチェック項目)

AGENTS.md はリポジトリの一級ファイルとして Git 管理する。テンプレート化して全プロジェクトに展開する。

Azure Skills の中核は、azure-prepare → azure-validate → azure-deploy の3ステップワークフローである。これら3つは個別に呼び出すこともできるが、開発者は通常「デプロイしてください」と依頼するだけで、Codex が3ステップを自動連鎖させる。

8.1 3ステップワークフローの全体像

azure-prepare → azure-validate → azure-deploy の連鎖

azure-prepare:プロジェクトの分析、Azure サービスの推奨、Bicep / Dockerfile / azure.yaml の生成。デプロイ計画を策定する。

azure-validate:IaC のシンタックスチェック、azure.yaml の妥当性確認、Azure CLI 認証の検証、必要な権限の確認、クォータの確認、デプロイ失敗を引き起こす要因の事前スキャン。実質的に「Dry Run」として機能する。

azure-deploy:azd up を実行し、インフラのプロビジョニング、コンテナイメージのビルド・プッシュ、コードのデプロイを行う。完了後にライブ URL を返す。

8.2 単一プロンプトによるエンドツーエンドデプロイ

プロンプト例

この Python Flask API を Azure にデプロイしてください。本番環境(rg-myapp-prod-japaneast)にデプロイし、デプロイ後の URL を教えてください。

Codex の動作

Codex は3つのスキルを自動的に連鎖させる。まず azure-prepare がプロジェクトを分析し、Bicep ファイルがまだなければ生成する。次に azure-validate がデプロイの前提条件(認証、クォータ、権限、Bicep のシンタックス)を確認し、問題があれば修正を提案する。最後に azure-deploy が azd up を実行する。各ステップの進捗が Codex Desktop App の UI 上にリアルタイム表示され、エラーが発生すれば原因と対処を即時に提示する。

8.3 個別ステップの明示的実行

制御を細かく行いたい場合、各ステップを個別に呼ぶ。

プロンプト例(検証のみ)

infra/main.bicep を本番にデプロイする前に、検証だけ実行してください。クォータが足りているか、必要な権限があるか、Bicep に構文エラーがないかを確認してください。

Codex の動作

azure-validate が独立して実行される。Azure MCP Server のクォータ取得ツールでリージョン別の利用状況を取得し、デプロイで消費する vCPU や接続数が上限内かを確認する。RBAC 上の権限不足があれば「Storage Blob Data Contributor が rg-myapp-prod に付与されていません」と具体的に指摘する。デプロイ実行はしない。

8.4 Azure DevOps を中核に据えない理由(GitHub Enterprise Cloud を推奨する根拠)

Azure 開発の現場では、ソースコード管理に Azure Repos、課題管理に Azure Boards、CI/CD に Azure Pipelines を使う構成 ── つまり Azure DevOps を中核に据えた構成が長年標準とされてきた。Microsoft の他サービスとの統合、Entra ID とのネイティブ連携、エンタープライズ契約での価格メリットを考えれば、今でも合理的な選択である。本記事の構成でも Azure DevOps が既存資産として運用されているなら、引き続き活用すべきである。

一方で、本記事が GitHub Enterprise Cloud + GitHub Actions + GitHub Issues(または Jira) を中核として推奨するのは、Codex を中心とした開発ワークフローを構築する際に、現時点で Azure DevOps では構造的に解決しにくい制約が複数存在するためである。「Azure DevOps が悪い」のではなく、「Codex と組み合わせる前提では現状 GitHub 側の統合度合いが高い」というのが本記事の判断である。具体的な根拠を以下に整理する。

本章の読み方:GitHub Enterprise Cloud が使える組織では、本章の構成が最有力。Azure DevOps を全社標準として運用している組織では、本章のワークフローは「置換」ではなく「併用」または「一部移植」として読むのが現実的である。Azure Boards / Pipelines を維持しつつ、Codex 連携が必要な部分のみ GitHub 側に寄せる、という構成も成立する。具体的な回避策は本章末尾(⑥)に整理した。

① Codex CLI / Desktop App が Azure DevOps Remote MCP Server に接続できない(2026年5月時点)

Microsoft は2026年3月、Azure DevOps Remote MCP Server を Public Preview として公開した。これによりエージェントから Azure DevOps の Work Item、Pull Request、Pipeline、Repos に MCP プロトコル経由でアクセスできるようになった ── ように見える。しかし公式ドキュメントに以下の重要な制約が明記されている:

追加設定なしでサポートされるクライアントは Visual Studio と VS Code のみ
Codex(Desktop App / CLI)、Claude Desktop、Claude Code、ChatGPT、GitHub Copilot CLI は、Microsoft Entra に OAuth Client ID を動的登録する必要があり、現時点では未対応
Microsoft は Entra チームと連携して対応中だが、完了時期は公表されていない
Azure DevOps Services のみサポート ── オンプレの Azure DevOps Server は API endpoint 不足で非対応
Standalone organization(MSA バック)は非対応 ── Entra ID 連携の組織のみ

これは「Codex Desktop App / CLI から Azure DevOps の Work Item を読み取って自動でタスクを実行する」「PR を作成する」「Pipeline 状況を取得する」といった、本記事の中核となる連携ができないことを意味する。一方 GitHub は OpenAI 公式の ChatGPT Connector と Codex Cloud で標準的にサポートされており、Codex Desktop App から直接の連携が初期状態で利用できる。

変化の速さに注意:本節の Azure DevOps Remote MCP Server に関する制約は、2026年5月時点で筆者が公式ドキュメントを確認した内容に基づく。Microsoft は Entra チームと連携して対応を進めており、Codex / Claude / ChatGPT 等のサポートは比較的近い将来に追加される可能性が高い。導入検討時は公式ドキュメントと Azure DevOps Blog で最新状況を確認することを推奨する。本節の判断は「現時点で確実に動く構成」を優先しているが、対応が進めば Azure DevOps を中核に据える構成も再評価の余地がある。

② Microsoft 自身の戦略的投資が GitHub 側に集中している

2026年現在、Microsoft の AI 開発支援機能(GitHub Copilot、GitHub Copilot Workspace、GitHub Copilot Autofix、GitHub Copilot Chat、PR Code Review 自動化等)はすべて GitHub 側に投入されている。Azure DevOps 側の AI 統合は Remote MCP Server 経由でアクセスを「提供する」立場で、Azure DevOps 自体が AI ネイティブのワークフローを生み出す方向には進んでいない。microsoft/azure-devops-mcp リポジトリの READMEでも、ローカル MCP Server は将来的に Remote MCP Server に置き換える方針が示されており、エコシステムは「Azure DevOps はオーケストレーション層、AI 連携の最前線は GitHub」という分業に明確に分岐している。

③ Codex Cloud と @codex メンション機能の連携先は GitHub のみ

Codex Cloud のタスク並列実行、GitHub Issues / PR への @codex メンションによるタスク起動、Pull Request での自動レビューといった機能は、OpenAI の ChatGPT GitHub Connector を経由する設計になっている。Azure DevOps の Work Item や PR で同等の体験を得るには、現状では Azure DevOps と GitHub を双方向連携(GitHub for Azure DevOps 拡張など)させた上で GitHub 側にミラーする運用が必要で、二重管理の複雑さが発生する。

④ GitHub Enterprise Managed Users(EMU)で Entra ID 統合は満たせる

Azure DevOps を選ぶ動機の一つに「Entra ID とのネイティブ連携」がある。これは正しいが、GitHub Enterprise Cloud には Enterprise Managed Users(EMU)という機能があり、ユーザーアカウントを企業の Entra ID にバインドできる。SCIM プロビジョニング、Conditional Access、退職時の自動デプロビジョニングが Entra ID 経由で動作するため、エンタープライズの ID ガバナンス要件はほぼ満たせる。実質的に Entra ID 連携で Azure DevOps を選ぶ強い理由は薄まっている。

⑤ GitHub Actions と Azure の OIDC 連携が成熟している

本記事で詳述する OIDC 認証(Federated Identity Credential)による Azure デプロイは、GitHub Actions 側で 2022年に標準化されて以降、ドキュメント・ベストプラクティス・事例が豊富に蓄積されている。Azure Pipelines にも同等の Workload Identity Federation が存在するが、Codex が生成するワークフローも、Microsoft Learn の参照ドキュメントも、GitHub Actions パターンが大多数を占めている。Codex に「デプロイワークフローを書いて」と依頼した時の出力品質と再現性が、GitHub Actions の方が高い。

⑥ それでも Azure DevOps を使う場合の妥協点と回避策

以下に該当する組織では、Azure DevOps を継続採用する判断は妥当である:

既に Azure DevOps が全社標準として運用されており、移行コストが過大
オンプレ Azure DevOps Server を運用しており、データ所在地の制約から GitHub Cloud に移れない
Microsoft Enterprise Agreement の包括契約に Azure DevOps が含まれており、GitHub Enterprise を別途契約する追加コスト負担が大きい
Azure Boards のエンタープライズ機能(ポートフォリオ管理、ガントチャート、複数プロジェクト横断等)が業務要件として必須

その場合の現実的な回避策:

VS Code 経由の Azure DevOps MCP 利用:Codex の代わりに、または並行して、VS Code + GitHub Copilot Chat 経由で Azure DevOps Remote MCP Server を活用する。Codex Desktop App と VS Code を場面によって使い分ける運用
非公式の az CLI 経由 MCP サーバー:az-devops-cli-mcp のような pip パッケージで、az CLI をラップした stdio MCP Server を Codex CLI に登録する方法がコミュニティで提供されている。ただし公式サポート対象外で、本番展開の前にセキュリティチームの審査が必要
Azure Pipelines を CI/CD に維持:ソースコードを Azure Repos、CI/CD を Azure Pipelines のままにし、Codex はローカル開発と Bicep 生成のみに使う構成。Codex Cloud や Codex の自動 PR 機能は犠牲になるが、既存の Azure DevOps 統制を維持できる
GitHub と Azure DevOps の双方向同期:ソースコードは GitHub Enterprise Cloud、課題管理は Azure Boards、CI/CD は Azure Pipelines という分業。Azure Boards と GitHub の連携機能で双方向同期する。両ツールの利点を取れるが、運用が複雑化

本記事の Step 8 以降の手順は GitHub Enterprise Cloud + GitHub Actions を前提として書かれているが、上記の回避策を採用すれば Azure DevOps 主体の環境でも本質的な部分(Foundry、Azure Skills Plugin、Hooks による監査、運用フェーズの Codex 活用)はそのまま適用できる。重要なのは「Codex のすべての連携機能を引き出すには GitHub 中心が現状の最適解」という事実を踏まえた上で、組織の既存資産と要件のバランスを取ることである。

8.5 GitHub Actions との OIDC 連携

Codex Desktop App から手動デプロイを実行する以外に、CI/CD パイプラインを構築する場合も Codex が支援する。

プロンプト例

main ブランチへのプッシュで本番にデプロイする GitHub Actions ワークフローを生成してください。要件は以下: - OIDC 認証(クライアントシークレットを使わない) - GitHub Environment "production" を使い、Required reviewers を設定する前提 - デプロイ前にユニットテストを実行 - デプロイ後にスモークテストを実行(エンドポイントへの HEAD リクエスト) - 失敗時には Slack の #deployment-alerts チャネルに通知 .github/workflows/deploy-prod.yml として生成してください。Federated Identity Credential の設定手順も README.md に追記してください。

Codex の動作

azure-deploy スキルと entra-app-registration スキルが連動する。Codex は azure/login@v2 アクション、id-token: write パーミッション、environment の指定など OIDC 認証のベストプラクティスを反映したワークフローを生成する。Federated Identity Credential の作成手順も az ad app federated-credential create コマンドベースで README.md に追記される。Slack 通知は slackapi/slack-github-action を使った標準実装。

8.6 マルチ環境管理

プロンプト例

現在の Bicep ファイルは本番(prod)用ですが、これを開発(dev)と検証(stg)環境にも対応できる構造にリファクタリングしてください。環境ごとに以下を変えたい: - App Service Plan の SKU(dev=B1、stg=S1、prod=P1v3) - Application Insights のサンプリング率(dev=100%、stg=50%、prod=10%) - Foundry のモデル名(dev=gpt-5-4-mini-dev、stg=gpt-5-4-stg、prod=gpt-5-5-prod) Bicep モジュール化、main.bicepparam の環境別ファイル作成、azd の azure.yaml への環境定義追加を行ってください。

Codex の動作

azure-prepare と azure-enterprise-infra-planner が連動する。Codex は Bicep を main.bicep(エントリポイント)、modules/app-service.bicep、modules/foundry.bicep 等にモジュール分割する。環境別パラメータファイル(main.dev.bicepparam、main.stg.bicepparam、main.prod.bicepparam)を生成し、azure.yaml にも environments: セクションを追加する。これにより azd env select dev → azd up で環境を切り替えられる構成になる。

Phase 4

9. 運用・監視フェーズ:Application Insights と KQL

デプロイされたシステムを継続的に監視し、異常を検知する。Codex は Application Insights、Log Analytics、Azure Monitor アラート、ダッシュボードの構築と運用を一貫して支援する。

9.1 Application Insights の計装

プロンプト例

app/ 配下の Python コードに Application Insights の計装を入れてください。要件は以下: - OpenTelemetry SDK 経由(opencensus は使わない) - 自動計装(automatic instrumentation)を最大限活用:Flask、requests、Azure SDK 呼び出しを自動でトレース - カスタムスパンを以下の3関数に追加: - app/storage_service.py の upload_image() - app/ai_summarizer.py の summarize() - app/database.py の execute_query() - すべてのリクエストにユーザー ID(認証コンテキストから)とリクエスト ID(uuid)を attribute として付与 - サンプリング率は環境変数 APP_INSIGHTS_SAMPLING_RATE から読み込む(デフォルト10%) - Application Insights の接続文字列は環境変数 APPLICATIONINSIGHTS_CONNECTION_STRING から取得

Codex の動作

appinsights-instrumentation スキルが OpenTelemetry の Azure Monitor Exporter の最新の使い方に基づいてコードを生成する。azure-monitor-opentelemetry パッケージを使った1行セットアップ(configure_azure_monitor())、Flask の自動計装、カスタムスパンの追加方法を反映したコードを返す。サンプリング率の動的設定も適切に組み込まれる。

9.2 監視ダッシュボードの生成

プロンプト例

本番アプリの運用ダッシュボードを Azure Portal に作成してください。表示したいメトリクス: - App Service: リクエスト数(直近24時間)、平均応答時間、P95 応答時間、エラー率(HTTP 5xx) - Foundry: API 呼び出し数、入出力トークン数、推論レイテンシ - Storage: Blob トランザクション数、容量、エラー率 - Application Insights: 失敗したリクエスト、例外発生数、依存関係呼び出しの失敗レイアウトは2列×4行とし、infra/dashboard.bicep として生成してください。main.bicep からモジュール参照する形に修正してください。

Codex の動作

azure-prepare と appinsights-instrumentation が連動して、Azure Portal Dashboard リソース(Microsoft.Portal/dashboards)を Bicep で定義する。各タイルには Azure Monitor Metrics または Application Insights のクエリが組み込まれる。dashboard.bicep は main.bicep からモジュール参照される構造になる。

9.3 KQL クエリによる詳細調査

プロンプト例

直近24時間で、Container App "myapp-prod" のエラーレートが上昇しているか調査してください。エラーの内訳を時系列で集計し、特に多発しているエラーパターンを特定してください。

Codex の動作

azure-kusto と azure-diagnostics スキルが KQL クエリを生成し、Azure MCP Server のログクエリツールを呼び出して Log Analytics ワークスペースで実行する。例えば以下のクエリが自動生成・実行される:

ContainerAppConsoleLogs_CL
| where TimeGenerated > ago(24h)
| where ContainerAppName_s == "myapp-prod"
| where Log_s contains "ERROR" or Log_s contains "Exception"
| summarize count() by bin(TimeGenerated, 1h), 
  ErrorType = extract(@"([A-Z][a-zA-Z]+Error|[A-Z][a-zA-Z]+Exception)", 1, Log_s)
| render timechart

結果は Codex がさらに要約し、「14時から急増したのは ConnectionTimeoutError で、外部 API への呼び出しがタイムアウトしている。直近にデプロイされた v1.2.3 で接続プールのサイズが変更されたことが原因の可能性が高い」といった洞察を返す。

9.4 アラート設定

プロンプト例

以下の条件で本番アプリにアラートを設定してください: - HTTP 5xx エラー率が5分間に5%を超えたら、Severity 1 のアラート - Foundry の推論レイテンシ P95 が5秒を超えたら、Severity 2 のアラート - App Service の応答時間 P95 が3秒を超えたら、Severity 3 のアラート - 月間予算の80%に達したら、Severity 2 のアラート通知先は SIRT チームの Slack(#sirt-alerts)とメーリングリスト(sirt@example.com)。これらを Bicep で定義し、main.bicep に統合してください。

Codex の動作

appinsights-instrumentation スキルが Azure Monitor アラートルール(Microsoft.Insights/metricAlerts、Microsoft.Insights/scheduledQueryRules)と Action Group(Microsoft.Insights/actionGroups)を Bicep で定義する。Slack 通知は Logic Apps または Azure Functions 経由のカスタム Webhook として実装され、適切な Severity に応じた通知ルーティングが組み込まれる。

9.5 SLO / SLI の定義と監視

プロンプト例

Bicep ファイルで定義したインフラと、実際にデプロイされているインフラの差分(ドリフト)を検出する。

プロンプト例

infra/main.bicep で定義した内容と、rg-myapp-prod-japaneast に実際にデプロイされているリソースに差分はありますか?もしあれば、その差分を一覧化し、Bicep を実態に合わせるべきか、実態を Bicep に合わせて修正すべきかを判断してください。

Codex の動作

Codex は az deployment group what-if を Azure MCP Server 経由で実行し、Bicep のデプロイがあった場合に何が変更されるかを取得する。差分があれば、それぞれの項目について「なぜ実態がそうなっているか」(過去のデプロイ履歴、手動変更の痕跡)を Activity Log と照合して推察する。最終的に「App Service Plan の SKU が Bicep では B1 だが実態は S1 になっている。これは2026年4月15日に手動で変更された痕跡があり、原因は本番トラフィック増加対応と思われる。Bicep を S1 に更新するのが妥当」といった判断を提示する。

11.2 コスト最適化スキャン

プロンプト例

私の Azure サブスクリプション全体のコスト最適化の余地をスキャンしてください。具体的には以下: - 使われていないリソース(過去30日間アクセスのない Storage、停止中の VM、空の Resource Group) - オーバーサイズなリソース(利用率の低い App Service Plan、過剰な PTU) - 古い世代の SKU を使っているリソース(Dv2 系の VM、Premium v1 の App Service など) - Reserved Instance や Savings Plan で割引できる候補 - ストレージのアクセス層が不適切(Cool で十分なのに Hot のもの) それぞれについて、削減見込み額と推奨アクションを提示してください。

Codex の動作

azure-cost-optimization スキルが Azure Cost Management API と Azure Advisor、Azure Resource Graph を組み合わせて分析を行う。各候補について実利用率と単価を取得し、年間削減見込み額を計算する。出力は「優先度高:Foundry の PTU を 50 から 30 に削減で年 540 万円削減(過去30日の利用率は実測35%)」「優先度中:Premium v1 の App Service Plan を Premium v3 にマイグレーションで年 240 万円削減」といった具体的な提案。承認すれば Codex はマイグレーション用の Bicep 変更も生成する。

11.3 セキュリティ・コンプライアンス監査

プロンプト例

月次のコンプライアンス監査を実行してください。チェック項目: 1. すべての Storage Account が「Public アクセス不可」になっているか 2. すべての Key Vault が「Soft Delete」と「Purge Protection」を有効化しているか 3. すべての App Service が HTTPS 強制になっているか 4. すべてのリソースに必須タグ(env、system、owner、cost-center、data-classification)が付いているか 5. RBAC ロール割り当てで、過剰権限(Owner、User Access Administrator が個人に付与)がないか 6. Public IP を持つリソースで、NSG が適切に設定されているか 7. 過去30日に Conditional Access ポリシーをバイパスしたサインインがないか結果をレポート形式で docs/audit/2026-05-monthly-audit.md に保存し、違反項目には修正案も添えてください。

Codex の動作

azure-compliance と azure-rbac スキルが連動する。Codex は各チェック項目について Azure Resource Graph や Microsoft Defender for Cloud の Recommendations API を呼び出してデータを取得する。違反項目があれば、修正に必要な Bicep 変更や az CLI コマンドを提示する。レポートはマネージメント向けの要約と、技術者向けの詳細を両方含む構造になる。

本番作業の鉄則は「いきなり変更しない」である。コマンド実行や IaC デプロイの前に、その変更が既存システムに与える影響を分析し、影響範囲・ダウンタイム・ロールバック手順を文書化し、人間がレビュー・承認したうえで初めて実行に移る。本セクションでは Azure Skills の限界を踏まえつつ、Codex で影響分析(Change Impact Analysis / Blast Radius Analysis)を体系化する方法と、Codex CLI の Plan モードを企業の変更管理プロセスに統合する具体的な手順を扱う。

12.1 影響分析が必要な理由と Azure Skills の限界

本番環境への変更で、影響分析を省略してはいけない理由は単純である:変更の結果は実行してみないと分からない、しかし実行してから「想定外でした」では取り返しがつかない。Codex のような AI エージェントは応答に揺れがあり、人間の操作よりも「予期せぬ波及」を起こしやすい。だからこそ、本番作業に着手する前段で「何が起きるか」を可能な限り言語化・文書化することが必須となる。

典型的に問われるべき項目:

影響範囲(Blast Radius):変更対象リソースに依存しているリソース・サービス・アプリケーションは何か。直接依存だけでなく、推移的依存(A → B → C)まで含めて把握する
ダウンタイムの有無:変更中・変更後に対象サービスが停止するか、応答が一時的に劣化するか。SLA・SLO への影響
外部システムへの波及:Private Endpoint 経由で接続している外部システム、Webhook 配信先、API クライアント、オンプレ連携への影響
データの保護:変更によりデータ消失・破損のリスクがあるか。バックアップ取得済みか、ポイントインタイムリストアが可能か
セキュリティ姿勢への影響:RBAC ロール、ネットワーク露出、暗号化、認証方式の変化
コスト変動:変更によって月次コストがどう変わるか、想定外の課金が発生しないか
ロールバック可能性:変更が想定通りいかなかった場合に、元の状態に戻せるか。戻すための時間とコスト
承認の取得状況:CAB(Change Advisory Board)承認、システムオーナー承認、変更管理チケットの状態

Azure Skills は何をカバーし、何をカバーしないか

Azure Skills Plugin が提供する25のスキルのうち、変更前検証に関連するものとしては azure-validate が最も近い。これは azure-deploy の前段で、Bicep の構文・クォータ・認証・必要な権限・デプロイ失敗を引き起こす要因を事前確認する pre-flight チェックである。ただし、これはあくまで「デプロイが技術的に成功するか」の検証であり、「本番システムが影響を受けるか」の影響分析ではない。

類似のスキルである azure-resource-visualizer は既存リソース構成の可視化を行うが、変更による影響を機械的に算出する機能は持たない。azure-diagnostics は障害後の診断であり、変更前の影響予測ではない。

つまり、2026年5月時点の Azure Skills Plugin には本格的な変更影響分析(Change Impact Analysis)や Blast Radius Analysis に特化したスキルは存在しない。これは Azure Skills の弱点というより、影響分析が「組織固有の依存関係・SLO・承認プロセスに強く依存する作業」であり、汎用スキルにしにくい性質を持つためである。したがって、企業として影響分析を体系化するには、Codex のプロンプト設計と組織カスタムのワークフロー、そして Plan モードの活用を組み合わせる必要がある。

12.2 影響分析の標準プロンプトテンプレート

本番変更に着手する前段で、Codex に必ず実行させるべき影響分析のプロンプトをテンプレート化する。AGENTS.md または docs/templates/impact-analysis-prompt.md に保存して、変更系作業の入口で必ず使う運用にする。

影響分析プロンプトテンプレート

これから {対象環境} の {対象リソース} に対して {操作内容} を実施する予定です。本作業に着手する前に、影響分析レポートを作成してください。【調査項目】 1. 影響範囲(Blast Radius)の特定 - 対象リソースに直接依存している Azure リソースを列挙 - 推移的依存(2〜3 階層先まで)を Azure Resource Graph で追跡 - 対象リソースを利用しているアプリケーション、サブシステム、業務プロセスを特定 - 外部システム連携(Private Endpoint、Service Endpoint、Webhook 配信先)を確認 2. ダウンタイム・劣化リスク - 変更操作が対象リソースを一時的に停止するか - SLA・SLO への影響(可用性、レイテンシ) - 影響時間帯と影響を受けるユーザー数の見積もり 3. データ保護 - 対象リソースがステートフルか(データを保持するか) - 最新のバックアップ取得時刻と取得方式 - ポイントインタイムリストア可能性と RTO・RPO 4. セキュリティ姿勢への影響 - RBAC 割り当ての変更有無 - ネットワーク露出の変更(Public Endpoint の追加削除、NSG ルール変更) - 暗号化方式・認証方式の変化 5. コスト変動 - 変更による月次コスト差分の見積もり - 想定外の課金が発生する可能性(データ転送、ストレージ層、API 呼び出し増加) 6. ロールバック計画 - 変更が失敗・想定外の事象を起こした場合の戻し手順 - ロールバックに要する時間 - ロールバック中の追加リスク 7. 承認状況 - 関連する変更管理チケット(ServiceNow / Jira)の番号と状態 - 必要な承認者と承認取得状況 8. 推奨実施時間帯 - メンテナンスウィンドウ(深夜、週末、業務時間外)の必要性 - 利用者への事前通知の要否と通知文案【出力形式】 docs/change-impact/{YYYY-MM-DD}-{change-id}.md として保存。各項目について「✅ 問題なし」「⚠ 注意事項あり」「❌ 重大なリスク」のいずれかで判定し、警告がある場合は具体的な内容と推奨対応を併記。最後に「実施可能 / 条件付き実施可能 / 実施不可」の総合判定を出してください。【重要】本レポートを作成しただけでは変更を実行しないこと。レポートを人間がレビューし、明示的に承認した後に初めて実行に移ること。

Codex の動作

azure-resource-lookup、azure-resource-visualizer、azure-cost-optimization、azure-rbac の各スキルが連動して動く。Codex は Azure Resource Graph で依存関係を辿り、Bicep / Terraform から定義済みの依存関係も抽出する。バックアップ状態は az backup item list、az sql db list 等で確認する。コスト試算は Azure Retail Prices API、ロールバック計画は対象リソースの種類に応じて az resource update、リビジョン切り戻し、Bicep 旧版再デプロイ等を提示する。出力は Markdown レポートで、表形式で判定結果が並ぶ。レポート作成後は明示的に作業を停止し、人間のレビューを待つ。

12.3 影響分析の具体例:Container App の SKU 変更

抽象論ではイメージしにくいため、具体例を示す。「本番の Container App のメモリ上限を 512Mi から 1Gi に変更」という、一見シンプルな作業の影響分析。

具体的な影響分析プロンプト

本番 Container App (ca-billing-prod-jpe-001) のメモリ上限を 512Mi から 1Gi に変更します。変更管理チケット CHG-2026-0512-001 で承認済みです。影響分析レポートを作成してください(12.2 のテンプレートに従う)。

Codex が返すレポートの例(抜粋)

影響分析レポート: CHG-2026-0512-001

1. 影響範囲:⚠ 注意事項あり
- ca-billing-prod-jpe-001 は Application Gateway (agw-front-prod-jpe-001) のバックエンドプールとして登録されている
- 同じ Container Apps Environment (cae-billing-prod-jpe-001) には ca-payment-prod-jpe-001、ca-notify-prod-jpe-001 も存在するが、メモリ上限変更は対象リビジョンのみに作用するため、他 Container App への影響なし
- 推移的依存:Application Gateway 経由で frontend Web App(app-portal-prod-jpe-001)が依存している

2. ダウンタイム:✅ 問題なし
- Container Apps の Revision モードが Multiple Revisions に設定されているため、新リビジョンが Healthy になってからトラフィック切替
- 新リビジョンが Unhealthy になった場合は旧リビジョンが継続稼働
- 想定ダウンタイム:ゼロ秒

3. データ保護:✅ 問題なし
- Container App はステートレス。データは外部の Cosmos DB に保管
- メモリ変更はデータレイヤーに影響しない

5. コスト変動:⚠ 注意事項あり
- メモリ単価: 0.000003 USD/GiB-second
- 平均レプリカ数 3、24時間稼働の場合の月次差分: +約 1,150 USD
- 想定を超えていなければ承認済み予算枠内

6. ロールバック計画:✅ 問題なし
- az containerapp revision deactivate --name ca-billing-prod-jpe-001 --revision <新リビジョン名> で旧リビジョンへ即時切り戻し
- ロールバック所要時間:約 30 秒

総合判定:✅ 実施可能(コスト増加の事前承認のみ確認すること)

推奨実施時間帯:業務時間内可。ただし、念のため業務時間内であれば監視担当者を待機させる

このような構造化レポートにより、人間レビュアーは「何を見るか」を考えずに、表に従って判定できる。影響分析の品質と速度が、組織のメンバー間でばらつかなくなる。

12.4 Codex Plan モード:計画と実行の分離

影響分析を組織のプロセスに組み込むうえで、Codex CLI の Plan モード(/plan コマンド)が強力な道具になる。Plan モードは Codex の動作を「計画立案」と「実行」の二段階に明示的に分離し、計画段階では一切の外部副作用(コマンド実行、ファイル変更、API 呼び出し)を発生させない。

① Plan モードの基本動作

段階	動作	副作用
① `/plan` 起動	ユーザーの要求を受け、Codex が計画(実行手順、対象リソース、想定影響、リスク)を構造化された Markdown で出力	なし(読み取り専用)
② 人間によるレビュー	計画内容を確認、必要に応じて Codex に修正指示	なし
③ `/approve` または明示的な承認	計画を確定し、Codex が実行モードに移行	承認操作のみ
④ 計画に基づく実行	承認された計画に従って Codex が実行。逸脱を検出した場合は即停止	計画範囲内のみ

これは「Codex が思いつきで本番リソースに触る」リスクを構造的に排除する仕組みである。承認モード(Suggest / Auto / Full-auto)とは別の軸の統制であり、両者を併用することでさらに堅牢になる。

② Plan モードの利用例

Plan モード起動と計画立案

/plan 本番の Container App (ca-billing-prod-jpe-001) のメモリ上限を 512Mi から 1Gi に変更したい。変更管理チケット CHG-2026-0512-001 で承認済み。以下を計画してください: 1. 変更前の影響分析(12.2 のテンプレートに従う) 2. Before スナップショット取得 3. 変更コマンド実行 4. After スナップショット取得と差分検証 5. ヘルスチェック確認 6. 想定通り動作しない場合のロールバック手順各ステップで使用する Azure CLI コマンドと、その実行前後で必要な確認項目を明示してください。実行はしないでください。計画の出力のみ。

Codex の動作(Plan モード)

Codex は Azure 環境への副作用を一切発生させず、計画書のみを出力する。出力は構造化された Markdown で、各ステップに番号・目的・実行コマンド・期待される結果・失敗時の判断基準・所要時間が明示される。この段階で計画が実行されることはない。ユーザーは計画書をレビューし、不足や懸念があれば「ステップ3の前にトラフィック分割設定の確認を追加してください」のように修正指示を出す。最終的に問題なければ /approve または「この計画で進めてください」と明示することで実行モードに移る。

③ Plan モードと影響分析・Hooks との連携

本記事の構成では、Plan モードは「変更系作業の入口」として機能し、影響分析・Hooks による Before/After 記録・実運用ガードレールと有機的に連動する。本番作業の標準フロー:

影響分析の依頼:12.2 のテンプレートで影響分析レポートを作成(Plan モードで起動するのが理想)
レポートのレビューと承認:人間レビュアーまたはセキュリティチームが内容を確認、変更管理チケットに添付
Plan モードで実行計画の立案:承認された影響分析を踏まえ、Codex に /plan で具体的な実行計画を作らせる
計画書のレビュー:ステップごとに無理がないか、ロールバック手順が現実的か確認
計画承認後の実行:/approve で実行モードに移行。Hooks(PreToolUse / PostToolUse)が Before / After スナップショットを自動取得しながら実行
実行結果のレビュー:Hooks が生成したエビデンス、After スナップショット、差分レポートを確認

この流れにより、本番作業は「Codex がいきなり何かする」ことが構造的に不可能になる。人間の承認とエージェントの実行が明確に分離され、変更管理プロセスの各ステップが Codex のセッション内で自動的に記録される。

12.5 影響分析を AGENTS.md に組み込む

Plan モードと影響分析を組織標準として徹底するには、AGENTS.md に明示的に記載する。Section 7.1 の AGENTS.md 例に以下を追加する。

## 12. 本番作業の標準フロー

本番環境(env=prod のリソース)に対する作成・変更・削除を伴う操作は、
以下のフローに従うこと。略すことは認められない。

### 12.1 影響分析の必須化
- 本番リソースへの変更系操作は、必ず docs/templates/impact-analysis-prompt.md
  のテンプレートで影響分析レポートを作成すること
- レポートは docs/change-impact/{YYYY-MM-DD}-{change-id}.md として保存
- 「総合判定: 実施可能」が出ない限り、後続のステップに進まない

### 12.2 Plan モードの必須化
- 本番への変更は Codex CLI の /plan で計画立案してから実行する
- 計画書は人間がレビューし、明示的に /approve するまで実行に進まない
- /plan を省略して直接実行することは禁止(緊急時の例外フローは 14.5 参照)

### 12.3 例外的に Plan モード不要な操作
以下は読み取り専用または影響範囲が極小のため、Plan モードを省略可能:
- リソースの読み取り(az * list、az * show)
- ログクエリ(KQL クエリ実行)
- 検証環境(env=stg、env=dev)への変更

### 12.4 影響分析レポートと Plan の保管
- 影響分析レポート、Plan、実行ログ、エビデンスはすべて Git でリポジトリ管理
- 変更管理チケットには、これら4点へのリポジトリリンクを添付

### 12.5 影響分析のレビュー責任
- Severity 1 操作(本番リソース削除等):セキュリティチーム + システムオーナーの両方の承認
- Severity 2 操作(SKU 変更、設定変更):システムオーナーの承認
- Severity 3 操作(タグ追加、メタデータ変更):変更担当者のセルフレビュー可

12.6 影響分析を機械的に補強する追加スキル(オプション)

Azure Skills Plugin にない影響分析特化スキルを、組織独自に開発する選択肢もある。microsoft/skills リポジトリの構造に従い、組織内向けの私的スキルを作成し、Codex に登録する。最低限の構成例:

# org-azure-impact-analysis/SKILL.md

---
name: org-azure-impact-analysis
description: |
  Azure リソースへの変更前に必須となる影響分析レポートを生成する。
  本番環境への作成・変更・削除コマンドが検知された場合、または明示的に
  「影響分析」「impact analysis」「blast radius」が要求された場合に発火する。
trigger_keywords:
  - 影響分析
  - impact analysis
  - blast radius
  - change impact
auto_invoke_patterns:
  - "az.*--resource-group rg-.*-prod"
  - "azd up.*--environment prod"
---

## 動作

1. 対象リソースを特定し、az resource show で現在状態を取得
2. Azure Resource Graph で依存関係を3階層まで追跡
3. バックアップ状態を確認(az backup, az sql db, az cosmosdb 等)
4. RBAC、ネットワーク、暗号化の現状を取得
5. 変更による影響を 12.2 テンプレートに従って構造化
6. 変更管理チケット番号がプロンプトに含まれている場合は、それを冒頭に明記
7. レポートを docs/change-impact/ に保存
8. 「明示的な承認なしには実行しない」旨を明記してセッションを停止

このようなカスタムスキルは /enterprise/skills/ 配下に配置し、Hooks と同じく managed_dir 経由で組織展開する。Azure Skills の汎用スキルでは扱いきれない、組織固有の影響分析ルール(社内 SLO の閾値、特定システムへの追加チェック等)を組み込める。

12.7 影響分析・Plan モード・Hooks の関係整理

本記事で扱う3つの統制レイヤー(影響分析、Plan モード、Hooks)はそれぞれ役割が異なる。混同しないよう整理する。

レイヤー	役割	タイミング	主な防御対象
影響分析(Section 12)	変更が起こす影響範囲・リスクを事前に言語化	変更計画の最初期段階	「想定外の波及」「ダウンタイム見落とし」
Plan モード	実行計画を立案し、人間レビューを挟む	変更実行の直前	「思いつき実行」「ステップ抜け」
Hooks(Section 13)	実行中のコマンドを記録・ブロック・通知	変更実行中	「無記録の操作」「危険コマンドの素通り」

これら3つは積層的に機能する。影響分析は意図と判断のレベル、Plan モードは実行手順のレベル、Hooks は個別操作のレベルで本番作業を守る。1つでも欠けると、その層に対応する事故が起きる可能性が残る。

Phase 8

13. 本番作業エビデンスとガバナンス:Codex Hooks による監査自動化

企業の本番作業では、誰が・いつ・何を・どのリソースに対して実行したかをすべてエビデンスとして残すことが、内部統制(J-SOX、SOC 2、ISO 27001 等)や監査対応の必須要件である。Codex のような AI エージェントは応答に「ゆれ」があり、人間がすべての作業をログに残せている前提も成り立たない。この問題に対する Codex 側の回答が、2026年3月に GA となった Hooks 機能である。本セクションでは Codex Hooks の仕組みを整理し、本番環境操作のエビデンスを構造的に残す実装方法を示す。

段階導入を強く推奨:本章は Hooks の完全な構成(記録 + ブロック + Sentinel 連携 + ITSM 連携 + Before/After スナップショット + Immutable Storage)を網羅的に示すが、これらすべてを最初から実装する必要はない。むしろプラットフォーム運用チームの負荷を考えると、「小さく始めて段階的に強化する」のが現実的である。推奨される導入順序:

第1段階:操作ログの記録(13.5)のみ。すべての Codex 操作を Append Blob に書き込み、まずは記録の網羅性を確立する
第2段階:危険操作のリアルタイムブロック(13.7)。誤実行リスクの高い操作を Exit code 2 で阻止する仕組みを追加
第3段階:Before/After スナップショット(13.6)。本番リソース変更時の前後状態を機械的に取得する
第4段階:Sentinel 統合(13.12)、ITSM 連携(承認状態の自動照会)、4-eyes 通知の高度化

各段階で運用が安定したことを確認してから次に進む。「すべて入れる」ことを目標にせず、組織の運用成熟度に合わせて選別することが現実的な運用継続の鍵となる。

13.1 AI 作業のエビデンスが従来と異なる4つの理由

従来の本番作業エビデンスは、変更管理票、作業ログ、スクリーンショット、4-eyes チェック(2名による承認)などで構成されてきた。AI エージェント時代には、これらが以下の理由で機能しにくくなる。

応答のゆれ:同じプロンプトでも Codex の出力するコマンド・対象リソース・実行順序が完全に同一とは限らない。「実行されたものが事前計画と一致する」という前提が崩れる。
暗黙の中間ステップ:Codex が自律的に補助コマンド(クォータ確認、依存チェック等)を実行することがある。これらは作業計画書に記載されないが、システムには痕跡が残る。
承認の希薄化:インタラクティブな対話の中で「はい」「OK」と返したものが、実際には複数の Azure 操作の承認を意味する。後から「何を承認したか」を再現するのが難しい。
4-eyes チェックの不在:1名の開発者と Codex のセッションは、定義上 1-eye の状態。組織として2名チェックを義務付けるなら、何らかの自動的な記録・通知の仕組みが必要となる。

これら4つの課題に対し、Codex Hooks は「実行されるすべての操作の前後で、外部スクリプトを強制的に発火させる」という仕組みで応える。エビデンスの記録、危険操作のブロック、別系統への通知などを、Codex のセッションとは独立した経路で実行できる。

13.2 Codex Hooks の概要

Hooks は Codex の「ライフサイクルイベント」に外部スクリプトを紐づける仕組みである。2026年5月時点で以下の5つのイベントに対応している(Codex CLI v0.117.0 以降)。公式ドキュメントに最新仕様が掲載されている。

イベント	発火タイミング	用途
SessionStart	Codex セッション開始時	セッション ID 採番、作業開始ログ、コンテキスト注入
UserPromptSubmit	ユーザーがプロンプトを送信した時	プロンプトの監査記録、機密情報スキャン、禁止語句チェック
PreToolUse	Codex がツール(Bash 等)を実行する直前	実行前の承認、コマンドの記録、危険操作のブロック
PostToolUse	ツール実行が完了した直後	実行結果の記録、出力の機密情報マスク、後処理(フォーマット等)
Stop	Codex セッション終了時	セッションサマリ生成、ログのアーカイブ、外部システムへの転送

2026年5月時点での制約:Hooks の PreToolUse / PostToolUse は Bash ツールでは確実に発火するが、apply_patch(ファイル編集)や一部の MCP ツール呼び出しでは発火しない場合がある(GitHub Issue #16732 で追跡中)。本番環境への操作は通常 Azure CLI / azd 等の Bash 経由になるため監査要件は満たせるが、リポジトリ内のファイル編集をすべて捕捉したい場合は、Git のフックや CI 側の検証と組み合わせる必要がある。

13.3 Hooks の設定構造

Codex CLI は ~/.codex/hooks.json または ~/.codex/config.toml の [hooks] セクションから設定を読み込む。さらに企業統制向けに managed_dir(管理ディレクトリ)を指定でき、IT 部門が配布したフックスクリプトを上書き不可で適用できる。設定の優先順位:

managed_dir(企業管理、最優先)
プロジェクトローカル(<repo>/.codex/hooks.json、信頼済みプロジェクトのみ)
ユーザーローカル(~/.codex/hooks.json)
プラグインバンドル([features].plugin_hooks = true の場合)

複数のレイヤーにフックがあれば、すべて読み込まれて並行実行される(上位が下位を上書きしない)。企業統制のフックは確実に動作し続けるという設計である。

13.4 操作ログだけでは内部統制を満たせない理由

本節以降で Hooks による各種記録の実装を示すが、まず重要な前提を確認する。Azure のリソースを作成・変更・削除する作業のエビデンスとして、「実行されたコマンド」と「コマンドの戻り値」を記録するだけでは内部統制要件を満たさない。ITIL の変更管理プロセス、J-SOX、SOC 2、ISO 27001 のいずれも、本番リソースへの変更については以下の三点セットを記録することを求めている。

記録区分	内容	なぜ必要か
① 事前状態(Before)	変更前のリソース構成全体(SKU、レプリカ数、各設定値、タグ、ネットワーク設定、IAM 割り当て等)	「何を変更したのか」を後から再現するには、変更前の状態が必要。障害時のロールバック先の決定根拠にもなる
② 操作内容(Action)	実行したコマンド・API 呼び出し・パラメータ・実行者・実行時刻・承認情報	誰がどの操作を意図したかの記録。変更管理チケットとの紐付けの起点
③ 事後状態(After)	変更後のリソース構成全体と、Before との差分	「操作の意図が実現したか」「想定外の副作用が発生していないか」を確認する根拠

例えば「Container App のメモリ上限を 512Mi から 1Gi に引き上げ」という単純な操作でも、コマンド文字列だけでは以下が分からない。

変更前は本当に 512Mi だったか(誰かが既に手動で別の値に変更していた可能性)
変更によってリビジョン番号、レプリカ数、ヘルスプローブ設定など、副次的に影響を受けた他の項目はないか
変更が意図通り反映されたか(API は成功を返したが実態が変わっていない、というケースもある)

従って、Hooks による本番作業エビデンスの実装では、PreToolUse で「これから実行する操作の対象リソースの現在状態」を取得・記録し、PostToolUse で「操作後の状態」を取得・記録して差分を計算するという二段構えが必要になる。以降の13.5〜13.7 で、この三点セットを実装する具体的な方法を示す。

13.5 操作ログの記録(Action)

三点セットのうち「② 操作内容」にあたる部分。Codex Desktop App / CLI が実行する Bash コマンドそのものを、改ざん不可能な外部ストレージに記録する。

① 管理ディレクトリへのフックスクリプト配置

IT 部門が /enterprise/hooks/(macOS / Linux)または C:\enterprise\hooks\(Windows)配下にスクリプトを配置する。Intune や Jamf 経由で全開発者端末に配布する。

#!/usr/bin/env python3
# /enterprise/hooks/pre_tool_use_audit.py
# PreToolUse Hook: 全 Bash コマンドを Azure Storage に記録

import json
import sys
import os
import uuid
from datetime import datetime, timezone

# Codex が標準入力に渡してくる JSON ペイロード
payload = json.loads(sys.stdin.read())

# エビデンスレコードの構築
evidence = {
    "evidence_id": str(uuid.uuid4()),
    "timestamp_utc": datetime.now(timezone.utc).isoformat(),
    "session_id": payload.get("session_id"),
    "turn_id": payload.get("turn_id"),
    "user_upn": os.environ.get("USER_UPN"),  # Entra ID の UPN
    "user_object_id": os.environ.get("USER_OBJECT_ID"),
    "device_id": os.environ.get("DEVICE_ID"),
    "hostname": os.uname().nodename,
    "tool_name": payload.get("tool_name"),
    "tool_input": payload.get("tool_input"),
    "approval_mode": payload.get("approval_mode"),  # interactive/auto/full-auto
    "azure_subscription": os.environ.get("AZURE_SUBSCRIPTION_ID"),
    "codex_model": os.environ.get("CODEX_MODEL"),
    "agents_md_hash": os.environ.get("AGENTS_MD_HASH"),  # 適用された AGENTS.md のハッシュ
}

# 危険操作の検知(本番リソースの削除等)
command = payload.get("tool_input", {}).get("command", "")
dangerous_patterns = [
    "az group delete",
    "az resource delete",
    "az account set --subscription rg-.*-prod",
    "rm -rf",
    "DROP TABLE",
    "DROP DATABASE",
]
import re
matched = [p for p in dangerous_patterns if re.search(p, command)]
evidence["dangerous_operation"] = bool(matched)
evidence["matched_patterns"] = matched

# Azure Storage(Append Blob)への即時書き込み
# - SAS トークンを使う実装も可だが、ここでは Managed Identity を想定
import subprocess
subprocess.run([
    "az", "storage", "blob", "append",
    "--account-name", "stcodexevidence001",
    "--container-name", "codex-evidence",
    "--name", f"{datetime.now(timezone.utc).strftime('%Y/%m/%d')}/{evidence['session_id']}.jsonl",
    "--content", json.dumps(evidence) + "\n",
    "--auth-mode", "login",
], check=False, capture_output=True)

# Codex への返却:exit 0 で続行
sys.exit(0)

② config.toml への組み込み

~/.codex/config.toml に以下を追加する。企業展開時は MDM 経由でこの設定を強制配布する。

[features]
hooks = true

[hooks]
managed_dir = "/enterprise/hooks"
windows_managed_dir = 'C:\enterprise\hooks'

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "python3 /enterprise/hooks/pre_tool_use_audit.py"
timeout = 30
statusMessage = "本番作業エビデンスを記録中..."

[[hooks.PostToolUse]]
matcher = "^Bash$"

[[hooks.PostToolUse.hooks]]
type = "command"
command = "python3 /enterprise/hooks/post_tool_use_audit.py"
timeout = 30
statusMessage = "実行結果を記録中..."

③ Storage Account 側の設計

エビデンスを格納する Azure Storage Account は、改ざん不可能性を保証するために以下の設定を施す。

Append Blobのみ受け付ける(既存内容の書き換え不可)
Immutable Storage Policy(Time-based Retention、例:7年保持)を適用
Legal Holdを有効化(訴訟・監査時の削除禁止)
Storage Account の Soft Delete(365日)と Versioning を有効化
RBAC で開発者には書き込み(Append)のみ許可、読み取り・削除権限は監査部門のみ
診断ログを Log Analytics と Microsoft Sentinel に転送し、SIEM 側でも保管

13.6 リソースの事前状態と事後状態のスナップショット(Before / After)

三点セットの中核となる部分。Azure リソースに対する変更コマンドが実行される際、PreToolUse Hook で対象リソースの現在状態を取得し、PostToolUse Hook で操作後の状態を取得して、差分とともにエビデンスとして残す。これにより、ITIL や J-SOX が要求する「変更前後の状態記録」を Codex の作業全体で自動化できる。

① 対象操作の特定

すべての Bash コマンドに対して事前/事後状態を取得すると、コマンド数によっては過剰な負荷とコストになる。Azure リソースの作成・変更・削除を伴うコマンドのみを対象にする。具体的には以下のパターンを Hooks 側で識別する。

az * create、az * update、az * delete、az * set
azd up、azd deploy、azd provision、azd down
az deployment * create(Bicep / ARM デプロイ)
az role assignment create/delete、az policy * create/delete
SQL の CREATE / ALTER / DROP / GRANT / REVOKE 文(az sql db query 等で実行されるもの)

読み取り系コマンド(az * list、az * show)は除外し、変更を伴うコマンドのみで Before / After 取得を発火させる。

② Before スナップショット(PreToolUse)

変更系コマンドが検知された場合、対象リソースの現在状態を Azure Resource Manager API(az resource show または az * show)で取得し、エビデンスストレージに記録する。

#!/usr/bin/env python3
# /enterprise/hooks/pre_tool_use_snapshot.py
# PreToolUse Hook: 変更系コマンドの対象リソースの事前状態を取得

import json
import sys
import os
import re
import uuid
import subprocess
from datetime import datetime, timezone

payload = json.loads(sys.stdin.read())
command = payload.get("tool_input", {}).get("command", "")
session_id = payload.get("session_id")
turn_id = payload.get("turn_id")

# 変更系コマンドのパターン
mutation_patterns = [
    r"az\s+\S+\s+(create|update|delete|set)\b",
    r"azd\s+(up|deploy|provision|down)\b",
    r"az\s+deployment\s+\S+\s+create\b",
    r"az\s+role\s+assignment\s+(create|delete)\b",
    r"az\s+policy\s+\S+\s+(create|delete|assign)\b",
]
is_mutation = any(re.search(p, command, re.IGNORECASE) for p in mutation_patterns)

if not is_mutation:
    sys.exit(0)  # 変更系ではない、スナップショット不要

# 対象リソースの特定(--name と --resource-group から取得)
resource_match = re.search(r"--name\s+(\S+)", command)
rg_match = re.search(r"--resource-group\s+(\S+)|-g\s+(\S+)", command)
resource_name = resource_match.group(1) if resource_match else None
resource_group = (rg_match.group(1) or rg_match.group(2)) if rg_match else None

snapshot = {
    "snapshot_id": str(uuid.uuid4()),
    "snapshot_type": "before",
    "timestamp_utc": datetime.now(timezone.utc).isoformat(),
    "session_id": session_id,
    "turn_id": turn_id,
    "user_upn": os.environ.get("USER_UPN"),
    "azure_subscription": os.environ.get("AZURE_SUBSCRIPTION_ID"),
    "command": command,
    "target_resource_name": resource_name,
    "target_resource_group": resource_group,
}

# Bicep / ARM デプロイの場合は what-if で「これから変更される予定」を取得
if "az deployment" in command and "create" in command:
    # azd up や azd deploy の場合、デプロイ前に what-if を実行して
    # 「変更されるリソース」のリストと差分予測を取得
    whatif_cmd = command.replace(" create ", " what-if ")
    whatif_result = subprocess.run(
        whatif_cmd.split(), capture_output=True, text=True, timeout=60
    )
    snapshot["whatif_output"] = whatif_result.stdout
    snapshot["whatif_predicted_changes"] = "what-if 結果から抽出"

# 単一リソースに対する update / delete の場合は az resource show
elif resource_name and resource_group:
    show_result = subprocess.run(
        ["az", "resource", "show",
         "--name", resource_name,
         "--resource-group", resource_group,
         "--output", "json"],
        capture_output=True, text=True, timeout=30
    )
    if show_result.returncode == 0:
        snapshot["resource_state_before"] = json.loads(show_result.stdout)
    else:
        snapshot["resource_state_before"] = None
        snapshot["snapshot_error"] = show_result.stderr

    # 依存リソースの状態も取得(タグ、IAM 割り当て、診断設定など)
    role_assignments = subprocess.run(
        ["az", "role", "assignment", "list",
         "--scope", f"/subscriptions/{os.environ.get('AZURE_SUBSCRIPTION_ID')}"
                    f"/resourceGroups/{resource_group}"
                    f"/providers/Microsoft.Resources/resourceGroups/{resource_group}"
                    f"/providers/{resource_name}",
         "--output", "json"],
        capture_output=True, text=True, timeout=30
    )
    if role_assignments.returncode == 0:
        snapshot["role_assignments_before"] = json.loads(role_assignments.stdout)

# スナップショットを Append Blob に書き込み
subprocess.run([
    "az", "storage", "blob", "append",
    "--account-name", "stcodexevidence001",
    "--container-name", "codex-snapshots",
    "--name", f"{datetime.now(timezone.utc).strftime('%Y/%m/%d')}/{session_id}/{turn_id}-before.json",
    "--content", json.dumps(snapshot, ensure_ascii=False),
    "--auth-mode", "login",
], check=False, capture_output=True)

# 環境変数で turn_id とリソース情報を後続フックに引き継ぐ
print(f"SNAPSHOT_TURN_ID={turn_id}")
print(f"SNAPSHOT_RESOURCE_NAME={resource_name or ''}")
print(f"SNAPSHOT_RESOURCE_GROUP={resource_group or ''}")

sys.exit(0)

③ After スナップショットと差分計算(PostToolUse)

変更コマンドの実行直後、PostToolUse Hook で同じリソースの状態を再度取得し、Before と比較して差分を記録する。

#!/usr/bin/env python3
# /enterprise/hooks/post_tool_use_snapshot.py
# PostToolUse Hook: 変更系コマンドの対象リソースの事後状態を取得し差分を記録

import json
import sys
import os
import re
import uuid
import subprocess
from datetime import datetime, timezone
from urllib.request import urlopen

payload = json.loads(sys.stdin.read())
command = payload.get("tool_input", {}).get("command", "")
session_id = payload.get("session_id")
turn_id = payload.get("turn_id")
exit_code = payload.get("tool_output", {}).get("exit_code", -1)
stdout = payload.get("tool_output", {}).get("stdout", "")
stderr = payload.get("tool_output", {}).get("stderr", "")

# 変更系コマンドの判定(Pre 側と同じロジック)
mutation_patterns = [
    r"az\s+\S+\s+(create|update|delete|set)\b",
    r"azd\s+(up|deploy|provision|down)\b",
    r"az\s+deployment\s+\S+\s+create\b",
    r"az\s+role\s+assignment\s+(create|delete)\b",
]
is_mutation = any(re.search(p, command, re.IGNORECASE) for p in mutation_patterns)
if not is_mutation:
    sys.exit(0)

resource_match = re.search(r"--name\s+(\S+)", command)
rg_match = re.search(r"--resource-group\s+(\S+)|-g\s+(\S+)", command)
resource_name = resource_match.group(1) if resource_match else None
resource_group = (rg_match.group(1) or rg_match.group(2)) if rg_match else None

snapshot_after = {
    "snapshot_id": str(uuid.uuid4()),
    "snapshot_type": "after",
    "timestamp_utc": datetime.now(timezone.utc).isoformat(),
    "session_id": session_id,
    "turn_id": turn_id,
    "command": command,
    "command_exit_code": exit_code,
    "command_stdout_excerpt": stdout[:2000],
    "command_stderr_excerpt": stderr[:2000],
    "target_resource_name": resource_name,
    "target_resource_group": resource_group,
}

# 削除コマンドの場合、リソースは既に存在しないので「削除完了」のみ記録
if "delete" in command:
    snapshot_after["resource_state_after"] = None
    snapshot_after["deletion_confirmed"] = (exit_code == 0)
elif resource_name and resource_group:
    # 変更後の状態を取得
    show_result = subprocess.run(
        ["az", "resource", "show",
         "--name", resource_name,
         "--resource-group", resource_group,
         "--output", "json"],
        capture_output=True, text=True, timeout=30
    )
    if show_result.returncode == 0:
        snapshot_after["resource_state_after"] = json.loads(show_result.stdout)

# Before スナップショットを取得して差分を計算
before_blob = subprocess.run(
    ["az", "storage", "blob", "download",
     "--account-name", "stcodexevidence001",
     "--container-name", "codex-snapshots",
     "--name", f"{datetime.now(timezone.utc).strftime('%Y/%m/%d')}/{session_id}/{turn_id}-before.json",
     "--auth-mode", "login",
     "--output", "tsv"],
    capture_output=True, text=True, timeout=30
)

if before_blob.returncode == 0:
    snapshot_before = json.loads(before_blob.stdout)
    before_state = snapshot_before.get("resource_state_before")
    after_state = snapshot_after.get("resource_state_after")
    
    # 差分の計算(deepdiff ライブラリを利用)
    if before_state and after_state:
        from deepdiff import DeepDiff
        diff = DeepDiff(before_state, after_state, ignore_order=True)
        snapshot_after["state_diff"] = json.loads(diff.to_json())
        # 重要な変更項目を抽出
        snapshot_after["changed_properties"] = list(diff.get("values_changed", {}).keys())

# Activity Log との突き合わせ(Azure 側の操作記録との二重確認)
# 操作の直後5分以内に Activity Log に該当エントリがあるかを確認
activity_check = subprocess.run(
    ["az", "monitor", "activity-log", "list",
     "--resource-group", resource_group or "",
     "--start-time", (datetime.now(timezone.utc).isoformat()),
     "--max-events", "10",
     "--output", "json"],
    capture_output=True, text=True, timeout=30
)
if activity_check.returncode == 0:
    snapshot_after["azure_activity_log_correlation"] = json.loads(activity_check.stdout)

# Append Blob に書き込み
subprocess.run([
    "az", "storage", "blob", "append",
    "--account-name", "stcodexevidence001",
    "--container-name", "codex-snapshots",
    "--name", f"{datetime.now(timezone.utc).strftime('%Y/%m/%d')}/{session_id}/{turn_id}-after.json",
    "--content", json.dumps(snapshot_after, ensure_ascii=False),
    "--auth-mode", "login",
], check=False, capture_output=True)

sys.exit(0)

④ Bicep / ARM デプロイの場合の特殊処理

単一リソースではなく、Bicep / ARM テンプレートを用いた一括デプロイ(az deployment group create、azd up 等)では、複数のリソースが同時に変更される。この場合、以下のように Before / After を取得する:

Before:az deployment * what-if を実行して「これから変更される予定の全リソースの差分予測」を取得し記録
After:デプロイ完了後、az deployment * show でデプロイ結果と各リソースの最終状態を取得
差分:what-if の予測と実際のデプロイ結果を突き合わせ、想定外の変更がなかったかを確認

これにより、Bicep の単一ファイル変更で複数リソースが連鎖的に変更される場合でも、変更前後のすべてのリソース状態がエビデンスとして残る。

⑤ config.toml への組み込み(完全版)

Pre / Post の両方を有効化する設定。複数のフックスクリプトを順次実行することで、操作ログとスナップショットの両方を取得する。

[features]
hooks = true

[hooks]
managed_dir = "/enterprise/hooks"
windows_managed_dir = 'C:\enterprise\hooks'

[[hooks.PreToolUse]]
matcher = "^Bash$"

# 操作ログ記録
[[hooks.PreToolUse.hooks]]
type = "command"
command = "python3 /enterprise/hooks/pre_tool_use_audit.py"
timeout = 30
statusMessage = "操作内容を記録中..."

# 危険操作のチェック
[[hooks.PreToolUse.hooks]]
type = "command"
command = "python3 /enterprise/hooks/pre_tool_use_policy.py"
timeout = 15
statusMessage = "ポリシーチェック中..."

# 事前状態スナップショット(変更系コマンドのみ)
[[hooks.PreToolUse.hooks]]
type = "command"
command = "python3 /enterprise/hooks/pre_tool_use_snapshot.py"
timeout = 60
statusMessage = "リソース事前状態を取得中..."

[[hooks.PostToolUse]]
matcher = "^Bash$"

# 実行結果ログ記録
[[hooks.PostToolUse.hooks]]
type = "command"
command = "python3 /enterprise/hooks/post_tool_use_audit.py"
timeout = 30
statusMessage = "実行結果を記録中..."

# 事後状態スナップショットと差分計算
[[hooks.PostToolUse.hooks]]
type = "command"
command = "python3 /enterprise/hooks/post_tool_use_snapshot.py"
timeout = 60
statusMessage = "リソース事後状態を取得し差分を計算中..."

# 本番変更通知
[[hooks.PostToolUse.hooks]]
type = "command"
command = "python3 /enterprise/hooks/post_tool_use_notify.py"
timeout = 15
statusMessage = "関係者に通知中..."

⑥ スナップショット取得の限界と補完

Before / After スナップショットには技術的な限界がある。以下の補完が必要になる:

競合状態のリスク:Pre スナップショット取得後・コマンド実行前に他のセッションが同じリソースを変更すると、記録された「Before」が実際の変更直前の状態と一致しない可能性がある。対策として Azure Resource Lock や Pessimistic Lock を併用する
非同期操作:az deployment group create や azd up は非同期で完了する場合があり、PostToolUse Hook が走った時点でデプロイがまだ進行中のことがある。この場合、最終状態は別途定期チェックジョブで補完する
RBAC 経由の権限変更:az role assignment の変更は対象リソースの show には現れない。別途 az role assignment list で割り当て一覧の Before / After を取得する
Azure Activity Log との突き合わせ:Codex の Hooks ログと Azure 側の Activity Log を session_id + 時刻で相関させ、Azure 側で実際に発生したリソース変更イベントとの整合性を二重チェックする
ボリュームとコスト:大規模リソースのフル JSON は数 MB になる。重要な属性のみを抽出する設定を組織標準として定める

これらの限界を踏まえても、「コマンド文字列のみのログ」と比べれば、はるかに監査に耐えるエビデンスチェーンが構築できる。完璧でなくとも、「変更前にどのような状態だったか、何が起きたか、変更後にどうなったか」が後から再現可能な状態を保つことが、内部統制の核心である。

13.7 危険操作のリアルタイムブロック

エビデンス記録に加えて、Hooks は本番への破壊的操作を実行前にブロックできる。これは Codex の応答ゆれによって意図せぬ操作が発生するリスクを構造的に排除する仕組みである。

① Exit Code 2 によるブロック

PreToolUse フックが exit code 2 で終了し、stderr にブロック理由を出力すると、Codex はそのコマンドを実行せず、stderr の内容を「ブロック理由」として AI に伝える。AI はそれを受けて、別の手段を試すか、ユーザーに確認を求める。

#!/usr/bin/env python3
# /enterprise/hooks/pre_tool_use_policy.py
# PreToolUse Hook: 本番リソースへの破壊的操作をブロック

import json
import sys
import re

payload = json.loads(sys.stdin.read())
command = payload.get("tool_input", {}).get("command", "")

# ブロック対象パターン
block_patterns = [
    (r"az group delete.*--name\s+rg-\S+-prod", 
     "本番リソースグループの削除は禁止されています。変更管理プロセスを経由してください。"),
    (r"az containerapp revision deactivate.*--name\s+\S+-prod", 
     "本番リビジョンの停止は SIRT 承認が必要です。"),
    (r"az role assignment create.*--role\s+Owner", 
     "Owner ロールの付与は禁止されています。最小権限の原則に従ってください。"),
    (r"az ad app credential reset", 
     "App Registration のクレデンシャルリセットは IT 管理者のみ実行可能です。"),
    (r"DROP\s+(TABLE|DATABASE|SCHEMA)", 
     "データベースの破壊的操作はメンテナンス時間外の実行が禁止されています。"),
]

for pattern, reason in block_patterns:
    if re.search(pattern, command, re.IGNORECASE):
        # ブロック理由を stderr に出力
        print(f"[Policy Block] {reason}", file=sys.stderr)
        print(f"[Policy Block] Command: {command}", file=sys.stderr)
        print(f"[Policy Block] Session: {payload.get('session_id')}", file=sys.stderr)
        # exit code 2 でブロック
        sys.exit(2)

# 通過(続行)
sys.exit(0)

② ブロック発動時の Codex の動作

プロンプト例(意図せぬ破壊的操作を依頼)

古いリソースグループを整理したいので、rg-myapp-prod-japaneast を削除してください。

Codex の動作

Codex は az group delete --name rg-myapp-prod-japaneast --yes を実行しようとするが、PreToolUse フックが Exit code 2 でブロックする。Codex は stderr の「本番リソースグループの削除は禁止されています。変更管理プロセスを経由してください。」を受け取り、AI 側の応答として「この操作は組織ポリシーによりブロックされました。本番リソースグループの削除には変更管理プロセスが必要です。代替として、リソースグループ内の特定リソースのみ削除するか、変更管理チケットを作成して承認を得てください」とユーザーに返す。実害は出ない。

13.8 4-eyes チェック相当の自動通知

本番への変更操作が実行された際、即座にチームリーダーや SIRT に通知することで、1名 + AI のセッションでも事実上の 4-eyes 効果を実現する。

#!/usr/bin/env python3
# /enterprise/hooks/post_tool_use_notify.py
# PostToolUse Hook: 本番操作の通知

import json
import sys
import os
import re
import requests
from datetime import datetime, timezone

payload = json.loads(sys.stdin.read())
command = payload.get("tool_input", {}).get("command", "")
output = payload.get("tool_output", {}).get("stdout", "")
exit_code = payload.get("tool_output", {}).get("exit_code", -1)

# 本番への変更操作のパターン
prod_patterns = [
    r"az deployment\s+\S+\s+create.*--resource-group\s+rg-\S+-prod",
    r"az containerapp update.*--name\s+\S+-prod",
    r"azd up.*--environment\s+prod",
    r"az webapp restart.*--name\s+\S+-prod",
]

is_prod_change = any(re.search(p, command) for p in prod_patterns)

if is_prod_change:
    # Teams / Slack への通知
    webhook_url = os.environ.get("SIRT_WEBHOOK_URL")
    user_upn = os.environ.get("USER_UPN")
    status_emoji = "✅" if exit_code == 0 else "❌"
    
    message = {
        "text": f"{status_emoji} 本番環境への変更操作が実行されました",
        "blocks": [
            {"type": "section", "text": {
                "type": "mrkdwn",
                "text": f"*実行者*: {user_upn}\n"
                        f"*セッション ID*: {payload.get('session_id')}\n"
                        f"*コマンド*: `{command[:200]}`\n"
                        f"*終了コード*: {exit_code}\n"
                        f"*時刻*: {datetime.now(timezone.utc).isoformat()}\n"
                        f"*Codex モデル*: {os.environ.get('CODEX_MODEL')}"
            }}
        ]
    }
    
    try:
        requests.post(webhook_url, json=message, timeout=5)
    except Exception as e:
        # 通知失敗は致命的でない(エビデンス自体は Step 13.4 で記録済)
        print(f"[Notify Warning] {e}", file=sys.stderr)

sys.exit(0)

13.9 セッションサマリと監査レポートの自動生成

Stop イベントは Codex セッションの終了時に発火する。ここでセッション全体の作業内容をまとめ、監査用のサマリを生成する。

#!/usr/bin/env python3
# /enterprise/hooks/stop_session_summary.py
# Stop Hook: セッションサマリの生成と外部送信

import json
import sys
import os
import subprocess
from datetime import datetime, timezone

payload = json.loads(sys.stdin.read())
session_id = payload.get("session_id")
transcript_path = payload.get("transcript_path")  # Codex がローカルに保存している会話履歴

# セッションの全コマンドを Storage から取得
result = subprocess.run([
    "az", "storage", "blob", "download-batch",
    "--account-name", "stcodexevidence001",
    "--source", "codex-evidence",
    "--pattern", f"*/{session_id}.jsonl",
    "--destination", "/tmp/",
    "--auth-mode", "login",
], capture_output=True, text=True)

# サマリ生成(セッション内の全操作の集計)
summary = {
    "session_id": session_id,
    "user_upn": os.environ.get("USER_UPN"),
    "start_time": payload.get("session_start_time"),
    "end_time": datetime.now(timezone.utc).isoformat(),
    "total_tool_calls": payload.get("total_tool_calls", 0),
    "blocked_operations": payload.get("blocked_operations", 0),
    "prod_changes": payload.get("prod_changes", 0),
    "agents_md_hash": os.environ.get("AGENTS_MD_HASH"),
    "transcript_uri": f"https://stcodexevidence001.blob.core.windows.net/codex-evidence/transcripts/{session_id}.md",
}

# Microsoft Sentinel へ送信(Log Analytics Data Collector API 経由)
# ここで送信した内容は SIEM 側で相関分析・アラート対象になる
import requests
requests.post(
    f"https://{os.environ.get('LAW_ID')}.ods.opinsights.azure.com/api/logs",
    json=[summary],
    headers={
        "Log-Type": "CodexSessionAudit",
        "Authorization": f"SharedKey {os.environ.get('LAW_SHARED_KEY')}",
        "x-ms-date": datetime.now(timezone.utc).strftime("%a, %d %b %Y %H:%M:%S GMT"),
    },
    timeout=10,
)

sys.exit(0)

13.10 監査要件と Hooks の対応マトリクス

主要な監査・統制フレームワークが要求する事項に対し、Codex Hooks がどう応えるかを整理する。

監査要件	従来の手段	Codex Hooks による実装
作業前承認の証跡	変更管理票、ITSM チケット	PreToolUse で ITSM(ServiceNow 等)に承認状態を照会し、未承認なら exit 2
変更前のリソース状態(Before)	運用手順書のスクリーンショット、az resource show の手動実行結果	PreToolUse で az resource show、role assignment list、診断設定等を自動取得し Immutable Storage に記録(13.6 参照)
実行コマンドの完全記録(Action)	SSH セッションログ、操作画面録画	PreToolUse で全コマンドを Immutable Storage に記録
実行結果の証跡	標準出力のスクリーンショット	PostToolUse で stdout / stderr / exit_code を構造化記録
変更後のリソース状態(After)	運用手順書による作業後の確認結果	PostToolUse で az resource show を再実行し、Immutable Storage に記録
変更前後の差分(Diff)	目視比較、人手によるレポート	PostToolUse で Before / After を deepdiff で機械的に比較、変更項目を抽出
Azure 側との二重確認	監査担当者による別系統での再確認	PostToolUse で Azure Activity Log を取得し、Codex 側ログとの突合
4-eyes チェック	2名でのオペレーション	PostToolUse で本番変更を即時通知、SIEM で相関監視
禁止操作の防止	権限剥奪、運用ルール周知	PreToolUse で危険パターンを exit 2 でブロック
機密情報の漏洩防止	マスキングルール、レビュー	UserPromptSubmit でプロンプト内の機密検知、PostToolUse で出力マスク
作業者特定	サインインログ、SSH 鍵	SessionStart で Entra ID UPN / Device ID をエビデンスに付与
非改ざん性	WORM ストレージ、紙印刷	Azure Storage Immutable Policy + Legal Hold
長期保管	テープバックアップ、外部委託	Storage の Time-based Retention(7年〜)

13.11 Hooks 運用の組織的設計

① 配布と更新の仕組み

Hooks スクリプトは IT 部門が一元管理し、開発者個人が改ざんできない経路で配布する。

配布チャネル:Microsoft Intune(macOS / Windows)または Jamf Pro(macOS)で /enterprise/hooks/ 配下に強制配置
バージョン管理:Hooks スクリプト自体を Git リポジトリで管理し、変更には PR レビューと CISO 承認を要求
整合性チェック:SessionStart イベントで、配置されているスクリプトのハッシュをチェックし、改ざん検知時はセッションを中断
緊急バイパス:インシデント時の緊急対応用にバイパス手順を文書化し、その手順自体も4-eyes チェックを要する

② Codex を使った Hooks 自体の生成

皮肉なことに、Hooks スクリプト自体も Codex に書かせることができる。ただし本番用 Hooks のコード生成は専用のレビュー環境で行い、本番配備前にセキュリティチームのレビューを必須とする。

プロンプト例(Hooks の生成依頼)

PreToolUse Hook の Python スクリプトを生成してください。要件: - 全 Bash コマンドを Azure Storage の Append Blob に記録 - ストレージアカウント: stcodexevidence001、コンテナ: codex-evidence - 認証は Managed Identity(az login の現在のセッション)を使用 - ファイルパス命名規則: {YYYY}/{MM}/{DD}/{session_id}.jsonl - 各レコードに含めるフィールド: 上記の通り - 危険操作パターン(本番リソース削除等)を検知し、検知時は別ストリームに記録 - Hook 自体の失敗は Codex セッションを停止させない(exit 0 で続行) スクリプトを /enterprise/hooks/pre_tool_use_audit.py として出力してください。

Codex の動作

azure-storage スキルと appinsights-instrumentation スキルが連動し、Azure Storage の Append Blob 操作の正しい使い方を反映した Python スクリプトを生成する。azure-identity を使った Managed Identity 認証、azure-storage-blob パッケージの BlobClient.append_block() 呼び出し、構造化ログの JSONL 形式、エラーハンドリングが含まれる。生成後は組織のセキュリティチームに PR レビューを依頼する流れになる。

③ パフォーマンスとタイムアウト管理

Hooks は同期実行されるため、遅いフックは Codex セッションのレスポンスを直接遅延させる。設計上の注意点:

各フックのタイムアウトを config.toml で明示(timeout = 30 秒)
重い処理(SIEM への大量データ送信等)は fire-and-forget パターンで非同期化
致命的でない処理(通知送信、メトリクス送信)は失敗を許容して exit 0 で続行
致命的な処理(エビデンス記録自体)は確実に成功するまで再試行

④ Approval Mode との関係

Codex Desktop App の承認モード(Suggest / Auto / Full-auto)と Hooks の関係:

承認モード	人間の介入	Hooks の役割
Suggest(対話モード)	各操作で人間が確認	記録 + 補助的なブロック
Auto	多くを自動承認	記録 + 危険操作の主要な防御線
Full-auto(無人実行)	人間の介入なし	記録 + すべての防御を担う重要な統制

Full-auto モードでは人間による確認がないため、Hooks が唯一のリアルタイム統制となる。Full-auto を本番作業で使う場合、Hooks の設計と監視は通常以上に厳密にする必要がある。

13.12 Microsoft Sentinel での SIEM 統合

Hooks で集めたエビデンスを、Microsoft Sentinel(または別 SIEM)に取り込み、相関分析・アラート・長期保管を行う。代表的な検知ルール例:

検知シナリオ	KQL 例(概念)
深夜帯の本番変更	`CodexSessionAudit_CL \| where prod_changes_d > 0 and hourofday(TimeGenerated) between (22 .. 6)`
短時間に多数のブロック発動	`CodexEvidence_CL \| where dangerous_operation_b == true \| summarize count() by user_upn_s, bin(TimeGenerated, 1h) \| where count_ > 5`
異常なコマンドパターン	UEBA(User and Entity Behavior Analytics)で各ユーザーの過去パターンと比較
承認外のリソース操作	`CodexEvidence_CL \| join (ChangeManagementTickets_CL) on session_id_s \| where ticket_status_s != "approved"`

これにより、AI を介した操作の異常行動検知が他の人間操作と同じレベルで実施可能となる。

13.13 GitHub Actions 経由のデプロイにおける補完

Hooks は開発者端末上の Codex セッションの記録に強い。一方、GitHub Actions 経由の本番デプロイは Codex のフックでは捕捉できない。以下の補完が必要となる。

GitHub Actions のワークフローログを GitHub Audit Log に取り込み、Sentinel に転送
Azure Activity Logを Log Analytics に転送し、すべてのリソース変更を記録
Azure Policyで組織標準を強制(タグ必須、特定 SKU 禁止等)
OIDC 認証のクレームで、どの PR がどのデプロイをトリガーしたかを追跡

Codex Hooks(開発者端末)+ GitHub Audit Log(CI/CD)+ Azure Activity Log(クラウド側)の3層で、エビデンスチェーンが完成する。

13.14 Hooks の限界と回避策

apply_patch 非対応:ファイル編集の捕捉は Git の pre-commit / pre-push フックや CI 側で補完する
一部 MCP ツール非対応:Azure MCP Server を介した操作の一部はフックを発火させない可能性がある。重要操作は Bash + az CLI 経由で実行するよう AGENTS.md で指示する
非同期処理:現状は同期 command 型のみ動作。async 型は将来対応予定
プロジェクトローカル Hooks のトラスト:プロジェクトディレクトリ配下の .codex/hooks.json は信頼済みプロジェクトでのみ動作する。新規リポジトリのトラスト承認プロセスを組織で定める

13.15 Hooks の位置づけ:監査補助の自動化層であり、監査基盤そのものではない

本章を読んだ読者が誤解しないように、Hooks の位置づけを明確にしておく。

区分	具体例
Hooks が有効な用途	危険操作の事前警告、定型証跡の自動生成、変更前後のスナップショット取得、承認境界の自動強制、本番変更の即時通知
Hooks を過信すべきでない用途	SIEM の代替(Hooks はあくまでクライアント側の記録)、完全な不正防止(悪意ある開発者によるバイパスは技術的に可能)、すべての監査証跡の単独ソース(Azure 側の Activity Log と SIEM との突合が必須)

Hooks は強力な仕組みだが、監査基盤そのものではなく、監査補助の自動化層と位置づけるのが正確である。最終的な監査証跡の正本は Azure Activity Log、Microsoft Sentinel、Storage の Immutable Storage に置く。Hooks はそこへの転送と、開発者端末でのリアルタイム統制という補完的役割を担う。組織として Hooks 導入時には、関係者の期待値を「すべてが自動で記録され、不正は不可能になる」ではなく「正しく運用された場合の作業をより監査しやすくする補助」に合わせることが、運用継続の鍵となる。

14. 実運用ガードレール:本番展開のための運用設計

本章は、これまでの実装ガイドを実際の組織に展開する際に必要となる運用設計を整理する。Codex のような AI エージェントは、技術的にどれだけ良く構築されていても、運用ルール・役割分担・承認境界・禁止事項が曖昧なまま導入すると、想定外の事故や運用停止に至る。本章はパイロット導入から本番展開へ進む過程で、組織として最低限固める必要がある事項を扱う。

14.1 このガイドをそのまま使える組織と、追加設計が必要な組織

本記事の構成は特定の前提に基づいている。導入判断にあたり、まず自社が以下のどちらに該当するかを確認する。

区分	該当する組織条件
そのまま適用しやすい組織	GitHub Enterprise Cloud が利用可能、または導入予定 Microsoft Entra ID で全社の ID 統制が完成している Azure を主要クラウド基盤として採用済み開発組織が5〜30名規模で、Git 管理されたリポジトリでの開発文化が定着 AGENTS.md のような規約ファイルを Git 管理する文化がある Preview / Public Preview 機能の試行的採用が許容される
追加設計・調整が必要な組織	Azure DevOps が全社標準で、移行困難オンプレ Azure DevOps Server を運用中(Remote MCP Server 非対応) 本番環境への変更にすべて事前 CAB 承認を要する厳格な変更管理プロセス Preview 機能の本番採用が禁止されている(本記事の構成には Public Preview 段階の機能を複数含む) MCP / 外部ツール接続に関する組織ポリシーが未整備金融・医療等の規制業界で、AI ツールの導入に追加の規制対応が必要

区分

該当する組織条件

そのまま適用しやすい組織

GitHub Enterprise Cloud が利用可能、または導入予定
Microsoft Entra ID で全社の ID 統制が完成している
Azure を主要クラウド基盤として採用済み
開発組織が5〜30名規模で、Git 管理されたリポジトリでの開発文化が定着
AGENTS.md のような規約ファイルを Git 管理する文化がある
Preview / Public Preview 機能の試行的採用が許容される

追加設計・調整が必要な組織

Azure DevOps が全社標準で、移行困難
オンプレ Azure DevOps Server を運用中(Remote MCP Server 非対応)
本番環境への変更にすべて事前 CAB 承認を要する厳格な変更管理プロセス
Preview 機能の本番採用が禁止されている(本記事の構成には Public Preview 段階の機能を複数含む)
MCP / 外部ツール接続に関する組織ポリシーが未整備
金融・医療等の規制業界で、AI ツールの導入に追加の規制対応が必要

後者に該当する組織でも本記事の本質部分は適用可能だが、Section 8.4 で示した回避策(VS Code 経由 MCP、非公式 az CLI ラッパー、Azure Pipelines 維持、双方向同期)や、追加の組織内承認プロセスを併設する設計が必要になる。

14.2 役割分担(RACI)

Codex を本番運用に組み込む場合、最低限以下の4つの役割と責任分担を組織として明確化する。役割を兼務してよい組織もあれば、明確に分離が必要な組織もある(規制業界では分離必須)。

活動	開発者	Azure 管理者	セキュリティ・ガバナンス	プラットフォーム運用
AGENTS.md の作成・更新	R	C	A	C
命名規則・ネットワーク標準の策定	C	R	A	I
Foundry プロジェクト・モデルデプロイ	I	R	C	A
Codex Desktop App / CLI のセットアップ	R	I	C	A
Hooks スクリプトの作成・配布	C	C	R	A
本番デプロイの実行	R	C	I	A
本番障害時の対応	R	C	I	A
監査ログのレビュー	I	C	R	A
禁止操作パターンの定義	C	C	R	A
モデル変更の判断	C	R	C	A
コスト管理・FinOps	I	R	I	A

※ R: Responsible(実行責任)、A: Accountable(説明責任)、C: Consulted(相談先)、I: Informed(情報共有)

この RACI は出発点である。実際の組織では、開発者の中をさらにテックリードと一般開発者に分け、Azure 管理者を SRE と Cloud Center of Excellence に分けるなど、組織構造に応じて細分化する。

14.3 承認境界:Codex に何を任せ、何に人を残すか

Codex Desktop App の承認モード(Suggest / Auto / Full-auto)は、技術的な選択肢にすぎない。実運用では「どの操作にどの承認モードを許可するか」を組織として定める。以下は推奨される承認境界の設計。

対象環境	許可される承認モード	4-eyes チェック	備考
個人ローカル開発環境	Suggest / Auto / Full-auto	不要	本人の生産性向上が主目的
共有開発環境(dev)	Suggest / Auto	不要	他開発者への影響を最小化、Full-auto は禁止
検証環境(stg)	Suggest のみ推奨、Auto は申請制	不要	本番に近いため慎重に
本番環境(prod)	Suggest のみ	必須(Hooks による即時通知 + 別チャネル承認)	Auto / Full-auto は原則禁止、緊急時のみ例外申請

本番環境への自動実行(Auto / Full-auto)を許可する場合は、以下の条件をすべて満たすことを推奨する:

影響範囲が読み取り専用の操作のみ(az * list、az * show、KQL クエリ等)
事前定義された Runbook の自動実行のみで、Codex が独自判断で操作を組み立てない
すべての操作が Hooks で記録され、Microsoft Sentinel にリアルタイム転送される
異常時に即座に停止できる人間が常時アサインされている

14.4 本番で禁止する事項(Don'ts)

運用開始時に明文化すべき禁止事項。AGENTS.md または別の組織ポリシー文書に記載し、レビューで強制する。

禁止事項	理由
本番サブスクリプションでの `approval_policy = "never"` 設定	すべての操作が人間の承認なしに実行され、事故時の影響範囲が制御不能
Public Preview 機能の本番標準化	仕様変更・廃止リスクがあり、本番依存は脆弱。本記事の構成にも Public Preview の機能が含まれる(Azure DevOps Remote MCP、一部 Azure Skills 等)
AGENTS.md 不在リポジトリでの自動変更許可	組織標準が適用されず、命名・タグ・セキュリティ規約違反が発生
Hooks を SIEM の代替として扱う(Hooks 単独で監査要件を満たすと主張する)	Hooks はクライアント側の補助記録に過ぎず、唯一の証跡源にはできない。Sentinel との二重化が必須
個人 ChatGPT アカウントでの業務リポジトリ接続	データ所有権・監査・退職者管理の観点で組織統制外
Codex Cloud Tasks で機密度の高いリポジトリを処理	Codex Cloud は OpenAI 直接ホストのため、データ境界が Foundry と異なる
Foundry の API キーを config.toml にハードコード	端末紛失・リポジトリ漏洩時のリスクが大きい。Key Vault 経由を必須化
本番リソースグループへの直接 az コマンド実行(IaC を介さない)	ドリフトが発生し、Bicep / Terraform との整合性が失われる
Codex セッションへの顧客 PII データの直接投入	推論プロセスでログ・キャッシュに残る可能性。匿名化・マスキング後に投入

14.5 例外承認フロー

13.4 の禁止事項に該当する作業が必要な場合の例外承認プロセスを定める。これがないと、現場で「禁止」が実態として機能しなくなる。

例外申請の提出:Jira / GitHub Issues で例外申請チケットを起票。理由、影響範囲、代替案検討結果、有効期限を記載
セキュリティ・ガバナンス担当者のレビュー:申請内容を評価。必要に応じて差し戻し
承認と期間限定の許可:最大30日の有効期限付きで承認。Hooks 側のポリシーリストから一時的に該当パターンを除外
事後監査:有効期限経過後、実際に行われた操作を SIEM ログで確認し、申請内容と乖離がないことを検証
恒久化または再申請:同じ例外が継続的に必要なら、組織標準そのものを見直す

14.6 AGENTS.md の三層構造

本記事の Section 7.1 で示した AGENTS.md 例は概念モデルに近い。実プロジェクトでそのまま運用すると、全プロジェクトに渡る共通ルールと、特定プロジェクトの個別事情、一時的な作業ルールが混在して肥大化し、更新が止まる。AGENTS.md は三層に分けて管理するのが現実的である。

レイヤー	配置場所	記載内容	更新責任者
① 組織共通レイヤー	テンプレートリポジトリ `org-agents-md-template` または共有 docs	全社共通の命名規則、セキュリティ規約、Codex モデル選択ルール、禁止事項	セキュリティ・ガバナンスチーム
② システム固有レイヤー	各リポジトリの `AGENTS.md`	そのシステム固有のアーキ前提、SLO、業務ルール、テスト方針、外部システム連携の制約	システムのテックリード
③ 案件・タスク固有レイヤー	ブランチ固有の `AGENTS.local.md`(`.gitignore` 対象)または PR description	進行中の特定タスクに特化した一時的なルール、現在のコンテキスト、注意事項	作業担当開発者

三層化の利点:

組織共通ルールの更新が一括反映される(① をテンプレートから取り込む同期スクリプト)
システム固有の事情を組織標準から分離できる(② が肥大化しない)
一時的な制約を Git 管理対象から外せる(③ で実験的な指示を試せる)
更新責任者が明確になり、レビュープロセスを設計しやすい

14.7 入力資料の信頼順位

Codex に複数の情報源を与えた場合、矛盾が発生する。あらかじめ信頼順位を AGENTS.md(① 組織共通レイヤー)に定めておく。

最優先:組織標準ドキュメント(docs/standards/*、AGENTS.md セクション 9〜11):「あるべき姿」の最終決定権
第二:Azure Resource Graph / az CLI による現状取得:「現実の状態」の確認。① と乖離があれば、まず ① を信じ、乖離を別途レポートする
第三:過去の Codex セッションログ・runbook:組織内の経験知。① と矛盾する場合は廃案として扱う
第四:Microsoft Docs MCP / Web 検索結果:業界一般知識。組織標準とのカスタマイズが必須
最下位:Codex 自身の事前知識:Codex の訓練データに含まれる一般知識。最新性・正確性を保証しない

14.8 レビュー観点テンプレート

Codex 生成物の PR レビューで、人間レビュアーが必ず確認する観点を定型化する。AGENTS.md または PR テンプレートに組み込む。

# Codex 生成物 レビュー観点(PR テンプレートに転記)

## 命名規則
- [ ] AGENTS.md セクション 9 の命名規則に従っているか
- [ ] グローバル一意リソースの名前が他テナント含めて利用可能か確認したか
- [ ] 既存環境との重複チェック結果が Bicep / Terraform 冒頭コメントに記載されているか

## ネットワーク
- [ ] 新規 CIDR が既存 VNet と重複していないか
- [ ] オンプレ ExpressRoute 接続先 CIDR との衝突がないか
- [ ] Private Endpoint の DNS Zone が既存と整合しているか

## タグ・ガバナンス
- [ ] 必須タグが全リソースに付与されているか
- [ ] cost-center が経理システムの有効コードか
- [ ] data-classification が組織のデータ分類ポリシーと整合するか

## セキュリティ
- [ ] DefaultAzureCredential を使い、接続文字列・API キーがハードコードされていないか
- [ ] Managed Identity に過剰権限が付与されていないか(最小権限)
- [ ] 暗号化、TLS 1.2 以上、診断ログ送信が設定されているか

## コスト
- [ ] SKU が部門の承認上限を超えていないか
- [ ] Application Insights の Daily cap が設定されているか
- [ ] 不要なリソース(orphaned Storage、停止中 VM 等)が含まれていないか

## Codex セッション情報
- [ ] 該当作業の Codex セッション ID が記載されているか
- [ ] 該当作業の Hooks エビデンスが Storage に記録されているか
- [ ] AGENTS.md セクション 11 のチェックリスト全項目が確認されているか

14.9 監視ノイズの抑制と人手介入条件

Codex を運用ライフサイクルに組み込むと、通知・アラート・エビデンス記録の量が増える。何でもかんでも通知するとアラート疲労が起き、本当に重要なものが見落とされる。以下のしきい値を組織として定める。

事象	Severity	通知先	人手介入条件
Hooks による危険操作ブロック発動	Sev 2	SIRT Slack(時間帯問わず)	同一ユーザーで1時間に3回以上ブロック発動時に確認
本番リソースの作成・更新	Sev 3	担当チーム Slack(営業時間内のみ即時)	変更管理チケットとの紐付けがない場合に確認
本番リソースの削除	Sev 2	SIRT Slack + 担当チームリード(時間帯問わず)	全件で人手確認
Codex Hooks 自体のエラー(タイムアウト等)	Sev 3	プラットフォーム運用 Slack	1時間に5件以上発生時に確認
承認境界違反(prod での Auto モード等)	Sev 1	SIRT Slack + CISO 通知	全件で即時人手確認
API キーローテーション失敗	Sev 2	プラットフォーム運用 Slack	全件で人手確認

14.10 Go / No-Go 判定:本番展開前の最終チェック

パイロットから本番展開に進む前に、以下を満たしているか確認する。1つでも満たさない場合は本番展開を延期し、不足部分を整備する。

カテゴリ	Go 条件
技術基盤	Foundry プロジェクト、Key Vault、Private Endpoint の本番構成が完了 Codex Desktop App / CLI を5名以上のパイロットで2週間以上問題なく運用できた Azure Skills Plugin と Azure MCP Server が安定動作している
セキュリティ・統制	Hooks スクリプトが managed_dir 経由で全端末に配布されている Immutable Storage によるエビデンス記録が動作確認済み Microsoft Sentinel への転送と検知ルールが設定済み禁止事項(14.4)が AGENTS.md に明記され、レビューで強制されている
運用体制	14.2 の RACI に基づき、4役割すべてに担当者が割り当てられている承認境界(14.3)が明文化され、関係者の合意が取れている例外承認フロー(14.5)が運用可能な状態にある障害対応 runbook と Codex への許可境界が定義されている
組織標準	AGENTS.md の三層構造(14.6)が確立し、共通レイヤーがテンプレートとして配布されている命名規則 NRD、ネットワーク設計書、IP 管理台帳が `docs/standards/` に整備されているレビュー観点テンプレート(14.8)が PR テンプレートに組み込まれている
教育・周知	対象開発者全員が Codex の基本操作と組織ルールの研修を受けた禁止事項とその理由が周知されている障害時の連絡先・エスカレーション経路が明確になっている

これらは「あったほうがよい」ではなく、本番運用での事故を回避するための最低限の整備項目と位置づける。

Go / No-Go 判定チェックリスト(印刷・転記用)

本番展開判定の最終確認に使うシンプルなチェックリスト。社内会議資料や導入判定書にそのまま転記して利用できる。すべての項目に ☑ が入った時点で本番展開判定会議を実施する。

A. 基盤(Infrastructure)

☐ Foundry プロジェクトが本番サブスクリプションに作成されている
☐ GPT-5.5(または GPT-5.4)モデルが本番デプロイメント名で利用可能
☐ Key Vault と Entra ID 認証ラッパースクリプトが全端末に配布済み
☐ Private Endpoint と閉域網構成が本番要件を満たして稼働
☐ Codex Desktop App / CLI / IDE 拡張のいずれかでパイロット2週間以上の稼働実績
☐ Azure Skills Plugin と Azure MCP Server が安定動作している
☐ Preview 機能を本番依存させていない(本番フロー全体が GA 機能のみで成立)

B. 認証・データ境界

☐ OIDC(Federated Identity Credential)による GitHub Actions → Azure 認証が動作確認済み
☐ API キーがハードコードされていない(全端末で Key Vault 経由)
☐ Conditional Access による MFA 強制が有効
☐ 個人 ChatGPT アカウントの業務利用を組織ポリシーで禁止済み
☐ Codex Cloud Tasks の利用方針が定義済み(機密リポジトリの制限有無)

C. 組織標準・AGENTS.md

☐ AGENTS.md の三層構造(組織共通/システム固有/案件固有)が確立済み
☐ 組織共通レイヤーがテンプレートリポジトリで管理され、各リポジトリに同期可能
☐ 命名規則 NRD が docs/standards/naming-conventions.md に整備済み
☐ ネットワーク設計書・IP 管理台帳が docs/standards/ に整備済み
☐ レビュー観点テンプレートが PR テンプレートに組み込まれている

D. 影響分析・Plan モード

☐ 影響分析の標準プロンプトテンプレート(12.2)が組織標準として配布済み
☐ Plan モードを本番作業の必須フローとして AGENTS.md に明記済み
☐ パイロット期間中に影響分析レポートを5件以上作成し、レビュー実績がある
☐ 例外的に Plan モードを省略可能な操作の範囲が明文化されている

E. Hooks とエビデンス基盤

☐ Hooks スクリプトが managed_dir 経由で全端末に MDM 配布されている
☐ 操作ログの記録(13.5)がパイロット期間中に問題なく動作した
☐ 段階導入の方針が定義済み(まず記録、次にブロック、次に Before/After…)
☐ Immutable Storage(Append Blob、Time-based Retention、Legal Hold)が設定済み
☐ Microsoft Sentinel への転送と最低限の検知ルール(14.10 参照)が設定済み
☐ Hooks 自体の障害時の挙動(fail-safe / fail-secure)が定義済み

F. 運用体制・ガードレール

☐ RACI(14.2)に基づき、4役割すべてに担当者が割り当てられている
☐ 環境別の承認境界(14.3)が明文化され、関係者の合意が取れている
☐ 本番禁止事項(14.4)の9項目が AGENTS.md または別文書に明記されている
☐ 例外承認フロー(14.5)が ITSM 上で運用可能な状態にある
☐ 障害対応 runbook と Codex への許可境界が定義されている
☐ 監視ノイズ抑制(14.9)のしきい値が定義済み

G. 教育・周知

☐ 対象開発者全員が Codex の基本操作と組織ルールの研修を受けた
☐ 本番禁止事項とその理由が周知され、テックリードレベルで理解されている
☐ 障害時の連絡先とエスカレーション経路が明確
☐ 例外承認の申請手順がドキュメント化されている

最終判定

A〜G の全項目に ☑ が入った場合 → 本番展開判定会議に進む(技術リード・セキュリティ・ガバナンス・プラットフォーム運用の合意で正式承認)
1〜5項目が未達 → 条件付き Go(未達項目を期限付きで整備し、再判定)
6項目以上未達 → No-Go(本番展開を延期し、不足項目を整備してから再判定)

15. 限界と注意点

15.1 API キー認証への依存

Codex Desktop App / CLI は依然として API キーで Foundry に接続する。Step 3 で構築した Key Vault + Entra ID ラッパー方式により API キーは端末に永続化されないが、完全な Entra ID パススルー認証ではない。Codex のロードマップに完全統合が含まれているが、それまでは以下の補完措置を併用する:

API キーの90日ローテーション
Conditional Access による MFA とデバイス要件の強制
Key Vault アクセスログの定期監査
定期的な再認証(長時間連続セッションを避ける)

15.2 自動実行の承認モード

Codex Desktop App の承認モードは Suggest / Auto / Full-auto から選べる。Azure リソースの破壊的操作(削除、SKU 変更、トラフィック切り替え)を行う作業では、Suggest モード+ PreToolUse フックでの二重防御が望ましい。Full-auto モードを採用する場合は、Hooks による統制が事実上唯一のリアルタイム防御線となるため、Hooks の設計と検証を通常以上に厳密に行う(13.11 ④、14.3 参照)。

15.3 Codex Cloud の利用範囲

Codex Desktop App / CLI / IDE 拡張は Foundry の自社デプロイモデルを利用できるが、Codex Cloud(@codex メンション、Slack 統合)は OpenAI 直接ホストで動作する。データ境界を厳密に管理したい場合は Codex Cloud 機能を無効化または利用範囲を限定する:

GitHub リポジトリの ChatGPT Connector を機密度の低いリポジトリに限定
Codex CLI の Cloud Tasks 機能(codex cloud)の組織ポリシーでの禁止
開発者の個人 ChatGPT アカウントの業務利用禁止

15.4 Azure Skills のスキルマッチング精度

Azure Skills は description ベースの暗黙発火を行うため、プロンプトが曖昧だと意図しないスキルが発火することがある。対策:

プロンプトに具体的なリソース名やリージョン、サービス名を含める
必要に応じて /skills で明示的にスキルを指定する
有効化スキルを必要なものに絞り、不要なものを無効化する

15.5 Hooks の対応範囲

Codex Hooks は本記事の構成における重要な統制レイヤーだが、現時点で以下の制約がある:

apply_patch(ファイル編集)未対応:リポジトリ内のファイル変更を完全に捕捉するには、Git の pre-commit / pre-push フックや CI 側の検証と組み合わせる必要がある
一部 MCP ツール未対応:Azure 操作の重要パスは az CLI / azd 経由(Bash)に揃え、AGENTS.md で「Azure リソース変更は az CLI 経由で実行」を組織標準として明示する
同期実行のみ:重い処理(SIEM 大量送信)は fire-and-forget パターンで非同期化する
プロジェクトトラスト:プロジェクトローカル Hooks は信頼済みプロジェクトでのみ動作。新規リポジトリのトラスト承認プロセスを組織で定める

15.6 IaC ファースト原則の徹底

Codex Desktop App から直接 Azure リソースを操作する選択肢があるが、それを濫用すると Bicep ファイルとのドリフトが発生する。組織ルールとして以下を徹底する:

本番への変更は必ず Bicep / Terraform 経由(IaC ファースト)
緊急時の手動変更は許容するが、48時間以内に IaC に反映
毎週のドリフト検出を自動実行(11.1 参照)
PreToolUse フックで本番リソースの直接変更コマンドをブロック(13.5 参照)

15.7 コスト管理の落とし穴

Azure 関連コストで予想外に膨らみやすいのは:

Application Insights のデータ取り込み量(Pay-as-you-go で 1GB あたり数百円、Daily cap の設定が必須)
Azure AI Search(RAG 用、Standard S1 で月3〜4万円から)
Foundry の Fine-tuned model のホスティング料金(推論せずとも発生)
外部リージョンからのデータ転送料金
Hooks のエビデンスを格納する Immutable Storage の容量増加(長期保管ポリシーにより削除不可)

Codex に定期的にコスト分析を依頼(11.2 のプロンプト)し、傾向を把握する習慣を組織に根付かせる。

15.8 モデル更新時の挙動変化

新しいモデルへの切り替え時(例:gpt-5.4 から gpt-5.5 への移行)には、以下を実施する:

本番投入前の2〜4週間のベンチマーク
既存テストケースでの A/B テスト
プロンプトテンプレートの再調整
応答長や応答形式が変わる可能性への備え
Hooks がブロックする頻度の変化監視(モデルが提案するコマンドパターンが変わるため)

15.9 ハーネス間の機能差

Codex Desktop App、CLI、IDE 拡張で機能差がある:

機能	Desktop App	CLI	IDE 拡張
並列タスク管理	○(主機能)	△(`codex exec` で疑似的に)	×
Automations(定期実行)	○	cron 経由	×
Git worktree 統合	○	△	×
インライン編集	×	×	○
CI/CD 統合	×	○	×
Hooks サポート	○	○	○(設定は同じ config.toml を共有)

組織として「すべてを Desktop App に揃える」よりも、用途に応じて使い分ける運用が現実的となる。Hooks の設定は3表面で共有されるため、エビデンス記録の一貫性は保たれる。

16. まとめ:判断軸と段階的導入

16.1 本記事の主張の集約

企業利用前提の Codex 活用は、Codex Desktop App / CLI / IDE 拡張を「ハーネス」、Azure AI Foundry にデプロイした GPT-5.5(または GPT-5.4)等の統合フロンティアモデルを「推論基盤」、Azure Skills Plugin + Azure MCP Server を「専門知識・実行層」とする三層構造が現実的な構成となる。
Azure Skills Plugin を導入すると、Codex は単なるコード生成器ではなく、設計判断、IaC 生成、デプロイ実行、運用監視、障害診断、構成管理を横断的に支援できるエージェントとして機能する。
各フェーズで Codex が自律的に動くのは、Azure 専門スキル(SKILL.md)と多数の Azure MCP ツールが、プロンプトの意図に応じて自動発火・連鎖するためである。
組織固有の規約・命名規則・禁止事項は AGENTS.md にまとめてリポジトリに置くことで、Codex のすべてのセッションで自動的に参照される。AGENTS.md は組織共通 / システム固有 / 案件固有の三層構造で管理すると更新が継続する。
既存環境への追加・変更ではゼロから設計させない。組織標準のドキュメント(命名規則 NRD、ネットワーク設計書、IP 管理台帳)を AGENTS.md および docs/standards/ に取り込み、変更対象のサブスクリプション・リソースグループに限定した Azure 環境スキャンと組み合わせる「ドキュメント優先 + スコープ限定スキャン」のハイブリッドが現実的。これにより命名重複、CIDR 競合、タグ不整合、既存ガバナンスからの逸脱を設計段階で機械的に防ぐ。
本番作業はいきなり実行しない。変更前に影響分析レポート(Blast Radius、ダウンタイム、ロールバック計画等)を作成し、Codex CLI の Plan モードで実行計画を立案し、人間レビュー・承認を経たうえで実行に移る。Azure Skills Plugin には変更影響分析特化のスキルが存在しないため、組織として標準プロンプトテンプレートとカスタムスキルで補強する必要がある。影響分析(意図と判断)・Plan モード(実行手順)・Hooks(個別操作)は積層的な3層防御として機能する。
本番作業のエビデンスは Codex Hooks で構造的に確保する。AI 応答のゆれを吸収しつつ、すべての操作を Immutable Storage に記録し、危険操作はリアルタイムでブロックし、本番変更は即時通知する。Azure リソースの作成・変更・削除では、操作ログだけでなく、PreToolUse で変更前の状態(Before)、PostToolUse で変更後の状態(After)と差分(Diff)を取得・記録する三点セットが、内部統制(J-SOX、SOC 2、ISO 27001)の変更管理要件を満たす最低限の構成となる。ただし Hooks は監査補助の自動化層であり、監査基盤の単独ソースではない。Codex Hooks(端末)+ GitHub Audit Log(CI/CD)+ Azure Activity Log(クラウド)+ Microsoft Sentinel(SIEM)の4層でエビデンスチェーンを構成する。
運用ライフサイクル全体での自動化は、Codex Desktop App の Automations 機能と GitHub Actions、Hooks を組み合わせることで実現する。
本番運用にはガードレールが必要。RACI による役割分担、環境別の承認境界、本番禁止事項の明文化、例外承認フロー、Go / No-Go 判定基準を整備した上で初めて、Codex を本番標準に組み込める。これらが未整備のまま本番展開すると、技術的にどれだけ良く構築されていても事故が起きる。
API キー認証への依存、Codex Cloud のデータ境界、IaC ファースト原則の徹底、Hooks 配布の組織統制など、企業環境固有の注意点を組織ガバナンスに織り込む。
ソースコード管理・課題管理は GitHub Enterprise Cloud + GitHub Issues / Jira を本記事の推奨とする。Azure 開発の標準である Azure DevOps は依然有効だが、Azure DevOps Remote MCP Server が現時点(2026年5月時点)で Codex(Desktop App / CLI)に対応しておらず、Microsoft 自身の AI 投資も GitHub 側に集中している。既存資産が Azure DevOps にある組織では、本記事のワークフローは「置換」ではなく「併用」または「一部移植」として読み、Codex のすべての連携機能を引き出すための回避策(VS Code 経由 MCP、非公式 az CLI ラッパー、双方向同期等)を組み合わせて運用する判断もありうる。

16.2 段階的導入のすすめ

すべての構成要素を最初から整えようとすると投資判断が膠着する。推奨される段階的アプローチ:

フェーズ	期間	達成目標
第1フェーズ:パイロット	1〜2か月	Non-production サブスクリプションで基盤セットアップと Azure Skills 導入を完了。5名程度のパイロットチームで、設計フェーズと開発フェーズに Codex を使った実利用パターンを計測。
第2フェーズ:本格運用準備	2〜3か月	閉域網構成と Hooks によるエビデンス基盤を本番向けに整備。Section 14 の運用ガードレール(RACI、承認境界、禁止事項、例外フロー、AGENTS.md 三層化)を確立。デプロイ・運用・監視フェーズに Codex を組み込む。20〜30名規模に拡大。
第3フェーズ:全社展開	3か月以降	Section 14.10 の Go / No-Go 判定をクリアしたうえで、PTU 本格導入、障害対応・保守フェーズの自動化、Automations 定常化、SIEM 統合の完成。全社展開と FinOps プラクティスの確立。

16.3 11ステップ全体の工程まとめ

Step	内容	所要時間
1	事前準備(契約・登録)	1〜3週間
2	Foundry プロジェクト・モデルデプロイ	1時間
3	Key Vault と API キー管理設計	2〜4時間
4	Codex Desktop App と config.toml セットアップ	30分/人
5	Private Endpoint と閉域網構成(本番のみ)	1〜2日
6	Azure Skills と AGENTS.md 整備(組織共通レイヤー)	4〜8時間
7	影響分析テンプレートと Plan モード運用ルールの整備	3〜5日
8	Codex Hooks 設計とエビデンス基盤構築	1〜2週間
9	運用ガードレール整備(RACI、承認境界、禁止事項、例外フロー)	2〜3週間
10	設計・開発・デプロイフェーズへの組み込み(パイロット)	4〜6週間
11	Go / No-Go 判定後の本番展開、運用・監視・障害対応・保守の自動化、SIEM 統合	継続(初動1か月)

初動期間は通常5〜8週間(影響分析・Plan モードの整備と運用ガードレールを含めて従来より2〜3週間長い)。100名規模の組織への全社展開は9〜13週間を見込む。Hooks の組織配備に Microsoft Intune / Jamf 等の MDM 設定、運用ガードレールの整備にセキュリティ・ガバナンス部門との合意形成が必要なため、IT インフラ部門・セキュリティ部門との早期調整が鍵となる。

16.4 最後に

Codex と Azure AI Foundry の組み合わせは、企業の AI コーディング展開を実用的な段階に押し上げた。Azure Skills Plugin の導入により、Codex は「コードを書くアシスタント」から「Azure 上のソフトウェアライフサイクルを横断的に支援する共同作業者」へと役割を広げている。そして Codex Hooks の登場で、その協働を監査可能な状態で本番運用に投入する道筋が整いつつある。「AI に作業させたが、何をしたかわからない」という従来の懸念は、Hooks による構造的なエビデンス記録と統制、そして組織としての運用ガードレールの組み合わせによって解消できる。残された課題は、技術選定でも実装でもなく、組織がこのエージェントとどう協働するか ── 役割分担、レビュープロセス、責任の所在、教育と訓練、そしてエビデンス文化の更新 ── という運用知の側にある。本記事の手順は、その協働を再現可能な形で立ち上げるための起点となる。各社の具体的なコンプライアンス要件と既存の Azure 環境を踏まえ、本記事を出発点として、組織固有の実装計画を組み立てていただきたい。

17. 付録:公式 URL 一覧

参考文献

Microsoft DevBlogs. (2026, March). Announcing the Azure Skills Plugin. All Things Azure.
Microsoft DevBlogs. (2026, March). Azure Skills Plugin - Let's Get Started! All Things Azure.
Microsoft DevBlogs. (2026, April). Building with Azure Skills (use case catalog). All Things Azure.
Microsoft / GitHub. (2026). microsoft/azure-skills: Official agent plugin providing skills and MCP server configurations for Azure scenarios.
Microsoft Learn. (2026). Install and configure Azure Skills.
Microsoft Learn. (2026). Codex with Azure OpenAI in Microsoft Foundry Models.
Microsoft Learn. (2026). Foundry Models sold directly by Azure.
Microsoft Azure Blog. (2026, April). OpenAI's GPT-5.5 in Microsoft Foundry.
Microsoft Community Hub. (2026, January). Announcing GPT-5.2-Codex in Microsoft Foundry.
Microsoft Community Hub. (2026, February). New Azure OpenAI models in Microsoft Foundry.
Microsoft Community Hub. (2025, December). OpenAI's GPT-5.1-codex-max in Microsoft Foundry.
OpenAI Developers. (2026). Codex Desktop App, CLI, IDE, and Authentication Documentation.
OpenAI Developers. (2026). Codex Configuration Reference (Advanced and Sample).
Microsoft Foundry blog (DevBlogs). (2025-2026). Codex Azure OpenAI Integration.
Microsoft / GitHub. (2026). microsoft/skills repository.
MicrosoftDocs / GitHub. (2026). Agent-Skills repository.
OpenAI Developers. (2026). Hooks – Codex (PreToolUse, PostToolUse, SessionStart, UserPromptSubmit, Stop lifecycle events; managed_dir for enterprise).
OpenAI / GitHub. (2026). Codex Issue #16732: ApplyPatchHandler doesn't emit PreToolUse/PostToolUse hook event.
Crosley, B. (2026, May). Codex Hooks Make the Harness Real.
Caparas, J. (2026, April). Codex hooks just gave you back complete control over your code (Exit code 2, lifecycle events, blocking mechanism). AI @ Sulat.com.
Speakeasy. (2026). AI agent hooks: the interface for governing AI agents.
Agentic Control Plane. (2026, April). Codex CLI hook governance: what works today (and what doesn't).
Microsoft Learn. (2026). Set up the remote Azure DevOps MCP Server (preview) - クライアント制約: Codex / Claude / ChatGPT は Entra OAuth Client ID の動的登録が必要、現時点では VS / VS Code のみサポート.
Microsoft DevBlogs. (2026, March). Azure DevOps Remote MCP Server (public preview).
Microsoft / GitHub. (2026). microsoft/azure-devops-mcp: Remote-first onboarding experience, local server option.