kintone条件分岐処理プラグインの設計方法｜入力制御と自動処理を分ける

kintone条件分岐処理プラグインは、便利です。

ステータスに応じて項目を非表示にする。

特定の選択肢を選んだら、日付や担当者を自動入力する。

保存時に不足項目をチェックする。

条件に応じてフィールドの書式を変える。

採番する。

テーブル行を追加する。

別アプリのレコードを更新する。

こうした処理を、JavaScriptを書かずに設定で実現できる場面があります。

しかし、条件分岐処理プラグインを入れれば、業務ルールが自然に整理されるわけではありません。

むしろ、便利だからこそ、次のような状態になりやすいです。

• 似た条件が何十個も増える
• 条件の優先順や実行タイミングが分からない
• 表示制御、保存時チェック、自動入力、アプリ間更新が混ざる
• どのフィールドを変更すると何が動くのか説明できない
• 担当者や組織の変更で条件が崩れる
• プラグイン設定を触るのが怖くなり、誰も直せない
• 本来はアプリを分けるべき業務まで、1アプリ内の条件で吸収しようとする
• 例外処理を追加し続け、テストできないアプリになる

条件分岐は、設定作業ではなく業務ルールの実装です。

そのため、最初に考えるべきなのは「何ができるか」ではありません。

どの条件を業務上のルールとして固定し、どの条件を入力補助にとどめるかです。

kintone条件分岐処理プラグインで最初に設計するのは、設定項目ではなく、条件を入力補助、保存時チェック、自動入力、アプリ間更新のどれとして扱うかです。

この記事では、kintone条件分岐処理プラグインを、機能紹介ではなく、業務ルール、入力制御、自動入力、保存時チェック、日付計算、自動採番、テーブル追加、アプリ間更新、例外処理の設計として整理します。

kintoneアプリ開発の進め方はこちら
kintoneカスタマイズの設計方法はこちら
kintoneプロセス管理の条件分岐設計はこちら
kintone API連携の設計方法はこちら

条件分岐は業務ルールの実装

条件分岐処理プラグインを使う前に、まず条件の種類を分けます。

すべてを同じ「条件」として扱うと、設定が増えたときに読めなくなります。

条件の種類	目的	例
入力補助	入力者の手間を減らす	種別に応じて担当部署を自動入力する
表示制御	画面を見やすくする	不要な項目を非表示にする
保存時チェック	不足や矛盾を止める	次回フォローありなら内容入力を必須にする
日付計算	期限や予定日を決める	契約日の翌月末を請求予定日にする
採番	管理番号を揃える	申請種別ごとに番号を付ける
テーブル追加	明細や作業行を用意する	商品種別に応じて必要な明細行を出す
アプリ間更新	関連アプリへ反映する	売上管理の金額変更を入金管理へ反映する
削除時チェック	誤削除を防ぐ	完了済みレコードの削除時に確認する

たとえば、「契約種別が年間契約なら更新日を自動入力する」は入力補助です。

「契約種別が年間契約なのに更新日が空欄なら保存させない」は保存時チェックです。

「年間契約だけ更新日フィールドを表示する」は表示制御です。

似ていますが、意味は違います。

この違いを分けないまま設定すると、後から条件の衝突が起きます。

同じ条件でも、入力補助、表示制御、保存時チェックでは目的が違います。目的を分けずに設定を増やすと、どの条件が業務を守っているのか分からなくなります。

TISの条件分岐処理プラグインページでは、条件に該当した場合に自動化処理、書式設定、エラーチェックなどを行うプラグインとして説明されています。

TIS：条件分岐処理プラグイン

また、TISの設定説明では、画面表示時や条件に指定したフィールドの値変更時に処理が実行されること、条件を指定していない処理は毎回実行されることが説明されています。

この点は設計上かなり重要です。

条件を付け忘れた処理は、意図しないタイミングで動く可能性があります。

そのため、設定前に「いつ動く条件か」を表にします。

条件名	いつ動くか	何をするか	止める条件
契約更新日の自動入力	契約種別変更時	更新予定日を入れる	手動修正済みなら上書きしない
フォロー内容の必須化	保存時	空欄なら保存を止める	次回フォローなしなら対象外
高額案件の注意表示	詳細表示時	金額欄を強調する	完了済みなら表示しない
入金管理への反映	金額確定時	別アプリを更新する	送信済みなら二重更新しない

この表がないまま設定画面へ入ると、条件が増えるほど保守しにくくなります。

自動入力・表示制御・保存時チェックを分ける

条件分岐処理プラグインでよく使うのは、自動入力、表示制御、保存時チェックです。

この3つは一緒に考えられがちですが、設計上は分けます。

処理	役割	設計の注意点
自動入力	入力候補や初期値を入れる	上書きしてよい値か確認する
表示制御	入力者に必要な項目だけ見せる	非表示でもデータが消えるわけではない
保存時チェック	保存前に不足や矛盾を止める	本当に止めるべき条件だけに絞る

たとえば、問い合わせ管理アプリで、問い合わせ種別が「クレーム」の場合だけ重要度を高にする。

これは自動入力です。

問い合わせ種別が「資料請求」の場合、訪問予定日は不要なので非表示にする。

これは表示制御です。

問い合わせ種別が「クレーム」なのに対応期限が空欄なら保存させない。

これは保存時チェックです。

同じ問い合わせ種別を条件にしていても、目的が違います。

目的が違う条件は、設定名を分けます。

悪い設定名	よい設定名
クレーム対応	クレーム時_重要度自動入力
クレーム対応2	クレーム時_対応期限必須チェック
資料請求	資料請求時_訪問予定日非表示

設定名を見ただけで、何をしているか分かる状態にします。

トヨクモの記事では、条件分岐処理プラグインの機能として、自動入力、自動コピー、日付の自動計算、入力不要項目の非表示、テーブル行の自動追加、保存時チェック、書式変更、自動採番、アプリ間更新、削除時チェックなどが紹介されています。

トヨクモ：kintoneの条件分岐処理プラグインとは？

システムクレイスの紹介ページでも、入力ミスや入力漏れを減らしたい、条件に応じて自動入力やテーブル追加をしたい、といった課題に対して、条件分岐処理プラグインを使う文脈が示されています。

システムクレイス：kintone条件分岐処理プラグイン

機能は多いですが、使う前に目的を分けることが重要です。

ステータス別の入力制御

条件分岐処理プラグインは、ステータスに応じた入力制御にも使われます。

たとえば、申請アプリでは次のような制御が考えられます。

ステータス	入力者	制御
下書き	申請者	申請内容を入力する
申請中	承認者	承認コメントを入力する
差し戻し	申請者	差し戻し理由を確認して修正する
承認済み	経理	支払予定日や処理番号を入力する
完了	管理者	原則編集しない

このような場合、条件分岐処理プラグインだけで全部を表すのではなく、プロセス管理、アクセス権、通知と合わせます。

プロセス管理は状態と作業者を扱います。

アクセス権は、誰が見てよいか、編集してよいかを扱います。

条件分岐処理プラグインは、画面上の入力補助やチェックを扱います。

この3つを混ぜると危険です。

たとえば、承認済みの金額欄を非表示にしても、権限や別経路の更新が残っていれば、業務ルールとしては守れていません。

本当に編集禁止にしたいなら、フィールド権限やプロセス管理、運用ルールも確認します。

kintoneワークフローの設計方法はこちら
kintoneセキュリティの設計方法はこちら

条件分岐処理プラグインは、画面上の入力補助には向いています。ただし、権限や承認ルールの代わりとして使うと、別経路の更新を止められないことがあります。

日付計算・自動採番・テーブル追加の使い方

条件分岐処理プラグインでは、日付計算、自動採番、テーブル追加もよく使われます。

TISの関数ドキュメントでは、TODAY、NOW、AGE、DATE_CALC、DATE_DIFF、DATE_FORMAT、LPADなどの関数が説明されています。

TIS：Summary of Formulas in BranchProcess

これらは便利ですが、業務上の意味を決めてから使います。

処理	使いどころ	注意点
日付計算	契約日から請求予定日を出す	休日、月末、締め日ルールを確認する
年齢計算	生年月日から年齢を出す	基準日が今日なのか申請日なのか決める
自動採番	申請番号、見積番号、案件番号を揃える	重複、欠番、再利用時の扱いを決める
テーブル追加	種別に応じた明細行を用意する	行を追加した後の修正ルールを決める
文字列整形	コードや番号の桁数を揃える	元フィールドの表記揺れを先に直す

たとえば、契約日の翌月末を請求予定日にする場合、DATE_CALCのような関数で表現できるかもしれません。

しかし、月末が土日祝の場合に前営業日へずらすのか、翌営業日へずらすのかは、プラグイン設定だけではなく業務ルールです。

自動採番も同じです。

番号が付けばよいのか。

部署ごとに連番が必要なのか。

年度でリセットするのか。

削除された番号を欠番として扱うのか。

再利用時に番号を振り直すのか。

こうしたルールを決めないまま採番すると、後から台帳や帳票と合わなくなります。

テーブル追加も注意が必要です。

種別に応じて明細行を自動追加すると、入力開始は楽になります。

ただし、後から種別を変えたときに既存行を消すのか、追加だけするのか、手動修正を残すのかを決めます。

kintoneテーブル設計の方法はこちら
kintoneサブテーブル設計の方法はこちら

アプリ間更新を使う前の注意点

条件分岐処理プラグインでは、アプリ間更新を使える場合があります。

TISの製品ページでも、自動アプリ間更新を指定すると条件に該当した場合に処理が実行され、更新先に存在しないデータを自動追加する設定に触れられています。

アプリ間更新は便利ですが、かなり慎重に設計します。

理由は、データの正本が曖昧になりやすいからです。

設計項目	決めること
正本アプリ	どのアプリの値が正しいのか
更新先	どのアプリの、どのレコードを更新するのか
更新キー	レコード番号、管理番号、顧客コードなど
更新タイミング	保存時、ステータス変更時、一覧ボタン実行時
上書きルール	空欄だけ入れるのか、常に上書きするのか
手動修正	更新先で手動修正した値を守るか
エラー時	誰が、どの一覧で失敗を確認するか
二重更新	同じ処理が複数回動いたときに重複しないか

たとえば、案件管理アプリの受注金額を、売上管理アプリへ反映する場合を考えます。

案件管理が正本なら、売上管理側の金額を手動で直してよいのかを決める必要があります。

売上管理が正本なら、案件管理からの上書きは危険です。

また、案件金額を変更したとき、過去の売上履歴まで上書きしてよいのかも問題になります。

アプリ間更新は、単なる転記ではありません。

正本、更新キー、上書き、履歴、エラー時の戻し方まで決めます。

kintoneアプリ間データ連携の設計方法はこちら
kintone API連携の設計方法はこちら

条件分岐処理プラグインのアプリ間更新は、転記作業の代わりではありません。正本アプリ、更新キー、上書きルール、失敗時の確認方法まで決めて使います。

条件が複雑化したときの設計見直し

条件分岐処理プラグインで対応できる範囲は広いですが、複雑になりすぎたら設計を見直します。

次の状態になったら、プラグイン設定を増やすより、アプリ構成や実装方法を見直した方がよいです。

状態	見直し方
条件が多すぎて読めない	条件を目的別に分け、不要条件を削る
同じフィールドを複数条件が更新する	更新責任を1つに絞る
ステータスごとの制御が多い	プロセス管理や権限設計を見直す
アプリ間更新が増えた	正本アプリ、API連携、連携ログを検討する
テーブル行の処理が複雑	明細アプリへ分ける
条件が部署や担当者に依存する	マスタアプリや権限設定へ寄せる
例外が多すぎる	例外を手動処理として残す

プラグインで吸収しすぎると、アプリの構造が見えなくなります。

たとえば、1つの申請アプリの中で、経費、契約、購買、休暇、出張をすべて条件分岐で切り替える設計は、最初は便利に見えます。

しかし、フォーム項目、承認者、添付資料、金額基準、保存時チェックが全部違うなら、別アプリに分けた方が保守しやすいことがあります。

また、複数アプリをまたぐ更新や外部SaaS連携が増えた場合は、REST API、Webhook、バッチ処理、ログアプリの方が向く場合があります。

kintone Webhookの設計方法はこちら
kintone連携サービス選定の設計方法はこちら

条件分岐処理プラグインは、業務ルールを設定で扱える強い選択肢です。

ただし、すべての業務ルールを1つのプラグイン設定に押し込む必要はありません。

権限・例外処理・保守の注意点

条件分岐処理プラグインを使う場合、最後に見るべきなのは保守です。

とくに、権限、例外処理、設定変更のルールを決めます。

項目	確認すること
権限	非表示や編集制限だけで本当に守れるルールか
例外処理	手動修正を許す条件、許さない条件
設定名	誰が見ても目的が分かる名前か
実行条件	画面表示、値変更、保存時、プロセスアクション時など
テスト	条件に該当するケース、該当しないケース
変更履歴	いつ、なぜ、誰が条件を変えたか
影響範囲	どのフィールド、一覧、連携先に影響するか
引き継ぎ	設定意図を説明できるメモがあるか

条件分岐処理プラグインは、設定画面で作れるため、コードレビューのような確認が抜けやすいです。

だからこそ、変更時はメモを残します。

おすすめは、アプリ管理者用メモや別の運用メモに、次のように残すことです。

記録すること	例
設定名	契約時_更新予定日自動入力
目的	契約更新日の入力漏れを防ぐ
条件	契約種別=年間契約、更新予定日が空欄
処理	契約日から1年後を更新予定日に入れる
例外	手動で更新予定日を入れた場合は上書きしない
確認ケース	年間契約、単発契約、契約日未入力、手動修正済み
変更日	2026-06-12

ここまで残っていれば、半年後に条件を見直すときも判断しやすくなります。

逆に、設定画面だけにしか情報がないと、触るほど怖くなります。

よくある失敗

kintone条件分岐処理プラグインでは、次の失敗が起きやすいです。

条件名が曖昧

「処理1」「条件2」のような名前では、後から目的が分かりません。

条件名には、対象、条件、処理を入れます。

非表示を権限制御だと思う

非表示は画面上の見え方です。

業務として編集や閲覧を制限したい場合は、アクセス権やプロセス管理も確認します。

自動入力で手動修正を上書きする

自動入力は便利ですが、入力者が意図して直した値を上書きすると事故になります。

空欄時だけ入れるのか、常に上書きするのかを決めます。

保存時チェックを増やしすぎる

チェックが多すぎると、入力者はどこを直せばよいか分からなくなります。

本当に保存を止めるべき条件だけに絞ります。

アプリ間更新を転記感覚で使う

別アプリへ値を入れるだけに見えても、実際には同期です。

正本、更新キー、上書き、失敗時の確認方法を決めます。

例外を全部条件で吸収する

例外を条件で吸収し続けると、設定が読めなくなります。

件数が少ない例外は、手動処理や承認者判断として残す方がよい場合があります。

テストケースを作らない

条件に該当するケースだけでなく、該当しないケースも確認します。

条件を増やしたら、既存条件が壊れていないかも見ます。

実装前チェックリスト

条件分岐処理プラグインを設定する前に、次の項目を確認します。

確認項目	判断すること
目的	入力補助、表示制御、保存時チェック、自動更新のどれか
条件	どのフィールドの、どの値で動かすか
実行タイミング	表示時、値変更時、保存時、プロセスアクション時など
上書き	既存値を上書きしてよいか
例外	手動修正、差し戻し、再利用時の扱い
権限	非表示や編集制限だけで足りるか
正本	アプリ間更新する場合、どのアプリが正しいか
更新キー	どの値で更新先レコードを特定するか
ログ	失敗や再実行をどこで確認するか
テスト	該当、非該当、境界値、権限違いを確認するか
保守	設定名、変更履歴、担当者を残すか
見直し	複雑なら別アプリ、JavaScript、APIへ切り替えるか

この表を埋めると、設定すべき条件と、設定しない方がよい条件が分かれます。

条件分岐処理プラグインで扱うもの。

標準機能で扱うもの。

プロセス管理や権限で扱うもの。

別アプリへ分けるもの。

JavaScriptやAPI連携へ切り替えるもの。

この切り分けができていれば、プラグイン設定が増えても崩れにくくなります。

Bitlightに相談できること

Bitlightでは、kintone条件分岐処理プラグインを、便利機能の追加ではなく、業務ルールの設計として整理します。

相談できる内容は次の通りです。

• 現在のプラグイン設定の棚卸し
• 入力補助、表示制御、保存時チェック、自動入力の分離
• ステータス別の入力制御とプロセス管理の整理
• 日付計算、自動採番、テーブル追加の業務ルール化
• アプリ間更新の正本、更新キー、上書きルール整理
• 条件が複雑化したアプリの分割判断
• JavaScript、REST API、Webhookへの切り替え判断
• 設定名、変更履歴、テストケース、保守メモの整備

条件分岐処理プラグインは、kintoneの標準機能だけでは表しにくい業務ルールを設定で扱える強い選択肢です。

ただし、強い機能ほど、設計なしに増やすと保守できなくなります。

kintone条件分岐処理プラグインは、条件を増やすための道具ではなく、業務ルールを入力補助、チェック、自動更新、例外処理に分けて保守するための道具です。

条件の目的、実行タイミング、上書きルール、例外処理を先に決めれば、便利な設定を安全に業務へ組み込みやすくなります。