GitHub、ClaudeとCodex agentでタスクごとにモデルを切り替える
Original: Model selection for Claude and Codex agents on github.com View original →
GitHubは third-party coding agent を、単一モデルの商品から調整可能な workflow に変え始めた。4月14日の changelog によれば、github.com 上で Claude と Codex の coding agent を使う際、task の開始時点で使うモデルを選べる。小さな UI 変更に見えるが、coding agent は model choice で挙動が大きく変わる。latency、reasoning depth、cost、patch quality のどれを優先するかは、task の種類によってまるで違うからだ。
実際、選べる範囲はかなり広い。Claude coding agent では Claude Sonnet 4.6、Claude Opus 4.6、Claude Sonnet 4.5、Claude Opus 4.5 が使える。Codex 側では GPT-5.2-Codex、GPT-5.3-Codex、GPT-5.4 を選択できる。つまり GitHub は Anthropic と OpenAI をまたぐ 7 モデルの surface を task 起点で見せるようになった。これは agent tab を、特定 vendor の backend を隠しただけの薄い wrapper から、実質的な routing layer へ近づける変更でもある。
この更新が効いてくるのは、coding agent の評価軸が benchmark の強さだけではなく、運用適合性へ移っているからだ。しつこい infrastructure bug を追う team は、遅くても深く考えるモデルを選びたいかもしれない。逆に反復的な pull request 整理や小さな修正では、速く安い option の方が価値を出す。GitHub が model choice を task kickoff に置いたのは、開発者が実際に触れているのは agent 単体ではなく、speed、depth、price の trade-off の束だと認めた形だ。
とはいえ自由度は完全ではない。利用権は既存の Copilot subscription に含まれるが、Copilot Business と Enterprise では Anthropic Claude または OpenAI Codex の policy を administrator が有効にする必要がある。さらに repository owner か organization 側でも Settings > Copilot > Cloud agent から agent を有効化しなければならない。柔軟性は広がるが、managed な guardrail の内側で開く設計だ。
もっと大きな意味では、github.com が coding surface であると同時に model marketplace interface になり始めたと言える。task 開始時に複数の Anthropic と OpenAI モデルを選べるようになると、team が比較する対象は agent 名だけではなくなる。routing の賢さ、pricing、governance、新モデルの追随速度まで見られるようになる。GitHubは、coding agent 競争が一つのモデルですべて解決するという見せ方ではなく、開発者に speed と depth の切り替えレバーをどれだけ渡せるかで決まると読んでいるように見える。
Related Articles
GitHubは2026年2月26日、Claude by AnthropicとOpenAI CodexをCopilot BusinessおよびCopilot Pro向けのcoding agentとして提供開始すると発表した。github.com、GitHub Mobile、VS Codeで同じcontextを共有でき、追加subscriptionなしでpublic preview中はsessionごとにone premium requestを消費する。
GitHub CopilotでOpus 4.6 fastが2026年6月29日に終了する。対象はCopilot Chat、inline edits、ask mode、agent mode、code completionsで、移行先はOpus 4.8 fastとされている。
GitHubはCopilot agentic harnessを5種類のtask suiteでmodel標準harnessと比較した。同じmodelとtask条件で、解決率は同等水準、token使用量は多くの構成で少ないという結果だ。