Cloud Integration (CPI): アーキテクチャと用途

JinJin48

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

May 10, 2026 · 22 min read

本記事の位置づけ#

参考資料#

1) Cloud Integration のランドスケープ#

Cloud Integration（旧称CPI）は、SAP Integration Suiteのプロセス統合機能です。SAP BTP Cloud Foundry上で動作し、リージョンはAWS、Microsoft Azure、Alibaba Cloudに対応しています（SAP Integration Suiteの機能範囲説明書では、Cloud Foundryが唯一の標準環境であると確認されており、EU-Access契約ではEU事業者以外のCloud Foundryを使用できないと記載されています）。内部では、CPIはApache Camelルーティングエンジンを実行しています。描画するすべてのiFlowは、ランタイムノードが実行するCamelルートにコンパイルされます（このアーキテクチャは、Vikas Sharma氏の コアアーキテクチャシリーズなどのサードパーティによる解説で要約されています）。

これらは代替品ではありません。

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

                    SAP Integration Suite — Cloud Integration tenant (BTP CF)
   ┌──────────────────────────────────────────────────────────────────────┐
   │  Tenant Management Node (TMN)                                        │
   │  ─ design-time, deployment, monitoring, keystore                     │
   │                                                                      │
   │  Worker nodes (JVM × N, Apache Camel)                                │
   │   ─ iFlow execution: adapter ↔ steps ↔ adapter                       │
   │   ─ JMS queues, Data Store, Variables (per-tenant)                   │
   └──────┬─────────────────────────┬──────────────────────────┬──────────┘
          │ IDoc / RFC / OData      │ OData / REST             │ XI / SOAP / file
          ▼                         ▼                          ▼
   ┌──────────────┐         ┌────────────────┐         ┌──────────────┐
   │ S/4HANA      │         │ S/4HANA        │         │ Trading      │
   │ on-premise   │         │ Cloud (public/ │         │ partners     │
   │ via SAP      │         │ private)       │         │ (AS2/AS4)    │
   │ Cloud        │         └────────────────┘         └──────────────┘
   │ Connector    │
   └──────────────┘

オンプレミスのS/4HANAの場合、RFCアダプタとIDocアダプタは、顧客環境へのセキュアなトンネルとして SAP Cloud Connector を必要とします。FSDドキュメントでは、サポート対象の基盤としてNetWeaver 7.31が記載されています。S/4HANA Cloudの場合、公開されたODataサービスに対するOAuth 2.0が標準パターンであり、OAuth2クライアントクレデンシャルフローは、 SAP Helpのセキュアな認証方法に従い、AMQP/WebSocket、OData V2、OData V4、およびHTTPレシーバアダプタでサポートされています。データの保存場所や低レイテンシでのローカルシステムアクセスが必要な場合、同じiFlowを代わりに Edge Integration Cell にデプロイできます。これは、 ハイブリッドデプロイメントにおけるEdge Integration Cellの使用に記載されている、顧客管理のKubernetesランタイムです。

重要ポイント：Cloud Integration は BTP 上でのルーティングおよび変換レイヤーです。S/4HANA エンドポイントへの到達可能性は、Cloud Integration テナント自体ではなく、Cloud Connector、アダプター、および（ハイブリッド環境では）Edge Integration Cell に依存します。

3) 成熟度マップ#

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

デザインドメインごとに1つのサブテーブル。各行は要件段階で決定可能でなければなりません — 実装の詳細は後回しにします。

アダプターと接続性#

永続性と信頼性#

セキュリティと認証情報#

オペレーションとトランスポート#

5) 意思決定基準#

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

Q1. 現在のポイントツーポイントやバッチジョブでは対応できない、測定可能かつ定期的なメッセージベースの統合作業が、異なるシステム間で発生していますか？

もし答えが「2つのインターフェースがあり、1つは夜間に実行され、両方とも動作している」というものであれば、Cloud Integrationは過剰です。Cloud Integrationのライセンス費用に見合う価値が生まれるのは、少なくとも数個のインターフェースが存在し、継続的な変更があり、cronジョブによるバッチ処理で提供できる範囲を超える運用SLAが求められる場合です。

Q2. データはどこに保存され、パブリッククラウドのiPaaSを経由してもよいか？

データレジデンシーがCloud Foundryリージョンの選択を左右し、規制ルールによってクラウド経由のデータ転送が完全に禁止される場合、ランタイムはEdge Integration Cellへと移行します。EICは安価なCPIではなく、顧客がKubernetesプラットフォームを所有する、異なる運用モデルです。

Q3. 組織図上で統合インターフェースを所有しているのは誰ですか。また、その担当者は構築とランタイムの両方に予算を確保していますか。

Cloud Integration のランタイムコストは、送信メッセージ1件あたり250KB単位のメッセージ量に大きく依存します。2年目のメッセージ量を追跡する予算責任者がいない場合、プロジェクトは過小規模で計画され、会計年度途中での再交渉が発生します。

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

ライセンスとコスト#

最も見落とされがちな請求ルール：アウトバウンドメッセージは250 KBごとにカウントされ、スプリッター出力と再試行はそれぞれ課金されます。標準の未変更SAP統合コンテンツ（SAP間）および内部のProcessDirectアダプターとJMSアダプターは例外ですが、標準コンテンツのProcessDirect拡張は例外ではありません（ integration-excellence.comのメッセージトラフィックライセンス分析による）。

6) よくある障害#

障害 1: ゴーライブ時点に合わせたサイジングであり、2年目を考慮していない

Go-live後の最初の60日間は代表的な期間ではありません。新しいインターフェースが追加され、スプリッターを多用するiFlowによって送信メッセージ数が増加し、インシデント発生時のリトライ急増により、含まれているメッセージバケットが消費されます。要件定義フェーズでは2年目の予想ボリュームを把握し、それを明示的に予算化してください。

障害 2: ProcessDirect 請求例外の反転

内部 ProcessDirect アダプタは課金されません。ただし、標準の SAP 統合コンテンツのカスタマ拡張機能を呼び出す場合を除きます。このルールを早合点したチームは「すべての ProcessDirect は無料」と想定し、出荷済み iFlow を拡張した後に課金を発見します。標準コンテンツを拡張する前に、ライセンス条件を必ずお読みください。

障害 3: べき等性が設計されていない

Cloud Integrationのデフォルトの配信は「最低1回（at-least-once）」です。Idempotent Process Call（または受信側の重複排除）がない場合、再試行の集中（リトライストーム）時に重複が受信側に到達し、その重複が数週間後に元の原因とはかけ離れた下流のインシデントを引き起こします。冪等性（Idempotency）は要件段階での判断であり、後付けの修正ではありません。

障害 4: 同一フロー内での JMS リトライとデータストアリトライの混在

JMS は SAPJMSRetries によりネイティブにリトライを実行します。一方、Data Store のリトライは明示的であり、設計者が SAP_DataStoreRetries を介して制御します。これらを1つの iFlow 内で混在させると（通常は2人のチームメンバーがそれぞれ一部を設計した場合）、リトライが2回発生したり、メッセージが失われたり、ポイズンピルでブロックされたりするフローが生成されます。インターフェースごとに1つの永続化およびリトライモデルを選択し、それを文書化してください。

障害 5: Cloud Connector の依存関係を見落としている

オンプレミスのS/4HANAをRFC/IDoc経由で接続するには、SAP Cloud Connectorが必要です。CPIからオンプレミスのECCに直接線を引いたアーキテクチャ図では、顧客が適切なNetWeaverパッチレベルでCloud Connectorをインストールするために慌てふためき、本番移行のカットオーバーに遅延が生じます。Cloud Connectorは実装の詳細ではなく、独立した依存関係として扱ってください。

障害 6: デプロイ後に命名規則を選択

命名ルールを最初から定めなければ、モニタリングフィルターが機能しなくなり、トランスポートパッケージに無関係なアーティファクトが混在し、ランブックには200ものiFlowがランダムな名前で羅列されることになります。SAPは Naming Conventionsのページを公開しています。初日から命名規則を決め、パッケージレベルのレビューでそれを徹底しましょう。稼働中のシステムで後から名前を修正するのは、本当に困難です。

FAQ#

Q: Cloud Integration は SAP PI/PO を置き換えるものですか？

新しいプロジェクトの場合、その通りです。SAPはCloud Integrationを将来のプラットフォームとして位置づけており、SAP Process Orchestration 7.5のコンテンツをIntegration Suiteに移行するためのMigration Assessment機能も公開しています。既存のPI/PO環境については、置き換えは単なる切り替えではなくプロジェクトとなります。アダプター、マッピングスタイル、運用習慣が十分に異なるため、「リフトアンドシフト」が正確であることはほとんどありません。

Q: Edge Integration Cellは、標準のCloud Foundryデプロイメントの代わりにいつ使用すべきですか？

データの保存場所、コンプライアンス、またはレイテンシ要件により、顧客のネットワーク外へのデータ送信が禁止されている場合に使用されます。EICはオンプレミス/プライベートクラウドランタイムであり、同じiFlowアーティファクトを実行します。設計と監視は引き続きBTPクラウドテナントで行われます。EICには、顧客所有のエンタープライズグレードのKubernetes（ SAP Architecture Centerリファレンスに従い、SUSE Rancher、OpenShift、AKS、EKS、GKE）が必要なため、その運用モデルはクラウド専用CPIとは根本的に異なります。

Q: メッセージの課金は具体的にどのように行われますか？

送信メッセージごとに、250 KB単位で課金されます。100 KBのメッセージ = 1課金、2 MBのメッセージ = 9課金、50件の出力を生成するスプリッター = 50課金となります。再試行は毎回カウントされます。標準のSAP間コンテンツおよび内部のProcessDirect / JMSアダプター呼び出しは例外となりますが、標準コンテンツのProcessDirect拡張は例外ではありません。

Q: JMS、データストア、変数はどのように使い分ければよいですか？

JMSは、ネイティブリトライ機能を備えた非同期キュー型インターフェースに使用します。バックプレッシャーが必要で、プラットフォーム自体がリトライを実行する場合に適しています。Data Storeは、明示的なライフサイクル管理（スケジュールされたコンシューマー、手動再処理UI、バッチハンドオフ）に使用します。Variablesは、テナントごとの小さな状態（最終成功タイムスタンプ、最終成功プライマリキー）のみに使用し、ペイロード本体には決して使用しません。公式の SAP Help 判定ページが正規のリファレンスです。

Q: プロジェクトからCloud Integrationを対象外とするのはどのような場合ですか？

統合フットプリントが1～2つのインターフェースであり、拡張のロードマップがない場合、Cloud Integrationテナントの固定費（サブスクリプションベースライン＋3つの環境（DEV/QAS/PROD）すべてが課金対象）は、単一の夜間OData呼び出しに対して正当化するのが困難です。そのようなケースでは、直接的なCommunication Arrangementまたは小規模なカスタムサービスの方がより適切です。

Q: 統合開発者が構築できるように、インターフェース要件を適切に文書化するにはどうすればよいですか？

各インターフェースについて、以下を記録してください：送信元システム＋エンドポイント、送信先システム＋エンドポイント、アクション動詞（作成/更新/削除/複製）、ビジネスオブジェクト（受注、ビジネスパートナーなど）、トリガー（スケジュール/イベント/同期呼び出し）、1日あたりおよびピーク時間あたりの想定ボリューム、平均および95パーセンタイルのペイロードサイズ、配信セマンティクス（ファイア・アンド・フォーゲット/最低1回/正確に1回）、および送信先での冪等性ルール。これにより、メッセージ課金、永続化の選択、アダプター選定の見積もりが可能になります。

Q: 非本番テナントは無料ですか？

いいえ。すべてのテナント（DEV、QAS、PROD）は、メッセージごとに独立して課金されます。一部のチームはこれを忘れて、QASに対する負荷テストで月間メッセージ枠の半分を消費してしまったことに気づきます。テストデータのボリュームはそれに応じて計画してください。

Q: テナント間でiFlowを移行するにはどうすればよいですか？

SAP Cloud Transport Management Service (CTMS) を Content Agent Service をブリッジとして使用します。CTMS はパッケージレベルおよび個別アーティファクトレベルの移送をサポートします。初回のプロモーションの前にセットアップしてください。アーティファクトがテナント全体に散在した後に行うと、設定の損失リスクが生じ、困難を伴います。

概要#

Cloud Integrationは成熟しており、十分に文書化されており、アーキテクチャ面で驚くことはありません。マルチテナントランタイム上のApache Camel、70以上のアダプタ、および 機能範囲の説明に従った3つの永続化モデルを備えています。しかし、2年目のボリュームを後回しにすると、商業面で驚くことになります。コンサルタントの仕事は、最初のiFlowを描く前に3つの質問をし、インターフェースごとに1つの永続化と再試行パターンを選択し、ワークロードが標準のCloud FoundryとEdge Integration Cellのどちらに属するかを判断し、アーティファクトをデプロイする前に命名規則を決めることです。これら4つの決定が明確であれば、それ以外のアダプタ、マッピング、OAuthフローなどは、統合開発者が処理できる実装の詳細にすぎません。

次に読むべきもの#