公開日：
こんにちは、システム開発グループの田邊です。
kintoneアプリを運用開始した直後に発覚しがちな問題の一つとして
kintone APIのリクエスト上限オーバーがあります。
上限を超過した場合、影響が大きい場合は最悪API実行が中断されるリスクがあります。
また、上限を超えていなくても、
無駄にAPIリクエスト数を消費するようなカスタマイズはkintoneの性能にも
悪影響が出ている可能性もあります。
APIリクエストはネットワークやサーバに負荷を与えるからです。
（だからこそ制限がかかっている、とも言えると思います）
このような事態に陥らないように
知っておいたほうがよいリクエスト数上限に関する情報をまとめました。
今回はノーコードでカスタマイズを行えるツール、
カスタマインを例に説明しようと思います！
プログラミングしていなければ関係ない？
関係あります！
kintoneを扱うプラグインやサービスの多くでは、内部でkintone APIを使っています。
弊社のカスタマインやエブリサイトの一部のカスタマイズでも使ってます。
上限を超えた場合どうなる？
kintone APIのリクエスト数はスタンダードコースでは
アプリごとに1日あたりの上限が1万になっています。
（ワイドコースでは10万です。）
サイボウズさんの公式サイトでは以下のように書かれています。
影響が大きい場合は、APIの利用が中断される事もあるようです。
kintone APIリクエスト数の超過メールが届いたら？
APIリクエスト数の上限値を超過した場合、サイボウズから利用状況について確認の連絡をする場合があります。
また、上限回数を超えたAPIリクエスト実行が他のユーザーの環境に重大な影響を及ぼす場合、API処理を中断することもあります。
そのため、APIリクエスト数の上限超過が恒常的に発生している場合は、原因を特定し適切な対策を講じる必要があります。
リクエスト消費の対象について
リクエスト消費については勘違いしがちなポイントが2つあります。
（１）アプリ単位で適用される
kintone APIのリクエスト上限は、アプリごとに適用されます。
個別のサービスごとに適用されるわけではないです。
複数のサービスを利用している場合はトータルで考える必要があります。
（２）アクセス対象のアプリに適用される
カスタマイズを入れたアプリで必ずしもカウントされるわけでない点にも注意です。
例えばAアプリにカスタマインのカスタマイズを適用していて、Bアプリはカスタマイズ非適用だとします。
AアプリのカスタマイズでBアプリのレコードを操作すればBアプリにカウントされます。
APIリクエスト数を消費するカスタマイズとは？
カスタマインの「やること」のうち、全てがAPIリクエスト数を消費するわけではありません。
どう判別するかですが、アプリ名の指定の有無である程度可能だと思います（※）。
実際に、以下のようなカスタマイズは確認したところ全て消費してました。
（例）
・「キーを指定してレコードを取得する」
・「全レコードを取得する」
以下のようなアプリ名の指定が不要なカスタマイズは消費していませんでした。
（例）
・「一覧で画面に表示されているレコードを取得する」
（※）ただし、以下のようにアプリ名の指定がなくても消費するカスタマイズがありました。
これは現在一覧に表示されていないレコードも含めて
条件に該当するレコードを全てkintone APIを利用して取得し直しているからと思われます。
・「一覧の条件でレコードを全件取得する」
kintone APIの仕様をある程度把握していると
カスタマインでどんなAPIを呼び出しているのか想像できて、判断がしやすくなるかと思います。
気になる場合は動作確認後に、kintoneシステム管理の「アプリ管理」のアプリ一覧から消費の有無を確認してみてください。
カスタマインで特に注意が必要なカスタマイズ
さて、カスタマインでは一括でレコードを取得して、
一件ごとに異なる処理を行うカスタマイズが実現できます。
例えば、「リストから要素を取り出す」で実現する以下の例のようなカスタマイズです。
「リストから要素を取り出す」を使って、ループ処理でレコードの内容によってやることを変えるカスタマイズ
これ、すごい便利でお気に入りなんですが、
ループの中で、kintone APIリクエスト消費を行うカスタマイズを入れると、
レコード件数に比例してAPIリクエスト数を消費します。
レコード件数が多い場合は注意が必要です。
カスタマインの場合、全く同じ条件、内容で更新する場合は、
以下のような一括更新用のカスタマイズを利用する事で、リクエスト消費数を抑えられ、高速にできます。
レコード一覧から複数レコードのコピーや値の一括更新
ワンクリックで一括承認してみよう
ただし、一括更新用のカスタマイズでも「レコードを１つずつ書き出す」のように
レコード1件ごとに消費するカスタマイズもあるのでご注意ください。
カスタマインは作り手の工夫次第でリクエスト消費数を抑え、性能を向上させる事ができます。
是非、いろいろとお試し頂けたらと思います！
(ご参考)
gusukuを使用することでkintone APIリクエスト数が大幅に増えることはありますか？
なぜ運用開始まで気づきにくいのか
上限の問題は、無計画だと開発中に気づくのは難しいです。
それは主に3つの理由からだと考えています。
(1)本番の想定レコード数で確認していない。
(2)本番の想定ユーザ数、利用頻度で動作させていない
(3)ユーザの各操作でどれくらいAPIリクエスト数が増えるのか把握していない
私の実体験では、詳細画面を開いてから保存するだけの操作なら
5回ぐらいだろうと思っていたら、15回ぐらい消費していて驚いた事があります。
まとめ
いかがでしょうか？
上限の問題は、計画段階で気づければ早期に対策できます。
例えば、アプリを分割すれば、APIリクエスト数の消費を分散させる事ができます。
ただし、運用開始してからこのような対策を行うのは
大きなコストと時間が必要になるリスクがあります。
計画段階で利用者数や想定レコード数、利用頻度を
想定し、アプリの設計を行う事が大事です。
弊社のSIサービスである「キミノマホロ」では設計段階から
お客様へ支援させていただく事も可能です。
具体的には「ロ-1 kintoneを使った実現イメージ検討」のメニューが該当します。
何かお困りごとがあれば、ぜひ気軽にご相談ください！
必要なものを、必要なだけ。
業務改善の新しいカタチ。
kintoneを活用した業務改善・システム開発サービス
kintoneを活用した業務改善・システム開発サービス
投稿者プロフィール
-
システム開発グループのエンジニアです。
kintoneを扱った案件をメインに
上流工程から下流工程まで幅広くやらせて頂いてます。
最新の投稿
gusuku2025年12月23日ノーコードツールでも注意！kintone APIリクエスト上限に備える- gusuku2025年10月15日カスタマインユーザがRepotovas Proを使う時に知っておきたい事
- kintone2025年7月9日kintoneの組織間のアクセス権の設定を行う前に知っておきたい事
- kintone2025年4月15日ゲストスペース脱却で性能が改善した理由
