kintone承認フローの作り方｜「承認待ち」を減らすプロセス管理・通知・期限設計

※本記事は2026年9月15日時点のkintone公式情報を確認して執筆しています。

※本記事では、テーマに関連する選択肢として、株式会社エイチが提供する「1Approval」を紹介しています。

申請を紙やメールからkintoneへ移したのに、「承認お願いします」というチャットが減らない。数日後には申請者が状況を確認し、総務が承認者を探し、月末には止まった案件を人力で掘り起こす。

これはkintoneの機能不足ではありません。多くの場合、フォームは作ったものの、誰が・いつまでに・何を判断し、止まったら誰が拾うかまで設計されていないことが原因です。

kintoneの承認フローで大切なのは、承認ボタンの数ではなく「次の一人が迷わず動ける状態」をつくること。本記事では、プロセス管理、一覧、通知、アクセス権をどう組み合わせるかを、出張申請の具体例と公開前テストまで含めて解説します。

kintoneの承認フローは4機能で設計する

kintone公式ヘルプでは、プロセス管理をステータス・作業者・アクションの組み合わせとして説明しています。ただし、プロセス管理だけを有効にしても承認待ちは減りません。実務では次の4機能を一つの仕組みとして設計します。

• プロセス管理：いまの状態、次の作業者、実行できるアクションを決める

• 一覧：本人が処理すべき案件を、探さなくても見つけられるようにする

• 通知：次に行動が必要になった瞬間だけ知らせる

• アクセス権：申請中・承認後に誰が閲覧・編集できるかを制御する

この4つは別々に設定できますが、利用者から見れば一つの体験です。「通知が来た→自分の未処理一覧を開いた→必要な情報を確認した→承認した」という流れが途切れないことが重要です。

最初に決めるのは画面ではなく「4つの業務ルール」

設定画面を開く前に、一枚の表へ次の4項目を書きます。

1. 現在の状態：下書き、申請中、承認済みなど

2. 次に動く一人：個人、ユーザー選択フィールド、組織・グループ

3. 期限：何営業日、または何月何日何時までか

4. 完了条件：何を確認できれば次へ進めてよいか

「上長が承認する」だけでは設計として不十分です。見積書が添付され、訪問目的と金額が入力されていれば承認できるのか。金額が一定以上なら部長確認が必要なのか。承認者が休暇中なら誰が判断できるのか。ここを決めずに実装すると、例外のたびにチャットと口頭確認へ戻ります。

出張申請は5ステータスから始める

複雑な組織図をそのままフローにすると、状態と分岐が増え、管理者にも利用者にも読めなくなります。最初は次の5ステータスで十分です。

1．下書き

申請者が入力中の状態です。本人だけが編集できるようにし、未完成の内容を承認者へ通知しません。

2．申請中

承認者が判断する状態です。kintoneでは、ユーザー選択フィールドを作業者として指定できます。固定の個人名を設定へ埋め込むより、申請レコードの「承認者」欄を参照するほうが、部署や案件ごとの担当変更に対応しやすくなります。

作業者にはレコードの閲覧権限も必要です。公式ヘルプでは、編集権限がなくてもアクション実行は可能ですが、閲覧権限がなければレコードを開けず、承認操作もできないと案内されています。

3．差し戻し

申請者が修正する状態です。「差し戻し理由」をコメントだけに残すと、一覧で集計できず、同じ不備が繰り返されます。理由の分類と具体的な修正内容をフィールドに分けると、申請フォームの改善材料になります。

4．承認済み

社内判断が終わった状態です。金額、用途、訪問先など承認根拠になった項目を後から自由に変更できると、承認履歴の意味が薄れます。ステータスに応じたレコード・フィールド権限を組み合わせ、修正が必要なら差し戻しや再申請へ戻します。

アクセス権の3層設計は、関連記事「kintoneアクセス権の設定方法｜3層の違いと情報漏えいを防ぐ設計・テスト」で詳しく整理しています。

5．手配完了

予約や発注まで終わった状態です。出張・購買業務では「承認済み」と「実行済み」は同じではありません。承認後に別サイトで予約するなら、誰が手配し、どの番号をkintoneへ戻し、価格が変わった場合に再承認するかまで決めます。

金額分岐は「承認者を増やす前」に条件を整理する

kintoneでは、フィールド値を使ってアクションの実行条件を設定できます。例えば、10万円未満は課長承認、10万円以上は部長承認へ進める設計が可能です。

ただし、金額帯ごとに分岐を足し続けると、どのルートを通るか誰も説明できなくなります。分岐を追加する前に、次を確認します。

• 金額以外に、取引先区分や契約期間など判断条件はあるか

• 承認者が不在でも代理可能な判断か

• 複数承認は全員の確認が必要か、誰か一人でよいか

• 例外条件が重なったとき、どちらを優先するか

アクション名も「処理する」ではなく、「部長承認へ回す」「申請者へ差し戻す」のように、押した後の状態が分かる言葉にします。利用者がボタンを押すたびにマニュアルを開く設計は定着しません。

一覧は「データを見る場所」ではなく仕事の入口にする

全件一覧しかないと、承認者は毎回フィルターをかけ、自分の案件を探します。数件なら我慢できますが、忙しい人ほど後回しになり、催促が増えます。

最低でも次の一覧を用意します。

• 自分が申請した未完了案件

• 自分が現在の作業者になっている案件

• 期限を過ぎた未処理案件

• 承認済みだが手配未完了の案件

一覧名は「申請一覧」ではなく、「自分が承認する申請」「手配待ち」のように、開いた人の次の行動が分かる名前にします。期限、申請者、金額、判断材料を一画面で比較できる列順にし、詳細を開かないと優先順位を判断できない状態を避けます。

通知は増やすのではなく、役割ごとに3種類へ絞る

プロセス管理で作業者になったユーザーには「自分宛」の通知が届き、ポータルの未処理件数から対象レコードを確認できます。一方、申請者へ承認完了を知らせたい場合は、レコードの条件通知などを別途設定する必要があります。

通知は次の3種類から始めると整理しやすくなります。

• 承認者：自分が作業者になった時。次の行動は承認または差し戻し

• 申請者：承認・差し戻し時。次の行動は確認または修正

• 管理者：期限超過時。次の行動は原因確認と担当調整

単なる項目更新まで全員へ通知すると、本当に必要な通知が埋もれます。また、通知の見出しにはレコードタイトルが表示されるため、タイトルに何の申請か分からない番号だけを使うと通知一覧の価値が下がります。「申請種別｜申請者｜利用日」のように、機密性へ配慮しつつ判断できるタイトルを設計します。

期限超過の検知には、日付・日時フィールドを基準に送れるリマインダーの条件通知が使えます。ただし、通知を送るだけでは解決しません。何日止まったら誰が確認し、代理判断できるかまで運用ルールへ落とします。

承認依頼を、メールではなくTeamsで確実に届ける方法はこちらで解説しています。
→ kintoneとTeamsを連携する方法4選｜2026年版・連携コネクタとPower Automateの選び方

見落とされやすい5つの落とし穴

作業者を部署全員にして責任者が消える

「誰か一人が処理すればよい」は便利ですが、担当が明確でなければ全員が他の人を待ちます。最終責任者を一人置き、代理者は例外として定義します。

作業者を設定せず、全員にボタンが見える

公式ヘルプでは、作業者を設定した場合は作業者だけにアクションボタンが表示され、作業者を設定しない場合はすべてのユーザーに表示されると説明されています。テスト用の仮設定を残したまま公開しないよう注意が必要です。

途中からプロセス管理を有効にして既存レコードを忘れる

有効化前に登録されたレコードは最初のステータスになりますが、作業者は設定されません。ステータスを変更すると作業者設定が反映されます。既存レコードを何件移行し、誰が状態を進めるかを公開前に決めます。

組織変更で過去の作業者も変わると思い込む

組織・グループのメンバーを変更しても、すでにアクションを実行したレコードの現在の作業者は自動変更されません。異動時はユーザー管理だけで終わらせず、止まっている案件の作業者も棚卸しします。

承認を業務の終点にする

承認後の予約、発注、支払い、経費精算が別作業なら、利用者の負担は残ります。「判断が終わった」と「業務が完了した」を分け、後工程の状態まで可視化します。

公開前は4役×5場面で試す

管理者アカウントだけで確認すると、広い権限のせいで問題を見落とします。申請者、通常承認者、代理承認者、対象外ユーザーの4役を用意し、架空データで次の場面を試します。

1. 通常申請から承認まで

2. 必須情報が不足した差し戻し

3. 金額条件による承認ルートの分岐

4. 承認者不在と代理対応

5. 承認後の内容修正と手配完了

結果は成功・失敗だけでなく、「迷った箇所」「口頭説明が必要だった箇所」「通知を見落とした理由」まで残します。説明を何度も求められる場所は、利用者の能力ではなく設計に問題がある可能性があります。

改善指標は承認時間だけを見ない

月に一度、次の数字を確認します。

• 申請から最初の承認までの中央値

• 期限超過件数と、その理由

• 差し戻し率と、理由別の件数

• 承認後から予約・発注完了までの時間

• チャットや口頭での催促回数

平均時間だけでは、一部の長期滞留が見えにくいため中央値と期限超過件数を併用します。通知を増やす前に、材料不足、作業者設定ミス、判断基準の曖昧さ、不在対応の欠如のどこで止まったかを分類すると、改善箇所が見えます。
原因別の切り分けと対策をさらに確認したい場合は、kintoneワークフロー承認遅延の原因と対策（1Approval）も参考になります。

1Approvalが埋めるのは「承認済み」と「実行済み」の間

出張や購買では、承認待ちの間に価格や在庫が変わり、承認後に再検索・再予約が必要になることがあります。社員の個人立替や月末の経費精算も、kintoneの承認フローだけでは自動的になくなりません。

株式会社エイチの1Approval for kintoneは、既存のkintone承認を起点に予約・購買へつなぎ、対象サービスの利用分を法人一括請求へまとめる中間Hubです。

重要なのは、外部連携を入れれば設計が不要になるわけではないことです。どのステータスで何のデータを渡すか、価格変動をどこまで許容するか、失敗時に誰が止めるかを決めて初めて、自動化が安全に回ります。

kintoneへAIを組み合わせる場合の権限・確認設計は「kintone AIは何ができる？検索AI・アプリ作成AIを導入する前の7項目」も参考にしてください。

まず一件の申請を、4項目で書き直す

最初から全社フローを作り直す必要はありません。止まりやすい申請を一件選び、「現在の状態」「次に動く一人」「期限」「完了条件」を書き出します。一つでも答えられなければ、ボタンを増やす前に業務ルールを決めるべき場所です。

承認待ちは、催促の回数ではなく設計で減らせます。次の一人が、自分の仕事と判断材料を一画面で理解できる状態から始めてください。

参考にした公式情報

• kintone ヘルプ「基本的なプロセス管理の設定」

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

• kintone ヘルプ「プロセス管理と組み合わせると便利な設定」

• kintone ヘルプ「リマインダーの条件通知」

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