脱SaaSで「自社のAI OS」を持つという選択——データ主権時代に日本企業が今すべきこと

「SaaS is dead」の本当の意味——死ぬのはSaaSではなく「業務ロジックの外注」

まず結論から書きます。「SaaS is dead」という言葉が指しているのは、SaaSという製品カテゴリの終焉ではありません。業務のロジックを、SaaSベンダーの中に預けたままにする時代が終わる、という意味です。

三菱総研は2026年のコラムで「SaaS is dead、AIエージェント時代に企業が進むべき道」と題し、その本質を「業務ロジックをSaaSの外に移せるようになったこと」だと整理しています(三菱総研)。これまで、受発注の判断も、在庫の引当も、承認の順序も、SaaSが用意した画面と設定の範囲でしか動かせませんでした。ロジックはベンダーのものだったのです。

ところがAIエージェント(人間の代わりに判断・行動するAIプログラム)が実用段階に入り、その前提が崩れました。自社のデータと業務知識をAIに渡し、自社の判断基準でエージェントを動かせるなら、ロジックを社外に預ける理由が薄れます。ここで初めて「脱SaaS」が、感情論ではなく経営の選択肢になりました。

誤解のないように言えば、私たちは「SaaSはすべて悪だ」と言いたいわけではありません。会計や勤怠のように、業界の標準に合わせておけば十分な領域は、むしろSaaSに任せるほうが合理的です。問題は、自社の競争力そのものを、他社と同じ標準機能に押し込めてしまうことにあります。日経ビジネスも、大手を中心に内製化と「脱SaaS」が進む背景を挙げています。SaaSごとに業務プロセスとデータが分断され、管理負荷とコストが膨らむ。そして標準化によって、自社の強みが失われていく——という懸念です(日経ビジネス)。

私たちが商談で繰り返し聞くのも、まさにこの声です。ある大手化学メーカーの上級執行役員は、大手SaaSについて「イニシャルコストも維持コストも高い」と実感を口にしました。ある不動産仲介会社の代表は「Salesforceは結局採用をやめた」「別のツールも月6万9800円払っていて地味に高い」と、ツール乱立とコスト膨張を率直に話しています。SaaSが憎いのではありません。自社の業務が、借り物の器に収まりきらなくなってきた——それが現場の実感です。

データ主権とソブリンAIとは何か——2026年が分岐点になった理由

次に、脱SaaSの受け皿になる「ソブリンAI」と「データ主権」を整理します。

データ主権とは、自社のデータをどこに保存し、誰がアクセスでき、どの国の法律に従うかを、自社の統制下に置く考え方です。金融・医療・公共のように機微データを扱う領域では、データ主権を確保できる基盤が不可欠になります(カゴヤ)。ソブリンAIは、その考え方をAIの運用全体にまで広げたものです。モデルの選定・学習・推論から、エージェントの実行に至るまで、AI運用のライフサイクル全体を自社(あるいは自国)の管理下に保ちます。

なぜ2026年が分岐点なのか。理由は、日本で政策・インフラ・モデルが同時に動き出したからです。ソブリンAIの解説記事によれば、2026年はいくつもの動きが重なった節目の年です。高市政権のAI基本計画に、経産省の約1兆円規模の支援が重なる。Microsoftは4年で約100億ドル(約1.5兆円)の対日投資を表明し、デジタル庁は「源内」で7つの基盤モデルを選定しました(navi-dx)。国産の基盤モデルも、NTTのtsuzumi、富士通のTakane、NECのcotomi、ソフトバンクのSarashinaと出そろってきました。「日本でつくり、日本で守るAI」が、掛け声から実装のフェーズに入っています。

投資の規模も桁違いです。調査会社や半導体大手の見通しでは、主権を保ったAI基盤への投資はこの数年で数倍規模へ膨らむとされ、マッキンゼーは2030年のソブリンAI市場を5,000〜6,000億ドル規模と試算しています。いずれも業界の予測・試算であり、私たちが独立に検証した確定値ではありません。ここは事実と試算を分けて読む必要があります。ただ、方向として「主権を保ったAI基盤」に巨額の資本が向かっていること自体は、複数の動きが裏づけています。ソフトバンクはフランスのデータセンターに最大750億ユーロを投じると表明しました(TechCrunch)。

ここで、経営として押さえておくべき一点があります。ソブリンAIの解説記事も最後にこう締めています——これは情シス案件ではなく、経営アジェンダだ、と。私たちの現場感覚も、まったく同じです。データをどこに置き、誰に見せ、AIに何を任せるかは、コスト削減の話ではなく、会社の意思決定の主導権をどこに置くかという話だからです。

「脱SaaS＝全部作る」ではない——取り戻すのは"業務ロジックの主権"だけ

ここで一番よくある誤解をほどいておきます。脱SaaS、ソブリンAIと聞くと、「では、すべてを自前で作り、すべてのモデルを国産に置き換えるのか」と身構える方が多いのです。正直に言えば、それは現実的ではありませんし、必要でもありません。

私たちがおすすめするのは、もっと現実的なハイブリッドです。基盤になるクラウドやインフラは、実績のあるものを使い続けます。取り戻すのは、その上で動く業務ロジックとデータ、そしてAIエージェントの制御だけです。私たちはこれを、顧客のデータを「硬いデータ(基幹システムの正)」と「柔らかいデータ(AIが活用するデータ)」に分けて実装しています。基幹の横にデータ空間を設け、バッチでコピーする「仮想のブロックエリア」方式です。基幹はそのまま、AIが働く層だけを自社の統制下に置く。この設計なら、AIはインフラを選ばず、オンプレでもクラウドでも、閉域環境でも動きます。

現場のニーズも、実はこの形に寄っています。あるレガシー刷新の商談で、私たちはこう説明しました。「裏のデータベースはデータベースのまま使い、制御を細かく組みやすいモダンアプリ側で作り直したほうが、セキュリティレベルはむしろ上がります」と。実際、IDとパスワードだけの古い基幹に、社内VPNの総当たりで侵入できてしまった例を私たちは見ています。「VPNを切っているから安全」という前提に寄りかかりすぎるのは危うい。全部を捨てて作り直すのではなく、守るべき層を見極めて、そこだけ主権を取り戻す。これが脱SaaSの現実解です。

ある大手化学メーカーの生産DXグループリーダーは「繋げようとしても縦割りが強く、事業ごとに顧客も機能も全然違う。一つのシステムでは使いづらい」と話しました。全社を一枚岩のシステムに押し込むのではなく、事業ごと・会社ごとにデータと画面が分かれ、必要なところだけ繋ぐ——その方向のほうが、日本企業の実態に合っています。

データ主権は「保存場所」の話で終わらない——権限・監査・人間承認まで含めて初めて「守れる設計」

ここが、この記事で最もお伝えしたい論点です。データ主権を「国内のサーバーに置けば安心」という保存場所の話だと思っていると、肝心なところで足をすくわれます。

私たちの信条は「企業AIは、守れる設計でなければ業務に入れない」というものです。守れる設計とは、データの置き場所だけでなく、どの操作を許すか、いつ人間の承認を挟むか、何を外に出してよいかを、仕組みとして構成することを指します。この考え方は、学術の世界でも「Governance by Construction(構成による統制)」として整理され始めています。arXivに公開された論文は、こう論じます。企業のAIエージェントには「どの行動が許されるか、いつ人間の監督が必要か、どの情報を開示してよいか」をポリシーとしてコード化する層(policy-as-code)が要る、と(arXiv: Governance by Construction for Generalist Agents)。ドメインごとにエージェントを作り直すのではなく、統制の層を差し込んで、予測可能で監査可能な振る舞いを担保する。この発想は、私たちの実装思想とそのまま重なります。

私たちは、これを思想としてではなく実装として自社でやり切っています。具体的にはこうです。

• 機能レベルの権限分離(RBAC)。資料の閲覧制限だけでなく、機能単位でアクセス権を振り分け、取引先ごとに権限セットを細かく運用します。財務経理や人事系まで含めて分離します。
• 本番反映は二段階＋人間確認。先にステージングで直し、回帰テストが通ってから本番に出します。トレーニング環境は背景を黄色にして、ひと目で本番と区別できるようにしています。本番デプロイは指示があっても人間確認を挟みます。
• レッドチームアタック。顧客の自社環境へ移す前に攻撃テストを実施し、本番にはIP制限を入れます。
• AIに学ばせるのは"解き方"だけ。「他社に情報が漏れないか」という懸念には、こう答えています——情報はマスキングし、誰のものか分からない状態で学習させる。AIが学ぶのは「どういうトラブルにどの回答で解決したか」というアルゴリズムだけで、金額や固有名詞は学習対象から外す。最終判断はユーザーが行う、と。

なぜここまでやるのか。ある大手化学メーカーのDX推進担当は、AI導入の手軽さに対して「簡単すぎて逆に怖い」と漏らし、「工場のPCが破られると中に入られる。ヒューマンエラーのリスクは拭えないのでは」とも指摘しました。この不安は正しい。AIのミスがそのままセキュリティリスクになる時代だからこそ、私たちは自社のシステムで先に踏み抜いて塞いでいます。RAG(社内文書をAIに読ませて回答精度を上げる技術)のテナント間データ漏れを自社で検知して是正する。権限設定の穴を自動で見つけて封鎖する。機密情報の移行では、平文を展開せずメモリ内で処理する。こうした「AIが作った基盤の穴」を自社運用で先に潰し、その知見を顧客環境へ持っていきます。統制の詳しい考え方は、エージェント型AIの業務導入とガバナンスでも掘り下げています。

データ主権は、保存場所から始まって、権限・監査・人間承認まで含めて、ようやく「守れる設計」になります。ここを外すと、国内サーバーに置いた機密データを、統制のないAIがうっかり社外に開示する——そんな事故が起きます。

脱SaaS・内製化のリアル——メリットの裏にある「作れるだけ」の罠

脱SaaSと聞いて次に浮かぶのが「では内製化だ」という発想でしょう。ここも、光と影を正直に書きます。

内製化のメリットははっきりしています。SaaSごとの分断が解消され、変更や修正に即時対応でき、自社の業務に合わせて磨き込める。VibeCoding(自然言語でAIに指示して開発する手法)の登場で、そのコストは従来の10分の1程度まで下がりました。かつてのホストコンピューティング時代のように、「痒いところに手が届く」システムを、もう一度、しかも安く作れる時代が来ています。

一方で、影も濃い。内製化の最大の落とし穴は、「作れるだけ」の状態で止まることです。ITmediaは「SaaS is Deadでも採用激化」という記事で、これからは「作れるだけ」のエンジニアが淘汰されると論じています(ITmedia)。コードが書けることと、業務を理解して定着まで運べることは、まったく別の能力だからです。

現場の声が、これを裏づけます。ある大手化学メーカーの担当者は、社内開発の停滞をこう明かしました。「『内製できます』と謳いつつ実際は難しい」「設計側、つまりデータモデリングと裏の処理がなかなか進まない」。別の担当者は「今使えているのは自分のパソコンの中まで。なぜ他の人のところまで広げられないのかが分からない」と、素朴な壁を口にしました。ツールを配っただけでは、内製は広がらないのです。

だからこそ私たちは、非エンジニアが安全に開発を回すためのガードレールを、そのまま顧客の内製担当に渡します。「最初はデータベースをいじらないものに留める。DBをいじると後戻りできない。自分のブランチをどれだけ汚してもいいが、DBさえ直接触らなければ大丈夫」。「メインに直接マージせず、まずPRを上げる。PRを上げるとAIが中身を確認してレビューし、妥当性を判断してくれる」。この線引きがあるかないかで、内製化が資産になるか、負債になるかが分かれます。VibeCodingそのものについてはVibeCodingとは何かで詳しく解説しています。

私たちの現場経験では——自社のAI OSは「1日プロトタイプ」から始まる

ここまで読んで、「理屈は分かった。でも、うちのような会社に自社AI基盤なんて大がかりすぎる」と思った方がいるかもしれません。そこが、いちばんお伝えしたいところです。

自社のAI OSは、大型調達から始まりません。1日で動くプロトタイプから始まります。私たちは構想を議論する段階で、実際に動くものをその場で作り、それを叩き台にして業務改善を話し合います。図や仕様書ではなく、触れるものを見せる。この進め方に切り替えてから、商談の成約率は9割を超えました。動くものを見せているから、です。

なぜ動くものが効くのか。ある老舗化粧品メーカーの生産計画担当者は「完璧なものにしようとすればするほど無理が生じる」「臨機応変な修正がどうしても必要だ」と、計画システムに完璧を求めない現実を語ってくれました。網羅的なAs-Is/To-Be整理は、複雑すぎて使えないことが多い。動くものを基に「ここをこうしたい」と要望を重ねるほうが、「思っていたのと違う」を避けられます。

そして私たちは、この自社AI基盤——データ主権を保った企業のためのSovereign AI OS——を「Company OS」と呼んでいます。会社ごとのデータ・画面・権限・AIエージェントが、一つの業務空間で育つ仕組みです。構成は3つ。AIPLA(業務・ナレッジ・エージェントを束ねる実務レイヤー)、Sibyl(判断とナレッジを蓄積する会社のBrain)、AI Workspace(人とAIが同じ文脈で働く実行環境)です。重要なのは、これを私たち自身が毎日、実運用していることです。売っているのは、他社で試す実験ではありません。自社で回しているものを渡しています。

運用の形も実例があります。MVPは自社基盤で素早く立ち上げ、その後は顧客の自社環境・専用ドメインへ移行する。ある化粧品製造業では、生産計画・製造管理システムをこの形で全面移行しました(利用者19名)。「会社ごとに分かれ、移管できる基盤」というソブリンの主張を、運用レベルで体現しています。買い切りで自社に持ちたい会社にはOEMライセンスで、伴走しながら育てたい会社にはFDE(フォワードデプロイドエンジニア。顧客の現場に入って本番コードを書くエンジニア)の形で。入口は会社ごとに変えられます。FDEモデルの詳細はFDEとは何かを参照してください。

自社は脱SaaSすべきか——競争優位性 × ミッションクリティカル性で判断する

ここで、読者が自分で判断できる物差しを渡します。すべての業務を脱SaaSする必要はありません。判断の軸は2つ、競争優位性とミッションクリティカル性です(三菱総研の整理を、私たちの現場感で補いました)。

縦軸に「その業務が自社の競争力に直結するか」、横軸に「止まると事業が止まるほど重要か」を取ります。

• 競争優位性が高く、ミッションクリティカルな業務——ここは自社のAI基盤で持つべき領域です。製造業なら生産計画・需要予測・品質管理、専門サービスなら提案・見積もりのロジック。会社の「秘伝のタレ」が詰まった業務ほど、標準SaaSに預けると強みが消えます。
• 競争優位性は低いが、ミッションクリティカル——会計・勤怠など。ここは実績あるSaaSに任せ、無理に作らないほうが賢い。
• 競争優位性が高いが、クリティカルではない——新規事業やナレッジ活用など。小さく内製で試し、育てる領域です。
• どちらも低い——今は手をつけない。

ある大手自転車メーカーの担当者は「狙っているのは大きな改革ではなく、現場の小さな無理無駄をなくすこと」と明言しました。この見極めが、まさに右上(競争優位×クリティカル)から手をつける、という判断です。実際に「秘伝のタレ」と呼ばれる属人的な工賃表を抱えた合成樹脂メーカーでは、7割がブラックボックス化した原価表がExcelで配信され、部材を一つ変えるだけで全シートを手作業で直していました。ここは標準SaaSでは救えない。自社の業務そのものだからです。

自己診断の手順はシンプルです。まず自社のAI利用と業務を棚卸しして「利用マップ」を作る。次に、各業務を上の2軸でリスク分類する。そのうえで、右上の業務から順に、自社基盤で持つ設計を考える。この順番を飛ばして「とりあえず全社にAIを」と広げると、たいてい「自分のパソコンの中まで」で止まります。

失敗パターン——ソブリンAIを「国産LLMに乗り換えること」と誤解する

最後に、これから最も増えるであろう失敗を先回りしておきます。ソブリンAIを「海外モデルをやめて国産LLMに乗り換えること」だと理解してしまう誤解です。

モデルの国産化は、ソブリンAIの一要素ではあっても、本質ではありません。本質は、データの統制・業務への接続・現場への定着です。どのモデルを使うかより、そのモデルにどんなデータを、どんな権限で、どんな承認フローで渡すか。そこを設計しなければ、国産モデルに替えても「守れる設計」にはなりません。

モデルの扱いについては、私たちはむしろ複数を使い分けます。「Geminiが出した回答を、もう少し賢いClaudeで採点させる」——精度は一つのモデルに賭けるのではなく、多段で担保します。RAGも「蓄積したナレッジ(一次情報)でまず答え、必要ならウェブを後追いで加える」と、根拠の出所を混ぜません。ここはRAGとは何かで詳述しています。大事なのは、モデルという「部品」ではなく、統制という「設計」です。

現場も、機械的な置き換えの限界を見抜いています。あるプラスチック成形機メーカーのマネージャーは、AI回答100問の比較評価をこう振り返りました。「間違った回答もいくつかあった。畑違いな回答も一部あった。結局、取説を見に行っちゃうシーンが目に浮かんだ」。モデルを替えるだけでは、この不信は消えません。消すのは、自社データに根ざした統制と、人間が最終判断する設計です。私たちの基本スタンスは変わりません——AIは壁打ち相手であり、判断は人間がする。

よくある質問

Q. 中小企業も、ソブリンAIやデータ主権を意識する必要がありますか。 あります。むしろ、機密性の高いデータを扱う中小・中堅ほど効きます。大がかりな基盤を最初から作る必要はなく、右上の業務(競争力に直結し、止められない業務)を一つ、自社の統制下でAI化することから始められます。中小企業向けには、省力化補助金・AI活用補助金を使って初期負担を抑えつつ会社ごとにカスタマイズする入口も、提携パートナー(弁理士・中小企業診断士)と連携して用意しています。

Q. ソブリンAIと国産AIは同じ意味ですか。 違います。国産AIは「日本製のモデルやサービスを使うこと」、ソブリンAIは「データとAI運用の主権を自社(自国)の統制下に保つこと」です。国産モデルを使ってもデータ統制がなければソブリンとは言えませんし、海外モデルを閉域・マスキング・権限分離の下で使えばソブリンの要件を満たすこともあります。

Q. データをすべて国内サーバーに置けば、データ主権は守れますか。 保存場所は必要条件であって、十分条件ではありません。誰がアクセスできるか(権限)、何が起きたか追えるか(監査)、AIが何をどこまで実行してよいか(人間承認)——この3つが揃って初めて「守れる設計」になります。

Q. 既存のSaaSは全部やめるべきですか。 いいえ。会計・勤怠など標準化で十分な領域はSaaSのままで構いません。取り戻すべきは、自社の競争力に直結する業務ロジックとデータだけです。全部作り直すのではなく、守るべき層を見極めるところから始めてください。

まず試すなら

読み終えて、自社に引きつけて考えたい方へ。翌日から着手できる3つを挙げます。

1. AI利用マップを作る。今、社内のどこで、誰が、どんなAIを使い、どんなデータを渡しているかを一枚に書き出す。「自分のパソコンの中まで」で止まっている利用がどれだけあるかが見えます。
2. 業務を2軸でリスク分類する。競争優位性 × ミッションクリティカル性で、主要業務を4象限に置く。右上(競争力に直結し、止められない)が、自社基盤で持つべき最初の候補です。
3. 右上の業務を一つ、1日プロトタイプで触ってみる。完璧を目指さず、動くものを叩き台にして現場と議論する。ここから、自社のAI OSは育ち始めます。

AI-Pathでは、この棚卸しと見極めを一緒に行う**無償の業務プロセス診断(BPR)**を実施しています。ヒアリングから業務フロー・改善案・投資対効果のたたき台までを可視化し、「どの業務にAIが効くか」「どこを自社の統制下に置くべきか」を明らかにします。脱SaaSを掛け声で終わらせず、守れる設計の一歩目にしたい方は、まず無償のBPRからご相談ください。

---

参考リンク

• SaaS is dead、AIエージェント時代に企業が進むべき道（三菱総合研究所）
• 【2026年版】ソブリンAIとは？日本企業のデータ主権戦略5つの判断軸（navi-dx）
• Governance by Construction for Generalist Agents（arXiv）
• 大手を中心に進む内製化と「脱SaaS」（日経ビジネス）