Retoolが提供
以前はこうした論理でした。ほとんどのユースケースでは、ソフトウェアを買うほうが安く、速く、安全でした。ビルドは、大規模なエンジニアリングチーム、潤沢な資金、そしてベンダーが対応できないほど特殊な問題を抱えた企業に限られていました。しかし今は、ソフトウェアの一部をコード化するコストがゼロになっています。
誰もが自分でソフトウェアを作れるようになりましたが、エンタープライズやガバナンスのモデルはまだ追いついていません。Retoolの2026 Build vs. Buy Shift Reportは、817人のビルダーへの調査に基づき、この変化がどのように進行しているかを正確に追跡しています。
コスト曲線は変わったが、SaaSの価格は変わっていない
2年前なら、社内向けのカスタムツールはエンジニアリングチームが数週間から数か月を費やし、費用は6桁にのぼることもありました。ところが現在では、適切なプラットフォームを使えるオペレーションリードなら、1日か2日で動くプロトタイプを作れるかもしれません。この構造的な変化は、AI支援による開発と、エンタープライズ向けアプリ構築プラットフォームの成熟によってもたらされています。
一方で、SaaSの価格設定は調整されていません。一般的なソフトウェアに対して席数課金のままで、そこにカスタマイズや統合のコストが上乗せされます。ビルドのコストが1桁ではなく桁違いに下がったのに、買うコストが横ばいなら、変わるのは大規模なエンジニアリングチームを抱える企業だけではありません。すべての企業の計算が変わります。
データがそれを裏付けています。Retoolのレポートでは、35%のチームが少なくとも1つのSaaSツールをカスタムビルドに置き換え済みであり、78%が2026年にさらにカスタムツールを作る計画だと分かりました。
ワークフロー自動化や管理ツールは、SaaSの中でもリスクが高い
変化は一様に起きているわけではありません。回答者が置き換えた、あるいは置き換えを検討した主要なSaaSツールには、ワークフロー自動化（35%）と社内向けの管理ツール（33%）が含まれ、その次がBIツール（29%）とCRM（25%）です。
購入したワークフロー自動化ツールは、数千の顧客に対応しなければならないため、平均的なケース向けに最適化されます――しかし平均的なケースは、誰の実際のケースでもありません。各社の社内ワークフローはそれぞれ異なります。組織の構造、コンプライアンス要件、データシステム、そしてその組織固有の業務ロジックに反映されるからです。
社内向けの管理ツールにも同じ問題があります。そもそも会社ごとに固有のものだからです。これらのカテゴリはもともと市販ソフトに当てはめるのが難しい領域でしたが、今は手頃で利用しやすい代替策があります（MITのState of AI in Businessでは、顧客サービスや文書処理のタスクで、毎年200万〜1000万ドルの節約が報告されています）。
置き換えのパターンは、全面的に入れ替えるというより「追加的」になりがちです（誰も単にSalesforceを丸ごと放り出してはいません）。うまく合わなかった特定の部分を置き換えるのです。たとえば3つの回避策が必要だった承認フロー、実データに接続できなかったダッシュボード……。しかし、そのような狭い置き換えも積み重なれば大きな差になります。チームが、購入したものよりうまく動くツールを1つ作った瞬間、デフォルトの問いは「何を買うべきか？」から「これを作れるか？」へと変わります。
ビルダーはITを迂回する傾向があり、調達の課題がより広範に存在することを示す
調達プロセスが、ビルド能力の拡大に追いついていないことを最も明確に示すのは、企業内で今起きているシャドーITの規模です。Retoolのレポートでは、ビルダーの60%が過去1年にITの監督外でツール、ワークフロー、または自動化を作ったと回答しており、さらに25%はそれを頻繁に行っていると報告しています。
経験を積み、判断力もある人ほど、プロセスよりスピードを選びます。全回答者の3分の2（64%）がシニアマネージャー以上です。既存の調達サイクルは、「ソフトウェアの作成に数か月ではなく数日かかる世界」のために設計されていません。人々が生成AIの試行の失敗率95%を引用したとしても、経営層のすぐ鼻先で進行している、堅実な草の根の導入については織り込まれていません。
この規模でのシャドーITは需要のサインです。問題に最も近い人たちが、既存のプロセスでは追いつけないのだと組織に伝えています――ITを迂回している人の31%は、単にITがツールを払い出すより自分のほうが速く作れるからそうしているのです。つまり、抑え込むことは生産的な対応ではありません。問題は、影で作られているツールは、役に立つ前に止まりやすいのもまた、そのツールだということです。
サンプルデータで動く「雰囲気コード」なプロトタイプは印象的です。実際のSalesforceインスタンスに接続され、ロールベースのアクセスとセキュリティレビューがあるプロダクションツールは役に立ちます。このレポートでは、ビルダーの51%が現在、チームで実際に使われているプロダクションソフトウェアを出荷済みであり、そのうち約半数が「週に6時間以上節約できている」と報告しています。
ガバナンスのない環境でビルドが行われると、組織は確実にどちらの成果も得られません。誰かが先週火曜にプロダクションデータへ接続して作ったプロトタイプに、監査証跡も、アクセス制御も、責任者もないままAIを組み込んでしまうことがあります。これを組織内で十数人のビルダーがそれぞれやってしまえば、ITですら存在を把握していないような、拡大するセキュリティ領域が生まれます。[1]
自社で作ったソリューションがプロダクションに到達するチームには、他とは異なる3つの共通点があります。現実のデータソースへの接続、信頼できるセキュリティと権限のモデル、そして何がデプロイされるかに関するレビュー工程です。スピードとセキュリティが対立しないガバナンスのある環境へビルダーのエネルギーを振り向けることが、シャドーITを負債化させない方法です。
ガバナンスが、次のSaaS時代を定義する
ビルド対買いのシフトは、すでに進行中です。今、より重要な問いは、そのビルドが行われる環境を誰が管理するのか、ということです。
ガバナンスのないビルドは、セキュリティ上のリスクを招くだけでなく、 ROIの説明を成立させにくくします。ITが存在を把握していないツールや、特定の個人のワークフローでしか動かないツールによって節約できた時間は測れません。先週火曜にプロダクションデータへ接続したプロトタイプに対して、アクセス制御を強制することもできません。これらは仮想のリスクではありません。Deloitteの2026 State of AI in the Enterpriseの3,200人超のリーダーへの調査では、データプライバシーとセキュリティが73%でAIに対する最大の懸念として順位付けされ、ガバナンス能力がそれに続いて46%でした。AI生産性の指標がない35%の組織は、ダッシュボードを欠いているだけではありません。そもそも「買うより作る」という判断を正当化する説明責任のための基盤が欠けているのです。
ガバナンスのある環境を、規模を持ってビルドするための前提条件だと捉える組織こそが、本当に機能していることを実証できるでしょう。できない組織は、何かが壊れたときにそれを知ることになります。
データの詳細（企業がAI支援によるビルドへどう取り組んでいるかを含む）については、完全版の 2026 Build vs. Buy Shift Reportをご覧ください。
[1] そのコストは高くつく可能性があります。 IBMの2025 Cost of Data Breach Reportによれば、AIに関連したケースでは、違反1件あたりで組織が65万ドル超を上回るコストを負担したことが分かりました。
David HsuはRetoolのCEOです。
スポンサー記事は、投稿に対して支払いをしている会社、またはVentureBeatとビジネス上の関係を持つ会社によって制作されたコンテンツであり、常に明確に表示されています。詳細は sales@venturebeat.comまでお問い合わせください。
