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

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

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

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

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

核心フレームワーク：あなたの未知を四つのマスに分ける

あなたの頭の中の計画、プロンプト、spec は「地図」だ。実際のコードベースや現実の制約は「領土」だ。Claude が領土の中で地図に記されていないものにぶつかるたび、あなたが本当は何を望むのかを推測して1つの決定を下さねばならない。その地点を1つの「未知（unknown）」と呼ぶ。こなす仕事が多いほど、ぶつかる未知も多くなる。

一つの問題に向き合うとき、「自分が何を知っているか」を四つのマスに分ける。

トップクラスの agentic coder（彼は Boris、Jarred の名を挙げた）には共通点がある：彼らの未知は少なく、彼らの prompt を見ると、コードベースにもモデルの挙動にも精通しているのが伝わる。同時に、彼らは未知が必ず存在すると織り込んでいる。だから未知を減らし、あらかじめ計画することこそ agentic coding という技芸の核心スキルであり、このスキルは「Claude と一緒に練習する」ことで伸ばせる。

なぜ未知への対処が鍵なのか？ Claude に指示を出すのは微妙なバランスで、具体的すぎても曖昧すぎても失敗するからだ。

未知に備えなければ両方で負ける：どの区間に落とし穴があるか分からず（細かくすべき所を細かくしない）、どの区間は実は通れて任せてしまえるかも分からない（手放すべき所を手放さない）。幸い Claude は未知探しを速めてくれる。コードベースもネット全体も検索が極めて速く、失敗からの反復もあなたより速い。最も肝心な一歩は、あなたの「出発点」を渡すことだ：いまどの段階を考えているか、この問題とコードベースにどれだけ経験があるかを伝え、思考のパートナーにする。

以下は実践できる8つのパターンで、着手前・着手中・着手後の3段階で整理してある。各メソッドカードの右上に小さな四象限アイコンがあり、ハイライトされたマスが、その方法が主に対処する未知のタイプだ。各実例 prompt は全て掲載する：日本語は訳文（理解用）、英語は原文（そのままコピーして使う用）。

着手前の2手：盲点スキャン ＋ ブレストとプロトタイプ

着手前にまず解くべき未知は2種類：そもそも思いつかないもの（未知の未知）と、言葉にできないが見れば分かるもの（未知の既知）だ。

"I'm working on adding a new auth provider but I know nothing about the auth modules in this codebase. Can you do a blind spot pass to help me figure out my relevant unknown unknowns and help me prompt you better."

"I don't know what color grading is but I need to grade this video. Can you teach me to understand my unknown unknowns about color grading, so that I can prompt better?"

"I want a dashboard for this data but I have no visual taste and don't know what's possible. Make me an HTML page with 4 wildly different design directions so I can react to them."

"Before wiring anything up, make a single HTML file mocking the new editor toolbar with fake data. I want to react to the layout before you touch the real app."

"Here's my rough problem: users churn after onboarding. Search the codebase and brainstorm 10 places we could intervene, from cheapest to most ambitious. I'll tell you which ones resonate."

着手前のあと3手：インタビューさせる、参照を渡す、実装計画をもらう

ブレストを十分にやっても、たいてい未知はいくつか残る。残り3手で、曖昧さをあぶり出し、より良い地図を渡し、計画で「変える可能性が最も高い決定」を最前に並べさせる。

"Interview me one question at a time about anything ambiguous, prioritize questions where my answer would change the architecture."

"This Rust crate in vendor/rate-limiter implements the exact backoff behavior I want. Read it and reimplement the same semantics in our TypeScript API client."

"Write an implementation plan in HTML, but lead with the decisions I'm most likely to tweak with: data model changes, new type interfaces, and anything user-facing. Bury the mechanical refactoring at the bottom, I trust you on that part."

着手中と着手後：実装ノート、売り込み資料、逆に自分を試させる

計画に満足したら、新しい session を立ち上げ、spec やプロトタイプといった artifacts を渡し、きれいなコンテキストウィンドウを与える。ただし計画段階の情報はすべて携えて。続く3手は、作業の途中と納品の後を担う。

"Keep an implementation-notes.md file. If you hit an edge case that forces you to deviate from the plan, pick the conservative option, log it under 'Deviations', and keep going."

"Package the prototype, the spec, and the implementation notes into a single doc I can drop in Slack to get buy-in. Lead with the demo GIF."

"I want to make sure I understand everything that's happened in this change. Give me a HTML report on the changes for me to read and understand with context, intuition, what was done, etc. and a quiz at the bottom on the changes that I must pass."

生きた教材：彼自身がこの方法を一通り使った実例

Fable のローンチ動画は、Thariq が Claude Code で最初から最後まで編集したものだ。動画編集は彼にとってまったく新しい領域で、専門家ではない。彼のやり方は、上記の方法をちょうど1本の鎖につないでいる。

解説、ブレスト、インタビュー、プロトタイプ、参照 —— そのどれもが「高くつく前」に、元々知らなかったことを安く突き止める手段だ。Thariq Shihipar、A Field Guide to Fable

実践チェックリスト：次のプロジェクトからどう使うか

8つのパターンを着手のタイミング別に1枚のリストにまとめた。照らし合わせて当てはめればいい。

方法を一言で：まず「自分が何を知っているか」を4通りに分け、次にプロンプト（prompt、AI に送る指示）のパターンで、散らばった未知を一歩ずつ「既知」へ移す。そうして初めてモデルは正しくこなす。加えて直感に反する一次的な変化がある —— モデルに与えるプロンプトは、いま引き算されている。

では「未知を見つける」とは具体的にどうやるのか？ 下の図を見よう。

通底する例：小互は自分のコードベースにログイン認証機能を足したいが、この認証モジュールについて何も知らない。頭の中の計画は「地図」、実際のコードベースは「領土」。AI が領土で地図に無いものにぶつかるたび「未知」が1つ増える。未知を「意識しているか × 実際に分かっているか」で四つのマスに分け、方法がやるのは、それらを左上の「既知」へ移すことだ。

著者は自分を生きた教材にした：Fable のローンチ動画は、彼が Claude Code で最初から最後まで編集したもので、動画編集は彼にとってまったく未知の領域だった。彼のやり方はこの方法をちょうど1本の鎖につなぐ —— まず AI に文字起こしの精度が足りるか尋ね（未知を見つける）、コードで単語ごとに同期する字幕のプロトタイプを作って先に検証し、分からないカラーグレーディング（color grading、画面の色調を決める）はまず Claude に教わってから着手する。素人が「まず盲点を見つけてからやる」で専門的な仕事をやり遂げた。

数字の出どころ：上記の数字と「数週間→数時間」はすべて、この講演と公式ブログ自体に由来する（Anthropic が自社製品を語るベンダーコンテンツ）。第三者による再現はない。