デモは完璧に動いた。社内で見せたら「いいね、これ本番でも使おう」と言われた。——そこから3週間、なぜか公開できないまま止まっている。
AIコーディングツール(Claude Code:Pro $20/月・Max $100〜200/月、Codex CLI:ChatGPT Plus $20/月〜)を使う方は多いはず。それで試作(PoC)まで作れる方なら、覚えがあるかもしれません。
「動くデモ」と「止まらず回り続けるシステム」の間には、見た目以上に深い谷があります。「最後の20%が9割の労力」というやつです。この記事では、その谷を分解して「どこで詰まるのか」「どう越えるか」を整理します。
なお本記事は、すでに AI で PoC を自分で組める段階の方を読者に想定しています。まだツール選びの段階という方は、AIコーディングツールの比較・選び方はこちらから読むと、この先の本番化の話が立体的に見えてきます。
まず確認:あなたの作ったものは「PoC」か「本番」か
同じ「AIで作った動くもの」でも、求められる水準はまるで違います。
| あなたの作ったものの段階 | いまの状態 |
|---|---|
| 自分の手元で一度動けばいい試作 | これは PoC。動いた時点でゴール、本番化は不要 |
| 数人に見せる社内デモ | PoC の延長。まだ本番ではない |
| 毎日誰かが使い、止まると業務が困る | ここから先が本番。求められる水準が一段上がる |
PoC のゴールは「実現できると示すこと」、本番のゴールは「自分が見ていない時間も、変なデータが来ても、止まらず動き続けること」。この二つは、似て非なる仕事です。
PoCと本番の間にある、6つの壁
「動くものができた」あと、本番化のどこで詰まるのか。よくあるつまずきを6つに分けて見ていきます。
| 壁 | PoCでは | 本番で問われること |
|---|---|---|
| 1. データ整合性 | きれいなデータでしか動かない | 空欄・全角半角混在・表記ゆれでも止まらず、間違った答えを静かに出し続けない設計か |
| 2. 監視 | 自分が見ている前で動く | 夜間バッチが静かに失敗しても、翌朝までに気づける仕組みがあるか |
| 3. 障害対応 | 落ちても自分がその場で直す | ログが残り、テストがあり、安全な手順で復旧できるか |
| 4. 認証・権限 | ログイン不要・自分専用 | 誰が何を見て・編集できるかの線引きがあるか(放置すると情報漏洩の入り口になる) |
| 5. スケール | 10件なら一瞬 | 1万件でも遅くならない設計か(並列処理の組み直しで85%の高速化を実現した実例あり) |
| 6. 引き継ぎ | 作った本人が動かせれば十分 | 本人が休んでも、ドキュメントと手順だけで誰かが対処できるか |
PoC を作る速度と本番を運用する速度は別のスキルです。前者は AI が得意ですが、後者は「壊れる前提の設計」という地味な準備の上に成り立ちます。
なぜ「最後の20%」がこんなに重いのか
これは能力の問題ではありません。PoC が相手にするのは「理想の条件」、本番が相手にするのは「現実の条件」——この違いが、最後の20%を重くしています。
| 観点 | PoC(動くデモ) | 本番(業務システム) |
|---|---|---|
| 入力データ | きれいな想定データ | 汚れた現実のデータ |
| 稼働時間 | 見ている前だけ | 24時間・無人でも |
| 利用者 | 自分だけ | 複数人・権限分け |
| 障害時 | その場で気づく | 通知・復旧の仕組みが要る |
| 件数 | 少数 | 増えても耐える設計 |
| 運用者 | 作った本人 | 本人がいなくても回る |
AI は左の列を爆速で作りますが、右の列への昇格は設計判断が中心になります。「本番化して」と頼んでも、一発では越えられないことが多いんです。
ツールの使い分けに興味が出てきたら、Claude CodeとCodexの比較も参考になります。
「最後の20%」を越えると、効果が一気に出る
逆に言えば、この谷を越えて本番に乗せ切ると、PoC の手前で止まっていた効果が一気に表に出てきます。
たとえば入退室ログと人事システムを自動でつなぐ仕組みの案件では、異常データでも落ちない・夜間に無人で動く・壊れたら気づける、というところまで作り切りました。日次の集計作業は 2時間/日 → 5分/日(96%削減) になりました。月3件あった転記ミスも 0件(100%解消) です。
工数集計の自動化で月次集計を 90%自動化 した案件、共有リンク作成の自動化で 月17時間 が浮いた案件もあります。いずれも本番に乗せ切ったからこその実測値です。
技術者向け:PoCを「本番に乗せる」ときに増える論点
| 観点 | PoC(動くデモ) | 本番に乗せた状態 |
|---|---|---|
| 入力検証 | ハッピーパスのみ | 異常系・境界値の網羅 |
| 監視 | なし | 失敗を能動的に通知 |
| ログ | なし/print頼り | 構造化ログ+追跡可能性 |
| 認証・権限 | なし/簡易 | 利用者ごとの権限分離 |
| データ整合性 | 楽観的に書き込み | 重複・競合・冪等性の考慮 |
| 性能 | 少数データで確認 | 並列化・件数増加への耐性 |
| 引き継ぎ | 本人の記憶 | ドキュメント・運用手順 |
AI は各項目の「実装」は手伝ってくれますが、「どこまでやるべきかの線引き」と「壊れたときの責任分界」は人間の設計判断として残ります。
まとめ:PoCで止めず、本番に乗せ切る
| 段階 | ゴール | 必要なこと |
|---|---|---|
| PoC・試作 | 実現できると示す | AIで素早く動くものを作る |
| 本番への昇格 | 止まらず回り続ける | 6つの壁を埋める |
| 本番運用 | 価値を出し続ける | 壊れても気づき、本人がいなくても回る |
「AI で PoC は作れる」は、もう揺るがない事実です。だからこそ、PoC が動いた段階で満足せず、「本番に乗せるなら、あと何が要るか」まで一度想像してみる。それだけで、本番化のどこで詰まるかが見えてきます(動くデモのまま塩漬けにするのは、意外とよくある落とし穴です)。
playpark は Web制作から業務改善、SaaS開発までを同じチームで対応しています。自社でもシフト管理のサービス(Shift Bud)を開発・運営していて、自分たちでも本番を回し続けている当事者です。AIコーディングツールを日常的に使っているからこそ、「この PoC はあとここを固めれば本番に乗りますよ」の線引きも率直にお伝えできます。
「うちのこの PoC、このまま本番に乗せていいのか」——その見極めに迷ったら、まずは現状を一緒に整理するところから始めませんか。具体的な相談先はAI実装支援からどうぞ。



