「AIで安く作る」ほど、運用費で高くつく理由

こんにちは、大平です。

AIで開発費が下がるなら、安く作って早く出せばいい。そう考えるのは自然ですし、方向として間違ってもいません。ただ、現場で見ていると、初期開発を安く抑えた結果、運用フェーズで高くつくケースが目に見えて増えています。

結論から言います。AIによって安くなったのは「作る費用」だけで、「直し続ける費用」は安くなっていません。 むしろ、作る速度が上がった分だけ、誰にも理解されていないコードが増え、運用費は以前より膨らみやすくなっています。本記事では、初期費用の安さがなぜ運用費に跳ね返るのか、そして総コストで判断するために経営として何を確認すべきかを、現場でAI駆動開発を回している立場から整理します。

システムの総コストは「作った後」に積み上がる

システムのコストは、作る費用だけではありません。長く使うほど、保守、改善、障害対応、問い合わせ対応の比率が上がっていきます。業務で使うシステムなら、リリース後の問い合わせと改善要望は必ず出ます。「必ず」です。ここに例外を見たことがありません。

にもかかわらず、開発予算は初期費用だけで組まれがちです。運用改善の枠をゼロで見積もったとき、リリース後に湧いてくる作業を誰が吸収するのか。現場の善意です。担当でもない誰かが、本来の業務の合間に問い合わせを捌き、動かなくなった箇所を調べる。善意にフリーライドする運用がいつまで持つかというと、その人が異動するか、疲れて辞めるまでです。破綻は時間の問題です。

もう一つ見落とされがちなのが、お金だけでなく時間の見積もりです。設計意図をナレッジとして残す時間、運用ルールを標準化する時間。これらは「開発作業」には見えないので、安い見積もりからは真っ先に削られます。しかし後述するとおり、削った分はあとで調査コストという形で、利子付きで返ってきます。

初期開発費は、総コストの入り口にすぎません。 あとで直せない、調査できない、担当者がいない状態になれば、安く作ったはずのシステムが総額ではいちばん高くつきます。

なぜ「AIで安く」が運用費に跳ね返るのか

理由は単純で、短期間で安く作ったものほど、設計意図や運用ルールが残らないからです。AIで生成したコードを十分に理解しないまま積み上げると、動いてはいるが誰も全体を説明できないシステムができあがります。この状態になると、機能追加のたびに「まず現状を調査する」工程が発生し、変更のたびに高くつくようになります。

これはAI以前からある話ですが、AIによって構造的に起きやすくなりました。以前は、実装の重さそのものが自然なブレーキでした。作る前に会議をし、仕様を固め、見積もりを出し、ようやく実装に入る。その遅さが、理解の追いつかないコードが積み上がる速度を抑えていたとも言えます。今は初期実装だけならすぐ形になります。「作れるから作る」「安いから作る」で進めば、コードが増える速度に組織の理解が追いつかないのは当然です。

もう一つの構造要因は、AIで見た目の進捗が出やすくなったことです。画面が次々にできあがるので、プロジェクトは順調に見える。その裏で、設計意図の記録、例外処理の検討、運用設計といった見えない仕事が過小評価されます。誰かが手を抜いているからではなく、見えるものと見えないものの生産速度の差が開いたために、悪意なく起きます。

AIは「書くコスト」を下げましたが、「理解するコスト」は下げていません。 そして運用費の正体は、この理解するコストです。コード量が増えるほど説明できない範囲が広がるなら、安く大量に作ることは、運用負債を安く大量に仕入れていることと同じです。

「画面が動く」と「事業で使える」の間にある距離

会議室で、AIで作ったデモが動いているとします。画面はきれいで、操作もできる。関係者の反応も悪くない。「もうほとんどできていますね」と言いたくなる気持ちは分かります。

しかし、この時点で確認できているのは、きれいな入力、想定通りの操作、限られたユーザー、短時間の確認という、かなり限定された条件だけです。その外側に、本番業務で本当に問題になる領域があります。権限、例外、データ移行、監査、問い合わせ、改善要望、障害対応。これらはデモの場では見えませんが、運用開始後には必ず表に出ます。本番データを入れた瞬間に例外が噴き出す。権限設計が足りず、運用開始前に作り直しになる。問い合わせ対応の担当が決まっておらず、作った本人がずっと呼ばれ続ける。どれも、コード量を増やしても解決しない問題です。

だから、初期費用の安さを評価する前に見るべきなのは、**「動いたか」ではなく「運用できるか」**です。動いたものを否定する必要はありません。動いたからこそ次の判断に進めます。ただしその場は祝勝会ではなく、本番に向けた棚卸しであるべきです。最初に決めるのは「どこまで作るか」だけではなく、「どこまで責任を持つか」「どこから先は作らないか」「何が確認できたら次に進むか」まで含めた判断です。

安く作ること自体は、悪ではない

誤解のないように言うと、安く速く作ること自体は悪くありません。使い捨ての検証、限定的な社内ツール、失敗しても影響が小さい領域なら、AIで安く作るのはむしろ正解です。検証の回転数はそのまま学習の速度になります。

問題は、この線引きをせずに、本番業務や顧客データに関わる領域まで同じノリで進めることです。そこで優先すべきは安さではなく、直し続けられることです。本当に安いのは、初期費用が低いシステムではなく、長期で見て変更コストが低いシステムです。

そして、低コストで作る場合ほど、記録を残すべきです。「予算が少ないからドキュメントは省く」という判断は、順序が逆です。なぜこの構成にしたのか、どこまでをAIに任せたのか、既知の制約は何か。この3点だけでも残っていれば、後から直す人の調査コストは大きく下がります。安く作るなら、未来の自分たちが読める最低限の地図を残してください。地図のない安普請が、いちばん高くつきます。

総コストで判断するためのチェックリスト

発注や着手の前に、最低限次の観点を確認しておくべきです。

この取り組みの目的は、売上増加、コスト削減、品質改善、学習のどれなのか
成功条件は、誰が見ても判断できる形で書かれているか
リリース後の運用責任者は、名前で決まっているか
AIが生成した成果物を、誰がレビューし、誰が説明責任を持つのか
失敗した場合の撤退条件やロールバック方法はあるか
初期開発費だけでなく、保守・改善・問い合わせ対応の予算があるか
外部に任せる範囲と、社内に残す判断が分かれているか

すべてを完璧に埋める必要はありません。重要なのは、未定の項目を「未定」として認識しておくことです。とくに運用責任者と運用予算が未定のまま初期費用の安さだけで進んだ案件は、ほぼ確実にこの記事で書いたコースをたどります。未定を見ないふりして進めると、後で必ず現場の負荷として返ってきます。

90日で「運用費が膨らまない体制」に整える

では、どこから手を付けるか。いきなり全社導入や本番リリースを狙う必要はありません。90日を3つに割るのが現実的です。

最初の30日は、現状把握に使います。既存の業務フロー、責任者、利用データ、外部サービス、そして手作業で吸収している例外を洗い出します。この段階では、無理に作り込まない方がいいです。作る前に、どこに判断の穴があるかを見ることが目的です。

次の30日で、小さな範囲で試します。対象部署を絞り、機能を絞り、失敗しても影響が限定される形で動かします。このとき、目的・成功条件・責任者・次の判断タイミングの4つを必ず決めてください。この4つが揃っていれば、小さい取り組みでも学習が残ります。逆に「何となく試しただけ」では、良かったのか悪かったのか判断できず、次につながりません。あわせて、設計意図・制約・運用ルールを最低限記録することをプロセスに入れます。

最後の30日は、継続運用に載せる準備です。担当者、レビュー手順、障害時の対応、改善要望の受付、そして運用予算の枠を決めます。ここまで決めて初めて、AIで作ったものが一過性のデモではなく、組織の仕組みになります。

発注側と開発側で、責任を分けて持つ

最後に、体制の話です。プロジェクトが揉めるときは、言葉の定義が揃っていないことが多いです。「完成」「リリース」「保守」「責任」といった言葉を、関係者が別々の意味で使っている。経営層にとっての完成は「顧客に見せられる状態」かもしれませんが、開発現場にとっての完成は「異常系や監視まで含めて運用できる状態」です。このズレを放置すると、どちらも悪くないのに衝突します。AIで作る速度が上がった分、言葉のズレは以前より大量の手戻りに化けます。早い段階で、完成とは何か、誰が承認するのか、どこから保守フェーズなのかを言葉にしてください。

そのうえで、分担です。発注側が持つべきなのは、業務の目的、優先順位、責任者の決定です。ここは外部に丸投げできません。開発会社や顧問は整理を手伝えますが、最終的に何を優先し、どのリスクを受け入れるかは発注側の判断です。開発側が持つべきなのは、技術的な実現方法、リスクの提示、選択肢の整理です。ただ作るだけでなく、「この進め方だとどこが危ないのか」「別案にすると何を失うのか」を説明する責任があります。

この分担が明確なら、AIは強力な道具になります。曖昧なままAIだけ入れると、誰の判断なのか分からない成果物が高速に量産されます。AIの出力は速いですが、責任の所在まで自動で整理してくれるわけではありません。