二つの台帳の変更を分け、人が確認した項目だけをコピーへ反映するデモ

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

二つの台帳で同じ項目が変わったとき、日時だけで上書きすると採用値を決める根拠が残りません。同じ行でも価格と案内文の変更元が違う場合や、反映済みの変更が戻ってくる場合を分け、確認が必要な変更を止めることを課題にしました。

実施内容

架空の商品6件・2項目・8変更を整理し、Pythonで台帳のコピーへ項目単位で反映した検証ラボをもとにしたデモです。原記録の明細を開く操作、人の判断・理由・担当と保留の確認先の記録、反映直前の再確認、意図的な誤りの教材、入力変更後の判断の無効化、JSON書き出しと候補JSONの手動取り込みを加えています。精度・正答率・正しさや導入の可否は評価しておらず、所要時間・時間短縮・費用効果も測定していません。

架空の二つの台帳で確かめること

• 台帳A・Bには商品1〜商品6が各6行あり、共通の項目は価格と案内文です。価格は台帳AからBへ、案内文は台帳BからAへ、対象項目だけを反映する設定です。価格は試作用の架空の円表示で、hirostaの料金ではありません。
• 商品2は両方の台帳で価格が変わっているため、日時が新しい方を選ばず両方を保留します。商品管理担当とB入力担当が、依頼と承認票から採用値を決める想定です。
• 商品3は価格と案内文が別々に変わっています。それぞれの正本から項目だけを反映し、もう一方の変更を保持します。行ごとコピーすると、台帳Aの価格3,200が3,000に戻るためです。
• 商品4のB04は、反映元A04の完了控えがある再到着の設定です。変更IDと反映元IDを分け、同じ変更の反映と完了履歴を追加しません。
• 商品5は承認不明、商品6は前回値の記録なしとして保留します。商品管理担当が承認票を、案内担当と台帳担当が前回の照合控えを確認します。「記録なし」を空欄への変更として扱いません。
• 商品・役割・価格・変更ID・反映元ID・原記録はすべて架空です。「正本」「反映元ID」「完了控え」などの項目名と記録形式は試作独自のもので、特定のサービスの記録形式や連携機能を示しません。

デモで加えた人の確認とコピーへの反映

• 台帳A・B、項目別の正本表、8変更と完了控えを見て、商品単位・変更別・教材の版を切り替えます。先に固定した想定表は人が評価した正解表ではなく、すべての変更が人の確認待ちから始まります。商品単位の版は比較用で、判断の記録と反映はできません。
• 変更を選んで原記録の明細を開き、人が扱い・理由・担当を入力します。保留では確認する記録と確認先も必須です。入力欄は空から始まり、下書きは読み取り専用です。「下書きを理由・確認先へ写す」を押した場合だけ転記し、前回の判断は欄の外に表示します。
• 「コピーへ反映」は、人が「反映する」と記録した変更だけが対象です。コードが反映直前に反映先の現在値を再確認し、不一致なら保留へ戻します。記録後に反映先が変わる場面も再現でき、押し直しても二重に反映しません。
• デモ内の「反映する」はコピーへの反映についての確認で、実際の台帳への反映の許可ではありません。実際の反映の確定と実行は、デモの外で人が行います。
• 両側の値とコピーの値、候補の根拠、人の判断・理由・担当・確認する記録・確認先・回答予定、反映結果と判断履歴をJSONで書き出せます。未判断の変更は「確認待ち」として残ります。
• 台帳・正本表・完了控えはJSON、変更はフォームで編集でき、CSVで変更一覧を置き換えられます。価格の空欄・「記録なし」はnull、不正な値は入力エラーになります。配布したJSONは変更しません。
• 入力を変えると関係する変更は「再整理待ち」になり、保存済み候補を使えなくなります。台帳・正本表・完了控え・CSVの変更では全件が対象です。値を戻しても古い候補は復活せず、無効化は「コード（入力・候補の変更）」として履歴に残ります。入力を変えてもAIは再処理しません。
• 整理用の指示と項目の説明をコピーし、任意の生成AIの出力や人が作った候補JSONを手動で取り込めます。現在の入力・版と合わない候補は受け付けず、JSON内の指示やコードは実行しません。デモ自体は外部へ送信しません。

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

• 実演モードは保存済みのAI出力例の再生です。その場でAIを呼ばず、APIキー・外部APIは使いません。外部接続や実在のシステムへの書き込みの機能はありません。
• 教材には、日時が新しいB02の採用、商品3の行コピー、B04の再反映、B06の記録なしの空欄扱いを意図的に入れています。照合用の教材であり、AIの自然な失敗の観察や、AI・コードが誤りを検出できた結果ではありません。
• 教材の版では「保留」「反映不要」だけを記録でき、「反映する」の記録とコピーへの反映はできません。止める理由は画面の注記に置きます。
• 教材の書き出しには先頭の「【教材の版・照合用】」とversion・teaching: trueが残ります。

使った技術

Node.js、JavaScript、ブラウザの画面、JSON、CSV。Node.js 22以上の標準モジュールとブラウザーの機能を使い、追加パッケージは不要です。npm startでローカルサーバーを起動し、npm run checkで構文を確認できます。MIT Licenseで公開されています。元の検証ラボではPythonで反映条件を確かめ、架空台帳のコピーを更新しました。

AIと人の役割

検証で扱った課題・制約

• 元の検証ラボの初版は、商品ごとに差と「要確認」だけをまとめる指示でした。6行では商品3の項目ごとの反映方向や、商品4の再到着の根拠を表せませんでした。日時による上書きは実行しておらず、AIが自然に起こした誤更新を直した実験ではありません。
• 商品2の採用価格、商品5の承認、商品6の前回値は整理後も未決定です。保留は差を解消した意味ではなく、両側の値と確認先を残した結果です。

検証から得た学び

• 元の検証ラボでは素材と想定表を変えず、変更ごとの状態・根拠・確認先を残す指示に修正しました。反映する3件（A01・A03・B03）、反映不要1件（B04）、保留4件（A02・B02・A05・B06）が事前想定の8行と対応し、不一致はありませんでした。同じAIが想定を決めて参照できる条件の照合で、盲検比較や人の評価、正答率ではありません。整理後も想定ファイルのSHA-256が一致しました。
• ラボではPythonで条件を確かめ、Bの商品1の価格を1,000から1,100、Bの商品3の価格を3,000から3,200、Aの商品3の案内文を「標準」から「持ち運び用」へ反映しました。Bの商品3の案内文とAの商品3の価格は保持し、商品2の価格はAが2,100・Bが1,900のままです。B04による反映と新しい完了履歴は追加しませんでした。
• 同じ項目の両側変更は日時で決めず保留し、同じ行でも別項目ならそれぞれの正本から反映する形にしました。変更IDと反映元IDを分けることで再到着を区別し、前回値の記録なしは空欄への変更と分けました。
• 原記録の明細閲覧と判断の記録、反映直前の再確認、教材、再整理待ちと判断の無効化、書き出し、候補JSONの取り込みはデモで加えたもので、元のラボの観察結果とは分けています。

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

• 二つの台帳の変更を、行全体や日時だけで上書きせず、項目ごとに人が確認する流れを検討したい場合。
• 項目ごとの正本・反映方向・責任者を決め、依頼・承認票・前回値・完了控えに戻って競合や不足資料を解決できる場合。
• 実務の権限、記録の版管理、同時変更の制御、永続的な監査記録、再実行・取り消し手順を別途設計できる場合。

補足

データはブラウザーのメモリー内だけで、再読み込みで初期状態に戻ります。原本ファイルの添付はなく、商品の名寄せ、変更一覧の取得漏れ、永続保存、利用者認証、複数人の同時操作は扱いません。元のラボでは永続的な履歴保存・同時実行・実行中の別担当の編集・通信断後の再開・実務の曖昧な履歴は試していません。実業務では正本と権限の合意、原記録の取得と版管理、承認者の本人確認、同時変更の制御、監査記録の保存、実行権限・再実行・取り消し手順が必要です。向いている条件は仕組みと限界から整理したもので、実案件への適用を確認したものではありません。