競合の99%を上回るパフォーマンスを誇るファンドマネージャーが、多くのソフトウェア企業にとってAIが脅威となり、その株価は「Toxic(有毒)」であると警告しました。この予測は、単なる投資アドバイスにとどまらず、SaaSやパッケージソフトに依存してきた日本企業のDX(デジタルトランスフォーメーション)戦略に大きな転換を迫るものです。
「ソフトウェアを買えば解決」という時代の終わり
Bloombergの報道によると、Polar Capitalのファンドマネージャーであるニック・エバンス氏は、AIの台頭によって多くのソフトウェア企業が生存競争に敗れると予測しています。これまで、企業のIT化といえば、課題解決のために優れたSaaS(Software as a Service)やパッケージ製品を選定・導入することが王道でした。しかし、生成AIと大規模言語モデル(LLM)の進化は、この前提を根底から揺るがそうとしています。
従来のソフトウェアビジネスは、機能をコードとして実装し、それをユーザー数(シート数)課金で提供するモデルが一般的でした。しかし、AIが高度化すると、ユーザーが複雑なUIを操作する必要がなくなり、AIエージェントが自律的にタスクを完遂するようになります。これにより、既存のソフトウェアが提供していた「操作画面(UI)」の価値が低下し、さらにはAIによるコーディング支援で「似たようなソフトウェア」を自社で容易に開発できるようになるため、既存ベンダーの価格決定力が削がれるというシナリオです。
日本市場における「SaaS信仰」と「SIer依存」への影響
この潮流は、日本のビジネス環境において特に重要な意味を持ちます。日本企業は長年、業務要件に合わせてシステムを作り込む「SIer(システムインテグレーター)依存」か、あるいは近年のDXブームに乗って「SaaS導入=DX」と捉える傾向がありました。
しかし、ソフトウェアのコモディティ化(汎用化)が進むと、以下の2つの変化が起こります。
- SaaSの選別:単にデータを記録するだけのSaaSや、AIで代替可能な単純作業プロセスのツールは価値を失います。企業は「ツールを入れること」ではなく、「AIにどうデータを食わせるか」に投資の軸足を移す必要があります。
- 内製化のハードル低下:エンジニア不足に悩む日本企業にとって、AIは朗報でもあります。GitHub CopilotやCursorなどのAIコーディング支援ツール、あるいはノーコードAIツールの進化により、高度なプログラミングスキルがない人材でも、自社業務に特化したアプリケーションを開発・維持できる可能性が広がっています。
リスク管理:ブラックボックス化とベンダーロックイン
一方で、実務的なリスクにも目を向ける必要があります。AI機能を組み込んだソフトウェアが増える中で、ガバナンスの観点からは「処理の透明性」が課題となります。特定のAI機能付きソフトウェアに業務プロセスを過度に依存させた場合、そのベンダーが競争に敗れてサービスを終了したり、AIの挙動がブラックボックス化したりした際のリスクが高まります。
また、日本の商習慣として、契約書や法規制への準拠が厳格に求められますが、海外製のAIツールやソフトウェアが日本の著作権法や個人情報保護法、あるいは業界固有の規制(金融庁のFISC安対基準など)に完全に対応しているとは限りません。ソフトウェアベンダーが淘汰される激動期だからこそ、導入するツールの持続可能性と、データポータビリティ(データを他へ移行できるか)の確認が、これまで以上に重要になります。
日本企業のAI活用への示唆
今回の「ソフトウェア企業の淘汰」という予測を踏まえ、日本の意思決定者や実務担当者は以下の点に留意すべきです。
- 「買う」から「統合する」への意識変革:SaaSを導入して終わりではなく、各ツールからデータを吸い上げ、自社のAI基盤(RAGやファインチューニング用のデータレイク)に統合できるかを重視してください。API連携が弱く、データがサイロ化するツールは避けるべきです。
- エンジニア不足の逆転発想:「エンジニアがいないから外注する」という従来の思考から脱却し、「AIを活用して社内のドメインエキスパート(業務知識者)にツールを作らせる」というアプローチを検討してください。これを支援する体制づくりこそが、これからのIT部門の役割です。
- ベンダーの生存能力を見極める:提案を受けているソフトウェアベンダーが、単に「AI機能を追加しました」と言っているだけなのか、それとも「AI時代に即したデータ構造とワークフロー」を根本から再設計しているのかを見極める必要があります。表面的なAI機能はいずれ淘汰されます。
- コンプライアンスと実験のバランス:日本の法規制を守りつつも、過度な萎縮は避けるべきです。サンドボックス環境(隔離されたテスト環境)を用意し、淘汰されるかもしれないツールであっても、短期的な業務効率化が見込めるなら使い倒す、という柔軟な「使い捨て」の思想も時には必要です。
