【PR】 NEW! スキル
これまでデータ分析基盤といえば、人間がLookerやTableauなどのBIツールなどを通じてデータを可視化し、意思決定に役立てるためのものだった。しかし今、その在り方が根底から覆る転換期を迎えている。生成AIやAIエージェントが、企業内のデータを直接参照して自律的に動くフェーズへと移行しつつあるからだ。
人が見る基盤から、AIが使う基盤へ。AIによる利用を前提としたデータ基盤は、従来と何が異なり、どのような設計が求められるのか。
解説するのは、Google Cloudのプロフェッショナル集団である株式会社grasysのCloudTech Div. Cloud Development Sec.で、データ分析基盤の設計・構築をリードする上間貫司さん。
AIにデータを正しく扱わせるための「メタデータ整備」や、処理の確実性を担保する「アセット指向」のアプローチなど、日々の構築業務で直面する課題と、その具体的な解決策を聞いた。
株式会社grasys
CloudTech Div.
Cloud Development Sec.
上間貫司さん
オンプレミス環境での開発を中心にエンジニアとしてキャリアをスタート。その後、クラウド技術の発展に将来性と面白さを感じ、クラウド領域への挑戦を決意して株式会社grasysへ入社。入社後はGoogle Cloudを活用したデータ基盤構築へ本格的にシフトし、要件定義などの上流工程からアーキテクチャ設計、運用までを幅広く担当。現在はBigQueryなどを用いたAI活用を見据えたデータ分析基盤の設計・構築やAIアプリケーション開発に携わり、最新技術を取り入れた最適な基盤づくりを推進している
目次
ーーデータを利用する主体が人間からAIに変わることで、基盤構築のアプローチはどう変わるのでしょうか？
極端に言えば、「とりあえずデータをためておく」というアプローチが通用しなくなるんです。
人間が使うのであれば、多少分かりにくいデータでも、担当者が中身を確認したり周囲に聞いたりしながら使えます。それこそ「とりあえずためておく」でも、ある程度は成立していました。
しかし、AI相手だとそうはいきません。AIにBigQueryへのアクセス権だけを渡して、「自由に使ってください」と言っても、それぞれのテーブルが何を表しているのか、どのカラムを使うべきなのかまでは判断できない。データが存在することと、AIが正しく使えることはまったく別の話なんです。
ーーでは、AIが正しくデータを使えるようにするには、何が必要なのでしょうか？
重要なのは、データそのものに「意味」を持たせることです。「このテーブルは何のデータなのか」「このカラムは何を示しているのか」「どの粒度で記録されているのか」といった情報を、メタデータとしてきちんと整備しておくことが欠かせません。
実務レベルで言うと、例えばBigQueryのテーブルやカラムごとに、業務上の意味やデータの粒度、更新条件、利用時の注意点などを記述していきます。加えて、ドメインや環境、データのライフサイクル、品質区分といったラベルを付けておけば、AIエージェントが参照候補を絞り込みやすくなる。機密情報の分類やアクセス制御については、ラベルではなくポリシータグやIAMなどを適切に使い分けるとよいでしょう。
このようにメタデータが整理されていれば、AIは「どのテーブルを見るべきか」「どのカラムを使うべきか」を判断しやすくなります。結果として、的外れなデータ参照や無駄な試行錯誤が減り、回答精度も上がる。不要なクエリやLLMの呼び出しを減らせるので、コストカットも期待できます。
ーーとはいえ、それだけのメタデータを人力で管理し続けるのは大変そうです。
確かに、人が手作業で更新し続ける運用ではいずれ限界が来ます。そのため、CI/CDパイプラインの中に組み込み、スキーマが変更されたらメタデータも強制的に追従させるような「仕組み化」までセットで考える必要がありますね。
また、同じ入力や条件に対して毎回一定の結果を返せるよう、処理をできるだけ「決定論的」にしておくことも重要です。今はAI自身がSQLを柔軟に書けるようになってきていますが、あまりにAI側に自由度を持たせすぎると、処理の確実性が担保できなくなってしまいます。
ーーSQLが書けるからといって、全てをAIの判断に任せるのは危ういと。
そうですね。例えば、「AというテーブルとBというテーブルを結合して」と指示したとします。どんなにAIが書くSQLの精度が上がっても、毎回まったく同じロジックで、100％意図した通りに結合されるとは限りません。
それならば、人間側であらかじめAとBを正しく結合した「ビュー（仮想テーブル）」を用意してあげて、「ここにあるものを使いなさい」と指定した方が確実です。AIに複雑な処理をその都度考えさせるのではなく、人間側で事前に処理を済ませておく。そうすることで、結合ロジックがブレず、同じ条件であれば常に同一の結果が得られる状態を作れます。
このように、AI時代の基盤設計は「AIに任せる部分」と「人間が事前に準備しておく部分」の境界線をどう引き、どこまでお膳立てしてあげられるかが非常に重要だと思います。
ーーデータ基盤は一度構築して終わりではなく、どのように継続して運用していくかも重要です。運用フェーズにおいては、何がポイントになりますか？
問題が起きたときに素早く原因を特定し、改修やリカバリーができる構造にしておくことです。急に元データの形式が変わってしまったり、これまで自動で投げられていたデータをこちらから取りに行かなければならなくなったりするケースはよくあります。
この課題を解決する上で、grasysでは「メダリオンアーキテクチャ」を採用することが多いです。これは、データを「ブロンズレイヤー（生データ）」「シルバーレイヤー（加工・クレンジング済データ）」「ゴールドレイヤー（分析やAI活用の目的に応じて整えたデータ）」の3層に分ける設計手法です。
データをきれいに整理するという意味合いも当然あるのですが、運用面において一番大きいのは「障害の切り分け」が圧倒的にしやすくなる点です。
ーー具体的には、どのように？
例えば、最終的なゴールであるゴールドレイヤーでうまくデータが生成されていなかったとします。もしレイヤーを分けずに一連の処理を一体化していると、最初のデータ取り込み時でつまずいたのか、途中の加工段階でおかしくなったのか、問題の発生箇所を特定するのに非常に時間がかかってしまいます。
ただ、レイヤーを明確に分け、各レイヤーの処理結果やデータ品質を監視する構造にしておけば、「ブロンズからシルバーに持っていく途中の処理で失敗しているな」といった形で、瞬時に障害箇所を特定できます。
途中で処理が失敗したときに、また一番最初の生データの取り込みからやり直すのは非効率です。もし、ブロンズとシルバーのデータが正常に生成されていて、ゴールドへ持っていく処理だけが失敗したのであれば、そこだけを再実行すればいい。
ーー再処理の範囲や影響を最小限に抑えるための構造としても、メダリオンアーキテクチャは非常に理にかなっていると。
ええ。ただ、概念としては理解しやすく有効なアプローチなのですが、実際の業務となると若干のやりづらさを感じる場面もあります。
というのも、「このデータって、シルバーだっけ？ ゴールドだっけ？」と、境界線が曖昧になってしまいがちなんです。
ーーレイヤーをきれいに分けたはずなのに、なぜ曖昧になってしまうのですか？
一番の原因としては、最終的な「アウトプットの形」が確定していない状態で開発をスタートさせてしまうことにあります。
本来であれば、お客さまがLookerやTableauといったBIツールで「こういう画面を見たい」「こういう数字を出したい」というゴールがあって、そこから逆算してレイヤーを定義していくべきです。しかし、そのゴールが固まりきらないまま、とりあえずデータ処理の流れだけで開発を進めてしまうケースは少なくありません。
そうなると、「今作っているこのデータは、最終的にそのまま見せるデータ（ゴールド）でいいんだっけ？ それとももう一段階加工（シルバー）を挟むんだっけ？」と、着地点が迷子になってしまうんですよね。
ーーその課題はどのように対応するのですか？
最終的に人間がBIツールでデータを見る用途であれば、まずはお客さまと一緒にBI画面や指標のプロトタイプを早い段階で作ることが重要です。実際の画面を確認しながら、「どの数字を、誰が、どのような判断に使うのか」を徹底的にすり合わせていきます。
「この画面にはこういうデータが欲しい」といった暫定的なものでも、アウトプットのイメージさえ共有できれば、それを出すためにはどういうデータ（ゴールドレイヤー）が必要で、そのためにどんなクレンジング（シルバーレイヤー）をして、元のデータ（ブロンズレイヤー）からどう引っ張ってくるか、と上流に向かって逆算して設計できます。
目的に応じてやりたいことを明確化し、そこからブレずに設計の筋を通していく。それこそが、データエンジニアの腕の見せ所だと思っています。
ーーレイヤーを分けてデータを加工していくとなると、一連の処理をどう連携・管理していくかが次の課題になりそうです。
そこで重要になってくるのが「オーケストレーター」です。データパイプライン全体を管理して、「どの処理をどの順番で実行するか」「失敗したときにどうするか」を制御するツールですね。
私たちのチームでも『Dagster』というオーケストレーションツールを導入しています。
ーー数あるツールの中で、なぜ『Dagster』を採用したのですか？
『Airflow』などの従来のオーケストレーションツールは、一般的に「タスク指向」と言われるように、タスクの実行順序を定義して、処理同士をどうつなげるかを中心に発展してきました。
一方で『Dagster』は「アセット指向」と呼ばれる設計思想で構築されています。処理そのものではなく、データパイプラインの各段階で生成される「データ（アセット）」を中心に据えて、データ間の依存関係をつないでいく考え方ですね。
この「アセット指向」が、先ほどお話しした「メダリオンアーキテクチャ」と非常に親和性が高い。それぞれのレイヤーで「何のデータ（成果物）が生成されるべきか」が明確になるため、私たちが理想とする設計思想に合致しているんですよね。
現在は『Dagster』の最適な構成に向けた検証を進めているところです。
ーー具体的にどのような検証をされているのですか？
『Dagster』の構成を、「継続的な稼働が必要な制御系」と「パイプライン実行時にだけ起動する処理系」に分けて、それぞれをサーバーレス環境で動かす構成を検証しています。
具体的には、Web UIを提供するDagster webserverをCloud Runサービスに、スケジュール管理など継続稼働が必要なDagster daemonをCloud Runワーカープールに配置します。そして、パイプラインの実行処理はCloud Runジョブとして必要なときにだけ起動させる形です。
基盤となるサーバーの構築や管理を不要にしつつ、実行系のリソースを必要なときだけ起動することで、システム全体のコストを最適化するのが狙いです。
オーケストレーションツールは、その性質上どうしても「常に処理を待ち受ける」必要があります。シンプルに考えればVM（仮想マシン）を立てて常時稼働させるのが一番手っ取り早いのですが、最近はお客さまもクラウドの利用コストを非常にシビアに見られています。VMを立てっぱなしにすれば、当然使っていない時間もコストが跳ね上がってしまいますよね。
お客さまにとって理想なのは、必要なときにだけリソースを利用して、その分だけコストが発生する状態です。そのため、サーバーレス環境を利用して、待機コストを最小限に抑えつつ『Dagster』の恩恵をどう引き出すか。そこを探りながら検証しているところです。
ーーツールが進化し、作業がどんどん効率化されていく中で、今後人間のデータエンジニアは一体何を担うことになるのでしょうか。
「そもそもお客さまは何を実現したいのか」「そのためにはどのデータが必要なのか」を言語化する要件定義や、予算や目的に応じて最適なシステムを組み立てる「技術選定・全体設計」の部分は、人間が責任を持って担うべき領域として残り続けるはずです。
AIが生成したクエリやパイプラインが本当に業務に合っているかを見極め、さまざまなツールを組み合わせて最適な基盤を描く。それこそが、これからのデータエンジニアに求められる本質的な役割だと思います。
ーーその全体設計において、ツールや技術を選ぶ際に意識されていることはありますか？
一番は「エンジニアのリソースをどこに集中させるか」ですね。例えば、データ分析基盤の中核となるツールをフラットに選定するとき、私たちはGoogle Cloudの「BigQuery」を第一候補に挙げることが多いんです。
パフォーマンスの高さはもちろんですが、最大の理由はフルマネージドで「インフラ管理の手間がない」こと。サーバーを立てて管理する“お守り業務”から解放されれば、その分の時間を「お客さまの課題解決」や「データ構造の設計」といった、人間にしかできない業務に投下できます。
実際、メインシステムでAWSを使っているお客さまでも、「データ基盤だけはBigQueryで整えたい」と、AWSからデータを流す構成をとるケースもあるほどです。
ーーそうした技術選定の引き出しを、上間さんはどのように身に付けてこられたのですか？
知識としてインプットするだけでなく、やはり「最終的にどんなデータ（アセット）が必要なのか」を現場で泥臭く考え続ける中で、視点が養われてきたと感じています。
実は私自身、grasysに入る前はクラウド自体が未経験で、ずっとオンプレミス環境でプログラムを書いていました。当時はどうしても「どう処理を動かすか」ばかり考えていたんです。
ですが、grasysに入社して「AI活用を見据えた基盤」に携わるようになってからは、考え方が大きく変わりました。AIに意味を理解させるためのメタデータ整備や、今回お話しした『Dagster』のような「アセット指向」の考え方に触れ、「処理」ではなく「データそのものの価値」を中心にシステムを逆算して設計するようになったんです。
単に言われたシステムを作るのではなく、「AIが使うならどういう形がベストか」を自分たちで探求し、お客さまと伴走しながら最適な形へと組み上げていく。そのプロセスにこそ、これからの時代におけるデータエンジニアの本当の面白さがあると感じています。
＞＞grasysの採用情報はこちら
撮影／桑原美樹 取材・文／今中康達（編集部）
タグ
