月初になると、売上集計の画面を開いた担当者が「また止まった」と言い出す。数分待てば表示されるものの、その間は受注入力をしている別の担当者の操作まで遅くなる。
この相談をすると、返ってくる提案はたいてい「分析用のデータウェアハウスを別に建てましょう」です。方向としては間違っていません。ただ、その前に決めるべきことが飛ばされていることがよくあります。 決めずに建てると、維持費と運用の手間が増えたのに、担当者の待ち時間は変わらないという結果になります。
なぜ集計だけが業務を止めるのか
業務システムのデータベースは、1件を速く読み書きすることに最適化されています。受注を1件登録する、顧客を1件引く。この形の処理は、必要な行だけを索引で拾って終わります。
集計はこれと性質が逆です。過去1年分の全行を舐めて、合計や件数を出します。 同じデータベースの上で同時に走ると、集計側がメモリとディスクを占有し、その裏で動いている通常の入力処理が待たされます。「重いのは集計画面だけのはずなのに、全体が遅くなる」という症状はここから来ます。
ここを取り違えて、索引を足したり、サーバーのスペックを上げたりする対処に進むことがあります。効く場合もありますが、根本的には同じ場所に置いていることが原因なので、データが増えれば同じ症状が戻ってきます。なお、集計とは無関係に一覧画面が遅い場合は別の原因であることが多く、切り分けは一覧が遅いときに最初に見る場所に整理しています。
置き場所は三択ある
選択肢は「いまのDB」か「クラウドDWH」かの二択ではありません。間があります。
A. 業務DBの中で分離する。 参照専用の複製（レプリカ）を1台用意し、集計はそちらに向けます。構成はほとんど変わらず、入力側が集計に巻き込まれなくなります。多くの中小企業の業務システムは、これで足ります。 PostgreSQL のような汎用DBを1つで回す判断については単一DBでどこまで持つかにまとめました。
B. 分析専用のDBを1つ置く。 日次で業務DBから抜いたデータを、集計に強い形式で別に持ちます。列指向のデータベースを使うと、同じ集計が桁違いに速くなります。サーバーを増やさず、既存のサーバー上でファイルとして持てるものもあります。
C. クラウドのデータウェアハウスを契約する。 BigQuery などに載せます。データ量が大きい、部署をまたいで多人数が自由に触る、外部データと突き合わせる——このいずれかが要るときに効きます。BigQuery のデータを各部署が自分で触れる形にする方法はConnected Sheets での自己解決にあります。
分岐点はデータ量ではない
どれを選ぶかを、行数で決めようとすると失敗します。100万行でもCが要る会社があり、1億行でもBで足りる会社があります。
見るべきは次の3点です。
- 誰が見るか。 決まった帳票を経理が月1回見るだけなら A か B です。営業も製造も自分で条件を変えて掘りたいなら C の検討に入ります。
- どのくらい新しい必要があるか。 「昨日までの数字」で判断できるなら、夜間に一度作るBで足ります。「たった今の受注状況」が要るなら、そもそも分析基盤ではなく業務システム側の画面で解く問題です。
- 誰が面倒を見るか。 Cを選ぶと、権限管理・課金の監視・データの取り込み処理の保守が増えます。専任がいない会社でCを選ぶと、半年後に「誰も中身を把握していない基盤」が残ります。 これがいちばん見落とされます。
3点目を先に決めておくと、AとBの範囲で収まる会社がかなりの割合であることが分かります。
Bの選択肢が広がっている
Bにあたる分析専用DBのうち、いま動きが大きいのが DuckDB です。追加のサーバーを立てずに、アプリケーションの中や1台のマシン上でそのまま動く列指向のデータベースで、集計処理に特化しています。
2026年8月17日に公開された次期版 DuckDB 2.0 のプレビューでは、性格が変わる変更が入っています。
- サーバーとして動けるようになる。 これまでは1つのプロセスの中でしか動きませんでしたが、複数のクライアントから接続できる形が正式機能になります。「分析用の小さなDBを1台置く」構成が素直に組めるようになります。
- 入出力が非同期になる。 クラウドストレージ上のファイルを読むときの並列度が上がり、リモートのデータに対する問い合わせが最大20倍速くなると説明されています。
- 半構造化データ用の型が入る。 JSONのような形のデータを、構造を自動で見つけて効率よく持てるようになります。
公開されている実測では、100万辺のグラフを辿る再帰的な問い合わせが 4.90 秒から 0.12 秒へ、およそ40倍になったとされています。
ただし、これはプレビューです。 正式版は2026年秋の予定で、いま業務システムの本番構成に入れるものではありません。知っておく価値があるのは「AとCの間の選択肢が、来期にはもっと現実的になる」という点です。 いま提案されているCの構成が本当に必要かを問い直す材料になります。
提案を受け取る側の確認事項
「データ基盤を作りましょう」という提案を受けたとき、次の3つを聞くと中身が見えます。
- その基盤が無い場合、いま困ることは具体的に何ですか。 「将来のため」しか出てこないなら、いま作る理由はありません。困りごとが「月初の待ち時間」だけなら、Aで解決する可能性が高いです。
- 運用は誰がやりますか。月々いくらかかりますか。 構築費だけでなく、維持の費用と担当を確認します。ここが空欄の提案は、作ったあとで止まります。
- やめるときはどうなりますか。 データを引き出して別の場所に移せるか。この答えが用意されている提案は、たいてい設計もまともです。
次にやること
まず、遅いと言われている画面を1つ特定してください。 「システム全体が重い」では手が付けられませんが、「月次売上集計の画面が月初だけ5分かかる」まで絞れれば、対処の選択肢はかなり狭まります。
そのうえで、その集計を誰が何回見るかを数えてください。 月1回、経理の1人だけが見る帳票のために基盤を建てる判断には、ほぼなりません。逆に、複数部署が毎日違う切り口で見ているなら、置き場所を分ける投資は回収できます。
業務システムの集計処理の見直し、分析データの置き場所の設計、既存提案のセカンドオピニオンについては、グリームハブの開発・AI・自動化のご相談で承っています。データ量と利用者の広がり方によって最適な構成が変わるため、個別にご相談ください。お問い合わせからどうぞ。
