※この記事は「Qlik Cloud Analyticsの分析用データ容量」をテーマにした全2回構成の第2回です。第1回では容量の考え方と確認方法を整理しました。本記事では、日々の運用で判断しやすいように、容量がどのように増減するのかを7つの検証ケースで確認します。

Qlik Cloud Analyticsでは、アプリケーション（以下アプリ）で利用するデータに対する操作によって、分析用データ容量が変わります。対象となる操作には、新規取り込み、QVDの再利用、リロード（アプリの複製後のリロード含む）、削除などがあります。

しかし、どの操作で容量が増えるのか、運用の中でどのように判断すればよいのか、イメージしづらい場合と感じている方もいらっしゃるのではないでしょうか。本記事では、容量管理を実務で考えるために、7つの検証ケースでポイントを整理します。

※本記事は、2026年8月時点のQlik Cloudヘルプの情報をもとに作成しています。契約内容やエディションによって、利用できる機能や計測基準が異なる場合があります。
分析用データを計測基準とするのは、主にQlik Cloud Analytics Standard、Premium、Enterpriseです。Qlik Cloud Analytics Starterはユーザー数を基準とするサブスクリプションのため、契約しているエディションによって容量の考え方が異なります。
詳しくは、サブスクリプションの計測基準について(Qlik Cloudヘルプ)と分析用データ(Qlik Cloudヘルプ)をご確認ください。

分析データを新規に取り込む場合

まず確認したいのは、新規取り込みが分析用データ容量にどのように影響するかです。たとえば、次の2つのケースを比較します。

1. CSVのようなファイルをアップロードして取り込む場合

2. Snowflakeなどの外部ソースからデータをロードする場合

どちらの場合も、Qlik Cloudに新しくデータを持ち込むため、分析用データ容量の計測対象になります。
今回は、約2GBのデータを上記の2つの方法で取り込み、計測しました。結果を表にまとめます。

※…データサイズは、筆者のPCに保存したデータのサイズをプロパティで確認した値です。
　　Snowflakeの場合は、テーブルをダウンロードしたCSVファイルを実測しています。

Snowflakeなどの外部データから取り込む際、Qlik Cloudのデータ容量としてカウントされるのは「圧縮されていない状態」のデータサイズです。

そのため、Snowflake上の表示サイズ(圧縮された状態)よりも、実際のカウント対象となる容量の方が大きくなる場合がある点にご注意ください。
図1はSnowflake上のスクリーンショットです。Snowflake画面上ではテーブルサイズは1.4GBと表示されています。一方、Qlik Cloudの分析用データ容量は2,007,718,755バイト(1.87GB)として計測されているため乖離があることが確認できます。

図1:Qlik Cloud Analyticsに取り込んだSnowflakeのテーブルサイズのスクリーンショット

圧縮率の高いDWHからデータを取り込む場合は、一度テーブルをダウンロードして実際のサイズを確認することをおすすめします。

詳細な消費レポートでも、カウントされている容量を確認できます。

図2はケース1で取り込んだCSVファイルを示しています。Datafile IDに値が入っており、Counted Towards Capacityが「Yes」になっていることから、データファイルとしてカウントされていることがわかります。

図2:詳細な消費レポートのテーブルチャートでケース1を確認

図3はケース2のSnowflakeから連携されたデータを示しています。App IDに値が入っており、アプリサイズとしてカウントされていることがわかります。

図3:詳細な消費レポートのテーブルチャートでケース2を確認

アプリを複製した場合

アプリを複製(コピー)して検証や改修を行う運用はよくあります。このとき、複製するだけの場合と、複製後に再ロードする場合で分析用データ容量のカウントが異なります。

単純なアプリの複製では、構成やシートを別のアプリへコピーするだけです。今回の検証条件では、複製操作による分析用データ容量の追加カウントはありません。
一方、複製したアプリで外部ソースからデータをロードし直すと、その取り込み分が新たに分析用データ容量として計測されます。
ケース2のアプリを複製しただけの場合と、複製後にリロードした場合を比較します。

3. ケース2のアプリを複製するだけで、リロードは実施しない

4. ケース2のアプリを複製して、リロードも実施する

それぞれのアプリIDは、図4、図5に示した詳細画面で確認できます。

図4:ケース3の複製のみしたアプリのアプリID

図5:ケース4の複製後にリロードしたアプリのアプリID

結果を表にまとめます。

ケース3では、共有スペースでアプリを複製するだけでリロードしない場合、複製操作による追加カウントはありません。図6のように詳細な消費レポートで検索しても一致するものがないことから、今回の検証では、複製による追加カウントがないことを確認できます。(詳細な消費レポートで検索した際に一致するものがない場合は、分析用データ容量のカウント対象になっていません。)

図6:詳細な消費レポートでケース3のアプリを検索したが該当するものはなし

ケース4では、ケース2のアプリと同じ量のデータがカウントされています(図7)。

図7:詳細な消費レポートのテーブルチャートでケース4を確認

「アプリの複製 = すべて容量が二重に増える」というイメージで一括りにしてしまうと、実態よりも慎重になりすぎる場合があります。リロードすると容量としてカウントされることを理解いただければ「複製は自由にしてよいが、再ロードするタイミングはルールを決める」といった運用設計がしやすくなります。

QVDを利用した場合

次に、QVDを再利用した場合の効果を確認します。

同じデータを複数のアプリで使うとき、毎回外部ソースから直接取り込むのではなく、一度QVD化して再利用すれば、容量と運用を整理しやすくなります。
次の2つのケースを比較します。

5. 外部ソースから同じデータを別アプリへ再度ロードした場合

6. 一度 QVD化したデータを別アプリから利用した場合

ケース5では、ケース2で利用したSnowflakeの接続定義を利用し、異なるアプリを作成しました。
ケース6では、まず、ケース5と同じSnowflakeのデータをQVD化します(図8)。その後、作成したQVDを利用して、2つのアプリを作成します(図9、10)。

図8:データフロー画面でSnowflakeのデータからQVDファイルを作成して保存

図9:QVDから2つのアプリを作成

図10:影響分析画面で同一のQVDから2つのアプリが作成されていることを確認

結果を表にまとめます。

ケース5では、異なるアプリを作成した場合も、ケース2と同様に分析用データ容量としてカウントされています(図11)。

図11:詳細な消費レポートのテーブルチャートでケース5を確認

ケース6では、作成したQVDは容量としてカウントされました(図12)。一方、QVDを利用して作成した2つのアプリは、今回の検証条件では追加カウントされていません(図13、14)。

図12:詳細な消費レポートのテーブルチャートでケース6のQVDファイルを確認

図13:詳細な消費レポートでケース6のアプリ1を検索したが該当するものはなし

図14:詳細な消費レポートでケース6のアプリ2を検索したが該当するものはなし

複数のアプリで共通データを使う場合は、どこまでをQVDで共通化するかが、容量管理と運用整理の重要なポイントになります。

アプリやデータを削除した場合

アプリやデータファイルを削除しても、削除した日の日次ピークや、その月に記録された月間ピークは取り消されません。一方、アプリを削除した翌日以降は、そのアプリの最終リロード量が日次使用量に引き継がれなくなります。

たとえば、ある日に2GBのデータを取り込んだ場合、翌日にリロードしなくても、前回の2GBが計測に含まれます。これは、毎日2GBを取り込んでいるという意味ではなく、最後に取り込んだ量が残っているということです。

そのため、アプリ内のテーブルを削除して表示上のデータを空にするだけでは、容量計測上の2GBがすぐに消えるとは限りません。また、大きなデータを取り込んだ同日にアプリを削除しても、その日に記録されたピーク値は取り消されません。

アプリを削除すると、翌日以降はそのアプリのデータ量が日次使用量に引き継がれなくなります。ただし、削除した日や、その月にすでに記録されたピーク値は変わりません。

おすすめの運用:少量データでリロード

検証用にデータを取り込んだものの、今後も必要なのはシート、チャート、ロードスクリプト、データ接続の設定だけ、というケースがあります。

この場合は、アプリを残したまま、必要最小限のデータでリロードします。最後に正常にリロードしたデータ量を少量に更新できるため、アプリの構成を保ちながら、翌日、翌月以降に引き継がれる量を小さくできます。
たとえば、次のような流れです。

• 1日目:検証のため、約2GBのデータをリロードする

• 2日目:リロードをしないため、前日の約2GBが計測に引き継がれる

• 3日目:約500KBのデータだけでリロードする

• 4日目以降:前回の約500KBを基準に計測される

図15:大きなデータを読み込んだあと、少量データでリロードすると、次の日以降の基準が小さくなるイメージ

このように、少量データでのリロードは、過去に一度だけ大きなデータを取り込んだアプリを、構成を残したまま「軽い状態」に戻すのに有効な方法です。

削除が「倉庫の中の不要な箱を捨てる」イメージだとすると、少量データでのリロードは「棚は残したまま、中身だけを軽いものに入れ替える」イメージに近いと言えます。

ただし、同じ月にすでに約2GBのデータを取り込んでいる場合、その月のピーク値は約2GBのままです。少量データでリロードしても、同月のピーク値が過去にさかのぼって小さくなることはありません。
少量データでリロードした効果は、翌日以降の日次使用量や、翌月の月間ピークで確認できます。

次のケースで実測します。

7. ケース2のアプリに取り込むデータを減らしてリロードする

まず、ケース2のアプリのロードスクリプトを、IDが10行分だけになるように変更します(図16)。その後、アプリをリロードします。

図16:ロードスクリプトの記述を変更

結果は次のとおりです。

2026-08-25にIDを10行分だけにし、取り込むデータ量を制限しリロードたところ、2026-08-26時点ではカウントされているデータ容量が大幅に減少していることが確認できました(図17)。

図17:詳細な消費レポートでケース7のアプリを確認。データ容量が減少していることがわかる

ただし、詳細な消費レポートの「By App ID and Month」タブを確認すると、図18の通り、その月の分析用データ容量として採用されているのは「2,007,718,755バイト(1.87GB)」であることが確認できます。

図18:詳細な消費レポートの「By App ID and Month」タブでケース7を確認

この結果からも、少量データでのリロードは、その月の分析用データ容量の値を取り消すための運用ではないことがわかります。少量データでリロードを行っても当月の月間ピーク容量を小さくすることはできませんが、翌月以降の月間ピークを抑える効果が期待できます。

容量管理で押さえておくポイント

ここまでの検証結果を、容量管理の観点から整理します。

• 外部ソースからデータを取り込む場合、外部ソースに表示されるテーブルサイズと、Qlik Cloudで計測される分析用データ容量は一致しない場合があります。容量を判断する際は、Qlik Cloudの計測値を確認します。

• 今回の検証条件では、アプリを複製するだけでは追加カウントはありません。ただし、複製したアプリをリロードすると、取り込んだデータ量がカウントされます。

• 同じデータを複数のアプリで利用する場合は、外部ソースから各アプリに個別に取り込むのではなく、QVDファイルに保存して再利用する方法をおすすめします。

• アプリやデータファイルを削除しても、その日に記録されたピーク値や当月の最大使用量が過去にさかのぼって消えることはありません。しかし、削除した翌日以降は、そのデータ量が日次使用量に加算されなくなるため、翌月以降の月間ピークを抑える効果が期待できます。

• アプリの構成を残したい場合は、少量のデータでリロードすることをおすすめします。ただし、一度取り込んでいるデータについて、当月の月間ピーク値は減少しない点に注意が必要です。

さいごに

容量管理では、現在アプリに表示されているデータ量だけを見るのではなく、最後にどのくらいのデータを取り込んだか、その量が翌日以降にも引き継がれていないかを確認することが重要です。
「データを再利用する」「不要なものは削除する」「残すものは少量データでリロードする」という考え方を持つことで、利便性と容量管理のバランスを取りやすくなります。
貴社の運用に近いパターンで実施前後を確認しておくと、容量の増減を具体的にイメージしやすくなり、どこから手を付ければよいかを判断する際にも役立ちます。
第1回とあわせて読んでいただくことで、Qlik Cloud Analyticsの容量を仕様として知るだけでなく、運用としてどのように扱うかを考えるきっかけになれば幸いです。
第1回記事:Qlik Cloud Analytics のデータ容量を正しく理解する①ー容量の考え方と確認の基本を整理する

出典：Qlikヘルプ
分析用データ

https://help.qlik.com/ja-JP/cloud-services/Subsystems/Hub/Content/Sense_Hub/Admin/subscription-value-meters-data-for-analysis.htm
サブスクリプションの計測基準について

https://help.qlik.com/ja-JP/cloud-services/Subsystems/Hub/Content/Sense_Hub/Admin/subscription-value-meters.htm
容量ベースのサブスクリプションの詳細な消費量の監視

https://help.qlik.com/ja-JP/cloud-services/Subsystems/Hub/Content/Sense_Hub/Admin/usage-metrics-app.htm