Integration Suite: ユースケースと意思決定パターン

JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

May 10, 2026 · 22 min read

本記事の位置づけ#

参考資料#

1) 統合ランドスケープ#

SAP Integration Suiteは、限られた数の反復的なユースケースパターンをカバーしています。顧客が「Salesforceと連携」「パートナーにAPIを公開」「リアルタイム在庫」「新しい3PL向けEDI」など、どのような言葉で表現しても、その背後にあるシナリオは、ほとんどの場合、以下の5つの行のいずれかに該当します。適切な機能を選択するための出発点は、価格表ではなく、ここにあります。

それらは代替ではありません。実際のプロジェクトには必ず主要カテゴリと、通常は1つの副次カテゴリがあります。両方を早期に命名することが、意思決定の半分を占めます。

2) S/4HANA への接続方法#

                     SAP Integration Suite (BTP)
   ┌──────────────────────────────────────────────────────────────┐
   │                                                              │
   │   A2A / Hybrid           API exposure          Event-driven  │
   │   ┌─────────────┐       ┌──────────────┐      ┌───────────┐  │
   │   │   Cloud     │──────▶│     API      │      │  Event    │  │
   │   │ Integration │       │  Management  │      │   Mesh    │  │
   │   └──────┬──────┘       └──────┬───────┘      └─────┬─────┘  │
   │          │                     │                    │        │
   │          │  Open Connectors    │                    │ AEM    │
   │          │  (non-SAP SaaS)     │                    │ (high  │
   │          │                     │                    │ volume)│
   │          │  TPM + Integration Advisor (B2B)         │        │
   │          │                                          │        │
   └──────────┼──────────────────────────────────────────┼────────┘
              │                                          │
              ▼  via Cloud Connector (on-prem)           ▼
        ┌──────────────┐                          ┌──────────────┐
        │  S/4HANA     │  ◀────  events  ────────▶│  S/4HANA     │
        │  on-premise  │                          │  Cloud       │
        └──────────────┘                          └──────────────┘
              ▲                                          ▲
              │                                          │
        ┌──────┴────────┐                          ┌─────┴────────┐
        │ Edge          │                          │ Non-SAP SaaS │
        │ Integration   │                          │ / IoT / B2B  │
        │ Cell (private)│                          │ partners     │
        └───────────────┘                          └──────────────┘

図を上から下に読んでください。Integration Suiteがオーケストレーションレイヤー、S/4HANA（オンプレミスまたはクラウド）が記録システム、そして最下行が統合の「相手側」が存在する場所（パートナー、SaaS、IoT、またはプライベートネットワークに制約された姉妹システム）です。Edge Integration CellはBTPの境界の下に位置します。これは、BTPでモデリングおよび管理されるものの、顧客のネットワーク内で実行されるためです。

重要なポイント：機能の選択は、エンドポイントがどこに存在し、どのように通信したいかによって決まります。顧客が既にプロビジョニングしている機能によって決まるわけではありません。

3) 成熟度マップ#

4) 要件チェックリスト#

以下の各表は、1つのユースケースカテゴリをカバーしています。ここに記載されている項目は要件段階で決定可能なものです。いずれかの行に回答できない場合、そのギャップは、それに続く実装作業ではなく、プロジェクトのリスクとなります。

A2A統合#

APIの公開と管理#

イベント駆動型統合#

外部取引先とのB2B#

ハイブリッド / データレジデンシー対応#

5) 意思決定基準#

最初に問うべき3つの質問#

Q1. 私たちが解決する、ビジネス上の観点で測定可能な統合の課題は何ですか？

もし答えが「iPaaSが欲しい」や「すでにIntegration Suiteを購入済み」であれば、そこで止めてください。答えが「SuccessFactorsからS/4HANAへの給与レプリケーションでレコードの3%が失敗し、その調整に月4人日かかっている」や「EDIマッピングにパートナーあたり6週間かかるため、12社目の3PLをオンボーディングできない」といった形になるまで戻ってください。測定可能な課題がなければ、機能の選択は恣意的になり、プロジェクトは漂流します。

Q2. エンドポイントはどこにあり、境界を越えてどのようなデータが流れていますか？

これはISA-Mドメインに関する質問です。クラウド間、オンプレミス間、オンプレミス間、さらにB2B/B2Gのオーバーレイがあり、それぞれの組み合わせによって回答が変わります。データが規制対象（個人識別情報、健康情報、財務情報）である場合、居住地法の対象となる場合、またはセキュリティポリシーがクラウドからのインバウンドを禁止している場合、候補は急速に絞り込まれ、通常はEdge Integration Cellに向かいます。

Q3. ゴーライブ後、統合の責任者は誰で、その運用予算はいくらですか？

30日目には成果を出したものの、400日目にはチームを破綻させる意思決定は、悪い意思決定です。Cloud Integrationのメッセージベースの課金は導入の拡大に比例して増加します。API Managementは異なる商用トラックで運用され、Advanced Event Meshのブローカーティアは別途交渉が必要です。予算権限を持つ明確な責任者がいない機能は、将来のインシデントです。

プロジェクトコンテキストによるドメイン選択#

ライセンスとコスト#

6) よくある障害#

障害 1: クラウド統合を万能ツールとして扱うこと

プロジェクトは、最もよく挙げられる機能であるという理由で最初にCloud Integrationを購入し、その後、純粋なAPI公開（本来はAPI Managementが適切なソリューション）や純粋なイベント公開（本来はEvent Meshが適切なソリューション）に使用します。その結果、統合コードを装ったiFlowの乱立が発生し、2年目には監視やライフサイクルの問題が表面化します。

障害 2: 初年度のボリューム予算策定

本番稼働時のメッセージ量に基づく消費予算の策定：定常状態の導入量ではなく#

この分野で最も一般的なコスト面での驚きは、本番稼働時のメッセージ量に基づいて消費予算を策定するのではなく、定常状態の導入量を基準にしてしまうことです。多くのお客様が本番稼働後12～18ヶ月で消費超過に陥り、その際の追加購入レートは通常、当初のCPEAレートよりも不利な条件となります。初年度の契約には、3年目の数値を組み込んでおくことを推奨します。

障害 3: UATまでデータレジデンシーが無視された

コンプライアンスおよび法務チームは、ほとんどのプロジェクトでテストフェーズになってから参画し、要件段階でデータレジデンシーが確認されていない場合、本番稼働を日常的にブロックします。これが、Edge Integration Cellの後付け改修を引き起こす失敗です。本来は初週の1週間の話し合いで済んだはずが、数か月にわたる再計画となってしまいます。

障害4: スタンドアロンミドルウェア、デュアルHAビジネスシステム

2つのビジネスクリティカルなシステムがHA/DR構成で24時間365日稼働している一方、それらを統合するテナントは単一インスタンスです。フェイルオーバー時に連携が失敗し、統合が停止します。Integration SuiteはクロスリージョンDRをサポートしていますが、これはデフォルトではなく、個別の判断が必要です。

障害5: B2Bクラスのフローにおけるエラーログの不十分さ

B2BおよびB2Gのシナリオでは、パートナーオンボーディング時や季節的な負荷の急増時に、エラー件数が成功件数を日常的に上回ります。汎用的なログ（「処理失敗」）では根本原因分析が不可能になり、パートナーからの問い合わせ1件ごとにエンジニアリングによる数時間の調査が必要になります。エラー処理の契約は、実装のバックログではなく、要件文書に含めるべきです。

障害 6: 名前で選択されたイベントメッシュ、AEMは形状で必要

2つの製品は「Event Mesh」という言葉を共有していますが、異なる商用トラックと異なるインフラストラクチャです。チームは、Standard Event Meshが安価でバンドルされているという理由で選択し、その後、最悪のタイミングで1 MBの上限またはスループットの実用的な制限に直面します。要件段階でメッセージサイズとイベントレートについて30分話し合うことで、6か月に及ぶ製品移行を防ぐことができます。

FAQ#

Q: すでにオンプレミスのSAP PI/POを使用しています。Integration Suiteが唯一の選択肢なのでしょうか？

これはSAPが公開する戦略的な将来の道筋であり、クラウドのみへの移行が困難なお客様向けに、Migration Assessment機能とEdge Integration Cellデプロイオプションによってサポートされています。SAP Process Orchestrationは引き続きサポートされますが、新たな投資はiPaaS側に集中しています。クリーンコア統合はSAPの5つのクリーンコア原則の1つであり、Integration Suiteを指しています。移行期間が複数年にわたる場合は移行を計画し、即時のコンプライアンス制約がある場合はEICがそのギャップを埋めます。

Q: Open Connectors が Cloud Integration カスタムアダプタよりも適切な選択となるのはどのような場合ですか？

対象のSaaSがサポートされているコネクタ一覧にあり、統合が主にストレートスルーで軽度のマッピングのみの場合、Open Connectorsを使用すれば数日で接続を確立できます。一方、Cloud Integrationとカスタムアダプタを使用する場合は、数週間の構築と永続的なメンテナンスが必要です。マッピングが複雑な場合には判断が逆転します。その場合は、どちらか一方を単独で構築するのではなく、Open Connectorsの後にCloud Integrationを連携させることを推奨します。

Q: Standard Event Mesh で十分かどうかは、どのように判断すればよいですか？

3つの数値がそれを決定します。最大メッセージサイズ（1 MB未満である必要があります）、イベントレート（サブアカウントごとに実用的に約250 KB/sに収まる必要があります）、およびトポロジー（SAP BTP内に収まる必要があります）。この3つのうちいずれかが不確定な場合は、次のボリューム階層をスコープするか、最初からAdvanced Event Mesh向けに設計してください。プロジェクト途中でのイベントレイヤーの製品切り替えはコストがかかります。

Q: Trading Partner Managementを対象外とし、Cloud IntegrationのB2Bアダプターをそのまま使用すべきなのはどのような場合ですか？

取引先の母数が少ない場合（通常5社以下）、ドキュメント標準は最小限であり、オンボーディングの頻度は四半期ごとではなく年単位となります。TPMの価値は、再利用可能なアーティファクト（会社プロファイル、取引先プロファイル、契約）とパートナーディレクトリにありますが、ボリュームが少ないとそのオーバーヘッドは償却されません。閾値を超えると、TPM + Integration Advisorは、オンボーディングにかかる時間の節約によって元が取れます。

Q: 統合要件を適切に文書化して、開発チームが再設計しなくて済むようにするにはどうすればよいですか？

3つの成果物：(1) 測定可能な課題を伴うユースケースカテゴリ（§1の5つのうちの1つ）、(2) 選択したケイパビリティを伴うISA-M分類（スタイル＋ドメイン）、(3) 運用モデルの決定（オーナー、予算、監視スタック、エラーワークフロー）。これら3つはすべて要件ドキュメントに記載され、本番環境でも維持されます。図だけでは不十分です。

Q: Cloud ALMはこの全体像の中でどのような位置づけですか？

SAP Cloud ALM と SAP Application Interface Framework は、Integration Suite全体で推奨される可観測性スタックです。これらは機能選択とは別の判断事項であり、上記の各機能はCloud ALMなしでも運用可能ですが、規模が拡大すると中央の可観測性が重要な役割を担います。監視スタックは機能と並行して決定し、後回しにしないでください。

概要#

Integration Suiteは、順番にデプロイする5つのプロダクトではありません。少数のユースケース形状と、それらの形状を防御可能な技術選択に変える方法論ISA-Mを備えた単一のプラットフォームです。5つの形状（A2A、API公開、イベント駆動、B2B、ハイブリッド）は、実際のプロジェクトが行うほぼすべてをカバーします。3つの質問（測定可能なペイン、エンドポイントドメイン、予算を持つ責任者）が、どの形状を適用するかを決定します。7つの失敗はすべて、実装のバグではなく、意思決定段階の失敗です。このフレームワークを1回のワークショップで顧客に説明できるコンサルタントは、エンゲージメントの価値があります。フレームワークを飛ばして実装ツールから始めるプロジェクトこそ、後で再設計が必要になるプロジェクトです。

次に読むべきもの#