ストーリー
田
田中VPoE
「フィージビリティ評価でConditional Goとなった。次はPoC（Proof of Concept: 概念実証）を設計する。PoC地獄に陥らないための設計がポイントだ。」
あなた
「Step 1で学んだPoC倒れの対策ですね。」
あ
田
田中VPoE
「そうだ。PoC目的を明確にし、成功基準を定量的に設定し、期間を区切る。これがPoC成功の3原則だ。」
あなた
「目的・基準・期間の3つですね。」
あ
田
田中VPoE
「加えて、データ準備と本番移行計画もPoCの段階から設計しておく。本番を見据えたPoCが重要だ。」
PoC設計の5要素
| 要素 | 内容 | 重要性 |
|---|---|---|
| 1. 目的設定 | PoCで何を検証するのか | 最も重要。目的が曖昧だとPoC地獄に |
| 2. 成功基準 | 何をもって成功とするか | 定量的な基準がないと判断できない |
| 3. データ準備 | PoCに使うデータの設計 | 本番データに近いデータを使う |
| 4. 期間設計 | PoCの実施期間 | 長すぎず短すぎない適切な期間 |
| 5. 本番移行計画 | PoC後のステップ | PoCと同時に計画しておく |
1. 目的設定
PoCの目的の種類
| 目的タイプ | 検証すること | 例 |
|---|---|---|
| 技術検証 | この技術で実現可能か | RAGの回答精度は業務要件を満たすか |
| ビジネス検証 | 期待した効果が得られるか | 工数削減効果は見込み通りか |
| ユーザー検証 | ユーザーに受け入れられるか | CS部のオペレーターは使ってくれるか |
| 統合検証 | 既存システムと統合できるか | Zendeskとの連携は問題ないか |
NetShop社FAQ自動回答のPoC目的
PoC目的:
1. [技術検証] RAGベースのチャットボットが定型質問に85%以上の正答率で回答できることを実証
2. [ビジネス検証] 定型質問の50%を自動回答することでCS部の月間工数を400h削減できることを実証
3. [ユーザー検証] 顧客満足度を維持しながらAI自動回答への切り替えが受容されることを実証2. 成功基準
SMART基準で設定
| 要素 | 意味 | FAQ自動回答の例 |
|---|---|---|
| Specific | 具体的 | 定型質問への自動回答の正答率 |
| Measurable | 測定可能 | 正答率85%以上 |
| Achievable | 達成可能 | 類似事例で80-90%の実績あり |
| Relevant | 関連性 | CS部の工数削減に直結 |
| Time-bound | 期限付き | 3ヶ月以内にPoC完了 |
成功基準の設定
| 指標 | 最低基準（Must） | 目標値（Want） | 測定方法 |
|---|---|---|---|
| 正答率 | 80%以上 | 90%以上 | 人間評価者による100件サンプリング |
| 自動回答率 | 30%以上 | 50%以上 | 自動回答数 / 総問い合わせ数 |
| 応答時間 | 10秒以内 | 5秒以内 | システムログの応答時間 |
| 顧客満足度 | 現状維持 | 5%向上 | アンケートスコア |
| エスカレーション率 | 70%以下 | 50%以下 | 人間にエスカレーションされた割合 |
撤退基準
| 状況 | 撤退判断 |
|---|---|
| 正答率が60%未満 | データ品質に根本的な問題がある可能性。PoC中止を検討 |
| 顧客クレームが発生 | 即座にAI回答を停止し、原因を分析 |
| 2ヶ月経過で進捗30%未満 | 計画の見直し、または中止を検討 |
3. データ準備
PoCデータの設計方針
| 方針 | 理由 |
|---|---|
| 本番データに近いデータを使用 | PoC用の綺麗なデータでは本番の精度を正しく評価できない |
| 代表的なカテゴリをカバー | 全カテゴリの中から頻出パターンを選定 |
| エッジケースを含める | 難しいケースでの挙動も確認 |
| 個人情報をマスキング | プライバシー保護のため |
NetShop社FAQ自動回答のデータ準備計画
| データ | 現状 | 準備作業 | 期間 |
|---|---|---|---|
| FAQデータ | 200件（分類不統一） | カテゴリ再分類、回答の品質確認 | 2週間 |
| 問い合わせログ | 30万件 | カテゴリタグの統一、個人情報マスキング | 2週間 |
| 評価用データ | なし | 100件のテストケース作成（正解付き） | 1週間 |
| エッジケース | なし | 30件の難易度の高いケースを選定 | 1週間 |
4. 期間設計
PoC期間の目安
| ユースケースの複雑度 | 推奨期間 |
|---|---|
| 低（既存ツール活用） | 2-4週間 |
| 中（カスタム開発） | 1-2ヶ月 |
| 高（新技術・複雑な統合） | 2-3ヶ月 |
NetShop社FAQ自動回答のPoCスケジュール
| 週 | フェーズ | 実施内容 | 成果物 |
|---|---|---|---|
| Week 1-2 | データ準備 | FAQ整理、ログのクレンジング | 整備済みデータセット |
| Week 3-4 | プロトタイプ開発 | RAG構築、チャットUI開発 | 動作するプロトタイプ |
| Week 5-6 | 内部テスト | CS部のベテラン5名でテスト | テスト結果レポート |
| Week 7-8 | パイロット運用 | 一部の顧客に限定公開 | パイロット結果データ |
| Week 9-10 | 評価・改善 | 成功基準との照合、改善 | PoC評価レポート |
| Week 11-12 | Go/No-Go判断 | 経営会議での報告・判断 | Go/No-Go判断書 |
5. 本番移行計画
PoCから本番への移行で必要なこと
| 項目 | PoC段階 | 本番段階 | ギャップ |
|---|---|---|---|
| データ量 | 200件のFAQ | 全FAQ＋ナレッジベース | 3倍のデータ整備 |
| 負荷 | 5名のテスター | 月3万件の問い合わせ | スケーラビリティ設計 |
| 可用性 | ダウンタイム許容 | 99.5%以上の稼働率 | 冗長構成の構築 |
| セキュリティ | 基本対策 | 本番レベルの対策 | DLP、監査ログ等 |
| 運用体制 | AI推進チーム | 24/7の監視体制 | 運用チームの構築 |
まとめ
| 項目 | ポイント |
|---|---|
| 5要素 | 目的、成功基準、データ準備、期間設計、本番移行計画 |
| 目的設定 | 技術・ビジネス・ユーザー・統合の4タイプで明確化 |
| 成功基準 | SMART基準で定量的に設定。撤退基準も事前に定義 |
| データ準備 | 本番データに近いデータを使用。個人情報はマスキング |
| 期間設計 | 複雑度に応じて2週間〜3ヶ月で区切る |
| 本番移行 | PoCと本番のギャップを事前に把握し計画に組み込む |
チェックリスト
- PoC設計の5要素を説明できる
- 成功基準のSMART設定ができる
- 撤退基準の重要性を理解した
- PoCから本番移行のギャップを把握した
次のステップへ
次は「Go/No-Go判断基準」として、PoC結果をどう評価し、本番移行を判断するかを学ぼう。
推定読了時間: 30分