kintoneのプロセス管理とは？仕組みと設計パターン

kintoneの「プロセス管理」は、ノーコードで承認ワークフローを構築できる標準機能です。稟議・経費申請・購買申請といった申請業務をkintone上に載せる際、ほぼ必ず使うことになります。ただし、設定画面の用語（ステータス・作業者・アクション）と、実際の業務でやりたいこと（多段階承認、金額分岐、合議、差し戻し、代理承認）が頭の中でつながらないまま設定を始めると、後から作り直しになりがちです。本記事では、プロセス管理の仕組みを構造から整理し、実務でよく使う設計パターンと、標準機能では実現できないこと・その回避策までを詳しく解説します。設定画面の操作手順はkintoneで承認ワークフロー（プロセス管理）を設定する方法【画面付き】で画面キャプチャつきに解説していますので、あわせてご覧ください。

この記事の要点

• プロセス管理はステータス・作業者・アクションの3要素で構成される。
• 作業者の指定方法は「全員」「うち1人」「選択」「フィールドの値」の4種類があり、これが承認ルートの性格を決める。
• 日本企業の稟議要件は、おおむね4つの設計パターンの組み合わせで表現できる。
• ステータス名に「上長承認」のような動作名をつけると承認待ちか承認済かが読み取れないため、運用設計上は避ける。
• 承認の可視化はできるが、承認後の発注・支払いはプロセス管理の対象外で、別の仕組みが必要になる。

プロセス管理は何で構成されているのか？（3つの要素）

プロセス管理は、ステータス・作業者・アクションの3要素で構成されます。この関係を押さえると、設定画面で迷うことはほとんどなくなります。

ステータス：レコードが今どの段階にあるか

「未処理」「上長承認待ち」「経理確認中」「承認済」「却下」のように、レコードの状態を表します。プロセス管理を有効にすると、レコード詳細画面や一覧にステータスが表示され、業務のどこで止まっているかが可視化されます。

作業者：いまボールを持っている人

各ステータスで処理する担当者です。作業者に指定された人だけがアクションを実行できるというのが基本ルールで、これが承認権限そのものになります。作業者はレコード単位で保持されるため、「誰の元で止まっているか」を一覧で確認できます。

アクション：ステータスを次へ進める操作

「承認する」「差し戻す」「却下する」といった、ステータス遷移の操作です。アクションには実行条件を設定でき、金額や部門などの条件に応じて、進む先を分岐させられます。

作業者はどう指定する？4種類の使い分け

承認ルートの性格を決めるのが、作業者の指定方法です。プロセス管理では次の指定ができます。

指定方法	挙動	向いているケース
次のユーザー全員	指定した全員が処理するまで次へ進まない	合議、関係部署の同意が必要な稟議
次のユーザーのうち1人	誰か1人が処理すれば次へ進む	同格の担当者が複数いて、手が空いた人が処理する運用
次のユーザーから選択	前の作業者が候補の中から次の担当を指名する	案件ごとに承認者が変わる、担当役員が案件で異なる
フィールドの値から指定	ユーザー選択・組織・グループフィールドの値を作業者にする	申請内容によって承認者が決まる、承認者マスタで運用する

実務で効いてくるのは4つ目のフィールドの値から指定です。申請フォーム側に「承認者」のユーザー選択フィールドを持たせ、ルックアップなどで部門マスタから自動セットする構成にしておけば、組織改編のたびにプロセス管理の設定そのものを直す必要がなくなります。承認者をプロセス管理の設定画面に直接書き込む運用は、変更のたびにアプリ管理者の作業が発生し、属人化の原因になります。

なお、作業者に複数人が指定されている場合、レコードの詳細画面には現在の作業者が表示されます。「全員」と「うち1人」のどちらを選んだかで停滞の起き方が変わるため、合議のつもりで「うち1人」にしていた、といった設定ミスがないか確認してください。

承認ルートはどう設計する？よく使う4パターン

日本企業の稟議要件は、おおむね次の4パターンの組み合わせで表現できます。

パターン1：直列の多段階承認

「未処理 → 上長承認待ち → 経理確認中 → 承認済」のように、ステータスを順に並べ、各段の作業者を設定します。最も基本的な形で、段数が増えても構造は変わりません。

パターン2：金額によるスキップ分岐

同じステータスに複数のアクションを作り、実行条件で出し分けます。たとえば「上長承認待ち」から、30万円以上なら「部門長承認待ち」へ、30万円未満なら直接「承認済」へ進むアクションを両方用意し、それぞれに金額条件を設定します。

設計上の注意点は2つあります。ひとつは、条件の境界を重複させないこと（「30万円以上」と「30万円以下」を両方書くと、ちょうど30万円のときにどちらも実行できてしまいます）。もうひとつは、同じステータス内に同名のアクションを作らないことです。アクション名はAPIやカスタマイズからの実行時にアクションを識別するキーになるため、同名のアクションがあるとどれを実行すべきか判別できずエラーになります。

パターン3：合議（関係部署の同時承認）

作業者を「次のユーザー全員」に設定し、関係部署の担当者を全員指定します。全員が処理するまで次へ進まないため、誰が未処理かを追える運用（一覧の絞り込みや通知）をセットで用意してください。承認の停滞が起きやすいのはこのパターンです。停滞への対処はkintoneワークフロー承認遅延を解消する原因と対策で整理しています。

パターン4：差し戻しと再申請

「上長承認待ち」から「差し戻し（修正中）」へ向かうアクションを別に用意し、修正後に再び承認へ戻すアクションを設定します。ここで決めておきたいのが、差し戻し理由をどこに残すかです。コメント欄に書く運用にするのか、専用フィールドを用意するのか。監査対応を視野に入れるなら、後から検索・集計できる専用フィールドを用意しておくほうが確実です。

補足：完了後の編集をどう止めるか

プロセス管理はステータスを管理する機能であり、それ単体では「承認済のレコードを編集できないようにする」ことまでは行いません。承認後の改ざんを防ぐには、フィールドのアクセス権を併用し、特定のステータスでは編集不可にする設定を組み合わせます。内部統制の観点での考え方はkintone監査ログの限界を内部統制でどう埋めるか実務ガイドで詳しく整理しています。

プロセス管理でできないことは何か？

プロセス管理は柔軟な機能ですが、業務要件によっては標準のままでは満たせない部分があります。設計前に把握しておきたい制約は次のとおりです。

一覧画面からの一括承認ができない

複数レコードのステータスをまとめて変更する操作は、標準の画面では用意されていません。月末に数十件の承認が集中する運用では、承認者が1件ずつレコードを開くことになり、これが停滞の原因になります。

回避策：REST APIでステータスを更新する方法（複数レコードのステータス更新に対応したAPIがあります）や、一括承認に対応したプラグインの利用を検討します。いずれも導入・保守のコストは発生します。

代理承認の専用機能がない

承認者の長期不在に対して、「不在の間は代理者が承認する」という設定を本人が行う仕組みは標準にはありません。

回避策：作業者を「次のユーザーのうち1人」にして代理者を含めておく、承認者フィールドを人ではなく組織・グループで指定する、あるいはアプリ管理者がステータスを進めるといった運用で代替します。どの方法も誰が実際に承認したかの記録の残り方が変わるため、監査要件と照らして選んでください。

承認者が「見たかどうか」は分からない

アクションが実行されるまで、承認者が内容を確認したかどうかは記録されません。督促の判断材料が「まだ進んでいない」という事実だけになるため、期限管理は通知やリマインドの運用で補う必要があります。

承認には原則としてkintoneのライセンスが必要

申請者・承認者ともにkintoneのユーザーである必要があります。役員や一部の拠点長だけがkintoneを使っていない、という組織では、その人の承認だけ別手段になり、フローが分断されます。

条件分岐が増えるほど保守が難しくなる

アクションと実行条件の組み合わせが増えると、設定画面上で全体像を追うのが難しくなります。どのステータスから、どの条件で、どこへ進むのかを一覧化したドキュメントを別途持っておかないと、アプリ管理者の異動時に誰も触れないアプリになりがちです。

アプリをまたいだ承認はできない

プロセス管理はアプリ単位の機能です。申請と購買実績を別アプリで管理している場合、両者をまたいで1つの承認フローとして扱うことはできず、アプリ間の連携は別途設計が必要になります。

運用設計で何を押さえておくべきか？

ステータス名は「状態」で、アクション名は「動詞」で書く

ステータスに「上長承認」のような動作名をつけると、承認待ちなのか承認済なのかが読み取れません。ステータスは「上長承認待ち」、アクションは「承認する」と書き分けると、一覧を見たときの誤解が減ります。

ステータスを増やしすぎない

業務の実態に合わせてステータスを細かく刻むと、レコード一覧の絞り込みや集計は精緻になりますが、承認者の操作回数も増えます。その状態を誰かが検索・集計する必要があるかを基準に、増やすかどうかを判断してください。

承認者はマスタから引く

前述のとおり、承認者をプロセス管理の設定に直接書き込むと、組織改編のたびにアプリ設定の変更が必要になります。部門マスタアプリを用意し、ルックアップで承認者フィールドに自動セットする構成にしておくと、以降の変更はマスタの更新だけで済みます。

通知とポータルで停滞を可視化する

条件通知を使って作業者へ通知を送るほか、ポータルや一覧に「自分が作業者のレコード」を表示しておくと、承認待ちの取りこぼしが減ります。

プロセス管理で完結しない業務はどうする？

プロセス管理で承認を電子化すると、「誰の元で止まっているか」「いつ承認されたか」は明確になります。一方で、プロセス管理が扱うのはステータスの遷移までです。承認された後の発注・支払い・経費計上は、担当者が別のサイトやシステムで手作業を行うことになります。

購買稟議であれば、承認後に申請者か購買担当者が購買サイトを開いて注文し直す必要があり、承認内容と実際の発注内容が一致しているかは後から人が突き合わせることになります。経費申請であれば、従業員が立て替えて後から精算する運用が残ります。購買稟議の電子化についてはkintone購買稟議テンプレート活用と電子化の実務ガイドで、経費申請についてはkintoneの経費精算は承認後が詰まる｜購買・出張との連携で整理しています。

1Approval for kintoneは、この「承認の先」をつなぐ仕組みです。既存のプロセス管理のステータス変更をトリガーにできるため、いま設計した承認ルートを大きく変えずに導入できます。承認された時点で購買が実行されるため、承認済みの申請と実際の発注が別々に存在する状態が生まれず、従業員の立替精算を前提としない法人決済に切り替えられます。購買データは実行時点で経費データとして自動生成されて会計・経費精算システムと連携でき、複数サービス・複数取引先の利用料は月1回の法人一括請求にまとめられます。事前承認時の価格と購買時点の価格に差が出た場合も、あらかじめ許容範囲を設定しておけば差し戻しなしに進められる「ダイナミック・ポリシー」により、承認から購買完了までのリードタイムを短縮できます。

プロセス管理で作った承認フローの先にある発注・精算業務まで含めて見直したい方は、1Approval for kintoneの詳細を見るから具体的な機能を確認してみてください。

よくある質問（FAQ）

プロセス管理は追加費用なしで使えますか？

kintoneの標準機能のため、アプリ単位で有効にするだけで利用できます。ただし、一括承認や代理承認など標準にない機能をプラグインやカスタマイズで補う場合は、その分の費用が発生します。

複数人の承認者全員に承認させることはできますか？

できます。作業者の指定方法で「次のユーザー全員」を選ぶと、指定した全員が処理するまで次のステータスへ進みません。誰か1人の処理で進めたい場合は「次のユーザーのうち1人」を選びます。

金額によって承認者を変えることはできますか？

できます。同じステータスから進むアクションを複数作り、それぞれに金額の実行条件を設定します。条件の境界が重複しないように書くこと、同じステータス内で同名のアクションを作らないことに注意してください。

承認者を組織やグループで指定できますか？

できます。組織フィールドやグループ選択フィールドの値を作業者にする設定が可能です。個人名で指定するより異動に強くなるため、承認者マスタと組み合わせた運用をおすすめします。

承認済みのレコードを編集できないようにするには？

プロセス管理だけでは編集の制御はできません。フィールドのアクセス権を併用し、特定のステータスのときは編集不可にする設定を組み合わせてください。

ステータスを一括で進めることはできますか？

標準の一覧画面から複数レコードのステータスをまとめて変更することはできません。REST APIによる更新や、一括承認に対応したプラグインの利用を検討することになります。

まとめ

kintoneのプロセス管理は、ステータス・作業者・アクションという3要素で構成され、作業者の指定方法（全員／うち1人／選択／フィールドの値）とアクションの実行条件を組み合わせることで、多段階承認・金額分岐・合議・差し戻しといった稟議の要件をノーコードで表現できます。

設計時のポイントは、承認者をマスタから引く構成にしておくこと、ステータスとアクションの命名を分けること、そして一括承認・代理承認・既読確認といった標準にない要件を、プラグイン・API・運用ルールのどれで埋めるかを先に決めておくことです。そのうえで、承認の先に続く発注・支払い・経費計上まで含めて業務を見直すと、承認の電子化だけでは届かない工数削減につながります。