Notion在庫管理の作り方｜入出庫・発注点・棚卸しをDB化する

Notionで在庫管理を作ることはできます。

商品名を一覧にする。

在庫数を表示する。

保管場所やカテゴリで絞り込む。

発注点を下回った商品をビューで見る。

入庫や出庫の履歴を残す。

棚卸しで差異を確認する。

こうした軽い在庫管理なら、Notionは十分に使えます。

Notionマーケットプレイスにも、在庫管理用途のテンプレートがあります。

Notion Marketplace：Inventory Management

ただし、Notion在庫管理で失敗するパターンもあります。

• 商品DBの在庫数を手で上書きして、なぜ増減したか分からない
• 入庫、出庫、棚卸し差異を同じメモ欄に書いている
• 発注点を下回っても誰も気づかない
• 同じ商品がカテゴリや保管場所ごとに重複している
• 現在庫、予約在庫、発注中、実在庫を混同している
• ロット、賞味期限、原価、請求、会計連携までNotionで抱えている
• AIや自動化で作った数量更新を人が確認していない

Notion在庫管理は、在庫数を直接上書きする表ではなく、商品DBと入出庫履歴DBを分け、現在庫、発注点、棚卸しをビューで確認する小さな業務DB として作る方が安定します。

この記事では、Notionで在庫管理を作る方法を、商品DB、入出庫履歴DB、現在庫、発注点通知、棚卸しビュー、Notionで向かないケース、専用システムへ移す判断まで整理します。

先に結論：現在庫は履歴から見る

Notionで在庫管理を作るときは、商品DBに現在庫だけを持たせるより、入出庫履歴を別DBにします。

最低限、次の2つを分けます。

DB	1行の意味	役割
商品DB	1商品、1SKU	商品名、カテゴリ、保管場所、発注点、管理責任者を持つ
入出庫履歴DB	1回の在庫増減	入庫、出庫、棚卸し調整、破損、返品などの数量変化を残す

小さな備品リストなら、商品DBだけでも始められます。

しかし、数量が変わるたびに手で現在庫を上書きすると、あとで理由を追えません。

たとえば、在庫が10個から6個になった時に、販売で4個出たのか、破損で4個減ったのか、棚卸し差異で減らしたのかが分からなくなります。

在庫管理では、数量そのものより、数量が変わった理由が重要です。

管理したいこと	置き場所
商品名、カテゴリ、保管場所	商品DB
発注点、管理者、仕入先候補	商品DB
入庫、出庫、返品、破損	入出庫履歴DB
棚卸し差異	入出庫履歴DB、棚卸しビュー
現在庫	入出庫履歴の集計、または確認用プロパティ
正式な原価、会計、請求	会計ソフト、販売管理、在庫管理システム

Notion公式ヘルプでは、データベースはページの集合体であり、プロパティやビューで整理できると説明されています。

Notion公式ヘルプ：データベースの基本

この特徴を使って、商品と在庫の増減履歴を分けます。

Notionデータベースの作り方

Notionで向く在庫管理

Notionに向いている在庫管理は、軽い在庫、備品、サンプル、販促物、小規模な商品管理です。

Notionに向く在庫	理由
社内備品	厳密な原価計算より、保管場所と数量確認が重要
販促物、ノベルティ	入出庫と発注点を見られればよい
展示会用品	保管場所、利用予定、返却確認を見たい
サンプル品	顧客、担当者、出庫履歴と紐づけやすい
小規模ECの補助台帳	商品数が少なく、正式管理は別にある
研究、制作、現場用の消耗品	管理者と補充タイミングを見たい

一方で、Notionに向かない在庫管理もあります。

Notionに向かない在庫	理由
倉庫単位の大量在庫	同時更新、棚卸し、ロケーション管理が重い
ロット、賞味期限、シリアル管理	追跡単位が細かく、誤登録の影響が大きい
原価、粗利、会計と直結する在庫	正式帳簿、税務、会計連携が必要
ECやPOSとリアルタイム連動する在庫	API連携、排他制御、予約在庫が必要
複数拠点、複数倉庫の在庫	移動、引当、棚卸し責任が複雑

Notionは、在庫管理の形を早く作るには向いています。

ただし、正式な在庫評価、会計、EC公開在庫、出荷指示までNotionに寄せるのは危険です。

Notionは、軽い管理、補助台帳、棚卸しチェック、現場の見える化に使うと安定します。

商品DB

商品DBは、在庫管理の軸です。

1行は1商品、または1SKUです。

プロパティ	型	目的
商品名	タイトル	商品や備品を識別する
SKU、管理番号	テキスト	重複を防ぐ
カテゴリ	セレクト	備品、販促物、商品、消耗品などを分ける
保管場所	セレクト、リレーション	倉庫、棚、拠点を管理する
管理責任者	ユーザー	補充や棚卸しの責任者
発注点	数値	補充が必要になる数量
標準発注数	数値	発注時の目安
仕入先	テキスト、リレーション	発注先を確認する
関連入出庫	リレーション	入出庫履歴DBとつなぐ
現在庫	ロールアップ、数値	入出庫履歴から見る
最終棚卸し日	日付、ロールアップ	棚卸し漏れを防ぐ

商品DBで重要なのは、商品名だけに頼らないことです。

同じような名称の商品、サイズ違い、色違い、拠点違いがあると、すぐに重複します。

SKU、管理番号、カテゴリ、保管場所を持たせます。

悪い例	問題
ノベルティ	どのノベルティか分からない
チラシ	版、サイズ、保管場所が分からない
サンプルA	顧客貸出用か社内検証用か分からない
PC備品	ケーブル、マウス、端末が混ざる

商品DBは、在庫数を書く場所ではありますが、数量を直接編集する場所にしすぎない方がよいです。

数量の増減は、入出庫履歴DBへ残します。

入出庫履歴DB

入出庫履歴DBは、在庫が増減した理由を残すDBです。

1行は1回の在庫変動です。

プロパティ	型	目的
履歴名	タイトル	入庫、出庫、棚卸し調整などを識別する
商品	リレーション	商品DBとつなぐ
日付	日付	いつ増減したか
区分	セレクト	入庫、出庫、返品、破損、棚卸し調整
数量	数値	増減数量
増減方向	セレクト、数式	入庫はプラス、出庫はマイナス
担当者	ユーザー	誰が処理したか
理由	テキスト	顧客出荷、社内利用、破損、棚卸し差異など
関連案件、顧客	リレーション	必要なら案件DBや顧客DBとつなぐ
確認状態	ステータス	未確認、確認済み、差戻し

現在庫は、単純には次の考え方で見ます。

現在庫 = 初期在庫 + 入庫合計 - 出庫合計 + 棚卸し調整

Notionだけで厳密な在庫計算をする場合、リレーション、ロールアップ、数式の設計が必要です。

ただし、複雑にしすぎると運用が崩れます。

小規模なら、商品DBに 現在庫 の確認用数値を持たせつつ、増減理由は必ず入出庫履歴DBへ残す形でも構いません。

重要なのは、数量を変えた理由が追えることです。

履歴を残すべき変動	例
入庫	仕入、返却、補充
出庫	販売、貸出、社内利用
破損、廃棄	使用不可、期限切れ
返品	顧客返品、仕入先返品
棚卸し調整	実数との差異補正

AIでレシートやメールから入庫候補を作る場合も、正式な数量更新は人が確認します。

AIや自動化で作るのは入出庫候補、正式な在庫更新は確認済み履歴 と分けると、誤登録の影響を抑えられます。

発注点と通知

在庫管理で重要なのは、在庫が少なくなった時に気づけることです。

商品DBには、発注点を持たせます。

プロパティ	型	目的
現在庫	数値、ロールアップ	今の数量を見る
発注点	数値	補充が必要になる基準
標準発注数	数値	補充時の目安
補充状態	ステータス	不要、要発注、発注中、入庫待ち
発注担当者	ユーザー	誰が動くか
次回確認日	日付	保留や確認待ちを拾う

ビューは、次のように作ります。

ビュー	条件
要発注	現在庫 が 発注点 以下
発注中	補充状態 = 発注中
入庫待ち	補充状態 = 入庫待ち
担当者別要確認	発注担当者 でグループ化
保管場所別在庫	保管場所 でグループ化

Notion公式ヘルプでは、データベースオートメーションでトリガーとアクションを設定し、プロパティ編集や通知などを自動化できると説明されています。

Notion公式ヘルプ：データベースオートメーション

これを使うなら、通知条件は絞ります。

通知してよい	通知しすぎない方がよい
発注点を下回った	すべての数量更新
棚卸し差異が大きい	軽微なメモ更新
入庫待ちが期限超過した	すべての商品編集
管理責任者が未設定	参考情報の追加

通知は便利ですが、在庫管理を通知だけに頼らない方がよいです。

毎日または週次で見る 要発注 ビューを作り、担当者が確認する運用にします。

棚卸しビュー

在庫管理では、棚卸しも設計します。

Notionで棚卸しをするなら、商品DBに棚卸し用のプロパティやビューを用意します。

プロパティ	型	目的
帳簿在庫	数値、ロールアップ	Notion上の数量
実棚数	数値	実際に数えた数量
差異	数式、数値	実棚数と帳簿在庫の差
棚卸し担当者	ユーザー	誰が数えたか
棚卸し日	日付	いつ確認したか
差異理由	テキスト	破損、出庫漏れ、登録漏れなど
確認状態	ステータス	未確認、確認済み、調整済み

棚卸しビューは、次のように分けます。

ビュー	条件
今月棚卸し対象	棚卸し日 が空、または前回から一定期間経過
差異あり	差異 が0ではない
確認待ち	確認状態 = 未確認
保管場所別棚卸し	保管場所 でグループ化
担当者別棚卸し	棚卸し担当者 でグループ化

棚卸し差異が出たら、商品DBの現在庫を直接直すだけで終わらせません。

入出庫履歴DBに 棚卸し調整 として履歴を残します。

差異理由が分かるなら、理由も残します。

差異理由	次の対応
出庫登録漏れ	出庫履歴を追加する
入庫登録漏れ	入庫履歴を追加する
破損、廃棄	破損または廃棄履歴を追加する
数え間違い	再棚卸しする
原因不明	調整履歴を残し、再発防止を見る

棚卸しは、数量合わせではありません。

運用の漏れを見つける作業です。

向かないケース

Notion在庫管理には限界があります。

次の条件がある場合は、Notionだけで完結させない方がよいです。

条件	Notionだけでは危ない理由
EC、POS、倉庫とリアルタイム連携する	同時更新、予約在庫、引当が必要
ロット、賞味期限、シリアル番号を管理する	追跡粒度が細かく、誤登録の影響が大きい
原価、粗利、会計評価を行う	会計、税務、棚卸評価の正式処理が必要
複数拠点、複数倉庫で移動が多い	拠点間移動、責任者、棚卸しが複雑
出荷、検品、返品フローが重い	ワークフローと承認履歴が必要
外部ユーザーや現場端末から大量入力する	入力制御、権限、操作ミス対策が必要

Notionは、自由に作れる分、入力ルールも崩れやすいです。

在庫は数字が少し違うだけで、発注、販売、会計、顧客対応に影響します。

「Notionで作れるか」ではなく、「誤登録した時に業務上どれだけ困るか」で判断します。

専用システムへ移す判断

次の状態になったら、専用の在庫管理システム、販売管理、kintone、EC管理、会計ソフトなどへ移すことを考えます。

移行サイン	理由
商品数や入出庫件数が増えた	手入力とビューだけでは追えなくなる
複数人が同時に数量更新する	誤更新や二重登録が起きやすい
発注、入荷、検品、出荷が分かれている	ステータスと責任の管理が必要
原価や売上とつながる	会計や販売管理と連携するべき
EC公開在庫と連動する	リアルタイム性と引当管理が必要
棚卸し差異の影響が大きい	監査、証跡、承認が必要

Notionを使わなくなるわけではありません。

専用システムに移した後も、Notionは次の用途で残せます。

Notionに残す	専用システムに移す
管理ルール、棚卸し手順	正式在庫数
商品説明、写真、利用メモ	入出庫実績
発注判断のメモ	発注、入荷、出荷
改善要望、現場メモ	原価、会計、請求
月次レビュー	在庫評価、監査ログ

Notion在庫管理は、最初から本格的な在庫システムを置き換えるものではありません。

小さな在庫管理を見える化する。

入出庫履歴を残す。

発注点を下回った商品に気づく。

棚卸し差異を確認する。

この範囲なら、Notionは十分に役立ちます。

一方で、在庫が売上、出荷、会計、顧客対応に直結するなら、Notionは補助台帳に留め、正式な在庫は専用システムで管理する方が安全です。