システム開発のPoCとは — 費用相場10万〜300万円と失敗しない進め方

PoC（Proof of Concept：概念実証）とは、システムの本開発に入る前に、小さく作って「技術的に実現できるか」「期待した効果が出るか」を確かめる検証作業のことです。本番の完成品を作るのではなく、いちばん不確かな部分だけを短期間・低予算で試し、本開発に進むか、やり方を変えるか、やめるかを判断する材料にします。

数百万円から数千万円の開発を発注してから「思っていたものと違った」「AIの精度が足りなかった」とわかると、取り返しがつきません。そこで、本開発の前に数十万円〜数百万円で不確かさを減らしておく、というのがPoCの考え方です。本記事では、IT専門ではない経営者・担当者向けに、PoC・プロトタイプ・MVPの違い、向くケースと不要なケース、費用と期間の目安、合否ラインの決め方、契約の注意点、よくある失敗、発注前のチェックリストまでを整理します。費用はいずれも市場の一般的な目安であり、実際の金額は内容や依頼先によって大きく異なります。

PoCでよくある誤解は、「本開発の縮小版を作ること」だと考えてしまう点です。PoCの目的は、完成度の高いものを作ることではなく、仮説を検証して判断材料を得ることにあります。たとえば「問い合わせメールをAIで自動分類できるか」を確かめたいなら、画面やログイン機能は不要で、過去のメール数百件を使って分類の正解率を測れば足ります。「現場の担当者が新しい入力画面を使いこなせるか」を確かめたいなら、裏側の処理は作らず、画面だけを動かして触ってもらえば十分です。

つまりPoCでは、「何がいちばん不確かか」を先に決め、そこだけを検証します。不確かさには大きく3種類あります。技術的に作れるのか（技術リスク）、使う人が使ってくれるのか（利用リスク）、費用に見合う効果が出るのか（効果リスク）です。この3つのどれを潰したいのかが曖昧なままPoCを始めると、「とりあえず動くものができたが、何がわかったのかわからない」という結果になりがちです。

似た言葉に、プロトタイプとMVP（Minimum Viable Product：実用最小限の製品）があります。現場では混同して使われることも多いため、発注前に「自社が頼みたいのはどれか」を揃えておくことが大切です。

簡単に言えば、PoCは「作れるかを試す」、プロトタイプは「見て触って決める」、MVPは「小さく出して反応を見る」です。たとえば新しい受発注システムを検討しているなら、まず画面の紙芝居（プロトタイプ）で現場と認識を合わせ、自動連携の部分に不安があればPoCで技術検証し、それから最小限の機能で運用を始める（MVP）という順番が考えられます。すべてを順番に踏む必要はなく、不確かさが小さいところは飛ばして構いません。

PoCは万能ではありません。やれば必ず安心できるわけでも、すべての開発に必要なわけでもありません。判断の目安は「失敗したときの損失の大きさ」と「やってみないとわからない部分があるか」の2点です。

PoCが向くのは、次のようなケースです。

- AI・機械学習を使う案件（必要な精度が出るかは、データを使って試すまでわからない）
- 既存システムや外部サービスとの連携があり、つながるかどうかが不確かな案件
- 前例のない業務や新しいサービスで、現場が使いこなせるかわからない案件
- 本開発の予算が大きく（目安として数百万円以上）、失敗の損失が大きい案件
- 経営層・現場・開発側で、完成イメージの認識がそろっていない案件
- 社内の合意を取るために、動くものを見せる必要がある案件

反対に、PoCが不要、または簡易なもので足りるのは次のようなケースです。

- 実績のある標準的なパッケージやSaaSで足りる案件（試用期間やデモで確認できる）
- 既存システムの小さな改修で、仕様がはっきりしている案件
- 同種の開発の経験が社内外に十分あり、技術的な不確かさが小さい案件
- 予算が小さく、PoCの費用が本開発の費用に近づいてしまう案件
- 既に結論が出ており、PoCが「形式的な通過儀礼」になりそうな案件

とくに最後の「形式的な通過儀礼」は注意が必要です。結果がどうであれ本開発に進むと決まっているなら、PoCは単なる前払いの工程になり、判断材料としての意味を失います。「この結果が出たら中止または方針変更する」という選択肢を、最初から本気で用意しておけるかが分かれ目です。発注全体の進め方はシステム開発の発注ガイドでも整理しています。

PoCの費用は、何を検証するかで大きく変わります。以下は市場で見られる一般的な目安のレンジであり、特定の会社の価格や保証ではありません。データの準備状況、検証の範囲、依頼先の規模によって、実際の金額はこの範囲を外れることもあります。

AI精度検証が高くなりやすいのは、データの整理や加工、評価用の正解データの作成に手間がかかるためです。自社でデータを整えておけば、その分だけ費用と期間を抑えられます。また、PoCの費用は本開発の費用の1〜2割程度に収めるのがひとつの考え方で、本開発が300万円なら30万円前後、3,000万円なら150〜300万円が一般的な水準です。PoCだけで本開発に近い金額になる場合は、検証の範囲を広げすぎていないか見直す価値があります。本開発の費用感はシステム開発費用の相場ガイドで整理しているので、あわせて参考にしてください。

期間については、PoCは長くするほど良いものではありません。3か月を超えると目的がぼやけ、検証が「開発の前倒し」に変わっていく傾向があります。期間を決め、期限が来たら、結果がどうあれ判断会議を開くことを最初に約束しておくと、ずるずると延びるのを防げます。

PoCでいちばん大切なのは、始める前に「どうなったら成功か」を数字で決めておくことです。これを決めずに始めると、結果が出た後に「まあまあ良さそうだ」「もう少し続ければ良くなるかも」と評価が揺れ、結局、判断ができません。成功基準は、次の3点セットで決めると整理しやすくなります。

- 測る指標：何を測るか（例：分類の正解率、1件あたりの処理時間、入力ミスの件数、現場の満足度）
- 合格ライン：いくつなら合格か（例：正解率90%以上、処理時間を現状の半分以下）
- 判断ルール：合格・不合格・中間のとき、それぞれどうするか（例：合格なら本開発の見積に進む、中間なら範囲を絞って再検証、不合格なら中止）

合格ラインは、現状の業務を基準に決めるのがコツです。たとえば問い合わせ分類を人が行っていて、人の正解率が95%なら、AIに求める水準は「95%以上」ではなく、「人がチェックする前提で、作業時間が半分になる水準」かもしれません。完璧を目指すと、永遠に合格しないPoCになります。現実の業務で「これなら使える」と言える最低ラインを、現場の担当者と一緒に決めてください。

また、不合格になる場合も想定しておくことが重要です。PoCの価値は「成功すること」ではなく「早く安く、正しく判断できること」にあります。不合格の結果が出たPoCは、数千万円の失敗を数十万円で防いだ、という意味で十分に成果です。この考え方を、経営層や関係者と事前に共有しておくと、結果に対する受け止め方が変わります。

PoCは「やってみないとわからない」要素を含むため、通常の開発とは契約の考え方が異なります。契約書で確認しておきたい点を整理します。契約全般の基本はシステム開発の契約の基礎知識も参考になります。

準委任契約が多い点は、依頼する側から見ると不安になるかもしれません。ただし、PoCは結果が不確かなこと自体を検証するものなので、「必ず成功する」という成果の保証は性質上なじみません。その代わりに、検証の手順、報告の頻度、判断の会議の日程といった「プロセス」を契約の中で具体的に決めておくことで、依頼する側の納得感を高められます。

もうひとつ見落としやすいのが、本開発への移行条件です。PoCを実施した会社が、そのまま本開発も受注すること前提で低価格でPoCを引き受ける場合があります。それ自体は悪いことではありませんが、PoCの成果物（ソースコードや検証データ）を受け取れず、他社に切り替えられない状態になると、本開発の価格交渉力を失います。PoCの成果物は自社が受け取れるようにし、本開発は改めて見積と比較して決められるようにしておくのが安全です。見積の読み方や比較の仕方はRFP（提案依頼書）の基本も役立ちます。

PoCは成功したのに、本開発に進まず終わってしまう状態は「PoC死」と呼ばれ、AIやDXの現場で広く問題になっています。技術的には合格だったのに、そのまま忘れ去られてしまうのです。原因の多くは、PoCの結果ではなく、PoCの「始め方」にあります。

- 本開発の予算や担当者が決まっていないまま、「まず試してみよう」で始めてしまった
- 現場の課題ではなく、「AIを使ってみたい」という手段が先にあった
- 合格したときに誰が何をするか（本開発の責任者、予算の決裁）が決まっていなかった
- 検証したのは技術だけで、運用の手間、セキュリティ、既存業務への組み込みを考えていなかった
- PoCの担当者だけが盛り上がり、現場や経営層が関与していなかった

防ぐ方法はシンプルで、PoCを始める前に「合格したら、いつまでに、誰が、いくらの予算で、何をするか」を決めておくことです。完全に確定している必要はありませんが、たとえば「合格なら翌期の予算で本開発の見積を取る。決裁者は〇〇、現場の責任者は〇〇」といった大枠は、PoCの開始前に決めておきます。また、PoCの段階から現場の担当者に実際に触ってもらい、本番の運用を想定した感想を集めておくと、本開発への移行がスムーズになります。AI活用の失敗パターンはAI導入の失敗パターンでも詳しく扱っています。

PoCそのものが失敗する典型的なパターンを挙げます。前章のPoC死とは別に、検証の進め方で起こりがちなものです。

とくに「きれいなデータだけで検証する」は見逃されがちです。PoCでは整ったサンプルデータで高い精度が出たのに、本番では表記ゆれや欠損だらけの実データで大きく精度が落ちる、という話はよく聞きます。できるだけ実際の業務データに近いものを使い、うまくいかないケースも含めて検証することが、PoCを意味のあるものにします。開発全般で起こりやすい失敗はシステム開発の失敗パターンも参考になります。

実際の進め方を、大まかな流れで整理します。小さなPoCでも、この順番を意識するだけで結果の質が変わります。まず、課題と仮説を整理します。解決したい業務上の課題は何か、「こうすれば解決するはず」という仮説は何か、を一文で書けるようにします。次に、成功基準を決めます。前述の指標、合格ライン、判断ルールです。三つ目に、検証の範囲とデータを決めます。何を作り、何を作らないか、どのデータを使うか、データの提供や加工は誰が行うかを確定します。四つ目に、短い期間で検証を実施します。週次で状況を共有し、途中で方向修正が必要なら範囲内で調整します。五つ目に、結果を報告し、判断会議を開きます。数字の結果だけでなく、わかったこと・わからなかったこと・本開発への提言をまとめ、事前に決めた判断ルールに従って次の一手を決めます。

ここで重要なのは、判断会議に決裁者が出席することです。担当者レベルの報告で終わってしまうと、PoC死の原因になります。会議の日程をPoCの開始時にあらかじめ押さえておくのも有効です。

PoCを依頼する前に、次の項目を確認してください。すべてに「はい」と答えられる必要はありませんが、答えられない項目があれば、そこが後で問題になりやすい部分です。

- 解決したい業務上の課題を、一文で説明できる
- 検証したい不確かさ（技術・利用・効果のどれか）を決めている
- 測る指標と、合格ラインの数字を決めている
- 不合格・中間の結果だった場合の対応を決めている
- PoCの費用が、本開発の費用に対して妥当な割合（目安は1〜2割）に収まっている
- 期間と、判断会議の日程、決裁者の出席を決めている
- 検証に使う実データと、その提供・加工の担当を決めている
- 契約形態（準委任か請負か）と、検証の範囲を文書で確認している
- 成果物の範囲と、知的財産権の帰属、データの取り扱いを確認している
- 合格した場合に本開発を依頼する義務がないこと、他社に切り替えられることを確認している
- 合格後の予算、担当者、スケジュールの大枠を決めている
- 現場の担当者が検証に関わる体制になっている