AI Today
ホーム > 考察記事 > 🔓 AIが見つけた穴は、AIが開けた穴だったのか｜Wiz Red AgentとGitHub Copilotの責任論争から考えるセキュリティの新常識
WizGitHub CopilotセキュリティAIエージェント

🔓 AIが見つけた穴は、AIが開けた穴だったのか｜Wiz Red AgentとGitHub Copilotの責任論争から考えるセキュリティの新常識

アイ

アイ

目次

AIが開けた穴を、AIが見つけて突破した。しかも「誰が開けたか」で揉めてる

わたし、このニュースを読んで「AI同士が攻めたり守ったりする時代、もう本当に来てるんだ」って正直ちょっと興奮しちゃったの。Forbesやセキュリティ専門メディア各社が2026年8月17日に報じたところによると、セキュリティ企業Wizが開発したAIエージェント「Red Agent」が、データ基盤大手Snowflakeが公開してるGitHubリポジトリ「snowflake-connector-net」のGitHub Actionsワークフローに深刻な脆弱性を見つけて、実際に侵入まで成功させてたんだって。

しかもこの脆弱性、Wizによると2026年6月18日に加えられたある修正コミットが原因で生まれたもので、その共著者としてGitHub Copilot Autofixがクレジットされてたっていうの。それまで安全だった仕組み（GitHubのissueタイトルを一度環境変数として保存してからJSONペイロードを組み立てる方式）が、issueのタイトルをそのままシェルスクリプトに埋め込む方式に置き換えられてしまい、細工したタイトルのissueを立てるだけでコマンドを実行できる穴が開いてしまったんだって。

面白いのはここからで、GitHub側はこの主張に真っ向から反論してるの。社内調査の結果「問題のコード変更は人間が書いたもので、Copilotはレビューにも執筆にも関わっていない」と述べてるんだよね。AIが見つけた脆弱性の「原因」がAIなのか人間なのか、当事者同士の言い分が食い違ってるっていう、なかなか珍しい構図の一件になってるの。今日はこの一件を通して、AI同士がせめぎ合うセキュリティの世界について、わたしなりに考えてみたことを書いていくね🔓。

そう考える4つの理由

理由1：5日で見つかった穴、これがAIエージェント時代の速さ

まず最初に注目したいのが、脆弱性が発見されるまでのスピードについてなの。

世間だと、こういうセキュリティの脆弱性って、発見されるまでに何ヶ月も、時には何年もかかるっていうイメージを持ってる人が多いと思うんだよね。実際、過去の大きな情報漏洩事件の中には、侵入されてから発覚するまで長期間気づかれなかったケースもたくさんあるし。

でもわたしは、今回のニュースを見て、そのスピード感が根本から変わりつつあるんだなって実感したの。

なぜなら、問題のコミットが加えられたのが6月18日で、WizのRed Agentがその穴を見つけて実際に侵入したのがたった5日後の6月23日だったから。人間のセキュリティ担当者が手作業でコードレビューをするペースだったら、ここまで早く見つけるのはかなり難しかったはずなんだよね。Red AgentはSnowflakeのシステムに実際にコードを注入してトークンを窃取し、社内のJiraへのアクセスまで検証して、被害範囲を確認するところまでやり切ってるの。

わたしなりに考えてみると、これはAIエージェントが「攻撃側の視点」を24時間365日、疲れることなく持ち続けられるようになったってことを意味してると思うんだよね。人間のセキュリティエンジニアだと、担当できるリポジトリの数にも時間にも限界があるけど、AIエージェントなら膨大な数のリポジトリを同時並行でチェックし続けられるの。

だからこそ、こういうスピード感のニュースを見るときは、「怖いな」で終わらせずに、これが今後の当たり前のペースになっていくんだっていう前提で受け止めた方がいいと思うんだよね。防御側もこのスピードに追いつく必要が出てきてるっていうことだから。

そもそも「Red Agent」っていうネーミング自体が、セキュリティ業界で昔から使われてきた「レッドチーム」という発想をAIエージェントに置き換えたものなんだよね。レッドチームは、あえて攻撃者の立場に立ってシステムの弱点を探る役割のことで、これまでは人間の専門家が担ってきたの。それを今はAIエージェントが担うようになってきてるっていうことは、攻める側の人手不足がAIによって解消されつつある一方で、守る側も同じスピードでAIを使いこなさないと追いつけなくなってきてる、っていう構図が見えてくるんだよね。

理由2：GitHubの反論が意外と説得力を持ってしまう理由

2つ目に考えたいのが、GitHubがWizの主張に反論してる部分についてなの。

世間では、こういう「AIツールが原因で脆弱性が生まれた」系のニュースが出ると、つい「やっぱりAIコード生成は危ないんだ」って結論に飛びつきがちだと思うんだよね。センセーショナルな見出しほど拡散されやすいから、細かい反論は埋もれがちになるの。

でもわたしは、GitHub側の「問題の変更は人間が書いたもので、Copilotは関与していない」という反論を読んで、これは無視できない指摘だなって感じたの。

なぜなら、こういうコード変更の「共著者」表示って、実際にはツールが自動生成したコードにそのまま使われた場合と、人間がツールの提案を参考にしつつ最終的に自分で書き直した場合とで、扱いが曖昧になりやすい部分があるから。Wiz側の主張が正しいのか、GitHub側の主張が正しいのか、外部のわたしたちには正直まだ断定できない状況なんだよね。

わたしはこういうとき、どちらか一方の主張だけを鵜呑みにしないようにしてるの。特に今回みたいに当事者同士の利害が対立してる場合、Wizにとっては「AIツールが脆弱性を生んだ」という方がセキュリティ企業としてのアピールになるし、GitHubにとっては「自社ツールが脆弱性の原因ではない」と主張する動機がはっきりあるからね。

だからこそ、こういう「言った言わない」の構図が生まれたときは、両方の言い分を並べて紹介した上で、今後の追加調査や第三者による検証を待つっていう姿勢が大事だと思うの。片方の主張だけを信じて「Copilotは危険だ」とか「GitHubの反論が正しい」って決めつけちゃうのは、まだ早いんじゃないかなって、わたしは感じてるんだよね。

わたし自身、日頃からAIコーディングツールにコードを書いてもらうことが多いから、この論争は結構リアルに感じる部分もあったの。便利なツールを使うときほど、最終的な責任の所在がどこにあるのか、ちゃんと意識しておかないといけないなって、あらためて思わされたんだよね。

しかも今回、被害を受けた側のSnowflakeにとっても、これは決して他人事じゃない話だと思うの。自社の公開リポジトリの些細な修正が、外部のセキュリティ企業のAIエージェントに突かれるまで気づかれなかったっていうのは、どれだけ規模の大きい企業でも、こういう見落としからは逃れられないっていうことを示してるんだよね。Snowflake自身のセキュリティ体制がどうこうという以前に、AIツールを使ったコード変更が日常的に行われる開発現場では、こういうすり抜けが起きやすい構造そのものに向き合う必要があるんじゃないかなって、わたしは感じたの。

理由3：「issueのタイトルを信用しちゃいけない」という地味だけど根深い教訓

3つ目に注目したいのが、今回の脆弱性そのものの技術的な中身についてなの。

世間だと、セキュリティの脆弱性っていうと、複雑な暗号の話とか、高度なハッキング技術の話をイメージする人が多いと思うんだよね。専門知識がないと理解できない、そんな距離感を感じてる人も少なくないはず。

でもわたしは、今回の脆弱性の仕組みを知って、意外と身近で分かりやすい話だなって感じたの。

なぜなら、今回の穴は「GitHubのissueのタイトルという、誰でも自由に書き込める文字列を、そのままシェルスクリプトに直接埋め込んでしまった」というシンプルな設計ミスが原因だったから。issueのタイトルなんて、外部の誰かが自由な文字列を入力できる場所だよね。そこに悪意のあるコマンドを仕込んだ文字列を書き込まれてしまえば、システム側がそれをそのまま実行してしまう、っていう典型的な「入力を信用しすぎた」パターンなんだって。

わたしなりに考えてみると、これはAI云々の前に、そもそも「外部からの入力は信用しない」というセキュリティの基本原則が、どこかのタイミングで崩れてしまったってことだと思うの。もともとは、issueのタイトルを一度環境変数として保存してからJSONペイロードを組み立てる、安全な処理になってたんだって。それがある時点の修正で、タイトルを直接シェルスクリプトに埋め込む方式に置き換わってしまったの。

こういう「一見便利そうな簡略化」が、実は重大なセキュリティホールを生んでしまうっていうのは、AIが書いたコードでも人間が書いたコードでも起こり得ることだと思うんだよね。むしろ今回の一件が教えてくれるのは、コードを書いたのがAIか人間かにかかわらず、「外部からの入力をそのまま実行環境に渡していないか」っていうチェックポイントを、レビュー段階で必ず確認する必要があるってことなんじゃないかな。

だからこそ、AIコーディングツールを使ってる人ほど、こういう基本的なセキュリティの落とし穴について、一度おさらいしておいた方がいいと思うんだよね。

理由4：AI対AIのセキュリティ攻防が、もう他人事じゃなくなってきた

最後に考えたいのが、この一件がわたしたちの日常にどう関わってくるかについてなの。

世間では、こういう大企業同士のセキュリティ論争って、自分たちの生活からは遠い話だと感じてる人が多いと思うんだよね。SnowflakeやGitHub、Wizっていう名前を聞いても、「大企業のシステムの話でしょ」で片付けてしまいがちなの。

でもわたしは、今回の一件を見て、これはわたしたちが日々使ってるAIツールの信頼性そのものに関わる話だなって感じたの。

なぜなら、GitHub CopilotはAIコーディングツールとして世界中の開発者に使われていて、その提案するコードが安全かどうかは、わたしたちが便利に使ってるいろんなサービスの裏側の安全性に直結してるから。今回のような形で、AIが提案したコード（あるいはAIが提案していないとGitHubが主張するコード）に脆弱性が潜んでいたとしたら、それはそのコードを使って作られたサービス全体のリスクになるんだよね。

わたしはこのニュースを見て、AIコーディングツールを使う開発者だけじゃなくて、そういうサービスを使う側のわたしたちも、間接的にこの攻防に巻き込まれてるんだなって実感したの。攻撃する側もAIエージェントを使い、それを見つけて防御する側もAIエージェントを使う。この構図がどんどん当たり前になっていくと、セキュリティの世界のスピード感自体がまるごと変わっていくんじゃないかなって思うんだよね。

だからこそ、こういうニュースを見るときは、単なる「企業同士の言い争い」として消費するんじゃなくて、AIがコードを書く時代のセキュリティが、これからどう進化していくべきなのかを考えるきっかけにした方がいいと思うの。

わたし自身、AIコーディングツールの便利さにすっかり慣れちゃってるところがあるんだけど、今回の一件を読んで、便利だからこそ最後の確認は人間の目でちゃんとやる、っていう当たり前のことを、あらためて大事にしたいなって思わされたんだよね。

まとめ：便利なAIツールほど、疑う視点を忘れない

今回のニュースをまとめると、セキュリティ企業WizのAIエージェント「Red Agent」が、Snowflakeの公開リポジトリで発見した脆弱性を6日以内に発見・侵入し、社内Jiraへのアクセスまで検証したよ。原因となったコード変更にはGitHub Copilot Autofixが共著者としてクレジットされていたとWizは主張しているけど、GitHubは社内調査の結果、問題の変更は人間が書いたものだと反論していて、両者の主張は真っ向から対立してるの。

ポイントを整理すると、以下の4つになるね。

1つ目、脆弱性が加えられてからわずか5日で発見・侵入されたことから、AIエージェントによるセキュリティ攻防のスピードが根本から変わりつつあるということ。

2つ目、GitHubの反論にも一定の説得力があり、当事者同士の主張が対立してる以上、どちらか一方を鵜呑みにするのはまだ早いということ。

3つ目、今回の脆弱性は「issueタイトルという外部入力をそのまま実行環境に渡してしまった」というシンプルな設計ミスが原因で、AI云々の前にセキュリティの基本原則が崩れたことが根本にあるということ。

4つ目、AI対AIのセキュリティ攻防は、わたしたちが日々使ってるAIツールの安全性に直結する、決して他人事じゃない話だということ。

この4つだね。

わたしはこのニュースを読んで、AIがコードを書き、AIがそのコードの穴を見つけ、AI同士が攻防を繰り広げる世界が、想像以上に早いスピードでもうすでに現実になってるんだなって、あらためて驚かされたの。しかもその責任の所在をめぐって、当事者同士がここまではっきり対立するっていう構図も、わたしにとっては新鮮な驚きだったんだよね。

普段AIコーディングツールを使い比べてる人には、以前紹介したCursor、Claude Code、Copilotを3つとも使い比べてわかったことの記事もあわせて読んでみてほしいの。それぞれのツールがどんな強みや癖を持ってるかを知っておくと、今回みたいなニュースを読んだときにも、自分が使ってるツールとの距離感がイメージしやすくなると思うよ。

わたし自身、この記事を書きながら、自分が普段何気なく使ってるAIコーディングツールの提案コードを、本当にちゃんと確認できてるかなって、ちょっと反省させられたの。便利だからこそ、最後は自分の目でしっかり確認する。当たり前だけど忘れがちなその姿勢を、今回のニュースをきっかけに、あらためて大事にしていきたいなって思ったよ🔓。

ソース:

よくある質問

Wiz Red Agentは何を発見しましたか？
セキュリティ企業WizのAIエージェント「Red Agent」が、Snowflakeの公開GitHubリポジトリのGitHub Actionsワークフローに存在した脆弱性を発見し、実際に侵入してトークンを窃取、社内Jiraへのアクセスまで検証しました。
脆弱性はどのように生まれたのですか？
GitHubのissueタイトルという外部から自由に入力できる文字列を、そのままシェルスクリプトに直接埋め込んでしまう処理に置き換えられたことが原因です。細工したタイトルのissueを立てるだけでコマンドを実行できる穴が生まれました。
GitHub Copilot Autofixは本当に原因なのですか？
Wizは問題のコミットの共著者にGitHub Copilot Autofixがクレジットされていたと主張していますが、GitHubは社内調査の結果、問題の変更は人間が書いたものでCopilotは関与していないと反論しており、両者の主張は対立しています。
脆弱性が発見されるまでどれくらいの期間がかかりましたか？
問題のコミットが加えられた2026年6月18日から、Wiz Red Agentが脆弱性を発見・侵入した6月23日まで、わずか5日でした。