GitHub インテグレーションを設定

このガイドでは、セットアップのうち GitHub に固有の部分を扱います。GitHub は対応している 3 つのコードホストの 1 つです — GitLab や Bitbucket の接続方法と、ワークスペースでこれらを併用する方法については、コードホストを接続を参照してください。

前提条件

作業したいリポジトリにアクセスできる GitHub アカウント
サーバーに登録された GitHub App（ GitHub App を作成を参照）でサインインできるようにする、 または repo と read:org を持つ個人アクセストークンを貼り付ける

GitHub でサインイン

デバイスフローです。GitHub が短いコードを表示し、あなたが github.com で承認すると、サーバーが認証情報を受け取ります — コールバック URL もポートも不要で、公開するものは何もありません。サーバーにクライアント id があればいつでも利用でき、公式ビルドにはすでに含まれています。

設定 → ワークスペース → プロフィールと識別情報 → コードホスティングを開きます（またはオンボーディングの最初のステップ）
GitHub の行で GitHub でサインインをクリックします
ダイアログに 8 文字のコードが表示され、ブラウザーで github.com/login/device が開きます。コードはすでにクリップボードにあります
貼り付けてアプリを承認し、戻ります。行は自動的に「your-username としてサインインしています」に変わります

ブラウザーでの作業を終える間はダイアログを閉じてもかまいません — サーバーはコードの有効期限が切れるまで（約 15 分）ポーリングを続けるため、サインインはそのまま完了します。

またはトークンを貼り付ける

サーバーにアプリがない場合、必要なアカウントにアプリがインストールされていない場合、または単に PAT を使いたい場合のフォールバックです。

設定 → ワークスペース → プロフィールと識別情報 → コードホスティングを開きます
GitHub の行で トークンを追加をクリックします
repo と read:org を持つトークン（classic）を貼り付けて保存します。きめ細かい トークンには、リポジトリの Contents と Pull requests（read and write）、さらに Checks と Actions（read）が必要です。

トークンは保存された時点で検証されるため、行にはそれが属するアカウントの名前が表示されます。削除するには切断をクリックします。

確認ポイント: GitHub の行に「your-username としてサインインしています」と表示されます。応答している認証情報が自分のものでない場合、末尾にそのソースが示されます — 「このサーバーのアプリ経由」または「環境変数から」です。

インテグレーションでできること

機能	仕組み
PR 一覧と詳細	サーバーから、アプリのアイデンティティまたは自分の認証情報で GitHub REST API を利用
チェック実行	GitHub Checks API
レビューの公開	レビューを PR に投稿する、ユーザーの操作を必要とするステップ
リポジトリの登録	チェックアウトの `origin` リモートが github.com — または gitlab.com / bitbucket.org — を指していれば受け入れられます
エージェントの GitHub アクセス	認証情報ブローカーが読み取り専用のトークンを `GH_TOKEN` / `GITHUB_TOKEN` として注入します。プッシュは Control Center を通ります
通知ピング	サーバー側で GitHub の通知受信トレイをポーリングし、「プルリクエストでメンション」と「レビュー依頼」を発生させます
ユーザープロフィール	プロフィールのホバーカードと、作者ごとの PR フィルタリング

一部の経路では、よりコストが低い箇所で REST の代わりに GraphQL API を使用します — PR 作成ピッカーのブランチアクティビティと、レビュー依頼の通知がまだ保留中かどうかを判断するライブのレビュー状態です。

GitHub の障害を監視する

プロバイダーが機能低下しているとき、タイトルバーにステータスチップが表示されます。対象は GitHub、 Claude、OpenAI、Kimi です。すべてが正常な間は非表示になります — 表示は障害の存在を伝えるものであり、その不在を伝えるものではありません。

チップをクリックすると、各プロバイダーの状態と更新ボタンを備えたフライアウトが開きます。ステータスは 2 分ごとに自動で更新されます。

エージェントが GitHub でどのように動作するか

GitHub のワークツリーで作業するエージェントは、常に読み取り専用の GitHub トークンを受け取ります。プッシュは Control Center を通り、Control Center は リモートへプッシュ のルールに問い合わせてから、エージェントが決して持たない書き込みトークンでプッシュを転送します。サンドボックスポリシーを設定を参照してください
エージェントが作成するコミットはエージェントとして作成されます — 表示名に (agent) を加えたもの、エージェントの id をキーとする合成アドレスを使い、人間として作成されることはありません。依頼した人には Co-Authored-By トレーラーでクレジットが付きます
GitHub App が設定されている場合、ブローカーは広範なトークンを渡す代わりに、起動ごとに、きめ細かくリポジトリ単位にスコープされた約 1 時間有効のインストールトークンを発行します。インストールは実行対象リポジトリのオーナーから解決されるため、複数のアカウントにインストールされた 1 つのアプリは、その実行が触れるアカウントに正しくスコープされます。アプリがない場合、エージェントは環境のトークンを受け取ります。これは読み取り専用に絞り込めないため、プッシュのルールは git push には効きますが、トークンを直接使うコードには効きません
トークンは常にブローカーのものであり、依頼したメンバー自身のものではありません。オーナーではなく GitHub を接続していないメンバーのために動く実行には、サーバーのトークンは渡されません

トラブルシューティング

PR 一覧が空で、GitHub が接続されていないと表示される

このサーバーに GitHub の認証情報がありません。コードホスティングでサインインするか、トークンを貼り付けてください。他のコードホストのリポジトリは影響を受けません — GitHub のものだけが何も寄与しません。

行に「トークンを追加」はあるが「GitHub でサインイン」がない

サーバーにクライアント id がありません — ソースからのビルドではこれが通常の状態で、認証情報は公式ビルドにのみ組み込まれるためです。 GitHub App を作成を参照してください。所要時間は約 2 分で、サーバー所有者だけが 1 回行うだけです。

サインインダイアログに、プロバイダーがデバイスコードを返さなかったと表示される

GitHub App は存在しますが、Device flow チェックボックスがオフになっています。アプリの設定（General → Device flow）でオンにして、もう一度試してください。

自分のアカウントを期待したのに、行に「このサーバーのアプリ経由」と表示される

あなたはサインインしていません。表示されているのは、応答しているサーバーのアプリのアイデンティティです。その行の GitHub でサインインをクリックしてください。

きめ細かい PAT でマージボタンやチェックステータスが表示されない

トークンには Contents と Pull requests（read and write）、さらに Checks と Actions（read）が必要です。変更後は、コードホスティングで再度貼り付けてください。

リポジトリの追加が拒否される

登録には次の 3 つすべてが必要です。パスが git ワークツリーの内部にあること、origin リモートがあること、そしてそのリモートが対応しているコードホスト（github.com、 gitlab.com、bitbucket.org）を指していることです。ワークスペースにリポジトリを追加を参照してください。

集中的に使ったあと、しばらく何も動かなくなる

それはレート制限のサーキットブレーカーです。GitHub はプライマリ制限を、 x-ratelimit-remaining: 0 とリセット時刻を伴う 403 で通知します。クライアントはそれを見ると、ウィンドウが経過するまで、ネットワーク呼び出しを行わずに以降のリクエストをローカルで失敗させるため、リトライの嵐が制限を深刻化させることはありません。一時的な失敗は、指数バックオフで最大 3 回再試行され、retry-after が尊重されます。