Geminiで大規模コード生成を成功させる7つの技術的ポイント｜Google現場から学ぶ実践AI活用術

「AIにコードを書かせているけれど、思うような品質が出ない」「プロンプトを工夫しているつもりなのに、指示から外れた結果ばかり返ってくる」――こんな悩みを抱えているエンジニアの方は多いのではないでしょうか。

実は、その悩みはGoogleの現場エンジニアも経験してきた課題そのものです。Google Cloudでは、100以上のプロダクト向けに提供している教育用コードサンプルをGeminiで大規模に自動生成するシステムを構築しました。そのプロセスで得られたリアルな知見が、2026年2月にGoogle Cloud公式ブログで公開されました。

この記事では、その7つの技術的ポイントをエンジニア目線で深く解説し、あなたのプロジェクトやチームの業務に即座に応用できる形でお届けします。AI活用を個人利用の範囲で留めず、チーム全体・プロダクション品質で活かしたい方にとって、非常に示唆に富む内容です。ぜひ最後までお読みください。

Googleが直面した「大規模コード生成」という難題
- 問題の背景：100以上のプロダクト、複数言語のサンプルコード
- システムの全体アーキテクチャ
ポイント1〜2：LLMの弱点を補う「分解」と「決定論」
- ポイント1：問題を小さく分解する（Decompose）
- ポイント2：決定論的に解ける問題はLLMを使わない（Adopt Determinism）
ポイント3〜4：プロンプトと評価の質を上げる
- ポイント3：プロンプトは「驚くほど具体的に」書く
- ポイント4：評価システム自体を評価する（Evaluate the Evaluator）
ポイント5〜6：システム全体をスケールさせ、テストで品質を保証する
- ポイント5：LLM以外の部分もスケールを意識する
- ポイント6：エンドツーエンドテストをすべての基準に据える
ポイント7と実践への応用：優れたエンジニアリングがすべての基盤
まとめ：Googleの現場が証明した「AI活用の本質」

Googleが直面した「大規模コード生成」という難題

問題の背景：100以上のプロダクト、複数言語のサンプルコード

Google Cloudには現在100以上のプロダクトが存在します。それぞれのプロダクトに対して、JavaScript・Python・Go・Javaなどのクライアントライブラリを使ったサンプルコードが必要です。これらのサンプルは開発者がAPIの使い方を学ぶための「教科書」であるため、単に動けばよいというものではありません。

多種多様な読者：プログラミング初心者から経験豊富なエンジニアまで
教育的な正確さ：コードの各行が意図を持って設計されている必要がある
一貫したスタイル：どのサンプルも同じ開発者が書いたかのような統一感

手書きでこれだけの量を賄うことは現実的でなく、2024年後半からGeminiとGenkit（生成AIツール開発用のオープンソースフレームワーク）を活用した専用の自動化システムを構築し始めました。

システムの全体アーキテクチャ

Googleが構築したシステムは、大きく3つのサブシステムで構成されています。

サブシステム	役割	使用技術
生成	サンプルファイル・単体テスト・package.jsonなどを生成	Gemini + Genkit
検証	生成コードをスコアリングしフィードバックを生成	LLM-as-a-judge + Linter
デリバリー	人間のレビューを経てGitHub・ドキュメントサイトへ公開	エンドツーエンドテスト

この3層構造こそが、単純なプロンプト試行とは一線を画す「プロダクションレディ」なAIシステムの骨格です。では、この構築過程で明らかになった7つのポイントを一つずつ見ていきましょう。

ポイント1〜2：LLMの弱点を補う「分解」と「決定論」

ポイント1：問題を小さく分解する（Decompose）

最初の失敗は「問題が大きすぎた」ことでした。1回のプロンプトでサンプルファイル全体を生成させようとしたところ、Geminiは意図しないコードを生成し始めました。具体的には、不要なコメントの追加や、意図していないprocess.exit()呼び出しなど、「指示から外れた」動作が頻発したのです。

解決策は「分解」でした。サンプルファイルを2つのパーツに分けました。

スニペット（Snippet）：開発者に価値を提供する教育的なコア部分
CLIロジック：コマンドラインからサンプルを呼び出すための汎用部分

それぞれのパーツに対して独立したプロンプトを割り当てることで、LLMへの要求を「小さく・具体的に」できました。結果として、ハルシネーション（LLMが誤った情報を生成してしまう現象）と指示からの逸脱が大幅に減少しました。

💡 エンジニアへの示唆 「1つのプロンプトで全部やらせよう」という発想は危険です。マイクロサービス設計と同じ考え方で、AIへの指示も単一責任の原則（SRP）で分割しましょう。例えば、「DBスキーマ設計」「モデルクラス生成」「APIエンドポイント生成」をそれぞれ別のプロンプトに分けるだけで精度が上がります。

ポイント2：決定論的に解ける問題はLLMを使わない（Adopt Determinism）

開発チームが陥りがちな「視野狭窄」——それは、どんな問題もLLMで解こうとしてしまうことです。Googleのチームも、気づけばすべての課題にGeminiを使おうとしていた時期があったと振り返っています。

実際には、以下のような処理はルールベースの決定論的な方法のほうが確実で高速です。

Apacheライセンスヘッダーの自動付与
package.jsonやrequirements.txtなどの依存関係マニフェストの生成
LintエラーのAuto-fix（eslint --fixなど）
LintフィードバックのフォーマットをGeminiに渡す形式に変換する処理

これらをLLMに任せると、コストも時間も無駄になります。「LLMは万能ではない。決定論で解ける問題は決定論で解く」というシンプルな原則が、システム全体の信頼性を底上げします。

ポイント3〜4：プロンプトと評価の質を上げる

ポイント3：プロンプトは「驚くほど具体的に」書く

「プロンプトは具体的に」というのはよく聞く話ですが、Googleチームの事例はその重要性を極端なまでに示しています。彼らはサンプルコードに関して100以上の設計上の決定事項についてチーム内で合意を取り、それをすべてプロンプトに明文化しました。

例えば、こんな細かい指示も必要でした。

// NG：Geminiが勝手にデフォルト値を設定してしまう
async function createGlossary(
  projectId = 'example-project-id', // Geminiがここを追加してしまう
  ...
) {

// OK：プロンプトで「デフォルト値を設定しないこと」と明示した結果
async function createGlossary(
  projectId,
  location,
  glossaryName,
) {

これは、プロンプトが「暗黙の前提」を排除できているかどうかの問題です。Geminiにとって「常識」と「あなたのコーディング規約」は別物です。

プロンプトを具体的にするメリットはもう一つあります。それは「シフトレフト」です。検証フェーズで初めてフィードバックされていた指示を、最初の生成プロンプトに前倒し（シフトレフト）することで、修正ループの回数を減らせます。

プロンプトの具体性	発生しやすい問題	修正コスト
抽象的・曖昧	ハルシネーション、スタイル不統一	高い（後工程での修正が必要）
具体的・明示的	ほぼなし	低い（最初から品質が高い）

ポイント4：評価システム自体を評価する（Evaluate the Evaluator）

「LLM-as-a-judge」とは、別のLLMを使って生成されたコードの品質を評価させる手法です。人間が一件一件チェックするよりも高速に、一定の精度でフィードバックを生成できます。

しかし、Googleのチームはここで重要な問いを立てました。「評価するLLM自身は信頼できるのか？」

彼らは実際に、手作業で「不完全なサンプルコード」と「正解」のペアデータセットを作成し、LLM-as-a-judgeが正しく判定できるかを検証しました。結果として、一部の評価質問ではGeminiが一貫して正解できないことが判明しました。

この「危うい質問」を特定・除去し、評価プロンプト全体を改善したことで、検証システムの信頼性が大幅に向上しました。

💡 エンジニアへの示唆 社内でAIが生成したコードをレビューする仕組みを作る場合、そのレビューAIが本当に機能しているかを定期的に「人間の正解データ」で検証する習慣を持ちましょう。AIによる評価も、ブラックボックスにしてはいけません。

ポイント5〜6：システム全体をスケールさせ、テストで品質を保証する

ポイント5：LLM以外の部分もスケールを意識する

「AIシステムのスケーリング」と聞くと、LLMの処理能力やAPIのレートリミットばかりに目が向きがちです。しかし、Googleのチームが最大のボトルネックとして特定したのは、意外な部分でした。

それは「人間によるレビューとエンドツーエンドテスト」のフェーズです。

1件のサンプルを公開するまでに、エンドツーエンドテストや人間のレビューを含めると5〜15分かかります。数百件のサンプルを一度に処理しようとすると、Geminiはスムーズに生成できても、後段の人間プロセスが追いつかないわけです。

AIシステムを業務に組み込む際に見落とされやすいのが、このパイプライン全体のスループット設計です。AIが速くなっても、前後の人間プロセスがボトルネックになれば全体は遅くなります。

スケールを考慮すべき要素	具体例
LLMのAPI制限	レートリミット、トークン数上限
後段の人間プロセス	レビュー、承認、デプロイ
インフラのスループット	CI/CDパイプライン、テスト実行環境
コスト	大量呼び出し時の従量課金

ポイント6：エンドツーエンドテストをすべての基準に据える

Googleがこのプロジェクトで達した哲学的な結論は明快です。「コードが実際に動かなければ、公開できない」。

これは当たり前のように聞こえますが、AI生成コードに対しては見落とされやすいポイントです。「AIが生成したのだから、だいたい合っているだろう」という過信は危険です。GoogleのDORA（DevOps Research and Assessment）プログラムも、この「信頼するが検証はする」アプローチを「成熟したAI導入」の証として評価しています。

手書きのサンプルでは当然のように行っていたエンドツーエンドテストを、AI生成のサンプルにも同じ基準で適用する——この一点を守るだけで、品質の崩壊を防げます。

実際のテストフロー（Googleの例） 1. Geminiがサンプルコードと単体テストを生成 2. Linterによる静的解析（決定論的） 3. LLM-as-a-judgeによるスタイル・品質評価 4. 人間によるレビュー 5. 実際の環境でエンドツーエンドテストを実行 6. 合格したものだけGitHubとドキュメントサイトへ公開

ポイント7と実践への応用：優れたエンジニアリングがすべての基盤

ポイント7：「AI固有の話」だと思っていたことは、実は普通のエンジニアリング

7つめのポイントは、ある意味最も深い示唆を含んでいます。Googleのチームが振り返ると、上述した6つのポイントの多くは、LLMに固有の話ではありませんでした。

問題を分解する → SRP（単一責任の原則）
決定論的に解ける問題を見極める → 適切なツール選定
プロンプトを具体的にする → 仕様書の明確化
評価システムを評価する → テストのテスト（メタテスト）
エンドツーエンドテスト → 品質保証の基本

確立されたソフトウェアエンジニアリングのベストプラクティスをAIシステムにも忠実に適用すること。それが結局、プロダクションレディなAIシステムを作る最短経路だったのです。

既存のAIコーディングツールとの比較

Geminiを使ったコード生成は、日常的なコーディング支援ツールとどう使い分けるべきでしょうか？

ツール	主な用途	強み	向いていないケース
Gemini（API）	大規模・バッチ生成、カスタムシステム構築	Google Cloud連携、長文コンテキスト対応	インタラクティブなリアルタイム補完
Gemini Code Assist	日常的なコーディング支援（VS Code等）	1日6,000件の補完、IDEシームレス統合	大規模バッチ処理
GitHub Copilot	GitHubリポジトリとの連携、補完	GitHub/Azure連携が強力	Google Cloud中心の開発
Cursor	AIネイティブのIDE体験	チャットベースの高度な生成	既存IDEからの移行コスト
ChatGPT（GPT-5）	複雑な推論、マルチファイル整合性	長い推論チェーンの安定性	Googleサービスとの連携