Claude Codeを安全に使う：権限モード・チェックポイント・秘密情報

01作業前：フォルダ・秘密情報・復旧手段を先に確認する

安全な利用は、プロンプトを送る前から始まります。まず現在のターミナル位置が正しいか確認し、練習なら実際の業務リポジトリとは分けたフォルダを使います。.env、証明書、個人資料のような機密ファイルがあるプロジェクトでは、AIツールに何を見せるかを先に確認します。例でAPIキーが必要に見えても、実際のキーではなく`sk-EXAMPLE-NOT-REAL`のような明らかな偽の値だけを使います。

作業開始前の確認
- 現在のフォルダは意図したプロジェクトか？
- 実際の個人情報・パスワード・APIキーが例のファイルに入っていないか？
- 変更前の状態をgitで確認し、必要ならコミットしたか？
- 初めて見る作業なら、planまたはManualのような確認重視の流れで始めるか？

Claude Codeにチェックポイントがあるからといって、別のバージョン管理が不要になるわけではありません。公式ドキュメントでも、チェックポイントはgitのようなバージョン管理を置き換えないと明記されています。重要なプロジェクトでは、作業前のコミットや別ブランチなど既存のバージョン管理習慣を維持します。

02権限モード：自動化の程度と人が確認する地点を分ける

公式ドキュメントで案内されている権限モードはManual、acceptEdits、plan、auto、dontAsk、bypassPermissionsです。Worknoteでは初心者にManualまたはplanから始めることを勧めます。これは危険がなくなるという意味ではなく、変更範囲を先に読んで判断する習慣を作るための選択です。

デフォルトの開始モードは料金プランによって異なります。2026-09-22に確認した公式ドキュメントでは、Pro・Max・Teamプランの対話型ターミナルのデフォルト開始モードはauto、その他のプランはManualと説明されています。したがって、常に同じ承認フローが表示されると仮定せず、現在のモードを確認します。

claude --permission-mode plan

03作業中：承認する前にファイルとコマンドの意味を読む

Claude Codeは必要なファイルを自分で読み、ファイル修正やコマンド実行の前に承認を求めることがあります。ただし、承認画面が表示されたこと自体はコマンドの安全性を保証しません。どのファイルが変わるのか、削除・移動・コピーのコマンドが含まれるのか、依頼していないインストールや範囲拡大があるのかを先に読みます。

変更前に、まず次の内容だけを教えてください。
1. 修正するファイル名
2. 各ファイルで変更する内容
3. 実行しようとしているシェルコマンド
4. 元ファイルを削除・移動・上書きする操作があるか
まだ修正やコマンド実行はしないでください。

• 依頼した範囲より多くのファイルが選ばれていたら理由を尋ねる。
• rm、mv、cpのようにファイル状態を直接変えるコマンドは、対象パスを再確認する。
• インストールコマンドが出たら、要件上本当に必要か確認する。
• 想定と違う変更が見えたら承認を続けず、planに戻る。
• 機密情報がプロンプト・ファイル・ログに入らないよう実際の値を取り除く。

04チェックポイント：巻き戻し機能の範囲を正確に知る

Claude Codeは送信する各プロンプトごとに自動チェックポイントを作成します。`/rewind`、または入力欄が空の状態でEscを二回押すと巻き戻しメニューを開け、コードと会話の復元、会話だけの復元、コードだけの復元、要約などを選べます。ただし、この機能がすべてのファイル変更を記録するわけではありません。

/rewind

特にシェルコマンドで削除・移動したファイルを`/rewind`がすべて元に戻してくれると期待してはいけません。チェックポイントはClaude Code内の作業を戻す補助手段と考え、プロジェクト履歴と復旧はgitなど別の手段で管理します。

05秘密情報と実データを練習例から分離する

コードが必要とするからという理由だけで、パスワード、APIキー、実際の顧客情報、実際の研究データをプロンプトや例のファイルにそのまま入れません。チュートリアルやエラー再現では、合成データと明らかな偽トークンを使います。実際のプロジェクトでどのデータをツールに提供できるかは、組織の方針と利用環境を別途確認する必要があります。

練習用の偽の値:
API_KEY=sk-EXAMPLE-NOT-REAL

仮想データ:
date,category,amount
2026-09-01,food,12000

プロジェクトに機密情報がすでに含まれている場合、単に「そのファイルは見ないで」と依頼するだけで十分だと考えてはいけません。ツールがアクセスできるファイル範囲とセキュリティ方針を確認し、必要なら機密情報を除いた作業用コピーで再現します。

06作業後：説明より実際のdiffと実行結果を基準にする

作業が終わった後は、AIが「完了した」と言うことより、実際のファイルと実行結果を基準に判断します。前の記事と同じようにgit diffを読み、実行コマンドをもう一度実行して期待値と比較します。エラー修正なら、問題が消えたかだけでなく、元の正常入力でも同じ結果が出続けるかを確認します。

作業後の確認
- git diffで想定したファイルだけが変わっているか？
- 実行結果が要件の期待値と一致しているか？
- 一時ファイル・偽の秘密情報がコミット対象に残っていないか？
- 次の人が理解できるよう、変更理由と実行方法が残っているか？

Claude Codeの自然言語による説明はレビューを助ける資料です。最終判断は、実際のdiff、実行結果、プロジェクトルールと照合して行います。この原則はモデルや権限モードが変わっても維持できます。

07最終成果物：作業前・作業中・作業後の安全チェックリスト

• 最初はManualまたはplanのような確認重視の流れを使う。
• bypassPermissionsはすべてのチェックを省略するため、隔離されたコンテナ・VMでのみ使う。
• チェックポイントをgitの代替と考えない。
• Bashコマンドで変わったファイルや外部で直接変えたファイルは、チェックポイントでの復元を期待しない。
• 実際のパスワード・APIキー・個人情報の代わりに、合成データと明らかな偽の値を使う。
• 完了したかどうかはAIの説明ではなく、diffと実際の実行結果で確認する。

このシリーズに共通する原則は、まず要件を小さく定め、読み取りと計画から始め、変更範囲を確認し、実行結果を人が検証することです。自動化の範囲が広がるほど人の役割がなくなるのではなく、何を許可し、その結果が基準に合っているかを確認する方へ移ります。

自分で確認する項目

Claude Code公式ドキュメント（2026-09-22確認）を基準に作成 · Claude Codeは実行していない · Python実行コードなし

• Manual、acceptEdits、plan、auto、dontAsk、bypassPermissionsの説明が公式ドキュメントと一致するか確認
• Pro・Max・Teamとその他のプランでデフォルト開始モードが異なる点を公式ドキュメントと照合
• 各プロンプトの自動チェックポイントと、/rewindまたは空の入力欄でEscを二回押してアクセスする方法を公式ドキュメントと照合
• Bashコマンドで変更されたファイルとClaude Code外で変更したファイルはチェックポイントで追跡・復元されないと明記しているか確認
• チェックポイントがgitを置き換えないという制限を明確に記載しているか確認
• 実際の秘密情報ではなくsk-EXAMPLE-NOT-REALのような明らかな偽の値だけを使っているか確認