ミラティブ ashura — 分析を民主化しつつ品質を保つAIエージェント基盤¶
作成日: 2026-07-03 出典 / きっかけ: 分析を"民主化"しつつ品質を保つAIエージェント基盤「ashura」の設計 - Mirrativ Tech Blog（著者: Tom・データ分析チーム、2026-05-27公開） 関連: メルペイ_決済常駐aiエージェント_設計と5層防御_整理 lineヤフー_組織ax_仕様構造化と海外先行事例_整理 ホタルシステム_個人業務のai自動化_整理
0. 要点（3行）¶
- ashura は Claude Code 上で「分析依頼→SQL→検算→報告書」を完結させる社内エージェント基盤。AIの賢さではなく、AIが参照できるドキュメント（用語集・テーブルカタログ・集計ルール）の整備が結果を決めるという思想が核
- LLMは長い指示書を読み飛ばすという前提に立ち、workflow-gate（hookでフェーズ定義を強制注入＋証跡ファイルがないとBigQuery実行をブロック）で「読まないと動けない」構造を物理的に作る
- 書き手と読み手を別サブエージェントに分離した多段反証レビュー（plan/query/verifier/report）で品質担保。結果、社内47名・1日20名が使う基盤に成長。ただし完全民主化には至らず人間レビューは残存
1. 背景 — なぜ作ったか¶
1-1. 分析業務のボトルネック¶
ミラティブ（ゲーム配信アプリ）は配信・視聴・コメント・ギフト・ガチャ・課金など膨大な行動ログを持つが、「どのログがどこにどんな形式であるか」が明文化されておらず、分析チーム以外はテーブル探索の時点で詰まる。要件擦り合わせ→SQL→レビュー→報告の全工程が分析チームに集中し、プロダクト開発の速度（新機能・施策の効果測定依頼の量）に追いつかない。
1-2. 「AI丸投げ」で起きた失敗¶
単にLLMに分析を投げると、次の3つが起きる（記事中の整理）:
- 曖昧な指標をAIが独自解釈する（「継続率」の定義が揺れる）
- 存在しないカラムを使った誤ったSQLを生成する
- 長い指示書の途中をスキップする（読み飛ばし）
→ ashura の目標は「分析の民主化（分析チーム以外が自分で集計できる）」と「専門家品質の維持（アナリストのレビューに耐える出力）」の両立。
2. アーキテクチャ — 4層構造¶
| 層 | 役割 | 構成要素 |
|---|---|---|
| ナレッジ層 | 暗黙知の明文化 | 用語集・テーブルカタログ・集計ルール（約6ヶ月かけて整備） |
| 実行層 | 分析業務の遂行 | 30超のスキル群、workflow-gate、Phase管理 |
| 安全層 | 破壊的操作の物理ブロック | Claude Code hooks |
| 品質層 | 多段AIレビュー | plan-reviewer / query-reviewer / verifier / report-reviewer |
- データはBigQueryの中間テーブル群に置き、AIが生ログを直接叩いてスキャンコストが膨張するのを防ぐ
- スキルは「1スキル=1役割」で分業（例:
data-researcher=データ探索、query-writer=SQL生成、analyst=報告書作成）。カテゴリはリサーチ/作成/レビュー/報告の4つ
3. workflow-gate と Phase 管理 — 読み飛ばしの物理防止¶
分析を Phase 1〜7 に分割し、各Phaseの入口で gate スクリプトを通す。
Phase 0 親エージェントが workflow-gate 起動、task_id 発行
│
Phase 1 requirement-aligner: 要件定義（指標定義・比較設計の擦り合わせ）
│ └─ 成果物: phase1_requirements_{task_id}.md
Phase 2 data-researcher: テーブル選定・データ設計図の作成
│ └─ 成果物: phase2_research_{task_id}.md
Phase 3 plan-reviewer: 設計図の反証レビュー ──── NG なら Phase 2 へ差し戻し
│
Phase 4 query-writer: SQL生成（ドライランで参照量確認）
│ ※ phase2 の設計図ファイルが無いと gate を通れない
Phase 5 query-reviewer: SQL の反証レビュー ───── NG なら Phase 4 へ差し戻し
│
Phase 6 verifier: 実行結果を Golden Table と照合・検算
│
Phase 7 analyst → report-reviewer: 報告書作成・最終レビュー
※ phase1 の要件定義ファイルが無いと gate を通れない
仕組みの要点:
workflow-gate.sh {phase} {task_id}が該当Phaseの定義ファイルを stderr に出力して会話に強制注入する。「AIが指示書を読み飛ばす」ことを物理的に不可能にする発想- gate 通過時に
tmp/.workflow_gate_{task_id}という証跡ファイルを作る - BigQueryクエリはSQL冒頭に
-- wf:{task_id}コメントが必須。hook が task_id を抽出し、対応する gate ファイルが存在しなければクエリ実行自体をブロックする - 前段の成果物ファイルがないと次のPhaseに進めない。「いきなり query-writer だけ呼ばれて適当なSQLを生成」という事故を構造で阻止する
4. 安全層 — hooks による物理ガード¶
ドキュメントに「やってはいけない」と書くのではなく、実行時にブロックする:
| ガード | 内容 |
|---|---|
| 破壊的SQLブロック | DROP / DELETE / --replace を含むコマンドを実行拒否 |
| 本番テーブル直書きブロック | summary.* や db.* など本番データセットへの --destination_table 指定を拒否 |
| スキャン量ガード | 300GB超のクエリを自動検出しユーザー承認を要求 |
Claude Code の hooks（コマンド実行前のシェルスクリプト差し込み）で実現。
5. 品質層 — 書き手と読み手を分離した多段反証レビュー¶
| レビュアー | 役割 |
|---|---|
plan-reviewer |
データ設計図の反証。テーブル選定ミス・要件取り違えを検出 |
query-reviewer |
SQLロジックの反証。JOIN膨張・NULL暗黙除外・二重カウントを検出 |
verifier |
実行結果を Golden Table と照合し異常値を検出 |
report-reviewer |
レポートの「事実」と「解釈」の混同、考察品質を検査 |
各レビュアーは独立サブエージェントで、書き手とコンテキストを共有しない。「正しく見えて間違っているケース」を能動的に反証テストで探す。
記事中の差し戻し実例:
- Phase 3: plan-reviewer が「観測期間中の未離脱ユーザー（打ち切り）を全員『離脱』と判定していないか。継続率が過小評価される。生存時間分析への切り替えか打ち切り判定の導入を」と指摘 — 書き手と分離されたレビュアーだからこそ出る指摘
- Phase 6: verifier が単純集計とのクロス検証で 0.3pt の乖離を検出して差し戻し
6. 3つのコア設計思想¶
- 暗黙知を明文化する — 「AIの賢さより、AIが参照できるドキュメント整備の方が結果を決める」。ドキュメントが無ければどれだけ高性能なLLMでもテーブル探索で詰まる。最重要投資
- 「読み飛ばし」を物理的に防ぐ — LLMは長い指示書を全部読まない前提で設計する。workflow-gate がフェーズ定義を毎回注入し、読まないと動けない構造にする
- 単一AIを信用しない — 書き手と読み手を独立サブエージェントに分離し、AI同士の相互反証で品質を担保する
7. 運用結果と残課題¶
- ユーザー数 47名、1日あたり 20名 が使用（記事時点）
- 「忙しそうだから依頼しない」で消えていた細かな分析が個人で完結するようになり、分析チームへの簡単な集計依頼が減少
- MTG中にその場で集計を回し、議論が止まる前にネクストアクションを決めるPdMも出現（リアルタイム意思決定）
- 残課題: アナリストなら気づけるデータ矛盾・分析手法の根本的間違いに気づけないユーザーが一定数おり、分析チームのレビュー（人間のセーフティネット）はまだ必要。完全な民主化には至っていない
- 今後: BigQuery実行をゲートウェイ経由化する「ashura Gateway」構想（回答ログ収集＋初心者の高コストクエリの堰き止め）、サブエージェントごとのモデル選定（haiku/sonnet/opus）と extended thinking の調整によるコストチューニング
なお全社的な背景として、ミラティブは行動指針に「with AI」を追加して Claude を全社導入し、社内イベント「AI祭り」で約1ヶ月に100件超の業務改善施策が発表された（ashura はその優勝作。PANORA 2026-05-25 報道）。
8. 自分の視点 — 他事例・自分のプロジェクトとの対比¶
| 観点 | ashura（ミラティブ） | 類似・対比 |
|---|---|---|
| ガードの置き場所 | hooks で実行時に物理ブロック（ドキュメントで諭さない） | メルペイ_決済常駐aiエージェント_設計と5層防御_整理 の5層防御と同じ「プロンプトではなく構造で縛る」系譜 |
| 判断基準の外化 | 用語集・集計ルールをドキュメントとして整備しAIに参照させる | 自分の ai-engineering-digest / st-japan-lab の harness.yaml（基準をコードでなくYAMLに集約）と同思想 |
| 読み飛ばし対策 | gate が stderr でフェーズ定義を強制注入＋証跡ファイル | 「CLAUDE.mdに書けば読まれる」への明確な反例。強制注入＋実行ブロックまでやる |
| 多段レビュー | 書き手と読み手のサブエージェント分離＋反証 | 自分のセルフレビュー運用（/code-review＋ミューテーションテスト）のデータ分析版 |
| 類似事例 | — | メルカリ「Socrates」（データアナリティクスAIエージェント、ADK活用）が同じ問題設定 |
特に効いているのは「成果物ファイルの存在チェックを gate にする」設計。Phase間の依存を「指示書に書く」のではなく「前段の成果物がないと物理的に進めない」にしている。Temporal のワークフロー設計（activity の出力が次の activity の入力）と同型で、LLMエージェントに決定的な順序を強制する手法として自分の research-orchestrator にも転用できる。
9. まとめ — いつ何を参考にするか¶
| 状況 | 参考にする部分 |
|---|---|
| 社内データ分析をAIに開放したい | まずナレッジ層（テーブルカタログ・用語集・集計ルール）。記事は「よく使うテーブルのドキュメント10個とクエリルール」からのスモールスタートを推奨 |
| エージェントが指示書を読み飛ばす | workflow-gate パターン（hookで定義を強制注入＋証跡ファイルがないと実行ブロック） |
| AI出力の品質が信用できない | 書き手/読み手のサブエージェント分離＋反証レビュー＋Golden Table照合 |
| BigQueryコストが怖い | 中間テーブル整備＋スキャン量ガード（300GB超で承認要求）＋破壊的SQL/本番直書きのhookブロック |
参考リンク¶
- 分析を"民主化"しつつ品質を保つAIエージェント基盤「ashura」の設計 - Mirrativ Tech Blog
- ミラティブ、行動指針に「with AI」を追加し全業務をAI協働前提に - PANORA
- メルカリにおけるデータアナリティクス AI エージェント「Socrates」と ADK 活用事例 - Speaker Deck
作成: 2026-07-03 ／ 最終更新: 2026-07-03