AIのPoCが本番につながらない理由は、PoCの技術精度だけではありません。そもそも「何を実現するためのPoCなのか」と、「PoCで何を確認できれば次へ進むのか」が決まっていないことが大きな原因だと考えています。
「とりあえずAIでPoCをやってみよう」。生成AIが普及して以降、こうした話を聞く機会は増えました。
※本記事には、当社の実務経験に基づく個人的な見解を含みます。
PoCが目的になった瞬間、本番につながりにくくなる
PoCはProof of Concept、つまり概念実証です。
本来は、最終的に実現したいことがあり、その途中で技術的・業務的に成立するかを確認するための手段です。
ところが、「まずAIを使ってみよう」「この業務だけPoCしてみよう」と、PoCそのものが目的になるケースがあります。
こうなると、PoCが終わった後に「で、次はどうするのか」が決まりません。
最初に決めるべきは、PoCではなく最終ゴール
重要なのは、最終的なゴールから逆算することです。
例えば最終目標が「経理処理を月40時間削減する」であれば、そのためにAIで証憑分類が実用になるかをPoCで確認する、という順番になります。
逆に「AIで証憑分類をPoCする」だけでは、精度が80%だったときに成功なのか失敗なのか判断できません。
最終的に何を実現したいのか。そのためにPoCで何を確認するのか。
この2つをセットで決める必要があります。
PoCの達成条件を開始前に決める
PoCを始める前に、終了条件と次の判断を決めておくべきだと考えています。
- どの技術要件を確認するのか
- どの精度なら業務で使えるのか
- 現場オペレーションに組み込めるか
- セキュリティ上の問題はないか
- 本番化したときの費用対効果は成立するか
- 成功したら次に何をするか
- 失敗したら何を変更するか、または中止するか
PoCの結果が「やらない方がいい」という判断でも構いません。意思決定に必要な情報が得られたなら、そのPoCには意味があります。
「PoC止まり」は、コミュニケーション不足で起きる
個人的には、「PoC止まり」がなぜ頻繁に起きるのかは、それほど不思議な話ではないと思っています。
何かを解決するためにPoCをするのであれば、その「何か」が明確なら、PoC後の判断もある程度決まるはずだからです。
それでも止まるということは、発注者と受託側の間で、そもそもの目的や成功条件を十分に話し合わずに始めている可能性があります。
「誰がこのPoCを選んだのか」より、「なぜこのPoCをやるのかを双方が理解しているか」の方が重要です。
PoCを始めない、という判断も重要
目的が曖昧な状態なら、無理にPoCを始めない方がよい場合もあります。
「まずやってみましょう」は、一見スピード感があります。しかし、最終目標が決まっていなければ、終わった後に成果を評価できません。
PoCの前に業務を整理し、本当に検証すべき箇所を決める。それ自体が重要な設計作業です。
PoC後に止まるもう一つの理由は、As-IsとTo-Beを離しすぎること
もう一つ、PoCが本番につながりにくくなる理由として、私はAs-IsとTo-Beを離しすぎることがあると考えています。
最終目的が明確でも、本番化の段階で「既存システムを大きく入れ替える」「現場のオペレーションを全面的に変える」となると、現場への負荷が一気に大きくなります。
PoCでは一部だけを試せたとしても、本丸へ進む瞬間に、教育、移行、データ連携、権限設計、既存システムとの切り替えなど、大掛かりな話になる。そこで現場から反発が出たり、導入コストが膨らんだりして、止まるケースは十分に考えられます。
システムに人を合わせるのではなく、人にシステムを合わせる
個人的には、AIが使えるようになった今だからこそ、従来とは逆の発想が取りやすくなると思っています。
これまではパッケージや基幹システムに合わせて、現場の業務フローを変えることが多くありました。一方で今後は、会社ごとの既存オペレーションをできるだけ残しながら、その上にAIや連携処理を組み合わせて、必要な情報を自動的に構造化・蓄積する形を作りやすくなるはずです。
もちろん、非効率な業務や根本的に問題のある運用まで残すべきだとは考えていません。本当に変える必要がある部分は変える。ただし、目的達成に関係のない部分まで「新システムに合わせるため」という理由だけで変える必要はない、という考え方です。
現場はほぼ変わらないのに、経営側から見ると大きく変わる状態を作る
目指したいのは、現場から見ると今までとほとんど同じように仕事をしているのに、その裏側では必要な情報が取れるようになり、データがつながり、経営分析や意思決定に使える状態になっていることです。
例えば、これまでチャットや口頭で行っていた業務を無理に新しい画面へ移すのではなく、今までのやり取りを残しながら、必要な情報だけを自動で抽出して台帳へ反映する。現場の操作はほとんど変わらなくても、経営側にはこれまで見えなかったデータが蓄積されるようになります。
この状態を作れれば、PoCと本番の間にある「大規模な業務変更」という壁を小さくできます。
現場への変化は最小限に、経営側の変化は最大限にする。
私は、AI時代のシステム導入では、この設計思想がより重要になると考えています。
PoCから本番までを最初から一つの流れとして設計する
OpenAIのFDE関連職種でも、PoCと本番導入を分断せず、顧客の業務・成功条件を整理し、プロトタイプから本番展開までを一貫して扱う考え方が示されています。
PoCの時点から、本番で必要になる権限、データ、運用、セキュリティ、利用者、評価方法を意識しておけば、PoC後の移行はスムーズになります。
BLP型FDEでは、PoCの前に課題を定義する
BLP型FDEでは、「何のPoCをやるか」から入るのではなく、まず会社の課題と最終目標を確認します。
その上で、本当にPoCが必要なのか、既存ツールで検証できないか、小さく本番投入した方がよくないかも含めて判断します。
PoCは目的ではなく、選択肢の一つです。
FDEとは？Forward Deployed Engineerの役割と、なぜ「誰でもFDE」は難しいのか →
まとめ：PoCの成功は「本番化したか」だけではない
PoCを本番につなげるために最も重要なのは、PoC前に最終ゴールと達成条件を決めることです。
最終ゴール → 検証したい仮説 → PoCの達成条件 → 次の意思決定。
この順番で設計し、さらに本番化の際にAs-IsとTo-Beを必要以上に離さず、現場のオペレーション変更を最小限に抑えられれば、PoCが単なる「やってみた」で終わる可能性は大きく下げられると考えています。現場はほぼ変わらない一方で、必要な情報が取れ、経営分析や意思決定は大きく変わる。AI時代には、そうした本番設計が重要になるはずです。
参考：
OpenAI – Deployment Lead, FDE
OpenAI – Forward Deployed Software Engineer