Xcode 27 の開発者ベータが公開され、エージェント型コーディングが Xcode 本体に取り込まれました。外部の優れたモデルやエージェントを開発フローへ直接持ち込める方向の更新です。歓迎すべき変化ですが、すでに Antigravity でエージェントを回している身からすると、最初に困るのは機能そのものではありません。「同じリポジトリに、コードを書けるエージェントが二つ並んだ」という状態の整理です。
片方は Xcode の中で、ビルドと実機デバッグに密着して動きます。もう片方は Antigravity の CLI や IDE で、複数ファイルを横断する作業や定常運用の自動化を引き受けます。境界を決めないまま両方を走らせると、同じファイルを別々のエージェントが書き換え、どちらの変更が正なのか分からなくなります。二つのエージェント型ツールをまたいで iOS を開発するとき、私がどう作業境界を設計しているかを、個人開発の現場目線で具体的にお伝えします。
なぜ「どちらに任せるか」が事故になるのか
エージェントが一つだけなら、source of truth は迷いません。書いたエージェントの最新状態が正です。ところが書き手が二つになると、正の定義が暗黙のうちに二重化します。
典型的な事故は三つあります。ひとつは二重編集です。Xcode 側のエージェントが ContentView.swift を整え、同時刻に Antigravity がリファクタで同じファイルへ触れ、保存の順序でどちらかの変更が消えます。ふたつめは前提のずれです。Xcode 側はビルドの通る状態を、Antigravity 側はテストの通る状態を、それぞれ「完了」と見なし、片方の基準だけ満たした中途半端なコミットが生まれます。みっつめは観測の分断です。どちらが何を変えたかが別々のログに散らばり、不具合の原因を後から追えなくなります。
これらはツールの優劣の問題ではありません。境界を設計していないことの問題です。先に決めるべきは「どちらが賢いか」ではなく、「何を一つの正とし、誰がそこに書き込んでよいか」です。
source of truth はリポジトリに一本化する
私が最初に固定するのは、正はリポジトリの作業ツリーだけ、という原則です。Xcode のエージェントも Antigravity も、編集対象は同じ Git 管理下のファイルに限定し、ツール内部の一時的な状態を正とはみなしません。当たり前に聞こえますが、エージェントは便利さのあまり、ツール固有のセッションや下書きにコンテキストを溜めがちです。そこを正にすると、別のツールから見えない情報が増えていきます。
そのうえで、両方のエージェントが起動時に必ず読む共通の規約を AGENTS.md としてリポジトリ直下に置きます。Antigravity はこの種のファイルをコンテキストとして拾いますし、Xcode 側のエージェントにも作業開始時に読ませることで、判断の前提を揃えられます。
# AGENTS.md — このリポジトリでエージェントが守る規約
## source of truth - 正はこの Git 作業ツリーのみ。ツール内の下書き状態を正にしない。 - 完了の定義: `scripts/verify.sh` が exit 0 を返すこと。ビルドだけ／テストだけの「完了」は認めない。
## 担当境界 - UI プレビュー連動・実機デバッグ密着の修正 → Xcode 側のエージェント - 複数ファイル横断のリファクタ・定常運用の自動化・CI 連携 → Antigravity - 同一ファイルへ両者が同時に触れる作業は禁止。先にブランチを分ける。
## コミット規約 - 1 コミット 1 関心事。件名に担当を明記する: [ xcode ] / [ agy ] - 検証を通していないコミットは push しない。 AGENTS.md は飾りではありません。後述する共通検証スクリプトの存在と、担当境界の明文化が、二つのエージェントを一つの規律の下に置くための芯になります。
作業を「仕様・実装・検証」の3層に分ける
担当境界を語る前に、作業そのものを3層に分けておくと、判断がぶれません。
仕様の層は、何を作るかを決める層です。ここはエージェントに丸投げせず、人が短い仕様メモとして書き出します。私は機能ごとに docs/spec/{feature}.md を置き、満たすべき条件と、やってはいけないことを数行で明記します。やってはいけないことを書く負の仕様は、エージェントの暴走を最も安く止める手段です。
実装の層は、仕様を満たすコードを書く層です。ここでツールを使い分けます。検証の層は、書かれたコードが仕様と既存の品質基準を満たすかを確かめる層で、ここはどちらのツールが書いても同じ一本のゲートに通します。
層を分ける利点は、ツールの議論を実装の層だけに閉じ込められることです。仕様と検証を共通化しておけば、実装をどちらのツールが担っても、入口と出口は一つに保たれます。
Xcode 側のエージェントに任せる領域
Xcode のエージェントが強いのは、ビルドと実機に密着した作業です。プレビューを見ながらレイアウトを詰める、ビルドエラーの文脈をそのまま読んで直す、実機のクラッシュログから当該箇所へ飛ぶ——こうした、Xcode が握っている情報に近いほど価値が出ます。
私はこうした性質の作業を Xcode 側に寄せています。SwiftUI のビュー単体の調整、Auto Layout やプレビューの崩れの修正、特定画面の実機デバッグに伴う局所的な直し、ビルド設定やシミュレータ依存の問題切り分けです。いずれも「一画面・一機能の中で完結し、ビルド可否がすぐ効いてくる」性質を持ちます。
逆に、Xcode 側に複数ファイル横断の大きなリファクタを任せるのは避けています。IDE のエージェントはその場のビルドが通ることを優先しがちで、リポジトリ全体の一貫性まで面倒を見る設計には必ずしもなっていないからです。
Antigravity に任せる領域
Antigravity が強いのは、リポジトリ全体を見渡す横断作業と、IDE の外で回る定常運用です。複数ファイルにまたがる命名統一、API クライアント層の差し替え、ローカライズ文言の一括整理、そして CLI を使ったスケジュール実行や CI への組み込みは、こちら側に寄せると安定します。
特に、夜間に走らせる定常処理は Antigravity の CLI が向いています。Go 製の CLI へ移行してから、起動の速さとトークン効率は実運用で体感できる水準になりました。公式には標準的なツール比で約3倍速、トークン消費は約70%削減と説明されており、放置気味に回す自動処理ほどこの差が効いてきます。個人開発で複数のアプリと運用を並行している私自身にとって、効率の数字はそのままコスト感に直結します。私は次のような非対話の検証を、push 前のフックとして回しています。
#!/usr/bin/env bash # scripts/agy-precheck.sh — push 前に Antigravity CLI で横断チェック set -euo pipefail
# 変更されたファイル一覧を渡し、規約違反を機械的に拾う CHANGED = $( git diff --cached --name-only --diff-filter=ACM | grep '\.swift$' || true ) [ -z " $CHANGED " ] && { echo "Swift 変更なし。スキップします。" ; exit 0 ; }
# 非対話・標準出力モードで実行（YOUR_AGY_PROFILE は各自の設定名に置換） agy run --non-interactive --profile YOUR_AGY_PROFILE \ --prompt "次のファイルが docs/spec の負の仕様に違反していないか確認し、違反のみ JSON 配列で出力。問題なければ [] を返す: ${ CHANGED }" \ > /tmp/agy_precheck.json
# 違反が空配列でなければ push を止める if [ "$( cat /tmp/agy_precheck.json | tr -d '[:space:]')" != "[]" ]; then echo "❌ 負の仕様への違反を検出しました:" cat /tmp/agy_precheck.json exit 1 fi echo "✅ 横断チェック通過" ここで大事なのは、Antigravity を「賢い相談相手」ではなく「機械的なゲートの一部」として組み込んでいる点です。出力を JSON に縛り、空配列以外なら止める。判断のゆらぎを運用から締め出すほど、二つのツールを併用したときの再現性が上がります。
境界で事故が起きるパターンと防ぎ方
最も多い落とし穴は、同じファイルへ両者が同時に触れることです。これを回避するには、ブランチで物理的に分けるのが一番確実でした。Xcode 側で触る作業と Antigravity で触る作業を、別ブランチに割り当て、マージは人がレビューしてから行います。担当を [xcode] / [agy] でコミット件名に明記しておくと、後から差分の出どころを追えます。二つのツールを併用するなら、この接頭辞の明記を強く推奨します。
次に多いのが、完了基準のずれです。これは前述の verify.sh を唯一の完了条件にすることで吸収します。Xcode 側で直して「動いた」状態も、Antigravity でリファクタして「テストが緑」の状態も、同じスクリプトを通らなければ未完了として扱います。
#!/usr/bin/env bash # scripts/verify.sh — どちらのエージェントが書いても通す唯一の完了ゲート set -euo pipefail
echo "▶ 1/3 ビルド" xcodebuild -scheme YourApp -destination 'platform=iOS Simulator,name=iPhone 16' \ build -quiet
echo "▶ 2/3 ユニットテスト" xcodebuild -scheme YourApp -destination 'platform=iOS Simulator,name=iPhone 16' \ test -quiet
echo "▶ 3/3 横断チェック（負の仕様）" git add -A scripts/agy-precheck.sh
echo "✅ verify 通過：このコミットは完了条件を満たします" 三つめは観測の分断です。どちらが何を変えたかを一箇所で読めるようにするため、私はコミット件名の接頭辞に加えて、エージェント実行のサマリを docs/agent-log/ に日付ごとの追記で残しています。ツールごとのセッションログは消えますが、リポジトリに残した要約は消えません。本番運用で不具合を追うとき、最後に頼れるのは正に置いた記録です。
小さく始めて、境界を後から動かす
最初から完璧な境界を引こうとすると、たいてい机上で破綻します。私は個人開発の延長として一機能だけを対象に、Xcode 側で UI を詰め、Antigravity で横断チェックを回す、という最小構成から始めました。二週間ほど回すうちに、「この種の修正は Xcode に寄せたほうが速い」「この自動化は Antigravity が安定する」という肌感覚が溜まり、それを AGENTS.md の担当境界へ反映していきます。
境界は固定物ではなく、運用しながら動かしていく前提のものだと考えています。Xcode 27 のエージェントもまだ動き続けるベータですし、Antigravity も小刻みに更新が続いています。道具が変われば最適な境界も変わります。変わることを前提に、source of truth を一つに保つ規律と、唯一の完了ゲートだけは動かさない——この二点を芯にしておけば、ツールが増えても運用は崩れにくくなります。
運用の立ち上げは、次の順で進めると無理がありません。
verify.sh を一本書き、手元の一機能をその出口に通す。その一機能だけ、UI は Xcode 側・横断チェックは Antigravity 側に割り当てて二週間回す。
溜まった肌感覚を AGENTS.md の担当境界へ反映し、対象機能を少しずつ広げる。
完了の定義を一つに決めるだけで、二つのエージェントは驚くほど素直に協調し始めます。
お読みいただきありがとうございました。同じように複数のエージェント型ツールを併用している方の設計の一助になれば幸いです。