AIエージェントに作業を委ねるとき、何を渡し、何を手元に残すかを考えたことがあるでしょうか。
Antigravityのエージェント機能が実務に耐えるようになってから、個人開発での進め方は大きく変わりました。壁紙や癒し系のアプリを複数のストアで運営しておりますが、リリース前の細々した作業の多くは、今はエージェント側に移っています。
ただ、最初の半年で何度か後悔する経験もしました。エージェントに任せた結果、動くコードは生まれたけれど「これは私が作りたかったものではない」という状況に何度か陥ったのです。
その経験から少しずつ気づいたのは、問題は「AIの能力不足」ではなく「自分の意図の言語化不足」だったということです。
エージェントが本当に得意な3つの作業類型
実際に使い続けてわかってきたのは、エージェントは「決まったゴールへの最短経路を走る」のが得意だということです。
1. ボイラープレートの生成と変換
Antigravityのエージェントが最も力を発揮するのは、パターンが明確な繰り返し作業です。APIレスポンスの型定義、データ変換ロジックのユニットテスト生成、i18nキーの英訳——これらは渡した瞬間から自分が作業するより速く、かつ正確に仕上がります。
私の場合、アプリの多言語対応（15言語以上）は以前は数日かかっていましたが、今はエージェントに任せると数分で終わります。
2. 既存コードのリファクタリング（スコープが明確な場合）
「この関数を純粋関数に書き直して」「このクラスをcomposableに分割して」のように、目標が明確で副作用の範囲が予測可能なリファクタリングも、エージェントは非常に得意です。
重要なのは「スコープが明確な場合」という条件です。「このコードをきれいにして」という曖昧な指示では、エージェントは自分なりの「きれいさ」を実装します。それが自分の意図と一致するとは限りません。
3. 診断とデバッグの仮説出し
エラーログを渡して「原因を3つ仮説として挙げて」という使い方は非常に効果的です。私自身が3時間格闘していた問題を、エージェントは5分で複数の仮説とともに提示してくれることがあります。
ただし最終的な原因特定と修正判断は、自分で行うべきです。エージェントは確率的に正しい仮説を出しますが、あなたのシステムの文脈を完全には理解していません。
人間が持ち続けなければならない「意図」
問題は、エージェントが「なぜそう実装するか」の理由を持っていないことです。
昨年の秋、壁紙アプリの課金フローを大幅に変更するリファクタリングをAntigravityエージェントに委任しました。技術的には完璧な実装でした。コードはきれいで、テストも通り、パフォーマンスも向上しました。
しかし数週間後、サブスクリプション解約率が上昇していることに気づきました。原因を調べると、エージェントが「技術的に正しい」実装として選んだUIフローが、ユーザーの「また使いたい」という気持ちを阻害する微妙な体験を生んでいたのです。
この経験から学んだのは、以下の3つが人間にしか持てないものだということです。
ユーザーとの文脈: なぜこのアプリがこのユーザーに使われているか。長年のデータと直感が宿る場所。
ビジネスロジックの優先順位: 速度と品質のどちらを今優先すべきか。収益とユーザー体験のどこでバランスをとるか。
将来の意図: 3ヶ月後にこのコードがどう変化するかのビジョン。エージェントには未来は見えません。
委任前の「5分間設計」が品質を変える
後悔する経験を重ねた結果、私は「委任前の5分間設計」という習慣を持つようになりました。
エージェントに作業を渡す前に、以下の3つを1〜2文で書き留めます。
# タスク委任メモ
目的: [なぜこれをやるか — ユーザー価値や技術的必然性]
成功条件: [完成したとわかる具体的な状態]
制約: [変えてはいけないこと・考慮してほしい文脈]
例えば、課金フローのリファクタリングなら：
目的: iOS StoreKit 2 移行によるレシート検証コードの簡素化。
ユーザー体験（購入フロー画面数・ボタン配置）は変えない。
成功条件: 既存の全テストが通り、購入完了までのタップ数が変わらない。
制約: 購入確認ダイアログのコピーは別チームが管理しているので変更しない。
この5分が、後の数時間の修正作業を防ぎます。
また、この習慣には予期しない副作用がありました。「目的」を書こうとしたとき、自分でも曖昧にしていた意図が明確になることがあります。書けないなら、それはまだ自分の中で整理できていないサインです。そのときはエージェントに任せるより先に、自分で設計を固める時間を取るべきです。
「なぜそう実装するか」を記録する AGENTS.md の活用
Antigravityが対応している AGENTS.md は、チームのためだけでなく個人開発者にも非常に有効なツールです。
私は各プロジェクトのルートに AGENTS.md を置き、以下を記録しています。
# AGENTS.md — このプロジェクトのAI委任ガイドライン
## アーキテクチャの意図
- 収益系のロジックは src/features/billing/ に集約。他からは直接触らない。
- UIコンポーネントはユーザー調査の結果を反映しているため、
「技術的改善」だけを理由にした変更は行わない。
## 委任していい作業
- テスト生成（スナップショット・ユニットテスト）
- i18n翻訳の追加
- 型定義の生成
## 必ず人間が判断すること
- 課金・サブスクリプション関連のUI変更
- App Store申請に影響するプライバシー関連の処理
- エラーメッセージのコピーライティングこのファイルを持っておくことで、エージェントは「ここは触らない」という境界線を学習します。また自分自身への備忘録としても機能します。
個人開発者として気づいた委任の経済学
最後に、少し抽象的な話をさせてください。
一人で開発を続けてきた中で、私が大切にしてきたのは「判断をためる」という感覚でした。一つひとつの実装判断に、ユーザーとの長い対話の蓄積があります。それはコードのコメントには書けない、体で覚えた文脈です。
AIエージェントは、その判断を私に代わって行うことはできません。でも、判断を下すまでの「準備」を大きく加速してくれます。
良い委任とは、自分の判断力を委ねることではなく、判断するための土台を速く作ってもらうことだと、今は考えています。
エージェントに仕事を渡す前に1分だけ立ち止まって「自分はここで何を決めようとしているのか」を確認する——その習慣が、AIと一緒に作るコードの品質を静かに上げていくと感じています。
境界線を文章ではなく仕組みで守る
AGENTS.md に境界を書いたとしても、エージェントが常にそれを尊重するとは限りません。これは推測ではなく、ツール側の挙動として実際に起きていたことです。
2026年7月16日の Antigravity CLI 1.1.3 で、ヘッドレス実行（-p）に関する修正が2件入りました。ひとつは、確認が必要なツールを呼んだ際に応答待ちのまま固まる、あるいは黙って自動承認してしまう問題。もうひとつは、always-proceed モードでワークスペース外へのファイル書き込みが誤って自動承認されていた問題です。
修正後は、許可が下りていないツールはソフト拒否され、承認に必要な allow ルール名が stderr に出力されるようになりました。夜間に長時間のタスクを流している方にとっては、前提そのものが変わる修正です。
この修正を知って、私は自分の allow ルールを読み直しました。半年前に「とりあえず通しておこう」と広めに書いたまま放置していたルールが、いくつも残っていたためです。
文章で書いた境界は、読まれなければ効きません。そこで、エージェントの実行後に「触ってほしくない領域に手が入っていないか」を機械的に確認する小さなゲートを、各プロジェクトに置くようになりました。
#!/usr/bin/env bash
# scripts/delegation-gate.sh — エージェント実行後に走らせる境界チェック
set -euo pipefail
# AGENTS.md の「必ず人間が判断すること」に対応する保護パス
PROTECTED=(
"src/features/billing/"
"src/features/privacy/"
"src/i18n/messages/errors."
)
BASE="${1:-HEAD}"
CHANGED="$(git diff --name-only "$BASE")"
HIT=0
while IFS= read -r file; do
[ -z "$file" ] && continue
for p in "${PROTECTED[@]}"; do
case "$file" in
"$p"*) echo "⚠️ 保護領域に変更: $file"; HIT=1 ;;
esac
done
done <<< "$CHANGED"
if [ "$HIT" -eq 1 ]; then
echo "→ 自動マージはしません。差分を目で確認してください。"
exit 1
fi
echo "✅ 保護領域への変更はありません（対象 $(echo "$CHANGED" | grep -c .) ファイル）"なぜ grep -q ではなく case のグロブで判定しているかというと、部分一致による誤検知を避けるためです。grep "billing" では src/utils/billing-format-test.ts のような無関係なファイルまで拾ってしまいます。パスの先頭から一致させることで、保護したいディレクトリだけを正確に捉えられます。
exit 1 にしているのは、CI に組み込んだときにそこで止めるためです。ローカルで走らせる場合も、マージ前に必ず目が向くようになります。レビュアーが自分しかいない個人開発では、この「止まる」という一手間が唯一のレビュー工程になります。
導入してからの数週間で、このゲートが反応したのは2回でした。1回は本当に触ってほしくない変更で、止められて助かりました。もう1回は保護パスの書き方が広すぎただけの誤検知です。後者のような空振りも、境界の定義を見直すきっかけとしては悪くないと感じています。
文章の境界と、仕組みの境界。前者は自分とエージェントの両方への説明であり、後者は自分が疲れている夜のための保険です。役割が違うので、片方だけでは足りません。
委任の失敗を早期に察知するサイン
使い続ける中で、「これはうまくいかない委任だ」と気づくための警告サインがわかってきました。
指示がどんどん長くなる
プロンプトに補足を追加し続けているとき、それはたいてい「タスクの定義がまだ不完全」というサインです。そういうときは一度立ち止まり、5分間の設計メモを書き直すのが結果的に速い選択です。
「完成」を検証する方法がない
委任する前に「これが正しく終わったとわかる条件は何か」を答えられない場合、それは受け入れ条件が曖昧なままです。ビジネスに影響するコードについては、受け入れテストやチェックリストを先に作ってから委任しましょう。
「考えたくないから任せる」という動機
最も注意したい状況です。何を作るべきか決まっていないとき、委任は決断を先送りするだけです。コードは速く生まれますが、その後の修正で倍の時間がかかります。エージェントに任せるのは「何を作るか決まった後」にするのが原則です。
同じように個人で開発を続けている方の参考になれば幸いです。