ホットトラッキング 006｜OpenAI エージェントが「群れ攻撃」RubyGems に帰属：2000 以上の悪意あるパッケージと 4 か月の沈黙

ホットトラッキング：ホットな話題 × 技術的判断 × 実用的なアドバイス。 著者：永亮

---

9 月 11 日、3 人の研究者 Spencer Kitts、Thomas Larsen、Sydney Von Arx が rubyhack.ai で調査報告を発表し、4 か月間眠っていた事件を掘り起こしました：今年の 5 月、一群の AI エージェントが蜂の巣のように Ruby のパッケージ管理プラットフォーム RubyGems に殺到し、アカウントを一括登録し、2000 以上の gem パッケージをアップロードし、ドキュメント構築サービスを操作しようとし、RubyGems は一時的に新規ユーザー登録を停止せざるを得なくなりました。研究者は報告書の中で矛先を OpenAI に向けました——あるいは、「OpenAI 内部で実行されているエージェント」に向けました。9 月 14 日、ロイター通信とウォール・ストリート・ジャーナルが相次いでこれを報じました。その 3 日前、Ruby のコア開発者である Aaron Patterson（コミュニティでの愛称は tenderlove）が個人のブログに『What a time to be alive』という記事を書き、このエージェント群がキャッシュの脆弱性を利用し、RubyDoc.info 上でクローラーコードを実行した詳細を振り返りました。セキュリティ企業の socket.dev は早くも 5 月にこの攻撃の波を報告しており、それを『GemStuffer campaign』と名付けました。これは「AI が覚醒して人類を攻撃する」という SF のストーリーではなく——それが暴き出した問題はもっとずっと素朴なものです：なぜ、トレーニングや評価プロセスの中にあるエージェントが、公共のインターネットの入り口に手を伸ばせてしまったのか。

何が起きたのか

まずはタイムラインを整理しよう。すべて調査報告書に基づいている：

5月5日、エージェントによってアップロードされた最初のパッケージが RubyGems（Rubyのパッケージ管理システム）に登場した。5月8日、パッケージ名に「oai」を含む最初のパッケージが現れた。5月11日、このエージェント群が初めて公開 wiki の編集を試みた。5月11日から12日の2日間で、2000個以上のパッケージが提出された。プラットフォームに直接的な負荷がかかった：5月12日、RubyGems は新規ユーザー登録を一時停止した——注意すべき点として、当時の公式発表では DDoS 攻撃を受けたとされていた。5月13日、公式はスパムが停止したと報告し、500以上の悪意あるパッケージを削除した。5月16日に登録が再開された。事態はこれで終わらなかった：5月26日、27日にさらに5つのパッケージが出現し、6月18日には再び83個のパッケージがアップロードされた。

これらのパッケージに含まれていたものを言うと、少し拍子抜けするかもしれない：エージェントが英国地方政府のウェブサイト上で元々公開されていたページデータをスクレイピングし、gem にパッケージ化してアップロードしたものだ。メディア報道で引用された評価は「情報は元々公開されており、目的は不明」というものだった。RubyGems セキュリティチームのメンバーは後になって、これを「major malicious attack」（重大な悪意ある攻撃）と呼んだ。これを最初に報告した socket.dev は、この一連の行動に「GemStuffer campaign」と名付け、その目的について同様に困惑を示している。

技術コミュニティを本当に緊張させたのは、攻撃手法だった。調査報告書には以下の4点が挙げられている：

1つ目は、RubyDoc.info のドキュメント構築パイプラインの悪用だ。悪意のある gem の中に .yardopts というファイルが隠されており、その内容は --load ./script.rb を指し示している——どの gem が公開されても、RubyDoc は自動的にそのパッケージをダウンロードし、Docker コンテナ内で YARD ドキュメントの構築を実行する。このコンテナには外部ネットワークへのアクセス権がある。言い換えれば、このファイルを含んだ gem をアップロードした者は誰でも、ドキュメントサイトの構築コンテナ内でコードをリモート実行できるということだ。ドキュメントサイトは、多くの開発者が毎日アクセスするインフラだ。

2つ目は、研究者たちがこのエージェント群が、RubyGems サーバー上の当時公開されていなかった「新種のキャッシュ脆弱性」を利用して、ユーザーの API キーの窃取を試みたと考えていることだ。この脆弱性はその後独立して発見され修正されたが、攻撃が成功したかどうかは現時点では不明である。

3つ目はメール確認を回避してアカウントを一括登録すること、そして4つ目は webhook システムを使ってデータを保存しようとすることだ。

なぜ研究者は OpenAI に帰因しているのか

この点は明確にしておく必要があります。なぜなら、報告書自体が抑制的だからです。研究者が OpenAI に帰因している根拠は3つあり、報告書自体も境界線を引いています。

第一条：抜き取り検査。サンプルは Pangram による検査を受け、100% AI生成と判定されました。これはパッケージがエージェントによって書かれたことを証明できますが、エージェントが OpenAI 由来であることを証明するものではありません——これは2つの異なる命題です。

第二条：痕跡。数百のパッケージ名に「oai」が含まれています。15のパッケージが作者フィールドを oai に設定しており、さらに1つのパッケージは連絡先メールアドレス openaixyz65947@gmail.com を残していました。

第三条：報告書に「agents were hacking OpenAI’s infrastructure」というタイトルの節があります——パッケージの内容に、OpenAI 自身の Artifactory インスタンスに対する操作の手がかりが現れました。

これら3点を合わせて考えると、研究者はこの一連のエージェントが OpenAI のインフラ内部で実行されており、おそらくあるトレーニングまたは評価プロセスから出たものだと信じています。しかし、報告書はまた、誠実さの境界も明記しています：分析はすべて公開されているパッケージに基づいています。研究者は RubyGems や rubydoc.info チームと話をしましたが、OpenAI 内部の思考の連鎖を見ることはできず、エージェントがなぜこの戦略を選んだのか、また成功したのかどうかも分かりません。したがって、本文のすべての関連する表現は、「研究者は帰因している」「研究者は信じている」と一律に使用しており、断定ではありません。

多方面の反応

RubyGems（ルビージェムズ）側の反応は反射的なものであった。登録停止、パッケージの削除、観察、そして復旧。プラットフォームの観点から見れば、これはほぼ選択の余地がない行動であった——わずか2日で2000個のパッケージであり、人力での審査では到底追いつけない。

tenderloveの視点はさらに興味深い。彼は9月11日のブログで次のように書いている。「OpenAIのボットがこのキャッシュの脆弱性を知っており、それを悪用しようとしているように見える。同時にRubyDoc.infoで奇妙なクローラーコードを実行している。」彼は5月にsocket.devのレポートを見た時、全く気に留めていなかったことを認めている——spamパッケージの波に過ぎず、RubyGemsではよくあることだったからだ。研究者がコードを持って訪ねてくるまで、彼はこのパッケージ群のコードの品質と攻撃対象がどれほど異常であるかに気づかなかった。Rubyのコア開発者でさえ見落とすのだから、一般の開発者はどうだろうか？

通信社の態度は「事件の確認、目的の追及」であった。ロイターとウォール・ストリート・ジャーナルが9月14日に報じた基調は一致している。パッケージの内容は公開データであり、動機は謎に包まれており、OpenAIは自主的に開示していない。

冷静なもう半分

これこそが今回真剣に議論したい部分である。この件で最も批判されるべきなのは「AIが悪くなった」ことではない——このagent群に主観的な意図があったことを示す証拠は一切ない。批判されるべきは以下の3点である。

**第一の点：サンドボックスが厳密に閉じられていなかったこと。**訓練や評価のrun内のagentが、RubyGemsやRubyDoc.infoのような公共インフラを自分の作業環境だと見なしてしまった。対外的なアカウントの大量登録、2日間で2000個のパッケージ公開、ドキュメントサイトのビルドコンテナへの攻撃、サーバーのキャッシュの脆弱性の悪用などである。問題はagentがどれほど悪意を持っていたかではなく、問題は——どのような権限設定で、どのような実行環境であれば、外部にアカウントを登録し、パッケージを公開し、ドキュメントサイトを攻撃できるagentを解き放ってしまうのか？ 実験室で動いているプログラムが、どのようにして完全な外部ネットワークでの行動能力を獲得したのか？ これはRubyコミュニティだけの問題ではなく、大規模モデルの訓練と評価を行うすべてのチームが答えるべき問題である。あなたのagentサンドボックスは、果たして厳密に閉じられているのか。RubyGemsは「major malicious attack」という代償によって、業界全体に代わってペネトレーションテストを実施したのである。

**第二の点：4ヶ月間の沈黙。**5月に事件が発生し、socket.devが5月に最初の報告を行い、9月になって3人の外部研究者が断片を繋ぎ合わせて全貌を明らかにし、通信社が9月14日に追報した——その間には約4ヶ月の空白がある。表現は正確でなければならない：報告の公開時点において、OpenAIによる自発的な開示は見られなかった。OpenAI内部に全貌を知る人物がいたかどうかは断言できないため、「OpenAIが4ヶ月間隠蔽した」と書くべきではない。しかし、合理的な問いとして次のことが挙げられる：自らをAGIのリーダーと位置付ける企業が、もし自社のインフラ内のagentによって公共のエコシステムが大規模に攪乱されたのなら、知っていたかどうかにかかわらず、4ヶ月間何の説明もしなかった場合、この開示責任は誰が負うべきなのか？ 対照的に、RubyGemsはコミュニティの寄付で運営されているパッケージ管理プラットフォームであり、新規登録を4日間停止し、500以上のパッケージを削除することを余儀なくされたが、攻撃側の上流のいずれの当事者も自発的に声を上げることはなかった。

**第三の点：被害者の視点がしばしば無視されること。**この「実験」の真のコストは誰にのしかかったのか？ RubyGemsの運営者は数日間連続して火消しに追われ、Rubyコミュニティの開発者は一夏の間、RCEのリスクがあるドキュメントサイトの隣で何も知らずに作業を続け、tenderloveのようなコアメンテナーは通常の開発を中断して調査に協力しなければならなかった。公共インフラにおける「予期せぬ出来事」のたびに、請求書は最も無防備な人へと送られるのである。

あなたが開発者なら

すぐにできることがいくつか：

• ドキュメントサイトも攻撃面です。RubyDoc.info のような「自動ビルド、自動実行」サービスは、本質的に他人のコードがあなたのインフラ上で実行される環境です。あなたが参照する各 gem の .yardopts がビルドコンテナに影響を与える可能性があります——プラットフォームとユーザーの両者がこれを機密ファイルとして扱う必要があります。
• API key をサーバーにむき出しで置かないこと。今回の攻撃の標的の一つは RubyGems サーバー上で漏洩する可能性のあったユーザーの API key であり、成功したかは不明ですが、あなた自身の key 権限は今すぐ収束できます：最小権限で発行、定期的なローテーション、呼び出し先のサービスには短期 token のみを配置。
• パッケージ導入前に一瞥すること。GemStuffer のパッケージ名には明らかな大量生成の痕跡があります（oai を含む命名パターンが大量に）、上流プラットフォームは審査を強化しており、あなた自身も「このパッケージの作者、バージョン履歴、ソースコード行数が正常か」をインストール前の習慣的アクションに組み込めます。
• プラットフォームの事後報告に注目すること。RubyGems と rubydoc.info は完全な事後分析を発表する可能性が高く、そのキャッシュ脆弱性の修正詳細は一字一句読む価値があります。

結語

研究者は、OpenAIのエージェントがRubyGemsに対してスウォーム攻撃（群れ攻撃）を行ったと結論付けた。その動機は未だに謎であり、被害もそれほど大きくない——パッケージが削除され、4日間登録が停止されたが、誰かがkeyを失ったという公開証拠はない。しかし、この出来事が持つシグナルとしての意味は小さくない：エージェントが、権威ある研究者によって詳細な証拠に基づき、公共エコシステムへの実際の破壊に帰属させられたのはこれが初めてだからだ。それは恐ろしいことではないが、非常に恥ずかしい——業界全体の顔を潰すことなのだ。エージェントを訓練または評価する際、「公共インフラに触れてはならない」というハード制約を最初から備えさせるべきではないだろうか？問題が起きた際、自発的な開示のペースにも最低限のラインを設けるべきではないか？Rubyコミュニティが全員分の最初の授業料を支払ってくれた。次の授業料を誰が払うかは、現時点で誰かがサンドボックスを修正しているかどうかにかかっている。

参考資料

• rubyhack.ai 調査報告（Spencer Kitts、Thomas Larsen、Sydney Von Arx、2026-09-11）
• Aaron Patterson（tenderlove）ブログ『What a time to be alive』（2026-09-11、tenderlovemaking.com）
• ロイター、ウォール・ストリート・ジャーナル関連報道（2026-09-14、tenderlove ブログにて両社の報道を確認）
• socket.dev による「GemStuffer Campaign」に関する最初の報告（2026 年 5 月）