Claude Codeにファイルを触らせる基本|どこまで任せて、どこで止めるか
Claude Codeでファイルを安全に編集するために、作業フォルダの選び方と上書き防止、確認を挟む操作の線引きを具体例で説明します。
結論から言うと、安全に任せるコツは3つの層でできています。①触ってよい作業フォルダを絞る。②権限モード(=確認の回数を決める設定)を仕事に合わせる。③戻しにくい操作・外へ影響する操作だけ人が止める。
全部を毎回確認する必要はありません。戻せる変更は任せて、戻しにくい操作の前だけ人が判断します。ただし「これさえ守れば何も起きない」という魔法の設定はありません。公式ドキュメントも、承認する内容を確認するのは利用者の責任だと説明しています(Security)。この記事では、公式の仕様を根拠にしながら、初心者がそのまま真似できる形で線引きを説明します。
作業フォルダは「今回の仕事の箱」まで絞る
Claude Codeを開く場所は、今回の仕事に使うファイルだけが入ったフォルダにします。パソコン全体や、写真・仕事・家族の書類が混ざった場所から始めるのは避けます。
これは気分の問題ではなく、仕組みに合わせた選び方です。公式の説明では、Claude Codeは起動したフォルダとその下(配下)を書き込みの境界にします。親フォルダ(1つ上の階層)を変更するには、別に明示的な許可が必要です(Security)。つまり「開いた場所=任せる範囲」なので、開く場所を狭くするほど、事故の起きる範囲も狭くなります。
注意点が1つあります。**「フォルダの外は一切見えない」わけではありません。**範囲の外のファイルも、承認すれば読めます。また --add-dir や /add-dir という指定で、作業できるフォルダを後から追加もできます(Configure permissions)。だからこそ、原本・秘密情報(パスワードや顧客の資料)・家族の書類は、最初から作業フォルダに入れないのが確実です。
進め方は次の順です。
- 今回の仕事のフォルダを1つ用意する(例: ブログなら、ブログのフォルダ)。
- 元に戻せないファイル(完成原稿・契約書・一つしかない写真)は、そのフォルダの外へ移す。作業にはコピーを使う。
- Claude Codeをそのフォルダで起動する。
- 最初の指示は「まず中身を読み、変更予定のファイル名を教えてください。まだ編集しないでください」にする。
返ってきたファイル名が合ってから編集を頼めば、場所違いを早い段階で見つけられます。自分の場合は、完成原稿と下書きを同じフォルダに置いて、どちらを直すか分からなくなり作業が止まったことがあります。ファイル名を工夫するより、完成原稿を別の保管場所へ移す方が迷いませんでした。
起動直後に「いまいる場所」と成功条件を確認する
作業フォルダを用意したら、Claude Codeを起動する前にターミナル(=文字で命令を入力する画面)で現在地を確認します。WindowsのPowerShellなら Get-Location、macOS・Linux・WSLなら pwd と入力します。表示されたパスの最後が、今回用意したフォルダ名になっていることを見てから claude を実行します。公式Quickstartも、先にプロジェクトのディレクトリへ移動し、それからClaude Codeを起動する順序を案内しています(Quickstart)。
cd C:\work\my-blog
Get-Location
claude
起動後は、いきなり「全部直して」と頼まず、まず次のように入力します。
このフォルダの目的と主なファイルを調べてください。
まだ編集せず、今回変更が必要だと思うファイル名、変更理由、確認方法を一覧にしてください。
成功の目印は、回答に出る対象が今回のフォルダ内へ収まり、関係のない写真フォルダや別の仕事の資料が混ざっていないことです。Claude Codeは起動したディレクトリのファイルだけでなく、現在のGitの状態やプロジェクト向けの指示も文脈として使います(How Claude Code works)。そのため、同じ指示でも起動場所が違えば、見える資料と提案される作業が変わります。
ここで知らないファイル名が大量に出たら、編集へ進まず、Get-Location または pwd をもう一度確認します。場所を間違えていた場合は、そのセッションで権限を広げるより、いったん終了して正しいフォルダから開き直す方が境界を説明しやすくなります。必要な資料が別フォルダに1つだけある場合も、パソコン全体を追加せず、そのフォルダだけを /add-dir で足します。
インストール自体を確かめたいときは、作業開始前に claude --version を実行します。正常ならバージョン番号が表示されます。command not found などが出る場合は、記事の権限設定ではなく、インストールまたはコマンドの場所の問題です。ファイルを動かして直そうとせず、公式のインストール確認手順へ戻ります(Advanced setup)。
権限モードで「確認の回数」を仕事に合わせる
Claude Codeには権限モードという仕組みがあり、どこまで確認なしで進むかを切り替えられます。既定(Manual)ではファイル変更のたびに承認を求め、Shift+Tabキーで切り替えられます(Quickstart)。主なモードの違いを早見表にします(2026-07-26時点の公式案内。仕様は変わるので最新は公式ページで確認してください)。
| モード | 確認なしで進む範囲 | 向いている場面 |
|---|---|---|
| Manual(既定) | ファイル変更のたびに確認を求める | 初めてのプロジェクト。原本に近いファイル |
| plan | ファイルを読み、調査し、計画を書くだけ。編集は計画を承認するまで止まる | まず何をされるか知りたいとき。調査だけ頼むとき |
| acceptEdits | 作業フォルダ内の編集に加え、rm(削除)・mv(移動)・cpなどの一般的なファイル操作も自動承認 | 誤字修正・下書き作成など、対象が限定され戻しやすい連続作業 |
使い分けの目安は2段階です。
- 初めて触るプロジェクトや、原本に近いファイル: planで「調査と計画だけ」させるか、Manualで1つずつ確認します。対象ファイル・変更理由を先に出してもらい、合ってから編集に進みます(Choose a permission mode)。
- 慣れた、戻しやすい編集だけ: acceptEditsで中断を減らします。誤字修正や下書き作成のような、失敗してもすぐ直せる仕事に向きます。
ここで大事な注意があります。acceptEditsでは、作業フォルダ内なら削除コマンド(rmやRemove-Itemなど)も自動承認の対象になり得ます(Choose a permission mode)。「削除の前には必ず確認画面が出る」とは思わないでください。削除が心配なときは、①削除候補の一覧だけ先に出してもらい人が選ぶ、②原本を作業フォルダの外に置く、③後述のask・denyルールを併用する、の3つで守ります。
人が止めるのは「戻しにくい・外へ影響する」操作
初心者向けの覚え方として「削除・外部送信・お金」の3語は今も有効です。ただしこれは公式の分類ではなく、あくまで入口の覚え方です。上位の判断基準は「失敗したとき、元へ戻しにくいか。パソコンの外へ影響が出るか」です。この基準で見ると、止める対象はもう少し広がります。
- 削除: 以前の内容へ戻せなくなる操作
- 外部送信: 公開する、メールで送る、外部サービスへアップロードする操作
- お金: 有料サービスの利用、契約や利用量の変更
- 本番反映(デプロイ): 実際に動いているサイトやアプリを書き換える操作
- 権限付与・共有基盤の変更: 他の人も使う場所や、アクセス権そのものを変える操作
- 秘密情報: パスワードや鍵を含むファイルを動かす・送る操作
参考までに、公式のautoモード(確認を減らすモード)でも、本番デプロイ、大量のクラウド削除、権限の付与、共有基盤の変更、セッション前から存在するファイルの不可逆な破壊、force push(履歴の強制上書き)などは既定で止める対象とされています(Choose a permission mode)。一方、作業を始めたブランチへの通常のpushなど、既定で許可される操作もあります。autoを「外部操作の前にはすべて確認が出るモード」と考えず、自分が止めたい操作は別にルール化してください。
伝え方は2段構えにします。
- 会話で伝える: 「削除・外部送信・お金・本番反映は、実行前に対象と影響を説明して確認を待ってください」と最初に頼む。
- 設定で固める: 確実に止めたい境界は
/permissionsで ask(毎回確認)や deny(禁止)のルールにする。ルールが複数当てはまるときは deny → ask → allow の順で評価されます(Configure permissions)。
会話のお願いは意図を伝える助けになりますが、公式も、会話の内容は圧縮(長い会話の自動要約)で消える可能性があるため、強い保証が必要なら deny・ask ルールを使うよう案内しています(Choose a permission mode)。「言ったから大丈夫」ではなく「設定にしたから止まる」を目指します。
/permissions で会話のお願いを停止ルールにする
/permissions は、どの道具やコマンドを確認なしで使えるか、毎回聞くか、使わせないかを管理する画面です。Claude Codeの入力欄へ /permissions と入力すると、allow・ask・denyのルールと、それぞれがどの設定ファイルから来たかを確認できます(Configure permissions)。
3つの意味は次のように分けます。
| 種類 | Claude Codeの動き | 使う例 |
|---|---|---|
| allow | 一致した操作を確認なしで許可する | npm test のような、何度も行う検査 |
| ask | 一致するたびに人へ確認する | 外部送信や、必要になることはあるファイル移動 |
| deny | 一致した操作を実行させない | 原本の削除、秘密ファイルの読み取り、許可していないpush |
初心者は、広いallowを増やすより、止めたいものからaskまたはdenyにする方が設定の意図を説明しやすくなります。たとえばWindowsでは、公式ドキュメントに PowerShell(Remove-Item *) をdenyへ置く例があります。PowerShellでは rm や rmdir などの別名も正規のコマンド名へ直して照合されるため、Remove-Item のルールが別名にも適用されます(Configure permissions)。
削除が本当に必要か判断できないときは、いきなりdenyを外すのではなく、次の順で確認します。
- 「削除予定のパスを1行に1件ずつ出し、なぜ不要か説明してください。まだ削除しないでください」と頼む。
- WindowsのPowerShellなら、同じ対象に対する
Remove-Itemへ-WhatIfを付けた確認用コマンドを先に提案してもらう。 - 表示された対象を確認し、必要なものだけを別フォルダへ移すか、その1回だけ許可する。
Microsoftの公式説明では、Remove-Item はファイルやフォルダなどを削除するコマンドで、-WhatIf は実行した場合に何が起きるかを表示し、コマンド自体は実行しません(Remove-Item)。ただし、確認後に対象やコマンドを書き換えたら別の操作です。-WhatIf の表示を見た後も、実行する行のパスが同じかを見直します。
もう1つの限界は、ファイル向けのRead・Editルールだけでは、PythonやNode.jsのスクリプトが間接的に読むファイルまで一律に遮断できないことです。公式も、組み込みのファイル道具に対するdenyと、Bashの子プロセス(=コマンドから起動する別プログラム)へのOSレベルの制限を分けています(Configure permissions)。機密資料を同じ作業フォルダへ置いたままルールだけで守ろうとせず、まず物理的に別の場所へ分ける方が簡単です。
チェックポイント・Git・別コピーの役割を分ける
「戻せるようにする」とき、1つの仕組みに全部を任せない方が安全です。Claude Codeのチェックポイント、Git、作業フォルダ外の別コピーは、守る対象が違います。
| 戻す手段 | 戻しやすいもの | 戻せない・弱いもの |
|---|---|---|
| Claude Codeのチェックポイント | 同じセッションでClaude Codeの編集道具が変えたファイル | Bash・PowerShell経由の削除や移動、外部サービスの変更 |
| Git | Gitが追跡し、履歴として残したファイル | Git管理外の原本、まだ記録していない未追跡ファイル、外部送信 |
| 作業フォルダ外の別コピー | 契約書、完成原稿、写真などの元データ | コピー後に更新した内容。保管先も同時に壊れた場合 |
Claude Codeでは、/rewind または入力欄が空の状態でEscキーを2回押すと、巻き戻す地点を選べます。コードと会話の両方、会話だけ、コードだけを戻す選択肢があります。一方、公式の制限には、Bashコマンドの rm・mv・cp などによるファイル変更はチェックポイントで追跡されず、rewindでは戻せないと明記されています(Checkpointing)。WindowsでPowerShellの削除や移動を任せる場合も、「チェックポイントがあるから後で戻せる」とは考えないでください。
Gitは、ファイルの変更履歴を追い、記録済みの以前の版へ戻すための仕組みです。GitHubの公式説明も、バージョン管理システムは変更履歴を追跡し、以前の版を回復できると説明しています(About Git)。ただし、Gitを入れただけでは履歴になりません。変更前の状態がcommit(=履歴の節目として保存する操作)されているか、少なくとも別コピーがあることを作業前に確認します。
唯一の原本は、Gitやチェックポイントとは別にコピーを作ります。NIST(米国国立標準技術研究所)は、バックアップを復旧のために作るファイルやプログラムのコピーと説明し、作るだけでなく維持し、実際に使えるか検査することを勧めています(Protecting Data from Ransomware and Other Data Loss Events)。個人の小さな作業でも考え方は同じです。コピー先のファイルを一度開き、内容が読めることまで確かめてから編集を始めます。
「チェックポイントがある」「Gitを使っている」「コピーを取った」のどれか1つで終わらせず、作業の大きさに合わせて重ねます。ブログの誤字修正ならGitだけでも管理しやすい一方、唯一の写真や契約書に近い文書は、AIへ渡す前に原本を作業フォルダの外へ置く方が後戻りしやすくなります。
作業後は変更ファイルと差分を確認する
任せた後の確認も、型を決めれば短時間で済みます。
- 完了したら「変更したファイル名、変更理由、実行した検査、その結果を一覧で出してください」と頼む。
- Gitを使っているなら
git status --shortを実行し、想定していないファイル名がないか見る。 git diff -- 対象ファイルで、対象を1ファイルに絞って中身の差を見る。- 新規ファイルは
git diffだけでは本文が表示されないことがあるため、git statusで未追跡と表示されたファイルを直接開く。 - 記事なら表示確認、プログラムならテストなど、最初に決めた確認方法を実行する。
git status は、変更されたファイル、次のcommit候補として準備されたファイル、Gitがまだ追跡していないファイルを区別して表示します(git-status)。git diff は、引数なしの基本形では、作業中のファイルと次のcommit用に準備した状態の差を表示します(git-diff)。つまり、statusは「どのファイルか」、diffは「中身がどう変わったか」を見る道具です。
意図と違う変更を見つけても、すぐに git restore . を実行しないでください。Git公式では、git restore は指定したパスを復元元の内容へ戻すコマンドで、. を指定すると現在のフォルダ全体が対象になります(git-restore)。必要だった別の変更まで失う可能性があるため、先に差分を見て、戻すファイル名を1つに絞ります。迷う場合は現在のファイルを別名で退避し、Claude Codeへ「実行せず、戻した場合に失う変更を説明してください」と頼みます。
うまくいかないときは表示ごとに分けて直す
同じ「編集できない」でも、原因によって次の一手が違います。何度も同じ指示を送る前に、画面の表示を次の3つへ分けます。
command not found と表示される
claude --version や claude に対して command not found と出る場合は、記事のファイル権限ではなく、Claude Codeのインストールまたはコマンドの場所を先に直します。公式の確認手順でも、claude --version が動けばバージョン番号を表示し、動かなければインストールのトラブルシューティングへ進む流れです(Advanced setup)。この状態でフォルダの権限を広げても解決にはつながりません。
許可画面が繰り返し出る
故障とは限りません。Manualでは編集やコマンドの前に確認し、作業フォルダ外のパスや未許可のコマンドも確認対象になります。画面に出たパスが正しいなら、その操作だけを許可するか、同種の安全な検査だけallowへ置きます。知らないパスなら拒否し、起動場所と /add-dir の追加先を確認します。確認を減らすためだけにパソコン全体を追加すると、扱う範囲まで広がるため避けます。
fatal: not a git repository と表示される
git status でこの表示が出たら、現在地がGitで管理された作業フォルダではない可能性があります。まず Get-Location または pwd で場所を確認します。正しいフォルダなのにGitを使っていない場合は、statusとdiffの手順だけを飛ばし、ファイル一覧と別コピーで確認します。エラーを消すためだけに、その場で自動的にGitを初期化する必要はありません。Gitを導入するなら、どのファイルを履歴へ含めるかを決める別の作業として行います。
よくある質問
デスクトップやホームフォルダからClaude Codeを始めてもよいですか?
技術的には起動できますが、おすすめしません。起動した場所の配下が作業の中心になるため、関係のないファイルまで作業の近くに置くことになります(Security)。今回の仕事のフォルダから始めて、別の場所が必要なときだけ /add-dir で追加する方が、範囲を説明しやすく安全です(Configure permissions)。
planモードならファイルは変更されませんか?
通常のplanモードは、ファイルを読み、調査用のコマンドを使い、計画を書きますが、計画を承認するまでソース(中身)の編集は止まります(Choose a permission mode)。初心者はまずこの通常のplanで「何をするつもりか」を見てから任せると安心です。
acceptEditsでも削除の前に確認されますか?
必ず確認されるとは限りません。作業フォルダ内では rm・rmdir・Remove-Item などの削除コマンドも自動承認の対象になり得ます(Choose a permission mode)。削除を止めたいときは、/permissions の ask・deny ルールを使い、原本は作業フォルダの外に保管してください(Configure permissions)。
「このファイルは触らないで」と文章で頼めば十分ですか?
意図を伝える助けにはなりますが、確実に止めたい境界を会話だけに任せないでください。会話は長くなると圧縮され、指示が消えることがあります。強い境界は /permissions のask・denyに置きます(Configure permissions)。さらに、あらゆる子プロセス(コマンドが呼び出す別のプログラム)までOSレベルで制限したい場合は、Bashサンドボックスという仕組みもあります。ただし2026-07-26時点の公式案内では、サンドボックスはmacOS・Linux・WSL2で動作し、素のWindowsには対応していません。Windowsの人はWSL2の中で使う形になります(Advanced setup)。
間違った編集は元に戻せますか?
Claude Codeの編集道具が変更したファイルは、チェックポイントから戻せる場合があります(Checkpointing)。ただし、Bash・PowerShellのコマンドが削除・移動・コピーしたファイル、別セッションからの変更、外部への公開・送信・課金は同じ仕組みでは戻せません。Gitの履歴と作業フォルダ外の別コピーも用意し、外へ影響する操作の前で止めてください。
まとめ
安全は「AIを毎回止めること」ではなく、狭い作業場所・仕事に合う権限モード・影響の大きい操作を止めるルール・最後の差分確認、の組み合わせで作ります。次の3つから始めてください。
- 今回の仕事のフォルダを1つ作り、原本と秘密情報は外へ出してから、そのフォルダでClaude Codeを起動する
- 初めての作業はplanかManualで「読むだけ・計画だけ」から始め、慣れた戻しやすい編集だけacceptEditsで任せる
- 削除・外部送信・お金・本番反映は「実行前に止まって」と伝えたうえで、確実に止めたいものは
/permissionsの ask・deny ルールにする
確認した一次情報
確認日: 2026-07-26
- Security - Claude Code Docs: 起動フォルダ配下が通常の書き込み境界で、親フォルダの変更には明示的な許可が必要だと説明
- Configure permissions - Claude Code Docs:
/permissionsでのallow・ask・deny管理、deny→ask→allowの評価順、/add-dirによる作業フォルダ追加、PowerShellルールを説明 - Choose a permission mode - Claude Code Docs: Manual・plan・acceptEdits・autoの違い、acceptEditsで自動承認されるファイル操作、autoの既定境界を説明
- Checkpointing - Claude Code Docs:
/rewindの使い方、保持するチェックポイント、Bash経由の変更を追跡しない制限、Gitの代替ではない点を説明 - How Claude Code works - Claude Code Docs: Claude Codeが使うプロジェクトとGitの情報、チェックポイントと権限の役割を説明
- Quickstart - Claude Code Docs: プロジェクトのディレクトリへ移動して起動する手順、権限モードの切り替え、変更ファイルを確認する流れを説明
- Advanced setup - Claude Code Docs:
claude --versionによる動作確認と、Windowsネイティブ・WSL2でのサンドボックス対応の違いを説明 - git-status - Git: 変更済み・準備済み・未追跡ファイルを確認するstatusの役割を説明
- git-diff - Git: 作業中のファイルとindexの差を表示する基本形を説明
- git-restore - Git: 指定したパスを復元元の内容へ戻す方法と、現在のフォルダ全体を対象にする例を説明
- About Git - GitHub Docs: バージョン管理が変更履歴を追跡し、以前の版を回復できる仕組みだと説明
- Remove-Item - Microsoft Learn: PowerShellのRemove-Itemが項目を削除することと、
-WhatIfが実行内容を表示してコマンドを実行しないことを説明 - Protecting Data from Ransomware and Other Data Loss Events - NIST: バックアップの定義と、バックアップを作成・維持・検査する考え方を説明
続き(結論と実データ)はnoteに置いています
ここでは手順のところまで書きました。実際に出た数字、うまくいかなかった条件、そのまま使える設定ファイルは、 note の記事にまとめてあります。