滞留在庫の見極め方:2026年における6つのチェック項目

在庫のエクスポートデータには、必ず動いていない資金が眠っています。難しいのは、在庫数がゼロのものを探すことではありません。どの動きの遅い商品ラインが問題で、どれが単にそういう売れ方をする製品なのかを判断することです。
この判断を一方に誤ると、本来売れたはずの在庫を廃棄することになります。もう一方に誤ると、現金が1年間も倉庫に眠り続けることになります。
この2つを分ける万能な日数というものは存在しません。存在するものは、手元にあるファイルに対して実行できる、再現可能な一連のチェック項目です。
本ガイドでは、滞留在庫(スロームービング・インベントリ)とは何か、なぜ固定のしきい値が機能しないのか、実行すべき6つのチェック、そして手動でのアプローチが限界を迎えるポイントについて解説します。
何が滞留在庫に該当するのか
実用的な区分は、「まだ必要な在庫」と「もう不要な在庫」の違いです。
SLOB inventory guideでは、過剰在庫や長期滞留在庫とも呼ばれる滞留在庫(slow-moving inventory)を、「必要」ではあるが「過剰」な製品と説明しています。一方で、不動在庫(obsolete inventory)は異なり、「もはや不要」な製品、「期限切れ」の製品、または「古いコレクション」の製品を指します。
この区分によって、取るべきアクションが変わります。滞留在庫には需要予測や購買の意思決定が必要です。不動在庫には処分(廃棄)の意思決定が必要であり、どれだけプロモーションを行っても解決しません。
反対の極にあるのが、誰もが気づく失敗です。欠品(stockout)とは在庫が底をつく事態であり、過剰在庫(overstock)はその逆で抱えすぎている状態を指します。ほとんどの在庫レポートは欠品を追いかけるばかりで、過剰在庫の定量化を行いません。しかし、コストがより高くつくのは後者です。
なぜ固定のしきい値が機能しないのか
90日間売れていないものはすべて滞留在庫と見なしたくなるものです。それが正しい場合もありますが、多くの場合、それは無意味です。
SLOB guideは、代わりに自社のデータからしきい値を導き出すことを推奨しています。全体の在庫回転日数を計算し、その基準値(ベースライン)より少し上に制限を設定します。同ガイドの具体的な例では、全体の在庫回転日数が35日で、推奨される制限は40日となっています。
これはそのままコピーすべきルールではないと明記されています。指示されているのは、リードタイム、再注文点、安全在庫レベルを考慮して、「この数値を自社のビジネスに適合させる」ことです。
同ガイドが示す在庫回転の計算式は、在庫価値を売上高で割り、その期間の日数を掛けたものです。まずカタログ全体でこれを実行し、次に製品ごとに実行して比較します。
つまり、しきい値は分析のインプットではなく、分析のアウトプットなのです。選択した数値をレポートに記録しておき、翌四半期のバージョンと比較できるようにしましょう。
6つのチェック項目
これらを順番に実行してください。それぞれのチェックが、前のチェックで生じた疑問に答える形になっています。
チェック 1:最終販売日からの経過日数
最もシンプルなシグナルであり、最初に始めるべきものです。各SKUについて、今日の日付から最終販売日を引きます。
現在の日付にはTODAY関数を使用し、列が自動的に更新されるようにします。降順で並べ替え、リストの上部を確認します。
このチェックは候補を見つけ出すためのものです。年に2回しか売れない製品が異常というわけではないため、これだけで何かが確定するわけではありません。
チェック 2:自社の基準値に対する在庫回転
次に、各SKUを計算したカタログの基準値と比較します。設定した制限を大幅に超えているものはすべて、フラグ付きのライン(行)になります。
SUMIFS関数を使用して期間中のSKUごとの売上合計を算出し、製品ごとに在庫回転の計算を適用します。
このチェックにより、本当に動きの遅いラインと、短い期間だけ静かに見えているだけのラインを区別することができます。
チェック 3:在庫充足日数とリードタイムの比較
現在の在庫を1日あたりの平均販売数で割り、在庫充足日数(カバー日数)を算出します。次に、それを同じSKUのサプライヤーのリードタイムと比較します。
在庫充足日数がリードタイムを大幅に上回っている場合は、まだ抱える必要のない在庫を保持していることを意味します。リードタイムを下回っている場合は、次の注文の到着が遅すぎることを意味します。
このチェックは、滞留在庫リスクと欠品リスクが、実は同じ分析を両端から見ているに過ぎないことが明らかになるポイントです。
チェック 4:個数ではなく、リスクにさらされている価値
フラグが立ったラインを、個数ではなく在庫価値で並べ替えます。動きの遅い1,000本のネジと、動きの遅い3台の機械は、同じ問題ではありません。
これにより、注視すべき優先順位が即座に変わります。価値ベースの上位5ラインが、リスク全体の大部分を占めていることはよくあります。
フラグ付き在庫の総価値を1つの数値として報告します。この数値こそが、財務に関する議論で実際に必要とされるものです。
チェック 5:売れ筋商品の欠品頻度
動きの遅いラインは、全体像の半分に過ぎません。在庫レベルのスナップショットに対してCOUNTIFS関数を使用し、最も動きの速いSKUがゼロになった頻度をカウントします。
大量の滞留在庫がある一方で欠品が頻発している場合、通常は1つの原因を指し示しています。購買部門が予算を誤ったラインに割り当てているのです。
このチェックがなければ、レポートは単なる廃棄リストに見えてしまいます。しかしこれがあれば、レポートは購買に関する議論の根拠になります。
チェック 6:不動在庫と滞留在庫のステータスフラグ
最後に、フラグが立ったラインを製品ステータスごとに分割します。SLOB guideが、まさにこの理由から、必要な列の中に製品ステータスフラグ(アクティブか不動か)を含めているのです。
フラグを信頼する前に、それが正確であるか確認してください。UNIQUE関数を使用して一意のステータス値をリストアップします。システムの変更後などには、同じ状態に対して3つの異なる表記が見つかることがよくあるためです。
不動在庫としてフラグが立ったラインは、需要予測の議論から外れ、処分の議論へと移行します。これらは別のテーブルに分けて管理してください。
手動で行う方法
オプション1:チェックごとに1つのフラグ列を作成する。 SKUリストに上記のチェックに対応する6つの列を作成し、その組み合わせでフィルターをかけます。なぜそのラインにフラグが立ったのかを尋ねられることになるため、1つの判定にネストするのではなく、各チェックを可視化したままにしておきます。
オプション2:カテゴリと価値帯によるピボット。 フラグが立ったラインを製品カテゴリごと、次に価値帯(価格帯)ごとに集計します。これにより、長いSKUリストがわずか3つの意思決定へと集約されます。
オプション3:パラメータタブ。 在庫回転の基準値、選択した制限、期間、使用したリードタイム、およびエクスポート日を記録します。これにより、翌四半期にもレポートを再実行できるようになります。
共通の前提条件。 3つのオプションはすべて、在庫と売上が同じキー(SKUなど)および同じ期間に基づいていることを前提としています。売上のエクスポートデータが複数週間に及び、在庫のスナップショットが1日だけをカバーしている場合、それらを整合させることが、6つのチェックを実行する前の大前提となります。
手動アプローチが限界を迎えるポイント
最初の実行には1日かかりますが、実際に埋もれていた資金を見つけ出すことができます。しかし、1四半期後の2回目の実行では、すべての基礎データが変化しているため、ほぼ同じだけの時間がかかります。
製品カタログは常に変化しています。新規SKU、名称変更されたSKU、統合されたSKUなどはすべて、前四半期のリストとの比較を困難にします。
基準値も変動します。今四半期の全体の在庫回転は異なるため、そこから導き出されるしきい値も変わります。前四半期には問題なかったラインが、製品とは無関係な理由でフラグを立てられることになります。
そして、最もコストがかかる失敗があります。フラグが立ったラインが一度レビューされたものの、何の意思決定も記録されないケースです。その結果、同じラインがさらに3ヶ月分の保管コストを上乗せされた状態で、次のレポートに再び現れることになります。
Powerdrill Bloomで構築する方法
ステップ 1:在庫と売上のエクスポートデータをアップロードする
在庫ファイルと売上ファイルを一緒にアップロードします。Powerdrill Bloomは取り込み時に対象列のプロファイルを分析するため、SKUフォーマットの不一致、重複する製品コード、一貫性のないステータス値などが、ラインにフラグが立つ前に検出されます。
ステップ 2:自然言語でチェック内容を記述する
ルールを構築するのではなく、言葉で説明します。期間、リードタイム(手元にある場合)、および不動在庫を意味するステータス値を指定します。
次に、順番にチェックを依頼します。まず全体の在庫回転を求め、次に設定した制限を超えるSKUごとの数値を求めます。続いて、フラグが立ったラインを個数ではなく価値で並べ替えるよう指示します。最後に、最も動きの速い商品の欠品回数を求めます。
ステップ 3:チャート、レポート、またはスライド資料をエクスポートする
フラグ付きのテーブル、リスクにさらされている価値を示すチャート、または使用したしきい値と結果をまとめたスライドを出力します。
なぜ手動での再実行よりも優れているのか
| 手動アプローチ | Powerdrill Bloom | |
|---|---|---|
| 基準となる在庫回転の導出 | カタログ全体に数式を適用 | 最初にそれを指示するだけ |
| 異なるしきい値のテスト | すべてのフラグ列を再構築 | 新しい制限を指定して指示するだけ |
| ファイル間でのSKUキーの不一致 | エラーになった参照(VLOOKUP等)で気づく | アップロード時に検出 |
| 翌四半期の再実行 | 変更されたカタログに合わせて再構築 | ファイルを差し替え、ルールはそのまま適用 |
2行目こそが、実際の判断が行われる部分です。40日の場合と60日の場合のフラグ付きリストを比較できることで、しきい値をめぐる議論が単なる推測から具体的な比較へと変わります。
よくある間違い
記事に書かれている「90日」というしきい値をそのままコピーする。 SLOB guideが指示しているように、自社の在庫回転の基準値から導き出し、リードタイムや安全在庫に合わせて調整してください。
フラグが立ったラインを個数順に並べる。 個数ベースではリスクの大きさが隠れてしまいます。在庫価値で並べ替え、リスクにさらされている総価値を報告してください。
滞留在庫と不動在庫を1つのリストとして扱う。 一方は需要予測の意思決定が必要であり、もう一方は処分の意思決定が必要です。ステータスフラグでこれらを分割してください。
過剰在庫を探す一方で欠品を無視する。 これらは通常、同じ購買上の問題です。両方を報告しなければ、分析レポートは単なる廃棄申請書に見えてしまいます。
システム変更後にステータス列をそのまま信用する。 まず一意の値をリストアップしてください。「不動(obsolete)」の表記が3通りあるだけで、集計値がひそかに分散してしまいます。
在庫のスナップショットと売上期間を比較する。 一方は「点」であり、もう一方は「幅」です。計算を行う前に、必ず期間を一致させてください。
意思決定を記録せずにラインにフラグを立てる。 アクションが取られないフラグは、翌四半期にさらに多くの保管コストを伴って再びフラグが立つことになります。ラインの横に決定事項を記録してください。
結論
自社の在庫回転からしきい値を導き出し、6つのチェックを順番に実行し、個数ではなく価値でランク付けし、滞留在庫と不動在庫を分割します。これこそが、在庫のエクスポートデータを購買の意思決定へと変える方法です。
コストがかかるのは、最初の分析ではありません。カタログも基準値も変動するため、レポートは再構築するのではなく、再実行可能でなければならないという点です。
四半期の時間がそこに費やされているのであれば、現在のエクスポートデータを使ってPowerdrill Bloomをお試しください。また、在庫および需要予測向けのAIツールのまとめや、サプライチェーン分析ツールのリストもご覧ください。コードを使わずに外れ値を検出する方法については、コードなしでデータセット内の外れ値を見つける方法のガイドで解説しています。ツールに関しては、CSV AIアシスタントおよびAI予測のページをご覧ください。
よくある質問
滞留在庫とは何ですか?
まだ必要であるものの、過剰に抱えている在庫のことで、過剰在庫や長期滞留在庫とも呼ばれます。まったく必要とされなくなった在庫である不動在庫とは異なります。
何日間売れなければ滞留在庫になりますか?
固定された日数はありません。全体の在庫回転を計算し、その基準値より少し上に制限を設定します。その後、リードタイム、再注文点、安全在庫に合わせて調整してください。
在庫回転はどのように計算しますか?
SLOB guideでは、在庫価値を売上高で割り、その期間の日数を掛けたものとされています。まずカタログ全体で実行して基準値を求め、次に比較のためにSKUごとに実行します。
フラグが立ったラインは、個数と価値のどちらでランク付けすべきですか?
価値(金額)です。個数ベースでは、安価な部品1,000個の方が高価な数個の製品よりも大きな問題として扱われてしまい、注視すべき場所を誤ることになります。
なぜ滞留在庫レポートに欠品を含めるのですか?
大量の滞留在庫と頻繁な欠品が同時に発生している場合、通常は1つの原因、すなわち予算が誤ったラインに割り当てられていることを示しているためです。両方を報告することで、分析が購買の意思決定へとつながります。