スキャン結果が法的判断のように見えるとき
AIエージェントをEUで提供する可能性があるなら、「自社のコードはEU AI Actを通過するのか」という疑問が生まれるのは自然です。ファイルを調べ、条項ごとにPASSを示すツールは魅力的に見えます。法務レビューの前に危険な箇所を素早く見つけられそうだからです。
AIR Blackboxの作成者は、11のオープンソースプロジェクトのPythonファイル5,754件を検査し、平均スコアは2.2/6で、6条項すべてでPASSとなったのは23ファイルだけだったと報告しました。Article 9ではファイルの97%、Article 12では89%、Article 14では84%で、作成者が対応付けたシグナルを見つけられませんでした。
ただし、これを「EU AI Actがコードを検査し、97%を不合格にした」と読むべきではありません。EU機関による調査でも、法律上の適合性評価でもありません。ツール作成者が定義したファイル単位のヒューリスティックの結果です。
23件のPASSが実際に意味すること
当時のベンチマークでは、個別条項のPASSは、その条項に結び付けられた複数の下位シグナルのうち少なくとも1つがファイル内で見つかったことを意味していました。23ファイルは6条項それぞれでこの条件を満たしたファイルであり、EU AI Actの6条項に法的に準拠していると判断されたファイルではありません。
ベンチマーク当時、作成者はArticle 9にリスク分類・アクセス制御・リスク監査を、Article 15にエラー処理やテストなどを対応付けていました。 作成者が例として挙げたLiteLLMの認証モジュールには、アクセス制御、構造化ログ、タイムスタンプ、エラー処理がすでにありました。 ここから得られる示唆は「23ファイルには特別な秘密があった」ではなく、日常的な運用統制が静的解析でも有用な手がかりとして現れ得るという程度です。残りのPASSファイル全体に共通する点は、公開資料だけでは確認できません。
この数値をベンチマークとして再現するのは困難です。
検査に使われたリポジトリごとのコミット、ファイル選定基準、raw JSONは、現在公開されている経路から再現できませんでした。偽陽性・偽陰性率を検証した独立評価も確認できていません。したがって、2.2/6や0.4%を自社プロジェクトの合格基準や業界平均として使うべきではありません。
法律が見るのはファイルではなくシステムです
EU AI Actの該当義務は、単一のコードパターンより広範です。Article 9は、高リスクAIシステムのライフサイクル全体にわたり、反復的に実施・文書化されるリスク管理体制を求めています。Article 11の技術文書も、docstringや型ヒントではなく、当局がシステムの適合性を評価できるよう、市場投入前に作成し、最新状態に保つ文書です。
| 条項 | 法律が求めるシステムレベルの確認 | v1.15.0スキャナーが探す主な手がかり |
|---|---|---|
| Article 9 | リスクの特定・評価・緩和と定期的な見直し | エラー処理、fallback·recovery |
| Article 11 | 適合性評価を可能にする最新の技術文書 | 文書化・型情報 |
| Article 12 | システム寿命の間、事象を自動記録する能力 | ログ・監査証跡の呼び出し |
| Article 14 | 出力を無視・上書きし、安全に停止するための人による監督手段 | human-in-the-loop、使用量・予算統制 |
| Article 15 | 正確性・堅牢性・サイバーセキュリティ | retry·backoff、プロンプトインジェクション防御、出力検証 |
右列は現在公開されているv1.15.0実装を要約したもので、5,754ファイルを検査した当時の対応付けとは異なります。 現在のコードスキャナーは、エラー処理とfallback·recoveryをArticle 9に、human-in-the-loopと使用量・予算統制をArticle 14に、retry·backoff、プロンプトインジェクション防御、出力検証をArticle 15に配置しています。
ログ呼び出しがあるからといって、保持期間や監査可能性が証明されるわけではありません。承認関数があっても、運用者が適時に介入できるかは分かりません。スキャナーは証拠ではなく、確認すべき場所を示すナビゲーターとして使うのが適切です。リポジトリも、このツールは認定済みのコンプライアンステストではなく、潜在的な空白を見つける出発点だと明記しています。 自己評価は準備済みの72個のfixtureと12個の検査を対象としたものであり、任意の運用コードに対する正確性を保証するものではありません。
最初のスキャンは結果の出所を分けることから始めます
Python 3.10以上、検査するプロジェクトのローカルソース、パッケージをインストールしてコマンドを実行する権限が必要です。以下の手順は法的準拠の判断ではなく、コードから初期的な統制の手がかりを探す作業です。確認済みの配布版v1.15.0を基準に説明しますが、更新により検査条件や出力が変わる可能性があります。
- プロジェクト環境にパッケージをインストールします。
pip install air-blackbox - まずインストール済みのバージョンとヘルプを記録します。 検査レポートにパッケージバージョンと実行日を残し、インストールされたコマンドのヘルプでオプションを確認してください。過去のベンチマークの条項マッピングを、現在の出力にそのまま当てはめてはいけません。
- プロジェクトルートへ移動します。 運用リポジトリなら、別ブランチまたは読み取り専用コピーから始めてください。
- 最初の比較は、選択的分析と履歴保存を無効にして実行します。
air-blackbox comply --scan. -v --no-llm --no-save
v1.15.0の既定コマンドはローカルゲートウェイの状態を確認し、静的検査とランタイム検査をともに出力します。Ollamaと既定モデルがあればAI分析を実行でき、既定設定では検査履歴もローカルに保存します。上記オプションは選択的LLM分析と履歴保存を除外し、最初の静的結果を比較しやすくします。 - ゲートウェイ未接続と統制不在を区別します。 localhost:8080のゲートウェイがなくても、静的検査は続行できる場合があります。このときランタイム検査で観測データがないという結果は、統制がない証拠ではなく、ランタイムをまだ検証できていないこととして別途記録してください。
- 検査ごとの状態とevidence文言を一緒に保存します。 現在のCLIは、過去の事例における条項別6/6スコアではなく、個別検査ごとにPASS·WARN·FAILを出力します。PASSも常に統制シグナルを見つけたことを意味しません。たとえばArticle 9のエラー処理検査は、直接のLLM呼び出しを見つけなかった場合に条件付きでPASSになることがあります。状態だけを転記せず、検査条件とevidenceも一緒に読んでください。
- 位置が出力された項目だけをファイルに結び付けます。 一部の検査は、ファイル名や行位置ではなく「N個のファイルで発見」のような集計だけを示します。位置のない結果をコード位置が自動的に確認されたものとして記録せず、その検査の検出パターンに基づき、別途コード検索と手動確認を行ってください。
- システム証拠と照合します。 PASS·WARN·FAILはいずれも法的判断ではありません。リスク登録簿、最新の技術文書、実際のログ保持、人による停止権限、正確性・堅牢性・セキュリティのテストで統制が機能しているかを確認します。
- 最後に適用範囲を分類します。 システムが高リスク区分に該当するか、組織が提供者とデプロイヤーのどちらに当たるか、どの施行スケジュールが適用されるかを別途検討してください。
最初の成功基準は6/6ではありません。 インストールしたバージョンと実行オプション、検査ごとの状態とevidenceを保存し、実際に位置が出力された項目だけを該当ファイルに結び付ければ、最初の段階は完了です。位置のない集計結果とランタイムデータがない検査は、後続の検索・運用確認リストとして分けてください。
EU向けかどうかと施行日も別途確認が必要です
EU域外の事業者でも、AIシステムをEU市場に投入・提供する場合や、その出力がEUで使用される構造なら適用範囲に入る可能性があります。ただし、EUの利用者が1人いるというだけで一律に結論づけることはできません。提供者・デプロイヤーの役割と、実際の市場提供関係をあわせて確認する必要があります。
施行スケジュールも、2026年8月2日という1日だけに単純化してはいけません。法律は原則として同日から適用されますが、現在の公式案内では、Annex IIIの特定の高リスク領域は2027年12月2日、規制対象製品に組み込まれたAnnex I高リスクシステムは2028年8月2日と区分されています。禁止慣行、AIリテラシー、汎用AIの義務には別のスケジュールが適用されます。
罰金も違反の種類ごとに異なります。最大3,500万ユーロまたは全世界年間売上高の7%は、Article 5の禁止慣行違反に対する上限です。Article 16など一般的な事業者義務違反の上限は1,500万ユーロまたは3%であり、中小企業には金額と割合のうち低い上限が適用されます。 Article 9の警告を直ちに「7%の罰金リスク」と結び付けてはならない理由です。
韓国の人工知能基本法は、公式の法令沿革によると2026年1月22日に施行されました。 ただし、EUスキャナーの結果から国内法の適用有無まで判断することはできません。国内の分類と義務は、別途公式法令に基づいて検討する必要があります。
さらに深く調べるなら
Regulation (EU) 2024/1689統合版 Article 2·9·11·12·14·15·99の現行文言を確認すると、静的解析シグナルとシステム義務の違いを確認できます。 eur-lex.europa.eu
AI Act公式ポリシー案内 義務ごとの適用時点と高リスクシステムの日程を確認する際に役立ちます。 digital-strategy.ec.europa.eu
airblackbox/airblackbox 現在のインストールコマンドと静的ギャップ分析の限界を確認できる公式リポジトリです。 github.com
AIR Blackbox v1.15.0ソース 現在のCLIが静的・ランタイム検査、選択的Ollama分析、ローカル履歴保存をどう処理するか確認できます。 raw.githubusercontent.com
