壁紙アプリ4本の保守を進める途中、Antigravity の Inspector を本気で使い始めた1ヶ月の記録です。最初は「ログが見られる便利機能」くらいの認識でしたが、運用に組み込んでみると、エージェントとの関係そのものを変える道具だと気づきました。
私自身、個人開発で複数のアプリを並行保守している立場です。アプリの本数が増えるほど、エージェントの返答を「正しそうだから採用する」では追いつかなくなります。なぜその判断をしたのか、どのファイルを根拠にしたのかを見えるようにしておくことが、品質を落とさず回し続けるための前提条件になっていきました。Inspector はちょうどその穴を埋めてくれる道具でした。
Inspector を真面目に見るようになったきっかけ
最初の動機は、ある夜の出来事でした。
壁紙アプリの1本でテーマ切替時の画面真っ白問題を修正してもらったあと、別のアプリで同じ修正を流用しようとしたら、コードは似ているのに挙動が違いました。「同じ症状」と私が勝手に括っていたものが、Antigravity 側ではまったく別の文脈として理解されていたのです。
それまでの私は、エージェントの返答だけを見て判断していました。返答が正しそうなら採用、おかしそうなら再質問。けれど Inspector を開いてみると、エージェントは私が想像していたよりずっと多くの判断を、声に出さずに済ませていました。「このファイルは読まなくていい」「この依存関係は触らない」「この変数は副作用が無いはず」と、勝手に決めていたのです。
その夜、初めて Inspector を真面目に眺めて、ようやく「エージェントと一緒に仕事をする」とはどういうことか、輪郭が掴めた気がしました。
1ヶ月で見るようになった3つのパネル
運用が落ち着いてきて、Inspector の中で私が日常的に見る場所は3つに絞られました。
- 読み込まれたファイルリスト — エージェントが本当に参照したファイルがそのまま残ります。私は AGENTS.md に「この設計原則を必ず参照」と書いていたのに、Inspector を見ると参照していない日がありました。書いてあるから読むだろう、という前提が崩れた瞬間でした。
- ツール呼び出し履歴 — 何を、どの順番で、何回呼んだかが残ります。失敗した呼び出しがあった場合、エージェントは静かにリカバリしてくることが多く、本人の返答からはその苦労がほとんど見えません。Inspector を見ない限り、私はずっと「一発で正解を出してくれた」と勘違いし続けたはずです。
- 中間プランの差分 — エージェントは内部的に何度か計画を立て直しています。最終回答だけを見ると一直線に見える仕事も、Inspector で追うと「最初の方針を撤回した瞬間」が残っています。この撤回の理由を読み解くことが、AGENTS.md を育てる一番の材料になりました。
Inspector を読むときに私が固定した順番
最初の頃は、開いたパネルを行き当たりばったりで眺めていて、結局「なんとなく動いていた」以上の情報を引き出せませんでした。1ヶ月かけて、私は読む順番を次の4ステップに固定しました。順番を決めるだけで、同じログから拾える発見の量がはっきり増えます。
- 最終回答ではなく、まず「読み込まれたファイルリスト」から見る。 返答を先に読むと、その内容に引きずられて根拠を後付けで納得してしまいます。先に参照ファイルを見ておくと、「この判断は本当にこのファイル群だけで下せるのか」を冷静に問えます。
- 次に「ツール呼び出し履歴」で寄り道を探す。 失敗 → リカバリの痕跡がある箇所は、エージェントが迷った場所です。迷いの場所は、たいてい AGENTS.md の記述が足りていない場所と一致します。
- 「中間プランの差分」で撤回点を1つだけ特定する。 すべてを追うと時間が足りないので、私は「一番大きく方針が変わった撤回」を1セッションにつき1つだけ拾うようにしています。
- 最後に最終回答を読み、上の3つと矛盾がないか確かめる。 矛盾があれば、それは「返答は正しそうだが根拠が弱い」サインです。
この順番にしてから、「返答は良いのに、なぜか別アプリで再現しない」というタイプの事故を事前に拾えるようになりました。
壁紙アプリ4本の保守で起きた具体的な変化
iOS と Android の壁紙アプリ4本を並行で保守していると、共通化したい部分と、各アプリ固有の文脈で分けたい部分が常にせめぎ合います。Inspector を入れる前後で、ここの判断がはっきり変わりました。
入れる前は、私が「共通化できそう」と感じた箇所をエージェントに任せて、出てきたコードをそのまま流用していました。動くので満足していたのですが、3週目あたりで、4本のうち1本だけテーマ初期化の順序がわずかに異なることが判明し、共通化したコードが UI 上のちらつきを生んでいたのです。
Inspector を入れてからは、エージェントが「このアプリには影響しないはず」と判断した根拠を、私が事前に確認できるようになりました。根拠が「ファイル名の類似」だけで終わっている場合は、私が立ち止まって追加の文脈を渡すようにしています。
結果として、共通化のスピードは一見遅くなりました。けれど、リリース後に戻して直す回数が減ったので、月単位で見ると体感はむしろ早くなっています。AdMob のフォーマット差分のような、各アプリで微妙にチューニングを変えている領域では、特に効きが大きいと感じました。
AGENTS.md を Inspector のログから育てる流れ
Inspector のもう一つの効用は、AGENTS.md を「書く側の都合」ではなく「読まれている実態」から育てられることです。
私は今、週に一度、Inspector のログをざっと眺めて、エージェントが「参照しなかった」項目と「参照したけれど効かせきれなかった」項目を抜き出しています。前者は記述位置が遠すぎるか、文脈とのリンクが弱いことが多く、後者は記述が抽象的すぎることが多いです。
たとえば「テーマ切替時はメイン Activity を再生成する」とだけ書いていた項目は、参照はされても効かない週が続いていました。Inspector を見ると、エージェントは「再生成する方法」が AGENTS.md からは分からないため、自前で安全側に倒して別の修正案を出していました。そこで「ApplicationRestarter ヘルパーを呼ぶ」とまで書き直したら、翌週からはほぼ一発で意図通りの修正が返ってくるようになりました。
書き手としては少し気恥ずかしい作業ですが、設定ファイルというのは一度書いて終わりではなく、読まれ方を見ながら何度も合わせ直していくものだと考えています。AGENTS.md を育てることは、エージェントとの約束を更新し続ける行為に近いと感じています。
読み解きで見落としやすい3つの落とし穴
1ヶ月のあいだに、私自身が何度かはまった読み間違いを残しておきます。Inspector は情報量が多いぶん、見方を誤ると逆に判断を曇らせます。
- 「参照された＝効いた」ではない。 ファイルリストに AGENTS.md が並んでいても、その内容が実際の修正に反映されているとは限りません。参照の有無と、効いたかどうかは別の軸として見る必要があります。
- 静かなリカバリを「実力」と読み違える。 ツール呼び出しが何度か失敗してから通っている場合、最終回答だけ見ると完璧に見えます。けれどその迷いこそ、次に同じ作業を頼むときの不安定要因です。失敗痕は減点ではなく、改善の材料として読むのが正解でした。
- 撤回点を全部追おうとして消耗する。 中間プランの差分は宝の山ですが、全部読もうとすると時間がいくらあっても足りません。1セッション1撤回に絞ると、続けられて、しかも効果が落ちませんでした。
Inspector のログを保存して比較する小さな工夫
1ヶ月運用してみて手応えがあったのは、Inspector のセッションログを軽く保存しておく習慣です。仰々しい仕組みは入れていません。気になったセッションだけ、テキストで以下のような短いメモを残しています。
- 日付: 2026-05-12
- 対象: 壁紙アプリ B / テーマ切替の白画面修正
- 参照されなかった AGENTS.md 項目: 「Activity 再生成の手順」
- ツール呼び出しの寄り道: lint を2回連続失敗 → 3回目で通過
- 学び: 再生成手順を具体メソッド名まで書き直す
このメモが3週間分溜まったところで、AGENTS.md の改訂が一気に進みました。Inspector の中身を眺めるだけでも価値はありますが、「気になった瞬間を後で読み返せる形に残す」ことのほうが、実際の保守には効いている気がしています。
1ヶ月運用して、変えなかった習慣と変えた習慣
変えなかったのは、「最終判断は人が下す」という姿勢です。Inspector で内部が見えるようになっても、エージェントが正しそうな判断をしているからといって、私の役割が減るわけではありません。むしろ判断材料が増えた分、責任の所在がはっきりしたと感じています。
変えたのは、「短いセッションを連ねる癖」です。以前は1セッションで多くを片付けようとしていましたが、Inspector で追跡したい単位を考えると、機能ごとにセッションを分ける方が後で読みやすくなりました。AdMob 関連と通知関連を同じセッションで扱わない、という単純な区切り方ですが、ログを後追いする側の負担はかなり違います。
これから取り組むこと
次の1ヶ月で取り組みたいのは、Inspector のログを Antigravity の Background Agent と連動させて、週次の振り返り資料を半自動で作る運用です。手で抜き出している作業を、もう少し再現性のある形に落とし込みたいと考えています。
ただし、過剰にツール化はしないつもりです。ログの整形は自動化しても、どの撤回を重く見るか、どの根拠を弱いと判断するかは、最後まで自分の手元に残しておきたいと考えています。エージェントの内部が見えるようになったいまこそ、見えたものをどう読むかという人間側の作法が、保守の質を分けるように感じています。
同じく個人で複数アプリを保守されている方の参考になれば幸いです。お読みいただきありがとうございました。