📝 序論：精密な B2B 相互作用のオーケストレーション

.

1. 図の概要

これはBPMN 2.0 コーディネーション図で、タイトルは「機能リクエストの送信」であり、2 つの参加者間の相互作用をモデル化しています。

参加者	役割
参加者 1 – クライアント	機能リクエストを開始し、代替案を検討し、最終的な承認を与える
参加者 2 – ベンダー	リクエストを受信し、実現可能性のチェックを行い、代替案を提案し、正式に承認し、計画を立てる

この図はまた、サブコリグラフィー: 「代替機能のレビュー (MI)」 — 代替機能が提案された際に使用されるマルチインスタンスサブプロセス。

コリグラフィー図はコリグラフィータスクで構成され、各タスクには少なくとも2つの参加者（開始者および非開始者）が必要です [[4]]。

---

2. ステップバイステップの工程解説

フェーズ1：開始

[開始イベント] → [機能リクエストの送信]

• ベンダークライアントは、正式な機能リクエストをベンダーに送信します。ベンダー.

• これは、メッセージ封筒アイコンを備えたコリグラフィータスクとして表され、参加者間の通信を示しています。

フェーズ2：実現可能性チェック（XORゲートウェイ）

[XORゲートウェイ：実現可能性チェック？]
   ├── 不可能（再提出）→ [機能リクエストの送信] にループ
   ├── はい → 先に進む
   └── 代替案が提供された → 「代替機能のレビュー (MI)」をトリガー

• ベンダーベンダーは、要求された機能が実現可能かどうかを評価します。

• 3つの可能な結果が存在しますが、各インスタンスでは1つのパスのみが選択されます。これがXORゲートウェイの定義的な特徴です [[13]]。

• もし実現不可能の場合、フローは再提出のためにループします（これは古典的なリトライパターンです）。

• もし実現可能（「はい」）の場合、プロセスはベンダー承認に向けて続行されます。

• もし代替案が提供された場合、マルチインスタンスサブプロセスがトリガーされます。

フェーズ3A：追加情報の要求（並列/オプションブランチ）

[情報要求] ↔ [応答要求]

• 最終承認のいずれの時点においても、双方は追加情報の要求を行うことができます。

• これは、ベンダーとクライアント間の双方向の協調タスクとしてモデル化されています。

フェーズ 3B: 代替機能のレビュー（マルチインスタンスサブプロセス）

[代替機能のレビュー III] ← MI マーカー
         ↓
[応答待ち] ← MI マーカー

• 代替案が提案されると、双方はマルチインスタンスループ— これは、レビューと待機のサイクルが各代替オプションに対して繰り返されることを意味します。

• マルチインスタンスアクティビティは、コレクション内の各要素に対して一度ずつ実行され、for-eachループに類似しています [[8]]。

• サブプロセスからメッセージエンベロープへの点線矢印は、各反復における非同期メッセージ交換を示しています。

フェーズ 4: ベンダーによる最終承認（XOR ゲートウェイ）

[XOR ゲートウェイ：ベンダーによる最終承認？]
   ├── いいえ → 再評価 → MI サブプロセスにループバック
   └── はい → 正式に承認し、計画する

• すべての代替案がレビューされた後（または代替案が必要なかった場合）、最終的な意思決定ゲートに到達します。

• 拒否された場合、プロセスはマルチインスタンスレビューループに再進入し、反復的な改良を可能にします。

• 承認された場合、プロセスは正式な承認に進みます。

フェーズ 5: 正式な承認と完了

[正式に承認し、計画する] → [確認メッセージ] → [終了イベント]

• ベンダーはベンダー機能を正式に承認し、実装計画を作成します。

• 確認メッセージがクライアント.

• 太い枠で囲まれた円は終了イベントを示しており、プロセスの成功した完了を意味します。

例外パス：キャンセル

[XOR ゲートウェイ] → [ベンダー、機能リクエストのキャンセル] → [終了イベント]

• 実現可能性チェックの段階において、ベンダーは一方的にリクエストを完全にキャンセルし、プロセスを直ちに終了させることができます。

---

3. 主要な BPMN 概念の解説

3.1 コーディネーションタスクとコラボレーションタスクの比較

概念	説明
コーディネーションタスク	示すのはメッセージの交換参加者間です。各タスクには、タスク矩形上に色付きの帯として示された開始者と応答者が含まれます。
コラボレーション図	各参加者ごとに独立したプール/レーンを使用し、内部プロセスロジックに焦点を当てます。
コーディネーションの適用タイミング	主たる関心が誰が誰と通信するか内部ステップではなく、である場合

コーディネーション図では、各タスクには少なくとも 2 つの参加者（開始者と非開始者）が必要です [[4]]。

3.2 XOR（排他的）ゲートウェイ

• ダイヤモンドの中に「X」が入った形で表されます。

• 条件または意思決定に基づいて1 つの出力パスが選択されます [[16]]。

• ここでは、実現可能性チェック、最終的なベンダーの受諾、およびキャンセル分岐という 3 つの重要な意思決定ポイントで使用されています。

• ベストプラクティス：出力シーケンスフローには常に明確な条件をラベル付けしてください [[14]]。

3.3 マルチインスタンス（MI）マーカー

• 3 つの縦線（|||) タスク/サブプロセスボックスの下部に配置されます。

• このアクティビティが並列または順次で複数回実行されることを示しますコレクション内の各項目に対して行われます [[9]]。

• この図では、これは「代替機能のレビュー」と「応答の待機」の両方に適用され、各代替案がレビューと応答のサイクルを独立して完了することを意味します。

• これはビジネスプロセスレベルのforeachループと考えることができます [[12]]。

3.4 メッセージイベントとエンベロープ

• シーケンスフロー上のエンベロープアイコンは非同期メッセージの送受信が参加者間で行われることを示します。

• 「提案」「依頼」「確認」などのメッセージは、組織の境界を越える明示的な成果物です。

• メッセージエンベロープを表示することで、通信契約を可視化し監査可能にします [[2]]。

3.5 終了イベント（強制終了）

• 「機能リクエストのキャンセル」の後に続く、太い境界線を持つ実心の黒い円は強制終了イベントです.

• これはすべてのアクティブなプロセスインスタンスを即座に終了します（現在のトークンだけでなく）— 強制キャンセルに有用です。

---

4. この種類の図をいつ使用するか

✅ 理想的な使用例

シナリオ	なぜチャートグラフィ（協調）が適しているか
B2B 統合プロセス	組織間のメッセージ契約を明確に示します
ベンダーとクライアントのオンボーディングワークフロー	交渉、提案、承認のサイクルをモデル化します
SLA に基づくサービスリクエスト	応答義務とエスカレーション経路を明確にする
規制・コンプライアンス文書	誰が何をいつ伝達したかの監査可能な証拠を提供する
API/サービスオーケストレーション設計	メッセージベースのマイクロサービス間相互作用に直接マッピングされる
契約ワークフロー定義	各コリオグラフィタスクは拘束力のある通信義務を表す

❌ コリオグラフィを使用すべきでない場合

シナリオ	より良い代替案
社内部門プロセス	レーン付き標準 BPMN 共同作業図
純粋に単一当事者の逐次ワークフロー	シンプル BPMN プロセス図
データ変換パイプライン	DMN 意思決定テーブルまたは ETL 図
リアルタイムイベントストリーミングアーキテクチャ	CQRS/イベントストームリング記法

---

5. ガイドラインとベストプラクティス

モデリングガイドライン

1. 1 ページに収める — 1 ページに収まる上位レベルの図を目指し、詳細は折りたたみサブプロセスに格納する [[6]]。

2. すべてのゲートウェイ出力にラベルを付ける — XOR ゲートウェイの分岐をラベルなしにしないこと；曖昧さは実装エラーの原因となる [[14]]。

3. 一貫した参加者順序を使用する — 可読性を保つため、すべてのタスクで同じ参加者を同じ帯位置（上/下）に維持する [[2]]。

4. コリオグラフィタスクは動詞句として命名する — 例：「機能リクエストを送信」であり、「機能リクエスト」ではない；アクションは開始者に属する。

5. メッセージ名を明示的に表示する — すべてのメッセージフローは名前付きアーティファクトを伴うべきであり、実装者がペイロード契約を理解できるようにする [[2]]。

6. メッセージフローの交差を避ける — 視覚的な混乱を最小限に抑えるためにタスクを再配置します。線の交差は認知的負荷を大幅に増加させます。

マルチインスタンスのヒント

7. コレクションを明確に定義する — 文書化またはモデル注釈において、反復を駆動するものを明確に指定します（例：「代替機能のリスト」）。

8. 並列とシーケンシャルのどちらを選択するか決定する — 並列 MI はすべてのインスタンスを同時に実行します。シーケンシャル MI はそれらを一度に一つずつ処理します。リソース制約と依存関係の要件に基づいて選択してください [[12]]。

9. 複雑な MI 本体には呼び出しアクティビティを使用する — マルチインスタンス本体が複雑な場合、保守性を高めるためにそれを独立した呼び出し可能なサブプロセスに抽出してください [[11]]。

ゲートウェイのヒント

10. XOR 分岐には排他的な条件が必要 — 2 つ以上の出力条件が同時に真になることがないようにしてください。そうしないとモデル化の欠陥が生じます [[18]]。

11. XOR 結合はトークンを同期する — XOR 結合はちょうど 1 つの入力トークンを待ちます。複数のトークンが到着することはモデル化エラーを意味します [[17]]。

12. デフォルトフローを検討する — 分岐する XOR ゲートウェイでは、条件に一致しない場合を処理するために、1 つの出力フローをデフォルトとしてマークしてください [[15]]。

一般的なヒントとコツ

13. 双方の利害関係者で検証する — チェオグラフィは組織にまたがるため、署名を得る必要があります。双方の — 実装前にクライアントチームとベンダーチームの両方からの承認を得てください。

14. 具体的なメッセージ形式に早期にマッピングする — 各メッセージエンベロープは、実際の API 呼び出し、メールテンプレート、または EDI トランザクションにマッピングされるべきです。

15. チェオグラフィ図のバージョン管理を行う — B2B 契約は進化します。SLA 文書とともに図のバージョンを追跡してください。

16. チェオグラフィ適合性チェックを使用する — 実際の実装がモデル化されたチェオグラフィに適合していることを確認するためのツールが存在します [[5]]。

17. 例外パスを徹底的にテストする — 「実行不可能 → 再提出」および「再評価 → ループバック」パスは、実際の現場で最も多くの失敗が発生する場所です。これらがハッピーパスと同様に厳密にテストされることを確認してください。

18. タイムアウト/エスカレーションルールを文書化する — 「応答待ち」MI タスクには定義された SLA（サービスレベル合意）があるべきです。応答が決して届かない場合の処理を文書化してください。

---

6. 実装マッピング

BPMN 要素	典型的な技術的実装
機能リクエストの送信	REST API POST / SOAP 呼び出し / メールトリガー
実現可能性チェック XOR	ビジネスルールエンジン / DMN 意思決定テーブル
追加情報の要求	双方向メッセージキュー / チャット統合
代替機能のレビュー（MI）	代替配列に対する非同期コールバック付きの for-each ループ
応答待ち（MI）	インスタンスごとのタイムアウトハンドラーを備えたメッセージ相関
最終ベンダー受入 XOR	承認ワークフローエンジン / 人間タスクシステム
正式に承認し、計画する	ERP/WMS 統合 + 通知配信
確認メッセージ	Webフック / メール / プッシュ通知
キャンセル（終了）	プロセス中止 API + 補償ロジック

---

7. 避けるべき一般的な落とし穴

落とし穴	結果	予防策
XOR でのデフォルトフローの欠落	条件が一致しない場合にプロセスが停止する	常にデフォルトの出力シーケンスフローを定義する [[15]]
ラベルなし MI コレクション	開発者は、イテレーションを駆動する要因を理解していない	モデルプロパティにコレクションソースを注記する
非対称な参加者バンド	各タスクを誰が開始するのかという混乱	[[2]]全体で一貫したバンド順序を維持する
内部ロジックに対してチャレオグラフィを過剰に使用すること	図が読めなくなる	チャレオグラフィは境界を跨ぐ通信にのみ使用する
終了セマンティクスを無視する	キャンセル時の部分的なクリーンアップ	終了パスに対する補償アクションを文書化する
応答待機にタイムアウトがない	ゾンビプロセスインスタンス	すべての待機状態に SLA ベースのタイマーを定義する

---

✅ 概要とツール推奨事項：Visual Paradigm BPMN と AI でモデリングを加速する