昨日まで問題なく動いていたシステム連携が、ある日突然止まる——。そんな事態が、いま多くのSAP利用企業に現実味を帯びている。SAPは、自社データへのアクセス方法に関するルールを、数年をかけて段階的に見直してきた。発端は2022年、SAPはODP-RFC（Operational Data Provisioning－Remote Function Call）という特定のデータ連携の仕組みについて「サポート対象外」と初めて示した[1]。2024年には、この表現がより強い「許可しない」に変わり、事実上の利用禁止になったといわれている[1]。そして2026年6月、とうとうODP-RFCを含む非公開APIの利用を技術的に制限する仕組みの適用が始まった[2]。注意喚起から実質禁止、そして技術的な遮断へ——約4年をかけて、規制は段階的に強められてきたことになる。
現時点で規制の対象となる非公開APIを利用している企業は少なくない。SAPのデータを外部システムと連携している企業、あるいはAIエージェントにSAPのデータを扱わせることを想定していた企業は、今回の変更の影響を受ける可能性が高く、注意が必要だ。本稿では、何が変わったのかを整理した上で、企業が取り得る具体的な対応の選択肢を紹介する。
1. SAP APIポリシー厳格化で何が変わるのか
2026年4月、SAPはAPIの利用条件を定めた「API Policy」の改訂版（v4/2026）を公開した[3]。今回の変更の柱は大きく2つある。1つ目は、これまで黙認されがちだった非公開APIの利用を実質的に禁止したこと。2つ目は、AIエージェントによるAPIの自動呼び出しを原則禁止したことだ。それぞれ見ていこう。
規制①：非公開APIの利用禁止
APIには、外部に公開され自由に使ってよい「公開API」（Published API）と、SAPが社内向けに用意した「非公開API」がある。今回のポリシーでは、公開API以外へのアクセスや呼び出しが原則禁止された[3]。対象となる代表例が、ODP-RFCと呼ばれる、SAPのデータ抽出の仕組みだ。もともと社内向けの機能だったが、サードパーティ製のツールが大規模なデータ連携を行うために事実上広く利用されていた経緯がある。あわせて、SAPが認めた方法以外でのスクレイピング（WEB上の情報を自動的に取得する技術）や大規模なデータ抽出も禁止された[3]。なお、禁止の対象はあくまでODP（Operational Data Provisioning）経由のRFC（Remote Function Call）利用であり、RFCというプロトコル全般ではない。BAPI（Business Application Programming Interface）やファンクションモジュールなど、他のRFCベースの連携は引き続き利用できる。また、プライベートクラウドやオンプレミス環境で顧客が独自に開発したABAP （Advanced Business Application Programming）インターフェース（カスタムAPI）の利用は、例外として認められている[2]。
規制②：AIエージェントからのAPI呼び出し制限
もう1つの柱が、AIエージェントに対する制限だ。APIの呼び出し順序を自ら計画し実行まで担う自律型／生成AIシステムとの連携は、SAPが認めた方法を除いて禁止された[3]。外部のAIエージェントがSAPのAPIを直接呼び出して業務を自動化する際は、SAPが認めた経路／条件を満たしているか確認する必要がある。
なお、この方針転換には批判もある。独語圏SAPユーザーグループ（DSAG）は、非公開APIの範囲や契約上の位置付けが十分に明確でないことから、透明性や顧客側の計画可能性に懸念を示している[4]。これに対しSAPのCEOクリスチャン・クライン氏は、“SAPは、顧客データの所有権やアクセス権を否定するものではない”と説明しており、ポリシーの目的をシステム安定性やセキュリティ、サポート可能なアーキテクチャーの維持にあるとしている[5]。
2. 規制①：非公開APIの利用禁止への対応策
自社が非公開APIやODP-RFCを利用していなければ、この規制への追加対応は基本的に不要となる。利用有無の確認には、SAPがSAP Note 3439624で提供するセルフアセスメントツールが利用できる[6]。利用している場合は、その利用目的に応じて次の3つの対策のいずれかを検討することになる。
対策案A：公開APIの直接利用
1つ目は、SAPが公式に用意しているOData（Open Data Protocol）APIなどの公開APIを直接使う方法だ。業務システムからリアルタイムで1件ずつ照会／更新する用途であれば、業務アプリケーションから公開APIを呼び出す形が向いている。中量程度のデータを分析基盤に取り込みたい場合も、クラウドのETL（Extract Transform Load、データを抽出・変換して格納する処理）サービス経由で公開APIに接続すれば対応できる。SAPが認めた経路以外での大規模かつ恒常的なデータ抽出はポリシーで禁止されているため[3]、大量データの抽出には向かない。AIエージェントがこの公開APIを直接呼び出す場合は、規制②の制約も別途及ぶ点は覚えておきたい。
対策案B：SAP BDC Connectによるゼロコピー連携
2つ目は、SAP Business Data Cloud（以下「BDC」）が提供する「ゼロコピー」連携だ。Delta Sharingという仕組みにより、データを複製せずに外部から参照できる[7]。SAP側の更新がほぼそのまま反映され、双方向の共有にも対応している。ただし、BDCはCapacity Unit（CU）と呼ばれる単位に基づく従量課金のサブスクリプションで提供されており、データ転送量や処理リクエスト数などに応じて費用がかかる[7]。具体的な料金はSAPや連携システムとの契約次第で変わるため、自社の利用規模に応じて見積もりを取ることを推奨する。
対策案C：Datasphere Replication Flowによるレプリケーション
3つ目は、SAP Datasphereの「Replication Flow」機能を使い、データを外部のストレージへ複製する方法だ。主要なクラウドストレージサービスへの複製が公式にサポートされている[8]。複製の方法は、「初回のみ」「初回と差分の両方」「差分のみ」の3種類から選べる。こちらも複製するデータ量に応じた追加のライセンス費用がかかる。
各プラットフォームの機能提供状況
対策BとCがいつから実施可能かは、連携先のクラウド基盤によって差がある。SAP公式のロードマップ情報（2026年7月1日時点）によると、対策C（Replication Flow）はDatabricks、AWS（Amazon Web Services）、Microsoft Azure、Google Cloud（BigQuery）、Snowflakeのいずれでもおおむね利用可能になっている[9]。一方、対策B（ゼロコピー連携）は基盤ごとに提供状況にばらつきがある。DatabricksとSnowflakeはすでに対応済みだが、AWS、Microsoft Azure、Google Cloudは執筆時点でまだ計画段階にとどまる。自社が使うクラウド基盤の対応状況は、各社の公式情報で確認することを推奨する。
ここまでの内容を整理すると、次のようになる。
3. 規制②：AIエージェントからのAPI呼び出し制限への対応策
規制②への対応でまず検討したいのは、そもそもAIエージェントにSAPのAPIを直接呼び出させる必要があるかどうかだ。分析や参照が目的で書き込みまでは不要という場合は、規制①で紹介した対策BかCによるデータ基盤の構築により対策が可能だ。SAPのAPIを直接叩かせないため、今回のポリシー変更の影響を受けにくい。
書き込みや業務の自動化までAIに担わせたい場合は、AIをどこで動かすかによって選択肢が変わる。
対策案D：Jouleのみを採用
SAP純正のAIアシスタントであるJoule（ジュール）を使う方法だ。専門領域ごとのエージェントがあらかじめ用意されており、SAPデータの意味づけも組み込まれているため、すぐに使い始めやすい。一方で、SAPへの依存度は高くなるというデメリットがある。
対策案E：サードパーティAI＋MCP Gateway
Jouleを使わず、外部のAIエージェントだけで進める場合の選択肢の1つが、MCP（Model Context Protocol、AIがツールやAPIを呼び出す際の共通規格）を扱うSAP提供の「MCP Gateway」からSAPデータを呼び出す方法だ。SAP Integration Suiteという基盤の上でSAPがMCP準拠のツールとして提供しており、認証、レート制限、監視などの統制機能をSAP提供基盤上で担保する。[10]。これにより、外部AIエージェントによるSAP API利用の制御／監視が可能になる。
対策案F：Agent Gateway経由のA2A連携
Jouleと外部のAIを併用したい場合は、A2A（Agent to Agent、AIエージェント同士が連携する仕組み）を使い、Agent Gateway経由で外部AIをJouleに接続する方法がある。複数のAIエージェントを連携させられるのが利点だが、2026年7月時点でAgent Gatewayは正式提供前とされ、通信も一方向にとどまると発表されている[11]。
対策案G：外部提供または自社構築のMCPサーバーの利用
MCP Gatewayを経由せず、ベンダーなどが外部で提供、運用するMCPサーバーを利用する、あるいは自社で構築、運用するMCPサーバーからSAPのAPIにアクセスする方法も選択肢の1つだ。SAPも一定の条件を満たせば正規の方法として認めているが[10]、書き込み処理などで意図しない誤操作が起きるリスクが指摘されており、いずれの形態でも運用や安全性に関する責任はすべて利用者側が負うことになる。SAPが管理する仕組みに比べると、負担は重くなる。
ここまでの内容を整理すると、次のようになる。
4. おわりに
2つの規制はいずれも、非公開APIや自律型AIへの依存度が高い企業ほど影響が大きい。まずは自社のSAP連携を棚卸しし、ODP-RFCなど非公開APIを使っているか、AIエージェントにSAPデータの書き込みまで担わせているかを確認するところから始めたい。棚卸しには、前述のセルフアセスメントツールが活用できる[6]。技術的な遮断はすでに一部で始まっており、猶予はそれほど長くない。
また、これは制約にとどまらない好機でもある。たとえば対策案Eで触れたMCP Gatewayを活用して他システムのAPIも同じ入口に束ねれば、AIエージェントが複数システムを横断して需要予測や顧客対応を担う基盤にもなり得る。棚卸しを起点に、規制対応と将来のAI活用を一体で描く移行計画を早期に固めたい。本稿がその一助となれば幸いである。
【出典】
[1] Simply Data Now（2026）, “SAP Note 3255746”, https://www.simplydatanow.com/sap-note-3255746.html（参照2026年7月4日）
[2] SAP SE（2026）, “3255746 – Unpermitted usage of ODP Data Replication APIs, Version 12”, https://me.sap.com/notes/3255746（参照2026年7月4日。閲覧にはSAPアカウントが必要。）
[3] SAP SE（2026）, “SAP API Policy v.4.2026a”, https://help.sap.com/doc/sap-api-policy/latest/en-US/API_Policy_latest.pdf（参照2026年7月4日）
[4] CIO（2026）, Manfred Bremmer, “SAP’s new API policy restricts AI access, draws customer criticism”, https://www.cio.com/article/4166172/dsag-criticizes-saps-new-api-policy.html（参照2026年7月4日）
[5] ERP Today（2026）, Adam Pitman, “SAP API Policy Raises New Questions About ERP Integration and AI Access”, https://erp.today/sap-api-policy-erp-integration-ai-access/（参照2026年7月4日）
[6] SAP SE（2026）, “3439624 – Assessment of ODP Data Replication API Usage”, https://me.sap.com/notes/3439624（参照2026年7月4日。閲覧にはSAPアカウントが必要）
[7] SAP Community（SAP公式, 2026）, jeet_kapase, “SAP Business Data Cloud FAQs”, https://community.sap.com/t5/technology-blog-posts-by-sap/sap-business-data-cloud-faqs/ba-p/14022781（参照2026年7月4日）
[8] SAP Community（SAP公式, 2025）, tobias_koebler, “Replication Flow Blog Series Part 1 – Overview”, https://community.sap.com/t5/technology-blog-posts-by-sap/replication-flow-blog-series-part-1-overview/ba-p/13581472（参照2026年7月4日）
[9] SAP SE（2026）, “SAP Road Map Explorer”, https://roadmaps.sap.com（参照2026年7月1日。閲覧にはSAPアカウントが必要。）
[10] SAP Architecture Center（SAP公式, 2026）, “Third-Party MCP Access to SAP Solutions”, https://architecture.learning.sap.com/docs/ref-arch/ca1d2a3e/10（参照2026年7月4日）
[11] SAP Architecture Center（SAP公式, 2026）, “A2A and MCP for Interoperability”, https://architecture.learning.sap.com/docs/ref-arch/76ec36（参照2026年7月4日）
[12] SAP Community（SAP公式, 2026）, FernandaFroelich, “How to use SAP Business Data Cloud Capacity Unit Estimator for SAP BDC Connect for Databricks”, https://community.sap.com/t5/technology-blog-posts-by-sap/how-to-use-sap-business-data-cloud-capacity-unit-estimator-for-sap-bdc/ba-p/14353832（参照2026年7月4日）
[13] SAP SE（2026）, “Premium Outbound Integration”, https://help.sap.com/docs/sap_datasphere/c8a54ee704e94e15926551293243fd1d/4e9c6acb5d6a43fa9a6471837399e71c.html（参照2026年7月4日）
[14] SAP SE（2026）, “SAP Innovation Guide H2 2025”, https://www.sap.com/topics/innovation-guide/h2（参照2026年7月4日）
＊本稿記載の時期および数値情報（提供時期、費用など）は2026年7月時点のものです。最新情報は各社公式サイトでご確認ください
＊SAP、SAPロゴ、記載されているすべてのSAP製品およびサービス名はドイツにあるSAP SEやその他世界各国における登録商標または商標です。
＊本文中のその他の商品名、会社名、団体名は、各社の商標または登録商標です。
