公式Docから紐解く、Claudeへのプロンプトのベストプラクティス
はじめに
最近、コンテキストエンジニアリングが大事と言われていますよね。それは勿論のことなのですが、AI Agentサービスを作成する上で、プロンプトエンジニアリングも依然として重要です。
本記事では、Anthropic公式ドキュメント「Prompting best practices」を元に、Claude Opus 4.6 / Sonnet 4.6 / Haiku 4.5 に対するプロンプトエンジニアリングのベストプラクティスを体系的にまとめました。
対象読者は、ClaudeのAPIを活用してアプリケーションやAI Agentを構築しているエンジニアです。
結論
Claudeへのプロンプトで最も大切なことは以下の3つです。
- 明確かつ具体的に指示する — 曖昧な表現を避け、何をどう出力してほしいかを具体的に書く
- XMLタグで構造化する — 指示・コンテキスト・例・入力を明確に分離する
- モデルの特性を理解して調整する — Claude 4.6世代は積極的に行動する傾向があるため、以前のモデル向けに書いた「強い促し」は逆効果になりうる
以下、公式ドキュメントの各セクションに沿って詳しく見ていきます。
1. 基本原則(General Principles)
1-1. 明確かつ直接的に伝える
Claudeは明確で具体的な指示に対して的確に応答します。公式ドキュメントでは、Claudeを「優秀だがあなたの業務のコンテキストを持たない新入社員」に例えています。
ゴールデンルール: 自分のプロンプトを、タスクについてほとんど文脈を知らない同僚に見せてみてください。その同僚が混乱するなら、Claudeも同様に混乱します。
具体的に意識するポイントは以下の通りです。
- 出力フォーマットと制約を明示する
- 手順の順序や網羅性が重要な場合は、番号付きリストやバレットポイントで指示を記述する
悪い例:
ダッシュボードを作って
良い例:
TypeScript + Next.jsでアナリティクスダッシュボードを作成してください。
以下の要件を満たしてください:
1. 日別/週別/月別のフィルタリングが可能なチャート
2. KPIカードにはDAU、MAU、リテンション率を表示
3. レスポンシブ対応
4. Rechartsを使用すること
1-2. コンテキスト(背景・動機)を与える
「なぜその指示を出しているのか」を伝えると、Claudeは目的をより正確に理解して応答します。
<context>
このAPIレスポンスはモバイルアプリで表示されます。
ネットワークが不安定な環境のユーザーも多いため、
レスポンスサイズは最小限に抑えてください。
</context>
動機を説明するだけで、Claudeはそこから汎化して適切な判断を下してくれます。
1-3. 例を効果的に使う(Few-shot Prompting)
例(Few-shot)は、Claudeの出力フォーマット・トーン・構造を制御する最も信頼性の高い方法の一つです。
効果的な例の条件は以下の通りです。
- 関連性がある: 実際のユースケースに近い内容にする
- 多様性がある: エッジケースをカバーし、意図しないパターンの学習を防ぐ
-
構造化されている:
<example>タグで囲み、指示と区別できるようにする
3〜5個の例を用意すると最も効果的です。また、Claudeに例の妥当性や多様性を評価してもらったり、追加の例を生成してもらうことも有効です。
<examples>
<example>
<input>NestJSのGuardとは何ですか?</input>
<output>GuardはNestJSにおける認可の仕組みです。リクエストが特定のルートにアクセスできるかどうかを、実行時に判断します。`@UseGuards()` デコレータで適用します。</output>
</example>
<example>
<input>NestJSのInterceptorとは何ですか?</input>
<output>Interceptorはリクエスト/レスポンスのパイプラインに割り込む仕組みです。ロギング、レスポンスの変換、例外のマッピングなどに活用されます。</output>
</example>
</examples>
1-4. XMLタグでプロンプトを構造化する
XMLタグは、Claudeが複雑なプロンプトを曖昧さなく解析するのに役立ちます。指示、コンテキスト、例、可変入力をそれぞれ専用のタグで囲むことで、誤解を減らせます。
ベストプラクティスは以下の通りです。
- 一貫性のある説明的なタグ名を使う(例:
<instructions>,<context>,<input>) - コンテンツに自然な階層がある場合はタグをネストする
<documents>
<document index="1">
<source>requirements.md</source>
<document_content>...</document_content>
</document>
<document index="2">
<source>architecture.md</source>
<document_content>...</document_content>
</document>
</documents>
<instructions>
上記のドキュメントを元に、NestJSのモジュール設計を提案してください。
</instructions>
1-5. Claudeに役割(ロール)を与える
システムプロンプトでロールを設定すると、Claudeの振る舞いとトーンが特定のユースケースに最適化されます。一文でも効果があります。
message = client.messages.create(
model="claude-opus-4-6",
max_tokens=1024,
system="You are a senior TypeScript engineer specializing in NestJS and AWS infrastructure.",
messages=[
{"role": "user", "content": "DynamoDBのシングルテーブル設計のパターンを教えて"}
],
)
1-6. 長いコンテキストのプロンプト
20K+ トークンを超えるような大量のドキュメントを扱う場合は、以下のポイントを押さえてください。
- 長文データはプロンプトの先頭に配置する: ドキュメントや入力データを上部に、クエリや指示をその後に配置します。テストでは最大30%の品質向上が確認されています。
-
ドキュメントをXMLタグで構造化する: 複数ドキュメントには
<document>タグとメタデータ用のサブタグを使う - 引用ベースで回答させる: 長いドキュメントに対しては、先に関連部分を引用してからタスクを実行するように指示すると、ノイズの多い文書でも精度が上がります
2. 出力とフォーマット制御(Output and Formatting)
2-1. コミュニケーションスタイルと冗長性
Claude最新モデルのコミュニケーションスタイルは以前より簡潔で自然です。
- より直接的: 自己賞賛的な更新ではなく事実ベースの進捗報告をする
- より会話的: 機械的ではなく流暢で口語的
- より簡潔: 効率のため詳細な要約をスキップすることがある
ツール使用後の推論過程を可視化したい場合は、明示的に指示してください。
ツール使用を伴うタスクの完了後、行った作業の簡単なサマリーを提供してください。
2-2. レスポンスフォーマットの制御
フォーマット制御には4つの効果的なアプローチがあります。
① 「しないこと」ではなく「すること」を伝える
# ❌
マークダウンを使わないでください
# ✅
滑らかに流れる散文のパラグラフで応答を構成してください。
② XMLフォーマットインジケータを使う
レスポンスの散文部分を <smoothly_flowing_prose_paragraphs> タグ内に記述してください。
③ プロンプトのスタイルを出力スタイルに合わせる
プロンプト自体のフォーマットスタイルがClaudeのレスポンスに影響します。マークダウンを減らしたい場合は、プロンプトからもマークダウンを除去すると効果的です。
④ 詳細な指示を与える
過度なマークダウンやバレットポイントを避けたい場合のプロンプト例:
<avoid_excessive_markdown_and_bullet_points>
レポート、ドキュメント、技術説明、分析、その他の長文コンテンツを書く際は、
完全なパラグラフと文章で明確に流れる散文で記述してください。
箇条書きや番号付きリストは以下の場合にのみ使用してください:
a) リスト形式が最適な離散的なアイテムを提示する場合
b) ユーザーが明示的にリストやランキングを要求した場合
</avoid_excessive_markdown_and_bullet_points>
2-3. LaTeX出力について
Claude Opus 4.6は数式にデフォルトでLaTeXを使用します。プレーンテキストが必要な場合は明示的に指示してください。
2-4. Prefilled Responsesの廃止
Claude 4.6モデルから、最後のアシスタントターンでの事前入力(prefill)はサポートされなくなりました。以下のようなユースケースには代替手法を使います。
- 出力フォーマット制御 → システムプロンプトやXMLタグで指定
- 前置きの排除 → 「前置きや導入なしで直接回答してください」と指示
- 不要な拒否の回避 → ロールやコンテキストをシステムプロンプトで設定
- 継続処理 → 「前回の続きから再開してください」と指示
3. ツール使用(Tool Use)
3-1. 明示的にツール使用を指示する
Claude最新モデルは指示に忠実に従うため、「変更を提案してもらえますか?」と言うと提案だけで終わることがあります。実際にアクションを起こしてほしい場合は明示してください。
# ❌
何か改善点を提案してもらえますか?
# ✅
このコードの改善点を見つけ、実際にファイルを編集して修正を実装してください。
デフォルトで積極的にアクションを起こすようにするプロンプト:
<default_to_action>
提案だけでなく、デフォルトで変更を実装してください。
ユーザーの意図が不明な場合は、最も有用なアクションを推測して実行し、
不足する詳細はツールを使って調べてください。
</default_to_action>
逆に慎重に行動させたい場合:
<do_not_act_before_instructions>
明確に変更の指示がない限り、ファイルの編集や実装に着手しないでください。
ユーザーの意図が曖昧な場合は、情報提供・調査・推奨にとどめてください。
</do_not_act_before_instructions>
注意: Claude Opus 4.5 / 4.6はシステムプロンプトへの反応性が以前のモデルより高いです。以前のモデル向けに「CRITICAL: You MUST use this tool when...」のような強い表現を使っていた場合、過剰にツールが発動する可能性があります。「Use this tool when...」程度の通常の表現に修正してください。
3-2. 並列ツール呼び出しの最適化
Claude最新モデルは並列ツール実行に優れています。依存関係のないツール呼び出しを同時に実行します。
<use_parallel_tool_calls>
複数のツールを呼び出す予定で、ツール呼び出し間に依存関係がない場合は、
すべての独立したツール呼び出しを並列で実行してください。
例えば、3つのファイルを読む場合は、3つのツール呼び出しを並列で実行し、
同時に3つのファイルをコンテキストに読み込んでください。
ただし、前のツール呼び出しの結果に依存するパラメータがある場合は、
並列ではなく順次実行してください。
プレースホルダの使用や、パラメータの推測は決して行わないでください。
</use_parallel_tool_calls>
4. 思考と推論(Thinking and Reasoning)
4-1. 過剰な思考への対処
Claude Opus 4.6は以前のモデルよりも大幅に多くの事前探索を行います。これは品質向上に寄与しますが、不要に深掘りする場合もあります。
対処法は以下の通りです。
- 包括的な指示を具体的な指示に置き換える: 「デフォルトで[ツール]を使って」ではなく「[ツール]が問題の理解を深める場合に使って」
- 過剰な促しを削除する: 以前のモデルで発動不足だったツールは、今は適切に発動するはず。「迷ったら[ツール]を使え」は過剰発動を引き起こす
-
effortパラメータを調整する: それでも積極的すぎる場合は、effortを低く設定する
思考トークンの膨張を抑えたい場合のプロンプト例:
問題へのアプローチを決める際は、一つのアプローチを選んでコミットしてください。
推論に直接矛盾する新情報が出ない限り、決定を再検討しないでください。
2つのアプローチで迷った場合は、1つを選んで最後までやり通してください。
選んだアプローチが失敗した場合はその後で軌道修正できます。
4-2. Adaptive Thinkingの活用
Claude Opus 4.6はAdaptive Thinking(thinking: {type: "adaptive"})を使用します。Claudeがいつ、どの程度思考するかを動的に判断します。
主な推奨事項は以下の通りです。
- 一般的な指示を具体的な手順より優先する: 「徹底的に考えて」の方が、手書きのステップバイステップ計画より良い推論結果を生むことが多い
-
Few-shot例にthinkingを含める:
<thinking>タグをFew-shot例に含めると、Claudeはその推論パターンを拡張思考ブロックにも般化する - セルフチェックを依頼する: 「完了前に[テスト基準]に対して回答を検証してください」を追加すると、特にコーディングや数学でエラーを確実にキャッチできる
# Adaptive Thinkingの設定例
client.messages.create(
model="claude-opus-4-6",
max_tokens=64000,
thinking={"type": "adaptive"},
output_config={"effort": "high"}, # max, high, medium, low
messages=[{"role": "user", "content": "..."}],
)
5. エージェントシステム(Agentic Systems)
5-1. 長期推論とステート管理
Claudeの最新モデルは、長期間にわたる推論タスクで優れたステート追跡能力を発揮します。一度にすべてを行うのではなく、いくつかのことに集中しつつ着実に進む形で増分的に進捗します。
コンテキストウィンドウの管理
Claude 4.6 / 4.5モデルはコンテキスト認識機能を備えており、残りのコンテキストウィンドウ(トークン予算)を追跡できます。エージェントハーネスでコンテキストのコンパクション(圧縮)を行う場合は、以下のように伝えてください。
あなたのコンテキストウィンドウは上限に近づくと自動的にコンパクションされ、
中断したところから無期限に作業を続けられます。
したがって、トークン予算の懸念からタスクを早期に中断しないでください。
トークン予算の上限に近づいたら、コンテキストウィンドウがリフレッシュされる前に
現在の進捗と状態をメモリに保存してください。
常にできるだけ自律的かつ粘り強く、タスクを完全に完了させてください。
マルチコンテキストウィンドウのワークフロー
タスクが複数のコンテキストウィンドウにまたがる場合のベストプラクティスは以下の通りです。
- 最初のコンテキストウィンドウでフレームワークを構築する: テストを書き、セットアップスクリプトを作成し、以降のウィンドウでTodoリストを消化する
-
構造化されたフォーマットでテストを記述させる: 作業開始前にテストを作成し、
tests.jsonのような構造化形式で管理する -
QOLツールをセットアップする: サーバー起動やテストスイート実行のスクリプト(例:
init.sh)を作成させる - gitでステート管理する: gitは作業ログとチェックポイントを提供し、Claudeの最新モデルはgitを使ったステート管理に特に優れている
- 検証ツールを提供する: Playwright MCPサーバーやcomputer use機能などを活用
5-2. 自律性と安全性のバランス
Claude Opus 4.6はガイダンスなしでは、ファイル削除やforce pushなど元に戻しにくいアクションを取る可能性があります。リスクのあるアクション前に確認を求めたい場合は、以下のようなプロンプトを追加してください。
アクションの可逆性と潜在的な影響を考慮してください。
ファイル編集やテスト実行のようなローカルで可逆的なアクションは推奨しますが、
元に戻しにくいアクション、共有システムに影響するアクション、
破壊的な可能性のあるアクションについては、実行前にユーザーに確認してください。
確認が必要なアクションの例:
- 破壊的操作: ファイルやブランチの削除、DBテーブルのドロップ、rm -rf
- 元に戻しにくい操作: git push --force, git reset --hard
- 他者に見える操作: コードのプッシュ、PR/issueへのコメント、メッセージの送信
5-3. サブエージェントのオーケストレーション
Claude最新モデルはサブエージェントの必要性を認識し、明示的な指示なしでも積極的にタスクを委譲します。ただし、Claude Opus 4.6はサブエージェントを過剰に使用する傾向があります。
シンプルなタスクにサブエージェントが過剰に生成される場合は、以下のように使い分けの指針を示してください。
サブエージェントは、タスクが並列実行可能な場合、隔離されたコンテキストが必要な場合、
または独立したワークストリームの場合に使用してください。
シンプルなタスク、順次操作、単一ファイルの編集、
またはステップ間でコンテキストを維持する必要がある場合は、
委譲せずに直接作業してください。
5-4. 過剰エンジニアリングへの対処
Claude Opus 4.5 / 4.6は、不要なファイルを作成したり、要求されていない抽象化や柔軟性を追加する傾向があります。
<avoid_overengineering>
過剰エンジニアリングを避けてください。
直接要求されたか、明らかに必要な変更のみを行ってください。
- スコープ: 要求されていない機能追加、リファクタリング、「改善」を行わない
- ドキュメント: 変更していないコードにdocstringやコメントを追加しない
- 防御的コーディング: 起こり得ないシナリオへのエラーハンドリングを追加しない
- 抽象化: 一度しか使わない操作にヘルパーやユーティリティを作成しない
</avoid_overengineering>
5-5. ハルシネーションの最小化
エージェントコーディングにおけるハルシネーションを抑制するためのプロンプト:
<investigate_before_answering>
開いていないコードについて推測しないでください。
ユーザーが特定のファイルを参照した場合、回答前にそのファイルを必ず読んでください。
コードベースに関する質問には、関連ファイルを調査してから回答してください。
調査済みでない限り、コードに関する主張は一切行わないでください。
根拠のある、ハルシネーションのない回答を提供してください。
</investigate_before_answering>
6. Claude 4.6への移行時の注意点
以前のモデルからClaude 4.6に移行する際の重要なポイントです。
- 望む出力を具体的に記述する: 例えば「ダッシュボードを作って」ではなく「関連する機能やインタラクションをできる限り多く含めてください。基本を超えた完全な機能実装を目指してください」と修飾子を付ける
-
Thinking設定を更新する: Claude 4.6モデルはAdaptive Thinking(
thinking: {type: "adaptive"})を使用する。budget_tokensの代わりにeffortパラメータで思考の深さを制御する - Prefilled Responsesから移行する: Claude 4.6から非サポート
- 反怠惰プロンプトを調整する: 以前のモデル向けに「もっと徹底的に」「積極的にツールを使え」と書いていた場合は表現を弱める。Claude 4.6は既に十分に積極的
Sonnet 4.5 → Sonnet 4.6への移行
Claude Sonnet 4.6のデフォルトeffortは high です。Sonnet 4.5から移行する場合、明示的にeffortを設定しないとレイテンシが増加する可能性があります。
推奨設定は以下の通りです。
-
ほとんどのアプリケーション:
medium -
大量処理/低レイテンシ:
low - 最も困難で長期的な問題: Opus 4.6の使用を検討
# コーディングユースケース(エージェントコーディング、ツール多用)
client.messages.create(
model="claude-sonnet-4-6",
max_tokens=16384,
thinking={"type": "enabled", "budget_tokens": 16384},
output_config={"effort": "medium"},
messages=[{"role": "user", "content": "..."}],
)
# チャット・非コーディングユースケース
client.messages.create(
model="claude-sonnet-4-6",
max_tokens=8192,
thinking={"type": "enabled", "budget_tokens": 16384},
output_config={"effort": "low"},
messages=[{"role": "user", "content": "..."}],
)
まとめ
Claude 4.6世代のプロンプトエンジニアリングでは、「以前のモデルに比べてClaudeが賢く積極的になっている」 という前提を常に持つことが重要です。
以前のモデルでは必要だった「強い促し」が、今のモデルでは過剰な行動を引き起こす原因になります。プロンプトは引き算の発想で最適化していくのが、Claude 4.6時代のベストプラクティスと言えるでしょう。
ポイントの整理:
- 明確かつ具体的な指示 + XMLタグによる構造化が基本
- Few-shot例は3〜5個で出力を安定させる
-
effortパラメータとAdaptive Thinkingで思考コストを制御する - エージェント用途では安全性ガードレールを明示的に設定する
- 以前のモデル向けの過剰な促しはClaude 4.6では逆効果
公式ドキュメントは随時更新されるため、最新情報はこちらを確認してください。