kintoneの資料を取り寄せると、できることばかりが書いてあります。経営者や上司を説得しようにも、公式情報だけでは「実際のところどうなのか」が見えにくい。
「高額な投資をして後悔するかもしれない」——その不安を持ちながら検索した方のために、サイボウズ公式のSIGNPOST・開発者ドキュメント・実際の構築現場から見えてくる制約を、できるだけ率直に整理します。読み終わるころには、「自社にkintoneが合うかどうか」を自分で判断し、上司や経営者にロジックで説明できる状態になるはずです。
kintoneのデメリット——5つの制約を率直に整理する
デメリット1：コスト構造——最低10ユーザー縛りとAI制限
kintoneはユーザー数による課金モデルです。最低10ユーザーからの契約が必要で、2026年8月時点の料金は次のとおりです（出典：kintone料金ページ）。
| プラン | 月額（税抜/ユーザー） | 最低ユーザー数 | kintone AI |
|---|---|---|---|
| ライト | 1,000円 | 10名 | 利用不可 |
| スタンダード | 1,800円 | 10名 | 500クレジット/ユーザー |
| ワイド | 3,000円 | 1,000名 | 1,000クレジット/ユーザー |
出典: kintone料金プラン（公式）（https://kintone.cybozu.co.jp/price/）
実際に使うのが3名でも、月額1万円（ライト・税抜）〜1万8,000円（スタンダード・税抜）が最低ラインです。協力会社や現場スタッフをゲストユーザーとして追加する場合、スタンダードなら月1,440円/ゲスト（税抜）が加わります。
見落とされやすいのがAI機能の制限です。日報の自動要約や記録の整理など、AI機能を活用したい場合はライトコースでは一切利用できません。スタンダード以上が必要です。プラン選定の段階でAI活用の有無を決めておかないと、後から乗り換えコストが発生します。
プランの詳細な機能差については、ライトとスタンダードの違いを比較した記事で整理しています。
デメリット2：使いこなすまでの学習コスト
kintoneは「ノーコードで動く」のは事実ですが、「誰でもすぐ使いこなせる」とは言い切れません。
アプリ設計・プロセス管理の設定・複数アプリのデータ連携（ルックアップ・関連レコード一覧）には、「kintoneの考え方」を理解するための時間がかかります。フォームはドラッグ＆ドロップで作れますが、フィールドの種類・関連レコードの設定・アクセス権の組み合わせは、慣れるまで直感的でない部分があります。
業務改善の専任担当がいる場合は習得を見込みやすいです。しかし、総務・経理・情シスを兼任している担当者が「空き時間で覚える」状況では、「3ヶ月で動かす予定が半年かかった」という事態が起きやすいです。
学習コストを下げる現実的な方法は「最初のアプリ設計を経験者と一緒に行う」ことです。設計の方向性が最初からずれると、後から直す工数の方が最初の学習コストより大きくなるケースがあります。kintoneが社内で活用されなくなる原因として学習コストが挙がるパターンについては、使われなくなる原因と対処法でも整理しています。
デメリット3：カスタマイズは深くやるほど自分を苦しめる
kintoneの強みは「設定の変更で容易にメンテナンスできる」点にあります。しかし、JavaScriptカスタマイズを重ねると、このメリットが失われます。
サイボウズ公式（SIGNPOST 1-06）には「過度なカスタマイズ開発により設定の変更で容易にメンテナンスできるというkintoneのメリットが薄れてしまう」と明示されています。また、SIGNPOST 3-29では「UI/UXの大幅なカスタマイズはkintoneのアップデートの影響を受け、アップデート後に想定通りの動きをしなくなる可能性がある」とも記載されています。
カスタマイズを重ねたシステムに特有のリスクが、担当者の離職です。複雑なJSカスタマイズは属人化しやすく、担当者が辞めると保守が事実上困難になります（出典：kintoneの歩き方 カスタマイズQ&A）。サイボウズ公式も、プラグインや連携サービスを優先して使うことを推奨しています。
外注でkintoneを構築した後、「担当者が退職して誰もメンテナンスできない」という状態は実際に起きやすいパターンです。kintone開発を外注する前のチェックリストでも、「保守体制の確認」を最初に行う理由として触れています。
デメリット4：帳票・印刷機能の標準はシンプルすぎる
kintoneの標準帳票機能は、業務帳票の複雑な要求には対応していません（出典：kintoneの歩き方 帳票印刷）。
プラグインなしでは対応が難しい代表的なケースです。
- ExcelやWord形式でのフォーマット出力
- 複数レコードをまとめた一括帳票処理（請求書を100件一度に出力など）
- 細かいレイアウト指定が必要な見積書・請求書
- Excelマクロ対応の出力・大量一括処理
「プリントクリエイター」「OPROARTS」などの有料プラグインで対応できますが、プラグインの月額費用はkintoneの基本料金に加算されます。「想定より費用が膨らんだ」という声の原因として、この帳票プラグイン費用が挙がることがよくあります。
「kintoneの月額費用しか見積もっていなかった」「プラグイン費用が後から積み上がった」という状況を防ぐには、導入前に帳票要件を具体的に整理しておくことが重要です。どのプラグインが必要か・費用はいくらになるかは、無料相談で一緒に試算できます。
デメリット5：大量データ・高頻度処理には性能の壁がある
kintoneには、大量データや外部連携を扱うときに押さえておくべき公式の性能目安があります（出典：SIGNPOST 性能・cybozu.dev）。
| 制約 | 公式の目安 |
|---|---|
| 1アプリのフィールド数 | 最大500。100フィールド超で表示遅延リスク |
| レコード数 | 最大約100万件。複雑な絞り込み・アクセス権がある場合は数万件レベルでも性能低下の可能性 |
| API同時接続数 | ドメイン全体で100件。101件目以降はエラー（全アプリに影響） |
| レコード取得APIのoffset | 上限10,000件。超えるとカーソルAPIが必要 |
| 1日あたりAPIリクエスト数 | 上限あり（数値は非公開）。超過でメール通知、場合によりAPI処理中断 |
見落とされやすいのがAPI同時接続数の範囲です。「1つのアプリだけでなく、ドメイン全体」が対象になります。複数の外部システムを同時に連携させると、思わぬタイミングで全アプリのAPIが詰まるリスクがあります。連携設計の妥当性を事前に確認したい場合は、無料相談で実際の構成を一緒に確認できます。
kintoneが向いていないケースの実態
「向いていない」は「kintoneが悪い」という意味ではありません。工具と同じで、ツールの性質と業務の要件が合っているかどうかがすべてです。
向いていないケース1：本格的な在庫管理（複数人同時更新）
複数人がリアルタイムで在庫数を更新する業務では、kintoneの構造上の制約があります。複数人がほぼ同時に同一レコードを更新すると、最初に完了した1人だけが成功し、他のユーザーには再入力を求める競合エラーが発生します（出典：cybozu.dev 在庫管理の活用と注意点）。
判断の分岐点は「商品点数×更新頻度×同時ユーザー数」の三重確認です。少品種・1日数回・実質1名担当であれば運用の余地はあります。多品種・高頻度・複数スタッフが同時に入出庫を記録する業務では、競合エラーが日常的に発生します。
さらに在庫引当・在庫評価などの機能実装には複数アプリをまたぐ複雑な集計が必要となり、カスタマイズコストがパッケージ型の専用システムと同等になる可能性があると、cybozu.devでも公式に言及されています。
向いていないケース2：議決承認・承認スキップが必要な稟議フロー
標準のプロセス管理では、次の2つは実現できません（出典：SIGNPOST 3-25）。
- 議決承認：複数の承認者が同時に承認する形式（全員合意型・委員会型）
- 承認スキップ：申請者と承認者が同一ユーザーの場合の自動スキップ
稟議・設備申請・購買フローでこれらが必要な業務は、最初からJSカスタマイズまたは専用ワークフローツールとの連携を前提にした見積もりが必要です。
上の画面はkintoneで構築した稟議管理アプリの入力フォームです。ステータスの遷移・承認者・コメントの記録はこのような形で管理できます。ただし「全員合意の承認」や「同一人物が連続承認者になる場合のスキップ」は、追加の設計・カスタマイズが前提になります。承認フローの要件が複雑な場合は、設計の段階で相談いただくことをお勧めします。
向いていないケース3：Excel/Word形式での帳票出力が業務の中心
既存のExcelフォーマットを維持しながらデータだけkintoneで管理したい場合は、プラグインや連携ツールで対応できる場面もあります。しかし、帳票の作成・出力がメインの業務フローにkintoneを中心に据えると、プラグイン費用と設定の複雑さが積み上がりやすくなります。
向いていないケース4：大量・高頻度の外部API連携
受発注の自動処理や複数システムからのリアルタイムデータ連携のように、「大量のデータを高頻度でAPIからやり取りする」設計は、前述のAPI制約（同時100件・1日の上限あり）と衝突しやすい構成です。初期は問題なく動いても、利用量が増えた段階で詰まりが生じるリスクがあります。
向いていないケース5：数十万件以上の大規模データベース
kintoneは「ローコードの業務アプリ」として設計されており、本格的なデータウェアハウスや大規模DBの代替ではありません。フィールド数が100を超えるアプリ設計や、数万件以上の複雑な集計が常時必要な業務では、専用DBやBIツールとの組み合わせを検討する方が現実的です。
デメリットを最小化する導入・設計の考え方
デメリットを理解した上で、それを最小化するアプローチは明確にあります。
① 「1業務・1アプリ」のスモールスタート
「全部一気に作る」アプローチは、最初の設計ミスが全体に波及します。まず1つの業務（日報・案件管理・点検記録など）に絞り、2〜3ヶ月使って現場の使い方を確認してから拡張するのが、定着率の高い進め方です。
スモールスタートで大切なのは「最初のアプリの設計精度」です。どのフィールドを作るか・どの業務フローを対象にするかが最初にずれると、後から直す工数の方が大きくなります。最初の設計を一緒に確認したい場合は、無料相談で実際の画面を見ながら整理できます。
② 「kintoneでやること」と「やらないこと」のスコープ管理
kintoneでできることが増えるほど、「これもkintoneで」という範囲の拡大（スコープクリープ）が起きやすくなります。「在庫は専用システムに任せる」「帳票出力はプラグイン対応」のように、kintoneが担当する範囲を最初に決めておくことが重要です。
外注で構築を依頼する際にスコープが曖昧なまま進むと、追加要望が続いてコストが当初見積もりの2〜3倍になるケースは珍しくありません。発注前のスコープ整理については、kintone開発を外注する前のチェックリストも参考にしてください。
③ カスタマイズの深さに「上限」を設ける
カスタマイズが必要な場面では「プラグインで対応できるか」を先に確認し、JSカスタマイズは最終手段とする設計方針を持つことが重要です。「このカスタマイズを誰が保守するか」を設計の時点で決めておくことも、運用フェーズの安心につながります。
他ツールとの比較軸——デメリットを知った上で選ぶ
他社名ではなく「業務の性質」で判断できる軸を整理します。
kintoneが向いている業務
- 「記録の集まり」として整理できる業務（日報・案件管理・点検記録・設備台帳）
- 承認やプロセスの流れを自動化したい業務（稟議・設備申請・休暇申請）
- 複数部署が同じデータをそれぞれの角度から参照したい場面
- まず動くものを現場に見せてフィードバックを受けながら作り込みたい場面
kintoneでなくてもよい場面
- ExcelやGoogleスプレッドシートで十分な業務（単純な記録・共有のみ）
- 在庫数をリアルタイムかつ高精度で扱う業務
- 既存のパッケージシステムで要件の80%以上を満たせる業務
- 実際に使うのが3名以下で、10ユーザー分の固定費が割に合わない規模感
この仕分けが一人では難しい場合は、「主要業務をリストアップして、それぞれkintoneとの相性を確認する」作業が有効です。無料相談では業務リストを持参いただければ、30〜60分で一緒に整理できます。
pullieの立ち位置——「kintoneが合うか」を一緒に判断する入口として
この記事で触れたデメリットのほとんどは「kintoneが悪い」のではなく、「設計の判断」の問題です。スコープを正しく決め、カスタマイズの深さを見極め、向いていない業務を別の手段で補えば、kintoneはコストパフォーマンスの高い選択肢になります。
問題は、その判断を誰と一緒にするか、です。
pullieは、サイボウズの認定パートナーではありません。
認定制度はkintoneの技術力を証明する外形的な基準として有効ですが、認定が証明するのは「kintone技術の習熟度」であり、発注側の業務（日報・承認・原価管理…）への実務理解は別の軸です。技術的には正しく動くシステムが「現場の言葉でできていない」「業務フローと合っていない」という理由で使われなくなるケースは珍しくありません。kintoneが使われなくなる原因と対処法でも、定着しない案件に共通するパターンが整理されています。
pullieは、建設・不動産の現場実務（施工管理・不動産仲介）の経験を持つエンジニアが対応します。 業務の言葉のまま要件を聞き、kintoneの仕組みに翻訳し、現場と直接やり取りしながら小さく始めて定着まで伴走します。
上は建設業向けに実際に構築した案件・工事管理アプリの一覧画面です。「施工中」「請求済」のステータス管理・粗利の自動計算・担当者・完工予定の一元管理を、現場で使う語彙のままアプリに落とし込んでいます。認定の有無ではなく「自社業務の言葉が画面に出てくるか」を、無料相談で実際に確認いただけます。
大規模・多拠点・組織体制重視の案件では、認定パートナー企業の組織力が向く場面もあります。どちらが合うかは規模と優先事項によるため、複数の選択肢を比較した上で決めることをお勧めします。比較の観点についてはkintoneパートナー選定のポイントも参考にしてください。
まとめ：デメリットを知った上でkintoneを選ぶ
kintoneのデメリット5つを整理しました。
| # | デメリット | 要点 |
|---|---|---|
| 1 | コスト構造 | 最低10ユーザー固定費。ライトはAI利用不可 |
| 2 | 学習コスト | 兼任担当者には使いこなすまで時間がかかる |
| 3 | カスタマイズの限界 | 深くやるほど保守リスクとアップデート影響が増える |
| 4 | 帳票機能の制約 | 複雑な帳票・Excel出力にはプラグイン費用が必要 |
| 5 | 性能の壁 | フィールド100超・大量API・高頻度更新は設計の工夫が必須 |
これらを踏まえると、「kintoneは万能ではないが、中小企業の業務改善ツールとして費用対効果の高い選択肢」という位置づけが実態に近いと思います。向いていない業務が多い場合はkintoneを選ばない判断も正解です。向いている業務の比率が高い場合は、スモールスタートで始めて拡張していく進め方が現実的です。
「自社にkintoneが合うかどうか」の判断が一人では難しい場合は、無料相談で一緒に整理できます。スコープの確認・実際の構築デモ・他ツールとの比較まで含めて、1時間程度で方向感を出せます。
