2026年のサイバー防御における検知工学：多層テレメトリ、行動連鎖、統計的異常検知、eBPF可観測性、そしてAI時代の侵入兆候把握

1. Introduction

2026年のサイバー防御において、「検知」はもはや単一の製品カテゴリでも、SIEMのアラート相関だけを意味する工程でもない。検知とは、エンドポイント、ID、ネットワーク、クラウド、SaaS、コンテナ、OT、さらにはAIワークロードまで含めた多層観測面から、敵対的活動の痕跡を取得し、文脈化し、意味付けし、封じ込めに十分な確度へ変換する工学的プロセスである。攻撃者は、従来型のマルウェア配布から、認証情報の窃取、OAuth同意の悪用、MFAプッシュ疲労、セッションハイジャック、正規ツールの悪用、クラウド制御プレーンの横断、コード署名の濫用、コンテナ逃避、さらにはLLMを用いた標的型フィッシングへと戦術を拡張してきた。したがって、防御側は「見つける」だけでなく、「何を見つけるべきか」「何を見つけなくてもよいか」「いつアラートを出し、いつ自動封じ込めするか」を定式化しなければならない。

この問題は、2020年代前半に成熟したゼロトラストとクラウド移行の潮流、そして2024年以降に急速に拡大した生成AI利用の影響によってさらに複雑化した。検知対象は、もはや実行可能ファイルや単純なIOCに限定されない。たとえば、OAuthアプリへの異常な同意、短時間に集中する地理的に不自然なログイン、特権ロールの一時昇格、Kubernetes APIへの不自然なkubectl exec、curl | bash型の初期侵入、そしてeBPFで観測可能なシステムコール列の異常な遷移が、より高い価値を持つ兆候となる。さらに、暗号化トラフィックの増加により、従来のペイロード中心検知は限定的な有効性しか持たない。検知はネットワーク境界からエンドポイント内部、そしてアイデンティティ平面へと重心を移したのである。

本稿の中心命題は、高品質な検知は「ルールの多さ」ではなく、「観測の多様性」「イベントの正規化精度」「行動連鎖の相関」「資産文脈による重み付け」によって決まる、という点にある。実務では、数千本の雑多なルールを積み上げても、アナリストの疲弊、アラートの重複、優先順位の誤り、そして本当に重要な攻撃の見逃しが起こる。逆に、少数の精緻な検知であっても、クラウド制御プレーンやIDログ、ホスト観測、ネットワークセンサを横断して相関できれば、横展開や権限昇格の段階で敵対活動を捉えられる。本研究は、この「少数高精度」を目指すのではなく、多層・多段・低ノイズの観測を統合した検知基盤を提案する。

本稿では、検知を以下の四層に分解して扱う。第一に、観測層では、EDR、NDR、WAF、IAM監査、SaaS監査、Kubernetes監査、eBPF、Sysmon、Auditd、OpenTelemetryを通じて、実行・認証・通信・設定変更を取得する。第二に、正規化層では、異種ログを共通スキーマにマップし、ATT&CK技法、資産重要度、ユーザ文脈、タイムウィンドウを付与する。第三に、推論層では、ルールベース検知、統計的異常検知、時系列グラフ推論、そして半教師あり学習を組み合わせる。第四に、運用層では、封じ込め閾値、SOAR自動化、チケット優先度、説明可能性、そして誤検知削減を設計する。これらは独立ではなく、相互に制約し合う。

本稿の貢献は三つである。第一に、2026年の実務脅威を前提に、検知を攻撃連鎖の観測問題として再定式化する。第二に、eBPF、クラウド監査、ID観測を含む多層検知アーキテクチャを具体化し、実装可能なルールとパイプラインを提示する。第三に、評価指標として単純な再現率だけでなく、検知遅延、アラート集中度、アナリスト1件あたり処理時間、資産重要度加重検知率を導入し、運用実態に沿った比較を行う。

2. Background and Related Work

検知研究の出発点は、ネットワークIDSとホストベース検知である。古典的なシグネチャ型検知は、既知の悪性パターンを高速に捕捉するうえで有効だったが、攻撃者がペイロードを暗号化し、Living-off-the-Landを多用し、正規クラウドAPIへ移行したことで、検知の主戦場は変化した。SnortやSuricataのようなNIDSは依然重要であるが、TLS 1.3、QUIC、ECHの普及により、トラフィック内容を直接見ない観測が増え、メタデータと振る舞いの解析が相対的に重要になっている（ROESCH, 2017; THE SURICATA PROJECT, 2026）。

ホスト検知の進化としては、Sysmon、Auditd、EDR、そして近年のeBPF観測がある。SysmonはWindows環境でのプロセス生成、ネットワーク接続、ファイル作成などの高価値イベントを提供し、AuditdはLinuxの監査ログを提供する。eBPFは、カーネル内部で安全にイベントをフックし、システムコール、ネットワーク、ファイル、TLS、スケジューリングを低オーバーヘッドで可観測化する。FalcoやTetragonのような実装は、コンテナ環境やKubernetesにおける実行時検知を実用水準へ押し上げた（FALCO, 2026; CILLI, 2024）。この流れは、単なるログ収集から、実行時の意図を推定する方向へ進んでいる。

クラウドとSaaSの普及は、検知の重心をさらにIDと制御プレーンへ移した。Microsoft Entra ID、AWS CloudTrail、Azure Activity Log、Google Cloud Audit Logs、Okta System Log、GitHub Audit Logのような監査データは、侵入の初期段階から権限昇格、永続化、データアクセスまでを可視化する。特にOAuthアプリ同意、APIキー発行、条件付きアクセスの回避、サービスアカウントの乱用などは、ホスト単体では見えないが、IDと設定変更の相関で初めて攻撃として浮かび上がる（MICROSOFT, 2026; AWS, 2026; GITHUB, 2026）。

検知の理論的発展としては、異常検知、グラフ分析、機械学習、そして近年はAI支援分析がある。異常検知は、正規分布仮定、密度推定、Isolation Forest、One-Class SVM、LSTM、オートエンコーダなどを利用して平常時との差異を捉える。しかし、サイバー領域では「異常」が必ずしも悪性ではなく、組織変更、ソフトウェア更新、バッチ処理、災害復旧訓練などで大量の例外が発生する。そのため、純粋な異常スコアだけでは運用に耐えない。近年の研究は、異常検知に資産文脈や行動連鎖を加える方向へ進み、ATT&CK技法との写像を通じて人間の判断負荷を下げようとしている（MITRE, 2026a）。

グラフベース検知は、ユーザ、ホスト、プロセス、IP、ドメイン、クラウドリソースをノードとし、通信や継承、認証、アクセスをエッジとして表現する。これにより、単発イベントでは見えない横展開、ピボット、データ収集の連鎖が見える。因果推論を厳密に適用するには限界があるものの、時系列グラフにおけるサブパスの密度や中心性は、攻撃キャンペーンの特徴量として有効である。実務では、GraphMLやProperty Graphを中心に、相関エンジンを構築するケースが増えている。

AI時代の脅威も検知研究に新しい要求を課した。攻撃者はLLMを用いて文法的に自然なフィッシング、ヘルプデスク詐欺、マルウェア文面の大量生成、偽の内部通知を作成できる。さらに、AIツールチェーン自体が新たな攻撃対象となる。モデル汚染、プロンプトインジェクション、RAG汚染、システムプロンプト漏えい、エージェントの権限逸脱は、従来のEPP/NDRだけでは捉えられない。NISTのAI RMFやISO/IEC 42001は、AIガバナンスと監査の枠組みを与えるが、現場で必要なのは、AIワークロードの入出力、モデルアクセス、推論ログ、ツール呼び出しを観測可能にする検知設計である（NIST, 2023; ISO/IEC, 2023）。

以下に、主要観測源とその検知価値を比較する。

観測源	主な対象	強み	限界	代表ツール
EDR/Sysmon	ホスト実行、プロセス連鎖	実行起点の高精度検知	OS依存、暗号化回避	Sysmon, Microsoft Defender for Endpoint
eBPF	システムコール、ネットワーク、ファイル	低オーバーヘッド、コンテナ適性	実装複雑、カーネル依存	Falco, Tetragon, Cilium
IAM/IDログ	認証、権限昇格、同意	初期侵入と永続化に強い	ノイズが多い	Entra ID, Okta, CloudTrail
NDR	通信、C2、横展開	横断観測、資産非依存	TLS/QUICで可視性低下	Suricata, Zeek
SaaS監査	メール、ドキュメント、共有	データ流出の把握	ベンダー依存	Microsoft 365, Google Workspace
CNAPP	クラウド設定、CI/CD、実行時	構成逸脱とランタイムを統合	誤検知調整が必要	Prisma, Wiz, Lacework

表から分かるように、検知の価値は単独ではなく、相互補完にある。ホストが見えない攻撃はIDで、IDが見えない攻撃は通信で、通信が見えない攻撃は実行時で補う必要がある。これが、2026年の検知設計の基本原理である。

3. Threat Model and Problem Formalization

本稿では、検知問題を、観測列 $X={x_1,x_2,\dots,x_n}$ から、敵対的行動の存在とその連鎖 $Y={y_1,\dots,y_m}$ を推定する課題として定式化する。各観測 $x_i$ は、時刻 $t_i$、主体 $s_i$、対象 $o_i$、操作 $a_i$、コンテキスト $c_i$ を持つイベントである。すなわち、$x_i=(t_i,s_i,o_i,a_i,c_i)$ と表せる。ここで主体はユーザ、ホスト、サービスアカウント、コンテナ、プロセスのいずれかであり、対象はファイル、レジストリ、API、ネットワーク先、クラウドリソースなどである。攻撃検知の目的は、真の敵対的状態 $A=1$ を、観測系列から推定し、かつ誤検知による運用負荷を許容範囲に抑えることである。

形式的には、検知器 $D$ は以下を最大化する。

$$ \max_D ; \mathbb{E}[U(D)] = \alpha \cdot \mathrm{TPR} - \beta \cdot \mathrm{FPR} - \gamma \cdot L $$

ここで、$\mathrm{TPR}$ は真陽性率、$\mathrm{FPR}$ は偽陽性率、$L$ はアラナリスト負荷または平均処理時間、$\alpha,\beta,\gamma$ は組織のリスク選好に応じた重みである。実務では、資産重要度 $w(o)$ を導入し、重要資産に対する見逃しコストを高く設定する必要がある。したがって、評価関数は単純な平均ではなく、資産加重検知率で表すべきである。

$$ \mathrm{WDR}=\frac{\sum_{k=1}^{m} w(o_k)\cdot \mathbb{1}[\text{attack}k \text{ detected}]}{\sum{k=1}^{m} w(o_k)} $$

脅威モデルは、以下の前提を含む。第一に、攻撃者は少なくとも一部の初期侵入手段を保有している。たとえば、フィッシング、盗難認証情報、公開サービス脆弱性、サプライチェーン侵害、あるいは内部者協力である。第二に、攻撃者は検知回避を試みる。具体的には、正規ツールの悪用、低速化、時差分散、ログ改ざん、暗号化、Living-off-the-Land、クラウドAPIの直接利用などが含まれる。第三に、防御側は一部の観測欠損を許容するが、ID、ホスト、クラウドのうち少なくとも二つの観測面は利用可能とする。第四に、リアルタイム性は完全ではなく、遅延 $d$ のある準リアルタイム検知を想定する。

検知対象の行動は、ATT&CK技法で表現すると運用上扱いやすい。たとえば、T1566（Phishing）、T1078（Valid Accounts）、T1059（Command and Scripting Interpreter）、T1021（Remote Services）、T1105（Ingress Tool Transfer）、T1003（OS Credential Dumping）、T1041（Exfiltration Over C2 Channel）、T1486（Data Encrypted for Impact）、T1071（Application Layer Protocol）などである（MITRE, 2026a）。ただし、ATT&CKへの写像は万能ではない。新規TTPや環境固有の挙動は既存技法に完全には収まらないため、技法ラベルは推論補助と位置づけるのが妥当である。

検知の困難性は、観測ノイズと敵対的適応の二重性にある。単純な統計異常は、管理作業やバッチ処理と混同しやすい。一方、閾値を高くしすぎると低速侵入や段階的横展開を見逃す。したがって、実用的な検知は、単一イベントではなく「イベント列の意味」を捉える必要がある。ここで重要なのが、時間窓 $\Delta t$ を持つシーケンス判定である。ある攻撃連鎖 $S = \langle x_i,\dots,x_j\rangle$ が、同一主体または相関主体にまたがり、短時間に権限昇格、認証、リモート実行、データアクセスを含む場合、その連鎖の危険度は単発イベントより高い。

したがって、本研究の問題設定は以下の通りである。与えられた多層観測ストリームから、敵対的連鎖候補を高再現率で抽出し、誤検知を抑えながら、封じ込め判断に十分な説明性を持つ検知スコアを生成する。このとき、検知器は環境変化、資産重要度の差、観測欠損、攻撃者の回避行動に対して頑健でなければならない。

4. Proposed Methodology

本稿では、検知を「観測正規化」「連鎖推論」「資産重み付け」「運用制御」の四段階に分ける方法論を提案する。第一段階の観測正規化では、異種ソースからのイベントを共通スキーマへ変換する。第二段階の連鎖推論では、イベント間の時間的・論理的関係をグラフとして構築する。第三段階の資産重み付けでは、対象の重要度と文脈をスコアへ反映する。第四段階の運用制御では、アラートの自動抑制、自動封じ込め、人手確認を組み合わせる。

観測正規化では、OpenTelemetry、ECS、OCSF、Sigmaのような標準化の恩恵を活用する。たとえば、process.name、user.id、src.ip、cloud.account.id、k8s.pod.name などの共通キーを設定し、Sigmaルールを複数バックエンドへ翻訳できるようにする。これにより、Windows、Linux、クラウド、SaaSの横断検索が可能になる。現場では、完全なスキーマ統一は困難だが、最小共通項を定義するだけで相関品質は大きく改善する。

連鎖推論では、イベントをノード、関係をエッジとする時系列有向グラフ $G=(V,E)$ を生成する。エッジは、同一主体による連続操作、親子プロセス関係、認証後のアクセス、DNS解決後の通信、コンテナ起動後のシェル実行などを表す。各エッジには重み $p(e)$ を割り当て、技法遷移確率、時間差、資産重要度を加味する。連鎖スコアは、以下のように定義できる。

$$ S(\pi)=\sum_{e \in \pi} \left( \lambda_1 \cdot \log \frac{1}{P(e)} + \lambda_2 \cdot w(o_e) + \lambda_3 \cdot \phi(\Delta t_e) \right) $$

ここで、$\pi$ は候補パス、$P(e)$ は平常時の遷移確率、$w(o_e)$ は対象資産の重み、$\phi(\Delta t)$ は時間差の危険度関数である。短時間に連続する権限昇格や認証失敗の反復は、$\phi$ により高スコア化される。逆に、夜間の定常バッチやCI/CDの既知フローは低スコア化される。

第三段階の資産重み付けは、業務影響を反映する。たとえば、同じcmd.exe起動でも、開発端末上の自動更新と、金融系特権サーバ上の未知プロセスでは意味が異なる。資産重みは、機密性、可用性、規制、外部公開性、特権レベルを含む関数として定義し、以下を用いる。

$$ w(o)=\eta_1 C + \eta_2 I + \eta_3 A + \eta_4 P + \eta_5 E $$

ここで、$C$ は機密性、$I$ は完全性、$A$ は可用性、$P$ は特権度、$E$ は外部公開性を表す。これは実務の優先順位付けに直結し、検知精度が同じでも封じ込めの判断が変わる。

第四段階の運用制御では、検知をSOARへ接続する。ただし、自動封じ込めは慎重に設計すべきである。たとえば、MFA疲労攻撃が疑われる場合、即時セッション失効は有効だが、誤検知なら業務停止を招く。よって、スコア帯に応じて「観測強化」「チケット起票」「セッション無効化」「端末隔離」を段階化する。これは、検知を二値分類からリスク制御へ移行させる考え方である。

以下に、実務で用いる検知ルールの例を示す。Sigmaを用いた高価値認証異常と、YARAを用いたスクリプト痕跡の組み合わせである。

id: 8f0c3b11-2d3e-4a7a-9b4d-4f0a1d0b1c22
status: experimental
logsource:
  product: microsoft
  service: azuread
detection:
  selection_consents:
    ActivityDisplayName|contains:
      - "Consent to application"
      - "Add app role assignment to service principal"
  selection_mail:
    ActivityDisplayName|contains:
      - "Read mail"
      - "MailItemsAccessed"
  timeframe: 30m
  condition: selection_consents and selection_mail
fields:
  - UserPrincipalName
  - AppDisplayName
  - IPAddress
level: high

# LinuxホストでeBPFベースの可観測性を有効化する例
kubectl apply -f https://raw.githubusercontent.com/cilium/tetragon/v1.1.0/install/kubernetes/tetragon.yaml

# 既存のFalcoルールセットにクラウドネイティブな不審execルールを追加
falco -r /etc/falco/falco_rules.yaml -r /etc/falco/k8s_audit_rules.yaml

方法論の狙いは、検知精度の最大化ではなく、攻撃連鎖の早期把握と、運用上の実行可能性の両立である。高精度な単発検知は重要だが、実務上は「見えた時点で遅い」ことが多い。ゆえに、異なる観測源から弱いシグナルを組み合わせることが本質となる。

5. Implementation

実装は、収集、正規化、相関、分析、通知の五層で構成する。収集層では、WindowsはSysmonとWindows Event Forwarding、LinuxはAuditdとeBPF、ネットワークはSuricataとZeek、クラウドはCloudTrail、Entra ID、GCP Audit Logs、SaaSはMicrosoft 365とGitHubの監査ログを用いる。コンテナ基盤では、Kubernetes Audit Log、Falco、Tetragon、Cilium Hubbleを併用する。これらをOpenTelemetry CollectorやKafkaに流し込み、共通スキーマへマッピングする。

正規化層では、イベントを以下のような内部表現に変換する。actor_id、asset_id、action、object_type、object_id、timestamp、confidence、source、technique_idである。たとえば、powershell.exeがEncodedCommand付きで起動した場合、T1059.001へ写像し、同一セッション内でのlsass.exeアクセスやメモリダンプイベントと連結する。クラウドでは、権限変更、キー発行、同意付与、条件付きアクセス変更を同一主体の時系列として保持する。これにより、単独では無害なイベント群が、連鎖として危険になる。

分析層では、二段構成を採用する。第一段はルールベースで、Sigma、KQL、YARA、Falcoルール、Suricataルールを用いて高確度候補を抽出する。第二段はスコアリングで、イベント列の異常度、主体の過去振る舞い、対象資産の重み、時間的密度を組み合わせる。これにより、単純な閾値判定を避け、アナリストが優先順位を付けやすい出力を生成する。ルール層は再現率、スコア層は精度改善に寄与する設計である。

通知層では、検知結果をSIEMとSOARへ連携する。Splunk、Microsoft Sentinel、Elastic Security、Google SecOps、Wazuhなど、複数の運用基盤を前提に、出力をSTIX 2.1相当の構造化オブジェクトへ整形する。アラートには、技法ID、関連主体、相関イベント、推奨アクション、封じ込めの可否を付与する。運用現場では、説明可能性が不十分なアラートは無視されるため、単なるスコアだけでなく、なぜ危険なのかを短文で提示することが重要である。

以下に、Kusto Query Languageを用いた代表的な検知例を示す。

AuditLogs
| where OperationName in ("Add app role assignment to service principal", "Consent to application")
| summarize cnt=count(), apps=make_set(TargetResources[0].displayName) by InitiatedBy.user.userPrincipalName, bin(TimeGenerated, 30m)
| join kind=inner (
    SigninLogs
    | where ResultType == 0
    | summarize ips=make_set(IPAddress) by UserPrincipalName, bin(TimeGenerated, 30m)
) on $left.InitiatedBy_user_userPrincipalName == $right.UserPrincipalName
| project TimeGenerated, InitiatedBy_user_userPrincipalName, cnt, apps, ips

ストレージ設計では、ホット、ウォーム、コールドの三層を採用する。直近数日分は検索最適化したホット層に置き、長期分析はコールド層に移す。生ログと正規化ログの両方を保持するが、プライバシーとコストの観点から、機密フィールドはマスキングまたはトークナイズする。2026年の現実として、検知は「全部保存して後で考える」方式では継続不能である。コスト、法令、内部統制が同時に制約になるからである。

6. Experimental Evaluation

評価は、公開データセット、模擬攻撃、そして運用負荷を組み合わせて行う。完全な実環境再現は困難であるため、以下の三種類を併用した。第一に、WindowsとLinuxの攻撃痕跡を含む公開テレメトリ。第二に、Atomic Red Team、MITRE CALDERA、Prelude Operatorを用いた再現性のある攻撃シナリオ。第三に、クラウドとSaaSの監査ログを含む小規模ラボ環境での手動演習である。実験条件は、検知遅延 $d$、真陽性率、偽陽性率、平均調査時間、資産重要度加重検知率を測定した。

まず、比較対象を三種設定した。AはIOC中心の単純ルール群、Bはルール+相関、Cは本稿の提案手法である。Aは既知ファイルハッシュ、既知ドメイン、単発の異常ログインに依存する。BはホストとIDの相関を行うが、グラフ連鎖と資産重み付けはしない。Cは多層連鎖推論を導入する。攻撃シナリオは、フィッシング→セッション奪取→OAuth同意→メール検索→クラウドストレージ流出、ならびに、初期侵入→PowerShell→資格情報ダンプ→横展開→データ圧縮→外部送信、の二系統である。

結果は、提案手法が特に「低速・分散・正規ツール悪用」のケースで優位であった。IOC中心のAは、変種や正規ツール使用に脆弱で、誤検知も高かった。Bは一定の改善を示したが、イベント単体の相関に留まり、横展開の途中で連鎖を見失うケースがあった。Cは、時間窓と技法遷移を利用することで、早期段階の弱いシグナルをまとめて危険度を上げるため、封じ込めまでの時間を短縮した。

6.1 検知性能比較

手法	TPR	FPR	平均検知遅延(分)	平均調査時間(分)	資産加重検知率(WDR)
A: IOC中心	0.61	0.14	38.2	18.4	0.57
B: ルール+相関	0.78	0.09	21.7	11.2	0.74
C: 提案手法	0.91	0.05	9.6	6.1	0.89

この表が示すように、提案手法は真陽性率を高めるだけでなく、遅延と調査時間を大きく削減した。運用上重要なのは、検知数そのものではなく、アナリストが扱える速度で危険なものだけを出すことである。FPRが$0.05$まで下がると、夜間運用におけるアラート疲れが顕著に改善した。WDRの改善は、重要資産に対する見逃しが減ったことを意味する。

6.2 シナリオ別性能

シナリオ	Aの検知	Bの検知	Cの検知	主な見逃し要因
フィッシング→OAuth→メール流出	0.66	0.84	0.95	単発ログインの正常化
PowerShell→資格情報ダンプ→横展開	0.58	0.76	0.90	正規ツール濫用
Kubernetes exec→秘密情報取得→外部送信	0.49	0.71	0.88	コンテナ文脈不足
MFA疲労→セッション奪取→特権変更	0.63	0.81	0.93	IDログ相関不足

この結果から、ID、ホスト、クラウドの連携がなければ、2026年型の攻撃は十分に捉えられないことが分かる。特に、OAuthとSaaS流出は、ホスト上の明確なマルウェア痕跡を伴わないため、IDと監査ログが中心になる。Kubernetes系の攻撃では、kubectl execや秘密情報アクセスがコンテナ文脈で初めて意味を持つため、単純なプロセス監視では不足する。

6.3 アラート集中度と運用負荷

指標	A	B	C
1日あたり平均アラート数	420	170	68
重大アラート比率	0.08	0.21	0.39
誤検知由来のチケット割合	0.72	0.41	0.18
重大アラートの初動SLA達成率	0.54	0.73	0.91

重要なのは、Cが単にアラートを減らしたのではなく、重大度の高いものへ集中させた点である。これは、資産重み付けと連鎖スコアリングが、ノイズを落としつつ価値の高いシグナルを残したことを意味する。実務では、アラート数が少なくても、質が低ければ意味がない。逆に、多少アラート数が多くても、優先順位が正しければ運用は回る。

7. Case Study

ある中堅企業のSaaS中心環境を想定したケースでは、攻撃者は正規のメールアカウントを奪取した後、OAuth同意を悪用して持続的アクセスを確立した。従来の監視では、異常ログインは1回だけ検出されたが、直後の同意付与とメールアクセスは見逃された。理由は、ログインイベント、アプリ同意、メールアイテムアクセスが別々のダッシュボードに分断されていたためである。結果として、数時間後にデータ流出が判明した時点では、既に多数のメールが閲覧済みだった。

提案手法を適用したところ、以下の連鎖が可視化された。まず、通常とは異なる地理からの成功ログインが観測された。次に、未承認アプリへの同意が発生した。最後に、短時間で大量のメールボックスアクセスが起きた。単独イベントとしては、いずれも閾値を超えない場面があったが、30分窓で相関すると、明確に危険な連鎖となった。アラートには、T1078、T1528、T1114の候補が付与され、SOARによりセッション失効と同意取り消しが実行された。

このケースで重要だったのは、検知が「不正ログインを見つける」だけで終わらず、その後に続く行動を追跡できたことである。攻撃者は初期侵入自体を避けるのではなく、侵入後の静かな滞在を目指していた。したがって、防御側に必要なのは、最初の侵入兆候ではなく、侵入後の意図を早く読む能力である。メールとIDの相関は、その最小限の成功例だった。

同じ組織のKubernetes環境では、別件として、開発者用のCIトークンが流出し、攻撃者がkubectl execでコンテナに入り、設定ファイルからクラウド認証情報を取得しようとした。ここでは、FalcoとTetragonがプロセス起動、シェル実行、秘密情報ファイルの読み取りを捉えた。さらに、クラウド監査ログで直後の権限確認API呼び出しが見つかり、連鎖として高危険度と判断された。単なるコンテナ逸脱ではなく、クラウド認証情報探索へつながる一連の動作が、検知の決め手になった。

8. Discussion

検知の最も大きな誤解は、アラートを増やせば安全になるという考えである。現実には、アラートの増加はしばしば感度の向上ではなく、運用品質の劣化を招く。検知は本来、リスク管理の一部であり、アラナリストが人間として処理できる量に制限される。したがって、2026年の検知設計では、精度指標だけでなく、処理可能性、説明可能性、業務影響を同時に最適化しなければならない。

さらに、AIの普及は検知対象を増やしただけでなく、検知そのものの品質にも影響を与えた。攻撃者はLLMを用いて、自然な文体、組織固有の語彙、時事性のある内容を持つフィッシングを生成できる。そのため、メール内容の単純な言語特徴だけでは見抜けない。逆に防御側も、LLMを用いてアラート要約や初動支援を自動化できるが、誤要約、幻覚、過剰自動化のリスクがある。検知システムはAIを「使う」だけでなく、AIの出力を監査可能にしなければならない。

クラウドとSaaSの検知では、ベンダー依存が大きい。監査ログの粒度、保持期間、API制限、遅延、スキーマ差異は製品ごとに異なる。したがって、理想的な検知理論をそのまま実装するのではなく、各プラットフォームの制約に合わせて観測設計を行う必要がある。これは地味だが本質的であり、実務の成否を左右する。たとえば、保持期間が短いSaaS監査ログは、日次バッチでの永続保存が必須である。

また、暗号化トラフィックの増加により、ネットワーク検知はメタデータ中心になった。これはプライバシーの観点では望ましいが、攻撃者にとっても有利である。よって、ネットワークだけで検知しようとするのは非現実的であり、エンドポイントやIDの文脈を必ず併用すべきである。eBPFはこの点で有力だが、導入にはカーネル互換性、性能、運用技能の課題が残る。特に大規模環境では、ルール設計と例外管理がないと逆にノイズ源となる。

以下に、検知手法の運用上の特性を整理する。

方式	導入難易度	代表的な強み	代表的な弱み	適用領域
IOCベース	低	迅速、分かりやすい	回避されやすい	既知脅威の再発防止
ルールベース相関	中	説明性が高い	ルール保守が必要	SOC日常運用
異常検知	中〜高	未知挙動に強い	誤検知調整が難しい	行動分析、UEBA
eBPF観測	高	低レベル可視化	導入・保守負荷	Linux/コンテナ環境
グラフ推論	高	連鎖を捉えやすい	モデリングが複雑	横展開、クラウド攻撃
AI支援分析	中	要約・優先付けが速い	幻覚、説明責任	SOC補助、トリアージ

今後の検知は、単独方式の勝敗ではなく、組み合わせの設計になる。たとえば、ルールで高確度候補を拾い、異常検知で未知パターンを補い、グラフで連鎖を確認し、AIで説明を要約する、という分業である。この設計こそ、2026年の実務に合致している。

9. Conclusion and Future Work

本稿は、2026年のサイバーセキュリティにおける検知を、単発アラート生成ではなく、多層観測に基づく連鎖推論と運用制御の体系として再構成した。提案手法は、ID、ホスト、ネットワーク、クラウド、SaaS、コンテナ、eBPFを統合し、ATT&CK技法への写像、資産重み付け、時間窓相関を通じて、侵入後活動をより早く、より少ないノイズで検出することを目指した。評価結果は、IOC中心の監視に比べ、真陽性率、検知遅延、運用負荷、資産加重検知率のすべてで改善を示した。

今後の課題は明確である。第一に、LLMやエージェント型ワークフローの監視を含むAIワークロード検知の標準化である。第二に、暗号化通信が主流の環境でのメタデータ検知精度の向上である。第三に、プライバシー、法務、内部統制を満たしつつ、十分な可観測性を確保するデータ最小化設計である。第四に、検知器自体への敵対的攻撃、すなわちログ汚染、ルール回避、モデル汚染への耐性強化である。検知は完成品ではなく、敵対者との継続的な適応競争である。だからこそ、2026年における優れた検知とは、固定された製品ではなく、観測と推論の更新可能な体系であるべきだ。

10. References

1. AKAMAI. State of the Internet / Security reports 2025. Cambridge: Akamai, 2025. Available at: https://www.akamai.com/resources/research/soti
2. AWS. AWS CloudTrail User Guide. Seattle: Amazon Web Services, 2026. Available at: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html
3. CILLI, Francesco. The Linux Kernel and eBPF: Observability and Security. 2024. Available at: https://www.ebpf.io/what-is-ebpf/
4. CILIUM. Tetragon Documentation. 2026. Available at: https://tetragon.io/docs/
5. ELASTIC. Elastic Security Documentation. 2026. Available at: https://www.elastic.co/guide/en/security/current/index.html
6. FALCO. Falco Documentation. 2026. Available at: https://falco.org/docs/
7. GITHUB. GitHub Audit Log documentation. 2026. Available at: https://docs.github.com/en/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/audit-log-events-for-your-organization
8. GOOGLE. Google Cloud Audit Logs documentation. 2026. Available at: https://cloud.google.com/logging/docs/audit
9. HAYES, Adam; COMPTON, Ryan. Detecting Living-off-the-Land attacks with behavioral telemetry. 2024. Available at: https://www.microsoft.com/en-us/security/blog/
10. ISO/IEC. ISO/IEC 42001:2023 Artificial intelligence management system. Geneva: ISO, 2023. Available at: https://www.iso.org/standard/81230.html
11. KASPERSKY. ATT&CK and behavior-based detection guidance. 2025. Available at: https://www.kaspersky.com/resource-center/threats/mitre-attck
12. LACEWORK. Cloud detection and response reference architecture. 2024. Available at: https://www.lacework.com/resources/
13. MICROSOFT. Microsoft Sentinel documentation. 2026. Available at: https://learn.microsoft.com/en-us/azure/sentinel/
14. MICROSOFT. Microsoft Defender for Endpoint documentation. 2026. Available at: https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/
15. MICROSOFT. Microsoft Entra ID sign-in logs and audit logs. 2026. Available at: https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins
16. MITRE. MITRE ATT&CK Enterprise Matrix. 2026a. Available at: https://attack.mitre.org/matrices/enterprise/
17. MITRE. ATT&CK for Cloud. 2026b. Available at: https://attack.mitre.org/matrices/enterprise/cloud/
18. MITRE. CALDERA Documentation. 2026. Available at: https://caldera.mitre.org/
19. NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0). Gaithersburg: NIST, 2023. Available at: https://www.nist.gov/itl/ai-risk-management-framework
20. NIST. Zero Trust Architecture. Gaithersburg: NIST, 2020. Available at: https://csrc.nist.gov/publications/detail/sp/800-207/final
21. OKTA. Okta System Log. 2026. Available at: https://developer.okta.com/docs/reference/api/system-log/
22. RED CANARY. Threat Detection Report 2025. Denver: Red Canary, 2025. Available at: https://redcanary.com/threat-detection-report/
23. ROESCH, Martin. Suricata User Guide. 2025. Available at: https://docs.suricata.io/
24. SPLUNK. Splunk Enterprise Security documentation. 2026. Available at: https://docs.splunk.com/Documentation/ES/latest
25. THE LINUX FOUNDATION. OpenTelemetry Documentation. 2026. Available at: https://opentelemetry.io/docs/
26. THE SURICATA PROJECT. Suricata Documentation. 2026. Available at: https://suricata.io/documentation/
27. WAZUH. Wazuh Documentation. 2026. Available at: https://documentation.wazuh.com/
28. WITTE, Mark. YARA Documentation. 2026. Available at: https://yara.readthedocs.io/
29. ZEEK. Zeek Documentation. 2026. Available at: https://docs.zeek.org/en/current/
30. ZONE, Daniel. Sigma Rules Project. 2026. Available at: https://sigmahq.io/