Claude CodeとCodexのセキュリティ｜情シスに渡せる運用標準

Claude CodeとCodexをチームで安全に使うには、「管理者が中央で固定する設定」と「現場で確認する運用」を分けて設計するのが実務的です。両者ともに「許可制」「サンドボックス」「監査ログ」の3点が統制の柱で、加えてMCPは「便利な拡張」ではなく「ガバナンス境界」として扱うのが原則。Claude Codeはmanaged settingsで個人設定からの上書きを禁止でき、Codexはmanaged requirementsで承認ポリシー・サンドボックス・MCP有効化を組織側から強制できます。本記事では、情シスがそのまま社内に展開できる5項目チェックリストと、それを月次でリフレッシュするためのSnorbe活用ループを紹介します。

AIコーディングエージェントのセキュリティが今ホットな理由
セキュリティの3つの基本ルール：許可・サンドボックス・監査
Claude Codeを安全に使うための設定ひな形
Codexを安全に使うための設定ひな形
情シスに渡せる運用標準と、Snorbeで続ける月次アップデート
よくある質問（FAQ）
調査手法について

AIコーディングエージェントのセキュリティが今ホットな理由

AIコーディングエージェントが書く・実行する・通信する3つの動きを表したイラスト

ここ1〜2年で、Claude CodeやCodexのような「AIコーディングエージェント」が一気に普及しました。コードを書くだけでなく、ファイルを開いて編集し、ターミナルでコマンドを実行し、ネットに繋いで情報を取りに行きます。便利さの裏で、「もしAIが間違った判断をしたら、パソコンの中で勝手にいろいろやってしまうのでは？」という不安が大きくなっています。

たとえば、Claude Codeは自分でテストを走らせたりGitHubにPull Requestを出したりできますし、Codexは作業ディレクトリ内でファイルを編集してコマンドを動かすのが既定動作です。Anthropicの公式ドキュメントでは、Claude Codeのセキュリティの考え方として「承認前にすべての提案された変更を確認」「MCPサーバー用にパーミッションを設定」「すべての操作はログされる」という三点セットが明示されています。OpenAIのCodex公式ドキュメントも、ローカルではOS強制のサンドボックスで実行範囲を限定し、必要に応じて承認を求める設計だと書かれています。

つまり、両者ともに「便利さと安全のバランスをユーザー側の運用で取ってください」というスタンスなのですね。ここが情シスの頭を悩ませている根っこです。

「承認プロンプトを93%通している」というリアル

衝撃的なデータがあります。RedditのClaudeCodeコミュニティで話題になった「Claude Code users approve 93% of permission prompts」というスレッドでは、ユーザーがほぼ脊髄反射で承認ボタンを押している現実が指摘されています。安全装置として作られた承認プロンプトが、人間側で「形だけのチェック」になっているわけです。

これは「許可疲れ（consent fatigue）」と呼ばれる現象で、AIエージェントに限らずどんなセキュリティ機構でも起きる人間側の弱点です。承認プロンプトを増やせば増やすほど、ユーザーは確認をやめます。だから「プロンプトを増やせば安全」ではなく、「危ないものだけ止めて、安全なものは黙って通す」という設計が必要になります。

AIが書いたコードが、必ずしも安全とは限らない

もうひとつ知っておきたいのが、AIが生成するコード自体の品質です。セキュリティ専門のDryRun Securityがおこなった検証では、Claude Codeで書いたコードのセキュリティ評価が思わしくなかった事例も報告されています。Claude Code vs Codex: The Real Comparisonなどの比較記事でも、ツールが賢いことと、生成物が安全であることは別の話だと整理されています。

つまり、AIエージェントを安全に使うには、二つの軸を分けて考える必要があります。

AIエージェント自体が「どこまで動けるか」を制限する（実行時の統制）
AIエージェントが「何を書いたか」を後からチェックする（成果物のレビュー）

どちらか一方だけでは安全になりません。本記事では、まず1の「実行時の統制」を整えるための運用標準を中心に扱います。

「禁止」でも「野放し」でもない第三の道

社内でAIコーディングエージェントを扱うとき、よくある反応は二極化します。

禁止派：「危ないから全社的に使うな」と通達する
野放し派：「個人の責任で使ってくれ」と現場任せにする

どちらも長続きしません。禁止しても、現場のエンジニアは個人PCでこっそり使うようになります。野放しにすると、社内コードや顧客データがAI側のクラウドに流れてしまうリスクが出ます。情シスが本当に欲しいのは、第三の道「中央で安全な既定値を固定し、現場が安心して使える状態」です。

この第三の道は、Claude Codeのmanaged settingsとCodexのmanaged requirementsという機能でちゃんとサポートされています。次の章から、その中身を順番に見ていきましょう。

たとえばあなたの会社が、今まさに「うちもClaude CodeかCodexを使うかどうか検討中」というフェーズにいるとしたら、最初に押さえるべきは「禁止か許可か」ではなく、「許可した場合に何を中央で固定するか」です。ここの設計図さえできれば、導入のハードルはぐっと下がります。

セキュリティの3つの基本ルール：許可・サンドボックス・監査

Claude CodeとCodexの公式ドキュメントを並べて読むと、面白いことに気づきます。両者ともに、セキュリティ統制の柱が「許可」「サンドボックス」「監査」の3つに集約されているのです。設定ファイルの形は違っても、考え方は驚くほど似ています。

ここでは中学生に説明するつもりで、それぞれを身近な比喩で見ていきます。

ルール1：許可制（approval）— 「やっていい？」と聞く仕組み

許可制は、AIエージェントが大事な操作をする前に必ず人間に「これやっていいですか？」と確認する仕組みです。学校でいうと、図書室で本を借りるときに先生のハンコをもらうイメージに近いです。

Claude Codeでは、Bash（ターミナルコマンド）の実行や、作業フォルダの外にあるファイルへの書き込みを、既定で承認待ちにできます。Claude Codeのセキュリティドキュメントでは「承認が必要」という表現で、危険な操作前に必ずユーザーの確認を取る挙動が説明されています。

Codexでは、approval_policyという設定で、never（聞かない）／on-request（必要なときだけ聞く）／on-failure（失敗したときだけ聞く）／untrusted（信頼できないものは全部聞く）の4段階を選べます。Codexの承認とセキュリティドキュメントでは、on-requestが推奨される既定の組み合わせとして紹介されています。

ここでのポイントは、許可制は強くしすぎると「許可疲れ」を生む、ということです。前章で触れた「93%のプロンプトを通している」問題ですね。じゃあどうするか。答えは次のサンドボックスにあります。

ルール2：サンドボックス（sandbox）— 「ここまでなら自由に遊んでいいよ」と決める仕組み

サンドボックスは、英語で「砂場」という意味です。公園の砂場って、その中なら子どもが自由に山を作ったり穴を掘ったりできますが、砂場の外に砂を撒いたら怒られますよね。あの境界線そのものです。

Codexのサンドボックスは、OSが強制する仕組みで、3つのモードがあります。

モード	できること	おすすめ用途
`read-only`	読み取りだけ	既存コードの調査・レビュー
`workspace-write`	作業フォルダ内なら書き込み・コマンド実行OK、ネットはオフ	日常の開発作業（既定）
`danger-full-access`	何でもできる	信頼できる隔離環境でのみ

Codexのサンドボックスドキュメントでは、サンドボックスは「Codexに自律的に動いてもらいながら、被害範囲を限定するための境界線」として説明されています。要するに、許可制でいちいち聞かれなくて済むように、最初から「この砂場の中なら好きにしていいよ」と範囲を決めておく仕組みです。

Claude Codeはサンドボックスという名前の機能こそ前面に出していませんが、permissions.allow / permissions.denyの組み合わせと、devcontainer（開発用コンテナ）の利用を推奨することで、同じ目的を達成しています。コンテナはまさに「OSごと隔離した砂場」なので、Claude Codeを動かす最も保守的な構成のひとつです。

許可制とサンドボックスは、組み合わせて使うのがコツです。サンドボックスで広めに自由を許し、サンドボックスを超える操作だけ許可制で止める。これが「許可疲れを起こさない設計」の基本です。

ルール3：監査ログ（audit log）— 「誰が何をしたか」を残す仕組み

監査ログは、エージェントが実行したコマンド・ツール呼び出し・承認結果などを、後から確認できる形で記録する仕組みです。学校でいうと、職員室の貸出ノートに「誰が何を借りたか」を書いておくのと同じです。何かトラブルが起きたとき、誰のどの操作が原因だったかを追えるようにしておきます。

Claude CodeはOpenTelemetry（OTelと呼ばれる業界標準のテレメトリ規格）に対応していて、CLAUDE_CODE_ENABLE_TELEMETRY=1を設定するとメトリクスとイベントを社内の監視基盤に流せます。Codexも同じくOpenTelemetryでログをエクスポートでき、加えてCompliance API経由でChatGPT Enterprise/Business契約のワークスペース全体のCodex利用ログを取得できます。

「監査ログがあるからといって、リアルタイムで全部見るわけではない」という点は実務上大事です。普段は溜めておいて、問題が起きたときに遡る。あるいは月次レビューで「想定外の操作はなかったか」を確認する。これが現実的な使い方です。

MCPサーバーは「便利な拡張」ではなく「ガバナンス境界」

3つの基本ルールに加えて、もうひとつ重要な概念があります。MCP（Model Context Protocol）です。

MCPは、AIエージェントに「外部ツールへの繋ぎ口」を提供する仕組みで、GitHubと連携したり、社内データベースを読みに行ったり、Slackに通知したりできるようになります。便利なのですが、便利さの分だけ攻撃面（attack surface）も増えます。

Claude Codeのセキュリティドキュメントでは、Anthropicは利用可能なMCPサーバーのリスト掲載基準を持っているものの、セキュリティ監査や管理はおこなわないと明記されています。つまり「使うかどうか、何を許すかは、運用側の責任」ということです。

Codexの公式MCPドキュメントも、MCPサーバーごとにinstructionsを書いて、サーバー全体に共通する制約やレート制限をエージェントに伝えられる設計になっています。MCPは便利な拡張ではなく、ガバナンス境界として扱う、というのが両者共通の前提です。

ここまでの「許可・サンドボックス・監査・MCP境界」の4点を押さえると、次の章からの具体的な設定ファイルが「何を実現したくて書かれているのか」が見えてくるはずです。さて、まずClaude Codeから具体的なひな形を見ていきましょう。

Claude Codeを安全に使うための設定ひな形

Claude Codeの設定は、4つの階層に分かれています。一番上の「Managed」というレイヤが、情シスが配るものです。ここで決めたことは、下のレイヤ（プロジェクト、ユーザー、ローカル）からは緩められません。これが情シス的に「ありがたい」ポイントですね。

まずは設定階層を頭に入れる

Claude Codeの設定ドキュメントによると、設定の優先順位は次のとおりです。

レイヤ	置き場所	誰が設定するか	gitに入れるか
Managed	システム設定ディレクトリ配下の`claude-code/managed-settings.json`（Linuxなら`/etc`配下、macOSとWindowsはそれぞれ別パス）	情シス・IT部門	いいえ（IT展開）
Project	リポジトリ内の`.claude/settings.json`	プロジェクト管理者	はい（チーム共有）
User	`~/.claude/settings.json`	開発者個人	いいえ
Local	リポジトリ内の`.claude/settings.local.json`	開発者個人（このリポだけ）	いいえ（gitignore）

Managedレイヤで決めたことは、UserやLocalでは上書きできません。たとえば情シスが「.envファイルの読み取りは禁止」とManagedで設定すれば、開発者がローカルで「いや、自分は読みたい」と言っても無視されます。

最小ひな形（managed-settings.json）

ここからは、情シスが最初に置くべき最小限の設定ひな形を見ていきます。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Bash(git status)",
      "Bash(git diff *)"
    ],
    "deny": [
      "Bash(curl ...)",
      "Bash(wget ...)",
      "Bash(rm -fr ...)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Write(./.env*)"
    ]
  },
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "https://otel-collector.example.com"
  },
  "allowedMcpServers": [
    {"serverName": "github"}
  ],
  "deniedMcpServers": [
    {"serverName": "filesystem"}
  ],
  "allowManagedMcpServersOnly": true,
  "allowManagedHooksOnly": true,
  "disableAllHooks": false
}

各設定の意味を、表で整理します。

設定	何をしているか	なぜ重要か
`permissions.allow`	自動承認するBashコマンドのリスト	許可疲れを起こさず、安全なものは黙って通す
`permissions.deny`	必ず拒否するコマンド・ファイル	機密情報や破壊的コマンドを最初から止める
`CLAUDE_CODE_ENABLE_TELEMETRY`	監査ログをOpenTelemetryで送る	監査ログの起点
`allowedMcpServers`	利用を許可するMCPサーバー	MCPの審査制を担保
`allowManagedMcpServersOnly`	Managed側の許可リストだけを有効に	ユーザーが勝手にMCPを足せなくする
`allowManagedHooksOnly`	Managed側で配ったhooksだけ動かす	hooksの抜け穴を塞ぐ

allowManagedMcpServersOnlyとallowManagedHooksOnlyは、Claude Codeの設定ドキュメントでManaged設定でのみ有効になる項目として明示されています。情シスが「個人による拡張を一切認めない」スタンスを取りたいときに使います。

hooksでガードレールを足す

Claude Codeにはhooksという仕組みがあり、特定のイベント（Bashを実行する前、ツールを呼ぶ前、ユーザーがプロンプトを送った直後など）でスクリプトを差し込めます。Claude Codeのhooksリファレンスを見ると、PreToolUse PermissionRequest PostToolUse SessionStartなど、ライフサイクル全体にフックポイントが用意されているのが分かります。

たとえば「Bashコマンドの中にAWSアクセスキーの先頭4文字パターンが含まれていたら拒否」というhookを書いておけば、AIエージェントがうっかり認証情報を環境変数として渡そうとしたときに止められます。これは社内の固有事情を取り込むうえで強力な手段です。

dev containerに焼き込むパターン

もうひとつおすすめのパターンが、dev containerにmanaged-settings.jsonを焼き込む構成です。

RUN mkdir -p ${SYSTEM_CONFIG_DIR}/claude-code
COPY managed-settings.json ${SYSTEM_CONFIG_DIR}/claude-code/managed-settings.json
# ${SYSTEM_CONFIG_DIR} は Linux なら /etc に相当

このようにDockerイメージに含めておけば、開発者がコンテナを起動するたびに同じ設定で開きます。OSごと隔離されているうえに、設定も中央で固定できるので、もっとも保守的な構成のひとつです。

エンタープライズではプロキシ・CA・mTLSも

大企業の場合は、ネットワーク経路の制御も必要になります。Claude Codeのエンタープライズネットワーク設定ドキュメントでは、HTTPSプロキシの指定、社内CA証明書の登録、mTLS認証までサポートされています。

export HTTPS_PROXY=https://proxy.example.com:8080
export NODE_EXTRA_CA_CERTS=/path/to/ca-cert.pem
export CLAUDE_CODE_CLIENT_CERT=/path/to/client-cert.pem
export CLAUDE_CODE_CLIENT_KEY=/path/to/client-key.pem

加えて、api.anthropic.com claude.ai platform.claude.com などの宛先をファイアウォール側で許可リストに入れる必要があります。デプロイ環境がAmazon Bedrock、Microsoft Foundry、Google Vertex AIの場合は、また別の宛先が必要なのでエンタープライズデプロイメント概要を確認してください。

ここまでで、Claude Codeの最小設定ひな形は揃いました。次はCodex側を見ていきます。考え方は似ていますが、ファイル形式とパラメータ名がだいぶ違うので、別物として整理するのがおすすめです。

Codexを安全に使うための設定ひな形

Codexの設定はTOML形式で、~/.codex/config.toml（ユーザー設定）と.codex/config.toml（プロジェクト設定、信頼されたプロジェクトのみ）に書きます。組織として強制する設定は別にrequirements.tomlという形で、admin-enforced（管理者強制）レイヤから配布できます。

Codexの最大の特徴は、サンドボックスと承認ポリシーが標準で「保守的な既定値」を持っているところです。何も設定しなくても、書き込みは作業フォルダ内だけ、ネットワークはオフ、承認は必要なときだけ聞く、という構成になっています。

サンドボックスと承認の組み合わせを理解する

Codexの承認とセキュリティドキュメントから引用すると、Codexの実行モードは大きく3つの組み合わせで整理できます。

プリセット	サンドボックス	承認	用途
Read Only	`read-only`	`on-request`	既存コードの調査・レビュー
Auto（既定）	`workspace-write`	`on-request`	日常の開発作業
Full Access	`danger-full-access`	`never`	信頼できる隔離環境のみ

workspace-writeの既定では、Codexは作業ディレクトリ内で読み書きとコマンド実行ができますが、ネットワークアクセスはオフです。ネットを使いたいときは別途有効化が必要で、しかも承認を求められます。

Codexアプリ・CLI・IDE拡張のすべてでこのモデルが共通しています。コマンドラインから明示的に切り替えるなら、こんな感じです。

# 既定（読み書きOK、ネットオフ、必要時のみ承認）
codex --sandbox workspace-write --ask-for-approval on-request

# 完全な読み取り専用モード
codex --sandbox read-only --ask-for-approval on-request

# 危険：何でもできるモード（基本的に使わない）
codex --sandbox danger-full-access

最小ひな形（~/.codex/config.toml）

ユーザー個人の設定として配るひな形です。

# ~/.codex/config.toml
model = "gpt-5.1-codex"
approval_policy = "on-request"
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = false

[mcp_servers.github]
url = "https://api.githubcopilot.com/mcp/"
http_headers = { Authorization = "Bearer ${GITHUB_PAT}" }

# OpenTelemetryで監査ログを送る
[otel]
enabled = true
endpoint = "https://otel-collector.example.com"

Codexの設定リファレンスでは、sandbox_modeの有効値、approval_policyの取りうる値、[mcp_servers]の書き方が一覧で示されています。

組織として強制する：requirements.toml

個人設定を書き換えられないように組織側から固定したいなら、requirements.tomlを使います。Codexの管理設定（Managed configuration）ドキュメントでは、approval_policy sandbox_mode permission profiles web search mode managed hooks などのセキュリティ重要設定をrequirementsで制約できると説明されています。

# requirements.toml（admin-enforced）
[approval_policy]
default = "on-request"
allow_override = false

[sandbox_mode]
default = "workspace-write"
allow_override = false

[mcp]
allowed_servers = ["github", "internal-jira"]
allow_user_additions = false

[experimental_network]
managed_allowed_domains_only = true
allowed_domains = [
  "github.com",
  "api.github.com",
  "registry.npmjs.org"
]

[features]
allow_managed_hooks_only = true

allow_managed_hooks_only = trueにしておくと、ユーザーやプロジェクトのhooksは無視され、管理者が配ったhooksだけが動きます。managed_allowed_domains_only = trueは、ユーザーがネットワークallowlistに勝手にドメインを足すのを禁止する設定です。

ChatGPT Business/Enterpriseでサインインしている場合、Codexはサインイン時にCodexサービスから管理者強制の要件を取得します。管理者はCodex設定画面で、ユーザーグループごとに異なる要件を割り当てることもできます。

コマンド単位の例外は.rulesで

「基本は禁止だが、この特定のコマンドだけはサンドボックス外で実行を許したい」というケースは現場でよく出ます。CodexはそのためにRulesという仕組みを用意しています。

# ~/.codex/rules/default.rules
# `gh pr view`の前でだけ確認する
[[rule]]
pattern = "gh pr view"
action = "prompt"

.rulesファイルで、コマンドごとに「prompt（確認）」「allow（自動許可）」「deny（拒否）」を書けます。ユーザーがTUI内でコマンドを許可リストに足すと、Codexは~/.codex/rules/default.rulesに書き込み、次回以降は確認をスキップする挙動になります。

監査ログ：OpenTelemetryとCompliance API

Codexの監査は2系統あります。

OpenTelemetry：Advanced Configurationで、APIリクエスト、SSEイベント、プロンプト、ツール承認・結果のテレメトリをエクスポートできます。codex.api_request codex.api_request.duration_msなどのメトリクスが標準で出ます。
Compliance API：Codexエンタープライズガバナンスで、ChatGPT Business/Enterpriseワークスペース単位の利用ログを引き出せます。SIEMへの集約用です。

両方を組み合わせれば、ローカルの実行詳細とクラウド側の利用統計の両面が押さえられます。

Codexクラウドでネットを使う場合

Codex Webのエージェントインターネットアクセスでは、既定でエージェント実行時はネットがブロックされていて、必要なドメインだけallowlistに加える設計です。プロンプトインジェクション（外部の文章にAIへの命令が紛れ込んで意図しない動作を引き起こす攻撃）を減らすため、信頼できるリソースだけに範囲を絞るのが推奨されています。

Codexの設計思想は「制限から始めて、必要に応じて広げる」です。Claude Codeの「許可・拒否を明示的に列挙する」スタイルとは方向性が違いますが、たどり着くゴール（最小権限・例外明示・監査）は同じです。

ここまでで、2製品それぞれの最小ひな形が揃いました。最後の章では、これらを統合して「情シスにそのまま渡せるチェックリスト」と、それを古びさせないための運用ループにまとめます。

情シスに渡せる運用標準と、Snorbeで続ける月次アップデート

ここまでで、Claude CodeとCodexそれぞれの基本ルールと最小ひな形が揃いました。あとは情シスがそのまま使えるチェックリスト形式に落とすだけです。

情シスに渡せる5項目チェックリスト

社内通達やセキュリティ規程の付属資料として、そのままコピーできる粒度で整理しました。

#	項目	Claude Code側で確認すること	Codex側で確認すること
1	管理設定が固定されているか	システム設定ディレクトリ配下の`managed-settings.json`が配布済み。`allowManagedMcpServersOnly`と`allowManagedHooksOnly`がtrue	`requirements.toml`が配布済み。`allow_override = false`で個人設定の上書きを禁止
2	許可リストが定義されているか	`permissions.allow`に自動承認するBashコマンドが列挙されている。`permissions.deny`に`.env`系・破壊的コマンドが入っている	`sandbox_mode = "workspace-write"`+ `network_access = false`が既定。allowlistドメインが明示
3	MCPが審査制になっているか	`allowedMcpServers`に許可リスト。`deniedMcpServers`に明示的拒否	`[mcp_servers.<name>]`で許可リスト。`allow_user_additions = false`
4	監査ログが取れているか	`CLAUDE_CODE_ENABLE_TELEMETRY=1`でOTel出力。社内SIEMに集約	`[otel]`でOTel出力＋Compliance API（Business/Enterprise）でクラウド側ログ
5	承認フローが明文化されているか	承認の責任者（プロジェクトリードか情シスか）が決まっている。例外申請のフォームがある	`approval_policy = "on-request"`が既定。`.rules`での例外は申請ベース

このチェックリストは、社内導入申請書のテンプレートにそのまま転記して使えます。

例外申請は「期限付き・責任者付き・理由付き」の3点セットで

運用標準を作っても、必ず例外申請は出ます。たとえば「特定のリポジトリでだけdanger-full-accessを使いたい」「このMCPサーバーだけ追加で許可してほしい」というケースです。

例外を野放しにすると、運用標準そのものが形骸化します。最低限、以下の3点を申請フォームに含めるのがおすすめです。

期限：いつまで例外を有効にするか（無期限はNG）
責任者：誰がその例外の安全性を保証するか（個人名）
理由：何のために必要か（プロジェクト名と用途）

期限が来たら自動で例外が切れる仕組みにしておけば、棚卸し作業の負荷も減ります。

公式Docsは「月単位で変わる」前提に立つ

ここからが、運用標準を作った後に必ず直面する現実の話です。

Claude CodeもCodexも、公式ドキュメントは月単位で項目が追加・改名されます。実例として、AnthropicはClaude Code向けに2026年にRoutines（スケジュール実行や外部トリガー）を、OpenAIはgpt-5.1-codex系のモデルやCodex Security cloudをローリングで追加してきました。AGENTS.mdの標準化を進めるAgentic AI Foundationの動きもあり、複数のツールが共通の指示ファイルを読む方向性が固まりつつあります。

つまり、せっかく作った社内標準も、3ヶ月後には参照しているドキュメント構造が変わっています。allow_managed_hooks_onlyのような新しい設定キーが出てきたら、それを社内標準に組み込むかどうか判断する必要があります。

ここを人手で追うのはかなり大変です。月に1度、Anthropic・OpenAI・GitHub Copilot・Cursor・Gemini CLIのドキュメントを横断して差分を取って、社内チェックリストに反映する。1人月では足りないレベルの労力です。

Snorbeで「公式Docs月次ウォッチ」のループを回す

ここで自社サービスの宣伝になりますが、Snorbeは専門領域のDeep Researchプラットフォームとして、こういう「公式Docsの継続ウォッチ」を回すのに向いています。

具体的なループは次のようなイメージです。

月初に Snorbe で Deep Research を起動 「Claude Code・Codex・GitHub Copilot CLI のセキュリティ関連ドキュメントで、先月から変わった項目を全部洗い出して」とリクエスト。完全記憶型ナレッジグラフが、前回の確認時点との差分を出してくれます。
差分を社内チェックリストと突き合わせる 新しい設定キー、デフォルト値の変更、廃止された項目を、今の社内標準と並べて表示。「対応が必要」「現状維持でOK」「議論が必要」に分類します。
判断はチームで議論し、結論を Snorbe のナレッジグラフに保存 「なぜこの設定を採用しなかったか」「なぜこの例外を認めたか」といった意思決定の経緯を、自然な日本語で残しておきます。これが次回更新時の判断材料になります。
必要なら社内チェックリストを更新し、informingでチーム配布 配布形式は、JSON/TOMLテンプレート＋PDFガイドの2本立てがおすすめです。

Snorbeのポイントは、検索キーワードを意識しなくても自然な日本語で問いを投げられること、そしてJPO・EPO・Google Patents・arXiv・PubMed・Semantic Scholarなど専門DBに加えて、開発者向けドキュメントの定点観測にも使えることです。完全記憶型ナレッジグラフが、「過去の議論」と「今回の発見」を勝手に紐づけてくれるので、属人化しがちな運用ナレッジを組織に蓄積できます。

今後のトレンドと、情シスが押さえておくべき2点

最後に、今後1〜2年の見通しを短くまとめます。

指示ファイルの標準化が進む AGENTS.mdが事実上の共通指示ファイルになる流れで、Claude CodeのCLAUDE.mdと並んで「リポジトリにファイルを置くだけで複数ツールの挙動を制御できる」状況が広がります。情シス的には「ファイルベースの統制が効きやすくなる」のはプラスです。
エージェントの自律性は上がる方向、サンドボックスはより細かくなる Codexのworkspace-write+on-requestのような既定値は維持しつつ、ネットワークallowlistや承認の細粒度化が進みます。Claude Codeも、hooksとMCPの組み合わせで「許可疲れを起こさず細かく止める」方向の改善が続いています。
コードレビュー側のAI化 Codex Security cloudのようなコミット単位の脆弱性スキャンが標準機能化する流れです。「AIが書いたコードを別のAIがレビューする」が当たり前になるので、レビュー結果の取り扱いと監査ログ統合も視野に入れておきましょう。

情シスとしては、運用標準を「一度作って終わり」にせず、月次でリフレッシュする仕組みを併せて整えることが重要です。Snorbeのような専門Deep Researchプラットフォームと組み合わせれば、その月次ループの負荷をぐっと下げられます。

社内でClaude CodeやCodexを安全に使いたい、しかし運用標準を一から作る時間がない、というチームには、本記事のチェックリストと設定ひな形を出発点に、月次ウォッチをSnorbeで回す構成を試してみてはいかがでしょうか。月曜日からでも始められる範囲のところから、ぜひ。

よくある質問（FAQ）

Q1. Claude CodeとCodexのセキュリティ思想の違いは？

両者ともに「管理者が安全な既定値を固定する」方向性は一致していますが、実装の主軸が違います。Claude Codeは設定ファイル（managed-settings.json）とpermissions.allow / permissions.denyの組み合わせで、ファイルベースの明示的な統制が中心です。一方Codexは、サンドボックス（workspace-writeなど）と承認ポリシー（on-requestなど）を実行時に効かせる設計が前面に出ています。同じゴール（最小権限・例外明示・監査可能性）に違う道で到達する、と理解するのが分かりやすいです。

Q2. managed settingsとconfig.tomlは個人で上書きできますか？

Claude Codeのmanagedレイヤは、ユーザーやローカルレイヤから上書きできません。情シスが「ここは絶対固定」と決めたい設定はmanagedに置きます。Codexもrequirements.tomlでallow_override = falseを指定すれば、ユーザー個人のconfig.tomlからは緩められなくなります。ただしCodexのmanaged requirementsはChatGPT Business/Enterpriseプラン契約時に効果を発揮するので、契約形態を確認してください。

Q3. MCPサーバーは全部禁止しておくべきですか？

最初は全部禁止から始めるのが安全です。そのうえで、業務に必要なサーバー（GitHub、Jira、社内Wikiなど）を1つずつ審査して許可リストに加える運用がおすすめです。Claude CodeはallowedMcpServersとallowManagedMcpServersOnly: true、Codexは[mcp_servers.<name>]とallow_user_additions = falseを組み合わせると、ユーザーが勝手にMCPサーバーを追加できなくなります。

Q4. 承認プロンプトを通しすぎる「許可疲れ」の対処法は？

承認プロンプトを増やすほどユーザーは確認をやめるため、「危ないものだけ止めて、安全なものは黙って通す」設計が基本です。Claude Codeならpermissions.allowに日常使うコマンド（npm run test *など）を列挙して自動承認に。Codexならサンドボックスをworkspace-writeで広めに許し、ネットワークアクセスや作業ディレクトリ外への書き込みだけ承認を求める構成にします。プロンプトの「数」より「質」を上げるのがコツです。

Q5. 監査ログは何を残せば十分ですか？

最低限、「誰が」「いつ」「どんなツールを呼んだか」「承認・拒否の結果はどうだったか」の4要素が必要です。Claude CodeとCodexはどちらもOpenTelemetryでこの情報を出力できるので、社内のSIEM（Splunk、Datadog、Elasticなど）に集約するのが標準的な構成です。Codex Business/Enterpriseの場合はCompliance APIでクラウド側の利用統計も取れます。リアルタイムで全部見るのではなく、月次レビューや問題発生時の遡及調査に使える状態にしておけば十分です。

Q6. 中小規模チームでもmanaged設定は必要ですか？

10人規模くらいまでなら、まずプロジェクト設定（.claude/settings.jsonや.codex/config.toml）をgit管理することから始めるのが現実的です。チーム全員が同じリポジトリで同じ設定を共有でき、レビュー履歴も追えます。組織が大きくなったり、複数プロジェクトで横串の統制が必要になったタイミングで、managed設定の導入を検討すれば十分です。

Q7. Codexのworkspace-writeとdanger-full-accessはどう使い分けますか？

workspace-writeが既定で、9割以上の日常作業はこれで足ります。作業フォルダ内で読み書きとコマンド実行ができ、ネットワークはオフ。一時的に外部APIを叩く必要があれば、その時だけ承認を求められる挙動になります。danger-full-accessは文字通り全権限を渡すモードで、原則として使わないのが推奨です。どうしても必要な場合は、Dockerコンテナや使い捨てのVMの中で、隔離された状態でのみ使うべきです。OpenAI公式もサンドボックス文書で「信頼できる隔離環境のみ」と明記しています。