Claude Code コネクターチュートリアル：GitHub リポジトリを20分でトリアージ

このチュートリアルでは、Claude コネクター（Model Context Protocol 上に構築）を使って Claude Code を GitHub に接続し、オープンソースのリポジトリをエンドツーエンドでトリアージする方法を紹介します。 

このワークフローでは何もクローンせず、ベクターストアも不要で、対象リポジトリの行には一切触れません。代わりに、Claude Code はコネクター経由で課題を読み取り、成果物をローカルファイルシステムに書き出します。投稿するかどうかは、その内容を確認してから判断します。

このチュートリアルの終わりには、次のものが得られます。

• 読み取り専用トークンによる、Claude Code と GitHub MCP の動作環境
• 任意の公開リポジトリに対して使用できる再利用可能なプロンプト
• 比較用の langchain-ai/langchain 向け完全なトリアージ成果物

Claude Code GitHub コネクター（MCP）とは？

Claude Code は Anthropic のターミナル型コーディングエージェントです。 

標準でファイルシステム、シェル、git に対応しています。Claude Code コネクターはそれを拡張し、ターミナル単体では扱えない GitHub の課題、Linear のチケット、Slack メッセージ、Postgres のクエリなど、外部コンテキストへアクセスできるようにします。

コネクターのプロトコルは MCP（Model Context Protocol） と呼ばれ、LLM エージェントにツールやデータを公開するためのオープンスタンダードです。 

Anthropic はすぐに使えるコネクターのディレクトリを提供しており、自作やサードパーティの MCP サーバーにも接続できます。

本チュートリアルでは、Docker でローカル実行する公式の GitHub MCP サーバー を使用します。セットアップの基本的な考え方は次のとおりです。

• クラウドの仲介なしにローカルの Docker コンテナとして実行されるため、認証情報はPCの中に留まります。
• 標準の GitHub Personal Access Token（PAT）で認証するため、OAuth アプリの登録は不要です。
• スコープ付き権限に対応しており、無スコープ PAT なら公開リポジトリの読み取り専用アクセスとなるため、GitHub API レベルで書き込みは不可能です。
• claude mcp add コマンドで Claude Code に公開すると、以降すべてのセッションでツールが利用可能になります。

オープンソースのトリアージは読み取りが多く、判断が重要で、間違ってもコストは低い作業です。 

50件の課題を読み込み、クラスタリングするのは人間には退屈ですが、すべてを一度に文脈に保持できるモデルには適しています。 

また、出力はまずローカルファイルとして書き出します。誤ったクラスタや拙い下書きでもコストはかからず、レビューで検知できます。

Claude Code GitHub コネクターチュートリアル：langchain-ai/langchain をトリアージ

このセクションでは、Claude Code で GitHub コネクターを設定し、langchain-ai/langchain に対して4つのトリアージプロンプトを実行します。これは大規模な ML リポジトリで、課題トラッカーが本当に混沌としています。概要として、次のことを行います。

• Docker 上で稼働する公式 MCP サーバー経由で Claude Code を GitHub に接続する
• ゼロスコープ PAT を使い、設計上読み取り専用のコネクターにする
• 結果をローカルファイルに保存するトリアージプロンプトを実行する
• 出力をレビューし、Claude が重複としてのクラスタリングを拒否したケースも確認する

それでは段階的に進めていきます。

ステップ1：Claude Code と Docker の前提条件をインストール

コネクターを設定する前に、次の3つが必要です。

• Claude Code：Anthropic の公式インストールガイドからインストール
• Docker Desktop：公式の GitHub MCP サーバーはコンテナで動くため、Docker をインストールして起動しておく
• GitHub アカウント：次のステップで PAT を作成するために必要

前提条件がそろったら、Docker が稼働しているか確認します：

docker info | head -5

Docker がインストールされていない、またはデーモンが起動していない場合は、"Cannot connect to the Docker daemon" エラーが表示されます。macOS の場合、Docker Desktop を次で起動します：

open -a Docker

Docker Desktop は完全に準備が整うまで15〜60秒かかり、その間は docker info がエラーを返し続けます。手動で確認する代わりに、デーモンが上がるまでポーリングする簡単なワンライナーを使いましょう：

until 

docker info >/dev/null 2>&1; do sleep 2; echo "waiting..."; done && echo "Docker ready"

Docker ready と表示されたら、次に進めます。

ステップ2：読み取り専用の GitHub トークンを作成

Docker の準備ができたら、github.com/settings/tokens に移動して、新しい classic トークンを作成します。

注意：スコープはすべて未選択のままにします。無スコープのトークンでも GitHub API を通じて公開リポジトリの読み取りが可能で、今回のエージェントに必要なのはそれだけです。スコープを一切選択していない場合、GitHub 上での書き込み・変更・削除は不可能で、Claude に何を指示しても実行されません。これはエージェントの挙動に関する約束ではなく、GitHub 側で強制されるハードな保証です。

トークンを生成したらすぐにコピーして保存し、シェルでエクスポートします：

export GITHUB_PERSONAL_ACCESS_TOKEN="ghp_your_token_here"

すでに Claude Code セッション内にいる場合、! プレフィックスでエクスポートコマンドを直接シェルで実行（例：! export GITHUB_PERSONAL_ACCESS_TOKEN="..."）したくなるかもしれません。 

しかし、! は一時的なサブシェルを起動するため、コマンド終了とともに変数は消え、Claude からは見えなくなります。

トークンをモデルのプロンプトに貼り付けず安全に設定するには、次のいずれかを行ってください：

1. /exit と入力して Claude を終了し、通常のターミナルでエクスポートコマンドを実行してから、claude を再起動する。
2. または、作業ディレクトリに .env ファイルとしてトークンを保存します。Claude Code は起動時に自動で読み込みます。

トークン自体を表示せず、両方の前提条件が整っているか確認します：

docker info | head -3
echo "Token set: ${GITHUB_PERSONAL_ACCESS_TOKEN:+yes}"

2つ目のコマンドは変数が存在すれば Token set: yes、空であれば Token set: （コロンの後は空） と表示します。 

これはトークンを直接 echo するより安全で、平文がシェル履歴に残る心配がありません。

ステップ3：GitHub コネクターを Claude Code に登録

公式の GitHub MCP サーバーは Docker イメージとして提供されています。 

これを claude mcp add で Claude Code に登録します：

claude mcp add github \
  -e GITHUB_PERSONAL_ACCESS_TOKEN=$GITHUB_PERSONAL_ACCESS_TOKEN \
  -- docker run -i --rm \
  -e GITHUB_PERSONAL_ACCESS_TOKEN \
  ghcr.io/github/github-mcp-server

ここで -e が2つあるのは誤りではありません：

• 最初の -e（-- の前）は、Claude Code が起動する MCP プロセスに環境変数を設定します。
• 2つ目の -e（docker run の引数内）は、その変数をコンテナにフォワードするよう Docker に指示します。

どちらかが欠けてトークンが空のままコンテナが起動すると、GitHub API に対する認証に失敗します。

コネクターが正しく登録されたか確認します：

claude mcp list

次のように表示されるはずです：

github — docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/github/github-mcp-server —  Connected

もし Failed to connect と出たら、よくある原因は Docker が動いていないか、GITHUB_PERSONAL_ACCESS_TOKEN を claude mcp add を実行したのと同じシェルでエクスポートしていないことです。

ステップ4：接続をサニティチェック

GitHub トークンの設定ができたら、作業ディレクトリを作成し、Claude Code の CLI を開きます：

mkdir demo && cd demo
claude

claude コマンドは、現在のディレクトリで対話セッションを起動します。 

トリアージ中に Claude が書き出すファイルは、ここに保存されます。 

次に、コネクターが使われているか確認するため、読み取り専用の簡単な質問をします：

Using the GitHub MCP connector, fetch the 5 most recently updated open issues in langchain-ai/langchain. Just list titles and numbers.

Claude Code が GitHub ツールを初めて使用する際は、承認を求められます。 

読み取り専用の list_issues、get_issue、search_issues などを承認してください。 

もし Claude が MCP ツールではなく公開 GitHub API に対する curl にフォールバックしているなら、コネクターが読み込まれていません。セッションを終了して再起動してください。

成功すると、次のような結果が返ります：

MCP 経由で実際の課題番号が返ってきたら、実際のトリアージを実行する準備は完了です。

ステップ5：バックログの要約を生成

ウォームアップ作業は完全に読み取り専用です。何かをする前に、まず課題トラッカーの全体像を把握します。

Prompt:
Using the GitHub MCP connector, pull the 50 most recently updated open issues from langchain-ai/langchain. 
Read their titles, bodies, and labels. Group them by likely area — bugs, feature requests, documentation, questions, and "needs more info." 
For each group, give me a count and 3-5 representative issue numbers with a one-line reason. Save as backlog-summary.md in the current directory.

Claude Code はコネクター経由で課題を取得し、読み込んだうえで、代表的な課題番号とともに分野ごとにグループ化した Markdown ファイルを書き出します。このファイルだけでも、メンテナーは1分で流し読みして、その週にどんな状況か把握できます。

ステップ6：重複候補にフラグを付ける

重複検出こそ、エージェントが真価を発揮する場面です。 

50件の課題を端から端まで読み、根本問題でクラスタリングするのは人間には面倒ですが、モデルなら全件を文脈に保持して、キーワード検索では見逃す重なりを見つけられます。

Prompt:
From the same 50 issues you already pulled, identify clusters of likely duplicates: issues describing the same underlying problem, even if titles differ. For each cluster, output issue numbers, a one-sentence shared-problem description, and confidence (high/medium/low). Save as duplicate-candidates.md.

私の実行では、Claude は実際に次のような結果を出しました：

最も興味深いのは、クラスター2〜4です。 

単純なキーワードベースの重複検出器なら、4つすべてを重複としてクローズしていたでしょう。 

しかし Claude は、それらを重複と断定することを明確に拒否しました。 

同一のサブシステムを持ちながら根本原因が異なるコンポーネントのクラスターとしてフラグを立て、どれを実際にクローズすべきか（クラスター1のみ）と、どれを一括トリアージしつつオープンのままにすべきかを示しました。

これは慎重な人間のトリアージ担当者に期待する振る舞いであり、ローカルファイルに出力してからレビューするパターンが一手間かける価値のある理由です。 

もしこれを GitHub の API に直結して、Claude のフラグどおり自動クローズしていたら、実在する3件のバグを閉じてしまっていたはずです。

ステップ7：レビューして、投稿可否を決める

これこそがローカルファイル方式の肝です。 

GitHub に何かが触れる前に、Claude が保存した各 .md ファイルを確認し、グルーピングが自分の感覚に合っているかチェックしてください。 

高信頼のクラスターは本当に重複に見えますか？ 下書きの返信を2〜3件読み、文体が自分らしいか確認しましょう。

実際にコメントを投稿したりラベルを適用したい場合は、次の2つの選択肢があります：

• 手動：下書きを自分で GitHub に貼り付けます。よそのリポジトリを単発でトリアージするなら、これで十分かつ適切なことが多いです。
• 自分のリポジトリで書き込みを許可：リポジトリスコープ付きの別 PAT を発行し、（例：github-write のように）個別のコネクターエントリとして追加。プロンプトを再実行して、Claude にラベル適用やコメント投稿を指示します。Claude Code は初回の各書き込みツール使用時に承認を求めます。

書き込み経路における重要な安全策は、読み取り用と書き込み用のトークンを分けておくことです。 

まとめ

このチュートリアルでは、MCP 経由で Claude Code を GitHub に接続し、実在のオープンソースリポジトリをエンドツーエンドでトリアージする方法を紹介しました。 

独自の GitHub ボットや Webhook を作る代わりに、公式 GitHub MCP サーバー経由で課題を読み取り、4つのトリアージ成果物をローカルファイルとして書き出し、投稿前にすべてをレビューできます。

より広い示唆として、コネクターは Claude Code を「コーディングエージェント」から、「手元のツールを読み取り、レビュー用の下準備をしてくれる道具」へと変えます。 

既定では、その作業を自分で目を通すまでローカルに留め、パターンを信頼できると思えたら、ミスのコストが低い範囲でエージェントに行動を任せるのがよいでしょう。

ここからは、次のような拡張が考えられます：

• 自分のリポジトリに書き込み可能なコネクターを追加し、レビュー後にラベルやコメントを自動適用
• Linear や Slack のコネクターを連携し、トリアージ結果をチームのワークフローに同期
• プロンプトを定期実行する CI ジョブ化し、毎週のトリアージ PR を作成
• 上記プロンプトを一般化して、任意のリポジトリ URL で動く再利用可能な Claude Code のスラッシュコマンドにする