在庫管理の自動化は、欠品アラートを自分で組むところから始まる

欠品と過剰在庫のアラートは、発注点（リードタイム需要＋安全在庫）と滞留日数という2本の数式をスプレッドシートに置き、しきい値を割ったSKUだけをGASの時間主導型トリガーで拾って通知すれば自作できる。必要な列は在庫数・平均日次出荷数・リードタイムの3つだ。

欠品と過剰在庫は逆方向の問題だが、検知の仕組みは「しきい値×定時チェック×該当時だけ通知」で共通化できる
しきい値を全SKU一律の決め打ちにすると空振り通知が増え、アラート疲れで仕組みごと形骸化する。カテゴリ別の分割と調整ログが要る
SKU数の増加・季節変動・複数拠点／複数モールの在庫引当という3つの条件でこの最小構成は壊れる。壊れる手前で止める判断基準を先に決めておく

なぜ「気づいたときには遅い」が起きるのか
欠品アラートの最小構成：発注点をスプレッドシートで出す
過剰在庫アラートの最小構成：滞留日数と在庫回転率でしきい値を切る
通知を自動化する具体手順：GASの時間主導型トリガーとSlack Incoming Webhook
しきい値の決め方：決め打ちが壊れる理由とカテゴリ別の分割
誤検知を減らす調整ログの取り方
この構成が壊れる条件と、壊れたら何を導入するか
よくある質問

なぜ「気づいたときには遅い」が起きるのか

欠品も過剰在庫も、発覚するのは「終わったあと」だ。楽天RMSの在庫一覧を開いて残1になっているのを見つけたときには、その日の受注はもう取り逃している。過剰在庫のほうはさらに遅く、セール前の棚卸しや期末の在庫評価で初めて「この商品管理番号、去年から動いていない」と分かる。どちらも、在庫数という数字自体はずっと画面にあった。見に行くタイミングが遅かっただけだ。

この遅れには構造的な理由がある。在庫を「今いくつあるか」で見ている限り、判断の材料が1つ足りない。足りないのはリードタイムだ。仕入先に発注してから入庫までが7日かかるなら、在庫がゼロになる7日前に発注していなければ間に合わない。つまり本当に見るべきしきい値は「在庫0」ではなく「これから7日間で売れるであろう数＋ブレの吸収分」であり、この数字は在庫一覧のどこにも表示されていない。自分で計算して列を足さない限り、画面には出てこない。

過剰在庫側も同じ構造だ。在庫数400個という数字は、それ単体では多いのか少ないのか判定できない。1日20個売れる商品の400個は20日分だが、1日2個の商品の400個は200日分になる。在庫数を出荷ペースで割った「滞留日数」に変換して初めて、多い・少ないの判断ができる。ここでも変換をしていないから、金額として痛みが出る棚卸しまで気づけない。

そして、変換した数字を持っていたとしても、それを毎日見に行く人がいなければ検知は起きない。EC担当が1〜3名で受注・出荷指示・CS・広告運用まで回している体制では、在庫チェックは「手が空いたときにやる作業」に落ちやすい。手が空くのは、たいていトラブルが終わったあとだ。

整理すると、遅れの原因は3つに分解できる。①在庫数をしきい値に変換していない、②変換の式にリードタイムと出荷ペースが入っていない、③変換した結果を定時に見に行く仕組みがない。この3つはどれも、高価なWMSがなくても埋められる。スプレッドシートに列を足して、時計で回すだけだ。

なお、この記事が扱うのは「検知して人に知らせる」までである。各モールの在庫数を書き戻す転記作業そのものを減らす話は工程が別なので、在庫更新の半自動化の側で扱っている。受注データを取り込む工程は受注メールからの情報抽出が近い。本記事は、それらで整えた在庫データを「いつ誰が動くか」に変える部分だけを切り出す。自動発注はスコープに入れない。発注量の最終判断を人が持つべき理由は、後半のしきい値の話で書く。

欠品アラートの最小構成：発注点をスプレッドシートで出す

欠品側のしきい値は「発注点」と呼ばれる。在庫管理の実務資料でよく使われる式はこうだ。

発注点＝（1日あたり平均需要 × リードタイム）＋安全在庫
安全在庫＝安全係数 × 需要の標準偏差 × √リードタイム（定量発注方式の場合）
定期発注方式なら、√の中がリードタイム＋発注間隔になる

先に断っておくと、この式は民間の在庫管理実務資料で広く共有されている形であり、経済産業省などの公的機関が標準として定義したものではない。今回の調査では公的定義を特定できなかった。だから「これが正解の式」ではなく「まず置いてみる叩き台」として使うのが正しい。実際には、自社の欠品履歴に当てはめて係数を動かしていくことになる。

数字を入れてみる。ある定番SKUの直近90日の出荷実績が平均8個/日、標準偏差3個、仕入先のリードタイムが7日だとする。

リードタイム需要＝ 8 × 7 ＝ 56個
安全在庫＝ 1.65 × 3 × √7 ≒ 1.65 × 3 × 2.65 ≒ 13.1 → 切り上げて14個
発注点＝ 56 ＋ 14 ＝ 70個

安全係数1.65は、需要が正規分布に従うと仮定したときのサイクルサービス率95％に対応する値だ（標準正規分布の片側95％点＝1.645）。99％まで上げたいなら2.33を使う。ここを上げれば欠品は減るが、そのぶん常に多めに在庫を抱えることになる。安全係数は「欠品の痛み」と「在庫の痛み」の交換レートを自分で決めるつまみであって、正解値が外から与えられるものではない。まず95％で置き、実際に欠品したSKUだけ上げるのが現実的だ。

スプレッドシート側の列設計は、最小でこうなる。

列	中身	取得元
SKU／商品管理番号	照合キー	各モールの管理画面またはOMS
商品名	通知文に載せる	同上
在庫数	引当後の現在庫	在庫の正本にしている場所
平均日次出荷数	直近30〜90日の出荷実績÷日数	受注／出荷データ
需要の標準偏差	同期間の日次出荷のSTDEV	同上
リードタイム	発注から入庫までの日数	仕入先ごとに手入力
発注点	計算列（前掲の式）	—
滞留日数	在庫数 ÷ 平均日次出荷数	—

発注点の数式は、平均日次出荷数がD列、標準偏差がE列、リードタイムがF列なら =ROUNDUP(D2*F2 + $B$1*E2*SQRT(F2), 0) でよい。安全係数を数式に直書きせず別セルに置いておくと、後でつまみを回すのが一箇所で済む。

ここで手が止まりやすいのは、在庫数と出荷実績をどこから持ってくるかだ。在庫の正本がShopify Adminなのか、楽天RMSなのか、Amazonセラーセントラルなのか、それともOMSなのかを先に1つ決める。決めずに複数画面から寄せ集めると、数字が合わないときの切り分けができなくなる。CSVで落とす場合、列名（ShopifyならSKUと在庫数にあたる列、楽天RMSの一括編集CSVなら商品管理番号と在庫数にあたる列）は仕様変更が入ることがあるので、記憶ではなく実際にダウンロードしたファイルのヘッダ行を見て合わせる。

複数シートに分かれている場合は IMPORTRANGE で集約シートに引き、QUERY で必要な列だけ抜くのが定石だ。ただし IMPORTRANGE は参照先の権限承認が外れると該当範囲が丸ごとエラー値になり、そのときスクリプト側は「在庫0」ではなく文字列を読むことになる。後述の通知スクリプトでは、数値でないセルを黙って読み飛ばさず、件数だけ別行で報告させておくと事故に気づける。

過剰在庫アラートの最小構成：滞留日数と在庫回転率でしきい値を切る

過剰在庫側は、欠品側より1つ手前でつまずく。「何個から多いのか」を先に決められないからだ。だから在庫数のままでは切らず、時間の単位に変換する。使う指標は2つでいい。

滞留日数＝在庫数 ÷ 平均日次出荷数（何日分の在庫を持っているか）
在庫回転率＝一定期間の出荷数 ÷ その期間の平均在庫数（年間なら年何回入れ替わったか）

滞留日数はSKU単位の即時判定に、在庫回転率はカテゴリや店舗全体の健康診断に向く。アラートに使うのは滞留日数のほうだ。在庫420個・平均日次出荷2個なら滞留日数は210日。これは「今の売れ方だと、この在庫を吐き切るのに7か月かかる」という意味になる。金額に直せば、その期間ずっと現金が棚に固定されているということでもある。

ではしきい値を何日に置くか。民間のEC実務解説では、滞留の目安として衣料品30〜45日、消耗品15〜30日といったレンジが挙げられている。在庫回転率については年4〜10回転、あるいは「年6回以上なら健全」という記述が見られる。ただしこれらはいずれも公的統計ではなく、資料によって数字が違う。参考として置く程度にとどめ、自社の値をそのまま当てはめないほうがいい。

業種差の大きさも押さえておきたい。民間解説が中小企業実態基本調査をもとに算出したとする二次集計では、小売業計で売上高基準の在庫回転率が年13.0回・回転日数28.1日、原価基準で年9.1回・39.9日という試算が示されている。業種別では飲食料品小売業が年33.0回（約11.1日）、衣服・身の回り品小売業が年6.5回（約56.0日）と、5倍以上の開きがある。ただしこの集計は、調査年度と集計基準の原典を今回特定できていない。原典表を確認できていないため、社内資料への転記は避ける。

ここで確認しておくべき観点は3つある。①その数字は売上高基準か原価基準か（この集計では約1.4倍の差がある）、②業種の粒度が自社と合っているか、③公的統計か民間解説か。この3つを区別せずに「業界平均は◯回転」と社内で言うと、粗利率の違う事業と比べていることになる。

実務としては、外部の平均値より自社の分布を見るほうが早い。全SKUの滞留日数を出して降順に並べ、上位からどこで肌感覚と合わなくなるかを見る。上位数十SKUを見た時点で「これは季節品だから通知不要」「これは本当に死んでいる」の仕分けが手で付くことが多い。その仕分け結果から逆算してしきい値を置けば、外部の目安より確実に自社に合う。

もう1つ、滞留日数だけでは拾えない在庫がある。平均日次出荷数が0のSKUだ。分母が0なので滞留日数は計算できず、除算エラーか空欄になって一覧から消える。これは「最も動いていない在庫が、最も検知されにくい」という最悪の抜けになる。判定式は =IF(D2=0, "停止", ROUND(C2/D2, 0)) のように分岐させ、停止したSKUは日数ではなく「直近◯日出荷ゼロ」という別の条件で拾う。

過剰在庫の通知は、欠品ほど急がない。日次で飛ばす必要はなく、週次でまとめて十分だ。欠品は分単位で機会損失になるが、過剰在庫は昨日と今日で状況が変わらない。この「急ぎ方の違い」をトリガーの頻度に反映させておくと、通知の総量がかなり減る。

通知を自動化する具体手順：GASの時間主導型トリガーとSlack Incoming Webhook

仕組みの部品は3つしかない。①しきい値を計算するシートの列、②行を走査して該当分だけ文面を組むスクリプト、③それを定時に叩くトリガーだ。①は前の2章で終わっている。残りを埋める。

通知先は先に決めておく。ここで注意が必要なのは、日本のEC現場で長く使われてきたLINE Notifyが2025年3月31日でサービスを終了している点だ（LINE公式の終了案内による）。2025年4月1日以降は機能を利用できないため、いま新規に組むならこの選択肢は最初から外す。ネット上に残る解説記事はLINE Notify前提のものが多いので、コードをコピーする前に発行日を見たほうがいい。現行の選択肢は2つになる。

Slack Incoming Webhook：Slackを使っているなら第一候補。SlackアプリでIncoming Webhooksを有効化し、投稿先チャンネルを選んでWebhook URLを発行する。ランニングコストは発生しない
LINE Messaging API：LINEへ通知を残したい場合の正式な移行先。ただし無料メッセージ通数（2026年8月時点でコミュニケーションプラン月200通）を超える分は追加送信できず、月額の有料プランへ変更する必要がある。従量課金の追加メッセージが使えるのは上位プランのみで、通数と料金は改定されるため公式の料金ページで現行値を確認すること

Slack Webhook URLはコードに直書きしない。Apps Scriptエディタの「プロジェクトの設定」→「スクリプトプロパティ」に SLACK_WEBHOOK_URL として保存し、コードからは名前で引く。シートを共有した相手に通知先が漏れるのを防げるうえ、テスト用チャンネルへの切り替えも1箇所で済む。

スクリプトは、スプレッドシートの「拡張機能」→「Apps Script」から作る。中身は40行に満たない。

function checkStock() {
  const sh = SpreadsheetApp.getActive().getSheetByName('在庫');
  if (sh.getLastRow() < 2) return;
  const rows = sh.getRange(2, 1, sh.getLastRow() - 1, 8).getValues();
  const shortage = [];
  const dead = [];
  let broken = 0;

  rows.forEach(r => {
    const [sku, name, stock, avg, sd, lt, rop, days] = r;
    if (typeof stock !== 'number' || typeof rop !== 'number') { broken++; return; }
    if (stock <= rop) shortage.push(sku + ' ' + name + '｜在庫' + stock + ' / 発注点' + rop);
    if (typeof days === 'number' && days >= 120) dead.push(sku + ' ' + name + '｜滞留' + days + '日');
  });

  const lines = [];
  if (shortage.length) lines.push('■発注点割れ ' + shortage.length + '件\n' + shortage.join('\n'));
  if (dead.length) lines.push('■滞留 ' + dead.length + '件\n' + dead.join('\n'));
  if (broken) lines.push('※数値として読めない行が ' + broken + ' 件あります');
  if (!lines.length) return;

  const url = PropertiesService.getScriptProperties().getProperty('SLACK_WEBHOOK_URL');
  UrlFetchApp.fetch(url, {
    method: 'post',
    contentType: 'application/json',
    payload: JSON.stringify({ text: lines.join('\n\n') })
  });
}

設計上のポイントは3つある。1つ目は getRange で範囲を一括取得して getValues() で配列にしていること。行ごとにセルを読みに行くとAPI呼び出しが行数分発生し、SKUが増えた瞬間に実行時間の壁に当たる。2つ目は if (!lines.length) return; で、該当0件のときは何も送らないこと。「本日、異常はありません」という通知を毎日送ると、それだけでアラート疲れが始まる。3つ目は、読めなかった行を握りつぶさず件数だけ報告していること。IMPORTRANGE の権限切れや列ズレは、無言で「該当0件」に化けるのが一番怖い。

トリガーはエディタ左の時計アイコン（トリガー）から「トリガーを追加」を開き、実行する関数に checkStock、イベントのソースに「時間主導型」を選び、日タイマーで時刻帯を指定する。欠品側は出荷業務が始まる前の朝、過剰在庫側は週タイマーで週1回、というように関数とトリガーを分けておくと頻度を別々に調整できる。

クォータは把握しておく。Google公式のApps Scriptクォータでは、1回のスクリプト実行時間の上限は6分、トリガーによる1日の合計実行時間は無料アカウントで90分、Google Workspaceアカウントで6時間とされている（いずれも2026年8月時点）。日次のチェック程度で当たる数字ではないが、SKUが数千行に増えて1回の処理が数分かかるようになると6分の壁が視野に入る。なお、時間主導型トリガーの最短実行間隔については、公式のクォータページ上で明示の下限を確認できなかった。短い間隔で回しすぎると Service invoked too many times in a short time というエラーで止まることが実務上知られているので、分単位で回す設計にするなら少しずつ間隔を詰めて挙動を確かめたほうがいい。

動いているかどうかの確認は、エディタ左の「実行数」で見る。ここに実行履歴が並ばない状態は、成功ではなく「トリガーが登録されていない」か「エラーで止まっている」かのどちらかだ。通知が来ないことを正常と読み違えないよう、組んだ直後に一度しきい値をわざと緩めて、通知が飛ぶことを確認しておく。

しきい値の決め方：決め打ちが壊れる理由とカテゴリ別の分割

ここが、この仕組みが形骸化するかどうかの分岐点になる。よくある壊れ方は「在庫が残り10個を切ったら通知」を全SKUに一律で適用することだ。なぜ壊れるかは、2つのSKUを並べれば分かる。

	SKU-A（定番・回転が速い）	SKU-B（低回転の長尾商品）
平均日次出荷	8個	0.5個
リードタイム	7日	3日
本来の発注点	70個	約4個
一律10個で切ると	60個分の手遅れ。気づいた時点で欠品が確定している	20日分の在庫があるのに通知が鳴り続ける

同じ「残り10個」が、片方では遅すぎ、片方では早すぎる。厄介なのは、実害の出方が非対称なことだ。SKU-Aの手遅れは静かに機会損失になるだけで、通知は来ない。一方SKU-Bは毎日通知を出し続ける。結果として担当者が体感するのは「役に立たない通知ばかり来る」であり、欠品を取り逃していることには最後まで気づかない。アラート疲れが危険なのは、通知が読まれなくなること自体より、この非対称性を隠してしまう点にある。

対処は、しきい値をSKUごとに持つことだ。前章の式を全行に入れれば、発注点は自動的にSKUごとに変わる。手で決めるのは安全係数のほうだけでよく、それもSKU単位ではなくカテゴリ単位で持つ。分割の軸は3つまでに絞る。増やすほど運用が回らなくなる。

リードタイム帯（国内翌日／国内数日／海外・船便）：√リードタイムの効き方が変わる。海外仕入れは安全係数を上げる対象になりやすい
出荷ペース帯（定番／中位／長尾）：長尾は需要のブレが平均に対して大きく、正規分布の前提が崩れやすい。式より実績優先で手当てする
季節性の有無（通年／季節品）：季節品は平均日次出荷の算出期間そのものを変える必要がある

この3軸で切ると、カテゴリは多くても10前後に収まる。安全係数の一覧を別シートに置き、在庫シートからは VLOOKUP で引く。カテゴリ列は最初こそ手で埋めることになるが、一度埋めれば以後は新規SKU登録時に1セル入れるだけになる。

しきい値を決めるとき、もう1つ先に決めておくべき数字がある。「1日に何件までなら実際に読むか」だ。通知は読まれて初めて意味を持つので、読める上限のほうが制約条件になる。仮に1日10件と決めたなら、初期のしきい値は10件前後に収まるところから始め、そこから広げていく。何件が正しいかの根拠は外部にはない。重要なのは、上限を先に決めておくこと自体だ。上限を決めずに組むと、通知件数は増える方向にしか動かない。

最後に、発注点を自動発注に直結させないことを勧めておく。発注点は「そろそろ動く時期だ」というトリガーであって、発注量ではない。実際の発注数は、仕入ロット、送料無料ライン、賞味期限や消費期限、次のお買い物マラソンやスーパーSALEの予定、モール側のクーポン原価やポイント原価の見込みまで含めて決まる。これらは式に入っていない。検知は機械に、量の決定は人に、という切り分けが最小構成としては正しい。

誤検知を減らす調整ログの取り方

しきい値は一度決めて終わりにならない。だが「なんとなく緩める」を繰り返すと、半年後には誰も根拠を説明できない数字が残る。防ぐには、通知に対して取った行動を記録するしかない。ここでの誤検知の定義はシンプルでいい。通知が来たのに、発注も値引きも棚移動もしなかったものを空振りとする。

ログはシートを1枚足すだけでよく、列は6つで足りる。

列	入れるもの
日付	通知を受けた日
SKU／カテゴリ	どのカテゴリで鳴ったか
種別	発注点割れ／滞留／読めない行
対応	発注した／値引きした／何もしなかった
何もしなかった理由	下の3分類から選ぶ
変更したパラメータ	安全係数 1.65→2.05 のように変更前後を書く

肝は「何もしなかった理由」を3つに分類することだ。どれに当たるかで、打つ手がまったく違う。

①しきい値が緩い：在庫は実際に十分あった。これだけが、しきい値を動かしてよい理由になる
②データが間違っていた：シート上の在庫数が実態と違う、平均日次出荷の算出期間にセール期間が混ざっている、など。この場合にしきい値をいじってはいけない。データの問題をしきい値で殴ると、正しい通知まで消える
③しきい値は正しいが行動できない：廃番になった、仕入先が長期休みに入っている、次回入荷が決まっている。これはSKUを一時的に対象外にする話であり、除外リスト列を持たせて解除予定日を必ず入れる。期限のない除外は、そのまま忘れられる

レビューは週1回、15分で足りる。見るのは空振り率（空振り件数÷通知件数）と、その内訳が①②③のどれに寄っているかだけだ。②が多いなら直すのはデータ側であり、③が多いなら直すのは対象SKUの範囲であって、いずれもしきい値の問題ではない。

パラメータを変えるときのルールは1つでいい。一度に1つだけ動かす。安全係数とカテゴリ分割を同時に変えると、どちらが効いたのか分からなくなり、次に迷ったとき戻す先がなくなる。変更後は2週間、変更前と同じ指標を並べて見る。

そして、通知件数からは絶対に見えない指標を1つ足しておく。見逃しだ。欠品が起きたのに通知が来ていなかったケース、滞留品を棚卸しで初めて見つけたケースを、月次で数える。空振りだけを見て調整を続けると、しきい値は必ず厳しい方向へ寄り、通知は静かになり、そして冒頭の「気づいたときには遅い」に戻る。空振りと見逃しは両方記録して初めて釣り合いが取れる。

この構成が壊れる条件と、壊れたら何を導入するか

ここまでの構成は、スプレッドシート1枚とGAS40行で成立する。ただし万能ではない。壊れる条件は事前にはっきりしているので、先に書いておく。

1つ目はSKU数だ。行数が増えると、1回の実行が前章のクォータ（6分）に近づく。まず効くのは走査対象を絞ることで、直近90日で1件も動きのないSKUは日次の欠品チェックから外し、週次の滞留チェックだけに回せば対象は大きく減る。それでも収まらないなら、シートを分けて関数を複数のトリガーに分散させる。分散の設計を考え始めた時点で、この仕組みは自作の適正範囲を超えかけている。

2つ目は季節変動だ。平均日次出荷を「直近30日」で固定すると、お買い物マラソンやスーパーSALEを跨いだ瞬間に平均が跳ね上がり、発注点も跳ね上がる。イベント明けに全SKUがいっせいに発注点割れの通知を出すのはこれが原因だ。逆にイベント直前は平均が低く出て、最も欠品してはいけないタイミングで発注点が緩む。対処は、算出期間からイベント期間を除外するか、前年同期の実績を併用するかになる。どちらにしても季節品は式だけでは持てない。人が予定を入れる欄が要る。

3つ目は複数拠点・複数モールの在庫引当だ。モールごとに在庫を振り分けて登録している場合、合算値だけ見ていると「全体では足りているのに楽天の割当分だけ枯れている」状態を検知できない。逆に共通在庫でモールを跨いで販売しているなら、問題は数量ではなく引当のタイミングのズレ（売り越し）に移る。どちらの場合も、しきい値の精度以前に「在庫の正本はどこか」の設計問題になっている。

やめどきのサインは3つに整理できる。①通知を受けた後の対応が、シート以外のシステムを開かないと完結しなくなった。②シートを更新する人が自分以外にも増え、権限と版の管理が必要になった。③実行時間や IMPORTRANGE のエラー対応が、月次の定例作業になった。このいずれかが出たら、直すべきはしきい値ではなく道具のほうだ。

では何を入れるか。ここは製品名で決めず、観点で決める。拠点数はいくつか、販売チャネル数はいくつか、引当ロジックはモール別か共通か、同時に在庫を触る人は何人か、そして在庫の正本を受注管理側（OMS）に寄せるのか庫内管理側（WMS）に寄せるのか。この5つを紙に書いてから比較検討に入ると、機能一覧の比較で迷う時間がかなり減る。料金や機能は改定が入るので、必ず各社の現行の資料で確認すること。

ここまで読んで分かるとおり、この仕組みで本当に難しいのはコードではない。しきい値をどう決め、どこで自作をやめるかという判断のほうだ。そしてその判断は、在庫管理ツールの操作スキルではなく、自社の商材とリードタイムを知っている人にしか下せない。EC担当者の市場価値は、何で決まっているのかで書いたとおり、代替されにくさが宿るのはこの層である。

まず1つだけやるなら、在庫シートに「滞留日数」の列を足すところから始めるといい。式は在庫数を平均日次出荷数で割るだけで、通知もトリガーもまだ要らない。降順に並べ替えて上から10行を眺めた時点で、今日発注すべきSKUと、来週値引きを考えるべきSKUの両方が見えるはずだ。仕組みはそのあとでいい。

関連記事：在庫管理を自分で組める人は、社内で何を評価されているのか。EC担当者の市場価値は、何で決まっているのか

よくある質問

Excelしか使えない環境でも同じことはできますか

計算式の部分はそのまま使えます。詰まるのは定時実行の部分で、Excelマクロ（VBA）やタスクスケジューラで組む場合、そのPCが起動していないと動きません。Microsoft 365環境ならPower Automateのスケジュール実行とTeams通知の組み合わせが近い構成になります。いずれにせよ「誰のPCにも依存せず定時に動くか」を先に確認してください。

通知先をLINEにしたいのですが

LINE Notifyは2025年3月31日でサービスを終了しているため使えません。LINEへ送るならLINE Messaging APIが正式な移行先ですが、無料通数を超えると追加送信はできず、有料プランへの変更が必要になります（従量課金は上位プランのみ）。無料通数と料金は改定されるため、実装前に公式の料金ページで現行の条件を確認してください。社内向けの在庫通知であれば、コストがかからないSlack Incoming Webhookのほうが素直です。

発注点はどのくらいの頻度で見直すべきですか

頻度で決めるより、きっかけで決めるほうが運用が続きます。見直すべきタイミングは、仕入先のリードタイムが変わったとき、欠品が実際に起きたとき、季節の変わり目、そして大型セールの前後の4つです。これらのタイミングで安全係数と算出期間だけを確認すれば足ります。定例で全SKUを見直す運用は、規模が小さいうちから続きません。

通知が多すぎるとき、最初に何を直せばいいですか

しきい値を触る前に、直近2週間の通知を「何もしなかった理由」で3分類してください。データの誤り（在庫数が実態と違う、算出期間にセールが混ざっている）が原因なら、しきい値を緩めても解決せず、正しい通知まで消えます。分類してみて①のしきい値が緩いケースが多数を占めていた場合に限り、カテゴリ単位で安全係数を動かします。