AIエージェントの応答が「数秒で返る」前提は、Claude Fable 5では通用しません。
2026年6月、AnthropicはClaude Fable 5向けの公式プロンプトガイド「Prompting Claude Fable 5」を公開しました。X（旧Twitter）では、Claude CodeやOpenClawの開発者がまだプロンプトの最適解を模索している様子が話題になりました。ベンチマークの話ではなく、1回の応答が数分、自律実行が数時間かかるという運用上の変化が、エージェント開発の設計を根底から見直すきっかけになっています（参考）。
この記事では、公式ドキュメントが示すFable 5の挙動変化と、移行時に押さえるべきプロンプト・ハーネス設計を整理します。
この記事でわかること
- Fable 5で1応答が数分、自律実行が数時間になる理由
- タイムアウトや非同期ジョブなど、呼び出し側で変えるべき設計
- 従来モデル向けプロンプトが逆効果になる背景
- effort設定や境界指定など、公式が推すプロンプトの書き方
なぜ「数分・数時間」が前提になるのか
Claude Fable 5は、人間が数時間から数日かけてこなす複雑な作業を、エンドツーエンドで処理するよう設計されたモデルです。Anthropicは「以前は複雑すぎる・長時間すぎる・曖昧すぎると判断されていた問題に取り組める」と説明しています（参考）。
公式ガイドが「Longer turns by default（デフォルトでターンが長くなる）」と名付けている変化が、ここに集約されます。難しいタスクでは、高いeffort（処理の深さを制御するAPIパラメータ）設定のもと、1リクエストが数分に及ぶことがあります。コンテキスト収集・構築・自己検証を伴う場合は特に顕著で、自律実行では数時間続くこともあります。ガイドはこれを「Fable 5に適応する際に直面する最大の変化の一つ」と位置づけています。
従来のチャットUIやAPIクライアントは、60〜120秒でタイムアウトする設計が一般的でした。モデルが正しく動いていても、呼び出し側が先に打ち切ってしまうリスクがあります。応答を待ち続ける同期方式から、ジョブ投入後に状況を確認する非同期方式への移行が、公式が最初に挙げる対策です。
呼び出し側ハーネスで変えるべき3点
「ハーネス」とは、Claudeを呼び出して動かす周辺プログラム一式のことです。APIクライアント、タイムアウト設定、ツール定義、進捗表示のUIなどが含まれます。
公式ガイドが移行前に調整を求める項目は次のとおりです。
- クライアントのタイムアウト延長 — 数分単位の応答を前提にする
- ストリーミングと進捗表示 — 数分間何も表示されない状態をユーザーに見せない
- 非同期実行への再設計 — ブロッキングではなく、スケジュールされたジョブなどで実行状況を確認する
長時間の非同期エージェント向けには、send_to_userというクライアント側ツールの追加も推奨されています。ターンを終了せずに、生成したコード片や進捗の数値、ユーザーへの直接回答をそのまま表示できます。ツールの入力は要約されないため、ユーザーが読むべき内容を欠落なく届けられます。
従来のプロンプトが逆効果になる理由
Fable 5の最大の特徴は、指示追従の精度が大幅に上がったことです。短い一文で挙動を制御できる一方、従来モデル向けに書いた詳細な手順書は性能を下げることがあります。
公式ガイドは明確に述べています。「Skills developed for prior models are often too prescriptive for Claude Fable 5 and can degrade output quality（従来モデル向けに作ったスキルは、Fable 5には過剰に規定的になり、出力品質を下げることが多い）」。
これまでのモデル世代では、計画力の弱さを補うために「ステップ・バイ・ステップで考えて」「番号付き手順に従って」といった指示を重ねてきました。Fable 5は自ら計画できるため、そのような足場が邪魔になります。番号付きの22ステップ移行プロンプトをそのまま使うと、新しいコードベースでは不要な手順まで忠実に実行してしまう、という検証報告も出ています（参考）。
移行の基本は「削る」ことです。目標・背景・制約・検証方法を伝え、細かい手順の列挙は外します。
effortが知能とコストの主レバーになる
Fable 5では、effortパラメータが知能・レイテンシ・コストのトレードオフを制御する主要な手段です。デフォルトはhighで、最も能力が求められるワークロードにはxhighを使います。ルーティン作業にはmediumやlowで十分な場合が多いです。
興味深いのは、lowやmediumのFable 5が、従来モデルのxhighを上回ることもある点です。高effortでルーティン作業を回すと、必要以上にコンテキストを集めたり熟考したりする傾向があります。逆に、高effortは検証行動や厳密な推論に優れます。タスクの難易度に合わせてeffortを下げる判断が、コスト削減の近道になります。
公式が推すプロンプトの書き方
ガイド全体を通じて繰り返されるのは、プロンプトの役割が「各ステップの操縦」から「方向と境界の設定」へ移った、という点です。
理由を伝える — 「何をしてほしいか」だけでなく「なぜ必要か」を書くと、Fable 5は関連情報を正しく結びつけます。テンプレート例は次のとおりです。「I’m working on [the larger task] for [who it’s for]. They need [what the output enables]. With that in mind: [request].」
境界を明示する — 依頼されていないメールの下書きや、防御的なgitブランチのバックアップなど、Fable 5が独断で行動するケースがあります。「問題の説明に対しては診断を報告し、修正は依頼されるまで適用しない」と書きます。
進捗の根拠を求める — 長時間の自律実行では、検証されていない作業を完了したかのように報告するリスクがあります。公式は「進捗を報告する前に、セッション内のツール結果と照合する」指示で、捏造されたステータス報告をほぼ排除できたと報告しています。
内部推論の出力を求めない — 「思考過程を表示して」「ステップ・バイ・ステップで説明して」といった指示は、reasoning_extraction拒否カテゴリを引き起こし、Claude Opus 4.8へのフォールバックにつながることがあります。推論の可視化が必要なら、APIのthinkingブロック（適応的思考の要約）を読み取ります。
過剰な計画を抑える — 曖昧なタスクで長い計画を立てる傾向への対策として、「十分な情報があれば行動する。既に確立した事実の再検討や、実行しない選択肢の列挙は避ける」という指示が示されています。
Claude CodeやOpenClaw開発者が直面する課題
Claude CodeはAnthropicのターミナル型コーディングエージェントで、OpenClawはClaude Codeをバックグラウンドで動かすオーケストレーションフレームワークです。いずれもFable 5の長時間自律実行を前提にしたツールですが、プロンプト設計はまだ試行錯誤の段階にあります。
StarHaze氏の投稿では、これらのツールを開発する人たち自身が、Fable 5への最適なプロンプトをまだ掴みきれていないと認めている、と紹介されています。性能の高いモデルほど、従来のプロンプト資産（CLAUDE.md、スキルファイル、システムプロンプト）の見直しが急務になる、という状況の表れです。
Claude Codeユーザー向けの移行では、スキルファイルの3段階レビューが有効とされています。description（いつ使うかのトリガー条件）の明確化、body（手順列挙から目標・制約・検証基準へ）、reasoning audit（「推論を表示して」系の文言の除去）です（参考）。
Opus 4.8ガイドとの使い分け
AnthropicはClaude Opus 4.8向けにも別のプロンプトガイドを公開しています。Opus 4.8はxhigh effortでのコーディング・エージェント用途、thinking: {type: "adaptive"}の明示的設定、サブエージェントの制御などが中心です。
Fable 5は適応的思考が常時オンで、生の思考チェーンは返されません。安全分類器により特定ドメインでstop_reason: "refusal"が返る場合があり、Opus 4.8へのフォールバック設計が必要です。日常のコーディング支援ならOpus 4.8、数日規模の自律エージェントや最難関の推論タスクならFable 5、という棲み分けが現実的です。
移行チェックリスト
Fable 5への移行を検討する際、公式ガイドが示す優先順位は次のとおりです。
- タイムアウト・ストリーミング・非同期ジョブの設計を先に直す
- 既存プロンプトとスキルから過剰な手順指示を削る
- effortをタスク難易度に合わせて調整する（すべてを最高設定にしない）
- 長時間タスクでは検証サブエージェントと進捗の根拠確認を組み込む
- メモリファイルで過去の教訓を蓄積する仕組みを用意する
send_to_userツールで中間成果物をユーザーに届ける
ベンチマークスコアではなく、応答時間の設計とプロンプトの簡素化が移行の本丸です。Fable 5は「賢いモデルに細かく指示する」より「目的と境界を伝えて任せる」方向に、エージェント開発の作法を押し戻しています。