BigQueryを金融・保険で使う判断｜規制要件と勘定系連携・DWH移行

BigQueryを金融・保険で検討するとき、性能や料金より先に止まるのはデータの置き場所と鍵の扱いです。分析基盤としての評価は済んでいても、勘定系の明細をクラウドへ出してよいのか、監査や検査で何を見せるのか、既存のオンプレDWHをどこまで畳むのかが決まらず、稟議が進まない。この記事では、データ所在の線引き、FISC安全対策基準から逆算して先に決める設定項目、勘定系や保険基幹系からの4つの連携方式、オンプレDWHを分割して移す順序を整理します。採用を見送るべき条件も、判断できる粒度で示します。

まとめ：金融・保険でBigQueryを採用してよい条件と先に決める3項目

結論から言えば、金融・保険でBigQueryを採用してよいのは、分析対象が勘定系そのものではなく、そこから切り出した明細や契約データであり、日次より短い粒度で照会したい業務がある場合です。この条件を外れる案件、たとえば月次の集計レポートしか要らない案件では、既存のオンプレDWHを残したほうが総コストは下がります。

着手前に決めるべきは3項目に絞られます。第一にデータの持ち出し範囲、つまりどの系統のデータを国内リージョンへ載せ、どれを載せないか。第二に暗号鍵の管理主体で、Google管理の既定鍵のままにするか、CMEKで自社の鍵管理に寄せるか。第三に監査証跡の保存先と期間です。この3つは後から変えると影響範囲が基盤全体に及ぶため、テーブル設計より前に固めます。

逆に、後から決めてよいものもあります。クエリの課金モデル、ダッシュボードの構成、データマート層の分割は、稼働後の実測を見てから変えられました。先に議論を集中させる先を間違えないことが、金融案件では期間短縮に効きます。BigQueryそのものの仕組みや料金体系はサーバーレスDWHとしてのBigQueryの仕組みと制約で整理しているため、本記事では金融・保険に固有の判断だけを扱います。

金融・保険のデータを載せる前に決めるデータ所在と保管範囲の線引き

金融案件でクラウドDWHの検討が長引く原因の大半は、技術選定ではなく「何を載せるか」の合意形成にあります。系統ごとに扱いを変えると、議論は一気に進みます。

勘定系・契約系・チャネルログの3系統で分ける持ち出し可否の基準

まず勘定系の元帳そのものは、BigQueryへ載せる対象から外します。理由は分析要件がないからではなく、元帳の正本性を二重に持つと、差分が出たときの説明責任が増えるためです。載せるのは元帳から日次で切り出した取引明細で、正本はオンプレに残したまま、分析側は複製という位置づけを明示します。

契約系、つまり保険の契約データや口座の属性情報は、個人情報を含むため列単位で判断します。氏名・住所・連絡先は載せず、契約IDと属性コードだけを載せる構成にすれば、持ち出し範囲の議論は短く済みました。チャネルログ、たとえばアプリの操作履歴やWebの行動ログは、個人特定の要素を落とせば持ち出しの障壁が最も低い系統です。実務では、この3系統目から着手して基盤の運用を慣らし、契約系、取引明細の順に広げる進め方が現実的でした。

東京asia-northeast1と大阪asia-northeast2を選ぶときの基準

BigQueryの国内リージョンは東京のasia-northeast1と大阪のasia-northeast2の2つです。どちらを選ぶかは、災害時の切り替え要件と、既存システムの所在で決めます。勘定系のデータセンターが東日本にあるなら、分析基盤を大阪に置いて地理的に離す構成が候補になります。

ただし、リージョンを分けると転送の経路と費用が増え、運用も二重になります。実務上は、分析基盤の停止が業務停止に直結しない限り、既存システムと同じ側のリージョンへ寄せ、切り替えはデータのエクスポートで担保する構成を選ぶ場面が多くなりました。データ所在を国内に限定したい要件が強い案件では、Assured Workloadsの「日本のデータ境界」というコントロールパッケージが用意されているため、対象製品と制約を個別に確認したうえで採否を判断します。

データセットのロケーションを後から変更できない前提での設計手順

公式ドキュメントには「データセットを作成した後で、そのロケーションを変更することはできません」と明記されています。これは金融案件で効いてくる制約です。検証用に作ったデータセットを米国リージョンのまま本番へ流用すると、作り直しになります。

手順としては、検証の最初のデータセットから国内リージョンで作ります。無料枠で試す段階でも同じです。あわせて、データセット名にリージョンと層（生データ層・整形層・集計層）を含める命名規則を先に決めておくと、後から棚卸しする際に取り違えが起きません。命名規則の変更はテーブル参照の書き換えを伴うため、これも初回に固めます。

FISC第12版から逆算するBigQuery側の設定項目と監査証跡の残し方

金融機関の稟議で参照されるのは、FISCが刊行する「金融機関等コンピュータシステムの安全対策基準・解説書」です。2024年3月に第12版が発行され、2026年8月時点でこれが最新の版にあたります。基準の条文を読み込むより、クラウド側の設定項目へ落とし込む順序を決めるほうが実務は進みます。

FISC第12版と対応セキュリティリファレンスの参照順序と使い方

Google Cloudユーザー会Jagu’e’rの金融分科会が「金融機関向けGoogle Cloud対応セキュリティリファレンス」を公開しており、FISC基準の各項目に対する考え方の対応づけが並びます。ただしこの資料が対応づけの土台に置いたのは第11版で、統制基準・実務基準・設備基準・監査基準を合わせた309項目が対象でした。第12版との差分は自分たちで埋める前提で使います。

参照の順序は、リファレンスで大枠の対応づけを把握し、自社の内部規程に照らして未充足の項目を洗い出し、その項目だけをGoogle Cloudの設定に落とす、という流れです。逆に基準の全項目を最初から自社で読み解こうとすると、着手までに数か月を溶かします。実際の検討では、未充足として残るのは鍵管理・アクセス権限・ログ保存の3領域に集約されました。

CMEKと列・行レベル制御を入れる境界と、暗号鍵運用の担当分け

BigQueryは保存データを既定で暗号化しますが、鍵はGoogleが管理します。自社で鍵を持つならCMEKを使い、Cloud KMSの鍵をデータセットへ紐づけます。鍵を握る側が変わるため、内部規程で「暗号鍵の管理主体は自社」と定めている場合はCMEKが前提になりました。

鍵の運用は分析チームから切り離します。鍵の作成・ローテーション・失効はセキュリティ部門、データセットの作成は基盤チーム、という担当分けにしないと、鍵の削除でテーブルが読めなくなる事故を止められません。列・行レベルの制御は別の層の話で、BigQueryには列レベルと行レベルのアクセス制御、および承認済みユーザー以外に値を隠す動的なデータマスキングが用意されています。境界の引き方はこうです。部署ごとに見える顧客の範囲が違うなら行レベル、同じ行を見るが一部の項目だけ隠したいなら列レベルとマスキング。両方を同時に入れると権限の検証工数が跳ねるため、片方から始めます。

金融検査で提出を求められる操作ログの種類と、保存期間の決め方

検査や内部監査で問われるのは「誰がいつどのデータを参照したか」です。BigQueryではCloud Audit Logsが該当し、テーブルの作成・削除といった管理操作のログと、クエリによる参照のログが別系統で記録されます。後者が取れているかを、基盤の構築時点でログ設定の画面から確認します。

保存期間は内部規程に合わせますが、Cloud Loggingの既定保持のままでは足りない場合が多く、シンクを設定してCloud StorageやBigQueryの別データセットへ書き出します。監査ログを分析対象と同じデータセットに置くと、参照権限が混ざって説明が難しくなるため、保存先は分けます。あわせて、誤削除に備えたタイムトラベルは既定で7日、データセット単位で短縮も可能です（2026年8月時点）。これは監査証跡の代わりにはならないため、別建てで設計します。

勘定系・保険基幹系からBigQueryへ流す4方式と閉域網での中継設計

金融案件で連携方式を決められない原因は、業務側の締め処理の時刻と、閉域網の制約が絡むためです。方式ごとに向く対象を切り分けます。

日次バッチ・CDC・ファイル連携・APIの4方式を比べる判断軸

判断軸は3つ、必要な鮮度、送信元の改修可否、失敗時の再送のしやすさです。鮮度だけで選ぶとCDCやAPIに寄りますが、勘定系の改修は費用も承認も重く、現実には日次バッチが残ります。

最初の1本は日次バッチで通し、業務が回ることを確認してから鮮度の要る系統だけをCDCやAPIへ寄せる進め方が、手戻りを最小にできました。全系統を同じ方式で揃える必要はありません。

閉域網に置いた勘定系から取り出す際の中継構成と再送・欠損の検知

勘定系が閉域網にある場合、BigQueryへ直接書き込む構成は取れません。DMZに中継サーバーを置き、そこからCloud Storageへ送って取り込む2段構成にします。中継サーバーは業務側の資産になるため、運用当番と監視の担当を最初に決めておきます。

再送で問題になるのは重複です。ファイル名に業務日付と連番を持たせ、取り込み後にジョブの実行結果を突き合わせる仕組みを入れます。欠損の検知は、送信側で件数と金額合計を別ファイルに書き出し、BigQuery側で照合するのが確実でした。この照合を省くと、月次の突合で差分が出たときに、どの日のどのファイルが落ちたかを追えなくなります。

保険基幹系とのAPI連携で権限設計とレート制限を詰める実務手順

保険の照会や試算をAPIで連携する場合、詰める順序は権限、レート制限、再試行です。まずサービスアカウントを用途ごとに分け、読み取り専用と書き込みを別アカウントにします。分析側のアカウントに書き込み権限を残したまま本番へ載せると、権限の説明で差し戻されます。

レート制限は、基幹系側の上限に合わせて呼び出し側で絞ります。基幹系のAPIは同時接続数が数十に制限されている例が多く、分析基盤からの一括呼び出しで業務チャネルを圧迫すると影響が大きい。再試行は指数バックオフを入れ、上限回数を超えたら止めて通知する設計にします。無制限の再試行は、障害時に基幹系へ負荷を掛け続けるため入れません。

オンプレDWHから移す範囲と残す範囲を分ける判断軸と移行の順序

既存のオンプレDWHがある金融機関では、全面移行を前提にすると計画が立たなくなります。分けて考えると期間の見通しが立ちます。

勘定系を残して分析系だけを先に移す場合の切り分けと移行の範囲

切り分けの基準は、そのデータが業務処理の入力になっているかどうかです。日次の勘定処理や帳票出力の入力になっているテーブルは、オンプレに残します。移すのは、経営レポートやマーケティング分析、リスク計測など、参照専用のワークロードです。

この切り分けだけで、移行対象は既存DWHのテーブル数の3割から4割に収まる例が多くありました。残りは既存のまま動かし、必要に応じて分析側へ複製します。全面移行はその先の話で、初期の合意事項に含めない。ここを曖昧にすると、勘定処理の停止リスクが議題に上がり、意思決定が止まります。移行の進め方そのものはPoCから本番移行までの手順と体制の組み方で扱っているため、あわせて確認してください。

既存DWHのストアドプロシージャを持ち込まないと決める判断基準

オンプレDWHには、長年の業務ロジックがストアドプロシージャとして蓄積されています。これを機械的に移植すると、移行工数の過半をここに使い、しかも移行後の保守が難しくなります。

判断基準はこうです。年に数回しか動かないもの、出力先が既に廃止された帳票のもの、担当者が説明できないものは移植しません。移すのは、現在も参照されているレポートの生成に直結するロジックだけに絞り、SQLとして書き直します。手続き型のまま持ち込むと、BigQueryの課金がスキャン量に依存する性質と噛み合わず、費用が読めなくなります。棚卸しの結果、移植対象が2割を切る案件も珍しくありません。

並行稼働の期間を決める基準と、旧DWHを停止してよい判断の条件

並行稼働の期間は「同じレポートが両方で同じ値を出す状態が、月次の締めを2回通過するまで」を基準にします。期間で切るのではなく、締めの通過回数で切ると、関係部門との合意が取りやすくなりました。

旧DWHを止めてよい条件は3つです。移行対象のレポートが全て新基盤で出ていること、参照系のバッチジョブの接続先が全て切り替わっていること、監査で参照する過去データの保管方針が決まっていること。3つ目が抜けると、停止直前で「過去5年分はどこに残すのか」という論点が出て、停止が半年延びます。勘定系との連携を含めて要件整理から任せたい場合は、金融システム開発の受託で扱う領域と重なるため、基幹系の改修範囲まで含めて相談先を検討してください。

金融でBigQueryを見送る条件と、規制対応で詰まる設定の失敗パターン

ここは判断を言い切ります。金融・保険であっても、BigQueryを入れないほうがよい条件があります。

データの国外移転を一切認められない案件でBigQueryを採用しない基準

データを国内に閉じる要件がある場合でも、リージョンを国内に指定すれば保存データは国内に置かれます。採用を見送るのは、保存だけでなく、サポート対応や運用の過程で国外の担当者がデータへ触れる可能性まで一切認められない、と内部規程が定めている案件です。この条件は設定では満たせません。

この場合の選択肢は、国内事業者のDWHサービスか、オンプレでの構築です。Assured Workloadsのコントロールパッケージで満たせる範囲もありますが、対象製品と機能の制限を精査する工数が数か月単位で発生します。要件の出どころが内部規程であれば、規程側の見直しを先に議題に載せたほうが早い。技術で押し切ろうとすると、検討が長期化して案件そのものが止まります。

分析対象が月次集計に限られる場合に既存DWHを残す判断の分岐点

月次の集計レポートだけが目的で、対象データが数百GB規模なら、BigQueryへ移す必要はありません。既存DWHの余力で足ります。分岐点は、日次より短い粒度で照会したい業務が実在するか、データ量が数TB規模へ伸びているか、この2点です。

どちらも該当しないのに移行すると、月額費用は下がらず、運用の学習コストだけが増えます。BigQueryは毎月1TiBのクエリ処理と10GiBのストレージが無料枠として用意されているため、少量なら費用は抑えられますが、費用の話と、移行に要する人員の話は別です。既存基盤で回っているものを動かす理由が「クラウドだから」しかないなら、着手しない判断が正しい。

権限設計を後回しにしたまま本番へ載せる失敗の型と手戻りの規模

最も多い失敗が、PoCの権限設定のまま本番データを載せてしまう型です。PoCでは開発メンバー全員にデータセットの編集権限を付けがちで、そのまま本番の契約データを入れると、内部監査で差し戻されます。

手戻りの規模は小さくありません。権限を作り直すだけでなく、その期間に誰が何を参照したかの説明を求められ、ログが取れていなければ経緯の再構成から始まります。防ぐ手立ては単純で、本番データを入れる前に、サービスアカウントの用途分離、データセット単位の権限、監査ログの出力先の3点を確認する工程を挟むことです。所要は数日で、後から作り直す工数とは桁が違います。

金融でBigQueryを採用してよい3つの条件と判断を分ける数値

採用してよい条件を数値で示します。第一に、分析対象のデータ量が3TBを超えているか、年内に超える見込みがあること。第二に、日次より短い粒度で照会したい業務が1つ以上あること。第三に、データの持ち出し範囲について、勘定系の正本を残す前提で社内の合意が取れていること。

3つ揃えば、規制対応の設定は先ほどの3領域（鍵・権限・ログ）に収まり、数か月で本番に載せられます。2つしか揃わないなら、揃うまで待つほうが総コストは下がりました。1つしか該当しない段階での着手は、費用対効果が見えないまま基盤だけが残ります。他業種での構成の作り方は製造業でのデータ集約と連携方式の設計例が参考になります。

よくある質問

金融・保険でBigQueryを検討する際に、稟議や社内説明の場で繰り返し出る質問を5つ挙げます。

金融機関がBigQueryを使うとFISCの基準に対応できますか？

製品を選べば対応が完了する性質のものではありません。FISC安全対策基準（2024年3月発行の第12版が2026年8月時点の最新）は、金融機関側の管理体制を含めた基準です。BigQuery側で用意されているのは、暗号鍵の自社管理（CMEK）、列レベル・行レベルのアクセス制御、監査ログ、VPC Service Controlsによる境界設定といった機能で、これらを内部規程に合わせて設定し、運用の担当と手順を定めることで基準への対応を組み立てます。Jagu’e’r金融分科会が公開した対応セキュリティリファレンスは、その対応づけの出発点として使えます。

BigQueryとSnowflake・Databricksは金融でどう使い分けますか？

選定の分かれ目は、既に使っているクラウドと、機械学習の比重です。Google Cloudを既に使っており、分析の主目的がSQLでの集計と照会なら、BigQueryが運用の追加負担が小さくなります。複数クラウドにデータが分散していて、どこからでも同じ基盤で扱いたい要件が強ければSnowflake、リスク計測や不正検知のモデル開発が主目的でノートブック中心の運用ならDatabricksが候補です。金融では既存の閉域網や委託先との接続要件が選定を左右するため、機能比較の前に接続経路の実現性を確認してください。

保険基幹系とBigQueryをAPI連携する場合、何から設定しますか？

サービスアカウントの用途分離から始めます。読み取り専用と書き込み用を分け、それぞれに付与するデータセットの範囲を限定する設計です。次に基幹系側のAPIの同時接続数とレート制限を確認し、呼び出し側で上限を下回るよう絞ります。最後に再試行の設計で、指数バックオフと上限回数、超過時の通知先を決めます。この3つを決めてから接続テストに入ると、権限の作り直しが発生しません。

金融でBigQueryを入れると月額はどれくらいかかりますか？

データ量とクエリのスキャン量で決まるため一律には出せませんが、費用の構造は把握できます。毎月1TiBのクエリ処理と10GiBのストレージが無料枠として設定されており、検証段階はこの範囲に収まる案件が多くあります。本番で費用が伸びる要因は、ダッシュボードの自動更新によるスキャン量の増加と、パーティションを指定しないクエリです。日付パーティションと必要な列だけの指定を徹底すると、同じ分析でもスキャン量は大きく下がります。

個人情報を含む顧客データをBigQueryに載せてよいですか？

載せられますが、載せる列を絞る前提で設計してください。氏名・住所・連絡先といった直接の識別子は分析に不要な場合が多く、契約IDや顧客IDと属性コードだけを載せる構成にすれば、社内の合意形成が短く済みます。載せる必要がある場合は、列レベルのアクセス制御と動的なデータマスキングを組み合わせ、参照できる担当者を限定したうえで、参照ログの保存先と期間を先に決めます。

関連記事

• BigQueryとは：サーバーレスDWHの仕組み・料金・できないことと採用判断：製品としての仕組みと料金体系、機能上の制約を確認したい場合はこちら
• BigQuery導入の手順と体制｜PoCから本番移行までと外注の判断：業種を問わない導入の進め方と、社内体制・外注範囲の決め方をまとめています
• BigQueryの事例4類型｜成果が出た条件と自社導入の判断軸：他社の導入が成果につながった条件を類型で整理しています
• BigQueryを製造業で使う構成｜設備ログと生産実績の集約・連携方式・費用：別業種でのデータ集約とテーブル構成の具体例です
• 金融システム開発：勘定系・保険基幹系との連携を含む開発の相談先です