ANTIGRAVITY LABEN
記事一覧/Agents & Manager
Agents & Manager/2026-03-23上級

NotebookLM × Antigravity — コードベース知識ベースとAIエージェントの高度な連携

NotebookLMの8x大規模コンテキストウィンドウをコードベース知識層として活用し、MCPブリッジ経由でAntigravityエージェントと連携する高度なアーキテクチャパターンを解説します。

NotebookLM3Antigravity338AI Agent2MCP17Codebase知識ベースエージェント連携

取り組みの背景

大規模なコードベースを扱うAIエージェントが直面する課題は、コンテキストウィンドウの制限知識の正確性です。数百万行のソースコードを丸ごとプロンプトに詰め込むことはできませんし、古い情報から学習したAIモデルでは最新のアーキテクチャ決定を正しく認識できません。

NotebookLM(Google社の先端的なAI知識管理ツール)はこの問題を解決する強力なレイヤーとなります。NotebookLMは最大8倍の拡張コンテキストウィンドウで複数のドキュメント・設計書・コードを同時分析でき、その分析結果をModel Context Protocol(MCP)経由でAntigravityエージェントに提供することで、よりコンテキストアウェアな意思決定が可能になります。


NotebookLMの8xコンテキストウィンドウと拡張性の仕組み

標準Claude APIとNotebookLMの違い

通常のClaude APIは約100Kトークンのコンテキストウィンドウを持ちますが、NotebookLMはこれを最大800Kトークン相当まで拡張できます。この拡張は以下のメカニズムで実現されます:

  1. 複数ドキュメントの段階的インデックス化 コードベース全体をMonolithic(一枚岩)に扱うのではなく、ファイル、モジュール、レイヤー単位で分割してインデックス化し、クエリに応じて関連部分のみを動的に検索ウィンドウに組み込みます。

  2. ハイブリッド検索エンジン キーワード検索+セマンティック検索(ベクトル類似度)を組み合わせることで、単なるテキストマッチではなく「この関数を呼び出している箇所」「このアーキテクチャパターンに従っている実装」といった意味的な関連性を捕捉します。

  3. キャッシュベースの段階的コンテキスト組み立て NotebookLMは過去のクエリと回答をキャッシュに保持し、次のクエリでは「前回の文脈」を保ったまま新しい情報を追加することで、効率的にコンテキストを拡張します。

コードベース向けの最適な構成

Antigravityプロジェクトで最高の効果を得るには、以下のドキュメント体系をNotebookLMに投入します:

NotebookLM 知識ベース構成例
├─ Architecture & Design
│  ├─ ARCHITECTURE.md(全体設計書)
│  ├─ DATA_MODEL.md(データ構造定義)
│  ├─ MODULE_DEPENDENCY_GRAPH.md(モジュール依存関係図)
│  └─ DESIGN_PATTERNS.md(採用パターン集)
├─ Codebase Reference
│  ├─ packages/*/README.md(各パッケージ概要)
│  ├─ src/*/INTERFACE.md(各モジュールのパブリックAPI)
│  └─ [オプション] .tsx, .ts (主要なエントリポイントのみ)
├─ Operational Knowledge
│  ├─ DEPLOYMENT.md
│  ├─ TESTING_STRATEGY.md
│  ├─ PERFORMANCE_TUNING.md
│  └─ TROUBLESHOOTING.md
└─ Decision Records
   ├─ ADR (Architecture Decision Records) 一式
   └─ RFC (Request for Comments) 実装済み分

重要なのは、すべてのコードをそのまま投入するのではなく、メタデータと設計意図を優先することです。NotebookLMは「これはなぜこう実装されているのか」という背景を理解することで、エージェントの質問に対してより深い回答を返せるようになります。


MCPブリッジの実装:NotebookLM ↔ Antigravityエージェント間の通信

MCPサーバーとしてのNotebookLM

Model Context Protocol(MCP)は、LLMアプリケーションが外部ツール・データベース・APIに安全かつ標準化された方法でアクセスするための規約です。NotebookLMをMCPサーバーとして実装することで、Antigravityエージェントは「自分のコンテキストウィンドウ内のメモリ」のような感覚で、常に必要な知識にアクセスできます。

基本的なMCPサーバーの実装は以下のようになります:

// mcp/notebooklm-server.ts
import Anthropic from "@anthropic-ai/sdk";
 
interface NotebookQuery {
  notebook_id: string;
  query: string;
  max_results?: number;
  context_depth?: "shallow" | "deep"; // 浅い = 直接関連, 深い = 多層的関連性
}
 
interface ContextResult {
  source: string;
  relevance: number; // 0.0 ~ 1.0
  content: string;
  related_items: string[];
}
 
class NotebookLMMCPServer {
  private client: Anthropic;
  private notebookCache: Map<string, string> = new Map();
 
  async queryNotebook(req: NotebookQuery): Promise<ContextResult[]> {
    // 1. NotebookLMに存在するノートブックから該当セッションを取得
    const notebookContent = await this.fetchNotebook(req.notebook_id);
 
    // 2. Claudeに「コンテキストウィンドウ内で」検索を実行
    const message = await this.client.messages.create({
      model: "claude-3-5-sonnet-20241022",
      max_tokens: 2000,
      system: `You are a knowledge retrieval specialist for a codebase documented in NotebookLM.
Your task is to search the provided codebase documentation and return relevant context.
For each result, include:
- source: the file/section name
- relevance: a confidence score 0.0-1.0
- content: the actual relevant text (max 500 chars each)
- related_items: references to connected concepts`,
      messages: [
        {
          role: "user",
          content: `Codebase Documentation:\n\n${notebookContent}\n\nQuery: ${req.query}\n\nReturn up to ${req.max_results || 5} most relevant items as JSON array.`,
        },
      ],
    });
 
    // 3. 結果をパース&標準化
    return this.parseResults(message.content[0]);
  }
 
  private async fetchNotebook(notebookId: string): Promise<string> {
    // NotebookLM Enterprise API or stored export
    if (this.notebookCache.has(notebookId)) {
      return this.notebookCache.get(notebookId)!;
    }
 
    // TODO: Call NotebookLM API to fetch notebook
    // For now, assume pre-exported markdown/PDF content
    const content = await this.loadFromStorage(notebookId);
    this.notebookCache.set(notebookId, content);
    return content;
  }
 
  private parseResults(content: any): ContextResult[] {
    // Parse Claude's structured response into ContextResult[]
    try {
      return JSON.parse(content.text);
    } catch {
      return [];
    }
  }
}
 
export default NotebookLMMCPServer;

このMCPサーバーを起動すると、Antigravityエージェント側では以下のように呼び出せます:

// Antigravity agent にMCPツールを登録
agent.registerMCPTool("notebook_query", {
  description: "Query the NotebookLM codebase knowledge base",
  inputSchema: {
    type: "object",
    properties: {
      query: {
        type: "string",
        description: "Natural language question about the codebase",
      },
      context_depth: {
        type: "string",
        enum: ["shallow", "deep"],
        description: "How deep to search for related concepts",
      },
    },
  },
});

エージェントのクエリフロー

実際のエージェント動作フローは以下のようになります:

User: "getUserProfileコンポーネントの実装をリファクタリングして、
       Suspenseパターンに対応させたい"

↓ [Antigravity Manager Surface]

Agent Planning:
  1. notebook_query("getUserProfile のレイアウト・責務・依存関係")
  2. notebook_query("プロジェクトのSuspense採用パターン")
  3. notebook_query("類似コンポーネントのリファクタリング事例")

↓ [NotebookLM MCP Server]

Context Retrieval:
  - getUserProfileコンポーネントの現在の設計意図
  - 周辺で使用している関数・型定義
  - Suspenseを使った他コンポーネント実装
  - ADRレコード:「なぜこの設計を採用したのか」

↓ [Agent Decision Making]

Code Generation:
  function getUserProfile_refactored() {
    // NotebookLMから取得した背景知識に基づいて
    // 要件を満たしつつ、プロジェクトの慣例に準拠した実装を生成
  }

↓ [Human Review in Antigravity IDE]

Developer:
  ✓ 生成されたコードを確認・修正 → Commit

マルチエージェント協調とManager Surface

知識分散による役割分担

NotebookLMベースの知識層により、複数のエージェントが異なる専門性を持つようになります:

エージェント知識ベース得意タスク
Architecture AgentARCHITECTURE.md, ADRシステム全体の最適化、マイグレーション計画
Code Quality AgentCODE_PATTERNS.md, TESTING_STRATEGY.mdコード生成、リファクタリング、テスト追加
Performance AgentPERFORMANCE_TUNING.md, DEPENDENCY_GRAPH.mdボトルネック分析、最適化提案
Documentation Agent全ドキュメントコード例の自動生成、ガイド更新

AntigravityのManager Surfaceは、これら複数エージェントのタスク分解と結果の統合を行います:

// Antigravity Manager Surface 統合例
class CodebaseCoordinationManager {
  async refactorComponent(
    componentPath: string,
    requirement: string
  ): Promise<RefactoringPlan> {
    // 1. Architecture Agent: 影響範囲の特定
    const impactAnalysis = await this.architectureAgent.analyze(
      `What components depend on ${componentPath}?`
    );
 
    // 2. Code Quality Agent: 最適な実装パターン
    const implementationPattern = await this.codeQualityAgent.suggest(
      `Refactor ${componentPath} to: ${requirement}`
    );
 
    // 3. Performance Agent: 性能上の懸念事項
    const perfReview = await this.performanceAgent.review(
      implementationPattern,
      impactAnalysis
    );
 
    // 4. すべての意見を統合
    return this.synthesizeResults({
      impact: impactAnalysis,
      implementation: implementationPattern,
      performance: perfReview,
    });
  }
}

知識の一貫性維持

複数エージェントが同じNotebookLM知識ベースにアクセスすることで、知識の一貫性が自動的に保証されます:

  • エージェントA が「このモジュールはイベント駆動」と判断
  • エージェントB が「同じモジュールは責務X」と判断

上記のような矛盾が起きにくくなります。すべて同じ知識源(NotebookLM)から引き出しているため、「前提」が統一されます。


実装シナリオ:大規模リファクタリング

ユースケース

500以上のTypeScript/React ファイルからなるプロジェクトで、「古いRedux状態管理を新しいContext API + Zustandに移行したい」という大規模リファクタリングを実施する場合を想定します。

Stage 1: 知識ベースの準備

まず、NotebookLMに投入するドキュメントを準備します:

# state-management-migration.md
 
## Current State (Redux)
- Store structure: src/store/redux/*
- Selectors pattern: src/selectors/*
- Action creators: src/actions/*
- Key pain points: [boilerplate, DevTools dependency]
 
## Target State (Context + Zustand)
- Design: stores/zustand/*.ts
- Integration points with React components
- Migration path: phase 1 (global state) → phase 2 (local modules)
 
## Affected Components & Dependencies Graph
[自動生成されたDOT形式のグラフ]
 
## ADR: Why Zustand?
Decision: 2026-03-15
Rationale: Better DX, smaller bundle, no boilerplate
Trade-offs: [...]
 
## Migration Checklist by Priority
[priority] Module → [estimated effort] → [risk level]

NotebookLMがこれらを解析すると、以下の能力を獲得します:

  • 「ReduxのSelectorを見たら、同等のZustandセレクターを自動生成できる」
  • 「古いconnect()HOCを見たら、その依存関係から影響を受けるコンポーネント全体を把握できる」
  • 「新しいパターンへの移行手順を優先度順に提案できる」

Stage 2: Antigravityエージェントの投入

// Antigravity IDE のコマンドパレット例
> Refactor: Redux → Zustand (全体)
 
Manager Surface が以下を実行:
 
1. [Architecture Agent]
   Query: "redux状態管理全体の依存関係とセレクター一覧"
   → NotebookLM から store structure を取得
 
2. [Code Quality Agent]
   Query: "reduxのactionCreatorパターンから等価なZustandアクションを生成"
   → migration pattern に基づいて batch refactoring プラン作成
 
3. [Performance Agent]
   Query: "新しいアーキテクチャでバンドルサイズとレンダリング性能は改善されるか"
   → 影響分析、metrics 予測
 
4. [Documentation Agent]
   Query: "この移行に伴う開発ガイド更新"
MIGRATION_GUIDE.md 自動生成
 
↓ Manager が統合
 
Refactoring Plan:
├─ Phase 1: Global Store Migration (70 files)
├─ Phase 2: Module-Local State (43 files)
├─ Phase 3: Cleanup & Tests (automated)
├─ Rollback strategy & checkpoints
└─ Performance metrics baseline → post-migration

Stage 3: インクリメンタル実行と学習ループ

// Antigravity UI での段階的実行
for (const phase of refactoringPlan.phases) {
  const results = await executePhase(phase);
 
  // テスト実行
  const testResults = await runTests();
 
  if (!testResults.passed) {
    // NotebookLMに学習フィードバック
    await notebookLM.addNote(
      `Migration Issue: ${testResults.failedTest}
       Root Cause: [分析結果]
       Solution Applied: [修正内容]
       Lessons for next phase: [...]`
    );
 
    // 次フェーズの計画を再調整
    refactoringPlan.phases[i+1] = await
      archAgent.replan(notebookLM.getUpdatedKnowledge());
  }
}

このループを回すことで、単なる自動化ツールではなく、プロジェクト固有の経験を蓄積するエージェントシステムになります。


NotebookLMの更新と同期戦略

継続的な知識ベース維持

NotebookLMの有効性は、ドキュメントの鮮度と正確性に直結します。以下の戦略で自動的に知識を最新に保ちます:

// 継続的同期パイプライン
class NotebookSyncPipeline {
  async runDailySync() {
    // 1. ソースコード変更の検出
    const changes = await git.getDailyDiff([
      "src/",
      "docs/",
      ".adr-dir/"
    ]);
 
    // 2. 変更が「ドキュメント更新が必要」な種類か判定
    for (const change of changes) {
      const needsUpdate = await this.classifyChange(change);
 
      if (needsUpdate === "ARCHITECTURE_CHANGE") {
        // ARCHITECTURE.md + ADR を自動生成
        await this.updateArchitectureDoc(change);
      } else if (needsUpdate === "INTERFACE_CHANGE") {
        // interfaces.md, API_REFERENCE.md を自動生成
        await this.updateInterfaceDoc(change);
      }
    }
 
    // 3. 更新されたドキュメントをNotebookLMに投入
    await notebookLM.sync({
      replaceSections: updatedSections,
      retainHistory: true, // 過去の推移も保持
    });
  }
}

外部エンタープライズAPI との連携

Google が提供する NotebookLM Enterprise API を使用することで、さらに深い統合が可能になります:

// NotebookLM Enterprise API 利用例
import { NotebookLMClient } from "@google-cloud/notebooklm";
 
const client = new NotebookLMClient({
  apiKey: process.env.NOTEBOOKLM_API_KEY,
});
 
// 1. Podcast generation API: 設計書から音声ガイドを生成
const podcast = await client.generatePodcast({
  notebookId: "my-codebase-notebook",
  sourceDocuments: ["ARCHITECTURE.md", "MIGRATION_GUIDE.md"],
  audienceLevel: "advanced_developer",
  format: "discussion", // narrator + expert discussion
});
 
// 生成されたポッドキャストを新規チームメンバーのオンボーディングで活用
await onboarding.addResource({
  type: "audio",
  url: podcast.publicUrl,
  title: "Architecture Deep Dive",
});
 
// 2. Notebook management API: ノートブック間の参照構造を管理
await client.createNotebookCollection({
  name: "Antigravity Codebase",
  notebooks: [
    { id: "arch-notebook", role: "source_of_truth" },
    { id: "performance-notebook", role: "derived_analysis" },
    { id: "migration-notebook", role: "execution_plan" },
  ],
  crossReferences: true, // ノートブック間の相互参照を有効化
});

まとめ

NotebookLMをコードベース知識ベースとして機能させ、Antigravityエージェントと MCPブリッジで連携することで:

  • コンテキスト拡張: 8x ウィンドウによる、より深い理解
  • 知識の一貫性: すべてのエージェントが同じ真実の源から学習
  • 複雑度の管理: 大規模リファクタリングも段階的・安全に実行可能
  • 経験の蓄積: ADR や migration notes が自動で知識ベースに追加される

このアーキテクチャは、単なるコード生成ツールから、プロジェクト固有の知識を蓄積し、時間とともにインテリジェントになるシステムへの進化を実現します。

次のステップは、Antigravityエージェントのメモリパターンや MCPサーバーの実装ガイドを参考に、自社のプロジェクトで試験運用を始めることです。

シェア

お読みいただきありがとうございます

Antigravity Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

もしこの記事がお役に立ちましたら、チップ(¥150)で応援いただけると大変励みになります。広告なしでの運営を続けるため、皆さまのご支援が大きな力になっています。

関連記事

Agents & Manager2026-07-17
エージェントに渡した参照メモの7割は届いていませんでした — head で切る運用の限界を測った記録
定期実行のエージェントに参照メモを cat と head で渡していたところ、肝心な行が黙って落ちていました。切り取り位置を実測し、行数ではなくセクション単位の契約に置き換えるまでの記録です。
Agents & Manager2026-07-16
AGENTS.md を厚くするほどルールが守られなくなった — 遵守率を計測して指示を削るまで
AGENTS.md に書いたルールが守られない。衝突でも読み込み失敗でもなく、単に無視されていました。ルールを検証可能な述語に分解し、遵守率を継続計測して指示を削るまでの運用記録です。
Agents & Manager2026-07-16
作業中のエージェントに、次の指示をいつ渡すか — 待つ・割り込む・積むを実運用で測りました
Antigravity v2.3.0 で入ったメッセージのキューイングと Send Now。待つ・割り込む・積むの三択を同じ物差しで測り、積んだ指示が古くなる問題と、前提スタンプで手戻りを22%から9%へ下げた記録をまとめました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →