Microsoft Project Perception 代替8選 無料・OSSで組む選び方 (2026年版)

「Microsoftの新しいセキュリティ基盤が良さそうだけど、うちの環境では待てない」。そんな状況で代替を探しているなら、探す対象を先に整理したほうが早いです。答えを先に書くと、代替になるのは単体ツールではなく、3層の組み合わせです。

Microsoft Project Perceptionとは、社内のデジタル環境に散らばるセキュリティデータをひとつの「セキュリティコンテキスト」としてつなぎ、複数のAIエージェントが同じ状況認識を共有できるようにする仕組みです。マイクロソフトの説明によれば、資産・ID・関係性・リスク・活動を継続的に更新される見取り図として保持し、エージェントは毎回シグナルを集め直さなくても、必要な情報に効率よくアクセスしてリスクを推論し、対応の優先順位を付けられるようになります。

つまり主役は検知エンジンではなく、その手前にある情報の地図。ここを理解しないまま「代わりのEDRを探す」と、まったく別の買い物になります。

Project Perceptionの正体は「検知」ではなく「共通の地図」

公開されている設計思想を要約すると、Project Perceptionの中核はエージェントが共有する状態の地図です。検知そのものは既存製品が担い、その出力に意味づけをします。

ここが分かると代替探しの筋が通ります。従来のセキュリティ運用では、アラートが来るたびに担当者が「この端末は誰の？」「この権限は本来必要？」「先週も似た事象があった？」を手作業で集めていました。この調査の前工程を、あらかじめ構造化して持っておくのが地図の役割です。

AIエージェントにとっての利点は分かりやすい。毎回ゼロから文脈を集め直すと、扱う文字のかたまり（トークン）を大量に消費します。地図が先にあれば、必要な部分だけを引けます。

要するに、代替を組むなら「アラートを出す道具」より「アラートに意味を与えるデータ構造」を先に用意する。ここを外した構成は、AIを乗せても賢くなりません。

なぜ代替を探すことになるのか

代替検討の理由は、機能不満よりも前提条件のミスマッチが大半です。よくある4つを挙げます。

• Microsoft 365やEntraを中心に据えていない環境で、旗艦機能の恩恵が薄い
• 提供形態や料金の詳細が読めず、稟議の数字を作れない
• 生ログを国外リージョンに置けない業界要件がある
• 検証したいのが「今」で、正式提供を待てない

とくに3つ目は日本の企業で重い制約です。金融・医療・公共の周辺では、データの所在そのものが要件表に書かれます。

閉域で回したいなら、選択肢は自然とオープンソースへ寄ります。ここから具体的な組み方に入ります。

代替を選ぶ前に決めておく3つの軸

道具から入ると必ず迷います。先に3つの軸を決めると、候補は勝手に絞られる。

つまり、置き場所と人手の2つが決まった時点で、オープンソース中心か商用中心かはほぼ確定します。AIの深さは後から足せる部分。

この3軸を紙1枚に書いてから、次の候補一覧を見てください。

無料・オープンソースの代替8選

無償で使え、商用利用も認められている定番を機能レイヤー別に並べます。すべて自社サーバーで動かせます。

つまり、Project Perceptionが1つの製品でまとめている領域を、8つの部品に分解して組み直す形になります。全部を同時に入れる必要はありません。

最小構成の答えは後半で出します。まず「地図」の作り方から。

オープンソースで「見取り図」をどう組み立てるか

地図づくりは3ステップで考えると迷いません。集める、揃える、つなぐ。

集めるはWazuhとosqueryの担当です。Wazuhは各端末にエージェントを入れてログとファイル変更を拾い、osqueryは「どの端末に何が入っているか」をSQLで問い合わせられるようにします。この2つで、資産の実態がテキストで引ける状態になります。

揃えるが地味に効きます。ログの項目名がバラバラだと、AIに読ませても関連づけができません。ここでOCSF（セキュリティログの共通スキーマ）に寄せておくと、後工程が一気に楽になります。検知ルールもSigmaという共通記法で書けば、基盤を乗り換えても資産が残る。

つなぐはOpenCTIの仕事です。攻撃者・手口・侵害指標・自社資産を関係グラフとして持てるので、Project Perceptionが言う「関係性の見取り図」に最も近い。

ここまでの整理：集める（Wazuh・osquery）→ 揃える（OCSF・Sigma）→ つなぐ（OpenCTI）。この3段を作れば、AIエージェントが読む土台は完成します。逆にここを飛ばして生ログをそのままLLMに投げる構成は、費用ばかりかかって精度が出ません。

土台ができたら、ようやくAIの出番です。

AIエージェントはどう接続する？

接続の主流はMCP（他のソフトからAIを呼び出す窓口を標準化した仕組み）経由です。OpenCTIやWazuhはREST APIを持つので、その前段にMCPサーバーを1枚かませて、エージェントから「この端末の直近7日の変更点」「この指標に関連する資産」を問い合わせられるようにします。

エージェント側の作り方は2通り。

• コードを書かずに組むなら Dify や n8n でワークフロー化する
• 調査の推論品質を優先するなら Claude などのモデルに直接ツールを持たせる

自動化の入り口としては前者が速い。ワークフロー型の自動化ツールをまだ触っていないなら、n8n から入ると全体像がつかみやすいです。

ここで大事なのは、エージェントに書き込み権限を渡さないこと。読み取りと要約までを任せ、遮断や隔離は人が押す。最初の3か月はこの線引きを守ったほうが安全です。

権限設計の話は、統制の観点で監査部門と衝突しやすい部分でもあります。監査側の道具立てを先に知っておくと話が早いので、内部監査で使えるAIツールの整理に目を通しておくと、社内説明の手間が減ります。

無料でどこまでできる？

製品費という意味では、紹介した8つはすべて0円です。かかるのはサーバー代と人件費だけ。

ただし無料には条件が付きます。ライセンスはApache 2.0、GPL、AGPLなどが混在していて、とくにAGPLのものを自社サービスに組み込んで外部提供する場合は扱いが変わります。社内利用に留めるなら気にする場面はほぼありません。

無料構成で現実に詰まるのは、次の3点です。

• 日本語の一次サポートがない（英語ドキュメントと有志コミュニティ）
• バージョン更新の追従を自分でやる
• 障害時に「聞ける相手」がいない

逆に言えば、Linuxの運用ができる人が1人いれば回ります。専任がゼロなら、無料構成は結局高くつく。ここは正直に見積もったほうがいい。

費用の比較は後半の表で数字の形にします。

日本語で運用できる？

管理画面はほぼ英語です。ここは期待しないほうがいい。

ただ、実務上の詰まりは思ったより小さい。理由は、読む必要があるのは画面ではなく調査結果だからです。APIから引いたJSONをLLMに渡して日本語で要約させれば、日々の運用は日本語で完結します。アラートの説明文、影響範囲の整理、報告書の下書き。このあたりは自動化と相性がいい。

日本語で調べ物をする段階では、国内の情報源に強い検索AIを併用すると速いです。Feloの使い方を押さえておくと、脆弱性の国内報道や公的機関の注意喚起を拾う速度が変わります。

自社ホストのモデルで完結させたい場合は、オープンウェイトのモデルを社内に置く選択肢もあります。その系譜を整理したMeta AIの解説が入り口として分かりやすい。

つまり、日本語対応は「ツールの機能」ではなく「構成の設計」で解決します。次は商用側の話。

商用ツールで置き換えるならどれ？

人手が足りない、あるいは経営から「面倒を見てくれる相手」を求められている場合は、商用に寄せる判断が正解になります。国内で稟議が通りやすい代表格を整理します。

料金は公開されていない、あるいは条件で大きく動くものが多く、見積もり前提で考えてください。ここに一般論の金額を書いても稟議には使えません。

つまり、守る対象が端末なのかコードなのかで、選ぶ列がまるごと変わるということ。両方を1本でまかなおうとすると、たいてい高い買い物になります。

国内のセキュリティ支援も選択肢に入れるなら、Flatt Security のような診断寄りのサービスと組み合わせる形が現実的です。カテゴリ全体はAIセキュリティにまとまっています。

商用とオープンソース、費用はどう違う？

比較の軸を「製品費」だけにすると判断を誤ります。人件費と立ち上げ時間を並べて見てください。

つまり、OSSは「金の代わりに人を出す」構成です。人が出せない組織が選ぶと、半年後に誰も触れない基盤が残る。ここは何度も見てきた失敗です。

判断の目安を1つ。セキュリティに割ける工数が週8時間を下回るなら、商用に寄せたほうが総額は安くなります。

4週間で立ち上げる手順

いきなり全社は無理です。範囲を絞って型を作る。

1週目：検証用サーバーを1台立て、Wazuhを入れて端末10台だけ接続します。ここでログが届く感触をつかむ。

2週目：osqueryを足して資産情報を引けるようにし、ログ項目をOCSFに寄せる設計を決めます。この週の成果物は設計メモ1枚。

3週目：OpenCTIを立てて、外部の脅威情報と自社資産をひも付けます。ここで初めて「地図」らしくなります。

4週目：MCP経由でAIエージェントを接続し、読み取り専用で調査の要約を試します。人が出す結論と突き合わせて、ズレを記録する。

この4週間で出す答えは「本番に載せるか、商用に切り替えるか」の一択です。判断を先送りにすると検証環境が塩漬けになります。

構成図を社内資料にまとめる段階では、図を作る道具も要ります。生成AIで図版を作る場合、ローカルで完結させたいならComfyUIとStable Diffusionの違いが参考になりますし、資料の挿絵をもっと手軽に済ませたいならイラスト生成ツールの比較から選ぶのが早いです。

移行で失敗しやすい3点

同じつまずき方をよく見ます。先に潰しておいてください。

1つ目、生ログをそのままLLMに投げる。文字数が膨らむだけで精度は上がりません。構造化してから渡す。

2つ目、エージェントに遮断権限を渡す。誤検知1件でネットワークが止まると、そこで信頼は終わります。読み取りから始める。

3つ目、SigmaやOCSFのような共通書式を使わない。独自形式で作り込むと、乗り換えのたびにゼロからやり直しになります。標準に寄せるのは、将来の自由度を買う行為。

この3つを守れば、途中で商用に切り替えても資産は残ります。

AI PICKS編集部の判定

Project Perceptionの代替を「1本の製品」で探しているなら、正直イマイチな結論しか出ません。あれは検知プロダクトではなく、AIエージェントに読ませるための情報構造の話だからです。

その前提に立てば、無料のオープンソースは破格です。Wazuh・osquery・OpenCTIの3点なら製品費ゼロで、しかも生ログを国外に出さずに済む。閉域要件がある組織にとっては、これ以上ない出発点になります。SIEMを検討したことがある担当者なら、1〜2週間で感触はつかめるはず。

ただし条件付きです。Linuxを触れる人が1人いること。ここが欠けると、半年後に誰も更新しない基盤が残ります。週8時間を割けないなら、CrowdStrike や SentinelOne のような商用に寄せたほうが総額は安い。

編集部の推しは1つ。まず4週間の検証を回して、自社に運用能力があるかを測ること。 道具選びより先に、人の余力を測る。ここを飛ばした導入は、値段にかかわらずうまくいきません。

よくある質問（FAQ）

Q. Project Perceptionは今すぐ使えますか？

公開されている情報は設計思想の説明が中心で、提供形態や料金の詳細は限られています。導入計画に組み込むなら、マイクロソフトの公式発表を確認したうえで、当面は既存製品での代替を前提に設計しておくのが安全です。

Q. 無料のオープンソースだけで本番運用しても大丈夫ですか？

技術的には可能です。実際、閉域環境でWazuhを本番運用している例は珍しくありません。ネックは人。障害対応と更新追従を自分でやる覚悟があるかどうかが分かれ目です。

Q. 日本語のサポートは受けられますか？

紹介したオープンソースは日本語の公式サポート窓口を持ちません。日本語で相談したいなら、国内のセキュリティ支援企業に運用を委託するか、商用製品の国内代理店経由で契約する形になります。

Q. どれか1つだけ選ぶとしたら何から入れるべきですか？

Wazuhです。端末とサーバーのログ集約という土台を先に作らないと、他のツールを足しても効果が見えません。逆に言えば、ここさえあれば後から順番に足せます。

Q. AIエージェントに任せると誤検知は減りますか？

減るのは誤検知そのものではなく、調査にかかる時間です。アラートの一次整理と関連情報の収集を任せると、担当者は判断に集中できます。検知精度はルールとデータの質で決まる部分が大きい。

Q. クラウドの設定ミスも同じ仕組みで見られますか？

見られます。ただしレイヤーが違うので、専用の点検ツールを足す形になります。開発とクラウド構成をまとめて見るなら Aikido Security、依存パッケージの脆弱性なら Snyk が守備範囲です。

Q. 社内に専任がいない場合の現実的な選択肢は？

商用SaaSと外部監視サービスの組み合わせです。オープンソース構成は「人件費を払う代わりに製品費を浮かせる」設計なので、人がいない前提だと成立しません。

Q. 途中でオープンソースから商用に乗り換えられますか？

可能です。ただし条件があって、検知ルールをSigma、ログ項目をOCSFのような共通書式で持っておくこと。独自形式で作り込むと、乗り換えコストが跳ね上がります。

関連する比較・代替を見る

用途別に代替候補を絞り込むなら、この順で見ると重複が減ります。

• CrowdStrikeの代替を見る — 端末防御を軸に置き換えたいとき
• Splunkの代替を見る — ログ分析基盤のコストを見直すとき
• Aikido Securityの代替を見る — 開発とクラウド構成をまとめて守りたいとき
• Snykの代替を見る — 依存パッケージの検査を安く回したいとき
• Semgrepの代替を見る — コード検査のルール運用を比較したいとき
• Microsoft 365 Copilotの代替を見る — Microsoft依存を減らす前提で考えるとき
• セキュリティ関連ツール一覧 — カテゴリ全体を眺めたいとき

次に読むならこれ。統制側の説明で必ず突っ込まれるポイントを先回りできるので、内部監査で使えるAIツールの整理を先に読んでおくと、稟議の往復が1回減ります。

各ツールの公式サイト（一次情報）

料金・機能・対応範囲は各社公式が一次情報です。本記事は公開時点の検証に基づきますが、最新かつ正確な条件は必ず各公式ページで確認してください。

• CrowdStrike Charlotte — 公式サイト（AI PICKSの詳細）
• SentinelOne — 公式サイト（AI PICKSの詳細）
• Splunk AI — 公式サイト（AI PICKSの詳細）
• Aikido Security — 公式サイト（AI PICKSの詳細）