はじめに
私はFable 5の性能を語りたい。そして、その前に自分のSkillを疑いたい。 以前のモデル向けに書いた指示は、新しいモデルでも動きます。 しかし、動くことは、能力を引き出すことを意味しません。
Prompting Claude Fable 5という題名から想像するのは、Fable 5に効く指示文の一覧です。ところが本文には、タイムアウト、ストリーミング、メモリ、サブエージェント、フォールバック、send_to_userまで並びます。プロンプトの話を読みに来たはずが、途中からクライアント、実行基盤、UI、権限管理の話を読んでいる。題名はプロンプトですが、読み終わるころには実装チケットが増えています。少し話が違う。そこが本題です。
この文書は、うまい言い回しによってモデルの能力を引き出すためのプロンプト集ではありません。長時間動き、ツールを使い、他のエージェントへ仕事を委譲するモデルを、どこまで自律的に動かすかを設計する移行ガイドです。読まずに「すごい」「期待ほどではない」と評すれば、モデルの能力と、古い足場との相性を取り違えかねません。ただし、Skillを新しくすれば性能が出ると決まったわけでもない。だから、指示と実行基盤を見直し、同じ仕事で測り直す必要があります。
話はFable 5より前から始まっていた
2025年9月、AnthropicはEffective context engineering for AI agentsを公開しました。そこでは、プロンプトエンジニアリングを、モデルに渡す指示を書く技術として位置づけています。その上で、複数ターンにわたって動くエージェントでは、システムプロンプトだけでなく、ツール、MCP、外部データ、会話履歴を含む文脈全体を管理する必要があると述べています。Anthropic自身が、コンテキストエンジニアリングをプロンプトエンジニアリングの自然な発展として扱っていました。
同年11月のEffective harnesses for long-running agentsでは、さらに実装へ踏み込みます。長時間実行では、会話圧縮（compaction）だけでは不十分です。最初に環境を整える初期化エージェントと、差分を少しずつ進める実装エージェントを分けています。
作業状態はclaude-progress.txtやGit履歴へ残します。次のセッションは推測せずに再開できます。ここで扱われているのは、長いプロンプトではなく、引き継ぎ可能な作業環境です。人間同士でも難しい「察して再開する」を、セッションの切れたモデルに期待するのは酷でした。
2026年1月のDemystifying evals for AI agentsでは、評価対象も変わります。Anthropicが評価するのはモデル単体ではありません。指示、ツール、実行環境、オーケストレーションを含むハーネスとモデルの組み合わせです。チャットの応答だけを採点するのではありません。複数ターンの実行後に、環境が本当に期待した状態になったかを確認します。
この流れの先に、2026年6月のFable 5があります。Anthropicによれば、Fable 5は従来のClaudeより長く自律的に動き、複雑で曖昧な仕事や複数エージェントの調整で能力を発揮します。ただし、これはAnthropicと初期利用者による評価です。自分たちの仕事でも同じ結果になるかは、自分たちのハーネスと評価で確かめる必要があります。
プロンプトは能力を引き出す呪文から、行動の契約へ変わった
Fable 5向けガイドに載っている指示を分類すると、推論手順を細かく教えるものは多くありません。十分な情報があれば行動する。依頼されていないリファクタリングをしない。破壊的な操作や本当のスコープ変更でだけ停止する。進捗を報告する前に、実際のツール結果と照合する。どれも、モデルを賢くする指示というより、権限、停止条件、報告責任を定める指示です。
Fable 5は指示追従が強く、振る舞いごとに例外を列挙しなくても、短い指示で制御できるとされています。だからといって、情報を何も渡さなくてよいわけではありません。ガイドは同時に、依頼の理由や大きな目的を伝えるよう勧めています。省くべきなのは、モデルの癖を1つずつ矯正するマイクロマネジメントであり、目的、制約、完了条件ではありません。マイクロマネジメントに付き合うのは、人間だけでも十分に大変です。
私自身、モデルの変更に合わせて、Skill（必要なときに読み込む手順書）やサブエージェントへの任せ方をかなり修正してきました。以前のモデルには必要だった細かな指示が、新しいモデルでは過剰になることがあります。その過程で、モデルが変われば、必要な指示の粒度と委譲時の境界も変わると感じました。
私は、プロンプトを考えるときも、ジョブ理論の見方を使うことが多いです。ここでいうジョブは、モデルへ渡す処理項目ではありません。ある状況に置かれた人が、前へ進むために片づけたいことです。製品やサービスの機能だけでなく、利用者が求める進歩と、その選択を生む機能面、感情面、社会面を捉えます。
この見方をエージェントへ持ち込むと、プロンプトは「何を出力するか」だけを指定する文書ではなくなります。まず、ユーザーがどんな状況にいて、何を前へ進めたいのかを捉えます。次に、その進歩のどこまでをモデルへ任せ、何をもって進んだと判断し、途中の不安をどう減らすかを決めます。出力形式やツールの指定は、その後に選ぶ手段です。
ただし、目的、権限、証拠、伝達という4分類は、ジョブ理論にある公式な分類ではありません。ジョブ理論の「状況と進歩」を、長時間動くエージェントの設計へ私なりに引き寄せた整理です。その前提で、私はFable 5向けのプロンプトを次の4つに分けて考えます。
- 目的: 誰がどんな状況にあり、何を前へ進めたいのか
- 権限: その進歩のために、どこまでモデルへ判断を任せるのか
- 証拠: 成果物の生成ではなく、進歩したと何で確認するのか
- 伝達: 実行中の不安を減らし、状況を共有するために何を届けるのか
この4つが定まれば、実装方法の探索をモデルに任せやすくなります。反対に、ここが曖昧なまま「最後まで自律的に実行して」とだけ書けば、速く動いても、どこへ向かっているかを評価できません。自律性とは、人間が何も決めないことではありません。人間が先に境界を決め、その内側の選択を任せることです。
Skillは、正しい手順を1つに固定する文書ではありません。望む結果と越えてはいけない線を共有し、その間の判断を任せる契約です。ユーザーが欲しいのは、定義された工程を最後まで眺めることではありません。ある状況から、望む状態へ前に進むことです。フェーズ完走記念バッジを求めているわけではありません。
「自由にやってよい。ただし失敗するな」は自律性ではなく、かなり雑な呪いです。十分な情報があり、操作が戻せて、依頼の範囲内なら進む。破壊的な操作、外部への公開、実質的な範囲変更、利用者にしか決められない選択では止まる。境界が明確なのに毎回承認を求めれば、モデルは賢い信号機になります。赤と青を判断できますが、ずっと黄色です。
長時間実行を支えるのは、長い会話ではない
Fable 5は、高いeffortでは1つのターンが何分も続き、自律実行は何時間にも及ぶ場合があります。そのため公式ガイドは、クライアントのタイムアウト、ストリーミング、進捗表示、非同期ジョブへの変更を求めています。これはプロンプトで解決できません。モデルが長く働けても、HTTPクライアントが先に切れれば、その能力は利用者へ届かないからです。どれほど賢いモデルでも、504 Gateway Timeoutとは議論できません。
長時間実行では、メモリも必要になります。ただし、会話をすべて保存すればよいわけではありません。Fable 5向けガイドは、確認できた手順と訂正を教訓として残し、重複は作らず、間違いが分かった記録は削除するよう勧めています。メモリはログの倉庫ではなく、次の判断へ持ち越す情報を選ぶ場所です。
会話を縮めても、途中の実装、失敗した方法、次にやることが正しく引き継がれるとは限りません。そこで、進捗ファイル、テスト結果、Git履歴、仕様書という外部の成果物へ状態を移します。長く働くモデルに必要なのは、長い記憶より、次のセッションが検証できる引き継ぎです。
「完了しました」を証拠なしで信じない
Fable 5向けガイドには、長時間実行中の進捗報告を、同じセッションのツール結果で監査させる指示があります。Anthropicのテストでは、この指示によって、実際には終わっていない作業の進捗報告が大きく減ったとされています。重要なのは、モデルが自信を持って報告したかではありません。テスト、コマンド出力、生成されたファイルなど、報告に対応する証拠があるかです。
俺より優秀なやつがサボることを俺は絶対に許さない。
かなり乱暴な言い方ですが、モデルに対する私の態度はだいたいこれです。AIに労働倫理を説きたいわけではありません。テストを実行できるのに「たぶん大丈夫です」で帰ろうとするなら、能力が足りないのではなく、仕事の完了条件が抜けています。優秀さに期待するからこそ、「信じてください」ではなく、差分とテスト結果を置いて帰ってもらいます。
現在のClaude Code公式ベストプラクティスも、テスト、ビルド、lint、スクリーンショット比較など、モデル自身が実行できる確認方法を先に渡すよう勧めています。実装したモデルとは別の検証用サブエージェントに、新しい文脈で結果を検証させる方法も紹介されています。Fable 5向けガイドが、自己批評より新しいコンテキストを持つ検証役を勧めるのも同じ理由です。作業者の確信と、成果物の検証を分離しています。
エージェント評価の記事には、フライト予約エージェントが「予約しました」と答えても、データベースに予約が存在しなければ成功ではないという例があります。実行記録に書かれた完了報告と、環境に残った最終状態は別です。Fable 5のプロンプトを改善するなら、形容詞を増やす前に、完了条件を観測できる状態として定義した方がよい。正確に、慎重に、最後までと重ねても、成否を判定する基準の代わりにはなりません。
完了報告を直すのに必要なのは、モデルへの反省文ではなく、証拠との対応です。何が成功し、何が失敗し、何を実行せず、何が入力待ちなのかを分ける。反省文を長くしても品質は上がりません。反省文にlintをかけても、やはり上がりません。
サブエージェントへ任せることと、曖昧に投げることは違う
Fable 5は、以前のモデルより積極的にサブエージェントへ仕事を委譲します。公式ガイドは、独立した仕事を並列に任せ、親エージェントは待機せずに作業を続け、必要なら途中で軌道修正するよう勧めています。長く文脈を保持するサブエージェントを再利用すれば、キャッシュと引き継ぎの面でも有利です。一方、検証には新しい文脈を持つサブエージェントが向いています。
矛盾しません。実行担当には、過去の判断と作業状態を持ち越す価値があります。検証担当には、実装時の思い込みを持ち越さない価値があります。サブエージェントを使うかどうかではなく、文脈を共有すべき仕事と、分離すべき仕事を見分ける必要があります。同じ依頼を十人へ渡して同じ答えを集めても、並列化でなく合唱です。
AnthropicがResearch機能のマルチエージェントシステムを作った際も、サブエージェントへ渡す仕事には目的、出力形式、利用する情報源、境界が必要だったと報告しています。単に「半導体不足を調べて」と渡すと、探索範囲が重複したり、異なる時期を調べたりしました。そこで採用されたのは、すべての経路を固定する規則ではなく、分解、情報源の評価、探索の絞り込みといった経験則です。Fable 5で短くできるのはオーケストレーターへの一般指示であって、委譲する仕事の定義まで曖昧にしてよいわけではありません。短い指示で委譲できるようになったなら、次に疑うべきは、以前のモデルのために積み上げた指示です。
古いSkillは、追加する前に分類する
Fable 5向けガイドで最も痛い指摘は、以前のモデル向けに作ったプロンプトやSkillが細かすぎて、かえって品質を落とす可能性があるという部分です。新しいモデルが出るたびに、振る舞いを補正する指示を末尾へ足してきた環境ほど、この問題を抱えます。指示同士が矛盾していなくても、昔の失敗対策が今回の依頼より前へ出て、重要な指示が埋もれます。
古いSkillを使ったまま期待した結果が出なかったとしても、それだけでFable 5の能力が低いとは言えません。そこで測っているのは、モデル単体ではなく、モデルとSkillとハーネスの組み合わせだからです。反対に、古い指示を削っただけで性能が上がるとも限りません。必要な制約まで失えば、成功率は下がります。惰性で残すことも、ガイドを読んで一律に削ることも、評価の代わりにはなりません。
ここで分けるべきなのは、指示の長さではなく寿命です。安全、権限、事実、利用者への損失に関わる制約は、モデルが賢くなっても残ります。一方、質問が多い、途中で止まる、説明が長いといった振る舞いを補正する指示には寿命があります。振る舞いが変わっても残し続ければ、補助は制約に変わります。
安全境界には寿命がありません。振る舞いの補正には寿命があります。
この指摘は他人事ではありません。このブログの作業環境にも、長いAGENTS.mdと複数のSKILL.mdがあります。設定ファイルは失敗対策の地層です。掘ると、当時の私が何に腹を立てていたかまで分かります。著者の事実を捏造しない。記事を勝手に修正しない。こうした境界は、モデルが賢くなっても残す必要があります。一方、以前のモデルの癖だけを補正する指示は、モデルごとに再評価できます。
私は既存の指示を、次の基準で監査します。
| 指示の種類 | 扱い |
|---|---|
| 安全、権限、事実に関する不変条件 | 常に読める短いRuleとして残す |
| リポジトリ固有の知識、コマンド、判断基準 | 必要な仕事で読むSkillへ置く |
| 独立して完了できる調査や検証 | 必要なときだけAgentへ任せる |
| 必ず実行すべき機械的な処理 | 自然言語ではなくフックやテストへ移す |
| 特定モデルの癖を補正する指示 | 同じ仕事で評価してから削るか分ける |
Claude Codeの公式ドキュメントにも、CLAUDE.mdの各行について、削除すると本当に失敗が増えるかを問い、そうでなければ削るという基準があります。常に適用する情報だけを短く残し、限定的な知識はSkillとして必要なときに読み込みます。CLAUDE.mdの指示は助言ですが、フックは決められた処理を必ず実行するという違いも明示されています。Fable 5への移行は、指示を増やす作業ではなく、指示を適切な層へ戻す作業です。
プロンプトの1行も、評価せずに変えない
2026年4月、AnthropicはClaude Codeの品質低下に関する報告を公開しました。原因の1つは、応答を簡潔にするため追加したシステムプロンプトの指示です。他の変更と組み合わさり、コーディング品質を下げていました。別の原因では、推論量の既定値をhighからmediumへ下げたことが、知能低下を感じさせる一因になりました。いずれもモデル自体の変更ではなく、モデルを囲む設定の変更でした。
Anthropicは対策として、Claude Codeのシステムプロンプトを変更するたびに、モデル別の評価を実施します。各行を1つずつ外す比較で効果を調べ、モデル固有の変更を対象モデルにだけ適用するとしています。ここには、Fable 5向けガイドの「古いSkillを再評価する」を実行する方法が書かれています。文章として正しそうかではなく、その1行を外したときの成功率、遅延、コスト、スコープ逸脱を見ます。プロンプトは読み物ではなく、振る舞いを変える変更です。
短くなったSkillを眺めると、仕事をした気分になります。整っています。余白もあります。しかし、見た目だけで完了を判断するなら、テスト画面を閉じてリファクタリングを終えるのと変わりません。削る基準は格好よさではなく、その指示を外したときに失敗が増えるかです。確認せずに短くすれば、祈る時間だけが増えます。
effortも同じです。Fable 5では、知能、遅延、コストの主な調整手段としてeffortが用意され、通常はhigh、特に能力が必要な仕事ではxhigh、定型作業ではmediumまたはlowが推奨されています。反応が遅いとき、プロンプトへ「簡潔に考えて」と足す前に、仕事とeffortの対応を測った方がよい。誤字修正へxhighを使うのは、庭の雑草をショベルカーで抜くようなものです。抜けます。庭も少し変わります。
GPT-5.6の公式ガイドも、同じ方向を向いている
この話はAnthropicだけのものではありません。OpenAIは2026年7月9日、GPT-5.6を一般提供しました。旗艦モデルのSol、能力とコストの均衡を取るTerra、高頻度処理向けのLunaに分かれ、仕事の難しさ、遅延、コストに応じて実行資源を選べる構成です。
GPT-5.6のプロンプトガイドも、望む結果、重要な制約、利用できる証拠、完了基準を定義し、経路の選択をモデルへ任せるよう勧めています。重複した指示、振る舞いを変えない例、使わないツールは削る。一方で、安全、権限、証拠、出力形式、停止条件は残します。Fable 5向けガイドと同じ方向です。
OpenAIの社内評価では、簡潔なシステムプロンプトが評価スコアを改善し、トークンとコストを減らしたと報告されています。ただし、条件が限られた社内結果です。私がここから持ち帰るのは「短くすれば勝てる」ではありません。振る舞いを変えない一行にも、読み込みと判断のコストがあるということです。
制御方法は異なります。GPT-5.6にはreasoning.effort、text.verbosity、Programmatic Tool Calling、persisted reasoningがあります。Fable 5にはadaptive thinking、effort、サブエージェント、send_to_userがあります。目的が似ていても、パラメータや状態管理をそのまま移植できません。
Programmatic Tool Callingは、フィルタリングや集計のように、中間データを決まった形へ縮められる処理に向いています。結果によって次の判断が変わる仕事や、承認と引用が必要な仕事は、通常のツール呼び出しに残します。persisted reasoningも、目的と前提が安定している間だけ使う。私なら、判断をコードへ移してよい範囲と、過去の判断を持ち越してよい期間を同じ問いとして扱います。残せるから残すのではありません。
両社のガイドが共有しているのは、特定のプロンプトテンプレートではありません。結果と境界は具体的にし、計算量や状態保持はAPIとハーネスで制御する。ただし、モデルへ任せる範囲を広げるほど、文章だけでは守れない境界が残ります。
安全境界は文章の外に置く
Fable 5向けガイドによると、質問や相談には見立てだけを返し、依頼されていない変更を防ぐ必要があります。この指示は必要です。しかし、自然言語で「秘密情報を送信しない」と書くことと、秘密情報へアクセスできない環境を作ることを同一視できません。前者が行動を導く指示なら、後者は越えられない境界です。
AnthropicはHow we contain Claude across productsで、人間が都度承認する方式には承認疲れがあると説明しています。高性能なモデルやマルチエージェントシステムでは、逸脱の監視も難しくなります。そのため、ファイルシステム、ネットワーク、認証情報へのアクセスを、サンドボックス、仮想マシン、外向き通信の制御によって制限します。事故が起きたときの範囲を環境側で抑えるためです。プロンプトは「何をしてよいか」を伝えます。環境は「何ができないか」を保証します。
Fable 5には、特定領域の依頼を安全分類器が拒否する仕組みもあります。Messages APIでは、拒否はHTTPエラーではなく、stop_reason: "refusal"を持つ成功レスポンスとして返ります。また、生の思考過程は返りません。内部推論の再現を求める指示は、reasoning_extractionとして拒否を引き起こす可能性があります。
refusalを扱う解決策も、気の利いたプロンプトではありません。拒否を通常の分岐として処理し、必要ならフォールバックを設けます。進捗はユーザー向けの経路で届ける。指示は望む振る舞いを伝えます。サンドボックスとAPIは、越えられない境界を作ります。モデルが賢くなっても、お願いが柵に変わるわけではありません。
それでも、全部は要らない
ここまで書くと、Fable 5を使うにはメモリ、サブエージェント、検証役、サンドボックス、非同期ジョブ、評価スイートを全部用意すべきだと読めます。本当にそうでしょうか。誤字修正や短い質問に、長時間エージェントのための基盤は要りません。町内会の回覧板を届けるために、航空管制塔を建てる必要はありません。小さな仕事へ複雑なハーネスを持ち込めば、能力より先に運用コストが増えます。
Fable 5向けガイド自身も、難易度の上限に近い仕事から試すよう勧める一方、定型作業ではeffortを下げるよう説明しています。Claude Codeのベストプラクティスも、1文で差分を説明できる小さな変更なら、計画工程を省くとしています。GPT-5.6の移行ガイドも、移行後の基準値を測る段階では、新機能をまとめて有効にしないよう求めています。対象はPro mode、persisted reasoning、Programmatic Tool Calling、multi-agentです。重要なのは、最新の仕組みを全部使うことではありません。仕事の長さ、失敗時の影響、検証可能性に合わせて、必要な層だけを追加します。
私なら、最初に難度の高い業務を1つ選びます。現在のプロンプトとハーネスで複数回実行し、成功率、完了までの時間、トークン数、スコープ逸脱、検証漏れを記録します。次に、指示を1行ずつ削るか、権限境界、テスト、メモリ、サブエージェントへ移し、同じ評価を実施します。「Fable 5らしいプロンプト」ではなく、自分たちの仕事で不要になった指示を見つけます。
おわりに
Prompting Claude Fable 5には、すぐ使える指示例がいくつも載っています。それをコピーするのも、最初の調整としては役立ちます。ただ、Anthropicの公式ブログを時間順にたどり、GPT-5.6の公式ガイドと重ねると、両社が一貫してプロンプトの外側へ視点を広げてきたことが見えます。
視点はプロンプトからコンテキストへ、コンテキストからハーネスへ、ハーネスから評価と安全境界へ移っています。モデルが長く自律的に働くほど、言葉だけで振る舞いを支える範囲は狭くなります。
私はFable 5の性能を語りたい。だからこそ、先に自分のSkillを疑います。モデルが賢くなると、人間が決めることは減るように見えます。実際には、細かな経路を決める仕事が減り、目的、権限、証拠を決める仕事が残ります。最後まで残る難題は、プロンプトの書き方ではなく、自分たちの仕事の定義でした。
目的、権限、証拠、伝達を短く定め、必要な仕組みをテスト、フック、メモリ、サンドボックス、UIへ置き直す。その上で、以前のモデルのために書いた指示を1行ずつ外し、同じ仕事で確かめます。Skillが長い。それだけでは問題ではありません。なぜ長いのかを説明できない。そこが監査の始まりです。
ちゃんと読むとは、サンプルプロンプトを保存したかではありません。ブックマークは実装ではない。私のブラウザは、その事実を長いあいだ隠してきました。モデルを評価する前に、モデルを囲む自分たちの足場も評価の対象へ戻す。古いSkillが動いている。それは安心材料にはなります。でも、能力を引き出せているかどうかは、まだ測らなければ分かりません。たぶん。
