Codex թիմ導入実践: 権限・運用ルール・Bedrock 経路を一気に決めるガイド

チームで Codex を使い始めると、セキュリティや運用側が最初に聞くのは「どのプランを買うか」ではなく、「誰に full access を与えるか、.env は何を読めるか、usage と audit logs はどこで見るか」です。これらがチーム導入の最初の分岐になります。結論から言うと、最初に API Key を選ぶのではなく、まず権限境界を決めます。本稿では、requirements.toml と permission profiles でメンバー権限を絞り、共有 AGENTS.md を標準化し、ChatGPT workspace・API Key・Amazon Bedrock のどれを採るかを決め、最後に analytics と compliance を接続するための判断枠を示します。はじめに明確にしておきたい事実が一つあります。AWS は 2026-06-03 に GovCloud で GPT-5.4 を利用可能にしたと発表しましたが、Codex Bedrock provider は現時点で GovCloud endpoints をサポートしていません。これは同じ話ではありません。

1. 企業の権限フレームワーク: full access を各人のローカルに散らさない

会社が Codex を標準化したいなら、まず cloud-managed requirements でローカルの振る舞いを縛れます。requirements.toml は Codex のポリシー設定ファイルです。管理者は個人ごとに設定を任せるのではなく、ユーザーグループ単位でポリシーを配れます。

1.1 requirements.toml の主要フィールド

実際の導入でよく使う項目は次の通りです。

フィールド	用途	推奨値
approval_policy	人間承認が必要かを制御	"suggest" か "auto-edit"。チームのデフォルトに "never" は使わない
approvals_reviewer	承認者を指定	チームオーナーまたはセキュリティ責任者
automatic_review_policy	自動レビューの規則	プロジェクトのリスクに応じて設定
permission profiles	新しい権限モデル (0.138.0+)	新規導入では推奨
sandbox_mode	旧権限モデル	既存移行でのみ利用
web_search_mode	Web 検索を許可するか	必要時のみ、機密案件では制限
managed_hooks	hook 設定を統一	lint-check、test-runner など
MCP servers allowlist	利用可能な MCP サーバー	許可した filesystem や github のみ

Codex 0.138.0 以降は、allowed_permission_profiles と default_permissions を使う permission profiles が推奨です。旧環境では allowed_sandbox_modes も残ります。

1.2 禁止すべき組み合わせ

チームのデフォルトにしてはいけないのは次の組み合わせです。

danger-full-access + approval_policy = "never"

これは最も強い権限で、承認なし実行の組み合わせです。個々のローカル設定に出てこないよう、cloud-managed requirements 側でブロックします。

1.3 設定例

# requirements.toml
[managed]
approval_policy = "suggest"
allowed_permission_profiles = ["suggest", "auto-edit"]
default_permissions = "suggest"

[mcp]
allowed_servers = ["filesystem", "github"]

[hooks]
managed_hooks = ["lint-check", "test-runner"]

この例では、メンバーを "suggest" と "auto-edit" に限定し、既定は "suggest" です。MCP は filesystem と github のみを許可し、hook も統一しています。中核の開発グループだけ "auto-edit" にして、インターンは "suggest" にするといった分け方も、ここで行います。

2. 最小権限と sandbox 設計: 具体ルール、deny glob、機密ファイル保護

セキュリティ担当に必要なのは「最小権限」というスローガンではなく、具体的なルールです。どのファイルを読めて、どれを編集できて、どれを完全に禁止するのかを決めます。

2.1 filesystem の 3 つの値

Codex の filesystem 権限には 3 つあります。

• read: 読み取りのみ、編集なし
• write: 読み書き可
• deny: 完全にアクセス禁止

優先順位は単純で、より具体的なルールが勝ち、deny が最優先です。たとえば "**/*.env" = "deny" と ":workspace_roots" = "write" を両方設定しても、.env は依然として読めません。

2.2 workspace の範囲制限

:workspace_roots で作業範囲を絞れます。

[permissions.filesystem]
":workspace_roots" = "write"

これで Codex は現在の workspace root とその配下だけで動きます。外側のファイルには触れません。

2.3 機密ファイル保護

deny glob を使えば、機密の環境ファイルや secret ディレクトリを隠せます。

[permissions.filesystem]
":workspace_roots" = "write"
"**/*.env" = "deny"
"**/secrets/**" = "deny"
"**/*.log" = "read"

この設定の意味は次の通りです。

• workspace root とその配下は書き込み可
• すべての .env はツリー全体で禁止
• secrets/ 配下は禁止
• .log は読み取り専用

2.4 network 権限

network 権限は、ドメイン allow/deny で管理できます。

[permissions.network]
enabled = true
allow = ["github.com", "api.openai.com"]
deny = ["localhost", "127.0.0.1"]

これで github.com と api.openai.com には到達できますが、localhost と loopback は止まります。ローカル/プライベートネットワークには追加の保護があるため、チーム側で独自の allow/deny を作ることもできます。

2.5 permission profiles と sandbox mode

比較	Permission profiles	Sandbox mode
世代	新しい導入モデル	旧モデル
粒度	より細かい	粗い
設定項目	allowed_permission_profiles + default_permissions	allowed_sandbox_modes
推奨	新規導入で優先	既存移行でのみ

新規導入は permission profiles を優先し、sandbox mode は段階的に外していきます。

3. チーム共有ルール: AGENTS.md は 1 つ、個人別ファイルは作らない

チームには共有 prompt、共有の文脈ルール、共有の review instruction が必要です。各人が別ファイルを保守してコストを増やす必要はありません。AGENTS.md は Codex の指示ファイルで、階層構造と優先順位を持てます。

3.1 instruction chain の順序

Codex 起動時の instruction chain は次の順です。

global rules (~/.config/codex/AGENTS.md)
  -> project rules (project AGENTS.md)
  -> nearest-to-current-directory rules

重なったときは、現在地に近いファイルが勝ちます。

3.2 階層構成のすすめ

全部を 1 つの巨大ファイルに詰め込まないでください。層を分けます。

• ~/.config/codex/AGENTS.md: global rules、スタイル、テスト期待値、一般禁止事項
• project の AGENTS.md: アーキテクチャ、依存、デプロイ方針
• module の AGENTS.md: モジュール固有の要件

各層を 10-15 KiB くらいに保つと、運用しやすく、打ち切りも避けやすくなります。

3.3 32 KiB 上限への対処

Codex の既定値 project_doc_max_bytes は 32 KiB です。AGENTS.md が大きくなると打ち切られます。

対処法は 2 つあります。

1. project_doc_max_bytes を引き上げる
2. ファイルをネストしたディレクトリに分割する

保守性を考えると、分割の方がたいてい良いです。

3.4 AGENTS.override.md の役割

AGENTS.override.md は上位の AGENTS.md を上書きするためのもので、優先度は最も高いです。使う場面は次の通りです。

• 特定のサブディレクトリだけ一時的にルールを変えたい
• 実験モジュールで制限を緩めたい
• モジュールの方針がプロジェクト全体と違う

上書き理由は必ず残し、あとで見ても分かるようにします。

3.5 運用のコツ

AGENTS.md を保守するときは、少なくとも次を明示します。

• Ownership: どの層を誰が持つか
• Maintenance budget: スプリントごとのレビュー時間
• Review cycle: global は四半期、project は月次など、いつ見直すか

こうすると、AGENTS.md は各人の私物ではなく、共有の生きたルールになります。

4. 導入経路の選び方: ChatGPT workspace、API Key、Bedrock をどう使い分けるか

組織は、どのアカウント経路を採るかを決める必要があります。3 つの経路は、強みも制限も適性も違います。

4.1 比較表

観点	ChatGPT Business/Enterprise	API Key	Amazon Bedrock
認証	ChatGPT sign-in	OPENAI_API_KEY	Bedrock API key または AWS IAM
請求先	OpenAI workspace	OpenAI API account	AWS account
チーム管理	Analytics Dashboard、managed requirements	ネイティブなチーム管理なし	AWS IAM と CloudTrail
機能の充実度	最も充実	最も柔軟	部分的 (4.2 参照)
コンプライアンス / region	OpenAI regions	OpenAI regions	AWS regions と data residency
GovCloud 対応	なし	なし	モデル可用性はあるが、Codex provider は別問題 (4.3 参照)
向いている組織	workspace 管理を重視する小中規模チーム	柔軟に統合したい開発者	AWS 中心の調達・IAM・監査を重視するチーム

4.2 Bedrock で欠ける機能

2026-06-08 時点で、この経路では次の機能が使えません。

• Fast Mode
• hosted web/file search
• computer use
• shell tool
• image generation tool
• remote MCP servers
• on-demand inference only は不可。Provisioned Throughput を使います

これらは OpenAI-hosted cloud services、hosted tools、cloud-managed discovery に依存するため、ここには含まれません。必要なら ChatGPT workspace か API Key を選びます。

4.3 GovCloud の整理

ここは 2 つの事実を分ける必要があります。

1. AWS GovCloud (US-West) で GPT-5.4 は利用可能

   • モデル自体は GovCloud で使える
   • GPT-5.4 を Bedrock API で呼べる

2. Codex Bedrock provider は GovCloud endpoints をまだサポートしていない

   • Codex の amazon-bedrock provider は AWS GovCloud Regions の Bedrock Mantle endpoints に未対応
   • 今日の時点で GovCloud へ Codex をそのまま向けることはできない

「Codex on Bedrock は GovCloud 対応」と一言で書かないでください。

4.4 適用シナリオ

組織ごとに経路を選びます。

ChatGPT Business/Enterprise

• 小中規模チーム
• workspace 管理が必要
• 機能をできるだけ揃えたい
• AWS の請求や IAM は不要

API Key

• 柔軟に接続したい開発者
• チーム管理は不要
• OpenAI API account に直接課金
• コンプライアンス管理は不要

Amazon Bedrock

• 既存の AWS account / IAM / billing がある AWS 中心チーム
• AWS commitments に集約したい
• data residency や特定の AWS region が必要
• 4.2 の部分機能制限を受け入れられる

5. Bedrock の設定と制限: AWS-native auth、機能不足、GovCloud リスク

Bedrock を選ぶなら、設定、認証、欠ける機能、GovCloud 境界を正確に理解しておく必要があります。

5.1 amazon-bedrock provider の設定

Codex 設定ファイルで provider をこう指定します。

{
  "provider": "amazon-bedrock",
  "aws_region": "us-east-1",
  "model_id": "openai.gpt-5.5"
}

model ID と region は、必ず公式ドキュメントに合わせます。

5.2 AWS-native auth

Bedrock 経路は AWS-native authentication を使い、OPENAI_API_KEY は使いません。

• Bedrock API key: 期限付き、最大 12 時間または session duration、IAM principal permissions を継承
• AWS IAM credentials: IAM role または IAM user で設定

本番では短命 key か IAM role を使い、長命 key は試験用途にとどめます。

5.3 サポートされる commercial AWS Regions

公式ドキュメントでは、現時点で次の commercial AWS Regions が対象です。

• us-east-1
• us-west-2
• eu-west-1
• ap-northeast-1

最新一覧は AWS Bedrock OpenAI models のドキュメントを確認してください。

5.4 Bedrock API key の管理

Bedrock の key 管理は次の通りです。

• Short-term key: 最大 12 時間または session duration、IAM principal permissions を継承、本番向き
• Long-term key: 試験用途のみ、本番向きではない
• CloudTrail logging: API calls は AWS CloudTrail に記録される。key そのものは平文では残らない
• IAM actions control: API key の作成と利用は IAM actions で制御できる

5.5 機能不足の再掲

2026-06-08 時点で Bedrock では次が使えません。

• Fast Mode
• hosted web/file search
• computer use
• shell tool
• image generation tool
• remote MCP servers
• on-demand inference only は不可。Provisioned Throughput を使う

必要機能があるなら、ChatGPT workspace か API Key に戻します。

5.6 GovCloud リスクの再掲

もう一度分けて書きます。

• AWS GPT-5.4 は GovCloud (US-West) で利用可能
• Codex Bedrock provider は GovCloud endpoints をサポートしていない

GovCloud が必要なチームは、今日の時点で Codex を Bedrock に向けられるとは考えないでください。

6. ガバナンスと監査: usage と compliance logs はどこで見るか

管理者は adoption、usage、code review の効果を追跡したいはずです。そのために analytics と audit の出力が必要です。

6.1 3 つのガバナンス経路の比較

経路	機能	遅延	向いている用途
Analytics Dashboard	adoption、usage、code review feedback	最大 12 時間程度遅れることがある	展開の追跡
Analytics API	daily/weekly buckets、workspace/per-user usage、per-client breakdown、Code Review metrics	数分〜数時間	コスト管理と深い分析
Compliance API	Codex activity と audit metadata の出力	SIEM/eDiscovery 連携に依存	コンプライアンス監査

6.2 利用シナリオ

6.2.1 展開追跡

Analytics Dashboard でチームの adoption と usage を見ます。

• メンバーの有効化率
• code review feedback の質
• クライアント別の利用分布

Dashboard のデータは最大 12 時間遅れることがあるので、リアルタイム監視より週次・月次向きです。

6.2.2 コスト管理

Analytics API で深く分析します。

• workspace / user / model 別に利用量を分解
• daily / weekly buckets を比較
• Codex App / CLI / IDE / Cloud 別に分布を見る
• Code Review 指標を集計する

これは社内のコスト管理や最適化に向いた経路です。

6.2.3 コンプライアンス監査

Compliance API で audit logs を出力します。

• Codex activity records
• audit metadata
• SIEM / eDiscovery 連携
• 監査レビューの支援

金融、行政、医療などの規制業種に向いた経路です。

6.3 ガバナンス経路の推奨

• Analytics Dashboard: チーム展開を追う技術責任者や PM に向く
• Analytics API: コスト管理や深い分析をする platform engineer に向く
• Compliance API: SIEM や eDiscovery を扱うセキュリティ・法務向け

3 つは組織に応じて組み合わせられます。

7. チーム展開の進め方: 個人試用から組織ガバナンスへ

どこから始めるか、どう段階を分けるか、最初の試行タスクをどう選ぶか。ここで迷うチームは多いです。

7.1 3 段階の進め方

ステージ 1: 個人管理 (権限境界を決める)

目的: 各メンバーの権限境界を管理可能にし、機密ファイルをローカルへ散らさないこと。

主なアクション:

• danger-full-access + approval_policy = "never" をチームのデフォルトにしない
• .env と secrets/ を deny glob で守る
• :workspace_roots で作業範囲を制限する

成功条件: 承認なしで機密ファイルに触れないこと。

ステージ 2: 小チーム試行 (共有ルール + 低リスク作業)

目的: 小チーム内で AGENTS.md と skill を統一し、低リスク作業から動作確認を始めること。

主なアクション:

• global AGENTS.md を書く (スタイル、テスト期待値)
• project AGENTS.md を書く (アーキテクチャ、依存、デプロイ)
• docs 生成、lint 修正、テスト追加など低リスク作業を選ぶ
• 本番デプロイや支払いロジックの自動化は避ける

成功条件: 多くのメンバーが共有 AGENTS.md を使い、重大な安全事故が起きないこと。

ステージ 3: 組織ガバナンス (managed requirements + Analytics/Compliance API)

目的: 権限とルールを組織レベルへ上げ、観測と監査をつなぐこと。

主なアクション:

• user group ごとに cloud-managed requirements を設定
• Analytics Dashboard/API で adoption と usage を追跡
• Compliance API を SIEM に接続
• permission profiles と MCP allowlists を定期確認

成功条件: ガバナンスの可視化が動き、audit logs を追えること。

7.2 試行タスクのおすすめ

まずは低リスク作業

最初の試行に向くタスク:

• README、API docs、ノート整形などの document generation
• eslint / prettier / formatting の lint 修正
• unit test / integration test の追加
• コード構造の改善提案 (人間の review 前提)

直接自動化は避ける

最初の試行に向かないタスク:

• production deployment
• payment logic
• permission changes
• data deletion

これらは高リスクなので、ガバナンスと監査が成熟するまで待ちます。

7.3 シリーズ内での位置づけ

この一篇はチーム導入の判断ページです。続きで深掘りできます。

• AGENTS.md の書き方: 階層ルール、打ち切り回避、保守方法
• 個人の詰まりと sandbox: 権限問題、sandbox 設定、よくある失敗
• Cloud / GitHub 連携: リモート開発、GitHub review、cloud task
• コストと quota 最適化: token 削減と予算管理
• automation と長時間タスク: scheduled triggers、heartbeat、跨日ジョブ

まとめと次の一手

チームで Codex を導入する技術責任者なら、順番はこうです。

1. まず権限設定を読む (1章と 2章) ことで危険な組み合わせを止める
2. 次に運用ルールを統一 (3章) して AGENTS.md の形を揃える
3. そのあと導入経路を選ぶ (4章と 5章) ことで workspace、API Key、Bedrock を切り分ける
4. 最後にガバナンスへ接続 (6章) して Analytics と Compliance API を使う

そこから先は、個別のモジュールへ進めます。

• AGENTS.md の書き方: 階層ルール、打ち切り回避、保守方法
• 個人の詰まりと sandbox: 権限問題、sandbox 設定、よくある失敗
• Cloud / GitHub 連携: リモート開発、GitHub review、cloud task
• コストと quota 最適化: token 削減と予算管理
• automation と長時間タスク: scheduled triggers、heartbeat、跨日ジョブ

関連する基礎:

• チーム Git 協業の基礎: Git flow、branch 戦略、code review の流れ
• CI secrets と権限安全: GitHub Actions secrets、権限境界、安全運用