2026年4月にSAPがAPIポリシーを更新したことで、企業がまず押さえるべき点は、サードパーティーツールが一律にSAPへ接続できなくなったという話ではありません。より重要なのは、SAPが中核ERPのデータと業務プロセスに触れるAPI利用を、公開済みAPI、製品文書、SAPが認めたアーキテクチャー、データサービス、またはサービス別の指定経路の中へ収めようとしていることです。^[1][7][10]

AIエージェントをSAPに接続しようとしている企業にとって、この変更はPoC、データ基盤、RPA、iPaaS、ETL、自社開発の自動化フローの設計に直接関わります。^[1][13]

何が変わったのか

新ポリシーは、API利用の境界線をより明文化しました。CIOが引用したSAPの説明によると、SAP Business Accelerator Hubまたは該当製品のドキュメントに記載されたインターフェースだけが、公開APIと見なされます。^[7] The Registerも、新ポリシーではAPI利用を

SAP-endorsed architectures, data services, or service-specific pathways

[2]

[10]

これは、企業が「呼び出せるインターフェースなら長期利用してよい」とは考えにくくなるということです。ポリシー文書に示されたAPI管理項目には、機能面・技術面の利用制限やクォータ、廃止予定、データの入出力量のクォータ、大量抽出やレプリケーションの制限・前提条件、その他のセキュリティ要件や技術要件が含まれます。^[9] SAPinsiderも、未文書化APIは広く使われているものの、更新後はサポート境界の外に置かれ、長期的な統合や運用リスクが高まると指摘しています。^[1]

つまり、これは単なるAI条項ではありません。どのAPIが公開済みなのか、どの使い方がサポート対象なのか、どのデータ抽出や複製に前提条件があるのか、どの自動化はSAP認定経路を通す必要があるのかという、ERP統合ガバナンス全体の問題です。^[7][9][13]

なぜAIエージェントが特に問題になるのか

最も注目されているのはAI関連の条項です。複数の報道は、SAPがSAP認定アーキテクチャー、データサービス、または明示された経路を除き、APIを半自律型または生成AIシステムとの相互作用・統合に使うことを禁じていると伝えています。対象になるのは、APIコールの列を計画、選択、実行するシステムです。^[5][10]

ここが従来型のシステム連携と、エージェント型AIの違いです。従来の連携は、あらかじめ決めた手順に従い、特定のAPIを呼び出して単一の処理を完了する設計が中心でした。一方、AIエージェントは目標に応じて次の手を選ぶことがあります。たとえば、まず仕入先を照会し、次に在庫を確認し、調達案を生成し、承認申請や記録更新へ進む、といった動きです。

このように、エージェントが自ら複数のSAP APIコールを選び、つなぎ合わせる場合、ポリシーが想定する多段API編成の範囲に入る可能性があります。実際に適合するかどうかは、使うAPI、アーキテクチャー、データサービス、SAPの認定方法によって変わります。^[5][10]

同じ制限は、スクレイピング、ハーベスティング、体系的または大規模なデータ抽出・複製にも及びます。^[5][10] したがって、影響を受けるのはSAPへ書き込むAIエージェントだけではありません。外部AI基盤、lakehouse、オーケストレーション層を支えるためにSAPデータを大量に読み出す設計も、再点検が必要です。^[9][13]

顧客のイノベーション：PoCは止まらないが、軽く始めにくくなる

イノベーション部門、SIer、ISVにとって大きな変化は、実験の前にガバナンスの確認が増えることです。以前なら、第三者AIエージェントをERPに接続し、自動照合、購買支援、在庫分析、顧客対応の自動化などを素早く試せたケースでも、新ポリシー下では確認事項が増えます。

具体的には、対象APIがSAP Business Accelerator Hubまたは製品文書に載っているか、アーキテクチャーがSAP認定経路に該当するか、利用量がクォータや大量抽出制限に触れないか、そしてエージェントが自律的に多段APIコールを組み立てるかを確認する必要があります。^[5][7][9]

これはAI PoCができなくなるという意味ではありません。ただし、PoCはより正式な統合プロジェクトに近づきます。API棚卸し、権限設計、利用量見積もり、データフロー審査、コンプライアンス確認が初期段階から必要になります。ERP Todayは、このポリシーが技術的な統合問題を、より広いERPアーキテクチャー上の問題へ押し上げたと説明しています。既存連携が正式に文書化されていないインターフェースに依存している可能性がある一方、新しいAIアプリケーションは企業データや取引ワークフローへの制御されたアクセスを必要とするためです。^[13]

不確実性そのものも、実験の速度を落とします。The Registerによると、ドイツ語圏のSAPユーザー会DSAGはこのポリシーが不確実性を生むと批判しました。同じ報道では、SAPが認めたインターフェース一覧が十分に管理され、最新化されているのかを疑問視する批判も紹介されています。^[2]

データ制御：論点は「誰のデータか」だけではない

この論争の焦点は、顧客データの所有権だけではありません。顧客が自分で選んだAIプラットフォーム、データ基盤、自動化ツールから、SAPのデータや取引プロセスへ直接、リアルタイム、継続的にアクセスできるのかが問われています。The Registerは、第三者AIツールが顧客のSAPデータから締め出される可能性としてこの問題を報じ、ERP TodayはERP統合、データ複製、AIアクセスのアーキテクチャー問題として扱っています。^[10][13]

企業がSAPデータを外部のlakehouse、AIプラットフォーム、エージェント・オーケストレーション層、第三者自動化システムへ同期したい場合は、データ入出力クォータ、大量抽出やレプリケーションの前提条件、公開APIの範囲、SAP認定経路の要否を特に確認すべきです。^[7][9][10]

こうした制限は、性能、セキュリティ、監査、ガバナンスを集中管理しやすくする面があります。一方で、SAPの取引データを大量に読み書きするAIユースケースでは、クロスプラットフォームなAIアーキテクチャーの自由度が下がる可能性があります。^[9][13]

ベンダーロックイン：リスクは上がるが、結末はまだ決まっていない

ロックイン懸念は、実務上の制約から生まれます。サードパーティーAIエージェントがSAP APIと自由にやり取りできないなら、顧客はSAP認定アーキテクチャー、公式データサービス、またはSAPが明示的に許す統合方式へより依存することになります。The Registerは、このAI条項がロックイン懸念を引き起こしていると報じています。理由は、一部の第三者AIツールが顧客のSAPデータへアクセスしにくくなる可能性があるためです。^[10]

DSAGの反応からも、顧客コミュニティの懸念が単なる技術論にとどまらないことが分かります。E3 Magazineによると、DSAGは未文書化用途、体系的な大量データ抽出、第三者の自律型生成AIシステムとの相互作用をSAPが厳しく制限することを受け入れがたいとしています。^[11]

ただし、ロックインは唯一の帰結ではありません。実際の影響は、SAPが認定経路をどれだけ明確に定義するか、公開API一覧を完全かつタイムリーに更新するか、監査可能な例外・承認プロセスを用意するか、そして第三者ベンダーが明確なルールの下で引き続き革新できるかに左右されます。批判者はすでに、認定リストの管理や更新速度に疑問を示しており、ここは企業の調達・アーキテクチャー判断で必ず確認すべき点です。^[2][7]

企業がいま確認すべき5つのこと

1. SAP連携を棚卸しする。 各インターフェースを、公開API、製品文書内API、未文書化インターフェース、大量抽出、リアルタイム読み書き、RPA、iPaaS、外部ワークフローまたはAIエージェント呼び出しに分類します。^[1][7][13]

2. AIユースケースを重点的に見る。 モデルやエージェントが複数のSAP APIコールを自ら計画、選択、実行するプロセスは、先にポリシーリスクを評価すべきです。^[5][10]

3. データ抽出と複製を再点検する。 大規模な抽出、レプリケーション、スクレイピング、ハーベスティングは制限対象に含まれます。既存のデータレイク、lakehouse、BI、AI学習、同期基盤について、クォータ、前提条件、許可された経路を確認します。^[5][9][10]

4. SAPまたは導入パートナーから書面確認を取る。 エージェント型AI、自動取引更新、クロスシステム・オーケストレーション、大量データエクスポートなどの高リスク領域では、口頭説明だけに頼るべきではありません。DSAGが不確実性を批判していることは、境界を文書で明確にする重要性を示しています。^[2]

5. アーキテクチャー上の選択肢を残す。 最終的にSAP認定経路を採る場合でも、AIオーケストレーション、データガバナンス、権限、監査ログ、業務ルールはできるだけ交換可能なモジュールとして設計し、革新のロジック全体が単一路線に固定されないようにします。

結論

SAPの2026年API新ポリシーが意味するのは、AIがSAPを使えなくなるという単純な話ではありません。サードパーティーAIエージェントがSAP APIを自由に編成できる、という前提を置きにくくなったということです。安全性、性能、監査、ガバナンスのハードルは上がる一方で、コンプライアンスコスト、実験の遅さ、ベンダーロックインへの懸念も強まります。^[10][13]

短期的に現実的な対応は、既存連携を棚卸しし、AIエージェントのリスクを見極め、SAP認定経路を確認しつつ、新しい構成の中でもクロスプラットフォームの選択肢を意図的に残すことです。