ChatGPTでIT予備部品の在庫水準を予測する方法

結論から言うと： 十二か月分の払い出し記録を日付・拠点・部品番号つきで書き出し、供給リードタイムと部品ごとの重要度区分を添えたうえで、ChatGPTに文章で見積もらせるのではなくコードを実行させて発注点を計算させます。半日で、拠点ごとの根拠ある発注点が手に入ります。まだ起きていない故障についての警告は、何も手に入りません。

予備部品の在庫は、誰もが記憶で解いている問題です。現場の技術者は支店が電源ユニットをよく食うことを知っている。運用責任者は、前回ペナンでスイッチが壊れたとき交換に三週間かかったことを覚えている。二人の頭の中の模型はうまく機能します——その人が休暇に入るまでは、あるいは対象規模が倍になるまでは、あるいは経理から「なぜ棚の上に数千万円が寝ているのか」と問われるまでは。

その模型を置き換える計算は難しくありません。どの運用管理の教科書にも載っている標準的な在庫数学です。妨げているのは、データが誰も集計したことのない払い出しの書き出しの中にあること、そしてその計算を部品ごと・拠点ごとに繰り返す必要があること——つまり、決してその週の優先順位の上位に来ない種類の面倒さです。

これはChatGPTの良い使い道です。ただし、産物に価値があるかどうかを決める重要な前提が一つあります。後述します。

予備部品の在庫が失敗する二つの型

向きが逆であり、だからこそ直感では扱いにくいのです。

寝ている資本。 すでに担当していない対象向けに買った部品、退役させた機種、悪い月のあとの慌てた発注。損益計算書には見えず、棚卸しでは一目瞭然です。十八か月動いていない部品が棚を埋め、その一部はメーカー保守も終わっている。

手元になかった一点。 支店が止まり、交換品は宅配で四日先、売っているSLAは翌営業日。高くつくのはこちらの失敗です。部品の値段ではなく、停止が顧客に与える損害と、信用に与える損害のためです。

チームは直近で痛かったほうへ過剰に振れます。ひどい欠品は一年分の過剰発注を招き、棚卸しの除却は次の停止まで在庫を絞らせます。計算をする目的は精度そのものではなく、この振り子を止めることです。

モデルに何を渡すか——そして実際に何を計算させるか

実際に必要なデータは何ですか

思われているより少ないのですが、形は正しくなければなりません。

部品別・拠点別・日付つきの消費履歴。 最低十二か月。季節性も拠点差も、それより短い窓では見えません。出所は払い出し記録——チケットや作業に対して部品を出した一件一件です。数量と日付が要り、チケットの本文は要りません。

部品ごとの供給リードタイム。 カタログ値ではなく、発注から実際に棚に載るまでの実測時間で、アジア域内で部品を越境させるなら通関も含めます。この一連の作業で最も記録されていない数値であり、答えを最も大きく動かす数値でもあります。

部品ごとの重要度区分。 二〜三段階で十分です。壊れると拠点が止まる部品と外装部品とでは必要な水準が違い、区分がなければモデルはノートPCの充電器とコアスイッチの電源を同じ問題として扱います。

拠点の前提。 どの拠点があり、それぞれ概ね何台あり、近隣の拠点からSLA内で供給できるか。中央に置いた部品は複数拠点を守れますが、四時間以内に現地で必要な部品はそうではありません。

入力はこれだけです。含まれていないものに注目してください。顧客名、チケットの記述、技術者名、価格。落としてください。リスクを増やすだけで、計算には何も寄与しません。

「ChatGPTに発注点を聞く」が小手先ではなく統計の問題である理由

ここから先すべての品質を決める前提です。

発注点とは、リードタイム中の平均需要に、需要のばらつきと守りたい水準に応じた安全在庫を足したものです。これは計算です——そして文章で見積もれと言われた言語モデルは、それらしく見えるが何の計算結果でもない数字を出します。危険なくらいの頻度で、だいたい合ってしまいます。

対処は、記憶から答えさせるのではなく、コードを書いて実行させることです。CSVを渡し、部品別・拠点別に、リードタイム窓の平均需要、そのばらつき、指定した水準での安全在庫、そこから導かれる発注点、推奨発注量を計算させます。結論だけでなく中間値も出させ、データについて置いた前提を明示させてください。

これで二つのことが得られ、どちらも重要です。過程を検算できること——中間の列があれば、分かっている人が「本当に計算されたのか、語られただけか」を確認できます。そして前提を一つ変えて数秒で再計算できること。本当の洞察はここにあります。目標水準を95%から99%に動かしたとき在庫金額がどう変わるかを見るほうが、単一の推奨値より役に立ちます。

計算以外でモデルが効くのは、その周りの雑然とした部分です。表記の揺れた部品名を読んで同等品をまとめる、ある拠点の三月の消費が三倍になっていることに気づく、履歴が少なすぎて計算しても意味のない部品に印を付ける。

実例——十二か月の払い出しデータを拠点別の発注点に変える

あるMSPが、中央倉庫一つと地域倉庫二つで、三か国22拠点のハードウェアを保守しています。払い出しの書き出しは約4,000行。日付、拠点、部品番号、数量、チケット参照。リードタイムは調達から別表で提供され、重要度は三区分をサービスマネージャーが半日で付けます。

一巡目は処方ではなく診断です。 部品別の消費はおなじみの形になります。少数の部品が動きの大半を占め、長い裾に年一〜二回しか動かない部品が並ぶ。有用な発見は裾のほうです。それらの部品に予測は意味を持たず、判断は計算ではなく方針の問題になります。保険として一つ持つか、リードタイムを受け入れるか。

発注点の計算は動く部品に対して行います。 各部品について、自身のリードタイムにおける平均需要、ばらつき、区分の水準に応じた安全在庫、発注点、発注量。たいてい二つが意外に映ります。動きの速い安価な部品は需要が安定しているぶん想定より緩衝が要らず、動きの遅い重要部品のいくつかは、長いリードタイムが小さなばらつきさえ増幅するため、より多く必要になります。

拠点別に見ると総量が変わります。 22拠点を合算すると数字は落ち着いて見えますが、分解すると絵が変わります。中央に置いた部品では、一日かかる拠点の四時間SLAは満たせないからです。重要な産物は部品ごとの発注点そのものではなく、部品ごとにどこへ置くかの判断であり、それは消費データではなくサービス上の約束によって決まります。

最後は在庫金額の比較で締めます。 現在の保有と、モデルが示す保有を、区分別に。現実的な結果は劇的な削減ではなく、再配分です。緩衝が過剰だった高回転品から資本を引き、静かに手薄だった少数の重要部品へ回す。

AI支援の予測 vs 在庫管理システム vs 技術者の勘

• 根拠ある数字が出るまでの速さ — AI支援の予測が有利。半日で済み、新しいツールの導入も要りません。
• 表記の揺れた部品名や雑な書き出しへの強さ — AI支援の予測が明確に有利。「PSU 650W」「650w電源」と部品コードを一つの品目にまとめるのは得意分野です。
• その数字がなぜその値なのかを説明する — 過程を開示させるならAI支援の予測が有利。勘は財務責任者に自分を説明できませんし、多くのシステムは閾値を表示するだけです。
• データに入っていないことを知っている — 技術者の勘が有利で、これは小さな領域ではありません。拡張予定の拠点、生産終了が近い機種、静かに当てにならない仕入先。
• 日々の在庫を正確に保つ — 在庫管理システムの圧勝。予測は閾値を決め、システムは残高を追い、閾値を割ったときに知らせます。
• 誰かが覚えていなくても行動につながる — システムが有利。入出庫に連動した自動の在庫下限アラートこそ、計算された発注点を実際の発注に変える仕組みです。

正直な推奨は組み合わせです。予測で閾値を決め、その閾値を在庫水準を見張り続けるものの中に置く。表計算の中の発注点は、誰も見ない数字です。

予測が壊れる場所

四つあり、これを知っていることが使いこなしの大半です。

履歴のない部品。 新しいハードウェアには消費記録がなく、計算の足場がありません。メーカーの故障率指標と、置き換えた機種の実績を使い、その数字は計算値と同じ列に並べず、推定値として明記してください。

生産終了が近い部品。 退役予定のプラットフォーム向けの部品は需要が落ちますが、入手性はもっと速く落ちます。最終購入の判断は予測ではなく、退役計画についての判断です。

一拠点が支配的な場合。 単一の大拠点が消費の大半を占めるなら、合算した統計はその拠点を説明しているだけです。分けてモデル化してください。

不良ロット。 ファームウェアの不具合や不良ロットは需要の山を作りますが、それは傾向ではありません。履歴に残したままだと、以降のすべての推奨値を押し上げます。外れ値を特定させ、除外するかどうかを意識的に決めてください。これは判断であり、自覚的な判断であるべきです。

ここを外さない——業務データ、仕入条件、そしてITに相談すべき時

実務上の三点です。

書き出しに何が入っているかを把握する。 払い出し記録にはたいていチケット参照が付き、そこから顧客名、拠点住所、時には利用者名までたどれます。予測に必要なのは日付、部品番号、数量、拠点識別子だけです。ファイルが環境を出る前に他を落とし、ビジネス版かエンタープライズ版を使い、その階層の現行のデータ取り扱いと学習の条件を「たぶん」で済ませず確認してください。消費者向けは異なることが多く、条件も変わります。

仕入条件は商業的に機微です。 リードタイムと発注単位は、あなたの交渉上の立ち位置を示唆します。開示が破滅的というわけではありませんが、調達表を見ずに貼るのではなく、意識して決める価値があります。仕入先名を仕入先コードに置き換えても、失うものはありません。

予測は小さいほうの半分です。 在庫を正しい場所に置き、拠点間で動かし、技術者が実際に消費した分と払い出した分を突き合わせ、アラートが停止に変わる前に発注する——それが運用の本体であり、それを担うのが私たちのAI+サポートとマネージドITサポートです。Brocentは2007年の北京での創業以来アジアでマネージドITを提供しており、本社はシンガポール、2016年から香港にも拠点があります。これを自分で繰り返す分析としてではなく、マネージドサービスとして運用するとどうなるかは、アジアにおける予備部品管理とハードウェア保守で扱っています。

よくある質問

予測が意味を持つには、どれくらいの消費履歴が必要ですか

実務上の下限は十二か月です。季節性を捉えられ、ばらつきが本物か短い窓の産物かを見分けられます。六か月あれば区分単位の粗い見立ては作れます。それ未満は雑音に模様を見ているだけで、メーカーの故障率を使い、推定値だと明記するほうが誠実です。

リードタイムが十二週の部品も扱えますか

扱えますし、長いリードタイムこそ計算が最も効く場面です。ばらつきはリードタイムの窓の中で積み上がるので、地味な部品でも驚くほど高い安全在庫が正当化されることがあります。より大きな制約は商業面です。十二週を完全に埋めるための寝かせる資本が、避けたいリスクより高くつくこともあり、その取捨は計算ではなく判断です。

AIに発注させてよいですか

いけません。推奨と根拠を出させ、承認は人が持ってください。発注は仕入条件に基づく資金の約束であり、モデルが持っていない文脈——終わりかけの契約、閉じる拠点、置き換わるプラットフォーム——に依存します。自動化するのはアラートであって、購買ではありません。

一度も消費したことのない部品はどうしますか

定義上、予測の外側です。保険の判断として扱ってください。この部品は何を守るのか、その停止はいくらか、一つ持つといくらか。明らかに持つべきものと明らかにそうでないものがあり、モデルは問いを整理できても、代わりに答えることはできません。

複数の国にまたがっても成り立ちますか

計算は拠点ごとに成り立ちます。国境をまたいで変わるのはリードタイムです。通関、輸入関税、規制品の扱いは、仕入先自身の出荷時間より大きなばらつきを生むことがあります。全社一律の数値ではなく、国ごとの実測のドア・ツー・ドア時間を使ってください。さもないと安全在庫が両方向に同時に狂います。

これをやれば在庫システムは要りませんか

予測は閾値がいくつであるべきかを教えますが、現在の残高は知らず、閾値を割ったことを誰にも伝えません。入出庫をチケットに紐づけて記録し、拠点別に残高を持ち、在庫下限アラートを出す仕組みこそが、数字を行動に変えます。予測が目標を決め、システムがそれを守らせます。

まずどこから

重要度区分を一つ——壊れると拠点が止まる部品——を選び、そこだけで計算を回してください。品目数は多くなく、データも扱える量で、そして本当に重要な問いに答えが出ます。外すと高くつく部品について、適切な緩衝を持てているか。数字は妥当だが閾値を割ったことを知らせるものが何もない、という結論なら、それは分析ではなく運用の欠落です。お問い合わせください。