kintoneのデメリットと対策｜導入後に詰まらない業務設計

kintoneには、アプリを作りやすい、現場で変更しやすい、一覧やコメントで状況を追いやすい、という強みがあります。

一方で、その自由度がそのままデメリットにもなります。

アプリを増やせるから、似たアプリが増える。

項目を足せるから、誰も使わない項目が残る。

テーブルを使えるから、明細や履歴を1レコードに抱えすぎる。

権限を細かく設定できるから、誰が何を見られるのか説明しづらくなる。

プラグインや外部連携を入れられるから、保守責任が曖昧になる。

つまり、kintoneのデメリットは「kintoneが悪い」というより、業務設計を省略したときに表に出ることが多いです。

kintoneのデメリットは、機能の有無だけで判断するものではありません。どの業務データをkintoneの正本にし、どこから外へ任せるかを決めたときに、初めて大きさが見えます。

この記事では、kintoneのデメリットを、アプリ乱立、テーブル設計、権限、通知、承認、連携、プラグイン、保守属人化、大量データの観点で整理します。

あわせて、導入前に決めるべき業務設計と運用ルールまで落とし込みます。

kintoneでできること・できないことの判断基準はこちら
kintoneアプリ作成の設計方法はこちら
kintoneデータベースの設計方法はこちら
kintoneテーブルの設計方法はこちら
kintoneワークフローでできないことの整理はこちら
kintoneセキュリティ設計はこちら
kintone API連携の設計方法はこちら

先に結論：デメリットは「作る前の境界決め」で小さくできる

kintoneのデメリットは、導入をやめる理由として見るより、設計で先に潰す論点として見る方が実務的です。

よく問題になるのは、次のような場面です。

デメリット	問題が出やすい条件	導入前の対策
アプリが乱立する	部署ごとに似たアプリを作る	受付、管理、履歴、マスタの役割を先に分ける
データが分散する	顧客、案件、商品を複数アプリに重複登録する	正本アプリと参照用アプリを決める
テーブルが重くなる	明細、履歴、コメント、状態を1レコードに抱える	明細アプリ化する条件を決める
権限が複雑になる	部署、役職、担当、状態、金額条件を重ねる	権限表とアプリ分割をセットで作る
通知が多すぎる	登録、更新、コメント、期限を全部通知する	通知を「次に動く人」だけに絞る
承認が硬くなる	全社ルールを1アプリで再現する	kintoneで持つ申請データと外部承認の境界を決める
プラグイン依存が強くなる	足りない機能を都度追加する	標準、プラグイン、連携、外部システムに分ける
保守が属人化する	作成者の判断で項目や設定を増やす	作成申請、変更管理、棚卸しを運用に入れる

この表のうち、1つか2つだけなら運用で吸収できることもあります。

しかし、アプリ乱立、複雑な権限、プラグイン依存、連携の不安定さが同時に起きると、後から直すのが難しくなります。

特に危ないのは、導入時に「とりあえず作ってから考える」で始めたアプリが、数か月後に正式な業務システムのように扱われるケースです。

一時的な試作と、本番で使う業務アプリでは、決めるべきことが違います。

区分	試作なら許容できること	本番前に決めること
アプリ	1部署だけで使う	業務全体のどこを担当するか
項目	後から足す	必須項目、更新者、変更してよい項目
権限	管理者だけで調整する	アプリ、レコード、フィールドの権限表
通知	多めに出す	誰が次に動く通知か
連携	手動CSVで確認する	正本、更新方向、失敗時対応
保守	作成者が直す	変更申請、棚卸し、引き継ぎ手順

kintoneは小さく作れることが強みです。ただし、本番で使うなら「小さく作る」と「設計せずに作る」は分けて考える必要があります。

デメリット1：アプリ乱立でデータが分散する

kintoneはアプリを作りやすいので、部署ごとに似たアプリが増えやすいです。

営業が案件管理アプリを作る。

管理部が契約管理アプリを作る。

サポートが問い合わせ管理アプリを作る。

最初は自然です。

しかし、顧客名、担当者、契約状態、請求予定、対応履歴がそれぞれのアプリに散らばると、どれが正しい情報なのか分からなくなります。

問題は、アプリ数そのものではありません。

同じ意味のデータが、複数の場所で別々に更新されることです。

乱立の形	起きる問題	対策
顧客アプリが複数ある	社名、担当者、連絡先が食い違う	顧客マスタを1つに寄せる
案件アプリが部署ごとにある	案件状態を横断して見られない	部署差分は区分や関連アプリで表す
履歴を各アプリに書く	対応履歴が分断される	履歴アプリを分け、関連レコードで見る
申請ごとに別アプリを作る	承認待ちが散らばる	申請種別で分ける範囲を決める
個人用アプリが残る	本番データか試作か分からない	作成申請と廃止ルールを置く

アプリ乱立を防ぐには、すべてを1つのアプリにまとめるのではなく、アプリの役割を決めます。

代表的には、次の4種類に分けます。

アプリの役割	例	設計で見ること
受付アプリ	問い合わせ、申込、依頼	入口の項目を少なくする
管理アプリ	案件、契約、作業	状態、担当者、期限を持つ
履歴アプリ	対応履歴、作業履歴、変更履歴	1回の行動を1レコードにする
マスタアプリ	顧客、商品、担当者、部署	重複登録を避ける

たとえば、問い合わせ管理なら、問い合わせ受付、顧客マスタ、案件管理、対応履歴を分けます。

受付アプリにすべてを持たせると、対応履歴が増えたときに苦しくなります。

反対に、最初から細かく分けすぎると、入力者が画面を行き来する負担が増えます。

このバランスは、kintone問い合わせ管理の設計方法やkintone顧客管理の設計方法ともつながります。

デメリット2：Excelをそのまま移すとテーブルや項目が肥大化する

kintone導入で多い失敗は、Excelの表をそのままアプリにすることです。

Excelでは、横に長い表、月別の列、担当者別の列、色分け、備考欄、メモ欄が混ざっていることがあります。

それをそのままkintoneに移すと、次のような状態になります。

• フィールドが増えすぎる
• 1レコードの意味が曖昧になる
• 月別列が増え続ける
• テーブル内の行が増えすぎる
• 一覧に表示する項目が多すぎる
• どの項目を更新すべきか分からない
• 集計や外部連携で扱いづらい

サイボウズの制限値一覧では、1アプリのフィールド数や一覧数、テーブル利用時の目安、CSVやExcel読み込みの条件などが示されています。

kintoneヘルプ：制限値一覧

ここで重要なのは、数値の上限だけではありません。

フィールドやテーブル行が多いほど、画面、一覧、検索、CSV、API、帳票、プラグインのすべてに影響が出るということです。

Excel的な作り方	kintoneで起きる問題	設計対策
1月、2月、3月のように列を増やす	年が変わるたびに項目追加が必要	月次データを別レコードにする
担当A、担当B、担当Cを列にする	担当者変更に弱い	担当者をユーザー選択や履歴で持つ
備考欄に履歴を書く	いつ誰が何をしたか追えない	履歴アプリを作る
明細を大きなテーブルに入れる	明細単位の検索や状態管理が難しい	明細アプリに分ける
表示用の空白列を作る	フィールド数が増える	フォーム配置と一覧で見せ方を分ける

kintoneでは、1レコードが何を表すのかを先に決めます。

顧客1件なのか。

案件1件なのか。

申請1件なのか。

作業1件なのか。

明細1行なのか。

この定義が曖昧なまま項目を増やすと、後から修正しづらくなります。

特にテーブルは注意が必要です。

テーブルは、見積明細や点検項目のように、親レコードに従属する少量の明細には向きます。

しかし、明細ごとに担当者、期限、状態、権限、外部連携が必要なら、別アプリ化を考えます。

詳しくは、kintoneテーブルの設計方法とkintone関連レコードの設計方法で整理しています。

デメリット3：権限・通知・承認が複雑になる

kintoneでは、アプリ、レコード、フィールドの単位でアクセス権を設定できます。

公式ヘルプでも、kintoneのアクセス権はこの3つのレベルで設定できると説明されています。

kintoneヘルプ：アクセス権の設定

これは強い機能です。

ただし、権限を細かく設定できることと、複雑な権限設計を安全に運用できることは別です。

次のような条件が重なると、設定が急に難しくなります。

• 部署ごとに閲覧範囲が違う
• 役職ごとに編集できる項目が違う
• 担当者だけが自分のレコードを見られる
• ステータスごとに編集可否が変わる
• 金額によって承認者が変わる
• 個人情報や添付ファイルの閲覧制限が必要
• 外部メンバーやゲストユーザーが関わる

このとき、全部を1つのアプリの権限設定で吸収しようとすると、誰が何をできるかを説明しづらくなります。

複雑化する要因	権限だけで抱えた場合	対策
部署別の閲覧	条件が増え続ける	部署共通アプリと部署別アプリを分ける
担当者別の編集	担当変更時に設定が崩れる	担当者フィールドと運用手順を決める
承認後の編集制御	例外修正が難しい	固定する項目と修正申請を分ける
添付ファイルの制御	レコード閲覧とファイル閲覧が絡む	添付を分離するアプリも検討する
ゲスト利用	内部情報の露出が怖い	ゲスト用アプリや公開範囲を分ける

通知も同じです。

登録通知、更新通知、コメント通知、期限通知、リマインダーをすべて出すと、利用者は通知を見なくなります。

通知は「知ってほしい人」ではなく、「次に動く人」に絞ります。

承認も同じです。

単純な申請、承認、差し戻しならkintoneのプロセス管理で始めやすいです。

しかし、組織階層、代理承認、金額別ルート、議決、全社横断の承認待ち管理が絡むと、標準機能だけで作り込むほど重くなります。

この論点は、kintoneワークフローの設計方法とkintoneワークフローでできないことで詳しく整理しています。

権限や通知は、細かく設定するほどよいわけではありません。利用者が「自分は何を見て、何を更新し、次に誰へ渡すのか」を説明できる粒度に抑えることが重要です。

デメリット4：プラグインや外部連携に依存しやすい

kintoneは標準機能だけでも多くの業務に対応できます。

ただし、帳票、フォーム連携、集計、入力補助、バックアップ、外部システム連携まで進むと、プラグインや連携サービスを使う場面が増えます。

プラグインや連携サービスは悪いものではありません。

むしろ、標準機能だけで無理に作り込むより、適切な製品を使った方が安定することもあります。

問題は、足りない機能が出るたびに追加し、全体の責任者がいなくなることです。

追加しがちなもの	便利な点	決めないと困ること
帳票プラグイン	見積書、請求書、報告書を出せる	出力してよい状態、再発行、控え保存
フォーム連携	外部から申込や問い合わせを受けられる	重複、本人確認、迷惑投稿、受付後の担当
集計プラグイン	標準グラフで足りない集計を補える	集計元、再計算、月次確定
入力補助	入力漏れや条件表示を補える	カスタマイズ更新、モバイル対応
バックアップ	事故時の復元に備えられる	復元手順、保存期間、添付ファイル
外部連携	会計、CRM、チャットとつなげる	正本、更新方向、失敗時の再実行

連携では、kintoneのREST APIの仕様も確認が必要です。

cybozu developer networkでは、kintone REST APIの同時接続数や1日に実行できるリクエスト数、レコード操作APIの制限などが公開されています。

cybozu developer network：kintone REST APIの共通仕様

APIがあるからつなげる、という判断では足りません。

次の点を決めてから連携します。

設計項目	決めること
正本	kintoneと外部システムのどちらが正しい値を持つか
更新方向	片方向か、双方向か、手動確認を挟むか
更新キー	顧客ID、案件ID、請求番号など何で紐づけるか
更新タイミング	即時、定期、承認後、締め後のどれか
エラー対応	失敗通知、再実行、手動修正、二重登録防止
監査	誰がいつ連携を実行し、何が変わったか

プラグインや外部連携は、足りない機能を埋める道具です。導入前に、正本、更新方向、失敗時対応、保守責任を決めないと、便利さより管理負担が大きくなります。

関連する設計は、kintone連携サービス選定の設計方法、kintone外部連携の設計方法、kintoneバックアップの設計方法も参考になります。

デメリット5：大量データや基幹処理を抱えると重くなる

kintoneは、現場で更新しながら確認する業務台帳に向いています。

一方で、大量データを高速に横断処理する基盤や、厳密な基幹処理をすべて担う前提で使うと苦しくなります。

たとえば、次のような業務です。

• 数年分の明細を横断して高速に集計する
• 在庫引当やロット管理を厳密に行う
• 会計仕訳や入金消込を正式な正本として持つ
• 給与計算や社会保険料計算を行う
• ECや基幹システムと常時双方向に同期する
• 多数の添付ファイルを文書管理の中心にする

このような業務では、kintoneに全部を持たせるより、専門システムと分担します。

業務	kintoneに持たせやすいもの	外へ任せたいもの
会計	請求前確認、承認状態、差し戻し理由	仕訳、入金消込、決算帳票
在庫	棚卸し依頼、現場確認、例外メモ	引当、ロット、原価、在庫評価
販売管理	見積前確認、受注前タスク	売上計上、締め処理、請求正本
人事労務	申請受付、提出状況、確認メモ	給与計算、年末調整、法定帳票
文書管理	契約書の確認状態、担当、期限	ファイル版管理、全文検索、長期保管

大事なのは、kintoneを使わない判断ではありません。

kintoneを、現場の入力、確認、例外処理、承認前後の管理に使う。

専門システムを、正式な計算、締め、会計、保管に使う。

この分担ができていると、kintoneはむしろ使いやすくなります。

逆に、会計ソフト、販売管理、文書管理、承認基盤をすべてkintoneで置き換えようとすると、標準機能、プラグイン、JavaScript、外部連携が積み上がり、保守が重くなります。

kintoneレコード数上限の設計方法やkintone帳票出力の設計方法も、導入前に確認しておくと判断しやすくなります。

デメリット6：保守が属人化しやすい

kintoneは、現場担当者でもアプリを作りやすい道具です。

これは大きな利点です。

ただし、作成者しか分からないアプリが増えると、異動、退職、部署変更、業務変更のたびに困ります。

属人化は、コードを書いたときだけ起きるものではありません。

標準機能だけで作ったアプリでも、次のような情報が残っていなければ属人化します。

残すべき情報	残っていないと起きること
アプリの目的	何のためのアプリか分からない
1レコードの定義	顧客、案件、履歴、申請が混ざる
関連アプリ	どのマスタや履歴とつながるか分からない
権限表	誰が見られるか確認できない
プラグイン一覧	更新や契約切れの影響が分からない
連携一覧	どこからデータが来て、どこへ渡るか分からない
変更履歴	なぜ項目が追加されたか分からない
棚卸し日	使われているか分からない

属人化を避けるには、設計書を厚く作るより、最低限の運用メモを残す方が続きます。

たとえば、次のようなシンプルな管理で十分です。

管理項目	内容
アプリ責任者	業務上の責任者と設定変更の担当者
作成目的	何の業務を扱うか、扱わないか
正本データ	顧客、案件、明細、履歴のどれを正本にするか
関連アプリ	ルックアップ、関連レコード、アプリアクション
権限方針	閲覧、編集、削除、管理者
通知方針	誰に、いつ、なぜ通知するか
連携方針	外部システム、更新方向、失敗時対応
棚卸し	最終確認日、廃止候補、改善候補

これをアプリごとに残すだけでも、保守の難易度は大きく下がります。

導入前に決めるべき運用ルール

kintoneのデメリットを抑えるには、機能選定だけでなく運用ルールが必要です。

ただし、重い統制にすると現場が使わなくなります。

最初に決めるなら、次の5つで十分です。

ルール	決めること
アプリ作成ルール	誰が、どんな目的で、どこに作ってよいか
項目追加ルール	項目追加の理由、入力者、利用する一覧や帳票
権限変更ルール	変更依頼者、承認者、影響範囲
プラグイン追加ルール	目的、費用、更新責任、代替案
棚卸しルール	未使用アプリ、重複アプリ、重い一覧、古い通知

特に、アプリ作成ルールは重要です。

アプリを作る前に、次の問いに答えます。

問い	確認する理由
このアプリの1レコードは何か	データの粒度を決めるため
既存アプリで代替できないか	乱立を防ぐため
正本はどこか	二重管理を防ぐため
誰が登録するか	入力責任を決めるため
誰が確認するか	通知と一覧を決めるため
どの状態で完了か	ステータスを決めるため
何と連携するか	更新キーと失敗時対応を決めるため
誰が保守するか	属人化を避けるため

これらを決めずに作ったアプリは、最初は便利でも、半年後に修正しづらくなります。

反対に、最初にこの程度を決めておけば、アプリを小さく作って始めても、後で育てやすくなります。

よくある失敗と対策

kintone導入でよくある失敗を、対策とセットで整理します。

失敗	原因	対策
似たアプリが増える	作成前の確認がない	作成申請とマスタ確認を入れる
項目が増えすぎる	入力後に誰が使うか決めていない	項目ごとに利用画面を決める
一覧が多すぎる	利用者ごとに場当たりで作る	標準一覧、自分用一覧、管理用一覧を分ける
通知が読まれない	全員に通知している	次に動く人だけに出す
権限設定が怖くて触れない	設定理由が残っていない	権限表と変更履歴を残す
プラグインが増え続ける	標準でできる範囲を見ていない	追加前に標準、運用、外部委譲を比較する
外部連携で二重登録が起きる	更新キーが曖昧	一意キーと重複時の処理を決める
アプリ作成者しか直せない	設計メモがない	目的、責任者、連携、権限を残す

ここでの対策は、特別なものではありません。

むしろ地味です。

アプリを増やす前に、既存アプリを見る。

項目を増やす前に、その項目を使う一覧や帳票を見る。

通知を出す前に、通知を受けた人の次の行動を見る。

プラグインを入れる前に、標準機能、運用、外部システムとの分担を見る。

外部連携を作る前に、正本と更新方向を見る。

この順番を守るだけで、多くのデメリットは小さくできます。

Bitlightに相談できること

Bitlightでは、kintoneのデメリットを単なる弱点一覧としてではなく、導入前に決める業務設計項目として整理します。

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

• 既存アプリ、Excel、紙帳票、外部システムの棚卸し
• アプリ乱立を防ぐための受付、管理、履歴、マスタ分割
• テーブル肥大を避けるための明細アプリ、履歴アプリ設計
• アプリ、レコード、フィールド単位の権限表作成
• 通知、プロセス管理、承認後修正の運用ルール設計
• プラグイン、JavaScript、API連携の採用判断
• アプリ作成申請、棚卸し、変更管理、引き継ぎメモの整備

kintoneのデメリットは、作ってから気づくと直す範囲が広くなります。

導入前に、正本、アプリ分割、権限、通知、連携、保守責任を決めておけば、作りやすさを活かしながら運用の重さを抑えられます。

まとめ：kintoneのデメリットは、導入前の設計項目です

kintoneにはデメリットがあります。

アプリが増えやすい。

権限が複雑になりやすい。

テーブルや項目が肥大化しやすい。

プラグインや外部連携に依存しやすい。

大量データや厳密な基幹処理には向かない場面がある。

保守が属人化しやすい。

ただし、これらは導入を避ける理由とは限りません。

むしろ、導入前に設計すべき項目です。

どの業務データをkintoneの正本にするか。

どのアプリに分けるか。

どこから外部システムに任せるか。

誰が見て、誰が更新し、誰が保守するか。

どの通知で次の行動が起きるか。

どのプラグインや連携を、誰が管理するか。

ここまで決めておけば、kintoneは現場に近い業務台帳として使いやすくなります。

逆に、この設計を飛ばすと、作りやすさがそのまま運用の重さになります。

導入前にデメリットを知ることは、不安材料を増やすためではありません。

後から詰まらない形で、kintoneに任せる範囲を決めるためです。