７月29日、「エンタメ業界のデータエンジニアリング最前線」（共催：データ横丁、マイナビ）の第2回が開催された。このイベントは、エンタメ業界に特化して、データ活用のための基盤構築のポイントや現場の工夫などを共有するものだ。

今回はゲーム編として、セガ JA Studios 第2事業本部　戦略企画部 データエンジニアリングセクション 槌屋琢氏と、ディー・エヌ・エー（DeNA） IT本部 AI・データ戦略統括部 データ基盤部 ゲームエンタメグループ 笠西哲氏が登壇し、自社のデータ基盤の構築と運用の効率化について説明。司会進行は吉村武氏が務めた。

セガのDatabricksを活用したデータ基盤構築

槌屋氏は、「セガのKPI可視化を支えるデータ基盤の構築と運用」と題して、データインテリジェンスプラットフォームである「Databricks」を活用したコスト削減とデータ活用の効率化について説明した。

  • セガ JA Studios 第2事業本部　戦略企画部 データエンジニアリングセクション 槌屋琢氏

データ基盤における3つの課題

同社では、「Apollo」というKPI基盤を構築しており、各システムのログデータをAWSに送り、Lambdaでデータ加工してS3に保存している。データ集計はRedshiftを使い、BIや可視化の部分はQlikや独自のダッシュボードを使っていた。ただ、機械学習の環境が統合されていない、ビッグデータ活用の自由度が低い、Redshiftのリソース余り問題という課題を抱えていたという。

「機械学習環境が用意されていなかったので、各自環境をつくって機械学習を行っていました。ビッグデータ活用の自由度が低いという点では、データ取得にエンジニアの手が必要になるという状況でした。また、システム課題としてRedshiftのリソース余り問題がありました。実は導入当時、Redshiftサーバレスが正式リリース前だったため、バッチ集計のピークにRedshiftの性能を合わせてしまったのです。その結果、リソースを使っていないときにはコストの無駄が発生していました」（槌屋氏）

そこで、同社はDatabricksを導入。S3のデータを保存するところまでは同じ流れだが、データの集計をDatabricksで行うようにした。これにより、集計にかかるリソースが動的に変化するようになり、必要なときに必要な分だけリソースを割けるため、コストカットできるようになった。

また、アナリストが自由にテーブルを作成し、分析がより迅速、細やかに行うことが可能になったほか、機械学習環境もDatabricksに統合した。

さらに、新機能としてDataFederation機能がリリースされ、他の地域で利用しているDatabricksとの連携のほか、SnowflakeやBigQueryとの連携も可能になったそうだ。

「必要なときに必要なデータにアクセスできる環境が構築できるようになりました」（槌屋氏）

Databricks導入の効果

セガでは、Databricksの導入により、時間とコストの削減に成功した。従来はデータをS3に貯めていたため、送り元と送り先で二重でログを保存していた。Databricks導入後は、各システムに直接アクセスするようになったため、重複していたS3のコストをカット。また集計の所要時間が約50%削減され、集計にかかっていたコストも約70%になった。

そして、もっとも大きな効果は、アナリストの作業効率が大幅にアップしたことだと槌屋氏は話す。

Databricksの導入前は、アナリストがほしい集計データをデータエンジニアに依頼。その依頼を受けて、データエンジニアがアナリストと擦り合わせながらテーブル設計をし、SQLの作成、データの整形やETLの処理の実装などを行っていた。

Databricksの導入後は、アナリスト専用のカタログを用意したため、自由にテーブルを作成し、ノートブックで集計ができるようになった。これによりエンジニアはスキーマーのアクセス制御や技術支援、新機能の検証や導入など、本来の業務に工数を割けるようになったほか、アナリストはアイデアを思いついたときに、すぐ検証ができる環境が整った。

また、エンジニアとアナリストの協業体制が強化され、分析のスピードが飛躍的にアップしたそうだ。

今後の展開

セガでは今後、データメッシュをさらに加速し、関連会社のデータも接続したデータハブとして、セガに多様な関わるデータを扱っていくことを考えているという。

そのために、技術面ではリリースされたばかりのMCP＋、Genie＋、Agent Bricksを導入し、Databricks内に保有しているデータに問い合わせて洞察を得る仕組みを検証している。

ビジネス面では、社内に点在するデータの整理、リスト化を行い、グループ全体でセガ全体のデータを扱っていくかたちを目指していく。

DeNAのデータ基盤開発スピード向上に向けた取り組み

続いて登壇した笠西氏は、「AIオールインで加速する! DeNAのデータ基盤開発スピード向上に向けた取り組み」と題して、データ基盤開発の効率化への取り組みについて紹介した。

同氏が所属するデータ基盤部は、全社横断でデータ基盤や機械学習基盤を開発・運用する組織で、「チームトポロジー」という考え方を導入し、事業ドメインごとにチームを細分化して、データ利活用支援、ML利活用支援を行っている。

DeNAは数多くのゲームタイトルをリリースしているが、ゲームタイトルごとに要件が異なるため、個別にデータ基盤を構築しているという。そのため、データ基盤の数が多すぎるという点が課題となり、環境構築の効率化が必須となっていた。そこで同社は、開発効率化に向けた取り組みを進めている。

  • ディー・エヌ・エー（DeNA） IT本部 AI・データ戦略統括部 データ基盤部 ゲームエンタメグループ 笠西哲氏

開発環境のテンプレート化

開発効率化に向けた取り組みの1つが開発環境のテンプレート化だ。ゲームタイトルごとにデータ基盤の要件は異なるものの、同じデータ基盤であるため、共通化できる部分も多い。そこで、開発環境のテンプレートを作成して、複数の案件で導入するかたちにした。

開発環境のテンプレートでは、全体のジョブの実行スケジュールを管理するオーケストレーションツールとして「Cloud Composer」を利用し、実際のデータ取り込み処理、変換処理に関しては、Google Cloudの「Batch」を利用している。これにより、インフラが整備されている状態で開発を始められるため、Pythonやdbt Coreで案件固有の処理を書くだけでデータ基盤を構築でき、開発スピードが向上したという。

また、テンプレート化は、属人化の解消にもつながった。

「各ゲームタイトルのアーキテクチャが共通化されることによって、新規メンバーがデータ基盤の開発運用に関わるときの認知負荷が低下しました。これによって、属人化の回避にも貢献していると考えています」（笠西氏）

立ち上げチェックリストの作成

同社は、開発環境のテンプレート化とともに、共通で満たすべき項目を網羅した「データ基盤立ち上げチェックリスト」の作成にも取り組んだ。チェックリストは担当者がやるべきことを明確化し、考慮漏れによる不要な手戻りを防ぐ目的で作成した。

「例えば、『KGIについてプロジェクト全体で合意してフィックスできているか』という項目は、一見データ基盤の実装には何の関係ない項目です。しかし、これがうやむやのままプロジェクトを進めると、そもそも分析したい要件が根本からひっくり返って、分析基盤の実装や設計も大きな影響を受けることが考えられます。そのため、見過ごすと手戻りのリスクが大きいと判断し、チェックリストに入れています」（笠西氏）

生成AIの活用

開発効率化に向けた取り組みの2つ目は、生成AIの活用だ。ゲームタイトルの情報は秘匿性が高いということもあり、生成AIの活用は昨年まで、他ドメインと比較してやや遅れていたが、今年2月にDeNAが「AIオールイン」戦略を掲げて以降、ゲームドメインでも生成AIを積極的に活用できる環境が整ってきた。

生成AIを活用したことで、ソースデータ（ログ）設計の効率化を成し得た。すでにログ設計済みの機能で生成AIにログ設計をさせることにチャレンジしたところ、シンプルなプロンプトを利用した場合でも、人間が実際に設計したログに近い出力が得られたという。

そこで、実際に新規追加される画面でログ設計を試したところ、必要なログの候補が出力され、出された方法をデータエンジニア・アナリストが選定するだけでログ設計が完了した。この例を通じて、必要なコンテクストが少ないタスクに関しては、「生成AIとの親和性が高そうだという所感が得られた」と笠西氏は話した。

また、マート設計においても、追加される機能の仕様書を渡して生成AIに考えてもらった。分析項目の網羅という点では厳しかったが、必要な分析項目の抜け漏れを防ぐという意味では生成AIは機能したという。

これを受けて同氏は、まず人間がきちんと考えたうえで生成AIを使って分析観点の抜け漏れをチェックし、マート設計に活用するというのが有効な使い方だと判断したそうだ。

さらに、ログの追加に伴う既存のマートへの影響範囲の推定も、生成AIを利用して行ったが、影響範囲の抜け漏れを洗い出すことができた。

「マート設計を一から生成AIに任せるというのはまだ難しいかもしれないというのが現時点での所感です。理由としては、マート設計は既存のマートの設計思想や、背後の中間集計との整合性をとる必要があり、ログ設計と比較して必要なコンテクストが多いという点があります」（笠西氏）

今後の展開

DeNAでは今後、他のデータ基盤構築フェーズの効率化や、生成AIが理解しやすいかたちのデータとは何かという検討も進めていく方針だ。

その理由を笠西氏は、「今後は、人間よりもAIのほうがSQLを書く機会が増えるでしょう。人間よりもむしろAIが理解しやすいかたちのデータを提供することが、データエンジニアに今後、求められるのではないか」と語った。

  • 司会進行の吉村武氏