AIでSaaSは不要になるのか？内製化の判断基準と3つの落とし穴

経営層から「AIエージェントを使えば、SaaSを解約して全部内製化できるのでは？」と聞かれたことはありませんか。

Claude CodeやGitHub Copilot、CursorといったAIコーディングエージェントの登場により、ソフトウェア開発のハードルは劇的に下がりました。実際にClaude Codeを使ってシステムを作ると、驚くほどのスピードで動くものが出来上がります。こうした体験を通じて、「SaaS is Dead（SaaSは死んだ）」という論調がシリコンバレーを中心に広がっています。

しかし、この議論には見落とされている論点が多くあります。

この記事では、AIエージェント時代におけるシステムの内製化について、以下の観点から整理します。

なぜ今「内製か外注か」が問い直されているのか
AIエージェントで何が本当に変わったのか
SaaS is Dead論争の本質 — 何が正しく、何が間違っているか
内製化すべきもの・すべきでないものの判断基準
UIが消える未来とその先
IT予算の配分をどう変えるべきか

所要時間: 読了12分

1. なぜ今「内製か外注か」が問い直されているのか

DX推進の行き詰まりとAIへの期待

多くの企業でDX推進が経営課題として位置づけられています。しかし、DXの実態は既存システムの維持管理に追われ、新しい取り組みに着手できない企業が少なくありません。

こうした中で、AIエージェントの登場は「DX推進の突破口になるのでは」という期待を生んでいます。特にソフトウェア開発の領域では、AIエージェントが人間のエンジニアに匹敵するコードを書けるようになりつつあり、「外注に出していた開発を社内でAIに任せられるのでは」という発想が広がっています。

内製化の議論は今に始まったことではない

振り返ると、内製化と外注化の振り子は過去何度も揺れてきました。

2000年代: 大規模SIerへの外注が主流
2010年代前半: クラウドとSaaSの普及で「作るより買う」が合理的に
2010年代後半: アジャイル開発の浸透で「内製化回帰」の機運
2020年代前半: DX推進で内製化を志向するも、人材不足で頓挫するケースが多発
2025年〜: AIエージェントの登場で「内製化のハードルが下がった」という新たな議論

つまり、内製化の議論そのものは目新しいものではありません。AIエージェントの登場が新たな変数として加わったことで、改めて「今度こそ内製化できるのでは」という期待が生まれているのです。

一般的な傾向として、内製化の議論が盛り上がるたびに「ツールの進化で開発が容易になった」という理由が挙げられます。クラウドの登場時も、ローコードの登場時も同じでした。

ネクストの解釈としては、AIエージェントは確かにこれまでの変化とは次元が異なります。しかし、ツールが進化しても内製化が成功するかどうかを決めるのは、何を作るべきかを定義する力と作ったものを運用し続ける体制です。この2点が欠けたまま内製化を進めると、過去と同じ失敗を繰り返します。

2. AIエージェントで何が本当に変わったのか

コーディングの民主化

AIコーディングエージェントの進化は目覚ましいものがあります。

Anthropicが公開しているSWE-bench Verifiedの結果によると、Claude 3.5 Sonnetは実際のGitHubリポジトリから抽出した500件の実装タスクに対して49%のスコアを達成しています（出典: Claude 3.5 Sonnet for Software Engineering – https://www.anthropic.com/research/swe-bench-sonnet ）。これは単なるコード補完ではなく、実務レベルのソフトウェアエンジニアリングタスクを自律的に解決できることを意味します。

Claude Codeは、コードベース全体を読み込み、ファイルの編集、コマンドの実行、開発ツールとの連携を自律的に行うエージェント型のコーディングツールです（出典: Claude Code overview – https://code.claude.com/docs ）。ターミナル、IDE、デスクトップアプリ、ブラウザから利用でき、複数ファイルにまたがる機能開発やバグ修正を自然言語の指示だけで実行できます。

しかし、変わっていないものがある

AIエージェントがコーディングを劇的に効率化したのは事実です。しかし、ソフトウェア開発の全工程を置き換えたわけではありません。

ソフトウェア開発で変わった部分

コードの記述速度
定型的なバグ修正
テストコードの生成
ドキュメントの作成
コードレビューの補助

ソフトウェア開発で変わっていない部分

何を作るかの定義: ビジネス要件を技術要件に落とし込む力
アーキテクチャ設計: スケーラビリティ、可用性、保守性を考慮した設計判断
インフラ構築と運用: クラウドインフラの設計、セキュリティ設定、障害対応
品質保証: テスト戦略の策定、非機能要件の担保
運用と保守: デプロイ、モニタリング、インシデント対応

AIエージェントが得意なのは「コードを書く」という工程です。しかし、ソフトウェア開発において、コードを書く工程は全体の一部にすぎません。要件定義、設計、インフラ構築、テスト、運用 — これらの工程は依然として専門知識を必要とします。

一般的な傾向として、AIエージェントの登場はコーディングの民主化をもたらしました。これまで専門のエンジニアでなければできなかったコード記述が、ビジネスサイドの人間でも可能になりつつあります。

ネクストの解釈としては、コーディングのコストが限りなくゼロに近づくことで、ソフトウェア開発の価値の重心が移動します。コードを書くこと自体の価値は下がり、何を作るべきかを見極める力と作ったものを安全に運用する力の価値が相対的に上がります。

実践的なアドバイスとして、AIエージェントを「エンジニアの代替」ではなく「エンジニアの生産性を数倍にするツール」として捉えるべきです。エンジニアがいない組織がAIエージェントだけで内製化を進めるのは、現時点では大きなリスクを伴います。

当社では500社以上の開発実績を通じて、要件定義からインフラ構築、運用までを一気通貫で支援しています。

サービス

3. SaaS is Dead論争の本質

論争の背景

2025年後半から、シリコンバレーのVC（ベンチャーキャピタル）やテクノロジーリーダーの間で「SaaS is Dead」という議論が活発化しています。

アメリカを代表するベンチャーキャピタルであるセコイア・キャピタルは「Generative AI’s Act Two」と題したレポートの中で、生成AIがSaaSよりも速いスピードで10億ドル規模の収益に到達したことを指摘しています。（出典: Generative AI’s Act Two – https://www.sequoiacap.com/article/generative-ai-act-two/ ）

また、VC Tom Tunguzのブログでは、公開SaaS企業の売上成長率が鈍化している傾向が分析されており、SaaS企業の粗利益率は76%と高いにもかかわらず、純利益がほぼゼロに近いという構造的な課題が指摘されています。（出典: Tom Tunguz Blog – https://tomtunguz.com/ ）

こうした背景から、AIエージェントがSaaSを置き換えるという見方が広がっているのです。

SaaS is Dead論の3つの論点

この議論を整理すると、3つの論点に分かれます。

論点1. 簡易的なSaaSはAIに置き換わる → これは正しい

AIエージェントを使えば、単純なCRUD（データの作成・読み取り・更新・削除）機能を提供するだけのSaaSは、社内で構築できるようになります。たとえば、社内向けの簡易的な管理画面、データ入力フォーム、レポート生成ツールなどは、Claude Codeを使えば数時間で構築可能です。

機能が単純で、自社固有の要件がないSaaSから順に、内製化やAI生成ツールに置き換わる可能性は十分にあります。

論点2. すべてのSaaSが不要になる → これは間違い

SaaS is Dead論が見落としているのは、SaaSの価値がソフトウェアの機能だけにあるわけではないという点です。

ネットワーク効果: Slackは社内だけでなく社外のパートナーとも繋がっている。Salesforceには取引先のデータが蓄積されている。こうしたネットワーク効果は、同じ機能を内製しても再現できません。
乗り換えコスト: 長年使い続けたSaaSには、業務プロセスが深く組み込まれています。データの移行、従業員の再教育、連携システムの改修 — これらの乗り換えコストは、AIエージェントでは解決できません。
規制対応とコンプライアンス: 会計ソフト、人事労務システム、電子契約サービスなどは、法改正への継続的な対応が求められます。これを自社で追い続けるのは、大きな負担になります。
ドメインデータの蓄積: 業界固有のベンチマークデータ、取引データ、市場データを持つSaaSの価値は、ソフトウェアの機能ではなくデータにあります。

論点3. SaaSのUIがなくなる → これは起きる

ここが最も重要な論点です。

現在のソフトウェアの構造は、以下のようになっています。

//現在
人間 → UI → アプリケーション → データ

AIエージェントが普及した未来では、この構造が変わります。

//将来
人間 → AIエージェント → アプリケーション → データ

たとえば、ECサイトで商品を購入する場面を考えてみましょう。現在は、人間がWebサイト（UI）を訪れ、検索し、商品を選び、カートに入れ、決済します。しかし、AIエージェントが代わりに購買を行う場合、Webサイトにアクセスする必要はありません。裏側のAPI（Application Programming Interface）を直接呼び出したほうが効率的です。

つまり、AIエージェントが普及すると、SaaSのUI（ユーザーインターフェース）は価値を失います。すべてのWebサービスはAPI化され、データを提供するためのプログラムに変わっていくでしょう。

しかし、SaaSのUIがなくなることと、SaaSが死ぬことは同じではありません。UIが消えても、Application（ビジネスロジック）とData（蓄積されたデータ）は残ります。SaaS is Deadではなく、SaaS is Transforming（SaaSは変容する）が正確な表現です。

ネクストのインサイト

一般的な傾向として、テクノロジーの変革期には「既存の仕組みはすべて不要になる」という極端な議論が出がちです。クラウドの登場時にも「オンプレミスは死んだ」と言われましたが、現実にはハイブリッド環境が主流になりました。

ネクストの解釈としては、SaaS is Dead論の本質は「ソフトウェアの価値がどこにあるか」の問い直しです。開発のハードルが究極的に下がった世界では、そのSaaSでなければ提供できない価値は、逆説的ですがソフトウェアエンジニアリング以外の部分 — ネットワーク効果、蓄積されたデータ、業界固有の知見、規制対応 — に移ります。

実践的なアドバイスとして、SaaS契約を一括解約するのではなく、各SaaSの価値を「機能の価値」と「機能以外の価値」に分解して評価することを推奨します。機能の価値だけのSaaSは内製化候補ですが、ネットワーク効果やデータに価値があるSaaSは引き続き利用すべきです。

4. 内製化すべきもの・すべきでないものの判断基準

判断フレームワーク: 4象限マトリクス

内製化の判断は、以下の2軸で整理できます。

縦軸: 自社の競争優位に直結するか
横軸: AIエージェントで構築可能か

	AIで構築しやすい	AIでは構築しにくい
競争優位に直結する	最優先で内製化	専門パートナーと内製化
競争優位に直結しない	既存SaaSのまま or 安価に内製	既存SaaSを継続利用

内製化すべきもの

自社固有のビジネスロジックを持つシステム

自社の業務フローや独自のルールが組み込まれたシステムは、内製化の最有力候補です。汎用SaaSでは対応しきれないカスタマイズが必要な場合、AIエージェントを活用して内製化することで、柔軟性とスピードの両方を手にできます。

差別化要因となる顧客体験

顧客に提供するサービスの体験が競合との差別化要因になっている場合、その部分はSaaSに依存すべきではありません。自社でコントロールできる内製システムのほうが、迅速な改善サイクルを回せます。

社内向けの簡易ツール

社内の業務効率化ツール、管理画面、レポート生成など、機能が限定的で外部とのデータ連携が少ないものは、AIエージェントで短期間に構築できます。SaaSのライセンス費用を削減できる可能性があります。

内製化すべきでないもの

ネットワーク効果が価値の源泉であるサービス

Slack、Microsoft Teams、Salesforceのように、社外のパートナーや取引先との接点がサービスの価値になっているものは、同じ機能を内製しても意味がありません。

法規制への継続的対応が必要なシステム

会計（freee、マネーフォワード）、人事労務（SmartHR）、電子契約（クラウドサイン）などは、法改正のたびにシステム改修が必要です。これを自社で追い続けるコストは、SaaSのライセンス費用を大幅に上回ります。

大量のドメインデータに価値があるサービス

業界ベンチマークデータ、市場データ、信用情報など、長年の蓄積によって成り立っているサービスは、機能を内製しても代替できません。

判断に迷った場合のチェックリスト

そのSaaSの機能だけで価値を感じているか、データやネットワークにも価値を感じているか
内製した場合、運用・保守を誰が担当するか明確か
法改正や規制変更への対応が必要なシステムか
社外のステークホルダーがそのサービスを利用しているか
内製した場合のセキュリティ対策を自社で担保できるか

5. IT予算の配分はこう変わる

従来のIT予算配分

多くの企業のIT予算は、以下のような配分になっています。

SaaSライセンス費: 月額課金の積み上げ
システム開発外注費: SIerやフリーランスへの開発委託
インフラ費: クラウド利用料、オンプレミス維持費
人件費: 情シス部門の人員コスト
保守・運用費: 既存システムの維持管理

AIエージェント時代の予算配分の変化

AIエージェントの普及により、IT予算の使い道は以下のように変わっていきます。

減少が見込まれる費用

システム開発外注費の一部: 定型的な開発はAIエージェントで内製化できるため、外注費の削減余地があります。ただし、アーキテクチャ設計やインフラ構築は引き続き専門家の支援が必要です。
簡易SaaSのライセンス費: 機能が単純なSaaSは内製ツールに置き換え可能です。

増加が見込まれる費用

AIインフラ・ツール費: Claude Code、GitHub Copilot等のAIコーディングツールのライセンス費、AIモデルのAPI利用料
セキュリティ強化費: AIが生成したコードのセキュリティレビュー体制、内製システムの脆弱性診断
従業員のリスキリング費: AIエージェントを使いこなすための教育投資。プロンプトエンジニアリング、要件定義スキル、AIとの協働スキル
データ基盤費: AIエージェントが活用するためのデータ基盤の整備

性質が変わる費用

クラウド利用料: AIネイティブなアーキテクチャへの移行に伴い、GPU利用料やAI推論コストが加わります

一般的な傾向として、多くの企業がAIエージェントの導入で「コスト削減」を第一の目的に掲げています。しかし、AIエージェント時代に求められるのは単なるコスト削減ではなく、予算配分の組み替えです。

ネクストの解釈としては、IT予算の総額は必ずしも減りません。ソフトウェア開発の外注費が減る一方で、AIインフラ費、セキュリティ費、人材育成費が増加するからです。重要なのは、「守り」の予算（既存システムの維持管理）を減らし、「攻め」の予算（AI活用、データ活用、新規プロジェクト）を増やすことです。

実践的なアドバイスとして、現在のSaaSライセンス費を棚卸しし、各サービスを「機能の価値」「データの価値」「ネットワークの価値」で分類してみてください。機能の価値しかないSaaSが全体の何割を占めるか。それが内製化による削減余地の目安になります。

当社では500社以上の開発実績を通じて、クラウドインフラの設計からAI活用支援まで、DX推進を包括的に支援しています。

サービス

6. 情シスが今やるべき3つのこと

やるべきこと1. AIエージェントを自分の手で触る

SaaS is Dead論に対して正しい判断を下すには、まずAIエージェントの実力を自分の目で確かめることが不可欠です。

Claude Codeを使って小さなツールを1つ作ってみてください。社内の情報を整理するダッシュボード、定型レポートの自動生成ツール、簡易的なデータ入力フォームなど、失敗しても影響が小さいものから始めましょう。

AIエージェントでできること・できないことの境界線が、実感として理解できるはずです。

やるべきこと2. SaaS棚卸しを実施する

現在契約しているSaaSの一覧を作成し、以下の観点で分類してください。

分類	基準	アクション
A: 機能のみ	機能だけが価値、データ蓄積なし	内製化を検討
B: データに価値	蓄積データやベンチマークが価値	継続利用
C: ネットワーク	社外連携が価値の源泉	継続利用
D: 規制対応	法改正対応が含まれる	継続利用

分類Aに該当するSaaSが、AIエージェントによる内製化候補です。

やるべきこと3. 内製化ロードマップを策定する

全SaaSを一斉に解約して内製化するのではなく、段階的に進めてください。

1. 小さな成功体験を作る（1ヶ月以内）

分類Aの中から、最も単純なSaaSを1つ選び、AIエージェントで代替ツールを構築します。ここで学んだ知見が、後のステップの判断材料になります。

2. 内製化の体制を整える（3ヶ月以内）

AIエージェントで構築したシステムの運用・保守体制を確立します。セキュリティレビューのプロセス、障害対応のフロー、コードのバージョン管理を整備します。

3. 本格的な内製化判断を行う（6ヶ月以内）

1・2の結果を踏まえ、追加のSaaSを内製化すべきか、現状のまま維持すべきかを判断します。この時点では、AIエージェントのコスト（APIの利用料）と、SaaSのライセンス費を実データで比較できるはずです。

まとめ

AIエージェントの登場は、ソフトウェア開発のあり方を根本から変えつつあります。しかし、「SaaS is Dead」「全部内製化すべき」という極端な結論に飛びつくのは危険です。

この記事の要点を整理します。

AIエージェントはコーディングを劇的に効率化した。しかし、要件定義、アーキテクチャ設計、インフラ構築、運用・保守は依然として専門知識を必要とする
SaaS is Deadではなく、SaaS is Transforming。UIはAIエージェントに置き換わるが、ネットワーク効果、蓄積データ、規制対応といったSaaSの価値は残る
内製化の判断は「競争優位 × AIでの構築難易度」で整理する。すべてを内製化するのではなく、自社の差別化に直結する領域に集中する
IT予算は「削減」ではなく「組み替え」。開発外注費をAIインフラ費、セキュリティ費、人材育成費に振り向ける

人間がコードを書く時代は、確実に終わりに向かっています。その時に情シスに求められるのは、コードを書く力ではなく、何を作るべきかを定義する力です。AIエージェントは強力な道具ですが、道具の使い方を決めるのは人間です。

まずは今日、Claude Codeを1回触ってみてください。

参考文献

Anthropic「Claude 3.5 Sonnet for Software Engineering」（SWE-bench Verified結果） https://www.anthropic.com/research/swe-bench-sonnet
Anthropic「Claude Code overview」 https://code.claude.com/docs
Sequoia Capital「Generative AI’s Act Two」 https://www.sequoiacap.com/article/generative-ai-act-two/
Tom Tunguz Blog（SaaS企業の成長率・収益性分析） https://tomtunguz.com/
ネクスト株式会社公式サイト https://www.next.inc