「kintoneが限界だ」と言われる状況には、性質の違うものが混ざっています。公式に決められた仕様上の上限に当たっている場合、上限には遠いが運用が重くなっている場合、そして機能ではなく改修の積み上がりが問題になっている場合です。
この3つは対処が違います。仕様上の上限は設計を変えれば回避できることがあり、運用の重さは設定で変わり、改修の積み上がりは体制の話です。以下では、公開されている数値と、編集部が判断材料として置いた見方を分けて書きます。
乗り換えなくていい条件は、どこで見分けるのか？
標準機能だけで運用できていて、改修の依頼が年に数えるほどなら、いまのまま使い続けて構いません。
具体的には、次の状態がすべて当てはまるなら、乗り換えの検討はまだ先で問題ありません。
- アプリの設定画面だけで運用が回っていて、JavaScriptやプラグインを入れていない
- 他のシステムとデータを行き来させる必要がなく、必要なときはCSVの受け渡しで足りている
- 一覧やグラフの表示が遅いと現場から言われていない
- kintoneの外で、担当者がExcelに転記して突き合わせる作業が発生していない
kintoneは、表とワークフローで表せる業務を、専任のエンジニアがいなくても組める点に価値があります。この価値が効いている領域を、わざわざ作り替える理由はありません。乗り換えを考えるべきなのは、上の4点のうち複数が崩れてきたときです。
仕様上の上限は、どこまで決まっているのか？
kintoneヘルプの制限値一覧に公表されています。上限がある項目と、上限がない項目が明確に分かれています。
まず押さえておきたいのは、レコード数についての記載です。kintoneヘルプの制限値一覧によると、レコード数の上限はありません。ただし同じページには、レコード数が多くなるとアプリの動作が遅くなる場合があること、表示やデータ処理の速度はアクセス権、絞り込み条件、フィールド数などの利用条件によって異なることが併記されています。あわせて、アクセス権や絞り込みを設定していない1つのアプリに100万件を登録した状態で、レコードの登録や閲覧に問題なく使用できることを確認した、とも書かれています。
つまり「何件までなら大丈夫か」は、公式には件数では答えられていません。件数ではなく設定条件で決まる、というのが公表内容です。
一方で、はっきりと数値が決まっている項目もあります。同じ制限値一覧から、判断に関わるものを抜き出します。
| 項目 | 仕様上の上限 |
|---|---|
| レコード数 | 上限なし（速度は利用条件による） |
| 1アプリのフィールド数 | 500個まで（ラベル・罫線・スペース・レコード番号・作成者・作成日時・更新者・更新日時は含まない） |
| 1アプリの一覧 | 1,000件まで |
| 1アプリのグラフ | 1,000件まで |
| 1アプリのプラグイン | 20個まで |
| 1アプリのJavaScript／CSSファイル | PC用・スマートフォン用それぞれ30個まで、1ファイル20MBまで |
| 1アプリのAPIトークン | 20個まで |
| 1アプリのリマインダー | 10個まで |
| CSV・TSV・TXTの読み込み | 1ファイル100MBまで、10万行まで |
| Excelの読み込み | 1ファイル1MBまで、1,000行・500列まで |
| ファイルの書き出し | 1ファイル100MBまで |
| REST APIの同時アクセス数 | 1ドメイン100まで（超過時はHTTPステータス429） |
| 添付ファイル | 1ファイル1GBまで |
テーブルについては、上限ではなく推奨として「1つのテーブルにつき10フィールドかつ100行までを目安とした利用をおすすめします」と書かれています。上限として禁止されているわけではないため、超えた設計は作れてしまいます。ここは仕様と運用の境目にあたる項目です。
上限に達していないのに重くなるのは、なぜか？
設定の掛け算で処理が増えるためです。件数だけでなく、アクセス権と絞り込みとフィールド数が同時に効きます。
制限値一覧には、絞り込みについて「取得するフィールド数が200万個を超える場合や、レコードの合計サイズが数十MBを超える場合、レコード情報の取得に失敗します」と記載されています。これはレコード件数ではなく、件数×フィールド数で決まる値です。1レコードあたりのフィールドが多いアプリでは、少ない件数でもこの値に近づきます。
アクセス権も体感に効きます。kintoneヘルプのアクセス権設定の反映に関する記事では、レコードのアクセス権とフィールドのアクセス権を変更した際、「どのレコードで、誰に、どのような操作を許可するか」を計算し直す処理が、いくつかのレコードごとに分割して行われると説明されています。同じページには、レコード数またはアクセス権設定数の多いアプリでは、処理の途中で新しい設定が反映済みのレコードと古い設定のままのレコードが混在することがあり、すべてのレコードへの反映に一定以上の時間がかかる場合は定期レポートの集計が失敗しエラーとなる、とも書かれています。
ここから読み取れるのは、アクセス権の細かい設定は「一度決めれば終わり」ではなく、変更のたびに全レコードへ波及する処理を伴う、ということです。部署ごと・案件ごとに権限を細かく切っているアプリほど、設定変更の影響が読みにくくなります。
改修とプラグインは、なぜ積み上がるのか？
標準機能で足りない部分を1つずつ埋めるためです。個々は小さくても、組み合わせの検証が後から効いてきます。
kintoneの拡張は、プラグインの追加とJavaScriptの記述で行います。制限値一覧のとおり、1アプリにプラグインは20個まで、JavaScript／CSSファイルはPC用とスマートフォン用でそれぞれ30個までという枠があります。この枠に達することは実務上まれですが、問題は枠ではなく組み合わせのほうに出ます。
- 同じ画面で複数のプラグインが同じ項目を書き換え、片方の挙動がもう片方を打ち消す
- kintone本体の更新後に、特定のプラグインだけ想定どおり動かなくなる
- 書いた人が退職し、なぜその処理が入っているのか社内で説明できない
- スマートフォン側だけ挙動が違い、現場から報告が上がるまで気づかない
これらは仕様上の限界ではなく、拡張を積み重ねた結果として現れます。だからこそ「あと何件まで大丈夫か」を測っても、この問題は見えてきません。見るべきは、直近の改修依頼が何件あったか、そのうち何件が既存の作り込みの手直しだったか、です。
なお、拡張機能そのものを使えるかどうかは契約コースで決まります。サイボウズの料金ページの比較表では、「外部サービス連携、プラグインなどの拡張機能」はスタンダードコースとワイドコースの提供内容として示され、ライトコースは対象外と表示されています。
移行を検討し始める判断の目安は？
自社の12か月分の履歴から、改修費、手作業、保守体制の基準線を作って判断します。
「年4回なら移行」のような共通基準はありません。業務変更の多い会社と少ない会社では、同じ改修件数でも意味が違うためです。まず直近12か月を月ごとに並べ、自社の通常時を基準線にします。
| 見るもの | 記録する数値 | 判断のしかた |
|---|---|---|
| 改修依頼 | 月ごとの件数、請求額、既存機能の手直しか新規要望か | 直近3か月の平均が、それ以前の9か月より増えた理由を確認する |
| 手作業 | 転記・突き合わせに使った時間と、処理した件数 | 件数が同じなのに作業時間が増えている工程を切り出す |
| 保守体制 | 修正できる人数、引き継ぎ手順の有無、復旧にかかった時間 | 担当者が不在でも復旧できるかを、実際の手順で確かめる |
基準線より悪化した項目が見つかったら、設定変更で戻せるかを先に試します。変更後も数値が戻らない、または戻すための改修費が増え続ける場合に、kintoneの中で直し続ける案と、一部を外に出す案を同じ期間と費用で比べます。
「レコードが◯件を超えたら移行」という言い方をしないのは、公式に件数の上限が示されていないためです。件数を材料にしたい場合は、自社のアプリで一覧を開く操作にかかる時間を実際に計測し、その推移を見るほうが確実です。
限界を確かめる進め方は？
4段階で確かめます。契約条件の確認、公式上限との照合、実測、そして続けた場合と分けた場合の比較です。
- 契約コースと契約形態を確認する。 現在のコース、契約ユーザー数、月額契約か年額契約かを控えます。使える機能の範囲と、後で契約を変えられる時期がここで決まります
- 公式の制限値と自社の設定を照合する。 フィールド数、一覧の数、プラグインの数、JavaScriptファイルの数を、アプリごとに書き出して制限値一覧と突き合わせます。上限に近い項目があれば、その設計自体を見直す候補になります
- 重い操作を実測する。 現場が「遅い」と言う画面を特定し、一覧を開く、絞り込む、書き出す、の3操作にかかる時間を計ります。感覚ではなく数値で残すと、設定変更の効き目も判定できます
- 続けた場合と分けた場合を、同じ期間で比べる。 次の見出しの数え方で、今後3年の総コストを両方について出します。片方だけを見積もると、比較になりません
この4段階を通しても「まだ判断できない」場合、多くは2番目で止まっています。アプリの棚卸しが済んでいないと、どこを測ればよいかが決まらないためです。
年間の総コストは、何を足して見るのか？
4つを足します。ライセンス料、改修費、保守費、そしてkintoneの外で発生している手作業の人件費です。
ライセンス料は公表されています。サイボウズの料金ページによると、年額契約の場合の1ユーザーあたりの料金は、ライトコースが12,000円、スタンダードコースが21,600円、ワイドコースが36,000円（いずれも税抜）です。最小ユーザー数はライトとスタンダードが10ユーザーです。たとえばスタンダードコースを10ユーザーで契約している場合、ライセンス料は年間216,000円（税抜）と計算できます。これは編集部による単純な掛け算であり、実際の請求額はオプションや契約時期によって変わります。
オプションも同じページに公表されています。ディスク増設が10GBあたり月額1,000円、セキュアアクセスが1ユーザーあたり月額250円、ゲストユーザーがライトコース700円・スタンダードコース1,440円（いずれも税抜）です。標準のディスク容量は5GB×ユーザー数と示されています。
残る3つには公表された相場がありません。改修費と保守費はベンダーとの契約次第で、手作業の人件費は自社の給与水準と作業時間で決まります。ここに一律の相場を当てはめると、判断を誤ります。次の形で自社の数字を入れてください。
- 改修費：直近12か月に支払った改修の請求額を合計する
- 保守費：月額の保守契約があれば12倍する。都度払いなら改修費に含める
- 手作業の人件費：対象作業の1日あたりの時間 × 営業日数 × 時間単価
この4つを足した額を、移行後に見込まれる費用と、同じ3年間で比べます。移行費用は初年度に偏り、ライセンス料と手作業費は毎年続くため、単年で比べると判断が歪みます。
全面移行以外に、どんな選び方があるのか？
3つあります。設定で直す、困っている業務だけを外に出す、そしてkintoneを残したまま段階的に移すことです。
設定で直す。 アプリを分割する、フィールドを整理する、アクセス権の粒度を粗くする、といった見直しで解決する場合があります。制限値一覧で上限に近づいている項目があるなら、まずここを試す価値があります。
困っている業務だけを外に出す。 在庫や原価のように、計算の型が決まっていて例外処理が多い業務は、kintoneの中で作り込むより外に出したほうが素直なことがあります。どこまでが標準機能で、どこからが外なのかは、在庫・原価管理をkintoneで続けられるか？向く条件と限界で整理しています。
kintoneを残したまま段階的に移す。 申請や情報共有はkintoneのまま、基幹に近い部分だけを別のシステムに置き、両者をつなぐ形です。この進め方と、連携方法ごとの違いはkintoneを捨てずに移行できるか？API連携から始める段階刷新で扱っています。
どれを選ぶかは、上の「判断の目安」で当てはまった項目によって変わります。判断の入口に戻る場合は、kintoneから乗り換えるべきか？限界・費用・移行方法を判断するを参照してください。
自社のアプリをどう棚卸しすればよいか迷う場合は、お問い合わせからご相談ください。移行を前提にせず、続ける場合の条件から確認します。