「まず PoC から始めましょう」──AI を業務に入れる話は、たいていこの一言から動き出します。慎重で、正しい進め方に見えます。ところが数ヶ月後、その PoC がどうなったかを尋ねると、はっきりした答えが返ってこないことが少なくありません。動いてはいる。悪くもなかった。でも本番には入っていないし、やめたわけでもない。この宙づりの状態が「PoC 止まり」です。先に結論を書きます。PoC 止まりは、AI の出来が悪かった結果ではありません。「終わり方」を決めずに始めた検証が、決めなかったとおりに終われなくなっているだけです。判定する日、合格の線、合格したときに引き取る人、途中で止める条件──この 4 つを先に書いた PoC は、本番に進むか、きれいに畳まれるかのどちらかになり、止まりにくくなります。この記事では、PoC 止まりとは何か、AI の PoC が本番に進まない 4 つの原因、始める前に決める終わり方の 4 点、PoC を「小さい本番」として組む手順、自社で判定日を動かさないために置いている型、そしてすでに止まっている PoC の立て直し方までを、稟議と現場の両方でそのまま使える形で整理します。
- PoC 止まりとは、検証が「失敗した」状態ではなく、判定が出ないまま宙づりになった状態 ── 失敗なら次に進めるが、宙づりは進めも畳めもしない
- 原因は AI の性能ではなく 4 つ ── 問いが「できるか」になっている / 合格線と判定日が無い / 本番の持ち主がいない / 検証の条件が本番と違う
- 始める前に決めるのは 判定日・合格線・本番の持ち主と入れる場所・止める条件 の 4 点。これがあると PoC は「本番へ / 条件つきで続ける / 畳む」の 3 択のどれかで終わる形になる
- AI の PoC は「小さい本番」として組む ── 本番の入力・権限・確認点で、上限つきで動かし、判定日に決める
PoC止まりとは ── 「うまくいかなかった検証」ではなく「終わり方を決めていない検証」
PoC(Proof of Concept・概念実証)とは、本格導入の前に「この方法は自社で成り立つか」を小さく確かめる取り組みのことです。AI の文脈では、任せたい業務に AI を当ててみて、使えそうかを見る試行を広く指します。呼び方はトライアル・実証実験・お試し導入とさまざまですが、この記事では「本番の前に、小さく確かめる工程」をまとめて PoC と呼びます。そしてPoC 止まりとは、その工程が終わっても(あるいは終わらないまま)本番に進まず、導入の判断もされずに宙づりになった状態を指します。
ここで大事なのは、PoC 止まりは「失敗」とは別のものだということです。失敗は、判定が出た状態です。「この業務には合わなかった」「この方法では回らない」という結論があり、次の一手──方法を変える、業務を変える、やめる──に進めます。PoC 止まりには判定がありません。動いてはいる、悪くもなかった、でも本番には入らない、やめる理由も無い。判定が無いので次に進めず、畳む理由も無いので終われない。関係者の関心だけが少しずつ薄れ、気づけば誰も触っていない──これが「PoC 疲れ」と呼ばれる状態の正体です。何度も PoC を回して疲れているのではなく、一度も終われていないことに疲れているのです。
対象が「答える AI」から「仕事を進める AI」に移ると、この宙づりは起きやすくなります。AI エージェントとは、目的を与えると必要な手順を自分で組み立てて実行し、結果まで進める AI のことです(言葉の整理と仕組みは「AIエージェントとは」に 1 本にまとめています)。答えを返す AI の PoC なら「答えの質」を見れば済みますが、仕事を進める AI の PoC で見るべきは「その仕事が、人の手を離れて毎回回るか」であり、これは数回の試行では見えません。見えないものを見ようとして期間が延び、延びるほど終わり方が曖昧になる──仕事を進める AI ほど、終わり方の設計が先に要る理由です。
もう 1 つ、PoC の結果が読めなくなる構造があります。「思ったほどではなかった」という結果が出たとき、その正体には 4 種類あります。効かない(方法が合っていない)、まだ(効き始めるまでの時間の途中にいる)、土俵に立てていない(そもそも前提の条件が揃っていない)、測れていない(見るべき数字を取っていない)。この 4 つは打つ手が全部違うのに、結果の数字だけを見ても区別がつきません。区別がつかないから「もう少し様子を見よう」になる。PoC 止まりの多くは、この「様子見」の積み重ねです。なお、チャットボットに限った PoC の設計は「チャットボットのトライアルとPoCの違い」に書きました。この記事はそれを AI 全般、とくに仕事を進める AI に広げ、止まる構造そのものをほどきます。
AIのPoCが本番に進まない 4 つの原因 ── どれも AI の性能ではない
本番に進まない PoC を並べて見ていくと、原因は 4 つに収まります。「AI の精度が足りなかった」というものは、その 4 つの中にありません。精度が原因に見える場合も、たいていは「どこまでの精度なら本番に入れるか」を決めていなかった、という原因 02 の形をしています。
AI に「この作業ができるか」と問う PoC は、ほぼ「できる」で終わります。いまの AI は、示された作業を 1 回きれいにこなす力を、たいてい持っているからです。しかし本番で問われるのは「できるか」ではなく「回るか」です。誰が動かすのか、どの頻度で、入力が乱れていたらどうするか、例外はどこに逃がすか、人はどこで確認するか。この問いを持たずに始めた PoC は、「できた」という証拠だけを積み上げ、本番に入れるための材料を 1 つも持たないまま終わります。お披露目の日が PoC の頂点になり、その後に何も残らない──そういう PoC は、問いの立て方が「できるか」だったのです。
「うまくいったら本番へ」の「うまくいったら」が数字や条件になっていない PoC は、終われません。合格線が無ければ、合格も不合格もありません。「悪くなかった」「もう少し精度を上げたい」「別のケースも試したい」という言葉が続き、期間が延び、延びた分だけ関心が薄れます。判定日が無いことも同じ働きをします。「いつ判断するか」が決まっていないと、判断は常に「次の会議で」になり、次の会議では別の議題が優先されます。合格線と判定日は、PoC を終わらせるための装置です。装置の無い PoC が止まるのは、自然な帰結です。
PoC の担当者と、本番でその業務を持つ人が違う、というのはよくあることです。推進部門や情報システム部門が PoC を回し、現場は「検証中らしい」と聞いているだけ。すると PoC が合格しても、本番の業務フローのどこに入れるか、誰が運用するか、その人の他の仕事をどう減らすかが決まらず、合格したまま止まります。もう 1 つ、本番に入れる決裁を持つ人が判定の場にいない PoC も止まります。担当者が「良さそうなので稟議を」と持ち込むところから説明が始まり、説明資料を作っている間に PoC の熱は冷めます。本番の持ち主(運用する人)と、本番に入れる決裁を持つ人。この 2 人が最初から判定の場にいない PoC は、合格しても本番に届きません。
整えたサンプルデータ、権限の制約が無い環境、詳しい担当者だけの少人数、費用の上限も締切も無い進め方──PoC を「動かしやすく」する工夫は、そのまま「本番とのズレ」になります。本番の入力は整っていません。本番では AI に渡せる権限に線があります。本番では詳しくない人が使い、費用には上限があります。PoC で動いたものを本番に持っていくと「PoC では動いたのに」が起き、その修正が別の PoC になり、また終わらない。特に、費用のかからない PoC には注意が要ります。無料で始められる PoC は始めやすい反面、続けても誰も痛くないので、終わる理由がありません。終わり方は、始めやすさの反対側に置かなければ、誰も決めません。
4 つに共通するのは、どれも「始める前に決めていなかったこと」に帰着することです。AI の性能は自社では動かせませんが、決め事は着手前の 1 時間で置けます。これは AI 導入の失敗全般に言えることで、その 5 つのパターンは「AI導入はなぜ失敗するのか」にまとめました。PoC 止まりはその中の 1 パターン(検証のまま本番に入らない)で、この記事はそこだけを深く掘ります。次のセクションで、置くべき決め事を 4 点に絞ります。
始める前に決める「終わり方」の 4 点 ── 判定日・合格線・持ち主・止める条件
PoC を始める前に、1 枚の紙に 4 つのことを書きます。書く時間は 1 時間もかかりません。しかしこの 1 枚が、PoC を「本番へ / 条件つきで続ける / 畳む」のどれかで終わる形にします。
決めごと 1 ── 判定日: いつ判断するかを、期間ではなく日付で
「いつ判断するか」を、期間ではなく日付で書きます。「4 週間」ではなく「○月○日の会議で」です。期間で書くと開始日がずれたときに終わりもずれ、日付で書くとずれません。判定日を置くときに 1 つだけ織り込むものがあります。効き始めるまでの時間です。AI に仕事を任せると、最初の数日は手順書とのズレが続けて見つかり、結果が悪く出ます。この期間を判定に含めると「効かない」と誤読するので、「最初の 1 週間は手順の調整期間として判定の対象から外す」のように、織り込む時間を先に書いておきます。判定日は 1 つだけ置きます。中間の確認日を置くのは構いませんが、判定は 1 回です。「中間で微妙だったから延ばす」を入れた瞬間に、判定日は無くなります。
決めごと 2 ── 合格線: 3 択の基準を、判定日の前に書く
合格線は「合格 / 不合格」の 2 択ではなく、3 択で書きます。本番へ進める条件、条件をつけて続ける条件、畳む条件。それぞれを、判定日に見る数字と状態で書きます。書き方の型は次の表のとおりです。
| 判定 | 基準の書き方(型) | 判定日にやること |
|---|---|---|
| 本番へ | 人の確認で差し戻した割合が決めた線を下回り、差し戻しの理由が「手順書で潰せるもの」だけになっている。本番の持ち主が「自分で回せる」と言える | 入れる日と場所を確定し、PoC の柵と手順書をそのまま本番に持ち上げる |
| 条件つきで続ける | 差し戻しの割合は下がり続けているが、線にはまだ届いていない。手順書の改訂が続いている | 続ける期間と次の判定日を書き直す(1 回だけ)。理由を 1 行残す |
| 畳む | 差し戻しの理由に、手順書では潰せないものが残っている(判断が毎回違う・入力が毎回違う)。本番の持ち主が「回せない」と言う | 理由を 1 行残して終える。「AI が駄目」ではなく「この業務・この切り出し方では回らなかった」と書く |
合格線で 1 つ注意があります。暗黙の合格線が「全問正解」になりがちなことです。AI の出力に誤りが混ざる可能性は、運用でゼロにはなりません。見るべきは、誤りが人の確認で拾える形になっているか、そして拾った誤りが手順書に返って減っていくか、です。合格線を「誤りゼロ」に置いた PoC は、どんな AI でも不合格になります。また、線を数字にするには「この入力にはこの出力が正しい」という合格の例が要ります。その作り方はこの記事では扱いません(末尾の予告のとおりです)。
決めごと 3 ── 本番の持ち主と、入れる場所
合格したとき、誰が運用し、業務フローのどこに入れるかを、PoC の前に書きます。「月次の締めの、請求書の突合の手前に入れる。運用は締めの担当者。確認は差異が出た分だけ」のように、業務の言葉で 1 行です。この 1 行が書けない PoC は、原因 03 の入り口に立っています。書けるなら、その持ち主を PoC の判定の場に最初から入れてください。本番に入れる決裁を持つ人も同じです。PoC の開始時に、この 1 枚(判定日・合格線・持ち主・止める条件)を 2 人と共有しておくと、判定日は「事前に合意した基準に対する結果の報告」だけで進み、説明資料を作る工程がまるごと消えます。
決めごと 4 ── 止める条件: 判定日を待たずに止めるとき
判定日まで走らせるのが原則ですが、判定日を待たずに止める条件も先に書いておきます。外に出てはいけないものが出た、使ってよい範囲の外に触った、使った量が上限に当たった──こうした事故や上限は、判定とは別に即時に止める理由です。止める条件を先に書いておくと、事故が起きたときに「止めるか続けるか」を現場が迷わずに済み、止めたことが PoC の失敗として扱われずに済みます。逆に、止める条件に「思ったより精度が低い」を入れてはいけません。それは判定日に合格線で見るものであって、途中で止める理由ではありません。途中の感触で止めたり延ばしたりを始めると、判定日も合格線も無いのと同じになります。
この 4 点を書いた PoC は、始める前に終わり方が決まっています。PoC は「やってみないと分からない」ものではなく、「何が分かったら終わりか」を先に決めるものです。分からないのは結果であって、終わり方ではありません。
PoC を「小さい本番」として組む 5 手順 ── 本番の入力・権限・確認点で、量だけ小さく
終わり方を書いたら、PoC そのものの組み方です。私たちは AI の PoC を「検証」ではなく「小さい本番」として組むことをおすすめしています。本番の入力・本番の権限・本番の確認点で、範囲と量だけを小さくして動かす。原因 04(条件が本番と違う)を構造ごと消す組み方で、合格したときに PoC の柵と手順書がそのまま本番に持ち上がります。手順は 5 つです。
- ①最初の 1 業務と、任せる範囲を決める ── PoC の対象は 1 業務です。「部署の業務をまとめて」は PoC を終わらなくします。手順を言葉で説明できて、繰り返し発生し、誤りに気づけばやり直せる業務を 1 つ選び、その中で AI に任せる工程と人が持つ工程の線を引きます。選び方と線の引き方は「AIエージェント導入の進め方」の 5 ステップに書いたとおりで、PoC の 1 業務目は本番の 1 業務目と同じものを選びます。PoC 用に別の業務を選ばない、が要点です。
- ②本番の入力・本番の権限・本番の確認点で動かす ── サンプルではなく実際の入力の一部を、整えずに渡します。AI には本番で渡すのと同じ権限を、本番と同じ線で与えます(読むだけなら読むだけ・書く先は限定・削除は持たせない)。人の確認は「念のため見る」ではなく工程に置きます。権限と柵の作り方は「AIエージェントのセキュリティ」で扱いました。「PoC だから権限を緩める」をやめると、本番でいちばん手戻りの多い部分が PoC の中で先に見えます。
- ③上限をつける ── 使ってよい利用料の上限、扱う件数の上限、期間(= 判定日)。上限があると PoC は「青天井の実験」から「上限のある本番」に変わり、稟議も通しやすくなります。利用料の上限をどう置くかは「AIエージェントの費用」の利用料の層に書きました。上限は、AI が自分で上げられない場所に置きます。
- ④差し戻しと例外を数える ── 判定日に合格線と照らすための数字を、初日から取ります。最低限は 2 つ、人の確認で差し戻した割合と、手順書に無い例外が出た割合です。差し戻しには理由を 1 行添え、「手順書で潰せるもの」と「潰せないもの」に分けておきます。この分け方が、判定日の 3 択をほぼ決めます。数字は AI に自分で報告させ、人は週に 1 度だけ見ます。動かした後に何を毎週見て、任せる範囲をどう広げるかは、運用の記事で改めて手順に落とす予定です。
- ⑤判定日に、3 択で決める ── 決めごと 2 の表のとおりに判定し、理由を 1 行残します。「本番へ」なら、PoC の柵・手順書・確認点をそのまま持ち上げて、入れる場所に入れます。小さい本番として組んでいれば、ここで作り直すものはほとんどありません。「畳む」なら、その 1 行が次の PoC の設計の材料になります。
小さい本番は、整えた環境で動かす PoC より、始めるのに手間がかかります。権限を設計し、実際の入力を渡し、確認点を工程に置く分だけ重い。それでも私たちがこの形を薦めるのは、整えた PoC で払わずに済んだ手間は、消えるのではなく本番投入のときにまとめて請求されるからです。しかもそのときには、PoC の熱は冷めています。同じ手間を、熱のある PoC の側で払うほうが安く、確実です。
自社の型 ── 判定日と基準を実行前に書き、途中で曲げない
Livune は、AI エージェントの開発・導入支援を行うと同時に、自社の日常業務を AI エージェントに任せて回している会社です。新しい取り組みを始めるときに自社で置いている型を、3 つ書きます。いずれも AI に限らず、施策や検証の全般に当てはめているものです。
1 つ目は、走り始めるときに 3 つを文章で書くことです。何の時間差を織り込むか、判定日はいつか、続行・撤退・方向転換のそれぞれをどの基準で判断するか。これを書かずに始めた取り組みは、判定が感情や直近の出来事で決まってしまう、というのが私たちの経験則です。そして、書いた判定日の前に出てくる「もうやめましょう」と「これは例外だから延ばしましょう」は、どちらも退けると決めています。曲げたくなったら、その場で曲げるのではなく「方針そのものを書き換える」議論を別に立てる。立てた方針は個別の誘惑で曲げない、という決まりを、会社の判断軸として文書に置いています。
2 つ目は、終点の数字だけを見ないことです。売上・問い合わせ・クリックといった終点の数字は、効き始めるまで時間がかかるうえ、ゼロの理由を語ってくれません。先ほどの 4 種類のゼロ(効かない / まだ / 土俵に立てていない / 測れていない)を区別するために、終点の手前に段階の計器を置き、判定日にどの段階まで来ているかで判断します。段階を置いてあれば、「まだ」と「効かない」を取り違えて早く畳むことも、「測れていない」を「効いている」と読んで続けすぎることも減ります。
3 つ目は、合格線を「使い倒す」ではなく「検証を通過する」に置くことです。私たちは、自分たちが使って効くと判断したものだけをお客様に提案する、と決めています。ただしその判断の線は「最低限の検証を通過したか」であって、「使い倒して完璧に分かったか」ではありません。線を高く置きすぎると、何も提案できなくなり、何も本番に進まなくなります。線を低く置きすぎると、効くと確かめていないものを出すことになります。検証の設計と合格線を先に書き、通過したら進む──線の高さそのものを、始める前に決めておくということです。
正直に書いておくと、この型を置いていても、判定できないことはあります。ある施策の効果を測る検証を組み、決めた期間を走らせた結果が「ゼロ」だったことがありました。ところが、その検証は比べる 2 つを互いに食い合う形で配置していて、しかも差が出るために必要な件数を桁で下回っていました。つまりそのゼロは「効かない」でも「まだ」でもなく、「測れていない」でした。私たちはこれを失敗ではなく「判定不能」として畳み、検証を組む前に「この設計で差は出るのか」を数字で確かめる、という作法を 1 つ足しました。AI の PoC でも同じことが起きます。対象の件数が少なすぎる PoC、比べる条件が混ざっている PoC は、期間をいくら延ばしても判定できません。判定日と合格線の前に、「その PoC は判定できる設計か」を 1 度だけ問うてください。
すでに PoC 止まりのとき ── 立て直しの 3 手
すでに宙づりになっている PoC がある場合の立て直し方です。新しく始めるより難しいのは、関わった人の時間と気持ちがすでに乗っているからです。だからこそ、立て直しは 3 手で短く終えます。
- ①今の PoC に、後付けで「終わり方」を書く ── 判定日・合格線・本番の持ち主・止める条件の 4 点を、いまから書きます。後付けでも効きます。書いてみて、本番の持ち主が書けない、合格線がどうしても数字にならない、という場合は、その PoC は畳む候補です。書けないこと自体が判定材料です。
- ②「できた」の証拠を、「回った」の証拠に置き換える ── これまでの PoC が整えた環境でのお披露目に寄っていたなら、本番の入力・権限・確認点で、期間を短く区切って動かし直します。数週間で構いません。ここで差し戻しと例外の数字が初めて取れ、合格線と照らせるようになります。
- ③判定日に 3 択で決め、理由を 1 行残す ── 本番へ / 条件つきで続ける / 畳む。畳む場合も「AI が駄目だった」とは書きません。「この業務の、この切り出し方では、手順書で潰せない例外が残った」と書きます。この 1 行があると、次の PoC は同じ場所で止まりません。畳んだ PoC は失敗ではなく、判定が出た検証です。
合格線を数字にするために欠かせないのが、「この入力にはこの出力が正しい」という合格の例をどう集め、いくつ用意し、どう更新するかです。ここは PoC の設計の中でも実務の細部が多く、別の記事で改めて手順に落とす予定です。この記事では「合格線は、合格の例があって初めて数字になる」ことだけを持ち帰ってください。
Livune は、「作業を AI に任せる仕組み」を構築している会社です。本番で回ることを前提に組み立て、PoC 止まりを作らない──これは私たちが自社の取り組みに対して置いている決まりでもあります。判定日と基準を実行前に書き、途中で曲げない型は、私たちが自分の会社でも使っているものです。
Livune は、任せる 1 業務の選定から、判定日と合格線、本番の持ち主、権限と柵、上限の置き方までを、本番運用を前提に一緒に設計する AI エージェント開発・導入支援の会社です。宙づりになっている PoC の立て直しからでもご一緒します。
Livune の AI エージェント導入について相談する →よくある質問
期間より先に判定日を決めてください。目安を挙げるなら、仕事を進める AI の PoC は、最初の手順調整の期間を除いて数週間の実運用があれば、差し戻しと例外の数字が合格線と照らせる程度に溜まります。ただし、対象の件数が少ない業務では、同じ週数でも判定に足りないことがあります。期間ではなく「判定に必要な件数が溜まる日」で判定日を置くと、延ばす・縮めるの議論がなくなります。
「失敗」ではなく「判定が出ていない」と説明します。そのうえで、判定日・合格線・本番の持ち主・止める条件の 4 点を後付けで書き、判定日に「本番へ / 条件つきで続ける / 畳む」の 3 択で決めると宣言します。畳む場合も理由を 1 行残せば、その PoC は次の設計の材料になります。宙づりを「判定が出た状態」に変えること自体が、立て直しの成果です。
足りるかどうかは、無料かどうかではなく、終わり方が書いてあるかで決まります。無料の PoC は始めやすい反面、続けても誰も痛くないので終わる理由がなく、PoC 止まりになりやすい構造を持っています。使うなら、無料期間の終了日をそのまま判定日にし、合格線と本番の持ち主を先に書いてください。それがあれば、無料期間は十分に役に立ちます。
「小さい本番」として組むなら、それはこの記事で言う PoC そのものです。飛ばすのではなく、PoC を本番の条件で組む、と考えてください。逆に、整えた環境の PoC を飛ばして、上限も確認点も無しに本番へ入れるのは薦めません。最初の 1 業務を、本番の入力・権限・確認点で、上限つきで動かし、判定日に決める──この形が、PoC と本番の間にある「PoC では動いたのに」を無くします。