資料一覧を件数・ID・続き・版で確かめ、人が全件扱いと保留の理由を残すデモ

想定した課題・業務フロー

集めた一覧が台帳と同じ4行でも、資料の重複や不足、取得途中の更新が残ることがあります。行数の一致と必要な資料がそろうことを分け、確認する記録と担当を残し、全件扱いを人の確認待ちにすることを課題にしました。

実施内容

架空の資料一覧6条件を読み合わせた検証ラボをもとにしたデモです。明細を開く操作、確認チェックと保留の必須項目、全件扱いの記録を止める条件、意図的な誤りの教材、再整理待ちと判断の無効化、確認一覧・確認依頼・履歴の書き出し、作業用コピーの編集、手動取り込みを加えています。精度・正答率・正しさや導入の可否は評価しておらず、時間短縮・費用効果も測定していません。

同じ4行でも、確かめる記録が違う6条件

• 基準は台帳V1のD1・D2・D3・D4です。対象は「架空資料室の直下にある手順書、旧版とごみ箱を除く、担当Aの閲覧範囲」、基準時点は2026年10月27日9時です。D1〜D4・X1とV1・V2は教材内の記号です。
• AはD1・D2とD3・D4の2ページで、続きなし・検索完了・V1とV1です。記録上は条件がそろいますが、人の確認待ちです。台帳自体の抜けや担当Aに見えない資料を検出したわけではありません。
• Bは4IDがそろっても続きがあり、台帳4件とも食い違うため保留します。Cは続きなしでも検索未完了、Dは続き・検索完了の記録が不明です。不明を「なし」「完了」に置き換えません。
• EはD1・D2とD2・X1で、4行でも異なるIDは3件です。D2の重複、D3・D4の不足、X1の余分を分けて残します。重複を除いても不足資料は戻りません。
• FはD1〜D4がそろってもV1・V2が混在します。取得途中でD4の本文が変わった架空設定で、同じ時点の一覧としては扱いません。
• 「続き」「検索完了」「ページの版」は試作独自の項目で、特定のサービスの応答形式や機能を示すものではありません。

デモで加えた人の記録と、入力変更後の扱い

• 台帳と取得記録を読み、「件数だけ」「根拠付き」「意図的な誤りの教材」を切り替え、集計・記録・候補・想定表を見比べます。想定表は先に固定した表で、人が評価した正解表ではありません。件数だけの版でも、コードの集計には条件ごとの違いが残ります。
• 条件の明細を開き、人が判断・理由・担当を入力します。保留では確認する記録と確認先も必須です。対象範囲・台帳・原記録を確認したチェックがなければ記録できません。判断・理由・確認先に初期値は入りません。
• 下書きは欄の外に表示し、「下書きを写す」を押した場合だけ入力欄へ写します。記録後は欄を空にし、前回の判断を欄の外に表示します。同じボタンを押し直しても履歴を二重に残しません。
• 比較用・教材の版では保留だけを記録でき、「全件として扱う」は記録できません。人が根拠付きの版で「全件として扱う（人の確認済み）」を記録しても、処理状態は「人の確認待ち」です。後工程の許可にはなりません。
• 確認一覧・確認依頼の下書きと採用文・判断履歴をJSON・CSV・Markdownで確認し、書き出せます。未記録の条件も残し、入力中の下書きは含めません。
• 台帳JSONと取得記録CSVの作業用コピーを編集し、条件を追加できます。条件は1〜30件、1条件は1〜20ページ、1ページは1〜100IDです。想定外の値は弾き、版の空欄も不明として全件扱いを止めます。配布ファイル自体は変更しません。
• 取得記録を変えた条件の候補と判断を無効にし、台帳を変えると全条件が再整理待ちになります。入力を元に戻しても古い候補は復活せず、AIは再処理しません。無効化は「コード（入力・候補の変更）」として履歴に残ります。
• 整理用の指示をコピーし、任意の生成AIの出力や人が作った候補JSONを手動で貼り付けられます。現在の入力・版と合わない候補は取り込まず、保存済みの候補と区別します。アプリから接続・送信はせず、候補JSONに書かれた指示やコードも実行しません。
• 入力と判断は画面のメモリー内だけで、再読み込みで初期化します。

実演モードと、意図的な誤りの教材

• 実演モードは保存済みのAI出力例の再生で、その場でAIを呼びません。外部APIや自由入力の生成AIへの接続、資料を取得する機能はありません。
• 教材にはBの続きの無視、Dの不明の置き換え、Eの重複・不足・余分の見落とし、Fの版の見落としを意図的に入れています。止める理由は画面の注記とコードの集計に置きます。AIの自然な失敗を観察した結果や、AI・コードが誤りを検出できた結果ではありません。
• 教材の書き出しには先頭の「【教材の版・照合用】」とversion・teaching: trueが残ります。

使った技術

Node.js、JavaScript、ブラウザの画面、JSON、CSV、Markdown。Node.js 22以上で動き、npm startでローカルサーバーを起動します。追加の依存・APIキーは不要で、.envは読み込みません。標準モジュールとブラウザー標準機能だけを使い、MIT Licenseで公開されています。元の検証ラボはPythonの標準ライブラリで行数・異なるID数・重複・不足・余分を計算し、資料の取得や全件の判定はしていません。

AIと人の役割

検証で扱った課題・制約

• 元の検証ラボの初版は、6条件とも「取得4行・基準4件・件数一致」と整理し、行ごとの違いや戻る記録が残りませんでした。「件数だけ」は意図的に付けた制限で、AIが自然に誤った全件判定を出したわけではありません。
• Eは行数が合っても必要なIDが不足し、FはIDの集合が合っても版が混在しました。件数・ID・同じ時点の内容がそろうことは分けて確かめる必要がありました。

検証から得た学び

• 元の検証ラボでは素材と想定を変えず、出力列と指示を広げました。修正版は6条件の整理・理由・戻り先が事前の想定と一致し、不一致や再試行はありませんでした。想定を参照できる同じAIによる読み合わせで、盲検比較や人の評価、正答率ではありません。整理後も想定ファイルのハッシュが変わっていないことを確認しています。
• Aも台帳が正しいという前提に依存します。台帳自体の抜けや実際の閲覧権限の差を確認したわけではなく、記録上の一致だけで全件とは確定できません。
• ラボのコードは行数とIDの差の計算までです。明細閲覧、確認チェックと保留の必須項目、全件扱いを止める条件、教材、判断の無効化、書き出し、作業用コピーの編集、手動取り込みはデモで加えたものです。

同様の取り組みが向いている条件

• 資料の整理や確認を始める前に、取得した一覧を件数だけで全件と扱わず、ID・続き・完了・版を分けて確認したい場合。
• 取得担当・資料管理担当・全件扱いの確定者を決め、不足記録や版の混在を確認先へ戻せる場合。
• 原記録の保全、閲覧権限と台帳の網羅性、版と基準時点の定義、確認先の回答、承認権限、監査記録・保存先を別途用意できる場合。

補足

資料の取得・削除・業務上の集計・通知・取り直しなどの後工程や、外部接続の機能はありません。保留の解消、全件扱いの最終確定、後工程の許可はデモの外です。元の検証ラボではDの欠けた記録の補完、Fの取り直し、人の回答・判断の記録、大量資料、IDの変更・別名、ページ取得の失敗、実際の権限差、画像・OCRは試していません。向いている条件は仕組みと限界から整理したもので、実案件への適用を確認したものではありません。