BPMNダイアグラム解説：実践的なビジネスプロセスガイド（2026年）

ビジネスプロセスが失敗するのは、人々が無能だからではありません。プロセスのドキュメント化が不十分で、チームによって異なる解釈がされているからです。BPMNはこの問題を解決するために存在しています。ビジネスアナリスト、開発者、経営者の誰もが読める、単一の標準化された表記法です。

円形、太い境界線、X印のゲートウェイを持つフローチャートを見たことがあるなら、BPMNに触れたことがあります。このガイドでは、それらのシンボルが何を意味するのか、BPMNがいつ複雑さに見合うのか、そして実際にコミュニケーションできるビジネスプロセス図を作成する方法について説明します。

BPMNとは？

BPMNはBusiness Process Model and Notation（ビジネスプロセスモデルと表記法）の略です。ビジネスプロセスをモデル化するためのObject Management Group（OMG）が管理する国際規格（ISO/IEC 19510）です。現行バージョンのBPMN 2.0は2011年にリリースされ、現在も支配的な標準として使用されています。

キーワードは表記法です。BPMNは、単なるプロセス図を描く一般的なアプローチではなく、精密なルールを持つ特定の視覚言語を定義しています。ドイツのコンサルタントが作成したBPMN図は、韓国の開発者にも同じ意味を持つはずです。

BPMN 2.0はXMLの相互交換フォーマットも定義しており、あるツールで作成されたBPMN図を別のツールにインポートできます。また、一部のツールではBPMN図を直接実行可能なワークフローとして実行できます。

BPMNと通常のフローチャートの比較

ほとんどのプロセスは基本的なフローチャートで文書化されます。BPMNはより構造化されており、より表現力豊かです。どちらを選ぶかは、対象者と目的によって異なります。

側面	通常のフローチャート	BPMNダイアグラム
標準	正式な標準なし	ISO/IEC 19510 (BPMN 2.0)
学習曲線	最小限 — 広く理解されている	中程度 — 表記法の学習が必要
イベントタイプ	開始/終了のみ	30以上のイベントタイプ（タイマー、メッセージ、エラー）
並列処理	表現が困難	組み込みの並列ゲートウェイサポート
複数の当事者	スイムレーンでは難しい	ネイティブプールとレーン
ツール実行可能	いいえ	はい（BPMSツール使用時）
最適用途	シンプルなプロセス、迅速なドキュメント化	複雑な組織横断プロセス、自動化
対象者	誰でも	ビジネスアナリスト、プロセスエンジニア

通常のフローチャートを使用する場合：

非技術的な対象者にプロセスを素早く説明する必要がある
プロセスが1人または1チームに内部的なものである
精度の要件が非公式である
実装のためのドキュメント化ではなく、スケッチをしている

BPMNを使用する場合：

プロセスが複数の部門または組織にまたがる
プロセスをワークフローエンジンで自動化または実装している
コンプライアンスが監査可能なプロセスドキュメントを要求する
開発者やBPMツールと精密にコミュニケーションする必要がある

BPMN 2.0のコア要素

BPMNには4つの主要な要素カテゴリがあります：フローオブジェクト、接続オブジェクト、スイムレーン、アーティファクトです。

イベント

イベントは何かが起こることを表します。円形で表示され、プロセスの開始、途中、または終わりに現れます。

  (  )         (  ●  )        (  ×  )
 開始          メッセージ      終了
 イベント      開始            イベント（終端）

開始イベント（細い境界線の円）はプロセスをトリガーします：

通常の開始：プロセスが手動またはオンデマンドで開始
メッセージ開始：受信メッセージによってトリガーされるプロセス
タイマー開始：スケジュールに基づいてトリガーされるプロセス

中間イベント（二重境界線の円）はプロセス中に発生します：

メッセージ中間：プロセス途中でメッセージを送受信
タイマー中間：継続前に特定の時間を待つ
エラー中間：サブプロセスからのエラーをキャッチ

終了イベント（太い境界線の円）はプロセスを完了します：

通常の終了：プロセスが正常に終了
メッセージ終了：メッセージを送信してプロセスが終了
終端終了：プロセス内のすべてのアクティビティを即座に停止

アクティビティ

アクティビティは実行中の作業を表します。角が丸い長方形で表示されます。

タスクは作業の原子単位です—それ以上分解できない単一のステップ：

┌─────────────────────┐
│   請求書を確認する   │
└─────────────────────┘

タスクの種類は左上のアイコンで示されます：

ユーザータスク：人が作業を実行
サービスタスク：システムが自動的に作業を実行
スクリプトタスク：スクリプトまたはルールエンジンが実行
手動タスク：ソフトウェアの支援なしに実行

サブプロセスには内部にネストされたプロセスが含まれます：

┌─────────────────────┐
│  支払いを処理する   │
│          [+]        │
└─────────────────────┘

[+]マーカーは、内部の詳細が非表示になった折りたたまれたサブプロセスを示します。展開すると内部のステップが表示されます。

ゲートウェイ

ゲートウェイは、シーケンスフローの分岐や合流を制御します。ひし形で表示されます。

排他ゲートウェイ（XOR） — 条件に基づいて1つのパスのみが取られます：

       ┌─────────────────┐
       │  残高確認       │
       └────────┬────────┘
                ↓
            ◇ XOR ◇
           ╱         ╲
      [十分]        [不十分]
          ↓               ↓
    ┌──────────┐    ┌──────────────┐
    │ 承認     │    │ ローン拒否   │
    └──────────┘    └──────────────┘

並列ゲートウェイ（AND） — すべてのパスが同時に実行されます：

            ◇ AND ◇
           ╱   |   ╲
          ↓    ↓    ↓
      メール  DB   チーム
      送信   更新  通知

ステップが並行して実行できる場合に使用します。対応する閉じゲートウェイは、すべてのパスが完了するまで待機してから継続します。

包括ゲートウェイ（OR） — 条件に基づいて1つ以上のパスが実行されます：

            ◇ OR ◇
           ╱       ╲
    [高優先度]   [任意の注文]
          ↓               ↓
    マネージャーに   チケット
    エスカレート     ログ

包括ゲートウェイはすべての条件を評価します。trueと評価された条件はすべてアクティブなパスを作成します。

シーケンスフロー

シーケンスフローは、プール内の要素を接続する矢印です。アクティビティの順序を示します。

通常のフロー： 実線の矢印
デフォルトフロー： ソース端にスラッシュが付いた矢印（他の条件が適用されない場合に使用）
条件付きフロー： ソース端にひし形が付いた矢印（条件がtrueの場合のみ使用）

プールとレーン

プールはプロセスを実行する参加者を表します（組織、システム、または役割）。レーンはプールを内部の役割や部門に細分化します。

┌─────────────────────────────────────────────────────────┐
│ プール：注文フルフィルメントプロセス                      │
│  ┌──────────────────────────────────────────────────┐  │
│  │ レーン：営業                                       │  │
│  │  (開始) → 注文受付 → 在庫確認                    │  │
│  └──────────────────────────────────────────────────┘  │
│  ┌──────────────────────────────────────────────────┐  │
│  │ レーン：倉庫                                       │  │
│  │  商品ピッキング → 梱包 → 出荷                     │  │
│  └──────────────────────────────────────────────────┘  │
│  ┌──────────────────────────────────────────────────┐  │
│  │ レーン：財務                                       │  │
│  │  請求書発行 → 支払い回収                          │  │
│  └──────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────┘

主要ルール：

1つのプール = 1人のプロセス参加者
レーンは参加者を役割に細分化する（別々の参加者ではない）
シーケンスフローは同じプール内の要素を接続する
メッセージフローは異なるプール間の要素を接続する（破線の矢印）

BPMNがやりすぎな場合

BPMNは強力ですが重い仕様です。デフォルトとして使用すると、利益なく摩擦が増えます。

BPMNをスキップする場合：

チームの短い会話のためにプロセスをドキュメント化している
プロセスのステップが10未満で参加者が1人
対象者がBPMN表記法に慣れていない（混乱を招くだけ）
プロセスが探索的で大幅に変更される可能性が高い

BPMNが必要な場合：

プロセスがワークフローエンジン（Camunda、Activiti、jBPM）で実装される
複数の組織がプロセスの責任について正式に合意する必要がある
コンプライアンスがISO標準のドキュメントを要求する
プロセスに複雑な並列実行パスが含まれる
システムを統合し、メッセージ交換を正確にドキュメント化する必要がある

ステップバイステップ：BPMNダイアグラムの作成

ステップ1：プロセスのスコープを定義する

プロセスに名前を付け、境界を設定します：

プロセスを開始するイベントは何ですか？
終了イベントは何ですか？（異なる結果に対して複数の終了イベントがある場合があります）
どの参加者がプロセスを所有していますか？

ステップ2：参加者を特定する

関係するすべての当事者をリストアップします：

どの役割や部門がアクティビティを実行しますか？
どの外部システムが情報を送受信しますか？
どの当事者が外部（別々の組織）ですか？

参加者ごとに1つのプールを作成します。外部の当事者が通知を受け取るだけの場合、内部の詳細がないブラックボックスプールとして表示されます。

ステップ3：ハッピーパスを最初にマップする

例外を追加する前に、通常の成功したフローを図示します：

開始イベントを配置する
アクティビティを順番に追加する
シーケンスフローで接続する
終了イベントを追加する

これにより、構築するための作業スケルトンが得られます。

ステップ4：判断ポイントを追加する

プロセスが分岐するすべての場所を特定します：

どの条件がどのパスを取るかを決定しますか？
パスは相互に排他的（XOR）ですか、それとも複数が発火できますか（OR）？
ステップは並列に実行できますか（AND）？

適切なゲートウェイタイプを配置し、各発信フローに条件のラベルを付けます。

ステップ5：例外とエラーを処理する

中間エラーイベントと例外パスを追加します：

タスクが失敗した場合はどうなりますか？
どのタイムアウトが存在しますか？
どの外部イベントがプロセスを中断できますか？

ステップ6：プール間にメッセージフローを追加する

複数のプールが存在する場合、参加者間でどの情報が渡されるかを示す破線のメッセージフロー矢印を描きます。

ステップ7：ステークホルダーとレビューする

実際のプロセス参加者と図を確認します。質問します：

これは理想ではなく、実際に何が起こるかを反映していますか？
アクティビティは正しいレーンに配置されていますか？
ゲートウェイは判断ロジックを正しく表現していますか？

実際の例：注文処理

┌─────────────────────────────────────────────────────────────────────────┐
│ プール：Eコマース注文プロセス                                             │
│  ┌───────────────────────────────────────────────────────────────────┐  │
│  │ レーン：カスタマーサービス                                          │  │
│  │  (開始) → 注文受付 → 確認送信                                    │  │
│  └───────────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────────┐  │
│  │ レーン：在庫管理                                                   │  │
│  │  在庫確認 → ◇XOR◇ → [在庫あり] → 商品確保                      │  │
│  │                     → [在庫なし] → 顧客通知 → (終了)             │  │
│  └───────────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────────┐  │
│  │ レーン：決済                                                       │  │
│  │  支払処理 → ◇XOR◇ → [成功] → 確認                              │  │
│  │                    → [失敗] → 顧客通知 → (終了)                  │  │
│  └───────────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────────┐  │
│  │ レーン：フルフィルメント                                           │  │
│  │  商品ピッキング → 注文梱包 → 出荷 → [タイマー：3日] → (終了)    │  │
│  └───────────────────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────────────────┘

この図が示していること：

複数の例外パス（在庫なし、決済失敗）
出荷追跡のためのタイマーイベント
明確なレーン責任と可視的な引き継ぎ

よくあるBPMNの誤り

ゲートウェイの誤使用。 ステップが実際に並列で実行されているのにXORゲートウェイを配置する、またはその逆。ゲートウェイのタイプは実際の実行ロジックに一致しなければなりません。

並列ゲートウェイを閉じるのを忘れる。 AND分割には対応するAND結合が必要です。並列パスが開いたまま合流しなければ、プロセスが完了しないことを意味します。

すべてを1つのプールに入れる。 別々の組織や外部システムは別々のプールであるべきで、レーンではありません。レーンは1人の参加者内の内部役割のためのものです。

BPMNシンボルを使いすぎる。 すべての図に中間イベント、補償マーカー、イベントサブプロセスが必要なわけではありません。シンプルに始め、実際のプロセス動作を反映する場合のみ複雑さを追加します。

抽象化レベルの混在。 あるレーンが高レベルの「申請処理」を示し、別のレーンが12の詳細なサブステップを示す。すべてのレーンを同じ詳細レベルに保つか、サブプロセスを使用して詳細を折りたたみます。

ゲートウェイのフローにラベルがない。 ゲートウェイから出るすべてのシーケンスフロー（デフォルトを除く）には条件のラベルが必要です。ラベルのない分岐は、各パスがいつ実行されるかについて曖昧さを生み出します。

FlowavaでBPMNダイアグラムを作成する

BPMNダイアグラムは手動での作成が著しく遅い—シンボルを正確に配置し、要素を整列させ、複雑なゲートウェイロジックを配線するのに専用ツールでも時間がかかります。

FlovovaのBPMNダイアグラムジェネレーターを使用すると、ビジネスプロセスをプレーンテキストで説明し、洗練できる構造化された図を生成できます。これは特に、プロセスの説明から初期図を作成したり、既存のドキュメントを視覚的な形式に変換したりするのに役立ちます。生成後、エディター内でゲートウェイのタイプを調整し、レーンを追加し、例外パスを接続できます。

まとめ

BPMNは精度が重要な場合の適切なツールです：複数の当事者が関わるプロセス、ワークフローの自動化、コンプライアンスのドキュメント化。内部コミュニケーションとシンプルなプロセスには、通常のフローチャートの方が速く理解しやすいです。

BPMNを使用する場合は、ハッピーパスから始め、ゲートウェイのタイプを正確に設定し、レーン構造を理想的な組織図ではなく実際の組織の境界に合わせます。