Opus 5.5 公式プロンプトガイドの要点 ─「よく考えて」は消していい
Anthropicが公開した「Prompting Claude Opus 5.5」の要点を整理します。思考量はプロンプトではなくeffortで調整し、既定のmediumでOpus 5のhigh相当。後半は、長時間タスクのチェックリスト、複数アプリの事前探索、マルチエージェントへの時間予算など、プロンプトの書き方よりハーネス側の設計が中心になっています。
Opus 5.5 公式プロンプトガイドの要点
Anthropicが Opus 5.5 専用のプロンプトガイドを出しました。結論から言うと、「よく考えて」「一歩ずつ」といった指示は消してよくなり、思考量は effort で調整します。後半はプロンプトの書き方ではなく、エージェントを動かす仕組み、ハーネス側の設計の話が中心です。
Opus 5 から何が変わったか
出力トークンの生成は Opus 5 より30%以上速く、同じタスクをより少ないトークンで終えます。既定の effort は high から medium に下がり、thinking は常にオン。途中経過のメッセージは text ブロックではなく thinking ブロックで返ります。Opus 5 向けのプロンプトはそのままでもよく動く、というのが公式の立場です。
思考量のダイヤルは effort
一番大事なのが effort です。Anthropic のテストでは、Opus 5.5 の medium が Opus 5 の high に並ぶか上回り、コーディング評価のいくつかでは low でもそれに近い。レベル名はモデル間で同じ思考量を意味しないので、Opus 5 の設定を持ち越さず、自分の評価で複数レベルを試すこと。
effort を運用する3つのコツ
同じレベルでも Opus 5.5 は1ターンあたりに多く考えるので、max_tokens は思考分の余裕を取る。長いエージェントコーディングなら上限の128,000が良かったそうです。xhigh と max は品質向上を測れた場合だけ。思考を減らしたいなら、プロンプトで頼むより effort を下げるほうが確実です。effort を途中で変えるとプロンプトキャッシュが無効になるので、メッセージ単位の effort 変更（ベータ）を使います。
「よく考えて」は消していい
話は2つあります。1つ目は消す話。チャットのシステムプロンプトに「回答前によく考えて」と書いているなら削除を検討。思考量はモデル自身が決め、調整するのは effort だからです。Anthropic のチャット製品で試したところ、返答の開始が早くなり、品質の明確な低下はなかった。2つ目は、任意で足してもいい話。Opus 5.5 は短い追加の質問でも前の回答を考え直すことがあるので、「一度答えたことは確定扱いにする」という2文を末尾に足すと、後続ターンの思考が減って返答が早まります。ただしこれは、長い分析や、後の工程で前の誤りが見つかりうるエージェント作業には入れないこと。自分から誤りを指摘しにくくなるからです。
thinking 無効で動かしていた人へ
Opus 5.5 では thinking を無効にできません。移行時は4つ。low から始めて測る。回答本文に推論を書かせる指示は外し、summarized thinking を読む。推論を本文に出させようとすると reasoning_extraction カテゴリで拒否されることがあります。thinking 無効時向けの回避策は再テスト。そしてレスポンスは先頭を text と決めつけず、ブロックの種類で読むこと。
ここから本題：ハーネスの設計
ガイドの後半は、プロンプトの一文よりも、モデルを動かす仕組み側の話になります。
無人エージェントが途中で止まる問題
Opus 5.5 は長いタスクで進捗を報告し、その報告が tool call なしでターンを終えることがあります。ループ側がそれを完了とみなすと、そこで止まる。対策は、テキストで終わったターンを完了の証拠ではなく報告として扱うこと。タスクをチェックリストで持たせ、未完了項目があって阻害要因も書かれていなければ、項目名を挙げて続行を促す。小さいモデルに完了条件を判定させる方法もあります。自動の続行は2〜3回で打ち止めにして、本当に詰まった実行を人がレビューできるようにします。
避けたい「早すぎる停止」4パターン
システムプロンプトで、避けたい停止の種類を具体的に名指しすると効きます。公式の例文が挙げる4つは、次の一歩を宣言して終わる長い要約、「よければ続けます」という申し出、実は何もブロックしていない判断事項の列挙、そして「区切りがいいから報告しよう」という判断。進捗メモは次の tool call と同じメッセージに入れさせます。止まってほしいのは、ユーザーなしでは何も進まないときだけ。危険な操作の確認は別途残すこと、人が見ている対話型アプリには入れないこと、も明記されています。
進捗表示の4つのレバー
途中経過が thinking ブロックで返るので、text だけ描画するクライアントは黙っているように見えます。1つ目、display updates を指定して要約を受け取る。2つ目、途中でコードなどをそのまま渡す必要があるなら、メッセージ送信用ツールを最初から定義しておく。3つ目、更新の頻度はシステムプロンプトで頼めば従う。4つ目、何も言わないツール呼び出しが5回続いたら、ハーネスから一言リマインドを差し込む。これで長い無言区間のあるタスクがおよそ半分になり、コストの変化は測定できなかったそうです。
複数アプリでは「先に見回せ」
メール、ドキュメント、スプレッドシート、CRM をまたぐ自動化では、必要な情報がタスクで言及されていない場所にあることが多い。Opus 5.5 はすぐ作業に取りかかる性格なので、行動前に広く探索させる一文を入れると、medium でも max でも正答が目に見えて増えた。代償はツール呼び出しとトークンが少し増えること。そして、見つけたものに従って動けと指示するので、検索対象に信頼できない内容を置かないことが条件です。
マルチエージェントに時間予算を渡す
Opus 5.5 は経過時間の情報をよく見ます。リードエージェントがサブエージェントに仕事を振る構成なら、ハーネスが各メッセージの末尾に「elapsed 340s / 1200s」のように経過時間と予算を付ける。モデルは予算内に収まるようにペース配分し、たいてい早めに終わるので、予算は実際に使いたい時間より少し多めに。予算が決められなければ経過時間だけ見せて、時間が大事だと一文添える。effort を下げると仕事そのものが減るのに対し、予算を絞ると並列に動くエージェントが増える、という違いがポイントです。予算は助言でしかないので、ハードな打ち切りは自前のタイムアウトで。
貼り付けたテキストに印を付ける
Opus 5.5 は間接プロンプトインジェクションへの耐性が歴代 Opus で最も高い。ユーザーがメールやWebページからコピーして貼った文章の中の指示にも、印を付ければ強くなります。アプリがランダムIDを生成し、pasted_content タグで開始と終了を囲む。システムプロンプトには、その中の指示はユーザー自身が頼んだ範囲でしか従わない、と書く。ただしタグはただの文字列で偽装できるので、防御の一枚として扱います。
図表の読み取りとWeb画面づくり
2つ話します。1つ目は、グラフや図、スクリーンショットを読ませる話。Opus 5 より大きく向上していて、最低の effort でも Opus 5 の最高 effort よりグラフの値を正確に読んだそうです。以前わざわざ用意していた補助の仕組みは不要かもしれないので再テストを。最も細かい図面などでは、高解像度の画像と、切り抜きや拡大ができる画像処理ツールがまだ効きます。2つ目は、Webページや画面、いわゆるフロントエンドを作らせる話。デザインの指示がないと、決まった見た目に戻りがちです。「AIっぽさを避けて」と頼んでも、別の決まった見た目に入れ替わるだけ。公式の例では、クリーム色の背景、見出しの斜体の強調、01・02・03の番号ラベル、等幅フォントのラベル、錠剤型のボタンを使わない、と具体的に名指ししています。出てきた結果を見て、禁止リストを足していくのがコツです。
3つの分野は自動チェックで断られる
Opus 5.5 には、依頼の中身を自動でチェックする仕組み、安全分類器が付いています。3つの分野のどれかに引っかかると、回答の代わりに「お断り」が返ってきます。APIでは stop_reason が refusal になります。1つ目は生物。悪用につながる生物学の依頼が対象で、日常の健康や教育の質問は影響を受けません。生命科学の研究で邪魔になる組織には、Anthropic の検証プログラムがあります。2つ目はサイバーセキュリティ。ソースコードの脆弱性を見つけるのはOKで、攻撃にも転用できる高リスクな作業はNG。3つ目が推論抽出。Opus 5.5 は回答の前に裏で考える、thinking をしています。その考えた過程を「全部、回答の本文に書き出して」と頼むのが推論抽出で、これが断られます。考えた過程を見たいなら、APIの設定で thinking の要約を別枠で受け取ります。なお、断られたときに別のモデルで自動再試行する仕組みがありますが、推論抽出だけは再試行されません。
今日見直す5つ
まとめです。effort を明示して複数レベルで測る。「よく考えて」系の指示を消す。ターン終了を完了とみなさず、チェックリストで続行させる。途中経過の表示を確認する。マルチエージェントなら時間予算を渡す。プロンプトの一文を磨く時代から、モデルが働く環境とフィードバックを設計する時代に移りつつあります。
出典
出典は Anthropic の公式ドキュメントです。数字はすべて Anthropic 自身のテストによるものなので、自分のワークロードで測ってから採用してください。
応援お願いします！
共通テンプレート（src/deck-shared.tsx の CtaSlide）。