不具合の報告に、管理画面のスクリーンショットをそのまま貼ってしまう。顧客の氏名やメールアドレス、APIキーが写っていたことに気づき、慌てて本文から画像のリンクを消す。これで済んだと思うかもしれませんが、GitHubでは、リンクを消しても画像そのものは消えていない可能性があります。
GitHubのドキュメントのリポジトリ（github/docs）に、2026年11月3日、この点を明記する節が加わりました。本記事では、追加された原文と添付ファイルに関する既存のページから、どこまでの人が見られるのか、貼る前に何を決めておくか、誤って貼ったときに何をするかを整理します。
追加された記述
追加されたのは、「About anonymized URLs」のページの「Removing GitHub-hosted attachments（GitHubがホストする添付ファイルの削除）」という節です。要点は次の4つです。
github.com/user-attachments/の下に置かれたファイルや画像は、それを参照しているコメントやプルリクエストの説明文とは別に存在する- Issueのコメントやプルリクエストの説明文からリンクを消しても、アップロードしたファイルが削除されるとは限らない。プルリクエストの説明文を編集中にアップロードした画像は、保存する前に消しても残っている可能性がある
- 添付ファイルの削除については、GitHubのサポートに問い合わせる。元のURLが分からなくても、サポートが削除を手伝える場合がある。削除されたあとは、そのURLは404エラーを返すはず
- 添付ファイルの削除は、外部画像を中継するCamoのキャッシュの消去とは別のもの
「保存する前に消しても残る」という一文が重要です。原文が例に挙げているのはプルリクエストの説明文ですが、添付のページ（「Attaching files」）には、ファイルを添付すると、すぐにGitHubへアップロードされ、入力欄が匿名化されたURLに書き換わる、とあります。Issueのコメント欄でも、貼った時点でアップロードは済んでいると読めます。投稿をやめても、ファイルが残る可能性を考えておく必要があります。
誰が見られるのか
添付のページ（「Attaching files」）の冒頭には、見られる範囲についての注記があります。原文は「For public repositories, uploaded files can be accessed without authentication. In the case of private and internal repositories, only people with access to the repository can view the uploaded files.」です。
| リポジトリの種類 | アップロードしたファイルを見られる人 |
|---|---|
| 公開（public） | 認証なしで誰でもアクセスできる |
| 非公開（private）・内部（internal） | リポジトリにアクセスできる人だけ |
この注記と、前の節の「リンクを消してもファイルが削除されるとは限らない」を合わせると、公開リポジトリに貼ったファイルは、本文からリンクを消しても、削除されるまではURLを知っている人が認証なしで開ける状態が続きうる、と読めます（編集部の解釈で、試してはいません）。非公開のリポジトリでも、見られる範囲は「そのリポジトリにアクセスできる人」です。協力会社の担当者や、外部のコラボレーターを招いているリポジトリでは、その人たちも含まれます。
なお、「About anonymized URLs」のページには、「Anyone who receives your anonymized URL, directly or indirectly, may view your image or video.」（匿名化されたURLを直接・間接に受け取った人は、誰でもその画像や動画を見られる可能性がある）という一文もあります。非公開のリポジトリに貼った添付ファイルのURLを、アクセス権のない人が開けるのかどうかについて、2つのページの書き方はそろっていません。本記事では試しておらず、どちらが当てはまるかは確かめていません。URLが外に渡った可能性があるなら、非公開のリポジトリでも見られた前提で考えるほうが安全です。
貼れるファイルは画像だけではありません。添付のページには、PDF、WordやExcelなどのOfficeの文書、CSV、ログ、JSONなども、Issue・プルリクエスト・Discussionsのコメントに添付できると書かれています。大きさの上限は、画像とGIFが10MB、そのほかのファイルが25MBなどです。顧客から受け取った資料や、本番のログを「とりあえず添付」できてしまう、ということでもあります。
また、GitHub CLIでは gh issue comment や gh pr create などに --attach を付けると、手元の画像や動画をアップロードして本文に埋め込めます（リポジトリへのpush権限が必要）。コマンドを実行するAIエージェントに作業を任せている場合、画面のキャプチャを自動で添付する流れも作れるため、何を添付してよいかの決めごとは人だけの問題ではなくなっています。
貼る前に決めておくこと
ここからは、上の原文をもとにした編集部の提案です。GitHubで実際に添付と削除の依頼を試したわけではありません。
顧客のデータが写った画面は貼らない、を原則にする。 不具合の再現には、検証用のアカウントとダミーのデータで撮り直した画面を使います。どうしても本番の画面が必要なときは、氏名・メールアドレス・IDなどを塗りつぶしてから保存した画像を使います。塗りつぶしの前の画像を一度でも貼ると、それがアップロードされる点に注意します。
公開リポジトリと非公開リポジトリで扱いを分ける。 オープンソースとして公開しているリポジトリのIssueには、利用者からの報告も集まります。報告のテンプレートに「個人情報や鍵が写った画像を貼らないこと」と書いておき、受け付ける側も、貼られていた場合の対応を決めておきます。
資料はGitHubではなく、権限を管理できる場所に置く。 顧客から受け取った仕様書や、本番のログの抜粋は、アクセス権を個別に管理できる共有ドライブなどに置き、Issueにはその場所だけを書く運用にします。プロジェクトが終わったときに、外部の人の権限をまとめて外せるからです。
AIエージェントの添付も、同じ規則の対象にする。 エージェントに gh を使わせる場合は、--attach を使ってよいリポジトリや、添付してよいファイルの種類を決め、指示ファイルに書いておきます。
鍵や認証情報がコードに入り込む経路とその点検の方法は、ソースコードのシークレット監査の記事で扱いました。CIのログに鍵が出た場合の検出は、Actionsのログのシークレットスキャンの記事を参照してください。
誤って貼ってしまったときの手順
公式に書かれているのは、「削除についてGitHubのサポートに問い合わせる（元のURLが分からなくても手伝える場合がある）」「削除後はURLが404を返すはず」の2点です。これに、編集部が勧める確認を加えると、次の順になります。
- 本文のリンクを消す前に、画像やファイルのURL（
github.com/user-attachments/で始まるもの）を控える。原文では、URLが分からなくてもサポートが手伝える場合があるとされていますが、分かっているほうが話は早いはずです - 写っていたものが鍵やパスワードなら、削除を待たずに発行元で無効化する。削除の前に誰かが見た可能性は消せないためです
- 本文やコメントからリンクを消し、GitHubのサポートに添付ファイルの削除について問い合わせる
- 削除されたと分かったら、控えたURLが404を返すことを確かめる（原文の表現は「404エラーを返すはず」）
- 個人情報が写っていた場合は、社内の手順に沿って、影響の範囲（公開か非公開か、アクセスできた人、URLを渡した先）を記録する
「リンクを消したから大丈夫」と判断しないこと。これが、今回の追記から読み取れる要点です。
確認した範囲
2026年11月9日に、github/docsのコミット 398255c（2026年11月3日、「Document removal requests for GitHub-hosted attachments」）の差分と、確認時点（8cd1075、2026年11月6日）の「About anonymized URLs」「Attaching files」「Attaching files with GitHub CLI」の原稿を確認しました（資料調査）。2026年11月11日に、docs.github.comの公開ページ3つと最新の原稿（7c3387d）を開き、本記事で引いた記述が変わっていないことを確かめました。同じ日に GitHub Changelog（10月28日〜11月11日）も見ましたが、添付ファイルの削除に関する告知はありませんでした。GitHub上での添付、リンクの削除、サポートへの問い合わせは試していません。「About anonymized URLs」のページの対象は、GitHub.comとGitHub Enterprise Cloudです（GitHub Enterprise Serverは対象外）。
協力会社と進める開発での情報の扱いや、リポジトリの権限の整理は、グリームハブの開発・AI・自動化のご相談で承っています。体制や取引先との約束によって決めることが変わるため、お問い合わせからご相談ください。
