LinearのイシューをMarkdownに書き出す方法

Linearは速くて、思想がはっきりしています。エンジニアリングチームが求めているのはまさにそれです。同時にLinearは、組織の知識が大量に溜まっていく場所でもあります。バグの再現手順、設計上の判断、ふりかえり、顧客からの報告。その中身をMarkdownとして取り出せれば、AIを使ったワークフロー、ドキュメント生成、アーカイブの道がひらけます。

この記事では、Linearのコンテンツを書き出す実用的な方法をすべて取り上げます。

なぜLinearをMarkdownに書き出すのか

AIによるトリアージ — 直近のイシューをClaudeやChatGPTに渡して「繰り返し出ているテーマは何か」と聞けます
クローズしたイシューからリリースノートを作る — Linear純正の「Build changelog」は優秀ですが融通が利きません。Markdownなら自由に組み替えられます
ポストモーテム — インシデントのイシューと、そこにリンクした親子イシューをまとめて1つのMarkdownにして、ふりかえりに持ち込めます
RAGのナレッジベース — クローズしたイシューをベクトルストアに取り込んでおけば、次の障害のときに過去の類似例が浮かび上がります
ポートフォリオのレビュー — プロジェクトのイシューを1ファイルに書き出して、関係者への報告に使えます
バックアップ — Linearが落ちても何でも再構成できると分かっていれば、夜はよく眠れます

方法1：Minibase Chrome拡張機能（イシュー1〜20件なら最速）

Minibase は、Linearのイシュー・プロジェクト・ドキュメントのどのページでも、ワンクリックできれいなMarkdownに変換します。

MinibaseがLinearから取り込むもの：

イシューのタイトル、ステータス、優先度、担当者、サイクル、プロジェクト
見出し・コードブロック・リスト・添付を含む説明本文まるごと
ラベルと期日をフロントマターとして
コメントスレッドを投稿順に、コメントごとの投稿者＋タイムスタンプ付きで
リアクションをインラインで（例：[:tada: × 3]）
リンクされたイシュー（親／子／blocks／blocked-by）をMarkdownリンクとして
添付ファイル（画像、リンクされたドキュメント）をMarkdownの参照として

Minibaseが取り除くもの：

Linearのサイドバー、コマンドバー、キーボードショートカットのヒント
ワークスペースのUI要素とアカウントウィジェット

向いている場面： 記事を書くために数件のイシューを引っぱってくるとき、ポストモーテムのためにインシデントの親イシューと子イシューをすべて抜き出すとき、その場かぎりの単発作業。

方法2：Linear GraphQL API

まとまった量の書き出しや、スクリプトへの組み込みなら LinearのGraphQL API が本筋の道です。

典型的な流れ：

Linear → Settings → API から個人用のAPIキーを作る
https://api.linear.app/graphql に Authorization: <api-key> ヘッダー付きでGraphQLクエリをPOSTする
イシュー、コメント、添付、リンクされたイシューを問い合わせる
レスポンスをたどってMarkdownを出力する

出発点になるクエリ：

query {
  issues(first: 100, filter: { project: { id: { eq: "PROJECT_ID" } } }) {
    nodes {
      identifier
      title
      description
      state { name }
      assignee { name }
      priority
      labels { nodes { name } }
      comments { nodes { body user { name } createdAt } }
    }
  }
}

長所： プログラムから扱え、フィルタとページネーションに対応し、繰り返しの書き出しにぴったりです。

短所： Markdownのシリアライザは自分で書くことになります。大きなプロジェクトではページネーションも必要です。

方法3：Linear CLI（@linear/cli）

Linearは、よく使うGraphQL操作をラップした CLI を提供しています。その場での問い合わせには便利ですが、本格的なMarkdown書き出しにはあまり向きません。

例：

npx @linear/cli issues list --project "Engineering Migration"

出力はプレーンテキストかJSONです。小さなNodeスクリプトや jq ＋テンプレートなどのコンバーターに通してMarkdownにします。

光る場面： さっと済ませたいスクリプト実行、完全な忠実度までは要らないCIジョブ。

方法4：Linear公式のエクスポート

Linear → Settings → Workspace → Export は、現時点ではイシューのCSVを書き出します。表計算での分析には使えますが、Markdownではありません。結局CSVからMarkdownへの変換を自分で書くことになります。

エンジニアリングチームのワークフロー

Linearユーザーのほとんどは、次の3つのどれかに当てはまります。

パターンA：「このイシューをノートに入れたい」

Linearでイシューを開く
ChromeのツールバーでMinibaseをクリック
Markdownファイルがダウンロードに届く → Obsidian／Notion／自分のRAGシステムにドラッグ

パターンB：「今サイクルでクローズしたイシューからリリースノートを作りたい」

GraphQL APIを使います。

query {
  issues(filter: { cycle: { id: { eq: "CYCLE_ID" } }, state: { type: { eq: "completed" } } }) {
    nodes { identifier title description labels { nodes { name } } }
  }
}

これをNodeスクリプトに流し込んで、テンプレート化したMarkdownのチェンジログを出力します。オープンソースの出発点：linear-cli-tools。

パターンC：「関係者向けにプロジェクト全体をMarkdownのアーカイブにしたい」

20件以下なら：Minibaseで1件ずつ手動で（十分速いです）。
100件以上なら：GraphQL APIをスクリプト化しましょう。

AIエージェントがLinearの書き出しに求めるもの

ClaudeやChatGPTに渡して要約させるのが目的なら、次の点が効きます。

イシューの識別子（ENG-1234）を残す — LLMはそれを引用し返す必要がよく出てきます
ステータスの遷移を残す — 単なる「Done」より「Backlog → In Progress → Done を3週間で」のほうがずっと情報量があります
コメントスレッドは時系列でフラットに並べる — 投稿者ごとにまとめないこと
リンク先イシューはIDだけでなくタイトルも入れる — 「blocks ENG-1230（オンボーディング導線の不具合）」は役に立ちますが、「blocks ENG-1230」だけでは何も伝わりません

Minibaseの抽出はこれをすべてすでにやっています。Linearはtier-1でサポートしているサイトで、出力もLLMに食わせる前提で調整されています。

実務的な判断

その場かぎり、1〜10件： Minibase。無料で保存は無制限、Plus（月5.99ドル）でAIテンプレート、履歴の保存、動画の文字起こしが加わります。
定期的なチェンジログ生成： GraphQL APIのスクリプトをCIから実行。
ワークスペース全体のアーカイブ： GraphQL API＋シリアライズ用スクリプトを一度だけ実行。
「Xって先期どこで決めたんだっけ」： 該当イシューをMinibaseで保存し、Claudeに「このスレッドの決定を要約して」と投げる → 5秒で答えが返ります。

Linearは速い。書き出しのほうも速くあるべきです。

MinibaseはどんなウェブページもワンクリックできれいなMarkdownに変換し、AIが検索できるローカル保管庫へ直接保存します。拡張機能は保存無制限で無料。Minibase Plus（月5.99ドル／年34.99ドル）でAIテンプレート、履歴、動画の文字起こしが加わります。minibase.md。