ノーコードBI 選定・比較レポート（ドラフト）
2026/7/29 商談反映版

QlikView リプレイス ― ノーコードBIツール 選定・比較レポート
— "止まらない・ID課金なし・オンプレ" を満たす最善構成のご提案 —

トヨタモビリティパーツ株式会社様向け。QlikViewのサポート終了・高額な維持費・コード属人化という課題を、オープンソースBI（Metabase / Apache Superset）とn8n による自動データ連携基盤で解決する構成を、実現可能性の観点から整理しました。「パッケージだけでどこまでカバーできるか」「n8nを入れるとどこまで届くか」を明確にしています。

宛先 ／ トヨタモビリティパーツ株式会社 松永 巌 様
作成 ／ Peace Flat System
作成日 ／ 2026-07-17
更新日 ／ 2026-07-29（初回商談の内容を反映）
結論 現状と課題 選択肢の全体像 スコア評価 推奨アーキテクチャ 責任分界点 ＋サーバー要件 パッケージ単体 vs n8n 要件充足マトリクス ＋できる/できない ライセンス・費用 推奨と根拠 導入ステップ ＋内製化・伴走 想定Q&A ご確認事項

今回の初回商談（2026/7/29）を受けた更新点

前回（7/17）版からの差分。黄色の「7/29 商談反映」バッジが付いた箇所が、今回の商談を踏まえて追記・修正した内容です。

今回の2回目商談（2026/8/7）を受けた更新点

国米様・松永様との2回目商談を踏まえた追記です。Metabaseの実現性（エンジニア見解）と、ご関心の高かった自動化・内製化を中心に反映しています。
結論：一番良い構成

Metabase（ノーコードBI・ユーザー数無制限／人数課金なし）＋ n8n（データ連携・自動更新基盤）＋ 分析データ基盤（数千万件を高速集計）

Metabase／ ノーコードBI・ユーザー数無制限無償 ＋ n8n／ 夜間バッチ・F-Watch・RPA受け ＋ 分析DB／ QlikViewインメモリの代替
ID課金ゼロ

Metabase・Superset・n8n・DBはすべてオープンソース。セルフホストなら利用者が何名でも（ユーザー数無制限）ライセンス費は0円。QlikViewの維持費を大幅圧縮。

オンプレ完結

すべて自社サーバーにセルフホスト可能。財務・金額を含む数千万件のデータを外部に出さず社内で完結。第一希望のオンプレ要件に適合。

脱・属人化

QlikViewのコード記述（ロード/変換スクリプト）を、n8nの画面ワークフローとMetabaseのドラッグ&ドロップに置換。誰でも修正できる。

結論の要点：「BIツール1本で全部」は成立しません。QlikViewで属人化していたのは"画面"ではなく"データを取り込み・整形・更新する仕組み（スクリプト）"です。ここを担うのが n8n＋分析DB。BI表示＝Metabase（＋大規模用途でSuperset）、データ連携・自動更新＝n8n＋DB（弊社構築）、元データ＝新基幹/WMS（御社） と役割を分けるのが、ノーコード・低コスト・オンプレを同時に満たす最短ルートです。
1

現状と課題

なぜ QlikView からのリプレイスが必要か

現状：QlikView（サポート終了済み）
サポート終了済みで維持費（ランニングコスト）が高い
開発・修正にコード記述が必要で属人化（特定担当に依存）
後継 QLIK SENSE はさらに複雑化し、自社メンテが困難な懸念
2027年8月に基幹＋WMSを刷新予定 → 元データが変わり、いずれにせよ全面作り直しのタイミング
裏を返せば好機です。2027年8月に元データが全面刷新されるため、"作り直しは避けられない"のが前提。ならば「サポート切れ・高額・属人化」のQlikViewに戻さず、この機に低コスト・ノーコード・オンプレの構成へ移すのが最も合理的です。
ご要望（ヒアリング）
除外 Forguncy / JustDB / ギークプラス / Spotfire / Power BI 以外
オンプレ 自社サーバー運用が第一希望（参照のみならクラウド可）
ノーコード Excelの数式レベルで誰でも修正・メンテ可
権限 閲覧者と編集者をグループで明確に分離（御社の想定規模：閲覧200〜300名／編集10名前後）
大容量 仕入・在庫・売上など数千万件・金額データ含む
連携 毎朝6時RPA夜間バッチ＋F-Watch（フォルダ監視）＋2027新基幹/WMS
課金 ID数課金・従量課金を避け、同時接続/共有前提で低コスト
納期 2027年5月までに導入完了（検証・習熟期間を確保）
商談で確定したデータ前提 7/29 商談反映：新基幹への刷新に伴い、現行QlikViewが取り込んでいるテキスト／CSV／Excelは"中身の項目そのもの"が変わり、新しい項目定義は御社が新規に決定されます。したがって現行データはそのままの本番移行対象にはなりません（＝どのみち作り直しが前提）。現行データは操作習熟・PoC（お試し構築）用の暫定利用と位置づけ、本番のダッシュボードは新基幹の新しい項目仕様に合わせて設計します。この前提は、後述の導入ステップ（§10）にも反映しています。
2

選択肢の全体像

除外5製品以外の主なノーコードBIを役割で整理

本命：BI表示

Metabase

オープンソースBI（OSS版）
ドラッグ&ドロップ・SQL不要で非エンジニアが作成/修正可。閲覧/編集のグループ権限分離。ユーザー数は無制限で無償（公式："Free unlimited users"／人数課金なし）。Excel・CSV出力も単体で可能。世界6万社超が利用。
OSS版 ライセンス無料・ユーザー数無制限 公式
AGPLライセンス。行/列レベルセキュリティ等はPro/Enterprise（ID課金）だが、閲覧/編集分離はOSSで可。
併用：大規模

Apache Superset

Apache財団 OSS BI
数千万件×同時多数に強い。行レベルセキュリティ(RLS)・詳細RBACが無償版で標準。ClickHouse等と組み高速。やや技術寄り。
OSS版 ライセンス無料（自社サーバー） 公式
Apache 2.0ライセンス。大規模・厳密な権限が要る場合の主軸候補。
本命：連携基盤

n8n

OSS 自動化 / iPaaS
オンプレでセルフホスト可・ライセンス無料。夜間バッチ・F-Watch・RPA連携・フォーマット変換・リトライ/通知を画面で組む。QlikViewの"ロードスクリプト"の置換。
セルフホスト版 ライセンス無料 公式
Sustainable Use License（社内業務利用可）。実費はサーバ代のみ。

分析DB（PostgreSQL / ClickHouse）

OSS データベース
数千万件の"受け皿"。QlikViewのインメモリ相当を担う集計基盤。列指向のClickHouseなら大量集計が高速。BIはこのDBを参照。
OSS ライセンス無料（自社サーバー） 公式
データ量・応答速度の要件次第でPostgreSQL/ClickHouseを選定。

Redash

OSS BI（参考）
OSSで無償・オンプレ可だがSQL記述が前提で、"誰でもノーコード修正"の要件に合いにくい。QlikViewの属人化を繰り返す懸念。
OSS ライセンス無料 公式
ノーコード性でMetabaseに劣るため今回は非推奨（参考枠）。

Looker Studio 等

無償クラウドBI（参考）
無償だがクラウド前提でオンプレ不可。財務・金額データを外部に出せない今回の第一希望に反する。参照のみ用途の比較参考。
無償（クラウド） 公式
オンプレ要件を満たせないため今回は非推奨（参考枠）。
役割の整理：「BIで見せる＝Metabase／Superset」「大量データを高速に集計＝分析DB」「データを取り込み自動更新＝n8n」。この3つは役割が別で、1つの製品には収まりません。除外指定の5製品（Forguncy等）はすべて外し、OSSで固めることでID課金・オンプレ・低コストを同時に満たします。
3

BIツール スコア評価（◎○△×）

御社要件の観点で採点（◎3／○2／△1／×0点・満点27点）

製品 ノーコード
(誰でも修正)		 オンプレ
運用		 ID非依存
ライセンス		 大容量
数千万件		 権限分離
閲覧/編集		 外部連携
(受け側)		 コスト
(維持費)		 導入
実績		 保守
しやすさ		 総合 判定
Metabase ◎◎◎○○△◎◎◎ 89%
24/27		 最有力（BI表示）
Apache Superset ○◎◎◎◎△◎◎○ 85%
23/27		 有力（大規模）
Redash ×◎◎○△△◎○△ 63%
17/27		 SQL前提で不適
Looker Studio ◎×◎△△△◎◎○ 63%
17/27		 オンプレ不可
QlikView（現状） ×◎×◎○△×△× 52%
14/27		 サポート終了
「外部連携（受け側）」がどのBIも△なのは、BIツール単体では夜間バッチ・F-Watch・RPA・新基幹/WMSからの自動取り込みまで面倒を見ないためです。ここを埋めるのが次セクションの n8n＋分析DB。BI単体の"届かない部分"を補完します。
で、何を使えばいい？

単体最高点は Metabase（89%）。ただし最高点でも要件は100%埋まりません。

どのBIも「グラフ・ダッシュボードを作る」までは高得点ですが、①元データの自動取り込み（夜間バッチ・F-Watch・RPA） ②数千万件を高速に捌く受け皿 ③2027年 新基幹/WMSへの"受け側"追随 ④更新失敗時の監視・リトライで必ず点を落とします。この"届かない部分"を埋めるのが n8n＋分析DB（次セクション）です。

Metabase／ 単体スコア最高 ＋ n8n＋分析DB／ 届かない部分を補完 ＝ 要件をほぼ100%充足
4

推奨アーキテクチャ ― 4層に分けて役割分担

QlikViewが1本で抱えていた機能を、役割ごとに最適なOSSへ分解

① データソース層
（御社）
新基幹システム・WMS（2027/8〜）／ 現行DB ／ ハンディ端末 ／ RPA夜間バッチ

毎朝6時のRPA夜間バッチ、F-Watch（フォルダ監視）でPCへ上書きされるハンディデータ。ここは御社資産。

新基幹WMSRPA夜間バッチF-Watch
② データ連携層
（中核・弊社構築）
n8n（オンプレ / セルフホスト）

夜間バッチ・F-Watchの更新ファイルを検知して取り込み、形式変換・名寄せして分析DBへロード。失敗時は自動リトライ＋通知。2027年の新基幹/WMS切替時も"受け側"はn8nの設定変更で吸収し、BI画面は作り直さない。

フォルダ監視取込形式変換/名寄せリトライ/監視新基幹/WMS追随
③ 分析データ基盤層
（弊社構築）
分析DB（PostgreSQL / ClickHouse）＋ 集計テーブル

仕入・在庫・売上など数千万件を保持し、工程別・金額の集計を事前計算（マテビュー/集計テーブル）。QlikViewのインメモリ高速表示の代替。BIはここを参照するので"重くならない"。

数千万件集計テーブル高速応答オンプレ
④ BI表示層
（パッケージ）
Metabase（主）／ Apache Superset（大規模用途）

ドラッグ&ドロップでダッシュボード作成。閲覧者/編集者をグループで権限分離。ユーザー数は無制限で無償（人数課金なし）。SQL不要で誰でも修正でき、属人化を解消。

MetabaseSupersetユーザー数無制限ID課金なし
F-Watch/フォルダ監視の受け取り

ハンディ端末からPCへ上書きされたファイルをn8nが検知し、リアルタイムに分析DBへ反映。既存のF-Watch運用を活かす。

自動リトライ＆更新監視

夜間バッチ取込が失敗しても再実行し、担当へメール/Teamsで通知。「今朝データが更新されていない」を防ぐ。

新基幹/WMSへの"受け側"追随

2027年の刷新で元データが変わっても、変更を吸収するのはn8nの取込設定のみ。BIダッシュボードは作り直さずに済む。

オンプレ完結（データ非流出）

BI・n8n・DBすべて社内サーバーにセルフホスト。財務・金額を含む数千万件を外部SaaSに預けない。

Metabase と Superset の使い分け：非エンジニアの編集担当が"誰でも触れる"ことを最優先するなら Metabase が本命。数千万件×同時多数のさらに厳密な行レベル権限（部門別に見える範囲を絞る等）が必要になったら Superset を併用/移行。両者は同じ分析DBを共有できるため、Metabaseで開始し、必要に応じてSupersetを足す段階導入が可能です。
5

責任分界点 ― どこまでがパッケージで、どこからが弊社か

「何にお金を払うのか」が一目で分かる切り分け

① パッケージ領域Metabase / Superset（OSS・無償）
グラフ・ダッシュボード作成
ドラッグ&ドロップのノーコード編集
閲覧/編集のグループ権限分離
ユーザー数無制限（ID課金なし）
セルフホスト（オンプレ稼働）
ライセンス費 0円（OSS）
参照
弊社のお見積り対象
② 弊社 構築領域n8n＋分析DB（デモモックの範囲）
夜間バッチ・F-Watch の取込ワークフロー
形式変換・名寄せ・項目マッピング
分析DBの設計（数千万件・集計テーブル）
2027 新基幹/WMS への受け側追随
更新の監視・自動リトライ・通知
初期ダッシュボード構築・権限設計
初期構築費 ＋ 月額保守費
元データ
③ 御社領域既存資産・意思決定
新基幹システム／WMS（元データ提供）
RPA夜間バッチ・F-Watch（既存運用）
閲覧/編集ユーザーの運用・棚卸し
オンプレサーバーの用意
既存資産の活用（新規開発なし）
ここが一番大事です：QlikViewでコード記述され属人化していたのは、まさに ②の部分（ロード/変換スクリプト）です。BIパッケージ（①）を入れても②は付いてきません。弊社が担うのは②だけで、①はOSS（無償）、③は御社のまま — この3分割が今回のご提案の骨格です。②を"コード"から"n8nの画面ワークフロー"に置き換えることが、脱・属人化の核心です。
工程担当実現手段費用の出方デモモック
グラフ・ダッシュボード作成パッケージMetabase / Superset 標準機能0円（OSS）◎ あり
ノーコード編集（SQL不要）パッケージMetabase クエリビルダー0円（OSS）◎ あり
閲覧/編集の権限分離パッケージMetabase グループ／Superset RBAC0円（OSS）◎ あり
夜間バッチ・F-Watch 取込弊社構築n8n ワークフロー初期構築費◎ あり
形式変換・名寄せ・項目マッピング弊社構築n8n＋変換ルール初期構築費◎ あり
分析DB設計（数千万件・集計）弊社構築PostgreSQL / ClickHouse 設計初期構築費◎ あり
2027 新基幹/WMS 受け側追随弊社構築n8n 取込設定の差し替え初期構築費/保守◎ あり
更新監視・自動リトライ・通知弊社構築n8n エラーハンドリング＋監視月額保守費◎ あり
新基幹システム／WMS 本体御社既存（2027刷新・弊社対象外）—対象外
オンプレサーバーの用意・運用御社社内インフラ—対象外
デモモックは 「弊社構築」の行＋BI表示画面のイメージ を画面化しています。 → 構築範囲デモを開く
いただいたサンプル（マスタ4種＋実績5,000行）を実際に読み込んだデモもご用意しました（Metabaseを契約した場合の画面／マスタと実績のリレーション／ドリルダウン・集計／分析DB・n8nの構成）。 → 実データデモを開く

オンプレ・サーバー要件（「サーバーは必要か」へのご回答） エンジニア回答 反映

ご質問いただいた「サーバーの必要性」について、エンジニア確認のうえご回答します

物理的にサーバーは必要か → 必須ではありません

「オンプレ」の要件はデータを社外に出さないことであり、社内ネットワーク内で動作すれば形態は問いません。

  • 物理サーバー1台
  • 既存の仮想基盤（VMware / Hyper-V 等）上の仮想サーバー1台
すでに社内に仮想基盤をお持ちであれば、そこに1台ご用意いただくのが最も早く、追加調達も不要です。
必要なスペック

BIツール・分析DB・取込バッチを1台に集約する想定です。

段階CPUメモリストレージ
検証（PoC）4コア16GBSSD 256GB
本番運用8〜16コア32〜64GBSSD・NVMe 1TB以上

OS：Linux（Ubuntu または RHEL系）を推奨。数千万件を扱うため特にメモリが処理速度に効きます。ディスクは生データ・整形済みデータ・集計データの3層＋過去データ・バックアップを見込んだ容量です。

PCをサーバーとして使えるか → 用途によって使い分け
検証（PoC）段階：問題ありません（むしろ推奨）

サーバー調達を待たずに着手できるため、手元のPCで構成の確認まで進められます。

本番運用：お勧めしません（性能ではなく運用面の理由）
  • ・24時間稼働の前提がなく、電源が落ちると翌朝データが更新されない
  • ・ディスクの冗長化（RAID）がなく、故障するとデータを失う
  • ・無停電電源・バックアップ・遠隔管理の仕組みがない
  • ・固定IPの付与やサーバー用ネットワークへの配置が難しい
200〜300名の方が日常的に利用される基盤となるため、本番はサーバー（物理または仮想）でのご用意を推奨します。PoCはPCで先行し、本番前にサーバーへ移す進め方が現実的です。
6

BIパッケージ単体 vs n8n併用 ― 到達点（天井）の違い

ツール単体では「ここまで」。n8n＋分析DBで天井を超える

BIパッケージ単体（n8nなし）
① グラフ・ダッシュボード作成
ドラッグ&ドロップで可視化できる
② ノーコード編集・権限分離
SQL不要・閲覧/編集の分離が可能
③ 用意済みDBへ接続して参照
既に整ったデータがあれば表示できる
ここがBIツール単体の天井 ― これ以上は自動で繋がらない
④ 夜間バッチ・F-Watch からの自動取込
フォルダ監視・上書きファイルの取り込みは製品標準にない
⑤ 数千万件を高速表示する集計基盤
生データ直参照では重い。集計テーブル設計が必要
⑥ 2027 新基幹/WMS への追随
元データ変更の吸収は自前で作り込む必要
⑦ 更新失敗の監視・自動リトライ・通知
「今朝データが更新されていない」に気づけない
n8n＋分析DB を足した弊社構成
①〜③ はそのまま活用
OSS BIの強み（無償・ノーコード・権限）は維持
④ 夜間バッチ・F-Watch を自動取込
n8nがフォルダ監視・上書き検知して分析DBへ反映
⑤ 数千万件も高速表示
分析DB＋集計テーブルでQlikViewインメモリ相当を再現
⑥ 新基幹/WMS 切替を"受け側"で吸収
n8nの取込設定変更のみ。BI画面は作り直さない
⑦ 更新を監視・自動リトライ・通知
失敗しても再実行し、担当へ即アラート
差の本質：BIツールは「あるデータを見せる」ところまで。その手前の"取り込む・貯める・自動更新する・止まらない"がn8n＋分析DBの担当です。ここがQlikViewでコード属人化していた部分で、弊社の構築価値の中心です。
7

ご要望 × 充足マトリクス

◎=最適 ○=可 △=条件付き ×=不可

ご要望 QlikView
現状		 Metabase＋n8n＋DB
推奨		 Superset＋n8n＋DB
大規模構成		 BI単体
（n8nなし）
除外5製品を回避○◎◎◎
オンプレ運用（自社サーバー）◎◎ 全て自ホスト◎◎
ノーコード（誰でも修正）× コード必須◎ D&D○ 一部技術◎
ID非依存ライセンス× 同時接続課金◎ 無制限0円◎ 無制限0円◎
閲覧/編集の権限分離（人数無制限）○◎ グループ◎ RBAC/RLS○
数千万件・金額データ◎ インメモリ◎ 分析DB◎ 列指向DB△ DB次第
夜間バッチ・F-Watch 連携△ スクリプト◎ n8n◎ n8n×
2027 新基幹/WMS 追随× 全面作り直し◎ 受け側のみ◎×
更新監視・自動リトライ×◎ n8n◎ n8n×
維持費（ランニングコスト）× 高額◎ OSSで最安◎ OSSで最安◎
脱・属人化×◎ 画面WF○△
QlikViewは「大容量・インメモリ表示」は強いものの、サポート終了・同時接続課金・コード属人化・2027刷新での全面作り直しという致命点があります。推奨構成は全要件でバランスが取れ、特にID課金回避・脱属人化・新基幹追随で明確に優位です。

Metabase で「できること」「できないこと」 7/29 商談反映・新設

商談でご質問の多かった点を、Metabase公式ドキュメント（2026年7月時点）で裏取りして正確に整理しました。「できない／有償」も正直に明記します。

Metabase 無償版（OSS）でできること SQL不要・0円
グラフ・ダッシュボード・ドリルダウン・フィルタ
ドラッグ&ドロップで作成。SQLは書かなくてよい
計算式（Custom Expression）をクリックで作成
集計＝Sum / CountIf / SumIf / Distinct / Median / Percentile 等、文字列＝concat / substring / replace / regexExtract 等、日付＝datetimeDiff / datetimeAdd 等、条件分岐＝case / coalesce / if。Excelの関数感覚で組める
テーブル同士のリレーション（JOIN・モデル定義）
「データ同士のリレーション」も画面操作で可能。外部キー・モデルで関連付け
データ型・意味付けの定義（日付／文字列／カテゴリ／通貨）
「これは日付、これは文字列」の定義もここで設定
Excel(.xlsx)・CSV への出力
Metabase単体で出力可能（1シート約104万行まで）。定型フォーマットや自動配布はn8nで整える
ダッシュボードの定期メール／Slack配信・しきい値アラート
「この数字を割ったら通知」もメール/Slack設定後に無償で可能
ユーザー数は無制限で無料登録（人数課金・座席課金なし）
公式：Open Source は "Free unlimited users"。閲覧/編集はグループで権限分離。何名でもライセンス費0円（御社想定：閲覧約300名/編集約10名は"上限"ではなく想定規模）
できないこと／有償・別手段が必要 正直な線引き
部門ごとに"見える行"を絞る（行／列レベル制御）
MetabaseではPro/Enterprise（有償・ID課金）。無償で行うなら Apache Superset（行レベルセキュリティが無償標準）を併用
Excelそのもののような多段の表計算
BIは表計算ソフトではない。関数を超える複雑な加工は SQL（中央管理＝属人化しない） か n8n＋AI で実施
元データの自動取り込み（夜間バッチ・F-Watch・RPA・新基幹連携）
Metabase単体の機能ではない → n8n が担当（本提案の中核）
ノーコードのAI自然言語質問（Metabot）
自社サーバー版は自前のLLM APIキー持ち込みが前提（キー不要の管理型AIはクラウド有償）。→ 御社の既存AIを使えばランニングコスト増なし
出力からのロゴ非表示・詳細な利用監査 等の一部管理機能
Pro/Enterprise（有償）。運用の必須要件でなければ無償版で十分
商談での「関数はExcelのSUM等まで使えるのか／AIで作るのか」へのより正確な回答：Metabaseはそれ自体に計算式エディタ（上記の関数群）を持ち、SQLもAIもなしで大半の集計・加工が組めます。AI（生成AI）は"必須"ではなく、Excel級の複雑な処理や自然言語での指示をしたいときの補助という位置づけです。AIを使う場合も御社の既存AIを流用できるため、追加のランニングコストは基本的に発生しません。
出典：Metabase 公式ドキュメント（docs/latest：計算式一覧／エクスポート／権限〈行・列セキュリティ〉／サブスクリプション／Metabot／料金ページ）を 2026年7月に確認。OSS製品の仕様・ライセンスは変更され得るため、契約前に最新条件を再確認します。
8

ライセンス・費用の考え方

ソフトのライセンス費と、弊社の構築・保守費を分けて可視化

金額の根拠： 公式 ベンダー公式のライセンス条件で確認済み 参考値 一般的な相場感・構成依存 申告 御社ヒアリングでの申告
推奨Metabase＋n8n＋DB
（ソフトライセンス）
0円/ID
Superset＋n8n＋DB
（ソフトライセンス）
0円/ID
参考Metabase Pro
（行/列権限を使う場合）
ID課金参考
現状QlikView
（維持費）
高額申告
バーはランニング（ソフトライセンス）の相対イメージ。推奨構成のソフトライセンスは0円（OSS・ユーザー数無制限）で、実費は自社サーバー費用のみ。QlikViewの維持費は御社申告により「高額」。
構成ソフトライセンス根拠サーバー弊社 初期構築弊社 月額保守ID課金
推奨 Metabase＋n8n＋分析DB0円（OSS） 公式自社サーバー別途見積別途見積なし
Superset＋n8n＋分析DB0円（OSS） 公式自社サーバー別途見積別途見積なし
Metabase Pro（行/列権限を使う場合）ユーザー課金 参考自社/クラウド別途見積別途見積あり
現状 QlikView高額（維持費） 申告自社サーバー—内製（属人化）同時接続
※1 Metabase・Apache Superset・n8n・PostgreSQL/ClickHouse はいずれもオープンソースで、セルフホストならユーザー数無制限・ライセンス費0円（Metabase公式の Open Source プランは "Free unlimited users"）。実費は自社サーバー費用のみで、利用者が何名でもID課金は一切発生しません（ご要望の「ID非依存」に完全適合）。「閲覧300名/編集10名」は御社の想定規模であり、Metabaseの上限ではありません。
※2 Metabaseで行/列レベルの厳密なデータ制御（部門ごとに見える行を絞る等）が必要な場合、その機能はPro/Enterprise（ID課金）です。ただし閲覧/編集のグループ分離はOSSで可能。厳密な行レベル制御が要件なら、その用途は無償のApache Supersetで代替できます。
※3 弊社の初期構築費・月額保守費は、連携対象・データ量・ダッシュボード本数・保守範囲に応じて別途お見積りします。本レポートでは具体金額の明示は控え、初回お打ち合わせ後に正式見積を提出いたします。
9

推奨と根拠

本命と次点、どちらを選ぶかの指針

本命
Metabase ＋ n8n ＋ 分析DB

「誰でもノーコードで修正」を最優先する今回に最適。編集担当が研修最小で扱え、閲覧はユーザー数無制限で無償（御社想定：閲覧約300名/編集約10名）。n8nで夜間バッチ・F-Watch・新基幹連携を自動化し、脱・属人化と低コストを両立。

ノーコード性が最高・非エンジニア向き
ID課金ゼロ・オンプレ完結・データ非流出
2027新基幹はn8nの受け側で吸収し作り直さない
次点 / 併用
Apache Superset ＋ n8n ＋ 分析DB

「数千万件×同時多数」「部門別に見える行を厳密に絞る（RLS）」を無償で強化したい場合。ClickHouse等と組めば大規模集計が高速。やや技術寄りだが権限は最も細かい。

大規模・行レベル権限が無償で標準
Metabaseと同じ分析DBを共有でき段階移行可
編集操作はMetabaseよりやや専門的
選び方の一言：「とにかく誰でも触れて・安く・オンプレで」→ 本命 Metabase。「規模と厳密な権限を無償で極めたい」→ 次点 Superset。どちらも n8n＋分析DB でデータ連携・自動更新を担う点は共通で、まずMetabaseで開始し、必要に応じてSupersetを足す段階導入をおすすめします。
10

導入ステップ ― 2027年5月 稼働に向けて

2027年8月の新基幹/WMS刷新に、検証・習熟期間を確保して間に合わせる

STEP 1
選定・要件定義・PoC

現行QlikViewの帳票棚卸し、データ量/応答速度の検証、Metabase/Supersetのどちらを主軸にするか小規模PoCで確定。

STEP 2
データ基盤・連携構築

分析DB設計＋n8nで取込を実装。現行データは操作習熟・PoC用に先行構築し、本番の項目は新基幹の新仕様で設計（商談確定の前提）。

STEP 3
新基幹/WMS 受け側 切替

2027年8月刷新に合わせ、n8nの取込設定を新データ形式へ差し替え。BIダッシュボードは維持。

STEP 4
内製化・運用保守

編集担当（御社想定 約10名）へノーコード操作研修。監視・リトライは弊社月額保守、日常のダッシュボード修正は御社内製へ。

まずのスタート（2回目商談で確認した流れ） 8/7 商談反映：① 御社がMetabaseをご契約（オープンソース版・セルフホスト。Metabaseと弊社は無関係で御社が直接契約）→ ② 秘密保持契約（NDA）を締結 → ③ 実データ・実画面をエンジニアと相談（本格稼働前の相談ベース）→ ④ PoCで応答速度・行レベル権限を実測 → ⑤ 本契約・構築・月額伴走開始。本格PoC（エンジニア稼働）は本契約後ですが、その前段はNDAベースで柔軟に対応します。
想定スケジュール（一例・実際は初回お打ち合わせで確定）
2026 Q4
選定・PoC

主軸BI確定

2027 Q1
基盤・連携構築

現行DBで先行

〜2027/5
導入完了・習熟

現行データで操作習熟

2027/8
新基幹/WMS刷新

受け側切替のみ

2027/8〜
本番・内製運用

保守伴走

ポイント 7/29 商談反映：現行データは項目が刷新されるため本番移行の対象ではなく、"操作に慣れる・PoCで規模を測る"ための土台として先行活用します。「まず現行データでMetabase／n8nの操作を習熟」→「新基幹稼働時はn8nの受け側と、新項目に合わせたダッシュボード定義を切替」。BIツールとデータ基盤の骨格（分析DB・権限・監視）は使い回せるため、2027年5月の導入完了希望に、元データ刷新リスクを切り離して間に合わせます。

内製化・伴走・勉強会 8/7 商談反映・新設

「作って終わり」にしない。御社が自分たちで自動化を作れる状態まで、月額伴走で支援します

弊社の方針は「システムを作って納品して終わり」にしないことです。大企業様ほど内製化のご要望が強く、1人の社員が10〜20個のワークフローを自分で作れるようになれば、自動化は社内で量産できます。n8nは1契約でワークフロー無制限で作成できます（セルフホスト版）。
月額伴走
コンサル型の伴走

要件定義・方向性決定・定例お打ち合わせ。BIだけでなく他業務の自動化相談も範囲内。軽微な自動化はその場で、大規模なものは別途エンジニア対応。

勉強会
全社員・部門向け

n8n・AI活用の勉強会や、Metabaseの「作る人／見る人」向け操作研修を伴走費の中で開催。

合宿型WS
1日集中ワークショップ

経営者・営業部長・DX推進など30名規模の実績。未経験の方でもその日のうちに複数の自動化を作成できる状態に。

ゴール
自走できる組織へ

社員が自分で自動化を量産し、属人化せず資産が増える状態。弊社は難所の支援と品質担保に回ります（末永い伴走）。

自動化（AIセールスくん／n8n）も同時並行で

BIの集計を各営業所へ自動配信する、商談・メール・議事録を自動化するなど、n8nを使った自動化の実例集を別デモにまとめています。BI導入と同時に、御社に合うものから伴走で構築できます。

AIセールスくん（自動化デモ）を見る
IT統制・セキュリティに配慮した進め方
  • Metabase・n8nともセルフホスト（オンプレ）で、データを社外に出さない
  • 基幹（財務・売上・売掛）に直結せずCSV連携で統制ルール内に収める
  • 実行ログが残り、監査で「何を自動化しているか」を提示できる
  • 実データ検証の前に秘密保持契約（NDA）を締結
伴走の具体的な内容・区切りは、御社のご要望に合わせて調整します。金額・工数は本資料には記載せず、要件が固まった段階で別途お見積りいたします。
11

よくあるご質問（初回商談 想定Q&A）

ノーコードBI・OSS構成に対して、実務・法務・情シスの観点で想定される疑問に正直にお答えします

Q1 オープンソースは無償なのは分かるが、開発が止まったり、サポートが切れたりするリスクは？継続性
いずれも背後に運営組織があり、活発に開発が継続している製品です。
  • Metabase … 米Metabase社が商用版で収益化しつつ開発。世界6万社超が利用
  • Apache Superset … Apache Software Foundation の正式プロジェクト（Airbnb発）。多数の大企業が採用
  • n8n … 独n8n GmbH が大型資金調達済みで開発を主導
加えて弊社が保守でバージョン追随・セキュリティパッチ適用を担うため、QlikViewのように「サポート終了で立ち往生」する事態を構造的に避けられます。万一将来別ツールへ替える場合も、データは分析DB（標準SQL）に残るため表示層だけ差し替え可能で、乗り換えコストは最小です。
正直に言うと：どのソフトも永久保証はありません。だからこそ「表示層は無償で替えが利く／データは標準DBに残す」設計にし、1製品に運命を預けないことが最大のリスク対策です。
Q2 AGPL等のライセンス条項が社内利用で問題にならないか、法務が気にしています。法務
社内での利用（自社サーバーでそのまま使う）であれば、実務上の制約はありません。
  • Metabase（AGPL）… ソースを改変して外部に配布しない限り開示義務は発生しません。社内利用は問題なし
  • n8n（Sustainable Use License／fair-code）… 社内業務での利用は無償で許諾されています
  • Apache Superset / PostgreSQL / ClickHouse … Apache 2.0 等の寛容ライセンスで制約は軽微
契約前に、その時点の最新ライセンス条文を御社法務と一緒に再確認する前提で進めます。ライセンスは変更され得るため、ここは必ずダブルチェックします。
Q3 今あるQlikViewの帳票は全部再現できるのか？移行にどれくらいかかる？移行
グラフ・表・KPI・ドリルダウン・フィルタといった一般的なBI表現はMetabase/Supersetで再現可能です。進め方は、まず現行帳票を棚卸しし、利用頻度の高いものから移行。QlikView独自スクリプトに依存していたデータ加工は、n8n＋分析DB側へ作り替えます。工数は帳票本数とデータ変換の複雑さで決まるため、PoC（お試し構築）で実データを使い規模を確定してから正式見積を提出します。
稀にQlikView特有の高度な連想検索表現は、そのままの形では再現しない場合があります。棚卸し時に「そっくり再現／代替表現／統廃合」を1本ずつ判定します。
Q4 "QlikViewの属人化"が、今度は"御社（PFS）依存"に置き換わるだけでは？ロックイン
そうならないよう設計します。
  • 採用技術が全て標準的なOSS（SQL・Metabase・n8n）で、QlikViewのような独自言語がない → 他ベンダーでも引き継げる
  • 編集担当への内製化研修（ノーコード操作＋n8nの読み解き）で、日常修正を御社内で完結
  • 構成ドキュメント・データ定義書を整備し、"その人・その会社でないと無理"を作らない
むしろ狙いは逆で、「特定製品・特定担当に縛られない状態」に持っていくことが今回のリプレイスの目的です。弊社は"抜けても回る"体制づくりまで含めて伴走します。
Q5 従業員9,000名規模。ユーザー登録数に上限は？想定300名の同時アクセスでも性能は大丈夫か？性能
大丈夫な構成にできます。まずユーザーの登録数に上限はありません（Metabase Open Source は "Free unlimited users"／人数課金なし）。9,000名全員に配っても登録費用は0円です。同時アクセスの性能は、BIが生データを毎回集計しないことがカギです。
  • BIは事前集計テーブルを参照するため、同時アクセスに強い
  • 目安として1CPUコア+1GBメモリで約20同時接続。数百名の同時閲覧はサーバー増強で対応（公式スケーリング指針）
  • 大規模なら Apache Superset ＋ 列指向DB（ClickHouse）＋ キャッシュ（Redis） で数千万件×同時多数に対応
  • 閲覧のピーク時間帯・帳票の重さに合わせてサーバーをサイジング
性能は「データ量×帳票の作り×同時数×サーバー」で決まります。PoCで現行の重い帳票を実測し、本番サーバー要件を数字で提示します（憶測で"速い"とは言いません）。
Q6 セキュリティ・監査対応（アクセスログ、データ持ち出し）はどうなる？セキュリティ
BI・n8n・分析DBを全て自社サーバーにセルフホストし、財務・金額を含むデータを外部に出しません。アクセスログ・操作監査はMetabase/Supersetの機能とDB側の記録で取得でき、「誰がいつ何を見たか」を残せます。閲覧/編集の権限分離、部門別の閲覧制限（Superset の行レベルセキュリティ）も可能です。弊社はISMS（ISO/IEC 27001）認証を取得しており、閉鎖環境での構築・運用を得意としています。
Q7 障害時（夜間バッチ失敗など）の責任分担・保守体制は？保守
「半分お任せ」を標準とします。
  • 弊社 … 更新監視・障害の一次対応・自動リトライ設計・バージョン追随・ルール修正（月額保守）
  • 御社 … 例外的な業務判断・社内ユーザー運用
アラートは御社担当と弊社保守窓口の両方に飛び、まず弊社が動きます。「エラーに担当が気づいて手で直す」QlikView時代の属人的な運用をなくします。範囲は完全委託〜一部委託まで調整可能です。
Q8 本格導入の前に、無償でお試し（PoC）はできる？PoC
できます。OSSなので試験環境をライセンス費0円で構築し、現行帳票の一部を実データで再現して、性能・操作性・ノーコード編集のしやすさを確かめてから本導入を判断できます。「触ってから決める」進め方でリスクを抑えられます。2027年8月の刷新に向け、まず現行データでPoC→先行稼働、という段取りを想定しています。
Q9 Power BIを社内で1名が有料契約している。共存や使い分けはできる？共存
今回は除外指定のため提案の主軸には含めませんが、Power BIは同じ分析DBを参照して共存が可能です。例えば「全社の標準閲覧＝無償のMetabase（何名でも0円・ユーザー数無制限）」「特定部署の作り込み＝既存のPower BI」といった使い分けもできます。分析DBを"共通の一次データ"として持つため、どのBIから見ても数字が一致する状態を保てます。
Q10 ドリルダウンした結果をExcelに出したい。Excelの関数（SUM等）はどこまで使える？7/29反映
Excel(.xlsx)・CSVへの出力はMetabase単体で可能です（1シート約104万行まで）。関数は、Metabase自身の計算式エディタで、集計（Sum／CountIf／SumIf／Distinct／Median 等）・文字列（concat／substring／replace 等）・日付（datetimeDiff／datetimeAdd 等）・条件分岐（case／if／coalesce）をSQLもAIもなしでクリック操作で組めます。
  • 「作った後にまた人がピボット貼り付け…」という手作業は、n8nで定型フォーマット化・自動配布すればなくせます
  • Excelそのもののような多段の表計算はBIの役割外。その場合はSQL（中央管理で属人化しない）かn8n＋AIで処理します
正直に言うと：「Excelの全関数がそのまま動く」ではありません。ただ実務で使う集計・加工の大半はMetabaseの計算式で足り、足りない部分だけSQL/n8nで補う、という切り分けです。→ 詳細は 「できること・できないこと」。
Q11 元データ同士のリレーション（結合）や、日付／文字列などの型定義はできる？7/29反映
できます。テーブル同士のJOIN（結合）・モデル定義・外部キーによる関連付けはMetabaseの画面操作（無償・SQL不要）で行えます。「これは日付、これは文字列、これは通貨」といったデータ型・意味付けの定義も標準機能です。大量データを事前に整えるリレーション・集計は分析DB側で持ち、Metabaseはそれを参照する構成にすると、数千万件でも軽快に扱えます。
複雑なリレーションはBI画面で無理に作り込まず、分析DB＋n8n側で"整った状態"を用意してからBIで見せるのが、速度・保守の両面で有利です。
Q12 AIは機能として最初から入っている？自社の独自AI（Copilot等）は使える？費用は？7/29反映
AIは"標準で同梱"ではなく、御社が既にお使いのAIを流用する形が基本です。n8nは司令塔として、御社の自社チャットAI／Microsoft Copilot／Google 等と各システムをつなぎます。
  • 既存AIをそのまま使えば、AI分のランニングコストは増えません
  • 別途Claude等を新規契約する場合のみ、その分の費用が発生します
  • Metabase内蔵のAI（Metabot）を使う場合、自社サーバー版は自前のLLM APIキー持ち込みが前提です
まずは過去データ・判断基準をAIに学習させ、人の「振り分けの勘」を再現していきます。最終判断は人が行い、AIは下書き・候補出しに徹する運用が安全です。
Q13 今後PDFで保存される帳票（手書き・O/0やI/1の混在）を、そのままデータ化できる？部門ごと（物流・営業）の連携は？7/29反映
OCR（PDF・手書き帳票の読み取り）＋品番マスタとの突合で対応します。O と 0、I と 1 の紛らわしい箇所はマスタと突き合わせて実在品番へ補正候補を提示し、信頼度の低い箇所は人が最終チェックして格納。7年分のPDFを"検索できる資産"に変えられます。部門連携は、営業の独自日報システムともAPI／CSV／画面操作（RPA）でつなぎ、物流・営業・経営で同じ分析DBを共有します。
  • 精度はOCRエンジンの選定次第。要件に合わせて選び、実データで精度を確認してから確定します
  • 「何をやりたいか」を先に絞り、効果の大きい所から1本ずつ追加する進め方をおすすめします
OCRは「100%自動」ではなく「候補を選ぶ・直すだけ」に短縮する位置づけ。誤読リスクがある以上、最終確認は人の目で残します。デモは 帳票OCRページ でご覧いただけます。
12

初回お打ち合わせでのご確認事項

正式見積・最終構成の確定に必要な確認ポイント

現行QlikViewの帳票・ダッシュボードは何本か（初期構築規模の算定に直結）
データ量と応答速度の要件（数千万件の"何を""どの粒度で"／PostgreSQLで足りるかClickHouseが要るか）
権限分離の細かさ（閲覧/編集の2区分で足りるか／部門ごとに見える行を絞る必要があるか＝Superset判断）
F-Watch・RPA夜間バッチの出力仕様（ファイル形式・置き場所・更新タイミング）
2027 新基幹/WMSの製品・データ提供方式（CSV/API/DB直参照のいずれか）
オンプレサーバーのスペック・OS（Docker利用可否・社内ネットワーク要件）
保守範囲の希望（監視・障害対応をどこまで弊社に委ねるか）
本レポートはあくまでも現時点の仮定に基づくドラフトです。製品の機能範囲・ライセンス条件・運用方法は、上記の確認結果を踏まえ初回お打ち合わせ以降に精査し、最終的な構成・見積は御社との協議のうえ確定いたします。OSS製品の仕様やライセンスは変更される可能性があるため、契約前に最新条件を再確認します。
提案資料（ドラフト）｜ Peace Flat System