Fable 5.1のper-message effortを安全に使う

結論：beta headerと評価用会話を固定してから切り替える

per-message effortは、トップレベルのeffort設定やthinkingのbudgetとは同じではありません。公式のEffortドキュメントで、対応モデル、level、output_config、betaの範囲を公開直前に確認します。betaである以上、仕様変更を前提にversion、header、評価結果を記録します。

何を変え、何を変えない機能か

Claude Platform release notesによると、system roleのメッセージに後続turnのeffortを置き、prompt cacheを保持したまま変更するのが要点です。会話のすべての設定を毎回作り直すのではなく、品質が必要なturnだけmaxやxhigh、定型処理でmediumやlowを試せます。どのlevelが使えるかはモデルごとに異なるため、名前だけで共通化しません。

公式Effortドキュメントは、effortが回答テキストだけでなくtool call、function arguments、thinkingを含む出力全体へ影響すると説明しています。lowにすれば料金が一定割合で下がる、maxにすれば品質が必ず上がる、と固定値で断定しません。taskの成功率、再試行、処理時間、出力token、human review時間を同じテストで比較します。

turn	候補level	確認する指標
要件整理	medium	抜け、質問の正確さ、速度
設計・難しい実装	high / xhigh	テスト通過、tool判断、再作業
最終要約	low / medium	事実保持、短さ、レビュー時間
失敗時	固定levelへfallback	error、再試行、費用上限

会話途中で切り替える8手順

1. モデルID、SDK version、API endpoint、現在のeffortを記録します。
2. 同じ会話で比較する要件、入力、期待する完了条件を固定します。
3. 公式ドキュメントで対応モデルとbeta header名をreadbackします。
4. system messageの適用turnと、後続turnへ残る設定を実装上で確認します。
5. highを基準にmedium、low、必要ならxhighを一つずつ試します。
6. max_tokensをthinkingと最終応答の合計に足りる値へ設定します。
7. 品質、token、latency、tool call、review時間、再試行をログへ分けます。
8. 一定回数の評価後に採用level、fallback、上限、見直し日を承認します。

評価用会話は、単純な質問だけでなく、途中で要件が追加されるケース、toolの結果を受けて判断するケース、長いcontextを要約するケースを含めます。per-message変更後にprompt cacheが維持されるという仕様上の利点と、会話の履歴・system messageの意図が正しく伝わることを別々に確認します。

実装と運用の境界

リクエストへbeta headerとoutput_configを追加するだけで導入完了とはしません。利用者が会話途中で任意にmaxへ変更できるなら、費用と品質のownerが不明になります。用途別の許可level、対象workspace、上限、変更理由を設定し、通常の定型処理はmedium、重要な判断はhigh以上というように業務ルールへ翻訳します。

エラー時は、headerが受け付けられない、対象modelが違う、system messageの位置が不正、max_tokensが不足するなどを分けます。fallbackで別のlevelや通常設定へ戻す場合、ユーザーへ設定が変わったことを表示し、結果の比較可能性を壊さないようにします。ログへpromptや秘密情報をそのまま残さず、version、level、token集計、判定結果を中心に保存します。

チェックリスト：per-message effortを承認する前に

対象modelの正式IDがあるか／beta headerを固定したか／変更するturnと適用範囲を説明できるか／prompt cacheを保つ条件を確認したか／max_tokensに余裕があるか／tool callとthinkingを含めて評価したか／quality・latency・費用を同じデータで比べたか／失敗時fallbackと停止条件があるか／beta仕様の再確認日とownerがあるか、を確認します。

cacheの設計はFable 5.1のPrompt Caching料金、モデル条件はFable 5.1とMythos 5.1の選び方、APIの費用観測はClaude API料金削減も参照してください。effortを単独の速度設定にせず、会話の完了条件と人間確認へ接続します。

業務への適用では、levelを利用者の好みで変えるのではなく、タスク分類に対応させます。たとえば要件整理のmediumから設計のhighへ移る条件を明示し、最終要約でlowへ戻すときは、重要な数字や固有名詞が保持されるテストを通します。変更履歴にはlevelだけでなく、会話の目的と結果の採否も残します。

よくある質問

per-message effortは通常のeffortと違いますか？

トップレベルのeffortがリクエスト全体の設定なのに対し、per-messageは会話途中の後続turnへ設定を変えるbeta機能です。対応条件とheaderを公式情報で確認します。

maxなら常に最良の答えになりますか？

最も高いlevelがすべての業務に適するとは限りません。成功率、再作業、費用、遅延、人間レビューを測り、業務ごとに決めます。

beta機能を全社で使うには？

まず小さな評価群へ限定し、version、header、許可level、fallback、ログ、停止条件を管理します。仕様更新時に再評価できる台帳を残します。

公式情報と無料診断

変更内容は公式release notes、levelと実装は公式Effortドキュメント、cache条件は公式Prompt cachingを公開直前にreadbackしてください。Miraigentの無料診断では、品質・費用・権限・fallbackを業務単位で整理します。