Claude Code 情報漏洩対策は何から始めるか、飯塚浩也さんの5つの防御を動画の順に追う

出典: 【徹底解説】Claude Code×Obsidianの情報漏洩対策！今すぐやるべきAIセキュリティ構築術

読まないで、と CLAUDE.md に書いておけば、AIはそのファイルを読まないのか。Claude Code を仕事で使い始めると、まずここが気になりますよね。この章は、その問いから始まります。

話の入口は、事故の話。飯塚さんは、AIエージェントを仕事で使えば個人情報は必ず絡み、実際に事故が少なくないと話します。

飯塚さん（動画 0:33〜）

いや、現に事故が結構起きてるんですよ。

Obsidian と Claude Code や Codex を使う人は事故のリスクが高い、という話が続きます。理由も挙がりますよ。

会社やお客さんの情報を、ローカルに貯めること。作った物を、外へ公開しがちなこと。探索が得意で、読んではいけない情報まで読んでしまうこと。この並びです。

やり取りの相手が、ルールファイルを使えば防げるのでは、と問いかけます。

飯塚さん（動画 2:21〜）

あれ書けばいいじゃん。違う。そんな甘くない。

答えは、ルールを書いても、AIがそれを越えて読んでしまうことがある、というもの。

さらに、Web クリッパーの例も出てきます。他人の文章を取り込む時、その文章が悪質だと、取り込んだ瞬間に攻撃されることがある、という話です。

飯塚さん（動画 2:42〜）

その文章の中に白い文字で目立たないように攻撃の指令が書いてあるわけですね。

でね、取り込んだ文章を Claude Code が読んで、そのまま実行してしまうことまで起こりうるって。

パソコンの乗っ取りや、意図しない動きで重要なファイルを読む例も、同じ並びで挙がります。

ここでホワイトボードに移ります。出てくるのが、スイスチーズモデル！穴の開いた板を何枚も重ねて、全部の穴をすり抜けた時だけ事故になる、という考え方です。

飯塚さん（動画 4:04〜）

つまりは私たちがAIエージェントでこうしたセキュリティ対策をする上で1つだけじゃなくて何層にも防御することは大事ですよ。これが基本の考え方になります。

正直、この章の芯は、書いたルールだけを頼りにしない、という一点。ただ、書くこと自体が無駄なわけではありません。1枚目の板としては、ちゃんと要ります！

委ねた先が嘘をついたり、逃げたり、やらなかったりしたら？私は、そこへは委ねられません。だから、信頼できる仕組みが先なんですよね。

2026年7月22日、私が管理する Gemini API で、身に覚えのない利用が見つかりました。

発生していた時間は約30分でした。リクエストは合計722件ありました。中身は、私の業務とは関係のない、画像や動画、音楽の生成で。調べて最も確度が高いと判断した経路は、鍵を示す環境変数が、Git で追跡される設定ファイルに入っていたことでした。

ただし、どこから第三者へ渡ったかまでは、立証できていません。

ルールに書いたかどうかではなく、鍵がどこに置いてあったか、の話ですよ。

私の記事より（CLAUDE.mdの置き場所とルールを決めると、Claude Codeで作ってもファイルが散らからない・CLAUDE.mdは必ず守られるわけではない、の段落の節）

CLAUDE.mdは、書いたから必ず守られるというものではない。

あ、これは動画の、それほど単純ではない、という答えと同じ向きです。書いた決まりはAIへのお願いで、扉の鍵とは別物なんですよね。

動画が話しているのは、ルールを書くだけでは足りない、という広い話です。私の記録は、鍵の置かれた場所が入口になりうる、という狭い話です。

ご自分の仕事場で、書いてあるだけで止まっている決まりは、いくつありますか？

ホワイトボードに、5つの防御が並びます。まず手を付けるのは、AIに読ませない場所に置くこと？それとも、読ませない札を立てることなのか、順番が気になる所です。

ホワイトボードには、①から⑤の丸数字。置き場所、パーミッション、サンドボックス、フック、運用の順です。

1つ目は置き場所です。秘密にしたい情報は、AIが読み取れる場所に置かない、という話ですよ。

飯塚さん（動画 4:19〜）

まず置き場所。これは秘密情報とか非常に重要な情報をAIが読み取れる場所に置かないってことですね。例えるなら自分の金庫を誰でも入れるような部屋に置かないのと同じですね。

決して漏らせない物は、Obsidian の外に置いて、Claude Code から読み取れないようにします。

2つ目はパーミッション。飯塚さんは、立ち入り禁止の札のような物、と例えます。

飯塚さん（動画 4:46〜）

ここは立ち入り禁止ですよっていうような、そうした札みたいなものですね。

settings.json という設定の場所に、許可することと禁止することを書けば、Claude Code がそのファイルを読んだり編集したりするのを防げる、という説明です。

3つ目はサンドボックスで、例えは公園の柵。4つ目のフックはプロンプトを送る時の警備員、5つ目の運用は機密を入れさせない決まりにたとえられます。

5つのうち、パーミッション・サンドボックス・フックはAIエージェントで設定し、置き場所と運用は人間が主体になる、という分け方です。

いやー、ここからが実演。画面では、架空の打ち合わせメモが入ったフォルダが、Obsidian の保管庫の中にあります。

何も対策せずに Claude Code を動かすと、連絡先や、秘密にすると約束した情報が漏れうる、と説明されます。

飯塚さん（動画 7:57〜）

この状態で何の対策もなくクロードコードを動かしてしまうとこの連絡先っていう情報を漏らしたりとか他者と契約書で秘密にしといてねっていう契約を交わしたのに漏れてしまったとか起こりうるので気をつけなきゃいけないんですね。

まず手を付けるのは置き場所ですね。フォルダを保管庫の外、デスクトップへ移します。

それでも、中身を要約して、と頼むと、Claude Code は読んでしまうんです！

で、次はパーミッションの出番ですよ。

設定ファイルに、そのフォルダを読む・編集することを禁じる設定を書き、Claude Code をいったん閉じて、あらためて立ち上げます。

同じ指示を出すと、画面にブロックされています、と出ます！飯塚さんは、これをパーミッションの威力だと話しますね。

飯塚さん（動画 10:29〜）

これがパーミッションの威力ですね。ただしReadとEditってこれクロードコードが実行するコマンドなんですけど、もうパソコン内蔵されてるコマンドは実行できちゃうんですね。

ただし、パーミッションが止めるのは Claude Code の命令まで。

パソコンに内蔵されたコマンドを使う Python のプログラムは、そのまま動いてしまう、と話は次の防御へ進みます。

5つを一度に並べ、どこに何を置くかを見せてくれる所が、この章の良さ。場所を動かしただけでは、頼めば読めてしまう、という実演まで付いています！

読ませない場所を決める話に合わせて、私の側の記録も置いておきます。

2026年10月9日、私は、AIにパスワードなどを直接見られない形で、うまく設定もしやすくしたい、と書きました。

同じ日に、ログイン情報をブラウザに入れて保存するやり方が使いやすかった、とも書いていて。鍵の管理画面を、ローカル限定で、セキュリティ万全に、でも管理しやすく作ってはどうか、とも書きました。

10月11日には、鍵のページを何個も作らず1個にまとめてほしい、鍵を預ける場所に全部集約できないか、と書いています。

私の記事より（Gemini APIキー漏洩で722件の不正利用。Googleへの対応までAIに委ねて分かったこと・主権は渡さない、の段落の節）

AIへ対応を任せても、主権まで渡す必要はない。

置き場所を決める役目まで、AIに渡さなくていいんですよね。任せるのは手間で、どこに何を置くかを決めるのは私。

動画は、読ませない場所を決める話です。私の記録は、鍵を置く場所を1つに絞る話です。

どちらも、置き場所が少ないほど守る所も少なくて済む、という点が近いかな。

場所を動かしても、頼めば読める状態。だから、札の出番です。

ここまでで、置き場所とパーミッションを使い、AIに読ませない設定はできました。でも、穴はまだ2つ残っています。パソコンに入っているコマンドと、自分で打つプロンプト。ここは、どう止めるんでしょう？

パーミッションで止められなかったのは、パソコンに内蔵されたコマンドを使うプログラムでした。それを防ぐのがサンドボックスだ、と飯塚さんは話します。

飯塚さん（動画 10:56〜）

こうしたプログラムとかコマンドとかを防ぐために設定するのがサンドボックスになります。

設定の場所は、さっきと同じ設定ファイルです。

パーミッションの下にサンドボックスの項目を足し、有効にする設定と、読み取りを拒否する場所を書きます。そのフォルダの周りに柵が付く、という説明。

難しい設定なので、画面を見ながら一緒に操作するのがよさそう、とやり取りが続きます。

実演では、Claude Code を一度閉じて開き直し、スクリプトを実行してノートを整形して、と頼みます。サンドボックスに弾かれれば成功です。

で、画面に出たのは、読み取りの拒否リストに入っているので読まなかった、という返事。OSのレベルで止まった、と飯塚さんは話します。

飯塚さん（動画 12:17〜）

読み取り拒否リストに含めているため読みませんでしたよと。OSレベルでブロックされたと。

これで3つ目の防御が完了。やり取りの相手は、完璧そうですね、と返します。ところが、話は、まだまだ、と進むんです！

理由は、人のうっかり。プロンプトに個人情報を書いてしまえば、それだけでアウトです。だから、送る前に止める役が要る、と話は続きます。

飯塚さん（動画 12:51〜）

なのでこうしたプロンプト送った時にクロードコードに送る前に止めてくれる警備員のようなそれ危ないよって言ってくれるような設定をフックでしてあげるんですね。

フックは2つ。1つ目は、ユーザーがプロンプトを送る前に動くもの。

2つ目は、Claude Code がファイルを開く直前に動いて、その動きを先に止めるものです。

飯塚さん（動画 13:25〜）

なので今回のようにプロンプトを入力する前にちゃんと防いでくれるような処理を行うことができます。そしてPreToolUseフック。これはクロードコードが例えばファイルを開く直前に何かをするとなのでクロードコードの動きを事前に止めるとそうした防御策ですね。

設定ファイルにフックの項目を作り、Python のプログラムを呼ぶ形です。顧客の名前や会社の名前がプロンプトに入っていたら止める、という中身。

実演では、Claude Code を開き直して、さっきと同じプロンプトを打ちます。

画面には、操作がブロックされた、と出ました！これで4つ目の防御まで終わり。

この章のいちばんの見どころは、穴の位置が違う板を重ねていることです。

パーミッションで止まらない所をサンドボックスで囲い、それでも残る人のうっかりをフックで止めます。スイスチーズモデルそのもの。

正直、こういう話は、止まった所だけを見て安心しがちなんですよね。私は、起きた事と、まだ確かめていない事、失敗した事を分けて、ごまかさずに見たいんです。

実は、2026年10月10日の夕方に、使い捨てのフォルダで、AIを使って Claude Code のサンドボックス（/sandbox）を付けて試しています。各操作は1回ずつです。ホーム直下にファイルを1つ作る操作は、Operation not permitted で止まりました。

外のサイトへの接続も、終了コード6で停止。一方で、囲いの外に置いた、秘密のない試験用のメモは、囲いがあっても読めました。そのフォルダの読み取りを止める設定を足すと、シェルの cat は停止。でも、Read ツールでは、同じメモが読めたんです。このとき、権限ルールは足していません。

同じ日、認証情報を守るフックが、AIの操作を2回止めました。1回目は、判定結果をファイルへ書き出そうとした時。

2回目は、コマンドの文字列に秘密のファイルの置き場所を入れただけで止まりました。

AIはどちらも迂回せず、止まった出力を証拠にしました。動画のデモと同じ設定だったかは、分かりません。

私の記事より（Claude Codeのsandboxで止まる操作と止まらない操作。ウェブ職TVの動画を見て、私のMacで確かめた・書けないことと読めないことは別、の段落の節）

書けないことと読めないことは別。止めたい操作が止まる所まで見て、初めて委ねる範囲を決められます。

書けない設定が入っていても、読めないとは限りません。だから、止まる所まで見てから決めたいんですよね。

動画も、弾かれたら成功、と実際に打って確かめていました。止めたい操作を打ち、止まる所を見てから任せます。ここは同じ向きです！

違いも1つ。私が公開済みの記事で確かめた公式の記載では、囲いの対象はシェルのコマンドです。Read などは、権限ルールで決まります。

フックとローカルの MCP は、囲いの外で動くもの。だから、動画のサンドボックスは、シェルを通る操作の話です。

囲いだけで、AIが何も読めなくなる？そうではないんです。穴の位置が違うからこそ、パーミッションと重ねる意味が出てきます。

フックも、見ている向きが違います。動画のフックが見ているのは、人が書くプロンプトの中の個人情報。私の記録のフックが見ていたのは、AIの操作のほう。

私なら、囲いやフックを足したら、止めたい操作を自分の手で1つ打って、止まる所まで見てから、任せる範囲を決めます。

ここまでで、防御は4つ。最後の運用を足すと5つになります。全部を自分で用意するとなると、ちょっと大変そうですよね。では、どこまでAIに任せていいのか？

最後の防御は、運用。個人情報はマスクできる、と話は始まります。飯塚さん自身は、ローカルのAIを役立てて使っている、と言います。

飯塚さん（動画 14:46〜）

個人情報をマスクするということはできると思うんですけど、ローカルLLMが個人的に便利だと思って私は使ってるんですね。具体的にはこちらOllamaというデスクトップサービスになるんですけど、これと最近クロードコードが連携するようになったんですね。

画面では、Claude Code のデスクトップの見た目のまま、裏側で Ollama が動いている場面が出ます。

ローカルに閉じたまま動かせる、という説明。

5つもあると大変そうに見えます。ただ、②から④、つまりパーミッションからフックまでは、AIエージェントと相談しながら作れる、という話。

飯塚さん（動画 15:30〜）

今回はお見せしたデモのこうしたスクリプトとかこれらもクロードコードに書かせたものになります。ま、なので②③④あたりはAIエージェントに書かして大丈夫だと思います。

実演で見せた設定のプログラムも、Claude Code に書かせたものでした。1つずつエディタで書かなくていいんですね、ってやり取りの相手も返します。

置き場所と運用は、人が主体で行う防御。AIに書かせてよい部分と、人が持つ部分が、ここではっきり分かれます。

まとめも同じ筋です。学習に使わない設定だけでは足りず、CLAUDE.md に読まないでと書くだけでも不十分。

大事なのは複数の防御を重ねること、と飯塚さんは話します。

順番は、まず読ませてはいけない情報を、AIが読めない場所へ移すところから。次にパーミッション。

サンドボックスで囲い、フックで人のうっかりを止めて、最後に運用でカバーします。

動画の最後には、アフタートーク。守るには、攻める側の目が要る、と飯塚さんは話します。

飯塚さん（動画 18:01〜）

なんで攻撃者の視点を持たないと防御できないなと。

そして、今日紹介した防御だけでも足りず、完璧なセキュリティは無い、と続きます。穴は必ずあって、それが優秀なAIに突破されるのが怖い、という話。

飯塚さん（動画 18:38〜）

セキュリティに完璧っていうのは必ずなくて、穴は必ずあって、で、それが優秀なAIモデルによって突破されてしまうっていうのが怖いっすよね。

この章の見どころは、AIに書かせてよい所と、人が持つ所を分けてくれること。そして最後に、完璧は無い、と言い切ってくれることです！

いやー、ここは私の判断の軸と重なるんですよね。分からないことは憶測しないで聞き、分かることは2度聞かない、という軸です。

2026年10月10日時点で、AIに任せるログイン台帳は58サービスありました。動作確認済みは3、まだ一度も測っていないものは46です。

一覧が出ることと、使えると確かめたことは別。そう書いていました。ちなみにこれは漏洩対策ではなく、ログインを保つための仕組みです。

7月の鍵の事故対応でも、AIには、判断以外の重い実務を広く引き取ってもらいました。

それでも、事実認定・秘密値・外部送信・設定変更を決める権利は、人の側に置いたまま。

私の記事より（パスワード変更は無意味？西尾素己さんの話を、AIに任せる私の鍵の数え方で読む・委ねられる理由、の段落の節）

委ねられる理由を、AIを信じる気持ちだけに置かない。数えて、止めて、AIに任せます。

AIを信じているから任せる、だけでは足りないんですよね。動画が、AIに書かせてよい、と言う②から④の防御も同じだと思います。

書かせた後に、止まるかを数えるところまで。そこまで含めて、初めて委ねられるんです！

違いを言うと、動画は防御の設定をAIに書かせてよい、という広い話。私の記録は、書かせた物が動くかを数えて確かめる、という狭い話です。

完璧が無いからこそ、数え続けるんですよね。

私なら、設定はAIに書かせても、置き場所と最後の決定は自分で持ち、止まるかを数え続けます。

動画は、ルールファイルだけでは足りないという話から始まります。

そこから置き場所とパーミッション、サンドボックスとフック、最後に運用とAIに書かせてよい範囲へと、順に進みます。

私が持ち帰ったのは、読み分けです！飯塚さんが画面で話した設定の書き方と、私が公開済みの記事で確かめた範囲を、分けて読むこと。

確かめた所だけを、事実として書くこと。

防御は、1枚に頼らず重ねる道具です。止めたい操作が本当に止まる所まで、自分の目で見る役目。そこは、私が持ち続けます！

今、Claude Code に読ませているフォルダの中に、漏れては困るものが入っていませんか？