kintoneワークフローの作り方｜設定前に決める状態・作業者・通知設計

kintoneでワークフローを作るとき、最初に触りたくなるのはプロセス管理の設定画面です。

プロセス管理を有効にする。

ステータスを作る。

作業者を指定する。

アクション名と遷移先を決める。

条件分岐を設定する。

通知を出す。

この流れで、kintone上に申請・承認のボタンは作れます。

ただし、実務で失敗するワークフローは、設定方法を知らないから失敗しているとは限りません。

次のような状態で始めると、設定はできても運用で崩れます。

• 紙やメールの承認フローを、そのままステータスに写している
• 「確認中」「処理中」「完了」の意味が曖昧なまま作っている
• 作業者を人名で固定し、異動や休暇に弱い
• 差し戻し後に何を修正できるか決まっていない
• 条件分岐を増やしすぎて、テストできない
• 通知を全員に出して、誰が次に動くのか分からない
• 承認済み後も金額や添付資料を自由に編集できる
• テストレコードで却下、差し戻し、再申請、期限超過を確認していない
• 運用開始後に、滞留や差し戻し理由を見直していない

kintoneワークフローの作り方で重要なのは、設定画面の順番だけではありません。

設定前に、業務を状態遷移として整理することです。

kintoneワークフローは、プロセス管理の設定画面から作り始めるのではなく、「現行業務の状態・作業者・判断・通知」を表にしてから作る方が安定します。

この記事では、kintoneワークフローの作り方を、現状業務の棚卸し、ステータス定義、作業者、アクション条件、通知、権限、テスト、運用後の見直しまで、実務で作る順番に沿って整理します。

kintoneワークフローの設計方法はこちら
kintone承認フローの設計方法はこちら

先に結論：作り方は「設定」ではなく「棚卸し」から始める

kintoneワークフローは、次の順番で作ると崩れにくいです。

順番	やること	成果物
1	現行業務を棚卸しする	申請、承認、差し戻し、完了までの流れ
2	申請レコードを決める	何を1件の申請として扱うか
3	ステータスを決める	下書き、承認待ち、差し戻し、完了など
4	作業者を決める	各状態で誰が次に動くか
5	アクションを決める	申請する、承認する、差し戻すなど
6	条件分岐を決める	金額、申請種別、部門など
7	通知と一覧を決める	承認待ち、期限超過、差し戻し中
8	権限と編集制御を決める	承認後に固定する項目
9	テストレコードで確認する	通常、差し戻し、却下、例外のテスト
10	運用後に棚卸しする	滞留、差し戻し理由、不要な通知の見直し

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

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

この3つは、設定項目であると同時に、業務の整理項目です。

ステータスは、申請レコードの状態です。

作業者は、次に動く人です。

アクションは、状態を進める操作です。

つまり、kintoneに設定する前に、紙やExcelやメールで行っている申請を、この3つに分解できる必要があります。

分解できないまま設定すると、画面にはボタンが出ても、現場では「誰が何をすればいいのか分からない」状態になります。

まず紙やExcelの承認フローを棚卸しする

最初にやるのは、今の承認フローをそのまま書き出すことです。

きれいに整理する必要はありません。

まず、現場で実際に起きている流れを出します。

見るもの	確認すること
紙の申請書	項目、押印欄、差し戻しメモ、添付資料
Excel台帳	ステータス、担当者、承認日、完了日
メール承認	誰に送っているか、何を見て承認しているか
チャット連絡	どこで催促、確認、差し戻しが発生しているか
会議・口頭確認	システム外で決まっている判断
後続処理	承認後に、発注、支払、契約、勤怠などへ渡るか

次に、1件の申請がどの状態を通るかを書きます。

たとえば、簡単な備品購入申請なら、次のようになります。

現在の状態	次に動く人	判断・作業	次の状態
下書き	申請者	内容と見積書を入力する	申請中
申請中	上長	業務上必要か確認する	承認済み、差し戻し、却下
差し戻し	申請者	理由を見て修正する	再申請
承認済み	総務	発注や購入を進める	完了
却下	申請者	今回は進めない	終了

ここで大事なのは、理想のフローではなく、実際に起きている例外も書くことです。

差し戻し。

却下。

申請者の取り下げ。

承認者不在。

金額変更。

添付資料の不足。

承認後の変更。

これらを最初に出しておくと、後でプロセス管理の設定を増やしすぎずに済みます。

現行フローの棚卸しでは、正常ルートよりも、差し戻し・却下・取り下げ・承認後変更を先に拾う方が実務に近いワークフローになります。

申請レコードとフォーム項目を決める

ワークフローは、レコードを進める仕組みです。

そのため、まず何を1件の申請レコードにするかを決めます。

経費精算なら、1回の精算申請か、1つの経費明細か。

見積承認なら、1つの見積ヘッダーか、見積明細ごとか。

休暇申請なら、1回の休暇申請か、半休や時間休を分けるか。

ここが曖昧だと、ステータスも作業者も決まりません。

業務	1レコードの候補	注意点
経費精算	1回の精算申請	明細や証憑をどう持つか
見積承認	1つの提出見積	版管理と明細をどう分けるか
休暇申請	1回の休暇申請	勤怠管理との連携をどうするか
購買申請	1つの購入依頼	発注や納品後の処理をどう追うか
契約確認	1つの契約案件	契約書ファイルと承認履歴をどう残すか

フォーム項目は、ワークフローで使う項目を先に決めます。

項目	使いどころ
申請種別	承認ルートや必要項目を分ける
申請者	差し戻し先、起票者の記録
部門	部門承認、集計、予算確認
金額	金額分岐、予算確認
添付資料	見積書、請求書、証憑、契約書
承認者候補	作業者や通知先の候補
差し戻し理由	再申請時の修正内容
承認コメント	判断の根拠
期限	承認期限、対応期限、実施日
後続処理状態	承認後の発注、支払、契約、勤怠反映

ワークフローを作る前に、これらの項目がフォームにあるか確認します。

金額分岐をしたいのに金額項目がない。

部門ごとに承認者を分けたいのに部門項目がない。

差し戻し理由を一覧で見たいのに理由項目がない。

この状態では、プロセス管理を設定しても運用しづらくなります。

kintone経費精算の設計方法やkintone見積書作成の設計方法でも整理したように、業務データの正本を先に決めると、ワークフローも設計しやすくなります。

ステータスを決める

ステータスは、申請レコードの現在状態です。

ステータス名は、できるだけ「誰が何を待っているか」が分かる名前にします。

弱いステータス名	改善例
確認中	上長承認待ち、経理確認中
処理中	発注処理待ち、支払処理中
完了	承認済み、支払済み、契約締結済み
保留	申請者修正待ち、管理部門確認待ち
再確認	差し戻し中、再申請待ち

最初からステータスを増やしすぎないことも重要です。

小さな申請なら、次の程度から始めます。

ステータス	意味	次に動く人
下書き	申請者が入力中	申請者
承認待ち	承認者が確認中	承認者
差し戻し	修正が必要	申請者
承認済み	承認が完了	次工程担当者
却下	今回の申請は通さない	申請者
完了	後続処理まで終了	関係者は参照中心

複数段階の承認がある場合だけ、一次承認待ち、最終承認待ち、経理確認中などを追加します。

ステータスは、画面上の表示名ではありません。

責任の置き場所です。

誰の作業で止まっているかが分からないステータスは、一覧や通知でも役に立ちません。

kintoneワークフローの設計方法で整理したように、ステータスは業務上の責任分界として設計します。

作業者と承認者を決める

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

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

この2つは似ていますが、同じではありません。

たとえば、承認済み後の発注処理では、作業者は総務担当です。

しかし、その人は承認者ではありません。

役割	意味	例
申請者	起票した人	経費申請者、休暇申請者
承認者	内容を判断する人	上長、部門長、管理部門
作業者	現在ボタンを押せる人	承認者、経理、総務、契約担当
閲覧者	状況を見る人	管理者、関係部署
次工程担当者	承認後に処理する人	発注、支払、契約、勤怠担当

kintoneの作業者設定では、ユーザー、組織、グループ、フィールドの値などを使って作業者を指定できます。

kintoneヘルプ：作業者の設定

実務では、人名固定よりも、ユーザー選択フィールドや役割で指定する方が保守しやすいです。

たとえば、申請レコードに「一次承認者」「経理確認者」「次工程担当者」というユーザー選択フィールドを持たせ、そのフィールドを作業者として使います。

作業者の指定方法	向いているケース	注意点
固定ユーザー	小さなチーム、管理者のみ	異動や退職で古くなる
組織	部門内の誰かが対応する	誰が責任者か曖昧になりやすい
グループ	役割で管理したい	グループ管理の運用が必要
ユーザー選択フィールド	レコードごとに承認者が違う	入力漏れや誤指定を防ぐ必要がある
ルックアップ・マスタ	社員や部門マスタから自動指定	マスタ整備が必要

作業者を決めるときは、通知先も同時に考えます。

作業者にした人が、次に何をするのか。

いつまでに対応するのか。

期限を過ぎたら誰が見るのか。

ここまで決めておくと、通知設定が増えすぎません。

アクション名と遷移先を決める

アクションは、ステータスを次へ進める操作です。

アクション名は、ユーザーが押すボタン名になります。

そのため、短く、意味が誤解されない名前にします。

アクション名	遷移先	使いどころ
申請する	承認待ち	下書きから提出する
承認する	承認済み、次承認待ち	内容を通す
差し戻す	差し戻し	修正を依頼する
却下する	却下	今回の申請を通さない
取り戻す	下書き	申請者が提出を取り下げる
再申請する	承認待ち	修正後に再提出する
完了にする	完了	後続処理が終わった

「OK」「処理」「次へ」のような名前は避けた方がよいです。

何を判断したのか、後から分かりにくくなります。

kintoneのプロセス管理では、アクションごとに実行前のステータス、実行後のステータス、作業者、条件を設定します。

公式ヘルプの申請ワークフロー設定例でも、差し戻し、複数承認者、条件分岐などの典型的な設定パターンが紹介されています。

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

設定するときは、次の表を先に作ります。

実行前ステータス	作業者	アクション名	実行後ステータス	条件
下書き	申請者	申請する	承認待ち	必須項目が入力済み
承認待ち	一次承認者	承認する	承認済み	金額が10万円未満
承認待ち	一次承認者	部長承認へ回す	部長承認待ち	金額が10万円以上
承認待ち	一次承認者	差し戻す	差し戻し	差し戻し理由あり
差し戻し	申請者	再申請する	承認待ち	修正済み
承認済み	次工程担当者	完了にする	完了	後続処理済み

この表がないまま設定すると、後からアクションが増え、テストが難しくなります。

プロセス管理の設定前に、実行前ステータス、作業者、アクション名、実行後ステータス、条件を1行ずつ表にします。表にできないフローは、kintone上でも説明しにくいです。

条件分岐と差し戻しを設定する

条件分岐は、ワークフローを便利にします。

ただし、増やしすぎると運用できません。

最初は、次の3つに絞るのが現実的です。

条件	例	注意点
申請種別	経費、購買、契約、休暇	種別ごとに必要項目が違う
金額	10万円以上は部長承認	判定金額を固定する
部門・役割	部門長、経理、管理部門	組織変更への対応が必要

kintoneでは、アクションが実行できる条件を設定できます。

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

たとえば、金額が一定以上なら部長承認へ進める、申請種別が契約なら管理部門確認へ進める、といった設計ができます。

ただし、条件は設定できるから増やすのではありません。

業務上、承認者や処理が変わる条件だけを設定します。

差し戻しも、最初から設計します。

差し戻しで決めること	例
差し戻し理由	添付不足、金額不一致、説明不足、承認者違い
修正できる項目	申請理由、添付資料、金額、申請種別など
再申請後の戻り先	一次承認へ戻す、最初から承認し直す
通知先	申請者、必要に応じて承認者
履歴	差し戻し者、日時、理由、修正内容

kintone承認フローの設計方法でも整理したように、差し戻しは「戻るボタン」ではなく、再申請に必要な修正情報を渡す操作です。

差し戻し理由をコメントだけにせず、カテゴリ項目と自由記述を分けて持つと、運用後に改善しやすくなります。

通知と権限を設定する

ワークフローを作るとき、通知は最後に足すものではありません。

ステータスと作業者が決まった時点で、通知先も決めます。

ただし、通知は増やしすぎない方がよいです。

タイミング	通知先	目的
申請された	承認者	承認依頼
差し戻された	申請者	修正依頼
承認済みになった	次工程担当者	後続処理
期限を過ぎた	作業者、上長	滞留確認
却下された	申請者	結果共有

通知だけで運用しようとしないことも重要です。

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

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

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

状態	申請者	承認者	次工程担当者	管理者
下書き	編集可	原則不要	原則不要	閲覧可
承認待ち	原則編集不可	判断・コメント	原則不要	閲覧可
差し戻し	指定項目を編集	閲覧	原則不要	閲覧可
承認済み	原則編集不可	閲覧	後続処理項目を更新	閲覧可
完了	原則編集不可	閲覧	閲覧	管理項目のみ編集

kintoneの標準機能だけで、ステータスごとの細かな入力制御をすべて表現するのが難しい場合もあります。

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

最初からすべてを制御しようとするより、承認後に変わると困る項目を優先して固定します。

金額、取引先、申請種別、添付資料、支払条件などです。

テストレコードで確認する

ワークフローは、設定して終わりではありません。

必ずテストレコードで確認します。

特に、正常ルートだけを確認して終わらせないことです。

テストケース	確認すること
通常申請	下書きから承認済み、完了まで進むか
差し戻し	申請者へ戻り、理由が残るか
再申請	修正後に正しい承認者へ戻るか
却下	今回の申請が終了するか
金額分岐	しきい値前後で正しいルートに進むか
申請種別分岐	契約、購買、休暇などでルートが変わるか
承認者不在	代理や管理者対応ができるか
期限超過	一覧や通知で気づけるか
承認後変更	重要項目が勝手に変わらないか
権限	見えてはいけない人に見えていないか

テストでは、実際のユーザー権限で確認します。

管理者権限だけで確認すると、現場ユーザーではボタンが見えない、編集できない、通知が届かない、といった問題を見落とします。

テストレコードには、金額境界の前後を入れます。

99,999円。

100,000円。

0円。

添付なし。

申請種別違い。

承認者未設定。

こうした例外を確認しておくと、運用開始後の手戻りが減ります。

ワークフローのテストは、正常ルートではなく、差し戻し・却下・金額境界・承認者未設定・承認後変更から確認します。

運用開始後に見直すポイント

ワークフローは、作って終わりではありません。

運用開始後に、どこで止まっているかを見ます。

見直し項目	確認すること
承認待ち件数	特定の承認者で滞留していないか
差し戻し理由	添付不足、説明不足、金額不一致が多くないか
期限超過	通知や一覧が機能しているか
不要な通知	読まれていない通知がないか
条件分岐	使われていない分岐がないか
権限	見えてはいけない申請が見えていないか
承認後変更	再承認なしの変更が起きていないか
次工程	承認済みで止まっていないか

最初の1か月は、週1回でよいので棚卸しします。

承認待ち一覧を見て、止まっている申請を確認します。

差し戻し理由を見て、入力フォームや説明文を直します。

通知が多すぎる場合は、条件を減らします。

条件分岐が多すぎる場合は、承認ルートを統合します。

ワークフローは、最初から完璧に作るより、テストしやすい形で始めて、運用データを見ながら削る方が安定します。

作り込みすぎない判断

kintoneのプロセス管理は便利ですが、ワークフロー専用システムではありません。

次のような要件が強い場合は、標準機能だけで作り込むより、プラグイン、カスタマイズ、専用ワークフロー連携を検討します。

要件	判断
複雑な組織階層に応じて承認者を自動決定したい	専用ワークフローや人事マスタ連携を検討
全社の申請を横断管理したい	申請基盤の設計が必要
厳密な代理承認、引き上げ、一括承認が必要	標準機能だけでは運用が重くなりやすい
監査向けに承認履歴を厳密に出力したい	承認履歴アプリや外部連携を検討
契約、購買、会計へ自動連携したい	連携ログと責任分界が必要
申請種別が多すぎる	アプリ分割や専用システムを検討

日立ケーイーシステムズの記事でも、kintoneワークフローの基本的な設定手順だけでなく、運用時の注意点や対応が難しい領域が整理されています。

日立ケーイーシステムズ：kintoneのワークフロー機能とは？

kintoneで作るべきなのは、すべての承認機能ではありません。

業務データと状態管理をkintoneに置き、複雑な承認統制だけ外部へ任せる構成もあります。

まとめ：作り方は、業務を状態遷移にしてから設定する

kintoneワークフローの作り方は、プロセス管理の画面操作だけではありません。

まず、紙、Excel、メールで行っている承認フローを棚卸しします。

次に、申請レコード、ステータス、作業者、アクション、条件分岐、通知、権限を表にします。

そのうえで、kintoneのプロセス管理に設定します。

最後に、テストレコードで、通常ルート、差し戻し、却下、金額分岐、承認者未設定、承認後変更を確認します。

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

Bitlightでは、kintoneワークフローの作成について、現行業務の棚卸し、申請アプリ設計、プロセス管理設定、通知、権限、テストケース、運用後の見直しまで一緒に整理できます。

「設定はできたが運用で止まっている」「差し戻しや承認後変更で崩れている」「どこまでkintoneで作るべきか判断したい」という場合は、設定画面だけでなく、業務フローそのものから見直すのが近道です。