ひとりで持てるデータ分析基盤｜BIツール卒業のための最小構成
BIツール（事業の数字を可視化するダッシュボード作成ソフト）は月3万円。ひとり事業主には重すぎる。でも数字は見たい。この矛盾に悩んでいる人は多いのではないだろうか。
売上、粗利、顧客あたりの単価、広告費の回収期間。感覚で動いていた時期は、なんとなくうまくいっているようでも、気づいたら手元の現金が減っていた、という経験を持つ人もいるはずだ。
数字を見る習慣は、ひとり事業主にとって生命線に近い。ただ、そのために月3万円、年間36万円のコストをかけるのは、小さな事業には重い。広告費に回したほうが、よほど売上に直結するだろう。
この記事では、BIツールを卒業して、ひとりで持ち運べるデータ分析基盤を組み立てる方法を書いていきたい。使う道具は、SQLite（小さなファイル型データベース）と、Next.js（Webアプリを作るための土台）、それからClaude Code（AIがコードを書く開発環境）の3つだけだ。追加コストはほぼゼロに近い。
この記事の前提
この記事が想定している読者は、ひとりで小さな事業を回している個人事業主だ。毎日の売上はなんとなく把握しているが、月次や週次のトレンド、商品ごとの粗利、リピート率のような踏み込んだ数字までは追えていない。Googleスプレッドシートで頑張ってはいるが、手動更新が面倒で続かない。そんな状況を想像している。
本格的なBIツール、たとえばLooker（Google傘下の分析サービス）やTableau（老舗の分析ツール）を導入するほどの予算もないし、導入しても使いこなせる気がしない。Metabase（オープンソースの分析ツール）のような無料の選択肢を知ってはいても、サーバー運用が億劫で手が出せない。そういう層に向けて書く。
この記事のスタンスは単純で、ひとりで扱える範囲の道具だけで、必要最小限の数字を見える化しよう、というものだ。大企業のような完璧な分析基盤は目指さない。意思決定に使う数字だけを、最小のコストで、毎朝見られる状態にする。これだけを目的にする。
もうひとつ。私はエンジニアを想定していない読者に向けて書いている。だから技術用語はなるべく括弧で言い換えていくつもりだ。コードも出てくるが、Claude Codeに「こう書いて」と頼めばそのまま動くレベルの内容しか書かない。安心して読み進めてほしい。
なぜBIツールはひとり事業主に重すぎるのか
図: BIツール vs ひとり用分析基盤
まず前提を整理したい。BIツールが悪いわけではない。あれは複数人のチームが、同じ数字を見ながら議論するために設計されている道具だ。権限管理、ダッシュボードの共有、アラートの配信先設定。こうした機能は、10人、20人のチームでは不可欠になる。
ところがひとり事業主には、この機能のほとんどが不要だ。自分しか見ない画面に、アクセス権限の設定はいらない。共有リンクも、配信先リストもいらない。必要なのは、自分が毎朝コーヒーを飲みながらチラッと見る、数字が並んだ画面だけだ。
それに月3万円というのは、固定費として重い。年間36万円。ひとり事業主の粗利率を仮に60%とすれば、この固定費を回収するために年間60万円の売上を追加で作らないといけない。広告、コンテンツ制作、新商品の仕入れ。その60万円を別の用途に回したほうが、ほぼ確実にリターンが大きい。
さらに本音を言うと、BIツールを契約した人の多くは、最初の1ヶ月しかダッシュボードを見ない。設定した瞬間は満足感があるが、数字が毎日そんなに動くわけでもない。気づけば月額だけが引き落とされ続ける、という話をよく聞く。月3万円を2年間払い続ければ72万円。使っていない期間のほうが長い、という笑えない状況になりがちだ。
ひとり事業主が本当に見たい数字
では何を見たいのか。ここを絞り込むのが最初の仕事になる。私が知っているひとり事業主の多くは、突き詰めると次の5つしか見ていない。
- 今月の売上と、先月同時点との差分
- 商品・サービスごとの粗利と構成比
- 広告費を払っている場合の回収期間
- リピート率、または継続率
- 前週と比べて異常に動いた数字
これだけだ。これ以上の数字は、見たとしても行動が変わらない。行動が変わらない数字を見る時間は、娯楽であって分析ではない。娯楽に月3万円払うなら、Netflixを10個契約できる。
だからひとりで持つ分析基盤は、この5つを見るためだけに設計する。それ以外の機能は、あとから必要になったら足せばいい。最初から盛り込んでも、絶対に使わない。
最小構成の全体像
図: ひとり分析基盤の4つの部品
ここから具体的な構成の話に入りたい。ひとりで持てる分析基盤は、次の4つの部品でできている。
・データの置き場所として、SQLite（1ファイルで完結する小さなデータベース） ・データの取り込みとして、各サービスのCSVエクスポート、またはAPI（外部サービスと通信する窓口） ・画面表示として、Next.js（Webアプリを作るための土台）で組んだ簡易ダッシュボード ・自動化として、週次レポートのメール配信と異常値検知
それぞれ順番に見ていきたい。
SQLiteというデータ置き場
SQLiteはファイル1個で動くデータベースだ。サーバーを立てる必要がない。パソコンの中の1つのファイルの中に、テーブル（表）がいくつも入っている、というイメージでいい。サイズが小さく、個人事業主が1年分のデータを入れても、多くの場合100MBにも満たない。
これがひとり事業主にとって何より大事なポイントで、データベースサーバーを管理する必要がない。PostgreSQLやMySQLのようなサーバー型のデータベースは、インストール、設定、バックアップ、バージョンアップ、すべて自分でやらないといけない。事業を回しながらこれをやるのは、正直しんどい。
SQLiteなら、そのファイルをDropboxやGoogle Driveに放り込んでおけば、それがそのままバックアップになる。パソコンを買い替えても、そのファイルを新しい端末にコピーするだけで続きから使える。このシンプルさが、ひとり事業主の運用スタイルに驚くほど馴染む。
Next.jsで画面を作る意味
データがSQLiteに入ったら、それを見る画面が必要になる。ここで選ぶのがNext.jsだ。本来はWebサービスを作るための土台だが、ひとりのダッシュボード用に使っても全く問題ない。
Next.jsを使う理由は3つある。1つ目は、Vercel（Next.jsを運営している会社が提供する配信サービス）に無料でデプロイ（公開）できること。2つ目は、Claude Codeとの相性がよく、AIに頼んでコードを書いてもらいやすいこと。3つ目は、スマホからも同じ画面が見られること。
3つ目が特に大きい。外出先のカフェで、スマホを開くだけで今月の売上推移が見られる。この気軽さは、いちいちパソコンを開いてBIツールにログインする手間と比べると、体感で10倍くらい違う。数字を見るハードルが下がると、数字を見る回数が増える。回数が増えると、判断が早くなる。
週次レポートと異常値検知の価値
ダッシュボードを作っただけでは、人は毎日見に行かない。最初の1週間は見に行くが、3週目あたりから面倒になる。これは私自身の経験でもあり、周囲のひとり事業主を見ていても例外なくそうだ。
だから、見に行かなくても数字が飛んでくる仕組みをセットで用意する必要がある。具体的には、週次の自動レポートと、異常値の自動検知だ。月曜の朝8時にメールが届いて、先週の売上、粗利、トップ商品、気になる変動が3行でまとまっている。これだけで、数字を見る習慣が続く。
異常値検知というと難しく聞こえるが、中身はシンプルだ。直近4週間の平均と比べて、今週の数字が大きくズレたらメールを送る。このルールをSQLで1本書くだけで実現できる。AIや機械学習は使わなくていい。
参考になる事例
Metabase — オープンソース分析ツール
Metabaseはオープンソースの分析ツールで、無料で使える。ボタンをポチポチ押すだけで、売上推移のグラフや顧客別の集計表が作れる。技術に詳しくない人でも触れるように設計されていて、世界中の中小企業が導入している。
ひとり事業主にとって魅力的なのは、月額費用がかからない点だ。ただし弱点もある。サーバーを自分で用意して運用する必要があり、バックアップ、アップデート、セキュリティパッチ、すべて自分で管理しないといけない。数年運用してみると分かるが、この運用コストが地味に効いてくる。時間という形で、結局月3万円に近いコストを払っている感覚になることもある。
だから私の提案は、Metabaseを勉強用に触ってみて、その上で自分が本当に見たい画面だけをNext.jsで作り直すやり方だ。Metabaseは「BIツールとはこういうものか」を知るための教材として優秀で、実運用の本命はもっと軽い仕組みにする。この二段構えがちょうどいい。
ある個人事業主の話
私が知っているある個人事業主は、長らくBIツールに月2.5万円を払っていた。解約しようと何度も思ったが、解約すると数字が見られなくなるのが怖くて続けていた、と話してくれた。典型的なサブスク依存の形だ。
あるとき意を決して、週末の2日間を使ってSQLiteとNext.jsの自作ダッシュボードに乗り換えた。作ったのはたった3画面。今月の売上推移、商品別の粗利ランキング、リピート率の3つだけ。BIツールにあった30個のダッシュボードのうち、結局見ていたのはこの3つだけだったそうだ。
結果、月2.5万円の固定費がゼロになり、年間30万円が浮いた。しかも自作したことで、画面のどこをどう変えたいかを自分で判断できるようになり、むしろ以前より数字を深く見るようになった、という話だった。これは私にとって、ひとり事業主が分析基盤を自作する価値を強く示す事例だった。
具体的な手順
図: 週末2日間で作る手順
ここからは、実際に手を動かす部分の話をしていきたい。Claude Codeに頼む前提で書くので、コード部分はそのままコピペしてもらって構わない。
手順1 プロジェクトの土台を作る
まずパソコンのターミナル（黒い画面）を開いて、次のコマンドを打つ。打つ前に、Node.js（JavaScriptを動かすための環境）がインストールされているかだけ確認してほしい。
npx create-next-app@latest my-dashboard
cd my-dashboard
npm install better-sqlite3
これだけでNext.jsのプロジェクトと、SQLiteを扱うためのライブラリが入る。ここまではClaude Codeに頼まなくても、30秒で終わる作業だ。
手順2 データベースのテーブルを設計する
次に、売上データを入れるテーブルを作る。私の推奨は、できるだけシンプルに、1つのテーブルから始めることだ。複雑に正規化（データを分けて整理する技法）しない。ひとりで扱うデータなら、それで十分に動く。
CREATE TABLE sales (
id INTEGER PRIMARY KEY AUTOINCREMENT,
sold_at DATE NOT NULL,
product TEXT NOT NULL,
amount INTEGER NOT NULL,
cost INTEGER NOT NULL,
customer_id TEXT
);
sold_atは販売日、productは商品名、amountは売上金額、costは原価、customer_idはお客さんを識別する記号だ。これだけあれば、粗利もリピート率も計算できる。欲しくなったら後から列を足せばいい。SQLiteは列の追加が簡単だ。
手順3 データを流し込む
既存のデータは、おそらくどこかのサービスのCSVファイル（カンマで区切られた表データ）として取り出せる。ShopifyでもBASEでもSTORESでも、管理画面から月ごとのCSVが落とせるはずだ。それを読み込むスクリプトをClaude Codeに頼む。
頼むときのプロンプトは、たとえばこういう書き方になる。
「sales.csv を読み込んで、data.db という SQLite ファイルの sales テーブルに INSERT する Node.js スクリプトを書いてほしい。列は sold_at、product、amount、cost、customer_id で、文字コードは UTF-8。重複を避けるため、同じ sold_at と product と amount の組み合わせがあればスキップしてほしい」
このくらい具体的に書けば、Claude Codeは動くコードを返してくれる。返ってきたコードを実行すると、data.dbというファイルの中に、過去の売上データがすべて入った状態になる。最初はドキドキするが、手を動かすと想像より簡単だ。
手順4 KPIを計算するSQLを書く
ここが分析基盤の心臓部になる。といっても、書くSQLは驚くほどシンプルだ。今月の売上なら、次のようになる。
SELECT SUM(amount) AS this_month
FROM sales
WHERE sold_at >= date('now', 'start of month');
これで今月の売上合計が出る。先月同時点との比較を出したい場合は、次のように書ける。
SELECT
SUM(CASE WHEN sold_at >= date('now', 'start of month') THEN amount ELSE 0 END) AS this_month,
SUM(CASE WHEN sold_at >= date('now', 'start of month', '-1 month')
AND sold_at < date('now', 'start of month') THEN amount ELSE 0 END) AS last_month
FROM sales;
粗利は amount - cost で出せる。商品別の構成比はGROUP BYで集計する。リピート率は、同じcustomer_idが2回以上登場した割合を出せばいい。こうした分析用のSQLは、Claude Codeに「今月の売上と先月同時点との差分を出すSQLを書いて」と頼めば、ほぼ確実に正しい答えが返ってくる。
手順5 画面を作る
Next.jsのAPIルート（裏側でSQLを実行する場所）を作って、そこで上記のSQLを実行する。その結果を画面側で表示する。見た目はシンプルで構わない。数字と、小さな折れ線グラフが1つ、棒グラフが2つあれば、ひとり事業主が毎朝チェックするには十分だ。
ここでの落とし穴は、凝りすぎないことだ。色、フォント、アニメーション、こだわり始めると週末が消える。初版は白背景に黒文字、数字は大きく、それだけでいい。見た目より、数字が毎日正しく更新されていることのほうが10倍大事だ。見た目は、3ヶ月続けてから考え直せばいい。
手順6 週次レポートの自動送信
週次レポートは、毎週月曜の朝8時に、先週の数字をメールで自分に送る仕組みだ。Vercel Cron（指定した時刻に自動でプログラムを動かす機能）を使うと、追加コストなしで設定できる。
送る内容はシンプルに。先週の売上合計、前週比、トップ商品3つ、粗利額、気になる変動が1行。これを箇条書きで並べた本文を、Resend（メール配信の無料枠があるサービス）やSendGrid（老舗のメール配信サービス）で送る。HTMLで華やかに作り込む必要はない。テキストメールで十分だ。
Claude Codeには、こう頼めばいい。「Vercel Cronで毎週月曜の朝8時に起動するAPIルートを書いてほしい。SQLiteから先週の売上合計、前週比、トップ商品3つを取得して、Resend経由で自分のメールアドレスにテキストメールで送る処理。環境変数は RESEND_API_KEY と MY_EMAIL を使う」。これで動くコードが出てくる。
手順7 異常値検知の仕組み
最後に異常値検知だ。これは週次レポートと同じ仕組みで動かす。直近4週間の日次平均と、前日の実績を比較して、1.5倍以上または0.5倍以下ならアラートメールを送る、というルールだけで十分だ。
WITH recent AS (
SELECT AVG(daily) AS avg4w
FROM (
SELECT SUM(amount) AS daily
FROM sales
WHERE sold_at >= date('now', '-28 days') AND sold_at < date('now', '-1 days')
GROUP BY sold_at
)
),
yesterday AS (
SELECT SUM(amount) AS y FROM sales WHERE sold_at = date('now', '-1 days')
)
SELECT avg4w, y FROM recent, yesterday;
このSQLの結果を見て、yがavg4wの1.5倍以上または0.5倍以下ならメールを送る。ロジックとしてはこれだけでいい。本格的な統計処理は不要だ。ひとり事業主の売上規模では、このシンプルなルールで十分に役立つ。
統計的に厳密にやりたくなる気持ちは分かるが、ぐっとこらえてほしい。厳密さを追い求めると、導入できずに終わる。8割正しいルールを今日動かすほうが、100点のルールを3ヶ月後に動かすより、ずっと事業に効く。
よくある失敗・落とし穴
ここまで読んで、よし作るぞ、と思ってくれた人に、先に失敗パターンを伝えておきたい。私自身も他人の事例を通じて、いくつもの落とし穴を見てきた。
落とし穴1 最初から完璧を目指す
これが一番多い失敗だ。Notionでテーブル設計を何枚も書き、ダッシュボードのワイヤーフレーム（画面の下書き）を10枚作り、気づけば2週間が経っている。そして一度も動くものができないまま、熱が冷めて終わる。
推奨は、最初の週末の2日間で、雑でもいいから動くものを1つ作ることだ。売上合計の数字が1つだけ表示される画面でいい。それを作ってから、次の週末に改善する。このリズムを守ると、3ヶ月後には本当に使える基盤ができあがっている。
落とし穴2 KPIを盛りすぎる
初版のダッシュボードで15個の数字を並べる、というのもよくある失敗だ。見る側は自分しかいない。自分が見ない数字を並べても、画面が賑やかになるだけで意味がない。
最初は3つでいい。今月の売上、先月同時点との差分、粗利率。この3つから始めてほしい。使いながら「これも見たい」が出てきたら、1個ずつ足していく。この足し算のペースが、結果的に最適な設計になる。
落とし穴3 データが汚いまま入れる
CSVをそのまま流し込むと、半角スペースの有無、全角と半角の混在、空欄の扱いで、集計がズレる。商品名「コース A」と「コースA」が別物として集計される、みたいな事故が起きる。
対策はシンプルで、取り込み時に商品名の空白を除去し、大文字小文字を統一する。この下処理を1回書いておけば、あとの集計がすべて正しくなる。Claude Codeに「商品名の前後のスペースを除去し、半角を全角に統一した上でINSERTする処理を追加して」と頼めばやってくれる。
落とし穴4 バックアップを忘れる
SQLiteはファイル1個で完結する。裏を返すと、そのファイルが消えたら全部消える。パソコンの故障、うっかり削除、同期ミスで一瞬にして1年分のデータが消える。これは本当に起きる。
対策も簡単で、毎晩、そのファイルをDropboxやGoogle Driveの同期フォルダにコピーするスクリプトを走らせるだけでいい。macOSならlaunchd、WindowsならタスクスケジューラでOK。1日1回、深夜に走らせる設定を1回やっておけば、一生の安心が手に入る。
落とし穴5 数字が合っていないのに信じる
自作した分析基盤の数字が、実はどこかでズレている、というのは普通に起きる。税込みと税抜きの混在、返金処理の反映漏れ、返品の扱い。最初の1ヶ月は、必ず元の管理画面の数字と突き合わせて検算してほしい。
検算の方法は単純で、ある1ヶ月を選んで、そのダッシュボードの売上合計と、決済サービスの管理画面の売上合計が一致するか確認するだけだ。ズレていたら原因を特定して直す。3ヶ月連続で一致すれば、そこから先は信頼して使える。この検算フェーズを飛ばすと、間違った数字で意思決定することになる。これが一番怖い。
落とし穴6 Claude Codeに丸投げしすぎる
Claude Codeは強力だが、丸投げすると細かいところで事故が起きる。日付の解釈、タイムゾーン、エッジケース（例外的な条件）。これらは人間が読んで確認しないと分からない。
推奨は、書いてもらったコードを必ず目で読んで、分からない部分はClaude Codeに解説させることだ。「この関数が何をしているか、非エンジニア向けに説明して」と頼めば、丁寧に教えてくれる。この往復を繰り返すうちに、自分でも少しずつコードが読めるようになっていく。これは副産物として大きな財産になる。
明日からやる3つのこと
ここまで読んでくれた人に、明日からすぐできる行動を3つだけ置いておきたい。読んで満足して終わる人と、少しでも手を動かす人の差は、この3つを踏むかどうかで決まる。
1つ目。今契約しているBIツールや分析サービスを棚卸しして、年額いくら払っているか計算する。月額表示に慣れていると感覚が鈍るが、年額で見ると金額のインパクトが全然違う。その年額で、自作の基盤を作る週末2日間の価値が釣り合うかどうかを判断してほしい。
2つ目。今の事業で、毎朝必ず見たい数字を3つだけ紙に書き出す。5つでも10つでもなく、3つだ。これが自作ダッシュボードの設計図になる。多くの人はこの「3つに絞る」作業で迷うが、迷ったら「その数字がズレたら明日の行動が変わるか」を基準にしてほしい。行動が変わらない数字は、ダッシュボードに載せなくていい。
3つ目。次の週末の2日間を予約する。カレンダーに「分析基盤を作る」と入れてしまう。予約しないと、絶対に手を動かさないまま時間が過ぎる。2日間で完成しなくていい。売上合計が1つだけ表示される画面ができれば、それで合格だ。残りは次の週末に足していけばいい。
ひとり事業主にとって、数字を見る習慣は、事業の命綱だ。そしてその命綱を、月3万円のBIツールに預ける時代は、もう終わりつつある。Claude CodeとSQLiteとNext.jsがあれば、自分の手の中に、自分だけのための分析基盤を持てる。作ってしまえば、それは一生使える資産になる。
週末の2日間を、未来の自分への投資として使ってみてはどうだろうか。月3万円を払い続ける未来と、自分で作った基盤を使い続ける未来。どちらが自分の事業を強くするかは、もう答えが出ているはずだ。
