生成AIの相談で最も多いのは「これから始めたい」ではなく、**「PoCは終わったが、そこから進まない」**です。
精度は悪くない。経営層へのデモも成功した。それでも本番に載らない。多くの場合、原因はモデルではありません。ここでは典型的な5つのパターンと、それぞれの潰し方を書きます。
理由1：「正しい」の定義がない
最も多い原因です。
PoCの評価が「なんとなく良さそう」で終わっている。プロンプトを変えるたびに担当者が数件を目視して「前より良くなった気がする」と言う。これでは、改善しているのか劣化しているのかが誰にも分かりません。
そして本番化の場面で必ずこう聞かれます。「精度は何％ですか」。答えられないので、話が止まります。
潰し方：モデルを触る前に評価パイプラインを作る
AIシステム開発で最初に作るべきはモデルでもUIでもなく、評価の仕組みです。当社では例外なくここから着手します。
重要なのは、単一の正解率では足りないという点です。業務では誤りの種類ごとに許容度が違うからです。
たとえば請求書からの金額抽出であれば、
- 金額を読み違える → 致命的。ゼロにしたい
- 読めないと判断して人間に回す → 許容できる。むしろ望ましい
- 余計な項目まで拾う → 軽微
この3つを区別せずに「正解率92%」と言っても、業務側は判断できません。誤りを分類し、それぞれの許容ラインを業務側と握る。これが評価設計の中身です。
理由2：確信度の低い出力を人間に回す設計がない
100%正しいAIは存在しません。にもかかわらず、多くのPoCは「全件をAIが処理する」前提で作られています。
これでは本番に載りません。業務側は「間違えたらどうするのか」に答えられない仕組みを受け入れられないからです。
潰し方：最初から人間との分担を設計に入れる
確信度の低い出力を自動的に人間の確認に回す設計を、最初から組み込みます。
このとき効くのが、しきい値を運用中に調整できるようにしておくことです。導入初期は保守的に（多めに人間へ回す）、精度への信頼が蓄積したら自動化率を上げていく。この調整ダイヤルがあるだけで、業務側の心理的な抵抗が大きく下がります。
「全自動か、導入しないか」の二択にしないこと。これが本番化の分かれ目になることは非常に多いです。
理由3：情報システム部門の審査項目に答えられない
デモは通ったのに、情シスや法務のレビューで止まる。ここで問われるのは、たいてい次の項目です。
- 誰がいつ何を入力し、何が出力されたかのログが残るか
- 権限管理はどうなっているか（部署ごとに見せるデータを分けられるか）
- 入力データがモデルの学習に使われないことをどう担保しているか
- API障害時に業務は止まらないか
- 誤出力が業務に損害を与えた場合の責任分界はどうなっているか
PoCではこれらが全て未実装です。そして、これらは後から足すと作り直しになる種類の要件です。
潰し方：PoCの段階で審査項目を先に取りに行く
技術検証と並行して、情シスの審査項目リストを先にもらってしまう。多くの企業では既存の外部サービス審査の様式があります。それを見れば、何を実装すべきかは明確になります。
「PoCが終わってから考える」ではなく、PoCの成果物に「審査項目への回答」を含める。当社ではこれを標準にしています。
理由4：ランニングコストが試算できず、予算が取れない
従量課金のAPIは、本格運用時の月額が読めません。読めないものには予算が付きません。
潰し方：実測値を取り、上限制御を実装する
PoCの段階で、1件あたりの入出力トークン数を実測します。そこに想定処理件数を掛ければ、月額のレンジは出ます。
さらに重要なのが、上限を超えたら自動で停止または縮退する制御を実装しておくことです。「予算超過が構造的に起きない」ことを示せると、稟議の通り方が変わります。金額の大小より、上限が保証されているかどうかが効きます。
あわせて、全ての処理に最高性能のモデルを使う必要はありません。前処理や分類に軽量モデルを使い、難しい判断だけ高性能モデルに回す。これだけで費用が数分の一になることは珍しくありません。
理由5：既存システムに繋がっていない
PoCがスタンドアロンのWebアプリとして作られており、実際の業務データがどこから来て、結果がどこへ行くのかが設計されていない。
これは技術的には地味ですが、実務では最も工数を食う部分です。基幹システムのAPIがない、CSVの受け渡しが手作業、認証基盤との連携が必要——このあたりが本番化工数の大半を占めます。
潰し方：PoCの入出力を実データの経路に合わせる
PoCの段階から、実際のデータ経路の端と端を繋いでおく。処理の中身が粗くても構いません。薄くても一気通貫で動くものを先に作れば、接続部分の難所が早期に発覚します。
当社ではこの進め方を「曳光弾開発」と呼び、標準にしています。半年の要件定義のあとで接続不能が判明する、という事故が起きなくなります。
順番が大事
5つ挙げましたが、着手順序は固定です。
- 評価パイプライン（理由1）
- 実データ経路との接続（理由5）
- 人間との分担設計（理由2）
- コスト実測と上限制御（理由4）
- 審査項目への対応（理由3）
評価がないまま2以降をやると、改善しているかどうかが分からないまま工数だけが増えます。逆に評価さえあれば、残りは順当に潰せます。
止まっているPoCがあれば、現状を拝見したうえで「何が足りないか」を整理するところからお手伝いできます。作り直したほうが早いと判断した場合も、その理由を根拠とともにお伝えします。