kintone承認フローの設計方法｜金額分岐・複数承認・差し戻しまで

kintoneで承認フローを作るとき、最初に考えやすいのはプロセス管理の設定です。

申請前。

承認待ち。

承認済み。

差し戻し。

却下。

このようなステータスを作り、申請する、承認する、差し戻す、却下する、といったアクションを置く。

承認者をユーザー選択フィールドや組織で指定する。

金額が高いときだけ部長承認に回す。

ここまでは、kintoneの標準機能でも始められます。

ただし、実務で問題になるのは、承認ボタンを表示できるかどうかではありません。

本当に崩れやすいのは、次のような状態です。

• 承認者が何を判断するのか決まっていない
• 金額分岐の基準が税込、税抜、明細合計のどれか曖昧
• 申請種別ごとの承認ルートが増えすぎる
• 複数承認が「全員承認」なのか「誰か1人」なのか分からない
• 差し戻し理由がコメントに散らばり、再申請時に追えない
• 代理承認を許可したが、誰の責任で承認したのか残らない
• 承認済み後に金額や添付資料が編集できてしまう
• 承認待ち通知は出るが、滞留や期限超過を一覧で見られない
• 組織変更後も古い承認者が作業者に残る
• 承認ログを監査や振り返りに使える形で残していない

承認フローは、ボタンの順番ではありません。

申請内容に対して、誰が、何を見て、どの条件なら承認し、どの条件なら差し戻し、どの状態なら承認後に変更できないのかを決める業務ルールです。

kintone承認フローで最初に決めるべきなのは、承認者の名前ではなく、「承認者が何を判断する責任を持つか」です。

この記事では、kintoneで承認フローを設計するときの、承認ルート、申請種別、金額分岐、複数承認、差し戻し、代理承認、通知、承認ログ、複雑化の削り方を整理します。

kintoneワークフローの設計方法はこちら
kintone経費精算の設計方法はこちら

先に結論：承認フローは「判断項目」から作る

kintoneで承認フローを作る前に、承認者ごとの判断項目を決めます。

承認者を先に並べるのではなく、何を判断する必要があるのかを先に出します。

判断項目	主な確認者	承認で見ること
業務上の必要性	上長、部門責任者	その申請が業務上必要か
金額の妥当性	上長、部長、経理	金額、予算、見積根拠が妥当か
規程との整合	管理部門、経理、人事	社内規程や申請ルールに合うか
契約・法務リスク	管理部門、法務、責任者	契約条件、個人情報、責任範囲に問題がないか
実行可能性	実務担当、管理者	納期、体制、後続処理が現実的か
会計・支払	経理	科目、税区分、支払条件、会計処理に問題がないか

たとえば、備品購入の承認なら、上長は業務上必要かを見ます。

経理は支払や科目を見ます。

情報システム担当はセキュリティや管理方法を見ます。

部長は予算と例外判断を見ます。

これらを全部「承認者」とだけ呼ぶと、誰が何を見たのか分からなくなります。

承認フローでは、承認者の名前より、判断の役割を分ける方が重要です。

悪い設計	起きやすい問題
Aさん承認、Bさん承認、Cさん承認	人事異動や退職で崩れる
上長承認だけ	金額、規程、会計の判断が混ざる
全部管理部門承認	現場の必要性を判断できない
金額だけで分岐	リスクや申請種別が見落とされる
コメントだけで判断理由を残す	後から集計、監査、改善に使いにくい

承認フローは、できるだけ「役割」で作ります。

営業責任者、部門長、経理担当、管理部門、実行責任者、情報システム担当のように、判断内容に対応した役割にします。

ユーザー名は、その役割に割り当てる運用にします。

承認者を人名で固定する前に、「その人が承認で見る項目」を1行で書けるか確認します。書けない承認者は、フローから外す候補です。

kintoneのプロセス管理で扱う基本要素

kintoneの承認フローは、主にプロセス管理で作ります。

kintone公式ヘルプでは、プロセス管理はステータス、作業者、アクションの3つを組み合わせて設定すると説明されています。

kintoneヘルプ：ステータス、作業者、アクションとは

承認フローに置き換えると、次のようになります。

要素	kintone上の意味	承認フローで決めること
ステータス	レコードの処理状況	申請前、承認待ち、承認済み、差し戻しなど
作業者	その状態で作業するユーザー	誰が承認・差し戻し・却下できるか
アクション	次の状態へ進める操作	申請する、承認する、差し戻す、却下するなど
アクション条件	条件を満たすときだけ出るボタン	金額、申請種別、承認コメントなど

公式ヘルプでは、作業者に設定されたユーザーへ自分宛通知が届いたり、未処理一覧に該当レコードが表示されたりすることも説明されています。

この点は、承認フロー設計では重要です。

承認者を作業者にするだけでなく、承認待ちを一覧で見られるようにする。

メールや通知だけに頼らず、未処理の承認を定期的に確認できるようにする。

ここまで含めて設計します。

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

承認フローで最も多い分岐は、申請種別、金額、部門です。

ただし、分岐条件を増やしすぎると、誰も理解できないフローになります。

まず、承認ルートを分ける理由を明確にします。

分岐条件	分ける理由	注意点
申請種別	経費、購買、契約、休暇で判断者が違う	種別を増やしすぎない
金額	承認権限や予算責任が変わる	税込、税抜、合計の定義を固定する
部門	部門長や予算責任者が違う	組織変更への対応が必要
取引先区分	新規取引、既存取引でリスクが違う	顧客マスタの品質が必要
契約有無	契約確認や法務確認が必要になる	契約管理との境界を決める
リスク度	個人情報、外部公開、重要顧客など	主観になりすぎないよう分類する

金額分岐は分かりやすいですが、設計を間違えると危険です。

たとえば、10万円未満は課長承認、10万円以上は部長承認にする場合、次を決めます。

決めること	例
判定金額	申請合計、明細合計、税抜合計、税込合計
境界値	100,000円以上は部長承認、99,999円以下は課長承認
変更時の扱い	金額変更時は再承認に戻す
複数明細	明細合計で判定するか、最大明細で判定するか
例外	予算内でも管理部門確認が必要な申請

kintoneのアクション条件では、フィールドの値に応じて特定の条件を満たしたときだけアクションを表示できます。

公式ヘルプでも、申請金額によって「10万円未満なら課長承認」「10万円以上なら部長承認」のようにアクションボタンを切り替える例が紹介されています。

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

ただし、アクション条件は業務ルールそのものではありません。

先に承認規程を決め、その規程をkintoneの条件に落とします。

金額、申請種別、部門、リスク度のどれで分岐するのかを決めずに条件だけ増やすと、フローが読めなくなります。

一次承認・最終承認・合議の設計

承認フローでは、一次承認と最終承認を分けると設計しやすくなります。

一次承認は、現場に近い確認です。

最終承認は、会社として通してよいかの判断です。

合議は、複数の観点を並行して確認する設計です。

承認段階	見ること	向いている申請
一次承認	業務上必要か、内容が妥当か	経費、購買、休暇、見積
最終承認	予算、リスク、会社判断	高額申請、契約、例外申請
経理確認	支払、科目、税区分、締め	経費、購買、請求
管理部門確認	規程、契約、社内手続き	契約、備品、外部委託
合議	複数部門の観点を合わせる	セキュリティ、法務、経理が絡む申請

複数承認では、「全員が承認する必要がある」のか「誰か1人が承認すればよい」のかを分けます。

kintoneの作業者設定では、複数のユーザーや組織を設定するときに、作業者全員、作業者のうち1人、作業者を選択といった考え方があります。

kintoneヘルプ：作業者の設定

この違いは、業務上の意味が大きいです。

複数承認の型	意味	向いている場面
誰か1人	グループ内の誰かが代表して判断する	チーム内の簡易確認、当番制
全員	指定された全員の判断が必要	経理と管理部門など観点が違う確認
選択式	申請者や前段承認者が次の作業者を選ぶ	案件ごとに担当者が変わる場合
直列承認	一次、二次、最終の順で進める	階層的な決裁
並列確認	複数部門が同時に確認する	期限を短くしたい合議

承認フローを設計するときは、全員承認を増やしすぎない方がよいです。

全員承認は、責任は明確になりますが、止まりやすくなります。

誰か1人承認は、速く進みますが、誰が判断してもよい内容に限定します。

合議が多い場合は、kintoneだけで抱え込むより、専用ワークフローや外部連携を検討します。

kintoneワークフローの設計方法でも整理したように、複雑な合議や代理承認は、標準機能だけで作るより役割分担を考えた方がよいケースがあります。

差し戻し・却下・再申請のルール

承認フローは、承認されるケースだけで設計してはいけません。

差し戻し、却下、再申請のルールがないと、実務で詰まります。

操作	意味	再申請の扱い
差し戻し	修正すれば再申請できる	同じレコードで修正して再申請
却下	今回の申請は通さない	原則終了。必要なら新規申請
取消	申請者や管理者が取り下げる	理由を残して終了
再申請	差し戻し後にもう一度提出する	前回理由と修正内容を残す
再承認	承認後に重要項目を変えた	承認待ちへ戻す

差し戻しでは、理由を構造化します。

コメントだけだと、後から「なぜ差し戻しが多いのか」を分析できません。

差し戻し理由	例
金額不備	見積書と申請金額が違う
添付不足	見積書、請求書、証憑がない
理由不足	申請目的や必要性が説明されていない
承認者違い	金額や部門に対してルートが違う
規程違反	社内規程の条件を満たしていない
期限不備	実施日、支払日、契約開始日が不明
申請種別違い	契約申請なのに購買申請で出している

差し戻し時に、何を編集できるかも決めます。

申請理由や添付資料は修正できることが多いです。

ただし、金額、取引先、申請種別を変えると、承認ルートそのものが変わる可能性があります。

項目	差し戻し後の扱い
申請理由	編集可。修正内容を明確にする
添付資料	編集可。差し替えや追加が必要
金額	編集可にする場合は再判定する
申請種別	原則慎重。ルートが変わる
承認コメント	承認者側の記録として編集させない
承認日時	自動記録または履歴として残す
承認者	手入力で変えさせない

差し戻しは、申請を戻す操作ではなく、再申請に必要な修正情報を渡す操作です。理由カテゴリと補足コメントを分けて残します。

承認後に編集できる項目とできない項目

承認フローで必ず決めるべきなのが、承認後の編集制御です。

承認済み後に申請内容が自由に編集できると、承認の意味がなくなります。

特に、次の項目は慎重に扱います。

項目	承認後の扱い
金額	原則編集不可。変更時は再承認
取引先	原則編集不可。変更時は再承認
申請種別	原則編集不可
添付資料	差し替え時は理由と履歴を残す
支払条件	変更時は経理確認が必要
実施日・契約開始日	業務により再承認
管理メモ	管理者のみ編集可
後続処理状態	次工程担当者が更新

承認後に変更が必要なことはあります。

見積金額が変わった。

請求書の金額に誤りがあった。

添付ファイルを差し替える必要が出た。

契約開始日が変わった。

この場合、承認済みレコードを直接上書きするのではなく、変更申請、再承認、管理者修正ログのどれで扱うかを決めます。

変更方法	向いているケース	注意点
差し戻しへ戻す	承認前の不備修正	承認済み後には使いにくい
再承認へ戻す	金額、条件、相手先が変わる	前回承認との差分を残す
変更申請を作る	承認済み後の正式な変更	元申請との関連を残す
管理者修正ログ	軽微な誤字や管理項目修正	修正理由と修正者を残す
別レコードで再申請	却下後や大幅変更	旧申請との関係を残す

kintone標準機能だけで、ステータスごとの細かなフィールド編集制御をすべて表現しきれない場合があります。

その場合は、アプリ分割、フィールドアクセス権、プロセス管理、プラグイン、JavaScriptカスタマイズ、運用ルールを組み合わせます。

ただし、最初から細かく作り込みすぎるのも危険です。

承認後に固定すべき項目を絞り、重要項目から制御します。

代理承認と組織変更への対応

代理承認は、便利ですが責任が曖昧になりやすい機能です。

承認者が不在のとき、誰かが代わりに承認できるようにしたい。

組織変更で承認者が変わった。

退職者や異動者が現在の作業者に残っている。

こうした問題は、承認フローの運用で必ず起きます。

kintoneのプロセス管理を設定したアプリでは、アクション実行時の組織、グループ、ユーザーの設定が現在の作業者に反映されます。

公式ヘルプでは、作業者に指定されている組織やグループにユーザーを追加しても、すでにアクションを実行したレコードの現在の作業者には自動反映されないことが説明されています。

kintoneヘルプ：プロセス管理を設定したアプリの使いかた

つまり、組織変更後も古い作業者が残る可能性があります。

承認フローでは、組織変更時の棚卸し手順を決めておく必要があります。

論点	決めること
代理できる人	上位者、同じ役割、管理者など
代理できる条件	休暇、期限超過、緊急、退職など
代理理由	必須入力にするか
ログ	元の承認者、代理承認者、理由を残す
通知	代理承認時に誰へ知らせるか
組織変更	作業者の棚卸しタイミング
管理者変更	現在の作業者を誰が修正できるか

代理承認を広く許可すると、承認責任が弱くなります。

代理承認は、権限を広げるためではなく、承認フローを止めないための例外処理です。

そのため、代理承認は「いつでも誰でも」ではなく、期限超過、緊急、承認者不在など条件を決めます。

通知・承認ログ・監査の残し方

承認フローは、通知が届けば回るわけではありません。

通知、未処理一覧、期限超過一覧、承認ログを組み合わせます。

目的	設計するもの
承認者に気づかせる	自分宛通知、メール通知、リマインダー
滞留を見つける	承認待ち一覧、期限超過一覧
判断理由を残す	承認コメント、差し戻し理由
後から追う	承認者、承認日時、承認結果
改善する	差し戻し理由、承認所要日数、滞留部門

通知は、次に動く人にだけ出します。

全員通知にすると、承認フローは早くならず、むしろ読まれなくなります。

kintoneメール通知の設計方法でも整理したように、通知は「誰が次に何をするか」とセットで考えます。

承認ログとして最低限残したい項目は、次の通りです。

項目	用途
承認ステップ	一次承認、最終承認、経理確認など
承認者	誰が判断したか
承認日時	いつ判断したか
承認結果	承認、差し戻し、却下、取消
承認コメント	判断理由や補足
差し戻し理由	修正すべき内容
代理承認フラグ	代理か通常か
変更前後	重要項目の変更履歴

kintoneにはレコードの変更履歴やコメントがあります。

ただし、承認分析や監査に使うなら、承認履歴を項目や関連アプリとして持つ設計も検討します。

コメントだけにすると、人間には読めますが、集計や一覧化がしづらくなります。

複雑すぎる承認フローの見直し方

承認フローは、放っておくと増えます。

金額分岐。

部門分岐。

申請種別分岐。

例外承認。

代理承認。

合議。

再承認。

承認者が増えるほど、安心に見えます。

しかし、実務では止まりやすくなります。

複雑すぎる承認フローは、次の順番で削ります。

見直し観点	削り方
判断が重複している	同じ内容を見ている承認者を統合する
金額分岐が細かすぎる	しきい値を減らす
全員承認が多い	本当に全員の判断が必要か見直す
例外が多い	例外カテゴリを整理し、標準ルートに寄せる
承認者が人名固定	役割やフィールド指定に寄せる
差し戻しが多い	入力必須、説明テンプレート、添付チェックを改善する
承認後修正が多い	申請前チェックと再承認ルールを見直す

承認フローの目的は、責任者を増やすことではありません。

必要な判断を、必要な人が、必要なタイミングで行うことです。

低リスクの申請は軽く通す。

高額、契約、個人情報、社外公開、会計処理が絡む申請だけ重くする。

このメリハリがないと、現場は承認フローを避けるようになります。

承認フローは複雑にするほど統制が強くなるわけではありません。判断が重複している承認者を減らし、高リスク条件だけ厚くする方が運用で守られます。

kintone承認フロー設計の進め方

実際に設計するときは、次の順番で進めます。

順番	決めること	成果物
1	承認対象の申請種別	経費、購買、契約、見積など
2	判断項目	必要性、金額、規程、契約、会計など
3	承認者の役割	上長、部門長、経理、管理部門など
4	金額・リスク条件	しきい値、対象金額、例外条件
5	承認ステータス	申請前、一次承認待ち、承認済みなど
6	作業者	誰がどのステータスでボタンを押すか
7	差し戻し・却下	理由、再申請、終了条件
8	承認後編集制御	固定する項目、再承認条件
9	通知・一覧	承認待ち、期限超過、差し戻し
10	承認ログ	承認者、日時、結果、理由

この順番を守ると、設定画面で迷いにくくなります。

最初にkintoneの画面を開いてしまうと、ステータスやボタン名の話になりがちです。

その前に、承認規程、判断項目、承認者の役割、例外条件を表にします。

表にして説明できない承認フローは、kintoneに入れても運用で崩れます。

まとめ：承認フローは、判断責任をデータ化する設計

kintoneで承認フローを作ること自体は難しくありません。

プロセス管理を使えば、ステータス、作業者、アクション、条件を設定し、申請、承認、差し戻し、却下の流れを作れます。

ただし、実務で使える承認フローにするには、設定の前に決めることがあります。

承認者は何を判断するのか。

金額分岐の基準は何か。

複数承認は全員なのか、誰か1人なのか。

差し戻し理由をどう残すのか。

承認後に何を編集不可にするのか。

代理承認や組織変更をどう扱うのか。

通知と承認ログをどう残すのか。

ここまで整理すると、kintoneの承認フローは単なるボタンではなく、判断責任をデータとして残す仕組みになります。

Bitlightでは、kintoneの承認フローについて、申請種別、金額分岐、承認者、差し戻し、代理承認、通知、承認ログ、外部連携の境界まで一緒に設計できます。

承認ルートが複雑になってきた場合や、承認済み後の変更、差し戻し、代理承認で運用が崩れている場合は、プロセス管理の設定だけでなく、承認ルールそのものから見直すのが近道です。