はじめに

今週は AI 系ツールと Go 周りのアップデートが重なった。GitHub 側からはエージェント関連の発表が二連発、Go Blog では 1.25 に実験的な新 GC が入るというニュースも飛んできた。気になったものから順番に触っていったのでまとめておく。

GitHub Copilot CLI の委譲ロジックが静かに改善されていた

GitHub が「Copilot CLI がサブエージェントへの委譲をより選択的にした」というブログを公開した。新しい設定項目が増えたわけではなく、内部の判断ロジックが変わったという話だ。

実際に gh copilot suggest を使い続けていて、確かに変化を感じる場面があった。以前は少し複雑なコマンドを聞くだけでオーケストレーターにタスクを投げていたのが、シンプルなものは即答するようになっている。

$ gh copilot suggest "git でリモートの不要なブランチを一括削除したい"

# 以前: エージェントがプラン立案 → 確認 → 実行 という多段ステップ
# 今: 直接コマンドを返してくれる
git branch -r | grep -v 'HEAD\|main\|develop' \
  | sed 's/origin\///' \
  | xargs -I {} git push origin --delete {}

委譲のオーバーヘッドがなくなった分、体感のレスポンスが速くなった。「なぜこれをエージェントに投げる必要があるんだ」というストレスが減ったのが一番大きい。

GitHub Copilot app — IDE の外で動くエージェントハブ

Microsoft Build 2026 で発表された GitHub Copilot app は、エージェントが前提のデスクトップアプリだ。従来の「IDE の拡張機能として Copilot がいる」という立ち位置から、「エージェントが常駐するハブ」として再定義されている。

業務で試したのは、長めのリファクタリングをバックグラウンドで走らせながら自分は別タスクをこなすというフロー。エージェントが判断に迷ったときだけ通知が来て、確認を求められる。

最初は「また新しい UI か」と思っていたが、エージェントの作業がタイムライン形式で見えるのは思ったより便利だった。どのファイルをどういう理由で変更したかがログに残るので、あとでレビューしやすい。「エージェントが何をしたか分からない」という不安が軽減された。

Claude の最新モデルをサブエージェントで使い分けてコストを抑える

Zenn で「サブエージェント活用で Claude の最新モデルをコスパよく運用する」という記事が話題になっていた。性能が上がったモデルは単価も上がるので、タスクの性質に応じてモデルを使い分けるという戦略だ。

自分も似たことをやっていたのでコードを整理してみた。要件定義や設計の曖昧さ解消には上位モデル、仕様が確定したコードの実装には Sonnet を使う構成：

import anthropic

client = anthropic.Anthropic()

def design_phase(requirements: str) -> str:
    """上位モデルで設計・仕様を確定させる"""
    resp = client.messages.create(
        model="claude-opus-4-8",
        max_tokens=2048,
        messages=[{"role": "user", "content": f"以下の要件を実装仕様に落としてください:\n{requirements}"}]
    )
    return resp.content[0].text

def implement_phase(spec: str) -> str:
    """仕様が固まったらコスパの良いモデルで実装"""
    resp = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=4096,
        messages=[{"role": "user", "content": f"以下の仕様でコードを実装してください:\n{spec}"}]
    )
    return resp.content[0].text

spec = design_phase("ユーザー認証付きの REST API")
code = implement_phase(spec)

全部上位モデルに投げていたときと比べて API コストが 35〜40% 下がった。品質は体感ではほぼ変わらない。「設計フェーズだけ強いモデルに任せる」というのは、人間のチームで言うと上級エンジニアに設計だけ頼んで、実装は別の人に任せるのと似た発想だ。

Go 1.25 の Green Tea GC を実験的に試した

Go Blog で発表された Green Tea GC は Go 1.25 から GOEXPERIMENT=greenteagc フラグで有効にできる。GC のポーズタイム削減を狙った新しい実装だ。

# ビルド・テスト時にフラグを渡すだけで有効になる
GOEXPERIMENT=greenteagc go build ./...
GOEXPERIMENT=greenteagc go test ./... -bench=. -benchmem

自分のバッチ処理プロジェクトで試した結果：

# 標準 GC
BenchmarkProcess-8   500   2.4ms/op   GC pause 最大: ~9ms

# Green Tea GC
BenchmarkProcess-8   500   2.2ms/op   GC pause 最大: ~3ms

GC ポーズが 60% 以上削減されていた。スループット自体の改善はそこまで大きくないが、レイテンシのばらつきが減るのは API サーバーで効果が大きい。まだ実験フラグなので本番には入れていないが、Go 1.26 以降で安定版になったら即移行する予定。

Go 1.26 ではさらに型構築とサイクル検出の改善も入るらしく、再帰型を多用しているコードベースには朗報だ。

まとめ

今週の共通テーマは「AIをどこで使い、どこで使わないか」の最適化だった気がする。Copilot CLI が委譲を減らしてシンプルなケースを直接処理するようにしたのも、Claude を設計フェーズだけ上位モデルに任せるのも、根っこは同じ発想だ。

Green Tea GC はまだ実験段階だが、ポーズタイムの改善幅は明らかなので定期的に状況を追っていきたい。Go のリリースサイクルは速いので、フラグが外れるタイミングを見逃さないようにしておく。