Go 言語は、Claude Code のような AI エージェントが「書く→確かめる→直す」を回しやすい言語です。型のエラー・go vet・gofmt・go test が標準でそろい、失敗が機械的に読めるからです。一方で、学習後に出た新機能や新しい書き方には弱く、go fix などで補う必要があります。実行結果・CLAUDE.md の設定例・実践手順で解説します。
SNSでシェアして、他のエンジニアにも教えてあげましょう
Go 言語は、Claude Code のような AI エージェントにとって書きやすく、確かめやすい言語です。型の誤りはコンパイラが、怪しい書き方は go vet が、書式の揺れは gofmt が、動作の誤りは go test が、どれも標準のコマンドで機械的に教えてくれます。エージェントは「書く→確かめる→直す」のループを、人の手を借りずに回せます。
一方で苦手な点もあります。モデルの学習後に出た新機能や新しい書き方を知らず、古い書き方をしがちです。この記事では、筆者が 2026 年 10 月 5 日に実際に動かした go vet・go test・Claude Code の出力を根拠に、相性の良い点と悪い点、CLAUDE.md や hooks の Go 向け設定例、実践の手順をまとめます。
結論から言うと、Go 言語は AI エージェントと相性の良い言語です。ただし「新しい Go」には弱いので、道具で補う前提で使います。
Claude Code の公式ベストプラクティスは、最初の項目で「Claude に自分の作業を確かめる手段を与える」ことを挙げています1。テスト・ビルドの終了コード・リンターのように、合否が会話の中で読めるチェックがあれば、Claude は直してはまた確かめ、チェックが通るまで続けます1。Go は、この「確かめる手段」が言語の標準ツールとして最初からそろっている点が強みです。
| 観点 | Go が得意なこと | Go が苦手なこと |
|---|---|---|
| 書く | 書き方の選択肢が少なく、書式は gofmt で 1 つに決まる | 学習後に出た新機能（Go 1.27 のジェネリックメソッドなど）を知らない |
| 確かめる | コンパイラ・go vet・go test が標準。出力が「ファイル:行:列: 理由」の形 | 動いても古い書き方のことがある |
| 直す | エラーの場所と理由がはっきりしていて、直す場所を絞りやすい | 大きなリファクタリングは他言語と同じく難しい |
| 配る | 単一バイナリで、依存が少ない | — |
理由は、静的型とコンパイラ、gofmt、標準のテストと静的解析、明示的なエラー処理、依存の少なさと互換性の 5 つです。どれも「AI が自分の誤りに気づける」ことにつながります。
Go のコンパイラは、使っていない import や変数もエラーにします。AI がよく残す「書きかけの変数」や「不要な import」が、その場で止まります。筆者の環境で、わざと誤りを入れたコードを go build した結果です。
$ go build ./...
# example.com/greet
./greet.go:5:2: "os" imported and not used
./greet.go:9:2: declared and not used: count
ファイル名・行・列・理由が 1 行にまとまっています。エージェントはこの出力を読むだけで、どこを直せばよいか分かります。
Go の書式は gofmt が決めます。設定項目がほぼ無く、誰が書いても同じ見た目になります。インデントや空白の好みで AI と人が揉めることがなく、差分は中身の変更だけになります。
# gofmt -d add.go の出力（一部）
-func Add(a,b int)int{return a+b}
+
+func Add(a, b int) int { return a + b }
go vet は、Printf の書式と引数の型が合わないなど、コンパイルは通るが怪しい書き方を見つけます。さらに go test は、テストの前に go vet の確度の高いチェック（printf など）を自動で実行し、問題があればテストを走らせません2。
$ go test ./...
# example.com/greet
# [example.com/greet]
./greet.go:6:29: fmt.Sprintf format %d has arg name of wrong type string
FAIL example.com/greet [build failed]
つまり CLAUDE.md に「go test ./ を通してから終える」と 1 行書くだけで、テストと主要な静的解析の両方が効きます。テストの書き方も標準の testing パッケージ 1 つなので、フレームワーク選びで AI が迷いません。
Go では、失敗しうる関数は error を戻り値で返し、呼び出し側が if err != nil で扱います。例外のように見えない経路で処理が飛ばないので、AI が書いたコードを人がレビューするとき、失敗時の流れを上から順に読めます。冗長に見える書き方ですが、生成とレビューの両方で「どこで失敗が扱われているか」が明確になります。
HTTP サーバー・JSON・テストなど、多くの機能が標準ライブラリにあります。AI が知らない外部ライブラリの API を推測で書く場面が減ります。また Go には「Go 1 の仕様で書いたプログラムは、仕様が続く限りそのまま動く」という互換性の約束があり、古い知識で書かれたコードでも、動かなくなることは起きにくい言語です。
ビルド結果が単一のバイナリになるのも利点です。エージェントが作ったツールを、実行環境をそろえずにそのまま配れます。
実際に、上の %d の誤りを入れたコードを Claude Code に直させました。CLAUDE.md には「go test ./ と go vet ./ を通してから終える」とだけ書き、ヘッドレス実行（claude -p）で頼んでいます。
claude -p "go test が落ちています。原因を調べて直してください" \
--allowedTools "Read" "Edit" "Bash(go test *)" "Bash(go vet *)" "Bash(gofmt *)" \
--model sonnet --output-format stream-json --verbose
stream-json の記録では、Claude Code は次の順に動きました。
go test ./ を実行して失敗を読むgreet.go と greet_test.go を読む%d を %s に直すgo test ./ で確かめる最後に「go vet のチェックが go test の中でも走るため、テストが実行される前にビルド失敗になっていた」と、原因まで正しく説明しています。この例は 6 ターン・約 17 秒で終わり、Claude Code が表示した費用の目安は約 0.12 ドルでした（小さな例 1 回の値で、規模や条件で変わります）。
Go と AI エージェントの組み合わせには、はっきりした弱点もあります。いちばん大きいのは、学習データに多い古い書き方をなぞりやすいことです。
Go チームは 2026 年 2 月の公式ブログで、2024 年 12 月ごろ、LLM のコーディング支援ツールが、より新しく良い書き方があっても学習に使われた大量の Go コードに似た書き方をする傾向に気づいたと書いています3。新しい機能を使うよう指示しても、モデルがその機能の存在を否定することさえあったそうです3。
時期のずれも見ておく必要があります。2026 年 10 月時点の Claude Opus 5.5・Sonnet 5.5 の信頼できる知識の期限は 2026 年 6 月です4。一方、Go 1.27 は 2026 年 8 月 19 日に出ており、ジェネリックメソッド、encoding/、uuid パッケージなどが入りました5。これらは、モデルが学習で十分に見ていない可能性が高い機能です。
公開されたベンチマークでも、Go が AI にとって特に簡単という結果は出ていません。SWE-bench Multilingual（実在のリポジトリの課題 300 件）で Claude 3.7 Sonnet と SWE-agent を評価した結果では、Go の解決率は 30.95% で、7 言語の中では下から 2 番目でした6。2025 年の古いモデルでの結果なので今のモデルにそのまま当てはまりませんが、「Go なら AI が必ずうまく書ける」とは言えません。
| 言語 | 解決率（%） |
|---|---|
| Rust | 58.14 |
| Java | 53.49 |
| PHP | 48.84 |
| Ruby | 43.18 |
| JavaScript/TypeScript | 34.88 |
| Go | 30.95 |
| C/C++ | 28.57 |
古い書き方への対策として、Go チームは go fix を作り直しました。Go 1.26 で go fix は解析フレームワークの上に書き直され、数十の「モダナイザー」（新しい書き方に直す修正）が入っています3。筆者の環境（Go 1.26.2）で、AI が書きがちな古い書き方のコードに go fix -diff を実行した結果の一部です。
- for _, x := range xs {
- if x == target {
- return true
- }
- }
- return false
+ return slices.Contains(xs, target)
-func Repeat(n int) []interface{} {
- var out []interface{}
- for i := 0; i < n; i++ {
+func Repeat(n int) []any {
+ var out []any
+ for i := range n {
- i := strings.Index(s, "=")
+ before, _, ok := strings.Cut(s, "=")
ループは slices.Contains に、interface{} は any に、3 つの式の for 文は range n に、strings.Index での切り出しは strings.Cut に直りました。AI に書かせたあと go fix ./ をかけ、差分を確かめてからコミットする流れにすると、古い書き方が残りにくくなります。
もう 1 つの対策は、Go の言語サーバー gopls を Claude Code につなぐことです。gopls には実験的な MCP サーバーがあり、claude mcp add gopls -- gopls mcp で追加できます7。Go チームはこれを、AI エージェントに診断結果を渡す「ガードレール」と位置づけています3。
Go のプロジェクトでは、CLAUDE.md は短くてかまいません。公式ドキュメントは、CLAUDE.md に「Claude が推測できないコマンド」や「既定と違うコードスタイル」を書き、「Claude がすでに知っている言語の標準的な慣習」は書かないよう勧めています1。gofmt の書式や if err != nil の書き方は書く必要がありません。
# CLAUDE.md
## コマンド
- テスト: `go test ./...`（go vet の主要チェックも走る）
- 1 パッケージだけ: `go test ./internal/order/ -run TestCancel`
- 静的解析: `go vet ./...`
- 書き方の更新: `go fix -diff ./...` で差分を確かめてから `go fix ./...`
## このリポジトリの約束
- Go 1.27。新しい標準ライブラリ（slices・maps・encoding/json/v2）を優先する
- エラーは `fmt.Errorf("...: %w", err)` で包んで返す。panic はしない
- DB へのアクセスは internal/store 以外に書かない
- 変更したら必ず `go test ./...` と `go vet ./...` を通してから終える
「Go 1.27 を使う」と書くのは、モデルの知識より新しいバージョンであることを伝えるためです。新機能を使ってほしいときは、go doc encoding/ のように手元のドキュメントを読ませる指示も有効です。
書式は指示ではなく hooks（フック）で強制します。公式ドキュメントでも、CLAUDE.md の指示は助言にとどまり、hooks は必ず実行される決定的な仕組みだと説明しています1。次の設定を .claude/ に置くと、Claude が Edit か Write で .go ファイルを変えるたびに gofmt がかかります8。
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "f=$(jq -r '.tool_input.file_path // empty'); case \"$f\" in *.go) gofmt -w \"$f\" ;; esac"
}
]
}
]
},
"permissions": {
"allow": [
"Bash(go test *)",
"Bash(go vet *)",
"Bash(go build *)",
"Bash(gofmt *)"
]
}
}
hook のコマンドは、{"tool_input":{"file_path":"…/ を標準入力に渡して試し、崩した書式の .go ファイルが整形されること、.go 以外では何もしないことを筆者の環境で確かめています。permissions.allow は、テストやビルドを毎回の確認なしで実行させる設定です。より詳しい書き方は CLAUDE.md の書き方（AGENTS.md との違い） と Claude Code の hooks 入門 を参照してください。
ここまでの設定を使って、Claude Code に Go を書かせる手順をまとめます。
/ で下書きを作り、上の例のようにコマンドと独自の約束だけに絞るgo test・go vet の許可を .claude/ に入れるCancel が二重に呼ばれたらエラーを返す。まず失敗するテーブル駆動テストを書き、それから実装して go test ./ を通して」のように、合否の基準を渡すgo fix -diff ./ を実行させ、差分を読んでから適用するgopls-lsp）を入れる3 の「先にテスト」は、Go と特に相性の良い進め方です。標準の testing だけでテーブル駆動テストが書けるので、仕様をテストの表として先に固め、実装を AI に任せられます。詳しくは Claude Code で Go のテスト駆動開発 で解説しています。
Go は、AI エージェントを「使う側」だけでなく「作る側」の言語としても使われています。Go チームは 2025 年 11 月の公式ブログで、MCP の公式 Go SDK を Anthropic と共同でリリースし、Google の ADK Go もその上に作られていると紹介しました9。
| リポジトリ | 内容 | 最新版（2026-10-05 時点） |
|---|---|---|
| modelcontextprotocol/go-sdk | MCP の公式 Go SDK | v1.8.0 |
| google/adk-go | Google の Agent Development Kit の Go 版 | v2.5.0 |
| anthropics/anthropic-sdk-go | Claude API の公式 Go SDK | v1.78.0 |
| github/github-mcp-server | GitHub 公式の MCP サーバー（Go 製） | — |
| charmbracelet/crush | ターミナルで動くコーディングエージェント（Go 製） | — |
| cloudwego/eino | LLM アプリの開発フレームワーク | — |
| リポジトリ | スター数（個） |
|---|---|
| github/github-mcp-server | 33,377 |
| charmbracelet/crush | 28,492 |
| cloudwego/eino | 13,240 |
| google/adk-go | 8,847 |
| modelcontextprotocol/go-sdk | 5,185 |
| anthropics/anthropic-sdk-go | 1,210 |
Go の開発者自身も AI ツールをよく使っています。Go チームの 2025 年開発者調査では、回答者の 53% が AI の開発ツールを毎日使っていました10。ただし、いちばんの不満は「動かないコードを生成する」（53%）で10、確かめる仕組みの大切さが数字にも表れています。
| 頻度 | 割合（%） |
|---|---|
| 1 日に何度も | 32 |
| 1 日に数回 | 21 |
| 週に数回 | 17 |
| 月に数回 | 7 |
| 1〜2 回だけ | 5 |
| ほぼ使っていない | 17 |
Go で自分のエージェントやツールを作る方法は、Go で AI エージェントを自作する：anthropic-sdk-go 入門 と Go で MCP サーバーを作る：公式 Go SDK 入門 で手順を紹介しています。
go test は go vet の主要チェックも兼ねるので、CLAUDE.md に「go test ./ を通して終える」と書くだけで検証が効くgo fix と gopls、CLAUDE.md のバージョン指定で補うまずは手元の Go のリポジトリに、10 行ほどの CLAUDE.md と gofmt の hook を入れ、小さな修正を 1 つ Claude Code に任せてみてください。
一概には言えません。Go は検証の道具が標準でそろっている点で有利ですが、公開されたベンチマークでは Go の解決率が他の言語より高いという結果は出ていません6。既存のコードの言語で使うのが基本で、新しく作るツールなら、検証のしやすさと配布の楽さで Go を選ぶ理由は十分にあります。
2026 年 10 月時点のモデルの知識の期限（2026 年 6 月）より後に出た機能なので45、指示しないと使わないことが多いと考えておくのが安全です。CLAUDE.md に Go のバージョンを書き、go doc で手元のドキュメントを読ませると、新しい API を正しく使わせやすくなります。
書かないほうがよいです。公式ドキュメントは、Claude がすでに知っている言語の標準的な慣習は書かず、推測できないコマンドや独自の約束だけを書くよう勧めています1。長すぎる CLAUDE.md は大事な指示が埋もれる原因になります。
hooks をおすすめします。CLAUDE.md の指示は守られないことがありますが、hooks は決められたタイミングで必ず実行されます1。PostToolUse の Edit|Write に gofmt を設定すれば、書式の崩れが残りません8。
Claude を自分のプログラムから呼ぶなら anthropic-sdk-go、Claude Code にツールを足すなら MCP の公式 Go SDK、Google のモデルや複数エージェントの構成を使うなら ADK Go が出発点になります。どれも公式のリポジトリで、2026 年 10 月時点で更新が続いています。
Best practices for Claude Code — Anthropic, 公開日不明（2026-10-05 参照） ↩ ↩2 ↩3 ↩4 ↩5 ↩6
cmd/go: Test packages — The Go Project, 公開日不明（2026-10-05 参照） ↩
Using go fix to modernize Go code — The Go Blog（Alan Donovan）, 2026-02-17（2026-10-05 参照） ↩ ↩2 ↩3 ↩4
Models overview — Anthropic, 公開日不明（2026-10-05 参照） ↩ ↩2
Go 1.27 is released — The Go Blog（Nicholas Husin）, 2026-08-19（2026-10-05 参照） ↩ ↩2
SWE-bench Multilingual — SWE-bench（Khandpur ほか）, 公開日不明（2026-10-05 参照） ↩ ↩2
Gopls: Model Context Protocol support — The Go Project, 公開日不明（2026-10-05 参照） ↩
Automate actions with hooks — Anthropic, 公開日不明（2026-10-05 参照） ↩ ↩2
Go's Sweet 16 — The Go Blog（Austin Clements）, 2025-11-14（2026-10-05 参照） ↩
Results from the 2025 Go Developer Survey — The Go Blog（Todd Kulesza）, 2026-01-21（2026-10-05 参照） ↩ ↩2