Crow-Eye — Windows フォレンジックエンジン

Windows のためのフォレンジックタイムマシン。
Crow-Eyeは単に検出するだけではありません — タイムライン上で実際に何が起こったのかを再構築し、取得からソースレコードまで追跡可能な判定結果までを一貫して提供します。

目次

• 概要
• ✨ 主な特長
• 👥 Crow-Eyeの対象ユーザー
• 🧭 サブシステム概要
• 🏗️ アーキテクチャ
• 📥 ダウンロードとインストール
• 🚀 クイックスタート
• 📂 対応アーティファクト
• 🔧 分析モード
  • 📎 証拠のインポート（サードパーティデータ）
• 🧠 ユーザー行動分析（UBA）
• 🧩 相関エンジン
• 👁️ Eye — フォレンジックAIアシスタント
• 📖 Eye-Describe — バイトレベルのアーティファクト知識ベース
• 🧪 品質と検証
• 🔬 研究プラットフォーム
• 🛠️ 技術ノート
• 📸 スクリーンショット
• 🚧 ロードマップ
• 📚 ドキュメント
• 🤝 コントリビューション
• 🌐 ウェブサイトとコミュニティ
• 📄 ライセンス
• 📝 Crow-Eyeの引用
• 💖 サポート
• クレジット

概要

Crow-Eyeは、取得、分析、検証、インテリジェンス、AIを統合したオープンソース（GPL-3.0）のWindowsフォレンジックエンジンです。 ほとんどのセキュリティツールは*「これは悪質か？」と問い、正常に見えるものをすべて除外します。Crow-Eyeは異なる問いを投げかけます：「何が起こったのか？」 疑わしいかどうかに関わらずすべてのアクティビティを相関させ、システム上で実際に発生した一連のイベントを再構築するため、調査の真実はアラートからの推測ではなく証拠から再構築*されます。

この再構築優先の設計こそが、APTや国家支援型の脅威をハンティングするために必要なものです：高度な敵対者は正当なツール（powershell.exe、PsExec、certutil）や、正常に見えるものを除外するツールには見えない一連のアクションの中に潜んでいます。Crow-Eyeは何も除外せず、実行アーティファクト（ログ改ざんやアンチフォレンジックに耐性がある）に基づいて推論するため、攻撃は隠れることができません。同じエンジンは、日常的なDFIR業務や、コンピュータで何が起こったのかを知りたいだけの非専門家にとっても使いやすい設計です。

• 🕰️ 検出だけでなく再構築 — 実際に発生した出来事のタイムラインを再構築します。
• 🖥️ クロスプラットフォーム — Windowsでは完全なライブ＋オフライン分析をサポート。Linuxではオフライン分析とフォレンジックイメージの解析をサポート（ライブパーサーはWindowsのみ）。
• 🔒 設計上のプライバシー保護 — デバイス外に送信されるデータは0ミリ秒。Eye AIアシスタントは完全にエアギャップ環境で実行可能。
• 🧾 法廷グレード — 証拠は暗号学的に封印され、すべてのステップが監査可能です。
• 📦 現在のバージョン: 0.13.0 · 相関エンジン: 1.7.0 · ライセンス: GPL-3.0。

✨ 主な特長

• 検出よりも再構築。 すべてのアーティファクトを相関させ、アラートの山ではなく、エンティティごとのナビゲート可能なストーリーに統合します。
• エンドツーエンドの統合 — 取得 → 相関 → タイムライン → 行動分析 → AI → 封印されたケースメモリ：既存のどのツールもカバーしていない完全なパイプラインです。
• ログの浅さではなく、アーティファクトの深さ。 Prefetch、Amcache、ShimCache、SRUM、MFT、USN、LNK/ジャンプリストなどは、ログのみのツールを盲目にするログ消去や「living-off-the-land」の手口にも耐性があります。
• Eye AIアシスタント — 監査可能で改ざん防止のチェーン・オブ・カストディを備えた自然言語によるフォレンジック調査。クラウド、プライベートサーバー、または完全にオフラインで実行可能。
• ユーザー行動分析（UBA） — 生のアーティファクトを、人事担当者や検査官が読める平易な英語のアクティビティストーリーに変換します。
• 無料＆オープンソース（GPL-3.0） — 誰でも監査可能で、活発な研究とドキュメント作成の取り組みがあります。

👥 Crow-Eyeの対象ユーザー

Crow-Eyeは非常に異なるワークフローで使用されます。それぞれが異なる入口からエンジンに入ります：

どのコレクターでも機能します。 Crow-Eyeは独自の取得ツールを必要としません。オフラインインポーターをVelociraptor、KAPE、EDR収集パッケージ、またはその他のコレクターが生成した生のアーティファクトのフォルダに向けるだけで、サポートされているアーティファクトをインデックス化し、それらに対してオフラインパーサーを実行します。さらに、Plaso、Autopsy、Volatility、またはその他のツールからの出力は、Import Evidenceを介してCSV、JSON、またはSQLiteとして取り込み、ネイティブアーティファクトと並行して相関させることができます。

🧭 サブシステム概要

Crow-Eyeは統合ループとして構築されています — 各ステージが次のステージに供給され、生のディスクから防御可能な判定結果までを一貫して処理します。

🏗️ アーキテクチャ

Crow-Eyeはパーサーの寄せ集めではなく、統合パイプラインです。証拠は一方向に流れ、すべてのステージはソースレコードへのリンクを保持します。```mermaid %%{init: {"flowchart": {"nodeSpacing": 60, "rankSpacing": 70, "curve": "basis"}, "themeVariables": {"fontSize": "17px", "fontFamily": "system-ui, sans-serif"}} }%% flowchart TB

%% ═══════════ 1. EVIDENCE SOURCE ═══════════ S1["Live Windows system"] S2["Forensic image
E01 · VHDX · VMDK · Raw"] S3["Collected artifacts
Velociraptor · KAPE · EDR"] S4["Third-party output
Plaso · Autopsy · Volatility"]

%% ═══════════ 2. INGEST ═══════════ I1["CROW-CLAW
live acquisition"] I2["IMAGE PARSING
direct, no mounting"] I3["OFFLINE IMPORTER
SCAN → COLLECT → PARSE"] I4["IMPORT EVIDENCE
CSV · JSON · SQLite"]

REPLAY["DIRTY-HIVE REPLAY<br/>transaction logs applied to a working copy"]
PARSERS["ARTIFACT PARSERS<br/>18 artifact types · live and offline"]

%% ═══════════ 3. CASE ═══════════ CASE[("CASE DATABASES
Target_Artifacts/
Imported_Evidence/")]

%% ═══════════ 4. ANALYSIS ═══════════ TL["INTERACTIVE TIMELINE
heat map · week · day"] UB["USER BEHAVIOR ANALYTICS
40 detections · plain-English story"] CE["CORRELATION ENGINE
Feathers → Wings → Engines → Pipelines"] RES[("Correlation results")] DL["DYNAMIC LINKING
non-destructive enrichment overlay"] INTEL[("Crow_Intelligence.db
SID · MAC · hash · GUID → name")]

%% ═══════════ 5. AI LAYER ═══════════ EYE["EYE
GEP-governed AI assistant"] NM["NARRATIVE MAP
hash-chained case memory"] COMP["COMPLIANCE
live GEP status · EvidenceSeal audit"]

OUT["LIVING REPORT<br/>CSV · JSON · HTML"]

%% ═══════════ FLOW ═══════════ S1 --> I1 S2 --> I2 S3 --> I3 S4 --> I4

I1 --> PARSERS
I2 --> PARSERS
I3 --> PARSERS

PARSERS -- "every registry hive,<br/>evidence never written to" --> REPLAY
REPLAY -- "the state Windows<br/>had not finished writing" --> PARSERS

PARSERS -- "parsed artifacts" --> CASE
I4 -- "verbatim copy or<br/>converted to feather" --> CASE

CASE -- "read-only" --> TL
CASE -- "read-only" --> UB
CASE -- "read-only" --> CE
CASE -- "read-only" --> DL
CE --> RES
DL --> INTEL

CASE -- "read-only queries" --> EYE
RES -. "queried on demand" .-> EYE
EYE <== "verdict · narrative · evidence" ==> NM

EYE -- "audited by" --> COMP

EYE -- "report_* tools" --> OUT

%% ═══════════ STYLE ═══════════ classDef src fill:#334155,stroke:#94a3b8,stroke-width:2px,color:#f1f5f9 classDef ing fill:#0f766e,stroke:#2dd4bf,stroke-width:2px,color:#f0fdfa classDef store fill:#92400e,stroke:#fbbf24,stroke-width:3px,color:#fffbeb classDef ana fill:#1e40af,stroke:#60a5fa,stroke-width:2px,color:#eff6ff classDef ai fill:#6b21a8,stroke:#c084fc,stroke-width:2px,color:#faf5ff classDef out fill:#166534,stroke:#4ade80,stroke-width:2px,color:#f0fdf4

class S1,S2,S3,S4 src
class I1,I2,I3,I4,PARSERS ing
class CASE,RES,INTEL store
class TL,UB,CE,DL ana
class EYE,NM,COMP ai
class OUT out

linkStyle default stroke-width:2px

*証拠ソース → 取り込み → ケースデータベース → 分析 → AIレイヤー → レポート*


**読み方:**

| ステージ | 重要なポイント |
|---|---|
| ① → ② | **ケースへの4つの独立した入り口。** Crow-Eye独自のコレクターは不要 — Velociraptor、KAPE、またはEDRパッケージからのフォルダはオフラインインポーターを経由し、サードパーティ製のCSV/JSON/SQLiteはImport Evidenceを経由します。 |
| ② → ③ | すべてが1つの場所に集約されます: **ケースデータベース**。解析されたアーティファクトは`Target_Artifacts/`に格納され、インポートされたサードパーティ製の証拠は`Imported_Evidence/`に格納され、自動検出されます。 |
| ③ → ④ | **3つの分析パスは互いに独立しています。** タイムラインとUBAはケースデータベースを直接読み取ります — どちらも相関実行を必要としません。相関エンジンは*追加の*レイヤーであり、前提条件ではありません。 |
| ③ → ④ | **動的リンクはタイムラインおよびUBAと並んで配置されます** — ケースデータベースの4つ目の独立したリーダーです(タイムラインの可視化とは無関係です)。IDマッピング(SID → ユーザー名、MAC → ネットワーク、ハッシュ/GUID → アプリ)をケースごとの`Crow_Intelligence.db`に収集し、そのコンテキストを非破壊的な`ATTACH` + `LEFT JOIN`を介して**アーティファクトデータテーブルにインラインで**重ね合わせます。レコードの*読み方*を変えるだけで、証拠自体は変更しません。 |
| ④ → ⑤ | Eyeはケースデータベースを直接クエリし、相関結果を**オンデマンドで**取得できます。証拠自体には一切触れず、Crow-Eyeが実行してログに記録するツールコールを発行します。 |
| ⑤ → レポート | **Living ReportはEye単独で構築され**、その`report_*`ツールを通じて行われます。タイムラインとUBAは分析サーフェスであり、レポートには書き込みません。ケースレベルの調査結果は、[検索とエクスポート](#-search--export)を介して個別にエクスポートできます。 |
| ⑤ ↔ | **ナラティブマップは双方向です**: Eyeが書き込み、ユーザーも書き込み、その内容は毎ターンEyeのプロンプトに注入されます。これはメモリであり、ユーザーが操作できます。 |
| ⑤ ⟳ | **コンプライアンスページはEyeを監査します。** Eyeが行うすべてのツールコールは**EvidenceSeal**ハッシュチェーンに固定され、ページはそのチェーンと`EYE_Logs/`から検証されたルールごとのライブ**GEP**ステータス(10原則)をレンダリングし、`audit_trail.json`としてエクスポートできます。 |

**独立したステージ。** タイムラインとUBAはケースのアーティファクトデータベースを**直接**読み取ります — どちらも相関実行を必要とせず、タイムラインは相関エンジンに依存しません(独自の軽量な時間的グループ化を適用します)。相関は追加の分析レイヤーであり、その結果をEyeがクエリできます。

**設計上読み取り専用。** 解析はケースデータベースに書き込みます。後続のすべてのステージ(UBA、タイムライン、相関ビューアー、Eye)はそれらのデータベースを**読み取り専用で**開きます。元の証拠は決して変更されません — [動的リンク](#-analysis-modes)はケースデータベースを読み取ってIDマッピングのケースごとの`Crow_Intelligence.db`を構築し、行を書き換えるのではなく非破壊的な`ATTACH` + `LEFT JOIN`クエリを介してアーティファクトデータテーブルをインラインで強化します。

**設計上ガバナンス。** Eyeが行うすべてのアクションは、改ざん防止の**EvidenceSeal**ハッシュチェーンに固定され、**コンプライアンス**ページは[Ghassan Elsman Protocol (GEP)](https://github.com/ghassan-elsman/crow-eye/blob/main/eye/docs/GEP_standard.md)に対してEyeを継続的に検証します — ルールごとのライブステータス、`EYE_Logs/audit_trail.json`にエクスポート可能です。

## 📥 ダウンロードとインストール

> **推奨:** 公式ウェブサイトからパッケージ化されたWindowsビルド(**MSIインストーラー / EXE**)を入手してください — Pythonのセットアップ不要で、すぐに実行できます。

### ▶️ [Crow-Eye for Windowsをダウンロード → crow-eye.com/download](https://crow-eye.com/download)

**インストールされたMSI/EXEビルドはCrow-Eyeを実行する推奨方法であり**、**アップデートの最優先事項**です:

- 🛡️ **最速の修正。** 問題が見つかったりバグが報告されたりすると、できるだけ早く更新されたEXEをリリースします — パッケージ化されたビルドが最初に修正が適用される場所です。
- 🔄 **内蔵の自動アップデート。** インストールされたアプリで、**設定 → アップデート**を開いて**アップデートを確認し、自動的にインストール**します — 手動での再インストールは不要です。
- 📦 **セットアップ不要。** Python、Node、依存関係のインストールは不要です。

> ソースから実行したいですか? 以下の**[クイックスタート](#-quick-start)**を参照してください。ソースからのビルドはコントリビューター向けであり、**自動アップデーターは含まれていません** — 自動アップデートにはMSI/EXEを使用してください。

## 🚀 クイックスタート

### オプションA — インストールされたビルド(推奨)
[crow-eye.com/download](https://crow-eye.com/download)から**MSI/EXE**をダウンロードし、インストールして、**Crow-Eye**を管理者として起動します。ケースを作成して分析を開始します。

### オプションB — ソースから実行(開発者向け)

> コントリビューターおよび上級ユーザー向け。このパスには**自動アップデーターは含まれていません** — 自動アップデートにはMSI/EXEを使用してください。

**要件**(初回実行時に自動インストールされます):
- Python 3.12.4
- **Node.js & npm** — **タイムラインの可視化**に必要
- 主要パッケージ: PyQt5、python-registry、pywin32、pandas、streamlit、altair、olefile、windowsprefetch、sqlite3、colorama、setuptools

**推奨ハードウェア**

| | 最小 | 大規模ケースの推奨 |
|---|---|---|
| **RAM** | 8 GB | 16 GB以上(MFT/USNセットが数百万レコードの場合) |
| **ディスク** | 5 GBの空き容量 | 解析対象の証拠サイズの2倍以上の空き容量 |
| **CPU** | 4コア | 8コア以上 |
| **OS** | Windows 10/11(フル) · Linux(オフラインおよびイメージ分析) | — |

> 相関処理は非常に大規模なデータセットでも一定メモリでストリーミングされるため、RAMがハードリミットになることはほとんどありません — 通常はディスクのスループットと空き容量が制約になります。

**起動**(Crow-Eyeがシステムアーティファクトにアクセスできるように管理者として実行):```bash
python "Crow Eye.py"

メインインターフェースが開き、ケースを作成すると、すべての分析出力がそのケースディレクトリの下に整理され、後でレビューやレポート作成に使用できます。

🖥️ クロスプラットフォームに関する注意: Linuxでは、ライブパーサーは自動的に無効化され、Crow-Eyeはオフライン / フォレンジックイメージモードで動作します。完全なライブ取得はWindowsのみ対応です。

📂 対応アーティファクト

Crow-Eyeは、ライブシステムとオフラインソース（収集済みフォルダまたはフォレンジックイメージ）の両方から、Windowsの実行、ファイルシステム、ユーザーアクティビティに関する幅広いアーティファクトを解析します。

ジャンプリストとLNKは、Crow-Eye独自の専用設計のLNK / ジャンプリストパーサーによって解析されます — サードパーティ製モジュールではありません。

カスタムレジストリ / ロックされたファイル: Windowsは動作中にライブレジストリハイブ（NTUSER.DAT、SOFTWARE、SYSTEM）をロックします。ライブシステムのカスタム分析には、外部メディア（WinPE/Live CD）から起動するか、フォレンジック取得ツールを使用するか、ディスクイメージを分析してください。

アーティファクト別の詳細

• ジャンプリストとLNK — Crow-Eye独自の専用パーサーにより、標準的なシステム場所から自動的に解析されます（ファイルアクセス、ターゲットパス、タイムスタンプ、メタデータ）。
• レジストリ — システムハイブを自動的に解析します。カスタムレジストリ分析の場合は、ハイブファイルをCrowEye/Artifacts Collectors/Target Artifacts（またはケースのregistry/フォルダ）にコピーします:
  • C:\Users\<Username>\NTUSER.DATからNTUSER.DAT
  • C:\Windows\System32\config\SOFTWAREからSOFTWARE
  • C:\Windows\System32\config\SYSTEMからSYSTEM
  • Windowsは動作中にこれらをロックします — ライブシステムの場合は、外部メディア（WinPE/Live CD）から起動するか、フォレンジック取得ツールを使用するか、ディスクイメージを分析してください。
• Prefetch — C:\Windows\Prefetchを解析し、実行履歴とフォレンジックメタデータ（実行ごとのタイムスタンプを含む）を抽出します。
• イベントログ — System/Security/Applicationログをデータベースに自動解析し、包括的な分析を実現します。
• レジストリの深さ（0.13.0） — パーサーはライブレジストリだけでなくハイブファイルも読み取るため、winregが管理者でさえ拒否する場所（すべてのデバイスPropertiesサブキー、およびそれに伴うUSB接続時刻）に到達し、ハイブのアロケータを走査して削除されたキーと値を復元し、クラス名とキーセキュリティ記述子を読み取ります。実際のデータを保持し、何にも読み取られていなかった19個のキーが現在解析されます — ExplorerのStartupApprovedを含みます。これは各自動起動エントリが実際に起動を許可されているかどうかを示します。
• ShellBags — フォルダアクセス履歴とユーザーのナビゲーションパターンを明らかにします。
• ごみ箱 — $RECYCLE.BINを解析し、削除されたファイル名、元のパス、削除時刻、サイズを復元します（ライブシステムとディスクイメージ）。
• MFT — マスターファイルテーブルを解析し、ファイルメタデータ、属性、タイムスタンプ、削除されたファイル情報を取得します（NTFS、Windows 7/10/11）。
• USNジャーナル — タイムスタンプと完全な名前履歴を含むファイルの作成/変更/削除/名前変更イベントを追跡し、タイムライン再構築に使用します。
• SRUM — アプリのリソース使用量（フォアグラウンド/バックグラウンド時間の期間バー）とアプリごとのネットワークアクティビティを視覚化します。
• ストレージフォレンジックスアナライザー — すべての物理ディスクとそのパーティションの完全なツリービュー。色分けされたパーティションタイプ（EFI、Linux、リカバリ、隠し/スワップなど）。起動可能なUSB、隠しLinuxルート、Intel Rapid Startに関する警告。生セクタのマジックスキャンによるフォールバック。

🔧 分析モード

🦅 Crow-Claw取得

Crow-Clawは、ライブシステムまたはマウントされたイメージからアーティファクトを収集・保存するためのCrow-Eyeの専用取得エンジンです。

• 選択的収集 — 特定のアーティファクトカテゴリ（レジストリ、イベントログ、ファイルシステム）を選択するか、すべてを収集します。
• ディープスキャン — ディレクトリとサブディレクトリを走査してフォレンジックトレースを検出します。
• 安全な保存 — アーティファクトは、フォレンジックの整合性を維持する構造化されたケースディレクトリに配置されます。

🔍 オフライン分析（オフラインインポーター）

ターゲットへのライブ接続なしで、任意のソースから収集されたアーティファクトを分析します — 3つの明確な操作:

• SCAN（検出） — ソースを走査し、ファイル名と拡張子パターンによってサポートされているすべてのアーティファクトをインデックス化します（高速、読み取り専用。この段階ではファイル内容は読み取られず、マジックバイトチェックも実行されません）。何も移動されません。
• COLLECT（取得） — 特定されたファイルをタイプ別に整理して、ケースのlive_acquisitionフォルダに物理的にコピーします。
• PARSE（詳細） — タイプ別（AMCACHE、EVTX、PREFETCHなど）に特定された項目をレビューし、選択したファイル（またはすべて）をフォレンジックデータベースに解析します。

解析はCrow-Eyeの専用オフラインパーサーによって処理されます — ライブモードと同じアーティファクトロジックで、収集されたファイルに対して動作します: Prefetch、レジストリ、MFT、USN（MFT/USNコリレーターを含む）、AmCache、ShimCache、SRUM、イベントログ、LNK/ジャンプリスト、ごみ箱。

📎 証拠のインポート（サードパーティデータ）

生のアーティファクトに加えて、Crow-Eyeはサードパーティのフォレンジック出力を直接ケースに取り込むことができます — Plaso、Autopsy、Volatility、または任意のカスタムエクスポート — そして、相関実行を事前に必要とせずに、Eyeとタイムラインで使用可能にします。

ケースデータベースマネージャーがケースツリーの下の任意の.dbを自動検出するため、インポートされた証拠はすぐに以下で利用可能になります:

• The Eye — ネイティブアーティファクトと並んで自然言語でクエリ可能（インポート時にスキーママニフェストが更新されます）。
• インタラクティブタイムライン — importedアーティファクトタイプとして提供され、時間ウィンドウフィルタリングと時間境界が機能します。
• 相関エンジン — ネイティブアーティファクトに対するツール間相関のためのFeatherとして使用可能。

インポーターは標準ライブラリのみ（sqlite3 / csv / json）で、バックグラウンドワーカーで実行されるため、大規模なインポートでもUIをブロックしません。

⚡ ライブ分析

実行中のWindowsシステムから直接アーティファクトを分析し、標準的な場所から自動抽出してリアルタイムのフォレンジック分析を実行します。

🗂️ ケース管理

すべての調査はケースです: アーティファクトデータベースと分析出力を整理する自己完結型のディレクトリです。Crow-Eyeは最近のケースを追跡し（お気に入り、タグ、ステータス付き）、開くときにケースを検証し、設定を原子的に書き込み（クラッシュセーフ）、ケース設定のインポート/エクスポートと、既製のセマンティックマッピングを備えたテンプレートをサポートします。

🕰️ インタラクティブタイムライン可視化

統一された時間グリッド上でアーティファクト間のイベントを相関させ、ヒートマップ、週、日ビューを備えています — フラットなスーパータイムラインではなく、アイデンティティスレッド化された、法廷で追跡可能なストーリーです。

タイムラインはケースの解析済みアーティファクトデータベースを直接読み取り、相関エンジンから独立しています — 使用するためにfeatherを構築したり、wingsを作成したり、パイプラインを実行したりする必要はありません。独自の軽量な時間的グループ化（正確なタイムスタンプと時間ウィンドウの相関、アプリケーション、パス、またはユーザーによるグループ化）を適用して、グリッド上のイベントを関連付けます。証拠のインポートを通じて取り込まれた証拠も、importedアーティファクトタイプとしてタイムラインに表示され、時間ウィンドウフィルタリングと時間境界が機能します。

🔎 検索とエクスポート

ケースデータベース全体の全文検索に加え、CSV（スプレッドシート）、JSON（他のツールとの統合）、詳細なHTMLレポート（検索語に関連するすべてのアーティファクトを統合した完全なドシエ）へのエクスポート。

🔗 動的リンク

SID、MACアドレス、ハッシュなどの生の技術的識別子を、その場で人間が読めるコンテキストに変換します。動的リンクは非破壊的なSQL ATTACHクエリを使用してビューを強化するため、元の証拠が変更されることはなく、バルクIOC脅威フィードを取り込んで既知の悪性インジケータをインラインでフラグ付けできます。

🧠 ユーザー行動分析（UBA）

生のアーティファクトを平易な英語のアクティビティストーリーに変換 — マネージャー/人事が読める、ユーザーとそのアプリケーションが実際に行ったことの説明であり、すべての記述が正確なソース証拠にトレース可能です。

ユーザー行動分析（UBA）は、ケースのTarget_Artifacts/フォルダ内の解析済みアーティファクトデータベースを読み取り（厳密に読み取り専用）、宣言型ルールセットを通じて再生して、明確で時系列のアクティビティストーリーを生成します。**「User Behavior」ツールバーボタンまたはCtrl+Shift+B**から開きます（ケースが読み込まれている必要があります）。

• 🧩 40の宣言型行動検出（uba/config/behavior_rules.json）— コードなしで調整可能 — それぞれが重大度で分類: routine · notable · suspicious · critical。
• 🕵️ 重要な行動を検出: サインイン / サインアウト / ロック解除、プログラム起動 · 実行 · インストール、ファイルオープン / 削除 / 推定コピー、USBデバイス接続、ネットワーク共有アクセス、永続化と自動起動、明示的資格情報の使用（runas）、アカウントとグループの変更、サービスの変更、システムクロック改ざん（suspicious）、イベントログ消去（critical）。
• 🗺️ 3つのビュー — アクティビティストーリーフィード、アクティビティマップヒートマップ（日×時間）、および各検出をこのケースに対してWorking / Limited / No data / By designとラベル付けする**「What we can see」**正直レポート。
• 🔗 すべてのアクティビティは証拠に裏付けられています。 任意の項目をクリックして、正確なバックアップレコード（database : table : rowid）を開きます — ソースなしで主張されるものはありません。
• 👤 正直な帰属。 アクターはUser / Application / Systemに解決されます（または空のまま）— UBAは誰が何をしたかを推測しません。

検出カバレッジ

40の検出は、4つの重大度クラスと解析済みアーティファクトセットの全範囲に及びます:

フィルター: フリーテキスト検索 · ユーザー/アクター（「Unattributed」とサインインセッショントグルを含む） · 行動クラス（user / application / system） · 重大度 · アプリケーション（200以上のプログラムにわたる検索可能なマルチセレクト） · クイックプリセット付きの日時範囲（全期間 / 初日 / 最終日 / アクティビティの最終1時間）。

データソース: Security、System、Applicationイベントログ · USNジャーナル · MFT · UserAssist · BAM · Prefetch · ShimCache · AmCache · MUICache · ShellBags · LNK / ジャンプリスト · ごみ箱 · SRUM（アプリケーション、ネットワーク、接続） · レジストリハイブ。

フォレンジック保証

• 読み取り専用。 ソースデータベースは読み取り専用で開かれ、分析が証拠に触れることはありません。
• 完全な出所。 すべてのイベントはdatabase → table → rowidを保持し、要求に応じて実際のソース行を開きます。
• 帰属は推測しません。 イベントはUser、Application、Systemに帰属されるか、空のままになります。インタラクティブログオンセッションはコンテキストラベル（「<user>のセッション中」）としてのみ使用され、アクションの帰属には使用されません。
• 正直な表現。 表現は意図的な操作（UserAssist、SRUMフォアグラウンド）と、アプリケーションも生成できるアーティファクト（ShellBags、LNK、ジャンプリスト）を区別し、カードに明示的な注意書きが表示されます。
• 不在は明示され、暗示されません。 What we can seeレポートは、この特定のケースに対してすべての検出をラベル付けするため、データの欠落が「何も起こらなかった」と暗黙的に読まれることはありません。

UBAはルール駆動の行動相関と分類であり、統計/ML異常スコアリングではありません — すべての検出は明示的で監査可能なルールにマッピングされます。完全な検出カタログについてはRELEASE_NOTES.mdを参照してください。

🧩 相関エンジン

相関エンジン v1.7.0 — 再構築のコア。リリース履歴についてはRELEASE_NOTES.mdを参照してください。

Crow-Eye相関エンジンは、本番グレードのフォレンジック相関システムです。任意のソースからWindowsアーティファクトを取り込み、正規化し、孤立したレコードをシステム上で何が、いつ、誰が関与して起こったかの一貫した物語に変える時間的およびアイデンティティの関係を表面化します。最も一般的な調査質問に対する組み込みの相関ルール（Wings）をすぐに使用でき、アナリストはコードに触れずにカスタムルールを作成でき、意味の解釈は作成可能なルールと調査者に委ねられます — ブラックボックスのスコアには決して委ねられません。

🎥 ユーザーガイド

ユニバーサルデータインポート: 相関エンジンは、任意のフォレンジックツールからの出力をCSV、JSON、またはSQLite形式で受け取り、Featherデータベースに変換できます。つまり、サードパーティツール（Plaso、Autopsy、Volatilityなど）のデータをCrow-Eyeのネイティブアーティファクトと相関させ、すべてのフォレンジックデータソースにわたる統一された相関分析を作成できます。

🎯 精度と証拠の完全性

0.11.0サイクルからの焦点を絞った精度パスで、実際の約70万レコードのWindowsケースに対してエンドツーエンドで検証され、以前の信頼性向上の上に積み重ねられました。以下のすべての修正はpytest回帰スイートによってロックされ、総合的な検証ハーネスによって検証されています。当時出荷された7つのデフォルトwingsを実行しました — 現在は11が出荷されています。以下に引用するマッチ数は、そのリリースのルールの下で測定されました: 0.13.0はマッチの定義を変更しました（マッチは現在、複数のfeatherにまたがる必要があります）および信頼度スコアの意味も変更したため、これらは現在の数値ではなく、そのパスの記録として扱ってください。

アイデンティティエンジンはすべての証拠を捕捉します

• 修正済み: アイデンティティエンジンは、時間フィルターがアクティブなときにすべてのfeatherの最初の行のみを反復処理していました（タイムゾーン対応と非対応のdatetime比較がTypeErrorを発生させ、行ごとのループを中止しました）。検証ケースでレコード数は3,558 → 745,615に増加しました。
• 修正済み: ログレコードはすべてのイベントをイベントプロバイダーにアイデンティティとして集約していました（33,855件すべてのSecurityLogsレコードが1つのアイデンティティを共有）。アーティファクトごとのマッピングは現在、チャネル/プロバイダーメタデータの前に実際の行ごとのエンティティ（User、ComputerName、NewProcessName、TargetUserName）を優先します。
• 修正済み: アーティファクト認識フィールドマッピングが機能しませんでした — パーサーが各行にartifact列をスタンプしないためです。エンジンは現在feather_metadata.artifact_typeにフォールバックするため、SecurityLogs / SystemLogs / ApplicationLogsはアーティファクト固有のアイデンティティ優先順位を使用します。
• 修正済み: プレースホルダー文字列が偽のアイデンティティになりました（'N/A'、'Unknown'、'-'、nil-GUIDが無関係なレコードをまとめていました）。バリデータは現在30以上のプレースホルダーバリアントを拒否します。
• 当時測定された1つの全範囲ウィンドウでの正味の結果: Execution Proof wingはアイデンティティエンジンで2,856のクロスfeather（High）マッチ、タイムエンジンで643のクロスfeatherマッチを表面化し、そのリリースの他の6つのwings全体でwingあたり24〜118のクロスfeatherマッチがありました。

「すべてがLow — 何かがおかしい」はもうありません

• 修正済み: 単一featherマッチがHighとタグ付けされていました。 feather_count == 1のマッチは現在confidence_category="Low - single feather"を取得するため、Highビューは実際のクロスfeather相関に焦点を当てます。
• 修正済み: パス認識の複合キーが同じアイデンティティをfeather間で分割していました（各featherはパスを異なる方法で保存するため、chromeは10以上のキーを持ち、相関しませんでした）。キーは現在名前のみです — クロスfeather相関が再び機能します。

パス分類によるなりすまし検出 — マッチが形成された後、エンジンはすべてのレコードのパスをTRUSTED（Program Files、System32、WinSxS、BAM/SRUMの/device/harddiskvolumeN/...形式など）またはSUSPICIOUS（Temp、Downloads、Public、AppData\Local\Temp、ごみ箱、リムーバブルルート、ネットワーク共有）として分類します。両方の分類にまたがるマッチはimpersonation_alertを発生させます（約0.05%の割合で、それぞれが実際の候補です）。誠実な証拠の会計処理 — 名前付きバケット（no_identity_field、normalize_failure、below_threshold_skipped、…）を備えたウィンドウ単位のドロップ台帳に加え、パイプライン単位のサマリー（処理レコード数、高/低信頼度の出力数、IDなし件数、ドロップバケット、タイムレスフェザーの結合）を提供します。すべてのレコードはマッチまたは名前付きドロップバケットのいずれかに分類されるため、「残された証拠がない」ことをログから検証できます。low_confidence_review_mode はデフォルトでONになっており、しきい値未満のグループは黙って消えるのではなく、低信頼度マッチになります。

タイムレスフェザーのIDエンリッチメント — 行単位のタイムスタンプを持たないフェザー（AutoStartPrograms、MUICache、SystemServices、TypedPaths）に、生成時刻の偽タイムスタンプを行ごとに付与することはなくなりました。代わりに、時間ベースのマッチが形成された後、エンジンはすべてのタイムレスフェザーからIDによって一致するレコードを補足証拠として結合します。

統合IDレジストリ — config/standard_fields/identities.json は、エンジンとEyeが参照するすべての列の単一の情報源です：98カテゴリ、1,146の列シノニム（アプリ/プロセス、ファイル、ハッシュ、ユーザー、ホスト/デバイス、ネットワーク、レジストリ、サービス/タスク、イベント、メール、ブラウザ、クラウド、Windows内部、証明書、コンテナ、OSオブジェクト）。新しい列シノニムの追加はコード変更ではなくJSON編集です。

セマンティックマッピングの誤検知修正 — 複数インジケータのゲーティングが実際に強制されるようになりました（data-exfiltration-pattern は2つ以上のインジケータを要求）。不可能なANDルール（4625 AND 4624）はORとして書き直されました。ワイパー/リモートツールのルールは、すべてのPrefetchエントリで発火する代わりに実際の正規表現を使用します。ベースラインアクティビティのルールは high/critical から info/low に格下げされました（ウィングの重み付きスコアリングが実際の脅威を増幅します）。

✅ 本番稼働状況

Correlation Engineは本番稼働可能であり、調査で積極的に使用されています（Correlation Engine v1.7.0）：

• ✅ 時間ウィンドウスキャンエンジン — 本番稼働可能、時間ベースの分析に推奨（O(N log N)）
• ✅ IDベースエンジン — 本番稼働可能、ID追跡に推奨（O(N log N)）
• ✅ Feather Builder / FeatherWriter — 任意のツールからCSV/JSON/SQLiteをインポート。トランザクションバッチ処理＋スキーマメタデータ
• ✅ Wingsシステム＆パイプラインオーケストレーション — 相関ルールの作成/管理とワークフローの自動化
• ✅ IDグループ化 — エンジン、ビューア、セマンティックフェーズ全体で統一
• ✅ 標準フィールドレジストリ — フィールドシノニムの一元化された情報源
• ✅ マルチタイムスタンプファンアウト — すべてのJSONリストのタイムスタンプが相関される
• 🔄 並列相関 — 基盤は整備済み。次はプロファイリング＋プロセスプールディスパッチ
• 🔄 セマンティックマッピング＆相関スコアリング — 機能拡張を進行中

主な機能

• 🔄 デュアルエンジンアーキテクチャ: 時間ウィンドウスキャン（O(N log N)）とIDベース（O(N log N)）の相関戦略を選択可能。
• 📊 マルチアーティファクト対応: Prefetch、ShimCache、AmCache、イベントログ、LNKファイル、ジャンプリスト、MFT、USN、SRUM、レジストリ、ごみ箱などを相関。
• 🔌 ユニバーサルインポート: 任意のフォレンジックツールからのCSV/JSON/SQLite出力をインポートし、Featherデータベースに変換。
• 🎯 スマートIDグループ化: Chrome.exe/chrome.dll/Chrome.EXE などのバリアントは1つのバケットに統合。バージョンやアーキテクチャの修飾子は区別されたまま。
• 🕒 寛容なタイムスタンプ: FILETIME、ISO 8601、Unixエポック（秒/ミリ秒/マイクロ秒）、YYYYMMDD、米国式スラッシュ形式、注釈付き文字列がすべて初回で正しく解析される。
• 📈 マルチタイムスタンプファンアウト: JSONタイムスタンプリスト（Prefetch run_times）が展開され、各実行が独自の相関イベントを取得。
• 🧰 単一の情報源: フィールドシノニムは config/standard_fields/*.json、テーブルごとのメタデータは correlation_engine/config/feather_schemas.json — コードではなくJSON編集で拡張。
• ⚡ ストリーミング＋スレッドセーフ: O(1)メモリの query_time_range_iter。ロック保護されたフェザーキャッシュ。並列相関に対応。
• 🔍 柔軟なルール: 設定可能なパラメータを持つカスタム相関ルール（Wings）を定義可能。
• 📋 誠実な診断: ウィンドウ単位の統計行（records_in / no_identity / parse_cache_hits / below_threshold / matches_emitted）により、証拠がドロップされたかどうかを常に把握可能。
• 🧪 品質の固定化: タイムスタンプ解析、ID正規化、ファンアウト、ライター契約、Eyeオーサリング（書き込み側GEPガバナンス）、標準フィールドレジストリをカバーするpytest回帰テストスイート。

システムアーキテクチャ

Correlation Engineは4つの主要コンポーネントで構成されています：

1. 🗄️ Feathers（データ正規化）

目的: 生のフォレンジックアーティファクトを標準化されたクエリ可能な形式に変換します。

• 正規化されたフォレンジックアーティファクトデータを含むSQLiteデータベース — アーティファクトタイプごとに1つのフェザー（Prefetch、ShimCache、イベントログ、…）で、効率的なクエリのための標準化されたスキーマとメタデータを備えます。
• 任意のフォレンジックツールからのデータを受け入れるユニバーサル形式。``` Any Tool Output → Feather Builder → Normalized Feather Database (CSV/JSON/SQLite) (SQLite with standard schema)

Examples:

• Plaso CSV → Feather Builder → timeline.db
• Autopsy JSON → Feather Builder → autopsy_artifacts.db
• Volatility CSV → Feather Builder → memory_artifacts.db
• Custom Output → Feather Builder → custom.db

**対応しているインポート形式:** CSV（ヘッダー付きの任意のファイル）、JSON（フラットまたはネスト）、SQLite（直接インポート）。自動カラムマッピング、データ型の検出、ISOへのタイムスタンプ正規化、検証、最適化されたインデックスを備えています。```
prefetch.db (Feather)
├── feather_metadata (artifact type, source, record count)
├── prefetch_data (executable_name, path, last_executed, hash)
└── Indexes (timestamp, name, path)

2. 🎯 Wings（相関ルール）

目的: どのアーティファクトを相関させるか、その方法を定義します。

• 時間ウィンドウ、最小一致数、アンカー優先度、および相関させるフェザー（重み付き）を指定するJSON/YAMLルール — ケースをまたいで再利用可能です。各Wingは作成・封印が可能です（誰が、なぜ、どのような証拠に基づいて作成したかを記録します）。```json { "wing_id": "execution-proof", "wing_name": "Execution Proof", "correlation_rules": { "time_window_minutes": 5, "minimum_matches": 2, "anchor_priority": ["Prefetch", "SRUM", "AmCache"] }, "feathers": [ {"feather_id": "prefetch", "weight": 0.4}, {"feather_id": "shimcache", "weight": 0.3}, {"feather_id": "amcache", "weight": 0.3} ] }

#### 3. ⚙️ エンジン（相関戦略）

**目的**: アーティファクト間の関係性を見つけるための相関ロジックを実行します。構造的なリンクが**最初**に処理され、その上に階層重み付けスコアが*解釈・ランキング*として重ねられます（マッチの基準ではありません）。

**時間ウィンドウ走査エンジン** — 時間ベースの分析や体系的な時間的相関に最適です。固定間隔で時間を走査し、ウィンドウごとに全フェザーからレコードを収集し、意味フィールドのマッチング＋重み付けスコアリングを適用し、MatchSet追跡により重複を防止します。**O(N log N)**（インデックス化されたタイムスタンプクエリ）。バッチ処理（約2,567ウィンドウ/秒）。

**アイデンティティベース相関エンジン** — 大規模データセット（1,000レコード超）やアイデンティティ追跡に最適です。アイデンティティを抽出・正規化し、アイデンティティごとにレコードをグループ化し、各クラスター内で時間的アンカーを構築し、証拠を一次/二次/補助として分類し、非常に大規模なセット（5,000アンカー超）では一定メモリでストリーミング処理します。**O(N log N)**。タイプごとに40以上のアイデンティティフィールドパターン。

**エンジン選択**: 時間ベースの分析には時間ウィンドウエンジンを、アイデンティティ追跡にはアイデンティティベースエンジンを使用してください。どちらも本番環境対応で、インデックス化されたクエリにより大規模データセット向けに最適化されています。

#### 4. 🔄 パイプライン（ワークフローオーケストレーション）

**目的**: フェザー作成から結果生成までの完全な分析ワークフローを自動化します。パイプラインは設定（エンジンタイプ、ウィング、フェザー）を読み取り、EngineSelectorを介して適切なエンジンをインスタンス化し、各ウィングを実行し、マッチを集約し、結果を保存（DB＋JSON）し、フィルタリングと可視化を備えたGUIで表示します。```json
{
  "pipeline_name": "Investigation Pipeline",
  "engine_type": "identity_based",
  "wings": [{"wing_id": "execution-proof"}, {"wing_id": "file-access"}],
  "feathers": [
    {"feather_id": "prefetch", "database_path": "data/prefetch.db"},
    {"feather_id": "srum", "database_path": "data/srum.db"},
    {"feather_id": "eventlogs", "database_path": "data/eventlogs.db"}
  ],
  "filters": {
    "time_period_start": "2024-01-01T00:00:00",
    "time_period_end": "2024-12-31T23:59:59"
  }
}

全体がどのように連携するか```

1. Data Preparation Raw Forensic Data → Feather Builder → Feather Databases
2. Configuration Wing Configs + Feather References → Pipeline Config
3. Execution Pipeline Executor → Engine Selector → Correlation Engine
4. Correlation Engine loads Feathers + applies Wing rules → Correlation Results
5. Visualization Results Database → Results Viewer GUI

### 使用例:実行証跡の検出

**シナリオ**: `malware.exe` がシステム上で実行されたことを証明する。```json
{
  "wing_id": "malware-execution",
  "correlation_rules": { "time_window_minutes": 5, "minimum_matches": 2 },
  "feathers": ["prefetch", "shimcache", "amcache"]
}

• -p, --port - ポート番号を指定します（デフォルト: 8080）。
• -t, --threads - スレッド数を指定します（デフォルト: 10）。
• -u, --user-agent - カスタムUser-Agentを指定します。
• -d, --delay - リクエスト間の遅延を秒単位で指定します。
• -o, --output - 結果をファイルに出力します。
• -v, --verbose - 詳細な出力を有効にします。```python from correlation_engine.pipeline import PipelineExecutor executor = PipelineExecutor(pipeline_config) results = executor.execute()

I need the actual content of chunk 20 to translate it. Please provide the Markdown text you want translated.```
Identity: malware.exe
  Anchor 1 (2024-01-15 10:30:00):
    ✓ Prefetch: malware.exe executed at 10:30:00
    ✓ ShimCache: malware.exe modified at 10:30:15
    ✓ AmCache:  malware.exe installed at 10:29:45

  Conclusion: Execution proven with 3 corroborating artifacts

パフォーマンスベンチマーク

相関エンジンの始め方

1. 起動: python -m correlation_engine.main
2. フェザーの作成: フォレンジックアーティファクト（Prefetch、ShimCacheなど）をインポートします。
3. ウィングの作成: 調査用の相関ルールを定義します。
4. パイプラインの作成: 使用するウィングとフェザーを設定します。
5. 実行: パイプラインを実行し、相関結果を表示します。
6. 分析: 結果ビューアを使用して時間的関係を調査します。

📚 相関エンジンのドキュメント

• 相関エンジン概要 — アーキテクチャ図付きのシステム概要
• エンジンドキュメント — デュアルエンジンアーキテクチャ、エンジン選択、パフォーマンス最適化
• アーキテクチャ — コンポーネント統合とデータフロー
• フェザードキュメント — データ正規化システム
• ウィングドキュメント — 相関ルール
• パイプラインドキュメント — ワークフローオーケストレーション
• アーティファクトの追加 — 新しいパーサーをエンジンに組み込むためのワークフロー
• 標準フィールドレジストリ — 両エンジンとEyeによって読み込まれる正規の列名シノニム
• コントリビューションガイド — エンジンへの貢献方法
• クイックリンク: エンジン選択 · トラブルシューティング · パフォーマンス最適化

👁️ Eye — フォレンジックAIアシスタント

強力なアシスタントであり、代替品ではありません。 Eyeは調査担当者の仮説を自動化し、検証します — 最終判断を代わりに行うことは決してありません。

Eye はCrow-Eyeに組み込まれたフォレンジックAIアシスタントです。Windowsアーティファクトの実際の知識ベースに支えられた熟練のフォレンジック調査担当者です。Prefetch、MFT、レジストリ、イベントログ、AmCache、ShimCache、SRUMなど、ケース内のすべてを照会、相関、文書化するための自然言語インターフェースを提供し、実行した内容の監査可能で改ざん防止された記録を保持します。EyeはCrow-Eyeの**「デバイス外に送信されるデータ0ミリ秒」**というプライバシーポリシーに沿って、完全に自社ハードウェア上で（完全なエアギャップ環境を含む）実行できます。完全なアーキテクチャ: eye/README.md。

Eyeは会話形式の質問（「22:00以降にC:\Tempから実行されたものを表示して」）を実際のフォレンジック作業に変換します。アプローチを計画し、関連するアーティファクト知識を取得し、ケースデータベースに対してSQLとクロスアーティファクト検索を実行し、検証済みの回答を統合します。すべての回答は同時に2つの場所で生成されます — あなたへのチャット返信と、ライブレポートワークスペースに書き込まれる構造化ブロックです。これにより、調査が進むにつれて資料が自動的に構築されます。

Ghassan Elsmanプロトコル（GEP）

Eyeが行うすべてのことは、Ghassan Elsmanプロトコル（GEP）に基づいています。これは、デジタルフォレンジックでAIをどのように使用すべきかに関するベンダー中立でツール非依存の標準です。準拠するシステムが守らなければならない10の原則であり、AI支援による調査結果が真実であり、ソースレコードにトレーサブルであり、監査可能で改ざん防止されたチェーンによって裏付けられ、人間の調査担当者が制御できることを保証します:

Crow-EyeのEyeはGEPのリファレンス実装であり、それを支える製品内の動作は運用ルールです。📜 標準を読む: eye/docs/GEP_standard.md。

デプロイメントモード

Eyeは3つのデプロイメントモードを通じて脅威モデルに適応します:

CLIエージェントモードでは、Crow-EyeはクラウドAPIやローカルオフラインサーバーの代わりに、既存のAIターミナル/コマンドラインエージェントをモデルとして駆動します。これにより、既に使用しているエージェントで調査できます。

調査ループ:

1. ケースを開くか作成 — Eyeはそのケースのアーティファクトデータベースと履歴にスコープを限定します。
2. 自然言語で質問するか、ワンクリックの包括的トリアージを起動します。
3. Eyeがパイプラインを実行 — 意図の検出 → 知識の取得 → ツールの実行 → 統合。
4. 二重出力を受け取る — 直接のチャット回答とライブレポートの新しいブロック。
5. ゲート付きアクションを承認 — エクスポートやその他の重要なステップはあなたの承認を待ちます。

switch_modelツールを使用して、実行時にモデルを変更できます。切り替えは同じバックエンド内に制限されているため、証拠が選択したものとは異なるプロバイダーに黙って送信されることはありません。

LLM思考プロセスのトレース

Eyeは、どのように結論に達したかを確認し、後で証明できるように構築されています。Eyeが作業する際、構造化されたThinkingStep更新をリアルタイムでUIにストリーミングします。各ステップにはstep_id、type、人間が読めるlabel、status（active → done、またはerror）、およびオプションのtool/params/detailが含まれます。

典型的なクエリはthinking → rag → thinking → tool_call → synthesisとして展開され、すべてのケースは後で検査できるディスク上のトレースアーティファクトを保持します:

ツール実行

Eyeはツール駆動型です。モデルは証拠に直接触れることはありません。ツール呼び出しを発行し、Eyeがケースのデータベースに対して実行して結果を返します。これにより、すべてのアクションが明示的で、ログに記録され、再現可能になります。ツールはconfigs/llm_config.jsonで定義され、eye/services/context_manager.pyを通じてディスパッチされます。

調査ツール — 証拠の読み取りと分析:

レポートツールはライブレポートワークスペースを構築します: report_append_section、report_add_data_table、report_add_chart、report_add_timeline、report_add_heatmap、report_add_chain_of_custody、report_add_chat_transcript、report_add_image、report_edit_section、report_delete_section、chat_add_table、およびexport_report（エクスポートには人間の承認が必要です）。

オーサリングツール（ガバナンス対象 — 相関ウィングとセマンティックマッピングの構築を参照）: correlation_create_wing、correlation_edit_wing、correlation_create_semantic_mapping、correlation_edit_semantic_mapping。ツール呼び出しはアクティブなバックエンドが期待するものに変換されます — クラウドAPIとローカルサーバーではネイティブの関数呼び出し、CLIエージェントではXML <tool_call>ラッパーです。

相関ウィングとセマンティックマッピングの構築

Eyeは相関エンジンを照会するだけでなく、拡張を支援できます。Eyeが繰り返し発生するクロスアーティファクトパターンを検出すると、新しいウィング（相関ルール）とセマンティックマッピング（技術的価値から人間が読める意味への変換）を提案できます。これはガバナンス付きオーサリングです。Eyeが提案し、アナリストが保存されたアーティファクトをレビューし、すべての変更が正当化され証拠に裏付けられています。

ウィングは、時間ウィンドウと最小一致しきい値内でフェザーを結び付けて主張を証明します:

セマンティックマッピングは、生の技術的価値を人間が読める意味に変換します（例: EventID 4624 → 「正常なログオン」）。2つの形式があります: 単純なmapping（単一の値/正規表現 → セマンティック値）または複数条件のrule（AND/ORで結合された条件）。両方ともcategory、severity、confidence、scopeをサポートし、両方ともreason + related_evidenceが必要です。

ガバナンス — GEPを支える書き込み側ルール:

• 理由必須（GEP-9 + GEP-2を支える）: すべての作成および編集にはフォレンジックなreasonを含める必要があります。
• 証拠リンク（GEP-2を支える）: すべての作成は少なくとも1つのdatabase:table:rowid参照を引用する必要があります。
• Eyeスタンプ付き / 他は読み取り専用（GEP-7 + GEP-9を支える）: Eyeはそのオーサーシップ + 理由 + 編集履歴をスタンプし、Eyeが作成したもののみを編集できます — 組み込みおよび人間が作成したルールは読み取り専用のままです。

自己修復コンテキスト

長時間の調査はモデルのコンテキストウィンドウを超える可能性があります — 特に小規模なオフラインモデルでは顕著です。クラッシュしたり証拠を黙って破棄したりする代わりに、Eyeは各モデル呼び出しの前に自身のコンテキストを自動圧縮します（ガードされた生成パス内で、完全に監査されます）。

各呼び出しの前に、Eyeは完全なペイロードを測定し、応答用のスペースを確保します（ウィンドウの10%、最小512トークン、半分を超えることはありません）。それでも収まらない場合は、保護されたメッセージ（固定、自動検出された証拠、またはツール結果）には決して触れずに、2つの順序付けられたパスで修復します:

1. 要約パス （1回） — 保護されていない履歴が1つの要約に圧縮され、SUMMARIZEDとしてログに記録されます。
2. 破棄パス — 最も古い保護されていないメッセージが収まるまで1つずつ削除され、TRUNCATEDとしてログに記録されます。

それでも削減不可能な証拠コア（固定 + ツール結果 + 現在の質問）が依然としてオーバーフローする場合、Eyeは証拠を切り詰めるのではなく続行を拒否し（REFUSED_OVERFLOW）、クエリを絞り込むかanalyze_large_datasetを使用するよう求めます。最終的にモデルに送信されるものはすべて、証拠保全チェーンのために封印される正確なペイロードです。

🗺️ ナラティブマップ — Eyeの永続的なケースメモリ

Eyeはターン間でステートレスです — そのためナラティブマップは、ケースの「既知のことと結論付けたこと」が保持される場所です。これはEyeの永続的で監査可能で改ざん防止された作業メモリであり、その内容は毎ターンEyeのプロンプトに注入されます（マップは文字通りメモリそのものです）。

• 🧭 評決 → ナラティブ → 証拠。 厳格な階層: 1つのケース評決、その下のナラティブ（主張、それぞれに状態 — proven · open · negative · needs · absolute）、およびその下のアーティファクトに裏付けられた証拠。
• 🪟 独自のウィンドウ。 Eyeチャットウィンドウの**「ナラティブマップ」**ボタンから開き、チャット、ライブレポート、ケースメモリを並べて表示できます。変更があるとライブ更新されます。
• ↔️ 双方向 — あなたが操作できるメモリ。 Eyeの編集とあなた自身のメモの両方が単一のGEP検証済みコミットを通じて流れ、ハッシュチェーン監査ログ（narrative_map_audit.jsonl）に封印されます。その主張と証拠を追加、編集、削除でき、Eyeがケースを理解して解釈する方法を直接形成できます。
• 🚫 裏付けのない主張は決してしません。 Eyeのナラティブは調査中は証拠なしでopenのままにできますが、証拠なしでprovenになることは決してありません。Eyeが確認したが空だったテーマは自動的に**negative**に変換されます — 文書化された不在自体が調査結果だからです。

コンプライアンスの仕組み

コンプライアンスは後付けの機能ではなく、パイプライン内で強制されます。

• 🔗 証拠保全チェーン（エビデンスシール）。 EyeがLLMに送信するすべてのペイロードは封印されます: 正確なバイトのSHA-256、トークン数、モデル + そのコンテキスト制限、および各証拠行の出所（database:table:rowid、MFTレコードの計算されたオフセットを含む）。シールは追加専用でハッシュチェーン化され、<case>/EYE_Logs/eye_payload_seal.jsonlに保存されます — 単一の変更または削除されたレコードがチェーンを壊すため、ログはモデルが分析したバイトを数学的に証明します。
• 🚫 黙った切り詰めはありません。 コンテキストが逼迫すると、Eyeは自己修復し、厳格な順序で予算を再配分します: 優先度1（不動）: 生の証拠 + システムプロンプト › 優先度2（犠牲）: カジュアルな会話 › 優先度3（柔軟）: RAGコンテキスト。それでも証拠コアが収まらない場合、Eyeは証拠を黙って破棄するのではなく拒否します。
• 🧾 切り詰め監査トレイル。 すべてのコンテキスト決定は<case>/EYE_Logs/truncation_audit.logにログ記録されます（SUMMARIZED、TRUNCATED、PRESERVED、PINNED、UNPINNED、BUDGET_REDUCED）。それぞれにハッシュが付きます。検出された証拠は信頼しきい値を超えると自動的に固定されます。メッセージを手動で固定することもできます。
• 📑 証拠からレポートへの義務。 Eyeはチャットで回答し、裏付けとなる証拠をレポートに永続化する必要があります。証拠の記録に失敗するとプロトコル違反としてフラグが立てられます。
• ⚖️ 相関ガバナンス。 Eyeが作成するウィングまたはマッピングにはフォレンジックなreasonとrelated_evidenceを含める必要があります。Eyeの外部で作成されたルールは読み取り専用であり、黙って書き換えることはできません。
• 🔐 プライバシーとエアギャップ。 オフラインモードではEyeは発信呼び出しをゼロにします。クラウドAPIキーはOSネイティブのキーチェーンに保存されます — ハードコードされることも、ログに書き込まれることもありません。

📖 完全なEyeアーキテクチャ: eye/README.md。

📖 Eye-Describe — バイトレベルのアーティファクト知識ベース

🔗 Eye-Describeを探索 → crow-eye.com/eye-describe

歴史的に、調査担当者は基礎となるアーティファクトがどのように動作するか、またはツールがそれらをどのように解析したかを理解せずにフォレンジックツールを信頼するという罠に陥っていました。今日のリスクは、単に*「ツール」を「AI」*に置き換えることです。AIはレコードを完全な技術的正確さで解析できても、それを誤ったコンテキストに配置する可能性があります — 証拠の意味全体を変えてしまいます。

Eye-Describeは、人間もモデルも推測する必要がないように存在します。これはWindowsアーティファクトの生のバイナリ構造のためのインタラクティブなバイトレベル参照であり、同時に2つの役割を果たします:

AIレイヤーを文書化されたアーティファクト動作に固定することで、Crow-Eyeはモデルを信頼するよう求めているのではなく、モデルが生のフォレンジクスを尊重するように制約しています。

ツールへの信頼をAIへの信頼に置き換えないでください。データを理解してください。

🧪 品質と検証

フォレンジックツールは、その出力が防御可能である場合にのみ有用です。Crow-Eyeの正確性に関する作業は意図的に可視化されています:- 回帰テストスイート。 Correlation Engineは、タイムスタンプ解析、ID正規化、マルチタイムスタンプのファンアウト、ライター契約、Eyeオーサリング（書き込み側GEPガバナンス）、標準フィールドレジストリをカバーするpytestスイートによってロックされています。UBAエンジンには独自のスイートが付属しており、実際のケースに対するエンドツーエンドの実行が含まれます。

• 検証ハーネス。 総合的なハーネスは、実際の約70万レコードのWindowsケースで、両方のエンジンに対してデフォルトの7つのウィングすべてを実行します。
• 公開された欠陥履歴。 精度の回帰とその測定された影響は、RELEASE_NOTES.mdに公開されています。修正によってレコード数が桁違いに変わったケースも含まれます。何が、いつ間違っていたかを知ることは、結果を擁護可能にする要素の一部です。
• 検証可能な証拠の会計。 すべてのレコードはマッチまたは名前付きドロップバケットのいずれかに配置され、ウィンドウごとのドロップ台帳により、「残った証拠がない」ことをログから確認でき、盲目的に信頼する必要はありません。
• 改ざん検出可能なログ。 verify_chain()は、Narrative Map監査ログとEvidence Sealチェーンを再ウォークして、変更（人間が読めるフィールドの変更を含む）を検出します。

🔬 研究プラットフォーム

Crow-Eyeはソフトウェア以上のものです。Windowsフォレンジックの分野全体を加速するオープンな研究プラットフォームです。このプロジェクトは以下に焦点を当てています：

• 内部アーティファクト構造に関する詳細なドキュメントの公開。
• 相関ロジックと方法論の共有。
• ピアレビュー、透明性、学術的コラボレーションの実現。
• フォレンジックコミュニティの集合知への貢献。

🛠️ 技術ノート

• レジストリ解析には、完全なレジストリハイブファイルが必要です。
• 一部のアーティファクトは、Windowsのファイルロックメカニズムにより特別な処理が必要です（カスタムレジストリ / ロックされたファイルを参照）。
• LNKおよびジャンプリストの解析は、Crow-Eye独自の専用パーサーによって処理されます。

📸 スクリーンショット

Crow-Eyeのインターフェースと分析ビューの一部です。

🎥 デモ動画:

🚧 ロードマップ

計画中および進行中の作業（リリース済みの変更についてはRELEASE_NOTES.mdを参照）：

• 📊 高度なGUIビューとレポート — よりリッチな可視化とレポート。
• 🔄 拡張された検索ダイアログ — 自然言語サポートを備えた高度なフィルタリング。
• 🎯 拡張されたセマンティックマッピング — すべてのアーティファクトタイプにわたる包括的なフィールドマッピング。
• 📈 高度な相関スコアリング — 洗練された説明可能な信頼度スコアリング。
• ⚡ 並列相関 — プロセスポールディスパッチ。大規模なワークロードではデフォルトで有効。

アイデアがある、またはアーティファクトを追加したいですか？ Issueを開くか、Contributingを参照してください。

📚 ドキュメント

• TECHNICAL_DOCUMENTATION.md — アーキテクチャ、コンポーネント、開発ガイド。
• RELEASE_NOTES.md — 各リリースの新機能（UBA、Narrative Map、クラウドEyeバックエンド、ケース管理の堅牢化など）。
• Correlation Engineドキュメント — 概要、エンジン、feathers、wings、パイプライン。
• タイムラインアーキテクチャ — タイムラインモジュールの内部構造。
• Eyeアーキテクチャ および GEP標準 — AIアシスタントとその統治プロトコル。

🤝 コントリビューション

Crow-Eyeはオープンな研究プラットフォームとして構築されており、新しいパーサー、相関ルール、ドキュメント、アーティファクト研究など、コントリビューションを歓迎します。

• 一般的なコントリビューション: CONTRIBUTING.md
• Correlation Engine（優先分野）: correlation_engine/CONTRIBUTING.md
• 連絡先: [email protected] · またはIssue / プルリクエストを開いてください。

🌐 ウェブサイトとコミュニティ

• 🌍 公式ウェブサイト: crow-eye.com — リソース、ドキュメント、ダウンロード。
• 💬 Discord: Crow-Eye Discordに参加 — 直接のサポート、アーティファクト研究、リリースのお知らせ。

📄 ライセンス

Crow-Eyeは**GNU General Public License v3.0**（GPL-3.0）の下でリリースされています。このライセンスの条件の下で、自由に使用、研究、共有、変更することができます。

📝 Crow-Eyeの引用

学術研究、発表された研究、またはケースレポートでCrow-Eyeを使用する場合は、次のように引用してください：```bibtex @software{elsman_crow_eye, author = {Elsman, Ghassan}, title = {Crow-Eye: A Windows Forensics Engine}, url = {https://github.com/Ghassan-elsman/Crow-Eye}, license = {GPL-3.0}, year = {2026} }

Elsman, G. *Crow-Eye: A Windows Forensics Engine* (GPL-3.0)。https://github.com/Ghassan-elsman/Crow-Eye

方法論の引用については、Ghassan Elsman Protocolは[`eye/docs/GEP_standard.md`](https://github.com/ghassan-elsman/crow-eye/blob/main/eye/docs/GEP_standard.md)に別途文書化されています。

## 💖 サポート

Crow-Eyeは無料のオープンソースであり、一人の開発者によって構築・保守されています。あなたの業務に役立つ場合は、スポンサーへのご登録をご検討ください。スポンサーシップは、新しいパーサーや研究の資金に直接充てられます：**[SPONSORS.md](https://github.com/ghassan-elsman/crow-eye/blob/main/SPONSORS.md)** ・ **[GitHub Sponsors](https://github.com/sponsors/Ghassan-elsman)**。

## クレジット

**Ghassan Elsman** によって作成・保守されています。