AIへの指示が上手い人は言葉が上手いのではなく、自分が何を知らないかを、高くつく前に見つけている。
【記事紹介】AIに仕事を任せる技術の正体は「自分が何を知らないか」を高くつく前に見つけること — Anthropic Thariq氏の Field Guide を現場に翻訳する
先に結論を言います。AIに仕事を任せる技術の正体は、プロンプトの書き方ではなく、「自分が何を知らないか」を、直すのが高くつく前に見つけることです。
そう言い切る根拠になる記事が公開されました。Anthropic で Claude Code に携わる Thariq 氏（@trq212）が2026年7月3日に公開した「A Field Guide to Fable: Finding Your Unknowns」。公開から1日足らずで大きな反響を呼んでいて、私も全文を読み込みました。エンジニア向けに書かれた記事ですが、AIに仕事を任せる場面がある人なら、職種を問わず持ち帰りがある内容だと感じました。
▶ 原文（X Article・英語）: A Field Guide to Fable: Finding Your Unknowns
地図は領土ではない — 「アンノウン」という考え方
Thariq 氏の出発点は古い格言です。「地図は領土ではない」。
- 地図 = プロンプト・スキル・コンテキスト。あなたが AI に渡すもの
- 領土 = 実際に仕事が起きる場所。コードベース、現実、その制約
この地図と領土の差分を、氏は**アンノウン（unknowns）**と呼びます。AI がアンノウンに突き当たるたび、AI は「あなたが望んでいそうなこと」を推測で埋める。任せる仕事が大きいほど、推測の回数は増える。だから最新モデルでは、仕事の質のボトルネックが「AIの賢さ」から「人間が自分のアンノウンを明確化する能力」に移った——これが記事の核心です。
アンノウンは4つに分類されます。
| 分類 | 意味 | 例 |
|---|---|---|
| Known Knowns | プロンプトに書けていること | 要件として明文化済みの仕様 |
| Known Unknowns | 未解決だと自覚していること | 「認証方式はまだ決めていない」 |
| Unknown Knowns | 当たり前すぎて書かないが、見れば分かること | 「そういうデザインじゃないんだよな」 |
| Unknown Unknowns | 考慮すらしていないこと | そもそも何を質問すべきか分からない領域 |
指示が具体的すぎると、AI は方向転換すべき場面でも指示に従い続ける。曖昧すぎると、あなたの現場に合わない「業界のベストプラクティス」で勝手に埋められる。両側の失敗の原因は同じで、自分のアンノウンを把握していないこと——この整理が見事です。
8つの技法 — 実装前・実装中・実装後
記事では、アンノウンを見つけるための技法がフェーズ別に紹介されます。要旨を私の言葉でまとめます（詳細な例文は原文をどうぞ）。
実装前
- ブラインドスポット・パス — 未知の領域に入る時、まず「この仕事における自分の unknown unknowns を教えて」と AI に頼む。本題のプロンプトはその後に書く
- ブレストとプロトタイプ — 「見れば分かるが言葉にできない」もの（デザイン等）は、方向性の違う複数案を先に出させて反応する。ほぼ毎セッションを探索から始める
- インタビュー — 「曖昧な点を1問ずつ私にインタビューして。答えがアーキテクチャを変える質問を優先して」と頼む
- リファレンス — 言葉で説明できないものは現物を指す。最良のリファレンスはソースコード。言語が違っても「これと同じ動きにして」で伝わる
- 実装計画 — 「私が変えたくなりそうな部分（データモデル・型・UX）を先頭に、機械的な作業は末尾に」という順序で計画を書かせてレビューする
実装中
- 実装ノート — 計画から逸れる判断をしたら、保守的な選択肢を取った上で専用ファイルに記録して続行させる。次の試行の学習材料になる
実装後
- ピッチと説明資料 — プロトタイプ・スペック・実装ノートを1つの資料に束ねて関係者に渡す。レビュアーも「あなたと同じアンノウン」から始まるので、承認が速くなる
- クイズ — 変更内容のレポートと理解度クイズを作らせ、自分が満点を取るまでマージしない
圧巻なのは実例です。Fable のローンチ動画は全編 Claude Code で編集されたそうですが、Thariq 氏は動画編集の専門家ではありません。転写の精度を確かめ、プロトタイプで実現可能性を見て、「カラーグレーディングが何かを知らない」と気づいた時には変種を出させるのをやめて、まず自分に教えさせた。未経験の領域で自分のアンノウンを順番に潰していく手順が、そのまま記録されています。
私の現場での実感 — 「答え合わせ」が2つ
読みながら、日々の運用と重なる点が2つありました。
1つ目は検証の分離。私は AI の実装を、実装した本人（同じ会話）に自己採点させず、別の文脈で検証する運用にしています。Thariq 氏の「クイズに満点を取るまでマージしない」は、その人間側バージョンです。AI の報告を信じるかどうかではなく、理解の証明をプロセスに組み込むという同じ思想が、Anthropic の中の人からも出てきたことに膝を打ちました。
2つ目は間違いのコストで手間を配分する発想です。モデルを「間違えた時のコスト」で使い分けていると以前書きましたが、この記事の締めの一文——explainer もブレストもインタビューもプロトタイプも、すべて「知らなかったこと」を傷が浅いうちに見つける方法だ——は、同じ原則のより一般的な形です。
人事の現場に翻訳すると
この記事はコーディングの話ですが、構造は人事業務の AI 移行にそのまま持ち込めます。
- 求人要件定義は Unknown Knowns の塊です。「いい人なら見れば分かる」と皆言いますが、書けない。だから先に候補者ペルソナの複数案を AI に出させて反応する——プロトタイプの技法そのものが効きます
- 「AIで何ができるか分からない」という相談への最初の一手は、ブラインドスポット・パスです。業務を説明して「私たちの unknown unknowns を教えて」から始めると、要件定義の質が変わります
- 制度設計のレビューは「変えたくなりそうな部分を先頭に」の順序で。等級定義や評価項目のように後から変えると高くつく部分こそ、先に議論のテーブルに載せる
次に AI へ仕事を頼む時、プロンプトを書き始める前に一言足してみてください。「まず、私が知らないことを教えて」。
AIの話も人事の話も、X（@awata_atsume）でいつでも気軽にどうぞ。
出典
- 原文: A Field Guide to Fable: Finding Your Unknowns（X Article・英語、2026年7月3日公開）
- 著者: Thariq 氏（@trq212、Anthropic / Claude Code チーム）
- 反響の数値（97万インプレッション・1万ブックマーク）は2026年7月4日時点の X 上の表示によります
- 本文中の引用・技法の説明は、原文（英語）を筆者が要約・翻訳した要旨です。例文プロンプトの原文など、正確な表現は必ず原文をご確認ください