AIエージェントに作業を委ねるとき、何を渡し、何を手元に残すかを考えたことがあるでしょうか。
2014年から個人でアプリを開発し続けて12年になります。累計ダウンロード数は5,000万を超え、壁紙や癒し系のアプリを複数のストアで運営してきました。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申請に影響するプライバシー関連の処理
- エラーメッセージのコピーライティングこのファイルを持っておくことで、エージェントは「ここは触らない」という境界線を学習します。また自分自身への備忘録としても機能します。
個人開発者として気づいた委任の経済学
最後に、少し抽象的な話をさせてください。
2014年から一人で開発を続けてきた中で、私が大切にしてきたのは「判断をためる」という感覚でした。一つひとつの実装判断に、ユーザーとの長い対話の蓄積があります。それはコードのコメントには書けない、体で覚えた文脈です。
AIエージェントは、その判断を私に代わって行うことはできません。でも、判断を下すまでの「準備」を大きく加速してくれます。
良い委任とは、自分の判断力を委ねることではなく、判断するための土台を速く作ってもらうことだと、今は考えています。
エージェントに仕事を渡す前に1分だけ立ち止まって「自分はここで何を決めようとしているのか」を確認する——その習慣が、AIと一緒に作るコードの品質を静かに上げていくと感じています。
委任の失敗を早期に察知するサイン
使い続ける中で、「これはうまくいかない委任だ」と気づくための警告サインがわかってきました。
指示がどんどん長くなる
プロンプトに補足を追加し続けているとき、それはたいてい「タスクの定義がまだ不完全」というサインです。そういうときは一度立ち止まり、5分間の設計メモを書き直すのが結果的に速い選択です。
「完成」を検証する方法がない
委任する前に「これが正しく終わったとわかる条件は何か」を答えられない場合、それは受け入れ条件が曖昧なままです。ビジネスに影響するコードについては、受け入れテストやチェックリストを先に作ってから委任しましょう。
「考えたくないから任せる」という動機
最も注意したい状況です。何を作るべきか決まっていないとき、委任は決断を先送りするだけです。コードは速く生まれますが、その後の修正で倍の時間がかかります。エージェントに任せるのは「何を作るか決まった後」にするのが原則です。
同じように個人で開発を続けている方の参考になれば幸いです。