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

冒頭では、当日の司会進行を務めた吉村武氏が全5回を予定する本イベントの趣旨を説明。第1回のテーマは「施設」、以降「ゲーム」「書籍」「動画」「CGM」というテーマを予定していると話した。

  • 司会進行の吉村武氏

今回は、GENDA IT戦略部 データエンジニア課 マネージャーの松村聡士氏と、バンダイナムコセブンズ テクノロジーイノベーション部 新規サービス開発課 プロダクト研究チーム チームリーダー ソフトウェアエンジニアの山口大貴氏が登壇。そのほか、スポンサーセッション、「楽市楽座」と題した懇親会が催された。

データエンジニア1人体制からスタート

イベントの前半に登壇した松村氏はまず、GENDAについて紹介した。同社はエンタメ領域でのM&Aを成長戦略の中心に置く純粋持株会社だが、グループ企業それぞれの事業はアミューズメント施設、カラオケ、コンテンツ&プロモーション、ツーリズム、映画配給などさまざまだ。

データ基盤については、2022年当初、アミューズメント事業とゲームセンターのGiGOが対象だったが、現在はM&AによりGENDAを含めて7社、業種としてはゲームセンター事業、カラオケ事業、外貨両替事業、フードアンドビジネスなど、多岐にわたるデータが集約されている状態だという。

  • 司会進行のGENDA IT戦略部 データエンジニア課 マネージャーの松村聡士氏

同氏はGENDAのデータ基盤の成長を4つのフェーズで説明した。

第1フェーズはデータエンジニアが1人で「スピード最優先」だった2021年～2023年夏ごろだ。データウェアハウスは主にSnowflakeを使用し、リアルタイム性が求められるパイプラインにはAWSのDNS、それ以外の小さなパイプライン処理はAWS Lambdaでコンパクトに処理していた。

しかし、この体制には課題があった。

「パイプラインは案件ごと、それぞれのパイプラインごとに異なる手法でつくられており、ジョブスケジューリングは統一されていませんでした。CI/CDもなく、ウェブコンソールから直接デプロイするといった手作業的な運用が続いていました」（松村氏）

課題を解決しながら進めたデータ基盤の構築

第2フェーズでは、第1フェーズで浮かび上がった課題に対し、具体的な解決策を進めていった。

体制は、複数人で運用するかたちに整えていった。ワークフロー管理ではAmazon MWAA（Managed Workflows for Apache Airflow）、Terraform、GitHub Actionsなどを導入。データカタログはStreamlitで自社のカタログを作成した。

しかしまだ大きな課題が残っていた。Streamlitを使った自作カタログは拡張性に乏しく、自動管理ができないなどの問題があった。分析基盤についても、高度な分析、AI活用、MLOpsの実施などに対応できるものが「必要だと感じた」と松村氏は振り返った。加えて、BIツールにも課題があった。それまで使っていたBIツールは運用コストが高く、集計基準が統一されていないなどアナリストの要望に応えきれなくなっていたのだ。

そこで第3フェーズではさらなる改善を行った。カタログ機能の限界については、自作カタログからOpenMetadataを導入して拡張性やメタデータ活用を広げた。分析基盤の不足については、Databricksを導入して対応、MLOpsの環境や、アナリストが自由にSQLを使ったり、AIを組み合わせた分析ができたりする環境を目指した。BIツールはアナリストが精通していたLookerに置き換えることにした。

こうして現在、第4フェーズに至っているが、同氏は「基盤が複雑化したことから新しい課題が出てきている」と言い、主なものとして「ツール・サービスの乱立」「権限・ガバナンス設計の複雑化」「AIフレンドリーな基盤への対応」の3つを挙げた。

例えば、SnowflakeとDatabricksと併用しているため、基盤ごとに権限の設計管理などの作業が生じており、管理が難しくなっている点がある。

メインの基盤はSnowflakeからDatabricksへ

今後の展望として松村氏は「シンプル化、パイプラインの標準化、ガバナンスの強化、マルチクラウド・マルチDWH最適化などを図っていく」と述べた。

データ基盤のメインはDatabricksにし、データパイプラインの加工先となるデータレイクの役割を持たせる。パイプラインなどは順次Databricksへの移行を進め、「一貫したパイプラインから最終的なBIの部分までカバーしていきたい」と話す。社内ユーザーがすぐに使えるBI環境、データサイエンティスト向けのサイエンス環境もDatabricksを活用する計画だ。LookerとSnowflakeは“サブ的な位置付け”で使用する予定だという。

このように次のフェーズに向けた取り組み課題を述べた後、同氏は今後大切にしたいポイントとして、「よりシンプルに設計する」「AI活用を前提に進化させる」「誰でも使いやすい基盤を目指す」「誰でも使いやすい基盤を目指す」「課題解決と改善を継続する」という5つを挙げた。これらを指針に、「環境やニーズが変化するなかで柔軟にアップデートを重ねて変化に寄り添い、進化し続ける基盤を構築したい」と決意を語った。

「今後については、Databricksに完全に移行するというよりは、DWHごとの特性を活かして、弊社から見てベストなかたちに、使い分けていく予定です」（松村氏）

特定のキャラクターの顔を自動判別するPoC

後半に登壇したのは、バンダイナムコセブンズの山口氏だ。バンダイナムコセブンズはバンダイナムコグループの一員で、パチンコ・パチスロといった遊技機開発を主軸とする事業会社である。

  • バンダイナムコセブンズ テクノロジーイノベーション部 新規サービス開発課 プロダクト研究チーム チームリーダー ソフトウェアエンジニアの山口大貴氏

同氏によると、遊技機の開発現場では「アニメ50話分、全場面の一覧資料の作成といった要望がよくある」という。場面写資料と言われるものだが、作成は手作業だ。アニメを再生しながらキャプチャを取得し、時間、登場しているキャラクター、セリフなどを記録していく。膨大な作業である。

そこで機械学習を利用してキャラクターを判別することで作業の効率化を図ることにした。機械学習は事前準備を短縮できるなどの理由からAmazon Rekognitionを採用、特定した顔を検出する「Custom Labels」という機能を利用した。PoCではアニメ作品の特定キャラクターを判別することに挑戦した。特定キャラクターの顔を学習データにして、汎用的な機械学習モデルに転移学習させることで、そのキャラクターを判定することに特化した、専用の機械学習モデルを簡単につくるというものだ。

PoC失敗の要因は「認識の違い」「過学習」

しかし、PoCは失敗に終わった。山口氏は大きく2つの失敗要因があったと振り返る。1つ目はコミュニケーションエラー、2つ目は過学習だ。

1つ目のコミュニケーションエラーとは意思決定者との認識の齟齬、つまり技術以外の要因である。意思決定者から伝えられた方針は「特定キャラクターの取りこぼしはNG。そのキャラクターが出ているシーンを見逃したら、ツールとしては使えない」というものだった。これを同氏は「特定のキャラクターを見逃さないこと（再現率）が評価基準」だと理解した。しかし、意思決定者が求めていたのは「特定のキャラクターとその他のキャラクターを間違えないこと（正解率）」だったのだ。見逃しを防げた割合を計算した再現率を指標とした場合、キャラクターの特定ミスがいくつか発生しても問題ではない。しかし、間違えなかった割合を指標とした場合、キャラクターの特定ミスは致命的だ。

2つ目の過学習とは何か。元々今回のPoCでは学習データが少ないため、キャラクターの顔のパターンを多数用意した。これは再現率の改善にはつながったものの、特定ミスの増加も招いた。同氏は検証で利用したアニメ作品に登場する、別のキャラクターと誤検知した例を挙げ、「瞳の形状や目に光が入っているなど作画の癖を判定したのではないか」と話した。

アニメ映像6話分を検証したPoCの結果として、再現率は約90％、正解率は35％だった。

同氏はこの結果から得られた知見として、「少ない学習データでたくさんのパターンを用意すると人物の検知の精度が上がるなど、Custom Labels自体は有用な点がある。だが、キャララクター個別の判別は難しいことが分かった」と語った。

進捗2割での共有が成功につながった

特定キャラクターの顔を自動判別するPoCが失敗に終わった後、山口氏は現場からの聞き取りを行った。そこで聞こえてきたものは「顔の判別ができればベストだが、そもそもの工数が多い」という現場の悲鳴だった。そこで同氏は、シーンの切り替わりを判断することができれば、場面写資料作成の工数が減らせると考えたという。

実はシーンの切り替わりの判定は、「失敗」に終わった最初のPoCで「約2割の進捗で完成していた」（山口氏）そうだが、当時はこれが役に立つとは気が付かなかったのだ。

技術としては、Amazon Rekognitionの「Rekognition Video」という機能を使って実装、API経由で動画を解析し、場面ごとの時間情報を取得した。

こうして完成したのが「NSP-CDK Cut Splitter」だ。Rekognition Video、それに音声を文字に変換するAmazon Transcribeも活用し、映像を場面ごとに自動で分け、サムネイルで一覧にして見ることができる。Amazon Transcribeでセリフも自動で文字起こししており、クリックするとサマリからシーンの詳細が分かる。

成果として、場面写資料の作成にかかる工数を1話あたり2人日だったのが1人日に削減できており、「今回は成功。現場が必要としていた解決策に辿り着いた」と言う同氏は、この経験から得たことを次のように語った。

「認識共有は迅速に、進捗2割で共有することが大切です」（山口氏）