PoCは、よくできていました。精度も出た。デモを見た役員も感心していた。文句のつけようがなかった。
そして、止まりました。
半年後にそのPoCがどうなったかを聞くと、「一応、動いてはいるんですけど」という返事が返ってきます。誰も使っていない、という意味です。よく聞く言い回しだと思います。
MITの研究プロジェクト「NANDA」が2025年に公表したレポートによれば、生成AIが業務フローに組み込まれてスケールしている企業は全体の5%にとどまります。裏返せば、残りは試したところで止まっている。
The GenAI Divide: STATE OF AI IN BUSINESS 2025（MIT Project NANDA, 2025）
https://www.artificialintelligence-news.com/wp-content/uploads/2025/08/ai_report_2025.pdf
この記事では、PoCが実装に進まない構造を分解してみます。技術の問題ではありません。始める前の合意の仕方に、原因があると思っています。
目次
- 「作りたい」が「困っている」を追い越す瞬間
- 合格条件を、始める前に文章にする
- 実装に進まない三つの理由
- 測るべきは精度ではない
- 期間と規模は、どう決めるか
- 誰を巻き込むかで、半分決まる
- 失敗したPoCのほうが価値があることもある
- 北海道では、年度がPoCを殺す
- 最後に
1. 「作りたい」が「困っている」を追い越す瞬間
PoCが迷子になるときには、だいたい共通のきっかけがあります。
最初は「困っている」から始まります。月末の処理が終わらない。属人化していて怖い。問い合わせ対応に時間が取られる。ここまでは健全です。
ところが検討が進むと、途中で主語が入れ替わります。ここが境目です。「せっかくだからエージェントで」「他社がやっているマルチモーダルも試したい」「どうせなら社内チャットと連携させたい」。
この瞬間に、PoCの目的は困りごとを解くことから新しい技術を試すことに移ります。そして技術を試すことが目的になったPoCは、技術的に成功した時点でゴールに到達してしまう。実装に進む理由が、どこにもありません。
見分け方があります。その説明を、情報システム部門ではなく現場の担当者にしてみてください。担当者が「それ、いつ使えるようになりますか」と聞いてきたら、困りごとから始まっている証拠です。「へえ、すごいですね」で終わったら、技術が主語になっています。
後者だった場合は、PoCを進める前に一度戻ったほうがいい。進めても、使われません。
2. 合格条件を、始める前に文章にする
次に多いのが、合格条件を決めないまま始めるケースです。
「まずやってみて、結果を見て判断しましょう」。合理的に聞こえます。しかし実際には、結果が出てから判断基準を作ることになるため、同じ数字を見ながら評価が割れ、議論がまとまりません。精度85%という結果に対して、十分だと言う人とまだ足りないと言う人が出て、決まらない。
やるべきことは単純です。始める前に合格条件を文章にして、関係者が署名する。署名は比喩ですが、それくらいの重みで扱う価値があります。
書くのは三つです。
定量条件。「現在70分かかっている作業が、30分以内になる」「人の確認が必要な件数が、全体の2割以下に収まる」。
定性条件。「担当者が、この仕組みを使い続けたいと言う」。これは曖昧に見えますが外せません。数値をクリアしても現場が嫌がる仕組みは定着しないからです。
そして、不合格だった場合の扱い。「条件を満たさなかった場合は、実装せず、理由を文書に残して終了する」。これを先に決めておくと、PoCが惰性で延命するのを防げます。
三つが書かれていれば、PoCの終わりに議論は起きません。条件に照らして、進むか止めるかを決めるだけです。
3. 実装に進まない三つの理由
合格条件を満たしたのに実装に進まない、というケースもあります。理由はほぼ三つに絞られます。
ひとつは、予算の桁が変わることを誰も計算していなかった、という理由。PoCは安く済みます。限られたデータで限られた範囲を動かすだけだからです。本番は違う。既存システムとの接続、権限管理、エラー発生時の運用設計、利用料の増加といった項目が一気に積み上がり、PoCの3倍から10倍の費用がかかることも珍しくありません。この見積りを事前に出しておかないと、結果が良かった瞬間に「そんな予算はない」で止まります。企画書には、本番導入の概算を併記しておくべきです。
ふたつめは、持ち主が決まっていなかった、という理由。PoCは情報システム部門か外部ベンダーが主導することが多く、本番運用は業務部門が持ちます。この引き渡しが設計されていないと、PoCが終わった時点で宙に浮く。業務部門からすれば、自分たちが関わっていないものを引き取るのは怖い。だから「もう少し検証が必要では」と言います。そして時間が経ち、関心が薄れていく。誰も反対していないのに、止まります。
みっつめは、現状を測っていなかった、という理由。PoCで「30分で処理できた」という結果が出たとして、現状が何分なのかを誰も知らない。これでは比較になりません。測れないものは、説明もできない。現状の測定はPoCを始める前にやる作業で、後からでは測れません。慣れてしまうからです。
4. 測るべきは精度ではない
報告書は、たいてい精度の話で埋まります。正答率が何%だった、という記述です。
精度は重要です。ただ、それだけでは実装の判断ができません。見るべきものが、もう二つあります。
ひとつは、人の確認工数。精度95%でも、どの5%が外れているか分からなければ人は全件見ます。それでは時間は浮きません。逆に精度85%でも、AIが「この件は自信がない」と申告してくれれば、人はその15%だけ見ればいい。
もうひとつは、想定外の入力に対する振る舞い。PoCではきれいなデータを使います。本番には汚れたデータが来る。読めないスキャン、書式の違う帳票、半分空欄の申請書。これらが来たときに止まるのか、推測で埋めるのか。ここを見ずに実装すると、運用開始から2週間で信用を失います。一度失うと、戻すのに1年かかる。
前出のUCバークレーらの調査では、本番環境でエージェントを運用するうえで最大の課題は信頼性であり、その背景に「正しさを保証し評価することの難しさ」があると整理されています。また、75%のチームが正式なベンチマークを持たないまま運用しているとも報告されています。
Measuring Agents in Production（arXiv, 2025）
https://arxiv.org/html/2512.04123v1
最先端のチームですらそうなのですから、中小企業に厳密な評価基盤を求めるのは現実的ではありません。ただ、実際に起きた失敗例を20件集めて手元に置いておくくらいのことは、誰にでもできます。設定を変えたときにその20件を通してみる。それだけで、壊していないかの確認はできます。
5. 期間と規模は、どう決めるか
合格条件の次に決めるのが、期間と規模です。ここも最初に決めておかないと伸びます。
期間は6〜8週間。これより短いと想定外の入力に当たる前に終わってしまいますし、長く取りすぎると途中で本業が忙しくなって自然消滅します。
内訳はこうです。最初の2週間で現状を測り、対象データを集める。次の2〜3週間で動くものを作る。残りの2〜3週間で、実際の業務と並行して流してみる。
この最後の並行期間が肝心です。作ったものを会議室で見るのと、日常業務の中で実際に使ってみるのとでは、見えてくるものがまるで違います。並行期間を取らない検証は、デモ止まりで終わります。
規模は、1業務・1部署・3人まで。広げたくなります。我慢したほうがいい。関係者が増えるほど調整に時間を取られ、本題に使える時間が減ります。扱うデータの量も絞ります。過去1年分でなく直近3か月分。全拠点でなく1拠点。狭くしておくと、失敗したときに原因の切り分けが簡単になります。
費用の目安も持っておきます。社内工数を含めて、本番導入の想定額の2割程度を上限にするのがひとつの目安です。これを超えるなら、検証という名目をやめて本番を小さく始めたほうが筋がいい。
6. 誰を巻き込むかで、半分決まる
成否は参加者で半分決まります。入れるべき人と、入れなくていい人があります。
必ず入れるのは、その業務を毎日やっている担当者です。管理職ではありません。手を動かしている人を最低1人。この人が「使える」と言わない限り、本番には進みません。逆に言えば、この人が最初から参加していれば、PoCの終わりに「現場が納得していない」という理由で止まることはなくなります。
決裁者は、終わりに呼ぶのではなく途中で巻き込みます。結果を最後にまとめて報告する形だと、そこで初めて疑問が出て追加検証になる。中間で一度、動いているものを見てもらってください。15分で構いません。この15分が、最後の数週間を節約します。
入れなくていいのは、念のためで呼ばれる関係部署です。本番導入のときには必要ですが、PoCの段階では参加者が増えるぶん意思決定が遅くなるだけになりがちです。
外部の使い方も一応書いておくと、自社だけでPoCを回すとうまくいかなかったときに技術の限界なのか使い方が悪いのかの切り分けができません。ここだけは経験のある人に見てもらう価値があります。常駐である必要はなく、週1回30分で足ります。
報告書の型も決めておくと楽です。A4で2枚、項目は六つ。やったこと、現状の数値、結果の数値、うまくいかなかったケース、本番にするなら何が要るか、進む／進まないの判定とその理由。このうち社内で最も読まれるのは四つめでした。意外に思われるかもしれませんが、決裁する側がいちばん知りたいのは「どこで壊れるか」だからです。壊れ方が分かっていれば、投資の判断ができます。
逆に書かないほうがいいのは技術構成の詳細です。どのモデルを使い、どう連携させたか。読む人はほとんどいませんし、どうせ半年で変わります。
7. 失敗したPoCのほうが価値があることもある
ここまで失敗の話をしてきましたが、ひとつ付け加えておきます。
合格条件を満たさなかったPoCは、失敗ではありません。「この業務は、いまの技術では割に合わない」という判断材料が手に入ったということです。これは、やってみないと分かりませんでした。
むしろ問題なのは、合格も不合格も判定されないまま静かにフェードアウトするPoCです。何も学習されず、半年後に別の部署が同じことを始めます。
だから、終わったPoCは必ず文書にして残してください。やったこと、結果、なぜ実装しなかったのか。A4で1枚あれば十分です。この1枚が、次の検討を半分の時間にします。
8. 北海道では、年度がPoCを殺す
道内でPoCを見ていると、本州とは少し違う力学が働いているのを感じます。補助金の年度です。
道内でAI活用に取り組む企業の多くが、何らかの補助制度を使います。これ自体は良いことです。ただ、補助の対象期間が年度で区切られているため、年度内に何かを完成させることが目的化しやすい。
結果、こういうことが起きます。年度末に向けてPoCを完成させる。報告書を提出する。補助金が確定する。そして年度が変わると誰も触らなくなる。本番運用に向けた予算が、次年度の計画に入っていないからです。
函館のある食品卸では、受発注のFAXを読み取る仕組みをPoCまで作ったものの、年度末に報告書を出したところで止まっていました。翌年、改めて「どの業務を、誰が、いつまで持つのか」から整理し直して本番に進めています。1年を失ったとも言えますが、そこで止めずに再開した判断は正しかったと思っています。
北海道でAI活用を進めるなら、補助の年度と業務の定着にかかる期間は別物だと最初に割り切っておくことをお勧めします。定着には、どんなに早くても半年、現実には1年かかる。年度内に終わるのはPoCまでです。本番の予算と持ち主を、PoCの企画段階で次年度計画に書き込んでおく。この一手間が、年度の壁を越えさせます。
9. 最後に
PoCで止まる原因を並べてきましたが、根っこは一つだと思っています。PoCを「技術が動くかどうかの確認」だと考えていることです。
技術が動くかどうかは、いまやたいてい動きます。確認すべきは、そこではありません。この業務に組み込んだときに人の手間が本当に減るのか。現場が使い続けるのか。次年度の予算と持ち主があるのか。
これらはすべて、PoCを始める前に設計できることです。技術検証の前に、合意の設計をする。それだけです。
冒頭の「一応、動いてはいるんですけど」を、何度か聞きました。あの言い方には、作った側の無念さと、使わなかった側の後ろめたさが両方入っている気がします。止まっているPoCが社内にあるなら、捨てる前に一度、合格条件を書いてみてください。書いてみたら実は合格していた、ということも、わりとあります。
Blakistonでは、北海道の企業のAI活用について、業務の棚卸しから定着までのご相談を承っています。
.png&w=3840&q=75)
.png&w=3840&q=75)