「うちのAIエージェントコード、EU AI Actを通過できる?」気になって本当に5,754個のファイルをスキャンした人がいます。
結果は97%が不合格。でも通過した23個のファイルには、誰も意図していなかった共通点がひとつありました。
法務の仕事だと思ってたのに
EU AI Actの話になると、みんな反射的に弁護士と書類作業を思い浮かべますよね。でも最近Hacker Newsに投稿された記事ひとつが、この思い込みをひっくり返しました。
ある開発者がAIR Blackboxというオープンソースの静的解析ツールを作り、GitHubスター341,000個超の有名オープンソースAIプロジェクト11個、ファイル5,754個をEU AI Actの6条項(Article 9・10・11・12・14・15)基準でスキャンしました。 結果はこうでした。
ここまでなら「やっぱり規制対応は大変だ」で終わる話でした。でも作成者が残した後続コメントが本当のポイントでした。6条項を全て通過したファイルのひとつだったLiteLLMの認証モジュールが目を引いたんですが、最初からコンプライアンスを狙って書かれたコードじゃなかったんです。すでにアクセス制御、構造化ロギング、タイムスタンプ、エラーハンドリングがあっただけでした。
作成者はこうまとめています。「チームがコンプライアンスインフラゼロのままAIエージェントを本番投入しているのは、気にしていないからじゃなく、簡単にしてくれるツールがないからだ。」 つまり、EUが求めているのは特別な法律知識じゃなく、すでに知っているはずのエンジニアリングの基本だったわけです。
6条項のうち本当に足を引っ張るのは?
条項別に見ると難易度差がはっきりしています。Article 11(技術文書化)は98%が通過しましたが、理由が拍子抜けするほど単純です — Pythonエンジニアはもともとdocstringや型ヒントを書きますからね。 逆にArticle 9(リスク管理)は97%が不合格でした。LLM呼び出し周りのエラーハンドリングとフォールバックロジックを見る条項ですが、大半のプロジェクトが「とりあえず動く」程度にしか作られていなかったということです。
| 条項 | 何を見るか | 5,754個スキャン結果 |
|---|---|---|
| Article 9 | リスク管理(エラーハンドリング・フォールバック) | 97%不合格 — 全体最下位 |
| Article 10 | データガバナンス(PII検出・入力検証) | 個別数値非公開 |
| Article 11 | 技術文書化(docstring・型ヒント) | ★98%通過 — 全体最高 |
| Article 12 | 記録保管(ロギング・監査証跡) | 個別数値非公開 |
| Article 14 | ヒューマンオーバーサイト(承認・キルスイッチ) | 個別数値非公開 |
| Article 15 | 正確性・セキュリティ(プロンプトインジェクション対策) | 個別数値非公開 |
作成者が公開したのは6条項中、最下位(Article 9)と最高(Article 11)の2点だけでした。残り4条項の個別通過率は明らかにされていませんが、平均が2.2/6であることを考えると、大半は中間以下だったということになります。
同じスキャナーでフレームワーク3つを丸ごと調べた人もいました。CrewAIとLangFlowは6個中4個を通過、RAGパイプラインツールのQuivrは1個しか通りませんでした。
| CrewAI | LangFlow | ひと目で見ると | |
|---|---|---|---|
| ヒューマンオーバーサイト | 560行のhuman_feedbackデコレーター保有 | ガードレール+プロンプトインジェクション検出 | 両方とも強い |
| 記録保管 | PASS | PASS | Quivrだけ WARN |
| 総合スコア | 4/6 | 4/6 | Quivrは1/6 |
まとめると、コンプライアンススコアは、そのプロジェクトのエンジニアリング成熟度スコアそのものでした。ヒューマンレビューの仕組みとトレーシングをすでに整えていたプロジェクトが、自然と上位に来ていたわけです。
注意
このスキャナーの結果を根拠に他のオープンソースプロジェクトへ「この機能追加して」というIssueを立てるケースもありましたが、反応は良いことばかりじゃありませんでした。ブラウザ自動化フレームワークbrowser-useに立てられたリクエストは「not planned」でクローズされています。 自動スキャンの結果だけを根拠に他人のリポジトリにIssueを立てる前に、一呼吸置いた方がよさそうです。
韓国の話じゃないとは言えない理由
EU AI Actの高リスクシステム義務は2026年8月2日から全面施行されます。違反時は最大3,500万ユーロ、または全世界売上高7%のうち大きい方が罰金です。 EUのユーザー向けにサービスを提供したり、EU市場にAIシステムを出したりする場合、本社が韓国にあっても対象になり得ます。
そして韓国も他人事ではありません。2026年1月22日からAI基本法が施行され、韓国はEUに次いで世界で2番目に包括的なAI規制体系を持つ国になりました。「高影響AI」に分類されると、EU AI Actと同様にリスクの識別・評価・緩和義務が生じ、違反時は最大3千万ウォンの過料が科されます。ただ、科学技術情報通信部が現場の混乱を減らすために最低1年以上規制適用を猶予することにしたため、今すぐの処罰よりも準備期間と見るのが妥当です。
つまりEU側は8月2日という確定した締め切りがあり、韓国国内は猶予期間中でも方向性はすでに決まっているということです。今コードを整えておけば、両方の規制に同時に備えることになります。
3分自己診断 — 今すぐやってみる方法
- インストール
pip install air-blackboxの一行だけ。会員登録もAPIキーも不要。 - スキャン実行
プロジェクトルートでair-blackbox comply --scan. -vを実行。ローカルのみで解析し、コードは絶対に外部へ出ません。 - 弱い条項から確認
大半はArticle 9(リスク管理)・10(データガバナンス)で引っかかります。LLM呼び出し周りのエラーハンドリングと入力検証から見直しましょう。 - すでにあるものを認める
docstringや型ヒントがあれば、Article 11はほぼ通過済みです。新規に作るものとすでにあるものを分けて優先順位をつけましょう。 - フレームワーク専用レイヤーを追加(任意)
LangChainやCrewAIを使っているなら、pip install air-blackbox[langchain]のように専用トラストレイヤーを載せられます。
ポイント
作成者自身もこう釘を刺しています。「これは認証されたコンプライアンステストではなく、潜在的なギャップを見つけるための出発点だ。」 スキャン通過が法的な免罪符ではないということです。
もっと深く知りたいなら
AIR Blackbox公式サイト 価格、対応フレームワーク、インストール方法が一箇所にまとまっています。 airblackbox.ai
GitHubリポジトリ 51個のチェック項目とベンチマーク文書までソースが全て公開されています。 github.com
10秒スキャンチュートリアル インストールから最初の結果解釈までステップ別に見せてくれる実践的な記事です。 dev.to
フレームワーク3つの実践比較 CrewAI・LangFlow・Quivrを直接スキャンした項目別スコア表です。 medium.com
韓国AI基本法ガイド 施行日、高影響AIの定義、事業者の義務3つを弁護士がまとめています。 help-me.kr
コンプライアンスツール比較 AIR Blackbox以外にどんなオープンソース・エンタープライズの代替があるかまとめた記事です。 airblackbox.ai
