エージェントが「どの基幹システムに触れるか」が次の関門になる
homulaは、エンタープライズ企業のAIエージェント導入を、接続先システムのポリシーやガバナンス要件まで含めて設計するAIインテグレーターです。
PoCを越えてエージェントを本番に乗せるとき、現場で最後に効いてくるのは「モデルの賢さ」ではなく、**「そのエージェントは、自社の基幹システムに正当にアクセスできるのか」という一点です。ERP・CRM・ITSMといったシステム・オブ・レコード（SoR）**は、業務データと業務ロジックの本丸です。ここにエージェントが届かなければ、自動化できるのは周辺業務だけにとどまります。
そして2026年春、この「エージェント・アクセス」をめぐって、主要なエンタープライズ・プラットフォーム各社の方針がはっきり二つに割れました。SAPは第三者AIエージェントによるAPI利用を制限する側へ、SalesforceとServiceNowは自社プラットフォームを任意のエージェントに開放する側へ——正反対の舵を切ったのです。本稿は、この分岐を「日本企業がエージェントの接続と統制をどこに置くべきか」という観点から読み解きます。
本稿は各社の公開発表・一次報道に基づきます。「事実（ポリシー文言・日付・各社の発表）」と「分析・自社見解」を区別して記述します。SAPの方針については同社の意図表明も併記し、一方的な評価にならないよう努めます。
SAP——第三者の「自律的なAPI連携」を制限する側へ
SAPは2026年4月、新しいAPIポリシー API Policy v4/2026（v.4.2026a） を公開しました。注目を集めたのは Section 2.2.2 で、SAPのAPIを**「API呼び出しのシーケンスを計画・選択・実行する（半）自律型または生成AIシステムとの相互作用・統合」に用いることを禁じる、という条項です。あわせて、消費してよいのは公開済みAPIに限る**とされ、内部・非公開APIの利用は認められません（The Register: 新APIポリシーがロックイン懸念を招く、Kai Waehner: SAPのAPIポリシーが迫るデータ統合の見直し）。
実務上重いのは運用開始日です。報道によれば、SAPは2026年6月9日から、非準拠のODP（RFC経由）連携を技術的にブロックするセキュリティパッチによって、この方針の運用を始めるとされています。つまり本稿公開時点（6月6日）で、適用は目前です。
SAPの狙いは「すべてのAIを締め出すこと」ではありません。CEOのクリスチャン・クライン氏はQ1投資家向け説明で、自社のドメイン知見の保護と性能劣化の防止が目的であり、顧客が自社データを使うことを妨げる意図はないと説明したと報じられています。ただし、こうした説明やFAQには法的拘束力がなく、Gartnerは「FAQは法的拘束力のある文書ではない」と指摘しています（Kai Waehner）。SAPの設計思想は、エージェント連携を自社の Joule／Business Data Cloud／Agent Gateway 経由に集約させる方向で、外部エージェントの直接アクセスを正面口にはしない、というものです。
一方で、ユーザー団体や調査会社からは反発も出ています。ドイツ語圏のSAPユーザー会 DSAG の会長Jens Hungershausen氏は、ルールそのものより**「不明確さ」を最大の問題として挙げ、SAP-to-非SAPのシナリオは「SAPが明示的に公開・文書化したインターフェースでのみ確実にサポートされる」ことになると述べています（CIO.com: DSAGがSAPの新APIポリシーを批判）。Forresterはさらに踏み込み、「SAPはエンタープライズAIのゲートキーパーになろうとしている——CIOは押し返すべきだ」と題したブログで、仲介役のJouleエージェントをSAPが定義し、プロトコルを統制し、トラフィックを計測する構図を問題視。エンタープライズSaaSの意思決定者の21%**がベンダーロックインを最大級の商業的懸念に挙げる、という調査も引いています（Forrester）。
Salesforce・ServiceNow——「どのエージェントにも開く」側へ
同じ時期、SalesforceとServiceNowは逆方向に動きました。両社に共通するのは、自社プラットフォームを「ヘッドレス」化し、どこのエージェントからでも統制付きで叩けるようにするという設計です。
Salesforceは2026年4月のTDX 2026で Headless 360 を打ち出し、プラットフォームのあらゆる機能を API／MCPツール／CLIコマンドとして外部に公開しました。これにより、Agentforce自身だけでなく、Claude Code・Cursor・OpenAI Codex といった第三者エージェントからもプラットフォームを利用できる、と説明されています。MCPクライアントのネイティブ対応は2026年1月にβへ進み、AgentExchangeには200社超のパートナーによる50超のMCPサーバーがカタログ化されています（Salesforce: Agentforce MCP）。
ServiceNowは2026年5月のKnowledge 2026で Action Fabric を発表し、一般提供（GA）となったMCPサーバーを通じて「フル・システム・オブ・アクション」を任意のAIエージェントに開放しました。ServiceNow製であれ、Claude・Copilot・自社内製エージェントであれ、フロー・プレイブック・承認・カタログといった実行可能な業務に外部から到達できます。重要なのは、そのすべてのアクションが ServiceNow AI Control Tower（AICT）を通る点です。AICTにより各アクションはID検証され、権限スコープが付与され、完全に監査可能になります。MCPサーバー・コンソールには、ガバナンス・消費メータリング・マネージドOAuth・監査証跡・セッション管理・ロールベースのツールパッケージが備わります（ServiceNow: 全システムを任意のエージェントに開放）。
| プラットフォーム | エージェント・アクセスの方針 | 主な手段 | 統制の置き方 |
|---|---|---|---|
| SAP | 第三者の（半）自律・生成AIによるAPI連携を制限 | Joule／Business Data Cloud／Agent Gateway 経由に集約 | 自社仲介層に一本化（公開API限定） |
| Salesforce | 任意のエージェントに開放 | Headless 360（API／MCP／CLI）、AgentExchange | プラットフォーム機能として権限管理 |
| ServiceNow | 任意のエージェントに開放 | Action Fabric＋GA版MCPサーバー | AI Control Tower でID検証・権限スコープ・監査 |
ここで読み違えてはいけないのは、「開く＝統制がない」「閉じる＝安全」ではない、という点です。ServiceNowは開きながら、すべてのアクションをAI Control Towerで監査可能にしています。逆にSAPの閉じる設計は、ロックインや不透明さという別種のリスクを指摘されています。論点は「開くか閉じるか」そのものより、**「アクセスをどう統制し、後から監査できるか」**にあります。
なぜ各社の判断が割れたのか——「データと業務ロジックの所有権」をめぐる攻防
方針が割れた背景には、それぞれの事業構造があります。SAPにとってERPは20年分の業務ロジックと基幹データの集積であり、ここを外部エージェントに自由に叩かれると、ドメイン知見が薄まり、自社のAI（Joule）の価値が相対化されるという懸念があります。SAP自身が説明する「ドメイン知見の保護」は、技術的にもビジネス的にも一定の合理性を持ちます。
一方、SalesforceとServiceNowは、「業務の実行層（system of action）」を握り続けられるなら、入口のエージェントは誰のものでもよいという賭けに出ています。エージェントが乱立するほど、それらが最終的に「叩く先」としての自社プラットフォームの中心性は増す——という読みです。ServiceNowがAI Control Towerを**「他社製エージェントも含めて統治する層」**として前面に出すのは、この戦略を象徴しています。
つまりこれは、生成AI時代における**「データと業務ロジックの所有権・ゲートウェイ権」をめぐる主導権争いです。そしてこの争いの帰結を、現場の日本企業がそのまま被る**構図になっています。
日本企業の現実——基幹は「一社」では完結しない
ここで直視すべきは、多くの日本企業のシステム構成が複数ベンダーの混在だという事実です。基幹はSAP、営業はSalesforce、社内ITはServiceNow、加えて国産の業務システムや部門SaaSが並走する——という構成は珍しくありません。
すると、エージェント戦略を特定ベンダーの「開く／閉じる」判断に丸ごと預けるのは危険だと分かります。SAPの方針一つで、せっかく組んだ自動化が6月9日以降に動かなくなる、というような事態は、単一ベンダー前提で設計したときに起こります。価値の高い業務ほど、SAPの受発注データ、Salesforceの商談、ServiceNowのチケットを横断します。だからこそ必要なのは、各プラットフォームの正規の作法（SAPなら公開APIとJoule／Agent Gateway、Salesforce/ServiceNowならMCP）を尊重しつつ、それらを束ねる**ベンダー中立の接続・統制の「面」**を、自社側に持っておくことです。
実務的な含意は明確です。(1) いま動かしているエージェント連携が、各プラットフォームの最新ポリシーに準拠しているかを棚卸しする（特にSAP連携は6月9日が一つの節目）。(2) 接続を各ベンダーの作法に合わせつつ、エージェント側は特定ベンダーにロックインしない。(3) 「どのエージェントが・どのシステムに・誰の権限で触れ・何をしたか」を、プラットフォームをまたいで一元監査できる状態にしておく。
homulaの観点——接続は各社の作法に合わせ、統制は横断で効かせる
今回の分岐が日本企業に突きつけるのは、「SAPかSalesforceか」という二者択一ではありません。**「複数の基幹システムに、各社のルールを守りながら、エージェントをどう正しく接続し、横断的に統制するか」**という設計課題です。これはSAPのn8n戦略投資やMCPの2026年のエンタープライズ進化の流れとも一直線につながります。
homulaはここを、特定ベンダーに寄り切らないインテグレーターとして設計します。AgensはMCPを活用し、200以上のツールと構築ゼロで接続する共通基盤を提供します。これは、SalesforceやServiceNowが開放したMCPの入口に正しく接ぎ、SAPのように制限のある相手には公開APIや正規ゲートウェイ経由で接ぐ——という**「各社の作法に合わせた接続」をベンダー中立に束ねる面**にあたります。
そのうえでAgens Controlが、承認フロー・DLP・RBAC・5年分の監査ログを、プラットフォームをまたいで一元的に効かせます。ServiceNowがAI Control Towerで自社内に実現する「ID検証・権限スコープ・監査」を、複数の基幹システム・複数のモデルにまたがって自社側に持つ、という役割です。活用技術としては n8n / Dify / LangGraph を業務特性に応じて使い分けます。
どの基幹システムに、どのエージェントを、どの承認点・監査要件で当てるか——その具体的な見極めは、業務棚卸しからプロトタイプ構築・ROI試算までを3〜5日（最短5日でPoC）で行うAIエージェント・ブートキャンプで素早く固められます。
まとめ
2026年春、基幹システムへの「エージェント・アクセス」をめぐって各社の方針は二極化しました。SAPはAPI Policy v4/2026のSection 2.2.2で第三者の（半）自律・生成AIによるAPI連携を制限し、6月9日から運用を始めます。対するSalesforceはHeadless 360、ServiceNowはAction Fabric＋GA版MCPサーバーで、自社プラットフォームを任意のエージェントに開放しました。狙いの根底にあるのは、生成AI時代の**「データと業務ロジックの所有権・ゲートウェイ権」**です。
日本企業が問うべきは「どのベンダーが正しいか」ではありません。**「複数ベンダー混在の現実の中で、各社の作法を守りつつ、エージェントの接続と監査を自社側で横断的に握れているか」です。ベンダー各社の方針は今後も揺れ動きます。だからこそ、特定ベンダーの開閉に左右されない接続と統制の「面」**を先に設計できた企業から、基幹業務の本丸でエージェントが安全に回り始めます。
基幹システム連携のエージェントを本番に乗せるなら、「各プラットフォームのポリシーに準拠しているか」「接続と監査を横断的に握れているか」を先に点検するのが近道です。自社のベンダー構成とコンプライアンス要件に合った接続・統制の置き方を、早めに整理することをおすすめします。