機能を説明し、コーディングエージェントに渡して、あとは任せておけばプルリクエストを開いてくれる。そして同じことを2つ目、3つ目のエージェントでも繰り返す。そうこうするうちに、本当の問題はエージェントを起動することではなく、それらを把握し続けることになる。GitHub Agent HQは、この混沌に対するGitHubの答えだ。複数ベンダーのコーディングエージェントをGitHub内の1つのコマンドセンターに集約する、ミッションコントロールである。これは間違いなく優れたアイデアであり、本ガイドでは、それが何であるか、誰に適しているか、そしてほとんどの記事が飛ばしてしまう1つの線引き——Agent HQが調整するのはGitHubエコシステム内に存在する作業であり、その外側にあるツールではない——について解説する。
この境界は、チーム全員がGitHubに完全に統一していない瞬間から重要になる。トラッカーがJiraだったり、リポジトリがGitLabにあったり、エージェントの半数がGitHubのクラウドに一切触れないラップトップやターミナル上で動いていたりするなら、あるツールの内側ではなく、あらゆるツールの上に位置するレイヤーが必要だ。それがSharkly、オールインワンのエージェント指揮・管理プラットフォームである。本記事では、Agent HQが輝く場面、その境界が正確にどこにあるのか、そして中立的なレイヤーが混在するフリートをリクエストからリリースまで可視化し続ける方法を順に見ていく。
ここからは、Agent HQの最も良いバージョンを前提に話を進める。それだけの価値があるからだ。そのうえで境界を率直に引いてみよう。そうすれば、Agent HQだけで十分なのか、それともすでに単一エコシステムのハブを超えているのかを、およそ2分で判断できるはずだ。
TL;DR
GitHub Agent HQは、GitHub内のコントロールプレーンであり、Mission Controlというブランド名で提供されている。複数ベンダー（Claude、Codex、Google、Cognition、xAI）のコーディングエージェントを、有料のGitHub Copilotサブスクリプションの一部として割り当て、誘導、追跡するためのものだ。モデルに関してはエージェント非依存であり、作業がすでにGitHubのリポジトリ、プルリクエスト、Actions上で行われている場合に極めて優れている。その境界はエコシステムであり、エージェントベンダーではない。つまりGitHub内で動くエージェントを調整するのであって、GitLab、Jiraボード、Bitbucket、あるいはGitHubのクラウド外のコンピュータ上でローカルに動くエージェントの実行は管理しない。GitHub一筋の組織ならAgent HQを使おう。チームがトラッカー、ホスト、ランタイムを混在させており、それらすべてにまたがる人間によるレビュー付きの単一の共有記録を必要とするなら、Sharklyのような中立的なレイヤーを使おう。
GitHub Agent HQとは実際に何なのか
GitHub Agent HQは、複数ベンダーのコーディングエージェントを割り当て、誘導、追跡するためのGitHub内のコマンドセンターであり、有料のGitHub Copilotサブスクリプションを通じて提供される。この一文にすべてが込められている。各エージェントが独自の起動画面を持つ別々のツールに存在するのではなく、Agent HQはそれらをGitHubがMission Controlと呼ぶ1つの場所に引き寄せる。GitHub自体、VS Code、モバイルアプリ、コマンドラインからアクセスできる。
特筆すべき転換点は、Agent HQが単一ベンダーのエージェントではないということだ。GitHubはこれをAnthropic、OpenAI、Google、Cognition、xAIのコーディングエージェントに開放したので、ハブを離れることなくあるステップではClaudeを、別のステップではCodexを選べる。タスクをエージェントに割り当てると、GitHubの環境内のブランチで作業し、チェックを実行し、あなたが普段コードをレビューするのと同じやり方でレビューできるプルリクエストを返す。Mission Controlはそうした複数の実行を同時に監視する場所であり、Plan Modeのような機能はエージェントが動き出す前に作業を形作る手助けをする。
このハブの要点は調整にある。5つの別々のエージェントツールを行き来して、どれが何をしているかを思い出そうとする必要はない。AIエージェントオーケストレーションとは何かについての解説記事を読んだことがあるなら、Agent HQはオーケストレーションの単一エコシステム版だ。多数のエージェントベンダー、1つのプラットフォーム、そしてそのプラットフォームがGitHubなのである。
Agent HQが得意なこと
この機能を最高の形で捉えよう。最高のバージョンは強力だからだ。ここがAgent HQの真価が発揮される場面である。
ベンダー中立なエージェント選択。ほとんどのエージェントハブは、1つのモデルメーカーに縛り付ける。Agent HQはそうではない。Claude、Codexなどを並行して動かし、ツールを切り替えたりコンテキストを失ったりすることなく、異なるステップに異なるエージェントを使ってアイデアから実装まで進められる。これはモデルロックインに対する確かな答えであり、ローンチ時に真っ先に打ち出された機能であるのも当然だ。
複数のサーフェスにまたがる1つのコマンドセンター。Mission Controlは、GitHub、VS Code、モバイル、CLIからエージェントの活動を単一のビューで見せてくれる。普段いる場所からどこでも割り当て、誘導、追跡できる。かつて並行実行を手作業でやりくりしていたチームにとって、複数のClaude Codeエージェントを並行して実行するガイドは、自作版がいかに面倒になるかを示している。Agent HQはGitHub内でのそのやりくりを取り除く。
レビューがすでに行われている場所に作業が着地する。エージェントはブランチで作業し、プルリクエストを返す。その出力は、チームが信頼するGitHubのレビューフローにそのまま収まり、すでに運用しているのと同じコードレビュー、チェック、マージルールが適用される。diffを探す新しい場所は不要だ。
チームがすでに暮らしているプラットフォームにネイティブ。GitHubがホームなら、Agent HQは後付けではない。アイデンティティ、権限、Actions、リポジトリを共有する。カスタムエージェントの指示と制御は、それが作用するコードの隣に位置するので、セットアップは作業の近くにあり、別のコンソールに取り残されることはない。
GitHubに隅々まで標準化したチームにとって、これは整然として強力なループだ。作業を説明し、エージェントを選び、プルリクエストをレビューし、マージする。それがあなたなら、Agent HQは必要なオーケストレーションのすべてかもしれず、ここで心置きなく読み終えてもらって構わない。
Agent HQは誰のためのものか
Agent HQはGitHub一筋の組織のために作られており、その組織によく奉仕する。最も明確に適合するのはこんなケースだ。ソースがGitHubリポジトリにあり、CIがGitHub Actionsで動き、チームがGitHubのプルリクエストを通じてレビューとマージを行い、有料のCopilotサブスクリプションを保有している。エージェントが読み、変更し、テストし、出荷するために必要なものはすべて1つのプラットフォーム内にすでにあるので、そのプラットフォーム内のハブは作業全体に完全に手が届く。
2026年を通じてロールアウトが進むにつれて、そのチームにとって価値は複利的に増していく。新しいエージェントベンダーも、新しいMission Controlの機能も、作業がすでに存在する場所に着地する。何かを統合する必要はない。すでに運用しているプラットフォームを、より多く活用するだけだ。GitHub中心のエンジニアリング組織にとって、それは説明されたタスクからレビュー済みのマージ済み変更までの最短経路である。
問われているのは、Agent HQがこれに長けているかどうかではない。チームの現実が、そのすべてがGitHubの中に収まるかどうかだ。ここで境界が登場する。
正直な境界：調整するのはGitHubエコシステムであり、その他のツールではない
ここが、発表文がほとんど代わりに引いてくれない線であり、多くの人が予想する線とは違う。限界はエージェントベンダーではない。Agent HQはそこに関しては驚くほどオープンだ。限界はエコシステムである。Agent HQが調整するのは、GitHub内で動くエージェントだ。GitHubリポジトリ、GitHubプルリクエスト、GitHub Actions、GitHubアイデンティティ、そしてGitHub Copilotサブスクリプションの下で。そのすべてがGitHubの要素である。これは欠陥ではない。設計だ。しかし、チームの作業が完全にGitHubの中で暮らさなくなった日、これは厳しい境界となる。
Agent HQはGitLabやBitbucket上の作業を管理しない。リポジトリやパイプラインの一部がGitHubの外にあるなら、Agent HQが調整するエージェントはそれらに届かない。そうした実行は、共有されたタイムラインを持たない別世界に存在する。
Agent HQはプロジェクトトラッカーではない。コードとプルリクエストに対してエージェントを調整するものだ。チームがJiraやLinearで作業を計画・割り当てしているなら、タスクの所有者は誰か、何に依存しているか、何がブロックされているかという問いは、Agent HQが運用しないシステムの中に存在する。プルリクエストはレビューの場であって、割り当てとコンテキストのレイヤーではない。
Agent HQはそのクラウド外で動くエージェントを調整しない。チームメイトがローカルターミナルでClaude Codeを動かしたり、自分のコンピュータでCodexを動かしたり、あなたがホストするランタイムでエージェントを動かしたりしているなら、その作業はMission Controlに現れない。このハブが見るのは、GitHub内で起動したエージェントであり、チームが他所で動かしているエージェントではない。
これはどれもGitHubを貶めるものではない。読者が誤って思い込むであろう箇所で、ツールが何でないかを率直に述べよう。Agent HQは単一エコシステムのコントロールプレーンであり、チームが使うあらゆるトラッカー、ホスト、ランタイムにまたがる中立的な調整レイヤーではない。スタック全体がGitHubなら、この境界が牙をむくことはない。その一部がそうでなくなった瞬間、牙をむく。
二者択一：GitHub一筋の組織か、混合ツールのチームか
選択は「良いハブ対悪いハブ」ではない。「どの形の調整がチームに合うか」である。ここで正直な二者択一を示そう。
GitHub一筋の組織ならGitHub Agent HQを使おう。リポジトリ、Actions、プルリクエスト、Copilotサブスクリプションがあり、そのエコシステムの外に意味のある作業がない場合。その世界では、Agent HQはタスクからレビュー済みブランチまでの最短経路であり、別のレイヤーを加えるのは不要なオーバーヘッドになる。作業のホームが1つだからこそ、ハブは完全に手が届く。
チームがトラッカー、ホスト、ランタイムを混在させているなら中立的なレイヤーを使おう。あなたの現実にJiraボード、GitLabリポジトリ、あるいはGitHubのクラウド外であなたが管理するコンピュータ上で動くエージェントが含まれた瞬間、欠けているのはより多くのエージェントではない。共有された記録だ。どのホスト、トラッカー、ランタイムが作業を行ったかに関係なく、目標、diff、議論、人間によるレビューを保持する1つのタスクが必要だ。それは、あるツールの内側ではなく、あらゆるツールの上に位置するレイヤーの仕事である。
これは、開発者が単一ベンダーのハブで必ずぶつかる分岐点と同じであり、エディタのケースについてはCursor background agentsの解説で、ローカルボードについてはVibe Kanban代替ガイドで扱っている。単一エコシステムのオーケストレーションは快適だ、エコシステムが物語のすべてでなくなるまでは。
Sharklyの位置づけ：あらゆるランタイムとトラッカーを包む中立的なレイヤー
SharklyはGitHub、Copilot、Claude Code、Codex、その他の実行ツールの代替ではない。チームがすでに使っているツールの周りに、共有されたタスク、コンピュータ、コンテキスト、制御、レビューのレイヤーを加えるものだ。この一文が関係のすべてなので、2度読んでほしい。GitHubはそのまま。Agent HQも合う場所ではそのまま。Sharklyは、フリートが単一エコシステムより大きくなったときに、そのフリートを調整するものだ。
役割分担は明確だ。GitHub、Copilot、Claude Code、Codex、および類似のツールが実行を担う。Sharklyは、それらのツールにまたがるチームレベルの割り当て、接続されたコンピュータ、タスクのコンテキスト、進捗、ブロッカー、結果、人間によるレビューを管理する。エージェントは調査し、実行し、テストし、報告する。人は方向を定め、権限を与え、結果を受け入れる。自動化は、チームの判断が必要なところで止まる。
具体的には、Sharklyのタスクが作業の主要単位であり、ある作業に関するすべてを1か所に保持する。あなたが管理するコンピュータ上で、選んだランタイムで動くエージェントにそれを割り当てる。実行、ブロッカー、結果、フォローアップの議論はタスクのタイムラインに戻り、あるプラットフォームのクラウド、別のトラッカー、いくつかのプライベートターミナルに散らばることはない。すべての実行の目標、diff、議論、レビューが一緒に保たれる。その実行がGitHub内のAgent HQを通じて行われたものでも、チームメイトのコンピュータ上のClaude Codeを通じて行われたものでも、来年採用する何かを通じて行われたものでも同じだ。
そして、何かを再構築するよう求めることもない。チームがすでに理解しているプロジェクト、タスク、ステータス、ワークフローを維持し、すでに運用しているトラッカーとホストにSharklyを接続し、チームがすでに使っているプロセスを再構築することなく作業のルーティングを始められる。モデルの使用はそれらのツールに設定されたサブスクリプションまたはAPIキーを通じて続くので、あなたが自分のサブスクリプションを持ち込み、Sharklyがその上に調整を加える。プラットフォームが初めてなら、Sharklyを知るで核となる考え方を、最初のタスクのチュートリアルで最小限の有用な形を端から端まで示している。Sharklyをダウンロードして1つのコンピュータを接続し、実際の作業に対して試してみることができる。
避けるべきよくある間違い
- 「ベンダー中立」を「ツール中立」と誤解する。Agent HQはどのエージェントが作業を行うかについてはオープンであり、それは確かな強みだ。作業がどこに存在するかについてはオープンではない。エージェントは依然としてGitHub内で動く。境界はモデルメーカーではなくエコシステムとして読むべきだ。
- あるエコシステムのハブを、戦略全体であるかのように採用する。今日Agent HQに標準化しつつ、来四半期にGitLabリポジトリやJiraボードを残しておけば、調整の場を静かに分裂させている。GitHubに本当に一筋なのか、混合ツールのチームなのかを早めに決めよう。
- プルリクエストを調整レイヤーとして扱う。プルリクエストはレビューの場であり、割り当てとコンテキストのレイヤーではない。タスクの所有者は誰か、何に依存しているか、なぜブロックされているかは、diffには収まらない。
- ハブに一切触れないエージェントを忘れる。GitHub外で、ローカルターミナルやあなたがホストするコンピュータ上で開始された実行は、Mission Controlに現れない。1つのハブを単一の信頼できる情報源と呼ぶ前に、それらの実行を数え上げよう。
GitHub Agent HQ対中立的なオーケストレーションレイヤー
これは点数表ではなく、役割分担として読んでほしい。
| 観点 | GitHub Agent HQ | 中立的なレイヤー（Sharkly） |
|---|---|---|
| どのエージェントを動かすか | Claude、Codex、Google、Cognition、xAI | Claude Code、Codex、Gemini、OpenCodeなど |
| 作業が存在する場所 | GitHubリポジトリ、Actions、プルリクエスト | チームが接続する任意のホストとトラッカー |
| エージェントが動く場所 | GitHubのクラウド環境 | チームが接続・管理するコンピュータ |
| コマンドサーフェス | GitHub、VS Code、モバイル、CLIにまたがるMission Control | タスク割り当て、CLI、REST API |
| トラッカー | GitHubネイティブ | Jira、Linear、すでに使っているトラッカーに接続 |
| ツールをまたぐ共有記録 | GitHubエコシステム内 | コンテキスト、進捗、ブロッカー、結果を保持する1つのタスク |
| 最適な適合 | GitHubに完全に標準化したチーム | ホスト、トラッカー、ランタイムを混在させるチーム |
| 関係性 | 単一エコシステム内のコントロールプレーン | すでに使っているツールを包むレイヤー |
どちらの列も「間違い」ではない。行ごとの答えが主に左の列に収まるなら、Agent HQが合う。右に傾くなら、特に作業が存在する場所、トラッカー、共有記録の行でそうなら、単一エコシステムのオーケストレーションをすでに超えている。
主なポイント
- GitHub Agent HQは、GitHub内のコントロールプレーンであり、Mission Controlというブランド名で、複数ベンダーのコーディングエージェントを有料のCopilotサブスクリプションの一部として割り当て、誘導、追跡するためのものだ。
- これは見事にこなす。ベンダー中立なエージェント選択、GitHub、VS Code、モバイル、CLIにまたがる1つのコマンドセンター、そしてすでに信頼するプルリクエストレビューフローに着地する作業だ。
- その境界はエコシステムであり、エージェントベンダーではない。GitHub内で動くエージェントを調整するので、GitLabリポジトリ、Jiraボード、GitHubのクラウド外で動くエージェントはその外側に位置する。
- GitHub一筋の組織ならAgent HQを使おう。チームがホスト、トラッカー、ランタイムを混在させ、それらすべてにまたがるレビュー付きの単一の共有記録を必要とするなら、中立的なレイヤーを使おう。
- SharklyはGitHubの代わりではなく、その隣で動く。ツールはそのままに、自分のサブスクリプションを持ち込み、すべての実行をリクエストからリリースまで1つのタスクに戻せる。
次のステップは意図的に小さくしてある。1つのコンピュータを接続し、1つのエージェントを作成し、地味な作業を1つ割り当ててみよう。各概念についてはdocs.sharkly.aiのドキュメントでより深く扱っている。
FAQ
GitHub Agent HQを一文で表すと？GitHub内のコマンドセンターで、Mission Controlというブランド名を持ち、複数ベンダーのコーディングエージェントを有料のGitHub Copilotサブスクリプションの一部として割り当て、誘導、追跡するものであり、エージェントはブランチで作業してプルリクエストを返す。
Agent HQではどのエージェントを動かせる？GitHubはこれをAnthropic、OpenAI、Google、Cognition、xAIのコーディングエージェントに開放したので、ハブを離れることなくあるステップではClaudeを、別のステップではCodexを選べる。正確なラインナップは2026年を通じたロールアウトに伴って拡大する。
GitHub Agent HQは無料？いいえ。有料のGitHub Copilotサブスクリプションを通じて提供され、Copilot Pro+やCopilot Enterpriseのようなプランに応じて利用可否が決まる。ロールアウトに伴って変わるため、最新のプラン詳細はGitHubのページを確認してほしい。
Agent HQはGitLabやJiraで動く？Agent HQが調整するのはGitHubエコシステム内で動くエージェントだ。GitHubリポジトリ、Actions、プルリクエスト。GitLabやBitbucket上の作業、JiraやLinearでの計画はその外側に位置する。それらをつなぐのが、あらゆるツールの上に位置する中立的なレイヤーである。同じ境界のエディタに縛られたバージョンについては、Cursor background agentsの解説を参照してほしい。
Sharklyを使うにはGitHubを置き換える必要がある？いいえ。SharklyはGitHubや実行ツールの代替ではない。すでに使っているツールの周りに共有されたタスク、コンテキスト、レビューのレイヤーを加えるので、GitHub、Copilot、Agent HQはこれまで通りに動き続ける。
Agent HQの上にオーケストレーションレイヤーを加えるべきでないのはどんなとき？スタック全体がGitHub——リポジトリ、Actions、プルリクエスト、Copilot——で、他所に意味のある作業がないなら、Agent HQが必要なオーケストレーションのすべてかもしれない。複数のホスト、トラッカー、ランタイムを運用し、それらにまたがる単一の共有記録を必要とするときにだけ、中立的なレイヤーを加えよう。
Sharklyはモデルの支払い方法を変える？いいえ。あなたが自分のサブスクリプションを持ち込む。モデルの使用は接続されたツールに設定されたサブスクリプションまたはAPIキーを通じて続き、モデルのクォータはチームが接続するプランとAPIアカウントに依存する。
大規模な移行なしに中立的なレイヤーのアプローチを試すには？最小限の有用なワークフローから始めよう。1つのコンピュータを接続し、1つのエージェントを作成し、リスクの低いタスクを1つ割り当てる。最初のタスクのチュートリアルで手順ごとに扱っており、複数のClaude Codeエージェントを並行して実行するでフリート側を示している。
