Go開発者のためのGemini シリーズへようこそ！パート1: Geminiモデルファミリー では、ユースケースに応じたGeminiモデルの使い分けやAPIサーフェスを掘り下げ、公式の Go GenAI SDK を使って最初のGoコードを作成しました。
続くこのパート2では、Geminiを活用してGoでコーディングを行う方法を探究します。まずは「AI時代におけるプログラミング言語の選択」についての考察から始め、エージェントハーネス（実行環境）や標準規格の動向を整理し、開発環境でGoの「エージェンティック親和性（Agentic Affinity）」を最大限に引き出すための推奨セットアップを紹介します。
AI時代になぜGoを使うのか？#
本題に入る前に、まずは根本的な疑問を解消しておきましょう。AI時代において、私たちがどのプログラミング言語を選ぶかは、そもそも重要なのでしょうか？
かつて言語の選定は、ほぼ常にチーム内の既存の専門知識によって決まっていました。新しい構文やイディオム、開発ツールの癖を習得するには貴重な時間が必要であり、大きな技術的転換に迫られない限り、多くのチームは慣れ親しんだ快適な領域にとどまっていました。
しかしAIの登場によって、その力学は一変しました。モデルが必要なボイラープレートコードをオンデマンドで生成してくれる現代において、構文はもはや参入障壁ではありません。5年前の古いStack Overflowのスレッドが自分のコンパイラエラーと完全に一致することを祈りながら何時間も過ごすくらいなら、AIチューターと一緒に見慣れないスタックを学ぶほうがはるかに快適です。
では、なぜ今言語の選定を気にする必要があるのでしょうか？ それは、言語エコシステム と エージェンティック親和性（Agentic Affinity） という2つの主要なテーマに行き着きます。
ここで言う言語エコシステムとは、その言語が持つ「重力」によって引き寄せられるものすべてを指します。活発にメンテナンスされているSDK、ライブラリ、ドキュメント、コミュニティの熱量、そして業界の知見などです。一方、エージェンティック親和性 は、私たちが今日生きている世界に特有の概念です。私はこれを「エージェントを誘導してその言語でコードを書かせることがどれだけ容易か」と定義しています。高いエージェンティック親和性は、第一にモデルがその言語でコードを生成する準備がどれだけ整っているか、第二にそのコードを検証・テスト・保守するために必要なツールをエージェントがどれだけ自在に扱えるかによって決まります。
エージェンティック親和性は当然ながら、モデルの学習時にその言語に関するデータがどれだけ豊富に存在したかに左右されるため、公開コードや技術文献が豊富な人気言語が自然と有利になります。とはいえ、データ量だけがすべてではありません。歴史の中で大規模なパラダイムシフトを経験した古い言語ではベストプラクティスが断片化しており、推論時にモデルが非推奨の古いパターンを提案してしまう原因になります。
私の個人的な経験から言えば、Go、Python、JavaScriptなどの言語は、デフォルトで高いエージェンティック親和性を備えています。中でもGoは際立っています。高い可読性、厳格な静的型付け、そして「暗黙的であるより明示的である方が良い（explicit is better than implicit）」というPython的とも言える設計思想により、構文のハルシネーション（幻覚）が極めて発生しにくくなっています。さらに重要なのは、Goの高速なコンパイル、標準のテスト機能、そして洗練された標準ツールチェーンが、コーディングエージェントに対して自律的にエラーを検知・修正するための即時かつ決定論的なフィードバックループを提供することです。（Goの設計思想がAI支援ソフトウェアエンジニアリングとどのように合致しているかについて詳しく知りたい方は、Google Developers Blogに掲載されたCameron Balahan氏とRichard Seroter氏によるエッセイ をご覧ください）。
一方で、RやCのような言語はスペクトラムの対極に位置します。Rはニッチな学術向け言語であり、エージェントの手厚いサポートがあっても、私の read.dbc パッケージをCRAN（Rのパッケージ配布システム）上で適切にメンテナンスし続けることができません。CRANのパイプラインから報告される問題を、モデルも私自身も再現できないためです。またC言語では、言語仕様上のガードレールが少ないため、些細なミスが致命的かつ潜在的なバグへと発展しやすく、充実したツール環境（エルゴノミクス）がなければエージェントが早期にバグを発見するのは困難です。
最終的にエージェンティック親和性は、エージェントの「ループ」の速度と応答性によって測られます。すなわち、人間の細かな介入（マイクロマネジメント）なしに、エージェントが最初から自律的にコードをビルドし、テストし、ベンチマークを取り、修復できるかどうかが鍵となります。
適切なエージェントサーフェスを選択する#
フロンティアモデルの性能競争は目覚ましいものがありますが、コード生成においてモデル単体は方程式の1ピースに過ぎません。エージェントを使ったコーディングの応答品質や開発者体験（DevEx）は、モデルを実行する「ハーネス（実行環境）」に大きく左右されます。
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) へと移行・一本化されています。
Gopherとして特に嬉しいポイントは、agy がGoで実装されている点です（従来のGemini CLIはTypeScript製でした）。これにより、ターミナルでの体感レスポンスが目に見えて軽快になっています。
Antigravity IDE#
視覚的で使い慣れたコードエディタ環境を好む開発者のために、Googleはコンパニオンアプリとして Antigravity IDE も提供しています。VS Codeをベースに構築されているため、おなじみのIDE要素がそのまま配置されており、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やPrompts、さらにはSkillsが「ソフトな誘導」を提供するのに対し、Hooks はエージェントの実行ループに「決定論的な制御」を導入します。ツール実行前（PreToolUse）、ツール実行後（PostToolUse）、モデル推論前（PreInvocation）、セッション終了時（Stop）など、エージェントのライフサイクルにおける特定の瞬間に介入するコールバック関数です。
LLMは非決定論的であるため、プロンプトで「コード編集後は必ずリンターを実行すること」と指示しても、実行されるかどうかは運任せになります。一方、Hooksはハーネスによって制御され、指定されたイベントに対して確実に実行されます。
ただし、Hooksを設計する際に常に注意すべき落とし穴が1つあります。モデルはHooksを回避するのが非常に得意だということです。ええ、残念ながらこれは実際に起こります。Hookがエージェントの危険な操作を阻止したとしても、エージェントはエージェント設定を改ざんしたり、トリガー条件をごまかそうとしたり、最悪の場合はHookスクリプトそのものを書き換えたりして、直後にHookを出し抜こうとします。
こう言うのは心苦しいのですが、以前はHooksを多用していたものの、新世代のモデルは賢くなりすぎて裏をかくようになってしまったため、私は徐々にHooksからSkillsへと移行しています。子育てと同じですね。「禁止するのではなく、教育する」のです。
Subagents#
Subagents（サブエージェント） は、コンテキストウィンドウの問題に対するもう1つの解決策であり、並列実行などの興味深いパラダイムを可能にします。メインエージェントが問題領域を分割し、個別のタスクに特化したエージェントを生成して作業を委任します。
分かりやすい例として、フロントエンドとバックエンドの両方を持つWebサービスの開発が挙げられます。ここでの変更は互いに直交しています。フロントエンドはHTML、CSS、JavaScriptを必要とし、バックエンドはGo、Python、そしてSQLを必要とします。フロントエンドとバックエンドのタスクでは、コーディング規約もビルドパイプラインも異なります。両者の契約（APIインターフェース）を除けば共通点はなく、同一のコンテキストウィンドウで作業を行うと、一方の情報が他方にとって単なるノイズになってしまいます。
タスクを2つ（またはそれ以上）のサブエージェントに分割することで、各サブエージェントが担当レイヤーに集中できるようになり、まったく異なる技術スタックが混ざり合ってコンテキストが劣化するリスクを抑えられます。
もう1つの好例は、完了したばかりの作業について客観的なレビューを行いたい場合です。エージェントにサブエージェントでのコードレビューを実行させれば、「先入観のない新鮮な視点」でコードを精査できるメリットが得られます。
Sidecars#
注記: 本稿執筆時点では、SidecarsはAntigravity 2.0でのみ動作します。
agyCLIやIDEでは利用できません。
Sidecars は、セッションの実行中、エージェントと並行して動作するバックグラウンドプロセスです。Antigravityの再起動ポリシーによってライフサイクルが管理される永続プロセスや、スケジュール実行されるプロセスを構成できます。
私自身はまだSidecarsを本格的に探究できていないため、現時点で議論できることは多くありませんが、同僚のMete Atamel氏が解説記事を公開していますので、詳細は 彼の記事 をご覧ください。
Agent Plugins#
Pluginsは要するに、Rules、MCP、Skills、Hooks、Agents、Sidecarsを1つの配布ユニットとしてまとめた「カスタマイズバンドル」です。私自身もPluginsの実験を続けてきましたが、残念ながら期待通りにスムーズには動作していません。例えば、プラグインに同梱したHooksが正しく実行されるように設定するのに非常に苦労したものの、結局うまく機能しませんでした。
また、プラグインの機能サポートはサーフェスによって非標準的です。例えば、SidecarsはAntigravity 2.0のプラグインでのみサポートされ、カスタムエージェントはAntigravity CLIでのみサポートされるといった具合です。
では、Pluginsは何に役立つのでしょうか？ 答えはMCPとSkillsです。偶然か必然か、業界全体も新しい Agent Plugins 標準によってこの方向に収束しつつあります。彼らの論理では、Hooks、Agents、Rules、LSPサーバーなどは依然としてクライアント依存が強いため、現時点では標準化の対象外とされています。
Goのエージェンティックツールキットを構築する#
エージェントハーネスとカスタマイズの全体像を把握したところで、Go開発用のツールキットを揃えていきましょう。必須のコミュニティツールと、AIネイティブな専門拡張機能の2つに分類して紹介します。
必須のコミュニティツール#
Goの標準ツールチェーンはエージェントにとって強固なベースラインを提供しますが、以下のコミュニティツールを導入することで、コード品質とリリース自動化をさらに向上させることができます。
golangci-lint: 数十種類の高速リンターを1回のパスで一括実行し、go vetが見逃す未処理エラー、型アサーションの不備、変数のシャドーイング、並行処理の落とし穴を捕捉します。goreleaser: バイナリを配布するプロジェクト向けに、.goreleaser.yamlからのクロスプラットフォームビルド、リリースパイプラインの管理、チェンジログ生成を自動化します。modernize/go fix: 最新のGoリリースに合わせてコードを解析し、手動のスライス/マップループやmin/maxヘルパーを現代的な組み込み関数へと機械的にアップグレードします。deadcode: プログラム全体の到達可能性解析（Reachability Analysis）を行い、パッケージ間の未使用関数や到達不能コードを特定します。seleneとtestquery（手前味噌ですが）: テストスイートの検証と改善のために私がメンテナンスしている2つのオープンソースツールです。seleneは、ASTに意図的な欠陥を注入してテストがバグを確実に検出できるかを検証するGo向けミューテーションテストツールです。testqueryは、Goのテスト結果やテストごとのカバレッジに対してSQLクエリを実行できるCLIです。ニッチではありますが、テストスイートの最適化に役立っています。
AIネイティブな専門ツール#
上記のツールは人間の開発者向けに作られたものですが、コーディングエージェントは標準のシェルコマンド経由でこれらを直接実行できます。続いて、AIネイティブなワークフローに特化したMCPやSkillsを見ていきましょう。
公式 gopls MCPサーバー#
従来のIDEにおいて、gopls は型チェック、参照検索、シンボル定義などのセマンティック認識（意味解析）をエディタに提供します。しかし、エージェントがヘッドレス環境やターミナル環境で動作する場合、通常はコードを生のテキストファイルとして扱います。
このギャップを埋めるため、Goチームは gopls にネイティブのMCPサポートを追加しました。MCPモードで gopls を実行すると、言語サーバーの型チェッカーとインデックスが実行可能なツールとしてモデルに直接公開されます。これにより、エージェントはコンパイラ自身のセマンティックモデルを利用してパッケージ階層を探索し、型シグネチャを検査できるようになります。
godoctor MCPサーバー#
gopls MCPサーバーに対する私の愚痴の1つは、それがLSP APIの上に設計されている点です。LSPはそもそもエージェントを想定して設計されたものではなく、人間のキーストロークに合わせたタイピング速度とインタラクティブ性のために作られました。一方、エージェントのワークフローはトランザクショナルです。そこで私は、AIネイティブなGo開発ツールを提供するために godoctor を開発しました。
現行バージョンの godoctor は以下の機能を提供します。
smart_edit: 自動go vet検証とタイポ補正機能を備えたAST認識型ファイルエディタ。編集によってコンパイルエラーや構文エラーが発生した場合、変更を自動的にロールバックし、周囲の識別子に基づいて「もしかしてこれですか？」という誘導プロンプト付きで修正案を提示します。smart_build: モジュール衛生管理（go mod tidy、modernize、goimports）、パッケージのビルド、カバレッジ付きテスト実行、golangci-lintによるリント検証を1回のパスで実行する自動検証パイプライン。smart_test:testqueryおよびseleneをサポートする、実践的なテストパイプライン。read_docs:go docベースのドキュメント検索機能。サンプルコードの表示に対応し、モジュール構成に依存しないフォールバックシステムを備えています。
プラットフォーム知識と自己改善#
godoctor や gopls がローカルコードの意味解析を担当する一方で、コーディングエージェントが外部サービスと連携する際には、リアルタイムなプラットフォーム知識やワークフローのプレイブックも必要になります。Go、GCP、Geminiを組み合わせて開発する上で不可欠なクラウドおよびAPIリソースは以下の通りです。
- 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）向けのスキルを閲覧できます。
さらに、独自のカスタム拡張機能で自分自身のワークフローを最適化するためのツールもあります。
- 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) などの高レベルエージェントフレームワークを探求します。それでは、次回お会いしましょう！
