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

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

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

Antigravity386AIエージェント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-04-27
AgentKit 2.0 で作ったAIエージェントを売る5つの収益化パス — 個人開発者が選ぶべき販売チャネルの判断軸
Antigravity で作ったAIエージェントを個人開発者がどう売るか。マーケットプレイス、自社サイト、SaaS 組み込み、受託からの商品化、サブスクの5チャネルを、手取り・顧客との距離・立ち上がりの速さで比べ、Stripe の課金コードと利用上限の設計まで書き残します。
◈ Agents & Manager2026-04-14
Antigravity × AgentKit 2.0 × Stripe でつくるAIエージェント SaaS — 個人開発者が本番運用まで到達する実装ガイド
AgentKit 2.0 と Stripe を組み合わせ、サブスクリプション収益を得られる AI エージェント SaaS を Antigravity で構築する手順をまとめました。アーキテクチャ設計から課金・Webhook の冪等性、同時実行スロットが漏れる Redis 実装の穴まで、個人開発で実際につまずいた箇所を中心に整理しています。
◈ Agents & Manager2026-10-16
エージェントに .zip を渡す前に、.git を除いて 29 MB を 15 MB にし、秘密情報の警告 28 件を見分けました
Antigravity アプリ v2.23.0 で .zip を添付できるようになりました。自分のリポジトリを実際に固めて .git の重さと秘密情報検査の誤検知を数え、除外・検査・マニフェストを一度に行う Python スクリプトの全文を残します。