サンプル商事の事故メモ確認デモ

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

事故直後のメモには、確認した記述、原因の推測、伝聞、後からの訂正が混ざります。分類だけで確認を終えず、何を根拠に確定し、何が未確認で、次に誰がどの資料を確かめるかを残すことを課題にしました。

実施内容

架空の事故3件・メモ24件を整理した検証ラボをもとに、人が照合して確定する流れまで広げました。元番号・時刻・役割・訂正元の付いた原文と、区分・理由・抜粋・未確認の範囲・関連番号・訂正状態・次の資料を並べます。「この行を照合」で架空の資料を開き、確認者と理由を入力して判断を残せます。確認待ちには担当・次の資料・割当理由を記録し、社内メモと判断履歴をブラウザ内に保存してJSONで書き出せます。

同梱の架空メモで比べること

• A02・A06・A08は20件から18件への訂正、C02・C06・C08は12行から10行への訂正です。訂正の記述と、原記録での確認を分けて扱います。
• B02・B06・B08の09:40と09:50は未解消の食い違いです。新しいメモに確認依頼があっても、確認完了にはしません。
• B07は候補ファイルの列を確認した記述ですが、送った添付との同一性は未確認です。「確認済み」の行にも残る未確認事項を見比べます。
• A07に含まれるAIへの指示は原文として表示するだけで、整理方針には採用しません。

実演モードと候補の読み込み

• 実演モードはデモ用に用意した保存済み候補の再生です。このデモでモデルを呼んだ結果ではなく、メモを変えてもAIは再処理しません。外部API・APIキー・外部送信は使いません。
• コピー用の指示と架空メモを表示できます。任意の生成AIへの入力は利用者が外部で行う操作です。返されたJSONを貼り付けると、元番号の欠落・重複・未知の番号、区分・抜粋・関連番号・資料の形式を確認します。
• 新しい候補を読み込むと、以前の判断を履歴に残して全行を確認待ちに戻します。原文を編集したりメモを追加したりすると候補との版のずれを表示し、古い候補のまま確定する操作を止めます。

使った技術

Node.js、ブラウザ内のローカル保存、JSON。Node.js 22以上で手元のローカルサーバーを動かします。追加の依存パッケージ・APIキー・共有DBは不要です。MIT Licenseで公開されています。

AIと人の役割

検証で扱った課題・制約

• 元の検証ラボでは、「食い違い」の区分だけでは訂正の記述がある行と未解消の行を見分けにくく、修正版で訂正状態を別欄にしました。新しいメモだから正しいとは扱いません。
• 「確認済み」の行にも未確認事項が残りました。B07の添付との同一性など、確認した範囲と未確認の範囲を分け、デモでも確定後に残る確認待ちを保持します。
• 元の検証ラボは事故単位の確認事項と資料との対応が粗く、修正版で元番号と資料を対応させました。公開デモでは、さらに行ごとの照合・理由・担当割当を記録する流れにしました。

検証から得た学び

• 分類候補を見せるだけでなく、原文・根拠・訂正状態・次に見る資料を人へ渡すことを重視しました。資料閲覧を必須にする制御と、照合の正しさは別です。
• 元の検証ラボは同じAIが架空メモ・想定表・整理結果を作り、照合した試作です。人の評価や独立した正答率ではなく、公開デモの候補もモデルの実測結果ではありません。分類精度・正答率・見落とし率・対応時間の短縮・費用の効果は測定していません。

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

• 初動メモの確認した記述・推測・伝聞・食い違いを、原文と並べて人が確かめる流れを検討したい場合。
• 訂正の採否と未確認の範囲を分け、次の担当・照合資料・判断理由を記録する手順を検討できる場合。
• 架空データで手元の操作を試し、実業務に必要な情報管理・権限・監査・保存期間・専門担当への引継ぎを別途設計できる場合。

補足

架空データで確認の流れを試す公開デモで、実際の事故対応や導入の実績、効果を示すものではありません。記録はブラウザのローカル保存で、共有DB・認証・権限管理・改ざんを防ぐ監査ログ・バックアップ・添付ファイルの実物・外部API連携はありません。書き出しはJSONのみで、照合資料もデモ用の表示です。貼り付け出力の検査は形式と一部の禁止表現に限り、文章の意味や正しさを保証しません。向いている条件はデモの仕組みと限界から整理したもので、実案件での適用を確認したものではありません。