Microsoft Security hub（Security hub – Security）は、Microsoftのセキュリティ製品を横断して「何を確認し、どの順番で対策するか」を整理するための公式ハブです。2026年5月21日のMicrosoft Security公式情報で重要なのは、単一の管理画面が増えたことではなく、AIアプリ、AIエージェント、ID、データ、クラウド、SOC運用をZero Trust前提でつなげて管理する方向性がより明確になった点です。管理者はまず、Microsoft Entra、Microsoft Purview、Microsoft Defender、Microsoft Sentinel、Microsoft Security Copilot、Agent 365まわりの可視化・権限・監査・データ保護設定を棚卸しする必要があります。(Microsoft Learn)
Microsoft Security hubとは何か
Microsoft Security hubは、Microsoft Learn上で提供されているMicrosoft Security関連情報の入口です。Microsoft Defender、Microsoft Sentinel、Microsoft Defender for Cloud、Microsoft Security Copilot、Microsoft Entra、Microsoft Purviewなどのドキュメント、学習モジュール、認定資格、導入フレームワークへの導線がまとめられています。(Microsoft Learn)
注意したいのは、Microsoft Security hub自体が「設定を有効化する管理コンソール」ではない点です。AWS Security Hubのような単一サービス名と混同しやすいですが、今回の文脈ではMicrosoft Learnのセキュリティ情報ハブを指します。実際の設定変更は、Microsoft Entra管理センター、Microsoft Purview、Microsoft Defenderポータル、Microsoft Sentinel、Azure、Microsoft 365管理センターなどで行います。
Microsoft Security hubを読む目的は、次の3つに分けると実務に落とし込みやすくなります。
| 目的 | 見るべき観点 | 主な担当者 |
|---|---|---|
| 変更点の把握 | Microsoft Securityの最新発表、AIセキュリティ、Agent 365、Purview、Entraの更新 | 情報システム、セキュリティ管理者 |
| 設定・運用の見直し | 条件付きアクセス、RBAC、DLP、監査ログ、Sentinel連携、Defenderの検出 | Microsoft 365管理者、SOC担当 |
| 展開・移行の判断 | AIエージェント、Security Copilot、Foundry Agent Service、既存AIアプリの管理 | 開発者、Azure管理者、アーキテクト |
2026年5月21日の公式情報で押さえるべき変更点
2026年5月21日に公開された「What’s new in Microsoft Security: May 2026」では、Microsoft Securityの更新として、PurviewによるClaude利用の可視化、Purview DSPMの新しい体験、Data Security Investigationsの拡張、Microsoft Entra ID Account recovery、Windows 365 for AgentsとAgent 365の連携が紹介されています。(Aka.ms)
実務上は、次のように整理すると対応漏れを防げます。
| 領域 | 主な変更・注目点 | 影響範囲 | 最初に確認すべきこと |
|---|---|---|---|
| AIアプリの可視化 | Microsoft PurviewでClaude Enterpriseの利用状況や監査シグナルを扱う流れが示された | 生成AIを業務利用する部門、コンプライアンス部門 | 自社でClaude、ChatGPT、Geminiなどの外部AI利用を許可・黙認していないか |
| データ保護 | Microsoft Purview Data Security Posture Managementの新しい体験が一般提供として紹介された | Purview管理者、DLP担当、監査担当 | 機密ラベル、DLP、監査ログ、外部共有の運用ルール |
| データ調査 | Data Security InvestigationsでOCRやカスタム検査の拡張が紹介された | インシデント対応、内部不正調査、法務・監査 | 画像内テキストや添付ファイルまで調査対象に含める運用の要否 |
| ID復旧 | Microsoft Entra ID Account recoveryが、全認証手段を失った場合の復旧手段として提示された | Entra管理者、ヘルプデスク、リモートワーク利用者 | SSPRだけで対応できないロックアウト時の復旧フロー |
| AIエージェント実行環境 | Windows 365 for AgentsとMicrosoft Agent 365により、エージェントの実行環境と統制を分けて考える流れが示された | AIエージェント開発者、Microsoft 365管理者、セキュリティ担当 | エージェントのID、実行場所、操作権限、監査ログの管理方針 |
今回の更新は「すぐ全社設定を変えるべき緊急パッチ」というより、AI利用が広がる組織に対して、可視化、統制、監査、復旧、エージェント管理の設計を見直すべきタイミングを示すものです。
影響範囲はMicrosoft 365管理者だけにとどまらない
Microsoft Security hubの内容は、Microsoft 365管理者だけで完結しません。特にAIエージェントや外部AIアプリの利用が進んでいる組織では、ID管理、データ保護、クラウド、SOC、開発チームが同じ前提で動く必要があります。
| 担当領域 | 影響を受ける理由 | 確認すべき代表項目 |
|---|---|---|
| Microsoft 365管理者 | Copilot、Teams、SharePoint、OneDrive上のデータがAIに参照される可能性がある | 共有範囲、ゲストアクセス、監査ログ、ライセンス |
| Microsoft Entra管理者 | AIアプリやエージェントにもIDとアクセス制御が必要になる | 条件付きアクセス、PIM、RBAC、Account recovery |
| Microsoft Purview管理者 | AI利用時のデータ漏えい、過共有、内部不正リスクを扱う中心になる | DLP、秘密度ラベル、DSPM、Data Security Investigations |
| Defender・Sentinel担当 | AIアプリ、AIエージェント、クラウドワークロードを検出・調査対象に含める必要がある | XDR、SIEM、アラート相関、インシデント対応手順 |
| 開発者・Azure担当 | MCPツール、Foundry Agent Service、Security Copilot agentsなどの展開にセキュリティ設計が必要 | RBAC、ネットワーク、ツール許可リスト、ログ、テスト |
| 法務・監査・リスク管理 | 生成AIの利用ログ、個人情報、機密情報、越境データ、第三者サービス利用が関係する | 利用規程、保持期間、調査権限、同意・通知 |
特に見落としやすいのは、AIアプリの利用可否を「利用規程」だけで管理しようとするケースです。規程は必要ですが、実際にはID、端末、クラウドアプリ検出、データ保護、監査ログがそろっていなければ、違反利用や過共有を継続的に把握できません。
管理者が最優先で確認すべき設定
Microsoft Entra：条件付きアクセスとAccount recoveryを見直す
Microsoft Security hubでは、条件付きアクセスが「どのユーザーが、どのリソースに、どの条件でアクセスできるか」を細かく制御する学習項目として示されています。AI利用が増えると、アクセス制御の対象は人間のユーザーだけでなく、アプリ、サービスプリンシパル、エージェントIDにも広がります。(Microsoft Learn)
まず確認すべき項目は次の通りです。
| 確認項目 | 推奨される状態 | よくある失敗 |
|---|---|---|
| 管理者権限 | Global Administratorの常用を避け、職務別ロールとPIMを使う | 日常作業を全てグローバル管理者で行う |
| 条件付きアクセス | 管理者、外部アクセス、リスク高ユーザー、AIアプリ利用を条件で分ける | 全社一律ポリシーで例外だらけになる |
| 多要素認証 | 特権ユーザーや高リスク操作では強い認証を要求する | SMSだけに依存する |
| 復旧フロー | SSPRで足りない完全ロックアウト時の対応を決める | ヘルプデスクが本人確認を口頭で行う |
| エージェントID | 人間ユーザーとは別に棚卸しし、権限範囲を限定する | 共有アカウントや広すぎるアプリ権限を与える |
Microsoft Entra ID Account recoveryは、ユーザーが登録済みの認証方法をすべて失った場合に、第三者の本人確認プロバイダーやMicrosoft Entra Verified IDを使って信頼を再確立する仕組みです。SSPRが「パスワードを忘れたが認証手段は残っている」状況に向くのに対し、Account recoveryは「スマートフォン、セキュリティキー、Authenticatorなどを失い、通常の自己復旧ができない」状況に向きます。(Microsoft Learn)
導入時は、最初から全社の本番運用にするのではなく、評価モードで少人数のグループから検証するのが安全です。政府発行IDや生体情報を扱う可能性があるため、プライバシー、データ保持、地域ごとのコンプライアンス要件も事前に確認してください。(Microsoft Learn)
Microsoft Purview：AI利用時のデータ漏えいと過共有を確認する
Microsoft Purviewは、Microsoft 365やAI利用時のデータ保護に関わる中心的なサービスです。Microsoft Security hubでも、Microsoft PurviewはMicrosoft 365とAIデータを保護するソリューションとして位置づけられています。(Microsoft Learn)
2026年5月21日の発表では、Microsoft Purviewの可視化対象がClaude Enterpriseにも広がること、Purview DSPMの新しい体験が一般提供になったこと、Data Security InvestigationsでOCRやカスタム検査が使えるようになることが紹介されています。これにより、AIアプリ上の会話、アップロードファイル、監査シグナル、画像内テキストなどを、より実務的な調査対象として扱う流れが強まっています。(Aka.ms)
管理者は、次の順番で確認すると効率的です。
| 手順 | 確認内容 | 判断基準 |
|---|---|---|
| 1 | 組織で利用されている生成AIアプリを洗い出す | 承認済み、未承認、部門限定、検証中に分類する |
| 2 | 機密データがAIアプリに投入される可能性を確認する | 顧客情報、契約書、設計資料、ソースコード、人事情報を優先 |
| 3 | 秘密度ラベルとDLPポリシーを見直す | ラベルなし重要ファイル、外部共有ファイルを重点確認 |
| 4 | DSPMでリスクを可視化する | 過共有、外部公開、機密データの移動を確認 |
| 5 | Data Security Investigationsの運用を決める | 誰が調査を開始し、誰が結果をレビューするかを明確にする |
Data Security Investigationsは、生成AIを使ってデータセキュリティインシデント、リスクのある内部関係者、データ侵害への調査と対応を支援する機能です。ベクター検索、分類、検査により、キーワードだけでは見つけにくい関連データや、資格情報・個人情報・ネットワークリスクなどを調査できます。(Aka.ms)
ただし、Data Security Investigationsは利用量に応じた課金や容量課金に関係する場合があります。特にDSPMからのプロアクティブなAI分析を有効にする場合は、継続的にコストが発生する可能性があるため、本番展開前に検証テナントや限定範囲で確認するのが現実的です。(Aka.ms)
Microsoft DefenderとMicrosoft Sentinel：AI時代のSOC運用に合わせる
Microsoft Security hubでは、Microsoft DefenderとMicrosoft Sentinelを使ったインシデント調査、アラート相関、脅威ハンティング、統合セキュリティ運用の学習導線が用意されています。(Microsoft Learn)
確認すべきポイントは、従来の端末・ID・メール・クラウドだけでなく、AIアプリやAIエージェントを検出・調査対象に入れられているかです。
具体的には、次の観点を見直してください。
| 観点 | 確認すること |
|---|---|
| アラート相関 | Defender XDR、Microsoft Sentinel、Purviewの調査結果が分断されていないか |
| ログ収集 | AIアプリ、MCPサーバー、クラウドワークロード、ID操作のログを追えるか |
| インシデント対応 | AIによるデータ漏えい、プロンプトインジェクション、過剰な権限行使を想定しているか |
| 優先度付け | 重要データ、特権ID、本番環境に関係するアラートを高優先度にしているか |
| 運用連携 | SOC、データ保護担当、ID管理者、開発者のエスカレーション先が決まっているか |
AIアプリのリスクは、通常のマルウェア検知だけでは見えにくいことがあります。たとえば、ユーザーが機密資料を承認済みでないAIサービスにアップロードした場合、端末は正常でもデータ保護上は重大な問題です。Defender、Purview、Sentinelを別々に見るのではなく、同じインシデントの文脈で扱う運用が重要になります。
Security Dashboard for AI：AI資産の可視化を始める
Microsoft Security Dashboard for AIは、組織内にどのAI資産が存在するか、現在のセキュリティ態勢はどうか、どこに対処すべきかを把握するための統合ダッシュボードです。Microsoft Entra、Microsoft Purview、Microsoft Defenderなどのシグナルを集約し、AIリスク、AI資産、推奨事項、経営層向けのレポートに活用できます。(Microsoft Learn)
このダッシュボードで特に重要なのは、AIエージェント、AIモデル、MCPサーバー、その他のAIアプリを「資産」として扱う点です。Microsoft 365 CopilotやCopilot Studio agents、Microsoft Foundryのアプリやエージェントだけでなく、Google Gemini、OpenAI ChatGPT、MCPサーバーなどの第三者AI資産も対象として扱われます。(Microsoft Learn)
権限面では、Security ReaderがすべてのSecurity Dashboard for AIデータの表示と推奨事項の割り当てに必要な最小のMicrosoft Entraロールとして示されています。CISOやセキュリティリーダーに可視性を与えたい一方で、テナント全体の設定変更権限までは渡したくない場合に有効です。(Microsoft Learn)
運用では、次の流れで使うと定着しやすくなります。
| フェーズ | やること |
|---|---|
| 初回確認 | AI InventoryでAIエージェント、AIモデル、MCPサーバー、AIアプリを確認する |
| 優先度付け | AI RiskでID、データ、クラウド、攻撃パスに関係するリスクを確認する |
| 対応割り当て | 推奨事項を担当者やグループに割り当て、期限を設定する |
| 改善確認 | 完了・未完了・スキップした推奨事項を定期レビューする |
| 経営報告 | リスク傾向、対応状況、残課題を月次でまとめる |
AIエージェント関連で開発者が確認すべきこと
エージェントは「ユーザーの代わりに動くアプリ」として設計する
Microsoft Learnの「Secure autonomous agentic AI systems」では、AIエージェントが計画、ツール呼び出し、データアクセス、アクション実行を限られた人間の介入で行えるため、自律性が高まるほど誤動作、悪用、侵害時の影響が大きくなると説明されています。(Microsoft Learn)
そのため、開発者はAIエージェントを単なるチャットUIとしてではなく、権限を持って業務システムを操作する実行主体として扱う必要があります。
実装前のチェック基準は次の通りです。
| 設計項目 | OK基準 | NG例 |
|---|---|---|
| ID | エージェントごとに識別可能なIDを持ち、所有者が明確 | 複数エージェントで同じサービスアカウントを共有 |
| 権限 | 必要なAPI、データ、操作だけに限定 | 管理者権限や広範なGraph権限を付与 |
| ツール呼び出し | 許可リスト、入力検証、実行ログがある | モデルの判断だけで任意ツールを実行 |
| 高リスク操作 | 削除、送信、課金、外部共有は人間承認を必須にする | エージェントが自動で外部送信する |
| ログ | プラン、ツール呼び出し、判断、結果を追跡できる | 成功・失敗だけしか記録しない |
| モデル変更 | モデルやプロンプト更新時に再評価する | モデル更新を本番に即反映 |
| データ | 機密ラベル、DLP、保持ポリシーに従う | 入力データを無制限に保存・再利用 |
Microsoftのガイダンスでは、モデル層、安全システム層、アプリケーション層、ポジショニング層に分けた防御が推奨されています。特に、モデル選定、プロンプトインジェクション対策、ログと観測性、ツール許可リスト、人間参加型の承認、最小権限、ユーザーへの能力開示が重要です。(Microsoft Learn)
Microsoft Foundry Agent Service利用者はRBACと移行期限を確認する
Microsoft Foundry Agent Serviceのセキュリティコントロールに関するLearnモジュールでは、Foundryリソースとプロジェクトのセキュリティ境界、ID、RBAC、ネットワーク、データソース、コンテンツ安全性、監視コントロールが学習対象になっています。また、Agents（classic）は2027年3月31日に廃止予定とされています。(Microsoft Learn)
Foundry Agent Serviceを使っている開発・Azureチームは、次の点を確認してください。
| 確認項目 | 対応ポイント |
|---|---|
| Agents（classic）の利用有無 | 利用中なら、2027年3月31日までの移行計画を作る |
| RBAC | Foundryリソース、プロジェクト、データソースごとに権限を分離する |
| ネットワーク | パブリックアクセス、閉域接続、許可IP、プライベート接続の要否を確認する |
| データソース | エージェントが参照できるデータ範囲を業務単位で制限する |
| コンテンツ安全性 | 入出力フィルター、プロンプトインジェクション対策、危険な応答の制御を入れる |
| 監視 | 実行ログ、API呼び出し、失敗、異常な利用パターンを監視する |
移行で失敗しやすいのは、機能差分だけを見てセキュリティ境界を後回しにすることです。AIエージェントはデータ、API、ユーザー操作をまたいで動くため、移行計画にはアーキテクチャ、権限、ログ、データ保護、テストケースを必ず含めてください。
Security Copilot agentsとMCPツールは検証前提で扱う
Security CopilotのMCP Quickstartでは、VS Code上でMCPツールを使い、Security Copilot agentsを作成、デプロイ、テストする流れが示されています。ただし、記事内では一部情報がプレリリース製品に関するもので、商用リリース前に大きく変更される可能性がある旨も明記されています。(Microsoft Learn)
開発者は、Quickstartの内容をそのまま本番テンプレートにするのではなく、次の観点でレビューしてください。
| レビュー項目 | 確認内容 |
|---|---|
| YAML定義 | エージェントの説明、利用ツール、権限、出力内容が明確か |
| MCPツール | どのデータソースやAPIにアクセスするか、管理者が把握しているか |
| スコープ | UserスコープとWorkspaceスコープの違いを理解しているか |
| テスト | 正常系だけでなく、権限不足、危険な入力、外部送信、データ漏えいを試験したか |
| ロールバック | 不具合時に無効化、権限削除、ログ確認ができるか |
特に、インシデントレポートを自動生成するようなエージェントでは、Defender、Purview、Sentinelのインシデント情報やエンティティ情報を扱う可能性があります。出力先、共有範囲、保持期間を決めずに展開すると、調査情報そのものが漏えいリスクになります。
Microsoft Agent 365とWindows 365 for Agentsの見方
Microsoft Agent 365は、組織内のAIエージェントを観測、保護、統制するためのコントロールプレーンとして説明されています。レジストリ、エージェントマップ、分析、ライフサイクル管理、監査、アクセス制御、データセキュリティ、脅威保護などが主な要素です。(Microsoft)
2026年5月21日のMicrosoft Security発表では、Windows 365 for Agentsがパブリックプレビューを拡大し、Agent 365と連携してエージェントの作業範囲と実行環境を分けて管理する方向性が示されました。Agent 365が「エージェントに何を許可するか」を管理し、Windows 365 for Agentsが「どこで実行するか」を担う、という整理です。(Aka.ms)
管理者は、次のように役割分担を決めておくと混乱しにくくなります。
| 領域 | 主な論点 | 担当候補 |
|---|---|---|
| エージェント台帳 | どのエージェントが、誰の所有で、何に使われているか | Microsoft 365管理者 |
| IDとアクセス | エージェントID、条件付きアクセス、最小権限 | Entra管理者 |
| データ保護 | エージェントが使うデータ、作成するデータ、DLP | Purview管理者 |
| 脅威検出 | エージェントへの攻撃、脆弱性、異常動作 | Defender担当 |
| 実行環境 | Cloud PC、アプリ、ネットワーク、監査可能性 | Windows 365・Intune管理者 |
| 業務利用 | どの部門が、どの業務に使うか | 業務部門責任者 |
AIエージェントは、作ることよりも「増えた後に管理できること」が重要です。所有者不明のエージェント、使われていないエージェント、広すぎる権限を持つエージェント、監査ログのないエージェントは、後から棚卸しするほど対応コストが増えます。
展開時に失敗しやすいポイント
Security hubを読んだだけで設定済みだと誤解する
Microsoft Security hubは情報の入口であり、設定状態を保証するものではありません。記事や学習モジュールを確認しただけでは、条件付きアクセス、DLP、Defender連携、Sentinel収集、Agent 365登録は有効になりません。
読み終えたら、必ず自社テナントで次の状態を確認してください。
| 確認場所 | 確認すること |
|---|---|
| Microsoft Entra | 管理者ロール、条件付きアクセス、PIM、認証方法、Account recovery |
| Microsoft Purview | ラベル、DLP、DSPM、監査、Data Security Investigations |
| Microsoft Defender | デバイス、クラウドアプリ、AI資産、アラート、脅威保護 |
| Microsoft Sentinel | データコネクタ、分析ルール、インシデント、SOAR |
| Microsoft 365管理センター | ライセンス、Agent 365、アプリ許可、管理者権限 |
| Azure | Foundry、AIリソース、ネットワーク、RBAC、診断設定 |
AIアプリの許可判断を部門任せにする
生成AIアプリは、現場部門が先に使い始めることが多い領域です。便利だから許可する、情報漏えいが怖いから全面禁止する、という二択では運用が破綻しやすくなります。
現実的には、次のように分類するのが実務向きです。
| 分類 | 例 | 管理方針 |
|---|---|---|
| 承認済みAI | 契約・監査・DLP・利用範囲が確認済みのAI | 全社または特定部門で利用可 |
| 条件付きAI | 検証中、特定用途のみ許可、機密データ投入禁止 | 利用者・用途・データ種別を限定 |
| 未承認AI | 契約、ログ、データ処理条件が未確認 | ブロックまたは申請制 |
| 禁止AI | 規制・契約・データ保護上の問題があるAI | 技術的制御と規程で禁止 |
Microsoft PurviewやDefender for Cloud Appsを使っても、許可基準が曖昧だと運用判断が属人化します。セキュリティ部門だけでなく、法務、購買、情報システム、業務部門を含めて基準を決めることが重要です。
エージェントに強すぎる権限を与える
AIエージェントの権限は「人間の管理者が操作するより危険になる」場合があります。理由は、エージェントが高速に、繰り返し、複数システムにまたがって操作できるからです。
たとえば、問い合わせ対応エージェントに顧客DBの全件読み取り権限、メール送信権限、ファイル共有権限をまとめて与えると、プロンプトインジェクションや誤動作が発生した際の影響範囲が一気に広がります。安全な設計では、読み取り範囲を業務単位に絞り、外部送信には人間承認を挟み、すべての操作を監査ログに残します。
課金とログ保存を後回しにする
AI分析、データ調査、ログ収集、Sentinelへの取り込みは、設定次第でコストに影響します。特にData Security InvestigationsのようなAI分析機能や、Sentinelへの大量ログ取り込みは、検証時点で費用見積もりを確認しておくべきです。(Aka.ms)
本番前に、最低限次の3点を決めてください。
| 項目 | 決めること |
|---|---|
| ログ保持 | 何を、何日または何カ月保持するか |
| 課金監視 | どのサービスの利用量を誰が確認するか |
| 調査権限 | 誰がAI分析やデータ調査を実行できるか |
管理者・開発者向けの実務対応チェックリスト
次のチェックリストを使うと、Microsoft Security hubの内容を自社環境の確認作業に落とし込みやすくなります。
| 優先度 | チェック項目 | 完了条件 |
|---|---|---|
| 高 | AIアプリとAIエージェントの棚卸し | 承認済み、未承認、検証中、禁止の分類がある |
| 高 | 特権IDと条件付きアクセスの見直し | 管理者の常用権限が最小化され、MFAとPIMが適用されている |
| 高 | Purviewのデータ保護設定 | ラベル、DLP、外部共有、監査ログが主要データに適用されている |
| 高 | Defender・Sentinelの連携 | AI関連リスクを含むアラートとインシデントの確認フローがある |
| 中 | Security Dashboard for AIの確認 | AI資産、AIリスク、推奨事項を定期的にレビューしている |
| 中 | Account recoveryの検証 | 評価モードで対象グループを絞って動作確認している |
| 中 | Foundry Agent ServiceのRBAC確認 | リソース、プロジェクト、データソースごとに権限が分離されている |
| 中 | Agents（classic）の利用確認 | 利用中なら2027年3月31日までの移行計画がある |
| 中 | Security Copilot agentsの展開基準 | YAML、MCPツール、スコープ、ログ、ロールバック手順をレビューしている |
| 低 | 認定・学習計画 | 管理者、SOC、開発者ごとのMicrosoft Learn学習パスを決めている |
まず次にやるべきこと
Microsoft Security hub – Securityの更新内容を実務に活かすなら、最初にやるべきことは「AI利用の可視化」と「権限の棚卸し」です。新機能を試す前に、どのAIアプリやエージェントが存在し、誰が使い、どのデータにアクセスし、どのログが残るのかを確認してください。
そのうえで、Microsoft Entraで条件付きアクセスと復旧フローを整え、Microsoft Purviewで機密データとAI利用のリスクを把握し、Microsoft DefenderとMicrosoft Sentinelで検出・調査・対応の流れを作ります。AIエージェントを開発・展開する場合は、Agent 365、Foundry Agent Service、Security Copilot agentsの権限、ツール、監査、移行計画を本番前にレビューすることが重要です。
Microsoft Security hubは、単なるリンク集ではなく、AI時代のセキュリティ運用をどの順番で整備するかを考えるための出発点です。まずは自社のAI利用状況、ID、データ、ログ、エージェントの5点を棚卸しし、30日以内に高リスクな過共有、特権ID、未承認AIアプリ、所有者不明エージェントの是正計画を作るところから始めてください。
コメント