QlikView リプレイスノーコードBI 選定・比較レポート

結論：一番良い構成

Metabase（ノーコードBI・閲覧300名/編集10名）＋ n8n（データ連携・自動更新基盤）＋分析データ基盤（数千万件を高速集計）

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

ID課金ゼロ

Metabase・Superset・n8n・DBはすべてオープンソース。セルフホストなら閲覧300名でもライセンス費は0円。QlikViewの維持費を大幅圧縮。

オンプレ完結

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

脱・属人化

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

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

現状と課題

なぜ 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月までに導入完了（検証・習熟期間を確保）

選択肢の全体像

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

本命：BI表示

Metabase

オープンソースBI（OSS版）

ドラッグ&ドロップ・SQL不要で非エンジニアが作成/修正可。閲覧/編集のグループ権限分離。ユーザー数無制限で無償。世界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課金・オンプレ・低コストを同時に満たします。

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層に分けて役割分担

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（大規模用途）

ドラッグ&ドロップでダッシュボード作成。閲覧300名/編集10名を権限分離。ユーザー数無制限で無償。SQL不要で誰でも修正でき、属人化を解消。

MetabaseSuperset閲覧300/編集10ID課金なし

F-Watch/フォルダ監視の受け取り

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

自動リトライ＆更新監視

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

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

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

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

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

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

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

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

① パッケージ領域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 RBAC	0円（OSS）	◎ あり
夜間バッチ・F-Watch 取込	弊社構築	n8n ワークフロー	初期構築費	◎ あり
形式変換・名寄せ・項目マッピング	弊社構築	n8n＋変換ルール	初期構築費	◎ あり
分析DB設計（数千万件・集計）	弊社構築	PostgreSQL / ClickHouse 設計	初期構築費	◎ あり
2027 新基幹/WMS 受け側追随	弊社構築	n8n 取込設定の差し替え	初期構築費/保守	◎ あり
更新監視・自動リトライ・通知	弊社構築	n8n エラーハンドリング＋監視	月額保守費	◎ あり
新基幹システム／WMS 本体	御社	既存（2027刷新・弊社対象外）	—	対象外
オンプレサーバーの用意・運用	御社	社内インフラ	—	対象外

デモモックは 「弊社構築」の行＋BI表示画面のイメージ を画面化しています。 → 構築範囲デモを開く

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でコード属人化していた部分で、弊社の構築価値の中心です。

ご要望 × 充足マトリクス

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

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

QlikViewは「大容量・インメモリ表示」は強いものの、サポート終了・同時接続課金・コード属人化・2027刷新での全面作り直しという致命点があります。推奨構成は全要件でバランスが取れ、特にID課金回避・脱属人化・新基幹追随で明確に優位です。

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

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

金額の根拠： 公式ベンダー公式のライセンス条件で確認済み参考値一般的な相場感・構成依存申告御社ヒアリングでの申告

推奨Metabase＋n8n＋DB
（ソフトライセンス）

0円/ID

Superset＋n8n＋DB
（ソフトライセンス）

0円/ID

参考Metabase Pro
（行/列権限を使う場合）

ID課金参考

現状QlikView
（維持費）

高額申告

バーはランニング（ソフトライセンス）の相対イメージ。推奨構成のソフトライセンスは0円（OSS・ユーザー数無制限）で、実費は自社サーバー費用のみ。QlikViewの維持費は御社申告により「高額」。

構成	ソフトライセンス	根拠	サーバー	弊社初期構築	弊社月額保守	ID課金
推奨 Metabase＋n8n＋分析DB	0円（OSS）	公式	自社サーバー	別途見積	別途見積	なし
Superset＋n8n＋分析DB	0円（OSS）	公式	自社サーバー	別途見積	別途見積	なし
Metabase Pro（行/列権限を使う場合）	ユーザー課金	参考	自社/クラウド	別途見積	別途見積	あり
現状 QlikView	高額（維持費）	申告	自社サーバー	—	内製（属人化）	同時接続

※1 Metabase・Apache Superset・n8n・PostgreSQL/ClickHouse はいずれもオープンソースで、セルフホストならユーザー数無制限・ライセンス費0円。実費は自社サーバー費用のみで、閲覧300名でもID課金は一切発生しません（ご要望の「ID非依存」に完全適合）。
※2 Metabaseで行/列レベルの厳密なデータ制御（部門ごとに見える行を絞る等）が必要な場合、その機能はPro/Enterprise（ID課金）です。ただし閲覧/編集のグループ分離はOSSで可能。厳密な行レベル制御が要件なら、その用途は無償のApache Supersetで代替できます。
※3 弊社の初期構築費・月額保守費は、連携対象・データ量・ダッシュボード本数・保守範囲に応じて別途お見積りします。本レポートでは具体金額の明示は控え、初回お打ち合わせ後に正式見積を提出いたします。

推奨と根拠

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

本命

Metabase ＋ n8n ＋分析DB

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

ノーコード性が最高・非エンジニア向き

ID課金ゼロ・オンプレ完結・データ非流出

2027新基幹はn8nの受け側で吸収し作り直さない

次点 / 併用

Apache Superset ＋ n8n ＋分析DB

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

大規模・行レベル権限が無償で標準

Metabaseと同じ分析DBを共有でき段階移行可

編集操作はMetabaseよりやや専門的

選び方の一言：「とにかく誰でも触れて・安く・オンプレで」→ 本命 Metabase。「規模と厳密な権限を無償で極めたい」→ 次点 Superset。どちらも n8n＋分析DB でデータ連携・自動更新を担う点は共通で、まずMetabaseで開始し、必要に応じてSupersetを足す段階導入をおすすめします。

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

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

STEP 1
選定・要件定義・PoC

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

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

分析DB設計＋n8nで夜間バッチ・F-Watch取込を実装。主要ダッシュボードを現行DB基準で先行構築。

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

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

STEP 4
内製化・運用保守

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

想定スケジュール（一例・実際は初回お打ち合わせで確定）

2026 Q4

選定・PoC

主軸BI確定

2027 Q1

基盤・連携構築

現行DBで先行

〜2027/5

導入完了・習熟

現行データで運用開始

2027/8

新基幹/WMS刷新

受け側切替のみ

2027/8〜

本番・内製運用

保守伴走

ポイント：「新基幹が動く前に、現行データでBIを先に立ち上げて習熟」→「新基幹稼働時はn8nの受け側だけ切替」。これにより2027年5月の導入完了希望を、元データ刷新リスクを分離しながら実現します。

よくあるご質問（初回商談想定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のような独自言語がない → 他ベンダーでも引き継げる
編集10名への内製化研修（ノーコード操作＋n8nの読み解き）で、日常修正を御社内で完結
構成ドキュメント・データ定義書を整備し、"その人・その会社でないと無理"を作らない

むしろ狙いは逆で、「特定製品・特定担当に縛られない状態」に持っていくことが今回のリプレイスの目的です。弊社は"抜けても回る"体制づくりまで含めて伴走します。

Q5 従業員9,000名規模、閲覧300名同時アクセスでも性能は大丈夫か？性能

大丈夫な構成にできます。要はBIが生データを毎回集計しないことがカギです。

BIは事前集計テーブルを参照するため、同時アクセスに強い
大規模なら 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（300名でも0円）」「特定部署の作り込み＝既存のPower BI」といった使い分けもできます。分析DBを"共通の一次データ"として持つため、どのBIから見ても数字が一致する状態を保てます。

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

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

現行QlikViewの帳票・ダッシュボードは何本か（初期構築規模の算定に直結）

データ量と応答速度の要件（数千万件の"何を""どの粒度で"／PostgreSQLで足りるかClickHouseが要るか）

権限分離の細かさ（閲覧/編集の2区分で足りるか／部門ごとに見える行を絞る必要があるか＝Superset判断）

F-Watch・RPA夜間バッチの出力仕様（ファイル形式・置き場所・更新タイミング）

2027 新基幹/WMSの製品・データ提供方式（CSV/API/DB直参照のいずれか）

オンプレサーバーのスペック・OS（Docker利用可否・社内ネットワーク要件）

保守範囲の希望（監視・障害対応をどこまで弊社に委ねるか）

本レポートはあくまでも現時点の仮定に基づくドラフトです。製品の機能範囲・ライセンス条件・運用方法は、上記の確認結果を踏まえ初回お打ち合わせ以降に精査し、最終的な構成・見積は御社との協議のうえ確定いたします。OSS製品の仕様やライセンスは変更される可能性があるため、契約前に最新条件を再確認します。

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

Metabase（ノーコードBI・閲覧300名/編集10名）＋ n8n（データ連携・自動更新基盤）＋ 分析データ基盤（数千万件を高速集計）