PoC で
終わらせない。

「PoC は成功したのですが、本番化はまだです」— この「PoC で止まる」状態は、一部の企業に限った話ではありません。MIT の調査では、企業の生成 AI 導入の約95%がパイロット段階にとどまり、本番運用での成果に結びついていないと報告されています[1]。つまずく原因の多くは、技術よりも進め方にあります。

1. PoC から本番に進めない実態

PoC は、技術的に実現できるかを確かめる短期のプロジェクトです。ところが、PoC が成功しても本番運用に届かないケースは少なくありません。主な調査の結果は次のとおりです。

本番に進めない主な原因は、PoC を設計する段階で本番の要件を織り込んでいないことにあります。検証用の簡易な環境・データ・処理で作られた PoC は、本番で求められる要件（大量データ、サービス品質の保証、運用、監視、セキュリティ）を満たせず、作り直しになります。

2. PoC が止まる5つの構造的要因

現場で繰り返し見られる、PoC を本番の手前で止めてしまう構造的な要因を5つに整理します。

2.1 曖昧な KPI 定義

「業務効率化」「生産性向上」のような抽象的な目標しか設定されていないと、PoC の結果を見ても成功か失敗かが分かりません。さらに、本番化するかどうかの基準も決まっていないため、経営層は Go/NoGo（本番化するか撤退するか）を判断できません。

2.2 本番環境とのギャップ

PoC は少量の整ったデータで成功しますが、本番では大量の実データを扱い、既存システムとの連携やセキュリティ・コンプライアンス要件も満たさなければなりません。PoC の段階で見えなかったこの3点の差が、本番化の壁になります。

2.3 運用設計の未整備

AI モデルの開発に力を注ぐあまり、本番稼働後の運用・保守（新しいデータでの再学習、監視、エラー対応）の設計が後回しになります。その結果、AI の精度が徐々に落ち、いつの間にか使われなくなります。

2.4 本番化の責任者が決まっていない

「IT 部門が作って業務部門に渡す」進め方では、業務部門が運用の責任を持たないため、結局使われなくなります。逆に「業務部門が PoC を主導した」場合、IT 部門が引き継ぎを拒否することもあります。本番化の責任を誰が持つかを、PoC の設計段階で決めていないことが原因です。

2.5 評価軸の不在

AI の精度は、試験用のデータで測った正解率のような1つの数字だけで評価されがちです。その数字が業務時間や売上といった事業 KPI にどう効いているかを測らなければ、「精度は出たが、業務上の価値が見えない」状態のまま、本番化するかどうかを決められません。

3. 本番運用に届ける7つの設計原則

Kmetric が現場で使っている7つの原則です。番号は便宜上のもので、7つすべてを PoC の設計段階で同時に組み込みます。

1. 原則1：本番化の Go/NoGo 基準を先に定義する — PoC を始める前に、「この数値を超えたら本番化、超えなければ撤退」という基準を経営層と合意します。基準は事業 KPI で表します（例：業務時間を30%削減、コンバージョンを2倍）。
2. 原則2：PoC を本番システムの1/10規模で作る — 本番と同じ量のデータ、すべてのシステム連携、セキュリティ要件を最初からそろえる必要はありません。ただ、規模を1/10に縮めてでも、この3つを一通り備えた PoC にしておけば、本番化のタイミングで「全部やり直し」を避けられます。
3. 原則3：出力品質の自動評価を初日から作る — AI の回答の良し悪しを自動で採点する仕組みを、PoC 初日から用意します。PoC の成否を数字で判断でき、本番化した後も同じ仕組みで品質の低下に気づけます。
4. 原則4：人間の確認を挟む設計を最初から織り込む — 「人間の判断をどこに挟むか」を PoC の段階で決めます。すべてを自動化するのは危険です。判断に迷うケースを人間に回す経路を用意しておけば、本番化したときの信頼性が高まります。
5. 原則5：動作の見える化を組み込む — 動作の記録（ログ）、主要な指標、処理の流れを、PoC の段階から残しておきます。本番化した後に「何が起きているか分からない」状態を避けるためです。
6. 原則6：本番化の責任者を1人に決める — PoC を始める時点で、本番化するかどうかを最終的に判断する人を1人決めます。IT 部門と業務部門の責任分担も文書にしておきます。
7. 原則7：撤退条件も明示する — PoC が成功したときの本番化の道筋だけでなく、失敗したときに撤退する条件と手順も設計します。撤退するときに何を記録に残すかまで決めておけば、失敗も次の PoC に生かせます。

4. 出力品質の自動評価が、本番化の成否を分ける

生成 AI を使う場合は特に、出力品質を自動で評価する仕組み（原則3）をどう設計するかが、本番化できるかどうかを大きく左右します。

自動評価の構成

• テストケース集：代表的な入力と、それに対して期待する回答の組み合わせを100〜1,000件
• 自動評価指標：期待する回答との一致度、意味の近さ、別の AI による採点
• 人間評価セッション：自動評価では測り切れない品質を、人が判断する
• 失敗ケースの記録：改善の前後で結果を比べるために使う

自動評価の運用ルール

• AI モデルや AI への指示（プロンプト）を変えるたびに、自動で実行する
• 品質の低下を検出したら、リリースを止める
• 本番の動作記録から、新しいテストケースを追加し続ける

5. 人間と AI、判断の境界をどこに置くか

AI が自律的に動作する範囲と、人間に判断を委ねる範囲を、明確に切り分けます。

人へ引き継ぐべき典型パターン

• AI 自身の確信度が基準を下回った判断
• 金額・件数が一定を超える操作
• 過去に似たケースで AI が判断を誤った種類の案件
• これまでにないパターンを検出したとき

運用組織の在り方

AI から引き継いだ案件を誰がどう処理するかを、PoC の段階で決めておきます。「業務担当者が確認する」と決めるだけでは足りません。確認の品質基準と対応期限を定め、担当者の判断記録を AI の改善に生かす仕組みまで設計します。

6. PoC 設計チェックリスト（12の質問）

PoC を始める前に、次の12の質問に答えられるかを確認します。

1. 本番化の Go/NoGo 基準（事業 KPI）は何か？
2. PoC の期間は何週間か、延長する条件は何か？
3. PoC が成功したとき、本番化の責任者は誰か？
4. 本番データの1/10規模の縮小版を用意できるか？
5. 本番システムとの連携を、少なくとも1つ PoC で再現できるか？
6. セキュリティ要件は把握できているか？
7. 出力品質の自動評価を誰が設計するか？
8. どんな条件のときに人間の確認を挟むか？
9. 失敗したときの撤退条件は何か？
10. 本番化までのコスト見積もりはあるか？
11. 運用に何人を充てるか？
12. 本番リリース後3ヶ月の改善計画はあるか？

答えられない質問は、PoC を始める前に検討し、答えを出しておきます。半分以下しか答えられない場合は、PoC の設計そのものを見直すべきタイミングです。そもそも対象業務が AI に向いているかどうかは、AI 適合診断（5問・1〜2分・登録不要）でスコア化できます。

7. Kmetric の進め方 — 2週間で MVP（最小限の実用版）、1〜2ヶ月で本番へ

Kmetric が標準にしている、PoC から本番化までの進め方です。AI エージェント開発や AI 開発スタジオの案件は、この流れで進めています。

1〜3日目：要件把握・設計

• 事業 KPI と Go/NoGo 基準の確定
• 本番システムとの連携範囲の確定
• 自動評価用のテストケースの作成（最初は50件）
• 人間の確認を挟む引き継ぎ基準の合意

4日目〜2週目：MVP の実装とデモ

• 本番と同じシステム構成を、1/10の規模で実装
• 自動評価を継続して実行
• 業務責任者を交えたデモと Go/NoGo 判定

3週目〜2ヶ月目：本番リリース

• 本番と同じデータ規模への拡張
• セキュリティ要件の全面適用
• 監視・通知体制の構築
• 段階的な本番への切り替え
• 運用組織への引き渡し

3ヶ月目以降：改善ループ

• 本番の動作記録から、自動評価のテストケースを追加
• 人間からのフィードバックを学習データに反映
• 事業 KPI の継続的な計測