使い捨てソフトウェア時代の幕開け ― 市場構造の根本的変革と日本企業

使い捨てソフトウェア時代の幕開け ― 市場構造の根本的変革と日本企業

こんにちは、株式会社Qualiteg コンサルティング部門です。

昨今、生成AIの急速な進化により、ソフトウェア開発の在り方が根本から変わりつつあります。2024年にはClaude、GPT-4、Geminiなどの大規模言語モデルがコード生成能力を飛躍的に向上させ、GitHub CopilotやCursor、Windsurf等の開発支援ツールが実際の開発現場で広く活用されるようになりました。さらに、Devin、OpenAI Canvas、Anthropic Claude Codingといった、より高度な自律的コーディング機能を持つAIエージェントも登場しています。

このような技術革新を背景に、当部門では今後のソフトウェア産業の構造変化について詳細な分析を行いました。本シリーズでは、特に注目すべき変化として、従来1000人月規模を要していた企業向けSaaSプラットフォームや、基幹システムが、AIエージェントを効果的に活用することで、わずか2-3名のチームが数日から数週間で実装可能になるという、開発生産性の劇的な向上について考察してまいります。

これは単なる効率化ではなく、ソフトウェア産業のビジネスモデル、競争環境、そして人材要件すべてを再定義する、パラダイムシフトの始まりです。

本レポートのサマリー動画版は以下で公開しています

1000人月が3人日になる世界

AIエージェントを駆使することで実現する1000人月が3日の世界。

これは単なる効率化ではありません。ソフトウェア産業の根本的な構造変革の始まりです。

顧客管理システムが欲しければ、要件を自然言語で伝えるだけで、AIが数時間で完成させます。在庫管理ツールも、勤怠管理アプリも、マーケティング分析ダッシュボードも、すべてが「オーダーメイドの既製品」として瞬時に生成される世界。エンジニアリングの専門知識なしに、誰もがソフトウェアの作り手になれる「開発の民主化」が現実のものとなりつつあります。

しかし、この変化の本質は、効率化や民主化といった表層的な現象ではありません。

それはどういうことでしょうか。

基幹システムの変遷:変更不可能から瞬間生成へ

現在:変更が困難な巨大システム

現在、多くの企業の基幹システムは「変更が極めて困難」な状態にあります。

20年前に構築されたERP、レガシーなメインフレーム、巨大な統合データベース。これらの変更には膨大なコストと時間がかかり、下手に触ると全体が壊れるリスクがあり「怖くて手が出せない」状態にあるのではないでしょうか。

また年に1〜2回の大型アップデートが精一杯で、ビジネスの変化に追いつけません。

なぜこれほど変更が困難なのか。それは、開発に数億円、保守に年間数千万円という巨額の投資が必要だったからです。これだけの投資をしたシステムを、簡単に作り変えることはできません。

結果として、企業はシステムに合わせて業務を設計し、イノベーションは「システムの制約内」でしか起きませんでした。

移行期:分解と再構成が可能に

しかし、AIによる開発コストの劇的な低下は、この状況を根本から変えています。

1億円のシステムが100万円で作れるなら、毎月作り直しても元が取れる。この単純な経済原理が、基幹システムの在り方を変革します。

モノリシックな巨大システムは、数百の小さなサービスに分解されます。会計サービス、在庫管理サービス、顧客管理サービス。これらは独立して動き、必要に応じて組み合わさり、不要になれば入れ替えられます。

実は、この変化はすでに始まっています。多くの企業で、基幹システムの周辺から変革が進行中です。帳票出力、データ分析、外部連携など、以前は基幹システムの一部だった機能が、独立したサービスとして切り出され、必要に応じて入れ替えられるようになっています。

未来:瞬間的な生成と消滅

さらに開発コストがゼロに近づいた未来では、基幹システムは
必要な時に瞬間的に生成される」ものになります。

CEOが「今四半期は東南アジア展開に注力する」と決定すると、AIエージェント群が瞬時に反応します。多通貨対応エージェント、現地規制対応エージェント、物流最適化エージェントが結合し、一時的な「基幹システム」を形成。四半期が終われば、これらは再び分散し、次の戦略に応じた新たな構成を待ちます。

毎日生まれ、毎日消える基幹システム。データだけが永続し、機能は刹那的に生成と消滅を繰り返します。

使い捨てソフトウェアという新たなパラダイム

ソフトウェアの「消費財化」現象

この変革の過程で、ソフトウェアは「資産」から「消耗品」へ、そして最終的には「瞬間的な現象」へと変化していきます。

「3ヶ月だけ使う販促キャンペーン管理ツール」「今週の会議だけのための参加者調整システム」「この四半期限定の売上分析ダッシュボード」―こうした短期間・限定用途のソフトウェアを、必要な時に必要なだけ作り、用が済めば躊躇なく捨てる。

ある大手小売企業の事例を考えてみましょう。クリスマス商戦用の在庫最適化システムを、従来なら6ヶ月かけて開発していたものを、AIを活用して3日で構築。シーズンが終われば廃棄し、翌年はまた新たに作り直す。メンテナンスコストを考えれば、この方が経済的に合理的です。

技術的負債という概念の消滅

エンジニアリングの世界ではいつからこういう言葉が使われるようになったのか知りませんが、「技術的負債」が常に課題でした。

古いコード、複雑な依存関係、誰も触りたくないレガシーシステム。しかし、使い捨てソフトウェアの世界では、この概念自体が消滅します。

負債が溜まる前に捨てる。リファクタリングする代わりに作り直す。ドキュメントを書く代わりに、次回はAIに要件を伝え直す。

もはやコードの品質を長期的に維持する必要がなくなります。3ヶ月後には全部捨てるのですから、重要なのは今すぐ動くものを、今すぐ提供することだけ。

市場の多層構造化:3つのレイヤーの出現

この変革により、いわゆるSaaS市場は明確に3つの層に分離していくと思われます。

第1層:表層 - 無数の使い捨てツール群

最も表層には、日々生まれては消えていく無数の使い捨てツールが存在します。寿命は3-6ヶ月、時には数時間。特定のタスクに特化し、必要最小限の機能だけを提供。

これらのツールには名前すらありません。純粋に機能だけで勝負する世界です。

興味深いのは、これらのツールの開発者の多くが、プログラミング経験のないビジネスユーザーだということです。営業担当者が自分用の顧客フォローアップツールを作り、人事担当者が面接スケジュール管理システムを構築する。まさに「市民開発者」の時代です。
フルスタックエンジニアを自称していた私にとっては寂しい限りですが、確実に来る現実です。

第2層:中間層 - 専門特化SaaS

中間層には、使い捨てには適さない、特定領域に深く根ざしたSaaSが位置します。

医療機器の制御ソフトウェア、金融取引システム、産業用ロボットの制御システムなど。これらは規制要件、安全性、専門知識の観点から、簡単に置き換えることができません。

ただし、これらのSaaSも無縁ではありません。周辺機能―レポート作成、データ可視化、ユーザー管理など―は使い捨て(的にすぐに作れる、作り直せる)モジュールに置き換わっていき、コア機能だけが残る「ドーナツ化現象」が起きています。

第3層:基盤層 - インフラ的SaaS

最も深い層には、使い捨てソフトウェアを支える基盤そのものが存在します。

AIモデルのAPI、コンテナ実行環境、データストレージ、認証基盤。これらは使い捨てツールが依存する「不動のインフラ」として、むしろ重要性を増していきます。

MicrosoftのAzure、AmazonのAWS、GoogleのCloud Platform―これらは無数のアプリケーションを支える土台として、盤石な地位を築いていきます。

価値軸の根本的シフト:永続するものと消えるもの

無限の中の有限を見出す

使い捨てソフトウェア時代の本質は、

「機能の無価値化」と「意味の高価値化」の同時進行です。

どんな複雑な機能も、AIエージェントが瞬時に生成できる。コストは限りなくゼロに近づく。このとき

企業に残る資産は、ソフトウェアではなく、それを使う「理由」と「関係性」、そして「安心」だけです。

新時代の6つの価値軸

1. データという新たな聖域

すべてが使い捨てになる時代、データだけは聖域として残ります。顧客との対話の歴史、失敗と成功の記録、判断の軌跡。これらの「文脈を持ったデータ」こそが、無限のAIエージェントに方向性を与える羅針盤となります。

2. 関係性という不可視の資産

ソフトウェアが瞬時に生成できても、関係性は時間をかけてしか築けません。CRMシステムは一瞬で作れても、顧客との10年の信頼関係は作れない。この「時間でしか作れないもの」の価値が、相対的に無限大に近づいていきます。

3. 「安心」という見えない商品

機能だけでなく「安心」を売る―これが新時代の競争軸となります

AIが生成したツールは高機能かもしれません。しかし、

「誰が作ったかわからない」

「トラブル時に誰に連絡すればいいかわからない」

「明日も存在するか保証がない」

こうした不安を抱えたツールを、企業の基幹業務に使うことはできません。

24時間365日の日本語サポート、障害時の迅速な対応、データ消失時の補償―これらの「安心」は、AIには生成できません。人間が時間をかけて築き上げ、責任を持って提供する必要があります。

4. 責任を取る勇気

AIエージェントが無限に機能を生成する時代、最後に残る人間の役割は「責任を取ること」です。

システム障害が起きたとき、データが消失したとき、セキュリティインシデントが発生したとき―誰が責任を取るのか。この問いに明確に答えられることが、使い捨て時代の最大の価値となります。

5. 美意識と倫理観

機能が無限に生成できる時代、「できる」と「すべき」の境界を定めるのは人間の美意識と倫理観です。この「選ばない勇気」「作らない美学」が、企業の姿勢としても個人の態度としても問われるのではないでしょうか。AIは何でも作れるようになりますが、なにをやっていいか、なにをやってはいけないか、作る側の理性が問われます。

日本市場における使い捨て時代の特殊性

「安心」を最優先する日本企業

さて、ロマンを含んだ近未来を想像してみましたが、もう少し現実に焦点をあててみましょう。私たちの住む日本にはソフトウェアやSaaSに対し特有の視点があります。それはふりかえりながら、少し考察してみましょう。

わたしたち日本企業がSaaSを選定する際、機能比較表で最も多くの「○」がついた製品が選ばれるわけではありません。

ある大手製造業の情報システム部門の現実を見てみましょう。

「機能が優れていても、担当者が辞めたら終わり、会社が潰れたら終わり、問い合わせても返事が来ない、そんなサービスは怖くて使えません。うちの業務を止めるわけにはいかないんです」

実際、日本市場で成功している外資系SaaSを見ると、興味深い共通点があります。Salesforce、Microsoft、SAPなど、いずれも日本法人を設立し、日本語での電話サポートを提供し、日本の商慣習に合わせた請求書発行に対応しています。それだけでなく、大企業向けには社内組織までつくって手厚くサポートします。これは機能的に優れた競合が多数存在する中でも、この「日本対応」こそが選ばれる決定的な理由となっているのです。海外でどれだけ流行っても日本ではサッパリというサービスはこの「サポート」不足によるものも多いということは、我々のようにSaaSを提供してるAI企業も心にとめておかなければいけません^^

使い捨て時代における「責任の所在」問題

またAIで誰でもソフトウェアを作れる時代、日本企業の「責任の所在」への要求はむしろ強まる可能性があります。

「このツール、便利だから使おう」という判断は、日本企業ではほぼあり得ません。障害時の対応窓口、データ漏洩時の責任、仕様変更時の相談先―これらが明確でない限り、どんなに優れたツールも採用されません。

使い捨てツールの開発者が個人や小規模チームの場合、この責任を負える体制があるのか。「何かあったときに誰が責任を取るのか」が明確でない限り、日本市場での普及は困難、という現実があります。

サポートが生み出す逆説的な価値

みなさまお気づきでしょか。

興味深いことに、開発が自動化される時代だからこそ、人間によるサポートの価値が相対的に高まります。

「このボタンの位置を3ピクセル右に」「帳票の印字順序を部署コード順に変更」「年度末の特殊処理に対応」―日本企業からベンダーへの要求は、時に驚くほど細やかです。そして重要なのは、これらの要求に「」が対応することへの期待です。

AIがサクっと生成したツールに、こうした細やかな要求への対応を(AIだけに)期待することはできません。

結果として、「機能はAIが作る、サポート(と微調整)は人間が提供する」というハイブリッドモデルが、日本市場では主流になる可能性があります。

日本型ハイブリッドモデルの可能性

現実的な選択は、使い捨ての「効率性」と、日本的な「安心」を両立させることかもしれません。

コア機能は安定基盤として維持

  • ミッションクリティカルなデータは絶対に守る
  • 法規制に関わる処理は慎重に扱う
  • 顧客との約束事は永続的に保持
  • 24時間365日のサポート体制を維持

周辺機能は積極的に使い捨て化

  • レポート機能から使い捨て化を始める
  • 分析ツールは必要に応じて生成
  • UIは頻繁に作り直す
  • 実験的プロジェクトで大胆に活用

この「守りと攻めの二正面作戦」が、日本企業の現実的な選択となるでしょう。

関係性と安心という日本の強み

実は、この「安心重視」の文化は、日本企業にとって大きなチャンスかもしれません。

グローバル市場では過剰とされる手厚いサポート、細やかなカスタマイズ対応、長期的な関係性の構築―これらは、機能が無限に生成できる時代にこそ、真の差別化要因となります。

「なぜうちから買うのか」―この問いに、機能ではなく、「安心」と「信頼」で答えられる企業。それこそが、使い捨て時代を生き抜く日本企業の姿です。

人間とAIエージェントの新たな関係

オーケストレーターとしての人間

使い捨てソフトウェアが増えれば増えるほど、人間の役割は「作る」から「orchestrate(編成)する」へとシフトします。

1日に100個のAIエージェントが生成され、50個が消滅する世界。人間にはもはや個々のツールを管理することは不可能です。代わりに、AIエージェント群に「どの領域のツールを作らせるか」「どの基準で廃棄させるか」という方針を示すことが、人間の主要な仕事となります。

判断と実行の完全分離

人間の領域:
- なぜ(Why):目的の設定
- 何を(What):ゴールの定義  
- いつ(When):タイミングの判断
- 誰に(Who):責任の引き受け

AIの領域:
- どうやって(How):方法の生成
- どれくらい(How much):リソースの最適化
- どこで(Where):実行環境の選択

この分離が進むほど、人間は「哲学者」と「保証人」の二つの役割を担うことになります。

産業構造への破壊的インパクト

SIビジネスから「安心提供業」への転換

日本のIT産業を支えてきたSIer(システムインテグレーター)は、根本的な変革を迫られています。

従来のSIビジネスは、大規模な初期開発と長期保守契約で成り立っていました。しかし、使い捨てソフトウェアの世界では、この構造が成立しません。

代わりに生まれるのは「安心提供業」とでも呼ぶべき新たなビジネスモデルです。

安心保証サービス

  • AIが生成したツールの品質保証
  • 24時間365日の日本語サポート
  • トラブル時の責任引き受け
  • データ消失時の補償

関係性管理サービス

  • 顧客との長期的関係構築
  • ステークホルダー間の調整
  • 信頼の醸成と維持

これらは、AIには提供できない、人間にしかできないサービスです。

新たな職能:セーフティネット・マネージャー

使い捨て時代には、新しい職種が生まれるかもしれません

セーフティネット・マネージャーの役割

  • 使い捨てツール群のリスク評価
  • 障害時の対応体制構築
  • ステークホルダーへの説明責任
  • 「安心」の可視化と提供

これは、技術力よりも信頼構築力、コーディング能力よりもコミュニケーション能力が求められる役割です。

まとめ:効率と安心の新たな均衡

使い捨てソフトウェア時代の到来は、単なる技術革新ではありません。それは、ソフトウェア産業の根本的な前提を覆すパラダイムシフトです。

しかし、すべてが使い捨てになるわけではありません。むしろ、この変化によって「永続的な価値」がより鮮明に浮かび上がります。

データ、関係性、責任、物語、美意識、そして「安心」―これらの人間的な要素こそが、最後に残る価値ではないでしょうか。

特に日本市場では、「安心」という見えない商品が、最も重要な競争軸となる可能性があります。機能は瞬時に作れても、安心は時間をかけてしか作れない。AIが無限にツールを生成できても、責任を取れるのは人間だけ。この逆説的な状況が、新たなビジネスチャンスを生み出します。

重要なのは、使い捨ての「効率性」と、日本的な「安心」を対立概念として捉えるのではなく、両立させる道を見出すことです。機能の生成はAIに任せ、安心の提供は人間が担う。この役割分担が、日本型DXの現実解となるでしょう。

AIによるソフトウェア開発の民主化がもたらす産業構造の転換

本稿では「使い捨て」というやや刺激的な表現をあえて用いましたが、これは決して品質軽視を推奨するものではありません。金融・医療といったミッションクリティカルな領域において、厳格な品質管理と信頼性への要求が緩和されることはないでしょう。

しかし、AIエージェントの急速な進化により、ソフトウェアの生成・修正が瞬時に可能となる時代において、我々は根本的な問いに直面しています。

数十年にわたり確立されてきた開発方法論、品質保証体系、そして価値創造モデル――これらすべてが再定義を迫られています。

この技術革新の波において重要なのは、以下の戦略的問いへの回答です

  • 自動化が進展する中で、人間にしか提供できない価値とは何か
  • 既存の開発プロセスのうち、本質的に残すべきコア・コンピタンスは何か
  • 新たな技術パラダイムにおける競争優位性をどう構築するか

変革は既に始まっています。この転換期における戦略的ポジショニングが、今後の企業競争力を決定づけることになるでしょう。

弊社コンサルティング部門では、ソフトウェアの即時生成やAIエージェントの急速な普及により事業環境が劇的に変化する中、次世代の経営戦略・技術戦略・新規事業開発を包括的にご支援いたします。

25年以上にわたりソフトウェア業界の最前線で実績を積み重ねたスペシャリスト、およびグローバル企業の経営戦略策定に従事してきたシニアコンサルタントが、貴社の持続的成長に向けた実践的なソリューションをご提供いたします。

詳細については、下記までお問い合わせください。貴社のビジネス課題に応じた最適なご提案をさせていただきます。

https://qualiteg.com/contact?inquiry=consulting

次回予告:少数精鋭の逆襲

この究極の使い捨て時代において、2-3人の小規模チームはどのような戦略で戦うのか。

興味深いことに、「安心」を重視する日本市場は、小規模チームにとって高い参入障壁となります。しかし、この障壁を突破できた者には、強固な競争優位がもたらされます。

次回は、少数精鋭チームが日本市場で成功するための戦略を詳しく解説します。「顔の見える安心」「超高速対応による信頼構築」「コミュニティを味方につける」など、小規模だからこそできる「安心」の提供方法とは。

さらに、その次の連載では、そのような時代における「大企業の戦い方」についても論じてみたいと思います。

Read more

NVIDIA GeForce RTX 50xx with CUDA capability sm_120 is not compatible with the current PyTorch installation. が発生したとき

NVIDIA GeForce RTX 50xx with CUDA capability sm_120 is not compatible with the current PyTorch installation. が発生したとき

こんにちは、PyTorch 2.6.0 環境で以下のような問題が発生したときの対処方法について解説いたします。 NVIDIA GeForce RTX 5090 with CUDA capability sm_120 is not compatible with the current PyTorch installation. The current PyTorch install supports CUDA capabilities sm_50 sm_60 sm_70 sm_75 sm_80 sm_86 sm_90. 他のBlackwell GeForce の場合は以下のようなメッセージとなります。 NVIDIA GeForce RTX

By Qualiteg プロダクト開発部
OpenCV cv2.imwrite で発生する「_img.empty()」エラーと「動画安定化」による解決法

OpenCV cv2.imwrite で発生する「_img.empty()」エラーと「動画安定化」による解決法

こんにちは! 画像処理や動画解析の現場で広く利用されている OpenCV。 しかし実務で動画処理を行っていると、時折以下のようなエラーに遭遇することがあります。 cv2.error: OpenCV(4.11.0) /io/opencv/modules/imgcodecs/src/loadsave.cpp:929: error: (-215:Assertion failed) !_img.empty() in function 'imwrite' このエラーは、cv2.imwrite() に渡された画像が空(None またはサイズ0) の場合に発生します。 一見単純に見える問題ですが、背後には「入力動画の不安定さ」や「並列処理の競合」といった要因が潜んでいることが少なくありません。 本記事では、このエラーの発生原因を掘り下げ、実務で効果のある解決策として 「動画の安定化(正規化)」 を紹介します。 TL;

By Qualiteg プロダクト開発部
発話音声からリアルなリップシンクを生成する技術 第5回(前編):Transformerの実装と実践的な技術選択

発話音声からリアルなリップシンクを生成する技術 第5回(前編):Transformerの実装と実践的な技術選択

こんにちは!リップシンク技術シリーズもいよいよ終盤となりました。 前回(第4回)では、LSTMの学習プロセスと限界について詳しく解説しました。限られたデータでも効果的に学習できるLSTMの強みを理解する一方で、長距離依存の処理に限界があることも明らかになりました。そして、この問題を解決する革新的なアプローチとして、すべての位置の情報を同時に参照できるTransformerのSelf-Attention機構を紹介しました。 第5回の今回は、 Transformerの具体的なネットワーク設計から始め、その実装上の課題を明らかにします。(前編※) そして、LSTMとTransformerの長所を組み合わせたハイブリッドアプローチを紹介し、実際の製品開発における技術選択の指針を示します。最後に、感情表現への拡張という次なる挑戦についても触れていきます。(後編※) ※Transformerの仕組みは複雑であるため、第5回は前編と後編に分けて解説させていただく予定です。 1. Transformerベースのネットワーク設計 1.1 全体アーキテクチャ図 では、さっそく、Tran

By Qualiteg 研究部, Qualiteg コンサルティング
大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第2回 ドメイン環境の構築

大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第2回 ドメイン環境の構築

こんにちは、今回はシリーズ第2回ドメイン環境の構築 - 検証環境の構築手順について解説いたします! 連載の構成 第1章:基本概念の理解 - Active DirectoryとKerberos/NTLM認証の基礎 【★今回です★】第2章:ドメイン環境の構築 - 検証環境の構築手順 第3章:クライアントとサーバーのドメイン参加 - ドメイン参加の詳細手順 第4章:プロキシサーバーと統合Windows認証 第5章:ブラウザ設定と認証 - 各ブラウザでの設定方法 第6章:トラブルシューティング - よくある問題と解決方法 第7章:セキュリティとベストプラクティス - 本番環境での考慮事項 第8章:実践的な構成例 - AIセキュリティツールとの統合事例 第2章:ドメイン環境の構築 2.1 ドメイン名の設計 2.1.1 ドメイン名の命名規則 Active Directoryを構築する際、

By Qualiteg コンサルティング