Linear MCP完全攻略 2026 — 公式リモートサーバー・OAuth 2.1・25+ツール、GraphQL専用APIで詰まる7つのポイント

なぜLinear MCPが2026年の注目株なのか

Linearはソフトウェアチーム向けのモダンなプロジェクト管理ツールで、issue・cycle・project・roadmapを高速なキーボードファーストUXで操作することで知られている。2025年末から2026年にかけて、Linearは Cloudflareおよび Anthropicと共同で公式MCPサーバー を公開し、AIエージェント時代のプロジェクト管理基盤として急速に存在感を高めている。

KanseiLinkのデータでは、Linearの公式MCPは agent_ready: connectable グレード(信頼スコア0.7)で、公式リモートホスト型・OAuth 2.1認可・25以上のツールを備える。注目すべきは『ローカルプロセスを動かさず、URL一つで接続できる』運用モデルで、これは多くのMCPサーバーがまだ npx ベースのstdio起動に依存している中で、明確に一歩先のモデルだ。

アーキテクチャ — リモートホスト型MCPの真価

Linear MCPは mcp.linear.app/mcp でホストされ、Linear社が運用・更新する。エージェント側の設定はおおむね以下のような構成で済む。

// MCPクライアント設定の例 (Claude Desktop / Cursor等)
{
  "mcpServers": {
    "linear": {
      "url": "https://mcp.linear.app/mcp",
      "transport": "http"
    }
  }
}

初回接続時、エージェントはブラウザを開いてLinearにログイン・スコープを承認するだけ。APIキーの手作業発行・保管・ローテーションが不要で、OAuth 2.1のフローでトークンが自動的に発行・更新される。さらに新ツールがLinear側で追加されてもクライアント側の更新は不要で、自動的に利用可能になる。

認証の落とし穴 — Bearer問題と Dynamic Client Registration

Linearは二つの認証方式を併存させている: Personal API Key (PAT) と OAuth 2.0/2.1。MCPサーバー経由ではOAuth 2.1 + DCRが推奨されるが、自前スクリプトやサービスアカウント用途ではPATも使われる。ここに最大の罠がある。

Dynamic Client Registration (DCR) の効果

2025年末からLinear MCPがサポートしたDCRは、エージェント運用にとって重要な意味を持つ。従来は『各ユーザーが個別にOAuthアプリを登録し、Client ID/Secretを生成し、コールバックURLを設定し…』という煩雑な前段が必要だった。DCRでは MCPクライアントが初回接続時に自動的にOAuthクライアントを動的登録 し、ユーザーは『Linearにログインしてスコープ承認するだけ』で完了する。

2026年4月9日には、Linearが『MCP OAuth接続が約24時間後に切断される』バグを修正したリリースをアナウンスしている。これはトークンの自動リフレッシュフローが特定クライアント実装で機能していなかったことが原因で、長時間稼働するエージェントが翌日突然失敗する厄介な挙動を示していた。長期セッションを前提とするエージェントは、OAuthエラー時に自動再認可フローを起動するフォールバックを今も推奨される。

GraphQL専用APIと複雑度ベースのレート制限

Linearは https://api.linear.app/graphql のみを公開しており、REST APIは存在しない。全てのリクエストは POST /graphql で、ペイロードに query / mutation を載せる形式となる。

POST https://api.linear.app/graphql
Authorization: lin_api_xxxxx          # PAT(Bearerなし)
Content-Type: application/json

{
  "query": "{ viewer { id name email } issues(first: 5) { nodes { id identifier title state { name } } } }"
}

レート制限は『複雑度ポイント制』で、単純な時間あたりリクエスト数ではない。PATは1時間あたり 1,500ポイント、OAuthアプリは 5,000ポイント。各フィールド/mutationには重みが設定されており、深くネストしたクエリほど消費が大きい。

本番運用での鍵は『最小フィールド原則』。エージェントが必要としない情報まで含めて問い合わせると複雑度ポイントを浪費する。GraphQLの利点はまさに『必要なフィールドだけ取得できる』こと——この特性を活かさないなら、Linearのレート制限と相性が悪い。

25+ツール・新機能 — Initiatives / Milestones / Project Updates

Linearの公式MCPサーバーは2026年2月のアップデートで initiatives, milestones, project updates, project labels, image loading のサポートが追加された。これにより、単なるissue管理を超えて、プロダクト計画やステークホルダー報告までエージェントが扱える領域が広がった。

• Issue操作: 作成・検索・更新・コメント・状態遷移
• Cycle/Sprint管理: 現在のサイクル取得、issueのアサイン
• Project & Initiative: プロジェクト・上位イニシアチブの作成/更新
• Project Milestones: マイルストーンの管理
• Project Updates: ステークホルダー向け状況更新の作成・取得
• Labels & Custom Fields: ラベル付与、プロジェクトラベル設定
• Team Management: チーム一覧、メンバーシップ確認

エージェント開発で詰まる7つのポイント

❌ 1. AuthorizationヘッダーのBearer/非Bearer混在

PATには『Bearer』を付けず、OAuthには付ける。MCPクライアントの自動Bearer付与に注意。

❌ 2. teamIdスコープなしの全件検索

ワークスペースに数千issueがあると応答が肥大化してトークンが浪費される。必ず teamId でスコープする。

❌ 3. ネストの深いクエリで複雑度爆発

issues { nodes { comments { nodes { user { teams { ... } } } } } } のようなネストは複雑度を一気に食う。フラットなクエリに分解し、必要なら2回に分ける。

❌ 4. UUIDとissue identifier(ENG-42)の取り違え

人間向けには ENG-42 形式の identifier を使うべきだが、APIは UUID も受け付ける。エージェントがユーザーから受け取る入力と、API呼び出しで使う識別子の正規化を統一する。

❌ 5. ポーリングによるレート制限消費

『5秒ごとに issues をポーリング』は最悪のパターン。WebhooksまたはGraphQL subscriptions(WebSocket)を使ったpush型 に切り替える。

❌ 6. OAuth長期セッションの突然死

4月の切断バグは修正済みだが、設計上『OAuthエラー時に自動再認可フローを起動』フォールバックを必ず実装する。

❌ 7. GraphQLエラーレスポンスのパース忘れ

Linearは {"errors": [{"message": "...", "extensions": {"code": "...", "type": "..."}}], "data": null} 形式の標準GraphQLエラーを返す。HTTP 200でも data: null になっていれば失敗。エージェントは errors 配列を必ず確認する。

Backlog/Asana/Jira との比較

Linearの強みは『OAuth 2.1 + DCR + リモートホスト』という最新仕様の採用と、新機能の継続追加の速度。一方Backlogは KanseiLink実測で90%成功率・128ms平均レイテンシ・91ユースケース蓄積と、実エージェント使用での信頼性データが豊富で、その意味では現時点で『AAA』はBacklogの方。新規プロジェクト向け・グローバルチームならLinear、日本市場での実績・既存導入率ならBacklogという棲み分けが妥当だ。

本番投入前チェックリスト

• MCPクライアントのAuthorizationヘッダー自動Bearer付与の挙動を確認した
• OAuth 2.1 + DCRフローで初回認可が完了することを確認した
• OAuthトークンのリフレッシュ失敗時の再認可フローを実装した
• 全issue検索ではなく teamId でスコープを絞っている
• GraphQLクエリは必要フィールドのみを指定する『最小フィールド原則』を守っている
• X-Complexity, X-RateLimit-Remaining をログ/監視に組み込んでいる
• 長時間ポーリングではなく Webhooks / subscriptions を採用している
• GraphQLレスポンスの errors 配列を必ず確認している(HTTP 200でも失敗があり得る)
• identifier(ENG-42)/UUID の正規化ロジックを用意している
• Personal API Keyを使う場合の鍵ローテーション運用フローを用意している

FAQ

Q1. Linear MCPはセルフホストできますか?

公式版はリモートホスト型のみです(mcp.linear.app/mcp)。コミュニティ製の npm @linear/mcp-server stdio型も存在しますが、Anthropic/Cloudflareと共同設計された最新機能(DCR等)は公式リモートが先行。新規開発は公式リモート、特殊な要件があれば3rdパーティを検討してください。

Q2. Personal API Keyの『Bearer問題』を避けるには?

MCPクライアントの実装で『PAT用には Authorization をそのまま、OAuthには Bearer を前置』と分岐を入れる。あるいはOAuthに統一してPATは使わない方針が最も安全。本番のエージェント運用では OAuth 2.1 + DCR が推奨です。

Q3. GraphQL複雑度の見積もり方は?

Linearは公式に各フィールドの重み一覧を公開していませんが、X-Complexity レスポンスヘッダーで実測できます。ステージング環境で本番想定クエリを流し、ヘッダー値を集計するのが王道。1クエリで100超なら設計見直しを検討してください。

Q4. Webhooksとsubscriptionsの使い分けは?

Webhooksは外部サーバー(自社のエンドポイント)に向けたHTTP POST、subscriptionsはWebSocketでクライアントに直接プッシュ。サーバー型エージェントならWebhooks、対話型クライアントエージェントならsubscriptionsが一般的な使い分けです。

Q5. KanseiLink上でLinearはなぜ『connectable』で AAA ではないのですか?

2026-05時点で、KanseiLinkの実エージェント挙動データ(usage_count)がまだ0件のためです。MCPは新しく、ツール自体は高品質ですが『実エージェントが本番で何回成功したか』のサンプル数が貯まると AAA に昇格する可能性は十分あります。本記事のような deep-dive はその検証を加速させます。

Q6. 日本のチームがLinearからBacklogに乗り換えるべきか?

ケースバイケースです。LinearはGitHub連携・速度・モダンUXで開発者体験が極めて高い一方、日本語UI・営業/PM/カスタマー含めた非エンジニア向けの使いやすさ・国内法務(電帳法等)対応はBacklogが優位。純粋なエンジニアチームはLinear、複数ロールが混在する組織はBacklogという整理が現実的です。