Codexの法人導入とは｜管理者の作業は5段階にまとまる

Codex の法人導入とは、担当・権限・実行範囲・リポジトリ設定・監査の5点を管理者が先にそろえ、業務で使われる状態まで運ぶ作業です。
アカウントを配って終わりにすると、設定は済んでいるのに誰も使っていない状態が残ります。
私が約50社の法人セットアップで最初に確かめるのも、アカウントの数ではなく「誰が何をどこまで実行できる状態になっているか」です。

Codex は、指示を受けてプログラムの作成や修正を進める OpenAI のAIです。
社員のパソコン上での利用と、OpenAI 側の環境での利用（Codex Cloud）に分かれ、法人導入ではこの2つを別々に許可し、別々に統制します。
以下で言うワークスペースは、会社単位で利用者と権限をまとめて管理する単位です。
リポジトリは、プログラムのソースコードを置いて共有する場所を指します。

結論：5段階を順に埋めれば社内に広げられる

1. 担当を決め、どこから広げるかを選ぶ
2. ワークスペースの権限をそろえる
3. 社員のPCでの実行範囲を requirements.toml でそろえる
4. リポジトリの共通設定で、誰が使っても同じ結果にする
5. 監査とレポートの線を先に引く

順番には理由があります。
実行範囲を決める前に業務の手順を書いても、歯止めになりません。
担当を決めずに端末の設定を配ろうとすると、情報システム部門と開発部門のあいだで止まります。

OpenAI公式の管理者手順8ステップとの対応

この5段階は私の言い換えです。
OpenAI の公式ドキュメントは、管理者向けの展開手順を8ステップで書いています（出典 https://learn.chatgpt.com/docs/enterprise/admin-setup ・2026年10月15日確認）。
対応は次の表のとおりです。
社内で稟議を回すときは、公式の呼び名も併記しておくと、あとで公式ドキュメントと突き合わせる人が迷いません。

なお、Claude Code と Codex の両方の法人セットアップをまとめて設計する支援については、Claude Code / Codex 法人セットアップのページに詳しく書いています。

段階1｜担当を決め、どこから広げるかを選ぶ

公式の Step 1 は「Assign owners and choose a rollout」です。
設定の話ではなく、担当の割り当てと展開方式の選択が最初に来ます。
順番が意外に思えるかもしれませんが、現場で止まる原因はほぼここです。

決めるのは3つの担当（ワークスペース・端末・リポジトリ）

• ワークスペースの権限を触る人：Admin Console にログインし、誰にCodexを配るかを決める
• 社員PCの設定を配る人：requirements.toml を配る担当。経路はmacOSのMDM管理設定（会社のパソコンを遠隔で設定管理する仕組み）・Agent Security・システムへのファイル配置から段階3で選ぶ
• リポジトリの共通設定を書く人：業務の手順と禁止事項を書き込む担当

段階3と段階4は、所管部署が別になることが多いところです。
端末管理は情報システム部門、リポジトリは開発部門という会社では、ここで名前を決めておかないと「あちらが設定するはず」で2週間が溶けます。

最初の対象は1チームに絞る

推測：全社一斉にすると、段階3の端末設定が追いつきません。
1チーム→部門→全社の順に広げると、最初のチームで出たつまずきを設定ファイルに反映してから次へ渡せるので、同じ質問を部門ごとに受けずに済みます。

もうひとつ、どのログイン方式で使うかを方針として決めてください。
方式は2つで、ChatGPT のアカウントでログインする方式（値は chatgpt）と、APIキーで使う方式（値は api、Amazon Bedrock 経由もこちら）です。
APIキーは外部のプログラムからOpenAIの機能を呼ぶための文字列で、この方式は使った分だけの従量課金になります。
社員にAPIキーで使わせないなら、段階3の requirements.toml に allowed_login_methods = ["chatgpt"]（許可するログイン方式を列挙するキー）と書きます（公式 managed-configuration の例、2026年10月15日確認）。
ここを見落として、月末に想定外の請求を見て相談に来る会社があります。

Re-railの進め方と期間の目安

①お問い合わせ → ②無料相談・簡易診断（60分） → ③ご提案・お見積り → ④ご契約・キックオフ → ⑤構築 → 完了判定 → （選んだ場合）伴走支援。

キックオフから設定を終えるまでは2〜4週間が目安です。
そのあとの伴走支援は、3ヶ月・6ヶ月・12ヶ月から選んでいただきます。
時間がかかるのは段階4の「業務の手順を書く」ところで、業務を知っている人の時間をどこで何時間もらえるかが期間を決めます。

段階2｜ワークスペースの権限をそろえる

公式の Step 2 は「Configure workspace access and identity」です。

誰にCodexを配るかはワークスペース設定で決まる

引っかかるのが、画面が2通りある点です。
CodexとWorkがまとまっている画面では、「Allow members to use Codex and Work Locally」という設定1つでローカル利用を許可します。
Codex LocalとWork Localが別セクションに分かれている画面では、Codexのローカル利用は「Allow members to use Codex locally」で許可します。
もう一方の「Use Work locally」はCodex以外の機能の設定で、片方を有効にしてももう一方は有効になりません（原文はEnabling either one doesn't enable the other）。
手順書には画面に出ている名前をそのまま書いてください。
違う名前だと、担当者が「この設定が無い」で止まります。

Codex Local と Codex Cloud は別に有効化する

ワークスペースの設定では、社員のパソコン上での利用を Codex Local、OpenAI 側の環境での利用を Codex Cloud と呼び分けます。
公式はこれを権限の区分名と注記しており、別の製品やアプリではありません。
Codex Cloud は Enterprise ワークスペースで既定オフです。
公式の原文は「Codex Cloud is off by default for Enterprise workspaces.」。
ただし、以前の Codex Cloud（Legacy）でクラウドを有効にしていたワークスペースは、その設定が引き継がれて使える状態のままです（公式 Step 5、2026年10月15日確認）。
クラウド側を使うかどうかは「Use Codex in the cloud」の設定で決まるので、今の状態を管理画面で確かめてください。

新しいモデルは管理者が有効化しないと使えない

公式の変更履歴は、新しいモデルを Enterprise で使うには管理者の有効化が要ると書いています（原文は「Enterprise administrators must enable the new models.」、出典 https://learn.chatgpt.com/docs/changelog ・2026年10月15日確認）。
社員から「新しいモデルが選べない」と言われたら、端末より先にワークスペースの設定を確認してください。
管理者が有効化していないモデルは、端末側では選べません。
新しいモデルが出たら管理者が有効化する、という運用を最初に決めておいてください。

段階3｜社員のPCでの実行範囲を requirements.toml でそろえる

公式の Step 3 は「Configure local runtime requirements」。
社員のパソコンで Codex がどこまで実行できるかを、管理者側から決めます。

requirements.toml は置き場所が決まっている

実行範囲を全社でそろえるためのファイルが requirements.toml です（出典 https://learn.chatgpt.com/docs/enterprise/managed-configuration ・2026年10月15日確認）。

• Unix（Linux / macOS）：/etc/codex/requirements.toml
• Windows：%ProgramData%\OpenAI\Codex\requirements.toml

旧方式の managed_config.toml は、新規導入では使いません。
以前から使っていた端末に残っている旧ファイルの設定は、システムへのファイル配置と Agent Security（Admin Console から各端末へ設定を配る仕組み）より強く効きます。
ただし macOSのMDM管理設定は、旧ファイルより強く効きます。
旧ファイル（managed_config.toml）の置き場所は、同じページの Locations にあります。

配り方は3つ、競合すると上位が勝つ

同じキーを複数の経路で配ると、上の経路が勝ちます。
配る経路は1つに決めてから増やしてください。
設定したのに効かないときは、配布経路が重複していないか、端末に旧ファイル managed_config.toml が残っていないかを確認してください。

新規導入は permission profiles で書く

新規導入では、sandbox_mode（Codex が書き換えやネットワーク利用をどこまでできるかを決める設定）ではなく permission profiles で書くよう公式は勧めています（公式 Step 3、2026年10月15日確認）。
全社へ配る前に、1台の端末で組み込みのプロファイルが効くかを確かめてから広げてください。
組み込みのプロファイルは3つあります。

• :read-only：読むだけ。ファイルを書き換えない
• :workspace：作業フォルダ（段階2のワークスペースとは別で、Codexが作業しているフォルダ）の中なら書き換えてよい
• :danger-full-access：制限なし

default_permissions（既定の実行範囲）は、sandbox_mode と、その細かい条件を書く [sandbox_workspace_write] とは併用しません（出典 https://learn.chatgpt.com/docs/config-file/config-reference ・2026年10月15日確認）。

requirements.toml で最初に決めるとよい主なキーは次のとおりです。

• [allowed_permission_profiles]：使ってよい実行範囲のプロファイルを、":read-only" = true の形で1行ずつ並べる設定のまとまり（公式 managed-configuration の例、2026年10月15日確認）
• default_permissions：既定の実行範囲
• [mcp_servers]：つないでよい外部ツールの許可リスト
• [rules]：全社に強制するコマンドのルール（段階4で説明します）
• allowed_login_methods：段階1で選んだログイン方式を列挙する

ほかのキーと値の書式は、公式の managed-configuration のページで確かめてください。

段階4｜リポジトリの共通設定で、誰が使っても同じ結果にする

段階3まで終えると、社員が実行できる範囲はそろいます。
ただ、この時点では同じ指示を出しても人によって結果が違う状態です。
会社の前提も、業務の手順も、Codex 側は知らないからです。

この段階で書くのは Configuration と Rules

公式の Step 4 は「Standardize repository configuration」で、中身は Configuration / Rules / Skills の3分類です。
本記事で扱うのは、前の2つです。
原文に AGENTS.md の語は出てきません。
2026年10月15日に、公式ページの元データ（Markdown形式）で確認しました。
AGENTS.md は別ページに独立した仕様として載っているので、Step 4 の Configuration に相当するものとして読むのが素直です。

ワークスペースへの参加、使えるモデル、Platform API（OpenAIの機能をAPIキーで呼ぶ窓口で、段階1のログイン方式 api で使うもの）、外部サービスとの接続は、リポジトリ側では与えられません。
原文は「Repository configuration can supply defaults and reusable workflows. It can't grant workspace, model, Platform API, or connected-system access.」。
参加とモデルは段階2、Platform API は段階1のログイン方式、外部サービスとの接続は段階3の [mcp_servers] で決まります。
段階4で書けるのは「どう進めるか」だけです。

AGENTS.md に業務の手順を書く（合計32 KiBまで）

AGENTS.md は、Codex が自動で読み込む指示書です（出典 https://learn.chatgpt.com/docs/agent-configuration/agents-md ・2026年10月15日確認）。
利用者ごとの設定フォルダ ~/.codex と、リポジトリの最上位から今の作業場所までの各フォルダにあるものを読み込みます。
今の作業場所に近いフォルダのものが後から読み込まれ、先のものを上書きします。

上限は、読み込まれる AGENTS.md をすべて結合した合計にかかります。
合計が 32 KiB を超えると、それ以降のファイルは読み込まれません（上限を決める設定 project_doc_max_bytes の既定値）。
全社の前提と部門ごとの手順を1枚に詰め込むと、わりと簡単に届きます。
私は、ルートに全社共通の短いものを置き、業務ごとのサブディレクトリに手順を置く形にしています。

禁止事項は Rules で強制する

AGENTS.md は上書きできる指示でしかありません。
禁止を強制したいなら、Rules を使います（出典 https://learn.chatgpt.com/docs/agent-configuration/rules ・2026年10月15日確認）。
公式は「Rules are experimental and may change.」と注記しています。
仕様が変わる前提で、段階5の定期見直しに Rules の確認を入れてください。

• 置き場所は、社員の端末の ~/.codex/rules/ と、リポジトリ最上位の .codex/rules/。リポジトリ側は、そのリポジトリの .codex/ を信頼済みとして扱っている場合だけ読み込まれ、確かめ方が公式に無いため歯止めに数えない
• 決定は allow（実行してよい）／prompt（実行前に確認する）／forbidden（実行させない）の3種
• 社員が外せないように全社で止めるものは、管理者が requirements.toml の [rules] に書く

全社に強制する [rules] の書き方は公式の managed-configuration のページ（Enforce command rules from requirements）に、端末やリポジトリに置くルールの書き方とルールが効かない例は公式の Rules のページにあります。
配る前に両方のページを確かめてください。

業務の手順、禁止、全社の上限の3層で書き分けると「誰が使っても同じ結果」に近づきます。

段階5｜監査とレポートの線を先に引く

公式の Step 7 は「Set up governance and observability」。
見るものは3つあります（出典 https://learn.chatgpt.com/docs/enterprise/governance ・2026年10月15日確認）。

• 管理ダッシュボードの Workspace analytics：管理画面で期間や条件を絞り込みながら見るレポート
• Analytics API：集計値を取り出すAPI（外部のプログラムから数値や記録を取り出すための接続窓口）
• Compliance API：監査記録を取り出すAPI

集計は Analytics API、記録は Compliance API

Analytics API は、利用量などの集計値を取るものです。
社内の定例レポートに使う数字はこちらから取ります。
Compliance API は記録を取るものです。

Compliance API で会話の記録が見えることと、社員PC上の操作がすべて記録されていることは別です。
原文は「Conversation visibility alone does not establish a complete record of local actions.」。
社員のパソコン上での実行は、OpenTelemetry（アプリの動作記録を外部の監視基盤に送るための共通規格）のイベントで別に集めます。

スコープを間違えると取れない

Analytics API を呼ぶには、ワークスペース単位の管理者キー（workspace-scoped Admin key）に、スコープ（APIで許可される操作の範囲）enterprise.analytics.usage.read を付けます。
名前が似ている Codex専用スコープの codex.enterprise.analytics.read を指定してしまいがちですが、公式には「The Codex scope codex.enterprise.analytics.read doesn't grant access to that endpoint」と明記されています（出典 https://learn.chatgpt.com/docs/enterprise/analytics-api ・2026年10月15日確認）。

ダッシュボードの項目名を前提にレポートを固定しないでください。
公式の注意は「Don't build a durable reporting contract from dashboard labels or downloaded report fields; those can change as the product evolves.」。
社内の定例レポートは、APIの値で組んでください。

設定の見直しを定期で回す（公式 Step 8）

公式の Step 8 は「Verify and maintain the rollout」です。
設定は、公式の変更に合わせて直す場面が出ます。
2026年10月14日（米国太平洋夏時間の正午）に、ChatGPTのアカウントでログインしている利用者のCodexから GPT-5.5 が引退しました（APIキーで使っている場合は対象外）。
公式は管理者に、ワークスペースの既定モデル、保存したモデル設定、管理者が配る設定、カスタムエージェント、定期実行タスク、スクリプトに残っている gpt-5.5 を、契約プランとアプリが対応していれば GPT-6.1 Sol（gpt-6.1-sol）へ書き換えるよう求めています（出典 https://learn.chatgpt.com/docs/changelog ・2026年10月15日確認）。
自社で選べるかは、段階2の管理者による有効化の状態と、この変更履歴で確かめます。
管理に関わる機能の追加も続いています（出典 https://learn.chatgpt.com/docs/whats-new ・2026年10月15日確認）。
月に1回は公式の変更履歴と段階4の Rules を見直し、触った日と次に見る日を記録してください。

設定の次が本番｜社内に広げるときの進め方

設定が終わった状態は「使われる状態」ではありません。
私が現場で見てきた失敗は、技術的なものより、この先の進め方で起きています。

最初に任せる業務は1つに絞る

最初に任せる業務は1つに絞り、着手前と着手後の作業時間を測って記録します。
そのあとで2つ目・3つ目の業務へ広げ、社内の運用ルールにしていきます。
「とりあえず全部の業務で試してください」と広く渡すと、誰も最後まで通さないまま3ヶ月が過ぎます。

時間を測る理由は、社内で予算を通すためだけではありません。
どの作業で効いたのかが分かっていれば、似た性質の作業を次に選べます。

「できたつもり」を残さない完了判定

引き渡し前に、私は6点を確かめています。

1. AGENTS.md に書いた手順名を指示すると、その作業が始まる
2. 手順名を使わず作業の内容を直接指示しても、同じ作業が始まる
3. 情報が足りない指示でも、不足を聞き返したうえで最後まで通る
4. つないだ外部ツールで実際に1つ操作が成功する
5. 主目的の業務を1つ最後まで実行できる
6. お客様が自分の手で1回再現できる

6番目がいちばん落ちます。
私が操作して動いたところを見せて終わると、翌週には誰も起動していません。

外部ツールとの連携（MCP、Codex から Google Drive や会計ソフトなどの外部サービスを操作するための仕組み）は、目的に合わせて絞り、1回操作が成功するところまで確かめます。
認証の切れ方と付け直し方も合わせて引き渡します。
段階3で設定した [mcp_servers] の許可リストと、実際につないだものをそろえておいてください。

よくあるつまずき4つ

• APIキー方式を選んで従量課金になる：段階1で決め、段階3で縛ります
• 外部連携の認証が切れて止まる：付け直し方を引き渡し時に渡しておきます
• 動作確認が足りず「できたつもり」で終わる：上の6点で止めます
• 最初の業務を広く取りすぎて定着しない：1つに絞ります

Re-railは、Claude Code / Codex の法人セットアップを約50社で実施しています（2026年7月時点）。
自社でも50体以上のAIエージェントで業務を分担しています（2026年7月時点）。

完成した AGENTS.md の実例

本文で説明した要素だけで、リポジトリに置く AGENTS.md の形を組んでみます。

社内の共通ルールを書く部分

リポジトリのルートに置くものです。
全社に共通する前提だけを短く書きます。

# 全社共通の前提

## この会社について
- 事業: （業種と主な業務を1〜2行）
- 開発体制: （チーム構成を1行）

## 使ってよい外部ツール（MCP）
- 社内ドキュメント置き場（読み取りのみ）
- 課題管理ツール（読み取りと起票）
- 上記以外はつながない。許可リストは管理者が requirements.toml の
  [mcp_servers] で管理しているため、ここに書いても追加されない。

## 実行範囲
- 既定は作業フォルダ内の書き換えまで（permission profile は :workspace）。
- 範囲を広げる必要が出た場合は、ここを書き換えず管理者に相談する。
  既定は requirements.toml の default_permissions、選べる範囲は
  allowed_permission_profiles で決まっており、このファイルからは変えられない。

## 出力の形式
- 日本語で書く。
- 変更の理由を先に1〜3行。そのあとに差分。
- 推測で埋めた箇所は「要確認」と明記する。

## 禁止事項について
- 本番データベースへの接続、本番環境へのデプロイ、顧客データの
  ダウンロードは行わない。
- ただし、この記述は「指示」であって歯止めではない。
  実際の遮断は端末側の ~/.codex/rules/ の forbidden と、管理者が配る
  requirements.toml の [rules] で行う。リポジトリ側は歯止めに数えない。

## このファイルのサイズ
- AGENTS.md の合計は 32 KiB（project_doc_max_bytes の既定）を超えると
  以降が読まれない。全社共通はこの1枚に収め、業務ごとの手順は
  サブディレクトリの AGENTS.md に分ける。

業務の手順を書く部分（禁止はどこで強制しているかを添える）

業務ごとのサブディレクトリに置くものです。
ルート側のファイルが先に読み込まれ、こちらが後から上書きします。
1つのディレクトリにつき1ファイルまでなので、ディレクトリを分けて置きます。

# 請求書の取り込み作業の手順

（配置: billing/AGENTS.md。ルートの AGENTS.md が先に読み込まれ、
  このファイルが後から上書きする）

## この作業で扱うもの
- 入力: 取引先から届いた請求書のPDF（inbox/ に置かれる）
- 出力: 取引先・日付・金額・品目に整理した表（output/ に書く）

## 手順
1. inbox/ のPDFを1件ずつ読む。
2. 取引先名を社内の表記に寄せる（取引先マスタを参照する）。
3. 金額は税込で記録し、税率が複数ある場合は行を分ける。
4. 読み取れなかった項目は空欄にせず「要確認」と書く。
5. 1件ずつ output/ に追記し、まとめて書き換えない。

## この作業での注意
- inbox/ のPDFは消さない。移動もしない。
- 会計ソフトへの登録は行わない。表を作るところまで。
  （会計ソフトは管理者が [mcp_servers] の許可リストに入れていないので、
  MCP経由では操作できない。コマンドで触らせたくない操作は端末側の
  ~/.codex/rules/ の forbidden と、全社強制なら requirements.toml の
  [rules] で止める）

## 広げる前に
- 着手前と着手後の作業時間を記録する。
- 2つ目の業務に広げるのは、この作業が1人で再現できてから。

読んだ人が段階4に戻れるよう、どこで強制しているかをコメントで添えておきます。

よくあるご質問

まとめ｜5段階を順に埋めれば、社内に広げられる

1. 担当を決める：ワークスペース・端末・リポジトリの3つの担当者を決め、どのチームから広げるかを選ぶ（公式 Step 1）
2. ワークスペースの権限をそろえる：誰に配るかを決め、ローカル利用とクラウド利用を別に許可する（公式 Step 2）
3. 社員PCの実行範囲を requirements.toml でそろえる：permission profiles で範囲を決め、配布経路を1つに絞って配る（公式 Step 3）
4. リポジトリの共通設定で結果をそろえる：業務の手順は AGENTS.md。禁止は端末側の ~/.codex/rules/ の Rules、外せなくするなら requirements.toml の [rules]（公式 Step 4）
5. 監査とレポートの取り方を決める：集計は Analytics API、記録は Compliance API、ローカル実行は OpenTelemetry（公式 Step 7・Step 8）

本記事の出典はすべて learn.chatgpt.com の公式ドキュメントで、2026年10月15日に確認したものです。
価格については、公式ページがこの日に取得できなかったため数値を書いていません。
GPT-5.5 の引退でモデル名の書き換えが必要になったように、「いつ時点の設定か」が分からない設定ファイルは、半年後に誰も触れなくなります。

自社の環境でどの段階から手を付けるか迷われたら、無料相談（60分）でお聞きします。

法人でのClaude Code / Codex 導入

Claude Code / Codex
法人セットアップの相談

自社の業務に合わせて、どこから導入するかを一緒に決めます。
設定から社内で使い続けられるまでを、Re-railが支援します。

導入について相談する法人セットアップの内容を見る