2026年4月、SAP は AI に携わるすべてのエンタープライズアーキテクトが注意深く読むべきポリシーの更新を、静かに公表しました。SAP の API ポリシー第4版には、SAP が推奨するアーキテクチャを通じて動作する場合を除き、サードパーティの AI エージェントが SAP API にアクセスすることを制限する条項が含まれています。このポリシーは、独立系コンサルタント、インテグレーションパートナー、そして SAP 自身のユーザーコミュニティから大きな反響を呼び、その懸念が現実であることを裏付けました。しかし、このポリシーが持つより広範な意義は、SAP そのものにあるわけではありません。それは、エンタープライズソフトウェアスタック全体でしばらく前から形成されつつあった構造的な動向に関するものであり、SAP はそれを明確にしたに過ぎないのです。

SAP の新しい API ポリシーが実際に定めていること

第2.2.2項の規定では、「API 呼び出しのシーケンスを計画、選択、または実行する（半）自律型または生成 AI システムとの接続または連携」を目的とした SAP API の使用が禁止されています。ただし、SAP が承認したアーキテクチャを経由する場合は除きます。具体的には、SAP 独自の AI アシスタント「Joule」、Business Data Cloud、および今後リリース予定の Agent Gateway が、エージェント型 AI による SAP データへのアクセスが許可された経路となります。Microsoft Copilot、Claude、主要なエージェント型フレームワークといったサードパーティ製 AI ツールは、SAP が経路を認定しない限り、正式に制限されます。未公開またはプライベート API の使用は即時禁止となります。ODP RFC インターフェースは2026年7月からブロックされ、SAP はコンプライアンス違反のアクセスパターンに対してアクセスの制限・一時停止・終了を行う権利を留保しています。

なお、SAP の CEO である Christian Klein 氏は2026年第1四半期の決算説明会で「SAP はオープンプラットフォームを目指している」と述べました。しかし、その発言以降、ポリシー文書の内容は実質的に変更されていません。公表されたポリシーの条項ではなく、ベンダーの説明を根拠にアーキテクチャ上の意思決定を行う企業は、ポリシーの文言が裏付けないリスクを自ら引き受けることになります。

安定性を根拠とする主張とその限界

まず SAP が提示した根拠について真摯に検討してみましょう。AI エージェントは、人間のユーザーとは根本的に異なる負荷プロファイルを生み出します。一連の SAP API 呼び出しを実行する自動エージェントは、処理を一時停止せず、スロットリングも行わず、人間がシステムを操作する際の自然なリズムを持ちません。決算処理、給与計算、サプライチェーン業務を担うミッションクリティカルな ERP インフラにとって、これは根拠のない懸念ではなく、現実の技術的課題です。その意味で、安定性を根拠とする正当化には一定の合理性があります。

ただし、この正当化はポリシーの適用範囲までは説明しきれません。このポリシーは、高トラフィックや管理が不十分なエージェントトラフィックを選択的に制限するものではなく、サードパーティの AI ツールを一律に制限するものです。SAP 自身の製品は同様の制限から除外されています。独立系 SAP コンサルタントやドイツ語圏の SAP ユーザーグループ（DSAG）はいずれも、この制限はインフラ保護の観点から正当化できる範囲を超えており、その実質的な影響はインテグレーションパートナーだけでなく企業自身をも制約するものだと公式に指摘しています。この非対称性は明確に指摘する価値があります。SAP が推奨する AI を利用する企業は、独立系ツールを利用する企業よりも、構造的により優位な連携経路を得られます。これは中立的なインフラ上の判断ではなく、API ポリシーを通じて表明された競争上のポジショニング判断です。

エンタープライズソフトウェアスタックに広がる共通のパターン

SAP のこの動きは異例なほど明示的ですが、その根底にある力学は SAP に固有のものではありません。エンタープライズソフトウェアベンダーは代替不可能なビジネスデータを大量に抱えるようになっており、そのデータを扱う主要なインターフェースとして AI が台頭したことで、どの AI ツールがそのデータを処理できるかを制御しようとする構造的なインセンティブが生まれています。Salesforce はサードパーティ製ツールによる Slack データのインデックス化や AI モデルのトレーニングへの利用を制限し、Agentforce に持続的な優位性をもたらしています。ServiceNow はインバウンドのエージェントトラフィックに API レート制限を課し、ServiceNow 以外のエージェントが大規模に利用することを制約しています。こうした動きは各社で一貫しています。データを管理するベンダーは、AI がそのデータにアクセスできる条件もあわせて形成しており、多くの場合、自社の AI 製品はサードパーティ製ツールには適用されない例外措置の恩恵を受けています。

企業の調達部門もこの状況に気づき始めています。ベンダーに対し、連携ユースケース向けの公開 API アクセスの維持、および自社 AI 製品と比較したサードパーティ製 AI ツールへの不当な制限の禁止を求める契約条項を盛り込む企業が増えています。これは、こうしたリスクに対して目の肥えた調達担当者がどのように考え始めているかを示す先行指標です。すべての企業が自問すべきは、特定のベンダーが表明した意図を信頼できるかどうかではなく、自社の AI アーキテクチャが、契約上の救済手段なしに一方的に変更されうるアクセス条件に依存していないか、という点です。

AI 戦略における「独立したデータレイヤー」の意味

ベンダーが管理する AI アクセスに対してこれに対抗するアーキテクチャとして、実務家たちが「独立したデータレイヤー（Independent Data Layer）」と呼ぶものがあります。これは、企業の基幹システムと AI ツールの間に位置する接続・連携層であり、アプリケーションベンダーではなく企業自身が管理するものです。単一ベンダーのポリシー変更や製品ロードマップの決定とは切り離された形で、どのエージェントがどのような権限のもとでデータにアクセスするかを制御できます。独立したデータレイヤーは、データを新たなサイロに移すものではありません。データの複製を行わず、アクセス条件がベンダー側のポリシー改訂に左右されることもなく、データが存在する場所への管理されたリアルタイムアクセスを提供するものです。

このアーキテクチャが AI 活用の柔軟性を高める理由は明快です。企業が接続レイヤーを自社で所有していれば、ベンダーとの権限再交渉や連携の再構築を行うことなく、AI ツールの変更、新しいエージェントの追加、新たなデータソースの組み込みが可能になります。AI ツールの環境が急速に進化し続ける中、この柔軟性は時間とともに価値を増します。今日、単一ベンダーの AI スタックに依存する組織は、多大な切り替えコストを伴う長期的なアーキテクチャ上のコミットメントを負うことになります。独立したデータレイヤーは、ベンダーをまたいだインテリジェンスを一貫したものにする要素でもあります。多くの企業では、SAP は Salesforce、Workday、ServiceNow などのシステムと並行して稼働しています。各ベンダーが認定した AI 経路に依存するアーキテクチャは、ビジネスの統合されたビューではなく、断片化を生み出します。この構造的な変化についてさらに詳しく知りたい場合は、2026年がエンタープライズ対応 MCP 導入にとって重要な年となる理由についての記事もご参照ください。

現在の SAP 連携アーキテクチャで監査すべき事項

IT およびデータ部門のリーダーが今すぐ確認すべきは、既存の SAP 連携が新しいポリシーに準拠しているか、そして準拠していない場合の是正経路がどのようなものかという点です。現時点で監査すべきリスクカテゴリは3つあります。

• 未公開または非公開の SAP API の使用（SAP Business Accelerator Hub に掲載されていない、または製品固有のドキュメントに記載されていないもの）

• 承認された仲介を経由せずに SAP API を直接呼び出すサードパーティ製 AI ツール

• 2026年6月からブロックが予定されている ODP RFC を利用したパイプライン

監査の推奨手順は次のとおりです。まず、現在 SAP データにアクセスしているすべてのシステムおよびツール（AI ツールや自動化パイプラインを含む）を棚卸しします。次に、それらのアクセスが公開済みの Business Accelerator Hub エンドポイントを経由しているかを確認します。続いて、6月までに移行が必要な ODP RFC への依存関係を特定します。そして、SAP が非準拠のアクセスをさらに制限した場合にどのエージェント型ワークフローが最初に影響を受けるかをマッピングします。ポリシー自体から読み取れる重要なアーキテクチャ上の注意点として、SAP はプロキシ、仲介サービス、またはカスタムコードによる回避を明示的に禁止しています。回避策はコンプライアンスに準拠した代替手段にはなりません。ポリシーはその抜け道を直接ふさいでいます。準拠した経路として認められているのは、公開・文書化されたインターフェースを通じた管理されたアクセスのみです。

契約上の側面：オープンアクセスを要件として明文化する

SAP の API ポリシーは最初の公開から1週間以内に改訂されました。これは、連携アクセスの維持をベンダーの善意に頼ることの実務上のリスクを端的に示しています。現時点でベンダーの API アクセスに関する契約条項を持たない企業は、将来一方的な変更が行われた際に、何ら救済手段を持たない状態に置かれます。技術的なアーキテクチャと契約上の姿勢は、セットで機能させる必要があります。

SAP との契約（新規・更新を問わず）を交渉する調達チームは、API アクセスと AI ツールの相互運用性を明示的な契約要件とすることを検討してください。具体的には、「ベンダーが連携ユースケース向けに公開 API アクセスを維持し、自社 AI 製品と比較してサードパーティ製 AI ツールを不当に制限しない」旨を定める条項を設けることが考えられます。こうした条項は、主要な SaaS プラットフォームにおける高度な企業間交渉においてすでに実例として根付きつつあります。この組み合わせこそが持続的な保護をもたらします。独立したデータレイヤーがベンダーのポリシー変更から技術面での影響を遮断し、契約条項がその約束を履行させるための法的根拠を提供します。どちらか一方だけでは不十分です。

よくある質問

CData で、自社主導で SAP データにアクセス

CData のソリューションは、公開された RFC インターフェースを通じて RFC_READ_TABLE を使用して SAP データにアクセスします。SAP Note 3255746 が対象とする ODP-RFC は使用していないため、SAP が2026年6月からサードパーティ製アプリケーションに適用するブロックの対象外です。レプリケーションベースの SAP 連携（ODP-RFC に依存する Azure Data Factory や Qlik Replicate など）に影響している制限は、CData の SAP 接続には適用されません。Connect AI のお客様はこの禁止措置の影響を受けません。

CData Connect AI は、データレプリケーションやベンダーロックインなしに、単一の AI 非依存エンドポイントを通じて SAP データおよびその他数百のエンタープライズデータソースへのガバナンスの効いたリアルタイムアクセスを提供するマネージド MCP プラットフォームです。Connect AI は SAP データをMCP サーバーとして公開するため、MCP をサポートするあらゆる AI（Claude、Microsoft Copilot Studio、IBM watsonx、Google Gemini、n8n など）が、同じエンドポイントを通じて同じガバナンスの効いた SAP データにアクセスできます。AI ツールごとに連携を再構築する必要はなく、SAP の認定経路リストに縛られることもありません。CData は、SAP S/4HANA、SAP HANA、SAP Business One、SAP SuccessFactors、SAP Concur などをカバーしており、SAP の製品群全体およびエンタープライズスタック全体にわたる単一の接続レイヤーを企業に提供します。現時点で SAP 連携のポリシー準拠を維持できるアーキテクチャは、将来どのような AI が登場しても選択肢を広げ続けられるアーキテクチャでもあります。

※本記事は CData US ブログ SAP API Policy & AI Strategy | CData Connect AI の翻訳です。