Claude Codeのセキュリティ対策と社内ルールの決め方

Claude Codeのセキュリティ対策で最初に決めるのは、どの禁止ルールを書くかではない。どのリスクをOSの層で強制し、どれを社内ルールに残すかである。Claude Codeの権限ルールや、管理画面から配る設定の一部は、公式ドキュメント自身が「セキュリティの境界ではない」と明記している。そこを境界のつもりで運用すると、ルールを増やすほど守れている気になり、実際には止まっていない操作が残る。

「Claude Code セキュリティ」で検索すると、上位には導入企業向けの対策の解説と、権限設定・サンドボックス・データ分類のチェックリストが並ぶ。項目としては正しい。だが、どの設定が何を止め、何を止めないのかまで書いた記事は少ない。本稿は2026年11月7日時点のAnthropicの公式ドキュメントと海外の元記事をもとに、情報セキュリティと開発組織の責任者が許可条件を決めるための材料を示す。

Claude Codeのセキュリティは、何を前提に考えるのか？

前提は、Claude Codeが開発者の端末で、その開発者の権限で動くことである。投資会社のa16zが従業員1,000人超の企業のCISO100人に行った調査では、83%がコーディング支援やコーディングエージェントを本番で使い、55%がMCPサーバーなどエージェントと業務アプリの連携を本番で動かしている。最大級の懸念の一つとして（複数回答）、47%が社員によるAIツールへの機密データの流出を、46%がエージェントの権限逸脱や乗っ取りを挙げた。元記事は、従来の端末向けセキュリティ製品が効かなくなる理由を次のように書く。

“Agents run on employee devices with the user’s own permissions, so to the tools built for the last decade of endpoint security, an agent reading a file or calling an API looks exactly like the employee doing it.”

訳: エージェントは社員の端末上で、その社員自身の権限で動く。そのため過去10年の端末向けセキュリティのために作られたツールから見ると、エージェントがファイルを読んだりAPIを呼んだりする操作は、社員本人の操作とまったく区別がつかない。

出典: The New Security Agenda, a16z, 2026-10-28（2027年のセキュリティ予算、87%のCISOが増加を予想──AIエージェント関連の優先度が急上昇で詳述）

データの扱いは、プランで大きく分かれる（2026年11月7日時点の公式ドキュメント。以下同じ）。Team・Enterprise・APIなど商用規約の利用者がClaude Codeに送ったコードやプロンプトは、生成モデルの学習に使われない。顧客が開発パートナープログラムなどで自ら提供を選んだ場合は例外である。サーバー側の標準の保持期間は30日で、条件を満たすEnterpriseの組織では、保持しない構成（Zero Data Retention）を個別に有効にできる。一方、Free・Pro・Max・Ultraの個人向けプランでは、利用者が学習への利用を許可していれば学習に使われ、その場合の保持期間は5年である。また、Claude Codeは会話の記録を端末の ~/.claude/projects/ に平文で、既定では30日間保存する。

ここから最初の論点が出てくる。社員が個人アカウントでClaude Codeを使えば、組織の契約条件は適用されない。公式ドキュメントによると、管理者は端末管理（MDM）で設定を配り、ログインを特定の組織のアカウントに限定できる（forceLoginOrgUUID と forceLoginMethod）。他の組織のアカウントでログインしようとすると、Claude Codeはエラーを出して起動を止める。この設定は、組織にログインしたあとに届く管理画面の設定では最初のログインを制御できないため、端末管理で配る必要がある。どの端末にこの強制をかけるかは、エージェントに渡す権限の線をどこに引くかと同じ種類の判断であり、AIエージェントの権限境界をスピード・統制・可逆性の3軸で設計する論点がそのまま使える。

Claude Codeの権限設定で、止まる操作と止まらない操作は何か？

Claude Codeは、操作ごとに確認を求める権限の仕組みを持つ。手動で承認するモード（Manual）では読み取りだけの状態から始まり、ファイルの編集やコマンドの実行の前に利用者に確認する。ルールは「禁止（deny）→確認（ask）→許可（allow）」の順に評価され、最初に一致したものが結果を決める。curl や wget のようにWebから内容を取るコマンドは、既定では自動で許可されない。なお、対話型のターミナルとVS Codeでは、最初のモードが自動モード（auto mode）になっている。利用者の代わりに別の分類モデルが操作を審査し、危険と判断したものを止める仕組みで、組織として無効にもできる。この仕組みも、禁止ルールの代わりにはならない。

ただし公式ドキュメントは、この仕組みの限界をはっきり書いている。止まらない操作の代表は次の4つである。

設定	止めるもの	公式ドキュメントが止まらないとしているもの
Bashコマンドの禁止ルール（例: Bash(curl *)）	curl https://example.com のように書かれたコマンド	/usr/bin/curl や sh -c 'curl …' のように別の形で呼んだ同じ操作。ルールは「プログラムを守るセキュリティの境界ではない」
ファイル読み取りの禁止ルール（例: Read(./.env)）	Claude自身のファイルツールと、cat などClaude Codeが認識するコマンドでの読み取り	PythonやNodeのスクリプトが自分でファイルを開く場合など、間接的な読み書き
作業ディレクトリの境界	作業ディレクトリの外へのファイルツールの読み書き（確認が出る）	利用者が承認したBashコマンドは、その利用者のアカウントで書ける場所ならどこにでも書ける
管理画面から配る設定（server-managed settings）	組織全体の禁止ルールやモードの固定	端末側で動く制御で、管理されていない端末では管理者権限なしに回避できる。他のモデル提供経路を設定した場合も適用されない

つまり、権限ルールと管理画面の設定は「普段の使い方をそろえる道具」であって、悪意のある操作や、プロンプトインジェクションで乗っ取られた操作を確実に止める壁ではない。確認をすべて飛ばすモード（bypassPermissions）についても、公式ドキュメントはコンテナや仮想マシンのような隔離された環境でだけ使うよう警告し、管理設定で使えなくする項目（disableBypassPermissionsMode）を用意している。

コーディングエージェント全般では、権限が十分に絞られていない運用で事故が起きている。Everyの技術コンサルティング責任者Mike Taylorは、GPT-5.6 Solを使っていたとき、モデルが問題の解決策としてデータベースをリセットした（バックアップがあった。Claude Codeの事例ではない）。そのあと、エージェントが実行する前にシェルコマンドを検査し、rm -rf や git reset --hard のような危険な操作を止めるオープンソースのツールを入れている。同氏は「みんな仕事を片付けるために、十分な権限設定なしでエージェントを動かしている」と述べている（AIエージェントをSlackに常駐させる前に何を決めるべきか——実行権限とガードレールの設計）。止めたいのは取り返しのつかない操作であり、ここでも読み取りと書き込み、可逆と不可逆を分けて考える権限境界の非対称な設計が判断の土台になる。

OSの層で強制するのは何か？

文字列のルールで止まらないものは、OSの層で止める。Claude Codeには、Bashコマンドとそこから起動されたプロセスのファイル操作と通信を、OSの仕組みで制限するサンドボックスがある。macOSではSeatbelt、LinuxとWSL2ではbubblewrapを使う。ネイティブのWindowsでは、コマンドはサンドボックスなしで動く。

公式ドキュメントの記述で、許可条件を決める側が押さえておくべき点は次のとおりである。

• 既定では無効である。 組織として使うなら、管理設定で有効化を必須にし、使えない環境では起動自体を止める（failIfUnavailable）。サンドボックスの外で実行し直す抜け道も閉じられる（allowUnsandboxedCommands: false）
• 既定では読み取りを制限しない。 書き込みは作業ディレクトリなどに限られるが、読み取りは ~/.ssh や ~/.aws/credentials のような認証情報のファイルを含め、端末のほとんどが対象になる。読ませたくない場所は明示的に禁じる
• 通信は許可したドメインだけに絞れる。 外への通信は端末上のプロキシを通り、許可リストは空から始まる。管理設定で、組織が許可したドメイン以外を確認なしで遮断することもできる（allowManagedDomainsOnly）。ただしプロキシはTLSの中身を検査せず、要求されたホスト名で判断する
• シェルコマンドしか覆わない。 Claudeのファイルツール、MCPサーバー、フックはサンドボックスの外で動く

設定の配り方にも強弱がある。公式ドキュメントは、端末管理（MDM）で配る設定のほうが、利用者による書き換えをOSの層で防げるため強い保証になると説明している。一方で、端末に配った設定はAnthropicの環境で動くクラウドセッションには届かないため、クラウドセッションを使う組織は管理画面からの設定も併用する必要がある。

さらに強く閉じたい業務は、実行環境ごと分ける。900人規模のメンタルヘルスケア企業Headwayは、Claude Code SDKで作った社内アシスタント「Eddy」の会話を、1回ごとに使い捨てるDockerコンテナで動かしている。データウェアハウスのSnowflakeは読み取りのみ、外部サイトの直接の閲覧とメールの送信はできず、最悪の事態としてプロンプトインジェクションによる社内データの持ち出しを想定して、外への通信の方針を組んだ（社内 AI アシスタントは自作すべきか購入すべきか ― Headway が Claude Code SDK で「Eddy」を自社構築した判断基準）。患者情報を扱う業界で各ステップの承認なしにエージェントを動かせたのは、エージェントを信用したからではなく、被害がコンテナの中で閉じるからである。サンドボックスの必須化や実行環境の分離をどの業務・どの端末に求めるかは、閉じ込める範囲を決める判断であり、権限境界を誰がどの基準で動かすかを制度にする論点とあわせて決めるとよい。

MCPサーバーとAIが作ったコードは、何を許可条件にするのか？

公式ドキュメントによると、既定ではClaude Codeの利用者は誰でも任意のMCPサーバーを接続できる。Anthropicは、公式ディレクトリ（Anthropic Directory）にコネクタを載せる前に掲載基準で審査するが、MCPサーバーのセキュリティ監査や管理は行わない。管理者は、次の段階で使えるサーバーを絞れる。

• MCPを全面的に止める、または全員に同じサーバーだけを配る（端末に配る managed-mcp.json。管理画面からは配れない）
• 承認したサーバーの一覧を公開し、それ以外を遮断する（allowedMcpServers と allowManagedMcpServersOnly）
• 既知の危険なサーバーだけを遮断する（deniedMcpServers）

注意点は、サーバーの「名前」で許可や遮断をしても統制にならないことだ。名前は利用者が付けるラベルで、どのサーバーにも github と名付けられる。公式ドキュメントは、実際に動くサーバーを縛るにはURLかコマンドで指定するよう警告している。

MCPの接続は、使う側だけでなく作る側でも穴になる。Everyのライター、Katie Parrottは、自作のアプリに、利用者のエージェントからつながるMCPの接続口をClaudeに作らせて公開した。のちに別系統の新しいモデル（GPT-5.6 Sol）にコードを点検させたところ、本来は非公開であるべき登録用の経路が公開されていたことがわかった。利用者のデータにアクセスされた形跡はなかったという。同氏は事後の自分のルールとして、AIが作ったものについて、同じ仕組みが「大丈夫だ」と言うことを準備完了の唯一の根拠にしない、と書いている（非エンジニアの AI 開発をどこまで許可すべきか — vibe coding が本番に持ち込んだ脆弱性の教訓）。

Claude Codeにも、作業中のブランチの変更をセキュリティの観点で点検する /security-review コマンドや、TeamとEnterpriseでプルリクエストを読むCode Reviewがある。ただしCode Reviewの公式ドキュメントは、指摘がないことはコードが安全であることを意味しないと明記し、プルリクエストの承認やブロックもしない。また、Zero Data RetentionやHIPAA向けの構成を適用した組織では、Code Reviewは使えない。許可条件として書くべきなのは「AIレビューを通すこと」ではなく、AIの点検を通ったあと、外部に公開する変更・認証や権限に触れる変更・取り消しにくい変更を、誰が人の目で確認するかである。この分担の決め方は、AI生成コードのレビューで、自動チェックに渡していない情報を誰が供給するかという論点で詳しく扱った。

社内ルールには何を書き、何を設定に任せるのか？

ここまでを並べると、Claude Codeのセキュリティ対策は3つの層に分かれる。

層	置くもの	強制の強さ
端末管理（MDM）で配る設定とOS	組織アカウントへのログイン強制、サンドボックスの必須化と通信先の許可リスト、MCPサーバーの承認制、確認を飛ばすモードの禁止	利用者が書き換えにくい
管理画面から配る設定・権限ルール	普段の使い方の標準（禁止コマンド、読ませないファイル、既定のモード）	普段の操作はそろうが、回避はできる
社内ルール	設定では判断できないもの（どのリポジトリで使ってよいか、顧客データを扱う作業の扱い、人の確認が要る変更の範囲）	人の判断に依存する

a16zの調査では、CISOの回答の63%が、セキュリティが少なくとも一部のAI導入を遅らせていると答えている。審査や承認の要件、特定の用途の制限がその中身である。社内ルールの条項を足して統制しようとすると、この遅れはさらに広がる可能性がある。これは本稿の読みである。設定で強制できるものは設定に移し、社内ルールには設定では判断できないことだけを残す。そうすると、ルールは短くなり、守られているかも確かめやすくなる。条項を増やすと守られ方が検証しやすい条項の側に偏る構造は、生成AIの社内ルールは足すほど効かなくなる、という見直しの論点で扱った。

情報セキュリティと開発組織の責任者が次に決めるのは、上の表の一番上の層に何を入れるかである。とくに、個人アカウントでの利用を端末側で止めるか、サンドボックスを必須にするか、MCPサーバーを承認制にするか、の3つは、社内ルールに書いても守られたかを確かめにくく、設定にすれば確かめられる。この3つを端末管理で強制する範囲として先に決めると、社内ルールに残る条項は、人が判断するしかないものだけになる。そのうえで残った条項の総量をどう抑えるかは、生成AIの社内ルールに条項の総量の上限を置くかという見直しの論点へ続く。どのプランで契約し、費用とレビューの分担を誰が持つかという導入判断の側は、Claude Code法人導入の判断ポイント4つで扱った。