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.12.6 · 相関エンジン: 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"]

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 -- "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パッケージのフォルダはOffline Importerを経由し、サードパーティ製の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が実行して記録するツールコールを発行するだけです。 |
| ⑤ → Report | **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**ハッシュチェーンに固定され、**コンプライアンス**ページはEyeを [Ghassan Elsman Protocol (GEP)](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/eye/docs/GEP_standard.md) に照らして継続的に検証します。ルールごとのライブなステータスが表示され、`EYE_Logs/audit_trail.json` にエクスポートできます。

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

> **推奨：** 公式ウェブサイトからパッケージ版のWindowsビルド（**MSIインストーラー / EXE**）を入手してください。Pythonのセットアップは不要で、すぐにそのまま動作します。

### ▶️ [Windows版Crow-Eyeをダウンロード → 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の実行、ファイルシステム、ユーザーアクティビティに関する幅広いアーティファクトを解析します。

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

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

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

• Jump Lists & LNK — Crow-Eye独自の専用パーサーにより、標準的なシステムロケーションから自動的に解析されます（ファイルアクセス、ターゲットパス、タイムスタンプ、メタデータ）。
• Registry — システムハイブを自動的に解析します。カスタムレジストリ解析を行うには、ハイブファイルを CrowEye/Artifacts Collectors/Target Artifacts（またはケースの registry/ フォルダ）にコピーします:
  • NTUSER.DAT（C:\Users\<Username>\NTUSER.DAT から）
  • SOFTWARE（C:\Windows\System32\config\SOFTWARE から）
  • SYSTEM（C:\Windows\System32\config\SYSTEM から）
  • Windowsは動作中にこれらをロックします。ライブシステムの場合は、外部メディア（WinPE/Live CD）から起動するか、フォレンジック取得ツールを使用するか、ディスクイメージを解析してください。
• Prefetch — C:\Windows\Prefetch を解析し、実行履歴とフォレンジックメタデータ（実行ごとのタイムスタンプを含む）を抽出します。
• Event Logs — System/Security/Applicationログをデータベースに自動解析し、包括的な分析を可能にします。
• ShellBags — フォルダアクセス履歴とユーザーのナビゲーションパターンを明らかにします。
• Recycle Bin — $RECYCLE.BIN を解析して、削除されたファイル名、元のパス、削除日時、サイズを復元します（ライブシステムとディスクイメージ）。

🔧 解析モード

🦅 Crow-Claw 取得

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

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

🔍 オフライン解析（Offline Importer）

ターゲットへのライブ接続なしで、あらゆるソースから収集されたアーティファクトを解析します。3つの明確な操作があります:

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

解析は、Crow-Eyeの専用オフラインパーサーが処理します。ライブモードと同じアーティファクトロジックを収集されたファイルに対して適用します: Prefetch、Registry、MFT、USN（MFT/USNコリレーターを含む）、AmCache、ShimCache、SRUM、Event Logs、LNK/JumpLists、Recycle Bin。

📎 Import Evidence（サードパーティデータ）

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

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

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

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

⚡ ライブ解析

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

🗂️ ケース管理

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

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

統合された時間グリッド上でアーティファクト間のイベントを相関させます。ヒートマップ、週、日のビューを備え、フラットなスーパータイムラインではなく、アイデンティティで結び付けられた、法廷で追跡可能なストーリーを提供します。

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

🔎 検索とエクスポート

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

🔗 動的リンキング

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

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

生のアーティファクトを、平易な英語のアクティビティストーリーに変換します。ユーザーとそのアプリケーションが実際に何を行ったかを、マネージャー/人事担当者にも読みやすい形で説明し、すべての記述は正確なソース証拠まで追跡可能です。

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

• 🧩 40の宣言型行動検知（uba/config/behavior_rules.json）— コードを書かずに調整可能 — 各検知は重大度で分類されます: routine · notable · suspicious · critical。
• 🕵️ 重要な行動を検出: サインイン/サインアウト/ロック解除、プログラムの起動・実行・インストール、ファイルのオープン/削除/推定コピー、USBデバイスの接続、ネットワーク共有へのアクセス、永続化と自動起動、明示的な資格情報の使用（runas）、アカウントとグループの変更、サービスの変更、システムクロックの改ざん（suspicious）、イベントログの消去（critical）。
• 🗺️ 3つのビュー — Activity Storyフィード、Activity Mapヒートマップ（日×時間）、そしてこのケースの各検知を 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 Journal · MFT · UserAssist · BAM · Prefetch · ShimCache · AmCache · MUICache · ShellBags · LNK / JumpLists · Recycle Bin · SRUM（アプリケーション、ネットワーク、接続） · レジストリハイブ。

フォレンジック保証

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

UBAは、統計/MLによる異常スコアリングではなく、ルール駆動の行動相関と分類です。すべての検出結果は、明示的で監査可能なルールに対応付けられます。完全な検知カタログについては RELEASE_NOTES.md を参照してください。

🧩 相関エンジン

Correlation Engine v1.7.0 — 再構築の中核。リリース履歴については RELEASE_NOTES.md を参照してください。

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

🎥 ユーザーガイド

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

🎯 精度と証拠の完全性

以前の信頼性向上作業の上に重ねられた、精度に焦点を当てたパスです。実際の約70万レコードのWindowsケースに対してエンドツーエンドで検証されています。以下のすべての修正はpytest回帰テストスイートによって固定され、両エンジンに対して7つのデフォルトWingすべてを実行する総合的な検証ハーネスによって検証されています。

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

• 修正: タイムフィルタが有効な場合、アイデンティティエンジンは各featherの最初の行だけを反復処理していました（タイムゾーン対応のdatetimeとnaive datetimeの比較がTypeErrorを発生させ、行ごとのループが中断されていました）。検証ケースでは、処理されたレコード数が3,558 → 745,615に増加しました。
• 修正: ログレコードはすべてのイベントを、そのイベントのPROVIDERをアイデンティティとして同一化していました（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つのwingでは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、Recycle Bin、リムーバブルルート、ネットワーク共有）に分類します。両方の分類にまたがるマッチは impersonation_alert を発生させます（約0.05%の割合で、それぞれが実際の候補です）。

正直な証拠の会計処理 — 名前付きバケット（no_identity_field、normalize_failure、below_threshold_skipped など）を持つウィンドウごとのドロップ台帳に加え、パイプラインごとのサマリー（処理されたレコード数、High/Lowの出力数、アイデンティティなし、ドロップバケット、timeless-feather結合）を提供します。すべてのレコードはマッチまたは名前付きドロップバケットのいずれかに格納されるため、「残った証拠がない」ことをログから検証できます。low_confidence_review_mode はデフォルトでONのため、閾値未満のグループは静かに消えるのではなく、Low信頼度マッチになります。

Timeless-featherのアイデンティティ強化 — 行ごとのタイムスタンプを持たないfeather（AutoStartPrograms、MUICache、SystemServices、TypedPaths）には、各行に偽の生成時刻がスタンプされなくなりました。代わりに、時間指定のマッチが形成された後、エンジンはすべてのtimeless featherから一致するレコードをアイデンティティごとに補足証拠として結合します。

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

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

✅ 本番対応状況

相関エンジンは本番対応であり、調査で積極的に使用されています（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、レジストリ、RecycleBinなどを相関。
• 🔌 ユニバーサルインポート：あらゆるフォレンジックツールのCSV/JSON/SQLite出力をインポートし、Featherデータベースに変換。
• 🎯 スマートIDグループ化：Chrome.exe/chrome.dll/Chrome.EXE などのバリアントは1つのバケットにまとまり、バージョンやアーキテクチャの修飾子は区別されたまま。
• 🕒 寛容なタイムスタンプ：FILETIME、ISO 8601、Unixエポック（s/ms/μs）、YYYYMMDD、米国式スラッシュ、注釈付き文字列をすべて初回で正しく解析。
• 📈 マルチタイムスタンプファンアウト：JSONタイムスタンプリスト（Prefetch run_times）を展開し、各実行が独自の相関イベントを取得。
• 🧰 単一の情報源：フィールド同義語は config/standard_fields/*.json、テーブルごとのメタデータは correlation_engine/config/feather_schemas.json — コードではなくJSONの編集で拡張。
• ⚡ ストリーミング＋スレッドセーフ：O(1)メモリの query_time_range_iter、ロック保護されたfeatherキャッシュ、並列相関に対応。
• 🔍 柔軟なルール：設定可能なパラメータでカスタム相関ルール（Wings）を定義可能。
• 📋 誠実な診断：ウィンドウごとの統計行（records_in / no_identity / parse_cache_hits / below_threshold / matches_emitted）により、エビデンスが破棄されたかどうかを常に把握可能。
• 🧪 品質の固定化：タイムスタンプ解析、ID正規化、ファンアウト、ライター契約、Eyeオーサリング（書き込み側GEPガバナンス）、標準フィールドレジストリをカバーするpytest回帰テストスイート。

システムアーキテクチャ

相関エンジンは4つの主要コンポーネントで構成されています：

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

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

• 正規化されたフォレンジックアーティファクトデータを含むSQLiteデータベース — アーティファクトタイプごとに1つのfeather（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（相関ルール）

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

• 時間枠、最小一致数、アンカー優先度、そして相関させるfeathers（重み付き）を指定する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. ⚙️ エンジン（相関戦略）

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

**タイムウィンドウスキャンエンジン** — 時間ベースの分析と体系的な時間的相関に最適です。固定間隔で時間をスキャンし、ウィンドウごとに全featherからレコードを収集し、セマンティックフィールドマッチング＋重み付けスコアリングを適用し、MatchSetトラッキングによって重複を防ぎます。**O(N log N)**（インデックス化されたタイムスタンプクエリ）。バッチ処理（約2,567ウィンドウ／秒）。

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

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

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

**目的**: feather作成から結果生成までの完全な分析ワークフローを自動化します。パイプラインは設定（エンジンタイプ、wings、feathers）を読み取り、EngineSelectorを介して適切なエンジンをインスタンス化し、各wingを実行し、マッチを集約し、結果（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"]
}

The input text for chunk 18 is missing. Please provide the Markdown content to translate.```python from correlation_engine.pipeline import PipelineExecutor executor = PipelineExecutor(pipeline_config) results = executor.execute()

```| STIX | ✅ | ✅ | ✅ (転送中) \n✅ (保存中) | 🟡 | 🟡 | ✅ | 🟡 |
| OpenIOC | ✅ | ✅ | ✅ (転送中) \n✅ (保存中) | ✅ | 🟡 (制限付き) | ✅ | ✅ |
| VirusTotal | ✅ | ✅ | ✅ (転送中) \n✅ (保存中) | ✅ | ✅ | ✅ | ✅ |
| Splunk | 🟡 | 🟡 | 🟡 (Splunkアプリなし) | ✅ | ✅ | 🟡 (モジュールなし) | 🟡 (モジュールなし) |
| FreshDesk | ✅ (変換なし) | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ |

### モジュールパス

- `frontend`: `$HOME/.shuffle`
- `backend`: `/var/lib/shuffle/`
- `Orborus`: `/var/lib/shuffle/`

## さらに詳しく
[<img src="https://shuffler.io/images/Shuffle-favicon-white-bg.png">](https://shuffler.io?utm_source=gh&utm_medium=repo) **shuffler.ioでオープンソースSOARについて詳しく学ぶ**``````
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. Feathersの作成: フォレンジックアーティファクト（Prefetch、ShimCache、…）をインポートします。
3. Wingsの作成: 調査のための相関ルールを定義します。
4. パイプラインの作成: 使用するwingsとfeathersを設定します。
5. 実行: パイプラインを実行し、相関結果を表示します。
6. 分析: Results Viewerを使用して時間的な関連性を調べます。

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

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

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

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

EyeはCrow-Eyeに組み込まれたフォレンジックAIアシスタントであり、Windowsアーティファクトの実知識ベースに支えられた熟練のフォレンジック調査担当者です。ケース内のすべて（Prefetch、MFT、Registry、Event Logs、AmCache、ShimCache、SRUMなど）を照会、相関、文書化するための自然言語インターフェースを提供し、実行内容の監査可能で改ざん防止された記録を保持します。Eyeは、Crow-Eyeの**「デバイス外に送信されるデータは0ms」**というプライバシーポリシーに従い、自分のハードウェアだけで（完全にエアギャップされた環境でも）実行できます。完全なアーキテクチャ: 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（エクスポートには人間の承認が必要）。

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

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

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

Wing は、タイムウィンドウと最小マッチ閾値内でfeathersを結び付け、主張を証明します:

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

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

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

自己修復コンテキスト

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

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

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

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

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

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

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

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

コンプライアンスは後付けの機能ではありません — パイプライン内で強制されます。

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

📖 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の正確性への取り組みは意図的に可視化されています:

• リグレッションスイート。 相関エンジンは、タイムスタンプ解析、アイデンティティ正規化、マルチタイムスタンプのファンアウト、ライターコントラクト、Eyeのオーサリング（書き込み側のGEPガバナンス）、標準フィールドレジストリをカバーするpytestスイートによってロックされています。UBAエンジンは、実際のケースに対するエンドツーエンドの実行を含む独自のスイートを同梱しています。
• 検証ハーネス。 総合的なハーネスが、実際の約70万レコードのWindowsケースで両方のエンジンに対して7つのデフォルトwingsすべてを実行します。
• 公開された欠陥履歴。 精度のリグレッションとその測定された影響はRELEASE_NOTES.mdで公開されています — 修正によって確認されたレコード数が桁違いに変化したケースも含まれます。何がいつ間違っていたかを知ることが、結果を防御可能にする要素の1つです。
• 検証可能な証拠の会計処理。 すべてのレコードはマッチまたは名前付きドロップバケットのいずれかに格納され、ウィンドウごとのドロップ台帳により、「残された証拠がない」ことを盲信するのではなくログから確認できます。
• 改ざん防止ログ。 verify_chain()は、ナラティブマップの監査ログとEvidence Sealチェーンを再ウォークして、人間が読めるフィールドの改ざんも含む変更を検出します。

🔬 研究プラットフォームCrow-Eye は単なるソフトウェアではありません — Windows フォレンジック分野全体を加速するオープンリサーチプラットフォームです。このプロジェクトは以下に重点を置いています:

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

🛠️ 技術メモ

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

📸 スクリーンショット

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

🎥 デモビデオ:

🚧 ロードマップ

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

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

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

📚 ドキュメント

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

🤝 コントリビューション

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

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

🌐 Web サイトとコミュニティ

• 🌍 公式 Web サイト: 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: Windowsフォレンジックスエンジン* (GPL-3.0). https://github.com/Ghassan-elsman/Crow-Eye

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

## 💖 サポート

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

## クレジット

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