1. 試したこと：件数が合っても、全件扱いを保留できるか
資料を集めた後に「4件あるので全部です」と判断すると、重複や古い版が混ざったまま、次の仕事へ進むおそれがあります。今回は、同じ4行でも、何を確かめる必要があるかを残せるかに絞りました。
資料一覧を確認する一般手順を、短い架空の取得記録に当てはめた試作です。資料の本文を検索して回答する実験や、通知の再掲をまとめる実験ではありません。
2. 作り方の要点：範囲・ID・取得の状態を分ける
架空の資料4件と6条件
基準の台帳V1には、資料ID「D1・D2・D3・D4」を記載しました。対象は「架空資料室の直下にある手順書、旧版とごみ箱を除く、担当Aの閲覧範囲」、基準時点は2026年10月27日9時です。実在の資料名・会社名・宛先・本文は使っていません。
以下は、この共通範囲について作った架空の記録です。「続き」は最後に取得したページの次があるか、「検索完了」は検索対象を調べ終えた記録があるかを表します。サービス固有の仕様ではありません。
| 条件 | 提供されたページのID | 続き | 検索完了 | ページの版 |
|---|---|---|---|---|
| A | D1・D2 ／ D3・D4 | なし | 完了 | V1・V1 |
| B | D1・D2・D3・D4 | あり | 完了 | V1 |
| C | D1・D2・D3・D4 | なし | 未完了 | V1 |
| D | D1・D2・D3・D4 | 不明 | 不明 | V1 |
| E | D1・D2 ／ D2・X1 | なし | 完了 | V1・V1 |
| F | D1・D2 ／ D3・D4 | なし | 完了 | V1・V2 |
「／」はページの区切りです。Fは、取得途中でD4の本文が変わったという架空設定です。実際に更新を起こしたり、更新中のサービスへアクセスしたりはしていません。Bの「4件あるのに続きあり」も、台帳と取得記録の食い違いとして意図的に含めました。
整理前に固定した想定と、AIへの指示
AIの整理前に、Aは「記録上は条件がそろうが人の確認待ち」、B〜Fは順に「続きあり」「検索未完了」「記録不明」「ID不一致」「版混在」で保留する想定を保存しました。確認する記録と戻り先も書き、整理後にファイルのハッシュが変わっていないことを確認しました。
初版は「取得行数と基準件数だけを整理する」、修正版は次の指示で処理しました。
行数だけでなく、IDの重複・不足・余分、続き、検索完了、版を整理してください。各行に全件扱いの候補、保留理由、確認する記録、戻り先、人の確認待ちを残してください。不明を「続きなし」「完了」に置き換えず、後工程は実行しないでください。
作業しているAI自身が初版・修正版を各1回整理しました。外部APIや追加の依存パッケージは使っていません。想定表を同じAIが参照できるため、盲検での比較ではありません。
コードは件数とIDの差だけを計算
Pythonの標準ライブラリで、ページをつないだ行数、異なるIDの数、重複ID、台帳にあるのに不足するID、台帳にない余分なIDを出しました。計算の中心は次の部分です。
ids = [item for page in case["pages"] for item in page]
counts = Counter(ids)
missing = sorted(baseline - counts.keys())
extra = sorted(counts.keys() - baseline)コードは資料を取得せず、全件とも判定しません。AIは計算出力と架空の状態記録を読み、確認理由を文章にする役割です。
3. 結果：4行一致でも、保留理由は五つに分かれた
初版はA〜Fのすべてを「取得4行・基準4件・件数一致」と整理しました。件数としては合っていますが、行ごとの違いは残りませんでした。
修正版を、コードの出力と事前の想定に読み合わせた結果です。表は左右にスクロールできます。
| 条件・集計結果 | AIが残した整理・理由 | 確認する記録と戻り先 |
|---|---|---|
| A：4行・4ID、ID一致 | 記録上は条件がそろう。人の確認待ち | 資料管理担当が対象範囲・台帳V1・取得記録を照合 |
| B：4行・4ID、ID一致 | 保留。続きがあり、4件の台帳とも食い違う。人の確認待ち | 取得担当が続きの記録、資料管理担当が台帳の範囲を確認 |
| C：4行・4ID、ID一致 | 保留。続きなしでも検索未完了。人の確認待ち | 取得担当が検索対象と完了記録を確認 |
| D：4行・4ID、ID一致 | 保留。続き・完了の記録が不明。人の確認待ち | 取得担当が欠けた取得記録を確認 |
| E：4行・3ID、D2重複、D3・D4不足、X1余分 | 保留。行数は合ってもIDの構成が違う。人の確認待ち | 取得担当と資料管理担当が元ページ・範囲・IDを確認 |
| F：4行・4ID、ID一致 | 保留。V1・V2が混在し、V1時点の一覧とは確かめられない。人の確認待ち | 資料管理担当と取得担当が基準時点・版と取り直す方法を確認 |
Eの4行には、D2が2回入っています。重複を除くと3IDで、さらにX1が余分です。「行数が合う」と「必要なIDがそろう」は別でした。重複だけを除いても、D3・D4は戻りません。
FはIDの集合まで一致しています。それでも、今回はD4の本文が変わった設定なので、IDだけでは同じ時点の内容がそろったとは扱えません。単に取り直せば必ず解決するとも言えず、実サービスで同一時点の一覧を作れる方法は別途確認が必要です。
6条件の整理・理由・戻り先は事前の想定と一致し、不一致や再試行はありませんでした。ただし、同じAIによる読み合わせであり、正答率ではありません。 Aも台帳が正しいという架空の前提に依存しています。台帳自体の抜けや、担当Aに見えない必要資料を検出したわけではありません。
かかった時間と測った範囲
2026年10月27日、想定保存後のUTC 01:07:22から、集計コードの作成・実行、AIの初版・修正版と読み合わせの保存後の01:08:03まで、経過は41秒でした。素材と想定の準備、事前調査、指示の検討、記事制作、サイトのビルド・表示確認は含みません。人の確認時間や業務の削減時間、AI単体の処理速度を測った値ではありません。
4. うまくいかなかったことと、直したこと
初版では件数しか残らず、B〜Fをどの記録へ戻すか分かりませんでした。そこで、素材と想定は変えず、出力列と指示を広げました。修正版では、各行だけを見ても保留理由と確認先が追える形になりました。
初版には意図的に「件数だけ」という制限を付けています。AIが自然に誤った全件判定を出し、それを修正した実験ではありません。今回確かめたのは、件数だけの表では失われる違いを、確認記録として残すことです。
修正版でも、Dの欠けた記録は埋まっていません。Fの版をそろえて実際に取り直す処理、人の回答・判断の記録も未実施です。大量資料、IDの変更・別名、ページ取得の失敗、実際の権限差、画像・OCRは試していません。
5. 実際の業務で使う前に確認すること
- 基準の範囲：フォルダ・期間・種類・旧版・権限と基準時点を決め、比較する台帳がその範囲を網羅するか、人が確認します。
- 取得の記録：利用するツールの公式説明で、続き・検索完了を何で確かめるか確認します。表示のない項目をAIに推測させません。
- IDと版：重複を除いた件数だけでなく、不足と余分を照合します。取得中の更新がある場合は、どの時点としてそろえるかを決めます。
- 保留の引き継ぎ：不足記録、確認を引き受ける人、回答予定を残します。AIの分類と担当者が独立に確認した結果を比べてから、実務での利用を判断します。
- 次の作業：全件の確認と、集計・削除・通知の許可は分けます。必要な情報だけをAIに渡し、次の操作の対象と内容を人が確認します。
取得停止後にどこから再開するかはフォルダ監視の復旧手順を参照してください。この試作では、再開処理の安全性は確認していません。
6. 相談への案内
「一覧の件数は合うのに、必要な資料が抜ける」「全件かどうかを誰に聞けばよいか分からない」といった困りごとから、範囲と確認工程を整理できます。書類処理AIのガイドとサービス・料金をご覧のうえ、現在の流れをお知らせください。