はじめに

AIエージェントにコーディングを任せていると、指示が少しでも曖昧だと明後日の方向に実装されたり、逆に細かく指定しすぎると融通が利かなかったりする。

たまたまYouTubeでAnthropicのブログ記事 A Field Guide to Claude Fable: Finding Your Unknowns を紹介している動画があって、自分の中の考え方が変わった。指示がうまくいかないのは技術の問題ではなく、自分が「何を分かっていないか」を分かっていないからではないか、と考えるようになったのだ。原文はこの「未知（unknowns）」をどう見つけるかを説明している。

この記事では、原文の内容を自分なりに噛み砕いて紹介しつつ、読んで考えたことを書く。原文は「AIにうまく仕事をさせるための技術」として書かれているが、自分が面白いと思ったのは、これはAIというより開発者自身の解像度の話だという点だった。

※ 原文は英語の記事で、ここでは要点を自分なりの言葉で要約している。正確なニュアンスはぜひ元の文章を読んでみてね！

地図と土地 ―― "unknowns"って何？

原文では、AIとの作業を「地図（map）」と「土地（territory）」の比喩で説明している。

地図 … 自分がAIに渡すもの。プロンプト、スキル、コンテキスト
土地 … 実際に作業が起きる場所。コードベース、現実の制約

この地図と土地のズレが「unknowns（未知）」で、どうやらAIは未知にぶつかると、「たぶんこうしてほしいんだろう」と推測で判断しはじめる。任せるタスクが複雑であるほど、ぶつかる未知は増えていく。

自分はたとえばこれを、車のナビを思い浮かべて考えた。「どこどこに行きたい」と住所を入力すると、ナビはその時点での最適ルートを出してくれる。でも、自分が普段運転している道の方が早く抜けられたり、渋滞にはまったときに小さい路地から抜けられたりするルートまでは提示してくれないときがある。そういう場合はナビを無視して自分の判断で走ったりすると思う。(わたしだけじゃないよね？)

ここで自分が記憶として持っている「裏道の知識」は、まだ地図に描かれていない土地の情報である。AIも同じで、放っておけば教科書どおりの最適ルートしか出せない。自分だけが知っている抜け道を少しずつ教えていく――それが未知を言語化するということなんじゃないかなと思っている。

本文でちょっと気になった一文があって、

Claude Fable is the first model where I find the quality of the work is bottlenecked by my ability to clarify its unknowns.
（成果物の質が「自分が未知をどれだけ明確にできるか」で頭打ちになる、初めてのモデルだ）

モデルの性能ではなく、指示する側の"未知を言語化する力"が上限を決める。一見、自社のFableを自慢しているようにも見えるが、それだけ賢く使えば何でもできるモデルが世に出てきたことの裏付けでもあると思う。

未知の4分類

原文では、問題を4つの「未知」に分解している。

分類	中身	ざっくり言うと
既知の既知	プロンプトに書けること	「やってほしい」と言えること
既知の未知	まだ解決してないと自覚してること	「ここ、まだ決めてない」と分かってる穴
未知の既知	言語化してないが、見れば分かること	「これじゃない」とは言えるが先に書けない好み
未知の未知	存在にすら気づいてないこと	そもそもなにが問題なのかが分からない領域

原文いわく、agentic codingが上手い人はこの未知が「少ない」うえに、未知が存在すること自体を前提にして動いているという。

自分の場合を当てはめてみた

この4つのパターンに、自分をそれぞれ当てはめていくと、

既知の既知：要件はざっくり伝えられる（issueがあるし、それを渡すとか）。でも細部が漏れる。実装し始めてから「あ、ここ指定してなかった」となることが多い。
既知の未知：判断しにくい点は設計理由とテスト・例外処理。コードが動くことを優先して、「なぜこの構成か」の言語化を飛ばしがち。
未知の既知：AI実装が早すぎてコード自体をあまり読めていなくて、ここはブラックボックスになっている。本来なら見れば「これじゃない」と気づけるはずの部分を、そもそも見ていないから把握できていない（プロジェクトの規則を守れていない、という指摘を何度受けたことか...）。
未知の未知：マージされた後にバグとして指摘されて、初めて気づくことが多い。まだ経験がないことに関しては、特にこれが多いのかなと感じている。

未知は「実装の前・中・後」で見つける

原文の本題は、未知を炙り出す具体的なパターン集。実装のフェーズごとに紹介されている。要点だけまとめる。

実装前

手法	何をするか
Blind Spot Pass	「自分の未知の未知を洗い出して」とAIに頼む。`blind spot pass` という言葉を実際に使うのがコツ
ブレスト＆プロトタイプ	実装前に「まったく違う4案を出して」と頼み、見て反応する。未知の既知を早めに言語化する
インタビュー	「曖昧な点を1問ずつ質問して。特にアーキテクチャが変わる質問を優先して」と、AIに自分を尋問させる
リファレンス	言葉で説明しづらいときは、参考にしたいソースコードを指す。スクショより情報量が多い
実装計画	「変更されやすい所（データモデル、型、UXフロー）を先頭に」と計画を書かせる

実装中

手法	何をするか
実装ノート	`implementation-notes.md` を持たせ、計画から逸脱した判断を記録させる

実装後

手法	何をするか
ピッチ／解説	変更内容を1枚のドキュメントにまとめさせ、レビューや承認を早める
クイズ	「変更内容を自分にクイズして。満点取るまでマージしない」

どの手法も解決したい方向性は一緒で、未知を"高くつく前"に、安く見つけること。実装で詰まってから気づくと修正が高くつくが、ブレストやインタビューは失敗しても早く見つけられるので対応がしやすい。

読んで思ったこと

気に入ったのは「Blind Spot Pass」

手法の中で自分に一番刺さったのは、実装前の Blind Spot Pass だった。自分がAIに任せて事故るのは、たいてい理解しているつもりで実は分かっていないコードの改修や、「今までもこうしてきたから」と惰性で進めているときが多いからだ。どちらも「既知の未知」「未知の既知」が多い場面。そこで先に「自分が気づいてない、あやふやになっている前提を洗い出して」と頼めるのは、事故る前に地図の解像度を上げられるということ。

クイズはちょっと合っていない気がする

一方で クイズ は、良い手法だと思いつつ自分としてはあんまりだと思っている。正直に書くと、クイズに正解するためだけに覚えてしまいそうだからだ。試験前の一夜漬けと同じで、テストが終われば抜ける。自分が欲しいのは「その場で覚えること」より、後から辿れること。

実装ノートは「未来の自分や、引き継ぐ誰かへの記憶」になる

そう考えると、原文の implementation-notes の見え方が変わった。原文では「次の実装のための軽いメモ」として紹介されているが、自分の文脈では、あれは未来の自分への記憶として効く。

時間が経つと、自分が書いたコードも自分にとって"未知の土地"になる。「なぜこう実装したか」をその場でAIに記録させておけば、後から振り返るときに当時の判断を辿れる。

そしてこれは、自分の振り返りだけじゃなく、他の人が実装した内容を引き継いだときにも当てはまる。たとえば、プロジェクトから離れた人が書いた機能に手を入れることになったとする。コード自体はAIに頼めばある程度分かりやすく説明してくれる。でも、前提になっている「なぜこのライブラリを選んだのか」「なぜこの分岐をわざわざ足したのか」までは説明してくれない。そうすると、自分たちは**「たぶんこういう意図でこうしたんだろう」と推測するしかない**。その推測が外れていれば、直したつもりが別のバグを生む。ここでもし実装意図をまとめたドキュメントが残っていれば、AIにそれを渡して「この判断の背景を説明して」と聞ける。引き継ぎの"たぶん"を、"なるほど"に変えられる。

とはいえ、ドキュメントを用意したところで結局読まれないことが多い。でも、AIになら読ませられる。「この実装ノートを踏まえて、当時なぜこの設計にしたか説明して」と聞けばいい。読み手を人間からAIに変えると考えれば、記録を残す手間にも納得がいく。

まとめ

AIとの作業のズレ＝unknowns（未知）。成果物の質は「自分が未知をどれだけ明確にできるか」で決まる
未知は4分類できる。厄介なのは自分で気づけない未知の既知／未知の未知
未知を炙り出す手法は実装の前・中・後にある（blind spot pass、インタビュー、クイズなど）
実装ノートを"未来の自分と、引き継ぐ人への記憶"として残すと、読み手を人間からAIに変えられる

原文の締めが良かったので、自分なりに要約して置いておく。未知を見つけるための一手（説明、ブレスト、インタビュー、プロトタイプ、参照）は、どれも"高くつく前に安く済ませる"投資だ。次のプロジェクトは、まず「自分のunknownsを一緒に探して」と頼むところから始めてみたい。

参考文献

A Field Guide to Claude Fable: Finding Your Unknowns - Anthropic (Thariq Shihipar)