食品の表示期限と納品条件を分け、根拠と不足資料を人が確かめて判断を残すデモ

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

表示期限まで日数が残っていても、取引先の納品条件に合うとは限りません。条件の旧版、別商品の条件、未回答の変更依頼、年月だけの表示を分け、何を誰に確認するかを根拠と一緒に残すことを課題にしました。

実施内容

商品2種・ロット3種・出荷予定6行と短い条件文を読み合わせた検証ラボをもとにしたデモです。コードによる日付差と条件の対象の確認、原文の閲覧、理由付きの判断、確認票の下書き・履歴のJSON書き出し、手動取り込みを加えています。精度・正答率・正しさや導入の可否は評価しておらず、時間短縮・費用効果も測定していません。

架空の資料と、表示期限だけでは分からないこと

• 商品P1・P2、出荷予定R1〜R6と、合意書・旧条件・変更依頼の短い条件文A0・A1・B0・B1・C1・C2を使います。条件の提供状況は2026年12月18日10時を基準にした設定で、R1は過去日付の対照行です。納品実績ではありません。
• R1は旧A0ではなくA1による条件一致候補です。R2は表示まで11日あっても、A1の条件日から5日後で条件不一致になります。条件一致候補も原記録・現物を確認済みという意味ではなく、全行が人の確認待ちです。
• R3はB0にP1の条件の根拠がなく、空欄を制限なしとは扱いません。R5の参照先B1はP2だけの条件で、P1には使えません。元の予定表D1の誤った紐付けは意図して入れたものです。
• R4はC1との不一致と、12月17日の変更依頼C2の合意待ちを併記します。回答未受領の依頼を合意済みにしません。R6の表示「2027.01」には日を補わず、30暦日条件との比較を保留します。
• 完全な日付だけで「表示の日付 − 納品予定日」と「条件の記載日 − 納品予定日」のUTCの暦日差を別々に示します。未合意の記載日も計算して表示しますが、適用条件には採用しません。

デモで加えた人の判断と、変更後の扱い

• 表示原文・出荷予定・納品予定と条件原文を開き、「条件一致」「条件不一致」「確認待ち」と理由・担当を記録します。対象外の参照の確認、確認待ちの確認先と終了に必要な資料、条件一致の現物・ロット・予定の確認を必須にしています。
• 人の欄は空から始まります。必要な場合だけボタンで下書きを写し、記録後は入力を消します。照合一覧、確認待ちの行の確認票の下書き、誰が・いつ・どの行を・どの版で判断したかの履歴をJSONで保存・コピーできます。確認票は送信しません。
• 行の追加・編集、CSV貼り付け、全入力JSONによる条件原文・版・対象・合意日の編集を試せます。変更行は再整理待ちになり、条件を編集すると全行が再整理待ちになります。AIは再処理しません。
• 候補作成指示を表示・コピーし、任意の生成AIや人が別途作った候補JSONを手動で取り込めます。版・revision・根拠ID・必須項目を検証し、入力変更前の古い指示で作った候補は取り込めません。デモから外部へ接続・送信する機能はありません。
• 入力変更・候補の取り込み・版の切り替えで判断を無効にし、記録者を「コード（入力・候補の変更）」として履歴に残します。元の版に戻しても保存済み候補は復活しません。状態はタブ内だけで、再読み込みで初期状態に戻ります。

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

• 実演モードは事前に用意したAIの条件候補を再生します。その場でAIを呼ばず、外部APIやAPIキーは使いません。ライブのモデル生成や性能を確認する機能はありません。
• 表示との前後だけを見る(a)、版・対象商品・合意を含む(b)、意図的な誤りの教材を切り替えられます。先に固定した想定表は同じAIが作ったもので、人が評価した正解表ではありません。
• 教材はR2の旧A0採用、R3の空欄を制限なしとする扱い、R4のC2を合意済みとする扱い、R6への月末日補完です。照合用に意図的に入れた候補で、AIの自然な失敗を観察した結果や、AI・コードが誤りを検出できた結果ではありません。
• 比較用の(a)と教材の版では「条件一致」を記録できません。教材の書き出しには teaching: true を付け、確認票の先頭に「【教材の版・照合用】」を付けます。

使った技術

Node.js、JavaScript、ブラウザの画面、CSV、JSON。Node.js 22以上で動き、npm startでローカルサーバーを起動します。追加の依存パッケージやAPIキーは不要です。MIT Licenseで公開されています。元の検証ラボの短いJavaScriptはUTCの暦日差だけを計算し、AIを呼ばず、条件の適用や個別の期限を確定しませんでした。

AIと人の役割

検証で扱った課題・制約

• 元の検証ラボの(a)は、表示期限と納品予定日の前後だけを残したため、5行で想定の主区分を特定できず、R6は情報不足の候補だけが一致しました。表示より前の5行を「出荷可能」とした結果ではありません。
• (a)の不足資料・確認先は「適用条件と合意根拠を受発注担当へ」と一括になり、行別の違いを残せませんでした。(b)でもR3・R5のP1の条件、R4の変更合意、R6の年月表示の扱いは資料不足のままでした。

検証から得た学び

• 表示期限内であることと、納品条件に合うことは別です。元の検証ラボの(b)は版・対象商品・納品先・適用日・合意の有無を根拠付きで残し、6行の主区分と理由が先に固定した想定表と一致しました。同じAIによる自己照合で、人の評価・独立評価や実務の正答率ではありません。
• 確認待ちの理由と確認先を分けても、欠けた合意資料は埋まりません。年月表示に日を補わず、空欄を制限なしとせず、未回答の変更依頼を合意済みにしないことが重要でした。
• 元の検証ラボのコードは暦日差の計算だけです。原文を開く操作、記録の必須項目、比較用の(a)・教材での記録制限、再整理待ちと判断の無効化、確認票・履歴の書き出し、手動取り込みはデモで加えたものです。旧A0の誤採用、C2の合意済み扱い、月末日の補完は元のラボでは観察されず、教材とは分けています。

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

• 食品の表示期限と取引先別の納品条件を分け、版・対象商品・適用日・合意の根拠へ戻って確認したい場合。
• 現物・ロット・予定と合意原文を担当者がそろえ、不足資料と確認先を残せる場合。
• 権限管理、保存先・保存期間、原記録と現物の照合、変更履歴、社内責任者の確認手順を別途設計できる場合。

補足

納品期限を法律上の一律の期限として扱いません。賞味期限の設定・延長、食品の安全性、出荷の可否、個別の期限はAIにもコードにも判定させません。条件表への書き戻し、確認票の送信、出荷指示、外部APIへの接続の機能はありません。契約やメールの全文、複数の変更の競合、画像・OCR、実際の保管状態は元の検証ラボで試していません。向いている条件は仕組みと限界から整理したもので、実案件への適用を確認したものではありません。