kintoneプロセス管理の条件分岐設計｜金額・部門・担当者で分ける方法

kintoneのプロセス管理では、フィールドの値を条件にして、表示するアクションを切り替えられます。

たとえば、申請金額が10万円未満なら課長承認、10万円以上なら部長承認にする。

申請種別が契約なら管理部門確認へ回す。

部門ごとに承認者を変える。

承認コメントが入力されているときだけ、承認ボタンを表示する。

このような条件分岐は、プロセス管理の実務ではよく使います。

ただし、条件を増やすほど、次の問題が出ます。

• どの条件が優先されるのか分からない
• 金額、部門、申請種別、リスク度が重なり、承認ルートを説明できない
• 条件に使うフィールドの入力揺れで、想定外のルートへ進む
• 例外対応のために分岐を追加し続け、テストケースが膨らむ
• 部門変更や承認者変更のたびにプロセス管理の設定を触る
• 差し戻し後に金額や種別を変えたとき、再承認が必要か分からない
• 通知が増え、誰が次に動くべきか分からない
• 承認者が人名固定になり、異動や退職で止まる

条件分岐は、設定項目ではなく業務ルールです。

だから、kintoneの画面で条件を入れる前に、分岐する理由を整理する必要があります。

kintoneプロセス管理の条件分岐は、「設定できる条件」を並べるのではなく、「判断者や確認内容が本当に変わる条件」だけに絞って設計します。

この記事では、kintoneプロセス管理で条件分岐を作るときに、金額、部門、申請種別、担当者、複数承認、スキップ、差し戻し、承認者マスタ、テストケース、変更管理をどう整理するかをまとめます。

kintoneプロセス管理の設計方法はこちら
kintone承認フローの設計方法はこちら

先に結論：条件分岐は少ないほど強い

条件分岐を設計するときは、まず次の4つに絞って考えます。

分岐軸	変わるもの	例
申請種別	見るべき観点	経費、購買、契約、休暇、稟議
金額	承認権限	10万円未満、10万円以上、100万円以上
部門	予算責任者	営業部、管理部、開発部
リスク度	追加確認者	個人情報、契約、支払、外部公開

すべての条件をプロセス管理の分岐にする必要はありません。

入力必須にすればよいもの。

一覧で確認すればよいもの。

通知だけで足りるもの。

承認者マスタで吸収した方がよいもの。

別アプリや別フローに分けた方がよいもの。

これらを分けずに、全部をアクション条件で表現すると、承認ルートがすぐに読めなくなります。

kintone公式ヘルプでは、アクションが実行できる条件を設定すると、フィールドの値に応じて必要なアクションだけを表示できると説明されています。例として、申請金額に応じて課長承認と部長承認のボタンを切り替える形が紹介されています。

kintoneヘルプ：アクションが実行できる条件の設定

この機能は便利です。

ただし、機能で分岐できることと、業務上分岐すべきことは別です。

設計時は、次の表に落とします。

条件	分岐にするか	理由
金額が10万円以上	する	承認権限が課長から部長に変わる
申請種別が契約	する	管理部門の確認が必要
添付資料がない	分岐ではなく入力制御	進める前に不足を防ぐ
申請理由が短い	分岐ではなくレビュー観点	機械的に判断しづらい
担当者が不在	分岐ではなく代理ルール	状況依存で変わる
重要顧客	ケース次第	定義が曖昧なら運用で崩れる

分岐条件を考えるときは、「その条件によって、誰が、何を判断するのか」が言えるものだけを残します。

言えない条件は、分岐ではなく入力チェック、一覧、通知、運用ルールに逃がします。

条件分岐で使う項目を先に固定する

条件分岐は、フォーム項目の品質に依存します。

金額で分けたいなら、どの金額を見るのかを固定します。

部門で分けたいなら、部門が選択式で安定して入力される必要があります。

申請種別で分けたいなら、種別の選択肢を増やしすぎない方がよいです。

項目	条件に使う前に決めること	崩れる例
申請種別	選択肢の粒度、追加ルール	「その他」が多すぎる
金額	税込、税抜、合計、明細合計	画面上の金額と承認基準が違う
部門	申請者部門か費用負担部門か	兼務や代理申請でずれる
承認者	人名固定か、フィールド参照か	異動時に設定変更が漏れる
リスク度	誰が分類するか、選択肢の意味	主観で高・中・低が変わる
添付有無	必須にするか、条件にするか	添付ファイルを条件にできない

特に注意したいのは、添付ファイルです。

kintoneのアクション条件では、指定できないフィールドがあります。公式ヘルプでは、文字列複数行、リッチエディター、ラベル、添付ファイル、関連レコード一覧などは条件に指定できないとされています。

そのため、「見積書が添付されている場合だけ承認へ進める」という条件をそのまま標準のアクション条件だけで作れるとは考えない方がよいです。

添付を必須にしたいなら、添付済みチェック項目を置く、申請前レビューを入れる、JavaScriptやプラグインの対象にする、運用ルールとして一覧で確認するなど、別の手段を検討します。

条件分岐で一番危ないのは、条件そのものではなく、条件に使うフィールドの定義が曖昧なことです。金額、部門、種別、承認者の意味を先に固定します。

金額で分ける承認ルート

金額分岐は、最も分かりやすく、最も揉めやすい分岐です。

10万円未満は課長承認。

10万円以上は部長承認。

100万円以上は役員承認。

このようなルールはよくあります。

ただし、金額分岐では境界を曖昧にしないことが重要です。

決めること	例
判定金額	税抜合計、税込合計、申請合計、明細合計
境界値	99,999円以下、100,000円以上
金額変更時	差し戻し、再申請、再承認のどれにするか
明細が複数ある場合	明細合計で見るか、品目ごとに見るか
追加条件	高額かつ契約ありなら管理部門確認を入れる

金額の境界値は、表で書くと事故を減らせます。

条件	アクション	次のステータス	作業者
100,000円未満	課長承認へ回す	課長承認待ち	申請者の上長
100,000円以上、1,000,000円未満	部長承認へ回す	部長承認待ち	部門長
1,000,000円以上	役員承認へ回す	役員承認待ち	役員、管理部門

ここで「100,000円はどちらか」が曖昧だと、設定者ごとに条件がずれます。

また、金額分岐を作るだけでは不十分です。

申請後に金額を変更できるなら、承認ルートが変わる可能性があります。

そのため、金額を変更したら差し戻し状態へ戻す、承認済み後は金額を編集できないようにする、重要項目を変更したら再申請にする、といったルールも必要です。

kintoneワークフローの作り方でも触れたように、ワークフローはボタンだけではなく、フォーム項目、権限、一覧、テストを合わせて作ります。

部門・申請種別で分ける承認ルート

部門や申請種別で承認ルートを分ける場合は、条件を増やしすぎないことが重要です。

たとえば、次のような分岐はよくあります。

申請種別	追加確認者	理由
経費	経理	科目、証憑、支払条件を確認する
購買	総務、購買担当	発注、納品、在庫を確認する
契約	管理部門、法務	契約条件、責任範囲を確認する
外部公開	広報、情報管理担当	公開範囲、表記、情報管理を確認する
個人情報を扱う作業	情報管理担当	取扱ルールを確認する

一方で、部門ごとにすべて別ステータスを作ると、設定が膨らみます。

営業部承認待ち。

管理部承認待ち。

開発部承認待ち。

人事部承認待ち。

経理部承認待ち。

部門が増えるたびにステータスやアクションを増やす設計は、組織変更に弱いです。

できれば、ステータス名は「部門承認待ち」にし、作業者を部門や承認者フィールドで変える設計を検討します。

設計	向いているケース	注意点
部門ごとにステータスを分ける	部門ごとに後続処理が大きく違う	ステータスが増えやすい
ステータスは共通、作業者だけ変える	承認の意味は同じで承認者だけ違う	承認者の決め方を整える
申請種別で別アプリに分ける	フォーム項目も承認観点も違う	横断集計を設計する
承認者マスタで決める	部門や金額で承認者が変わる	マスタの保守責任が必要

部門ごとに判断内容が同じなら、分岐は最小限でよいです。

判断内容が違う場合だけ、ステータスやフローを分けます。

部門ごとに承認者が違うだけなら、ステータスを増やすより、作業者の決め方や承認者マスタを整える方が保守しやすいです。

複数承認者のAND/OR設計

条件分岐と同じくらい重要なのが、複数承認者の設計です。

複数人を作業者にしたとき、「全員が承認する」のか「誰か1人が承認する」のかで、業務上の意味は大きく変わります。

kintone公式ヘルプでは、複数のユーザーや組織を作業者として設定する場合に、次のユーザーから作業者を選択、次のユーザー全員、次のユーザーのうち1人といった指定方法があると説明されています。

kintoneヘルプ：作業者の設定

実務では、次のように使い分けます。

型	意味	向いている場面
誰か1人	候補者のうち1人が代表して処理する	当番制、チーム内確認、軽微な承認
全員	指定された全員が確認する	経理と管理部門など観点が違う確認
作業者を選択	前段の作業者が次の担当を選ぶ	案件ごとに担当者が変わる
直列承認	一次、二次、最終の順に進む	決裁権限が段階的に上がる
並列確認	複数部門が同時に確認する	期限を短くしたい合議

ここで大事なのは、全員承認を安易に増やさないことです。

全員承認は、確認漏れを減らします。

一方で、止まりやすくなります。

誰か1人承認は、速く進みます。

一方で、誰が判断しても同じ品質になるルールが必要です。

承認者が複数いるときは、次のように判断の責任を分けます。

確認者	見ること	全員承認にする理由
上長	業務上の必要性	現場判断が必要
経理	支払、科目、証憑	会計処理が必要
管理部門	規程、契約、個人情報	会社ルールとの整合が必要
情報管理担当	アカウント、権限、外部公開	情報管理の確認が必要

「念のため全員承認」にすると、止まるだけです。

全員承認にするなら、各承認者が見る項目を1行で書けることを条件にします。

kintone承認フローの設計方法でも整理したように、承認者の名前より、判断の役割を分ける方が大切です。

スキップ・差し戻し・例外処理を決める

条件分岐は、通常ルートだけで考えると失敗します。

実務では、スキップ、差し戻し、却下、取り下げ、代理承認、再申請が発生します。

処理	決めること	例
スキップ	どの条件なら承認段階を飛ばすか	10万円未満は部長承認を飛ばす
差し戻し	どこへ戻すか	申請者修正待ち、一次承認待ち
却下	レコードを終了するか	却下で終了し、再申請は新規
取り下げ	誰が実行できるか	申請者、管理者
代理承認	どの条件で許すか	長期不在時のみ、代理理由を残す
再承認	どの変更で戻すか	金額、取引先、申請種別の変更

差し戻しは、戻し先を1つに決めすぎると不便です。

たとえば、部長承認で差し戻したい理由が「申請理由不足」なら申請者に戻します。

「経理確認で科目だけ直したい」なら、経理確認中に戻す方がよい場合もあります。

ただし、戻し先を増やしすぎると、今度は運用が複雑になります。

最初は、次の2つで十分なことが多いです。

差し戻し先	使う場面
申請者修正待ち	申請内容、金額、添付、理由を直す
前段確認待ち	前段承認者の判断や担当設定を直す

例外処理は、通常ルートに混ぜ込みすぎない方がよいです。

年に数回しかない例外のために、毎日使う承認ルートへ条件を追加すると、通常処理が読みにくくなります。

例外は、管理者だけが実行できるアクション、別アプリ、別ステータス、コメントと監査ログで扱うなど、頻度とリスクに応じて分けます。

承認者マスタ化を検討するケース

条件分岐が増えてきたら、プロセス管理の設定だけで抱えない方がよい場合があります。

特に、部門、金額、申請種別ごとに承認者が変わるなら、承認者マスタを検討します。

マスタ項目	例
部門	営業部、管理部、開発部
申請種別	経費、購買、契約
金額下限	0円、100,000円、1,000,000円
金額上限	99,999円、999,999円、上限なし
一次承認者	課長、チームリーダー
最終承認者	部長、役員
追加確認者	経理、管理部門、情報管理担当
有効開始日	2026-04-01
有効終了日	2027-03-31

マスタ化すると、承認者変更をプロセス管理の設定変更ではなく、マスタ更新で扱いやすくなります。

ただし、標準機能だけで完全に自動化できるとは限りません。

ルックアップ、関連レコード、プラグイン、JavaScript、連携サービスのどれを使うかは、要件によります。

重要なのは、プロセス管理の条件分岐を増やし続ける前に、「これは設定画面で持つべきルールか、マスタで持つべきルールか」を分けることです。

条件数	方針
少ない	プロセス管理の条件で管理する
部門・金額・種別の組み合わせが増える	承認者マスタを検討する
期間で承認者が変わる	有効期間を持つマスタを検討する
申請内容から承認者を自動入力したい	カスタマイズやプラグインを検討する
監査証跡や代理承認が厳しい	専用ワークフローも比較する

承認者マスタを作る場合は、保守責任者も決めます。

誰でもマスタを変えられる状態では、承認ルートの統制が効きません。

テストケースと変更管理

条件分岐を作ったら、必ずテストケースを作ります。

画面で1件だけ動かして終わりにすると、境界値や例外で崩れます。

最低限、次のテストは必要です。

テスト	確認すること
金額の下限	99,999円が課長承認へ進むか
金額の境界	100,000円が部長承認へ進むか
高額	1,000,000円以上が最終承認へ進むか
申請種別	契約だけ管理部門確認へ進むか
部門	部門ごとの承認者が正しいか
差し戻し	申請者修正待ちへ戻るか
再申請	修正後に正しいルートへ戻るか
承認コメント	入力がないと承認ボタンが出ないか
作業者以外	ボタンが表示されないか
完了後編集	金額や種別を変更できないか

kintone公式ヘルプでは、作業者が設定されている場合、アクションボタンは作業者のレコード詳細画面だけに表示されると説明されています。

この動きもテスト対象です。

管理者の画面では見えるのに、現場ユーザーでは見えない。

逆に、作業者ではない人にもボタンが出てしまう。

このような権限まわりは、テスト用ユーザーで確認します。

変更管理では、次を記録します。

変更内容	記録すること
金額基準の変更	変更前後の閾値、適用開始日
承認者の変更	対象部門、対象申請種別、引継ぎ日
申請種別の追加	追加理由、承認ルート、必要項目
ステータス追加	一覧、通知、権限への影響
例外ルート追加	使う条件、利用頻度、管理者

条件分岐は、設定した日よりも、変更する日の方が事故りやすいです。金額基準、承認者、申請種別を変えるときの影響範囲を先に表にします。

よくある失敗

kintoneプロセス管理の条件分岐でよくある失敗は、次の通りです。

失敗	起きること	対策
条件を全部ステータスにする	ステータスが増えすぎる	ステータスと作業者を分ける
人名で承認者を固定する	異動で止まる	役割、フィールド、マスタで持つ
金額の境界が曖昧	10万円ちょうどで迷う	以上、未満を表にする
例外を通常フローに混ぜる	画面が読めない	例外フローや管理者アクションに分ける
全員承認を増やす	滞留が増える	見る項目がある人だけに絞る
通知で解決しようとする	誰が動くか分からない	作業者と未処理一覧を使う
テストが通常ルートだけ	差し戻しや境界値で崩れる	テストケース表を作る
設定変更の記録がない	後から理由が分からない	変更履歴と設計表を残す

条件分岐は、最初に作るときよりも、半年後に直すときに差が出ます。

どの条件が何のためにあるのか。

どの条件を変えると、どの承認ルートに影響するのか。

どの条件は削っても問題ないのか。

これを説明できる状態にしておくことが、保守しやすいプロセス管理です。

kintoneプロセス管理の条件分岐は、設計表から作る

kintoneプロセス管理の条件分岐は、設定画面から始めると増えすぎます。

まず、次の順番で整理します。

1. 申請種別、金額、部門、リスク度のうち、どれで本当にルートが変わるか決める
2. 条件に使うフォーム項目の意味を固定する
3. 金額の境界値と変更時の扱いを決める
4. 部門ごとの承認者は、ステータスではなく作業者やマスタで吸収できないか確認する
5. 複数承認者は、全員承認と誰か1人承認を分ける
6. スキップ、差し戻し、例外、再承認を通常ルートとは別に整理する
7. テストケースと変更管理表を作る

条件分岐は、複雑な業務をそのまま写すための機能ではありません。

業務ルールを絞り、判断者を明確にし、変更しても崩れにくい承認ルートにするための機能です。

Bitlightでは、kintoneプロセス管理の条件分岐を、金額、部門、申請種別、承認者、通知、差し戻し、テストケースまで含めて設計できます。

既存の承認フローが複雑になっている場合は、まず条件分岐の一覧化と削れる条件の整理から始めるのが現実的です。

kintoneメール通知の設計方法はこちら
kintoneワークフローの設計方法はこちら