書類の工程履歴から再開と確認待ちを分け、人が扱いを記録するデモ

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

書類を取得済みでも、保存・通知・転記がすべて終わったとは限りません。同名の別書類や旧版の完了を流用せず、未着手と結果不明を分け、再開前に人が確認する記録と担当を残すことを課題にしました。

実施内容

架空の書類6件・7組・21工程を読み合わせた検証ラボをもとにしたデモです。明細の閲覧、人の判断と必須項目、通知から転記への記録順序、意図的な誤りの教材、入力変更後の再整理待ちと判断の解除、引き継ぎ表の書き出し、履歴編集と候補JSONの手動取り込みを加えています。精度・正答率・正しさや導入の可否は評価しておらず、時間短縮・費用効果も測定していません。

取得済みでも、工程の履歴は異なる6書類

• 全6書類を取得済みとする設定です。書類3だけ第1版・第2版があり、7組それぞれの保存・通知・転記を分けた21工程を扱います。保存は7組とも再実行不要という想定です。
• 書類1と書類4はどちらも受付票Aですが、書類IDと受付番号が違う別書類です。書類1は全工程完了、書類4は保存だけ完了で、通知と転記は未着手・実行者なし・手動処理なしとしています。書類2も通知と転記が未着手です。
• 書類3の第1版は全工程完了、第2版は数量の訂正で保存だけ完了しています。旧版への訂正方法が未決のため、新版の通知と転記は確認待ちです。旧版の完了を新版へ流用しません。
• 書類5は全工程完了後に受付箱から保管箱へ移動しただけです。移動を新規受付や再処理の理由にしません。
• 書類6は保存完了ですが、通知開始後に記録が途切れて送信結果が不明で、転記履歴も欠落しています。欠落を未実行とせず、通知先の控え・送信結果と転記先・手動処理の有無を確認するまで再実行しません。
• 書類ID・版・受付番号は教材内の記号です。工程名と履歴項目も試作独自のもので、特定のサービスの記録形式や機能を示しません。実在の会社・人物・取引の情報は使っていません。

デモで加えた人の記録と引き継ぎ

• 書類単位のA・工程別のB・意図的な誤りの教材を切り替えます。Aは6件の取得済み一覧、Bは7組・21工程と、先に固定した想定表の比較です。想定表は人が評価した正解表ではありません。
• 明細を開き、人が扱い・理由・担当の役割名を入力します。確認待ちでは確認する記録と確認先も必須です。人の欄とチェックは毎回空から始まり、読み取り専用の候補は「下書きを写す」を押したときだけ理由・確認先・確認する記録へ写します。記録後は欄を消し、前回の判断を欄の外に表示します。
• 書類2・書類4は通知を「再開する」と記録してから、転記を「再開する」にできます。依頼する順序だけの制御で、通知が完了したことを実証するものではありません。通知の判断を書き直すと同じ組の転記の判断も解除します。
• デモの「再開する」は人の確認後の扱いで、実行の許可ではありません。どの扱いでも処理状態は「人の確認待ち（担当が原記録で確かめ、再開の確定者が決める）」のままです。
• 未判断を含む全工程の引き継ぎ表と、判断・無効化の履歴をJSON・CSV・Markdownで書き出せます。入力した履歴は、判断や書き出しによって書き換えません。
• 履歴のJSONを編集するか、CSVを貼り付けて反映できます。同じ書類ID・版・受付番号・工程の重複や想定外の値は拒否します。状態の空欄はnull（資料なし）とし、未着手や完了で埋めません。
• 入力を変えた書類は、同じ書類IDの別の版も含めて再整理待ちになり、保存済み候補を使えなくなります。元に戻しても復活せず、AIも再処理しません。入力・候補・版の変更による判断の解除は「コード（入力・候補の変更）」として履歴に残し、人の判断と分けます。
• 整理用の指示をコピーし、別に作った候補JSONを人が確認して取り込めます。全工程を1行ずつ含める必要があります。デモから生成AIへは接続せず、受け渡しは人が行います。

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

• 実演モードは保存済みのAI出力例の再生で、その場でAIを呼びません。外部API・APIキーは不要で、保存・通知・転記の実処理、ファイル監視、外部接続の機能はありません。
• 教材には、書類6の欠落を未実行とする、書類3の新版へ旧版の完了を流用する、書類4を同名の書類1と取り違える、書類5の移動を新規受付とする誤りを意図的に入れています。AIの自然な失敗の観察や、AI・コードが誤りを検出できた結果ではありません。
• 比較用のAでは判断を記録できず、教材では「確認待ち」だけを記録できます。教材の書き出しには「【教材の版・照合用】」、version、teaching: trueが残ります。

使った技術

Node.js、JavaScript、ブラウザの画面、JSON、CSV、Markdown。Node.js 22以上で動き、追加パッケージは不要です。npm startでローカルサーバーを起動し、npm run checkで構文を確認できます。MIT Licenseで公開されています。元の検証ラボのPython標準ライブラリは、文字履歴にID・版・受付番号を付けた一覧を作るだけで、状態の判定や工程の実行はしていません。

AIと人の役割

検証で扱った課題・制約

• 元の検証ラボの初版は、意図的に名前と取得済みの状態だけを1書類1行で残す指示でした。6件とも取得済みと整理できても、工程の完了や再開する工程を表せず、同名の別書類と旧版・新版も追いにくくなりました。AIが自然に誤った再実行をして、それを防げた実験ではありません。
• 修正版でも書類6の送信結果と欠けた履歴、書類3の訂正方法は分からないままです。「確認待ち」と書けたことは、業務が復旧した成果ではありません。

検証から得た学び

• 元の検証ラボでは素材と想定を変えず、書類・版・工程ごとの扱い・根拠・確認先を残す指示に修正しました。再開する4工程（書類2・書類4の通知と転記）、再実行不要13工程、確認待ち4工程（書類3の新版と書類6の通知と転記）が事前の想定と対応し、不一致はありませんでした。同じAIが想定表を参照できる条件の読み合わせで、盲検比較や人の評価、正答率ではありません。初版・修正版の前後で想定ファイルのSHA-256も一致しました。
• 取得済みと各工程の完了は別です。同名や移動だけを再処理の理由にせず、旧版の完了を新版へ流用しません。履歴の欠落を未実行と見なさず、結果不明は確認まで再実行しない形にしました。
• 明細閲覧、人の判断と必須項目、記録順序、教材、再整理待ちと判断の解除、書き出し、履歴編集、候補JSONの取り込みはデモで加えたもので、ラボの観察結果とは分けています。

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

• 書類の取得済みだけで再開を決めず、保存・通知・転記ごとの履歴と確認先を整理したい場合。
• 原記録に戻れる担当と再開の確定者を決め、訂正方法や送信結果が不明なら確認まで止められる場合。
• 正式な識別項目、通知結果の照会、転記先の突合、訂正方法、役割別権限、監査記録の永続保存、二重実行の防止、実行直前の承認を別途用意できる場合。

補足

データはメモリー内だけで、再読み込みで初期状態に戻ります。版は第1版・第2版、工程は保存・通知・転記に限り、最大150行です。候補JSONの構造と識別項目は検査しますが、内容の正しさは保証しません。明細を開いたことやチェックは原記録を調べた証明ではありません。元の検証ラボでは実際の再開処理、同時実行、履歴の永続保存、大量書類や長い履歴は試していません。向いている条件は仕組みと限界から整理したもので、実案件への適用を確認したものではありません。