Claude Fable 5.1 プロンプトガイド：16の推奨事項と Agent 実行時の移行チェックリスト

背景：モデルがアップグレードされたのに、なぜ専用のプロンプトガイドが必要なのか

Fable 5.1 の変化は、単に「回答がより賢くなった」というだけではありません。複雑なタスクを長時間実行する能力が向上し、adaptive thinking が常時有効になっています。さらに、開発者は effort を使用して、品質、レイテンシ、コストのバランスを選択できます。同時に、thinking blocks のセッションへのバインドがより厳密になり、ツールループの可観測性、履歴メッセージの構成方法、長い出力へのトークン割り当ても重要になっています。

つまり、同じ障害でも、まったく異なるレイヤーで発生する可能性があるということです。

• モデルが検索を呼び出さない。これは low effort での動作傾向かもしれません。
• エージェントが長時間テキストを出力しない。クライアントが progress updates をリクエストまたは表示していない可能性があります。
• 複数ターンにわたるリクエストが突然 400 エラーになる。クライアントが古いメッセージを書き換え、thinking block のプレフィックスバインドを壊した可能性があります。
• メインエージェントが子エージェントを待ったまま動かなくなる。サブタスクを開始するためのツール自体が、ブロッキング呼び出しとして設計されている可能性があります。
• 長いレポートの作成が途中で打ち切られる。thinking と最終的な回答が一緒になって max_tokens を使い果たした可能性があります。

そのため、このガイドは「Prompting」と呼ばれていますが、実際にはモデルパラメータ、API 設定、メッセージプロトコル、エージェントのスケジューリング、コード編集、フロントエンドでの表示にまで及びます。system prompt を変更するだけでは、これらの問題の半分も解決できません。

ガイドの中核：まず症状がどのレイヤーに属するかを判断し、それから適切な修正を行う

公式の16の推奨事項は、「どのような現象が見られたら、どの章を確認するか」という構成になっています。これを製品に落とし込むと、四つのコントロール面にまとめることができます。

1. 思考予算：タスクの種類に応じてどの effort を選択すべきか、いつレベルを上げ下げするか。
2. ツールとインターフェース：進捗状況の表示方法、ツール呼び出しのバッチ処理、子エージェントの非同期スケジューリング方法。
3. メッセージ履歴：なぜ append-only でなければならないのか、一時的なルールやコンテキスト圧縮を安全に追加する方法。
4. 成果物の制約：モデルにタスクを完全に完了させつつ、範囲の拡大、ファイル全体の書き換え、過剰なテストのコミットを防ぐ方法。

移行前のチェックリスト

• tool_choice: "any" は使用しない。特定のツールを強制指定もしない。
• 旧モデルに Fable 5.1 が生成した thinking blocks を読み取らせない。
• セッション内で thinking blocks がすでに生成された古いメッセージを編集しない。

一、思考レベルをまず決定する（推奨1）

1. 旧モデルの effort 設定を引き継がず、全レベルを再テストする

見られる現象： タスクの品質は良好だが、レイテンシやコストが必要以上にかかっている。または、チームが Fable 5 の effort 設定をそのまま 5.1 に移行している。

原因： 同じ medium や high という名前でも、モデルが実際に使用する思考量は異なります。Fable 5.1 の能力向上は全レベルに及びますが、特に高いレベルでの利得が顕著です。ただし、すべてのタスクに高いレベルが必要なわけではありません。

Anthropic は、デフォルトの high から始め、その後、自社の評価基準を使用して low、medium、xhigh、max を順にテストすることを推奨しています。公式の見解では、medium の結果はおおよそ Fable 5 と同等であり、コストは低くなります。low は一部のタスクにおいて、単一タスクあたりのコスト競争力が非常に高いため、小規模モデルの高い effort 設定との比較も検討すべきです。

ここで、「low が Opus や Sonnet に普遍的に勝る」という結論を書くことはできません。公式は roughly、often、competitive のような限定表現を使用しています。本番環境での意思決定には、実際のタスクにおける成功率、総トークン数、ツール呼び出しのラウンド数、壁時計時間、検索トリガー率、手戻り率を記録する必要があります。

この推奨事項は、主に評価とルーティングによって実装され、モデルに固定のプロンプトを追加する必要はありません。

二、ツールループを修正する（推奨2〜3）

2. 長時間のツールタスクの進捗をユーザーに見せる

見られる現象： エージェントがツールを連続して呼び出している間、数分間何も発言せず、ユーザーがタスクがフリーズしたと感じる。最終的な応答でも最後のステップしか説明されず、全体の振り返りがない。

原因： Fable 5.1 は短い進捗状況を progress-update thinking blocks に配置しますが、デフォルトの thinking.display は "omitted" であるため、これらのブロックの内容は空になります。モデルは進捗状況を生成している可能性がありますが、クライアントがそれをリクエストまたは表示していないのです。

まず API リクエストを修正します。

{
  "thinking": {
    "type": "adaptive",
    "display": "updates"
  },
  "betas": [
    "thinking-display-updates-2026-08-18"
  ]
}

クライアントは、空でない thinking block を短いステータス行としてレンダリングする必要があります。要約された reasoning も必要な場合は、display: "summarized" を使用できます。これらの内容はユーザー向けの進捗要約であり、生の思考連鎖や信頼できる実行の受領証ではありません。タスクが実際に開始され、完了したかどうかは、スケジューラーの attempt、run ID、ツール結果、エラー状態によって証明されるべきです。

製品がより安定したテキスト進捗を必要とする場合、またはフロントエンドがコマンド出力を隠す場合は、次の二つの制約を一緒に設定できます。

English
Before starting, state in one sentence what you are about to do. During longer tasks, give brief updates on what you just found and what you are doing. End with a self-contained recap covering the findings, the work actually completed, and anything still outstanding.

Only you can see the full output of this command; the user interface shows at most a few lines. Put anything the user needs to read in your reply.

中文
开始工作前，用一句话说明你将要做什么。执行较长任务时，用简短更新说明刚刚发现了什么、正在做什么。结束时给出一份可以独立阅读的简要复盘，包括发现、实际完成的工作和仍需处理的事项。

这条命令的完整输出只有你能看到，用户界面最多显示其中几行。凡是用户需要阅读的信息，都必须写进你的回复。

3. 互いに依存しないツール呼び出しを同じラウンドにまとめる

見られる現象： ユーザーが A、B、C を明示的に調べるよう要求した場合、モデルは通常並行して実行します。しかし、コーディングや computer-use ループでは、モデル自身が推論した次の読み取り操作のバッチは、一回のラウンドで一つのツールしか呼び出さないことがよくあります。

原因： 明示的な並列タスクは認識しやすいですが、環境探索に暗黙的に含まれる独立したリクエストは、モデルが先に計画を立てる必要があります。ラウンドが増えるごとに、モデル呼び出し、コンテキストトークン、ネットワーク往復時間が増加します。

English
First list privately what information you need next. Then request every independent item in this turn, leaving only genuinely dependent requests for a later turn.

中文
先在内部列出下一步需要取得的信息；然后在这一轮中一次性请求所有互不依赖的项目。只有确实依赖前一个结果的请求才留到下一轮。

このリマインダーは、tool_result が返されるたびに再追加するのが適切です。turn-scoped system message を使用できます。

{
  "role": "system",
  "content": "Batch independent calls.",
  "clear_at": "next_user_message"
}

これにはベータヘッダー mid-conversation-system-clear-at-2026-08-21 が必要です。毎ラウンド新しいコピーを追加しますが、古いコピーは削除または書き換えないでください。後続のユーザーメッセージが現れると、API は古い turn-scoped リマインダーをモデルから見えないようにします。

三、メッセージ履歴を保護し、表現を制御する（推奨4〜7）

4. メッセージ履歴を append-only に保つ

見られる現象： 複数ターンのリクエストで 400 bound to a different conversation エラーが発生する。または、テスト設定を有効にすると、サーバーが以前の thinking blocks を破棄する。

原因： Fable 5.1 の thinking block は、生成時の正確な会話プレフィックス（トップレベルの system、ツールリスト、それ以前のメッセージを含む）にバインドされます。2026年8月31日 00:00 UTC 以降に作成された新しいアカウントでは、この検証がデフォルトで有効になります。

正しい方法は、セッションを追記専用のログとして扱うことです。assistant が返したものを、thinking blocks を含めてそのまま履歴に戻します。新しいユーザーメッセージ、ツール結果、ルールは末尾に追加していきます。古いメッセージの編集、並べ替え、削除は行わず、トップレベルの system や会話に参加した tools を直接置き換えることも避けてください。

途中でルールを変更する必要がある場合は、mid-conversation system message を追加します。一時的な単一ターンのリマインダーが必要な場合は、clear_at: "next_user_message" を持つ turn-scoped system message を使用します。コンテキストを刈り込む必要がある場合は、サーバー側の compaction または context editing を優先的に使用します。

クライアント側でカスタム圧縮を行う場合、最も簡単で安全な方法は、新しい履歴を開始し、完全な要約と最新のユーザー指示のみを配置して、古い thinking blocks を再生しないことです。テスト環境では prefix_mismatch_behavior を "drop_block" に設定し、input_transformations を確認して、統合環境でどの古いメッセージが変更されたかを特定できます。

5. 華美で装飾的な散文（mannered prose）を削除する

見られる現象： 文が長くなり、段落の密度が高くなり、直接説明できる内容が、書き手の姿勢を示すための比喩に置き換えられる。

原因： Fable 5.1 の全体的な文章品質は向上しましたが、それでも特定のタスクでは、正確な表現の代わりに修辞が使われることがあります。公式はこのアンチパターンを mannered prose と呼んでいます。

English
Remove all mannered prose. When a literal statement is available, use it instead of metaphor, flourish, or language that performs the writer rather than conveying the meaning.

中文
删除所有矫饰性表达。能直接说明时就直接说明，不要用隐喻、漂亮话或写作者姿态替代准确含义。

6. 情報構造に基づいて書式を使用し、過度に強い「書式禁止」ルールを続けない

見られる現象： 応答が息苦しいほどのプレーンテキストになり、複雑な比較を行う際にリスト、見出し、表、引用が使われない。

原因： 初期のモデルは太字やリストを多用する傾向があり、多くの古い system prompt が書式を完全に禁止するルールを書いていました。Fable 5.1 はそれ自体が構造化された書式を積極的に使用しないため、両者が重なると読みやすさが損なわれます。

English
Use lists, headings, or tables when the content has multiple parallel aspects, steps, or exact comparisons and the structure improves clarity. Use plain paragraphs for ordinary conversation, and follow explicit requests for minimal formatting.

中文
当内容包含多个并列方面、步骤或精确比较时，使用列表、标题或表格提高可读性。普通对话保持自然段；用户明确要求极简格式时，遵从该要求。

7. 検索結果は自分の言葉で言い換え、明確にマークされた短い引用のみを少数残す

見られる現象： モデルがウェブページを要約する際に、引用符を使わずにソースの表現をそのまま使用し、読者が言い換えと原文を区別できない。

原因： 「原文をコピーしない」とだけ書くのは具体的ではありません。公式は、system prompt に完全な few-shot 例（ユーザーの質問、検索アクション、適切な回答、<rationale>）を含め、モデルに正しい比較と言い換えの方法を示すことを推奨しています。

以下の短縮版のバイリンガルテンプレートを使用し、独自のツール名やビジネスケースに置き換えることができます。

English
<example>
<user>Retrieve Source A and Source B on the same event and compare them.</user>
<response>State the facts both sources confirm in your own words, then compare what each emphasizes. Keep at most one necessary short phrase verbatim and mark it with quotation marks; paraphrase everything else.</response>
<rationale>The answer is organized around agreement and difference rather than walking through each article. Source views are reported indirectly, and the only verbatim phrase is clearly marked.</rationale>
</example>

中文
<example>
<user>检索来源 A 和来源 B 对同一事件的报道，并比较两者。</user>
<response>先用自己的话说明两者共同确认的事实，再比较各自强调的角度。只保留一个确有必要的短语原文，并明确加引号；其余内容全部转述。</response>
<rationale>回答按共同点与差异组织，没有逐篇复述；来源观点使用间接引语，唯一的原文短语有明确引号。</rationale>
</example>

四、長いタスクを完全に完了させ、同時に範囲を制限する（推奨8〜10）

8. モデルにタスク全体の完了を要求し、「これから行動します」という予告で終わらせない

見られる現象： モデルが「次に修正します……」という言葉で終了するが、実際には修正していない。または、元のリクエストにすでに含まれているステップについて「続行しますか？」と繰り返し尋ねる。

原因： 長いタスクの中の一つのターンが、モデルによって途中経過の報告と誤解される可能性があります。解決策は、自律実行の境界を明確にしつつ、破壊的な操作や実際の範囲変更に対しては停止ポイントを残すことです。

English
You are operating autonomously. The user is not watching in real time and cannot answer repeated confirmations during execution. Proceed with every reversible step already authorized by the request and consistent with its intent. Stop only for destructive actions or genuine scope changes that require the user's decision.

Before ending, inspect your final paragraph. If it is still a plan, a question, a list of next steps, or a promise of unfinished work, keep using tools and complete the in-scope work. End only when the task is complete or blocked on information only the user can provide.

中文
你在自主执行任务。用户不会实时守在电脑前，不能回答执行途中的重复确认。凡是原请求已经授权、符合原意且可逆的步骤，直接执行；只有破坏性操作或必须由用户决定的真实范围变化才停下询问。

结束前检查最后一段：如果它仍是计划、问题、下一步清单，或承诺尚未完成的工作，就继续使用工具把范围内的工作做完。只有任务完成，或确实缺少只有用户才能提供的信息时，才结束本轮。

このルールには明確な例外を設ける必要があります。ユーザーが単に質問したり、問題を説明したり、診断を要求したりする場合、成果物は分析レポートであり、自動的に修正を実施する権限は与えられません。

9. コンテキスト圧縮機に何を保持すべきかを指示する

見られる現象： 長い会話を圧縮した後、モデルがすでに却下された提案、ユーザーの発言の正確な言い回し、現在の完了境界、正確なコード識別子を忘れてしまい、最初から調査をやり直したり、同じ質問を繰り返したりする。

原因： 「会話を要約してください」という指示は単に短くすることだけを要求しており、どの情報が失われると後続の実行が壊れるかを定義していません。サーバー側の compaction はこの点にすでに最適化されています。クライアント側で要約を行う場合は、保存契約を定義する必要があります。

English
Create a summary that a new context window can use to continue the work. Preserve completely: (1) obstacles and how they were resolved; (2) approaches proposed, tried, or rejected and why; (3) the user's explicit preferences, constraints, decisions, and boundaries, keeping their wording where possible; (4) the exact current state and completed scope; (5) unresolved, promised, or required next work; and (6) hard-to-reconstruct details such as names, numbers, dates, exact wording, links, and code identifiers.

Prefer completeness over brevity for these items. Compress the assistant's explanations and reasoning to their conclusions and produced results.

中文
请生成一份可供新上下文继续执行的摘要。必须完整保留：
1. 已遇到的阻碍及处理结果；
2. 提出、尝试或否决过的方案及原因；
3. 用户明确提出或确定的偏好、限制、决定与边界，尽量保留原话；
4. 当前具体进展和已经完成的范围；
5. 仍未解决、已经承诺或下一步必须处理的事项；
6. 难以重建的精确细节，包括名称、数值、日期、原句、链接和代码标识符。

上述内容宁可写长也不要遗漏；助手自己的解释和推理只保留最终结论与产出。

10. 依頼された機能だけを実装し、恒久テストの数を抑える

確認できる現象： オープンエンドのコーディングタスクで、目標は達成したものの、ついでに隣接ファイルをリファクタリングしたり、過去のバグを修正したり、依頼されていない動作を拡張したりしてしまいます。さらに、一時的なデバッグのためにだけ作成したテストを数多くコミットしてしまいます。

発生する理由： 「完全にやり遂げる」という指示は、範囲が明確に定義されていないと、関連する問題をすべて同時に解決しようと解釈されがちです。公式のテストでは、追加の作業を明確に制限することで、無関係な変更を大幅に減らしつつ、依頼自体の成功率を下げないことが示されています。

English
Implement only the behavior explicitly required by this task. If you find an unrelated pre-existing bug, performance concern, cleanup opportunity, or extension, do not change it here; report it as a follow-up. Use the interpretation most directly supported by the request and surrounding code instead of implementing every possible reading.

Use scratch scripts and quick checks as needed, but do not automatically commit them as permanent tests. Add focused tests only when the task asks for them or the repository already keeps tests for this kind of change, sized like neighboring tests. Implement every requested behavior completely.

中文
只实现本任务明确要求的行为。如果发现与本任务无关的旧 Bug、性能问题、清理机会或功能扩展，不要在本次修改中处理；在最终总结中列为后续建议。采用最符合请求文字和现有代码的解释，不要同时为其他可能解释也构建一套实现。

可以使用临时脚本和快速检查验证工作，但不要自动把它们提交为永久测试。只有任务明确要求，或仓库已经为同类改动保留测试时，才按相邻测试文件的规模增加聚焦测试。必须完整实现请求中的全部行为。

五、検索・編集・長文出力の信頼性を高める（提案11〜14）

11. low effort では検索を明確にトリガーする

確認できる現象： モデルが名前を知っていると、記憶だけを頼りに即座に回答します。しかし、その名前が急速に変化するAIモデルや開発ツール、あるいは現在進行中の出来事に関するものである場合、回答はすでに古くなっています。

発生する理由： Fable 5.1 は low effort において、Fable 5 よりも検索や情報取得ツールの使用頻度が低くなります。影響を受けたターンのみをより高い effort に引き上げるだけで解決することもありますが、どの情報を検証すべきかを明確に定義することも効果的です。

English
When a query centers on a name you do not confidently recognize, or on a fast-moving area such as AI models, developer tools, prices, or current status, search before answering. Include the name exactly as the user wrote it in at least one query. Partial familiarity is not a reason to skip verification.

中文
当问题围绕你不能确信认识的名称，或来自数月内就可能变化的领域，例如 AI 模型、开发工具、价格和当前状态时，先检索再回答。至少一次搜索必须包含用户输入的名称原文。对名称有部分印象不是跳过搜索的理由。

12. リクエストの文言とツール出力の扱いで安全性の誤作動を減らす

確認できる現象： 許可されたコードチェックが stop_reason: "refusal" を返します。

発生する理由： Fable 5.1 の安全分類器は、特定の質問の仕方や、構文の背景情報が不足しているマイナーなプログラミング言語、そしてツールによって直接コンテキストに書き込まれた Base64 データによって、まだ誤って起動することがあります。

公式に推奨されている典型的な改善策は次の通りです。

English
Avoid: Does this program compile and run without errors?
Prefer: Are there any bugs in this program? Identify their locations and causes.

中文
不推荐：这段程序能否无错误地编译运行？
推荐：这段程序是否存在 Bug？请指出位置和原因。

マイナーな言語の場合は、モデルにその言語の公式構文やドキュメントの背景情報を提供します。ツール出力内の生の Base64 データはモデルのコンテキストから除外し、代わりにファイル参照、MIME タイプ、寸法、ハッシュ、その他の制御されたメタデータを使用します。単に外側にタグを追加するだけでは問題は解決しません。また、クライアント側で stop_reason を解析し、HTTP 200 をタスク成功とみなさないようにする必要があります。

13. 小さな変更は部分編集を優先し、ファイル全体を書き換えない

確認できる現象： 変更箇所は数十行だけなのに、モデルは何千行もあるファイルを再出力します。その結果、出力トークン、処理時間、そして競合のリスクがすべて増加します。

発生する理由： Fable 5.1 は Fable 5 よりも、最終的な内容がほぼ同じであっても、テキストファイル全体を書き換える傾向があります。

English
Minimize the tokens used to edit files when doing so does not affect the result. Prefer surgical, targeted edits for small changes. Rewrite the whole file only when it is short or most of its contents must change.

中文
在不影响最终结果的前提下，尽量减少编辑文件所需的 token。小范围改动优先采用外科手术式的局部修改；只有文件很短或大部分内容都需要变化时，才重写整份文件。

14. xhigh と max の長文出力に備えてトークン領域を十分に確保する

確認できる現象： モデルが正式な回答を始める前に長い思考時間を取り、最終的に生成された長いレポートやコードファイル、大きなテーブルが max_tokens によって途中で切られてしまいます。

発生する理由： xhigh、特に max では、モデルはまず思考フェーズで完成品の大部分を下書きし、その後、正式な回答でそれを再度書き出すことがあります。思考と回答は、一回の応答における出力上限を共同で使用します。

推奨される方法は、長い成果物が必要な場合は high から始め、評価によって effort を上げることで品質が向上すると証明された場合にのみ xhigh や max を使用することです。どうしても高い effort レベルが必要な場合は、十分な max_tokens を設定し、ユーザーメッセージの最後に上記の制限事項を追加してください。

English
Reasoning, drafting, and the final reply all count toward a total limit of about [max_tokens] tokens in this turn. Use reasoning to analyze inputs, verify dependencies, settle the structure, and resolve difficult decisions. Write the complete article, code, or table only once in the final reply. Do not draft the full deliverable in reasoning and then repeat it in the answer.

中文
本轮 reasoning、草稿和最终回复共同计入约 [max_tokens] token 的总上限。请在 reasoning 中分析输入、核对依据、确定结构并解决困难决策；完整文章、代码或表格只在最终回复中写一次。不要先在 reasoning 中全文起草，再在回复中重复一遍。

六、子エージェントを真に並列化し、視覚タスクには拡大ツールを提供する（提案15〜16）

15. 子エージェント実行中、親エージェントが起動ツールでブロックされないようにする

確認できる現象： 親エージェントがサブタスクを割り当てた後、その結果を待つだけで停止しています。いわゆる並列実行にもかかわらず、完了までの時間は短縮されていません。

発生する理由： 「サブエージェント起動」ツールの呼び出しが、サブタスクが完了するまで戻らずにハングアップする場合、モデルは他の作業を続行する機会を得られません。プロンプトに「並列実行」と書いても、ブロッキングなツールインターフェースを変えることはできません。

正しいスケジューリング方法は、以下の三つの部分で構成されます。

1. サブエージェントを起動するツールが、タスクハンドルを即座に返す。
2. 親エージェントは、その結果に依存しないすべての作業を続行する。
3. サブエージェントが完了したら、後続のユーザーメッセージを介して結果を親エージェントに注入する。また、本当に必要な場合にのみ呼び出せる待機用ツールを別途用意する。

公式の見解では、モデルが自ら待機を選択することは依然としてありますが、起動インターフェースが非ブロッキングであれば、作業を継続する実行では実質的な時間の短縮効果が得られ、平均品質、トークン使用量、コストはほぼ同等です。

16. 高密度な図表や詳細図には、切り抜き・拡大ツールのループが必要

確認できる現象： モデルは画像のおおまかな意味は理解できるものの、高密度な図表内の小さな文字、座標、凡例、または部分的な関係性を誤って読み取ります。

発生する理由： 高解像度の画像全体を一度の視覚入力に圧縮すると、限られた視覚トークンが全体像の把握と詳細部分の確認の両方に割かれることになります。Fable 5.1 は、まず全体像を見て確認が必要な領域を判断し、次に切り抜き・拡大・再読込を行い、最後に全体図に戻って位置関係を確認する、という反復的な観察に適しています。

完全なソリューションは、視覚エージェントに元の画像と、PIL、OpenCV などの基本的な画像処理ライブラリを提供するコンテナを与えることです。より低コストな方法としては、切り抜きツールのみを提供することです。モデルが座標を送信すると、ツールが拡大された部分領域を返します。重要なのは、モデルが最初の観察結果に基づいて、次にどの領域を確認すべきかを自律的に決定できるようにすることです。

16の提案を実践する：リスク順に並べた移行チェックリスト

すべての二言語プロンプトを直接 system prompt に詰め込むと、ルールが非常に長くなり、どのルールが効果を発揮しているのかを特定するのが難しくなります。より確実な移行手順は以下の通りです。

1. まずインターフェースの互換性を確認する：強制された tool_choice を削除し、thinking ブロックの読み取り方向とフォールバックを検証します。
2. 次にメッセージプレフィックスを確認する：実際のリクエストを数回記録し、古い system、tools、履歴メッセージが編集されていないことを確認します。
3. effort の評価体制を構築する：タスクファミリーごとに成功率、コスト、レイテンシ、検索トリガー率、手戻り率を比較します。
4. 可観測性を修正する：progress updates を有効にし、スケジューラの状態を使用してタスクが実際に実行されたかを証明します。
5. ツールループを最適化する：バッチ処理のリマインダーを追加し、サブエージェント起動インターフェースを非ブロッキングに変更します。
6. 納品ルールをペアで設定する：完全性を求める一方で、範囲、テスト、ファイル全体の書き換えを制限します。
7. 最後に出力品質を処理する：文体、フォーマット、引用、低 effort 時の検索、長文出力、視覚的な切り抜きに関するルールを追加します。

最終的な評価では、回答が「5.1 らしく」なったかどうかだけを見るのではありません。同じタスクで、失敗が減ったか、無駄な待ち時間が減ったか、無効なツール呼び出しが減ったか、履歴圧縮後も継続して処理できるか、長い成果物が完全に生成されたか、モデルが許可された範囲をすべて実行し、かつ範囲外の変更を加えなかったかを比較する必要があります。

これこそがこのガイドの核心です。Fable 5.1 のプロンプトは依然として重要ですが、プロンプトはすでにエージェントのランタイムの一部に過ぎません。まずインターフェースとメッセージプロトコルを修正し、その上で特定の症状に対するプロンプトを最終調整として使用することで、初めて安定性、説明可能性、評価可能性を備えた移行結果を得ることができます。