AIエージェントに丸投げしないための「未知の見つけ方」｜Fable 5記事から考える実務導入の型

「AIエージェントに任せれば、あとは勝手に進む」。そう聞くと便利そうですが、実務ではここが一番危ないところです。AIが止まらず動けるようになるほど、何を知らないまま進んでいるのかが見えにくくなります。

Claude Codeに関わるThariq氏がXで公開した記事「A Field Guide to Fable: Finding Your Unknowns」では、Claude Fable 5のような長い作業を進めるモデルでは、プロンプトの上手さ以上に「未知を見つける力」が成果を左右すると整理されています。この記事では、その考え方を中小企業の業務改善に置き換えて噛み砕きます。

「地図」と「現場」は、必ずズレる

元記事の中心にある比喩は、地図と現場です。プロンプト、スキル、文脈、仕様書は「地図」。実際のコード、業務フロー、顧客の例外対応、社内ルールは「現場」。そして、地図と現場の差分が「未知」です。

AIエージェントは、未知にぶつかったときに何らかの判断をします。判断そのものが悪いわけではありません。問題は、その判断が自社の現場感とズレたまま、どんどん先へ進んでしまうことです。

たとえば「問い合わせメールを分類して」と頼んだとします。一般的には、購入前相談、クレーム、サポート依頼、営業メールに分ければよさそうです。でも現場では、「このお客様は社長が直接見る」「この表現は強めなので翌朝に返信する」「この商品だけは例外的に電話確認する」といった暗黙知があります。ここが未知です。

未知には4種類ある。厄介なのは「自分では当たり前」なこと

記事では、未知を4つに分けています。業務改善で特に効くのは、Unknown KnownsとUnknown Unknownsです。自分では当たり前すぎて書かないこと、そもそも考えていなかったこと。ここをAIに先回りして見つけてもらいます。

実装前は、Blind Spot Passで「見えていない穴」を探す

元記事で最初に紹介されているのが、Blind Spot Passです。新しい領域に手を付ける前に、AIへ「自分が見落としている未知の未知を洗い出して」と頼む方法です。

業務改善なら、いきなり「この作業を自動化して」ではなく、「この業務をAI化する前に、見落としそうな制約・例外・確認ポイントを洗い出して」と頼みます。ここ、けっこう大事です。作る前に1時間考えるだけで、あとからの手戻りが減ります。

あなたは業務改善プロジェクトの設計担当です。
以下の業務をAIエージェントに任せる前に、blindspot passをしてください。

対象業務:
{例: 問い合わせメールの一次分類と返信案作成}

前提:
- 私はこの業務の全体像は分かっていますが、AI化の落とし穴は詳しくありません。
- 個人情報、送信ミス、顧客別の例外、社内承認の観点を重視してください。

出力:
1. unknown unknownsの候補
2. 事前に聞くべき質問
3. モックで確認すべき画面・帳票
4. 人が必ず止めるべき操作

ポイントは、「AIに答えを出させる」のではなく、「AIに質問を出させる」ことです。現場の人が答えるべき問いが出てくれば、導入の地図がかなり現実に近づきます。

モック、インタビュー、参照資料で、言葉にできない判断を引き出す

元記事では、HTML artifact、プロトタイプ、インタビュー、参照コードなどを使って未知を減らす方法が紹介されています。業務で言えば、画面、帳票、メール文面、分類ルールを「見て反応できる形」にするということです。

「いい感じにして」と頼むと、AIは一般的な正解へ寄せます。でも、会社ごとの「いい感じ」は違います。だから、先に4案出してもらい、担当者が「これは近い」「これは違う」と反応する。ノンプログラマー目線では、この進め方の方がずっと自然です。

実装中は、判断ログを残す。AIが迷った場所こそ資産になる

計画を作っても、実際に進めると必ずズレます。元記事では、実装中にClaudeへ implementation-notes.md を残させ、計画から外れた判断やエッジケースを記録する方法が紹介されています。

業務自動化でも同じです。「この条件はテンプレートAにした」「このケースは判断できないので人に回した」「このCSVの列名が資料と違った」。こうした小さな判断ログが、次の改善材料になります。

i-Styleでは、AI活用の価値は「一回早く終わること」だけではないと見ています。AIが迷った場所を記録し、次回の依頼書や業務マニュアルに戻す。地味ですが、ここが半年後に効いてくる部分です。

実装後は、説明資料とクイズで「人が理解した状態」に戻す

長いAI作業のあと、人間側が置いていかれることがあります。差分は出ている。成果物もある。でも、なぜそうなったか分からない。この状態で本番に入れるのは危険です。

元記事では、実装後にpitch docやexplainerを作り、さらにクイズで理解確認する方法が紹介されています。これは開発だけでなく、社内業務にもそのまま使えます。

AI導入で大事なのは、AIが理解していることではなく、人が運用できることです。説明できない自動化は、トラブル時に止められません。逆に、担当者が「ここはAI、ここは人」と説明できる状態なら、小さく始めても強い仕組みになります。

今日使うなら、まず「未知を洗い出す会議」を15分だけ

最初から大きな自動化を作る必要はありません。おすすめは、1つの業務を選んで、AIに未知を洗い出させる15分のミニ会議です。問い合わせ、見積もり、請求前チェック、社内FAQ、日報整理。対象は小さくて大丈夫です。

これだけでも、業務の暗黙知がかなり見えてきます。AIエージェントは、作業者としてだけでなく、現場の見えない前提を言語化する相棒として使える。今回の記事から持ち帰りたいのは、まさにこの読み筋です。

よくある質問

まとめ

AIエージェントの性能が上がるほど、「良いプロンプトを書く」だけでは足りなくなります。AIが長く動けるからこそ、どこで迷い、どこで人に戻し、どの判断をログに残すかを設計する必要があります。

i-Styleでは、AI導入を「人を置き換える話」ではなく、現場の暗黙知を言語化し、裏側で仕組みを構築する仕事だと捉えています。AIに丸投げする前に、AIと一緒に未知を見つける。その小さな一歩が、自社サイズの現実解になります。

• check_circleプロンプトや仕様書は地図であり、実際の業務という現場とは必ずズレます。
• check_circleUnknown KnownsとUnknown Unknownsを見つけると、AI導入の手戻りを減らせます。
• check_circle実装前はBlind Spot Pass、実装中は判断ログ、実装後は説明資料と理解確認が有効です。
• check_circle最初は15分の「未知を洗い出す会議」から始めるのが現実的です。