Share
Embed
Transcript
25 slides
-
2 山田 瑠奈(やまだ るな) • 2021年新卒入社 • 所属:株式会社サイバーエージェント メディア統括本部 >
Data Science Center • 職種:データエンジニア • 業務概要:WINTICKETデータマネジメント • 経歴 ◦ Ameba ▪ 2021年 記事レコメンドシステムの 運用・改善などを担当 ◦ WINTICKET ▪ 2023年 マーケティング分析を担当 ▪ 2024年 データマネジメント推進を担当 自己紹介 -
4 会社紹介 / WINTICKET の概要 • 競輪・オートレースの投票サービス • 株式会社サイバーエージェントの連結子会社 •
組織規模は約70名。うち開発者は約40名 並行して複数の施策を進行しながらスピード感を持って開発中 • データマネジメントチームは現在2名 決算資料より引用 -
7 Devinとは? 自立型AIエージェント PlaybookとKnowledge • コード生成・実行、ブラウザ操作等が可能 • Slack/Linearなどの複数インターフェース から自然言語で呼び出しが可能 •
Playbook: 自動化させたいタスクのシステム指示 • Knowledge: タスク実行に必要な事前知識 -
8 WINTICKETにおけるDevin活用 データ分析 Slackワークフローをトリガーとして 自然言語でデータ分析を実行 データパイプライン障害の対応 データパイプラインに異常が起きた場合に 原因追及とコード修正・PR作成まで実施 ログ設計 施策仕様書と過去のログ設計などを
元にログ仕様書を作成 その他運用業務の効率化 コードレビュー / データセットの追加 一部データマートの作成 などの業務効率化 -
9 WINTICKETにおけるDevin活用 データ分析 Slackワークフローをトリガーとして 自然言語でデータ分析を実行 データパイプライン障害の対応 データパイプラインに異常が起きた場合に 原因追及とコード修正・PR作成まで実施 ログ設計 施策仕様書と過去のログ設計などを
元にログ仕様書を作成 その他運用業務の効率化 コードレビュー / データセットの追加 一部データマートの作成 などの業務効率化 本日のメインテーマ -
データ分析エージェントとしてのDevin 11 質問 回答 分析者 BigQuery Dataform 改善要望 分析Playbook 分析Knowledge
改善Playbook Dataform repo Knowledge repo -
分析プロセス 1. Slackから自然言語で質問 Slackワークフローから分析内容・期間を入力 実際のやりとり 13 特徴① Slackを入力とした分析体験 2. 分析方針をユーザと擦り合わせ
不明点があればヒアリングし、承認を得てから次へ進む 3. SQL生成・実行・結果解釈 実行前に必ずユーザ確認を挟み、サマリ付きで回答 2026/01/01から3/25までの新規登録者数の日別の推移を抽出したい意図 を改めて言語化 集計軸(日)やフィルタ条件 (本人確認完了など )を提示 実行前に必ず実行して良いか確認を挟むようにルール化 実際に利用するテーブルやカラムについてユーザに確認 1.理解した意図 2.分析設計 3.使用テーブル 4.SQL 5.結果の解釈 実行結果をわかりやすくまとめて展開 -
改善プロセス 1. Slackから改善要望を提出 足りてないドメイン知識などを分析者が追加 実際のやりとり 特徴② 分析結果に問題があれば改善要望 2. DevinがPRを作成 Knowledge修正などの内容が含まれる
3. DS/DMのコアメンバーがレビュー コンテキストが肥大化しないように適切性を確認 4. マージ後 Knowledgeに自動で反映される 次回以降の分析に反映される ・追加対象の Knowledge ・追加する内容 14 -
15 分析Playbook設計時に気を付けたポイント 5ステップの回答フォーマット 意図理解 → 分析設計 → テーブル選定 → SQL生成・実行
→ 結果解釈 各ステップのどこが課題となっているかを振り返り時に判断できるように SQL実行前にユーザ確認を必須に 候補クエリを提示し、ユーザーの承認を得てから実行 不明確な質問にはヒアリングで要件を明確化してから分析に入る 生成された SQLに監査コメントを必須に 全SQLに requested_by, session_id, query_purpose を付与して 後からクエリの実行ログを分析でき、改善サイクルを回せるように -
データ分析から始まる基盤改善 17 分析セッションログ Linear 振り返りPlaybook (定期実行) Dataform repo Knowledge repo
継続的な改善サイクル 不足している ドメイン知識の追加 基盤側に問題がある 場合は直接修正 -
起票されたIssueの傾向 19 カテゴリ 割合 Issue内容 1.意図理解 23% ビジネス用語や指標の定義を知らない 2.分析設計 30%
集計単位やドメイン特有の除外条件の前提を知らない 3.テーブル選択 35% 類似テーブルの使い分けを知らない 4.SQL生成 4% NULL処理、タイムゾーン等の技術的問題 5.結果解釈 2% 出力フォーマットのルール データ基盤側 6% テーブル定義自体の不整合やデータ欠損 分析ステップ +データ基盤のカテゴリに Issueを分類 SQL実行前にユーザー確認を挟むため SQL生成以降の問題はその場で修正されIssueとして残りにくい -
Issueから見えてきたこと: 実際の事例 20 「今日新規登録したユーザーを抽出して」 「そんなことないはず!」 日次バッチのテーブルで集計 → 結果: 0件 当日用のリアルタイムテーブルに切り替え
→ 正しい結果 テーブル選択ミス 当日はテーブルが異なることを Devinは知らなかった 0件だったから気付けた 微妙にズレた数字であれば 依頼者は気付かない可能性もある この指示がそのまま Issue化 Knowledgeとして追加することで次 回から同じ間違いをしない -
Issueへの打ち手 21 ドメイン知識不足が原因のものと、依頼の質に依存するが混在 用語や指標の定義が曖昧 🚧 Knowledge整備 現時点では管理可能だが Tipsが増え続けた場合の構造化が課題 🚧 分析依頼のガイドライン作成
Issueの傾向からよくある曖昧な 依頼パターンを整理して展開 🚧 セマンティックレイヤー整備 ただ、導入・維持コストが高く 少人数チームでは現実的でない 🚧 入力フォーマットの改善 利用ハードルとのトレードオフ ドメイン知識 依頼の質 依頼内容が曖昧で期待する出力が不明瞭 -
現状の到達点 23 うまくいってること • 職種問わず様々な方に使ってもらえてる • 分析 → 振り返り →
Issue起票 のサイクルが人手ゼロで稼働 • 分析のハードルが下がりクエリ実行ログから データマートの需要を検知できるようになった 課題 • IssueからKnowledgeへの反映が追いつかず、同じ指摘が繰り返される • 依頼の質にばらつきがあり、曖昧な依頼は精度が上がらない • Issue化は分析者が気づけた問題しか拾えない