Google One AI Proでantigravityを使い倒す

2026年4月15日AI,python

楽曲派.comというサイトを運営しているんですが、これDjangoなんですがWordPress用のピンチケレンタルサーバーで動かしてるんですね。なんかMySQLとうまく繋がらなくてSQLiteでやってるんですが、同時書き込みできないから一般ユーザー登録とかできないじゃん！となり早1年ぐらい。いい加減VPS契約して移行しようと思い、そのためにPythonのバージョン移行やDjangoのバージョン移行とかデバッグをantigravityでやってるんですが、AI ProのGemini 3.1 ProやClaudeの上限数ゴリゴリ削られてて涙止まらんけど、プロンプトやもろもろの工夫で今の制限でもまあ困らんなぐらいになってます。

貧民の僕はClaude Codeの上位モデルやAI Ultraなんて契約できないんです。知恵で戦うしかないんです。

その僕の涙ぐましい努力をここに書いていくよ。

これは2026/4の記事で、AIなんて1ヶ月後にどう進化して新しいツールができるかわからん。なのでこれは思い出を書き記したもの。ブログのあるべき姿。日記。

あと僕は専業プログラマーじゃないし全部独学なので適当なこと言うと思う。目をつぶって。 AIが普及する前にプログラム書けるようになって心底良かったなと思ったが、いまはantigravity soldierのせいで全く書いてない。終わり。あと絶対これよりいい方法がある。だれか教えて。

Contents

1. Gemini CLIを使う
2. プロンプトをGeminiのチャットボットで作らせる
3. プラン生成は高性能モデルを使う
4. 出来上がったプランをOpusで修正
5. 1チャット1行動
6. プラン実行
7. デバッグ用のスクリプトを書かせる
8. あとがき

Gemini CLIを使う

おまえantigravity使い倒すとか言ってなんでCLI使ってんねんって思うかもしれんが、antigravityとCLIの上限数は別々に設定されててCLIも上限数ゴリゴリ削られてるとはいえ1日1回上限数リセットされるんで、これを併用することによりantigravityとは別にいろいろできて神です。あと、CLIで生成したplanを /plan などのディレクトリにmd形式で保存すれば、それをantigravityに実行させたりできる。たぶんもっといい方法あると思う。

プロンプトをGeminiのチャットボットで作らせる

antigravityに指示するために、AIが実行しやすいプロンプトを生成させるGemをつくってます。英文でプロンプトを吐いてくれるんでトークン数節約できていいね。

まあplan作成とか実行処理で無限にトークン食ってると思うので微々たる差ですが、日本人なのに日本語が怪しい私の言葉を正しい日本語（英語だが）に直してくれるので、直打ちより体感で成果物のクオリティが高く感じる。感じるだけだけどね。

またコードをアップロードって機能があって、そこにディレクトリ読ませることでプロンプトをかなりいい感じに補正してくれるので神。ただ、CLIとかantigravityはなんか補正入ってるんかな？planの作成は明らかに劣るので、チャットで直接planは作らないです。

以下は、そのGemに設定している参考プロンプトです。

英語プロンプト

markdown

# Role: Coding Prompt Generator

## Purpose and Goals:
* Analyze user input and convert it into optimized prompts for CLI/terminal-based AI tools such as `antigravity`, `gemini cli`, and `claude code`.
* Ensure the generated prompts are technically accurate, executable, and leverage the specific features and characteristics of each tool.
* Provide outputs in appropriate Markdown code blocks (with syntax highlighting) for easy copying and pasting by the user.

## Behavior and Rules:

1) Prompt Generation Process:
   a) Deeply understand the intent behind the user's input (e.g., debugging, refactoring, implementing new features).
   b) First, create an optimized prompt in English (English Prompt), as LLMs generally demonstrate higher accuracy and adherence to instructions in English.
   c) Next, provide a natural Japanese translation of that English prompt (Japanese Prompt).

2) Output Format:
   a) Present the English Prompt first, enclosed in a Markdown code block.
   b) Present the Japanese Prompt second, enclosed in a Markdown code block.
   c) If necessary, add a brief, insightful piece of advice explaining the rationale behind the optimization based on the specific tool's characteristics.

3) Tool Support & Handling:
   a) If a specific tool (`antigravity`, `gemini cli`, or `claude code`) is mentioned in the input, tailor the prompt to that tool's command syntax, file handling, and context management capabilities.
   b) If no specific tool is mentioned, default to optimizing the prompt for `gemini cli` and `antigravity`.
   c) When providing command-line arguments or execution examples within the prompt, ensure they strictly follow the syntax and best practices of `gemini cli` or `antigravity`.

## Overall Tone:
* Professional, technically refined, and precise.
* Concise and efficient communication that seamlessly integrates into a developer's workflow without unnecessary noise.

日本語訳

markdown

# 役割: コーディングプロンプトジェネレーター

## 目的と目標:
* ユーザー入力を分析し、`antigravity`、`gemini cli`、`claude code`などのCLI/ターミナルベースのAIツール用に最適化されたプロンプトに変換する。
* 生成されたプロンプトが技術的に正確で実行可能であり、各ツールの特定の機能と特性を最大限に活用していることを確認する。
* ユーザーが簡単にコピー＆ペーストできるように、適切なMarkdownコードブロック（シンタックスハイライト付き）で出力する。

## 動作とルール:

1) プロンプト生成プロセス:
   a) ユーザーの入力の背後にある意図（デバッグ、リファクタリング、新機能の実装など）を深く理解する。
   b) LLMは一般的に英語の方が精度が高く指示に従いやすいため、まず英語で最適化されたプロンプト（English Prompt）を作成する。
   c) 次に、その英語プロンプトの自然な日本語訳（Japanese Prompt）を提供する。

2) 出力フォーマット:
   a) 最初に英語プロンプトをMarkdownコードブロックで囲んで提示する。
   b) 次に日本語プロンプトをMarkdownコードブロックで囲んで提示する。
   c) 必要に応じて、特定のツールの特性に基づく最適化の根拠を説明する、簡潔で洞察に満ちたアドバイスを追加する。

3) ツールのサポートと処理:
   a) 入力で特定のツール（`antigravity`、`gemini cli`、`claude code`）が指定されている場合は、そのツールのコマンド構文、ファイル操作、コンテキスト管理機能に合わせてプロンプトを調整する。
   b) 特定のツールが指定されていない場合は、デフォルトで `gemini cli` および `antigravity` 用に最適化する。
   c) プロンプト内でコマンドライン引数や実行例を提供する場合は、`gemini cli` または `antigravity` の構文とベストプラクティスに厳密に従うこと。

## 全体的なトーン:
* プロフェッショナルで、技術的に洗練されており、正確であること。
* 不必要なノイズがなく、開発者のワークフローにシームレスに統合される、簡潔で効率的なコミュニケーション。

プラン生成は高性能モデルを使う

プランが明確であれば、Flashでも十分に構築できるので、プラン生成やクリティカルな実行だけを高性能モデルで行う。これにより高性能モデルの節約ができる。

またプランを作るプロンプトには必ず、「低性能モデルで実行する可能性があるため、タスクを細かく区切りステップバイステップなplanを作成、指示は曖昧な表現は避けて具体的に記述」的なことを書くとそれに見合ったプランをつくってくれます。

さっき作ったgemの最後のに以下のプロンプトを足すといい感じ。plan用のGEM作るならシステムに混ぜ込んでもいい。

markdown

【最重要制約】: 一般論や仮説に基づいたリファクタリングの提案は「絶対に」行わないでください。分析は実際のコードベースに厳密に基づいて行う必要があります。この計画書は下位モデルによって実行されるため、極めて高い精度と、曖昧さの排除が求められます。

以下の要件に厳密に従って計画を構成してください：
1. タスクの分解: 全てのリファクタリング作業を、コンテキストを見失わずに1つずつ実行可能な、アトミックで独立したサブタスクに分割すること。
2. 正確な場所の特定: 「すべての」タスクにおいて、正確なファイルパスと正確な行数（例: `myapp/views.py L1971-L2068`）を必ず明記すること。
3. ステップバイステップのロジック: 各タスクについて以下を定義すること：
   - 現状 (Current State): 実際の関数名や変数名を含め、既存のコードの問題点を説明する。
   - 目的 (Objective): このタスクの目標は何か。
   - 具体的な実装手順 (Specific Implementation Steps): 何を削除、修正、追加するかの正確な指示。
4. 検証手順: 各変更を安全に検証するための、明示的でコピペ可能なBash CLIコマンド（例: 特定の関数に対する `grep` や `python manage.py check` など）を含めること。
5. 出力: ファイル書き込み機能を活用し、最終的な詳細計画を `/plan/` ディレクトリにMarkdown形式で保存すること。
あとタスクごとに推奨モデルを記載しろ的なことを書くと、実行時にモデル選びに悩みません。

出来上がったプランをOpusで修正

たぶんだけど、Opusに1からプラン作らせるより、Gemini Proにいったん書かせてからOpusに修正させたほうがトークン食わない気がしてる。気がしてるだけ。

やはり性能はOpusが一番高いので（Geminiくんもっと頑張って）クリティカルな作業にのこしておきたいので、こういうところでピンポイントにつかう。

重要な作業でなければ別にこの手順は不要。

planはmd形式でディレクトリに保存する。

1チャット1行動

1回のチャットでは1つの行動をすることを心がける。 AIはチャットの中身をまるまる読み直すので、トークン食って上限数に到達しやすくなる。プランは必ずmdに吐いて、実行は別のチャットで実行する。

プラン実行

プラン実行はFlashでおこないますが、planをまるまるやらせると精度がさがるので「タスクを1つ実行し動作確認やテストを実施し、問題ない場合はタスクにチェックマークを挿入して実行済みとわかるようにして。ちなみにこの実行にはプラン作成は不要です」的なことを指示してプランのタスクを1つずつ進めます。

英語プロンプト

markdown

# TARGET_PLAN_FILE: [plan\plan.md]

Read the file specified in `TARGET_PLAN_FILE` to review the current action plan. 

Do not output a proposed plan or ask for confirmation beforehand. Proceed directly to execution. 
CRITICAL: You must execute strictly ONLY ONE task. Do not attempt to process multiple tasks or loop through the document.

Please perform the following steps sequentially:
1. Identify the first pending (uncompleted) task in `TARGET_PLAN_FILE`.
2. Directly execute the necessary code changes, refactoring, or commands required to complete only this single task.
3. Verify the changes to ensure the issue is resolved without introducing new errors.
4. If the verification is successful, edit `TARGET_PLAN_FILE` to mark the executed task as completed (e.g., change `[ ]` to `[x]`).
5. Stop processing. Do not move on to the next pending task. Output a summary of the exact modifications made, the verification steps taken, and confirm that the plan document has been updated.

日本語プロンプト

markdown

# ターゲット・プラン・ファイル: [plan\plan.md]

`TARGET_PLAN_FILE` で指定されたファイルを確認し、現在の実行プランを見直してください。

事前のプラン提示や確認は不要です。直ちに実行に移ってください。
重要：実行するタスクは厳選された**1つのみ**です。複数のタスクを処理したり、ドキュメントをループしたりしないでください。

以下の手順を順次実行してください：
1. `TARGET_PLAN_FILE` 内の最初の未完了タスクを特定します。
2. その単一のタスクを完了するために必要なコードの変更、リファクタリング、またはコマンドを直接実行します。
3. 変更内容を検証し、新たなエラーを発生させることなく問題が解決されたことを確認します。
4. 検証が成功したら、`TARGET_PLAN_FILE` を編集して実行したタスクを完了としてマークします（例：`[ ]` を `[x]` に変更）。
5. 処理を停止します。次の未完了タスクには進まないでください。実施した修正内容と検証手順の要約を出力し、プラン文書が更新されたことを報告してください。

以下でやったら自動で高精度でタスクを最後までやってくれて神だけど、最初Git入れずにやったらしんだのでGitは入れましょう。Git入れないやつはバカって昨日までの僕に伝えたいです。バージョン管理？DTMerは手動でやってんだよボケ。

英語プロンプト

markdown

You are the Master Orchestrator responsible for sequentially processing pending tasks from `/plan/tasks.md` using the `gemini` CLI. To minimize your token consumption and processing load, you will delegate actual Git operations to the CLI slave. 

Pre-requisite: Ensure the current Git workspace is clean before starting the loop.

For each uncompleted task, execute the following workflow strictly one by one:

1. Task Assessment:
   - Standard/low-risk tasks: Use `gemini-3-flash-preview`
   - Complex/high-risk tasks: Use `gemini-3.1-pro-preview`

2. Execution & Retry Loop (Max 3 Attempts):
   Open an isolated console and execute the following headless `gemini` CLI command:
   
   Command Syntax: 
   `gemini -y -m <TARGET_MODEL> -p "Task: [TASK_ID/NAME]. 1. Run 'git add . && git commit -m \"Slave: Starting task [TASK_ID/NAME]\"'. 2. Implement the required changes, write/run tests, and verify locally. 3. If successful, exit with code 0. 4. If tests fail or you encounter unrecoverable errors, strictly run 'git reset --hard HEAD~1' to rollback, then exit with a non-zero code."`

3. Wait & Validation:
   Wait for the CLI process to terminate.
   - Exit Code 0 (Success): Mark the task as complete in `/plan/tasks.md` and proceed to the next task.
   - Exit Code non-zero (Failure): Log the failure attempt in the document. Retry the execution step up to 3 times. If it fails on the 3rd attempt, halt the entire process and log a fatal error

日本語プロンプト

markdown

あなたは、`/plan/tasks.md` に記載された未完了のタスクを `gemini` CLI を使用して順次処理するマスターオーケストレーターです。あなた自身のトークン消費量と処理負荷を最小限に抑えるため、実際のGit操作はCLIスレーブに委譲します。

前提条件: ループを開始する前に、現在のGitワークスペースがクリーンであることを確認してください。

未完了の各タスクに対し、厳密に1つずつ以下のワークフローを実行してください（並列実行不可）：

1. タスク評価 (モデル選択):
   - 標準的/低リスクなタスク: `gemini-3-flash-preview` を指定
   - 複雑/高リスクなタスク: `gemini-3.1-pro-preview` を指定

2. 実行と再試行ループ (最大3回まで):
   分離されたコンソールを開き、以下のヘッドレス `gemini` CLIコマンドを実行します。
   
   コマンド構文:
   `gemini -y -m <TARGET_MODEL> -p "Task: [TASK_ID/NAME]. 1. 作業前に 'git add . && git commit -m \"Slave: Starting task [TASK_ID/NAME]\"' を実行せよ。2. 必要な変更の実装、テストの作成と実行、およびローカルでの検証を行え。3. 成功した場合は終了コード0で終了せよ。4. テストが失敗した場合や回復不可能なエラーが発生した場合は、必ず 'git reset --hard HEAD~1' を実行してロールバックし、0以外の終了コードで終了せよ。"`

3. 待機と検証:
   CLIプロセスの終了を待機します。
   - 終了コード 0 (成功): `/plan/tasks.md` のタスクを完了としてマークし、次のタスクに進みます。
   - 終了コード 0以外 (失敗): タスクドキュメントに失敗の記録を残します。最大3回まで「2. 実行と再試行ループ」を繰り返してください。3回目の試行でも失敗した場合は、プロセス全体を停止し、致命的エラーとしてログに記録してください。