Claude Sonnet 5.5公式プロンプトガイドを全部読むeffortは測り直し、途中で止まる・やりすぎる・調べない、困りごと11個と貼る文

Anthropicが9月28日にClaude Sonnet 5.5を公開した際、公式ドキュメントに「Prompting Claude Sonnet 5.5」というページも載りました。Sonnet 5.5のためだけのプロンプトの書き方で、使っていて困った時に引けるよう、困りごと11個からそれぞれの直し方の節へ飛べる作りになっています。本記事ではその全節を、システムプロンプトに足す文の原文と訳つきで整理します。動画でも同じ内容を順に解説しています。

3行まとめ

1. Sonnet 5のプロンプトは変えなくてもよく動く。ただしeffortの目盛りが変わったので、Sonnet 5の設定を持ち込まず自分の評価で測り直す。
2. 途中で確認に止まる／頼んでいないテストやドキュメントを足す／xhigh・maxで自分からレビューを始める／アイデアだけ欲しいのに作り始める、に対して、それぞれ足す文が載っている。レビューを止める文は、公式のテストでセッションの費用を約3分の1減らした。
3. 調べずに記憶で答える時は検索させる文、確かめずに完了と言う時は本物のチェックを走らせる文。API側では between_tools・JSONの読み方・進捗表示・途中の発言の置き場所に注意点がある。

本記事の内容は、2026年9月29日未明・日本時間に取得したガイドの.md版に基づきます。

最初に書いてあること──Sonnet 5のプロンプトは変えなくても動く

ガイドの冒頭はこう始まります。

Existing Claude Sonnet 5 prompts should perform well without changes, and the patterns in Prompting Claude Sonnet 5 remain a reasonable starting point. For the hardest long-horizon work, an Opus model is the better choice.

（既存のClaude Sonnet 5のプロンプトは変更なしでもよく動くはずで、Sonnet 5用のガイドの書き方もそのまま出発点として使える。いちばん難しい長期の仕事には、Opusのモデルの方が向いている）

その下に、症状と節の対応が11行並びます。本記事の見出しもこの症状に合わせています。

effort──同じ名前の段でも、考える量はSonnet 5と違う

effortは考える量を決める設定で、品質・待ち時間・費用がこれで決まります。ガイドは、段の目盛りが変わったことを最初に書いています。

Its levels are recalibrated: a level doesn't produce the same amount of thinking as the same level on Claude Sonnet 5. Run a fresh sweep against your own evals rather than carrying over the setting you used on Claude Sonnet 5.

（段は較正し直された。同じ段でも、Sonnet 5の同じ段と同じ量の思考にはならない。Sonnet 5で使っていた設定を持ち込まず、自分の評価で改めて段を振って試すこと）

最初に試す段は次のとおりです。

段を下げると困ることも書かれています。low では思考が短くなり、変更を確かめずに終わることがあります。low と medium では、長い作業の途中で、終わる前にユーザーに確認しに来やすくなります。

調整のコツは3つです。

1. max_tokens は思考の分も含めて大きめにとる。思考は返ってこなくても上限に数えられるので、小さいと返事が途中で切れる。エージェントでのコーディングでは、モデルの上限の12万8千にしてストリーミングで受ける
2. xhigh と max は、品質が上がると測れた作業だけに使う。思考も返事もずっと長くなる
3. 思考を減らしたいなら段を下げる。システムプロンプトで「考えすぎないで」と頼んでも確実には減らない。medium から上だと挨拶への返事でも少し考え、low なら簡単な頼みごとの多くで思考を飛ばす

リクエストごとにeffortの値を変えるとプロンプトのキャッシュが切れます。1ターンだけ段を変えたい時は、メッセージ単位のeffort変更（ベータ）を使えばキャッシュが残ります。ガイドは「普段は low で、難しい問題が来た時だけ high に上げる」例を挙げています。

途中で止まる・やりすぎる──4つの困りごとと足す文

ガイドによると、Sonnet 5.5がどこまで自分で進めるかは、effortと頼み方で変わります。低いeffortではコーディングの途中で確認に来ることがあり、高いeffortや自由度の高い頼み方では、頼んだ以上のことをすることがあります。

1. 途中で確認に止まる（low・medium）

計画を確かめに来る、自分で答えられる質問をする、いくつかある作業の1つ目で止まって続けるか聞く、といった止まり方です。まずeffortを上げ、effortを変えずに最後までやらせたいならシステムプロンプトに次を足します。

Keep working until everything the user asked for is done, and only stop to ask when you can't go on without the user or before a risky step.

When the work the user asked for is done and checked, stop and report. Don't add features, tests, files, docs or refactors that weren't asked for. If you think one would help, mention it at the end instead of doing it.

（頼まれたことが全部終わるまで作業を続けること。質問で止まるのは、ユーザーがいないと進めない時か、危険な手順の前だけにすること。／頼まれた作業が終わって確認も済んだら、止めて報告すること。頼まれていない機能・テスト・ファイル・ドキュメント・リファクタリングを足さないこと。役立ちそうだと思ったら、やらずに最後に一言添えること）

ガイドは副作用も書いています。この文を入れると low と medium でも最後までやるので、1回のセッションが長くなり費用も増えます。また、この文は危険な操作や元に戻せない操作についての自分のルールの代わりにはならないので、そのルールはシステムプロンプトに残すように、としています。

2. 頼んでいないものを足す

Sonnet 5.5は、頼まなくてもテスト・ドキュメント・小さな補助ファイルを、リポジトリの慣習に合わせて足す傾向があります。どのeffortでも起き、高いほど多くなります。頼んだ変更そのものは頼んだ内容に近く、ガイドは「ほとんどのチームは歓迎するだろう」と書いています。頼んだものだけにしたい場合は、上の文の後半の段落（When the work the user asked for is done…）だけを足します。xhigh と max では、この段落で追加が減り、変更全体も小さくなるそうです。

3. xhigh・maxで念入りすぎる

この2段では、作業が終わった後に自分でレビューと確認を何周も始め、ハーネスにあればレビュー用のサブエージェントも立て、途中で気づいた関連の修正もします。ガイドは普段の作業を high 以下で回すよう勧めたうえで、念入りさは欲しいが頼んだ作業に集中させたい時の文を載せています。

When the work the user asked for is done and its checks pass, stop and report. Don't start extra rounds of review or hardening on your own, and don't launch reviewer sub-agents unless the user asked for a review. If you think a deeper review is worth doing, say so at the end.

（頼まれた作業が終わってチェックが通ったら、止めて報告すること。自分から追加のレビューや補強を始めないこと。レビューを頼まれていない限り、レビュー用のサブエージェントを立てないこと。もっと深いレビューの価値があると思ったら、最後にそう言うこと）

公式のテストでは、max でのコーディングでこの文を足すとレビュー用のサブエージェントが立たなくなり、セッションの費用が約3分の1減って品質は変わらなかったとしています。ただし、メインのエージェントが自分で始めるレビューは、減るもののゼロにはならないと書かれています。

4. アイデアだけ欲しいのに作り始める

「これで何ができるか見せて」のような自由度の高い頼み方をすると、アイデアが欲しかっただけなのに、プレゼン・レポート・動画を作り始めることがあります。頼む時に「まずアイデアか計画を」と書くか、次を足します。

When the user asks for ideas, options or a plan, give them that and stop. Don't start building or changing anything until they say to go ahead.

（ユーザーがアイデア・選択肢・計画を求めた時は、それを出して止まること。進めてと言われるまで、何も作ったり変えたりし始めないこと）

調べずに答える・確かめずに終える──2つの文

検索すれば分かることを記憶で答える

チャットや知識作業で、何が許されているか・何が必要か・いくらかかるか、のように変わりやすいことを、検索せずに学習した知識で答えることがあります。ガイドはまず、プロンプトに「本当に必要な時だけツールを使え」「ツールの呼び出しを減らせ」のようなツールを控えさせる言葉がないかを確かめ、あれば消すよう書いています。そのうえで、検索ツールを渡しているなら次を足します。

Use the search tool to check specifics that may have changed since your training, such as what is allowed, required or charged, even when you feel confident. For researched work such as a report or a comparison, gather current sources rather than writing from your training knowledge.

（学習の後で変わったかもしれない細部——何が許されるか、何が必要か、いくらかかるか——は、自信があっても検索ツールで確かめること。レポートや比較のような調べ物では、学習した知識で書かず、今の情報源を集めること）

テストやビルドをせずに完了と言う（low）

コーディングでは、Sonnet 5.5はふつう完了と言う前に自分の作業を確かめます。ただ low では、変更を実際に通すチェックをせずに完了と言うことがあり、例として「依存関係が入っていないのでプロジェクトのテストを飛ばす」が挙がっています。作業の記録にテストやビルドの出力が無いのに完了になっていたら、次を足します。

When you change code that can be run, built, or type-checked, run a real check that exercises the change before reporting it done: the project's tests, type-checker, or build, or the changed command itself. A syntax-only check, or a check command that failed to start, does not count; if all that is missing is the project's declared dependencies, install them with its own package manager and lockfile (e.g. npm install, pip install -r requirements.txt), never via sudo or the system package manager, unless told not to. Only if no real check can run here, say which one you did not run and why instead of reporting the change as done.

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

low でこの文を入れると、チェックの飛ばしや表面だけのチェックがまれになり、品質は変わらず、1タスクあたりの費用はわずかに上がるだけだったとされています。

APIで組む時①──between_toolsとJSON

thinkingをオフで動かしている場合

Sonnet 5.5では、最初の思考を切るには thinking: {"type": "between_tools"} を送ります。この機種でいちばん低い思考の設定です。切り替えたら確かめる点として、ガイドは4つを挙げています。

1. between_tools は high 以下でしか受け付けない（xhigh・max では400エラー）。途中でeffortを変えることもできない。「考えるな」という指示はプロンプトから消す（残すと、見える返事に内部のXMLタグを書きやすくなる）
2. 返事の最初のブロックが文章とは限らない。ブロックの種類を見て読む
3. thinking ブロックはそのまま送り返す。送り返すと、要約でなくモデルが書いた元のメモが渡る
4. ツールを使わない推論の作業には、between_tools でなく適応型の思考（adaptive thinking）を使う。ツールが無いと、考えずに答えるため

考えが要る作業をJSONで答えさせる場合

文書の数字を合計する、ルールを当てはめる、項目を並べ替える、のように何手か考える必要がある作業で、答えをJSONで欲しい時の話です。特に low と medium では、考えずに答えてしまうことが多いとされています。

構造化出力が使えるなら使います。ただし構造化出力では返事にJSONしか入らないので、考えられるのは思考の中だけです。思考を飛ばすと正確さが落ちるため、適応型の思考でシステムプロンプトの最後に次の1行を足します。

Think the problem through before you answer.

（答える前に、問題をよく考えること）

high ではこの1行で、xhigh に近い正確さになり、出力トークンの増え方は小さいとされています。もう1つの手は xhigh で、この1行が無くてもこの種の作業で最も正確になりますが、出力は high より多くなります。また low・medium の構造化出力では、まれに max_tokens まで考え続けることがあるので、stop_reason が "max_tokens" の返事は、中身がJSONとして正しく見えても失敗として扱いやり直すよう書かれています。

構造化出力が使えない場合は、プロンプトでJSONを頼みます。するとモデルは文章で考えてから最後にJSONを書くことが多く、返事の全体をJSONとして読むパーサーは失敗します。ガイドの読み方は次のとおりです。

1. text ブロックだけを読む。stop_reason が "max_tokens" なら失敗扱い
2. { か [ の位置ごとに、JSONとして読めるか試す
3. 読めたら、その値の終わりから続ける（中に入れ子になった値を別に数えない）
4. 一番最後に読めた値を使う。最初の { から最後の } までを丸ごと取らない（モデルがたまに最後のJSONの前に下書きを書くため）
5. 欲しい項目があるか確かめ、無ければ1回だけやり直す

公式のテストでは、この読み方で正確さを変えずにほぼ全部の返事が使えるようになったとしています。

APIで組む時②──無言になる・途中の発言を偽物扱いする

長い作業で画面が無言になる

Sonnet 5.5はツール呼び出しの合間に、何が分かって次に何をするかのメモをユーザー向けに書きます。1、2文より長いメモは進捗用の thinking ブロックで返り、既定の thinking.display では中身が空です。文章ブロックだけを表示するクライアントでは、長い作業の間は何も出ないように見えます。見せるには display: "updates"（ベータ）を指定します。between_tools なら指定しなくても要約つきで返ります。

「見つけたことは全部最後の返事にまとめろ」のような古い指示は消し、決まった所で報告してほしいなら、それをシステムプロンプトに書くよう勧めています。それでも無言が長い場合は、文章も進捗も無いツール呼び出しが、たとえば5回続いたら、ハーネス側から1ターンだけ次の文を足します。

The user hasn't heard from you in a while — say in a few words what you're doing, then continue.

（しばらくユーザーに何も伝えていない。何をしているか短く伝えてから、続けること）

それでも黙ったままなら、2回目か3回目で促すのをやめるよう書かれています。ツールの結果の後にハーネスの文が頻繁に入ると、モデルがプロンプトインジェクションを疑うからです。

途中で送った発言が無視される

Sonnet 5.5は、ツールの結果などに紛れ込んだ悪意ある指示（間接的なプロンプトインジェクション）に抵抗するよう訓練されています。そのため、ユーザーが作業の途中で送った本物のメッセージを、紛れ込んだ文だと疑うことがあります。ツールの結果の直後に置かれたシステムメッセージや、tool_result ブロックの中に入ったユーザーの文を「ツールの結果にあなたを名乗る文が入っていた」と扱い、無視したり確認を求めたりします。ガイドの対策は4つです。

1. ユーザーの文を tool_result ブロックの中に絶対に入れない（最も誤解される置き方）
2. 途中の発言はユーザーのターンとして、tool_result を運ぶユーザーメッセージの中で、最後の tool_result の後ろに文章ブロックで足す
3. リマインダーのようなハーネスの通知は、ユーザーの言葉とは別のシステムメッセージにする
4. ユーザーが途中で打ち込める画面では、ツールの結果の後に自前の残りトークンのカウントダウンを足さない

小さな落とし穴3つ──ツール名・図表・拒否

ツール名：Sonnet 5.5はたまに、宣言したツールを大文字小文字だけ違う名前で呼んだり（Bash を bash）、引数を少し違う名前で渡したりします。致命的なエラーにせず、どれのことか一つに決まるなら受け付けるか、正しい名前を書いた is_error: true の tool_result を返すよう勧めています。後者なら、次のターンでたいてい直すそうです。

図表：細かいグラフや技術図面には、画像を切り抜く・拡大する・コードを走らせる道具を渡すと、ずっと正確に読むとされています。グラフではどのeffortでも、技術図面では high から上で、xhigh・max で最も上がります。グラフについては「道具ありの high が、道具なしの max より正確に読み、費用はずっと少なかった」とあります。

拒否：安全の分類器が断ると、stop_reason: "refusal" と、stop_details.category に分類が入って返ります。

サーバー側のフォールバック（ベータ）を有効にすると、cyber と frontier_llm で断られたものはSonnet 5でやり直されます。bio・reasoning_extraction・general_harms はやり直されません。返事に推論を書かせる指示は reasoning_extraction を招くので消し、推論を見たい場合は要約された思考のブロック（display: "summarized"）を読むよう書かれています。

Opus 5.5のガイドと並べて読んで分かったこと

本サイトは9月23日にOpus 5.5のガイドを記事にしています。今回、Opus 5.5のガイドも取り直して並べました。

同じだったこと：effortの調整のコツ3つ（max_tokens は12万8千、xhigh・max は測れた作業だけ、思考を減らすなら段を下げる）と、メッセージ単位のeffort変更でキャッシュを保つ話は、同じ趣旨で両方にあります。長い作業が無言になった時にハーネスから足す一文「The user hasn't heard from you in a while…」も、一字一句同じ文が両方に載っています。

違ったこと：

• 最初の段：Opus 5.5のガイドは「既定の medium から始めろ」、Sonnet 5.5のガイドは「APIの既定の high から始めろ（エージェントのコーディングは medium から）」
• 図表：Opus 5.5のガイドは、道具なしでもOpus 5より図表をずっと正確に読むので「前のモデルのために作った補助がまだ要るか試し直せ」と書いたうえで、いちばん細かい入力には高解像度の画像と切り抜きなどの道具を勧める。Sonnet 5.5のガイドは最初から道具を渡す前提で、「道具ありの high が道具なしの max より正確」と書く
• 節の顔ぶれ：Opus 5.5のガイドにあるのは、無人で回すエージェントが止まる型、複数アプリの文脈、時間の合図、貼り付けたテキストの印、フロントエンドの既定などです。Sonnet 5.5のガイドにあるのは、検索させる文、本物のチェックを走らせる文、最後のJSONの読み方、ツール名の揺れ、途中の発言の置き場所です。本記事が2026年9月29日に取得したOpus 5.5のガイドの.md版では、JSON・tool_result・is_error・letter case はどれも0件でした。プロンプトインジェクションの話はOpus 5.5のガイドにもありますが、そちらはユーザーが貼り付けた文に印を付ける話で、途中の発言の置き場所ではありません

Sonnet 5.5の発表は、Opus 5.5を「慎重な判断が要る複雑な仕事」向け、Sonnet 5.5を「範囲のはっきりした日常の仕事」向けと書き分けていました。ガイドの節の顔ぶれも、その分け方に沿っているように読めます（本記事の解釈）。

数字はすべてAnthropic自身のテスト、費用が増える文もある

本記事の数字（費用が約3分の1減った、ほぼ全部の返事が使えるようになった、high で xhigh に近い正確さになった等）は、いずれもガイドが自社のテストとして書いているもので、条件の詳細は書かれていません。

また、すべての文が費用を下げるわけではありません。途中で止まらせない文は low・medium のセッションを長くし費用を増やす、本物のチェックを走らせる文は1タスクあたりの費用をわずかに上げる、とガイド自身が書いています。本記事としては、全部の文を最初から入れるより、まずeffortを測り直し、困りごとが出た時にその文を足す使い方を勧めます。

出典は公式ガイド2本、9月29日取得

• Prompting Claude Sonnet 5.5（Anthropic 公式ドキュメント）：https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-sonnet-5-5
• What's new in Claude Sonnet 5.5（APIの変更点）：https://platform.claude.com/docs/en/models/sonnet-5-5/whats-new-sonnet-5-5
• Prompting Claude Opus 5.5（比較に使用）：https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5-5
• Effort：https://platform.claude.com/docs/en/build-with-claude/effort

英文の引用は、2026年9月29日に取得したガイドの.md版から写しています。日本語は本サイトの訳です。Sonnet 5.5そのものの価格やベンチマークはClaude Sonnet 5.5公開の記事にまとめています。