kintoneの処理を外部バックエンドへ分けるべきタイミングは？見直しの兆候と判断基準
- 1 日前
- 読了時間: 8分
kintoneのデータが増えたからといって、すぐに外部システムへ移す必要はありません。
見るべきなのは件数そのものではなく、処理時間、APIの呼び出し方、変更影響、失敗時の復旧、外部アクセスの集中といった運用上の兆候です。本記事では、すでにkintoneを使っている会社が構成見直しを検討するタイミングを整理します。
はじめに：レコード件数だけでは、外部化のタイミングは決められない
サイボウズのクラウドサービス制限事項では、kintoneの登録レコード数について、現在上限値は設けていないと案内されています。また、1つのアプリに100万件を登録した状態で快適に使用できることを確認したとも記載されています。
一方、kintone REST APIの共通仕様には別の制限があります。1つのアプリにつき1日に実行できるAPIリクエストは、スタンダードコースで10,000件、ワイドコースで100,000件です。同時にリクエストできるAPIは1ドメインにつき100までです。複数レコードの取得は1回500件まで、登録・更新・削除は1回100件までです。
つまり、**「何件あるか」より「その件数をどう処理しているか」**のほうが重要です。
外部バックエンドへ分けても、kintone側のAPI上限そのものが増えるわけではありません。外部化に意味があるのは、外部側で計算・集計・待ち合わせ・再実行などを行い、kintoneへ送る処理をまとめたり、必要な結果だけを書き戻したりすることで、kintoneが担う処理責務とAPI呼び出しを減らせる場合です。
結論：外部バックエンドを検討するのは「運用上の症状」が出始めたとき
単純なレコード件数ではなく、まず次のような症状が出ていないかを確認します。
定期処理が時間内に終わらない、またはAPI回数が増え続けている
同じ業務ルールを複数箇所へ実装し、修正漏れや結果の不一致が起きている
連携失敗時の確認・再実行を人が手作業で行っている
社外ユーザーからのアクセスを、そのままkintoneへ流すことが不安になっている
これらは「kintoneではできない」という意味ではありません。kintone内へ処理を積み増すより、機械処理だけを外へ分けたほうが運用しやすくなり始めたサインです。
兆候1：定期処理が時間内に終わらない、API回数が増え続けている
たとえば、毎晩の集計や基幹システムとの連携が、以前は短時間で終わっていたのに、データの増加とともに翌朝まで残るようになったケースです。
このとき見るべきなのは、単なるレコード総数ではありません。
1回の処理で何件読むのか
何件更新するのか
1レコードごとにAPIを呼んでいないか
差分だけではなく全件を毎回処理していないか
1日に同じアプリへ何回APIを呼んでいるか
を数えます。
たとえば2万件すべてを更新対象として、1件ずつAPIで更新すれば2万回のリクエストが必要です。一方、複数レコード更新APIは1回100件まで更新できるため、100件単位にまとめれば更新処理は理論上200回です。さらに外部バックエンド側で差分判定を行い、実際に変更が必要なのが500件だけなら、更新処理は5回まで減らせます。
**「データが多いから外へ出す」のではなく、「kintoneへ何度も同じ仕事をさせる構成になっているから見直す」**という考え方です。
兆候2：同じ業務ルールを複数箇所へ実装し、結果がずれ始めた
次の兆候は、処理時間ではなく変更時に現れます。
たとえば、同じ料金計算や判定ロジックを複数のkintoneアプリやJavaScriptカスタマイズへ書いている場合です。
最初は問題なくても、条件変更のたびに複数箇所を修正する必要があります。片方だけ修正されると、アプリによって計算結果が異なる状態になります。
現場で、
「どちらの数字が正しいのか確認しないと分からない」
「この条件変更は何個のアプリへ影響するのか毎回調査している」
「同じ修正を複数のカスタマイズへ反映している」
といった状況が出ているなら、業務ロジックを共通のバックエンドへ集約することを検討できます。
ここで外へ出すのは画面そのものではなく、複数箇所で共通利用する機械的な判断・計算部分です。
兆候3：連携が止まると、人が「どこまで成功したか」を調べている
外部サービスや基幹システムとの連携では、正常に動くときより、途中で止まったときに構成の弱点が見えます。
たとえば100件の連携中に途中でエラーになり、担当者が、
何件目まで成功したかを確認する
失敗した対象をExcelなどへ控える
手作業で再実行する
二重登録されていないかを確認する
という作業をしているなら、単純なAPI接続の範囲を超え始めています。
この段階では、処理ID、実行状態、エラーログ、再実行対象などをバックエンド側で管理する構成が候補になります。
重要なのは「再実行機能が欲しいから外部化する」という機能論ではありません。障害時の復旧手順を人が記憶と手作業で支えていること自体が、構成見直しの兆候です。
兆候4：社外ユーザーからのアクセスを、そのままkintoneへ流すことが不安になった
予約サイト、会員向けマイページ、外部フォームなど、kintoneを操作しない社外ユーザーからアクセスを受ける構成では、アクセス数の増加も判断材料になります。
kintone REST APIは、同時にリクエストできるAPIが1ドメインにつき100までです。また、1日に実行できるAPIリクエスト数にも1アプリごとの上限があります。
外部バックエンドを間に置けば、この制限自体がなくなるわけではありません。
ただし、
同じ情報を毎回kintoneから読まず、一時的に保持する
更新を100件単位などへまとめる
アクセスが集中した処理を待ち行列（キュー）へ入れて順番に実行する
kintoneに保存する必要のない途中処理を外部側だけで完結させる
といった方法で、kintoneへ直接流れるリクエストを減らせる場合があります。
外部化の目的は制限の回避ではなく、制限の中で安定して運用できるようにリクエストの流れを設計することです。
具体例：2万件あることではなく、「毎晩どう処理しているか」を見る
仮に、基幹システムから毎晩2万件のデータを取り込み、計算結果をkintoneへ反映する処理があるとします。
2万件あること自体は、外部化の理由にはなりません。
問題になるのは、毎晩、
kintoneから全件取得する
1件ずつ計算する
1件ずつ更新する
途中で失敗すると最初から再実行する
という構成になっている場合です。
この場合、外部バックエンド側で基幹データとの比較・計算・差分判定を行い、変更が必要なレコードだけをまとめてkintoneへ更新する構成へ変える余地があります。
当社がこのような構成を検討する場合も、最初に見るのは「総レコード数」ではなく、1回の業務処理でAPIを何回呼んでいるか、どの処理がkintoneでなければならないのか、失敗時にどこから再開できるかです。
この3点を整理すると、「kintoneを残したまま一部だけ外へ出すべきか」が判断しやすくなります。
外部バックエンドを追加しないほうがよいケースもある
外部システムを増やせば、サーバー、認証、監視、障害対応など、新しい保守対象も増えます。
そのため、たとえば、
処理が1つのアプリ内で完結している
利用者が社内の少人数だけ
定期的な大量処理や外部アクセスがない
エラー時も簡単にやり直せる
現場担当者がkintoneの設定変更だけで業務改善できている
という状態なら、無理に外部バックエンドを追加しないほうがシンプルです。
外部化は高機能化ではなく、複雑さを適切な場所へ分けるための手段です。分ける必要がまだない段階でシステムを増やすと、かえって運用負荷が上がります。
構成見直しの前に確認したい7項目
外部バックエンドの必要性を検討するときは、次の項目を一度整理してみてください。
1回の定期処理でkintone APIを何回呼んでいるか
1日あたり、対象アプリへ何回APIを呼んでいるか
定期処理は必要な時間内に終わっているか
同じ計算・判定ルールが複数のアプリやカスタマイズへ重複していないか
連携失敗時に「どこまで成功したか」を人が調べていないか
社外ユーザーからのアクセスが特定時間帯へ集中していないか
現場担当者が自分で変更したい処理と、開発者が管理すべき機械処理を分けられているか
全部に問題がなければ、今の構成を維持する判断も十分に合理的です。
反対に複数が当てはまるなら、kintoneを置き換える話を始める前に、どの処理だけを外へ分ければ現在のkintoneを活かし続けられるかを整理する価値があります。
kintoneと外部バックエンドの役割分担そのものは別の記事で解説しています
本記事は「いつ見直しを検討するか」に絞りました。
kintoneと外部システムの得意分野や、どこまでをkintoneに残すかという役割分担そのものは、kintoneを活かした業務システム拡張。外部連携で実現できることで解説しています。
また、基幹システム・社内DBとの連携で、リアルタイム同期・定期同期などの方式を選ぶ考え方は、kintoneと基幹システム・社内DBを連携するとき、データ同期方式をどう選ぶかをご覧ください。
プレイリーソリューションズでは、現行構成の整理から対応できます
外部バックエンドが必要かどうかは、要件だけを聞いても判断しづらい場合があります。
プレイリーソリューションズでは、事業会社の方から「kintoneのカスタマイズが増えてきた」「基幹システムや外部サービスとの連携が重くなってきた」といったご相談を受けた場合、まず現行の処理とAPIの流れを整理し、どこをkintoneへ残し、どこを外部へ分けるべきかを検討できます。
必要に応じて、Java / AWSを使ったバックエンド、既存DBや外部APIとの連携まで含めて対応可能です。
最初から全面的な作り直しを前提にせず、現行調査や技術整理から小さく切り出して進めることもできます。
事業会社の方で、現在のkintone構成をこのまま拡張してよいか判断しづらくなっている場合は、ご相談ください。
まとめ：まずは「1回の業務でAPIを何回呼んでいるか」を数える
kintoneの処理を外部バックエンドへ分ける判断は、レコード件数だけでは決められません。
まず見るべきなのは、処理時間、API回数、変更影響、障害時の復旧、外部アクセスの集中といった、実際の運用で観測できる症状です。
そして、外部バックエンドを追加してもkintone側のAPI制限自体は変わりません。外部側で処理をまとめ、必要な結果だけをkintoneへ戻すことで、kintoneが得意な業務画面・データ管理を残しながら、機械処理だけを分離できるかを検討します。
まずは「1回の業務処理でkintone APIを何回呼んでいるか」を数えるところから始めると、構成見直しが必要か判断しやすくなります。
