設備1台が1分ごとに1行を書き出すと、100台では年5,256万行になります。この量を生産管理システムの内部に貯め続けると月次の集計が詰まり、外に出す案が持ち上がりました。本記事では、設備ログ・生産実績・品質検査の3系統をどの粒度で載せるか、既存の生産管理システムやMESからどの方式で流すか、その量なら月額がいくらになるか、現場が見続ける画面をどう組むかを順に整理します。単価と無料枠は2026年8月13日にGoogle Cloud公式の料金ページで確認した値です。
まとめ：製造業でBigQueryを採用してよい条件と最初に載せるデータ
製造業でBigQueryを採用してよいのは、次の3つが同時に成り立つときだけです。自動でデータが上がる設備が50台以上ある、生産実績と品質検査を突き合わせて不良の原因を追う要求が現場から出ている、参照者が複数部署にまたがる。揃わないなら既存の生産管理システムの帳票機能とExcelで足ります。
最初に載せるのは設備ログではなく生産実績です。設備ログは行数が多い一方、品目コードとロット番号が付いておらず単体では原因追跡に使えません。生産実績を先に入れて品目・工程・ロットの軸を確定させ、設備ログを時刻で寄せる順序にすると後戻りが減ります。
費用の当たりも先に置きます。設備100台・1分間隔・1行200バイトなら年約10.5GBで、ストレージは毎月10GiBの無料枠と同水準です。請求を動かすのはスキャン量のほうで、5画面を1時間ごとに全期間スキャンさせると月約210米ドルに達しました。日付パーティションで1日分に絞れば、同じ画面が毎月1TiBの無料枠の内側で回ります。
製造現場で生まれる3種類のデータと、BigQueryに載せる前に決める粒度
工場から出るデータは性質の違う3系統に分かれます。一括で設計すると、行数の桁も更新頻度も噛み合いません。
設備ログ・生産実績・品質検査データの発生頻度と1日あたりの行数の目安
設備ログはPLCやセンサーが出す時系列で、1台1分間隔なら1日1,440行、100台で14.4万行です。生産実績は製造指図の消化に伴って出るため、1日の指図200件・工程5つなら1日1,000行程度にとどまります。品質検査はその中間で、抜き取りなら生産実績と同じ桁、全数の画像判定なら設備ログに近い桁まで膨らみます。
桁が3系統で100倍違うことが設計上の分かれ目です。設備ログを基準に設計すると生産実績側に無意味なパーティションが並び、生産実績を基準にすると設備ログが1パーティションに詰まります。3系統は別テーブルに分け、結合はクエリ側で行います。用途ごとの成果条件はBigQueryの事例4類型の側で整理しました。
生データのまま載せる範囲と、PLC側で間引いてから送る範囲の線引き
すべてを生のまま送る必要はありません。基準は「後から粒度を戻せるか」です。温度や電流のような連続値は、1分平均に間引くと異常のスパイクが消えて戻せなくなるため生のまま送ります。稼働・停止のような状態値は変化点だけで復元できるので、PLC側で間引いた方が行数が1桁減りました。
迷ったときは「その値で過去の異常を再現する場面があるか」で切ります。原因追跡に使う可能性がある信号は生のまま、稼働率の集計にしか使わない信号は間引く。この線引きを設備ごとの信号一覧に書いてから配線設計に入ります。
設備IDと品目コードの表記ゆれを吸収するマスタ整備の順序と担当
製造業の基盤で最初に破綻するのは、たいてい設備IDです。設備台帳では「NC-01」、PLCのタグ名では「nc01」、保全システムでは「機械番号1」という状態が普通にあります。品目コードも旧図番・新図番・得意先向けの型式が併存しました。
- 設備台帳と品目マスタの正本をどのシステムに置くかを決め、所管部署を1つに定める
- PLCタグ名・検査機の出力・生産管理システムの各コードから正本への変換表を作る
- 変換表をマスタテーブルとして持ち、取り込み時ではなく整形層で当てる
- 正本に無いコードは弾かずに未知として溜め、週次で棚卸しする
変換表を取り込み時に当てると、間違った対応付けをした過去データを復元できません。生のまま入れて整形層で当てておけば、変換表を直して作り直すだけで済みます。担当はコードの意味を知っている生産技術か生産管理に置きます。
設備ログと生産実績を1つのデータセットに集約するテーブル構成の作り方
どのデータセットにどう並べるかが、スキャン量つまり月額を直接決めます。
時系列テーブルは日付パーティション、設備IDでクラスタリングする理由
BigQueryのパーティション分割テーブルは、時間単位・日単位・月単位・年単位で作成でき、DATE型の列を使う場合は日・月・年に限られます。設備ログは日単位のパーティションにし、設備IDによるクラスタリングを併用する構成が扱いやすい形でした。公式ドキュメントも両者の併用を勧めています。
時間単位を選びたくなる場面はありますが、1日24個のパーティションが365日で8,760個になり、数年分で上限に近づきます。時間単位まで刻む必要があるのは監視画面を同じテーブルで賄う場合だけで、監視は別系統に切ります。
生産実績と品質検査を結ぶキー設計：ロット番号と製造指図番号の扱い
不良の原因追跡は、品質検査の結果から「そのとき何番の指図をどの設備で流していたか」を引く操作です。この経路を作れるかどうかで基盤の価値が決まりました。結合キーは製造指図番号を主、ロット番号を従に置きます。ロット番号は工程間で分割・統合されるため、単独では追跡が切れるからです。
設備ログには指図番号もロット番号も入っていません。そこで生産実績側に「その設備でその指図を流していた開始時刻と終了時刻」を持たせ、設備ログとは時刻範囲で結合しました。この範囲テーブルを整形層に置けば、分析のたびに時刻計算を書き直さずに済みます。
生データ層・整形層・集計層の3層に分けるデータセットの分割基準
データセットは役割で3つに割ります。生データ層は取り込んだままの姿で、加工も削除もしません。整形層は表記ゆれの変換とキーの付与を済ませた状態、集計層は画面が読む日次・時間別の集計結果です。分ける理由は権限とコストの両方にあります。
権限の面では、生データ層を情シスと開発者だけに閉じ、現場の閲覧者には集計層しか見せない構成にできました。コストの面では、1回のスキャンがギガバイト単位からメガバイト単位に落ちます。3層に割る手間は初回だけで、運用後の差は請求書に出ます。
既存の生産管理システムからBigQueryへ流す4つの連携方式と選定条件
データ源はクラウドではなく工場内のオンプレ機器です。この条件が連携方式の選択を縛ります。
日次バッチ・CDC・Pub/Sub直結・ファイル連携の4方式を比べる判断軸
方式は遅延と運用負荷の釣り合いで選びます。すべてを最短の遅延で揃える必要はありません。
| 方式 | 遅延 | 向く用途 | 注意点 |
|---|---|---|---|
| 日次バッチ読み込み | 1日 | 生産実績・原価集計 | 当日中の異常は見えない |
| CDC（Datastream） | 数分 | 指図と工程進捗の変更 | 元DBの負荷と権限設計 |
| Pub/Sub直結 | 秒 | 設備アラート・稼働状態 | 重複排除は後段で行う |
| ファイル・iPaaS経由 | 数分〜1日 | 検査機のCSV出力 | 命名と文字コードの統一 |
DatastreamはMySQL・Oracle・PostgreSQL・SQL Server・MongoDB・Spannerを一般提供のソースとして扱い、宛先にBigQueryを選べます。国内の生産管理システムはSQL ServerかOracleで動いていることが多く、この2つが対象に入る点が実務で効きました。Pub/SubのBigQueryサブスクリプションは、受け取ったメッセージをBigQuery Storage Write API経由でテーブルへ直接書き込む仕組みで、別のサブスクライバーもDataflowも要りません。配信保証は「少なくとも1回」だけなので、重複排除は後処理で担保します。
オンプレのMESが閉域網にある場合の中継設計と、送信の失敗時の再送
工場のMESや制御系は外部通信を許可していないことが多く、そのままでは1行も出せません。現実的な形は、工場内に中継サーバーを1台置き、そこだけが外向きの通信を持つ構成です。制御系からは既存の閉域網、中継サーバーからGoogle Cloudへは限定した経路だけを開けます。
設計で落としやすいのが失敗時の扱いでした。回線が切れている間のデータを中継サーバー側でファイルに保持し、復旧後にまとめて送る仕組みを最初から入れます。Pub/Sub側でデッドレタートピックを設定しておくと、スキーマが合わないメッセージが握り潰されずに退避され、属性CloudPubSubDeadLetterSourceDeliveryErrorMessageに理由が入ります。この2段構えが無いと、停電明けの1日分が静かに消えました。
1秒単位のセンサー値を送るときにストリーミングを見送る判断の条件
1分間隔を1秒間隔に変えると、100台で年約31.5億行・約630GBになります。60倍です。取り込み料金そのものは、Storage Write APIが1GiBあたり0.025米ドルで毎月2TiBまで無料のため、この量でも大きくは動きません。跳ねるのはストレージと、その先のスキャン量です。
1秒単位を採るかは、判断に使う時間分解能で決めます。稼働率や日々の生産性を見るだけなら1分平均で足り、1秒値は費用に見合いません。振動や電流の波形から異常の予兆を取る場合だけ、対象設備を絞って1秒以下に上げます。全設備を一律に上げる設計は、用途を実測できていない段階では見送ってください。
工場のデータ量から逆算する月額費用の目安と、請求が膨らむ操作の型
製造業の見積りで最も外れるのが費用です。ストレージ単価を見て安いと判断し、運用開始後にクエリ側で請求が跳ねる順序をよく見ました。
設備100台・1分間隔で1年分を貯めた場合のストレージ量と概算費用
前提を置いて計算します。設備100台、1分間隔、1行200バイト。行数は年5,256万行、バイト数は約10.5GB（約9.8GiB）です。BigQueryのストレージは毎月10GiBまで無料なので、1年分がちょうど無料枠の縁に来ます。3年貯めても約30GBで、超過分の課金は小さい水準にとどまりました。
90日間連続で変更のないテーブルまたはパーティションは長期保存扱いになり、単価が自動で約50%下がります。性能・耐久性・可用性に差はありません。設備ログは書き込んだ後に更新しないため、この割引がそのまま効きます。ストレージはボトルネックになりません。
無料枠1TiBの中で回る規模と、超えたときに効くパーティション指定
問題はクエリ側です。オンデマンド料金は処理バイト数に対する課金で、毎月1TiBまでが無料、超過分は1TiBあたり6.25米ドル。約9.8GiBのテーブルを1日1回フルスキャンしても月294GiB程度で、無料枠に収まります。
効くのはパーティション指定です。日付パーティションを切ったテーブルでWHERE句に日付の範囲を書けば、1日分の約27MiBだけがスキャン対象になります。書かなければ全期間の約9.8GiBが読まれ、同じ画面でも360倍の差が出ました。なおLIMITを付けても課金額は減りません。選択した列の処理データ全量に課金されるためで、列と日付の絞り込みだけが効きます。料金モデルの構造はBigQueryとはの解説で分解しました。
ダッシュボードの自動更新がスキャン量を押し上げる仕組みと抑え方
請求が跳ねる典型は、人が書いた重いクエリではありません。画面の自動更新です。5つのダッシュボードを1時間ごとに更新すると、月3,600回のクエリが自動で走りました。各回が全期間の約9.8GiBを読むと月約34.5TiB、無料枠を引いて約210米ドルになります。誰も操作していない夜間も同じ頻度で走り続けます。
抑え方は3つあります。画面が読む先を集計層に限定する、日付パーティションを必ず指定する、更新頻度を用途に合わせて落とす。これで同じ3,600回でも月100GiB弱に収まり、無料枠の内側に戻りました。エラーで終わったクエリとキャッシュから返ったクエリは課金対象外なので、同じ結果を何度も見る画面では条件式を固定します。スキャン量が月次で安定したら、スロット時間課金のEditionsへ切り替える判断も出てきます。コミットメントなしの単価はStandardが0.04米ドル、Enterpriseが0.06米ドル、Enterprise Plusが0.10米ドルで、購入は最小50スロットから50スロット単位です。
現場に定着する可視化の作り方：見る単位と更新頻度、権限を決める基準
基盤を作ったのに誰も見ない状態はよく起きます。原因は精度でも速度でもなく、画面の単位が現場の仕事と合っていないことでした。
班長が朝礼で見る画面と、生産技術が原因を追う画面を分けて作る理由
朝礼で使う画面に要るのは、昨日の実績が計画に対してどうだったかと、止まった設備がどれかの2点だけです。指標を10個並べた画面は5分の朝礼では読めません。生産技術が不良の原因を追うときは、指図単位で設備ログまで降りられる詳細が要ります。情報量が正反対なので、1枚に統合すると両方が使われなくなりました。
作る順序は朝礼用が先です。毎日開かれる画面が1枚できれば、データの間違いは翌日に指摘されて直ります。詳細画面から作ると、使われないまま数値のずれが放置されました。
Looker Studioで組む場合の更新頻度と、抽出の保存を挟む判断
可視化にLooker Studioを使う場合、既定のままだとページを開くたびにBigQueryへクエリが飛びます。閲覧者が20人いれば20回です。ここで抽出（エクストラクト）を挟み、1日1回だけ集計結果を取り込む構成にすると、クエリ回数は1回に落ちました。日次で足りる指標はすべてこの形にします。
抽出を挟まないのは、当日の進捗や設備の停止状況のようにその場の値が要る画面だけです。ツール側の機能と料金はLooker Studioの解説記事にまとめました。どの画面が何分遅れまで許されるかを先に現場と決めれば、この判断は機械的に片付きます。
閲覧者が増えたときの権限設計と、行レベルの制御を入れる判断の境界
閲覧者が1拠点に閉じているうちは、データセット単位の権限で足ります。複数拠点や協力会社が入ると、同じテーブルの中で見せる行を分ける必要が出てきました。BigQueryはCREATE ROW ACCESS POLICYによる行アクセスポリシーで、WHERE句と同じ形の条件式を使い、ユーザーやグループごとに見える行を絞れます。
ただし、行レベルの制御を最初から入れるのは勧めません。ポリシーが増えるほど、なぜこの人にこの行が見えるのかの説明が難しくなるからです。境界は「拠点や取引先をまたいで同じテーブルを見せる必要が出たとき」。それまではデータセットを分ける方が軽く済みます。JSON列には適用できないため、その列を持つテーブルは設計段階で分けます。
製造業でBigQueryを見送るべき場面と、先に直すべき前工程の条件
合わない条件で入れると、費用より先に工数で失敗します。条件を数値で切ります。
工場が1拠点・設備20台以下で日次集計しか要らないなら採用しない
設備20台を1分間隔で1年貯めても、約1,051万行・約2.1GBにしかなりません。この規模なら既存の生産管理システムのデータベースで集計が回ります。日次の実績集計しか要求が無いなら、基盤を別に立てる工数と学習コストが上回るため採用しません。分析が遅いなら原因はデータ量ではなくインデックスか帳票の作りで、既存システム側を見直すほうが早く効きました。
紙とExcelで実績を集めている段階では、収集の仕組みを先に作る
実績が日報の手書きとExcelの転記で集まっている工場では、BigQueryに入れても分析できません。入力の粒度が人によって違い、記録の抜けが日常的にあるからです。先に作るのは、生産実績が自動で記録される仕組みのほうでした。
一創では、工程実績の収集から進捗の把握までを含む生産管理システムの開発を受託しており、収集の仕組みが無い段階からの相談も引き受けています。分析基盤は、記録が機械的に溜まるようになってからの次の一手です。順序を逆にすると、精度の低いデータを高い費用で貯めるだけになりました。
導入初期に費用と工数が跳ねる失敗の型と、着手前に置く3つの歯止め
繰り返し見る失敗は、全設備の全信号をとりあえず生で送る構成です。用途が決まっていないため間引き判断ができず、行数だけが積み上がります。もう1つは、パーティションを切らずに画面から生データ層を直接読む構成で、これが月200米ドル級の請求になりました。
- 対象設備を最初は10台以内に絞り、用途が実証できてから広げる
- 画面が読むテーブルを集計層に限定し、生データ層への直接参照を権限で塞ぐ
- プロジェクトに費用の上限アラートを置き、超過時に通知が飛ぶようにする
3つとも設定は数時間で終わります。進め方の組み立てと体制の分担はBigQuery導入の手順と体制の側で扱いました。
BigQueryを採用してよい3つの条件と、判断を分ける具体的な数値
逆に、次の条件が揃っているなら着手して問題ありません。自動でデータが上がる設備が50台以上、または年間1億行を超える見込みがある。生産実績と品質検査を突き合わせる要求が現場から具体的に出ている。参照者が複数部署または複数拠点にまたがる。
50台という線には根拠があります。1分間隔で年5,256万行を超えると、既存のリレーショナルデータベースでの全期間集計が分単位に入り、帳票の待ち時間として現場から不満が出るからです。1億行を超えるとインデックスを足しても集計時間は戻りません。この境界を越えているかを、まず自社の設備台数と収集間隔から計算してみてください。
よくある質問
費用・設定・使い方について繰り返し挙がる質問をまとめました。
製造業でBigQueryを使うと月額はどれくらいかかりますか？
データ量よりも画面の作り方で決まります。設備100台・1分間隔・1行200バイトなら年約10.5GBで、ストレージは毎月10GiBの無料枠と同水準です。クエリはオンデマンド料金で毎月1TiBまで無料、超過分が1TiBあたり6.25米ドル。集計層を作らずダッシュボードを1時間ごとに全期間スキャンさせると月約210米ドルに達しますが、日付パーティションを指定すれば無料枠の内側で回ります。見積りは月間スキャン量から逆算します。
生産管理システムのデータをBigQueryに送る設定は何から始めますか？
最初に決めるのは連携方式ではなく、送る対象と粒度です。生産実績のどのテーブルを、どの主キーで、どの頻度で送るかを1枚の表にまとめました。そのうえで、日次で足りるならCloud Storage経由のバッチ読み込み、数分の遅延が要るならDatastreamによる変更データキャプチャを選びます。DatastreamはSQL ServerとOracleを一般提供のソースとして扱うため、国内の生産管理システムの多くが対象に入ります。設定作業より、送る対象を絞る側に時間をかけてください。
設備のセンサーデータは何秒間隔まで送って問題ありませんか？
判断に使う時間分解能で決めます。稼働率や日次の生産性を見るだけなら1分間隔で足り、1秒に上げても情報は増えません。100台を1秒間隔にすると年約31.5億行・約630GBとなり、1分間隔の60倍です。取り込み自体はStorage Write APIが毎月2TiBまで無料のため吸収できますが、ストレージとスキャン量が同じ倍率で増えます。波形から予兆を取る目的がある設備だけに絞ってください。
既存のオンプレDWHがある場合でもBigQueryを併用する意味はありますか？
あります。分ける軸は、更新が入るデータか、追記だけのデータかです。原価計算や在庫のように更新と整合性が要る処理は既存のデータベースに残し、設備ログや検査結果のように追記しかしない時系列をBigQuery側へ寄せると噛み合います。全面移行を先に検討すると、既存の帳票と締め処理の作り直しで止まりがちでした。追記型だけを外に出す形なら、既存システムを止めずに始められます。
現場の担当者がSQLを書けなくても使い方は定着しますか？
定着します。条件は、現場が触るのはBIツールの画面だけという分担にすることです。SQLは情シスか外部の開発側が集計層のビューとして作り込み、現場には期間と設備の絞り込みだけを渡します。定着した工場に共通していたのは、朝礼で毎日必ず開く画面が1枚あったこと。全員にクエリを書かせようとした場合はほぼ使われませんでした。
関連記事
- BigQueryとは：サーバーレスDWHの仕組み・料金・できないことと採用判断：料金モデルとスロットの構造を製品側から分解。
- BigQueryの事例4類型｜成果が出た条件と自社導入の判断軸：業種横断の用途パターンと成果が出た構成の共通条件。
- BigQuery導入の手順と体制｜PoCから本番移行までと外注の判断：着手後の工程・体制・パートナー選定の観点。
- Looker Studioとは｜無料BIツールの機能・料金・BigQuery連携と企業導入の判断：可視化側の機能と抽出を挟む設定の詳細。
- 需要予測の事例を業種別に読む｜製造・小売・アパレル・自動車で効果が出た条件：集めたデータを予測に回す段階の業種別実例。
- BigQueryを金融・保険で使う判断｜規制要件と勘定系連携・DWH移行の見極め：金融・保険で先に決めるデータ所在と連携方式の判断。
