SaaSは、誰が使うものか？──"人が使う"から"AIが使う"へ。アプリケーションアーキテクチャの主語転換

3. なぜERPは変革の足かせになったのか？

従来のアプリケーションアーキテクチャは、記録・統制・効率化を主目的に、ERPを中心とする構造で発展してきました。「業務にシステムを合わせる」発想で大量のアドオン開発を行い、密結合のモノリシック構造（システム全体が一体化した構造）を形成しました。根本前提は、「人がシステムを使う」ことでした。しかし時間とともに、個別要件を取り込み続けた結果、システムは複雑化し、一部機能の変更にも影響調査と大規模テストが必要になり、ブラックボックス化が進みました。AIを活用しようにも、必要なデータを取り出すことすら容易ではありません。Traditionalなアーキテクチャは、記録・統制・効率化には強みを持っていましたが、結果として、変化し続ける意思決定には対応できない構造となっていました。

4. SaaSを増やしたのになぜ業務は速くならないのか？

SaaSやクラウドの普及により、企業はコンポーザブル（機能を組み合わせて使う）な発想へと転換しました。SaaSをAPIで接続し、Fit to Standardでベストプラクティスを取り込む。つまり、「人がサービスを組み合わせる」時代です。サービス単位での導入・変更が可能になり、市場変化への対応速度は向上しました。しかし、新たな問題も生まれています。SaaS乱立、データ分断、APIスパゲティ（複雑化）、PoC乱立です。多くのPoCは「技術が使えるか」を確認しますが、「どの意思決定を変えるか」までは設計していません。予測精度が上がっても、

• 誰が結果を確認するのか
• どの判断に使うのか
• どのKPIで評価するか

が定義されていなければ、AIは現場の便利ツールで終わります。サービスを組み合わせる主体が人である限り、全体設計なしには複雑性が増え続けるのです。

5. AIがSaaSを"使う側"になる日が来る？

AI時代の本質的変化は、アプリケーションの「使われ方」が逆転することにあります。従来、業務の起点はシステムにあらかじめ定義されたプロセスでした。AI-Driven時代には、起点は顧客問い合わせ、市場変動、在庫不足、売上の異常変動といったイベントになります。AIエージェントがそれを捉え、必要なデータ・アプリケーション・外部サービスを動的に組み合わせて対応します。ERPパッケージ、SFA、HCM、社内ワークフローなど、それぞれのソリューションは、業務領域に閉じたシステムではなく、AIが必要に応じて呼び出す「機能リソース」へと変わります。

一言で言えば、「人がSaaSを使う」から「AIがSaaSを使う」への転換です。

ここで決定的に重要なのは、AIエージェントが複数システムを横断できる前提条件です。

• APIが整備されている
• データ定義が統一されている
• 適切な権限設計が行われている
• 業務プロセスがシステムに固定されていない

このようにアプリケーション構造そのものを、AIが活用できる形に再設計することで、AIは必要なデータを取り出し、正しい数字を判断して、生成した最適解を実行に移すことができるのです。

ただし、すべてがAIに置き換わるわけではありません。AIは実行・支援・高度化を担う一方で、人はより高度な判断・創造・合意形成に集中します。どこをAIに委ね、どこに人が介在するかを設計することが、AI時代のアプリケーションアーキテクチャの核心となります。

6. 機能を組み合わせるか、意思決定を組み替えるか？

今後必要なのは、ERP、SaaS、AIエージェント、データ、業務、組織、ガバナンスを統合した、全体最適の意思決定構造です。本稿ではこれを、「デジタル・エンタープライズ・アーキテクチャ」と定義します。その中でアプリケーションアーキテクチャは、ERP・SaaS・AIエージェントの役割分担を設計する役割を担います。

具体的には、以下の設計原則が重要になります。

1. Composable Architecture：単なる部品化ではなく、「どの意思決定を支える機能を、どの粒度でモジュール化するか」を設計します。
2. API-First設計：APIは、「システム同士をつなぐもの」から、「AIエージェントが呼び出すインターフェース」へと性格が変わります。
3. Agentic Workflow：業務プロセスは固定手順ではなく、AIエージェントが状況に応じて動的に組み立てる実行フローへ変わります。どのイベントを起点に、どこまで自律実行し、どこで人の判断を仰ぐかを定義します。
4. Human-in-the-loop設計：AIが提案し、人が承認し、結果を学習へ反映するサイクルを、業務粒度と条件で設計します。
5. Product Operating Model：プロジェクト型開発から、業務機能や意思決定領域をプロダクトとして継続的に進化させる運営モデルへ移行します。

7. どの意思決定から、変えるべきか？

Phase 1：問いの設計と意思決定の可視化

最初に行うべきは、技術選定でも、システムの棚卸しでもありません。「どの意思決定を変えるか」の定義です。

需要予測、価格決定、在庫配置、営業優先順位、投資判断、顧客対応――企業ごとに競争力を左右する意思決定は異なります。その意思決定を支えるデータ、AI、業務プロセス、APIを逆算して整理します。

「どのシステムを使うか」の前に、「何を判断するために、何が必要か」を設計する順序が重要です。

Phase 2：PoCで終わらせず、業務に組み込む

AIモデルが動くだけでは、業務は変わりません。判断結果が業務システムに連携され、人の承認フローを経て、実際のアクションにつながる状態を作る必要があります。

需要予測AIであれば、予測結果を誰が確認し、どの条件で生産計画を変更し、どの例外は人が判断するかまで設計します。販売計画・生産計画・在庫配置・財務見通しという意思決定の連鎖に組み込まれて初めて、業務組込みが実現します。

API設計、データ定義、エージェント設計、ガバナンスルールを再利用可能な形で整備することで、全社へのスケールが可能になります。小さく始めることと、全社最適の思想を持つことは矛盾しません。

8. アーキテクチャが、変革を回すエンジンになる日は来るか？

EYは、アーキテクチャを単なるシステム構成設計とは捉えていません。AI時代におけるアーキテクチャは、企業の意思決定構造を実行可能な形に落とし込む、経営の中核アジェンダであると考えています。

構想フェーズでは、経営、事業、IT、データ、AIを統合し、高度化すべき意思決定を明確化した上で、AI時代におけるデジタル・エンタープライズ・アーキテクチャの将来像を描きます。ロードマップ策定では、レガシーや投資規模、事業環境変化を踏まえ、現実的な変革ステップへ落とし込みます。実行フェーズでは、個別プロジェクトが全体アーキテクチャと整合するよう、継続的な統制と支援を行います。

最も重視するのは、アーキテクチャをドキュメントとして終わらせないことです。アーキテクチャは、変革を止めるための統制ではなく、変革を回し続けるための意思決定ルールであるべきです。AI時代のアプリケーションアーキテクチャは、業務を固定的に実行する器から、AIがERP、SaaS、データ、外部サービスを動的に組み合わせ、意思決定を高度化するエンジンへと進化します。DXの本質は、意思決定構造を最構想し、業務に組み込み、継続的に進化させることにあります。