はじめに
生成AI導入がPoCで止まる理由は、モデルの精度だけでは説明できません。
本番導入で問われるのは、誰のどの業務を変えるのか、どの情報を参照してよいのか、誤回答時にどう止めるのか、どの指標で改善するのかです。これを現場で横断して進める役割が、FDE（Forward Deployed Engineer）です。
この記事では、AIチャットボットや業務支援AIを例に、FDE型で「作る前」「作る」「運用する」をどうつなぐかを整理します。
FDEは実装担当だけではない
FDEは顧客の現場で課題を見つけ、関係者と合意し、実装し、本番で使われる状態まで進める役割です。要件を受け取って納品するだけではなく、仮説の優先順位と成功条件そのものを一緒に定義します。
AI導入では特に、次の工程が分断されると失速しやすくなります。
- 課題設定: 問い合わせ削減、商品選び支援、社内検索など、最初の対象を一つに絞る
- 情報設計: 参照してよい文書、最新性の担保、回答禁止領域を決める
- 実装: 検索、プロンプト、権限、UI、既存システム連携を組み立てる
- 評価: 正答率だけでなく、解決率、有人引き継ぎ率、次の行動への接続率を確認する
- 定着: ログから不足情報を見つけ、FAQや業務フローも改善する
最初に固定したい「回答境界」
生成AIを使う際、最初に作るべきなのは派手な画面ではなく、回答境界です。少なくとも以下を文書化します。
- 参照元: 公開FAQ、商品データ、社内規程など
- 回答可能な質問: 例として配送条件、商品の仕様、社内手順
- 回答しない質問: 個人情報、契約判断、法務・医療・金融上の判断
- エスカレーション条件: 根拠がない、確信度が低い、権限外、緊急性がある場合
- ログ方針: 保持期間、閲覧者、個人情報マスキング、削除・停止の手順
RAGを採用しても、参照データが古い、権限が混ざる、根拠を返せない、といった問題は残ります。データ取得・分割・検索・回答生成の各段階で、どの情報が通ってよいかを確認できる設計にします。
PoCから本番へ進むための評価設計
PoCは「動く」だけでは十分ではありません。リリース前には、実際の問い合わせや業務ケースからテストセットを作り、合否基準を持ちます。
最低限の評価項目
| 観点 | 例 |
|---|---|
| 正確性 | 根拠に沿った回答か |
| 完全性 | 重要な条件や例外が抜けていないか |
| 安全性 | 回答禁止領域に踏み込まないか |
| 導線 | 正しいページ・担当者・次の操作へ案内できるか |
| 失敗時 | 不明と伝え、人へ引き継げるか |
テストは正常系だけでは足りません。曖昧な質問、指示の上書きを狙う入力、権限外の情報要求、古い文書しかないケース、連続送信、外部連携が失敗するケースまで確認します。
本番運用では「観測」と「戻せること」が重要
リリース後は、会話数だけを追っても改善点は見えません。FDE型の運用では、次のような指標を定期的に確認します。
- 回答後に自己解決または次のページへ進んだ割合
- 有人対応へ引き継いだ割合と理由
- 回答できなかった質問の分類
- 参照元ごとの利用頻度と更新状況
- エラー率、応答時間、利用上限への到達状況
加えて、設定・プロンプト・参照データを変更したときに、以前の状態へ戻せるようにしておくことが欠かせません。変更履歴、テストセット、リリース判断、ロールバック手順を小さくても残します。
まとめ
AIが実装を速くしても、「何を作るか」「安全に使えるか」「現場で価値が出たか」は自動では決まりません。FDEは、課題設定、実装、評価、運用を分断せずに扱うための実務的な役割です。
熊本でのAI・FDE導入支援と、より詳しい解説は以下にまとめています。