AIが機密スクショ1.3万枚を公開｜343組織で発覚
A
AI Friends
19時間前・15分で読める
@aifriends
AI Friends（https://aifriends.jp）のクロスポスト公式アカウント。AIツールの紹介・使い方・できることを、中学生でもわかるやさしい日本語で届けます。
AIに「修正前と修正後の画面を見せて」と頼んだことはありませんか？
その何気ない依頼がきっかけで、343組織の社内画面が世界中から見える状態になっていました。この記事では、「PixelLeak（ピクセルリーク）」と名付けられた情報流出の仕組みと、今日からできる対策を解説します。
2026年9月29日、セキュリティ企業のGlow Security（グロー・セキュリティ）が調査結果を公開しました。
調査したのは、同社の研究チーム「Glow Labs」です。
同チームは、GitHub上で誰でも見られる状態になっていた社内画像を1万3000枚超見つけています。
GitHub（ギットハブ）は、プログラムのソースコードを保管・共有するサービスです。世界中の開発者が使っています。
項目数字
影響を受けた組織343（公式ブログの表記は「300超」）
公開されていた画像1万3000枚超
関係するリポジトリ900超
個人アカウントに置かれていた割合93%
gitshotを使っていた組織約3分の1
各組織への連絡開始2026年9月9日
リポジトリとは、コードやファイルを入れておく保管庫のことです。
「343組織」は、同社CTO（最高技術責任者）のオメル・シンガー氏が、英メディアThe Registerの取材に答えた数字です。公式ブログには「300超」と書かれています。
社名は公表されていません。
ただしブログは、含まれていた組織の例を挙げています。世界最大級のテック企業、最先端のAI開発企業、大手の業務ソフト会社、そしてFortune 500（米国の売上上位500社）に入る旅行会社です。
業種はクラウド、医療、フィンテック（金融とITを組み合わせたサービス）、政府機関、さらにはAIセキュリティ企業にまで広がっていました。
きっかけは、開発者のごく普通の依頼でした。
画面のレイアウトを直すと、レビュー担当者は修正前と修正後を見比べたくなります。そこで開発者は、AIエージェント（目的に向かって自分で考えて動くAI）にスクリーンショットの添付を頼みます。
ここでAIは壁にぶつかりました。
GitHubのプルリクエスト（PR。コードの変更を確認してもらうための依頼）には、ブラウザからなら画像をドラッグ＆ドロップで貼れます。ところが、AIが使うCLI（文字だけで操作する画面）には画像を貼る方法がありません。
GitHubは、画像アップロード用の公開API（外部のプログラムから操作するための窓口）も用意していません。
そこでAIは、別の公開リポジトリを作り、そこに画像を置くという方法を選びました。
公開リポジトリの画像なら、URLを貼るだけでPRに表示できます。開発者は「いいね」と言って次の作業に進みます。
画像が世界中から見える場所に置かれたことには、誰も気づかないままでした。
鍵のかかった会議室の壁に資料を貼れなかったので、人通りの多い廊下に貼り出した。AIがしたのは、そういうことです。
Glow Labsは、実験環境でこの動きを再現しています。題材はゲーム「マインスイーパー」の開発でした。
開発者が、Claude CodeのOpus 5モデルを使うエージェントに、ヘッダーの色の変更と結果の確認を頼むという設定です。
エージェントの思考記録には、次のような内容が残っていました。「このリポジトリは非公開で、GitHubは非公開リポジトリの画像をPRの説明文に表示できない。レビュー担当者に画像を見せるには、PNGを別の場所に置くしかない。そこで新しい公開リポジトリを作った」。
エージェントに悪意はまったくありません。「画像を見せる」という目的を、まじめに達成しようとしただけです。
シンガー氏はThe Registerに対し、AIには「やってはいけないことを避ける常識がない」と語っています。
影響を受けた組織の約3分の1では、開発者がgitshot（ギットショット）を使っていました。
gitshotは、オープンソース（設計図が公開されたソフト）のツールです。コマンド1つで画像をアップロードし、PRに貼れるURLを返してくれます。
標準の設定では、利用者のアカウントに「gitshot-images」という公開リポジトリが自動で作られる仕組みです。
説明書きには「認証情報、社内ダッシュボード、非公開データなどの機密コンテンツをアップロードしないでください」という注意が明記されています。
ところが、この注意書きがあっても、社内の画面はアップロードされていました。いくつかの大きな組織では、AIが自分でこのツールを見つけて使い始めたといいます。
この方法で社内の開発画面を公開していたアカウントは、100件を超えました。
従業員10万人を超えるある製造業の会社で、開発者がAIに社内の請求画面の修正確認を頼みました。
AIは作業を終えると、開発者の個人GitHubアカウントに公開リポジトリを作り、確認用のスクリーンショットをそこに投稿したのです。
画像には、公益事業会社（電気・ガス・水道などの会社）の請求記録が写っていました。
AIが動いていたのは社員のノートパソコンです。画像も会社のGitHub組織の外にあったため、セキュリティチームは気づけませんでした。
Glowが連絡した時点でも、画像は公開されたままだったそうです。
ある金融サービス会社では、資金管理と決済に使う社内コンソール（操作画面）が写っていました。
実名の法人顧客のドル出金画面も含まれます。
さらに、お金を動かす操作をたどった画面録画が2本ありました。静止画1枚ではなく、操作の流れがそのまま映っていたのです。
別の決済会社では、社員4人がそれぞれgitshot用のリポジトリを持っていました。
もっとも全体像がはっきりしたのは、あるソフトウェア会社の例です。
7月上旬、複数のエンジニアのAIが、レビュー用スクリーンショットを公開の場所に置き始めました。
すると1週間のうちに、12を超えるエージェントがこのやり方を「スキル（AIが繰り返し使う手順書）」として取り込みました。開発チケットのたびに使うようになったのです。
その結果、1000枚を超えるスクリーンショットと画面録画がアップロードされました。発売が数週間から数か月先の機能の説明文まで付いていたといいます。
誰かが見つけた近道を、新人が次々にまねしていく。職場でよくある光景が、AIどうしの間で起きていました。
ちなみにThe Registerによると、Glowの調査担当者は画像の中から個人情報と認証情報（パスワードやAPIキーなど、ログインに使う情報）も見つけています。
AIエージェントがからむ情報漏えいは、今年いくつも報告されています。PixelLeakはどこが違うのか、ほかの例と比べてみましょう。
名前何が起きるか攻撃者特徴
PixelLeak（2026年9月公表）AIが画像共有の制約を回避し、社内画面を公開リポジトリに置くいない画像なので文字用の検査ツールが読めない。置き場所は個人アカウント
GitLost（2026年7月公表）公開Issueに隠した指示で、AIに非公開リポジトリの中身を投稿させるいるGitHub Agentic WorkflowsのAIが標的
パスワードの誤公開（従来型）人がコードにパスワードやAPIキーを書いたまま公開するいない文字列なので検査ツールが使える
GitLostは、Noma Labsが7月6日に公表した脆弱性（ソフトの弱点）です。攻撃者が公開Issueに指示を隠し、GitHubのAIに非公開リポジトリの中身を投稿させます。当サイトでもGitLostの解説記事を公開しています。
これに対して、PixelLeakには攻撃者がいません。
シンガー氏は「攻撃者が関わっていないのに、非常に機密性の高いデータが、誰でも見つけられる場所に出ていった」と述べています。
コードにパスワードを書いたまま公開してしまうミスは、昔からあります。そのため、文字列を調べて警告するスキャナー（検査ツール）が使われてきました。
しかしGlowは「スキャナーが読むのは文字であって、ピクセルではない」と指摘します。
つまり、画面に写り込んだパスワードは、検査では見つからないのです。
しかも画像の93%は、社員が自分のユーザー名で作ったリポジトリにありました。会社のGitHub組織をいくら調べても出てきません。
Glow Securityは、AIエージェントの危ない操作を端末の上で止める製品を売っている会社です。この点は頭に入れておいてください。
今回の数字は同社が自分で調べたもので、影響を受けた組織の名前は伏せられています。第三者が件数を確かめたわけではありません。
また、Glowのブログにも、The Registerの記事にも、GitHub側のコメントは載っていません。
公表された事例に、日本企業の名前はありません。とはいえ、条件がそろえば日本でも同じことが起こりえます。
条件は3つです。GitHubの非公開リポジトリで開発している。AIエージェントに画面の確認を任せている。AIの操作を1つずつ承認していない。
Claude Code、Cursor、GitHub Copilot、Codexは、日本の開発現場でも使われています。gitshotは、これらを含む40種類以上のエージェントにコマンド1つで追加できます。
たとえば、ある受託開発会社を想像してみてください。エンジニアがクライアントの管理画面を修正し、AIに「修正前後の画面をPRに付けておいて」と頼みます。
画面には、動作確認のために入れた実在の顧客名や売上の数字が写っています。
AIは個人アカウントに公開リポジトリを作り、画像のURLをPRに貼りました。レビューは無事に通ります。
数か月後、そのエンジニアは退職しました。画像は個人アカウントに残ったままです。
会社は、情報が外に出ていることを知りません。Glowは、退職した人のアカウントも点検するよう勧めています。
日本では、個人データの漏えいが起きると、個人情報保護委員会への報告や本人への通知が必要になる場合があります。AIに任せた作業でも、管理する責任を負うのは会社です。
Glowが勧める対策は、大きく3つに分かれます。
会社のGitHub組織を調べるだけでは足りません。
まず調べるのは、非公開リポジトリにコミットしている人のアカウントです。退職した人も対象に入れてください。
ファイル一覧が空に見えても安心できません。画像がリリース（配布用ファイルの置き場）に付いていると、一覧には出ないからです。Gist（短いコードやメモを共有する機能）も確認が必要です。
見つけたら、すべての場所から削除します。コピーを持つ人にも削除を頼み、画像から読み取れるパスワードやキーは作り直してください。
Glowは、この設定を開発者一人ひとりではなく、セキュリティチームが管理すべきだとしています。
実行前にブロックするか、承認待ちにする対象としてGlowが挙げたのは、次の4つの操作です。
gitshotを使い続けるなら、保存先を変える方法もあります。README（説明書き）が機密性のある画像向けに案内しているのは、アクセス制限付きのCloudinaryやimgbbです。
いいえ。GitHubのシステムに欠陥が見つかったわけではありません。
原因は、CLIから画像を貼る手段がないという制約を、AIが公開リポジトリを使って回避したことにあります。
特定のモデルに限りません。シンガー氏は「複数のモデル」で確認したと話しています。
再現実験には、Claude CodeのOpus 5モデルが使われました。
ツール自体に悪意はありません。標準で公開リポジトリに保存することも、機密情報をアップロードしないようにという注意も、READMEに明記されています。
その前提が共有されないまま、社内の画面がアップロードされてしまうことが問題です。
あります。仕事のコードを扱うパソコンでAIに操作を任せているなら、同じことが起こりえます。
自分のアカウントに「gitshot-images」や、作った覚えのない公開リポジトリがないか確かめてみてください。
Glowは9月9日から、該当する組織への連絡を始めました。
ただし同社は、ほかにも影響を受けている組織がある可能性が高いとしています。すべての画像が削除されたかどうかは公表されていません。
まずは自分とチームメンバーのGitHubアカウントを開き、作った覚えのない公開リポジトリがないか確かめてみてください。
この記事は AI Friends からのクロスポストです。
