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 を検討する、という小さな儀式を挟むようにしています。

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 は方針を渡せば従ってくれるので、人間側が判断をルール化してリポジトリに置くだけで、道具の挙動はかなり手元に寄ってきます。

失敗例から学んだこと

正直に書くと、運用 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 の文脈を温めたまま使い切る、という感覚に近いです。

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

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

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

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

これから取り組むこと

1 ヶ月の運用で、Inline と Agent の境界はある程度自分のなかで言語化できました。次に取り組みたいのは、この使い分けをチーム外のメンバー（ときどき手伝ってもらう外部の方）にも共有できる形にすることです。属人的な判断のままだと、私が止まったときにメンテナンスが進まなくなるので、AGENTS.md の方針節をもう少し読みやすく整え、簡単な判断フローを添えておきたいと考えています。

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

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