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

このTipsでできること

Claude CodeにLinearを接続すると、コードを書いている画面から離れずにIssueの起票・調査・優先度付けを依頼できます。Linear公式のMCPドキュメントは、ロードマップ計画・スタンドアップ記録・バグ調査・サイクル集計・実装計画・タイムライン生成といった定番ワークフローを例示しています。本Tipsは、そのうち実務で頻度の高いものをClaude Codeでどう依頼すればよいかまとめます。接続そのものの手順はClaude Linear連携 — 接続手順とできることで扱っているので、まだ接続していない場合はそちらを先に確認してください。

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

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

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

ポイントは、先に一覧だけを求め、実際のラベル変更や担当者アサインは確認後に別依頼で行うことです。1回の指示で評価と変更を同時に頼むと、Claudeの判断基準を確認する前に既存のIssueが動いてしまいます。評価結果を見て納得できたら、「高評価の3件にhigh-priorityラベルを付けて」と続けて指示すれば、確認済みの範囲だけを安全に反映できます。

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

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

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

Claude Codeはリポジトリのコードを直接読めるため、Issueの説明文だけでは分からない原因の当たりをつけやすいのが強みです。Linear単体のMCPクライアント(claude.aiなど)では得にくい、コードとチケットを横断した調査がClaude Codeの差別化点になります。証拠が弱い推測は断定させず、明示的に「不確実」と書かせる指示を入れておくと、後から読んだ人が調査の確度を判断しやすくなります。

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

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

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

実務上は「確信が持てるものだけ処理する」という条件を必ず入れておきます。曖昧な言及まで無理に紐づけると、無関係なIssueにノイズのようなコメントが増えていきます。未対応として弾かれたメモは人間が最後に目視で確認すれば十分で、全件を機械的に処理しようとしないほうが結果的に信頼できる運用になります。

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

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

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

振り返りの精度は元のIssueの記述量に依存します。タイトルだけで詳細が書かれていないIssueが多いチームでは、要約の粒度も粗くなります。この依頼を継続的に使うなら、Issue作成時に一定の説明を書く運用ルールと組み合わせるほうが効果が出ます。サイクルごとに同じ形式で振り返りを蓄積しておくと、数サイクル分をまとめて比較する依頼もそのまま応用できます。

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

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

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

実際にIssueを作成する前に、必ず構成案を提示させてから確認する流れにしておきましょう。ドキュメントの記述が曖昧な場合、Claudeが不足を推測で埋めてしまう可能性があるため、「書かれていないことは作らない」という制約を明示しておくと、意図しない構造のIssueが量産される事態を防げます。

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

これらのワークフローはいずれもLinearへの書き込みを伴います。チーム全体で使う前に、どこまでを自動実行させ、どこから人間の承認を挟むかを決めておくことが実務上の前提になります。個人で試すだけなら細かい設計は後回しでも構いませんが、チーム共通の運用として定着させるなら、最初に権限の線引きを決めてから展開したほうが、後から「誰かが勝手にIssueを大量作成した」といった事故を防げます。

読み取り専用にしたいチームは、接続先を https://mcp.linear.app/mcp/readonly にする方法もあります。この設定の詳細は接続ガイドの「読み取り専用にして安全に接続する方法」で扱っています。評価や調査だけを任せたいチームは、まずこの読み取り専用の状態から運用を始めて、慣れてきたら書き込み権限を段階的に広げていく進め方が現実的です。

繰り返し使う依頼はスラッシュコマンドに固定する

上記の依頼を毎回打ち込むのは手間です。使う頻度の高いものは、Claude Codeのカスタムスラッシュコマンドとしてプロジェクトに保存しておくと、チーム全員が同じ品質で依頼を再利用できます。.claude/commands/ にMarkdownファイルを置き、本文にプロンプトの型を書いておけば、/triage-linear のような短いコマンドで毎回同じ手順を呼び出せます。

チームで共有する場合は、権限の強い操作(Issue作成・ラベル変更)を含むコマンドほど、実行前に必ず内容を提示させる設計にしておくのが安全です。「まず一覧・提案を見せる」「確認後に別コマンドで実行する」という2段階の構成をコマンド化しておけば、誰が使っても同じ安全性を保てます。個人の裁量でプロンプトを毎回微調整するより、チーム共通のコマンドとして固定したほうが、優先度評価の基準や調査レポートの粒度がぶれません。

複数のコネクタを併用するときの負荷対策

LinearだけでなくSlackやGitHubなど複数のConnectorを同時に有効化していると、会話ごとに読み込むツールの数が増え、応答が重くなったりコンテキストを圧迫したりします。Claude公式は接続数が10を超えたあたりから、ツールの読み込み方を「Auto(既定)」から「On demand」へ切り替えることを案内しています。On demandにすると、実際に必要になったタイミングでだけツールを読み込むため、会話全体の見通しが良くなります。

Linearでの開発ワークフローに絞って使うセッションでは、そのタイミングだけLinear以外のConnectorをオフにしておくのも有効です。優先度評価やバグ調査のように処理対象が多いタスクほど、余計なツールを読み込ませない工夫が応答の安定につながります。

よくあるつまずき

• 一括処理で意図しないIssueまで変更される: 「対象を先に一覧表示し、確認後に変更する」という2段階の依頼に分けていないと、想定外のIssueまで巻き込まれることがあります。まず一覧、変更は別依頼が基本です
• 調査結果の確度が分からない: バグ調査を依頼するとき「不確実な部分は明記して」と指定しないと、推測と確認済みの事実が同じトーンで書かれてしまいます
• スタンドアップの自動転記でノイズが増える: あいまいな言及まで無理に紐づけると、関係の薄いコメントがIssueに溜まっていきます。確信度の低いものは未対応として弾く条件を必ず入れます
• サイクル振り返りが実態より前向きに書かれる: 元のIssueの説明が薄いと、要約が楽観的な言い回しに寄りがちです。「誇張せず現状のまま報告して」と明示的に指定すると精度が上がります
• 計画書からのIssue一括作成で構造が暴走する: 依存関係やマイルストーンを勝手に補完されると、後から手直しする手間のほうが大きくなります。作成前に構成案の提示を必須にします

よくある質問

claude.aiやDesktopでも同じ依頼はできますか

依頼自体は可能ですが、コードベースを直接参照した調査(バグの原因特定など)はClaude Codeが有利です。claude.ai・Desktopでの接続手順は冒頭で触れた接続ガイドにまとめていますので、まだ接続していない場合はあわせて確認してください。

複数のリポジトリにまたがるIssue整理はできますか

Claude Codeのセッションは基本的に1プロジェクト単位ですが、Linear側のIssueはリポジトリと1対1に紐づく必要はありません。複数リポジトリを横断する調査は、対象リポジトリを明示的に指定しながら依頼すると精度が保てます。マイクロサービス構成で複数リポジトリを行き来するチームでは、調査対象のリポジトリ名をプロンプトの冒頭に書いておくと、どのコードベースを見て判断したのかが後から追跡しやすくなります。リポジトリごとにセッションを分けて、それぞれの調査結果を最後に1つのIssueへまとめる、という2段階の進め方も実務では有効です。

自動でIssueを作らせるのは危険ではありませんか

Tool permissionsで書き込み系ツールを「Needs approval」にしておけば、実行前に必ず内容の確認が挟まります。本記事で示したプロンプトも、多くが「まず一覧・提案を見せてから」という2段階の設計にしているのはこのためです。特にチーム全体に展開するスラッシュコマンドでは、この確認ステップを省略しない設計にしておくと、意図しない書き込みが起きるリスクを抑えられます。

Slackのやり取りを起点にできますか

できます。SlackとLinearを両方接続していれば、Slackのスレッドを要約してからLinearのコメントに転記する、といった横断的な依頼も可能です。Slackコネクタの前提条件はClaude Connectorsとはで確認できます。複数のConnectorを組み合わせるほど便利になる一方、読み込むツールも増えるため、前述のTool accessモードの設定とあわせて検討すると快適に使えます。