「kintone の月額料金だけでは済まなくなってきた」「JavaScript カスタマイズの保守費が毎年上がっている」「アプリが 30 個を超えて、どれが業務の中心か分からなくなった」。kintone を導入して 3 〜 5 年経った中小企業の情シスや総務から、この 1 〜 2 年で相談が増えています。kintone は「最初の 1 歩」としてはスピードと安さで有利ですが、業務が乗ってくるとどこかで「このまま拡張し続けるか、自社スクラッチに切り替えるか、組み合わせるか」の判断が必要になります。本記事は、その判断材料として、kintone の開発費用の実態と、自社スクラッチとの比較軸を、AI 駆動開発のクリエイティブスタジオが実例ベースで整理した実務ガイドです。
結論: kintone は「早い入り口」で、ある規模で分岐点が来る
先に結論を書きます。kintone は月額料金の見た目は安く、初期の導入スピードも速いため、業務システム化の第一歩としては優れた選択肢です。しかし、業務が乗って規模が拡大すると、月額料金の累積・JavaScript カスタマイズの保守費・アプリ間連携の複雑化のどこかで、自社スクラッチと比べたときの「割安感」が薄れる分岐点が来ます。この分岐点は、ユーザー数・アプリ数・カスタマイズ範囲の 3 つの軸で判断できます。
分岐点に来たときの選択肢は 3 つです。1 つ目は「kintone を続ける」。カスタマイズを削って kintone の標準機能に業務を寄せ、拡張路線をやめる方向です。2 つ目は「乗り換える」。自社スクラッチで業務システムを作り直し、kintone を停止する方向です。3 つ目は「組み合わせる」。kintone を残しつつ、業務の一部だけ自社スクラッチで作る方向です。中小企業の実務では、3 つ目の「組み合わせる」が最も現実的なケースが多いです。
注意
kintone は「やめる or 続ける」の二択で語られがちですが、実務では「残しつつ一部を自社開発する」組み合わせが最も現実的なことが多いです。kintone は REST API と Webhook が公開されており、外部システムとの連携がしやすい設計です。
本記事では、まず kintone の料金体系と開発費用の実態を整理し、そのうえで「乗り換え」と「組み合わせ」の判断表を作ります。kintone の料金全体像と乗り換えの総論は kintone の料金は高い?コース体系の見方と自社開発との比較・乗り換え判断 にまとめているので、あわせて参照してください。本記事は「開発費用」に絞って掘り下げます。
kintone の料金体系と初期構築費の全体像
kintone の総所有コストは、大きく次の 4 つで構成されます。単純に月額料金だけを見ていると、実際の総額を見誤りやすい構造になっています。
| 費用の種類 | 目安 (100 名利用の場合) | 発生頻度 | 主な内訳 |
|---|---|---|---|
| 月額ライセンス費用 | 12〜18 万円 / 月 | 継続 | ユーザー数 × コース単価 |
| 初期構築費 (自社) | 0〜100 万円 | 一度 | 内製で構築する場合の人件費目安 |
| 初期構築費 (パートナー) | 100〜500 万円 | 一度 | 導入パートナー会社への構築委託費 |
| カスタマイズ費 | 年 50〜300 万円 | 継続 | JavaScript カスタマイズ・プラグイン購入・保守 |
初期構築費は、内製と外部パートナーへの委託でレンジが大きく変わります。内製の場合、kintone の基本操作を学べば非エンジニアでもアプリを作れるという設計のため、費用は主に社内の人件費ぶんで済みます。ただし、初期の 5 〜 10 アプリを非エンジニアが設計すると、後になって「業務ロジックがアプリを跨いで散らばる」「同じマスタが複数アプリに重複している」「レポート出力の要件を後から追加すると設計が破綻する」といった問題が顕在化しやすいです。
外部パートナー会社に委託する場合、業種テンプレートや過去導入の設計知見を活用できる代わりに、初期構築で 100 〜 500 万円のレンジになります。100 万円台の案件は「テンプレートを微修正して数アプリ導入」の規模、500 万円に近づくのは「20 アプリ以上、複数部署をまたぐ業務フロー」を含む規模です。カスタマイズ費は、業務システム化の要求が上がるほど積み上がる継続費用で、年 50 〜 300 万円のレンジが標準的です。ここが「月額料金の見た目」と実際の総額を大きく乖離させる要因になります。
開発費用の内訳と、費用が跳ねる 3 パターン
kintone の開発費用のうち、事前に予測しづらく、かつ運用フェーズで跳ね上がりやすいのがカスタマイズ費用です。カスタマイズ費用が跳ねる主要なパターンは次の 3 つです。
**1 つ目は「JavaScript カスタマイズの深化」**です。kintone は JavaScript でイベントに介入するカスタマイズが公式にサポートされており、フォームの入力チェック、他アプリからのデータ取得、レコードの一括更新など、標準機能では届かない要件を JavaScript で埋められます。これは大きな利点ですが、業務ロジックが JavaScript に寄っていくと、次の 3 つのコストが発生します。
- kintone のプラットフォーム側のアップデートで既存カスタマイズが動かなくなるリスク。年 2 〜 3 回発生する API の変更で、動作確認と手直しが要ります。
- JavaScript の保守要員の確保。kintone カスタマイズを書ける開発者は限定的で、外部委託の時給単価が上がりやすいです。
- テストの困難さ。kintone の JavaScript カスタマイズは、単体テストのフレームワークが整備されておらず、手動テストに依存しがちで、後工程で不具合が顕在化します。
**2 つ目は「大量アプリ連携の複雑化」**です。20 アプリを超えるあたりから、アプリ間のデータ参照とマスタ同期の複雑性が急に上がります。顧客マスタ、商品マスタ、担当者マスタといった中核データを複数アプリで参照する構成では、片方のアプリで更新したデータがもう片方に反映されない、といった不整合が発生します。この不整合を解決するために、Webhook や JavaScript カスタマイズで同期処理を書き足していくと、その保守がまた費用に乗ります。
**3 つ目は「外部システム同期の要件追加」**です。会計システム、EC カート、CRM、勤怠システム、といった外部システムとのデータ同期を kintone で行おうとすると、両方向の同期処理を JavaScript や外部の連携サービス (Zapier、Make、iPaaS 系サービス) で組む必要があります。両方向同期は片方向同期よりも設計が難しく、エラー時の復旧手順、競合したときの優先順位、といった論点が積み上がります。iPaaS 系サービスの月額費用も別途乗ってくるため、総所有コストがさらに上がります。
FIXITkintone って、そのまま使えば安いものだと思ってたけど、意外とお金かかるの？
月額料金だけ見るとお得なんですよ。でも、業務が乗ってくると、カスタマイズ費や連携費が積み上がっていくんです。
Hinata特に JavaScript カスタマイズと外部システムとの同期が入ると、保守費が年ごとに増えていく傾向があります。
FIXITじゃあ、どのタイミングでスクラッチに切り替えを考えるべき？
Hinataユーザー数・アプリ数・カスタマイズ範囲の 3 つの軸で判断すると分かりやすいですよ。
自社スクラッチと比較したときの分岐点
kintone とスクラッチの分岐点は、3 つの軸で判断すると整理しやすいです。それぞれの軸で「厳しくなってきた」ラインを超えたかどうかを見て、2 つ以上超えていたら本格的にスクラッチを検討するタイミングです。
| 判断軸 | まだ kintone で良いライン | スクラッチを検討するライン | スクラッチが有利なライン |
|---|---|---|---|
| ユーザー数 | 〜 50 名 | 100 〜 300 名 | 300 名以上 |
| アプリ数 | 〜 15 アプリ | 20 〜 50 アプリ | 50 アプリ以上 |
| カスタマイズ範囲 | 入力チェックとレポート | 業務フロー全体を JS で分岐 | 外部システム両方向同期 |
これらの軸を組み合わせて、次のような 3 つの状態を区別できます。
状態 A: まだ kintone が最適。ユーザー数 50 名以下、アプリ数 15 以下、カスタマイズは入力チェックとレポート程度。スクラッチに切り替えると初期費が回収できない領域です。この状態でスクラッチ化の見積を取り始めると、判断がぶれるだけになります。
状態 B: 分岐点。ユーザー数 100 〜 300 名、アプリ数 20 〜 50、業務フロー全体を JavaScript カスタマイズで分岐している状態。この状態ではスクラッチとの費用比較が拮抗してきて、3 年後の運用を見据えた戦略判断が必要になります。「乗り換える」「組み合わせる」「拡張路線を止める」の 3 つを並列で検討します。
状態 C: スクラッチが有利。ユーザー数 300 名以上、アプリ 50 以上、外部システムとの両方向同期を含む構成。この状態では、月額料金の累積とカスタマイズ費で、スクラッチの初期費を数年で回収できるレンジに入ります。「乗り換え」または「主要業務だけスクラッチ化」の判断が現実的です。
FIXIT が支援した実案件では、状態 B の中小企業で「kintone を残しつつ、業務の根幹だけスクラッチで作る組み合わせ型」に落ち着くケースが多いです。全部を kintone に寄せると保守費が跳ね、全部をスクラッチにすると初期費と機能追加のスピードで劣る。中間解として、業務の性質ごとに使い分ける組み合わせが、費用対効果のバランスで最も良い結果になりやすいです。
AI 駆動開発でスクラッチ側を選ぶメリット
分岐点の判断で、スクラッチ側の初期費が高い、というのが従来の kintone 継続の理由の 1 つでした。しかし、AI 駆動開発の登場で、この初期費が大きく下がってきています。実案件の感触では、業務システムのバックオフィス業務 (社内申請、顧客管理、在庫、受発注) をスクラッチで作る場合、従来開発と比べて 1/2 〜 2/3 の期間・費用で本番投入できるケースが増えています。
なぜスクラッチのコストが下がるのか。理由は 3 つあります。
1 つ目は、業務システムの領域が「業務ロジックが明確で、テストを先に書きやすい」という特性を持っていることです。社内申請、承認フロー、在庫の入出庫、といった業務は、入力と出力が明確で、テストを先に書いてから AI に実装させる進め方が有効です。これは AI 駆動 TDD で扱っている進め方の応用領域です。
2 つ目は、UI が「フォームとリスト中心」で、複雑なアニメーションやゲーム的なインタラクションを要求しない領域だという点です。フォームとリスト中心の UI は AI コーディングツールが最も得意とする領域で、Claude Code などに要件を渡すと 1 画面あたり数十分から数時間で骨格が出来上がります。
3 つ目は、認証・課金・監視のような必須インフラを、AI に IaC (Infrastructure as Code) で書かせてセットアップできる点です。従来はここで 1 〜 2 週間かかっていた作業が、AI 駆動で 2 〜 3 日に圧縮できるようになりました。この効果は SaaS の MVP 開発の費用と期間 にも整理しています。
3 年累計での比較を試算すると、次のようになります (100 名利用、20 アプリ相当の業務システム、スタンダードコース想定)。
| 内訳 | kintone 継続 (3 年) | スクラッチ (AI 駆動) |
|---|---|---|
| 月額 or 初期開発費 | 540 万円 | 600 〜 800 万円 |
| カスタマイズ費 or 追加開発 | 300 万円 | 100 〜 200 万円 |
| インフラ費 | 込み | 20 〜 40 万円 |
| 3 年累計 | 840 万円 | 720 〜 1,040 万円 |
3 年累計で kintone と拮抗するラインが、AI 駆動開発の導入で下方向にシフトしていることが分かります。従来ではスクラッチ側が明らかに高かった規模でも、AI 駆動なら「初期費で回収できる」レンジに入ってきています。
kintone を残しつつ組み合わせる進め方
「乗り換える」よりも「組み合わせる」ほうが現実解になるケースが多いと述べました。組み合わせのパターンは大きく 3 つあります。
**1 つ目は「フロント補完型」**です。kintone をデータ基盤として使い、社外向けのフロント画面を自社スクラッチで作ります。会員ポータル、予約受付、EC サイト、といったカスタマー向け機能で使われます。kintone の REST API で会員データを読み書きし、フロント側は Next.js や SvelteKit で作る構成が典型例です。この構成では、社内業務は kintone のまま、対外向けの UX だけをスクラッチで磨けます。
**2 つ目は「バックエンド補完型」**です。kintone を業務入力の窓口として使い、分析・帳票・大量データ処理を自社スクラッチのバックエンドで行います。kintone の Webhook で業務データが更新されたイベントを受け、スクラッチ側の DB に同期し、集計や帳票出力を行う構成です。kintone の標準機能では処理しづらい「1 万件を超えるレコードの集計」「複雑な条件のクロス集計」「他システムのデータとの結合」といった要件は、この構成で解けます。
**3 つ目は「機能特化型」**です。kintone の得意な業務 (社内申請、進捗管理、簡易 CRM) は kintone に任せ、業務の根幹 (受注、請求、在庫) だけスクラッチで作ります。中規模の EC 事業者や卸売業で採用されるパターンで、kintone の「みんなが触れる業務基盤」の役割を残しつつ、事業の中核データはスクラッチで管理します。
3 つのうちどれを選ぶかは、kintone のどの部分に不満があるかで決まります。カスタマイズの限界であれば機能特化型、パフォーマンスの限界であればバックエンド補完型、外部向け UX の限界であればフロント補完型、といった対応関係です。
失敗を避けるチェックリスト
kintone の開発費用の判断と、スクラッチとの比較・組み合わせの検討で、事前に確認しておくべき論点を整理します。
- 現在の kintone の総所有コスト (月額 + カスタマイズ費) を 3 年累計で試算しているか
- ユーザー数・アプリ数・カスタマイズ範囲の 3 軸で「厳しくなってきた」ラインを超えたかを確認しているか
- 「乗り換え」「組み合わせ」「拡張停止」の 3 つを並列で検討しているか
- 組み合わせを選ぶ場合、フロント補完型・バックエンド補完型・機能特化型のどれに該当するかが明確か
- スクラッチ側の見積を、AI 駆動開発の前提で取り直しているか (従来開発の見積と比較すると判断がぶれる)
- 移行対象データの整合性と、既存 kintone アプリの停止順序を計画に含めているか
これらを満たしたうえで、AI 駆動開発でスクラッチを選ぶメリットは 3 年累計での費用面だけでなく、業務の中心にあるデータを自社で細部までコントロールできる点にあります。kintone を続けるか、スクラッチに切り替えるか、組み合わせるか。判断のための情報が揃った時点で、経営会議で議題に上げるのが良いフェーズです。
kintone 継続 vs 自社開発のご相談
kintone を導入して 3 〜 5 年経ち、月額料金とカスタマイズ費が積み上がってきた中小企業ほど、次の一手の判断が難しくなります。「乗り換え」「組み合わせ」「拡張停止」のうちどれが最適か、AI 駆動開発でスクラッチを組んだ場合の実際の見積はどうなるか、といった具体的な数字を持って議論を進めるフェーズなら、FIXIT の無料相談が判断材料の 1 つになります。まずは システム刷新・リプレイスのサービス内容 をご覧いただき、お問い合わせ からお気軽にご相談ください。