Anthropic公式「Claude Fable 5 プロンプトエンジニアリングガイド」を日本語で読み解く ── そこからわかる、次世代モデルを使いこなす原則
こんにちは、株式会社Renewerの堀内です。
話題のClaude最上位モデル「Claude Fable 5」が、7月1日から再度利用できるようになりました。それに合わせて、開発元のAnthropicが「Claude Platform Docs」で、Fable 5専用のプロンプトエンジニアリングガイドを公開しています。
Fable 5を効果的に使う上で、開発元のAnthropic自身が書いた、かなり重要なドキュメントだと思います。
私自身、「これを読んで使い倒そう」と思ったのですが、原文をそのまま翻訳しただけでは、ぱっと見で理解しづらい箇所がいくつかありました。
そこで、わかりやすい言葉に置き換えながら、日本語訳・解説としてまとめ直したのがこの記事です。
ガイドに掲載されている「そのまま使えるプロンプト」も、日本語で使える形に翻訳しています。
私と同じく、Fable 5を使い倒したい方の参考になれば幸いです。
なお、理解しやすさを優先して意訳した箇所や、扱っていない章があります。正確な内容は原文をご確認ください。
｜
私がこの記事を深堀りして理解しようと思った理由がもうひとつあります。
ここに書かれている内容は、Fable 5にかかわらず、次世代モデルと使いこなすための原則になるのではないか、ということです。
これまで私は、以下の記事のようにプロンプトエンジニアリングの変遷を追いかけてきました。
例えば、以前は「できるだけ多くの情報を盛り込む」ことが精度を上げる原則でした。一方で最新の高性能モデルでは、シンプルなプロンプトの方が効果を発揮する傾向が見えてきています。
この記事は、そうした認識をアップデートするためのものです。
GPT、Geminiでも、さらなる高性能化・自律化が進んでいます。
したがって、Fable 5に関わらず次世代モデルを今後使っていく方、プロンプトエンジニアリングの現在地や未来について関心がある方も、示唆のある内容になっていると思います。
そのような背景もあり、ガイドブックでもまとめました。こちらも合わせてご覧ください。
以下から無料でダウンロードできます。
Fable 5の特徴
公式ガイドは冒頭で、Fable 5の位置づけをこう説明しています。
Fable 5 は「人間が数時間〜数週間かける仕事」を丸ごと任せられるモデル
簡単なタスクだけで試すと実力を過小評価しがちで、「一番難しい未解決の課題」をぶつけたチームほど良い成果を出している、とされています。
何が進化したか（Opus 4.8比）
Fable 5がClaude Opus 4.8と比べて、明確な性能向上を示しているのは以下の7領域です。
長時間の自律稼働
数日がかりのタスクでも指示を忘れずに完走できる
一発回答の精度
要件が明確な複雑タスクなら、従来数日の試行錯誤が必要だった実装を1パスで完成させた事例も
画像認識（Vision）
情報密度の高い技術図・スクショの読解精度が大幅向上。傾き・ぼやけた画像はbashやクロップツールで自力補正する訓練済み
業務系アウトプット
財務分析・Excel・スライド・ドキュメントで「そのまま提出できる品質」
コードレビュー・デバッグ
バグ検出の再現率が明確に向上。コードベースやリポジトリ履歴の横断検索も強い
曖昧な依頼への対応
ふわっとした複数論点の依頼から、次のアクションを自分で決められる
サブエージェント運用
並列サブエージェントの起動・管理、長時間稼働するエージェント間の連携が格段に安定
ただし従来モデル（Opus 4.8）とは挙動のクセが変わったので、プロンプトや周辺システムの調整である、と述べています。
ここからは、Fable 5を使っていく上での「調整のポイント」と、具体的なプロンプトを8つに分けて紹介します。
1. 1ターンが長くなる（最も顕著な変化）
難しい仕事を任せた場合、1回の依頼への応答に数分かかることがあります。AIが自律的に作業を続ける場合は、数時間に及ぶこともあります。
この変化の副作用として、指示が曖昧な場合、「考えすぎ（過剰プランニング）」を行うことがあります。
それを防ぐのが、以下のプロンプトです。
「考えすぎ」を防ぐプロンプト（例）
行動できるだけの情報が揃ったら、すぐに行動してください。
会話の中ですでに確定した事実を調べ直したり、ユーザーが決定済みのことを蒸し返したり、採用しない選択肢について説明したりしないでください。選択に迷ったときは、選択肢を並べるのではなく、おすすめの案を1つ提示してください。（思考ブロックの中では自由に検討して構いません）
また、APIを利用して開発している方向けには、移行前にやるべきことも挙げられています。
クライアントのタイムアウト値を延ばす
ストリーミングと進捗表示 UI を整備する
「完了までブロックして待つ」設計から、定期ジョブ等で非同期にポーリングする設計へ
2. effort（考える深さ）は全レベルを検討する
Claude Codeには「effort」という設定があります。
effortは、AIがどれだけ深く考えるかを決めるもので、「賢さ × 応答速度 × コスト」のバランスを調整する重要な設定項目です。
デフォルトは high
最重要ワークロードのみ xhigh
定型作業は medium / low でもよい
注目したいのは、「Fable 5の低いeffortは、旧モデルのxhighを上回ることも多い」という一文です。タスクは完了するけれど時間がかかりすぎる、もっとテンポよく対話したい。そういう場合は、effortを下げることが推奨されています。
副作用もあります。高いeffortだと定型作業でも余計な調査・熟考をしがちです。
頼んでいない整理・リファクタリングを防ぐプロンプト（例）
タスクに必要な範囲を超えた機能追加・リファクタリング・抽象化はしないでください。
バグ修正のついでに周辺コードを整理する必要はありません。
「将来使うかもしれない」という仮定のための設計はせず、うまく動く最もシンプルな方法を選んでください。
起こり得ないケースへのエラー処理やバリデーションは追加しないでください。入力チェックはシステムの境界（ユーザー入力・外部 API）だけで行ってください。
ちなみに「effort」は、Claude Desktopではモデル名の右「高」をクリックすると変更できます。（日本語設定では「工数」と表示されます）
3. プロンプトは「短い方針」で良い
Fable 5 は指示追従性（Instruction Following）が大きく向上し、短い方針ひとことで、ほとんどの挙動を制御できるようになりました。
採用しない選択肢の調査結果を長々と述べる
根本原因を必要以上に詳しく説明する
過剰に構造化されたPR説明文を書く
次の行の動作をなぞるだけのコメントを書く
これまでは、上記を1つずつ禁止する必要がありましたが、Fable 5では短い方針指示1つで同等の効果が得られます。
AIからの出力が冗長になるのを防ぐプロンプト（例）
結論から書いてください。
作業を終えたら、最初の1文で「何が起きたか」「何がわかったか」に答えてください（「要点だけ教えて」と言われたときに返す内容です）。
詳細や理由づけはその後に続けてください。
読みやすさと短さは別物で、読みやすさを優先してください。
出力を短くするときは、読み手の次の行動に影響しない詳細を削ってください。断片的な文・略語・「A→B→失敗」のような矢印表記・専門用語の多用に圧縮するのはやめてください。
例2：長時間ワークフローでの「確認のために止まるべきポイント」を伝えるプロンプト
ユーザーに確認を求めるのは、本当に必要な場面だけにしてください。
具体的には、破壊的で元に戻せない操作をするとき、作業範囲が本質的に変わるとき、ユーザーにしか提供できない情報が必要なときです。
該当する場合は質問してターンを終えてください。
「あとでやっておきます」という約束で終えないでください。
「結論から書いてください」「本当に必要な場面だけにしてください」。これが「短い方針」の実例です。細かいユースケースを列挙するのではなく、大きな方針を1つ示せばよい、ということですね。
このあたりは、過去のプロンプトエンジニアリングの常識から見ると大きな転換です。作り込んだ長い指示が、新しいモデルではかえって品質を下げることもある。
これからはモデルの世代交代のたびに、プロンプトを「削る」見直しをすることが必要になる気がします。
4. 長時間実行では「進捗報告の裏取り」を義務化する
長時間の自律実行には、見過ごせないリスクがあります。実際にはやっていない作業を「完了しました」と報告してしまうことです。
Fable 5では、進捗報告をツールの実行結果と突き合わせるプロンプトを入れることで、このリスクをほぼ排除できることが確認されています。
進捗報告の裏取りプロンプト（例）
進捗を報告する前に、報告する内容全てが、このセッション内のツール実行結果と一致しているかを確認してください。
証拠を示せる作業だけを報告し、まだ検証していないものは「未検証」と明記してください。
テストが失敗したら、その出力とあわせて失敗したと伝えてください。
スキップしたステップがあれば、そのように伝えてください。
完了して検証も済んでいることは、曖昧にぼかさず、はっきり完了と伝えてください。
Anthropicの社内テストでは、わざと虚偽報告を誘発するように設計したタスクでも、この指示でほぼゼロにできたそうです。
5. やっていいこと・ダメなことの境界を明示する
Fable 5は、稀に頼んでいない行動を取ることがあります。
勝手にメールの下書きを作る、念のためのバックアップを作る、といった具合です。
それを避けるための推奨プロンプトも紹介されています。
ユーザーが「相談・質問・思考の言語化」したいときのプロンプト
ユーザーが問題を説明している・質問している・考えを口に出しているだけのときは、求められている成果物は「あなたの見解」です。
わかったことを報告して、そこで止まってください。
修正は、頼まれるまで実行しないでください。
「相談しただけなのに、見解ではなくアクションまで一気に進んでしまう」は、私も使っていて何度か遭遇しました。能力の高いモデルほど「気を利かせすぎる」という副作用ですね。
6. サブエージェントを積極的に使う
Fable 5 は従来より積極的にサブエージェントを並列起動します。
利用者もサブエージェントを「たまに使う」のではなく「頻繁に使う」ことが推奨されています。
あわせて、以下のような運用が示されています。
頻繁に使うように指示する
どういうときに仕事を任せるべきかを、あらかじめ明示する
メインのAIは各サブエージェントの完了を待たず、並行して作業を進める
文脈を保持したまま長く働くサブエージェントは、時間もコストも節約できる
サブエージェントを積極的に使うプロンプト（例）
独立して進められるサブタスクはサブエージェントに任せ、その間もあなた自身の作業を続けてください。
サブエージェントが脱線したり、必要なコンテキストが不足しているときは介入してください。
7. メモリシステムを用意する
Fable 5は、過去の実行から学んだ教訓を記録し参照できる環境で特に高い性能を発揮します。
Markdownファイルのようなシンプルな形式でAIにメモを書き留めさせて、それを記録・ナレッジとして活用します。
メモリを残すプロンプト（例）
教訓は1ファイルに1つずつ保存し、冒頭に1行のサマリーを付けてください。
指摘された修正も、うまくいくと確認できたやり方も、「なぜ重要だったのか」とあわせて記録してください。
リポジトリやチャット履歴にすでに残っていることは保存しないでください。
同じ内容のメモを重複して作らず、既存のメモを更新してください。誤りだとわかったメモは削除してください。
これまでのチャット履歴からメモリを作成するためのプロンプトも紹介されています。
チャット履歴をメモリ化するプロンプト（例）
これまでのセッションを振り返ってください。
サブエージェントを使って主要なテーマと教訓を抽出し、[X] に保存してください。
今後の作業で [X] を参照することを忘れないようにしてください。
メモリの活用自体は私もFable 5以前から取り組んでいますが、とても有効なやり方です。
戦略、方針、壁打ちした内容など、これから先の作業に関わるやりとりは記録して使用させると、アウトプットの質が格段に上がります。
Fable 5だとさらに高い性能を発揮するとのことで、楽しみな変化の一つです。
8. 「依頼」だけでなく「理由」を伝える
Fable 5は、依頼の背後にある意図を理解すると性能が上がります。背景情報があることで、タスクを関連情報に自ら結び付けられるようになり、意図を推測する無駄がなくなるためです。
長時間稼働するエージェントでは特に効果的とされています。
理由・背景を伝えるプロンプト（例）
私は［誰のため］に［より大きなタスク］に取り組んでいます。
相手には［アウトプットで実現したいこと］が必要です。
これを踏まえて、［依頼内容］をお願いします。
私も試してみたところ、確かに出力の的確さが変わるのを感じました。特に、資料作成のように「正解が1つではない」仕事ほど効きます。
一番手軽で、Fable 5時代に意識したいプロンプト原則ではないでしょうか。
ここまでお読み頂き、ありがとうございました！
原則が変わるタイミングでいちばん先を行けるのは、いち早く取り入れて自分の手で試した人です。
幸い、公式ガイドには原則がそのまま使えるプロンプトの形で載っているので、今日からコピペで試せます。
プロンプトや8つの原則をまとめたガイドブックは、以下から無料でダウンロードできます。
プロンプトの作成や改善に課題を感じている方は、私たちが提供しているプロンプト作成アシスタント「connon」も使ってみてください。
セブン&アイホールディングスなど、エンタープライズ企業で導入されているプロダクトです。
仕事・企業で使えるClaudeの情報は以下マガジンにまとめています。
合わせてお読みください。よろしければフォローお願いします。
