Excel管理をやめたら、イベント販売がここまで楽になった

Posted at 2026-09-07

React × Node.js × SQLiteで「売上・在庫・Instagram施策」をまとめて管理するWebアプリを作ってみた

はじめに

イベント販売の管理って、最初はExcelで十分なんですよね。

商品名、価格、原価、在庫数、販売数。

このくらいなら問題ありません。

でも、実際に運用しようとすると、だんだん管理したいことが増えてきました。

商品が売れたら在庫を減らしたい
利益も自動計算したい
無料配布したシールも在庫から減らしたい
Instagramフォロー施策の効果も見たい
入力ミスを修正・取消したい
イベント終了後にExcelでも出力したい

ここまでくると、ExcelやCSVだけでは少し苦しくなります。

そこで今回、もともとExcel・CSVで管理していたイベント販売データを、

React + Node.js + SQLite

を使ったローカルWebアプリへ作り替えました。

この記事では、実装した機能と、フロントエンド・バックエンドで意識したことを、3〜5分程度で読める形にまとめます。

作ったもの

今回作ったのは、小規模イベント販売向けの

売上・在庫・施策管理アプリ

です。

現在はブラウザから、以下をまとめて管理できます。

商品管理
在庫管理
売上登録
無料配布
Instagramフォロー施策
売上・利益確認
目標管理
取引履歴
Excel出力
バックアップ

画面は大きく、

ダッシュボード
商品・在庫一覧

取引履歴
で構成しています。

技術構成

フロントエンド

React 19
Vite
Recharts
Lucide React
CSS
Fetch API

バックエンド

Node.js
Express
SQLite
ExcelJS
csv-parse
zlib

正式な保存先はSQLiteです。

初期版ではCSVを使っていましたが、売上・在庫・履歴を安全に連動させるためSQLiteへ移行しました。

商品管理

商品一覧では、次の情報を確認できます。

商品画像
商品名
カテゴリ
商品管理番号
販売価格
販売数
現在庫
在庫状況

商品は、

グリッド表示
リスト表示

を切り替えられます。

表示方法はlocalStorageに保存し、次回起動時も前回の設定を維持します。

商品データそのものはlocalStorageには置かず、SQLiteを正としています。

商品画像も管理

もともとExcelに入っていた商品画像をWebアプリへ移行しました。

画像がない商品は、商品名の先頭文字を使ったプレースホルダーを表示します。
例えば、

コ
ジ
M
ア

のような形です。

これで、画像未登録の商品があってもカードの見た目が崩れません。

在庫変更画面から商品画像を追加・変更することもできます。

商品追加

商品一覧の上部には「商品を追加」ボタンがあります。

現在は次の情報を入力できます。

・商品名
・カテゴリ
・販売価格
・原価
・初期在庫

一時期は、
ITEM-001 ITEM-002 ITEM-003
のような商品管理番号を自動発行する仕様にしていました。

今後は、任意の商品IDを入力できるように戻す予定です。

在庫管理

各商品カードには「在庫変更」ボタンがあります。

ここから、次の操作ができます。

在庫数の増減
数量の直接入力
販売価格の変更
原価の変更
商品画像の追加・変更

在庫変更時には、変更理由も記録します。

選択できる理由は以下です。

入荷
棚卸し
破損
返品
その他

変更すると、以下の情報が履歴として残ります。

変更日時
商品名
変更前在庫
変更後在庫
増減数
変更理由

単純に在庫数だけを書き換えるのではなく、

「なぜ在庫が変わったのか」

まで後から追えるようにしています。

在庫残り1点の商品を自動通知

ダッシュボードには「在庫のお知らせ」を表示しています。

現在庫が残り1点になった商品だけを自動で一覧表示します。

例えば、

ピンクプードル　あと1点
ポンスキー　　　あと1点
マルチーズ　　　あと1点

のように表示します。

在庫0の商品は含めません。

この欄は、売り切れる直前の商品へ早めに気付くことを目的としています。

売上登録

各商品カードには「売上登録」ボタンを用意しています。

イベント会場では、できるだけ少ない操作で販売処理を完了できるようにしたかったため、商品一覧からそのまま売上登録できる構成にしました。

売上登録時には、以下の内容を指定できます。

商品
数量
取引区分
支払方法
販売経路

支払方法は次の4種類です。

現金
クレジットカード
電子マネー
その他

販売経路は次の2種類です。

通常
Instagram経由

売上を登録すると、その内容は自動的に在庫や集計へ反映されます。

更新される主な項目は以下です。

現在庫
販売数
売上金額
原価
利益
カテゴリ別グラフ
売上目標
利益目標
支払方法別集計
Instagram経由売上

フロントエンドだけで在庫を減らさない

実装時に特に意識したのは、

画面上の数字だけを先に変更しないこと

です。

例えば、React側で単純に在庫数を1減らしてしまうと、API通信やDB保存に失敗した場合に、

画面上では在庫4個
SQLiteでは在庫5個

SQLiteへの保存が成功してから最新データを読み直すことで、画面に表示される値と実際のデータを一致させています。

売上登録を起点に集計を自動更新

販売情報を1件登録するだけで、関連する集計へ自動的に反映されるようにしました。

例えば、1,200円の商品を1個販売した場合は、次のように更新されます。

現在庫
↓ 1個減少

販売数
↓ 1件増加

売上
↓ 1,200円加算

原価
↓ 販売商品の原価を加算

利益
↓ 売上 - 原価

さらに、この取引内容は以下にも自動反映されます。

・売上グラフ
・支払方法別集計
・売上目標の進捗
・利益目標の進捗
・Instagram経由売上

つまり、売上を1件登録するたびに、在庫・売上・利益・グラフ・目標進捗を個別に更新する必要はありません。

イベント中にExcelや電卓を使って別途集計しなくても、登録した内容がそのままダッシュボード全体へ反映される構成にしています。

これによって、

「売上を登録する」ことを起点に、必要な集計がすべて連動して更新される

ようにしました。

Instagram経由の売上も同時に記録

売上登録時には、販売経路として以下の2種類を選択できます。

通常
Instagram経由

「Instagram経由」を選択して売上を登録すると、その取引は通常の売上に含めつつ、Instagram経由の売上としても別途集計されます。

これによって、

Instagram経由売上
Instagram経由商品の原価
Instagram経由の実売利益

を確認できます。
例えば、Instagramを見て来店したお客様が1,200円の商品を購入し、その商品の原価が450円だった場合は、次のように集計します。

Instagram経由売上
= 1,200円

Instagram経由原価
= 450円

Instagram経由実売利益
= 1,200円 - 450円
= 750円

また、このアプリでは、

Instagramフォローによる広告換算価値

と、

Instagram経由で実際に発生した売上

を分けて管理しています。

例えば、フォロー数が増えたからといって、その金額がそのまま実際の売上になるわけではありません。

そのため、次の2つの視点で確認できるようにしました。

フォロー施策
↓
広告としてどれくらいの価値があったか

Instagram経由売上
↓
実際にいくら購入されたか

これによって、

「フォロワーは増えたけれど、売上にはつながらなかった」

のか、

「Instagramをきっかけに、実際の購入までつながった」

のかを分けて分析できます。

ダッシュボード

イベント中に確認したい情報を、画面上部のダッシュボードへまとめています。

表示している主な項目は以下です。

売上
利益
現在庫
在庫原価
無料配布数
販売数

これまでExcelで確認していた数字を、Webアプリを開くだけですぐ確認できるようにしました。

また、集計期間は以下の3種類から切り替えられます。

今日
直近7日
イベント全体

例えばイベント当日は「今日」を選択し、その日の売上状況を確認します。

イベント終了後には「イベント全体」へ切り替えることで、イベント期間全体の結果を確認できます。

集計期間を変えると関連データも連動

期間を変更すると、売上金額だけではなく、関連する集計も同じ期間に合わせて切り替わります。

具体的には、以下が連動します。

売上
利益
販売数
無料配布数
カテゴリ別売上グラフ
支払方法別集計

例えば、

今日
↓
本日の売上・利益・販売数を表示

直近7日
↓
過去7日間のデータを集計

イベント全体
↓
イベント期間中の全取引を集計

という形です。

これによって、画面ごとに期間を設定し直す必要がありません。

イベント中に「今どうなっているか」をすぐ確認

今回のダッシュボードでは、詳細な分析よりも、

イベント中に必要な数字をすぐ確認できること

を重視しました。

例えば、

今いくら売れているか
利益はいくら出ているか
あと何個在庫が残っているか
無料配布を何枚したか

といった情報を、画面を移動せずに確認できます。

特にイベント販売では、後から詳しく分析できることだけではなく、

その場で現在の状況を把握できること

が重要だと考えました。

売上グラフ

ダッシュボードでは、カテゴリごとの売れ方を確認できるようにしています。

グラフ表示にはRechartsを利用し、1つのグラフの中に以下の2種類を重ねています。

棒グラフ：販売数
折れ線グラフ：売上金額

対象カテゴリは以下です。

ハンカチ
湯呑み
ノート
シール
リング
その他

販売数と売上金額では単位が異なるため、左右に別々のY軸を用意しています。

これによって、

たくさん売れた商品カテゴリ

と、

売上金額が大きかった商品カテゴリ

を同時に確認できます。

例えば、単価の低い商品は販売数が多くても売上金額は小さいことがあります。

逆に、販売数が少なくても単価が高ければ売上金額は大きくなることがあります。

この2つを同じ画面で確認することで、

「何がよく売れたか」だけではなく「何が売上に貢献したか」

まで見られるようにしました。

支払方法別集計

イベント販売では、売上金額だけでなく、

どの支払方法でいくら売れたか

も重要です。

そこで、選択した期間について以下の支払方法ごとに売上を集計しています。

現金
クレジットカード
電子マネー
その他

例えばイベント終了後には、

アプリ上の現金売上
↓
実際に手元にある現金

を照合できます。

同じように、クレジットカードや電子マネーについても、決済サービス側の履歴と比較できます。

これによって、

売上集計だけではなく、イベント終了後の精算確認にも使える

ようにしています。

売上目標と利益目標

ダッシュボードでは、以下の2種類の目標を設定できます。

売上目標
利益目標

それぞれについて、

現在金額
目標金額
進捗率

を表示します。

例えば、

売上
20,000円 / 50,000円

利益
15,000円 / 30,000円

のように確認できます。

単純に売上だけを見るのではなく、利益も同時に確認できるようにしています。

「あと何個売ればいい？」を自動計算

目標進捗だけではなく、

目標達成までに何を何個売ればよいか

も計算するようにしました。

計算には以下の情報を利用しています。

現在の売上
現在の利益
売上目標
利益目標
商品ごとの販売価格
商品ごとの原価
商品ごとの利益額
現在庫

ここで意識したのは、

売上目標だけを見ないこと

です。

例えば、売上目標まであと5,000円だったとしても、利益率の低い商品だけを販売すると、売上目標は達成しても利益目標には届かない可能性があります。

そのため、売上と利益の両方を考慮して、

売るべき商品
必要な販売数
見込売上
見込利益

を表示します。

さらに、現在庫だけでは目標を達成できない場合には、

不足する売上額
不足する利益額

も表示します。

これによって、

あといくら売ればいいか

だけではなく、

何を何個売れば目標に近づけるか

まで確認できるようにしました。

取引履歴

登録した取引はすべて履歴として保存しています。

取引履歴では、以下の条件で検索・絞り込みができます。

商品名
商品管理番号
取引区分
支払方法
開始日
終了日

取引区分は以下の3種類です。

販売
無料配布
Instagramフォロー

これによって、

この商品はいつ売れたか

や、

今日は現金決済が何件あったか

といった確認がしやすくなっています。

取引を後から修正できる

イベント中は、入力ミスが起こることもあります。

例えば、

商品Aを2個販売

と登録したものの、実際には、

商品Bを1個販売

だった場合です。

このとき、単純に取引履歴の文字だけを書き換えることはしません。

バックエンドでは、以下の流れで処理します。

1. 元商品の在庫を戻す
2. 元商品の販売数・配布数を戻す
3. 新しい商品の在庫を確認する
4. 新しい商品の在庫を減らす
5. 新しい商品の販売数・配布数を増やす
6. 取引履歴を更新する

この一連の処理をSQLiteのトランザクション内で行います。

そのため、途中でエラーが起きた場合でも、

在庫だけ戻った
取引履歴だけ変わった

といった中途半端な状態になりません。

取引取消

登録した取引は、後から完全に取り消すこともできます。

取消すると、取引内容に応じて以下を元へ戻します。

在庫
販売数
無料配布数
Instagramフォロー数

その結果、以下の集計も再計算されます。

売上
原価
利益
グラフ
目標進捗

取消処理では、単純に表示中の数字を減算するのではなく、

残っている取引履歴を基準に再計算する

ようにしています。

これによって、取消後も集計値が自然に正しい状態へ戻ります。

登録直後は「元に戻す」

イベント中は操作スピードも重要です。

間違えて登録したときに、

取引履歴を開く
↓
対象の取引を探す
↓
取消ボタンを押す

という操作を毎回するのは少し面倒です。

そこで、新しい売上や無料配布を登録した直後には、約8秒間、

元に戻す

ボタンを表示しています。

登録直後にミスへ気付いた場合、その場ですぐに取り消せます。

時間が経過した後でも、取引履歴から通常どおり修正・取消できます。

二重登録を防ぐ

イベント当日は、端末や処理速度によって登録に少し時間がかかることがあります。

そのとき、

押せていないかも

と思って、登録ボタンをもう一度押してしまう可能性があります。

同じ取引が2回登録されると、

売上が二重になる
在庫が2個減る
販売数も2件増える

といった問題が発生します。

そこで、フロントエンドとバックエンドの両方で二重登録を防止しています。

フロントエンド側

登録処理中はボタンを無効化します。

さらに、Reactの再描画を待つ前に連続クリックされた場合でも、2回目の処理を止められるようにしています。

バックエンド側

取引ごとに一意の重複防止キーを付けています。

SQLite側にもUNIQUE制約を設定します。

UNIQUE(request_id)

同じキーを持ったリクエストが再送された場合でも、同じ取引を2回保存できません。

これによって、

連続クリック

だけでなく、

通信の再試行

にも対応しています。

CSVからSQLiteへ移行した理由

初期版ではCSVを正式な保存先としていました。

しかし、機能が増えるにつれて、1回の操作で複数のデータを変更する必要が出てきました。

例えば売上登録では、

在庫を減らす
↓
販売数を増やす
↓
取引履歴を追加する

という処理が必要です。

CSVの場合、途中で処理に失敗すると、

在庫の更新には成功
↓
取引履歴の保存には失敗

という状態になる可能性があります。

すると、

在庫だけ減っている
でも取引履歴には残っていない

という不整合が発生します。

そこで、正式な保存先をSQLiteへ変更しました。

SQLiteのテーブル構成

主に以下のテーブルを利用しています。

products

商品情報を保存します。

商品ID
商品名
カテゴリ
販売価格
原価
初期在庫
販売数
無料配布数
現在庫
商品画像
利用状態

transactions

販売や無料配布などの取引を保存します。

取引ID
登録日時
商品ID
商品名
取引区分
数量
支払方法
販売時単価
販売時原価
フォロー広告価値
販売経路
重複防止キー

inventory_history

在庫変更履歴を保存します。

変更ID
変更日時
商品ID
商品名
変更前在庫
変更後在庫
増減数
変更理由

settings

アプリ全体の設定を保存します。

1フォローの広告価値
売上目標
利益目標

過去の売上が壊れないようにした

販売管理では、

取引した時点の価格を残すこと

が重要です。

例えば、9月1日にハンカチを1,200円で販売したとします。

9月1日
ハンカチ：1,200円

その後、価格を1,500円へ変更したとします。

9月10日
ハンカチ：1,500円

もし過去の取引が商品マスターの現在価格だけを参照していた場合、9月1日の売上まで1,500円として再計算されてしまいます。

そこで取引データには、

販売時単価
販売時原価

を保存しています。

つまり、

現在の商品価格

と、

その取引を行った当時の商品価格

を分けています。

これによって、後から価格や原価を変更しても、過去の売上や利益は変わりません。

SQLiteトランザクションでデータを守る

売上登録では、複数のDB更新を1つの処理として扱っています。

イメージとしては以下です。

BEGIN

商品確認
在庫確認
在庫更新
販売数更新
取引履歴追加

COMMIT

途中で問題が起きた場合は、

ROLLBACK

します。

つまり、処理が最後まで成功した場合だけ、すべての変更を確定します。

これによって、

在庫だけ減った

や、

履歴だけ追加された

といった不整合を防ぎます。

サーバー側でも入力を検証

React側で入力項目を制限していても、APIを直接呼び出せば任意の値を送信できます。

そのため、Node.js側でも入力内容を検証しています。

主なチェック項目は以下です。

数量が1以上の整数か
商品が存在するか
在庫不足していないか
取引区分が正しいか
価格が0以上か
原価が0以上か
在庫が0以上か
無料配布対象商品か
Instagram特典対象商品か
商品画像の形式が正しいか
商品画像の容量が大きすぎないか

考え方としては、

フロントエンド
↓
使いやすくする・入力ミスを減らす

バックエンド
↓
不正なデータを保存させない

という役割分担です。

SQLiteの同時更新対策

SQLiteでは、以下の設定も利用しています。

WALモード
外部キー制約
busy timeout
即時トランザクション

今回のようなローカルで使う小規模な販売管理アプリでは、SQLiteの軽さと扱いやすさがかなり合っていました。

MySQLやPostgreSQLのように別途DBサーバーを用意しなくても、SQLiteなら1つのDBファイルを中心に管理できます。

検索処理の工夫

取引履歴や在庫変更履歴が増えても検索しやすいように、よく利用する項目にはインデックスを設定しています。

主な対象は以下です。

取引日時
商品ID
在庫変更日時
在庫変更の商品ID

また、フロントエンド側では検索や絞り込みにuseMemoを利用しています。

const filteredProducts = useMemo(() => {
  return products.filter(...);
}, [products, keyword, category]);

検索条件に関係のないstateが変更された場合まで、毎回フィルタ処理を行わないようにしています。

現時点では小規模なデータですが、商品数や取引件数が増えた場合にも対応しやすい構成にしています。

商品画像の読み込みも軽くした

商品画像には遅延読み込みを設定しています。

<img loading="lazy">

画面を開いた瞬間にすべての商品画像を読み込むのではなく、画面上に表示される位置へ近づいた段階で読み込みます。

ハンカチのように画像付きの商品が多いため、初期表示を軽くする目的で利用しています。

PC・タブレット・スマートフォンに対応

イベント会場で使うことを考えると、PCだけで動けばよいわけではありません。

そのため、画面幅に応じてレイアウトが変わるようにしています。

主に調整しているのは以下です。

商品カードの列数
ダッシュボードの列数
グラフの配置
Instagram集計欄
取引履歴の検索欄
モーダル入力欄
ボタン配置

イベント当日はタブレットやスマートフォンを使う可能性もあるため、どの端末でも操作しやすいことを意識しました。

Excel出力も残した

Webアプリへ移行したからといって、Excelを完全にやめたわけではありません。

イベント終了後には、

データの確認
共有
保管
別の集計

などでExcelが便利な場面があります。

そこでExcelJSを利用し、現在のデータをExcelとして出力できるようにしました。

出力するシートは以下です。

ダッシュボード
在庫一覧
取引履歴
在庫変更履歴

見やすくするために、

見出しの色
太字
列幅調整

なども設定しています。

考え方としては、

日々の入力・管理
↓
Webアプリ

確認・共有・保管
↓
Excel

という使い分けです。

バックアップ機能

イベント当日のデータは失いたくないため、バックアップ機能も実装しました。

「データを保存」では、以下をまとめて保存します。

商品情報
現在庫
売上履歴
無料配布履歴
Instagram履歴
設定
在庫変更履歴
商品画像

これらをJSON形式へまとめ、gzipで圧縮して、

.mimibak

という専用バックアップファイルとして出力します。

商品画像も含まれるため、現在のバックアップサイズは約59MBです。

復元時にも安全対策

バックアップを読み込むときは、いきなり現在のデータを上書きしません。

まず、現在のSQLiteデータを安全コピーとして保存します。

現在のSQLiteデータ
↓
安全コピーを作成
↓
バックアップデータを復元

さらに、読み込んだファイルについても以下を確認します。

正しいバックアップ形式か
必要な商品情報が含まれているか
取引データの形式が正しいか
設定データが正しいか
画像ファイル名が安全か

そのうえで、商品・取引・設定・履歴・画像をまとめて復元します。

今後追加したい機能

直近では、以下の2つを追加する予定です。

商品追加時の商品ID入力
商品削除機能

ただし、商品削除については単純に、

DELETE FROM products

とはしない予定です。

すでに取引履歴がある商品を完全削除すると、過去の集計や履歴表示が壊れる可能性があるためです。

そのため、以下のような設計を考えています。

取引履歴がない商品
↓
完全削除

取引履歴がある商品
↓
販売終了・非表示

いわゆる論理削除です。

過去の履歴は残しつつ、新しい販売では選択できない状態にする予定です。

フロントエンドで意識したこと

今回のフロントエンドでは、

機能を増やすことより、イベント会場で迷わず使えること

を重視しました。

特に意識したのは以下です。

商品画像を見ながら選べる
商品カードから直接売上登録できる
不要な選択肢を表示しない
モーダルでその場から入力できる
在庫残り1点を自動通知する
登録直後ならすぐ元に戻せる
グリッドとリストを切り替えられる
スマートフォンやタブレットでも使える

実際に使う場面を考えると、

「機能があるか」より「何回の操作で使えるか」

の方が重要だと感じました。

バックエンドで意識したこと

一方、バックエンドでは、

使いやすさよりデータの正しさ

を重視しています。

特に重要だと考えたのは以下です。

SQLiteトランザクション
二重登録防止
サーバー側入力検証
取引時価格の保存
取引修正時の在庫復元
取消後の再計算
在庫変更履歴
バックアップ
外部キー制約
WALモード

販売管理アプリでは、

在庫が1個ずれる
売上が二重登録される
取消したのに利益が戻らない

といった問題が起きると、見た目がきれいでも実用できません。

そのため、

フロントエンドでは「使いやすさ」、バックエンドでは「壊れにくさ」

を意識して役割を分けました。

まとめ

今回、Excel・CSVで管理していたイベント販売データを、

React
Node.js
Express
SQLite

を使ったローカルWebアプリへ移行しました。

現在は以下まで一通り実装しています。

商品管理
在庫管理
売上登録
無料配布
Instagram施策管理
売上・利益分析
目標管理
取引修正・取消
二重登録防止
Excel出力
バックアップ

最初は単純なExcel管理でしたが、必要な機能を追加していく中で、

Excel
↓
CSV
↓
React
↓
Node.js
↓
SQLite

という形へ発展しました。

今回作ってみて特に感じたのは、

「画面を作る」だけでは、実際に使えるアプリにはならない

ということです。

例えば、

どのデータを正とするのか

途中で処理に失敗したらどうするのか

二重登録をどう防ぐのか

価格変更後も過去データを守れるか

取引を取り消したときに在庫まで戻せるか

といった部分まで考える必要がありました。

個人開発でも、こうしたデータ整合性や運用時のミスまで考えて設計することで、

「動くアプリ」から「実際に使えるアプリ」へ一段近づける

と感じました。

今後は商品削除や販売終了管理などを追加し、実際のイベント運用を通してさらに改善していく予定です。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up