メインフレームからAI駆動の成熟へ：Veriskのデータ近代化の歩み

最終編集日時：2026年10月26日

dbt Summit 2026の分科会において、Verisk Analyticsの引受データチームに所属するデータエンジニアであるケイシー・シュウェーゲル氏、ヴィジャイ・シン氏、マテウシュ・ゲカ氏は、レガシーデータスタックを引き継いだ経験のある方なら耳馴染みのある、4段階からなるモダナイゼーションのストーリーを語りました。それは、一見うまく機能しているように見えても、やがてスケールしなくなり、その問題を解決するために新たな対策を講じた結果、さらに別の課題が生じる——という流れです。

Veriskは、数百社もの保険会社から得た保険に関する経験データを統合しており、各社はそれぞれ独自のシステムを、千ページに及ぶPDFマニュアルで定められた一定幅の固定フォーマットへと変換しています。このプロセスについて、チームは淡々と、ほとんど誤りが生じないと認めています。その出力は、歴史的データをもとに州規制当局へ提出される価格設定に関する意思決定へと結びつく、要求の厳しいデータ利用者であるアクチュアリーに供給されます。つまり、この処理フローにおいて、誤った数値が混入する余地は一切ないのです。

データ自体は、各テーブルに数十億行と数百列を備えた形で保存されています。数十年にわたり、それはメインフレーム上で稼働してきました。「メインフレームに問題はありませんでした」とケイシー氏は述べました。

「それは数十年にわたる引受規則を保持しており、その役割を非常に優れた形で果たしていました。」しかし、ある数値が実際にどこから来たのか、何十年にもわたる文書化されていないロジックのどこかに埋もれている料率算定規則を辿ろうとすると、まるでブラックボックスを見つめるような状況になり、チーム自身のルールはこうでした：作業が失敗したら、決して手を加えない。

チームがクラウドへと移行した最初の一手として、SnowflakeとJupyterノートブックを組み合わせたことで、かつてメインフレームのジョブストリームに埋もれていたビジネスロジックにバージョン管理と可視性がもたらされました。四半期ごとのバッチ処理にはうまく機能しましたが、ノートブックは日常的な本番運用の自動化を想定して設計されていませんでした。次のステップでは、ストリームやタスク、動的テーブルといったSnowflakeのネイティブオブジェクトを直接活用することで、毎日の更新が可能になりましたが、一方で古い課題は新たな問題へと置き換わりました。すなわち、数百もの孤立したタスクやテーブルを手作業で調整しなければならず、環境間でコードをクリーンに昇格させる手段がなかったのです。

テーブルとビューはデータとロジックを格納し、マテリアライズドビューは最も重いデータセットの処理を高速化しました。ストリームとタスクはcronスケジュールに基づいて変更データを捕捉し、動的テーブルはターゲットの遅延に応じて自動的に更新されました。これらは機能していましたが、保守には数百もの個々のオブジェクトを手作業で逐一管理する必要がありました。上流のスキーマ変更やタスクの失敗が発生すると、クエリ履歴を1件ずつ丹念に確認しなければなりませんでした。

dbtこそが、それらすべてをついに統合した存在である：ピアレビューによるバージョン管理されたモデル、古くなったWikiに頼るのではなく自己文書化されるリネージ、そして不正なデータが保険数理担当者に届く前にパイプラインを停止させ、報告書を静かに破損させるのではなく事前に検知するテスト。Snowflakeでは異なるスキーマ間で同一のテーブル名が許可される一方で、dbtでは各モデル名を一意にする必要があるため、チームは事業部門ごとにプロジェクトを構成し、それぞれの中にステージング層、中間層、マート層を階層的に配置した。さらに、層・ドメイン・オブジェクト名を組み合わせた命名規則を採用することで、名前の衝突を防いでいる。カスタムマクロが各モデルのファイルパスに含まれるマーカーを読み取り、そのモデルをどのスキーマに配置すべきかを自動的に解決する。開発環境では開発者の個人スキーマに、本番環境では共有スキーマに配置され、手動でのエイリアス設定は不要である。

dbt導入前、チームは3つの異なる信頼できる情報源との間で常に齟齬を抱えていました。Snowflakeに直接パッチが適用される本番ロジック、Gitに保管されていて遅れがちなソースコード、そしてConfluenceに存在して数か月も前に現実を反映しなくなってしまったドキュメントです。dbtのドキュメントブロックにより、これらが1つのMarkdownファイルに一度記述された説明へと統合され、必要な場所でどこでも参照されるようになります。そのため、一箇所で更新すれば自動的に全箇所が最新状態になり、バージョン管理され、コードと並行してレビューされるため、コードから乖離することがなくなります。

マテウシュが実装の過程を説明する際に述べたように、「この講演は実はdbtそのものについてというよりも、dbtを導入した後に起こる変化についてのものです。」

その基盤が、現在チームによるAIの活用を可能にしています。カスタムのdbt WizardスキルでDAG全体にドキュメントを自動的に展開し、プロジェクトコンテキストを活用してより優れたAI生成SQLを取得し、プルリクエストに対して標準を自動で強制適用し、さらにジョブログとクエリ履歴を相互参照することでデバッグを迅速化しています。最初の対象となったのはドキュメントでした。専用のdbt Wizardスキルとdoc blocksパターンを組み合わせることで、開発者が初期のソース記述を入力した時点で、手動でコピー＆ペーストするのではなく、列の説明がDAG全体に自動的に伝播されるようになりました。

同じく豊かなコンテキスト層により、リクエストを単なる生のSQLの仕組みではなくビジネス上の文脈で表現できるため、AI支援型のモデル開発はより信頼性が高まります。また、個別のスキルによってチーム独自の標準や命名規則、必須のYAMLフィールドが定義されるため、他の誰かが確認する前に、開発者は自らのプルリクエストに対してそれを実行して検証することが可能です。

チームは、いずれも人間が適切に関与したままであることに十分注意を払っています。「AIはパターンと文脈に基づいて発展していくものであり、私たちのドキュメントや命名規則、リネージ、標準が整備されるほど、AIが活用できる文脈も増えていきます」とケイシー氏は述べました。

この移行における人間側の課題として、GitやSQLの知識がないスタッフのオンボーディングが挙げられました。チームの率直な答えは、方向性がますます技術主導へと進むなかで、一部の人々が変革を先導し、他の全員を巻き込んでいくしかないということでした。一方、データ面では未解決の課題としてスケールが挙げられます。アクチュアリーたちは、10年以上にわたる完全に最新化された履歴データを求めていますが、段階的なモデルでは依然としてその要請に追いついていません。

dbt Summit 2026の基調講演および分科会をすべてオンデマンドで視聴できます。dbt Summit 2026をオンデマンドで視聴する →

dbtの利用を開始する

実際にスケールするデータインフラを構築しているアナリティクスエンジニアの仲間に加わりましょう。

dbt Wizard CLI をインストールする

分析エンジニアリング専用に設計されたエージェントで、すぐに使い始めることができます。どのツールを呼び出すべきか、どのコンテキストを取得すべきかを把握し、あなたに結果を提示する前に自らの作業を確認します。

情報源

dbt