Claude Code セキュリティ事故例と会社で使う設定と対策

Q: Claude Codeの権限設定はどこで変えますか？

Claude Codeの権限設定は、settings.json という設定ファイルで変えます。権限の設定ファイルの置き場所には、組織の管理設定（組織の全員に効き、利用者が上書きできない設定。端末に置く場合のファイル名は managed-settings.json で、TeamとEnterpriseではClaude.aiの管理画面から設定を配る方式もあります）、プロジェクトの .claude/settings.json、利用者の ~/.claude/settings.json などがあり、この中では管理設定が最も強く効きます。Claude Codeの今の権限の状態は、/permissions というコマンドで確かめられます。

Q: Claude Codeの --dangerously-skip-permissions は使ってよいですか？

--dangerously-skip-permissions は、原則として使いません。このオプションは、確認をほぼすべて飛ばす bypassPermissions モードと同じです。Claude Codeの公式ドキュメントは、このオプションを、壊れても困らないコンテナ（ほかから切り離したプログラムの実行環境）や仮想マシンの中だけで使うよう書いています。会社では、管理設定（組織の全員に効き、利用者が上書きできない設定）の permissions.disableBypassPermissionsMode で、このオプションを封じます。

Q: .envをClaude Codeに読ませないにはどうすればいいですか？

Claude Codeの権限の Read の禁止ルール（ファイルの読み取りを禁じるルール）で .env を指定し、AIの実行環境を囲うサンドボックスでも、同じファイルの読み取りを禁止します。禁止ルールだけでは、スクリプト（短いプログラム）の中からファイルを開く読み方を止められないためです。そもそも鍵の値を .env に書かず、OSの鍵の保管庫や鍵の管理サービスから読み込む方法もあります。

「Claude Codeのセキュリティ｜事故例と会社で使う設定」の全体像をまとめた図解｜AIで作り、別の目で確かめる

Claude Codeを会社で使うとき、AIが触るファイルと操作を決める。

作ったものを別の人が確認してから本番へ出します。

本番とは、社員やお客様が実際に使うシステムのことです。

権限の設定と運用のルールは事故のリスクを減らします。

さらに claude code セキュリティを考慮すると、AI任せの事故が増えます。

2025年〜2026年には大手サービスでも、AI任せの事故が続いています。

ARCHECO（AIを使った新規事業とプロダクト開発の会社）では、claude code セキュリティを重視するエンジニアと、エンジニアでないメンバーの両方が開発を進めています。さらに、この記事は、前半だけを読めば「会社で Claude Codeを使ってよいか、何に気をつければよいか」が分かるよう、前半と後半を分けて書いています。

ここだけ読めば分かる（前半の要点）

AIに開発や操作を任せたことによる事故は、2025年から2026年にかけて、Replit、Amazon、GitHub、Google、Anthropic（Claude Codeの提供元）といった大手のサービスでも続いています

事故の原因は、AIに権限を与えすぎる、人が確認しない、AIが読む文章に命令を混ぜられる、使っている部品が乗っ取られる、設定を間違える、の5つの型に分かれます

AIは、自分が作った穴に自分では気づきにくく、見つかった穴をAIだけで直すのも危険です

作るときは、作業用のフォルダ、確認の画面の読み方、鍵の扱い、消す・送る操作の確認を、最初に決めておきます

それでも穴は残るため、最後は、作った人とは別の人の目で確かめてからリリースします

前半は「それでも危ないときの仕組み作り」の節までです。

また、後半の知識では権限モードを扱います。

さらに、設定ファイルの置き場所と優先順位、サンドボックス、フック、管理設定、データの扱いを claude code セキュリティの観点から整理します。

この記事に書いたことは、事故の事例なら各社の公式の発表と報道の本文（2026年11月8日に取得し、出典を表に示した）、Claude Codeの仕様なら公式ドキュメント（code.claude.com/docs の日本語版と、auto モード（確認を出さずに進めるモード）の設定のページは英語版）とAnthropicのヘルプセンター（2026年11月7日と8日に取得）、研究と上位の解説記事が勧める設定なら、それぞれの文に出典を示した外部の記事と論文、ARCHECOの仕組みと数字なら、ARCHECOの社内の設定と記録と、2026年11月7日に業務用のMacで測った実測によります。Claude Codeは更新が速いため、設定の名前や既定値は、使う前に公式ドキュメントで確かめてください。

仕様の一次資料：セキュリティ、権限、権限モード、設定項目、サンドボックス、管理設定、データの扱い、autoモードの設定（英語）。

最近続いているAIの開発の事故

AIにコードを書かせる開発や、AIに操作を任せる道具に関わる事故のうち、企業やサービスの公式の発表か報道の本文で確かめられたものを、日付の順に並べます（出典はすべて2026年11月8日に取得）。

日付	企業・サービス	何が起きたか	出典
2025年5月29日（公表）	Lovable（文章で頼むとアプリを作るサービス）	Lovableで作られて公開されていたアプリを研究者が1,645件調べたところ、170件で、データベースの読み書きの制限が足りず、ログインしなくても他人のデータを読んだり書き換えたりできる状態だった	Matt Palmer氏の声明
2025年7月18〜20日ごろ	Replit（AIでアプリを作るサービス）とSaaStr	変更を禁じる指示を出していたのに、開発中のAIが本番のデータベースを削除し、1,200人を超える経営者と1,190社を超える会社のデータが消えた。AIは「復元できない」と説明したが、実際には復元できた	The Register・Fortune
2025年7月23日（AWSの発表）	Amazon Q Developer（AmazonのAIの開発支援）	VS Code（プログラムを書くための編集ソフト）向けの拡張機能の1つの版に、AIに端末やクラウドの資源を消させる命令が仕込まれたまま配られた。書き方の誤りで命令は実行されず、AWSは利用者の環境への影響はなかったとしている	AWS Security Bulletin
2025年8月26〜27日	nx（広く使われている開発の部品）とnpm（部品の配布の場）	乗っ取られた部品を入れたパソコンで、手元のClaude Code・Gemini CLI・Amazon qが、確認なしで動く設定で起動され、鍵のファイル探しに使われた	Nxの勧告・StepSecurity
2025年9月末〜10月（公表）	GitHub Copilot Chat	変更の確認の依頼の説明欄に、画面には見えない形でAIへの命令を書いておくと、それを読んだ人のAIが、その人の権限で非公開のコードを外へ送れることを研究者が示した。実際の悪用は報告されておらず、GitHubは修正済み	Legit Security
2025年12月1日（報道）	Google Antigravity（GoogleのAIの開発の道具）	エンジニアでない利用者が一時ファイル（キャッシュ）の削除を頼んだところ、AIがドライブ全体を、ごみ箱を通さずに消した。根拠は本人の投稿で、第三者の検証はない	The Register
2026年3月31日	axios（週に約1億回使われる通信の部品）とnpm	部品の管理者が偽の会議に誘われて公開用の鍵を盗まれ、遠隔操作の不正なプログラムを仕込んだ版が約3時間公開された	Datadog Security Labs
2026年3月31日	Anthropic（Claude Code）	Claude Codeの配布物に、元のソースコードを復元できるファイルが入ったまま公開され、約51万行が読める状態になった。Anthropicは、人の誤りによる出荷の問題で、顧客のデータや認証の情報は含まれないと説明した	Decrypt
2026年7月30日（公表）	Anthropic	委託先の環境で行っていた安全性の試験で、インターネットにつながっていないはずのClaudeが実際にはつながっており、実在する3つの組織の本番のシステムに侵入していた	Anthropicの報告
2026年10月19日（公表）	GMOサイバーセキュリティ by イエラエの調査	AIが自動で侵入を試す道具が、日本企業への攻撃に使われていたことを確認した。1台の攻撃元が狙った日本企業のうち8社が、2026年9〜10月に情報の漏えいを公表している	GMOサイバーセキュリティ by イエラエ・ScanNetSecurity

AIの開発の道具を自分で作っている大手の会社でも、これだけの事故が起きています。社内の担当者が、こうした事故の知らせを追い続けて、そのたびに自社の設定に当てはめ直すのは、片手間では難しい仕事です。

事故が起きた5つの根本原因

10件の事故を原因で分けると、次の5つの型にまとまります。どの型も、AIが特別に賢いとか愚かだとかいう話ではなく、人がAIに与えた権限と、確認の手順と、設定の問題です。

1. 権限の与えすぎ

AIが、本番のデータベースやドライブ全体や、強い権限を持つ鍵を、人の確認なしで使える状態になっていました。Replit、Google Antigravity、Amazon Q Developer、nxの事故がこの型です。新しく入った社員に初日から金庫の鍵を渡さないのと同じように、AIにも、その作業に要る分だけの権限を渡します。

2. 人が確認しなかった

「本番には触らないで」という指示を文章で伝えただけで、止める仕組みが無かった。自動の処理が、確かめられないまま製品に組み込まれた。公開する中身から除く設定を、誰も見ていなかった。Replit、Amazon Q Developer、Claude Codeのソースコードの公開、Google Antigravityの事故がこの型です。危ない操作は文章のお願いではなく仕組みで止め、出荷の前に人が確かめる工程を入れます。

3. AIへの命令の差し込み

AIは、「読んだ文章」と「頼まれた仕事」を区別しきれません。変更の依頼の説明欄や、外から届いた文章の中に命令を隠しておくと、AIが利用者の権限のまま、その命令に従ってしまうことがあります。専門の言葉では、プロンプトインジェクションと呼びます。GitHub Copilot Chat、Amazon Q Developer、nxの事故がこの型です。外から来た文章を読むAIに、強い権限と、外へデータを送る手段を、同時に持たせないことが対策です。

4. 部品の乗っ取り

AIに書かせたコードも、人が書いたコードも、ほかの人が作って公開している部品に頼っています。その部品の管理者がだまされたり、鍵を盗まれたりすると、部品を入れた全員が被害を受けます。nx、axios、Amazon Q Developerの事故がこの型です。部品の版を固定し、審査の無い置き場から部品を入れないことが対策です。

5. 設定ミス

データベースの読み書きの制限が無い、つながっていないはずの環境がインターネットにつながっていた、という型です。Lovableで作られたアプリと、Anthropicの試験の事故がこの型です。AIに作らせると画面はすぐに動きますが、画面に出てこない設定は、誰も確かめていないことがよくあります。公開の前に、外から見て中のデータが見えないかを確かめます。

5つの型のうち、2から5は、AIに詳しいかどうかに関係なく起きる、仕事の進め方の問題です。設定を1つ入れれば終わる話ではなく、作る工程のどこで、誰が確かめるかを決めておく必要があります。

エンジニアでない人がClaude Codeでアプリを作るときのリスク

Claude Desktop（パソコンに入れて使うClaudeのアプリ）などの登場で、ターミナル（文字でコマンドを打ち込む画面）に慣れていない人も、Claude Codeで社内の道具や小さなアプリを作れるようになりました。エンジニアでない人が作るときに特に起きやすいのは、次の4つです。

起きやすいこと	なぜ起きるか	前半の事故との関係
動いたので完成だと思う	画面で動くことと、外から攻撃されても安全なことは別。データベースの読み書きの制限のような設定は、画面に出てこない	Lovableで作られたアプリ（設定ミス）
確認の画面で、意味が分からないまま「はい」を押す	AIが何を消そうとしているか、何を送ろうとしているかを、画面の文から読み取れない	Google Antigravity（人が確認しなかった）
鍵（APIキーやパスワード）を会話に貼る、コードに書く	動かすために鍵が要るとき、いちばん手早い方法を選んでしまう。Claude Codeの会話の記録は、既定でパソコンに30日間、暗号化されずに残る（公式ドキュメント）	鍵が残ると、乗っ取りや漏えいの入口になる
AIが勧めた部品を、そのまま入れる	部品の名前が本物かどうかを確かめる手段を知らない。AIが書く部品の名前のうち、実在しないものが商用のAIで平均5.2%以上あったという研究もある（後半の「Claude Codeで起きうる危険」で説明）	部品の乗っ取り

作る人がこうした点を全部覚えて、毎回ひとりで守り切るのは難しいことです。エンジニアでない人が作る場合こそ、会社の側で、作る人とは別に確かめる人を置くのが現実的です。

社内の監査：作る人とは別の目で確かめる

ARCHECOでは、セキュリティに強いエンジニアと、エンジニアでないメンバーの両方がAIを使って開発し、社内ツールのセキュリティ監査を日常の業務として行っています。

作った画面が動くかだけでなく、見せてはいけないデータが見えないか、変更してはいけないデータを書き換えられないか、といった点を確かめるのが監査です。図は、こうした確認で使う模擬攻撃の考え方を示しています。特定のアプリの実験結果や、確認された弱点を示す図ではありません。

見つかった穴をAI任せで直すのは危ない

穴が見つかったとき、「Claude Codeに直して、と頼めばよい」と考えるのは自然です。しかし、AIだけで直して終わりにするのは危険です。理由は3つあります。

作ったAIと同じ見落としをする: Anthropicの技術者は、2026年3月24日に公開した記事「Harness design for long-running application development」で、AIに自分が作ったものを評価させると、人が見れば出来が良くないものでも、自信を持って褒める傾向があると書いています。穴を作ったときの思い込みのまま直すと、同じ所を見落とします
「直った」という報告が正しいとは限らない: 前半のReplitの事故では、AIは「データベースは復元できない」と説明しましたが、実際には復元できました。AIの報告は、AIが確かめた範囲の話でしかありません
直す作業にも権限が要る: 穴を直すためにAIに本番やデータベースを触らせると、5つの型の1と2（強い権限と、人の確認なし）がそろってしまいます

Anthropic自身も、コード全体の弱点を調べるClaude Securityで、AIが作った修正案を自動では当てず、担当者が画面で根拠と修正案を確かめる作りにしています（後半の「自動セキュリティレビューとClaude Security」で説明）。AIに修正案を作らせるのは有効ですが、修正案を当ててよいかを決めるのは人です。直したつもりの穴が本当にふさがったかを、攻撃する側の目で確かめ直す作業まで社内で回すには、セキュリティに詳しい人の時間がかかります。

AIが自分で作った穴に気づけない理由

AIは、攻撃に使える穴を作っているその場で、なぜ気づけないのでしょうか。なお、出典と実測から分かっている理由は、claude code セキュリティに関する次の3つです。

作る役と確かめる役が同じ

AIに自分の作業を確かめさせると、作ったときと同じ前提で読み直すため、同じ所を見落とします。前の節で紹介したAnthropicの記事は、作る役のAIと評価する役のAIを分けることが、この問題への強い手段になり、評価する役を疑い深く調整するほうが、作る役に自分の作業を批判させるよりはるかに扱いやすいと書いています。

頼まれたことの完成を優先する

AIは、頼まれた機能を動かすことを目標に作業を進めます。安全かどうかは、頼まれていなければ後回しになりがちです。GitHub Copilotが書いたコードを調べた研究（Pearceほか「Asleep at the Keyboard?」、2022年のIEEE Symposium on Security and Privacyで発表）では、弱点が生まれやすい89の場面で書かせた1,689本のプログラムのうち、約40%に弱点がありました。また、裏口（外から勝手に操作するために隠した仕掛け）を仕込んだリポジトリ（プログラムのファイル一式と変更の履歴を入れた保管場所）で機能の追加を頼むと、Claude Codeが裏口を残したまま作業を進めたという技術者の検証も報告されています（後半の「Claude Codeで起きうる危険」で説明）。Replitの事故でも、AIは変更を禁じる指示より、目の前の作業を進めることを優先しました。

守りの全体の地図を持っていない

AIが見ているのは、いま作っている画面や関数（プログラムの部品の1単位）です。どの入口から攻撃され、どこに鍵をかけるべきかという全体の地図は、頼まれない限り持っていません。Lovableで作られたアプリの事故では、画面の側の制限だけに頼り、データベースの側に鍵がかかっていませんでした。ARCHECOが2026年11月7日に試した実測でも、ファイルの書き込みを止める守りが、ある入口では働き、別の入口では呼ばれもしませんでした（「それでも危ないときの仕組み作り」の節で説明）。

3つの理由は、どれもAIの性能が上がれば自然に消えるものではなく、作る工程の組み方で補うものです。作る役と確かめる役を分け、守りの地図を誰かが持つ体制を、社内だけで最初から用意するのは、多くの会社にとって簡単ではありません。

作るときから守る：ARCHECOの社内勉強会で教えている要点

ARCHECOでは、2026年8月から、エンジニアでないメンバーがそれぞれ自分で持ち込んだテーマでアプリを作り、エンジニアが伴走してレビューする、非エンジニア向けの開発勉強会を開いています。勉強会では、セキュリティを詳しく説明しています。勉強会で教えている要点のうち、エンジニアでない人が自分で実行できるものに絞ると、次のとおりです。

作業用の専用のフォルダで起動する: 自宅のフォルダ（ホームディレクトリ）の直下でClaude Codeを起動しない。作るアプリごとにフォルダを作り、機密の書類のフォルダから離す
確認の画面は、読んでから押す: 何を消すのか、どこへ送るのかが読み取れないときは「いいえ」を選び、詳しい人に聞く。「はい、今後は聞かない」は、意味が分かっている操作にだけ使う
確認を飛ばす設定を使わない: 確認をほぼすべて飛ばすモード（bypassPermissions、起動の指定では –dangerously-skip-permissions）は使わない。前半のnxの事故では、この種の設定で起動されたAIの道具が、鍵のファイル探しに使われた
鍵を会話に貼らない、コードに書かない: 鍵は、人が自分のターミナルで設定する。鍵を書いた .env のようなファイルは、権限の Read の禁止ルールに入れて、AIに読ませない
消す・送る・公開する操作は、毎回確認にする: 本番への反映や、手元の変更を共有の保管場所へ送る操作（プッシュ）を、権限のルールの ask（毎回確認）に入れる
会社が配った設定を外さない: 会社が管理設定で配った禁止や確認のルールは、自分の判断で外さない。うまく動かないときは、配った人に相談する
知らないものをそのまま入れない: ネットで見つけたコマンド、知らない人のリポジトリ、提供元の分からないMCP（外部のサービスとClaude Codeをつなぐ仕組み）のサーバーやスキル（作業の手順書）は、そのまま実行したり入れたりしない
公開の前に、別の人に見てもらう: /security-review というコマンドでClaude Codeにコードを点検させたうえで、その結果と、外から見てデータが見えないかを、エンジニアに確かめてもらってから公開する

フックや管理設定のように、エンジニアでない人が自分で書くのが難しいものは、会社の側（エンジニアや管理者）が用意して配ります。中身は後半で詳しく説明しています。8つの要点は、作る人の注意で守るものです。人の注意は、忙しいときほど抜け落ちます。

それでも危ないときの仕組み作り

要点を守っていても、人は忘れ、AIは別の書き方を思いつきます。そこで、人の注意に頼らずに止まる仕組みを、作る人とは別の側で置いておきます。以下は、ARCHECOが社内で実際に使っている仕組みです。設定の値・鍵・トークン（ログインした状態を表す文字列）・取引先の名前は載せず、仕組みの形だけを書きます。

intBBという社内の仕組みで、AIが読める範囲を絞る

ARCHECOでは、社内の会議の記録や資料をAIから読めるようにした、intBBという社内の仕組みを使っています。AIに社内の情報を渡すほど仕事は速くなりますが、渡し方を誤ると、見せてはいけない人にまで情報が届きます。intBBでは、社内の会議の記録に残っている範囲で、次の形をとっています。

見られる範囲を、データの出どころごとに絞る: 2026年10月の社内の会議で、見られる範囲の決め方を、会議やチャットのチャンネルといったデータの出どころの単位に改め、初めの状態では、その会議の参加者だけが見られるようにする方針にした
機微な情報を、AIで自動で判定する: 見られる範囲の設定に加えて、機微な情報が含まれていないかをAIで自動で判定する仕組みを重ね、守りを1か所に頼らない形にする方針にした
社外とつなぐときは、ファイルを直接送り込まない: 2026年10月の社内の会議で、社外のアプリやスキルとつなぐときは、外からファイルを直接送り込む方式を避け、MCPやAPI（プログラムどうしが決まった形でやり取りする窓口）でつなぎ、各社が自分で持つ保管場所を参照する方式を基本にした
社外に出すときは、会社ごとに環境を分ける: 社外の会社に使ってもらう形では、会社ごとに独立した環境を置き、データを1か所に集める構成はとらない方針にした

社内のAI開発の標準ガイドラインでも、機密のファイルを扱うMCPを入れるときは、役割ごと・データの種類ごとに権限を切り分け、安全の歯止めを置くことを必須にしています。

設定を足すほど安全になるとは限らない

ここまで読むと、Claude Codeのセキュリティは、禁止のルールを正しく並べれば固められるように見えます。禁止のルールとは、危険なコマンドを禁止し、鍵のファイルの読み取りを禁止し、確認を飛ばすモードを封じる、といった設定です。上位の記事も、その順で設定を並べています。実際、これらの禁止の設定は、どれも正しく、入れておくべきものです。

ただし、会社でClaude Codeに仕事を任せきる段階になると、別の問題が前に出てきます。権限のルールも含めて、守りはそれぞれ、止められる入口と止められない入口が決まっていて、すべての入口を見張る守りは無いからです。Read(./.env) を禁止しても、python -c のように、スクリプト（短いプログラム）の中から .env を開く読み方には、その禁止のルールは効きません。Bash(rm -rf *) を禁止しても、rm -rf が bash -c の中から呼ばれると、その禁止のルールには当てはまりません。上位の記事は、こうした抜け道を1つずつ見つけてはルールを足しています。しかし、抜け道をルールで1つずつふさぐやり方は、AIが別の書き方を思いつくたびに後手に回ります。

ここで必要なのは、ルールを増やすことではなく、自分の守りが、どの入口を見ていて、どの入口を見ていないのかを、実際に試して知ることです。見ていない入口が分かれば、会社でClaude Codeを管理する人が、そこに別の層を当てられます。以下は、ARCHECOの業務用のMac 1台で、2026年11月7日に試した結果です。

守りの入口の地図：フックに8通りの入力を渡して試した

ARCHECOでは、AIの作業がどこまで進んだかを記録した「状態ファイル」を、AIが直接書き換えられないようにしています。AIが自分の進み具合の記録を書き換えられると、何が本当に終わったのかを、人もAIも確かめられなくなるからです。ARCHECOでは、状態ファイルを専用のコマンドを通してだけ更新し、AIによる直接の書き込みは、PreToolUse フックで拒否しています。

このフックは44行の小さなプログラムで、Claude Codeから渡される「これから実行する操作」の情報を読み、書き込みの道具（Write・Edit・NotebookEdit）が状態ファイルのフォルダを指していたら、拒否の答えを返します。ARCHECOは、この記事のために、状態ファイルのフックに8通りの入力を渡し、フックがどう答えるかを確かめました。

試した操作	フックの答え
Writeで状態ファイルに書く	拒否
Editで、`legacy/../` のように一度別のフォルダを経由する書き方で状態ファイルを指す	拒否（経路を正規化（回り道を除いた本当の場所に直すこと）してから判定している）
NotebookEditで状態ファイルのフォルダに書く	拒否
入力が壊れていて読めない	拒否（読めないときは止める側に倒す）
Writeで状態ファイルの外（記事のファイル）に書く	通す（拒否を返さず、書き込みは通常の権限の確認へ進む）
あらかじめ例外として決めた、古い記録のフォルダに書く	通す（意図した例外。拒否を返さず、書き込みは通常の権限の確認へ進む）
入力が空	何も返さない（拒否も許可も出さず、通常の権限の確認に任せる。フックが想定外の場面で呼ばれたときに、拒否をばらまかないため）
Bashで `echo ... > 状態ファイル`（文字をファイルへ書き出すシェルの書き方）と書く	何も返さない（実機では、そもそもフックが呼ばれず、書き込みは止まらない）

さらにARCHECOは、作業用の一時フォルダに状態ファイルのフォルダと同じ構成を作り、実際のClaude Codeで2通りの書き込みを試しました。Writeの道具で書こうとすると、フックが「状態ファイルは専用のコマンドで管理している」という理由を返して拒否し、ファイルは作られませんでした。一方、Bashの echo で同じ場所に書くと、ファイルは作られました。フックは、設定で「Write・Edit・NotebookEditのときに呼ぶ」と決めてあるため、Bashの操作ではそもそも呼ばれないからです。この試験では、状態ファイルのフォルダに、権限の Edit の禁止ルールは置いていません。

分かったこと：守りは入口ごとに別の層が要る

Bashからの書き込みで状態ファイルのフックが呼ばれなかったのは、フックの作りの誤りではありません。フックは、名前を挙げた道具の入口を、試した8通りの範囲では、経路の回り込みや壊れた入力まで含めて止めています。分かったのは、守りはそれぞれ、止められる入口と止められない入口が決まっていて、専用の道具・シェルのコマンド・スクリプトの3つの入口をすべて見張る守りは無いということです。公式ドキュメントの権限のページを読み合わせると、入口ごとに効く層は次のように分かれます。表の「止める」は、その入口からの書き込みが断られてファイルが書き換わらないこと、「呼ばれない」「止めない」「対象外」は、その層では書き込みが止まらないことを指します。

書き込みの入口	ARCHECOの状態ファイルのフック	権限の `Edit(...)` の禁止ルール	サンドボックスの書き込みの制限
Write・Edit・NotebookEditの道具	止める（実測）	止める	対象外（サンドボックスはBashのコマンドと、そのコマンドが起動した別のプログラムを囲う仕組み）
Bashの `>` での書き込み、`tee`・`sed` など（ファイルを書き換えるシェルのコマンド）	呼ばれない（実測）	止める（公式：Claude CodeがBashの中で認識するファイルのコマンドとリダイレクト（コマンドの出力をファイルへ流す書き方）に効く）	止める（`filesystem.denyWrite` か `Edit` の禁止ルールで名指しした場所。作業フォルダの中は既定では書ける）
PythonやNode（プログラムの言語と、その実行の道具）のスクリプトの中からファイルを開く	呼ばれない	止めない（公式：間接的にファイルを読み書きするプログラムには効かない）	止める（Bashのコマンドの行と同じく、書き込みを禁じた場所。公式：OSの機能で、子のプロセス（そのプログラムが起動した別のプログラム）まで含めて囲う）

2026年11月8日時点の公式ドキュメントでは、Edit の禁止ルールは、tee・sed のようにClaude CodeがBashの中で認識するファイルのコマンドと、> でのリダイレクトの書き込み先にも効くとされており、書き込みの入口の表のうち、Bashの > や tee・sed で書き込む入口は、権限のルールでふさげます。そして、Bashのコマンドの入口をルールでふさいでも、スクリプトの中からファイルを開く入口が残ります。スクリプトの中からファイルを開く入口を閉じられるのは、3つの層のうち、OSの機能で囲うサンドボックスだけで、それも守りたいファイルを書き込みを禁じた場所として指定したときに限ります。設定を「◯選」として並べると、この3つの層が同じ重さに見えてしまいます。会社で決めるべきなのは、守りたいファイルごとに、3つの入口のどれまでを閉じるかです。

実は、ARCHECOの状態ファイルの場合、AIが状態ファイルを書き換える動機は「進み具合の記録を早く進めたい」という、悪意のない近道です。悪意のない近道は、ほぼすべてがWrite・Edit・NotebookEditの道具を通るため、フックの層で実用上は足ります。一方、鍵のファイルのように、外から送り込まれた命令（プロンプトインジェクション）で中身を読み出されうるものは、直前の表の書き込みの入口ではなく、読み取りの入口を閉じる必要があり、専用の道具とシェルのコマンドからの読み取りは権限の Read の禁止ルールで止まりますが、スクリプトの中からファイルを開く読み方を閉じられるのは、鍵のファイルを読み取り禁止の場所（filesystem.denyRead）に指定したサンドボックスだけです。守りの強さは、守る対象を誰がどんな動機で狙うかで決めます。

本番とデータベースは「名指し」で頼まれたときだけ通す

ARCHECOでは、AIに任せる作業の決まりとして、「お金・外部への送信・相手への約束・本番の変更だけは、人が直接確かめる」と書いています。本番への反映や、アクセス解析の設定の公開も、人が対象を名指しで頼んだときだけAIに実行させます。

このルールを、Claude Codeの auto モードの分類器に教えています。auto モードの分類器は、利用者の設定ファイル（~/.claude/settings.json）か組織の管理設定の autoMode という欄から、組織の環境の説明（environment）と、止めたい操作（soft_deny。人の明示の指示で解除できる禁止）を読みます。ARCHECOの業務用のMacで、2026年11月7日に claude auto-mode defaults（組み込みのルールを表示するコマンド）と claude auto-mode config（実際に効いているルールを表示するコマンド）を実行して比べた結果は、次のとおりです。

ルールの種類	組み込みの数	このMacで効いている数	差の中身
environment（信頼する環境の説明）	21	24	鍵の扱い方、使っているサービスの範囲、信頼しない外部の宛先などを、文章で説明
soft_deny（人の明示の指示で解除できる禁止）	72	74	本番の環境を書き換える2つのコマンドを追加
hard_deny（解除できない禁止）	1	1	変更なし（組み込みの1つは、データを信頼する範囲の外へ持ち出す操作の禁止）
allow（禁止の例外）	16	16	変更なし

「本番は名指しで頼まれたときだけ通す」というARCHECOのルールを支えているのが、auto モードの分類器の判定の順番です。英語版の公式ドキュメント（auto-mode-config、2026年11月7日取得）によると、soft_deny に当てはまる操作は止められますが、利用者のメッセージが、AIがこれから実行する操作そのものを直接・具体的に指示している場合は、分類器がそれを通します。「リポジトリを片付けて」のような大まかな頼み方では、強制的な上書きの操作は通りません。組み込みのルールにも「本番への反映は、本番の対象を名指ししたときだけ」という条件が書かれています。

つまり、「本番は名指しで頼まれたときだけ」という会社の運用のルールが、分類器の判定の順番とそのまま一致します。運用のルールを文書に書いて社員に守らせるだけでなく、AIの側の判定の仕組みに同じ線を引いておくと、人が見ていない時間の作業でも、分類器が同じ線で判定します。

auto モードの分類器に会社のルールを教える設定（autoMode）には、公式ドキュメントが書いている4つの注意があります。

分類器は、リポジトリの中の設定ファイル .claude/settings.json からは autoMode を読みません。リポジトリに仕込まれた設定で、許可のルールを差し込まれないためです。利用者の設定か、組織の管理設定に書きます
利用者が足した allow のルールは、組織の soft_deny を上書きできます。組織の管理設定の autoMode と利用者の設定の autoMode は、どちらかが優先されるのではなく、両方のルールが合わせて読まれるため、組織の soft_deny は、利用者が外せない絶対の線にはなりません
どんな指示でも実行させてはいけない操作は、分類器ではなく、管理設定の permissions.deny に書きます。こちらは分類器より先に効き、誰も上書きできません
自分のルールを足すときは、リストに "$defaults" という印を必ず残します。この印を書かずにリストを設定すると、その種類の組み込みのルール（強制的な上書きや本番への反映を止めるルールなど）が丸ごと置き換わり、消えてしまいます。ARCHECOの設定は、soft_deny ではこの印を残したうえで2つのコマンドを足しています。environment は、Claude Codeの /auto-mode-setup（環境の説明の下書きを作るコマンド）が組み込みの説明を書き写した形で、会社の環境の説明を足しています。設定を初めの状態に戻すときは claude auto-mode reset というコマンドを使います

autoMode は、公式ドキュメントの例では次の形で書きます。各項目は、新しく入った技術者に会社の環境を説明するときのような普通の文章で書き、書いた後は claude auto-mode config のコマンドで、効いているルールに入ったかを確かめます。

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted internal domains: *.corp.example.com, api.internal.example.com"
    ]
  }
}

秘密の鍵は会話に入れず、権限を絞った鍵をAIに渡す

ARCHECOの業務用のMacでは、AIが使う外部のサービスの鍵を、次の形で置いています。

クラウドの鍵は、AIの作業に要る権限だけを持つ専用の利用者に発行する: ARCHECOでは、クラウドの鍵を、画面からのログインができない、コマンド専用の利用者に発行し、AIの作業に要るサービスの権限だけを付けています。管理者の全権を持つ鍵は使いません。ほかのサービスを操作しようとすると、権限がないと断られます
鍵は、人が自分の端末で入力する: 鍵の値は、AIとの会話に貼らず、人が自分のターミナルで設定のコマンドに入力しています。後半の「見落としやすい2つの経路」で説明するとおり、会話の記録は端末に平文で残るため、鍵を会話に貼らないことに加え、記録のフォルダ（~/.claude/projects/）を読める人を本人だけに絞っておきます
権限の広い操作は、鍵の側で分けておく: GitHubのコマンドの道具（gh）で標準の手順で発行した鍵では、自動の処理の定義ファイル（.github/workflows/ の下）を書き換えて送ることができず、追加の権限（workflow）が要ります。この権限を足す操作は、人がブラウザで画面に表示された番号を入力して承認する手順になっていて、AIだけでは足せません。AIが自動の処理の定義を書き換えて、鍵を外へ送る処理を仕込む経路を、鍵の側で人の承認の後ろに置けます

会話の記録に鍵が残っていないかは、鍵の形をした文字列（たとえばクラウドの鍵の決まった書き出し）で、会話の記録のフォルダを定期的に検索すると確かめられます。ただし、説明書の例や試験用の偽の値でも当たるため、当たった件数だけでは漏れたかどうかは決まりません。当たったものは1件ずつ、本物かどうかと、まだ有効かどうかを確かめます。

作る役と確かめる役を、別の会社のAIに分ける

ARCHECOでは、Claude Codeが作ったコードや文章を、OpenAIのCodexとGoogleのGeminiに、それぞれ独立して確かめさせる自作の道具を使っています。この道具は、確かめる対象のファイルだけを空の一時フォルダに写し、確かめる側のAIをそのフォルダの中で動かします。確かめる側のAIは、リポジトリの残りの部分や鍵のファイルに触れません。

作った本人のAIに自分の作業を確かめさせると、そのAIは、作ったときと同じ思い込みで、同じ所を見落としがちです。ARCHECOの社内のAI開発の標準ガイドラインでも、Codexはファクトの確認とコードのレビューに、Claudeは複雑な文脈の分析と文章の作成に向くと整理しています。この記事の下書きも、公開の前にこの道具で、Claude以外のAIの確認を受けています。

端末と自動権限モード（auto モード）の決め方

ARCHECOの社内のAI定例（AIの使い方を話し合う定例の会議）の議事録には、Claude Codeの安全に関わる次の判断が残っています。

2026年4月8日のAI定例で、Claude Teamプランの組織の設定を、セキュリティ・費用・運用への影響の観点から1つずつ確かめ、自動権限モードを有効にすると議事録に記録された。処理を速くするモードは、費用が大きく増えるため見送ると記録されている。同じ回に、確認をほぼすべて飛ばすモード（bypassPermissions）は、危険なため見送ったことも記録されている
2026年10月13日のAI定例で、AIに常時作業させる専用の端末を置くことと、端末のセキュリティの隔離、複数の利用者のプロファイル（ブラウザやアカウントの利用環境）と遠隔接続の切り分け方について話し合った

とはいえ、自動権限モードを有効にする判断は、守りを緩めたという意味ではありません。議事録に残る有効化の理由は業務の効率化とAIの活用であり、確認を減らすことと、守りを外すことは、同じ回の議事録でも別々に扱われています。確認の画面を何十回も出すと、人は読まずに「はい」を押すようになり、確認は形だけになります。ARCHECOの考え方は、確認を減らす代わりに、本番とデータベースへの線をauto モードの分類器のルールで、AIの進み具合の記録への線を状態ファイルのフックで、先に引いておく、という順番です。

生成AIの道具を取引先の業務に持ち込む場面について、取引先の情報システム部門とのセキュリティの評価や、データが外に出ないことの説明への備えを話し合った記録が、2026年の社内の議事録に複数あります。その説明で問われるのは、「どの設定を入れたか」よりも、「AIが触れられる入口を、どこまで、どの層で閉じたか」です。

ここまでの仕組みは、ARCHECOが自社の業務の中で、試しては直しながら作ってきたものです。同じものを社内で一から作り、Claude Codeの版が上がるたびに試し直すには、エンジニアの手間が続けてかかります。

ここから後半：本当は知っておくべき知識

ここから先は、Claude Codeの設定を自分で決める人や、社内の決まりを作る人に向けて、公式ドキュメントと、「Claude Code セキュリティ」で検索したときに上位に並ぶ解説記事（以下、上位の記事）の内容を詳しく整理します。前半で要点を確かめた人は、必要な節だけを読めば足ります。

Claude Codeのセキュリティとは

Claude Codeは、Anthropicが提供する、パソコンの中のファイルを読み、書き換え、コマンドを実行して結果を確かめるところまで自分で進めるAIです。ChatGPTのようなチャットのAIは、チャットの画面で使う限り、文章で答えを返すのが中心で、パソコンの中のファイルには直接触れません。Claude Codeは、頼まれた作業を終わらせるために、ファイルを消す、外部のサイトからプログラムを取ってくる、インターネットへデータを送るといった操作まで実行できます。Claude Codeのセキュリティの考え方が、チャットのAIのセキュリティの考え方と根本から違うのは、Claude Codeがこうした操作まで自分で実行できるためです。

Anthropicが用意している土台

公式ドキュメントのセキュリティのページ（code.claude.com/docs/ja/security）によると、Claude CodeはAnthropicのセキュリティの取り組みに沿って開発されており、外部の監査の報告書（SOC 2 Type 2）と情報セキュリティの国際規格の認証（ISO 27001）は、Anthropic Trust Center（Anthropicのセキュリティ情報の公開ページ）で確認できます。

その上で、Claude Codeの安全は「権限」を中心に組み立てられています。権限とは、AIが何かを実行する前に、その操作を人の確認なしで進めてよいかどうかを、権限モード（どこまで確認なしで進めるかの段階）と権限のルールで決める仕組みです。

使う人の責任の範囲

公式ドキュメントは、Claude Codeが持つのは使う人が与えた権限だけであり、提案されたコードやコマンドを承認する前に安全を確かめる責任は使う人にある、と書いています。会社で使わせる立場の人が最初に決めるべきなのは、社員が「はい」を押す回数を減らしながら、押してはいけない操作だけは、押せない形にしておくことです。

Claude Codeで起きうる危険

上位の解説記事が挙げている危険を、何が起きるかの順に整理すると、次の8つになります。

危険	何が起きるか	起きる主な経路
ファイルへの広いアクセス	作業と関係のない書類や設定ファイルまで、AIが読む・書き換える	自宅のフォルダ（ホームディレクトリ）でClaude Codeを起動する
コマンドの意図しない実行	ファイルの一括削除、本番（社員やお客様が実際に使っているシステム）のデータベースの削除、チームで共有しているプログラムの変更の履歴の書き換え	確認の画面を読まずに「はい」を押し続ける。確認を飛ばす設定にする
秘密の情報の誤送信	パスワードやAPIキー（外部のサービスを使うための鍵）が、会話やコミット（プログラムの変更を履歴として記録すること）に入って外へ出る	鍵を書いたファイル（.envなど）を作業フォルダに置く。会話に鍵を貼る
プロンプトインジェクション	読み込んだWebページや文書に隠された命令を、AIが指示として実行する	信頼できないページ・リポジトリ（プログラムのファイル一式と変更の履歴を入れた保管場所）・文書をAIに読ませる
悪意のある部品の混入	乗っ取られたライブラリ（ほかの人が作って公開している、プログラムの部品）や、名前の似た偽のライブラリを入れてしまう	AIにライブラリを選ばせ、そのまま入れる
他人のリポジトリに仕込まれた設定	リポジトリに置かれた設定ファイルやフックが、開いた人のパソコンで動く	知らない人のリポジトリをそのまま開く
想定外の請求	定額のつもりが、追加の利用分で大きな請求になる	使用量を誰も見ていない
ソーシャルエンジニアリング	「このコマンドを貼って実行して」という誘導に、人かAIが従う	ネットで見つけたコマンドを確かめずに実行する

上位の記事と論文が挙げる事故

上位の記事と論文には、次のような事例が挙げられています。出所は項目ごとに括弧の中に書いた外部の記事と論文で、記事ごとに数え方もばらつくため、数字は「この程度のことが起きている」という目安として読むのが安全です。

2026年2月、教育コミュニティを運営する会社で、サーバーの構成を管理する道具（Terraform）の整理をClaude Codeに任せたところ、本番のデータベースと自動バックアップまで削除され、約2.5年分のデータが一時的に失われた（note.com の記事。AWS（Amazonのクラウドのサービス）の支援で24時間後に復旧したとされる）
2026年3月31日、JavaScript（Webのプログラムの言語）で広く使われる通信の部品（axios）の開発者のアカウントが乗っ取られ、遠隔操作の道具を仕込んだ版が一時的に公開された（Zennの記事が、セキュリティの会社のトレンドマイクロと、弱点の管理のサービスのyamoryの解説を出典に紹介）
裏口（外から勝手に操作するために隠して仕込んだ仕掛け）を仕込んだリポジトリで機能の追加を頼むと、Claude Codeが裏口を残したまま作業を進めたという、ある技術者の検証（2026年3月にQiitaで公開された記事。note.com の記事が紹介）
AIが書いたコードに出てくるライブラリの名前のうち、実在しないものが、商用のAIで平均5.2%以上、誰でも入手できる公開のAI（オープンソースのAI）で21.7%あったという研究（16のAIに2つのプログラムの言語で57.6万件のコードを書かせて調べた論文。出所は「実在しないライブラリの名前をAIが書く割合を調べた論文（USENIX Security 2025）」。2024年6月に公開され、2025年にセキュリティの国際学会USENIX Securityで発表された。実在しない名前を攻撃者が先に登録すると、AIが書いた名前のままライブラリを入れた人は、攻撃者の偽の部品を入れてしまう）
5人のチームで、Claude Codeの利用料として月127万円の請求が来たという事例（note.com の記事。時期と会社名は書かれていない。プランの枠を超えた利用を誰も見ていなかった）

脆弱性はAnthropicが受け付けて直す

Claude Code自体のセキュリティ上の欠陥（脆弱性）は、AnthropicがHackerOne（脆弱性の報告を受け付ける外部のサービス）で報告を受け付けています。公式ドキュメントは、見つけた人に、公開の場で明かさず、再現の手順を添えて報告し、修正までの時間を与えるよう求めています。使う側にできるのは、Claude Codeを最新の版に保つことです。Claude Codeは、claude update というコマンドで手動でも更新でき、claude doctor というコマンドでインストールの方法と今の版を確かめられます。

実際に修正された例として、Claude Codeの情報を扱うサイトであるclaude-code-lab の記事は、GitHub Advisory Database（プログラムを置いて共有するサービスのGitHubが運営する、脆弱性の公開データベース）に載った、悪意のあるリポジトリの設定ファイルによって、そのフォルダを信頼するかを尋ねる画面で人が承認するより前にAPIキーが外へ送られうる脆弱性（CVE-2026-21852）を挙げています。この脆弱性はClaude Codeの版2.0.65で修正されたとされます。Claude Codeを古い版のまま使って知らないリポジトリを開くと、こうした修正済みの穴が手元のClaude Codeには残ったままになります。

他のAIの道具と比べたときの位置

2026年11月時点で、GitHub Copilot（プログラムを書く作業を補助するAI）やChatGPTと比べると、Claude Codeは、コマンドの実行とファイルの操作の自由度が最も高い道具です。Claude Codeは自由度が高いぶん、設定を間違えたときの被害も、GitHub CopilotやChatGPTより大きくなります。一方で、Claude Codeは、権限を細かく決められる範囲も3つの道具の中で最も広く、設定と運用で守れる範囲が広い道具でもあります。

観点	Claude Code	GitHub Copilot	ChatGPT
コマンドの実行	できる	エージェントの機能（AIが自分で手順を進める機能）とCLI（文字のコマンドで操作する道具）でできる	一部の機能でできる
ファイルの操作	できる	編集ソフトの中が中心	アップロードしたファイルだけ
権限の管理	ツール・コマンド・ファイル・通信先ごとに設定できる	編集ソフトの設定に依存	会話ごとに使う機能を選ぶ

公式の保護機能

Claude Codeには、最初から次の保護機能が入っています。この節の内容は、公式ドキュメントのセキュリティと権限のページ（2026年11月7日取得）と権限モードのページ（2026年11月8日取得）によります（拡張機能の改ざんの事例だけは、claude-code-lab の記事が出所です）。

権限モード：どこまで確認なしで進めるか

モード	確認なしで進める範囲	向いている場面
Manual（設定値は default）	読み取りと、ls・cat・git statusなどの読み取り専用のコマンドだけ。編集やコマンドの前に確認する	機密性の高い作業、最初に試すとき
acceptEdits	作業フォルダの中のファイルの編集と、mkdir・mv・cpなどの基本的なコマンド	差分を後でまとめて確かめる修正
auto	確認の代わりに、分類器（操作が頼まれた内容に合っているかを点検する別のAI）が操作を実行の前に点検する	長い作業、確認の連続を減らしたいとき
plan	読み取りと調査。ファイルは書き換えない（auto モードが使える環境では、分類器が承認したコマンドも実行する）	変更の前の調査と計画
dontAsk	事前に許可した操作だけを実行し、それ以外は確認を出さずに断る	決まった作業だけを自動で回すとき
bypassPermissions	確認をほぼすべて飛ばす	壊れても困らないコンテナ（ほかから切り離したプログラムの実行環境）や仮想マシン（パソコンの中に作った仮のパソコン）の中だけ

注意したいのは、公式ドキュメントによると、対話型のターミナル（文字でコマンドを打ち込む画面）とVS Code（Microsoftのプログラムを書くための編集ソフト）では、Claude Codeの版2.1.283以降、auto モードが組み込みの開始モードになっていることです。「毎回確認してくれるはず」と思い込まず、会社で配る設定で、どのモードから始めるかを決めておきます。

実行環境を囲う仕組み

サンドボックス: AIが実行するシェルのコマンドを、OS（パソコンの基本ソフト）の機能で囲い、読み書きできるフォルダと通信できる先を制限します。Claude Codeの中で /sandbox というコマンドを打って設定します。プロンプトインジェクションでAIの判断がだまされても、サンドボックスの制限は働き続けます
作業フォルダの境界: Manual モードでは、Claude Codeのファイルの道具（ReadやEditなど）は、起動したフォルダの外のファイルを読み書きする前に人に確認します。ただし、この境界は確認の画面であり、人が承認したコマンドは、利用者のアカウントが書き込める場所ならどこにでも書けます
クラウドで動かすとき: AnthropicのクラウドでClaude Codeを動かす場合、会話ごとに隔離された仮想マシンで動き、通信は既定で制限され、GitHubの認証情報は仮想マシンに入らず、ブランチ（変更を本流から分けて進める作業の枝）の削除は拒否され、操作は監査のために記録されます

プロンプトインジェクションへの備え

curlやwgetのように外部から内容を取ってくるコマンドは、既定では自動で承認されません
WebFetch（Webページを読む機能）は、多くの場合、ページの中身を別のAIに要約させ、Claude Codeは生のページではなく要約を受け取ります
まだ信頼していないフォルダで起動すると、そのフォルダを信頼するかを尋ねる画面（ワークスペースの信頼の確認）が出ます
Manual モードでは、完全には解析できない複雑なコマンドは、許可のルールがあっても、Claude Codeが実行の前に人に確認します
Manual モードでは、どのルールにも当てはまらないコマンドは、Claude Codeが人に確認を求めます（フェイルクローズド＝迷ったら止める側に倒す設計）。auto モードでは、こうしたコマンドは分類器が判定します

秘密の情報とデータの守り

Claude Codeが使うAPIキーやトークン（ログインした状態を表す文字列）は、macOSではキーチェーン（OSの鍵の保管庫）に保存されます。Linux（サーバーなどで使われるOS）では本人だけが読めるファイルに保存されます。ただし、作業フォルダに置いた鍵のファイルは、この保管庫の外にあります
MCP（外部のサービスとClaude Codeをつなぐ仕組み）のサーバーは、自分で作るか、信頼できる提供元のものを使うよう推奨されています。リポジトリの .mcp.json（MCPのサーバーを登録する設定ファイル）だけを見ても、読み込まれる全部のサーバーは分かりません
MCPのサーバー、スキル（作業の手順書）、プラグイン（機能の追加の部品）は、どれもClaude Codeに新しい道具や指示を足すものです。外部のサービスから受け取った文章を通じたプロンプトインジェクションの入口にもなるため、入れる前に提供元を確かめ、MCPの道具ごとに mcp__サーバー名__道具名 の形で許可と禁止を書けます
VS CodeなどのIDE（プログラムを書くための編集ソフト）で使う場合も、同じ権限の設定が効きます。IDEの拡張機能そのものが改ざんされる危険もあり、claude-code-lab の記事は、2026年10月に別の編集ソフトの拡張機能の配布元で、改ざんされた拡張機能が約11時間配られた事例を挙げています
Windowsでは、WebDAV（ネットワーク越しにファイルを扱う古い仕組み）を有効にすると、権限の仕組みを迂回して外部へ通信する恐れがあるため、推奨されていません

Claude Codeの権限設定

権限の設定は、settings.json という設定ファイルに書きます。上位の記事が「設定◯選」として並べる内容の土台は、設定ファイルの置き場所、ルールの評価の順番、基本の設定、ルールの書き方の4点です。

設定ファイルの置き場所と優先順位

置き場所	効く範囲	主な使い方
管理設定（managed settings）	組織の全員。利用者もプロジェクトも上書きできない	会社として絶対に守らせる禁止と、危険なモードの封印
起動のときのコマンドの引数（claude の後ろに付ける指定）	その実行だけ	自動実行のときの一時的な指定
プロジェクトの `.claude/settings.local.json`	その人のそのプロジェクトだけ	個人の試し
プロジェクトの `.claude/settings.json`	そのリポジトリを使う全員（バージョン管理で共有）	チームで決めた許可と禁止
利用者の `~/.claude/settings.json`	その人の全プロジェクト	個人の共通の設定

設定ファイルの置き場所は、管理設定、起動のときのコマンドの引数、プロジェクトの .claude/settings.local.json、プロジェクトの .claude/settings.json、利用者の ~/.claude/settings.json の順に優先され、管理設定の禁止は、コマンドの引数でも外せません。また、どの置き場所の禁止も、別の置き場所の許可より先に効きます。

ルールは「禁止→確認→許可」の順に評価される

権限のルールには、deny（禁止）、ask（毎回確認）、allow（確認なしで許可）の3種類があり、この順に評価され、最初に当てはまったものが結果を決めます。たとえば Bash(aws *)（Bashはシェルのコマンドを実行する道具の名前で、awsはAWSを操作するコマンド）を禁止にすると、Bash(aws s3 ls) を許可に書いても実行できません。今の状態は /permissions というコマンドで一覧でき、公式ドキュメントは定期的にここで見直すよう勧めています。

上位の記事が勧める基本の設定

2026年11月時点で「Claude Code セキュリティ」と検索したときの上位10本の記事で共通して勧められている設定を、まとめると次のとおりです。

ホームディレクトリの直下で起動しない: 作業ごとに専用のフォルダを作り、機密の書類のフォルダから離す。Claude Codeを起動するアカウントに、管理者（root）の権限を与えない
危険なコマンドを禁止に入れる: 一括削除（rm -rf）、強制的な履歴の上書き（git push –force）、外部からの取得（curl・wget）など
鍵のファイルを読ませない: Read(./.env) のように、鍵を書いたファイルの読み取りを禁止する
間接的な実行の入口をふさぐ: bash -c・python -c・node -e・eval のように、別のコマンドの中から禁止のコマンドを呼べる入口を禁止する
サンドボックスを有効にし、読めるファイルと通信先を絞る
確認を飛ばすモードを封じる: 設定の項目 permissions.disableBypassPermissionsMode と、必要なら permissions.disableAutoMode を “disable” にする
念のため毎回確認したい操作を ask に入れる: 本番への反映やプッシュ（手元の変更を共有の保管場所へ送ること）など
フックで独自の検査を挟む: 操作の直前に動く PreToolUse フックで、自作の検査を実行する。設定の変更を記録・阻止する ConfigChange フックも使える
CLAUDE.mdに日本語のルールを書く: AIに毎回読ませる指示書に、触ってはいけない場所を書く
危険な作業は dev container（隔離した開発用の箱）で動かす。Anthropicは、Claude Codeの公開リポジトリ（anthropics/claude-code）の .devcontainer フォルダに、通信を既定で遮断し、許可した先とだけ通信させるファイアウォール付きの参考の構成を公開しています
会社で設定を配るときは、ここまでの設定を管理設定で強制する

管理設定の配り方は2通りあります。公式ドキュメント（サーバー管理設定のページ、2026年11月8日取得）によると、Claudeの法人向けのプランであるTeamとEnterpriseでは、Claude.aiの管理画面から設定を配る方式（サーバーで管理する設定）が使え、端末の管理の道具（MDM）が無い会社でも配れます。もう1つは、MDM（JamfやIntuneなど）で、各端末の決まった場所に設定ファイルを置く方式です。

OS	端末に置く管理設定のファイルの場所
macOS	`/Library/Application Support/ClaudeCode/managed-settings.json`
Linux	`/etc/claude-code/managed-settings.json`
Windows	`C:\Program Files\ClaudeCode\managed-settings.json`

管理設定で使う主な項目は次のとおりです。次の表のうち、allowManagedPermissionRulesOnly・allowManagedHooksOnly・allowManagedMcpServersOnly・sandbox.network.allowManagedDomainsOnly の4つの項目は、管理設定に書いたときだけ効きます。

項目	働き
`allowManagedPermissionRulesOnly: true`	管理設定の許可・禁止のルールだけを有効にし、社員が書いたルールを無視する
`allowManagedHooksOnly: true`	管理設定が配ったフック（管理設定で強制的に有効にしたプラグインのフックを含む）だけを動かし、利用者やプロジェクトのフックは動かさない
`allowManagedMcpServersOnly: true`	管理者が許可したMCPのサーバーだけを使わせる
`sandbox.network.allowManagedDomainsOnly: true`	管理設定の通信先の許可リストだけを有効にする
`permissions.disableBypassPermissionsMode: "disable"`	確認を飛ばすモードを禁止する（どの設定ファイルにも書けるが、管理設定に書くと社員が外せない）

これらを組み合わせた、管理設定の最小の形の例は次のとおりです。通信を許す先や禁止するコマンドは、会社の開発の環境に合わせて書き換えます。管理設定は社員が外せないため、全員に配る前に数人の端末で試し、開発の道具や自動の処理が止まらないかを確かめてから広げます。

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": ["Read(./.env)", "Read(./.env.*)", "Bash(rm -rf *)", "Bash(git push --force *)"],
    "ask": ["Bash(git push *)"]
  },
  "allowManagedPermissionRulesOnly": true,
  "allowManagedHooksOnly": true,
  "allowManagedMcpServersOnly": true,
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "filesystem": { "denyRead": ["~/.ssh", "~/.aws/credentials"] },
    "network": { "allowManagedDomainsOnly": true, "allowedDomains": ["github.com", "*.npmjs.org"] }
  }
}

このほか、ライブラリの乗っ取りへの備えとして、依存するライブラリの版を固定すること、npm（JavaScriptのライブラリを入れる道具）の設定ファイル（.npmrc）に min-release-age=7d と書いて公開から7日未満の版を避けることも、上位の記事で勧められています。.claudeignore というファイルで機密のファイルを除外する方法を紹介する記事もありますが、2026年11月7日時点の公式ドキュメントで読み取りを止める方法として説明されているのは、権限の Read の禁止ルールとサンドボックスの読み取りの制限です。

権限のルールの書き方

権限のルールは、「道具の名前（対象）」の形で書きます。上位の記事と公式ドキュメントの例をまとめると、次のとおりです。

書き方	当てはまる操作
`Bash`	すべてのシェルのコマンド
`Bash(npm run *)`	`npm run` で始まるコマンド（`*` は任意の続き）
`Read(./.env)`	作業フォルダの `.env` の読み取り
`Edit(/src/*/.ts)`	プロジェクトの src フォルダの下のTypeScript（プログラムの言語の1つ）のファイルの編集
`WebFetch(domain:github.com)`	github.com のページの読み込み
`mcp__サーバー名`	そのMCPのサーバーの道具すべて

通信先を絞るときは、Bash(curl http://github.com/ *) のようにコマンドの文字で絞らず、WebFetch(domain:...) のルールとサンドボックスの通信先の許可リストで絞ります。Zennの記事が指摘するとおり、コマンドの文字での絞り込みは、オプションの位置や変数の展開（実行の時点でコマンドの中の文字を別の文字に置き換える仕組み）で簡単にすり抜けられるからです。

サンドボックスの設定と抜け穴のふさぎ方

サンドボックスは、settings.json の sandbox の欄で設定します。上位の記事が勧める主な項目は次のとおりです。

項目	働き
`enabled: true`	サンドボックスを有効にする
`allowUnsandboxedCommands: false`	AIが「サンドボックスの外で実行したい」と求める抜け道（`dangerouslyDisableSandbox`）を無効にする。外で動かしてよいコマンドは `excludedCommands` に明示する
`failIfUnavailable: true`	サンドボックスが使えない環境では、囲わずに動くのではなく起動を止める
`filesystem.denyRead`	`~/.ssh` やクラウドの鍵のファイルなど、読ませないフォルダとファイル
`network.allowedDomains`	通信してよい先（GitHubや、ライブラリの配布元など）の許可リスト

ところが、サンドボックスを有効にしても、allowUnsandboxedCommands を既定のままにすると、AIが囲いの外で実行する許可を求める道が残ります。上位の記事が「禁止のルールとサンドボックスは両方そろえて初めて意味がある」と書くのは、このためです。

CLAUDE.mdの置き場所と効く範囲

AIに毎回読ませる指示書のCLAUDE.mdも、権限の設定ファイルと同じく、置き場所で効く範囲が変わります。組織の管理ポリシーの場所に置けば組織の全員に、リポジトリの ./CLAUDE.md に置けばチームの全員に、~/.claude/CLAUDE.md に置けば本人の全プロジェクトに効きます。.claude/rules/ のフォルダに、特定のファイルにだけ効くルールを分けて置くこともできます。ただし、CLAUDE.mdは「お願い」であり、AIが従わなかったときに止める力はありません。

抑止・制限・隔離の3つに分けて考える

上位の記事のうち、クラウドの導入支援の会社であるクラスメソッドの社内勉強会の資料は、守りの手段を3つに分けています。この分け方は、会社で設定を決めるときに使いやすい整理です。

分類	手段	強さ
抑止（お願いする）	CLAUDE.md、会話での指示	弱い。長い会話の要約で抜け落ちることがある
制限（ルールで止める）	権限のルール、フック	中くらい。ルールが見張っている入口だけを止める
隔離（環境ごと囲う）	サンドボックス、dev container、仮想マシン	強い。囲いの中で動くプログラムは、許した範囲の外に触れられない。ただし、Claude Codeのサンドボックスが囲うのはシェルのコマンドと、そこから起動したプログラムだけ

他人のリポジトリは、自動の実行で特に危ない

公式ドキュメントの権限のページには、上位の記事が触れていない注意があります。人が画面を見ながら使う対話型の会話では、信頼していないフォルダを開くと確認の画面が出ます。しかし、claude -p（画面なしで1回だけ実行するモード）やAgent SDK（Claude Codeを部品として組み込む開発キット）で実行すると、確認の画面が出ないまま、リポジトリに置かれたフックや環境変数の設定が使われ、.mcp.json のサーバーには承認の有無に関わらず接続されます。

取引先や社外の人から受け取ったリポジトリを、自動の処理でClaude Codeにレビューさせる場合は、公式ドキュメントが示す次の方法で、リポジトリ側の設定を読ませないようにします。

--setting-sources user を付けて、プロジェクトの設定ファイルと .mcp.json を読ませない
--bare を付けて、プロジェクトのフック・スキル・サブエージェント（作業の一部を任せる別のAI）・.mcp.json を読ませない（ただし、プロジェクトの設定ファイルの環境変数の設定は使われる）
--settings '{"disableAllHooks": true}' を付けて、その実行のフックを止める

情報漏洩とAIの学習への利用

「社内のコードをClaude Codeに渡して大丈夫か」は、会社でClaude Codeを使わせる立場の人が、まず確かめたくなる点です。公式ドキュメントのデータの使い方のページ（code.claude.com/docs/ja/data-usage、2026年11月7日取得）の要点は次のとおりです。

学習に使われるか

契約	会話のデータを新しいモデルの学習に使うか	Anthropic側の保持期間
個人向け（Free・Pro・Max・Ultra）	本人が設定で選ぶ。許可していれば使われる	許可している場合は5年間、許可していない場合は30日間
商用（Team・Enterprise・API＝プログラムから呼び出して使う契約）	商用の利用規約に従い、組織が明示的に申し込まない限り使われない	標準は30日間。条件を満たすEnterpriseでは、データを保持しない契約（ゼロデータ保持）も選べる

ところが、社員が個人のProの契約で会社のコードを扱うと、学習の設定は社員ひとりひとりの選択に委ねられます。会社のコードを扱うなら、組織で管理できるTeamかEnterpriseの契約にそろえるのが基本です。

見落としやすい2つの経路

パソコンに残る会話の記録: Claude Codeは、会話を再開できるように、会話の記録を既定で30日間、~/.claude/projects/ のフォルダの下に平文（暗号化しない文字）で保存します。期間は cleanupPeriodDays という設定で変えられます。会話に貼った鍵は、このファイルにもそのまま残ります
フィードバックの送信: /feedback（使い心地の報告）・/bug・/share のコマンドで送った会話の記録は、Anthropicで5年間保持されます。会社として止めたい場合は、DISABLE_FEEDBACK_COMMAND=1 という環境変数（プログラムに外から渡す設定の値）で、/feedback と、同じ経路で送る /bug・/share の3つのコマンドをまとめて無効にできます（Claudeが下書きするフィードバックも止まります）

渡す前に、リポジトリの中の秘密を洗い出す

Claude Codeに渡す前に、リポジトリの中に鍵やパスワードが残っていないかを確かめます。上位の記事が勧める手順は次のとおりです。

gitleaksやtruffleHog（鍵の形の文字列を探す道具）で、Git（プログラムの変更の履歴を記録する道具）の全部の履歴を調べる
見つかった鍵をコードから消し、Gitの履歴からも消す
見つかった鍵は、すぐに無効にし、新しい鍵に差し替える（履歴から消しても、一度外に出た鍵は使える状態のまま残るため）
.gitignore（Gitに記録させないファイルを書いておく設定ファイル）に鍵のファイルを入れ、コミットの前に鍵を検出して止める仕組み（pre-commit と gitleaks の組み合わせなど）を入れる

Claude Codeに渡してよいデータの範囲も、渡す前に表にしておきます。侍エンジニアの記事は、ソースコードと匿名化したテストデータは可、.env・本番のデータベースの接続情報・個人情報を含むログは不可、という例を挙げています。AIが答えを作る処理（推論）を行う地域、保持期間、監査の要件は、Anthropicと直接契約するか、Amazon BedrockやGoogle Cloudなどのクラウドを経由するかで変わるため、契約の前に確かめます。

自動セキュリティレビューとClaude Security

Claude Codeには、守りの設定とは別に、書いたコードの弱点を見つける機能もあります。上位の記事のうち3本が、この機能を扱っています。

/security-review とGitHub Actions

Anthropicのヘルプセンターの記事によると、/security-review というコマンドを実行すると、Claude Codeがコードを分析し、見つけた問題ごとに説明を返します。Claude Codeのセキュリティレビューを GitHub Actions（GitHubで自動の処理を動かす仕組み）に組み込むと、プルリクエスト（変更を取り込む前に確認を頼む依頼）が開かれるたびに、Claude Codeが自動でレビューし、懸念と修正案を行ごとのコメントで残します。検出の対象として挙げられているのは、SQLインジェクション（データベースへの命令を外から差し込む攻撃）、クロスサイトスクリプティング（Webページに悪意のある処理を埋め込む攻撃）、認証と認可の欠陥（本人の確かめ方と権限の与え方の誤り）、安全でないデータの扱い、依存するライブラリの既知の脆弱性です。侍エンジニアの記事は、コードに直接書かれた鍵（ハードコードされた認証情報）の検出も挙げています。見つかった問題は、そのままClaude Codeに修正を頼めます。/security-review の観点は自社の基準に合わせて変えられ、GitHub Actionsのほうも、リポジトリの設定から導入し、脆弱性の種類ごとの感度や、誤検知を減らす絞り込みのルールを調整できます。ヘルプセンターは、本番のコードを含むすべてのリポジトリにGitHub Actionsのレビューを入れ、大きな変更の前に /security-review を実行することを勧めています。ヘルプセンターは、この機能を既存のセキュリティの取り組みと人のレビューを補うものであり、置き換えるものではないと書いています。

Claude Security（旧 Claude Code Security）

マネーフォワード Adminaの記事（2026年10月25日確認）によると、Anthropicは2026年2月20日に、コード全体の脆弱性を調べて修正案を出す機能を「Claude Code Security」として限定公開し、2026年4月30日に「Claude Security」と名前を変えて、Enterprise向けの公開ベータにしました。

項目	Web版のClaude Security	Claude Code向けのプラグイン
動く場所	Anthropicの基盤から、GitHubなどのリポジトリにつないで調べる	利用者のClaude Codeの会話の中
使える条件	Enterpriseの契約、利用者ごとの上位の席（Enterpriseの中で上位の機能を使える利用枠）、従量課金のクレジット（使った分だけ差し引かれる利用の枠）	有料プランかAPIなど
データの保持	ゼロデータ保持には対応していない	使っているモデルの提供元との契約に従う
修正案の扱い	担当者が画面で根拠と修正案を確かめる	別のAIがレビューした修正案をファイルに保存し、自動では当てない

2026年11月8日時点のヘルプセンターの記事によると、Claude Securityでは、見つかった弱点（所見）ごとに重大度（Critical・High・Medium・Lowの4段階）が付き、所見が担当者の画面に出る前に、Claudeが自分の所見を批判的に見直す多段階の検証を通ります。Claude Securityを、既存の静的解析（プログラムを動かさずに弱点を探す検査）の置き換えではなく、ルールに基づく検査では拾いにくい、文脈に依存する弱点を探す層として足すのが、この機能を扱う上位の記事に共通する位置づけです。

企業で使う際の社内ルール

会社で使わせる立場の人が、設定の前に決めておくべきことを、公式ドキュメントの推奨と上位の記事の内容から整理します。導入の手順やプランの選び方、社内への展開の順番は、Claude Codeの料金とプランの選び方を扱う別の記事で整理しています。

決めること	公式の推奨・上位の記事の内容
守らせる設定の配り方	管理設定で組織の基準を強制し、チームで承認した権限の設定をバージョン管理で共有する
使い方の監視	OpenTelemetry（動作の記録を集める標準の仕組み）で利用状況を集める
設定の書き換えの監査	ConfigChange フックで、会話の途中の設定の変更を記録するか止める
教育	利用者にセキュリティの基本を教える
つないでよい外部のサービス	管理設定で、使ってよいMCPのサーバーを絞る
機密のリポジトリ	プロジェクトごとに権限の設定を分け、必要ならdev containerで動かす
お金	利用の上限を設定し、週に一度、使用量を確かめる
シャドーAI（会社が把握していないAIの利用）	個人の契約での業務利用を禁じ、会社の契約にそろえる

上位の記事のうち、note.comの入門記事は、最初の1か月を練習用のフォルダで過ごし、慣れてから少しずつ範囲を広げる進め方を勧めています。「優秀な新入社員でも、初日から金庫の鍵は渡さない」という例えは、社員への説明にそのまま使える言い方です。

現場でぶつかる壁と注意点

確認の連続で、人が読まなくなる

確認の画面は、多すぎると守りとして働きません。上位の記事でも「はいを連打するのが怖い」という相談が紹介されています。確認を減らすなら、確認の代わりになる層（サンドボックス、禁止のルール、分類器のルール）を先に置いてから減らします。

auto モードを信じすぎない

auto モードの分類器は、作業を進めるAIとは別のAIであり、その判定もAIの判断です。公式ドキュメントも、どの保護機能もすべての攻撃を防げるわけではないと書いています。会話の中で「確認するまでプッシュしないで」と伝えた境界は、長い会話の要約で消えることがあると、公式ドキュメント自身が注意しています。消えては困る境界は、ask か deny のルールに書きます。

設定が時間とともにずれる

AIの作業中に、Claude Codeの権限の設定が書き換わることもあります。ConfigChange フックで設定の変更を記録し、/permissions というコマンドで権限の設定を定期的に見直します。Claude Codeの版が上がると、既定のモードや設定の名前が変わることもあるため、版を上げたら公式ドキュメントの変更点を確かめます。

「今後は聞かない」の許可が積み上がる

確認の画面で「はい、今後は聞かない」を選ぶと、シェルのコマンドの許可は、そのリポジトリとコマンドの組み合わせで残り続けます。忙しいときに押した許可が積み上がり、いつの間にか広い範囲を確認なしで許している状態になります。公式ドキュメントによると、この許可は、そのリポジトリの .claude/settings.local.json というファイルに保存されます。/permissions のコマンドで一覧を開き、要らなくなった許可を消すか、このファイルの該当する行を消して、定期的に棚卸しします。

Claude Codeの利用が非エンジニアにも広がる

Claude Desktop（パソコンに入れて使うClaudeのアプリ）の登場で、ターミナルに慣れていない社員も、Claude Codeを使い始めています。非エンジニアに設定の中身をすべて理解させるのは現実的ではないため、会社の側で管理設定として配り、本人の判断に任せる範囲を小さくします。前半の「作るときから守る」の節で挙げた8つの要点は、本人が守る範囲を、この小さくした範囲に合わせたものです。

最後は人の目で確かめてからリリースする

後半で整理したとおり、Claude Codeの安全に関わる知識は、6つの権限モード、設定ファイルの置き場所と優先順位、禁止・確認・許可のルールの評価の順番、サンドボックスの抜け道のふさぎ方、フックが呼ばれる入口、MCPのサーバーの扱い、管理設定の配り方、会話の記録とデータの扱い、と広い範囲にわたります。しかも、Claude Codeは更新が速く、版が上がると、既定のモードや設定の名前が変わることがあります。

そのうえ、権限のルールも、フックも、サンドボックスも、それぞれ止められる入口と止められない入口が決まっていて、専用の道具・シェルのコマンド・スクリプトの3つの入口をすべて見張る守りはありません。ARCHECOのMacで試したとおり、書き込みの道具を止めたフックも、Bashからの書き込みでは呼ばれませんでした。会社で決めるべきなのは、設定の数ではなく、守りたいものごとに、どの入口まで、どの層で閉じるかです。本番とデータベースへの線は、人が名指しで頼んだときだけ越えられるように、運用のルールとAIの判定の仕組みの両方に同じ線を引きます。鍵は、名指しで頼まれても越えさせないように、分類器の判定に任せず、会話に入れず、権限の禁止ルールと、鍵のファイルを読み取り禁止の場所に指定したサンドボックスで、スクリプトの入口まで閉じます。役に立つのは、禁止のコマンドの長い一覧ではなく、「この会社のAIは、どの入口から何に触れられて、それぞれの入口を何が見張っているか」という入口の地図です。

これを全部知ったうえで、作る人ひとりひとりが毎回正しく運用するのは、現実には難しいことです。そこで、最後の守りとして、AIが作ったものを、作った人とは別の人が目で確かめてから（目検してから）リリースする工程を置きます。前半の5つの型に合わせると、リリースの前に人が確かめる点は次のとおりです。

AIや作ったアプリに渡した権限が、その作業に要る範囲を超えていないか（権限の与えすぎ）
消す・送る・公開する操作の前に、人の確認が入る作りになっているか（人が確認しなかった）
外から来た文章を読む部分に、強い権限と、外へデータを送る手段が同時に付いていないか（AIへの命令の差し込み）
使っている部品の版が固定され、知らない部品が入っていないか（部品の乗っ取り）
ログインしていない人から、データや保存場所が見えないか（設定ミス）

AIで作る速さは残したまま、リリースの直前にだけ人の目を挟むのが、会社でClaude Codeに開発を任せるときの、現実的な落としどころです。

AIで作り、人の目で確かめてリリースまで進める支援

ARCHECOは、AIで基礎の開発を進め、人の目で確かめてからリリースまで進める開発を支援しています。ARCHECOにこの仕事を任せる理由になりうる点は、次の4つです。

セキュリティに強いエンジニアと、エンジニアでないメンバーの両方が、AIで開発している: エンジニアでない人がつまずく所と、攻撃する側の目で見る所の両方を、社内の開発と勉強会で日常的に見ています
社内のツールのセキュリティの監査を、通常の業務として行っている: 社内で作ったツールや自社のWebサイトについて、既知の弱点、鍵の置き場所、外から見える設定などを点検する監査を、普段の仕事として回しています（監査で見つかった内容は公開していません）
作る役と確かめる役を分けている: Claude Codeが作ったものを別の会社のAIに独立して確かめさせ、最後は人が確かめます
本番は人の確認を挟む: 本番への反映と外部への送信は、人が対象を名指しで頼み、人が確かめてから行い、AIの判定の仕組みでも同じ線を引いています

AIで作る範囲を決めて小さく作り、確かめながらリリースまで進める開発は、MVP開発のページで進め方を説明しています。AIに任せた仕事を、守りと検査の仕組みで支える設計と組み立ては、ハーネスエンジニアリング（AIに仕事を任せるための守りと検査の仕組みを作る支援）のページで扱っています。

よくある質問

Claude Codeは安全に使えますか？

Claude Codeは、適切な権限の設定と運用のルールを決めれば、業務で安全に使えます。Claude Codeの提供元であるAnthropicは外部の監査の報告書（SOC 2 Type 2）と国際規格の認証（ISO 27001）を公開しており、Claude Codeには、操作の前の権限の確認、AIの実行環境を囲うサンドボックス、文書に隠された命令をAIが実行してしまう攻撃（プロンプトインジェクション）への備えなどの保護機能も最初から入っています。ただし、Claude Codeが提案した操作を承認する前に、その安全を確かめる責任は使う人にあり、AIが作ったものは、リリースの前に人の目で確かめることが前提です。

エンジニアでない人がClaude Codeでアプリを作っても大丈夫ですか？

エンジニアでない人でも、Claude Codeでアプリを作ること自体はできます。ただし、画面で動くことと、外から攻撃されても安全であることは別のため、専用のフォルダで起動する、鍵を会話に貼らない、消す・送る操作を毎回確認にする、といった決まりを守ったうえで、公開する前にセキュリティに詳しい人に確かめてもらうことが前提です。

AIが作ったアプリの安全は、AIに確かめさせれば足りますか？

AIに確かめさせることは役に立ちますが、それだけでは足りません。Claude Codeの提供元であるAnthropicの技術者も、AIは自分の作ったものを甘く評価しがちだと書いています。確かめる役を作る役とは別のAIに分け、最後は人の目で確かめてからリリースします。

Claude Codeで情報漏洩は起きますか？

Claude Codeの設定と運用を誤ると、情報漏洩は起きえます。Claude Codeで情報漏洩が起きる主な経路は、鍵（パスワードやAPIキーなど、外部のサービスを使うための秘密の文字列）を書いたファイルをAIに読ませる、会話に鍵を貼る、読み込んだWebページに隠れた命令をAIが実行する、の3つです。情報漏洩を防ぐには、鍵のファイルを作業フォルダの外に置き、読み取りの禁止ルールと、AIの実行環境を囲うサンドボックスの読み取りの制限を両方入れ、AIが通信してよい先を絞ります。

入力したデータはAIの学習に使われますか？

AnthropicのTeam・Enterprise・APIの商用の契約では、2026年11月7日時点の公式ドキュメントによると、Claude Codeに入力したデータは、組織が明示的に申し込まない限りAIの学習に使われません。Claudeの個人向けのプラン（Free・Pro・Max・Ultra）では、入力したデータを学習に使わせるかを本人が設定で選べ、許可していればAIの学習に使われます。会社のコードを扱うなら、組織で管理できる商用の契約にそろえるのが基本です。

社内のコードをClaude Codeで扱っても大丈夫ですか？

Claudeの商用の契約（Team・Enterprise・API）で、プロジェクトごとの権限の設定と、AIの実行環境を囲うサンドボックスを使えば、社内のコードをClaude Codeで扱えます。機密性の高いリポジトリ（プログラムのファイル一式と変更の履歴を入れた保管場所）を扱うときは、Claude Codeをdev container（隔離した開発用の環境）や仮想マシンの中で動かします。データを保持しない契約（ゼロデータ保持）が必要なら、条件を満たすEnterpriseの契約で選べるかを確かめます。

Claude Codeの権限設定はどこで変えますか？

Claude Codeの権限設定は、settings.json という設定ファイルで変えます。権限の設定ファイルの置き場所には、組織の管理設定（組織の全員に効き、利用者が上書きできない設定。端末に置く場合のファイル名は managed-settings.json で、TeamとEnterpriseではClaude.aiの管理画面から設定を配る方式もあります）、プロジェクトの .claude/settings.json、利用者の ~/.claude/settings.json などがあり、この中では管理設定が最も強く効きます。Claude Codeの今の権限の状態は、/permissions というコマンドで確かめられます。

Claude Codeの auto モードは安全ですか？

Claude Codeの auto モードは、作業を進めるAIとは別のAI（分類器）が操作を実行の前に点検するため、確認なしで進めるモードの中では守りがあるほうです。ただし、分類器の判断も完璧ではないため、本番やデータベースへの操作のうち、毎回人が確かめたいものは ask（毎回確認）、どんな指示でも実行させないものは管理設定の deny（禁止）の権限のルールに書きます。組織で auto モードを使わせたくない場合は、管理設定（組織の全員に効き、利用者が上書きできない設定）の permissions.disableAutoMode を “disable” にします。

Claude Codeの –dangerously-skip-permissions は使ってよいですか？

–dangerously-skip-permissions は、原則として使いません。このオプションは、確認をほぼすべて飛ばす bypassPermissions モードと同じです。Claude Codeの公式ドキュメントは、このオプションを、壊れても困らないコンテナ（ほかから切り離したプログラムの実行環境）や仮想マシンの中だけで使うよう書いています。会社では、管理設定（組織の全員に効き、利用者が上書きできない設定）の permissions.disableBypassPermissionsMode で、このオプションを封じます。

.envをClaude Codeに読ませないにはどうすればいいですか？

Claude Codeの権限の Read の禁止ルール（ファイルの読み取りを禁じるルール）で .env を指定し、AIの実行環境を囲うサンドボックスでも、同じファイルの読み取りを禁止します。禁止ルールだけでは、スクリプト（短いプログラム）の中からファイルを開く読み方を止められないためです。そもそも鍵の値を .env に書かず、OSの鍵の保管庫や鍵の管理サービスから読み込む方法もあります。

Claude Codeはセキュリティレビューに使えますか？

Claude Codeは、セキュリティレビューに使えます。/security-review というコマンドで手元の変更を調べられ、GitHubで自動の処理を動かす仕組み（GitHub Actions）に組み込むと、変更を取り込む前の確認の依頼（プルリクエスト）ごとに自動でレビューできます。コード全体の脆弱性を調べるClaude Security（2026年11月時点ではEnterprise向けの公開ベータ）もあります。これらの機能はどれも、既存のセキュリティの検査と人のレビューを補うもので、置き換えるものではありません。

Claude Code Securityとは何ですか？

Claude Code Securityは、2026年2月20日にAnthropicが限定公開として発表した、コード全体の脆弱性を調べて修正案を出す機能です。Claude Code Securityは、その後「Claude Security」と名前を変え、2026年11月8日時点のヘルプセンターでは、Enterprise向けの公開ベータと案内されています。Web版のClaude Securityを使うには、Enterpriseの契約、利用者ごとの上位の席（プレミアムシート）、従量課金のクレジット（使った分だけ差し引かれる利用の枠）が要ります。Claude Securityには、Claude Codeの中で動くプラグイン版もあります。

他人のリポジトリをClaude Codeで開くと何が危険ですか？

他人のリポジトリに置かれたCLAUDE.md（AIに毎回読ませる指示書）・フック（AIの操作の前後に自動で動く検査）・MCP（外部のサービスとつなぐ仕組み）のサーバーの設定に、悪意のある命令が含まれている場合があります。対話型の会話では信頼の確認が出ますが、claude -p（画面なしで1回だけ実行するモード）や Agent SDK（Claude Codeを部品として組み込む開発キット）の自動の実行では、リポジトリ側のフックや設定の一部が、確認が出ないまま使われます。Claude Codeを自動で実行するときは、起動のオプションの --setting-sources user を付けて、プロジェクトの設定ファイルと .mcp.json を読ませないようにします（--bare もフックと .mcp.json を読ませませんが、プロジェクトの環境変数の設定は使われます）。

会社でClaude Codeを使うときの社内ルールは何を決めればいいですか？

会社でClaude Codeを使うときに社内ルールで決めることは、配る設定（組織の全員に効き、利用者が上書きできない管理設定で、危険なコマンドの禁止と、確認をほぼすべて飛ばすモードの封印を強制する）、使い方の監視、設定の書き換えの監査、利用者への教育、つないでよい外部のサービス、機密のリポジトリ（プログラムのファイル一式と変更の履歴を入れた保管場所）の扱い、使用量の上限と確認の頻度、個人の契約での業務利用の禁止（会社の契約にそろえる）の8つです。Claude Codeの設定は、守りたいものごとに、AIがファイルに触れる入口（専用の道具・シェルのコマンド・スクリプト）のどこまでを閉じるかで決めます。