はじめに
ワイドコース限定の機能として「性能カスタマイズオプション」がリリースされました。
kintoneはレコード数・ユーザー数・カスタマイズの複雑さなど、お客様ごとに利用状況が大きく異なり、パフォーマンスに影響する要因も多岐にわたります。
そのため、すべてのケースに対応できる汎用的な改善策を用意することが難しい状況です。
そこで、ユーザー自身が利用用途に応じて性能を調整できるカスタマイズオプションを用意し、kintoneにおける性能面の懸念を軽減することを目的としています。
今回は性能カスタマイズオプションについて、下記のような疑問を解消できるようご紹介します。
- どういう機能なのか?
- オプションを適用したときに何ができなくなるのか?
- どんなアプリに適用するべきなのか?
課題別に見る推奨オプション
| 課題 | 推奨オプション |
|---|---|
| 短時間にレコード登録が集中する | |
| グラフ表示の処理時間を短縮したい | |
| 大量レコードで一覧表示・絞り込みに時間がかかる | |
| 一覧画面の表示・件数取得に時間がかかる | |
| 詳細画面の表示に時間がかかる 一覧から詳細への遷移に時間がかかる |
レコード登録時のレコード番号連番保証設定を解除する
kintoneにレコードを登録する際に割り当てられるレコード番号の連番を保証しないオプションです。
仕組み
レコード番号の連番について
kintoneのレコードには「レコード番号」が自動付与されます。
レコードが登録される場合、レコード番号を管理するテーブルがロックされ保存処理が実行されます。
複数レコードが同時に登録される場合はロック待ちが生じる仕様となっています。
オプションを有効にした場合
レコード登録時、保存処理を待たずに採番処理が完了するため、ロック待ちが短縮される仕様となります。
どんな問題を解決するか
テーブルのロック待ちが短縮されるため、多くのレコードを効率的に登録できるようになります。
適用が有効なケース
- 外部システムからAPIを通じて大量レコードを並列登録している
- 複数担当者が同時に新規レコードを作成する業務フローがある
- 月末・期末などの特定タイミングにレコード登録が集中する
適用時の注意点
保存処理を待たずに採番処理が完了するため、一部の番号がスキップされる可能性があります。
「連番に欠けがあってはならない(伝票番号・契約番号など)」という業務要件がある場合は適用できません。
一斉大量書き込み用非同期レコード登録REST APIを有効化する
非同期登録エンドポイントを登録するAPI(/k/v1/async.json)が利用できるようになるオプションです。
仕組み
通常のREST APIの動き
通常のREST API(同期登録)は、kintoneサーバーが登録処理を完了させてからレスポンスを返します。
処理に時間がかかる場合、呼び出し元はその間待機し続けます。
非同期登録エンドポイントの動き
APIを実行したタイミングでは、DBにレコードデータは保存されません。
エンドポイントを作成し、後から順次レコードデータを登録します。
どんな問題を解決するか
受け付けたリクエストを非同期で順次実行可能となり、リクエスト受け付け時の処理負荷が削減されます。
その結果、短時間での大量リクエストを受け付けることが可能になります。
適用が有効なケース
- 外部システムから大量レコードをバッチで流し込む一方向連携
- APIタイムアウトや同時接続数の上限超過が発生するリスクを軽減したい場合
適用時の注意点
バックグラウンド処理中にエラーが発生した場合、呼び出し元はそのエラーを受け取れません。
「登録成功を確認してから次の処理に進む」という設計が必要な業務では適用できません。
警告
このオプションは複数のアプリに適用することができません。
レコード一覧・グラフ表示用のデータ取得リクエストをリードレプリカに対して実行する
kintoneは内部でメインDBとレプリカDB(複製)を持っており、読み書き処理がメインDBで行われます。
リードレプリカ利用オプションを有効にすると、読み取り処理(集計・クエリ)をレプリカDBに向け、メインDBの負荷を軽減します。
レコード一覧のデータ・レコードデータを集計してグラフを表示する際のデータ取得リクエストをリードレプリカに対して実行するように変更するオプションです。
適用できるオプションは次のとおりです。
- グラフ表示用のデータ取得リクエストをリードレプリカに対して実行する
- レコード一覧表示用のデータ取得リクエストをリードレプリカに対して実行する
仕組み
レコード一覧・グラフ表示は、リードレプリカを参照し、レコード一覧・グラフ表示以外のリクエストはメインDBを参照します。
どんな問題を解決するか
大量データ環境や、kintoneを利用するユーザー数が多い環境では、各種処理に伴うDBの負荷が高くなる傾向があります。
特に、全件を対象とするフルスキャン系のクエリ(集計・ソート・複雑な絞り込み)は処理コストが高く、メインDBの負荷を圧迫する要因となります。
本機能を適用することで、メインDBの負荷を軽減し、処理遅延の抑制が期待できます。
適用が有効なケース
- 大量データを持つアプリで集計・検索が主な操作
- グラフ・集計表示のパフォーマンスが低下している
- 読み取り操作が多く、書き込みは比較的少ない
- 特定アプリへのアクセスが多くなる場合
- 大量データは登録されているアプリ
- レコード一覧に重い絞り込みを利用している
適用時の注意点
メインDBへの書き込みがレプリカDBに反映されるまでにわずかな遅延(レプリケーションラグ)があります。
そのため、レコードの登録・更新直後に同一レコードを検索した場合、反映までに時間差が生じ、更新前の内容が表示される場合があります。
レコード・関連データ・件数を手動で取得する
kintoneはレコード一覧画面や詳細画面などを表示すると自動でレコード・関連データ・件数等を取得します。
この自動取得は便利な反面、大量データやアクセス数が多い時にDBの負荷を高める原因にもなります。
自動取得を無効にすることで、サーバーへの負荷を軽減できる可能性があります。
適用できるオプションは次のとおりです。
レコード一覧表示時にデータを手動で取得する
レコード一覧画面を表示した際にレコードを自動取得しないようにするオプションです。
仕組み
オプションを適用した場合、一覧画面に「データを取得」のボタンが表示され、ボタンが押下された際にデータ取得され一覧が表示されます。
どんな問題を解決するか
kintoneアプリに登録されているレコード件数・複雑なアクセス権・重い絞り込み条件などの影響を受け、レコード一覧が表示されるまでに時間がかかる場合があります。
有効にすることで、kintoneアプリを表示したタイミングで、レコードデータを取得しなくなるため、一覧画面表示の負荷を削減できます。
関連レコード一覧のデータを手動で取得する
レコード詳細画面を表示する際に関連レコード一覧を自動取得しないようにするオプションです。
仕組み
オプションを適用した場合、詳細画面に「関連レコードを取得」のボタンが表示され、ボタンが押下された際にデータが取得され関連レコードのデータが表示されます。
どんな問題を解決するか
関連レコード一覧の取得は、関連レコード一覧の設置数に応じてリクエスト数が増加します。
また、レコード詳細画面が表示される度に実行されるため、配置している関連レコードの数だけリクエストが送信されます。
関連レコードを複数配置している場合や、複雑な絞り込みを設定している場合に、DBの負荷がかかります。
有効にすることで、kintoneアプリのレコード詳細画面を表示したタイミングで、関連レコード一覧のデータを取得しなくなり詳細画面表示の負荷を軽減できます。
レコード一覧表示時のレコードの総件数を手動で取得する
レコード一覧画面を表示した際にレコード一覧画面右上に表示されるレコードの総件数を自動取得しないようにするオプションです。
仕組み
レコードの総件数の箇所には「(件数を表示)」が表示され、押下するとレコードの総件数が集計され表示されます。
どんな問題を解決するか
レコード一覧画面が表示される度にレコード件数を集計する処理が実行されるため、レコードの登録件数・絞り込み条件・アクセス権等の影響によって処理が重くなる場合があります。
有効にすることで、kintoneでレコード一覧画面を表示したタイミングで、レコード件数が取得されなくなり、一覧画面表示の負荷を軽減できます。
適用が有効なケース
- 大規模データを保持するアプリを利用する場合
- 大量データを扱うアプリを利用する場合
- レコード数が多いアプリ環境において
適用時の注意点
自動表示がなくなることで「データが消えた」「画面が壊れた」と誤解されることがあります。
適用前に利用ユーザーへの説明と、必要に応じた画面上のガイダンス追加を検討してください。
3つのオプション(レコード一覧・関連レコード・件数)は独立して設定可能です。
業務フローに合わせて組み合わせてご利用ください。
レコード詳細画面の「次/前のレコードへ移動」時にキャッシュを利用し、データの絞り込み処理を省略する
レコード一覧に表示されているすべてのレコードIDをキャッシュ化するオプションです。
仕組み
レコード詳細画面に表示される「次/前のボタン」は、アクセス権や削除済みレコードを考慮する仕様となっています。
そのため、レコード詳細画面を表示する際には、内部的にレコードの絞り込み処理が再実行されます。
なお、レコードの絞り込み処理は、レコードの登録件数・絞り込み条件・アクセス権などの要因により負荷が高くなる場合があります。
有効にすることで、レコード一覧のレコードIDをキャッシュ化して利用するため、内部的にデータの絞り込み処理が再実行されません。
どんな問題を解決するか
大量ユーザーが一覧から詳細を繰り返し参照するような業務では、このリクエストが積み上がってサーバー負荷を高めます。
有効にすることで、レコード詳細画面を表示する際に必要となる内部的な絞り込み処理を軽減できます。
適用が有効なケース
- 詳細画面から次/前のレコードへの遷移を繰り返す参照中心の業務(コールセンター・受付確認など)
適用時の注意点
表示内容が最新でない場合があります。
特にレコード詳細画面に遷移後に追加したレコードなど対応できない可能性があります。
一覧画面に戻ることで最新データを取得できます。
複数選択、チェックボックス、ユーザー選択、グループ選択、組織選択フィールドの絞り込み時に実行する内部クエリを切り替える
内部的に利用しているクエリを別のクエリに切り替え、レスポンスの改善を試みるオプションです。
仕組み
チェックボックス・複数選択リストなどの複数選択系フィールドを絞り込み条件に使う際のクエリ生成方式を変更します。
どんな問題を解決するか
特定のkintoneアプリを利用するユーザー数が多く、アプリの利用頻度が高まることで、DBの負荷が増加します。
さらに、アプリに大量のレコードが登録されているかつ、複数選択系フィールド(複数選択、チェックボックス、ユーザー選択、グループ選択、組織選択)などの絞り込みを設定している場合に効果が期待できます。
適用が有効なケース
- レコード件数が多いアプリで複数選択・チェックボックス等の絞り込みを使用している場合
適用時の注意点
- 利用するクエリを変更するオプションとなるため、絞り込み条件やデータ件数などの影響によりレスポンスが悪化する場合もあります
- 複数選択フィールドを使った絞り込みを利用する場合は、次のリンクも併せてご確認ください。
快適な絞り込みを設定してみよう!
おわりに
今回はワイドコース限定の「性能カスタマイズオプション」についてご紹介しました。
適切なオプションを適用することで大量レコード・大量アクセスが発生する環境でもエラーや遅延がなく快適にご利用いただける可能性があります。
各課題別に性能カスタマイズオプションをご検討ください。
また、下記記事では大規模導入を想定した設計および運用面で考慮すべき技術的なポイントを解説していますので、併せてご参照ください。
kintone大規模運用のためのパフォーマンス設計ガイド
このTipsは、2026年2月版kintoneで動作を確認しています。
