スプレッドシートで在庫管理をしている場合、「現在の在庫数」を把握すること自体はそれほど難しくありません。入出庫を記録していけば、在庫数は自動的に可視化できます。
一方で難しいのは、「いつ・何個発注するか」という判断です。
- どのくらいのペースで売れているのか
- 発注してから届くまでの間に在庫が尽きないか
- 最近の売れ行きに変化はないか
こうした要素を踏まえて発注数を決める作業は、担当者の経験や感覚に頼っている現場も多いのではないでしょうか。
そこで本記事では、スプレッドシート (Google Sheets を使用)に蓄積した販売データと在庫数をもとに、自動化ツールであるn8nと生成AIを用いて適切な発注数を予測し、通知まで行う一連の自動化フローを作成しました。今回はその全体像と各手順を解説します。
【目次】
- チームへの共有やあとで見返す用にこの記事まるごとダウンロードできます
- n8n・AI・スプレッドシートで作る在庫管理システムの全体像
- 在庫管理システムで扱うスプレッドシートのデータ構成
- 在庫管理システムの各手順の詳細
- 実際の使用結果例
- ワークフロー使用時の注意点
- まとめ
チームへの共有やあとで見返す用にこの記事まるごとダウンロードできます
n8n・AI・スプレッドシートで作る在庫管理システムの全体像
今回は、スプレッドシートから現在の商品の在庫状況、および直近30日間・7日間の販売履歴を取得し、生成AIにそこから分かる販売傾向をもとに今後の需要量と必要な発注数を予測させ、発注が必要なものはSlackに通知する形としました。
一連のワークフローの全体像は以下の通りです。
ここでは、スプレッドシート、n8n、生成AIを以下のように役割分担しています。
- スプレッドシート：商品マスタ・販売履歴・予測結果などのデータを保存
- n8n：スプレッドシートからデータを取得、生成AIによる予測など、ワークフロー全体の制御
- 生成AI：取得したデータから直近の販売傾向を分析、発注数を予測
また、本ワークフローは以下の3つの流れで自動化を行います。
1．データ取得：商品マスタに加え、販売履歴から商品ごとの販売実績（30日間の平均販売数・7日間の平均販売数）を集計し、生成AIに利用する
2．発注数の予測：取得したデータをもとに、生成AIが傾向を分析して発注数を予測する
3．結果の保存、通知：予測した発注数を保存し、発注が必要な商品はSlackで担当者へ通知する
在庫管理システムで扱うスプレッドシートのデータ構成
今回は、3つのシートを使用します。各シートの構成は以下の通りです。
products（商品マスタ）
列名 | 内容 |
|---|---|
product_id | 商品ID |
product_name | 商品名 |
category | カテゴリ |
current_stock | 現在庫数 |
safety_stock | 安全在庫数 (最低在庫数) |
lead_time_days | リードタイム (発注から入荷までの日数) |
unit_price | 単価 |
supplier | 仕入先 |
sales_history（販売履歴）
列名 | 内容 |
|---|---|
date | 販売日 |
purchase_id | 購入ID |
product_id | 商品ID |
quantity | 販売数量 |
purchase_recommendations（発注予測の保存先）
列名 | 内容 |
|---|---|
calculated_at | 算出日時 |
product_id | 商品ID |
product_name | 商品名 |
current_stock | 現在庫数 |
avg_30_quantity | 30日間の平均販売数 |
avg_7_quantity | 7日間の平均販売数 |
lead_time_days | リードタイム (発注から入荷までの日数) |
safety_stock | 安全在庫数 (最低在庫数) |
forecast_demand_daily | 1日あたりの予測需要数 |
recommended_quantity | 最終的な推奨発注数 |
reason | 理由 |
在庫管理システムの各手順の詳細
スプレッドシートからのデータ取得・整理
データを取得し、生成AIで扱う形へと整理する流れは以下の通りです。
各ノードを順に解説します。
- 「Schedule Trigger」：指定した時刻をトリガーにワークフローを開始します。以下の例では、毎朝6時にワークフローが実行されるように設定しています。
設定例：
項目 | 設定値 |
|---|---|
Trigger Interval | Days |
Days Between Triggers | 1 |
Trigger at Hour | 6am |
Trigger at Minute | 0 |
- 「Get row(s) in sheet」：対象のシートを指定し、行単位でデータを取得します。
設定例：
項目 | 設定値 |
|---|---|
Resource | Sheet Within Document |
Operation | Get Row(s) |
Document | スプレッドシート名 |
Sheet | products / sales_history |
- 「Filter」：「Get row(s) in sheet」では販売履歴をすべて取得しているため、このノードで「直近30日」と「直近7日」をそれぞれ抽出します。「Get row(s) in sheet」ノードから2つに分岐させ、それぞれ設定します。
条件設定：
{{ $json.date }} is after {{ $now.minus({days:31}).toFormat('yyyy-MM-dd') }} (30日間)
{{ $json.date }} is after {{ $now.minus({days:8}).toFormat('yyyy-MM-dd') }} (7日間)
- 「Summarize」：product_id ごとに販売数量を合計します。
設定例：
項目 | 設定値 |
|---|---|
Aggregation | Sum |
Field | quantity |
Fields to Split By | product_id |
- 「Edit Fields｜avg_30(7)days」：それぞれ30(7)日間における1日あたりの平均販売数を計算し、product_id とあわせてデータを保持します。
設定例：
名前 | 形式 | 値 |
|---|---|---|
product_id | String | {{ $json.product_id }} |
avg_30(7)_quantity | Number | {{ $json.sum_quantity/30(7) }} |
- 「Merge」：2つのデータを product_id をキーに結合します。Mergeノードの「Combine」は2つのデータしか扱えないため、30日間の平均販売数と7日間の平均販売数の結合、およびそれらと商品マスタの結合で、Mergeノードを2つ使用します。最終的には、各商品のレコード末尾に平均販売数が追加される形になります。
設定例：
項目 | 設定値 |
|---|---|
Mode | Combine |
Combine By | Matching Fields |
Fields to Match | product_id |
Output Type | Keep Everything |
ここまでで、生成AIの予測に必要なデータを整理します。
生成AIによる発注数予測
今回は、Google Gemini を用いて発注数を予測します。
生成AIに渡すプロンプトには、ここまで整理した以下の項目を入力データとして含めます。
商品ID: {{ $json.product_id }}
商品名:{{ $json.product_name }}
現在庫数:{{ $json.current_stock }}
30日間の平均販売数:{{ $json.avg_30_quantity }}
7日間の平均販売数:{{ $json.avg_7_quantity }}
安全在庫数: {{ $json.safety_stock }}
リードタイム: {{ $json.lead_time_days }}
また、プロンプト内で次の方針も明示します。
30日間の平均販売数と直近7日間の平均販売数を比較し、販売傾向を分析すること
7日間の平均販売数と30日間の平均販売数の乖離や販売傾向の方向性を踏まえて1日あたりの需要を予測すること
最近の販売増加/減少が一時的な変動である可能性も考え、根拠が弱い場合は過度に見積もらないこと
1日あたりの予測需要数とリードタイムを考慮して必要な発注数を計算すること
在庫過多によるコストと欠品のリスクの両方を考慮し、過剰な発注を避けること
1日あたりの予測需要数は小数点1桁、最終的な推奨発注数は整数とすること、発注不要な場合は0とすること
それぞれの平均の評価、1日あたりの予測需要数、最終的な推奨発注数を理由に必ず明記すること
これにより、販売傾向の分析から需要の予測、推奨発注数の算出までを、過去の販売実績だけでなく、現在庫数・リードタイム・安全在庫数 (最低在庫数)も踏まえて総合的に判断できるようになります。また、発注コストを意識し、在庫が残ってしまうリスクや過剰な発注を考慮したうえで予測をしています。
出力は必ずJSON形式とし、出力のキー名を purchase_recommendations のシートの列名に統一するよう、以下をプロンプトに明示します。
{
"calculated_at": "{{ $now.setZone('Asia/Tokyo').toFormat('yyyy-MM-dd HH:mm:ss') }}",
"product_id": "商品ID",
"product_name": "商品名",
"current_stock": 現在庫数,
"avg_30_quantity": 30日間の平均販売数,
"avg_7_quantity": 7日間の平均販売数,
"lead_time_days": リードタイム,
"safety_stock": 安全在庫数,
"forecast_demand_daily": 1日あたりの予測需要数,
"recommended_quantity": 最終的な推奨発注数,
"reason": "日本語で1〜2文で簡潔に記載。30日間の平均販売数と7日間の平均販売数をどのように評価したか、1日あたりの予測需要数、最終的な推奨発注数は必ず明記すること。発注不要の場合はその旨を記載すること。"
}
これにより出力が統一され、以降のワークフローでのエラー発生を防止します。
「Google Gemini」 ノードでは「Output Content as JSON」のトグルをオンにすると、出力形式が自動的にJSONになります。
なお、このノードで使用したプロンプトの全文はこちらからダウンロードいただけます。
スプレッドシートへの結果保存と通知
生成AIが予測した結果を保存し通知する流れは、以下の通りです。
- 「Append or update row in sheet」：結果を purchase_recommendations シートに追加します。
設定例：
項目 | 設定値 |
|---|---|
Resource | Sheet Within Document |
Operation | Append or Update Row |
Document | スプレッドシート名 |
Sheet | purchase_recommendations |
Mapping Column Mode | Map Each Column Manually |
Column to match on | calculated_at |
（列名） | JSON.parse($json.content.parts[0].text).（列名） }} |
- 「If」：発注が必要なものだけSlackに通知するよう条件分岐します。最終的な推奨発注数 {{ $json.recommended_quantity }} が0より大きい場合を条件に、当てはまる商品のみ次の処理を行います。
- 「Send a message」：Slackでメッセージを作成し、担当者へ通知します。商品名・現在庫数・推奨発注数など、担当者がひと目で現在の状況と必要な発注数が分かるようにすることを推奨します。
実際の使用結果例
本ワークフローを実際に使用した場合に、どのような結果が得られるかを確認します。以下の商品マスタをもとに、発注数の予測を行った結果を例として示します。
ワークフロー実行後の purchase_recommendations に保存された結果はこのようになりました。赤丸で囲まれている部分が1日あたりの予測需要数と最終的な推奨発注数です。(calculated_atとreasonは省略)
結果：
P001、P002、P003、P005、P008などは直近7日間の販売傾向に応じて、1日あたりの予測需要数が、30日間の平均販売数を基準に増減していることがわかります。さらに、P008のように30日間の平均販売数と7日間の平均販売数の差が大きいほど、予測需要数の変化も大きくなる傾向が見られます。
また、P009にあるように直近7日間の販売数が0であっても予測需要数は0にならず、30日間の平均販売数との比較を踏まえて予測している点が読み取れます。発注数についても、予測需要数・安全在庫数 (最低在庫数)・現在庫数を考慮し、必要な分だけ算出されていることが確認できました。
ワークフロー使用時の注意点
今回のワークフローを使用する際の注意点は以下の通りです。
入力データの限界
AIが分析に使用しているのは、30日間平均と直近7日間平均の販売数のみです。日別の販売推移までは入力していないため、急な変動を細かく捉えることはできません。
予測のタイムラグ
今回の分析では傾向変化の要因(例：セール)までは判断できません。そのため、セール終了後に販売が落ち着くケースなどでは、予測が反映されるまでに時間がかかる可能性があります。
AI利用量の増加
商品数が増えるほど生成AIへのリクエスト回数も増え、トークン使用量も相対的に増加します。大量の商品を扱う場合は、AIに分析させる対象範囲や、必要なデータの粒度を事前に検討することを推奨します。
まとめ
本記事では、スプレッドシートに蓄積した販売実績をもとにAIで需要を予測し、発注数の算出から記録・通知までを自動化しました。これにより、販売実績を目視で確認しながら計算し、発注数を検討する工程を効率化できることが期待できます。