課題はすでにGitHub上にある。コードも、プルリクエストのレビューも、チームが四半期かけて合意したブランチルールも同じだ。最初のボードと同期を取り続ける二つ目のボードなど、誰も望まない。足りないのは、そうした課題の一つをコーディングエージェントに渡し、レビュー可能なプルリクエストとして受け取る手段だ。しかも、その課題が生まれたリポジトリから離れることなく。
GitHubをSharklyに接続すると、それが実現する。Sharklyはエージェントの指揮と管理をこれ一つでこなすオールインワンプラットフォームだ。GitHubの課題をアサイン可能なTaskに変換し、コーディングエージェント（Claude Code、Codex、Gemini、あるいはチームが使う任意のRuntime）に振り分け、隔離されたworktree内のComputer上で作業を実行し、結果を通常どおりレビューできるプルリクエストとして返す。ここで押さえておきたいのは二点。実際にリポジトリに触れるのは誰か、そして人間がどこで承認しなければならないか、だ。
ループを1文で言い表すと
GitHubを接続し、リポジトリをSpaceにリンクすると、新しい課題がTaskになる。それをエージェントにアサインすれば、Sharklyのどこでも同じ約束事が適用される。エージェントは調査し、実行し、テストし、報告する。人間はdiffをレビューし、何をリリースするかを決める。
2つの接続——なぜ別物なのか
GitHub連携は2つのレイヤーに分かれており、これを混同すると、誰が何を見られるのかがたちまちわからなくなる。
1つ目のレイヤーは組織の接続だ。Organization OwnerまたはAdminがIntegrationsを開き、GitHubを見つけ、参照させるべきリポジトリに対してGitHub Appをインストールする。この接続があってこそ、プルリクエストのリンクやリンクバックコメントが可能になる。メンバーが個人のGitHubアカウントを接続することもできるが、それは同期されたコメントにどの身元が表示されるかが変わるだけで、組織の接続がすでに果たしている役割は変わらない。
2つ目のレイヤーは、そうしたリポジトリの1つをSpaceにリンクすることだ。これを設定すると、新しいGitHub課題がTaskとして表示されるようになる。既存の課題はインポートされない。リポジトリはSpaceに対して一方向（課題の変更は流入するだけで、決して戻らない）または双方向（課題とTaskが双方向で同期し続ける）で連携でき、Spaceが同時に持てる双方向リポジトリは1つだけなので、慎重に選びたい。
ここに、多くの人がつまずく境界線がある。これらはどれも、エージェントがコードをクローンする権限を得る仕組みではない。GitHub連携が担うのは、プルリクエストのリンク、課題の同期、リンクバックコメントだ。どのエージェントにも、リポジトリへの読み取り・書き込みアクセスを渡すものではない。
エージェントへのコードアクセスは別途付与する
コードアクセスは別の設定であり、GitHub接続ではなく、エージェントまたはSpaceに対して行う。自前のリポジトリを持たないエージェントは、そのTaskのSpaceに設定されている内容にフォールバックする。Spaceが参照する複数のコードベースのうち1つしか触れてほしくない場合は、エージェント側でそのリストを絞り込む。
いずれにせよ、実行にはComputer上で機能するGitアクセスが別途必要だ。SSHキー、HTTPSトークン、あるいはすでにそこに設定済みのホスト認証情報などである。組織の接続がこれらを提供したり置き換えたりすることはない。実行がクローンできない場合、それはComputer側の問題であり、GitHub Appの設定の問題ではない。
課題をエージェントにアサインする
リポジトリをリンクすると、新しいGitHub課題がTaskとして登録される（Issue、Bug、Feature、Ticketはいずれも有効なタスク種別で、Spaceがどれを使っていても構わない）。エージェントへのアサインは、同僚にアサインするのと同じ要領だ。Assigneeコントロールを開き、代わりにエージェントを選ぶ。
エージェントは保存された作業構成であり、使い捨てのプロンプトではない。その指示、Runtime、リポジトリ、実行設定が作業を形づくる。ちょうど職務記述書が新入社員の仕事を形づくるように。TaskがBacklogに入った場合、まだ何も実行されない。そこは待機場所だ。作業中のステータスに移し、ComputerとRuntimeの準備が整えば、Sharklyが実行をディスパッチする。
2つのエージェントが同じリポジトリに触れるとき
ここがチームが最も気にする部分だ。デフォルトのモードはTemporaryで、各Taskには隔離されたディレクトリが割り当てられ、リポジトリに紐づく実行では新しいworktreeが用意される。同じリポジトリの異なる2つの課題に取り組む2つのエージェントは、それぞれ自分のチェックアウトを取得し、共有することはない。そのため、同じComputer上であっても、互いのファイルを上書きしたり、ブランチを奪い合ったりすることはない。これは、AIコーディングエージェントとgit worktreeを併用するときに手作業で行うのと同じ作法を、自動化したものにすぎない。
同時実行にも上限がある。Temporaryの実行はデフォルトでComputer全体の上限のおよそ半分になる。手動で引き上げることはできるが、その値が利用可能なディレクトリ容量を超えると製品が警告を出す。実際に衝突が始まるのはそこからだ。Specifiedモードも存在し、こちらは新しいworktreeではなく1つの固定ディレクトリをエージェントが再利用する。ただし一度に1つの実行しか処理できず、複数のエージェントが同時に叩くリポジトリには向かない。
返ってくるもの——プルリクエスト
エージェントがプルリクエストを開いたら、ブランチ名、タイトル、本文のいずれかにTask IDを書くことでTaskと紐づけられる。3つのうちどれか1つで十分で、SH-312 のようなID単体でも Fixes SH-312 と同じように機能する。fixes、closes、skip といった単語に特別な処理はないからだ。公開リポジトリでは、信頼できる作成者、つまりオーナー、メンバー、コラボレーターだけがリンクされ、部外者のプルリクエストがあなたのTaskに成りすますことはできない。
リンクされたプルリクエストには、Taskを指し示すリンクバックコメントを付けることもできる。これはプライベートリポジトリではデフォルトでオン、公開リポジトリではデフォルトでオフになっている。この切り替えはGitHubの設定にあり、Space自体が公開か非公開かとは別の話だ。
レビューの関門——判断が置かれる場所
プルリクエストをマージしてもTaskのステータスは変わらないし、マージが勝手に起こることもない。これは意図的な設計だ。Taskのステータスとエージェントの作業状態は別々に追跡される。そのため、StartedのTaskが同時にWorking、Waiting for human reply、Waiting for human review、Errorを示すこともあり、これらのシグナルは担当者のInboxに表示される。元のGitHub課題をクローズまたは再オープンすると、双方向同期のTaskのステータスは動くことがあるが、プルリクエストのマージでは動かない。
エージェントは調査し、実行し、テストし、報告する。人間は元の課題と照らしてdiffを読み、変更を依頼するか承認し、マージとリリースの判断を自分で下す。この分担は一貫して保たれる。GitHub上でも、Sharklyの他のあらゆる場所と同じだ。自動化は、チームの判断が必要なまさにその地点で止まる。より詳しい仕組みについては、Sharklyのヒューマン・イン・ザ・ループのレビューワークフローで直接扱っている。
GitHub自身のエージェントハブで足りる場合
チームがGitHubに全面的に依存しているなら——ソース、CI、レビュー、そして有料のCopilotシートまで——GitHub自身のAgent HQはそのエコシステム内でエージェントをうまく統率してくれるので、他に何も必要ないかもしれない。Sharklyが生きてくるのは、作業がJiraも経由するようになったとき、エージェントがGitHubのクラウド外のComputer上で動くようになったとき、あるいはチームが複数のRuntimeを併用していて、最適なものが変わるたびにワークフローを組み直したくないときだ。Jiraがその混在の一部なら、JiraチケットをAIエージェントにアサインするで、同じループをJira側からたどっている。
実際の課題1つで試すなら、SharklyのGitHub、Jira、Slack連携を開き、GitHub組織を接続し、アクセスの少ないリポジトリを1つSpaceにリンクし、次に来た小さな課題を自分ではなくエージェントにアサインしてみよう。
よくある質問
GitHub組織を接続すると、エージェントが自分のコードにアクセスできるようになりますか？いいえ。組織の接続が担うのは、プルリクエストのリンク、課題の同期、リンクバックコメントです。コードアクセスはエージェントまたはSpaceに対して別途設定し、実行にはComputer上で独自のGit認証情報が別途必要です。
同じリポジトリで作業する2つのエージェントが衝突することはありますか？デフォルトのTemporaryモードではありません。各実行はそれぞれ隔離されたworktreeを取得するため、同じComputer上でも同時実行中のエージェントが作業コピーを共有することはありません。
プルリクエストをマージすると、GitHub課題やTaskはクローズされますか？マージだけではTaskのステータスは変わりません。双方向同期されたリポジトリでは、元のGitHub課題をクローズすると変わることはありますが、それはPRのマージとは別の操作です。
エージェントのプルリクエストは実際どこを対象にするのですか？Sharklyは、Runtimeが書き込んだブランチ、タイトル、本文のいずれかのTask IDによってプルリクエストをリンクします。ブランチ戦略を指定するわけではないので、テスト課題より重要なものをアサインする前に、使用するRuntimeのデフォルトのベースブランチの挙動を確認しておきましょう。
新規だけでなく、既存のGitHub課題も残せますか？リポジトリをリンクすると、それ以降に作成される課題が同期されます。既存の課題は自動ではインポートされません。
