トヨタモビリティパーツ様 ｜ このデモの読み方
接続先：分析DB 18,330 行（サンプルデータ.xlsx 実データ） Metabase v0.5x セルフホスト（仮定）
TMP

このデモの読み方

2026/7/29 のお打ち合わせでいただいた サンプルデータ.xlsx（出荷実績 18,330行） を実際に読み込み、Metabase を契約・セルフホストした場合に何が見えるかを再現したデモです。グラフの数値はすべて実データの集計値で、加工・脚色はしていません。

ご提案書に戻る ダッシュボードを見る

読み込んだ実データ

サンプルデータ.xlsx / Sheet1
18,330 行
出荷明細（ヘッダ行を除く）
13 項目
売上日／お客様コード／GD／出荷数合計／品番／商品グループ／メーカーコード／フォローコード／納品区分 ほか
2026/5/1 → 6/1
31日分（1か月）
21 / 4,050 / 147 / 64
お客様コード／品番／商品グループ／メーカーコード の実数
このデータには金額項目がありません。したがって本デモのグラフはすべて「件数」と「出荷数」ベースです。売上金額・粗利の分析は、金額列を連携いただいた時点で同じ操作のまま作成できます（→ できない予測）。

3層の役割分担（ご提案書の再掲）

① Metabase（パッケージ／御社ご契約）パッケージ

グラフ・ダッシュボード・ノーコード集計・Excel/CSV出力・共有。OSS版はユーザー数無制限で0円（セルフホスト・AGPLv3）。本デモの画面

② 分析DB（弊社構築）PFS

基幹から出てくる明細を貯め、BIが速く読める形に集計・整形する層。QlikViewのスクリプトが担っていた「加工」の受け皿。P4で解説

③ n8n（弊社構築）PFS

基幹CSVの自動取込・検証・DB投入・更新・配信。人が触らなくても毎朝データが最新になる「線」の部分。P5で解説

BIツールだけでは動きません。Metabaseは「見せる」層です。②と③がないと、結局誰かが手でCSVを整形して読ませることになり、属人化はQlikViewのまま残ります。

ページ構成とご確認いただきたい点

ページ内容ご確認いただきたいこと担当層
ダッシュボード実データ18,330行を集計した出荷実績ダッシュボード。期間・お客様・商品グループのフィルタが実際に効きます。グラフのクリックでドリルダウンします。この粒度・この切り口で業務が回るかMetabase
ノーコード作成SQLを書かずにクリックだけで上のグラフを作る手順を、そのまま操作できる形で再現。現場の方が自分で作れそうかMetabase
出力・共有Excel/CSV/PDF出力、定期配信、ダッシュボード共有の範囲と、有料機能との境目。Excel出力の形が実務に合うかMetabase
分析DB集計18,330行の明細を、BIが即答できる集計テーブルに落とすまでのSQL・テーブル設計。集計の定義（何を1件と数えるか）PFS構築
n8n自動化基幹CSV検知→検証→DB投入→更新→配信までの自動化フロー。実行ログ付き。基幹からの出力方式・タイミングPFS構築
データ品質実データを読んで実際に見つかった問題点（定数列・重複行・未定義コード等）。各コードの意味・正しい定義御社ご教示
できない予測今のデータでは原理的にできない分析と、何を足せばできるようになるか。追加連携できる項目の有無御社ご確認
本デモはあくまでも仮定に基づくものです。Metabaseを契約・セルフホストした場合の画面イメージ、および分析DB・n8nの構成案を、いただいたサンプルデータで再現したものです。集計項目の定義、実際の運用フロー、基幹システムからの連携方式は、今後の要件定義でお客様と協議のうえ決定いたします。データの集計値そのものは実データに基づく実測値ですが、各コードの業務上の意味は弊社の推定を含みます。

出荷実績ダッシュボード Metabase 標準機能

実データ18,330行をそのまま集計しています。上のフィルタを操作すると全グラフが連動し、グラフの棒をクリックするとその条件で絞り込まれます（Metabaseのドリルダウン相当）。

この画面の解説

  • すべてノーコードで作れます。下の6つのグラフはSQLを1行も書かず、「集計する内容を選ぶ → グループ化する列を選ぶ → グラフ種類を選ぶ」の3クリックで作成できます（作り方はノーコード作成で実演）。
  • フィルタは後から自由に足せます。ダッシュボード上部のフィルタは、各グラフの列に紐づけるだけで全体に効きます。QlikViewのように再スクリプトは不要です。
  • クリックで深掘りできます。棒グラフをクリック → そのお客様だけの内訳へ。さらに掘ると明細行まで到達し、その場でCSV/Excel出力できます。
  • この速度は分析DB側の設計あってこそです。18,330行なら生データ直読みでも動きますが、実運用の数百万行では事前集計がないと待たされます。
画面・グラフ＝Metabaseデータの形・速度＝分析DB（PFS）最新化＝n8n（PFS）
期間
お客様コード 商品グループ 納品区分
出荷明細件数
–
–
出荷数合計
–
–
出荷数0の明細
–
意味の定義が必要（P6）
取扱品番数
–
–
お客様数
–
–

日別の出荷推移

出荷数合計 と 明細件数
折れ線クリックでその日に絞込
出荷数合計明細件数
–

お客様コード別 出荷数

クリックでドリルダウン

商品グループ別 出荷数 TOP10

クリックで絞込

曜日別の負荷

明細件数
–

メーカーコード別 構成

出荷数シェア

品番の集中度（ABC分析）

出荷数の累計構成比
–

お客様 × 商品グループ

出荷数のクロス集計
少 多※数値は出荷数合計

ドリルダウン先の明細（集計表）

この表がそのままExcel出力されます

ノーコードでグラフを作る Metabase 標準機能

「開発できる人が限られ、運用が属人化している」という現状課題への直接の回答です。下のボタンを順に押すだけで、実データから本物の集計結果が出ます。SQLは一切書きません。

この画面の解説

  • Metabaseの「クエリビルダー」を再現しています。実際の画面でも ①データ ②フィルタ ③集計 ④グループ化 ⑤可視化 という同じ順に選ぶだけです。
  • QlikViewとの決定的な違い。QlikViewは新しい切り口が欲しくなるたびにスクリプト改修＝有識者待ちでした。Metabaseは見る人が自分で列を選び直せます。
  • SQLが書ける方はSQLでも書けます。ノーコードで作ったものをSQLに変換して編集することも、最初からSQLで書くことも可能です（両方標準機能）。
  • 作った質問（Question）は保存・共有・ダッシュボードへの配置が自由です。「誰かの手元のExcel」ではなく共有資産になります。

クエリビルダー

クリックして組み立ててください
1
データData
18,330行
2
フィルタFilter
3
集計Summarize
4
グループ化Group by
5
可視化Visualize
裏で生成されるSQL（参考・書く必要はありません）
-- 手順2〜5を選択してください

実行結果

–
左の 2〜5 を選ぶと、実データを集計した結果がここに出ます

カスタム式（Excel関数のような書き方）

Metabase標準・SQL不要

7/29のお打ち合わせでご質問いただいた「計算・集計」は、Metabaseのカスタム列／カスタム集計で対応できます。Excelの関数に近い書き方です。実データに当てはめた例：

やりたいことカスタム式の書き方実データでの結果
出荷ゼロ率を出すShare([出荷数合計] = 0)全体 15.1%（2,776件 / 18,330件）
出荷ゼロ件数だけ数えるCountIf([出荷数合計] = 0)フォローコードQ で 1,523件（同コード内の50.6%）
1明細あたりの平均出荷数Sum([出荷数合計]) / Count()全体 1.47
区分名に読み替えるcase([納品区分]="2","当日便",[納品区分]="6","定期便","その他")※区分の実名称は御社ご教示が必要（P6）
大口明細だけフラグcase([出荷数合計] >= 10, "大口", "通常")大口 296件（1.6%）
使い分けの指針。「1つのグラフの中で完結する計算」はMetabaseのカスタム式が速いです。一方全社で共通に使う指標（欠品率の定義など）は分析DB側で1回だけ計算して全員が同じ数字を見る形にします。ここを分けないと、部署ごとに違う「欠品率」が生まれます。

出力・共有でできること Metabase ＋n8n

「Excelに落として使う」現場運用をそのまま残せるか、という論点です。OSS版（無償）でできること／有料プランが必要なことを分けて記載しています。

この画面の解説

  • Excel/CSV出力はOSS版の標準機能です。画面の右下のダウンロードボタンから .xlsx / .csv / .json、グラフは .png で落とせます。追加費用はかかりません。
  • 「毎朝決まった人にExcelを送る」はn8n側で作ります。Metabase単体のメール定期配信もありますが、宛先ごとに絞り込みを変える・ファイル名を業務ルールに合わせる・共有フォルダに置くといった実務要件はn8nの方が柔軟です。
  • ユーザー数は無制限（OSS版）です。QlikViewの同時接続ライセンスのような「見る人が増えると費用が増える」構造から外れます。
  • ただし細かい権限制御は有料です。行レベル権限（このお客様の行だけ見せる）・SSO・監査ログは Pro 以上。ここは正確にお伝えしておきます。

OSS版（無償・セルフホスト）でできること

Excel（.xlsx）／CSV／JSON 出力

集計結果も明細も、画面から1クリック。P1の下部の表がそのまま出力されるイメージです。

グラフのPNG出力・ダッシュボードのPDF出力

会議資料への貼り付け用。

ユーザー数・ダッシュボード数 無制限

閲覧者を増やしても0円。部署単位のコレクション（フォルダ）で整理できます。

ダッシュボードのメール定期配信（Subscription）

毎朝8時に指定ダッシュボードをメール送信、といった設定が画面から可能です。

REST API

外部システムから集計結果を取りに行く／n8nから叩く、が可能。連携の土台になります。

コレクション単位の閲覧権限・グループ管理

「営業部フォルダは営業部だけ」程度の制御はOSS版で可能です。

有料プランが必要なこと（正確にお伝えします）

行レベル・列レベルの権限

「担当のお客様の行だけ見える」制御は Pro 以上。代替：拠点別にビューを分けて配置

SSO（SAML/JWT）・監査ログ

社内認証基盤との統合は Pro 以上。代替：Google認証はOSS版でも可

Metabot（AIによる自然言語質問）

有料アドオン。代替：生成AI＋n8nで別途構成可能

ホワイトラベル（ロゴ差し替え等）

社外配布用途で必要になれば Pro 以上。

現時点のご提案は OSS版（0円）を前提としています。上記が業務要件になった段階で、初めて有料プランの検討が必要になります。要件定義でここを見極めます。

「Excelに落として配る」をn8nで自動化した場合 PFS構築

毎朝 7:30

スケジュールトリガー

Metabase API

保存済みの質問を実行し結果を取得

宛先ごとに分岐

お客様コード単位でデータを分割

Excel生成

既存の帳票フォーマットに流し込み

配信

メール／共有フォルダ／チャットへ

ここが「点」ではなく「線」の自動化です。Metabase単体の配信は「同じ内容を全員に送る」までですが、n8nを挟むと宛先ごとに中身を変え、既存のExcel様式のまま配ることができます。受け取る側の仕事のやり方を変えずに済むのが利点です。

分析DBでの集計 弊社構築範囲

QlikViewのスクリプトが担っていた「データの加工」は、BIツールを替えるだけでは消えません。この層に移すことで、加工ロジックが全員に見える形（SQL）になり、属人化が解けます。

この画面の解説

  • なぜ必要か。いただいたデータは明細のベタ持ちです。これを毎回そのまま集計すると、行数が増えたときにダッシュボードが重くなります。あらかじめ集計しておく層が要ります。
  • 実測：18,330行 → 9,784行に圧縮できます。「日付×お客様×商品グループ×メーカー×納品区分×フォローコード」で束ねると約47%に減り、ダッシュボードの応答が安定します（本デモは実際にこの集計済みデータで動いています）。
  • 指標の定義を1か所に集約します。「欠品とは何か」「1件とは何か」をここで定義すれば、誰がどのグラフを作っても同じ数字になります。
  • 2027年の基幹刷新への備えにもなります。基幹の出力仕様が変わっても、この取込層のSQLだけ直せばダッシュボードは作り直し不要です。QlikViewのように全面再構築になりません。
設計・構築＝PFS指標の定義＝御社ご教示
① 生データ層（Raw）
18,330行
基幹から来た明細をそのまま保管
（監査・再集計のため無加工で残す）
1か月分
② 整形層（Cleansed）
-2,607行
全列が完全に一致する重複行を検出
（実測値・扱いは要ご確認 → P6）
要定義
③ 集計層（Mart）
9,784行
BIが直接読む集計テーブル
約47%に圧縮／ダッシュボードは即応答
Metabaseの接続先

集計テーブルを作るSQL（実データに対応）

日次でn8nが実行
-- ③ 集計層：日付×お客様×商品グループ×メーカー×納品区分×フォローコード CREATE TABLE mart_shipment_daily AS SELECT sales_date -- 売上日 , customer_cd -- お客様コード , product_group -- 商品ｸﾞﾙｰﾌﾟ , maker_cd -- メーカーコード , delivery_type -- 納品区分 , follow_cd -- フォローコード , COUNT(*) AS detail_cnt , SUM(ship_qty) AS ship_qty , COUNT(*) FILTER (WHERE ship_qty = 0) AS zero_cnt , COUNT(DISTINCT part_no) AS part_kinds FROM raw_shipment GROUP BY 1,2,3,4,5,6; -- 結果：18,330行 → 9,784行（実測）
このSQLは弊社が作って保守します。現場の方が触る必要はありません。触るのはこの上のMetabase画面だけです。

テーブル構成案

テーブル役割更新想定行数
raw_shipment出荷明細（無加工）日次追記年 約22万行
mart_shipment_daily日次集計（BI接続先）日次洗替年 約12万行
mart_part_abc品番ABCランク日次再計算4,050行
m_customerお客様マスタ未連携随時21行
m_product品番マスタ未連携随時4,050行
m_code区分コード名称未連携随時数十行
マスタ3種が未連携です。今のデータはコードのみのため、画面上も「37631」「OI」「70000」というコードのまま表示されています。マスタを連携いただければ、同じグラフが「お客様名」「商品グループ名」で表示されます。要件定義での最初の確認事項です。

なぜ「BIツールを替えるだけ」では終わらないのか

QlikViewが担っていた仕事BIツール単体で代替できるか本ご提案での受け皿
データの取込（テキスト/CSV読込）できない BIは基本DBに繋ぐもので、ファイルの定期取込は守備範囲外n8n ファイル検知→取込
データの加工・結合（スクリプト）できない 画面ごとの計算はできるが、共通の加工ロジックの置き場がない分析DB SQLで定義
事前集計・インメモリ保持部分的 キャッシュはあるが、集計設計そのものは必要分析DB 集計テーブル
グラフ・ダッシュボード表示できる ここがMetabaseの本領Metabase
配布・共有できる ユーザー数無制限で共有・配信Metabase＋n8n
「BIツールの費用だけ見て乗り換えると、加工の受け皿がなく結局スクリプトを書ける人に依存し続ける」——これが最も避けたい着地です。属人化を解くのは分析DBとn8nの層であり、Metabaseはその成果を全員に配る役割です。

n8nによる自動化 弊社構築範囲

基幹システムからのCSV出力を検知し、検証・投入・集計・配信までを人手ゼロで回す想定フローです。「実行」ボタンで動きをご覧いただけます。

この画面の解説

  • 「毎朝データが最新になっている」状態を作るのがn8nの仕事です。誰かが出社してCSVを流し込む、という運用をなくします。
  • 検証ステップが要です。行数が想定より極端に少ない／日付が飛んでいる／未知のコードが出てきた、といった異常をダッシュボードに反映する前に止めて通知します。間違った数字が独り歩きするのを防ぎます。
  • 2027年の基幹刷新時、直すのはこのフローの入口だけです。出力仕様が変わっても、後段の分析DB・Metabaseはそのまま使えます。
  • セルフホスト版はライセンス無料で、オンプレ環境に設置できます（データを外に出さない構成）。

メインフロー：基幹CSV → 分析DB → Metabase更新 → 配信

毎営業日 6:00 起動
①ファイル検知

基幹が出力した売上CSVを共有フォルダで待機

②データ検証

行数・日付連続性・必須項目・未知コードをチェック

③整形・名寄せ

重複除去・コード→名称変換・型変換

④分析DBへ投入

raw層へ追記（冪等・再実行可）

⑤集計テーブル更新

mart層のSQLを実行し洗い替え

⑥Metabase更新

REST APIでキャッシュ再生成

⑦配信・通知

Excel添付でメール／チャットへ完了通知

実行ログ

待機中
--:--:--「ワークフローを実行」を押すと動作します

異常時に自動で止める・知らせる

検知する異常判定ルール（案）動作
ファイル未着6:30時点でCSVが無い通知
行数の急変直近同曜日の平均比 ±50%超保留＋通知
日付の欠落前回取込日との間に営業日の抜け保留＋通知
未知コード出現マスタに無い商品グループ／メーカーコード取込継続＋一覧通知
出荷ゼロ率の急変実測ベース15.1%から大きく乖離通知
重複行の急増実測ベース2,607行から大きく乖離通知
判定ルールの閾値は、本デモで実測した値を初期値として置いています。運用しながら調整します。

このほかに自動化できる業務（ご参考）

複数システムのデータ集約

基幹・独自日報システム・Excelを1つの分析DBに寄せる。API／CSV／RPAいずれの方式にも対応可能です（方式は要確認）。

定型帳票の自動作成

既存のExcel様式に数字を流し込んで生成。受け取る側の様式を変えずに済みます。

閾値アラート

「特定のお客様の出荷が3日連続ゼロ」等を検知して担当者へ通知。BIは見に行くもの、n8nは知らせるもの。

PDF・帳票のデータ化（OCR）

7/29でご質問いただいた領域。手書きも読めますが「0とO」等は最終確認を人の目で行う運用が前提です。別途要件定義

生成AIによる要約・コメント生成

「今週の出荷傾向を3行で」といった要約を自動生成しダッシュボードに添える。要別途検討

基幹への書き戻し

技術的には可能ですが、基幹側の受け口とリスク評価が必要です。要確認

実データを読んで分かったこと 御社ご教示事項

いただいた18,330行を実際に解析した実測結果です。BI構築の前に定義を決めておかないと、数字が食い違う原因になる箇所を挙げています。これは「データが悪い」という話ではなく、要件定義で最初に潰すべき論点の洗い出しです。

この画面の解説

  • ここを曖昧にしたままダッシュボードを作ると、必ず後で作り直しになります。「その数字の定義は？」が最初に来る質問だからです。
  • 7/29に伺った「やりたいことを先に固めないと収拾がつかない」というご懸念への、具体的な着手点としてご覧ください。抽象的に議論するより、実データの論点から詰める方が早く固まります。
  • 各項目は実データの集計値（実測）と、弊社の推定を分けて記載しています。

常に同じ値しか入っていない列が2本あります

実測

「DS：ND」と「SM：ND」の2列は、18,330行すべてで値が「1」でした。分析軸として使えません（グラフにしても1本の棒にしかなりません）。

列名実際に入っていた値種類数分析での使用可否
DS：ND1 のみ1使用不可
SM：ND1 のみ1使用不可
OＢＯ：ND1（15,772件） / 2（2,558件）2意味の確認要
SM：ND（4列目）0（17,999件） / 7（252件） / 6（79件）3意味の確認要
ご確認いただきたいこと：これらの列の正式名称と意味、および「SM：ND」という同名の列が2本ある理由（抽出条件の違い等）をご教示ください。意味が分かれば分析軸として活かせます。

出荷数が「0」の明細が15.1%あります

実測

2,776件 / 18,330件。この行が「欠品」なのか「取寄せ扱い」なのか「伝票上の区分行」なのかで、作るべき指標が変わります。偏りには明確な傾向がありました。

切り口特に高い区分出荷ゼロ率
フォローコードQ（3,008件中1,523件）50.6%
フォローコード2（283件中140件）49.5%
フォローコードZ（2,206件中0件）0.0%
納品区分2（10,000件中2,345件）23.4%
納品区分6（6,317件中163件）2.6%
商品グループOZ（539件中314件）58.3%
ご確認いただきたいこと：出荷数0の行の業務上の意味。もし「欠品」であれば、これは欠品率ダッシュボードという最も価値の高い分析につながります。フォローコードQに集中している点から、弊社としては「取寄せ・後日出荷を表す区分」ではないかと推定していますが、確証はありません。

全項目が完全一致する行が2,607件あります

実測

同じ売上日・同じお客様・同じ品番・同じ数量…と、13項目すべてが一致する行です。正常な複数伝票なのか、抽出時の重複なのかで集計結果が変わります。

例：2026/5/1 にお客様コード 37590・品番 V92220011 の行が同一内容で複数存在
ご確認いただきたいこと：これらを「別々の伝票（そのまま数える）」と扱うか「重複（1件に寄せる）」と扱うか。件数系の指標が最大14%変わりますので、最初に決める必要があります。伝票番号・明細番号の列を追加いただければ、この判断は自動化できます。

コードの名称マスタがありません

要連携

お客様も商品グループもメーカーもコードのみです。そのためP1のダッシュボードはコード表示のままになっています。会議で使う資料としては名称表示が必須です。

項目種類現在の表示マスタ連携後
お客様コード2137631○○店／○○営業所
商品ｸﾞﾙｰﾌﾟ147OI（品目カテゴリ名）
メーカーコード6470000（仕入先名）
納品区分72 / 6 / 5 …（当日便／定期便 等）
フォローコード109 / 3 / Q / Z …（要ご教示）
GD201 / 05（要ご教示）
マスタはCSV1枚いただければ連携できます。分析DBに取り込めば、既存のグラフはそのまま名称表示に変わります（グラフの作り直しは不要です）。

次回までにご確認いただきたい事項（まとめ）

#確認事項なぜ必要か影響度
1出荷数0（2,776件）の意味欠品率という最重要指標が作れるかどうかが決まる大
2完全重複行（2,607件）の扱い件数系の全指標が最大14%変わる大
3金額項目を連携できるか売上・粗利の分析可否が決まる（→P7）大
4各マスタ（お客様／品番／区分名称）の提供可否グラフを名称表示にできる中
5DS：ND / SM：ND / OＢＯ：ND の定義分析軸として使えるか判断できる中
6お客様コードは店舗か得意先かダッシュボードの階層設計が変わる中
7基幹からの出力方式・頻度・文字コードn8n取込フローの設計に直結中
8独自日報システムの連携方式（API／CSV／RPA）7/29の未解決事項。データ統合範囲が決まる中

現状のデータでは「できない」こと

ノーコードBIは万能ではありません。いただいたデータで原理的にできない分析を、できない理由と「何を足せばできるか」とセットで正確に記載します。ここを最初に共有しておくことが、導入後の期待値ずれを防ぎます。

この画面の解説

  • 「できない」には2種類あります。①データが無いからできない（項目を足せば解決）②期間が足りないからできない（時間が解決）。前者は要件定義で、後者は運用開始後に自然に解けます。
  • 特に重要なのは「予測」です。需要予測・欠品予測はご期待の大きい領域ですが、1か月分のデータでは統計的に成立しません。この点は先に明確にしておきます。
  • 下表の「必要なもの」がそろえば、いずれもMetabase＋分析DBの範囲で実現可能です（AIが必要なものは別途明記しています）。

① データが無いためできないこと

売上金額・粗利・単価の分析

13項目に金額列が1つもありません。「どのお客様が儲かっているか」「粗利率の高い商品グループは」といった、BI導入で最も求められる分析が現状はできません。

必要なもの：売上単価／売上金額／原価（または仕入単価）の連携 → 連携できれば即座に売上・粗利ダッシュボードが作れます
在庫回転率・適正在庫・滞留在庫の分析

在庫数量のデータがありません。出荷実績だけでは「売れた数」は分かっても「余っている数」が分かりません。

必要なもの：日次の在庫スナップショット（品番×拠点×在庫数）
リードタイム・納期遵守率の分析

あるのは「売上日」のみで、受注日・要求納期・実出荷日がありません。「何日で届けられているか」が測れません。

必要なもの：受注日／指定納期／実出荷日
地域別・業態別・担当者別の分析

お客様コードはありますが、属性（地域・業態・規模・担当営業）がありません。「どのエリアが伸びているか」が出せません。

必要なもの：お客様マスタ（地域／業態／担当者）
返品・クレーム・誤出荷の分析

該当するデータがありません。品質管理系の指標は現状作れません。

必要なもの：返品／クレーム実績データ

② 期間が足りないためできないこと（＝予測系）

今回のデータは2026/5/1〜6/1の31日分のみです。予測・傾向分析は、この期間では統計的に成立しません。以下はすべて「データが貯まればできる」ものです。
需要予測（次月の出荷数を予測する）

季節変動を掴むには最低でも13か月（前年同月と比較するため）、実用精度なら24〜36か月が必要です。31日分では「先月比」すら出せません。

必要なもの：過去24か月以上の出荷実績（過去データを一括で連携いただければ、初日から可能になります）
前年同月比・前月比・成長率

比較対象の期間が存在しません。BIダッシュボードで最も使われる指標が、現状は表示できません。

必要なもの：過去13か月以上の実績
季節性の把握（繁忙期・閑散期の特定）

自動車部品は車検時期・タイヤ交換期・年度末などの季節性が想定されますが、1か月では検出できません。

必要なもの：過去24か月以上の実績
発注点・安全在庫の自動算出

需要のばらつきと調達リードタイムの両方が必要です。現状はどちらも算出できません。

必要なもの：過去実績（12か月以上）＋在庫データ＋仕入リードタイム
離脱・取引減少の予兆検知

「いつも買っているお客様の出荷が止まった」を検知するには、平常時のパターン学習が必要です。3〜6か月の運用で実用レベルに到達します（比較的早く実現できる領域です）。

必要なもの：運用開始後3〜6か月の蓄積 ／ 検知と通知はn8nで実装

一方で、今のデータのままでも「できる」こと

出荷実績の可視化一式

日別・お客様別・商品グループ別・メーカー別・曜日別。P1のダッシュボードがそのまま該当します。

品番ABC分析

上位50品番で出荷数の51.9%を占めるといった集中度分析（実測値）。重点管理品番の特定に使えます。

お客様別の取扱構成分析

どのお客様がどの商品グループを何品番扱っているか。提案の切り口になります。

業務負荷の平準化検討

曜日別の明細件数の偏り（実測で最大10倍超の差）。人員配置の検討材料になります。

出荷ゼロの傾向分析

定義が確定すれば、欠品率ダッシュボードとして即座に構築できます。

定型帳票の自動化

今Excelで作っている集計表を、n8nで毎朝自動生成・配信。金額がなくても実現できます。

実現可能性 早見表

やりたいこと今できる？必要なもの実現時期の目安担当層
出荷実績ダッシュボードできる—（現データで可）フェーズ1MB
Excel自動出力・配信できる—（現データで可）フェーズ1n8n
名称表示のダッシュボード条件付き各種マスタCSVフェーズ1御社
欠品率の管理条件付き出荷数0の定義確定フェーズ1御社
売上金額・粗利分析できない金額・原価項目の連携フェーズ1〜2御社
前年比・季節性できない過去13〜24か月の実績過去データ次第御社
在庫回転・滞留分析できない在庫スナップショットフェーズ2御社
納期遵守率できない受注日・納期・出荷日フェーズ2御社
需要予測・発注点算出できない24か月実績＋在庫＋LTフェーズ3PFS
取引減少の予兆検知できない運用3〜6か月の蓄積フェーズ3n8n
自然言語での質問（AI）条件付きMetabot（有料）または生成AI＋n8nフェーズ3PFS
過去データをお持ちであれば、予測系は大幅に前倒しできます。QlikViewが参照していた元データに過去数年分が残っていれば、それを分析DBに一括投入することで、運用開始と同時に前年比・季節性の分析が可能になります。次回、過去データの保有状況をご確認いただけますと幸いです。

段階導入の進め方（案）

「やりたいことを先に固めないと収拾がつかない」というご懸念に対し、小さく作って早く見せることで要件を固めていく進め方をご提案します。2027年の基幹刷新までの時間軸も考慮しています。

フェーズ0：検証（PoC）
  • Metabase・分析DB・n8nを検証環境に構築
  • 今回のサンプルデータを実際に投入
  • P6の確認事項をもとに指標定義を確定
  • 現場の方に実際に触っていただく
  • 基幹からの出力方式・文字コードの確認
ゴール：「自分たちで作れる」を体感いただき、要件を実物ベースで固める
フェーズ1：本番構築
  • 分析DBの本番構築・マスタ連携
  • n8nによる日次自動取込フローの構築
  • 出荷実績ダッシュボードの本番公開
  • 既存Excel帳票の自動生成・配信への置換
  • 操作研修（作る人／見る人で分けて実施）
ゴール：QlikViewの現行機能を代替し、日々の運用を回す
フェーズ2以降：拡張
  • 金額・在庫データの追加連携
  • 2027年基幹刷新への対応（取込層の改修）
  • 独自日報システム等の統合
  • 過去データ投入による前年比・季節性分析
  • 需要予測・予兆検知・生成AI活用の検討
ゴール：QlikViewではできなかった領域へ踏み出す

進め方の注意点

最初から全部作らないことをお勧めします。7/29に伺った「やりたいことが未整理」というご懸念に対しては、1つのダッシュボードを実データで作って触っていただくのが最短です。要件は議論より実物から出てきます。
指標の定義を先に決めます。P6の確認事項（特に出荷数0と重複行）は、作り始める前に決着させます。後から変えると全ダッシュボードの数字が変わります。
基幹刷新のスケジュールと重ねます。2027年の刷新で仕様が変わるため、取込層（n8n）を疎結合に設計しておくことが前提です。ここを最初から意識して作ります。
「作る人」を社内に育てます。ノーコードでも、最初は作り方の型が要ります。フェーズ1の研修で数名の方に型を持っていただくのが、属人化を再発させないコツです。

次回に向けてのお願い事項

#お願いしたいことこれがあると
1出荷数0（2,776件）の意味をご教示ください欠品率分析が可能に
2完全重複行（2,607件）の扱いをご判断ください件数指標が確定
3金額項目を出力できるかご確認ください売上・粗利分析が可能に
4過去データ（何年分あるか）をご確認ください前年比・季節性が前倒し
5各種マスタ（お客様／商品／区分名称）のCSV名称表示が可能に
6基幹からの出力方式・頻度・文字コード取込フローを設計可能に
7独自日報システムの連携方式（API/CSV/RPA）統合範囲が確定
8QlikViewで今どんな帳票を出しているか（画面キャプチャ等）移行対象が明確に
1〜4がそろえば、次回はより実務に近いダッシュボードをお見せできます。特に過去データの有無は、ご提案の幅が大きく変わる分岐点です。
本資料はあくまでも仮定に基づくご提案です。機能説明・運用フロー・段階導入の区切りは想定であり、実運用の設計はお客様との協議のうえ決定いたします。ダッシュボードの集計値はいただいたサンプルデータの実測値ですが、各コードの業務上の意味には弊社の推定が含まれます。また、Metabase・n8nの機能範囲は本資料作成時点の公開情報に基づきます。