Anthropic は Claude Fable 5 と Claude Mythos 5 向けのプロンプトエンジニアリングガイドを公開しました。この文書の重点はモデル能力そのものではなく、既存の Claude Opus 4.8 ワークフローを Fable 5 に移行する場合、プロンプト、Agent harness、タイムアウト戦略、安全フォールバックを調整する必要があるという点です。
Fable 5 の変化は、簡単に言えばこうです。長時間で複雑なエンドツーエンドのタスクにより向いている一方、高 effort では計画、確認、コンテキスト拡張により多くの時間を使う場合があります。うまく使うには、古いプロンプトをそのまま移すのではなく、タスク境界、検証方法、長時間タスクのやり取りを設計し直すことが重要です。
まずタスク難度を上げてテストする
Anthropic は、Fable 5 を簡単なタスクだけでテストしないことを勧めています。強みが見えやすいのは、以前なら人が数時間、数日、場合によっては数週間かけていた作業です。たとえば大規模なコード移行、多段階分析、複雑な Agent フロー、文書横断の調査、高精度な視覚理解です。
短い質疑応答、簡単な要約、一回限りの小さな関数だけで評価すると、Fable 5 を過小評価しやすくなります。より適切なのは、旧モデルが苦労していた種類のタスクを使い、理解、計画、実行、検証までの一連の流れを任せることです。
テストに適したタスクは次のようなものです。
- モデルにコードベースを読ませ、モジュール横断の変更を行わせる；
- 目標仕様に基づいて機能を実装し、テストを追加し、チェックを実行させる；
- Agent に複数日にわたる調査や分析フローを処理させる；
- スクリーンショット、表、PDF、グラフから構造化情報を抽出させる；
- 複数のサブ Agent に独立タスクを分担させ、主 Agent が結果をまとめる。
effort が主な制御ノブ
Fable 5 では、effort が知能、レイテンシ、コストを制御する主なパラメータです。公式の推奨では、多くのタスクは high から始め、能力感度が最も高い重いタスクには xhigh を使い、通常作業には medium または low を使います。
注目すべき点は、Fable 5 の低い effort 設定でも、旧モデルの高い effort 設定を上回る場合があることです。移行時にすべてのタスクを最高設定にする必要はありません。よりよい戦略は次のとおりです。
- 難題や高価値タスクにはまず
highを使う； - 最重要の複雑推論や長時間タスクには
xhighを使う； - 通常の質疑応答、軽いリライト、簡単なツール呼び出しには
mediumまたはlowを使う； - タスクは完了するが時間がかかりすぎる場合は effort を下げる；
- 出力検証が弱い、または推論が浅い場合は effort を上げる。
高 effort の利点は、推論と自己確認が強くなることです。一方で、モデルが余分にコンテキストを集めたり、説明を増やしたり、不要な整理をしたりすることがあります。コーディングタスクでは、プロンプトで範囲を明確に制限するのがよいです。
|
|
長時間タスクではタイムアウト、ストリーミング、進捗表示を変える
Fable 5 は難しいタスクでは単一リクエストが数分間実行されることがあり、自律タスクでは数時間続くこともあります。これは移行時に最も見落としやすい点の一つです。
アプリケーションが短いリクエスト前提で設計されている場合、まず次を確認します。
- クライアントとサーバーのタイムアウト時間；
- streaming に対応しているか；
- UI で進捗を表示できるか；
- Agent harness が非同期チェックをサポートしているか；
- ずっとブロックするのではなく、定期ジョブでポーリングする必要があるか。
曖昧なタスクでモデルが過剰に計画するのを避けるには、短い制約を加えます。
|
|
Fable 5 は指示追従能力が強いため、このような短い指示は長い行動リストより効果的です。
進捗報告は実際の証拠に基づかせる
長時間 Agent 実行では、モデルがもっともらしいがツール結果に裏付けられていない状況報告を出すことがあります。Anthropic は、ユーザーに報告する前に進捗を監査するようプロンプトで求めることを勧めています。
次のような制約を使えます。
|
|
これはコード Agent、データ処理 Agent、長時間の調査タスクで重要です。ユーザーが必要としているのは楽観的な状態ではなく、追跡でき、確認できる進捗です。
境界を明確にする
Fable 5 はより能動的で、明示的に求められていない行動を取ることがあります。たとえばメールを下書きする、バックアップブランチを作る、タスク範囲を広げる、といったことです。古いプロンプトを移行するときは、「いつ判断だけを返すのか」「いつ実行してよいのか」を明確にします。
例：
|
|
このルールはカスタマーサポート、運用、開発者ツール、企業の知識業務に適用できます。モデルが有能になるほど、権限境界を明確に定義する必要があります。
サブ Agent をより積極的に使う
公式文書では、Fable 5 は旧モデルより並列サブ Agent の起動と維持が得意だとされています。複雑なタスクでは、すべての手順を主 Agent が順番に処理する必要はありません。独立したサブタスクを切り出し、主 Agent は主線を進め、サブ Agent が逸れたときに介入するほうがよいです。
サブ Agent に向いているタスクは次のようなものです。
- コードベースの異なるモジュールから関連実装を探す；
- 修正が仕様を満たしているか独立に検証する；
- 異なる文書やデータソースを分析する；
- フロントエンド実装を視覚的に照合する；
- 最終出力を fresh-context でレビューする。
長時間タスクでは、Anthropic は自己批判だけに頼らず、独立した検証サブ Agent を使うことも勧めています。プロンプトでは次のように要求できます。
|
|
これは「モデルが自分で正しいと思い込む」問題を減らします。
記憶システムは長期性能を高める
Fable 5 は記憶を持つワークフローに向いています。公式は、Markdown ファイルのような簡単なものでも、モデルが経験を記録できる場所を用意することを勧めています。重要なのは、チャット履歴をコピーするのではなく、再利用できる教訓を記録することです。
簡単なルールは次のとおりです。
|
|
これはコードベースの継続保守、長期研究プロジェクト、企業知識ベース、複雑な自動化フローで特に有効です。Fable 5 は一回限りの実行器にとどまらず、複数タスクの間でコンテキストを蓄積する使い方に向いています。
内部推論の復唱を求めない
Fable 5 へ移行するときは、古い prompt、skill、system 指示に「思考過程を示す」「推論を復唱する」「内部 reasoning を説明する」といった要求がないか確認します。公式文書は、この種の指示が reasoning_extraction 拒否カテゴリを引き起こし、Claude Opus 4.8 へのフォールバックを増やす可能性があると明確に警告しています。
アプリケーションが本当に推論の可視性を必要とする場合は、モデルに内部推論を通常の返信テキストとして出力させるのではなく、構造化された thinking blocks を読むべきです。長時間タスクでユーザーに進捗を表示する必要がある場合も、send_to_user のようなツールを作り、Agent が実行を中断せずにそのまま表示すべき情報を送れるようにするほうが適しています。
安全分類と fallback に注意する
Fable 5 は高リスク領域向けの安全分類器を実行します。対象には、攻撃的なサイバーセキュリティ技術、生物・生命科学コンテンツ、モデルの要約思考を抽出する要求などがあります。正当なサイバーセキュリティや生命科学タスクでも、保護機構が作動する可能性があります。
リクエストが拒否またはルーティングされた場合、API 側では Claude Opus 4.8 への server-side または client-side fallback を設定する必要があります。つまり、Fable 5 への移行はモデル名を変えるだけではありません。失敗処理、stop_reason: "refusal"、ユーザー向けメッセージ、課金経路も確認し直す必要があります。
ユーザーへの最終返信はより明確にする
長時間のツール呼び出しや Agent ワークフローの後、モデルは多くの内部コンテキストを蓄積し、最終要約が実行者にしか分からない shorthand になりがちです。Anthropic は、最終返信のスタイルを別途制約することを勧めています。結果を先に述べ、次に重要な補足情報を示し、作業中の略語、矢印チェーン、内部ラベルをそのままユーザーに渡さないという方針です。
最終返信の要件は次のように書けます。
|
|
これはプロダクト内の Agent 体験にとって重要です。ユーザーはモデルのすべての作業痕跡を見る必要はありません。必要なのは結果、証拠、リスク、次の一手です。
移行時に最初に変えるべきこと
すでに Claude Agent やプロンプト体系がある場合、Fable 5 への移行では次の順序で確認できます。
- テストタスクをより難しく、長く、完整なものに変える；
- すべてのタスクを最高設定にするのではなく、
effortを再評価する； - タイムアウト、streaming、非同期タスクチェックを調整する；
- 長時間タスクにツール結果ベースの進捗監査を加える；
- モデルが実行してよい場合と判断だけを報告すべき場合を明確にする；
- 独立検証を fresh-context サブ Agent に任せる；
- 単純な記憶システムを追加し、タスク横断の教訓を保存する；
- 内部推論の復唱を求める古い指示を削除する；
- Fable 5 の拒否またはルーティング後の Opus 4.8 fallback を設定する；
- 最終要約スタイルを書き直し、ユーザーがすばやく結果を理解できるようにする。
Fable 5 のプロンプトエンジニアリングの重点は、より長いルールを書くことではありません。より強いモデルに合うワークフロー、つまり難しいタスク、明確な境界、実証的な検証、非同期なやり取りを設計することです。旧モデルでは安定させるために多くの細かな制約が必要だったことも、Fable 5 ではより短い原則で制御できる場合があります。一方で、長時間タスク、権限境界、安全フォールバックは、harness 層で事前に設計しておく必要があります。