kintoneワークフローでできないこと｜専用ツール連携を判断する設計基準

kintoneのワークフローは、プロセス管理を使えばかなり作れます。

申請。

承認。

差し戻し。

却下。

条件分岐。

複数承認。

作業者への通知。

承認待ちの一覧化。

小さな稟議、休暇申請、備品購入、簡単な経費申請であれば、kintoneの標準機能だけでも十分に始められます。

一方で、「できる」と「運用に耐える」は違います。

次のような要件が出てくると、標準機能だけで作るほど設定や運用が重くなります。

• 承認者を組織階層や役職から自動で決めたい
• 申請種別が多く、ルートが部門ごとに違う
• 代理承認、引き上げ承認、一括承認を厳密に管理したい
• 承認後に特定項目だけ編集不可にしたい
• 全申請を横断して承認待ち、期限超過、監査履歴を見たい
• 議決承認のように、複数人の過半数で承認可否を決めたい
• 人事異動や組織変更に合わせて承認ルートを自動更新したい
• 契約、購買、会計など外部システムと承認結果を同期したい

kintoneワークフローでできないことを考えるときは、「機能として完全に不可能か」だけを見ると判断を誤ります。

本当に見るべきなのは、標準機能で実装したときに、設定変更、例外対応、監査、運用保守まで耐えられるかです。

kintoneワークフローの限界は、「作れるか」ではなく、「運用変更、例外処理、監査、組織変更まで含めて保守できるか」で判断します。

この記事では、kintoneワークフローで標準機能だけでは難しいこと、プラグインやカスタマイズで補えること、専用ワークフロー連携を検討すべきことを整理します。

kintoneワークフローの設計方法はこちら
kintoneワークフローの作り方はこちら

先に結論：単純承認は得意、複雑な承認統制は要注意

kintoneのワークフローは、単純な承認や業務データに近い状態管理に向いています。

逆に、全社共通の承認基盤、複雑な組織階層、厳密な代理承認、議決承認、監査向けの承認履歴管理をすべてkintone標準機能だけで作り込むのは慎重に考えた方がよいです。

判断は、次の3段階で行います。

判断	向いている要件	例
標準機能で作る	固定ルート、少数条件、特定部署の申請	休暇申請、備品購入、簡易稟議
プラグイン・カスタマイズで補う	入力制御、自動採番、承認後ロック、横断一覧	承認済み後の項目固定、申請番号採番
専用ワークフロー連携を使う	複雑な組織階層、議決、厳密な監査、全社統制	全社稟議、契約承認、購買承認基盤

kintone SIGNPOSTでも、kintoneはワークフロー専用ツールではないため、基本機能のみ、プラグイン/カスタマイズの併用、ワークフロー専用システムとの連携という3つの構成に分けて考える必要があると整理されています。

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

この切り分けはかなり実務的です。

最初から専用ツールを入れればよいわけではありません。

逆に、kintoneだけに閉じれば安いとも限りません。

個別カスタマイズが増えすぎると、専用ワークフローを使うより高く、変更しづらくなることがあります。

kintoneで無理に作り込むより、申請データはkintone、承認エンジンは専用ツール、承認結果はkintoneへ戻す、という分担の方が安定するケースがあります。

標準機能でできること

kintoneの標準機能だけでも、基本的なワークフローは作れます。

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

kintoneヘルプ：プロセス管理

標準機能で扱いやすいのは、次のような要件です。

標準機能で扱いやすいこと	例
ステータス管理	下書き、承認待ち、差し戻し、承認済み
作業者の指定	申請者、上長、経理、管理者
アクション	申請する、承認する、差し戻す、却下する
条件分岐	金額や申請種別でボタンを出し分ける
複数承認者	全員、誰か1人、選択式など
取り戻し	申請者が提出を取り下げる
通知	作業者への自分宛通知、メール通知
一覧	承認待ち、差し戻し中、期限超過
コメント	判断理由や確認事項を残す
アクセス権	アプリ、レコード、フィールド単位の制御
リマインダー	期限前、期限超過の通知

この範囲であれば、kintone標準機能だけで始める価値があります。

特に、次の条件なら標準機能から始めやすいです。

標準機能で始めやすい条件	理由
承認ルートが固定	作業者やアクションをシンプルにできる
申請種別が少ない	条件分岐が増えすぎない
承認者が少ない	滞留や代理の問題が小さい
特定部署内で使う	組織変更や全社統制の影響が小さい
監査要件が軽い	コメントや変更履歴で足りることが多い
承認後の処理が手動でも回る	外部連携を急がなくてよい

たとえば、少人数の備品購入申請なら、下書き、承認待ち、差し戻し、承認済み、完了で十分です。

承認者は上長と総務担当。

通知は承認待ちと差し戻しだけ。

承認済み後に総務が発注状態を更新する。

この程度なら、標準機能で始める方が速いです。

標準機能だけでは難しいこと

標準機能だけで難しいのは、承認ルートが複雑な場合です。

単にステータスが多いだけではありません。

承認者の決まり方、例外処理、組織変更、ログ出力、入力制御が絡むと重くなります。

標準機能だけでは難しいこと	なぜ難しいか
複雑な承認経路の自動設定	部門、役職、金額、申請種別、申請者属性が絡む
組織階層に応じた自動承認者設定	人事情報や組織改編との連動が必要
議決承認	過半数や比率による承認判定が必要
厳密な代理承認	代理条件、理由、期限、元承認者の記録が必要
一括承認	多数レコードの同時判断とログが必要
承認スキップ	同一承認者が連続する場合の扱いが必要
ステータスごとの細かな入力制御	項目単位で編集可否が変わる
承認後の完全なロック	重要項目の変更防止と例外修正が必要
全申請の横断一覧	複数アプリをまたいだ承認管理が必要
監査向け履歴出力	承認者、日時、結果、理由を整形して出す必要

日立ケーイーシステムズの記事でも、kintoneのワークフローは基本設定や条件分岐に対応できる一方、対応が難しいことや運用上の注意点を把握する必要があると整理されています。

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

ここで重要なのは、標準機能だけでは難しいから、すぐ諦めるという話ではないことです。

難しいものの中には、業務ルールをシンプルにすれば標準機能で足りるものがあります。

たとえば、承認ルートが10通りある場合でも、実際には金額と申請種別の2条件だけで整理できることがあります。

逆に、例外をすべてkintoneで再現しようとすると、ステータスとアクションが増えすぎます。

標準機能でできないことを考える前に、現行ルールを削れるか確認します。

入力制御・承認後ロック・代理承認の論点

kintoneワークフローで相談が多いのは、入力制御、承認後ロック、代理承認です。

どれも、単純な承認ボタンより運用設計が難しい領域です。

入力制御

入力制御とは、ステータスやユーザーによって、編集できる項目を変えることです。

たとえば、下書きでは申請者が全項目を編集できる。

承認待ちでは申請者は編集できない。

差し戻しでは申請理由と添付資料だけ編集できる。

承認済み後は金額と取引先を編集できない。

このような制御です。

状態	編集させたい項目	注意点
下書き	申請内容、金額、添付	入力漏れを防ぐ
承認待ち	原則編集不可	承認者が見た内容を保つ
差し戻し	申請理由、添付、補足	どこまで直せるか決める
承認済み	管理項目、後続処理状態	重要項目は固定する
完了	原則編集不可	管理者修正だけ許可する

kintone標準のアクセス権やフィールドアクセス権で対応できる範囲もあります。

ただし、ステータスごとに細かく項目制御したい場合は、プラグインやJavaScriptカスタマイズを検討することになります。

承認後ロック

承認後に金額、取引先、添付資料、申請種別が変わると、承認の意味がなくなります。

そのため、承認済み後にどの項目を固定するかを決めます。

固定したい項目	理由
金額	承認金額と支払金額がずれる
取引先	承認対象が変わる
申請種別	承認ルートが変わる
添付資料	判断根拠が変わる
支払条件	経理確認が必要
契約開始日	契約・実行条件が変わる

承認後の変更を完全に禁止するのではなく、変更申請や再承認へ戻す設計にします。

kintone承認フローの設計方法でも整理したように、承認後に重要項目を変えるなら、再承認、変更申請、管理者修正ログのどれで扱うかを決める必要があります。

代理承認

代理承認は、便利ですが責任が曖昧になりやすいです。

代理できる人、代理できる条件、代理理由、元承認者への通知、ログの残し方を決めます。

代理承認で決めること	例
代理者	上位者、同じ役割、管理者
条件	承認者不在、期限超過、緊急
理由	出張、休暇、退職、組織変更
ログ	元承認者、代理者、日時、理由
通知	申請者、元承認者、管理者

代理承認を広く許可すると、誰が責任を持って判断したのか分からなくなります。

標準機能で対応できる範囲と、専用ワークフローで厳密に管理する範囲を分けます。

入力制御、承認後ロック、代理承認は、機能追加の話ではなく、承認責任をどこまで厳密に管理するかの話です。

組織階層や人事異動に弱いケース

kintoneワークフローで特に注意したいのが、組織階層と人事異動です。

小さなチームなら、承認者をユーザー選択フィールドで指定しても運用できます。

しかし、全社で使う申請になると、次のような問題が出ます。

• 申請者の所属部門によって承認者が変わる
• 金額によって課長、部長、役員が変わる
• 兼務、代理、異動、退職が発生する
• 組織改編で部門名や上長が変わる
• 古いレコードの現在作業者が残る
• 申請時点の組織で承認するのか、現在組織で承認するのか決める必要がある

この領域は、単純なプロセス管理設定だけでは弱くなりやすいです。

人事マスタ、部門マスタ、承認経路マスタを整備し、申請時点で承認者をコピーするのか、都度参照するのかを決める必要があります。

設計	向いているケース	注意点
人名固定	小規模、変更が少ない	異動や退職で古くなる
ユーザー選択フィールド	申請ごとに承認者が違う	誤指定や入力漏れが起きる
経路マスタ	部門、金額、種別で承認者を管理	マスタ保守が必要
人事マスタ連携	組織階層に沿って自動設定	連携と同期の設計が必要
専用ワークフロー	全社統制、複雑な階層	費用と連携設計が必要

kintone SIGNPOSTでも、利用組織が大きく複雑になるほど、ユーザー情報や経路マスタの設定が煩雑になりうる点が注意点として整理されています。

全社の承認基盤として使うなら、組織変更時の棚卸し手順を必ず決めます。

誰が経路マスタを更新するのか。

異動発令日と承認者反映日をどう合わせるのか。

進行中の申請は旧承認者のままにするのか、新承認者へ移すのか。

ここが決まっていないと、承認フローは止まります。

プラグインで補える範囲

標準機能だけで足りない場合でも、すぐ専用ワークフローに行く必要はありません。

プラグインやJavaScriptカスタマイズで補える範囲があります。

補える可能性があること	例
入力制御	ステータス別に項目を編集不可にする
自動採番	申請番号や承認番号を付ける
承認後ロック	重要項目を固定する
通知拡張	チャット通知、条件通知、期限通知
一括処理	一括承認、一括更新
帳票出力	承認済み申請のPDF出力
横断一覧	複数アプリの承認状況をまとめる
マスタ連携	承認経路や社員情報の参照

ただし、プラグインやカスタマイズは万能ではありません。

増やしすぎると、次の問題が出ます。

問題	内容
保守負荷	誰が設定変更や不具合対応をするか
依存関係	kintone更新や他プラグインとの相性
費用	月額費用や開発費が増える
属人化	JavaScriptを直せる人が限られる
仕様の複雑化	現場がルールを理解できなくなる
テスト負荷	変更のたびに分岐と権限を確認する必要

GXOの記事でも、kintoneの限界を知った上で、標準機能、拡張、別システムを判断する重要性が整理されています。

GXO：kintoneの限界10選

プラグインを使うべきかは、機能の有無だけで決めません。

そのプラグインを入れることで、現場のルールが簡単になるか。

管理者が保守できるか。

テストしやすいか。

これを見ます。

専用ワークフロー連携を選ぶ基準

専用ワークフロー連携を検討すべきなのは、承認機能が複雑な場合です。

ただし、専用ツールにすればすべて解決するわけではありません。

連携、ユーザー同期、費用、運用教育が必要になります。

専用ワークフローを検討する条件	理由
全社横断で申請種別が多い	申請基盤としての管理が必要
組織階層に応じた承認者自動設定が必要	人事情報との連動が必要
議決承認や合議が多い	kintone標準では表現しづらい
代理承認、引き上げ、一括承認を厳密に扱う	権限とログの統制が必要
監査向けの履歴出力が重要	承認履歴の整形と保管が必要
契約、購買、会計と連携する	外部システムとの責任分界が必要
申請ルール変更が頻繁	専用の管理画面や承認マスタが必要

kintone SIGNPOSTでは、ワークフロー専用システムとの連携例として、申請時に必要なマスタデータをkintoneで管理し、ワークフローシステムから参照する構成や、kintoneで作成した申請データをワークフローシステムへ連携し、承認結果をkintoneへ戻す構成が紹介されています。

この分担は、実務でも使いやすいです。

kintoneは、顧客、案件、見積、契約、経費などの業務データを持つ。

専用ワークフローは、承認経路、代理、合議、監査履歴を持つ。

承認結果だけをkintoneへ戻す。

こうすれば、kintoneの業務データを中心にしながら、承認統制だけを専用システムへ任せられます。

kintoneに残すデータと外部に任せる処理

外部連携を選ぶ場合でも、kintone側の設計は必要です。

むしろ、ここを決めないと二重管理になります。

kintoneに残すもの	外部ワークフローに任せるもの
申請元の業務データ	承認経路の決定
顧客、案件、社員、部門などのマスタ	組織階層に応じた承認者設定
見積、契約、経費、購買などの申請内容	代理承認、引き上げ、議決
承認依頼の状態	承認履歴の厳密な管理
承認結果の受け取り	監査向け履歴出力
後続処理の状態	全社横断の承認管理
連携ログとエラー	承認通知や催促

重要なのは、正本を分けることです。

申請内容の正本はkintoneなのか。

承認結果の正本は外部ワークフローなのか。

承認済み後にkintoneの申請内容を変更できるのか。

外部で差し戻しされたとき、kintone側はどのステータスへ戻すのか。

連携エラーが起きたら、どちらを直すのか。

この責任分界が曖昧だと、kintoneと外部ツールの両方に似た状態が残り、どちらが正しいか分からなくなります。

外部ワークフロー連携では、kintoneに残す申請データと、外部に任せる承認経路・承認履歴を分けないと、二重管理になります。

よくある判断ミス

kintoneワークフローの限界を考えるとき、よくある判断ミスがあります。

できないことを全部プラグインで埋めようとする

プラグインは便利です。

しかし、入力制御、採番、通知、帳票、横断一覧、承認後ロック、一括承認をすべて別々に追加すると、全体の仕様が見えづらくなります。

プラグインを入れる前に、業務ルールを削れないか確認します。

専用ワークフローを入れれば設計が不要だと思う

専用ワークフローを使っても、申請データの設計は必要です。

何を申請単位にするか。

どのマスタを参照するか。

承認結果をどこへ戻すか。

承認後の後続処理をkintoneでどう持つか。

ここは残ります。

kintoneに全申請を詰め込む

全社の稟議、経費、休暇、契約、購買、見積を1つの申請アプリで扱うと、項目もステータスも条件分岐も増えすぎます。

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

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

限界を理由に、標準機能で十分なものまで外へ出す

小さな申請まで専用ワークフローへ出すと、利用者の画面移動が増え、運用が重くなります。

固定ルートで、特定部署内で、監査要件が軽いなら、kintone標準機能から始めた方がよいケースもあります。

判断表：標準・拡張・外部連携をどう選ぶか

最後に、判断表として整理します。

要件	標準機能	プラグイン・カスタマイズ	専用ワークフロー連携
固定ルートの承認	向いている	不要なことが多い	重い
少数の条件分岐	向いている	条件が増えたら検討	重い
ステータス別入力制御	一部可能	向いている	要件次第
承認後ロック	一部運用で対応	向いている	要件次第
一括承認	弱い	検討	向いている場合あり
議決承認	弱い	難しいことが多い	向いている
複雑な組織階層	弱い	マスタ連携が必要	向いている
監査履歴出力	弱い	履歴アプリや帳票で補う	向いている
複数アプリ横断管理	弱い	横断一覧で補う	向いている場合あり
契約・購買・会計連携	APIや手動で対応	連携設計が必要	要件次第

判断に迷ったら、次の順番で考えます。

1. 承認ルールを削れないか
2. kintone標準機能で運用できる範囲か
3. プラグインや軽いカスタマイズで保守できるか
4. 個別カスタマイズが増えすぎないか
5. 専用ワークフローに任せた方が安く、長く保守できるか

kintoneワークフローの作り方でも触れたように、まずテストしやすい形で始め、運用データを見ながら削るのが現実的です。

まとめ：できないことは、業務設計の分担として考える

kintoneワークフローでできないことを調べると、機能の限界が気になります。

ただ、実務で重要なのは、弱点の列挙ではありません。

標準機能で十分な申請。

プラグインやカスタマイズで補えばよい申請。

専用ワークフローに任せた方がよい申請。

この3つを分けることです。

kintoneは、業務データを持つ場所として強いです。

申請内容、顧客、案件、経費、見積、契約、後続処理を同じ業務アプリで管理できます。

一方で、複雑な承認経路、組織階層、議決、厳密な代理承認、監査履歴をすべてkintone標準機能だけで抱えると、運用が重くなります。

Bitlightでは、kintoneワークフローについて、標準機能で作る範囲、プラグインやカスタマイズで補う範囲、専用ワークフロー連携に分けて設計できます。

「できないこと」を不安材料として見るのではなく、自社の申請データと承認統制をどう分担するかの判断材料として整理するのが現実的です。