なぜ「安さ」に飛びつくと危険なのか
公開日：2026年7月13日｜カテゴリ：システム開発・内製化・運用保守
「AIを使うので、従来の半額で開発できます」——この提案に、あなたの会社は今年、必ず出会う。
そして5年後、こうなっている会社が出てくる。システムは動いているが、中身を理解している人が社内にも開発会社にもいない。小さな改修の見積もりが異常に高い。担当エンジニアは退職済み。作り直すしかないと言われる——。
ソフトウェアの費用は「作って終わり」ではない。運用保守費は開発費の15〜25%/年が相場——つまり10年使えば、開発費の1.5〜2.5倍を保守に払う。安い開発費に飛びつく判断は、この「氷山の下」を見ていない。
誤解しないでほしい。バイブコーディング（AIによる開発）を否定する記事ではない。実装工数87%減という実測もある本物の技術革新だ。問題は「安さ」だけを見て、誰が・どうやって・何年運用するのかを考えずに発注することにある。
本記事では、行動経済学・認知科学・成功者の思考パターンをもとに、AI時代の自社ソフト開発——内製・外注の使い分け、バイブコーディングのメリット・デメリット、そして長く運用するためのAI活用法——を具体的に解説する。
第1章：なぜ「安さ」に飛びつくと危険なのか——行動経済学の答え
現在バイアス：目の前の300万円と、5年後の1,500万円
行動経済学の「現在バイアス」——人は目先の利益・損失を将来のそれより過大評価する——が、開発発注の失敗の根源だ。
A社「従来型で800万円、ドキュメント完備・保守体制あり」とB社「AIで300万円、詳細は納品後に」を比べたとき、脳は500万円の差額だけを見る。だが本当に比べるべきはTCO（総保有コスト）だ。ドキュメントのないAI生成コードは、改修のたびに「解読作業」から始まる。10年間の保守費・改修費・作り直しリスクまで含めると、B社の総額がA社を超えるケースは珍しくない。
理解の錯覚：「動いている」ことと「理解している」ことは別
認知科学の「説明深度の錯覚（Illusion of Explanatory Depth）」——人は仕組みを説明できないものでも「理解している」と錯覚する——が、AI生成コードで深刻化している。
AIは動くコードを高速に量産する。だが「動く」ことに安心して中身の理解を省略すると、「誰も説明できないシステム」が完成する。従来の開発では、コードを書く過程で人間の頭に仕様の理解が蓄積された。AI開発ではこの蓄積が自動では起きない。意識的に「理解を残す仕組み」を作らない限り、システムはブラックボックス化する。これがAI時代特有の技術的負債だ。
「安い開発会社」が保守で問題を起こす構造
「AIで安く」を売りにする会社の一部は、こういう構造で動いている。AIで高速にコードを生成し、動作確認して納品する。テスト・ドキュメント・設計の整理は「工数削減」の名の下に省かれる。AI生成コードには一定割合で脆弱性が混入する（実測で19〜35.8%のコードに欠陥という調査もある）が、レビューが薄いため残存する。
納品直後は問題ない。問題は運用フェーズで噴出する。バグ修正を依頼すると「調査に時間がかかる」と高額請求。担当者が変わると誰も構造を知らない。改修のたびにデグレード（直したら別が壊れる）が起きる——安さの正体は「後工程へのコスト先送り」なのだ。
第2章：内製か外注か——「継続雇用」まで含めて考える
「自社の人員だけで開発・運用できれば理想」——その通りだ。だが内製には「作れる人を雇い続けられるか」という継続雇用の問題が付きまとう。AI時代の内製・外注の判断材料を整理する。
図1｜内製 vs 外注 AI時代の判断材料
| 観点 | 内製（自社開発） | 外注（開発会社） |
|---|---|---|
| 業務理解・改修速度 | ◎ 強い。業務を知る人が直すので速い。AIで非エンジニア社員でも小改修が可能になった | △ 遅い。見積もり→承認→対応のサイクル。業務説明のコストが毎回発生 |
| 継続雇用リスク | ✗ 最大の弱点。担当者の退職＝システムの死。IT人材の採用・定着は年々困難。1人に依存する内製は外注より危険 | ◎ 会社対会社。個人の退職リスクは開発会社側が吸収。ただし会社ごと撤退・倒産のリスクは残る |
| コスト構造 | 人件費は固定費化。開発が少ない時期も発生。ただしAIで1人あたりの生産性が数倍になり、少人数内製の現実味が増した | 変動費として扱える。ただし保守費15〜25%/年＋改修費が長期的に積み上がる |
| 知識の所在 | 社内に蓄積される——が、文書化しなければ属人化する。「現場任せ」のAI活用は知見が個人に固着し、退職で消える | 開発会社側に蓄積。ソースコード・設計書・権利の帰属を契約で確保しないとベンダーロックインに陥る |
| 向いている領域 | 頻繁に変わる業務ツール・社内システム・データ分析。変更が多いものほど内製が効く | 基幹システム・高セキュリティ領域・大規模開発。専門性と体制が必要なもの |
※現実解は「二者択一」ではなく配分。変更頻度の高い周辺ツールは内製（AI活用で敷居が下がった）、基幹部分は体制のある外注、が2026年の定石。
継続雇用問題への現実的な答え：「1人の天才」より「仕組み＋AI」
内製の最大リスクである継続雇用問題への答えは、「優秀な1人を確保し続ける」ことではない。それは宝くじだ。答えは「普通の社員2〜3人＋AI＋文書化の仕組み」で回る体制を作ることだ。AIがコーディングの専門性の壁を下げた今、業務を深く知る社員がAIを使って開発・保守する形は現実的な選択肢になった。ただし後述する「理解を残す仕組み」とセットでなければ、内製でも属人化は起きる。
第3章：バイブコーディングのメリット・デメリット一覧
繰り返すが、バイブコーディングは否定すべき技術ではない。使いどころを誤らなければ強力な武器だ。公平に一覧化する。
図2｜バイブコーディング メリット・デメリット一覧
| ✅ メリット | ⚠ デメリット |
|---|---|
|
① 開発速度が桁違い
実測で工数87%減の事例。小規模開発では8割減が常態化。試作が1日で動く
|
① コードの品質が不安定
生成コードの19〜35.8%に脆弱性という調査も。レビューなしの本番投入は危険
|
|
② 開発コストの大幅減
MVP開発100〜250万円の相場が形成。従来の数分の一で試せる
|
② ブラックボックス化しやすい
「動くが誰も中身を説明できない」状態に陥りやすく、保守・改修コストが後から膨らむ
|
|
③ 非エンジニアが作れる
業務を最も知る社員が直接ツール化できる。「要件が伝わらない」問題が消える
|
③ 設計なき増築が起きる
「動いたから追加」を繰り返すと構造が崩れ、ある日突然、修正不能になる
|
|
④ 試行錯誤が安くなる
失敗コストが激減し、「作って確かめる」経営判断が可能になった
|
④ テスト・保守は削減されない
減るのは実装だけ。品質保証・運用の工数は残る。「全部安くなる」は誤解
|
|
⑤ 一般業務アプリの8割に適用可
予約・在庫・社内ツール等の大半はバイブコーディングで十分に対応できる
|
⑤ 高セキュリティ領域には不向き
金融・医療・決済など厳格な基準が必要な領域は従来型の設計・検証が適する
|
※結論：バイブコーディングは「試作・小規模・変更の多い周辺ツール」で最強。「基幹・高リスク領域」では従来型の規律と組み合わせる。技術の問題ではなく、使い分けの問題。
第4章：長く運用するためのAI活用法——5つの原則
ここが本記事の核心だ。AIは「安く作る」ためだけの道具ではない。「長く運用する」ための道具として使ったとき、最大の価値を発揮する。
図3｜長期運用のためのAI活用 5原則
| 原則 | やること | 具体的な実践方法 |
|---|---|---|
| 1 | ドキュメントをAIに書かせる | 「このコードの設計書・処理フロー・改修時の注意点を初心者向けに書いて」とAIに指示。従来は面倒で省かれた文書化が、AIならほぼゼロコストでできる。納品物に「AIで生成・人間が確認したドキュメント一式」を必須条件にする。 |
| 2 | 「読める化」を保守の武器にする | 引き継いだ謎のコードも、AIに「このコードが何をしているか説明して」と聞けば解読できる。担当者交代・ベンダー変更時の引き継ぎコストが激減する。属人化の解毒剤としてAIを使う。 |
| 3 | テストコードを資産にする | AIに「正常系・異常系・境界値を網羅した自動テストを書いて」と指示し、テスト一式を納品物に含める。自動テストがあれば、将来の改修で「直したら別が壊れた」を機械的に検知でき、改修費が下がり続ける。 |
| 4 | 運用ナレッジをRAG化する | 障害対応の記録・設定変更の履歴・過去のQAを蓄積し、AIに読み込ませて「社内システム専用の相談窓口AI」を作る。「あの障害どう直したっけ」が数秒で引ける。担当者の頭の中を組織の資産に変える。 |
| 5 | 契約に「運用の権利」を書き込む | 外注時は「ソースコード・設計書・テストコードの納品と権利帰属」「AI利用箇所の明示」「他社が引き継げる状態での納品」を契約条件にする。これを渋る会社は、保守で儲ける前提の会社だと分かる——契約前の踏み絵になる。 |
※共通する思想：AIで浮いた実装工数を「価格の安さ」ではなく「文書・テスト・引き継ぎ可能性」に再投資する。これが10年使えるシステムと5年で作り直すシステムの分岐点。
第5章：発注前に開発会社へ聞くべき3つの質問
「AIで安く」を掲げる会社が信頼できるかは、次の3問で判別できる。
質問1「AIで削減した工数は、どこに再投資されていますか？」——誠実な会社は「テストとドキュメントに回している」と答える。「その分お安くしています」だけの会社は、品質工程を削って安くしている可能性が高い。
質問2「納品後、御社以外でも保守できる状態で納品されますか？」——設計書・テストコード・環境構築手順の納品と権利帰属を確認する。言葉を濁す会社は、保守の囲い込み（ベンダーロックイン）で回収するビジネスモデルだ。
質問3「5年後の改修を、誰がどう行う想定ですか？」——この質問に具体的なシナリオで答えられる会社は、運用まで考えて設計している。「その時にご相談ください」は、考えていないという意味だ。
第6章：成功者の思考パターン——「作る力」より「持続させる力」
Amazonの「Day 1」哲学やトヨタの「カイゼン」に共通するのは、システムを「完成品」ではなく「育て続けるもの」と捉える思想だ。優れた経営者はソフトウェアを買うとき、「いくらで作れるか」ではなく「10年間でいくらかかり、その間ビジネスの変化に追従できるか」を問う。
行動経済学の「IKEA効果」——自分が組み立てたものに人は高い価値と愛着を感じる——は、内製・AI活用にプラスに働く。社員がAIと共に育てたシステムは「自分たちのもの」として改善が続く。外注の丸投げでは、この当事者意識は決して生まれない。
AI時代の本当の競争優位は「安く作れること」ではない。誰でも安く作れるようになったからだ。差がつくのは「作ったものを、理解し、文書化し、改善し続けられる組織能力」——AIはそのための最強の道具であり、その道具の使い方こそが問われている。
まとめ：今日から動ける3つのアクション
アクション1（見積もり比較の前に）： 候補の開発費に「保守費15〜25%/年×想定利用年数」を足したTCOで比較し直す。目先の差額ではなく10年総額で並べると、「安い」の順位が入れ替わることがある。
アクション2（商談で）： 第5章の3つの質問——工数の再投資先・引き継ぎ可能な納品・5年後の改修シナリオ——をそのまま聞く。回答の具体性で会社の本性が分かる。
アクション3（既存システムに対して今週中）： いま動いているシステムのコードや仕様書をAIに読ませ、「このシステムの構造と改修時の注意点を文書化して」と指示する。属人化の解消は、新規開発を待たず今日から始められる。
「AIで安く作れます」は嘘ではない。だが安く作れる時代だからこそ、価値は「作った後」に移った。浮いたコストを文書化・テスト・引き継ぎ可能性に再投資する発注者と、価格だけを削る発注者——5年後に笑うのがどちらかは、もう明らかだ。
データ出典：トランスコスモス「Developers X Summit 2025」発表・ACM掲載のAI生成コード実証研究・SIA株式会社「受託開発費を左右する9つの要素」・ITmedia オルタナティブ・ブログ「2026年の生成AI実態」・各社公開情報（2025〜2026年）。数値は各調査時点のものであり、契約判断の際は必ず最新の一次情報をご確認ください。
タグ： 自社開発 | 内製化 | バイブコーディング | 運用保守 | 技術的負債 | TCO | システム開発 | AI活用 | 行動経済学 | ベンダーロックイン
