PoCとは？実証実験では出ない0.1%が、本番で最後に残る

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

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

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

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

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

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

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

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

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

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

動きました。

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

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

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

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

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

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

② そのとおりに本番へ載せて、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%を先に考えないという点では、僕も人のことは言えませんでした。

以上です。