「完了しました」を信じられないなら。Claude Fable 5のプロンプトは削って直す
Claude Fable 5を長時間動くAIエージェントとして使うための実践ガイド。effort、進捗の証拠、権限境界、サブエージェント、メモリ、API移行の要点を解説します。
数時間かけて動いたAIエージェントから、「完了しました」と報告が届く。
ところが成果物を開くと、変更したはずの箇所が変わっていない。テストの結果も見当たりません。
この問題を防ぐために「最後まで実行する」「必ずテストする」と書き足しても、実行した証拠までは作れません。むしろ、失敗へ対処するたびにルールを増やすと、同じ意味の指示や矛盾する指示が残ります。
AIを安全に動かすためのプロンプトが、かえってモデルを迷わせていました。
Anthropicが公開したClaude Fable 5向けのプロンプティングガイドは、旧モデル向けに積み上げた指示を見直し、不要なものを削るよう勧めています。
もちろん、短いプロンプトへ書き換えるだけでは解決しません。
目的と完了条件を決める。AIが触ってよい範囲を決める。進捗報告を実際のツール結果へ結びつける。長く続く仕事なら、サブエージェントやメモリも用意する。
Fable 5では、上手な頼み方より、AIへ仕事を渡す仕組みの方が重要になります。
最近のぼくの使い方だと、Fable 5は、リポジトリ全体の設計の壁打ちをしてから方針を決め、方針決定後、Fableを全体監督の立場に専念させて、実装処理はSonnet 5やOpusをサブエージェントとして呼び出すことで、Fableだけに処理をさせないようにします。こうすると、トークン節約と複数サブエージェントに処理を委任させることでうまくいっています。
もう少しFable 5の特長を見ていきましょう。
※本記事は2026年7月19日時点のAnthropic公式情報をもとにしています。
短いデモだけでは、Fable 5の強みが見えない
新しいモデルが出ると、まず短い要約や数十行のコード生成を試したくなります。僕も最初はそうします。前のモデルとの違いを早く確かめられるからです。
Fable 5は、そうした短い仕事でも高い性能を発揮します。ただ、Anthropicが強調しているのは、人間なら数時間から数週間かかる仕事を、調査から実装、検証まで通して進める能力です。
例えば、次のような仕事です。
- 既存のコードベースを調べ、移行計画を作り、実装してテストまで通す
- 複数の資料を横断して調査し、分析結果を文書やスライドにまとめる
- デザインやスクリーンショットを読み取り、UIを実装して差分を確かめる
- リポジトリの履歴まで調べ、不具合の原因を特定して再発防止策を入れる
Fable 5では、長期の自律実行、複雑な課題の初回正答率、画像理解、コードレビュー、曖昧な依頼への対応、サブエージェントの運用が強化されています。
「この仕事を完了状態まで持っていく」と渡したときに強みが出ます。僕なら、以前のモデルには任せられないと諦めたほど難しい仕事から試します。
旧モデル向けの長いプロンプトは、一度削ってみる
Fable 5は指示への追従性が上がり、短い一文でも振る舞いを変えやすくなっています。
Fable 5へ旧モデル向けの長いプロンプトをそのまま持ち込むと、同じ命令を言い換えて繰り返したり、起こりそうにない例外への対応を残したりして、判断の幅を狭めることがあります。
移行時に必要なのは、指示の追加より棚卸しです。
例えば、次の4行だけでも行動の軸を作れます。
十分な情報がそろったら、実行に移る。
すでに決まったことを再検討しない。
採用しない選択肢を長く列挙しない。
結果を先に報告し、必要な根拠をあとに続ける。
コーディングでも同じです。effortを高くすると、依頼していない周辺整理やリファクタリングまで始める場合があります。
その場合は「依頼に必要な最小範囲だけを変更する」「将来使うかもしれない機能のために抽象化しない」と、境界を短く示します。
強いモデルほど、手順を一歩ずつマイクロマネジメントする必要は減ります。一方で、目的、完了条件、触ってよい範囲は曖昧にできません。
仕事の仕様を残し、重複した制御を削ります。
effortは品質ボタンではなく、仕事ごとに変える
APIで指定するeffortは、知能、待ち時間、コストのバランスを決めます。
Anthropicは、多くの仕事でhighを基本にし、能力差が成果へ直結する仕事ではxhigh、定型作業ではmediumやlowも検討する方針を示しています。
ただし、常に高ければよいわけではありません。
effortを高くすると検証は丁寧になります。その反面、簡単な仕事でも文脈を集めすぎ、頼んでいない改善まで始めることがあります。
| タスク | effortの目安 | 選ぶ理由 |
|---|---|---|
| 定型的な変換、分類、抽出 | low〜medium | 速度とコストを優先しやすい |
| 通常の実装、デバッグ、コードレビュー | high | 判断と検証のバランスを取りやすい |
| 大規模移行、複雑な設計、長時間の自律実行 | xhigh | 能力差が成果物の品質へ直結しやすい |
| 会話しながら素早く詰める仕事 | medium | 応答性を保ちやすい |
これは固定ルールではありません。
タスクは完了しているのに遅すぎるなら下げる。品質不足や検証漏れが出るなら上げる。モデル名だけで一律に決めず、実際の完了率、所要時間、コストで調整します。
「進んでいます」ではなく、証拠を報告させる
長時間動くAIエージェントで怖いのは、派手な失敗だけではありません。
「修正しました」「テスト済みです」という報告と、実際の状態がずれることです。
進捗を伝える前に、そのセッションで得たツール結果と照合させます。テストが失敗したなら、失敗と報告する。確認していないなら、未確認と明記する。工程を飛ばした場合も、その事実を隠しません。
Anthropicは、この照合を指示したテストで、長時間実行中の根拠のないステータス報告がほぼなくなったと説明しています。
進捗を報告する前に、今回の実行で得たツール結果と照合する。
未実行、未確認、失敗、スキップは、そのまま報告する。
完了と書けるのは、成果物と検証結果の両方がある場合だけとする。
完了条件も「コードを書いた」では足りず、しっかりと僕たちが望む条件を定義して渡してあげます。
- 変更された成果物が存在する
- テストや表示確認などの検証結果がある
- 仕様と成果物の差分を確認している
よくあるテスト完了報告での問題は、テストコードが古い実装はパスするようになっているが、新規実装内容のテストには対応していないため、古い実装はパスしたから「テスト完了です」と報告してくることがあります。これでは困ってしまうため、サブエージェントに実装・テストを依頼しているならば、その結果をFable側に報告させて、全体責任者としてチェックする体制を整えることで回避できる可能性が上がります。
この偽テスト通過報告は本当に困る問題なので、入念に人間もチェックしたいところです。
AIエージェントの品質は、成果物と証拠が一致しているかで判断します。実行時間が長くなり、エージェントへ与える権限が増えるほど、このルールは重要になります。
止まる条件は3つに絞る
自律型エージェントが小さな判断のたびに「続けてもいいですか」と聞いてくると、長時間実行の意味がありません。
かといって、何でも勝手に進める設計も危険です。
実務では、作業を止めてユーザーへ確認する場面を、次の3つに絞ると扱いやすくなります。
- 破壊的、または元に戻せない操作を行うとき
- 当初の依頼から実質的に外れる変更が必要なとき
- ユーザーにしか提供できない情報が必要なとき
それ以外の可逆な操作は、元の依頼の範囲内で進めます。
公式ガイドでも同じ考え方が示されています。長いセッションでは、実行できる作業があるのに「これから実行します」と書いただけで終了する場合があります。そのため、「計画で終わらず、可能な作業は実行する」という指示も有効です。
「自律的に動け」という性格の指定だけでは足りません。どの操作まで任せてよいかを決めます。
相談と変更依頼では、成果物を分ける
Fable 5は能動的です。
そこが強みですが、質問に答えるだけの場面でファイルを編集したり、頼んでいないメールの下書きを作ったり、念のためにGitブランチを増やしたりする場合があります。
そこで、依頼の種類ごとに成果物を分けます。
| 依頼 | 成果物 |
|---|---|
| 質問、相談、アイデアの検討 | 評価や提案を報告して止まる |
| 修正、実装、作成 | 依頼された範囲の変更を行う |
| 再起動、削除、設定変更 | 根拠と必要性を確かめ、必要なら確認する |
この区別は地味ですが、業務用エージェントでは欠かせません。
性能が上がるほど、「できること」と「やってよいこと」の差が広がります。回答できるかどうかとは別に、外部の状態を変える権限を設計する必要があります。
サブエージェントは役職ではなく、依存関係で分ける
Fable 5は、独立した作業を複数のサブエージェントへ渡し、並行して進める能力が強化されています。
ただし、エージェントの数を増やせば速くなるわけではありません。
分割の基準は、作業同士が独立しているかを基準にします。前の作業結果がなければ始められない仕事を無理に並列化すると、待ち時間や手戻りが増えます。
大規模な機能実装なら、例えば次のように分けられます。
- メインエージェントは、全体設計と実装を統合する
- 調査エージェントは、既存コードと関連APIを確認する
- テストエージェントは、受け入れ条件とテストケースを作る
- 検証エージェントは、完成物を仕様と照合する
特に分けたいのが検証です。
長いあいだ同じ文脈で作業したエージェントは、自分が置いた前提を疑いにくくなります。別のコンテキストで動く検証担当へ仕様と成果物だけを渡すと、実装担当が見落とした差分を拾いやすくなります。
サブエージェントは、役職名を並べる機能ではありません。独立した仕事を同時に進め、検証の視点を切り離すために使います。
チャット履歴をためず、更新できるメモリを作る
長時間のエージェント運用では、会話履歴が残っているだけでは不十分です。
必要なのは、次の仕事でも使えるように整理され、間違いがあれば直せるメモリです。
Anthropicは、一つの学びを一つのファイルへ保存し、先頭に1行の要約を置く方法を例示しています。
memory/
auth-refresh-token.md
deploy-preview-check.md
cms-slug-rule.md
ファイルの中身は、次のように絞れます。
# 1行の要約
- どの状況で起きたか
- 確認できた方法
- なぜ有効だったか
- 採用しなかった方法
- 根拠となるログ、テスト、仕様
成功した方法だけでなく、あとから誤りと分かった理解も残します。なぜ訂正が必要だったのかも記録します。既存の記録と重複するなら新しく作らず、間違いと分かったメモは更新するか削除します。
メモリは量よりも、正確さと更新しやすさが大切です。
チャットログを倉庫にせず、運用知識を編集できる資産へ変えます。
最終報告も、エージェントのUIとして設計する
長い仕事が終わったあと、ユーザーが途中のツール呼び出しをすべて見ているとは限りません。
それなのに、エージェントが作業中の略語や内部用ラベルをそのまま使うと、最終報告だけ読んでも何が起きたのか分かりません。
最終メッセージは、ユーザーが初めて結果を見る画面として書きます。
順番は次の4つで足ります。
- 何が完了したか、または何が分かったか
- 重要な変更点と検証結果
- 未完了、失敗、判断が必要な点
- ユーザーの操作が必要な場合だけ、その内容
モデルが長く働けても、待っている人が状態を理解できなければ業務にはなりません。進捗と完了報告も、AIエージェントを構成する機能の一つです。
内部の思考ではなく、成果物と根拠を見せる
Fable 5へ「考えた手順をすべて説明して」「内部の推論を逐語的に出して」と指示するのは避けた方がよいでしょう。
思考内容の抽出を求める指示は、reasoning_extractionとして拒否やフォールバックの対象になる場合があります。公式ガイドも、既存のプロンプトやスキルに含まれる「思考をすべて説明する」といった指示を削除するよう勧めています。
実務上の監査に必要なのは、内部の思考を読むことではありません。
- どの成果物を作ったか
- どのツール結果を根拠にしたか
- 何を検証したか
- どこが未確認か
- 次に人間が判断すべきことは何か
この5点が見えれば、作業が正しく進んだかを確認できます。
API移行では、プロンプト以外も確認する
Fable 5への移行は、モデル名を書き換えるだけでは終わりません。
Fable 5では、モデルが思考量を調整するadaptive thinkingが前提です。従来のようにextended thinkingの予算を固定する方式とは設定が異なります。
APIで推論の状態を扱う場合は、推論結果を構造化して返すthinkingブロックを使います。ユーザー向けの画面には、内部の推論を出さず、進捗と根拠を表示します。
また、サイバーセキュリティや生物・生命科学の一部の依頼、思考抽出に関する指示は、安全分類器に止められる場合があります。アプリケーション側にはrefusalの停止理由と、Claude Opus 4.8へフォールバックした後の処理が必要です。
2026年7月19日時点では、安全監視のため、Fable 5の利用に30日間のデータ保持が必要と案内されています。機密情報を扱う業務へ導入する場合は、性能だけで判断できません。データ保持、契約、アクセス権限、ログの扱いまで確認します。
長時間実行に合わせて、クライアント側のタイムアウト、ストリーミング、進捗表示、非同期で状態を確認する仕組みも調整します。途中で必ず届けたい成果物があるなら、実行を続けたままメッセージだけを送れるsend-to-userのようなツールも使えます。
拒否への対応、フォールバック、データ保持は、プロンプトの工夫だけでは解決できません。
業務へ組み込むなら、モデル設定とガバナンスを同時に設計します。
そのまま使える、Fable 5向けの最小システムプロンプト
ここまでの内容を、実務用のたたき台として整理します。
あなたは、長時間の実務を完了状態まで進める自律エージェントです。
# 仕事の進め方
- 目的、対象範囲、完了条件を確認し、十分な情報があれば実行に移る。
- すでに決まった事項を再検討しない。採用しない案を長く列挙しない。
- タスクに不要な機能追加、一般化、周辺リファクタリングを行わない。
- 独立した作業はサブエージェントへ委任し、自分の作業も並行して進める。
- 重要な節目では、仕様と成果物を新しいコンテキストの検証担当に照合させる。
# 権限と停止条件
- 依頼が評価、質問、相談である場合は、分析結果を報告して停止し、変更を実行しない。
- 破壊的または不可逆な操作、実質的なスコープ変更、ユーザーしか提供できない情報が必要な場合だけ停止して確認する。
- それ以外の可逆な操作は、元の依頼の範囲内で進める。
# 進捗と完了
- 進捗を報告する前に、今回のツール結果と照合する。
- 未実行、未確認、失敗、スキップはそのまま報告する。
- 完了と報告するのは、成果物と検証結果がそろった場合だけとする。
- 最終報告は結果から始め、重要な根拠、検証結果、残課題の順に書く。
- 内部の思考過程はユーザー向けの本文へ出力しない。
このプロンプトも完成形ではありません。
実際の業務に合わせて、権限、完了条件、使えるツール、検証方法を足します。反対に、効果を確かめられない指示は削ります。
Fable 5向けの良いプロンプトは、旧モデル向けの半分ほどの長さになるかもしれません。
導入前は、プロンプトより運用条件を確認する
- 簡単なデモではなく、実際に困っている難しい仕事で評価したか
- 成果物と完了条件を言葉にしたか
- effortを難しさと待ち時間に合わせて選んだか
- 相談と変更依頼を分けたか
- 触ってよい範囲と停止条件を決めたか
- 進捗報告をツール結果やテストへ結びつけたか
- 独立作業と検証をサブエージェントへ分けたか
- 次回も使える、更新可能なメモリを用意したか
- 長時間実行に合わせてタイムアウトと進捗表示を調整したか
- refusal、フォールバック、データ保持を確認したか
すべてを一度に作る必要はありません。
まずは、今使っている長いプロンプトから、重複した指示を一つ削る。次に、完了条件をツール結果で確かめられる形へ変える。そこから始められます。
モデルを管理するのは「思考」より「仕事」になる
Fable 5で変わるのは、回答の賢さだけではなく、AIへ渡せる仕事の大きさ・質が変わります。
目的、完了条件、権限のボーダーライン、検証の証拠、更新できるメモリ、読み手へ届く進捗報告を先に設計します。
強いモデルを細かくマイクロマネジメントせずに、ただし、放置もしない。内部の思考を追いかけず、成果物と証拠を見る。
Fable 5のベストプラクティスは、プロンプトの技巧から、仕事の設計へ移ることです。
僕も次にAIが止まったときは、注意書きをすぐには足しません。まず、何をもって完了とするか、どの証拠が足りないのかを確認します。
それではまた！