PoCとは

PoCとは

PoC（Proof of Concept）は、新しい技術や仕組みを本格的に開発する前に、自社の業務とデータで期待した機能を発揮できるかを小規模に確認する検証です。日本語では概念実証と訳します。構築するものは本番のシステムではなく、確認したい一点が分かる最小限の仕組みにとどめます。新しい技術や製品を採用する前の検証に広く用います。

工場にたとえると新しい工作機械を導入する前の試し削りに相当します。自社の材料と図面で削ってみて、求める精度が出るかを確認します。量産ラインの設計や作業手順の整備はその後に行います。

なぜ必要か

AIやデータ活用の開発では、開発してみるまで結果の分からない部分が残存します。予測の精度は手元のデータの量と質で左右され、契約の時点では約束できません。それでも通常のシステム開発と同じく全体の仕様を確定して一括で発注すると、期待した精度に達しないと分かるのは完成した後になります。そうなれば費用はまるごと無駄になります。

PoCはこの不確かさを本開発の前に小さな費用で確認します。経済産業省が2018年に公表したAI・データの利用に関する契約ガイドラインは、AIの開発を事前の見立て、PoC、開発、運用中の追加学習の4段階に区分しています。段階ごとに次の段階へ移行するかを当事者で確認する進め方です。PoC段階の目的は手元のデータで利用者が望む精度の予測の仕組みを構築できるかの確認とされます。

同ガイドラインはPoCを本開発とは別の導入検証契約で結び、構築した仕組みや提供したデータを誰がどこまで利用できるかを段階ごとに定める形を示しています。これを定めずに着手すると、本開発を別の会社へ依頼するときにPoCの成果を引き継げないことがあります。経済産業省の情報経済課が2021年1月に作成した概要資料が公正取引委員会の競争政策研究センターの会議資料として公開されており、段階ごとの目的、成果物、結ぶ契約が1枚に集約されています。

プロトタイプ・MVPとの違い

PoCはプロトタイプやMVP（Minimum Viable Product）とは確認する対象が違います。

言葉	確認すること	主な相手
PoC	技術的に実現できるか、狙った精度や性能が得られるか	開発チームと発注側の責任者
プロトタイプ	画面や操作の流れが利用できるか、要件に抜けがないか	利用者や業務担当者
MVP	実際の顧客がお金や時間を払う価値を感じるか	市場の顧客

MVPは最小の労力で顧客について最大の学びを得られる最小限の製品を指します。PoCで技術的にできると分かっても、顧客に利用されるかはMVPで別に確認する必要があります。

効果

• 本開発の前に、技術的に実現できない案を少ない費用で見切れる
• 自社のデータで得られる精度や処理時間が分かり、本開発の見積もりと計画の精度が上がる
• データの欠損や形式のばらつきなど、本開発で問題になる点を早期に発見できる
• 結果を数値で示せるため、社内で本開発の予算承認を得る材料になる

コストとリスク

• PoCの費用と期間は成功しても本開発の費用と期間とは別にかかる
• PoCの仕組みを本番用に再構築する費用が別にかかる
• 本番のデータ連携、運用の担い手、利用部門への展開の費用は、PoCの段階ではまだ判明しない
• 業務部門の担当者がデータの準備や評価に時間を取られる。日経クロステックは2019年の記事で、慣れない作業が続いて業務部門が疲弊する状態をPoC疲れとして取り上げている
• 自社のデータを開発会社や外部のサービスに提供する。個人情報を含むか、提供したデータが相手の学習に利用されないかを契約で確認しておく
• 検証の範囲を広げすぎるとPoCが実質的に本開発の前倒しになり、打ち切りの判断がしにくくなる

PoC止まりが発生する理由

PoCで良い結果が得られても本番の導入に至らない状態を、PoC止まりと呼びます。調査会社IDCがLenovoと共同で行い2025年に公表した調査では、企業が開始したAIのPoCのうち本番に移行するのは33件に4件の割合でした。調査を紹介したCIO.comの記事は、理由に投資対効果の不明確さ、AIに利用できる状態のデータの不足、社内の専門人材の不足を挙げています。

原因の多くは技術ではなく、着手前に定めるべきことを定めていない点と結果の評価の仕方にあります。

• 何が分かれば成功かを定めずに着手し、結果を確認してから評価の基準を定める
• 本番へ移行したときの予算と、本番の運用を担う部署が確定していない
• PoCの件数そのものが成果として評価され、本番化を決定する人がいない。本番化の段取りがないまま数を重ねると、費用と業務部門の負担だけが積み上がり、新しい技術そのものへの不信が社内に残る
• PoCで使用したデータが手作業で整備したもので、本番のデータでは同じ結果が得られない
• PoCの仕組みをそのまま本番に流用する。検証の速さを優先して障害時の動き、セキュリティ、利用者の増加への備えを省略しているため、後から改修する手間が技術的負債として積み上がる

逆の読み違いもあります。期待した精度が得られなかったPoCでも、技術そのものは活用できる場合があります。原因がデータの量や整え方にある場合です。打ち切る前に、データを追加すれば目標の精度に到達する見込みがあるかを開発会社に確認します。