---
title: "PoC（概念実証）とは？意味・進め方と計画書、PoC止まりを防ぐ判断基準"
url: "https://www.issoh.co.jp/column/details/5223/"
published: 2025-02-07
updated: 2026-10-30
categories: ["ビジネス理論・用語"]
publisher: "株式会社一創"
---

# PoC（概念実証）とは？意味・進め方と計画書、PoC止まりを防ぐ判断基準

PoC（Proof of Concept、概念実証）は、新しい技術やアイデアを本格的に作り込む前に、限られた範囲で「本当に実現できるか」「投資に見合う効果が出るか」を確かめる検証です。読み方は「ピーオーシー」が一般的で、「ポック」と呼ぶ人もいます。経済産業省のDXレポートは、日本企業でPoCが繰り返される一方で事業の変革につながっていない状況を指摘しました。本記事では、PoCの意味とPoV・PoB・実証実験・プロトタイプとの違い、進め方と計画書の項目、外部に依頼するときの契約、PoC止まりを防ぐ判断基準を、経産省・特許庁の公開資料の原文に沿って整理します。

## まとめ：PoCの要点

- PoCは本開発の前に「実現できるか・効果が出るか」を限定範囲で確かめる工程です。成果物は検証レポートなどの判断材料で、検証内容によって試作品や学習済みモデルも含みます。
- PoVは事業価値、PoBは事業として成立するか、プロトタイプは形と操作感、MVPは市場の反応を確かめます。PoCはこのうち「作れるか」を確かめる検証で、どれから行うかは未確認の課題で決めます。
- 進め方は「目的と合否基準を決める→範囲と期間を絞る→計画書で合意→実施→評価して次へ進むか決める」の5段階です。開始前に撤退ラインまで決めます。
- 外部に依頼するPoCは、成果物の完成を約束しない準委任型の契約が基本です。無償で繰り返す「PoC貧乏」を避けるため、費用・知財・次の段階への協議を契約に書きます。
- DXレポートは「戦略なき技術起点のPoCは疲弊と失敗のもと」と書いています。「AIで何かできないか」から始めるPoCは、始める前に目的を作り直すべきです。

## PoCの意味と読み方（Proof of Concept＝概念実証）

PoCはProof of Conceptの頭文字で、日本語では「概念実証」と訳します。経済産業省の[DXレポート（2018年9月7日）](https://www.meti.go.jp/shingikai/mono%5Finfo%5Fservice/digital%5Ftransformation/pdf/20180907%5F03.pdf)は、PoCを「新しいプロジェクト全体を作り上げる前に実施する戦略仮説・コンセプトの検証工程」と説明しています。企画書の段階では見えない性能・費用・現場への当てはまりを、実データや実機で確かめて、本開発に進むかを決める材料をそろえる工程です。

### PoCで確かめる3つの論点

PoCで確かめる対象は、技術・効果・業務の3つに分かれます。技術は「想定の精度や処理速度が実データで出るか」、効果は「導入した場合に費用削減や売上増が投資額を上回るか」、業務は「現場の手順や既存システムに組み込めるか」です。論点ごとに測る指標も必要なデータも違うため、3つを同時に追うと準備と評価の工数が膨らみ、期日までに判断できる結果がそろわないことがあります。最も不確実な1つを主目的に置き、残りは測る範囲を絞るか次の段階に回すと、評価会議で結論を出しやすくなります。

### 医療・創薬のPoCと、同じ綴りのPOC（point of care）

PoCという言葉は医薬品開発でも使われます。新薬の候補が人で狙った効果を示すかを初期の臨床試験で確かめることを指し、たとえば厚生労働科学研究の[2014年度の研究報告](https://mhlw-grants.niph.go.jp/project/24033)は、第I/IIa相の医師主導治験について「有効性に関しても、POC（proof of concept）がほぼ得られている状況」と記しています。一方、医療機器や検査の分野で見かけるPOCは別の言葉で、[米FDA](https://www.fda.gov/medical-devices/coronavirus-covid-19-and-medical-devices/covid-19-test-uses-faqs-testing-sars-cov-2)は「Point-of-care (POC) settings」を患者の近くで検査を行う場として説明しています。「POC検査」「POCT」と書かれていれば、概念実証ではなく臨床現場即時検査のことです。

## PoCとPoV・PoB・実証実験・プロトタイプ・MVPの違い

似た言葉は、何を確かめるかで区別します。法令や規格で定めた定義はなく、企業や業界によって使い方に幅があるため、社内や取引先と使うときは「この工程で何を確かめるか」を言葉の定義より先に合わせてください。

| 用語                     | 確かめること        | 主な成果物      |
| ---------------------- | ------------- | ---------- |
| PoC（概念実証）              | 実現できるか        | 検証結果のレポート  |
| PoV（Proof of Value）    | 導入効果が投資に見合うか  | 効果の試算・測定結果 |
| PoB（Proof of Business） | 事業として収益が成り立つか | 事業計画・収支見込み |
| 実証実験                   | 実環境で運用できるか    | 運用上の課題と改善点 |
| プロトタイプ                 | 形・操作感が意図どおりか  | 動く試作品      |
| MVP                    | 市場で受け入れられるか   | 最小限の機能の製品  |

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

PoCの問いは「そもそも作れるか」、プロトタイプの問いは「どういう形にするか」です。PoCで試作品を作ることはありますが、それは判断材料を得る手段で、完成度は問いません。技術的な成立が最大の懸念ならPoCを先に置き、画面や操作が課題ならプロトタイプで確かめるなど、未確認の課題に応じて順序を決めます。試作品の種類や作り方は[プロトタイプとは？意味・語源・略し方とプロトタイピングの種類・進め方](/column/details/6627/)、市場に出して反応を見るMVPの範囲の決め方は[MVP開発とは？進め方5ステップとPoC・プロトタイプの違い・範囲の決め方](/column/details/7849/)で解説しています。

### PoV・PoB・実証実験の違い

PoVとPoBは、技術的な実現可能性とは別に、導入効果や事業の採算を検証するための整理です。PoVは「1部署で使ったら作業時間が何時間減るか」のように効果を金額や時間で測り、PoBは価格・販路・原価を含めて事業の収支が成り立つかを見ます。実証実験は、実際の利用環境で運用上の課題を確かめる試行を指して使われる言葉ですが、PoCと呼び方や範囲が重なる場合もあるため、名称だけで規模や期間を判断せず実施条件を確認します。どれも「次に進むか」を決める材料を得る工程である点は同じなので、名称にこだわるより、検証の問いと合否基準を明確にするほうが実務では効きます。

## 新規事業・DXでPoCを行うべき場面と省くべき場面

PoCが役に立つのは、結果が事前に読めず、外れたときの損失が大きい案件です。社内にない技術を使う、手元のデータで精度が出るか分からない、現場の運用が変わる、といった条件が重なるほど価値が上がります。新規事業では、市場の反応を確かめる前に「この仕組みで提供できるか」を先に詰める段階として置かれます。新規事業の検証全体の考え方は[リーンスタートアップとは？意味・進め方と「時代遅れ」論を研究データで検証](/column/details/9236/)が参考になります。

反対に、PoCを省いて本開発やSaaSの試用に進むべき場面もあります。既存パッケージの標準機能で要件を満たし、自社環境への適合性に未確認の論点がなく、失敗時の損失も小さい案件なら、独立したPoCを省く判断ができます。「上司を説得する材料が欲しい」という理由で始めるPoCも、合否基準が後付けになりやすく、結果が出ても判断に使われません。

## PoCの進め方5ステップ

1. 目的と合否基準を決める：主に確かめる論点を1つ選び、合格・不合格を判定できる数値にする。
2. 範囲と期間を絞る：対象業務・データ・拠点を限定し、検証しない範囲も書き出す。
3. 計画書で合意する：目的、合否基準、体制、期間、判断する人を関係者で合わせる。
4. 実施してデータを取る：本番に近い条件で試し、うまくいかなかった記録も残す。
5. 評価して次の段階を決める：合否基準と照らして、本開発・再検証・中止のどれかを決める。

### 合否基準（KPI）と撤退ラインの決め方

合否基準は、後から「達成した・しなかった」を言い争わずに判定できる形にします。指標・測り方・閾値はセットで書きます。たとえば「固定した評価用の問い合わせ100件を担当者が採点し、85件以上で正答」（数値は説明用の例）とすれば、評価対象・採点方法・合格ラインを共有できます。同時に「この数値を下回ったら中止する」撤退ラインも決めておきます。合格ラインだけを決めて撤退ラインを決めないと、未達のたびに条件を変えて再検証が続き、後述のPoC止まりに入ります。

### 期間とスケジュールの組み方

期間は検証の中身で決まり、一律の目安はありません。経産省の[AI・データの利用に関する契約ガイドライン](https://www.meti.go.jp/press/2019/12/20191209001/20191209001-1.pdf)は、PoCの前段のアセスメント段階でも「数か月単位の時間をかけて行うことも珍しくはない」とし、PoC段階は「1回で完結せず、複数回実施されることも少なくない」と書いています。期間を区切る目的は、期日に評価会議を開いて判断を先送りしないことにあります。下は8週間で組んだ場合の配分の例です。

| 時期（例） | 作業           | 終わったと言える状態        |
| ----- | ------------ | ----------------- |
| 1〜2週目 | 計画書の合意・データ受領 | 合否基準と判断者が決まっている   |
| 3〜6週目 | 検証の実施・測定     | 合否基準の数値が取れている     |
| 7週目   | 結果の分析・報告書作成  | 未達の原因が切り分けられている   |
| 8週目   | 評価会議         | 本開発・再検証・中止が決まっている |

### 評価と次の段階への判断

評価会議では、合否基準の数値だけでなく、未達だった場合にその原因がデータ・技術・業務のどこにあるかを切り分けます。データの量や質が原因なら、データを整えたうえでの再検証に意味があります。技術の限界が原因なら、条件を変えて繰り返しても結果は変わりにくく、中止か別の手段への切り替えを選ぶべきです。判断する時期も先に決めておきます。OIモデル契約書のPoC契約書（AI編・ver1.0）は第6条で、報告書の確認完了日から2か月以内に共同研究開発へ進むか否かの検討結果を通知する義務を事業会社に課しており、解説は「PoC後に次のステップに進むかどうか未確定なままで時間が経過することを避けるため」と理由を述べています。社内のPoCでも、計画書に判断者と評価会議の日を書いておくと同じ効果があります。

## PoC計画書に書く項目

計画書は分厚い資料である必要はなく、関係者が同じ前提で動ければ足ります。次の項目が埋まっていれば、実施中の範囲の膨張と、評価時の判断の先送りを防げます。

| 項目      | 書く内容の例             |
| ------- | ------------------ |
| 背景と目的   | 解決したい業務課題・主に確かめる論点 |
| 合否基準    | 指標・測り方・合格の閾値       |
| 撤退ライン   | 中止を決める数値・条件        |
| 検証範囲    | 対象業務・データ・拠点        |
| 検証しない範囲 | 今回は扱わない機能・部署       |
| 体制と役割   | 実施者・データ提供者・判断者     |
| 期間と評価日  | 開始日・中間確認日・評価会議の日   |
| 費用と負担   | 予算・外部委託費・負担する部署    |
| 成果物     | 報告書の形式・提出日         |
| 次の段階    | 合格時に進む工程と予算の目処     |

社内決裁を通すための事業計画との違いや、撤退基準の書き方は[社内向け事業計画書の書き方｜新規事業の決裁で問われる項目と撤退基準・創業計画書との違い](/column/details/12231/)で詳しく扱っています。

## PoCを外部に依頼するときの契約と費用負担

PoCを開発会社やスタートアップに依頼するときは、本開発の契約とは性質が違う点を押さえておきます。特許庁と経済産業省は、秘密保持からPoC、共同研究開発、ライセンスまで段階ごとのひな形をそろえた[OIモデル契約書](https://www.jpo.go.jp/support/general/open-innovation-portal/index.html)を公開しており、2025年4月改訂のver2.2にも新素材編とAI編のPoC契約書が収められています。AIの検証については、経済産業省の[AI・データの利用に関する契約ガイドライン1.1版（令和元年12月）](https://www.meti.go.jp/press/2019/12/20191209001/20191209001-1.pdf)が段階ごとの契約の考え方を示しています。

### PoC契約の契約類型と成果物の範囲

AI・データの利用に関する契約ガイドラインは、AI開発を「アセスメント段階」「PoC段階」「開発段階」「追加学習段階」に分ける「探索的段階型」の開発方式を提唱し、PoC段階の契約を「導入検証契約書」、成果物を「レポート／学習済みモデル（パイロット版）等」としています。そのうえで、PoC段階は「そもそも学習済みモデルの完成を目的とする段階ではない」ため、完成を約束する請負型ではなく、役務の提供を目的とする準委任型の契約が「実態になじみやすい」と述べています。OIモデル契約書のPoC契約書の[逐条解説（ver1.0）](https://github.com/meti-oi-startups/METI-JPO-Model-Contract)も、実質は検証を行って報告書を作る「業務委託契約（準委任契約）」だと説明しています。

発注側が注意したいのは、準委任では「目標の精度が出なかった」こと自体は契約違反にならない点です。合否基準は契約で結果を保証させるためではなく、評価会議で次へ進むかを決めるために使います。請負と準委任の違いは[準委任契約とは？請負・派遣との違いとシステム開発での使い分けを解説](/column/details/13187/)で整理しています。

### 「PoC貧乏」を避けるために契約に書くこと

同じ逐条解説は、本開発への移行をちらつかせて無償のPoCを次々に依頼し、結局本開発に進まないために受託側が費用を回収できないケースを「PoC貧乏」と呼び、検証で得た知見の譲渡を迫られたり無断で出願されたりする紛争も起きていると書いています。発注側も、検証に必要な工数と対価を合意し、担当者・実施範囲・報告内容を契約で明確にします。

契約では、少なくとも次の4点を決めておきます。検証の内容と提供するデータの範囲（量・形式・提供日）、報酬と支払時期、報告書や検証中に生まれた知的財産の帰属と利用条件、合格した場合に本開発をいつまでに協議するか、です。AIの検証を外部と組む場合は、自社の[AIコンサルティング・PoC支援](/service/ai/poc/)のように、合否基準と撤退ラインの設計から関わる体制を選ぶと、検証結果がそのまま本開発の判断に使えます。

## PoC止まり（PoC死・PoC疲れ）の原因と防ぎ方

PoCを繰り返しても本開発や事業に進まない状態は「PoC止まり」「PoC死」、検証が続いて現場が消耗する状態は「PoC疲れ」と呼ばれます。DXレポートは、経営者から明確な指示がないまま「AIを使って何かできないか」と指示が出され、「PoCが繰り返されるものの、ビジネスの改革に繋がらないといったケースも多い」と指摘し、失敗ケースとして「戦略なき技術起点のPoCは疲弊と失敗のもと」を挙げています。DXレポートが示した課題がその後どうなったかは[2025年の崖とは何だったのか｜DXレポートの試算と2026年に刷新を判断する基準](/column/details/16398/)で検証しています。

技術的な検証に成功しても、事業化の準備が足りなければ本開発には進めません。目的が「新しい技術を試すこと」になっている、合否基準と判断者が決まっていない、合格しても本開発の予算と担当部署が決まっていない、の3つが重なると、PoCは成功しても止まります。防ぎ方は、PoCを始める前に「合格したら誰がいくらの予算で何を作るか」まで決めることです。そこまで決められない案件は、PoCより先に目的の作り直しが要ります。

## AI・生成AIのPoCで検証範囲に入れる項目

AIのPoCは、デモが短時間で動くぶん「動いた＝成功」と誤判定しやすい領域です。Gartnerは[2024年7月29日の発表](https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025)で、生成AIプロジェクトの少なくとも30%が2025年末までにPoCの後で放棄されると予測し、理由に「データ品質の低さ、不十分なリスク管理、膨らむコスト、不明確な事業価値」を挙げました。裏を返せば、精度だけを測るPoCでは、この4つの理由を事前に見抜けません。

生成AIのPoCでは、回答の正答率に加えて、社内データを整える工数、誤答（ハルシネーション）の発生率と許容できる上限、本番の利用量で試算したAPI費用と応答時間、個人情報や機密情報の扱いを検証範囲に入れます。精度目標の置き方や学習データの準備、本番移行の判断基準は[AI PoCとは？精度目標の決め方とデータ準備・本番移行を判断する基準](/column/details/16003/)、誤答を減らす実装は[AIハルシネーション対策｜プロンプト・RAG・検出APIで誤答を減らす実装手順](/tech/details/8017/)で解説しています。

## よくある質問

### PoCは何の略ですか？

Proof of Conceptの略で、日本語では「概念実証」と訳します。読み方は「ピーオーシー」が一般的で、「ポック」と読む人もいます。医療の検査分野で使うPOC（point of care）は別の言葉です。

### PoCの期間はどのくらいが目安ですか？

一律の目安はありません。対象業務が1つでも、必要なデータの準備や評価条件によって期間は変わり、AIのように精度の改善を繰り返す検証では、PoCを複数回に分けることもあります。期間より、評価会議の日を開始前に決めておくことが大切です。

### PoCの費用は資産計上できますか？

多くの場合、費用として処理します。研究開発に当たる支出は[研究開発費等に係る会計基準](https://www.asb-j.jp/jp/accounting%5Fstandards%5Fsystem/details.html?topics%5Fid=82)で「すべて発生時に費用として処理しなければならない」とされ、自社で使うソフトウェアの制作でも、将来の収益獲得や費用削減が確実と言えない段階の支出は費用処理になります。税務上の扱いは会計上の処理と異なる場合があるため、判定は[システム開発費の資産計上と費用処理｜判定基準・勘定科目・PoC・要件定義の扱い](/column/details/11038/)を参照してください。

### PoC開発と本開発は何が違いますか？

PoC開発は判断材料を得るための作業で、成果物には検証結果の報告書や、検証用の試作品・モデルなどがあります。本開発は運用に耐える製品を完成させる作業で、品質・保守性・セキュリティの要件を満たす必要があります。PoCで作ったコードをそのまま本番に流用すると、検証のために省いた例外処理や権限管理が抜けたまま残るため、本開発で作り直す前提で予算を組みます。

### PoCを依頼する開発会社はどう選べばよいですか？

検証したい技術の実績に加えて、合否基準と撤退ラインの設計に踏み込んでくれるか、PoCの後の本開発まで見通した提案ができるかを確認します。契約は準委任型が基本なので、報告書の形式、知的財産の帰属、合格時の本開発の協議時期を見積もりの段階で確認しておくと、PoC貧乏やPoC止まりを避けられます。

## 関連記事

- [プロトタイプとは？意味・語源・略し方とプロトタイピングの種類・進め方](/column/details/6627/)
- [MVP開発とは？進め方5ステップとPoC・プロトタイプの違い・範囲の決め方](/column/details/7849/)
- [AI PoCとは？精度目標の決め方とデータ準備・本番移行を判断する基準](/column/details/16003/)
- [準委任契約とは？請負・派遣との違いとシステム開発での使い分けを解説](/column/details/13187/)
- [システム開発費の資産計上と費用処理｜判定基準・勘定科目・PoC・要件定義の扱い](/column/details/11038/)

---

出典: [PoC（概念実証）とは？意味・進め方と計画書、PoC止まりを防ぐ判断基準](<https://www.issoh.co.jp/column/details/5223/>)（株式会社一創）