kintoneプロセス管理の使い方｜承認フロー設定と分岐の型

「あの申請、いま誰のところで止まってる？」

申請書は紙で回り、承認の依頼はメールで届き、催促は口頭。建設や不動産の事務所では、こうした形がいまも珍しくありません。誰の承認待ちなのかを知るには、人に聞いて回るしかなくなります。

kintoneの「プロセス管理」は、この状態を「いまどのステータスか」「次に動けるのは誰か」で見えるようにする標準機能です。ただ、機能があることは知っていても、触って既存の業務を止めてしまわないか不安で、手を付けられずにいる方もいらっしゃるでしょう。

この記事では、設定の前に決めておくことから、基本の設定手順、よくある承認フローの型、つまずいたときの確認順までを順に説明します。読み終えるころには、自社の承認フローをアプリに落とし込む手順を自分で組み立てられる状態を目指します。

プロセス管理とは何か——紙・メールの承認を3つの部品で動かす仕組み

プロセス管理は、レコード（1件1件のデータ）に「ステータス」を持たせ、ステータスを進める操作を「アクション」として、その操作ができる「作業者」を決める機能です。

部品	意味	申請書で言うと
ステータス	レコードがいまどの段階にいるか	「申請前」「申請中」「承認済」の判子欄
アクション	ステータスを次へ進める操作（ボタン）	「承認する」「差し戻す」を押す動作
作業者	そのアクションを実行できる人	次に判子を押す担当者

紙の申請書にたとえると、「いまどの机の上にあるか」がステータス、「判子を押して次の机へ回す」がアクション、「その机の持ち主」が作業者です。

設定の前に決めておくこと——承認ルートを書き出す

設定画面を触りながら考えると、途中で整合が取れなくなりがちです。画面を開く前に、紙1枚で次の4点を書き出しておくと迷いが減ります。

1. 段階数：申請者の次に何人が承認するか（例：上長のみ、上長→部長）
2. 各段階の担当：個人で決まっているのか、部署の誰か1人でよいのか
3. 差し戻しの行き先：差し戻したら申請者に戻すのか、1つ前の承認者に戻すのか
4. 条件で分かれるケース：金額や区分によって、承認者や段階が変わるか

書き出した内容は、そのままステータスとアクションの一覧表に変わります。たとえば「申請→上長が承認→完了」なら、ステータスは3つ、アクションは「申請する」「承認する」の2つです。

既存の業務を止めたくない場合は、いきなり本番のアプリに設定しないでください。まずテスト用のアプリを1つ作り、同じ項目を数個だけ入れて、設定と動作を一通り試します。流れを確認してから本番へ移せば、失敗しても業務への影響は出ません。

基本の設定手順——ステータス・作業者・アクション

公式ヘルプの設定例は、「物品購入申請アプリ」を題材に5つのステップで構成されています。

1. 設計の準備
2. プロセス管理の有効化
3. ステータスの設定
4. プロセスの設定
5. フロー図の確認と更新

この記事でも、物品購入申請を例に進めます。

ステップ1〜2：設計と有効化

設計の準備は、前の章で書き出した内容がそのまま使えます。そのうえで、プロセス管理を有効にします。

有効にする前に登録済みのレコードがある場合は注意が必要です。有効にする前に登録したレコードは最初のステータスになり、作業者は設定されません。 以前から運用しているアプリへ後から入れるときは、既存データがその状態になることを前提にしてください。

ステップ3：ステータスを設定する

公式の例では、最初が「申請前」、その後ろが「申請中」「承認済」です。自社の承認ルートに合わせて、名前と数を整えます。

名前は、画面を見た人が説明なしで意味が分かる言葉にします。「処理中」より「上長確認中」のように、誰の手元にあるかが分かる名前のほうが、「いまどこ？」と聞いて回る手間を減らせます。

最初のステータスは新しく追加できず、既存のものの名前を変更する形になります（API仕様）。名前は変えられるので、「申請前」など自社の言葉に直しておきましょう。

ステップ4：プロセスを設定する

ここが中心の作業です。1つのアクションごとに、次の5つを決めます。

項目	内容
アクション実行前のステータス	どの段階のレコードで押せるか
作業者	誰が押せるか
アクションが実行できる条件	どんなレコードのときに押せるか
アクション名（ボタン名）	画面に表示されるボタンの名前
実行後のステータス	押したあと、どの段階へ進むか

最初のプロセスの作業者は「作成者」を選びます。申請を作った本人が、最初の「申請する」ボタンを押す形です。後続のプロセスでは、次の章で説明する3つの方式から選びます。

アクション名は、ステータスと区別しておくと混乱しません。ステータスが「上長確認中」なら、アクションは「承認する」「差し戻す」のように、動詞で書きます。

ステップ5：フロー図を確認して更新する

設定が終わったら、フロー図で流れを確認し、問題がなければ更新して反映します。ここで見るのは、行き止まりのステータスがないか、差し戻しのアクションが抜けていないかの2点です。

テスト用アプリでの確認では、申請者・承認者の両方のユーザーで実際にレコードを動かし、ボタンの出方まで見てください。設定画面の見た目が正しくても、押せる人が想定と違うことがあります。

作業者の指定方式の違い——選択・全員・1人のうち誰か

後続のプロセスで作業者を決めるとき、画面では次の3つから選びます。

• 次のユーザーから作業者を選択
• 次のユーザー全員
• 次のユーザーのうち1人

承認の性質によって、使い分けの考え方が変わります。

方式	動き	使いどころの考え方
次のユーザーから作業者を選択	対象の候補の中から、次に動く人を選んで進める	承認者が案件によって変わるとき
次のユーザー全員	指定した全員が実行する	複数の部署の確認がそろって初めて進めたいとき
次のユーザーのうち1人	指定したうちの誰か1人が実行すればよい	経理部の誰かが確認すれば足りる、といった担当者の代替が利くとき

これはAPI仕様の説明にある ONE（指定ユーザーから1人を選んで実行）、ALL（指定ユーザー全員が実行）、ANY（指定ユーザーのうち誰でも実行）と対応しています。ただし、画面の表示名とこれらの対応は、公式の説明文からの推定を含みます。画面で選ぶときは、表示されている名前と説明文を基準にしてください。

「全員」は指定した全員が実行する方式なので、1人でも動けない人がいれば進みません。出張や休みの多い部署に使うと、承認が止まる原因になります。迷ったら、まず「1人」で始めて、複数の確認が本当に必要になった段階で「全員」に切り替えるほうが安全です。

承認フローの型を設定する——1段階・多段階・差し戻し・金額による分岐

よく使う承認フローは、大きく4つの型に分けて考えられます。

型1：1段階承認

申請者が申請し、承認者が1人承認して完了する、最小の型です。

• ステータス：申請前 → 承認待ち → 承認済
• アクション：「申請する」「承認する」

まずはこの型でテスト用アプリに組み、仕組みに慣れるのがおすすめです。

型2：多段階承認

承認者が複数いる型です。たとえば上長→部長の2段階なら、ステータスは「申請前」「上長確認中」「部長確認中」「承認済」の4つ、アクションは「申請する」「上長承認」「部長承認」の3つです。段階が増えるほど、ステータスとアクションも増えます。

型3：差し戻しと再申請

承認者が内容に不備を見つけたとき、申請者へ戻すためのアクションを別に用意します。たとえば「上長確認中」のステータスに「差し戻す」のアクションを追加し、実行後のステータスを「申請前」に戻す形です。

差し戻しを後から足すと、設定の見直しが増えます。最初から、各承認段階に「承認」と「差し戻し」の2つのアクションを並べておきましょう。

型4：金額などの条件による分岐

「少額は上長だけ、高額は部長まで」のように、承認ルートを分けたい場合は、アクションの「実行できる条件」を使います。同じステータスに、条件の異なるアクションを複数並べる、という考え方です。

たとえば「上長確認中」に、次の2つを用意するイメージです。

• 金額が一定未満のとき押せる「承認して完了」→ 実行後は「承認済」
• 金額が一定以上のとき押せる「部長へ回す」→ 実行後は「部長確認中」

実行条件は、レコードの項目を使った条件式（クエリ形式、API上の名前は filterCond）で指定できます。API仕様の例は「レコード番号 = “1”」です。

なお、金額による分岐の画面手順そのものは、確認できた範囲では公式の記載を取れていません。実際に組む際は、公式ヘルプの画面の説明と、テスト用アプリでの動作確認を併用してください。条件が増えるほど、どのレコードがどの道を通るかが分かりにくくなるので、フロー図を紙に書いて確認することを勧めます。

業務別の当てはめ例——稟議・問い合わせ・採用選考

ここでは、考え方をつかむためのステータス設計の例を挙げます。公式の事例ではなく、一般的な例示です。

業務	ステータスの並び（例）	ポイント
稟議・経費申請	申請前 → 上長確認中 → 経理確認中 → 承認済（差し戻しは申請前へ）	金額で承認者が変わるなら、前章の分岐を使う
問い合わせ対応	未対応 → 対応中 → 確認待ち → 完了	承認ではなく「進捗の見える化」が目的。作業者は担当者を選択する方式が合いやすい
採用選考	応募受付 → 書類選考 → 面接 → 内定 / 見送り	結果が複数に分かれるので、最終段階に複数のアクションを並べる

自社製品の話をすると、在庫管理スターターパックは、入出庫の申請から承認、在庫への反映までをプロセス管理で設定しています。在庫数を直接編集させず、申請と承認を通して反映する設計にすると、同時に更新したときの競合を構造的に避けられます。承認フローは、書類を回す以外にも、データの入口を整理する用途に使えます。

つまずきやすい点——症状から確認する順番

設定後に「ボタンが出ない」「動かない」となったときの、確認する順番をまとめます。

症状	確認すること
アクションのボタンが出ない	実行前のステータスは合っているか／自分が作業者に指定されているか／実行できる条件を満たしているか
承認者が動けない・進まない	作業者の方式が「全員」になっていないか／作業者が利用停止になっていないか
設定を変えたのに既存レコードが変わらない	変更後も、作成済みレコードの作業者は変わらない
作業者の指定方法を変更できない	そのステータスに、作業者が指定されたレコードが残っていないか

運用が始まってから気づきにくいものが3つあります。

利用を停止したユーザーが作業者のまま残っている。 異動や退職で利用を停止したユーザーが作業者に指定されたままだと、そのレコードのステータスを変更できなくなります。別のユーザーへの変更が必要です。

設定を変えても、作成済みのレコードの作業者は変わらない。 必要に応じて、アプリ管理者が個別に対応します。

作業者の指定方法を変えようとしても、変えられない。 そのステータスに作業者が指定されたレコードがあると変更できません。レコードを削除するか、別のステータスへ移す必要があります。

最後に、確認が取れなかった点も正直に書いておきます。

• 通知：プロセス管理の通知の設定場所と、通知が届く条件は、確認できた範囲では公式の記載を取れていません。「通知が届かない」場合は、公式ヘルプで通知の設定場所を確認してください。
• レコードが見えない：作業者に指定されたユーザーが、レコードを閲覧するために必要な権限（アクセス権との関係）も、公式の直接の記述を確認できていません。作業者のはずなのにレコードが見えないときは、アプリやレコードのアクセス権の設定も合わせて見る必要があります。
• 一括承認：画面からの一括承認が可能とする公式の記載は、確認した範囲では見つかりませんでした。公式が示しているのは、REST APIでの複数レコードの更新です。一度に更新できるのは最大100件で、101件以上はエラーになります。

また、API経由でステータスを更新する場合は、ユーザー認証ならレコードの作業者が未指定か、実行ユーザーが作業者であるときに実行できます。変更先の作業者が「次のユーザーから作業者を選択」で選べるユーザーがいるときは、assignee の指定が必須です。

自社の業務に当てはめる考え方——まとめ

最後に、自社の承認フローを落とし込むときの進め方を整理します。

1. 今の紙やメールの流れを、そのまま書き出す。 理想の形に整える前に、実際に今どう回っているかを表にします。建設業の事務所なら、現場監督が発注書を書き、事務員が金額を確認し、所長が押印する、といった実際の流れです。

2. 書き出した各「机」をステータスに、各「判子」をアクションに置き換える。 机が4つならステータスは4つです。

3. 例外の扱いを後回しにしない。 現場でよくあるつまずきは、「普段は1人が承認するが、その人が不在のとき誰が代わりに押すか」が決まっていないことです。設定したあとで、「所長が出張中で、承認が止まった」という事態が起きます。作業者を「1人」方式にして、代替できる複数の担当者を指定しておくと、この種の停滞を防ぎやすくなります。

4. テスト用アプリで確認してから、本番に移す。

画面を見ながら一緒に設計を整理したい場合は、無料相談でも確認できます。

プロセス管理は、一度に完璧な仕組みを作る機能ではありません。1段階の承認から始めて、運用しながら差し戻しや分岐を足していく使い方でも、「誰の承認で止まっているか」は見えやすくなります。まずはテスト用アプリで、ステータス3つ、アクション2つの最小構成から試してみてください。