PoC報告書の書き方｜経営判断につなぐ6ブロックと記入例

結論｜PoC報告書は6ブロックで次の意思決定まで書く

PoC報告書の読み手が最初に知りたいのは、活動回数ではありません。何を確かめるPoCで、どの基準に対してどの事実が得られ、担当者は何を推奨し、会議で何を決めてほしいのかです。

6ブロックを順につなげると、報告書は活動記録から意思決定の道具へ変わります。 詳細なデータや実施経緯は補足資料へ分け、本文では判断へ必要な情報を短い経路で示します。

6ブロックは、さらに「証拠」「決定」「引き継ぎ」の三つの役割へ分けられます。具体的には、問いから解釈までは証拠、判断は決定、次の計画は引き継ぎです。

そのため、文章が整っていても、どれかが欠けると、追加投資の判断や引き継ぎが進まなくなるおそれがあります。

PoC自体の目的や進め方を先に整理したい場合は、PoCとは何かを確認してください。PoC報告書では、そこで設定した仮説と判断基準を変えずに受け取り、結果と照合します。

推奨と決定を同じものにしない

報告者が書くのは「推奨」であり、会議で権限者が選んだものが「決定」です。そのため、両者が異なる場合も、報告書を書き換えて同じに見せず、推奨、決定、差が生じた理由を残します。

会議前の版には推奨判断を置き、会議後に決定ログを追加します。後から結果だけを見て当時の判断を評価するのではなく、その時点で使えた証拠、制約、判断理由をたどれる状態にするためです。

6ブロックの間で主語もそろえます。具体的には、問いでは顧客、利用者、設備などの対象を示し、事実では同じ対象について観察した内容を書きます。

たとえば、問いが顧客の利用行動なのに、事実が技術性能だけで終われば、技術検証はできても顧客仮説には答えていません。また、複数の問いがある場合は、主判断と補助判断を分け、どちらの証拠か分かる見出しを付けます。

技術の結果を、次の投資判断につなぐために必要な情報

技術検証が終わっても、追加の予算と人員を誰が承認するかは別に決める必要があります。大企業の新規事業関与者888名への調査では、PoC・検証から事業化・拡大へ移る際の最大の障壁として、経営層の後ろ盾不足を174名、判断基準の曖昧さを168名、投資承認を得られないことを99名が選びました。

この3項目を意思決定に関わる障壁としてまとめると、441名、49.7%です。報告書の形式を評価した調査ではありませんが、技術の結果だけでなく、その結果を受けて誰が何を決めるかまで整理する理由になります。

出典：イノベーション総合研究所「新規事業の実態と意思決定に関する調査」（2026年4月、n=888、調査実施：株式会社マクロミル）

PoC報告書の冒頭には、結果と、今回求める判断を一組で書きます。

例えば外観検査AIを試す場合、「検証環境で精度を確認した」は試験結果です。しかし次へ進むためには、本番の照明条件でも確認できるか、品質保証部がどの条件で受け入れるか、追加検証に誰が予算を出すかを明示します。

そのうえで、これらを、確認済み・追加確認・判断待ちに分けてください。

事業化へ渡す体制・初期顧客・判断条件の全体像は、PoCから事業化へ進めるための設計にまとめています。本記事では、その判断を承認者へ渡せる報告書の書き方に絞って解説します。

PoC報告書の書き方は提出前ではなく検証前から決まる

報告書を仕上げるのはPoCの後ですが、良い報告書の骨格は検証前に決まります。問い、成功・中止・追加検証の条件、証拠の取得方法、判断者を先に決めなければ、結果を何と照らすかが分からないからです。

書き始める前に、報告会で誰が何を決めるのかを一文にしてください。 「PoC結果を共有する」ではなく、「顧客検証へ進むための追加予算を承認する」「この用途への投資を終了する」のように、判断の対象まで書きます。

基準を結果の後に作ると、期待に合う数値だけを重く扱う余地が生まれます。途中で市場条件や実施条件が変わり、基準を変更する必要が生じた場合は、旧基準を消さず、変更理由、変更者、変更日、新しい基準を併記します。

公的な評価の考え方も参考になります。NEDOの研究評価・事業評価では、成果だけでなく、アウトカムまでの道筋、目標と達成状況、マネジメントを評価し、加速・縮小・中止・見直しなどへ結果を反映しています。

これは企業内PoCの様式そのものではありませんが、結果と次の資源配分を接続する視点は共通します。

PoCの前段で判断基準を設計する方法は、新規事業の撤退基準も参照してください。撤退基準は失敗を責める条件ではなく、追加投資の停止や仮説の切り替えを早く決める条件です。

判断者が報告会へ参加できない場合も、代理出席だけで済ませず、承認できる範囲と持ち帰る条件を決めます。というのも、判断者不在のまま共有会を開くと、追加質問のたびに資料を作り直し、基準の追加と検証の延長が起きやすくなるからです。

そのため、会議日、出席者、決裁範囲、未決時の回答期限をPoC計画と報告書の表紙へ記載してください。

PoC報告書の6ブロックとコピーできる記入例

6ブロックは、見出しの順番をそろえるだけでは足りません。前の欄に書いた内容が次の欄の根拠になり、問いから次の計画まで一本の線でつながっている必要があります。

空欄を曖昧な言葉で埋めず、未確認なら「何を・誰が・いつ確かめるか」を書きます。 次の表は、そのまま社内様式へ移せる最小テンプレートです。

まず6行を一続きで埋め、前後の欄が論理的につながるか確認してください。接続しない欄は文章で補わず、問い、基準、証拠のどこを直すか決めます。

問いは一文で、判断に必要な変化を書く

「サービスの有効性を確認する」では広すぎます。代わりに、「対象業務の担当者が、試作品を使って処理時間を短縮できるか」のように、対象、条件、観察する変化を一文にします。

また、顧客価値と技術成立性を同時に確かめたい場合は、問いを分け、どちらが今回の主判断かを決めます。

事前基準はGoだけでなくKillと追加検証も書く

Goだけを決めると、条件を満たさなかったときに「もう少し続ける」が選ばれやすくなります。そこで、終了する条件と、未達・評価不能・条件変更の際に追加で確かめる条件を同じ欄へ置きます。

ただし、未達だから必ず中止、評価できたから再検証は不要、と機械的には決めません。そして、追加検証を提案する場合は、どの不確実性を解くか、方法、費用上限、終了条件を明らかにします。

事実は評価語を使わず、観察できた内容を書く

「反応は良好だった」「一定のニーズがあった」では、読み手が同じ判断を再現できません。そのため、誰がどの状況で何をしたか、ログに何が記録されたか、提示した価格に対してどの行動を選んだかを記載します。

なお、面談数やテスト件数は検証範囲の説明であり、仮説が確かめられた証拠とは分けます。

解釈は言える範囲と代替説明を書く

事実から言えることだけでなく、言えないことも書きます。たとえば利用されなかった場合、「価値がない」だけでなく、操作条件、対象者、導入説明、既存手順の制約という別の説明があり得ます。

どの説明を次に確かめるかを決めると、都合のよい結論へ飛ぶのを防げます。

判断と次の計画で会議後の行動を固定する

判断欄ではGo・Kill・追加検証のどれを推奨するか、どの基準と証拠を重く見たかを書きます。そして次の計画では、担当、必要資源、期限、協力部門、次回判断日を置きます。

逆に、「関係部署と調整する」「引き続き検討する」だけでは、誰も着手できません。

6ブロックを完成させたら、各欄を一文ずつ読み上げて接続を確認します。「この問いだから、この基準を使った」「この事実だから、この解釈になった」「この解釈と基準だから、この判断を勧める」「この判断だから、この担当と資源が必要になる」と説明できることが目安です。

もし途中で期待や既定方針だけが理由になるなら、証拠か決定理由が不足しています。

完成記入例｜正解率99%でも、そのままGoにしない

工場の外観検査AIについて、実ラインでの限定試験へ進むかを報告する架空例です。なお、以下の件数・基準・費用・期間は説明用の仮定で、安全基準や業界標準ではありません。

全体の正解率が高くても、見逃したくない不良品を半分見逃していれば、同じ「良い結果」とは扱えません。

ここでは、人が正解を確認した試験画像1,000件の内訳を、良品980件、不良品20件とします。

AIは良品980件をすべて正しく判定した一方、不良品は10件を検出し、残り10件を良品と誤判定したとします。この場合、全体の正解率は990件÷1,000件＝99%ですが、不良品の検出割合は10件÷20件＝50%です。

指標の定義はGoogleの機械学習教材「Accuracy, recall, precision, and related metrics」を参照。この教材では、正解率と、実際の不良品を分母にする再現率を区別しています。

なお、数値と外観検査の設定は、本記事の架空例です。

不良品は20件しかないため、1件の違いで検出割合が5ポイント変わります。そのため、この例の90%を満たすだけで商用化を承認せず、不良の種類、試験数、実際の照明・速度・対象製品を踏まえて評価条件を決めます。

そして報告書には、今回のデータで分かることと、本番でまだ確かめていないことの両方を残します。

会議後は、表の推奨欄を決定済みの表現へ上書きせず、承認者・決定日・承認額・条件を追記します。例えば40万円の提案に対して20万円の原因分析だけが承認されたなら、再試験まで承認されたとは扱いません。

予算の範囲が変われば、次の作業と判断日も合わせて更新します。

1枚目は「問い・判断・次の行動」に絞る

報告書の冒頭1枚は、全体の縮小版ではありません。判断者が最初に知るべき「今回の問い」「推奨判断」「会議で承認してほしいこと」を先に置き、判断へ直接関係する証拠だけを添えます。

1枚目を読んだ人が、何を決める会議か説明できれば合格です。 長い背景、全グラフ、すべての発言、技術仕様は後ろへ分け、冒頭から証拠IDや見出しでたどれるようにします。

基準が複数ある場合は、達成、未達、評価不能を分けます。ただし、評価不能は未達と同じではありません。

そこで、取得条件の不備で評価できなかったのか、必要なデータが不足したのかを示し、追加検証の対象を限定します。

推奨判断の横には、承認してほしい内容を具体的に置きます。たとえば、Goなら次段階の範囲・予算・体制、Killなら終了する仮説・契約・残す知見、追加検証なら新しい問い・費用上限・期限です。

こうすれば、判断者が賛否だけでなく、何を承認するのか確認できるようにします。

会議後に決定ログを追加する

会議前の報告書は提案です。そして会議後に、決定日、決定者、選択した判断、採用理由、条件、次回確認日を追加して、初めて意思決定の履歴になります。

また、推奨と異なる決定なら、その差と理由も記録します。

保留を選ぶ場合も、足りない情報、取得担当、期限、期限までに取得できない場合の扱いを決めます。無期限の保留は、実質的に追加投資を続けながら判断を先送りする状態です。

1枚目には更新日時と版番号も置きます。というのも、報告会の直前に数値や判断案が変わった場合、参加者が異なる版を見ていると議論の前提が崩れるからです。

そのため、変更した箇所、変更理由、確認者を短く残し、会議で使う版を固定します。そして会議後は、同じ版へ決定ログを追記するか、決定反映版として番号を更新し、配布先をそろえてください。

事実と解釈を分け、証拠をたどれるようにする

PoC報告書の数値や発言には、取得条件と元記録をたどれる証拠IDを付けます。本文には判断に必要な要約を載せ、詳細なログ、観察記録、集計元は証拠台帳や補足資料に分けます。

証拠台帳は資料を増やすためではなく、同じデータを別の担当者が再解釈する手戻りを減らすために使います。 PoC終了後に事業化担当へ引き継ぐ場合も、何をどの条件で確かめたかを再確認できます。

顧客発言を引用するなら、肯定的な一文だけでなく、質問、対象者の役割、前後の文脈を元記録へ残します。本文には判断へ必要な要約を置き、「顧客に好評」ではなく、「提示した価格と条件に対して、次回の社内審査へ進むことを選んだ」のように行動を記載します。

技術検証でも、試験環境で動いたことと、本番環境で運用できることを分けます。そのため、性能、品質、安全、情報管理、運用負荷、保守、既存システムとの接続など、未確認条件を明記してください。

IPAが公開する製造プラットフォーム間連携のPoCも、位置づけ、システム構成、懸念、対策、確認した効果を分けて記録しています。ただし、個社の様式をそのまま転用するのではなく、条件と効果の対応を残す例として参考になります。

個人情報や機密情報は、報告書本文へ必要以上に複製しません。証拠台帳の閲覧権限、保存先、保管期限、削除責任を定め、本文から権限に応じて参照できるようにします。

集計値を載せる場合は、母数、対象条件、欠損の扱い、比較期間をグラフの近くへ記載します。ただし、社内の集計作業の詳細を本文へ並べる必要はありません。

判断が変わり得る条件だけを示し、再計算に必要な定義は補足資料へ分けます。割合だけを大きく見せず、該当数と対象の範囲も確認できるようにしてください。

Go・Kill・追加検証でPoC報告書を書き分ける

PoC報告書は、どの判断でも同じ分量にする必要はありません。Goでは次段階の未確認条件、Killでは終了範囲と残す資産、追加検証では新しい問いと終了条件を厚く書きます。

重要なのは、どの判断でも次の担当・資源・期限・判断日を空欄にしないことです。 「成功」「失敗」という評価だけで終えると、事業化、終了処理、再検証のいずれも開始できません。

表の左列で判断を一つ選び、中央列を本文、右列を会議の承認依頼へ反映します。複数の判断を並記する場合は、対象となる仮説や用途を分けてください。

検証結果を事業化の実行計画へ移す段階で、社内の役割分担や判断日まで含めた伴走が必要な場合は、新規事業の実行・事業化支援 Launchで、PoC後の移行計画と意思決定の設計を支援しています。

Goは商用化の完了ではない

PoCで成立したのは、設定した条件の範囲です。つまり、本番環境、対象顧客の拡大、量産、販売、運用、採算まで自動的に成立したわけではありません。

そのため、Goを推奨する場合は、確かめた条件と未確認条件を分け、次段階で解消するリスクを示します。

PoCから事業化へ移る際の体制や判断点は、PoCから事業化へ進む方法で詳しく整理しています。報告書の次の計画を、この移行設計へ接続してください。

Killは活動の否定ではなく仮説への投資停止

期待と異なる結果でも、事前基準に照らして終了を判断できればPoCの役割を果たしています。その際は、どの仮説・用途・顧客条件を終了するか、どの技術・顧客知見・データ・契約を残すかを書きます。

また、担当者の人事評価と案件の判断を混ぜないことも重要です。

追加検証は同じPoCの延長にしない

追加検証には、次に確かめる問い、対象、方法、基準、費用上限、期間、判断日を置きます。また、同じ問いを再検証する場合も、前回と変える条件や追加する観測を明記します。

つまり、「データが足りないため継続」ではなく、何が分かればGoかKillを決められるかを明記します。追加予算の承認方法は、新規事業の予算・稟議と接続すると、判断までの範囲を切り分けやすくなります。

PoC報告書で避けたい4つのNGパターン

読みにくいPoC報告書は、文章表現より構造に問題があります。活動量だけを報告する、データを並べる、結論を先送りする、都合のよい結果だけを示す、という四つを先に点検してください。

NGパターンは、情報を足すより「どの判断に使う情報か」を決めると直せます。 表の右列を修正指示として使い、各段落を問い・基準・判断へ戻します。

活動報告型では、「面談を20件実施した」だけでなく、その活動からどの顧客行動が確認され、事前基準にどう影響したかを書きます。面談件数は検証範囲を示す補足であり、仮説成立の結論ではありません。

データ羅列型では、読む人がグラフから独自に結論を作る状態になっています。そこで、主な事実を問いごとに選び、「この事実から言えること」「言えないこと」「別の説明」を添えます。

そして、元データは補足へ残し、証拠IDで参照します。

結論先送り型では、追加検証を選ぶとしても、何を、誰が、いつまでに確かめ、何が分かったら終えるかを決めます。成功偽装型では、期待に合わない証拠を消さず、次の投資で表面化するリスクとして示します。

提出前チェックリスト｜1枚で判断できるか確認する

提出前の確認は、誤字や体裁だけでは不十分です。PoCに関わっていない人が1枚目を読み、今回の問い、推奨判断、根拠、会議で決めることを説明できるか確認します。

チェックで不足が見つかったら、文章を増やす前に6ブロックの接続を直してください。 問いと基準がずれていれば事実を増やしても判断できず、判断と次の計画が切れていれば会議後に動けません。

通常の箇条書きでも確認できます。

• すべての主要な数値と発言に、取得条件か証拠IDがある
• グラフのタイトルが、指標名だけでなく何を比較しているかを示している
• 報告者の推奨と、会議後の決定が別に記録されている
• 本文から補足資料の元データへたどれる
• 個人情報・機密情報の閲覧権限と保管先が決まっている
• 次段階で未確認の条件が、成功条件のように書かれていない

チェックは報告者だけで行わず、PoCの設計に関わっていない人、次に引き継ぐ部門、判断権限者のいずれかに読んでもらいます。説明を聞かずに要点を把握できない箇所が、報告書で補うべき箇所です。

会議後は決定ログを反映し、版番号と更新日を付けます。また、推奨と異なる判断になった場合は、決定者、理由、新しい条件を残します。

こうした履歴が、次のPoCで同じ論点を繰り返さないための組織知になります。

報告書を保管する場所も提出前に決めます。というのも、案件名だけで保存すると、終了後に検索できても、どの問いを検証した資料か分からないからです。

そのため、テーマ、顧客課題、検証した仮説、判断日、最終判断を検索項目として持たせ、証拠台帳と決定ログを同じ単位で関連付けます。そして後続案件が再利用するときは、結論だけでなく成立条件と適用限界まで確認します。

PoC報告書の書き方に関するよくある質問

PoC報告書の枚数、失敗結果の扱い、口頭報告との使い分けなど、実務で迷いやすい点を整理します。

Q. PoC報告書は何枚にまとめるべきですか

A. 一律の枚数では決めません。冒頭1枚に問い、事前基準、主な事実、推奨判断、承認事項、次の担当をまとめ、詳細なログやグラフは補足へ分けます。判断者が必要な根拠へ証拠IDや見出しでたどれる構成にしてください。

Q. 失敗したPoCはどのように報告しますか

A. 期待と異なる結果でも、事前基準に照らしてKillや修正を判断できれば価値があります。確認した事実、否定された仮説、止められる投資、残す知見を記載し、成功したように見せるために評価軸を変えないことが重要です。

Q. PoC報告書と口頭報告はどう使い分けますか

A. 報告書は事実、基準、推奨、決定の履歴を残すために使い、口頭説明は論点確認と意思決定に使います。口頭で補足する前提でも、推奨判断と次の計画は文書に残し、会議後に実際の決定を追記します。

Q. 追加検証を提案するときは何を書けばよいですか

A. 未達・評価不能・条件変更の理由、次に確かめる問い、対象、方法、Go・Killの基準、費用上限、担当、期限、判断日を書きます。元のPoCをそのまま延長せず、判断できる最小単位へ切り分けてください。

Q. PoC報告書の作成責任者は誰ですか

A. 報告書の編集責任者は一人に決めますが、全欄を一人で確定しません。事実は検証実施者、解釈は仮説責任者、推奨は事業責任者、決定は権限者、次の計画は引き継ぎ先と確認します。各欄の確認者を明記すると責任の混同を防げます。

本記事のまとめ｜PoC報告書は判断と引き継ぎを残す

PoC報告書は、問い、事前基準、事実、解釈、判断、次の計画の6ブロックで構成します。活動量やデータの多さではなく、結果を見る前の基準に照らして何を推奨し、会議で何を決めてほしいかを中心に書きます。

最初の一歩は、報告書の1枚目に「問い・推奨判断・承認事項・次の担当」を並べることです。 その後ろに、判断へ直接関係する事実、証拠ID、言える範囲、反証、未確認条件を置いてください。

Goでは次段階のリスクと移行条件、Killでは終了範囲と残す資産、追加検証では新しい問いと終了基準を厚くします。どの判断でも、担当、必要資源、期限、次回判断日まで決めます。

提出前には、PoCに関わっていない人が冒頭1枚だけで会議の目的を説明できるか確認します。会議後は推奨を上書きせず、実際の決定、決定者、理由、条件を決定ログへ追記してください。

こうして報告書を完成資料ではなく、次の投資と実行を動かす判断履歴として残します。