Issueを、ただ管理するのではなく。
AIが読んで、計画して、進める。
Linear MCPを接続するとClaude Codeから、 Issue・Project・Comment・Initiative・Milestone・Project Updateなどへアクセスできます。 「プロジェクト管理」と「AI開発」を直接つなぎ、 計画から実装・調査・更新までを1つのワークフローへまとめる公式連携です。
Claude CodeからIssue・Project・Commentを検索・作成・更新でき、 Initiative、Milestone、Project Updateなどロードマップレベルの情報まで扱えます。 開発タスクだけでなく、プロダクト計画そのものをAIへ接続できます。
Linear MCPとは？
Linear MCP Serverは、Linearが公式提供するRemote MCPサーバーです。
MCP対応AIクライアントから、Linear Workspaceに存在する開発・プロダクト管理データへ標準化された方法でアクセスできます。
サーバーはLinear側でホスト・管理されており、現在の主要TransportはStreamable HTTPです。
通常のRead-Write接続先は次のURLです。
https://mcp.linear.app/mcp認証にはOAuth 2.1とDynamic Client Registrationが利用されます。
必要に応じてBearer TokenやLinear API Keyによる認証も可能です。
Claude CodeにLinear MCPを接続する
Linear公式ドキュメントでは、Claude Code向けに次のコマンドが案内されています。
claude mcp add --transport http linear-server \
https://mcp.linear.app/mcp追加後、Claude Codeを開いて、
/mcpを実行します。
Linearを選択し、ブラウザでOAuth認証を完了すれば利用できます。
Read-only接続もできる
Linear MCPのかなり良い点が、公式Read-only Endpointが用意されていることです。
https://mcp.linear.app/mcp/readonly/mcp
Read-Write
Issue・Project・Commentなどを読み取り、作成・更新する通常接続。
/mcp/readonly
Read-only
読み取りツールのみを公開する専用Endpoint。
OAuth scope: read
Token側でRead-only
通常Endpointでもread scopeのみ要求すれば書き込みAPIへアクセスできません。
Issueやロードマップを調査・要約するだけなら書き込み権限は不要です。 AIへ必要以上の権限を渡さない最小権限の設計ができます。
Linear MCPで何ができる？
Issueを検索・取得・作成・更新し、開発タスクへ直接接続。
Project情報を参照・更新し、開発のまとまりをAIが理解。
調査結果や進捗、技術的な判断をIssueへ記録できます。
複数Projectを束ねる上位ロードマップ情報を作成・更新。
Project内の重要なPhase・Deliverable・Checkpointを管理。
プロジェクトやInitiativeの進捗をAIから更新。
Linearの階層を理解するとMCPが使いやすい
複数Projectをまとめる上位戦略・ロードマップ。
一定の目的・成果物を持つ開発・プロダクト単位。
ProjectのPhase・重要チェックポイント。
実際に実行する個別タスク・バグ・Feature。
Issueをさらに具体的な実装作業へ分解。
企画書からProject・Issueを自動生成する
Linear公式がMCPの代表的ユースケースとして紹介しているのがRoadmap Planningです。
Claude Codeへ企画書や仕様書を渡し、
目的・Scope・Timeline・Open Questionを整理。
企画全体を表すLinear Projectを生成。
Phase・Deliverable・Checkpointが明確ならMilestone化。
実行可能な具体的作業へ落とし込みます。
明確な関連性があるIssue同士を関係付けます。
Linear公式の推奨Promptでも、元資料にないDependencyやStructureをAIが勝手に発明しないこと、 曖昧なら推測せずOutlineを人間へ提示することが推奨されています。
アイデアから実装計画へ
Linear公式は、Implementation Plan作成もMCPのユースケースとして紹介しています。
例えばClaude Codeへ、
このFeatureの実装計画を作成してください。
1. Linear上の関連Issueを調査
2. 関連するProject Contextを確認
3. Repositoryを調査
4. 実装方針を作成
5. Trade-offとOpen Questionを明示
6. まず計画だけ提示
7. 承認後にParent Issueを作成
8. 実装単位でSub-issuesへ分割
不明点を推測してIssue化しないでください。という形で依頼できます。
Linear Issueからバグを調査する
Incoming Bug Investigationも公式ユースケースです。
Claude CodeはIssueのDescriptionや関連Contextを起点にRepositoryを調査し、原因候補を探せます。
Linear MCPでAPP-421を取得してください。
その後、
1. Issueの内容を整理
2. Repository内の関連コードを調査
3. 再現条件を確認
4. 原因候補を特定
5. 根拠が弱ければ推測しない
6. 十分な根拠があれば修正
7. テストを実行
8. 調査結果をLinear Issueへコメント
Issue更新前に内容を見せてください。調査結果をIssueへ戻せる
ここがLinear MCPとClaude Codeの相性が良い部分です。
AIがローカルコードを調査して終わるのではなく、その結果をLinear側へ戻せます。
例えば、
原因 / 変更内容 / テスト結果 / 残課題 / 次のAction
をIssue Commentとして残せます。
Linearへ戻せば、その情報は次に作業する人間やAgentも参照できます。 AI開発で重要なのは、AIが賢いだけでなく「仕事の履歴が共有されること」です。
Standup NoteからIssueを更新する
Linear公式にはStandup Note AutomationのPrompt例もあります。
StandupのTranscriptやメモを渡し、Issue ID・Title・Owner・Contextから関連Issueを特定。
一致に十分な根拠がある場合だけ、
進捗 / Blocker / Next Step
をIssueへCommentとして追加します。
曖昧なものは無理に結び付けず、「Unmatched」として人間へ返す設計が推奨されています。
Cycle完了内容をAIにまとめさせる
Linear MCPを使えば、特定Teamの直近Cycleを集計して、
何が実際にDoneになったかを取得。
Bug修正・Feature・Infraなど作業傾向を整理。
どのProjectが前進したかを要約。
Standup・週次報告・経営報告向けに整形。
過去の開発履歴をTimeline化する
あるFeatureや障害について、Linear内のIssue・Project・Updateを横断して時系列を作ることもできます。
> 「Public Form」の開発履歴を調べてください。
> 関連Issue / Projectを探し、
時系列で重要な出来事をまとめてください。
含めるもの:
- 最初のIssue
- 方針変更
- Major implementation
- Bug
- Release
- 重要なDecision
根拠がない出来事は追加しないでください。2026年のLinear MCPはプロダクト管理まで広がっている
2026年2月、LinearはMCPをProduct Management用途へ大きく拡張しました。
追加された代表的な機能には、
複数Projectを束ねる上位ロードマップをAIから管理。
戦略レベルの進捗報告を作成・編集。
ProjectのPhaseやCheckpointを作成・編集。
AIが進捗Contextを整理してStatus Updateへ反映。
Project分類や整理もMCPから操作。
Linear上の視覚的ContextもAIワークフローへ利用。
古いSSE設定に注意
過去のLinear MCP記事では、次のURLを使っている例があります。
https://mcp.linear.app/sseしかし現在の新規セットアップではStreamable HTTPが推奨されています。
https://mcp.linear.app/mcpSSEは旧ClientなどのFallback用途として扱われています。
Claude Codeなど現在の対応クライアントではStreamable HTTPの/mcp Endpointを使うのが基本です。
複数Linear Workspaceを使う場合
Linear MCPはSessionごとにOAuth認証します。
複数Workspaceを扱う場合、単純にReconnectするだけでは現在の認証Context内でWorkspaceが切り替わらないことがあります。
mcp-remoteなどConfiguration Directoryを利用できるClientでは、WorkspaceごとにAuth Directoryを分離できます。
MCP_REMOTE_CONFIG_DIR=~/.mcp-auth/workspace-a \
npx mcp-remote https://mcp.linear.app/mcp
MCP_REMOTE_CONFIG_DIR=~/.mcp-auth/workspace-b \
npx mcp-remote https://mcp.linear.app/mcpAPI Keyでも接続できる？
できます。
Linear MCPはInteractive OAuthだけでなく、OAuth Access TokenやLinear API Keyを直接Bearer Headerとして送る方法にも対応しています。
Authorization: Bearer YOUR_TOKENRead-only用途ならRead Permissionだけを持つAPI Keyを作成する方法もあります。
ただしTokenをRepositoryへCommitしたり、共有設定へ直書きするのは避けるべきです。
EnterpriseではOkta管理もできる
LinearはEnterprise向けに、MCPのEnterprise-managed Authenticationにも対応しています。
Okta SAMLとAuthorization Serverを組み合わせることで、対応MCP Clientの認証にも企業側のAccess Policyを適用できます。
つまり、従業員が勝手に別認証経路でLinear MCPへ接続するのではなく、企業のIdentity管理へ寄せた運用が可能です。
Linear Coding Sessionsとは？
ここはMCPとかなり混同しやすいポイントです。
2026年6月、LinearはCoding Sessionsを公開しました。
Linear AgentがClaude CodeやCodexを使って、実際にコードを書ける仕組みです。
Claude Codeを作業の中心にしてLinearを参照・更新。 Repositoryで実装しながらIssue・Project Contextを利用する形。
Linear側を起点にIssueをAgentへ割り当て、 Claude CodeやCodexによるCloud Coding Sessionを開始する形。
Coding SessionsではIssueをLinear AgentへAssignしたり、Chat・Comment・Slack Threadから変更を依頼できます。
SessionにはIssue Detail、History、Customer Request、Discussion、Related WorkなどLinear WorkspaceのContextが渡されます。
2026年のLinearは単なるIssue Trackerではなく、 AI Agentを開発プロセスの中で調整するControl Planeの方向へ進んでいます。
Linear Agent自身も外部MCPへ接続できる
もう一段ややこしいですが重要です。
2026年4月からLinear Agent自身も外部MCP Serverへ接続できます。
例えば、
NotionのInterview NoteからCustomer Requestを作る。
PostHogデータから仮説を検証。
Meetingの決定事項からFollow-up Issueを生成。
企業内ContextからProject Specを補強。
つまり、
Claude Code → Linear MCP → Linear
だけでなく、
Linear Agent → 外部MCP → Notion / Analytics / Knowledge
という逆方向の連携も存在します。
安全に使うための設計
「書き込める範囲」を先に決める。
Issue作成・Status変更・Project Updateなどは便利ですが、 AIの誤判断がWorkspace全体へ影響しないようにHuman Reviewを残す設計が重要です。
- 調査用途ならRead-only Endpointから始める
- 曖昧なIssueをAIに勝手に生成させない
- Project作成前にPlanを確認する
- Assignee変更は明示的な指示がある場合だけ行う
- Status更新前にテスト結果を確認する
- TokenやAPI KeyをRepositoryへ保存しない
- 重要なロードマップ変更にはHuman Approvalを残す
実践用プロンプト
Linear MCPを使って、
APP-421のIssueを確認してください。
作業フロー:
1. Issue本文・コメント・関連Issueを取得
2. Project Contextを確認
3. 要件と完了条件を整理
4. Repository内の関連コードを調査
5. 原因と影響範囲を特定
6. 不明点があれば推測せず報告
7. 実装計画を先に提示
8. 承認後に最小変更で修正
9. Test / Typecheck / Buildを実行
10. 必要ならPlaywrightでE2E確認
11. Git diffを自己レビュー
12. 変更内容・テスト結果・残課題をまとめる
13. Linearへ投稿するComment案を提示
14. 承認後にIssueへComment
15. 完了条件を満たした場合のみStatus変更
新しいIssue・Sub-issue・Assignee・Dependencyは
元のContextに根拠がない限り勝手に作成しないでください。これまでのMCPを全部つなぐと？
PRD・仕様・Meeting Contextを取得。
UI・Design System・Variablesを取得。
Project・Milestone・Issueへ作業を構造化。
Repository・PR・Issue Contextと連携。
実際のコードを実装・修正。
DB・Auth・Backend Contextを確認。
Preview Deployment・Logsを確認。
実ブラウザでE2Eを検証。
Production Error・Traceを監視。
進捗・検証結果・残課題・Statusを更新。
Notionが仕様、Figmaがデザイン、GitHubがCode History、 VercelがDeployment、SentryがProductionの状態を持つなら、 Linearは「今どの仕事を、誰が、どこまで進めているのか」を持ちます。 MCPによってこれらがAgentから横断可能になります。
Linear MCPでプロジェクト管理はどう変わる？
AIがProject Systemを直接読める。
Issue・Project・Milestone・UpdateがMachine-readableになることで、 AI Agentは「何をするべきか」を人間とのChatだけに依存せず理解できるようになります。
従来は、
Issueを読む → 人間がAIへ説明 → AIが実装 → 人間がLinearへ戻して更新
という往復がありました。
MCPを使えば、
Linearを読む → Claude Codeが実装 → 検証 → Linearを更新
まで同じAgent Workflowの中で扱えます。
Coding Agentが十分に速くなれば、 人間が仕様・Issue・進捗を別々のツールからコピーしてAIへ伝える時間の方が目立ちます。 Linear MCPの価値は、その受け渡し自体を減らせることにあります。
関連記事
出典：Linear公式「MCP server」「Linear MCP for product management」「Coding sessions in Linear」「Linear Agent MCP support」ほか。接続方法・機能・認証仕様は記事執筆時点の情報です。
