kintoneワークフローの設計方法｜申請・承認・差し戻しを崩さない構成

kintoneでワークフローを作りたい相談では、最初にプロセス管理の設定画面が話題になります。

下書き。

申請中。

一次承認待ち。

最終承認待ち。

承認済み。

差し戻し。

却下。

このようなステータスを作り、申請する、承認する、差し戻す、却下する、といったアクションを設定すれば、ワークフローらしい画面は作れます。

ただし、実務で困るのは、承認ボタンを作れないことではありません。

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

• 申請内容の正本がどのレコードか分からない
• 申請中に申請者がどこまで編集してよいか決まっていない
• 差し戻し後に何を直したのか追えない
• 却下と差し戻しの意味が混ざっている
• 承認者が人名固定で、異動や退職に弱い
• 複数承認者のうち誰が判断したのか曖昧になる
• 承認待ち通知は届くが、期限超過や滞留が見えない
• 承認済み後に、経理、契約、発注、請求など次工程へ渡らない
• 代理承認や取り戻しを後から追加し、責任範囲が分からなくなる
• 専用ワークフローシステムで扱うべき複雑な承認までkintoneで作り込む

kintoneのワークフローは、プロセス管理だけで考えると狭くなります。

プロセス管理は重要ですが、それは申請・承認業務を動かす部品の1つです。

ワークフローとして運用するには、申請データ、ステータス、作業者、アクション、通知、権限、履歴、外部連携までを一緒に設計します。

kintoneワークフローで最初に決めるべきなのは、承認ボタンの名前ではなく、「申請レコードがどの状態なら誰が何をできるか」です。

この記事では、kintoneでワークフローを崩れにくい業務システムとして設計する方法を整理します。

kintone経費精算の設計方法はこちら
kintone見積書作成の設計方法はこちら

先に結論：ワークフローはステータス設計から始める

kintoneでワークフローを作るとき、最初に決めるべきなのはフォーム項目でも、承認ボタンでもありません。

まず、申請レコードが取りうる状態を決めます。

状態が決まると、次に誰が作業者になるのか、どのアクションを実行できるのか、どの通知を出すのか、どの項目を編集できるのかが決まります。

状態	主な意味	次に動く人
下書き	申請者が入力している	申請者
申請中	申請が提出され、承認待ち	一次承認者
一次承認済み	部門内の確認が終わった	最終承認者、管理部門
最終承認待ち	最終判断を待っている	決裁者、管理者
承認済み	申請が通った	次工程の担当者
差し戻し	修正が必要	申請者
却下	今回の申請は通さない	申請者、管理者
取り戻し	申請者が提出を取り下げた	申請者
完了	後続処理まで終わった	関係者は参照中心

この表を作らずにプロセス管理を設定すると、後からボタンが増えます。

差し戻し、再申請、取り戻し、代理承認、完了、取消、再オープンなどを追加するたびに、状態の意味が曖昧になります。

状態の意味が曖昧になると、一覧も通知も権限も崩れます。

たとえば「承認済み」は、申請が通っただけなのか、発注や支払まで完了した状態なのか。

「差し戻し」は、申請者が修正できる状態なのか、承認者コメントだけを追記する状態なのか。

「却下」は、再申請できるのか、別レコードで新規申請するのか。

ここを先に決めます。

ステータスは画面上の表示名ではなく、業務上の責任分界です。誰が責任を持つ状態なのかを説明できないステータスは増やさない方がよいです。

kintoneのワークフローとプロセス管理の関係

kintoneでは、標準機能のプロセス管理を使って、申請や承認の流れを作れます。

公式ヘルプでも、プロセス管理は業務プロセスに沿った進捗管理ができる機能で、申請の承認や稟議の決裁をアプリで管理してワークフローのように使えると説明されています。

kintoneヘルプ：プロセス管理

プロセス管理では、主に次の要素を設計します。

要素	意味	設計で決めること
ステータス	レコードの現在状態	下書き、申請中、承認済みなど
作業者	次にアクションを実行する人	申請者、上長、経理、管理者など
アクション	状態を進める操作	申請、承認、差し戻し、却下など
条件	アクションを出す条件	金額、申請種別、部門、項目入力など
通知	次の作業者への知らせ	自分宛通知、メール、リマインダーなど

この機能を使うと、レコードの詳細画面からボタンを押して、次のステータスへ進められます。

申請者が申請し、承認者が承認し、必要なら差し戻す。

小規模な稟議、休暇申請、経費申請、見積承認、社内確認であれば、kintoneのプロセス管理だけでも十分に始められます。

一方で、プロセス管理はワークフロー専用システムそのものではありません。

kintone SIGNPOSTでも、kintoneでワークフローを扱う場合は、基本機能だけで行うケース、プラグインやカスタマイズを併用するケース、専用システムと連携するケースを分けて考える必要があると整理されています。

kintone SIGNPOST：ワークフローとして利用する場合の設計

つまり、最初から「全部kintoneでやる」と決めない方がよいです。

申請の入力、状態管理、一覧、コメント、レコードの権限管理はkintoneが得意です。

複雑な合議、厳密な代理承認、組織階層に応じた自動経路、全社横断の承認履歴管理は、専用ワークフローシステムの方が向くことがあります。

申請データ・申請者・承認者を分ける

ワークフロー設計で最初に分けるのは、人ではなくデータです。

申請レコードは、申請の正本です。

申請者は、申請を起票した人です。

承認者は、申請内容を確認して判断する人です。

この3つを混ぜると、後から運用が崩れます。

分けるもの	1レコード・1項目の意味	役割
申請レコード	1件の申請	申請内容、状態、承認結果の正本
申請者	起票した人	入力、修正、再申請を担当
所属・部門	申請者の所属	承認ルートや集計に使う
承認者	判断する人	承認、差し戻し、却下を実行
作業者	現在ボタンを押せる人	プロセス管理上の担当
閲覧者	参照だけする人	監査、管理、関係部署の確認
次工程担当者	承認後に処理する人	発注、支払、契約、登録など

たとえば経費精算では、申請者、上長承認者、経理確認者、支払担当者が違います。

kintone経費精算の設計方法でも整理したように、申請、明細、証憑、支払、会計を分けないと、承認後の処理が追えません。

見積書作成では、営業担当、営業責任者、管理部門、帳票出力担当、受注処理担当が違います。

kintone見積書作成の設計方法のように、見積データ、明細、価格、承認、版管理を分けると、ワークフローも安定します。

申請アプリに持たせる項目は、次のように考えます。

フィールド	型	設計意図
申請番号	文字列、採番	申請のキーにする
申請種別	ドロップダウン	稟議、休暇、経費、見積、契約などを分ける
申請者	ユーザー選択	起票者を明確にする
所属部門	組織選択、ルックアップ	承認ルートや集計に使う
承認者候補	ユーザー選択	上長や管理者を保持する
申請金額	数値	承認条件や一覧に使う
申請理由	文字列複数行	判断材料を残す
添付資料	添付ファイル	見積書、請求書、証憑など
現在ステータス	プロセス管理	下書き、申請中、承認済みなど
差し戻し理由	文字列複数行	修正理由を残す
承認コメント	文字列複数行、コメント	判断の根拠を残す
次工程状態	ドロップダウン、ステータス	承認後の処理を追う

申請者と作業者は同じとは限りません。

申請者は起票者です。

作業者は、現在のステータスでアクションを実行できる人です。

この違いを分けておくと、差し戻し時に申請者へ戻す、承認済み後に経理へ渡す、期限超過時に管理者へ通知する、といった運用を作りやすくなります。

差し戻し・却下・取り戻しの状態設計

ワークフローで崩れやすいのは、差し戻し、却下、取り戻しです。

承認だけなら簡単です。

問題は、申請内容に不備があるとき、申請者が提出を取り消したいとき、承認者が通せないと判断したときです。

操作	意味	次に動く人
差し戻し	修正すれば再申請できる	申請者
却下	今回の申請は通さない	申請者、管理者
取り戻し	申請者が提出を取り下げる	申請者
再申請	修正後にもう一度提出する	承認者
取消	承認後の処理を止める	管理者、責任者

差し戻しは、修正を前提にした状態です。

そのため、差し戻し後に申請者が編集できる項目を決めます。

申請理由、添付資料、金額、申請種別、明細、承認者候補など、どこまで直せるかです。

すべて編集できるようにすると、承認者が見た内容と再申請時の内容が大きく変わる可能性があります。

一方で、ほとんど編集できないと、差し戻しの意味がありません。

差し戻し後に編集させる候補	方針
申請理由	原則編集可。補足や修正が必要になる
添付資料	原則編集可。不備資料の差し替えが多い
金額	業務により制御。変更時は再承認が必要
申請種別	原則慎重に扱う。承認ルートが変わるため
承認者	自動設定が基本。手入力変更は監査しにくい
承認済みコメント	編集不可。判断記録として残す

却下は、今回の申請を通さない判断です。

再申請を認めるなら、却下レコードを再利用するのか、新しい申請を作るのかを決めます。

取り戻しは、申請者側の操作です。

提出後に誤りに気づいた場合、承認前なら申請者が取り戻せるようにするか、承認者に差し戻してもらう運用にするかを決めます。

kintoneの申請ワークフロー設定例では、差し戻しや複数承認者を使うパターンが紹介されています。

kintoneヘルプ：申請ワークフローの設定例

公式の設定例は、どの機能で表現できるかを確認する入口として有用です。

ただし、自社の業務では、差し戻し理由、再申請時の編集範囲、却下後の扱い、取り戻しの条件まで決める必要があります。

差し戻しは「戻るボタン」ではありません。何を直せば再申請できるのか、どの項目を変更できるのか、変更前の判断記録をどう残すのかまで決める必要があります。

複数承認・条件分岐・代理承認の考え方

複数承認や条件分岐は、必要になってから足すと複雑になります。

ただし、最初から全パターンを作り込むのも危険です。

ワークフロー設計では、まず次の3段階で考えます。

段階	例	設計方針
固定ルート	申請者 → 上長 → 管理部門	標準機能で始めやすい
条件分岐	金額、部門、申請種別で承認者が変わる	条件を少なく保つ
例外処理	代理承認、引き上げ、組織変更、一括承認	運用ルールと権限が必要

固定ルートは、もっとも運用しやすいです。

申請者が申請し、上長が承認し、管理部門が確認する。

休暇申請、簡易稟議、小規模な経費申請なら、この構成で十分なことがあります。

条件分岐は、申請金額、申請種別、所属部門、案件区分などで承認者を変える設計です。

たとえば、金額が一定以上なら部長承認を追加する、契約関連なら管理部門確認を必須にする、備品購入なら総務確認に回す、といった形です。

条件分岐は便利ですが、増やしすぎると誰も説明できないワークフローになります。

条件分岐に使う項目	向いている理由	注意点
申請種別	稟議、経費、契約などで処理が違う	種別が増えすぎると運用が重い
金額	承認権限と結びつきやすい	税込、税抜、合計の定義をそろえる
部門	部門長承認に使える	組織変更への対応が必要
取引先区分	新規取引、既存取引で確認が変わる	顧客マスタの品質が必要
期限	緊急申請、期限超過で扱いを変える	例外が常態化しないようにする

代理承認や引き上げ承認は、便利ですが慎重に扱います。

「誰でも代理承認できる」状態にすると、承認責任が曖昧になります。

代理承認を許可するなら、代理できる人、理由、期限、ログの残し方を決めます。

kintone SIGNPOSTのまとめでも、kintoneの基本機能、プラグインやカスタマイズ、専用システム連携では、扱える承認機能や注意点が違うことが整理されています。

複雑な議決承認、組織階層連動、全社共通の承認基盤が必要なら、kintoneの基本機能だけで抱え込まない方がよいです。

通知・権限・編集制御

ワークフローは、ステータスを進めるだけでは足りません。

誰に通知するか。

誰が閲覧できるか。

誰が編集できるか。

承認後にどの項目を固定するか。

ここまで決めて初めて、申請・承認として使えます。

通知は、次に作業する人へ出します。

全員に知らせるものではありません。

状態変化	通知先	目的
下書き → 申請中	一次承認者	承認依頼
申請中 → 差し戻し	申請者	修正依頼
一次承認済み → 最終承認待ち	最終承認者	決裁依頼
承認済み → 次工程待ち	経理、総務、契約担当など	後続処理
期限超過	作業者、上長	滞留確認
却下	申請者、必要に応じて管理者	結果共有

通知を増やす前に、一覧を作ります。

承認待ち一覧、差し戻し中一覧、期限超過一覧、承認済み未処理一覧です。

通知だけで運用すると、メールを見逃した瞬間に止まります。

kintoneメール通知の設計方法でも整理したように、通知は「知らせる量」ではなく「次に誰が何をするか」で設計します。

権限は、ステータスとセットで考えます。

状態	申請者	承認者	管理者	閲覧者
下書き	編集可	原則閲覧不要	閲覧可	原則不可
申請中	原則編集不可	閲覧・判断	閲覧可	必要範囲で閲覧
差し戻し	指定項目を編集	閲覧	閲覧可	必要範囲で閲覧
承認済み	原則編集不可	閲覧	後続処理項目を編集	必要範囲で閲覧
却下	原則編集不可	閲覧	閲覧可	必要範囲で閲覧
完了	原則編集不可	閲覧	管理項目のみ編集	必要範囲で閲覧

kintoneのアクセス権だけで、ステータスごとの細かな入力制御をすべて表現するのは難しいことがあります。

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

重要なのは、承認済みデータが無断で変わらないことです。

承認済み後に金額、取引先、添付資料、条件が変わるなら、再承認が必要です。

kintoneだけで足りないケース

kintoneのプロセス管理は、業務に近い申請・承認を作れる便利な機能です。

ただし、何でもkintoneだけで完結させればよいわけではありません。

次の条件が強い場合は、kintone単体では重くなります。

kintoneだけでは重いケース	理由
全社横断で申請種別が多い	申請アプリと承認ルートが増えすぎる
組織階層に応じて自動で承認者を決めたい	人事情報や組織改編との同期が必要
議決承認や複雑な合議が必要	標準の承認パターンでは表現しにくい
代理承認、引き上げ、一括承認を厳密に管理したい	権限とログの設計が重くなる
監査向けの承認履歴出力が必要	履歴データの正本と出力形式が重要
複数アプリを横断して全申請を見たい	横断一覧や検索基盤が必要
承認後に契約、購買、会計へ自動連携したい	外部システムとの責任分界が必要

これらがあるからといって、必ず専用システムにする必要はありません。

ただし、kintoneで作る範囲、プラグインやカスタマイズで補う範囲、専用ワークフローシステムへ任せる範囲を分けます。

小さく始めるなら、kintoneで申請データと状態管理を持ちます。

複雑な承認経路だけ外部ワークフローに任せ、承認結果をkintoneへ戻す構成もあります。

また、kintone側は案件、経費、見積、契約などの業務データを持ち、承認専用システム側は申請経路と承認履歴を持つ分担もあります。

専用ワークフローや外部連携に逃がす判断

専用ワークフローシステムや外部連携を検討する判断軸は、機能の多さではありません。

運用責任をどこに置くかです。

判断軸	kintone中心でよい	外部連携を検討
申請範囲	特定部署、特定業務	全社横断、多数の申請種別
承認経路	固定または少数条件	組織階層、役職、代理、合議が多い
申請データ	kintone業務データが正本	承認基盤側に申請正本が必要
変更頻度	現場管理者が変更できる	組織改編や規程変更と連動が必要
監査	kintone履歴と運用で足りる	承認履歴の厳密な出力が必要
連携	手動確認やCSVで足りる	契約、購買、会計と自動連携が必要
費用	kintone内で収めたい	追加費用を払って管理負荷を下げたい

外部連携にする場合も、kintone側の設計は必要です。

承認依頼を出す前の申請データ。

承認中の状態。

承認結果の受け取り。

差し戻し時の修正。

承認済み後の後続処理。

これらをkintoneでどう持つかを決めます。

専用ワークフローに逃がすというより、役割を分けると考えた方がよいです。

複雑な承認機能をkintoneで再現することが目的ではありません。kintoneが持つ業務データと、承認基盤が持つ判断履歴をどう分担するかが設計の中心です。

よくある失敗パターン

kintoneワークフローでよく起きる失敗は、機能不足よりも設計不足です。

ステータス名が業務責任を表していない

「確認中」「処理中」「完了」だけでは、誰が何をする状態か分かりません。

ステータス名は、できるだけ次の責任が分かる名前にします。

承認待ち、申請者修正中、経理確認中、発注処理待ち、契約確認待ちのように、担当と状態が見える名前にします。

差し戻し理由が残らない

差し戻しは、再申請のための情報です。

理由がコメント欄だけに散らばると、一覧で確認できません。

差し戻し理由、修正期限、再申請日、再申請回数を項目として持つと、滞留を見やすくなります。

承認後に申請内容を自由に編集できる

承認後に金額や添付資料が変わると、承認の意味がなくなります。

承認後に変更が必要な場合は、変更申請、再承認、管理者修正ログのいずれかを用意します。

承認済みで止まる

ワークフローは、承認されたら終わりとは限りません。

経費なら支払や会計確認。

見積なら受注や帳票送付。

契約なら契約書確認や締結。

休暇なら勤怠反映。

承認後の次工程まで見ないと、申請は通ったのに実務が止まります。

通知だけで滞留を防ごうとする

通知は必要ですが、通知だけでは足りません。

承認待ち一覧、期限超過一覧、差し戻し中一覧、承認済み未処理一覧を作ります。

週次で滞留を確認する運用も必要です。

すべてを1つの申請アプリに入れる

稟議、経費、休暇、見積、契約、購買を1つのアプリに詰め込むと、項目も承認ルートも増えすぎます。

共通の申請受付アプリを作る場合でも、申請種別ごとに必要項目、承認ルート、後続処理を分けます。

業務データが強いものは、経費精算アプリ、見積アプリ、契約管理アプリなどに分けた方がよいです。

kintoneワークフロー設計の進め方

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

順番	決めること	成果物
1	対象業務と申請種別	どの申請を扱うか
2	申請レコードの正本	何を1件の申請とするか
3	ステータス	下書き、申請中、承認済みなど
4	作業者	各状態で誰が動くか
5	アクション	申請、承認、差し戻し、却下など
6	編集範囲	どの状態で誰が何を編集できるか
7	通知と一覧	承認待ち、期限超過、差し戻し
8	承認後の処理	支払、発注、契約、勤怠、会計など
9	例外処理	代理、取り戻し、取消、再承認
10	外部連携の境界	専用ワークフロー、会計、契約など

設計時には、現場の申請書やメール承認をそのままkintone化しない方がよいです。

紙やメールでは、曖昧でも人が補っていた部分があります。

kintoneに移すと、曖昧な部分はステータス、作業者、権限、通知の矛盾として表に出ます。

そのため、現行業務を写す前に、状態と責任を言語化します。

「誰が、何を見て、何を判断し、次にどこへ渡すのか」を1ステータスずつ確認します。

まとめ：ワークフローはボタンではなく責任の流れとして設計する

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

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

ただし、実務で長く使うには、設定画面より前に決めることがあります。

申請レコードは何を正本にするのか。

誰が申請者で、誰が承認者で、誰が次工程を担当するのか。

差し戻し後に何を修正できるのか。

承認済み後にどの項目を固定するのか。

通知は誰に出し、一覧で何を確認するのか。

どこまでをkintoneで行い、どこから専用ワークフローや外部システムに任せるのか。

ここまで決めると、kintoneのワークフローは単なる承認ボタンではなく、業務を前に進める仕組みになります。

Bitlightでは、kintoneの申請・承認ワークフローについて、アプリ設計、ステータス、承認ルート、差し戻し、通知、権限、外部連携の境界まで一緒に整理できます。

申請アプリを作ったものの運用が止まっている場合や、承認ルートが複雑になってきた場合は、プロセス管理の設定だけでなく、業務設計から見直すのが近道です。