雰囲気を伝えるだけで、数分で動くものが出てくる。あのデモは、素直にすごいと思います。
探索目的でなら自分も使います。何を作るべきかまだ固まっていない段階で、とりあえず形にして眺めてみる。手が動き出すまでの時間が明確に縮むので、あれは便利です。
ただ、業務システムの納品物としてそのまま使ったことは、一度もありません。
食わず嫌いではありません。持ち込もうとするたびに、具体的な場所で手が止まりました。この記事では、その手が止まる場所を5つ、できるだけ技術的な例とあわせて書きます。
デモを否定したいわけではありません。デモと業務システムでは、置かれている条件そのものが違う。その差分を言葉にしておきたい、という話です。
1. 仕様を持っている人が、自分ではない
デモでは、作る人が仕様の所有者を兼ねています。「こういうものが欲しい」が本人の頭の中にある。だから雰囲気を伝えるだけで話が進みます。
業務システムでは、仕様を持っているのは顧客であり、他部署であり、現場の担当者です。厄介なのは、その仕様が、まだ誰の頭の中にも存在しないケースが多いことです。
「一覧画面に検索機能をつけたい」という依頼だけで作らせると、こういう食い違いが起きます。
# 依頼した側の頭の中
「検索」で完全一致のつもりだった（コード番号のような一意な項目のイメージ）
# 出てきたもの
LIKE '%キーワード%' の部分一致検索
（一般的な「検索」の実装としては妥当。だから正しく動いているように見える）
どちらも技術的には正しいコードです。ずれているのは仕様の解釈のほうで、これはコードレビューでは見つかりません。依頼した本人が画面を触って初めて発覚します。
この段階では、正解かどうかを判定する基準がそもそも存在しないので、動くものを出しても評価ができません。
2. 更地ではなく、既存の上に建てる
デモはゼロから作ります。制約のない土地に、好きな工法で建てられます。
業務システムでその状況は、まずありません。既存の上に建てるので、合わせるべきものが山ほどあります。
-
テーブル定義とカラム命名の規則（日付は必ず
_ymdで終わる、論理削除フラグの名前が決まっている、など現場ごとの流儀） - 例外処理の方針（どの層で捕まえて、どこまで投げるか。ログに残す粒度）
- トランザクション境界の張り方
- 社内の共通ライブラリや独自フレームワーク（外部の一般的な書き方が通らない）
- 認証・認可の既存基盤（自前で書いてはいけない部分）
- リンタやフォーマッタの設定、レビューで指摘される暗黙のルール
規約を渡さずに作らせると、命名の時点でこうなります。
-- 提案されたカラム名（一般的な命名としては妥当）
created_at
updated_at
is_deleted
-- この現場の規約
created_ymd
updated_ymd
del_flg
どちらも技術者としては違和感のない命名です。ただしその現場の流儀とは無関係な動き方をします。合わせにいくと、結局ほとんど書き直しになります。しかも「一般的には正しいが、ここでは通らない」書き方が混ざるので、レビューで指摘するほうにも手間がかかります。
新規開発なら自由かというと、そうでもありません。二つ目の機能を作る時点で、もう「一つ目に合わせる」が発生します。 更地でいられる期間は、思っているより短いです。
3. 止まったとき、説明する義務がある
デモは落ちても誰も困りません。もう一度やればいい。
業務システムは違います。本番で止まれば、まず調べるところから始まります。手がかりはログです。
2026-08-21 03:12:07 ERROR [OrderService] Unexpected null
at OrderService.calculate(OrderService.java:88)
これだけでは「なぜnullが来たか」は分かりません。呼び出し元をたどり、どの条件でnullを許容する設計だったのかを追う必要があります。設計の意図が別に残っていれば数分で終わる調査が、コードだけを頼りに逆算すると数時間かかることもあります。
そのうえで、障害報告に書く項目はだいたい決まっています。
- 発生日時と検知の経緯
- 影響範囲（どの機能が、何件、どの顧客に）
- 直接の原因
- 暫定対応と、復旧の見込み時刻
- 恒久対応
- 再発防止策
このうち「直接の原因」から下は、中身を把握していないと一行も書けません。
そして、「AIが書いたので分かりません」は報告書に書けません。相手は顧客だったり、上司だったり、品質保証の部署だったりします。説明を求められるのは障害のときだけでもありません。レビュー、監査、引き継ぎ、どの場面でも**「なぜこの実装なのか」**は聞かれます。
自分で書いたコードなら、少なくともどこを見ればいいかの見当がつきます。中身を把握していないものを抱えたまま、時間に追われながら障害対応をする状況は、あまり経験したくないものです。動いているうちは、問題になりません。問題は、動かなくなったときに説明する立場に自分がいることです。
4. 半年後、別の人が触る
デモは、作った本人がその場で動かして終わります。
業務システムで作ったものは残ります。半年も経てば、たいてい別の人が触っています。異動もあれば、案件を離れることもあります。
このとき、git blame で分かるのは「誰が」「いつ」書いたかまでです。「なぜ」は出てきません。コミットメッセージが fix や update の一言だけだと、なおさらです。
- なぜこの条件が入っているのか
- なぜ別の方式を選ばなかったのか
- どこまでが仕様で、どこからが実装の都合か
これらがどこにも残っていないと、受け取った側はコードから仕様を逆算するしかありません。変数名やコメントの断片から意図を推測し、たいてい元の意図とはずれます。
雰囲気で作ったものからは、雰囲気しか受け取れません。作った本人の頭の中にあったはずのものが、コミット履歴にもコードにも書き出されていないからです。自分が引き継ぐ側だったときのことを思い出すと、これは他人事ではありません。
5. 必ず、変更が来る
そして、これが一番効いてきます。
デモは一度動けば終わりです。業務システムは、三ヶ月後に「この条件を追加してほしい」が来ます。来ないことは、まずありません。
そのとき効いてくるのが、最初に何を決めたのかが残っているかです。
例えば「ステータスは3種類」という前提で作ったものに、4つ目のステータスを追加してほしいと言われたとします。判定ロジックが if (status == A) { ... } else { ... } のような二分岐で散らばっていた場合、追加箇所を洗い出すだけで一苦労です。なぜ二分岐で足りると判断したのかが残っていれば、影響範囲はすぐ絞り込めます。残っていなければ、コードを一行ずつ読み解いて意図を推測するところから始まります。
一度作って終わりなら、中身が多少分からなくても構いません。ただ業務システムは、作った後のほうが圧倒的に長いです。初速で稼いだ時間は、二回目の変更でだいたい返済することになります。
これは、遅れているという話ではない
5つ並べてみると、共通点がはっきりします。
どれも、新しい技術についていけるかどうかとは無関係です。
仕様が固まっていないのも、既存システムがあるのも、説明を求められるのも、引き継がれるのも、変更が来るのも、AIが登場するずっと前から業務システムに付いていた条件です。
デモの世界には、この5つが最初から存在しません。だからあの速度が出ます。速くて当然です。乗れないのは、能力の差ではなく、置かれている条件が違うだけです。
では、どうしているか
AIを避けているわけではありません。設計もコードもテストも、かなりの部分でAIの手を借りています。
違うのは、渡すタイミングです。上の5つは、どれも後から効いてくるものでした。仕様、既存の流儀、説明責任、引き継ぎ、変更。これらが表面化するのは、たいてい作り始めてからずっと後です。
先に片付けてからAIに渡すと、出てくるものが変わります。現場の流儀を無視したコードは出てきませんし、半年後に誰も読めないコードも出てきません。
最初の一歩は速くありません。数分で動くものは出てこない。そこは正直に書いておきます。ただ、二回目の変更まで含めた合計では、こちらのほうが短く済んでいます。
補足しておくと、このやり方には新しい技術が一つも出てきません。 目新しいフレームワークも、話題のツールも、凝った構成も使っていません。人に話しても、たいてい拍子抜けされます。地味です。
それでも、この地味なやり方で案件をさばいてきましたし、バイブコーディングに乗れないことで困ったことは一度もありません。
この記事は「なぜ止まるのか」までの話です。実際に何をどの順番でやっているのかは、書き出したら長くなったので、note に4回のシリーズとして別にまとめてあります。興味のある方はどうぞ。