まず結論です。SAP Integration Suite は「システムをつなぐための道具」としてだけ見ると、かなりもったいないサービスです。もちろん、API Management、Cloud Integration、Event Mesh などを使って連携を作ることはできます。しかし企業システムで本当に面倒なのは、最初の接続よりも、その接続を長く安全に運用し続けることです。

この記事では、SAP BTP 上の Integration Suite を、実装ツールではなく連携ガバナンスのための基盤として整理します。Qiita 版より少し設計寄りに、API ライフサイクル、イベント、監視、認証、監査の境界を見ます。

この記事で扱うこと

対象読者は、SAP S/4HANA、周辺 SaaS、オンプレミスシステム、クラウドサービスを連携させる立場の人です。開発者だけでなく、アーキテクト、BTP 管理者、情シス側のプラットフォーム担当にも関係します。

この記事で見るポイントは次の 4 つです。

| 観点 | よくある見方 | 実際に重要なこと |

|---|---|---|

| 接続 | API を呼べるか | 誰が、どの条件で、どの責任で呼べるか |

| 実装 | フローを作れるか | 変更・再利用・障害対応に耐えられるか |

| 運用 | エラーが見えるか | 監視、再処理、監査の流れが決まっているか |

| 統制 | 連携を増やせるか | 野良 API と属人化を防げるか |

「つながったので完了」という考え方は、最初のデモでは通用します。運用に入ると、だいたいそこで事故ります。

Integration Suite は何をまとめているのか

SAP Integration Suite は、単一の機能名ではありません。複数の連携機能をまとめたスイートです。代表的には次のような要素があります。

  • Cloud Integration: システム間のメッセージ変換、ルーティング、連携フロー
  • API Management: API の公開、保護、ポリシー適用、利用管理
  • Event Mesh: イベント駆動連携のためのメッセージング
  • Open Connectors: 外部 SaaS とのコネクタ活用
  • Trading Partner Management: B2B 連携の管理
  • Integration Advisor: マッピングや B2B メッセージ設計の支援

もちろん全部を一度に使う必要はありません。ただし重要なのは、これらが「接続手段の寄せ集め」ではなく、連携を管理可能な形にするための部品だという点です。

たとえば S/4HANA の受注データを外部の物流システムへ送るだけなら、技術的には HTTP API、ファイル連携、メッセージキューなど、いくつも方法があります。しかし実務では次の問いがすぐに出ます。

  • API の利用者をどう認証するのか
  • 失敗したメッセージを誰が再処理するのか
  • 項目変更があったとき影響範囲をどう追うのか
  • 外部パートナーごとの仕様差分をどこに閉じ込めるのか
  • 監査時に、いつ誰が何を送ったか説明できるのか

このあたりを放置した連携は、動いているように見えても運用負債です。

「API を公開する」と「API を管理する」は違う

API Management の価値は、エンドポイントを外に出すことだけではありません。むしろ重要なのは、API を管理対象として扱えるようにすることです。

最低限、次のような論点があります。

| 論点 | 見るべきこと |

|---|---|

| 認証・認可 | OAuth、JWT、API key、Principal Propagation などをどう使うか |

| 利用制御 | レート制限、クォータ、IP 制限、呼び出し元制御 |

| バージョン管理 | v1/v2 の共存、廃止ポリシー、利用者への移行通知 |

| 可観測性 | 呼び出し回数、エラー率、レスポンス時間、利用者別の傾向 |

| セキュリティ | 不要な項目露出、過剰権限、内部 API の外部公開防止 |

API は一度公開すると、勝手に消せません。利用者が増えるほど、変更の自由度は下がります。だから最初から「誰に、どの契約で、どの保証範囲で使わせるのか」を決めておく必要があります。

ここを考えずに Integration Suite を使うと、ただの便利な中継サーバーになります。残念ながら、それは BTP を使っているのに治理できていない状態です。

Cloud Integration はフロー作成ツールで終わらせない

Cloud Integration では、iFlow を使って連携ロジックを作れます。メッセージ変換、条件分岐、例外処理、外部サービス呼び出しなど、実装面ではかなり柔軟です。

ただし、ここでよくある失敗は「動く iFlow」を大量生産することです。動くものを作るだけなら早い。しかし、次の半年で地獄を見る可能性があります。

たとえば次のような状態です。

  • 似たようなマッピングが複数の iFlow に散らばる
  • エラー処理の方針がフローごとに違う
  • 命名規則がなく、何の連携か分からない
  • 接続先の認証情報が場当たり的に管理される
  • テスト環境と本番環境の差分が説明できない

Integration Suite を治理基盤として使うなら、iFlow はコード資産に近いものとして扱うべきです。命名、責任範囲、再利用部品、エラーハンドリング、リリース手順を決める。地味ですが、ここをやらないと連携基盤はすぐ汚れます。

イベント連携は「リアルタイムっぽい」だけでは足りない

Event Mesh を使うと、イベント駆動の連携を組みやすくなります。S/4HANA 側で業務イベントが発生し、それを購読側システムが処理する、という形です。

これは疎結合化に効きます。送信側が受信側の都合を細かく知らなくてもよくなり、複数の購読者へ展開しやすくなります。

ただし、イベント連携にも治理が必要です。

  • イベント名の命名規則
  • ペイロードのスキーマ管理
  • 冪等性の設計
  • 重複配信や遅延への対処
  • 失敗時の再処理とデッドレター処理
  • 購読者が増えたときの影響範囲管理

たとえば「BusinessPartnerChanged」というイベントを出すとしても、何が変わったのか、どの粒度で通知するのか、過去互換性をどう保つのかを決めないと、購読側はすぐ壊れます。

イベント駆動は魔法ではありません。同期 API の密結合を、名前のついていない非同期地獄に変えるだけなら、むしろ悪化です。

監視と監査を後付けにしない

連携は失敗します。ネットワーク、認証、データ不整合、外部 API の仕様変更、タイムアウト。理由はいくらでもあります。

だから設計段階で、少なくとも次を決める必要があります。

| 項目 | 決めること |

|---|---|

| 検知 | どのエラーを誰に通知するか |

| 再処理 | 自動再試行するか、人手で確認するか |

| 保管 | メッセージやログをどこまで残すか |

| 監査 | 誰がいつ何を連携したか説明できるか |

| 責任 | SAP 側、外部システム側、基盤側の境界 |

Integration Suite には監視やログ確認の仕組みがありますが、ツールがあるだけでは運用になりません。通知先、一次対応、再実行ルール、データ修正の権限まで決めて、初めて運用です。

「エラーが出たら見ればいい」は、だいたい誰も見ません。現場あるあるですが、笑えません。

BTP 全体の治理とつなげて考える

Integration Suite は、BTP の中で単独に存在するわけではありません。認証は Identity Authentication や Identity Provisioning、権限管理、場合によっては Principal Propagation と関係します。拡張アプリは CAP、Kyma、ABAP Cloud などと連携することもあります。監査や運用設計は、企業全体のセキュリティ標準ともつながります。

つまり Integration Suite の設計は、BTP 全体のプラットフォーム設計から切り離せません。

たとえば次のような決め事が必要です。

  • どの API を社内標準 API として扱うか
  • 誰が API のオーナーになるか
  • 接続先ごとの認証情報をどう管理するか
  • サブアカウント、スペース、環境分離をどう設計するか
  • 本番変更の承認フローをどうするか
  • 監査ログをどの期間保持するか

これらを決めずに各プロジェクトが自由に連携を作ると、短期的には速く見えます。しかし数年後には、誰も全体像を把握できない連携ジャングルになります。森ではありません。ジャングルです。しかも毒があります。

実務で最初に決めるべきチェックリスト

Integration Suite を本気で使うなら、最初に次を決めておくと失敗しにくいです。

| チェック | 内容 |

|---|---|

| API オーナー | API の仕様変更と廃止判断の責任者 |

| 命名規則 | API、iFlow、イベント、トピック、パッケージの名前 |

| 認証方式 | OAuth、証明書、Principal Propagation などの標準方針 |

| エラー処理 | 再試行、通知、手動介入、デッドレターの扱い |

| ログ保持 | 監査・障害調査に必要な保持期間 |

| バージョン管理 | 互換性、移行期間、破壊的変更の扱い |

| 環境分離 | 開発、検証、本番の差分管理 |

| 再利用方針 | 共通マッピング、共通接続、標準テンプレート |

この表の半分も決まっていないなら、まだ「統合基盤」ではなく「連携作業場」です。便利ですが、治理とは呼びにくい。

まとめ

Integration Suite の本質は、SAP と外部システムを接続することだけではありません。API、イベント、メッセージ変換、認証、監視、監査を、企業として管理できる形に近づけることです。

要点をまとめます。

  • Integration Suite は単なる接続ツールではなく、連携治理の基盤になり得る
  • API Management は公開よりも、認証、制御、バージョン、利用状況の管理が重要
  • Cloud Integration は iFlow を量産する場所ではなく、運用可能な連携資産を作る場所
  • Event Mesh は疎結合化に効くが、スキーマ、冪等性、再処理設計が必要
  • 監視と監査は後付けではなく、最初から設計するべき

まずやるべきことは、機能一覧を眺めることではありません。自社の連携を、誰が所有し、どう変更し、どう失敗から復旧し、どう監査に耐えさせるのかを決めることです。

Integration Suite は、そのための道具です。道具を買っただけで治理が生えるわけではありません。そこを間違えると、また高級な配線置き場が増えるだけです。