エラー検知から修正案の作成までを自動化しても、「修復できた」と判断するには再現テスト、権限の制限、独立レビューが必要です。n8nはイベントと状態を管理し、コーディングエージェントは隔離環境で差分と検証結果を返す、という責任分界を考えます。
本稿は設計案です。Antigravityとn8nの実接続、無人修復、PR作成、本番復旧を検証した運用実績としては扱いません。 旧稿の「寝ている間に勝手に直る」「コードを一行も書かず完成した」という記述は、検証証拠を確認できないため撤回します。
製品の機能と、連携の実装を分ける
Cursorにもブラウザー機能があります。公式の2.0変更履歴では、1.7のベータからGAへ移行したことが説明されています。「Cursorでは画面を操作できず、Antigravityだけができる」という比較は適切ではありません。Cursor 2.0変更履歴
AntigravityのCLI・IDE・SDKという実行面が存在することと、n8nから安全にジョブを投入できることは別です。採用する版で、認証、非対話実行、終了コード、出力形式、タイムアウト、キャンセル、権限設定を確認します。本稿は「Antigravity Agent API」という未確認のHTTPエンドポイントを提示しません。公式ドキュメント
GeminiのComputer Useも、モデルが提案した操作をアプリケーション側が実行し、結果をモデルへ返す構成です。モデルの応答だけでサーバー起動・クリックが実行されるわけではありません。Antigravityのブラウザー機能と、Gemini APIを使って自分で作る実行ループも区別します。Computer Use公式資料
n8nに任せる範囲と、エージェントに任せる範囲
| 役割 | 責務 | 次の段階へ渡すもの |
|---|---|---|
| エラー検知 | 許可した監視元からイベントを受ける | 対象、時刻、サニタイズ済みの症状 |
| n8nと状態ストア | 重複排除、試行予算、実行状態、期限を管理 | ジョブIDと固定した対象SHA |
| 隔離した実行環境 | 許可したリポジトリだけを取得し、固定した検証コマンドを実行 | 差分、再現結果、テスト結果 |
| エージェント | 原因候補を調べ、最小限の修正案を作る | パッチと説明。公開権限は渡さない |
| 独立レビューと人間 | 差分、権限変更、失敗時の挙動を確認する | 対象SHAを指定した承認 |
| 公開担当 | 承認済み成果物を反映し、結果を照合する | PR・デプロイの確定状態 |
アラート本文は信頼できる命令ではありません。そこにあるシェル文字列、URL、ファイルパスをそのまま実行しません。対象は管理側の許可リストから解決し、リポジトリ外へのパス、秘密情報の読み出し、任意の送信先を拒否します。ログや画面には個人情報・トークンが含まれ得るため、外部モデルへ渡せる範囲も先に定めます。
Rulesは指示、権限の制限は実行側
現行公式資料では、プロジェクトのRulesは .agents/rules/*.md に置けます。旧 .agent/rules/*.md も記載されていますが、旧稿の .antigravity/rules は公式の配置として説明できません。Rules内のMarkdownには有効な trigger のfrontmatterが必要です。例えば、次は常時適用する指示の例です。Rules公式資料
---
trigger: always_on
description: "修復案の対象と検証・承認条件"
---
# 修復案の作成条件
- 対象リポジトリとSHAを確認し、最初に不具合を再現する。
- 原因、差分、実施した検証、未確認の範囲を返す。
- 権限拡大、秘密情報の取得、依存の追加は修正案として報告する。
- テスト失敗、中断、実行結果不明を成功として報告しない。
- PR作成、外部送信、マージ、本番反映は対象SHAの承認後に行う。
alwaysOn のような別表記やfrontmatterの欠落では、現行仕様上ルールが読み込まれない場合があります。単純な常時指示は AGENTS.md に置く選択肢もあります。
ただし、指示を読ませたことは強制的なアクセス制御の証明ではありません。実行環境の書込み範囲、ネットワーク、コマンド権限、秘密情報、公開用資格情報を別に制限します。エージェントの修正段階へ本番資格情報やDockerソケットを渡さない構成を優先します。Permissions公式資料
Dev Containerのエラーに特権を自動追加しない
「接続が切れた」「終了コード1006が出た」という症状だけでは原因を特定できません。発生したコンポーネント、コンテナの終了理由、ビルドログ、リソース不足、接続先・設定を調べます。
旧稿の privileged: true を万能対処として追加する案は撤回します。Dockerの特権コンテナは全capabilityとデバイスへのアクセスを与え、Linuxの保護設定も緩めます。Docker Desktopの場合も、コンテナを動かすVM内での権限境界に影響するため、単に「開発用だから安全」とは扱えません。必要性を説明できる場合だけ、限定したdeviceやcapability等を含めてレビューします。Docker公式資料
スクリーンショットだけで成功にしない
ヘッダーが画面に存在しても、hydrationエラー、操作不能、通信失敗が解消したとは限りません。修正前に失敗する再現手順を固定し、修正後に同じ手順を実行します。
- サーバー応答、ブラウザーのconsole・pageerror、必要な通信を確認する。
- 表示だけでなく、対象の入力・クリック・遷移の結果を検証する。
- リロード、クライアント遷移など不具合が出た条件を再確認する。
- 関連する回帰テストと独立レビューを通す。
画像生成は不具合修正の必須工程ではありません。追加生成を組み込む場合は、別途必要性と費用・公開条件を判断します。
通知の抑制と、修復ループの停止は別
1時間の通知ミュートでは、修復ジョブの再実行は止まりません。状態を永続化し、同じ障害の試行回数をワークフローの再実行でリセットしないようにします。
| 状態・条件 | 次の動作 |
|---|---|
| 同じジョブIDを受信 | 原子的な取得条件で重複実行を避ける |
| 実行中 | 所有者・lease・期限を記録し、別実行は開始しない |
| 試行上限または期限に到達 | 停止して診断情報を引き継ぐ |
| 修正案と検証結果が揃った | 承認待ちへ移す |
| 中断 | 新しい操作を停止し、完了済み操作と未処理を記録する |
| PR作成等がタイムアウト | 結果不明として照合し、確認前に再作成しない |
例えば「1ジョブ最大3試行」は設計上の例で、推奨値を実測したものではありません。対象SHAと症状から作るfingerprint、再オープンの条件、総時間・費用の上限を決めます。lease切れでも、既に外部操作が成功している可能性は消えないため、引継ぎ時には結果の照合が必要です。
導入前に確認すること
まず、公開情報と架空のエラーだけを使った隔離環境で、接続・再現・停止・重複排除・結果不明からの復旧を検証します。その後で、承認待ちまでを自動化する範囲を決めます。
本稿で確認したのは公式資料とRules例のYAML構文です。n8n連携、エージェント実行、状態ストアの排他制御、画面テスト、PR作成・デプロイは未実施です。「自律修復が完成した」ではなく、実装と検証が必要な設計として読んでください。
旧稿の掲載画像
以下は元の記事の画像を維持しています。現在の機能、連携成功、本番復旧の検証証拠を意味しません。
2026-10-12訂正：製品比較、Rulesの配置、未確認の連携API、特権付与、成功判定と再試行の説明を修正しました。未確認の無人運用実績を撤回し、設計案と検証範囲を区別しています。
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。