2026年4月にSAPがAPI Policyを更新したことで、第三者AIエージェントがSAP APIを直接操作できるかどうかは、単なる接続可否の話ではなくなった。今後は、企業アーキテクチャ、契約上の権利、データガバナンスまで含めて判断する問題になる。^[5][6][10]

SAPのAPI Policy自体は、APIの利用可能範囲や制限を説明し、ソリューションの健全性とセキュリティを守り、公平なアクセスを促し、APIの不正・過剰利用を防ぐための管理策を定めるものだとしている。^[9] ただし今回、特に注目されているのはAIエージェントに関する条項だ。

外部分析や報道によれば、API Policy v4/2026の第2.2.2節は、API呼び出しの一連の流れを自ら計画、選択、実行する半自律型または生成AIシステムを対象にしている。SAPが認めるアーキテクチャ、データサービス、またはサービス別に指定された経路を通さない限り、こうしたAPI連携や統合は禁じられると解釈されている。^[6][8][10]

まず押さえるべき線引き：AIが助言するだけか、SAPを操作するのか

この新政策は、企業によるAI利用を全面的に禁じるものではない。より正確には、AIエージェントがSAP APIを自由に組み合わせて業務操作を行う設計、特にAIが次に呼ぶAPIを自分で決め、複数のSAP APIを横断し、結果を基幹システムへ書き戻すような設計を強く制限するものだ。^[6][8][10]

たとえば、すでに許可された形で抽出済みのデータを使い、AIが要約、予測、提案を行い、最終判断と実行は人がSAP画面上で行う。こうした使い方は、最も敏感な「エージェント型AI」の領域には入りにくい。

一方で、AIが在庫を自動照会し、受注を変更し、購買発注を作成し、承認フローを進め、マスターデータを更新するような場合は、リスクが一気に高まる。複数APIの連続実行、書き戻し、業務状態の変更を伴うため、新政策が問題にしている多段階API編成に近づくからだ。^[6][8][10]

新政策が実務上つくる4つの境界線

1. 第三者AIエージェントは「SAPが認める経路」が前提になる

The Registerは、新条項について、SAPが認めるアーキテクチャの外で外部AIシステムとAPI統合することをSAPが禁じていると報じた。これにより、第三者AIツールが顧客のSAPデータから締め出されるのではないかという懸念が出ている。^[10]

Fivetranも、今回のポリシーが、API呼び出しの順序を自ら計画、選択、実行する半自律型または生成AIシステムを明示的に対象にしていると指摘している。^[8]

つまり、技術的にAPIへ接続できることと、ポリシー上その接続が認められることは別問題になった。第三者AIエージェントにSAPを操作させる場合、焦点は「その設計がSAP-endorsed architecture、data service、service-specific pathwayのいずれかに該当するか」になる。^[10]

2. 公開・文書化されたAPIの利用が基本条件になる

SAPInsiderは、今回の更新により、システムアクセスが公開・文書化されたAPIへ絞られる方向になったと指摘している。文書化されていないAPIはサポート境界の外に置かれ、長期的な統合運用リスクが高まるという見方だ。^[5]

SAP API Policyでも、Published APIsはSAP Business Accelerator Hub、いわゆるAPI Hubで公開されているAPI、または製品別ドキュメントで特定されているAPIだと説明されている。^[9]

長年のカスタム連携、古いコネクター、正式ドキュメントに載っていない内部的なAPI利用に依存している企業は、現行の接続方式を棚卸しする必要がある。今は動いていても、今後のサポート、監査、アップグレード対応で不確実性が増すためだ。^[5][9]

3. 大規模な抽出・複製も制限対象になる

新条項は、AIエージェントによるAPI編成だけを見ているわけではない。FivetranとThe Registerは、scraping、harvesting、システム的または大規模なデータ抽出・複製も対象に含まれると指摘している。SAPが管理または承認したアーキテクチャや経路を通さない場合、こうした処理は制限される可能性がある。^[8][10]

そのため、SAPデータを外部のデータレイク、データウェアハウス、または非SAP系AIプラットフォームへ大量にコピーする計画では、単に処理性能やコストを見れば足りるわけではない。API Policy、契約上の利用権限、API制限、監査要件、承認された経路の有無まで確認する必要がある。^[8][9][10]

4. SAP公式エコシステムは選びやすいルートになる

SAPの公式ドキュメントでは、SAP BTP上でAIエージェントを構築し、SAPの中心的AIコパイロットであるJouleや、SAP BTPのAIインフラと統合できると説明されている。SAP Cloud SDK for AIは、LangChainなどのアダプターを通じて一般的なエージェントフレームワークとも連携できる。^[1]

またSAPは、SAP Knowledge Graphを、JouleやAIエージェントを含む他のAIが、SAPアプリケーション内の業務文脈を踏まえて、より正確で関連性の高い回答を行うための仕組みとして位置づけている。^[4]

これは第三者ソリューションがすべて使えないという意味ではない。ただし、ポリシー上の境界が狭まるほど、企業のアーキテクト、法務、リスク管理部門にとっては、SAP公式またはSAPが認めた経路のほうが通しやすくなる。^[1][4][10]

どのAIプロジェクトが影響を受けやすいか

利用シナリオ	影響度	理由
許可された形で抽出したデータを使うBI、レポート、オフライン分析	低〜中	AIがSAP APIを直接編成しないなら、エージェント型AI条項には触れにくい。ただし、大規模な抽出や複製は別途確認が必要。[8][10]
チャットボットが助言だけを行い、人がSAPで実行する	低	政策の中心は、API呼び出しの順序を計画・選択・実行するAIシステム。助言型のワークフローと直接操作型エージェントは分けて考えるべきだ。[6][8]
AIが在庫照会、受注変更、購買発注、承認、マスターデータ更新を自動実行する	高	複数APIの連続呼び出し、書き戻し、業務状態の変更を伴いやすく、政策が最も警戒するエージェント型AIに近い。[6][8][10]
SAPデータを外部AI基盤へ大量コピーする	高	政策はscraping、harvesting、システム的または大規模なデータ抽出・複製も対象にしている。[8][10]
文書化されていないAPIに依存する旧式コネクターやカスタム連携	中〜高	文書化されていないAPIはサポート境界の外に置かれるとの指摘があり、SAP Policy上のPublished APIsもAPI Hubまたは製品文書で特定されたAPIとされている。[5][9]

PoCの前に、アーキテクチャ審査が必要になる

プラットフォーム運営の観点では、SAPが外部エージェントによる基幹ERP APIへの無制限な大量アクセスを抑えたいと考える理由は理解できる。特に書き込み、トランザクション処理、システム性能に関わる領域では、制御がなければ影響範囲が大きい。SAP API Policyも、管理策の目的としてソリューションの健全性、セキュリティ、公平なアクセス、API悪用の防止を挙げている。^[9]

ただし開発チームから見ると、AIの概念実証、いわゆるPoCの前提コストは上がる。以前なら、API権限を取り、コネクターを作り、動作確認するだけで実験を進められたかもしれない。しかしAIが次の操作を自律的に判断し、複数APIをまたいでタスクを実行するなら、SAPが認めるアーキテクチャ、データサービス、または指定経路に収まるかを先に確認しなければならない。^[8][10]

これはイノベーションの停止を意味しない。むしろ、イノベーションに前倒しのガバナンスが必要になったということだ。自社開発エージェント、パートナー製品、第三者AIプラットフォームのいずれであっても、SAP APIへ技術的に接続できるだけでは不十分で、契約、アーキテクチャ、データ利用の審査を早い段階で行う必要がある。^[5][8][10]

データを読めることと、リアルタイムに操作できることは違う

今回の政策は、主にAPIの利用可能性、API制限、管理策を扱うものであり、データ所有権を包括的に定める文書ではない。^[9] それでもエージェント型AIの文脈では、データコントロールの意味が変わる。

単にレポートをダウンロードできるかではなく、誰のAIがリアルタイムに読み取り、書き込み、API呼び出しを並べ替え、SAP内の業務状態を変更できるのかが問われるからだ。^[6][8][10]

外部分析では、この問題は企業データ統合の再点検として説明されている。企業は「SAPデータにアクセスできるか」だけでなく、「自社が選んだAIエージェントに、そのデータへ直接アクションを取らせられるか」を問う必要がある、という見方だ。^[6]

一方で、公平を期すなら、Kai Waehnerの外部分析は、SAP CEOのChristian Klein氏による説明として、政策の意図はSAPのドメイン知識を保護し、性能劣化を防ぐことであり、顧客が自社データへアクセスすることを妨げるものではない、という趣旨の発言も紹介している。^[6] 企業にとって重要なのは、この説明をそのまま期待値にするのではなく、契約、API Policy、認定アーキテクチャの一覧、個別ユースケースの許可範囲に落とし込んで確認することだ。^[6][9][12]

ベンダーロックインは「データ」より「業務フロー編成」に現れる

ベンダーロックインは、必ずしもデータを一切外へ出せない形で起きるわけではない。AIエージェント時代には、むしろ業務フローの編成層で起きやすい。

最も安全で、法務上の争点が少なく、運用サポートを受けやすいAI自動化ルートが、SAP BTP、Joule、SAP AI Core、SAP Knowledge Graph関連の経路に集まるなら、企業の長期的なAIアーキテクチャは自然とSAPエコシステムに依存しやすくなる。^[1][4][10]

The Registerは、新AI条項がロックイン懸念を引き起こしていると明確に報じている。第三者AIツールが顧客のSAPデータや業務プロセスへ直接アクセスしにくくなる可能性があるためだ。^[10] Fivetranも、ERPデータにAIエージェントをアクセスさせたい企業にとって、この政策はAI戦略上のリスクと選択を重くすると見ている。^[8]

企業が今すぐ確認すべき5項目

1. AIユースケースを細かく分解する。 読み取り専用なのか、書き戻しがあるのか、人の承認を挟むのか、AIが自律的に多段階実行するのかを分ける。後者ほど政策リスクは高くなる。^[6][8][10]
2. SAPまたはシステムインテグレーターに承認経路を確認する。 各シナリオがSAP-endorsed architecture、data service、service-specific pathway、またはSAP BTP／Joule関連の設計で実現できるかを明確にする。^[1][10]
3. 使っているAPIが公開・文書化されているかを確認する。 既存連携が文書化されていないAPIに依存している場合、リファクタリングとサポートリスクを見込む必要がある。^[5][9]
4. データ権利を契約とガバナンス文書に書き込む。 第三者AI利用、データ抽出・複製、API制限、監査、インシデント時の責任、AIがSAPへ書き戻す場合の責任分界を明確にする。^[8][9][10]
5. SAPのFAQと政策更新を継続的に追う。 SAPのFAQ文書は、API Policyに関する一般的な質問への回答を含み、随時更新される可能性があるとしている。一度の口頭説明だけに依存すべきではない。^[12]

結論：第三者AIにSAPを「自由に触らせる」前提は見直しへ

SAPの新API政策が示すメッセージは明確だ。第三者AIエージェントは、SAP APIを自由に編成してよいとは想定できなくなった。

レポート作成、オフライン分析、人が最終確認する助言型AIへの影響は限定的にとどまる可能性がある。一方、AIにSAPの中核業務を直接操作させる、ERPへ書き戻す、SAPデータを外部へ大規模に複製する、といった計画では、アーキテクチャ、契約、データガバナンスを含む重大な確認ポイントになる。^[8][10]

すでにSAP BTP、Joule、SAP AI Coreを前提にAI投資を進めている企業にとっては、公式ルートがより明確になる可能性がある。^[1][4] 反対に、ERP、CRM、サプライチェーン、データ基盤を横断するオープンなAIエージェント層を構築したい企業は、開発に入る前に、SAPが認めるアーキテクチャ、API利用権限、データ抽出の境界を確認すべきだ。そうしなければ、後になってコンプライアンス上運用できない連携方式の上に、重要なAIプロジェクトを築いてしまうリスクがある。^[5][10]