「そのSaaS、買わずに自分たちで作れないか」——2026年、この問いが会議室で本気で交わされるようになりました。きっかけは、エージェント型のコーディングツール（Codex や Claude Code のような、指示を受けて自律的にコードを書き・テストし・統合まで進める“ハーネス”）が、カスタムソフトを立ち上げる初期コストを大きく引き下げたことです。McKinsey が2026年8月25日に公表した「The State of AI: Global Survey 2026」は、この変化を数字で裏づけました。
homula はエンタープライズ向けの AIエージェント・インテグレーターとして、日本企業の「戦略 → PoC → 実装 → 運用 → 内製化」を一気通貫で支援しています。本稿では、この「作るか買うか（build vs buy）」の分岐点が動いたという事実を確認したうえで、その先で必ず立ち上がる“運用の請求書”——保守・セキュリティ・統制のコスト——にどう向き合うかを、実務目線で整理します。
「作るか買うか」の線が動いた——McKinseyが捉えた32%
McKinsey の2026年調査は、97カ国・1,719人の回答者を対象に、2026年5月4日〜6月8日に実施されたものです（McKinsey）。最も目を引く発見はこれです。
回答企業の 32% が、「エージェント型コーディングツールで社内構築できる」として、1つ以上のソフトウェア製品・機能の購入を見送った。
この「見送り」は業種で濃淡があります。報道によれば、テクノロジー業界が 41% で最も高く、ヘルスケアのペイヤー・プロバイダーが 39% で続きます（Yahoo Finance・2026年8月）。さらに、AI で成果を出している「ハイパフォーマー」——EBIT の5%以上をAI由来と回答した6%の企業——では、約半数が購入を見送っており、それ以外の企業の 31% を大きく上回ります。
つまり「作る」は、一部の先進企業の特殊事情ではなく、ふつうの企業の3社に1社が現実に選び始めた選択肢になりました。背景には、大企業で「1つ以上の業務にエージェントを本格展開している」割合が 27%から40%へ 上がったという、同調査の別の数字もあります。
なぜ今なのか——エージェント型コーディングが『作る』側のコストを崩した
「作る」がここまで身近になったのは、AI が単に“賢く”なったからではありません。カスタムソフトを立ち上げる工数（設計・結合・テスト・出荷）そのものが、エージェント型コーディングによって圧縮されたからです。歴史的に、この初期工数の高さこそが「コア以外はほぼ全部レンタル（＝買う）」という判断を企業に強いてきました。その前提が崩れつつあります。
この変化は、OpenAI が公表した企業データからも裏づけられます。同社の「From assistance to execution」レポートによれば、2026年6月時点で、エンタープライズ顧客の Codex と ChatGPT を合わせた出力トークンの 64% を Codex（エージェント型の実行）が占めるまでになりました。さらに Codex の週次利用は2月以降、エンジニアリングの5倍に対し、法務で108倍・営業で41倍・採用で41倍・マーケティングで26倍と、非エンジニア部門にまで急速に広がっています。加えて、利用量上位10%の「フロンティア企業」は、1人あたり出力トークンで一般企業の 8.3倍（1月時点の2.6倍から拡大）を消費しています。
要するに、「作る」ための道具が、開発部門の外にまで行き渡り始めた——これが2026年の実像です。
「作る」は安くない——見送った購入費の裏で立ち上がる“運用の請求書”
ここで日本企業が冷静に見るべきなのは、「購入を見送った金額」＝「節約できた金額」ではないという点です。ソフトウェアのコストの大半は、作った“後”に発生します。AI が生成したコードであっても、所有者・テスト・セキュリティレビュー・依存関係や規制変更への追随が必要であることは変わりません（The Daily Brief による分析）。ソフトウェアのライフサイクル費用において、保守が占める割合が大きいことは、以前から広く知られてきた経験則です。
エージェント型コーディングは、この構図に新しい費用を上乗せします。動かし続けるためのトークン課金、生成コードの継続的な監査、そして「誰が・どのエージェントに・何をさせたか」を後から説明できる状態の維持です。作る初期費用が下がったぶん、判断の重心は“運用の総コスト（TCO）”へ移ったと捉えるのが正確です。
| 判断軸 | 「買う（SaaS）」の場合 | 「作る（内製＋エージェント）」の場合 |
|---|---|---|
| 初期コスト | ライセンス費（比較的読みやすい） | エージェント型コーディングで大幅圧縮 |
| 差別化 | 他社と同じ機能になりがち | 自社業務に密着させやすい |
| 保守の担い手 | ベンダーが負う | 自社が負う（テスト・更新・改修） |
| セキュリティ／統制 | ベンダーの認証・SLAに依存 | 自社で設計・証明する必要 |
| 継続コスト | 月額課金 | 運用・監査・トークン・改修の合算 |
「32%が購入を見送った」を「32%のコストが消えた」と読み替えてはいけません。作ったソフトとエージェントには、生きている限り保守・セキュリティ・統制の請求書が届き続けます。内製の意思決定は、初期費の比較ではなく、**3年スパンのTCOと“誰が保守を背負うか”**で下すべきです。
それでも内製が進む理由と、勝者の条件
コストが単純に下がらないなら、なぜ内製は進むのか。理由はコストではなく主導権にあります。自社の業務に密着した振る舞い、データの置き場所、更新の速度——これらを自分で握れることの価値が、ハイパフォーマーほど高く評価されています。実際、AI で明確なEBIT貢献を出せている企業ほど購入を見送る傾向が強い、という前掲の数字は、「作れること」自体が競争優位になりつつある兆候です。
ただし注意すべきは、AIから財務的インパクトを引き出せている企業は依然として限られるという事実です。同じ McKinsey 調査では、「何らかのEBIT影響がある」と答えた企業は 37% で、前年から横ばい。ハイパフォーマーの壁（EBITの5%以上）を越えたのは 6% にとどまります。道具が民主化しても、成果に結びつけられるかは別問題——ここに、内製の“勝者”と“作っただけ”の分かれ目があります。
勝者の条件を整理すると、次の3点に集約されます。
- 作る対象を選ぶ規律：差別化に効く領域だけを内製し、コモディティは買う。全部を作ろうとしない。
- 運用を前提にした設計：テスト・監査・改修の担い手を最初から決め、TCOで判断する。
- 統制を後付けにしない：自社で持つ以上、承認・権限・監査を初日から組み込む。
homula の観点——『作る』を速く、『動かす・統べる』を確かに
homula の立ち位置は、この潮流のちょうど中心にあります。私たちは、企業の内製化そのものを支援するAIエージェント・インテグレーターだからです。「作るか買うか」が「作る」に傾いた今こそ、支援の型が効きます。
- 作る対象を選び、速く立ち上げる：homula の AIエージェント・ブートキャンプは、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で完結させます。「どの業務を内製すれば差別化に効くか」を、感覚ではなく試算で選ぶための最初の一歩です。PoC は最短5日で回します。
- 配管は作り込まず、標準でつなぐ：統合プラットフォーム Agens は、MCP を活用して 200以上のツールと構築ゼロで接続します。内製の“下回り”を個別に作り込むほど保守費は膨らむため、接続は標準で持つのが堅い選択です。
- 運用と統制を初日から敷く：Agens Control は、実行前の承認フロー・DLP・RBAC・5年分の監査ログを提供します。自社で作ったエージェントほど「誰が・何を・なぜ実行したか」を後から証明できる状態が要ります。これは、後から膨らむ“運用の請求書”を読める形にする投資です（運用コストの統制という観点は別稿でも整理しました）。
homula は、こうした「作る前提」の設計で処理時間を93%削減した実績があります。派手な内製ブームの見た目ではなく、**“何を作り、どう動かし、どう統べるか”**という地味な設計にこそ、再現性のある成果の源泉があります。
まとめ
- McKinsey の2026年調査で、企業の 32% が「エージェント型コーディングで作れる」としてソフト購入を見送った。テクノロジー業界は41%、ハイパフォーマーは約半数に達する。
- 背景は、エージェント型コーディングがカスタムソフトの初期工数を圧縮したこと。OpenAI のデータでも、Codex が企業の出力トークンの64%を占め、非エンジニア部門にまで広がっている。
- ただし「作る」は安くない。**保守・セキュリティ・監査という“運用の請求書”**は、作った後に立ち上がる。判断は初期費ではなく 3年TCOと保守の担い手で。
- 勝者の条件は、作る対象を選ぶ規律・運用前提の設計・後付けにしない統制。道具が民主化しても、EBIT貢献を出せる企業は依然6%にとどまる。
「作るか買うか」が「作る」に動いた今、差がつくのは作る速さと、動かし続ける確かさです。homula は、内製すべき対象を選ぶところから、運用と統制の設計まで伴走します。