記事のサマリー（TL;DR）
- ニューヨーク州RAISE Actはフロンティアモデル開発者を対象とするが、蒸留・ファインチューニングで規制対象外となる抜け穴が指摘されている
- Black Hat Business Hallでは、データアクセス範囲の可視化（Cyera）・エージェント行動監視（Manifold）など「利用側の統制」に特化した製品が多数を占めた
- ChatGPT・Claude Code・MCPサーバーをサービス単位で個別に統制し、Shadow AIの存在を把握することが現場の共通課題
freee・Claude Code・MCPサーバーを導入済みの企業が今押さえるべきAIガバナンス実務
freeeが今回のレポートで示している「AIサービスごとに統制する」という考え方は、すでにClaude CodeやMCPサーバーを業務に組み込んでいる企業に直接関係します。MCPサーバーはツール呼び出しを通じてファイルシステムや外部APIへアクセスするため、「エージェントがどの権限でどこまで実行できるか」を明示しないまま運用すると、意図しないデータへのアクセスや外部送信が発生するリスクがあります。EU AI ActやISO/IEC 42001が参照される一方、製品レベルの統制ルールとの対応関係はまだ曖昧な段階にあり、自社のポリシーを「データ・権限・証跡」の3軸で具体化し、OWASP Top 10 for LLM Applicationsに照らして技術的な制御に落とし込む作業は、各社が個別に行う必要があります。kintoneやSalesforceなど複数SaaSを横断するエージェント構成を検討している場合、どのサービスに何の権限を与えるかの設計がガバナンスの出発点になります。
詳細
Black Hat／DEF CONとは
Black HatとDEF CONは、毎年夏にラスベガスで連続開催される大規模セキュリティカンファレンスです。
Black Hat は、専門家によるトレーニング、最新研究のBriefings、ツールデモのArsenal、企業が製品を紹介するBusiness Hallで構成されます。研究・実務・ビジネスの動向を一つの会場で追えるイベントです。
DEF CON は、参加者コミュニティが運営するVillageを中心に、講演・ワークショップ・CTF・デモが行われます。テーマ別に会場が分かれており、興味のある分野に自分から飛び込む雰囲気があります。
freeeセキュリティチームのhikae氏は今回、Black HatではBusiness Hallでの製品デモ・担当者との対話を中心に行動し、DEF CONでは自身がコントリビュートするOSS（sisakulint）のDemo Labs参加と複数Villageの訪問を行いました。レポートのテーマは「AIガバナンス」に絞られています。
セッション紹介：「AI Safety Theater: What the RAISE Act Regulates, and What It Does Not」
DEF CON Policy Villageで聴講したFinite StateのJoshua Marpet氏によるセッションです。ニューヨーク州のAI規制RAISE Actを題材に、「法律に準拠してもリスクは低減されない」という形骸化リスクを丁寧な分析で明らかにする内容でした。
RAISE Actとは
RAISE Actは、フロンティアモデルを開発する事業者に対し、安全性と透明性に関する義務を課すニューヨーク州法です。2027年1月施行予定で、化学・生物・放射線・核（CBRN）リスク、重大なサイバー攻撃、開発者・利用者の制御を逃れる挙動を主な対象としています。
RAISE Actを3プロセスで評価する
講演ではRAISE Actを「カバーしていること」「意図的に除外したリスク」「コンプライアンス負担と実際のリスク低減の釣り合い」の3軸で評価しています。
カバーしていること：一定規模を超えるフロンティアモデル開発者に対し、安全枠組みの作成・実装・遵守・公開を求め、監査可能な義務を課している点は評価されました。
意図的なスコープ外：対象モデルの定義は「10²⁶ FLOPs / $1億ドルの計算コスト」。蒸留やファインチューニングによって規制対象外になりうる点が指摘されています。対象企業の売上要件は$5億ドルで、売上のないスタートアップは除外されます。危害の閾値も「100人以上への深刻な被害」または「$10億ドルの経済的損失」と極めて高く設定されており、実際のAIリスク低減には論点がずれると批判されています。さらに、モデルを実際に停止させる実効力がなく、連邦法によって無効化されうることもギャップとして挙げられました。
コスト対効果の非対称性：「Who pays isn’t who’s protected（コストを支払う主体と保護される主体が一致しない）」という指摘が印象的でした。開発者側に課されたコンプライアンス負担が、利用側で実際に発生しているAI脅威の低減に直結しないとされています。
コロラド州版RAISE Actからみるポリシー設計の考え方
コロラド州版は対象を「学習する企業」から「利用する企業」にシフトさせた点で評価されています。具体的な変更点は以下の4点です。
- Cover the deployments：採用・刑事司法などハイリスク用途の「利用者側」を対象に
- Create liability：閾値未達でも達成が見込まれる段階から法的効力を発生させる
- Tell the people：規制当局への開示だけでなく、影響を受けた本人への通知義務を追加
- Secure the deployment：「どう学習したか」ではなく「AIシステム全体の安全設計」に重心を移動
実際に保護すべきユーザーと直接向き合う企業にコンプライアンス負担を課す設計が、より実効性のある規制に近いという評価です。
AI規制はどこに向かっているのか
講演者は2026年に12州以上で同等のAI法がモデルとして採用されると予測しています。ただし、リスク低減効果が弱いまま複製されるリスクについても警鐘を鳴らしています。EU AI Actのように、地域ごとに生まれた規制が共通仕様化フェーズを経て実効性を持つプロセスは、日本でも参照できる事例として挙げられています。2026年のトレンドは、「学習」に偏っていた従来の規制が「AIシステム全体」へ適用可能な形に移行しつつある点にあると整理されています。
Business Hallから見た、AIセキュリティのトレンド
Black Hat Business Hallのブースの多くがAIセキュリティ関連製品でした。「Security for AI」「AI for Security」の双方への関心の高まりを示しています。
AI利用で生じうるリスクと、それに対応するポリシー・実装の関係は次のように整理されました。
| AI利用で起こり得ること | ポリシーとして決めるべきこと | 実装で必要になること |
|---|---|---|
| AIが利用目的を超えるデータや権限に到達する | どのデータを誰がどのAIに使わせてよいか | データの所在・公開状態・アクセス権の把握と是正 |
| 利用者が管理外の経路からAIへ情報を渡す | どのサービス・アカウント・操作を認めるか | 利用経路・利用者・操作内容に応じたアクセス制御と記録 |
| 端末に未承認のAIツールが持ち込まれる | どのAIツールや開発支援ツールを利用可能とするか | 端末とソフトウェアの継続的な把握・導入制御 |
| エージェントが許容しない操作を行う | どのツールをどの権限でどこまで実行できるか | ツール呼び出しの追跡・実行時の制御・操作履歴の保存 |
AIが参照できる範囲をモニタリングする
AIのリスクはモデルの性能だけで決まりません。公開リンクが残ったファイル、共有範囲が広すぎる文書、無関係な部署のデータへアクセスできる状態は、エージェントが通常の検索・要約・問い合わせ対応を行うだけで情報漏えいにつながります。
DSPM（Data Security Posture Management）を手がけるCyeraは、データとアクセス権の関係をデータフローとして整理し、AIが到達できるデータ範囲をリアルタイムで把握する製品を展示していました。AIポリシーを実務へ落とし込む際の出発点として機能します。
どのようなAIがどう行動しているのかをモニタリングする
「何が導入されているか」と「何を実行しているか」は技術的に別の仕組みで担保する必要があります。
Glow はCASB的な方式でローカルのAIツール・コーディング支援ツール・開発環境の拡張機能を継続的に把握し、組織が認めていないソフトウェアをスコアリングします。
Manifold はエージェントが動き始めた後の行動監視に特化しています。エージェントがどのツールを呼び出し、どの操作を実行しようとしたかを追跡し、危険な実行を制御します。デモでは、エージェントの起動・LLMへのリクエスト・ツール呼び出しを同一セッションの時系列で確認する画面が示されていました。Harnessのhook機能を利用しているとのことです。
現地の人が今抱えているAIセキュリティの課題
各社製品のルール評価にはOWASP Top 10 for LLM Applicationsが広く使われていました。ただし、特定の規制を主軸にルールを構築している例は少なく、EU AI ActやISO/IEC 42001は「参考にする」位置付けにとどまる印象でした。
規制が対象とする主体・目的と、製品が技術的に防ごうとする脅威は必ずしも一対一に対応しません。OWASP Top 10への準拠が組織のAIポリシー充足を意味するわけではなく、利用する企業側が自社のポリシーとリスクに照らして採用するルール・残すべき証跡・導入するモニタリングツールを決める必要があります。
AIサービスごとに統制する
現場で共通していた考え方は、ChatGPT・Claude Code・MCPサーバーといったAIサービスを個別に把握し、社内ポリシーを具体的な統制に落とし込むことでした。AIを一括りの分類として扱うのではなく、サービスごとに異なるデータの扱い・権限・実行できる操作・利用者を個別に管理する必要があります。
また、組織が把握していないAI利用（Shadow AI）の評価も共通課題でした。未承認利用を単に禁止するのではなく、まず存在を把握し、接続されているデータや業務を評価したうえで許可・制限・代替手段を決められるツールが、実効性のあるAIセキュリティ製品の要件として挙げられていました。
実務で今からできること
freeeはAI倫理に関する基本方針を公開しており、AIMS（AIマネジメントシステム）などで主軸とされる現行の一般的な方針に準拠した社内統制を目指しています。
規制やフレームワークはチェックリストとして扱うのではなく、「自社が守るべきデータや業務」「AIに許可する操作」「例外時の判断者」「必要な証跡」に翻訳したうえで、各製品の可視化・検知・制御の範囲を自社の脅威モデルに照らして選択することが重要だと整理されています。
おわりに
Black Hat／DEF CONで得た最大の学びは、「AIガバナンスに完成された正解はなく、規制・ポリシー・技術的統制を実際の利用環境でつなぐ段階にある」ということです。
自組織でAI利用を考える際の出発点として、以下の3つの問いが提示されています。
- AIは、どのデータにアクセスできるのか
- AIは、誰の権限で、どの操作まで実行できるのか
- 想定外の利用や操作を、どこで止め、何を記録できるのか
規制やフレームワークは論点整理に重要ですが、それをチェックリストとして導入するだけではリスク低減にほとんど寄与しません。AIセキュリティは特定の技術領域だけで解決できるものではなく、既存のセキュリティとガバナンスにAIシステム特有の脅威検知を組み込んでいくアップデート作業だという認識が、今回の参加を通じて得られた結論です。
なお、DEF CONではサプライチェーンセキュリティスキャナsisakulintのDemo Labsでの発表にOSSコントリビューターとして参加し、セキュリティコミュニティとの直接交流も行われました。