「AIエージェントの権限は絞ってある」という説明を導入担当者から聞くとき、その中身を聞くと大抵は「そういうルールを決めた」という話であって、「開発者がそれを書き換えられないようにした」という話ではないことが多い。Claude Codeの公式ドキュメントは、この2つをはっきり別のレイヤーとして扱っている。決めたルールが、実際に開発者を縛れているかどうかは別問題だという整理を確認する。

全体像：4つの配布経路と、勝敗が決まる順番

Claude Codeには、組織のポリシーを開発者の手元に届ける経路が4つある。公式ドキュメントによると、優先順位はこの順で決まっている。

経路届け方対応プラットフォーム
サーバー管理設定claude.aiの管理コンソール、または自前のゲートウェイ全て（Team/Enterpriseプラン等が前提）
MDM／レジストリポリシーmacOSのプロファイル、WindowsのHKLMレジストリmacOS・Windows
ファイル配布（managed-settings.json）各マシンの決まったパスに直接配置全て
Windowsユーザーレジストリ（HKCU）昇格権限なしで書ける値Windowsのみ

上位の経路が1つでもポリシーを配っていれば、それより下の経路は無視される。そしてこの4つのどれかで設定した値は、開発者自身の設定ファイル・プロジェクト設定・--settingsオプションよりも常に優先される（一部のセキュリティ上の例外を除く）。つまり「管理設定で決めた」ものは、現場が勝手に緩めることができない。

管理設定で強制できる対象は、公式ドキュメントの一覧によると多岐にわたる。許可ルール（何を自動実行し何を確認制にするか）、--dangerously-skip-permissionsの無効化、サンドボックスのネットワーク・ファイルアクセス許可リスト、全社共通のCLAUDE.md、MCPサーバーの許可/拒否リスト、プラグイン導入元の制限、フックの実行制限、ログイン方法の強制、利用可能モデルの制限、バージョンの下限——といった項目が並ぶ。

公式ドキュメントはこの一覧のすぐ後に、なぜ複数の項目が要るのかも書いている。「WebFetchを拒否してもClaudeのfetchツールが止まるだけで、Bashが許可されていればcurlやwgetで同じ場所に到達できる。サンドボックスはそこを塞ぐ」。1つの設定を強くしても、別の経路が空いていれば同じ結果に届いてしまうという説明で、以前の記事で扱った「許可ルール・フック・サンドボックス・auto mode」という4つの壁の話と同じ構造がここにもある。

適用条件と例外——「強制」に見えて強制できていない3つの穴

サーバー管理設定はTeam/Enterpriseプランが前提。 claude.aiの管理コンソールから配る方式は契約プランに紐づく。Consoleでの従量課金やAmazon Bedrock等のクラウド経由で使っている組織は、自前のゲートウェイを用意するか、ファイル配布・MDMのどちらかで代替する必要がある。

ファイル配布は、マシンの管理者権限を握っている前提でしか機能しない。 公式ドキュメントは開発者にできることの例外として明記している。「マシンの管理者権限を持つ開発者は、管理設定そのものを編集できる」。つまりmanaged-settings.jsonを各マシンに置くだけでは、そのマシンの管理者権限を誰が持っているかまで決めていない限り、書いたルールは技術的に開発者の合意の上に乗っているだけになる。ここを見落として「ファイルを配ったから強制できている」と思い込むのが、最もありがちなすれ違いだと思う。

管理設定はClaude Code自体しか縛らない。 公式の注記に「開発者が別のツールからAPIを直接呼ぶ場合、その利用は管理設定の対象外」とある。Claude Codeの権限設計をどれだけ丁寧にやっても、社員が別の手段でAPIキーを直接使えば、そのやり取りは今回の話が守る範囲の外にある。

自社で判断する基準——「書いた指示」と「強制する仕組み」を分けて考える

中小企業の多くは、MDMで全端末を管理する体制も、Enterprise契約も持っていない。その場合、Claude Codeの管理設定を丸ごと導入するのは現実的ではないことが多い。それでも上記の整理は使える。自社が今持っている統制の手段を、次の2つのどちらかに仕分けてみることだ。

  1. 技術的に強制できるもの——共有サーバーで動かすなら、そのマシンの管理者権限を絞った上でファイル配布の管理設定を使う。個人のノートPCで完結する小規模な運用なら、少なくともサンドボックスとdenyルールで、消してはいけない操作・触られたくないファイルは機械的に塞いでおく。
  2. 書いた指示に頼るしかないもの——組織のリソースやツールの制約で技術的な強制まで手が回らない範囲は、指示として明文化した上で、結果を人が見る運用にする。

この2つ目に当てはまる実例が、このブログの運用そのものにある。この記事も含め、ブログの一部の記事は自動化されたエージェントが調査・執筆・公開までを担当しているが、「触ってよい範囲はこのプロジェクトのディレクトリだけ」「助成金・補助金を主題にした記事は、事実確認で問題がなくても人間のレビューを経るまでマージしない」というルールは、OSレベルのサンドボックスやmanaged-settingsのような技術的な壁ではなく、実行のたびに与えるタスクの指示として明文化してあるだけだ。指示は技術的な強制より弱い——エージェントが読み違える余地は理屈の上では残る。だからこそ「金額や期限を扱う話題」という、誤りが起きたときの影響が大きい一点だけは、指示を信頼して終わらせず、人間が見るまでは公開しないという別の仕組みを重ねてある。

自社のAIエージェント運用を点検するときも、同じ軸で確認するとよい。今ある制約は技術的に強制されているか、それとも書いて伝えているだけか。書いて伝えているだけの制約を、誰か(あるいはエージェント自身)が読み違えたとき、実際にどこまでの被害が起こり得るか。その被害が金銭・法務・対外的な信頼に関わるなら、指示だけで済まさず、人が結果を確認するまで先に進めない仕組みを別途置く——ここまで含めて初めて「権限設計」と呼べる。

自社のAIエージェント運用でどこまでを技術的に強制し、どこを人の確認で担保するか整理したい場合は、パイロット・構築のフェーズで一緒に設計できる。まずは30分の無料診断から相談してほしい。