Anthropicが公開する「Prompting best practices」は、これまで分散していたプロンプトエンジニアリングのガイドを1ページに統合したリファレンスです。対象はClaude Opus 4.8 / 4.7 / 4.6、Sonnet 4.6、Haiku 4.5。基礎技法から出力制御、ツール使用、思考、エージェントシステムまでをカバーしますが、ここでは特にモデル更新時に「何をチューニングすべきか」という実務視点で整理します。
Opus 4.8で押さえるべき挙動
Opus 4.8は既存の4.7向けプロンプトでそのまま動作しますが、いくつかの挙動はチューニングが必要です。なかでも運用に直結する4点を見ていきます。
応答長の自動キャリブレーション
固定の冗長性ではなく、タスクの複雑さに応じて長さを調整します。単純な照会は短く、オープンエンドな分析は長くなります。特定のスタイルや出力量に依存するプロダクトでは、明示的にプロンプトで調整する必要があります。冗長さを抑えるなら「簡潔で焦点を絞った応答を。本質的でない文脈は省く」といった指示が有効です。
リテラルな指示解釈 重要
Opus 4.8はプロンプトを文字通り・明示的に解釈し、ある項目から別の項目へ暗黙の一般化を行いません。求めていない要求も推測しません。この「リテラルさ」は構造化抽出やパイプラインでの予測可能性につながる一方、広く適用したい指示は「最初のセクションだけでなく全セクションに適用して」のように適用範囲を明示する必要があります。
思考はデフォルトでOFF
Opus 4.8では thinking: {type: "adaptive"} を明示設定しない限り思考は行われません。トリガー挙動はプロンプトでステアリング可能で、大きく複雑なシステムプロンプトでは意図せず思考が頻発することがあります。その場合は「思考はレイテンシを増やす。多段推論が必要な問題でのみ使い、迷ったら直接応答せよ」といったガイドで抑制できます。
ツール使用より推論を優先する傾向
多くのケースでこれは良い結果を生みますが、ツール使用を増やしたい場合はeffortを上げるのが有効なレバーです。high や xhigh ではエージェント検索やコーディングでのツール使用が大幅に増えます。プロンプトで「いつ・どのようにツールを使うか」を明示的に指示することも可能です。
effortレベルの設計
effortパラメータは、知性とトークン消費のトレードオフを調整します。Opus 4.8はこのレベルを厳格に遵守し、特に低い側では指示された範囲にスコープを限定します。浅い推論が観測されたときは、プロンプトで回避するのではなくeffortを high や xhigh に上げるのが正しい対処です。
| effort | 適した用途 |
|---|---|
max | 知性最優先のタスク。収穫逓減・過剰思考のリスクがあり要検証 |
xhigh | ほとんどのコーディング・エージェント用途のベスト設定 |
high | トークンと知性のバランス。知性重視は最低これ |
medium | コスト重視で知性をトレードオフする用途 |
low | 短くスコープの狭いタスク、レイテンシ重視のワークロード |
出力トークンの確保: max や xhigh で動かすときは、サブエージェントとツール呼び出しの余地を確保するため最大出力トークン予算を大きく取ります。64kから開始してチューニングするのが推奨です。
普遍的な基本原則
モデルが変わっても効く基礎技法は、どれも「明確さ」に集約されます。記事はClaudeを「優秀だが自社の規範やワークフローを知らない新入社員」と捉えることを勧めます。Golden ruleは、文脈の薄い同僚にプロンプトを見せて混乱するなら、Claudeも混乱するというものです。
明確かつ直接的に
望む出力形式と制約を具体的に。「期待以上」を望むなら、推測に頼らず明示的に要求する。順序が重要な手順は番号付きリストで示す。
文脈・動機を加える
なぜその挙動が重要なのかを説明すると、Claudeはゴールをよりよく理解し、説明から一般化してくれる。
例を効果的に使う
Few-shotは出力の形式・トーン・構造を操る最も信頼できる手段。3〜5個を、関連性・多様性・構造化（<example>タグ）を満たす形で。
XMLタグで構造化
指示・文脈・例・入力が混在するとき、<instructions> 等のタグで包むと誤解釈が減る。自然な階層はネストする。
長文脈プロンプティング
20k+トークンの大きな文書を扱うときは、長文データをプロンプトの冒頭、クエリや指示・例より上に置きます。末尾にクエリを置くと、複雑なマルチ文書入力で応答品質が最大30%向上するとされます。各文書は <document> に <document_content> と <source> を入れて包み、回答前に関連箇所を引用させるとノイズを切り抜けやすくなります。
出力フォーマットの制御
フォーマットを操る効果的な方法はいくつかあります。第一に「〜するな」より「〜せよ」と伝えること。「markdownを使うな」ではなく「滑らかに流れる散文の段落で構成して」と言う方が効きます。第二にXMLフォーマット指示子を使うこと。第三に、プロンプト自身のスタイルを望む出力に近づけること——プロンプトからmarkdownを減らすと、出力のmarkdownも減ります。
なお最新モデルは数式にLaTeXをデフォルト使用します。プレーンテキストが必要なら、LaTeXやMathJaxなどのマークアップを使わず標準文字で書くよう明示的に指示します。
思考とエージェントシステム
adaptive thinking（4.6 / Sonnet 4.6）は、effortとクエリの複雑度に基づいて思考量を動的に決定します。内部評価ではextended thinkingより高性能とされ、多段ツール使用や長期エージェントループのようなワークロードに向きます。一般的な指示（「徹底的に考えて」）が手書きの手順より良い推論を生むことが多く、終える前に基準に照らして自己検証させると、特にコーディングや数学でエラーを確実に捕捉できます。
エージェント設計では、複数のコンテキストウィンドウをまたぐ作業をファイルシステム・git・JSONで状態管理するのが基本です。コンテキストアウェアネスを持つモデルには、compaction前提なら「トークン予算を理由に早期終了するな」と伝えます。並列ツール呼び出しは明示プロンプトでほぼ100%に引き上げられます。
過去モデル向けプロンプトの棚卸し
移行時に最も見落としやすいのが、旧モデル向けの「アンチ怠惰」プロンプトです。4.6以降のモデルは大幅に積極的になっており、過去に必要だった強い指示はオーバートリガーの原因になります。
同様に、コードレビューのharnessで「高重要度のみ報告」「保守的に」とチューニングしていると、Opus 4.8はその指示を旧モデルより忠実に守り、調査は同じ深さで行いつつ報告を絞ります。これはcapabilityの回帰ではなくharness効果です。recallを取り戻すには、発見段階では網羅性を優先し、確信度フィルタリングを別ステージに分離するよう明示します。
注意点と移行時の落とし穴
知っておくべき制限・変更
- prefill廃止：Claude 4.6モデル以降、最終assistantターンのprefillは非対応（400エラー）
- budget_tokensは非推奨：effort または max_tokensへ移行する
maxeffortは過剰思考に陥ることがあり、知性向上が収穫逓減になる場合がある- Sonnet 4.6のデフォルトeffortは
high。明示設定しないと高レイテンシになりうる - デザインのデフォルト（クリーム背景+セリフ+テラコッタ）は強固。「クリーム使うな」等の一般指示は別の固定パレットに移るだけ。具体的な代替仕様か「4案提示→選択」が有効
まとめ
この統合リファレンスを貫くのは、「曖昧な期待をプロンプトで補うのではなく、モデルの素の挙動を理解してチューニングする」という姿勢です。Opus 4.8はリテラルに指示を解釈し、暗黙の一般化をしません。これは構造化抽出やパイプラインでは精度と予測可能性の向上につながります。
浅い推論が出たらプロンプトで回避せずeffortを上げる、思考が必要ならadaptive thinkingを明示設定する、旧モデル向けの強制表現は棚卸しする——この3つを押さえるだけで、モデル更新時の「なんか挙動が変わった」という戸惑いの多くは解消できます。