SAP Integration Suite：判断と、本番運用でのトレードオフ

SAP Integration Suiteは、SAP BTP上のSAPの連携プラットフォームです。Cloud Integration（旧CPI）に加えて、API Management、Event Mesh、Integration Advisor、Open Connectors、PI/POから移行するためのツールで構成されます。S/4HANAのクラウドプログラムでは標準のミドルウェアであり、メインストリームメンテナンスが2027年に終了するPI/POから離れるための道筋でもあります。インターフェースの遅延は、技術から生じることはまれです。原因は、あいまいな所有権、レガシーシステムに関する未検証の前提、そして失敗を見つけるためではなく合格するために設計されたテストにあります。このガイドは、連携リード、アーキテクト、プログラムマネージャーに向けたものです。各コンポーネントが何のためにあるか、標準コンテンツとカスタム開発、PI/POの移行、レガシーとテストのリスク、本稼働後のガバナンスを扱います。

**PI/POはカウントダウンの中にあります。**SAP Process IntegrationとProcess Orchestration 7.5は、2027年末までメインストリームメンテナンスの対象です。オプションの延長メンテナンスは2030年末まで続き、その後はSAPのサポートが終了します。SAPの移行リファレンスアーキテクチャが、その道筋を示しています。Integration Suiteには、PI/POの各シナリオをサイジングするMigration Assessmentアプリケーションと、Cloud Integrationのウィザード形式の移行ツールが含まれています。移行はウェーブに分けて行います。リスクの低いSAP間のフローを最初に、B2BとEDIを中間に、大量の受注フローを最後に。期限のプレッシャーのもとでの強制的なカットオーバーは、より長くかかり、より費用がかさみます。

1. ウェーブ1リスクの低いSAP間のフローMigration Assessmentで、すべてのシナリオを先にサイジングする
2. ウェーブ2B2BとEDI
3. ウェーブ3大量の受注フロー
4. 2027年PI/PO 7.5のメインストリームメンテナンス終了年末。この時期より前にウェーブを完了できるよう計画する
5. 2030年オプションの延長メンテナンス終了年末。その後、SAPのサポートが終了する

出典: SAPのメンテナンス期日と移行リファレンスアーキテクチャ。2026年10月に確認

**クラウド契約がカバーする範囲を確認してください。**RISEとGROWの契約には通常、Integration Suiteの費用に充てられるSAP BTPクレジットが含まれています。Integration Suiteを機能だけでMuleSoftやBoomiと比較する前に、ご自身の利用権がどのエディションとメッセージ量をカバーしているかを確認してください。プラットフォームが含まれている場合の経済性は、比較の結果を変えます。

**AIは段階的に登場しています。**Cloud Integrationは、2024年半ばから、Premiumエディションで生成AIによるフロー生成を提供しています。生成されるのはiFlowの構造（ステップ、チャネル、例外サブプロセス）であって、マッピングやスクリプトではありません。2026年3月に始まったSAPのenhancedエディションでは、テキストからのフロー生成とスクリプトの最適化が加わり、SAPは、Integration Suite向けのJouleを2026年第3四半期に一般提供する計画でした。標準的なフローには役立ちます。深い業務ロジックを伴う複雑なオーケストレーションには、今もシニアアーキテクトが必要です。

Integration Suiteはサービスの集合体です。仕事に合ったものを使うことが、環境の持ちやすさを左右します。

コンポーネント	役割	誤用したときに起きること
Cloud Integration（CPI）	メッセージフロー、ルーティング、変換。ほとんどのiFlowの標準	APIやイベントも含め、すべてをCPIに詰め込むと、サポートもテストも難しくなる
API Management	APIの公開をガバナンスする。セキュリティ、レート制限、アナリティクス	省くとポイントツーポイントの呼び出しが増殖し、ガバナンスを後から追加するのは難しい
Event Mesh	疎結合なトリガーのための非同期メッセージング	追跡されないキューは、誰にもアラートを出さないまま静かに増大する
Integration Advisor	EDIFACT、X12、IDocなどのB2Bフォーマットに対するマッピング提案	チームが高いカバー率を想定する。あるチームは80%を見込んで、実際は40%に近かった
Open Connectors	サードパーティのクラウドアプリ向けの構築済みコネクタ	誰かが監視していない限り、外部APIの変更でコネクタが気づかれずに壊れる
Migration Assessmentとツール	PI/POシナリオのサイジングと移行	実際の移行計画ではなく、1回限りの見積もりとして扱われる

Integration Suiteを「アドオン付きのCPI」として扱うチームは、API ManagementとEvent Meshを無視しがちです。それは、複雑さが追いついてくるまでは通用します。Cloud Integration自体については、私のSAP CPIガイドでさらに掘り下げています。

SAPの構築済み連携コンテンツは、プロセスが標準的であれば本当に役に立ちます。標準プロセスでS/4HANAをSAP AribaやSuccessFactorsにつなぐ場合は、きれいに収まることが多いものです。実際のプロセスが、SAPのリファレンスの線の内側にとどまることはまれです。

標準コンテンツを選ぶのは、次の場合です。

1. シナリオがSAP間で、SAPのリファレンスプロセスに近い
2. フローが単純で、ほとんど一方向である
3. SAPのマッピングで問題なく、提供されているエグジットを通じてのみ拡張できる

カスタム開発を選ぶのは、次の場合です。

1. 長年の社内判断によって、プロセスがSAPのモデルから離れている
2. 条件付きルーティング、複数ステップのロジック、レガシー特有のクセが関わる
3. 大幅な変更を加えると、標準パッケージに対するSAPのサポートの整合性が損なわれる

判断はブループリントの段階で行ってください。遅れて判断すると、プロジェクトの途中で、「標準」のiFlowが大幅に改変されてサポートの整合性を失っていたことが判明し、本稼働のプレッシャーのもとで作り直すことになります。標準コンテンツが、カスタムのマスタデータ構造、追加フィールド、レガシー認証を一度に吸収してくれると思い込んだせいで、数週間を失ったプロジェクトを見てきました。吸収されませんでした。設計の段階で行うべき分析が、UATの最中に行われたのです。

大規模なSAPプログラムでは、連携は、ワークストリームの隙間に最初に落ちるものであることが多いです。インターフェースはチームの境界をまたぎますが、その調整を担う人はいません。2つのプロジェクトチームが、同じビジネスパートナーに対して、同じエンドポイントを指す別々の連携を、互いを知らないまま構築していたのを見たことがあります。どちらも、UATまで気づきませんでした。これは構造上の失敗であって、技術上の失敗ではありません。

中央の連携ガバナンスを、早い段階で立ち上げてください。

1. すべてのワークストリームから見える、共有の連携バックログ
2. 各インターフェースに指名されたオーナーを置き、デリバリーを通じて追跡する
3. 主要なデプロイの前に、ワークストリーム間で調整のチェックポイントを設ける
4. 本稼働のコミットメントの前に、インターフェース間の依存関係をレビューし、共有されるエンドポイントとキューをカットオーバー計画の中で順序付けする
5. 環境間の自動デプロイ。認証情報はランドスケープごとに文書化する

最も難しい連携の問題は、最新のプラットフォームであることはまれです。重要なプロセスの中央にある、古いシステムです。

レガシーERPは、同時の同期呼び出しを処理できないことがよくあります。5つのAPI呼び出しを並列で送ると、サーバーは遅くなるか、フリーズするか、データを黙って落とします。非同期連携が役立つのは、受信側のシステムがキューを処理できる場合に限られますが、それができないシステムは多くあります。

プロトコルの不一致はよくあり、見つかるのは遅い時期です。OAuth2とRESTで設計したのに、レガシーシステムはSOAPで、タイムアウトは30秒にハードコードされており、トークンの更新も苦手です。

あるクライアントの事例では、サードパーティの給与システムが発行するトークンが週ごとに失効するため、ミドルウェアのフローが毎週金曜日に失敗していました。2回目のUATサイクルまで、誰も気づきませんでした。このようなクセはよくあり、タイムラインを食いつぶします。

次の表は、設計凍結の前に確認すべきリスクの一覧です。

リスク	よくある問題	設計で行うべきこと
同期の制約	並列呼び出しでレガシーがロックアップする	非同期メッセージングを使い、Event MeshまたはCloud Integration経由で呼び出しをずらす
プロトコルの不一致	レガシーがRESTやOAuthを拒否する、またはSOAPでタイムアウトする	設計を始める前に、プロトコルとタイムアウトを確認する
APIのレート制限	バッチジョブがサードパーティのスロットリングを超える	API Managementで流量を絞り、iFlowに待機ロジックを加える
トークンの失効	閑散時間帯にフローが黙って失敗する	更新サイクルをスケジュールし、失効を監視する
硬直的なフォーマット	動的なペイロードがレガシーのパースを壊す	本番の実サンプルで検証する
フォールバックなし	ファイル転送がリトライなしで失敗し、データが滞留する	ミドルウェアでバッファし、iFlowにリトライとアラートを組み込む

クラウドをまたぐ場合のこうした問題については、私の記事ERPとSalesforceの連携が失敗する理由と対処法をご覧ください。

連携は、機能テストが確認するような壊れ方はしません。タイミングの圧力のもとで、バックグラウンドジョブが重なったときに、そして入力が1件ずつではなく大量に届いたときに失敗します。機能テストが証明するのは、トランザクションが転記され、メッセージがログに現れることです。最初の給与処理でIDocが大量に押し寄せたときに何が起きるかは、証明してくれません。あるプロジェクトでは、システム統合テストできれいに見えたIDocが、実際の給与の量が流れ込んだときにキューを止めました。それを見つけたのは負荷テストだけでした。

インターフェースのテストでは、次をカバーする必要があります。

1. 同時ユーザーを伴う、現実的なデータ量
2. サービスの中断と、復旧時の挙動
3. ミドルウェアとバックエンドをまたぐタイムアウトとリトライ
4. リアルタイム呼び出しと並行して動くバッチジョブ
5. 月末やその他のピーク期間

開発環境はきれいです。デッドロック、競合状態、スロットリングは、他のシステムとバッチウィンドウが稼働しているUATや本番前環境で表に出るので、負荷テストはそこで行ってください。責任分担は明確に分けます。機能チームはフロー全体にわたってビジネス結果を検証し、連携チームはログ、リトライ、例外フローを所有し、プロジェクトリードはカバレッジを確認します。負荷面については、私のガイドSAPパフォーマンステストで扱っています。

Integration Advisorは、構造化されたB2Bフォーマットに対するマッピングを提案します。厳格な規約に従うパートナーであれば、セットアップの手間を確実に減らします。レガシーシステム、カスタムフィールド、条件付きロジック、文書化されていないルールを伴うエンタープライズの連携では、出発点にすぎません。

私が関わったあるチームは、マッピングの80%がカバーされると見込んでいました。実際のカバー率は約40%でした。残りは、カスタマイズし、ビジネス側と検証し、手作業でテストする必要がありました。

長年にわたって非公式に積み上がった業務ロジック（支払条件、価格カテゴリー、単位の慣行）、業務の文脈に基づく条件付きルール、標準フォーマットの外にある例外は、解決してくれません。これらには機能面のインプットが必要です。それがなければ、インターフェースは技術的にはマッピングされていても、特定のケースでは論理的に間違っているものになります。

連携は、ドキュメントが実態から離れ、所有権が正式に定められていないと、本稼働後に劣化します。役に立つドキュメントは、フィールドマッピングと変換ロジック、そしてエンドポイント、トークンの更新、認証情報のローテーションといった認証の詳細を扱います。エラー処理、フォールバックのルール、月末や給与処理といった重要な期間の量の見込みも扱います。判断基準はこうです。来週サポートチームに加わった人が、ドキュメントだけを頼りに、障害の出たインターフェースをトラブルシューティングできるでしょうか。

すべてのインターフェースには、取引量が少ないものであっても、監視、エスカレーション、ライフサイクルの変更を担う指名されたオーナーが必要です。それがなければ、障害はBasis、ミドルウェア、機能の各チームの間をたらい回しにされ、その間ビジネスは待たされます。ハイパーケアの後は、監視が薄れがちです。定期的なエラーログのレビュー、プロジェクトからサポートへの正式な引き継ぎ、ビジネスとITの間で合意したサービスレベルを組み込んでください。放置された連携は、本稼働の数週間後に表面化する、転記の遅れ、請求書の欠落、財務レポートの不整合の多くの背後にあります。

SAP Integration Suiteとは何で、CPIとはどう違いますか？

Cloud Integration（旧SAP Cloud Platform Integration、CPI）は、Integration Suiteの中の1つの機能です。スイートには、ガバナンスの効いたAPI公開のためのAPI Managementと、非同期メッセージングのためのEvent Meshが加わります。さらに、B2Bのマッピング提案のためのIntegration Advisor、サードパーティのクラウドアプリ向けのOpen Connectors、PI/PO向けの評価・移行ツールも含まれます。名前が変わっただけのCPIとして扱うチームは、API ManagementとEvent Meshを省きがちで、後からガバナンスのギャップでその代償を払います。

SAP PI/POのサポートはいつ終了しますか？

SAP Process IntegrationとProcess Orchestration 7.5は、2027年末までメインストリームメンテナンスの対象です。お客様は、2030年末までオプションの延長メンテナンスを選べますが、その後はSAPのサポートが終了します。Integration Suiteには、各シナリオをサイジングするMigration Assessmentアプリケーションと、成果物を半自動で移行する移行ツールが含まれています。期限を待つのではなく、ウェーブの計画から始めてください。

SAPの連携では、標準コンテンツとカスタム開発をどう使い分けるべきですか？

シナリオがSAP間で、SAPのリファレンスプロセスに近く、比較的単純な場合は、標準コンテンツを使います。プロセスがSAPのモデルから離れている場合、レガシー特有のクセに個別の対応が必要な場合、あるいは条件付きや複数ステップのロジックのために標準パッケージに大幅な変更を加えざるを得ない場合は、カスタムで構築します。判断はブループリントの段階で行ってください。本稼働のプレッシャーのもとで、変更しすぎた標準フローを作り直すほうが、最初からきれいにカスタムで作るより費用がかかります。

複雑なプログラムでSAPの連携が失敗する原因は何ですか？

ほとんどは構造的な原因です。監視とエラー解決の指名されたオーナーがいないため、障害がチーム間をたらい回しになる。2つのワークストリームが、互いに知らないまま、エンドポイントやキューを共有する連携を構築する。同時呼び出しを処理できないレガシーシステムが、負荷がかかって初めて見つかる。そして、単体ではきれいに通るのに、バッチの重なりやピーク時の量を一度も再現しないテスト。

SAP Integration Suiteの連携テストは、どう構成すべきですか？

機能テストに加えて、最初の月末処理や給与処理のような、現実的な量をカバーしてください。バッチジョブとリアルタイムのインターフェースを並行して動かすテスト、下流のシステムが利用できないときの復旧、一括処理時のサードパーティのレート制限もテストします。クリーンな開発システムは問題を隠してしまうため、負荷テストとパフォーマンステストは、本番に近い環境で実施してください。

本稼働後のSAP連携は、どうガバナンスすべきですか？

すべてのインターフェースに、監視、エスカレーション、変更を担う指名されたオーナーを置きます。ドキュメントは最新に保ちます。マッピング、認証と認証情報のローテーション、エラー処理、量の見込みです。そして、定期的なエラーログのレビュー、プロジェクトからサポートへの正式な引き継ぎ、合意されたサービスレベルを備えた、長期的なサポートモデルを構築します。見えなくなった連携は、放置されます。