T45_Claude Codeをユーザーフォルダ全体で起動していた。YouTubeで学んで、ゾッとした話。
Claude Codeで記事を書く。PowerPointを作る。Skillsを作る。
作業フォルダは指定していました。気をつけているつもりでした。
でも、Claude Code自体の設定をするとき——ユーザーフォルダ全体で起動していました。
「気をつけていた」はずが、盲点があった
私は元々、慎重な性格です。
以前、楽天カードを不正利用された経験があります。
この経験から、セキュリティへの意識は人一倍高いと思っています。
だから、Claude Codeを使い始めたときも、note記事の作成やPowerPoint作成は、OneDrive内のClaude Code専用フォルダを指定して進めていました。
気をつけているつもりでした。
ただ、Claude Code自体の設定作業——statuslineの表示を整えたり、モデルの表示を調整したりするとき——は、ユーザーフォルダ全体で起動していました。
無自覚に、です。
「新しい技術に慣れていこう」という気持ちが少し先走って、Claude CodeがPC全体にアクセスできるという点への警戒が、薄れていました。
Claude Codeは、文章を返すだけのAIではありません。
ファイルを読み、書き換え、コマンドを実行できます。
それがユーザーフォルダ全体にアクセスできる状態で動いていた。
YouTubeでセキュリティの動画を見続けるうちに、その意味が体感としてわかったとき、ゾッとしました。
幸いだったのは、ネットワークを使う設定やAPIを使う運用には、まだ手を出していなかったことです。
でも、「何も起きなかった」は「安全だった」ではない。
そう気づいたことが、この記事を書くきっかけになりました。
Claude Codeで実際に起きた3つの事故パターン
「それで、何が危ないの?」
具体的な事故パターンを3つ整理します。
① 削除の暴走
「いらないフォルダを消して」と頼んだら、想定より広い範囲が削除されてしまう事故があります。
Claude Codeは、指示の解釈を広げることがあります。
特に `rm -rf` のような削除系コマンドは、一瞬で取り返しのつかない状態になります。
だからこそ、重要なデータの近くで起動しないことが、最初の防御になります。
② 秘密情報の流出
`.env` ファイルや認証情報のそばで作業していると、「全部まとめて」という指示の対象に秘密情報が含まれてしまうことがあります。
学校のデータや個人情報でも同じことが起きえます。
ユーザーフォルダで起動するということは、そういったファイルへのアクセス権を渡している状態です。
③ Yes連打による確認スキップ
Claude Codeに慣れてくると、確認画面を深く読まずに進めるようになります。
お、できるじゃん。これも任せよう。まあ大丈夫だろう。Yes。Yes。Yes。
この流れが危ない。
便利ツールは、慣れた頃に事故ります。
自転車の話に置き換えると分かりやすいかもしれません。補助輪が外れた直後は慎重に走るのに、乗り慣れた頃に転ぶのと同じです。「大丈夫だろう」という感覚が、判断を狂わせます。
Claude Codeも同じです。
第一防衛ラインは、設定より「起動場所」だった
Claude Codeの安全対策というと、細かい設定の話になりがちです。
でも私が一番効いたと感じたのは、もっとシンプルなことでした。
どのフォルダで起動するか。それだけです。
Claude Codeを、職員室の金庫の前で起動しない。
まずは空き教室で作業させる。
「空き教室」は、専用の作業フォルダです。
「金庫」は、学校データや個人情報、APIキーが入っている場所です。
私が今使っているのは、OneDrive内に作ったClaude Code専用フォルダです。
OneDrive
└─ Claude_Code_Work
├─ 00_reference
├─ 10_work
├─ 20_output
└─ 90_archive起動するときは、このフォルダを作業場所として指定します。
逆に、次の場所では起動しません。
OneDrive全体
Documents / Desktop / Downloads
学校データ・成績・名簿があるフォルダ
APIキーや `.env` があるフォルダ
あなたのClaude Codeは今、どのフォルダで起動していますか?
整えた3つのブレーキ
空き教室を確保しただけでは、まだ半分です。次は、その教室に「ここでは火気厳禁」「この棚は触るな」というルールを貼り出す作業があります。
起動場所を限定したうえで、技術的なブレーキを3つ整えました。
① settings.jsonで危険操作に制限をかける
settings.jsonは、Claude Codeの動作に制限をかける設定ファイルです。
次のような操作を、denyまたはaskに設定しています。
削除系コマンド(`rm -rf`、`Remove-Item` など)
外部通信(`curl`、`Invoke-WebRequest` など)
`.env` や credentials の読み取り
`git push`
`npm install` / `pip install`
settings.jsonはサンドボックスではありません。
あくまで「事故りにくくする、技術的なブレーキ」です。
② CLAUDE.mdに自然言語の作業ルールを書く
settings.jsonが技術的なブレーキなら、CLAUDE.mdは作業時の判断基準です。
私は次のような内容を書いています。
このプロジェクトフォルダ外のファイルを読む・変更する必要がある場合は、
必ず事前に理由を説明し、ユーザーの許可を得ること。
学校データ、個人情報、APIキー、.env にはアクセスしないこと。
作業は原則Plan Modeで進め、実行前に計画を提示すること。役割分担はこうです。
settings.json:技術的な制限
CLAUDE.md :作業時の判断基準・行動方針③ Plan Modeでいきなり実行させない
第一段階では、Plan Mode中心で進めています。
作業前に、次を確認させます。
作業目的
読むファイル
変更するファイル
実行するコマンド
危険操作の有無
指示の例はこうです。
まず実装せず、計画だけ出してください。
どのファイルを読むか、どのファイルを変更するか、
実行するコマンドがあれば事前に説明してください。
私が承認するまで実行しないでください。これは、仕事で言えば「決裁前に稟議を見る」ようなものです。
いきなり実行させない。それだけで、安心感がかなり変わります。
Windows Nativeは「ダメ」じゃない。普段使いの作業机でいい。
「Windows Native」とは、今使っているWindowsパソコンをそのまま使う環境のことです。
Claude Codeの安全対策を調べると、DockerやWSL2という言葉が出てきます。これらはClaude Codeを他のファイルから完全に切り離す「鍵付きの実験室」を作る技術です。セキュリティ面では理想的ですが、設定に手間がかかり、非エンジニアには最初のハードルが高い。
だから私は、最初からそこへは行きませんでした。
Windows Nativeは、普段使いの作業机。
WSL2 / Docker / Dev Containerは、実験室。
私が第一段階でやっていること——
note記事の作成
Markdownの整理
PowerPointの下書き
ポスター案の作成
Claude Code Skillsの試作
この範囲なら、Windows Nativeで十分始められます。
道具は、使いながら増やすもの。最初から全部揃えようとすると、準備で力尽きます。
いきなりDockerを勧めるのは、ラーメンを食べたい人に「まず小麦を育てましょう」と言うくらい遠い話です——そう感じる人には、まずWindows Nativeで始めることをお勧めします。
怖い。でも使いたい。だからこう始める。
Claude Codeの安全運用は、完璧な知識を揃えてからやるものではありません。
今の自分に合った範囲で始めて、少しずつ広げていくものだと思っています。
私はまだ第一段階にいます。
でも、起動場所を絞り、設定を整え、Plan Modeを使うようにしてから、気持ちが変わりました。
Claude Codeは、怖がるだけではもったいない。
でも、雑に任せるには強すぎる。
まずは、安全な作業場を作るところから始めてみてください。
今日できることは3つです。
Claude Codeの起動フォルダを、専用フォルダひとつに絞る
settings.jsonに削除・外部通信の制限を入れる
初めての作業はPlan Modeで確認してから実行する

この3つを整えたとき、あの「ゾッとした」感覚が、ようやく「気をつけてよかった」に変わりました。
この記事は、Claude Code安全運用の「第一段階」を整理したものです。
ネットワーク・API・外部通信を使う「第二段階」は、別記事で書きます。
いいなと思ったら応援しよう!
チップ一枚の魔法、ライターが泣いて喜びます!