Antigravity 2.0 は、コードを書くエディタから「複数エージェントを同時に監督する管制塔」へと位置づけを変えました。並列で動くサブエージェント、バックグラウンドのスケジュール実行。手数は確かに増えます。
増えた手数の代償は、私の場合は「誰が何をしたのか分からない」という形でやってきました。個人開発で 4 サイトを並列に自動運用していると、ある朝、見覚えのない変更がリポジトリに入っている。エージェントがやったのは間違いないのですが、どのタスクの、どの判断で入ったのかが追えない。これが一番こわい状態です。私自身、Dolice として運用するメディアでこの状態に陥り、原因の特定に半日を溶かしました。
エージェントを増やす前に、変更を後から追える設計を先に入れるべきでした。この記事は、その監査トレイルをどう作るかを、実運用の失敗から逆算して書きます。
追えなくなるのは、意図が記録されないから
エージェントの変更が追えなくなる原因は、差分そのものではありません。差分は git に残ります。失われるのは「なぜその変更をしたか」という意図です。
人間の開発者なら、コミットメッセージや PR の説明に意図を書きます。ところがエージェントは、放っておくと「Update files」のような中身のないメッセージを残しがちです。半年後にそのコミットを見ても、何のための変更だったのか分かりません。
だから監査トレイルの第一歩は、意図を機械的に残させることです。差分ではなく、意図を残す。ここが起点になります。
コミット末尾に、追跡用メタデータを刻む
私が採用しているのは、コミットメッセージの末尾に構造化メタデータを必ず付けさせる規約です。本文は人間向けの説明、末尾は機械が grep するためのタグにします。
Add: プレミアム記事 3 本を公開 (claudelab)
CLI 移行・OS 委譲・監査設計の 3 テーマ。日英セットで作成。
Agent-Task: claudelab-premium-thu
Agent-Run: 2026-06-13T20:14+09:00
Agent-Intent: premium-content-publish
Agent-Gates: article,templating,frontmatter,redirect=pass
Agent-Task でどのスケジュールタスク由来かが分かり、Agent-Run で実行時刻、Agent-Intent で意図、Agent-Gates で通過した品質ゲートが残ります。後から「あの変更はどのタスクだ」と思ったとき、これがあるだけで追跡が一瞬で終わります。
実際の抽出はこうです。
# 特定タスク由来のコミットだけを時系列で並べる git log --all --grep= "Agent-Task: claudelab-premium-thu" \ --pretty=format: "%h %ci %s"
# 品質ゲートをすり抜けたコミットがないか監査する git log --all --grep= "Agent-Gates:" --pretty=%b \ | grep "Agent-Gates:" | grep -v "=pass" || echo "全コミットがゲート通過済み" この 2 本の grep が、私の毎朝の点検になっています。前者で昨夜どのタスクが何を入れたかを把握し、後者でゲートをすり抜けた変更がないかを確認します。
人間が見るべき変更と、自動承認してよい変更を分ける
全変更を人間がレビューするのは、並列運用では現実的ではありません。かといって全自動は事故のもとです。私は変更を 3 段に分けて、ゲートの強さを変えています。
低リスク（自動承認）: 既存記事の誤字修正、内部リンクの張り替えなど、影響範囲が閉じた変更。品質ゲート通過を条件に自動マージする
中リスク（事後レビュー）: 新規記事の公開、設定値の調整。マージはするが、翌朝に人間が差分を一覧で確認する
高リスク（事前承認）: リダイレクト追加、記事の削除、価格や認証に触れる変更。人間の承認なしには本番へ出さない
この仕分けの肝は、リスクを「変更の種類」で機械的に判定できるようにしておくことです。「リダイレクト設定ファイルに触れたら高リスク」のように、ファイルパスでルール化すると、エージェント側でも人間側でも判断がぶれません。
# 変更ファイルから自動的にリスク階級を判定する changed = $( git diff --name-only HEAD~1 ) if echo " $changed " | grep -qE "next.config|pricing|gone-slugs|middleware" ; then echo "RISK=high: 人間の事前承認が必要です" exit 1 # 高リスクは自動マージを止める fi 私は記事削除を自動で走らせていた時期に、消すべきでない記事まで巻き込んで本番から落としたことがあります。それ以来、削除とリダイレクトは無条件で高リスクに固定しました。事故のコストが、レビューの手間を大きく上回るからです。
意図を 1 行で書かせる、プロンプト側の規約
メタデータを残させるには、エージェントへの指示そのものに規約を埋め込みます。私はタスクのプロンプト末尾に、次の一文を必ず入れています。
「コミットメッセージ末尾に Agent-Task / Agent-Intent / Agent-Gates の 3 行を付与すること。Agent-Intent は 30 字以内で、なぜこの変更が必要かを書くこと」
この「なぜ」を 30 字に圧縮させるのが効きます。意図を一言で言えない変更は、たいてい筋が悪い。エージェントが Agent-Intent を書こうとして詰まるなら、その変更自体を見直す合図になります。人間のコードレビューで「この PR、何のため」と聞かれて答えに窮するのと同じ構図です。
誤検知を減らし、運用コストに見合わせる
リスク階級を機械判定すると、最初は誤検知が出ます。私の環境では、導入直後の 1 週間で高リスク判定の約 30% が、実際には安全な変更でした。ファイルパスのルールが大雑把すぎたのが原因です。
ここで「厳しすぎるから緩めよう」と判断すると、本末転倒です。私が採用したのは、誤検知をログに残し、週末に「本当に高リスクだったか」を一件ずつ振り返る運用です。2 週間ほど回すと、ルールの精度が上がり、誤検知は 1 桁台に落ち着きました。
この運用には地味なコストがかかります。ですが、削除やリダイレクトの事故が一度起きれば、App Store のレビュー対応や検索順位の回復に何週間も持っていかれます。事故の回避コストと点検の手間を秤にかければ、点検を続けるほうが安いと私は考えています。完璧な自動判定を待つより、誤検知を許容しながら精度を上げるアプローチを推奨します。
トレイルは、増やす前に作る
監査トレイルの教訓を一言にすると、こうなります。エージェントを増やす前に、追える仕組みを先に入れる。順序を逆にすると、追えない変更が積み上がった後で、過去には遡れません。
私は管制塔という言葉に少し身構えています。複数のエージェントを同時に動かせることと、その全部の動きに責任を持てることは、別の能力だからです。前者はツールが与えてくれますが、後者は設計でしか手に入りません。今 1 体でもエージェントを自動で走らせているなら、まずコミット末尾の 3 行メタデータから始めてみてください。明日の自分が、昨夜のエージェントを追えるようになります。