AIのPoCは動いたのに、本番導入できない理由：後から見つかる非AI要件
木村 優志
社内文書への質問に回答できた。サンプル画像から不良を検出できた。会議音声を文字に起こせた。PoCでAIの中核機能が動けば、技術的な不確実性を一つ減らせます。
しかし、そのまま利用者を増やして本番運用できるとは限りません。
PoCでは、開発者が選んだデータを使い、管理者権限で、一人ずつ試すことができます。本番では、評価時になかった入力も届きます。さらに、利用者ごとの権限を守り、更新されるデータを取り込み、同時アクセスを処理し、失敗した処理を復旧しなければなりません。
この差を作るのは、モデルの精度だけではありません。入力条件の変化、認証、データ連携、性能、監視、障害対応、費用、運用体制まで含めて考える必要があります。
本記事では、PoCから本番導入へ進むときに後から見つかる要件を、検証用の構成と本番の構成の違いから整理します。中心になるのはAIの外側にある要件ですが、非AI要件とAI品質を切り離せない例として、ドメインシフトも扱います。
PoCが証明したことを、広げて解釈しない
PoCで確認できるのは、あらかじめ決めた条件における実現可能性です。
たとえば、次の構成で社内文書を検索するRAGを試したとします。
開発者が選んだPDFを手動で登録
→ 一つのアカウントで検索
→ LLMが回答と出典を表示
→ 担当者が回答を確認このPoCで回答品質を確認できても、次のことまで証明したわけではありません。
- 利用者が閲覧できない文書を回答へ含めない
- 文書の追加・改定・削除を検索結果へ反映する
- 評価用データと条件が違う入力でも、必要な品質を保つ
- 複数人が同時に使っても、許容時間内に回答する
- 外部APIが停止したとき、処理を安全に中断・再開する
- 問題のある回答が、どのデータと処理から作られたか追跡する
- 利用量が増えても、予算内で運用する
PoCの成功を否定する必要はありません。ただし、何を検証し、何をまだ検証していないかを分けないと、本番化の追加作業を「少し整えるだけ」と見誤ります。
1. 共通アカウントから、利用者ごとの認証と権限へ
PoCでは、開発用のAPIキーや管理者アカウントでデータへ接続することがあります。本番で同じ認証情報を共有すると、誰が操作したか分からず、本来見られないデータまでAI経由で取得できる可能性があります。
本番では、少なくとも次を決めます。
- 利用者をどの仕組みで認証するか
- 部署、役職、案件ごとの閲覧範囲をどう引き継ぐか
- AIが使うサービスアカウントに、どこまで権限を与えるか
- 管理者、一般利用者、運用担当者が行える操作をどう分けるか
- 退職・異動時にアクセスをどう停止するか
RAGであれば、検索インデックスへ文書を入れた時点で、元システムのアクセス権を失わない設計が必要です。CRM連携であれば、全顧客を読める管理者トークンではなく、利用者または業務上必要な範囲へ絞った権限で取得します。
認証画面を追加するだけでは解決しません。検索、生成、外部操作の各段階で、利用者が許可された対象だけを扱っているかを確認する必要があります。
権限と自動実行の境界については、AIエージェントを業務システムにつなぐ前に決める、権限と自動実行の境界で詳しく整理しています。
2. 手動投入したデータから、更新され続けるデータへ
PoCでは、評価しやすい文書や画像をフォルダへまとめ、開発者が一度だけ登録できます。本番データは追加され、修正され、削除されます。
社内文書を使う場合は、次の処理が必要です。
- 新規文書を検知して取り込む
- 改定版が出たら、旧版と区別して更新する
- 削除・公開停止された文書を検索対象から外す
- 取り込みに失敗した文書を検知し、再処理する
- 対応していない形式や壊れたファイルを隔離する
- 文書の所有者、版、公開範囲、更新日時を保持する
画像認識でも同じです。PoC用の画像をアップロードして判定するだけなら単純ですが、本番ではカメラとの接続、撮影タイミング、画像欠損、保存期間、再送、機器ごとの設定が必要になります。
データ連携は、AIの前処理というより、独立した運用システムです。「毎晩同期する」「更新から15分以内に反映する」など、業務が許容できる鮮度を要件にします。
3. 評価用に切り取ったデータから、変化する実環境へ
データを正しく同期できても、PoCと本番で入力の傾向が変われば、同じモデルが同じ品質を出すとは限りません。評価時と運用時で入力データの分布や条件が変わることを、ここではドメインシフトと呼びます。
画像認識では、PoC用の撮影環境を固定できても、本番では次のような変化が起こります。
- 照明の明るさ、色、外光の入り方
- カメラ、レンズ、焦点、設置角度
- 製造ライン、材料、製品ロット
- 汚れ、振動、背景への映り込み
- PoCでは集められなかった不良の種類
音声AIでは、静かな会議室から工場や店舗へ移るだけで、騒音、反響、マイクとの距離、話者の発音、専門用語が変わります。RAGでも、本番利用者の質問は評価セットより短く曖昧だったり、複数の文書をまたぐ回答を求めたりします。
重要なのは、PoCの評価データを無作為に増やすことではありません。本番で変わり得る条件を列挙し、その条件をまたいで評価データを分けることです。
たとえば画像をランダムに学習用と評価用へ分けると、同じ日に同じ製品を連続撮影した似た画像が両方へ入ることがあります。この結果だけでは、別の日、別ロット、別ラインでも使えるか判断できません。撮影日、製品個体、ロット、設備など、本番で変化する単位をまたいで評価します。
PoCから本番へ進む前に、次を確認します。
- PoCのデータが、どの期間・設備・利用者・条件から集められたか
- 本番にあってPoCにない条件は何か
- 条件別に品質を測れるメタデータが残っているか
- 判定不能や人への引き継ぎを記録できるか
- 品質低下を検知したとき、停止・切り戻し・再評価のどれを行うか
ドメインシフト自体はAI品質の問題です。しかし、それを見つけるためのデータ収集、条件別の監視、人による確認、再評価の手順は、本番システムと運用の要件です。モデルを一度評価して終わりにせず、どの変化を観測するかまで設計します。
4. 一人で試す処理から、同時利用と待ち時間の管理へ
PoCのデモでは、一回の処理が成功するかを確認します。本番では、同じ時間帯に複数人が利用し、長い文書や音声、画像が同時に送られます。
確認すべきなのは、モデル単体の推論時間だけではありません。
ファイルのアップロード
→ 形式変換・前処理
→ 検索または推論
→ 外部APIの待ち時間
→ 後処理・保存
→ 画面への表示この全体で、利用者が待つ時間が決まります。
本番化の前に、次を数値で置きます。
- 通常時と繁忙時の同時利用者数
- 一件あたりの最大データ量
- 許容する応答時間
- 時間内に処理できなかった場合の扱い
- 外部APIのレート制限を超えた場合の待機・再試行
- バッチ処理を完了させる期限
長い処理は、画面を開いたまま待たせず、ジョブとして受け付ける方法があります。その場合は、進行状況、キャンセル、重複実行の防止、完了通知まで必要です。
平均応答時間だけでなく、遅い側の処理も測ります。一部の大きなファイルだけ数分かかるのであれば、平均値では利用上の問題を見落とします。
5. 成功するデモから、失敗しても壊れない処理へ
外部のLLM API、ストレージ、CRM、カメラ、ネットワークのいずれかは、応答しないことがあります。入力形式が想定外で、処理の途中だけ成功することもあります。
たとえば、AIが回答を作った後にCRMへの保存だけ失敗した場合、単純に最初から再実行すると、回答やレコードを二重登録する可能性があります。
本番では、失敗時の動きを設計します。
- 一時的なエラーだけを、間隔を空けて再試行する
- 同じ処理を再実行しても、二重登録しない
- 途中まで成功した状態を記録する
- 再処理できない入力を隔離し、運用担当者へ知らせる
- 外部サービス停止時に、代替手順または従来業務へ戻す
- AIが判定できない場合と、システム障害を区別する
「エラーを表示する」だけでは、誰が何をすれば復旧するのか分かりません。利用者がやり直せるのか、運用担当者が再処理するのか、開発会社の対応が必要なのかまで決めます。
6. 画面上の結果から、原因を追える記録へ
AIの出力に問題があったとき、本番運用では原因を切り分ける必要があります。
- 入力データが不足していた
- 検索が誤った文書を取得した
- 古い版の文書を参照した
- プロンプトやモデルの変更で挙動が変わった
- 外部ツールへ誤った引数を渡した
- 出力は正しかったが、その後の保存に失敗した
最終的な回答だけを保存しても、この違いは分かりません。追跡に必要な範囲で、次の情報を記録します。
- 誰が、いつ、どの機能を利用したか
- 入力と出力を識別するID
- 参照した文書、画像、レコードとその版
- 使用したモデル、プロンプト、検索設定のバージョン
- 外部ツールの呼び出しと結果
- 処理時間、再試行、エラー
- 人が修正・承認した内容
ただし、ログを増やせばよいわけではありません。入力に個人情報や機密情報がある場合、ログへの本文保存が新たな漏洩経路になります。本文を保存するか、識別子や統計だけにするか、閲覧権限と保存期間を含めて決めます。
監視では「サーバーが動いているか」だけでなく、取り込み失敗の増加、検索結果が空になる割合、判定不能率、人による修正率、条件別の精度、外部APIのエラー、処理時間、利用量の急増など、業務品質につながる変化を検知します。
正解がすぐに分からない業務では、本番中の精度をリアルタイムに計算できないこともあります。その場合は、入力条件の変化や判定不能率を先行指標として監視し、後から確定した正解を定期評価へ戻します。
7. 試作費用から、利用量に応じた運用費用へ
PoCの費用は、限られた回数のAPI呼び出しと開発環境だけで済む場合があります。本番では、利用者数、入力サイズ、保存量、監視、バックアップ、ネットワークによって費用が変わります。
生成AIでは、入力と出力のトークンだけでなく、次の費用も確認します。
- 文書の解析、OCR、埋め込み生成
- 検索インデックスとデータ保存
- 音声認識、音声合成、通話
- 画像・動画の転送と保管
- 再試行、評価、監視のための処理
- 開発・検証・本番環境の維持
- 運用担当者による確認と問い合わせ対応
一回あたりの費用を出すときは、短い成功例だけで計算せず、本番で想定する長い入力、再試行、検索、外部連携まで含めます。
また、月額上限に達したらどうするかも要件です。処理を停止する、低価格な経路へ切り替える、管理者の承認を求めるなど、予算超過を検知した後の動作を決めます。
8. 開発者が面倒を見る状態から、運用できる体制へ
PoCでは、問題があれば開発者がデータベースやログを直接確認できます。本番では、それを日常の運用方法にはできません。
稼働前に、少なくとも次の役割を置きます。
- 利用者からの問い合わせを受ける人
- アカウントと権限を管理する人
- 文書や判定基準を更新する人
- AIの誤りを確認し、評価セットへ追加する人
- 障害を一次判断し、必要なら開発会社へ連絡する人
- モデルや外部APIの変更を承認する人
運用画面も必要になることがあります。利用者一覧、取り込み状況、失敗したジョブ、利用量、フィードバックを、コードやクラウド管理画面を触らずに確認できるようにします。
本番導入の判断には、正常時の操作マニュアルだけでなく、停止、再開、データ更新、権限変更、障害連絡の手順も含めます。
非AI要件は、PoC後ではなくPoCの範囲を決めるときに確認する
すべての本番機能をPoCで作る必要はありません。認証、監視、冗長化を最初から完成させると、実現可能性を確かめる前に費用が膨らみます。
ただし、後で必要になる要件を知らずに省くことと、把握したうえで検証対象から外すことは違います。
PoCを始める前に、次の三つへ分けます。
今回、実装して検証する
例：条件別の回答・判定品質、検索品質、実環境での推論時間
簡易構成で前提だけ確認する
例：認証方式、データ連携先、本番で変わる入力条件、想定同時利用者数
本番化の工程で実装する
例：運用画面、監視、バックアップ、障害復旧この区分と、本番化に必要な追加工程をPoCの計画に残します。そうすれば、PoC終了時に「精度は確認できたが、本番費用と期間が分からない」という状態を避けやすくなります。
PoC終了時に確認する本番化チェック
PoCの結果を評価するときは、精度と業務価値に加えて、次を確認します。
認証・権限
- 本番の利用者と閲覧範囲を定義したか
- 開発用の共通キーや管理者権限を、本番用に置き換えられるか
データ
- 追加、更新、削除を取り込む方法があるか
- データの管理者と更新頻度が決まっているか
実環境との差
- 本番で変わる撮影条件、音響条件、利用者、質問傾向を洗い出したか
- 条件別の品質低下を検知し、再評価できるか
性能・費用
- 想定する同時利用とデータ量で応答時間を試したか
- 一回・一日・一か月あたりの費用を見積もれるか
障害対応・監視
- 外部サービスやネットワークの失敗時に、安全に停止・再試行できるか
- 問題のある処理を追跡するための記録があるか
運用
- 問い合わせ、権限変更、データ更新、障害対応の担当者がいるか
- モデルやデータの変更後に、同じ評価を再実行できるか
一つでも未定なら本番化できない、というチェックリストではありません。未定の項目を、誰がいつ判断し、追加で何を実装するかを見えるようにするための一覧です。
まとめ
AIのPoCで中核機能が動いても、本番導入には次の差が残ります。
- 共通アカウントから、利用者ごとの認証と権限へ
- 手動投入したデータから、更新され続けるデータへ
- 評価用に切り取ったデータから、変化する実環境へ
- 一人で試す処理から、同時利用と待ち時間の管理へ
- 成功するデモから、失敗しても壊れない処理へ
- 画面上の結果から、原因を追える記録へ
- 試作費用から、利用量に応じた運用費用へ
- 開発者が面倒を見る状態から、運用できる体制へ
ドメインシフトを除けば、これらの多くはAIモデルの外側にあります。しかし、どれもAIを業務システムとして使い続けるための要件です。
PoCでは、すべてを実装する必要はありません。何をPoCで検証し、どの本番条件をまだ試しておらず、何を本番化の工程へ残したかを明示します。精度の評価と同時に、実環境との差、認証、データ更新、性能、障害、費用、運用の見通しを持つことで、「動く試作品」と「運用できるシステム」の距離を判断できます。
関連記事
- 生成AIの評価セットをどう作るか：業務で使えるLLM評価の設計
- AIエージェントを業務システムにつなぐ前に決める、権限と自動実行の境界
- RAGが答えられないとき、最初に疑うべきはLLMではなく検索です
