イントロダクション：なぜ今、チケット振り分けにAIが必要なのか
カスタマーサポート（CS）の現場では、優秀なマネージャーたちが「終わらないチケットの山」と格闘している光景が日常的に見られます。
経営者視点とエンジニア視点の双方から見ると、この状況には強い危機感を覚えます。なぜなら、多くの時間が「問題を解決する」ことではなく、「誰が解決すべきか判断する」という、本来自動化されるべきタスクに費やされているからです。
CS現場を疲弊させる「振り分け」という見えないコスト
皆さんのチームでも、こんなことは起きていませんか？
朝一番、マネージャーやベテランオペレーターが数百件の未処理チケットを目視で確認し、「これは技術チーム」「これは請求担当」「これはスパム」と手作業でタグ付けしていく。この作業だけで貴重な午前中の数時間が消えてしまう。
この「トリアージ（選別）」という作業は、顧客にとっては「待ち時間」でしかありません。どんなに素晴らしい回答を用意していても、担当者に届くまでに数時間かかってしまっては、顧客満足度（CSAT）は低下する一方です。まさに、見えないコストがCX（顧客体験）を蝕んでいる状態です。
ルールベースの限界とAIへの期待値のズレ
「うちはキーワードで自動振り分けしているから大丈夫」
そうおっしゃる方もいるでしょう。確かに、「請求書」という単語があれば経理チームへ、「ログインできない」があればテクニカルサポートへ飛ばす、といったルールベース（If-Thenルール）の自動化は、初期段階では有効です。
しかし、自然言語は複雑で多義的です。
「ログインできないから、請求書が見られないんです」
こう書かれていた場合、単純なキーワードマッチングでは、「請求書」に反応して経理に飛ばすか、「ログイン」に反応してテクニカルに飛ばすか、あるいは競合してエラーになるかです。文脈（Context）を理解しなければ、正しい判断はできません。
ここで登場するのが、急速に進化を続ける自然言語処理（NLP）技術です。現在、AIによる言語理解は新たなフェーズに突入しています。最新のLLM（大規模言語モデル）はマルチモーダル化が進み、テキスト情報だけでなく、音声データから直接ニュアンスを理解したり、高度な推論機能によって複雑な文脈を解き明かしたりすることが可能になりました。
例えば、Liquid AIなどが開発する最新の音声言語モデルでは、音声をテキストに変換するプロセスを経ずに、顧客の声色から感情や緊急度を直接解析する技術も実用化されています。また、同じ問いかけを内部で反復することで推論精度を高める手法など、技術的なブレイクスルーは枚挙にいとまがありません。
しかし、多くの現場がここで「AIなら魔法のように100%正しく振り分けてくれるはずだ」という過度な期待を持ってしまい、最初のボタンを掛け違えます。
技術の本質を見抜く観点から、厳しい現実にも目を向ける必要があります。AIの文脈理解能力や推論能力は飛躍的に向上しましたが、それでも「魔法の杖」ではありません。導入すれば自動的にすべてが解決するわけではなく、その特性を理解し、適切なデータを与え、継続的に精度を改善していくプロセスが不可欠です。最新のAI技術トレンドを踏まえつつ、チケット自動振り分けを成功させるための、実践的なエンジニアリング・アプローチを解説します。
Q1 多くの企業が陥る「精度の罠」とは？
── HARITAさん、AI導入で最初に直面する壁は何でしょうか？
HARITA：
ズバリ、「精度の呪縛」ですね。これはAIプロジェクトの失敗原因として非常に多く見られます。
導入担当者の方は、PoC（概念実証）の段階でベンダーにこう聞くことがよくあります。「このAIの分類精度（Accuracy）は何パーセントですか？」と。そしてベンダーは、きれいに整備されたテストデータでの結果として「90%以上です」と答える。でも、いざ自社のノイズだらけの本番データを入れてみると、60%程度しか当たらない。「話が違うじゃないか！」となって、プロジェクトが頓挫する。このパターンは枚挙に暇がありません。
「100%自動化」という幻想を捨てる勇気
実務の現場における傾向として、初期導入でいきなり実運用上の精度が90%を超えることは稀です。なぜなら、AIモデルの問題以前に、各現場ごとに「正解」の定義が曖昧だからです。
例えば、「パスワードリセット」と「ログイン不可」というカテゴリがあったとします。これらは意味的に重複していますよね？ パスワードを忘れてログインできないケースは、どちらに分類すべきでしょうか？ 人間でも迷うような境界線（Decision Boundary）が曖昧なチケットを、学習したばかりのAIが完璧に分離できるわけがありません。
導入プロジェクトにおいて推奨されるのは、次のようなスタンスです。
「最初は精度60〜70%で上出来だと考えましょう。残りの30%は間違えます。でも、その間違いを許容できるプロセスを組む方が、精度を上げるために何ヶ月もモデルチューニングに時間を費やすより、よほどビジネス価値があります」
まず動くものを作り、全体像を捉えることが重要です。局所的な「AIモデルの正解率」だけを最適化しようとすると、全体としての「業務プロセスの改善」が遅れてしまうのです。
AIが得意な領域と人間がカバーすべき領域：自信度の活用
重要なのは、AIの予測結果を「0か1か」で扱わないことです。
Transformerアーキテクチャを採用したモデル（BERTなどの従来型モデルや、最新のLLMを含む）の多くは、分類結果と同時に「自信度（Confidence Score）」という確率や確信度を出力できます。これを活用したフロー設計こそが、エンジニアリングの勘所です。
システムに組み込む際の実装面について補足します。これらのモデルを稼働させる基盤として広く使われるHugging Face Transformersの最新環境では、内部設計がモジュール型へと刷新され、PyTorch中心の最適化が進んでいます。その一方で、TensorFlowやFlaxのサポートは終了しました。もし過去にTensorFlowベースで構築した分類モデルを運用している場合は、PyTorchベースへの移行を計画することが推奨されます。最新環境ではtransformers serveを活用してOpenAI互換APIとして容易にデプロイできるため、外部ツールとの連携や移行プロセス自体はスムーズに行えます。
効果的なアプローチとして、以下のような「3層のトリアージフロー」を設計することが推奨されます。
- 高信頼ゾーン（自信度 0.9以上）： 自動で担当チームへ振り分け、即時対応フローへ回す。ここはAIに任せます。
- グレーゾーン（自信度 0.6〜0.89）： 一応振り分けるが、「要確認」フラグを立てて、人間のオペレーターがサッと目視確認するキューに入れる。
- 低信頼ゾーン（自信度 0.6未満）： 無理に分類せず「その他／未分類」として、ベテランオペレーターのトリアージボックスへ回す。
このように、AIの判断を絶対視せず、スコアに応じた条件分岐（Thresholding）を行うことで、誤分類（False Positive）のリスクをコントロールできます。「AIが間違えたらどうするんだ！」と怒るのではなく、「自信がない時は人間にエスカレーションさせる」ように設計するのが、賢いAIアーキテクチャと言えるでしょう。
Q2 ツール選定で見落とされがちな「教師データ」の質
── ツール選びよりも大切なことがあるそうですね。
HARITA：
ええ、ツールやアルゴリズムの選定なんて、全体の工程の2割程度です。残りの8割は、皆さんの手元にある「データ」の準備にかかっています。
データサイエンスの世界には「Garbage In, Garbage Out（ゴミを入れればゴミが出てくる）」という絶対的な法則があります。どんなに高性能なLLM（大規模言語モデル）を使っても、学習データや参照データが汚れていれば、出力される結果は信頼できません。
ゴミデータを学習させてもゴミしか出てこない
一般的な傾向として、過去の問い合わせ履歴（チケットログ）を分析すると、AI学習用としては非常に厳しい状況に直面することが多くあります。
- カテゴリの不均衡： 「その他」というラベルが全体の40%を占めている。
- ラベルの一貫性欠如： 同じ「ログインできない」事象に対して、Aさんは「機能不全」、Bさんは「アカウント管理」とタグ付けしている。
- 陳腐化したデータ： すでに終了したサービスのカテゴリや、古い用語が残ったままになっている。
こんな状態でAIをトレーニングしても、AIは「人間の迷い」や「矛盾」まで学習してしまいます。
過去のチケット履歴をAI用に整備するステップ
では、どうすればいいか。AI導入プロジェクトの最初のステップは、ツールの契約ではなく、「タグ付けの断捨離（データクレンジング）」です。
- タクソノミー（分類体系）の再定義： 似たようなカテゴリは統合し、階層を深くしすぎない（2階層までが理想）。AIにとって識別しやすい明確な定義を作ります。
- 「その他」の撲滅： 「その他」に入っているチケットを分析し、主要なトピックを抽出して新しいカテゴリを作るか、既存のカテゴリに振り分けます。
- ゴールドデータの作成（アノテーション）： 過去数年分のデータを全て使う必要はありません。直近3ヶ月〜半年分のデータだけで良いので、ベテランオペレーターが手動で正しいタグを付け直した「正解データセット」を作成します。
特に3つ目が重要です。数万件のノイズ混じりのデータより、1,000件の「磨き上げられた高品質なデータ」の方が、AIの学習効率と精度においてはるかに価値があります。
適切に導入した場合、全社員で集中的に過去のチケットのタグ修正を行うことで、振り分け精度が一気に85%まで向上した事例もあります。AIは正直なんです。良い教科書を与えれば、ちゃんと賢くなります。
Q3 導入効果を最大化する「エスカレーション設計」の極意
── 正しく振り分けられた後、どう業務効率化につなげるかが課題ですね。
HARITA：
その通りです。振り分け（Classification）はゴールではなく、ワークフローの始点に過ぎません。AIによって「誰が対応すべきか」が瞬時に決まった後、そのチケットをどう最速で解決（Resolution）に導くかが腕の見せ所です。
振り分けはゴールではなくスタート
AIによる自動分類の最大のメリットは、チケットの内容を解析する過程で、単なるカテゴリ以外のメタデータも抽出できる点です。
具体的には、顧客の「感情（Sentiment）」や「緊急度（Urgency）」です。
例えば、「システムダウン」や「損害」という単語が含まれ、かつ感情分析で「激怒（Negative High）」と判定されたチケットを想像してください。これを通常のキューに入れて順番待ちさせるのは危険です。AIがこれを検知したら、通常のフローをバイパスして、いきなりマネージャークラスの「緊急対応チーム（SWAT）」にSlack通知と共に割り当てる。
逆に、「パスワード変更方法」のような定型的な質問で、感情がフラットなものは、自動応答ボット（チャットボット）に誘導するか、入社間もないジュニアオペレーターに優先的に割り当てる。
これにより、一次解決率（FCR: First Contact Resolution）が劇的に向上します。適切なスキルを持つ人間が、最初からボールを持てるからです。
スキルベースルーティングとの掛け合わせ
ここで技術的に実装すべきなのが、「スキルベースルーティング」です。
オペレーター一人ひとりのスキルセット（担当製品、対応言語、得意分野、技術レベル）をデータベース化しておき、AIが分類したカテゴリとリアルタイムでマッチングさせるのです。
- AIの出力： カテゴリ「API連携エラー」 / 言語「英語」 / 難易度「高」
- ルーティングロジック： 「API知識あり」AND「英語対応可能」AND「シニアレベル」のオペレーターを検索
ここまで自動化できて初めて、CSの生産性は爆発的に上がります。ベテランは「自分にしか解けない難問」に集中でき、新人は「自分のレベルに合った案件」で経験を積める。AIは、人間の仕事を奪うのではなく、人間が「適材適所」で輝くためのロジスティクスを担うのです。
Q4 失敗しないための段階的導入ロードマップ
── 具体的にどのような手順で導入を進めればよいでしょうか？
HARITA：
焦りは禁物です。「来月から全自動化します！」と宣言してしまえば、現場は混乱し、誤分類によるクレーム対応でプロジェクト自体が頓挫しかねません。業務システム設計の観点から、リスクを管理しながら進める必要があります。
実務において強く推奨されるのは、「Crawl, Walk, Run（這って、歩いて、走る）」という段階的なデプロイモデルです。
全件適用ではなく「自信のあるカテゴリ」から
Phase 1: シャドーモード（Crawl）
まずは、AIを実際の振り分け業務には適用せず、バックグラウンドで推論のみを実行させます。人間が実際に振り分けた結果と、AIの予測結果をログとして記録し、突き合わせを行います。
この段階で、正解率（Accuracy）だけでなく、見逃しがないか（再現率：Recall）、誤検知が多すぎないか（適合率：Precision）といった指標を厳密に計測し、モデルの特性や「癖」を把握します。現場のオペレーションには一切影響を与えません。
Phase 2: ハイブリッド運用（Walk）
次に、AIの確信度（Confidence Score）が高いチケット（例えば98%以上）や、「パスワードリセット」「資料請求」といった定型的でミスのリスクが低いカテゴリに限定して、自動振り分けを開始します。
それ以外のグレーゾーンにあるチケットは、従来通り人間が目視で判断します。これにより、リスクを最小限に抑えながら、徐々に自動化による工数削減効果を実証できます。
Phase 3: 本格運用と継続的な最適化（Run）
精度が安定し、現場の信頼が得られてきたら、適用範囲を広げ、確信度の閾値を慎重に調整（例：98%→90%）していきます。
ただし、ここでも「完全放置」は危険です。AIモデルのパフォーマンスを定期的にモニタリングし、異常があれば即座に介入できる体制を維持します。
AIの判断に対するフィードバックループの構築
AIシステム導入において、技術的なモデル選定以上に重要なのが、「Human-in-the-loop（人間参加型ループ）」の設計です。
AIが誤って振り分けたチケットを受け取ったオペレーターが、CRMやチケット管理画面上で、ワンクリックで「振り分けミスを報告（正しいカテゴリを選択）」できる直感的なUIを用意することが不可欠です。そして、その修正データが自動的にAIの再学習用データセットに蓄積され、モデルを更新するパイプライン（MLOps/LLMOps）を構築します。
現場のスタッフには、こう伝えてマインドセットを変えてもらいましょう。
「AIが間違えたら、怒らずに正解を教えてあげてください。それが、新しい同僚であるAIを賢くする唯一の方法なのです」と。
このフィードバックループが回っている現場のAIは、日々賢くなり、新しい問い合わせトレンドや用語の変化にも適応していきます。逆に、この仕組みがないと、AIモデルは現実のデータ分布とのズレ（データドリフト）を起こし、徐々に精度が低下して陳腐化してしまいます。
AI導入は、一度きりの「購入」ではなく、終わりのない「育成」プロセスであると認識してください。
編集後記：AIは「魔法の杖」ではなく「新人の部下」である
最後までお読みいただき、ありがとうございます。
ここまで、技術的な指標やプロセスフローの話をしてきましたが、最後に一番大切なマインドセットの話をさせてください。
AIツールを導入するということは、単に新しいソフトウェアをインストールすることではありません。「とてつもなく処理能力は高いが、まだ世間知らずな新人の部下」をチームに迎え入れることだと考えてください。
新人がミスをしたとき、あなたならどうしますか？ 頭ごなしに怒鳴って「使えない」と切り捨てますか？ しませんよね。「なぜ間違えたのか」を一緒に考え、正しいやり方を教え、得意な仕事を任せるはずです。
AIも同じです。最初から完璧なAIなんて存在しません。あなたのチームの文化、顧客の言葉のニュアンス、製品の特性……それらを根気強くデータとして教えていくことで、AIはあなたのチームにとってかけがえのない「最強の戦力」に育っていきます。
「AI対人間」の対立構造で捉えるのではなく、「AIと人間」の協働構造を作る。
AIの不完全さを理解し、それを運用でカバーしながら、共に成長していくプロセスを楽しめる現場こそが、これからの時代、最高の顧客体験を提供できると考えます。
さあ、まずは「タグ付けの断捨離」から始めてみませんか？ きっと、新しい景色が見えてくるはずです。
コメント