深掘り · 小互の解説

Claude Fable 5 実践ガイド:8つの「未知を見つける」プロンプトパターン、盲点スキャンから読了後の小テストまで

Claude Code チームの Thariq Shihipar による大会講演の実録 —— 新モデルのボトルネックはもはやモデル自体ではなく、あなたが自分の未知をどれだけ明確に語れるかにある
要点
  • Anthropic の Claude Code チームメンバー Thariq Shihipar が AI Engineer World's Fair で講演「A Field Guide to Fable」を行い、同日に公式ブログも公開した。報道によれば3日間で閲覧数は約200万に達した。
  • 核心の方法論:「自分が何を知っているか」を四象限に分ける —— 既知の既知、既知の未知、未知の既知、未知の未知。これらの「未知」を減らし、あらかじめ計画することが、新世代モデルを使いこなす核心スキルだ。
  • 講演では、そのまま真似できる8つのプロンプトパターンが示され、着手前・着手中・着手後で整理されており、それぞれに日本語・英語の実例 prompt が付いている。
  • 直感に反する一次情報の開示:Claude Code のシステムプロンプトは最近80%削られた。新モデルにとって、例はかえって足かせになる。方向性は「制約を与える」から「文脈を与える」へと変わった。
  • Thariq はこの方法で、Fable のローンチ動画をゼロから編集し上げた。動画編集は彼にとってまったく未知の領域だった。
立場の注記:これは Anthropic(Claude Code チーム)自身による AI Engineer 大会での講演と、同名の公式ブログであり、自社の Claude Fable 5 の使いこなし方を語る、ベンダー発のコンテンツだ。講演には Fable のベンチマークやアーキテクチャ、ハードな指標はほとんどなく、主体は方法論と社内のプロンプトエンジニアリングに関する一次的な観察である。
1これは何の話か

この講演は結局何を語っているのか

Anthropic の Claude Code チームメンバー Thariq Shihipar が、AI Engineer World's Fair で基調講演を行い、同名の公式ブログ「A field guide to Claude Fable 5: Finding your unknowns」を同時に公開した。

この講演が語るのはとても具体的なことだ:Fable 世代のモデルがどこまでできるか、その頸木はもはやモデル自体ではなくあなたの側に移り、「自分が何を知らないか」をどれだけ明確に語れるかに移った。講演には Fable のハードな指標やアーキテクチャはほとんどなく、全編が「より強いモデルとどう協働するか」だ。
📌
なぜ見る価値があるか:Claude Code のシステムプロンプトは最近80%削られ、方向性は「制約を与える」から「文脈を与える」へ移った。これは Anthropic 社内のプロンプトエンジニアリングの一次的な変化だ。加えて「より強いモデルの使いこなし方」を、そのままコピペできる8つのプロンプトパターンにまとめており、それぞれに実例が付いている。

講演に繰り返し出てくる言葉がある:モデルの解放(unhobbling)。本当にモデルを縛っているのは、多くの場合あなた自身がかぶせた枠組みや、プロンプトを書く際の古い習慣であり、これらの枠組みは本質的に「あなたのモデル理解度」の写像だ。それを改めれば、モデルが元々持っている能力を解き放てる。

たとえるなら

もともと走れる馬から、不要な手綱や目隠しを外してやるようなものだ。

約200万
付随する公式ブログ公開後3日間の閲覧数(報道による)
80%
Claude Code のシステムプロンプトが最近削減された割合。方向は「制約を与える」から「文脈を与える」へ
8つ
講演がまとめた、そのままコピーして使えるプロンプトパターンの数
完全版の講演 · 中国語・英語字幕(約19分、サムネイルをクリックで読み込み) · 元動画 YouTube 英語 ↗
2背景 · プロンプトは引き算

モデルは「尖った形」で賢くなる、だからプロンプトはむしろ引き算すべき

この世代のモデルが「例は少なく、文脈は多く」である理由を理解するために、まず2つの背景を見よう。この節は前置きで、要点は後にある。

1つ目の背景は能力の張り出し(capability overhang):モデルは横並びで強くなるのではなく、特定のタスクで突然一段飛び抜ける。ネットで話題になった投稿に「なぜ大規模モデルは名前が AW で終わるポケモンを言えないのか」というものがあった。普通のチャットモデルは答えられない、全ポケモンの名前を明らかに知っているにもかかわらず。だが Claude Code は答えられる。各ポケモンを取ってきて、AW で終わるものを絞り込むスクリプトを書くからだ。同じ「知識」でも、コード実行ツールを与えるかどうかで結果は天と地ほど違う。

たとえるなら

地下に深さの異なる鉱脈が埋まっているようなもので、ツールはどの鉱脈まで掘れるかを決めるつるはしだ。新モデルを使いこなす労力の半分は、いま一体どんな新しい可能性があるのかを見極めることにある。

2つ目の背景はさらに直感に反する:システムプロンプトはどんどん小さくなっている。Thariq はプロンプトエンジニアリングのベストプラクティスを3段階に分けており、傾向が見て取れる。

Sonnet 3.5 New 時代
小さいプロンプト · 少ないツール
主に大量の例を積んで、その通りにやらせていた。
モデルが強くなった後
大きいプロンプト · 多いツール
より多くの情報と指示を詰め込め、指示通りに実行し始めた。例は相変わらず積む。
Fable のこの世代
システムプロンプトを80%削減
例はかえって足かせになる。モデルの方が、あなたが与える例より想像力豊かだ。文脈を与え、制約は与えず、「これをするな」はできるだけ書かない。

ツールもモデルの能力とともに進化している。ask-user-question ツール(計画段階でモデルが逆に選択式の質問をあなたに投げかける)を例に取ると:Opus 4 の頃はかろうじて呼び出せる程度、Opus 4.5 では「要件について40個質問して」と頼め、あなたをインタビューし始めた。Opus 4.8 と Fable になると、質問を埋め込んだ HTML レポート一式を直接生成できる。モデルを理解することは、むしろ生物学に近い。経験的で有機的で、あなたが直感を築いていく必要がある。