SaaSの請求書が、毎年少しずつ重くなっています。10本、20本と契約が増え、そのうちいくつかは機能の1割しか使っていない。そこへ、AIにアプリを作らせた話が社内外から入ってきます。社員がClaude CodeやCopilotで申請フォームを作ってしまった、Excelの集計がボタン1つになった。だったら、あのSaaSもやめて自作できるのではないか。そう考えるのは自然です。

SaaS 内製化で検索すると、「SaaSは終わる」と「自作は危ない」の両方の記事が出てきます。どちらも一部は本当で、一部は誤解です。この記事は、2026年10月30日時点で確認できる事実をもとに、SaaSを内製化するときに考えるべきことを8段の手順に並べます。読者は、30〜300人の会社で契約を決める経営者と、SaaSの管理を任されている情報システム担当者を想定しています。

結論を先に書きます。

  1. 「SaaSは死ぬ」の元になった発言は、各社が自作する話ではありません。 Microsoftの戦略の話で、同じ発言者が2026年10月には「記録の要となるシステムはむしろ重要」と書いています。一方で、作る道具と動かす場所が2026年にMicrosoft 365の中に用意され、値上げも続きました。内製の条件は確かに変わっています。
  2. 内製化には3つの形があり、まず試すのは「SaaSの周りを自作する」です。 SaaSを丸ごと置き換える、SaaSの周りの画面と手順を自作する、SaaSの設定と運用を自社で持つ。元データを持つSaaSは残し、その上の申請・集計・通知を作るのが、2026年の現実的な線です。
  3. 判断は資格・責任・頻度で分けます。 法令や制度の改正に合わせ続ける機能、事故のとき責任を外に置くべき機能はSaaSに残す。毎日使い、業務に合わせて頻繁に直したい機能は自作に向く。これが当社の整理です。
  4. 比べるのは作る費用ではなく、続ける費用です。 保守の時間に時間単価を掛けた額がSaaSの月額を超えるなら、利用料だけを見ればSaaSのほうが安い。kintoneを10人で使う会社なら、分かれ目は月3〜4時間です。

「SaaSは終わる」の話は、何が本当で何が誤解か

この話題の元をたどると、2024年12月12日に公開されたポッドキャストBG2でのSatya Nadella氏の発言に行き着きます。動画の文字起こしで確かめると、話しているのは「業務アプリはデータベースにビジネスロジックが載ったもので、そのロジックはAIの層に移る。AIの層にロジックが集まると、バックエンドを置き換え始める」というMicrosoftの製品戦略です。自社のDynamicsを例に、バックエンドでの勝率が高いから積極的にまとめていく、と続けています。各社が自分でSaaSを作る、という話ではありません。

同じ人物が2026年10月8日に出したエッセイ「The Infinite SaaS Factory」は、報道によれば、言葉で説明すればCopilot Codeが機能やモジュールを作れる、と書く一方で、エージェントが増えてもCRMやERPのような記録の要となるシステムの重要さは下がらず、むしろ上がる、とも書いています。原文は今回取得できていないので、この部分は報道で確認した内容です。

2026年2月の「SaaSpocalypse」も、中身は株価の話です。DeepLearning.AIのThe Batchによれば、Anthropicが1月30日に職種別のCowork用プラグインを公開した約4日後に、S&P Software & Services指数が4%下がり、1月12日から2月23日までで25%下落しました。記事自体が、Anthropicの発表が原因だと証明したわけではない、と書いています。その後、Gartnerは2026年10月21日に、世界のソフトウェア支出が2026年に前年比15.2%増になると予測しました。こちらはページ本文が取得できず、検索結果の要約で確認した数字です。

Klarnaの話も、2025年3月4日にCEO自身が訂正しています。TechCrunchによれば、本人はXで「SaaSをLLMで置き換えたのではない。CRMのデータをLLMに入れるには限界がある」と書き、実際にやったのは、使っていた多くのSaaSのデータをNeo4jなどで社内に集めて社内のAIに使わせることだった、と説明しました。ほかの会社が同じことをするかについても、疑わしい、と本人が言っています。2025年5月にカスタマーサポートで人を再び採用した件は、問い合わせ対応の自動化の見直しで、SaaSの置き換えとは別の話です。

つまり、よく引用される3つの材料は、内製化を勧める根拠にはなりません。それでも、この記事を書く理由があります。2026年に、内製の条件そのものが変わったからです。

2026年に変わった3つの条件

作る道具と動かす場所が、Microsoft 365の中に用意された

Microsoftは2026年9月25日に、新しいCopilot（Home・Code・Autopilot）を発表しました。公式ブログによれば、Copilot Codeは「アプリ、トラッカー、ダッシュボード、自動化、ワークフローを言葉で説明すると、Copilotが作り方を選んで作る」もので、Cowork・Code・Autopilotは従量課金で動きます。

作ったものを動かす場所がCopilot Managed Runtimeです。Microsoft Learn（2026年10月5日）によれば、Cowork、Copilot Studio、Copilot Code、SDKとCLIの4通りで作ったアプリが同じ場所で動き、Microsoft Entraの認証、テナントのポリシー（許可したコネクタ、共有のルール）が最初から適用され、Microsoft 365管理センターの一覧に出ます。利用者はmanagedapps.cloud.microsoftから開きます。現時点ではプレビューで、一般提供日は公開ロードマップにありません。

ここで費用の前提が1つ増えます。Learnの開発者向けページ（2026年9月29日）によれば、アプリを使う人はPower Apps PremiumかCopilot Creditsのどちらかが必要で、Creditsの場合はアプリの起動ごとと、API呼び出し1回あたり0.1クレジットが課金されます。1クレジットは0.01米ドルです。Creditsが足りない人は、20回の操作か5分の利用で止まります。作ったあとに「誰が動かす費用を払うか」が、SaaSの席料と同じ形で残るということです。

Microsoft 365を使っていない会社でも、作る道具の側は同じ方向に動いています。Anthropicは2026年4月9日にClaude CoworkとClaude Codeのデスクトップ版を全有料プランで一般提供し、GitHubは2026年10月28日にGitHub EnterpriseのライセンスにCopilotを含める形を発表しました。GitHubの変更履歴によれば、席ごとのクレジットはなく、企業全体のAI予算から最初の1回目から従量で引かれ、予算が尽きるとChat・コードレビュー・クラウドでの実行が止まります。コード補完は使えます。

値上げが続いた

2025年から2026年にかけて、主要なSaaSの値上げが続きました。確認できた一次資料だけ並べます。

製品 内容 適用日 出典
Microsoft 365 Business Basic 6→7ドル、Business Standard 12.50→14ドル、Microsoft 365 E3 36→39ドル、E5 57→60ドル。Business Premium 22ドルとCopilot単体は据え置き 2026年7月1日 Microsoft Licensing News（2026年2月16日）
Salesforce 新エディション Core 195ドル、Advanced 395ドル、Max 550ドル（ユーザー・月）。Agentforce、Slack、分析、Premier Success Planを同梱。従来のエディションの既存価格は据え置き 発表 2026年9月6日 Salesforce News
Atlassian Cloud Jira、Confluence、JSM、Guard、Bitbucket Premiumなどの定価を改定。日本円の為替レートも見直し。従量の部分（Rovoクレジット、Automation）は別 2026年10月13日 Atlassian FAQ
Microsoft 365 Copilot Business CSP経由で新規購入すると、従量課金がデフォルトで有効。上限の初期値は1人月4,000クレジット 2026年12月1日 Partner Center告知（日本での開始時期は要確認）

外資のSaaSは、ドルの定価と為替の両方で上がります。Atlassianのように為替レート自体を見直す例が出たので、円建ての請求額は定価の改定率より大きく動くことがあります。SaaSを続ける費用を見積もるときは、この値上げの見込みを足す必要があります。

作るのは速くなった。続けるのは速くなっていない

3つ目の条件は、前の2つと向きが逆です。作る速さは上がりましたが、続ける手間は変わっていません。

The Pragmatic Engineerの2026年1月29日の記事で、著者はCodexを使い、Webサイトに推薦コメントを表示する年120ドルのサービスを約20分で置き換えました。ただし本人が、最初の画面は間違っていた、レイアウトとフレームワークは自分で指示した、更新のたびにAIとコードを確かめられる人が要る、と書いています。継続して価値を出すもの（コンプライアンス、分析、通知）は置き換えにくい、というのも本人の結論です。

Hacker Newsでは2026年に同じ話が繰り返し出ています。4月27日のスレッドでは、月30〜50ドルの製品を売る開発者が、時給100ドルの人が数週間かけて自作すると言う、と嘆き、コメントでは、製品の手間の大半はその後の保守と改良で、ブラウザやOSやLLMが更新されると自作は動かなくなる、との指摘が集まりました。10月12日のスレッドでは、企業ではコードを書く部分は費用の10%以下で、要件を決める話し合いと5〜10年の保守のほうがずっと大きい、との意見が出ています。

日本語の事例も同じことを示しています。Qiitaに2026年10月28日に投稿された製造業の調達担当者の記事では、Claude Codeで部品の相見積もり表を約14分で作れた一方、AIが作った取得スクリプトは一度も実行されていない状態で、実行すると9件中8件が成功表示なのに1件は別商品の価格を拾っていました。修正の確認中にAIがその日のCSVを上書きして4行消した、との記録もあります。2026年4月1日の別の投稿は、ローコードやAIで作ったものを期限付きの道具と考え、作る時点で見直しの時期を決める、と提案しています。作った人の異動と退職、接続先の変更、全社公開のままの共有リンク、使われないまま費用を消費するフロー、が理由です。

当社が持ち込み記事で書いたAIエージェントを安全に動かすサンドボックスの選び方も、同じ前提に立っています。作る環境と動かす環境を分けないと、速さがそのまま事故の速さになります。

内製化には3つの形がある

SaaSの内製化と一言で言っても、やることは3つに分かれます。難しさと戻しやすさが違うので、最初に分けておきます。

SaaSの内製化の3つの形を3段の階段で示した図。下の段はSaaSの設定と運用を自社で持つ、中の段はSaaSの周りの申請・集計・通知を自作して元データはSaaSに残す、上の段は契約をやめてデータを自作のシステムに移す。上の段ほど戻すときの費用が大きい

  1. SaaSの設定と運用を自社で持つ。 ベンダーや代理店に頼んでいた設定変更、ユーザー管理、他システムとの連携設定を、自社の担当者ができるようにする。SaaSはそのまま使います。
  2. SaaSの周りを自作する。 元データはSaaSに残し、その上の申請画面、集計、通知、他のSaaSとのつなぎを自作する。Copilot Studio、Power Automate、Copilot Managed Runtime、Claude Codeで作る小さなアプリの大半はここに入ります。
  3. SaaSを置き換える。 契約をやめ、データを自作のシステムに移す。戻すときはデータの移し替えがもう一度要ります。

当社が勧める順番は1、2、3です。1は費用がほぼ要らず、2は失敗しても元データが無事なので戻せます。3だけが、戻るときに大きな費用が要ります。Klarnaが実際にやったのも、本人の説明を読む限り、2と、別のSaaSへの乗り換えでした。

判断の手順。8段を上から順に確かめる

ここからが本題です。対象のSaaSを1つ決めて、上から順に確かめます。途中で「残す」と決まったら、そこで止めて構いません。

1. 使っている機能は全体の何割か

Hacker Newsの10月12日のスレッドに、Salesforceの10%しか使っていないチームなら、その業務に合う簡単なCRMを年間ライセンス料の何分の一かで作れる、というコメントがあります。まず、そのSaaSで実際に使っている機能を書き出します。メニューを上から順に見て、過去3か月に開いたものだけに印を付ける作業で十分です。使っている機能が全体の1〜2割なら、2の「周りを自作する」か3の候補になります。8割使っているなら、作り直す量は小さくなりません。

2. そのSaaSは記録の要か、画面と手順の層か

顧客、会計、人事の元データを持っているSaaSは、記録の要です。Nadella氏も2026年10月のエッセイで、記録の要となるシステムは重要さが増す、と書いています。元データを持つSaaSは残し、その上の画面、集計、申請の流れを自作する。これが、2026年に現実的な線です。元データが社内のどこにも複製されていないSaaSを置き換える場合は、データの移し替えと検証の費用を最初に見積もります。

3. 資格・責任・頻度で分ける（当社の整理）

ここは当社の整理です。インハウス経営の線引きとして社内で使っている判定で、SaaSに当てはめると次のようになります。

  • 資格: 法令や制度の改正に合わせ続ける必要がある機能は、SaaSに残します。給与の料率、電子帳簿保存法、インボイス、電子署名がこれに当たります。改正のたびに自社で直し続けるのは、作る費用より大きい仕事です。
  • 責任: 事故のとき、責任を外に置くべき機能もSaaSに残します。決済、セキュリティ製品、認証です。自作して事故が起きたとき、説明する相手は顧客と取引先で、ベンダーに代わってもらえません。
  • 頻度: 毎日使い、業務に合わせて頻繁に直したい機能は、自作に向きます。年に数回しか触らない機能は、買うほうが安い。直す頻度が高いほど、自社で持つ利点が出ます。

当社では、自社でやる仕事の判定を「月に1回以上ある」「自社の情報が無いと決められない」「失敗してもやり直せる」の3つで行っています。SaaSの内製化も同じで、3つとも当てはまる機能から手を付けます。

4. データの保存先と、渡してよいデータ

自作のアプリはどこで動き、誰が見られるのか。Copilot Managed Runtimeなら、Microsoft Entraの認証とテナントのポリシーが最初から適用され、管理センターの一覧に出ます。一方、CoworkのAppスキルで作ったアプリの共有はリンク方式です。Learnによれば、共有できるのは組織内でMicrosoft 365 Copilotを使える人に限られますが、その中でリンクを持つ人はデータを含めてアプリを開けるので、見せてよい人にだけ共有する、と書かれています。自前のホスティングなら、認証、権限、ログを自分で作ることになります。

もう1つは、作る過程で何を渡すかです。AIのコーディングツールに顧客データを渡してよいか、社内の契約と個人情報保護法の整理が要ります。この点は後の節で触れます。

5. 費用を、続ける費用で比べる

次の節で表にします。

6. 作る場所を選ぶ

Microsoft 365が中心の会社なら、Copilot Managed RuntimeかPower Appsです。管理センターでの一覧とポリシーの自動適用が最初から付いてきます。その代わり、使う人にライセンスが要ります。Managed RuntimeならPower Apps PremiumかCopilot Credits、Power Appsのcode appsならPower Apps Premium、従量課金、App Passのいずれかです。自前のホスティングは自由度が高い代わりに、認証と権限とログを自分で用意します。どちらにしても、Microsoft Learnの記述どおり、Managed Runtimeのリポジトリの種類（Microsoftが管理するGitか、自社のGitHubか）は作成時に決めると変えられず、自社のGitHubを使うにはGitHub Enterprise Cloudの組織が必要です。後の節で書く「やめるとき」に直接関わるので、作る前に決めます。

7. 公開前の点検

AIが作ったアプリの点検は、人がやります。arXivの論文（2026年9月14日のv4）は、Claude CodeとLovableで作られたオープンソースのアプリ9,041件を集め、公開されて動いている200件を監査して、91.0%に少なくとも1つの脆弱性があった、と報告しています。見つかった1,186件のうち65.77%が致命的か高で、アクセス制御の不備、インジェクション、認証の不備に集中していました。公開前に最低限見る5つは、後の節に書きます。

8. 持ち主と期限を決める

誰が直すのか、2人目は誰か、いつ見直すのか。この3つが決まらないなら、作りません。Gartnerが2026年9月29日に出した予測では、ベンダーのFDEが作ったAIエージェントの利用を、2028年までに企業の7割がやめます。当社はFDEに頼んだエージェントの出口戦略で書いたとおり、原因は技術より、知識が社内に移らない、費用が続かない、やめ方が決まっていない、という構造だと見ています。社内で作ったものでも、作った人が1人なら同じことが起きます。

内製に向くSaaS、向かないSaaS

8段の手順を、SaaSの種類ごとに先に当てはめた表です。自社の契約一覧をこの表に並べると、候補が数本に絞れます。

SaaSを2軸で4つに分けた図。横軸は自社の手順そのものか、法令や責任や相手が関わるか。縦軸は毎日使い頻繁に直すか、年に数回しか触らないか。自社の手順で頻繁に直すものは申請・承認、受付フォーム、集計で、自作に向く。法令や責任が関わるが頻繁に直すものは会計やCRMの周りの画面だけを自作する。自社の手順で年に数回のものはプロジェクト管理や知識ベースで、買うか設定を自社で持つ。法令や責任が関わり年に数回のものは給与、決済、電子署名、セキュリティで、SaaSに残す

分類 例 判断 理由
社内の申請・承認 備品申請、権限申請、各種届 向く 毎日使う。自社の手順そのもの。やり直せる
入力フォーム・受付 問い合わせ受付、点検記録、日報 向く 画面と保存先が単純。Managed RuntimeやPower Appsの想定用途に入っている
集計・ダッシュボード 売上の週次表、在庫の一覧 向く 元データは別システムに残し、見せ方だけ作る
社内の知識・手順書 FAQ、マニュアル 条件付き 保存先はSharePointなどに残し、検索と回答の画面を作る
簡単なCRM 小さなチームの案件管理 条件付き 使っている機能が一部なら作れる。顧客の元データの持ち方と他システムとの連携が条件
プロジェクト管理 Jira、Floatの代わり 条件付き Hacker Newsの8月10日のスレッドには、社内で広まった自作に全社が移った例と、試して買ったツールに戻った例の両方がある
会計・請求書 仕訳、インボイス発行 向かない 電子帳簿保存法とインボイスに合わせ続ける。自作ならシステム概要の書類も要る
給与・勤怠・社会保険 給与計算、勤怠 向かない 料率や制度が毎年のように変わる。2026年4月の保険料からは子ども・子育て支援金（0.23%）が加わった
決済 カード決済、請求の回収 向かない 事故のとき責任を外に置くべき
セキュリティ製品・認証 EDR、ID管理、バックアップ 向かない 責任を外に置く。攻撃側もAIを使う
法的効力のある電子署名 電子契約 向かない 法的な効力と相手方の信頼が要る
社外とつながるもの Slack、Teamsの社外連絡、採用媒体 向かない 相手も同じサービスを使っていることに価値がある

向くと判断した分類でも、周りを自作するところから始めます。申請・承認なら、承認結果を今のSaaSに書き戻す形にすれば、元データの持ち主は変わりません。

費用は、作る費用ではなく続ける費用で比べる

SaaSを続ける場合と自作する場合を、同じ項目で並べます。

項目 SaaSを続ける 自作に置き換える
利用料 席数×月額×12。値上げの見込みを足す なし
作る費用 初期設定のみ 要件を決める時間＋作る時間＋点検の時間に、社内の時間単価を掛ける（または外注費）
AIの費用 SaaSに含まれることが多い コーディングツールの席料と従量分
動かす費用 なし Managed RuntimeならPower Apps PremiumかCredits。自前ならホスティング代
保守 ベンダー 月の保守時間×時間単価×12。法改正、接続先の変更、ブラウザやOSの更新、AIモデルの変更への対応
持ち主の交代への備え ベンダー 引き継ぎの文書、2人目の育成、コードの保存先
やめるとき データの書き出し、契約終了後の削除の確認 作り直しかSaaSへの戻り。データの移し替え

数字を入れてみます。以下は【試算】で、時間単価5,000円、1ドル150円、回数は当社が置いた仮定です。実際の請求額ではありません。

試算1。kintoneスタンダードを10人で使っている会社。 サイボウズの価格ページ（確認日2026年10月30日）では、スタンダードは1ユーザー月1,800円（税抜）で最低10ユーザーなので、年216,000円です。これを自作に置き換えるとします。要件決めと作成と点検に40時間かけると200,000円。Copilot Managed RuntimeでCredits払いにし、10人が1日50回の課金対象のAPI呼び出しをして月20日使うと、50×20×10×0.1＝1,000クレジットで月10ドル、年18,000円。アプリの起動ごとの課金は単価が公開されていないので含めていません。保守を月3時間とすると年180,000円。初年度は合計398,000円、2年目以降は198,000円です。

つまり、SaaSの月18,000円は、時間単価5,000円なら保守3.6時間分に相当します。保守が月3〜4時間を超えるなら、利用料だけを見ればSaaSのほうが安い。 逆に、席数が多い、使っている機能が一部、業務に合わせて頻繁に直したい、のどれかなら自作が有利になりやすい。この分かれ目を、自社の数字で出すのが5段目です。

試算2。承認ワークフローのSaaSを30人で使っている会社。 1人月500円の承認ワークフローSaaSを30人で使っていると仮定すると、年180,000円です。申請と承認の流れをManaged Runtimeで作り、24時間かけると120,000円。30人が1日20回の課金対象のAPI呼び出しをして月20日使うと、20×20×30×0.1＝1,200クレジットで月12ドル、年21,600円。起動ごとの課金は同じく含めていません。保守を月2時間とすると年120,000円。初年度は261,600円、2年目以降は141,600円です。この例では2年目から自作のほうが安くなりますが、差は年4万円弱です。承認の経路を頻繁に変える会社なら自作の利点が大きく、年に1回しか変えないならSaaSのままで十分、という読み方になります。

2つの試算の年額を比べた棒グラフ。試算1はkintoneスタンダード10人で、SaaSは年21万6千円、自作は初年度39万8千円、2年目以降19万8千円。試算2は1人月500円の承認ワークフローを30人で、SaaSは年18万円、自作は初年度26万1,600円、2年目以降14万1,600円。どちらも自作は初年度がSaaSより高く、2年目以降に保守の時間で逆転するかが決まる

Hacker Newsのコメントにあった、企業ではコードを書く費用はおそらく全体の1割以下、という意見と合う結果です。サブスクリプションは払い済みだからAIの作業はただに感じる、というのが落とし穴で、AIの費用を誰が見るかはAIのトークン費用を誰が見張るかで書いたとおり、最初に決めておきます。

Microsoftで作るなら、どこで動かすか

Microsoft 365の会社が自作を始めるときの入り口は、2026年10月30日時点で4つあります。どれも、できたアプリはCopilot Managed Runtimeで動きます。

作り方 向いている人 状況（2026年10月30日） 費用
Copilot CoworkのAppスキル 会話の中で説明して作りたい業務部門 Frontierプログラムの参加が前提。共有はリンク方式 Coworkの従量課金。Coworkのタスクの目安は1タスク100〜700超クレジットで、アプリ作成に同じ目安が当てはまるかは公式に明記がない
Copilot Studioの「Apps」 計画・下書き・公開の各段階を自分で確かめたい担当者 公開プレビュー（2026年9月に開始） 作成と実行は従量課金
Copilot Code AIのコーディングエージェントで作りたい業務部門と開発者 2026年9月末にFrontierへ。Microsoft 365 PremiumとPro向けのプレビューは「年内」 従量課金。Microsoft 365 Copilotライセンスと支出ポリシーが前提
Managed Runtime SDKとCLI コードで作りたい開発者 プレビュー 使う人にPower Apps PremiumかCredits（起動ごととAPI 1回0.1クレジット）

ここで注意が2つあります。1つは、Power Appsの「vibe」体験です。Learnの該当ページ（2026年10月13日更新）の冒頭に、アプリ作成はCopilot Coworkで使えるようになり、まもなくCopilot Studioにも展開するので今後はそちらを推奨する、という案内が付きました。この体験自体はUS、オーストラリア、アジア、インドのリージョンで英語のみ、デフォルトの環境では使えません。プレビューの道具に業務を載せると、道具ごと変わることがある、という実例です。

もう1つは、Copilot Managed Runtime CLIの公式GitHubの不具合報告です。2026年10月20日のIssueでは、組織全体でCLIを止める設定にしても、新しく作られた開発者環境に設定が数分遅れて反映されるため、その間に誰でもアプリを公開できてしまう、という報告があり、Microsoftの担当者が不具合と認めて10月27日に修正の展開を予告しています。プレビューの段階で業務に載せるなら、この種の穴があることを前提に、公開の承認を人の手順でも持っておきます。

Coworkそのものの費用と日本語の癖は、Copilot Coworkとは。任せられる仕事と費用、日本語の癖に分けて書きました。

安全性。91%と56%の読み方と、最低限の5つの点検

AIが作ったアプリの安全性について、2026年に出た数字を正確に読みます。

arXivの論文の91.0%は、公開されて動いているオープンソースのアプリ200件の数字です。社内だけで使うアプリの数字ではありませんが、脆弱性の種類（アクセス制御の不備、インジェクション、認証の不備）は社内アプリでもそのまま起きます。論文は、エージェントの使い方とプロンプトの工夫で発生は減るが、なくならない、と結論づけています。別に、セキュリティ監査会社Kingbirdが2026年1〜3月に監査した200件超のうち91.5%に、同社が定義する欠陥が少なくとも1つあった、という数字も出回っています。対象は公開前の点検や事故対応のために創業者から持ち込まれたアプリで、再現できる手順は公開されていません。2つの91%は別物です。

Veracodeが2026年7月28日に出した報告では、AIが書いたコードのセキュリティテストの合格率は平均56%で、前年からほぼ変わっていません。セキュリティの指示を与えない場合、約44%の課題で危ない脆弱性が入りました。最高はGPT-5.5の68%、言語別ではPython 63%、Java 30%です。ベンダーの自社テストという前提付きですが、モデルが賢くなってもコードの安全性は横ばい、という傾向はarXivの結果と合っています。

当社がAIで作ったアプリの91%に脆弱性。公開前の5つの点検で書いた点検を、SaaSの置き換えに合わせて並べ直すと次の5つです。

  1. 誰が何を見られるかを、画面ごとに人が確かめる。 他人の申請が見える、管理者だけの画面がURLを知っていれば開ける、が最も多い穴です。
  2. 入力をそのままSQLやコマンドに渡していないかを見る。 AIは動くコードを書きますが、入力の扱いは指示しないと甘くなります。
  3. 認証はMicrosoft Entraなど既存の仕組みに任せ、自作しない。 Managed Runtimeを使う利点はここにあります。
  4. AIが作ったスクリプトは、本番のデータで一度動かして数字を見比べる。 Qiitaの調達担当者の例のように、成功表示でも1件だけ違う値を拾うことがあります。
  5. 共有リンクの範囲を公開前に確かめる。 CoworkのAppは、組織内でMicrosoft 365 Copilotを使える人のうち、リンクを持つ人がデータごと開けます。

日本の法令で増える仕事

SaaSを自作に置き換えると、ベンダーが引き受けていた法令対応が自社に戻ってきます。中小企業で特に関係するものを4つ挙げます。

個人情報保護法の改正。 改正法は2026年7月10日に成立し、7月17日に公布されました。個人情報保護委員会の概要には、データ処理等の委託を受けた事業者について、委託された個人データ等の適正な取扱いに係る義務を見直す、という項目があります（第30条の3、第58条の2）。SaaS事業者が預けたデータを委託の範囲を超えて使っていないか、契約を見直すきっかけになる一方、自作に切り替えてAIのコーディングツールや外部の実行基盤にデータを渡すときも、同じ整理が要ります。施行は原則として公布から2年以内で政令が定める日ですが、罰則の改正などは公布から6か月を経過した日、つまり2027年1月17日からです。この日付は改正法の附則第1条から当社が計算したもので、政令や規則は準備中です。

電子帳簿保存法。 国税庁の一問一答【電子取引関係】問18によれば、電子取引データの保存には真実性と可視性の要件があり、自社開発のプログラムを使う場合に限って、電子計算機処理システムの概要を記載した書類の備付けが要ります。市販の会計ソフトなら要らない書類が、自作では増えるということです。基準期間の売上高が5,000万円以下で、税務調査のダウンロードの求めに応じられるなら検索機能の確保は不要ですが、この条件も自社で管理し続けることになります。

給与と社会保険。 こども家庭庁によれば、子ども・子育て支援金は被用者保険では令和8年4月の保険料から徴収が始まり、令和8年度の支援金率は一律0.23%で、半分を企業が負担します。こうした率や制度の変更は毎年のように来ます。給与計算を自作した会社は、その全部に自分で合わせ続けることになります。資格の項でSaaSに残すべき理由はここです。

取適法（旧下請法）。 社内ツールの開発を外部に頼む場合は、2026年1月1日に下請法から変わった中小受託取引適正化法の対象になりえます。手形払いの禁止、価格協議に応じない一方的な代金決定の禁止、従業員数による基準の追加が主な変更です。自作と言いながら実態は外注、という形にするなら、契約の側も2026年の法令で確かめます。

やめるとき、作った人がいなくなるときの備え

内製化の判断で最後まで残るのが、やめ方です。作るときに、次の4つを決めておきます。

  • コードとデータの保存先。 Managed Runtimeのリポジトリの種類は作成時に決めると変えられません。最初から自社のGitHubに置けば、コードは手元に残ります。Power Appsのcode appsは、Learnによれば、Power PlatformのGit連携にまだ対応していません。
  • SaaS側のデータの書き出しと削除。 置き換える前に、今のSaaSからデータを書き出す形式と、契約終了後にデータが消される確認の手順を取っておきます。2026年9月から10月に日本で公表されたサイバー事案を個人が集計した記事では、契約終了後もデータが消されていなかった事案が含まれていました。
  • 期限と見直しの時期。 作った時点で「この仕組みは2027年6月に見直す」と決め、管理の一覧に書いておきます。使われないフローが費用だけ消費する状態を防ぐためです。
  • 2人目。 作った人が異動や退職でいなくなったとき、直せる人がもう1人いるか。いないなら、作る前に育てるか、外に作らせた場合は知識を社内に移す期間を契約に入れます。

11月17日からのIgniteで見る点

Microsoft Igniteは2026年11月17日から20日に、サンフランシスコとオンラインで開かれます。公開されているセッション一覧には、Copilot Managed Runtimeでどこで作ったアプリでも動かす話（BRK378）、Copilot Codeで独自の仕組みを作る話（BRK203）、Copilot Studioの新機能（BRK267）、1つのプロンプトから業務アプリを作る短い講演（THR887）が入っています。発表の中身は予測しませんが、この記事に関係するのは、Managed Runtimeの一般提供日と費用、Copilot Codeの日本語と日本リージョンでの動作、Power Platformとの役割分担の3点です。公開ロードマップには、11月にWork IQのBusiness Appsでmodel-drivenアプリを使う項目（571888）、12月にPower Appsのgenerative pagesでコネクタとDataverseのカスタムAPIを使う項目（576283、576284）があります。

誤情報になりやすい点

よくある言い方 実際
Nadella氏がSaaSは死ぬと言った 2024年12月の発言は業務アプリのロジックがAIの層に移るというMicrosoftの戦略の話。2026年10月のエッセイでは記録の要となるシステムはむしろ重要、と書いている
KlarnaはSalesforceをAIで置き換えた CEO自身が2025年3月に「LLMで置き換えたのではない」と訂正。別のSaaSへの乗り換えと社内のデータ基盤づくり
SaaSpocalypseでSaaSの売上が落ちた 2026年2月に落ちたのは株価。Gartnerは2026年のソフトウェア支出を15%増と予測（本文は要確認）
AIで作ったアプリの91%に脆弱性 arXivの91.0%は公開中のオープンソースのアプリ200件の数字。別にKingbirdの91.5%（持ち込まれた200件超、同社の定義による欠陥）があり、混ざりやすい
OWASPによるとAIのコードの45%が危ない 44%はVeracode 2026の「指示なしで失敗する割合」。OWASPの数字ではない
Copilot Managed Runtimeは一般提供で追加費用なし プレビュー。使う人にPower Apps PremiumかCopilot Creditsが要る
Power Apps vibeで日本語のアプリを作れる US、オーストラリア、アジア、インドのリージョンで英語のみ。Microsoft自身がCoworkとCopilot Studioを推奨
改正個人情報保護法は2026年7月10日施行 7月10日は成立日。公布は7月17日。罰則などは2027年1月17日、本体は公布から2年以内
電子帳簿保存法の対応にはJIIMA認証が必須 必須ではない。自社開発ならシステム概要の書類の備付けが要る
Microsoft 365は全プラン値上げ Business PremiumとCopilot単体は据え置き

KOIYALの見解

当社は、SaaSの内製化を費用の判断ではなく、能力の判断だと考えています。自社の業務を言葉にできる。データの保存先が整っている。作ったものを直し続ける人がいる。この3つがそろった会社は、内製化で費用も下がります。そろっていない会社は、AIで作る速さが上がっても、続ける費用で負けます。費用は結果で、能力が原因です。

だから、最初に狙うのは、一番高いSaaSより、一番小さく一周できる仕事です。SaaSの周りを自作する仕事を1つ選び、作る、点検する、直す、を自社で一周する。一周できた会社は、2本目から判断が速くなります。一周できなかった会社は、置き換えに手を出さなくてよかった、と分かります。

当社の関わり方で言えば、どの業務から始めるかを一緒に決めるのがDesign for youです。一周目を一緒に作るのがDo with you、2周目から自社だけで続けられるようにするのがEnable youに当たります。内製化とは、資格・責任・頻度で外に残すものを決めたうえで、残りを自社で持てる状態を作ることです。

次の行動

  1. 契約一覧を、この記事の表に並べる。 SaaSを1行ずつ、向く・条件付き・向かないに分けます。向くと条件付きの中で、使っている機能が全体の2割以下のものに印を付けます。
  2. 印が付いたSaaSを1つ選び、8段の手順を上から埋める。 5段目の費用は、保守の時間を月の時間で書き、時間単価を掛けます。分かれ目の時間が出たら、それを経営者と共有します。
  3. 「周りを自作する」形で、1本目を作る。 元データは今のSaaSに残し、申請か集計か通知の1つだけを作ります。公開前に5つの点検を人が行い、持ち主と2人目と見直しの時期を一覧に書きます。

1本目の選び方から、作る場所と費用の見積もり、公開前の点検までを一緒に進めたい会社には、AI活用・内製化の支援で、8段の表を自社の契約と業務に合わせて埋めるところから始めます。契約一覧があれば、初回の打ち合わせで候補は数本に絞れるはずです。経営者が決める部分だけ先に整理したい場合は、AIコンサルティングでも同じ表を使えます。お問い合わせの本文に、SaaSの本数と、置き換えを考えている1本の名前を書いていただければ、初回の前に当社で表の叩き台を作ります。

参考