/ ディレクトリ / プレイグラウンド / Linear
● 公式 linear 🔑 自分のキーが必要

Linear

作者 linear · linear/linear

エージェントがLinearのバックログをトリアージし、サイクルの進捗を投稿し、Sentryからバグを起票します — アプリを開く必要はありません。

LinearのリモートMCP(SSE)は、イシュー、プロジェクト、サイクル、チーム、コメント、ユーザーを公開します。OAuthはLinearが処理するため、PATの管理は不要です。Sentry(自動バグ起票)、GitHub(PR連携)、Notion(週次レポート)との組み合わせが最適です。

なぜ使うのか

主な機能

ライブデモ

実際の動作

linear.replay ▶ 準備完了
0/0

インストール

クライアントを選択

~/Library/Application Support/Claude/claude_desktop_config.json  · Windows: %APPDATA%\Claude\claude_desktop_config.json
{
  "mcpServers": {
    "linear": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.linear.app/sse"
      ]
    }
  }
}

Claude Desktop → Settings → Developer → Edit Config を開く。保存後、アプリを再起動。

~/.cursor/mcp.json · .cursor/mcp.json
{
  "mcpServers": {
    "linear": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.linear.app/sse"
      ]
    }
  }
}

Cursor は Claude Desktop と同じ mcpServers スキーマを使用。プロジェクト設定はグローバルより優先。

VS Code → Cline → MCP Servers → Edit
{
  "mcpServers": {
    "linear": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.linear.app/sse"
      ]
    }
  }
}

Cline サイドバーの MCP Servers アイコンをクリックし、"Edit Configuration" を選択。

~/.codeium/windsurf/mcp_config.json
{
  "mcpServers": {
    "linear": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.linear.app/sse"
      ]
    }
  }
}

Claude Desktop と同じ形式。Windsurf を再起動して反映。

~/.continue/config.json
{
  "mcpServers": [
    {
      "name": "linear",
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.linear.app/sse"
      ]
    }
  ]
}

Continue はマップではなくサーバーオブジェクトの配列を使用。

~/.config/zed/settings.json
{
  "context_servers": {
    "linear": {
      "command": {
        "path": "npx",
        "args": [
          "-y",
          "mcp-remote",
          "https://mcp.linear.app/sse"
        ]
      }
    }
  }
}

context_servers に追加。保存時に Zed がホットリロード。

claude mcp add linear -- npx -y mcp-remote https://mcp.linear.app/sse

ワンライナー。claude mcp list で確認、claude mcp remove で削除。

ユースケース

実用的な使い方: Linear

散らかったLinearバックログを10分でトリアージする方法

👤 エンジニアリングマネージャー、テックリード ⏱ ~15 min intermediate

使うタイミング: 月曜の朝。バックログに未トリアージのイシューが200件以上あり、1時間後にプランニングが控えている場面。

前提条件
  • Linearワークスペースへのアクセスmcp-remote経由のOAuth — 最初のツール呼び出し時にブラウザが開き権限を付与
  • チームスラッグ(例: ENG — 任意のイシューIDを確認 — プレフィックスがチームスラッグです
フロー
  1. チームの未トリアージイシューをすべて取得
    List all ENG issues in state 'Triage' or with no priority set, created in the last 30 days. Return id, title, reporter, and description length.✓ コピーしました
    → 分類に十分なコンテキストを持つ候補の一覧表
  2. テーマごとにクラスタリング
    Group these into 4-6 themes (bug / infra / onboarding / perf / etc.). For each cluster, propose a priority and suggested project.✓ コピーしました
    → 根拠付きのテーマ別クラスター
  3. 決定を適用
    For each cluster, update the issues: set priority, add the matching label, and move to 'Backlog' state. Do NOT assign anyone.✓ コピーしました
    → N件のイシューが更新され、確認ログが記録される

結果: プランニングに使えるバックログが、グループ化・優先度付けされ、エージェントが行ったすべての変更の監査証跡付きで完成します。

注意点
  • エージェントが「類似コードを書いた人」を根拠に誤った担当者へ一括アサインしてしまう — アサインしないよう明示的に指示してください — アサインは人間が判断すべきです
  • Linear無料プランでは約1500リクエスト/時でレート制限がかかるissueBatchUpdateが利用可能であればバッチ更新を使用し、そうでなければトリアージを500件以下に抑えてください
組み合わせ: sentry · github

Linearから週次サイクルステータスレポートを生成する

👤 エンジニアリングマネージャー、PM ⏱ ~10 min beginner

使うタイミング: 金曜の午後、経営層への週次アップデートを書く必要がある場面。

前提条件
  • Linearのアクティブなサイクル — Linear > チーム > Cycles から現在のサイクル番号を確認
フロー
  1. サイクルの統計を取得
    For ENG cycle 47, list all issues grouped by state. Include completed-this-week, in-progress, blocked, and at-risk (no update in 3+ days).✓ コピーしました
    → 件数とイシュータイトル付きの内訳
  2. 前週との差分を確認
    Compare to last week's snapshot [paste prior JSON]. What shipped, what regressed to earlier states, what's newly blocked?✓ コピーしました
    → 説明付きの差分
  3. レポートを作成
    Write a 1-page Markdown report: wins, in-flight, blockers, help-needed. Keep it honest — leadership reads between the lines.✓ コピーしました
    → SlackやNotionに貼り付け可能なレポート

結果: 45分かかっていたサイクルアップデートが10分で完成します。

注意点
  • マージ済みPRのない完了イシューは進捗に見えて実態が伴わない — GitHub MCPと組み合わせて、各「Done」イシューにマージ済みPRが紐づいているか検証してください
組み合わせ: github · notion

新規SentryイシューからLinearバグを自動起票する

👤 オンコールエンジニア ⏱ ~15 min intermediate

使うタイミング: Sentryのリアルタイムエラースパイクを、手動コピペなしで追跡可能なバグとして記録したい場面。

前提条件
  • Linear と並行してSentry MCPがインストール済み — セットアップはsentryガイドを参照
  • from-sentryのような専用Linearラベル — Linear > Settings > Labels から一度作成
フロー
  1. 閾値を超えた新規Sentryイシューを検索
    Find Sentry issues first seen in the last 24h with >50 events in the web-prod project.✓ コピーしました
    → イシューIDとイベント数の一覧
  2. Linearで重複を確認
    For each Sentry issue title, search Linear for existing issues with similar titles or containing the Sentry URL. Skip ones already filed.✓ コピーしました
    → 重複排除リスト — 本当に新規のもののみ
  3. Linearバグを作成
    Create a Linear issue in ENG team for each new Sentry issue: title = Sentry title, description = stacktrace + link, priority = Urgent if >1000 events else High, label = from-sentry.✓ コピーしました
    → N件のイシューが作成され、リンクが返される

結果: 本番エラーを取りこぼさない、クリーンなLinearバグ取り込みフローが実現します。

注意点
  • タイトルの微妙な違いにより同じSentryイシューが二重起票される — SentryイシューのショートID(例: WEB-3a91)をLinearタイトルに含め、その部分文字列で重複排除してください
組み合わせ: sentry

現在のサイクルで停滞しているイシューをリマインドする

👤 テックリード、スクラムマスター ⏱ ~5 min beginner

使うタイミング: サイクル中間チェック。5日以上ステータス変更のないアサイン済みイシューは大抵止まっています。

フロー
  1. 停滞イシューを検索
    List issues in the current ENG cycle that have been in 'In Progress' for 5+ days without a state change or comment.✓ コピーしました
    → 担当者と停滞日数付きの一覧
  2. やさしいリマインドコメントを投稿
    Add a comment on each: 'Quick check-in — still on track for this cycle, or do you need to break this down / get help?' Tag the assignee.✓ コピーしました
    → コメント投稿済み、リンクが返される
  3. 無反応の場合はエスカレーション
    In 48 hours, re-run. If still no update, DM me a list for 1:1 follow-up.✓ コピーしました
    → 人間によるフォローアップ用のエスカレーションリスト

結果: 毎日口うるさいマネージャーにならずに、停滞した作業を解消できます。

注意点
  • 毎時実行するとコメントスパムになる — 投稿前に、エージェントが過去3日以内にすでにコメント済みかどうかを確認してください

NotionのスペックからLinearプロジェクトをスキャフォールドする

👤 PM、新しい施策を立ち上げるテックリード ⏱ ~20 min intermediate

使うタイミング: PRDが書き上がり、追跡可能なイシューに分解する必要がある場面。

前提条件
  • Notion MCPがインストール済み — notionガイドを参照
  • PRDページのURL — Notionからコピー
フロー
  1. スペックを読み込んで要約
    Read the Notion PRD at <URL> and list every discrete deliverable as a one-line description.✓ コピーしました
    → 15〜40件の候補イシュー
  2. レビューと精査
    Group these into 3-5 milestones. Flag any that need design, API, or DB work as separate issues.✓ コピーしました
    → 構造化されたイシューツリー
  3. Linearプロジェクトとイシューを作成
    Create a Linear project named '<Spec title>' in ENG team. Create each milestone as a parent issue, with children as sub-issues. Link back to the Notion page in each description.✓ コピーしました
    → プロジェクトURL + イシュー数

結果: 2時間の手動チケット作成の代わりに、20分で完全にスキャフォールドされたLinearプロジェクトが完成します。

注意点
  • エージェントが20件で十分なところに80件のイシューを作成してしまう — 粒度が細かすぎる — ステップ2で明示的に上限を指定: 「イシューは合計20件以下、1日未満の作業はまとめること」
組み合わせ: notion

組み合わせ

他のMCPと組み合わせて10倍の力を

linear + sentry

本番のエラースパイクを自動的に追跡可能なLinearバグに変換

Find new Sentry web-prod issues from the last 24h with >50 events. For each, create a Linear bug in ENG team labeled 'from-sentry', priority High, with the stacktrace in the description.✓ コピーしました
linear + github

PRをLinearイシューに自動リンクし、PRマージ時にイシューをクローズ

For every open PR in my repo, find the Linear issue ID in the title or branch name and add a reference comment on the Linear issue with the PR URL.✓ コピーしました
linear + notion

週次サイクルダイジェストをNotionデータベースに投稿

Generate this week's ENG cycle status and create a page in the Notion 'Engineering Weekly' database with the full report.✓ コピーしました

ツール

このMCPが提供する機能

ツール入力呼び出すタイミングコスト
list_issues team?, assignee?, state?, label?, cycle?, query?, limit? 主要な検索手段 — ストリームをフィルタリング 1 API call
get_issue id 単一イシューの完全なコンテキストを取得 1 API call
create_issue teamId, title, description?, priority?, labelIds?, assigneeId?, projectId? 新しいイシューを起票 1 API call
update_issue id, stateId?, priority?, assigneeId?, labelIds?, title?, description? ステータス、優先度、またはアサインを変更 1 API call
create_comment issueId, body イシューにリマインドやステータスメモを投稿 1 API call
list_projects teamId? チーム内のアクティブなプロジェクトを一覧取得 1 API call
list_cycles teamId チームのアクティブまたは最近のサイクルを検索 1 API call
list_teams ワークスペース内のチームを一覧取得 1 API call

コストと制限

運用コスト

APIクォータ
OAuthアプリは1500リクエスト/時、バーストは120リクエスト/分 — 実用的なワークフローには十分な余裕
呼び出しあたりのトークン
イシューの説明やコメントの量に応じて、1回あたり300〜1500トークン
金額
無料 — Linear MCPはすべてのLinearプランに含まれています
ヒント
全件取得してからフィルタリングするのではなく、list_issuesに具体的なフィルターを指定してください — 大規模バックログではトークンコストを10分の1に削減できます

セキュリティ

権限、シークレット、影響範囲

最小スコープ: read write issues:create
認証情報の保管: mcp-remote経由のOAuth — トークンは~/.mcp-auth/に保存され、再ログインなしでリフレッシュ可能
データ送信先: すべての呼び出しはapi.linear.appおよびmcp.linear.appへ送信されます
絶対に付与しない: admin

トラブルシューティング

よくあるエラーと対処法

OAuthブラウザポップアップが開かない

npx -y mcp-remote https://mcp.linear.app/sseを手動で一度実行してください — ブラウザに貼り付け可能なURLが表示されます

確認: 認証後、エージェントを再実行してください。トークンは~/.mcp-auth/にキャッシュされます
update_issueで403エラー

Linearのロールにそのチームへの書き込み権限がありません。ワークスペース管理者に昇格を依頼するか、自分が所有するチームにエージェントのスコープを限定してください。

イシューは返されるがコメントが欠落している

コメントは別クエリです — include-comments付きでget_issueを使用するか、イシューIDでコメントを個別に取得してください。

存在するはずのイシューが見つからない

チームフィルターを確認してください — team=nullを指定するか対象チームを明示しない限り、他チームのイシューは返されません。

代替案

Linear 他との比較

代替案代わりに使う場面トレードオフ
Jira MCP組織がLinearではなくJiraを使用している場合APIが重く、ステータスやフィールドが多い — エージェントはJiraではそのままでは精度が落ちます
GitHub Issues (via GitHub MCP)別ツールを使わずにイシューをコードと密結合させたい場合サイクル、プロジェクト、ワークフローステータスがなくなります — GitHub Issuesはシンプルですが構造化の度合いは低くなります

その他

リソース

📖 GitHub の公式 README を読む

🐙 オープンな issue を見る

🔍 400以上のMCPサーバーとSkillsを見る