AiSOCは何を監査できるのか、セルフホスト型AI SOCの実像を読む
プロジェクト概要：オープンソースの AI を活用したセキュリティ オペレーション センター、アラート フュージョン、パープル チーム訓練、エージェント支援トリアージ、MITRE ATT&CK 調査。 MIT ライセンスを取得しており、自己ホスト可能です。
ひと目でわかる
- これは何？
- beenuar/AiSOCのREADMEとリポジトリ情報をもとに、アラート処理、調査台帳、評価、データ境界、導入上の確認点を整理します。
- 誰に向いている？
- AiSOCは、エージェントのプロンプト、応答、根拠、ツール呼び出しを後から追いたいセキュリティチームや、運用データの境界を自分で管理したい組織に検討余地があります。一方、READMEにある検知数や評価結果だけでは本番性能、誤検知率、保守体制までは判断できません。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 4 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月18日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
AiSOCが狙うSOCの作業範囲
beenuar/AiSOCは、セキュリティイベントの取り込み、相関、AIを使った調査、結果を表示するSOCコンソールを一つのセルフホスト型スタックにまとめるプロジェクトです。リポジトリの説明は、閉じたSaaSを置き換えたという実績ではなく、エージェントとその基盤を読める形で提供するという立場を示しています。MITライセンスで公開されているため、コードを読み、フォークし、構成要素を差し替える余地があります。
メタデータ上の実装言語はPython、既定ブランチはmain、アーカイブ状態はfalseです。2026年8月4日時点の取得情報では、2,384スター、252フォーク、23件のオープンイシューが記録されています。これらは関心の大きさや公開活動の手掛かりであって、検知精度や導入の容易さを保証する数字ではありません。評価するときは、人気と実際の運用適合性を分けて見ます。
60秒デモが示すアラート処理の境界
READMEには、環境に応じて複数の入口が用意されています。`npx aisoc triage --demo` は、アラートをエスカレーション、レビュー、抑制の判定へ分類する決定論的なエンジンを使うデモです。READMEの例では200件を処理し、12件をTP、171件を抑制、17件をレビュー対象とし、ノイズ率85.5パーセント、処理時間0.1秒と表示します。ただし、これは固定デモの出力であり、利用者のログや本番の検知精度を示す測定ではありません。
Python 3.10以上なら、`pip install -e packages/aisoc-sandbox && aisoc-sandbox demo` で、APIキーやネットワークを使わないメモリ内シミュレーターを動かせます。lateral-movement、aws-credential-exfil、phishing-payload、kubernetes-privesc、github-token-theftという同梱シナリオを選べ、独自JSONを`--file`で渡す経路も説明されています。Dockerとpnpmを使う実スタックはPostgres、Redis、Kafka、API、エージェント、Webを起動し、LockBit 3.0のシード済みケースを表示します。デモを本番運用の証拠に読み替えないことが大切です。
Investigation Ledgerが残す判断の連鎖
AiSOCの差別化点としてREADMEが挙げるのがInvestigation Ledgerです。各実行の各ステップについて、LLMに渡したプロンプト、返された応答、引用した証拠、次に行ったツール呼び出しを記録し、後から再生できると説明されています。調査担当者が最終判定だけを見るのではなく、どの入力がどの行動につながったかをたどれる設計です。公開用には編集済みのパーマリンクとして共有できるという説明もあります。
オーケストレーターは`services/agents/`に置かれた約600行のLangGraphとして紹介されています。小さい実装を読み切り、モデルを交換し、パッチを当てやすいというのがREADMEの判断です。実際に監査へ使えるかは、台帳の改ざん防止、アクセス権、保持期間、機密値のマスキング、再生時のモデル差分を確認しなければ決まりません。ログがあることと、ログが証拠として信頼できることは同じではありません。
イベントからコンソールまでの構成
READMEの構成図では、EDRやXDR、SIEM、クラウドAPI、アイデンティティ、ネットワークなどの情報源からコネクターを通じて取り込みと正規化を行い、Kafkaのイベントスパインへ流します。検知と推論の層にはフュージョン、UEBA、ルールエンジン、LangGraphベースのAIエージェントが置かれています。保存先としてPostgreSQL、ClickHouse、OpenSearch、Qdrant、Neo4j、Redisが挙げられ、外部向けの面にはFastAPIのコアAPI、Next.jsのWebコンソール、TypeScriptのMCPサーバーがあります。
この一覧は大規模な配置を把握する地図としては有用ですが、各サービスの容量、障害時の挙動、データ保持方針、必要な権限までを説明するものではありません。完全な構成の詳細は`apps/docs/docs/architecture.md`にあるとREADMEが案内しています。導入候補にする場合は、まず必要な部品だけを選び、ログとアラートがどの保存先に複製されるか、停止時に調査がどこまで続くかを設計書と実機で突き合わせます。
検知コーパスとCI評価をどう読むか
READMEは、947件の実行可能な検知ルール、そのうち869件のネイティブルール、出所を追跡できる6,000ルールのインポートライブラリを主張しています。また、mainまたはdevelopを対象にしたプルリクエストを5つの評価スイートでゲートすると説明します。固定された1,000アラートのストリームに対するアラート削減測定、55テンプレートを含む決定論的な200インシデントデータセットを使う3つのルーブリック系スイート、基盤テレメトリのコーパスを確認するスイートが構成要素です。
ここで確認できるのは、評価の枠組みが公開文書に書かれていることです。ルール数や、実環境での検出率、ノイズ抑制の再現性は、この入力だけから検証できません。READMEは`apps/docs/docs/benchmark.md`で各スイートが測るものと測らないものを説明するとしています。候補組織はその定義を読み、自分のログ形式、攻撃パターン、誤検知のコストがベンチマークの対象と重なるかを確認する必要があります。
データを境界内に置くための選択肢
プロジェクトは、ベンダークラウドへのコールバックやモデル改善用のテレメトリを行わないとREADMEで説明しています。ホスト型LLMを使う場合は、内部IP、ホスト名、メールアドレス、パス、シークレット、ユーザー名を不透明なトークンへ置き換える擬似匿名化が既定とされています。OllamaやvLLMのローカルモデルを使えば、完全にエアギャップされた経路を選べるという案内もあります。どのモードで何が外へ出るかは`docs/trust/data-flows.md`を確認する設計です。
この説明はデータ境界を設計するための材料であり、導入先の規制要件を満たす証明ではありません。マスキング対象から外れる値、プロンプトの保存先、障害ログ、バックアップ、管理者が台帳を閲覧できる範囲を個別に確認してください。外部モデルを許可しない組織では、まずローカルモデルを使う最小構成で調査品質と資源消費を測り、外部接続を追加する場合は送信項目を差分として審査します。
編集部の結論
AiSOCは、エージェントのプロンプト、応答、根拠、ツール呼び出しを後から追いたいセキュリティチームや、運用データの境界を自分で管理したい組織に検討余地があります。一方、READMEにある検知数や評価結果だけでは本番性能、誤検知率、保守体制までは判断できません。まずaisoc-sandboxのオフラインデモで調査の流れを確認し、次に自組織のデータを外部モデルへ送らない構成、保存先、権限、復旧手順を小さな検証環境で確かめてから採用範囲を決めるべきです。
コミュニティノート