Claude Code でデータ分析エージェントを作る: 入口スキル→KPI別オーケストレーター→専門スキルの3段と、組織の文脈を貯める memory.md（Ubie の事例）

解決する問題

• 「この KPI が下がった理由は？」と聞くと、最初に見つけたそれらしい原因で止まってしまう
• テーブルの意味、社内の定義、過去に人が直した解釈などの組織固有の文脈を、毎回プロンプトで渡すのは無理がある
• 分析の知識が個人の手元に散らばり、チームで共有できない

構成（プラグインの中身）

1. 入口スキル: ユーザーの質問を受けて、どのエージェントに回すかを決めるだけ。自分では分析しない
2. KPI 別のオーケストレーターエージェント: KPI ごとに1つ。調査の進め方（下の仮説駆動ルール）を持ち、必要な専門スキルを呼ぶ
3. 専門スキル: データ領域ごとに1つ。各スキルの references/ に次の4ファイルを置く
   • table-knowledge.md: テーブル・カラムの意味、結合のしかた、落とし穴
   • institutional-context.md: 社内の定義や業務の背景（何をもって「有効ユーザー」とするか など）
   • learned-corrections.md: 人に指摘されて直した解釈の記録。同じ間違いを繰り返さないため
   • queries.md: 検証済みの SQL の例

仮説駆動のルール（オーケストレーターに書く）

1. まず事実を見る（数字の動き、期間、セグメント）
2. 仮説を 3つ以上 挙げる
3. 最初に当てはまった仮説で止まらず、全部を検証する
4. 結果から新しい仮説が出たら、また 2 に戻る

文脈を貯める仕組み

• cron で Claude Code を定期実行し、Slack・JIRA・Notion・GitHub から分析に関係する出来事（施策のリリース、障害、キャンペーンなど）を集めて memory.md にまとめる
• 分析エージェントは調査の結論を memory.md に書き戻す。次の分析は「先月の落ち込みはこれが原因だった」という前提から始められる
• プラグインは社内のプラグインマーケットプレイスで配り、全員が同じ版を使う

考え方の整理

• データ層（テーブル知識・クエリ）、分析層（仮説駆動の手順）、文脈層（組織の出来事と過去の結論）の3つに分けると、OpenAI が示した「6層のコンテキスト」の考え方とも対応する
• 「入口は振り分けだけ」にしておくと、KPI を増やしてもエージェントを足すだけで済む

注意点

• learned-corrections.md と memory.md は放っておくと膨らむ。定期的に人が読み、古い結論や間違った結論を消す
• 定期実行で Slack などを読むため、その権限とトークンの扱いを先に決める（読み取り専用にする、対象チャンネルを絞る）
• エージェントの結論を memory に書き戻すと、間違いも次に引き継がれる。重要な結論は人が確かめてから残す運用にするとよい

関連

• スキルは9つの型で棚卸しし、Gotchas 節を育てる（Anthropic 社内の運用から）

出典

• @ShingenTaguchi · 2026-04-04
• note「Ubie の分析エージェント」: note.com