このデモの読み方
今回いただいた サンプル_マスタ実績データ.xlsx を実際に読み込み、Metabase(ノーコードBI)を導入した場合に何がどう見えるか を再現したデモです。前回のサンプルと違い、4種類のマスタ と売上金額 が揃ったため、「マスタと実績のつながり」「金額での集計」まで実演できます。
このモックは「見え方・操作のイメージ」です。 実際のシステムでは
Metabase / Superset というBI製品の標準画面をそのまま使う ため、この画面自体を作る開発は発生しません。弊社の作業は「分析DBの設計・構築」「製品の導入・設定」「取込バッチ」です。
どこまでが製品標準で、どこからが弊社の構築範囲か は
位置づけ・責任分界点 に整理しました(
まず最初にご覧ください )。
読み込んだデータサンプル_マスタ実績データ.xlsx
4 種類のマスタ
営業所10/コース50/得意先100/商品50
2026/4/1 → 8/20 約5か月分(月・エリア・区分あり)
¥34,639,200 売上金額の合計(今回は金額あり)
前回サンプルからの進化: ①マスタが付いた → コードを名称・エリア・カテゴリ で表示・集計できる/②売上金額 が付いた → 数量だけでなく金額での分析 ができる/③整合性が完璧 (孤立コード0件・金額=数量×標準単価が100%一致)。
3層の役割分担(ご提案書の再掲)
① Metabase(パッケージ/御社ご契約)パッケージ
グラフ・ダッシュボード・ノーコード集計・ドリルダウン・Excel/CSV出力。OSS版はユーザー数無制限で0円 (セルフホスト)。本デモの画面
② 分析DB(弊社構築)PFS
マスタと実績を結び付け(リレーション) 、BIが速く読める形に整える層。QlikViewのスクリプトが担っていた「加工」の受け皿。P5で解説
③ n8n(弊社構築)PFS
基幹CSVとマスタの自動取込・更新・配信 。人が触らなくても毎朝データが最新になる「線」の部分。P6で解説
次回ご確認いただきたい4点 = このデモの見どころいただいたメールのご要望に沿って構成しています
本デモはあくまでも仮定に基づくものです。 Metabaseを契約・セルフホストした場合の画面イメージを、いただいたサンプルデータで再現したものです。グラフの数値はすべて実データ(5,000行)の集計値で加工していませんが、実際の集計項目の定義・運用フロー・基幹連携方式は今後の要件定義でお客様と協議のうえ決定いたします。今回のサンプルは説明用に作られた整ったデータであり、本番データの品質確認は別途必要です(→
データ品質 )。
このデモの位置づけ・責任分界点
システム化にあたっての前提を確認するページです。モックの内容は実現できます。ただし“見た目”はモックのままにはならず、製品標準のデザイン になります。「何が製品標準の機能で、どこからが弊社の構築範囲か」をはっきりさせます。
前提:このモックは「イメージ」で、画面は作りません
モックは「Metabase / Superset を使うと、こういう見え方・操作になる 」というイメージをお示しするためのデモです。実際のシステムではこれらOSS製品の標準画面をそのまま使う ため、モックの画面を作る開発は発生せず、見積にも含んでいません 。
弊社(PFS)の作業は次の3つです
① 分析DBの設計・構築 実績とマスタを結び付け(リレーション)、BIが読める・速く返せる形に整える土台。
② 製品の導入・設定 Metabase / Superset のセルフホスト構築、接続設定、権限や配信の設定。
③ 取込バッチ 基幹から出るCSV/テキストを毎日取り込み、分析DBを最新化する仕組み。
モックの内容は実現できるか(4分類)結論:実現可能。ただし見た目は製品標準になります
実現できる(製品の標準機能) KPI表示/月別推移・カテゴリ別・区分別のグラフ/クロス集計/明細表/グラフをクリックして下の階層へ掘る操作/Excel・CSV出力/集計項目や軸をプルダウンで差し替える操作/メールでの定期配信。いずれもMetabaseが最初から持っている機能 で、弊社が作り込むものではありません。
モックと変わる点(見た目) 画面の配色・レイアウト・遷移の見せ方は製品標準のもの になります。「同じ情報に、同じ操作で辿れるが、見た目は製品のもの 」とご理解ください。本モックの配色やレイアウトは再現されません。
弊社側で作り込みが必要な部分 ドリルダウンの階層(エリア→営業所→コース→得意先 )は、分析DB側でその階層を持つデータを用意して初めて成立 します。グラフを掘る操作は製品機能ですが、掘れる階層を作るのは弊社の構築範囲 です。
現時点で確約できない点 ①速度: モックは5,000行をブラウザ内で計算しているため即時表示ですが、本番は数千万件のため事前集計テーブルを用意して速度を確保する設計 になります。実際の応答速度はPoCで実測して確定 します。②行レベル権限: 閲覧者ごとに見えるデータを制限する機能は、Metabase無償版では対応できない可能性 があります(有償Pro、または無償のSupersetで代替)。
Metabaseでできること(網羅一覧)「できない/有償」も正直に記載
ドリルダウン・集計・グラフ・出力・配信はすべて製品標準機能 で、弊社が画面を作るものではありません。弊社の構築範囲は「掘れる階層を持つ分析DB」と「自動取込(n8n)」 です(機能範囲はMetabase公式情報に基づく本資料作成時点の整理で、最終確定はPoCで行います)。
セキュリティ(セルフホスト/オンプレ)価格データを扱う前提で
データは社外に出しません
・Metabaseはセルフホスト(オンプレ) で運用でき、クラウドを経由しません
・第三者への共有・学習利用の心配がありません
・自動化のn8nもセルフホスト版(月額基本無料) でオンプレ運用可
IT統制のルール内で
・基幹(財務・売上・売掛)に直接つながずCSV連携 で運用可能
・実データを扱う検証の前に秘密保持契約(NDA) を締結
・行レベル権限が必須なら、オンプレのProやSupersetで対応
サーバー要件(「サーバーは必要か」へのご回答)エンジニア確認済み
物理サーバーは必須ではありません
「オンプレ」の要件はデータを社外に出さないこと 。社内ネットワーク内で動けば形態は問いません 。物理サーバー1台でも、既存の仮想基盤(VMware/Hyper-V等)上の仮想サーバー1台 でも可。仮想基盤があれば1台用意が最短で追加調達も不要です。
想定スペック(BI・分析DB・取込を1台に集約)
OS:Linux(Ubuntu/RHEL系)推奨。数千万件のため特にメモリが速度に効きます。
PCをサーバー代わりに:検証(PoC)はOK(むしろ推奨) —調達を待たず手元PCで構成確認まで可能。本番は非推奨 (性能でなく運用面:24時間稼働・RAID冗長化・無停電電源・固定IPがないため)。200〜300名が使う基盤のため、本番はサーバー(物理/仮想)を推奨します。
ご確認いただきたい4点は、このモックを操作しながらご覧いただけます
現時点では環境構築前のため、実物のMetabase画面はまだお見せできません。 この場ではこのモックの該当画面でご覧いただき 、実物での確認はPoC(実機検証)以降 となります。
取込対象ファイルの前提(範囲)
現在の前提に含まれる範囲
・実績データ 1系統 + マスタ 4種 (営業所・コース・得意先・商品)= 計5本
・形式は CSV/テキストの固定レイアウト
・日次1回 の取込
この範囲を超えるもの(別途追加が必要)
・別系統の追加(仕入・在庫・売上 などの別ファイル)
・Excel形式 での取込
・レイアウトが可変 のファイル
・日中の随時取込 (日次1回を超えるもの)
「テキストもCSVもExcelも来る」とのことでしたので、 実際にどの業務から・どの形式で・何本のファイルが出てくるか をお教えいただけますと、取込の範囲を確定できます。本数と形式によって構築範囲が変わります。
本ページはシステム構成上の前提を整理したものです。 製品標準機能・弊社構築範囲・確約できない点の区分は本資料作成時点の想定であり、最終的な機能範囲・速度・権限制御の可否は、PoC(実機検証)と要件定義を通じて確定いたします。
① マスタと実績データのつながり(リレーション)
BIの土台になる考え方です。実績データはコードしか持っていません 。そのコードをマスタ(辞書)と突き合わせて(=リレーション) 、はじめて「大阪営業所の飲料が…」と読める・集計できるデータになります。
リレーションとは?(かんたんに)
実績データ=日々の伝票。 「誰が・どの店に・どの商品を・いくつ」を、場所を取らないようコード(S001, P0001…) で記録します。
マスタ=コードの意味を書いた辞書。 「S001=大阪営業所(関西)」「P0001=飲料 商品001(標準単価500円)」のように、コードと名称・属性の対応表です。
リレーション=この2つを「同じコード」でつなぐこと。 実績の 営業所コード と、営業所マスタの 営業所コード を鍵にして自動でつなぎます。Excelの VLOOKUP を全項目・全行に一括でかけるイメージです。
つなぐと何が嬉しいか。 コードのままでは「S001の合計」しか出せませんが、つなげば「関西エリアの合計」「飲料カテゴリの合計」 のように、マスタが持つ属性で自由に集計できます。
ご確認いただきたい4点のうち、この「①リレーション」だけが弊社(PFS)の構築範囲です。 ②ドリルダウン・③集計の見え方・④集計方法の変更は、いずれもMetabaseの標準機能です。
今回のサンプルはコード整合性が100%(不一致0件) だったため、そのまま結合を組めます(→
責任分界点 )。
データの構造(スタースキーマ)中心の実績データが、4つのマスタを参照します
中心の実績データ が持つ4つのコードが、それぞれのマスタの先頭列(主キー) と一致します。この「1つのファクト(実績)+複数のマスタ」という放射状の形をスタースキーマ と呼び、BIで最も扱いやすい標準形です。
実演:伝票1行が「読めるデータ」に変わる
別の伝票で見る
売上金額は「商品マスタの標準単価 × 実績の数量」で説明できます (今回のサンプルは5,000行すべてで一致を確認)。実運用では特売値引き等で単価が動くため、実際の売上金額そのものを実績側に持たせるのが一般的です。
マスタの中身(実データ)タブで切り替え
マスタは基幹システムから出力し、n8nで分析DBに取り込みます。
マスタが更新されれば(新店舗・新商品など)、翌日の集計に自動で反映 されます(→
n8n自動化 )。
③ 集計方法を変える(ノーコード) Metabase 標準機能
「集計方法の変更方法」のご確認への回答です。「何を集計するか」と「何でまとめるか」をボタンで選ぶだけ で、実データ5,000行から本物の集計結果が出ます。SQLは一切書きません。
最初から
この画面の解説
Metabaseの「クエリビルダー」を再現しています。 実際の画面でも ①データ ②絞り込み ③集計 ④まとめる単位 ⑤グラフ という同じ順に選ぶだけです。
「集計方法を変える」=2か所を選び直すだけ。 「③集計」で金額/数量/件数/平均単価などを、「④まとめる単位」でエリア/商品/月などを選ぶと、結果が即座に組み替わります。
QlikViewとの決定的な違い。 QlikViewは切り口を増やすたびスクリプト改修=有識者待ちでした。Metabaseは見る人が自分で選び直せます 。
作った集計は保存・共有・ダッシュボード配置が自由。 「誰かの手元のExcel」ではなく、みんなで使える共有資産になります。
この「集計方法の変更(④)」もMetabaseの標準機能です。 弊社が画面を作るのではなく、製品が最初から持っている操作です。
QlikViewのようにスクリプトを書く必要がなくなる 点が、今回の移行の中心になります。実物の画面デザインは製品標準となり、確認はPoC以降です(→
責任分界点 )。
クエリビルダークリックして組み立ててください
1
データData
📦 実績データ(分析DB) 5,000行
2
絞り込みFilter
なし(全件)
エリア=関西
区分=特売
2026/7 以降
3
集計何を計算
売上金額の合計
数量の合計
納品件数の合計
件数(伝票数)
平均単価
得意先の種類数
4
まとめる単位Group by
月
エリア
営業所
商品カテゴリ
商品
得意先
区分
曜日
裏で生成されるSQL(参考・書く必要はありません) -- 手順3(集計)と手順4(まとめる単位)を選んでください
左の 3・4 を選ぶと、実データを集計した結果がここに出ます
いろいろ試してみてください。 例:「売上金額の合計 × エリア」→ 関西が突出、「平均単価 × 商品カテゴリ」→ 日用品が高い、「数量の合計 × 曜日」→ 曜日の偏り。同じデータでも、選び方を変えるだけで別の発見が出ます 。これが属人化からの脱却です。
分析DBでリレーションを構築する PFS構築
①で見た「マスタと実績のつながり」を、実際に速く・安定して動かすための土台 です。QlikViewのスクリプトが担っていた「加工・結合」を、標準的なSQL(またはn8nの画面操作)で置き換え、脱属人化します。
リレーションを1つのビューにまとめる
-- 実績データに4つのマスタを結合し、名称・属性を付与した「読めるビュー」
CREATE VIEW v_shipment AS
SELECT f.実績日, f.月,
o.営業所名, o.エリア, -- ← 営業所マスタ
c.コース名, -- ← コースマスタ
k.得意先名, k.店舗区分, -- ← 得意先マスタ
p.商品名, p.商品カテゴリ, p.標準単価, -- ← 商品マスタ
f.数量, f.売上金額, f.納品件数, f.区分
FROM 実績データ f
JOIN 営業所マスタ o ON f.営業所コード = o.営業所コード
JOIN コースマスタ c ON f.コースコード = c.コースコード
JOIN 得意先マスタ k ON f.得意先コード = k.得意先コード
JOIN 商品マスタ p ON f.商品コード = p.商品コード;
これを一度作れば、以降のBIは全部このビューを見るだけ。 Metabase上ではSQLを意識せず、「エリア」「商品カテゴリ」を選ぶだけで集計できます。結合ルールの管理が1か所に集約 され、属人化しません。
事前集計で数百万件でも高速に
-- BIが即答できるよう、よく使う粒度に事前集計しておく
CREATE TABLE mart_sales_daily AS
SELECT 月, エリア, 営業所名, 商品カテゴリ, 区分,
SUM (売上金額) AS 売上金額,
SUM (数量) AS 数量,
SUM (納品件数) AS 納品件数,
COUNT (*) AS 件数
FROM v_shipment
GROUP BY 月, エリア, 営業所名, 商品カテゴリ, 区分;
QlikViewが「メモリに全部載せて速い」を実現していた部分は、この事前集計テーブル で代替します。実運用の数百万〜数千万件でも、見る粒度に集計しておけば300名同時でもサクサク です。
SQLはあくまで構成イメージです。 実際のテーブル名・結合キー・集計粒度は、基幹システムの出力仕様と御社の分析要件に合わせて設計します。この層は弊社(PFS)が構築・保守し、御社に属人的なコード管理は発生しません。
今回のサンプルを読んで分かったこと(データ品質)
いただいたサンプルを機械的に全件チェックした結果です。今回のデータは「説明用に整えられた、非常にきれいなデータ」 でした。本番データではここが崩れることが多いため、確認すべき観点を整理します。
参照整合性 100% 実績の営業所/コース/得意先/商品コードはすべてマスタに存在 (孤立コード0件)。リレーションがきれいに張れます。
金額の筋が通っている 売上金額 = 数量 × 標準単価 が5,000行すべてで一致 。金額の検算が可能です。
欠損・ゼロなし 数量・売上金額・納品件数に0や空欄なし 。区分は特売/通常/追加の3種で統一。
本番データで確認すべき観点今回サンプルはきれいですが、実データでは要注意
次回に向けてのお願い事項
過去データの有無 は、ご提案の幅が大きく変わる分岐点です。QlikViewの元データに数年分が残っていれば、予測系を大きく前倒しできます。
本ページはいただいたサンプルデータの実測に基づく所見です。 今回のサンプルは説明用に整えられたデータのため品質上の問題は見当たりませんでしたが、本番データでは上記観点の確認が必要です。各項目の業務上の定義は、要件定義でお客様と協議のうえ確定します。
段階導入の進め方(案)
「やりたいことを先に固めないと収拾がつかない」というご懸念に対し、小さく作って早く見せる ことで要件を固めていく進め方をご提案します。2027年の基幹刷新までの時間軸も考慮しています。
フェーズ0:検証(PoC)
Metabase・分析DB・n8nを検証環境に構築
今回のマスタ+実績データを実際に投入
マスタと実績のリレーションを確定
現場の方に実際に触っていただく
基幹からの出力方式・文字コードの確認
ゴール:「自分たちで作れる」を体感いただき、要件を実物ベースで固める
フェーズ1:本番構築
分析DBの本番構築・本番マスタ連携
n8nによる日次自動取込フローの構築
売上ダッシュボードの本番公開
既存Excel帳票の自動生成・配信への置換
操作研修(作る人/見る人で分けて実施)
ゴール:QlikViewの現行機能を代替し、日々の運用を回す
フェーズ2以降:拡張
原価・粗利データの追加連携
2027年基幹刷新への対応(取込層の改修)
独自日報システム等の統合
過去データ投入による前年比・季節性分析
需要予測・予兆検知・生成AI活用の検討
ゴール:QlikViewではできなかった領域へ踏み出す
次のステップ(実機確認までの進め方)商談でご相談した流れ
Metabase契約御社でオープンソース版をセルフホスト(オンプレ)。弊社はMetabaseとは無関係 で、御社が直接ご契約。
NDA締結実データを扱う前に会社間で秘密保持契約 。御社データを厳重に扱います。
エンジニア相談実データ・実画面をエンジニアと確認し、実現可能性をすり合わせ (本格稼働前の相談ベース)。
PoC(実測)応答速度(数千万件)・行レベル権限 など、確約前の項目を実機で検証・確定。
本契約・伴走分析DB構築・取込・ダッシュボード公開。月額伴走で内製化まで支援 。
本格的なPoC(エンジニア稼働)は本契約後 ですが、その前段はNDAベースの相談 として柔軟に対応します。まずは①Metabaseのご契約 からスタートいただければ、そこから一緒に進めていきます。
内製化・伴走・勉強会(作って終わりにしません)
弊社は「システムを作って納品して終わり」にはしません。御社が自分たちで自動化を作れる ようになるまで、月額の伴走費の中で ご支援します。
要件定義・方向性決定・定例お打ち合わせ
全社員/部門向けの勉強会 ・操作研修(作る人/見る人)
1日集中の合宿型ワークショップ (自分でワークフローを作れる状態へ)
BIだけでなく他業務の自動化(n8n)のご相談 も範囲内
自動化(AIセールスくん)も同時並行で
BIの集計を各営業所へ自動配信する、商談・メール・議事録を自動化するなど、n8nを使った自動化の実例集 を別デモにまとめています。伴走の中で、御社に合うものから構築できます。
AIセールスくん(自動化デモ)を見る
進め方の注意点
最初から全部作らない。 「やりたいことが未整理」というご懸念には、1つのダッシュボードを実データで作って触っていただく のが最短です。要件は議論より実物から出てきます。
指標の定義を先に決める。 「純売上に返品を含めるか」等は作り始める前に決着させます。後から変えると全ダッシュボードの数字が変わります。
基幹刷新のスケジュールと重ねる。 2027年の刷新で仕様が変わるため、取込層(n8n)を疎結合に設計 しておくことが前提です。
「作る人」を社内に育てる。 ノーコードでも最初は作り方の型が要ります。研修で数名に型を持っていただくのが、属人化を再発させないコツです。
本資料はあくまでも仮定に基づくご提案です。 機能説明・運用フロー・段階導入の区切りは想定であり、実運用の設計はお客様との協議のうえ決定いたします。ダッシュボードの集計値はいただいたサンプルデータの実測値です。Metabase・n8nの機能範囲は本資料作成時点の公開情報に基づきます。