ANTIGRAVITY LABEN
記事一覧/Agents & Manager
Agents & Manager/2026-04-19上級

Antigravity Background Agent 上級実践ガイド — タスク設計・並列実行・CI/CD統合の完全メソッド

Background Agentの内部構造から、タスク設計・AGENTS.md最適化・git worktree並列実行・GitHub Actions統合・コスト管理まで網羅。有料に値する実践ノウハウを1記事に凝縮した上級完全ガイドです。

background-agent8antigravity435advanced19CI/CD17git-worktree3並列実行4コスト最適化6AGENTS-md3

Background Agentを試してみたものの、「なんとなく使ってはいるが、本当に効果的に使えている気がしない」という感覚はありませんか?

私自身、最初の1〜2週間はそうでした。起動して待つ、途中で確認する、思った通りの結果にならない……そのサイクルを繰り返していて、「これ、本当に使えるのか?」と正直疑っていました。

転機になったのは、Background Agentがなぜ普通のエージェントと根本的に違うのかをアーキテクチャレベルで理解したときです。その後、タスク設計を見直し、AGENTS.mdを整備し、git worktreeと組み合わせるようになってから、開発の進み方が大きく変わりました。

ここではBackground Agentを「なんとなく使うツール」から「本番開発に組み込んだ自律的な協働者」に変えるために必要なことを、すべて書き出しました。

Background Agentが「単なる非同期処理」と根本的に違う理由

Antigravityのインラインエージェントとの最大の違いは、Background Agentが完全に隔離されたLinux仮想マシン上で動作する点です。これは「非同期で動く」という話ではなく、アーキテクチャが根本から異なります。

サンドボックスVMの内部構造

Background Agentが起動すると、Antigravityはあなたのリポジトリのスナップショットを取り、独立したVM環境を立ち上げます。このVMは:

  • あなたのローカル環境には直接アクセスしない
  • ネットワークはインターネットに出られるが、ローカルのlocalhost:3000などは参照できない
  • ファイルシステムへの書き込みはVM内で完結し、完了時にプルリクエスト(またはコミット)として返ってくる
  • VSCodeのデバッガやdevtoolsは使用不可(CLIツールのみ)

この隔離性がBackground Agentの強さであり、同時に制約でもあります。「ブラウザで確認しながら修正してほしい」「ローカルDBに接続して動作確認してほしい」といった用途には向いていません。一方で、「コードを解析して改善する」「テストを生成する」「ドキュメントを更新する」といったタスクでは、邪魔されずに長時間集中して作業できます。

通常エージェントとの使い分け判断基準

どちらのエージェントを使うべきか、私は次の基準で判断しています:

Background Agentに適しているタスク:

  • 完了まで5分以上かかりそうなもの
  • 結果を確認するまで自分の判断が不要なもの
  • ローカル環境の状態(実行中サーバー、DB接続など)に依存しないもの
  • 明確な「完了条件」を事前に言語化できるもの

通常エージェントが適しているタスク:

  • 「こんな感じで」という対話が必要なもの
  • UIの見た目を確認しながら進めたいもの
  • 10分以内に終わりそうなシンプルなもの
  • 設計判断が途中で必要になりそうなもの

特に「完了条件を言語化できるか」は重要です。これが曖昧だと、Background Agentはそれなりに仕事をしてくれますが、期待通りの結果にならないことが多くなります。

成果を最大化するタスク仕様書の設計

Background Agentへの指示は、インタラクティブなチャットとは根本的に違います。対話による補正ができないため、最初の指示の質がそのまま結果の質に直結します。

タスク仕様書の構造

私が実際に使っているテンプレートを共有します。このフォーマットを使うようになってから、Background Agentの成功率が体感で7割から9割以上に上がりました:

## 目標
UserProfile コンポーネントのテストカバレッジを80%以上に引き上げてください。
現在のカバレッジ: 約35%(`npx vitest coverage` で確認済み)
 
## 対象ファイル
- src/components/UserProfile.tsx(主要対象)
- src/components/UserProfile.test.tsx(新規または追記)
- src/types/user.ts(参照のみ)
 
## 使用するテストフレームワーク
- vitest + @testing-library/react
- モックは vi.mock() を使用
- ユーザーイベントは @testing-library/user-event
 
## 完了条件(全て満たすこと)
1. `npx vitest coverage` でカバレッジ80%以上
2. 既存のテストが全てパス(変更禁止)
3. TypeScript のビルドエラーがゼロ
4. 各テストケースに日本語のdescribeとitコメント付き
 
## 禁止事項
- UserProfile.tsx の既存の props インターフェースを変更しない
- 外部APIのモックに実際のエンドポイントURLを使わない
- スナップショットテストは作成しない(メンテコストが高いため)
 
## 参考情報
- 既存のAuthコンポーネントのテスト(src/components/Auth.test.tsx)が参考になります
- テスト実行: `npx vitest run --reporter=verbose`

このテンプレートで重要なのは「禁止事項」セクションです。Background Agentは指示されたことをやろうとするあまり、既存コードを予期しない形で変更することがあります。変えてほしくないものを明示することで、大幅に品質が安定します。

タスクの粒度設計

「大きすぎるタスク」はBackground Agentが得意ではありません。具体的には:

# ❌ 大きすぎるタスク(失敗リスク高)
"プロジェクト全体をリファクタリングして、型安全性を向上させてください"
 
# ✅ 適切な粒度(1つのセッションで完結)
"src/api/ ディレクトリ内のすべてのAPIクライアント関数に、
 zod スキーマを使った入出力バリデーションを追加してください"

私の経験では、Background Agentが最も安定して動くのは「1〜3時間の人間の作業に相当するタスク」です。半日以上かかるようなタスクは、サブタスクに分割して順番に実行する方が、最終的に速く・品質高く完了できます。

事前のコンテキスト投入

Background Agentを起動する前に、関連するファイルやドキュメントを「Knowledge Items」として追加しておくと、精度が大きく向上します。特に以下は必ず追加しています:

  • プロジェクトのアーキテクチャ設計ドキュメント
  • コーディング規約(CONTRIBUTING.md など)
  • 関連する型定義ファイル(types/ ディレクトリ)
  • エラーが起きやすい部分のコメント

AGENTS.md でプロジェクトコンテキストを自動注入する

Background Agentに毎回同じコンテキストを指示するのは非効率です。AGENTS.md を適切に設計すると、そのファイルに書いたことが全てのエージェントセッションに自動で注入されます。

プロジェクト専用 AGENTS.md の設計

# プロジェクト: MyApp — エージェント向け作業指針
 
## このプロジェクトについて
Next.js 16 App Router + TypeScript + Cloudflare Workers で構築された
個人向けタスク管理SaaSです。日英2言語対応(next-intl v4)。
 
## 技術的な制約(必読)
- Node.js は使用不可(Cloudflare Workers 環境)
- `fs` モジュールは使用不可 — ファイルI/Oはすべて ASSETS バインディング経由
- npm run build の前に `node scripts/generate-content.mjs` が必要(prebuildに設定済み)
- テストランナー: vitest(jest ではない)
 
## コーディング規約
- 型定義は `src/types/` に集中管理
- コンポーネントは Server/Client を明示('use client' ディレクティブ)
- APIルートは `src/app/api/` 配下、命名は `route.ts`
- 日本語コメントを推奨(英語も可)
 
## よくある間違いと回避方法
### ❌ よくやってしまうこと
- `headers()` を同期で呼ぶ → async/await 必須
- `cookies().set()` をクライアントコンポーネントで使う → サーバーコンポーネントのみ
 
### ✅ 正しいパターン
- 環境変数: `process.env.NEXT_PUBLIC_*` (クライアント) / `process.env.*` (サーバー)
- DBアクセス: `getCloudflareContext().env.DB` を使用
 
## テスト実行コマンド
\`\`\`bash
npx vitest run          # 全テスト実行
npx vitest coverage     # カバレッジ計測
npx tsc --noEmit        # 型チェック
\`\`\`
 
## 変更してはいけないファイル
- src/config/pricing.ts(Stripe price ID が格納されている)
- public/robots.txt(SEO設定)
- wrangler.toml(Cloudflare設定)

この AGENTS.md があるだけで、Background Agentへの指示から「このプロジェクトでは fs は使えません」「テストはvitestです」といった説明が不要になります。プロジェクト固有の制約が多いほど、AGENTS.md の効果は大きくなります。

ディレクトリ別 AGENTS.md の活用

プロジェクトルートだけでなく、特定のディレクトリにも AGENTS.md を置けます。私は以下のような構成にしています:

project/
├── AGENTS.md              ← プロジェクト全体の共通ルール
├── src/
│   ├── components/
│   │   └── AGENTS.md     ← UIコンポーネントの設計ルール
│   └── api/
│       └── AGENTS.md     ← APIルートの実装規約
└── scripts/
    └── AGENTS.md         ← スクリプト変更時の注意点

複数Background Agentの並列実行戦略

単一のBackground Agentでも十分強力ですが、複数を並列で走らせることで開発速度をさらに上げられます。ただし、無計画に並列実行すると git の競合地獄に陥ります。

並列化できるタスクの特定

並列実行が安全なのは、変更するファイルが重複しないタスクの組み合わせです:

# ✅ 安全な並列実行の例
エージェントA: src/components/ 配下のテスト追加
エージェントB: src/api/ 配下のバリデーション強化
エージェントC: docs/ 配下のAPI仕様書更新

# ❌ 危険な並列実行(同じファイルを変更する可能性)
エージェントA: src/types/user.ts の型を改善
エージェントB: UserProfile コンポーネントをリファクタリング
(→ 両者が user.ts を変更する可能性)

git worktree との統合

複数のBackground Agentを安全に並列実行するために、git worktree を使います。各エージェントに独立したworktreeを割り当てることで、ブランチ競合を根本から防げます。

# worktreeの事前準備スクリプト
#\!/bin/bash
 
PROJECT_DIR="$HOME/myapp"
WORKTREES_DIR="$HOME/myapp-worktrees"
 
# 3つの並列タスク用worktreeを作成
for task in "test-coverage" "api-validation" "docs-update"; do
  branch="agent/$task-$(date +%Y%m%d)"
  worktree_path="$WORKTREES_DIR/$task"
  
  # worktreeを作成(新規ブランチ)
  git -C "$PROJECT_DIR" worktree add \
    -b "$branch" \
    "$worktree_path" \
    main
  
  echo "✅ Created worktree: $worktree_path (branch: $branch)"
done
 
# 確認
git -C "$PROJECT_DIR" worktree list

Background Agentを起動する際は、各worktreeのパスを指定します。エージェントAは myapp-worktrees/test-coverage 上で作業し、エージェントBは myapp-worktrees/api-validation 上で作業するため、完全に独立して動作します。

全エージェントが完了したら:

# 各worktreeのブランチをmainにマージ
for task in "test-coverage" "api-validation" "docs-update"; do
  branch=$(git -C "$WORKTREES_DIR/$task" rev-parse --abbrev-ref HEAD)
  
  echo "Merging $branch..."
  git -C "$PROJECT_DIR" merge --no-ff "$branch" \
    -m "Merge: agent/$task auto-generated changes"
  
  # 完了したworktreeを削除
  git -C "$PROJECT_DIR" worktree remove "$WORKTREES_DIR/$task"
  git -C "$PROJECT_DIR" branch -d "$branch"
done

関連する実践ガイドとして、Antigravity × git worktree で並列開発を加速するも参考になります。

監視・エラーハンドリング・リカバリ

Background Agentは「放置して完了を待つ」のが基本ですが、完全に目を離すのも禁物です。特に長時間のタスクでは、適切な監視が最終品質を左右します。

チェックポイントの活用

Antigravityは実行中のエージェントの進捗を定期的にチェックポイントとして保存します。タスクが途中で失敗した場合も、チェックポイントから再開できます。

進捗確認のタイミングとして、私が推奨するのは:

  • タスク開始直後(5〜10分後):指示が正しく理解されているか確認
  • 中間点(タスクの折り返し付近):方向性が正しいか確認
  • 完了後:全ての完了条件を満たしているか確認

よくある失敗パターンと対処

パターン1: コンテキスト不足による迷走

症状:エージェントが同じ場所を行ったり来たりして、進展しありません。

原因:プロジェクトの構造や制約が十分に伝わっていありません。

対処:AGENTS.md を更新し、特に「変更してはいけない箇所」と「推奨する実装パターン」を追記します。該当タスクを小さく分割して再実行します。

パターン2: テストが壊れる変更

症状:コードは改善されたが、既存のテストが失敗しています。

原因:「完了条件に既存テストのパス」が明示されていなかった。

対処:タスク仕様書に必ず 既存テストが全てパスすること を完了条件として記載します。Background Agentに「まず npm test を実行して現状を確認してから作業開始」と明示します。

パターン3: TypeScript エラーの放置

症状:実装は動作するが、TypeScript の型エラーが残っています。

原因:型チェックの実行が完了条件に含まれていなかった。

対処:完了条件に npx tsc --noEmit でエラーゼロ を必ず含める。

パターン4: 意図しないファイルの変更

症状:指示していないファイルも変更されていた。

原因:エージェントが関連ファイルの改善を「善意で」行った。

対処:AGENTS.md の「変更してはいけないファイル」リストを充実させる。タスク仕様書の「禁止事項」に明示的に記載します。

CI/CDパイプラインへの統合

ここからが、Background Agentを本番開発に組み込む本題です。GitHub Actions と連携させることで、PR作成時に自動でBackground Agentがタスクを実行する仕組みを構築できます。

テスト生成の自動化

新しいコードがプッシュされたとき、Background Agentが自動でテストを生成・追加するワークフローです:

# .github/workflows/auto-test-generation.yml
name: Auto Test Generation
 
on:
  pull_request:
    types: [opened]
    paths:
      - 'src/components/**'
      - 'src/api/**'
 
jobs:
  generate-tests:
    runs-on: ubuntu-latest
    # テストカバレッジが70%未満のファイルのみ対象
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          
      - name: Install dependencies
        run: npm ci
        
      - name: Check coverage
        id: coverage-check
        run: |
          npx vitest coverage --reporter=json 2>/dev/null || true
          
          # カバレッジが低いファイルを特定
          LOW_COVERAGE_FILES=$(node -e "
            const report = require('./coverage/coverage-summary.json');
            const files = Object.entries(report)
              .filter(([file, data]) => 
                file \!== 'total' && 
                data.lines.pct < 70
              )
              .map(([file]) => file)
              .slice(0, 5); // 最大5ファイル
            console.log(files.join(','));
          ")
          echo "files=$LOW_COVERAGE_FILES" >> $GITHUB_OUTPUT
          
      - name: Trigger Background Agent for test generation
        if: steps.coverage-check.outputs.files \!= ''
        env:
          ANTIGRAVITY_API_KEY: ${{ secrets.ANTIGRAVITY_API_KEY }}
        run: |
          FILES="${{ steps.coverage-check.outputs.files }}"
          
          # Background Agent の起動(APIが利用可能な場合)
          curl -X POST "https://api.antigravity.google/v1/agents/background" \
            -H "Authorization: Bearer $ANTIGRAVITY_API_KEY" \
            -H "Content-Type: application/json" \
            -d "{
              \"task\": \"以下のファイルのテストカバレッジを80%以上に引き上げてください: $FILES\",
              \"branch\": \"${{ github.head_ref }}\",
              \"constraints\": [
                \"既存テストは変更しない\",
                \"vitestを使用\",
                \"TypeScriptエラーをゼロにする\"
              ]
            }"

ドキュメント自動更新の仕組み

APIルートが変更されたとき、Background Agentが自動でドキュメントを更新するパターンです:

# .github/workflows/auto-docs-update.yml
name: Auto Documentation Update
 
on:
  push:
    branches: [main]
    paths:
      - 'src/app/api/**'
 
jobs:
  update-docs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 2
          
      - name: Detect API changes
        id: api-changes
        run: |
          # 変更されたAPIファイルを取得
          CHANGED=$(git diff HEAD~1 HEAD --name-only -- 'src/app/api/**' | head -10)
          echo "changed_files=$CHANGED" >> $GITHUB_OUTPUT
          
      - name: Update API documentation
        if: steps.api-changes.outputs.changed_files \!= ''
        env:
          ANTIGRAVITY_API_KEY: ${{ secrets.ANTIGRAVITY_API_KEY }}
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          CHANGED_FILES="${{ steps.api-changes.outputs.changed_files }}"
          
          # Background Agentに変更されたAPIのドキュメント更新を依頼
          echo "変更されたAPIファイル: $CHANGED_FILES"
          echo "Background AgentによるAPI仕様書更新を開始..."
          
          # 実装: docs/api/ 配下のMarkdownを自動更新
          # エラーハンドリング: 更新失敗時はSlack通知

コンテキスト・エンジニアリングの詳細については、Antigravity コンテキスト・エンジニアリング上級マスターガイドも合わせてご覧ください。

コスト管理と課金最適化

Background Agentは便利ですが、使い方を誤るとクレジットが想定外のスピードで消費されます。実際に私が試行錯誤した中で見えてきたコスト管理の実践ノウハウを共有します。

クレジット消費パターンの理解

Background Agentのクレジット消費は、主に以下の要素で決まります:

  • コンテキストウィンドウのサイズ:AGENTS.md や Knowledge Items が多いほど、各ステップでのコンテキストが大きくなり消費量が増える
  • タスクの試行回数:エラーリカバリのためにエージェントが再試行するたびにクレジットを消費する
  • 出力の量:大量のコードを生成するタスクは自然と消費量が増える

私の経験では、同じタスクでも「タスク仕様書が明確」な場合と「曖昧」な場合でクレジット消費に2〜3倍の差が出ることがあります。再試行の回数が減るからです。

コスト最適化の実践テクニック

テクニック1: 小さなタスクから始める

Background Agentに初めて委任するタスクは、まず小さな単位で試してください。精度と消費量の感覚をつかんでから、より大きなタスクに移行するのが安全です。

テクニック2: AGENTS.md を充実させてリトライを減らす

AGENTS.md が充実しているプロジェクトでは、エージェントの試行回数が減り、結果としてコスト効率が上がります。プロジェクト固有の制約や「よくあるエラーと解決策」を書き込んでおくことが、最も費用対効果の高い投資です。

テクニック3: 時間帯を選ぶ

Background Agentのレート制限は時間帯によって変わる場合があります。重要なタスクは日本時間の昼間よりも、深夜から早朝にかけて走らせると安定することが多いです。

テクニック4: 小タスクは通常エージェントに切り替える

10分以内に完了するような小さなタスクは、Background Agentより通常のインラインエージェントの方がクレジット効率が良いことがあります。Background Agentはあくまでも「時間のかかる・長い・放置できる」タスクに特化して使うのが賢明です。

関連する実践情報として、Antigravity Background Agent — コーディングしながらAIに別タスクを任せる実践ガイドも入門として参考になります。

本番開発でのユースケース実例

理論だけでなく、私が実際にBackground Agentを本番開発で使っているユースケースをそのまま共有します。

ユースケース1: 夜間の技術的負債解消

就寝前にBackground Agentを起動し、翌朝起きると技術的負債が解消されているというワークフローです:

## タスク:src/utils/ の型安全性改善
 
### 目標
`src/utils/` 配下の全ファイルで以下を達成してください:
- `any` 型の使用をゼロにする
- 明示的な型注釈を全関数に追加
- JSDocコメントを全エクスポート関数に追加
 
### 完了条件
1. `npx tsc --noEmit` でエラーゼロ
2. `any` 型が `grep -r "any" src/utils/` でゼロ件
3. 既存テストが全てパス
4. 各関数に@param/@returns のJSDocあり
 
### 対象外
- src/utils/legacy/ 配下(別途対応予定)
- テスト用のモックファイル

ユースケース2: 新機能のサンドボックス実装

設計段階の新機能を「とりあえずBackground Agentに実装させてみる」という使い方です。完璧なコードを期待するのではなく、実装の叩き台を高速に得ることが目的です:

## タスク:通知設定ページの初期実装
 
### 目標
/settings/notifications ページの基本実装を作成してください。
デザインはMockup.pngを参考に(添付)。
 
### 実装範囲
- NotificationSettings コンポーネント
- 設定の保存/読み込み(Zustandストア)
- 4種類の通知タイプのトグルUI
 
### あえて実装しなくて良いもの
- 実際の通知送信ロジック(バックエンド未実装)
- アニメーション
- モバイル対応(後工程で対応)
 
### 完了条件
1. ページが表示される(エラーなし)
2. TypeScriptエラーゼロ
3. 各トグルのON/OFFがストアに反映される

この叩き台をレビューして改善点を指示する、という流れで進めると、ゼロから実装するよりも大幅に速く完成品に近づけます。

全体を振り返ってに代えて:Background Agentとの協働の本質

Background Agentを使いこなすのは、優秀なエンジニアに仕事を依頼するのと似ています。「何を、どこまで、なぜそうするのか」を明確に伝えれば、期待以上の結果を返してくれます。曖昧な依頼には曖昧な結果が返ってくる、というのも同じです。

まず今日試してほしいのは、自分の開発の中で「完了条件を明確に言語化できるタスク」を1つ見つけて、この記事のテンプレートに当てはめてみることです。最初から大きなタスクを委任しようとしなくて大丈夫です。小さな成功体験を積み上げながら、徐々に委任の範囲を広げていくのが、Background Agentとの協働をうまく機能させる一番の近道です。

シェア

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

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

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

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

関連記事

Agents & Manager2026-06-21
Background Agent に夜間作業を任せて、朝に後悔しないために — 無人実行のガードレール設計
Antigravity の Background Agent に夜間リファクタを任せると、朝には便利さと同じだけの不安が届きます。被害範囲・完了条件・静かな劣化の検出という3点から、無人実行を安心して回すためのガードレール設計を運用視点でまとめました。
Agents & Manager2026-06-19
複数エージェントをどう束ねるか: 並列化する仕事と直列に残す仕事の線引き
Antigravity 2.0 で複数エージェントの真の並列実行が可能になりました。ただ全部を並列にすれば速くなるわけではありません。どの作業を並列に分け、どこを直列のまま残すか。依存関係と競合の観点から、破綻しないオーケストレーション設計を考えます。
Agents & Manager2026-05-28
Antigravity Background Agent のフォレンジック設計 — 6 ヶ月後でも判断を再現できる Cloudflare R2 監査ログ運用
Antigravity Background Agent の本番運用が長期化したときに必要になる、6 ヶ月後でも判断理由を再現できる監査ログの設計を、Cloudflare R2 への書き込み層・PII マスキング・Polars クエリまで実装パターンとしてまとめました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →