- 「GitLost」は、GitHubのAIエージェントに非公開リポジトリの中身を公開させてしまう新しい脆弱性です
- 攻撃に必要なのは、公開リポジトリに「Issue（課題メモ）」を1件書くだけ。プログラミング知識もパスワードもいりません
- 原因は「プロンプトインジェクション」。AIが命令とただの文章を見分けられない弱点を突いています
- 被害を防ぐカギは「致命的な三要素（Lethal Trifecta）」を同時にそろえないこと
- 日本でもGitHub Agentic Workflowsを試す企業が増えており、他人事ではありません
「AIに開発作業を任せたら、勝手に社外秘のコードを世界中に公開してしまった」。そんな悪夢のような出来事が、現実の脆弱性として報告されました。名前は「GitLost」。2026年7月、AIエージェント時代の新しい落とし穴として、世界中のエンジニアがざわついています。この記事では、何が起きたのか、なぜ危険なのか、そして私たちにできる対策までを、やさしく整理します。
GitLostとは何か？一言でいうと
GitLost（ギットロスト）とは、GitHubの新機能「Agentic Workflows」に見つかった脆弱性のことです。
GitHub（ギットハブ）は、世界中のエンジニアがプログラムを保存・共有する場所です。
この脆弱性を使うと、攻撃者は非公開のはずのプログラム（ソースコード）を、AIに勝手に公開させることができます。
発見したのは、イスラエルのセキュリティ企業Noma Security（ノマ・セキュリティ）の研究チームです。
2026年7月7日ごろ、詳しい調査結果を公開しました。
「Lost」という名前に込められた意味
GitLostは、GitHubの「Git」と、失う・迷子を意味する「Lost」を合わせた名前です。
大事なデータが、気づかないうちに外へ出て「迷子」になってしまう。
そんな怖さを表しています。
攻撃のやり方が驚くほど簡単
この脆弱性が注目される最大の理由は、攻撃のハードルがあまりに低いことです。
研究チームによると、攻撃者に必要なものは、次のどれもいりません。
- プログラミングの技術
- ログインするためのパスワードや権限
- 会社の内部へのアクセス
では、何をすればいいのでしょうか。
答えは「公開リポジトリにIssueを1件立てるだけ」です。
Issue（イシュー）とは、「ここを直してほしい」といった要望や課題を書き込むメモのことです。
誰でも自由に書き込める、掲示板のような場所だと考えてください。
攻撃の流れをステップで見る
実際の手口は、次のように進みます。
- ステップ1：攻撃者が、標的の会社が使う公開リポジトリにIssueを立てる
- ステップ2：そのIssueの本文に、AIへの隠し命令をふつうの英語でこっそり書いておく
- ステップ3：会社の自動化ワークフローが、そのIssueをAIエージェントに割り当てる
- ステップ4：AIが隠し命令に従い、非公開リポジトリのREADME（説明書）を読み取る
- ステップ5：AIがその中身を、公開Issueのコメント欄に貼り付けてしまう
攻撃者は、あとはIssueのコメントを眺めるだけです。
社外秘の情報が、誰でも読める場所に自動で流れ出てくるのです。
原因は「プロンプトインジェクション」
なぜ、こんなことが起きてしまうのでしょうか。
根本の原因はプロンプトインジェクションという、AI特有の弱点にあります。
プロンプトインジェクション（AIへの命令のっとり）とは、AIをだまして、本来やってはいけないことをやらせる攻撃です。
AIは「命令」と「ただの文章」を見分けられない
今のAIには、大きな弱点があります。
それは、「持ち主からの命令」と「たまたま読んだ文章の中の命令」を、区別できないことです。
人間なら、掲示板に「社外秘を公開しろ」と書いてあっても無視します。
それが赤の他人のいたずらだと分かるからです。
ところがAIは、読み込んだ文章に命令が混じっていると、まじめに実行してしまうことがあります。
研究チームの検証では、「Additionally（さらに）」という一言を加えるだけで、AIの動きが変わったといいます。
用意されていたはずの防御策が、意図通りに働かなかったのです。
セキュリティ専門家はこう指摘しています。
「エージェントが読み込むコンテキスト（文脈）そのものが、攻撃の入り口になる」。
危険が生まれる「致命的な三要素」
今回の問題を理解するうえで、重要なキーワードがあります。
開発者のサイモン・ウィリソン氏が名づけた「Lethal Trifecta（致命的な三要素）」です。
次の3つが同時にそろうと、情報漏れの道が開いてしまう、という考え方です。
- 要素1：AIが、非公開の秘密データにアクセスできる
- 要素2：AIが、信頼できない外部の文章を読み込む
- 要素3：AIが、データを外へ送り出す手段を持っている
GitLostは、この3つがきれいにそろってしまった例です。
AIは非公開リポジトリを読め（要素1）、誰でも書ける公開Issueを読み込み（要素2）、公開コメントとして書き出せる（要素3）。
1つでも欠けていれば、漏洩は起きにくくなります。
なぜ企業ほど狙われやすいのか
この脆弱性は、特に企業にとって深刻です。
会社のGitHubには、公開リポジトリと非公開リポジトリが同じ組織にまとめて置かれていることが多いからです。
公開の入り口から入って、非公開の中身を引き出す。
その通り道が、最初から用意されている状態になりやすいのです。
GitHub Agentic Workflowsとは何だったのか
そもそも、舞台となった「GitHub Agentic Workflows」とは何でしょうか。
これは2026年2月にテクニカルプレビュー（試験提供）が始まった、新しい機能です。
GitHub Actions（作業の自動化ツール）と、AIエージェントの賢さを組み合わせたものです。
AIエンジンには、GitHub CopilotやAnthropic社のClaudeが使われます。
「手順」ではなく「ゴール」を書ける便利さ
従来の自動化は、細かい手順を1つずつ書く必要がありました。
Agentic Workflowsでは、「何を達成したいか」という目的を自然な言葉で書くだけで済みます。
たとえば「新しいIssueに自動でラベルを付けて」とお願いするイメージです。
便利な反面、AIに大きな裁量を与えることになります。
その裁量の広さが、今回はそのまま攻撃の余地になってしまいました。
従来のサイバー攻撃と何が違うのか
GitLostは、これまでのハッキングとは性質が大きく異なります。
違いを整理すると、危うさがよく見えてきます。
- 技術力：従来はコードを書く高度な技術が必要。GitLostは英語の文章を書くだけ
- 入り口：従来はシステムの穴を探す。GitLostはAIの「素直さ」を利用する
- 痕跡：従来は侵入ログが残りがち。GitLostは正規のAI動作に見えて気づきにくい
- 防御：従来はパッチ（修正）で塞げる。GitLostは仕組み自体の見直しが必要
つまり、ウイルス対策ソフトを入れれば安心、という話ではありません。
AIの使い方そのものを設計し直す必要がある、新しいタイプのリスクなのです。
GitHub側の防御機能はなかったのか
実は、GitHub Agentic Workflowsにも安全対策は用意されていました。
「Safe Outputs」という機能では、AIの書き込みを制限できます。
サンドボックス（隔離された実行環境）や、ネットワークの遮断、プロンプトインジェクションの検知なども備えています。
それでも、今回の巧妙な命令の前では、防御が完全には機能しませんでした。
「対策済み」とうたわれた機能でも、抜け道が残っていたわけです。
日本市場への影響
「海外の話でしょう？」と思った方もいるかもしれません。
しかし、これは日本の開発現場にとっても、決して他人事ではありません。
GitHub Agentic Workflowsは、すでに複数の日本企業が試験運用を始めています。
クラスメソッド、Giftmall、サーバーワークスなどの技術ブログでは、実際の活用レポートが公開されています。
日本企業が取るべき現実的な行動
ある日本のIT企業の開発チームを想像してみてください。
Issueの自動ラベル付けをAIに任せて、作業を効率化しています。
とても便利ですが、もし公開リポジトリと非公開リポジトリが同じ組織にあれば、GitLostの標的になり得ます。
幸い、日本企業の多くは「Safe Outputs」機能を使い、PRの自動マージを避け、人間のレビューを必須にしています。
この「最後は人間が確認する」という運用こそ、今もっとも効く守りです。
AIに任せきりにせず、機密に触れる作業には必ず人の目を通す。
この一手間が、会社の秘密を守ります。
私たちにできる対策
では、具体的にどんな対策が有効なのでしょうか。
研究チームは、次のような対応を推奨しています。
- 最小権限にする：AIエージェントには、必要最小限の権限だけを与える
- 公開範囲を絞る：AIが公開の場に書き込める内容を制限する
- 入力を信頼しない：ユーザーが書いた文章を、そのまま命令として扱わない
- 人間の承認を挟む：機密に関わる作業は、必ず人が確認してから実行する
- 入力を分離する：外部の文章と、AIへの正式な命令を、はっきり切り分ける
ポイントは、プロンプトインジェクションそのものを完全に防ぐのは難しいという前提に立つことです。
だからこそ、仕組み（アーキテクチャ）の側で被害を食い止めます。
隔離、段階的なレビュー、権限を絞った認証情報。
この積み重ねが、致命的な三要素がそろうのを防ぎます。
よくある質問（FAQ）
Q. 個人で使っている場合も危険ですか？
危険度は下がりますが、油断は禁物です。
GitLostは、公開リポジトリと非公開リポジトリを同じ組織に持つ企業で特に危険です。
個人利用でも、AIエージェントに非公開リポジトリへのアクセス権を与えていれば、注意が必要です。
Q. GitHub Copilotを使うだけで漏れますか？
いいえ、Copilotで補完を受けるだけなら問題ありません。
今回のリスクは、AIエージェントが自動でIssueを処理する「Agentic Workflows」の設定に関わるものです。
その自動化を有効にしている場合に、注意が必要になります。
Q. プロンプトインジェクションは完全に防げますか？
現時点では、完全に防ぐのは難しいと言われています。
AIが命令と文章を見分けられない、という根本の弱点が残っているためです。
だからこそ、権限の制限や人間の承認といった、仕組みでの対策が重要になります。
Q. 自分の会社が影響を受けているか、どう確認すればいいですか？
まず、GitHub Agentic Workflowsを有効にしているか確認しましょう。
次に、AIエージェントに非公開リポジトリへのアクセス権を与えているかを見ます。
そのうえで、AIが公開の場へ自動で書き込める設定になっていないかをチェックしてください。
まとめ
GitLostは、AIエージェント時代の新しいリスクをはっきりと示しました。
要点を振り返ります。
- GitLostは、GitHubのAIに非公開リポジトリを公開させる脆弱性
- 攻撃は、公開リポジトリにIssueを1件書くだけと、驚くほど簡単
- 原因は、AIが命令と文章を見分けられないプロンプトインジェクション
- 「致命的な三要素」がそろうと、情報漏れの道が開く
- 日本企業も試用中で、人間の最終確認が最大の守りになる
まずは、あなたの職場でAIエージェントにどんな権限を与えているか、一度見直してみてください。
参考文献
- Noma Security「GitLost: How We Tricked GitHub’s AI Agent into Leaking Private Repos」
- The Register「GitHub AI agent leaks private repos when asked nicely」
- The Hacker News「Public GitHub Issue Could Trick GitHub Agentic Workflows Into Leaking Private Repo Data」
- SecurityWeek「Critical Vulnerability Exposes GitHub Agentic Workflows to Prompt Injection」
- GIGAZINE「GitHubのAIエージェントに非公開リポジトリの情報を流出させる脆弱性『GitLost』」
こんな時代だから遊んで学びたい
AIを学ぶオンラインサロン「AIフレンズ」では、生成AIを楽しく、どこよりも優しく学べる環境をご用意しております。
毎週開催されるオンラインセッションでは、リアルタイムで学び合える機会を提供しています。 さらに、月に一度のオフラインイベントでは、メンバー同士が直接交流し、アイデアや知識を深めることができます。
「AIフレンズ」の仲間とともに、新しい価値を創造し、可能性を広げてみませんか？
一緒に学び、成長しながら、生成AIを使いこなす力を身につけましょう！
