3社に1社が「そのソフトは買わない」と決めた ― 稟議に載らないまま、保守だけが自社に移る
カテゴリに戻る
AI導入戦略 / ROI・投資判断2026.09.0113分

3社に1社が「そのソフトは買わない」と決めた ― 稟議に載らないまま、保守だけが自社に移る

多くの企業では、ソフトウェアを買うときに稟議が回る。相見積もりを取り、ベンダー審査をかけ、契約書を法務が確認し、稟議書が決裁される。この一連の記録が、後から「なぜこれを使っているのか」を説明する根拠になる。

いま静かに増えているのは、その反対側の判断である。「買わない」と決めるケースだ。そして買わない判断には、稟議書も契約書もベンダー審査も残らない。

2026年8月に公表された McKinsey の年次調査は、この動きを初めて数字で捉えた。

3社に1社が、購入を見送っていた

業種別に見た「買わずに作る」を選んだ企業の割合を示す横棒グラフ。エージェント型コーディングツールで内製できるためソフトウェア購入を見送った組織は全体で約32%。業種別では技術41%、ヘルスケア(保険者・医療機関)39%、プロフェッショナルサービス38%、エネルギー・素材38%、金融機関36%、メディア・通信34%、製薬・医療機器33%、保険19%、公共・社会セクター17%。規制産業ほど比率は低いが、金融36%・ヘルスケア39%という水準は、規制の厳しさが歯止めになっていないことを示す。出典はMcKinsey「The State of AI in 2026」、2026年8月公表、回答1,719名

業種別に見た「買わずに作る」を選んだ企業の割合を示す横棒グラフ。エージェント型コーディングツールで内製できるためソフトウェア購入を見送った組織は全体で約32%。業種別では技術41%、ヘルスケア(保険者・医療機関)39%、プロフェッショナルサービス38%、エネルギー・素材38%、金融機関36%、メディア・通信34%、製薬・医療機器33%、保険19%、公共・社会セクター17%。規制産業ほど比率は低いが、金融36%・ヘルスケア39%という水準は、規制の厳しさが歯止めになっていないことを示す。出典はMcKinsey「The State of AI in 2026」、2026年8月公表、回答1,719名

McKinsey が2026年8月に公表した 「The State of AI in 2026」(回答者1,719名)によれば、約32%の組織が、エージェント型コーディングツールで内製できるという理由で、少なくとも1つのソフトウェア製品または機能の購入を見送っていた

業種別に見ると、技術41%、ヘルスケア(保険者・医療機関)39%、プロフェッショナルサービスとエネルギー・素材が38%、金融機関36%、メディア・通信34%、製薬・医療機器33%と続く。保険19%、公共・社会セクター17%は低いが、金融とヘルスケアが4割弱に達している点は見逃せない。規制の厳しさは、この動きの歯止めになっていない。

同じ調査では、年商10億ドル超の大企業のうち エージェントを1つ以上の機能で本格展開している割合が27%から40%に上昇した。中小規模は22%で横ばいである。つまりこの変化は、大企業側で先に起きている。

McKinsey のシニアパートナー Lieven Van der Veken 氏は「リーダーたちは、自分たちでAIツールを作るために組織に何が必要かを問い始めている」と述べている。問いが「どのベンダーを選ぶか」から「自分たちで作れるか」に移ったということだ。

買わない判断は、調達プロセスを通っていない

Retoolの調査結果を示す図。「The Build vs. Buy Shift」817名回答、2025年後半調査。3つの数字が並ぶ。置き換え済み35%(SaaSツールを1つ以上、自社開発に置き換えた)、今後の意向78%(2026年はさらに社内ツールを内製すると回答)、調達の外60%(その内製は正式な調達プロセスの外で発生)。なぜ経営に見えないのかとして3点。買えば契約・稟議・ベンダー審査が残るが、作れば何も残らない。購入を見送った判断はコスト削減としても投資としても計上されない。結果、意思決定した記録がないまま保守責任だけが自社に発生する。買わないは決裁事項として扱われていないが、実質的には最も重い調達判断である。なおRetoolは内製ツール基盤のベンダーであり、自社顧客・ビルダー層への調査である点は割り引いて読む必要がある

Retoolの調査結果を示す図。「The Build vs. Buy Shift」817名回答、2025年後半調査。3つの数字が並ぶ。置き換え済み35%(SaaSツールを1つ以上、自社開発に置き換えた)、今後の意向78%(2026年はさらに社内ツールを内製すると回答)、調達の外60%(その内製は正式な調達プロセスの外で発生)。なぜ経営に見えないのかとして3点。買えば契約・稟議・ベンダー審査が残るが、作れば何も残らない。購入を見送った判断はコスト削減としても投資としても計上されない。結果、意思決定した記録がないまま保守責任だけが自社に発生する。買わないは決裁事項として扱われていないが、実質的には最も重い調達判断である。なおRetoolは内製ツール基盤のベンダーであり、自社顧客・ビルダー層への調査である点は割り引いて読む必要がある

内製ツール基盤を提供する Retool が2025年後半に実施した調査(817名回答、レポート名は「The Build vs. Buy Shift: How Vibe Coding and Shadow IT Have Reshaped Enterprise Software」)は、この現象の質感をより具体的に示している。

  • 35% が、SaaSツールを1つ以上、自社開発に置き換え済み
  • 78% が、2026年はさらに社内ツールを内製すると回答
  • そして、その内製の60%は正式な調達プロセスの外で起きていた

Retool は内製基盤のベンダーであり、回答者はその顧客層である。数字そのものは割り引いて読む必要がある。だが「調達の外で起きている」という構造の指摘は、McKinsey の32%と矛盾しない。

問題は割合ではなく、記録が残らないことにある。

買えば、契約・稟議・ベンダー審査という3種類の記録が残る。作れば、コミット履歴以外に何も残らない。「購入を見送った」という判断は、コスト削減としても投資としても会計に現れない。意思決定した事実そのものが、経営の視界に入らない。

そして、記録が残らないまま移動しているものがある。保守責任である。

SaaSライセンスに、実は何が含まれていたのか

SaaSライセンスに含まれていたものが内製に切り替えた後どこへ行くかを示す図。ライセンス料に含まれていたものは、脆弱性の発見とパッチ提供、OSや依存ライブラリ更新への追随、SLAと障害対応の当番体制、第三者認証・監査への回答(SOC 2等)、法改正・制度変更への機能追随、事業継続とデータ移行手段、作った担当者が辞めても続くこと。内製に切り替えた後の請求先はすべて自社であり、多くの場合は情報システム部門の定員は増えない。請求書は来ないが工数として毎年発生し、発生するのは作った翌年度以降で、その頃には作った本人は別の部署にいる。実測データとして、Escape.techの本番稼働アプリ調査で1,400アプリ中2,038件の重大脆弱性と秘密情報400件超・個人情報175件、Georgia Tech Vibe Security RadarではAI生成コード起因のCVEが2026年1月6件から2月15件、3月35件へ増加、ApiiroのFortune 50での計測ではセキュリティ検出件数が月1,000件から1万件へ増え権限昇格経路が322%増加。作る速度が上がった分だけ検証・修正・監査の負荷も同じ倍率で上がっている

SaaSライセンスに含まれていたものが内製に切り替えた後どこへ行くかを示す図。ライセンス料に含まれていたものは、脆弱性の発見とパッチ提供、OSや依存ライブラリ更新への追随、SLAと障害対応の当番体制、第三者認証・監査への回答(SOC 2等)、法改正・制度変更への機能追随、事業継続とデータ移行手段、作った担当者が辞めても続くこと。内製に切り替えた後の請求先はすべて自社であり、多くの場合は情報システム部門の定員は増えない。請求書は来ないが工数として毎年発生し、発生するのは作った翌年度以降で、その頃には作った本人は別の部署にいる。実測データとして、Escape.techの本番稼働アプリ調査で1,400アプリ中2,038件の重大脆弱性と秘密情報400件超・個人情報175件、Georgia Tech Vibe Security RadarではAI生成コード起因のCVEが2026年1月6件から2月15件、3月35件へ増加、ApiiroのFortune 50での計測ではセキュリティ検出件数が月1,000件から1万件へ増え権限昇格経路が322%増加。作る速度が上がった分だけ検証・修正・監査の負荷も同じ倍率で上がっている

「作れるなら作ったほうが安い」という判断は、開発コストだけを比較している。だがSaaSのライセンス料に含まれていたのは、機能だけではない。

  • 脆弱性の発見とパッチ提供
  • OS・依存ライブラリの更新への追随
  • SLA と障害対応の当番体制
  • 第三者認証・監査への回答(SOC 2 等)
  • 法改正・制度変更への機能追随
  • 事業継続とデータ移行の手段
  • 作った担当者が辞めても、動き続けること

これらは内製に切り替えた瞬間に消えるのではなく、自社に移動する。しかも請求書は来ない。工数として、翌年度以降に、静かに発生する。

その負荷は、すでに実測されている。Cloud Security Alliance が2026年にまとめたリサーチノートによれば、Georgia Tech の Vibe Security Radar が追跡した AI生成コード起因のCVEは、2026年1月の6件から2月15件、3月35件へと2ヶ月で約6倍に増えた。セキュリティ企業 Escape.tech が本番稼働中のアプリを対象に実施した調査では、1,400アプリから2,038件の重大な脆弱性、400件超の秘密情報(APIキー・認証情報)、175件の個人情報露出が見つかっている。すべて、実際に稼働しているシステムでの検出である。

より示唆的なのは、Fortune 50 企業での計測データだ。Apiiro によれば、AI支援を受けた開発者のコミット量は同僚の3〜4倍に増える一方、セキュリティ検出件数は月あたり約1,000件から1万件超へと10倍に増え、権限昇格の経路は322%、アーキテクチャ上の設計欠陥は153%増加した。

Google の DORA レポートはこれを 「検証税(verification tax)」 と呼ぶ。生成の速度が上がった分、それが正しいか・安全か・既存アーキテクチャと整合するかを確認する工数が増える。開発が速くなっても、本番に載せる速度が同じだけ速くなるとは限らない。

それでも損益は動いていない

McKinseyのThe State of AI in 2026における導入から損益への距離を示す漏斗型の図。AIを全社規模でスケールさせている企業は44%、大企業でエージェントを1機能以上に展開しているのは40%で前年は27%、EBITへの影響があると回答したのは37%、EBITの5%以上をAIに帰属する高パフォーマーは6%。高パフォーマー6%は前年から変わっておらず、導入率とエージェント展開率は伸びたが損益に届く比率だけが1年間ほぼ動かなかった。差がついているのは作れるかどうかではなく、業務プロセスを作り替えたかどうかである

McKinseyのThe State of AI in 2026における導入から損益への距離を示す漏斗型の図。AIを全社規模でスケールさせている企業は44%、大企業でエージェントを1機能以上に展開しているのは40%で前年は27%、EBITへの影響があると回答したのは37%、EBITの5%以上をAIに帰属する高パフォーマーは6%。高パフォーマー6%は前年から変わっておらず、導入率とエージェント展開率は伸びたが損益に届く比率だけが1年間ほぼ動かなかった。差がついているのは作れるかどうかではなく、業務プロセスを作り替えたかどうかである

ここで、同じ McKinsey 調査のもう一方の数字を並べる必要がある。

AI を全社規模でスケールさせている組織は44%(前年38%)、3機能以上に展開している組織は56%(同51%)。導入は確実に進んでいる。ところが、EBIT への影響が「ある」と答えたのは37%にとどまり、EBITの5%以上をAIに帰属させる「高パフォーマー」は6%で、前年から変わっていない

つまり、1年間で伸びたのは「作れる」「動かせる」の側だけで、「損益に届く」の側は動いていない。

そしてこの構図は、内製化の議論にそのまま当てはまる。エージェント型コーディングで内製できるようになったことは、能力の問題を解いただけである。成果が出るかどうかを決めているのは、McKinsey が繰り返し指摘してきたとおり、業務プロセスそのものを作り替えたかどうかだ。

日本企業ではこの点がさらに厳しく出る。国内大企業の生成AI導入率は57.7%(野村総合研究所)に達している一方、AI投資を拡大する予定がある企業は67.2%あるのに対し、業務フロー再設計への投資は18.4%にとどまる(Mer「Japan AI Operations Report 2026 Summer」)。投資は増えているが、作り替えには向かっていない。

さらに日本固有の事情がある。JUAS「企業IT動向調査2026」(東証上場企業等4,500社に調査、957社回答)は、テーマとして「人とAIで未来を創る、新時代のIT部門像」を掲げた。裏を返せば、IT部門像の再定義がまだ途上ということだ。多くの日本企業は運用保守を外部委託する構造を長年とってきた。その構造のまま内製アプリだけが増えれば、作った瞬間に、誰の保守対象でもないシステムが生まれる。

「買わない」を、決裁事項に戻す

買わないを決裁事項に戻す5つの手当てを示す図。内製を止めるためではなく内製したものを本番で持ち続けるための施策。1つ目は購入見送りを申請様式に載せること。買う判断に稟議があるなら買わない判断にも同じ様式を用意し、記入必須は保守オーナー・想定寿命・退役条件の3項目でよい。2つ目は保守オーナーを作った人ではなく組織に置くこと。個人に紐づいた内製は異動・退職の時点で自動的にシャドーIT化するため、部署単位で受け皿を決め引き継ぎ様式を最初から用意する。3つ目は置き換えてよいSaaSの分類を先に決めること。社内の可視化ツールや管理画面は内製向きだが、基幹・決済・個人情報の一次管理は向かない。禁止リストではなく可逆性・データ区分・監査対象かという判断基準で書く。4つ目は内製アプリを既存の脆弱性管理の対象に入れること。ベンダーが出していたパッチ通知が来なくなるため、依存関係の棚卸しとスキャンを購入ソフトと同じ台帳・同じ頻度で回す。5つ目は効果を作れた数ではなく業務指標で測ること。内製本数やライセンス削減額ではなく差し戻し率・手戻り工数・処理リードタイムで測る。損益に届いているのは6%であり、作れた数を数えている限りその6%には入らない

買わないを決裁事項に戻す5つの手当てを示す図。内製を止めるためではなく内製したものを本番で持ち続けるための施策。1つ目は購入見送りを申請様式に載せること。買う判断に稟議があるなら買わない判断にも同じ様式を用意し、記入必須は保守オーナー・想定寿命・退役条件の3項目でよい。2つ目は保守オーナーを作った人ではなく組織に置くこと。個人に紐づいた内製は異動・退職の時点で自動的にシャドーIT化するため、部署単位で受け皿を決め引き継ぎ様式を最初から用意する。3つ目は置き換えてよいSaaSの分類を先に決めること。社内の可視化ツールや管理画面は内製向きだが、基幹・決済・個人情報の一次管理は向かない。禁止リストではなく可逆性・データ区分・監査対象かという判断基準で書く。4つ目は内製アプリを既存の脆弱性管理の対象に入れること。ベンダーが出していたパッチ通知が来なくなるため、依存関係の棚卸しとスキャンを購入ソフトと同じ台帳・同じ頻度で回す。5つ目は効果を作れた数ではなく業務指標で測ること。内製本数やライセンス削減額ではなく差し戻し率・手戻り工数・処理リードタイムで測る。損益に届いているのは6%であり、作れた数を数えている限りその6%には入らない

ここで必要なのは、内製を止めることではない。買わない判断を、買う判断と同じ重さで扱うことである。実務としては、次の5点に絞れる。

1. 「購入見送り」を申請様式に載せる。 買う判断に稟議があるなら、買わない判断にも同じ様式を用意する。記入必須は3項目でよい ―「保守オーナー」「想定寿命」「退役条件」。この3つが書けない内製は、翌年度に必ず問題になる。

2. 保守オーナーを、作った人ではなく組織に置く。 個人に紐づいた内製は、異動・退職の時点で自動的にシャドーITに変わる。部署単位で受け皿を決め、引き継ぎ様式を最初から用意しておく。

3. 「置き換えてよいSaaS」の分類を先に決める。 社内の可視化ツールや管理画面は内製向きだが、基幹・決済・個人情報の一次管理は向かない。禁止リストで書くと必ず抜け道ができる。可逆性・データ区分・監査対象かという判断基準で書く。

4. 内製アプリを、既存の脆弱性管理の台帳に入れる。 ベンダーからのパッチ通知が来なくなる分、依存関係の棚卸しとスキャンを自社で回す必要がある。購入ソフトと同じ台帳・同じ頻度で扱う。台帳に載らないものは、存在しないのと同じである。

5. 効果を「作れた数」ではなく業務指標で測る。 内製本数やライセンス削減額は、成果の代理指標としては弱い。差し戻し率・手戻り工数・処理リードタイムで測る。

まとめ ― 能力の問題は解けた。残ったのは設計の問題

Wizit の整理する「4つの壁」で言えば、この動きは一見すると人材の壁が下がった話に見える。作れる人がいなくても作れるようになったのだから、外注依存は減るはずだ。

だが実際に起きているのは、壁の場所が移動しただけである。作る局面の人材制約は緩んだ。代わりに、作ったものを持ち続ける局面に制約が寄った。保守・脆弱性対応・監査対応・引き継ぎ ― これらはエージェントが肩代わりしてくれる領域ではない。同時に、調達を通らない内製が増えることでガバナンスの壁が高くなり、作ったものが台帳にも載らず横展開もされないことで横展開の壁が残る。

高パフォーマーが6%から動かなかったという事実は、この構造を裏づけている。作れるようになっただけでは、損益は動かない。

Wizit は、大企業のAIをPoCで止めず、本番運用とROIまで動かし切ることを仕事にしている。その経験から言えば、内製化は目指すべき到達点である。ただしそれは「作れること」ではなく、「作ったものを本番で持ち続けられること」を指す。両者は別のケイパビリティであり、前者だけを手に入れた組織は、翌年度に保守の請求書を受け取る。

自社の今期の「見送ったソフトウェア購入」を数えてみてほしい。そのリストは、どこかに存在しているだろうか。 存在していないなら、それは買わなかったのではなく、記録せずに作ったということである。

---

出典:

  • McKinsey「The State of AI in 2026」(2026年8月公表、回答1,719名。エージェント型コーディングによる購入見送り約32%と業種別内訳、大企業のエージェント展開27%→40%、全社スケール44%、3機能以上56%、EBIT影響37%、高パフォーマー6%。Lieven Van der Veken 氏コメント)
  • The Register「McKinsey says enterprise AI is finally 'on the road to ROI'」(2026年8月25日)
  • Retool「The Build vs. Buy Shift: How Vibe Coding and Shadow IT Have Reshaped Enterprise Software」(2026年公表、817名回答・2025年後半調査。SaaS置き換え35%、内製拡大意向78%、調達外での内製60%)
  • Cloud Security Alliance リサーチノート「Vibe Coding's Security Debt: The AI-Generated CVE Surge」(2026年。Georgia Tech Vibe Security Radar のCVE件数、Apiiro による Fortune 50 での計測、Veracode・Snyk 調査の引用)
  • Escape.tech「The State of Security of Vibe Coded Apps」(本番稼働アプリの脆弱性・秘密情報・個人情報の検出結果)
  • Google DORA「Balancing AI tensions: Moving from AI adoption to effective SDLC use」(検証税、スループットと不安定性の同時上昇)
  • 野村総合研究所(国内大企業の生成AI導入率57.7%、業種別内訳)
  • 株式会社Mer「Japan AI Operations Report 2026 Summer」(2026年8月6日公表。AI投資拡大予定67.2%、業務フロー再設計への投資18.4%)
  • JUAS「企業IT動向調査2026」(2025年9月5日〜10月24日調査、東証上場企業等4,500社対象・957社回答。テーマ「人とAIで未来を創る、新時代のIT部門像」)

AI活用のご相談はWizitへ

3社に1社が「そのソフトは買わない」と決めた ― 稟議に載らないまま、保守だけが自社に移る | 株式会社Wizit