断言する。To-Beを描き直せないEAは、2027年末までに存在意義を問われる。AIエージェントの進化は、2020年代初頭に描いたTo-Beをすでに陳腐化させた。

社内でライセンスの予算を通すたびに、決まってこう言われる。「高いね、こんなにかかってたんだ」。多くの現場で繰り返されている話だ。使ってはいるが高いシステム、使われていないが契約が続くSaaS。複数の調査で、企業のSaaSライセンスの相当割合が実際には活用されていないという傾向が一致して確認されており、SaaSコストの肥大化は多くのIT部門が直面している構造的な課題だ。AIエージェントがSaaSの業務領域を侵食し始めている今、SaaSを使い続けることの費用対効果を、今すぐ問い直すべき時代になった。

少し前、CIOにこう言われた。「今のTo-Beは古い。AIで何をしたいのか、IT部門としての意思がない」。悔しいというより、確かにその通りだと腑に落ちた。コスト管理を進めていたつもりだったが、AIエージェントという時代に即したTo-Beを描けていなかった。最初の一手として、自社のSaaSポートフォリオを「AIで代替できるか」という軸で棚卸しすることから始めた。それをどう数字に落とし、どう承認を取っていくか――この記事はその途中経過でもある。

なお、この記事は主にSaaS統一がある程度進んだ大手企業のEA担当者・IT部門マネージャーに向けて書いている。ただしSaaS移行がまだ途中の企業にとっても「まずSaaS統一を完成させることがAIエージェント活用の前提だ」という意味で、無関係な話ではない。

目次
  1. 「脱SaaS」とは何か――AIエージェント時代のIT戦略の転換点
  2. SaaS統一はゴールではなく通過点だ――2020年代のTo-Beを再定義する
  3. 脱SaaSの対象と対象外――EAが引くべき境界線
  4. 脱SaaS設計論：EAが実践する3ステップのサイクル
  5. SAP ECC 6.0移行期限がTo-Be再設計の最大のトリガーだ
  6. EAの役割はAI時代の経営戦略をIT戦略に翻訳することだ
  7. 参考文献

「脱SaaS」とは何か――AIエージェント時代のIT戦略の転換点

まず定義を示しておく。この記事で言う「脱SaaS」とは、SaaSを全廃することではない。プラットフォーム性も内部統制の担保もない「便利ツール系SaaS」をAIエージェントやスクラッチ開発に置き換え、SaaSポートフォリオを戦略的に絞り込むことだ。

なぜ今なのか。AIエージェントが、SaaSが担っていた業務領域を侵食し始めているからだ。社内申請フローや稟議の集約・整理、レポーティングの生成、データの集約と判断――これらはすでに一部のAIエージェントが担い始めており、Gartnerが2030年までに35%のポイント製品が代替されると予測する背景には、AIエージェントの精度向上への確信がある。プラットフォーム型は対象外だが、それでも企業が抱える「便利ツール系SaaS」の相当割合が10年以内に代替される計算になる。

たとえばCFOの仕事を考えてみてほしい。複数のデータを統合して経営層に報告する、財務シナリオを比較して判断材料を提示する、数字の根拠を説明する――こういった財務分析・経営報告の業務は、すでに一部のAIエージェントが担い始めている。ただしこれは財務分析の話であり、承認フローや監査証跡の記録はAIに任せられる段階にない――その点はSAPが残る理由と同じだ。

ではCFOは不要になるのか。ならない。「AIは責任を取れない」からだ。AIが間違えても刑務所には入れられない。だから最終的な意思決定と責任を負う人間は残る。ただしその役割は「自分で分析して説明する人」から「AIの出力を検証して最終承認する責任者」に変わっていく。これはCFOに限らず、財務系の判断業務において人が分析・説明を担ってきたすべての領域に当てはまる話だ。

CFOの役割変化は、EAが設計すべきTo-Beの変化を象徴している。AIが分析・説明を担い、人間が検証・承認を担う――この役割分担をTo-Beの設計に落とし込むことが、次の設計の起点だ。「誰が何を判断し、どこにAIを挟むか」を設計できていないなら、まだ半分だ。あなたの現場でも、「AIでよくないか」という声は出始めていないだろうか。

SaaS統一はゴールではなく通過点だ――2020年代のTo-Beを再定義する

EA（エンタープライズアーキテクチャ）の仕事はTo-Beを描くことだ。あるべき姿を設計し、そこに向けて組織とシステムを動かしていく。

2020年代に入って多くの大手企業が描いたTo-Beは、こうだった。「バラバラに積み上がった個別システムをやめ、グローバル標準のSaaSに統一する。業務もSaaSに合わせてシンプル化する」。フィット・トゥ・スタンダードの考え方を軸に、SaaS移行を推進する。これが当時の主軸だった。

ただし正直に言う。SaaSを入れれば業務標準化が進むわけではない。SaaSに合わせて業務を変える覚悟がなければ、ITの負債が1つ増えるだけだ。標準化できた企業だけが、次のステップに進める。

そして今、この認識の転換が必要だ。SaaS統一の目的は「SaaSで使い続けること」ではなく「業務を標準化してAIエージェント活用の土台を作ること」だ。SaaS統一はゴールではなく通過点であり、その先にAIエージェントを前提としたITガバナンス設計がある。

AIエージェントを前提としたアーキテクチャへの転換には、業務が標準化されていることが前提条件だ。標準化されていない業務にAIを乗せても、AIは何を処理すべきかを判断できない。SaaS統一によって業務が整理されてはじめて、AIエージェントが自律的に動ける環境が整う。だからSaaS統一は通過点として必ず経由しなければならない。この転換を自分の中で完了させることが、新しいTo-Beを描く起点になる。

脱SaaSの対象と対象外――EAが引くべき境界線

To-Beを描き直す前に、「何が脱SaaSの対象になるか」を整理しておく。ここを曖昧にしたまま進むと、SaaSポートフォリオの最適化が迷走する。

MicrosoftはIDとアクセス権の基盤を握っており、AIを乗せるプラットフォームとして進化している。標準OSがWindowsである限り動かない。SAPはお金周りの内部統制と監査証跡を担っており、承認フローの記録はシステムとして担保されなければならない領域だ。この2つは脱SaaSの対象外だ。

一方、SalesforceやServiceNowは自社での使われ方で判断する。「IT管理の効率化ツール」として使っているに過ぎないなら、AIスクラッチ開発の代替候補になる。SaaSのブランドではなく、自社の利用実態で線を引くことが重要だ。

なお「AIが判断した結果を承認記録として残す」という構造を実装したシステムはすでに存在するが、内部統制・SOX対応の文脈で監査法人が認めるかどうかはまだ議論中だ。経済産業省が2024年12月に改訂した「システム管理基準追補版」では、AIエージェントのような非決定論的システムが自律的に承認・仕訳を実行した際の監査証跡管理が最大の論点として浮上している。EAはITアーキテクチャ全体を設計する立場として、設計プロセスの早い段階で監査法人との対話を組み込むことが後工程の手戻りを防ぐ。CFOや法務部門とも連携しながら、EAが先手を打つことが重要だ。

詳細な個別SaaSの判断軸についてはAIに代替されるSaaSとされないSaaSで整理している。本記事では設計のステップに集中する。

脱SaaS設計論：EAが実践する3ステップのサイクル

では、AIエージェント時代のTo-Beはどう設計するか。

ステップ1・標準化：SaaSで業務プロセスをシンプル化する

SaaSのベストプラクティスに業務を合わせる意思決定が必要だ。カスタマイズを最小化し、標準機能の範囲で業務プロセスを再設計する。「この業務はSaaSの標準フローに合わせられるか」を1プロセスずつ検証し、合わせられない業務については「本当に必要か」を問い直す。失敗しやすいのは「現場の要望をすべて受け入れてカスタマイズを重ねる」パターンだ。ここで妥協すると次のステップに進めなくなる。

ステップ2・特定：AIエージェントで代替できる業務領域を見極める

判断軸は「その業務は監査証跡が必要か」「プラットフォームとして他の仕組みを支えているか」の2点だ。どちらもNOなら代替検討の対象になる。ただしAI活用による業務自動化の判断は技術的な可否だけでは決まらない。組織の合意形成・法的要件の確認・リスク評価のプロセスを並行して進めることが必要だ。よくある抵抗パターンは「前例がない」「責任の所在が不明確」の2つで、この2つへの回答を事前に用意しておくことが現場を動かす鍵になる。

ステップ3・開発：社内標準アプリをスクラッチで内製化する

AI代替できない領域に絞って開発する。「かつての失敗を繰り返すのでは」という反論は必ず出る。しかし業務プロセスが標準化された後のスクラッチ開発は、過去の個別要件積み上げとは根本的に違う。開発前に「このアプリが担う業務範囲」と「担わない業務範囲」を明文化し、追加要件の受け入れ基準を事前に設計することが肥大化を防ぐ。失敗しやすいのは「開発が始まってから要件が膨らむ」パターンだ。スコープの境界線をEAが守り続けることが、このステップの核心だ。

特に注目すべきは、To-Beアーキテクチャの設計思想が「人間が操作するUI」から「AIエージェントが効率的にデータを収集・処理できるAPIやMCPエンドポイント」の整備へとシフトしていることだ。TOGAFの最新動向でも、To-Beアーキテクチャの設計フォーカスがこの方向にシフトすることが議論されており[6]、スクラッチ開発の設計において人間向けの画面だけでなくAIエージェントとの接続インターフェースを初期設計に組み込むことが、次のサイクルへの橋渡しになる。

なお、AIエージェントの調達・選定においてはベンダーロックインのリスクも考慮が必要だ。ITリーダーの67%が特定AIベンダーへの高依存を回避しようとしている一方、45%がすでに「現行ベンダーのロックインにより柔軟な採用が制限されている」と感じているという調査がある。EAとしてポータビリティの確保をシステム設計に織り込むことは、開発段階における重要な論点だ。

フィンテック企業のKlarnaは、SalesforceやWorkdayといったエンタープライズSaaSを単純に置き換えるのではなく、グラフデータベースと内製AIエージェントを組み合わせた「インテリジェント・オーケストレーションレイヤー」を自社開発した[5]。コアな人事マスターは特定機能に特化した軽量なSaaSに移行し、その上位にAI層を重ねることで巨額ライセンスをバイパスする新しいアーキテクチャモデルを実現している。私の読み方ではこれは「EAが設計の起点に立ち、スコープを明確に引いたからこそ成立した」事例だ。AIを乗せる前に業務を整理し、開発範囲を絞り込む――この順序がなければKlarnaの成功はなかった。

このサイクルを回す過程で、どの業務をAIに渡し、どこに人間の判断を残すかが段階的に明確になっていく。一度のサイクルで完成するものではなく、繰り返すことでIT予算の削減と社内IT部門のDX推進が進んでいく。

3ステップを読んで「うちには関係ない」と思ったEA担当者がいるなら、それこそが一番危ない。SaaS統一が終わっていないから、SAP移行がまだだから――そういう理由でTo-Beの再設計を後回しにしている間に、経営層の目線はすでにAIエージェント前提の世界に移っている。

SAP ECC 6.0移行期限がTo-Be再設計の最大のトリガーだ

「いつTo-Beを描き直すべきか」という問いに対して、私は明確な答えを持っている。

SAP ECC 6.0はEHP0〜5の標準サポートがすでに2025年12月31日に終了しており、EHP6〜8も2027年12月31日に終了する。延長サポート（ESS）は既存のEnterprise Support契約を前提に、2028年から2030年まで提供されるが、追加プレミアム手数料が毎年上乗せされ、機能は完全に凍結される[7]。機能が凍結されるということは、AIとの統合拡張が一切できなくなることを意味する。EAの視点からは、この時点でTo-Beを描き直す機会を失うと考えるべきだ。

このタイミングを逃してはならない理由が2つある。第一に、基幹システムの移行判断はITアーキテクチャ全体に波及する。S/4HANA移行の議論の場にAIエージェントを前提としたTo-Beを同時に持ち込まなければ、基幹システムだけが新しくなって周辺は旧来のままという中途半端な状態になる。Gartnerの調査では2024年末時点でSAP ECC顧客の約85%が移行未完了であり[8]、多くの企業がまさにこの判断を迫られている。

第二に、移行後に「やはりAIを前提に設計し直したい」となっても、すでに多大なコストと時間をかけた後では動きにくい。今描き直すのと、移行後に描き直すのでは、難易度が根本的に違う。

これは主に大手企業の話だ。SAPを基幹システムとして使い、グローバル展開を持ち、IT投資の規模が一定以上ある企業のEA担当者・IT部門マネージャーは、このタイミングを逃さないでほしい。

EAの役割はAI時代の経営戦略をIT戦略に翻訳することだ

このTo-Beの再設計に対して、現場からは必ず抵抗が出る。「せっかく新しいSaaSを入れたのに、またやり直すのか」という声だ。これはトップダウンで動かすしかない。

経営層に意思があるなら、EAはその経営戦略をIT戦略に翻訳して現場に落とし込む。逆に経営層にその意思がまだないなら、EAが最初にやるべきことは「その意思を引き出すこと」だ。数字で示す、事例で語る、リスクを可視化する――経営層を動かすこともEAの仕事だ。受け身でいるEAに、To-Beは描けない。

私自身も今、その途中にいる。To-Beを描き直したEAだけが、AIエージェント時代の設計者として経営層から必要とされる。今すぐできるネクストアクションは2つだ。自社のSaaSポートフォリオを棚卸しして「監査証跡が必要か」「プラットフォームとして機能しているか」の2軸で仕分ける。そしてSAP移行の議論の場に「AIエージェントを前提としたTo-Beの再設計」を同時に持ち込む。

あなたのTo-Beは、AIエージェントの時代に耐えられるか。

参考文献

関連記事：AIに代替されるSaaSとされないSaaS――EA歴10年が現場から言い切る

筆者：EAの中の人｜事業会社の社内IT部門にてエンタープライズアーキテクトとしてEA推進・ITガバナンス・データ活用・AI活用に携わって10年以上。
本記事の内容は個人の見解であり、所属組織を代表するものではありません。