AIコーディングツール「Antigravity」を1週間ガッツリ使ってみた振り返りです。
結論から言うと、「AIの思考は凄まじいが、手綱を握る人間側に別のスキルが求められる」という教訓を得た1週間でした。
1. Workspaceにファイルが多量にあると「激遅」になる
当初、ワークスペースにObsidianの4フォルダとUnityプロジェクト一式を放り込んでいましたが、これが失敗でした。 とにかくAIの思考時間が長すぎる。 Geminiが思考している間に、皿洗いと洗濯物を済ませられるレベル。
こんなものかな（無料だったので）と思ってましたが、ワークスペースのファイル数に依存するようです。 そこでファイル数を削り、Obsidian 1フォルダ ＋ Unityフォルダのみに絞ったところ、実用的な速度に改善。
「AIに全部見せる」のではなく、「いかにファイルを増やさないか」という情報の取捨選択がパフォーマンスに直結します。
2. Gemini 3.0の「知能」と「うっかり」のギャップ
Gemini 3.0は思考能力自体は非常に高く、複雑なエラーの解決策は即座に提示してくれます。 一方で、プログラミングの基礎的な部分で「しょーもないミス」を平然とやらかす二面性があります。
AIからの謝罪例：
「申し訳ない。コンパイルエラーの原因は Assets/Scripts/GameManager.cs という既存のクラスと名前が衝突していたためだ。 namespace ObjectX で囲っていても、Partial定義や同じ型名があるとUnityが混乱することがある。また、エラーメッセージを見るに、GameManager という型が既に存在していると認識されていたためだ。」
AIに「ニンゲン感覚のコーディング嗅覚」がほしいです。
以下、今回直面した課題の数々です。
マジックナンバー
9999f や 0.001f といった謎の数値が唐突にハードコーディングされます。後から調整しようにも、その数字の意図をAIに聞き直すコストが発生します。
レガシーコードの増殖
会話のコンテキストが切り替わる際、以前のコードとの整合性が取れなくなり、使われない古いメソッドや変数がゾンビのように残ります。「コードの全体像」を常に把握し続けることの難しさを感じます。
アクセス制御の崩壊
ChartManager.Instance.ActivePlanets.ToArray(); のような、どこからでも何でもできてしまう万能アクセスを平然と提案してきます。小規模なら良いですが、中〜大規模開発では設計の崩壊を招く火種です。
構文の破壊
基本的なシンタックスエラーも時折混じります。{} の閉じ忘れで関数が閉じられなかったり、リファクタリングの拍子に関数名が消滅したりすることも。また、C#的には string.IsNullOrEmpty を使うべき場面で String == null と書くような、言語仕様への甘さも見られました。
Unityの罠
Unity特有の「癖」にハマるケースです。代表的なのは GameObject == null の判定ミスや、スクリプトからShaderを初期化する際に誤って null を代入し、オブジェクトがピンク色（Missing Shader）で表示されてしまう現象などです。
3. 「Playモードへの移行時間」が最大のボトルネック
AIによる実装スピードが上がった結果、新たな問題にぶつかりました。
「AIは10秒で実装するが、UnityのコンパイルとPlayモード起動に1分かかる」という逆転現象です。
「Playモードで動かして確認する」という従来のデバッグ手法では、AIの速度を活かしきれません。このままだと、どんなにAIが速くても「15分に1実装」が限界だと感じています。もっと軽量な検証方法を模索する必要があります。
4. フォルダ構造の無秩序化
フォルダ管理をAIに任せた結果、Scripts/ 以下が非常に「綺麗で不便」な状態になりました。
- 生成されたフォルダ：
Audio,Core,Data,Debug,Editor,Entities,Environment,Event,Logic...
用途は明確ですが、「Planet.csを探すのにどの階層を掘ればいいのか分からない」。
結局、機能単位（例：Planet/ フォルダに関連クラスをまとめる）で管理したほうが、人間にもAIにも優しい構造になると痛感しました。
5. 謎の rg.exe 増殖事件
突如、バックグラウンドで rg.exe (ripgrep) が大量発生。
ウイルスかと思いきや検索を高速化する実行ファイルだそうですが、これがPCのメモリ（64GB）を食いつぶし、YouTubeすら処理落ちする事態に。
応急処置：
taskkillのbatファイルを作成して強制終了。謎： 同様の症例がネットに見当たらないため、環境固有の問題か、Antigravityのインデックス貼りが暴走している可能性があります。要調査。
まとめ：どうしてこうなったか？
今回の反省を一言で言えば、これに尽きます。
AIは「最短距離でゴール（今動くコード）」を望み、
人間は「最長期間、楽に維持できる道」を理想とする。
AIの理解力に全依存してしまった結果、細かい技術的負債が山積みになってしまいました。
今後の対策
エディタ側で常にルールを監視させる .cursorrules のような仕組みの導入が不可欠です。
ただし、それを使いこなすためには、結局「人間側がUnityのベストプラクティスに精通していること」が絶対条件になる。
AI時代こそ、基礎体力が重要だと思い知らされた1週間でした。
