kintoneでフィールドを条件で表示・非表示にする方法3選

2026-07-22公開 ／ カテゴリ: 入力支援・フォーム制御 ／ 執筆: bst 開発チーム

「区分が『法人』のときだけ、会社名の欄を出したい」「受注になったら、受注日を必須にしたい」「確定した金額は、もう書き換えられないようにしたい」——kintoneのフォームを作り込むと、必ず行き着くのがこの「条件による入力制御」です。

そして設定画面を探し回った結果、それができないことに気づきます。私たちはkintoneプラグインの開発元として、この「条件で変えたい」相談を数多く受けてきました。本記事は2026年7月時点の仕様に基づいて、できない理由と3つの解決方法を整理します。

入力ミスの後始末は、気づく→確認する→差し戻す→直すという長い往復です。ミスの発生源が入力画面にあるなら、総コストではプラグインが最も安くつくケースが多い——これが本記事の結論です。理由を順に説明します。

kintoneでフィールドの条件制御ができない理由｜標準機能でできること・できないこと

原因：標準の制御は「誰か」で決まり、「値」では変わらない

kintoneには入力を制御する標準機能がいくつもあります。ただし、それらの条件はすべて「ユーザーが誰か」「レコードがどの状態か」であって、「いま何が入力されているか」でフォームの見た目やルールを変えることはできません。

「個人のお客様に会社名は不要」「請求書払いのときだけ請求先住所が要る」——現場のルールは値に紐づいているのに、標準機能はそこに手が届かない。このずれが、入力ミスと「入力しない運用ルール」の氾濫を生みます。下のデモで違いを体感してみてください。

標準機能でできること（まずは正しく使い切る）

• フィールドのアクセス権：ユーザー・組織・ロールを条件に、フィールドの閲覧・編集を制限できます。「経理以外は金額を編集できない」はこれで実現できます。
• レコードの条件アクセス権：レコードの値を条件に、レコード単位の閲覧・編集を制限できます（フィールド単位の表示切替はできません）。
• プロセス管理：ステータスごとに作業者を決め、それ以外の人の編集を止められます。
• グループフィールド・ラベル：「法人の方のみ入力」の注意書きや、折りたたみでの整理はできます。

標準機能ではできないこと

• 値を条件にした表示・非表示：「区分＝法人のときだけ会社名を表示」はできません。
• 値を条件にした必須切替：「ステータス＝受注なら受注日を必須」はできません（必須は常に必須です）。
• 値を条件にした編集禁止：「承認済みになったら金額を読取専用に」はできません。

フィールドの条件制御を実現する3つの方法【比較】

方法1：フォーム設計と運用で工夫する（代替方法・無料）

制御そのものは諦め、迷いにくいフォームで誤入力を減らす方向です。グループフィールドで「法人のお客様のみ」の項目群をまとめ、ラベルで注意書きを添え、入力マニュアルを整備します。

メリットは費用ゼロで今日できること。デメリットは、強制力がないことに尽きます。注意書きは読まれない前提で設計すべきで、「個人なのに会社名が入っている」「必須のはずの受注日が空」というデータは残り続けます。データが汚れてからの掃除は、防止よりずっと高くつきます。

方法2：JavaScriptで制御を自作する（無料〜外注10万円台）

kintoneはJavaScriptカスタマイズを公式にサポートしており、条件制御も実装できます。表示・非表示は変更イベント（app.record.edit.change）と表示切替API（kintone.app.record.setFieldShown）の組み合わせで、比較的素直に作れます。

一方、必須の切り替えには専用のAPIがありません。保存イベント（submit）で値を自前チェックしてエラーを返す実装になり、読取専用はフィールドのdisabled制御で行います。効果の種類ごとに実装方法が異なるのが、この道の実態です。

メリットはライセンス費用が不要なこと。デメリットと注意点は3つあります。

1. 分岐の爆発：条件が2つ、3つと増えるたびにコードの分岐が増え、「受注かつ100万円以上」のような複合条件で一気に複雑化します。
2. 画面種別ごとの対応：追加画面・編集画面・一覧上の編集・モバイルと、同じ制御を複数の画面に実装する必要があります。
3. 属人化：「この条件も足したい」という現場の要望のたびにコード修正が必要で、作った人が異動すると入力ルールそのものが凍結します。

方法3：条件付きフィールド制御プラグインを使う（ノーコード・GUI設定）

プラグインは、kintoneに機能を追加する公式の仕組みです。bstの条件付きフィールド制御プラグインの場合、設定は「条件を選ぶ → 効果を選ぶ」の2ステップだけ。できるようになることは3つです。

条件は「受注 かつ 100万円以上」のようなAND条件に対応し、ルールは何本でも作成できます。効果は複数フィールドにまとめて適用でき、設定画面では保存前に動きを確認できます。メリットは導入の速さと、ルール変更を現場で完結できること。デメリットは年額費用（例: ¥19,800/年）がかかることです。制御の処理はブラウザ内で完結し、業務データが外部に送信されることはありません。

導入前の注意点として、入力制御系プラグインを選ぶ際は次の4点を確認してください。

1. 効果の種類：表示切替だけでなく、必須と読取専用まで制御できるか（入力ミスの型は1つではありません）
2. 条件の表現力：AND条件などの組み合わせに対応し、ルールを本数の制限なく足せるか
3. データの扱い：制御は画面上だけで、フィールドや保存済みデータに手を加えない設計か
4. 外部通信の有無：業務データが外部サーバーへ送られない設計か（情報システム部門の審査ポイントです）

入力ミスを仕組みで防ぐ、ルール設計の3つのコツ（業務改善の視点）

制御の手段を手に入れても、ルールの設計が悪いと逆に混乱します。コツは3つです。

社内稟議・情報システム部門への説明ポイント

有料プラグインの導入に承認が必要な場合は、次の3点で説明すると通りやすくなります。

活用イメージとよくある質問

現場での活用イメージ

条件付きフィールド制御がよく使われる典型的な場面を3つ紹介します（特定の導入企業の事例ではなく、想定される代表的な活用パターンです）。自社のフォームに近いものがあれば、試用版で同じルールを再現してみてください。

• 顧客・申込管理×区分：法人なら会社名・部署を表示して必須に、個人なら非表示に。冒頭のデモそのままの、最も基本的で効果の大きい使い方です。
• 案件管理×ステータス：受注になったら受注日と受注金額を必須に、失注なら失注理由を必須に。「あとで入れます」が残らない仕組みです。
• 申請・承認×確定ロック：承認済みになったら金額と条件面を読取専用に。承認後の改変を防ぎ、監査にも説明できる状態を保ちます。

よくある質問

まとめ：良いフォームは、正しい入力しかできないフォーム

• kintoneの標準制御は「誰か」を条件にするもので、「入力された値」ではフォームを変えられない
• まずはアクセス権とプロセス管理という標準の強制力を使い切る。人単位の制御はそれで足りる
• 値を条件にした制御が必要なら、内製体制があればJavaScript、なければプラグインが総コスト最小
• 選定時は効果の種類（表示・必須・読取専用）・条件の表現力・データ不変・外部通信なしの4点を確認する
• ルール設計はまず隠す・必須は条件付きで・ロックは確定の瞬間に。仕組みが注意力を代替する

関連記事: kintoneの入力ミスを減らす7つの対策 ／ kintoneのドロップダウンを連動させる方法3選 ／ kintoneフォームをタブで整理する方法3選