Media > AI活用ユースケース > 物流 > 棚卸の差異を、入出庫の記録から原因別に切り分ける

棚卸の差異を、入出庫の記録から原因別に切り分ける

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

棚卸で出た差異を入力に、同じ時期の入出庫の記録と照らして、原因の候補を区分ごとに並べます。担当者の作業は、差異を1件ずつ追いかけることから、示された候補を確かめて原因を確定することに変わります。

サマリー
利用ツール
ChatGPT/Claude/Gemini/Python
対象業界
EC/商社/小売/製造
対象部門
物流/経理
対象業務
分類・仕分け/集計・分析
主な課題
データ分析に時間がかかる/属人化している/確認ミスが多い
AIで行う処理
分類
主な効果
入力漏れ削減/判断支援/工数削減
導入難易度
★★★☆☆
実装レベル
半自動化
費用感
個別開発(大)
人間の確認
条件付き
現在工数
90h/月
AI導入後
26h/月
想定削減
71%
年間削減
768h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 循環棚卸の対象SKUを、システムから出す
  2. 倉庫の担当者が実地で数え、実地数量を入力する
  3. 帳簿数量との差異が一覧に出る
  4. 在庫管理の担当者が、差異の大きいものから確認する
  5. 在庫管理システムで、その品目の直近の入出庫履歴を開く
  6. 入荷・出荷・返品・振替の記録を1件ずつ見て、手がかりを探す
  7. 見つかれば原因を特定し、伝票を訂正する
  8. 見つからなければ「棚卸減耗」として処理する
  9. 月次で、差異の金額を経理に報告する
導入後(After)
  1. 循環棚卸の対象SKUを出し、実地数量を入力する
  2. 自動帳簿数量との差異を抽出する
  3. 自動差異ごとに、直近60日の入出庫記録を集める(在庫管理・WMS・販売管理の3系統を横断)
  4. 自動機械的に照合できる候補を抽出する
  5. 自動入出庫記録の備考欄と伝票のメモを読み、手がかりを拾う
  6. 自動原因の候補を区分ごとに並べ、根拠となる伝票を添える
  7. 自動過去にその品目で差異が出た履歴を添える
  8. 担当者が候補を確認し、原因を確定する
  9. 必要な伝票の訂正を行う
  10. 自動確定した原因を記録し、月次で傾向を集計する
各工程の詳しい説明を読む
  1. 循環棚卸の対象SKUを、システムから出す
  2. 倉庫の担当者が実地で数え、実地数量を入力する
  3. 帳簿数量との差異が一覧に出る
  4. 在庫管理の担当者が、差異の大きいものから確認する
  5. 在庫管理システムで、その品目の直近の入出庫履歴を開く
  6. 入荷・出荷・返品・振替の記録を1件ずつ見て、手がかりを探す
  7. 見つかれば原因を特定し、伝票を訂正する
  8. 見つからなければ「棚卸減耗」として処理する
  9. 月次で、差異の金額を経理に報告する

問題は5つあります。

(a)1件追うのに時間がかかる。 在庫管理システムとWMSと販売管理システムを行き来して、伝票を照合します。5分では終わらないこともあります。

(b)追えるのは上位100件だけ。 残り500件は原因が分からないまま処理されます。そこに、本当に対処すべき問題が埋まっている可能性があります。

(c)同じ品目で毎回差異が出ていることに気づけない。 循環棚卸は1年で一巡するため、「去年も同じ品目で差異が出た」ことを覚えている人がいません。

(d)原因区分が担当者でばらばら。 「数え間違い」と「ロケーション違い」の使い分けが3名で違います。集計しても傾向が見えません。

(e)期ズレと紛失が区別できない。 月末に出荷したが計上が翌月になった、という期ズレは差異として出ます。翌月に反対の差異が出て相殺されますが、その時点では分かりません。

  1. 循環棚卸の対象SKUを出し、実地数量を入力する
  2. 【自動】 帳簿数量との差異を抽出する
  3. 【自動】 差異ごとに、直近60日の入出庫記録を集める(在庫管理・WMS・販売管理の3系統を横断
  4. 【自動】 機械的に照合できる候補を抽出する

- 同数量の反対差異が同時期にある(期ズレの可能性) - 類似品番で反対の差異がある(取り違えの可能性) - ケース入数の倍数と一致する(単位の取り違えの可能性) - 直近に返品の記録がある - 直近にロケーション振替の記録がある

  1. 【自動】 入出庫記録の備考欄と伝票のメモを読み、手がかりを拾う
  2. 【自動】 原因の候補を区分ごとに並べ、根拠となる伝票を添える
  3. 【自動】 過去にその品目で差異が出た履歴を添える
  4. 【人】 担当者が候補を確認し、原因を確定する
  5. 【人】 必要な伝票の訂正を行う
  6. 【自動】 確定した原因を記録し、月次で傾向を集計する

自動化されるのは「集める」「照合する」「読む」「並べる」の4つです。残るのは「原因を確定して伝票を訂正すること」です。

02今回想定するシステム構成

構成図
循環棚卸(実地数量の入力)
   │
   ▼
在庫管理システム(帳簿数量)── 差異の一覧
   │
   ▼【トリガー】棚卸の確定時 / 毎日 深夜
Python のバッチ処理
   │
   ├──▶ 入出庫記録の収集(在庫管理 / WMS / 販売管理の3系統・直近60日)
   │
   ├──▶ 機械的な候補の抽出(計算。AIを使わない)
   │       ├─ 同数量の反対差異(期ズレ)
   │       ├─ 類似品番の反対差異(取り違え)
   │       ├─ ケース入数の倍数(単位の取り違え)
   │       ├─ 返品・振替の記録
   │       └─ 過去の差異履歴
   │
   ├──▶ LLM API ── 備考欄・伝票メモからの手がかりの抽出
   │                 + 原因区分への振り分け
   │                 + 確認事項の作成
   │
   ▼
差異の原因候補の一覧 ──【担当者が確認・原因を確定】
   │
   ├──▶ 伝票の訂正(人が行う)
   │
   ▼
確定した原因を記録 ── 月次で傾向を集計
役割想定する製品代替候補
実行環境Python個別開発
生成AIClaude APIOpenAI API、Gemini API
在庫管理システム各社の在庫管理システムERP
倉庫管理WMS
出力先スプレッドシートBIツール

在庫管理システムやWMSに差異分析の機能があるなら、まずそれを使ってください。 近年の製品には、差異の候補を提示する機能を持つものがあります。自前で組む価値があるのは、3つのシステムに記録が分散していて横断できない場合と、備考欄の自由記述を判断に使いたい場合です。

Python を選んだのは、3系統のデータを突き合わせる処理が中心だからです。 照合のロジックは条件分岐と集計であり、コードで書くのが自然です。

03どうやって実装するのか

Step1

処理の起点を決める

トリガーは2つです。

1つ目は、循環棚卸の確定時です。差異が確定した時点で、候補の抽出を走らせます。

2つ目は、毎日の深夜バッチです。期ズレの検出には、翌月以降の記録が要ります。 未解決の差異について、後から反対の記録が現れていないかを毎日確認します。

この2つ目が実務で効きます。 「先月の差異が、今月の入荷計上で相殺された」ことが自動で分かれば、減耗として処理したものを取り消せます。

Step2

入力データを集める

データ中身取得元
棚卸の差異品番、ロケーション、帳簿数量、実地数量、差異数、棚卸日在庫管理システム
入出庫記録伝票番号、日付、種別(入荷/出荷/返品/振替/廃棄)、数量、備考在庫管理システム
倉庫の作業記録ピッキング、格納、移動の記録、作業者、メモWMS
受発注データ発注残、受注残、納品予定日販売管理システム
品目マスタ品番、品名、ケース入数、単位、保管ロケーション、類似品番在庫管理システム
原因区分の定義差異の原因の分類と、その判断の目安物流部(文書化が必要
過去の差異履歴品目ごとの差異の発生履歴と、確定した原因運用で蓄積
破損・廃棄の記録倉庫で発生した破損とその処理WMS

「原因区分の定義」を先に固めてください。

区分判断の目安
入荷計上漏れ実地>帳簿。入荷の伝票が未計上または日付が翌月
出荷計上漏れ実地<帳簿。出荷の伝票が未計上
期ズレ翌月に反対の差異が出て相殺される
誤出荷・取り違え類似品番で反対の差異が同時に出ている
単位の取り違え差異数がケース入数の倍数に一致する
返品の未処理返品の記録があるが在庫に戻っていない
ロケーション違い別のロケーションに同数量がある
破損・廃棄の未計上WMSに破損の記録があるが在庫から引かれていない
数え間違い他のすべてを否定できたときのみ
原因不明追跡したが手がかりが見つからない

「数え間違い」を安易に使わせないことが重要です。 実務では、原因が分からないものを「数え間違い」に寄せがちです。そうすると、本当の原因(誤出荷、盗難、計上漏れ)が見えなくなります。

「原因不明」の区分を必ず用意してください。 「分からなかった」を記録できないと、すべてが「数え間違い」になります。

Step3

データの取得方法を決める

3系統の横断が、この構成の要です。

システム取得するもの突合の鍵
在庫管理システム帳簿数量、入出庫の計上記録品番+ロケーション+日付
WMS実際の作業記録(ピッキング、格納、移動、破損)品番+ロケーション+作業日時
販売管理システム受発注の状況、納品予定品番+伝票番号

「在庫管理システムには計上されていないが、WMSには作業記録がある」という組み合わせが、計上漏れの典型です。 1つのシステムだけを見ていては見つかりません。

備考欄の取得を忘れないでください。 「破損のため別置き」「客先で数量違い」といったメモが、伝票の備考欄に書かれています。これが手がかりの中心です。

過去の差異履歴: 過去2年分の棚卸差異と、確定した原因を一覧にします。循環棚卸なら、同じ品目が2回は登場しています。

Step4

AIへ渡す前に整形する

  1. 差異の正規化 … 数量の差異と金額の差異を分けます。単価の高い品目は少量でも金額が大きくなります
  2. 対象期間の設定 … 前回の棚卸日から今回までを対象にします。循環棚卸なら1年前からになるため、直近60日と全期間の2段階で見ます
  3. 3系統のデータの突合 … 品番とロケーションで名寄せします。ロケーションコードの表記が系統で違うことがあります
  4. ケース入数の適用 … 品目マスタからケース入数を取り、差異数が倍数かを判定します
  5. 類似品番の抽出 … 品番の体系から、1〜2文字違いの品番を抽出します
  6. 過去履歴の引き当て … 同じ品目の過去の差異と確定原因を用意します
Step5

AIに処理させる

機械的な照合は、プログラムで行います。

照合方法
同数量の反対差異(期ズレ)数量の一致と日付の近接で判定
類似品番の反対差異(取り違え)品番の編集距離と数量の一致
ケース入数の倍数(単位の取り違え)割り算
返品・振替の記録の有無伝票種別の検索
別ロケーションの同数量在庫データの検索
過去の差異履歴品番での検索

これらはすべて計算で決まります。LLMを使う理由がありません。

LLMにさせること:

処理内容
備考欄からの手がかりの抽出「破損のため別置き」「客先で数量違い」といった記述を拾う
WMSの作業メモの読み取り倉庫作業者が残したメモから、関係しそうな記述を拾う
原因区分への振り分けの候補機械的な候補と備考の手がかりから、区分の候補を示す
確認事項の作成「この伝票の備考に『破損』とあります。廃棄処理は済んでいますか」といった問い
過去の原因との照合「同じ品目で3回、ロケーション違いが原因だった」ことを示す

原因を確定させないでください。 出すのは「候補」です。確定は担当者が伝票を確認して行います。

「数え間違い」を候補として出させないでください。 これは他のすべてを否定した結果として人が選ぶ区分です。AIに選ばせると、手がかりが弱い差異がすべてそこに寄ります。

Step6

指示内容を固定する

あなたは、棚卸差異の原因を追う担当者を支援する担当者です。
入出庫の記録から、原因の手がかりになる記述を拾ってください。

【厳守事項】
- 原因を確定しないでください。
  「この差異の原因は出荷計上漏れです」と書かないでください。
  「〜の可能性がある」という候補として示し、根拠を必ず添えてください。
- 「数え間違い」を候補として挙げないでください。
  これは他のすべてを否定したときに人が選ぶ区分です。
  手がかりが見つからない場合は、cause_candidates を空にし、
  「記録から手がかりが見つかりません」と書いてください。
- 記録にないことを推測しないでください。
  「おそらく別の棚に置かれたと思われます」と書かないでください。
- 在庫数の修正を提案しないでください。
  「帳簿を◯個に修正してください」と書かないでください。
- 備考欄やメモを引用するときは、原文のまま quoted_text に入れてください。
  要約しないでください。
- 伝票を根拠として挙げるときは、伝票番号と日付を必ず記載してください。
  根拠のない候補を出さないでください。
- 作業者の氏名が記録に含まれていても、指摘文に転記しないでください。
  誰の作業かではなく、何が起きたかを扱ってください。
- 確認事項は、担当者が伝票やシステムで確かめられる形で書いてください。
  「原因を調査してください」ではなく
  「伝票 A-12345(9月3日)の備考に『破損』とあります。廃棄の計上を確認してください」
  のように書いてください。

【原因区分の定義】
{cause_categories}

【この差異】
品番: {item_code} / 品名: {item_name} / ロケーション: {location}
帳簿数量: {book_qty} / 実地数量: {actual_qty} / 差異: {variance}
ケース入数: {case_qty} / 単価: {unit_price}

【機械的に抽出された候補】
{mechanical_candidates}

【直近60日の入出庫記録(備考欄を含む)】
{transaction_history}

【WMSの作業記録(メモを含む)】
{wms_records}

【この品目の過去の差異履歴と確定原因】
{past_variances}

「数え間違いを候補として挙げない」の1行が、この構成でもっとも重要な指示です。 これを書かないと、手がかりの弱い差異の大半が「数え間違いの可能性」で埋まります。そして、それを見た担当者が「やはり数え間違いか」と納得して処理します。 本当の原因は見つかりません。

「在庫数の修正を提案しない」も必ず入れてください。 在庫の修正は、金額の確定と会計処理を伴います。AIが提案してよい範囲ではありません。

Step7

出力形式を固定する

機械的な照合(プログラム)の出力:

{
  "variance_id": "",
  "item_code": "",
  "location": "",
  "book_qty": 0,
  "actual_qty": 0,
  "variance_qty": 0,
  "variance_amount": 0,
  "mechanical_candidates": [
    {
      "type": "timing_offset | similar_item_swap | case_unit_mismatch | return_pending | location_transfer | other_location_match",
      "matched_record": { "voucher_no": "", "date": "", "qty": 0, "system": "" },
      "match_strength": "exact | partial"
    }
  ],
  "past_variance_count": 0,
  "past_causes": []
}

LLM部分の出力:

{
  "variance_id": "",
  "findings": [
    {
      "source": "transaction_note | wms_memo | past_variance",
      "quoted_text": "",
      "voucher_no": "",
      "date": "",
      "relevance": ""
    }
  ],
  "cause_candidates": [
    {
      "category": "",
      "basis": "",
      "supporting_records": [],
      "confidence": "high | medium | low"
    }
  ],
  "questions_to_check": [],
  "recurring_pattern": "",
  "needs_review": []
}

quoted_text(備考欄の原文)を必ず残します。 「破損の記載あり」と要約されると、どの程度の記述かが分かりません。

cause_candidates に「数え間違い」は現れません。 区分の一覧から除外しておきます。担当者が画面で選ぶときにだけ表示します。

recurring_pattern には、同じ品目で繰り返している傾向を入れます。 「過去2年で4回差異が発生し、うち3回がロケーション違い」といった記述です。これが、個別の差異の処理から、原因の除去へ進む手がかりになります。

なお、Claude API には出力をJSONスキーマに沿わせる構造化出力の機能があります(2026-09-17時点ではベータ機能として提供)。600件を機械処理するため、利用できると安全です。

Step8

システムへ連携する

つなぐ先内容
在庫管理システム(読み取り)差異、帳簿数量、入出庫記録、品目マスタ
WMS(読み取り)作業記録、破損の記録
販売管理システム(読み取り)受発注の状況
スプレッドシート候補の一覧を出す。担当者の判断もここで入力する
差異の履歴(蓄積)確定した原因を記録する
在庫管理システム(書き込み)行いません(後述)

在庫数の修正と伝票の訂正を自動化しないでください。 在庫の修正は、棚卸減耗として損益に計上されます。会計上の処理であり、経理の確認を経て行うものです。

確定した原因の記録は自動化してください。 担当者がスプレッドシートで区分を選べば、履歴に蓄積されます。これがないと、翌年の同じ品目の差異で同じ調査を繰り返します。

Step9

人が確認する

すべての差異について、原因の確定は人が行います。

見る優先順位は次のとおりです。

優先対象対応
1variance_amount が大きい金額の影響が大きい。必ず追う
2mechanical_candidatessimilar_item_swap がある誤出荷の可能性。顧客に誤った商品が届いている
3recurring_pattern があるもの繰り返している。個別の処理ではなく原因の除去が要る
4cause_candidateshigh のもの候補を確認して確定する
5cause_candidates が空のもの手がかりがない。「原因不明」として記録する
6timing_offset(期ズレの可能性)翌月の記録を待つ。すぐに減耗にしない

2番目を見落とさないでください。 類似品番で反対の差異が出ているということは、顧客に別の商品が届いている可能性があります。 在庫の問題であると同時に、顧客対応の問題です。

5番目の「原因不明」を、きちんと記録してください。 原因不明の件数と金額が集計できれば、「追えていない差異がどれだけあるか」が経営に説明できます。

Step10

例外に対処する

起きること対応
手がかりが見つからないcause_candidates を空にする。「数え間違い」に寄せない
期ズレの可能性がある翌月の記録を待つ。すぐに減耗処理しない
類似品番で反対の差異誤出荷の可能性として優先度を上げる。顧客への確認が必要
別ロケーションに同数量があるロケーション違いの候補。実地で確認する
ケース入数の倍数と一致単位の取り違えの候補。自動で確定しない
3系統でロケーションコードが違う名寄せの対応表を作る。照合できないと候補が出ない
備考欄が空欄手がかりなし。「特に問題なし」と解釈しない
同じ品目で毎回差異が出るrecurring_pattern で示す。個別処理ではなく原因の除去へ
実地数量の入力ミス差異が極端に大きい場合に検出し、再カウントを求める
単価が極端に高い品目金額の影響が大きい。少量でも優先して追う
盗難が疑われるこの構成では判断しない。 人が判断し、社内の規程に従って対応する
過去の差異履歴がない(導入初期)繰り返しの検出ができない。1年分たまるまで機能しない
Step11

記録を残す

  • 棚卸の差異(品番、ロケーション、数量、金額、棚卸日)
  • 機械的に抽出された候補と、その根拠となる伝票
  • LLMが拾った手がかりと、備考欄の原文
  • 担当者が確定した原因と、その根拠
  • 伝票の訂正の記録(誰が、いつ、何を)
  • 期ズレとして保留し、後から相殺された記録
  • 月次の集計(原因区分別の件数と金額、原因不明の件数と金額)

「担当者が確定した原因と根拠」が、この構成の資産です。 翌年に同じ品目で差異が出たとき、前回の原因がそのまま手がかりになります。

棚卸表は法人税法上の保存対象の書類に含まれます。 帳簿書類の保存期間は、その事業年度の確定申告書の提出期限の翌日から原則7年間です(欠損金が生じた事業年度は10年間)。保存の対象と期間は、自社の税務処理に合わせて確認してください。

月次の集計で「原因不明」の件数と金額を必ず出してください。 この数字が減っていくことが、この構成の成果です。

04実装レベルの3段階

最小構成:Excelで機械的な照合を行い、候補を出す / 照合
半自動化:3系統のデータを横断して候補を抽出し、備考欄の手がかりも拾って一覧にする / 収集・照合・手がかりの抽出
本格構成:上記+過去の差異履歴との照合+期ズレの追跡+月次の傾向集計 / 原因の確定以外のすべて

本格構成に価値があります。 半自動化だけだと、期ズレの追跡(翌月に相殺されたかの確認)が手作業のまま残ります。期ズレを減耗として処理してしまうことが、差異分析でもっとも多い誤りです。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
3 名
月間件数
600 件
1件あたり現在時間
9 分
1件あたり導入後時間
2.6 分
現在  600件 × 9分 ÷ 60 = 90 時間/月
導入後 600件 × 2.6分 ÷ 60 = 26 時間/月
月間削減時間
64h
削減率
71%
年間削減時間
768h
年間金額換算(時間単価3,000円)
230万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 在庫品目が3,000点以上あり、循環棚卸または月次棚卸を行っている企業。入出庫の記録が電子データで残っていること。棚卸差異が月100件以上あり、原因を追いきれていないこと。
向いていない
  1. 品目が数百点以下で、担当者が差異の原因を把握できている場合。棚卸が年1回のみで、差異の分析を行っていない場合。在庫管理システムに差異の原因分析の機能があり、それで足りている場合。

07最小構成で試す方法

  1. 直近の棚卸差異を50件選ぶ(金額の大小を混ぜる
  2. 各差異について、直近60日の入出庫記録をExcelに出す
  3. 機械的な照合だけをExcelで行う

- 同数量の反対差異があるか - 差異数がケース入数の倍数か - 類似品番で反対の差異があるか

  1. 候補が見つかった件数を数える

この3ステップで、AIを使わずに効果が測れます。 多くの場合、50件のうち15〜25件で候補が見つかります。

次にAIの部分を試します。

  1. 候補が見つからなかった差異について、入出庫記録の備考欄を生成AIに渡す
  2. 手がかりになる記述を拾わせる
  3. 担当者が実際に追跡して見つけた原因と比べる

見るのは次の4点です。

見る点判断
備考欄から手がかりを拾えたか拾えれば、機械照合で漏れた分をカバーできる
「数え間違い」を候補に挙げていないか挙げていたら、プロンプトを強める。ここが最重要
原因を確定していないか確定していたら同上
根拠の伝票番号が示されているか示されていなければ、担当者が確かめられない

あわせて、原因区分の定義を作ってください。 3名の担当者で「数え間違い」と「ロケーション違い」の使い分けを揃えます。この作業だけでも、集計の意味が変わります。

08実装時につまずきやすいポイント

問題対策
AIが「数え間違い」を候補に挙げる区分の一覧から除外する。手がかりがなければ空にする。最重要
AIが原因を確定する「可能性がある」の候補にとどめる。根拠の伝票を必須にする
AIが在庫数の修正を提案する禁止する。会計処理は経理の判断
期ズレを減耗として処理してしまう翌月の記録を待つ仕組みを入れる。差異分析で最も多い誤り
3系統のロケーションコードが揃わない名寄せの対応表を作る。照合できないと候補が出ない
備考欄を取得していない取得する。手がかりの中心はここ
原因区分の定義がなく集計が意味をなさない先に定義を文書にする
「原因不明」の区分がない用意する。ないとすべてが「数え間違い」になる
類似品番の反対差異を見落とす誤出荷の可能性。優先度を上げる
過去の差異履歴を残さない確定した原因を記録する。翌年の同じ調査を防ぐ
作業者の氏名が指摘に出る転記させない。誰の作業かではなく何が起きたかを扱う

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 在庫数量、品目、単価、入出庫の記録、倉庫作業者の氏名。単価と在庫数量は、自社の仕入条件と商品構成を示す情報です。

  1. 外部AIへの入力可否 … 品目、数量、単価が含まれます。単価は仕入先との取引条件に関わることがあります。 自社の情報管理規程を確認してください。判断に単価は不要なので、マスクして渡す構成も取れます(金額による優先度づけは計算側で行えます)
  2. 作業者の氏名 … 入出庫の記録には作業者の氏名が含まれます。LLMに渡す必要はありません。 渡す場合も、指摘文に転記させないでください
  3. 個人の評価に使わない … 差異の発生を、倉庫作業者の評価に直接結び付けないでください。差異を隠す、報告しないという行動につながります。 方針として明文化してください
  4. 盗難の疑いの扱い … 差異の原因が盗難である可能性は、実務上存在します。この構成では判断しません。 原因不明の差異が特定の品目・ロケーションに集中している場合の扱いは、社内の規程に従って人が判断します
  5. 学習利用 … 入力を学習に使わないことが契約で保証されるサービスを選びます
  6. 会計処理の正確性 … 棚卸減耗は損益に計上されます。AIの候補を根拠に処理しないでください。 根拠は伝票と実地の確認です
  7. 記録の保存 … 棚卸表は法人税法上の保存対象です。原則7年間(欠損金が生じた事業年度は10年間)の保存が必要です。AIの処理に使ったデータとは別に、正本を保存してください
  8. 自動実行してよい範囲 … 候補の抽出と手がかりの提示までです。原因の確定、伝票の訂正、在庫数の修正、減耗の計上は、必ず人が行います

誤りが起きた場合のリスクは、誤った原因の確定による会計処理の誤りと、誤出荷の見落としです。後者は顧客に別の商品が届いたまま放置されることを意味します。

10まず何から始めるか

1週目:原因不明の件数と金額を数える

直近1年の棚卸差異について、次を数えます。

  • 差異の総件数と総金額
  • 原因を追跡した件数
  • 「棚卸減耗」「数え間違い」として処理した件数と金額

3番目の数字が、この構成の対象です。 金額が大きければ、経営に説明する材料になります。

2週目:原因区分の定義を作る

担当者3名で、原因区分と判断の目安を文書にします。「数え間違い」を最後の手段とすること、「原因不明」を用意することを、ここで決めてください。

3週目:50件で機械照合を試す

直近の差異50件について、同数量の反対差異、ケース入数の倍数、類似品番の反対差異をExcelで照合します。候補が見つかった件数を数えてください。 AIは使いません。

4週目:備考欄の手がかりを試す

候補が見つからなかった差異について、備考欄を生成AIに渡して手がかりを拾わせます。「数え間違い」を挙げていないかを必ず確かめてください。

2か月目:3系統の横断を作る

在庫管理・WMS・販売管理からデータを取得し、名寄せして照合する処理を作ります。ロケーションコードの表記揺れが最初の壁になります。

3か月目以降: 備考欄の読み取りと、期ズレの追跡を追加します。9分が何分になるかを実測し、あわせて「原因不明」の件数と金額を毎月追ってください。 それが減ることが、この構成の成果です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-09-17/最終更新:2026-09-17
確認した内容情報源確認日
法人の帳簿書類の保存期間が、その事業年度の確定申告書の提出期限の翌日から原則7年間であること(欠損金や災害損失金が生じた事業年度は10年間。平成30年4月1日前開始事業年度は9年間)。保存対象の書類に棚卸表が含まれること国税庁:No.5930 帳簿書類等の保存期間2026-09-17
Claude API に、出力をJSONスキーマに沿わせる構造化出力の機能があること(2026-09-17時点ではベータ機能)Claude Platform Docs: Structured outputs2026-09-17
Claude のプロジェクトに参照用の文書をアップロードして会話の中で読ませられること(最小構成で原因区分の定義を持たせる場合)Claude Help Center: What are projects?2026-09-17

棚卸減耗の会計処理と税務上の取扱いは、自社の会計方針と税務の判断によります。この部分は顧問税理士に確認してください。 在庫管理システム・WMS・販売管理システムからのデータ取得方式は、製品によって異なります。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。棚卸減耗の金額の削減効果は、根拠がないため数値化していません。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-0117)についてのご相談はこちらから。

AI活用について相談する
目次