Column業務・基幹システム
kintone運用の限界?8つのサインと3つの選択肢
Authorこの記事を書いた人

株式会社Riize Advisors 代表取締役
細倉 尚将
外資系コンサルティングファームにてM&A戦略・新規事業立案等に従事した後、株式会社Riize Advisorsを創業。コンサルタントとエンジニアのチームで、AI・システム開発を構想から実装・運用まで支援している。
「kintoneのアプリが増えて、どれが何をしているのか分からなくなってきました」「JavaScriptのカスタマイズを作った担当者が辞めてしまい、触るのが怖いです」「受注や在庫といった会社の中核の業務まで、このままkintoneで回してよいのか迷っています」。kintoneで業務を回してきた企業から、こうした声が聞かれます。この記事では、kintoneの運用が限界に来ているかを見分ける8つのサインと、kintoneのまま整理する・中核業務だけを切り出して併用する・全面的に移行する、の3つの選択肢の選び方、作り込みとともに増えるセキュリティ上の確認点をお伝えします。
kintoneで業務を回してきた会社が、次に考えること
kintoneの大きな強みは、現場の担当者が自分たちで業務のアプリを作れることです。サイボウズの「アプリ運用ルール策定ガイド 基本機能編」も、kintoneを「必要なアプリをマウス操作で作っていけるノーコードプラットフォーム」と位置づけ、業務で必要なシステムを業務担当者自身で作っていけることを特長に挙げています。Excelやメールで回していた業務を短い期間で共有のデータに置き換えられるのは、大きな価値です。
一方で、同じガイドは、kintoneを使う部門や業務が多くなると全体像が把握しづらくなり、各人が自由にアプリを作るとアプリの乱立などの問題が起きやすいとも述べています。数年使ううちに、アプリ、JavaScriptのカスタマイズ、プラグイン、外部サービスとの連携が少しずつ積み重なり、気付いたときには誰も全体を説明できなくなっている、ということが起こります。
ここで言う「限界」は、kintoneという製品の欠点ではありません。多くの場合は、作り込みの積み重ねによって管理が追いつかなくなった状態か、kintoneに向いている範囲を超えた業務までkintoneで支えようとしている状態です。前者ならkintoneのまま整理すれば解消でき、後者なら業務ごとに置き場所を考え直すことになります。kintoneを数年使ってきた企業のご相談では、困りごとの中心が製品そのものより、積み重なった作り込みを把握できていないことにある場合が多くあります。
公式の制限値と、性能についての注意
判断の前提として、公式の制限値も押さえておきます。kintone ヘルプの「制限値一覧」によると、主な値は次のとおりです。
| 項目 | 制限値(公式ヘルプの記載) |
|---|---|
| フィールド数 | 1つのアプリにつき500個まで |
| レコード数 | 上限なし |
| プラグイン | 1つのアプリにつき20個まで |
| JavaScript・CSSファイル | 1つのアプリにつき、PC用とスマートフォン用でそれぞれ30個まで |
| 同時アクセス数 | 1つのドメインにつき100まで |
| テーブル | 1つのテーブルにつき10フィールドかつ100行までが利用の目安 |
アプリ数と1日のAPIリクエスト数の上限は、契約しているコースによって異なります。レコード数については、アクセス権や絞り込みを設定していない1つのアプリに100万件を登録した状態で、問題なく使えることを確認していると書かれています。同じページには、表示やデータ処理の速度はアクセス権、絞り込み条件、フィールド数などの利用条件によって異なる、という注意もあります。
サイボウズの開発者向けサイトの「kintone大規模導入における技術的検討ポイント」も、保存できるレコード件数と実運用での操作性能は必ずしも一致しないとしています。アプリの設計、一覧の条件、フィールドの構成、カスタマイズ、アクセス権の内容、APIでのデータの取り方によって、応答の速さが変わることがあります。制限値に届いていなくても作り方次第で重くなり、反対に見直せば軽くなる余地もあるということです。
kintone運用が限界に来ているサイン8つ
次の8つのうち、自社に当てはまるものを確認してみてください。
| # | サイン | 起きていること |
|---|---|---|
| 1 | 一覧の表示や保存の遅さ | 以前より画面の表示や保存、一括の更新に時間がかかるようになった状態 |
| 2 | 中身の分からないカスタマイズ・プラグイン | 何のために入れたのか、誰も説明できないものが残っている状態 |
| 3 | 直せる人の不在 | 作った担当者や外注先にしか直せない、または作った人がもういない状態 |
| 4 | 似たアプリの乱立 | 部署ごとに同じような項目のアプリがあり、同じデータを何度も入力している状態 |
| 5 | 説明できないアクセス権 | 誰がどのアプリ・レコード・フィールドを見られるかを、一覧で示せない状態 |
| 6 | 把握しきれない外部連携 | APIトークンや連携サービスが増え、データがどこへ流れているか一覧にない状態 |
| 7 | 制限値や目安への接近 | プラグインやJavaScriptのファイル数、テーブルの大きさ、APIリクエスト数が目安に近づいている状態 |
| 8 | 中核業務の複雑なルールの作り込み | 見積の計算や在庫の引当てなど、会社の中核のルールをカスタマイズで無理に実現している状態 |
1〜3:作り込みが把握できていないサイン
1の動作の遅さは、最も気付きやすいサインです。ただし、遅さの原因はレコードの件数だけとは限りません。サイボウズの開発者向けサイトの「kintoneレコード操作の遅延を防ぐアクセス権設定」によると、kintoneはレコードを保存したときに、レコード数とアクセス権の設定数、アクセス権を持つユーザー・組織・グループの数に応じてアクセス権の事前評価を行います。この評価の量が増えると、一覧の表示が遅くなる可能性があるとされています。重さが気になるときは、まずアクセス権の設定やカスタマイズの処理の見直しから始めると、kintoneのままで改善できることがあります。
2と3は、多くの場合セットで起きます。サイボウズの「アプリ運用ルール策定ガイド 拡張機能編」(2021年11月時点のkintoneを基にした資料)は、拡張機能が運用保守しにくくなる主な原因として、度重なる機能追加で管理対象が増えること、機能だけを追加して導入の理由や経緯が分からなくなること、機能を追加したい人に管理権限を与えがちなこと、の3つを挙げています。作った担当者がいなくなった場合の引き継ぎの進め方は、システム担当者の退職・引き継ぎの進め方で詳しく説明しています。
4〜6:データと権限が見通せないサイン
4のアプリの乱立は、現場が自由にアプリを作れるkintoneだからこそ起きやすいサインです。顧客や商品の情報が複数のアプリに分かれると、どれが正しい値か分からなくなり、Excelで起きていた二重入力の問題がkintoneの上で再び起きます。Excelで同じ問題に向き合ったときの考え方は、Excel管理の限界サインとシステム化の判断でも取り上げています。
5と6は、セキュリティに直結するサインです。詳しくは後の章で説明します。
7〜8:kintoneに向いた範囲を超えつつあるサイン
7は、制限値に届いていなくても、一つのアプリに多くの処理を重ねているしるしです。用途ごとにアプリを分け直すだけで軽くなることもあります。
8は、判断に最も影響するサインです。kintoneは台帳や申請、案件の管理のように、現場の業務を早く形にする用途に強みがあります。一方、複数の工程にまたがって数量や金額の整合を取り続けるような処理を、JavaScriptで作り込んでいくと、変更のたびに影響範囲の確認が重くなります。これはパッケージやERPに追加開発を重ねた場合と同じ構造で、作り込みが次の改修の費用を押し上げる仕組みは基幹システムの追加開発費用が高くなる理由で説明しています。
すぐに移さなくてよい場合
サインがいくつか当てはまっても、すぐにkintoneから移る必要があるとは限りません。次のような場合は、まずkintoneのまま整理する方が向いています。
- 当てはまるサインが1〜6の範囲で、作り込みの棚卸しと整理で解消できそうな場合
- 動作の遅さが特定のアプリに限られ、アクセス権や一覧の条件の見直しで改善の余地がある場合
- 使っているアプリの多くが台帳・申請・案件管理など、kintoneが得意とする用途の場合
- 業務のやり方がまだ変わり続けていて、現場で素早く直せることの価値が大きい場合
業務が固まっていない段階で別のシステムを作ると、作った直後から業務と合わなくなりがちです。現場が自分で直せるというkintoneの強みは、こうした段階でこそ生きます。
反対に、8が当てはまり、kintoneが止まったり誤った値を返したりすると、受注や出荷、請求といった会社の中核の業務が止まる状態になっている場合は、置き場所を考え直す時期に来ています。
3つの選択肢と向き不向き
選択肢は大きく3つあります。全社で一つを選ぶのではなく、業務ごとに選ぶのが現実的です。
| 選択肢 | 向いている場合 | 注意すること |
|---|---|---|
| kintoneのままでの整理 | サインの多くが作り込みの把握不足から来ている場合 | 整理した状態を保つための管理の担当とルールが要ること |
| 中核業務だけの切り出しと併用 | 中核の業務だけがkintoneに向いた範囲を超えている場合 | 二つの仕組みの間でデータの正をどちらに置くかを決めること |
| 全面的な移行 | kintone上の業務の大半が一つの複雑な業務に組み込まれている場合 | 現場が自分で直せる強みを失うため、移す理由を数字で確かめること |
1. kintoneのままでの整理
最初に検討したいのが、kintoneのまま作り込みを整理することです。拡張機能編のガイドは、管理の体制をまず作ったうえで、機能追加・管理権限・要求と要件の3つをコントロールし、追加した機能の棚卸しを半年に1回行うことを勧めています。棚卸しで確認する観点として挙がっているのは、たとえば次のような点です。
- 用途の分からないプラグインや、使われていないプラグインが入っていないか
- カスタマイズを使っているアプリの数と、用途の分からないカスタマイズがないか
- 1日のAPIリクエスト数が多いアプリはどれか、用途の分からないリクエストが起きていないか
- kintoneとは別の連携サービスに、用途の分からない接続設定や使われていない設定が残っていないか
あわせて、アプリやカスタマイズの名前の付け方をそろえ、追加した理由と担当者を記録します。ガイドでも、機能追加の背景となった要求や要件を、アプリ管理者用メモなどに記録することが勧められています。使われていないアプリやプラグインは、データの保管が必要かを確かめたうえで止めるか廃止し、管理する対象そのものを減らします。
2. 中核業務だけの切り出しと併用
中核の業務だけがkintoneに向いた範囲を超えている場合は、その業務だけを別のシステムに切り出し、台帳や申請、日々の記録はkintoneに残す方法があります。サイボウズ自身も、技術的検討ポイントの記事で、kintone以外の環境に基幹システムやデータウェアハウスがある場合でも、kintoneへデータを移す必要はないとしています。kintoneとほかのシステムが役割を分けて並ぶのは、特別なことではありません。
切り出しを考えるときの線引きは、その業務が自社の強みにどれだけ関わっているかです。会計や勤怠のように、どの会社でもやり方が近い業務はSaaSでよく、現場の台帳や申請はkintoneのままで十分な場合が多くあります。見積の作り方、受発注の条件、在庫の引当てのルールなど、自社独自のやり方が取引先からの評価や利益につながっている業務だけを、必要な機能に絞ってスクラッチで作る、という分け方です。
この方法では、どちらのデータを正とするかと、データを渡す向きを先に決めます。たとえば、取引先や商品のマスタは切り出した側を正とし、kintoneは参照するだけにする、といった取り決めです。ここが曖昧なままだと、サイン4の二重入力が二つの仕組みの間で起きます。
また、今は生成AIを使った開発によって、必要な機能に絞ったシステムを以前より短い期間や少ない費用で作れる場合があります。作り込みを重ねるか切り出すかを比べるときの判断材料に入れておくとよいでしょう。
3. 全面的な移行
kintone上の業務の大半が一つの複雑な業務につながっていて、切り出すと残る部分がほとんどない場合は、全面的な移行も選択肢になります。ただし、全面移行では、現場が自分でアプリを直せるという強みも手放すことになります。移す理由が「重い」「複雑」といった印象だけでなく、改修にかかっている時間や費用、ミスや停止の影響として数字で説明できるかを確かめてから決めることをお勧めします。
業務を止めずに移すための計画の立て方や、データ移行の段取りは、基幹システムリプレイスの進め方で詳しく説明しています。
作り込みとともに増えるセキュリティ上の確認点
kintoneにはアクセス権の設定をはじめ、セキュリティのための機能が用意されています。注意したいのは、作り込みが増えるほど、それらの設定を正しく保つ手間も増えることです。見通しが悪くなりやすいのは次の4点です。
| 確認点 | 増えやすいリスク | 確認すること |
|---|---|---|
| アクセス権 | アプリごとに設定が増え、全体の見通しが悪くなること | 個人情報や金額を扱うアプリで、誰が何を見られるか |
| APIトークン | 作った人の手元に残り、広い操作を許したままになること | トークンごとの用途・担当者・許可している操作 |
| 退職者・異動者のアカウント | 使わなくなったアカウントや管理権限が残ること | 管理権限を持つ人と、退職・異動の際の手順 |
| プラグイン・外部連携 | データの通り道が増え、提供元の数も増えること | 接続している外部サービスの一覧と、それぞれの必要性 |
アクセス権の増加と見通しの悪さ
kintoneでは、アプリ、レコード、フィールドの単位でアクセス権を設定できます。細かく制御できる反面、アプリが増えるほど設定も増え、個々のアプリを開かないと誰が何を見られるかが分からなくなります。サイボウズの開発者向けサイトには、アクセス権の運用を効率化するためのアプリとカスタマイズとして、すべてのアプリのアクセス権の設定を一つの管理用アプリに集め、運用の方針に合わないアプリを見つける方法も紹介されています。まずは個人情報や取引の金額を扱うアプリから、設定を一覧にしてみることをお勧めします。
APIトークンの管理
外部のサービスや自作のプログラムとkintoneをつなぐときには、APIトークンを使うことが多くあります。kintone ヘルプの「APIトークンを生成する」によると、APIトークンはアプリごとに生成し、トークンごとに許可する操作を選びます。このとき、アプリのアクセス権、レコードのアクセス権、フィールドのアクセス権の設定に関わらず、APIトークンに設定したアクセス権が優先されます。同じページは、生成したトークンを第三者に知られないようにすることと、メモ欄に担当者や利用目的を書いておくと管理に役立つことも案内しています。
また、サイボウズの開発者向けサイトの認証の説明によると、APIトークンを使った操作は、Administratorによる操作として扱われます。トークンを作った担当者の手元にだけ控えがあり、どの連携で使っているかの記録が無いと、誰の何のための操作なのかを後から追いにくくなります。棚卸しの際には、トークンごとに用途と担当者、許可している操作が必要な範囲に収まっているかを確かめます。
退職者・異動者のアカウントと管理権限
基本機能編のガイドによると、kintoneには、cybozu.com共通管理者、kintoneシステム管理者、アプリ管理者、スペース管理者の大きく4種類の管理者がいます。最上位のcybozu.com共通管理者は、ユーザーの追加・編集・削除やセキュリティの設定を行います。作り込みが進むとアプリごとの管理者が増え、退職や異動の後も管理権限が残ることがあります。人の出入りがあったときのアカウントと管理権限の扱いを、手順として決めておくと安心です。
プラグインと外部連携が増えることの意味
プラグインや外部の連携サービスが一つ増えるごとに、kintoneのデータが通る道と、関わる提供元が一つ増えます。IPAの「情報セキュリティ10大脅威 2026」でも、組織向けの脅威の2位に「サプライチェーンや委託先を狙った攻撃」が挙げられています。個々のプラグインやサービスに問題があるということではなく、使う数が増えるほど、一つひとつの必要性と提供元の情報を確かめておく対象も増える、ということです。使っていない連携を止めることは、整理であると同時にセキュリティの対策にもなります。
判断の進め方
3つの選択肢のどれを選ぶにしても、次の順に進めると判断を誤りにくくなります。
| 段階 | 主な作業 | 次へ進む条件 |
|---|---|---|
| 1. 作り込みの棚卸し | アプリ、カスタマイズ、プラグイン、APIトークン、外部連携、アクセス権を一覧にします | 用途と担当者が分からないものが洗い出されていること |
| 2. 整理 | 使われていないものを止め、名前と記録をそろえます | 残すものの用途と担当者がすべて決まっていること |
| 3. 業務ごとの置き場所の判断 | 業務ごとに、kintoneに残すか、切り出すかを決めます | 切り出す業務と、その効果の数字が決まっていること |
| 4. 小さな範囲での切り出し | 一つの業務から切り出し、データの正と連携の向きを決めて動かします | 切り出した業務が、元に戻らずに回っていること |
棚卸しをせずに移行を決めると、何に使われているか分からないカスタマイズが、移行先の要件から抜け落ちることがあります。
3では、業務ごとに「手間×頻度×影響」で並べ、切り出す効果がコストの削減なのか、受注を増やす余力なのかを決めてから着手します。たとえば、医療卸の基幹システム刷新では、見積・受発注・請求がそれぞれ独立して管理され、同じ取引情報を複数の帳票やシステムへ重複して入力していました。業務を工程単位で棚卸しして単一のデータ基盤の上に組み直したことで、二重入力と転記ミスを解消しています。取り組みの概要は支援実績で紹介しています。
まとめ:kintoneの限界は「作り込み」と「業務の置き場所」で考える
- kintoneの限界の多くは製品の欠点ではなく、作り込みの積み重ねで管理が追いつかなくなった状態か、kintoneに向いた範囲を超えた業務まで支えようとしている状態です。
- 動作の遅さ、中身の分からないカスタマイズ、直せる人の不在、アプリの乱立、アクセス権、外部連携、制限値への接近、中核業務の作り込みの8つで、サインを確認できます。
- サインの多くが作り込みの把握不足から来ているなら、まずkintoneのまま棚卸しと整理を行います。サイボウズのガイドも、追加した機能の棚卸しを半年に1回行うことを勧めています。
- 中核の業務だけがkintoneに向いた範囲を超えているなら、その業務だけを切り出し、台帳や申請はkintoneに残す併用が現実的です。全面移行は、移す理由を数字で説明できるときに検討します。
- 作り込みが増えるほど、アクセス権、APIトークン、退職者のアカウント、外部連携の点検の手間も増えます。棚卸しの際に、セキュリティの観点もあわせて確認しておきます。
kintoneの作り込みの棚卸しから、中核業務だけを切り出すかどうかの判断、必要な機能に絞った開発まで、システム開発の支援でご相談いただけます。kintoneを使い続ける前提での整理のご相談も歓迎しています。
Related


