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

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

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

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

6ブロックは、さらに「証拠」「決定」「引き継ぎ」の三つの役割へ分けられます。問いから解釈までは証拠、判断は決定、次の計画は引き継ぎです。文章が整っていても、このどれかが欠ければ、PoC後の投資や事業化は止まります。

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

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

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

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

6ブロックの間で主語もそろえます。問いでは顧客、利用者、設備などの対象を示し、事実では同じ対象について観察した内容を書きます。問いが顧客の利用行動なのに、事実が技術性能だけで終われば、技術検証はできても顧客仮説には答えていません。複数の問いがある場合は、主判断と補助判断を分け、どちらの証拠か分かる見出しを付けます。

888名調査では、PoC結果だけで稟議を動かすのは難しい

イノベーション総研が大企業の新規事業関係者888名へ行った調査では、直近の新規事業で到達した最も進んだ段階は「PoC・顧客ヒアリング」が24.7%で、8段階の中で最も多い結果でした。この到達段階の割合だけでは、PoC後の判断に時間がかかる原因までは分かりません。結果を次の事業判断へつなぐ条件は、案件ごとに確認する必要があります。

48.5%

ROI・費用対効果の試算

36.0%

他社導入事例・実績

24.2%

経営課題・中期経営計画との整合性

22.2%

無料トライアル・お試し利用の結果

出典：イノベーション総研「新規事業の実態と意思決定に関する調査」（2026年4月、n=888、複数回答・最大3つ）

この図は、外部支援サービスの導入承認で重視する材料の回答割合です。PoC結果の重要度や、実際に稟議が通った確率を測ったものではありません。イノベーション総研は、PoC結果を単独で示すだけでは、投資額と事業戦略を判断する材料として不足しやすいと捉えています。PoC報告書には、結果に加えて、次段階の費用と効果の前提、中期経営計画のどの目標へ寄与するか、既存の選択肢と比べて何が変わるかを示す必要があります。

この補足が必要なのは、PoC後に追加予算、開発体制、顧客展開などの承認を求める場合です。技術的な成立だけを確認する社内実験であれば、無理にROIを確定させず、未確認の前提と次に確かめる条件を明記します。

次の会議までに、1枚目へ「今回のPoC結果」「次段階の投資額と効果の前提」「中期経営計画との接点」の3行を追加してください。 数値を置けない項目は、推測で埋めず、未確認事項と確認担当を記します。

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

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

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

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

公的な評価の考え方も参考になります。NEDOの研究評価・事業評価では、成果だけでなく、アウトカムまでの道筋、目標と達成状況、マネジメントを評価し、加速・縮小・中止・見直しなどへ結果を反映しています。企業内PoCの様式そのものではありませんが、結果と次の資源配分を接続する視点は共通します。

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

判断者が報告会へ参加できない場合も、代理出席だけで済ませず、承認できる範囲と持ち帰る条件を決めます。判断者不在のまま共有会を開くと、追加質問のたびに資料を作り直し、基準の追加と検証の延長が起きやすくなります。会議日、出席者、決裁範囲、未決時の回答期限をPoC計画と報告書の表紙へ記載してください。

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

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

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

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

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

「サービスの有効性を確認する」では広すぎます。「対象業務の担当者が、試作品を使って処理時間を短縮できるか」のように、対象、条件、観察する変化を一文にします。顧客価値と技術成立性を同時に確かめたい場合は、問いを分け、どちらが今回の主判断かを決めます。

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

Goだけを決めると、条件を満たさなかったときに「もう少し続ける」が選ばれやすくなります。終了する条件と、評価不能だった場合に限定して確かめ直す条件を同じ欄へ置きます。追加検証は期間延長ではなく、新しい問い、方法、費用上限、終了条件を持つ別の検証です。

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

「反応は良好だった」「一定のニーズがあった」では、読み手が同じ判断を再現できません。誰がどの状況で何をしたか、ログに何が記録されたか、提示した価格に対してどの行動を選んだかを記載します。面談数やテスト件数は検証範囲の説明であり、仮説が確かめられた証拠とは分けます。

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

事実から言えることだけでなく、言えないことも書きます。たとえば利用されなかった場合、「価値がない」だけでなく、操作条件、対象者、導入説明、既存手順の制約という別の説明があり得ます。どの説明を次に確かめるかを決めると、都合のよい結論へ飛ぶのを防げます。

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

判断欄ではGo・Kill・追加検証のどれを推奨するか、どの基準と証拠を重く見たかを書きます。次の計画では担当、必要資源、期限、協力部門、次回判断日を置きます。「関係部署と調整する」「引き続き検討する」だけでは、誰も着手できません。

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

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枚だけで会議の目的を説明できるか確認します。会議後は推奨を上書きせず、実際の決定、決定者、理由、条件を決定ログへ追記してください。こうして報告書を完成資料ではなく、次の投資と実行を動かす判断履歴として残します。