在庫を多めに持てば「資金を寝かせるな」と言われ、絞れば「なぜ欠品させた」と責められる。製造業の調達・購買・生産管理に共通する、出口のない板挟みです。結論から言えば、この板挟みは担当者の判断力の問題ではなく、発注量を決めるための材料が個人の頭とExcelに分散している情報構造の問題です。本記事では、適正在庫と発注点の判断がなぜ属人化するのかを業務の構造から分解し、調達OS（見積・サプライヤー管理・購買を統合する業務基盤）でそろえられる範囲と、そろえられない範囲を切り分けて整理します。発注のベテランが一人いるかどうかで在庫が変わってしまう状態から抜け出すための、最初の一歩を示します。

適正在庫とは？なぜ「持ちすぎ」も「欠品」も叱られるのか

適正在庫とは、在庫を保有するコストと、欠品によって失うコストの合計が最小になる在庫量のことです。在庫は多く持つほど保管費・資金の固定・廃却リスクが増え、少なく持つほど欠品による機会損失や特急手配のコストが増えます。一方が下がればもう一方が上がる関係のため、両者の合計が最小になる一点が存在します。これが適正在庫です。

問題は、この「一点」が固定値ではなく、需要や納期の変化で日々動くことです。現場の担当者は、動く標的に対して毎回その時点の最適解を当てにいっています。多すぎても少なすぎても叱られるのは、最適解の幅が狭く、しかも見えにくいからです。そして発注点（在庫がどこまで減ったら発注をかけるかの基準）も、本来はこの適正在庫と調達リードタイムから逆算して決まるべきものですが、実際には「だいたいこのくらいで動く」という感覚で運用されているのが実情です。

発注量の判断はなぜ属人化するのか？

発注量が属人化する直接の理由は、発注量が一つの数式ではなく、5つの変数の掛け算で決まるからです。需要予測（売れ行きの読み）、調達リードタイム（入荷までの日数）、最小発注ロット（仕入先の制約）、季節やキャンペーンによる変動、そして過去の欠品・過剰の経験。このうち、リードタイムや最小ロットは仕入先データとして比較的とらえやすい一方、需要予測と過去経験は担当者の記憶と勘に強く依存します。

「あの部品は梅雨前に動くから早めに積む」「この仕入先は表記より一週間遅れる」といった補正は、ベテランの頭の中にしかない判断ルールです。これらは台帳のどこにも書かれていないため、本人が休んだり退職したりすると、とたんに在庫が乱れます。これは調達部に限った話ではなく、設計部で起きている「探索コスト」の問題と同じ構造です。

設計部での「探索コスト」と同じ構造が、調達部では「参照と転記のコスト」として現れます。

調達OSとは——見積・サプライヤー管理・購買業務を統合する業務基盤

つまり属人化の正体は「能力の差」ではなく、判断に必要な材料（過去の入出庫、納期実績、補正ルール）が、システムではなく個人の記憶と手元ファイルに置かれているという情報配置の問題です。担当者を責めても、より頑張れと言っても、材料の置き場所が変わらない限り構造は再生産されます。

調達OSでそろえられる範囲はどこまでか

調達OSは、発注の意思決定を丸ごとAIに置き換える仕組みではありません。やることは「判断材料を一つの基盤にそろえ、誰がどんな根拠で発注したかを記録に残す」ことです。発注の最終判断は人が握ったままでも、その判断を支える材料が見える化されれば、勘は属人的なものから引き継げるものへ変わります。下表に、属人化しやすい業務がどこまで仕組みで支えられるかを整理しました。

発注に関わる業務	従来（属人運用）	調達OSでそろえられること	人に残る判断
需要予測	担当者が過去の記憶と感覚で見積もる	過去の入出庫・受注データを基準値として自動提示	新製品や特需など前例のない変動の上乗せ
リードタイム把握	「この仕入先は遅れがち」を経験で補正	仕入先ごとの納期実績を記録し平均・ばらつきを表示	取引関係や緊急度を踏まえた発注先の選択
発注点の設定	「だいたいこの残数で動く」の感覚	適正在庫とリードタイムから発注点の目安を算出	欠品許容度・保管制約を踏まえた最終調整
補正ルール	ベテランの頭の中（暗黙知）	過去の補正判断と理由をタグ付きで蓄積	ルールが効かない例外状況の見極め
発注の根拠記録	残らない（結果の数字だけ）	判断根拠を発注ごとに記録し後から参照可能	記録をどう次の判断に活かすか

ポイントは、調達OSが奪うのは「探す・転記する・思い出す」という作業であって、「どこまで在庫リスクを取るか」という判断ではないことです。判断は経営や現場の方針そのものなので、人に残すべきものです。仕組みが材料をそろえることで、担当者は本来価値である判断に時間を使えるようになります。これは見積業務の属人化を扱った過去記事でも示した切り分けと同じ考え方です。

3つ以上当てはまるなら、単価査定の属人化は個人の努力では解けない構造の問題です。

相見積の単価査定が属人化する構造——調達部の見積業務をどこまでAIエージェントに任せられるか

ERPやWMSがあるのに、なぜ発注はそろわないのか？

「在庫管理システム（WMS）も基幹システム（ERP）も入っているのに、なぜ発注はばらつくのか」という疑問はよく聞きます。理由は、ERPやWMSが記録の台帳であって、判断を支援する仕組みではないからです。現在庫や入出庫履歴は正確に記録されますが、「だからいくつ発注すべきか」「この仕入先は何日遅れるか」という判断の手前にある材料は、依然として担当者が頭の中で組み立てています。台帳があることと、判断がそろうことは別の問題です。調達OSはこの判断の手前にある材料の整備を担う点で、台帳系システムと役割が異なります。

自社の発注業務のどこが属人化しているかを30分の無料業務診断で棚卸しする

「勘の発注」を仕組みにすると、現場はかえって窮屈にならないか？

仕組み化と聞くと「ベテランの裁量が奪われ、機械の言うとおりに発注させられる」という反発が現場から出ます。これはもっともな懸念です。ただ、目的は裁量を奪うことではなく、裁量の根拠を見える化して引き継げるようにすることです。ベテランが「梅雨前に積む」と判断したなら、その判断と理由を記録に残す。次の担当者は、その記録を出発点にできます。勘を否定するのではなく、勘を資産として蓄える発想です。

もう一つの懸念は「うちは多品種少量で前例が少ないから、データで予測しても当たらない」という声です。確かに前例の少ない品目では自動算出の精度は上がりません。だからこそ、仕組みが出すのはあくまで基準値（たたき台）であり、最終判断は人が上書きする設計が現実的です。前例が少ない品目ほど人の判断比率を高く保てばよく、全自動にする必要はありません。仕組みと個別ツールのどちらから入れるべきかという論点は、業務ごとに切り分けて考えるのが定石です。

業務OSと個別ツールの選択は、二者択一ではありません。「どの業務から、どの粒度で、どの順番で」を決める設計の問題です。

業務OSと個別ツール——どちらから導入すべきかの判断フレーム

自己診断：あなたの発注業務は属人化していないか

次の5項目のうち、当てはまる数を数えてみてください。3つ以上当てはまるなら、発注の属人化は個人の頑張りでは解けない構造の問題です。

• 特定のベテランが休むと、発注量や在庫水準が目に見えて乱れる。
• 「この仕入先は遅れがち」などの納期補正が、台帳ではなく個人の記憶にある。
• 発注点（発注をかける在庫残数）が品目ごとに明文化されていない。
• なぜその数量を発注したのか、後から根拠をたどれない。
• 需要予測のもとになる過去データが、担当者個人のExcelに散在している。

次のアクション

まず取り組むべきは、自社の発注業務を「仕組みでそろえられる作業」と「人が握るべき判断」に棚卸しすることです。どの品目の、どの判断が属人化していて、その材料がどこに散らばっているかが見えれば、手を入れる順番が決まります。その棚卸しを一緒に行う場として、30分の無料業務診断を提供しています。在庫が特定の人に依存している実感がある段階で、一度棚卸しをしておくことをおすすめします。

次に読みたい関連記事

• 調達OSとは——見積・サプライヤー管理・購買業務を統合する業務基盤
• 相見積の単価査定が属人化する構造——調達部の見積業務をどこまでAIエージェントに任せられるか
• 業務OSと個別ツール——どちらから導入すべきかの判断フレーム

よくある質問（FAQ）

適正在庫と発注点はどう違うのですか？

適正在庫は「保有すべき在庫量の目安」、発注点は「在庫がどこまで減ったら発注をかけるかの基準残数」です。発注点は、適正在庫と調達リードタイム（入荷までの日数）から逆算して決まります。リードタイムが長い品目ほど発注点は高くなります。

調達OSを入れれば発注は自動化されますか？

発注判断を丸ごと自動化するものではありません。調達OSが担うのは、判断材料（過去の入出庫、納期実績、補正ルール）を一つの基盤にそろえ、根拠を記録に残すことです。最終的な発注判断は人が握る設計が現実的で、前例の少ない品目ほど人の判断比率を高く保ちます。

ERPやWMSがあれば調達OSは不要では？

ERPやWMSは在庫や入出庫を正確に記録する台帳ですが、「だからいくつ発注すべきか」という判断の手前の材料整備までは担いません。台帳があることと発注判断がそろうことは別の問題で、調達OSはこの判断支援の層を補う役割を持ちます。

出典

• 適正在庫が「保有コストと欠品コストの合計を最小化する量」であるという考え方は、経済的発注量（EOQ：Economic Order Quantity）モデルに基づく。EOQモデルは1913年にFord W. Harrisが提唱した在庫管理の古典的フレームワークである。本記事の図1は同モデルの考え方を概念的に図示したもので、具体的な数値は実データではない。
• 図2の依存度は業務構造を説明するための概念値であり、実測値ではない。