「SaaSの死」ではなく、SaaSが“操作画面”から“統制基盤”に変わる

私は、生成AIやAIエージェントが既存SaaSを飲み込むという話を、単純な市場交代とは見ていません。現場で起きているのは、もっと生々しい変化です。

人間がSaaSの画面を開いて、検索し、選び、入力し、承認し、配信していた。それをAIエージェントが代わりにやるようになる。この時点で、SaaSの価値は「画面の使いやすさ」から、データ、権限、承認、ブランド、監査ログをどこまで握れているかに移ります。

だから私は、「SaaSの死」というより、SaaSの再定義だと見ています。

生き残るSaaSは、AIに操作されるだけの箱ではありません。AIエージェントが安全に業務を実行するための、データ統制、ブランド統制、権限統制、監査証跡の基盤になります。

確認日：2026年5月7日。以下では、企業名、媒体名、個人名、製品名は出さず、現場で実際に起きる論点として整理します。

1. 現場で最初に壊れるのは、ブランドガイドラインです

AIで広告やLP、メール、SNS投稿、営業資料を大量生成できるようになると、最初に現場は喜びます。

「1日で100本作れます」「ABテストのパターンを増やせます」「地域別、年齢別、顧客属性別に出し分けできます」「マーケターの作業時間を減らせます」

しかし、すぐに別の問題が出ます。

ブランドカラーが微妙に違う。禁止表現を使っている。薬機・景表法・金融説明上まずい言い回しが入る。過去に炎上したコピーに似ている。競合比較が強すぎる。画像の人物表現が社内基準に合わない。ロゴの余白ルールを守っていない。古いキャンペーン文言を再利用している。地域別表現で文化的にまずいものが混ざる。顧客属性に応じた出し分けが、差別的なターゲティングに見える。

これが現場です。

AIは「それっぽい」ものを大量に出します。でも、ブランドは「それっぽい」では駄目です。

ブランドは、色、余白、言葉、禁止表現、トーン、顧客への約束、法令上の制約、過去の事故、地域差、商標、権利処理の集合です。

私は、AIエージェントにブランド制作を任せるなら、まずブランドガイドラインをAIが読める形にする必要があると考えています。

PDFで置いてあるだけでは不十分です。SharePointに古い版と新しい版が混在している状態も危険です。代理店だけが最新版を持っている状態も危険です。

必要なのは、次です。

最新版のブランドガイドライン。禁止表現リスト。業種別の法務チェック項目。商標・ロゴ利用ルール。画像生成時の禁止要素。承認済み素材の台帳。過去にNGとなった表現の履歴。地域別・国別の表現差分。AIが参照してよいデータと、参照してはいけないデータの区分。

AIエージェントにブランドを守らせるなら、先にブランドデータを統治しなければなりません。

2. 「AIが作ったから速い」は、法務レビューを消さない

現場では、AIで制作スピードが上がると、法務・審査・承認のボトルネックが露出します。

AIが広告文を100本作る。マーケターはすぐ配信したい。営業はキャンペーンを走らせたい。法務は全部見られない。ブランド部門も全部見られない。結果として、承認前のものが配信される。

ここで事故が起きます。

AIエージェントが作ったものだから安全、ではありません。むしろ、人間が手で作ったときより量が増えるので、事故の母数が増えます。

私は、AI生成コンテンツでは、必ずリスク別に承認フローを分けます。

低リスクの社内向け下書き。既存素材の要約。過去承認済み表現の組み換え。外部公開広告。金融・医療・法律・採用・未成年向け表現。価格・割引・効果効能・比較広告。個人データを使ったパーソナライズ。

全部を同じ承認にすると現場が止まります。全部を自動承認にすると事故ります。

だから、AIエージェントにはリスク階層が必要です。

AIが作る。ルールで一次判定する。低リスクは自動承認または簡易承認。中リスクはブランド・法務確認。高リスクは人間承認必須。配信後もログで追えるようにする。

この設計がないAIマーケティングは、速いだけで危険です。

3. 顧客データをAIに渡した瞬間に、SaaSの価値は“データ統制”になる

AIエージェントで本当に成果を出そうとすると、顧客データを参照したくなります。

購買履歴。閲覧履歴。問い合わせ履歴。メール反応。広告接触履歴。店舗来訪履歴。会員属性。予算感。好み。家族構成。地域。過去のクレーム。解約兆候。

これを使えば、AIは強くなります。しかし、同時に危険になります。

現場ではこうなります。

マーケティング部門は「精度を上げたい」と言う。データ部門は「統合基盤にあります」と言う。法務は「利用目的と同意範囲を確認したい」と言う。情シスは「外部AIへ送るのか」と聞く。営業は「早く配信したい」と言う。委託先は「分析のためにデータをもらいたい」と言う。

ここで整理できない会社は、AIエージェントに顧客データを渡してはいけません。

私は、まずデータを分類します。

AIが読んでよいデータ。AIが要約だけしてよいデータ。AIが外部送信してはいけないデータ。個人を識別できるデータ。仮名化すれば使えるデータ。広告配信に使ってよいデータ。契約上、二次利用できないデータ。未成年・健康・金融・センシティブなデータ。削除請求が来た場合に消せるデータ。

これをやらずに「AIで顧客体験を最適化します」と言うのは危険です。

山崎行政書士事務所のクラウド法務としては、ここをデータフロー図、利用目的整理、委託先責任分界、AI利用台帳、本人向け説明文書に落とします。

4. AIエージェントにSaaSを操作させると、権限設計が一気に難しくなる

AIエージェントがSaaSを横断的に操作する時代になると、一番危ないのは権限です。

AIが広告を作る。AIが配信対象を選ぶ。AIがキャンペーンを作成する。AIがメールを送る。AIがSNS投稿を予約する。AIが顧客セグメントを更新する。AIがCRMにメモを書く。AIがWebページを公開する。AIが予算配分を変える。

これは、AIが業務を実行している状態です。ただのチャットではありません。

現場で一番危ない設計は、AIエージェントに人間の管理者権限を使わせることです。

「マーケティング責任者のアカウントで動かします」「APIキーは共通です」「とりあえず管理者権限を付けています」「PoCなのでログは後で考えます」「本番配信は人間が見るはずです」

これが事故の入口です。

私は、AIエージェントには専用IDを持たせるべきだと考えています。

どのSaaSに接続できるか。どのデータを読めるか。どのデータを書けるか。どの操作は下書きまでか。どの操作は人間承認が必要か。どの操作は完全禁止か。どのログを残すか。誰が停止できるか。トークンやAPIキーはどこで管理するか。

AIエージェントは新人ではありません。APIを持った自動実行主体です。

だから、人間より厳しく管理するべきです。

5. モデル連携プロトコルは便利だが、コネクタ地獄を生む

AIエージェントが複数SaaSや複数AIモデルと連携する仕組みは、現場では確実に広がります。

チャットAIからデザインSaaSを呼ぶ。デザインSaaSから画像生成モデルを選ぶ。マーケティングSaaSからCRMを読む。CRMから配信SaaSへ渡す。配信結果を分析SaaSへ戻す。その結果をAIが次の施策に反映する。

便利です。

しかし、ここでコネクタ地獄が起きます。

誰がどのコネクタを許可したのか分からない。どのAIがどのSaaSを呼べるのか分からない。APIスコープが広すぎる。読み取りだけのつもりが書き込み権限もある。テスト用コネクタが本番データを読んでいる。委託先が作った連携が残っている。退職者が作った連携が生きている。トークンの失効管理がない。連携先AIが入力データを学習に使う可能性がある。監査ログがSaaSごとに分断されている。

これが現場です。

私は、AI連携では必ずコネクタ台帳を作ります。

連携元。連携先。利用目的。認証方式。APIスコープ。読み取り権限。書き込み権限。実行可能操作。利用データ。個人情報の有無。秘密情報の有無。委託先関与。ログ保存場所。管理責任者。停止手順。

AIエージェント連携は、つながった瞬間が完成ではありません。つながりを棚卸しできることが完成です。

6. ブランド保護AIの本質は、生成AIではなく“承認済み素材の統制”です

ブランドを守るAIを作るなら、モデルの性能よりも、素材管理が重要です。

承認済みロゴ。承認済み写真。使用期限付き素材。契約上、特定地域でしか使えない素材。タレント契約。モデルリリース。利用許諾済みBGM。過去キャンペーンの素材。使用禁止になった旧ロゴ。撤回済みコピー。権利処理が未確認の画像。

これらが整理されていないと、AIは間違った素材を使います。

現場ではこうなります。

AIが見栄えのよい広告を作る。古いロゴを使っている。期限切れのタレント画像を使っている。地域限定素材を全国配信している。著作権処理が不明な画像を混ぜる。競合他社に似た構図を作る。過去にNGとなったコピーを再利用する。

これはAIの問題ではなく、素材台帳の問題です。

私は、生成AIをブランド制作に使うなら、先に承認済み素材ライブラリを整えます。

AIは、自由に何でも作ってよいのではありません。承認済み素材、承認済み文言、承認済みトーン、禁止事項の中で動かすべきです。

7. AIエージェントの費用は、モデル料金より運用コストが重い

AIエージェント導入で、現場が見落とすのがコストです。

モデル利用料。API呼び出し料。画像生成料。ログ保存料。データ統合基盤。DWH・CDP連携。権限管理。DLP。監査ログ。プロンプト管理。評価環境。人間レビュー。法務審査。ブランド審査。SOC監視。委託先管理。教育。障害対応。

表面上は「AIで効率化」ですが、裏では運用基盤にかなり費用がかかります。

現場では、PoCは安く見えます。本番化した瞬間に高くなります。

小さなチームで試す。数百件のコンテンツを作る。成果が出る。全社展開する。データ統合が必要になる。権限設計が必要になる。監査ログが必要になる。法務レビューが必要になる。結果として、PoCの10倍以上の運用コストになる。

だから私は、導入前に必ず「AIエージェント原価」を見ます。

1件の広告生成にいくらかかるか。1キャンペーン運用にいくらかかるか。人間レビューを含めた単価はいくらか。再生成率は何％か。NG率は何％か。誤配信時の損失はいくらか。監査ログ保存費用はいくらか。モデル切替時の再評価費用はいくらか。

AIのコストは、トークン単価だけではありません。

8. SaaSが生き残る条件は、AIが使う“信頼できる業務データ”を持つことです

私は、SaaSが死ぬとは思っていません。ただし、SaaSの役割は変わります。

人間が画面を操作するSaaSから、AIが参照・実行する業務基盤になります。

そのとき、価値があるのは次です。

正規化された顧客データ。権限管理。承認フロー。監査ログ。ブランド管理。ワークフロー。配信チャネル連携。データ品質。履歴管理。コンプライアンス機能。ロールバック。API制御。AIエージェントの実行制御。

単なるUIはAIに置き換えられます。しかし、統制されたデータ基盤は残ります。

むしろ、AIが業務を横断するほど、統制基盤としてのSaaSは重要になります。

9. 私が現場で必ず作るもの

山崎行政書士事務所のクラウド法務として、この領域では次の成果物を作るべきだと考えています。

AIエージェント台帳

どのAIエージェントが、どのSaaSに、どの権限で、何を実行できるかを整理します。

コネクタ台帳

AI、SaaS、CRM、広告配信、画像生成、DWH、ストレージ、チャット、メールの連携を一覧化します。

ブランドガイドライン機械可読化メモ

AIが参照できるブランドルール、禁止表現、承認済み素材、旧素材、地域差分を整理します。

AI生成コンテンツ承認フロー

低リスク・中リスク・高リスクで、人間レビューの要否を分けます。

顧客データ利用範囲表

AIが読める顧客データ、読めない顧客データ、匿名化が必要なデータ、外部送信禁止データを整理します。

AIログ設計書

プロンプト、出力、参照データ、実行操作、承認者、配信履歴、モデル名をどこまで残すか決めます。

委託先・SaaS契約チェックリスト

学習利用、再委託、国外移転、ログ、削除、監査、事故報告、モデル変更通知、API連携範囲を確認します。

取締役会向けAIエージェント統制レポート

導入効果、事故リスク、未承認連携、顧客データ利用、ブランド逸脱、例外承認、運用コストを報告します。

10. Azureで実装するなら、私はここを見る

Azureを使う企業なら、私は次を見ます。

Entra ID。条件付きアクセス。PIM。AIエージェント用ID。アプリ登録。サービスプリンシパル。Managed ID。Key Vault。API Management。Private Endpoint。Purview。DLP。Defender。Sentinel。Log Analytics。Storage。AI利用ログ。SaaS連携ログ。GitHub / DevOps の変更履歴。Power Platform やLogic Appsの連携。外部委託先のアクセス権。

AIエージェントをAzureで安全に動かすには、モデル以前にIDと権限を固めます。APIキーを平文で持たせる設計は論外です。共用アカウントで動かす設計も危険です。人間の管理者権限をAIに流用する設計も駄目です。

AIには専用ID。最小権限。Key Vaultで秘密情報管理。PIMで特権操作を制限。Sentinelで実行ログ監視。Purviewでデータ分類。DLPで外部送信抑止。API Managementで呼び出し制御。例外操作は承認制。

これが最低ラインです。

11. 現場で一番危険な事故パターン

私が一番怖いのは、次のような流れです。

マーケティング部門がAIエージェントを導入する。顧客データ、ブランドガイドライン、広告配信SaaSを接続する。PoCでは人間が見ていた。本番では自動化が進む。AIがセグメントを作る。AIが広告文を作る。AIが配信設定をする。AIが一部顧客に不適切な表現を送る。その根拠になったデータが、利用目的外だった。広告表現もブランド基準から外れていた。誰が承認したか分からない。どのモデルが生成したか分からない。プロンプトログも残っていない。委託先が設定したコネクタの権限が広すぎた。経営層は「AIがやった」と言う。顧客は「会社がやった」と見る。

これが一番危険です。

AIがやった、は説明になりません。企業が使ったAIです。説明するのは企業です。

12. 山崎行政書士事務所としての見解

私は、この領域を単なるAI導入支援とは見ません。

これは、クラウド法務のど真ん中です。

ブランド。顧客データ。広告表現。個人情報。委託先。SaaS契約。AI連携。API権限。ログ。監査。事故対応。取締役会報告。

全部が絡みます。

山崎行政書士事務所としては、技術と法務を分けずに見ます。

AIエージェントが何をできるかを技術的に見る。その操作が契約・規程・個人情報・ブランドルールに合うかを見る。ログで説明できるかを見る。委託先の責任を文書化する。監査資料に落とす。経営層が判断できる形にする。

行政書士としては、契約、規程、責任分界表、事実証明資料、監査説明資料、利用規約、社内運用文書の作成支援が中心です。個別紛争、損害賠償請求、交渉代理、訴訟対応は弁護士等との連携領域です。

13. 最終評価

私は、「SaaSの死」という表現には違和感があります。死ぬのは、単なる画面操作だけを提供していたSaaSです。

生き残るのは、AIエージェントが安全に業務を実行するための統制基盤です。

つまり、これからのSaaSに必要なのは、次です。

AIが参照できる正しいデータ。ブランドを守るルール。顧客データの利用制御。API権限管理。承認フロー。監査ログ。連携コネクタ管理。人間レビュー。事故時の説明資料。コスト管理。取締役会報告。

山崎行政書士事務所のクラウド法務として、私はこのテーマを次の一文で整理します。

AIエージェント時代のSaaSは、画面ではなく統制基盤になる。ブランド、顧客データ、権限、ログ、承認、委託契約を説明できるSaaSだけが残る。

AIが速く作る時代だからこそ、企業は遅くても確認すべきところを決めなければなりません。どのデータを使ったのか。誰が承認したのか。どのブランドルールに従ったのか。どの顧客へ配信したのか。どのAIが実行したのか。どのログで説明できるのか。

ここまで答えられる企業だけが、AIエージェントを業務の武器にできます。答えられない企業は、AIで速く事故を起こします。