🚫 絶対NG ― 明確な違反

▶ ODP-RFC の使用

ODP-RFC（Operational Data Provisioning via RFC）とは、SAPシステムからデータを大量に取り出すための古い仕組みです。以前はBW（Business Warehouse）やサードパーティのデータ連携ツールで広く使われていました。

SAPはこの仕組みを「使ってはいけない」と公式に明示しました（SAPノート3255746）。オンプレミスもクラウドも関係なく、すべてのABAPシステムが対象です。

今後はSAP Business Data Cloud（BDC）、ODP-OData、またはSLT（Landscape Transformation Replication Server）といった正式サポートされた方式に移行する必要があります。

【具体例】 SalesforceやTableauなどのBIツールが、SAPからODP-RFC経由でデータを自動取得している場合は要対応。サードパーティの連携ツール（例：Informatica、Talend等）がODP-RFCを使っていないか確認が必要です。

▶ 非公開の SAP 内部API へのアクセス

SAPには「公式に公開されているAPI」と「社内用の非公開API」があります。非公開APIとは、デバッグ中に発見したり、コミュニティブログに掲載されていたりするもので、SAP公式の「API Hub（Business Accelerator Hub）」に掲載されていないものです。

これらは「internal」「private」「Confidential」等のラベルが付いていることが多く、SAPが外部利用を意図していません。予告なしに仕様が変わったり削除されたりするリスクがあります。

今回のポリシーで、こうした非公開APIへのアクセスは明確に禁止されました。

【具体例】 過去にSAPの画面をデバッグして発見したAPIや、コミュニティフォーラムで共有されていた接続先を使っている場合は要注意。「API Hubに載っているかどうか」が判断基準です。

▶ 競合分析目的での API 使用

SAP APIで取得したデータを、競合他社の製品・価格・動向の調査・分析に使うことは禁止されています。

これはポリシー条項 2.2.1(a) に明示されており、利用者の意図や規模を問わず違反となります。

【具体例】 SAP上の販売データをAPIで取得し、競合他社の市場シェアを推定するような分析ツールに流し込む行為が該当します。

▶ ガバナンスなしの AI エージェントによる直接 API 呼び出し

ChatGPTのようなAI（LLM）や、複数の処理を自動でこなすAIエージェントが、SAP APIに直接・無制限にアクセスすることは禁止です。

なぜなら、人間が1回操作するだけで、AIが裏側で何千回ものAPI呼び出しを行うことがあり、システムに想定外の負荷がかかるためです。

SAP Integration Suite上のMCP Gateway、またはA2A（Agent2Agent）プロトコルという「管理された入口」を通じて接続する必要があります。

【具体例】 社内で構築したAIアシスタントが「在庫確認して」という指示を受けたとき、SAP APIを直接繰り返し呼び出している場合は禁止対象。Integration Suite等のガバナンス層を経由する構成に変更が必要です。

▶ API コントロールの意図的な迂回

SAPが設けているAPIの制限（1時間あたりの呼び出し回数の上限など）を、プロキシサーバーや独自の中継コード・なりすまし等で回避することは禁止です。

たとえ善意であっても、「制限を避けるために別の経路を通す」行為は違反とみなされます。

【具体例】 API呼び出し回数の上限に引っかかるため、複数のユーザーIDを使い回して制限を回避するような実装は禁止です。

▶ 承認されていない大規模なデータ抽出

SAP APIはもともと「業務処理のための呼び出し（1件ずつの照会や更新）」向けに設計されており、大量データの一括取得には適していません。

BDC、SLT、Analytical CDS Viewsといった「大量データ用の正式な経路」を使わずに、APIを繰り返し呼び出してデータを根こそぎ取得することは禁止です。

【具体例】 受注APIを深夜にループ処理で呼び出し、全受注データをCSVで抜き出すようなバッチ処理が該当します。代わりにBDCやSLTを使った連携設計が必要です。

⚠️ グレーゾーン ― 要確認・要議論

▶ Z ネームスペースのカスタムコード

SAPでは、お客様が独自に開発したプログラムを「Z」または「Y」で始まる名前（ネームスペース）で管理します。このカスタムコード自体はポリシーの制限対象外です。

ただし、そのカスタムコードの中で「SAP内部API（非公開API）」を呼び出している場合は違反となります。また、APIの制限を回避するためにカスタムコードを使うことも禁止です。

ABAP Test Cockpit（ATC）のCloud Readiness Checkというツールで、内部API依存がないか確認することができます。

【具体例】 Z_GET_STOCK_DATAという自社開発の在庫照会プログラムがある場合、そのプログラム内部でSAP非公開の内部関数を呼び出していないかを確認する必要があります。

▶ サードパーティの RPA ツール

RPA（Robotic Process Automation）とは、画面操作や定型処理を自動化するツール（例：UiPath、Automation Anywhereなど）です。

あらかじめ決められた手順を機械的に実行するだけのRPAは、ポリシーの禁止対象（条項 2.2.2）には当たりません。

ただし、RPAにAI（LLM等）を組み合わせて「状況を判断しながら自律的にAPIを呼び出す」構成になっている場合は禁止対象となる可能性があります。この境界線が曖昧なため注意が必要です。

【具体例】 毎朝9時に売上データを自動ダウンロードするRPAはOK。一方、AIが「今日の状況を見て判断しながら必要な情報をSAPから収集する」RPAはグレーゾーンです。

▶ 既存統合の遡及適用

今回のポリシー改訂により「これまで使えていた連携が急に使えなくなる」ということは、SAPは現時点では想定していません。

ただし、非公開APIを使った連携は今後も「自己責任」扱いとなり、SAPのサポート対象外です。突然変更・削除されるリスクは残ります。

心配な連携がある場合は、SAPサポートに相談しながら移行計画を立てることを推奨します。

【具体例】 5年前に構築した他社ERPとのAPI連携が、今でも非公開SAPインターフェースを使っている場合。即時停止にはならないが、移行計画を立てておくべきです。

▶ ADT API（開発ツール用 API）

ADT（ABAP Development Tools）は、Eclipse上でSAP ABAPの開発を行うためのツールです。このツールが内部的に使用するAPIは、あくまで開発作業のみを目的としています。

ビジネスデータの抽出・SQLの直接実行・AIワークフローへの活用などの目的での使用は禁止です。

【具体例】 開発者がADTを使ってコードを書いたりデバッグしたりするのはOK。ADT経由でSAPの販売データを自動収集するスクリプトを組むのはNG。

🔧 アーキテクチャ見直しが必要な点

▶ AI エージェント経路の再設計

AIツールやAIエージェントがSAPのデータを使う場合、直接SAP APIを呼び出す設計は禁止です。

SAP推奨の経路は2つあります。①SAP Integration Suite上に「MCP Gateway（管理された入口）」を設置し、そこを通じてAIがSAPにアクセスする方式。②A2A（Agent2Agent）プロトコルという標準規格を使い、AIエージェント同士が安全に連携する方式です。

詳細はSAP Architecture Center AI Golden Path（https://architecture.learning.sap.com/docs/aigp）を参照してください。

【具体例】 社内のAIチャットボットが「今月の売上を教えて」という問いに答えるためSAP APIを直接呼び出している場合、Integration SuiteのMCP Gateway経由に変更する必要があります。

▶ 大規模データ抽出経路の移行（特に ODP-RFC からの脱却）

大量データを定期的にSAPから取り出す連携（BIツールへのデータ供給・データウェアハウスへの連携など）で、ODP-RFCを使っているものは早急に移行が必要です。

主な移行先：SAP Business Data Cloud（BDC）＋Delta Sharingプロトコル（Databricks・Snowflakeなどとの連携に対応）、または SLT（SAP Landscape Transformation Replication Server）。分析用途にはAnalytical CDS Viewsも活用できます。

移行に関してはSAP Note 3475661も参照してください。

【具体例】 TableauやPower BIがSAP S/4HANAのデータをODP-RFC経由で毎晩取得している場合、BDCやODP-OData経由に切り替える設計変更が必要です。

▶ カスタムコードの棚卸し（内部 API 依存の洗い出し）

長年の運用の中で積み上がってきたカスタムプログラム（Zプログラム等）の中に、非公開のSAP内部APIを呼び出しているものが混在している可能性があります。

ABAP Test Cockpit（ATC）のCloud Readiness CheckやCloudification Repository Viewerというツールを使えば、そうした依存関係を自動的に洗い出すことができます。

特にRISE（クラウド移行）を検討している場合、この棚卸しは移行前に必ず実施すべき作業です。

【具体例】 10年以上運用しているSAPシステムには、当時の開発者が作ったZプログラムが数百本あることも。その中に非公開API呼び出しが含まれていないかをATCで一括チェックできます。

▶ レート制限（API 呼び出し回数の上限）への備え

各SAPのAPIには「1時間あたり何回まで呼び出せる」という上限（レート制限）が設けられています。この上限はAPI Hub（SAP Business Accelerator Hub）に記載されています。

SAPは「制裁より対話優先」の方針を明言しており、上限を超えてもすぐにアクセスが遮断されるわけではありません。ただし、継続的に超過する場合はSAPから連絡が来て、一緒に解決策を検討することになります。

SAP Integration SuiteのTraffic Management機能を使うと、超過する前に流量を調整できます。

【具体例】 月末締め処理でAPI呼び出しが集中し、レート制限に達することが想定される場合、Integration Suiteで流量制御を設定しておくと安全です。

▶ RISE 移行時の統合リメディエーション

RISE with SAPとは、オンプレミスのSAPシステムをクラウド（S/4HANA Cloud Private Edition）に移行するSAPのサービスです。

このRISEの標準サービスには「既存の連携を修正・改修する作業」は含まれていません。つまり、APIポリシーに違反した連携の改修コストはお客様負担です。

RISE移行の契約交渉の段階で、どの連携を誰が・いつまでに・どのコストで修正するかを明確に合意しておくことが非常に重要です。

【具体例】 RISE移行後に「既存のデータ連携が動かなくなった」と発覚しても、それはRISEの契約範囲外。移行前に連携の棚卸しをしておき、必要な改修をスコープに含めて交渉することが重要です。

✅ 問題なし ― 継続利用 OK

▶ Published API（公開 API）の使用

「Published API（公開API）」とは、SAP Business Accelerator Hub（API Hub）に公式に掲載されているAPIのことです。SAPが外部利用を明示的に許可しており、ドキュメント・バージョン情報・利用制限なども公式に管理されています。

このPublished APIを、ドキュメントに定められた用途・制限の範囲内で使用することは問題ありません。

【具体例】 S/4HANAのBusiness Partner APIや Sales Order APIをAPI Hubで確認しながら利用している連携はOKです。「API Hubで検索して出てくるAPI＝使っていいAPI」と覚えてください。

▶ Z/Y ネームスペースのカスタム開発

お客様が自社のネームスペース（Z〜 や Y〜 で始まる名前）で開発したプログラムやAPI（カスタムRFC、カスタムODataサービス、カスタムCDSビューなど）は、今回のポリシー制限の対象外です。

ただし、そのカスタムコードが内部でSAP非公開APIを呼び出していたり、APIコントロールを迂回する目的で使われている場合は対象となります。

【具体例】 自社専用の在庫照会ODataサービス（ZSTOCK_SRV等）や、社内システム連携用のカスタムRFCはOK。それ自体への制限はありません。

▶ 承認済みパス経由のアクセス

SAPが「承認済み」と明示している連携方式を使っている場合はすべて問題ありません。

主な承認済みパスには以下があります：SAP Integration Suite（旧Cloud Platform Integration）、SAP Business Data Cloud（BDC）、SLT（データレプリケーション）、A2AプロトコルやMCP Gateway（AIエージェント連携用）。

【具体例】 SAP Integration Suite上にビルドしたiFlowで他システムとAPI連携している場合はOKです。SLTを使ってSAPデータをリアルタイムでデータウェアハウスにレプリケーションしている場合もOKです。