生成AIのPoC（概念実証）で機能が動いても、そのまま日々の業務で使えるとは限りません。実際の利用者、参照する情報、人が確認する判断、導入後の担当者まで決める必要があります。FDE×AIの取り組みを、試作から業務定着までどうつなぐか。アンドドットの常駐型FDEの公開情報をもとに、進め方と各段階の確認点を整理します。
FDE×AIは、現場の課題から運用改善までつなぐ進め方
AIを使うこと自体を目的にしない
アンドドットの常駐型FDEの公式ページでは、FDEが顧客の業務を最前線で理解し、課題の発見、解決策の提示、システム開発、運用定着まで繰り返す役割として説明されています。近年は、生成AIを業務に使いこなせる人材の不足も、企業の課題として挙げています。
この進め方では、最初からAIの利用を決めません。困っている業務を調べた結果、手順の変更や既存システムの改善が適切な場合もあります。AIを使う場合も、何の判断を助け、どの作業を短くしたいのかを先に言葉にします。
PoCの成功と業務での利用を分けて確かめる
PoCで確認できるのは、選んだ条件で技術的に動くかどうかです。実務では、例外的な問い合わせ、古い資料、権限の違い、利用者による確認作業なども加わります。試作の評価を、業務全体の成果と同じ意味で扱わないことが大切です。
PoCの開始時に「次の段階へ進む条件」を決めます。例えば、利用者が日々の手順の中で使えるか、誤った出力を誰が見つけて直すか、参照情報を更新できるかです。これらは業務ごとに設計する確認項目であり、特定の数値目標を一律に当てはめるものではありません。
PoCから定着へ進める4つの段階
1. 現場の仕事と課題を確かめる
「問い合わせをAIで自動化したい」という依頼なら、まず誰からどんな質問が来て、担当者が何を調べて答えているかを確認します。回答が遅れる原因が情報の散在なのか、判断権限の不足なのかで、解決策は変わります。FDEの役割は、依頼された機能の背景にある業務課題を見つけることから始まります。
対象を広げすぎず、最初に試す業務と利用者を絞ります。現在の作業手順、頻度、困りごとを記録し、改善後に同じ観点で比べられる状態を作ります。社内側も、課題の優先順位を決める担当者を置きます。
2. AIを含む解決策を比較して合意する
公式ページのFDEジャーニーは、課題を捉えた後、複数案を業務への効果、実装難易度、運用負荷で比べ、顧客と進め方を合意する段階を示しています。AIによる回答生成だけでなく、資料の整理、検索の改善、承認手順の見直しも候補になります。
AIを使う案では、参照する情報の範囲、誤りが起きた場合の影響、人が確認する工程を明らかにします。必要な情報へアクセスできるか、権限をどう扱うかも確認します。業務の責任者が、効果だけでなく運用上の負担を見て採否を決めます。
3. 小さく実装し、現場で試して直す
公式ページでは、常駐型FDUが小さく開発して現場で試し、利用者のフィードバックを反映する進め方を掲げています。試作を見せるだけでなく、利用者が実際の業務でどこにつまずくかを記録します。期待した答えが出ないときは、入力、参照資料、業務手順のどこを見直すべきかを分けて考えます。
変更の判断者と、試す範囲を先に決めます。機能を増やす前に、対象業務で必要な最低限の動きが安定しているかを確認します。現場の声を受けて課題の定義そのものを見直す場合もあり、初期の仕様を守ることだけを成功とはしません。
4. 運用担当と改善の仕組みを残す
使う業務と担当者が決まらなければ、PoCの成果物は日常の仕事に入りません。公式ページが示す最後の段階は「社内での定着・運用」です。FDEが抜けた後も運用と改善を続けられる状態を意識しています。
社内の担当者へ、参照資料の更新方法、利用者からの問い合わせ先、問題が起きたときの判断と修正の手順を引き継ぎます。利用状況を誰が、どの間隔で見て、改善を決めるかも合意します。外部の支援を続ける範囲と、社内へ移す範囲を分けておきます。
PoCの次へ進む前に合意したい3つの判断
業務の変化を何で確かめるか
「AIが回答できた」だけでは業務の改善を判断できません。対象となる問い合わせや書類作成などについて、作業時間、確認の手間、手戻り、利用者の困りごとを開始前から記録します。指標は業務に合わせて選び、誰が集計するかを決めます。
件数が少ない試行では、短期間の変化を一般化しないようにします。数字だけでなく、使われなかった理由や、人の確認が増えた場面も残します。判断に必要な材料をそろえることが、次の投資や対象拡大の前提です。
人が確認すべき場面をどこに置くか
生成AIの出力には誤りや不適切な内容が混ざり得ます。対外回答、重要な社内判断、個人情報を含む処理などでは、人が確認する範囲を業務ごとに決めます。試作段階で問題が見えなくても、対象データや利用者が増えれば確認方法を見直す必要があります。
確認担当者に負担が集中しないかも確かめます。AIを使った結果、作業を移しただけで全体の手間が減っていないなら、目的と手順を再検討します。技術の動作と業務上の安全性を別々に評価します。
情報と運用の責任者を誰にするか
参照する資料が古くなる、権限が変わる、利用者が増えるといった変化は、導入後に起こります。情報の管理者、システムの管理者、業務上の判断者を明確にします。FDE側が改善を提案する場合でも、企業側の意思決定を外部に丸投げしません。
運用開始後の問い合わせ、障害、誤回答への対応を誰が受け、いつ見直すかを決めておきます。引き継ぎ資料だけではなく、担当者が実際に更新と判断を行えるかを確認します。
公開されている活用例を自社へ当てはめるとき
定型問い合わせの自動回答
アンドドットの公開ページには、社内文書を参照して定型問い合わせに答える想定例があります。自社で検討する際は、質問の種類、参照資料の管理者、回答を人へ引き継ぐ条件を確認します。答えを生成する機能だけでなく、資料の更新と誤回答の訂正も運用に含めます。
企画書の初稿作成
過去案件や業界情報から企画書の初稿を作る想定例も示されています。自社では、再利用できる資料の範囲、機密情報の扱い、最終的に内容を確認する人を整理します。初稿の作成時間が短くなっても、事実確認や提案の判断に必要な時間は別に見ます。
公式ページに掲載された業種や数値を、実案件の成果として引用しません。自社の効果は、対象業務で測った実測値に基づいて判断します。ここで挙げた確認点は、公開された想定例を検討するための観点です。
企業が相談前にそろえたい5つの項目
技術の相談を業務の相談につなげる
FDE×AIの相談では、次の項目をそろえると、PoCの範囲とその後の運用を話しやすくなります。
対象業務：誰の、どの作業や判断を改善したいか。
現状：現在の手順、困りごと、利用件数をどう確かめるか。
情報：参照する資料と、その更新・アクセス権を誰が管理するか。
判断：AIの出力を誰が確認し、次の段階へ進む条件を誰が決めるか。
運用：導入後の担当、問い合わせ、改善の優先順位をどう決めるか。
料金、契約条件、具体的な対応範囲は公開情報だけでは確定できません。業務の前提と期待する変化を共有したうえで、個別の提案内容を確認してください。
FDE×AIとPoCについてよくある質問
PoCが成功したら、そのまま本番運用できる？
試作で機能が動いたことと、日常の業務で使えることは別です。利用者、データと権限、人による確認、問題が起きたときの対応を確かめてから、本番で使う範囲を決めます。
AIを使わない方がよい業務もある？
あります。課題の原因が資料の整理不足や手順の不統一なら、まずその改善が必要です。FDE型の進め方でも、AIを含む複数の解決策を効果と運用負荷から比べて決めます。
まとめ：PoCの出口を業務の中に作る
アンドドットが挙げるDXの停滞点は、目的のずれ、課題の優先順位不足、解決策の選び違い、開発時の手戻り、成果を測れないことです。AIのPoCも、モデルが動いた段階ではこれらを解消したとは言えません。現場の真の課題を確かめ、AI以外も含めて案を比較し、小さく実装して利用状況と業務の変化を測るところまで設計します。
PoC後の運用まで見据えたら、誰が実装と定着を担うか、必要な費用をどう評価するか、社内で何を合意するかを整理します。次の3点セットには、FDE導入の進め方から費用・投資対効果、稟議・発注までの資料をまとめています。
