Busabase × GitHub CopilotGitHub Copilotのナレッジベース
GitHubはコード変更を十分に記録できます。BusabaseはIDE Agent、cloud agent、Pull Request、その先の運用システムをまたぐ判断と事実にレビュー付きの引き継ぎ層を加えます。
1つの製品、複数の実行面
同じタスクがローカルで始まり、クラウドで続き、レビューキューで終わる。
GitHubはIDE agent modeとCopilot cloud agentを区別しています。cloud agentはGitHub Actionsによる一時環境で動き、ブランチとPull Requestを作成できます。IDE Agentは開発者のローカル環境を編集します。Copilot code reviewは別のリポジトリ文脈利用者です。引き継ぎでは各主張を生んだ実行面を明記します。
ローカル環境
開発者の端末で編集とテストを実行。
GitHub上のタスク
調査、計画、ブランチ、Commit、Pull Request。
Pull Request
リポジトリ文脈と方針に照らしてコードを確認。
リポジトリ文脈には既存の所有者がいる
GitHubの指示、Commit、Pull Requestを別のデータベースへ複製しない。
GitHubはリポジトリ全体の指示、パス別指示、AGENTS.md、Copilot Memoryをサポートします。リポジトリmemoryは同じリポジトリ内に限定され、参照コードを検証してから使われます。コード文脈には強力です。Busabaseはリポジトリだけでは所有できない事実を扱います。
| 成果物 | 役割 | 正式な所有者 |
|---|---|---|
| .github/copilot-instructions.md | このリポジトリの構築、テスト、検証方法。 | Git |
| AGENTS.md / パス別指示 | ディレクトリやファイル範囲に応じた指示。 | Git |
| CommitとPull Request | 具体的なコード変更とレビュー議論。 | GitHub |
| 顧客、リリース、サポート、運用判断 | 複数リポジトリや非開発チームが再利用する事実。 | Busabase |
引き継ぎチェーン
Pull Requestのマージは1つのイベントであり、配信記録の全体ではない。
タスクはIssueから始まり、Agent session、Pull Request、CI、デプロイを経て、リリースや顧客向け状態を変えることがあります。各段階の証拠と、結果を承認する責任者は異なります。
リリース証拠の契約
システムを越える事実に、Pull Request後も残る構造を与える。
記録はGitHubをコピーせず参照します。小さなスキーマがあれば、コードのマージ後も展開、文書、サポート準備、顧客影響のレビューが残っているか分かります。
| フィールド | 意味 |
|---|---|
| work_item | 作業を承認したIssueまたはタスク |
| pull_request | レビュー済みコード変更 |
| commit_sha | 評価した正確なバージョン |
| environment | ステージング、プロダクション、地域、テナント |
| verification | テスト、ヘルスチェック、観測結果 |
| operational_state | 提案、準備完了、公開、ロールバック、停止 |
| owner | 現在の状態に責任を持つ人 |
| effective_at | 下流が信頼してよい開始時点 |
Pull Request外のレビュー
コード承認と業務上の受け入れは別の時点で起こる。
Copilotはマージ済みPull Requestとデプロイ証拠を読み、リリース状態の変更を提案できます。Busabaseは変更予定のフィールドを示し、プロダクト、サポート、運用が影響を確認してから新しい状態をマージします。
イベントで台帳を更新
自動化は次の作業を提案する。レビュー担当者を消さない。
デプロイWebhookや定期Agentは新しいイベントを検出してChange Requestを開けます。配信ログはイベントの到着を示し、記録レビューはその解釈を正式な事実にするか判断します。
deploy.succeededリリース状態と検証URLを提案deploy.failed停止状態とインシデント責任者を提案rollback.completed復元したバージョンと影響範囲を提案
MCPは実行面ごとに異なる
VS Codeで動く接続が、Copilot cloud agentでもそのまま動くとは限らない。
Busabase接続ページはVS CodeのCopilot Agent mode向けで、Streamable HTTPとOAuthを使います。一方、GitHubのcloud agent文書は、現在MCP toolsのみをサポートし、resourcesとprompts、OAuthを使うリモートMCPは未対応と説明しています。別々の配備方法として扱います。
| VS Code Agent mode | Streamable HTTP + OAuth | 既存ガイドで接続しauth_verifyを確認。 |
|---|---|---|
| Copilot cloud agent | リポジトリMCP設定 | 必要なtoolsだけを選び、現在のremote OAuth制限に注意。 |
| Copilot code review | リポジトリMCP設定を共有 | 自律実行される可能性があるためアクセス範囲を確認。 |
Copilot引き継ぎの質問
GitHub CopilotナレッジベースのFAQ
BusabaseはGitHub IssuesやPull Requestの代わりですか？
いいえ。コードタスク、Commit、ブランチ、Pull Request、コードレビューはGitHubが正式に管理します。Busabaseはリポジトリを越え、プロダクト、サポート、リリース、運用で使うレビュー済み事実を管理します。
Copilot Memoryの代わりですか？
いいえ。Copilot Memoryは対応するCopilot機能向けにリポジトリ事実と個人設定を保存します。明確なフィールド、外部責任者、レビュー判断、リポジトリ外での再利用が必要な記録にBusabaseを使います。
cloud agentとVS Code Agent modeは同じ方法で接続できますか？
必ずしも同じではありません。GitHubはcloud agentについて異なるMCP機能と認証制限を文書化しています。実行面ごとに設定と検証が必要です。
デプロイイベントは正式記録へ直接書きますか？
決定的なイベントは提案を開始できますが、配信成功が業務準備完了を意味するとは限りません。顧客、サポート、コンプライアンス、共同リリースに影響する状態はレビューします。
最初のBaseでは何を追跡しますか？
チーム間で認識がずれやすい引き継ぎから始めます。リリース準備、移行状態、セキュリティ修正、障害対応、顧客影響などです。
Pull Requestの後から始める
1つのマージ済み変更を、全チームが使えるレビュー済み事実にする。
実際に使う環境でCopilotを接続し、リリース状態の記録を1つ定義し、GitHubの証拠から運用上の事実への最初の引き継ぎをレビューします。