■ 1. イベント概要
- Data Engineering Study第35回 非構造化データの活用事例
- 登壇企業はチューリング、レイヤーX、Vポイントマーケティングの3社
- 現代のデータの約80%を占める非構造化データ（画像・動画・テキスト・書類等）をビジネス価値に変える実践知を共有
■ 2. セッション1: チューリング — 自動運転動画のセマンティック検索システム
- 課題:
- チューリングは数万時間規模の運転動画を保有するが、映像内容を元にした検索手段がなかった
- 検索可能な条件は日時・車両ID・地図情報のみで、「交差点で歩行者が横断している」などのシーン検索が事実上不可能
- データが増えるほど問題が深刻化し、複数チームから要望が発生
- 主な用途: シナリオテストの拡充、学習データの管理、モデルの挙動分析
- コア技術:
- NVIDIAの「Cosmos Embed 1」（16億パラメータのビデオ・テキストジョイントエンベディングモデル）を採用
- 動画とテキストを同じベクトル空間に射影し、物理世界（自動運転・ロボット）のデータに特化
- 8倍以上のパラメータを持つQwen3-VLと比較したが、自動運転領域ではCosmos Embed 1が優位
- アーキテクチャ（4パート構成）:
- フレーム画像の抽出: 映像デコードとエンベディング生成を分離し、将来のモデル切り替え時の再処理を回避
- エンベディングの計算: オンプレGPUクラスターで毎日バッチ処理（AWSはコスト高のため）
- テキストとベクトルの検索: DatabricksのAuto LoaderとDLTにより、エンベディングのS3アップロードを契機にインデックスを自動構築
- テキスト検索用Lambda: CPUのみで数ミリ秒応答、Provisioned Concurrencyでコールドスタートを数秒以内に抑制
- 学びとコスト:
- セマンティック検索だけでなく、SQL的な絞り込みとのハイブリッド検索が重要
- DatabricksベクターサーチはJOINが不可でメタデータ追加のたびにインデックス再作成が必要という制限あり
- バッチ処理はオンプレのためコストほぼゼロ、Databricksベクターサーチエンドポイントは月数千〜7,000円程度
- POCに1週間、本番実装に1週間という短期間でリリース
■ 3. セッション2: レイヤーX — エスカレーション効率化エージェント「ラムジー」
- 背景:
- BtoBのバックオフィスSaaSでお客様からのエスカレーション対応がエンジニアの開発業務を圧迫
- 調査内容が多岐にわたるため、AIによる自動化をエンジニアギルドで検討
- システム構成:
- SlackをインターフェイスとしてAIエージェント（AWS上）が調査し、結果をStreamlit（Snowflake上）のURLで返す
- 調査フロー: 仕様・ソースコード・アプリケーションデータ・過去の調査記録の確認をAIが代替
- Snowflakeエコシステムの活用:
- Cortex Analyst: アプリケーションDBのデータをSnowflakeに連携し、セマンティックビューを定義することで自然言語でのデータ照会を実現
- セマンティックビューはAIエージェントが仕様書・スキーマ・ソースコードから自動生成
- 分析用（集計重視）とは別に調査用（IDによる絞り込み重視）のセマンティックビューを構築
- Cortex Search: ZendeskのデータをSnowflakeに連携し、ハイブリッド検索（キーワード＋ベクトル）で過去の類似問い合わせを検索
- デフォルトモデルは英語・512トークン制限のため、多言語対応の大容量モデルに切り替え
- セキュリティとガードレール:
- Cortex Agentの外部Webブラウザ検索ツールをオフに設定し、外部データ送信を制御
- 出力をSnowflakeのマネージドステージに保存してStreamlitでレンダリングし、権限管理をSnowflakeに一元化
- 実行SQLをレスポンスに含めてエージェントの調査過程を透明化
- SQLのWHERE句をフックしてテナントフィルター漏れを検知・警告
- 外部サービスDevin AIはSnowflakeデータアクセス後は呼び出し不可とする制御を実装
- コスト:
- Snowflake側コストは1日数十件の利用のため大きくなく、LLM（Bedrock）のコストの方が高い
- Langfuseでトラッキングしキャッシュを活用することでLLMコストを削減
■ 4. セッション3: Vポイントマーケティング — AIレディなデータ基盤のためのメダリオンアーキテクチャ
- 背景:
- CCCグループで「社員全員がAIを活用できる」環境を目指し、Difyを社内展開
- 市民開発メンバーがPDF・PPTXをDifyのナレッジベース（RAG）に取り込む際、テキスト化で情報が欠落する問題が発生
- 各個人がナレッジベースを独自管理するため品質が散漫になるという課題も発生
- メダリオンアーキテクチャの適用:
- ブロンズ層（IT・インフラチーム）: SharePointを非構造化データの格納場所として整備
- シルバー層（AIエンジニアリングチーム）: AIを使ったデータ加工・テキスト化
- ゴールド層（データエンジニアリングチーム）: Snowflakeでエージェントへのデータ提供
- 各層の担当と必要な権限・専門性が社内組織構造とマッチした点が採用理由
- 非構造化データの処理フロー（シルバー層）:
- SharePointとの接続容易性を理由にMicrosoft Fabricを採用（DatabricksよりFabricが優位）
- PDFはPyMuPDFで各ページを画像化し、Azure OpenAIのLLMでマークダウン形式にテキスト化
- PDF以外（PPTX・Word等）はLibreOfficeが使えないFabricの制約からMicrosoft Graph APIを活用
- Graph APIの
format=PDFパラメーターでSharePoint上のファイルをPDF変換してダウンロード- Word・HTML・PowerPoint・Excel等の幅広い形式に対応
- 抽出データにはページ種別（表紙・結論・通常）とページイメージURLも付与
- ゴールド層とエージェントへの提供:
- SnowflakeのCortex Searchでハイブリッド検索（キーワード＋ベクトル）を実現
- SnowflakeのManaged MCPサーバーとしてCortex SearchやCortex Analystを公開し、DifyやMCP対応クライアントからアクセス可能に
- シルバーからゴールドへの差分更新でファイル更新・削除に対応
- 今後の課題:
- SharePoint以外のデータソース（Googleドライブ等）への対応にDatabricksのコネクターを活用検討
- センシティブな社内資料処理のために社内GPUクラスターでオープンソースLLMの活用を検討
- LLMによる抽出結果の品質管理（図や画像内の関係性欠落への対処）
■ 5. 共通の知見
- LLMの発展により非構造化データの活用が急速に進んでいる
- データウェアハウス（Databricks・Snowflake等）でのベクトル検索基盤が整い、ElasticSearch等の自前構築なしにセマンティック検索を実装できる時代になっている
- コスト意識として、GPUや動画ストレージ等の主要コストと比較してベクトル検索・LLM推論のコストは相対的に小さい
- セキュリティ面では、本番DBの代わりにデータプラットフォーム上でフィルタリング済みデータを参照することが有効
- POCで先に使われるかを確認してから本格実装に進むアプローチが各社共通