棚卸しの数量差を反映時点・調整履歴と照合し、確認待ちにするデモ

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

棚卸しの数量が帳簿と合わないとき、単位や保管場所、入出庫の反映時点をそろえずに差を埋めると、調整済みの差をもう一度処理するおそれがあります。差を消す前に元の記録と調整履歴を確認し、不足資料や再計数が必要な品目を理由付きで確認待ちに残すことを課題にしました。

実施内容

架空の6品目で数量計算をコード、分類候補と質問の整理をAIに分けた検証ラボをもとにしたデモです。元の記録の閲覧、役割・分類・理由を伴う採用や保留、質問への回答と再計算、一覧と判断履歴のJSON書き出しまで試せます。精度・正答率・在庫や会計処理の正しさは評価しておらず、時間短縮・費用効果も測定していません。

架空の6品目で比べること

• 会社「サンプル部材室」の品目「架空留め具A〜F」と保管場所・記録はすべて架空です。基準は2026年10月18日17時で、帳簿L・棚卸表S・入出庫T・調整履歴J・入り数Uを開き、差を「棚卸数量−帳簿数量」で計算します。
• Aは5箱×10個を50個に換算して差−2個、B・Cは反映時点のずれ、Dは帳簿が第一庫と第二庫・棚卸表が第一庫だけという条件不足です。Eは旧版との差−5個と調整済み版との差0個を分け、Fは差を説明する記録がない例です。
• 初版・修正版・誤りの教材を切り替え、元の記録、計算、AIの分類候補・理由・元番号・質問、先に固定した想定表を並べて確認します。想定表は初期入力に対するもので、分類が一致しても理由の正しさは保証しません。
• Bは入出庫を全行足すと同じ出庫OUT-01の再掲も数え、帳簿90個・差＋5個になります。同じ伝票番号を1回だけ数えると帳簿95個・差0個になります。「記録上の差が0」は渡された記録の上で説明がつくという意味で、元の記録や在庫数量の正しさを確認した結果ではありません。

デモで加えた回答・再計算と調整前の確認

• 質問への回答には、回答内容・元番号・理由が必要です。Dで第二庫の棚卸表S-D2の5個を追加すると帳簿100個・棚卸100個に再計算します。Bで同一伝票の再掲と確認すると同じ伝票を1回だけ数えますが、別伝票はまとめられません。
• Fは再計数95個を確認しても差−5個が残り、確認した履歴を残します。再計数だけで原因が分かったことにはしません。Eの「調整のメモを作る前に確認」では、同じ棚卸表S-Eを対象にした調整J-Eがあることを警告します。メモの保存や調整の記帳は行いません。
• 誤りの教材には、Fの原因を確認せず−5個を調整する案、Bの別伝票OUT-02をOUT-01の再掲と混同する案、Dの第二庫を推測で5個と補う案を用意しています。コードは別伝票を加算して差＋5個とし、不明な数量は補わず暫定値を表示します。教材版は採用できず、人が元番号を確かめて保留だけを記録します。
• 誤りの教材は照合用に意図して誤りを入れた版です。元の検証ラボで観察した問題とは別で、AIの自然な失敗や精度を観察した結果ではありません。

実演モードと入力の変更

• 実演モードは事前に用意したAIの出力例を再生し、その場でAIを呼びません。入力を変えてもAIは再処理しません。保存済みの候補は特定モデルによる評価結果ではなく、外部API・APIキーは不要です。計算・照合・状態の操作はコードが実際に行います。
• JSONで品目名・数量・元の記録を変更し、行や架空品目を追加できます。保存すると再計算し、保存済みのAI候補とのずれを表示します。人が元の記録を開き直して分類を選ぶまで確定できません。
• 記録と指示をコピーし、任意の生成AIで作ったJSONや人が編集したJSONを貼り付けられます。item・category・refs・reason・questionを取り込み、すべて人の確認待ちにします。デモから生成AIへ送信する機能はなく、形式の検証は内容の正しさの確認ではありません。

使った技術

Node.js、JavaScript、ブラウザの画面、JSON。Node.js 22以上とnpmで動かし、npm startでローカルホストだけに待ち受けるサーバーを起動します。追加の依存パッケージ・外部フォント・外部画像はなく、MIT Licenseで公開されています。

AIと人の役割

検証で扱った課題・制約

• 元の検証ラボでは、入出庫の全行を加算する方式がBの同じ出庫OUT-01の再掲を2回数え、帳簿90個・差＋5個になりました。同じ伝票番号を1回だけ数える方式では95個・差0個でした。AIが自然に二重調整を提案した結果ではなく、計算方式を比べて見つけた問題です。
• 元の検証ラボでAIの分類初版は、全件が確認待ちであることを表の外にだけ書いていました。行だけ取り出すと「調整済み」が確定結果に見えるため、修正版では全行に「人の確認待ち」を付けました。分類自体は変えていません。

検証から得た学び

• 差が0になることと、元の記録や在庫数量が正しいことは別です。調整済みの品目も人の確認待ちに残し、対象の棚卸表と調整履歴を元番号でたどる必要があります。
• 元の検証ラボは同じAIが素材・想定表・分類・照合を担当し、想定表を参照できる条件での試作です。人の評価・独立した評価ではなく、経理・在庫担当者による評価も未実施です。デモの教材版や質問への回答・再計算・重複警告・履歴の書き出しは、元記事の観察とは分けています。
• 元の記録を開いた操作だけでは、内容を正しく理解した保証にはなりません。入力や回答で計算が変わったら再確認し、原因が分からない差は埋めず、確認した内容と未解決の点を理由とともに残す流れにしています。

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

• 帳簿へ差を合わせる前に、単位・保管場所・基準時点・入出庫の反映・調整済みかを元の記録から確認したい場合。
• 在庫担当・経理担当・棚卸責任者が不足資料や再計数を確認し、採用・保留の理由を残して、調整の判断を別の手続きで行える場合。
• 架空データで流れを試し、実業務でのアクセス権限、記録の保管と真正性、単位や基準時点の定義、履歴の永続化、承認、重複・欠落の検証、会計方針に沿う専門家の判断を別途整えられる場合。

補足

帳簿の更新・調整の記帳・質問の送信は行いません。個別の会計・税務判断も行いません。データと履歴はタブのメモリ内だけで、再読み込みすると失われます。入力は1シナリオ20品目・1品目100記録までで、複雑な拠点間移動・開封箱・版管理には対応しません。向いている条件はデモの仕組みと限界から整理したもので、実案件での適用を確認したものではありません。