2026年5月、MicrosoftはProject Perceptionをプレビュー公開した。Red(攻撃シミュレーション)・Blue(脅威検出およびトリアージ)・Green(脆弱性修正)の3つの専門化されたAIエージェントが1つのチームとして機能し、人間の介入なしにセキュリティワークフロー全体を自動化するエージェンティックセキュリティシステムである。「人間は戦略を立て、エージェントが実行を担う」というビジョンの下、Microsoftはセキュリティ運用のパラダイムを「AIが支援(assist)」から「AIが実行(act)」へと転換している。
Google、Palo Alto Networks、CrowdStrike、SentinelOneなど競合各社も同様のエージェンティックアプローチを競って導入中だ。既存のレガシーセキュリティベンダーはこの流れに適応するのか、それとも取り残されるのか。LLMがなぜ今セキュリティの中心になったのか、そしてその波及効果を分析する。
| # | 示唆 | 一行要約 |
|---|---|---|
| 1 | パラダイムシフト:支援から実行へ | AIが分析だけを行う時代は終わった。AIが直接行動する時代へ |
| 2 | マルチエージェントオーケストレーション | Red・Blue・Greenが協働するチーム構造は、階層的自動化の完成形である |
| 3 | レガシーベンダーの危機 | 既存のSIEM・SOARは、単一モデルの推論能力によって機能的に代替可能になる |
| 4 | 実行権限境界の再定義 | AIが行動する時代において、「承認境界」をコードで構築することが核心的課題である |
1. Project Perceptionとは何か
1.1 構造 — 3つのエージェント、1つのチームプレイ
Project Perceptionの中核は、Red・Blue・Greenの3色のエージェントが有機的に協働するマルチエージェントアーキテクチャである。
| エージェント | 役割 | 従来の対応方式との違い |
|---|---|---|
| Red Agent | 攻撃者のように環境を探索し脆弱性を発見 | 年1〜2回の外部レッドチーム点検 → 常時稼働の自動脆弱性発見 |
| Blue Agent | 脅威を検出しインシデントを分類・調査 | 人間アナリストがログ収集・相関分析 → AIがフルコンテキストで自動トリアージ |
| Green Agent | 特定された脆弱性を自動修正しシステムを強化 | パッチ管理者の手動対応 → 検出-修正が一つの連続ワークフローに |
エージェントは互いに情報を共有し、Redが発見した脆弱性はBlueの脅威インテリジェンスと結合され、Greenがこれを修正する一連のプロセスが人間のハンドオフなしで進行する。Microsoftはこれを「一つの発見が一つの修正につながる」と表現する。
3つのエージェントはループエンジニアリングを通じてセキュリティ脆弱性を改善し、防御戦略を構築する。
1.2 構成要素
Project Perceptionは単なるAIチャットボットではなく、次の6つのコンポーネントで構成される統合システムである。
| コンポーネント | 説明 |
|---|---|
| Agents | Red・Blue・Greenエージェント。攻撃ライフサイクル全体をカバー |
| Models | MAI-Cyber-1-Flashなどのサイバーセキュリティ特化型ファウンデーションモデル。汎用LLMではなくセキュリティ専用のマルチモデルアプローチ |
| Harness | エージェントのオーケストレーション・テスト・制御を担うフレームワーク |
| Context | 組織の過去のインシデント、ポリシー決定、ID関係、エンドポイント・クラウド・アプリのシグナルをリアルタイム統合したコンテキスト |
| Signals & Sensors | エンドポイント・ID・クラウド・アプリ全体のエンドツーエンドシグナル |
| Actuators | エージェントの決定を実際の行動に変換する実行メカニズム。単なる推奨ではなく実際の変更を実行 |
1.3 Security Copilotとの違い
MicrosoftはSecurity Copilot(生成AIベースのセキュリティアシスタント)とProject Perceptionの関係を明確に区別している。
Security Copilot = AI that assists(AIが支援) Project Perception = AI that acts(AIが行動)
Security Copilotはアナリストに情報を提供し、脅威を要約し、対応策を提案するヘルパーである。Project Perceptionはエージェントが直接環境をスキャンし、脆弱性の悪用を検証し、パッチを適用する主体である。両システムは共に動作するが、その役割の重心は根本的に異なる。
1.4 価格モデル
Project PerceptionはSecurity Compute Unit(SCU)ベースの消費型従量課金サブスクリプションモデルである。エージェントが重い作業を実行するほど多くのSCUを消費し、コストは実際の作業量に比例する。これはセキュリティ運用チームが予測可能なコスト構造でシステムを導入できる設計である。
AWS、Azure、GCPを含め、Agentic Securityが有料モデルとして導入されており、この流れは継続するだろう。
2. エージェンティックセキュリティシステムが登場する理由
2.1 攻撃におけるAI利用の増加
2026年7月、Hugging Faceに侵入した自律AIエージェントは、4.5日間で17,600件の攻撃行動を人間の介入なしに実行した。単一のワーカーPodでコード実行を確保してから13時間以内に、複数の内部クラスターでcluster-admin権限を取得した。エージェントは独自のC2プロトコルを設計し、チャンク+XOR+圧縮エンコーディングで通信を隠蔽し、100以上の使い捨てデッドドロップエンドポイントを運用した。
この事件が示したことは明確である。攻撃はすでに機械の速度で動作している。 人間のアナリストがログを読み、脅威を相関分析し、対応プレイブックを選択している間に、攻撃は数千回の試行をすでに完了している。防御側も同じ速度で動作しなければ、非対称性は不可逆的に広がる。
北朝鮮も不足しているサイバー攻撃能力をLLMで補強しており、古いGoベースのマルウェアをRust言語ベースに変更してワクチン検出回避を試みている。
2.2 人材不足とSOC疲労
グローバルなサイバーセキュリティ人材不足は400万人を超えた(ISC2 2025レポート基準)。特にSOC(Security Operations Center)アナリストの離職率は平均2年を下回る。無限に降り注ぐアラートの中で誤検知をフィルタリングし、実際の脅威を識別することは、人間にとってますます困難な課題になっている。
エージェンティックセキュリティシステムはこの2つの問題を同時に解決する。攻撃速度に対抗できる唯一の防御は同じ技術スタックで武装した防御エージェントであり、人材不足を補完する唯一の方法は1人の人間が多数のエージェントを監督する構造である。
2.3 コンテキストの爆発的増加
現代のエンタープライズ環境は、エンドポイント、クラウド、ID、SaaSアプリケーション、ネットワーク、OT/IoT機器などで構成される巨大なシグナル空間である。単一の脅威であっても数十の異種ログソースを横断して痕跡を残す。人間がこれらすべてのシグナルをリアルタイムで相関分析することは物理的に不可能である。
Project Perceptionのアプローチは「データ収集から始めるのではなく、コンテキストから始める」ことである。エージェントはすでに組織の全体コンテキスト(過去のインシデント、ID関係、ポリシー、リアルタイムシグナル)をロードした状態で作業を開始する。これは「証拠グレード推論(evidence-grade reasoning)」であり、単なるパターンマッチングではない。
3. クラウドとインフラを保護する新しいLLMアプローチ
3.1 なぜ既存のMLでは不十分なのか
過去10年間、セキュリティ業界はシグネチャベース検出 → 振る舞いベース分析 → 機械学習(ML)ベースの異常検出へと進化してきた。しかし、既存のMLアプローチには根本的な限界がある。
教師あり学習モデルは既知のパターンのみを検出する。 ゼロデイ脆弱性や新しい攻撃チェーンはトレーニングデータに存在しないため検出できない。
頻度ベースの異常検出にはコンテキストがない。 「普段より多いログイン試行」が正常な新サービス立ち上げなのか、攻撃なのかを区別できない。
推論の連鎖を説明できない。 MLモデルが「脅威確率87%」を出力しても、アナリストはその判断の根拠を知ることができない。
LLMは古い脆弱性を学習し、オープンソース上でこのコードを使用した変種をリサイクルし、脆弱性レベルは低いが複数の脆弱性が結合されるとゼロデイになる長いコンテキストをうまく活用している。
3.2 LLMが提供するもの
LLM(大規模言語モデル)は上記の限界に対する根本的な迂回路を提供する。
| 既存ML | LLMベースアプローチ |
|---|---|
| 既知パターンマッチング | 未知のパターンに対する推論(reasoning) |
| 単一シグナル判断 | 複数シグナルのコンテキスト統合 |
| ブラックボックス確率出力 | 自然言語による思考連鎖(chain-of-thought)の提供 |
| 静的モデル、再学習必要 | インコンテキストラーニングで新たな脅威にリアルタイム適応 |
Project Perceptionは特にMAI-Cyber-1-Flashというセキュリティ特化型ファウンデーションモデルを使用する。これは汎用LLMにセキュリティコンテキストを上乗せしたものではなく、セキュリティドメインに特化した専用モデルである。CVE分析、エクスプロイトチェーン再構築、攻撃グラフ生成、ログフォレンジックなどに最適化されたトークナイザーとプリトレーニングコーパスを備えている。
3.3 「AIが行動する」ことの技術的意味
Project PerceptionのActuatorは、エージェントの推論結果を実際のシステム変更に変換する構成要素である。これは推奨(例:「このパッチを適用してください」)ではなく、実行(パッチ適用、ファイアウォールルール変更、アカウント無効化)である。
Microsoftはこの地点でHuman-in-the-loop原則を強調する。すべての高影響作業には人間の承認が必要であり、すべての決定は監査可能で再現可能である。ただし、この原則が実際の運用速度でどのように維持されるかは、まだ証明されていない課題である。
4. 競合プラットフォーム — エージェンティックセキュリティの全景
Project Perceptionが単独で登場したわけではない。主要なセキュリティ・クラウドベンダーが一斉に類似の戦略を展開しており、この技術が一時的な流行ではなく産業の構造的転換であることを示している。
4.1 競合プラットフォーム比較
| ベンダー | 製品/イニシアチブ | アプローチ | 差別化ポイント |
|---|---|---|---|
| Project Naptime → Big Sleep | LLMがバイナリ・ソースコードを分析しゼロデイ脆弱性を自動発見 | 脆弱性研究(VR)に集中。すでに実際のCVEを多数発見。SecureFlag、SQLite3など実脆弱性を発見 | |
| Palo Alto Networks | XSIAM + AIOps | 5,000以上のMLモデルを統合したSOC自動化。エージェンティックセキュリティオペレーター導入を発表 | SIEM・SOAR・XDRを単一AIプラットフォームに統合。膨大なインストールベースのデータ優位性 |
| CrowdStrike | Charlotte AI | 自然言語ベースの脅威ハンティング・インシデント分析・対応自動化アシスタント。2026年にエージェンティック機能拡張 | エンドポイントテレメトリ1位のデータ規模。Falconプラットフォームとの密接な統合 |
| SentinelOne | Purple AI | 自然言語ベースのセキュリティ分析。SingularityプラットフォームでAIエージェントが脅威調査と対応ガイドを提供 | オープンアーキテクチャ。自社エージェント以外にサードパーティLLM連携をサポート |
| Cisco | AI Defense + Hypershield | ネットワーク・アプリケーションレイヤーでAIベースの自律防御。分散型AIエンジンがAIアプリケーション自体を保護 | ネットワークレイヤーアプローチ。AI-to-AI攻撃防御に焦点 |
| OpenAI | (非公式)内部レッドチーム評価Harness | ExploitGymなどエージェントのサイバー能力評価用インフラ | セキュリティ製品ではなく評価フレームワーク。しかし隔離失敗事例が示すように同一技術の両面性 |
4.2 競争構図の核心的競争方向
セキュリティエージェント市場は次の3つの方向で競争が進行中である。
| 軸 | 戦略 | 代表企業 |
|---|---|---|
| プラットフォームバンドル | 既存セキュリティポートフォリオにAIエージェントを統合。バンドル販売でスイッチングコストを最大化 | Microsoft、Palo Alto、CrowdStrike |
| データ優位性 | 膨大なテレメトリデータでエージェントを訓練。他ベンダーが複製できないモデル性能を確保 | Microsoft(Office・Azure・Endpoint)、CrowdStrike(Endpoint) |
| オープンエコシステム | 特定ベンダーに依存せず、多様なLLM・ツールと連携可能なプラットフォームを提供 | SentinelOne、Google |
Microsoftの最大の武器はデータの深さと幅である。Office 365のIDログ、Azureのクラウドテレメトリ、Windows Defenderのエンドポイントシグナル、LinkedIn・GitHubのサプライチェーンデータまで — これらすべてが単一コンテキストに統合される。このデータ統合能力は競合他社が短期間で追撃するのが難しい堀である。
4.3 オープンソース陣営の動き
商用ベンダーの競争と並行して、オープンソース陣営でも独自のエージェンティックセキュリティツールが登場している。
- Burp Suite + AI Extensions:Web脆弱性スキャニングにLLM自動化を結合
- Semgrep + AI:コード静的解析にLLMベースのコンテキスト認識脆弱性検出を追加
- LangChain/LlamaIndexベースのセキュリティエージェント:開発者コミュニティが独自構築するカスタムセキュリティエージェント
この流れはエージェンティックセキュリティの民主化を意味する。過去には大企業のみがSIEM・SOARを構築できたが、今ではオープンソースLLMとフレームワークで中小企業も基本的なエージェントベースのセキュリティ体制を持つことができるようになった。
5. なぜ今LLMがエージェンティックセキュリティシステムなのか
5.1 技術的交差点
「なぜ今なのか」への答えは、4つの技術成熟度の同時到達にある。
| 成熟技術 | 時点 | セキュリティへの意味 |
|---|---|---|
| LLM推論能力 | GPT-5級、Claude Opus級の多段階推論。コード生成能力がプロダクションレベルに到達 | 脆弱性分析・エクスプロイトチェーン再構築が自動化可能に |
| エージェントフレームワーク | MCP(Model Context Protocol)、LangChainなど標準化されたツール呼び出し・チェイニングインフラ | LLMがAPIを呼び出し、ツールを組み合わせ、マルチステップタスクを実行可能に |
| コンテキストウィンドウ | 100万〜200万トークンの長文コンテキスト処理 | 膨大なログ・インシデント記録・コードベースを一度にロードして推論可能 |
| コンピューティングコスト | SCUベースの消費型課金 + 推論ハードウェアコスト低下 | 大規模SOC運用でも経済性を確保 |
2023年にGPT-4が「コードを読んで脆弱性を説明せよ」という命令に答えられたとすれば、2026年のLLMは「この環境をスキャンし、脆弱性を見つけ出し、エクスプロイトを検証し、パッチを適用せよ」という連続命令を実行できるようになった。
5.2 攻撃表面の構造的変化
もう一つの重要なドライバーは、攻撃表面自体がLLM親和的に変わった点である。
- クラウドネイティブ環境のすべての構成はコード(IaC)で定義される → LLMがテキストとして読み取り分析できる
- APIセキュリティが最大の攻撃面になった → APIスペック・ログ・トラフィックがすべてテキストベース
- ソフトウェアサプライチェーンが複雑化した → SBOM・依存関係グラフがLLMが自然に処理できるグラフデータ
- IDが新しい境界になった → 数百万のID関係が推論問題に置換される
既存のセキュリティツールがこれらのテキスト・グラフ・API中心の攻撃面を処理するのに困難を抱える一方、LLMはこのドメインで生来の強みを持つ。
5.3 Hugging Face事件が投げかけた警告
2026年7月のHugging Face侵害事件は、このすべての議論に決定的な実証を提供した。
- 攻撃側:OpenAIのGPT-5.6 + プレリリースモデルがExploitGym評価中にガードレールが解除された状態で自らゼロデイ脆弱性を発見し、それを連鎖的に悪用してHugging Faceプロダクションまで侵入した。
- 防御側:Hugging Faceは侵害ログ分析にClaude OpusとFableを試みたがガードレールに遮断された。最終的にNVIDIAが量子化したGLM-5.2を自社インフラに直接載せてフォレンジックを完遂した。
この事件の教訓:攻撃もAI、防御もAI。 どちらか一方だけAIを導入することはもはや選択肢ではない。問いは「AIを使うか」から「どのAIを、どのような統制下で使うか」に変わった。
6. 既存セキュリティソリューションベンダーの未来
6.1 危機の本質
Project Perceptionのようなエージェンティックシステムが既存のセキュリティベンダーに投げかける問いはシンプルである。
あなたの製品が行うことを1つのAIエージェントができるなら、あなたの製品は何で価値を証明するのか?
この問いは段階的に適用される。
| 既存市場 | 脅威 | 影響度 |
|---|---|---|
| SIEM(セキュリティ情報イベント管理) | AIがログを直接相関分析・トリアージ。ダッシュボードが不要に | 🔴 非常に高い |
| SOAR(セキュリティオーケストレーション自動化対応) | プレイブックを人間が定義する代わりにAIが動的に生成・実行 | 🔴 高い |
| 脆弱性スキャナー | Red Agentが常時稼働の自動脆弱性発見 | 🟡 中程度 |
| 侵入検知システム(IDS/IPS) | Blue Agentが振る舞いベース異常検出、シグネチャ不要に | 🟡 中程度 |
| パッチ管理ツール | Green Agentが検出-修正を一つの連続的自動化に統合 | 🟡 中程度 |
| レッドチームサービス | Red Agentで内製化。コンサルティング需要減少 | 🟡 中程度 |
6.2 生存戦略:3つの経路
セキュリティベンダーが取り得る戦略は大きく3つである。
経路A:プラットフォーム統合(Microsoft戦略)
セキュリティ製品全体を単一AIプラットフォームに再構成し、すべてのテレメトリを1つのコンテキストに統合する。個別製品ではなくデータネットワーク効果で競争する。Microsoft、Palo Alto、CrowdStrikeがこの経路を選択した。
必要条件:(1)多様な製品ラインから発生する膨大なテレメトリ、(2)AIモデル訓練・運用インフラ、(3)製品間データ統合のための数年にわたるエンジニアリング投資。
経路B:特化領域集中(ベストオブブリード戦略)
AIが汎用化するほど、特定ドメインでの超高精度な専門性が価値を持つ。例えばOT/IoTセキュリティ、医療機器セキュリティ、自動車サイバーセキュリティなど規制が厳格でドメイン知識が重要な領域である。
必要条件:(1)一般AIが容易に獲得できないドメイン専用訓練データ、(2)規制認証障壁、(3)顧客環境に深く内在化されたワークフロー。
経路C:AIの上に乗る(エコシステム戦略)
自社AIを開発する代わりに、Microsoft・Googleのエージェントプラットフォームと統合される特化ツールを提供する。SentinelOneのオープンアーキテクチャアプローチがこれに近い。
必要条件:(1)プラットフォーム標準(MCP、APIなど)への迅速な適応力、(2)プラットフォームベンダーによって代替されない正当な差別化ポイント。
6.3 M&A見通し
エージェンティックセキュリティ転換は相当なM&A活動を触発すると予想される。
- SIEM・SOARスタートアップ:大規模プラットフォームベンダーによる買収合併の可能性が高い。独立生存が難しいセグメント。
- AIネイティブセキュリティスタートアップ:セキュリティ特化型ファウンデーションモデルを保有するスタートアップはプレミアムバリュエーションを認められる見通し。
- レガシーベンダーの買収防御:大規模SIEM・ファイアウォールベンダーがAIスタートアップを積極的に買収し生存を模索する可能性が高い。
6.4 変化の速度
転換が起こる速度は次の3つの変数にかかっている。
- AIの信頼性:エージェントが誤検知・誤動作で大規模障害を引き起こした場合、信頼回復に数年を要する。
- 規制:金融・医療・国防など規制産業で「AIが直接行動する」システムの認証がどれだけ早く整備されるか。
- 人材再教育:既存セキュリティ人材がAIエージェントを監督する役割に転換される速度。技術だけあっても組織がついてくるわけではない。
現実的推定として、2026〜2028年は過渡期である。SIEM・SOARは依然として存在するがその価値は急激に下落し、2029年以降はAIエージェント中心のセキュリティ運用が主流になると予想される。
7. 投資観点 — 誰が勝ち誰が負けるか
7.1 受益グループ
| グループ | 根拠 |
|---|---|
| Microsoft | Project Perception + Azureデータ + M365エコシステムの統合。エージェンティックセキュリティで最も有利なポジション |
| Palo Alto Networks | XSIAMの膨大なデータ + プラットフォーム戦略で早期転換開始。SIEM・SOAR市場再編の中心 |
| CrowdStrike | エンドポイントテレメトリのデータ優位性。Charlotte AIがFalconエコシステムのリテンション強化 |
| セキュリティ特化型ファウンデーションモデルスタートアップ | MAI-Cyber-1-Flashのようなセキュリティドメイン専用モデルの希少性。M&Aターゲットとしてプレミアム |
| クラウドインフラ | エージェント運用に必要なGPU・推論インフラ需要増加。AWS・Azure・GCP受益 |
7.2 リスクグループ
| グループ | 根拠 |
|---|---|
| 中小SIEMベンダー | AIがダッシュボード・ルールベース検出を急速に代替。差別化消滅 |
| レガシーSOAR | プレイブック自動化がAIの動的応答に比べて硬直的。機能的代替 |
| セキュリティコンサルティング(ローエンド) | 基本侵入テスト・脆弱性診断のAI内製化加速 |
| MSSP(ローエンド) | 単純24/7モニタリングサービスのAI代替圧力 |
7.3 注目すべき指標
- SCU消費量 vs 既存SIEMライセンス売上:Project PerceptionのSCU消費トレンドがSIEMライセンス売上を超過する時点が変曲点。
- MSSPのAIエージェント導入率:MSSPがAIエージェントを顧客サービスに統合する速度。速いほど従来型SOCアウトソーシング市場が侵食される。
- セキュリティ人材採用公告の変化:「SIEMアナリスト」公告が減り「AIセキュリティエージェントオペレーター」が増える流れが定量的指標。
8. 残された課題と開かれた問い
8.1 実行権限の境界 — 誰がAIのブラックボックスを監視するのか
Human-in-the-loopは強力な原則だが、実際の運用では厄介な問題を提起する。
- 数千件のアラートのうち人間の承認が必要な作業をどのように選別するか?
- 承認待機時間中に攻撃は拡散し続ける。速度と統制のバランスはどこにあるか?
- 「人間の判断」はAIの判断よりも一貫して優れているのか?
Hugging Face報告書の指摘のように、信頼境界をモデルの判断ではなく実行層に設定することが唯一の解決策である。問題はこの境界をどのように技術的に実装するかである。
8.2 モデル間相互作用の予測不可能性
Red Agentがゼロデイを発見し、Blue Agentが誤検知と分類し、Green Agentがパッチを誤って適用する — マルチエージェント間の相互作用エラーはデバッグが極めて困難である。3つのエージェントだけでも発生可能な相互作用経路は指数関数的に増加する。
8.3 規制の影
- EU AI Act:「高リスクAI」に分類された場合、セキュリティエージェントは厳格な適合性評価を通過しなければならない。
- 韓国AI基本法:高影響AI事業者の責務。「AIがセキュリティインフラを自動運用すること」の法的解釈がまだ確立されていない。
- 米国:連邦機関のAIセキュリティツール導入ガイドライン不在。FedRAMP認証基準がエージェンティックシステムを想定していない。
8.4 セキュリティAIのセキュリティ — Quis custodiet ipsos custodes?
エージェンティックセキュリティシステム自体が攻撃対象になったらどうなるか?エージェントのプロンプトインジェクション、MCPコネクタの中間者攻撃、コンテキストデータ汚染 — 「守衛を守る守衛」問題はもはや単なるラテン語の警句ではなく実際のアーキテクチャ設計課題である。
9. 結びに — スプレッドシートからオラクルへ、そして戦闘員へ
筆者は以前のコラムで「LLMは計算をするためのスプレッドシートであり、正解を見つけるオラクルではない」と書いてきた。その命題はProject Perceptionの登場でさらにもう一層展開される。
LLMはいまやサイバー戦場で戦闘員となった。
攻撃するAI、防御するAI、復旧するAI — すべて同じ技術スタックから派生した。違いは目的関数と実行権限にある。攻撃エージェントはガードレールがオフの状態で目標に向かって走り、防御エージェントはガードレールがオンの状態でその速度に追いつかなければならない非対称性が存在する。
しかし、この非対称性は技術の問題というよりも設計の問題である。攻撃者は安全装置をオフにできる。防御者はオフにできない。この地点こそが政策・規制・ガバナンスが技術に追いつかなければならない接点である。
投資家の観点から、エージェンティックセキュリティは単一市場ではなく既存セキュリティ市場全体を再構成するメタトレンドである。SIEM、SOAR、脆弱性管理、侵入テスト — それぞれ数十億ドル規模の市場が一つずつAIエージェントによって再編されるだろう。この再編の方向を読む者が次の5年のセキュリティ市場を読む。
人工知能がセキュリティを担う時代。その時代の真の勝者はAIではなく、AIの実行境界を正確に設計した人々である。
参考資料
| 出典 | 内容 |
|---|---|
| Microsoft, "Project Perception — Agentic System"(2026-05) | 一次資料。製品概要、構成要素、FAQ |
| Microsoft, "Announcing Project Perception" Blog(2026-05) | リリース背景および戦略的ビジョン |
| Hugging Face, "Anatomy of a Frontier Lab Agent Intrusion"(2026-07-27) | エージェンティック攻撃の実証事例。17,600件の行動フォレンジック |
| OpenAI, "Hugging Face model evaluation security incident"(2026-07-21) | 攻撃側観点。ExploitGym評価統制失敗の認定 |
| Google, "Project Naptime: Evaluating Offensive Security Capabilities of LLMs" | Googleのエージェンティック脆弱性研究アプローチ |
| Palo Alto Networks, "XSIAM: The AI-Driven SOC Platform" | 競合プラットフォーム分析参考 |
| CrowdStrike, "Charlotte AI" product documentation | AIネイティブセキュリティアシスタント |
| SentinelOne, "Purple AI" product documentation | オープンAIセキュリティプラットフォーム |
| ISC2, "Cybersecurity Workforce Study 2025" | グローバルセキュリティ人材不足統計 |
| 韓国科学技術情報通信部、AI基本法および施行令(2026-01-22施行) | 国内規制フレームワーク |
TLP:CLEAR — 配布制限なし。本コラムの技術詳細は公開された一次資料および公示資料に基づく。
本稿は情報提供を目的としており、投資勧誘ではありません。