AIチャットボット開発の最初の打ち合わせで聞くこと｜後戻りを防ぐ

2026年8月18日

丸山桃子

この記事のポイント

✓AIチャットボット開発の初回の打ち合わせで何を聞けば後戻りを防げるのかを
✓受注後の実務目線でまとめました
✓制約の順に確認する手順と

AIチャットボット開発の初回の打ち合わせで一番やってはいけないのは、機能の話から入ることです。結論から言うと、初回で確認すべきなのは「何を作るか」ではなく「何が終われば成功なのか」と「その材料はどこにあるのか」の2点です。この2点が曖昧なまま設計に進むと、実装が終わった段階で全部やり直しになります。

後戻りの原因は、技術的な難しさではありません。参照させたい資料が揃わない、精度の合格ラインが人によって違う、決裁権のある人が打ち合わせに出ていなかった。この3つがほとんどです。どれも初回に確認できます。

この記事では、初回打ち合わせで何をどの順番で聞くのか、その場で決めることと持ち帰ることの線引き、打ち合わせ後にすぐやる作業までを扱います。

初回打ち合わせのゴールを先に決める

初回でやることは、要件を全部固めることではありません。固まらないのが普通です。初回のゴールは3つに絞ります。

ひとつは、発注側が解きたい問題を、依頼側の言葉から自分の言葉に翻訳できる状態にすること。ふたつめは、次に進むために必要な情報と、それを誰がいつまでに用意するかを決めること。みっつめは、この案件の意思決定者と、確認の流れを把握することです。

この3つが取れていれば、初回としては成功です。逆に、機能の一覧を聞き出しただけで終わった打ち合わせは、その後で必ず揺れます。機能は目的から導かれるものであり、目的が定まらないうちに並べた機能は、途中で全部組み替わります。

打ち合わせの前に準備しておくもの

準備なしで臨むと、その場で考える時間に打ち合わせの半分が消えます。事前にやるのは3つです。

相手の公開情報を読みます。会社の事業内容、サービスの利用者、問い合わせフォームやFAQページの構成。特にFAQページは、そのまま参照データの候補になるので、構成と分量を見ておきます。この段階で「今のFAQは項目が並んでいるだけで、検索しづらい構造になっていますね」と言えると、話が具体的なところから始まります。

想定質問を書き出します。後述する6つの領域について、それぞれ聞くことを事前に文章にしておきます。その場で思いつく質問は、たいてい機能の話に寄ります。

議事録の型を用意します。空欄の項目を並べた状態で持ち込み、その場で埋めながら進めます。埋まらなかった欄が、そのまま宿題の一覧になります。

聞くこと1：目的と、達成された状態

最初に聞くのは目的です。ただし「チャットボットで何を実現したいですか」という聞き方はしません。この聞き方だと「問い合わせ対応を効率化したい」という抽象的な答えで止まります。

聞き方を変えます。「今、その問い合わせは誰が、どうやって処理していますか」。この質問には具体的な答えしか返ってきません。担当者が何人いて、1日にどれくらいの件数を、どんな方法で処理しているか。そこに何時間かかっているか。その時間が減ったら、その人は代わりに何をするのか。

目的を数値で置く必要性は、開発の教科書的な手順としても示されています。

まずは「誰のために」「何のために」チャットボットを作るのかを定義します。「社内ヘルプデスクへの電話問い合わせを30%削減する」「ECサイトでの夜間の購入機会損失を防ぐ」など、具体的な数値目標を設定してください。出典: ricoh.co.jp

ここで重要なのは、数値目標そのものより、その数値を誰がどうやって測るのかです。削減率を目標に置くなら、今の件数を測る仕組みが必要です。測っていないなら、まず測るところから始めることになります。この事実を初回で共有しておくと、公開後に「効果が分からない」と言われる事態を避けられます。

「なぜ今なのか」を確認する

目的とあわせて聞くのが、着手のきっかけです。担当者が困っているのか、上層部から指示が出たのか、他社が導入したから追随するのか。この背景で、案件の進み方が大きく変わります。

上からの指示で動いている場合、担当者は「何を作るか」を決める権限を持っていないことがあります。その場合、初回で決めた内容が上長の確認で覆る可能性を織り込む必要があります。逆に、担当者本人が困って探してきた案件は、要件が具体的で進みが速くなります。

聞くこと2：回答の元になる情報

チャットボットの答えは、参照させた情報の質を超えません。ここが初回打ち合わせで最も時間を使うべき領域です。

所在、形式、量、更新頻度

どこに何があるかを、実物を見せてもらいながら確認します。口頭の説明だけでは実態が分かりません。共有フォルダの画面を見せてもらうだけで、ファイル名の付け方、版管理の有無、更新の止まり具合が分かります。

確認する項目は、所在、形式、量、更新頻度の4つです。形式では、文書なのか表なのか、紙をスキャンした画像なのかを区別します。画像のPDFは、そのままでは機械が読めません。この一点を初回で確認しなかっただけで、後の工程が丸ごと増えます。

更新頻度は、公開後の運用設計に直結します。月次で改訂される規程を参照させるなら、改訂のたびに差し替える手順が要ります。誰が差し替えるのかを、この段階で話題に出しておきます。

「正解」を持っている人は誰か

もうひとつ聞くのが、その情報の正しさを保証する人です。同じ制度について、部署ごとに違う説明資料を持っていることがあります。どれを正とするかを決められるのは誰か。この人が決まっていないと、精度の検証で必ず止まります。

実務でよくあるのは、資料が3世代分残っていて、現場は最新版を使っているが共有フォルダには旧版も置いてある、という状態です。旧版を混ぜて参照させると、古い情報を自信満々に答える仕組みができあがります。旧版の除去を誰がやるかは、初回で話題にしておく価値があります。

権限と持ち出しの可否

参照させたい情報に、受注側がアクセスできるかどうかを確認します。閲覧権限の申請に社内手続きが必要なら、その手続きにかかる日数が日程に乗ります。社外への持ち出しが禁止されている情報なら、作業場所や環境の制約が出ます。

聞くこと3：利用者と使われ方

誰が使うのかで、作るものが変わります。社内向けと社外向けでは、求められる安全性の水準が違います。

利用者の属性と、置く場所

社内向けなら、全社員が使うのか特定部署だけかを確認します。部署によって見せてよい情報が違うなら、権限による出し分けが必要です。この要件は後から足すと、設計の根本に手を入れることになります。

社外向けなら、どのページに置くのか、ログイン前の利用者も使えるのかを確認します。ログイン前に使えるなら、個人を特定できる情報を入力させない設計にする必要があります。

設置するチャネルも聞きます。自社サイトの中だけか、社内チャットツールからも使うのか、メッセージアプリと繋ぐのか。チャネルが増えるほど工程が増えます。

想定される質問の中身

利用者が実際に何を聞くかを、具体例で出してもらいます。過去の問い合わせ履歴があるなら、それを見せてもらうのが最短です。履歴を見ると、質問の8割が数種類のパターンに集中していることが分かります。その集中している部分を確実に答えられるようにするのが、最初の目標になります。

履歴がない場合は、担当者に思い出してもらいながら書き出します。この作業自体が、発注側にとって価値のある整理になります。

答えられない質問をどこへ逃がすか

すべての質問に答えられる仕組みは作れません。答えられないときに、どこへ繋ぐのかを決めます。問い合わせフォームか、電話番号の案内か、担当者への転送か。この導線が設計されていないと、利用者は行き止まりに突き当たります。

社外向けの場合、ここの設計が満足度を大きく左右します。答えられないこと自体より、その後どうすればいいか分からないことの方が不満につながります。

聞くこと4：精度と、間違えたときの扱い

生成AIを使う以上、間違えることがあります。この前提を初回で共有しておくかどうかで、後の関係が変わります。

公開前の検証工程は省けません。

本格的な公開の前に、必ずクローズドな環境でテスト運用を行います。実際に想定される質問を入力し、回答が正しいか、ハルシネーション（もっともらしい嘘）が発生していないかを確認します。出典: ricoh.co.jp

初回で確認するのは、この検証を誰がやるかです。発注側の担当者が業務時間を割いて質問を投げ、結果を判定する作業が発生します。その時間を確保できるのかを、初回のうちに聞いておきます。ここが確保できない案件は、公開後に品質の問題が噴出します。

あわせて、間違った回答が出たときに何が起きるかを聞きます。社内の福利厚生の案内を間違えるのと、料金の説明を間違えるのでは、影響がまったく違います。影響が大きい領域は、そもそも回答させない設計にする判断もありえます。

聞くこと5：体制と決裁

技術の話ばかりして、この確認を飛ばす人が多い領域です。

窓口になる担当者は誰か。その人は決裁権を持っているか。持っていないなら、決めるのは誰で、どういう順番で承認が回るか。確認を依頼したとき、返答までにどれくらいかかるか。この4点を聞きます。

返答の速度は、日程に直結します。確認待ちで止まる時間は、受注側にはどうにもできません。「確認事項をお送りしてから、だいたい何営業日でお返事いただけますか」と聞き、その答えを日程の前提に書きます。

打ち合わせに決裁者が出ていない場合、初回で決めたことが後から覆るリスクがあります。その場合は、決まった内容を文書にして、決裁者の確認を取ってもらう段取りを提案します。

社内の関係部署も確認します。情報システム部門の承認が必要か、法務のチェックが入るか、個人情報を扱うなら管理部門の確認が要るか。これらの手続きは、着手してから発覚すると日程を大きく押します。

聞くこと6：制約条件

最後に、動かせない条件を確認します。

期限があるなら、その理由を聞きます。展示会に間に合わせたい、期の変わり目に合わせたい、といった理由があるなら、その日を過ぎたら価値が下がることを意味します。理由のない期限なら、交渉の余地があります。

既存の契約やシステムの制約も確認します。すでに導入しているツールと繋ぐ必要があるか、社内のセキュリティ規程で使えない外部サービスがあるか。生成AIのサービスについて、社内で利用が承認されているものとされていないものがある企業も増えています。

予算の枠組みは、金額そのものを聞き出すというより、どういう単位で予算を持っているかを確認します。年度で確保された枠なのか、都度申請なのか。都度申請なら、承認の手続きに時間がかかります。

答えが曖昧なときの掘り下げ方

聞いても抽象的な答えしか返ってこないことがあります。相手が隠しているのではなく、言語化されていないだけです。掘り下げの型を3つ持っておくと、その場で具体化できます。

ひとつめは、直近の実例を求める型です。「最近そういうケースはありましたか」「先週で言うと、どんな問い合わせが来ましたか」。時期を狭く区切って聞くと、思い出せる範囲に入るので具体的な答えが出ます。「よくある問い合わせは何ですか」と聞くより、はるかに実態に近い答えが取れます。

ふたつめは、反対側から聞く型です。「これができなかったら、いちばん困るのは誰ですか」「今のままで続けたら、何が起きますか」。目的を正面から聞くと建前が返ってきますが、困る側から聞くと本音が出ます。担当者本人が困っているのか、別の部署が困っているのかも、この聞き方で見えます。

みっつめは、選択肢を出して選んでもらう型です。「回答は、社内規程の文言をそのまま出す形と、要約して噛み砕く形がありますが、どちらが近いですか」。ゼロから考えてもらうより、二択で選んでもらう方が早く、しかも選んだ理由の説明から追加の情報が出てきます。

避けたいのは、専門用語で確認する聞き方です。「参照するナレッジベースの粒度はどうしますか」と聞かれても、業務側の担当者は答えられません。「一問一答の形で持っていますか、それとも長い文書のまま持っていますか」と言い換えれば、その場で答えが出ます。

そのまま使える確認項目の一覧

初回に持ち込む一覧の例を挙げます。全部を一度に埋める必要はなく、埋まらなかった欄が宿題になります。

目的の領域では、対象となる業務、今の処理方法、関わっている人数、かかっている時間、減らしたい部分、成功と判断する基準、その基準を測る方法を並べます。

データの領域では、参照させたい資料の名称、保管場所、形式、おおよその分量、更新の頻度と担当、旧版の有無、正しさを保証する人、受注側がアクセスできるか、社外に持ち出せるかを並べます。

利用者の領域では、使う人の範囲、設置する場所、想定される質問の例、質問の履歴の有無、権限による出し分けの要否、答えられないときの逃がし先を並べます。

精度の領域では、間違えたときの影響、検証を担当する人、検証に割ける時間、合格と判断する基準、公開前の限定運用の期間を並べます。

体制の領域では、窓口の担当者、決裁者、承認の流れ、確認の返答にかかる日数、関係部署の有無を並べます。

制約の領域では、希望する期限とその理由、既存システムとの接続の要否、社内で利用が認められている外部サービス、セキュリティ規程の有無、予算の持ち方を並べます。

この一覧を打ち合わせの前に共有しておくと、当日までに調べておいてもらえることがあります。全部を調べてもらえなくても、何を聞かれるかが分かっている状態は、相手にとっても楽です。

オンラインでの打ち合わせで気をつけること

初回がオンラインになることは珍しくありません。対面と違って通用しない部分があります。

画面共有を使って、議事録を映しながら進めるのが有効です。その場で埋まっていく様子が見えると、相手も抜けに気づきやすくなります。口頭だけで進めると、認識のずれがその場では表面化しません。

資料の実物を見せてもらうときも、画面共有を頼みます。「共有フォルダの中を少し見せていただけますか」と言えるかどうかで、得られる情報の質が変わります。機密の都合で難しい場合は、ファイル名の付け方だけでも説明してもらいます。

通信の途切れや音声の遅れがある環境では、確認の一言を挟む頻度を増やします。対面なら表情で伝わる「腑に落ちていない」が、画面越しだと分かりません。ひとつの領域を聞き終えるごとに「ここまでで、認識がずれているところはありませんか」と挟むだけで、後の食い違いが減ります。

チャット欄も活用します。口頭で出た用語のうち、相手が知らなそうなものを打ち込んでおくと、後から議事録を書くときの手がかりになります。相手側も、口を挟みにくい場面でチャットに補足を書いてくれることがあります。

録画は、相手の許可を取れば有効です。ただし録画に頼ると、その場でのメモが雑になります。録画は確認用と割り切り、議事録は当日中に書きます。

参加者が多い場合、発言しない人が誰なのかを見ておきます。黙っている人が決裁者だった、というケースがあります。最後に一言もらう場を作ると、その人の関心が分かります。

その場で決めないこと

初回で答えを出さない方がよい質問があります。

金額です。話を聞いた直後に暗算した数字は、前提条件が抜けたまま一人歩きします。「持ち帰って整理してお出しします」と答え、代わりに確認事項の一覧をその場で共有します。

実現可否の断定も避けます。「それはできます」と即答した機能が、既存システムの仕様上できなかった、という事故が起きます。「確認してお返事します」で問題ありません。むしろ即答しない方が、慎重な相手だと受け取られます。

日程も同様です。確認待ちの時間や社内手続きの日数が読めないうちに、納期を口にしないでください。

打ち合わせが終わったらすぐやること

打ち合わせの内容は、時間が経つほど薄れます。当日か翌日には、次の3つを送ります。

議事録を送ります。決まったこと、決まらなかったこと、認識が分かれた点を分けて書きます。認識が分かれた点を書くのが大事で、ここを曖昧にしたまま進めると、後で「言った言わない」になります。

宿題の一覧を送ります。誰が、何を、いつまでに用意するかを表にします。受注側の宿題も同じ表に入れます。片側だけの宿題表は、発注側に催促の印象を与えます。

次の打ち合わせの日程を提案します。宿題の期限から逆算して、材料が揃ってから開くように設定します。

送った議事録に対して修正の返事が来たら、その修正内容がそのまま重要な情報です。特に、数値目標や責任範囲の記述が直された場合、そこが発注側の関心の中心にあります。

初回で見えてくる、危ない案件のサイン

聞いているうちに、進め方を変えた方がよいと分かる場合があります。断るという意味ではなく、段階を分ける、前提条件を厚く書く、といった対処が必要になるサインです。

目的を聞いても「とりあえずAIを使ってみたい」から先に進まない場合、成功の判断基準が作れません。この場合は、いきなり本番の開発に入らず、限られた範囲で試す段階を挟む提案をします。試した結果を見てから本開発の要件を決める形にすれば、どちらにとっても無駄が減ります。

参照させる資料の話になると担当者の口が重くなる場合、社内で整理されていないことを本人が自覚しています。ここで「こちらで整理します」と安請け合いすると、際限のない作業になります。整理の範囲を点数や時間で区切る前提を、先に共有しておきます。

決裁者が誰か答えられない場合、社内でこの案件の位置づけが定まっていません。見積もりを出しても稟議が回らず、そのまま止まることがあります。初回のうちに、社内でどう進める予定かを聞いておきます。

期限だけが先に決まっていて、その理由が説明されない場合も注意します。展示会や制度改正のような外部要因なら動かせませんが、理由がないなら、要件が固まってから日程を引き直す提案ができます。

これらのサインが出たからといって、悪い案件だと決めつける必要はありません。対処の仕方を初回で決められるかどうかが分かれ目です。

二回目の打ち合わせに向けて

初回が終わったら、次回までに受注側でやることがあります。

聞いた内容から、実現する方法の候補を2つか3つ組み立てます。既製のツールを設定して使う方法、個別に開発する方法、その中間。それぞれで何ができて何ができないかを並べます。この比較を持っていくと、二回目の打ち合わせが判断の場になります。

聞き漏らした項目を洗い出します。初回で全部埋まることはまずないので、埋まらなかった欄を宿題の一覧に足して送ります。

日程の骨組みも粗く引いておきます。確定した日程を出す必要はなく、どの工程がどの順で並び、どこに発注側の作業が入るかが分かる程度で十分です。発注側の作業が可視化されると、「思っていたより自分たちがやることが多い」という反応が返ってきます。この反応が二回目で出るのは健全で、公開直前に出ると事故になります。

想定される難所を書き出しておきます。データの形式、既存システムとの接続、権限の出し分け。難所を先に共有しておくと、後から出てきたときに「聞いていた話だ」となります。隠して進めるより、早く出す方が信頼されます。

実務の勘所と、案件の探し方

初回の打ち合わせは、聞き出す作業であると同時に、相手に「この人に任せられそうだ」と思ってもらう場でもあります。ここで効くのは技術用語の量ではなく、業務の話をどれだけ具体的に聞けるかです。

業務にAIを組み込む支援の仕事は、まさにこのヒアリングが中心になります。仕事の内容と求められる姿勢はAIコンサル・業務活用支援のお仕事にまとまっています。開発を伴わない相談だけの案件もあり、初回打ち合わせの練習として引き受ける選択肢もあります。

実装まで含めた案件でどんな工程が求められるかは、アプリケーション開発のお仕事で確認できます。設計から保守までの流れを頭に入れておくと、初回で聞くべき項目が自然に出てきます。個人情報や社内規程が絡む案件ではAI・マーケティング・セキュリティのお仕事の観点が役立ちます。セキュリティ要件を初回で聞けるかどうかで、後の手戻りが大きく変わります。

チャットボット開発を仕事として続けるうえで必要なスキルの全体像は、AIチャットボット開発のフリーランス案件｜必要スキルと単価で整理しています。打ち合わせで答えられる範囲を広げるための学習の指針として使えます。この職種が市場でどう位置づけられているかはソフトウェア作成者の年収・単価相場にデータがまとまっています。

打ち合わせの記録を残す作業そのものも、地味ですが技術です。議事録や確認依頼の文書を正確に書けるかどうかで、案件の進み方が変わります。文書作成の基礎を体系立てて確認したい場合はビジネス文書検定の出題範囲が参考になります。資格を取ること自体より、何が求められる文書なのかを知る用途で見る価値があります。

現場を見てきた立場からの観察

フリーランスと在宅ワークの市場を20年運営してきた立場から言えば、初回の打ち合わせで案件の8割が決まります。決まるのは受注の可否ではなく、その案件が最後まで穏やかに進むかどうかです。穏やかに終わる案件は、初回の議事録に「決まらなかったこと」がきちんと書かれています。逆に荒れる案件は、初回の議事録が決定事項だけで埋まっている。曖昧なまま「決まった」ことにした部分が、後で全部戻ってきます。

運営者として見てきた限りでは、繰り返し指名される人は、打ち合わせで自分が話す時間が短い傾向があります。聞いて、書いて、確認する。この3つを丁寧にやる人のところに、次の依頼が来ます。中間に仲介が入らない直接取引の場では、この差がはっきり出ます。仲介の担当者が要件をまとめてくれる代わりに、伝言のたびに情報が落ちる、ということが起きないからです。同じ予算でも、発注側は説明の往復に使う時間が減り、受け手は手数料0%のぶん手取りが厚くなる。金額の話というより、やり取りの精度が上がるという意味で、直接話せる関係には価値があります。

もう一点、長く見てきて確かだと言えるのは、初回で聞ききれなかった項目は、放っておいても埋まらないということです。作業が進むと、目の前の実装の話に時間が取られ、前提の確認は後回しになります。そして後回しにした前提が、検収の直前に噴き出します。宿題の一覧を毎回の打ち合わせに持ち込み、埋まっていない欄を機械的に読み上げる。この単純な運用をしている人ほど、後戻りが少なくなっています。

初回の打ち合わせは、営業の場ではなく調査の場です。売り込む時間を減らして、聞く時間に充てるほど、後戻りは減ります。