注文確定を在庫・配送へどう伝える？イベント連携で先に決めること

イベント連携は、起きた事実を次の仕事へ伝える仕組み

イベントは、業務やシステムで起きた出来事を表す情報です。この例なら「注文が確定した」という事実が候補です。イベント連携では、その知らせを必要な側が受け取り、自分の仕事を判断します。「在庫を引き当ててください」という依頼と、「注文が確定しました」という事実の知らせは意味が違います。事実を知らせたことだけで、相手の仕事を完了にしません。

発信側

知らせる事実を記録し、外へ渡す側です。この架空例では受注側です。何を確定と呼ぶか、いつ発信するか、項目の意味を説明できる必要があります。

受信側

知らせを受けて、自分の業務を進める側です。在庫側と配送側では、必要な情報、開始条件、完了の意味が異なります。

中継する仕組み

必要に応じて、知らせを受け付け、宛先へ届ける仕組みを置きます。一般にブローカーなどと呼ばれます。保存、配送、再送、順序の扱いは採用する製品や設定で確認します。この例では製品も構成も未決です。

連携の取り決め

知らせる事実、項目の意味、受け手の処理条件、変更時の連絡、結果確認、例外時の対応をそろえた約束です。通信で使う形式だけを指すものではありません。

一つの出来事を複数の仕事が利用する場合でも、すべての仕事を同時に開始できるとは限りません。配送準備に在庫引当の完了が必要なら、配送側は注文確定の受領だけで準備へ進まず、必要な状態を確認する設計が要ります。

AWSの設計解説では、発信者が項目の意味を含む取り決めを明らかにし、受信者が受信後の処理を担うという責任の分け方を示しています。この記事では、その考え方を一件の注文の質問へ具体化します。特定製品の導入や、自動的な配信保証を意味しません。AWS公式解説（2023年7月24日）の責任分担

イベント連携を選ぶ前に、待てる仕事と待てない判断を分ける

イベント連携が適するかは、「今すぐ相手の業務結果が必要か」「受信後の状態を追えるか」「受け手ごとに開始条件を決められるか」で考えます。受注側と受信側を分けるほど、全体の状態を追い、途中で止まった注文を調べる責任も必要です。

注文を確定する前に、在庫確保の可否を回答する必要がある

必要な業務結果を待つ呼出しや、一連の手順を管理する方式を候補にします。「後で処理する知らせ」に置き換えるだけでは、顧客へ回答する条件を満たせません。確定前の判断と、確定後の通知を分ける組合せもあります。

注文確定後、複数の受信先がそれぞれ処理でき、途中の状態も追える

イベント連携を候補にできます。ただし、いつまで待てるか、未着や処理保留を誰が見つけるか、途中状態を業務画面などへどう示すかを先に決めます。ここで待ち時間の数値を一律には決めません。

一日分をまとめて照合すればよく、既存の連携で目的を満たしている

まとめて渡す方式を保つ選択もあります。通知先が増える可能性だけを理由に、運用や例外処理を含む仕組みを増やす必要はありません。頻度、欠落時の影響、担当者が追える範囲を比べます。

APIとイベント連携は、排他的な二択ではありません。APIはシステムが情報や処理をやり取りする窓口で、イベントの受渡しにAPIを使う構成もあります。APIの受付応答が即時に返っても、その後の在庫引当まで終わったとは限りません。通信の応答と業務結果を分けて比べます。項目の意味や応答を一つのAPIで確認する場合は、社内APIの仕様と必須IDを確かめる方法も参考になります。

「注文確定」の意味と、注文・出来事の識別を決める

どの状態になったら、何が起きたと知らせるか

業務担当は「注文を受け付けた」「注文を確定した」「在庫を引き当てた」「支払いを確認した」を区別して説明します。会社によって、注文確定という言葉に含む条件が異なるためです。発信の条件が曖昧なままでは、受け手が在庫確保済みや出荷可能と読み違えます。

この例では、知らせる事実を「注文確定」と置いています。しかし、支払いや引当まで済んでいるという情報はありません。実案件では受注担当と開発先に、どの記録がどの状態になったときに発信し、その知らせから何を推測してよいかを確認します。注文記録を確定することと、外へ知らせることの間で処理が止まった場合、未通知をどう見つけて回復するかも設計対象です。

注文を追う値と、一つの出来事を追う値を混ぜない

注文IDは、どの注文の話かを対応させるための値です。出来事IDは、その注文について起きた一つの出来事をほかの出来事から区別するための値です。同じ注文でも、注文確定、変更、取消など複数の出来事があり得ます。注文IDが同じという理由だけで、別の出来事を重複扱いにしません。

図と記録に出るorder-Aとevt-Aは、この対応を読むための架空の値です。メニュー名や作業名の代用ではありません。実際に何をIDへ使うか、どの範囲で一意か、再送で同じIDを保つか、訂正で新しい出来事を作るかは、開発先と取り決めます。

イベント情報の共通形式であるCloudEventsの参照版v1.0.2では、発生元を表すsourceとidの組合せで異なる出来事を識別します。同じ出来事の再送で同じIDを使うことも認めています。これは情報を見分ける規定であり、業務処理が一度だけ実行される保証ではありません。CloudEvents公式仕様のidとsource

この下書きは業務の読み合わせ用で、CloudEventsの送信形式そのものではありません。「受注側」という業務名を、そのまま仕様に適合するsourceの値と認定しません。形式を採用する場合は必須項目、値の型、版、任意項目を開発先が仕様に合わせて確認します。時刻も、発生時刻・送信時刻・受信時刻のどれかを明示し、受信した順が業務上の発生順だと決め付けないようにします。

在庫と配送で、受信・開始・完了の条件を別々に決める

在庫側：注文を受けた後、何を引き当てれば完了か

在庫担当は、対象商品、数量、扱う保管場所、注文の状態など、引当判断に必要な情報を説明します。これらは実務で確認する項目の候補であり、この架空記録に具体値があるという意味ではありません。情報を知らせに含めるか、必要な記録を参照するかも相談します。後から更新される記録を参照するなら、今回の出来事が起きた時点との違いをどう扱うかが問題になります。

受領の出口は、対象の知らせを受け付けた記録です。業務完了の出口は、対象注文のどの明細・数量を、どの条件で引き当てたかが確認できる状態です。一部だけ引き当てる場合、引当待ちにする場合、注文自体を止める場合を業務側が決めます。引当が完了していないという値だけで、欠品やプログラム障害と診断しません。

配送側：受領した時点で、準備を始めてよいか

配送担当は、届け先、対象商品・数量、配送条件、出荷保留の有無など、準備に必要な条件を示します。在庫引当や支払確認が前提なら、その状態をどこで確かめるかを決めます。注文確定の通知だけでは不足する場合、準備開始の条件を満たした別の事実を待つ、状態を確認して保留するなど、業務に合う方式を比べます。

「配送準備完了」は、何を終えた状態かまで定義します。伝票の作成、梱包、出荷可否の確認などの範囲は会社によります。準備完了を、発送済みや配達完了へ読み替えません。この例の配送準備の値は未取得で、実際にどこまで進んだかは分かりません。

全体：それぞれの証拠を、同じ注文へ対応させる

発信側の記録、在庫側の受領と引当、配送側の受領と準備を、同じ注文・出来事との対応で追えるようにします。受注担当へ何を表示するかも、各状態の意味に合わせます。片側の受領を全体の成功にまとめたり、受信記録のない側を失敗にしたりしません。

発信側、受信側、仕組みの運用側で調べられる範囲は異なります。誰が結果を照合し、保留の注文を業務担当へ返し、復旧判断をするかを決めます。この二つの記録では結果確認担当が未取得なので、担当者名を埋める前に役割と権限を確認します。相手と情報のまとまりの洗出しがまだなら、システム連携先と確認担当を整理する方法から始められます。

重複・片側だけの受領・順序の不明は、同じ復旧方法にしない

重複がある：何が重なり、どこまで更新したかを調べる

同じ知らせが複数回届く可能性を前提にする場合、出来事を区別する情報、処理中・完了・保留の状態、すでに起きた業務上の変更を調べる方法を決めます。「同じIDなら常に捨てる」だけでは、最初の処理が途中で止まった場合を説明できません。同時に届いた場合も含め、二重の引当や配送準備を防ぐ仕組みを開発先へ確認します。

冪等性は、同じ操作を繰り返しても、意図しない追加の影響を生じさせない性質です。IDを持つだけで実現するものではありません。重複の判定と実際の更新をどう対応させ、失敗や再開をどう扱うかまで必要です。外部サービスを含む場合は、その側の扱いも確認します。

片側の受領が分からない：未着と、記録を調べていない状態を分ける

配送側の受領が未取得なら、届いていないのか、届いたが照会できていないのかは分かりません。発信記録、配送側の受領・処理記録、中継する仕組みを使う場合はその記録を、同じ対象で照合します。調査が済む前に全受信先へ再送すると、すでに進んだ仕事へ追加の影響を与えるおそれがあります。

調査結果に応じて、未受領側だけへ渡せるか、処理途中から再開できるか、業務担当の判断が必要かを決めます。対象を限定する手段や、権限、手順が未確認なら、担当者が独断で本番を再実行しません。保留対象と次に確認する相手を残し、分かっている側の状況まで書き換えないことが大切です。

出来事の順序が分からない：先に届いた順で業務を進めない

注文確定の後に取消が起きるなど、同じ注文に関係する出来事を扱うなら、どの順序を守る必要があるかを業務側が説明します。別の届け方や経路を使う場合も含め、何を見れば古い知らせや前提不足を見分けられるかを開発先と決めます。時刻だけで並べ替えてよいとは限らず、版や状態の扱いも仕様次第です。

必要な前の出来事が見つからない場合、保留して照会する、現在状態を確認するなどの選択肢を比べます。「必ず順番どおり届く」「全イベントを一つにまとめれば解決」とは、この記録から言えません。二つの注文のIDが違うことを、同じ注文の修正履歴としてつなぐこともできません。

取り消す・元へ戻す：別の業務判断として決める

一方の仕事だけが完了した後で注文取消が必要になる場合、引当解除、準備の停止、すでに外へ依頼した仕事の扱いなどが問題になります。再送は、元へ戻す操作の代わりにはなりません。取消を受け付けられる状態、確認する担当、相手へ伝える結果を別途決めます。ここでは取消の実記録や復旧成功を追加しません。

図では、一つの知らせと二つの仕事の間を読む

図を原寸で確認する

二つの注文の違いを、同じ項目で読み比べる

最初の注文は、在庫の引当・配送側の受領・重複の有無が未確認です。別の注文は、引当未完了・配送側の受領あり・重複受信ありと明記されています。両方とも配送準備の結果は未確認です。二つは別注文で、修正前後ではありません。

質問の回答を、処理条件と例外時の判断へ反映する

質問を列挙するだけで終えず、回答によって何を変更するかまで決めます。次は開発先だけに丸投げせず、受注・在庫・配送の業務担当も交えて確認する項目です。

「注文確定」は、何を終えた状態ですか

受注担当へ状態の定義を聞き、開発先へ発信条件と記録の対応を確認します。引当前の確定なら、受信側に「在庫確保済み」を前提にさせません。引当後の事実が必要なら、発信する出来事や準備開始条件を見直します。

受信の記録と、引当・準備の結果は、何で同じ対象へ結び付きますか

各受信側の担当と開発先へ、注文・出来事との対応、照会方法、結果が分かる場所を確認します。受信しか追えないなら、業務完了の確認方法を仕様へ追加します。担当の役割と権限も合わせます。

重複時に、どの更新を繰り返さず、途中の仕事をどう扱いますか

開発先に判定の範囲と状態の扱いを確認し、業務側に二重更新の影響を確認します。処理中や一部だけ完了した場合の再開条件も決めます。IDの一致だけで完了扱い・破棄する仕様にはしません。

配送準備に必要な前提が、まだ届かない場合はどうしますか

配送担当と開発先に、待つ条件、確認する状態、保留の表示、再評価のきっかけを確認します。受領順を前提にできないなら、順序を調べる情報や前提確認を仕様へ反映します。業務上待てる期限と、超えた場合の窓口も決めます。

片側だけ進んだとき、誰が、どこまで回復できますか

運用側と各業務担当へ、調べられる記録、対象を限定した再送・再開の可否、取消や人の判断が要る範囲を確認します。回答がないまま再送を標準手順にせず、保留と連絡先を決めます。

知らせる項目や意味が変わるとき、受信側へどう伝えますか

発信側と受信側の開発先へ、変更の影響を受ける項目、版の区別、旧形式の扱い、切替時の確認を聞きます。「項目を足すだけ」でも受信側がどう扱うかを確かめます。必要以上の個人情報を広く配信せず、受け手ごとの必要性、権限、記録の保管も確認します。

回答は、出来事の定義、項目と意味、受信先ごとの開始・完了条件、例外時の判断、確認する役割へ反映します。未回答の条件は未回答と残し、決まった範囲の作業と混ぜません。変更があれば関係する受信先と読み合わせ、確認前の仮案を正式な運用手順として使わないようにします。

許可された試験で、一件の発信と二つの業務結果を照合する

仕様が説明できたことと、実際に動作を確認したことは別です。ここでは試験の組み立て方を示します。実施場所、使えるデータ、権限、復旧方法を担当者と決め、本番の注文を流したり、未確認の再送を試したりしません。

1. 一件の期待結果を先に合わせる。注文確定の条件、出来事と注文の対応、在庫側の受領・引当、配送側の受領・準備について、何を見てどこまでを合格とするかを決めます。業務上の保留が正しい場合は、保留と連絡先も期待結果にします。
2. 同じ対象を、発信から受信先ごとに追う。発信の記録、受領、業務結果を区別して記録します。受信ログがあっても引当や準備を確認していなければ、未確認のまま残します。別注文の結果を、今回の出来事の成功証拠に使いません。
3. 必要な例外を、安全な条件で確かめる。同じ知らせの再受領、処理途中、片側の遅れ、前提となる出来事がない場合など、今回の仕様に必要な条件を選びます。各条件で、二重の業務更新を防げるか、保留と照会が正しくできるかを確認します。製品の説明だけで実際の設定や処理結果まで合格にしません。
4. 期待と違う部分を、対象と状態で返す。どの注文・出来事について、どちらの受信先の、受領・処理中・完了・保留のどこが違うかを示します。原因と修正後の結果は調査してから記録し、試していない条件を合格へ加えません。
5. 運用へ渡す条件まで確かめる。未着や処理保留を見つける方法、担当者が結果を調べる導線、対象を限定した回復の権限と手順を読み合わせます。状態の意味や連絡先が変わったら仕様と運用の説明をそろえます。障害が起きてから誰が調べるかを決める状態を残さないようにします。

この架空例の引当未完了や未確認の項目は、試験の実結果ではありません。試験結果は、決めた条件・対象・確認方法と結び付けて別途確かめます。実施していない性能測定、配信保証、本番復旧や顧客への効果は、この記事では認定していません。

まとめ：知らせの到着と、各側の仕事の完了を分けて決める

イベント連携の仕様は、発信するデータの形だけでは完成しません。何が起きたという知らせか、どの時点で出すか、どの注文・出来事を追うかをそろえ、在庫と配送それぞれの開始条件、受信の証拠、業務完了の証拠、確認する役割を決めます。即時に業務結果が要る部分や、現行方式で目的を満たす部分も踏まえて方式を選びます。

重複、片側の状況、出来事の順序が不明な場合は、全体の完了や一括再送を推測で決めません。確認した結果に応じて、再開・保留・取消などの条件を仕様へ反映し、許可された試験で期待結果と実結果を照合します。