筆者プロフィール: ソフトウェアエンジニア。「知った気にならない。いつまでも学び続ける」を信条に、業務と個人開発の両輪で技術を磨いています。AI 駆動開発で複数の個人開発アプリを構築・運用中。
👉 ポートフォリオ: 筆者ホームページ
この記事は約4分で読めます。
Claude にプロンプトを投げるとき、何を意識すれば結果が劇的に変わるのか？ 本記事では Anthropic 公式のベストプラクティスから「これだけ押さえれば90点取れる3原則」を抽出します。全8記事シリーズの第1回です。
この記事の位置付け
本記事は 全8記事の連載「Claude プロンプト術 完全ガイド」の第1回 です。本記事だけでも独立して読めますが、他の記事と組み合わせるとより理解が深まります（末尾の関連記事参照）。
信頼度の凡例
Anthropic 公式ドキュメントをベースにしていますが、全てが「公式の明言」ではありません。
| 凡例 | 意味 |
|---|---|
| 🟢 公式引用 | 公式ドキュメントの原文を直接引用・翻訳 |
| 🟡 公式記述 | 公式ドキュメントに記載された技術・機能・手順 |
| 🔵 筆者解釈 | 公式情報を筆者が再整理・優先度付けしたもの |
原則1. ゴールデンルール — 「インターン初日」レベルまで具体化 🟢
公式が最初に提示する原則:
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" |
テスト・スクショ・期待出力のいずれかを必ず添える ことで、Claude は自己検証できるようになります。
まとめ — 3原則の優先順位
| 原則 | キーワード | 公式表現 |
|---|---|---|
| 1 | ゴールデンルール | "If they'd be confused, Claude will be too." |
| 2 | コンテキストウィンドウ管理 | "performance degrades as it fills" |
| 3 | 検証手段の提供 | "single highest-leverage thing" |
特に原則3は公式が「単独で最も効果が大きい」と明言しています。今日から使うなら、まず検証手段を添える習慣 から始めてください。
次回予告
次回は 開発ワークフロー（Explore → Plan → Code → Commit の4段階） を解説します。Claude に「いきなりコードを書かせる」のがなぜ危険なのかを、公式の根拠とともにお伝えします。
参考（一次ソース）
関連記事（連載「Claude プロンプト術 完全ガイド」全8回）
- 第1回（本記事）: Claude プロンプト最重要3原則
- 第2回: Claude 開発ワークフロー — Explore → Plan → Code → Commit
- 第3回: Claude プロンプト 開発編11パターン
- 第4回: Claude に伝わる指示の書き方
- 第5回: Claude Code 固有機能の使い分け
- 第6回: Claude プロンプト 思考編13パターン
- 第7回: Claude プロンプト 日常編18パターン
- 第8回: Claude プロンプト術 完全ガイド — 全記事まとめ