【導入事例】大手通信会社様 ― 生成AI活用のPoC地獄を脱却。3ヶ月で本番稼働まで伴走した実践記録

プロジェクト概要

背景と課題

同社は、カスタマーサポート部門で生成AIを活用したいと考え、過去2回PoCを実施していた。しかし、いずれも「PoCとしては成功」と評価されながら、本番導入には至らなかった。

過去のPoC失敗の構造的要因:

• 1回目（大手SIer主導）: 技術的には動いたが、現場のオペレーターが使い方を理解できず、「結局人が対応した方が早い」という結論に
• 2回目（AIベンダー主導）: 精度は高かったが、既存のCRMシステムとの連携が技術的に困難。インテグレーション費用が当初見積もりの3倍になり凍結

同社のDX推進部長は、こう振り返る。

> 「PoCは"うまくいった"のに、本番には進めない。この繰り返しで、社内のAIへの期待が冷めてきていた」

Wizitのアプローチ

なぜWizitに声がかかったか

Wizitの代表・立道は、外資系コンサルティングファーム時代から大企業のDXプロジェクトに多数携わり、「戦略は立てたが実行されない」という問題を何度も目の当たりにしてきた。その経験から、Wizitは「PoCから本番まで一気通貫で伴走する」ことを基本スタンスとしている。

同社のケースでは、GX（GenerativeX）社経由で案件を受託。GXとの協業体制のもと、Wizitが実装の現場に深く入り込む形でプロジェクトを進めた。

Phase 1: 失敗分析と再設計（1〜2週目）

まず、過去2回のPoCが「なぜ本番に進めなかったか」を徹底分析した。

発見した3つの根本原因:

• 技術と業務の分離 : AIの精度は検証したが、オペレーターの業務フローへの組み込み方を設計していなかった
• システム連携の後回し : CRM連携を「本番化の際に対応」としていたが、それが最大のハードルだった
• 成功基準の曖昧さ : 「PoCが成功したら本番化」としていたが、「何をもって成功とするか」が定義されていなかった

この分析を踏まえ、「本番稼働から逆算したPoC設計」に切り替えた。

Phase 2: 本番逆算型PoC（3〜6週目）

従来のPoCとの最大の違いは、最初からCRM連携と業務フロー統合を含めて検証した点だ。

技術構成:

• 生成AI（LLM）による問い合わせ内容の自動分類・回答案生成
• 既存CRM（Salesforce）とのリアルタイムAPI連携
• オペレーター向けUIの設計（AIの回答を「参考情報」として表示）

業務設計のポイント:

• オペレーターが「AIの回答をそのまま送信」するのではなく、「AIの下書きを確認・修正して送信」するワークフローを設計
• これにより、AI精度が100%でなくても運用可能な仕組みにした
• オペレーターのフィードバックを学習データとして蓄積する循環を構築

Phase 3: 本番稼働と定着化（7〜12週目）

PoCの結果を踏まえ、段階的に本番展開。まず問い合わせの3カテゴリ（料金プラン、契約変更、障害報告）から開始し、2週間ごとに対象カテゴリを追加。

定着化の工夫:

• 現場リーダー3名を「AIチャンピオン」に任命し、チーム内での普及を推進
• 週次の改善ミーティングで、AIの回答精度とオペレーターの利用率を可視化
• 「AIが苦手な質問パターン」を収集し、継続的にプロンプトを改善

成果

定量成果

定性成果

• 「PoC地獄」からの脱却: 3度目の挑戦で本番稼働を実現。社内のAIへの信頼が回復
• オペレーターの意識変化: 「AIに仕事を奪われる」から「AIが面倒な下調べをしてくれる」へ
• 継続改善の文化: オペレーター自身がAIの改善提案を出す仕組みが定着

Wizitの支援で重視したこと

このプロジェクトで最も重視したのは、「技術の完成度」より「業務に組み込めるか」という視点だ。

過去2回のPoCは、AI単体の精度を追求するあまり、現場のオペレーターが実際に使えるかどうかを後回しにしていた。Wizitは逆のアプローチを取り、「80%の精度でも、オペレーターの業務に自然に組み込めるなら、それは本番稼働できる」という判断基準を設定した。

代表の立道が外資コンサル時代に何度も見てきた「素晴らしい戦略が実行されない」問題。その根本原因は、現場の業務実態を軽視した設計にあった。この経験が、Wizitの「業務起点のAI実装」というアプローチの原点になっている。