MetaがAIエージェントで数百MWの電力を削減した方法：統一プラットフォームの真価

はじめに：0.1%の性能劣化が30億ユーザーに与えるインパクト

Facebook、Instagram、WhatsAppなど30億人以上のユーザーにサービスを提供するMetaにとって、0.1%の性能劣化は莫大な電力消費の増加に直結します。MetaのCapacity Efficiency組織は、この問題を**攻め（Offense）と守り（Defense）**という2つの軸で捉えました。

• Offense（攻め）: 既存システムをより効率的にするための事前のコード変更機会を発見し、デプロイすること。
• Defense（守り）: プロダクション環境でのリソース使用量を監視し、パフォーマンス回帰（Regression）を検出、原因を特定のPR（Pull Request）に紐付け、対策を講じること。

この2つのアプローチは長年にわたり効果的でしたが、決定的なボトルネックがありました。それは人間のエンジニアの時間です。どんなに優れたツールがあっても、エンジニアがすべての回帰を分析し、最適化の機会を発掘するには限界がありました。そこでMetaは、「AIが調査と解決を自動化できないか？」 という問いを立て、その答えが統合AIエージェントプラットフォームでした。

核心的な洞察：OffenseとDefenseは同じ構造を共有する

Metaのエンジニアが気づいた重要な洞察は、OffenseとDefenseが根本的に同じ問題解決構造を共有しているという点です。

# 概念コード：OffenseとDefenseの共通パイプライン
class EfficiencyPipeline:
    def __init__(self, tools: list, skills: list):
        self.tools = tools  # 標準化されたインターフェース（MCP Tools）
        self.skills = skills  # ドメイン専門知識（Skills）

    def gather_context(self, problem_context: dict):
        """ツールを使用して問題のコンテキストを収集"""
        context = {}
        for tool in self.tools:
            context[tool.name] = tool.query(problem_context)
        return context

    def apply_domain_expertise(self, context: dict):
        """スキルを使用してドメイン知識を適用"""
        for skill in self.skills:
            context = skill.apply(context)
        return context

    def create_resolution(self, context: dict) -> str:
        """最終的な解決策（PR）を生成"""
        # ... コード生成ロジック ...
        return "generated_pull_request.diff"

# 攻め（Offense）と守り（Defense）の両方で同じパイプラインを使用
offense_pipeline = EfficiencyPipeline(
    tools=[ProfilingTool(), DocSearchTool()],
    skills=[MemoizationSkill(), LoopOptimizationSkill()]
)

defense_pipeline = EfficiencyPipeline(
    tools=[ProfilingTool(), ConfigHistoryTool()],
    skills=[LoggingRegressionSkill(), SchemaChangeSkill()]
)

この構造により、Metaは2つの別々のシステムではなく、1つの統合プラットフォームを構築しました。プラットフォームは2つのレイヤーで構成されます。

1. MCP Tools（標準化されたインターフェース）: LLMがコードを呼び出すための標準インターフェースです。プロファイリングデータの取得、実験結果の取得、設定履歴の検索、コード検索、ドキュメント抽出など、各ツールは1つのタスクのみを実行します。
2. Skills（ドメイン専門知識）: パフォーマンス効率に関するドメイン専門知識をエンコードします。例えば「特定のエンドポイントのレイテンシ回帰については、上位のGraphQLエンドポイントを参照せよ」や「シリアライゼーションを処理する関数であれば、最近のスキーマ変更を探せ」といった経験則をカプセル化します。

同じツールがOffenseとDefenseの両方で使用され、Skillsだけが異なります。このアーキテクチャのおかげで、新しいユースケース（例：キャパシティプランニングエージェント、パーソナライズされた機会レコメンデーション）が追加されるたびに、データ統合を新たに行う必要はなく、既存のツールと新しいSkillを組み合わせるだけで済みます。

実際の動作：Defense（FBDetect）とOffense（AIによる機会発掘）

Defense：回帰を自動修正するAI Regression Solver

Metaの社内回帰検出ツールFBDetectは、ノイズの多いプロダクション環境で0.005%レベルの小さなパフォーマンス回帰も検出します。回帰が発見されると、従来はエンジニアが手動で原因を分析し対策を講じる必要がありました。しかし現在は、AI Regression Solverが自動的にPRを生成します。

1. コンテキスト収集（Tools）: 回帰の症状（影響を受けた関数）、根本原因（PRと変更されたファイル/行）を取得します。
2. ドメイン知識の適用（Skills）: 特定のコードベース、言語、回帰タイプに応じた緩和知識を適用します。例えば、ロギングによる回帰はサンプリングレートを上げて緩和します。
3. 解決策の生成: 新しいPRを生成し、元のPR作成者にレビューを依頼します。

結果として、約10時間の手動調査作業が約30分に短縮されました。

Offense：効率化機会を自動的にPRに変換

攻めの側面では、エンジニアが効率化の機会（例：特定の関数をメモ化してCPU使用量を削減する）を提案すると、AIエージェントが自動的にPRを生成します。

1. コンテキスト収集（Tools）: 機会のメタデータ、最適化パターンのドキュメント、類似事例、関連ファイル/関数、検証基準を取得します。
2. ドメイン知識の適用（Skills）: 特定の効率化機会タイプに関する専門家の知識を適用します。
3. 解決策の生成: ガードレール付きのコードを生成し、構文とスタイルを検証した後、エンジニアのエディタにワンクリックで適用可能な形で提供します。

注意点と限界

• Skillsのメンテナンス: ドメイン知識をSkillsとしてエンコードする作業は継続的な更新が必要です。新しい最適化パターンや回帰タイプが発見されるたびに、Skillの追加・修正が必要です。
• LLMのハルシネーション可能性: AIが生成したコードはガードレールで検証されますが、完璧ではありません。特に新しいコードベースや稀なパターンでは注意が必要です。
• 初期構築コスト: MCP ToolsとSkillsを最初に構築するにはかなりのエンジニアリングリソースが必要です。しかし、一度構築すれば新しいユースケースの追加コストは非常に低くなります。

日本開発コミュニティにおける適用コンテキスト

Metaのアプローチは、日本の大規模サービス企業（例：楽天、LINEヤフー、メルカリ）やクラウドインフラを運用する企業にとって特に有用です。日本環境で適用する際の考慮点は以下の通りです。

• レガシーシステムとの統合: Metaは比較的均一な技術スタックを持っていますが、日本の多くの企業は多様な言語やフレームワークが混在するレガシーシステムを運用しています。MCP Toolsを開発する際に、各システムに合わせた標準化されたインターフェースを定義することが最初の課題です。
• データパイプライン: パフォーマンスプロファイリングデータをリアルタイムで収集・分析できるインフラが先行して必要です。多くの日本企業がこの部分で苦労しています。
• 文化的な違い: AIが生成したコードをPRとして直接提出する文化は、日本ではまだ馴染みが薄いかもしれません。段階的に導入し、信頼を築くアプローチが必要です。

次のステップとしての学習方向

1. LLMベースのコード生成の基礎理解: LangChain、LlamaIndexなどを学習し、AIエージェントの基本的なアーキテクチャを理解しましょう。
2. MCP（Model Context Protocol）の学習: Metaが使用した標準化されたツールインターフェースの概念はMCPプロトコルと類似しています。MCP公式ドキュメントを参照してください。
3. パフォーマンスプロファイリングツールの習得: PyTorch Profiler、cProfile、JProfilerなど、言語別のプロファイリングツールを習得し、データ収集パイプラインを構築する練習をしてみましょう。

根拠資料: 本稿はMeta Engineering Blogの「Capacity efficiency at Meta: How unified AI agents optimize performance at hyperscale」を基に分析・再構成しました。

合わせて読みたい記事

• AWS欧州主権クラウド、クロスパーティション障害復旧設計のすべて
• Waypoint-1.5 ローカルPCでリアルタイム探索可能なAI生成ワールドの進化