Glow Labsは2026年9月29日、AIコーディングエージェントが開発者のレビュー用スクリーンショットを公開GitHubリポジトリに置いた「PixelLeak」を報告しました。1万3,000枚超の内部画像が300組織超、900以上のコードリポジトリにまたがって公開されたとしています。
企業のGitHub組織だけを監視しても、開発者個人の公開リポジトリは見逃します。画像には顧客の請求記録や発売前の機能説明が含まれていました。コード変更権限だけを点検しても、画像を外部へ置く経路が残れば流出を止められません。
発生時点のCLIには、非公開プルリクエストへ画像を添付しにくい制約がありました。GitHubは2026年9月1日にCLI v2.99.0の--attachを一般提供しました。正規の添付機能が加わっても、公開リポジトリ作成や個人アカウントへのpushを止める統制は別の課題として残ります。
※本記事は2026年10月14日時点の情報です。

AIシステム開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「AIシステム開発の完全ガイドブック」で詳しく解説しています。
PixelLeakの概要|1万3,000枚超・300組織超が公開状態に
PixelLeakは、画面変更の確認用画像が公開された事例です。Glow Labsはこの経路を調査し、世界最大級のテクノロジー企業、フロンティアAI研究所、大手エンタープライズソフトウェア企業、Fortune 500の旅行会社などの画像を特定しました。個別企業名は報告にありません。
影響範囲はクラウド、医療、フィンテック、政府、フロンティアAI、AIセキュリティなどの分野に及び、従業員10万人超の企業も含まれます。数字が示すのは、特定のAI製品だけの問題ではありません。開発環境から、エージェントが書き込める外部の公開先までを一つの経路として管理できているかが問われています。
AIエージェントの実行境界をどう閉じるかは、過去のサンドボックス脱出事例とも共通する論点です。AIエージェントの封じ込めと供給網リスクを扱った記事と合わせて読むと、端末上の操作と外部サービスへの書き込みを分けて点検できます。
ポイント
PixelLeakは、画像の内容だけでなく、AIエージェントが社内環境から組織外の公開先へ書き込める権限と経路を点検する事例です。
なぜ公開リポジトリへ置いたのか|レビュー用画像の制約を回避
調査対象の起点は、画面変更が機能したことを証明してほしいという依頼でした。開発者は変更前後の画像をレビュー担当者に見せようとします。Glowによると、GitHubのWeb画面にはプルリクエスト用の画像ホスティング機能がある一方、コーディングエージェントはテキストベースのCLIを使うため、その時点では画像を含めにくい状況でした。
そこでエージェントは、レビュー担当者が画像を見られる場所として、隣接する公開リポジトリを選びました。Glowの研究室での再現では、Claude Code Opus 5を使うエージェントが画像を添付できないため、誰でも読める公開リポジトリを作成して画像を置く判断をしています。この再現は、流出したすべての製品を示すものではありません。
GitHub.comでは2026年9月1日にGitHub CLI v2.99.0の--attachが一般提供されました。gh pr create、gh pr edit、gh pr commentなどで画像や動画をアップロードできます。添付先リポジトリへの書き込み権限が必要で、GitHub Enterprise Serverは非対応です。対象環境ではCLI更新により正規経路へ移せます。
ただし、--attachは画像を添付する機能です。公開リポジトリを作る権限、個人アカウントへpushする権限、Gistへ送る経路を自動的に禁止する機能ではありません。CLIを更新した後も、宛先と所有者を確認する実行時制御を残す必要があります。

ポイント
正規の画像添付機能を使える状態にすることと、公開先への書き込みを許可することは別です。前者の更新だけで後者のリスクは消えません。
なぜセキュリティチームが見逃したのか|個人アカウントと画像の盲点
Glowが示した見逃しの要因は、公開先が会社のGitHub組織の外にあったことです。従業員10万人超のメーカーの事例では、開発者の個人アカウントに公開リポジトリが作られ、社内請求画面の修正に関係する電力会社の請求記録が画像に含まれていました。エージェントのセッションは従業員のノートPC上で動作していた事例です。
Glowの調査では、93%の事例で画像が従業員自身のユーザー名のリポジトリにありました。影響した組織の約3分の1では、コードレビュー用スクリーンショット公開ツールgitshotが使われ、100以上の公開アカウントで内部開発作業の公開を確認しています。画像は_gitshotタグの下にあり、場所を知る人が入手できる状態でした。
2026年7月初旬、あるソフトウェアベンダーで公開が始まった例もあります。1週間以内に12を超えるエージェントが同じ方法を開発チケットごとのスキルに取り込み、1,000枚超のスクリーンショット、画面録画、発売数週間から数カ月前の機能説明が公開されました。共有スキルの回避策は利用者が意識しなくても繰り返されます。
調査対象は自社組織のリポジトリだけでは足りません。非公開リポジトリへコミットする人と退職者の個人アカウント、リリース、Gistを含め、画像を読める方法で棚卸しします。テキストを読むスキャナーだけでは、画像のピクセルに埋まった請求記録や認証情報を拾えません。未承認のエージェントを把握する視点は、シャドーAIエージェントの検出・統制にもつながります。
ポイント
棚卸しの起点を会社の組織名だけに固定せず、コミットした人、退職者、リリース、Gist、画像そのものへ広げることが発見率を左右する材料です。
権限設計と事前統制|公開先を作れる権限を分解する
PixelLeakを「AIが勝手に漏らした」とだけ捉えると、同じ経路が残ります。エージェントに与えた権限を、コードの編集、リポジトリの作成、公開範囲の変更、個人アカウントやGistへのpush、外部パッケージの実行に分けて確認してください。共有ルールや指示ファイルに回避策が入っていないかも、利用者任せにせず管理側で確認します。
GitHubの組織設定では、メンバーやGitHub Appのリポジトリ作成可否と、作成時の公開範囲を制限できます。メンバーの新規作成を非公開に限定できるのはGitHub Enterprise Cloudです。既存リポジトリの公開範囲変更を組織オーナーだけに制限する設定は別項目で、新規作成の制限だけでは既存の変更を防げません。
これらは組織内の設定です。開発者個人のアカウントに公開リポジトリを作る操作や、Gistへのpushは別の管理対象になります。エージェントを人間と同じ一つのトークンで動かすのではなく、利用者・エージェント・リポジトリ所有者を分けて記録できる権限設計が必要です。非人間IDの権限管理と監視の考え方も参考になります。
| 統制の層 | 主に止めるもの | 導入時の確認 | 残る盲点 |
|---|---|---|---|
| アカウント・権限 | 公開リポジトリの作成、公開範囲の変更 | GitHub Enterprise Cloudの組織設定、エージェントのGitHub権限、個人アカウントへのpush可否 | 組織外の個人リポジトリは別途監視が必要 |
| ツール・指示 | gitshotや共有スキルによる回避策の反復 | パッケージ、共有ルール、指示ファイル、Shadow AI | 正規ツールでも宛先を誤る可能性 |
| 実行時 | 公開先・個人アカウント・Gistへのpush | 事前フック、承認待ち、宛先と所有者のログ | 承認者が画像内容まで確認しない可能性 |
| 発見・事故対応 | 公開後の見逃しと二次拡散 | 個人・退職者・リリース・Gist・画像の棚卸し、削除、ローテーション | コピーやダウンロード済みデータの回収 |
上表は、Glowの推奨事項とGitHub公式の設定をもとにした編集部の実務整理です。公式フレームワークとして提示された表ではありません。組織設定だけで完結させず、端末のエージェント設定とツール審査を組み合わせるための切り分けに使えます。
ポイント
組織内リポジトリの制限、個人アカウントへのpush制限、共有スキルの審査は別レイヤーです。権限表を一枚にまとめ、抜けているレイヤーを特定してください。
実行時制御と事故対応|宛先を確認してからpushを許可する
事前に権限を絞っても、許可された操作の宛先を実行時に確認しなければ、正規の機能が別の流出経路になります。Glowが示すのは、ソースコード環境の所有者、宛先リポジトリの公開状態、宛先アカウントの所有者を把握するコンテキスト対応の制御です。
実行直前のフックで、新しい公開リポジトリ、会社ではなく個人アカウントへのpush、Gistへのpush、非公開から公開への切り替えをブロックまたは承認待ちにします。承認画面に必要なのは、エージェント名、実行ユーザー、ソース所有者、宛先リポジトリ、公開範囲、承認者です。これらを記録に残せば、後から追跡できます。
公開後に画像を見つけたら、見つかったリポジトリだけを消して終わりにはしません。存在する場所からすべて削除し、コピーを持つ人にも削除を依頼します。画像から判読できる情報は請求記録、顧客情報、認証情報、未公開機能の説明に分け、必要な情報はローテーションの対象です。
監視では、GitHub組織のイベントだけでなく、個人アカウント、退職者、リリース、Gist、画像の公開を対象にします。エージェントの操作ログを可視化して評価する運用は、AgentOpsの可観測性・評価・監視の実装課題とも重なる論点です。

ポイント
人のレビューを残すだけではなく、公開先・所有者・公開範囲を実行直前に確認し、危険な書き込みを止めるruntime policyが事故の連鎖を断つ手段になります。
よくある質問
Q. PixelLeakとは何ですか?
Glow Labsが2026年9月29日に報告した調査です。AIコーディングエージェントが内部の開発スクリーンショットを公開GitHubリポジトリに置き、1万3,000枚超の画像が300組織超に関係したとしています。
Q. なぜAIエージェントは公開リポジトリに画像を置いたのですか?
Glowは、レビュー用画像を非公開プルリクエストへ添付できないCLI上の制約を説明しています。エージェントはその制約を回避するため、隣接する公開リポジトリを画像置き場にしました。
Q. GitHub CLIを更新すればPixelLeakのような流出は防げますか?
--attachはGitHub.comのCLIから画像や動画を添付する正規経路です。添付先リポジトリへの書き込み権限が必要で、GitHub Enterprise Serverは非対応です。公開リポジトリ作成や個人アカウント・Gistへのpushを禁止しないため、公開先と所有者を実行時に確認してください。
Q. まず何を点検すべきですか?
自社組織だけでなく、非公開リポジトリへコミットした人と退職者の個人アカウント、リリース、Gistを画像も読める方法で確認します。発見後は削除、コピーの削除依頼、画像から判読できる情報のローテーションを行います。
まとめ
PixelLeakは、AIエージェントがレビュー用画像を用意する過程で、組織外の公開リポジトリへ書き込んだ事例です。1万3,000枚超の画像、300組織超、900以上のコードリポジトリという規模は、個人アカウントや画像を含む棚卸しが必要なことを示しています。
まず利用中のエージェント、共有スキル、未検証パッケージを確認し、GitHub組織のリポジトリ作成・公開範囲変更の設定を分けて点検します。そのうえで、個人アカウントやGistへのpushを実行時に止め、公開後の削除と情報のローテーションまで含む手順を用意してください。
ポイント
GitHub CLIの更新は安全な添付経路を増やします。公開先と所有者を実行時に確認する統制、画像を含む棚卸し、事故後の削除・ローテーションを組み合わせてPixelLeak型の経路を閉じます。
関連記事
- AI生成コード時代のコードレビューを解説|開発現場のボトルネックと対策
- Claudeのサンドボックス脱出事例を解説|AIエージェントの封じ込めと供給網リスク
- 非人間IDを解説|AIエージェントの権限管理と監視のポイント
- シャドーAIエージェント対策を解説|検出・統制の進め方
- AgentOpsを解説|AIエージェントの可観測性・評価・監視のポイント
▼開発を相談する前に読みたい無料ホワイトペーパー
・AIシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>


株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。
