田町.ai 一晩中分析し続ける自律成長分析基盤の構築

Transcript

1. LIGHTNING TALK5 分 2026 / 04 / 20 ProductHall · Analytics 01 / 2 3 自律的に動き続ける分析基盤 一晩中、分析を止めない。自律成長する分析基盤を作った話。 LLMエージェントを長時間動かすために、目的・データ・ エージェントの三層を設計した。その構成と、 まだ残っている課題についての報告。
2. SPEAKER 自己紹介 02 / 2 3 0 1 S P E A K E R すぎけん X · @sugiken_bike C A R E E R 0 1 freee Eng 10 割 0 2 バックテック PdM 7 割 / Eng 3 割
3. 以前の課題 単発では、扱えるテーマに限界があった 03 / 2 3 0 2 旧来の分析体験 単発の分析では、浅いテーマしか扱えない。 Notionエージェントや単発の分析 Skill は、 起動のたびに文脈がリセットされる。結果、 AIが自分で立てる問いは「今週 WAU が減った理由」 のような、その場で答えが出るものに偏る。構造的・ 横断的な問いに時間を使えない。 0 1 Notion / 単発 Skill では、毎回文脈がゼロから始まる。 0 2 だから出てくる問いが常に「明確で浅い」ものに寄る。 0 3 長時間走らせたい。だが LLM は目的を忘れ・文脈が溢れ・ 同じミスを繰り返す。
4. 以前の課題 毎回、同じ答えに戻ってきていた 04 / 2 3 0 3 旧来の分析体験 / 実例 「再帰的に調べて」と頼んでも、毎回同じ答えが返ってきた。 人間 KPIデータやアナリティクスMCPを用いて、今のプロダクトの問題点を再帰的に調べて原因を特定して AI はい、今の課題は WAU の急落です！なんと前週比 -15%！原因は登録ページ訪問者が少なく〜 毎回これ 「再帰的に」と指示しても、文脈が消えれば毎回ゼロから始まり、毎回同じ答えに戻る。
5. 全体像 長時間動かし続けるための三層 05 / 2 3 0 3 全体像 / 三層で整える LLMが忘れる前提で、外側に三層を積み上げることにした。 01 P U R P O S E 目的層 — 何のために動くか 四半期KPIを明文化して、判断基準のトップに置く。 — AGENTS.md × 至上命題 — 全スキル冒頭に再掲 02 DATA データ層 — 何を読ませるか AIが読みやすい形に整えた3系統のデータソース。 — data/ ( スプレッドシート事前格納) — BigQuery × toolbox MCP — Amplitude MCP 03 AG E N T エージェント層 — どう動き続けるか 文脈を保ち・記憶を残し・学び続けるための仕組み。 — SubAgent 分業 — ナレッジグラフ — retro 自動 + 人間
6. 第 1 章 / 全 4 章 06 / 2 3 第 1 章 · 目的層 01 / 0 4 目的層 — 何のために動くのか。 長時間動かす上での前提。AIにも四半期KPIを渡して、 判断基準のトップを一つに決めておく。
7. AGENTS.MD × 至上命題 07 / 2 3 0 5 目的層 AIにも、今期のチームKPIを渡しておく。 リポジトリ直下の AGENTS.md に至上命題を書く。 セッション起動時に自動で読まれ、コンテキストの先頭に残り続ける。 判断基準のトップは常に 至上命題への貢献度。 # 至上命題 2026年4月1日〜6月30日の3ヶ月間で、合計x,000人（ユニーク） の面談予約を獲得する。 ※ 累計ではなく、2026年度Q1（4〜6月）の期間内での新規面談予約ユニークユーザー数が対象。 すべての分析・施策提案はこの至上命題の達成に貢献するかどうかを判断基準とすること。
8. 第 2 章 / 全 4 章 08 / 2 3 第 2 章 · データ層 02 / 0 4 データ層 — 何を読ませるのか。 AIの仕事は分析。整形は事前に済ませておく。3系統のデータを、 読むだけで済む形にしておく。
9. AIが読みやすい3つのデータソース 09 / 2 3 07 データ層 AIの仕事は分析。整形は事前に済ませる。 ソース 0 1 · 事前E T L data/ spreadsheet → json 背景 すでに運用されている KPIスプレッドシート への対応。 数式・参照・マージ構造が複雑で、 AIに直接読ませるとブレる・遅い Python で sync し、JSON 化して data/ に置いておく AI側は「ファイルを読むだけ」で済む 事前整形が、トークンと時間の節約に一番効く。 ソース 0 2 · ウェアハウス BigQuery × toolbox MCP 本番DBのマスキング済みコピーをBQへ toolbox MCP 経由で安全にSQL実行 深掘り分析を安全かつ速く回せる 本番DBを直接触るリスクを避けつつ、 SQLの自由度は保つ。 ソース 0 3 · 行動データ Amplitude MCP イベント検索・プロパティ分布・ チャート生成が自然言語で完結 自作ダッシュボードを見るより、 AIに聞いた方が早い場面が多い 使ってみて、思ったより普通に実用だった エージェント側の設計と同じくらい、 データ基盤の整備が効く。
10. 第 3 章 / 全 4 章 10 / 2 3 第 3 章 · エージェント層 03 / 0 4 エージェント層 — どう動き続けるか。 ここがLTの本題。文脈を保つ・記憶を残す・学び続ける、 この3つをSubAgent分業・ナレッジグラフ・retroで仕組みにしていく。
11. SUBAGENT 分業 — 文脈を保つ 11 / 2 3 0 9 文脈を保つ 親はオーケストレーション、子は専門タスクに分ける。 子エージェントが何万トークン使っても、 親に戻るのは要約3行だけ。 親のコンテキストを汚さないために、 これが一番効いた。 1サイクル数KBで回り続ける。 親のコンテキストを軽く保つのが最優先。 オーケストレーター（親） 親に戻るのは要約3 行のみ · 1 サイクルあたり 子 theme-decision → 要約3 行 子 theme-executor → 要約3 行 子 knowledge-update → 要約3 行 子 self-retro → 要約3 行
12. 問いかけ "分析" は、何で構成されているか 12 / 2 3 1 0 問いかけ 「分析」を分解してみた 仕組みに落とす前に、構成要素を整理しておきたかった。 結論、自分が扱う分析はこの4要素とその関係で表せる。 H Y P OT H E S E S 仮説 まだ検証されていない主張と、 その根拠候補。 A N A LY S E S 数値を見る 問いを立てて、 データで確かめた1 回の作業。 M E T R I C S 指標の定義と現在値 観測の単位。名前・定義・今いくつか。 記憶や感覚で扱いがちな部分。 AC T I O N S アクション 仮説を検証・前進させるための次の一手。 観察 — 現場の実態 この4つを関係を保ったまま記録し続けている現場を、自分はほとんど見たことがない。 大抵は個人の記憶と Slack と散らばったドキュメントに分かれて、属人化する。
13. 4要素を、どこに残すか 13 / 2 3 1 1 記憶を残す / 意思決定 4要素はSQLite の1ファイルに固定した。 Markdown を散らばせる案・Notion・vector DB と比較した上での決定。 履歴を残すのではなく、次サイクルが読む入力として設計したかったので、 構造とアクセス手段を揃えておきたかった。 0 1 関係を辿れる。 却下: Markdown 散らばし 仮説 → 分析 → 指標 → アクションの参照を残したかった。Markdown では JOIN も WHERE も書けない。グラフとして引ける形が必要。 SELECT * FROM hypotheses h JOIN edges e ... 0 2 決定的に絞れる。 却下: vector DB 次サイクルが読むべき行は「似てる」では選べない。 priority・status・trigger で確定的に絞り込みたい。 曖昧検索では入力として弱かった。 WHERE status=' 未検証' AND priority IN (' 最重要',' 高') 0 3 持ち運べる。 却下: Notion / 外部 SaaS API 越しは遅く、スキーマ運用も重い。1ファイル・ 依存ゼロ・git に乗る形が、 この用途には一番合っていた。 docs/auto-analysis/knowledge_graph.db 結論、SQLite 1ファイル。 4ノード × 7エッジを同じスキーマで持ち、AI が SELECT で次の問いを引ける状態を、最小コストで用意する。
14. ナレッジグラフ — 記録の実体 14 / 2 3 1 1 記憶を残す / 何を、どのくらい貯めているか 分析ごとの仮説・指標・結論が蓄積されている。 散らすから属人化する。4つを、関係ごと、同じスキーマで持つ。実体は SQLite 1ファイル、4ノード × 7エッジ＋優先度・再検証トリガー。読み返す履歴ではなく、 次サイクルが読む入力として設計した。 仮説 115 行 主張と根拠のペア。 · status × priority （最重要 / 高 / 中 / 低） · reverification_triggers — 何が起きたら再検証するか 数値を見る 33 行 1本の分析レポート。 · 確信度 + 品質7 項目 で自己評価 指標の定義と現在値 84 行 観測の単位。 · trend （急増 / 急減 / 増加 / 減少 / 横ばい） · category （MAU / リテンション … ） アクション 86 行 仮説検証のための次の手。 · priority × deadline · target_hypothesis で仮説に紐付く 関係 384 本 生成 117 計測 88 検証 77 支持 64 拡張 25 矛盾 13 仮説 · ステータス 115 行 支持 76 未検証 19 棄却 10 要再検証 5 保留 5 なぜこのフィールド設計か 数字を貯めるだけなら CSV でも足りる。ここで効くのは priority・reverification_triggers・矛盾エッジ。次のサイクルに読まれるためのフィールド。
15. ナレッジグラフ — 活用と自律性 15 / 2 3 1 2 記憶を残す / なぜ分析に深みと自律性が生まれるか 過去の分析から、次に調べるべきことが決まる。 KG は「履歴の置き場」ではなく、次サイクルの入力。何を読み、何を書き、その結果何が起きるか。 A I が読む 次に分析すべきものを、自分で選ぶ。 theme-decision （ステップ 1 ） 未検証 × 優先度「最重要 / 高」の仮説を拾う SELECT WHERE status=' 未検証' AND priority IN (' 最重要',' 高') 要再検証の仮説で、reverification_triggers が満たされたものを検出 提案ステータスのアクションで、 期限が近いものを浮上させる 直近1週間の実施テーマを除外（重複回避） A I が書く 結果を、既存知識と整合させて積む。 knowledge-update （ステップ 5 ） 仮説のステータス遷移を書き換える 未検証 → 支持 / 棄却 / 要再検証 棄却時は contradicting_evidence に根拠を必ず添える （ルール強制） エッジを追加（生成 / 支持 / 矛盾 / 拡張 / 検証） 重複は INSERT 前に SELECT COUNT でチェック docs/knowledge/ との矛盾チェック。 食い違えばドメイン知識側も更新する 結果として生まれる 分析の深さと自律性は、この構造から出てくる。 システム挙動として 数ヶ月前の未検証仮説が、 条件を満たした瞬間に自動で浮上する 例: トリガーに「サンプル n≥30 」があれば、 母集団が育った時に再検証へ 過去の棄却が 矛盾エッジとして残るため、 同じ仮説を再提案しない 拡張エッジで 分析 → 分析 を繋げ、 一歩深い問いに段階的に移る 品質スコア7項目が履歴に残り、 質の低い分析は自己訂正される
16. 第 3 章 · 学び続ける 16 / 2 3 第 3 章 · C . 学び続ける 03 / 学習 学び続ける — 何を、どうやって。 分析業務で「学ぶ」ものは一種類ではない。変わる速さも、保存の形も、 参照の仕方も違う。分けて設計する。
17. 分析業務の学習は、3種類ある 17 / 2 3 1 3 学び続ける / 何を学ぶのか 分析業務の学習は、3種類ある。 変わる速さも、保存する形も、参照の仕方も違う。分けて設計するのが前提。 種類 0 1 現状の数値 「今」どういう数値なのか。変わりやすく、 改善に合わせて動く。 新しい発見が継続的に出てくる領域。 保存 knowledge_graph.db （SQLite ） 参照 theme-decision が再帰 JOIN で引く 種類 0 2 プロダクトの学習 短期的には変わらない知識。ロール・主な利用サイクル・ ペルソナなど。 前提として毎回効いてくる領域。 保存 docs/knowledge/ に Markdown 参照 Agentic Search で都度参照 種類 0 3 分析方法の学習 人間でいうツールの使い方。Amplitude の引き方、 統計検定の選び方など。 失敗から積み重ねていく領域。 保存 docs/knowledge/ に Markdown 参照 Skills 経由で参照
18. RETRO 2系統 — 学び続ける 18 / 2 3 1 4 学び続ける / どう回すか AIによる学習と、人間による指導。両方で回す。 自動 · A I が実行 自動 retro プロセスの失敗、ツール利用の誤り、サイクル間の抜けをAI自身が検出する。スキル・ ルール・フックの修正提案まで出す。 対象 — プロセス · スキル · ツール 出力 — retro/*.md → スキル書き換え 人間による指導 · A I からの問い human-review AIが判断に迷った現象・事実を、質問として人間に投げる仕組み。対話で解消した結果は docs/knowledge/ に残り、以後の全サイクルで参照される。 対象 — AI が判断に迷った事実・現象 出力 — knowledges/ → docs/knowledge/
19. 学習を支える3つの軸 19 / 2 3 1 5 学び続ける / 実装 プロセス振り返り · 人間による指導。独立した2つの軸で学習する。 軸 0 1 · プロセス振り返り AIが自分のスキルを直す。 実行プロセスの失敗や気付きを拾って、スキル本体を書き換える軸。 01 self-retro 各スキル末尾 書込 docs/auto-analysis/retro/ {ts}_{skill}.md 02 process-retro ステップ 6 読込 docs/auto-analysis/retro/*.md 書込 .claude/skills/auto-analysis-*/SKILL.md .claude/rules/** N E X T 次サイクル以降、全スキルが書き換え後のルールで動く。 AI が自分を直すループ。 軸 0 2 · 人間による指導 迷った現象は、人間に聞く。 AIが判断に迷った事実・現象を人間に質問して、知識として取り込む軸。 01 （各分析スキル） 判断保留時 書込 docs/auto-analysis/ human-review/*.md 02 human-review-resolver ステップ 0 読込 docs/auto-analysis/ human-review/*.md 書込 docs/auto-analysis/knowledges/*.md 次は ステップ 1–4 が解消済みの知識を前提に動く。 曖昧なまま分析に入らない。
20. リポジトリ構造として見る三層 × 三軸 20 / 2 3 1 7 まとめ / リポジトリの全体像 リポジトリの全体像。 三層（目的・データ・エージェント）と学習の三軸が、そのままディレクトリ構造に対応している。 ProductHall/ ├─ AGENTS.md 目的層 至上命題。セッション起動時に自動読込 │ ├─ src/sync/ データ層 スプシ → JSON の ETL スクリプト ├─ data/ (customers / pbi / csActivities / kpi) データ層 AIが読むだけで済む形に整えたデータ │ ├─ docs/ │ ├─ knowledge/ 学習 · プロダクト / 方法 PDM検証済みのドメイン知識 │ └─ auto-analysis/ 自律分析の全成果物 │ ├─ knowledge_graph.db 軸 01 · 知識 SQLite ナレッジグラフ │ ├─ kg_utils.py AIがデータを引きやすくするツール群 │ ├─ {ts}_{theme}/report.md 分析セッションごとの記録 │ ├─ knowledges/ AI蓄積 → PDM検証 → docs/knowledge/ に格納 │ ├─ retro/ 軸 02 · プロセス振り返り self-retro 出力 │ └─ human-review/ 軸 03 · 人間による指導 AIが混乱した事実を人間に問う │ └─ .claude/ エージェント層 ├─ skills/ auto-analysis-* + 他 オーケストレーションの本体 ├─ rules/ 横断ルール（季節要因禁止 など） └─ hooks/ lint-knowledge-graph.py 等 目的層 — AGENTS.md データ層 — src/ · data/ 軸 01 · 知識 軸 02 · プロセス振り返り 軸 03 · 人間による指導
21. 第 4 章 / 全 4 章 21 / 2 3 第 4 章 · 現状の課題 04 / 0 4 現状の課題。 ここまでは上手くいった話。ここからは、まだ残っている課題の話をする。
22. 現状の課題 正直な話、まだここまで 22 / 2 3 1 7 残っている課題 分析オペレーターとしては優秀。でも、意思決定者にはまだなれていない。 0 1 解釈コストが人間に残る 分析の量と質は十分。 「で、どうする？」は人間が読まないと決まらない。 ボトルネックが生成から解釈に移っただけ、とも言える。 0 2 トークン消費がそれなり Claude Code Max Plan でも足りない場面がある。人を雇うより圧倒的に安いが、 まだ圧縮の余地はある。 0 3 プロダクト改善への接続 分析 → 意思決定 → PBI起票 → 検証、という流れのうち、 自動化できているのはまだ最初の1ステップだけ。 0 4 自発的な問い立てが弱い 「何を分析するか」を自分で決める力は、まだ人間側の仕事のまま。 感触としては、こういう人を雇ったイメージ 意思決定力や提案力はそこまで高くない。ただ、 分析だけはめちゃくちゃ得意な新人データ分析官。 指示された分析タスクには期待以上の出力で返してくる。一方で、 数値から施策への落とし込みや、問いを自分で立てることは、 まだシニアに任せたい。
23. 締め 持ち帰り / 次の挑戦 ご清聴ありがとうございました 23 / 2 3 1 8 TA K E AWAY S 0 1 目的・データ・エージェントの三層で、 長時間動かせる状態を作った。 0 2 retro は自動 + 人間の2系統。 AIが知らないことがある前提で設計する。 0 3 新人分析官までは作れた。次は「提案できる中堅」 の設計へ。 D O N E 一晩中、動き続ける基盤はもうできた。 N E XT 朝起きた自分に、意思決定まで届ける。