ClaudeのGitHub連携が使えないときの原因と対処法
GitHub連携でリポジトリを追加しても中身が読み取れない不具合について、発生時期・影響範囲・コミュニティで報告されている回避策を一次ソースからまとめます。
claude.aiの「Add content from GitHub」機能でリポジトリを追加しても、Claudeがファイルの中身を一切読めない不具合が2026年6月末から報告され続けています。接続そのものはUI上「成功」した見た目になるため、原因を切り分けにくいのが厄介な点です。GitHub Issueに集まった一次情報から、症状・影響範囲・コミュニティが試している回避策をまとめます。
症状から原因を切り分ける
「GitHub連携が使えない」といっても、実際に起きている症状は一様ではありません。まず次の表で当てはまる症状を確認してください。
| 症状 | 原因 |
|---|---|
| リポジトリピッカーに組織のリポジトリが出てこない | 原因SSO必須の組織で個別の認可がまだ済んでいない。対処はClaude GitHub連携の使い方にまとめています |
| リポジトリのURLを入力しても中身を取得できない | 原因プライベートリポジトリへのアクセス許可がまだ設定されていない。対処はClaude GitHub連携の使い方にまとめています |
| リポジトリの表示・選択自体はできるのに、追加後にClaudeが中身を読めない | 原因本記事が扱う不具合(2026年6月末〜報告) |
前の2つは連携機能そのものの仕様・設定に起因するもので、姉妹記事の手順で解消します。ここから先は3つ目、表示や選択は正常にできているのにClaudeが中身へたどり着けないケースを扱います。
何が起きているのか
GitHub連携は、チャット入力欄の「+」ボタンから「Add from GitHub」を選び、リポジトリとブランチを選んで追加する機能です。不具合が起きている環境では、この操作自体はエラーなく完了します。リポジトリの一覧も正しく表示され、選択も問題なくできます。
ところが、追加したはずのリポジトリについてファイル構成や中身を尋ねても、Claudeは何も参照できません。まるで最初から何も添付していないかのような応答が返ってきます。症状の出方には細かな幅があり、「Add repository」ボタンを押すとリポジトリのURLがそのままメッセージ欄に貼り付くだけになる報告(Hoshea26、0x044)、ファイルブラウザーを開いてもツリーが空のまま何も表示されない報告(dip-del)、ブランチ選択の画面自体が出てこない報告(kni927)が混在しています。表面上の壊れ方は違っても、最終的にClaudeが中身へたどり着けない結果は共通しています。
最初の報告者は、公開・非公開を問わずどのリポジトリ・どのブランチでも100%再現すると説明しています。GitHub Appを一度解除して再認可しても、リポジトリとブランチを選び直しても結果は変わりませんでした。断続的にではなく毎回必ず失敗する点が、個別リポジトリの権限設定に起因する従来型のトラブルとは異なります。
いつから、どの環境で発生しているか
Issue #71542によると、2026年6月19〜20日ごろまでは正常に動作していました。6月25日を境に失敗が始まり、翌26日にIssueが立てられています。特定の日に切り替わっていることから、Anthropic側のバックエンド変更が引き金になったとみられます。
影響はブラウザ版のclaude.aiだけにとどまりません。Claude Desktopアプリでも同じ症状が出るという報告があり、akrumsieg-momentusはmacOS版アプリのバージョン「1.18286.0 (259c3f)」に更新した後もブラウザ側と同様に再現したと述べています。ianlundbergはDesktopアプリとWebアプリの両方で発生したと報告し、Hoshea26はmacOSのデスクトップチャットで発生を確認しています。チャットへの直接追加だけでなく、プロジェクトのナレッジ画面経由で追加した場合にも空の結果しか返らないという報告(WyomingWill、MdRasB)があります。
プランの幅も広く、Freeプラン(Antares9879)、Pro(dip-del)、Max(mhc-services)に加えて、Team・Enterpriseの組織アカウントでも再現が確認されています。pfernandes-nbcは2026年7月24日、Team契約のGitHub組織とEnterprise契約のClaude組織を使った検証結果を報告し、組織レベルの設定がすべて正しく見える状態でも同じ不具合が起きることを示しました。
GitHubのAPI呼び出しは成功しているのに中身が渡らない理由
技術的に手がかりになるのは、ブラウザの開発者ツールでネットワーク通信を確認した報告です。dip-delは、リポジトリを選択した時点でGitHub側へのAPIコールが正常に完了し、ファイルパスやサイズを含むツリー情報が「truncated: false」の状態で取得できていることを確認しました。GitHubからのデータ取得自体は成功しているわけです。
問題はその先にあります。取得できているはずのデータが、実際のチャットのモデルコンテキストには渡っていません。dip-delはこの結果を、GitHub側の認証やAPI呼び出しではなく、フロントエンドからモデルへのデータ受け渡しに不具合があると位置づけています。
pfernandes-nbcのEnterpriseプランでの検証は、この見立てを別の角度から裏づけます。GitHub側の「Authorized GitHub Apps」一覧にはClaudeのエントリが表示されているのに、ステータスは「Never used」のままだったといいます。何度リポジトリを添付し直しても、Claude側からその認可が実際には呼び出されていないことになります。同じ報告では、新しいチャットで接続先が見つからない場合にClaudeがWeb取得(robots.txtでブロック)や未認証のGitHub API(レート制限に抵触)、git clone(認証エラー)を順に試みて失敗する挙動も記録されています。GitHub連携が使えるという前提のフォールバック経路まで一通り失敗する、という点は不具合の根の深さを表しています。
報告されている回避策(公式のサポートではない点に注意)
このIssueには2026年6月26日の起票から9月14日までに62件のコメントが寄せられましたが、すべて利用者からのもので、Anthropic所属を示すアカウントからの返信は見当たりません。公式な修正の発表も確認できていません。以下はいずれもコミュニティが個別に試した結果であり、効果を保証するものではない点に注意してください。
| 状況 | 試されている対処 | 注意点 |
|---|---|---|
| 不具合を運営に確実に届けたい | 試されている対処失敗したチャット内でサムズダウンからフィードバックし、Issue番号を書き添える。またはsupport.anthropic.comからサポートチケットを出す | 注意点利用者の報告では、この経路の方がclaude.aiのプロダクトチームに届きやすいとされる |
| とにかく今すぐ中身を読ませたい | 試されている対処リポジトリをローカルで1ファイルにまとめ、チャットに直接アップロードする | 注意点GitHub連携を経由しないため、この回帰自体の影響を受けない |
| チャットでの追加がだめな場合 | 試されている対処プロジェクトのナレッジ画面から新規プロジェクトを作り、リポジトリを追加し直す | 注意点通った報告(Andysouza24)と通らなかった報告(WyomingWill)の両方があり、再現性は高くない |
| 認可自体を疑っている場合 | 試されている対処Claude側・GitHub側の双方でアプリを完全に解除し、シークレットウィンドウで再認可する | 注意点改善したという報告(ancient-doppler、50回以上試した末とのこと)はあるが、同じ手順で変化がなかった報告も多い |
「1ファイルにまとめる」方法は、repomixのようなリポジトリをテキスト化するツールを使うと簡単です。実際にNeoOne601は、repomixで出力したファイルをアップロードして代替する運用を報告しています。
npx repomixリポジトリのルートで実行すると、ディレクトリ構成とファイル内容をまとめたテキストファイルが生成されます。それをそのままチャットにドラッグ&ドロップすれば、GitHub連携を経由せずに同じ目的を達成できます。ファイルの合計サイズがClaudeのコンテキストウィンドウに収まる範囲であることが前提です。
GitHub連携が本来取得する範囲
前の節で挙げた回避策と合わせて、この連携が本来何を取得する仕組みなのかも確認しておきます。公式ドキュメントによると、取得されるのは指定したブランチのファイル名とファイルの中身だけです。
| 取得される | 取得されない |
|---|---|
| ファイル名 | 取得されないコミット履歴 |
| ファイルの中身 | 取得されないプルリクエスト |
| 選択したブランチの内容 | 取得されないIssueやリポジトリのメタデータ |
公式のFAQでは、リポジトリへのアクセス権を失った場合、それ以降プレビューは表示されなくなる一方、会話履歴自体は残ると説明されています。今回の不具合は、この設計とは別の層で起きています。ピッカーへのリポジトリ表示やGitHub側の認可は正常なのに、選んだ内容がモデルに渡る手前で止まっている状態です。
このIssueが「invalid」のまま動きにくい構造
このIssueにはinvalidラベルが付いています。ラベルの説明は「Issue doesn't seem to be related to Claude Code」、つまりClaude Codeとは関係のない不具合だから、というものです。
報告者自身も本文で明記している通り、これはclaude.aiのWebチャットにおけるGitHub連携の不具合であり、Claude Code CLIの不具合ではありません。ただしIssueが立てられているのはClaude Code用のリポジトリです。コメント欄ではラベルを外して再分類してほしいという要望が繰り返されていますが、9月14日までの範囲では変わっていません。davidhunter-emは、claude.aiのバグはこのリポジトリではなく、失敗したチャット内のフィードバックかsupport.anthropic.comのサポートチケットの方が製品チームに届きやすいと投稿し、Dave-Murray98はアプリ内のヘルプボットにこのIssueへのリンクを送る方法を試したと報告しています。
報告者は本文中で、関連する可能性がある他のIssue番号(#68517、#10647、#33875、#18467、#27155)も挙げています。これらの個別の内容は未確認ですが、同種の症状を訴えるIssueが複数番号にわたって存在すること自体は、報告者自身が本文で明記している事実です。
Claude CodeのGitHub連携・GitHub MCPサーバーとの違い
同じ「GitHubとClaudeをつなぐ」話でも、対象が異なる仕組みが複数あります。混同すると回避策の当たりを外しやすいので、違いを表にまとめます。
| 項目 | Add content from GitHub(本記事の対象) | Claude CodeのGitHub App | GitHub MCPサーバー |
|---|---|---|---|
| 今回のIssueでの言及 | Add content from GitHub(本記事の対象)あり(本記事の対象) | Claude CodeのGitHub Appなし | GitHub MCPサーバーなし |
| 詳しい手順 | Add content from GitHub(本記事の対象)Claude GitHub連携の使い方 | Claude CodeのGitHub AppClaude GitHub Appを導入する手順 | GitHub MCPサーバーGitHub MCPサーバーの使い方 |
Claude CodeのGitHub Appは/install-github-appから導入する別の仕組みで、今回問題になっている「チャットにリポジトリを読ませる」機能とは対象が異なります。今回のIssueにこの仕組みへの言及は見当たりません。
コードを読み書きする用途でGitHubとより深く統合したい場合は、GitHub自身が提供するGitHub MCPサーバーという選択肢もあります。これも今回のIssueで言及されている「Add content from GitHub」とは別の仕組みです。それぞれの導入手順や対象範囲はClaude GitHub Appを導入する手順とGitHub MCPサーバーの使い方にまとめています。Connectors全体の中でGitHub連携がどこに位置するかは、Claude Connectorsとはで扱っています。
まとめ
claude.aiの「Add content from GitHub」でリポジトリの中身が読めない不具合は、2026年6月25日ごろに始まり、9月14日までコメントが積み重なる形で報告が続いています。dip-delのネットワーク通信の観察によれば、GitHub側のAPI呼び出しは成功しているのに、取得した内容がモデルのコンテキストに渡っていません。フロントエンドとモデルの間の受け渡し部分に原因があるとみられます。
公式な修正の発表はまだ確認できません。今すぐコードの中身を読ませたい場合は、リポジトリを1ファイルにまとめてチャットに直接アップロードする方法がGitHub連携を経由しないため試す価値があります。不具合そのものを届けたい場合は、失敗したチャット内のフィードバックか、サポートチケットを通じた報告が有効だという声が複数上がっています。Claude CodeのGitHub App連携やGitHub MCPサーバーは別の仕組みなので、用途に応じて切り替える選択肢として覚えておくと役立ちます。