Agentの報告が正しく見えても、表全体を読んだとは限りません。最初の応答に含まれた実在のレコードだけで、もっともらしい分析は作れます。必要なのは文章の説得力に加えて、取得範囲を最後まで確認した証拠です。
Busabaseでは、対象Baseとレコードの状態を固定し、返されたカーソルを終点までたどり、現在のコミットから業務項目を読むことで、その範囲を説明できます。
最初に全件の範囲を決める
Recordsの取得ではbaseIdを明示します。省略するとSpace全体が対象になります。activeとarchivedも区別してください。現在の顧客を確認する作業に、ゴミ箱の履歴を混ぜると分母が変わります。
対象状態、フィルター、必要な項目、開始時刻を作業条件として保存します。一つの状態だけを調べたなら、報告もその範囲に限定します。
構造図・調整可能な設計
nextCursorがnullになるまで取得する
OpenAPIではrecords.listのlimitは最大100です。応答のrecordsが今回のデータ、nextCursorが続きの入口です。カーソルを解析せず、そのまま次の要求へ渡し、nullになるまで続けます。件数の少ないページを独自の終了条件にしないでください。
ページごとに件数、取得時刻、続きの有無を記録し、recordIdの重複を確認します。通信に失敗したら完了済みページと次のカーソルを保存します。未取得ページが残る結果は部分完了として扱います。
業務項目は現在のpayloadから読む
現在値はrecords[].headCommit.payloadにあり、キーは項目slugです。外側のBase、作成者、コミット情報はメタデータです。slugがなければ空として扱い、似た名前の別オブジェクトから補いません。
summary=trueは4 KBを超える値を省略マーカーへ置き換えます。候補の特定に使い、長文の確認にはrecords.getで完全なレコードを取得します。確認したheadCommitIdも残してください。
構造図・調整可能な設計
絞り込みと並び順の意味を確認する
records.listのfiltersは条件より広い集合を返す場合があるため、取得後の再判定が必要です。対応する厳密比較にはBaseを指定したvalueFiltersを使います。非対応の比較を、暗黙に別の条件へ変換しないことが大切です。
信頼できる項目ソートはnumberとdateが対象です。他の型で優先度順や文字順を推測しないでください。画面の表示とAPIの意味が同一とは限りません。
判断と一緒に取得台帳を渡す
接続済みAgentへの指示は、次のようにできます。
指定Baseのactiveだけを、nextCursor=nullまで取得してください。各ページの件数、recordId、headCommitIdを保存し、現在値はheadCommit.payloadから読みます。省略された長文は別途取得し、重複、空欄、失敗ページ、取得の開始・終了時刻を報告してください。未完了なら全件確認済みと書かないでください。
成果物には対象範囲、ページ数、総件数、固有ID数、失敗、終点を含めます。取得中に編集があれば、各要求が同じ瞬間の状態を示す保証はありません。カーソル巡回自体はスナップショット分離を約束しないため、重要な判断に使うレコードは直前に再読します。
構造図・調整可能な設計
読み終えた後も権限は別に確認する
全件取得は一括変更や外部送信の許可にはなりません。根拠と変更範囲を確認してから、認められた内容だけをChangeRequestで提案します。
REST APIガイドで接続を確認し、実際の一つの業務質問から始めてください。取得台帳を結論に添えれば、次の担当者も確認済み範囲と残作業を区別できます。