PoCと本番の間にある壁

PoCの結果が良く、社内の合意も取れた。それでも本番化が進まない、あるいは進めてみたら想定の何倍も時間がかかった。この落差は、PoCが悪かったから生まれるのではありません。PoCが意図的に削った部分が、本番では削れないからです。

削った部分は、大きく4つに分かれます。負荷、権限、例外データ、運用体制です。いずれも技術の難しさというより、「誰が責任を持つか」を決める設計の問題です。

壁1：負荷 — 件数と時間帯の偏り

PoCは数十件を手元で処理します。本番は、実際の業務量を、実際のタイミングで処理します。ここで出てくる論点は次のとおりです。

• 月間・日次の処理件数はどのくらいか
• 特定の時間帯や締め日に集中しないか
• 1件あたりの処理時間は、待たせてよい長さか
• 外部のAIサービス側で、一定時間あたりの呼び出し回数に制限がかかる場合の扱い

最後の点は見落とされがちです。既製のAI APIには利用量の制限があり、集中して呼び出すと待たされたり拒否されたりします。本番設計では、順番待ちの仕組みを入れる、夜間にまとめて処理する、といった対応が必要になります。外部API連携の設計と運用で扱う考え方が、そのまま当てはまります。

利用料も負荷とともに増えます。PoCの期間と費用の考え方で試算した月額に加え、想定より利用が増えたときの上限と、その監視の方法を決めておきます。

壁2：権限 — 誰が何を見てよいか

PoCは、限られた担当者が自分の手元でデータを扱います。本番では、複数の人が、それぞれ違う立場で同じ仕組みを使います。

• 誰がAIの出力を見てよいか
• 元になるデータのうち、見せてよい範囲はどこまでか
• 誰が結果を修正・承認できるか
• 誰がその履歴を確認できるか

顧客情報や取引情報を扱う処理では、この設計が本番化の必須条件になります。PoCでは不要だった認証、権限の区分、操作の記録が、まとめて必要になります。外部のAIサービスに渡すデータの範囲も、担当者の裁量ではなく仕組みとして制限する形に変わります。スタートアップのセキュリティと個人情報保護で扱う基準を、PoCの段階から念頭に置いておくと、この段階での作り直しが減ります。

壁3：例外データ — PoCで崩れたものが本番では毎日来る

PoCで「この種類の入力では結果が崩れる」と分かった場合、本番ではそれが毎日届きます。数は少なくても、必ず来ます。

本番設計では、次を決める必要があります。

このうち最も重要なのは3つ目です。誤りに誰も気づけない設計は、精度の数値が良くても本番に出せません。逆に、誤っても次の工程で必ず人の目が入るなら、多少精度が低くても運用できます。AIの精度をどう評価するかで、誤りに気づけるかどうかを確認項目に入れておくのは、このためです。

想定例：ある企業が、請求内容の確認作業にAIを導入したとします。PoCでは、通常の請求は問題なく処理でき、複数の契約が混在する請求だけが崩れると分かりました。本番設計では、契約数が複数の請求を処理の前に振り分けて人が担当し、それ以外を自動処理する形にします。さらに、自動処理した結果は月次の集計時に金額の合計が合うかを確認する工程を残し、見逃しがあれば必ずそこで気づく設計にしました。精度そのものを上げるより、気づける仕組みを作るほうが、この場合は確実で安く済んでいます。

壁4：運用体制 — 導入後に誰が面倒を見るか

最も見落とされ、そして最も本番化を止めるのがこれです。AIを組み込んだ仕組みは、作って終わりになりません。

• 出力の質を定期的に確認するのは誰か
• 誤りの報告を受けて、指示文を調整するのは誰か
• 利用料の推移を見て、上限を管理するのは誰か
• 外部のAIサービスが更新されたとき、動作を確認するのは誰か

4つ目が、従来のシステム開発にはなかった論点です。既製のAI APIは事業者側の都合で更新され、以前と同じ入力に対して出力が変わることがあります。本番運用では、更新があったときに主要な事例で結果を確認する手順を、あらかじめ決めておく必要があります。PoCで作った評価用データが、ここでそのまま役に立ちます。

運用の担当者を決められない場合、選択肢は二つです。本番化を見送るか、人の確認が不要な範囲まで用途を狭めるか。「とりあえず入れてから考える」は、この4つ目に関しては避けたほうが安全です。

壁を見込んだPoCの設計

4つの壁は、PoCで乗り越えるものではありません。PoCで乗り越えようとすると、範囲が膨らみ、PoCの範囲を最小にする切り方で述べた最小化と矛盾します。

PoCの段階でやるのは、作ることではなく、確認しておくことです。次の4点だけ、検証と並行して答えを持っておいてください。

1. 件数：本番で月に何件処理するか、偏りはあるか（業務側に聞けば分かります）
2. 権限：このデータを見てよい人の範囲はどこまでか（社内ルールを確認します）
3. 例外：PoCで崩れた入力の種類を記録し、本番での発生頻度を見積もります
4. 担当：運用を誰が、週に何時間で担うかの見込みを立てます

この4点が揃っていれば、PoCの結果が出た時点で本番化の見積もりが立ちます。逆に揃っていないと、「良い結果が出たので本番の検討を始めます」という、また別の数か月が始まります。

弊社がAI活用開発やWebシステム開発でPoCから本番化までをご一緒する場合も、この4点はPoCの初回打ち合わせで確認させていただいています。技術の検証と並行して埋めておくほうが、後から聞くより早く、正確だからです。

削った周辺が、本番の仕事になる

PoCが削るのは、負荷への備え、権限の管理、例外データの扱い、そして運用の体制です。これらは本番では削れず、多くの場合こちらのほうが手間がかかります。PoCの段階で4点を確認しておけば、結果が出た瞬間に次の見積もりが立ち、判断が止まりません。

本番化の設計をどこから始めるべきか、あるいはこの壁を越えられる体制かどうかを整理したい場合は、お問い合わせからご相談ください。オンラインで業務と体制の状況を伺い、現実的な進め方を一緒に考えます。

本記事は一般的な情報であり、個別の事案は専門家・所管官庁にご確認ください。