google/adk-go を採用すべきか: Goでエージェントを組むための判断材料
An open-source, code-first Go toolkit for building, evaluating, and deploying sophisticated AI agents with flexibility and control.
ひと目でわかる
- これは何？
- Go版ADKは、エージェントのロジックをGoコードとして書き、テストし、バージョン管理するためのツールキットである。モジュール分割とデプロイの自由度が持ち味だが、バージョン系列が2本並走している点は導入前に確認したい。
- 誰に向いている？
- Goでエージェントを書き、そのロジックをコードとしてテストとバージョン管理の対象にしたいチームに向く。Python版ADKや他言語版と同じ設計を共有したい場合や、エージェント定義を設定ファイルで完結させたい場合は別の選択肢を検討したほうがよい。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Go です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
ADK Goが解こうとしている問題は、エージェント定義をどこに置くかである
エージェントの振る舞いをYAMLやDSLで記述するツールは多い。ADK Goは逆の立場を取る。READMEは「Code-First Development」を掲げ、エージェントのロジック、ツール、オーケストレーションをGoで直接書くと説明している。狙いは柔軟性、テスト容易性、バージョン管理にあるという。エージェントの分岐やツール呼び出しの条件を、既存のCI、レビュー、go test の流れに乗せたい開発者にとっては素直な設計だ。対象読者はREADMEの記述では「クラウドネイティブなエージェントアプリケーションを構築する開発者」で、Goの並行処理と性能を活かす用途を想定している。つまり、単発のプロンプト実行ではなく、複数のエージェントやツールを組み合わせた処理をサービスとして動かす場面が主戦場になる。
モジュール分割とマルチエージェント構成という設計の中心
READMEが挙げる機能のうち、構造に関わるのは「Modular Multi-Agent Systems」と「Rich Tool Ecosystem」の2つである。前者は特化した複数のエージェントを組み合わせてアプリケーションを組む考え方、後者は事前定義されたツール、自作関数、既存ツールの取り込みという3つの供給経路を示している。この2つが組み合わさると、1つの巨大なエージェントに全部を背負わせるのではなく、役割ごとに分けてツールを割り当てる形になる。ただしREADMEは具体的なインタフェース名やルーティングの仕組みまでは書いていない。実際のAPIはGo Package Doc（pkg.go.dev/google.golang.org/adk/v2）とadk-docs側のGo APIリファレンスに置かれている。設計の粒度を判断するには、READMEではなくexamplesディレクトリとAPIリファレンスを読む必要がある。
導入は go get 1行、ただしモジュールパスの版に注意
インストールはREADMEの記載どおり、go get google.golang.org/adk/v2 を実行してプロジェクトに追加する。ここで見落としやすいのが、このパスがv2系列を指しているという点だ。リポジトリのリリース一覧には v1.6.1（2026-09-07）、v2.3.0（2026-08-31）、v1.6.0（2026-08-12）が並んでおり、v1系とv2系が同時に更新されている。Go Modulesではメジャーバージョンがパスの一部になるため、v1系を使う場合はインポートパスが変わる。既存コードや社内ライブラリがv1系に依存している場合、READMEのコマンドをそのまま貼るとv2系が入る。まず自分の依存関係がどちらの系列を必要としているかを確認してから、go.mod のrequire行を決めるのが安全である。ライセンスはApache-2.0で、例外として internal/httprr に独自のLICENSEファイルがあるとREADMEは明記している。internal配下は外部からインポートできないパッケージだが、ライセンス表示を機械的に処理する仕組みを使っている場合はこの例外を拾っておきたい。
AIコーディングエージェントに文脈を渡す llms.txt という導線
READMEには、adk.dev/llms.txt がADKドキュメントの機械可読インデックス、adk.dev/llms-full.txt が同じドキュメントを1ファイルにまとめたものだと書かれている。どちらも adk-docs リポジトリから生成され、Go APIリファレンスとサンプルを含む。READMEが示すプロンプト例は「Plan and implement an agent that reviews customer issues and generates a report. Use the ADK Go framework, referring to https://adk.dev/llms-full.txt for sample code.」というもので、コーディングエージェントにこのURLを渡して文脈として使わせる使い方を想定している。ドキュメントを人手で要約してプロンプトに埋め込む運用と比べ、参照先が固定されるぶん再現性は高い。ただしこれはドキュメントの配布形式の話であり、生成されたコードが動くかどうかを保証するものではない。
モデル非依存とGemini最適化は同じ文の中で両立している
READMEは「While optimized for Gemini, ADK is model-agnostic, deployment-agnostic, and compatible with other frameworks.」と述べている。Gemini向けに最適化されている一方で、モデルにもデプロイ先にも縛られないという宣言だ。トピックには gemini、vertex-ai に加えて mcp と a2a が並んでおり、外部ツール連携とエージェント間連携のプロトコルが視野に入っていることがわかる。ただしモデル非依存という言葉が具体的にどのモデルをどのアダプタ経由で扱えるかを示すのはREADMEではない。マルチモデル構成を前提にするなら、対応状況はAPIリファレンスとexamplesで確認する作業が残る。ここはREADMEの記述だけでは判断できない部分だと明記しておく。
向かない場面: 設定ファイルで完結させたい場合と、他言語版との同一性を求める場合
ADK Goはコードでエージェントを定義する。これは利点であると同時に制約でもある。エージェントの振る舞いを非エンジニアが編集する運用や、定義を設定ファイルとして配布したい運用には向かない。Goのビルドとデプロイのサイクルが、プロンプト変更のたびに必要になる。もう1つの注意点は言語間の差だ。READMEはPython、Java、Kotlin、TypeScriptの各ADKとADK Webへのリンクを並べているが、これらが同一の機能セットを同一のタイミングで提供するとは書かれていない。リポジトリごとにリリースの刻みも版番号の付け方も違う。複数言語で同じエージェント構成を維持したいチームは、まず各言語版で使いたい機能の有無を突き合わせる必要がある。Go版を選ぶ理由が「Goで書きたいから」ではなく「他言語版と同じだから」であるなら、その前提は一度疑ったほうがよい。
比較対象としてのPython版ADKと、コードファーストの代償
同じリポジトリ群のPython版ADKは、READMEからリンクされている最も直接的な比較対象である。違いは言語だけではない。Python版はデータ分析やノートブック環境との親和性が高く、試行錯誤のループを短くできる。ADK Goはその逆で、コンパイルとテストという手順を挟む代わりに、並行処理と型の恩恵を受ける。READMEがGo版の利点として挙げるのも「Goの並行処理と性能」であり、対話的な探索ではなくサービスとしての運用を想定している。エージェントの挙動を何十回も書き換えながら固めていく段階ではPython版のほうが速い。逆に、複数のエージェントを並行して走らせ、ツール呼び出しの失敗を型で扱い、CIで回帰を検出したい段階ではGo版の構造が効いてくる。どちらが優れているかではなく、どの段階にいるかの問題である。
メンテナンスとアップグレードの実際の負担
リポジトリはアーカイブされておらず、最終pushは2026-09-09、直近のリリースは v1.6.1 と v2.3.0 である。活発に更新されているぶん、追従のコストは見込んでおく必要がある。特にv1系とv2系が並走している状況では、セキュリティ修正やバグ修正がどちらの系列に入るのかを追う必要がある。Go Modulesではメジャーバージョン間の移行にインポートパスの変更が伴うため、v1からv2への移行はgo.modとimport文の書き換えを意味する。READMEには移行ガイドへの言及がないので、この作業量は実際のコードベースで見積もるしかない。nightly.yml のワークフローが存在することはREADMEのバッジから読み取れるが、それが何を検証しているかはREADMEの範囲ではわからない。ライセンスはApache-2.0で、特許許諾と変更点の明示といった条項を含む標準的な内容だが、internal/httprr だけ別ライセンスである点は依存関係の棚卸しで引っかかりうる。法務判断はここでは扱わない。
編集部の結論
Goでエージェントを書き、そのロジックをコードとしてテストとバージョン管理の対象にしたいチームに向く。Python版ADKや他言語版と同じ設計を共有したい場合や、エージェント定義を設定ファイルで完結させたい場合は別の選択肢を検討したほうがよい。導入前に確認すべきは、go.mod に google.golang.org/adk/v2 を入れるのか v1 系列を選ぶのかという点と、その系列で自分のユースケースに必要なツールとモデル連携が揃っているかである。v1.6.1 と v2.3.0 が同じ時期にリリースされている以上、どちらの系列が自分の依存関係にとって安定なのかを実際のモジュールで確かめてから本採用を決めるのが順当だ。
コミュニティノート