◈ Agents & Manager/2026-03-21上級

Antigravity マルチエージェント本番パターン — 委譲設計・並列実行・コスト管理を個人開発の実務目線で

Antigravityの本番マルチエージェント編成を個人開発の実務目線で整理します。5つの編成パターンに加え、委譲の判断基準、並列度の決め方、コスト監視の指標まで、破綻させずに黒字で回すための設計を解説します。

agents⁹⁰ multi-agent²¹ orchestration¹⁵ production⁵⁹ Mission Control advanced¹⁹ enterprise²

✦ プレミアム記事

個人でアプリを6本並行運用していた頃、リリース作業が重なる時期はいつも綱渡りでした。片方のアプリのバナー配置を直している最中に、別のアプリの審査リジェクトが飛んでくる。手は二本しかありません。

マルチエージェントに初めてタスク群を委譲したとき、あの綱渡りの記憶がよみがえりました。並列で動く存在をどう束ねるか——本質は当時と変わっていませんでした。破綻するのは、たいてい調整と監視を後回しにしたときです。

ここでは、Antigravity の本番マルチエージェント編成を、理想論ではなく個人開発の実務目線で整理していきます。5つの編成パターンに加えて、「何を委譲し、何を自分の手に残すか」の判断基準と、並列度をコストで破綻させないための設計を扱います。

マルチエージェント編成の理解

単一エージェントはフォーカスされたタスクに優れていますが、エンタープライズワークフローには高度な調整が必要です：

コードレビューエージェント — スタイル違反と設計問題を識別
テスト生成エージェント — 包括的なテストスイートを作成
ドキュメンテーションエージェント — 正確なAPIドキュメント管理
セキュリティスキャナーエージェント — 脆弱性とコンプライアンス問題をフラグ
パフォーマンス分析エージェント — ボトルネックを最適化

これらのエージェントが独立して動作すると、断片化された結果が生成されます。適切な編成により、これらは開発のあらゆる決定を支援する統一されたインテリジェンスになります。

Mission Controlアーキテクチャ

Antigravityの Mission Control は編成バックボーン—調整層：

コンテキストに基づきタスクをルーティング — 適切なエージェントへ
エージェント実行間の依存関係を管理
フォールバック戦略で失敗を処理
出力を調整 — ダウンストリーム処理用
進捗追跡 — マルチステップワークフロー全体
コンテキスト保持 — エージェント呼び出し全体

// Mission Control 用 AGENTS.md 設定
{
  "mission": "code-quality-improvement",
  "version": "1.0",
  "agents": {
    "review": {
      "role": "code-quality-guardian",
      "model": "claude-opus-4",
      "context": "full-project"
    },
    "testing": {
      "role": "test-coverage-specialist",
      "model": "claude-opus-4",
      "context": "file-aware"
    },
    "documentation": {
      "role": "api-documentation-expert",
      "model": "claude-haiku-4",
      "context": "exports-only"
    }
  },
  "orchestration": {
    "type": "sequential-with-fallback",
    "timeout": 3600,
    "retryPolicy": "exponential-backoff"
  }
}

✦

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

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦委譲する／しないを検証コスト・可逆性・反復性の3軸で判断する具体的な線引き

✦並列度を「検証しきれる出力数」で決め、コストを破綻させない設計

✦タスクあたりトークン・リトライ率・承認待ち滞留の3指標による本番監視

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

パターン1：ハンドオフ付きシーケンシャル編成

使用事例： 各エージェントの出力が次のエージェント入力となる線形ワークフロー。

このパターンは以下に適します：

コード生成 → テスト → ドキュメント化
要件収集 → 設計 → 実装
セキュリティスキャン → 改善 → 検証

// Mission Control でのシーケンシャル実行フロー
export class SequentialOrchestrator {
  async executeWorkflow(task: WorkflowTask): Promise<WorkflowResult> {
    const results: AgentResult[] = [];
    let input = task.initialData;
 
    for (const agentName of task.agentSequence) {
      try {
        const agent = this.agents[agentName];
 
        // プランモード：実行前にエージェントアクションをプレビュー
        const plan = await agent.generatePlan(input);
        await this.notifyPlanGenerated(plan);
 
        // 前のステップのコンテキストで実行
        const output = await agent.execute({
          input,
          context: results,
          planApproval: true
        });
 
        results.push({
          agent: agentName,
          output,
          timestamp: Date.now(),
          success: true
        });
 
        // 出力を次のエージェント入力として使用
        input = output.transformedData;
 
      } catch (error) {
        // 失敗処理戦略
        if (task.critical) {
          throw error;
        }
        // 重大でない失敗：ログして続行
        results.push({
          agent: agentName,
          error: error.message,
          success: false
        });
      }
    }
 
    return {
      completed: true,
      results,
      finalOutput: input,
      totalDuration: this.calculateDuration(results)
    };
  }
}

プランモード実際動作：

ユーザー：「UserService を依存関係注入を使用してリファクタリング」

Mission Control プラン：
1. [code-analyzer-agent] 現在の UserService 構造を分析
   - 7つの依存関係を識別
   - インジェクションポイントをマップ

2. [refactoring-agent] リファクタリングされた実装を生成
   - コンストラクタインジェクション適用
   - 12呼び出しサイトを更新

3. [testing-agent] リファクタリングされたコード用テスト作成
   - ユニットテスト生成
   - 統合テスト生成

4. [verification-agent] 互換性を確保
   - 型チェック
   - 循環依存検出

[ユーザーがプランを承認]

実行中... (4ステップ中 3完了)

パターン2：並列エージェント実行

使用事例： 結果がマージまたは結合される独立した分析タスク。

// 独立したエージェント用の並列実行
export class ParallelOrchestrator {
  async executeParallelAgents(
    codeFile: string,
    agents: Agent[]
  ): Promise<CombinedAnalysis> {
 
    // すべてのエージェントが同時に分析
    const analyses = await Promise.all(
      agents.map(agent =>
        agent.analyze(codeFile, {
          timeout: 30000,
          priority: 'high'
        })
      )
    );
 
    // 結果を集約
    return {
      security: analyses[0],      // SecurityAgent 出力
      performance: analyses[1],   // PerformanceAgent 出力
      accessibility: analyses[2], // A11yAgent 出力
      style: analyses[3],         // StyleAgent 出力
 
      // 複合インサイト
      criticalIssues: this.mergeCritical(analyses),
      recommendations: this.rankByImpact(analyses),
      estimatedFixTime: this.calculateRemediationTime(analyses)
    };
  }
}

エンタープライズ使用事例：コードレビューパイプライン

// 本番コードレビューの並列エージェント
const parallelReviewAgents = [
  {
    agent: 'security-agent',
    analysis: 'vulnerability-scanning',
    timeout: 45000,
    context: 'dependencies + code'
  },
  {
    agent: 'performance-agent',
    analysis: 'algorithmic-complexity',
    timeout: 30000,
    context: 'code only'
  },
  {
    agent: 'accessibility-agent',
    analysis: 'a11y-compliance',
    timeout: 25000,
    context: 'ui-code only'
  },
  {
    agent: 'style-agent',
    analysis: 'code-style',
    timeout: 15000,
    context: 'code only'
  }
];
 
// プルリクエストで4つのエージェント全てが同時実行
// 本番フィードバック用に2分以内に結果集約

パターン3：動的エージェント選択を備えたルーターパターン

使用事例： 異なるリクエストタイプは異なるエージェントが必要。最適なハンドラーにルーティング。

// タスク分類に基づくスマートルーティング
export class RouterAgent {
  private routes = new Map<string, Agent>();
 
  async classifyTask(input: string): Promise<string> {
    // 軽量モデルで分類
    const classification = await claude.classify(input, {
      categories: [
        'bug-fix',
        'feature-implementation',
        'refactoring',
        'documentation',
        'infrastructure',
        'performance-optimization'
      ]
    });
 
    return classification.category;
  }
 
  async routeAndExecute(input: string): Promise<AgentResult> {
    const category = await this.classifyTask(input);
    const targetAgent = this.routes.get(category);
 
    if (!targetAgent) {
      return {
        success: false,
        error: `${category} 用のエージェントが設定されていません`
      };
    }
 
    return targetAgent.execute(input, {
      classified: true,
      category,
      confidence: this.getConfidence(category)
    });
  }
}

AGENTS.md でのルーター設定：

router:
  classification:
    model: "claude-haiku-4"  # 高速分類
    retryOnLowConfidence: true
    fallbackCategory: "general-assistant"
 
  routes:
    bug-fix:
      agent: "debugging-specialist"
      priority: "high"
      estimatedTime: "15-30 minutes"
 
    feature-implementation:
      agent: "feature-engineer"
      priority: "normal"
      estimatedTime: "2-4 hours"
 
    refactoring:
      agent: "code-architect"
      priority: "normal"
      estimatedTime: "1-3 hours"
 
    performance-optimization:
      agent: "performance-specialist"
      priority: "normal"
      estimatedTime: "30-60 minutes"

パターン4：コンセンサスベース検証

使用事例： 複数の視点からの検証が必要な重大決定。

コード変更が重大なシステムに影響する場合、複数エージェントが承認前に提案を独立して検証します。

// 重大な変更用コンセンサスパターン
export class ConsensusValidator {
  async validateCriticalChange(
    change: CodeChange,
    validators: Agent[]
  ): Promise<ValidationResult> {
 
    // 独立した評価を取得
    const assessments = await Promise.all(
      validators.map(agent =>
        agent.validate(change, { independentAnalysis: true })
      )
    );
 
    // コンセンサス計算
    const consensus = this.calculateConsensus(assessments);
 
    return {
      unanimous: consensus.agreementLevel === 1.0,
      agreementLevel: consensus.agreementLevel,
      approvalVotes: assessments.filter(a => a.approved).length,
      concerns: this.extractConcerns(assessments),
      recommendation: this.determineRecommendation(consensus),
      canProceed: consensus.agreementLevel >= 0.8
    };
  }
 
  private extractConcerns(assessments: Assessment[]): Concern[] {
    return assessments
      .filter(a => a.concerns && a.concerns.length > 0)
      .flatMap(a => a.concerns)
      .sort((a, b) => b.severity - a.severity);
  }
}

本番例：データベースマイグレーション検証

// データベースマイグレーション実行前に複数エージェントで検証
 
const migrationValidators = [
  {
    name: 'schema-safety-agent',
    role: 'スキーマ互換性を検証'
  },
  {
    name: 'performance-impact-agent',
    role: 'クエリパフォーマンス影響を分析'
  },
  {
    name: 'data-integrity-agent',
    role: 'データ保全を確保'
  },
  {
    name: 'rollback-safety-agent',
    role: 'ロールバック手順を検証'
  }
];
 
// 4つのエージェントが独立で検証
// 3/4以上が承認した場合のみマイグレーション実行

パターン5：適応学習とフィードバックループ

使用事例： エージェントはフィードバックに基づいて出力を改善し、学習フィードバックループを作成。

// 学習フィードバック付きの適応エージェント
export class AdaptiveAgent extends Agent {
  private feedbackHistory: Feedback[] = [];
  private performanceMetrics: PerformanceMetric[] = [];
 
  async execute(input: string): Promise<AgentResult> {
    // 類似の過去タスクを取得
    const similarPastTasks = await this.findSimilarTasks(input);
    const successfulApproaches = similarPastTasks
      .filter(t => t.feedback.successful)
      .map(t => t.approach);
 
    // 学習されたコンテキストで実行
    const result = await this.agent.execute(input, {
      learnedContext: successfulApproaches,
      previousAttempts: this.feedbackHistory
    });
 
    // 将来改善用にパフォーマンスを追跡
    this.performanceMetrics.push({
      taskId: result.id,
      executionTime: result.duration,
      qualityScore: await this.evaluateQuality(result),
      timestamp: Date.now()
    });
 
    return result;
  }
 
  async acceptFeedback(feedback: Feedback): void {
    this.feedbackHistory.push({
      ...feedback,
      timestamp: Date.now()
    });
 
    // フィードバックに基づいてシステムプロンプトを更新
    if (feedback.type === 'quality-issue') {
      await this.updateSystemPrompt(feedback.details);
    }
  }
}

本番設定のベストプラクティス

エンタープライズ用 AGENTS.md 構造

version: "1.0"
metadata:
  project: "backend-infrastructure"
  team: "core-platform"
  slackChannel: "#agent-alerts"
 
agents:
  code-quality-guardian:
    model: "claude-opus-4"
    contextWindow: "unlimited"
    timeout: 300
    retryPolicy: "aggressive"
    alertThreshold: "error"
 
  test-coverage-specialist:
    model: "claude-opus-4"
    contextWindow: "100k"
    timeout: 600
    retryPolicy: "gentle"
    alertThreshold: "warning"
 
  performance-analyst:
    model: "claude-opus-4"
    contextWindow: "100k"
    timeout: 180
    retryPolicy: "moderate"
    alertThreshold: "critical"
 
orchestration:
  defaultPattern: "sequential-with-parallel-fallback"
  maxConcurrentAgents: 4
  globalTimeout: 3600
  failureStrategy: "escalate-to-human"
 
  patterns:
    - name: "pull-request-review"
      agents: ["code-quality-guardian", "test-coverage-specialist"]
      type: "parallel"
 
    - name: "release-validation"
      agents: ["performance-analyst", "security-validator", "compatibility-checker"]
      type: "consensus"
      requiredAgreement: 0.8
 
monitoring:
  metricsCollection: true
  agentPerformanceTracking: true
  slackAlerts: true
  customMetrics:
    - "execution-time-by-agent"
    - "failure-rate-trends"
    - "human-override-frequency"

パフォーマンス最適化戦略

大規模コードベース向けコンテキスト管理

// パフォーマンス用の選択的コンテキスト読み込み
export class ContextOptimizer {
  async prepareContext(
    targetFile: string,
    agent: Agent
  ): Promise<ProjectContext> {
 
    const context = {
      // 常に含める：ターゲットファイル + 直接依存関係
      primary: await this.loadFileAndDependencies(targetFile),
 
      // エージェントがリクエストした場合のみ含める：より広いコンテキスト
      secondary: agent.needsBroaderContext
        ? await this.loadRelatedFiles(targetFile)
        : null,
 
      // 必要な場合のみロード：フルプロジェクトコンテキスト
      full: null, // 必要な場合のみロード
 
      // 高コスト分析を事前計算
      precomputedMetrics: await this.calculateMetrics(targetFile)
    };
 
    return context;
  }
}

キャッシングと状態管理

// エージェント出力をキャッシュして冗長な分析を回避
export class AgentCache {
  private cache = new Map<string, CachedResult>();
  private readonly TTL = 3600000; // 1時間
 
  async execute(agent: Agent, input: string): Promise<AgentResult> {
    const cacheKey = this.generateKey(agent.name, input);
 
    // キャッシュの有効性を確認
    if (this.cache.has(cacheKey)) {
      const cached = this.cache.get(cacheKey)!;
      if (Date.now() - cached.timestamp < this.TTL) {
        return cached.result;
      }
    }
 
    // 実行してキャッシュ
    const result = await agent.execute(input);
    this.cache.set(cacheKey, {
      result,
      timestamp: Date.now()
    });
 
    return result;
  }
}

エラー処理と復元力

グレースフルデグラデーション戦略

// プライマリエージェント失敗時のフォールバックチェーン
export class ResilientOrchestrator {
  private fallbackChain = [
    { agent: 'claude-opus-4', context: 'full' },
    { agent: 'claude-sonnet-3', context: 'focused' },
    { agent: 'claude-haiku-4', context: 'minimal' }
  ];
 
  async executeWithFallback(task: Task): Promise<Result> {
    for (const option of this.fallbackChain) {
      try {
        return await this.executeAgent(option.agent, task, option.context);
      } catch (error) {
        console.log(`エージェント ${option.agent} が失敗、フォールバック試行中...`);
        continue;
      }
    }
 
    throw new Error('すべてのエージェントオプションが枯渇');
  }
}

実世界エンタープライズシナリオ

シナリオ1：継続的統合パイプライン

マルチエージェントシステムがすべてのプルリクエストを検証：

静的分析エージェント — 型チェック、リンティング
セキュリティエージェント — 脆弱性スキャン、依存関係監査
テストエージェント — テスト実行、カバレッジ測定
パフォーマンスエージェント — 重大パスをベンチマーク
ドキュメンテーションエージェント — 関連ドキュメント更新

結果は重大度階層化されたPRコメントで集約。

シナリオ2：機能実装ワークフロー

マルチエージェントシステムが機能開発に協力：

要件エージェント — 仕様を明確化
アーキテクチャエージェント — システムアプローチを設計
実装エージェント — コード生成
テストエージェント — 包括的テスト作成
ドキュメンテーションエージェント — APIドキュメント作成

出力：完全にテストされ、ドキュメント化された機能レビュー準備完了。

シナリオ3：インフラストラクチャ管理

マルチエージェントシステムがクラウドインフラを管理：

インフラエージェント — IaC定義
セキュリティエージェント — コンプライアンス検証
コストエージェント — 予算影響を分析
スケーリングエージェント — キャパシティ計画を確保
監視エージェント — 可観測性を設定

結果：セキュア、コスト最適化、可観測なインフラデプロイメント。

監視と可観測性

// 包括的なマルチエージェント可観測性
export class AgentMonitoring {
  async trackExecution(orchestration: Orchestration) {
    const metrics = {
      totalAgents: orchestration.agents.length,
      parallelAgents: orchestration.parallelCount,
      totalDuration: orchestration.duration,
      agentDurations: orchestration.agents.map(a => ({
        agent: a.name,
        duration: a.executionTime,
        success: a.succeeded
      })),
      failures: orchestration.agents.filter(a => !a.succeeded),
      criticalPath: this.identifyCriticalPath(orchestration),
      efficiency: (orchestration.optimalTime / orchestration.actualTime) * 100
    };
 
    // 監視バックエンドに送信
    await this.sendMetrics(metrics);
 
    // 異常でアラート
    if (metrics.failures.length > 0) {
      await this.alertOnFailure(metrics);
    }
 
    return metrics;
  }
}

個人開発者のための「委譲する／しない」判断基準

編成パターンを知っていても、最初に迷うのは「そのタスクをエージェントに渡してよいのか」です。ここを曖昧にしたまま並列度だけ上げると、レビューのコストが生成のコストを上回ります。

私が実務で使っている線引きは、次の3つの軸です。

軸	委譲に向く	手元に残す
検証コスト	出力の正否を機械的に判定できる（テスト・型・スキーマ）	正否の判断に文脈や美的感覚が要る
失敗の可逆性	やり直しが安く、影響範囲が閉じている	課金・データ削除・公開設定など不可逆な操作を含む
反復性	同型の作業が繰り返し発生する	一度きりで、判断の前提が毎回変わる

アプリ運営で言えば、ユーザーレビューの一次分類やテストコードの雛形生成は迷わず委譲します。片や、価格改定やストア掲載文の最終判断は手元に残します。前者は間違えても安く戻せますが、後者は収益と信頼に直結し、戻すコストが跳ね上がるためです。

判断に迷うタスクは、いったん「提案まではエージェント、確定は人間」に置くのが安全です。Antigravity のプランモードはこの中間地帯と相性がよく、実行前の計画を人間が承認する形で、可逆性の低い操作にゲートを設けられます。

// 不可逆な操作には承認ゲートを挟む
{
  "agents": {
    "billing": {
      "role": "subscription-manager",
      "requiresApproval": true,      // 課金系は必ず人間が承認
      "context": "billing-scope-only"
    }
  }
}

線引きは一度決めて終わりではありません。エージェントの精度が上がれば委譲側に寄せ、事故が起きれば手元側に戻す。この可動域を持たせておくことが、破綻を避ける一番の近道でした。

コスト設計と並列度の決め方

並列エージェントは、動かした瞬間からコストが並列に膨らみます。ここを設計せずに走らせると、月末の請求で手が止まります。

現在の料金体系を前提にすると、判断の起点は上限です。AI Pro に対して AI Ultra（月$100）は Antigravity の利用上限が5倍に設定されています。上限が効いてくるのは、視覚回帰テストやマルチモーダル評価のように、1タスクあたりのトークン消費が大きいエージェントを常時並列で回すときです。逆に、短い分類や整形が中心なら Pro の枠内でも十分に足ります。

並列度を決めるとき、私は「同時に走らせるエージェント数」ではなく「同時に検証しきれる出力数」を上限にしています。5体を並列で動かしても、人間が確認できるのが1時間に2本なら、残り3本の出力は滞留し、コストだけが先に発生します。生成の並列度は、検証のスループットに合わせて絞るのが実務的です。

監視で最低限見ておきたいのは次の3つです。

指標	見る理由	異常時のサイン
タスクあたりトークン	コストの主因を特定する	特定のエージェントだけ桁が跳ねる
リトライ率	失敗ループの早期発見	指数バックオフでも収束しない
承認待ちの滞留数	並列度が過剰かを判断する	キューが単調に増え続ける

アプリ運営で AdMob の eCPM を国別・時間帯別に見ていた頃と、やっていることは似ています。全体の平均値だけを見ていると、一部の異常が平均に溶けて見えなくなる。エージェント運用でも、平均トークンではなく「どのエージェントが跳ねているか」を分解して見ることで、コストの主因に最短で辿り着けます。

コストは、生成を速くするより検証を速くするほうが下がります。テストや型で正否を自動判定できる領域を広げるほど、人間の承認待ちが減り、並列度を安全に上げられる。ここが個人開発でマルチエージェントを黒字で回すための、地味ですが効く一手でした。