GitHubのリポジトリ・Issue・PRをMarkdownで保存する方法(2026年版)

·

GitHubのコンテンツはREADME、Issue、PR、Discussion、Gistに分散しており --- Markdown形式でなければ、それらをLLMに渡すのは面倒です。READMEはすでにそこにありますが、実際に必要なのは80件のコメントが付いたIssueスレッドで誰かがようやく回避策を見つけた箇所だったり、Breaking Changeが説明されたPRだったり、なぜそのAPIがそう設計されたのかを説明するDiscussionだったりします。それらはどれも、Claudeの使えるコンテキストになるまで1クリックでは届きません。

このガイドでは、GitHubコンテンツをクリーンなMarkdownに変換するあらゆる方法を扱います --- 単一のREADMEから長いPRのディスカッション、リポジトリ全体まで。

なぜGitHubのコンテンツをMarkdownで保存するのか?

Markdownは、コードに関する知識を持っていきたいあらゆる場所で機能する形式です:

  • LLMに渡す --- Claude、ChatGPT、Gemini、ローカルモデルはすべてMarkdownをコンテキストとしてネイティブに読み込み、コードブロックと言語識別子は保持されます
  • ObsidianやNotionに入れる --- Issueやリポジトリごとに1ファイル、完全に検索可能で、見出しも正しく付与されます
  • スレッドがロック・削除される前にアーカイブする --- メンテナはIssueをクローズし、リポジトリはプライベート化され、あなたのノートはGitHubの稼働状況に依存すべきではありません
  • オフラインドキュメントを構築する --- 複数リポジトリのREADMEをまとめて1つのリファレンスにする
  • 長いスレッド内の特定コメントを引用する --- 200件のコメントが付いたIssueの中で唯一役立った返信に戻るのは検索1回で済みます

2026年にGitHubからMarkdownへのトラフィックを最も牽引しているユースケースは1つ目です:開発者はライブラリ、バグ、設計判断についてLLMに質問したいが、URLを貼り付けてもモデルが必要とするものは渡せません。

方法1:Save(最速、ワンクリック)

SaveはChrome拡張機能で、GitHubの任意のページをワンクリックでMarkdownファイルに変換します。レンダリングされたページを読み取り、可能な限り元のMarkdownを再構築し、Claude、Obsidian、ドキュメントフォルダにそのまま落とせるものを生成します。

動作のしくみ:

  1. ChromeでGitHubのページを開く --- リポジトリ、Issue、PR、Discussion、Gist、Wiki
  2. ツールバーのSave拡張機能アイコンをクリック
  3. .mdファイルが即座にダウンロードされる(Save Vaultを接続していればそこに保存)

得られるもの:

  • コードブロック、テーブル、見出しがそのままのREADME
  • IssueとPRのタイトル、本文、ステータス、スレッド化されたコメント
  • 正しいネスト構造のDiscussionスレッド
  • 参照リンクされたIssueと@mentionsが保持される
  • ラベル、マイルストーン、担当者がフロントマターに
  • コードブロックは言語識別子を保持(Markdownビューアでシンタックスハイライトが効く)
  • Gist(単一ファイル・複数ファイル)サポート
  • リポジトリ、作者、日付、URL、ステート(open/closed/merged)を含むフロントマター

取り除かれるもの:

  • GitHubのナビゲーション、サイドバー、フッター
  • 各コメント下のリアクション絵文字行
  • 「X hidden items」の折りたたみ(Saveは展開して含める)
  • CI、dependabot、stale-botからのBotコメント(切り替え可能)
  • 前のコメントを繰り返すだけのquote-reply

最適な用途: AIでデバッグする開発者、ドキュメントをまとめるテクニカルライター、スレッドをアーカイブする研究者、ライブラリが実際にどう動くかについて個人ナレッジベースを構築したい人。Claudeに貼り付けたりObsidianで読んだりするためのクリーンなMarkdownが必要なら、これが最もクリーンな経路です。

出力例

Issueスレッドを保存すると、以下のような出力が得られます:

---
title: "Memory leak when using streaming with large responses"
repo: anthropics/anthropic-sdk-python
number: 412
author: alice-dev
state: closed
labels: ["bug", "streaming", "memory"]
assignees: ["bob-maintainer"]
milestone: "v0.34.0"
created: 2026-03-12
closed: 2026-03-18
url: https://github.com/anthropics/anthropic-sdk-python/issues/412
---

## Issue

When streaming responses larger than ~50MB, memory grows linearly and is
never released. Reproduced on Python 3.11 and 3.12, macOS and Linux.

**Reproduction:**

\`\`\`python
from anthropic import Anthropic

client = Anthropic()
with client.messages.stream(...) as stream:
    for text in stream.text_stream:
        print(text, end="")
\`\`\`

After the loop ends, `tracemalloc` shows the buffer is still resident.

## Comments

### bob-maintainer (maintainer) --- 2026-03-13

Confirmed. The internal buffer in `_streaming.py` isn't being cleared on
context exit. Looking at it now.

### alice-dev --- 2026-03-14

Thanks. Workaround for anyone hitting this: call `stream.close()`
explicitly before the `with` block exits. References #389.

### bob-maintainer (maintainer) --- 2026-03-18

Fixed in #418, released in v0.34.0. Closing.

このファイルは貼り付けひとつでClaudeのコンテキストとして使え、キー入力ひとつで永続的なObsidianノートになります。

方法2:GitHub API + スクリプト

GitHubのREST APIとGraphQL APIはすべてを公開しています --- README、Issue、コメント、PRのdiff。取得して変換するスクリプトを書けます。

gh api repos/OWNER/REPO/issues/412 --jq '.body' > issue-412.md
gh api repos/OWNER/REPO/issues/412/comments --jq '.[].body' >> issue-412.md

最適な用途: ドキュメンテーションパイプラインを構築するエンジニアリングチーム、複数リポジトリ間でIssueやPRを一括エクスポートするスクリプトを書く人。

このアプローチの問題:

  • APIは生のMarkdown本文を返しますが、タイトル + 本文 + コメント + メタデータを読みやすい1ファイルにまとめるのはあなたの仕事
  • フロントマター(ラベル、マイルストーン、担当者、ステート)には複数のAPIコールと手動の組み立てが必要
  • コメントの順序、作者の帰属、ネストされた返信チェーンにはカスタムロジックが必要
  • 大規模リポジトリではレート制限にすぐ達する(認証済みで5,000リクエスト/時)
  • DiscussionはREST APIではなくGraphQL APIの背後にあるため、スクリプトは2つのパイプラインに
  • PR diffとレビューコメントはまた別のエンドポイント

これはパイプラインを構築する場合の正しい方法です。単一のIssueにはやりすぎです。

方法3:Clone + ローカル変換(リポジトリ全体向け)

READMEとリポジトリ内のドキュメントについては、最もシンプルな方法はクローンしてファイルを直接読むこと --- ディスク上ですでにMarkdownです。

git clone https://github.com/OWNER/REPO.git
cd REPO
cat README.md docs/*.md > combined.md

最適な用途: リポジトリのドキュメントへのオフラインアクセスが欲しい開発者、ドキュメント全体のツリーをロングコンテキストLLMに渡す必要がある人。

このアプローチの問題:

  • リポジトリに保存されたコンテンツ(README、/docs、別途クローンしたWiki)にしか機能しない
  • Issue、PR、Discussionは取れない --- それらはGitHubのデータベースに存在し、Gitツリーには存在しない
  • ドキュメントとIssue間のクロスリファレンスが壊れる(#412はローカルでは解決されない)
  • READMEの画像URLはuser-attachments.githubusercontent.comを指していることが多く、オフライン用途では書き換えが必要
  • 1ファイルにしたければ、結合とクリーンアップのスクリプトが依然必要

「ドキュメントをオフラインで欲しい」には十分。「この80コメントのIssueスレッドが欲しい」には間違ったツール。

方法4:ブラウザから手動コピー

力技:ページを開いてすべて選択し、Markdownエディタに貼り付けて整える。

手順:

  1. ブラウザでIssueまたはPRを開く
  2. 関連するセクション(またはページ全体)を選択
  3. Obsidian、VS Code、または別のMarkdownエディタに貼り付け
  4. UIノイズ(リアクション、ナビ、サイドバー)を手で除去
  5. コードフェンスを再度追加、コメント順を修正、フロントマターを追加

このアプローチの問題:

  • コードブロックは言語識別子とシンタックスハイライトを失う
  • コメントの著者とタイムスタンプは構造化フロントマターではなく自由形式テキストになる
  • READMEのテーブルはタブ区切りのプレーンテキストとして貼り付けられることが多い
  • リアクション行(+1 heart rocket)が本文に漏れ出る
  • スレッド化されたDiscussionのネストがフラットテキストに崩れる
  • 長いスレッドで10分かかる ; 保存するIssueの数だけかかる

短いREADMEには機能。実際のIssueスレッドでは破綻。

どの方法を使うべき?

シナリオベストな方法
IssueやPRをClaudeに貼り付けSave --- ワンクリック、構造化された出力
長いDiscussionスレッドをアーカイブSave --- ネスト構造とメタデータが保持される
リポジトリのドキュメントのオフラインコピーを作るgit clone --- READMEはすでにMarkdown
多数のリポジトリでIssueを一括エクスポートGitHub API + スクリプト --- プログラマティック
単一のREADMEを素早く保存Save --- cloneステップをスキップ
個人ノート用の単発のクイックリファレンス手動コピー --- 短いページなら機能

ほとんどの開発者にとって --- 特にGitHubコンテンツをAIコンテキストとして使う人にとって --- Saveが答えです。セットアップゼロで最もクリーンなMarkdownを生成し、長いIssueスレッドをREADMEと同じ速度で扱います。

Saveが扱うエッジケース

  • プライベートリポジトリ。 Saveはログイン済みブラウザセッションを使います。あなたのGitHubアカウントがリポジトリを見られるなら、Saveも読めます。APIトークンの設定不要。
  • セルフホスト型GitHub Enterprise。 あらゆるgithub.*ドメインパターンで動作。Saveはレンダリングされたページを読むので、UIがGitHub標準レイアウトである限り変換は機能します。
  • GitHub DiscussionsとIssue。 どちらもサポート。Discussionはカテゴリーをフロントマターに(category: Q&Acategory: Announcements)、ネストされた返信はスレッド構造として取得します。
  • PRのdiffとファイル変更。 関連する場合は保持。PRの本文、レビューコメント、ファイル単位の会話を含めます。生のdiff自体は丸投げではなく要約 --- LLMコンテキストに5,000行のdiffは普通要りません。
  • リアクション絵文字行。 除去。各コメント下の+1heartrocket行はトレンド分析以外ノイズです。
  • 非常に長いIssueスレッド。 何百ものコメントを持つスレッドでは、SaveはIssue本文、メンテナのレスポンス、解決コメント、「Other comments: N omitted」マーカーを保持。すべての返信が必要なら全件含めに切り替え可能。
  • Wikiページ。 リポジトリWikiはサポート。各ページは1つのMarkdownファイルになり、内部Wikiリンクは相対パスに書き換えられます。
  • プロジェクトボード。 プロジェクトボードビューは構造化リストとしてキャプチャ:カラム → カードタイトル → リンクされたIssue/PR。スプリントを閉じる前にアーカイブするのに便利。
  • Botコメント。 Dependabot、stale-bot、CodeQL、GitHub Actions --- すべて検出され切り替え可能。ほぼ常にノイズを増やすのでデフォルトはオフ。
  • 言語識別子付きコードブロック。 トリプルバッククォートの言語タグ(```python```rust)は保持され、MarkdownレンダラーやLLMはシンタックスハイライトのヒントを得られます。
  • Gist。 単一ファイルと複数ファイルのGistはどちらもサポート。複数ファイルのGistは、各ファイルがセクションとして並ぶ1つのMarkdownファイルになります。

あなたのワークフローと組み合わせる

Markdown出力は必要なところで機能します:

  • Claude / ChatGPT / Gemini --- ファイルを貼り付け、「なぜこのIssueはクローズされた?」や「このPRの設計判断を要約して」と聞く
  • Obsidian --- vaultに入れ、Issueを関連ノートにリンクし、保存したすべてのライブラリを横断検索
  • Notion --- 直接貼り付け、見出し、テーブル、コードブロックが正しくレンダリングされる
  • Cursor / Claude Code --- ファイルをプロジェクトに入れる、修正提案時にAIは上流コンテキストを持つようになる
  • Save Vault --- 接続していれば、すべてのGitHub保存はリポジトリをタグに、他の保存済みスレッドへのバックリンク付きで自動でそこに着地します

FAQ

Saveはプライベートリポジトリで機能しますか? はい。ログイン済みブラウザセッションを使うため、あなたのGitHubアカウントが見られるものはすべてSaveが保存できます。PATやOAuthの設定不要。

GitHub Enterprise(セルフホスト)で機能しますか? はい。ドメインに関係なくあらゆるGitHub UIをサポートします。会社でgithub.acme-corp.comを運用していれば、そこでもSaveは機能します。

500コメントのスレッドのすべてのコメントをキャプチャしますか? デフォルトでは、SaveはIssue本文、メンテナのレスポンス、解決を保持します。スレッド全体を取得するには、保存前に拡張機能メニューで「Include all comments」を切り替えてください。

コードブロックは正しくフォーマットされますか? はい。トリプルバッククォートのフェンスと言語識別子は正確に保持されます。```python```pythonのままなので、LLMやMarkdownビューアはシンタックスハイライトを得られます。

PR diffを扱いますか? PR本文、レビューコメント、ファイル内インライン会話を含めます。生のdiffはまるごと投げ込むのではなくファイル単位で要約 --- 通常LLMコンテキスト用に望むものです。完全なパッチが必要なら「Include raw diff」を切り替えてください。

GitHub Discussionsはどうですか? 完全サポート。カテゴリ、ネストされた返信、回答済みマーキング、すべて構造化Markdownとして取得されます。

@mentionsとクロスリファレンスは保持されますか? はい。@usernameのメンションはプレーンテキストのメンションとして残り、#123のIssue参照もそのまま保持されます。GitHubへのハイパーリンクにしたければ、保存時に拡張機能で書き換え可能です。

GitHubのモバイルサイトで機能しますか? 拡張機能はChromeデスクトップ専用です。モバイルではURLをコピーしてデスクトップで開くか、MacのSave Vaultに共有してください。

料金はいくらですか? Saveには無料枠があり、いくつかのリポジトリやIssueで試せます。それ以上は、小額のサブスクリプションでより多くの使用をカバーします。

関連するSaveガイド

## Continue reading

Jean-Sébastien Wallez

Written by

Jean-Sébastien Wallez

I've been making internet products for 10+ years. Built Save on weekends because I wanted my own reading library in clean markdown for Claude and Obsidian. Write here about web clipping, AI workflows, and the small things that make a personal knowledge base actually useful.

## try save

よりスマートに保存しませんか?

あらゆるウェブページをワンクリックでMarkdownに変換。

Chromeに追加 🐿️