取締役会に半分だけの答えを持って臨むCISO

今後数カ月で何百もの企業で起こるであろうシナリオを考えてみてください。CISOが取締役会の会議に入り、「当社のOpenClaw戦略はNemoClawです。NVIDIAのOpenShellがポリシーエンジンです。Cisco、CrowdStrike、Microsoftもすべてこれを基盤にしています。これで万全です」と話します。

取締役会はうなずき、スライド資料も印象的です。CISOは実際に作業を行い、ランタイムを評価し、適切なインフラパートナーを選定し、ネットワークガードレール付きのサンドボックス環境にエージェントを展開しました。ランタイムセキュリティの観点から見れば、アーキテクチャは堅牢です。

6カ月後、CMMCアセッサーがやってきます。最初の質問はランタイムサンドボックスについてではありません。ネットワークガードレールについてでもありません。エージェントがどのモデルを使っているかでもありません。

質問はこうです。「このエージェントがどのCUIにアクセスしたのか、その認可は何か、どの暗号化を使ったのか、そのアクセスを人間の承認者に紐付ける監査証跡を提示してください。」

その時、CISOはランタイムポリシーとコンプライアンスポリシーが別物であることに気付きます。そしてその時点で、コンプライアンスギャップは6カ月間にわたる統制されないエージェントのやり取りによって拡大し、遡及的な監査ができなくなっています。アセッサーが必要とする証拠は存在しません。CISOが怠慢だったからではなく、アーキテクチャが誤ったレイヤーに対応していたからです。

このシナリオは仮定の話ではありません。Jensen Huang氏の「ポリシーエンジン」という主張と規制コンプライアンス要件を混同した結果として、予測可能な結末です。この違いを理解することが、2026年にCISOやコンプライアンス責任者が下す最も重要なガバナンス判断となります。

Huang氏が実際に語ったこと—その本当の意味

ここでは正確さが重要です。GTC 2026基調講演で、Huang氏はNVIDIA OpenShellをNemoClawスタックの一部として紹介し、これらの技術が「世界中のSaaS企業のポリシーエンジン」として機能できると述べました。

NVIDIAのVP Kari Briski氏はカンファレンス前の記者説明会でさらに説明しました。「OpenShellは、clawの下層に不足していたインフラ層を提供し、エージェントが生産的に活動するために必要なアクセスを与えつつ、ポリシーベースのセキュリティ、ネットワーク、プライバシーのガードレールを強制します。」

これらの発言はOpenShellの機能を正確に表しています。OpenShellは、エージェントの実行をサンドボックス化し、ネットワーク制御を強制し、ランタイムレベルでデータ分離を管理し、エージェントが定義された境界内で動作するためのインフラを提供するオープンソースランタイムです。これは意義があり、必要な機能です。

しかし「ポリシーエンジン」は、コンプライアンスの文脈ではNVIDIAの使い方とは根本的に異なる特定の意味を持ちます。HIPAAのコンプライアンス責任者が「ポリシーエンジン」と聞けば、PHIへのアクセス制御、最小限必要性の強制、暗号化の検証、監査証跡を思い浮かべます。CMMCアセッサーが聞けば、CUIへの認可されたアクセス、文書化された制御、証拠パッケージを想起します。Huang氏が言う「ポリシーエンジン」は、SaaSアプリケーションとエージェントのやり取りにおけるランタイムガードレールを指します。

どちらの使い方も正当です。危険なのは、それらを混同することです。

ギャップの技術的アーキテクチャ：ランタイムポリシーとデータガバナンスポリシーの違い

ランタイムポリシーとデータガバナンスポリシーの違いは言葉の問題ではなく、アーキテクチャの問題です。エンタープライズスタックのどこでそれぞれが機能するのかを理解することが、OpenClaw戦略を完成させるために不可欠です。

ランタイムポリシー（OpenShellの領域）はエージェント実行層で機能します。例えば「このエージェントはこのツールを呼び出せるか？」「このエージェントはこのネットワークパスにアクセスできるか？」「このエージェントは適切なサンドボックス内で動作しているか？」「実行環境はシステム全体から分離されているか？」といった問いに答えます。これらは、エージェントがコンピューティングプロセスとして何を許可されているかを制約するインフラレベルの制御です。

データガバナンスポリシー（コンプライアンス領域）はデータアクセス層で機能します。「このエージェントはこの特定のファイルにアクセスできるか？」「どの認可の下で、誰が人間の承認者か？」「データは検証済みの暗号化で保護されているか？」「すべてのアクセスが改ざん検知可能な記録に記録されているか？」「この監査記録は特定の規制要件にマッピングできるか？」といった問いに答えます。これらは、エージェントがどの情報に触れられるかを制約し、コンプライアンスに必要な証拠を生み出すデータレベルの制御です。このレイヤーがなければ、AIエージェントが増加する中で、企業はデータセキュリティポスチャ管理の基盤を持てません。

Kiteworks 2026予測は、企業がAIのデータガバナンス要件をどれだけ満たせていないかを示しています。AIデータゲートウェイを中央集約しているのは43%のみ。19%は一貫性のないポイントソリューションを寄せ集めて対応。7%はAI専用の制御が全くありません。

OpenShellはこれらのデータ層のギャップを一切埋めません。そもそもそのために設計されていません。エージェントのランタイムを安全にするために設計されたものであり、全く別の課題です。

主要な規制フレームワークが本当に求めていること—OpenShellが及ばない理由

規制が規制するのはエージェントではなく、データです。この違いこそがコンプライアンスギャップの根本です。

HIPAAは、対象事業者に対し、保護対象保健情報（PHI）へのアクセス制御（§164.312(a)(1)）、最小限必要性の強制（§164.502(b)）、PHIアクセスの監査ログの維持（§164.312(b)）、電子PHIへの暗号化適用（§164.312(a)(2)(iv)）を求めています。例えばAIエージェントが患者記録を取得して退院サマリーを作成する医療機関では、そのエージェントもこれらすべての要件の対象です。OpenShellのサンドボックスはファイルレベルで最小限必要性を強制できず、エージェントが現在のワークフロー外の患者記録にアクセスするのを防げません。どの患者のどの記録にアクセスしたかを示すPHI専用の監査ログも生成しません。データ保存時にFIPS 140-3認証済み暗号化も適用しません。OCR調査官がエージェントのPHI操作に関するアクセス制御の証拠を求めても、ランタイムガードレールでは不十分です。

CMMCは、制御された非公開情報（CUI）への認可されたアクセスと文書化されたアクセス制御（AC.1.001、AC.2.006）、CUIアクセスの監査ログ（AU.2.042）、検証済み暗号化（SC.3.177）を要求します。AIエージェントで技術データパッケージを処理する防衛請負業者は、すべてのエージェントによるCUI操作が特定の個人によって認可され、操作レベルでログ記録され、検証済み暗号化で保護されていることを示さなければなりません。OpenShellのネットワークガードレールは、これらの具体的な実践要件には対応していません。CMMCコンプライアンスアセッサーは、エージェントの行動を人間の承認者に紐付ける委任チェーンを求めますが、これはデータガバナンス層でしか実現できません。

PCI DSS 4.0は、カード会員データへのアクセス制限（要件7）、カード会員データの暗号化（要件4）、すべてのアクセスのログ記録（要件10）を求めます。NemoClawランタイムで決済データを処理するOpenClawエージェントも、ランタイムがどれだけサンドボックス化されていても、これらすべての要件の対象です。QSA（認定セキュリティ評価者）が評価するのはランタイムではなく、カード会員データへのアクセスがPCI DSS要件通りに制限・暗号化・ログ記録されているかどうかです。

SOXセクション404は、財務データに対するIT全般統制（ID・アクセス管理、変更管理、監査証跡など）を要求します。四半期数値の取得、口座照合、レポート作成など財務報告データにアクセスするエージェントも、人間の従業員と同じITGC制御下で動作しなければなりません。これらの制御は監査人に対し、要求に応じて証拠を提示できる必要があります。

すべての場合において、規制要件が対象とするのはデータ層であり、ランタイム層ではありません。OpenShellはランタイムを安全にしますが、データアクセスをコンプライアンス対応にはしません。

マイクロソフトの証明：NVIDIAのパートナーでさえ違いを認識

ランタイムとデータの違いを最も強く裏付けるのは、NVIDIA自身のパートナーです。Microsoft Securityは、NemotronとOpenShellを通じてNVIDIAと敵対的学習で提携し、Microsoft SecurityのNEXT AIチームVPであるAlexander Stojanovic氏は「AIベース攻撃の検知・緩和で160倍の改善」と報告しました。これは、エージェントが操作・侵害・武器化された場合のランタイム脅威検知における大きな進歩です。

同時に、Microsoftのセキュリティブログでは、OpenClawの安全な運用に関する詳細ガイダンスを公開し、「永続的な認証情報を持つ信頼できないコード実行」として扱い、専用かつ非特権の認証情報を用いた完全分離環境でのみ展開することを推奨しました。このガイダンスでは、ローカルで実行されるエージェントはホストマシンの全特権を継承し、永続メモリにより侵害データがセッションをまたいでアクセス可能となること、従来のセキュリティツールではエージェントの挙動検知が難しいことを明確に警告しています。

この2つの立場は矛盾していません。むしろ補完的であり、本稿が述べる多層アーキテクチャをまさに示しています。MicrosoftはOpenShellによるランタイム敵対的保護（レイヤー2）に投資しつつ、ランタイム保護だけではデータアクセスリスク（レイヤー3）は解決しないことを認識しています。AI攻撃検知で160倍の改善というのは、侵害されたエージェントをより早く発見できるという意味です。エージェントがアクセスしたデータがガバナンスされ、暗号化され、証拠保全されたかどうかは別問題であり、コンプライアンス監査人が求める証拠保全（証拠保管の連鎖）にはなりません。

MicrosoftというNVIDIAの公式セキュリティパートナーですらこの違いを公式ガイダンスで明確にしているのですから、エンタープライズのCISOもアーキテクチャ判断でこの違いを維持すべきです。

CiscoとCrowdStrikeのエコシステム：レイヤー1・2は優秀、レイヤー3は沈黙

NemoClawを中心に構築されるエコシステムは、この補完的な位置付けを強調しています。CiscoのAI Defenseはエージェント実行を保護し、NemoClawスタックに統合された最初のエンタープライズセキュリティソリューションの一つでした。CrowdStrikeのSecure-by-Design AI Blueprintは、脅威検知保護をエージェント展開ワークフローに直接組み込んでいます。LangChain統合により、ローカルエージェント開発時にもランタイムレベルでガバナンスフックが利用できます。

これらはすべて価値あるセキュリティ機能ですが、いずれもランタイムやインフラ層で動作します。どれも個々のファイル操作にABACポリシーを強制することはなく、エージェントがフォルダーを閲覧するのと中身をダウンロードするのを区別できません。どれもHIPAA、CMMC、PCIコンプライアンス、SOX制御要件にマッピングされる規制特有の証拠パッケージを生成しません。どれもエージェントの行動から人間の承認者までの委任チェーン（コンプライアンスアセッサーが求める証拠リンク）を保持しません。どれもエージェントがアクセスするデータ保存時にFIPS 140-3認証済み暗号化を適用しません。

CrowdStrikeは、OpenClawのセキュリティリスクに関する詳細分析を公開し、Falcon for ITを通じてエンタープライズ全体の検索・削除コンテンツパックをリリースしました。彼らの焦点は検知と対応—OpenClawが管理対象エンドポイントのどこに展開されているかを特定し、露出を把握し、リスクを是正することです。これはレイヤー2の仕事であり、重要な仕事です。しかしレイヤー3—エージェントがどのデータにアクセスしたか、その際のコンプライアンス制御、監査証跡—は、NVIDIAエコシステムのどのパートナーも対応していません。エコシステムはエージェントを守りますが、エージェントが触れるデータは誰も守っていません。

Kiteworks Compliant AIがOpenShellの空白を埋めるコンプライアンスレイヤー

Kiteworks Compliant AIは、エンタープライズOpenClawアーキテクチャのレイヤー3—AIデータガバナンスおよび規制コンプライアンス層で動作します。AIエージェントによる機密エンタープライズデータへのすべての操作をインターセプトし、ID検証、ABACポリシー強制、FIPS 140-3認証済み暗号化、改ざん検知可能な監査ログ取得をデータアクセス前に実施します。AIエージェントと規制対象データの間に位置し、モデル・ランタイム・エージェントフレームワークに依存せずアクセスを制御します。

このアーキテクチャは、コンプライアンス対応AIデータアクセスのための4つの不可欠な要件を実装しています。認証済みエージェントIDは、すべてのデータアクセス前にエージェントを検証し、ワークフローを委任した人間の承認者とエージェントを紐付けます。ABACポリシー強制は、エージェントプロファイル・データ分類・リクエストコンテキスト・操作内容など多次元ポリシーで全データリクエストを評価します。FIPS 140-3認証済み暗号化は、連邦・エンタープライズ監査要件を満たす暗号モジュールで全エージェントアクセスデータを保護します。そして改ざん検知可能な監査証跡は、誰が・何を・いつ・なぜ操作したかを記録し、エンタープライズSIEMシステムに直接連携します。

Kiteworks Secure MCP Serverは、OAuth 2.0認証によるModel Context Protocolを通じて対話型AIアシスタント（Claude、Copilotなど）をガバナンスします。AIデータゲートウェイは、プログラムによるRAGパイプラインや自動化ワークフローをガバナンスします。3つの専用Governed Assistは、ファイル管理・フォルダー操作・フォーム作成という最も一般的な規制データ操作にコンプライアンスを拡張し、すべてID検証・ABAC評価・FIPS 140-3暗号化・改ざん検知ログを実現します。どちらの統合パターンでも、Kiteworks Compliant AIポリシーが一貫して適用されます。

これはOpenShellと競合するものではありません。OpenShellの下に必要なレイヤーであり、コンプライアンスの全体像を完成させます。NemoClawはエージェントの安全な実行を実現し、Kiteworks Compliant AIはエージェントがアクセスするデータのガバナンスと監査証跡を担保し、企業があらゆる規制フレームワークでデータコンプライアンスを証明できるようにします。

CISO・コンプライアンス責任者が次回AIガバナンスレビュー前にすべきこと

まず、現在のAIガバナンスアーキテクチャを3層モデルで監査しましょう。すべての制御をどのレイヤー（コンピュート、ランタイム、データ）に対応しているかマッピングし、ギャップが最も大きいレイヤーを特定します。Kiteworks 2026予測によれば、57%の組織でレイヤー3が最大のギャップとなっています。

次に、取締役会にランタイムポリシーとコンプライアンスポリシーの違いを教育し、「ポリシーエンジン」と聞いて問題が解決したと誤解されないようにしましょう。Kubernetesの例えを使いましょう：ネットワークポリシーでは監査人は満足せず、ランタイムサンドボックスも同様です。特にDORAやNIS 2の対象組織では、ICTリスク管理義務がAIシステムにも明示的に拡大されています。

三つ目に、自社の規制義務（HIPAA、CMMC、PCI DSS、SOX）をAIエージェントのやり取りにマッピングしましょう。どの要件がエージェントのデータアクセスに適用されるか文書化し、現行制御でカバーできているか検証します。多くの組織は重大なギャップを発見するでしょう。AIエージェントのデータアクセスに関する正式なリスク評価は、もはやベストプラクティスではなく、規制上の期待となりつつあります。

四つ目に、エージェント展開を拡大する前に中央集約型AIデータガバナンスを導入しましょう。スケール前にガバナンス基盤を整備した組織は、コストのかかる後付け改修を回避できます。データ層ガバナンスのない1週間は、遡及監査できない統制外のやり取りが1週間増えることを意味します。

五つ目に、社内議論でコンプライアンスガバナンスをAI推進の加速要素として位置付けましょう。AI導入が最も速い組織は、AIデータ保護審査を最速で通過できる組織です。自動化された組み込みガバナンスは、すべての規制企業でAIプロジェクトの障壁となる手動コンプライアンスゲートを置き換えます。

コンプライアンスのタイムリミットは迫っています。EU AI法のハイリスク条項は2026年8月に完全施行されます。Gartnerは、年末までに大企業の50%以上がAIコンプライアンス監査を義務付けられると予測しています。レイヤー3を構築するのは、監査人が来る前です。

Kiteworksがどのように支援できるか、カスタムデモを今すぐご予約ください。

追加リソース

• ブログ記事
  手頃なAIプライバシー保護のためのゼロトラスト戦略
• ブログ記事
  77%の組織がAIデータセキュリティで失敗している理由
• eBook
  AIガバナンスギャップ：2025年に91%の中小企業がデータセキュリティでロシアンルーレット状態
• ブログ記事
  あなたのデータに「–dangerously-skip-permissions」は存在しない
• ブログ記事
  規制当局は「AIポリシーがあるか」ではなく「機能している証拠」を求めている