B2B カスタマーサポートにおけるAI：複雑なアカウント、エンタイトルメント、技術的な問題

著者: Linh Ngo · 更新日: 2026年10月11日

B2B カスタマーサポートにおけるAIとは、言語モデルとルーティングのロジックを使って、法人顧客のサポートを行うことです。法人顧客では、すべてのチケットが、複数の窓口を持つアカウント、顧客が受けられる内容を決める契約、そしてヘルプ記事では説明しきれない技術的な問題の中に位置しています。 コンシューマー向けサポートとの違いは、技術ではありません。AIが有用なことを何か述べる前に、誰が尋ねているのか、何を購入しているのか、契約が何を約束しているのかを知っていなければならない点です。

小売業のヘルプセンターではうまく動くボットが、B2Bの現場で失敗するのは、そのためです。「パスワードをリセットするにはどうすればよいですか？」という質問には、誰に対しても1つの答えがあります。「なぜ当社のインテグレーションが失敗しているのですか？」という質問の答えは、プラン、バージョン、管理者の権限、署名済み契約書の条項によって変わります。この記事では、B2Bに合わせてAIサポートがどう変わるのか、何をどの順序で構築するのか、AIがどこで止まるべきかを解説します。この記事はAI for Customer Serviceコレクションの一部であり、概要をお読みであることを前提としています。

重要なポイント

• サポート担当者5,179人を対象としたフィールド調査では、生成AIアシスタントを利用することで、1時間あたりの解決件数が平均で約14%、新人や低スキルの担当者では約34%向上し、経験豊富な担当者への影響はわずかでした（NBER Working Paper 31161）。
• Salesforceの2025年版State of Serviceレポート（サービス担当者6,500人、2025年4月から6月に調査）では、チームの推定として、現在AIが案件の約30%を処理しており、2027年までに50%になると見込まれていました（Salesforce）。
• 同じレポートで、サービスリーダーの51%が、セキュリティ上の懸念がAI施策の遅れや制約につながったと回答しており、挙げられた障壁の中で最多でした（Salesforce）。
• Qualtricsの調査では、カスタマーサービスでAIを利用した消費者のほぼ5人に1人が何の恩恵も得られておらず、これはAI全般の利用での割合のほぼ4倍にあたります。また、半数が、AIのせいで人間につながれなくなることを心配しています（Qualtrics）。
• ZendeskなどのヘルプデスクのSLAポリシーは、設定した条件に一致するチケットにのみ適用され、目標はチケットの優先度フィールドに対して測定されます。そのため、優先度のないチケットは、気づかないうちにSLAの対象外になる可能性があります（Zendesk）。

B2BサポートとB2Cサポートの違い

顧客が企業になると、4つのことが変わります。

顧客は個人ではなく、アカウントです。 1つの会社に、契約を管理する管理者、日常的に使う十数人のユーザー、調達の窓口、経営層のスポンサーがいることがあります。全員が、しばしば同じ問題について連絡してきますが、それぞれに適した答えは異なります。管理者は設定変更を承認できますが、一般ユーザーにはできません。

自社が負う義務は、契約によって決まる。 2社の顧客がまったく同じ質問を送ってきても、受けるべき内容は異なることがあります。1社には4時間以内の応答、もう1社には翌営業日、3社目には専任エンジニアです。サポートチームはこれをエンタイトルメントと呼び、顧客が購入したサービス、チャネル、応答時間を指します。

問題は技術的で、具体的である。 コンシューマーの問題は、数十のテーマに集中します。B2Bの問題には、インテグレーション、権限、データのインポート、APIエラー、顧客ごとに異なる設定の選択が絡みます。答えは、ヘルプ記事ではなく、ログの中にあることが多くあります。

チケット1件あたりの影響が大きい。 1つのアカウントが、売上の大きな割合を占めることもあります。誤った回答、SLAの未達、不満を抱えた管理者を門前払いするボットは、デフレクション（問い合わせ削減）で減らせた1か月分のチケットがもたらす節約よりも、高くつくことがあります。

こうした事情があっても、AIが除外されるわけではありません。変わるのは、AIに最初に何をさせるか、そして何を見えるようにしておくかです。

AIが回答する前に知っておくべきこと

B2Cでは、AIに必要なのは主にヘルプコンテンツです。B2Bでは、アカウントのコンテキストも必要になり、多くのプロジェクトはここで止まります。モデルが何かを下書きしたり送信したりする前に、次の情報を参照できる状態にしておく必要があります。

• 誰が書いているか： 本人の役割、権限、所属するアカウント。
• アカウントが保有しているもの： プラン、モジュール、アドオン、サポートティア、契約日。
• 自社が負っている義務： 応答と解決の目標、サポート時間、指定の窓口担当者、含まれるチャネル。
• 現在起きていること： オープン中のチケット、最近のインシデント、製品バージョン、インテグレーションの状態。

これは、AIのためのサポートデータの準備で取り上げたデータ整備の問題と同じですが、リスクはより高くなります。CRM、請求システム、ヘルプデスクで、顧客がどのプランにいるかが食い違っていれば、AIはどれか1つを選び、確信を持って答えてしまいます。

ACE Frameworkの観点では、これはIngestとAnalyzeの作業（メッセージを読み取り、アカウントのレコードと結びつけること）であり、GenerateやExecuteの前に行う必要があります。検索に基づくアシスタントの質は、取得を許可されたレコードの質で決まり、B2Bでは、そのレコードに記事だけでなく、構造化されたアカウントデータも含まれます。

複数の窓口を持つアカウント

1つのアカウントから多くの会話が生まれ、AIがあると、それぞれを初対面の相手のように扱いがちです。設計時に考えるべきパターンは3つあります。

1. すべての窓口担当者をアカウントに紐づける。 ヘルプデスクはエンドユーザーを組織にまとめ、そのグループ分けが、担当者が見られる範囲を決めます。たとえばZendeskでは、担当者を、自分の組織内のユーザーが起票したチケットのみに制限できます（Zendesk）。同じ境界をAIにも適用する必要があります。A社のユーザーに答えるボットが、B社のチケット、ログ、設定の詳細を表示してはなりません。ポリシーで許可されていない限り、一般ユーザーに同僚のチケットを見せてもいけません。
2. 重複した報告を検出する。 1社の5人が同じ障害を報告するのは、1件のインシデントです。AIは、アカウントと症状でこれらをクラスタリングして統合し、5人の担当者が並行して調査するのではなく、1つのステータス更新で5人全員に回答できます。
3. 役割を尊重する。 AIに、リクエストした人にその変更を依頼する権限があるかを確認させます。インテグレーションの削除、シートの追加、全データのエクスポートを求めるユーザーに対しては、愛想のよい了承ではなく、管理者リストとの照合を行うべきです。

短い例を挙げます。顧客の経理担当者が、請求書が会計ツールに同期されなくなった理由を尋ねてきました。AIは、そのアカウントに管理者が2人いて、有効なインテグレーションがあり、1時間前にIT管理者が同じ症状で起票したチケットが開いていることを確認します。新しいトラブルシューティングのスレッドを始める代わりに、2つを紐づけ、経理担当者にはすでに対応中であることを伝え、両方の窓口担当者にステータスを投稿します。誰も同じ説明を繰り返さず、担当者の作業も重複しませんでした。

エンタイトルメントとSLA

エンタイトルメントは、B2BでAIが気づかないうちに被害をもたらしやすい領域です。親切な回答が、契約でカバーされていないことを約束してしまうことがあるからです。3つの層で対処してください。

エンタイトルメントを文章ではなくデータにする。 サポートティアがPDFや担当者の頭の中にしかなければ、AIは使えません。ティア、時間、チャネル、目標を、AIとヘルプデスクの両方が読めるフィールドとして保存してください。

エンタイトルメントでルーティングを動かす。 ルーティングのロジックは、受付の時点でエンタイトルメントを読み取り、優先度、キュー、SLAの時計を設定するべきです。SaaSのヘルプデスク向けのこのパターンは、ヘルプデスクにおけるマルチティアAIルーティングで解説しています。お使いのツールの仕組みにも注意してください。Zendeskでは、SLAポリシーは条件に一致するチケットにのみ適用され、目標は標準の優先度フィールドに対して測定され、優先度が空のチケットにはSLAがまったく適用されません（Zendesk）。AIがチケットを分類しても、そのフィールドを埋めなければ、気づかないうちに約束を守れないシステムを作ってしまいます。

AIが約束してよい範囲を制限する。 アシスタントは、アカウントレコードにある応答目標を引用できます。しかし、「本日中に修正します」とその場で言ったり、サービスクレジットを付与したり、プラン外の機能を提案したりしてはなりません。これらは商業上の判断であり、人が行うものです。

よくある場面で、この3つの層がどう機能するかを示します。

技術的なトラブルシューティング

これは、B2Bサポートの中で最も価値が高く、最もリスクも高い部分です。AIが最も役立つのは、読み込みと整理を速めるときであり、最も役立たないのは、エンジニアの役割を任せるときです。

AIが役立つ場面：

• 受付。 製品バージョン、エラーメッセージ、再現手順、環境を、会話の中で最初に尋ねておくと、チケットを最初に開く人間が、質問から始めるのではなく、診断から始められます。以前は3往復かかったトリアージが、1回で済みます。
• 要約。 40通のチケットのスレッドが、数行になります。試したこと、除外したこと、まだ残っていることです。
• 類似案件の取得。 アシスタントが、同じエラーシグネチャを持つ解決済みチケットと社内Runbookを表示します。
• 返信案。 サポートエンジニアは、関連するドキュメントを添付した返信案を受け取り、送信前に編集します。

この支援パターンについては、私たちが持っている中で最も強力なエビデンスがあります。担当者5,179人を対象としたNBERの調査では、AIアシスタントによって1時間あたりの解決件数が平均で約14%向上し、新人や低スキルの担当者では約34%向上し、経験豊富な担当者への影響はわずかでした（NBER）。B2Bのチームにとっては、最も大きな効果が、ベテランほど製品に深く通じていない新しいサポートエンジニアの立ち上げにあり、最も優秀な人材を速くすることにはないことを示唆しています。

AIが慎重になるべき場面：

• 顧客のシステムを変更するあらゆる操作。 サービスの再起動、キーのローテーション、データの削除、設定の編集はExecuteにあたり、人間か、範囲を限定した明示的な承認を必須とすべきです。
• 未知のバグに対する自信ありげな推測。 エラーシグネチャがどれにも一致しない場合、適切な出力は、もっともらしい修正ではなく、「分かりません。ここまでに集めた情報はこちらです」です。それ以下では、AIが要約してエスカレーションする確信度のしきい値を設定してください。
• 機微なデータ。 ログやスクリーンショットには、認証情報や個人データが含まれていることがよくあります。モデルに送ってよいものを決め、それ以外は除去またはマスキングします。Salesforceの調査では、セキュリティがサービスリーダーにとって最大の障壁であり、51%が、AI施策の遅れや制約につながったと挙げています（Salesforce）。

ヘルプセンター検索は、セルフサービス側の最初の一歩として適しています。チケットが作成される前に、ユーザーや管理者が問題を普通の言葉で説明して、適切なドキュメントを見つけられるようにします。

AIが引き継ぐべきとき

B2Bでは、引き継ぎは、発動しないことを願うフォールバックではありません。設計の一部です。2万人を超える消費者を対象としたQualtricsの調査では、半数が、AIのせいで人間につながれなくなることを心配していることが分かりました（Qualtrics）。これは消費者の話で、本番環境で障害に直面している法人顧客は、もっと我慢できないでしょう。

人にただちにルーティングする、厳格なトリガーを設定してください。

• アカウントが高額または離反リスクのあるティアにあり、問題が緊急と判定されている場合です。
• 顧客が、データの損失、セキュリティ上の懸念、多数のユーザーに影響する障害を報告している場合です。
• リクエストが、お金、契約、法的条件、アクセスの変更、削除に関わる場合です。
• AIの確信度が低い場合、または2ターンたっても解決できていない場合です。
• 顧客が、どのような言い方であれ、人を求めている場合です。
• 同じ問題で繰り返し連絡しているなど、顧客のトーンがエスカレーションを示している場合です。

ここで仕組みを設計し直す必要はありません。コンテキストを担当者に引き継ぐ、引き継ぎそのものについては、チャットボットから担当者への引き継ぎで、ボットが回答できないときや有人チームがオフラインのときの動作については、AIエージェントのフォールバックフローで解説しています。エスカレーションを自動化された独立した役割として扱う場合は、AIエスカレーションマネージャーエージェントをご覧ください。B2B特有の追加事項は、引き継ぎにアカウントのコンテキストを持たせることです。ティア、SLAの時計、すでに関わっている窓口担当者、関連するオープン中のチケットです。引き継ぎを受ける人が、顧客が誰なのかを尋ねる必要があってはなりません。

B2BサポートにAIを段階的に導入する方法

1. アカウントモデルを整理する。 重要なエンティティを一覧にします。会社、窓口担当者、役割、契約、製品、環境です。それぞれについて、どのシステムを唯一の信頼できる情報源とするかを決めます。
2. エンタイトルメントを機械可読にする。 ティア、時間、チャネル、応答目標をフィールドに入れます。CRM、請求、ヘルプデスクの間の矛盾を解消します。
3. エージェントアシストから始める。 サポートエンジニア向けに、返信案、案件の要約、類似案件の検索を提供します。すべてを人間がレビューするため、顧客の目に触れる前に誤りを捉えられます。
4. アカウントを認識した受付を追加する。 AIに、窓口担当者とアカウントを特定させ、バージョンとエラーの詳細を収集させ、優先度を設定させて、SLAの時計が正しく始まるようにします。
5. 限定的なセルフサービスを開始する。 使い方の質問、ステータスの照会、設定のガイダンスなど、文書化された低リスクのトピックを選びます。アカウントの変更や商業的なことは範囲外にします。自動化か支援かのフレームワークが、各トピックをどこに置くかを判断する助けになります。
6. 引き継ぎのトリガーを書き出す。 上のリストを使って、自社のティアに合わせて調整し、公開前に実際の例ですべてのトリガーをテストします。
7. ベースラインと比較してパイロットを行う。 最初の返信までの時間、SLA達成率、再オープン率、エスカレーション率、解決までの時間、CSATを、ティア別、およびAIが対応したチケットと人間が対応したチケット別に測定します。
8. 失敗を毎週レビューする。 AIが訂正された、または顧客がエスカレーションしたトランスクリプトを読みます。プロンプトだけでなく、データやコンテンツの不足を直してください。

避けるべき落とし穴

すべての顧客を同じように扱う。 画一的なボットは、ティア、役割、契約を無視します。最大のアカウントが、最初に気づきます。

AIに約束をその場で作らせる。 日付、クレジット、回避策、機能の約束は、レコードか人から来るものでなければなりません。

アカウントをまたいで情報が漏れる。 担当者に適用される権限の境界は、AIにも適用されなければなりません。公開前に、意図的にアカウントをまたぐプロンプトでテストしてください。

解決ではなくデフレクションを測る。 B2Bでは、あきらめた顧客がアカウントマネージャー経由でエスカレーションすることが多く、チケットよりも悪い結果です。問題が解決されたか、顧客が再び連絡してきたかを追跡してください。

優先度フィールドを飛ばす。 SLAがAIの埋めないフィールドに依存していると、気づかないうちに違反します。

データが整う前に自動化する。 システム間でプランのデータが食い違っていると、自信に満ちた誤回答が生まれます。まずレコードを直してください。

次に読む記事

1つのアカウントティア、1つの製品領域、1つの支援のユースケースを選んでください。サポートエンジニアにアカウントを認識した要約と返信案を提供し、1か月間、SLA達成率と再オープン率を測定し、その後で初めて、安全と確認できたトピックにセルフサービスを開放します。ツールより重要なのは、その下にあるアカウントデータです。