GitHub Agent HQ(エージェントHQ)は、GitHub Copilotに加えてAnthropic Claude・OpenAI Codex・Google Julesといった外部ベンダーのコーディングエージェントを、ひとつのGitHubプラットフォーム上で割り当て・並列実行・比較できるようにする中枢機能だ。2025年10月のGitHub Universeで発表され、2026年2月にClaudeとCodexがパブリックプレビューに入った。
本記事は、GitHub公式ブログとChangelogという一次ソースを軸に、Agent HQの位置づけ・Mission Control・主要機能・料金・エンタープライズ統制までを整理する。Copilot単体との混同を避け、導入判断の基準値を先に持てる形でまとめる。
- Agent HQは「複数エージェントを束ねる器」。Copilot本体とは別レイヤーで、Claude・Codex・Julesを同じGitHub上で並列運用できる。
- 中核はMission Control。GitHub.com・VS Code・Mobile・CLIを横断し、1つのIssueを複数エージェントに割り当てて結果を比較・マージできる。
- 2026年2月4日にClaudeとCodexがパブリックプレビュー入り。対象はCopilot Pro+とEnterpriseで、1セッション=プレミアムリクエスト1回。
- AGENTS.mdでベンダー横断の共通ルールを配り、Control Planeで監査・ポリシー強制・アクセス管理を行う。
- CursorやClaude Codeとは競合ではなく補完関係。クラウド側オーケストレーションはAgent HQ、エディタ内編集は手元ツール、と役割分担する。
30秒で理解する
まず全体像を箇条書きで押さえる。各項目は後続のH2で一次ソースとともに展開する。
・Agent HQは複数ベンダーのコーディングエージェントをGitHub上に統合する「オープンエコシステム」構想で、2025年10月のGitHub Universeで発表された
・対応エージェントはAnthropic Claude・OpenAI Codex・Google Jules・Cognition・xAIで、有料Copilotサブスクリプションを通じて順次提供される
・中核機能Mission Controlは、GitHub.com・VS Code・Mobile・CLIを横断する司令塔で、複数エージェントへの並列割り当てと進捗追跡を担う
・2026年2月4日にClaudeとCodexがパブリックプレビュー入り。対象はCopilot Pro+とEnterprise、各セッションがプレミアムリクエストを1回消費する
・AGENTS.mdによる共通ルール配布、コードレビューエージェント、GitHub MCP Registry、Control Planeによる統制が周辺機能として揃う
AIエージェントそのものの仕組み(計画→ツール実行→評価のループ)や主要フレームワークの全体像は、ピラー記事 AIエージェントとは?仕組み・種類・代表的OSSフレームワークを初心者向けに解説【2026年版】 に整理してある。本記事はその応用として「GitHubがエージェントをどう束ねるか」を深掘りする位置づけだ。
GitHub Agent HQ とは
GitHub Agent HQは、GitHubを「あらゆるエージェントが集う単一プラットフォーム」に変えるための構想であり機能群だ。発表時のキャッチコピーは “Any agent, any way you work”(どのエージェントでも、あなたのやり方で)で、GitHub公式は「エージェントは後付けで貼り付けるものではなく、すでに自分が働いている流れの中で動くべきだ」と位置づけた。
ここで重要なのは、Agent HQがCopilotの別売り後継製品ではないという点だ。Copilotはコード補完・Chat・エージェント実行を提供する製品本体で、Agent HQはそのCopilotに外部ベンダーのエージェントを接続し、GitHub上で横断管理する「上位レイヤー」にあたる。CopilotとIssue、Pull Request、Coding Agentの関係を一段俯瞰したのがAgent HQだと考えるとわかりやすい。
発表のタイムラインを整理しておく。2025年10月28日のGitHub UniverseでAgent HQ構想が発表され、その後数か月かけて外部エージェントが順次GitHubに統合される計画が示された。そして2026年2月4日、AnthropicのClaudeとOpenAIのCodexがGitHub上でパブリックプレビューとして利用可能になった。これがAgent HQが「構想」から「実際に触れる機能」へ移った節目だ。
Copilot=エージェント本体、Agent HQ=複数エージェントを束ねる司令塔。前者は「賢く書く道具」、後者は「誰に何を任せ、結果をどう裁くかを管理する場」。この二段構えを混同しないことが、料金・機能の理解の出発点になる。
Copilotの大型アップデートや料金体系そのものの基礎は、別記事 GitHub Copilotの使い方|導入・基本操作・Agent Mode・料金体系を2026年最新版で解説 で扱っている。本記事はその上に乗る「複数エージェント統合」の層に焦点を当てる。
なぜ Agent HQ が必要だったか
2025年から2026年にかけて、開発現場では複数のコーディングエージェントが同時に使われるようになった。Copilotで補完しつつ、難所はClaude Codeに投げ、別タスクはCursorやClineで回す——という運用は珍しくない。しかしこの「マルチエージェント並走」は、放置すると深刻な散らかりを生む。
具体的には次のような分断が起きていた。
・窓口の分散:エージェントごとに別UI・別ターミナル・別ログで、どのタスクを誰に任せたか俯瞰できない
・ルールの重複:ツールごとに指示ファイルやガードレールを別管理する必要があり、規約が食い違う
・成果物の合流コスト:複数エージェントが作ったブランチやPRを、人手で突き合わせてマージする手間が増える
・統制の空白:どのエージェントがどのリポジトリで何をしたか、組織として監査・制御する仕組みが追いつかない
Agent HQはこの4つの分断を、GitHubという既存の作業基盤の上で解消しようとする。エージェントを新しい別の場所に置くのではなく、Issue・PR・CIといった開発者がすでに使っている導線にエージェントを溶け込ませる。これが「後付けで貼り付けない」という設計思想の実体だ。なお、Copilot本体がネイティブアプリ化してgit worktreeで複数エージェントを並列実行する流れは GitHub Copilotがネイティブアプリ化、デフォルトモデルもPolarisへ——Build 2026の主戦場 で扱っており、Agent HQはその「並列実行」をGitHubのクラウド側に引き上げた延長線上にある。
個々のエージェントは十分に賢い。問題は、それらを横断して割り当て・追跡・統制する層が欠けていたことだ。Agent HQが狙うのは新しいエージェントを増やすことではなく、すでにある複数のエージェントを1つの作業面に集約することにある。
アーキテクチャと主要機能
Agent HQの全体構成を俯瞰すると、GitHubという基盤の上にMission Controlという司令塔が乗り、その下に複数ベンダーのエージェントがぶら下がる多層構造になっている。下図はその関係を整理したものだ。
主要なコンポーネントを個別に見ていく。
・Mission Control(司令塔):GitHub.com・VS Code・Mobile・CLIを横断する統一コマンドセンター。複数エージェントへのタスク並列割り当て、進捗追跡、結果比較を1か所で行う
・Coding Agents(実働層):Copilot Coding Agentに加え、Claude・Codex・Jules・Cognition・xAIなど外部エージェントを接続。IssueやPRに割り当てて自律的に作業させる
・AGENTS.md(共通ルール):リポジトリにコミットするルールファイル。コーディング規約やガードレールをベンダー横断で各エージェントに配る
・Code Review Agent(レビュー統合):人間レビューの前段で一次レビューを自動実行し、指摘をPRに付ける
・GitHub MCP Registry:VS Code上でStripeやFigmaなどのMCPサーバをワンクリックで発見・導入できる
・Control Plane(統制層):セキュリティポリシー適用・監査ログ・エージェントのアクセス管理を担うエンタープライズ統制レイヤー
タスクがどう流れるかを、IssueからマージまでのフローでMermaid化すると次のようになる。1つのIssueを複数エージェントに割り当て、それぞれのDraft PRを比較して最良を選ぶ「コンペ方式」が中核だ。
並列割り当て"] MC --> A1["@copilot
Draft PR A"] MC --> A2["@claude
Draft PR B"] MC --> A3["@codex
Draft PR C"] A1 --> CR["Code Review Agent
一次レビュー"] A2 --> CR A3 --> CR CR --> CMP["結果を比較
diffを並べる"] CMP --> H["人間レビュー → 最良をマージ"] H --> CP["Control Plane
監査ログ・ポリシー強制"]
VS Code側ではセッションが3種類に分かれる。用途で使い分ける設計だ。
・Local:対話的で高速な支援。目の前の作業を手伝う
・Cloud:GitHubがホストする自律タスク。手元のマシンを占有しない
・Background:非同期のローカルタスク。現状はCopilot限定
主要ユースケースとコード例
Agent HQの使いどころを、3つの代表シナリオで具体化する。いずれもIssue・PR・コメントという既存のGitHub操作の延長で完結する点がポイントだ。
Issue → 自動着手
IssueのAssigneesドロップダウンからエージェントを割り当てると、そのエージェントが内容を読み、作業ブランチを切ってDraft PRを起こすところまで自律的に進める。コメント欄でのメンションでも同じことができる。
# Issue本文の末尾、またはコメントで割り当て
@claude このバグを再現するテストを追加してから修正してください。
変更は Draft PR で提出してください。
PR レビュー × エージェント
既存のPRに対して、コードレビューエージェントを一次レビューとして走らせる。人間がレビューに入る前に、明白な指摘を潰しておく使い方だ。複数エージェントに同じPRをレビューさせ、観点の違いを突き合わせることもできる。
# Pull Request のコメントでレビューを依頼
@copilot このPRをセキュリティ観点でレビューしてください。
@codex 同じPRをパフォーマンス観点でレビューしてください。
レビューエージェントの比較や使い分けの基礎は、別記事 AIコードレビューツール比較2026|CodeRabbit・Greptile・Qodo・Bito・Sourcery・Codacyを使い分け解説 で扱っている。Agent HQはそれらをGitHubネイティブの導線に統合する位置づけだ。
並列タスク実行
同じIssueを複数エージェントに同時に割り当て、生成されたDraft PRを並べて比較し、最良の1本をマージする。導入の流れは次のとおりだ。
Step 1: リポジトリでAgent HQを有効化する
対象リポジトリでCopilot coding agentを有効にし、利用したいエージェント(Claude / Codex)をプレビュー対象として有効化する。VS Codeを使う場合は1.109以降に更新しておく。
# VS Code のバージョン確認(1.109以降が必要)
code --version
Step 2: 共通ルールをAGENTS.mdに置く
リポジトリ直下にAGENTS.mdを作り、全エージェント共通の規約・禁止操作・レビュー観点を書く。これでベンダーをまたいで前提が揃う。
# AGENTS.md(抜粋)
- 変更は必ず Draft PR で提出する
- 既存のテストを壊さない。壊れたら原因を要約する
- 破壊的なマイグレーションは提案のみで実行しない
Step 3: Mission Controlで割り当てて比較する
IssueのAssigneesまたはコメントで複数エージェントに割り当て、Mission Controlで進捗を追う。出てきたDraft PRのdiffを並べ、最良の1本を人間がレビューしてマージする。
既存ツール(Cursor / Cline / Claude Code)との関係
Agent HQが登場したことで、「CursorやClaude Codeはもう要らないのか」という疑問が出やすい。結論から言えば、両者は競合というより補完関係にある。
軸を整理すると、Agent HQの強みはGitHub・Issue・PR・CIに密結合したクラウド側のオーケストレーションだ。リポジトリ横断のタスクを複数エージェントに割り当て、結果を比較してマージする流れに向く。一方でCursorやClineはエディタ内の対話的なコーディング体験に強く、目の前のファイルを賢く編集する作業に向く。Claude Codeはターミナル中心で、任意のモデルやスキルを細かく制御したいケースに強い。
リポジトリ横断・並列実行・PR比較はAgent HQ、手元のファイル編集や対話的な試行錯誤は手元のIDE拡張やターミナルツール。Agent HQはベンダー中立を掲げる以上、特定ツールを排除する設計ではない。強みの違う層として併用するのが現実解だ。
外部エージェントの接続は、GitHub上のAssigneesやメンションを通じて行う。CursorやClineを「Agent HQの中で動かす」のではなく、GitHubに集約された作業(Issue・PR)をAgent HQ側のエージェントに任せ、ローカルの細かな編集は手元ツールに任せる、という住み分けになる。信頼境界(どこまでクラウドに送るか)を意識して使い分けたい。
料金と利用条件
Agent HQは独立した別売り製品ではなく、有料Copilotサブスクリプションの上で動く。2026年6月時点の料金体系を整理する。
| プラン | 月額 | プレミアムリクエスト | 外部エージェント(Claude/Codex) |
|---|---|---|---|
| Copilot Pro | $10 | 300 | 段階的に拡大予定 |
| Copilot Pro+ | $21 | 1,500 | パブリックプレビューで利用可 |
| Copilot Business | $19/ユーザー | 組織管理に準拠 | 段階的に拡大予定 |
| Copilot Enterprise | $39/ユーザー | 組織管理に準拠 | パブリックプレビューで利用可 |
数値の出どころと条件を明示しておく。ClaudeとCodexのパブリックプレビューは、2026年2月4日時点でCopilot Pro+とCopilot Enterpriseの契約者が対象だ。各コーディングエージェントのセッションは、プレビュー中はプレミアムリクエストを1回消費する。ProやBusinessへの外部エージェント展開は「今後拡大」とされており、対象プランと消費単価はプレビュー中に変わり得る。
プレミアムリクエストの消費単価や対象プランは、パブリックプレビューの段階では変更されやすい。組織導入の予算を組む際は、本記事の表を出発点としつつ、GitHub公式の料金ページとChangelogで最新の数値を確認すること。
エンタープライズ用途
組織でAgent HQを使う場合、統制(ガバナンス)の仕組みが鍵になる。複数ベンダーのエージェントが社内リポジトリで自律的に動く以上、「誰が・何に・どこまでアクセスして・何をしたか」を追跡・制御できなければ導入は難しい。
Agent HQはこの要求にControl Planeで応える。Control Planeはエンタープライズ向けの統制層で、セキュリティポリシーの適用・監査ログ・エージェントのアクセス管理を提供する。これに加えて次の機能が組み合わさる。
・ブランチ制御:エージェントが触れられるブランチや操作の範囲を組織ポリシーで縛る
・GitHub Code Quality:組織横断でコードの保守性を可視化・統制し、レポーティングする
・Copilot Metrics Dashboard:組織全体の利用状況とインパクトを把握する(パブリックプレビュー)
これらにより、エージェントの自律性と組織の統制を両立させる設計になっている。とはいえSSOの構成・データ送信境界(クラウドサンドボックスに何が送られるか)・モデル選定を組織で固定できるかといった契約条件は、Enterpriseプランの公式ドキュメントとアカウントチームに直接確認するのが安全だ。
導入のステップとしては、いきなり全社展開するのではなく、影響範囲の小さいリポジトリでパブリックプレビューを試し、Control Planeのポリシーと監査ログの見え方を確認してから広げるのが定石だ。エージェントが生成したPRのマージ権限を最初は人間に限定し、レビュー精度が安定してから自律度を上げていく。Copilot Metrics Dashboardで「どのエージェントがどれだけ使われ、どの程度PRに反映されたか」を定点観測すれば、プレミアムリクエストの消費とアウトプットの費用対効果を組織として判断できる。プレビュー段階での全面投入は、仕様変更のたびに運用が揺れるため避けたい。
Microsoft Agent Framework / Vercel AI SDK 6 / Microsoft IQ との位置づけ
Agent HQを「クラウドベンダー各社のエージェントOS戦略」という大きな地図の上に置くと、立ち位置がはっきりする。2025〜2026年は、各社が「エージェントをどこに集約し、どう統制するか」を競った時期だった。
各陣営のアプローチを並べて整理する。
| 取り組み | 主体 | レイヤー | 焦点 |
|---|---|---|---|
| Agent HQ | GitHub / Microsoft | 開発プラットフォーム | Issue・PR起点でエージェントを束ね、コードを生む |
| Microsoft Agent Framework | Microsoft | エージェント実行基盤 | 業務アプリ向けエージェントの構築・実行 |
| Vercel AI SDK 6 | Vercel | アプリ開発SDK | フロント/バックでLLM・エージェントを組み込む |
| Microsoft IQ | Microsoft | 知識・データ統合 | Work/Web/Foundry/FabricをMCP・RAGで束ねる |
ざっくり言えば、Agent HQは「ソフトウェア開発という作業の中枢」に位置する。Microsoft Agent FrameworkやVercel AI SDK 6は「エージェントを組み込んだアプリを作る側」のツールで、Agent HQは「そのアプリを作る開発作業そのものをエージェントに任せる場」だ。レイヤーが違うため競合というより役割分担に近い。
クラウドの知識・データ統合の文脈は、別記事 Microsoft IQの4層を読み解く——Work/Web/Foundry/FabricとMCP・RAGの関係 で扱っている。Agent HQが「開発作業の統合」なら、Microsoft IQは「企業知識の統合」で、どちらもMicrosoft陣営のエージェント戦略の別の面を成している。
よくある落とし穴
最後に、Agent HQをめぐって混同しやすい点を潰しておく。境界が曖昧だと判断を誤る。
・Copilot単体との混同:Agent HQは「複数エージェントを束ねる器」で、Copilotは「エージェント本体」。Agent HQを別売り製品だと思い込むと料金・機能の理解がずれる
・プレビューとGAの混同:ClaudeとCodexの提供はパブリックプレビュー段階だ。本番フローに全面投入する前に、仕様変更の可能性を織り込む
・既存IDEワークフローからの移行コスト:Cursor・Cline・Claude Codeに慣れたチームほど、いきなり全部Agent HQへ寄せると学習コストが跳ねる。クラウド側オーケストレーションから段階導入する
・外部エージェント設定の信頼境界:複数ベンダーのエージェントに権限を渡す以上、クラウドサンドボックスに何が送られるか・どのブランチを触れるかを必ず設計してから有効化する
とくに1つ目は本記事の主旋律だ。「Agent HQ=Copilotの新版」という誤解だけが独り歩きしやすいが、実体はCopilotを含む複数エージェントを束ねるオーケストレーション層であり、料金も既存Copilotサブスクリプションの上に乗る。
どのエージェントに・どのリポジトリで・どのブランチまで触らせるか、クラウドに何を送るか。この信頼境界を設計せずにプレビューを本番リポジトリで有効化すると、統制の空白が生まれる。Control Planeのポリシーを先に組んでから広げること。
総じて、Agent HQが示したのは「AI開発の主戦場が、単一アシスタントから複数エージェントのオーケストレーションへ移った」という構図だ。器(GitHub)と司令塔(Mission Control)が揃ったいま、ユーザー側に求められるのは、どのエージェントに何を任せ、結果をどう裁くかという運用設計を先に持っておくことである。
参照ソース
・GitHub Blog(公式・Agent HQ発表):Introducing Agent HQ: Any agent, any way you work
・GitHub Changelog(公式・Claude/Codexプレビュー):Claude and Codex are now available in public preview on GitHub
・GitHub Blog(公式・エージェント選択):Pick your agent: Use Claude and Codex on Agent HQ
・GitHub(公式・Agents製品ページ):GitHub Copilot · Agents on GitHub