ブログ/Claude Sonnet 4.6 のプロンプト設計のコツ

Claude Sonnet 4.6 のプロンプト設計のコツ

約24分で読めます

Claude Sonnet 4.6 は、性能・コスト・速度のバランスが良く、業務用途で広く使われてきたモデルです。本記事では、Sonnet 4.6 の特性に合わせたプロンプト設計のコツを、API 側の設定と併せて解説します。

なお、Anthropic はその後 Claude Sonnet 5 を公開しており、Sonnet 4.6 は世代としては一つ前になりました。ただし Sonnet 4.6 は引き続き利用可能で、既存のプロンプト資産がそのまま動くという実務上の利点があります。動いているものを急いで移行する必要はありません。本記事の内容は Sonnet 4.6 を前提に書いていますが、設計の考え方は後継モデルにもそのまま通用します。

Sonnet 4.6 の特性

主な特徴:

  • 指示への忠実度が高い: システムプロンプトの守りが強い
  • 構造化出力に強い: JSON / XML / Markdown を安定して生成
  • 長文への対応: コンテキスト処理の安定性が高い
  • コードと文章の両方: ソフトウェアエンジニアリングと業務文書の両方で実用レベル
  • コスト効率: Opus 系より大幅に安く、Haiku 4.5 より高品質

「業務で広く使う第一選択肢」と思っておけば、ほぼ問題ありません。

押さえておく基本仕様

項目Sonnet 4.6
コンテキストウィンドウ1M トークン
最大出力トークン128K（大きな値を使う場合はストリーミングが必要）
思考設定adaptive thinking（推奨）／無効化も可
effort（思考の深さ）low / medium / high / max（既定は high）
プレフィル（最終assistantターン）非対応（エラーになる）

仕様は更新されることがあるため、実装前に公式ドキュメントで最新の値を確認してください。特に価格と上限値は変わる可能性があります。

API 設定で押さえる4点

プロンプトの文面を磨く前に、API 側の設定を正しくしておく方が効果が大きい場面があります。ここを外していると、プロンプトをいくら直しても改善しません。

1. 思考は「文言」でなく「設定」で制御する

Sonnet 4.6 では、思考の有無と深さを API のパラメータで指定できます。プロンプト本文に「ステップバイステップで考えてください」と書くより、adaptive thinking を有効にする方が確実です。adaptive thinking では、モデルがタスクの複雑さに応じて思考量を自分で調整します。

古い書き方として、思考に使うトークン数を固定値で指定する方法がありますが、Sonnet 4.6 ではこの指定は非推奨です。代わりに effort（後述）で深さを調整してください。

2. effort で深さとコストを調整する

effort は思考の深さと全体のトークン消費を制御するパラメータです。Sonnet 4.6 では low / medium / high / max が使え、指定しない場合は high になります。

設定向いている用途
low分類、単純な抽出、定型文の生成。レイテンシ重視
medium多くの業務タスクのバランス点
high既定値。判断や多段階の検討を含むタスク
max正確性がコストより重要な場面。過剰に考え込むこともある

重要なのは、指定しないと high で動く という点です。分類のような軽いタスクを何も指定せずに大量実行すると、必要以上のコストと待ち時間が発生します。用途ごとに明示的に設定してください。

3. 出力形式は API 側で固定できる

JSON など厳密な形式が必要な場合、プロンプトでの指示だけに頼らず、構造化出力（スキーマ指定） を使う方が確実です。スキーマを渡すと、出力がそのスキーマに沿うことが保証されます。

プロンプトでの「JSON で出力してください」は、守られる確率が高いだけで保証ではありません。後続の処理がパースに失敗する前提のコードになっているなら、API 側の機能に置き換える価値があります。

4. プレフィルは使えない

出力の書き出しをこちらで与えて誘導する手法（最後に assistant のターンを置く方法）は、Sonnet 4.6 では エラーになります。以前のモデル向けに書かれたコードを移してくると、ここで詰まります。

代替はシンプルです。

プレフィルの目的代替
JSON を強制する構造化出力（スキーマ指定）
分類ラベルを固定する列挙型のスキーマ、または選択肢を明示した指示
「以下が要約です：」等の前置きを省くシステムプロンプトで「前置きなしで本文から始める」と指示
途中で切れた出力の続きを書かせるユーザーターンで「直前の出力は〜で終わっています。続きを書いてください」

効くプロンプトの 5 パターン

パターン 1: 構造化指示

Sonnet 4.6 は Markdown 見出しや番号付きリストを使った構造化指示によく従います。

# 役割
あなたは営業支援アシスタントです。

# タスク
以下の議事録から決定事項とネクストアクションを抽出してください。

# ルール
1. 議事録に明示されている内容のみ
2. 推測は禁止
3. 出力は JSON 形式

# 議事録
{{minutes}}

明確なセクション分けが Sonnet では効きます。加えて、処理対象（この例なら議事録）は最後に置く のが定石です。長い入力の後に指示を書くと、指示が埋もれることがあります。入力が長いときほど、この順序が効きます。

パターン 2: ロール定義 + トーン指定

具体的な役割とトーンを指定すると、出力の一貫性が上がります。

あなたは {{company}} のサポート担当（敬語ベース、絵文字なし）として、
以下の問い合わせに対応してください。

ここでのコツは、肩書きより判断基準を書く ことです。「あなたは優秀な〇〇です」という修飾はほとんど効きません。効くのは「何を優先して判断するか」の指定です。

（効きにくい）
あなたは優秀なマーケターです。この施策を評価してください。

（効く）
予算配分を決める立場のマーケティング責任者として評価してください。
実行可能性とコストを優先し、新規性は評価軸に入れないでください。

パターン 3: 出力フォーマットの明示

JSON や表形式の出力は、フォーマット例を明示すると安定します。

出力例:
{
  "category": "feature_request",
  "summary": "...",
  "urgency": "high|medium|low"
}

形式の揺れが業務に影響する場合は、この方法ではなく前述の構造化出力を使ってください。フォーマット例は「安定させる工夫」であって「保証」ではない という区別が重要です。

表形式で出す場合は、列名・列の順序・行数の上限まで指定すると揺れが止まります。

以下の列を持つ表で出力してください:
施策名 / 想定コスト / 実行難易度（高中低） / 推奨度（1〜5）
行は5つまで。表の下に、推奨度1位の理由を3行で書いてください。

パターン 4: 制約付き思考（CoT 控えめ）

Sonnet は素のままで内部的に推論を行うので、CoT は 長く書くより簡潔に する方が効率的です。

判断手順:
1. 入力を分類する
2. 該当ルールを選ぶ
3. ルールに従って出力

各ステップは 30 字以内で記述してから最終出力。

思考の「量」は effort で、思考の「順序」はプロンプトで、という分担で考えると整理しやすくなります。プロンプトに書くべきは、どの順序で何を検討するか という手順そのものです。「よく考えて」「慎重に」といった言葉は、手順の指定にはなりません。

パターン 5: 否定形より肯定形

「〜しないでください」より「〜してください」の方が効きやすいです。

# 弱い指示
専門用語を使わないでください。

# 強い指示
中学生でも理解できる平易な言葉で書いてください。

ただし、禁止事項そのものが重要な場面（社外に出せない情報、書いてはいけない断定）では、否定形でも明記してください。その場合も 禁止は3つ程度に絞る のが実務的です。禁止事項を10個並べると互いに競合し、優先すべきものが薄まります。

苦手領域と回避策

苦手 1: 数値計算

複雑な計算（消費税、稼働日、料金計算）はミスが出ます。

回避策: 計算は別途プログラム化、AI は「式の組み立てだけ」を担当する分業に。検算が必要な用途では、計算結果をそのまま採用せず、必ず人かプログラムで確認する工程を挟んでください。

苦手 2: 厳密な日時推論

「3 営業日後」「翌月初」などの推論は不安定です。

回避策: 今日の日付をプロンプトに明示し、出力で「YYYY-MM-DD 形式」を要求。祝日や自社の営業日カレンダーが絡む場合は、カレンダー情報を入力として渡すか、計算自体をプログラム側に持たせてください。

苦手 3: 自由創作の長文

小説や詩の長文生成は、長くなるほど一貫性が落ちます。

回避策: 章単位で分割して生成、章間を別プロンプトで統合。

苦手 4: 事実の網羅性が求められる調査

学習データに含まれない情報や、最新の事実は答えられません。「知らない」と言わずにそれらしく埋めることもあります。

回避策: 事実は入力として渡すか、検索機能を併用してください。プロンプト側で「知らない場合は『不明』と書く」と明示するのも有効ですが、それだけに頼らない設計にしてください。

苦手 5: 曖昧な指示からの意図の補完

指示が曖昧なとき、それらしい解釈で進めてしまいます。結果として、求めていたものと違う成果物が返ってきます。

回避策: 「何のために使う出力か」を書いてください。目的が書かれた瞬間に、何を残し何を削るかの判断ができるようになります。

（曖昧）
この議事録をまとめて。

（目的つき）
この議事録から、明日の経営会議で報告する内容をまとめてください。
報告先は役員3名で、判断してほしいのは予算の追加承認の可否です。

1M context への乗せ方の基本

Sonnet 4.6 は 1M トークンのコンテキストウィンドウを持ちます。長文を扱う時のコツ:

  1. 章立てを明示: Markdown 見出しで構造を示す
  2. TL;DR を各章先頭に: 5 行程度の要約を置く
  3. 索引を文書冒頭: どこに何があるかを示す
  4. 重要情報は冒頭か末尾: 中央の情報は取りこぼされやすい
  5. Prompt Caching を活用: 同じ長文を複数回使うならコストが激減

入れれば入れるほど良い、ではない

コンテキストが大きいからといって、関連しそうな資料を全部入れるのは逆効果です。関係のない情報が増えるほど、必要な情報の相対的な重みが下がります。

判断の目安は「この情報がなければ答えられないか」です。あると便利な程度の資料は外し、必須のものだけを入れてください。どうしても量が必要なら、索引と見出しで構造を与えるのが前提になります。

質問は入力の後ろに置く

長い資料と質問を同時に渡す場合、質問は資料の後ろに置いてください。前に置くと、長い資料を読む間に指示が薄まることがあります。

詳しくは別記事「Claude の 1M コンテキストを活かす情報設計の実践」を参照ください。

動画で見る：プロンプトを社内で回す仕組み（Fitsel AI の無料AI講座） →

Prompt Caching の実務

同じ長文を繰り返し使う運用では、プロンプトキャッシュがコストに直結します。押さえるべきは1点だけです。

キャッシュは前方一致です。プロンプトの先頭から一致する部分だけが再利用されます。

ここから実務上の注意がすべて導けます。

やってはいけないことなぜ壊れるか
システムプロンプトの冒頭に現在日時を入れる毎回先頭が変わり、以降すべてがキャッシュ対象外になる
実行IDやセッションIDを先頭に入れる同上
リクエストごとにツールの並び順が変わるツール定義は先頭側にあるため、順序が変わると全体が無効化される
条件分岐でシステムプロンプトの一部を出し入れする分岐の組み合わせごとに別のキャッシュになる

安定して変わらないものを前に、毎回変わるものを後ろに ——これだけを守れば、キャッシュはおおむね機能します。日時やユーザー情報など動的な要素は、システムプロンプトではなく後方のメッセージに入れてください。

キャッシュが効いているかは、レスポンスに含まれるキャッシュ読み込みトークン数で確認できます。同じ先頭を持つリクエストを繰り返しているのにゼロのままなら、どこかに毎回変わる要素が混ざっています。

モデル選択の判断軸

シナリオ推奨
業務全般のデフォルトSonnet 系
複雑な推論・長時間の自律作業・大規模なコード改修Opus 系
大量バッチ・低コスト処理・分類Haiku 4.5

迷ったら Sonnet で始めて、品質不足なら Opus、コスト課題なら Haiku に切り替えるのが現実的です。

世代を上げるかどうかの判断

Sonnet 4.6 から後継の Sonnet 5 へ移行するかは、次の観点で判断してください。

  • 今の出力に不満がないなら、急がなくてよい：Sonnet 4.6 は引き続き使えます
  • 移行するなら再測定が必要：世代が変わるとトークンの数え方や既定の挙動が変わることがあり、コストと出力の傾向が変わります。移行前後で同じ入力を流して比べてください
  • プロンプトの前提が変わることがある：前の世代向けに書いた「回りくどい指示」が、新しい世代では過剰になることがあります

いずれの場合も、まず1つのルートで試してから全体を切り替える のが安全です。

よくある失敗

「あなたは優秀な〇〇です」だけで済ませている

肩書きの修飾はほとんど効きません。効くのは判断基準の指定です。役割を書くなら、何を優先し何を評価軸に入れないかまで書いてください。

effort を設定していない

指定しないと high で動きます。分類のような軽いタスクを大量に流すなら、明示的に下げてください。逆に、判断を含むタスクで出力が浅いと感じたら、プロンプトを直す前に effort を上げてみてください。

前提を渡さずに指示だけ磨いている

一般論しか返ってこないときの原因は、ほぼ前提の不足です。業種・規模・直近の状況・制約を渡してください。言い回しをいくら直しても変わりません。

1つのプロンプトに複数タスクを詰めている

「要約して、課題を抽出して、対策を3つ出して、優先順位もつけて」は4タスクです。後半ほど雑になります。出力の形式が途中で変わるなら、別のプロンプトに分けてください。

出力をそのまま業務に流している

数値計算と日付推論は苦手領域です。ここを含む出力は、必ず確認工程を挟んでください。

まとめ

  • Sonnet 4.6 は世代としては一つ前だが、引き続き使える。急いで移行する必要はない
  • 思考の深さはプロンプトの文言でなく API の設定（adaptive thinking と effort）で制御する
  • effort は指定しないと high。軽いタスクでは明示的に下げる
  • 厳密な形式が必要なら、プロンプトの指示ではなく構造化出力を使う
  • プレフィルは使えない。目的別に代替手段へ置き換える
  • 役割は肩書きでなく判断基準で書く。禁止事項は3つ程度に絞る
  • 長文は「入れるほど良い」ではない。必須のものだけを、構造を与えて渡す
  • キャッシュは前方一致。変わらないものを前、変わるものを後ろ

関連ガイド

PrompTune で運用する

PrompTune の 無料診断ツール は Claude Haiku 4.5 で稼働しており、5 軸でプロンプト品質をスコアリングします。プロンプトを試す前に診断にかけることで、Sonnet での出力品質を予測できます。

Related

ガイド · 部署別

部署別 業務AI活用 完全ガイド｜営業・CS・人事・法務の典型シーンと共通設計原則

営業・カスタマーサクセス・人事・法務の4部署における業務AI活用シーンを横断的に整理。部署共通の設計原則と、個別部署の業務特性を網羅した、部署別AI活用の決定版ガイドです。

AIっぽさ · 文章術

AIっぽい文章の特徴15と直し方｜“AI臭”を消して自然な文章にする完全ガイド

「この文章、AIっぽい」と言われる原因を、語り口・具体性・視点・構文・読み手適合の5要素×15の特徴に分解して解説。ChatGPT・Claudeが書いた文章を、読み手に違和感を与えない自然な文章に直す具体的な方法と、全文Before/After実例、用途別の直す優先順位まで紹介します。

ガイド · 業界別

業界別 業務AI活用 完全ガイド｜19業界の典型シーンと共通設計原則

不動産・医療・EC・教育・金融・会計・製造・物流・建設・小売・宿泊・士業・飲食・介護・自治体・IT受託・広告・人材・出版の19業界における業務AI活用シーンを横断的に整理。業界共通の設計原則と、個別業界の特殊事情の両方を網羅した、業界別AI活用の決定版ガイドです。