Claude Media
Claude Code Linear連携 — 開発チケットの整理と優先度付け
Claude CodeClaude連携Tips

Claude Code Linear連携 — 開発チケットの整理と優先度付け

Claude CodeとLinearを組み合わせると、バグ調査からIssue起票、スタンドアップの記録まで開発者の手を離れずに進められます。接続の2経路と権限の切り分け、実務で使える依頼の型をまとめます。

読了目安 約17分

このTipsでできること

Claude CodeにLinearを接続すると、コードを書いている画面から離れずにIssueの起票・調査・優先度付けを依頼できます。Linearが公式ドキュメントで例示している定番ワークフローは、ロードマップ計画・スタンドアップ記録・バグ調査・サイクル集計・実装計画・タイムライン生成の6つです。本Tipsは、そのうち実務で頻度の高いものをClaude Codeでどう依頼するかを扱います。

接続そのものの手順はClaude Linear連携 — 接続手順とできることにあります。ここでは、接続の経路ごとの違いと、書き込みを伴う依頼を安全に回すための型に絞ります。

Claude CodeからLinearへつなぐ2つの経路

Linearへの接続は、claude.aiのコネクタを使う経路と、Claude Codeに直接登録する経路の2つです。どちらでも使えるツールは同じLinearのMCPサーバーですが、設定の置き場所と、読み込まれる条件が違います。

くらべる

接続の2経路

アカウント連動

claude.aiのコネクタ

claude.aiで追加したコネクタが、claude.aiアカウントでログインしたClaude Codeに自動で現れます。/mcp の一覧には、claude.ai由来であることを示す表示が付きます。

ANTHROPIC_API_KEY・ANTHROPIC_AUTH_TOKEN・apiKeyHelper が有効なとき、またはBedrockなどのサードパーティ経由で使っているときは読み込まれません。claude setup-token で発行した CLAUDE_CODE_OAUTH_TOKEN はモデル呼び出しにしか使えないため、この場合も読み込まれません。ANTHROPIC_PROFILE、フェデレーション用の変数、有効なAnthropicプロファイルが認証情報を渡している場合も同様です。

Claude Code側で直接登録

claude mcp add

Linearのドキュメントが示すコマンドで登録し、セッション内で /mcp を開いて認証します。APIキーでログインしている環境でも使えます。

ツール名は mcp__<登録名>__<ツール名> の形になり、権限ルールを登録名で書けます。

直接登録するコマンドは次のとおりです。登録名の linear-server はLinearのドキュメントの例に合わせています。

claude mcp add --transport http linear-server https://mcp.linear.app/mcp

同じURLをコネクタと直接登録の両方で持っている場合は、直接登録のほうが優先されます。このとき /mcp ではコネクタ側がhiddenと表示されます。重複を解消するなら、直接登録のエントリを claude mcp remove で外すとコネクタが使われます。

開発チケットの優先度付けを任せる

Issueが溜まってどれから手を付けるか判断に迷うとき、Claudeに一括で評価させると整理が早く進みます。

triageキューにあるIssueを全部確認して、影響範囲・再現頻度・修正コストの3軸で
優先度を評価してほしい。高・中・低の3段階に分けて理由を1行ずつ添えて、
高評価のものから順にリストアップして。ラベルや担当者は変更せず、まず一覧だけ出して。

書き込みを伴う依頼は、評価と変更を1回の指示にまとめず、3段階に分けます。この型は以降の節でも使い回します。

手順

確認を挟む3段階の依頼

  1. 1

    一覧だけを出させる

    対象のIssueと評価の根拠だけを出力させ、ラベルや担当者には触れさせません。

  2. 2

    確認した範囲を指定する

    評価に納得できたら、「高評価の3件にhigh-priorityラベルを付けて」のように件数や条件を絞って指示します。

  3. 3

    変更の結果を報告させる

    反映したIssueのIDと変更内容を一覧で返させると、意図した範囲だけが動いたかを見比べられます。

バグ調査からIssueへの記録までを1回で頼む

Linearの公式例に載っている代表的なユースケースの1つが、既存Issueを起点にした原因調査です。

Linear Issue LIN-142 を確認して、関連しそうな箇所をリポジトリ内で調べてほしい。
再現手順・想定される原因・直したときの影響範囲を整理して、証拠が弱い部分は
「不確実」と明記して。まとまったらそのままLIN-142にコメントとして投稿して。

Claude Codeはリポジトリのコードを直接読めるので、Issueの説明文だけでは分からない原因の当たりをつけられます。コードとチケットをまたいだ調査は、Claude Codeで依頼するときの強みです。証拠が弱い推測を断定させず、「不確実」と書かせる指示を入れておくと、後から読んだ人が調査の確度を判断できます。

Linearの公式例は、この調査の要約をIssueへコメントとして投稿するところまでを1つの依頼にしています。投稿前に内容を見たいときは、「コメントを投稿する前に全文を見せて」の一文を足します。

スタンドアップメモをIssueの更新に変換する

朝会やSlackで共有された進捗メモを、手作業でLinearに転記する作業は地味に時間を食います。

以下のスタンドアップメモを読んで、言及されているIssueをタイトルやIDから
特定して。確信を持って紐づけられるものだけコメントを追加し、
何をしたか・現在の状況・次のアクションを簡潔にまとめて。
あいまいで紐づけ先が分からないメモは、未対応としてそのまま報告して。
コメントを投稿する前に、更新するIssueと投稿するコメントの全文を見せて。
 
メモ: [ここに当日のメモを貼り付け]

「確信が持てるものだけ処理する」という条件は外せません。曖昧な言及まで無理に紐づけると、無関係なIssueにノイズのようなコメントが増えます。

Linearの公式例も同じ考え方で、曖昧なメモは当て推量で処理せず未対応として返し、コメントは適用前に投稿予定の全文を見せる構成です。未対応のメモは人間が最後に目で確かめれば足りるので、全件を機械的に処理しようとしないほうが運用は安定します。

サイクルの振り返りを自動で作る

スプリント(サイクル)の終わりに、何が完了したかをまとめる作業もClaudeに任せられます。

直近で完了したサイクルの対象チームのIssueを集めて、完了した作業の要点を
まとめて。バグ修正・機能追加・技術的な整備がそれぞれどれくらいの比率か、
目立った傾向があれば触れて。進行中で終わらなかった作業は誇張せず、
現状のまま報告して。

振り返りの精度は元のIssueの記述量に依存します。タイトルだけで詳細が書かれていないIssueが多いチームでは、要約の粒度も粗くなり、楽観的な言い回しに寄りがちです。依頼文に「誇張せず現状のまま報告して」と入れ、Issue作成時に説明を書く運用ルールと組み合わせると効果が出ます。サイクルごとに同じ形式で振り返りを蓄積すれば、数サイクル分を比べる依頼にもそのまま応用できます。

計画書からIssueをまとめて起こす

企画書や仕様メモのような文書を渡して、そこからプロジェクトとIssueの構造をまとめて作らせる使い方もあります。

このプランニングドキュメントを読んで、目的・スコープ・スケジュールに沿った
Linearプロジェクトを作りたい。まず提案する構成(プロジェクト・マイルストーン・
Issue案・依存関係)を先に見せて、私が確認してから実際の作成に進んで。
ドキュメントに書かれていない依存関係や構造を勝手に作らないで。

Linearの公式例は、文書が曖昧で質の高い作業にできないときは推測せず、構成案を返してレビューを求める指示を含んでいます。上の依頼文はそれに沿った形です。ドキュメントの記述が曖昧だと、Claudeが不足を推測で埋めてしまうことがあります。「書かれていないことは作らない」と明示しておけば、意図しない構造のIssueが量産される事態を防げます。

権限設計を先に決めておく

ここまでのワークフローはいずれもLinearへの書き込みを伴います。個人で試すだけなら細かい設計は後回しでも構いません。チーム共通の運用にするなら、どこまでを自動実行させ、どこから人間の承認を挟むかを最初に決めます。後から「誰かが勝手にIssueを大量作成した」という事故が起きにくくなります。

用途設定の目安理由
優先度評価・調査レポート作成設定の目安読み取りのみ許可理由Issueを変更しないので誤操作のリスクがない
Issueへのコメント追加設定の目安Needs approval理由内容を確認してから記録に残したい
ラベル変更・担当者アサイン設定の目安Needs approval理由既存の運用ルールと矛盾しないか人間が確認する余地を残す
新規Issue・プロジェクトの一括作成設定の目安提案の提示までを既定、作成は都度確認理由誤った構造のIssueが量産されるのを防ぐ

Claude Codeでは、確認の強さが設定の置き場所で変わります。組織がclaude.aiのコネクタのツールを ask に設定している場合、そのツールは毎回の呼び出しで確認が出ます。この確認は acceptEdits・auto・bypassPermissions の各モードでも省かれず、一致する許可ルールがあっても残ります。dontAsk モードでは、確認の代わりに呼び出しが拒否されます。Claude Desktopのローカル・SSHセッションには組織の ask が届かず、通常の権限ルールが適用されます。

個人やチームのレベルでは、.claude/settings.json の権限ルールで直接登録したLinearサーバーを丸ごと確認制にできます。ルールはサーバー名で書き、mcp__linear-server はそのサーバーのすべてのツールに一致します。

{
  "permissions": {
    "ask": ["mcp__linear-server"]
  }
}

claude.aiのコネクタ経由のツール名は mcp__claude_ai_<サーバー名>__<ツール名> の形です。ルールを書くときは、/mcp に表示される実際の名前に合わせます。

読み取り専用から始める

評価や調査だけを任せたいなら、書き込みができない状態で接続する方法が3つあります。Linearのドキュメントが挙げているのは次のとおりです。

  • 接続先を https://mcp.linear.app/mcp/readonly にする。このエンドポイントは読み取りツールだけを公開します
  • 通常の /mcp エンドポイントに、read のOAuthスコープだけを要求して接続する。このスコープで認可されたトークンは書き込みAPIに届きません
  • Read 権限だけを付けたLinearのAPIキーを、Authorization: Bearer ヘッダーで渡す

1つ目と3つ目は、Claude Codeでは次のように登録します。

claude mcp add --transport http linear-readonly https://mcp.linear.app/mcp/readonly
claude mcp add --transport http linear-key https://mcp.linear.app/mcp \
  --header "Authorization: Bearer <Readだけを付けたAPIキー>"

読み取り専用で運用してから、必要な範囲だけ書き込み用の登録を足していく進め方もあります。

繰り返し使う依頼はスキルかコマンドに固定する

ここまでの依頼を毎回打ち込むのは手間です。使う頻度の高いものは、プロジェクトに保存しておくと、チーム全員が同じ依頼を再利用できます。.claude/commands/ に置いたMarkdownファイルは今も /triage-linear のようなコマンドとして動きます。Claude Codeではカスタムコマンドがスキルに統合されており、新しく作るなら、補助ファイルを持てるスキルが推奨されています。

チームで共有するコマンドは、書き込みを含むものほど、実行前に内容を提示させる設計にしておくと安全です。「まず一覧・提案を見せる」「確認後に別のコマンドで実行する」という2段階をそれぞれコマンド化すれば、誰が使っても同じ確認の手順を踏めます。個人の裁量で毎回プロンプトを微調整するより、優先度評価の基準や調査レポートの粒度がぶれません。

コネクタを増やしたときの負荷と切り分け

claude.aiのチャットには、コネクタの読み込み方を選ぶTool accessの設定があり、既定はAutoです。ヘルプでは、有効なコネクタが10個以上あるときはOn demandへの切り替えを検討するよう案内されています。

Claude Codeの側は事情が違います。MCPのツール定義はツール検索で後回しにされ、セッション開始時に読み込まれるのはツール名とサーバーの指示だけです。この動きは既定で有効ですが、ANTHROPIC_BASE_URL が1st partyのホスト以外を指すときなど、一部の環境では既定で無効になります。サーバーを足しても、コンテキストへの影響は小さいと説明されています。

そのため、Claude Codeで気にしたいのは重さよりも、依頼に関係のないコネクタが書き込みの候補に混ざることです。Linear中心のセッションでは、/mcp のトグルで他のコネクタを現在のプロジェクトだけオフにできます。Slackなどを併用する場合の前提はClaude Connectorsとはにあります。コネクタを一括で止めるなら、ENABLE_CLAUDEAI_MCP_SERVERS=false を付けて claude を起動する方法があります。

接続で詰まったときの切り分け

切り分け

症状から原因をたどる

  • コネクタが /mcp に出ない

    /status で、いまの認証方式を確かめます。APIキーなどの認証が優先されているときは、コネクタが読み込まれません。該当する環境変数を外し、apiKeyHelper の設定を消すか、プロファイルをオフにしてから、/login でclaude.aiアカウントにサインインします。Bedrockなどのサードパーティ経由で使っている場合は、/login だけでは直りません。Bedrockを有効にしている環境変数など、プロバイダ側の設定を外す必要があります。

  • session token rejected と出る

    claude.aiが、Claude Codeのログインのトークンを拒否した状態です。コネクタの認可をやり直しても直りません。/login でサインインし直し、/mcp から再接続します。

  • 複数のワークスペースを使い分けたい

    Linearのドキュメントでは、ワークスペースごとに別の認証コンテキストが必要とされています。mcp-remote を使う構成なら、MCP_REMOTE_CONFIG_DIR をワークスペースごとに分けます。

  • 接続時に内部サーバーエラーになる

    Linearのドキュメントは、接続時の内部サーバーエラーの対処として、保存された認証情報を消す rm -rf ~/.mcp-auth を実行してから再接続するよう案内しています。必要なら、Nodeを新しいバージョンに上げるようにも書かれています。~/.mcp-auth はmcp-remoteの認証情報の置き場所なので、mcp-remoteを使う構成で当てはまる手順です。

どこから始めるか

個人で試すなら、claude mcp add で登録し、優先度評価とバグ調査の読み取りから始めます。チームに広げるなら、読み取り専用の登録と、確認制のコマンドをセットで配る形が運用しやすくなります。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →