■ 1. 本記事の主題と結論
- 本記事のテーマ:
- 自律型AIエージェントの普及によってSIerのビジネスモデルがどう変わるのかを考える
- 生き残るために何を獲得し、何を捨てるべきなのかを考える
- 結論:
- SIerの価値は「ソフトウェアを作ること」から「AIを活用して顧客企業を変革し、その成果とリスクに責任を持つこと」へ移る
■ 2. 「SaaSの死」が示したもの
- 2026年2月の市場変動:
- SaaS関連銘柄から48時間で約2,850億ドルの時価総額が消えた
- 引き金は自律型AIエージェントが複数ステップからなる業務ワークフローを最後まで完遂できると広く実証されたこと
- この動きは「SaaSの死」として大きく報じられた
- SaaS自体は消滅しない:
- SaaSは単なる人間が操作する画面ではない
- 業務データが蓄積され、企業の業務を支える基盤として長年運用されてきた資産がある
- AIエージェントがSaaSを操作できるようになっても、これらの役割までなくなるわけではない
- 変わるのは使い方:
- 変わるのはSaaSそのものではなく、SaaSを誰が、どのように使うのかという部分
- これまでのSaaSは人間が画面を操作して業務を進めることを前提に発展してきた
- これからのSaaSは人間だけでなくAIエージェントが利用することも前提に設計する必要がある
- 揺らぐ常識:
- 揺らいでいるのはSaaS自体の存在ではなく、「ソフトウェアは人間が操作するもの」というこれまでの常識
- AIは利用と開発の両工程に浸透:
- すでにシステム開発の工程にもAIが組み込まれている
- AIエージェントによる業務実行の自動化と同時に、業務を支えるシステムの開発もAIによって大きく効率化されている
- 利用する工程の変化は、人間が操作することを前提としてきたビジネスに影響を与える
- 開発する工程の変化は、ソフトウェアは人間が作るものを前提としてきたビジネス全体に影響を与える
■ 3. 人月モデルの構造的限界
- 人月という収益モデル:
- SIerは顧客から要件を受け、必要な人数と期間を見積もり、その工数を人月として売ってきた
- 10人月の仕事なら10人月分の売上になる
- AIによる前提の崩壊:
- AIによって1人あたりの生産性が大きく向上すると、この前提が崩れ始める
- 同じ成果をより少ない人月で実現できるケースもある
- 同じ10人月でこれまで以上の量や品質を求められるケースもある
- AIの利用自体にもコストがかかる
- 本質は工数と成果の関係変化:
- 重要なのは単純に「10人月の仕事が3人月になる」ということではない
- AIによって投入した人月と生み出される成果の関係が大きく変わることが本質
- 同じ10人月でもAIを使いこなすチームとそうでないチームでは、生み出せる成果に大きな差が生まれる
- 尺度としての機能低下:
- 「何人が、何ヶ月働いたか」は仕事の価値を測る尺度として徐々に機能しにくくなる
- ここに人月ビジネスの構造的な限界がある
■ 4. AI化はチャンスであり分岐点
- 顧客企業のAI化は段階的:
- 既存の基幹システムやSaaS、業務データ、セキュリティ要件、法規制、社内ルールがすぐになくなるわけではない
- 既存の環境にAIを組み込みながら、段階的に業務を変えていくことになる
- 新たに問われる論点:
- どの業務をAI化するのか
- 既存システムとAIをどう連携するのか
- どこまでAIに任せ、どこに人間の判断を残すのか
- AIを安全に運用するには何が必要なのか
- 新しい仕事の発生:
- こうした問題を整理し、業務とシステムの両方を設計することがこれからのSIerに求められる
- AIによって開発案件が減ることだけを恐れる必要はない
- 「作る仕事」が減る一方で「AIを前提に業務とシステムを作り変える仕事」が生まれる
- 問われるのは減っていく工数をどう守るかではなく、AIによって生まれる新しい価値をどう事業に変えるか
■ 5. SIerの提供価値の変化
- 価値の移動:
- AIによって実装コストが下がれば、作ること自体では差がつきにくくなる
- 何をAI化するかを決め、既存システムと組み合わせ、安全に運用し、業務成果につなげる仕事の重要性が高まる
- 提供価値は「作って納める」から「業務を変え、動かし続ける」ことへ移る
- これまでとこれからの対比:
- 収益は人月・受託開発から成果連動・継続サービスへ変わる
- 開発は実装工数そのものが価値である状態から、AIで実装を効率化し設計や成果へ価値を移す状態へ変わる
- 設計はシステム単位の設計から、AIを前提とした業務全体の設計へ変わる
- 運用は納品後の保守から、AIの監視・改善・統制へ変わる
- 顧客との関係は納品を一区切りとする形から、継続的に改善へ伴走する形へ変わる
- 1. 人月ではなく成果で稼ぐ:
- 投入した工数と生み出される成果の関係は、これまで以上に不均一になる
- 労働量だけでは仕事の価値を測りにくくなり、顧客にどれだけの成果を生み出したかが問われる
- 業務時間の短縮、コストの削減、売上や生産性の向上が成果の指標になる
- 開発にかかった工数ではなく、顧客に生み出した事業価値で稼ぐモデルへの転換が必要
- 2. 仕様定義とアーキテクチャで差がつく:
- コード生成やテストをAIが担うことで、「どう実装するか」だけでは差がつきにくくなる
- 「何を作るべきか」を決める重要性はむしろ高まる
- 顧客の曖昧な要求を整理し、業務上の制約を理解する必要がある
- AI、SaaS、既存システムをどう組み合わせるかを設計し、実現可能な仕様とアーキテクチャに落とし込む力が求められる
- 3. AIを安全に使う仕組みの提供:
- AIが業務の一部を担うようになれば、「何ができるか」だけでなく「何をさせてよいか」が重要になる
- どのデータへのアクセスを許可するのか、どこまで自律的な操作を認めるのかを決める必要がある
- どこで人間の承認を挟むのか、AIの判断をどう監査し問題が起きたときにどう止めるのかを定める必要がある
- AIを導入するだけでなく、安全に使い続けられる環境まで設計することが新たな提供価値になる
- 4. 責任そのものを価値にする:
- 顧客企業自身がシステムを作りやすくなっても、すべてのリスクまで自社で引き受けられるとは限らない
- 障害対応、データ漏洩時の説明、AIの誤判断に対する原因調査と改善を誰が担うのかという問題が残る
- AIそのものがこうした責任を引き受けることはない
- 品質や運用を担保し、問題が起きたときに対応するという法人としての信用と責任が価値になる
■ 6. 古い仕組みの見直し
- 新しい能力の獲得だけでは不足:
- これまでのSIビジネスを支えてきた仕組みそのものを見直す必要がある
- 人月を前提に最適化されてきた人員構成や組織、営業、開発環境の一部は変革を妨げる要因になり得る
- もともと悪い仕組みではない:
- 多くの開発者を抱えることも、工数を正確に管理することも、外注先を確保することも人月ビジネスでは合理的だった
- 少人数で高い生産性を出すことが求められるようになれば、その合理性は変わる
- 人員構成の見直し:
- 「多くの人で実装する組織」から「少人数で設計し、AIを使って実装する組織」への転換が必要
- 定型実装を前提とした人員構成は、実装の生産性が上がり同じ成果に必要な人数が減るため見直す
- 工数・進捗管理中心の管理職の役割は、成果物の品質やAI活用開発全体を判断する能力が必要になるため見直す
- 特定言語や製品だけに依存した専門性は、コード解析や技術移行が容易になり差別化しにくくなるため見直す
- 組織・ビジネスモデルの見直し:
- 売上や評価制度が投入人数を前提としたままでは、AIを使うほど不利になるという矛盾が生まれる
- 営業では工数ではなく成果に対して価格を設定する
- 社内の評価も稼働率ではなく、少ない工数でどれだけ大きな成果を生み出したかを評価する仕組みへ変える
- 多くの人員を集めることを前提とした多重下請け構造から、少人数のチームがAIを活用する体制へ移す
- 「人を多く動かすほど売上と評価が上がる仕組み」から「少ない人員で大きな成果を出すほど利益と評価が上がる仕組み」への転換が必要
- 開発環境の見直し:
- セキュリティ要件の厳しい開発現場では、安全性を重視して独自のルールや閉じた開発環境が整備されてきた
- それらがAI活用そのものを妨げるなら、安全性を維持しながらAIを利用できる環境へ作り直す必要がある
- 過度に独自化された開発ルールは、AIを前提とした開発プロセスへの移行を妨げる可能性がある
- AI利用を想定していない閉じた開発環境では、クラウド型のAI開発ツールを利用できず生産性向上の恩恵を受けにくい
- 問い直しの本質:
- 単純に古いから捨てるのではなく、従来合理的だった仕組みが前提の変化後も合理的なのかを問い直す
- 新しいAIツールを導入するだけならそれほど難しくない
- 本当に難しいのは、AIを活かすためにこれまで会社を支えてきた仕組みそのものを変えられるかどうか
■ 7. AI時代に求められる中核能力
- 4つの能力領域:
- 経営・戦略として、顧客企業の業務をAI前提で再設計し、投資対効果まで構想する
- 技術の見極めとして、AIモデルやAI製品の特性を理解し、適切な技術を組み合わせる
- データ・ガバナンスとして、顧客データをAIで安全に活用できる状態に整え、権限や統制を設計する
- 変革の推進として、小さく導入し効果を検証しながら現場へ定着させ、適用範囲を広げる
- システムの外側への踏み込み:
- 重要なのはAIそのものの技術力だけではない
- 顧客の業務を理解し、経営と対話し、投資対効果を示す必要がある
- 安全なデータ利用を設計し、導入したAIを現場に定着させる必要がある
- これまでSIerがシステムの外側と考えてきた領域まで踏み込む必要がある
- 責任の価値の上昇:
- 作ることの価値が下がるほど、何を変えるべきかを考え、安全に実現し、結果に責任を持つことの価値は高まる
- SIerはこれまでもシステムの品質や安定稼働、セキュリティに責任を担ってきた
- 作ることがコモディティ化するほど、成果やリスクに責任を持てることがこれまで以上に重要な提供価値になる
■ 8. まとめ
- 「SaaSの死」の本質:
- SaaSそのものの終わりではない
- AIによって「ソフトウェアは人間が操作するもの」という前提が揺らぎ始めたこと
- 作る側でも同じ変化:
- コード生成やテストなどをAIが担えば、1人あたりが生み出せる成果は大きく変わる
- 投入した人月と生み出される成果の関係はこれまで以上に不均一になる
- その影響を特に強く受けるのが、人の工数を売上に変えてきたSIer
- 仕事自体はなくならない:
- 顧客企業のAI化には既存システムとの統合、業務の再設計、ガバナンス、継続的な改善が必要になる
- SIerの仕事がなくなるのではなく、価値のある仕事が作ることから別の場所へ移る
- 価値が移る方向:
- 人月から成果へ
- 実装から設計へ
- 導入から統制へ
- 納品から継続的な責任へ
- 最終的に問われること:
- 新しい能力を獲得するだけでなく、人月を前提として築いてきた既存の仕組みを変える必要がある
- 問われるのはAIによって減っていく仕事をどう守るかではない
- AIによって生まれる新しい価値を、どう自分たちの事業に変えていくかが問われる