kintone 稟議 申請の承認フロー｜プロセス管理で組める範囲

「稟議が紙とメールで回っていて、いま誰のところで止まっているか分からない」。 この相談はよく来ます。そしてkintoneで組めるかという問いへの答えは、 機能の話としては「組めます」です。申請書をアプリにして、承認の状態を進めていく形は、 kintoneが標準で持っている仕組みの範囲に収まります。

ところが実際に作り始めると、設定画面ではなく手前で止まります。 「この金額は誰の承認が要るのか」を決めようとした瞬間に、社内に答えがないことが分かるからです。 この記事では、プロセス管理で組める範囲を整理したうえで、 本当のボトルネックがどこにあるのか、そして先に何を決めておけば作業が進むのかを書きます。

プロセス管理でできること——申請を回す形自体は素直に作れる

kintoneには、レコードにステータスと作業者を持たせて、 状態を順に進めていく仕組みがあります。プロセス管理と呼ばれるものです。 「申請中」「一次承認済み」「決裁済み」のようにステータスを並べ、 それぞれの段で誰が処理するかを作業者として設定すると、 レコードは「いま誰のところにあるか」を自分で持つようになります。

だから、稟議書や購買申請、経費精算、値引き申請といった「1枚の紙が人を渡っていく」種類の業務は、素直にアプリの形に落ちます。 紙とメールで回していたときに手作業でやっていたことのうち、 次の3つは仕組みの側が持ってくれます。

金額で決裁者が変わる稟議も、標準機能の範囲で組めます。例えば同じステータスから出るアクションを2つ作り、金額が50万円未満と50万円以上の条件をそれぞれに付けます。行き先のステータスごとに作業者を別の決裁者に設定すれば、金額によって承認者が変わる稟議になります。 プロセス管理ではアクションごとに実行できる条件（例：金額が一定額以上）を設定でき、kintoneヘルプ「アクションが実行できる条件の設定」でも、金額による条件分岐の設定例が案内されています。 ステータス数や分岐数の上限値は、本記事では扱いません。

ここまでは、kintoneを触ったことのある方なら想像がつく範囲だと思います。 そして多くの記事はここで終わります。実務で問題になるのはこの先です。

本当に詰まるのは、決裁者を決める条件が社内で決まっていないところ

「承認フローが複雑でツールに載せられない」と言われるとき、 複雑なのはフローの形ではなく決裁者を決める条件です。 実際に出てくるのは、だいたいこの4つです。

• 金額で分岐する。ある額までは部長、それを超えると役員、 さらに超えると社長——という区切りがある
• 部署で分岐する。同じ金額でも、部門によって承認者と段数が違う
• 不在時に代理が立つ。承認者が出張や休暇のとき、 誰が代わりに通してよいのかが決まっている（つもりになっている）
• 途中で金額が上がったらやり直す。申請時の見積が上振れしたとき、 承認を取り直すのか、そのまま進めるのかが分かれる

問題は、この分岐の一覧が社内に文書として存在していないことです。 当社が支援の現場で見てきた傾向であり統計ではありませんが、 「決裁権限規程はあるが、金額の区切りが実態と合っていない」あるいは 「規程そのものが無く、経験のある人の頭の中にある」という状態はかなり多いです。 そして今までは、それで回っていました。判断できる人が社内にいて、 その人に聞けば答えが出たからです。

ここが核心です。アプリを作る作業は、そのまま決裁ルールを決める作業になります。 設定画面は「この条件のときは誰ですか」と聞いてきますが、 その質問は情報システムの質問ではなく、経営の質問です。 だから担当者だけでは埋められず、作業が止まります。 「kintoneでは複雑な承認フローが組めなかった」という感想の多くは、 実際には会社の側が条件を確定できなかったという出来事です。

止まり方には見分けがつく

ツールの制約で止まっているのか、ルールが無くて止まっているのかは、 症状で見分けられます。ツールの制約なら、要件は言えるのに実現方法が見つからない。 逆にルールが無い場合は、要件を書こうとすると誰かに確認しないと文が完成しません。 後者なら、設定を工夫しても解決しません。連携サービスやカスタマイズを検討しても、 同じ空欄を別の画面で聞かれるだけです。

決裁ルールを先に書き出す——申請の種類ごとに5項目

やり方はごく素朴です。申請の種類ごとに1行を用意して、次の5項目を埋めます。 スプレッドシートでも紙でもかまいません。kintoneはまだ触らないでください。

決裁表を埋めていくと、たいてい「いくらから誰の承認が要るか」「代理は誰か」「差し戻しはどこに戻るか」のどこかが空欄で残ります。 その空欄が、いま属人化している場所です。 裏を返せば、この表が埋まっていれば設定作業は淡々と進みます。 承認フローを組む前に業務そのものを並べ直したい場合は「業務の棚卸しのやり方」の手順が使えます。

kintoneで素直に解けない部分

決裁ルールが決まっていても、設計として引っかかる箇所はあります。 承認フローの周辺で当社がよく相談を受けるのは、次の3つです。

1. 承認済みの金額は計算フィールドで集計できない

「承認済みの稟議金額を積み上げて、予算の消化率を出したい」。 承認フローを作った次に必ず出てくる要望です。 ところがkintoneヘルプの「計算式で参照できるフィールド／参照できないフィールド」では、 ほかのアプリのレコードを表示する［関連レコード一覧］は計算式で参照できないとされています。 計算フィールドで承認済み稟議の金額を集めて合計する形にはなりません。

集計の表示と、予算への反映を分けて考える

• 合計を見る：一覧の集計やグラフで「承認済みの合計」を確認できます。見るだけなら、この方法で足ります。
• 別アプリへ手動で反映する：標準機能でヘルプが案内しているのは、集計結果をファイルに書き出して読み込ませる手順です。手作業が残ります。
• 承認のたびに自動更新する：別アプリの予算フィールドへの書き戻しには、外部連携やカスタマイズを検討することになります。

承認済み金額を予算アプリへ自動反映するには外部連携やカスタマイズが必要です。サイボウズの料金ページでは、外部サービス連携 （API・プラグイン・JavaScriptカスタマイズ）はライトコースでは使えず、 スタンダードコース以上（月額1,800円／1ユーザー・税抜、2026年8月時点の掲載）と案内されています。 自動反映まで必要かどうかで、契約するコースの前提が変わるので、 要件の順番を先に決めておくほうが安全です。

そもそもこの引っかかりは、cybozu developer networkの解説にある 「kintone の1つのアプリがリレーショナルデータベースの1つのテーブルに相当するように思えますが、 別物として考えることが重要です」という性質から来ています。 表計算やデータベースの発想で「集計して書き戻す」を前提に設計すると、 途中で必ずこの壁に当たります。案件別の積み上げについては「kintone 原価管理｜案件別の集計をどこまで載せられるか」で単独に扱っています。

2. ルックアップの落とし穴——過去の申請は古い値のまま残る

申請時に、社員マスタから部署名や上司をルックアップで取ってくる設計はよく使われます。 このとき知っておく必要があるのは、cybozu developer networkの解説にあるとおり、ルックアップは参照元が変わっても参照先のデータが自動では更新されないという性質です。更新するには取得ボタンを押し直すか、APIで更新する操作が必要になります。 一方で関連レコード一覧は、参照元の変更が自動的に反映されます。 また、ルックアップでコピーしたフィールドは編集できません。

申請時点を残すか、最新の組織を見せるか

これは不具合ではなく、どちらが欲しいかという選択です。 稟議の場合、「申請時点の所属と承認者を記録として残したい」なら、古いまま残るのが正しい挙動です。 異動後にマスタを直したら過去の稟議の部署名まで書き換わってしまうほうが、 記録としては困ります。

逆に「常に最新の組織図を見たい」なら、ルックアップでコピーするのではなく 関連レコード一覧で参照する形にするか、判断のたびにマスタを見る運用にします。どちらが欲しいかを先に決める。決めずに作ると、 後から「過去分も直してほしい」と言われて手作業の更新が発生します。

3. 申請の種類を1アプリに詰め込むか、分けるか

購買も外注も値引きも経費も、ぜんぶ1つの「申請アプリ」で受けたくなります。 入口が1つになって分かりやすいからです。ただし種類ごとに必要な項目が違うので、 項目はどんどん増えます。kintone SIGNPOSTの「性能上の考慮点と改善策」には 「1アプリの最大フィールド数は500ですが、100を超えるとレコード一覧/詳細画面の表示などに遅延が生じる可能性があります。」 と記載されています。上限まで余裕があっても、体感の速さは早い段階から落ちうるという説明です。

一方、アプリ数のほうは余裕があります。サイボウズが公表している料金ページによれば、 アプリ数はライトコースで200個、スタンダードコースで1,000個 （いずれも2026年8月時点の掲載）です。 つまり分ける側にコストがかかりにくい構成になっています。 承認の段数や決裁者が違う申請を1つのアプリに同居させ、 条件分岐で切り分ける設計は、作るのも直すのも重くなります。素直に分けたほうが楽です。

少人数でも、最低契約ユーザー数で費用を確認する

サイボウズの料金ページでは、最低契約ユーザー数は10ユーザーです。5人の会社でも10ユーザー分の料金を前提にします。

30日間の無料お試しもあるので、決裁表を書き終えたあとに実際の設定を試すのが順番としては合っています。

向く場合と向かない場合

ここまでを、自社が向くかどうかの判定に落とします。 以下は当社が支援の現場で見てきた傾向を整理したものであり、統計ではありません。

最後の行だけ「向かない」ではなく「要確認」にしています。 会計処理や電子帳簿の保存に関わる要件は、 当社が本記事で正確に書ける範囲を超えるためです。 該当しそうな場合は、要件を先に確定させてから、 その要件を満たせる保存方法を選ぶ順番になります。 ツールを選んでから要件を確認すると、選び直しになります。

先に決めること——kintoneを触る前に決裁表を1枚作る

結論はシンプルです。kintoneを触る前に、決裁表を1枚作ってください。 申請の種類を縦に並べ、横に次の5項目を並べた表です。 これを作るのに専門知識は要らず、必要なのは決める人の同席だけです。

1. 何を申請するか
2. いくらから誰の承認が要るか
3. 不在時の代理
4. 差し戻し先と再承認の条件
5. 承認後に動く作業

そして埋まらない欄が、本当のボトルネックです。 そこはツールを変えても、連携サービスを買っても埋まりません。 逆に埋まってさえいれば、kintoneでもほかの道具でも、 設定の作業は淡々と終わります。当社が繰り返しお伝えしているのは構造を決めてから道具を選ぶという順番で、 承認フローはその順番の効き方がいちばん分かりやすい領域です。

kintoneをそもそも自社の業務にどう当てるかという全体の話は「不動産会社がkintoneで顧客管理・物件管理を始める方法」、他のツールとの比較の観点は「中小企業向けCRM比較」「不動産会社にSalesforce・HubSpotは合うのか」で扱っています。勤怠のような専用システムがある領域との線引きは「kintone 勤怠管理は向くのか」に分けました。

※ 本記事は公開されている資料をもとにした一般的な整理です。引用した料金・仕様は 2026年8月時点の掲載内容であり、改定される可能性があります。導入前に提供元の最新情報をご確認ください。 「月10,000円」「月18,000円」は、公表されている最低契約ユーザー数10ユーザーと月額単価から当社が計算したものです（いずれも税抜）。 プロセス管理のステータス数の上限や条件分岐の仕様上限については、当社が公表値を確認できていないため記載していません。 会計処理・電子帳簿の保存に関する要件の中身も本記事では扱っていません。 決裁表の5項目と向く／向かないの整理は、当社が支援の現場で観察した傾向を整理したものであり、 統計的に検証された区分ではありません。