ソートリーダー
次のソフトウェアユーザーはAIエージェント。あなたのアーキテクチャは対応できていますか?

AIエージェントが顧客からの請求に関する異議申し立てに対応する場面を想像してみてください。申し立ての内容を読み、アカウントの履歴を確認し、返金クレジットを付与すべきだと判断します。すべて数秒のうちに完了します。
見事です。では実際にクレジットを発行するよう指示してみてください。
顧客との契約は別のシステムにあります。承認ルールはアプリケーションのコードに埋もれています。請求処理ツールは、人が複数の画面を順にクリックして操作することを前提としています。
エージェントは何をすべきか理解していますが、アーキテクチャがその作業の完了を妨げています。
エージェント型AIが本番環境で稼働し始めるにつれて、より多くの企業が直面するだろうと私が考えているのは、まさにこの問題です。しかし不思議なのは、タスクを完了できない障壁が、エージェントの知能とはほとんど関係ないことです。
これまで私たちは、エンタープライズソフトウェアを使う人々のために、何年もかけてその近代化に取り組んできました。今度は、ますます多くの業務を担うようになるエージェントのために、ソフトウェアを近代化する必要があります。
ユーザーインターフェースだけが製品のすべてではなかった
現在のエンタープライズソフトウェアの使われ方を考えてみてください。人々はアプリケーションを開き、ダッシュボードを操作し、判断を下し、あるシステムから別のシステムへと業務を引き継ぎます。ユーザーインターフェースは、ビジネスとやり取りするための手段です。
エージェントに、そうした画面が必要とは限りません。APIやモデルコンテキストプロトコル(MCP)サーバー、その他のプログラム用インターフェースを通じて、情報を取得したり処理を開始したりできます。これは、ヘッドレスアーキテクチャへの移行の一端です。
しかし、ヘッドレス化によってアプリケーションが消えてなくなるわけではありません。アプリケーションのデータ、ビジネスルール、権限、コンプライアンス要件は、依然として重要です。むしろ、以前にも増して重要になると私は考えています。
長年、ソフトウェアベンダーは、洗練されたユーザーインターフェース、ユーザーの習慣、従業員の再教育にかかるコストを競争優位の源としてきました。エージェントがアプリケーションのユーザーインターフェースを開かずに多くの業務をこなすようになると、こうした優位性は弱まります。より価値を増すのは、その基盤となる記録システムです。信頼できるデータ、検証済みのドメインロジック、運用ガバナンス、そして監査可能な取引が重要になります。
商業面にも影響があります。2030年までに、エンタープライズアプリケーションへの支出のうち、最大で2,340億ドルがエージェント型AIによる変革の影響を受ける可能性があります。これは変革によって影響を受けるリスクがある支出であり、消失が確実な支出という意味ではありません。また、かつてダッシュボード上で人が行っていた業務をエージェントが担うようになれば、ユーザー数に応じた料金体系は、利用量、実行したアクション、または成果に基づく料金体系へと、ますます移行していく可能性があります。
ソフトウェアベンダーにとって、これはビジネスモデルの課題です。アプリケーションに依存する企業にとっては、アーキテクチャの課題です。
部分ごとは近代化してきたが、ワークフローはそうではない
多くの企業は、何年も前から近代化に取り組んできました。あるチームはレガシーアプリケーションを更新し、別のチームは分散したデータを最新のプラットフォームに集約します。さらに別のチームは連携機能を構築したり、単にユーザーインターフェースを刷新したりします。
それぞれのプロジェクトは、単独では成功することがあります。問題が始まるのは、エージェントがそれらすべてにまたがるワークフローを実行しなければならないときです。
エージェントに正確な顧客情報を与えても、その情報に基づいて処理するアプリケーションの重要なルールがレガシーコードに埋もれていたら、その先に何が起きるでしょうか。あるいは、整然としたAPIを公開しても、その背後にあるデータに一貫性がなければどうでしょう。エージェントは処理を実行できますが、その判断を信頼できるでしょうか。
どちらの場合も、技術の一部は近代化できていますが、業務そのものは近代化できていません。
エージェント型AIは、どの近代化プロジェクトが成功したかを気にしません。関心があるのは、ワークフロー全体が機能するかどうかです。
実際には、次のようなケースがあります。あるクライアントは、複雑なエンジン修理の見積もりを迅速化する必要がありました。契約によって、どの部品を修理、交換、再生できるかが定められている案件です。契約書や整備マニュアルを手作業で調べるため、見積もりごとに数日、ときには数週間かかっていました。クライアントはすでにデータプラットフォームを近代化していましたが、見積もりの作成は速くなりませんでした。ボトルネックはデータではなかったからです。問題は調査にありました。私たちは複数の調査エージェントを活用してワークフローを再構築し、調査時間を80%削減しました。その結果、見積もりの進むスピードは一変しました。
だからこそ、アプリケーションの近代化とデータの近代化を、互いに独立した2つの作業として計画することはできません。アーキテクチャは、ビジネス上の成果を最後まで実現できるものでなければなりません。
APIがあっても、システムがエージェントに対応できるとは限らない
答えは簡単だと思いたくなるかもしれません。エンドポイントを公開し、エージェントを接続すれば、それで完了だ、と。
そんなに簡単ならよかったのですが。
情報を取得することと、クレジットを発行したり、財務記録を更新したり、交換用の部品を注文したりすることは、まったく別です。ここで必要なのは、単なるアクセスではなく、処理の実行です。
ここで私が使うのが、エージェント制御面という用語です。これは、範囲とガバナンスが定められたインターフェースであり、エージェントが記録システムから情報を読み取り、そこに書き込むためのものです。
APIやMCPサーバーを通じて、エージェントにツールやデータを公開できます。しかし、MCPがビジネスルールを自動的に適用したり、誰に実行権限があるかを判断したりするわけではありません。こうした制御は、引き続き基盤となるシステムやワークフローに組み込む必要があります。
エージェントは信頼できる正確なデータを取得できるでしょうか。ビジネスルールは明確に定められ、一貫して適用されているでしょうか。行動を提案しつつ、実行できるのは実行を許可された行動だけでしょうか。問題が起きたとき、その処理を追跡し、例外に対処し、可能であれば元に戻せるでしょうか。
こうした問題は、より優れたモデルを導入するだけで解決するものではありません。ワークフロー、アプリケーション設計、データアーキテクチャ、統合、ガバナンスに関する課題です。そして、これらには一体となって取り組まなければなりません。
テクノロジーではなく、業務から始める
では、どこから始めればよいでしょうか。
すべてのアプリケーションをヘッドレス化したり、利用可能なAPIをすべて公開したりすることから始めるつもりはありません。まずは、事業にとって重要なワークフローを一つ選びます。
そのワークフローを最初から最後まで追ってみましょう。記録を保持しているシステムはどれでしょうか。ビジネスロジックはどこにあるでしょうか。エージェントが信頼できるデータは何でしょうか。どの判断に人の承認が必要でしょうか。システムが途中で停止したらどうなるでしょうか。ガバナンスはどのように維持されているでしょうか。
そうすれば、重要な課題が見えてきます。それが、アプリケーション、データ、統合、制御にまたがる、連携の取れたバックログとしてまとめるモダナイゼーションのロードマップです。ばらばらの技術プロジェクトではなく、事業成果を軸に進めます。
評価も、それに即して行いましょう。公開したAPIの数や移行したデータ量ではなく、ワークフローが確実に完了するか、例外がどのように解決されるか、そして事業成果が向上しているかを基準にします。
目指すのは、あらゆる場面での自律化ではありません。人の判断が必要なところでは人が判断しながら、確実で信頼できる実行を実現することです。
本質的な変化はヘッドレス化にとどまらない
私が期待しているのは、ダッシュボードをなくすことではありません。仕事を進めるために、人が分断されたシステム間で手作業によって業務を受け渡す必要がなくなったときに何が起きるか、ということです。
しかし、エージェント向けに設計されていないアーキテクチャの上にエージェントを載せても、そこにはたどり着けません。
次世代のエンタープライズソフトウェアを決めるのは、人が何を見られるかだけではありません。エージェントが何を確実かつ責任を持って実行できるかも、その価値を決めるのです。











