PoCの進め方5ステップ｜AI PoCの期間・費用と本番移行の判断

去年の暮れに、家族で1000ピースのジグソーパズルを組みました。

三日かけて999ピースまで並べて、最後の1ピースが見つかりませんでした。 テーブルの下、ソファの隙間、鞄の底。30分探しました。

その30分、あの絵は誰にも「絵」として見えていません。 1ピース欠けた絵は、絵ではなく未完成品です。

99.9%とは、そういう状態のことです。僕がただの神経質なだけかもしれませんが…。

先に一行だけ置きます。PoCとは Proof of Concept の略で、作り込む前に「その考えが成立するか」を小さく確かめる実証実験のことです。

題材は、滞在客が自分の端末から荷物の配送を申し込めるアプリです。ホテルに置いて、現場で実際に使ってもらいました。

前置きはさておき、本題に入ります。

今日は、PoCで99.9%まで行ったものを本番に載せたときに、最後に何が残ったかという話をしていこうと思います。

① 教科書どおりに、PoCで確かめる

AI PoCとは

PoC（Proof of Concept／概念実証）とは、本格的に作り始める前に、「そもそも成立するのか」を小さく確かめる工程です。AI開発では、やってみないと精度が分からないという性質があるため、他の開発より重い意味を持ちます。

通常のシステム開発なら、仕様を決めれば「作れるか」はほぼ判断できます。AIは違います。同じ作り方でも、データが変われば結果が変わる。だから先に確かめます。

PoC・実証実験・本開発の違い

	何を確かめるか	作るもの
PoC	技術的に成立するか	検証に必要な最小限
実証実験	現場の運用に乗るか	限定環境で動くもの
本開発	（確かめ終わっている）	本番で使えるもの

この3つは順番であって、程度の差ではありません。PoCで「技術的に成立する」が出ても、実証実験で「現場が使えない」で止まることがあります。逆順にはできません。

AI開発でPoCが重視される背景

• 結果がデータに依存する — 手元のデータで出るかは、やってみないと分からない
• 投資額が大きくなりやすい — 学習環境と人材の確保に費用がかかる
• 期待値がずれやすい — 「AIなら全部できる」という前提で会話が始まりがち

3つ目が実務ではいちばん効きます。PoCは技術の検証であると同時に、何ができて何ができないかを関係者で揃える場でもあります。

PoCを行うメリット

メリット	中身
開発リスクを下げられる	本開発に入ってから「できませんでした」が起きない
手元のデータを評価できる	量・質・偏りが足りているかが、実際に回して分かる
投資判断の材料になる	進むか止めるかを、数字で決められる

「止める判断ができる」ことが本来の価値です。PoCを通すための工程だと考えると、止めるべきものが止まらなくなります。

AI PoCの進め方｜ステップ1｜目的・範囲・評価指標を決める

ここで決めた指標が、後の全部を決めます。何を、どの水準で満たせば「成立」とするのか。

評価指標は、精度だけにしないでください。精度99%でも、処理に1件30秒かかれば現場では使えません。速度・運用コスト・例外が出たときの扱いまで、合否の条件に入れます。

ステップ2｜データを評価し、準備する

必要なデータが、必要な量と質で存在するかを確認します。実務で止まるのはたいていここです。

• 量は足りているか（学習に使える件数）
• 偏りは無いか — 特定の条件のデータばかりだと、そこ以外で外す
• 正解のラベルは付いているか — 付いていなければ、付ける工数が別途かかる
• 個人情報や機密情報が含まれていないか

3つ目を見落とすと、PoCの前にラベル付けだけで数週間かかります。

ステップ3｜モデルを選び、試作する

既製のAPIで足りるのか、自社データで学習させる必要があるのかを決めます。最初から作り込まないのが要点です。既製のもので試して、足りない部分だけを自前にするほうが、確かめる速度が上がります。

ステップ4｜検証し、評価する

ステップ1で決めた指標に対して、結果を突き合わせます。

結果は厳しく評価してください。「おおむね良好」で通すと、本番で同じ問題が出ます。指標を満たしていない項目は、満たしていないと書きます。PoCの価値は、通すことではなく、通らないものを見つけることにあります。

ステップ5｜本番へ移すかを判断する

進む・条件付きで進む・止める、の3つで判断します。

「条件付きで進む」を必ず用意してください。進むか止めるかの二択にすると、惜しい結果が全部「進む」に寄ります。何が満たされたら進むのかを、期限つきで書きます。

AI PoCにかかる期間の目安

1〜3か月が一般的な範囲です。ただし、この期間を決めているのは技術ではなくデータの準備状況です。

状況	期間への影響
データが揃っていて、ラベルも付いている	短く済む
データはあるが、整形が必要	整形の工数が丸ごと乗る
ラベル付けから始める	PoC本体より長くなることがある
データをこれから集める	PoC以前の工程になる

AI PoCの費用は、何で決まるか

金額そのものより、何が金額を動かすかを押さえたほうが見積もりを読めます。

• データの準備工数 — ラベル付けが要るかどうかで大きく変わる
• 検証の回数 — 指標を満たすまで何周するか
• 既製APIか、自社学習か — 学習環境の費用が乗るかどうか
• 現場での検証を含むか — 実データを使うなら、現場の工数も費用です

見積書で確認すべきなのは、4つ目が誰の負担になっているかです。発注側の作業として書かれていないと、あとから自社の工数として現れます。

PoCから本番運用へ進む割合

PoCを実施した案件のうち、本番まで到達するのは一部にとどまります。これは失敗率ではありません。止めるべきものを止めた結果も含みます。

問題になるのは、成立したのに本番へ進めなかったケースのほうです。この記事の後半は、そこの話です。

PoCでよくある失敗と、回避のしかた

よくある失敗	回避のしかた
目的が曖昧なまま始める	合否の条件を、着手前に文章で書く
評価指標が精度だけ	速度・運用コスト・例外の扱いを条件に入れる
データの準備を軽く見る	着手前に、量・質・ラベルの有無を確認する
PoCが延々と続く	期限を先に決め、延長は理由と条件を書いて判断する
現場を巻き込まない	使う人に、検証段階で触ってもらう

4つ目が最も多いです。「もう少しで届きそう」で延長が繰り返されます。延ばすなら、何が変われば届くのかを書いてから延ばします。

生成AIのPoCで、特に気をつけること

従来のAIと違い、生成AIは同じ入力でも出力が毎回変わります。評価のしかたが変わります。

• 出力の揺れを前提に評価する — 1回の結果で判断せず、複数回の分布で見る
• 誤りの種類を分けて数える — 「間違い」を一括りにせず、どう間違えたかで分ける
• PoC→MVP→本番の3段階で設計する — 生成AIは中間段階が要る

PoCチームに揃えるべき3つの役割

役割	担うこと
業務を知っている人	何が正解かを判定できる。ここが欠けると評価が成立しない
技術を担当する人	モデルの選定と実装
判断できる人	進む・止めるを決められる。会議を待たずに答えられる立場

1つ目が最も欠けます。技術者だけで検証すると、「動いた」は判定できても「使える」は判定できません。

本番運用へ進むときに、追加で必要になるもの

PoCで確かめた範囲の外に、本番で初めて要るものがあります。

• セキュリティ設計 — 誰がどのデータにアクセスできるか
• 可用性の担保 — 止まったときにどうするか。落ちる前提の設計
• ガバナンス体制 — 誰が使ってよいか、出力の責任は誰が持つか
• 運用の担当 — 精度が落ちたときに、誰が気づいて誰が直すか

これらはPoCの見積もりに入っていません。本番の費用が「PoCの延長」で計算できないのは、ここが理由です。

PoCの外注先の選び方｜納品型と伴走型

	何を受け取るか	向いているとき
納品型	検証結果の報告書と試作物	検証したい内容が確定している
伴走型	一緒に進める過程そのもの	何を検証すべきかから決めたい

「何を確かめたいか」が自社で言語化できているかで選びます。言語化できていない状態で納品型を選ぶと、報告書は出るのに判断ができない、という結果になります。

PoCの教科書どおりに進めました。小さく作って、現場に置いて、成立するかを見る。

動きました。

申し込みはフォームから入り、料金が自動で計算され、決済が通り、注文が一覧に並ぶ。問い合わせにはAIが答える。精度も応答も、十分でした。

この時点の報告は、こうです。

「LLMは99.9%にできるけど、100%の処理では予期せぬ対応をする可能性がある」

正確な報告です。 そして同時に、危険な報告でもありました。

99.9%という数字が、褒め言葉として読めてしまうからです。 そう報告されたら、会議はそこで止まります。誰も「残りの0.1%を誰がやるのか」を聞きません。

ここまでは、教科書どおりです。

目的を決め、データを揃え、指標で判定し、進むか止めるかを決める。ここまでやれば、PoCは機能します。

この記事の後半で扱うのは、機能したあとの話です。指標を満たした検証結果が、そのまま本番になるとは限りません。

② そのとおりに本番へ載せて、3万円が宙に浮く

本番で、こうなりました。

3万円を超える注文が1件、システムのどこにも記録されないまま、与信だけが確保されていました。

構造は3段です。

→ ① そのサービスは、システムとしては受け付けない状態で閉じていた
→ ② LLMが良かれと思って、それを案内した
→ ③ 話が進んで決済まで到達し、与信だけが残った

利用者のカードは、その金額ぶん押さえられています。ところが、荷物を取りに行く先が、どこにも記録されていません。

いちばん厄介だったのは、これがエラーとして飛ばないことでした。

→ 画面は落ちていない
→ 通信は成功している
→ 案内は自然
→ ログにもエラーが無い

事故の痕跡が「あるべきものが存在しない」形で残ります。

誰かが台帳と決済の明細を突き合わせるまで、この3万円は誰の目にも入りません。

③ そして、0.1%は精度の話ではないと分かる

なぜPoCで出なかったのかというと、理由はこうです。PoCでは、受け付けを止めている状態を試していなかったからです。

PoCが確かめられるのは、試した範囲の中だけです。

そして、ここで「0.1%」の正体が変わりました。

0.1%とは、小さいという意味ではありません。AIが手を引いた後に丸ごと残る仕事量につけた名前です。

引き受け手には、3つしか選択肢がありません。

→ AIが引き受ける — できません。それが0.1%の定義です
→ 設計が引き受ける — 止める仕組みを作る
→ 現場が引き受ける — 気づいた人が手で直す

要は、3つ目がいつも既定になっています。

④ 原因は「見積書に0.1%の行が無い」こと

原因を一つに絞ると、これでした。

機能や画面の数には行があります。「AIが通したものを止める仕組み」には行がありません。

止める仕組みは機能ではないからです。行が無いので、誰の担当でもない。誰の担当でもないので、事故が起きてから初めて存在が認識されます。

そして厄介なのは、ここ数年で99.9%側の値段が急激に下がったことです。作る部分が安くなったぶん、残った0.1%の比重だけが上がりました。

⑤ 直してみる — 0.1%を、直せる層に置く

事故の当日、修正の見積りはこう出ました。

「火曜日には対応が完了します」

打ち消し線です。その2分後。

「アプリのバージョンアップをせずにバックエンドだけで対応できそうなので、1時間後には対応が完了します。」

2分で、火曜日が1時間後になっています。

これを「速い」と読むのは半分しか読めていません。差を作ったのは技術力ではなく、修正がどの層に閉じるかです。

→ 自分の側で閉じる修正 — 1時間
→ 外部の審査を通る修正 — 火曜日

同じ1行でも、置いた場所が違うだけで火曜日と1時間に分かれます。 そしてこの差は、事故が起きてからでは作れません。

その外側の話もします。当時、ストアの審査が遅れていました。理由について、こう聞いています。

「AI開発による申請が増えまくっていて…」

皮肉です。99.9%を作れる人が増えた結果、100%に至る最後の関門だけが混雑しました。 速度をいくら上げても、渋滞は自分では解けません。

⑥ あとで知った — この現象には、43年前の名前がついていた

素朴な対処のつもりでしたが、調べると同じものを指す論文は、すでにありました。

認知心理学者のリザンヌ・ベインブリッジが1983年に『Automatica』へ発表した 「Ironies of Automation（自動化の皮肉）」 です。

主張はこうです。仕事の大半を自動化すると、新たに深刻な問題が生じる。人間の作業者には、自動化できなかった仕事だけが残るからだ。

そして、残された側に何が起きるかも書かれています。作業者は、脈絡のない仕事の寄せ集めと、わずかな支援だけを渡された状態になる。

「脈絡のない寄せ集め」。 これが、私たちが0.1%と呼んでいたものの正体でした。

さらに二段目があります。自動化されると、作業者は日常業務の中で技能を練習しなくなる。にもかかわらず、稀にしか起きない重要な介入に備える必要がある。だから訓練は減るのではなく、増やさなければならない。

自動化すると人の仕事は減る、という前提そのものが違っていました。

この論文は2016年11月時点で1,800件の引用を集めており、その数は増え続けているそうです。43年前に指摘されたことが、いまAIで再演されています。

新しい理屈は、ひとつも要りませんでした。

⑦ 何が変わったか — 数字が動いたのは、作り切った週ではなかった

成果の側に移ります。こちらのほうが、0.1%の正体がはっきり出ます。

中間時点の記録です。

「目標の160DL、26件受注（受注率15%）に対し、今は約50ダウンロード・2件受注（受注率4%）」

受注率で、目標の4分の1です。 詰まっていたのはファネルの手前でした。

最終の記録はこうです。

「受注19件／配送32個（昨年24個に対し133%）／売上127,951円（目標に対し121%）」

そして、内訳がこれです。

「前半13日で2件、後半11日で17件（850%成長）」

同じアプリ、同じ現場、同じ声かけ。人も増えていません。

記録には、この週に起きたことが2つ並んでいます。

→ 部屋への案内と、ドアノブに吊るチラシ。 これを実施した後、ダウンロードが200〜300%増加
→ 残り4日のところで、Push通知・クーポン・配送時間指定が本番投入

正直に書くと、この2つは同じ週に走っており、どちらがどれだけ効いたかは切り分けられていません。

ただ、一つだけ言えます。数字が動いたのは、アプリの中身を作り切った週ではありませんでした。

逆側の記録もあります。飲食予約の機能は、最終日まで受注ゼロでした。客に「どこで飲食店を調べていますか」と聞くと、そもそも調べていないという答えが返ってきます。

需要が無いのではありません。その人の中に、まだ「調べ方」という習慣が無いという答えです。機能を足しても、習慣は生まれません。

そして、現場から出てきた解のひとつが、これです。

「タオルを3枚置けば内線の問い合わせはかかってこない」

数千万円規模の実装量と、タオル3枚が、同じ問題への解として並置されます。

⑧ 現場で使うなら、この3枚

表1：0.1%の引き受け手（見積書に行を作る）

0.1%の中身	検知方法	誰が	いつ
AIが閉じた受付を案内した	突き合わせ	運用担当	毎日
決済のみ成立	突き合わせ	運用担当	毎日
利用を思い出してもらう	現場の掲示	決めていないと誰もやらない	常時
判断がつかない問い合わせ	有人へ転送	現場	即時

この表を、機能一覧と同じ扱いで見積書に載せてください。

表2：修正がどの層に閉じるか（事故の前に決める）

修正の置き場所	復旧までの時間	事故の前にやること
バックエンドの設定	1時間	止める判断をここに置く
バックエンドのコード	数時間	—
アプリ本体	審査を挟む＝数日	ここに置かない

「同じ1行を、どこに置くか」を先に決めます。 事故が起きてからでは動かせません。

表3：PoCの合否判定（精度で判定しない）

見る項目	合格条件
精度	参考値。単独では合否にしない
0.1%の引き受け手	表1が全行埋まっている
突き合わせの設計	実装されている
利用を始めてもらう導線	担当が決まっている

⑨ この考え方が効き続ける理由

99.9%の値段は、これからも下がります。そして、下がるほど0.1%の比重が上がります。 これは技術の進歩で解決しません。0.1%は、精度ではなく配分の問題だからです。

→ 作る部分が安くなる → 誰でも99.9%に到達できる
→ 残るのは引き受け手の決まっていない0.1%
→ そこには見積書の行が無い
→ だから、事故として現れる

PoCの合否を精度で判定してはいけません。 0.1%の引き受け手が決まっているかどうかで判定してください。

そして、実装力の証明もそこに出ます。火曜日を1時間に変えたのは、事故の日の技術力ではなく、事故の前に置き場所を決めていたことでした。

ところで、ここまで書いてきたことは全部、事故のあとに分かったことです。ただし、事故の前に分かる方法もありました。突き合わせを1件、設計に入れておくだけです。とはいえ、それを見積書に書ける人が、当時どこにもいませんでした。

関連して、内製化しても意思決定は速くならない話と、AIエージェントの目標書き換えを防ぐ話を別に書いています。物流DXで最後の0.1%が残る話はすでに公開しています。あわせて読むと、同じ判断が別の場所でも効いていることが分かると思います。

この判断を実際の案件で使う場面については、新規事業コンサルとMVP・PoCのページに整理しています。

---

0.1%といえば、宝くじの当選確率をいまだに正確には知りません。当たったあとの使い道だけは、毎回きちんと決まっています。

残りの0.1%を先に考えないという点では、僕も人のことは言えませんでした。

以上です。

AI PoCのよくある質問

AI PoCとは何ですか？

本格的に作り始める前に、「そもそも成立するのか」を小さく確かめる工程です。AI開発では、同じ作り方でもデータが変われば結果が変わるため、他の開発より重い意味を持ちます。

PoCと実証実験、本開発は何が違いますか？

PoCは技術的に成立するか、実証実験は現場の運用に乗るか、本開発は確かめ終わったものを作る工程です。3つは順番であって程度の差ではありません。PoCで成立しても、実証実験で「現場が使えない」で止まることがあります。

AI PoCの進め方を教えてください。

5ステップです。①目的・範囲・評価指標を決める ②データを評価し準備する ③モデルを選び試作する ④検証し評価する ⑤本番へ移すかを判断する。①で決めた指標が後の全部を決めます。評価指標を精度だけにしないでください。

AI PoCはどのくらいの期間がかかりますか？

1〜3か月が一般的な範囲です。ただしこの期間を決めているのは技術ではなくデータの準備状況です。ラベル付けから始める場合、PoC本体より長くなることがあります。

AI PoCの費用は何で決まりますか？

データの準備工数、検証の回数、既製APIか自社学習か、現場での検証を含むかの4つです。見積書では、4つ目が誰の負担になっているかを確認してください。発注側の作業として書かれていないと、あとから自社の工数として現れます。

PoCとは何ですか？

Proof of Concept の略で、作り込む前に「その考えが成立するか」を小さく確かめる実証実験のことです。技術的に動くか、業務に載るか、費用が見合うかを確認します。ただし確認できるのは、試した範囲の中だけです。本番で起きることの多くは、PoCの範囲の外側で起きます。

PoCで99.9%の精度が出れば、本番に載せて大丈夫ですか？

危険です。99.9%という数字は褒め言葉として読めてしまうため、会議がそこで止まります。残りの0.1%は「小さい」という意味ではなく、AIが手を引いた後に丸ごと残る仕事量につけた名前です。誰がそれを引き受けるかが決まっていなければ、本番で事故として現れます。

AIが原因の不具合は、どう見つけるのですか？

突き合わせを設計に含めます。実際に起きた事故では、画面も落ちず、通信も成功し、ログにもエラーがありませんでした。決済側には与信が立っているのに、業務側に注文が存在しない。壊れたものを探す監視では見つかりません。2つの記録を並べて、片方にしか無い行を拾う仕組みが要ります。

PoCから本番化するとき、見積りで見落としがちな工程は何ですか？

AIが通したものを止める仕組みと、利用を思い出してもらう仕掛けです。どちらも機能ではないので、機能一覧にも見積書にも行がありません。行が無いので誰の担当でもなく、事故が起きてから存在が認識されます。ここを工程として書けるかどうかで、本番化の成否が決まります。

AIで作った機能を増やせば、利用は伸びますか？

伸びないことがあります。ある現場では、飲食予約の機能が最終日まで受注ゼロでした。客に聞くと、そもそも飲食店を調べる習慣が無いという答えでした。需要が無いのではなく、習慣が無い。一方で数字が動いたのは、アプリを作り込んだ週ではなく、部屋への案内とドアノブに吊るチラシを配った週でした。