Claude Sonnet 5.5のプロンプトガイド — 前置き思考なしと検証の書き方

Sonnet 5.5のプロンプトは何を足し、何を消すか

Sonnet 5のプロンプトは、そのまま5.5でも動く見込みです。ただし挙動の癖は変わっています。低いeffortでは途中で確認を取りたがり、ユーザーの割り込みメッセージを注入攻撃と疑い、JSON回答では考えずに答えます。直し方は、システムプロンプトに短い文を足すか、古い指示を消すかのどちらかです。

この記事は、症状ごとに使える文面を並べます。モデルの概要・料金・破壊的変更はClaude Sonnet 5.5とはにあります。effortの再較正もそちらの担当です。ここでは、プロンプトの書き方だけを扱います。

まず症状と対処の対応表です。

途中で止まる・やりすぎる挙動は2つの段落で調整する

lowとmediumのエージェント系コーディングでは、作業の途中で確認を挟むことがあります。計画の確認を求める、自分で答えられる質問をする、複数パートの1つ目が終わったところで続行を尋ねる、といった動きです。効果が最も素直なのはeffortを上げる方法です。effortを変えたくないときは、次の2段落をシステムプロンプトに足します(英文例の訳です)。

ユーザーに頼まれたことがすべて終わるまで作業を続けること。ユーザーの返答なしには進めないとき、またはリスクのある操作の前でだけ確認する。
 
頼まれた作業が終わり、確認も済んだら、そこで止めて報告すること。頼まれていない機能・テスト・ファイル・ドキュメント・リファクタは足さない。有益だと思うなら、実行せず最後に提案として書く。

1段落目が「続けさせる」指示、2段落目が「範囲を守らせる」指示です。どちらも公式の英文例を日本語に直した文面で、訳は本記事の例です。

1段落目を足すと、lowとmediumでもモデルは最後まで作業を運びます。そのぶんセッションは長くなり、コストも増えます。危険な操作やもう戻せない操作についての自前のルールは、この段落では代替できません。別に残してください。

頼まれていない追加を止めたいときは2段落目だけ

Sonnet 5.5は、リポジトリの慣習に合うテスト・ドキュメント・小さな補助ファイルを、頼まれなくても足す傾向があります。どのeffortでも起き、高いほど多くなります。歓迎するチームは多いはずで、その場合は何もしなくて構いません。変更を依頼範囲に限りたいときだけ、2段落目を単独で足します。xhighとmaxでは、この段落が追加を減らし、変更全体も小さくなります。

xhigh・maxの過剰な再レビューを止める文面

xhighとmaxのSonnet 5.5は、タスクを終えたあとに自分でレビューと検証を回し始めます。ハーネスが許せば、サブエージェントも立てます。目に留まった周辺の修正まで済ませることもあります。この徹底ぶりは欲しいが、対象は依頼した作業に絞りたい場合は、次の文面が使えます(英文例の訳)。

頼まれた作業が終わり、チェックも通ったら、そこで止めて報告すること。自分から追加のレビューや堅牢化の作業を始めない。ユーザーがレビューを求めていない限り、レビュー用のサブエージェントも起動しない。より深いレビューが必要だと思うなら、最後にそう伝える。

maxでのコーディングの検証では、この文面でレビュー用サブエージェントが起動しなくなり、品質を変えずにセッションコストが約3分の1下がりました。メインエージェントが自発的に回すレビューは、減るものの完全にはなくなりません。日常的な作業はhigh以下で回すのが前提です。

「アイデアをください」で作り始めてしまうとき

「これで何ができるか見せて」のように範囲を決めない依頼では、アイデアだけ欲しいのにプレゼン資料や動画の制作に入ることがあります。依頼文で「まず案だけ」と書くか、次の1段落(英文例の訳)を足します。

ユーザーがアイデア・選択肢・計画を求めたときは、それだけを示して止まること。ユーザーが進めてよいと言うまで、何も作らず、何も変更しない。

前置き思考なしで動かすときにプロンプトから消すもの

思考を切っていた実装は、thinking: {"type": "between_tools"}に移します。Sonnet 5.5で最も低い思考設定で、high以下のeffort(low・medium・high)で受け付け、xhighとmaxでは400になります。移行の破壊的変更としての整理はClaude Sonnet 5.5とはにあるので、ここではプロンプト側の作業に絞ります。

import anthropic
 
client = anthropic.Anthropic()
 
response = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=16000,
    output_config={"effort": "medium"},
    thinking={"type": "between_tools"},
    tools=tools,
    system=system_prompt,  # 「考えるな」系の指示は入れない
    messages=messages,
)

プロンプトについて要点は1つです。「考えるな」という指示は削ります。between_toolsのもとでそうした指示を残すと、モデルが内部用のXMLタグを可視の出力へ書き出しやすくなります。思考を減らしたいなら、指示ではなくeffortを下げる方法が向いています。medium以上では、挨拶にすら短く考えてから返します。システムプロンプトで「あまり考えないで」と頼んでも、思考量は確実には減りません。lowなら、単純な依頼の多くで思考を飛ばします。

返ってきた思考ブロックは触らずに戻す

between_toolsでも、ツール呼び出しの合間のメモが1〜2文を超えるとthinkingブロックとして返ります。中身は要約です。次のリクエストでは、それをassistantターンの残りと一緒に無加工で戻します。戻したブロックは、要約ではなくモデルが書いた全文のメモとして働きます。最初のコンテンツブロックがtextとは限らないので、レスポンスはブロックの型で読み分けます。

ツールなしの推論タスクには使わない

ツールを渡さないリクエストでbetween_toolsを使うと、モデルは考えずに答えます。数段階の推論が要る用途では、adaptive thinkingを使ってください。理由は次の節のとおりです。

JSONで答えさせる推論タスクは、考えさせる1行を足す

書類の数字を合計する、規則を当てはめる、項目を順位づける。こうした数段階の推論を伴う質問にJSONで答えさせると、Sonnet 5.5は考えずに答えることがあります。lowとmediumで特に多く出ます。structured outputsを使う場合、レスポンステキストはJSONだけになります。モデルが筋道を立てられる場所は思考しかなく、思考を飛ばした分だけ精度が落ちます。

対処は3通りです。

• adaptive thinkingを有効にし、システムプロンプトの末尾に1行足す
• adaptive thinkingでeffortをxhighにする
• between_toolsを使わない(ツールなしだと考えないため)

公式の英文はThink the problem through before you answer.です。日本語では次のように書けます(訳は本記事の例)。

答える前に、問題をじっくり考え抜くこと。

この1行で、モデルは答える前により頻繁に考えます。highでは精度がxhighに近づき、出力トークンの増加は控えめです。lowとmediumでも精度は上がりますが、highには届かず、トークンの増え方は大きくなります。xhighは、この1行なしでも最高精度でした。出力トークンはhighより増えます。

structured outputsのlowとmediumには、もう1つ落とし穴があります。まれに、思考がmax_tokensに達するまで続きます。high以上ではほぼ起きません。stop_reasonが"max_tokens"のレスポンスは、JSONとして読めても失敗として扱い、再試行してください。max_tokensの見積もりは、Sonnet 5でmax_tokensが途中で切れる問題と同じ考え方で、思考とJSONの両方が収まる額にします。

structured outputsが使えないときは、最後のJSONを拾う

プロンプトでJSONを頼む方式だと、モデルは本文で筋道を書いてから、末尾にJSONを置くことが多くなります。答えは大抵合っています。レスポンス全体をJSONとして読む実装が落ちるだけです。パーサー側の直し方は次のとおりです。

1. textブロックだけを読み、stop_reasonが"max_tokens"なら失敗として扱う
2. 各{か[から順にJSONの読み取りを試し、成功したらその末尾から再開する(内側の値を単独で数えないため)
3. 最後に見つかった値を採用する
4. 期待するフィールドがそろっているか確認し、足りなければ1回だけ再試行する

最初の{から最後の}までを切り出す方法は避けます。モデルが最終JSONの前に下書きを書くことがあり、その範囲には下書きも入るためです。次のコードは、この手順の実装例です(本記事の例で、公式のコードではありません)。

import json
 
def last_json_value(text: str):
    decoder = json.JSONDecoder()
    found, i = None, 0
    while i < len(text):
        if text[i] in "{[":
            try:
                value, end = decoder.raw_decode(text, i)
                found, i = value, end
                continue
            except json.JSONDecodeError:
                pass
        i += 1
    return found

レコードを1行ずつ並べる形式の答えでは、「空白・カンマ・改行だけで区切られた最後の連続」を採用する処理が別に要ります。この手順で、検証ではほぼすべてのレスポンスが使えるようになり、精度は変わりませんでした。代案はxhigh+adaptive thinkingです。作業が思考の側へ移り、JSONだけが返ることが大半で、出力トークンの合計はhighと同程度に収まります。

長いターンが無言に見えるときは、進捗更新を設計する

Sonnet 5.5は、ツール呼び出しの合間に、いま分かったことと次にやることをユーザー向けに書きます。1〜2文を超えるメモは、progress-updateのthinkingブロックで返ります。既定のthinking.displayでは、そのブロックの中身が空です。textブロックだけを描画するクライアントは、長いエージェントターンの間、黙って見えます。

表示するには、display: "updates"(ベータ、thinking-display-updates-2026-08-18ヘッダー)を指定します。between_toolsなら要約つきで返るので、displayは要りません。between_toolsにはdisplay・budget_tokens・block_bindingを併用できず、送ると400になります。

プロンプトの側では3つ手を打てます。

1. 「最終回答まで途中の発見を溜めておけ」といった古い指示を消す
2. 更新のタイミングを決めたいなら、システムプロンプトで指定する(最初のツール呼び出しの前に一言、終わりに短い振り返り、など)
3. コード片や質問のような正確な文面をユーザーに見せたいとき用に、メッセージ送信用の簡単なツールを渡す

ツールを渡すときは、そのツールを「そうした内容専用」と指示します。ツール一覧が途中で変わらないよう、セッション最初のリクエストで宣言します。プロンプトキャッシュへの影響は、自動プロンプトキャッシュの挙動で確認できます。

ハーネスから催促するときの文面

それでも黙る時間が長いなら、ハーネス側で催促します。ユーザーへのテキストも進捗更新も出さないツール呼び出しの連続数を数え、たとえば5回続いたら、直近のツール結果の後ろに1ターン限りのリマインダーを足します。turn-scopedなシステムメッセージ(ベータ)として送る文面は次の文面です(英文例の訳)。

しばらくユーザーに何も伝えていない。いま何をしているかを短い言葉で伝えてから、作業を続けること。

催促を2〜3回送っても静かなままなら、それ以上は送りません。ツール結果の直後にハーネスの文面が頻繁に差し込まれると、モデルが注入攻撃を疑うからです。リマインダーは以降のリクエストでもmessagesに残します。挿入して後で消すのではなく末尾に追記する形なので、プロンプトキャッシュとpreserved thinkingは壊れません。highでメッセージ送信ツールがある条件では、この催促でモデルの更新頻度が上がり、最長の無言区間が短くなりました。タスクの品質に測定できる差は出ていません。

ターン途中のユーザーメッセージは、注入と誤認される置き方がある

Sonnet 5.5は、ツール結果などの読み込んだ内容に混じる悪意ある指示(間接プロンプトインジェクション)に耐えるよう訓練されています。その副作用として、本物のユーザーのメッセージを注入と疑うことがあります。ユーザーが作業中に打った言葉が、ツール結果の直後に置かれたmid-conversationのシステムメッセージや、tool_resultブロックの中に入って届くと起きます。モデルは「ツール結果にあなたを装った文が入っていました」とユーザーに告げ、そのメッセージを無視するか、確認を求めます。

きっかけになりやすいのは、次の実装です。

• 各ツール結果の後にトークンの残量カウントダウンを付ける
• 複数ステップのターンの途中でユーザーに送信を許す
• 毎ステップ、ツール結果の後に指示や文脈を足す

どれも、ツール結果の直後に文面が来ます。カウントダウンや毎ステップの指示なら、ツール呼び出しのたびに起きえます。たまに送る1ターン限りのリマインダーは、頻度がずっと低くなります。自前のリマインダーで誤認が出たら、送る回数を減らします。

置き方の指針は4つです。

• ユーザーの文言をtool_resultブロックの中に入れない(誤認が最も多い置き方)
• 割り込みは、tool_resultを運ぶuserメッセージの中の、最後のtool_resultの後ろにtextブロックとして足す
• リマインダーなどハーネスの通知は、ユーザーの言葉の後ろに、別のmid-conversationシステムメッセージとして置く。通知とユーザーの言葉を同じブロックに入れない
• 途中入力ができる対話セッションでは、自前のトークンやバジェットのカウントダウンをツール結果の後に足さない

割り込みを載せたuserメッセージの形は、次のようになります(構造の例です)。

{
  "role": "user",
  "content": [
    {"type": "tool_result", "tool_use_id": "toolu_01", "content": "…テスト結果…"},
    {"type": "text", "text": "ついでにREADMEの手順も直しておいて"}
  ]
}

tool_resultはtool_useと対にする必要があるので、textは必ずその後ろです。task budgets(ベータ)も似たカウントダウンを足しますが、この誤認を起こした例は確認されていません。タスクバジェットを設定した状態で誤認が出たら、バジェットなしでも試します。

検証の指示は、「本物のチェック」を定義して書く

Sonnet 5.5は、エージェント系コーディングで完了を報告する前に、たいてい自分の変更を確かめます。lowでは、その確認を飛ばして「終わりました」と報告することがあります。たとえば、依存関係が入っていないという理由でプロジェクトのテストを省きます。トランスクリプトにテストやビルドの出力が見当たらないまま完了報告が来るなら、次の段落(英文例の訳)を足します。

実行・ビルド・型チェックができるコードを変更したときは、完了を報告する前に、その変更を実際に確かめるチェックを回すこと。プロジェクトのテスト・型チェッカー・ビルド、または変更したコマンド自体を実行する。構文チェックだけのもの、起動に失敗したチェックコマンドは数えない。足りないのが宣言済みの依存関係だけなら、禁止されていない限り入れてよい。入れるのはプロジェクト自身のパッケージマネージャーとロックファイルで行う(例: npm install、pip install -r requirements.txt)。sudoやシステムのパッケージマネージャーは使わない。この環境で本物のチェックが回せないときだけ、変更を完了として報告する代わりに、どのチェックを回せなかったかと理由を伝える。

この段落は何を決めているのでしょうか。中身を分けると、次の4点です。

最後の1文が、逃げ道を塞ぎます。回せないなら、どのチェックを回せなかったか、なぜかを書かせます。lowでこの段落を足すと、飛ばされたチェックや形だけのチェックは稀になりました。品質に測定できる差はなく、タスクあたりのコストは少し上がります。

Claude Codeで同じことをするなら、CLAUDE.mdに検証コマンドを具体名で書く形が使えます。段落の思想はそのままで、npm testやnpx tsc --noEmitのようなプロジェクト固有のコマンドを添えるだけです。これはこの記事の応用例で、公式の手順ではありません。効果はeffortごとに違うので、評価セットで測ってください。測り方はプロンプト評価の実践ガイドにあります。

検索させたいときは、抑制の文言を消す

チャットや知識労働では、料金・許可・必須条件のような変わりやすい細部を、検索せずに訓練知識から答えることがあります。まず、プロンプトの中の「ツールは本当に必要なときだけ使う」「ツール呼び出しは最小限に」といった文言を消します。そのうえで、検索ツールを渡している製品なら、次の段落(英文例の訳)を足します。

訓練時点から変わっている可能性のある細部は、自信があっても、検索ツールで確認すること。たとえば、何が許可されているか、何が必須か、何が課金されるか、といった点である。レポートや比較のような調査を伴う作業では、訓練知識で書かず、最新の情報源を集める。

リサーチ系とサポート系の製品で特に効きます。答えが最新の細部に依存するためです。

小さな実装上の注意3点

ツール名の大文字小文字とパラメータ名のずれ

宣言済みのツールを、大文字小文字だけ違う名前(Bashに対するbash)で呼ぶことがあります。既知のパラメータを少し違う名前で渡すこともあります。ハーネス側の対処は2通りです。1つは、一意に決まるなら大文字小文字が違っても受け付けること。もう1つは、is_error: trueのtool_resultで正しい名前を返すことで、モデルは次のターンで直すことが多くなります。プロンプトで叱るより、この2通りのほうが確実です。

複雑な画像には切り抜き・拡大・コード実行の手段を渡す

密度の高いグラフや技術図面は、切り抜き・拡大・コード実行の手段を渡すと読み取りが大きく改善します。グラフでは全effortで効きます。技術図面はhigh以上で効き、xhighとmaxで最大です。グラフについては、highでツールありのほうが、maxでツールなしより正確で、コストは小さくなりました。ツール定義の実例は、公式のcropツールのクックブックにあります。

拒否はstop_reasonで受け、理由の指示を消す

安全分類器が要求を断ると、通常のレスポンスにstop_reason: "refusal"が付き、stop_details.categoryにカテゴリ(cyber・bio・frontier_llm・reasoning_extraction・general_harms)が入ります。プロンプトの書き方として関係するのは、reasoning_extractionです。「回答に推論過程を含めて」と頼む指示は、この拒否を呼びます。消したうえで、推論はadaptive thinkingの要約ブロック(display: "summarized")から読みます。server-side fallbackの再試行範囲は、cyberとfrontier_llmだけです。カテゴリごとの扱いはreasoning_extraction拒否とfallback設計にあります。

5.5のプロンプト調整は、足すより先に消す作業になる

これまでの節を並べると、共通点があります。足す文面は短いのに、消すべき文面が毎回出てきます。

• 「ツール呼び出しは最小限に」は検索を減らす
• 「途中の発見は最終回答まで溜める」は進捗更新を消す
• 「考えるな」は内部タグの露出を招く
• 「推論を回答に含めて」は拒否を招く
• ツール結果の後に毎回差し込む文面は、ユーザーの言葉を注入と誤認させる

古いモデルのために書いた予防線が、5.5では副作用に変わります。Sonnet 5のプロンプトがそのまま動くとしても、動くことと最適なことは別の話です。効き目の分かっている短い文面を足す前に、プロンプトの棚卸しから始めるのが近道です。棚卸しのあとで、足した1行ごとに評価セットで差を測れば、どの文面が実際に効いているかが分かります。

まとめ

• 途中で止まる:「終わるまで続ける」段落を足すか、effortを上げる。範囲を守らせたいなら2段落目
• 思考なし運用:between_toolsはhigh以下。「考えるな」は消し、思考ブロックは無加工で戻す
• JSON回答:adaptive thinkingと「考えてから答える」1行。max_tokens停止は失敗扱い
• 進捗と割り込み:更新はdisplayかメッセージ用ツールで見せ、ユーザーの言葉はtool_resultの外に置く
• 検証:何を本物のチェックと数えるかを書き、回せないときの報告まで指示する

文面はどれも公式が挙げた出発点です。自分のワークロードで、effortごとに測ってから採用してください。