はじめに

こんにちは。

前回、こちらの記事にてGemini 2.5 Proの力を借りてTTD-DR（Target-Time-Dependent Dynamic Routing）※1 の実装を行いましたが、読解ミスや力不足もあり不完全なものになっていました。
今回はさらに強力になったGemini 3.0 Pro (Preview)、そしてそれを搭載した新世代AIベースIDE: Antigravity の力を借りて再実装に挑みました。

※1 元論文 - Deep Researcher with Test-Time Diffusion - Arxiv.org

Gemini 3.0 Proは2.5と比較して読解力・推論力が段違いに高く、元論文の内容をより正確に把握できていました。
（前回の論文紹介の誤りについても後ほど訂正させてください）
またそれを搭載したAntigravityによる実装速度は驚異的の一言でした。

一方でAntigravityのUIの使い勝手はGeminiには一歩劣るので、現状のAI駆動開発では、

Geminiで構想・設計
Antigravityで実装

…という役割分担が最適解と感じました。

改めて実装

今回の実装にあたっては、

読解: 論文を読んで内容を理解する (Gemini 3.0 Pro)
設計: 読解の結果を元に、実装するための設計を行う (Gemini 3.0 Pro)
実装: 設計を元に実際の実装を行う (Antigravity)
ブラッシュアップ: 内容を洗練させていく (Gemini 3.0 Pro & Antigravity)

…という段階を踏んで実装していきました

1. 読解フェーズ:

前回の記事でご紹介したTTD-DRのロジックですが、一部に大きな誤りがありました（お詫び申し上げます）

今回のプロジェクトでは、前回と同じくGemini 3.0の力を借りてTTD-DRの論文を読解するところから始めました。
その結果、前回2.5の力を借りて読解した内容と異なる部分が見られ、再検証の結果誤っていることが判明しました。

Gemini 2.5 Proの課題:

最初は筋が通った説明をしているように見えても、説明が曖昧だったりする場所の詳細を突っ込むと矛盾が生じていた
その間違いを指摘しても訂正できず、強引に元の主張を通そうとする『幻覚の正当化』現象が見られた

Gemini 3.0 Proの進化:

今回改めて3.0に論文を読んでもらったところ、前回と異なる解釈が返ってきた
- 曖昧な部分が激減しており、詳細を聞いてもスムーズに答えてくれる
- また質問すると「論文のこの部分に基づくと～」とソースを明確に示しながら論理的に説明してくれるため、わかりやすく信頼性が非常に高い
  - まだ完全に無批判に受け入れることは出来ないものの、少なくとも人間が確認しやすくなったことは確か

正しいTTD-DRのロジック概要:

ここでは、TTD-DRの正しい構造について述べます。

TTD-DRのフローは大きく分けて3つのフェーズで構成されます。

①Initialize
- ユーザーからのクエリを元に、自己進化プロセス（後述）でリサーチ計画を作成
- リサーチ計画をLLMに渡し、初期ドラフトを作成
  - （※この時点ではクオリティが低くても問題ないため検索は行わない）
②Denoising
- （直前の）ドラフトを元に、自己進化プロセスで改善点を探し、検索クエリを作成する
- 検索クエリを元にWeb検索を行い、検索結果を取得
- 検索結果とドラフト、リサーチ計画を合わせて、自己進化プロセスでブラッシュアップされたドラフトを得る
- （このループを終了条件が満たされる（論文では規定回数のループが条件）まで繰り返す）
③Finalize
- 終了条件を満たしたドラフトを最終ドラフトとする
- 最終ドラフトに、それまでの全ての情報（リサーチ計画・各検索キーワードと検索結果・ドラフト修正履歴）を合わせて、自己進化プロセスを経て最終レポートを仕上げる

また、フローの随所に自己進化プロセスと呼ばれるプロセスが挟まれています。
これは単純なLLMクエリではなく、以下のようなフローで出力の品質を最大化するものです。
（前回の記事ではここの理解が大きく間違っていました）

自己進化プロセス
- クエリを入力する
- クエリに対する回答候補を、パラメータ（論文ではtemperature, top_k）を変えてLLMに渡すことで複数生成する
- それぞれの回答候補をLLMに渡し、自己批判（評価および改善ポイントのフィードバック）を得る
- フィードバックを元に、回答候補を修正して新たな回答候補を得る
- （自己批判→修正のループを終了条件が満たされる（論文では規定回数のループが条件）まで繰り返す）
  - （ただし論文中では各1回が推奨されている）
- 最後に、全ての回答候補をLLMに渡し、それぞれの良いところを取り込んだ一つの最終的な回答を生成して出力する

この手法は、類似手法に比べて主に以下のような特徴・利点があります（論文の記述より抜粋）

改善点の模索とブラッシュアップを毎回ドラフト全体から行うので、各要素ごとに改善するよりも全体の文脈の不整合が少なくなる
情報の検索と執筆を細かく繰り返すことで、得られた情報のロスが少なくなる
自己進化プロセスにより、一般的な検索クエリや修正ポイントだけでなくより視野の広い柔軟なブラッシュアップが可能
計算リソースに対するクオリティ上昇効率が高い（OpenAI Deep Researchに比べて70%程度高いという結果が得られた）

2. 設計・実装フェーズ:

今回は実装はAntigravityで行うため、Geminiには構成の構想・要件定義までを依頼しました。

アーキテクチャの決定

まずは最低限動くもの（MVP）を作るため、構成としては複雑なクラウド構成は避けて、

ローカルサーバー（Fast API）
Geminiへのクエリ経路（Vertex AI Gemini API）

という構成で作成することにしました（Geminiの提案を採用）

MVPの生成

MVPを作るにあたり、Antigravityに提供した資料は以下の2つです。

実装仕様書:
- これは読解フェーズで得られた理解を元に、どのようなシステムを構成するかをGeminiと相談して決めたものです（論文の記述をベースに、まずは最低限の機能が得られるように簡略化アレンジを加えました）
  - Canvasでの出力までやってくれたので、Googleドキュメントにエクスポート→pdf形式でダウンロードしました（ここは直接ダウンロードできるようにしてもらえると助かるんですが）
ワークフロー:
- これもGeminiにお願いして作ってもらった、どのようなフローで処理がされるかのデータです。
  - こちらはmermaid形式で記述してもらい、同じくCanvas→Googleドキュメント経由でpdf化しました。

・TTD-DR (Test-Time Diffusion Deep Researcher) 実装仕様書.pdf：具体的な実装内容の指示書です。
・TTD-DR (Test-Time Diffusion Deep Researcher) Workflow Specification.pdf：TTD-DRのワークフローです。これに沿った動きをするようにしてください。

あなたにお願いしたいこと：
TTD-DRを実現するシステムを、ローカル・GCPのハイブリッド環境を使って実装したいです（GCPだけでも構いません）
大まかな構成および細かいワークフローは資料としてお渡しします。作れそうでしょうか？

※お願い：こちらとのやりとり、プランの資料などはなるべく日本語で書いて欲しいです（英語を交える形でも大丈夫です）

自分としては、まず資料を読んでもらい、作れるかどうか（足りない情報がないかどうか）判断してもらうつもりだったのですが…

いただいたPDFファイルの内容を確認し、実装プランを作成しました。 ttd_dr フォルダ内にシステムを構築する計画です。

確認事項:

実装には GCP (Google Cloud Platform) の認証情報（API Key, Custom Search Engine ID, Project ID）が必要です。これらは .env ファイルで設定する形にします。
ローカル環境で動作させつつ、将来的に Cloud Run 等へデプロイ可能な構成にします。
プランの内容をご確認ください。問題なければ実装を開始します。

なんと、一気にプランニングまで済ませて実装の直前まで行ってしまいました。スピード感がGeminiチャット経由の時とは違う…
どこまでやってもらえるかわからないですが、まあ試しにやってもらおうとお願いしたところ…

TTD-DRシステムの実装が完了しました。

次のステップ:

ttd_dr フォルダ内の .env.example をコピーして .env を作成し、GCPの認証情報を入力してください。
以下のコマンドでサーバーを起動します：
bash
cd ttd_dr
uvicorn main:app --reload
ブラウザで http://localhost:8000 にアクセスして動作確認を行ってください。
まずはロジックの疎通確認として、モックテストを実行することも可能です：

bash
python ttd_dr/tests/test_workflow.py
（※モックテストは外部APIを呼ばずに動作フローだけを確認します）

問題がなければ、これで完了とさせていただきます。

すごいですね！！！
なんと、たった2ターンのやりとりでMVPが出来上がってしまいました。
試しに認証情報を入力して動かしてみたところ…普通に動きました！

3. 改善フェーズ

機能改善

もちろんこの段階ではMVPであり、そのままでは使いづらい部分も多々ありました。
なので、Antigravityのチャット経由で改善を行っていきます。

UIのブラッシュアップ
ログ出力の強化
GCP（Cloud Run）への移行

基本的に人間がコーディングすることはなく（キーの入力などは除く）、チャット経由で自動的にコードが書き込まれていきます。これがプロンプトエンジニアリングの完成形か…

デバッグ

実際に動かしてみるとうまく動かなかったりすることもありますが、エラーメッセージを渡せばすぐにデバッグしてくれるので非常に楽でした。
時々袋小路にはまってしまい、デバッグ用のprintなどを追加してもらったり人の手による救出が必要になることもありますが、それが起こる確率は体感で10分の1以下でした。
（Antigravityが抜け出せなくなったら、Geminiにコードとエラーを渡して解析してもらうと的確な答えを返してくれることが多い）

機能追加とAntigravityの限界

論文の記述だけだと製品化には物足りない部分もあるので、いろいろな機能を追加していきます。

Web検索以外のソース（データベースなど）を検索対象とする機能
検索キーワードにいろいろな要素を入れすぎるとWeb検索が非効率的になるため、キーワードを分割させる機能
NotebookLMのように引用した情報を論文中に記載する機能…など

Antigravityは、仕様書に沿って『最初の環境』を作る能力はすさまじいの一言です。
しかし、後からどんどん機能を足していったりデバッグを繰り返したりすると、だんだんと一発では実装できないことが多くなっていきます。
これはGeminiチャットがコンテキストウィンドウに縛られるのと似ていて、おそらくですがAntigravityが現状の仕様を把握・管理しきれないこと…そして単純に複雑化しすぎて修正箇所が他の機能に影響を与えてしまうことが原因と思われます。

リファクタリング
コードが複雑になりすぎてどうにもならなくなってきたら、以下の手順でリファクタリングを行います。

Geminiにコード全体を渡し、現状の仕様書を作成してもらう
- これは機能を追加しすぎるとGeminiだけでは一度で把握しきれず、手動またはGeminiとのやりとりによる大幅な修正が必要になるため、仕様書の更新はある程度定期的に行った方がいい
完成した仕様書をベースにまたAntigravity用の実装計画プロンプトを作ってもらい、仕様書と一緒にAntigravityに渡して一からコーディングを行う

…これを定期的にやるとなると少々手間ですが、人間の手でリファクタリングよりは遙かに簡単になります。

結論: 現時点での最強の開発ホットライン

Antigravityは、コードの生成と直接書き込み・オートテスト機能などコーディング関連の機能が非常に強力ですが、UIという観点ではGeminiには見劣りします
一方Geminiチャットはドキュメント作成（Canvas含む）・調査能力（Deep Research含む）・複数の形式のファイルの取り扱いなど、UIとしての対話能力が高いですが、マルチモーダル・汎用ツールであるが故にコーディング能力だけに絞るとAntigravityにはかないません

TTD-DR以外のアプリ開発も含めて検証した結果、以下のワークフローが最も効率的だと感じています。

①構想・設計 (PM/Architect役: Gemini)

Geminiとの対話で作りたいものの大枠を固める
UIやUX、他のGoogleサービス（GWS等）との連携もここでチェックする
重要: Geminiに「実装のためのプロンプト（Markdown）」を作ってもらう

②実装 (Coder役: Antigravity)

作成してもらったプロンプトをAntigravityに渡し、コードを書いてもらう
- コードに密着した修正能力を活かす

③レビューと修正ループ

書いてもらったプログラムを動かす
気になる部分があったら、再び
- Geminiに相談
- → プロンプト修正
- → Antigravityで反映
…のループを繰り返す

「Gemini（広範な知識・連携・設計）」×「Antigravity（強力な実装力）」 の組み合わせが、現状では最適解と言えそうです。

あとがき

改めて、生成AIの進化はすごいですね…
前回も生成AIによる開発は手動を上回ると記載していましたが、AIが直接コードを書き込むようになっただけでさらに数段上のスピードになっています。
ここ数年だけ見ても、

GitHub Coplilotなどによるコーディング補助の登場
Geminiチャットなどによるコード生成の登場
Claude CodeやAntigravityなど、直接コードを編集できるエージェント型AIのコーディングの登場

…と、めまぐるしい進化を遂げています。次に来るのは何でしょうね…

Claude Codeなどの完全対話型（と言っていいのか）のエージェントとAntigravityのようなエージェントAI搭載IDEの比較で言うと、視覚化されており人間の手も入れやすいAntigravityの方が現状の生成AIのレベルには合っているかなと感じます。
しかしもっとレベルの高い生成AIが登場すれば、その地位も逆転するのでしょうか。

弊社の社員の一人が、「仕事でコードを書くのは今年で最後になりそうだな」と言っていましたが、そんな未来が目前に迫っているのがちょっと怖くもあり楽しみでもあります。
来年の年明けぐらいには人間がコードを触る必要がなくなり、そもそもPythonなど高級言語自体が前世代のものになっていたりしそうですね。
その頃に自分がまだエンジニアをやれているのか、大いに不安ではありますが…あまり不必要に怯えることなく、「すごい時代の変化に立ち会えたな」ぐらいの気持ちでいたいと思います。