fable5-best-practice

fable5-best-practice

Claude Fable 5 は、高速なチャットモデルではなく、長期的な意思決定とオーケストレーションを担うモデルとして扱ってください。判断、分解、検証、または継続的なツール利用が重要で、プレミアムなコストとレイテンシーを正当化できる場合に使用します。

Fable に関する最新情報は変わりやすいものです。料金、提供状況、データ保持、フォールバック、またはプラットフォーム固有の API について案内する前に、Anthropic の公式ドキュメントを再確認してください。2026-07-09 時点の公式ドキュメントでは、Fable 5 は常時有効な適応型思考機能を備えた高い自律性のモデルとして説明されています。通常は high を初期設定の努力レベルとし、Opus／Sonnet よりも料金が高く、30 日間のデータ保持要件があるため、ゼロデータ保持の契約では利用できません。

基本ルール

受け入れ基準を確実に満たせる、最も安価なモデルを使用してください。

• 調査、機械的な実行、長いツールループ、決定論的な検証には Sonnet を使用します。
• センスが重視される制作、アーキテクチャ／API のレビュー、微妙な実装、シニアレベルの判断には Opus を使用します。
• 難しい推論、長期的な自律性、事前検討、相反する証拠の統合、最終的な裁定には Fable 5 を使用します。
• ハーネスで利用できる場合は、異なるモデルファミリーと強力なローカルツールを備えた、独立したシニアエンジニアリングの対等なレビュー担当として Codex を使用します。

より安価なモデルが特定の受け入れ基準を満たせなかった場合、またはリスクの高いタスクで弱いモデルによる試行がかえって割高になる場合にのみ、上位モデルに切り替えてください。Fable のトークンは、大量の情報収集ではなく判断に使ってください。

Fable を使うべき場面

次のいずれかに当てはまる場合は、Fable 5 を優先してください。

• 多くのステップ、ファイル、システム、関係者、または複数日にわたる作業を伴います。
• 進め方が曖昧で、方向づけ、アーキテクチャ、センス、トレードオフの判断、または事前検討が必要です。
• ユーザーが求めているのは小さな回答ではなく、戦略、設計、調査計画、移行計画、評価スイート、またはエージェントのループです。
• 検証が重要で、エージェントが成功を宣言する前に証拠を調べ、ツールを実行し、前提をテストし、自ら修正できます。
• 永続的なメモリや長期的に使える作業メモによって、成果が大きく向上します。

単純な質疑応答、書式設定、機械的な編集、単発の要約、定型的なリポジトリ検索、またはより安価なモデルが一度で完了できる作業には Fable 5 を使わないでください。

効果的な運用

細かな手順を逐一指示するより、目標を優先してください。

• 成果、成功基準、制約、対象者、承認ゲートを尋ねてください。
• なぜその成果が重要なのか、どのような意思決定やワークフローに役立つのかを尋ねてください。
• 進捗を測れるように、Fable にツール、ファイル、テスト、証拠ソースを与えてください。
• 進め方は提案させつつ、破壊的、高コスト、外部から見える、またはスコープを変更する操作にはチェックポイントを必須にしてください。

指示は簡潔にしてください。安全性、予算、データ、スタイル、スコープ、またはビジネス上の判断を守るルールは残してください。モデルに説明の繰り返し、過剰な計画や構造化、隠れた推論の開示を強いるだけの補助的な指示は取り除いてください。

行動するのに十分な情報があるなら、行動してください。すでに確定した事実を再導出したり、ユーザーがすでに下した決定を蒸し返したり、採用しない選択肢を調べたり、今すぐ実行できる作業を後で行うと約束して終えたりしないでください。

高い努力レベルでの実行は、対象範囲を絞ってください。証拠から必要性が示されない限り、タスクの範囲を超えて機能を追加したり、大規模なリファクタリング、予備のバックアップ、機能フラグ、互換性シム、抽象化、検証を追加したりしないでください。ユーザー入力や外部 API など、システム境界で検証し、適切な場合は内部フレームワークの保証を信頼してください。

ユーザーが変更を委任するのではなく、質問したり、問題を共有したり、考えを口にしたりしている場合は、評価を提示してそこで終えてください。

古いプロンプトを監査する

既存のプロンプト、スキル、ワークフローを Fable 5 に移行する前に：

• 弱いモデルを補うためだけの、段階的な足場かけを取り除きます。
• 安全性、予算、データ、スタイル、範囲、ビジネス上の制約を守るルールは維持します。
• 「推論を見せて」「考えを文字起こしして」などの指示を削除します。
• タイムアウト、ストリーミング、進捗インジケーター、非同期ジョブの処理を確認します。難しいターンは数分かかることがあり、自律実行は数時間から数日続く場合があります。
• 移行を本格導入する前に、実際のワークロードでコストとトークン使用量の基準を再設定します。

不明点に取り組む

プロンプトは地図です。コードベース、設計空間、ユーザー、制約、デプロイ対象領域は実地です。Fable の出力は、通常、モデルの生の能力ではなく、実行中にどれだけ不明点を明らかにできるかによってボトルネックが決まります。

不確実性を次の4つに分類します：

• 既知の既知：プロンプトに記載します。
• 既知の未知：質問、調査、またはプロトタイプ作成を行います。
• 未知の既知：「見ればわかる」好みを、ブレインストーミングや使い捨てのプロトタイプを通じて明らかにします。
• 未知の未知：見落としを洗い出すレビューを依頼します。

重大な影響がある作業や曖昧な作業では、references/phase-playbook.md を読み、タスクに合った手法だけを選びます：

• 着手前：見落としを洗い出すレビュー、ブレインストーミング／プロトタイプ作成、インタビュー、ソースコードの参照、変更可能な判断事項を先頭に置いた実装計画。
• 作業中：新しい実装セッションで、一時的な implementation-notes.md に逸脱ログを記録します。
• 完了後：マージ前に、提案／説明用の成果物またはクイズを作成します。

ユーザーが文章ではなく形を見て判断する必要があるブレインストーミング、プロトタイプ、計画、提案、クイズには、HTML の成果物を優先します。

簡潔にインタビューする

重大な影響がある作業では、利用可能な場合、計画を立てる前にハーネスのユーザー質問ツールを使います。自分で確認できる事実ではなく、意図、優先事項、制約、判断が必要な点を尋ねます。

効果の高い質問：

• 次のタスクだけでなく、目指す意欲的な最終状態は何ですか？
• 誰が成果物を使い、どのような意思決定やワークフローに役立てますか？
• 実際の制約は何ですか：期限、予算、技術スタック、ポリシー、データ、品質基準？
• どのような場合に Fable は一時停止すべきですか：破壊的な変更、購入、デプロイ、外部へのメッセージ、法務／セキュリティ／プライバシーに関する話題、または大幅な範囲変更？
• 多くの作業を行っても、実行が失敗だったと判断されるのはどのような場合ですか？
• このハーネスはサブエージェントを起動できますか？できる場合は、モデルのルーティングを明示的に設計してください。

質問ツールが選択肢に対応している場合は、推奨する既定の選択肢を最初に置き、(Recommended) と記します。質問ツールが利用できない場合は、平易な言葉で簡潔に質問し、リスクが低ければ妥当な前提を置いて続行します。

労力と予算を設定する

労力を意図的に使います：

• low：定型的な分類、抽出、確実で範囲が限定された作業、低コストな機械的チェック。
• medium：対話的な探索、迅速な設計フィードバック、簡単なデバッグ、または深い調査よりレイテンシーが重要な場合。
• high：本格的なコーディング、アーキテクチャ、計画、調査の統合、プロダクト戦略、複数ステップのツール使用に対する既定値。
• xhigh または利用可能な最高の労力：重大な意思決定、大規模な移行、複雑な根本原因分析、評価設計、徹底的な事前検討、最終的な裁定。

Fable 主導のコーディングワークフローでは、最大ではなく high を既定にします。判断のリスクが高い場合、または high で受け入れ基準を満たせない場合にのみ引き上げます。high でタスクを解決できても、使われない代替案まで調査する、求められていない改善を加える、またはユーザーが活用できる以上の詳細を出力する場合は、medium に下げます。

利用可能な場合は、時間、トークン、コスト、ツール呼び出し回数、変更するファイルの最大数、試行回数の上限、停止条件について、明示的な予算を設定します。範囲が狭いタスクでは、作業範囲を制御する指示を追加します。

労力とモデルの選択は独立しています。Sonnet-low によるマッピングと Opus-high による設計レビューは、同じグリッド上の異なる点です。

境界を定義する

長時間にわたる作業や機密性の高い作業には、許可する範囲と禁止する範囲を簡潔に定めます。

Boundary:
- Allowed: [files, tools, systems, actions]
- Forbidden: [external messages, deploys, branch changes, destructive commands,
  purchases, secrets, unrelated directories]

Pause only for destructive or irreversible actions, real scope changes, or information
only the user can provide. Otherwise continue and report when done.

エージェントが境界外に有用なアクションを見つけた場合は、それを提案して待機します。

ループを設計する

意欲的な作業では、次のようなループを構成します。

1. 目標、制約、承認ゲートを明確にします。
2. マイルストーン、リスク、依存関係、検証を含む計画を立てます。
3. 次に最も効果の高い範囲を実行します。
4. ツール、テスト、レビュー、またはソースシステムの証拠を使って検証します。
5. 学びを簡潔に記録し、計画を更新します。
6. 完了条件、予算、または停止条件に達するまで続けます。

すべてのループには、明確に定まる停止条件、最大試行回数、残る失敗または停止理由を含む報告形式が必要です。「より良くする」といった表現よりも、数値で示せる、または外部から確認できる完了条件を優先します。

重要な作業を実行コンテキストだけで評価させないでください。正確性、安全性、コスト、または外部への影響が重要な場合は、サブエージェント、より低コストのモデル、テストスイート、リンター、ベンチマーク、クエリ、スクリーンショットの確認、ステークホルダーのチェックリスト、人間による承認ゲートなど、独立した検証者を追加します。

/goal、/loop、/schedule、/sprint、カスタムコマンド、動的ワークフローは、ローカルハーネスで実際に利用できる場合にのみ使用します。これらはフェーズ制御の基本要素として扱い、受け入れ基準、予算、停止条件の代わりにしないでください。

進捗を証拠に基づかせる

長時間にわたる自律実行では、ステータスを証拠に結び付ける必要があります。ステータスの正確性が重要な場合は、次の指示を追加します。

Before reporting progress, audit each claim against a tool result from this session.
Only report work you can point to evidence for. If something is not verified, label it
unverified. If tests failed or a step was skipped, say so plainly.

「X を実行する予定です」と述べただけでは、進捗として数えないでください。エージェントがツールを実行すると述べ、そのアクションが許可されている場合は、ターンを終える前にツールを実行する必要があります。

アクションを実行せず、計画だけを示して早期に停止する可能性がある場合は、次を追加します。

Before ending your turn, check whether your last message is a plan, promise, question,
or list of next steps. If the original request allows the work and no user-only input
is required, do the work now with tools.

メモリを慎重に使用する

複数セッションにわたる作業では、state.md などの短い永続メモリを維持し、教訓をタスク間で引き継ぐ必要がある場合にのみ learnings/ を使用します。メモリは変更履歴ではなく、常に更新されるスナップショットとして保ちます。

推奨形式：

# Current State

One-sentence summary of the goal and current status.

## Decisions
- Durable decisions that should affect future work.

## Constraints
- Real constraints and approval gates.

## Learnings
- Things discovered through failed attempts, tests, user feedback, or measurement.

## Next
- The next highest-leverage action.

古い内容は日記のように追記せず、置き換えます。リポジトリやチャットにすでにある事実を重複して記載しないでください。ファイルを増やす前に重複したメモを更新し、後から得られた証拠によって誤りと判明したメモは削除します。

モデルを振り分け、コンテキストを制御する

サブエージェントを起動できるワークフロー、サブエージェントのツリー、モデル割り当てポリシー、またはエージェント向けプロンプトを扱う場合は、references/claude-model-routing.md を読みます。このリファレンスには、詳細な振り分け表、コスト規則、キャッシュ／セッションのコスト効率、トークン管理のチェックリスト、Codex の準備完了ゲート、引き継ぎ用プロンプトが記載されています。

次の運用パターンをメインプロンプトに含めます。

• Fable には、問題の整理、作業の分割、コンテキストの簡潔な維持、最終的な判断を任せます。
• 受け入れ基準が明確な場合、生の情報収集、ファイルの読み取り、ログのトリアージ、ブラウザー／コンピューター操作の基盤づくり、スクリプト化された運用、機械的な実装は Sonnet に委任します。
• アーキテクチャ、細かなコード品質、センスが重視される UI／文章／API 作業、設計レビューには Opus を使います。
• 現在のハーネスで Codex が利用でき、セットアップによって準備完了が確認されている場合にのみ、独立したピアとして Codex を使います。
• 作業者には、目標、制約、担当パス、不変条件、受け入れ基準、検証コマンド、承認ゲートを含む簡潔な設計パケットを渡します。
• 作業者の出力は簡潔にするよう求めます。結論、証拠、変更したファイル、検証結果、阻害要因、エスカレーションが必要な判断事項を含めます。

大量の作業を Fable のフォークに委任してはいけません。フォークは高コストのコンテキストを引き継ぐため、想定していた低コストの作業者がオーケストレーターと同じ料金になります。代わりに、コンテキストを新たにした Sonnet／Opus の作業者を起動します。

長時間にわたって稼働する作業者には、次を追加します。

Never end your turn while work remains. Wait by blocking (sleep/poll loops inside a
tool call with a generous timeout), not by stopping to await notifications.

拒否への対処

Fable の拒否やフォールバックは、クラッシュではなくプロダクトの動作として扱ってください。

• stop_reason: "refusal" は、ルーティングが必要な正常な応答として扱ってください。
• 利用可能な場合は、サーバー側、クライアント側、または手動のフォールバックを設定してください。
• 適切な場合は、安全な防御、教育、またはコンプライアンスに関する作業に向けて、依頼を言い換えてください。
• セーフガードを回避しようとしないでください。
• 隠された推論を再現、書き起こし、または開示するよう Fable に指示しないでください。

結果を伝える

Fable は長時間の実行後に説明が冗長になることがあります。最終回答では、まず結果、つまり何が起きたか、何が見つかったか、何が変わったかを伝えてください。読み手が次に何を信頼し、何をすべきかに影響する詳細だけを加えてください。

ツール呼び出しを見ていないユーザーに向けて書いてください。判断に役立つ場合を除き、密度の高い略記、説明のないラベル、矢印でつないだ手順、隠された推論への言及、独自に作り出した分類は避けてください。

破壊的または取り消せない操作、実際のスコープ変更、外部への確約、またはユーザーにしか提供できない情報が必要な場合に限り、ユーザーの対応を待ってください。

ハーネスがモデルに残りのコンテキスト予算を示す場合、その数値をタスクの枠組みに含めないでください。表示する必要がある場合は、コンテキストの制限だけを理由に停止、要約、または引き継ぎをしないよう明示してください。

プロンプトのパターン

重要なタスクでは、references/prompt-patterns.md を使用してください。Fable へのプロンプトに、コンテキスト、依頼、出力形式、制約、現在の状態、成功基準、委任とモデルの組み合わせ、承認ゲート、そしてモデルにインタビュー、見落としの確認、計画、事前検証、実行、検証を求める「your job」で締めくくる項目をまとめています。

ユーザーに助言する際は、どのモードを使うかを明確にしてください。

• 長期にわたる自律性が役立つタスクには、「これは Fable に適しています」と伝えてください。
• 主に実行作業である場合は、「意思決定の部分だけに Fable を使用してください」と伝えてください。
• 小規模または反復的な作業には、「より低コストのモデルを使用してください」と伝えてください。
• 正確性、安全性、または外部への影響が重要な場合は、「検証役を追加してください」と伝えてください。
• 実行が際限なく広がる可能性がある場合は、「予算と停止条件を設定してください」と伝えてください。