kintoneカスタマイズの設計方法｜標準機能・プラグイン・JavaScriptを分ける

kintoneを使い始めると、次のような要望が出ます。

入力項目を条件によって出し分けたい。

特定の状態では編集できないようにしたい。

一覧にボタンを出したい。

自動採番したい。

入力チェックを厳しくしたい。

外部サービスからデータを取得したい。

画面を部署に合わせて使いやすくしたい。

プラグインで足りないところをJavaScriptで補いたい。

これらは、どれも「カスタマイズ」と呼ばれます。

ただし、全部を同じ扱いにすると失敗します。

• 標準機能でできることをJavaScriptで作ってしまう
• プラグインを複数入れすぎて、どれがどの画面を変えているか分からない
• PC画面だけ動き、スマートフォンで使えない
• JavaScriptで非表示にしただけなのに、権限制御したつもりになる
• 担当者の個人管理ファイルをアップロードしており、変更履歴が追えない
• kintoneの画面変更やアプリ設定変更で、カスタマイズが壊れる
• テスト環境がなく、本番アプリで直接試してしまう
• 退職や異動で、誰も直せないカスタマイズだけが残る
• 外部連携まで画面JavaScriptで処理し、失敗時の再実行ができない

kintoneカスタマイズは、便利にするための手段です。

しかし、作れば作るほど保守対象も増えます。

重要なのは、JavaScriptを書けるかどうかではなく、業務要件に対してどの手段を選ぶかです。

kintoneカスタマイズで最初に決めるべきなのは、JavaScriptで何を書くかではなく、標準機能、プラグイン、JavaScript/CSS、外部連携のどれに任せるかです。

この記事では、kintoneカスタマイズを、実装方法の紹介ではなく、保守できる業務システムとして設計する方法として整理します。

kintone API連携の設計方法はこちら
kintone外部連携の設計方法はこちら
kintoneセキュリティ設計はこちら
kintoneプロセス管理の設計方法はこちら

カスタマイズ前に業務要件を分ける

kintoneカスタマイズでは、最初に要望を実装単位へ分けます。

「使いやすくしたい」だけでは、設計できません。

要望	実装前に決めること
入力しやすくしたい	どの画面で、誰が、どの項目を入力するのか
入力ミスを防ぎたい	標準の必須、重複禁止、計算、入力制限で足りるか
条件で表示を変えたい	見た目の切り替えか、権限として守るべきか
自動処理したい	保存前、保存後、ステータス変更時、夜間処理のどれか
外部サービスとつなぎたい	画面操作時か、サーバー側処理か、バッチ処理か
承認を分けたい	プロセス管理で足りるか、追加制御が必要か
帳票やメールを出したい	プラグインか、外部サービス連携か、個別開発か
表示を整えたい	一覧、詳細、ポータル、スマートフォンのどこか

この段階で、「標準機能で済む要件」と「作る必要がある要件」を分けます。

標準機能でできることまでJavaScriptで作ると、後でアプリ設定を変えたときに崩れやすくなります。

一方で、標準機能だけで無理に運用すると、現場に手作業や確認漏れが残ります。

まずは、業務上の目的を次のように言い換えます。

悪い例: 入力画面をいい感じにしたい
良い例: 受注ステータスが「確定」のときだけ、出荷予定日を必須にしたい

悪い例: ボタンを追加したい
良い例: 見積承認済みレコードだけ、契約作成アプリへ必要項目を引き継ぎたい

悪い例: 外部システムと連携したい
良い例: kintoneの顧客番号をキーに、会計システムの請求先IDを夜間に同期したい

要件が具体化すると、標準機能、プラグイン、JavaScript、REST APIのどれを使うべきか判断できます。

標準機能で済ませるべき要件

kintoneカスタマイズでは、まず標準機能で済むかを確認します。

標準機能でできるなら、保守が軽く、引き継ぎもしやすいからです。

要件	標準機能で検討するもの
必須入力	フィールド設定、プロセス管理、運用ルール
選択肢入力	ドロップダウン、ラジオボタン、チェックボックス
計算	計算フィールド、数値フィールド
参照	ルックアップ、関連レコード一覧
承認	プロセス管理
通知	条件通知、リマインダー、アプリ通知
権限	アプリ、レコード、フィールドのアクセス権
一覧整理	一覧、絞り込み、グラフ

たとえば、「担当者以外に見せたくない」という要件は、JavaScriptで非表示にする話ではありません。

アクセス権で制御する話です。

「特定のステータスで承認者に回したい」という要件は、まずプロセス管理で考えます。

「関連する顧客情報を表示したい」という要件は、まずルックアップや関連レコード一覧を確認します。

標準機能で済ませるべき要件をJavaScriptで作ると、次の問題が出ます。

• アプリ管理画面を見ても仕様が分からない
• 権限設定と画面制御が二重になる
• スマートフォンで同じ挙動にならない
• アプリコピーやテンプレート化で引き継ぎにくい
• ちょっとした項目追加でもコード修正が必要になる

kintoneカスタマイズは、標準機能で表現できる業務ルールまでコード化しないことが重要です。コードは最後に残る保守対象です。

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

プラグインで対応する要件

標準機能では足りないが、よくある業務要件であれば、プラグインや連携サービスを検討します。

kintoneの歩き方では、プラグインや連携サービスは複数のJavaScriptやCSSをひとつのパック、またはサービスとして適用できる追加プログラムであり、独自開発はJavaScriptやCSSでアプリの動作や画面をカスタマイズするものだと説明されています。

kintoneの歩き方：JavaScriptやCSSカスタマイズのよくある例

プラグインが向いているのは、次のような要件です。

要件	プラグインが向く理由
帳票出力	既存の帳票テンプレート、PDF出力、印刷設定を使える
メール送信	テンプレート、送信履歴、添付、宛先管理がまとまっている
カレンダー表示	UIやドラッグ操作を作り込まずに使える
ガントチャート	期間、担当、進捗を専用UIで見られる
入力制御	画面で条件を設定できる製品がある
ストレージ連携	Box、Google Drive、OneDriveなどとの連携部品を使える
外部サービス連携	API認証やログを製品側に任せられる場合がある

プラグインは、買えば終わりではありません。

導入前に次を確認します。

確認項目	見ること
対応範囲	要件のどこまで標準設定でできるか
保守	提供元のサポート、更新頻度、障害対応
権限	kintoneのアクセス権とどう連動するか
スマートフォン	モバイル画面で使えるか
他プラグインとの干渉	同じ画面、同じイベントを触らないか
データの持ち方	設定情報や外部IDをどこに持つか
解約時	プラグインを外した後、データや画面がどうなるか

プラグインは、標準機能と個別開発の中間です。

よくある要件なら速く導入できます。

ただし、プラグインの仕様に業務を合わせる必要があります。

業務が複雑すぎる場合や、複数アプリをまたぐ厳密な制御が必要な場合は、個別開発を検討します。

JavaScript/CSSで作る要件

JavaScript/CSSカスタマイズは、kintone画面上の動作や表示を変えたいときに使います。

kintone公式ヘルプでは、JavaScriptやCSSを利用してアプリの動作や画面をカスタマイズでき、PC用とスマートフォン用で分けてカスタマイズすると説明されています。また、アプリの設定画面からJavaScript/CSSファイルを適用する流れが示されています。

kintoneヘルプ：JavaScriptやCSSでアプリをカスタマイズする

JavaScript/CSSが向いているのは、次のような要件です。

要件	例
画面表示の制御	ステータスに応じて補足欄を表示する
入力補助	郵便番号から住所候補を入れる、関連項目を自動入力する
保存前チェック	組み合わせ条件を確認し、エラーを出す
一覧の操作補助	一覧に処理ボタンを追加する
色やラベルの補助	期限超過や重要度を見やすくする
アプリアクション補助	条件を見て遷移先を変える
外部画面への導線	関連システムへのリンクを出す

ただし、JavaScriptで作るべきではないものもあります。

避けたい要件	理由
権限そのもの	非表示にしても、アクセス権の代わりにはならない
大量データ処理	画面表示時に重くなりやすい
長時間処理	ブラウザを閉じると止まりやすい
夜間同期	画面操作に依存しない処理にすべき
秘密情報の保持	ブラウザに認証情報を置くべきではない
複雑な外部連携	失敗ログや再実行が弱くなりやすい

JavaScriptは、ユーザーが画面を開いたとき、入力したとき、保存したときなどのイベントで動きます。

cybozu developer networkのJavaScript APIドキュメントでは、レコード一覧画面、詳細画面、追加画面、編集画面などのイベント、フィールド表示、API実行、プラグイン関連のAPIが整理されています。

cybozu developer network：kintone JavaScript API

このイベント単位を理解すると、どこで処理すべきか判断できます。

保存前に止めるのか。

保存後に別アプリへ登録するのか。

一覧表示時にボタンを出すのか。

詳細画面で外部リンクを表示するのか。

処理のタイミングを間違えると、同じカスタマイズでも事故の起き方が変わります。

API・外部連携へ出す要件

画面上のカスタマイズで済ませないほうがよい要件もあります。

外部システムとの同期、夜間バッチ、会計システム連携、在庫連携、複数アプリの一括更新などは、REST APIや外部処理として設計します。

要件	画面JavaScriptではなく外部連携を検討する理由
夜間同期	ユーザー操作に依存しない
複数アプリ更新	失敗時の再実行単位を持たせやすい
外部SaaS連携	認証情報をサーバー側で管理できる
大量データ処理	API制限、分割処理、ログを設計しやすい
監査ログ	誰が、いつ、何を処理したか残しやすい
リトライ	失敗分だけ再実行しやすい

画面JavaScriptでREST APIを呼ぶこと自体はできます。

しかし、業務処理の中心をブラウザに置くと、処理の途中で画面を閉じた、ネットワークが切れた、権限が違った、といった問題が起きます。

外部連携では、kintone、外部SaaS、連携処理、ログ、再実行の責任分界を決めます。

APIトークンやOAuth、Webhook、バッチ処理の選定も必要です。

kintone API連携の設計方法はこちら
kintone API制限の設計方法はこちら

画面を便利にする処理はJavaScript、業務データを外部と同期する処理はREST APIや外部連携として分けると、障害時に追いやすくなります。

PC・モバイル・権限の注意点

kintoneカスタマイズでは、PCだけ見て判断しないことが重要です。

公式ヘルプでも、JavaScript/CSSはPC用とスマートフォン用で分けてカスタマイズすると説明されています。

現場入力、承認、写真登録、在庫確認などは、スマートフォンで使われることがあります。

PCでだけ動くカスタマイズを入れると、現場では標準画面に戻ってしまうことがあります。

設計時には、次の表で確認します。

観点	確認すること
PC画面	一覧、詳細、編集、追加、印刷で動くか
モバイル	モバイルブラウザ、スマートフォンアプリで必要か
一覧編集	一覧のインライン編集に対応するか
プロセス管理	アクション実行時に処理が必要か
権限	非表示ではなく、アクセス権で守るべき情報か
ゲストスペース	外部ユーザーでも動く必要があるか
ブラウザ	利用ブラウザ、拡張機能、社内制限に影響されないか

特に権限は分けます。

JavaScriptでフィールドを隠すことは、見た目の制御です。

権限として守るべき情報は、アプリ、レコード、フィールドのアクセス権で制御します。

JavaScriptで見えなくしただけでは、仕様変更や別画面、API、CSV出力などの経路で問題が出る可能性があります。

画面の使いやすさと情報保護は、別の設計項目です。

kintoneセキュリティ設計はこちら

検証環境・リリース・保守体制

kintoneカスタマイズは、作って終わりではありません。

保守できる形で残す必要があります。

最低限、次を管理します。

管理項目	内容
要件メモ	何の業務課題を解くためのカスタマイズか
対象アプリ	アプリID、アプリ名、関連アプリ
対象画面	一覧、詳細、追加、編集、モバイルなど
ファイル	JavaScript/CSSのファイル名、保存場所、バージョン
設定	適用順、CDN、ライブラリ、プラグインとの関係
権限	実行ユーザー、必要なアプリ権限、APIトークン
テスト観点	正常系、異常系、権限別、PC・モバイル
リリース手順	検証、本番反映、戻し方、関係者通知
保守担当	修正できる人、レビューできる人、問い合わせ先

本番アプリで直接試すのは避けます。

検証用アプリ、検証スペース、テストデータを用意します。

小さな変更でも、次のような確認が必要です。

• 既存レコードで表示が崩れないか
• 必須入力や保存前チェックが過剰に止めないか
• 権限の違うユーザーで動くか
• モバイルで必要な画面が使えるか
• プラグインや他のカスタマイズと干渉しないか
• エラー時にユーザーへ分かる表示が出るか
• 戻す手順があるか

カスタマイズは、運用中に必ず変わります。

項目が増える。

ステータスが変わる。

部署が増える。

承認ルートが変わる。

外部サービスの仕様が変わる。

そのたびに直せるよう、仕様、コード、設定、リリース履歴を残します。

よくある失敗

kintoneカスタマイズでは、次の失敗が起きやすいです。

標準機能でできることをコードで作る

必須入力、選択肢、計算、通知、アクセス権など、標準機能で表現できるものをJavaScriptで作ると、保守が重くなります。

まず標準機能でできるか確認します。

プラグインとJavaScriptが同じ画面を触る

同じ画面、同じフィールド、同じ保存イベントを複数のプラグインやJavaScriptが触ると、原因調査が難しくなります。

適用順と役割を整理します。

PCだけでテストする

スマートフォンで入力する業務なのに、PCだけで確認すると現場で使えません。

モバイルが必要な業務は、最初から要件に入れます。

非表示を権限と勘違いする

JavaScriptで隠すことと、アクセス権で守ることは違います。

見せないだけでよい項目と、権限として守る項目を分けます。

個人管理のファイルをそのまま適用する

誰のPCに最新ファイルがあるのか分からない状態は危険です。

ファイルの保存場所、バージョン、変更理由、リリース日を管理します。

外部連携まで画面操作に依存させる

ユーザーが画面を開いたときだけ同期する設計は、漏れや失敗に弱いです。

業務上重要な連携は、サーバー側処理やバッチ、Webhook、ログ、再実行を検討します。

仕様を誰も読めない

コードは残っていても、なぜその処理があるのか分からないと直せません。

要件、対象画面、例外、権限、テスト観点を残します。

実装前チェックリスト

kintoneカスタマイズを始める前に、次の項目を確認します。

確認項目	判断すること
業務目的	何の作業ミス、確認漏れ、手戻りを減らすのか
標準機能	アクセス権、プロセス管理、通知、ルックアップで足りるか
プラグイン	既存製品で要件に合うものがあるか
JavaScript/CSS	画面表示、入力制御、保存前チェックとして妥当か
API連携	外部同期、バッチ、再実行が必要か
PC・モバイル	どの端末、どの画面で必要か
権限	見た目の制御か、アクセス権として守るべきか
検証環境	本番以外で試せるか
変更履歴	ファイル、設定、理由を残せるか
リリース	戻し方、通知先、確認者が決まっているか
保守担当	修正できる人、レビューできる人がいるか

この表が埋まらないまま実装を始めると、カスタマイズが増えるほど保守しにくくなります。

逆に、要件を分けられれば、標準機能で済ませるところ、プラグインを使うところ、JavaScriptで作るところ、API連携へ出すところが明確になります。

Bitlightに相談できること

Bitlightでは、kintoneカスタマイズを、単なるJavaScript実装ではなく、業務要件と保守体制から整理します。

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

• 標準機能、プラグイン、JavaScript/CSS、API連携の切り分け
• 入力制御、保存前チェック、一覧ボタン、画面表示の設計
• PC・モバイルの利用シーン整理
• アクセス権と画面制御の分離
• 既存プラグインや既存カスタマイズの棚卸し
• 検証環境、本番反映、戻し手順の整備
• API連携、Webhook、外部処理への切り出し
• 保守担当、変更履歴、属人化防止の設計

「kintoneをカスタマイズしたい」という相談は、実際には業務要件の整理から始まります。

どこまで標準機能で持たせるか。

どこをプラグインで買うか。

どこをJavaScriptで作るか。

どこを外部連携に出すか。

kintoneカスタマイズは、作れるものを増やす作業ではなく、作らなくてよいものを標準機能に戻し、作るべきものだけを保守できる形で残す設計です。

この判断ができると、カスタマイズが増えても、業務変更や担当交代に耐えやすくなります。