T45_Claude Codeをユーザーフォルダ全体で起動していた。YouTubeで学んで、ゾッとした話。

シンパクト和先生

2026年5月3日 16:59

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・外部通信を使う「第二段階」は、別記事で書きます。