こんにちは、AI エージェントにお願いしたあと「なんか違うな……？」と一緒に首をかしげがちなアーキテクトのやまぱん！です 😅
Thariq さん（@trq212）の X 投稿 A Field Guide to Fable: Finding Your Unknowns Working with Claude をきっかけに、AI エージェントと成果を出すうえで大事なのは、prompt や skills や context を整えることだけではないなーと感じました。
もちろん、それらは大事です。めちゃくちゃ大事です。ただ、それだけだと「地図はきれいだけど、現地の崖に気づいていない」みたいなことが起きます。
この記事では、prompt / skills / context を「map」、実際の codebase や制約を「territory」として見たとき、その差分にある unknowns をどう見つけるかを考えます。Claude の話から出発しつつ、GitHub Copilot やコーディングエージェント一般でも使える実践として整理してみます。
補足コメントや質問、いいね、拡散、ぜひお願いします 🥺！
間違っていたら 優しく 教えてください！
注: この記事は 2026/07/06 時点で確認できた公開情報をもとにした考察です。外部記事の直訳や長い引用ではなく、私の GitHub Copilot / コーディングエージェント運用に引き寄せた実践メモとして書いています。
TL;DR
- prompt / skills / context は AI エージェントに渡す「map」ですが、実際の codebase や運用制約という「territory」とは必ずズレます。
- そのズレにあるのが unknowns で、ここを見つけられるかが成果物の質をかなり左右します。
- known knowns / known unknowns だけでなく、 unknown knowns と unknown unknowns を掘り起こす設計が大事です。
-
blindspot pass、interview、prototype / reference、implementation-notes.md、post-implementation quiz は unknowns 発見の型として使いやすいです。 - これは「プロンプト不要」という話ではなく、プロンプトだけでは足りない という話です。
図にすると、やりたいことは「map をきれいにする」だけではなく、map と territory のズレを早く見つける ことです。
map は prompt / skills / context、territory は現実の codebase
X 投稿カードと調査メモで読めた範囲で一番しっくり来たのは、AI エージェントに渡す情報を map、実際に作業が起きる場所を territory と見る整理です。
- map: prompt、skills、context、仕様メモ、設計方針など、私たちが AI エージェントに渡す表現
- territory: 実際の codebase、既存の制約、テスト、運用、利用者、レビュー観点など
prompt はあくまで地図です。地図は必要ですが、地図そのものが現地ではありません。
たとえば「この API に認証プロバイダーを追加して」と書いたとします。prompt としては成立しています。でも実際の codebase には、過去の互換性、既存の middleware、監査ログ、テストデータ、運用チームの暗黙ルールがあるかもしれません。
この prompt には書かれていないが、作業結果には効いてくるもの が territory 側にあります。AI エージェントがここを知らないまま実装すると、コードは動くけどレビューで止まる、ということが起きます。
これ、けっこうありますよね 😅
unknowns を 4 つに分けて考える
調査メモで読めた範囲では、unknowns を 4 象限で整理していました。日本語に寄せると、こんな感じです。
| 分類 | ざっくり言うと | 開発での例 |
|---|---|---|
| known knowns | 分かっていて、prompt にも書けていること | 「この API に新しい auth provider を追加したい」 |
| known unknowns | 分からないと自覚していること | 「既存 auth module の設計はまだ読めていない」 |
| unknown knowns | 自分の中では判断できるが、言語化していないこと | 「この UI は業務ツールなので、派手すぎる見た目は嫌」 |
| unknown unknowns | 存在すら気づいていない論点 | 「実は監査ログの形式に互換性制約がある」 |
AI エージェントに渡しやすいのは known knowns です。普通の prompt はここが中心になります。
でも、成果物のズレを生みやすいのは、むしろ unknown knowns と unknown unknowns です。
たとえば UI 実装なら、「見たら違うと分かる」けど、最初から言葉にできていない好みがあります。これは unknown knowns です。セキュリティや運用制約のように、自分もまだ気づいていない落とし穴は unknown unknowns です。
AI エージェントをうまく使うというのは、きれいな prompt を一発で書くことではなく、 unknown unknowns を known unknowns に引き上げる ことでもあるのだと思います。
AI エージェントに unknowns を見つけてもらう 5 つの型
ここからは、自分の GitHub Copilot / Claude Code 運用にも持ち込みやすい形で、unknowns を見つける型に整理します。
1. blindspot pass: まず見落とし候補を出してもらう
新しい領域に入るときは、いきなり実装させる前に blindspot pass を頼むのがよさそうです。
たとえば、こんな依頼です。
この codebase の auth module はまだ詳しくありません。
新しい auth provider を追加する前に、見落としそうな unknown unknowns を洗い出してください。
仕様、既存設計、テスト、セキュリティ、運用の観点で、私が追加で prompt に書くべきことも提案してください。
ポイントは、「実装して」ではなく、 見落としそうなことを先に見つけて と頼むことです。
GitHub Copilot でも Claude Code でも、codebase を検索できる agent なら、既存実装・テスト・命名・過去の似た機能を見て、こちらが知らなかった観点を出してくれます。
これはかなり安い保険です。実装後に「その制約、先に知りたかった……」となるより、最初に blindspot を探した方が戻りが少ないです。
2. interview: AI から質問してもらう
要件がぼんやりしているとき、人間側が「何を決めるべきか」すら分かっていないことがあります。
そういうときは、AI エージェントに質問役をやってもらうのが便利です。
実装に入る前に、曖昧な点を一問ずつ質問してください。
優先順位は「私の回答によって architecture や data model が変わるもの」を高くしてください。
一問ずつ、というのが意外と大事です。まとめて 15 問出されると、人間が疲れます。しかも、最初の回答で次の質問が変わることもあります。
これは、unknown knowns を引き出すのに向いています。
自分の中では「当然こうでしょ」と思っていたことが、AI から聞かれると「あ、確かにそれ prompt に書いてなかった」と気づけます。
3. prototype / reference: 言葉にできないものを小さく見せる
UI や資料、設計方針のようなものは、言葉だけで伝えるのが難しいです。
「いい感じに」「業務ツールっぽく」「見やすく」と言っても、AI エージェント側には幅がありすぎます。そこで、prototype や reference を使います。
たとえば UI なら、いきなり本体に組み込ませず、HTML 1 枚で 3〜4 パターン出してもらいます。
本実装に入る前に、この dashboard の UI 方向性を 4 パターンの HTML mock で出してください。
それぞれ、業務向け、分析向け、管理者向け、軽量ツール向けの方向で変えてください。
私は見てから、採用したい方向と避けたい方向を返します。
また、言葉で説明しにくい挙動があるなら、reference を渡します。
この folder の既存 component と同じ密度感・操作感にしてください。
特に toolbar の配置と empty state の扱いを参考にしてください。
これは「見れば分かるけど、最初から言語化できない」unknown knowns に効きます。
4. implementation-notes: 実装中の発見を残す
どれだけ準備しても、実装中に初めて分かることはあります。
そこで、AI エージェントに一時的な implementation-notes.md を残させるという型が使えます。
実装中に plan から逸れる必要が出た場合は、保守的な選択をして進めてください。
ただし、逸れた理由、見つけた edge case、次回 prompt に入れるべきことを implementation-notes.md に記録してください。
これは「今回の実装を通じて見つかった territory」を次回の map に戻す作業です。
agent に任せると、成果物だけが残って、途中で何を見つけたのかが消えがちです。implementation-notes.md があると、「なぜその実装になったのか」「次に同じことをやるなら何を先に伝えるべきか」が残ります。
個人的には、長めのコーディングエージェント作業ほどこのメモは価値があると思います。
5. post-implementation quiz: 実装後に理解度を逆質問する
AI エージェントが大きな差分を作ったあと、diff を読むだけで全部理解するのはけっこう大変です。
そこで、実装後に quiz を作らせます。
今回の変更を私が理解できているか確認したいです。
変更の背景、主要な code path、リスク、テスト観点を説明したうえで、6 問の quiz を出してください。
私が間違えた場合は、該当する説明箇所に戻れるようにしてください。
これは少し大げさに見えるかもしれません。でも、merge 前の理解チェックとしてかなり良いです。
「AI が作ったから分からないけど、テスト通ってるし merge」ではなく、 自分が説明できる状態に戻す ための型ですね。
Claude だけでなく GitHub Copilot でも同じ話
元記事は Claude / Fable の話です。Fable は元記事側の文脈に出てくる題材ですが、この記事ではモデル固有の評価ではなく、そこから取り出せる map / territory / unknowns の考え方に絞ります。
この unknowns の考え方は、GitHub Copilot でもかなり使えます。
たとえば VS Code の GitHub Copilot Chat でコーディングエージェントに依頼するときも、最初の prompt だけで完璧に伝えようとすると苦しくなります。
なお、GitHub Copilot には IDE 上で動く agent mode と、GitHub.com / Issue / Pull Request から作業を委譲する Copilot cloud agent があります。公式 Docs でも両者は別の実行形態として説明されています。この記事では細かな機能差ではなく、どちらにも共通する「作業前に unknowns を減らす」考え方に寄せています。
むしろ、最初からこういう流れにすると安定します。
-
blindspot passで見落としを探す - agent に質問してもらい、曖昧な前提を潰す
- 必要なら prototype や reference で方向性を合わせる
- implementation plan を見て、人間が変えそうな判断を先に確認する
- 実装中の発見を notes に残す
- 実装後に quiz / explainer で人間の理解に戻す
これ、ほぼ agent workflow の設計です。
prompt を「作業命令」として一発で投げるのではなく、 unknowns を減らす対話プロセス として見る。ここがかなり大きな違いだと思います。
「プロンプトだけでは足りない」は「プロンプトが要らない」ではない
ここは誤解しやすいので、強めに書いておきます。
これは「プロンプトエンジニアリングはもう不要です」という話ではありません。
むしろ逆です。prompt / skills / context は、AI エージェントに渡す map として今後も重要です。ただ、map をきれいにするだけでは territory のすべては表せません。
だから、良い prompt を書く力に加えて、次の力が必要になります。
- 自分が何を知らないかを見つける力
- AI エージェントに質問させる力
- prototype や reference で曖昧さを外に出す力
- 実装中に発見した制約を次の context に戻す力
- AI が作ったものを自分の理解に引き戻す力
このあたりが、AI エージェント時代の実践的なスキルになっていくのかなと思います。
あわせて読むとつながる記事
今回の話は「未知を見つける」ことに寄せましたが、AI エージェントをちゃんと仕事に組み込むには、ループ、検証、Skill 設計もセットで効いてきます。過去に書いた記事だと、次のあたりが近いです。
- Loop Engineering とは？ エージェントに「指示する側」を卒業する設計の話: prompt を毎回打つのではなく、AI エージェントが回る仕組みそのものを設計する話です。
- AI エージェントを「最後までやり切らせる」 goal-loop という Agent Skill を作った話: unknowns を見つけたあと、完了条件と検証で最後まで進めるためのループ設計です。
- GitHub Copilot CLI の外でもラバーダックしたくて、duck-critic という Agent Skill を作った話: AI が出した答えをそのまま信じず、別視点で批評してから進める producer-critic の話です。
-
🔥 はじめての Agent Skills 🔥 12 選＆リポジトリ一覧！GitHub Copilot でも使える AI の手順書:
skillsとは何か、prompt や tool と何が違うのかを整理した入門記事です。 - Claude Code の Skills 記事を読んで、Gotchas から Agent Skill 設計を見直した話: 一般論よりも、現場で毎回つまずく Gotchas を残す方が長く効く、という話です。
まとめ
Thariq さんの投稿をきっかけに、AI エージェント活用の見方が少し変わりました。
これまでは、prompt / skills / context をどう整えるかに意識が寄りがちでした。でも、それらはあくまで map です。実際の作業が起きる territory には、まだ見えていない制約や判断軸があります。
AI エージェントに任せる前に、AI エージェントと一緒に unknowns を探す。
この順番を入れるだけで、実装の戻りや「なんか違う」がかなり減りそうです。明日から 1 つだけ試すなら、まずは blindspot pass からでよいと思います。
私も次から、少し重めの作業を投げる前には、まずこう聞いてみようと思います。
この作業に入る前に、私が気づいていない unknown unknowns を探してください。
そして、より良い prompt にするために私へ確認すべきことを、一問ずつ質問してください。
プロンプトを書く技術から、未知を一緒に見つける技術へ。
AI エージェントとの付き合い方は、たぶんこの方向に進んでいくんだろうなーと思いました。
参考 / 出典
- Thariq さんの X 投稿: A Field Guide to Fable: Finding Your Unknowns Working with Claude
- GitHub Docs: About GitHub Copilot cloud agent