まずは、停止期間から再開後の照合までを6段階で進める

hirostaの提案は、対象を一覧にしてから、未処理の工程だけを進める方法です。 次の順序で、業務担当者と保守担当者・委託先が確認します。

  1. 止まっていた期間を確かめる:最後に正常に処理した時点と、再開した時点を記録で確認する。
  2. 変更取得の再開位置を確かめる:保存していた開始位置があり、その位置から必要な変更を取得できるかを確認する。
  3. 拾い直す一覧を作る:停止中に追加・変更・削除・移動されたファイルを整理する。
  4. 取得と業務の処理を分ける:取得済みか、保存・通知・転記が済んでいるか、どこが未処理かを記録と照合する。
  5. 未処理だけを進める:処理済みを再実行せず、分からないものは確認待ちにする。
  6. 再開後に人が照合する:一覧と処理先の記録が合い、漏れや二重処理がないかを確認する。

書類受付全体の流れや、再送・差し替えの扱いはLINEの書類受付・確認・転記の記事で説明しています。停止原因の切り分けはAIの作業が止まったときの記事に譲り、ここでは停止中のファイルの拾い直しに絞ります。

1. 最後の正常処理と、再開時点を記録する

監視の記録、取得の記録、保存先や通知先・転記先の記録を並べ、最後にどのファイルのどの工程が正常に終わったかを確かめます。監視が動いていた時刻と、業務処理が最後まで終わった時刻は別に残してください。

  • 対象のフォルダと、その中のどこまでを監視していたか。
  • 最後に正常に処理したファイル、工程、日時と、その根拠になる記録。
  • 監視の停止を確認した日時と、再開した日時。時刻の基準も揃える。
  • 停止中に人が手動で保存・通知・転記した対象と、その記録。

停止に気付いた時刻を、そのまま停止開始時刻にはしません。最後の正常処理以降が不明なら、その時点から再開時点までを確認対象に含めます。分からない境界は「確認待ち」として残します。

2. 保守担当者と、変更取得を再開する位置を確かめる

開始位置とは、変更の一覧をどこから読み進めるかを示す情報です。まず保守担当者に、保存していた位置と取得の記録があるか、取得した内容と業務処理の記録が対応するかを確認してもらいます。取得位置だけが先に進み、転記が途中で止まっている場合もあるためです。

Google Drive APIで確認したこと

2026年10月20日に確認した公式ガイド「Retrieve changes」では、次のように説明されています。これはGoogle Drive APIの説明であり、ほかのサービスに同じ仕様があるという意味ではありません。

  • changes.getStartPageToken は、アカウントの現在の状態に対する開始用のページトークンを取得し、初回の changes.list に使います。
  • changes.list でログイン中のユーザーの変更を取得します。変更されたファイルについて返されるのは現在の状態です。削除・共有項目を取得結果に含めるかは、includeRemoved や restrictToMyDrive の指定に関係します。
  • nextPageToken があれば、その続きのページを取得します。続きがなければ、返された newStartPageToken を次回の変更取得用に保存します。
  • 変更通知は、新しい変更があることを知らせるもので、変更内容そのものを含みません。内容は変更の一覧から取得します。

再開時に取得した「現在の開始位置」だけでは、停止中の変更を拾い直した証拠になりません。保存していた位置から続きのページを最後まで取得できるか、対象のフォルダ・共有範囲を含められるかを、保守担当者と確認します。この記事ではトークンの有効期間や、すべての移動履歴を復元できることは断定しません。

変更の通知・取得の記録は、すべての改訂の履歴でも、業務処理の完了証拠でもありません。途中の変更や以前の場所まで分かると決めつけず、取得結果と業務側の記録を分けて扱ってください。

保存していた位置が使えない、記録が足りない場合

フォルダの現状のファイル一覧・更新日時と、最後の正常処理以降の保存・通知・転記の記録を突き合わせます。以前の一覧や移動・削除の記録が残っていれば、それも保守担当者に確認してもらいます。

現状の一覧だけでは、すでに削除された書類、フォルダの外へ移動した書類、途中で差し替えられた内容を確定できない場合があります。更新日時だけを根拠に「この期間のすべてを回収できた」とせず、不明な対象・期間と、追加確認する担当者を残します。

3. 追加・変更・削除・移動を拾い直す一覧にする

次の列を用意し、記録から分かる変化を書きます。これはhirostaの提案する管理方法で、サービスの標準画面ではありません。

列 記入する内容
ファイル名 書類の名前。同名を区別できるファイルID・受付番号も併記する
場所 現在のフォルダ。移動前の場所が分かれば併記する
止まっていた間の変化 追加・変更・削除・移動。種類や順序が不明なら確認待ちと書く
取得済みか 対象の版を取得済み・未取得・確認待ちのいずれかにする
業務で処理済みか 保存・通知・転記の工程ごとに、処理済み・未処理・確認待ちを分ける
処理した記録 保存先、通知履歴、転記先の受付番号など、照合できる参照先
確認した人と日付 確認者、確認日、保留なら引き継ぎ先も残す

ファイル名だけで同じ書類と判断しません。同じファイルの内容が変わった場合は、以前の版の処理記録と、今の版の処理状況を分けます。ファイルIDと業務の受付番号が対応するかも確認してください。

削除・移動を見つけても、転記先を自動で削除したり、同じ書類を新規受付として処理したりしません。削除されたのか、権限や対象範囲の変更で見えないのかを含めて確認し、業務上の取消・訂正が必要なら担当者の判断へ戻します。

4. 想定シナリオ:取得済みでも、通知・転記は終わっていない

以下は架空の「サンプル商事」の請求書受付を想定したシナリオです。会社名・書類・番号・担当者名は説明用で、hirostaやお客様の実績ではありません。監視停止中に届いた書類を、再開日に照合する場面です。

ここでは、一覧の1行分に当たる内容を項目別に示します。

拾い直し一覧の1件分の記入例

  • ファイル名:サンプル商事向け請求書A.pdf(ファイルID:例A、受付番号:例001)。
  • 場所:共有フォルダ内の「請求書/受付」。
  • 止まっていた間の変化:追加。受付記録と取得記録で確認。
  • 取得済みか:取得済み。取得した版と現在の書類を照合。
  • 業務で処理済みか:保存は処理済み、通知と転記は未処理。各工程の記録を担当者が照合。
  • 処理した記録:保存先の受付番号「例001」。通知履歴と転記先には対応する記録がなく、担当者も未実行と確認。
  • 確認した人と日付:担当者A、2026年10月20日。

この場合は、保存を繰り返さず、確認した通知・転記の工程だけを進めます。履歴がないという理由だけで未処理とせず、記録が欠けていないか、人が別の方法で処理していないかも確かめます。

ほかの書類では、次のように判断を分けます。

  • 請求書Bが差し替えられていた:旧版を転記済みでも、新版まで処理済みとはしない。変更内容と訂正の要否を人が確認し、新規の請求書として二重に転記しない。
  • 申込書Cが受付から確認済みフォルダへ移動していた:同じファイルID・受付番号と確認記録が対応するなら、移動だけを理由に再通知しない。
  • 請求書Dが一覧からなくなっていた:削除や移動の根拠が見つからなければ、変化の種類も処理状況も確認待ち。取り消し済みとは推測しない。

5. 未処理だけを処理し、通常の監視と重ねない

一覧の各工程について、未処理と確認できた対象だけを担当者が再開対象にします。「取得済みだから完了」「完了記録が見当たらないから全部やり直す」という進め方は避けます。

保守担当者・委託先とは、拾い直しと通常の監視が同じ書類を同時に処理しないかを確かめます。同じ受付番号・対象の版について、処理直前に処理済み記録を照合する方法と、担当を重ねない手順があるかを確認してください。再開後に新しく届く書類と、停止中の書類を分ける境界も記録します。

再開処理が途中で止まったときも、一覧に工程ごとの結果を残します。通知を送った直後に記録が止まったなど、結果が分からない工程は確認待ちへ戻し、送信先・記録先で照合するまで再実行しません。

6. 再開後に、一覧と実際の処理結果を人が照合する

業務担当者は、再開対象とした各ファイルについて、保存先、通知履歴、転記先の記録が一覧に対応するかを確認します。件数の合計だけでなく、受付番号と対象の版まで照合します。

  • 未処理として進めた工程に、完了を確認できる記録があるか。
  • すでに処理済みだった書類が、再通知・二重転記されていないか。
  • 削除・移動・差し替えの対象が、意図せず新規受付や取消として扱われていないか。
  • 通常の監視へ引き継いだ範囲と、拾い直しの対象がつながっているか。
  • 確認待ちの対象・期間、理由、担当者、次の確認日を残したか。

保守担当者には、変更取得が途中のページで止まっていないことと、次回用の位置を保存できたことも確認してもらいます。変更取得の完了と業務処理の完了を別々に報告し、不明な範囲が残れば「全件復旧済み」とは記録しません。

AIは照合の補助に使い、処理済みの確定は人が行う

AIを使う範囲は、一覧と処理記録の突き合わせの補助、未処理候補の洗い出し、復旧記録の下書きまでとします。処理済みかどうかをAIの推測で確定させません。 記録で確かめられないものは未確認として残し、人が正式な記録先で照合します。

利用する場合も、社内で許可した環境と情報の範囲を守り、書類本文や個人情報を必要以上に渡しません。似たファイル名や日時だけで、AIに同一書類・同一の版と決めさせないことが大切です。

背景:ファイル検知から保存までをつなぐ要望

日本AI導入支援協会が2026年10月7日に公表した調査には、ファイルの検知から分析・保存までを自動化したいという回答が紹介されています。2026年10月20日に掲載内容を確認しました。

これは同協会の企業向けAI活用セミナー申込者を対象とした調査で、全国の中小企業を代表する調査ではありません。 また、フォルダ監視の停止頻度や、本記事の復旧手順の有効性を調べたものでもありません。

自社の復旧手順を決める際は、自動化したい工程に加え、止まった間の変更と処理結果を何で確かめるかを整理してください。書類処理AIのガイドでは、業務全体でAIと人の役割を分ける判断材料を紹介しています。