Anthropic公式『Prompting Claude Fable 5』完全解説 — Opus 4.8 ガイドとの違いと使い分け

Anthropic Official · Prompting Claude Fable 5 · 完全日本語解説

Claude Fable 5 の登場で、Anthropic 公式ドキュメントに 「Prompting Claude Fable 5」^[1] というモデル固有のプロンプトガイドが追加されました。一読すると「能力が上がった」という話に見えますが、本質はまったく逆で、「賢くなったモデルには、これまでと正反対のプロンプトが必要になる」という移行マニュアルです。実際、直前の世代向けに書かれた「Prompting Claude Opus 4.8」^[2] と読み比べると、サブエージェント・エフォート・指示の書き方など、複数の項目で 推奨が逆転しています。本記事では Fable 5 ガイドの全項目を 1 つずつ噛み砕き、公式プロンプト例にはすべて日本語訳と業務での活用例を添えたうえで、Opus 4.8 ガイドとの違い・使い分けまで整理します。所要時間は約 35 分。読み終わる頃には、手元のシステムプロンプトのどこを削り、どこに足せばいいかが具体的に分かります。

you@fable5:~/prompting ❯ 01_tldr.md結論：90 秒ダイジェスト — Fable 5 でプロンプトはこう変わる

全 14 章を読む時間がない方のために、まず結論だけ圧縮します。Fable 5 ガイド^[1] が伝えたいのは次の 7 点です。

1. 一番難しい仕事から渡す。Fable 5 は人間が数時間〜数週間かける仕事を最初から最後まで通しで完了できる。簡単なタスクだけでテストすると能力を過小評価する——これがガイド冒頭の最初のメッセージ。
2. 1 回の応答（ターン）が長くなる前提で、呼び出し側のプログラムを作り直す。高エフォートでは 1 リクエストが何分も、自律実行は数時間に及ぶ。タイムアウト・ストリーミング・進捗表示の見直しが移行の最初の作業になる。
3. エフォートは high がデフォルト。最重要ワークロードのみ xhigh、日常作業は medium / low。低エフォートでも従来モデルの xhigh を上回ることが多い。
4. 指示は「列挙」せず「原則」で書く。指示追従が大幅に向上したため、禁止事項を 1 つずつ並べるより、短い原則 1 つで複数の挙動をまとめて制御できる。
5. 賢くなったぶん「境界」を引く。頼んでいないメール下書きの作成や、念のための git ブランチ作成など、先回り行動が起きうる。「やるべきこと／やらないこと」の境界線を明示する。
6. サブエージェントとメモリを前提に設計する。並列サブエージェント（メインのエージェントが仕事を切り出して任せる子エージェント）の信頼性が大幅向上。教訓を書き溜める Markdown ベースのメモリを与えると特に性能が伸びる。
7. 古いプロンプトは「足す」より「削る」。従来モデル向けに書き込んだ細かい指示や、途中報告を強制する仕組みは、Fable 5 では出力品質をむしろ下げることがある。

そして Opus 4.8 ガイド^[2] との最重要差分を 1 行でいうと、「Opus 4.8 は文字通りに動くモデルを“促す”プロンプト、Fable 5 は先回りするモデルに“境界を引く”プロンプト」です。同じ語彙（エフォート、サブエージェント、進捗報告）を使いながら、推奨の向きが反転している項目が多い——この対比は ch13 で表にして全部見せます。

you@fable5:~/prompting ❯ 02_positioning.mdこのガイドの位置づけ — 「モデル固有ガイド」という読み方

Anthropic のプロンプトドキュメントは、大きく 2 層に分かれています。

つまりモデル固有ガイドは「プロンプト入門」ではなく、「前の世代から乗り換えるとき、どこで挙動が変わって戸惑うか」をまとめた差分リリースノートとして読むのが正解です。Fable 5 ガイドの冒頭には、このガイドの対象が Claude Fable 5 と Claude Mythos 5 であること、API パラメータの変更点（適応的思考のみ、要約された思考出力、拡張思考バジェットの廃止、refusal という新しい停止理由）は別ページ「Claude Fable 5 と Claude Mythos 5 の紹介」^[4] にまとまっていることが明記されています。

見落とされがちな前提：安全性分類器とフォールバック

ガイド冒頭の注記には、運用設計に直結する重要な記述があります。Fable 5 は、攻撃的サイバーセキュリティ技術（攻撃コード、マルウェア、攻撃ツールの構築など）・生物学/ライフサイエンス関連コンテンツ・モデルの思考内容の抜き出しを検知する安全性分類器（リクエストを自動チェックする仕組み）を実行しており、無害なセキュリティ作業や有益なライフサイエンスのタスクでも作動する場合があると明言されています^[1]。

この「拒否されたら Opus 4.8 に振り直す」という構図自体が、両モデルの使い分け（ch13）の伏線になっています。Opus 4.8 は引退するモデルではなく、Fable 5 体制の安全網であり、予測可能性が必要な処理の担当として併走する設計が公式に想定されているわけです。

you@fable5:~/prompting ❯ 03_capabilities.md能力向上 7 項目を読み解く — 何が「数日規模」になったのか

ガイドは Opus 4.8 と比較した向上点を 7 つ列挙しています^[1]。単なる宣伝文に見えますが、それぞれが後続章のプロンプトパターンと 1 対 1 で対応しているので、先に全体像を掴んでおくと後の章がスッと入ります。

注目すべきは冒頭の一文です。ガイドは「最良の成果を得ているチームは、Fable 5 を最も困難な未解決の問題に適用している。より単純なワークロードでのみテストすると、その能力範囲を過小評価しがち」と書いています。つまり 「とりあえず今のタスクで比較テストして、差が小さいから移行見送り」という評価方法そのものが間違いだ、というのが公式の主張です。評価の段階から「これまで Claude に任せられなかった粒度の仕事」をテストケースに含める必要があります。

you@fable5:~/prompting ❯ 04_longer_turns.mdデフォルトでより長いターン — タイムアウトと非同期設計

ガイドが「チームが Fable 5 に適応する際に直面する最も大きな変化の一つ」と呼ぶのがこれです。難しいタスクへの 1 回のリクエストは、情報収集・構築・自己検証が必要な場合、高エフォートでは何分も実行され、自律実行は数時間に及ぶことがあります^[1]。

これはプロンプトの問題である前に、Claude を呼び出す側のプログラム（ハーネス）の問題です。ガイドは移行前のチェック項目として次を挙げています。

1. クライアントのタイムアウトを延ばす。60 秒や 120 秒で打ち切る設定のままだと、モデルが正しく動いているのに呼び出し側が先に諦めてしまう。
2. ストリーミング（応答を少しずつ受け取る方式）と、ユーザー向けの進捗表示を整える。「数分間なにも表示されない」状態をユーザーに見せない画面設計が必須になる。
3. 応答を待ち続ける方式をやめ、ジョブを投げて後から状況確認する非同期方式に作り替える。リクエストを送って返事を待ち続けるのではなく、「ジョブ投入 → 定期的に状況を見に行く／完了通知を受け取る」方式へ。

一方で、「タスクが曖昧なときに延々と計画ばかり立てる」過剰計画を防ぐプロンプトも提示されています。

When you have enough information to act, act. Do not re-derive facts already established
in the conversation, re-litigate a decision the user has already made, or narrate
options you will not pursue in user-facing messages. If you are weighing a choice, give
a recommendation, not an exhaustive survey. This does not apply to thinking blocks.

you@fable5:~/prompting ❯ 05_effort.mdエフォート設定の再設計 — Fable 5 は high、Opus 4.8 は xhigh

エフォート（effort）とは、Claude が 1 つのタスクにどれだけ考える力（＝時間とトークン）を使うかを段階で指定する API パラメータです^[6]。上げるほど賢く・遅く・高くなり、下げるほど速く・安くなります。ここは両ガイドが同じパラメータを扱いながら推奨デフォルトが 1 段ずれている、使い分けの核心ポイントです。

実務的な読み方はこうです。

• Fable 5：迷ったら high。「タスクは完了するが必要以上に時間がかかる」「もっとテンポよく対話したい」と感じたら下げる。低エフォートの性能が底上げされているので、下げることをためらう必要はない。
• Opus 4.8：コーディングなら xhigh から。逆に low / medium では「求められた範囲を超えない」厳密な動き方をするため、そこそこ複雑なタスクで考え不足になるリスクがある。推論が浅いと感じたらプロンプトで工夫する前にエフォートを上げるのが第一の調整手段、と明記されています。

もう 1 つ、Fable 5 ガイドには高エフォート特有の副作用への対処が書かれています。高エフォートでは「タスクが必要とする以上に情報を集め、考え込む」「頼んでいないコード整理やリファクタリングをする」ことがあり、これを防ぐ公式スニペットが以下です。

Don't add features, refactor, or introduce abstractions beyond what the task requires. A
bug fix doesn't need surrounding cleanup and a one-shot operation usually doesn't need a
helper. Don't design for hypothetical future requirements: do the simplest thing that
works well. Avoid premature abstraction and half-finished implementations. Don't add
error handling, fallbacks, or validation for scenarios that cannot happen. Trust
internal code and framework guarantees. Only validate at system boundaries (user input,
external APIs). Don't use feature flags or backwards-compatibility shims when you can
just change the code.

you@fable5:~/prompting ❯ 06_instructions.md強力な指示追従 — 「列挙」をやめて「原則」を書く

従来のプロンプト設計では、望ましくない挙動を見つけるたびに「〜しないでください」を 1 行ずつ追加していくのが定石でした。Fable 5 ガイドはこれを明確に否定します。「指示追従が十分に改善されているため、各動作を名前で列挙するのではなく、簡潔な指示でほとんどの動作を制御できる」^[1]。

例として挙げられているのが「説明が長すぎる」問題です。Fable 5 は特に高エフォートで、採用しない選択肢の調査・根本原因の長い説明・形式ばりすぎたプルリクエスト説明文・コードの次の行が何をするかを説明するだけのコメントなど、タスクが必要とする以上に詳しく書くことがあります。これらを 1 個ずつ禁止する代わりに、次の短い原則で足ります。

Lead with the outcome. Your first sentence after finishing should answer "what happened"
or "what did you find": the thing the user would ask for if they said "just give me the
TLDR." Supporting detail and reasoning come after. Being readable and being concise are
different things, and readability matters more.

The way to keep output short is to be selective about what you include (drop details
that don't change what the reader would do next), not to compress the writing into
fragments, abbreviations, arrow chains like A → B → fails, or jargon.

「どこで止まって確認すべきか」も原則 1 つで制御できる

長時間のワークフローで「どの場面ならユーザーに確認すべきか」も、場面を列挙する必要はありません。

Pause for the user only when the work genuinely requires them: a destructive or
irreversible action, a real scope change, or input that only they can provide. If you
hit one of these, ask and end the turn, rather than ending on a promise.

you@fable5:~/prompting ❯ 07_grounding.md進捗報告を証拠で裏づける・やらないことの線引き

進捗報告を証拠に紐づける

長時間の自律実行で怖いのは、「やりました」という報告が事実かどうかです。ガイドはここに具体的な対策を示しており、しかも効果の根拠が明記されています。「Anthropic のテストでは、これにより、捏造を誘発するように設計されたタスクであっても、捏造された進捗報告がほぼ完全に排除された」^[1]。

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. Report outcomes faithfully: if tests fail, say so with the output; if a step
was skipped, say that; when something is done and verified, state it plainly without
hedging.

やらないことの線引き — 「親切すぎる」挙動への対処

Fable 5 は、頼まれていないアクション——ガイドの例では「依頼されていないメールの下書き作成」「念のための git ブランチのバックアップ作成」——を実行することがあります。能力が上がったモデルほど「気を利かせた」行動の影響範囲も大きくなるため、ガイドはやるべきこと／やらないことの明示的な線引きを推奨します。

When the user is describing a problem, asking a question, or thinking out loud rather
than requesting a change, the deliverable is your assessment. Report your findings and
stop. Don't apply a fix until they ask for one. Before running a command that changes
system state (restarts, deletes, config edits), check that the evidence actually
supports that specific action. A signal that pattern-matches to a known failure may have
a different cause.

you@fable5:~/prompting ❯ 08_subagents.md並列サブエージェント — 2 つのガイドで真逆のチューニング

サブエージェントとは、メインのエージェント（指揮役）が独立したサブタスクを切り出して任せる、別の文脈を持った子エージェントです。ここが両ガイドの差が最も鮮明な場所です。

Fable 5 ガイドの推奨スニペットは、促すというより「並走」の流儀を教えるものです。

Delegate independent subtasks to subagents and keep working while they run. Intervene
if a subagent goes off track or is missing relevant context.

対して Opus 4.8 ガイドのスニペットは、生成の「条件」を線引きするものでした。

Do not spawn a subagent for work you can complete directly in a single response (e.g.
refactoring a function you can already see).

Spawn multiple subagents in the same turn when fanning out across items or reading multiple files.

Fable 5 ガイドにはもう 1 つ、コスト最適化の重要なヒントが埋まっています。「サブタスク間で文脈を保持する長寿命のサブエージェントは、キャッシュ読み取りによって時間とコストを節約し、最も遅いサブエージェントがボトルネックになることを回避する」。つまり、サブタスクのたびに使い捨ての子エージェントを起動するのではなく、文脈を覚えたままの子エージェントに次のタスクも続けて送る方が、同じ文脈を読み直すコストがキャッシュ（一度読んだ内容の再利用）で安くなり、速度も出る、という設計指針です。

you@fable5:~/prompting ❯ 09_memory.mdメモリシステムを構築する — Markdown 1 枚から始める長期記憶

Fable 5 ガイドだけにある章です。「Claude Fable 5 は、以前の実行から得た教訓を記録し、それを参照できる場合に特に優れたパフォーマンスを発揮する。Markdown ファイルのようなシンプルなものでよいので、メモを書き込む場所を提供してください」^[1]。ベクトルデータベースのような特別な仕組みは要らず、書き込めるフォルダ 1 つで始められます。

Store one lesson per file with a one-line summary at the top. Record corrections and
confirmed approaches alike, including why they mattered. Don't save what the repo or
chat history already records; update an existing note rather than creating a duplicate;
delete notes that turn out to be wrong.

さらに、ゼロから育てるのではなく過去セッションの履歴からメモリを一括生成（ブートストラップ＝初期立ち上げ）するプロンプトも提示されています。

Reflect on the previous sessions we've had together. Use subagents to identify core
themes and lessons, and store them in [X]. Make sure you know to reference [X] for
future use.

you@fable5:~/prompting ❯ 10_edge_cases.mdまれに起こる 2 つの症状 — 早期停止とコンテキスト不安

ガイドは「まれに発生する」と前置きしつつ、長いセッションで起きうる 2 つの症状と処方箋を載せています。どちらも知らないと「モデルが壊れた」と誤診しやすいので、トラブル対応集として覚えておく価値があります。

症状 1：早期停止 — 「これから X をします」と言って止まる

長いセッションの深い段階で、実際の処理を実行せずに「これから X を実行します」というテキストだけで応答を終えたり、続行に十分な情報があるのに許可を求めて止まったりすることがあります。対話で使っているなら「続けてください」「最後までやり切ってください」の一言で復帰します。人間が見ていない自動実行パイプラインでは、次のリマインダーを常駐させます。

You are operating autonomously. The user is not watching in real time and cannot answer
questions mid-task, so asking "Want me to…?" or "Shall I…?" will block the work. For
reversible actions that follow from the original request, proceed without asking.
Offering follow-ups after the task is done is fine; asking permission after already
discussing with the user before doing the work is not. Before ending your turn, check
your last paragraph. If it is a plan, an analysis, a question, a list of next steps, or
a promise about work you have not done ("I'll…", "let me know when…"), do that work now
with tool calls. End your turn only when the task is complete or you are blocked on
input only the user can provide.

症状 2：コンテキスト不安 — 残り容量を気にして勝手に「巻き」に入る

コンテキスト（モデルが一度に扱える会話・作業内容の容量）が長くなったセッションで、新しいセッションを提案したり、「ここまでを要約して引き継ぎます」と申し出たり、作業を勝手に切り詰めたりすることがあります。ガイドによると、これは呼び出し側のプログラムが「残りトークン数」のカウントダウンをモデルに見せている場合に最も頻発します。第一の対策は「可能な限り、残り容量の数値をモデルに見せない」こと。どうしても表示が必要な場合は、次の「安心させる」指示を入れます。

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

you@fable5:~/prompting ❯ 11_communication.mdコミュニケーション設計 — 理由・読みやすさ・send_to_user ツール

ガイド後半の 3 章は、いずれも「モデルと人間の接点」の設計です。まとめて押さえます。

(1) リクエストだけでなく「理由」を伝える

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].

(2) ユーザー向け出力の読みやすさ

長いエージェント的セッション（大量のツール実行・大きな作業文脈）の後、Fable 5 は読みにくいテキスト——矢印だらけの省略記法、深すぎる実装詳細、ユーザーには見えていない内部検討への言及、過度に技術的な表現——を生成することがあります。ガイドの補足指示は長めですが、考え方の核心はこの一文です。

Terse shorthand is fine between tool calls (that's you thinking out loud, and brevity there is good). Your final summary is different: it's for a reader who didn't see any of that.

Prompting Claude Fable 5（Anthropic 公式） / [1]

続けてガイドは、こう指示しています。「夜間や多数のツール実行を挟んで長時間働いた後の最終メッセージは、作業メモの続きではなく初めて読む人への報告として書け。作業中に自分が編み出した用語や略語は読み手のものではないから持ち込むな。完全な文で書き、用語は省略せずに綴り、矢印の連鎖や自作のラベルを使うな。短さと明確さで迷ったら明確さを取れ」。

(3) send_to_user ツール — 作業を終えずにユーザーへ届ける

長時間動く非同期エージェントでは、「応答の終了＝メッセージ送信」という従来の前提が崩れます。作業はまだ続いているのに、途中経過や成果物だけ先にユーザーへ見せたい場面が出てくるからです。そこでガイドは、エージェントが作業を終了せずに、ユーザーへメッセージを一字一句そのまま届けるための専用ツールの追加を推奨しています。用途は、成果物（生成したコードや文面の下書き）、具体的な数値を含む進捗報告、ユーザーが作業中に投げた質問への直接回答など。ツールへの入力は要約処理を通らないため、内容がそのまま届くのがポイントです。

{
  "name": "send_to_user",
  "description": "Display a message directly to the user. Use this for progress updates, partial results, or content the user must see exactly as written before the task finishes.",
  "input_schema": {
    "type": "object",
    "properties": {
      "message": {
        "type": "string",
        "description": "The content to display to the user."
      }
    },
    "required": ["message"]
  }
}

you@fable5:~/prompting ❯ 12_scaffolding.md推奨される移行作業 5 箇条 — 「足す」より「削る」

ガイドの最終章は、移行時にやるべき作業のリストです。原文では「スキャフォールディング（scaffolding＝足場）の変更」と呼ばれています。スキャフォールディングとは、モデルの周囲に組む仕組み一式——システムプロンプト、ツール定義、スキル（再利用する指示書）、自動化スクリプトなど——のことです。5 項目あります^[1]。

1. 難易度の最上位から始める。従来モデルに任せていたより難しいタスクを選び、Fable 5 自身に作業範囲の定義と、不明点の質問をさせてから実行させる。
2. 長時間実行プロンプトに自己検証を組み込む（下で詳述）。
3. 既存のプロンプトとスキルを見直して削る。従来モデル向けのスキルは Fable 5 には「指示が細かすぎる」ことが多く、出力品質をかえって下げうる。素の性能の方が良ければ古い指示は削除を検討する。Fable 5 は、目の前のタスクから学んだことでスキルをその場で改訂するのも得意。
4. 「思考過程を回答に再現させる」指示を撤去する（下のコールアウトで詳述）。
5. send_to_user ツールを作成する（ch11 参照）。長時間の非同期エージェントで、途中経過をそのまま届ける手段として。

2 項目めの自己検証について、公式の指示例はこうです。

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.

5 箇条を通して見ると、方向性は一貫しています。旧世代向けに「足してきた」細かい管理指示を削り、代わりに「検証の仕組み」と「届ける手段」という構造を足す。プロンプトの書き換えというより、エージェント運用設計の作り直しです。

you@fable5:~/prompting ❯ 13_vs_opus48.mdOpus 4.8 ガイドとの完全対照 — どちらをいつ使うか

ここまで随所で触れてきた Opus 4.8 ガイド^[2] との違いを、一枚の表に集約します。両ガイドを並べて読むと、同じテーマに対する推奨の「向き」が見事に対になっていることが分かります。

Opus 4.8 ガイドにしかない 4 つの知見

Fable 5 に移行しても、Opus 4.8 ガイド固有の知見は引き続き有効です（拒否時の振り直し先・併用モデルとして Opus 4.8 を使い続けるため）。特に重要な 4 つを要約します。

• デザインの定番スタイル打破：Opus 4.8 が作る画面デザインには一貫した「いつもの作風」（クリーム色の背景 約 #F4F1EA・飾り気のあるセリフ体見出し・テラコッタ系の差し色）があり、「クリーム色を使わないで」のようなふわっとした指示では別の固定パターンに移るだけで多様になりません。確実なのは、(1) 色コードや書体まで含む具体的な代替仕様を渡す、(2) 作り始める前に「背景色・差し色・書体と一行の理由」の組を 4 案提案させて選ぶ、の 2 つです。
• コードレビューの報告基準：Opus 4.8 はバグ発見力が上がったのに、旧モデル向けの「重大な問題だけ報告して」という指示に忠実に従いすぎて、見つけたバグを報告せず、見かけ上の検出数が減ることがあります。対策は、発見の段階では「不確かでも軽微でも全部報告。選別は後工程の仕事。あなたの役割は網羅」と明示し、確信度と重大度を添えさせて後で絞ること。
• 対話型製品のトークン効率：Opus 4.8 はユーザーの発言のたびに考え直すため、対話型ではトークン消費が増えます。最初の発言でタスク・意図・制約をまとめて伝え、やり取りの回数を減らす方が、効率も品質も上がります。
• コンピュータ操作の画面解像度：画面を見ながら操作する機能は最大 2576px / 3.75MP まで対応し、1080p が性能とコストのバランス良。コスト重視なら 720p や 1366×768 も選択肢です。

使い分けの実務指針

you@fable5:~/prompting ❯ 14_checklist.md移行チェックリスト 15 項目とまとめ

最後に、本記事の内容を「明日やる作業」に変換したチェックリストです。上から順に潰せば、Fable 5 ガイドの推奨をひととおり実装したことになります。

インフラ・呼び出し側プログラム（ch04・ch10）

1. クライアントのタイムアウトを「数分単位の応答」前提に延長した
2. ストリーミングと進捗表示を整備した
3. 応答を待ち続ける方式をやめ、非同期（ジョブ投入＋状況確認/完了通知）の構成にした
4. 残りトークン数などの内部情報をモデルに見せるのをやめた（消せない場合は「まだ十分残っている」スニペットを追加）
5. 拒否（stop_reason: "refusal"）時の Opus 4.8 への振り直しを実装した

システムプロンプト（ch04〜ch07・ch11）

1. 「十分な情報が揃ったら行動せよ」の過剰計画防止スニペットを入れた
2. 「タスクが要求する以上の機能追加・リファクタをするな」のスニペットを入れた（コーディング用途）
3. 「結論を先頭に・削るのは情報の選別であって文章の圧縮ではない」の簡潔さ原則を入れた
4. 止まるべき 3 条件（不可逆な操作／範囲の変更／本人にしか出せない情報）の停止条件を入れた
5. 進捗報告をツール実行結果と突き合わせる監査スニペットを入れた（長時間の自律実行）
6. 「問題の説明には見立てを返して止まる」「状態を変えるコマンドの前に証拠を確認」の線引きスニペットを入れた
7. 依頼の書き方を「理由つきテンプレート」（誰のため・何のため・それを踏まえて依頼）に変えた

スキル・仕組みの棚卸し（ch08・ch09・ch12）

1. 旧モデル向けの細かすぎる指示・途中報告を強制する仕組みを削除候補としてリストアップし、素の性能と比較した
2. 「思考過程を回答に含めて」系の指示を検索で洗い出して撤去した（拒否応答の予防）
3. メモリ用フォルダ（1 ファイル 1 教訓）を用意し、必要に応じて send_to_user ツール・定期的な検証サブエージェントを導入した

まとめ

本記事の要点を 3 つに集約します。

1. Fable 5 ガイドの本質は「境界の設計」。賢く・自律的になったモデルには、細かい手順書ではなく、行動原則と越えてはいけない線（停止条件・証拠主義・作業範囲）を与える。指示は列挙から原則へ。
2. Opus 4.8 ガイドの本質は「促しの設計」。文字通りに動く高精度モデルには、ツール使用・サブエージェント・適用範囲を明示的に促し、染みついた定番（画面デザインの作風・報告の自己選別）を具体的な仕様で上書きする。両者はプロンプトの「向き」が逆。
3. 移行は削る作業から始まる。タイムアウト延長と非同期化という足回りの整備を済ませたら、旧世代向けに足してきた細かい管理指示を削り、メモリ・検証サブエージェント・send_to_user という新しい構造を足す。そして評価には「これまで任せられなかった一番難しいタスク」を使う。

プロンプトエンジニアリングの普遍的な基礎（明確さ・例示・XML タグ）は引き続き有効です^[3]。そのうえで、モデル世代ごとの「性格」に合わせてプロンプトの抽象度と向きを切り替える——それが 2 つの公式ガイドが教えてくれる、これからのモデル運用の作法です。