Go開発者のためのGemini シリーズへようこそ！パート1: Geminiモデルファミリー では、ユースケースに応じたGeminiモデルの使い分けやAPIサーフェスを学び、公式の Go GenAI SDK を使って最初のGoコードを作成しました。
このパート2では、Geminiを活用してGoでコーディングする方法を探究します。AI時代におけるプログラミング言語の選択についての考察から始め、エージェント実行基盤（ハーネス）や標準規格の動向を整理し、開発環境でGoの「エージェンティック親和性（Agentic Affinity）」を最大限に引き出す推奨セットアップを紹介します。
AI時代になぜGoを使うのか？#
本題に入る前に、まずは根本的な疑問を解消しておきましょう。AI時代において、アプリケーション開発にどの言語を選ぶかは、果たして今でも重要なのでしょうか？
かつて、プロジェクトで使用する言語の選定は、チーム内の既存の専門知識に大きく左右されていました。新しい構文やデザインパターン、ツールの癖を習得するには膨大な時間が必要であり、開発の締め切りに追われる中で学習コストを払うのは難しかったためです。そのため、大きな技術的転換点や人材市場の変化といった強いビジネス上の動機がない限り、多くのチームは慣れ親しんだ快適な環境にとどまることを選択していました。
しかし、AIの登場によってこの力学は一変しました。モデルが必要なボイラープレートコードを瞬時に生成してくれる現代において、構文の習得はもはや高い参入障壁ではありません。確固たるソフトウェア工学の基礎さえあれば、AIをチューターとして活用することで未知のスタックを驚くほど素早く学習できます。5年前の古いStack Overflowの回答を何時間も探し回る必要はもうありません。
では、なぜ今言語の選定が重要なのでしょうか？それは、「言語エコシステム」 と 「エージェンティック親和性」 という2つの重要な要素に集約されます。
ここで言う言語エコシステムとは、その言語が持つ重力によって引き寄せられるものすべてを指します。活発にメンテナンスされているSDK、ライブラリ、ドキュメント、コミュニティの熱量、そして業界の知見などです。一方、エージェンティック親和性 は、まさに現代特有の概念です。私はこれを「エージェントにその言語でコーディングさせるのがどれだけ容易か」と定義しています。エージェンティック親和性の高さは、第一にモデルがその言語のコードをどれだけ正確に生成できるか、第二にコードの検証、テスト、保守を行うための開発ツールをエージェントがどれだけ自在に扱えるかによって決まります。
エージェンティック親和性は、モデルの学習時にその言語に関するデータがどれだけ豊富に存在したかに大きく依存するため、公開コードや技術文献が多い人気言語が自然と有利になります。ただし、データ量が多ければ良いというわけではありません。長い歴史の中で大きなパラダイムシフトを経験した古い言語では、コーディング手法やツールが断片化しており、推論時にモデルが非推奨の古いパターンを生成してしまうリスクが高くなります。
私の個人的な経験から言えば、Go、Python、JavaScriptなどの言語は、優れたツール群と活発なオープンソースコミュニティに支えられ、デフォルトで高いエージェンティック親和性を備えています。中でもGoは際立っています。高い可読性、厳格な静的型付け、そして「暗黙的であるより明示的である方が良い」という設計思想により、構文のハルシネーション（幻覚）が極めて発生しにくくなっています。さらに重要なのは、Goの高速なコンパイル、標準のテストフレームワーク、そして洗練された標準ツールチェーンが、コーディングエージェントに対して自律的にエラーを検知・修正するための即時かつ決定論的なフィードバックループを提供することです。（Goの設計哲学とAI支援エンジニアリングの親和性について詳しく知りたい方は、Google Developers BlogのCameron Balahan氏とRichard Seroter氏によるエッセイ をご覧ください）。
一方、RやCのような言語は対極に位置します。Rはニッチな学術言語であり、AIエージェントの全面的な支援を受けても、私の read.dbc パッケージをCRAN（Rの公式パッケージリポジトリ）上で適切にメンテナンスし続けることは困難です。CRANのパイプラインが報告するエラーをモデルも私自身も再現できないためです。またC言語では、言語仕様上のガードレールが少ないため、些細なミスが検知困難なメモリ破壊バグへと発展しやすく、人間向けのツール環境ではエージェントが早期にバグを発見するのが困難です。
最終的に、エージェンティック親和性の真価は、エージェントループの速度と応答性によって測られます。すなわち、エージェントが人間の手作業による介入を必要とせず、即座にコードのビルド、テスト、ベンチマーク、そして自動修復を実行できるかどうかが鍵となります。
適切なエージェント環境（サーフェス）を選択する#
フロンティアモデルの性能競争は目覚ましいものがありますが、コード生成においてモデル単体はパズルの1ピースに過ぎません。エージェントによるコーディングの品質と開発体験は、そのモデルを実行する「ハーネス（実行環境）」に大きく左右されます。
Geminiを活用してコーディングを行う場合、最も自然な選択肢は Antigravityエコシステム です。Googleは Antigravity 2.0 のリリースに伴い、開発者の作業スタイルに応じてエコシステムを3つのサーフェスに整理しました。
Antigravity 2.0#
Antigravityエコシステムの中核を成すのが、デスクトップアプリケーションである Antigravity 2.0（Agent Manager とも呼ばれます）です。最大の特徴は、エージェントとの対話体験を前面に押し出し、ソースコードを背後に配置した設計にあります。従来のIDEに慣れ親しんだ開発者にとっては、ファイルツリーがなく、手動でファイルを直接編集できない点に驚くかもしれません。すべての変更はエージェントを介して行われ、開発者はGoogleドキュメントのようなコメント機能でエージェントに指示を与え、作業をレビューします。
Antigravity CLI (agy)#
Agent ManagerのようなUIは比較的新しい概念ですが、ターミナルベースのエージェントUIは Claude、Aider、Cline などによって以前から広く普及しています。2025年6月、Googleも独自のターミナルUIとして Gemini CLI を発表しましたが、現在は新しい Antigravity CLI (agy) へと統合・移行されています。
Goエンジニアとして特に嬉しいポイントは、agy がGoで実装されている点です（従来のGemini CLIはTypeScript製でした）。これにより、ターミナルでの動作レスポンスが劇的に高速化されました。
Antigravity IDE#
視覚的で使い慣れたコードエディタ環境を好む開発者のために、Googleはコンパニオンアプリとして Antigravity IDE も提供しています。VS Codeをベースに構築されているため、おなじみの拡張機能やUI配置をそのまま利用でき、Geminiと対話するためのエージェントサイドパネルが統合されています。
個人的な作業スタイルを率直にお話しすると、最近はコーディング目的でIDEを開くことはほとんどなくなりました。IDEを使うのは、手動での執筆や編集作業が多い記事の執筆時（この記事の作成など）に限られています。コードに関しては、現在ほとんど手作業で編集することはありません。
コーディングに適用されるエージェント標準規格#
どのサーフェスを選択した場合でも、Antigravityは単体で高い能力を発揮しますが、固有の癖もあります。Antigravityの真価を引き出す最良の方法は、エージェントに適切な カスタマイズ（拡張機能） を導入することです。
Antigravityは、Rules、Skills、MCP、Hooks、Subagents、Sidecars、Pluginsといった確立された標準や新興の仕様を幅広くサポートしています。ただし、これらのカスタマイズ機能のサポート状況は、現時点ではAntigravityのサーフェス間で 完全には統一されていません。
それぞれのカスタマイズがどのように機能するかを見ていきましょう。
エージェントへの指示とルール（Instructions & Rules）#
エージェントへの指示という概念は AGENTS.md イニシアチブによって標準化され、Antigravityでは AGENTS.md や GEMINI.md ファイル（または .gemini/rules/ や .agents/rules/ 下のモジュール化されたルール）を通じてサポートされています。
AGENTS.md は、「AIエージェントのための README.md」と捉えることができます。プロジェクトのアーキテクチャ上の制約、テスト実行コマンド、コーディング規約など、エージェントが把握すべき必須情報でありながら、人間向けのドキュメントには冗長になりがちなコンテキストを記述する場所です。
正直なところ、Agent Skillsの登場以降、私自身は GEMINI.md を更新する機会が減り、多くのリポジトリで古いファイルが残ってしまっています。それでも、エージェントの方向性を大まかに導く上では依然として有用です。ただし、プロンプトベースの指示は「ガードレール（強制力）」というよりも「推奨事項」として機能するため、長時間のセッションではエージェントがルールを徐々に見落としたり逸脱したりする可能性がある点に留意してください。
Model Context Protocol (MCP)#
Model Context Protocol (MCP) は、AIアプリケーションを外部のツールやデータソースと接続するためのオープン標準規格です。
MCPは主に3つのプリミティブを提供します。
- Tools: エージェントが実行可能な関数（データベースへの問い合わせ、リンターの実行、ビルド検証など）。
- Resources: エージェントが閲覧できる読み取り専用のデータソース（ドキュメント、DBスキーマ、システムログなど）。
- Prompts: 定型化されたワークフローテンプレート。
実際の開発現場で最も活用されるのはToolsです。多くのクライアントはResourcesやPromptsをネイティブサポートしていません（ResourcesはTools経由で代替でき、Promptsは柔軟性の高いAgent Skillsへ移行が進んでいるためです）。
Skillsにはスクリプトを同梱できるため、MCPを完全に廃止してSkillsへ一本化しようとする動きもあります。しかし、ライフサイクル管理の観点（特にHTTPS経由の利用）では、依然としてMCPに大きな優位性があります。企業がMCPサーバーをWebサービスとしてホストすれば、開発者は一度設定するだけで常に最新のドキュメントやツールにアクセスできます。一方、Skillsの場合、全クライアントが確実に最新バージョンを参照する仕組みにはまだ課題が残されています。
Agent Skills#
Skill（スキル） は、指示書（SKILL.md）、任意のヘルパースクリプト、ドキュメントを同梱したディレクトリであり、特定のエージェントワークフローを実行する方法をエージェントに教育します。
Skillsの中核となるアーキテクチャ概念は 「段階的開示（Progressive Disclosure）」 です。数百ページに及ぶドキュメントを最初からコンテキストウィンドウに流し込むのではなく、システムはまずスキルの名前と概要文のみをエージェントに伝えます。エージェントがタスクとスキルの関連性を認識した時点で初めて、完全な SKILL.md の指示を読み込み、スクリプトを実行します。これにより、専門的な知識を常時利用可能にしつつ、コンテキストウィンドウの圧迫や無関係な情報によるモデルの混乱を防ぐことができます。
エージェントはスキルの説明文に基づいて自動発火を試みますが、自動判定のみに頼るのは確実ではありません。Antigravityではすべてのスキルがスラッシュコマンドとしてマップされるため、プロンプト内に /<skill-name> と入力することで確実にスキルを発火させることができます。重要なワークフローでは、明示的なスキル起動をおすすめします。
Hooks#
RulesやSkillsが「ソフトな誘導」を提供するのに対し、Hooks はエージェントの実行ループに「決定論的な制御」を導入します。ツール実行前（PreToolUse）、ツール実行後（PostToolUse）、モデル推論前（PreInvocation）、セッション終了時（Stop）など、特定のライフサイクルイベントに介入するコールバック関数です。
LLMは本質的に非決定論的であるため、プロンプトで「コード編集後は必ずリンターを実行すること」と指示しても、実行が担保されるとは限りません。一方、Hooksはハーネスによって強制的にトリガーされるため、確実な検証が可能になります。
ただし、Hooksを設計する際には注意すべき点があります。近年の高度なモデルは、Hooksを回避しようと試みることがあります。Hookによって危険な操作がブロックされた後、エージェントが設定を変更したり、トリガー条件を偽装したり、最悪の場合はHookスクリプト自体を書き換えてすり抜けようとするケースが報告されています。
そのため、私自身もかつては多用していたHooksから、徐々にSkillsによるガイダンスへと移行しています。子どもを育てるのと同じで、「禁止するよりも、正しい方法を教育する」アプローチが効果的です。
Subagents#
Subagents（サブエージェント） は、コンテキストウィンドウの肥大化を防ぎつつ、並列実行などの強力なパラダイムを実現します。メインエージェントが問題領域を分割し、個別のタスクに特化した子エージェントを生成して作業を委任します。
典型的な例として、フロントエンドとバックエンドが混在するWebサービスの開発が挙げられます。フロントエンド（HTML/CSS/JS）とバックエンド（Go/Python/SQL）では、適用すべきコーディング規約やビルドパイプラインが直交しています。共通のAPIインターフェースを除けば両者に重複はなく、同一のコンテキストウィンドウで処理すると互いのノイズになってしまいます。
タスクを複数のサブエージェントに分離することで、各エージェントは担当レイヤーに集中でき、異種スタックの混在によるコンテキストの品質劣化を防ぐことができます。
また、実装完了後のコードレビューをサブエージェントに依頼し、「先入観のない第三者の視点」でチェックさせる手法も非常に有効です。
Sidecars#
注: 執筆時点において、SidecarsはAntigravity 2.0でのみ動作し、
agyCLIやIDEでは利用できません。
Sidecars は、セッションの実行中、エージェントの背後で常駐動作するバックグラウンドプロセスです。Antigravityの再起動ポリシーによってライフサイクルが管理される永続プロセスや、スケジュール実行されるタスクを構成できます。
Sidecarsの本格的な活用は今後の課題ですが、同僚のMete Atamel氏が解説記事を公開していますので、詳細は 彼の記事 をご覧ください。
Agent Plugins#
Pluginsは、Rules、MCP、Skills、Hooks、Agents、Sidecarsを1つのパッケージとしてまとめた配布ユニットです。私自身もPluginsの検証を重ねてきましたが、現時点では期待通りにスムーズに動作しない場面があります。例えば、プラグインに同梱したHooksの実行保証に苦労した経験があります。
また、プラグインの機能サポートはサーフェスによって異なり、Antigravity 2.0でのみSidecarsが動作し、CLIでのみカスタムエージェントが動作するといった差異が存在します。
現時点で確実に機能するのはMCPとSkillsのバンドルです。偶然か必然か、業界全体も新しい Agent Plugins 仕様に向けて同様の収束を見せています。HooksやAgents、LSPサーバーなどはクライアント依存度が高いため、現行の標準化範囲からは一旦除外されています。
Goのエージェンティックツールキットを構築する#
ハーネスとカスタマイズの全体像を把握したところで、Go開発に特化した実践的なツールキットを揃えていきましょう。必須のコミュニティツールと、AIネイティブな専門拡張機能の2つに分類して紹介します。
必須のコミュニティツール#
Goの標準ツールチェーンはエージェントにとって極めて強力な基盤ですが、以下のコミュニティツールを導入することで、コード品質とリリース自動化が一段と向上します。
golangci-lint: 数十種類の高速リンターを一括実行し、go vetでは検知できない未処理エラー、型アサーションの不備、シャドーイング変数、並行処理の落とし穴を捕捉します。goreleaser: バイナリ配布を行うプロジェクトにおいて、.goreleaser.yamlに基づくクロスプラットフォームビルド、リリースパイプラインの管理、チェンジログ生成を自動化します。modernize/go fix: 最新のGoバージョンに合わせてコードを解析し、手動のスライス/マップループやmin/maxヘルパーを現代的な組み込み関数へと機械的にアップグレードします。deadcode: プログラム全体の到達可能性解析（Reachability Analysis）を行い、パッケージ間の未使用関数やデッドコードを特定します。seleneとtestquery（手前味噌ですが）: テストスイートの品質を検証・改善するために私が公開しているツールです。seleneは、ASTに意図的な欠陥を挿入してテストがバグを確実に検出できるかを検証するGo向けミューテーションテストツールです。testqueryは、テスト結果やカバレッジに対してSQLクエリを実行できるCLIです。テストスイートの最適化に役立てています。
AIネイティブな専門ツール#
上記のツールは元々人間の開発者向けに作られたものですが、コーディングエージェントはシェルコマンド経由でこれらを直接実行できます。続いて、AIネイティブな開発ワークフローに特化したMCPサーバーとSkillsを見ていきましょう。
公式 gopls MCPサーバー#
従来のIDEにおいて、gopls は型チェック、シンボル定義ジャンプ、参照検索などの意味解析（セマンティクス）を提供します。しかし、エージェントがターミナルやヘッドレス環境で動作する場合、通常はコードを生のテキストファイルとして扱います。
このギャップを埋めるため、Goチームは gopls にネイティブのMCPサポートを追加しました。MCPモードで gopls を実行すると、言語サーバーの型チェッカーとインデックスが実行可能なツールとしてモデルに直接公開されます。これにより、エージェントはコンパイラ自身のセマンティックモデルを利用してパッケージ構造を探索し、型シグネチャを正確に把握できるようになります。
godoctor MCPサーバー#
公式の gopls MCPサーバーに対する私の率直な懸念は、それがLSP（Language Server Protocol）のAPI上に設計されている点です。LSPは元々人間のキーストロークに合わせたタイピング速度とインタラクティブ性のために設計されたものであり、エージェントの「トランザクショナルな操作」には最適化されていません。そこで私は、AIネイティブなGo開発体験を提供するために godoctor を開発しました。
現行バージョンの godoctor は以下の機能を提供します。
smart_edit: 自動go vet検証とタイポ補正機能を備えたAST認識型ファイルエディタ。編集によってコンパイルエラーが発生した場合、変更を自動的にロールバックし、周囲の識別子に基づいて「もしかして…？」形式の修正候補を提示します。smart_build: モジュールのクリーンアップ（go mod tidy、modernize、goimports）、パッケージビルド、カバレッジ付きテスト実行、golangci-lintによる検証を一括で実行する自動化パイプライン。smart_test:testqueryおよびseleneと統合された実践的なテストパイプライン。read_docs:go docベースのドキュメント検索機能。サンプルコードの表示に対応し、モジュール構成に依存しないフォールバックシステムを備えています。
プラットフォーム知識と自己改善#
godoctor や gopls がローカルコードの意味解析を担当する一方で、エージェントが外部サービスと連携する際には、リアルタイムなプラットフォーム知識やベストプラクティス集が必要になります。Go、GCP、Geminiを組み合わせて開発する上で必須のリソースは以下の通りです。
- Google Developer Knowledge MCP (
developerknowledge.googleapis.com/mcp): Google Cloud、Gemini Enterprise (Vertex AI)、Google APIの公式ドキュメントにエージェントを直接接続します。 - Gemini Docs MCP (
gemini-api-docs-mcp.dev): 最新のGemini APIエンドポイント、SDK更新情報、構成パターンを提供します（詳細は Geminiコーディングエージェントガイド を参照）。 - 公式 Google Skills:
github.com/google/skillsおよびgithub.com/google-gemini/gemini-skillsには、Googleが公式にメンテナンスするSkills（gemini-api-dev、gemini-live-api-dev、gemini-interactions-apiなど）が収録されています。 - コミュニティおよび個人カタログ: 私の個人カタログ
skills.danicat.dev（または GitHub）では、エンジニアリングのベストプラクティス、2Dゲーム開発、生成メディア（Lyria、Nano Banana Pro）向けのSkillsを公開しています。
さらに、独自の拡張機能で開発環境を改善するためのツールもあります。
- AgentSkills MCP (
agentskills.io/mcp): Agent Skillsオープン仕様 やスキル作成のベストプラクティスを検索するための公式MCPサーバー。日々の業務で自作スキルを開発する際に非常に役立ちます。 - MCP開発向けSkills: エージェントスキル開発用のMCPが存在するなら、MCPサーバー開発用のAgent Skills も当然存在します（笑）。ニッチではありますが、自身の環境に合わせて独自のMCPサーバーを作成することも、開発効率を劇的に高める優れたアプローチです。
Gopherのための5分間エージェントセットアップ#
Geminiを使って今すぐGo開発を始めたい方のための、5分で完了する推奨クイックスタートです。
- 公式サイトから Antigravity をダウンロードします。
- 推奨MCPサーバーを設定します。
- Gemini Docs MCP:
npx add-mcp "https://gemini-api-docs-mcp.dev" - Developer Knowledge MCP: APIを有効化し、ドキュメントに従って設定します。
- Agent Skills MCP: 任意のページのコピーボタンから設定コマンドを取得します。
- godoctor: 1行インストールスクリプトを実行します。
- Gemini Docs MCP:
- 推奨Skillsを追加します。
- Gemini API development:
npx skills add google-gemini/gemini-skills --skill gemini-api-dev - Swarm coding:
npx skills add github.com/danicat/skills/agents/swarm-coding
- Gemini API development:
- 自律検証ループを試す:
エージェントに以下のプロンプトを入力して検証を実行させます。
Run a smart build on this package with godoctor, address any findings, and evaluate the test suite with selene.
次のステップ#
本記事では、エージェント実行環境の全体像、カスタマイズ規格（Rules、MCP、Skills、Hooks、Subagents、Plugins）、そしてGeminiを使った実践的なGo開発環境の構築方法について解説しました。
続く パート3: Goでエージェントを開発する では、テーブルの反対側へと進み、Goを用いた自律型エージェントランタイムの構築に挑戦します。ツール呼び出し（Tool Calling）ループ、コンテキストエンジニアリング、そして Genkit Go や Agent Development Kit (ADK) などの高レベルフレームワークについて詳しく見ていきます。それでは、パート3でお会いしましょう！
