PoCは動いた。でも、そこから数ヶ月経っても本番に進んでいない。 ——生成AIに取り組んだ企業の多くが、ちょうどこの地点で止まる。技術的に不可能だったからではない。むしろ「動くことは確認できた」からこそ、次に何を決めればいいのかが曖昧になり、止まる。
この記事は、すでにPoCを終えている読者に向けて書く。PoCとは何かの説明はしない。書くのは、止まったPoCを本番へ動かすために、何が具体的に足りないのかである。
「ガバナンスが大事」だけでは、PoCは動かない
生成AIの本番化を扱う記事の多くは、最終的に「ガバナンス体制を整えましょう」で終わる。間違ってはいない。だが、すでにPoCを終えた読者にとって、この結論は情報量が少なすぎる。ガバナンスが大事なのは分かっている。知りたいのは、PoCの設計のどこに何が足りなかったから、本番化の判断ができない状態のまま止まっているのか、という具体である。
AIへの投資からの価値創出には、企業間で大きな差がある——BCGとMcKinseyの2025年調査を一次から確認した内容を、以前の記事「AIに投資した企業の60%が、金額として何も得ていない」にまとめた。あの記事は「なぜ差がつくのか」を調査データから読み解く記事だった。この記事はその続きとして、「止まっているPoCを、具体的にどう動かすか」を、PoCの設計そのものに落とし込んで書く。
ここから先の内容は、BCG・McKinseyの調査結果ではなく、LLLが私有LLMのPoC設計・本番導入支援で実際に見ている運用上のパターンである。特定の調査の結論として提示しているものではない、という前提で読んでほしい。
PoCが「決められる形」で終わっていないと、次に進めない
PoCが止まる典型的な理由は、技術が足りなかったことではない。PoCが「動いた」という事実は残したが、「本番へ進むべきか」を判断できる材料を残していないことが多い。
デモが成功した、精度も悪くなさそうだった——ここまでは多くのPoCが到達する。だが、次のような問いに、PoCの成果物だけで答えられるだろうか。
- どの水準の精度が出れば「本番に進んでよい」と言えるのか、その基準はテストを始める前に文書化されていたか
- 精度を測ったのは、ベンダーのデモ用データか、それとも自社の実際の文書・実際の質問パターンか
- 本番で使う想定の構成（提供形態・モデルサイズ・データの行き先）と、PoCで検証した構成は同じか
- 本番化した場合の費用感は、PoCの結果から具体的に見積もられているか
この4つに答えられないままPoCが「完了」扱いになっていると、本番化の議論は振り出しに戻る。関係者が集まって「動いたことは分かったが、進めていいのか」を毎回一から議論することになり、それが「止まっている」の正体であることが多い。
本番に進めるPoCの設計に、最初から入っているべき3つのもの
止まらないPoCと止まるPoCの違いは、実施後の分析ではなく設計段階にある。LLLが私有LLMのPoCを設計する際に成果物として固定している3つの要素を、そのまま挙げる。
1. 評価セットは、ベンチマークではなく自社の文書・自社の質問で作る
生成AIのデモは、汎用ベンチマークやベンダー用意のサンプルデータでは高い精度を示しやすい。だが、それは本番で扱う実際の業務文書・実際の質問パターンでの精度を保証しない。PoCの評価セットを自社の実データから構築していなければ、PoCで出た「精度」の数字は、本番化の判断材料としては使いにくい。
2. 「feasible / conditionally feasible / not feasible」の判定基準を、テスト開始前に文書化する
精度が何%出れば「進めてよい」のか、レイテンシがどこまでなら許容できるのか——この基準をテストの結果を見た後に決めると、数字の解釈がその場の空気で決まってしまう。基準はテストを始める前に、書面で合意しておく必要がある。
これを設計に組み込むと、PoCの結果は「feasible（進めてよい）」「conditionally feasible（条件付きで進められる）」「not feasible（この構成では見送るべき）」のいずれかとして出てくる。「not feasible」という結論も、PoCが正しく機能した結果である。それを避けたくて基準を曖昧にしたまま進めると、後で止まる。
3. 提供形態・モデルサイズ・費用見積もりを、PoCの成果物に含める
「動くことは確認できた」で終わるPoCは、本番化の検討を実質ゼロから始めさせる。セルフホスト・マネージド・共有インフラのどれが自社の利用規模に合うのか、モデルはどのクラスが必要なのか、フルビルドにいくらかかるのか——これらがPoCの成果物に含まれていなければ、PoC後にもう一段、調査フェーズが必要になる。
PoCの設計段階で「テスト結果から、この3つを書面で出す」と決めておけば、本番化は新しい調査ではなく、PoCで出した推奨をそのまま実行する作業になる。LLLの30日間私有LLM PoCは、この3つを含む書面の推奨レポートを成果物として設計している。
データの行き先は、PoCの評価環境の時点で本番と同じ形にしておく
本番直前に「このデータを外部APIに送っていいのか」という法務・情報セキュリティ上の疑問が噴出し、そこで止まる——これがもう一つの典型的な詰まり方である。原因の多くは、PoCの段階でデータの行き先を曖昧にしたまま、技術的に動くものを先に作ってしまうことにある。
生成AIの活用は、プロンプトに載せたデータがどこへ送られるかが異なる3つの構成のどれかを選ぶ作業になる。
- 私有LLM——自社が管理する、またはベンダーが代理で運用するインフラの中で推論が完結する
- フロンティアAPI——OpenAI・Anthropic・Googleといったプロバイダーのサーバーへプロンプトが実際に送られる
- ハイブリッド——機微な情報は私有LLM側へ、それ以外はフロンティアモデルへ振り分ける
3構成の詳しい決め方は私有LLMかAPIか——選択肢は3つ、決め方には順序があるにまとめている。
重要なのは、この決定を本番直前ではなくPoCが始まる前に済ませ、PoCの評価環境そのものを、本番で使う予定の構成と同じ形にしておくことだ。PoCを都合の良い構成（例えば機微データを避けたサンプルセット）で走らせてしまうと、本番化の段階で「本番のデータで、もう一度正しい構成でやり直す」という追加の工程が発生する。これがPoCと本番の間の段差の正体になっていることが多い。3構成の書き分けはAI開発サービスのデータプライバシーの項目でも扱っている。
モデルサイズは、「精度が足りるか」と「さばく量が足りるか」を別の軸として検証する
モデルサイズの検討でよくある詰まり方は、精度の問題と処理能力の問題を混同することだ。この2つは別の軸にある。
- 精度の下限は、モデルのクラスと量子化の下限で決まる。実務水準を満たす下限として32Bクラス、社内向けChatGPT相当の既定値として70Bクラスというように、クラスが上がるほど精度の余地は増える。量子化についても同様で、FP8を下回ると（例えば4bit量子化まで下げると）日本語業務タスクの精度が測定可能なレベルで落ちる、というのが実測に基づく知見である。
- さばく量の上限は、同時利用者数やリクエスト頻度によって決まる。同時利用が多い組織向けの122B-A10B、トリアージ・ガードレール専用の35B-A3Bというように、こちらはモデルの構造（MoEのアクティブパラメータ数など）が効いてくる。
PoCの段階で、精度をコストの安い小さいモデルで確かめ、処理能力は別の大きいモデルを想定して見積もる、というように検証したモデルと本番で使う予定のモデルがずれていると、本番化の直前になって「精度を確かめたモデルでは同時利用をさばけない」「さばける規模のモデルでは精度が足りない」という話が出てきて、また止まる。PoCでは、精度とレイテンシ・スループットの両方を、本番で使う予定と同じモデル構成で検証しておく必要がある。モデル規模の選定についてはプライベートLLM基盤に詳しい。
まとめ：やり直すのではなく、足りない設計を足す
PoCが止まっているとき、必要なのは「もう一度PoCをやる」ことでも、「ガバナンス体制の議論を始める」ことでもないことが多い。足りないのは、次の4つを、PoCの成果物として明文化することである。
- 自社の文書・自社の質問で作った評価セットでの精度・レイテンシの実測値
- テスト開始前に文書化した「feasible / conditionally feasible / not feasible」の判定基準
- 提供形態・モデルサイズ・費用見積もりを含む本番化の推奨
- 本番で使う予定と同じデータの行き先・同じモデル構成での検証
ガバナンスや人的レビューの体制は、この後も必要になる。高リスクな出力に人の確認を挟む設計や、生成コンテンツへのガードレールは、本番運用に入ってからも継続して求められる。だが、それはPoCの代わりにはならない。決定できる材料を持ったPoCの上に載る仕組みであって、決定できる材料がないままガバナンスの議論だけを重ねても、本番化の判断は前に進みにくい。
PoCを、本番に進める判断材料に変える
自社データで成立するかを確かめる30日PoC、私有LLM基盤の構築、AI開発について、LLLが提供している内容を以下にまとめている。
30日間の私有LLM PoCについて見る プライベートLLM基盤について見る AI開発サービスについて見る