ANTIGRAVITY LABEN
記事一覧/Agents & Manager
Agents & Manager/2026-05-30上級

エージェントが壊す前提で組む — ブラスト半径を小さく保つ運用設計

Antigravity のエージェントに本番作業を任せ始めると、性能より先に「事故ったときの被害範囲」が問題になります。ブラスト半径を縮小する4層の封じ込め設計を、TypeScript の実装と実測値つきで整理しました。

Antigravity338AIエージェント36本番運用17信頼性設計8ブラスト半径

プレミアム記事

5,000万DLのアプリを個人で運用していると、エージェントに任せたい雑務はいくらでも出てきます。依存パッケージの一括更新、多言語リソースの整合、Crashlytics で見つかった同型クラッシュのまとめ修正。2014年からずっと手で回してきた作業ほど、自動化したい欲が強くなります。

ところが、Antigravity のエージェントに本番リポジトリの一括書き換えを初めて任せた日、私は38ファイルが一度に壊れた差分を前に固まりました。エージェントの判断は1箇所だけ間違っていたのですが、その1箇所を「全ファイルに横展開」する設計だったため、被害が一気に広がったのです。テストは通っていました。壊れたのは、テストが見ていない初期化順序でした。

このとき痛感したのは、エージェント運用で先に効いてくるのは賢さではなく ブラスト半径(blast radius/1回の失敗が及ぶ被害範囲) だということです。賢いエージェントでも必ず間違えます。問題は「間違えたとき、どこまで巻き込むか」です。ここでは、被害範囲を構造的に小さく保つ封じ込め設計を、実装とともに整理します。

ブラスト半径を3軸で測る

「事故が怖い」は感想であって設計にはなりません。封じ込めの議論を始める前に、被害範囲を測る物差しを決めます。私は次の3軸を使っています。

  • 影響範囲(spread): 1回の実行が変更するファイル数・レコード数・外部呼び出し数
  • コスト(cost): その実行で消費するトークン課金額と、失敗時に無駄になる金額
  • 復旧時間(MTTR): 壊れてから元に戻すまでの実時間

38ファイル事故を3軸で振り返ると、影響範囲は38(過大)、コストは1回 ¥120 程度(軽微)、復旧時間は git revert とビルド検証で27分(重い)でした。つまりこの作業の本当のリスクは「お金」ではなく「広がりすぎる影響範囲」と「長い復旧時間」にあったわけです。軸を分けて測ると、どこを締めるべきかが見えてきます。

この3軸を実行前に見積もる小さなヘルパーを最初に置きます。

// risk-estimate.ts — エージェント実行前に被害範囲を見積もる
export interface RiskEstimate {
  spread: number;       // 変更対象の件数(ファイル/レコード/API呼び出し)
  costYen: number;      // 想定トークン課金(円)
  mttrMinutes: number;  // 失敗時の想定復旧時間(分)
}
 
export interface RiskPolicy {
  maxSpread: number;
  maxCostYen: number;
  maxMttrMinutes: number;
}
 
export function classifyRisk(est: RiskEstimate, policy: RiskPolicy) {
  const reasons: string[] = [];
  if (est.spread > policy.maxSpread) reasons.push(`spread ${est.spread} > ${policy.maxSpread}`);
  if (est.costYen > policy.maxCostYen) reasons.push(`cost ¥${est.costYen} > ¥${policy.maxCostYen}`);
  if (est.mttrMinutes > policy.maxMttrMinutes) reasons.push(`mttr ${est.mttrMinutes}m > ${policy.maxMttrMinutes}m`);
  // reasons が空なら自動実行可、そうでなければ人間の承認ゲートへ
  return { autoApprove: reasons.length === 0, reasons };
}

ポイントは、3軸のどれか1つでも閾値を超えたら自動実行を止めて承認ゲートに回す、という単純な論理にすることです。複雑なスコアリングにすると、なぜ止まったのかが後で説明できなくなります。私は「説明できない自動判断は本番に置かない」を原則にしています。

第1層: dry-run で先に差分を見る

封じ込めの一番外側は、実行する前に「何が変わるか」を確定させる dry-run です。Antigravity のエージェントはツール呼び出しの形で副作用を起こすので、ツール側を「計画モード」と「適用モード」に分けるのが効きます。

// dry-run-wrapper.ts — 副作用ツールを計画/適用の2モードに分離
type Plan = { op: "write" | "delete"; path: string; preview: string }[];
 
interface ToolContext {
  mode: "plan" | "apply";
  plan: Plan;
}
 
export async function writeFile(ctx: ToolContext, path: string, content: string) {
  if (ctx.mode === "plan") {
    // 実際には書かず、差分だけ計画に積む
    ctx.plan.push({ op: "write", path, preview: content.slice(0, 200) });
    return { staged: true };
  }
  await fs.writeFile(path, content, "utf-8");
  return { staged: false, written: true };
}
 
// エージェントの1ターンをまず plan で走らせ、spread を測ってから apply する
export async function runWithDryRun(agentTurn: (ctx: ToolContext) => Promise<void>, policy: RiskPolicy) {
  const ctx: ToolContext = { mode: "plan", plan: [] };
  await agentTurn(ctx);
  const spread = ctx.plan.length;
  if (spread > policy.maxSpread) {
    return { applied: false, plan: ctx.plan, blockedBy: `spread ${spread}` };
  }
  await agentTurn({ mode: "apply", plan: ctx.plan });
  return { applied: true, plan: ctx.plan };
}

公式のツール設計ガイドにはあまり強調されていませんが、本番で効くのは「エージェントに同じターンを2回走らせる」発想です。1回目は計画、そこで spread を数えてから2回目で適用する。38ファイル事故は、この plan フェーズがあれば「38件変更します」という表示で私が止められました。トークンは2倍弱かかりますが、1回 ¥120 の作業で復旧27分のリスクを消せるなら、安い保険です。

注意点として、plan と apply で実行結果が変わる非決定的なツール(時刻依存・乱数依存・外部状態依存)があると、この2回走行は破綻します。私は副作用ツールの入力を実行開始時にスナップショットして両フェーズに同じ値を渡すようにしています。ここを雑にすると「計画では3件だったのに適用で12件変わった」という最悪の裏切りが起きます。

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

この記事の続きを読む

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

この記事で得られること
エージェントの自律実行を「dry-run → スコープ限定 → サーキットブレーカー → デッドレター」の4層で囲い、1件の暴走が本番全体に波及しない封じ込め構造をTypeScriptでそのまま組める
5,000万DLのアプリ運用で実際に起きた『一括書き換えで38ファイルが壊れた』事故を題材に、被害範囲をファイル数・コスト・ロールバック時間の3軸で測る具体的な閾値設計が分かる
サーキットブレーカーの開放閾値・デッドレターの再投入条件・承認ゲートを通す境界線を、過剰防御で生産性を殺さない実数値で決められるようになる
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

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

または
メンバーシップなら全記事が読み放題 →
シェア

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

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

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

関連記事

Agents & Manager2026-06-30
Android CLI が3倍速・トークン7割減になったとき、増やすべきは並列数ではなく1件あたりの検証だった
Android CLI のエージェントが3倍速・トークン約7割減になった、というニュースを見て最初に考えたのは「では何本同時に走らせようか」でした。けれど速くなって本当に変わるのは生産量ではなく、詰まる場所です。レビューと検証ゲートに移ったボトルネックを Little's Law で見積もり、WIP キャップで並列数を抑え、浮いた予算を1件あたりの検証に回す設計を、動く Python 実装と実測値でまとめました。
Agents & Manager2026-06-03
やり直せる操作とやり直せない操作を分けて任せる — 可逆性で自律度を決めるエージェント設計
Antigravity のエージェントに本番作業を任せるとき、賢さより先に効いてくるのは「その操作をあとから取り消せるか」です。操作を可逆性で3階層に分け、自動実行・チェックポイント付き実行・人間ゲートへ振り分ける設計を、TypeScript の実装と6アプリ並行運用の実測値つきで整理しました。
Agents & Manager2026-06-01
途中で失敗したエージェントの副作用を巻き戻す — 補償トランザクション設計の実装メモ
Antigravity のエージェントに複数の外部システムをまたぐ作業を任せると、途中の一段が失敗したときに半分だけ世界が書き換わって残ります。やり直しでは直らないこの状態を、補償トランザクション(Saga)で安全に巻き戻す設計を、TypeScript の実装と実運用の数値つきで整理しました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →