はじめに
AnthropicのThariq Shihipar氏による興味深い講演動画「Fable活用ガイド」を視聴しました。
本記事では、Claudeの能力を最大限に引き出すための具体的なアプローチから、強力なAIツールを手にした私たちが直面する「感情の揺れ」や「マインドセットの変化」まで、動画の要点を分かりやすくまとめます。
1. Unhobbling Claude（Claudeに制限をかけない）
「システムプロンプトを80%も削減できた」
——そんな驚きの事実から動画は始まります。Claudeの真の能力を引き出すには、私たちが無意識にかけている「制限」を取り払う必要があります。
「理解の枠組み」を超える
従来のハーネスやプロンプト設計は、あくまで人間が定義した「理解の枠組み」の中でしか出力を得られません。しかし、これらの制限を取っ払うことで、モデルは枠組みを超えた能力（Capability Overhang）を発揮できるようになります。
プロンプトではなくツールを与える
制限を外すための具体的な手段として、長大なプロンプトで細かく指示を出すのではなく、モデルにツール（Bash, RAG, MCPなど）を与えるアプローチへシフトすべきです。
Before: システムプロンプト(大)、ツール(大)、出力例(大)
After: システムプロンプト(小)、ツール(検索などを持たせる)、出力例(無)
Fableの性質
Fableは物理的（システム的）に制御するものではなく、生物学的（経験的で有機的）に育っていくものとして捉える必要があります。
2. Finding your Unknowns（未知の領域を見つけよ）
Fableに自律性を持たせると、ユーザーが明示的に指定した箇所以外でも
モデルが自ら意思決定を行う場面が増えていきます。
この「穴」を埋め、プロンプトに適切に絡めていくためには、
自分自身の「未知（Unknowns）」を発見しなければなりません。
Fableを使いこなす上で、情報は以下の4つの領域に分類されます。
| 領域 | 状態 | 概要 |
|---|---|---|
| Known Knowns | 既知の既知 | プロンプトに明確に書くことができる要素 |
| Known Unknowns | 既知の未知 | まだ未解決・未決定だと分かっている要素 |
| Unknown Knowns | 未知の既知 | 言葉にしていない暗黙知や、個人の好み |
| Unknown Unknowns | 未知の未知 | 考慮すらしていない、プロンプトの前提を変える要素 |
特に重要な「Unknown unknowns（未知の未知）」を見つけ出すために、
以下のような手法が推奨されています。
-
Blindspot pass（死角のチェック）: Gitの差分やSlackの履歴などを読み込ませて、自分が見落としている死角を探させる
-
Brainstorms and prototypes: デザインなど言葉にしにくい「Unknown」を見つけるため、複数の案やプロトタイプを出させ、隠れた好みや要件を特定する
-
Interview: プロジェクトの背景を伝えた上で、モデル側から「逆インタビュー」をさせる。特にアーキテクチャを変えるような本質的な質問を優先させる
-
Reference: 細かい仕様を文章で起こす代わりに、別言語や別システムのコードを渡したり、HTMLのモックアップを参照させて「地図」として扱わせる
-
Implementation note: FableがUnknownに直面して当初の計画から逸脱した際、その内容をログとして記録させる
-
Quiz: 一連の作業後に、「何がおきたか」をクイズとして出題させる
3. Dealing with the Grief & Being Unreasonable
講演の終盤では、手法やテクニックだけでなく、エンジニア自身の感情やマインドセットについて語られます。
Dealing with the Grief（喪失感との向き合い方）
AIによってコーディングにかける時間が大幅に減少し、多大な恩恵を受ける一方で、私たちは「自らの手で作る楽しさ」を失うことになります。この変化は元には戻らず、この喪失感から抜け出すには「Through（通り抜ける）」しかありません。
Being Unreasonable（非合理になれ）
常識的な妥協を捨てることこそが、Fable時代のマインドセットです。「良い・早い・安い」のトレードオフはもはや存在せず、すべてを取ることができます。Building（設計や実装）は簡単になったからこそ、これからは generating value（価値を生み出すこと） こそが最も重要になります。
作る楽しさの喪失と、新しい価値創造へ
私自身、この「作る楽しさを失う（Grief）」という言葉にはハッとさせられました。
エラーと格闘しながらコードを書き上げる泥臭い楽しさが減ってしまうことへの寂しさは、多くのエンジニアが密かに感じていることだと思います。
しかし「良い・早い・安い」のトレードオフがなくなり、実装のハードルが下がったことで、私たちはより純粋に「どんな価値を生み出すか」にフルコミットできるようになりました。
失うものを嘆くのではなく、「非常識（Unreasonable）」なほどの理想を追求し、AIと共に新しい価値を創造していく。そんなマインドセットへのアップデートが、今まさに求められているのだと感じました。