# Event Mesh の価値は疎結合では終わらない：SAP 業務イベントを企業全体の共通言語に変える設計

Event Mesh を紹介する記事はよくありますが、多くは「疎結合になる」「非同期でつながる」といった説明で止まります。もちろんそれ自体は間違っていません。ただ、その理解だけで導入すると、実務ではかなりの確率で期待を外します。

本当に重要なのは、SAP の業務イベントを企業全体で再利用できる共通言語に変えられるか です。技術的にはイベント配信でも、設計上の本質はイベントの契約、意味、順序、監査、再処理の扱いにあります。

この記事では、SAP BTP の Event Mesh を単なる連携機能としてではなく、業務イベントを企業アーキテクチャへ持ち出すための基盤として整理します。

先に結論

先に結論を言うと、Event Mesh の価値は「システムをゆるくつなぐこと」だけではありません。

本当に価値が出るのは、次の 3 つがそろったときです。

  • SAP 側の出来事を業務イベントとして明確に定義できること
  • 受け手がそのイベントの意味を安定して理解できること
  • 順序、冪等性、再送、監査まで運用設計に落とせること

つまり Event Mesh は、単なる配信手段ではなく、業務イベントを組織横断で使える契約に変えるための土台です。

なぜ「疎結合」だけで語ると危ないのか

Event Mesh を「疎結合に便利な仕組み」とだけ捉えると、設計はすぐ雑になります。

たとえば次のような問題が起きがちです。

  • どのイベントを公開すべきかが曖昧
  • 同じ意味のイベントがシステムごとに乱立する
  • イベント名はあるが、業務上の意味が定義されていない
  • 再送時の扱いが決まっておらず二重処理が起きる
  • 障害時に「どこまで処理されたか」を説明できない

この状態では、配信はできても業務基盤にはなりません。むしろ同期 API より追跡しづらいぶん、後から厄介になります。

Event Mesh でまず設計すべきもの

Event Mesh を本番で使うなら、先に決めるべきなのはツール設定ではなく、イベント契約です。

最低でも次の観点を詰める必要があります。

  • 何が業務イベントなのか
  • そのイベントは誰の責務で発行されるのか
  • 発生順序を受信側がどこまで前提にしてよいのか
  • 同じイベントを複数回受けても安全か
  • 再送・欠落・遅延をどう扱うか
  • 監査時にどの ID を追跡キーにするか

ここを曖昧にしたまま「とりあえずイベントでつなぐ」と、後で受信側ごとに独自解釈が生まれます。結果として、疎結合どころか意味の不一致が広がります。

SAP 業務イ���ントを共通言語にするとはどういうことか

「共通言語」と言うと抽象的に聞こえますが、実務ではかなり具体的です。

たとえば S/4HANA で受注が確定したとき、単に `sales-order-event` のような曖昧な名前を投げるだけでは足りません。受け手にとって重要なのは、次のような情報です。

  • それは新規作成なのか、更新なのか、キャンセルなのか
  • 業務的に確定済みなのか、まだ暫定なのか
  • 下流システムは何をトリガーしてよいのか
  • 後続で訂正イベントが来る可能性はあるのか

この意味が安定していれば、物流、課金、通知、分析など複数の受信側で同じイベントを再利用できます。逆に意味が曖昧なら、各システムが独自ロジックで補完することになり、共通言語にはなりません。

実務で一番効く論点は冪等性と順序保証

Event Mesh の説明で見落とされやすいのが、冪等性と順序です。

冪等性

イベント配信では、再送や重複受信を前提に考える方が安全です。したがって受信側は、同じイベントを複数回受けても壊れない設計であるべきです。

たとえば次のような対応が必要です。

  • イベント ID で重複判定する
  • 処理済みテーブルを持つ
  • 更新系処理は version や timestamp を見て適用順を制御する

冪等性を受信側の責務として最初から置いておかないと、本番障害時に二重課金や二重通知のような地味に痛い事故が起きます。

順序保証

もう一つ重要なのが、イベントの順序をどこまで期待するかです。

業務上は「作成 → 更新 → キャンセル」の順で来てほしくても、分散環境では必ずしも綺麗に並びません。ここを曖昧にすると、受信側は最新状態を誤解します。

そのため、順序に依存する設計をするなら次を明確にする必要があります。

  • 順序保証はトピック単位か、エンティティ単位か
  • 受信側は古いイベントをどう棄却するか
  • 欠落検知をどう行うか

Event Mesh と API をどう使い分けるか

Event Mesh があるから API が不要になるわけではありません。ここを誤解すると構成が崩れます。

ざっくり言えば、次のように分けると安定します。

| 方式 | 向いている用途 | 注意点 |

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

| API | 即時応答が必要な問い合わせ・確定処理 | 呼び出し側と受け側が強く結びつきやすい |

| Event Mesh | 業務イベントの通知、非同期連携、複数購読者への展開 | 順序、再送、冪等性、監査を設計しないと壊れやすい |

つまり、API は命令に強く、Event Mesh は出来事の共有に強いです。命令と出来事を混ぜると、どちらの設計も雑になります。

監査と再処理を設計に含めないと本番で困る

PoC では流れれば終わりでも、本番ではそうはいきません。業務イベントを扱う以上、監査と再処理の設計は最初から必要です。

確認すべき論点は少なくとも次の通りです。

  • 失敗したイベントをどこで検知するか
  • 何をキーに追跡するか
  • 再処理時に業務整合性をどう守るか
  • 監査要求に対して配信と処理の履歴をどう示すか

このあたりを後付けにすると、イベント駆動は「動いているが説明できない仕組み」になりやすいです。企業システムでは、それはかなり危険です。

Event Mesh を導入しても価値が出にくいパターン

逆に、次のような状態では Event Mesh を入れても価値が出にくいです。

  • 業務イベントの意味定義が組織内で合意されていない
  • 発行元ごとに命名規則がばらばら
  • 受信側が冪等性を持っていない
  • API で十分な箇所までイベント化して複雑度だけ増やす
  • 監査と運用監視が未整備のまま本番に入る

要するに、Event Mesh は魔法の解耦装置ではありません。業務イベントを資産として扱う前提がないと、ただ難しいだけの仕組みになります。

まとめ

Event Mesh の本当の価値は、疎結合という一般論ではなく、SAP の業務イベントを企業全体で再利用できる共通言語に変えられることにあります。

そのために必要なのは、

  • イベント契約の明確化
  • 冪等性と順序保証の設計
  • API との役割分担
  • 監査と再処理の運用設計

です。

Event Mesh を導入するかどうかより大事なのは、どの業務上の出来事を、どの粒度で、誰が信頼できるイベントとして公開するのか を先に決めることです。そこが固まっていれば、Event Mesh は単なる連携機能ではなく、企業アーキテクチャの土台として効きます。