kintoneは本当にノーコード？使い込むほど増えていくJavaScript・プラグイン・API
kintoneは「ノーコード・ローコードツール」として広く知られています。
実際、プログラムを書かなくても、ドラッグ＆ドロップを中心とした操作で業務アプリを作ることができます。
Excelや紙で管理していた業務を短期間でアプリ化したい場合には、非常に便利な仕組みです。
システムキューブでもkintoneを利用していますし、サイボウズ社のパートナーとしてkintoneの開発・カスタマイズにも携わっています。
そのうえで、システム開発会社として一つ考えておきたいことがあります。
kintoneは、本当に「ノーコードの業務システム」と言い切れるのでしょうか。
もう少し正確に言えば、
「ノーコードで始められること」と、「ノーコードのまま長期間使い続けられること」は、同じではないのではないか。
という疑問です。
kintoneは間違いなく「ノーコードで始められる」
最初に明確にしておきたいのは、kintoneをノーコードツールと呼ぶこと自体がおかしいという話ではありません。
サイボウズ社も公式サイトで、kintoneはドラッグ＆ドロップによるノーコード開発に加え、JavaScriptを利用したローコード開発、他システムとの連携、プラグインによる機能拡張にも対応していると説明しています。
例えば、
- 顧客管理
- 案件管理
- 日報
- 問い合わせ管理
- 備品管理
- 簡単な申請
- アンケート管理
といった業務であれば、プログラムを書かずに十分実用的なアプリを構築できるケースがあります。
これまで、
「Excelでは複数人で管理しにくい」
「Accessを使える担当者がいなくなった」
「小さな業務システムのために数百万円の開発費をかけるのは難しい」
と考えていた企業にとって、kintoneの登場によってシステム化のハードルが下がったことは大きなメリットです。
問題は、その先です。
業務で使い始めると「もう少しこうしたい」が増えてくる
最初は標準機能だけで十分だったアプリでも、実際に現場で使い始めると、さまざまな要望が出てきます。
例えば、
「この項目を入力したら、別の項目を自動計算してほしい」
「条件によって項目を表示・非表示にしたい」
「一覧画面をもっと見やすくしたい」
「見積番号を自動採番したい」
「別のアプリへ自動的にデータを反映したい」
「会計システムと連携したい」
「Webサイトから登録された情報を自動でkintoneへ入れたい」
「基幹システムのマスタ情報をkintoneでも利用したい」
といったものです。
ここから、kintoneは単純なノーコードアプリから少しずつ姿を変えていきます。
まず増えてくるのがプラグイン
標準機能では実現できないことが出てきたとき、最初の選択肢になりやすいのがプラグインです。
プラグインは非常に便利です。
自社でJavaScriptを書くことなく、
入力支援
帳票作成
アプリ間連携
検索機能強化
一覧画面改善
など、さまざまな機能を追加できます。
「標準機能では少し足りない」という状況を、比較的簡単に解決できます。
これはkintoneの大きな強みの一つです。
ただ、注意したいのは、
プラグインを追加することは、システムの構成要素を一つ増やすことでもある
という点です。
例えば10個のプラグインを利用すれば、それぞれについて、
どのアプリで使っているのか
何のために導入したのか
契約は誰が管理しているのか
費用はいくらなのか
将来も提供され続けるのか
といった管理が必要になります。
プラグインそのものが悪いわけではありません。
しかし、
「困ったらプラグインを追加する」
を繰り返していくと、数年後にはシステム全体の構成を把握しにくくなることがあります。
プラグインでも足りなければJavaScriptへ
さらに細かい要望が出てくると、JavaScriptを使ったカスタマイズが必要になる場合があります。
kintoneには正式にJavaScript APIが提供されており、JavaScriptやCSSを利用して画面やアプリの動作をカスタマイズできます。
これは非常に強力です。
kintoneの標準画面だけでは実現できない入力制御や表示変更なども可能になります。
ところが、この時点で状況は少し変わります。
JavaScriptを書いているのであれば、それはもう通常の意味での「ノーコード」ではありません。
プログラムです。
当然、
仕様を理解する人
ソースコードを管理する人
不具合が起きたときに調査する人
将来修正する人
が必要になります。
サイボウズ社自身も、kintoneはノーコードで始められる一方、高度な画面カスタマイズや外部サービスとの連携にはエンジニアのスキルが必要だと説明しています。
ここは、kintoneを長期間利用するうえで非常に重要なポイントだと思います。
さらに使い込むとREST APIや外部連携が登場する
kintoneにはREST APIも用意されています。
REST APIを利用すると、kintoneのレコードを取得・登録・更新したり、外部システムとデータをやり取りしたりできます。
例えば、
基幹システム
販売管理システム
ECサイト
Webフォーム
会計システム
外部データベース
などとの連携が可能になります。
ここまで来ると、kintoneは単独のノーコードツールというより、
企業システムを構成する一つのプラットフォーム
という性格が強くなってきます。
kintone
＋プラグイン
＋JavaScript
＋REST API
＋外部サービス
という構成になるからです。
この構成自体が悪いわけではありません。
むしろ、適切に設計されていれば非常に便利な仕組みになります。
ただし、
「ノーコードだからシステム部門がいなくても簡単に管理できる」
という当初のイメージとは、少し違うものになっている可能性があります。
いつの間にか普通の「システム開発」になっていないか
ここで一度、立ち止まって考えてみたいと思います。
例えば、ある企業のkintone環境が、
30個のアプリ
10種類のプラグイン
複数のJavaScriptカスタマイズ
外部システムとのAPI連携
独自の帳票
複雑なアクセス権
複数段階の承認フロー
という構成になっていたとします。
これは「ノーコードシステム」でしょうか。
少なくとも、システム会社から見ると、
かなり本格的な業務システムです。
しかもJavaScriptを書いている担当者が退職した場合、そのコードを誰かが読み解く必要があります。
API連携している外部システムが変更された場合には、連携部分を修正する必要があります。
利用しているプラグインが提供終了すれば、代替方法を検討する必要があります。
つまり、
ツールをノーコードで作ったかどうかと、システムをノーコードで保守できるかどうかは別問題
なのです。
サイボウズ自身が開発者向けに本格的な情報を提供している
この点は、サイボウズ社自身が非常によく理解していると思います。
cybozu developer networkには、
JavaScript API
REST API
Webhook
プラグイン
TypeScript
React
Vite
async/await
など、かなり本格的な開発者向け情報が用意されています。
2026年現在の開発者向けコンテンツでも、ViteによるJavaScript管理、TypeScript、React、REST API Clientなどが紹介されています。
ここまで来ると、
「プログラミング不要の簡単なノーコードツール」
という一面だけでkintoneを捉えるのは、少し違うのではないでしょうか。
むしろ、
ノーコードから始められ、必要に応じて本格的なシステム開発まで拡張できるプラットフォーム
と考える方が実態に近いように思います。
これは決して悪いことではありません。
むしろ高い拡張性を持っているということです。
ただ、その拡張性を使えば使うほど、当然ながら設計・開発・保守の重要性も高くなります。
「簡単に作れる」と「簡単に保守できる」は別の話
ノーコード・ローコードツールについて考えるとき、私たちはどうしても「作るときの簡単さ」に注目しがちです。
プログラミング不要。
短期間で構築できる。
現場担当者でもアプリを作れる。
これは非常に分かりやすいメリットです。
しかし企業の業務システムは、作った瞬間よりも、その後使っている期間の方が圧倒的に長くなります。
1年。
3年。
5年。
場合によっては10年以上使います。
そこで重要になるのは、
誰が仕様を管理するのか。
誰が変更するのか。
どのプラグインを利用しているのか。
JavaScriptはどこにあるのか。
外部システムとはどのAPIで連携しているのか。
担当者が退職しても変更できるのか。
といった問題です。
つまり、
開発のしやすさだけでなく、5年後・10年後の保守性まで含めてシステムを考える必要があります。
ノーコードだから「設計しなくてもよい」わけではない
ここは特に重要だと思います。
一般的なシステム開発では、
要件定義
データ設計
画面設計
権限設計
連携設計
テスト
などを行います。
ノーコードツールを使えば、プログラムを書く工程の一部を大幅に減らすことはできます。
しかし、
何をどう管理するかを考える工程までなくなるわけではありません。
例えば、
顧客マスタをどのアプリで持つのか。
案件と顧客をどう関連付けるのか。
同じ情報を複数アプリに持たせるのか。
権限をどうするのか。
将来どのシステムと連携するのか。
こうした設計を考えず、
「必要になったらアプリを作る」
「足りなければプラグインを入れる」
「さらに足りなければJavaScriptを書く」
という対応だけを繰り返すと、いつか全体構造が分かりにくくなります。
これはkintoneだから起きる問題ではありません。
AccessでもExcel VBAでも、スクラッチ開発でも同じです。
違うのは、
ノーコードツールは作り始めるハードルが低い分、全体設計を考える前にシステムが増えていきやすい
という点です。
kintoneは「ノーコードか？」より「どこまでノーコードで使うか」が重要
では、kintoneはノーコードなのでしょうか。
答えは、
「ノーコードでも使えるし、ローコードでも使える。そして必要なら本格的な開発もできる」
が一番正確だと思います。
標準機能で業務が完結するなら、ノーコードのメリットを最大限に活かせます。
少し足りない部分をプラグインで補うのも有効です。
JavaScriptやAPIを利用して高度なシステムを作ることもできます。
問題は、
どこまでkintone上で作り込むのか
という判断です。
例えば、標準機能で80％まで実現できる業務に、残り20％を実現するため大量のJavaScriptやプラグインを追加する。
その結果、保守が難しくなり、開発会社しか触れなくなる。
そうであれば、
「本当に残り20％までkintoneで作る必要があるのか」
を一度考えた方がよいケースもあります。
逆に、kintoneで十分実現できる業務を、わざわざゼロからスクラッチ開発する必要もありません。
大切なのは、kintoneを使うことでも、使わないことでもなく、
業務に対して適切な技術を選ぶこと
だと思います。
「ノーコードだから安心」ではなく、一つの業務システムとして考える
kintoneの価値の一つは、ノーコードで業務改善を始められることです。
これは間違いありません。
しかし、利用範囲が広がれば、
プラグイン
JavaScript
REST API
外部システム連携
などが増える可能性があります。
そうなったときには、
「ノーコードだから簡単なシステム」
という認識から、
「会社の重要な業務を支える一つの業務システム」
という認識へ切り替えた方がよいでしょう。
そして業務システムである以上、
設計
保守
運用
セキュリティ
担当者の引き継ぎ
将来の移行
まで考えておく必要があります。
システムキューブでも、kintoneを利用し、kintoneの開発やカスタマイズを行っています。
だからこそ、何でもkintoneへ作り込むのではなく、
標準機能でシンプルに使う部分、カスタマイズする部分、外部システムへ任せる部分を見極めること
が、kintoneを長く使い続けるために重要だと考えています。
「ノーコードだからどう作っても大丈夫」ではありません。
むしろ簡単に作れるツールだからこそ、
5年後、10年後にも分かりやすく保守できる状態になっているか。
そこまで考えてkintoneを活用することが、本当の意味での業務改善につながるのではないでしょうか。