ルートの設計 - 承認経路の組み立て
このページでは、承認経路を組み立てる際に利用できるノードと、その選びかたを説明します。
ノード一覧
承認経路は、目的に応じたノードを配置して組み立てます。代表的なノードと、その利用シーンは次のとおりです。詳細は各セクションを参照してください。
| ノード | 概要 | 利用シーン |
|---|---|---|
 承認 | 設計時に決めた担当者が承認する基本ノード | 承認者があらかじめ決まっている |
 横配置 | 申請時に指定した複数人が順番に承認する | 人数や顔ぶれが申請ごとに変わる直列の承認 |
 縦配置 | 申請時に指定した複数人が同時に承認する | 人数や顔ぶれが申請ごとに変わる並列の承認 |
 動的承認 | 処理時に次の承認者をひとり指名、または承認を省略する | 承認者を進行中に決めたい、状況により省略したい |
 分岐開始／ 分岐終了 | 条件に応じて経路を選び、合流させる | 金額や種別などの条件でルートを切り替えたい |
 同期開始／ 同期終了 | 複数経路を並行で進め、全完了を待ち合わせる | 複数の担当者全員の承認を必須にしたい |
 テンプレート置換 | 事前に部品化したルートを案件開始時に展開する | 定型の承認パターンを複数ルートで再利用したい |
 確認 | フローの進行に影響を与えず、関係者へ内容を通知する | 承認は不要だが内容を知らせたい |
 システム | 人を介さず、登録したプログラムを自動実行する | 外部システム連携や自動処理を組み込みたい |
各ノードの詳細な設定方法については、以下のドキュメントを参照してください。
承認ノード：承認者を固定で設定する
承認ノードは、ルートを設計する時点で承認者を決めておく、もっとも基本的なノードです。「課長が承認する」「経理担当が承認する」のように、担当者があらかじめ決まっている場合に利用します。
以降で説明する動的なノードは、いずれもこの承認ノードを起点とした応用と考えると理解しやすくなります。承認者を固定できる場合は、まず承認ノードで組み立てることを基本とします。
承認ノードの処理対象者を指定なしのまま運用しても、そのノードが自動的にスキップされるわけではありません。処理対象者が決まらず、案件が進行できなくなる場合があります。承認を省略したい場合は、動的承認ノードの利用を検討してください。
承認者を動的に決める
承認者の人数や顔ぶれが申請ごとに変わる場合は、申請時や処理時に承認者を決定するノードを利用します。
横配置ノード：申請時に複数人を順番に指定したい
横配置ノードは、申請時に指定した複数の承認者が順番に（直列で） 承認するノードです。指定した人数だけ承認ステップが直列に展開されます。
承認者がひとりずつ順を追って確認する必要がある場合に適しています。
利用シーンの例
- 申請者が承認ルートに加える上長を、申請のたびに選びたい
- 関係部署の担当者を、案件に応じて順番に承認者として追加したい
縦配置ノード：並行して複数人の承認を集めたい
縦配置ノードは、申請時に指定した複数の承認者が同時に（並列で） 承認するノードです。指定した人数だけ承認ステップが並列に展開されます。
複数の承認者の承認を待ち合わせる必要がある場合に適しています。順番は問わず、全員の承認がそろった時点で次へ進みます。
利用シーンの例
- 複数の関係者から並行して承認を集め、処理時間を短縮したい
- 順序を問わず、関係者全員の合意を得たい
横配置ノード・縦配置ノードは、いずれも申請時に処理対象者を指定します。承認者の人数を、設計時ではなく実行時に決められる点が特徴です。
動的承認ノード：次の承認者をひとりだけ指名またはスキップしたい
動的承認ノードは、処理の進行中に次の承認者をひとり指名できるノードです。承認者をひとりだけ追加したい場合や、状況に応じて承認を省略したい場合に利用します。
横配置・縦配置ノードが「申請時に複数人を指定する」のに対し、動的承認ノードは「処理時にひとりを指名する、または省略する」点が異なります。
利用シーンの例
- 承認者がその場で次の確認者をひとり指名したい
- 条件によっては承認を省略し、次のノードへ進めたい
経路を分ける・並行させる
ここまでは、ひとつの経路を直線的にたどるノードを説明してきました。承認の経路を条件によって分けたい場合や、複数の経路を並行して進めたい場合は、専用のノードを利用します。
これらのノードは、いずれも経路の入口（開始）と出口（終了）がペアになっており、開始ノードから複数の経路を引き出し、終了ノードで再びひとつにまとめます。開始ノードと終了ノードは必ずセットで配置します。
分岐開始・終了ノード：条件で経路を選んで合流させたい
分岐開始ノードは、到達した時点で条件に応じて進む経路を選ぶノードです。分岐終了ノードは、選ばれた経路の処理状況を判定したうえで、後続の処理へ進むノードです。
金額や申請種別などの条件で承認ルートを切り替えたい場合に利用します。条件に合致した経路だけに進む（該当しない経路は進まない）のが基本的な動きです。
分岐開始ノードでの分岐方法は、以下から選びます。
| 分岐開始方法 | 概要 |
|---|---|
| 画面による分岐先の選択 | 申請者や承認者が、その場で進む経路を画面上で選ぶ |
| 分岐処理プログラムによる分岐先の選択 | ロジックフローやユーザプログラムで経路を判定する |
| ルール定義による分岐先の選択 | 申請内容（金額・種別など）を条件に照らし、自動で経路を選ぶ |
| 設定しない | 条件を判定せず、分岐内のすべての経路へ無条件に処理を進める（同期開始ノードと同じ動作） |
一方、分岐終了ノードで「いつ分岐を終わらせて次へ進むか」を判定する方法は、以下から選びます。
| 分岐終了方法 | 概要 |
|---|---|
| 結合処理プログラムによる判定 | ロジックフローやユーザプログラムで、分岐を終了させるかどうかを判定する |
| ルール定義による判定 | ルールの判定結果に応じて、分岐を終了させるかどうかを決める |
| 設定しない | 分岐内で到達しているノードがすべて処理済みになると、自動で分岐の外へ進む（同期終了ノードと同じ待ち合わせ動作） |
多くの場合は「設定しない」で十分です。分岐した経路がすべて処理されたら自動的に次へ進むため、特別な終了判定が不要ならルールやプログラムを設定する必要はありません。
利用シーンの例
- 支払金額が一定額未満なら課長承認、一定額以上なら部長承認へ振り分けたい
- 「通常申請」と「緊急申請」で承認ルートを変えたい
- 条件を満たす場合だけ、特定の承認ステップを追加または省略したい
分岐終了方法の補足
「設定しない」は、分岐したすべての経路の完了を待ってから合流する標準の動作です。条件を問わず全経路がそろえばよい場合は、「設定しない」で十分です。
一方、ルール定義や結合処理プログラムは、全経路の完了を待たずにビジネスルールで合流させたいときに設定します。次のような場合に利用します。
- 特定の経路の処理結果が出た時点で、早期に合流させたい
- いずれかの経路が完了したら、次へ進めたい（OR結合のような動作）
- 申請内容や処理状況に応じて、合流のタイミングを動的に制御したい
なお、分岐開始・終了ノードで「設定しない」を選ぶと、条件を見ずに分岐内のすべての経路へ並行して処理を進めます。この動作は同期開始・終了ノードと同じです。並行処理の詳しい動きと注意点は、後述の「同期開始・終了ノード」を参照してください。
ルール定義や結合処理プログラムで終了条件を設定すると、終了条件を一度も満たさない場合に、分岐終了ノードで案件が滞留します。このリスクは、終了方法を設定したときに特有のものです。「設定しない」では発生しません。
設計時には、どの分岐パターンでも終了条件が必ず成立するか、網羅性を検証してください。
案件が滞留したかどうかは、処理停止検出（分岐終了）ジョブによって後方のいずれのノードにも進めない案件が検出されます。検出後は、ワークフロー管理者権限を持つユーザが、監視画面や管理機能から対応します。
分岐開始・終了ノードの詳細については、以下のドキュメントを参照してください。
同期開始・終了ノード：複数経路を並行させ全完了を待ちたい
同期開始ノードは、到達した時点で後続のすべての経路へ同時に処理を進めるノードです。同期終了ノードでは、並行して進んだ経路がすべて完了するまで待ち合わせ、全経路がそろった時点で後続の処理に進む役割を担います。
複数の担当者や部署から、順序を問わず全員の承認を必須で集めたい場合に利用します。分岐開始ノードと違い、条件は一切見ず、つながっている経路すべてに無条件で進む点が特徴です。
利用シーンの例
- 上長・人事・経理など、複数の担当者全員の承認をそろえてから次へ進めたい
- 公開前に、法務・品質・セキュリティの担当者全員から確認を得たい
- 独立した複数のチェックを並行で実施し、処理時間を短縮したい
同期開始・終了ノードは、経路の組みかたによっては同期終了を完了できず、案件の進行が滞留することがあります。同期終了ノードは、内側のすべての経路が処理されてはじめて次へ進むためです。
滞留の発生条件
同期の内側に「一度も処理されない経路」が残ると起こります。たとえば、次の2本の経路を同期開始・終了ノードで並行させた場合を考えます。
- 経路1：承認ノードがあり、必ず処理される
- 経路2：分岐開始ノードと分岐終了ノードが直接つながり、処理されない
経路2は一度も処理されないため、同期終了ノードはこの経路の完了を待ち続けます。その結果、同期が完了せず、案件は次へ進めません。
同期の内側に分岐を組み合わせる場合は、各経路が必ず一度は処理されるように設計してください。滞留する経路パターンの詳細は、以下のドキュメントを参照してください。
テンプレート置換ノード：よく使うルートパターンを部品化して再利用したい
テンプレート置換ノードは、あらかじめ部品として作成しておいたルートを、案件の申請時に自動で展開（置換）するノードです。横配置・縦配置ノードが「承認者の人数」を実行時に展開するのに対し、テンプレート置換ノードはルートのまとまり（サブルート）全体を部品として再利用する点が異なります。
部品となるルートは、IM-Workflowのルート定義でテンプレート置換用のルート種類をあらかじめ作成しておきます。これは「テンプレート置換開始ノード」から「テンプレート置換終了ノード」までを一連のルートとしてまとめた、再利用可能な部品です。本体のルートにテンプレート置換ノードを配置し、展開するルートテンプレート定義を指定しておくと、申請時にその内容が自動的に展開されます。
ルート種類：テンプレート置換用
ルート種類：通常用
利用シーンの例
- 「一定金額以上は部長 → 本部長 → 役員」のような定型の承認ルートを部品化し、複数のルートで使い回したい
- 各部門で共通して使う承認パターンをテンプレート化し、変更時にはテンプレートの修正だけで全ルートへ反映させたい
- 大きなルートの一部（経理チェックなど）を部品として切り出し、ルート全体の見通しをよくしたい
ルート全体をテンプレートとして管理できるため、同じ承認パターンが複数のルートに現れる場合や、将来のルール変更に備えてメンテナンス性を高めたい場合に有効です。
テンプレートが展開されるのは申請時です。動的承認ノードのように処理の進行中に展開されるわけではありません。また、テンプレート置換ノードを、ルートテンプレート定義の中に配置することはできません。
ルートテンプレート定義の概要や設定方法については、以下のドキュメントを参照してください。
確認ノード：フローを止めずに関係者へ通知・確認させたい
確認ノードは、指定した対象者にタスクを通知し、内容を確認させるノードです。承認ノードと異なり、フローの進行には影響を与えません。確認ノードの対象者が確認したかどうかにかかわらず、フローはそのまま次のノードへ進みます。
承認の判断は不要だが、関係者に内容を知らせておきたい場合に利用します。
利用シーンの例
- 申請内容を関連部署へ周知したい
- 決裁済みの案件を、記録として担当者に確認させたい
確認ノードは通知・記録を目的としたノードであり、承認経路そのものを構成するノードではありません。フローを止めずに情報共有を行いたい場合に活用してください。
システムノード：外部システムと連携する・自動処理を組み込む
システムノードは、人間の承認者が存在しない唯一のノードです。承認が完了した後に外部システムへデータを送信したり、画面を介さない自動処理を実行したりする場面で利用します。
利用シーンの例
- 承認完了後に基幹システム（ERPなど）へ申請データを自動連携したい
- 外部のWeb APIを呼び出してデータを取得・更新したい
- 画面を介さずにバックグラウンドで後処理を実行したい
システムノードはノードに到達しても、自動で次のノードへは進みません。ノードに登録したプログラム側で、次のノードへ進める処理を明示的に実装する必要があります。「到達したら自動で完了する」と誤解しやすいため、注意してください。
システムノードに設定する処理は、IM-LogicDesignerなどで作成したプログラムとして登録します。