kintoneアプリ開発の進め方｜標準機能・JavaScript・API連携を分ける

kintoneアプリ開発という言葉は、かなり広く使われます。

新しいアプリを作ること。

フォームや一覧を整えること。

JavaScriptやCSSで画面を変えること。

プラグインを入れること。

REST APIで外部SaaSとつなぐこと。

帳票、CSV、基幹システム、会計ソフト、Google Workspaceなどと連携すること。

これらはすべて、広い意味ではkintoneアプリ開発です。

しかし、実務で失敗しやすいのは、開発技術の選び方ではありません。

どこまでをkintoneの標準機能で作り、どこからを追加開発にするかが曖昧なまま始めることです。

たとえば、次のような状態です。

• 標準の一覧で足りるのに、最初から独自画面を作る
• 選択肢やプロセス管理で表せる業務ルールをJavaScriptへ埋め込む
• データ構造が決まらないまま外部連携を作る
• API連携の更新キーや失敗時の戻し方を決めない
• プラグインを入れた後に、誰も設定意図を説明できない
• 検証環境なしで本番アプリへ直接反映する
• 開発した人しか直せないアプリになる
• 社内の担当者と外部開発会社の責任範囲が曖昧になる

kintoneは、標準機能だけでもかなり多くの業務を作れます。

一方で、業務に合わせた入力制御、画面操作、外部連携、バッチ処理、帳票出力、既存システム連携が必要になることもあります。

だからこそ、アプリ開発の最初に決めるべきことは、コードを書く範囲ではありません。

標準機能、JavaScript/CSS、REST API、プラグイン、外部システムの責任分担です。

kintoneアプリ開発で最初に決めるべきなのは、何を作るかではなく、何を標準機能に任せ、何を追加開発として保守対象にするかです。

この記事では、kintoneアプリ開発を、開発会社探しや技術選定ではなく、業務要件、データ設計、標準機能、JavaScript、REST API、プラグイン、検証環境、保守運用に分けて整理します。

kintoneアプリ作成の設計方法はこちら
kintoneデータベースの設計方法はこちら
kintoneカスタマイズの設計方法はこちら
kintone API連携の設計方法はこちら

開発前に業務要件を整理する

kintoneアプリ開発を始める前に、まず業務要件を整理します。

ここでいう要件は、画面に置きたい項目の一覧ではありません。

誰が、いつ、どの情報を入力し、誰が確認し、どの状態になったら次の処理へ進むのか。

この流れを決めることです。

確認すること	開発判断への影響
1レコードの意味	1案件、1申請、1作業、1履歴のどれかを決める
入力者	フォーム配置、必須項目、モバイル対応が変わる
確認者	プロセス管理、通知、権限が変わる
更新タイミング	保存時チェック、ステータス更新、外部連携の発火条件が変わる
正本データ	kintoneを正本にするか、外部システムを正本にするか決める
例外処理	手動修正を許すか、エラーとして止めるか決める
外部連携	REST API、Webhook、CSV、バッチ処理の必要性を判断する
保守担当	標準機能中心か、コード管理が必要かを判断する

たとえば、案件管理アプリを開発する場合、案件名、顧客名、金額、担当者だけでは足りません。

受注確度、見積状態、契約状態、請求状態、失注理由、次回アクション、営業担当、上長確認、経理確認、外部会計ソフトとの連携有無まで見る必要があります。

この時点で、次のように分けます。

• 顧客情報は顧客マスタへ分ける
• 案件情報は案件管理アプリへ置く
• 活動履歴は履歴アプリへ分ける
• 請求や入金は会計側との連携を検討する
• 受注確度やステータスは選択肢やプロセス管理で表す
• 画面上の注意喚起だけJavaScriptで補う

この整理をせずに「一覧を見やすくしたい」「ボタンを付けたい」「会計ソフトとつなぎたい」から始めると、開発対象が膨らみます。

開発前に、業務データの分け方を決めます。

kintoneデータベースの設計方法はこちら

標準機能で作れる範囲

kintoneアプリ開発では、最初に標準機能で作れる範囲を確認します。

標準機能で済むものまでコード化すると、将来の変更が重くなります。

標準機能で検討するもの	例
フォーム	文字列、数値、日付、選択肢、ユーザー選択、テーブル
一覧	担当者別、期限別、ステータス別、未対応一覧
グラフ	件数、金額、分類、月別、担当者別
プロセス管理	申請中、確認中、承認済み、差し戻し
アクセス権	アプリ、レコード、フィールドごとの閲覧や編集
通知	登録時、更新時、期限前、ステータス変更時
ルックアップ	顧客マスタや商品マスタから情報を取得する
関連レコード一覧	顧客に紐づく案件や履歴を表示する

たとえば、ステータスごとの承認ルートは、まずプロセス管理で表せないか確認します。

担当者別の未対応一覧は、まず標準一覧で表せないか確認します。

顧客名や商品名の表記揺れは、まずルックアップやマスタ設計で抑えられないか確認します。

入力漏れは、まず必須設定、選択肢、一覧、通知で抑えます。

kintoneアプリ開発では、標準機能で表せる業務ルールをコードへ逃がさないことが重要です。コードは便利な反面、保守対象になります。

kintoneワークフローの設計方法はこちら
kintone通知の設計方法はこちら
kintone一覧カスタマイズの設計方法はこちら

JavaScript・CSSが必要な範囲

標準機能で足りない場合、JavaScriptやCSSでアプリを補うことがあります。

kintone公式ヘルプでは、JavaScriptやCSSを用いて作成したカスタマイズファイルをアプリに適用する手順が説明されています。

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

Kintone Developer ProgramのJavaScript APIドキュメントでは、レコード一覧、詳細、追加、編集、グラフ、ポータルなどのイベントや、レコード値の取得、画面要素の操作、REST APIリクエストなどが整理されています。

Kintone Developer Program：Kintone JavaScript API

JavaScriptやCSSが向いているのは、主に画面上の補助です。

開発対象	例
入力補助	条件に応じた初期値、入力欄の表示切り替え
保存前チェック	複数項目をまたぐ入力チェック、注意メッセージ
一覧の操作	ボタン追加、行の表示調整、簡易一括処理
画面導線	関連画面へのリンク、担当者向けの操作ボタン
視認性	注意すべきレコードの強調、補足表示

ただし、JavaScriptで何でも作るのは危険です。

画面上では止められても、API、CSV、別アプリからの更新で同じ制御が効かないことがあります。

また、デスクトップとモバイルで利用できるイベントや画面構造が異なる場合もあります。

そのため、JavaScriptで実装する前に、次を確認します。

• 標準機能で代替できないか
• デスクトップとモバイルの両方で必要か
• 一覧、詳細、追加、編集のどの画面で動かすか
• APIやCSV更新時にも同じルールが必要か
• 権限設定と矛盾しないか
• 変更時に誰がコードを直すか

たとえば、承認済みレコードの金額欄を編集不可に見せるだけなら、画面上の制御で済むかもしれません。

しかし、承認済みレコードの金額変更を業務として禁止したいなら、権限、プロセス管理、運用ルール、API更新経路まで含めて考える必要があります。

画面を便利にする処理と、業務データを守る処理を混ぜないことが重要です。

kintoneカスタマイズの設計方法はこちら

REST API・外部連携が必要な範囲

外部SaaS、基幹システム、会計ソフト、Google Workspace、帳票システムなどとつなぐ場合、REST APIやWebhook、バッチ処理を検討します。

Kintone Developer ProgramのREST APIドキュメントでは、アプリ、レコード、ファイル、スペースを扱うAPIが整理されています。

Kintone Developer Program：Kintone REST API

kintoneヘルプでは、APIトークンが外部プログラムからkintone REST APIを実行する際の認証に使われることが説明されています。

kintoneヘルプ：APIトークンを生成する

API連携で最初に決めるべきなのは、接続方法ではありません。

どちらのシステムが正本かです。

設計項目	決めること
正本	kintone、外部SaaS、基幹システムのどれを正とするか
更新方向	片方向か、双方向か
更新キー	レコード番号、顧客コード、注文番号、外部IDのどれか
実行タイミング	保存時、Webhook、夜間バッチ、手動実行
認証	APIトークン、OAuth、セッションなど
ログ	成功、失敗、再実行対象をどこに残すか
例外処理	重複、削除、差し戻し、外部側エラーをどう扱うか
権限	APIで更新してよい項目と、手動更新だけの項目を分ける

たとえば、会計ソフトへ請求データを送る場合、kintoneの案件アプリから直接請求登録するだけでは不十分です。

送信済みか。

会計側のIDはどこへ保存するか。

送信後に金額が変わったらどうするか。

再送して二重登録にならないか。

外部側でエラーになった場合、誰がどの一覧を見るか。

これらを決めてから実装します。

REST API連携は、データを送れるかどうかより、正本、更新キー、ログ、再実行、手動修正の扱いを決めることが重要です。

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

プラグイン開発と既製プラグインの判断

kintoneアプリ開発では、既製プラグインを使うか、独自に開発するかも判断します。

Kintone Developer Programには、インストール済みプラグインやプラグイン関連APIのドキュメントがあります。

Kintone Developer Program：Plug-ins

プラグインを検討する場面は、次のようなときです。

選択肢	向いているケース	注意点
既製プラグイン	汎用的な要件で、設定だけで使える	仕様変更や料金、対応範囲を確認する
独自プラグイン	複数アプリで同じ機能を使い、設定画面も必要	開発、配布、更新、問い合わせ対応が必要
アプリ個別JavaScript	特定アプリだけの画面補助や入力制御	横展開すると管理が散らばる
外部サービス	帳票、フォーム、メール、会計など専用機能が強い領域	kintone側との責任分担を決める

既製プラグインは、要件に合えば強い選択肢です。

ただし、業務ルールが複雑で、例外処理や外部連携まで含む場合、設定だけで吸収しきれないことがあります。

独自プラグインは、複数アプリに同じ機能を配る場合に向きます。

一方で、1アプリだけの小さな画面補助なら、アプリ個別のJavaScriptで足りることもあります。

重要なのは、プラグインを入れる前に、次を決めることです。

• 何をプラグインに任せるか
• 標準機能やJavaScriptで代替できるか
• 設定変更は誰が行うか
• バージョン更新時に誰が確認するか
• 使えなくなった場合の代替手段はあるか
• 複数アプリに入れる場合、設定の差分をどう管理するか

プラグインは便利ですが、入れた瞬間から保守対象になります。

使う理由と、使わなくなったときの戻し方を決めておきます。

内製と外注の役割分担

kintoneアプリ開発は、すべて外注する必要はありません。

むしろ、業務を知っている社内担当者と、設計や実装を担う外部担当者の役割を分けたほうが進みやすいです。

領域	社内で持つべきこと	外部に頼みやすいこと
業務要件	現場の流れ、例外、判断基準	要件の整理、アプリ構成への変換
データ設計	正本データ、コード体系、運用ルール	マスタ分割、更新キー、連携設計
標準機能	日常的な項目追加、一覧修正	初期構成、権限、プロセス管理設計
JavaScript	運用上の希望、画面上の困りごと	実装、コード管理、テスト
API連携	連携先の業務ルール、エラー時の対応	認証、ログ、再実行、バッチ処理
保守	問い合わせ窓口、変更要望の判断	不具合調査、改修、影響確認

社内で持つべきなのは、業務判断です。

外部に頼むべきなのは、設計の整理、実装、テスト、保守しやすい形への落とし込みです。

逆に、業務判断まで外注すると、完成したアプリが現場に合わないことがあります。

また、外部開発会社へ依頼するときは、次を明確にします。

• 要件定義だけ頼むのか
• 初期構築まで頼むのか
• JavaScriptやAPI連携まで頼むのか
• 仕様変更の扱いはどうするか
• 軽微な項目変更は社内で行うのか
• 障害時の連絡先はどこか
• コードや設定資料は納品されるか

kintoneは社内で触りやすいツールです。

だからこそ、社内で触る部分と、外部に任せる部分を最初に分ける必要があります。

検証環境・リリース・保守運用

kintoneアプリ開発では、作って終わりにしないために、検証環境、リリース手順、保守運用を決めます。

項目	決めること
検証環境	本番アプリへ直接反映しないための確認場所
テストデータ	本番に近いが、個人情報や重要情報を含めすぎないデータ
リリース手順	いつ、誰が、どの設定やコードを反映するか
戻し方	問題が出たときに前の状態へ戻せるか
仕様書	フィールド、一覧、権限、コード、連携先、処理条件
変更履歴	いつ、何を、なぜ変えたか
監視	外部連携の失敗、ログ、未処理、期限超過
保守窓口	現場からの問い合わせ先と改修判断者

特にJavaScriptやAPI連携を入れる場合、リリース前の確認が重要です。

画面上では動いても、権限の違うユーザーでは動かないことがあります。

スマホでは表示が崩れることがあります。

外部SaaS側の制限や認証切れで止まることがあります。

本番データで二重更新が起きることがあります。

そのため、リリース前に次を確認します。

• 管理者以外のユーザーで動くか
• 閲覧だけのユーザーに不要なボタンが出ないか
• モバイルで必要な操作ができるか
• API更新時に同じ業務ルールが守られるか
• 失敗ログが残るか
• 再実行しても二重登録にならないか
• 変更前に戻せるか

kintoneアプリ開発は、リリースした瞬間が完成ではありません。検証環境、戻し方、ログ、変更履歴、保守担当まで決めて初めて運用できます。

よくある失敗

kintoneアプリ開発では、次の失敗が起きやすいです。

最初からコードで作る

標準機能でできることまでJavaScriptで作ると、後から項目追加や権限変更が重くなります。

まず標準機能で表せる範囲を確認します。

業務データの正本が決まっていない

kintoneと外部システムのどちらが正しいのか決まらないまま連携すると、差分が出たときに戻せません。

正本、更新キー、同期方向を決めます。

画面制御と業務制御を混ぜる

JavaScriptで画面上の入力を止めても、APIやCSVから更新される経路が残る場合があります。

本当に守るべきルールは、権限、プロセス管理、外部連携の設計まで含めます。

プラグインを入れすぎる

小さな要望ごとにプラグインを増やすと、設定や更新の管理が難しくなります。

既製プラグイン、独自プラグイン、JavaScript、標準機能の使い分けを決めます。

検証環境がない

本番アプリへ直接反映すると、動作確認中に現場業務へ影響します。

特にコードや外部連携を入れる場合は、検証環境で確認します。

外注範囲が曖昧

要件定義、実装、テスト、保守、軽微修正のどこまでを頼むのか曖昧だと、完成後に止まります。

社内で判断する部分と、外部へ任せる部分を分けます。

仕様変更の扱いを決めていない

開発中に現場から追加要望が出るのは普通です。

ただし、すべてを同じリリースに入れると、完成しません。

初回リリースに入れるもの、次回改善に回すものを分けます。

実装前チェックリスト

kintoneアプリ開発を始める前に、次の項目を確認します。

確認項目	判断すること
業務目的	何の業務をアプリ化、または改修するのか
1レコード	1件が何を表すのか
データ構造	マスタ、取引、履歴、集計を分ける必要があるか
標準機能	フォーム、一覧、プロセス管理、通知、権限で足りるか
JavaScript/CSS	どの画面で、何を補うのか
REST API	どの外部システムと、どの方向へ連携するのか
プラグイン	既製品で足りるか、独自開発が必要か
認証	APIトークン、OAuth、ユーザー権限をどう扱うか
ログ	失敗、再実行、二重登録防止をどう残すか
検証環境	本番反映前にどこで確認するか
リリース	いつ、誰が、どの手順で反映するか
保守	変更要望、不具合、問い合わせを誰が受けるか

この表を埋めると、開発対象が見えます。

標準機能で作るべき部分。

JavaScriptで補う部分。

REST APIでつなぐ部分。

プラグインで買う部分。

外部サービスに任せる部分。

社内で持つ部分。

外部へ依頼する部分。

この切り分けができていれば、kintoneアプリ開発は一回きりの改修で終わりにくくなります。

Bitlightに相談できること

Bitlightでは、kintoneアプリ開発を、コードを書く作業だけとしては扱いません。

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

• 既存業務と既存アプリの棚卸し
• 標準機能で作る範囲と追加開発する範囲の整理
• マスタ、取引、履歴、集計へのデータ分割
• JavaScript/CSSカスタマイズの要否判断
• REST API、Webhook、CSV、外部SaaS連携の設計
• 既製プラグイン、独自プラグイン、外部サービスの使い分け
• 検証環境、リリース手順、保守運用の整理
• 内製担当者と外部開発担当者の役割分担

kintoneアプリ開発で重要なのは、作れるものを増やすことではありません。

作らなくてよいものを標準機能に戻し、作るべきものだけを保守できる形で残すことです。

kintoneアプリ開発は、標準機能、JavaScript、REST API、プラグインを並べる作業ではなく、業務要件に対して最小限の保守対象を決める設計です。

この切り分けができれば、初回リリース後も、現場の変更要望に合わせてアプリを育てやすくなります。