個人開発で iOS / Android のアプリを複数本、日常的にメンテナンスしています。壁紙系・癒し系を中心としたその運用ラインに Antigravity を組み込み始めて、ちょうど 1 ヶ月が経ちました。「Inline Edit」と「Agent モード」をどう使い分けるのか — 壁紙アプリ 4 本の同時メンテナンスを通じて 1 ヶ月手探りした所感を、できる限り淡々と書き留めておきます。
最初に断っておくと、これは「どちらが優れているか」という比較記事ではありません。両方とも実務で必要な道具で、判断を誤ると静かに時間を溶かす類のものです。1 ヶ月のメモを読み返しながら、自分のなかでようやく整理がついた使い分けの軸を、同じように複数アプリを抱えている方の参考になればという気持ちで書いています。
なぜ Inline と Agent の使い分けに悩んだのか
きっかけは、Firebase の CocoaPods から SwiftPM への移行作業でした。4 本のアプリで同じような調整を繰り返す必要があり、最初は「全部 Agent モードに任せれば早そうだ」と高を括っていたのですが、結果としては小回りの利く修正まで Agent に依頼してしまい、不要な周辺ファイルへの編集提案が混ざって取り消しに時間を取られる、という事態が続きました。
逆に、依存解決や Build Settings の整合性チェックなど、複数ファイルを横断する作業を Inline で粘ってしまい、後から「これは最初から Agent に投げたほうが早かった」と気づくこともありました。道具の選択を一つ誤るだけで、それまでの手の動きがまるごと空回りしてしまう — その感覚を早めに言葉にしておきたいと思ったのが、今回のメモを残す動機です。
Inline Edit が向いていた場面
1 ヶ月のメモから、Inline Edit を選んで満足度が高かった作業を整理すると、共通点が見えてきました。
第一に、変更スコープが 1 ファイルかつ 10〜30 行程度の修正です。たとえば、Localizable.strings の表記揺れ修正、命名規約に揃える小さなリファクタリング、SwiftUI の View 内でのモディファイア順序の入れ替えなど、目視で全体を追える範囲では Inline のテンポが明らかに良いと感じました。
第二に、「確定的に置換したい」場面です。i18n リソースのキー命名統一や、Deprecated API の単純置換は、提案内容を 1 つずつ承認して進めたほうが、後から差分を読み返したときに自分の思考過程が辿りやすいです。Agent に丸投げすると差分が大きくなりすぎ、レビュー時に「なぜここをこう書き換えたのか」が分からなくなる場面が何度かありました。
第三に、プロンプトを短く保ちたい場面です。Inline は選択範囲が文脈の中心になるため、長い前置きを書かなくても意図が通じやすいです。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 件を、誤りの方向で分けてみると、非対称性がもっとはっきりしました。
| 誤りの方向 | 件数 | 1 件あたりの平均ロス | いちばん多かった主因 |
|---|
| Inline で足りる作業を Agent に渡した | 7 | 約 8 分 | 提案が周辺構造まで広がり、却下と読み直しに時間を取られた |
| Agent に渡すべき作業を Inline で抱えた | 4 | 約 34 分 | 3 ファイル目あたりで整合性が崩れ、最初から書き直しになった |
件数では前者が多いのに、失われた時間で見ると後者が 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 件でした。母数が小さいので効果を断言はできませんが、少なくとも「気づくのが遅い」側の失敗には手が届いています。
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 日間の消費を操作種別ごとに割り付けてみました。ダッシュボードで見える日次消費を、その日の作業ログと突き合わせた粗い推計です。
| 操作の種別 | 14 日間の回数 | 消費シェア（概算） | 1 回あたりの相対コスト |
|---|
| Inline Edit（10〜30 行） | 約 180 | 約 15% | 1（基準） |
| Agent — 目的が固まった変更依頼 | 約 45 | 約 35% | 約 9 |
| Agent — 探索・試作（対話往復あり） | 約 25 | 約 50% | 約 24 |
操作回数では 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 まで含めて、いまの手癖はひととおり形になっています。
次に確かめたいのは、これがチーム外のメンバー（ときどき手伝ってもらう外部の方）にそのまま渡せるかどうかです。判断フローは私の作業の粒度に合わせて書いたもので、扱うリポジトリの規模が変われば閾値も変わるはずです。inline-guard.sh の閾値を 2 に置いたのも、壁紙アプリのメンテナンスが「1 ファイルで完結する小さな修正」に偏っているからで、機能開発が主のリポジトリでは 2 では鳴りすぎるでしょう。渡す前に、閾値をリポジトリごとに持たせる形へ直しておきたいと考えています。
もう一つ、Antigravity 自体のアップデートが続いているので、3 ヶ月後、6 ヶ月後にこの判断軸がどう変わっているかも記録に残していきたいです。道具は変わりますし、自分の使い方も少しずつ変わります。両方の変化を観察しながら、静かに整えていくのが、個人開発を長く続けてきた私自身にとって、いちばん性に合っているように感じます。
お読みいただきありがとうございました。同じように複数アプリを抱えながら Antigravity を導入してみたいと考えている方の、判断材料の一つになれば嬉しいです。