【Claude活用入門 第5回】Claude Codeのベストプラクティス ― 探索→計画→実装→検証、検証手段を渡す、CLAUDE.md、コンテキストの管理、Skills・フック、権限とauto mode、秘密情報の守り方

生成AI
スポンサーリンク
スポンサーリンク

「Claude Code が “できました” と報告してきたのに、動かしてみたらエラーでした」
「長く使っていると、最初に伝えたルールを守らなくなってきます」

Claude Code は、ファイルを読み書きし、コマンドを実行して、何段階もの作業を任せられる道具です。任せられる範囲が広い分、任せ方で結果が大きく変わります。

第5回では、公式の Claude Code のベストプラクティス(code.claude.com/docs/en/best-practices)を中心に、進め方、検証、CLAUDE.md、コンテキストの管理、拡張の仕組み、権限を見ていきます。あわせて、秘密情報の守り方や並行作業など、使い始めてから知りたくなる機能も補います。


探索→計画→実装→検証→コミット

公式のベストプラクティスの中心は、いきなりコードを書かせないことです。

①探索(読んで把握)→②計画(プランモード)→人が確認→③実装→④検証(テスト・確認)→⑤コミットの順に進め、検証で失敗したら実装に戻し、プランモードはShift+Tabで切り替えて読むことと提案することだけを行いファイルを変更せず、計画はCtrl+Gでエディターで直接直せることを示す図
  1. 探索:関係するファイルや設定を読ませて、状況を把握させる
  2. 計画:どう変えるかの計画を出させ、人が確認する
  3. 実装:計画に沿って変更させる
  4. 検証:テストや確認のコマンドで結果を確かめさせる
  5. コミット:問題がなければコミットする

大きな変更では、プランモード(Shift+Tab で切り替え)を使うと、Claude は読むことと提案することだけを行い、ファイルを変更しません。計画は Ctrl+G でエディターに開いて直接直せます。一方、タイプミスの修正や変数名の変更のように、範囲がはっきりした小さな修正なら、計画を省いて直接任せて構いません。作業の大きさに合わせて使い分けます。


検証手段を渡す

  • 検証手段がないと、「できたように見える」ところで止まる:公式が最も重視している点。冒頭の1つ目の相談がこれ
  • 渡せる検証手段:テスト、ビルド、lint、確認用のコマンド、スクリーンショット、期待する出力の例
  • インフラでの例:ansible-playbook --check --diff、terraform plan、nginx -t、systemctl status、ヘルスチェックの URL
  • 検証まで含めて依頼する:「変更後に --check で差分がないことを確かめてから報告して」
  • 止める仕組み:フック(Stop)で、検証が通るまで終了させない設定もできる
  • 独立した確認:別のサブエージェントに検証だけを任せる

CLAUDE.md

  • 何か:プロジェクトのルールを書くファイル。セッションの開始時に毎回読み込まれる
  • 書くこと:ビルド・テストの手順、作業の規約、よく使うコマンド、間違えやすい点
  • 書かないこと:Claude が自分で読み取れること(ディレクトリ構成など)、頻繁に変わる情報
  • 短く保つ:公式の目安は 1ファイル200行未満。長いとコンテキストを使い、守られにくくなる。特定のファイルにだけ効くルールは .claude/rules/ に分ける(paths を指定すると、一致するファイルを扱うときだけ読み込まれる)。4MiB を超える CLAUDE.md は読み込まれない
  • ほかのファイルを取り込む:CLAUDE.md の中に @docs/runbook.md のように書く
  • 始め方:/init でリポジトリを解析して下書きを作れる。編集は /memory からもできる(以前の # で書き足すショートカットは廃止された。Claude に「CLAUDE.md に追記して」と頼む)
  • 置き場所:プロジェクトの CLAUDE.md(チームで共有)、CLAUDE.local.md(自分だけ。.gitignore に入れる)、~/.claude/CLAUDE.md(全プロジェクト共通)。CLAUDE.md が無ければ AGENTS.md も読む
# 作業ルール(例)
- 本番のインベントリ(inventory/prod)への実行は、必ず --check --diff を先に見せる
- playbook は roles/ 配下に置き、変数は group_vars に書く
- 変更後は ansible-lint を通してから報告する

auto memory

Claude Code には、作業の中で分かったことを Claude 自身が書き留める auto memory もあり、既定でオンです。保存先は ~/.claude/projects/<プロジェクト>/memory/ で、毎回、先頭の200行(または25KB)が読み込まれます。/memory で内容の確認やオン・オフができます。チームで守るべきルールは CLAUDE.md に、個人の作業で分かったことは auto memory に、と分けて考えます。


コンテキストの管理

公式は「最大の制約はコンテキストウィンドウ」としています。会話が長くなるほど最初の指示を見失いやすくなり、使用量も増えます。冒頭の2つ目の相談は、これが原因です。

操作何をするかいつ使うか
/clear会話をリセットする関係のない作業に移るとき
/compactこれまでの会話を要約して、コンテキストを空ける長くなってきたとき(自動でも行われる)
/rewind以前のチェックポイントに戻す(入力欄が空のときに Esc を2回でも開く)方向を間違えたとき
EscClaude の作業を止める早めに方向を直したいとき
サブエージェント別のコンテキストで調べさせ、結論だけを受け取る調べものでメインの会話を埋めたくないとき
/contextコンテキストの使用量を表示する何が場所を取っているか知りたいとき
/usage使用量の枠の残りと内訳を表示する上限が気になるとき(第3回)
  • チェックポイントは、プロンプトを送るたびに自動で作られる(1セッションで直近100個)。「コードと会話を戻す」「会話だけ戻す」「コードだけ戻す」などを選べる
  • ただし、Bash のコマンドで変えたファイル、外部での変更は追跡されない。サーバーの設定変更のように、コマンドで行った変更は /rewind では戻らない。戻せるのは Claude が編集したファイルだけと考え、本番の変更は Git と手順書の切り戻しで守る

拡張の仕組み

仕組み何か使いどころ
Skills手順・スクリプト・資料をまとめたフォルダー(SKILL.md)。関係する作業のときだけ読み込まれる繰り返す作業の手順(例:資料の最新化、playbook の作り方)
MCP外部のサービス・ツールとつなぐ仕組みAWS・監視ツール・チケット管理との連携
フック決まったタイミングで必ず実行する処理編集後の lint、危険なコマンドの遮断(CLAUDE.md より強い)
サブエージェント別のコンテキストで動く補助のエージェント調べもの、検証、並行作業
プラグインSkills・フック・サブエージェント・MCP をまとめて配る単位同じ道具一式を配る
  • 以前の「カスタムのスラッシュコマンド」(.claude/commands/)は、Skills に統合された。.claude/commands/deploy.md も .claude/skills/deploy/SKILL.md も /deploy で呼べる。新しく作るなら、補助のファイルを置ける Skills が勧められている
  • Skills の置き場所は、個人用が ~/.claude/skills/<名前>/、プロジェクト用が .claude/skills/<名前>/。一覧は /skills
  • CLAUDE.md は「お願い」、フックは「必ず実行される仕組み」。守らせたいことの重さで使い分ける

権限と auto mode

Claude Code は、ファイルの変更やコマンドの実行の前に許可を求めます。毎回の確認を減らしつつ安全を保つには、権限ルールを使います。

Claudeの操作は、settings.jsonの権限ルールで、allow(自動で許可:読み取り・--check)、ask(必ず確認:本番への実行)、deny(実行させない:破壊的な操作)に分かれ、ルールにない操作はauto mode(ターミナルでの既定)の分類器が安全なら承認し危険なら止めることを示す図
  • settings.json に、自動で許可する操作(allow)、必ず確認する操作(ask)、決して実行させない操作(deny)を書く。たとえば、読み取りや --check は許可、本番への実行は確認、破壊的なコマンドは拒否
  • auto mode では、別の分類モデルが、依頼の範囲を超えていないか、読み込んだ内容に誘導されていないかなどを確かめ、安全な操作は確認なしで実行し、危険な操作を止める。v2.1.283 以降は、ターミナルと VS Code で最初から auto mode で始まる(全プランで使える)
  • 公式は、auto mode は安全を保証するものではないと明記している。ログや Web ページに紛れた指示に従ってしまうリスク(プロンプトインジェクション、第6回)はゼロではない。取り消せない操作は人が承認する設計にする

権限モードの一覧

モード動き
default(表示名は Manual)操作ごとに確認する
acceptEditsファイルの編集と一部のファイル操作を自動で許可する
plan読むだけで、編集しない(プランモード)
auto分類モデルが判断して、安全な操作を自動で許可する
dontAsk確認が必要な操作はすべて拒否する(CI 向け)
bypassPermissions確認をすべて省く。コンテナや VM の中だけで使う

Shift+Tab では Manual → acceptEdits → plan の順に切り替わり、auto も有効ならこの中に入ります。dontAsk は起動時の --permission-mode dontAsk で指定し、bypassPermissions も起動時のオプションや設定で有効にしたときだけ選べます。deny のルールは、どのモードでも効きます。

秘密情報を読ませない

.env や認証情報のファイルは、deny のルールで読ませないようにできます。公式の例は次のとおりです。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)"
    ]
  }
}
  • 一致したファイルは、読み取りと編集が拒否され、cat などのコマンドでの読み取りにも効く
  • ただし、grep -r のようにファイル名を挙げずに読むコマンドまでは防げない。OS のレベルで守るには sandbox(/sandbox で有効にする)を使う。書き込めるのは作業ディレクトリなどに限られ、新しい宛先への通信には承認が要る
  • sandbox は macOS・Linux・WSL2 で使え、Windows のネイティブの環境では使えない

並行作業と自動化

  • worktree で並行作業:claude --worktree <名前>(-w)で、別の作業ツリー(.claude/worktrees/<名前>/)とブランチを作ってセッションを始められる。複数の作業を、ファイルを取り合わずに並行して進められる。.claude/worktrees/ は .gitignore に入れる
  • 対話なしで実行:claude -p "…" で、結果を標準出力に出して終わる。--output-format json で結果を JSON で受け取れる。スクリプトや定期実行に組み込める。デスクトップアプリの Code タブは対話専用で、対話なしの実行と Agent teams(複数の Claude がチームで分担する機能)は CLI だけで使える
  • GitHub Actions:anthropics/claude-code-action で、Issue やプルリクエストで @claude と呼ぶと応答させられる。Claude Code の /install-github-app で設定を進められる

自動で動かすときほど、権限ルールと deny を先に決めておきます。


筆者の実例:資料づくりのプロジェクト

筆者は、この連載のもとになった勉強会の資料づくりも Claude Code で行っています。

原稿md(唯一の正)をPythonで図の定義にし、PowerShellのbuild.ps1でPowerPointのpptxを作り、全ページを画像にして確認し、直すのはmdという流れと、支える仕組みとしてCLAUDE.md・引継ぎ書、Skills、サブエージェントでの公式情報の調査があることを示す図
  • CLAUDE.md と引継ぎ書:資料の書式、命名、確定した方針、環境の落とし穴(PowerPoint の自動操作の不具合など)をファイルに残し、次のセッションが同じ前提で始められる
  • Skills:資料の誤りの洗い出しと修正、解説のスライドの追加など、繰り返す作業の手順をまとめた
  • 原稿 md → pptx の自動生成:md を直してスクリプトで作り直す。pptx を直接編集しない
  • 検証:全ページを画像にして、はみ出し・重なりを確認する
  • 調査:公式情報の調査はサブエージェントで並行して行い、出典付きでまとめる

探索→計画→実装→検証の流れ、検証手段、CLAUDE.md と Skills が、そのまま資料づくりにも効いています。


考えてみよう

  1. Claude Code に頼んでいる作業で、Claude が自分で結果を確かめられる検証手段を渡していますか。インフラの作業なら、何を渡せますか。
  2. 手元の CLAUDE.md は何行ありますか。200行を超えていたら、.claude/rules/ や Skills に分けられる部分はどこでしょうか。
  3. 本番のサーバーの設定を変えるコマンドを実行した後、/rewind で元に戻せるでしょうか。

ヒント:検証手段を渡す、CLAUDE.md、コンテキストの管理の節のチェックポイントの注意を見直してください。


まとめ

  • 探索→計画→実装→検証→コミット。大きな変更はプランモードで計画を先に確認する
  • 検証手段を渡す。渡さないと「できたように見える」ところで止まる
  • CLAUDE.md は200行未満に保ち、ファイル別のルールは .claude/rules/、繰り返す手順は Skills に分ける
  • コンテキストは作業の区切りでリセットする。/rewind は Bash で変えたものを戻さない
  • 権限は allow・ask・deny で分け、秘密情報は deny と sandbox で守る。auto mode でも取り消せない操作は人が承認する

次回は最終回です。データの扱い、プロンプトインジェクションとハルシネーション、AI Fluency の4D など、安全に使うための考え方をまとめます。


連載「Claude活用入門」全6回

  1. Claudeの全体像とプラン
  2. Chat・Cowork・Codeの使い分け
  3. ModelとEffort
  4. プロンプトの基本と指示の例
  5. Claude Codeのベストプラクティス(この記事)
  6. 安全に使う

コメント

タイトルとURLをコピーしました