Claude Fable 5.1新機能β3種の実装ガイド【2026年9月】

Claude Fable 5.1（2026年9月1日リリース）で実装側が新しく触るのは、βヘッダー3本と、コード変更が一切要らない来歴（content provenance）の合計4つだけです。会話の途中で effort を変える mid-conversation-output-config-2026-07-01、1ターンだけ効く system メッセージの mid-conversation-system-clear-at-2026-08-21、ツール呼び出しの合間の進捗テキストを受け取る thinking-display-updates-2026-08-18 — この3本をリクエストに足すだけで挙動が変わり、来歴は何もしなくても付きます。2026年9月2日時点で公式ドキュメントに書かれている仕様だけを、機能ごとに「使いどころ → リクエスト例 → レスポンスの読み方 → 落とし穴」の順で並べました。

移行そのもの（forced tool use の廃止、thinking ブロックのモデル束縛、履歴編集の禁止という破壊的変更3点）は姉妹記事で扱っています。まだ移行前の方は先にそちらを読んでください → Claude Fable 5.1 API移行ガイド｜破壊的変更3点の直し方。この記事は移行が終わった前提で、「新機能を実際に使うコード」だけを扱います。

結論：βヘッダー3行が全部。来歴はコード変更ゼロ

Claude Fable 5.1 の追加要素は公式ドキュメント上で5つ（per-message effort、turn-scoped system messages、progress updates の display: "updates"、キャッシュ読み取り価格の引き下げ、content provenance）。このうち価格は自動で効くので、開発者が書くコードは実質4つです。

機能	βヘッダー	触るフィールド	対応モデル（公式記載）
会話途中の effort 変更（per-message effort）	mid-conversation-output-config-2026-07-01	messages 内の role: "system" ＋ output_config.effort	Claude Fable 5.1 / Claude Mythos 5.1 / Claude Opus 5
ターン限定 system メッセージ	mid-conversation-system-clear-at-2026-08-21	role: "system" の clear_at	mid-conversation system messages と同じモデル・プラットフォーム
ツール呼び出し間の進捗テキスト	thinking-display-updates-2026-08-18	thinking.display	Claude Fable 5.1 / Claude Mythos 5.1 / Claude Fable 5
content provenance（透かしとC2PA）	不要	なし（リクエストもレスポンスも変更不要）	Claude Fable 5.1 / Claude Mythos 5.1

モデル本体の仕様は Claude Fable 5 から据え置きです。モデルIDは claude-fable-5-1、コンテキストは100万トークン、最大出力は12万8,000トークン、思考は常時オン（adaptive）で既定の effort は high、信頼できる知識のカットオフは2026年6月。価格は入力・出力ともに Claude Fable 5 と同じで、キャッシュ読み取りだけが基本入力価格の0.025倍（他の Claude モデルは0.1倍）に下がっています。出典は Claude Fable 5.1 のモデル概要と What’s new in Claude Fable 5.1（いずれも2026年9月2日確認）。

前提：なぜ「追記だけで指示を変える」機能が3つも足されたのか

3つのβ機能は別々に生まれたものではなく、Claude Fable 5.1 の破壊的変更のひとつ「earlier turns を編集すると thinking ブロックが無効になる」の裏返しです。公式ドキュメントは、あとから指示を足したいときに system や tools を作り直すのではなく、mid-conversation system message を追記しろ、と明示しています。会話を append-only（末尾に足すだけ）に保てば、thinking ブロックも壊れず、プロンプトキャッシュも温かいまま保てるという設計です。

公式が「後続の thinking ブロックを無効にする」と列挙している操作は次のとおりです。

• 過去のターンを編集・並べ替え・削除する（後続を残したまま）
• リクエストごとの文言（リマインダーやステータス行）を過去のターンに差し込み、次のリクエストで消す
• 同じ会話の中でトップレベルの system や tools 配列を作り直す
• 画像・ドキュメントのURLが後のリクエストで別のバイト列を返す（チェック対象はURLではなくバイト列なので、同一ファイルの署名付きURLのローテーションは問題なし）

2番目がまさに「毎ターンの注意書きを履歴に差し込んで次で消す」という、多くのエージェントハーネスがやっている実装です。これを正しく置き換えるのが turn-scoped system message、という関係になっています。破壊的変更の詳しい直し方はAPI移行ガイドにまとめてあります。

機能1｜会話の途中で effort を切り替える（per-message effort）

使いどころ

長いセッションの中で、難所だけ思考を深くし、定型作業では節約したいときに使います。Claude Fable 5.1 が対応する effort は low / medium / high（既定） / xhigh / max の5段階。公式の推奨は「high から始め、能力が要る agentic・コーディング作業では xhigh や max へ上げ、evals で品質が保てると確認できたら定型作業を medium や low へ下げる」です。

これまで effort はリクエスト単位（トップレベルの output_config.effort）でしたが、トップレベルの値を途中で変えると、レンダリングされるプロンプトが変わるためキャッシュ済みプレフィックスが効かなくなります。per-message effort はここを解決するもので、公式は「Claude Fable 5.1 ではトップレベルを変える方式よりこちらを優先せよ」と書いています。理由が2つ挙げられていて、1つはキャッシュが維持されること、もう1つはトップレベル変更はモデルの舵取りとしても効きが悪いという点です。過去の返答が前の effort で書かれているため、モデルはそれに合わせて一貫性を保とうとする、と説明されています。

リクエスト例

公式の例は「high で計画を立てさせ、そのあとの定型的な要約だけ low に落とす」という形です。effort だけを運ぶ system メッセージ（content が空配列）を messages に挟みます。

curl https://api.anthropic.com/v1/messages 
  -H "x-api-key: $ANTHROPIC_API_KEY" 
  -H "anthropic-version: 2023-06-01" 
  -H "anthropic-beta: mid-conversation-output-config-2026-07-01" 
  -H "content-type: application/json" 
  -d '{
    "model": "claude-fable-5-1",
    "max_tokens": 4096,
    "output_config": {"effort": "high"},
    "messages": [
      {"role": "user", "content": "Plan a migration from SQLite to PostgreSQL in three short steps."},
      {"role": "assistant", "content": "1. Export the SQLite data. 2. Create the PostgreSQL schema. 3. Import the data and verify row counts."},
      {"role": "system", "content": [], "output_config": {"effort": "low"}},
      {"role": "user", "content": "Summarize the plan in one sentence."}
    ]
  }'

Python SDK なら betas にヘッダー名を渡すだけです。

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=4096,
    output_config={"effort": "high"},
    messages=[
        {"role": "user", "content": "Plan a migration from SQLite to PostgreSQL in three short steps."},
        {"role": "assistant", "content": "1. Export the SQLite data. 2. Create the PostgreSQL schema. 3. Import the data and verify row counts."},
        # effort だけを運ぶ system メッセージ。新しい水準は次の user ターンから効く
        {"role": "system", "content": [], "output_config": {"effort": "low"}},
        {"role": "user", "content": "Summarize the plan in one sentence."},
    ],
    betas=["mid-conversation-output-config-2026-07-01"],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

レスポンスと効き方の読み方

レスポンス本体の形は変わりません。読み方として押さえるべきは、公式が書いている次の3点です。

• 効き始めるタイミング：新しい水準は次の user ターンから効き、あとのメッセージで変更されるまで維持されます。同じターンの中で即座に切り替わるものではありません。
• 置ける場所：effort だけの system メッセージはテキストを持たないため、mid-conversation system message の配置ルールが適用されません。messages のどこにでも置けます。配列の先頭でも、assistant ターンと次の user ターンの間でも構いません。エージェントループでは後者が使いどころになります。
• キャッシュ：そのメッセージより前は何も変わらないので、キャッシュ済みプレフィックスは一致し続けます。effort をリクエスト間で変えること自体は、後続の thinking ブロックを無効にしません（公式が「後続ブロックを有効なまま保つ操作」として明記）。

落とし穴

1. βヘッダーを付け忘れる／未対応モデルに送る：per-message effort に対応しないモデル（Claude Fable 5 を含む）は400を返し、メッセージは output_config.effort requires a model that supports per-turn effort; this model does not です。ルーターやフォールバックで別モデルへ流れる構成では、このエラーを握りつぶさないこと。
2. adaptive を effort の値として渡す：公式が名指しで注意しています。adaptive は thinking のモードであって effort の水準ではありません。effort に渡せるのは水準名（low / medium / high / xhigh / max）だけです。
3. low に落としたまま鮮度の要る作業をさせる：Claude Fable 5.1 は最も低い effort で検索・取得ツールの呼び出し回数が減り、記憶から答える頻度が上がると公式が明記しています。最新情報が要るターンでは、まさにこの機能で effort を上げ直すのが正しい使い方です。
4. max_tokens を据え置きで effort だけ上げる：high 以上では大きめの max_tokens を設定するよう公式が求めています。max_tokens は思考と応答テキストを合わせた総出力の上限（ハードリミット）だからです。effort だけ上げると、途中で打ち切られます。
5. turn-scoped メッセージに output_config を載せる：これは400になります（後述）。effort 変更と1ターン限定の注意書きは、別々の system メッセージに分けます。

effort の上げ下げはそのままトークン消費と請求に直結します。エージェントのコスト可視化をまだ入れていないなら、AIエージェントのコスト監視入門を先に済ませておくと、effort チューニングの効果が数字で見えます。モデルそのものの振り分け設計はClaude Opus 5のルーティング設計が参考になります。

機能2｜1ターンだけ効く system メッセージ（clear_at）

使いどころ

ツールループの中で「今回だけ」効かせたい注意書きに使います。公式が挙げている例は「独立した読み取りは1ターンにまとめて要求せよ」「シェルがステータス137で終了した」といった、その場のリマインダーです。

従来これをやるには、注意書きを履歴に差し込んで次のリクエストで消す実装が一般的でした。しかし Claude Fable 5.1 ではそれが履歴の編集にあたり、以降の thinking ブロックが会話チェックに落ちます。turn-scoped system message は「配列には残したまま、レンダリングだけ止める」ことでこれを回避します。クリアされたメッセージは入力トークンを消費しません（usage.input_tokens にもトークンカウントにも加算されない、と公式が明記）。

リクエスト例

clear_at が取る値は2つだけです。"never"（既定・フィールドを省略した場合と同じ）と "next_user_message"。後者を指定すると、そのメッセージより後ろに role: "user" のメッセージが存在しない間だけテキストがレンダリングされます。tool_result ブロックだけを載せた user メッセージも「user メッセージ」として数えられる点が重要です。

curl https://api.anthropic.com/v1/messages 
  -H "x-api-key: $ANTHROPIC_API_KEY" 
  -H "anthropic-version: 2023-06-01" 
  -H "anthropic-beta: mid-conversation-system-clear-at-2026-08-21" 
  -H "content-type: application/json" 
  -d '{
    "model": "claude-fable-5-1",
    "max_tokens": 4096,
    "messages": [
      {"role": "user", "content": "Draft a short status update on the database migration for the team channel."},
      {"role": "system", "clear_at": "next_user_message", "content": "The reader is on call: keep this reply under 50 words."}
    ]
  }'

ツールループでの実際の並びは次のようになります。messages[3] は前回のリクエストでは配列の末尾だったのでレンダリングされ、今回 messages[5]（後続の user メッセージ）が現れたことでクリアされます。配列からは消していないので、messages[4] の thinking ブロックより前の会話は変わりません。

{
  "model": "claude-fable-5-1",
  "max_tokens": 16000,
  "messages": [
    { "role": "user", "content": "Fix the failing test." },
    { "role": "assistant", "content": [ "...thinking...", "...tool_use toolu_01..." ] },
    { "role": "user", "content": [ "...tool_result toolu_01..." ] },
    {
      "role": "system",
      "clear_at": "next_user_message",
      "content": "Request independent reads in one turn."
    },
    { "role": "assistant", "content": [ "...thinking...", "...tool_use toolu_02, toolu_03..." ] },
    { "role": "user", "content": [ "...tool_result toolu_02...", "...tool_result toolu_03..." ] },
    {
      "role": "system",
      "clear_at": "next_user_message",
      "content": "Request independent reads in one turn."
    },
    {
      "role": "system",
      "clear_at": "next_user_message",
      "content": "The shell exited with status 137."
    }
  ]
}

※ 上の content 配列の中身は、記事の読みやすさのために公式例の構造だけを残して省略記法にしています。実際には thinking / tool_use / tool_result の各ブロックをそのまま入れてください。末尾のように、同じターンに turn-scoped メッセージを2つ並べることもできます（公式例では両方が順にレンダリングされます）。

レスポンスの読み方

レスポンス側に clear_at 由来の新しいフィールドは増えません。確認すべきはリクエスト側の会計で、公式は「レンダリングされたものだけがトークンに乗る」と書いています。つまり、クリアされたメッセージが積み上がっても usage.input_tokens は増えません。導入前後で同じ会話長のときの input_tokens を比べれば、リマインダーが本当に無料化できているかを検証できます。

キャッシュの挙動も明記されています。メッセージをクリアするリクエストでは、再利用できるキャッシュ済みプレフィックスはその1つ前の user ターンまでで終わり、そのメッセージと新しい user メッセージの間にある assistant ターン1つ分だけが再処理されます。

落とし穴

1. クリア済みメッセージを作り直す：公式が「verbatim（そのまま）で再送せよ」と明記しています。現在の状態から組み立て直す（トークン数やタイムスタンプを入れ直す）、不要だからと落とす、clear_at の値を変える — いずれも過去メッセージの編集にあたり、キャッシュが外れ、Claude Fable 5.1 では以降の thinking ブロックが全部チェックに落ちます。リマインダー文字列は定数にしてください。
2. テキスト以外を載せる：turn-scoped メッセージの content はテキストブロック（または文字列）だけです。tool_addition / tool_removal ブロックも output_config も400になります。ツール変更や effort 変更は clear_at を付けない別の system メッセージでやります。
3. cache_control を付ける：これも400です。クリアされたメッセージはキャッシュキーの一部にならないため、ブレークポイントを置いても一致しようがありません。ブレークポイントは直前の user ターンの最後のブロックに置きます。
4. 配置ルールを外す：クリア済みかどうかにかかわらず、turn-scoped メッセージは user ターン（またはサーバーツール結果で終わる assistant ターン）の後ろに置き、assistant ターンの前か配列の末尾で終わる必要があります。直後に別の user メッセージが来る配置は400で、「クリアされた状態」にはなりません。1回のツールラウンドの結果は1つの user メッセージにまとめ、リマインダーはその後ろに置く、が公式の指示です。
5. assistant ターンでクリアされると思い込む：クリアの条件は「後ろに user メッセージがあること」だけです。プレフィルや一時停止した assistant ターン、サーバー側のツールループは user メッセージを増やさないので、その継続でもリマインダーは表示され続けます。クライアント側のツールループで毎回見せたいなら、tool_result メッセージのたびに追記し直します。

機能3｜ツール呼び出し間の進捗テキスト（display: “updates”）

使いどころ

推論は隠したまま、ユーザーには各ステップのステータス行を見せたいエージェントUIのための機能です。Claude Fable 5.1 / Mythos 5.1 / Fable 5 は、ツール呼び出しの合間に「今何を見つけて、次に何をするか」を1〜2文で書きます。これは推論ではなく、エージェントを見ている人間に向けて書かれたテキストで、それを紹介する tool_use または server_tool_use ブロックの直前に、独自の signature を持つ独立した thinking ブロックとして届きます。各ツール呼び出しの前に来る進捗更新は最大1つで、モデルがスキップすることもあります。

問題は既定値です。Claude Fable 5.1 の thinking.display は "omitted" が既定で、このとき進捗更新ブロックも推論ブロックも thinking フィールドが空で返ります。つまり、長いエージェントターンがユーザーからは完全に沈黙して見えます。display: "updates" はここだけを開ける設定です。

リクエスト例

{
  "model": "claude-fable-5-1",
  "max_tokens": 16000,
  "thinking": { "type": "adaptive", "display": "updates" },
  "tools": [
    {
      "name": "edit_file",
      "description": "Replace the contents of a file in the repository.",
      "input_schema": {
        "type": "object",
        "properties": {
          "path": { "type": "string" },
          "content": { "type": "string" }
        },
        "required": ["path", "content"]
      }
    }
  ],
  "messages": [
    {
      "role": "user",
      "content": "The login test fails after an hour of uptime. Find out why and fix it."
    }
  ]
}

これに anthropic-beta: thinking-display-updates-2026-08-18 を付けます。ヘッダーがないと、未知の display 値と同じ400 invalid_request_error で弾かれます。Amazon Bedrock / Google Cloud / Microsoft Foundry では、各プラットフォームのβヘッダーの渡し方に従います。

レスポンスの読み方

display の値で何が入るかは次の表のとおりです。

display	推論ブロック	進捗更新ブロック
"omitted"（これらのモデルの既定）	thinking フィールドは空	thinking フィールドは空
"updates"（β）	thinking フィールドは空	要約テキスト
"summarized"	要約テキスト	要約テキスト（推論ブロックと区別できない）

つまり "updates" のもとでは、テキストが空でない thinking ブロック＝進捗更新です。公式は「それだけをレンダリングし、他は何も出すな」と書いています。実際のレスポンスは次の形になります。1つ目は推論ブロックなので空のまま、2つ目がテキストを持つので進捗更新です。

{
  "content": [
    {
      "type": "thinking",
      "thinking": "",
      "signature": "EqMBCkYICxIM..."
    },
    {
      "type": "thinking",
      "thinking": "Confirmed the retry path never refreshes the expired token. Editing auth.py to add the refresh call.",
      "signature": "Es8CCkYICxIM..."
    },
    {
      "type": "tool_use",
      "id": "toolu_01D7FLrfh4GYq7yT1ULFeyMV",
      "name": "edit_file",
      "input": { "path": "auth.py", "content": "..." }
    }
  ]
}

ストリーミングでは、進捗更新ブロックのテキストが thinking_delta イベントとして流れ、そのあとに紹介対象の tool_use ブロックが開きます。判定は「そのブロックの thinking_delta のいずれかが空でないテキストを運んだ瞬間に進捗更新とみなす」でよい、と公式が明記しています。display: "omitted" では thinking_delta は一切出ず、"updates" では進捗更新ブロックだけが thinking_delta を出します。

落とし穴

1. UIが narration に依存しているのに移行してしまう：Claude Fable 5.1 は Claude Fable 5 より進捗更新を書く回数が少なく、特に高い effort と長いツールチェーンで減ります。"updates" を入れても期待した本数が出ない場合があります。公式の対処は「最終応答まで発見を伏せておけ」型のプロンプト行を削除し、必要なら冒頭の一言・定期的な更新・締めのまとめを明示的に頼むこと。
2. 空のブロックに何かを描画する：進捗更新ブロックは、どの display 値でも thinking フィールドが空で返ることがあります。空なら何も描画しないのが正解で、"updates" のもとでは空の推論ブロックと見分けがつかず、区別する必要もありません。
3. テキストの長さで課金を見積もる：受け取るテキストは進捗更新の要約で、通常1〜2文です。長さに依存した実装をしないこと。課金上は要約ではなく元の長さで usage.output_tokens に乗ります。
4. 打ち切り時の定型文を知らずにエラー表示する：max_tokens / model_context_window_exceeded / stop_sequence で応答が止まったとき、最後のブロックが「終わらなかった作業の代わり」の進捗更新ブロックになることがあります。"updates" と "summarized" ではそのテキストがちょうど This part of the response was interrupted before it finished. になります。他の更新と同じように表示してよく、続けるには assistant ターンをそのまま返し、そのターンの各 tool_use に対応する tool_result を入れた新しい user メッセージを足します。
5. 「思考が見える」と誤解する：どの display 設定でも生の思考連鎖は返りません。"updates" で得られるのはステータス行であって推論の可視化ではありません。ブロックをそのまま返送する義務は変わらず、進捗更新ブロックも他の thinking ブロックと同様に無改変で assistant ターンごと返します。

機能4｜content provenance（テキスト透かしとC2PA）

使いどころ

これだけは「実装する」機能ではなく、「もう付いていることを説明できるようにしておく」種類のものです。Claude Fable 5.1 と Claude Mythos 5.1 が生成したテキストは、そのモデルが提供されているすべてのプラットフォームで Anthropic の統計的テキスト透かしを帯びます。Claude が生成した対応形式の画像・動画ファイル（たとえばコード実行ツール経由のもの）は、Claude API の Files API 経由で取得したときに署名付きの C2PA Content Credentials を持ちます。

実務での使いどころは、AI生成物であることの機械可読な表示が求められる場面です。EU域内で提供する製品なら、透明性義務との関係を整理しておく必要があります（EU AI法第50条の対応まとめ）。

リクエスト例：変更なし

公式は「リクエストにもレスポンスにも変更は要らない」と明記しています。透かしは出力の意味・品質・可読性を変えず、トークンを増やさず、隠し文字も入れず、あなたや組織に関する情報を一切運びません。つまり、この節でコード例を出すとしたら「何も足さない」が正解です。C2PA が付くのは Files API 経由で取得した対応ファイルなので、触るとすれば取得側の実装ですが、その具体的なコードは本記事が参照した一次情報には載っていません（2026年9月2日時点）。Files API のドキュメントを直接参照してください。

読み方：見て確認する手段が現時点では限られる

Anthropic のサポート記事「How Claude marks AI-generated content」（2026年9月2日確認）によると、透かしは知覚できず、コピー＆ペーストしても残り、「一部の編集を経ても残ることがある（may persist through some editing）」とされています。マーキングの対象は Claude Platform（API）、Claude、Claude Code、Claude Cowork、Claude Tag に加え、AWS・Google Cloud・Microsoft Foundry 上の提供分です。

検出側は現時点でプライベートプレビューで、規制当局・法執行機関・報道・ファクトチェッカー・独立研究者・教育機関・EUの市民社会団体といった対象組織、およびコンプライアンス上の義務を負う企業に限って提供されています。つまり「自社の出力に透かしが入っているか自分で確かめる」ことは、一般の開発者にはまだできません。背景は Anthropic のテキスト透かしの発表にもまとまっています。

落とし穴

1. 対象ファイル形式の粒度が資料によって違う：What’s new は「対応する画像・動画ファイル」と書き、サポート記事は「.svg、.png、.jpg」と列挙しています。自分が扱う形式に署名が付くかは、形式ごとに公式で確認してください。
2. 透かしを「AI生成の証明」として運用に組み込む：公式が保証しているのは「編集を経ても残ることがある」までで、必ず残るとは書かれていません（2026年9月2日時点）。透かしの有無を単独の判定根拠にする運用設計は避けるのが安全です。
3. C2PA署名が示す範囲を広く取りすぎる：サポート記事の説明では、署名は「Claude がそのファイルを処理したこと」を示し、その後の改ざんを明らかにできる、というものです。生成の全工程の証明ではありません。
4. API だけの話だと思う：マーキングの対象サーフェスには Claude Code や Claude Cowork も含まれます。社内での成果物の扱いを決めるときは、API経由の出力だけでなく、これらのツールの出力も同じ前提で考える必要があります。

Claude Code と Agent SDK からはどう見えるか

公式ドキュメントの記述範囲で言えることは3つです。

1. 履歴編集チェックは自前でやらなくてよい。 Claude Code、claude.ai、Claude Managed Agents、そして Claude Agent SDK は、thinking ブロックの前にあるプレフィックスをそのまま保つよう作られている、と What’s new が明記しています。履歴編集チェックを走らせる必要があるのは、messages 配列を自分のコードで組み立てている場合です。

2. 並列ツール呼び出しのばらつきは、自作ハーネス側に出る。 Claude Fable 5.1 は、Claude Fable 5 が複数まとめて出していた場面で1ターンに1回のツール呼び出しになることがあります。公式が「顕在化する場所」として挙げているのは、カスタムのコーディングエージェント、bash とエディタを組み合わせたハーネス、コンピュータ操作です。回答の質が落ちるわけではなく、余分なターンがトークン・往復・実時間を食う、という影響の出方です。対処は Prompting Claude Fable 5.1 にある1行のバッチ指示を足すこと。上で見た turn-scoped system message の公式例が「Request independent reads in one turn.」だったのは、まさにこの用途です。

3. narration の減少はUI設計に効く。 長いツール実行中にモデルが書くユーザー向けテキストが減り、特に高い effort で顕著です。Claude Code のようなツールのUI上でこの3つのβをどう設定できるかは、本記事が参照した一次情報には記載がありません（2026年9月2日時点）。ここで扱っているのは Claude API のリクエストパラメータの話であり、各ツールのUI設定として提供されているかは別途確認が必要です。

サブエージェントを含む構成でどうループを組むかはClaude Codeサブエージェントfork既定化の記事で扱っています。

3つを1つのエージェントループに入れる最小構成

ここまでの配置ルールを踏まえると、エージェントループでの挿入順は一意に決まります。effort だけの system メッセージは「assistant ターンと次の user ターンの間」に置けて、新しい水準は次の user ターンから効く。turn-scoped メッセージは「user ターンの後ろ、配列の末尾」に置ける。この2つは同じメッセージに同居できない（turn-scoped に output_config を載せると400）。したがって、1ラウンドの並びは assistant → effort変更（必要な時だけ）→ tool_result をまとめた user → 1ターン限定のリマインダー になります。

import anthropic

client = anthropic.Anthropic()

BETAS = [
    "mid-conversation-output-config-2026-07-01",
    "mid-conversation-system-clear-at-2026-08-21",
    "thinking-display-updates-2026-08-18",
]

# 定数にする。毎回組み立て直すと「過去メッセージの編集」になる
REMINDER = "Request independent reads in one turn."

messages = [{"role": "user", "content": "Fix the failing test."}]

while True:
    response = client.beta.messages.create(
        model="claude-fable-5-1",
        max_tokens=16000,
        output_config={"effort": "high"},
        thinking={"type": "adaptive", "display": "updates"},
        tools=TOOLS,
        messages=messages,
        betas=BETAS,
    )

    # (1) テキストが空でない thinking ブロックだけがステータス行
    for block in response.content:
        if block.type == "thinking" and block.thinking:
            render_status_line(block.thinking)

    # (2) assistant ターンは無改変でそのまま返送する
    messages.append({"role": "assistant", "content": response.content})
    if response.stop_reason != "tool_use":
        break

    # (3) 難所だけ effort を上げる。assistant ターンと次の user ターンの間に置く
    if needs_deep_step(response):
        messages.append({
            "role": "system",
            "content": [],
            "output_config": {"effort": "xhigh"},
        })

    # (4) 1ラウンド分の tool_result は1つの user メッセージにまとめる
    messages.append({"role": "user", "content": run_tools(response)})

    # (5) 1ターンだけ効くリマインダーを user ターンの後ろに足す（配列の末尾）
    messages.append({
        "role": "system",
        "clear_at": "next_user_message",
        "content": REMINDER,
    })

2周目に入ると、(5) で足したリマインダーの後ろに新しい tool_result の user メッセージが現れるため、そのリマインダーは自動的にクリアされます。配列からは消さず、次のラウンドでも同じ文字列のまま送り続けます。これが「積み上がらないのに履歴も壊さない」状態です。

注意点を2つ。レスポンスブロックを保持するフィールドはワイヤー上は thinking（公式のレスポンス例で確認）ですが、SDKの属性名はバージョンで変わり得るので手元で確認してください。それと、3つのβヘッダーを同時に有効化した構成の可否について明示的な記述は、本記事が参照した一次情報にはありません（2026年9月2日時点）。まず1つずつ単体で検証してから合成することをおすすめします。

よくある失敗5パターン

症状	原因	直し方
400 output_config.effort requires a model that supports per-turn effort; this model does not	per-message effort 非対応モデル（Claude Fable 5 など）へ送っている	モデルIDを claude-fable-5-1 等に揃える。ルーターのフォールバック先も確認する
400 messages.N.clear_at: Extra inputs are not permitted	βヘッダー mid-conversation-system-clear-at-2026-08-21 が付いていない	ヘッダーを追加する（これがヘッダーなしのときのエラー）
400 output_config is not permitted on a turn-scoped system message	effort 変更とリマインダーを同じ system メッセージに詰めた	2つの system メッセージに分ける
リマインダーを入れた直後から thinking ブロックが400で弾かれる	クリア済みメッセージを組み立て直した／削除した	リマインダー文字列を定数化し、配列から消さず verbatim で再送する
display: "updates" にしてもステータス行がほとんど出ない	Claude Fable 5.1 は進捗更新が少なく、高い effort と長いツールチェーンでさらに減る	「最終応答まで発見を伏せる」プロンプト行を削除し、冒頭の一言・定期更新・締めのまとめを明示的に頼む

よくある質問

Claude Fable 5.1 は Claude Fable 5 と何が違いますか？

追加要素は5つ（per-message effort、turn-scoped system messages、display: "updates"、キャッシュ読み取り価格の引き下げ、content provenance）、破壊的変更は3つ（forced tool use の非対応、thinking ブロックが生成モデルに束縛されること、過去ターンの編集で thinking ブロックが無効になること）です。入力・出力の価格は据え置きで、キャッシュ読み取りだけが基本入力価格の0.025倍に下がっています。破壊的変更の対処はAPI移行ガイドを参照してください。

βヘッダーを付け忘れるとどうなりますか？

機能ごとにエラーの出方が違います。clear_at はヘッダーがないと未知のフィールドとして messages.N.clear_at: Extra inputs are not permitted で弾かれます。display: "updates" はヘッダーがないと、未知の display 値と同じ400 invalid_request_error になります。per-message effort は、非対応モデルの場合に output_config.effort requires a model that supports per-turn effort; this model does not を返します。

C2PAとは何ですか。「来歴」とは何を指しますか？

C2PA は Coalition for Content Provenance and Authenticity が策定した、コンテンツの来歴（どこで作られ、その後どう扱われたか）を機械可読な形でファイルに埋め込むためのオープン標準です。Claude の文脈では、生成された対応形式のファイルに署名付きの Content Credentials が付き、Claude がそのファイルを処理したことを示し、その後の改ざんを明らかにできる、という位置づけになります。テキスト側は C2PA ではなく統計的テキスト透かしで扱われます。

自分の出力に透かしが入っているか確認できますか？

2026年9月2日時点では、一般の開発者が自分で確認する手段は提供されていません。検出はプライベートプレビューで、規制当局・法執行機関・報道・ファクトチェッカー・独立研究者・教育機関・EUの市民社会団体などの対象組織と、コンプライアンス上の義務を負う企業に限られています。

effort は何段階ありますか。どこから始めるべきですか？

low / medium / high / xhigh / max の5段階で、Claude Fable 5.1 は全段階に対応します。API の既定は high で、high を明示することとパラメータを省略することは同じ挙動です。公式の推奨は high から始めること。上げるのは能力が要る agentic・コーディング作業、下げるのは evals で品質が保てると確認できた定型作業や遅延重視の作業です。high 以上では max_tokens を大きめに設定してください（思考と応答テキストを合わせた総出力のハードリミットです）。

まとめ：先に1つずつ、次に合成する

3つのβはどれも「会話を末尾に足すだけで運用する」ための道具で、Claude Fable 5.1 の履歴編集チェックとセットで理解すると腹落ちします。導入順としては、まず display: "updates"（UIへの影響だけで済み、失敗しても壊れない）、次に turn-scoped system message（既存のリマインダー差し込み実装をそのまま置き換えられる）、最後に per-message effort（コストと品質のチューニングなので evals が要る）という順が扱いやすいはずです。content provenance はコードの作業がないぶん、社内の説明責任の整理として先に手を付けておくと後で困りません。

移行そのものがまだの方、あるいは forced tool use や thinking ブロックの400で止まっている方は、先にClaude Fable 5.1 API移行ガイド｜破壊的変更3点の直し方を読んでください。この記事の内容は、その移行が済んでいることが前提です。

参照した一次情報（すべて2026年9月2日確認）：What’s new in Claude Fable 5.1／Claude Fable 5.1 overview／Effort／Mid-conversation system messages and tool changes／Thinking／How Claude marks AI-generated content／Migrating to Claude Fable 5.1

著者：佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。著書『AIエージェント仕事術』。

あわせて読みたい

• ▸ Claude Fable 5.1 API移行ガイド｜破壊的変更3点の直し方
• ▸ Notion Agent APIの使い方｜Sessions実装4手順
• ▸ Claude Code GitLab連携完全ガイド【2026年8月】
• ▸ Microsoft Agent Framework for Go公開｜使い方解説
• ▸ GitHub Copilot×Ollama接続ガイド｜BYOKでローカルLLM