PoC設計とは——「作る前に、終わり方を決める」設計行為
PoC（Proof of Concept: 概念実証）は本来、「このアプローチで課題が解けるか」を小さく確かめるための手段です。ところが実際には「とりあえずAIで何か作ってみる」という活動として始まり、判断材料を何も残さずに終わるPoCが後を絶ちません。
PoC設計とは、着手前に次の4点を決めきる設計行為です。
- 検証すべき仮説——「LLMで問い合わせ分類を自動化すれば、1次対応の時間を半減できるはずだ」のように、真偽を確かめられる文で書く
- 成功基準——仮説が正しいと判定できる数値ライン（例: 分類一致率90%以上・処理時間50%減）
- 期間——検証に使う期限。延長するなら何を根拠にするかも決めておく
- 本番移行条件——成功基準を満たしたら次に何をするか（予算・体制・対象範囲の拡大条件）を事前に合意しておく
4点目が最も見落とされがちです。移行条件を決めずに始めたPoCは、たとえ技術的に成功しても「良かったですね」で終わります。PoCの価値は動いたことではなく、導入判断ができるようになったこと——これがPoC設計の出発点です。
FDEの現場でどう使うか——「PoC止まり」問題の構造とスコープの絞り方
PoC止まり問題の構造＝成功基準なき実験
「PoC止まり」は生成AI導入の定番の失敗パターンとして知られています。構造は単純で、成功基準のない実験は、成功も失敗も定義できないため、意思決定につながらないのです。デモを見た関係者の感想（「すごい」「ちょっと不安」）だけが判断材料になり、結論は先送りされ、予算サイクルとともにプロジェクトが風化します。FDEはこの構造を知っているからこそ、実装より先に成功基準の合意に時間を使います。その前段となる課題定義の技術は要件の言語化スキルで解説した通りです。
スコープの絞り方
PoCのスコープは「業務全体の自動化」ではなく、仮説の検証に必要な最小の一工程に絞ります。実務では次の基準が使えます。
- 頻度が高く、1件あたりが小さい工程を選ぶ——検証データが早く貯まり、失敗しても被害が小さい
- 現状値が測れる工程を選ぶ——ビフォーの数字がないと改善を証明できない
- 人間のチェックを残せる形にする——全自動ではなく「ドラフト生成＋人間承認」から始めると、本番移行のハードルが大きく下がる
スピードも設計の一部
国内でFDE組織を運営するSansanの公式テックブログでは、顧客訪問で業務プロセスを整理した翌週にはプロトタイプを確認・リリースする高速サイクルが紹介されています（出典: Sansan Tech Blog・2026年7月）。数日でプロトタイプを出せるのは、事前にスコープと検証したいことが絞り込まれているからこそです。スピードは根性ではなく設計の産物であり、速い検証サイクルは顧客の熱量が高いうちに判断材料を届けるという点で、PoC止まり防止策そのものでもあります。
今どうやって身につけるか——小さく作って計測する習慣
1. 「仮説→基準→期限」を書いてから作る癖をつける
現職の小さな改善で構いません。何かを作る前に「仮説・成功基準・期限」の3行を書き、終わったら数字で判定する——この形式を守るだけで、PoC設計と同じ訓練になります。たとえば「議事録作成にLLMを使えば1本30分が10分になるはずだ。2週間・10本で検証する」と書いてから始める。判定の結果が「ならなかった」でも、検証プロセス自体が選考で語れる実績になります。
2. 評価指標の「型」を持つ
生成AI施策の評価指標は、実務ではおおむね次の3系統に集約されます。
| 型 | 測るもの | 例 |
|---|---|---|
| 時間削減 | 1件あたりの処理時間の変化 | 問い合わせ1次対応 20分→8分 |
| 精度 | 人間の判断との一致率・修正率 | 分類一致率92%、修正が必要な出力15% |
| 利用率 | 対象ユーザーの継続利用 | 対象30名中24名が週3回以上利用 |
3つ目の利用率は忘れられがちですが、「精度は高いのに使われない」を検出できる唯一の指標です。時間削減と精度が良くても利用率が上がらないなら、UIか業務フローへの組み込みに問題がある——と切り分けられます。
3. 計測できるものを作る練習
ポートフォリオを作る際も、デモで終わらせず「使用ログを取り、数字で語れる」ところまで作り込むのがおすすめです（ポートフォリオの作り方）。学習ステップ全体は未経験からのロードマップ、必要スキルの全体像はFDEになるにはを参照してください。
FDE Outlook: PoC乱発期の終わりと「本番移行力」の時代
今見えていること: 2023〜2025年は「まずAIで何か試す」PoC乱発期でした。多くの企業がすでに一巡分のPoC経験（と、本番に至らなかった記憶）を持っており、経営側の問いは「AIで何ができるか」から「なぜうちのPoCは本番に行かないのか」へ移りつつあります。国内でFDE職を掲げる企業が現れていること自体（FDE採用企業の動向）が、実験ではなく実装・定着への需要シフトの表れです。
今後の見立て: プロトタイプを作る能力はAIコーディングツールの進化で急速にコモディティ化します。差がつくのは、検証を設計し、成功基準で判定し、本番移行まで持ち込む一連の実行力——本記事でいうPoC設計スキルです。「PoCを100本やった」より「PoCを本番に3本上げた」が評価される時代への移行を、当サイトは見込んでいます。課題を定義する側の技術は要件の言語化スキルで解説しています。2本セットでFDEの中核能力になります。