0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

思考のGeminiと実装のCopilotを使い分けてコードの精度を高める

Posted at

生成AIを使った開発が当たり前になりましたが、どのAIを使うかで迷うことはないでしょうか。「Gemini(またはChatGPT)だけで完結させようとしてコードが動かない」「GitHub Copilotに複雑な指示を出したら意図と違う実装になった」。こうした経験は誰にでもあるはずです。

私自身、試行錯誤の末にたどり着いたのが 「Geminiで拡散させ、Copilotで収束させる」 というアプローチです。それぞれの得意分野を理解し、パイプラインのように繋ぐことで、開発効率とコード品質の両方を劇的に向上させることができます。

今回は、私が実践している「いいとこ取り」のワークフローをご紹介します。

2つのAIの決定的な違い

まずは、両者の特性を「思考の方向性」という観点で整理します。

Gemini:拡散的思考(Divergent Thinking)

Gemini(特に3 Proなどの大規模モデル)は、ゼロからイチを生み出す計画フェーズに強みがあります。コンテキストウィンドウが広いため、プロジェクト全体の要件や設計思想といった「大きな文脈」を理解するのが得意です。

しかし、具体的なコーディングとなると弱点も露呈します。長いコードを一気に書かせると、存在しないライブラリを捏造したり(ハルシネーション)、途中でロジックが破綻したりすることがあります。また、ローカルの最新のファイル状況をリアルタイムに把握しているわけではありません。

GitHub Copilot:収束的思考(Convergent Thinking)

一方、IDEに統合されたGitHub Copilotは、与えられた明確なゴールに向かって正解を導き出す実装フェーズに特化しています。現在開いているファイルや関連ファイルの情報をコンテキストとして読み込んでいるため、プロジェクトのコーディング規約や既存のユーティリティ関数に沿った、精度の高いコードを生成します。

その反面、ゼロからの「計画力」は弱く、複雑な要件を丸投げすると処理しきれずに的はずれな回答を返したり、すぐにPremium Requestsのリミットに達してしまったりします。

推奨ワークフロー:Geminiを「PM」、Copilotを「実装者」にする

この特性を踏まえた最強の使い方は、Geminiに「作業指示書」を書かせ、それをCopilotに渡して実装させるというフローです。

Step 1: Geminiで設計とタスク出しを行う

まずはGeminiに対して、やりたいことの概要や要件を伝えます。ここではコードそのものではなく、アーキテクチャや手順を固めることに注力します。

重要なのは、プロンプトの最後に**「この内容を、別のAIエージェント(GitHub Copilot)が実装するための作業指示書としてまとめて」**と指示することです。

Geminiへのプロンプト例:

ReactとTypeScriptを使って、バリデーション付きのユーザー登録フォームを作りたいです。ZodとReact Hook Formを使用します。要件は以下の通りです...(要件詳細)。
これを実現するためのファイル構成と、各コンポーネントの責務を設計してください。最後に、GitHub Copilotに実装させるための詳細なマークダウン形式のプロンプト(指示書)を出力してください。

こうすることで、Geminiは人間が読むための説明ではなく、AIが理解しやすい構造化された指示テキストを生成してくれます。

Step 2: 作業指示書をCopilotに渡す

Geminiが出力した「作業指示書」をコピーし、VS CodeなどのIDE上のGitHub Copilot Chatに貼り付けます。

このとき、Copilotは現在のワークスペース(開いているファイルやディレクトリ構造)を認識しています。Geminiが作った「論理的な設計図」と、Copilotが持っている「現場の文脈」が組み合わさることで、驚くほど精度の高いコードが生成されます。

Copilotへの指示:

(Geminiが作った指示書をペースト)
@workspace 上記の指示に従って、src/components/UserForm.tsx を実装してください。既存のUIコンポーネント src/components/ui を活用すること。

Step 3: レビューと微修正

Copilotが出力したコードは、すでにプロジェクトの文脈(既存の型定義やコンポーネント)を考慮したものになっているはずです。人間は生成されたコードのロジックを確認し、微修正を行うだけで済みます。

なぜこの方法がうまくいくのか

すべてをGeminiでやろうとすると、プロジェクト固有の細かい文脈(ユーティリティ関数の場所や型定義の詳細など)が不足しがちです。それを補うために大量のファイルを添付すると、今度はコンテキストあふれを起こしたり、回答の精度が落ちたりします。

逆にCopilotだけでやろうとすると、「どう設計すべきか」という上流工程の思考が抜け落ちてしまい、場当たり的なコードになりがちです。

このワークフローでは、「What(何を作るか)」と「Why(なぜそうするか)」をGeminiが担当し、「How(どう書くか)」をCopilotが担当するという分業が成立しています。

将来の希望

Copilottだけで完結できたらいいんですけどね。なかなか…。いまはデュアルモニターでコピペをしています。

まとめ

AIツールは「どれか一つを選ぶ」ものではなく、「適材適所で組み合わせる」ものです。

  • Gemini: 拡散的思考でプランニングし、作業指示書を作る(アーキテクト/PM)
  • GitHub Copilot: 収束的思考で、指示書と現行コードを適合させて実装する(シニアエンジニア)

この役割分担を意識するだけで、AIの回答精度にイライラする時間は大幅に減ります。Premiumプランの制限を気にしながらCopilotに何度も聞き直すよりも、Geminiでしっかりとした「設計図」を作ってから渡す方が、結果として最短距離でゴールにたどり着けるはずです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?