- 決まった質問にしか答えられないチャットボットでは、チームの仕事はほとんど減りません。顧客が実際に電話してくる用件は、たいていその顧客自身の情報を開いて確認する必要があるからです。
- 新しいサービスシステムは顧客の履歴を確認でき、同じ問題が以前にも起きたかどうかを把握し、簡単な用件ならその場で完了させます。
- 決めておくべきことは、システムが自分で処理できる用件と、人に回す用件の線引きです。人に回すときは、顧客が同じ説明を繰り返さなくて済むように引き継ぎます。
従来のWebサイトやアプリの限界
古いタイプのチャットボットは、出勤初日のインターンのようなものです。決まった答えは暗唱できても、顧客に「昨日注文した商品は今どこですか」と聞かれると、担当者におつなぎするまでお待ちくださいと返すことしかできません。そのため、本当に手間のかかる仕事は少しも減りません。
ボットが同じFAQを何度も送ってきたり、スタッフに同じ情報を何度も聞かれたりすると、顧客はいら立ちます。新しいAIはこうした手間やストレスを減らすべきですが、リスクのあるケースで人に連絡する手段を隠してはいけません。
多くのサービスポータルは、チケットを起票したら、あとは顧客を待たせるだけです。製品の型番、不具合の写真、修理履歴、サービスの利用資格（保証や契約の範囲）といった大事な情報は、最初の段階で集めて一次確認までできるのに、それをしていません。そのため、スタッフは同じ質問を繰り返し、案件は別のチームに回され、顧客は自分の件がどの段階にあるのかわかりません。
よいAIサービスポータルは、回答が長くなったFAQとは別物で、ケースを処理するための作業スペース（Case Workspace）です。証拠を集め、許された範囲で原因を診断し、安全な手順を案内し、予約を入れ、その後の経過を確認します。システムはケースの進み具合を覚えておき、セルフサービスから人の対応へ、情報を落とさずに切り替えられなければなりません。
| 従来の形 | 新しい世代のAIプロダクト |
|---|---|
| キーワードを拾い、決まった台本どおりに答え、中身のないチケットを作る | 履歴、写真、音声を読み取り、症状を切り分け、利用資格を確認し、解決の手順を案内し、承認済みのツールを呼び出し、タイムラインを添えて専門スタッフに渡す |
サービス業務のAIが診断を手伝い、仕事を先へ進められるのは、ケースの履歴、利用資格、承認済みの手順とつながっているときです。ツールを呼び出すたびにケースIDとひも付けて証拠を記録すれば、案内が履歴と食い違ったり、同じ操作を二重に実行したりするのを防げます。
ビジネスに使える新しい機能
違いを生むのは、システムがその顧客の情報を実際に開いて確認でき、同じ問題が以前に報告されたかどうかを把握し、配送先住所の変更や領収書の再発行といった簡単な用件を自分で完了させる権限があることです。複雑な用件や、間違えたときの損害が大きい用件は、これまでどおり必要な情報をそろえたうえで人に回します。
プロジェクトの形
ユーザーはまず、テキスト、音声、写真、書類のいずれかで症状を説明します。システムはケースを分類し、その顧客の製品と利用資格に合ったチェックリストを作ります。画面には、現在の状況、確認中の内容、追加で送ってほしいもの、おおよその所要時間を表示し、提供した情報がそれぞれ何の役に立つのかを顧客がわかるようにします。
問題解決のための機能
主な機能としては、テキストや写真、音声などをまとめて受け付ける窓口（Multimodal Intake）、誘導型の診断、ナレッジにもとづく回答、安全な操作、予約、ケースのタイムライン、通知、専門スタッフへの引き継ぎが考えられます。手順どおりに試しても解決しないときは、結果を記録して別の対応に切り替えます。同じ回答を繰り返し出したり、記事を送ったというだけでケースを閉じたりしてはいけません。
支える技術
システムは、顧客の本人情報、製品・設備の記録、利用資格、チケット管理、ナレッジベースとAPIでつながります。検索（Retrieval）で承認済みの手順を引用し、写真や音声の読み取りには画像認識や音声認識を使うこともあります。その場合は確信度も記録します。すべての操作に監査証跡を残し、顧客の設定や契約・権限に手を触れる前には安全停止（Safety Stop）のルールを適用します。
利用者にとっての効果
顧客は回答や進み具合の連絡を早く受け取れ、窓口を変えるたびに同じ説明をし直す必要もなくなります。スタッフは証拠がそろったケースの要約（Case Brief）から作業を始められるので、情報集めより問題の解決に時間を使えます。企業の側では、顧客が何度も問い合わせてくる原因がわかり、製品、マニュアル、上流のワークフローの改善に生かせます。
- テキスト、写真、書類、音声を受け付けるマルチモーダルな窓口
- 症状と製品に合わせて質問を変える診断フロー
- 状況確認、リセット、技術者の手配、ケース番号の発行といった操作ツール
- 対応後にこちらから結果を尋ね、解決していなければケースを再開するフォローアップ
架空のケース
具体的な利用場面
顧客が家電製品に表示されたエラーを撮影すると、アプリがエラーコードを読み取り、型番と保証を確認して、安全な手順を案内します。それで直らなければ、写真、履歴、すでに試したことを添えて技術者の訪問を手配します。
架空のケースで、もう少し詳しく見てみます。ある顧客から、アップデートのあとに機器が動かなくなったと連絡が入ります。顧客が画面を撮影すると、システムが型番とエラーコードを読み取り、サービスの利用資格を確認したうえで、技術部門が承認した点検手順を示します。危険の兆候が見つかれば、システムはセルフサービスを止め、すぐに専門スタッフの時間を予約します。
専門スタッフが受け取るタイムラインには、システムが何を尋ね、顧客が何を確認し、どの手順をすでに試したか、どの情報が推測にすぎないかが記されています。修理が終わると結果がシステムに記録され、診断の手順が本当に役立ったのか、かえってケースを遅らせたのかを評価できます。
操作の前に証拠をそろえる（Evidence-before-Action）
実際に影響のある操作をシステムにさせる前に、最低限の証拠をそろえ、何が起きるのかをユーザーに示して確認してもらいます。
速さと引き換えに、別のアカウントや別の機器を操作してしまうことがあってはなりません。
範囲、リスク、効果の測り方
「回答を送った」と「問題が解決した」は分けて考えます。指標には、一次解決率（First-contact Resolution）、再オープン率、専門スタッフにつながるまでの時間、安全停止の件数、顧客が踏まなければならない手順の数を入れます。自己解決率（Deflection）が上がっても、再オープンや損害が増えているなら、システムは仕事を減らしたのではなく、見えなくしただけです。
安全、お金、顧客の契約や権限に関わる業務では、範囲をはっきり決め、同意を記録し、いつでも人が引き継げるようにしておきます。
開発チーム向け · 技術指標
追跡すべき指標：First-contact Resolution、Repeat Contact、Escalation Quality、Unsafe Suggestion、Customer Effort
- Discover：実際の業務を追い、通常のケースと例外の実例を集めます。
- Assist：人が主導権を持ったまま、AIに下書きや提案をさせます。
- Act：テストセットに合格してから、ツールを1つずつ使えるようにします。
- Scale：監視、フォールバック、コスト管理、責任者がそろってから範囲を広げます。
危険の兆候があるとき、本人確認の情報が一致しないとき、システムの案内がスタッフに何度も覆されているときは、すぐにセルフサービスを止めます。必要なケースを早めに専門スタッフへ回すのは、サービスの質の高さの表れで、AIの失敗には当たりません。
BUSINESS & PRODUCT READINESS
セルフサービス、AIによる支援、専門スタッフの境界線を設計する
よいサービスのために、AIがすべてのケースを閉じる必要はありません。解決の段階（Resolution Ladder）を分けておきます。一般的な情報にはすぐ答え、標準的な点検手順はAIが証拠を示しながら案内し、元に戻せる操作はユーザーに確認してもらい、リスクのあるケースは専門スタッフに回します。自己解決率の目標を高くしすぎると、顧客が人にたどり着きにくくなり、再度の問い合わせが増えることがよくあります。
開発チーム向け · 技術的な詳細
Case Taxonomy、Required Evidence、Safety Stop、Entitlement、Outcome Codeをすべて用意し、「解決した」と「回答を送った」の違いをシステムが判別できるようにします。満足度スコアだけに頼らず、修正（Override）された回答と再オープンされたケースを、ナレッジとワークフローを改善するためのデータとして蓄積します。
症状ごとのケース分類、必要な証拠、解決の定義は、導入企業のサービスチームと専門スタッフが一緒に作るべきです。一般のユーザーが自分で行える手順、本人確認が必要な手順、技術者や権限のある人に限る手順もはっきりさせます。こうした線引きは業務の専門知識で、ソフトウェアに推測させるものではありません。
試験導入は、点検手順がはっきりしていてリスクの低い、よくあるケースから始めます。最初は人が確認する前提で、AIに情報集めと案内文の下書きを手伝わせます。ケースが正しく分類され、漏れなく引き継がれ、再オープンも増えていないという裏づけがそろってから、セルフサービスや操作の範囲を1種類ずつ広げます。
顧客の契約や権限に触れずに解決できるケースはどれか
症状ごとに最低限必要な証拠は何か
人に引き継ぐとき、どんな情報を添えるか
どの時点でケースが本当に完了したとみなすか
過去のやり取りを覚え、ケースを最後まで導くサービスを設計する
DNA Makerは、お客様のサービスチームや製品の専門家と一緒に、受け付け、診断、対応、フォローアップからエスカレーションまでのサービスブループリント（サービス全体の設計図）を作ります。技術面や安全面の解決手順を書くのはお客様です。私たちはその手順を、証拠を示しながら進み、範囲を超えたら止まる判断フローに組み立てるお手伝いをします。
UXチームは、長い質問攻めにせずに必要な情報を集められるよう、テキスト、画像、書類、音声での受け付けを設計します。システムがいま何をしているのか、どこで人を呼べるのかが顧客にわかる画面も作ります。エージェントのプロトタイプは、通常のケース、情報が足りないケース、システムが案内してはいけないケースで試します。
DNA Makerは、ケースのデータモデルと、顧客、スタッフ、ナレッジ管理者それぞれの画面を設計し、全員が同じ状況を見られるようにします。チケット管理・CRM、設備情報、予約、通知を役割に応じた権限でつなぎ、システム連携が遅いとき、データが欠けているとき、モデルの確信度が低いときのフォールバックも設計します。
開発中は実際のケースでプロトタイプを作り、通常、例外、危険なケースのテストセットを用意します。ダッシュボードは、回答の量より、解決できたかどうかを追う形にします。毎週チームの時間を取られている種類のチケットがあれば、個人データを伏せたサンプルをお持ちください。どの部分を誘導フローにし、どこをAIの支援に任せ、どこを専門スタッフだけの対応にするかを一緒に見極めます。
DNA Makerは、顧客ポータルやモバイルアプリ、AI診断エージェント、チケット管理・CRM、予約、通知、リアルタイム音声を開発でき、同意管理、監査、評価、担当者への引き継ぎも組み込みます。運用を始めたあとは、システムが答えられなかったケースと、追加すべきナレッジをダッシュボードが示します。
繰り返し届く同じ種類のチケットがあり、解決手順もある程度はっきりしているなら、スタッフが確認を続ける形の試験導入をお手伝いします。操作の範囲を広げる前に、一次解決率が上がることを確かめられます。まずはご相談ください。
SOFTWARE ENGINEERING GLOSSARY
ソフトウェア開発用語集
この用語集では、顧客が送ってくる写真や音声などの形式、ケースの文脈、同意、人への引き継ぎを分けて説明しています。ポータルが問題の解決に十分な情報を集めつつ、必要以上に集めていないかを見直すときに使ってください。
| 用語 | 意味 | わかりやすい例 | 開発チームへの質問 |
|---|---|---|---|
| Multimodal | 複数の形式の情報を受け取り、理解すること。写真は証拠になり、音声は手がふさがっているときに役立つというように、形式ごとに得意なことが違う。仕事に合うものを選べばよく、できるからといってすべての形式を加える必要はない | エラー画面の写真と、音声での説明をあわせて読み取る | 実際に使えるほどの品質があるのは、どの形式ですか？ |
| Session Context | 1つのケースの中でシステムが覚えておく情報。ユーザーが確認した内容と、AIが要約・推測した内容を分けて持ち、プライバシーに配慮した保存期間を設ける | 型番と、顧客がすでに試した手順を覚えておく | どれくらいの期間保存し、誰が見られますか？ |
| Escalation | システムの範囲を超えたケースを人に回すこと。リスク、確信度の低さ、権限の範囲外といった、確認できるルールにもとづいて引き継ぎ、受け取るチームとそのSLAも決めておく | 電気系統のトラブルは、すぐ技術者に回す | 危険と判断する条件に、漏れはありませんか？ |
| Consent | ユーザーの同意。目的、使うデータ、撤回の方法を示す必要があり、利用開始前に置かれた大ざっぱな「同意する」のチェック欄では足りない | ケースの確認のために写真を使うことを許可する | ユーザーはどうやって同意を撤回しますか？ |
| Realtime API | 音声やデータを低遅延でやり取りするための接続。音声での対話や、すぐに応答が必要な場面に向くが、遅延（レイテンシ）、会話の割り込み、コスト、ネットワークが使えないときの代替手段を計画しておく必要がある | 音声で会話しながら、ケースの状況を呼び出す | 音声が途切れたら、どの窓口に切り替えますか？ |
関連資料（原典）：https://platform.openai.com/docs/api-reference/realtime