Claude Fable 5でハーネス設計はこう変わる｜公式が認めた3原則

Claude Fable 5が戻ってきました。2026年6月9日に発表され、6月12日に全ユーザーのアクセスが停止、そして7月1日にセーフガードを強化したうえで復旧——という異例の経緯をたどったモデルです。

すでにnoteには「Fable 5とは？」「完全攻略」「プロンプトガイド要約」といった記事が並んでいます。料金や停止の経緯は、もう十分に語られました。

だからこの記事では、別の角度から書きます。Anthropicが公開したFable 5の公式プロンプティングガイドは、実は「マルチエージェント設計の経験則」を公式に追認した文書だった、という話です。

私はClaude Codeのマルチエージェント設計について、Anthropic Labsの実験記事や実践者の記事を1年近く読み溜めてナレッジベースにまとめてきました。そこに蓄積された仮説のうち3つが、今回の公式ドキュメントでほぼそのまま裏付けられていたのです。しかも、そのうち1つは「対策の方向が逆だった」ことまで判明しました。

さらに、公式ガイドを読み込むと実装で確実に踏む地雷が3つ埋まっています。1つは、設定を忘れるとAPIが黙って止まります。

そもそもFable 5は「ハーネス前提」のモデルとして設計されている

まず押さえておくべき前提があります。Anthropicの公式製品ページは、Fable 5の用途の筆頭にエージェントハーネスを挙げています。

「段階をまたいだ計画」「サブエージェントへの委譲」「自分の仕事の検証」。この3つは、マルチエージェント設計で言うところのPlanner・Generator・Evaluatorそのものです。

ここが決定的な変化です。これまでハーネス設計は「単一エージェントの限界を回避するための工夫」でした。コンテキストが埋まると品質が落ちるから分割する、自己評価が甘いから評価役を別に立てる——つまりモデルの弱点を補う回避策だったわけです。

それがFable 5では、最上位モデルの標準的な使い方としてAnthropic自身が提示しています。ハーネスを組まずにFable 5を使うのは、性能の大半を捨てているのと同じです。

料金は「Opusの2倍」

先に現実的な話をしておきます。Fable 5は入力100万トークンあたり10ドル、出力100万トークンあたり50ドルです。

比較すると、こうなります。

• Claude Fable 5: 入力$10 / 出力$50、コンテキスト1M

• Claude Opus 4.8: 入力$5 / 出力$25、コンテキスト1M

• Claude Sonnet 5: 入力$3 / 出力$15、コンテキスト1M

• Claude Haiku 4.5: 入力$1 / 出力$5、コンテキスト200K

つまりOpus 4.8のちょうど2倍です。「最新モデルに上げたい」という理由でFable 5を選ぶのは間違いです。 その答えはOpus 4.8です。Fable 5を選ぶのは、数日がかりの自律タスクを任せたいときだけ。プロンプトキャッシュの入力90%割引は従来どおり効くので、長時間ランではここが効いてきます。

なお30日間のデータ保持が必須で、ゼロデータ保持（ZDR）設定の組織ではすべてのリクエストが400エラーになります。企業導入では最初に確認すべきポイントです。

公式が裏付けた設計原則①：コンテキスト不安は「ハーネス側の問題」だった

ここから本題です。

マルチエージェント設計の世界にはコンテキスト不安（context anxiety）と呼ばれる現象が知られています。コンテキストウィンドウが埋まってくると、モデルが「そろそろ終わらせなきゃ」と焦って品質を犠牲にする。テストを先送りする、エラーハンドリングが雑になる、機能を勝手に省略する——といった症状が出ます。

Fable 5の公式ガイドには、これが "Rare cases of context-budget concern"（稀に起きるコンテキスト予算への懸念）として記載されています。長いセッションの深部で、Fable 5は「新しいセッションを始めましょうか」と提案したり、要約して引き継ごうと申し出たり、自分の作業を切り詰めたりすることがある、と。

ここまでは想定内でした。驚いたのは、その次の一文です。

引き金は、ハーネスが親切心で表示していた「残りトークン数」だったのです。

これは対策の方向が180度変わることを意味します。コンテキスト不安はモデル側の欠陥である以上に、ハーネス側の情報設計の問題だった。やるべきことは「モデルに何を見せるか」を工夫することではなく、「何を見せないか」を決めることです。

残量表示は人間のオペレーターには有用です。でもモデルに渡してはいけない。ハーネスのUI層と、モデルに渡すコンテキストは分離すべきなのです。

どうしても表示せざるを得ない場合、公式は緩和プロンプトを用意しています。

You have ample context remaining. Do not stop, summarize, or suggest
a new session on account of context limits. Continue the work.

（コンテキストはまだ十分にある。コンテキスト制限を理由に停止・要約・新セッションの提案をするな。作業を続けよ）

公式が裏付けた設計原則②：自己批評では足りない、「別コンテキスト」が要る

2つ目は自己評価バイアスです。AIに「自分のコードをレビューして」と頼むと、明らかなバグがあっても「よくできています」と返ってくる。作る側と評価する側が同じである限り、品質の天井は破れません。

だからGenerator（生成器）とEvaluator（評価器）を別エージェントに分ける——これがマルチエージェント設計の基本パターンです。

公式ガイドは、この対策を明確に支持しました。ただし、こう書かれています。

注目すべきは fresh-context という語です。

私たちはこれまで「別エージェントに分離する」と表現してきました。公式が強調しているのは、そこから一段踏み込んだ「別コンテキスト」です。評価器が生成過程の文脈を引き継いでしまっていると、それは自己批評に近づいてしまう。エージェントを分けるだけでなく、コンテキストを分けるところまでが対策に含まれるということです。

Claude Codeの生みの親であるBoris Chernyは「Claude自身にテストを実行させ、スクリーンショットを撮らせる自己検証こそが最大レバレッジだ」と語っています。これは単一エージェント内の実装として有効です。しかし公式は、その上位にfresh-contextの検証サブエージェントを置いたことになります。

公式が示す実装プロンプト

長時間ランでの自己検証について、公式はそのまま使えるプロンプトを提示しています。

Establish a method for checking your own work at an interval of [X] as you build.
Run this every [X interval], verifying your work with subagents against the specification.

（作りながら、一定間隔[X]で自分の仕事を検証する方法を確立せよ。その間隔ごとに実行し、仕様に対してサブエージェントで検証せよ）

この短い指示に、設計のポイントが3つ埋まっています。

検証は仕様に対して行う。 「against the specification」です。何をもって完了とするかを事前に定義しておかないと、評価器は何も判定できません。

検証をループに埋め込む。 終端で1回レビューするのではなく、作りながら一定間隔で回す。

検証はサブエージェントにやらせる。 自分ではなく、別のコンテキストを持つ誰かに。

進捗報告の「捏造」という新しい症状

自己評価バイアスには変種があります。長時間ランで、Fable 5はやっていない作業を「やった」と報告することがあるのです。

公式の対策プロンプトがこれです。

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 yet verified,
say so explicitly.

（進捗を報告する前に、各主張をこのセッションのツール結果と突き合わせて監査せよ。証拠を指し示せる作業だけを報告し、未検証のものは未検証だと明言せよ）

Anthropicのテストでは、捏造を意図的に誘発するタスクでさえ、このプロンプトで虚偽の進捗報告がほぼ消滅したと報告されています。主観的な自己評価を、ツール結果という外部証拠に接地させる構造です。

公式が裏付けた設計原則③：スキルは「削る」フェーズに入った

3つ目が、いちばん逆説的です。

マルチエージェント設計には「ハーネスの各コンポーネントは、モデルが単独でできないことへの仮定をエンコードしている」という洞察があります。だからモデルが進化すると、ハーネスは縮小するのではなく移動する。ある部品が不要になり、別の部品が重要になる。

Anthropicは今回、この現象を自ら実例で示しました。

手順を丁寧に書き込んだスキルが、Fable 5では品質を下げる。 デフォルト性能のほうが良ければ、古い指示は削れ、と公式が言っているのです。

何が削れて、何が増えるのか

Fable 5におけるハーネス部品の移動を整理すると、こうなります。

削るもの

• 詳細な手順指示（過剰に規定的なスキル）

• モデルに見せる残トークンのカウントダウン

強化するもの

• 評価器。同一コンテキストの自己批評では足りず、fresh-contextの検証サブエージェントが要る

• 進捗報告への証拠要求。ツール結果と突き合わせて監査させる

• サブエージェントの活用。しかもブロッキングで待たず非同期に

作り替えるもの

• タイムアウト設計。単発リクエストが数分〜十数分、自律ランは数時間に及ぶ

• 同期的に結果を待つ構造そのもの

ここで大事なのは、ハーネスは総量として縮んでいないことです。手順指示は削れましたが、評価器は強化されました。モデルが自力でできるようになった箇所（手順の組み立て）から、まだできない箇所（自分の仕事の客観評価）へ、コンポーネントが移動しているだけなのです。

ちなみに公式は「Fable 5はタスク中の学びからスキルをその場で更新するのも得意」とも書いています。SKILL.mdが、人間の書いた静的な資産から、エージェントが書き換える動的な資産に変わりつつある、ということです。

実装で確実に踏む地雷3つ

ここからは実務の話です。公式ドキュメントを読み込んだうえで、「知らないと確実に事故る」ポイントを3つ挙げます。

地雷1：APIのフォールバックは自動ではない

Fable 5には、サイバーセキュリティと生物学の領域に安全性分類器が組み込まれています。この領域のクエリを検知すると、正常なHTTP 200で `stop_reason: "refusal"` が返ります。エラーではありません。200番です。

`response.content[0]` を無条件で読むコードは、ここで壊れます。必ず先に `stop_reason` を確認してください。

そして、ここが本題です。公式FAQにこう書かれています。

つまり自動フォールバックはClaudeアプリ側の挙動です。API利用者が自分で設定しなければ、拒否されたまま処理が停止します。

公式は「Fable 5のコードには既定でフォールバックを入れよ」と推奨しています。具体的には `fallbacks: [{"model": "claude-opus-4-8"}]` を指定します。良性のセキュリティ業務やライフサイエンス業務でも誤検知は起きるので、これは保険ではなく必需品です。

なおアプリ側で自動ルーティングされた分には、Fable価格は課金されません（Opus 4.8の料金になります）。地味に良心的な設計です。

地雷2：「思考過程を書き出せ」という指示がフォールバックを頻発させる

これは既存のスキル資産を持っている人ほど危険です。

安全性分類器の対象には、サイバーセキュリティと生物学に加えて、モデルの要約思考の抽出（reasoning extraction）が含まれています。

そして公式ガイドには、こう警告されています。

「思考の過程も見せてね」「なぜそう判断したか説明して」——こうした指示は、これまで品質向上のテクニックとして広く使われてきました。Fable 5ではこれが逆効果になります。

移行時に、既存のスキルとsystem promptを全部grepしてください。 推論の可視化が必要なら、応答テキストに書かせるのではなく、adaptive thinkingの構造化された `thinking` ブロックを読むのが正解です。

地雷3：思考をオフにできない、ターンが数分で終わらない

Fable 5では `thinking: {type: "disabled"}` が400エラーになります。Opus 4.8や4.7では受理される書き方です。Fable 5では `thinking` パラメータそのものを省略するのが正解で、深さは `output_config.effort` で制御します。

`budget_tokens` も400です。プレフィル（最後のassistantターンの先読み）も非対応です。

そして最大の運用シフトがこれです。高effortでの単発リクエストは数分から十数分、自律ランは数時間に及びます。 公式はこれを「チームが直面する最大のシフトのひとつ」と表現しています。

移行前に、クライアントのタイムアウト、ストリーミング、進捗表示を見直してください。そして公式が指示しているのは、もっと踏み込んだ変更です。ブロッキングで結果を待つ構造をやめて、スケジュールジョブなどで非同期にランを確認する構造に作り替えよ。

`/loop` やRoutinesのような常駐監視層の重要度が、ここで一段上がります。

effortは「全レベルを試せ」

コスト面で朗報がひとつ。公式はこう書いています。

既定は `high` です。最も能力を要する用途だけ `xhigh`、ルーチンワークは `medium` や `low` で構いません。高effortは優れた検証挙動を生む一方、ルーチンワークでは過剰に文脈収集して熟考しすぎます。「頼んでいないリファクタ」もここで発生します。

よくある質問

Q: Fable 5とMythos 5は何が違いますか

A: 同一基盤・同一価格・同一API挙動です。違いは提供範囲だけ。Mythos 5は限定提供で、サイバーセキュリティ・生物学研究の用途で審査済みパートナーに開放する予定です。Fable 5は同じ基盤にリスク領域のセーフガードを組み込んで、広く提供する版にあたります。

Q: 停止と復旧の経緯を簡単に教えてください

A: 2026年6月9日に発表、6月12日に全ユーザーのアクセスが停止、7月1日にセーフガードを強化したうえで復旧しました。公式製品ページは復旧を「セーフガードをさらに強化した」とのみ記しています。教訓は「業務の中核を単一モデルに依存させるな」です。 フォールバック先の設計は、APIパラメータとしても事業継続性としても必要です。

Q: とりあえず最新モデルに乗り換えたいのですが

A: それならOpus 4.8です。Fable 5はOpus 4.8の2倍の単価で、API挙動も違います。数日がかりの自律タスクを任せる明確な理由があるときだけ選んでください。

まとめ｜ハーネスを持たない人には、宝の持ち腐れになる

要点を整理します。

• Fable 5はハーネス前提のモデル。公式が用途の筆頭にエージェントハーネスを挙げ、「数日間稼働し、計画し、委譲し、自分の仕事を検証する」と明記している

• コンテキスト不安の引き金は残トークン表示だった。モデルに見せてはいけない。ハーネスのUI層とコンテキストを分離する

• 自己批評では足りない。評価器は「別エージェント」ではなく「別コンテキスト」で立てる

• 手順を書き込んだスキルは削る対象。ハーネスは縮小せず移動する。手順指示から評価器へ

• APIのフォールバックは手動設定。忘れると拒否のまま停止する

• 「思考過程を書き出せ」系の指示は既存スキルからgrepして消す。フォールバックを頻発させる

Fable 5は、単体で賢いモデルではありません。計画させ、委譲させ、検証させる器を用意して初めて性能が出るモデルです。逆に言えば、これまでマルチエージェント設計を積み上げてきた人にとっては、その資産が一気に効いてくるタイミングでもあります。

まずはOpus 4.8で回している自律タスクをひとつ選んで、評価器をfresh-contextのサブエージェントに切り出すところから始めてみてください。残トークンの表示を止めるのは、その日のうちにできます。

📚 さらに深く学びたい方へ

本記事で扱ったハーネス設計は、Claude Codeの基本構造を押さえているほど応用が利きます。

実践Claude Code入門―現場で活用するためのAIコーディングの思考法

生成AIコーディングを「一時的な効率化」ではなく「開発プロセスの再設計」として扱う一冊。本記事の「ハーネスは縮小せず移動する」という発想の土台になる考え方が整理されています。

Claude CodeによるAI駆動開発入門

これからClaude Codeを触る方はこちらから。CLAUDE.mdやスキルの基本的な役割が丁寧に解説されており、本記事の「スキルを削る」という判断をする前提知識が身につきます。

🎯 AI JONBIN Guildのご案内

AI活用をもっと深く学びたい方へ。限定コミュニティで一緒にスキルアップしませんか？

• 定期的なAI勉強会・セミナー

• ClaudeCodeなどのエージェントファイル共有

• n8nサーバーへのアクセス

• AI専門家による限定セミナー

• メンバー同士の情報交換

▶️ AI JONBIN Guildの詳細はこちら

この記事が参考になったら「スキ❤️」をお願いします。Fable 5を実務で回した結果があれば、ぜひコメントで教えてください！

X: @sumo_wonderful
YouTube: AI大学~ヨッピーch~
note: note.com/samurai_worker

#ClaudeFable5 #ClaudeCode #AIエージェント #ハーネス設計 #生成AI #AI活用 #マルチエージェント