プロンプトを磨く前に、土台を整える
プロンプトエンジニアリングは「良い出力を引き出す調整作業」ですが、その前に測る基準がなければ改善しているのかどうかが分かりません。公式ガイドは、着手前に次の3つを揃えておくことを前提としています。
成功基準の明確化
ユースケースにおいて「何をもって成功とするか」を具体的に定義する。
実証的なテスト
その基準に照らして、経験的に検証できる仕組みを用意しておく。
改善したい初稿
まず叩き台となるプロンプトを用意する。無ければConsoleのプロンプトジェネレーターが使える。
すべての課題がプロンプトで解けるわけではありません。たとえばレイテンシやコストは、プロンプト調整よりも別のモデルを選ぶ方が手早く改善できることがあります。まず「これはプロンプトで制御可能な問題か？」を見極めましょう。
すべての最新モデルに共通する基本技法
以下は Claude Opus 4.8・Sonnet 5・Fable 5 などの最新モデルすべてに共通する、プロンプト設計の核となる考え方です。
明確に、そして率直に
Claudeは明示的な指示によく応えます。「文脈をほとんど知らない優秀な新入社員」として捉えるのがコツです。あなたの職場の慣習やワークフローを知らない相手に説明するつもりで、望む出力を具体的に伝えましょう。「期待以上」の働きが欲しいなら、それも明言します。
そのプロンプトを、タスクの背景をほとんど知らない同僚に見せて実行してもらう——もし相手が困惑するなら、Claudeも同じように困惑します。
指示に「理由」を添える
「なぜそうしてほしいのか」という背景や動機を添えると、Claudeはゴールをより深く理解し、的を射た応答を返します。Claudeは説明から一般化できるだけの賢さを備えています。
例示を効果的に使う（few-shot / multishot）
出力の形式・トーン・構造を導く最も信頼できる手段が「例示」です。数個の良質な例を添えるだけで、精度と一貫性が向上します。良い例の条件は次の3つ。
関連性（Relevant）
実際のユースケースに近い例を選ぶ。
多様性（Diverse）
エッジケースを含め、意図しないパターンを拾わない程度に変化を持たせる。
構造化（Structured）
各例を <example> タグで囲み、指示文と区別できるようにする。
目安の数
ベストな結果には3〜5個。例の妥当性評価や追加生成もClaudeに頼める。
XMLタグで構造化する
指示・文脈・例・入力変数が混在するプロンプトでは、種類ごとにXMLタグで囲むと Claude が誤解なく解釈できます。一貫した記述的なタグ名を使い、自然な階層があれば入れ子にします。
役割（ロール）を与える
システムプロンプトで役割を設定すると、用途に合わせて振る舞いとトーンが焦点化されます。たった一文でも効果があります。
ロングコンテキストの扱い（20k+ トークン）
長い資料はプロンプトの先頭へ
長文データは、クエリ・指示・例よりも上に置く。末尾に質問を置くと、複雑な複数文書入力で応答品質が最大30%向上したというテスト結果もある。
文書とメタデータをタグで整理
各文書を <document> で囲み、<document_content> や <source> といったサブタグで明確化する。
引用で応答を接地させる
長文タスクでは、作業前に「関連箇所をまず引用させる」ことで、文書内のノイズを切り分けて精度を高められる。
応答の形をコントロールする
最新モデルは以前より簡潔で自然な文体になり、ツール呼び出し後の要約を省くこともあります。可視性が欲しい場合は明示的に指示します。出力形式を操る効果的な方法は次のとおり。
「してはいけないこと」ではなく「してほしいこと」を伝える——これが第一のコツです。加えて次の手も有効です。
最新モデルは数式に既定でLaTeXを使います。プレーンテキストが欲しい場合は、「LaTeXやMathJax、\( \)・$ などの記法を使わず、標準文字（/ ・ * ・ ^）で数式を書く」と明示的に指示します。
「提案」ではなく「実行」させる
最新モデルは指示に忠実です。「変更を提案してくれる？」と言うと、実装ではなく提案だけを返すことがあります。行動してほしいなら、より明示的に指示しましょう。
行動性はプロンプトで調整できる
既定で積極的に動いてほしければ <default_to_action> のような指示を、逆に慎重に振る舞ってほしければ <do_not_act_before_instructions> のような指示を与えます。
最新のOpusはシステムプロンプトへの反応が鋭いため、旧モデル向けの「CRITICAL: 必ずこのツールを使え」といった強い言い回しは過剰発火（overtrigger）を招きます。「〜のときにこのツールを使って」程度の普通の表現に落ち着かせましょう。
並列ツール呼び出しの最適化
最新モデルは独立したツール呼び出しを並列実行します（複数ファイルの同時読み込みなど）。<use_parallel_tool_calls> を添えると成功率をほぼ100%に高められる一方、依存関係のある呼び出しは順次実行するよう促せます。
アダプティブ・シンキングを活かす
最新モデルはアダプティブ・シンキング（thinking: {type:"adaptive"}）を用い、いつ・どれだけ考えるかを effort パラメータとクエリの複雑さに応じて自ら調整します。簡単な問いには直接答え、必要なときだけ深く考えます。
細かい手順より大枠の指示
「徹底的に考えて」の方が、人手で書いた逐次プランより良い推論を生むことが多い。
例示にも思考を織り込む
few-shot例の中で <thinking> タグを使うと、その推論スタイルを一般化する。
自己検証を頼む
「終える前に答えを◯◯の基準で検証して」の一文が、特にコード・数学で誤りを確実に捉える。
考えすぎを抑える
思考が過剰なら、一つの方針を選んで貫くよう促すか、effort を下げる。
思考オフの一部モデルは「think」という語に敏感に反応します。挙動を安定させたいときは consider / evaluate / reason through といった代替語を使うのも手です。
長時間タスクと状態管理
最新モデルは強力な状態追跡能力を持ち、複数のコンテキストウィンドウをまたぐ長期タスクをこなせます。全部を一度にやろうとせず、少しずつ着実に前進するのが特徴です。効果を引き出すための実践は次のとおり。
- 最初のウィンドウは別プロンプトでテストの作成やセットアップスクリプトなど「枠組み作り」に使い、以降のウィンドウで ToDo を反復する。
- テストを構造化形式で管理
tests.jsonのような形で保持させる。「テストの削除・改変は禁止」と念押しすると長期の反復力が上がる。 - 状態はgit・JSON・自由文で使い分け構造化データはJSON、進捗メモは自由文、履歴とチェックポイントはgit。増分的な前進を明示的に依頼する。
- 検証ツールを与えるPlaywright MCPやcomputer useなど、人手のフィードバックなしに正しさを確認できる手段を用意する。
指示がないと、ファイル削除や git push --force のような元に戻しにくい操作を取ることがあります。破壊的・共有システムに影響する操作の前には確認を求めるよう、プロンプトで明示しましょう。