Microsoft SecurityのAutoJack AI agent RCE研究でまず押さえるべき結論は、「AutoJackをオン・オフする単独の設定画面がある」のではなく、AIエージェントの開発環境、ローカル制御プレーン、MCP、Web閲覧ツール、Microsoft Defender系の検知、ユーザー周知をセットで確認する必要があるという点です。
2026年6月18日にMicrosoft Security Blogで公開されたAutoJackの研究は、公式分類では「Research」です。対象はMicrosoft Security全体の新機能リリースではなく、AutoGen Studioの開発中機能におけるAI agent RCEの攻撃パターンを示したものです。通常の利用者がすぐに「Microsoft Securityの設定を1つ変更すれば完了」と考えるのは危険です。実務では、自社でAIエージェントやAutoGen Studio、MCP連携、Web要約エージェント、コード実行ツールを動かしている端末や環境を洗い出し、Microsoft Defender、Defender for Cloud、Agent 365、Microsoft Entra Agent IDの管理画面で可視化・検知・制御を確認するのが現実的な対応になります。(Microsoft)
Microsoft SecurityのAutoJack AI agent RCE研究で何が問題になったのか
AutoJackは、外部Webページを閲覧できるAIエージェントが、同じ端末上のローカルサービスに到達できる場合、localhostを安全境界として扱う設計が崩れることを示した研究です。Microsoftの説明では、AutoGen StudioのMCP WebSocket面に関する複数の弱点が連鎖し、エージェントが閲覧したページをきっかけにホスト側でプロセス実行へつながる可能性が示されました。重要なのは、個別の実装不備だけでなく、「外部コンテンツを読むエージェント」と「強い権限を持つローカル制御プレーン」が同じ環境にある構成そのものがリスクになる点です。(Microsoft)
Microsoft Security Blogでは、問題のコードは開発中に発見・修正され、影響を受けるMCP WebSocket面はPyPIで公開されたAutoGen Studioパッケージには含まれていなかったと説明されています。一方で、GitHubのmainブランチからMCP対応を含めてビルドしていた開発者は、修正コミット以降を使う必要があるとされています。つまり、実務上の確認ポイントは「自社にAutoJackそのものがあるか」だけでなく、「同じ構造の危険なAI agent構成がないか」です。(Microsoft)
まず確認すべき対象環境
AutoJackの設定確認では、全社員のMicrosoft 365設定を一律に確認するよりも、AIエージェントを開発・検証・運用している環境から優先して調べます。特に次の条件が重なる場合は、優先度を上げてください。
| 確認対象 | リスクが高くなる例 | 実務上の判断 |
|---|---|---|
| AutoGen Studioや類似のAI agentフレームワーク | AutoGen Studioをソースからビルドしている、MCPサーバーを接続している | PyPI版かソースビルドか、コミット、実行端末を確認する |
| Web閲覧機能付きエージェント | URL要約、競合調査、Web巡回、社外サイトの内容取得を自動化している | 信頼できないページをレンダリングする前提で隔離する |
| コード実行・シェル実行ツール | Python、PowerShell、Bash、Node、MCP経由のツール呼び出しを許可している | 実行可能コマンドを許可リスト化する |
| ローカル制御プレーン | localhostのAPI、WebSocket、MCP、デバッグポート、開発DBがある | localhostだけを信頼境界にしない |
| 高権限の開発端末 | 管理者権限、Azure権限、GitHubトークン、クラウド資格情報を持つ端末で検証している | 低権限ユーザー、VM、コンテナー、Dev Boxへ分離する |
AutoGen Studio自体は、公式ドキュメントやPyPI説明でもプロトタイピング向けの位置づけが示されており、本番サービスとしてインターネット公開する前提のアプリではありません。インストール方法も、通常はPyPIからのインストールが推奨され、ソースからの導入は変更や開発を行う場合の方法として説明されています。(Microsoft GitHub)
設定場所と管理画面の確認ポイント
AutoJack対策で見るべき管理画面は1つではありません。開発端末の実装確認、Microsoft Defenderのエンドポイント保護、Defender for CloudのAI保護、Agent 365やMicrosoft Entraのエージェント管理を分けて確認します。
| 領域 | 管理画面・確認場所 | 確認する設定 | 対応の目安 |
|---|---|---|---|
| AutoGen Studio・開発端末 | 端末上のPython環境、Gitリポジトリ、CMDB、EDRのソフトウェア一覧 | PyPI版かソースビルドか、実行ポート、MCP利用、Web閲覧ツール、コード実行ツール | ソースビルドは修正済みコミット以降か確認。実行は低権限・隔離環境へ移す |
| Microsoft Defender for Endpoint | Microsoft Defenderポータル、Intune、グループポリシー | Network Protection、Web protection、Web content filtering、カスタムURL/IPインジケーター | まず監査モードで影響確認し、問題がなければブロックへ移行する |
| Microsoft Defender XDR | Microsoft DefenderポータルのHunting | AutoGen Studio関連プロセスからの不審な子プロセス、ローカルポート通信、外部URLアクセス | KQLを保存し、検出ルールや定期ハンティングにする |
| Microsoft Defender for Cloud | Azure portal > Microsoft Defender for Cloud > Environment settings | AI servicesプラン、Suspicious prompt evidence、AI model security、Data and AI security dashboard | Azure AIを使うサブスクリプション単位で有効化・可視化を確認する |
| Security for AI / Agent 365 | Microsoft Defenderポータル > System > Settings > Security for AI、Microsoft 365管理センター > Agents | AI agent inventory、Security for AI Agents、リアルタイム保護、Agent 365ライセンス | 2026年7月1日のライセンス・機能移行前に設定と運用を見直す |
| Microsoft Entra Agent ID | Microsoft Entra管理センター > Entra ID > Agents > Agent identities / Agent blueprints | エージェントID、所有者、スポンサー、権限、サインインログ、条件付きアクセス | 人間ユーザーと同じ発想で、最小権限・責任者・ログ監査を徹底する |
Microsoft Defender for EndpointのWeb protectionは、Web threat protection、Web content filtering、Custom indicatorsで構成され、Microsoft DefenderポータルのReports > Web protectionでレポートを確認できます。Web content filteringの管理は、Microsoft DefenderポータルのSettings > Endpoints > Rules > Web content filteringで行います。(Microsoft Learn)
Network Protectionは、Intuneのエンドポイントセキュリティポリシー、セキュリティベースライン、デバイス構成プロファイル、グループポリシーなどから構成できます。監査モードで影響を見てからブロックモードに移す運用が安全です。(Microsoft Learn)
AutoGen Studio側で確認する手順
AutoJackの個別影響を確認する場合は、まず「どの経路でAutoGen Studioを導入したか」を切り分けます。
PyPI版かソースビルドかを確認する
開発端末で次のように確認します。
python -m pip show autogenstudio
python -m pip freeze | findstr /i "autogen autogenstudio"ソースビルドや開発ブランチを使っている場合は、リポジトリのコミットも確認します。
git rev-parse HEAD
git branch --show-currentMicrosoftの説明では、影響を受けるMCP WebSocket面はPyPIで公開されたAutoGen Studioには含まれておらず、問題の露出はMCPプラグインが入った後から修正コミットまでのmainブランチをビルドした開発者に限定されるとされています。ただし、これは「PyPI版なら何も確認しなくてよい」という意味ではありません。Web閲覧エージェント、MCP、コード実行ツール、ローカル制御面を組み合わせる構造的リスクは、他のAIエージェントフレームワークにも当てはまります。(Microsoft)
ローカルポートと公開範囲を確認する
AutoGen Studioは、Web UIを指定ポートで起動し、ブラウザーからlocalhostでアクセスする使い方が説明されています。実務では、開発端末で次の点を確認してください。(PyPI)
netstat -ano | findstr ":8081"確認すべきポイントは次の通りです。
- 0.0.0.0で待ち受けていないか
- 社内ネットワークやインターネットから到達できないか
- 開発端末のファイアウォールで非ループバック通信を遮断しているか
- 逆プロキシを使う場合、WebSocketや/api配下を含む全パスで認証がかかっているか
- 管理者権限や日常利用アカウントで実行していないか
- ブラウジングエージェントとコード実行エージェントを同じOSユーザー・同じ端末で動かしていないか
特に危険なのは、「localhostでしか開いていないから安全」と判断することです。AutoJack研究の中心的な教訓は、AIエージェントが同じ端末上で外部コンテンツを閲覧できる場合、localhostが従来どおりの安全境界にならないことです。(Microsoft)
Microsoft Defenderで確認する設定
AutoJack型のリスクは、侵入前のURLアクセス、プロンプト操作、ローカルプロセス生成、資格情報悪用、横展開の各段階で検知・封じ込めを考えます。
Network ProtectionとWeb content filtering
Microsoft Defender for Endpointを利用している場合は、まずNetwork ProtectionとWeb protectionの適用状況を確認します。AIエージェントのヘッドレスブラウザーやPython/Nodeプロセスが外部サイトへアクセスする場合、Microsoft Edgeだけでなく、非Microsoftブラウザーや他プロセスの通信も考慮する必要があります。MicrosoftのWeb protectionドキュメントでは、Microsoft Edge以外のプロセスではNetwork Protectionが検査と enforcement に使われると説明されています。(Microsoft Learn)
確認の流れは次の通りです。
| 手順 | 操作 | 判断基準 |
|---|---|---|
| 現状確認 | Microsoft DefenderポータルでWeb protectionレポートを見る | ブロック、警告、許可の傾向を確認する |
| 機能確認 | Settings > Endpoints > Advanced featuresでWeb content filteringがOnか確認 | Offなら対象デバイスと運用影響を確認して有効化を検討 |
| ポリシー確認 | Settings > Endpoints > Rules > Web content filteringで対象デバイスグループを確認 | 開発端末やAI検証端末が対象外になっていないか見る |
| 段階適用 | IntuneでNetwork ProtectionをAuditまたはBlockに設定 | いきなり全社ブロックせず、開発端末グループから段階展開 |
| 例外管理 | Custom indicatorsで許可・警告・ブロックを管理 | 業務上必要なURLだけを明示的に許可し、例外を棚卸しする |
Web content filteringはカテゴリ制御に便利ですが、AutoJack型の攻撃では「正規サイトのコメント欄」「社外ドキュメント」「攻撃者が用意したURL」など、カテゴリだけでは判断しにくいケースがあります。そのため、Network Protection、Custom indicators、EDRのプロセス監視、ユーザー教育を組み合わせる必要があります。
Advanced Huntingで不審な子プロセスを探す
Microsoft Defender XDRの高度なハンティングは、最大30日間の生データを探索して脅威の兆候を探すためのクエリベースの機能です。KQLに慣れていない場合でも、まずはAutoGen StudioやAIエージェント関連プロセスから起動された不審な子プロセスを見るところから始めると実務に落とし込みやすくなります。(Microsoft Learn)
以下は、AutoJack型の調査用に調整して使える例です。
DeviceProcessEvents
| where Timestamp > ago(30d)
| where InitiatingProcessCommandLine has_any ("autogenstudio", "autogen", "mcp", "playwright")
or InitiatingProcessFolderPath has_any ("autogenstudio", "autogen")
| where FileName in~ (
"cmd.exe", "powershell.exe", "pwsh.exe", "bash.exe", "wsl.exe",
"curl.exe", "wget.exe", "certutil.exe", "mshta.exe",
"rundll32.exe", "regsvr32.exe"
)
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp descローカル制御プレーンやMCP関連の通信を探す場合は、環境で取得できるテレメトリに合わせて次のような観点を追加します。
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemotePort in (8081, 8080)
| where RemoteUrl has_any ("/api/mcp", "server_params", "ws")
| project Timestamp, DeviceName, InitiatingProcessFileName,
InitiatingProcessCommandLine, RemoteIP, RemotePort, RemoteUrl
| sort by Timestamp descローカルWebSocketやlocalhost通信は、ネットワークセンサーやOSの記録方法によって見え方が変わります。クエリで何も出ない場合でも、影響なしと即断しないでください。プロセス生成、ファイル作成、資格情報アクセス、EDRアラート、開発端末のローカルログを併せて確認します。
Defender for CloudとAI servicesの確認
Azure OpenAIやAzure AI Model InferenceなどのAIサービスを利用している場合は、Microsoft Defender for CloudのAI services保護も確認します。Defender for CloudのAI threat protectionは、生成AIアプリケーションやエージェントに対する脅威を検出し、Defender XDRポータルでアラートやインシデントを集約できると説明されています。対応範囲はサービス、モデル、クラウド、トークン種別によって制約があるため、利用条件を必ず確認してください。(Microsoft Learn)
AI servicesプランの有効化場所
Azure portalで次の順に確認します。
| 確認項目 | 管理画面 | 見るべきポイント |
|---|---|---|
| AI services保護 | Microsoft Defender for Cloud > Environment settings > 対象サブスクリプション > Defender plans | AI servicesがOnか |
| Suspicious prompt evidence | AI services > Settings | アラート証跡にプロンプトや応答の疑わしい部分を含めるか |
| Data security for AI interactions | AI services > Settings | Purview連携が必要なデータセキュリティ要件があるか |
| AI model security | AI services > Settings | Azure Machine Learningのモデルスキャンやリスク確認が必要か |
| Data and AI dashboard | Defender for CloudのData and AI security dashboard | AIリソース、保護状況、重大な推奨事項、アラートを俯瞰する |
Defender for AI Servicesでは、AI servicesプランを有効にしたうえで、Suspicious prompt evidence、Data security for AI interactions、AI model securityなどのコンポーネントを個別に制御できます。Prompt evidenceはプロンプトとモデル応答を証跡として扱うため、プライバシー、データ分類、監査ルールと合わせて判断してください。(Microsoft Learn)
Data and AI security dashboardは、データとAIリソースのリスク、保護状況、重大な推奨事項、攻撃パスをまとめて確認する画面です。フル活用するには、Defender CSPM、関連するDefenderプラン、Microsoft.Securityリソースプロバイダー登録、必要な読み取り権限などの前提を確認します。(Microsoft Learn)
Prompt Shieldsでできることとできないこと
Azure AI Content SafetyのPrompt Shieldsは、ユーザープロンプト攻撃やドキュメント経由の間接プロンプトインジェクションを検出・ブロックするためのAPIです。外部ドキュメントやWebコンテンツに隠れた指示を扱うAIエージェントでは、早い段階の防御として有効です。(Microsoft Learn)
ただし、Prompt ShieldsだけでAutoJack型のリスクを完全に防げるとは考えないでください。Microsoft Security Blogでも、Prompt Shieldsは初期段階の誘導を捉える助けになる一方、クライアント側JavaScriptの実行そのものを止めるものではないと説明されています。したがって、Prompt Shieldsは「入力の検査」、Defender for Endpointは「端末上の挙動検知」、ネットワーク制御は「外部接続の抑制」、MCPやツール設計は「危険な操作の許可リスト化」と役割を分けて考える必要があります。(Microsoft)
Agent 365とSecurity for AIで確認すること
AIエージェントの可視化や保護は、2026年7月1日を境にライセンスと管理体験の確認が特に重要になります。Microsoft Learnでは、2026年7月1日以降、Microsoft Copilot StudioとMicrosoft Foundry agentsのAI agent security capabilitiesにはMicrosoft Agent 365ライセンスが必要になり、対象ライセンスがないテナントでは該当機能にアクセスできなくなると説明されています。(Microsoft Learn)
Security for AI Agentsの確認場所
Microsoft Defenderポータルでは、System > Settings > Security for AIでSecurity for AI Agentsの設定を確認します。Copilot StudioのAI agent inventoryを有効化する場合は、Microsoft Defender側の設定に加え、Power Platform管理者と連携してPower Platform側のSecurity > Threat ProtectionでMicrosoft Defender – Copilot Studio AI Agentsを有効化する手順が示されています。(Microsoft Learn)
2026年7月1日の移行で特に注意すべき点は次の通りです。
| 確認項目 | なぜ重要か | 実務対応 |
|---|---|---|
| Agent 365対象ライセンス | 未対応テナントでは一部のエージェントセキュリティ機能にアクセスできなくなる | ライセンス、試用、購入計画を確認する |
| Security for AI Agentsトグル | Offの場合、Security for AI関連機能が無効になる | Defenderポータルで設定状態を確認する |
| 既存のブロックルール | 既存ルールが移行後にブロックしなくなるケースがある | Settings > Security for AI > Policiesで再定義する計画を作る |
| Advanced Huntingテーブル | AI agent inventoryのテーブル移行がある | 保存済みKQL、カスタム検出、ブックを棚卸しする |
| Foundry agentの可視性 | Azure portal側の一部表示が変わる | DefenderポータルとAgent 365側で確認経路を整理する |
| 関係者周知 | SOC、IT、Power Platform、開発部門で見ている画面が違う | 変更日と影響範囲を明文化して通知する |
Agent 365の統合レジストリは、Microsoft 365管理センターのAgents > All agentsからエージェント一覧を確認する導線が示されています。一方、Microsoft Entra管理センターはエージェントID、アクセス制御、条件付きアクセス、IDガバナンスなどの管理を担います。全体棚卸しはAgent 365、IDと権限の制御はMicrosoft Entra、と役割を分けると混乱しにくくなります。(Microsoft Learn)
Microsoft Entra Agent IDで見るべき権限と責任者
AutoJack型のリスクは、最終的に「エージェントが誰の権限で何をできるか」に直結します。Microsoft Entra Agent IDは、AIエージェントに対して認証、認可、ガバナンス、保護を適用するための仕組みです。Microsoft Entra Agent IDはAIエージェント向けのIDとセキュリティフレームワークとして説明され、OAuth 2.0、MCP、A2Aなどのプロトコルも対象に含まれます。(Microsoft Learn)
Microsoft Entra管理センターでは、Entra ID > Agents > Agent identitiesからエージェントIDを確認できます。詳細画面では、名前、状態、所有者、スポンサー、付与権限、サインインログなどを確認できます。Agent blueprintsでは、親となるブループリント、権限、監査ログ、サインインログも確認できます。(Microsoft Learn)
確認の観点は次の通りです。
| 観点 | 確認内容 | 危険な状態 |
|---|---|---|
| 所有者 | 技術的な管理者が明確か | 退職者、個人任せ、部署不明 |
| スポンサー | 業務責任者が明確か | 目的不明のエージェントが残っている |
| 権限 | Graph、SharePoint、Dataverse、社内APIへの権限 | 読み取りだけで十分なのに書き込みや管理権限がある |
| 条件付きアクセス | エージェントIDやエージェントユーザーにポリシーがあるか | 高リスクでもアクセスできる |
| サインインログ | どのリソースへ、いつ、どの頻度でアクセスしているか | 突然のアクセス増加、未知のリソースアクセス |
| 無効化手順 | 事故時に誰が止められるか | SOCが止め方を知らない |
エージェントIDを全社で一律無効化すると業務影響が出る可能性があります。いきなり全停止するのではなく、リスクの高いエージェント、スポンサー不明のエージェント、外部コンテンツを扱うエージェント、広い権限を持つエージェントから優先して制御しましょう。
管理者向けの実務チェックリスト
AutoJack研究を受けて、管理者は次の順序で確認すると実装に落とし込みやすくなります。
| 優先度 | チェック項目 | 完了の判断 |
|---|---|---|
| 高 | AutoGen Studio、AutoGen、MCP、Playwright、Web閲覧エージェントの利用部署を洗い出す | 対象端末、所有者、用途、実行アカウントが一覧化されている |
| 高 | AutoGen StudioがPyPI版かソースビルドか確認する | ソースビルドの場合、修正済みコミット以降か説明できる |
| 高 | localhostの制御プレーン、デバッグポート、MCP、コード実行ツールを確認する | 認証、許可リスト、ファイアウォール、低権限実行が設定されている |
| 高 | Microsoft Defender for EndpointのNetwork Protectionを確認する | AuditまたはBlockで対象端末に適用されている |
| 中 | Web content filteringとCustom indicatorsを確認する | AI検証端末がポリシー対象に含まれている |
| 中 | Defender XDRでハンティングクエリを保存する | 不審な子プロセスや外部URLアクセスを定期確認できる |
| 中 | Defender for CloudのAI servicesプランを確認する | 対象サブスクリプションで有効化状態を説明できる |
| 中 | Agent 365 / Security for AIの移行状況を確認する | 2026年7月1日以降のライセンス、ポリシー、ハンティング移行が整理されている |
| 中 | Entra Agent IDで所有者・スポンサー・権限を確認する | 責任者不明、過剰権限、放置エージェントが是正対象になっている |
| 低 | ユーザー周知と開発ガイドを更新する | 外部URL、MCP、コード実行、端末分離のルールが明文化されている |
ユーザー周知で伝えるべきポイント
AIエージェントのリスクは、管理者だけが理解していても防げません。特にURL要約、Web調査、ドキュメント要約、コード生成、社内API連携を使うユーザーには、次の内容を短く具体的に周知します。
開発者向けの周知例
外部Webページや社外ドキュメントをAIエージェントに読ませる場合、その内容に隠れた指示やスクリプトが含まれる可能性があります。Web閲覧エージェント、MCP、コード実行ツール、ローカルAPIを同じ端末で動かす検証は、低権限ユーザー、VM、コンテナー、Microsoft Dev Boxなどの隔離環境で実施してください。管理者権限の端末や日常利用アカウントでは実行しないでください。
一般ユーザー向けの周知例
不審なURL、差出人不明の資料、出所が分からないページをAIエージェントに要約させないでください。AIエージェントが外部ページを読むと、ページ内の見えない指示に影響される可能性があります。業務で必要な場合は、社内で承認されたツールと手順を使ってください。
SOC・ヘルプデスク向けの周知例
AIエージェント利用中に、PowerShell、cmd、Bash、curl、未知のブラウザー自動化プロセス、予期しないウィンドウ起動が発生した場合は、通常のマルウェア疑いと同じく端末隔離、認証情報の保護、トークンのローテーション、ログ保全を実施してください。AI関連の検証端末であっても、DefenderやNetwork Protectionを無効化した状態を標準にしないでください。
失敗しやすい判断と避け方
| 失敗しやすい判断 | なぜ危険か | 正しい対応 |
|---|---|---|
| localhostだから安全 | AIエージェントが同じ端末上で外部コンテンツを扱うと、localhost前提の防御が崩れる | ローカル制御プレーンにも認証・認可・分離を適用する |
| 認証設定を入れたから全パスが守られている | WebSocketや/api配下が認証ミドルウェアの対象外になる実装もあり得る | ルート単位、プロトコル単位で認証を確認する |
| PyPI版は今回のチェーン対象外だから対策不要 | 個別脆弱性と構造的リスクは別問題 | Web閲覧、MCP、コード実行、ローカルAPIの組み合わせを見直す |
| Prompt Shieldsだけで十分 | 入力段階の検出であり、端末上のJavaScript実行やプロセス生成を直接止めるものではない | Defender、ネットワーク制御、サンドボックス、ツール許可リストを併用する |
| EDRのソフトウェア一覧だけで把握できる | pipパッケージやソースビルドは標準インベントリに出ない場合がある | ファイル、プロセス、Git、開発者申告、CMDBを組み合わせる |
| AIエージェントの所有者を決めていない | 事故時に停止、権限削除、説明責任の所在が不明になる | Entra Agent IDやAgent 365で所有者・スポンサーを管理する |
まとめ：AutoJack対応は「設定確認」より「AIエージェントの境界確認」が重要
Microsoft SecurityのAutoJack AI agent RCE研究を受けた実務対応では、まず自社にAutoGen Studio、AutoGen、MCP、Web閲覧エージェント、コード実行ツールがあるかを確認します。PyPI版AutoGen Studioが今回の具体的な攻撃チェーンに含まれていないとしても、外部コンテンツを読むAIエージェントがローカル制御プレーンに触れる構成は、今後も同種のリスクを生みます。
管理者が次に取るべき行動は明確です。開発端末を棚卸しし、AutoGen Studioの導入経路と実行権限を確認し、Microsoft Defender for EndpointのNetwork ProtectionとWeb protectionを有効化・監査し、Defender XDRでハンティングを始めます。Azure AIを使っている場合はDefender for CloudのAI services保護を確認し、Copilot StudioやFoundry agentsを管理している組織はAgent 365、Security for AI、Microsoft Entra Agent IDのライセンス・設定・責任者を2026年7月1日の移行前に整理してください。
AutoJackから得るべき最大の教訓は、AIエージェント時代には「localhost」「開発端末」「プロトタイプ」「社内だけ」という言葉だけでは安全を説明できないことです。AIエージェントが見に行く外部コンテンツ、呼び出せるツール、到達できるローカルサービス、使えるID権限を1つずつ棚卸しし、認証、最小権限、隔離、検知、ユーザー周知で多層的に守ることが、現実的で効果の高い設定確認になります。
コメント