原題: Inside Meta’s Home Grown AI Analytics Agent
著者: Analytics at Meta
公開日: 2026年3月
ソースURL: https://medium.com/@AnalyticsAtMeta/inside-metas-home-grown-ai-analytics-agent-4ea6779acfb3
アーカイブ日: 2026-04-03
仮説はシンプルだった。「データサイエンティストが繰り返し受ける似たような分析依頼を、AIエージェントが自律的にこなせるか？」
Metaのデータサイエンティストの一人が週末に自分のdevserverでプロトタイプを作った。内部データウェアハウスに対してSQLを実行でき、同僚の過去クエリ履歴をコンテキストとして持つエージェントだ。
最初の実戦テストは、ヘルスモニタリング指標の急落診断だった。エージェントは自力で適切なテーブルを特定し、複数の診断クエリを実行し、根本原因を最近のコード変更に追跡した。
これが「あ、できる」という転換点になった。その後6ヶ月で、MetaのデータサイエンティストとデータエンジニアのうちWeekly Active Userが77%に達した。さらにデータ職以外のユーザーはその約5倍いる。
成功の核心は、データ分析の意外な特性にある。
Metaのデータ科学者を調べると、ある日に実行するクエリの88%が、過去90日以内にすでに使ったテーブルのみを参照している。つまり分析の大部分は完全に新しい探索ではなく、慣れ親しんだ領域の中での作業だ。
これは制約された環境を生む。そして制約された環境こそ、AIが真価を発揮するところだ。AlphaGoが現実世界ではなく固定ルールのゲームで成功したのと同じ理由で、Analytics Agentは「各アナリストの仕事が境界付きの学習可能な領域に収まる」という特性を活かしている。
Metaのデータウェアハウスには数百万のテーブルがあるが、個々のアナリストが使うのは数十程度。エージェントにその人の過去クエリ履歴（どのテーブルを使い、どう使い、どんな質問をするか）を与えることで、「この人にとって何が重要なデータか」というコンテキストを最初から持たせた。
処理の流れは大きく3段階：
① Discover Data & Gather Context（データ発見とコンテキスト収集）
エージェントが分析を始める前に、成功に必要なリソースを集める。
データサイエンティストの知見は多くの場合、コードリポジトリではなくクエリエディタやノートブックに散在している。これを橋渡しするために「共有メモリ」を構築する。オフラインLLMパイプラインが従業員の過去クエリを処理し、使用テーブル・利用パターン・分析スタイルの説明を生成。これらのサマリーはリアルタイムで更新・保存され、エージェントがいつでも取得できる。
さらに個人履歴に加え、ドキュメント・データウェアハウスメタデータ・データパイプラインのソースコード・セマンティックモデルもインデックス化して検索可能にする。
② Iterative Reasoning Loop（反復推論ループ）
「先週火曜にサインアップが減ったのはなぜ？」という質問に対して：
このサイクルがエージェント内部で完結する。アナリストはすべてのクエリを見て方向修正できるが、多くの場合エージェントが自己修正する。
③ Answer（回答の透明性）
Analytics Agentが出す数値にはすべて、それを生成したSQLクエリが添付される。「間違った数値を自信満々に提示する」より「確認可能な答えを出す」方が分析ツールとして価値がある。
基本機能が動いた後、ユーザーからカスタマイズの要望が出た。それに応えて3層の知識システムを構築した。
Cookbooks（クックブック）
エントリーポイント。特定チームやドメインのエージェントを専門家に変えるために必要なすべてをバンドルしたパッケージ。クックブックから会話を始めると、エージェントはすでにチームのテーブル・指標・ベストプラクティス・分析パターンを知っている。
Recipes（レシピ）
分析の「手順書」。「どう分析するか」を定義する。
Ingredients（食材）
「何を意味するか」を定義する知識資産。セマンティックモデルは「l7_activeというカラムは、チャーンアカウントを除いた過去7日間のアクティブユーザー数（国・日付単位）を意味する」という情報を持つ。このような定義を一度エンコードすれば、そのドメインのすべての会話で利用できる。
3層の関係:
1. 反証可能な賭けから始める
「88%のクエリが過去90日のテーブルに依存する」という具体的かつ測定可能な仮説があったから、エージェントが機能する根拠を事前に示せた。「AIで分析を改善できる」という漠然したピッチではなく、「この特性が存在するから自動化できる」という論理から入った。
2. 個人コンテキストがキラー機能
データウェアハウスへのアクセスがあるだけでは「データベースにアクセスできるチャットボット」に過ぎない。個人の過去クエリ履歴によって「ドメイン専門家」に変わる。コンテキストこそが変換点だ。
3. 作業を見せる
分析AIにとって「作業を見せること」はオプションではなくコア機能要件。確認できない精度は役に立たない。
4. コミュニティはプロダクトチーム
H2 2025だけで750件以上のフィードバック投稿、130件以上のベストプラクティス共有。ユーザーがprototypした機能をチームがproductionに昇格させた。オープンベータ時点で4,500件以上のコミュニティ作成レシピが150,000回使用されていた。
5. 早く出して速く学ぶ
週末のプロトタイプから全社展開まで約6ヶ月。「最大のリスクは早すぎるリリースではなく、遅すぎるリリース」。
この記事の核心にある「88%のクエリが過去90日のテーブルのみに依存する」というデータは印象的だ。AIエージェントの成功は、「問題空間がいかに制約されているか」に直接依存するという洞察——「制約された環境でAIは輝く」——は、データ分析を超えて多くの領域に適用できる普遍的原則だ。
Cookbooks/Recipes/Ingredientsというアーキテクチャは、「ドメイン知識をどう組織するか」という設計問題への一つの実践的回答でもある。「分析の方法（Recipes）」と「データの意味（Ingredients）」を分離するという設計判断は、エンタープライズAIシステム設計において広く参照できる構造だ。
Metaという特殊な環境での話ではあるが、「作業履歴から個人の専門ドメインを学習し、それをコンテキストとして利用する」というアプローチは、規模を問わずAIエージェントの実用化に向けた普遍的なパターンを示している。
タグ: #AI #エージェント #データエンジニアリング #分析 #Meta #LLM #RAG