生成AIはIT業界をどう変えるのか？SIerの人月ジレンマとSaaSの二極化構造

生成AIはシステム開発を変えたか？

生成AIの話題になると、「コーディングが劇的に速くなる」「テストコードの自動生成で人手が減る」といった、開発手法の直接的な変化ばかりが注目されがちです。たしかに、GitHub CopilotやCursorといったAI搭載エディタの普及により、設計書の要約、定型的なコードの生成、バグの発見、ドキュメント作成など、従来はエンジニアが手作業で時間をかけていた工程の一部は、すでに驚異的なスピードで効率化されています。

コードを書くことはIT業務のごく一部

しかし、ITシステム構築における仕事は、単純にコードを書くこと（プログラミング）だけではありません。特に大企業向けの複雑な業務システム開発においては、以下のような周辺業務・上流工程の比重が非常に大きいのが現実です。

• 要件定義と業務フローの整理： 現場の曖昧な要望をヒアリングし、矛盾のないシステム要件に落とし込む作業。

• 関係者調整（ステークホルダー・マネジメント）： 複数部署の利害対立を調整し、仕様を合意形成するプロセス。

• 既存システムとの連携・移行設計： レガシーシステム（古いシステム）とどう連携し、データをどう安全に移行するかという高度なアーキテクチャ設計。

• 非機能要件の担保： セキュリティ、可用性、パフォーマンス、障害時の復旧目標といった、目に見えない品質の作り込み。

これらは、現状の生成AIにプロンプトを投げるだけで完全に自動化できる領域ではありません。人間（エンジニアやコンサルタント）が介在し、文脈を読み取りながら意思決定を行う必要があります。

「誰が責任を負うのか」という根本的な問い

さらに重要なのが責任の所在です。生成AIが書いたコードに潜んでいた脆弱性を突かれて顧客情報が流出した場合、あるいは計算ロジックのミスで大規模な会計障害が起きた場合、「AIが書いたから」という言い訳は一切通用しません。

そのため、生成AIがIT業界に与える影響を正しく捉えるには、「どのようなシステムを作る会社なのか」「誰に向けて提供するビジネスなのか」「トラブル時の責任を誰が負うのか」というビジネスモデルの構造から切り分けて分析する必要があります。

日本独自のIT業界構造（なぜSIerビジネスは強いのか）

生成AIの影響を考える上で避けて通れないのが、日本独自のIT業界の構造です。ここを理解しなければ、なぜ日本のIT業界がすぐには変わらないのかが見えてきません。

米国と日本のITエンジニアの偏在

米国などのIT先進国では、ITエンジニアの約7割がユーザー企業（非IT企業）に所属し、社内システムの自社開発（内製化）を行っています。一方、日本では構造が全く逆転しており、ITエンジニアの約7割がSIerや受託開発ベンダーなどのIT企業に所属しています。

つまり、日本のユーザー企業の多くは自社内にシステムを開発・運用する十分なノウハウを持っておらず、ITベンダーに丸投げに近い形で依存してきた歴史があります。この外部委託前提の構造が、日本における生成AI導入のハードルを一段と高くしています。

人月商売と多重下請け構造のジレンマ

SIerのビジネスモデルの根幹を成すのが「人月（にんげつ）商売」です。「1人のエンジニアが1ヶ月働いた場合の作業量（1人月）」を基準とし、「1人月100万円のエンジニアが10人で半年かかるから6,000万円」といった形でシステム開発の見積もりを算出します。もちろん、システム開発のプライシングは一様ではありませんが、システム開発のコストは最終的には労働に集約されるため、この積み上げ方式による見積が調達コストとしてのベースラインになります。

さらに、大手SIer（プライムベンダー）が受注した案件を、二次請け、三次請けといった中小のソフトウェアハウスに委託していく多重下請け構造が形成されています。大手SIerの役割は自らコードを書くことではなく、顧客との折衝と、下請け企業を束ねるプロジェクトマネジメントへとシフトしています。

この強固な構造の中に生成AIが入り込んだとき、一体何が起こるのでしょうか。

生成AIのSIerビジネスへの影響

結論から言えば、生成AIによって開発工程の一部が効率化されても、SIerの多重下請け構造はすぐには崩壊しません。そこには、顧客側とベンダー側双方に深い課題が存在しているためです。

顧客（ユーザー企業）におけるガバナンスと説明責任

大手企業において、生成AIのPoC（概念実証）や、社内向けのセキュアなChatGPT環境の構築などは急速に進んでいます。しかし、基幹システムや本番環境の開発プロジェクトに生成AIを全面適用できているケースはまだ少数です。それは、以下のような課題があるためです。

• 監査とセキュリティルールの壁： 機密データの入力による情報漏洩リスクや、ハルシネーション（AIのもっともらしい嘘）、著作権侵害のリスクなど、「社内ルールに適合するか」「厳しい外部監査やコンプライアンス要件に耐えられるか」という論点をクリアしなければ、実運用には進めません。

• AIを使いこなす人材や組織の不在： 単発のAIツールを導入して終わるのではなく、全社的な予算配分、検証体制の構築、そして何より「AIの出力を業務プロセスに安全に組み込める人材（AIオーケストレーター）」が圧倒的に不足しています。

• 顧客の真の期待は内製化ではない： 大規模システムは極めて複雑で、わずかな仕様のズレでも甚大な業務停止を招くことがあります。トラブル時の原因究明や迅速な復旧対応といった説明責任（アカウンタビリティ）は、AIに丸投げできません。そのため、多くのユーザー企業の本音は、「生成AIを使ってすべて自社で作ろう」という内製化への回帰ではなく、「信頼できるベンダーに生成AIを最大限駆使してもらい、従来よりも安く、速く、高品質に開発してほしい」という点に集約されます。

ベンダー側が抱える売上減少のジレンマ

一方のSIerや受託開発ベンダー側も、生産性向上のために社内での生成AI活用は進めていますが、顧客向けの開発業務（クライアントワーク）に全面適用するには大きな構造的壁があります。

• 開発環境の制約： 顧客の要件をもとに開発を進める場合には、顧客データそのものを受領しないまでも、一定の機密情報を受領し開発することもあります。その場合、顧客との契約において、生成AIといった外部ツールにその情報を出すこと自体が制限されていることがあります。また、開発環境自体が顧客の指定環境である必要があるなど、生成AIといったオープンなテクノロジーを速やかに取り入れることが難しい現実があります。

• 効率化すると利益が減る矛盾： 前述の通り、SIerの収益は「エンジニアの人月工数×単価」で成り立っています。もし生成AIを活用して、これまで100人月かかっていた開発を半分の50人月で完了させてしまった場合、自社の売上と利益規模がそのまま半減してしまうという強烈なジレンマを抱えています。

• 見えないマネジメントコスト： コーディングの一部がAIによって効率化されても、要件定義、品質保証（テストの妥当性確認）、下請け企業のマネジメント、顧客への報告といった周辺業務はなくなりません。むしろ、AIが生成したブラックボックスなコードが納品されると、マネジメントコストがかえって上昇することも有りえます。「リスクを取ってAIを導入しても、売上が下がるだけで責任やマネジメントの手間はそのまま」という状況では、ベンダー側から自発的に既存の商習慣（人月見積もり）を壊すような提案を行うインセンティブは働きにくいのが実態です。

構造変化のトリガーは「AIの信頼」

当面はこの多重下請け・人月構造が維持されると見ていますが、その大前提にあるのは「顧客がAIの出力結果よりも、人間を信用している（または人間に責任を負わせたい）」という事実です。

しかし、今後数年でAIの精度がさらに向上し、「人間のエンジニアが手作業で書いたコードよりもAIが生成したコードの方がバグが少なく、裏取りをしなくても実務で安全に機能する」という認識が社会全体に浸透すれば事態は一変します。ユーザー企業が多額の人件費コストを払ってSIerに発注する意義が薄れ、ここで初めてSIerのビジネスモデルそのものが根本から揺らぐパラダイムシフトが起きる可能性があります。

自社開発ベンダー（SaaS等）への影響

受託開発による複雑な権利関係や人月モデルの制約がない自社開発ベンダー（SaaS企業やパッケージソフトウェア企業）は、プロダクトの主導権や説明責任を自社でコントロールできるため、生成AIの恩恵を最も受けやすい立場にあります。

しかし、だからといって全てのSaaS企業が安泰というわけではありません。今後はSaaS市場において、二極化が加速すると予想しています。

顧客サイドの選択肢拡大

これまで、パッケージソフトの標準機能で満たせない独自の業務要件があった場合、顧客の選択肢は「業務をシステムに合わせる（我慢する）」か「高額な追加カスタマイズ費用をベンダーに払う」の二択でした。しかし、生成AIとノーコード・ローコードツールの進化により、顧客側に「足りない機能はAIを使って内製化（自作）する」という第三の強力な選択肢が加わりました。

したがって、生成AIの自社開発ベンダーへのインパクトを語る上では、その対象としているパッケージソフトが「顧客側に自作という第三の選択肢」を生じさせるものなのかどうかによって、見え方が大きく異なります。ポイントは以下の3点です。

• 代替リスクが高い「便利機能SaaS（Horizontal SaaSの一部）」： 簡易的なワークフローシステム、社内FAQ向けのチャットボット、単純なデータ集計ツールや通知の自動化など、万が一システムが止まっても事業の根幹に致命的な影響を与えない「便利機能」に特化したSaaSは生成AIに代替されるリスクがあります。これらは顧客企業の情シス部門、あるいは現場の非エンジニアであっても、生成AIを使って容易に代替ツールを構築できるようになるため、解約（チャーン）リスクが高まり、激しい価格競争に晒されます。

• 選ばれ続ける「インフラ型SaaS（Vertical SaaSや基幹系システム）」： 一方で、金融、会計、労務、法務、医療など、複雑な法制度や厳密なコンプライアンスへの対応が不可欠な領域のシステムは比較的リスクが低いと考えられます。これらのシステムは、「法令改正への迅速な追いつき」「専門家による監修」「高度な業界知識の反映」が求められます。「そのシステムを使うことで、自動的に最新の法規制をクリアできる」という価値があるため、AIにコードが書けるようになったからといって顧客が簡単に自作できるものではありません。AI時代においても、企業のインフラとして強固なポジションを築く可能性が高いです。

• 技術力以外の「独自アセット」： 長年蓄積された膨大な企業データベース、独自の業界ネットワーク、秘匿性の高い学習データといった「技術以外の資産（アセット）」を持つプロダクトは、生成AI時代においても優位です。生成AIによって誰もが高度なプログラムを書ける技術のコモディティ化が進むからこそ、一朝一夕には模倣できない独自データの価値が相対的に上昇します。今後のSaaS市場では、「どんな機能を作れるか」よりも「どんな独自データを持っているか」が競争優位の源泉となる可能性があります。

自社開発の現場は爆速化

自社開発ベンダーの現場では、生成AIの活用によって新規事業の立ち上げスピードが劇的に向上しています。新しいプロダクトのアイデア検証、プロトタイプ作成、MVP（Minimum Viable Product：実証用最小構成）の市場投入までの期間が、従来とは比較にならないほど短縮されています。少ないリソースで多くの仮説検証（アジャイル開発）を高速に回せるようになるため、この変化は特にスタートアップ企業や新規事業開発部門にとって強力な追い風となっています。

エンジニア採用・育成への影響

IT業界の構造変化を語る上で欠かせないのが、「エンジニアという職業はどうなるのか」という問いです。結論から言えば、生成AIはエンジニアの仕事を完全に奪うのではなく、「求められるスキルの性質を大きく変容させ、人材価値の二極化を生み出す」ことになります。

シニア人材（アーキテクト層）の価値は高騰

新規開発のプロトタイプはAIで簡単に作れても、長く運用されている既存システムの改修は全く別のスキルを要求されます。既存の巨大なコードベースに変更を加える際、生成AIが出力したコードをそのまま鵜呑みにすることは非常に危険です。「そのコードが他の機能へどのような影響を与えるか（デグレの防止）」「元の設計意図（アーキテクチャ）と整合性が取れているか」「セキュリティ上の脆弱性はないか」「ビジネス上の要件を満たしているか」を瞬時に見抜き、適切な意思決定ができる高度な監修能力（レビュー能力）が不可欠になります。

AIを優秀なアシスタントや壁打ち相手として使いこなしながら、複雑なシステム全体の設計図を描き、プロジェクト全体を牽引できるシニアエンジニア（テックリードやアーキテクト）の価値は、生成AIの登場によって下がるどころか、むしろ急激に高騰しています。彼らの生産性がAIによって10倍、20倍に引き上げられるからです。

AI前提のジュニア育成という新たな課題

一方で、詳細設計書通りにただ決められたコードをタイピングするだけの、いわゆるコーダーとしての業務は、今後急速にAIに代替されていきます。コードを書くこと自体にまだ課題のある経験の浅いジュニアエンジニアにとって、生き残るためのハードルは高くなっているように見えます。

しかし、市場で即戦力となるシニアエンジニアを外部から採用することは、資金力のある大手企業であっても至難の業です。そこで現在、先見の明があるシステム会社の多くは、「ポテンシャルのあるジュニア層をあえて採用し、最初から生成AIツールをフル活用させて自走力を高め、より上流工程や要件定義に目を向けられる次世代エンジニアへと自社内で育成する」という戦略へと舵を切っています。

もはや「AIを使えること（プロンプトエンジニアリング等のスキル）」は特別なアピールポイントではなく、エンジニアとして開発業務に携わるための標準的な前提条件になりつつあります。

ただ注意していただきたいのは、何でもかんでもAIで効率的に開発できれば良いかというと、そうではありません。シニアエンジニアの価値が高騰している理由が「監修能力」であることから想像できるように、ジュニアエンジニアであっても生成AIが作成したコードの監修をし、説明できるべきです。その意味では、未経験者や簡単なポートフォリオを自作したことのないエンジニアは、生成AIを敢えて使わず、ドキュメントを頼りに開発するというプロセスを一度経験することが、遠回りのようで近道となる可能性もあります。

参考：【2026年最新】IT転職を成功させるための完全ガイド

ユーザー企業とITベンダーの勝ち筋

このような激動の時代において、顧客であるユーザー企業と、システムを提供するITベンダーは、それぞれどのような戦略を取るべきなのでしょうか。

ユーザー企業が取るべきアクション

ユーザー企業は、「ITはベンダーに丸投げ」という従来のスタンスから脱却しなければ、生成AIの恩恵を十分に受けることはできません。そのために必要なポイントは以下の2点です。

• 自社にとってのコア領域の見極め： 競争力の源泉となるコア業務（顧客体験に直結する部分）については、生成AIを活用しつつ社内での内製化を進め、柔軟かつ高速に改善できる体制を構築すべきです。一方で、バックオフィスなどのノンコア業務は、優れたSaaSを積極的に導入して標準化を図る使い分けが重要になります。そのためにはハンズオン開発ができるスタッフを配置する必要がありますが、「総合職採用だけど若手でITリテラシーが高いから」といった理由で人選するのではなく、「本人がキャリアのコア価値について技術をベースとして考えている人」を配置した方が、中長期的にはメリットが大きいです。というのも、システムは一度作って終わりではなく、運用や保守が必要になるためです。

• 価値ベースでのベンダーとの関係再構築： ベンダーに対して人月で安く買い叩くのではなく、「システムがもたらすビジネス上の価値」や「問題解決のスピード」に対して報酬を支払う（準委任契約やアジャイル型開発の推進）パートナーシップへと関係性をアップデートする必要があります。これに関して近年増えてきているのは「ラボ型開発」と呼ばれる形態で、プロジェクトベースではなく専任の技術者が常駐し、発生する周辺課題を解決していくというものです。基幹システムなど高度なマネジメントが必要な領域に適用するのは難しいですが、ここでも対象領域を絞って実験していくのがおすすめです。

ITベンダーが取るべきアクション

SIerや受託開発企業は、既存の人月商売が崩壊するリスクを直視し、ビジネスモデルの転換を図る必要があります。

• 作る価値から提供価値へのシフト： ただコードを書いて納品するビジネスから、顧客企業が生成AIを安全に業務に組み込むための「ガバナンス構築」「プロンプトの設計」「セキュリティ環境の構築支援」といった、より上流のコンサルティングや伴走支援へと提供価値をシフトさせるのが一案です。コンサルティング領域は少数精鋭のプロジェクトとなり、大きな財務インパクトをもたらさないかもしれませんが、単にシステムを構築するという業務自体が、AIに取って代わられるリスクがあります。またコンサルティング領域は一般的に上流工程になりますので、その後のプロジェクトをハンドリングしやすくなります。

• 自社独自のSaaS/ソリューション展開： 過去の受託開発で培った特定の業界に対する深い業務知識を活かし、受託開発（労働集約型）から自社プロダクト開発（知識集約型）へとポートフォリオを移行していくことが、中長期的な生存戦略となります。前述のとおり、便利機能としてのSaaSはこれから淘汰されていきますので、業界の監修や業務に特化した代替困難な領域を目指すことがポイントです。

まとめ

生成AIは、IT業界の既存プレイヤーを一気に消し去るような単純な話ではありません。生成AIは、それぞれの企業が本来持っている強みと弱みをより鮮明にし、市場における選別を加速させる役割を担っています。

SIer領域では、堅牢なガバナンスと、顧客のビジネスリスクを背負う説明責任を担保できる能力がある限り、当面は現在のビジネス構造が形を変えながらも維持されるでしょう。しかし、単なる労働力の提供しかできない下請けベンダーは淘汰の危機に直面します。一方のSaaS領域では、単なる便利機能の切り売りは顧客企業自身の内製化の波に飲まれ、高度な制度対応力や独自のデータアセットといったAIにも置き換え不可能な価値を持つ企業だけが勝ち残ります。

AIが瞬時に大量のコードを書き上げるこれからの時代、IT企業に求められるのはプログラミングのスピードではありません。「最終的な成果物に誰が責任を持つのか」「複雑なビジネス課題をどう解決するのか」「AIには生み出せない独自のデータやドメイン知識は何か」。この本質的な問いに対して明確な答えを提示できる企業とエンジニアこそが、次世代のIT業界を牽引していくことになります。

転職を検討される方にとって、今後どの領域でキャリアを構築していくのかを考えるきっかけになれば幸いです。