動かない在庫を毎月洗い出して、処分・返品・値引きの候補に仕分ける

処理の起点を決める

毎月1日の定時実行です。 前月の締めが終わり、月末時点の在庫と出庫の履歴が確定したところで動かします。

年1回の棚卸のときだけ動かす形にもしません。月次にすることが、いちばん大きな変更点です。 終売から時間がたつほど値引きでも動かなくなり、返品の相談も難しくなります。発見が早いほど、選べる手が多く残ります。

処理の単位は品目コードと保管場所の組み合わせです。品目だけで見ると、動いている拠点の実績に隠れて滞留が見えません。

入力データを集める

下の3つが、この構成の質を決めます。 基準表が無ければ全品目を同じ日数で測ることになり、保守部品が全部滞留になります。除外リストが無ければ、触ってはいけないものが並びます。

基準表は、区分ごとに3つの数値を持ちます。

どれをいくつ超えたときに候補とするかも、区分ごとに決めます。 季節ものを日数だけで測ると、毎年同じ時期に全件が候補になります。

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

在庫管理システムと購買システムからは、APIで取れるならAPIで、取れないなら書き出しファイルで受け取ります。 月1回の処理なので、夜間バッチのCSVを読む形で十分です。

基準表と除外リストと契約台帳は、スプレッドシートを読むだけで足ります。契約台帳から引くのは、返品条項の有無と期限だけです。 契約の全文は読みません。

AIへ渡す前に整形する

1. 単位をそろえる … 品目コードと保管場所の組み合わせを行の単位にし、在庫数を換算します
2. 除外リストを当てる … 保守部品、法定保有、預り在庫、試作の保管に当たるものを外します
3. 引当を確かめる … 引当の数量が1以上のものを外します
4. 日の浅いものを外す … 初回入庫から保管期間に満たないものは候補にしません
5. 指標を計算する … 最終出庫日からの日数、保管期間、回転率をPythonで計算します
6. 基準表に当てる … 区分ごとのしきい値と比べ、候補かどうかを決めます
7. 在庫金額を計算し、並べる … 在庫数と単価を掛け、大きい順に並べます
8. AIに渡す件数を絞る … 金額の大きいほうから、その月に扱える件数までを渡します

AIに処理させる

させるのは、滞留の理由を区分し、取るべき手の候補を挙げ、その根拠にした材料を書き出すことだけです。

指示内容を固定する

あなたは物流部門で、動きの止まった在庫の滞留の理由を区分する立場です。
渡された材料だけを見て判断してください。材料に無いことを推測で補わないでください。

【理由の区分（この7つから1つ選ぶ）】
- discontinued ..... 終売になった製品またはその部材
- spec_change ...... 仕様変更で使えなくなった
- seasonal ......... 季節を外しただけで、次の季節に動く見込み
- over_order ....... 発注が実際の使用量より多すぎた
- demand_drop ...... 需要が段階的に落ちている
- sample_leftover .. 展示会・試作・サンプルの残り
- unknown .......... 渡された材料では区分を決められない

【取るべき手の候補（この6つから1つ以上挙げる）】
- markdown ......... 値引きして販売する
- return_to_vendor . 仕入先への返品を相談する
- transfer ......... その品目が動いている他拠点への転送
- scrap ............ 廃棄を検討する
- hold ............. そのまま保有する
- need_info ........ 判断の材料が足りない

【厳守事項】
- 廃棄するかどうかを決めないでください。scrap は「検討する候補」であり、
  決定ではありません。決めるのは在庫の責任者です。
- 仕入先に返品できるかどうかを判断しないでください。契約の条件は
  渡していません。return_to_vendor は相談する候補という意味です。
- 評価損など会計上の処理や、値引きの金額・率を書かないでください。
- 在庫金額、回転率、日数を計算し直さないでください。
- 終売とも仕様変更とも読めないときは unknown を選び、reason_evidence に
  「何が分かれば決められるか」を書いてください。迷ったときに
  discontinued を選ばないでください。
- reason_evidence には、判断の根拠にした材料の値をそのまま写してください。
  「終売フラグ = 1」「直近24か月の出庫 = 0」のように、値で書いてください。

【この品目の材料】
品目コード / 保管場所 / 品目の区分 / 在庫数 / 在庫金額 .. {item}
最終出庫日からの日数 / 保管期間 / 回転率 ................ {metrics}
終売の区分 / 仕様変更の有無 / 後継品 / 季節性 ........... {master}
直近の発注日 / 発注数 / 発注の理由 ...................... {po}
他拠点の在庫数 / 他拠点の直近の出庫 ..................... {other_sites}

「迷ったときに discontinued を選ばない」を書いておかないと、unknown がほとんど出ません。 終売は材料が分かりやすく、逃げ場所になります。unknown が出ないほうが困ります。 材料が足りないという事実が見えなくなり、品目マスタが更新されていないことに気づけなくなります。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "item_code": "",
  "location": "",
  "reason": "discontinued | spec_change | seasonal | over_order | demand_drop | sample_leftover | unknown",
  "reason_evidence": "",
  "confidence": "high | medium | low",
  "actions": [
    { "action": "markdown | return_to_vendor | transfer | scrap | hold | need_info",
      "rationale": "" }
  ],
  "missing_info": ""
}

スキーマは strict: true で渡し、すべてのフィールドを required に入れ、オブジェクトには additionalProperties: false を付けます。公開ドキュメントでは、Structured Outputs は必須キーを省略したり無効な enum 値を生成したりすることがないとされています。enum に固定しているのは、後段の集計が区分の文字列に依存するからです。 自由文が1件でも混ざると、その月の集計が合いません。

安全上の理由で応答が拒否された場合は、refusal フィールドで拒否が示されるとされています。空のJSONとして後段に流れないよう、検出して人へ回す経路を作ります。

システムへ連携する

書き込むのは処理の台帳だけです。在庫数を動かす操作が経路に一切無い状態を保ちます。 実際の出庫や廃棄の登録は、承認のあとに担当部署が既存の手順で行います。

ツール利用（function calling）を使う設計も考えられます。 公開ドキュメントでは、ツールを含めてリクエストし、呼び出しを受け取り、アプリケーション側で実行し、その出力を含めて再度リクエストし、最終応答を得る流れが示されています。今回は前処理で材料をそろえてから1回で渡す形にしています。 使う場合は20個未満に抑えることが推奨されています。

人が確認する

Power Automate では、承認ワークフローを作るには「承認 - 開始して承認を待機」アクションを追加するとされています。承認の種類を選び、タイトル、割り当て先、詳細を指定する形です。承認者は承認センターか電子メールの受信ボックスから返信できると説明されています。

1. confidence が low のものと missing_info のあるものを先に見る … 多くは品目マスタの更新漏れです
2. 在庫金額の大きいものから候補と根拠を確かめる … reason_evidence の値を見て、区分が合っているかを判断します
3. 手を決める … 値引き・返品・転送・廃棄・保有継続のどれにするかを、責任者が選びます
4. 返品と会計は別の人に回す … 返品の可否は購買が仕入先に確かめ、評価損の処理は経理に回します

3番目は、AIの候補をそのまま承認する場ではありません。 候補が scrap でも、責任者が hold を選べる形にします。選び直した記録が、翌月の基準表と除外リストを直す材料になります。 AIが scrap を出したものに hold が選ばれ続けるなら、候補の出し方が業務と合っていません。

承認の詳細の欄には、品目コード、保管場所、在庫数、在庫金額、日数、区分、根拠、候補を並べます。Markdown を使って詳細フィールドの書式を設定することができるとされているので、一覧の形で読める状態にしておきます。 承認者が在庫管理システムを開かずに判断できるかで、確認に使う時間が変わります。条件分岐は、承認者の応答が「承認」と等しいかで分けます。

フローの実行期間が30日を超える可能性がある場合については、承認データを Microsoft Dataverse に保存する方法が示されています。2つのフローに分け、「承認の作成 (v2)」アクションで応答側の処理を行う形です。在庫の判断は仕入先への確認待ちで数週間止まることがあるため、この形を前提にしておくと止まりません。

例外に対処する

下2行が、運用に乗るかを決めます。 承認が返らないまま月が変わると同じものが翌月も並び、やがて誰も一覧を開かなくなります。

記録を残す

• 毎月の候補の一覧（品目、保管場所、在庫数、在庫金額、日数、保管期間、回転率）
• AIが返したJSONの全文（reason、reason_evidence、confidence、actions、missing_info）
• そのとき使った基準表と除外リストの内容
• 承認の結果（誰が、いつ、どの手を選んだか）と、AIの候補と違う手を選んだ記録
• 決めたあとの実際の処理（値引きの開始日、返品の可否、転送先、廃棄の日）
• 滞留している在庫金額の合計の、月ごとの推移

3つ目を残すのは、基準表が後から変わるためです。 しきい値を変えると、過去に候補にならなかった品目の意味が変わります。当時の基準が無いと、見直しの範囲が決まりません。