筆者プロフィール: ソフトウェアエンジニア。「知った気にならない。いつまでも学び続ける」を信条に、業務と個人開発の両輪で技術を磨いています。AI 駆動開発で複数の個人開発アプリを構築・運用中。
👉 ポートフォリオ: 筆者ホームページ
この記事は約12分で読めます。
Claude Code にプロンプトを投げるとき、こんな悩みはありませんか？ 「同じ指示を繰り返している」「思ったコードが出てこない」「トークンを無駄に消費している」。本記事では、Anthropic 公式の Claude Code ベストプラクティスとClaude 4 プロンプトエンジニアリングガイドを一次ソースとして、コスト削減と効率化のテクニックを整理します。
本記事の信頼度について
本記事は Anthropic 公式ドキュメントをベースにしていますが、すべての内容が「公式の明言」ではありません。以下の凡例で信頼度を明示します。
| 凡例 | 意味 |
|---|---|
| 🟢 公式引用 | 公式ドキュメントの原文を直接引用・翻訳 |
| 🟡 公式記述 | 公式ドキュメントに記載された技術・機能・手順 |
| 🔵 筆者解釈 | 公式情報を筆者が再整理・優先度付けしたもの |
後ほどこの記事は複数に分割する予定です。まずは網羅的な一覧としてお役立てください。
この記事の対象読者
- Claude Code を使っているが、プロンプトのコツを体系的に知りたい方
- AI 駆動開発でコストを削減したい方
- 公式情報ベースの確かな情報源を求める方
1. ゴールデンルール 🟢
公式が最初に提示する原則（Claude 4 best practices）:
Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too.
「文脈をほとんど持たない同僚がそのプロンプトを読んで迷わず実行できるか？」 この問いに Yes と答えられないなら、Claude も迷います。
公式では「Claude を、職場初日のインターン」と表現しています。
Think of Claude as a brilliant but new employee who lacks context on your norms and workflows. The more precisely you explain what you want, the better the result.
2. コンテキストウィンドウの管理が最重要 🟢
公式が明言する Claude Code ベストプラクティスの根本原則:
Most best practices are based on one constraint: Claude's context window fills up fast, and performance degrades as it fills.
コンテキストが埋まると Claude の性能が劣化する のです。したがって、コスト削減と性能向上は同じ軸で語られます。
🟡 コンテキスト管理の具体策（公式記載）
| 操作 | 用途 |
|---|---|
/clear |
タスク切替時にコンテキストをリセット |
Esc（1回） |
Claude を途中で止める（コンテキストは保持） |
Esc + Esc / /rewind
|
過去のチェックポイントに戻る |
/compact <instructions> |
コンテキストを要約して圧縮 |
/btw |
質問をコンテキストに残さず一時的に聞く |
🟢 公式の警告
If you've corrected Claude more than twice on the same issue in one session, the context is cluttered with failed approaches. Run
/clearand start fresh with a more specific prompt that incorporates what you learned.
同じ指摘を2回以上繰り返したら /clear が公式の鉄則です。
3. 検証手段を必ず提供する 🟢（最高優先度）
公式が "the single highest-leverage thing you can do"（単独で最も効果の大きいこと）と明言:
Include tests, screenshots, or expected outputs so Claude can check itself. This is the single highest-leverage thing you can do.
🟡 具体例（公式の Before/After）
| 戦略 | ❌ Before | ✅ After |
|---|---|---|
| 検証基準の提供 | "implement a function that validates email addresses" | "write a validateEmail function. example test cases: user@example.com is true, invalid is false, user@.com is false. run the tests after implementing" |
| UI変更の視覚的検証 | "make the dashboard look better" | "[paste screenshot] implement this design. take a screenshot of the result and compare it to the original. list differences and fix them" |
| 根本原因への対処 | "the build is failing" | "the build fails with this error: [paste error]. fix it and verify the build succeeds. address the root cause, don't suppress the error" |
4. Explore → Plan → Code → Commit の4段階 🟢
公式推奨の基本ワークフロー:
Letting Claude jump straight to coding can produce code that solves the wrong problem. Use Plan Mode to separate exploration from execution.
🟡 4段階の詳細
① Explore（Plan Mode）: ファイルを読ませて理解させる
例: "read /src/auth and understand how we handle sessions and login"
② Plan: 実装計画を作らせる（Ctrl+G で編集可能）
例: "I want to add Google OAuth. What files need to change? Create a plan."
③ Implement（Normal Mode）: 計画通りに実装・検証
例: "implement the OAuth flow from your plan. write tests, run them, fix failures"
④ Commit: 説明的なメッセージでコミット
例: "commit with a descriptive message and open a PR"
🟢 Plan Mode のスキップ条件（公式）
For tasks where the scope is clear and the fix is small (like fixing a typo, adding a log line, or renaming a variable) ask Claude to do it directly. Planning is most useful when you're uncertain about the approach, when the change modifies multiple files, or when you're unfamiliar with the code being modified.
一文で diff を説明できる修正は Plan 不要 が目安です。
5. 具体的なコンテキストをプロンプトに入れる 🟢
The more precise your instructions, the fewer corrections you'll need.
🟡 公式の Before/After 例
| 戦略 | ❌ Before | ✅ After |
|---|---|---|
| スコープを切る | "add tests for foo.py" | "write a test for foo.py covering the edge case where the user is logged out. avoid mocks." |
| 情報源を指す | "why does ExecutionFactory have such a weird api?" | "look through ExecutionFactory's git history and summarize how its api came to be" |
| 既存パターンを指す | "add a calendar widget" | "look at how existing widgets are implemented. HotDogWidget.php is a good example. follow the pattern..." |
| 症状を描写する | "fix the login bug" | "users report that login fails after session timeout. check src/auth/, especially token refresh. write a failing test, then fix it" |
🟡 リッチな情報を渡す方法（公式記載）
-
@でファイル参照: ファイルの場所を説明する代わりに@path/to/fileで直接参照 - 画像の貼り付け: コピペ・ドラッグで直接渡せる
- URL を渡す: ドキュメント・API リファレンスを参照させる
-
データをパイプ:
cat error.log | claudeで直接送る - Claude 自身に取得させる: Bash コマンドや MCP ツール経由
6. CLAUDE.md の書き方 🟢
🟢 公式の警告
Keep it concise. For each line, ask: "Would removing this cause Claude to make mistakes?" If not, cut it. Bloated CLAUDE.md files cause Claude to ignore your actual instructions!
肥大した CLAUDE.md は、Claude が指示を無視する原因 になります。
🟡 含めるべき内容 vs 除外すべき内容（公式表）
| ✅ 含める | ❌ 除外する |
|---|---|
| Claude が推測できない Bash コマンド | コードを読めば分かること |
| デフォルトと異なるコードスタイル | 標準的な言語慣習 |
| テスト実行手順と推奨テストランナー | 詳細な API ドキュメント（リンクにする） |
| リポジトリのエチケット（ブランチ命名、PR 規約） | 頻繁に変わる情報 |
| プロジェクト固有のアーキテクチャ判断 | 長い説明やチュートリアル |
| 開発環境の独自仕様（必須 env var） | ファイル毎の詳細説明 |
| 一般的でない挙動や注意点 | 「きれいなコードを書こう」等の自明なこと |
🟢 強調の効果（公式明言）
You can tune instructions by adding emphasis (e.g., "IMPORTANT" or "YOU MUST") to improve adherence.
「IMPORTANT」「YOU MUST」を付けると遵守率が上がる と公式が認めています。
7. 動機・理由を説明する 🟢
Providing context or motivation behind your instructions, such as explaining to Claude why such behavior is important, can help Claude better understand your goals and deliver more targeted responses.
🟡 公式の例
| ❌ Before | ✅ After |
|---|---|
NEVER use ellipses |
Your response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them. |
理由を添えると、Claude は類似のケースにも正しく対応できます（公式記述: "Claude is smart enough to generalize from the explanation."）。
8. XML タグで構造化する 🟢
XML tags help Claude parse complex prompts unambiguously, especially when your prompt mixes instructions, context, examples, and variable inputs.
🟡 推奨タグ（公式例）
<instructions>
ここに指示を書く
</instructions>
<context>
ここに背景・文脈を書く
</context>
<examples>
<example>
具体例1
</example>
<example>
具体例2
</example>
</examples>
<input>
処理対象のデータ
</input>
🟢 公式のベストプラクティス
- Use consistent, descriptive tag names across your prompts.
- Nest tags when content has a natural hierarchy (documents inside
<documents>, each inside<document index="n">).
9. Few-shot（例示）の活用 🟢
Examples are one of the most reliable ways to steer Claude's output format, tone, and structure.
🟢 公式推奨
Include 3–5 examples for best results.
3〜5個の例 が最適、と明言されています。
🟡 良い例の3条件（公式）
- Relevant（関連性）: 実際のユースケースと近い
- Diverse（多様性）: エッジケースをカバー、偏らない
-
Structured（構造化）:
<example>タグで囲む
10. 長文プロンプトは「長文を上に、質問を下に」 🟢
🟢 公式の性能データ
Queries at the end can improve response quality by up to 30% in tests, especially with complex, multi-document inputs.
質問を末尾に置くと、複数ドキュメントを扱う場合に最大30%品質が向上 します。
🟡 推奨構造（公式例）
<documents>
<document index="1">
<source>annual_report_2023.pdf</source>
<document_content>
{{ANNUAL_REPORT}}
</document_content>
</document>
<document index="2">
<source>competitor_analysis_q2.xlsx</source>
<document_content>
{{COMPETITOR_ANALYSIS}}
</document_content>
</document>
</documents>
Analyze the annual report and competitor analysis. Identify strategic advantages and recommend Q3 focus areas.
🟡 引用ベースの回答を促す（公式記載）
For long document tasks, ask Claude to quote relevant parts of the documents first before carrying out its task. This helps Claude cut through the noise of the rest of the document's contents.
11. Claude Code 固有の機能 🟢
🟡 公式が紹介する環境設定
| 機能 | 用途 | 公式コマンド |
|---|---|---|
/init |
プロジェクトから CLAUDE.md の雛形を生成 | /init |
| Skills | ドメイン知識・繰り返し作業を .claude/skills/ に定義 |
.claude/skills/SKILL.md |
| Subagents | 専門タスクを別コンテキストで実行 | .claude/agents/*.md |
| Hooks | 特定タイミングで自動実行するスクリプト | .claude/settings.json |
| Plugins | Skills/Hooks/Subagents/MCP のバンドル | /plugin |
| MCP servers | 外部ツール連携（Notion, Figma, DB 等） | claude mcp add |
| Auto mode | 分類器が安全性を判定、承認プロンプトを削減 | --permission-mode auto |
🟢 Hooks の特徴（公式明言）
Unlike CLAUDE.md instructions which are advisory, hooks are deterministic and guarantee the action happens.
CLAUDE.md は推奨、Hooks は決定的 という役割分担です。
12. Let Claude interview you（Claude に質問させる）🟢
For larger features, have Claude interview you first. Start with a minimal prompt and ask Claude to interview you using the
AskUserQuestiontool.
🟡 公式のプロンプト例
I want to build [brief description]. Interview me in detail using the AskUserQuestion tool.
Ask about technical implementation, UI/UX, edge cases, concerns, and tradeoffs. Don't ask obvious questions, dig into the hard parts I might not have considered.
Keep interviewing until we've covered everything, then write a complete spec to SPEC.md.
大きな機能は Claude に逆インタビューさせる のが公式の推奨です。
13. サブエージェントで調査を分離する 🟢
🟢 公式の戦略
Since context is your fundamental constraint, subagents are one of the most powerful tools available. When Claude researches a codebase it reads lots of files, all of which consume your context. Subagents run in separate context windows and report back summaries.
🟡 使い方（公式例）
Use subagents to investigate how our authentication system handles token refresh, and whether we have any existing OAuth utilities I should reuse.
サブエージェントは別コンテキストで動くため、メイン会話のコンテキストを汚さずに調査できます。
14. Writer/Reviewer パターン 🟢
🟢 公式の推奨
A fresh context improves code review since Claude won't be biased toward code it just wrote.
同一 Claude がレビューすると自分のコードに肯定的になるバイアス があるため、別セッションでレビューさせる。
🟡 公式のパターン例
| Session A (Writer) | Session B (Reviewer) |
|---|---|
Implement a rate limiter for our API endpoints |
|
Review the rate limiter implementation in @src/middleware/rateLimiter.ts. Look for edge cases, race conditions, and consistency with our existing middleware patterns. |
|
Here's the review feedback: [Session B output]. Address these issues. |
15. 非対話モードで自動化 🟢
🟡 公式の使い方
# ワンショットクエリ
claude -p "Explain what this project does"
# JSON 出力（スクリプト連携）
claude -p "List all API endpoints" --output-format json
# ストリーミング出力
claude -p "Analyze this log file" --output-format stream-json
CI パイプラインや pre-commit hook に組み込めます。
16. 避けるべきアンチパターン 🟢（公式明記）
公式が "Common failure patterns" として明記しているもの:
| アンチパターン | 症状 | 公式の対策 |
|---|---|---|
| Kitchen sink session | 1セッションで無関係タスクを混ぜる | タスク切替時に /clear
|
| Correcting over and over | 同じ指摘を繰り返す | 2回失敗したら /clear して改善プロンプトで再開 |
| Over-specified CLAUDE.md | CLAUDE.md が長すぎて無視される | 容赦なく刈り込む |
| Trust-then-verify gap | 動きそうで動かないコード | 必ず検証手段を提供、できないなら出荷しない |
| Infinite exploration | スコープなしの調査で context 消費 | スコープを切るか、サブエージェントを使う |
17. Claude Opus 4.7 固有の注意点 🟢
🟢 effort パラメータ（公式推奨）
Start with the new
xhigheffort level for coding and agentic use cases, and use a minimum ofhigheffort for most intelligence-sensitive use cases.
| effort | 用途 |
|---|---|
max |
高負荷タスク。過剰思考のリスクあり |
xhigh（新） |
コーディング・エージェントの推奨デフォルト |
high |
バランス重視。知識タスクの最低ライン |
medium |
コスト重視、知能とのトレードオフ |
low |
短時間タスク・低レイテンシ要件 |
🟢 より文字通りの指示解釈（公式明言）
Claude Opus 4.7 interprets prompts more literally and explicitly than Claude Opus 4.6, particularly at lower effort levels. It will not silently generalize an instruction from one item to another.
「1箇所に適用した指示を他にも自動適用する」挙動が減った ため、スコープを明示する必要があります。
If you need Claude to apply an instruction broadly, state the scope explicitly (for example, "Apply this formatting to every section, not just the first one").
18. 🔵 コスト削減優先度ランキング（筆者解釈）
⚠️ 以下は筆者の解釈です。公式は各施策の効果量を定量比較していません。 公式ドキュメントの表現強度と文脈から、筆者が推測した優先度です。
| 優先度 | 施策 | 根拠 |
|---|---|---|
| ⭐⭐⭐ | 検証手段（テスト・スクショ）を提供 | 公式が "the single highest-leverage thing" と明言 🟢 |
| ⭐⭐⭐ |
/clear をタスク切替で実行 |
公式が "the most important resource to manage" と明言 🟢 |
| ⭐⭐⭐ | Explore → Plan → Code の順守 | 公式が "recommended workflow" として提示 🟢 |
| ⭐⭐ | サブエージェントで調査を分離 | 公式が "one of the most powerful tools" と表現 🟢 |
| ⭐⭐ |
@ でファイル参照 |
トークン効率が良い（筆者の推論 🔵） |
| ⭐⭐ | CLAUDE.md を 150 行以内に刈り込む | 公式が "bloated files cause Claude to ignore" と警告 🟢 |
| ⭐ | XML タグで構造化 | 複雑プロンプトで効果的（公式記述 🟢） |
| ⭐ | effort パラメータを調整 | コスト vs 知能の明示的なトレードオフ 🟢 |
19. 🔵 パターン別プロンプト例 42選（筆者解釈）
⚠️ 以下の具体的なプロンプト文言は筆者の解釈です。 公式ドキュメントが示す原則（明確な指示・具体的コンテキスト・検証手段・動機付け・XMLタグ等）を、日常的な使用シーンに応用したものです。Claude Code だけでなく、Claude Web / API / Desktop 含む Claude 全般で使えます。
使うときは {{ }} の部分を自分の状況に置き換えてください。
A. 開発・コーディング系（11パターン）
A1. 実装依頼
{{機能名}} を実装してください。
【前提】
- 言語: {{言語}}
- フレームワーク: {{FW}}
- 既存コード: @{{ファイルパス}}
【要件】
- {{要件1}}
- {{要件2}}
【検証基準】
- {{テストケース1}} → {{期待結果}}
- {{テストケース2}} → {{期待結果}}
実装後、テストを実行し結果を報告してください。
A2. コードレビュー依頼
以下のコードをレビューしてください。
観点: セキュリティ、パフォーマンス、可読性、テスト容易性。
各指摘には重要度（Critical/High/Medium/Low）を付け、
修正案のコードも併記してください。
{{コード}}
A3. デバッグ・バグ調査
以下のエラーが発生しています。根本原因を特定し、修正してください。
エラーを抑制するのではなく、原因に対処してください。
【エラーメッセージ】
{{エラーログ}}
【再現手順】
1. {{手順1}}
2. {{手順2}}
【環境】
- {{バージョン情報}}
修正後、失敗していたケースが通ることをテストで検証してください。
A4. リファクタリング
以下のコードをリファクタリングしてください。
目的: {{目的（可読性向上/責務分離/パフォーマンス改善など）}}
【制約】
- 外部インターフェースは変更しない
- 既存のテストが全て通ること
- 1コミット = 1つの意図にまとまるよう段階的に
{{対象コード}}
A5. テスト生成
{{関数名}} のテストを書いてください。
【カバーすべきケース】
- 正常系: {{ケース}}
- 異常系: {{ケース}}
- エッジケース: {{空値/最大値/境界値など}}
【制約】
- モックは最小限
- テストランナー: {{Jest/pytest等}}
- AAA パターン（Arrange-Act-Assert）で記述
テストを書いた後、実際に実行して全てパスすることを確認してください。
A6. ドキュメント生成
以下のコードから README.md を生成してください。
【含める内容】
- プロジェクト概要
- セットアップ手順（コピペで動くコマンド）
- 使い方（最小動作例）
- 主要な API / エンドポイント
- 環境変数一覧
【除外】
- 自明な説明
- AI っぽい修飾表現
{{コード or ディレクトリ}}
A7. 設計相談
{{機能名}} の設計を相談したいです。
いきなり実装案を出さず、まず設計を議論してください。
【背景】
{{状況・課題}}
【検討してほしい観点】
- アーキテクチャ（モノリス/マイクロサービス/レイヤー構成）
- データモデル
- 外部依存（DB/API/キュー）
- トレードオフ
3〜5個の選択肢を提示し、各メリット・デメリット・推奨度を表形式でください。
A8. 技術選定
{{用途}} に使う {{ライブラリ/FW}} を選定します。
候補: {{候補A}}, {{候補B}}, {{候補C}}
以下の観点で比較表を作成してください。
- 学習コスト
- パフォーマンス
- コミュニティの活発さ（GitHub Stars, 最終更新日）
- 本プロジェクトでの向き不向き
- ライセンス
公式ドキュメントを参照し、推測ではなく事実ベースで。
A9. 既存コード理解
@{{ファイルパス}} のコードを読み解いてください。
【知りたいこと】
- このファイルの責務
- 主要なクラス/関数の役割
- 他のどのファイルと依存しているか
- 「なぜこう書かれているか」の推測（git blame は必要なら参照）
初見の開発者にも分かるレベルで説明してください。
A10. マイグレーション
{{FW}} を v{{旧}} から v{{新}} にアップグレードします。
【手順】
1. 公式のアップグレードガイドを参照
2. 破壊的変更をリストアップ
3. 本プロジェクトで影響する箇所を @ で特定
4. 修正パッチを段階的に提示
一度に全部変更せず、影響箇所ごとに確認できるよう分割してください。
A11. コマンド生成
{{やりたいこと}} を実現する {{Bash/Git/Docker/kubectl}} コマンドを教えてください。
【前提】
- OS: {{Windows/macOS/Linux}}
- 対象: {{ファイル/コンテナ/リソース}}
【望む形式】
- コマンド本体
- 各オプションの意味
- 実行前に確認すべきこと（破壊的でないか）
B. 情報収集・学習系（7パターン）
B1. 確かな情報が欲しい
{{トピック}} について、公式ドキュメント・公式リポジトリ・RFCなど一次ソースを参照して教えてください。
【要件】
- 各情報に出典URLを明記
- 推測の場合は「要確認」と注記
- バージョン依存の情報は対象バージョンを明記
- AIの知識カットオフ以降の情報は Web 検索で補完
B2. 概念の理解
{{技術用語}} を教えてください。
【形式】
1. 一言で説明
2. なぜ存在するか（背景・解決する課題）
3. 具体的な使用例
4. 似た概念との違い
5. より深く学ぶためのリソース
B3. 初心者向け解説
{{トピック}} を、中学生にも分かるように説明してください。
【制約】
- 専門用語を使うときは必ず例えを添える
- コード例は動く最小限のもの
- 「なぜそれが必要か」を最初に説明
B4. 比較・違いの整理
{{A}} と {{B}} の違いを表形式で整理してください。
【比較軸】
- 目的
- 使う場面
- メリット / デメリット
- コード例（同じことを両方でやる）
- どちらを選ぶべきかの判断基準
B5. 段階的学習
{{スキル}} を学ぶロードマップを作ってください。
【前提】
- 現在のレベル: {{初心者/中級者}}
- 目標: {{達成したい状態}}
- 使える時間: 1日 {{N}} 時間
【形式】
- ステップを段階的に提示
- 各ステップの所要時間の目安
- 各ステップの学習リソース（公式ドキュメント優先）
- 次のステップに進む判定基準
B6. 最新情報のキャッチアップ
{{技術}} の v{{旧}} → v{{新}} の変更点をまとめてください。
【ソース】
- 公式リリースノート
- 公式アップグレードガイド
【形式】
- 破壊的変更（Breaking Changes）
- 新機能（New Features）
- 非推奨化（Deprecations）
- 既存プロジェクトで特に影響する箇所
各項目に公式ドキュメントの該当セクションへのリンクを添えてください。
B7. 具体例での理解
{{抽象的な概念}} を、具体例で理解したいです。
【希望】
- 日常生活のアナロジー
- コード例（最小限で動くもの）
- 「これが役立つ実際のシーン」
- よくある誤解
C. 思考・意思決定系（6パターン）
C1. 壁打ち・アイデア発散
{{アイデア/課題}} について壁打ちしたいです。
賛成でも反対でもなく、以下の役割で対応してください。
- 深掘り質問を投げる
- 前提の穴を指摘する
- 類似事例を提示する
- 別視点を提案する
結論を急がず、私の思考を整理する手伝いをしてください。
C2. 意思決定サポート
{{選択肢A}} と {{選択肢B}} で迷っています。
【私が大切にしている価値観】
- {{価値観1}}
- {{価値観2}}
【それぞれの状況】
- A: {{状況}}
- B: {{状況}}
各選択肢について、私の価値観に照らした評価・5年後の想定・見落としそうなリスクを
分析してください。最後に「もし私の立場なら」どう決めるかも教えてください。
C3. メリット・デメリット分析
{{選択肢}} のメリット・デメリットを表形式で整理してください。
【制約】
- 各項目に「影響の大きさ（大/中/小）」を付ける
- 短期影響と長期影響を分ける
- 数値化できるものは数値化
- 私が見落としがちな観点も含める
C4. 批判的レビュー
以下の私の案に対して、**意図的に批判的な視点**で穴を指摘してください。
【私の案】
{{案}}
【指摘してほしい観点】
- 論理の飛躍
- 前提の誤り
- 抜けている考慮事項
- 反論されたときの弱点
- 実行時に詰まりそうな箇所
優しさより正確さを優先してください。
C5. 逆質問（Claudeに聞かせる）
{{やりたいこと}} を始めます。
いきなり実装に入らず、まず AskUserQuestion ツールを使って私にインタビューしてください。
技術実装・UI/UX・エッジケース・トレードオフなど、私が見落としそうな観点を深掘りしてください。
全て聞き終わったら、仕様書（SPEC.md）にまとめてください。
C6. 前提条件の整理
以下の私の考えを、前提・論点・結論に分けて構造化してください。
{{自由記述}}
【希望する整理】
- どの前提が揺らぐと結論が変わるか
- 暗黙の前提になっているもの
- 論理の飛躍がある箇所
D. 文章作成系（5パターン）
D1. ブログ記事作成
{{テーマ}} についての技術記事を書きたいです。
【要件】
- 想定読者: {{読者層}}
- 読了時間: 3〜5分
- 構成: 導入 → 本題（段階的難易度） → まとめ
- 具体例・コード例を豊富に
- 主張は公式ドキュメントで裏取り
まず構成案（目次）を提案し、合意後に本文を書いてください。
D2. メール・ビジネス文書
以下の要件で {{メール/報告書}} を書いてください。
【宛先・関係性】
{{上司/顧客/同僚}}
【伝えたい内容】
{{本質的なメッセージ}}
【トーン】
- 丁寧だが冗長にならない
- クッション言葉は最小限
- アクションが明確になる締め
最終的に相手に取ってほしい行動を明記してください。
D3. 要約
以下の長文を要約してください。
【形式】
- 3行サマリー（全体の結論）
- 5つの箇条書き（主要な論点）
- 元の論理構造を崩さない
- 筆者の主張と事実を区別
{{長文}}
D4. 校正・推敲
以下の文章を校正してください。
【チェック観点】
- 誤字脱字
- 文法ミス
- 冗長な表現
- 主述のねじれ
- 論理の飛躍
【出力形式】
- 修正前後の diff
- 修正理由
- 全体の読みやすさスコア（10点満点）
{{文章}}
D5. 翻訳
以下を {{日本語 → 英語 / 英語 → 日本語}} に翻訳してください。
【文脈】
- 用途: {{ブログ/ビジネス/カジュアル}}
- 読者: {{対象}}
【希望】
- 直訳ではなく、自然な表現
- 専門用語は原語のまま残す（必要なら括弧で補足）
- 文化的ニュアンスを意識
{{原文}}
E. キャリア・人生相談系（5パターン）
E1. キャリア相談
キャリアについて相談したいです。結論を急がず、まず私の状況を深掘りしてください。
【現状】
- 職種: {{}}
- 経験年数: {{}}
- 現在の悩み: {{}}
【大切にしている価値観】
- {{}}
私の状況を整理するための質問を投げてください。
十分に情報が集まった段階で、選択肢を整理して提示してください。
E2. 人生相談
人生の大きな選択について相談したいです。
助言を急がず、以下の役割で対応してください。
1. まず私の話を傾聴する姿勢で質問を投げる
2. 私が言語化できていない感情・価値観を言語化する手伝い
3. 最終的な決断は私がするものであることを尊重する
【状況】
{{自由記述}}
E3. 目標設定のサポート
{{達成したいこと}} に向けて目標設定をサポートしてください。
【フレームワーク】
- SMART（Specific, Measurable, Achievable, Relevant, Time-bound）
- 目標を「なぜ」「何を」「どう」の3階層に分解
【出力】
- 最終ゴール（1年後）
- マイルストーン（3ヶ月ごと）
- 今週の具体的アクション
- 進捗を測る指標
E4. 自己分析
自己分析を手伝ってください。
【素材】
- これまでの経歴: {{}}
- 得意なこと: {{}}
- 苦手なこと: {{}}
- 最近やって楽しかったこと: {{}}
【希望】
- 私の強みを5つ言語化（「なぜそれが強みか」の根拠付き）
- 弱みを補う方法 or 弱みを避ける環境
- 私に向いている役割・職種の提案
E5. 学習計画の立案
{{資格/スキル}} を {{期限}} までに習得したいです。学習計画を立ててください。
【前提】
- 現在の知識レベル: {{}}
- 使える時間: 平日{{N}}時間 / 休日{{N}}時間
- 参考書・教材: {{}}
【希望する計画】
- 週単位のマイルストーン
- 定期的な振り返りポイント
- 挫折しそうなときの対処法
F. 感情サポート系（4パターン）
F1. 共感してほしい
これから話すことに対して、**まず共感を示してから**返答してください。
いきなり解決策や助言を出さないでください。
「それは大変だったね」「そう感じるのは自然だよ」など、感情を受け止める姿勢を最初に示してください。
その後、私がアドバイスを求めた場合のみ、具体的な提案をしてください。
{{話したいこと}}
F2. 慰めてほしい
失敗して落ち込んでいます。慰めてください。
【制約】
- 「でも」「しかし」で否定しない
- 安易な励まし（「大丈夫」「なんとかなる」）は避ける
- 私の感情を認めた上で、少しだけ視点を広げる言葉を添える
- 今日やるべきことは「休むこと」と伝えてほしい
{{状況}}
F3. 励ましてほしい
{{挑戦すること}} に向かっています。モチベーションを上げる言葉をください。
【希望】
- 根拠のない励ましではなく、私の過去の実績や努力に基づいた言葉
- 完璧を求めず「小さな一歩」を評価してくれる視点
- 失敗しても続けられるマインドセット
F4. 愚痴を聞いてほしい
愚痴を聞いてほしいだけです。
【ルール】
- 解決策を提示しない
- 「こうしたら？」と言わない
- 「わかる」「それは辛いね」のような相槌だけでOK
- 感情を受け止めることに徹してください
{{愚痴}}
G. 日常タスク系（4パターン）
G1. タスク整理
以下のタスクを優先順位付けしてください。
【タスク一覧】
- {{タスク1}}
- {{タスク2}}
...
【優先度フレームワーク】
- 緊急度 × 重要度マトリクス
- 各タスクの所要時間の目安
- 依存関係（他のタスクの前提になっているか）
【出力】
- 今日やるべき3つ
- 今週中にやるべきこと
- やらない・委任すべきこと
G2. スケジュール作成
以下の予定を踏まえて、{{期間}} のスケジュールを組んでください。
【やること】
- {{タスクA}}: {{所要時間}}
- {{タスクB}}: {{所要時間}}
【制約】
- {{制約条件（休憩時間、会議など）}}
【考慮点】
- 集中力のピーク時間帯に重要タスクを配置
- バッファ時間を15%確保
- 連続作業は90分を超えない
G3. アイデア出し
{{テーマ}} についてアイデアを出してください。
【出力形式】
- 発散フェーズ: 質より量で20個
- 収束フェーズ: 上位5個を選び、各メリット・実現難易度を評価
- 組み合わせ案: 2つ以上を組み合わせた新提案
【制約】
- 「ありがち」を避ける
- 制約を外した発想（お金・時間・倫理の制約がなかったら）も1つ含める
G4. 比較検討（買い物・サービス選び）
{{商品/サービス}} を選ぶのを手伝ってください。
【候補】
- {{A}}
- {{B}}
- {{C}}
【私の優先事項】
1. {{最も重視すること}}
2. {{次に重視すること}}
【比較表】
- 価格
- 性能
- レビュー傾向（公式サイト・Amazon・価格コム等）
- 私の用途に対する向き不向き
- 購入後に後悔しそうなポイント
パターン活用のコツ 🔵
-
{{ }}を必ず埋める — 空欄のままだとClaude は推測で埋めてしまう - 複数パターンの組み合わせOK — 「B1 (確かな情報) + D1 (ブログ執筆)」等
- 自分用にカスタマイズ — 業務で頻出するパターンは、自分用テンプレとして保存
-
スキル化を検討 — 繰り返し使うものは
.claude/skills/に登録すると/skill-nameで呼び出せる（🟡 Claude Code 限定）
まとめ — 明日から使える5つの鉄則
| # | 鉄則 | 信頼度 |
|---|---|---|
| 1 |
検証手段を必ず提供 (tests/screenshots/expected outputs) |
🟢 公式明言 |
| 2 |
2回失敗したら /clear して改善プロンプトで再開 |
🟢 公式明言 |
| 3 | Explore → Plan → Code → Commit の順序を守る | 🟢 公式推奨 |
| 4 | CLAUDE.md は 150 行以内 に刈り込む | 🟡 公式の強い示唆 |
| 5 | 指示には「理由」を添える | 🟢 公式明言 |
参考（一次ソース）
- Best Practices for Claude Code — Anthropic 公式
- Prompting best practices for Claude 4 — Anthropic 公式
- Prompt engineering overview — Anthropic 公式