GitHub Copilot Linear連携GA、課題からPRへ

GitHubは2026年7月23日、Copilot cloud agent for Linearの一般提供を発表した。Linear issueをGitHub Copilot cloud agentに割り当てると、issue本文やコメントを読み、GitHub側でdraft pull requestを開き、独立した実行環境で作業し、進捗をLinearのactivity timelineへ返す。

これは単なる通知連携ではない。Linearを起点に、課題管理、実装、PRレビューの入口がつながる更新である。すでにこのサイトでは、Copilot for Jira正式化でJira work itemからPRへつなぐ流れを扱い、Copilot cloud agent自動実行ではscheduleやIssue/PR eventからagentを起動する運用を見た。今回のLinear GAは、Linearを開発管理の中心に置くプロダクトチームに同じ設計課題を持ち込む。

日本の開発組織で重要なのは、「LinearからAIに任せられる」こと自体ではない。どのissueなら渡してよいか、どのrepositoryとbranchを対象にするか、どのmodelやcustom agentを許すか、誰がレビューし、AI CreditsとGitHub Actions minutesをどの予算で見るかである。

事実: Linear issueからdraft PRまで進む

GitHub Changelogによると、Linear issueをCopilotに割り当てると、Copilotはissue内容を分析してdraft pull requestを開く。作業はGitHub Actionsに支えられたephemeral development environmentで進み、コード変更、テストやlintの実行、進捗のLinear activity timelineへの反映、完了時のpull request review依頼までが流れに含まれる。

GitHub Docsも、Linear workspaceを離れずにCopilot cloud agent sessionを開始できると説明している。Linear issueの説明やコメントを文脈として使い、model、custom agent、base branch、working branchを選び、作業中のsessionへ追加指示を出せる。GitHubの発表では、これらをissue単位で設定するだけでなく、workspaceやteamのagent guidanceとして適用できる点も示されている。

Linear側のintegrationページも同じ流れを示している。対象は、bug fix、small refactor、documentation updateのような反復的な作業であり、PRは既存のreview and approval rulesに従う。つまり、Linear連携は人間のレビューを消す機能ではなく、issueからdraft PRを作るまでの手作業と文脈移動を減らす機能である。

利用条件も確認が必要だ。GitHubは、Copilot cloud agentがCopilot Pro、Pro+、Business、Enterpriseで利用できると説明している。Linear integrationの導入には、GitHub organization owner権限とLinear workspace admin権限が必要になる。BusinessやEnterpriseでは、Copilot cloud agent自体の組織ポリシー、repository opt-out、ユーザー権限も実質的な入口になる。

分析: Linear issueが実装依頼書になる

ここからは分析である。

Linear連携の本質は、issue trackerがagent promptになることだ。従来のLinear issueは、人間の開発者、PM、デザイナー、QAが共通理解を持つための作業単位だった。Copilotをassignできるようになると、title、description、comments、関連リンク、label、project、teamの情報が、そのままAI実装の入力になる。

日本のスタートアップやプロダクト組織では、Linearを軽量に使うことが多い。Slackで背景を話し、FigmaやNotionに仕様を置き、Linearには短いタイトルとメモだけ残す運用も珍しくない。このままCopilotに渡すと、agentは暗黙の背景を読めない。結果として、scopeが広すぎるPR、仕様の取り違え、テスト不足、既存設計との不整合が起きやすい。

したがって、Linear連携を入れる前に、agent向けのdefinition of readyを作るべきだ。最低限、対象repository、変更範囲、期待する挙動、除外事項、受け入れ条件、触ってよいbranch、関連する設計リンク、必要なテストを書いておく。UI修正なら画面状態と文言、API修正ならrequest/response例、バグ修正なら再現手順と期待結果を入れる。

これは人間にとっても悪くない改善である。AIに渡せるissueは、人間にとってもレビューしやすいissueになりやすい。逆に、Copilotが失敗するissueは、もともと人間同士でも暗黙知に依存していた可能性が高い。Linear連携は、AI導入というより、課題管理の品質を露出させる更新として見たほうがよい。

実務: Jira連携との違いを分けて見る

Linear GAは、先行するJira連携と似ている。どちらもissue trackerからCopilot cloud agentを起動し、GitHub上でdraft PRを作る。ただし、日本企業での導入文脈は少し違う。

Jiraは大企業や受託開発、複数部門の承認フローに入りやすい。Rovo、Atlassian admin、Jira project permission、SSO、カスタムフィールドなど、導入前の確認項目が多い。一方、Linearはプロダクトチームやスタートアップで、軽量なissue運用と高速なPRサイクルに寄せて使われることが多い。だからLinear連携では、重い承認設計よりも、issue粒度、branch運用、review queue、agent guidanceの標準化が先に効く。

とはいえ、軽量に始められることは、統制が不要という意味ではない。Copilot AI Credits表示で整理した通り、cloud agentやcode reviewのようなagentic機能は、補完中心の利用より費用の見え方が変わる。Linearから起動できるようになると、GitHub画面に入らないPMやテックリードもagent作業を増やせる。便利さの裏側で、起動者、対象repo、モデル、実行時間、AI Credits、Actions minutesを追える状態が必要になる。

レビュー面では、Copilot code reviewとAGENTS.mdの論点がそのまま重なる。Linearから作られたdraft PRも、リポジトリ規約、CODEOWNERS、required checks、人間reviewerの責任からは逃れられない。AGENTS.mdやcustom instructionsでAIに前提を渡しつつ、最終判断はmaintainerが行う設計にする必要がある。

導入時に決める5つの線

第一に、対象チームを絞る。いきなり全workspaceで有効化せず、LinearとGitHubの運用が近い1つのプロダクトチームで試す。対象repositoryも、内部ツール、ドキュメント、テスト追加、軽微なUI修正など、失敗しても戻しやすい領域から始める。

第二に、issue typeを限定する。bug fix、small refactor、documentation update、テスト追加は向いている。一方、認証、課金、個人情報、権限、DB migration、本番障害対応、顧客固有データの扱いは、初期のLinear起点agent作業から外すべきだ。

第三に、agent guidanceを整える。workspaceやteam単位で使うなら、対象branch、model選択、custom agent、レビュー前の必須テスト、コメントで追加指示する場合の書き方を短く決める。GitHub側のrepository instructionsやAGENTS.mdと矛盾しないようにする。

第四に、レビューSLAを決める。Copilotがdraft PRを作れるようになると、PRの数は増える。レビュー担当が決まっていないと、Linear上では進んで見えるがGitHub上ではdraft PRが滞留する。AIが作ったPRほど、差分だけでなく、元issueとの対応を確認する時間を明示的に置く必要がある。

第五に、費用を日次ではなく週次で見る。初期は件数が少ないため、個別PRの費用を厳密に追うより、週ごとに起動数、完了数、merged率、差し戻し理由、AI Credits、Actions minutesを並べるほうが判断しやすい。効果が低いissue種別は止め、うまくいく種別だけ広げる。

まとめ

GitHub Copilot cloud agent for Linearの一般提供は、Linear issueからAI実装とdraft PR作成へ進む導線を正式化する更新である。GitHub画面でissueを書き直さなくても、Linearで管理している課題をそのままCopilotに渡せるようになる。

ただし、日本の開発チームが見るべき焦点は、連携の便利さではない。Linear issueの品質、agent guidance、branchとrepository権限、レビュー責任、AI CreditsとActions minutesを一体で設計することだ。Linearは軽量だからこそ、曖昧なissueも速く流れる。Copilot連携を使うなら、AIに渡せるissueと、人間が責任を持ってmergeできるPRの形を先にそろえるべきである。

出典

• Copilot cloud agent for Linear is now generally available - GitHub Changelog, 2026-07-23
• Integrating Copilot cloud agent with Linear - GitHub Docs
• GitHub Copilot Integration - Linear - Linear
• About GitHub Copilot cloud agent - GitHub Docs