- ほとんどのWebサイトは「情報はここにあります」と示すだけで、あとは顧客に探させます。探すのが面倒な人は、ページを閉じて競合に移ります。
- 新しいWebサイトは、有能な受付係のように働きます。2つ3つ質問して顧客が何を求めているかを理解し、用件が済むまで案内します。
- 技術より先に準備すべきなのは、自社の正しい答えです。価格、条件、実際に提供できる内容がそれにあたります。
従来のWebサイトやアプリの限界
店に入ったのに誰にも声をかけられず、商品がどの棚にあるかを示す案内板しかない場面を想像してください。欲しいものが決まっている人はそのまま取りに行けますが、まだ迷っている人は立ち尽くし、そのまま店を出ていきます。情報ページと「お問い合わせ」ボタンしかないWebサイトは、ちょうどこの店員のいない店と同じです。
顧客はすべてのページを読みたいわけではありません。知りたいのは、その商品が自分に合うのか、何を準備すればよいのか、だいたいいくらかかるのか、次に何をすればよいのかです。従来のメニューや検索窓は、こうした質問にばらばらにしか答えられません。
Webサイトの情報が少ないことが、いつも問題とは限りません。情報はそろっていても、部署や社内の組織に沿って並べている会社は多くあります。そのため、実際の状況を抱えてやって来た顧客は、自分の問題をサービス名に置き換える作業を自分でしなければなりません。見つからなければサイトを離れるか、電話で問い合わせるか、漠然としたメッセージを送ります。営業担当は、要望の聞き取りを一から始めることになります。
AI Webサイトを設計するときは、画面の隅に浮かぶチャット欄を思い浮かべるより、顧客の意図を理解し、利用の流れ全体を通して文脈を保つ体験の層として考えるべきです。既存のコンテンツページは、参照元として引き続き役に立ちます。AIは情報を選び、足りない部分だけを尋ね、その状況に合った画面やアクションへユーザーを導きます。
| 従来の形 | 新しい世代のAIプロダクト |
|---|---|
| キーワードで検索し、FAQを表示し、全員を同じフォームに送る | 会話で状況を聞き取り、承認済みの情報から検索し、ケースに合わせた提案を作り、予約、資料請求、要約付きのリード登録といったワークフローを起動する |
技術面で大事なのは、会話をWebページやバックエンドのシステムと、状態を保ったままつなぐことです。そうすれば顧客は、質問から始めて情報を見に行き、戻って要件を直し、予約ボタンを押すまで、文脈を失わずに進めます。どのツールも、実際に何かを変更する前に、権限とデータをもう一度確認する必要があります。
ビジネスに使える新しい機能
変わったのは、Webサイトが有能な受付係のように働き始めたことです。いくつか質問して顧客が何を求めているかをつかみ、システムから実際の価格と条件を取り出して答え、予約や見積もり依頼の段階まで案内します。顧客は、次にどのページを押せばよいかを推測しなくて済みます。
プロジェクトの形
このプロジェクトでは、Webページと連動するデジタルコンシェルジュを作ります。ユーザーにテキストでの会話だけを強いることはありません。顧客は画面上で目的を選ぶところから始め、会話で詳細を伝え、比較表を見て、フォームに戻って入力を直すこともでき、その間も文脈は失われません。会話と、見慣れた画面操作を組み合わせた体験になります。
画面で見せるべき機能
システムは要望の絞り込み、承認済みの情報からの回答検索、パッケージの比較、価格帯の見積もり、サービス提供エリアの確認、予約、書類の受け取り、リード（見込み客）の概要づくりまでこなします。もう1つの大事な機能は、なぜその情報を尋ねるのかを説明することです。AIと話したくないときは、質問を飛ばしたり、スタッフを呼び出したりできるようにしておきます。
支える技術
主な構成要素は、情報を探すナレッジ検索（Knowledge Retrieval）、言葉を理解する言語モデル、CRM・カレンダー・価格システムとつなぐツール呼び出し（Tool Calling）、文脈を覚えておくセッションメモリ、権限を定めるポリシーレイヤーです。すべての回答とアクションはログに残し、後から確認したり、失敗したケースを再テストしたりできるようにします。
利用者と企業が得られるもの
顧客はどのページを開けばよいかを推測する必要がなく、同じ話を何度も繰り返さずに済みます。営業部門は整理された形で情報を受け取り、次に何をすべきかがわかります。企業は、Webページでは本当に答えられていない質問も把握できるので、その情報をサービス、コンテンツ、営業の進め方の改善に生かせます。チャットの件数が減るのに加えて、用件を最後まで済ませる顧客の割合も上がります。
- 必要なことだけを聞き返し、顧客を質問攻めにしないAIコンシェルジュ
- 顧客の意図に合わせて質問と画面を変えるガイド付きの流れ（Guided Journey）
- カレンダー、CRM、価格、サービス提供エリアにつなぐツール呼び出し
- 会話と根拠をスタッフに渡し、顧客が説明し直さなくて済む人への引き継ぎ
架空のケース
具体的な利用場面
B2Bのサービス企業が、顧客に目的、予算、時期、制約を入力してもらいます。AIは要望をまとめ、実際のデータをもとにパッケージを比較し、空いている商談の時間を提案します。特殊なケースは、概要を添えて専門の担当者に回します。
新しいシステムの導入を考えているビルの管理者を思い浮かべてください。パッケージの名前は知りませんが、設置箇所の数、建物の種類、予算、サービス開始が必要な日付は伝えられます。システムはエリアを確認し、まだ足りない情報の一覧を示し、理由を添えて2つの選択肢を出し、要点をまとめた状態で営業エンジニアとの打ち合わせを予約します。
スタッフ側の画面には、会話の記録に加えて、顧客が確認した事実、受け取った書類、システムが置いた前提、まだ答えの出ていない質問が表示されます。顧客が翌日戻ってきても、前回の流れの続きから再開でき、最初からやり直す必要はありません。チャットボットと、実際に仕事を担う製品との違いはここにあります。
Intent-to-Action Map
顧客の主な意図を10個書き出し、それぞれについて回答、必要なデータ、使うツール、承認が必要な箇所、成功の条件を決めます。
まずは、頻繁に起きて、測定でき、元に戻せる意図から始めます。
範囲、リスク、効果の測り方
回答とアクションの対応表（Answer-to-Action Matrix）を作り、どの質問にどの情報源から答えられるか、どのアクションならすぐ実行してよいか、どのアクションには確認が必要か、どのアクションはAIに実行させないかをはっきり分けます。AIに任せないものの例は、プロジェクトごとの価格の確約や納期の約束です。効果を測るときは、回答が自然に聞こえるかの点数だけを見ず、正確さとアクションの後の影響を両方見る必要があります。
AIエージェントには、正となるデータ（Source of Truth）を読まずに価格、条件、作業の空き状況を約束させないでください。必要以上のデータを集めることも避けます。
追跡すべき指標：Task Completion、Qualified Lead、Time-to-Handoff、Answer Citation、Abandonment
- Discover：実際の業務を追い、通常のケースと例外の実例を集めます。
- Assist：人が主導権を持ったまま、AIに下書きや提案をさせます。
- Act：テストセットに合格してから、ツールを1つずつ使えるようにします。
- Scale：監視、フォールバック、コスト管理、責任者がそろってから範囲を広げます。
エージェントが参照元にない情報を示す、情報の欠けたリードを作る、スタッフが顧客に何度も聞き直す、といったことが起きたら、止めるか一段階戻すべきです。ジャーニーとデータ契約（Data Contract）が、まだアクションを増やせる状態にないというサインです。
BUSINESS & PRODUCT READINESS
AIコンシェルジュを作る前に、回答と顧客の動線をどう整理するか
まず会話の棚卸し（Conversation Inventory）から始めます。チャット、メール、営業部門に寄せられた質問を集め、顧客が打ち込んだ言葉ではなく意図ごとに分類します。同じ意図でも言い方はさまざまで、「見積もりがほしい」「この予算で何ができるか」「小さいパッケージはあるか」はどれも同じ意図かもしれません。次に、確認済みの答え、追加で聞くべき情報、Webサイトで実行できるアクションを決めます。この土台があれば、エージェントは話がうまいだけで顧客を同じページに戻すボットに終わらず、実際に役立つものになります。
見落とされがちなのは、AIが確信を持てない場面の設計です。情報が古い資料から来ているとき、回答がおおよその見積もりにすぎないとき、専門家の判断が必要なケースのときには、システムがそれを示すべきです。経営者は商品ルール、サービス提供エリア、価格の条件、SLA、そして答えられない質問の例を用意しておきます。「推測で答えてはいけない質問」をはっきり決めておくほうが、プロンプトを延々と足していくより早く公開にこぎつけられます。
開発に入る前に、データごとの責任者と更新の方法を決めておきます。CRMの価格とWebサイトのPDFの価格が違っていたら、システムはどちらが正しい版かを知っている必要があります。担当者がコンテンツを修正し、バージョンを承認し、データの変更がどの回答に影響するかを確認できる管理用のワークフローも用意するべきです。
安全な公開計画は、検索と要約だけを行う読み取り専用のコンシェルジュから始まります。次に、予約の仮登録のような元に戻せるアクションを加え、そのあとで顧客や実際のリソースに影響するアクションを開放します。どの段階でも、実際の会話から作ったテストセットと、品質が基準を下回ったときに一段階戻す条件を用意しておきます。
頻繁に起き、価値の高い意図はどれか
正しい版のデータはどのシステムにあるか
元に戻せるアクションはどれか
すぐにスタッフへ回すべきケースはどれか
メニュー構成ではなく、顧客の会話から始めるWebサイト設計
DNA Makerはまず、顧客と営業部門やサービスチームとの間で実際に交わされている会話に耳を傾け、意図のマップ（Intent Map）、カスタマージャーニー、アクションの境界（Action Boundary）を一緒に作ります。ナレッジベースから答えるべきこと、CRMや価格システムから読み取るべきこと、人に聞くべきことを切り分けるのも私たちの役割です。商品の知識や例外の扱いは、これまでどおり自社のチームのものです。私たちはその知識を、社内の構造を知らない顧客でも使える流れに変えます。
設計の段階では、会話のプロトタイプと、比較表、フォーム、カレンダー、書類アップロードなどの画面を作り、顧客が質問から成果まで本当にたどり着けるかを試します。大きなシステムを書く前に、使う言葉、引き継ぎのタイミング、最低限必要な情報を、通常のケースと答えられないケースの両方で検証します。
アーキテクチャの細部は、業務に合わせて選びます。1つのモデルですべてに答える必要はありません。意図によっては決まったルールが向いていて、検索が向いているものもあれば、APIを呼び出す必要があるものもあります。私たちはモデルルーティング、ナレッジのインデックス、権限、監査ログ、コスト管理を、アクションごとの価値とリスクに見合うように設計します。
そのため最初の期間の成果物は、見栄えのよい画面に加えて、ジャーニーのプロトタイプ、意図のカタログ、データとツールの対応図、ガードレール、評価セット、試験導入の計画など、事業部門が確認できるものになります。公開後は、DNA Makerが利用データを読み、行き止まり（Dead End）を探し、UX、ナレッジ、ワークフローを見直して、感覚に頼らず根拠に基づいてシステムを改善していきます。
方向性が固まれば、DNA MakerはWebサイトや顧客ポータル、AIコンシェルジュ、CRMやカレンダーとの連携、ツールの承認機能、分析機能、ナレッジを更新するための管理画面を開発し、公開後の評価と監視も行います。チームが毎回開発を待たずに、コンテンツやルールを直せるように設計します。
Webサイトにアクセスはあるのに、顧客が同じ質問を電話でしてくるなら、実際の質問を30〜50件持って、ご相談ください。どのジャーニーをAIとの会話にし、どれをガイド付きフォームにし、どれを人が引き継ぐべきかを一緒に見極め、用件の完了率（Task Completion）を測れる試験導入を計画します。
SOFTWARE ENGINEERING GLOSSARY
ソフトウェア開発用語集
Webサイトの責任者が、顧客の意図からアクション、人への引き継ぎまで、開発チームと話し合うための用語です。最後の列の質問を使うと、プロジェクトが測っているのが実際の成果なのか、会話の能力だけなのかを確かめられます。
| 用語 | 意味 | わかりやすい例 | 開発チームへの質問 |
|---|---|---|---|
| Intent | ユーザーが達成したい目的。設計では、意図に名前を付けて質問を分類するところで止めず、必要なデータ、次の手順、成功の定義と結びつける | 現地調査を予約したい（「survey」という単語を探しているわけではない） | 主な意図は、実際のデータから把握したものですか？推測ですか？ |
| Tool Calling | AIがシステムの機能の呼び出しを要求すること。ツールの使用を求めるのはモデルだが、実際に実行する前に、ソフトウェア側がパラメータ、権限、結果を確認する必要がある | 時間を提案する前に予約表を確認する | すべてのツールに承認が必要ですか？ |
| Handoff | AIから人へ、文脈を添えて仕事を渡すこと。よい引き継ぎでは、事実、根拠、試したこと、引き継ぐ理由をすべて渡し、受け取った人がすぐに判断できるようにする | 営業担当が、顧客に聞き直さずに要約を受け取る | どんな条件のときに、すぐ人に引き継ぐ必要がありますか？ |
| Guardrail | 処理を確認したり止めたりするルール。実行前のルール、実行後の結果チェック、停止して人を呼ぶ条件などがあり、リスクに応じて何層にも設計する必要がある | 料金表にない価格を提示しない | ルールの責任者は誰で、いつ見直していますか？ |
| Conversion Event | 事業上の成果が出たとみなす出来事。チャットの開始やクリックの回数を数えるより、予約の完了や必要情報の送信完了など、実際の成果を表すイベントを決めるべき | 予約が完了する、または書類がすべて送られる | 測っているのは会話の量ですか？実際の成果ですか？ |