AIで動くものは作れた、でも本番に乗らない — PoC止まりを超える「最後の20%」の正体

デモは完璧に動いた。社内で見せたら「いいね、これ本番でも使おう」と言われた。——そこから3週間、なぜか公開できないまま止まっている。

AIコーディングツール（Claude Code（Pro $20/月、Max $100〜200/月）や、ChatGPT のサブスク（Plus $20/月〜）に紐づく Codex CLI など、自然言語で開発を進められるツール）で試作（PoC＝Proof of Concept、「これ実現できる？」を確かめる動くサンプル）まで自力で作れる方なら、この「あと一歩が越えられない」感覚に覚えがあるかもしれません。情シスの方も、技術に明るい経営者の方も、いまや AI に指示すれば「動くもの」はその日のうちに手元に現れます。

デモが動くのは見た。で、それ本番でも同じように動くの？——問題は、そこから先です。「動くデモ」と「毎日の業務で止まらず回り続けるシステム」の間には、見た目以上に深い谷がある。世間でよく言われる「最後の20%が9割の労力」というやつが、ここで牙をむきます。この記事では、その谷——PoC から本番化までに立ちはだかる壁を一つずつ分解して、「どこで詰まるのか」「どう越えるか」を、あなた自身が見通せるように整理します。

なお本記事は、すでに AI で PoC を自分で組める段階の方を読者に想定しています。まだツール選びの段階という方は、AIコーディングツールの比較・選び方はこちらから読むと、この先の本番化の話が立体的に見えてきます。

まず確認：あなたの作ったものは「PoC」か「本番」か

同じ「AIで作った動くもの」でも、求められる水準はまるで違います。最初にここを切り分けると、判断がぐっと楽になります。

あなたの作ったものの段階	いまの状態
自分の手元で一度動けばいい試作	これは PoC。動いた時点でゴール、本番化は不要
数人に見せる社内デモ	PoC の延長。まだ本番ではない
毎日誰かが使い、止まると業務が困る	ここから先が本番。求められる水準が一段上がる

ざっくり言うと、PoC のゴールは「実現できると示すこと」、本番のゴールは「自分が見ていない時間も、変なデータが来ても、止まらず動き続けること」。この二つは、似て非なる仕事です。PoC が動いたことと、本番に乗ることは、地続きに見えて実は段差がある——まずこの前提を共有させてください。

PoCと本番の間にある、6つの壁

「動くものができた」あと、本番化のどこで詰まるのか。よくあるつまずきを6つに分けて見ていきます。これがいわゆる「最後の20%」の中身です。

1. データ整合性：きれいなデータでしか動かない

PoC は「正しいデータ」で動かします。でも本番の業務データは、いつだって想定外を含んでいます。空欄、全角と半角の混在、想定外の桁数、文字化け、同じ意味なのに表記が違う名前——。

デモでは綺麗に通った処理が、本番データの一行目で止まる。しかもタチが悪いのは、止まらずに「間違った答え」を静かに出し続けるケースです。集計がずれていることに、月末になって気づく。AI は「動くもの」を速く作りますが、「現実の汚れたデータでも正しい答えを出し続けるもの」は、設計の話になってきます。

2. 監視：止まったことに、誰も気づけない

PoC は自分が見ている前で動かすので、エラーが出れば即わかります。でも本番は違う。夜間に自動で動くバッチ、誰かが裏で叩く処理——これらが静かに失敗したとき、気づく仕組みがなければ、翌朝出社するまで（あるいは取引先からの電話まで）誰も知りません。

「動いているはず」と「動いていることを確認できる」の間には、大きな差があります。あなたの作ったツールが、もし今夜こっそり止まったとして、明日の朝まで誰も気づかない——そんな心配、ありませんか？　ここに不安が残るなら、それはごく自然なことです。本番運用とは、ある意味で「壊れたら自分にちゃんと知らせてくれる」状態を作る仕事でもあるんですよね。

3. 障害対応：落ちたとき、原因にたどり着けない

いざ止まったとき、問われるのは「なぜ止まったのか」を追える状態になっているか、です。

• エラーが出ても、どこで何が起きたかの記録（ログ）が残っていない（手がかりゼロから犯人探し）
• 直そうにも、テストがないので「直したつもりが別の場所を壊す」（モグラ叩きの始まり）
• そもそも本番環境にどう手を入れれば安全なのか、手順が決まっていない

PoC を作る速度と、障害から復旧する速度は、別のスキルです。前者は AI が得意ですが、後者は「壊れることを前提に設計しておく」という、少し地味な準備の上に成り立ちます。

4. 認証・権限：誰が使っていいのか、決まっていない

自分専用の PoC なら、ログインも権限分けも要りません。でも複数人で使う本番ツールに昇格した瞬間、「誰がアクセスできるのか」「誰が何を編集・閲覧できるのか」を決める必要が出てきます。

• 部署の全員が、見せたくないデータまで見られてしまう
• 退職した人のアクセスが、いつまでも有効なまま残る
• 個人情報や取引先データを、無防備に置いてしまう

ここを後回しにすると、便利なツールが「情報漏洩の入り口」に化けかねません。動かすことより、誰に開くかの線引きのほうが、本番では重い判断になることもあります。

5. スケール：件数が増えた瞬間に遅くなる

PoC は少ないデータで動かすので、速度は気になりません。問題は本番で件数が増えたとき。10件なら一瞬だった処理が、1万件になると数十分かかる、あるいはタイムアウトで落ちる——これは「あるある」です。

たとえば外部サービスと連携する処理を一件ずつ順番に呼んでいると、件数に比例して遅くなります。これを並列で処理する設計に変えるだけで、体感が大きく変わることがあります（実際の案件で、こうした処理の組み直しで 85%の高速化を実現したことがあります。いずれも実際の業務での計測値です）。PoC では見えない「量の壁」が、本番では効いてきます。

6. 引き継ぎ：作った本人しか、運用できない

本番化の最後の壁が、これです。AI に指示して作ったコードは、書いた本人ですら数ヶ月後には中身を忘れています。ましてや「どう動かすか」「壊れたらどうするか」が本人の頭の中だけにあると、その人が休んだ日に限ってツールが止まり、誰も対処できない。

PoC は「作った本人が動かせれば十分」ですが、本番は「作った本人がいなくても回る」ことが求められます。属人化を防ぐドキュメントや手順は、動くものを作る作業とはまた別の一手間なんですよね。

なぜ「最後の20%」がこんなに重いのか

ここで強調したいのは、これは能力の問題ではない、ということです。AI で PoC を組めるようになったのは、紛れもない進歩です。ただ、PoC が相手にするのは「理想の条件」、本番が相手にするのは「現実の条件」——この違いが、最後の20%を重くしています。

観点	PoC（動くデモ）	本番（業務システム）
入力データ	きれいな想定データ	汚れた現実のデータ
稼働時間	見ている前だけ	24時間・無人でも
利用者	自分だけ	複数人・権限分け
障害時	その場で気づく	通知・復旧の仕組みが要る
件数	少数	増えても耐える設計
運用者	作った本人	本人がいなくても回る

AI は左の列（動くもの）を爆速で作ってくれます。難しいのは右の列への昇格で、ここは「何をどこまでやるべきか」という設計判断が中心になる。だから、AI に「本番化して」と頼んでも、一発では越えられないことが多いんです。

ツールの使い分けや、複数ツールを併用するときの段取りに興味が出てきたら、Claude CodeとCodexの比較も、本番化を見据えた選び方の参考になります。

「最後の20%」を越えると、効果が一気に出る

逆に言えば、この谷を越えて本番に乗せ切ると、PoC の手前で止まっていた効果が一気に表に出てきます。

たとえば入退室ログと人事システムを自動でつなぐ仕組み（システム同士を自動でデータ連携させる仕組み）を、異常なデータでも落ちない・夜間に無人で動く・壊れたら気づける、というところまで作り切った実際の導入案件では、日次の集計作業が 2時間/日 → 5分/日（96%削減）——毎朝の2時間が、コーヒーを淹れる間に終わる作業に変わりました。月3件あった転記ミスも 0件（100%解消） になり、「あの数字、合ってる？」と差し戻される気まずさごと消えています。

工数集計の自動化では、月次の集計を 90%自動化した案件、共有リンク作成の自動化で 月17時間が浮いた案件もあります（まる二日分の手作業が返ってくる計算です）。これらはどれも「デモが動いた」時点ではなく、汚れたデータ・無人稼働・障害時の備えまで含めて本番に乗せ切ったからこそ出た数字です。いずれも実際の案件での計測値です。

逆に、ここを設計しないまま本番に乗せると、便利なはずのツールが「いつ止まるかわからない不安の種」になりかねません。価値が生まれるのは、PoC が動いた瞬間ではなく、本番で回り続けたその先にあります。

playpark の場合、Web制作から業務改善、SaaS開発までを同じチームで対応していて、自社でもシフト管理のサービス（Shift Bud）を開発・運営しています。つまり、自分たちでも本番を回し続けている当事者です。AIコーディングツールを日常的に使っているからこそ、「この PoC はあとここを固めれば本番に乗りますよ」「この壁は一緒に越えましょう」の線引きも、率直にお伝えできます。法人として、作って終わりではなく、本番に乗せて回し続けるところまで責任を持って伴走できます。

技術者向け：PoCを「本番に乗せる」ときに増える論点

「動くもの」から「運用に耐える業務システム」への昇格でよく追加される観点：

観点	PoC（動くデモ）	本番に乗せた状態
入力検証	ハッピーパスのみ	異常系・境界値の網羅
監視	なし	失敗を能動的に通知
ログ	なし／print頼り	構造化ログ＋追跡可能性
認証・権限	なし／簡易	利用者ごとの権限分離
データ整合性	楽観的に書き込み	重複・競合・冪等性の考慮
性能	少数データで確認	並列化・件数増加への耐性
引き継ぎ	本人の記憶	ドキュメント・運用手順

AI は各項目の「実装」は十分に手伝ってくれます。難しいのは「どこまでやるべきかの線引き」と「壊れたときの責任分界」で、これは人間の設計判断として残ります。PoC を作るプロンプトと、本番化を設計する判断は、別物として分けて考えると見通しが良くなります。

まとめ：PoCで止めず、本番に乗せ切る

整理すると、こういうことです。

段階	ゴール	必要なこと
PoC・試作	実現できると示す	AIで素早く動くものを作る
本番への昇格	止まらず回り続ける	6つの壁（データ整合性・監視・障害対応・認証・スケール・引き継ぎ）を埋める
本番運用	価値を出し続ける	壊れても気づき、本人がいなくても回る

「AI で PoC は作れる」は、もう揺るがない事実です。だからこそ、PoC が動いた段階で満足せず、「これを本番に乗せるなら、あと何が要るか」まで一度想像してみる——これだけで、本番化のどこで詰まるかがかなり見えてきます。作れる領域はどんどん作って、最後の20%でつまずきそうな壁だけ、本番を回し切れる相手を巻き込む。その見極めができると、AI で作った PoC が「動いただけのデモ」で終わらず、ちゃんと事業に効くものになります。

「うちのこの PoC、このまま本番に乗せていいのか、それともどこを固めれば安全に動かせるのか」——その見極めに迷ったら、まずは現状を一緒に整理するところから始めませんか。何が本番化のボトルネックになっているか、率直にお伝えします。具体的な相談先はplaypark のソリューション一覧からどうぞ。デモのまま塩漬けにしてしまう前に、お気軽にご相談ください。