大量のレコードを一括取得する際のkintoneにかかる負荷の軽減が目的です。
これにあたってレコード大量取得の新たな方式として、事前に提供されたのが カーソルAPI（cursor.json） です。
記事では「仕様変更に伴って既存実装を含めて処理を置き換えるにはどうしたらいいか」を書きましたが、カーソルAPIについては、
既存のレコード一括取得処理に対する置き換えは難しい仕様です。
として詳細は割愛しました。
多くのレコードを一括で取得する際の一つの手ではあるのですが、使い所は限定的です。
これについて、どうして「置き換えは難しい」のかを踏まえながら、使いどころを考えてみたいと思います。
改めてcursor.jsonとは
指定条件下のレコードを「カーソル」という単位で一旦まとめておき、「カーソルID」という名前をつけておいてカーソルの範囲でレコードを順次取得できるようにする仕組みです。
カーソルを作成し、カーソルIDを取得します。取得したカーソルIDを使ってカーソルから最大500件単位で順次取得できます。1回目のリクエストが1〜500件目、2回めのリクエストは自動的に501件目から1000件目まで、という具合です。
全て取得し終えると、カーソルは破棄されます。
メリットは対象レコード数が大量である場合の取得処理の高速化です。もともと最大500件単位で取得するrecords.jsonは、任意の抽出を取得毎に行うのに対し、cursor.jsonは抽出済みのレコード群を件数毎に取り出していくだけなので、高速かつ負荷が低い処理が可能、ということになります。
こちらの記事で示されている通り、対象が多くなればなるほどその効果は高くなります。
cursor.jsonはどうしてrecords.jsonと置き換えが難しいのか
高速ではあるのですが、$idでのソートと比較するとその差は大きくありません。あくまで、検索・抽出処理が伴った場合に効果がある方式ということになりそうです。
また、仕様を追っていけば見えてきますが、カーソルAPIはブラウザ上で複数のユーザーが使用することを想定していません。
ドメイン単位で同時に10個しか作れない／カーソルを10分以上保持できない
カーソルは、作成されたカーソルのレコードを全て取得し終えると自動的に開放されます。
カーソルとカーソルIDは常に使い捨てです。
ただし、カーソルを作成して全て取得し終えない状態で放置（解放の処理をしないままに）された場合、１０個の制限を食い続けることが起こりえます。
ひとつのkintone環境に１０個しか共存できないので、複数のユーザーが同時進行で処理を実行していれば、比較的かんたんに処理が滞る状態ができそうです。
また、複数のカスタマイズ、プラグイン、外部連携等でカーソルAPIが使用された場合、同時使用数の状況を確認する術もなく、問題が生じた際に原因の切り分けが難しくなります。
並列処理ができず最大限に高速化できない
作成されたカーソルの範囲で順次に処理することしかできないので、並列処理ができません。
順次処理を前提にすれば高速ですが、$idソートで並列的に取得する方式と比較すれば優位性は高くありません。
やはり基本的には$idソート方式で
カーソルAPIはブラウザ上でのJavaScriptカスタマイズにおいてレコード一括取得をする場合には、基本的には使えない、と捉えて良いでしょう。
外部からバッチ処理を実行するなど、限定的な用途を想定している、ということですね。
レコードが大量でカーソルAPIを複数同時進行で使用しない、且つ、並列処理・$idソート方式が使えない or 望ましくない状況
があれば、カーソルAPIは効力を発揮してくれそうですね。
当然、ブラウザ上で数十万件のレコードを取得、処理することはそもそも望ましいことではないかもしれません。
とはいえ、集計、データ視覚化といった用途をブラウザ上で行いたい、対象が1万件を超えるという場面は十分にあり得ます。
kintoneのカスタマイズにおいて汎用的なレコード一括取得の方式を選択するときは、やはり$idソート方式を選ぶことになるのかもしれません。
