ヒアリングを、​AIに​任せる​ ──フォーム1枚を​「要件の​揃った​実装指示」に​変える​AIエージェントを​作った

制作の仕事で、いちばん最初に、いちばん時間が溶けるのが「ヒアリング」です。何を作りたいのか、お店の情報は、素材は、納期は——それを聞き出して、整理して、抜けを埋める。毎回ゼロから、往復のメールで。

私たちは、この工程をAIに任せる仕組みを作りました。名前は「御用聞きAI」。お客さまは短いフォームに答えるだけ。するとそのままAIとの会話に切り替わり、GoogleマップのURLからお店の情報を確かめ、参考サイトや素材を集め、最後は「要件の揃った実装指示」を自動で書き出します。いまは私たち自身と、パートナーのLP制作会社が、本番の受注業務で使っています。

作ってみて分かったのは、この手のAIで効くのは「賢く喋らせること」ではない、ということでした。効いたのは会話の"状態"の設計——たとえば、お客さまの「はい」を、いつ・何に対する「はい」として扱うか。ここを雑に作ると、間違った情報が"確認済み"の顔をして残ります。

この記事では、①何を作ったか ②ヒアリングがなぜ難しいか ③本番で効いた設計判断（特に「はい」の扱い）④その結果、を順に書きます。専門用語は都度かみくだきます。導入先の企業名・サービス名・担当者名は伏せた匿名ケーススタディです。

01何を​作ったか​ ──フォーム1枚が、​実装指示に​なるまで

御用聞きAIは、受注業務の「入口から実装の一歩手前まで」を一本につなぎます。流れはこうです。

1. フォーム：お店・サービスのこと、要望、連絡先を数項目。答えやすい順に並べ、連絡先は最後にしました。
2. AI会話へ切替：送信すると、その内容を読んだAIが会話を始めます。足りない要件を、雑談のように埋めていきます。
3. 店舗情報の自動確認：GoogleマップのURLを貼ると、店名・住所・電話・営業時間を取得し、会話で「この情報で合っていますか？」と確かめて確定します。
4. 素材集め：参考サイト、ロゴ、写真などをその場でアップロード。会話履歴に残ります。
5. 実装指示の自動生成：必須が揃うと、実装担当（人＋AI）がそのまま着手できる指示書を書き出します。
6. 人が引き継ぐ：料金や難しい判断は、AIが抱え込まずに人へエスカレーションします（HITL＝最終判断は人間）。

「AIチャットを置きました」で終わる話ではありません。フォーム・会話・外部データ照合・素材・成果物生成・人への引き継ぎを、ひとつの流れとして設計したのが、この制作の中身です。

02なぜ​「ヒアリング」は、​こんなに​難しいのか

発注する側も、受ける側も、ヒアリングでつまずく理由ははっきりしています。

受ける側は、毎回ゼロから同じことを聞き、聞き漏らすと後で手戻りになります。素材はなかなか集まらず、メールの往復で数日が溶けます。発注する側は、そもそも何を伝えればいいのか分からない。フォームは冷たくて、途中で面倒になって離脱します。

「じゃあAIチャットにすれば？」と思いますが、ここに落とし穴があります。会話をAIにさせると、今度は「言った・言わない」が起きる。AIが要件を取りこぼす。さらに厄介なのは、AIが取りこぼしたことに、誰も気づかないことです。人間同士なら「あれ、その話しましたっけ？」と拾えますが、AIは平然と会話を進めてしまいます。

だから難しさの本質は、「AIをどれだけ賢く喋らせるか」ではありません。会話の中で確定した事実を、どう間違いなく積み上げるか——地味ですが、ここが全部です。以降は、本番で実際にぶつかって直した設計判断を3つ紹介します。

03フォームの​送信後を、​無反応に​しない

最初の一手は、地味ですが離脱に直結します。送信ボタンを押した後の"待ち時間"です。

当初の実装は、送信処理の中で「店舗情報の取得」と「AIの最初の一言の生成」まで同期で終わらせてから画面を返していました。結果、送信から次の画面まで10秒以上、無反応。ここで多くの人が離脱します。フォームの文言をどう直しても、この沈黙は埋まりません。

直し方は、重い処理を送信から切り離すことです。送信は「会話の入れ物を作るだけ」に縮小し（実測1.7秒で遷移）、店舗情報の取得とAIの一言は、遷移した先で「入力内容を読んでいます…」と動きを見せながらストリーミング表示します。案内メールも、送信処理を待たせず後追いで送ります（＝離脱した人にも届く）。

離脱の主因は、文言ではなく"無反応な沈黙"でした。 待たせるなら、せめて動きを見せる。ここは、AIうんぬんより手前のUX設計の話です。

04Googleマップの​URLから、​店の​情報を​「確かめて」確定する

次の一手です。ヒアリングで毎回聞く「店名・住所・電話・営業時間」は、GoogleマップのURLを1本もらえれば機械で取れます。Googleの Places API（お店の情報を取得するAPI）に問い合わせて、構造化された店舗情報にします。

ただし、ここには二重の罠がありました。ひとつは、お客さまが「URLが分かりません」と書いたとき。この文章をそのまま検索APIに渡すと、Places検索は"必ず何か1件返す"性質があるため、まったく無関係な海外の店舗を「確認済みの情報」として提示してしまいました。直し方は、AIが抽出した値が入力内に実在するかを検証し、地域が一致するかまで確かめるガードレールを噛ませること。「分からない」は「分からない」として扱います。

もうひとつが、より根深い問題でした。次の章で詳しく書きます。いずれにせよ、外部データは「取得して終わり」にしない。取ってきた情報を、会話で「これで合っていますか？」と本人に確認して初めて確定します。この一手間が、後工程の事故を止めます。

05​「はい」を、​文脈に​結びつける​ ──誤りが​"確認済み"に​化ける​前に

これが、この制作でいちばん効いた設計判断です。

本番で、こんな報告が上がってきました。「正しい店名と住所を送っているのに、AIが電話番号も営業時間も取ってこない」。最初は「Places APIの取得失敗だろう」と考えました。ところが、本番の会話ログとデータベースを突き合わせて分かった真因は、まったく別のところにありました。

流れはこうです。お客さまが最初に誤った店名を入力→AIが候補を提示→お客さまが「違います」→ところが、その否定で候補が捨てられていなかった。その後の会話で、お客さまが別の文脈で言った何気ない「はい」を、システムが「さっきの誤った候補への承認」として食べてしまった。結果、間違った店が「確認済み」に昇格し、以降どの処理も「これは本人が確認した正しい情報だ」として扱いました。誤りが"確認済み"の顔をして居座り、監視にも掛からない——いちばん質の悪い壊れ方です。

根っこは、「はい」を文脈なしで拾っていたことです。会話AIで「はい／いいえ」を判定するなら、必ず「何に対するはいか」を紐づけないといけない。直した設計はこうです。

• 直前のAIの発言が候補を提示していたときだけ、確認の判定をする。
• 返事を「肯定／否定／どちらでもない」の3値で扱う。関係ない「はい」は確認として食べない。
• 「違います」は候補を破棄し、「もう提示しない店」のリストに積む（同じ間違いを繰り返さない）。
• 確定するまでは、新しい入力が来たら検索し直して上書きする。

一般化すると、外部から情報を取り込む会話には「入れる経路」だけでなく「消す経路」を必ず作る、ということです。訂正を受け付けない状態機械は、ユーザーから見ると「AIがちゃんと調べてくれない」という、まったく別の症状に化けます。本番の会話ログとDBを突き合わせ、誤って確定していた1件を修復しました。

06集めた​会話を、​そのまま​「実装指示」に​変える

ヒアリングのゴールは、会話を楽しむことではなく、実装が始められる状態を作ることです。御用聞きAIは、必須項目が揃うと、集めた会話・店舗情報・素材から、実装担当がそのまま着手できる指示書（Markdown）を自動で書き出します。人が議事録を清書する工程が、まるごと消えます。

そして、AIが抱え込まない線引きも設計に入れています。料金や、要件の重い判断は、AIが勝手に答えずに人へエスカレーションする（HITL＝Human-in-the-Loop、最終判断は人間）。「AIに一次対応させ、難しいところは人が引き継ぐ」——この線引きを先に決めておくことが、AIを業務に載せる前提になります。この考え方は、このサイトの受注チャットAIでも同じです。

関連記事 ｜ 姉妹編・受注チャットAIこのサイトのAIは、自分たちで作った ──HITL・顧客別メモリ・メール⇄チャット双方向を実装した顧客対応AIの中身 →

07まとめ ──​「ヒアリングの​型」を、​資産に​する

御用聞きAIは、私たちの内製ツールとして始まり、いまはパートナーのLP制作会社が本番の受注業務で使う外販プロダクトになりました。新しい導入先も、設定を1枚書けば数分で立ち上がります。作ったのは単発のチャットボットではなく、「ヒアリングの型」そのものです。

この制作から持ち帰れる3点

• AIチャットの勝負は"賢さ"より"状態設計"。 確定した事実をどう間違いなく積むか。「はい」は文脈に紐づける。
• 外部データは取って終わりにしない。 会話で確認して確定し、「消す経路（否定＝破棄）」を必ず作る。
• AIに一次対応、難しいところは人へ。 線引き（HITL）を先に決める。

ヒアリングは、どんな受注業務にも必ずあります。そこをAIに任せられれば、人は「作ること」と「判断すること」に集中できます。私たちが実装と検証で毎回いちばん時間を使うのも、モデルの賢さより、この線引きの設計のほうです。