ある夜、Antigravity エージェントが書いてくれたコードにバグを発見しました。画面上に出ているのは TypeError: Cannot read properties of undefined (reading 'map')。3年前なら10分もあれば原因の見当がつき、修正まで済んでいたはずのエラーです。
ところが、私はしばらく画面を見つめたまま動けませんでした。
「エージェントに聞けば直してくれる」という考えが先に来て、自分でコードを追う回路が、どこかでオフになっていたのです。
これが、Antigravityを本格的に使い始めて8ヶ月目に気づいた「思考の外注化」の実態でした。
「任せすぎ」に気づいたのは、デバッグできなくなったとき
2014年からアプリを個人で開発し続けてきました。累計5,000万ダウンロードを超えた今も、新機能の設計からデバッグまで、基本的にひとりで手を動かしています。
Antigravity を導入したのは昨年の夏。最初は「補助ツール」のつもりでした。それが気づけば、実装の大半をエージェントに投げるようになっていました。
問題は、それが便利だったことです。
スピードは明らかに上がりました。以前なら半日かかっていた機能実装が、プロンプトをうまく書けば1〜2時間で動くものが出てきます。ですが、半年後に同じようなバグに遭遇したとき、私は「あのときのコードはどう解決したのか」をまったく覚えていませんでした。
エージェントが解決してくれた問題は、自分の記憶に残りにくいのです。これは個人的な怠慢ではなく、認知的な仕組みの問題だと思います。人は「自分が格闘して解決した問題」でなければ、解決プロセスを長期記憶に格納しません。エージェントへの丸投げは、その「格闘」の機会を奪います。
思考の外注化が進む3つのサイン
同じ状況に陥っていないかを確かめるための問いがあります。
1. 「なぜこのコードがそう動くのか」を説明できない
エージェントが生成したコードを使い続けていると、動いている理由を理解しないまま本番に出すことが増えます。コードレビューの場で「ここ、どういう意図ですか」と聞かれたとき、答えに詰まるようになっていたら要注意です。
2. 自分でコードを書き始めることへの抵抗が生まれている
最初の1行を書くとき、「エージェントに任せればいいか」と考えてしまう頻度が増えていませんか。問題の設計段階から即座に「プロンプトの設計」へ思考がジャンプするようになると、問題そのものを直視する習慣が少しずつ失われていきます。
3. エラーメッセージを読む前にエージェントに貼り付けている
エラーが出た瞬間、内容を確認する前にAntigravityに貼り付ける。これが癖になると、デバッグ力は確実に落ちます。宮大工だった私の祖父が「材木を見る目は、切ることでしか育たない」と言っていました。コードも同じだと今は思います。道具が先に動いていては、目が育ちません。
エージェントを「増幅器」として設計する発想の転換
方向を変えるきっかけになったのは、Antigravity の使い方を「代替」から「増幅」へ切り替えたことでした。
具体的にこう変えました。
Before（外注型）: 「このAPIの認証エラーを修正して」→ エージェントが修正コードを出力 → レビューなしにマージ
After（増幅型）: 自分でエラーの原因を特定 → 仮説を立てる → 「この仮説で正しいか確認して、もし間違いなら何が見落とされているか教えて」→ 判断はあくまで自分が持つ
コードの書き方もこのように変わりました。
// Before: エージェントにすべて委ねる
// prompt: "認証エラーを修正して"
// After: 仮説を持ってからエージェントに確認させる
// 自分の仮説: "refreshToken の有効期限切れで 401 が発生している"
// prompt: "以下のエラーログと仮説を確認してください。
// 仮説が正しければ修正コードを、間違っていれば
// 別の可能性と確認方法を教えてください"
const handleAuthError = async (error: unknown) => {
if (error instanceof AuthError && error.code === 'TOKEN_EXPIRED') {
// 仮説を先に立てることで、コードの意味を自分が把握できている
await refreshAccessToken();
return retryRequest();
}
throw error;
};たった10分かかっても、「なぜこのコードなのか」を自分が語れる状態を作ること。それが長期的な開発力の維持につながります。エージェントへの指示の出し方を「答えをくれ」から「考えを確かめてくれ」に変えるだけで、使い方の質が大きく変わります。
「考えさせる前に自分が考える」プロンプト設計
毎日使っているプロンプトの書き方を共有します。
# 自分の現状認識
機能: ユーザーのオフライン状態でのキャッシュ同期
問題: アプリ再起動後にキャッシュが無効化されている
仮説: UserDefaults への保存時に Data 変換が失敗している可能性
# エージェントへの確認依頼
上記の仮説を検証するための最小限のデバッグコードを書いてください。
修正コードは不要です。まず仮説が正しいかどうかの確認を優先してください。
この形式に変えてから、コードの品質が上がりました。エージェントが「答え」ではなく「確認の道具」として機能するようになったからです。
解決策をもらうのではなく、自分の思考を試す場にAntigravityを使う。この違いが、数ヶ月後の開発力の差に現れます。
Antigravity のエージェントモードの基本的な使い方については、Antigravity エージェント入門 — 最初のワークフロー設計 も参照してみてください。
創造性という軸を手放さないために
アプリ開発だけでなく、アートの制作も長く続けてきた立場から言うと、創造的な仕事において「問いを立てる能力」は最も失ってはならないものだと感じています。
AIエージェントは、問いに対して非常に速く答えを出します。ですが、「どんな問いを立てるか」は、今のところ人間が設計しなければならない領域です。Antigravity を使って実装スピードを上げながら、自分が立てた問いに対して責任を持ち続けること。その感覚が、長期的な開発者としての強さにつながると思います。
17歳のときにオンラインで出会ったメンターが教えてくれた言葉があります。「芸術とは、特別な人間が作るものではなく、問いを持ち続けた人間が作るものだ」と。プログラミングも、同じかもしれないと今は思います。
AIとのペアプログラミングで陥りやすいパターンについては、AIとのペアプログラミングで陥りやすいパターン も合わせて読むと、自分の傾向がよく見えてくるかもしれません。
まず今日から試せること
思考の外注化を防ぐための最初の一歩は、小さくていいと思います。
「今日のデバッグは5分だけ自分で考えてからエージェントに渡す」という制約を設けてみてください。5分で解決できなければ迷わず渡してよいのですが、その5分の格闘が記憶に残ります。エラーの文脈、自分が最初に疑った箇所、外れた仮説。その蓄積が、半年後の判断力になります。
Antigravityはとても優れたツールです。だからこそ、使い手の姿勢が問われます。