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 listBackground 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との協働をうまく機能させる一番の近道です。