ものづくりの本質——AIは「人がいらない仕組み」を取り戻せるか

システム開発の本質とは、本来「人がいなくても動いて稼ぐ仕組み」を作ることのはずです。しかし現実の開発現場を見渡すと、そこにあるのは「人がいないと動かないもの」の大量生産です。この逆説は、日本のIT業界の構造そのものに根ざしています。この逆説の正体とAIがもたらす変化を考察します。

なぜ「減らない」構造ができあがるのか

SIerやITベンダーの収益は、開発だけでなく保守・運用・追加改修によって成り立っています。システムが複雑であればあるほどその維持には人手と契約が必要になり、結果としてベンダー側には「本当に手離れの良いシステム」を作るインセンティブが働きにくい構造があります。

レーマンの法則が示す複雑さの必然性

これは感覚的な話ではなく、ソフトウェア工学の古典的な知見とも符合します。1970年代にIBMのOS/360を分析したレーマン（Lehman）は、ソフトウェアは進化し続ける限り複雑さが増大し、意図的に手を入れない限り複雑性は減らないという法則を提示しました。ソフトウェアは環境変化に適応し続けなければ陳腐化する一方で、その適応の積み重ねそのものが複雑さを増していきます。ソフトウェアが変更されるたびに複雑さは増していき、リファクタリングのような意図的な取り組みがなければその複雑性は解消されないというのが、レーマンの法則の核心です。

つまり「複雑さの増大」は業界の怠慢というより、ソフトウェアという存在に内在する性質であり、それを人為的に押しとどめる努力を誰かが担わない限り、システムは自然と「人手を必要とするもの」へと肥大化していきます。日本のSIビジネスの構造は、この自然法則に抗うインセンティブを持ちにくい面があります。むしろ複雑さの維持が収益源になっているため、法則にただ身を任せている構図になりやすいと言えます。

AIは複雑さの増殖を止められるか

ここでAIの台頭は、単なる効率化ツール以上の意味を持ちうると考えられます。要件整理からコード生成、テスト、保守までを少人数、あるいは一人で完結できるようになれば、「複雑さを維持する経済的動機」自体が薄れる可能性があります。

データが示す生産性向上の実態

実際のデータを見ると、生成AIの導入は着実に生産性を押し上げています。スタンフォード大学が2026年に発表したAI Indexでは、顧客対応やソフトウェア開発の分野で14〜26%の生産性向上が報告されています。マッキンゼーの調査でも、AI活用の先行企業群では仕事の生産量やリリース速度で16〜30%の向上を、ソフトウェア品質では31〜45%の改善が見られたと報告されています。これらは平均的な企業一般の数値ではなく、AI活用に成功した一部の企業群における結果である点に留意が必要です。

楽観視できない技術的負債のリスク

ただし、ここで手放しに楽観視はできません。ArmorCodeが引用するGartnerの予測では、プロンプトだけでアプリケーションを作る手法（プロンプト・トゥ・アプリ）が一般の開発者以外にも広がることで、2028年までにソフトウェアの不具合が2,500%増加するとされています。この数値は二次情報源からの引用であり、Gartnerの一次資料に基づく詳細な条件までは確認できていない点に留意が必要ですが、AIが生成したコードは構文的には正しくても、システム全体の設計やビジネスルールへの理解を欠いた「文脈不足の欠陥」を生みやすいという指摘自体は妥当性が高いとされています。

つまりAIは「作業量としての複雑さ」を減らす一方で、「無自覚に負債を積み上げる速度」も同時に増幅しうる、諸刃の剣です。AIが本当に「人がいらない仕組み」に近づく力になるのか、それとも「もっと速く複雑さを生み出す道具」に終わるのかは、使う側の設計思想次第だということになります。

人口減少という文脈が変える評価軸

この問いが切実さを増すのは、日本の人口動態を重ねたときです。経済産業省は「2025年の崖」と呼ばれるレポートで、レガシーシステムの老朽化と保守人材の高齢化が同時に進行する問題を提起しています。これとは別のIT人材需給調査では、2030年の需給ギャップは16.4万〜78.7万人と試算されており、中位シナリオでは44.9万人、高位シナリオでは78.7万人となっています。両者は同一の文書ではないものの、根底で問題意識を共有しています。人を増やして複雑さを維持するという従来の解決策は、労働供給という前提条件そのものが崩れつつあります。

単純化しすぎない視点も必要

もっとも、この文脈を単純化しすぎるのも公平ではありません。経済学者の小峰隆夫氏による分析では、過去の潜在成長率の低下は人口減少による労働力減少そのものよりも、設備投資の停滞と全要素生産性（技術革新）の鈍化が主因であったと指摘されており、これまでの日本経済は生産年齢人口の減少を女性や高齢者の就業率上昇という「動員型対応」で補ってきたことも示されています。つまり人口減少がそのまま供給制約に直結するという単純な図式ではなく、労働参加率や技術進歩といった変数の組み合わせで結果は変わりうるという留保が必要です。

とはいえ、その動員型対応にも限界（いわゆる「ルイスの転換点」）が近づいているという指摘がある以上、中長期的には「同じ人数でどれだけ回せるか」という一人当たり生産性の問題が、資金の問題より先に効いてくる局面は現実味を帯びてきます。

複雑さを減らす取り組みが機能しにくいケースと注意点

短期的な会計評価との相性が悪いケース：新しい機能を「作る」ことは売上に直結し、複雑さを「減らす」ことは評価されにくい構造があります。リファクタリングやアーキテクチャ整理への投資判断は、短期の業績評価軸だけでは正当化しにくい場合があります
AI生成コードの検証体制がないまま導入するケース：ArmorCodeが引用するGartnerの予測によれば、AIが生成したコードは構文的には正しくても設計思想やビジネスルールへの理解を欠くことがあるとされています。人間によるレビュー・アーキテクチャ設計の判断を省略すると、かえって技術的負債が加速するリスクがあります
「人を増やせば解決する」という前提で計画するケース：人口動態を踏まえると、今後は労働供給そのものが制約になる場面が増えていきます。人員増加を前提とした従来型の解決策は、中長期的には機能しにくくなる可能性があります
複雑さの維持が収益構造に組み込まれている組織のケース：保守・運用契約の継続が収益の柱になっている場合、複雑さを減らす取り組み自体が既存のビジネスモデルと矛盾する可能性があります。この構造を自覚しないまま「AIで効率化しよう」と掲げても、実際には形骸化しやすくなります

よくある質問

Q1. AIを導入すればシステムの複雑さは自動的に減りますか？

自動的には減りません。AIは複雑さを減らす方向にも、より速く複雑さを増やす方向にも使える道具です。どちらに転ぶかは、AIを使う側が「複雑さを減らす設計思想」を意図的に持っているかどうかに左右されます。人間によるアーキテクチャ判断・レビュー体制を伴わないままAIにコード生成を任せると、ArmorCodeが引用するGartnerの予測が指摘するように文脈を欠いた欠陥が積み上がるリスクがあります。次に確認すべきことは、自社のAI活用にレビュー・設計判断の工程が組み込まれているかどうかです。

Q2. レーマンの法則は今のAI時代にも当てはまりますか？

基本的な考え方は今も当てはまるとされています。ソフトウェアが環境変化に適応し続ける限り複雑さが増大するという法則自体は、開発の主体が人間かAIかによって変わるものではありません。むしろAIによってコード生成の速度が上がった分、意図的なリファクタリングを怠った場合の複雑化の速度も加速する可能性があります。法則に抗うための「意図的な力」を、より少ない人数で行使できるかどうかが今後の論点になります。

Q3. 日本のSIビジネスは今後どう変わっていく可能性がありますか？

保守・運用契約による収益構造は、IT人材不足という供給制約の中で見直しを迫られる可能性があります。ただし、これは特定の企業や業界全体の将来を断定するものではなく、個々の企業の経営判断や技術投資の方向性によって結果は大きく異なります。人口動態という文脈は重要な変数のひとつですが、小峰隆夫氏の分析が示すように、生産性向上や労働参加率の変化によって影響の度合いは変わりうる点に留意が必要です。海外では、一部のAI・データ企業において、顧客企業に技術者を深く入り込ませて導入から実装までを担うFDE（Forward Deployed Engineer）というモデルが広がりつつあり、従来の人月商売とは異なる形でのAI導入支援のあり方も、今後の業界構造を考える上で参考になります。

Q4. 技術的負債の増加を防ぐには何から始めればいいですか？

AIが生成したコードをそのまま採用するのではなく、アーキテクチャ全体との整合性を人間が確認する工程を設けることが基本的な出発点です。ArmorCodeが引用するGartnerの予測によれば、AI生成コードの欠陥は従来型のテスト手法では発見しにくい複雑な構造的問題であることが多いとされており、通常のテストに加えて設計レベルでのレビューを組み込むことが有効と考えられます。次に確認すべきことは、自社の開発プロセスにAI生成コード専用のレビュー基準があるかどうかです。

Q5. 個人のエンジニアがこの構造の中でできることは何ですか？

自分が関わる開発が「人がいなくても回る仕組み」に近づいているか、「人がいないと回らないもの」を増やしているだけかを、定期的に自問する視点を持つことが実務的な出発点になります。AIを使う際も、単にコード生成を任せるだけでなく、生成された内容がシステム全体の設計にどう影響するかを確認する習慣をつけることが、技術的負債を防ぐ個人レベルの対策になります。

まとめ

システム開発の本質は「人がいなくても動く仕組み」を作ることだが、SIビジネスの収益構造は複雑さの維持と結びつきやすい。これはレーマンの法則が示すソフトウェアの自然な性質とも符合します
AIの導入により生産性は着実に向上している一方、技術的負債が急増するリスクも指摘されている。二次情報で引用されるGartner予測では2028年までにソフトウェア不具合が2,500%増加するとされており、諸刃の剣であることを認識する必要があります
日本の人口減少・IT人材不足という文脈は、複雑さを減らす取り組みの経済的価値を変える可能性がある。ただし人口減少がそのまま供給制約に直結するという単純な図式ではない点にも留意が必要です
複雑さを減らす取り組みが機能しにくいケースを理解した上で、意図的な設計思想を持つことが重要です