Microsoft Intuneに追加された「Local AI Agent Baseline – OpenClaw」は、OpenClawのような未承認のローカルAIエージェントを制限するためのセキュリティベースラインです。結論から言うと、すぐ全社展開する設定ではなく、まずは「どの端末でローカルAIエージェントやNode.js、WSLが使われているか」を棚卸しし、影響範囲を確認してから段階的に展開すべき機能です。
2026年6月3日に更新された公式設定リファレンスでは、このベースラインはプレビュー扱いで、OpenClawなどの未承認ローカルAIエージェントが使う一般的な実行経路を妨げる目的で提供されています。特にNode.js実行ファイルからの送信TCP通信をブロックするファイアウォール規則が含まれるため、開発者PCや自動化端末では業務影響が出る可能性があります。(Microsoft Learn)
Microsoft IntuneのOpenClawベースラインとは
Microsoft IntuneのOpenClawベースラインは、正式名称では「ローカル AI エージェント ベースライン – OpenClaw」と呼ばれるセキュリティベースラインです。Microsoft Learnの一覧では、2026年5月版の「Version 1」として、Intuneの利用可能なセキュリティベースラインに追加されています。(Microsoft Learn)
通常のセキュリティベースラインと同じく、管理者はIntune管理センターの「エンドポイント セキュリティ」からプロファイルを作成し、対象グループへ割り当てます。ベースラインは、個別の設定を一つずつ探すためのものではなく、Microsoftが推奨する構成をまとめて確認・展開するためのテンプレートです。Intuneのセキュリティベースラインは、関連するセキュリティチームが推奨するWindows設定のグループとして提供され、必要に応じて組織向けにカスタマイズできます。(Microsoft Learn)
今回のポイントは、対象が従来のOS全般のハードニングではなく、ローカルAIエージェントという新しい運用リスクに向いていることです。
OpenClawのようなローカルAIエージェントは、ユーザー端末上で動作し、メッセージング、API、ファイル、開発ツールなどと連携する場合があります。便利な一方で、管理外のエージェントが社内データや認証情報、業務システムにアクセスできる状態になると、従来のアプリ管理だけでは把握しにくいリスクになります。
何が変わるのか
今回の変更は、「OpenClawという特定アプリだけを完全に禁止するスイッチが追加された」というより、ローカルAIエージェント対策をIntuneのセキュリティベースラインとしてレビューしやすくなった、という理解が実務的です。
公式リファレンスでは、このベースラインにより、OpenClawなどの未承認ローカルAIエージェントが使う一般的な実行パスを妨げる設定を構成すると説明されています。また、Node.jsのようなローカルエージェント実行環境からの送信ネットワーク通信を制限するファイアウォール規則が含まれます。(Microsoft Learn)
| 変更点 | 実務上の意味 |
|---|---|
| OpenClaw向けのセキュリティベースラインが追加 | 管理者がOpenClaw対策をポリシー単位で確認・展開しやすくなる |
| Node.js実行ファイルの送信TCP通信をブロックする規則を含む | OpenClawだけでなく、Node.jsを使う正規業務にも影響する可能性がある |
| WSL関連の設定項目も含まれる | 開発者や検証環境でWSLを使っている場合は事前確認が必要 |
| プレビュー版として提供 | 本番一括展開ではなく、検証・例外設計・段階展開が前提 |
| プロパティカタログによる事前棚卸しが推奨 | いきなりブロックする前に、利用実態を把握できる |
特に注意したいのは、OpenClawだけを狙い撃ちする仕組みではない点です。公式ドキュメントでも、この設定がすべてのエージェント実行パスを完全にブロックするとは限らず、OpenClaw以外のプロセスもブロックする可能性があるため、展開前に各設定を確認・テストするよう注意しています。(Microsoft Learn)
対象になる環境と影響を受けやすい人
Microsoft Intuneのセキュリティベースラインは、管理対象のWindowsデバイスに対して展開するものです。Intuneのセキュリティベースライン機能はWindows 11とWindows 10 バージョン1809以降に適用されますが、Windows 10は2025年10月14日にサポート終了しており、Intuneへの登録や一部機能の利用は可能でも、機能保証は限定的です。(Microsoft Learn)
影響を受けやすいのは、次のようなチームです。
| 対象者 | 確認すべきこと |
|---|---|
| エンドポイント管理者 | 既存の構成プロファイル、ファイアウォールポリシー、セキュリティベースラインとの競合 |
| セキュリティ担当者 | 未承認AIエージェントの利用実態、例外承認ルール、監査ログ |
| 開発者 | Node.js、npm、社内CLI、WSL、ローカル検証環境への影響 |
| 情報システム部門 | ヘルプデスク問い合わせ、例外申請、業務停止時の切り戻し手順 |
| アプリ運用担当 | Windows端末上で動く自動化スクリプトやエージェントの通信要件 |
たとえば、フロントエンド開発者が%ProgramFiles%\nodejs\node.exeを使ってnpmパッケージを取得している場合、送信TCP通信のブロックにより、パッケージ取得、API接続、ローカル開発サーバーからの外部通信などが失敗する可能性があります。
一方、一般事務端末でNode.jsやWSLを業務利用していない場合は、影響が限定的な可能性があります。この差を見極めずに全社展開すると、「セキュリティ強化のつもりが、開発・検証業務を止める」結果になりかねません。
OpenClawベースラインに含まれる主な設定
2026年6月3日更新の公式リファレンスで確認できる主な設定は、WSL関連の項目と、Node.jsを対象にしたファイアウォール規則です。(Microsoft Learn)
| 設定カテゴリ | 設定内容 | 管理者が見るべきポイント |
|---|---|---|
| Windows Subsystem for Linux | WSL1を許可する、Linux用Windowsサブシステムを許可する | 開発者や検証担当がWSLを使っているか。組織としてWSL利用を認めるか |
| ファイアウォール | %LOCALAPPDATA%\Programs\node\node.exe の送信TCP通信をブロック | ユーザー単位で導入されたNode.jsを使う業務がないか |
| ファイアウォール | %ProgramFiles%\nodejs\node.exe の送信TCP通信をブロック | 標準インストールされたNode.js、社内CLI、ビルドツールへの影響 |
| ネットワーク種類 | すべてのネットワークプロファイルが対象 | 社内LAN、VPN、自宅ネットワークなど利用場所を問わず影響する可能性 |
| 通信方向 | 送信トラフィックを対象 | 外部API、パッケージレジストリ、クラウドサービス接続に注意 |
ここで失敗しやすいのは、「OpenClawを使っていないから影響なし」と判断することです。ファイアウォール規則はOpenClaw本体だけでなく、指定パスにあるNode.js実行ファイルの通信を止めます。そのため、OpenClawを導入していない端末でも、Node.jsを使う正規業務があれば影響を受けます。
展開前に必ず確認したいチェックリスト
OpenClawベースラインは、展開前の棚卸しが重要です。Microsoftは、ベースライン展開前にローカルAIエージェントがインストールされているデバイスを特定する方法として、プロパティカタログでローカルAIエージェントのインベントリデータを収集することを案内しています。(Microsoft Learn)
実務では、次の順番で確認すると安全です。
| 確認項目 | 具体的な確認内容 | 判断基準 |
|---|---|---|
| ローカルAIエージェントの有無 | OpenClawなどが端末に存在するか | 未承認なら制限対象。研究・検証利用なら例外審査 |
| Node.jsの利用状況 | 開発、社内ツール、CLI、自動化で使っているか | 業務必須なら除外グループや別制御を検討 |
| WSLの利用状況 | Docker、Linuxツール、開発環境で使っているか | 部門単位で利用可否を決める |
| 既存ポリシーとの競合 | ファイアウォール、設定カタログ、Defender、既存ベースライン | 同じ設定を複数ポリシーで管理していないか |
| 展開対象 | 全社、部門、端末種別、パイロットグループ | 最初は小さなデバイスグループに限定 |
| 切り戻し方法 | 影響発生時に割り当て解除・設定変更できるか | ヘルプデスクが手順を把握しているか |
プロパティカタログでは、Windowsデバイス上のOpenClawなどのローカルAIエージェントを検出する用途が示されています。ポリシー作成時に収集するプロパティを選択でき、初期収集には最大24時間かかる場合があります。(Microsoft Learn)
推奨される展開手順
OpenClawベースラインは、次のように段階展開するのが現実的です。
| フェーズ | 実施内容 | ゴール |
|---|---|---|
| 棚卸し | プロパティカタログでローカルAIエージェント、Node.js、WSL利用状況を確認 | 影響対象を把握する |
| 設計 | 対象グループ、除外グループ、例外承認ルールを決める | 全社一括適用を避ける |
| パイロット | IT部門や限定端末へ割り当てる | 設定競合と業務影響を検証 |
| 部門展開 | Node.jsやWSL利用が少ない部門から拡大 | 問い合わせ傾向を把握 |
| 例外管理 | 開発者・検証端末の例外を期限付きで管理 | セキュリティと業務継続を両立 |
| 定期レビュー | ベースライン更新、利用実態、監査結果を確認 | 設定の陳腐化を防ぐ |
Intuneでセキュリティベースラインプロファイルを作成する場合は、管理センターで「エンドポイント セキュリティ」>「セキュリティ ベースライン」へ進み、対象ベースラインを選択してポリシーを作成します。作成後は割り当てられたグループへすぐにプッシュされ、適用されます。(Microsoft Learn)
実務では、プロファイル名にバージョンと展開リングを入れておくと後で管理しやすくなります。
例：
LAB-OpenClaw-v1-Pilot-IT-202606
LAB-OpenClaw-v1-Production-General-202607
LAB-OpenClaw-v1-Exception-Developers-202607
名前だけで、対象・目的・作成時期が分かる状態にしておくと、半年後のレビュー時に迷いません。
管理者が注意すべき設定競合
Intuneでは、セキュリティベースライン、設定カタログ、エンドポイントセキュリティポリシー、ファイアウォールポリシーなどが同じ設定領域に触れることがあります。
公式ドキュメントでも、複数のセキュリティベースラインやデバイス構成プロファイルを併用すると、同じ設定に異なる値が入り、競合が発生する可能性があると説明されています。(Microsoft Learn)
OpenClawベースラインでは、特に次の競合に注意してください。
| 競合しやすい領域 | 起こり得る問題 | 対策 |
|---|---|---|
| 既存のWindows Firewallポリシー | 同じNode.js通信に対して許可・拒否が混在 | 既存規則と優先順位を確認 |
| 開発者向け構成プロファイル | WSLやNode.js利用前提の設定と衝突 | 開発端末用の別リングを作る |
| Defender for Endpoint関連設定 | セキュリティ基準が重複し、調査が複雑化 | どのポリシーが何を管理するか台帳化 |
| 全社向けベースライン | 一部部門の業務ツールだけ停止 | 除外グループを事前定義 |
| 手動ローカル設定 | 管理外のファイアウォール規則と不整合 | Intune管理に寄せる |
「セキュリティベースラインを入れたら安全」という発想ではなく、「どの設定が、どのポリシーから、どの端末に適用されているか」を追える状態にすることが重要です。
開発者PCでは何が壊れやすいか
OpenClawベースラインで最も影響を受けやすいのは、Node.jsとWSLを使う開発者PCです。
たとえば、次のような作業に影響が出る可能性があります。
| 業務例 | 影響の可能性 |
|---|---|
| npmパッケージの取得 | Node.jsの送信通信がブロックされ、取得に失敗する可能性 |
| 社内Node.js CLIの利用 | API接続や認証処理でエラーになる可能性 |
| フロントエンド開発 | ローカル開発サーバーや外部API接続に影響する可能性 |
| WSL上の開発環境 | WSL関連設定の扱い次第で開発フローに影響 |
| 自動化スクリプト | node.exe経由の外部通信が止まり、処理が途中失敗する可能性 |
開発者PCを守る場合、単純に「開発者は全員除外」では不十分です。除外が長期化すると、未承認AIエージェントのリスクが残ります。
現実的には、次のような設計が向いています。
| 方針 | 内容 |
|---|---|
| 開発端末を専用グループ化 | 一般事務端末とは別のポリシーリングにする |
| 例外を期限付きにする | 例外申請に責任者、理由、期限を持たせる |
| 代替制御を入れる | Defender、アプリ制御、ネットワーク監視、最小権限を併用 |
| 許可済みAIツールを明確化 | 「何を禁止するか」だけでなく「何なら使えるか」を示す |
| 利用実態を継続監視 | 一度の棚卸しで終わらせない |
特に、AIエージェント対策は利用者の生産性とぶつかりやすい領域です。禁止だけを先行させると、ユーザーが別経路でツールを導入し、かえって把握しづらくなることがあります。
プレビュー版として扱うべき理由
OpenClawベースラインはプレビューとして提供されています。Microsoftは、プレビュー版のセキュリティベースラインを運用環境で使うことを推奨しておらず、プレビュー中に設定が変更される可能性があると説明しています。(Microsoft Learn)
そのため、本番環境で使う場合でも、次の条件を満たしてからにしてください。
| 条件 | 確認内容 |
|---|---|
| パイロット検証済み | 少なくともIT部門・代表部門で業務影響を確認した |
| 切り戻し可能 | 割り当て解除、除外グループ追加、設定変更の手順がある |
| 問い合わせ窓口がある | Node.jsやWSLのエラーを受け付ける導線がある |
| 例外申請ルールがある | 開発・研究・検証用途を審査できる |
| 更新確認の担当がいる | ベースラインの新バージョンや既定値変更を追跡する |
プレビュー版を全社展開する場合は、「正式版になったら見直す」では遅いことがあります。最初からレビュー日を決め、30日後、60日後、正式版公開時などに再評価する運用を入れておくべきです。
将来のバージョン更新で注意すること
セキュリティベースラインは、今後新しいバージョンが提供される可能性があります。Intuneでは、新しいバージョンが利用可能になっても既存プロファイルが自動的にアップグレードされるわけではありません。また、新しいバージョンに更新する際は、最新バージョンに基づく新しいインスタンスがサイドバイサイドで作成され、スコープタグや割り当ては引き継がれません。(Microsoft Learn)
これは、OpenClawベースラインでも将来的に重要になります。
やってはいけないのは、古いプロファイルと新しいプロファイルを同じ対象に同時適用して、設定競合を起こすことです。
バージョン更新時は、次の順番で進めます。
| 手順 | 内容 |
|---|---|
| 新旧差分を確認 | 新規設定、削除設定、既定値変更を確認 |
| カスタマイズ維持の要否を判断 | 既存の例外や変更を引き継ぐか決める |
| 新プロファイルを未割り当てで作成 | いきなり本番グループへ割り当てない |
| パイロットへ展開 | 既存プロファイルとの競合を避けて検証 |
| 旧プロファイルの割り当て解除 | 新旧同時適用を避ける |
| 台帳を更新 | どの部門にどのバージョンを適用したか記録 |
OpenClawベースラインだけでは不十分な理由
OpenClawベースラインは有用ですが、AIエージェント対策のすべてではありません。
公式ドキュメントでも、これらの設定ですべてのエージェント実行パスを完全にブロックできるとは限らないとされています。(Microsoft Learn)
たとえば、次のようなケースは別途対策が必要です。
| リスク | ベースラインだけで不十分な理由 | 追加対策 |
|---|---|---|
| 別ランタイムのAIエージェント | Node.js以外で動く可能性がある | アプリ制御、ソフトウェアインベントリ |
| ポータブル実行ファイル | 標準パス以外で動く可能性がある | App Control for Business、Defender検知 |
| クラウド型AIエージェント | ローカル制御だけでは対象外 | CASB、DLP、条件付きアクセス |
| 認証情報の持ち出し | 通信ブロックだけでは防げない | 秘密情報管理、ブラウザ制御、監査 |
| ユーザーの回避行動 | 禁止だけでは別ツール利用に流れる | 利用可能な公式AI環境の提示 |
つまり、このベースラインは「AIエージェント対策の入口」です。ゼロトラスト、アプリ制御、データ保護、ID管理、開発者向けガイドラインと組み合わせて初めて効果を発揮します。
実務でのおすすめポリシー設計
OpenClawベースラインを使うなら、端末を一律に扱わないことが重要です。
おすすめは、次のようなリング設計です。
| リング | 対象 | 方針 |
|---|---|---|
| Ring 0 | IT管理者、セキュリティ担当 | 最初に検証。ログと影響を確認 |
| Ring 1 | 一般事務端末の一部 | Node.jsやWSL利用が少ない部門で確認 |
| Ring 2 | 一般事務端末全体 | 問題が少ない場合に段階展開 |
| Ring Dev | 開発者端末 | カスタム設定または例外管理 |
| Ring Exception | 研究・検証・承認済みAI利用端末 | 期限付き例外と追加監視 |
ポイントは、「開発者だけ特別扱い」ではなく、「リスクと業務要件に応じて別管理する」ことです。
開発者端末には、OpenClawベースラインをそのまま適用しない代わりに、次のような代替策を入れるとバランスが取りやすくなります。
| 代替策 | 目的 |
|---|---|
| 承認済みNode.js配布経路の利用 | 野良インストールを減らす |
| パッケージ取得先の制御 | 不審な外部レジストリ利用を抑える |
| Defender for Endpointの監視強化 | 不審なプロセス・通信を検知する |
| 最小権限の徹底 | エージェントが端末全体を操作できる範囲を狭める |
| AI利用ルールの明文化 | ユーザー判断による危険な導入を減らす |
導入後の確認ポイント
OpenClawベースラインを割り当てた後は、展開して終わりではありません。次の観点で確認してください。
| 確認項目 | 見るべきサイン |
|---|---|
| ポリシー適用状況 | 対象端末に成功・失敗・競合が出ていないか |
| ユーザー影響 | npm、社内CLI、WSL利用者から問い合わせが増えていないか |
| セキュリティ効果 | 未承認OpenClaw利用端末が減っているか |
| 例外の増加 | 例外申請が多すぎないか |
| 競合 | 他のファイアウォール設定と矛盾していないか |
| ヘルプデスク対応 | 問い合わせ時に切り分けできているか |
問い合わせでよく起きるのは、「Node.jsが壊れた」「npmが遅い」「社内ツールが急に通信できない」といった曖昧な報告です。ヘルプデスク向けには、少なくとも次の切り分け項目を用意しておくと対応が早くなります。
| 質問 | 意図 |
|---|---|
| いつから発生したか | ベースライン適用タイミングとの関係を見る |
| どの実行ファイルを使っているか | 対象パスのnode.exeか確認する |
| どの宛先へ通信しているか | ブロック対象の送信TCP通信か確認する |
| 端末がどのグループに属するか | 適用ポリシーを特定する |
| 業務必須か一時利用か | 例外承認の必要性を判断する |
管理者と開発者が今すぐやるべきこと
今すぐ全社展開するより、まずは次の3つを進めるのが安全です。
| 優先度 | やること |
|---|---|
| 高 | プロパティカタログでOpenClawなどのローカルAIエージェント利用端末を把握する |
| 高 | Node.js、WSLを使う部門・端末を洗い出す |
| 中 | OpenClawベースラインのパイロット用プロファイルを作成し、未割り当てまたは限定割り当てで確認する |
| 中 | 開発者・研究部門向けの例外ルールを作る |
| 中 | AIエージェント利用ポリシーを社内に周知する |
| 低 | 正式版や次バージョン公開時のレビュー予定を設定する |
OpenClawベースラインは、単なる「OpenClaw禁止設定」ではなく、エンドポイント管理チームがローカルAIエージェントの利用実態とリスクを見直すためのチェックリストとして使うべき機能です。
特に、Node.jsとWSLを使う端末では業務影響が出やすいため、棚卸し、影響分類、パイロット、例外管理の順に進めてください。一般端末には早めに制御をかけ、開発端末には代替制御を組み合わせる。この分け方が、セキュリティ強化と業務継続を両立する現実的な進め方です。
コメント