10月6日、Tigeraが「EU Cyber Resilience Act: Europe Just Put Your AI Agents on a 24-Hour Clock」と題した記事を公開した。この記事では、EUサイバーレジリエンス法（CRA）がAIエージェントを含むあらゆるソフトウェア製品に対して脆弱性の24時間以内報告義務を課す内容と、そのインフラ要件について詳しく紹介されている。
「明日の昼までに答えを出せ」という法的義務
2026年9月11日、EUサイバーレジリエンス法（CRA）の報告義務が強制適用となった。その9日前の9月2日、CISAが7件の脆弱性をKEV（既知悪用済み脆弱性カタログ）に追加した。そのうち3件はAIインフラに関するもので、1件はオープンソースのAIゲートウェイ「LiteLLM」のMCP（Model Context Protocol）エンドポイントに存在していた。
CVEの内容は端的だ。細工したBearerトークン（1文字でも通った）を使えば、認証済みのMCPセッションを開いてツール一覧を取得し、内部システムにアクセスできた。Wizがハニーポットで観察したところ、攻撃者は夏の間この手法で探索を続けていた。パッチは5月に出ていた。
この出来事は、CRAが何を要求しているかを具体的に示している。もしCRAが先に施行されており、その後に悪用が発覚していたとしたら、LiteLLMを製品に組み込んで欧州顧客に出荷していた企業が問われるのは「パッチを当てるか」ではない。問われるのは以下の4点だ。
- どの製品のどのバージョンが影響を受けるか（翌朝までに）
- どの加盟国のどの顧客が動かしているか
- 脆弱性があるだけか、実際に悪用されたか
- 侵害されたコンポーネントは何にアクセスできたか
CRAはAIエージェントに適用されるか
適用される。 ただし法律はAIをそもそも意識していない。CRA（Regulation (EU) 2024/2847）は「デジタル要素を持つ製品」全般を対象とし、ソフトウェア・ハードウェアおよびそのリモートデータ処理ソリューションを含む。エージェント、MCPサーバー、AIゲートウェイ、Helmチャート——いずれもデータ接続を持つソフトウェア製品であり、それで要件は満たされる。欧州委員会が2026年7月27日に公開した67例からなるガイダンス文書には、「エージェント」「MCP」「大規模言語モデル」という語は一度も登場しない。除外規定が存在しないのは、そもそも書かれなかったからだ。
よく誤解される境界が3つある。
- SaaSは原則対象外だが、製品の一部になれば対象に入る。 ブラウザ越しのホスティングサービスはNIS2の管轄だが、製品が依存するリモートデータ処理（それがなければ製品の機能が動かないもの）はCRAの管轄に含まれる。つまり、インストール型エージェントがクラウド上のプランニングサービスなしに動かない構成なら、そのホスティング部分も含めて一つの製品として扱われる。なお、NIS2（Directive (EU) 2022/2555）はEU加盟国の重要インフラ事業者に対するサイバーセキュリティ義務を定める指令であり、CRAとは規制対象・義務内容が異なる。両者の適用関係を把握しておくことが、欧州市場向けサービスを設計する上では不可欠だ。
- オープンソースは商用化した時点で対象になる。 無償・非商業目的で開発されたソフトウェアは除外されるが、サポート契約や製品への組み込みが発生した瞬間に、使用しているすべてのコンポーネントへのデューデリジェンスを含む製造者義務が生じる。「LiteLLMの脆弱性はLiteLLMの問題」ではなく、それを組み込んだ自社製品の問題になる。
- 社内向けエージェントの運用は製造に当たらない。 ただし、製造者がArticle 14に基づいてユーザーへ脆弱性通知を送ってきた場合、受け取った側も「自社のどのエージェントが影響を受け、何にアクセスできたか」を答える必要が生じる。問題の構造は同じだ。
**制裁金の上限はEUR 1,500万または全世界売上高の2.5%**。報告義務の強制適用は2026年9月11日から、製品要件（セキュア・バイ・デザイン）の全面適用は2027年12月から。
24時間クロックの中身
Article 14が定める3段階の報告期限は以下のとおりだ。
| 期限 | 悪用済み脆弱性 | 深刻なインシデント |
|---|---|---|
| 認知から24時間 | 早期警告：悪用の事実と製品提供加盟国 | 早期警告：発生事実と悪意ある行為の有無 |
| 72時間 | 影響製品、悪用の概要、暫定対策 | インシデントの性質、初期評価、対応措置 |
| 最終報告 | 修正提供から14日以内：脆弱性の詳細、深刻度、セキュリティアップデート | 72時間通知から1ヶ月以内：詳細、根本原因、対策 |
報告先はENISAが運用するSingle Reporting Platform（CRA施行と同日に開設）と、主たる事業所が置かれた加盟国のCSIRT、そして影響を受けるユーザー。
重要なのは、クロックの起点がパッチリリース時ではなく「悪用の信頼できる証拠」を得た時点である点だ。エージェントが1台なら午後の作業で済む。10台ならスプレッドシートの話になる。200台、複数チーム、複数フレームワークで構成されたフリートでは、24時間に収まるプロジェクトではない。
2027年12月の「セキュア・バイ・デザイン」要件
報告義務よりも根本的な要件が、Annex I Part Iのセキュア・バイ・デザイン規定だ。これをAIエージェントに当てはめると、多くのチームが現状で持っていないインフラを要求していることが分かる。
| Annex Iの要件 | エージェントで意味すること |
|---|---|
| デフォルトでセキュアな設定 | エージェント・MCPサーバー・ゲートウェイは、追加設定なしにデフォルト拒否が起点 |
| 認証・認可・アクセス管理 | 全エージェントとツールが検証可能なIDを持ち、全呼び出しがそれに基づいてチェックされる。細工したBearerトークンは何も開かない |
| データ最小化 | エージェントは現在のタスクが必要とするものだけを処理し、クレデンシャルが許可するすべてにはアクセスしない |
| 攻撃面の最小化 | エージェントは登録されたツール・モデル・ピアにしか到達できない |
LiteLLMの事例はこの要件を逆から照らし出している。キーのチェックが失敗した際に空のIDへフォールバックする認証は、「セキュア・バイ・デフォルト」の正反対だ。
欧州市場向けにAIエージェントや関連インフラを提供している、あるいは将来的に展開を検討しているエンジニアリングチームにとって、今確認すべき具体的な問いは「自社の製品フリートで、あの4つの質問に24時間以内に答えられるか」であり、その準備状況を今すぐ点検すべきだ。
詳細はEU Cyber Resilience Act: Europe Just Put Your AI Agents on a 24-Hour Clockを参照していただきたい。
