※お役に立てたらストック、いいねをよろしくお願いします！！
＜📝本記事のターゲット層＞
- Claude Fable 5の特徴を短時間で把握したい生成AI初心者
- Claude向けのプロンプトを作成・改善したいエンジニア
- 調査や開発などの長時間タスクをAIエージェントに任せたい人
- 既存のClaude向けプロンプトをFable 5へ移行したい人
🔷Claude Fable 5とは？長期的なエージェント作業に強いモデル
Claude Fable 5は、Anthropicが2026年6月9日に一般提供を開始した、複雑な推論や長期的なエージェント作業向けのモデルです。モデルIDは claude-fable-5 です。
これまでの生成AIは、質問を入力して回答を受け取る「一問一答」の使い方が中心でした。一方、Claude Fable 5は、調査、設計、実装、検証といった複数の工程を、一連の仕事として任せる使い方を想定しています。
たとえば、次のようなタスクです。
- 大量の仕様書とソースコードを読み、変更箇所を特定する
- 実装方針を考え、コードを修正し、テスト結果まで確認する
- 複数の資料を調査し、根拠付きのレポートを作成する
- 大きな作業を複数のエージェントへ分けて進める
- 画像や文書を含む資料から、業務用の成果物を作成する
つまり、単に「答えを教えてくれるAI」ではなく、目的と作業条件を渡して仕事を任せるAIとして捉えると分かりやすいです。
🔹大きなコンテキストと長い出力に対応
Claude Fable 5は、デフォルトで100万トークンのコンテキストウィンドウを持ち、最大128kトークンの出力をサポートしています。
コンテキストウィンドウとは、モデルが1回の処理で参照できる情報量のことです。これが大きいほど、多数の仕様書、長い議事録、大規模なコードベース、過去の作業記録などをまとめて扱いやすくなります。
ただし、読み込める情報量が多いことと、依頼が正確に伝わることは別です。大量の情報を渡しても、目的や完了条件が曖昧であれば、モデルは「どこまで調べるのか」「何を成果物とするのか」を独自に判断することになります。
Claude Fable 5の能力を活かすには、情報量を増やすだけでなく、仕事のゴールと境界線を明確にすることが重要です。
🔹自律性が高いからこそ、やりすぎにも注意する
Claude Fable 5は複雑な依頼を自律的に進められる一方、依頼者が想定していない範囲まで作業を広げる場合があります。
たとえば、ログイン画面の不具合修正を依頼しただけなのに、周辺コードのリファクタリング、新しい共通部品の作成、将来の機能追加を想定した抽象化まで行うケースです。変更自体が技術的に正しくても、レビュー範囲やテスト範囲が広がり、かえって導入しづらくなることがあります。
そのため、プロンプトには次のような境界線を入れておくと安心です。
- 問題の修正に必要なファイルだけを変更してください
- 関係のないリファクタリングは行わないでください
- 将来の仮想的な要件に備えた機能追加は不要です
- 既存の設計パターンを優先してください
高性能なモデルへ細かな手順をすべて命令する必要はありません。しかし、何をしてよいかと同じくらい、何をしないかを伝えることが大切です。
🔷Claude Fable 5向けプロンプトに必要な5つの要素
Claude Fable 5向けのプロンプトでは、操作手順を何十個も並べるより、AIが判断するための条件を整理するほうが実践的です。
基本となるのは、次の5要素です。
| 要素 | 書く内容 | 例 |
|---|---|---|
| 目的 | なぜ作業するのか | 初回利用者の離脱を減らしたい |
| 成果物 | 最終的に何を出すのか | 改善案をMarkdownの表で出す |
| 範囲 | やること・やらないこと | UIは対象、認証方式は対象外 |
| 完了条件 | どの状態で終了するのか | 3案を比較できれば完了 |
| 検証方法 | 何を根拠に正しさを確認するのか | 公式資料やテスト結果で確認 |
🔹1. 目的を書く
最初に、何のための作業なのかを伝えます。目的が分かると、モデルは複数の選択肢から適切なものを選びやすくなります。
たとえば「ログイン画面を改善する」だけでは、デザインを変えたいのか、エラーを減らしたいのか、登録率を高めたいのかが分かりません。
初回利用者がログイン方法に迷って離脱する割合を減らすために、
ログイン画面のUX改善案を作成してください。
このように目的を加えると、見た目だけではなく、入力項目、説明文、エラー表示など、初回利用者の迷いに関係する要素へ焦点を当てられます。
🔹2. 成果物を書く
成果物では、最終的に何を受け取りたいのかを指定します。形式、対象読者、分量、粒度を必要に応じて書きましょう。
成果物:
- 改善案は3つまで
- Markdownの表で整理する
- 各案に期待効果、実装コスト、リスクを含める
- 専門知識のない企画担当者にも分かる表現にする
「調査してください」だけでは、調査メモ、長い報告書、箇条書きの結論など、さまざまな出力が考えられます。成果物を具体化すると、出力後の手直しを減らせます。
🔹3. 範囲を書く
範囲では、作業に含める内容と、含めない内容を分けて書きます。
範囲:
- 対象: 画面構成、入力項目、説明文、入力エラー表示
- 対象外: 認証方式の変更、データベース設計、コードの実装
この指定がないと、モデルが改善に必要だと判断した領域まで調査や提案を広げる可能性があります。特にコード変更を伴うタスクでは、対象ファイルや変更してよい機能を明記しておくのがおすすめです。
🔹4. 完了条件を書く
完了条件は、モデルが作業を終える判断基準です。長時間タスクでは特に重要になります。
完了条件:
- 現状の課題が整理されている
- 改善案が3つ以内に絞られている
- 各案の効果、実装コスト、リスクを比較できる
完了条件がない場合、追加調査を続けたり、逆に最低限の回答だけで終了したりする可能性があります。「何を満たせば終わりなのか」を書くことで、作業量と成果物の品質を調整できます。
🔹5. 検証方法を書く
最後に、回答や作業結果を何で確認するのかを指定します。
調査タスクなら公式ドキュメント、開発タスクならテストや静的解析、データ処理なら件数やサンプル結果などが検証材料になります。
検証:
- 仕様に関する主張は公式ドキュメントを優先する
- コード変更後は既存テストを実行する
- テストできなかった項目は、未確認として明記する
- 推測と確認済みの事実を分けて記載する
検証方法を書く目的は、モデルへ「絶対に正しい回答を出して」と頼むことではありません。何を確認できて、何を確認できていないのかを見えるようにすることです。
🔷長時間タスクで失敗を防ぐ指示とAPI利用時の注意点
数時間以上かかる調査や開発を任せる場合は、通常の質問とは異なる注意が必要です。特に気をつけたいのが、進捗報告、停止条件、推論設定、安全分類による拒否です。
🔹進捗報告はツール結果と照合させる
長い作業では、「テストが成功しました」「修正は完了しました」という報告が、本当に確認済みなのかを区別する必要があります。
プロンプトに次のルールを追加しておきましょう。
進捗報告のルール:
- 報告内容を、この作業で得たツール結果と照合してください
- 実施していない作業を完了済みとして扱わないでください
- テストが失敗した場合は、失敗した事実と結果を記載してください
- 確認できなかった内容は「未確認」と明記してください
これにより、最終報告を読む人が、確認済みの結果と残っている作業を判断しやすくなります。
🔹停止条件を指定する
自律的に進めてほしいからといって、すべての操作を無条件で許可するのは危険です。削除、外部公開、本番環境への反映など、元に戻せない可能性がある操作では停止させる必要があります。
次の場合だけ作業を停止し、確認してください。
- 破壊的または不可逆な操作が必要な場合
- 当初の依頼範囲を実際に変更する必要がある場合
- ユーザーしか提供できない情報が必要な場合
- 本番環境や外部サービスへ変更を反映する場合
「分からないことがあれば何でも質問してください」と書くと、小さな判断でも作業が止まりやすくなります。反対に「絶対に質問せず進めてください」では、重要な操作まで独自判断される可能性があります。止める条件を具体化することが、両者のバランスを取る方法です。
🔹effortで能力・時間・コストを調整する
Claude Fable 5では、effort が推論能力、処理時間、コストのバランスを調整する主要な手段として説明されています。
用途の目安は次のとおりです。
| 用途 |
effortの目安 |
|---|---|
| 短い要約、文章の言い換え |
low / medium
|
| 一般的な調査や設計相談 |
medium / high
|
| 複雑な設計、長いコードレビュー | high |
| 失敗時の影響が大きい推論や検証 | xhigh |
常に最大設定を使えばよいわけではありません。簡単な処理に高い設定を使うと、必要以上に時間とコストがかかる可能性があります。まずは作業の難しさと失敗時の影響を考え、設定を選びましょう。
🔹生の思考過程ではなく、判断理由を求める
Claude Fable 5ではAdaptive Thinkingが常時有効であり、生のChain of Thought、つまり内部思考をそのまま返す設計ではありません。必要に応じて thinking.display: "summarized" を指定すると、読みやすく要約された思考情報を受け取れます。
プロンプトでも「考えたことを一語一句すべて出してください」と求めるのではなく、次のように依頼します。
最終判断の理由を、ユーザーに説明できる範囲で簡潔にまとめてください。
確認できた根拠、置いた前提、不確実な点を分けて記載してください。
欲しいのは内部思考そのものではなく、結果を評価するための根拠です。判断理由、前提、不確実性が分かれば、レビューにも十分活用できます。
❓困ったときは：HTTP 200なのに回答が得られない
Claude Fable 5では、依頼内容によって安全分類器による拒否が発生する場合があります。対象になり得るのは、一部の攻撃的サイバーセキュリティ、生命科学、モデルの思考抽出に関係する依頼などです。
注意したいのは、拒否が通常のAPIエラーとして返るとは限らない点です。HTTPステータスが200でも、レスポンス内の stop_reason が "refusal" になる場合があります。
アプリケーション側では、HTTPステータスだけで成功を判断せず、少なくとも次の値を確認してください。
stop_reason: "refusal"
拒否を受けた場合は、分類器を回避しようとするのではなく、依頼の目的と範囲を見直します。正当な防御目的の作業であれば、対象システム、許可された範囲、期待する防御的成果物を明確にすることが重要です。
🔷そのまま使えるClaude Fable 5向けプロンプトテンプレート
ここまでの内容を、実務で使いやすいテンプレートにまとめます。すべての項目を長く書く必要はありません。モデルが判断に迷いそうな部分を具体化してください。
私は [目的・背景] のために、[作業内容] をしたいです。
以下を満たしてください。
1. 成果物
- [出してほしい形式]
- [対象読者]
- [分量や粒度]
2. 範囲
- やること: [含める内容]
- やらないこと: [不要な内容、禁止事項]
3. 進め方
- 情報が十分なら、そのまま作業してください
- 本当に必要な確認事項だけ質問してください
- 判断に迷う場合は、推奨案を1つ選んで進めてください
4. 完了条件と検証
- [完了と判断する条件]
- 事実は根拠を示してください
- 不確かな点は不確かと明記してください
- 実際に確認した結果だけを完了済みとして報告してください
5. 出力
- 最初に結論
- 次に重要な根拠
- 最後に残課題または次のアクション
🔹コードレビュー向けの記入例
テンプレートをコードレビューへ適用すると、次のように書けます。
このリポジトリをレビューしてください。
目的:
本番投入前に、重大なバグ、設計ミス、セキュリティ上の懸念を見つけるためです。
成果物:
- Markdown形式
- 重要度の高い指摘から並べる
- 各指摘に影響、根拠、修正案を含める
範囲:
- 本番障害につながる問題を優先する
- スタイル修正や好みによるリファクタリングは行わない
- 仕様が不明な箇所は断定せず、仮説として記載する
進め方:
- まず全体構成を把握する
- 次に重要な処理を深掘りする
- 必要に応じてテストを実行する
完了条件と検証:
- 指摘には該当ファイルや確認結果を添える
- 確認できなかった内容は未確認と明記する
- 指摘がない場合も、残っているリスクや未実施のテストを書く
この例では、「レビューする」という作業だけでなく、優先順位、不要な作業、指摘の形式、確認できなかった場合の扱いまで指定しています。そのため、表面的なスタイル指摘ばかりになることを防ぎ、本番への影響が大きい問題へ集中しやすくなります。
💡Tips：タスクの大きさに合わせて項目を減らす
短い文章の要約に、毎回5項目すべてを詳しく書く必要はありません。
たとえば、日常的な要約なら次の程度でも十分です。
この文章を、プロジェクトの状況を知らない上司向けに要約してください。
結論、現在の問題、必要な判断の順に、300文字以内でまとめてください。
本文にない内容は推測で補わないでください。
反対に、複数ファイルの変更や外部サービスとの連携を含む作業では、範囲、完了条件、検証方法、停止条件を詳しく書きます。
大切なのはテンプレートを機械的に埋めることではありません。AIが仕事を進めるうえで、どこを独自判断してよいかを設計することです。
✅まとめ：Claude Fable 5には手順ではなく仕事の条件を渡す
Claude Fable 5は、複雑な推論と長期的なエージェント作業に向いたモデルです。大量の情報を参照しながら、調査、設計、実装、検証をまとめて進める用途で力を発揮します。
一方、自律性が高いからこそ、曖昧な依頼では不要な変更や過剰な調査まで進める可能性があります。プロンプトでは、次の5要素を意識しましょう。
- 目的：何のための作業か
- 成果物：何を、どの形式で出すか
- 範囲：何を行い、何を行わないか
- 完了条件：どの状態になれば終了か
- 検証方法：何を根拠に結果を確認するか
長時間タスクでは、進捗をツール結果と照合し、未確認事項やテスト失敗を正直に報告させることも重要です。APIから利用する場合は、作業に応じた effort の選択、thinking.display: "summarized"、stop_reason: "refusal" の扱いも確認してください。
最初から完璧なプロンプトを書く必要はありません。まずは本記事の基本テンプレートへ目的と成果物を記入し、モデルが迷いそうな部分に範囲、完了条件、検証方法を追加してみましょう。
🔹参考URL
- Introducing Claude Fable 5 and Claude Mythos 5 - Claude API Docs
- Prompting Claude Fable 5 - Claude API Docs
※お役に立てたらストック、いいねをよろしくお願いします！！