Fable 5は調べ物AIではない。限定時間で本当に試すべきだった20のこと

Fable 5を限られた時間で使うなら、「調べて」より「この材料で、最後まで形にして」と頼むべきだった。

Fableを試せる機会があり、多くの人が一斉に使っていた。
自分も見ていて感じたのは、Fableの魅力は「賢く考えること」より、「長い作業を最後まで進めること」にある、という点だった。

相談する。
壁打ちする。
スキル磨きに使う。
情報収集を頼む。
短い文章を書かせる。

もちろん、どれも悪くない。
ただ、それだけだとFableでなくてもよい場面が多い。

Fableの本質は、材料を読み、作業を分け、実行し、確認し、直すところにある。
つまり、百科事典ではなく、実行担当者に近い。

この記事では、限定時間でFableを使えるなら何を試すべきだったのかを整理する。
具体的な事業名、サイト名、会社名、競合名、数値は出さない。
あとから自分の仕事へ置き換えられる形にする。

Fable 5をめぐる反応は大きく分かれた

Fable 5の無料・限定利用で起きたことは、単なる新モデル祭りではなかった。
むしろ、高性能AIを前にしたとき、多くの人がまだ「質問する」「相談する」「試す」という使い方に寄ってしまうことが見えた出来事だった。

ここは、事実と反応を分けて見たい。

公式情報として、AnthropicはFable 5を長時間・複雑な作業、自律的なタスク遂行、自己検証に強いモデルとして紹介している。
報道ベースでは、Business Insiderが、Pro、Max、Team、Enterprise系の有料ユーザー向けに、2026年7月7日まで週使用上限の一部でFable 5を試せる限定提供があったと報じている。
このあたりは、公式ページや報道で確認できる情報だ。

一方、X上で見えていた反応は、もう少し生々しい。
ただし、個別投稿を事実として扱うのではなく、「そういう受け止めが見られた」という観察にとどめる。

1つ目は、「Fableをチャットボット扱いするのはもったいない」という反応。
質問に答えさせるだけではなく、長いタスクを走らせるモデルとして見るべきだ、という声があった。
これはこの記事の中心主張に近い。

2つ目は、Skill作成やAI社員づくりに使う反応。
教材、メモ、知識ベース、社内ナレッジのような材料を読ませ、自分仕様のAIや作業の型を作る方向だ。
これはFableの自律性を活かす使い方ではある。
ただ、時間制限がある状態では、知識ベース作りだけで使い切るリスクもある。
まずは「仕組みを作る」より、「いま手元にある材料から成果物を出す」ほうがよかったのではないか。

3つ目は、小さな自動化や情報整理の仕組みを作った反応。
X上では、要約、配信補助、業務支援ツールのような小さな自動化に使った例も見られた。
ここから分かるのは、Fableは「何かを聞く」より、「何かを作らせる」ほうが手応えを感じやすいということだ。

4つ目は、「正直そこまで圧倒的ではなかった」という反応。
これも自然だと思う。
普通に質問するだけなら、Fableの差は見えにくい。
相談や壁打ちだけなら、他の高性能AIでもかなりできる。

Fableを使って肩透かしを感じた人がいたとしたら、それはFableが弱かったからではなく、Fableに渡した仕事が短すぎたのかもしれない。

高性能AIの差は、1問1答では見えにくい。
差が出るのは、材料を読み、矛盾を見つけ、手順に分解し、最後まで形にするような長いタスクを任せたときだ。

Fableは検索係ではなく実行係として見る

Fableに調べ物をさせることはできる。
でも、限定時間で使うなら、そこに一番重い力を使うのは少しもったいない。

検索する。
ページを読む。
要約する。
関係ありそうな情報を抜く。

ここまでで時間もトークンも使う。
しかも、検索結果の良し悪しに成果が引っ張られる。

それよりも、調査は先に済ませる。
メモ、既存資料、画面、アクセスデータ、顧客の声、過去のやり取りを集める。
そのうえでFableに渡す。

Fableに検索からやらせるのは、高性能な職人に材料の買い出しから頼むようなものだ。
本当に任せるべきなのは、材料が揃ったあとの設計、組み立て、検証、改善だった。

「何を知っているか」ではなく、「材料からどこまで進められるか」。
そこにFableの使いどころがある。

肩透かしになりやすい使い方

Fableを試すとき、多くの人はまず能力を見たくなる。

• 何ができるか聞く
• 普通に相談する
• プロンプトを考えさせる
• スキルアップの壁打ちに使う
• 情報収集から全部やらせる
• 単発の記事や文章を書かせる

これは自然な試し方だ。
新しいAIを触るとき、まず話してみたくなる。

ただ、この使い方だと「少し賢いチャット」で終わりやすい。
短い相談なら通常のAIでもかなりできる。
軽い言い換えや要約なら、安いモデルでも足りる。

Fableで試すべきだったのは、もっと終わりのある作業だった。

たとえば、複数ページの矛盾を洗い出す。
手元のデータを見て、改善順を決める。
サービス紹介文を読み、説明不足をタスク化する。
海外ユーザー向けの表現に違和感がないか見る。
長い資料を、次に動けるチェックリストへ変える。

こういう仕事は、一問一答では終わらない。
読む、分ける、直す、確認する、もう一度直す。
その流れがある。

公式説明でもFableは長い作業向け

Anthropic公式は、Fable 5を「最も難しい知識労働とコーディング問題」のための次世代モデルとして説明している。
Fable 5のモデルページでは、野心的で長く走るプロジェクト向けであり、thorough、proactive、tests its own work と説明されている。
さらにClaude CodeやClaude Managed Agentsのようなエージェント環境では、段階的に計画し、サブエージェントへ分担し、自分の作業を確認しながら数日単位で働ける、と書かれている。
参照元はAnthropic公式のClaude Fableだ。

発表記事でも、Fable 5とMythos 5は以前のClaudeモデルより長く自律的に働けると説明されている。
長く複雑なタスクほど、他モデルとの差が大きくなる、という書き方もある。
参照元はAnthropic公式のClaude Fable 5 and Claude Mythos 5。

ここから見ると、Fableは「その場で気の利いた答えを出すAI」だけではない。
むしろ、長い仕事を崩さず進めるためのAIとして見るほうが自然だ。

AIエージェント全体の流れも同じ方向にある。
たとえば、スプレッドシート自動化の研究「SheetMind」は、Manager Agentが複雑な指示をサブタスクに分け、Action Agentが操作へ変換し、Reflection Agentが元の意図と合っているかを確認する構成を取っている。
単なる会話ではなく、分解、実行、検証の組み合わせだ。
参照元はarXivのSheetMind: An End-to-End LLM-Powered Multi-Agent Framework for Spreadsheet Automation。

Fableを活かすなら、この流れに乗せたほうがいい。

Fableを使う前に材料をそろえる

Fableに丸投げする前に、人間側で準備したほうがいいものがある。

材料があるほど、Fableは「調べる時間」より「仕上げる時間」に力を使える。
そして、人間は最後の判断に集中できる。

Fableにやらせるべきだった20のこと

ここからは、Fableに頼むなら何がよかったのか。
実務が特定されない範囲で、20個に分ける。

1. 手元の資料をもとに改善点を洗い出す

集めたメモやページを渡し、「どこを直すべきか」を出してもらう。
感想ではなく、実行できるタスクに分けるのがコツ。

2. 複数ページの矛盾や抜けを見つける

同じ説明なのに言い方が違う。
あるページには書いてあるのに、別ページにはない。
こういうズレは人間が見落としやすい。

3. ユーザー目線で導線を確認する

初めて来た人が、次にどこへ進むか。
迷う場所、戻りたくなる場所、説明が足りない場所を出してもらう。

4. 比較対象との差分を整理する

固有名を出さなくても、比較メモは作れる。
表現、価格感、見せ方、信頼材料、よくある不安への答え方を並べる。

5. 説明不足の箇所を見つける

作っている側には当たり前でも、読む側には飛躍に見える部分がある。
Fableには、その飛躍を探させる。

6. 文章のAIっぽさを検出する

「自然なようで薄い」言い回しを抜く。
言い換えだけでなく、なぜ弱いのか、どう直すかまで出す。

7. 長い記事を構造化し直す

長くなった記事を、読者の疑問順に並べ直す。
削る場所、残す場所、別記事に分ける場所も整理する。

8. FAQ候補をまとめる

顧客の声や検索メモから、FAQを作る。
ただし、答えられない質問は「人間確認」に分ける。

9. 数字をもとに優先順位をつける

アクセスや反応のデータを渡し、どこから直すか決める。
数字だけでなく、作業量とリスクも一緒に見る。

10. LPやサービス紹介文を改善する

いきなり美文にしない。
誰向けか、何が不安か、どこで止まるかを先に出す。
その後で文章を直す。

11. 多言語表現の違和感を確認する

直訳っぽい表現、現地の人に伝わりにくい表現を探す。
意味が変わる場所は、人間判断に戻す。

12. 画像やデザインの伝わり方を確認する

画像が何を伝えているか。
文章と合っているか。
見た瞬間に誤解されないか。
スクリーンショットを渡して確認する。

13. 作業手順をチェックリスト化する

毎回やる確認を、順番に並べる。
抜けやすい項目、止める条件、最後に人間が見る場所を入れる。

14. 他のAIに渡す指示書を作る

Fableで全部やらない。
安いAIや通常モデルへ渡せる作業は、指示書にして分ける。

15. 失敗しそうなポイントを先に出す

公開前、送信前、提出前に危ない場所を出す。
思い込み、古い情報、未確認の断定、表現のズレを見つける。

16. 本番前の確認項目を作る

リンク、表示、表記、画像、引用、権利、公開範囲。
最後に見る項目を短くまとめる。

17. 1週間分の実行計画に落とす

大きな改善案を、今日、明日、今週に分ける。
「いつかやる」ではなく、実行順にする。

18. 作業ログをレポートにする

何を見たか。
何を直したか。
何を保留したか。
次に誰が判断するか。
ログを読み返せる形にする。

19. 人間が判断すべき部分を分ける

AIに任せるほど、最後の判断点が大事になる。
採用、保留、削除、公開、ブランド表現は人間側に戻す。

20. 高性能AIに任せる仕事と安いAIで十分な仕事を分ける

全部をFableに投げない。
構造化、判断、検証、複数資料の統合はFable向き。
単純な言い換え、短い要約、軽い下書きは別のAIで十分なことが多い。

Fableに任せなくてもいいこと

高性能だから、何でも任せればいいわけではない。

• 単純な検索
• ただの要約
• 軽い言い換え
• 短い文章作成
• 明確な正解がある作業
• 安いモデルや通常のAIで十分な作業

Anthropic公式の価格表示では、Fable 5はAPIで100万入力トークンあたり10ドル、100万出力トークンあたり50ドルと説明されている。
同じページでは、Fableには30日間のデータ保持が必要とも書かれている。
さらに、サイバーセキュリティ、バイオロジー、化学など一部領域では、保護機能によりOpus 4.8へ切り替わる場合がある。
参照元はAnthropic公式のClaude Fableと発表記事。

だから、使いどころを絞るほうがいい。
Fableには、単純作業ではなく、判断と構造が必要な仕事を渡す。
長く、複雑で、最後に成果物が残る仕事を渡す。

Fableに投げるならこう依頼する

材料を渡す前提なら、依頼文はこうなる。

文章を直したいなら、こうする。

ポイントは、最初から「成果物の形」を決めることだ。

ただ相談するのではなく、最後に何を残すかを決める。
改善リストなのか。
修正案なのか。
チェックリストなのか。
一週間の実行計画なのか。
他のAIへ渡す指示書なのか。

終わりがあるほど、Fableは走りやすい。

最後は人間が選ぶ

Fableに任せるのは、整理、実行、検証、改善だ。

でも、何を採用するか。
何を捨てるか。
どの言葉を自分たちの表現として選ぶか。
どこまで公開するか。

ここは人間が判断する。

Fableに考えさせる、というより、Fableに走らせて人間が選ぶ。
この距離感がちょうどいい。

AIが長い作業を進めるほど、人間の役割は消えない。
むしろ、最後の選択が濃くなる。

「この材料で最後まで形にして」と頼む

Fableを限定時間で使うなら、調べ物に使うのはもったいない。

調査は他で済ませる。
材料を渡す。
目的を決める。
終わりのある作業にする。
Fableには最後まで走らせる。
そして最後に人間が判断する。

Fableは、百科事典ではなく、実行担当者に近い。
だからこそ、頼むべき言葉は「調べて」ではなかった。

「この材料を使って、最後まで形にして」

短い時間しか使えない高性能AIほど、この頼み方の差が出る。

参考資料