Claude Codeのプロンプト完全ガイド【2026年最新】：CLAUDE.md・システムプロンプト・ベストプラクティスまで徹底解説

Claude Codeのプロンプト完全ガイド【2026年最新】：CLAUDE.md・システムプロンプト・ベストプラクティスまで徹底解説

この記事を読むと、Claude Codeでのプロンプトの書き方、CLAUDE.mdの活用、システムプロンプトのカスタマイズ方法が一通り理解できます。「なんとなく使っている」から「意図通りに動かせる」レベルに上がりたい方に向けた内容です。

Claude Codeのプロンプト構造：3つの層を理解する

1. チャットプロンプト: ターミナルやWebで直接打つ一回限りの指示
2. CLAUDE.md: プロジェクト（またはユーザー）ごとに永続する設定ファイル
3. システムプロンプト: Claude Code本体が内部で持つ基盤プロンプト（カスタマイズ可能）

チャットプロンプトと永続設定の違い

チャットプロンプトの書き方：具体的で効果が出る指示の作り方

• UIの変更 → 「スクリーンショットを撮って元のデザインと比較して、違いを直して」
• ロジックの実装 → 「実装後にこのコマンドを実行して、全テストが通ることを確認して」
• バグ修正 → 「まず失敗するテストを書いてから修正して、エラーを握りつぶさず根本原因を直して」

マルチライン入力とプロンプトエディタの使い方

# ファイルからプロンプトを読み込む
claude -p "$(cat my-prompt.md)"

# または非対話モードで
claude --print "$(cat my-prompt.md)"

CLAUDE.mdの書き方：プロジェクトに永続する設定ファイルを作る

CLAUDE.mdに書くべきこと・書かないこと

書くべき内容:

• Claudeが自分で推測できないBashコマンド（ビルドコマンド、テスト実行コマンド）
• デフォルトから外れるコードスタイルのルール
• テスト手順と優先するテストランナー
• リポジトリのルール（ブランチ命名規則、PR規約）
• プロジェクト固有のアーキテクチャの決定事項
• 開発環境の特殊設定（必須の環境変数など）

書かないべき内容:

• Claudeがコードを読めばわかること
• 標準的な言語の慣習（Claude自身が知っている）
• 詳細なAPIドキュメント（リンクだけ貼れば十分）
• 頻繁に変わる情報
• 長い解説や説明文
• 「クリーンなコードを書く」などの自明な話

/initコマンドでCLAUDE.mdを自動生成する

@インポート構文でCLAUDE.mdをモジュール化する

# CLAUDE.md

プロジェクト概要は @README を参照。

# コーディングガイドライン
@docs/coding-guide.md

# テスト規約
@docs/testing.md

システムプロンプトとカスタマイズ：--append-system-promptの使い方

# CLIオプションでシステムプロンプトに追記
claude --append-system-prompt "常に日本語で回答してください。コードにはコメントを付けてください。"

システムプロンプトの流出と「何が書かれているか」

プロンプトキャッシング：コスト削減の重要なメカニズム

自動キャッシング（Automatic caching）:

• リクエストのトップレベルに cache_control フィールドを1つ追加するだけ
• 会話履歴が増えていくと自動的に最適なキャッシュポイントに適用
• マルチターンの会話に向いている

明示的なキャッシュブレークポイント（Explicit cache breakpoints）:

• 個別のコンテンツブロックに直接 cache_control を配置
• キャッシュする部分を細かく制御したいときに使う

「プロンプトが長すぎる」エラーの対処法

対処法1: /compact コマンドを使う

コンテキストを圧縮して整理します。会話の重要部分は維持しつつ、不要な詳細を省略してくれます。

対処法2: 新しいセッションを開始する

長くなった会話をいったん終了して、必要な情報だけ伝えながら新しいセッションを始める方法です。

対処法3: CLAUDE.mdで不要な内容をそぎ落とす

CLAUDE.mdが肥大化している場合は、必要なルールだけに絞り込む。

再利用可能なプロンプトの管理：Skillsとプロンプトライブラリ

# .claude/skills/code-review.md

コードレビューを実施してください。以下の観点でチェックしてください：

1. バグやエラーハンドリングの漏れ
2. パフォーマンス上の問題
3. セキュリティ上のリスク
4. コードの可読性と保守性
5. テストカバレッジ

レビュー結果をMarkdown形式で出力してください。

プロンプトエンジニアリングの実践：Claude Codeに特化したベストプラクティス

1. 「探索→計画→実行」を分けて指示する

いきなり「これ全部実装して」という大きな指示より、最初はPlanモードで計画だけ出させるアプローチが効果的です。shift + tab でPlanモードに切り替えると、Claudeは実装せずに計画書を出すだけになる。計画を確認してから実装を承認する流れが安全です。

2. コードベース探索の指示を先に出す

「このバグを直して」と言う前に「まず関連するファイルを探してリストアップして」と言う。先に地図を作ってもらってから実装に入る形ですね。

3. 「なぜ」を添える

指示の意図を伝えると品質が上がります。「テストにモックを使わないで（なぜなら統合テストを重視しているから）」という形ですね。

プロンプトの書き方でよくある失敗パターン

失敗1: スコープが大きすぎる

「このアプリ全体をリファクタリングして」という指示は、Claude Codeにとっては「どこから手をつけるかわからない」状態になりがちです。「src/api/handlers/userHandler.tsのエラーハンドリングを整理して」のように具体的なスコープを示す方が良い結果が出ます。

失敗2: 制約を後から追加する

最初に「ログイン機能を実装して」と言ってから「あ、このライブラリは使わないで」「ファイル構造はこうして」と後から条件を追加すると、手戻りが発生しやすい。最初から全条件を伝える方が効率的です。

失敗3: 完了定義が曖昧

「いい感じに整理して」「ちゃんと動くようにして」という指示は、Claudeが「完了」の判断をしにくい。「このテストが全部通れば完了」「このコマンドの出力がXXになれば完了」という明確な完了条件を付けることが重要です。

Skillsを使ったプロンプト自動化：カスタムコマンドの実際

コードレビュー系:

• /security-review : セキュリティの観点でコードを確認する
• /performance-review : パフォーマンスボトルネックをチェックする
• /review-pr : PRの差分をレビューして問題点をリストアップする

開発フロー系:

• /create-tests : 実装済みコードのテストを自動生成する
• /update-docs : コードの変更に合わせてドキュメントを更新する
• /commit : ステージングされた変更の適切なコミットメッセージを提案する

プロジェクト管理系:

• /deploy-staging : ステージング環境へのデプロイ手順を実行する
• /check-deps : 依存パッケージのバージョンを確認して更新が必要なものを提案する

オートメモリとセッション間の知識継承

• CLAUDE.md → チームで共有すべき安定したルール
• オートメモリ → 個人のワークスタイルや、Claudeが発見した知見

という役割分担になりますね。サブエージェントも独自のオートメモリを持てるので、エージェントチームの場合はそれぞれが知見を蓄積していく設計になっています。

よくある質問（FAQ）

Q: CLAUDE.mdとプロンプトの違いは何ですか？

Q: システムプロンプトは見られますか？

Q: プロンプトが長すぎてエラーになります

Q: チームで同じプロンプトを共有したい

Q: プロンプトを改善したいが何から始めれば？

まとめ

---

出典

• Claude Code公式ドキュメント - Store instructions and memories
• Claude Code公式ドキュメント - Best Practices
• Claude Code公式ドキュメント - Overview
• Anthropic公式ドキュメント - Prompt caching
• Claude Code公式ドキュメント - Settings