エンタープライズAIエージェントが実行で失敗する理由と解決策

エンタープライズAIエージェントが失敗するのは推論ではなく実行においてです。そしてその失敗はアーキテクチャ上の問題であり、技術的な問題ではありません。

今日の大規模言語モデルの推論能力は、エンタープライズAIのパイロットが本番環境に移行できない原因ではありません。モデルは考えることができます。意図を解釈し、コンテキストを統合し、マルチステップのシーケンスを計画し、正確な出力を生成できます。パイロットが機能して本番デプロイが機能しなかった理由は、モデルではありません。

ボトルネックはモデルとエンタープライズの間のレイヤーにあります。エージェントが誰として行動するか、どのシステムにアクセスできるか、それらのシステム内で実際に何を行うことが許可されているか、そしてそのアクションが確実に実行されるか、それとも脆弱なAPIコールを毎回ゼロから組み立てて実行されるかを決定するインフラです。

ネットワークアーキテクチャの用語で言えば、データプレーンはエージェントがエンタープライズシステムに対してアクションを実行する場所です。コントロールプレーン（具体的にはAIコントロールプレーン）はエージェントが行えることを決定するガバナンスレイヤーです。ほとんどのエンタープライズAIデプロイには、適切なAIコントロールプレーン（アイデンティティと監査が機能しない）も、適切な実行プレーン（エージェントが生のAPIでデータプレーンを即興実行する）もありません。解決策はアーキテクチャ的です。デプロイの後ではなく前に、両方のレイヤーを統一されたインフラとして確立することです。

あるFortune 100の金融ソフトウェア企業はアーキテクチャを正しく構築しました。39のMCPサーバーを本番環境にデプロイし、新しいAIユースケースの提供を2〜3ヶ月から2〜3時間に短縮し、LLMトークン消費を93%削減し、フラットなトークン支出でAIツールの利用を10倍に増やしました。パイロットと本番デプロイの間でモデルは変わりませんでした。変わったのはアーキテクチャです。具体的には、ビジネスプロセスの実行を担うガバナンスされた実行プレーン（データプレーン）を追加し、モデルがオーケストレーションを即興するのではなく推論に集中できるようにしました。

なぜエンタープライズAIエージェントは推論ではなく実行で失敗するのか？

エンタープライズAIプログラムを終わらせる失敗のパターンは予測可能で一貫しています。パイロットが管理された環境では機能するが、本番環境に移行しようとすると3つの壁のひとつにぶつかります。

壁1：アイデンティティ。 エージェントはSalesforce・Workday・ServiceNowにおいて実際のユーザーとして行動する必要があります。しかし利用可能な認証情報は広範な権限を持つ共有サービスアカウントだけです。セキュリティチームはそれを承認しません。CISOはエージェントが誰として行動したかを問い、誰も検証可能な答えを持っていません。デプロイが停止します。これはAIコントロールプレーンの失敗です。ユーザーごとのアイデンティティメカニズムが存在しません。

壁2：ガバナンス。 エージェントはツールレベルの境界を必要とします。顧客レコードを読むことはできるが変更はできない、チケットを作成することはできるが解決はできない、などです。アクセス制御システムはシステムへのアクセスを許可します。AIエージェントのアクションに対してスコープされた・ユーザーごとの・ツールごとのパーミッションは付与しません。そのガバナンスレイヤーをゼロから構築するのは数ヶ月のプロジェクトです。これもAIコントロールプレーンの失敗です。アクションレベルのガバナンスレイヤーが存在しません。

壁3：実行。 エージェントはマルチステップのビジネスプロセスを実行する必要があります。払い戻しの処理・従業員のオンボード・パスワードのリセット。エージェントには生のAPIがあります。コールのシーケンスを組み立て、各システムの認証を個別に処理し、リトライロジックを管理し、毎回ゼロからワークフロー全体を再構築します。これはデータプレーンの失敗です。実行プレーンには繰り返し可能なビジネスアクションのための共有インフラがないため、すべてのエージェントがデータプレーンで即興実行し、大幅なトークンコストをかけます。

これらの失敗はいずれも推論の失敗ではありません。モデルは何をすべきか知っています。AIコントロールプレーンと実行プレーンのインフラが、それを安全かつ確実に実行できる環境を提供していないのです。

エンタープライズAIにとって「アーキテクチャの失敗」とは何か、なぜ技術的な失敗と異なるのか？

技術的な失敗は、壊れたものを反復的に改善することで修正できます。誤った出力を返すモデルはファインチューニングできます。壊れたエンドポイントを持つコネクタはパッチ適用できます。

アーキテクチャの失敗は構造的です。存在しているものを改善するのではなく、欠けているインフラを立ち上げることが必要です。

ほとんどのエンタープライズAIプログラムがぶつかるアーキテクチャのギャップは次のとおりです。エージェントが個々のチーム内の実験として展開された、各実験が独自の認証情報とデータプレーン接続を立ち上げた、共有のAIコントロールプレーンが確立されなかった、そして今エンタープライズには数十の孤立したパイロットがあり、各パイロットのガバナンスと実行インフラを再構築せずに本番環境への道筋がない状態です。

これはエンタープライズがAPIスプロールで経験したのと同じ話です。すべてのチームが独自のインテグレーションを構築しました。それぞれが独立して機能しました。インフラを共有したものは何もありませんでした。事後に統合しようとしたエンタープライズは何年もかけて何千もの個別ビルドを解体することになりました。

エンタープライズAIはそのパターンをより速く繰り返しています。エージェントはAPIより速く増殖するからです。パターンを早期に認識したエンタープライズは、スケール後ではなくスケール前にAIコントロールプレーンと実行プレーン（データプレーン）を確立しています。

エンタープライズAIにおけるデータプレーンとは何か、なぜそこでエージェントは失敗するのか？

エンタープライズAIにおけるデータプレーンは実行レイヤーです。エージェントがエンタープライズシステムに対してアクションを実行し、ツールを呼び出し、ビジネスプロセスを実行する場所です。この用語はネットワークアーキテクチャに由来します。データプレーンはトラフィックを運び、コントロールプレーンがそれをルーティングします。エンタープライズAIにおいて、データプレーンはエージェントのアクションがSalesforce・ServiceNow・Workday・SAP・その他あらゆるシステムオブレコードに着地する場所です。

ほとんどのエンタープライズAIガバナンスの議論はAIコントロールプレーン（誰が何を行えるか）に焦点を当て、データプレーンをエージェントの責任として扱います。エージェントはシステムに到達し（コントロールプレーンがアクセスを承認）、その後実行ロジックを即興します。APIコールを組み立て、システムごとの認証を管理し、エラーを処理し、毎回ゼロからワークフローを再構築します。

失敗はここに潜んでいます。データプレーンがガバナンスされていないのは、AIコントロールプレーンがそれをガバナンスするのを忘れたからではなく、実行プレーンのインフラ、つまりデータプレーンが実行すべきプリビルドの共有ビジネスプロセスロジックが存在しないからです。エージェントが即興します。モデルがプラットフォームで実行すべきオーケストレーションのためにトークンを消費します。結果は脆弱でコストが高く、チームをまたいで再利用できません。

アーキテクチャ上の解決策はより優れたモデルではありません。データプレーンに必要なものを提供する実行プレーンです。エージェントが生のAPIから組み立てる代わりに呼び出す、プリビルドでガバナンスされたビジネスアクションです。

AIコントロールプレーンはどのようにしてエージェントの実行プレーン（データプレーン）をガバナンスするのか？

AIコントロールプレーンと実行プレーン（データプレーン）は、エンタープライズAIアーキテクチャにおいて特定の関係を持ちます。

• AIコントロールプレーンは次を決定します。このエージェントは誰として行動しているか（Verified User Authenticationによるアイデンティティ）、何を行えるか（ツールレベルのRBACによるアクセス範囲）、そして何が起きたか（アクションごとの監査証跡）です。
• 実行プレーン・データプレーンはガバナンスされたアクションが実行される場所です。ビジネスプロセスが実行され、マルチシステムコールが完了し、結果が返されます。

AIコントロールプレーンが実行プレーンを効果的にガバナンスするには、両方が同じインフラの一部である必要があります。エージェントのアクションを承認しながらエージェントに生のAPIを渡すスタンドアロンのAIコントロールプレーンは、データプレーンをガバナンスしていません。アクセス決定をガバナンスし、その後コントロールを手放しています。

Workato Enterprise MCPは両方を統一します。AIコントロールプレーン（VUA・ツールレベルRBAC・監査・コンプライアンス）はアクションがデータプレーンに到達する前に検証します。実行プレーン（エンタープライズスキル・ステートフルオーケストレーション・1,200以上のコネクタ）はガバナンスされたプリビルドのビジネスロジックを通じてアクションを実行します。データプレーンはガバナンスされていない実行を一切見ません。

MCPサーバーを生成してもガバナンス問題が解決されないのはなぜか？

MCPサーバーを生成することは本当に簡単です。ツールの成熟により、開発者は午後だけでビジネスシステムをMCPサーバーとして公開できます。単一チームの社内ワークフローには適切な選択かもしれません。

エンタープライズの本番環境では、生成は簡単な部分が終わる場所です。

生成が提供しないもの：ユーザーごとのアイデンティティ伝播（AIコントロールプレーン）、ユーザーごとのツールレベルアクセス範囲（AIコントロールプレーン）、コンプライアンス要件を満たす監査証跡（AIコントロールプレーン）、PIIマスキング（AIコントロールプレーン）、マルチステップのデータプレーンワークフロー全体のトランザクション整合性（実行プレーン）、エラーハンドリングとリトライロジック（実行プレーン）、すべてのサーバーに対して無期限に続く上流APIバージョン変更を通じたメンテナンスです。

Workatoのフレームはこうです。生成はガバナンスされていません。生成されたMCPサーバーをエンタープライズの本番環境で運用するために必要なAIコントロールプレーンと実行プレーンのインフラが実際のプロジェクトです。そして一回限りのビルドではありません。サーバーの数に比例してスケールし、時間とともに複利的に増大するメンテナンスです。

Workatoと自作ビルドを比較評価したあるエンタープライズアーキテクトは、アイデンティティ要件を直接的に述べています。ユーザーごとのアイデンティティ伝播は「監査担当者から必要とされている」ものであり、自社で構築すれば認証情報が設定ファイルに浮いたままになると。それは生成だけでは解決されないAIコントロールプレーンの問題です。

ほとんどのエンタープライズAIデプロイが停止する原因となるアイデンティティ問題とは何か？

アイデンティティ問題はデータプレーン境界におけるAIコントロールプレーンの失敗です。

AIエージェントは実際のユーザーの代わりにエンタープライズシステムで行動する必要があります。しかしほとんどのエンタープライズがデフォルトとする認証情報インフラは、エージェントに実際のユーザーではなく共有サービスアカウントとしてのアクセスを与えます。エージェントがSalesforceやWorkdayのデータプレーン境界を越えると、検証された人物としてではなく、サービスアカウントとして到達します。

広範な権限を持つ共有サービスアカウントは、ほとんどのMCPサーバーが認証する方法です。そして多くのセキュリティレビューが失敗する方法でもあります。エージェントが検証されたユーザーではなくサービスアカウントとして行動すると、AIコントロールプレーンは監査担当者の基本的な問いに答えられません。このエージェントはデータプレーンで誰として行動したか、そして何を行う権限を持っていたか？

監査の問題を超えて、共有サービスアカウントの認証情報はセキュリティ上の負債です。サービスアカウントが侵害されると、それが触れるすべてのシステムが露出します。ユーザーのアクセスを取り消すべき場合（従業員の退職・役割の変更）、サービスアカウントの取り消しが唯一のレバーであり、それを共有しているすべてのエージェントに影響します。

アーキテクチャ上の解決策はユーザーごとのアイデンティティ伝播です。すべてのエージェントアクションが実際のユーザーのアイデンティティをデータプレーン境界を越えて運び、ソースシステム自体がそのアイデンティティを検証します。これがデータプレーンを監査可能にするAIコントロールプレーンの機能です。

Verified User Authenticationとは何か、そしてどのようにしてAIコントロールプレーンのアイデンティティギャップを解消するのか？

Verified User Authentication（VUA）は、サービスアカウントやAPIキーを信頼するのではなく、ソースシステム自体がアイデンティティを確認する形で、各エンドユーザーの実際のアイデンティティをすべてのAIエージェントアクションに伝播するWorkatoの特許取得済みメカニズムです。

VUAはAIコントロールプレーンがデータプレーンを監査可能にするために必要とするアイデンティティメカニズムです。WorkatoによってガバナンスされたエージェントがSalesforceでアクションを実行すると、Salesforceは実際の従業員のアイデンティティを認識します。その従業員が行うことを許可されていることにスコープされた形で。アクションはユーザーの実際のアイデンティティに対して記録されます。ユーザーのアクセスを取り消すと、エージェントがそのユーザーに代わって行動する能力が即座に取り消されます。共有認証情報に触れることなく。

VUAはエンタープライズデプロイで最も一般的なAIコントロールプレーンの失敗を解消します。「エージェントはデータプレーンで誰として行動したか？」という問いに、曖昧な形ではなく、ソースシステムによって検証された証拠をもって答えられない状態です。VUAは特許を取得しており、一般提供されています。ロードマップ上の予定項目ではありません。

セキュリティの会話への影響は次のとおりです。CISOがAIデプロイがデータプレーン境界を越えるために共有サービスアカウントを使用しているかどうかを問うとき、答えはノーです。エージェントは実際のユーザーとして行動し、ソースシステムによって検証され、そのユーザーが持つ正確なパーミッションの範囲内で動作します。

なぜAIパイロットは大企業で本番環境に到達できないのか？

機能したパイロットとスケールする本番デプロイの間のギャップは4つのインフラのギャップです。AIコントロールプレーンに2つ、実行プレーンに2つあります。

コントロールプレーンのギャップ1：共有アイデンティティモデルがない。 各パイロットがデータプレーン用の独自の認証情報を立ち上げます。パイロットをまたいでガバナンスする時が来ても、ガバナンスの起点となる統一されたアイデンティティレイヤーがありません。

コントロールプレーンのギャップ2：アクションガバナンスがない。 アクセス制御システムはシステムへのアクセスを許可します。データプレーン上のAIエージェントアクションに対するツールレベル・ユーザーごと・アクションごとのガバナンスは付与しません。

実行プレーンのギャップ1：共有データプレーンインフラがない。 各パイロットのエージェントが生のAPIからデータプレーンワークフローを組み立てます。そのロジックは再利用可能でなく、共有されず、ガバナンスされません。スケールは脆弱性とコストを増大させます。

実行プレーンのギャップ2：採用モデルがない。 パイロットを次のユースケースに拡張するには別の完全な構築サイクルが必要です。次のデータプレーンのユースケースが継承できる「初日からのガバナンス」がありません。

Workato Enterprise MCPは4つすべてに対処します。Fortune 100の金融ソフトウェア企業の結果（ユースケースあたり2〜3ヶ月から2〜3時間、93%のトークン消費削減）は、スケール前にAIコントロールプレーンと実行プレーンの両方を確立した複合的な成果です。

AIアクセス制御とAIアクションガバナンスの違いは何か？

アクセス制御が答える問いは「このエージェントはこのシステムに接続してデータプレーン境界を越えられるか？」です。

アクションガバナンスが答える問いは「このエージェントがデータプレーン境界を越えるとき、ツールレベルでこの特定のユーザーに対して具体的に何を行うことが許可されているか、そしてそれを監査担当者に証明できるか？」です。

アクセス制御は前提条件です。それだけでは十分ではありません。アクセス制御を通過したエージェントは依然として、特定のユーザーがデータプレーンで許可されている範囲をはるかに超えて行動できます。

アクションガバナンスはエンタープライズAIが必要とし、スタンドアロンのゲートウェイが頻繁に省略する追加のAIコントロールプレーンレイヤーです。ツールレベルのスコープは各ユーザーのエージェントが呼び出せる実行プレーンのアクションを正確に定義します。フィールドレベルセキュリティはエージェントがユーザーのパーミッション外のデータフィールドにアクセスすることを防ぎます。監査証跡はすべてのアクション・ツール呼び出し・データアクセスを、ユーザーごと・エージェントごと・セッションごとに記録します。実行プレーンが業務を完了する間も。

Workato Enterprise MCPはアクセス制御とアクションガバナンスの両方を統一プラットフォームとして提供します。AIコントロールプレーンがガバナンスします。実行プレーン（データプレーン）はそのガバナンスのもとで実行します。

実行プレーンがAIコントロールプレーンと同じくらい重要なのはなぜか？

AIコントロールプレーンはエージェントが行えることを決定します。実行プレーンはデータプレーン上でそれを確実に・ガバナンスされた形で・再利用可能な方法で実現します。

ガバナンスのみのアーキテクチャ（実行プレーンなしのAIコントロールプレーン）は、エージェントに許可されているアクションを伝え、生のAPIを渡してデータプレーン上で実装を見つけることを期待します。単純な単一システムのルックアップなら機能します。複雑なマルチシステムのビジネスプロセス（エンタープライズAIが実質的なROIを生み出す場所）では機能しません。

データプレーンで毎回「払い戻し処理」をCRM・決済プロセッサ・レガシーERPにまたがって即興しなければならないガバナンスされたエージェントは、

• トークンが高コスト（モデルが実行プレーンが処理すべきことをデータプレーンでオーケストレーションしている）
• 本番環境で脆弱（上流APIの変更が即興シーケンスを壊す可能性がある）、
• 一貫性がない（異なるエージェントが同じデータプレーンプロセスを異なる方法で処理するかもしれない）
• 再利用できない（次のチームがゼロから再構築する）という状態になります。

エンタープライズスキルは実行プレーンの答えです。エージェントがデータプレーン上で組み立てる代わりに呼び出す、プリビルドでガバナンス済みのビジネスアクションです。払い戻し処理。従業員のオンボード。パスワードリセット。見積書作成。チケットのルーティング。各スキルはオーケストレーションロジック・システムコール・承認ルーティング・エラーハンドリング・監査イベントをカプセル化します。エージェントがスキルを呼び出します。実行プレーンがそれを実行します。AIコントロールプレーンはすでにそれが到達する前に検証しています。

ある大手グローバルエンタープライズテクノロジー企業のAI支援の取引ワークフロー（ガバナンスされたプリビルドの実行プレーン機能を通じて実行）は、1億6,700万ドルのパイプライン創出と2,500万ドルの成約売上への貢献、四半期あたり6,000時間以上の営業担当者の時間回収をもたらしました。モデルが推論を提供しました。実行プレーンが確実なデータプレーンのアクションを提供しました。

エンタープライズスキルはどのようにしてデータプレーン上の生のAPIコールを置き換えるのか？

エンタープライズスキルは、Workato Enterprise MCPを通じてAIエージェントが呼び出すプリビルドでガバナンス済みのビジネスアクションです。生のデータプレーン上で同等のロジックを組み立てる代わりに使用されます。

生のAPIコールはAIエージェントに伝えます。「ここにエンドポイントがあります。パラメータ・認証・エラーハンドリング・リトライロジック・マルチステップシーケンスを自分で解決してください。」エージェントはデータプレーン上で実行を即興します。トークンを消費し、脆弱で、再利用できません。

エンタープライズスキルはモデルに伝えます。「ここに実証済みのビジネスアクションがあります。これらのパラメータで呼び出してください。AIコントロールプレーンがあなたのパーミッションを検証しました。実行プレーンがデータプレーンの実行を担当します。」

エージェントが「払い戻し処理」スキルを呼び出すと、WorkatoのオーケストレーションエンジンがCRMレコードの更新・決済プロセッサの払い戻し・ERPへの書き戻し・必要な場合の承認ルーティング・監査ログエントリを正しい順序で・トランザクション整合性を持って・いずれかのステップが失敗した場合のエラー回復とともに処理します。エージェントの役割は払い戻しが適切であることを判断することです。実行プレーンの役割はデータプレーン上でそれを正しく実行することです。

Workatoのスキルライブラリは10年以上にわたって開発されたエンタープライズオーケストレーションインフラの上に構築されています。各スキル上のAIコントロールプレーンのガバナンスは後から追加されたものではありません。スキルが構築されている基盤そのものです。

「生成」された MCPインフラと「統制された」MCPインフラの違いは何か？

生成されたMCPインフラ：開発者が特定のシステム用のMCPサーバーを生成します。サーバーはツールを公開します。エージェントはそれを通じてデータプレーンにアクセスできます。

統制されたMCPインフラ：ソースシステムによって検証されたユーザーごとのアイデンティティ伝播（AIコントロールプレーン）。ユーザーごとにスコープされたツールレベルのパーミッション（AIコントロールプレーン）。アクションごとの監査証跡（AIコントロールプレーン）。PIIマスキング（AIコントロールプレーン）。マルチステップのデータプレーンワークフロー全体のトランザクション整合性（実行プレーン）。上流APIの変更を通じて維持されるエラーハンドリング（実行プレーン）。組み込みのコンプライアンス認証です。

生成とガバナンスの間のギャップは、セキュリティレビュー・コンプライアンス要件・データプレーンの本番環境での障害がそれを表面化させるまで見えません。

Workatoの競争的フレームはこうです。エージェントを生成してください。AIコントロールプレーンと実行プレーンを再構築しない部分にしてください。

既存のAI投資を置き換えずにアーキテクチャを修正するにはどうすればよいか？

Workato Enterprise MCPは、どのモデルがエージェントを動かしているか、どのフレームワークが構築したかに関わらず、エージェントをガバナンスします。AIコントロールプレーンと実行プレーンはエージェントとエンタープライズシステムの間に位置します。ユーザーとモデルの間ではありません。

Copilotのユーザーは引き続きCopilotを使います。Geminiへの投資はそのまま維持されます。AIコントロールプレーンは、それらすべてのエージェントがSalesforce・ServiceNow・Workdayに同時にデータプレーン境界を越えて行動する際に何を行えるかをガバナンスします。実行プレーンは、どのモデルが意図を生成したかに関わらずデータプレーンの業務を処理します。

フレームはこうです。AI投資を維持してください。問いは、それらすべてが同時にエンタープライズシステムで行動するとき、データプレーン上で何がそれらをガバナンスし実行するかです。そのガバナンスは、それがガバナンスするモデルのいずれかに属することはできません。守るべきモデルのポジションを持たないベンダーが必要です。設計上ニュートラルであることが求められます。

まとめ：エンタープライズAIエージェントが実行で失敗する理由とそれを修正するアーキテクチャ

エンタープライズAIエージェントが実行で失敗するのは、アイデンティティをガバナンスし・パーミッションをスコープし・アクションを監査し・複雑なビジネスプロセスを確実に実行するために必要なAIコントロールプレーンと実行プレーン（データプレーン）のインフラが、ほとんどのエンタープライズAIデプロイに存在しないからです。モデルが問題ではありません。アーキテクチャが問題です。

重要なポイントは次のとおりです。

• 失敗はアーキテクチャ的です。AIコントロールプレーン（アイデンティティ・アクションガバナンス・監査）が欠如しており、実行プレーン（繰り返し可能なビジネスプロセスのためのデータプレーンインフラ）も欠如しています。
• 生成されたMCPサーバーはデータプレーンをガバナンスなしに公開します。AIコントロールプレーンと実行プレーンのギャップは、生成だけでは解決されません。
• アーキテクチャの修正により、新しいAIユースケースの提供が数ヶ月から数時間に、LLMトークン消費が93%削減されました。ガバナンスされた実行プレーンのインフラをデータプレーンに確立することによって。
• Verified User Authentication（特許取得済み、一般提供中）はAIコントロールプレーンのアイデンティティギャップを解消します。
• エンタープライズAIがセキュリティレビューで停止する最も一般的な理由です。エンタープライズスキルは即興のデータプレーン実行を、実行プレーンからのプリビルドでガバナンス済みのビジネスアクションに置き換えます。
• 修正はモデルにとらわれません。1つのニュートラルなAIコントロールプレーンが、どのベンダーがエージェントを構築したかに関わらず、データプレーン全体をガバナンスします。

診断の問いはこれです。エージェントが今日あなたのコアシステム（データプレーン）でアクションを実行するとき、誰として行動したか、そしてソースシステムがそのアイデンティティを検証したことを証明できるか？答えが「サービスアカウントとして」であれば、AIコントロールプレーンをスケールが負債にする前に確立する必要があります。