業務システムを新しく作るとき、誰もが「kintoneのようなノーコードで済ませるか、スクラッチで一から作るか」で迷います。比較記事の多くは「kintoneは安い・速い」と煽りますが、知りたいのは自社のケースではどちらが正解かのはずです。
先に結論を言います。kintone対スクラッチは、本来は二択ではありません。多くの場合の最適解は「kintoneで足りる部分は作らず、足りない部分だけ開発する」というハイブリッドです。
株式会社六（Roku inc.）は、kintoneの連携・カスタマイズとスクラッチ開発の両方を手がけています。だからこそ、どちらかに偏った推し方はしません。この記事では、kintoneの向き・不向き、ぶつかる前に知るべき限界、スクラッチが本当に必要になる条件、そして第三の選択肢までを中立的に整理します。
kintoneとスクラッチ開発は何が違うのか
両者の違いは「部品を組むか、ゼロから設計するか」に集約されます。
kintoneは、サイボウズが提供するクラウド型の業務アプリ作成プラットフォームです。用意された「部品」（フィールド・一覧・グラフなど）をノーコードで組み合わせ、データ管理アプリを素早く作ります。現場担当者が自分で項目を足し画面を直せるのが大きな特徴です。一方スクラッチ開発は、要件に合わせてデータ構造・処理・画面をゼロから設計します。プラットフォームの制約に縛られず業務に完全に合わせられますが、その分、設計と実装の工数がかかります。
傾向を1枚にまとめます（数値は目安、要件により変動）。
| 観点 | kintone | スクラッチ開発 |
|---|---|---|
| 初期費用 | 低い（開発不要〜小規模カスタマイズ） | 高い（小規模 約200万〜500万円、中規模 約500万〜1,000万円｜出典：hnavi.co.jp、giginc.co.jp） |
| ランニング | 月額ライセンス費が継続発生（後述） | 保守費は要件次第。固定ライセンスはない |
| スピード | 速い（標準機能なら即日〜） | 遅め（規模により最低1年・一般に2〜3年｜出典：system-kanji.com）※当社はAI駆動開発で短縮を図る |
| 自由度 | 部品の範囲内。超える部分はJS/APIで拡張 | ほぼ無制限 |
| 現場での変更 | 得意（ノーコードで自分で直せる） | 開発者対応が必要なことが多い |
製品としてのkintoneの詳細はkintone開発・カスタマイズとは？で解説しています。
kintoneが向いているケース・向かないケース
業務が「部品の組み合わせ」で表現できるかが分かれ目です。
向いているケース（出典：business.ntt-east.co.jp）
- 顧客管理・案件管理・日報・問い合わせ記録など定型業務のデータ管理
- 小さく始めて使いながら改善するスモールスタート
- 情報システム部門に頼らず現場が自分で運用変更したい
向かないケース（出典：abkss.jp）
- 複雑な業務ロジック（多数データへのリアルタイム計算など）
- 数万件超の一括処理、数十万〜数百万件規模の処理・保存
- アクセス集中する高頻度処理、独自UIや外部システムとの深い連携
ここで正直にお伝えしたい反証があります。「kintone＝スモールスタートで安い」という前提は、最新の料金体系では崩れつつあります。2024年11月の改定で、最小契約ユーザー数が5名から10名に引き上げられ、料金も値上げされました（2026年6月時点。出典：pepacomi.com、smartat.jp）。実際に使うのが3〜5名でも10名分の費用が発生します。つまり少人数で長く使うほどSaaSの固定費が積み上がるため、軽量なスクラッチや他ツールのほうが結果的に安くなるケースもあるのです。
kintoneの「3つの限界」：拡張性・データ量・移行
kintoneを選ぶなら、いつか来る限界を「ぶつかってから」ではなく事前に見積もるのが賢明です。
拡張性の限界
標準機能やプラグインで届かない要件は、JavaScriptカスタマイズやAPI連携が必要です。逆に言えば、ここを開発で補えればkintoneの守備範囲は大きく広がります。当社はこのJS/API開発でノーコードの限界を超える実装を多数手がけてきました（カスタマイズの幅はkintone開発・カスタマイズとは？参照）。
データ量・パフォーマンスの限界
ここでも誤解を解いておきます。「kintoneは限界だらけ」という煽りも誇張です。レコード数に上限はありません。公式に「上限値は設けていない」と明記され、100万件登録時の快適動作も確認済みとされています（出典：cybozu.com）。
正確には、限界は「行数」ではなく掛け算で訪れます。公式のkintone SIGNPOSTは、性能を「①データ量 × ②複雑度 × ③アクセス数」の掛け合わせで捉えるよう示しています（出典：kintone.cybozu.co.jp）。「何件まで大丈夫か」を単一の数字で判断するのは危険です。具体的な制約値は次のとおり（2026年6月時点。出典：cybozu.com）。
- フィールド数：1アプリあたり最大500個
- API：1アプリあたり10,000リクエスト/日、ドメインごとの同時アクセス数100
- ディスク容量：契約ユーザー数 × 5GB（ドメイン全体で共有、他サイボウズ製品とも合算）
移行（ベンダーロックイン）の限界
CSVでのデータ書き出しは可能ですが、アプリの構造・JSカスタマイズ・プラグイン設定はそのまま移せず、移行先で再設計が必要になるのが実態です。移行コストは案件依存のため一概には言えません。だからこそ最初の設計時に、将来の出口も意識しておくと安心です。
スクラッチ開発が必要になる条件
業務がkintoneの「部品とデータモデル」に収まらなくなったときが境界線です。業務システム全体をスクラッチで考える場合の全体像は業務システム開発とはで整理しています。
- データモデルに収まらないとき：部品の組み合わせや500フィールドの枠、アプリ単位のデータ構造に業務が収まらない場合は、ゼロからのデータ設計が必要
- 性能・同時アクセス・独自UXが競争力に直結するとき：大量データの高速処理やアクセス集中耐性、独自の操作体験が差別化要因になる場合、APIレート制限や共有基盤の制約があるkintoneでは表現しきれない
- 複数システム連携が業務の中核になるとき：外部システムをまたいだ処理が中心なら、connectの自由度が高いスクラッチが向く
なお「スクラッチは高い・遅い」という旧来の常識は前提が変わりつつあります。相場は前掲のとおり数百万〜数千万円・1〜3年ですが（出典：giginc.co.jp）、当社はAI駆動の高速開発で期間短縮を図っています。短縮率はケース次第のため断定しませんが、「スクラッチ＝必ず高く遅い」という前提だけで選択肢から外すのは早計です。
第三の選択肢：kintone＋必要部分だけスクラッチ
「全部kintone」も「全部スクラッチ」も、等しく失敗します。
得意でない大規模処理まで何でもkintoneに押し込むと、類似アプリの乱立や死蔵アプリの増加、パフォーマンス低下を招きます。管理ルールなしに広げた結果、かえって情報が探しにくくなる——これは公式コミュニティでも指摘される典型的な失敗です（出典：kincom.cybozu.co.jp）。拡張＝正義ではないのです。
そこで現実的なのが、足りる部分はkintoneに任せ、足りない部分だけJS/APIや外部開発で補うハイブリッド設計です。当社にはこの設計を支える実績があります。
- サイボウズ商店：kintoneの提供元であるサイボウズ社のShopifyストアで、kintone×Shopifyの在庫・販売履歴を連携するカスタムアプリを開発。kintone上での一括管理を実現し、約3ヶ月で完了
- NPO法人わくわーく 入館管理システム：NFCタグとカードリーダーをkintoneと連携させ、入館データを自動記録。現場の管理負担を軽減
AI×APIの実例としては、ChatGPT問い合わせ自動応答システム（ChatGPT・Shopify・Logiless API連携、約5ヶ月で構築、1時間あたり約400件処理）もあります。これはkintone連携ではなくShopify/Logiless連携ですが、「既存ツール＋AI×APIで足りない部分を補う」という発想は同じです。
失敗しない判断ステップ
要件を3つの軸で仕分けると、自社の立ち位置が見えます。
- 定型／非定型：データを記録・一覧する定型業務か、複雑なロジックが絡む非定型業務か
- データ量・アクセス：件数、同時利用人数、処理頻度はどのくらいか
- 連携：他システム連携が「あれば便利」か「業務の中核」か
定型・小〜中規模・連携が軽いほどkintone寄り、非定型・大規模・連携が中核ほどスクラッチ寄り、その中間がハイブリッドです。相談前に「対象業務の流れ」「想定ユーザー数とデータ量」「連携したい既存システム」を整理しておくと話が早く進みます。依頼先の選び方はkintone開発会社の選び方｜伴走型支援とはで詳しく扱っています。
よくある質問
Q. kintoneで作ったものを後からスクラッチに移行できますか？
データのCSV書き出しは可能ですが、アプリ構造・JSカスタマイズ・プラグイン設定はそのまま移せず、移行先での再設計が前提になります。移行コストは案件依存のため一概には言えません。最初の設計段階で「将来の出口」を意識しておくのがおすすめです。
Q. kintoneのカスタマイズ（JS/API）はどこまでできますか？
標準機能やプラグインで届かない要件は、JavaScriptカスタマイズやAPI連携でかなりの範囲を補えます。当社もこのJS/API開発でノーコードの限界を超える実装を行ってきました。ただしAPIは1アプリ10,000リクエスト/日、同時アクセス100といった制約があり（出典：cybozu.com）、高頻度・大量処理が中核ならスクラッチが向きます。
Q. スクラッチ開発はkintoneよりどのくらい高い・長いですか？
一般的な相場は小規模で約200万〜500万円、中規模で約500万〜1,000万円、期間は1〜3年程度です（出典：hnavi.co.jp、system-kanji.com）。一方でkintoneも最小10ユーザーのライセンス費が継続発生します（2026年6月時点）。当社はAI駆動の高速開発で期間短縮を図っており、総保有コストで比較するのが正確です。
Q. 小規模・少人数でもスクラッチを選ぶべきケースはありますか？
あります。実際に使うのが3〜5名でも、kintoneは最小10ユーザー分の費用がかかります（2026年6月時点。出典：pepacomi.com）。少人数で長期運用するほど固定費が積み上がるため、軽量なスクラッチや他ツールのほうが総額で安くなることもあります。利用人数と運用年数を掛けて試算してみてください。
Q. kintoneとスクラッチ、両方を相談できる会社はありますか？
株式会社六（Roku inc.）は、kintone連携・カスタマイズとスクラッチ開発の両方を手がけています。どちらかに誘導するのではなく、「そもそも作るべきか」「どこまでkintoneで足りるか」から中立に診断します。システム開発・kintone連携サービスをご覧いただくか、無料相談からご相談ください。
kintone対スクラッチは、勝ち負けを決める二択ではありません。本当に問うべきは「どこまでkintoneに任せ、どこからを作るか」という線引きです。当社は無理に作らない中立的立場で、その線引きからお手伝いします。判断に迷ったら、まずはお問い合わせください。
