Claude Fable 5.1のlow effortで検索が減るときの直し方

low effortのClaude Fable 5.1が検索せず答える現象

検索ツールを渡しているのに、最新の製品名やモデル名を聞くとツールを呼ばず、それらしい答えを返してくる。Claude Fable 5.1をlow effortで動かしているとき、この挙動が出ることがあります。Prompting Claude Fable 5.1のガイドには、low ではFable 5.1がFable 5より検索・取得ツールを呼びにくく、記憶から答えやすいと書かれています。

厄介なのは、答えが古くても文面は自信ありげなことです。一部だけ知っている名前ほど、古い情報が権威ある口調で返ってきます。ガイドが挙げる対処は2つあり、effortを上げるか、system promptで検索を促すかのどちらかです。

なぜlowで使うのか

lowを選ぶのは、速度とコストのためです。Prompting Claude Fable 5.1は、low のFable 5.1はコストあたりの成果でClaude OpusやSonnetと競えるうえ、スコアは上回ることが多いと書いています。medium ではFable 5と同程度の結果がより低いコストで得られるとも書かれています。小さいモデルを高いeffortで回している箇所の代替候補になる、という位置づけです。

だからこそ、low のまま検索だけ減るのは見落としやすい落とし穴になります。コストと速度の利点は保ちたい、でも最新情報の質問では検索してほしい、という要望がぶつかる場面です。

同じ傾向は他のモデルにもあります。effortのドキュメントにあるClaude Haiku 5.5の推奨レベルの説明では、長いエージェント用プロンプトの low で検索や確認を飛ばしやすくなると書かれています。モデルを替えたときも、low ではツール呼び出しが減っていないかをまず疑う価値があります。

手1: 該当ターンだけeffortを上げる

最初に試すのはeffortです。ガイドは「会話全体ではなく、影響を受けるターンだけeffortを上げるのが最も単純な直し方になる場合がある」という趣旨で書いています。

Fable 5.1には、会話の途中でeffortを変えるper-message effortがあります。betaヘッダー mid-conversation-output-config-2026-07-01 が必要で、role: "system" のメッセージに空の content と新しいレベルを入れます。例えば次のような形です。

{
  "model": "claude-fable-5-1",
  "max_tokens": 4096,
  "output_config": { "effort": "low" },
  "messages": [
    { "role": "user", "content": "前の質問への回答をまとめて" },
    { "role": "assistant", "content": "（省略）" },
    { "role": "system", "content": [], "output_config": { "effort": "high" } },
    { "role": "user", "content": "このライブラリの最新バージョンと変更点を調べて" }
  ]
}

これは公式の例を、本記事の用途に合わせて組み替えた例示です。effort専用のsystemメッセージはテキストを持たないため、配置の制約は受けず、messages のどこにでも置けます。直後のuserターンに新しい入力があればそのターンの返信から、それ以外の位置ならば次の新しい入力のあるuserターンから効きます。

注意点が3つあります。

• ツール結果だけを持つuserターンは「新しい入力」に数えられません。ツール実行ループの途中に差し込んだ変更は、次の通常のuserターンまで待たされます
• 変更後のレベルは、次に変更するまで続きます。検索が済んだら low へ戻すメッセージを入れます
• betaヘッダーなしで送ると400エラーになり、messages.N.output_config: Extra inputs are not permitted と返ります

トップレベルの output_config.effort を次のリクエストで書き換える方法もありますが、ガイドは勧めていません。キャッシュが作り直しになるうえ、Fable 5.1では効き方も不安定になります。以前の返信が前のレベルで書かれているため、モデルがそれと一貫させようとするからです。cache read率が重要な長い会話では、per-message effortを選ぶ理由になります。

per-message effortの入れ方そのものは、mid-conversation effortの切り替えで手順を追っています。

手1が使える面とモデル

per-message effortはbetaで、使える面とモデルが分かれます。Claude APIとGoogle Cloudでは、Claude Fable 5.1のほかClaude Mythos 5.1、Claude Opus 5.5、Claude Opus 5、Claude Sonnet 5.5、Claude Haiku 5.5が対象です。Amazon Bedrockで使えるのはClaude Fable 5.1、Claude Mythos 5.1、Claude Opus 5.5の3つです。

BedrockのInvokeModel APIを使う場合は、betaヘッダーではなく、リクエスト本文の anthropic_beta 配列に mid-conversation-output-config-2026-07-01 を入れます。この経路で使えるのはFable 5.1とOpus 5.5です。

非対応のモデルに送ったときのエラーも面で違います。Claude Fable 5のようにper-message effortを持たないモデルにbetaつきで送ると、output_config.effort requires a model that supports per-turn effort; this model does not という400になります。Bedrockでは、同じ状況で Extra inputs are not permitted が返ります。エラー文言から面を取り違えないよう、どの面にリクエストを送ったかを先に確かめてください。

手2: system promptに「名前を検索して確かめる」を足す

effortを動かせない構成もあります。固定の low で回すサブエージェントや、リクエストごとの設定を持たないアプリです。その場合はsystem promptで確認を促します。ガイドは、名前を知っていることと、その名前の現在の状態を知っていることは別だと伝えるよう勧めています。例示されている文面は次のとおりです。

When a query centers on a name you do not confidently recognize, or recognize from a fast-moving area like AI models and developer tools where the landscape shifts within months, the name itself is the thing to verify: search before answering, and include the name as the user wrote it in at least one query alongside any reformulations. This holds even when you have some background on it — partial background is exactly what makes an out-of-date answer sound authoritative, so familiarity is not a reason to skip the search.

この指示が押さえている点は3つです。

2つ目の「書かれたとおりの名前で検索する」が実用上のポイントです。言い換えた語だけで検索すると、ユーザーが指した名前そのものを引けないことがあります。

この文面は英語のまま、system promptに入れる前提で書かれています。日本語に訳して入れる場合は、意味が変わらないかを自分の評価セットで確かめてください。

どちらを選ぶか

どちらの手も、効果は自分のタスクで測るものです。ガイドは、effortを動かす前に各レベルを自前の評価で試すよう勧めています。目安として、次の表のように分けられます。

組み合わせることもできます。固定の low にsystem promptの指示を足し、それでも検索されない質問種別が見つかったら、その種別だけeffortを上げる、という順です。

lowに落とす前に決めておくこと

Fable 5.1の推奨は、既定の high から始め、評価で品質が保てると分かった作業だけ medium や low に下げる流れです。xhigh や max は、能力への依存が大きいエージェント作業やコーディングに回します。low は、速度に敏感な定型作業を落とし先にするレベルです。

この順序だと、low に下げた時点で、検索が要る質問が評価セットに入っているかが分かれ目になります。入っていなければ、検索が減る問題は本番で初めて見つかります。

評価セットの組み方の一例です。

• 古い答えが出やすい質問: 新しいモデル名、直近のリリース、料金改定
• 検索が要らない質問: 要約、文章の言い換え、手元のコードの説明
• ユーザーが一部だけ知っている名前を含む質問: 製品名の略称、バージョン違いの名前

検索が要らない質問を混ぜるのは、検索を促す指示を足したときに、不要な検索まで増えていないかを見るためです。これは筆者の設計例で、公式が示す構成ではありません。

Haiku 5.5はFable 5.1と事情が違い、既定が medium です。effortのドキュメントは low を、チャットや短いツール作業、単純で大量のリクエスト向けとしています。長いエージェント用プロンプトでは、検索を飛ばす、早めに止まる、確認を省く、といった挙動が low で出やすくなります。モデルを替える場合は、このレベル設計も取り直しになります。

検索されたかを確かめる

直したあとは、検索ツールが実際に呼ばれたかを見ます。応答の content にツール呼び出しのブロックがあるか、サーバー側ツールならその利用ブロックがあるかを、ログに残します。

def called_tools(response) -> list[str]:
    # tool_use / server_tool_use ブロックの名前を集める
    return [
        b.name for b in response.content
        if b.type in ("tool_use", "server_tool_use")
    ]

これは最小限の例示です。新しい製品名、直近のリリース、料金のように「古い答えが出やすい質問」を10〜20件並べ、effortごと・指示の有無ごとに検索の発生率を比べると、どの手が効いているかが分かります。回答の正しさまで見るなら、検索結果と照合する別の確認が要ります。

effortのドキュメントには、effortが低いほどツール呼び出しを少なくまとめる傾向があると書かれています。検索が減ること自体を不具合と決めつけず、検索を省いてよい質問と省けない質問を先に分けておくと、評価の指標を作りやすくなります。

引き続き残る注意点

system promptの指示は、検索を促すだけで、検索結果の正しさは保証しません。また、検索を増やせばその分トークンとレイテンシが増えます。low effortを選んだ理由が速度やコストだった場合、その利点を一部手放すことになります。

effort全体の使い分けはClaude Opus 5のeffort使い分け方に、Fable系の別の挙動はFable 5の早期停止をプロンプトで防ぐ方法にあります。モデルそのものの仕様はClaude Fable 5.1の解説にまとめています。