はじめに

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と共に新しい価値を創造していく。そんなマインドセットへのアップデートが、今まさに求められているのだと感じました。