技術的に可能かどうかは、もはや難しい問題ではない
「作れるか」という問いは、エンタープライズテクノロジーの世界で意味を失いつつあります。
バイブコーディングによって、アイデアと動くデモの距離は一気に縮まりました。しかし市場は、それをデモと本番環境の距離まで縮まったものと取り違えています。実際にはそうなっていません。ビジネスユーザーは、従来の開発サイクルを待たずに、有用なインターフェースや自動化を作れるようになりました。ですが、作りやすさがアーキテクチャ、ガバナンス、レジリエンス、セキュリティ、運用上のオーナーシップをもたらしてくれるわけではありません。
従業員は、MCPで接続されたインターフェースを通じて、エンタープライズアプリケーションに対話形式でアクセスできます。ある Genie がタスクを開始し、その一部を別の Genie に任せることもできます。従来型のワークフローが、LLMを使ってドキュメントを解釈してから、確立されたビジネスロジックへと処理を進めることもできます。
テクノロジーは、これらすべてのパターンに対応できます。
より重要な問いは、生まれたケイパビリティが再利用でき、ガバナンスを効かせられ、さらにエージェントプラットフォーム、モデル、プロトコル、インターフェースが変わっても機能し続けるかどうかです。
だからこそ、アーキテクチャがエンタープライズAIにおける中心的な課題なのです。
エージェントはユーザーの目に見える存在です。しかし、そのエクスペリエンスが企業内での長期的な利用に耐えられるかどうかは、エージェントの下にあるアーキテクチャが決めます。
三つのAIパターンを、三つのテクノロジースタックにしてはいけない
AIエクスペリエンスのたびに新しいインテグレーションが必要になるなら、そのアーキテクチャはすでに破綻しています。
Massimo の記事「エージェント型AIで成功するには、オーケストレーション戦略が必要」では、エンタープライズAIオーケストレーションの三つの側面が説明されています。企業は、エージェントをアプリケーションやデータに接続し、エージェント同士が連携して動けるようにし、さらにエージェントを決定論的なビジネスプロセスに組み込む必要があります。
これらの側面は、私が Workato で目にするパターンとよく重なります。
一つ目のパターンは、MCPを通じた、システム・オブ・レコードへの対話型アクセスです。
MCPによる接続は、AIインターフェースをエンタープライズアプリケーションにつなぐ実用的な手段になり得ます。企業が必要とするコンテキストとアクションをAIにもたらし、AIをはるかに有用なものにします。
二つ目のパターンは、エージェント間のコラボレーションです。
ある Genie がタスクを開始し、より適した専門性やアクセス権を持つ別の Genie があると判断して、作業の一部を引き継ぐことがあります。これにより、一つのエージェントにすべてを理解させ実行させるのではなく、複雑なプロセスを責任範囲の明確な単位に分割できます。
三つ目のパターンは、従来型のワークフローの内部に組み込まれたAIです。
請求書を受領したとき、AIはそこから仕入先、請求書番号、合計金額、明細を抽出できます。その後、Workato のレシピが、情報を検証し、関連する発注書を取得し、NetSuite 内の該当レコードを特定し、ビジネスルールを適用し、不一致を洗い出し、次のアクションを決定します。
これらのエクスペリエンスは見た目がまったく異なるかもしれません。しかし、エンタープライズのケイパビリティを利用するものであれ、オーケストレーションするものであれ、体現するものであれ、同じガバナンスされたケイパビリティ・アーキテクチャに参加するべきです。
MCPで接続を標準化しても、混乱は生まれ得る
共通のプロトコルがあるからといって、企業全体が一貫した状態になるとは限りません。
MCPは、AIインターフェースやエージェントがツールを発見し呼び出すための手段として、重要性を増しています。しかし、プロトコルが標準化されたからといって、それらのツールが自動的に再利用可能、効率的、ガバナンス済み、本番対応になるわけではありません。
MCPサーバーが、粒度の細かいアプリケーション操作を何十個も公開し、どの操作をどの順序で呼び出すか、どの情報を保持するか、ステップが失敗したときにどう復旧するかをモデルの判断に委ねることもあります。
技術的には、それでも動くかもしれません。しかしアーキテクチャの観点では、ポイント・ツー・ポイント・インテグレーションの最悪の特性を再現しています。各エージェントが、自分自身でシーケンス制御、ビジネスルール、アプリケーションへの依存関係、障害処理、プロセスの解釈を担うことになります。エージェントが増えるほど、同じエンタープライズプロセスが少しずつ異なる形で何度も実装されます。接続は増え、ロジックは乖離し、統制は緩み、アプリケーションを変更するたびに依存関係の網は大きくなっていきます。
プロトコルは標準化されていても、アーキテクチャはポイント・ツー・ポイントのままです。単にモデルが呼び出しを行うポイント・ツー・ポイント・インテグレーションにすぎず、アーキテクトにとって最悪の悪夢です。
「AIトークンの価格低下でも、AIエージェントのコストが上昇し続ける理由」を取り上げた Workato の記事では、低レベルのアクションの集合を公開することと、成果に焦点を当てた、範囲の明確なビジネスケイパビリティを公開することの違いが説明されています。エージェントが個々の操作をすべて自分で調整しなければならない場合、そのプロセスにはより多くの推論、より多くのコンテキスト、より長いレイテンシ、そしてより多くのエラーの機会が必要になります。
エージェントに必要なのは、アプリケーションのあらゆる生の操作への無制限のアクセスではありません。適切なエンタープライズケイパビリティへのアクセスです。そのケイパビリティには、明確な入力、範囲の定まった振る舞い、組み込まれたビジネスルール、予測可能な障害処理、構造化された結果が備わっているべきです。
最初の接続を素早く実現することと、最終的なエンタープライズアーキテクチャを混同してはいけません。ユースケースが成熟するにつれて、そのツールは再利用可能でガバナンスされたケイパビリティ・レイヤーの一部になるべきです。そうでなければ、新しいエージェントが増えるたびに、独自の接続、認証情報、ワークフローロジック、そして同じビジネスプロセスに対する独自の解釈が持ち込まれます。
それはAI戦略ではありません。会話型インターフェースを備えた、インテグレーションのスプロール化です。
Workato では、製品が提供するスターターテンプレートを使って、ユーザーにとって最も重要な MCP サーバーを素早く展開しました。たとえば、Salesforce と Gong にまたがる顧客コンテキストの把握、Google Calendar からの当日の予定の取得、Jira チケットの作成などです。その後、チームはユーザーがこれらの MCP サーバーをどのように利用しているかを分析し、自社のニーズに合わせて繰り返し改善を重ねました。また、これらの MCP は当初から、すべての MCP クライアントがシステム・オブ・レコードに接続するために利用するサービスとして構築され、社内で使用されているすべての MCP クライアントに実装されました。
これにより、拡張性のあるオンボーディングとガバナンスのパターンを確立できました。どの MCP クライアントでも、同じ管理された MCP サーバーを利用でき、車輪の再発明をする必要がありません。今後どのような新しい MCP クライアントや AI ツールを導入しても、それらはすべて Workato 上でホストされる、ガバナンスされた拡張性のある同じ MCP サーバーに接続します。そのため、初日から一貫した基本的な安全対策が整った状態になります。
エージェント間のコラボレーションで受け渡すのは、複雑さではなく作業であるべき
タスクの引き継ぎが、アーキテクチャの引き継ぎになってはいけません。
ある Genie が別の Genie に作業を割り当てる場面でも、同じ原則が当てはまります。
エージェント間コラボレーションの価値は、専門性にあります。ある Genie は大きな目標を理解しており、別の Genie は特定のタスクを完了するための適切な知識、アクセス権、あるいはビジネス上の責任を持っているかもしれません。
しかし、受け取る側の Genie が、関連性のない操作の一覧から、アプリケーションのプロセス全体を再構築しなければならない状況は避けるべきです。受け取るのは範囲の定まった依頼であり、その作業を完了させるガバナンスされたケイパビリティにアクセスできるべきです。
たとえば、経理担当の Genie が、ある請求書が既定の照合ルールの範囲外であると判断したとします。その場合、ガバナンスされたエンタープライズケイパビリティを体現する専門の Genie に、範囲を限定した依頼を委任します。
この専門の Genie こそが、再利用可能なエンタープライズケイパビリティです。範囲の定まった依頼を受け取り、関連するレコードを取得し、確立されたルールと判断を適用して、意味のある結果を返します。経理担当の Genie は、その背後にある請求書処理のプロセスを理解したり再構築したりする必要はありません。
これにより、引き継ぎのテスト、セキュリティ確保、ガバナンス、進化がしやすくなります。エージェントは専門性を高めつつ、エンタープライズケイパビリティは一貫したまま保たれます。
再利用はガバナンス戦略
重複したAIワークフローは、そのたびにポリシー例外の火種になります。
再利用性は、開発上のメリットとして語られることが多いものです。しかし同時に、最も実践的なガバナンスの形の一つでもあります。不要な重複が一つ生まれるたびに、セキュリティ確保、テスト、モニタリング、バージョン管理、保守の対象となる実装が一つ増え、ポリシーが乖離しかねない場所も一つ増えます。
MCPクライアント、Genie、従来型のレシピ、データパイプラインのすべてが同じエンタープライズケイパビリティを呼び出せるなら、組織はコアとなるビジネスロジックの実装を減らすことができ、セキュリティ確保、テスト、モニタリング、保守の対象も減らせます。
コアとなるビジネスルールとケイパビリティ・コントラクトは一貫して保てます。一方で、実行、アイデンティティ、承認、復旧に関するポリシーは、認可されたチャネルと運用コンテキストに応じて変えられます。プロセスが変わったときも、エージェントごとの複数のバージョンを探し回るのではなく、共有されたケイパビリティを更新すれば済みます。
Massimo は、場当たり的なアプローチはPoC(概念実証)では機能するかもしれないが、組織が数十、数百のエージェントを展開し始めると持続不可能になると警告しています。その結果、ツールの重複、管理されていないオーケストレーション、一貫性のないガバナンス、運用コストの上昇、そして後から是正するのが難しい技術的負債が生じかねません。
共有ケイパビリティ・レイヤーは、すべてのAIプロジェクトを単一の中央集権的なチームが構築するという意味ではありません。チームは、共通のプラットフォーム、共通の標準、そしてエンタープライズケイパビリティは再利用可能な資産であるという共通認識を共有するべきです。共有されるケイパビリティにはそれぞれ、明確なドメインオーナー、ガバナンスされたアクセス、バージョン管理、サポートの期待値、そして廃止のプロセスが必要です。この運用モデルがなければ、再利用は管理されない依存関係の一形態になってしまいます。
Workato では、オーナーシップはビジネスプロセスに最も近いドメインが持ちます。たとえば、Marketing Operations は、Marketo でキャンペーンを作成するためのガバナンスされた MCP ケイパビリティを所有しています。キャンペーン作成にまつわるビジネスルール、データ、ポリシーもこれに含まれ、それがカスタムの Workato MCP ツールとして共有されています。新しいAIインターフェースは、キャンペーンのプロセスを作り直したり、オーナーシップを中央のプラットフォームチームに移したりすることなく、このケイパビリティを再利用できます。
インターフェースは、特定のチームに属するかもしれません。しかしその下にあるケイパビリティは、責任を負うドメインオーナーを持つエンタープライズの資産です。
インターフェースは変わっても、ケイパビリティは残るべき
エンタープライズプロセスを装ったエージェント固有のワークフローは、AIというラベルを貼っただけの技術的負債です。
モデルは変わります。
エージェントプラットフォームは変わります。
プロトコルは成熟していきます。
新しいインタラクションチャネルが登場します。
AIテクノロジースタックがこれほど急速に変化していく中でも、基盤となるエンタープライズケイパビリティは、それと対話するレイヤーで何が起きようとも、安定し、ガバナンスされ、再利用可能であり続けなければなりません。
Workato のおかげで、私のチームは、MCP接続、エージェント間コラボレーション、組み込みのLLMステップ、データパイプライン、従来型のオーケストレーションを、別々のテクノロジー領域として扱わずに済んでいます。同じプロセスが、人がAIインターフェースに話しかけることで始まることもあれば、Genie がタスクを割り当てることで始まることも、ドキュメントが届くことで始まることも、アプリケーションがイベントを発行することで始まることも、スケジュールされたデータパイプラインが実行されることで始まることもあります。
エントリーポイントは変わっても、エンタープライズロジックまで変える必要はありません。これこそが、エンタープライズAIに求められるアーキテクチャです。ケイパビリティを一度構築し、認可されたすべてのインターフェースに使わせるのです。
これで、最初の課題である分断(フラグメンテーション)は解決します。
しかし、コンテキストの問題は解決しません。
エージェントが有用な判断を下せるのは、周囲のシステムが適切な情報を集め、AIの判断が本当に必要になるタイミングを見極めているときだけです。
それが、パート2のテーマです。
