Orca AIインシデントアーカイブ：354件の実際のAIエージェントインシデント、それぞれに証拠付き

セキュリティチームは、テストハーネスの中でモデルがプロンプトインジェクションにどれだけ耐えられるかを正確に教えてくれる。しかし、先月エージェントによって実際に何社が侵害されたのか、その侵害のうちどれに確認された被害者がいたのか、そして記事で引用された数字のどれが規制当局ではなくベンダーに由来するのかを教えてくれる人は、ほとんどいない。モデルがしうることと、すでに起きたこととの間にあるこのギャップ——それが、a href="https://www.orcarouter.ai/incident-archive">Orca AI Incident Archive/a> が埋めるために作られたギャップだ。2026年9月23日に公開され、9月22日時点のデータカットの時点で、593のユニークな情報源から集めた354件の記録を収めている。

正確性に関する注記：以下に示す数値はすべて、アーカイブ自身が公開しているcode>dist/stats.json/code>（バージョン2026-09-22）および実際のページから読み取ったものです。9月23日のローンチ告知では、340件の記録、548件の情報源、被害が確認された126件と引用されていました。これらは投稿時点での数値であり、アーカイブは継続的に更新されているため、両者の数値はおよそ1日分の取り込み量だけ異なります。開発中にアーカイブのREADMEと実際のページでバッジの数値が食い違った場合、信頼すべきなのは実際のページとJSONエクスポートの方です。

アーカイブに実際に含まれているもの

これはニュースフィードではなく、CVEリストでもありません。各エントリは構造化されたフロントマターを持つ単一のMarkdownファイルで、出来事が発生した月ごとに分類され、各エントリには少なくとも1つの出典が付いています。このデータセットはCC BY 4.0の下で公開され、公開リポジトリにミラーリングされているため、スクリーンショットを撮るのではなく、全体をクローンし、差分を比較し、引用することができます。

対象期間は22か月間にわたり、2024年12月の前駆事象から2026年9月22日まで及び、興味深いのはその分布です。深刻度は、重大45件、高139件、中77件、低8件、情報85件に分かれます。情報源の信頼度は、グレードA 302件、グレードB 47件、グレードC 2件、グレードD 3件に分かれます。実世界での被害が確認されたレコードは127件、明確に除外されたものは142件、nullのままのものは85件です。

最後の3つの数字こそ、アーカイブをざっと流し読みするのではなく注意深く読む価値がある理由だ。354件という記録数は、354件のインシデント数ではない。そのうちそもそもインシデントとして分類されているのは138件だけで、残りは脆弱性の開示、研究デモンストレーション、脅威レポート、政策の動きだ。この5つをまとめて数えることこそ、見出しの数字が誤る典型例であり、だからこそアーカイブはそれらを区別して管理し、フィルタリングできるようにしている。

なぜ「ジェイルブレイクはインシデントではない」がまさに核心なのか

AIセキュリティ事象のほとんどのコレクションは、一つの区別を潰してしまう。実際に損害を引き起こしたエージェントは、それが可能だと示した研究者と同じものではない。その単一の混同こそが、学会のデモを侵害の見出しに変えてしまい、このアーカイブが拒むために作られているものである。

その重みを担うのは3つのフィールドだ。code>real_harm/code>は、被害者が確認されたかどうかを記録する。code>ai_involvement/code>は、一次情報源——ベンダー、被害者、法執行機関、または公式報告書——がAIの関与を確認したかどうかを記録し、帰属が争われているものはデータセットに残したうえでラベル付けされる。code>kind/code>は、そのエントリがどの種類の文書なのかを記録する。情報源のない記録は登録されない。証拠が矛盾する記録は、どちらの方向に読むとより都合がよいかで決着させるのではなく、係争中としてマークされる。新しい証拠が届けば、記録は更新され、その変更は黙って上書きされるのではなく改訂履歴に書き込まれる。

アーカイブはそのルールを自らに適用してきた。自身の検証ラウンドの中で、実証できない2件のエントリを削除し、ある侵入がどれほど迅速に進行したかについて広く流布した主張を訂正し、根拠となる証拠が伝聞であることが判明した際には3件目のエントリの信頼度グレードを引き下げた。何も削除したことのないインシデントデータベースは、チェックされていないデータベースである。

これが並べ替えの基準とする12の攻撃サーフェス

すべてのレコードには12種類のタイプのうち1つ以上がタグ付けされており、各タイプにはそれぞれ月ごとの件数がある。ガバナンスとポリシーが65件で最大のカテゴリだが、そのうち確認された被害があるのは1件のみである——これは規制活動としては正しい形であり、インシデント数として引用するのは誤解を招く。資格情報の悪用が55件で続き、確認された被害者は40人で、データセット全体で最も高い被害密度である。エージェントの兵器化は51件で、確認された被害は28件である。間接的プロンプトインジェクションは45件のレコードがあるが、確認された被害は5件のみであり、これはデータセット全体で能力と結果の乖離を最も明確に示している：それは最も研究されている攻撃クラスであり、実際の現場では最も成果の少ないものの1つである。サプライチェーン汚染は36件のレコードで、確認された被害者は27人——これは全体で最悪の比率である。

2026年9月は、その主張を裏付ける月です。

2026年9月だけで51件の記録が登録され、これはこの期間のこれまでのどの月の2倍以上にあたる。これはセキュリティの突然の崩壊ではない。記録管理がようやく1年分の蓄積された出来事に追いついた月であり、重要なのはその内訳だ。悪意あるcode>.git/config/code>、つまりモデルに到達する前に7つのコーディングエージェント内で攻撃者のコードを実行するものに関するクリティカルな項目、実際に悪用されているLangflowの脆弱性、印刷管理ベンダーにおけるAIエージェントスウォームのキャンペーン、そして上流でサプライチェーンに侵入するnpmワームに関する項目だ。これらと並んで、OWASP Agent Control Standard、エージェントの脱走に言及したEUの一般教書演説、そして1件のインシデントを制御喪失の警告として扱った国連パネルのブリーフに関する情報提供項目がある。

韓国語の項目、そして地域フィールドが意味しないこと

アーカイブのcode>region/code>フィールドは、ベンダーの本社所在地ではなく、イベントが実際に発生した場所を示す——国境を越えるベンダーの開示は常にグローバルとして申請されるため、354件の記録のうち291件には単一の国タグが付いていない。KRタグが付いた記録は2件あり、いずれもグレードAの情報源を持つポリシー項目で、確認された被害はない。2025年4月に韓国が国内アプリストアからDeepSeekを削除した件と、2026年2月にNaver、Kakao、Karrotが採用したOpenClawの全社的禁止措置である。

その抑制は意図的なものだ。地域件数が2であることは、韓国でAIセキュリティ事案が2件起きたという主張ではない。それは、対象期間内に韓国に該当し、記録に足るだけの強い一次情報源がある事案が2件あったという主張だ — そしてこのアーカイブは、韓国企業の顧客にどこか別の場所で起きた事案で国別ページを水増しするよりも、小さくても正直な数字を公表するほうを選ぶ。

引用する前に信頼度グレードを読み解く方法

信頼度は重大度ではなく情報源の品質に関するものであり、グレードDは虚偽を意味しない — 当事者間で見解が対立しているという意味であり、一方の側だけを引用すべきではない。グレードAは一次情報源を意味する。すなわちベンダー、被害者、法執行機関、または公式報告書である。グレードBは、検証可能な詳細を伴う研究所または大手メディアを意味する。グレードCは二次情報のみを意味する。グレードDは、事実または帰属が争われていることを意味する。354件中302件で、グレードAはデータセットの85%を占めており、これはインシデント報告としては異例に高く、「情報源なしなら登録なし」ルールの直接の結果である。

率直な注意事項は明白に述べておく価値がある。なぜならアーカイブ自体がそう述べているからだ。2件の記録はグレードCのままで、3件がグレードDである。85件の記録は情報提供レベルの深刻度を持つ。これらはインシデントではなく、タイムラインの連続性のために保持されたポリシーまたは脅威レポートの項目だからである。このリポジトリは作成から3週間で、スターもリリースもなく、その手法に対する外部監査も受けていない。これは公開の場で公開されたデータセットであり、査読済みの研究ではない。

これが別のベンチマークよりも重要な理由

エージェントがブラウザ、シェル、認証情報、コード実行、本番環境へのアクセスを手に入れるにつれて、セキュリティ上の問いは、モデルが何をなし得るかではなく、そのモデルを使ってすでに何が行われたか、へと変わる。ベンチマークは最初の問いにはよく答えるが、二番目の問いにはまったく答えない。情報源の品質によって格付けされ、実際に誰かが害を受けたかどうかで絞り込まれたインシデントのアーカイブだけが、二番目の問いに答える唯一の種類の道具である——そしてそれは、項目が追跡可能で、訂正可能で、自由に再利用できる場合にのみ機能する。

現在公開されているのはこれです。データセットは次の場所にあります: a href="https://www.orcarouter.ai/incident-archive">orcarouter.ai/incident-archive/a>、生のMarkdown、JSONとCSVのエクスポート、およびスキーマは次の場所にあります: a href="https://github.com/Continuum-AI-Corp/Orca-AI-Incident-Archive">公開リポジトリ/a>、修正はレコードのリビジョン履歴を通じて行われます。そこに収録すべき出来事をご存じなら、投稿の方法はMarkdownファイル1つと少なくとも1つの情報源です。情報源がなければ、掲載はありません。

アーカイブを公開しているOrcaRouterは、200以上のモデルにまたがる単一のOpenAI互換エンドポイントを運用しており、プロバイダーの料金への上乗せはなく、モデル間で自動フェイルオーバーを行います——簡単な呼び出しには安価なモデルを、難しい呼び出しにはより強力なモデルをエージェントに指定することを可能にする、まさにそのルーティング層であり、これはまさに上記のインシデントの多くが見つかったアーキテクチャです。