Linear MCPの設定と使い方：AI連携・権限管理・チームでの活用

Linear MCPの接続先URLと認証方式

接続先はhttps://mcp.linear.app/mcpです。ホストされたサーバーにWeb経由で接続するStreamable HTTPを使います。対話形式で設定する場合は、動的クライアント登録に対応したOAuth 2.1で、クライアントの登録とユーザーによる認可を行います。別の方法として、OAuthトークンまたはLinear APIキーをAuthorization: Bearer <yourtoken>で送ることもできます。Linear MCPの設定

MCPは、共通のサービス窓口と考えるとわかりやすいでしょう。アシスタントが「イシューを検索する」「変更を保存する」といった名前付きの操作を要求し、Linearのサーバーが、その接続で許可された操作を実行します。プロンプトで伝えるのは作業の意図です。プロンプトによって権限が追加されるわけではありません。

これらは、接続の権限を制限するための異なる方法です。プロンプトに「編集しないで」と書くのはアシスタントへの指示ですが、読み取り専用のエンドポイントや認証情報は、アシスタントが実行できる操作そのものを制限します。Linearのアクセス設定

チームで使っているクライアントを接続する

ClaudeとClaude Codeの接続手順

Claudeのブラウザー版またはデスクトップアプリで、Settings → Connectorsを開き、Linearを接続します。LinearのClaude連携ページでは、この手順が案内されています。

Claude Codeでは、次のように設定します。

1. ターミナルでclaude mcp add --transport http linear-server https://mcp.linear.app/mcpを実行します。
2. Claude Codeのセッションを開きます。
3. /mcpを実行し、認証を完了します。

このコマンドと実行後の操作は、どちらもLinearのClaude設定ガイドに記載されています。

Cursorの接続手順

LinearのMCPガイドにはインストール用リンクがあり、CursorのMCPツールページでLinearを探すよう案内されています。LinearのCursor向け設定にあるインストール項目から進めます。

Cursor専用の連携ページには、次の手動設定手順も掲載されています。

1. Ctrl/Cmd + Shift + Jを押してCursorの設定を開きます。
2. MCPを選択します。
3. Add new global MCP serverを選択します。
4. 次の設定を追加します。

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

この設定では、クライアントとホストされたサーバーの橋渡しをするmcp-remoteを使います。LinearのCursor連携ページに掲載されている設定です。

Codex CLIとIDE拡張機能の接続手順

Linearの説明では、CLIとIDE拡張機能はMCPの設定を共有します。

1. codex mcp add linear --url https://mcp.linear.app/mcpを実行します。
2. 設定ガイドに記載されているLinearへのログイン案内に従います。
3. 手動で設定する場合は、~/.codex/config.tomlを編集した後、codex mcp login linearで認証するよう案内されています。

設定をコピーする前に、ドキュメント間で記載が食い違っている点を確認しておきましょう。

専用ページの手動設定では、サーバーの項目は[mcp_servers.linear]、URLはurl = "https://mcp.linear.app/mcp"です。ここでは公開されている設定をそのまま示していますが、記載の異なる機能フラグを、現在どの環境でも必須の設定と捉えるべきではありません。LinearのCodex連携、MCPのメインガイド

上記の追加・ログイン手順を使ってください。OpenAIの現行MCPガイドでは、HTTPサーバーの設定とcodex mcp login <server-name>が案内されており、どちらの機能フラグも必須とされていません。OpenAI公式MCPドキュメント

ChatGPTとの連携手順

Linearが公開している手順に沿って接続します。

1. LinearのChatGPT連携ページにあるリンクから、ChatGPTのコネクター設定を開きます。
2. Linearを接続します。
3. ディープリサーチで、Linearを情報源として追加します。

Linearはこの接続について、既存のユーザー単位の権限を維持したまま、イシュー、プロジェクト、ディスカッションを参照する方法と説明しています。この設定を通じたイシューの作成や更新は、ドキュメントに記載されていません。調査や要約にはこの接続を使い、以下の編集例には、書き込みへの対応が明記されたMCPクライアントを使ってください。これはここで紹介した接続についての区別であり、ChatGPTのあらゆる連携機能について断定するものではありません。

Linearが公開しているMCPツール

ツールを理解するうえでは、情報を取得する操作と、変更を保存する操作を分けて考えると便利です。次の表は、Linearが公開しているよく使われるツールの一覧から、識別子をそのまま抜き出し、用途とともに整理したものです。この一覧は、Slack連携ページの、同じLinear MCPサーバーをSlackbotに接続する説明の中にあります。Linearのツール一覧

Linearの変更履歴には、list_cycles、list_issue_labels、list_comments、save_project、save_documentも登場します。サイクルの詳細、ページ分割されたラベルやコメントの取得、プロジェクトの変更、イニシアチブやサイクル配下でのドキュメント作成・親の付け替えが説明されています。ここで示しているのは、関連するツールの公開情報です。すべてのクライアントが、同じ個数の固定されたツールを公開するという意味ではありません。サイクルとラベルのツール、コメントのツール、プロジェクトとドキュメントのツール

古い例では、create_issueとupdate_issueを別々に呼び出していることがあります。Linearでは、これらは**save_issue**に統合されています。過去のプロンプトをコピーしたり、ツール名を前提に仕組みを組んだりする際は、この変更を踏まえてください。Linearのツール変更

接続に与える権限と、管理者が制御できること

この接続は、認可を受けてワークスペースのデータにアクセスする経路として扱ってください。LinearのOAuthでは、readは「ユーザーのアカウントに対する読み取りアクセス」、writeは「ユーザーのアカウントに対する書き込みアクセス」を意味します。デフォルトのユーザーアクターでは、アプリケーションを認可したユーザーとしてリソースが作成されます。LinearのOAuth権限

APIキーについてLinearは、「ユーザーがアクセスできるデータへのフルアクセス」を持ち、権限やチームを制限できると説明しています。そのため、制限を設けたキーと、広い権限を持つ個人用キーでは、実際に可能な操作が大きく異なります。APIキーの権限

利用できる管理機能は、接続の認証方法によって異なります。

Linearは、アプリ承認機能の目的を「どのアプリケーションがワークスペースとそのデータにアクセスできるか」を管理することと説明しています。メンバーはインストール時に承認を申請できます。キーの管理機能が対象とするのはAPIキーによる認証です。OAuthアプリの接続を管理する仕組みの代わりにはなりません。アプリケーションの承認、APIの管理

Okta SAMLを利用しているEnterpriseワークスペースでは、対応するAnthropicクライアントで、企業が一元管理する認可を利用できます。Linearによると、この方式では「既存のLinear権限が適用される」とされています。接続のたびにユーザーが個別に認可する代わりに、管理者がOktaを通じてアクセスを管理します。企業が一元管理する認可

状況の確認だけを行うワークフローには、読み取り専用のアクセスを選びます。トリアージやイシュー作成には必要な書き込み権限を付与し、反映前に変更案を確認できるようにします。この確認手順は、運用上の推奨です。どのクライアントでも同じ承認動作が強制される、という意味ではありません。

実務で使いたい3つのワークフロー

最初は、書き込みなしで使えるサイクルレポートがおすすめです。新規イシューの受け付けで同じ作業が繰り返されているなら、次はトリアージです。すでに決まった内容をリードがチケットに書き起こす時間が多いなら、仕様からイシューへの変換が役立ちます。

以下は、架空の情報を使った具体例です。プロンプトと期待する成果物を示すものであり、ログインして実施したテストの結果ではありません。

新規イシューを整理し、人が確認できるトリアージ案にする

エンジニアリングリードは、届いた報告を確認し、似た既存イシューを取得したうえで、変更案をまとめるようアシスタントに依頼できます。検索やプロパティ編集の繰り返しを減らしながら、担当者と優先度の判断はリードの手元に残せます。

入力例：「エクスポートボタンを押すと固まる」という新しい報告には、絞り込み条件を指定してエクスポートするとブラウザーが応答しなくなる、と書かれています。既存イシュー「絞り込み後のエクスポートが終わらない」も、同じ画面についての報告です。別の報告「招待が届かない」には、配信ログも再現手順もありません。

プロンプト：

確認に使いやすい提案例：

レビュー後、リードは合意できたラベルと担当者の変更だけをsave_issueで反映するよう許可し、判断材料が足りない報告はそのまま残せます。アシスタントには、対象イシューへのリンクと、変更したフィールドの記録を返させます。取得と保存の操作は、Linearのツール一覧に掲載されています。

独自のトリアージシステムを作る前に、Triage Intelligenceと比較してください。Linearにはすでに、プロパティの提案や、重複・関連性の検出機能があります。MCPで独自の処理を組む意義が大きいのは、標準のワークフローでは扱えない背景情報やルールが判断に必要な場合です。Triage Intelligence

要件を勝手に補わず、仕様からイシューを作る

創業者は、承認済みの機能概要からイシューの下書きを作り、レビューした内容をLinearに登録できます。利点は、内容の一貫性を保ちやすいことです。各チケットに元の要件を紐付け、未決定の事項は未決定のまま見える形で残せます。

仕様の例：「ワークスペースの管理者は、メールでメンバーを招待できます。招待された人は、メール内のリンクから招待を承諾します。管理者は、承諾待ちの招待を取り消せます。課金に関する変更と一括招待は対象外です。」

プロンプト：

イシューへの分割案：

**未決定の事項：**メールアドレスがすでにメンバーとして登録されていたら、どう扱いますか。招待に有効期限はありますか。取り消し後に招待された人がアクセスした場合、何を表示しますか。これらは、プロダクトオーナーが判断するまで未決定として残します。

承認後、アシスタントは親イシューとサブイシューを作成し、それぞれのURLと、作成できなかった項目があればその内容を返せます。サブイシューの作成は、MCPの機能として公開されています。LinearのMCP更新情報

書き起こしを担うのはアシスタントです。プロダクトとしての判断は、引き続きプロダクトオーナーが行います。

サイクルの情報から週次の進捗報告を作る

リードは、サイクル内の作業をもとに、各記述の根拠となるリンクを添えた進捗報告の下書きを作れます。点在するイシューの更新情報から、内容を検証できるレポートにまとめるまでの手間を減らせます。

週次レポートとサイクルの要約では、対象期間が異なる場合があります。チーム、サイクル、報告対象期間を明示し、「このサイクルで完了」が、いつの間にか「今週完了」に置き換わらないようにしてください。

元情報の例：「招待メール」は報告対象期間内にDoneになっています。「招待の承諾」はIn Progressのままです。「招待の取り消し」には、取り消し済みリンクを開いた際の画面について、プロダクト上の判断を待っているため実装が止まっている、というコメントがあります。

プロンプト：

下書きの例：

実際の下書きでは、各文に対応するイシューのURLを付けます。この例では、あえて完了率やリリース済みとの主張を含めていません。サイクル、イシュー、コメントの取得機能を組み合わせると、このワークフローに必要な材料を集められます。サイクルとイシューのツール、コメントの取得

基本のワークフローが定着したら試したい用途

コメントの作成は、サーバーの機能として公開されています。また、プロジェクト関連のツールは、引き継ぎに必要な背景情報を取得するのに使えます。サーバーの機能、プロジェクトのツール

費用対効果は、確認にかかる時間まで含めて考える

影響を受けるのは、エンジニアリングの調整業務にかかるコストです。MCPの導入前は、リードが検索、コピー、情報の照合、文章化を行います。アシスタントを接続した後も、依頼の範囲を決め、結果を確認し、誤りを修正する作業は残ります。

自社のコストを当てはめて、次の式で採算を確認してください。

純便益 =（手作業での準備時間 − アシスタントを使った準備・確認・修正の時間）× 間接費込みの時間単価 − 追加のクライアント利用料と運用コスト。

見栄えのよいレポートでも、検証に以前より時間がかかるなら、チームの時間を節約できたとはいえません。比較する際はレポートの対象範囲をそろえ、誤った編集を元に戻す作業も含めてください。目指すのは、確認を終えて採用できる成果物あたりの調整作業を減らすことです。

プラン選びについては、Linearの料金を参照してください。そもそもどの管理ツールを使うか決まっていない場合は、LinearとJiraの比較が参考になります。関連する接続先は、おすすめのMCPサーバーガイドで紹介しています。

Linear MCPを使って、どんなサービスを作れるか

最初に検討するなら、サイクルの進捗報告を下書きするサービスが有力です。 チームごとの情報の境界を守り、完了した作業と未完了の作業を分け、根拠となるイシューを添えた一貫性のあるレポートには、エンジニアリングリードが対価を払う可能性があります。最小限の実用的な構成は、レポートの定義を保存し、関連するサイクルのデータを取得して、編集可能な下書きを出力するものです。定期実行、再試行、配信は、自分のアプリケーション側で実装する部分になります。

課題は差別化です。汎用的な要約プロンプトは簡単に再現できます。製品として価値になり得るのは、企業ごとの報告ルール、情報源を追跡できる仕組み、レビューのプロセスです。独立したサブスクリプションサービスを作る前に、チームがこれらの点で繰り返し困っているかを確かめてください。

独自のトリアージ案をレビューするキューは、より対象を絞った機会です。 プラットフォーム部門やサポートエンジニアリングのリードには、Linearのイシュー情報に、自社の振り分けルールと、別途アクセス認可を得たサポート情報を組み合わせる仕組みへの支払い意欲があるかもしれません。最小限の構成では、フィールドの変更案と根拠を示し、承認するか見送るかを選べるようにして、承認された変更を反映します。

課題は、Linear標準のTriage Intelligenceと直接競合することです。追加の情報やルールによって、そのチームでは標準機能だけで十分に扱えない判断を改善できる場合に限って作るべきでしょう。これらは製品の仮説であり、顧客に成果が出たという実績の主張ではありません。

MCPで接続しても解決できないこと

MCPによって、アシスタントは操作を実行できるようになります。しかし、曖昧な要件が確定したり、不完全なイシュー情報が信頼できるデータに変わったりするわけではありません。Doneになったチケットは、そのチケットの状況を述べる根拠になります。ただし、それだけで顧客が機能を利用できるようになったと証明することはできません。

同様に、Linearへのアクセスを認可しても、イシュー内で言及されているすべてのドキュメント、リポジトリ、サポートシステムへのアクセスまで認可されるわけではありません。それらの情報源が必要な仕組みを作るなら、それぞれのアクセス権と取得経路を別途設計してください。

新しく設定する場合は/mcpを使います。Linearは/sseを非推奨のフォールバックとしています。また、以前のjerhadfによるコミュニティサーバーも、非推奨で保守を終了していることを明記し、Linearの公式サーバーを使うよう案内しています。現在のエンドポイントの案内

週明けにまず取り組むなら、エンジニアリングリードがチーム、サイクル、報告対象期間を決め、読み取り専用で進捗報告の下書きを作ってみてください。各記述をリンク先のイシューと照合し、準備にかかる手間を現在の方法と比較します。チーム内で確認手順が明確に定まったら、書き込みを伴う用途にも広げましょう。

チームのルールに合わせてこうしたワークフローを構築したい場合は、AI自動化の開発をご相談ください。