ANTIGRAVITY LABEN
記事一覧/Agents & Manager
Agents & Manager/2026-06-03上級

やり直せる操作とやり直せない操作を分けて任せる — 可逆性で自律度を決めるエージェント設計

Antigravity のエージェントに本番作業を任せるとき、賢さより先に効いてくるのは「その操作をあとから取り消せるか」です。操作を可逆性で3階層に分け、自動実行・チェックポイント付き実行・人間ゲートへ振り分ける設計を、TypeScript の実装と6アプリ並行運用の実測値つきで整理しました。

Antigravity338AIエージェント36信頼性設計8本番運用17自律実行4

プレミアム記事

6本のアプリを個人で並行運用していると、エージェントに任せたい作業はいくらでも出てきます。依存パッケージの更新、多言語リソースの整合、Remote Config のフラグ調整、AdMob のメディエーション設定の見直し。2014年から手で回してきた作業ほど、自動化したい気持ちが強くなります。

ところが今年の春、ある木曜の深夜に肝が冷えました。Antigravity のエージェントに「広告まわりの設定を整理して」とだけ伝えたところ、エージェントは Remote Config のあるフラグを本番に反映してしまったのです。コード編集なら git で戻せます。けれど本番の Remote Config は、すでに 5,000万DL のうちその時間に起動した端末へ配信が始まっていました。取り消しても、もう新しい値を受け取った端末は元に戻りません。テストは通っていました。問題はテストの外、「取り消せるかどうか」にありました。

このとき気づいたのは、エージェント運用で先に効いてくるのは賢さではなく その操作をあとから取り消せるか だということです。賢いエージェントでも必ず間違えます。間違えたときに git で戻せる操作と、世界に痕跡が残って戻せない操作とでは、任せ方をまったく変えるべきでした。ここでは、操作を可逆性で分類し、自律度を段階的に切り替える設計を実装とともに整理します。

操作を「やり直せるか」で二分する

ソフトウェアの意思決定には、あとから引き返せる「両開きの扉(two-way door)」と、通り抜けたら戻れない「片開きの扉(one-way door)」がある、という考え方があります。これをエージェントの操作にそのまま当てはめると、運用の見通しが一気に良くなります。

両開きの扉にあたる操作は、ファイルの編集、ブランチへのコミット、下書きの生成、ローカルでのビルドなどです。失敗しても git で戻せますし、誰の目にも触れません。こうした操作にいちいち人間の承認を挟むのは、エージェントを雇った意味を消してしまいます。

片開きの扉にあたる操作は、App Store への申請、本番データベースへのマイグレーション、Remote Config の本番反映、課金イベントの発火、外部への通知送信などです。一度実行すると、ユーザーの端末・決済・外部システムに痕跡が残り、コマンド一つでは戻せません。ここを賢さに任せてはいけません。

私が最初に作った仕組みは「重要な操作は承認を挟む」というものでした。けれど「重要」という基準が曖昧で、結局あらゆる操作で確認ダイアログが出て、エージェントはほとんど自律的に動けませんでした。基準を「重要かどうか」ではなく 「取り消せるかどうか」 に置き換えたとき、初めて運用が回り始めました。

可逆性は3階層で捉えると運用しやすい

二分だけでは現場に合いませんでした。両開きと片開きの間に、もう一段が必要だったからです。私は最終的に、操作を次の3階層に分けています。

第1階層は 自動可逆 です。git で戻せる、外部に痕跡が残らない、巻き戻しコストがほぼゼロ。コード編集、ローカルテスト、下書き生成などが該当します。これはエージェントに無条件で任せます。

第2階層は 要チェックポイント です。技術的には戻せるけれど、戻すのに手間がかかる、あるいは戻し忘れると危ない操作です。ステージング環境への反映、スキーマ変更を伴わないデータ更新、ブランチ間のマージなどが該当します。実行する前に必ず巻き戻し点(スナップショット)を残し、戻せる状態を保証してから自動実行します。

第3階層は 不可逆 です。実行したら世界に痕跡が残り、人間にしか責任を持てない操作です。ストア申請、本番マイグレーション、課金・通知の発火がここに入ります。この階層だけは、エージェントが「実行直前」で止まり、人間が中身を確認してから通します。

この3階層の良いところは、判断の重さが操作の取り消しやすさに正確に比例することです。安全な操作は速く、危険な操作だけ慎重に。賢さの議論を持ち込まずに、機械的に振り分けられます。

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

この記事の続きを読む

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

この記事で得られること
エージェントの全操作を「自動可逆 / 要チェックポイント / 不可逆」の3階層に分類し、可逆なものは自動実行・不可逆なものだけ人間ゲートへ振り分けるルーターを TypeScript でそのまま組める
6本のアプリを並行運用する中で実際に起きた『取り消せない設定をエージェントが本番反映した』事故を題材に、操作の可逆性を判定する分類器と、巻き戻し点を残すチェックポイント層の実装が分かる
全エージェント操作の約70%が可逆・人間ゲートが必要なのは8%という実測の内訳から、承認待ちで運用を重くせず事故だけを止める閾値設計を、1日あたりの停止回数まで具体的な数値で決められるようになる
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-01
途中で失敗したエージェントの副作用を巻き戻す — 補償トランザクション設計の実装メモ
Antigravity のエージェントに複数の外部システムをまたぐ作業を任せると、途中の一段が失敗したときに半分だけ世界が書き換わって残ります。やり直しでは直らないこの状態を、補償トランザクション(Saga)で安全に巻き戻す設計を、TypeScript の実装と実運用の数値つきで整理しました。
Agents & Manager2026-05-31
自律エージェントの流量を制御する — バックプレッシャーと待ち行列で本番を壊さない設計
Antigravity のエージェントを複数同時に走らせると、賢さより先に「下流が捌けない」問題にぶつかります。同時実行数・到着レート・処理能力の3つで流量を捉え、待ち行列・セマフォ・トークンバケット・バックプレッシャーで本番を守る設計を、TypeScript の実装と実測値つきで整理しました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →