PoC を勧められたら、最初に決めること
「まず PoC から始めましょう」。新しいシステムや生成 AI の導入を検討していると、社内からもベンダーからも、この言葉をよく聞きます。小さく試してから本開発に進むという考え方自体は正しいのですが、PoC という言葉だけが先に決まり、何を確かめて、どうなったら終わりなのかが決まらないまま始まる例は少なくありません。
その結果、検証は終わったのに次に進むかどうかを誰も決められず、追加の検証だけが続きます。DX 推進が止まる原因としてよく挙がる状態で、全体像は DX 推進が失敗する 7 つの原因 で整理しています。
本記事では、PoC の意味と読み方から入り、似た言葉との違い、進め方の 6 ステップ、本番に進むかを決める判定基準、期間・費用・契約の考え方までを、発注者の立場で整理します。経済産業省の公開資料を引いた箇所には、本文に出典を示しました。後半では、AI エージェントの PoC で追加して確かめることを 1 つの章にまとめています。
PoC とは: 意味・読み方と目的
PoC の意味と読み方
PoC は Proof of Concept の略で、日本語では「概念実証」と訳します。読み方は「ピーオーシー」が一般的で、「ポック」と読む人もいます。新しい技術やアイデアが自社の業務で実際に成り立つかを、本開発の前に小さな範囲で確かめる検証のことです。
経済産業省の DX レポート (2018 年 9 月) は、PoC を「戦略仮説・コンセプトの検証工程」と説明しています。技術として成り立つかに加えて、事業上の狙い (戦略仮説) が成り立つかを確かめる工程だと読めます。
PoC の目的は、進むか止めるかを決める材料を集めること
PoC の目的は、動くものを作ることではありません。本開発に進むか、止めるかを決める材料を、本開発より小さな費用と期間で集めることです。
経済産業省の AI・データの利用に関する契約ガイドライン - AI 編 - (平成 30 年 6 月。以下、AI 契約ガイドライン) は、AI の学習済みモデルを作る開発を、アセスメント・PoC・開発・追加学習の段階に分けて進める「探索的段階型」の開発方式を提唱しています。本記事で引く箇所は、令和元年 12 月の 1.1 版でも同じです。段階に分ける利点として挙げているのは次の 2 つです。
- 段階ごとの達成目標を明確にすることで、発注者と開発側が成果物への認識をすり合わせられる
- 十分な性能が出ないと分かった段階で開発を中止でき、それ以上の損失の拡大を防げる
2 つ目が示すとおり、「止める」と判断できることも PoC の成果です。止める判断を失敗と捉えると、担当者は結果を良く見せようとし、PoC を続けること自体が目的になりがちです。
PoC で確かめる 3 つのこと
PoC で確かめることは、大きく 3 つに分けられます。
| 観点 | 確かめること | 例 |
|---|---|---|
| 技術 | 自社のデータと条件で、目的の処理ができるか | 自社の帳票を読み取れるか、社内文書から正しく答えを探せるか |
| 業務での効果 | 現場の作業が実際に変わり、担当者が使い続けられるか | 手作業の時間が減るか、出力を手直しなしで使えるか |
| 費用 | 本番の規模で、費用が効果に見合うか | 本番の処理量での利用料・運用の人手が、削減できる工数に見合うか |
技術の観点だけを確かめて終えると、本開発に進むかは決められません。決めるには 3 つとも必要です。どれを今回の PoC で確かめ、どれを後の段階に回すかを、始める前に決めておきます。
PoC と似た言葉の違い: 実証実験・プロトタイプ・MVP・PoV・PoB
PoC の周辺には、似た目的の言葉がいくつもあります。提案書や社内の議論で混ざりやすいので、確かめることと終わり方で比べておきます。定義は資料や会社によって異なるため、ここでは一般的な使い分けで比べます。
| 言葉 | 確かめること | 作るもの | 終わり方 |
|---|---|---|---|
| PoC | 技術やアイデアで目的を達成できるか | 検証用の仕組み・検証結果のレポート | 本開発に進むか止めるかを判定する |
| 実証実験 | 実際の環境で使ったときに課題が出ないか | 実環境に置く製品・サービス | 課題を洗い出し、導入の可否を決める |
| プロトタイプ | 操作・画面・機能の形が意図どおりか | 試作品 | 仕様やデザインを固める |
| MVP | 市場や顧客に受け入れられるか | 最小限の機能を持つ実際の製品 | 利用者の反応を見て改善を続ける |
| PoV | 利用者や顧客にとって価値があるか | 価値を測るための試用・調査 | 価値に見合う投資かを判断する |
| PoB | 事業として採算が取れるか | 収支の試算・事業計画 | 事業化の可否を判断する |
PoC と実証実験は厳密に区別されず、同じ意味で使われる場面もあります。言葉の定義そのものより、何を確かめて、何をもって終わりとするかが提案書に書かれているかを確認してください。
MVP は PoC と混同されやすい言葉ですが、利用者に使ってもらう実際の製品で、作って終わりではなく改善を続ける前提です。技術が成り立つと分かったうえで市場の反応を確かめたい場合は、MVP の段取りが合います。進め方は SaaS の MVP の作り方 で解説しています。
PoC が本番に進まない 4 つの理由
PoC を繰り返しても本番に進まない状態は、「PoC 疲れ」「PoC 止まり」と呼ばれます。経済産業省の DX レポートは、この状態について次のように書いています。
しかしながら、PoC（Proof of Concept: 概念実証。戦略仮説・コンセプトの検証工程）を繰り返す等、ある程度の投資は行われるものの実際のビジネス変革には繋がっていないというのが多くの企業の現状である。
同じレポートは、経営者からビジネスをどう変えるかの明確な指示が示されないまま「AI を使って何かできないか」という指示が出され、PoC が繰り返されるものの事業の改革につながらないケースも多い、との指摘を紹介しています。参考資料の「DX 推進システムガイドライン」の構成案には、失敗ケースとして「戦略なき技術起点の PoC は疲弊と失敗のもと」が挙がっています。
本番に進まない理由は、次の 4 つに整理できます。
- 「AI を使って何かできないか」から始まり、解決したい業務の課題が決まっていないため、検証が終わっても何が分かれば成功だったのかを誰も言えません。
- 合格ラインと中止ラインを決めずに始め、結果を見てから評価を議論するため、関係者ごとに「良さそう」「不安」と受け止め方が割れて判定できません。
- 業務全体を一度に対象にして範囲が広すぎるため、どこが使えてどこが使えないのかを切り分けられず、使える部分まで「全体としてだめ」と判断されます。
- 本番化の予算・運用の担当・本番の環境を決めずに始めるため、検証で良い結果が出ても、本開発を引き受ける予算と人がいません。
4 つとも、技術力ではなく始める前の決め方で防ぎやすくなります。次の章で、決めることを順に並べます。
FIXITPoC って、とりあえず作ってみることじゃないの？
Tsukasa結論から言うと、作る前に、止める条件まで決めてから試すのが PoC です。
FIXITえっ、成功させたいのに、止める条件から決めるの？
Tsukasa中止ラインが無いと、合格に届かないときに誰も PoC を止められません。延長が続くだけです。
PoC の進め方 6 ステップ
PoC の検証は、次の 6 ステップで進めます。1〜3 は始める前に決めることで、ここを飛ばすと、前章の 4 つの理由のどれかで PoC が本番に進まなくなります。
1. 目的と仮説を書く
最初に、PoC で何を確かめたいかを 1 文の仮説にします。「AI で問い合わせ対応を改善する」では広すぎます。「問い合わせのうち件数の多い種類について、AI の下書きを担当者が手直しなしで送れる割合が、目標の水準に届くか」のように、対象・測るもの・判定の向きが読み取れる形にします。
経済産業省の AI 契約ガイドラインも、検証の前段階で重要なのは「AI 導入により何を解決したいのか」という課題の設定であり、KPI (達成度を測る指標) を設定できる場合はそれを明確にすることだと書いています。課題と KPI の設定は事業内容に依存するため、発注者が責任を持ち、開発側が支援する役割分担が実情に合うとしています。目的と仮説は、ベンダーに任せず発注者が書くものです。
2. 範囲と期間を区切る
次に、検証の対象を絞り、期間を決めます。対象は、件数が多く正解を判定しやすい業務から選ぶと、短い期間で結論を出しやすくなります。あわせて「今回は確かめないこと」も書きます。全社展開・他部署への横展開・24 時間の運用などを対象外と明記しておくと、検証中に要件が膨らむのを防ぎやすくなります。
期間は先に区切ります。経済産業省の AI 契約ガイドラインも、PoC 段階では様々な業務が対象になりうるため、対象範囲と対象期間を合意しておくことが重要だとしています。
3. 判定基準 (合格ライン・中止ライン) を先に決める
始める前に、合格ラインと中止ラインを数字か判定条件で書きます。ここがこの記事でいちばん伝えたいステップで、書き方は次の章で詳しく説明します。結果を見てから基準を決めると、手元の結果に基準を寄せてしまい、関係者が判定に納得できません。
4. データと検証環境を用意する
検証に使うデータは、きれいに整えたサンプルではなく、現場で実際に発生している入力から集めます。表記の揺れ、欠けている項目、想定外の言い回しなど、本番で必ず出てくる入力を含めないと、本番で使い始めた途端に、正しく処理できる割合が下がりやすくなります。個人情報や機密情報を含む場合は、マスキングの方法と、ベンダーに渡す範囲をこの段階で決めます。
5. 検証し、結果と条件を記録する
検証では、結果の数字だけでなく、どのデータで、どの設定で、何回試したかを記録します。条件が残っていないと、本開発で同じ結果を再現できるかを確かめられません。うまくいかなかったケースも捨てずに残します。失敗したケースの記録が、本開発で手当てする箇所の一覧になります。
6. 判定し、次の段階を決める
期間の終わりに、3 で決めた基準で判定します。判定の結果は「進む」「条件付きで進む」「止める」のどれかにし、追加検証は条件付きで進む場合の 1 つの選択肢として扱います。進む場合は、本番への移行条件・データを管理する担当・障害時の対応を決め、セキュリティの確認をいつまでに終えるかも決めて、次の段階の計画に渡します。
計画書に書く項目
PoC の計画を社内で通すときは、1〜6 で決めたことを 1 枚の計画書にまとめます。経営層の承認を得るときも、ベンダーに依頼するときも、この 1 枚が共通の前提になります。
| 項目 | 書くこと |
|---|---|
| 目的 | 解決したい業務の課題と、PoC の結果で何を決めるか |
| 仮説 | 対象・測るもの・判定の向きが分かる 1 文 |
| 範囲 | 対象の業務とデータ。あわせて「今回は確かめないこと」 |
| 期間 | 開始日と判定日。延長する場合の条件 |
| 判定基準 | 観点ごとの合格ライン・中止ライン・測り方 |
| 体制 | 判定する人、現場で評価する人、本番で運用する予定の人 |
| データ | 使うデータの出どころ・件数・マスキングの方法 |
| 費用と契約 | 検証の費用、契約の形、成果物とその権利 |
| 次の段階 | 進む場合の本開発の範囲・予算の見込み・承認の手順 |
本番で運用する予定の人を体制に入れておくのは、前章の「本番を想定していない」を防ぐためです。運用する人が検証の段階から関わっていれば、良い結果が出たときに本番の準備へすぐ移れます。
失敗しない判定基準の作り方
3 観点で、合格ラインと中止ラインを書く
判定基準は、「PoC で確かめる 3 つのこと」の観点ごとに、合格ラインと中止ラインを書きます。合格ラインだけでは、届かなかったときに「もう少し続ければ届くかもしれない」と延長が続きます。中止ラインを合格ラインと同じ重みで書くと、期限どおりに PoC を終わらせやすくなります。
| 観点 | 測るもの | 合格ラインの書き方 | 中止ラインの書き方 |
|---|---|---|---|
| 技術 | 評価データに対する出力の正しさ・処理時間 | 「評価データ N 件のうち、基準を満たす割合が ◯% 以上」 | 「改善を ◯ 回行っても ◯% に届かなければ中止」 |
| 業務での効果 | 作業時間・手直しの有無・担当者が使い続けるか | 「対象業務の作業時間が現状から ◯ 割減る」 | 「担当者が使い続けたくないと判断した場合は中止」 |
| 費用 | 本番の規模での利用料・運用の人手 | 「本番の処理量で、月の費用が削減できる工数を下回る」 | 「本番の処理量で費用が効果を上回る見込みなら中止」 |
◯ の数字は業務ごとに違うため、ここでは書き方の型だけを示します。数字は、現状の作業時間や誤りの許容度を現場の担当者と確かめて決めてください。誤った案内が大きな損害につながる業務では、正しさの割合より「危ないケースを人に回せるか」を合格ラインにするなど、業務のリスクに合わせて測るものを変えます。
判定は 3 つのどれかにする
| 判定 | 条件 | 次にやること |
|---|---|---|
| 進む | すべての観点で合格ラインを満たした | 本開発の計画と見積もりに進む |
| 条件付きで進む | 一部の観点が合格ラインに届かないが、中止ラインには触れず、原因が特定できている | 判定基準と期間を置き直し、原因に絞って追加検証する |
| 止める | どれかの観点で中止ラインに触れた | 結果と原因をレポートに残し、別の手段や課題に移る |
PoC が複数回になること自体は珍しくありません (前述の AI 契約ガイドラインも、1 回で完結せず複数回実施されることも少なくないとしています)。「条件付きで進む」で追加検証をするときは、そのつど判定基準と期間を置き直し、原因に絞って行います。範囲を広げたり期間を区切らなかったりすると、PoC を繰り返すだけの状態に戻ります。
1 回の結果だけで判定しない
特に生成 AI のように、同じ入力でも出力が揺れる技術では、1 回だけ合格ラインに届いた結果で判定しないでください。評価データを入れ替えたり、同じデータで何度か試したりして、結果のぶれ幅も含めて合格ラインを満たすかを見ます。この点は後半の AI エージェントの章で詳しく書きます。
PoC 開発の期間と費用の考え方
期間と費用を決める要素
PoC 開発の期間と費用は、主に次の要素で決まります。
- 使えるデータがそろっているか。データの収集や整形から始める場合は、その分の期間と費用が加わります
- 検証の範囲。対象の業務やデータの種類が増えるほど、評価の手間が増えます
- 評価の仕組みをどこまで作るか。手作業で確かめるのか、評価を自動で繰り返せる仕組みまで作るのかで、期間と費用が変わります
- 検証の環境。開発側の環境で試すのか、本番に近い環境や実環境で試すのかで、期間と費用が変わります
- 外部システムとの連携。既存のシステムからデータを取り込む、結果を戻すといった連携が増えるほど、期間と費用が増えます
経済産業省の AI 契約ガイドラインも、PoC は試行錯誤を避けられず、1 回で完結せず複数回行われることも少なくないと書いています。費用を見積もるときは、1 回で結論が出なかった場合にどうするかを先に決めておくと、予算が膨らみにくくなります。
期間を先に区切る
PoC の期間は、終わってから振り返るものではなく、始める前に区切るものです。期間を決めたら、その期間で判定できる範囲まで対象を絞ります。期間が足りないと分かったら、延長する前に、範囲が広すぎないか、判定基準が測れる形になっているかを見直します。延長は、判定基準を見直したうえで行う例外として扱います。
費用の相場は、見積もりの記事で確認する
AI 開発の PoC にかかる費用の相場と内訳は、データ準備・PoC・本開発・運用の 4 段階に分けて AI・機械学習開発の見積相場 で解説しています。見積もりを比べるときは、総額ではなく、データの準備・評価の仕組み・検証作業の工数がそれぞれいくらかを見てください。
PoC の契約で決めておくこと
ベンダーに PoC を頼む場合は、契約で次のことを決めておきます。経済産業省の AI 契約ガイドラインは AI の学習済みモデルを作る開発を対象にした資料ですが、段階ごとに契約を分けて決めるという考え方は、他の PoC にも参考になります。
| 決めること | ガイドラインの考え方 | 発注者が確かめること |
|---|---|---|
| 契約の形 | AI の学習済みモデルの生成は、どの段階でも準委任型の契約がなじむ。PoC の導入検証契約のモデル契約も準委任型 | 完成を約束する請負ではなく、完成義務を負わない準委任か |
| 成果物 | 検証の結果はレポートにまとめるのが一般的。場合によってはパイロット版の学習済みモデル | レポートに何を書くか (結果・条件・失敗したケース・次の提案) |
| 範囲と期間 | PoC 段階は対象範囲と対象期間を合意しておくことが重要 | 計画書の範囲・期間と契約の記載が一致しているか |
| データと成果物の権利 | 提供するデータや成果物の権利・利用条件を、段階ごとにあらかじめ検討しておくことが望ましい | 渡したデータの扱い、作った仕組みを本開発で使えるか |
| 次の段階 | PoC がうまくいった場合に開発段階へ移る認識を確かめる趣旨で、開発契約の締結の努力義務を定めることもある | 進む場合の契約の切り替え方と、ベンダーを替える自由 |
PoC を準委任で契約すると、ベンダーは完成の義務を負わず、検証の作業を適切に行う責任を負います。だからこそ、判定基準とレポートの中身を発注者側で決めておく必要があります。準委任と請負の違いと選び方は AI 開発の契約は準委任と請負どちらが正解か で詳しく扱っています。
秘密保持契約 (NDA) は PoC の契約より前に結びます。未公開の業務データや企画を渡すことになるためです。
AI エージェントの PoC で追加して確かめること
ここまでの進め方と判定基準は、AI エージェントや生成 AI の PoC にもそのまま使えます。そのうえで、AI エージェントでは次の 5 点も確かめます。
出力の揺れを前提に、評価データで測る
生成 AI の出力は、同じ入力でも揺れます。一度うまく答えたデモを見ても、同じ品質が安定して出るとは限りません。そこで、代表的な入力と期待する振る舞いを評価データとして固定し、出力を自動で採点して合格の割合を出す仕組み (評価ハーネス) を作ります。正誤やツールの呼び出しのように機械的に判定できる部分はルールで採点し、自然さのように判断が入る部分は判定用の LLM に採点させます。評価ハーネスがあれば、プロンプトやモデルを変えるたびに同じ基準で再評価でき、ある入力への回答を直したら、別の入力への回答の品質が下がったという回帰にも気づけます。作り方は LLM アプリの評価ハーネス構築 で解説しています。
検索と生成を分けて測る
社内文書を検索して答える仕組み (RAG) では、必要な文書を拾えているか (検索) と、拾った文書に基づいて正しく答えているか (生成) を分けて測ります。分けて測らないと、回答が間違っていたときに、どちらを直せばよいかが分かりません。あわせて、検索した文書に書かれていないことを答えていないかも評価項目に入れます。構築の手順は RAG 構築の実践ガイド で扱っています。
最終の回答だけでなく、途中の判断を測る
ツールを使うエージェントは、正しいツールを選んだか、引数を正しく渡したか、ツールの結果を踏まえて次の手を選べたかを、ステップごとに確かめます。最終の回答だけを見ていると、たまたま正解にたどり着いただけで途中の判断がおかしいエージェントを見逃します。
コストと応答時間を同じ評価で測る
1 件あたり何回モデルを呼び、いくらかかり、何秒で返るかを、正しさと同じ評価の仕組みで測ります。判定基準の費用の観点で使う数字は、ここで測った値に本番の処理量を掛けて試算します。
本番に持ち込むガードレールとログを PoC から入れる
外部への送信・課金・データの更新や削除など、影響の大きい操作の前に人の承認を挟む仕組み (ガードレール) と、各ステップの入力・出力・判断理由を残すログは、PoC の段階から入れておきます。後から足すと作り直しになりやすく、PoC で入れておけば、本番への移行で作り直す範囲を小さくできます。
顧客からの問い合わせの一次対応を AI エージェントで設計した事例は、顧客対応オペレーションの自動化事例 で紹介しています。
FIXITデモで賢く答えたら、その PoC は合格でいいの？
Tsukasaまだ合格とは言えません。一度うまく答えても、同じ品質が続くとは限りません。
FIXITじゃあ、何を見れば合格って言えるの？
Tsukasa判断の軸は、評価データで合格ラインを超え続けるかどうかです。
FIXIT の運用 — AI エージェントの PoC と、その手前の業務 DX
AI 駆動開発のクリエイティブスタジオである FIXIT の AI エージェント開発 では、業務ログの分析から入り、自動化できる業務・半分だけ自動化する業務・人が担う業務に切り分けてから設計を始めます。評価ハーネスはセットで納品し、モデルを変えたときにも同じ基準で品質を比べられる資産として残します。特定のモデルに依存しない構成を採っているため、新しいモデルが出たときも同じ評価で比べられます。費用の目安は PoC 規模で 300 万〜600 万円 (税抜) です。ナレッジの整備状況によっては、PoC だけなら 3 週間で終えることもできます。本格運用まで進む場合の費用と期間を含め、詳しくはサービスのページをご覧ください。
AI の PoC より手前の段階にいる会社もあります。連絡が社員それぞれの個人 LINE に、ファイルが個人の PC に散らばっていると、PoC に使う業務のデータを集めること自体が難しくなります。その場合は、連絡を Slack へ、メールとファイルを Google Workspace へ移し、生成 AI を日常業務で使えるようにするところから始めるほうが近道です。この支援は 業務 DX 伴走支援 として提供しており、連絡の基盤から小さく始めて、効果を確かめながら広げる進め方もできます。
まとめ
PoC (Proof of Concept・概念実証) は、本開発に進むか止めるかを決める材料を、小さな範囲と区切った期間で集める検証です。経済産業省の DX レポートが指摘するとおり、PoC を繰り返しても事業の変革につながらない企業は少なくありません。本記事で整理したとおり、本番に進まない PoC の多くは、目的・判定基準・範囲・本番の予算と担当を決めずに始まっています。始める前に、技術・業務・費用の 3 観点で合格ラインと中止ラインを書き、期間を区切り、契約で範囲と成果物を決めておけば、終わった時点で「進む」「条件付きで進む」「止める」を言い切れます。
次の一歩は、本記事の「計画書に書く項目」の表を使って、検討中の PoC を 1 枚に書いてみることです。目的と判定基準の欄が埋まらない場合は、まだ PoC を始める段階ではありません。AI エージェントの PoC を検討している場合は AI エージェント開発 を、どの業務を対象にするかの整理を相談したい場合は お問い合わせ からご連絡ください。計画書の書き方から、判定基準の決め方まで一緒に検討します。