Antigravity の Inline Edit と Agent モードを壁紙アプリ運用で1ヶ月使い分けた所感

Agent モードが向いていた場面

一方、Agent モードに任せて良かったと感じる場面にも共通項がありました。

最も大きかったのは、ファイル横断の依存関係を把握しないと変更できない作業です。具体例を挙げると、AdMob SDK のバージョン更新に伴う Info.plist の SKAdNetworkItems 追記と、それに連動する ATT 同意フローの調整、Privacy Manifest の更新、関連テストの修正までを一連で進めるような作業です。これらを Inline で 1 ファイルずつ詰めていくと、どこかで歩調がずれて整合性が崩れます。Agent モードに「目的」を渡し、必要な変更計画を出してもらってから個別に確認していく流れのほうが、結果として手戻りが少なくなりました。

もう一つは、自分が初めて触る領域の調査と試作です。たとえば、iOS の App Intents まわりはまだ手探りの部分が多く、関連ドキュメントを読みながら最小サンプルを動かすところまでを Agent に任せると、必要な API のあたりを早くつけられました。完全に任せるのではなく、生成された結果をたたき台として自分で読み返し、納得した部分だけを残す、という運用が現実的です。

1 ヶ月の実測値 — 何回どちらを使い、どこで時間を溶かしたか

感覚だけで語ると説得力に欠けるので、後半 2 週間は意識的に簡単なログを取りました。Antigravity の操作回数を厳密にカウントしたわけではなく、作業ログ（私は Obsidian の日次ノートに「何をどちらで進めたか」を 1 行ずつ残しています）から数えた概算ですが、自分の運用傾向がはっきり見えたので共有します。

後半 14 日間の集計はおおむね次の通りでした。

• Inline Edit で着手した作業: 約 180 件（全体の約 72%）
• Agent モードで着手した作業: 約 70 件（全体の約 28%）
• 「選択を誤った」と後から判断した作業: 11 件
• そのうち手戻りが 15 分以上に膨らんだもの: 4 件

件数で見ると Inline が大きく上回るのですが、これは壁紙アプリのメンテナンスが「小さな修正の積み重ね」で成り立っているからです。リソースの差し替え、表記の統一、定数の調整といった局所作業が日々の大半を占めます。一方で、時間ベースで見ると話が変わります。手戻りが 15 分以上に膨らんだ 4 件のうち 3 件は「Inline で粘りすぎて整合性を崩した」ケースで、1 件あたり 30〜45 分を溶かしていました。件数では Inline が主役でも、損失時間の山は Agent に渡すべき作業を Inline で抱え込んだときに発生していたわけです。

この非対称性に気づいてから、私は判断を「件数の多い側に最適化する」のではなく、「損失の大きい側を取りこぼさない」方向に切り替えました。具体的には、2 ファイル以上に触れそうだと感じた瞬間に、いったん手を止めて Agent を検討する、という小さな儀式を挟むようにしています。

誤選択 11 件を方向別に並べ直す

「選択を誤った」と後から判断した 11 件を、誤りの方向で分けてみると、非対称性がもっとはっきりしました。

件数では前者が多いのに、失われた時間で見ると後者が 4 倍以上高くつきます。両者の差は、ミスの重さそのものではなく、気づくまでの時間差でした。

前者は、その場で気づけます。Agent の提案が画面に出た瞬間に「これは広すぎる」と分かるので、却下して Inline に戻れば数分で復帰できます。後者は気づくのが遅いのです。1 ファイル目も 2 ファイル目も手応えはあるのに、3 ファイル目で初めて破綻が見えます。そこまで進んでいると、部分的な修正では戻せません。

だとすれば、打つべき手は「判断の精度を上げる」ことではなく、「Inline で抱えすぎている状態を早く検知する」ことになります。判断そのものは既に言語化できているので、あとは気づきさえすれば手は動きます。

2 ファイル目に触れた瞬間に気づく — 検知を注意力から外す

前節に書いた「いったん手を止めて Agent を検討する」という儀式は、集中しているときほど飛びます。実際、儀式を決めた後にも同じ失敗を 2 回しました。人間の注意力に依存した運用は、疲れている日にいちばん先に崩れます。

そこで、作業ツリーの変更ファイル数を数えるだけの小さなスクリプトを置きました。判断はしません。気づくきっかけだけを作ります。

#!/usr/bin/env bash
# inline-guard.sh — 未コミットの変更ファイル数が閾値を跨いだときだけ知らせる
set -euo pipefail
 
THRESHOLD="${INLINE_GUARD_THRESHOLD:-2}"
STATE_FILE=".git/inline-guard-last"
 
# 追跡済みファイルの変更のみを数える（未追跡の新規ファイルは対象外）
CHANGED=$(git status --porcelain --untracked-files=no | wc -l | tr -d ' ')
LAST=$(cat "$STATE_FILE" 2>/dev/null || echo 0)
echo "$CHANGED" > "$STATE_FILE"
 
# 閾値を「跨いだ瞬間」だけ鳴らす（超えている間ずっと鳴らすと無視されるようになる）
if [ "$CHANGED" -ge "$THRESHOLD" ] && [ "$LAST" -lt "$THRESHOLD" ]; then
  echo "▲ ${CHANGED} ファイルに変更が及んでいます。Agent に渡す作業ではありませんか？" >&2
  git status --porcelain --untracked-files=no | sed 's/^/    /' >&2
fi

肝は最後の条件節です。閾値を超えている間ずっと鳴らす作りにすると、3 日で目が滑るようになります。跨いだ 1 回だけ鳴らすので、警告が「いま状況が変わった」という意味を保ちます。

これを zsh の precmd（プロンプトを描く直前に走るフック）に噛ませて、コマンドを打つたびに黙って走らせています。

# ~/.zshrc
inline_guard_precmd() {
  git rev-parse --is-inside-work-tree >/dev/null 2>&1 || return
  [ -x ./scripts/inline-guard.sh ] && ./scripts/inline-guard.sh
}
autoload -Uz add-zsh-hook
add-zsh-hook precmd inline_guard_precmd

導入から 2 週間で 12 回発火し、そのうち 5 回は実際に手を止めて Agent へ切り替えました。残り 7 回は「意図して複数ファイルを触っている」ケースで、そのまま続行しています。

7 回の空振りを許容できるのは、鳴らすだけで何も止めないからです。ビルドを失敗させたり編集をブロックしたりする作りにしていたら、私は 3 日で外していたと思います。開発中の自分に何かを強制する仕組みは、たいてい長続きしません。気づかせるところまでで手を引くのが、この種の仕掛けの落としどころだと感じています。

同じ 2 週間で、Inline に抱え込んだことによる 15 分超の手戻りは 0 件でした。母数が小さいので効果を断言はできませんが、少なくとも「気づくのが遅い」側の失敗には手が届いています。

閾値を自分で決めず、リポジトリの履歴に聞く

inline-guard.sh を Lab のサイト（Next.js を Cloudflare Workers で動かしているほうです）にも置いてみた日、昼までに 9 回鳴りました。壁紙アプリでちょうどよかった閾値 2 が、ここではまるで機能しません。記事を 1 本足すだけでも MDX が 2 本（日本語と英語）、タグの定義、ときに一覧側の調整と、最低 3 ファイルには触れるからです。

鳴りすぎる警告は、鳴らない警告より質が悪いと思っています。1 週間で目が滑るようになり、本当に効かせたい日に読まれなくなります。

そこで、閾値を勘で決めるのをやめました。そのリポジトリの過去のコミットが 1 回あたり何ファイルに触れてきたかを数えれば、「このリポジトリにとっての普通」が出ます。普通より少し上に置けば、鳴るのは普通から外れたときだけになります。

#!/usr/bin/env bash
# inline-guard-threshold.sh — 直近のコミット履歴から、このリポジトリの閾値を決める
set -euo pipefail
 
SAMPLE="${1:-200}"   # 何コミットぶん遡るか
 
# コミットごとの変更ファイル数を昇順に並べる（マージコミットは除外）
COUNTS=$(git log -n "$SAMPLE" --no-merges --format='%H' | while read -r sha; do
  git show --pretty=format: --name-only "$sha" | sed '/^$/d' | wc -l | tr -d ' '
done | sort -n)
 
TOTAL=$(printf '%s\n' "$COUNTS" | sed '/^$/d' | wc -l | tr -d ' ')
if [ "$TOTAL" -lt 20 ]; then
  echo "履歴が ${TOTAL} 件では足りません。既定の 2 のままにします。" >&2
  exit 1
fi
 
# 75 パーセンタイルの 1 つ上を閾値にする（4 回に 3 回は黙っている水準）
IDX=$(( (TOTAL * 75 + 99) / 100 ))
P75=$(printf '%s\n' "$COUNTS" | sed -n "${IDX}p")
THRESHOLD=$(( P75 + 1 ))
 
git config inline-guard.threshold "$THRESHOLD"
echo "対象 ${TOTAL} コミット / 75 パーセンタイル ${P75} → 閾値 ${THRESHOLD} を .git/config に記録しました。"

置き場所を .git/config にしたことが、計算そのものより効きました。値はリポジトリごとに分かれ、クローンを消せば設定も消え、追跡されるファイルが 1 つも増えません。ルートに .inline-guard.toml のような設定ファイルを置くと、共同作業者にどの値を配るかという話が付いてきますし、.gitignore の世話も増えます。プロジェクトではなく自分の作業リズムに属する設定は、リポジトリの中ではなくリポジトリの設定へ。 この線引きを覚えてから、手元の小道具がずいぶん散らからなくなりました。

呼び出し側は 1 行だけ差し替えます。

# inline-guard.sh の冒頭（差し替え）
THRESHOLD="$(git config --get inline-guard.threshold || echo "${INLINE_GUARD_THRESHOLD:-2}")"

手元の 5 つのリポジトリで走らせた結果です。

勘で置いた 2 と一致したのは、壁紙アプリの iOS 側だけでした。残り 4 つはすべて 3 以上です。私の勘は、いちばん長く触っているリポジトリの感覚を、そのまま他所へ持ち出していたのだと分かりました。

導入後の 1 週間で、Lab のサイトでの発火は 9 回から 2 回に減り、そのうち 1 回は実際に Agent へ切り替えています。壁紙アプリ側の挙動は変わりません。効いたのは閾値が上がったことそのものより、鳴った回数のうち意味のあった割合が上がったことでした。読む気になる警告だけが残ったのです。

四半期に一度、inline-guard-threshold.sh を回し直すつもりでいます。リポジトリの性格は開発の段階で変わりますし、いま機能開発が続いている受託のサイトの値は、保守中心に戻れば下がるはずです。決め打ちにしない仕組みにしておけば、そのときに考え直す手間もかかりません。

1 ヶ月のメモから抽出した使い分けの判断軸

恥ずかしながら、最初の 2 週間は感覚で使い分けていて、判断がぶれていました。後半 2 週間は意識的にメモを取り、以下のような目安に落ち着きました。あくまで私の運用での目安なので、ご自身の規模感や扱う言語によって調整が必要だと思います。

• 変更スコープが 1 ファイル ＆ 10〜30 行未満で、目視レビューで十分なら Inline
• 変更が 2 ファイル以上にまたがり、かつそれらの整合性が崩れると挙動が壊れるなら Agent
• 提案を即時に承認 / 却下しながら進めたいなら Inline
• 「何を変えるべきか」を AI 側に考えてもらう必要があるなら Agent
• 自分が文脈をすべて把握している修正なら Inline
• 自分の知識に不確かさが残る領域なら Agent

この軸に落ち着いてからは、「どちらで進めるか」を迷う時間が体感で 7〜8 割（およそ 70〜80%）ほど減りました。判断そのものを 1 拍で済ませられるようになったのが、地味ですが大きな効果でした。

判断軸を AGENTS.md に書き出して固定する

頭の中の判断軸は、放っておくとまた少しずつぶれます。そこで私は、上の 6 つの目安を AGENTS.md に明文化して、リポジトリの中に置くようにしました。Antigravity はプロジェクト直下の AGENTS.md を Agent の文脈として読み込んでくれるため、ここに方針を書いておくと、Agent 自身が「この作業は Inline 向きでは？」と判断材料を持ってくれる場面が増えます。

実際に 4 本のアプリリポジトリへ共通で置いている節を抜粋します。

## このリポジトリでの Inline / Agent 使い分け方針
 
- 単一ファイル・10〜30 行・目視レビューで足りる変更は、Agent を起動せず Inline 編集で進めてください。
- 2 ファイル以上にまたがり、整合性が崩れると挙動が壊れる変更（依存更新、Build Settings、
  Privacy Manifest と ATT の連動など）は、まず変更計画を提示してから着手してください。
- 局所的なリファクタリング依頼に対して、周辺の構造（Theme・命名規約など）まで
  巻き込む再設計を勝手に拡張しないでください。必要だと判断した場合は、本作業とは
  分けて「別タスクの提案」として最後に箇条書きで挙げるにとどめてください。
- 破壊的変更の前にチェックポイントを切る前提で動いてください。

最後の 2 項目が、私にとっては効きました。「局所作業を勝手に広げない」という制約を明文化してから、失敗例 1 で書いたような「Color 定数の整理を頼んだら Theme 構造体の再設計まで返ってきた」類の暴発が、明らかに減りました。Agent は方針を渡せば従ってくれるので、人間側が判断をルール化してリポジトリに置くだけで、道具の挙動はかなり手元に寄ってきます。

6 つの目安を 1 枚のフローに畳む

箇条書きの 6 項目は、読み返すには良いのですが、作業中に参照するには長すぎました。手が動いているときに欲しいのは、上から順に見て最初に当たったところで決まる形です。そこで、AGENTS.md の方針節の直後に、次のフローを添えました。

## 判断フロー（上から順に、最初に当てはまった時点で決定）
 
1. 触るファイルが 2 つ以上になりそう            → Agent
2. 何を変えるべきかが自分の中で決まっていない    → Agent
3. 変更後の正しさを自分で判定できない領域である  → Agent
4. 上のいずれにも当たらない                      → Inline
 
補足: 3 は「知らない領域か」ではなく「判定できるか」で決める。
      判定できないなら Agent に計画を出させ、その計画の妥当性を人間が見る。

もとの 6 項目から Inline 側の条件を消して、Agent に上げる条件だけを並べたのが要点です。既定を Inline に置き、上げる理由がある場合だけ上げます。この一方向の形にしてから、迷いがはっきり減りました。6 項目を並べていたときは、Inline 側の条件と Agent 側の条件を突き合わせる作業が毎回発生していて、それ自体が判断コストになっていたのだと思います。

3 番目の文言は後から書き直しました。最初は「自分の知識に不確かさが残る領域」と書いていたのですが、この基準は日によって解釈が動きます。疲れている日ほど「知っているつもり」に寄ってしまうのです。「変更後の正しさを自分で判定できるか」に言い換えてからは、ぶれがほぼ止まりました。

判断軸を言葉にするときは、気分ではなく検証可能な問いに落とすほうが長持ちします。私はこれを、あとから何度も書き直すことでようやく学びました。

失敗例から学んだこと

正直に書くと、運用 1 ヶ月のうちには小さな失敗もいくつかありました。共有する価値があるものを 2 件だけ挙げます。

1 件目は、Inline で進めるべきだった作業を Agent に渡してしまったケースです。SwiftUI の Color 定数の整理という、本当に局所的な作業を、なんとなく Agent に依頼したところ、関連する Theme 構造体の再設計まで提案され、レビューに 30 分以上かかってしまいました。提案そのものは妥当でしたが、その日のスケジュールには合っていませんでした。AI の提案が常に「今やるべき作業」とは限らない、という当たり前のことを、改めて学びました。

2 件目は、Agent に任せるべきだった作業を Inline で粘ったケースです。Firebase Crashlytics の dSYM アップロード設定を 4 本のアプリで揃える作業を、Build Phase スクリプトの 1 行ずつを Inline で書き換えていたのですが、3 本目で構文ミスに気づき、最初から書き直しになりました。Agent に「全 4 本で同じ Build Phase を統一したい」と渡せば、一貫した変更を一度に提案してもらえたはずです。

どちらの失敗も、技術的な難しさが原因ではなく、道具の選択ミスが原因でした。1 ヶ月のうちにこういう小さな失敗を意識的に拾えたことが、結果としていちばんの収穫だったかもしれません。

失敗例2をどう直したか — dSYM Build Phase を Agent に一括統一させる

2 件目の失敗は、その後きちんと Agent に投げ直して解決しました。再現性のある手順として残しておきます。

まず、Agent に渡したのは「全 4 本のアプリで Crashlytics の dSYM アップロード用 Run Script Build Phase を同一の内容に統一し、入力ファイルリストの取りこぼしで警告が出ない形にしてほしい」という目的です。1 行ずつのパッチではなく、最終的に揃えたいスクリプトの形を提示しました。

Agent が 4 本に対して統一した Run Script は、おおむね次の内容です。

# Crashlytics dSYM upload (Run Script Build Phase)
# Input Files に $(SRCROOT)/$(BUILT_PRODUCTS_DIR)/$(INFOPLIST_PATH) と
# ${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME} を登録しておくこと
if [ "${CONFIGURATION}" = "Release" ]; then
  "${PODS_ROOT}/FirebaseCrashlytics/run" \
    -gsp "${PROJECT_DIR}/GoogleService-Info.plist" \
    -p ios
fi

ポイントは、スクリプト本体よりも Input Files の登録漏れが警告の温床になっていた点です。Inline で 1 行ずつ直していたときは、この「スクリプト外の設定（Build Phase の Input Files）」まで意識が回らず、3 本目で構文と設定の両方がずれていました。Agent に目的単位で渡すと、スクリプトだけでなく「Input Files にこれを登録してください」という付随手順まで計画に含めて返してくれたので、4 本の歩調が一度で揃いました。

ここで学んだのは、Agent に渡すべきなのは「diff」ではなく「揃えたい最終状態」だということです。差分を細かく指示すると Inline と変わらない手間がかかりますが、目的と完成形を渡すと、人間が見落としがちな周辺設定まで含めて面倒を見てくれます。

App Intents の試作を Agent に任せたときの最小サンプル

「自分が初めて触る領域」の代表例として、iOS の App Intents を Agent に試作させた話も具体で残しておきます。壁紙アプリに「今日の壁紙をショートカットから設定する」導線を検討していたとき、まず最小で動く形を Agent に作らせ、私はそれを読んで理解する、という進め方をしました。

Agent が最初に出してきた骨格は、おおむね次のようなものでした。

import AppIntents
 
struct SetTodayWallpaperIntent: AppIntent {
    static var title: LocalizedStringResource = "今日の壁紙を設定"
    static var description = IntentDescription("おすすめの壁紙を本日の1枚として保存します。")
 
    @Parameter(title: "カテゴリ")
    var category: WallpaperCategoryEntity
 
    func perform() async throws -> some IntentResult & ProvidesDialog {
        let picked = try await WallpaperStore.shared.pickDaily(in: category.id)
        try await WallpaperStore.shared.markAsToday(picked.id)
        return .result(dialog: "「\(picked.title)」を今日の壁紙にしました。")
    }
}

この骨格自体は完璧ではなく、WallpaperCategoryEntity の AppEntity 準拠や EntityQuery の実装は私が後から書き直しました。それでも、「App Intents は perform() を中心に組み立てる」「パラメータは @Parameter で宣言する」「結果に ProvidesDialog を足すと Siri / ショートカットで読み上げられる」といった全体像を、ドキュメントを端から読むより早く掴めたのは大きな利点でした。

私の運用では、Agent の出力は「正解」ではなく「土台」です。動く最小形を早く手元に置き、そこから自分の理解で固めていく。この順番だと、未知の領域でも立ち上がりが速く、かつ最終的なコードの理解度も落ちません。

クレジット消費の観点での使い分け

もう一つ、Pro / Ultra プランを使ううえで無視できないのが、Agent モードはクレジットを多く消費するという現実です。Agent は複数ファイルを読み、計画を立て、変更を提案するまでに相応のトークンを使います。Inline の小さな置換と比べると、1 操作あたりの消費は当然ながら大きくなります。

私は途中から、判断軸に「コスト」の観点も薄く重ねるようにしました。とはいえ「クレジットを惜しんで Inline で粘る」のは本末転倒で、失敗例 2 のような手戻りを生めば、人件費（自分の時間）のほうがはるかに高くつきます。私が落ち着いた運用は次の 2 点です。

第一に、Agent に投げる前に目的を 1 〜 2 文で固めること。曖昧なまま投げて何度も対話を往復させると、その都度クレジットを消費します。AGENTS.md に方針を書いておくと、初回の提案精度が上がり、往復回数が減るので、結果的にクレジットの節約にもつながりました。

第二に、探索的な調査は 1 回のセッションにまとめること。App Intents の試作のように「読む・試す・直す」を伴う作業は、思い立つたびに細切れで投げるより、まとまった時間に一気に進めたほうが、文脈の再読み込みが減って効率的です。クレジットの最適化というより、Agent の文脈を温めたまま使い切る、という感覚に近いです。

クレジット消費を 2 週間ぶん数えてみる

「Agent は多く消費する」というのは肌感覚では分かるのですが、どの程度なのかを一度は把握しておきたくて、後半 14 日間の消費を操作種別ごとに割り付けてみました。ダッシュボードで見える日次消費を、その日の作業ログと突き合わせた粗い推計です。

操作回数では Agent が 3 割弱ですが、消費では 8 割強を占めていました。さらに内訳を見ると、同じ Agent でも探索・試作が突出しています。目的が固まった変更依頼の 3 倍近くに達していました。

理由ははっきりしていて、探索は往復するからです。App Intents の試作では、最初の骨格が出てから私が読み、質問し、直してもらい、また読む、という往復が 1 セッションで 5 〜 8 回ありました。1 往復ごとにそれまでの文脈を読み直すので、回数が増えるほど加速度的に効いてきます。

この数字を見てから、探索の進め方を 1 つだけ変えました。分からない点をその場で 1 つずつ聞かず、ひととおり読み終えてからまとめて聞くようにしたのです。往復は 5 〜 8 回から 2 〜 3 回に減り、探索 1 件あたりの消費は体感で半分程度になりました。

理解の質は落ちていません。むしろ、まとめて聞くために自分でコードを読み込む時間ができたぶん、手元に残る理解は深くなったように感じます。節約のつもりで変えた運用が、結果として学習の質を上げていたというのは、少し意外な発見でした。

チェックポイントとの相性

Antigravity のチェックポイント機能は、特に Agent モード使用時に大きな安心材料になりました。複数ファイルにわたる変更を提案された際、いったん全部受け入れてから動作確認し、問題があればチェックポイントに戻る、という運用が現実的に回るからです。

私は「Agent に何かを依頼する前に必ずチェックポイントを切る」というルールを途中から徹底するようにしました。Inline であれば差分が小さく頭で追えますが、Agent はどうしても変更範囲が広くなりがちなので、ロールバック可能な状態を維持しておく安心感は侮れません。手戻りそのものは時間のロスですが、「いつでも戻れる」という前提が頭にあると、思い切った試行錯誤がしやすくなる、という二次的な効果もありました。

このルールは前述の AGENTS.md にも明記してあります。人間が忘れても、方針として残しておけば運用は崩れにくくなります。チェックポイントと Git のコミットは役割が違っていて、私はチェックポイントを「1 つの依頼の中の小さな避難所」、コミットを「意味のある区切り」として使い分けています。Agent の試行錯誤はチェックポイントで吸収し、納得できた状態だけをコミットに昇格させる、という流れが、いまの私には合っています。

これから取り組むこと

1 ヶ月の運用で、Inline と Agent の境界はある程度自分のなかで言語化できました。判断フローと inline-guard.sh まで含めて、いまの手癖はひととおり形になっています。

次に確かめたいのは、これがチーム外のメンバー（ときどき手伝ってもらう外部の方）にそのまま渡せるかどうかです。閾値のほうは履歴から算出する形になったので、渡した先のリポジトリが勝手に自分の値を出してくれます。残っているのは判断軸のほうで、こちらは数えて決められません。「変更後の正しさを自分で判定できるか」という基準は、判定する人の知っている範囲が変われば、同じ作業でも答えが変わります。私の 6 項目をそのまま渡すのではなく、その方自身の言葉で書き直してもらう形が要るのかもしれません。

もう一つ、Antigravity 自体のアップデートが続いているので、3 ヶ月後、6 ヶ月後にこの判断軸がどう変わっているかも記録に残していきたいです。道具は変わりますし、自分の使い方も少しずつ変わります。両方の変化を観察しながら、静かに整えていくのが、個人開発を長く続けてきた私自身にとって、いちばん性に合っているように感じます。

お読みいただきありがとうございました。同じように複数アプリを抱えながら Antigravity を導入してみたいと考えている方の、判断材料の一つになれば嬉しいです。