GitHub

GitHub はほとんどのワークスペースが最初に使う統合です。SprintLoop GitHub App によって、レーンはブランチを push し、PR を開き、ステータス更新を投稿し、CI シグナルをレーンの監査台帳に取り込めるようになります。アプリなしではレーンは GitHub に対して読み取り専用。アプリがあれば、完全なコラボレーターです。

このページはインストール、スコープ、リポジトリ接続、ブランチ保護、webhook フロー、よくあるはまりどころをカバーします。

アプリのインストール

SprintLoop 内部から: Settings → Integrations → GitHub → Install the GitHub App。 GitHub のアプリインストールフローへリダイレクトされます。

GitHub は以下の選択を求めます:

アカウントか org か。 SprintLoop にレーンをディスパッチさせたいリポジトリを所有する側を選びます。複数の org にアプリをインストールし、後で切り替えられます。
リポジトリ。 org の全リポジトリを接続するなら All repositories、サブセットを選ぶなら Only select repositories。レーンが暴走したときの爆発半径を狭めるため、“select” の方を推奨します。

インストール後、SprintLoop に戻り、接続済みのリポジトリごとにグリーンのステータス行が出ます。アプリはバックグラウンドでデフォルトブランチ、ブランチ保護ルール、CI 設定を取得します。通常 5–15 秒です。

必要なスコープ

アプリはインストール時に次のパーミッションを要求します:

スコープ	なぜ
`contents: write`	レーンブランチを push、コミットを書く
`pull_requests: write`	PR を開く、ステータスコメントを投稿
`checks: read`	CI ステータスをレーン監査台帳に取り込む
`members: read`	チームから PR レビュアー候補を表示
`metadata: read`	リポジトリ設定（デフォルトブランチ、ブランチ保護）を読む

要求しないもの:

secrets — SprintLoop はあなたのリポジトリシークレットを read も write もしません。
packages — GitHub Packages へのアクセスなし。
admin:org — org admin endpoint へのアクセスなし。
delete:repo — 破壊的パーミッションなし。

セキュリティチームが監査する必要があれば、マニフェストは https://github.com/apps/sprintloop で公開され、スコープはアプリの公開ページから可視です。

リポジトリ接続

リポジトリは、アプリがそこにインストールされ、かつワークスペースが Settings → Integrations → GitHub → Repos にリストしている時点で「接続済み」になります。初回インストールがリストを自動で埋めます。アプリをアンインストールせずに後でリポジトリを切断できます。

接続済みリポジトリには次が付きます:

デフォルトブランチ（GitHub から自動検出）。
スコープポリシー（デフォルト: レーンはリポジトリ配下の任意のパスを claim 可能）。
CI 取り込み設定（デフォルト: checks: all）。
任意の PR template オーバーライド。

接続はワークスペース単位。同じリポジトリを 2 つの SprintLoop ワークスペースに接続することもできます — OSS プロジェクトが dev と security のワークスペースを分けるときに便利。違うワークスペースから同じリポジトリへのレーンはスコープクレームを共有しません。衝突は GitHub 側の PR-merge 時点で解決されます。

レーンが PR を開くときに起きること

完全なフロー:

オーナーがレーンを承認。
SprintLoop が、接続済みリポジトリで sprintloop/<workspace-handle>/<lane-id> というブランチにレーンの署名済みコミットを push。
SprintLoop が GitHub API 経由で PR を開く。PR タイトルはレーンのタイトル。PR 本文には概要、使ったハーネス、モデルバージョン、Review Committee の判定、レーンの監査ページへのリンクが入る。
GitHub がステータスチェックとブランチ保護が要求するレビュアーを発火。
SprintLoop がチェック結果をレーンのチェーンに取り込む（署名済みエントリ — 各 CI ステータスは監査可能）。
PR が GitHub でマージされると（あなたか別のチームメイトが）、SprintLoop が pull_request.closed webhook を受け、レーンを merged に印付け、フェデレーションルートにスタンプ。

PR description はデフォルトで冗長。チームが簡潔な PR を好むなら、Settings → Integrations → GitHub → PR template でテンプレートを設定してください。テンプレートはレーン概要と同じ Liquid 風の変数（{{lane.title}}、{{lane.harness}} など）をサポートします。

ブランチ保護

リポジトリが N 件の承認、CI green、強制 push の制限を要求するブランチ保護を持つなら、SprintLoop はそのすべてを尊重します。レーンの sign-off は内部のものです — ワークスペースオーナーがレーンをレビューしたという表明で、GitHub レビューではありません。あなたのブランチ保護ルールは GitHub 側で依然として適用されます。

よくあるパターン: ブランチ保護が SprintLoop sign-off の上に GitHub 外部レビューを 1 件要求する。チームは外の目の安全性を得て、レーンの監査証跡は SprintLoop のレビュアーエージェントとワークスペースオーナーが見たすべてを捕らえます。

ブランチ保護が、レーンが満たせないステータスチェック（例えば、保護されたパスへの変更でしか走らないカスタムチェック）を要求すると、レーンページに足りないチェックを名指す黄色いバナーが出ます。チェックが満たされるかルールが修正されるまでマージは失敗します。

アプリは次に subscribe します:

pull_request — PR の merge / close を追跡。
push — Context Engine のリポジトリマップを refresh。
check_run と check_suite — CI ステータスを取り込み。
installation と installation_repositories — 接続済みリポジトリのリストを sync。
workflow_run — Actions ランを発火させたレーンに帰属。

Webhook は https://api.sprintloop.ai/integrations/github/webhook に届きます。エンドポイントはすべてのリクエストで GitHub の署名ヘッダを検証し、<50ms で 200 を返します（作業はキューされ、インラインでは処理されません）。GitHub があなたの org の設定で webhook 持続失敗を報告していたら、ほぼ常に一過性 — アプリはリトライして自己修復します — が、24 時間で 1% を超える持続失敗率はサポートに連絡してください。

よくあるはまりどころ

「レーンが push したのに PR が開かない。」 レーンのブランチが正しいベースに対して push されたか確認してください。リポジトリのデフォルトブランチが develop（main ではない）なら、ディスパッチごとにオーバーライドしない限りレーンは develop をベースに使います。同じブランチからすでに PR が存在すると PR 作成は失敗します（二重に開きません）。

「GitHub では CI green なのにレーンは pending と表示。」 チェック取り込みは check_suite.completed webhook に依存します。一部の CI プロバイダは visible なグリーンチェックの後 30–60 秒それを発火するのに時間がかかります。5 分経っても pending なら、webhook が我々に届かなかった — GitHub からスイートを再発火するか、レーンページで Re-sync CI をクリックしてください。

「代わりに GitLab か Bitbucket を使いたい。」 GitLab は同じ形の統合でサポート — Integrations index を見てください。Bitbucket は 2026 Q3 のロードマップ。

「アプリが新しいリポジトリで再 grant を求め続ける。」 GitHub App は org ごとのパーミッション grant を持ち、新しいリポジトリはアプリの Configure ページから追加する必要があります。設計上、新しく作られたリポジトリを自動 claim しません — opt in は意図的な行動です。