AIエージェントの一覧取得｜全件を確認したと言える条件

「未対応の問い合わせを一覧にして」とAIエージェントへ頼み、きれいな表が返ってきた。ところが、担当者が業務画面を開くと、表にない案件が残っている。こうした取りこぼしは、AIの文章表現を直すだけでは解決しない場合があります。

業務システムは、大きな一覧を何回かに分けて返すことがあります。一回の取得に成功したことと、指定した対象を最後まで取得したことを分けるのが、一覧を使う業務の基本です。

本記事はGoogle DriveとMicrosoft Graphの公式資料を2026年11月3日に確認した基礎解説です。新機能の提供開始を伝える記事ではありません。以下の受付業務は仮想例であり、確認手順はIvyLeapの設計提案です。

最初に「全件」の対象を一文で決める

AIへ渡す依頼が「問い合わせを全部調べて」だけでは、取得を終える条件を定めにくくなります。部署、期間、状態、保存場所など、対象を絞る条件を先に決めます。

例えば、AIコールセンターの担当者支援なら、「営業部の受付記録のうち、昨日までに受け付け、現在も折り返し未完了の案件」を探す、といった定義です。これは、全社の全期間の案件を探す依頼とは異なります。

担当者と開発者がそろえておきたいのは、次の四点です。

• 対象に含める部署・保存先・期間。
• 未対応や完了など、検索に使う状態の定義。
• ごみ箱・取消済み・保管済みの記録を含めるか。
• 誰の権限で閲覧できる記録を対象にするか。

例えばGoogle Driveのファイル一覧は、標準ではごみ箱内のファイルも含みます。除きたい場合は、その条件を指定する仕様です。画面で普段見ている一覧とAPIの取得条件が同じか、確認が必要です。Google Drive公式資料：files.list

「閲覧できた範囲で該当する全件」と「会社に存在する全件」も同じではありません。権限そのものの設計は、利用者ごとの検索権限で扱っています。

一ページ目の成功で、一覧取得を終えない

システムが一覧を分割して返す仕組みを、ページ分割と呼びます。画面の「次へ」に似ていますが、APIでは次の取得先や続きの情報が応答に含まれます。

Microsoft Graphは、続きがある場合に次ページのURLを返し、それが返らなくなるまで取得を続けると説明しています。また、そのURLの一部分を抜き出して作り直すのではなく、返されたURL全体を使うよう案内しています。Microsoft公式資料：一覧のページ分割

導入担当者は、細かな実装方法を覚えるより、「一回で返る上限を超える案件があるとき、続きをどこで確かめているか」と質問するとよいでしょう。AIに「最後まで読んで」と書くだけで、連携処理が自動で続くとは限りません。

仮に、条件に一致する案件が235件あり、取得結果が100件、100件、35件に分かれて返る例を考えます。最初の100件だけで表を完成させると、残り135件が業務から落ちます。この数字は説明用で、特定サービスの標準件数を示していません。

返ってきた件数が少なくても、終端とは限らない

一回の取得件数が少なかったとき、担当者は「もう残りがない」と考えがちです。しかし、Microsoft Graphの公式資料は、一ページに含まれる結果が0件以上であること、ページサイズなどの挙動がAPIごとに異なることを説明しています。Microsoft公式資料：ページごとの挙動

そのため、件数だけを終了条件にせず、利用しているAPIが示す続きの有無を確かめます。例えば、空の応答でも続きの情報がある場合は、「該当なし」と確定せず、仕様に沿って次を確認する設計が必要です。

Google Driveには、検索が一部で完了しなかったことを示す情報もあります。複数ドライブを横断した検索などで発生し得るため、次ページの有無とは別に確認します。Google Drive公式資料：検索の未完了を示す情報

業務担当者が見る報告にも、「続きなし」「検索自体の未完了なし」を分けて残すと、少ない件数をそのまま成功と扱う誤りを減らせます。

途中でデータが変わる場合は、取得時点を記録する

一覧を読み進めている間にも、別の担当者が案件を追加したり、状態を完了へ変えたりする可能性があります。最後までページを取得しても、同じ時刻の全データを固定して読んだとは限りません。

Google Driveは、ページを取得する間に項目が追加・削除されると、想定する結果が変わり得ると説明しています。また、続きの取得に使う情報が拒否された場合は、それを捨てて最初のページから再開するよう案内しています。Google Drive公式資料：続きの情報と結果の変化

自社の報告では、取得開始時刻と終了時刻、使った条件、途中で再開したかを記録します。厳密に同じ時点の集計が必要な業務なら、接続先が提供する時点固定の取得や、所定時刻の出力ファイルを使えるか、管理者へ確認します。利用できる仕組みを確認せず、「この時点の完全な一覧」とは表示しません。

重複の照合には、名称だけでなく、接続先が発行する案件IDやファイルIDを使う設計が候補になります。同じ名前の別案件を消さず、同じIDを再取得した場合は、どの版・状態を採るかを決めます。単に重複行を消すだけでは、取りこぼしがないことまでは証明できません。

途中終了の一覧を、完了報告に使わない

時間や処理回数の上限で止まること自体は、運用上あり得ます。そのときは、取得済みの部分と未確認の部分を分けて返します。

先ほどの235件の仮想例で、二ページ目の取得前に停止したなら、「条件に合う案件は100件です」とは報告しません。「取得済み100件。続きの取得は未完了」と表示し、担当者が追加確認の必要を判断できる状態にします。接続先の総件数が分からない場合は、残数を推測して埋めません。

報告に残したい項目は、対象条件、取得できた件数、IDで照合した件数、続きの有無、未完了やエラーの理由、確認時刻です。保存する記録に接続用の秘密情報を含める必要はありません。

また、取得した一覧を使って顧客へ連絡する処理は、読み取りと分けます。途中までの一覧でも連絡を始めるのか、確認を待つのかを業務側で決め、再開時に同じ案件へ重複して連絡しないようにします。データを送る先の受領・取り込み確認については、ファイル連携の完了条件も参考になります。

導入前に試したい六つの場面

実際の顧客データを使う前に、検証用の保存先と架空の記録で、次を確かめます。

1. 一回の上限を超える件数を用意する。 最後のページに置いた確認用の案件まで取得できるか。
2. 少ない件数や空のページに、続きの情報を付ける。 件数だけで該当なし・完了としないか。
3. 検索が未完了という応答を返す。 取得成功と検索全体の完了を混同しないか。
4. 同じIDの記録が再び返る。 重複して数えず、同名の別IDを残せるか。
5. 途中で通信や続きの情報が無効になる。 接続先の仕様に沿って再開し、途中結果を全件と表示しないか。
6. 取得中に案件の追加や状態変更が起こる。 取得時刻と条件を残し、時点固定を確認していない結果へ断定的な表示をしないか。

試験結果は、期待した案件IDと実際に取得したIDを対応付けて確認します。画面上の行数が合っただけで終わらせず、最後の案件、途中で再取得した案件、対象外にした案件の扱いを見ます。

AIエージェントの一覧取得では、表が読みやすいかに加えて、その表がどの範囲の何を表しているかが大切です。まず一つの一覧業務を選び、「対象条件」「続き」「途中終了」の三点を担当者と開発者でそろえてみてください。

IvyLeapのAIエージェント構築支援では、業務システムとの連携や確認手順を整理できます。現在AIに任せたい一覧業務と、取りこぼすと困る記録をまとめて、お問い合わせください。

※公式資料は2026年11月3日に確認。ページ分割・検索範囲・取得中の変更への対応は、採用するサービスとAPIごとに異なります。資料の確認日を機能の提供開始日とは扱っていません。