「Fable 5はすごいらしい。で、実際の仕事ではどう頼めばいいのか」。だいたい、ここで止まります。短い質問なら、これまでのやり方で足ります。困るのは、調査、資料作成、コードのレビュー、業務の設計。数十分から数時間かかる仕事を任せるときです。
公式ドキュメントを読むと、Fable 5向けのプロンプト設計は「丁寧にお願いする」話ではありませんでした。作業の難易度、どこまで粘るか、止まる条件、進捗の根拠、担当の分け方、記録の残し方、そして安全の線。仕事の依頼書に近づいています。
先にまとめ
長い仕事を任せるなら、書くのは4つです。どこまで粘るか（effort）、どこで止まるか、進捗を何で報告させるか、記録をどこに残すか。特に効くのは2つめと3つめ。「できました」ではなく「何を読んで、何を実行したか」で報告させると、確認の手間がはっきり減ります。
調査・資料作成・開発・業務改善などの長めの仕事にAIを使いたい方に向けた内容です。APIのパラメータ一覧を確認したい方には向きません。
一問一答ではなく、長い仕事を前提に考える
公式では、Fable 5は複雑で長く、曖昧さのある仕事に向いていると説明されています。人が数時間、場合によっては数日かけるような、最初から最後までの仕事で力を出す、という位置づけです。
だとすれば、「この文章を要約して」だけでは足りません。仕事の範囲、使ってよい資料、途中で確認する条件、最後の検証方法。ここまで書いておくと、AIは迷いません。人に頼むときと、まったく同じです。
逆に言えば、短い依頼で済ませているうちは、高性能モデルの持ち味は出ません。プロンプトが短いから悪いのではなく、任せている仕事が小さいだけです。
最初に決めるのは、粘り方と止まる条件
effort は、能力と待ち時間と費用の釣り合いを決める主なつまみとして説明されています。多くの仕事では high、正確さを最優先する仕事では xhigh、定型作業なら medium や low も選択肢になる、という案内です。
ここで大事なのは、常に最大にすればよいわけではないことです。高い設定は検証や粘り強い推論に効きますが、簡単な仕事では文脈を集めすぎたり、頼んでいない整理まで始めたりします。丁寧すぎる新人と同じで、時間だけが延びます。
アクセルを踏むなら、ブレーキも書く
「顧客へ送る前に止まる」「公開前に人の確認を待つ」「出典が取れない数字は使わない」。この3行を足すだけで、任せられる範囲が広がります。プロンプトはアクセルだけの文章ではなく、ブレーキも含めた依頼書です。
止まる条件を書いていない依頼は、結局こちらが張り付いて見ることになります。任せた気になって、実は監視しているだけ。それでは楽になりません。
進捗は「実行結果」で報告させる
長い作業で怖いのは、「できました」と言われているのに、実際には確かめていない状態です。公式では、実際の実行結果に照らして進捗を点検させると、作り話のような進捗報告がほぼ無くなった、と説明されています。
現場でもそのまま使えます。「進んだ感じ」ではなく、何を読んだか、何を実行したか、どのファイルを作ったか、どのテストが通ったか。この形で書かせます。
- check_circle確認したURL・ファイル・ログを具体名で書く
- check_circle「完了」は、実行結果か読み戻しがあるものだけに使う
- check_circle未確認の数字・日付・固有名詞は、未確認として分けて出す
- check_circle人が判断することを1〜3個に絞って最後に置く
4つめが地味に効きます。判断を求められる箇所が10個あると、結局こちらが全部読み直すことになる。3個までに絞らせると、報告がそのまま意思決定の場になります。
長い資料は、上に資料、下に質問
これはFable 5に限らない原則です。公式では、長い資料を扱うとき、資料をプロンプトの上に置き、質問や指示を後ろに置くよう勧めています。複数の文書を扱う場合、質問を最後に置くだけで、回答の品質が最大30%改善した例もあると説明されています。
複数の資料を渡すときは、タグで区切って「これは資料」「これは出典」「これが指示」と分けます。難しく見えますが、やっていることは封筒にラベルを貼るのと同じです。
順番を変えるだけ、ラベルを貼るだけ。それで返ってくるものが変わるなら、試さない理由はありません。
担当を分ける。記録を残す
Fable 5は、作業を分身に振り分けたり、長く動く分身とやり取りしたりする点が強くなったと説明されています。会社の仕事に置き換えると、1人に全部を抱えさせず、調査係、検証係、文章係に分ける発想です。
もう1つが記録です。公式は、過去の実行から学んだことをファイルに残し、次回参照する仕組みを勧めています。ここに顧客情報や秘密を入れないでください。残すのは、手順、判断の基準、つまずきやすい点。この3つで十分です。
記録が溜まると、次の依頼が短くなります。前提を毎回書かなくてよくなるからです。長いプロンプトを書き続けている人ほど、この効果は大きくなります。
内部の思考ではなく、根拠を求める
安全の線引きにも触れておきます。公式情報では、攻撃的なセキュリティ、生命科学、そして内部の思考をそのまま取り出そうとする依頼が、制限の対象になり得ると説明されています。データの保持条件にも決まりがあります。
実務で大事なのは、「考えていることを全部見せて」と求めることではありません。根拠、実行の結果、未確認の事項、人が見るべき箇所。この4つを出してもらう。透明性は十分に確保できますし、そのほうが読む側も速い。
今日から使える雛形
最後に、長い仕事を任せるときの雛形を置いておきます。作業内容だけでなく、確認方法と止まる条件まで入れるのが要点です。
【目的】この作業のゴールを1文で 【使ってよい資料】ファイル名・URLを列挙（それ以外は使わない） 【進め方】調査 → 整理 → 下書き → 自己点検の順で 【報告の形】 - 読んだもの、実行したものを具体名で - 「完了」は結果を確認できたものだけ - 未確認の数字・日付・固有名詞は分けて書く - 人に判断してほしいことを3つまで 【止まる条件】 - 社外に出す直前 - 金額・契約・個人情報に触れるとき - 出典が取れない数字を使いそうなとき
そのまま貼って使えます。目的の1文と、使ってよい資料の指定だけ、自社のものに書き換えてください。
まとめ：プロンプトは、依頼書に近づいた
長ければ良いわけではありません。目的、使ってよい情報、止まる条件、確認方法。この4つが書けているかどうかです。うまい言い回しを探すより、決めていないことを決めるほうが先でした。
冒頭の「実際の仕事ではどう頼めばいいのか」に短く答えると、こうなります。人に頼むときと同じように書く。ただし、止まってほしい場所だけは、人に頼むときより丁寧に。
参考: Prompting Claude Fable 5 ／ Claude prompting best practices ／ Introducing Claude Fable 5 and Claude Mythos 5（Claude Platform Docs / 2026年8月28日確認）
AI活用を、業務の流れに合わせて設計したい方へ
i-Styleでは、AIツールの使い方だけでなく、社内ルール、プロンプトの型化、確認フロー、業務自動化の裏側まで含めて、現実的な導入を支援しています。
お問い合わせページへarrow_forward
