Reel

設定可能なワークフロー、キャンペーン管理、オプションの認証情報プロキシを備えた、フィッシングシミュレーションおよびセキュリティ意識向上フレームワーク。

クイックスタート（OPS 用途）

1. リポジトリをクローンして、その中に cd します。
2. ./deploy.sh を実行します。Ubuntu を使用している前提で、前提条件を自動設定します。
3. ./start.sh --preload-ml を実行します。これによりサーバーが起動し、使用する ML モデルが事前ロードされます。

Admin UI は http://localhost:8000、フィッシングサーバーは http://localhost:1234 で利用できます。デフォルトのログインは admin / admin123 です。初回ログイン後にパスワードを変更してください。

管理者パネルにアクセスするには、SSH 経由でポート 8000 をローカルにフォワーディングしてください。管理者パネルや Flask サーバー（ポート 1234）をインターネットに直接公開しないでください。

deploy.sh は同じホストに Caddy サーバーをインストールします。すべて Caddy をリバースプロキシとして使用する前提で構築されています。使用しなくても構いませんが、その場合は自己責任となります。

start.sh のオプションフラグ：

• --with-caddy — Docker 経由で Caddy を起動します（ローカルテストのみ）。
• --preload-ml — フィッシング検出モデル（約1.3GB）を事前ダウンロードします。Phishing Detector プラグイン使用時の初回遅延を回避します。
• --reset-db — データベースをリセットして再初期化します。
• --admin-only — 管理サーバー（ポート 8000）のみ起動します。
• --phishing-only — フィッシングサーバー（ポート 1234）のみ起動します。
• --skip-init — データベースの初期化をスキップします。
• --skip-setup — venv/依存関係のセットアップをスキップし、.env を読み込んでサーバーを起動するだけです。

start.sh を使用しない場合、依存関係のインストールとデータベースの初期化後に、uv run python -m cli start で両方のサーバーを実行できます。

依存関係

Python： requirements.txt を参照してください。コアスタックには Flask、SQLAlchemy、Jinja2、Pydantic、Flask-Login、python-jose、passlib、cryptography、Flask-WTF が含まれます。Phishing Detector プラグインは transformers と torch を使用します。認証情報プロキシは Playwright を使用し、オプションの統合機能は OpenAI/Anthropic と boto3（AWS Connect）を使用します。

開発： requirements-dev.txt には pytest、pytest-cov、および関連するテストツールが追加されています。テストとカバレッジを実行するには uv pip install -r requirements-dev.txt でインストールします。

システム（本番）： デプロイスクリプトは Ubuntu/Debian を対象としています。uv、Caddy（リバースプロキシ）、libmagic1 などのシステムパッケージをインストールします。認証情報プロキシ用に、start.sh は uv run playwright install chromium を実行して Chromium をインストールします。

スクリプト

deploy.sh

Ubuntu での本番環境の準備。冪等性があります。以下の処理を行います：

1. Ubuntu/Debian を確認します。
2. システムパッケージ（curl、ca-certificates、libmagic1 など）をインストールします。
3. uv が無い場合はインストールします。
4. Caddy をリバースプロキシとしてインストールします（APT）。
5. 仮想環境を作成し、requirements.txt から Python の依存関係をインストールします。
6. .env が無い場合は .env.example から作成し、SECRET_KEY と JWT_SECRET_KEY が未設定の場合は生成します。
7. 必要なディレクトリを作成します（storage/caddy/data、storage/caddy/config、storage/uploads、storage/templates、storage/assets、instance）。
8. オプションで --init-db によりデータベースを初期化します（uv run python -m cli init --force を実行）。

アプリケーションは起動しません。本番環境では、Caddy（リバースプロキシ）を起動してから、./start.sh またはプロセスマネージャでアプリを起動し、すべてのトラフィックがプロキシ経由でアプリに届くようにします。

start.sh

開発およびローカル起動用。以下の処理を行います：

1. .env を読み込み、SECRET_KEY と JWT_SECRET_KEY を確認します（デフォルト値が設定されている場合は生成します）。
2. uv がインストールされていることを確認します。
3. 仮想環境が無い場合は作成します。
4. requirements.txt から依存関係をインストールします。
5. 認証情報プロキシ用に uv run playwright install chromium を実行します。
6. オプションで --preload-ml によりフィッシング検出モデル（約1.3GB）を事前ダウンロードします。
7. データベースファイルが存在しない場合はデータベースを初期化します（--skip-init を指定した場合を除く）。削除して再初期化するには --reset-db を使用します。
8. オプションで --with-caddy により Docker 経由で Caddy を起動します（ローカルテストのみ）。
9. サーバーを起動します。デフォルトでは uv run python -m cli start で管理サーバーとフィッシングサーバーの両方を起動します。どちらか一方のみを起動するには --admin-only または --phishing-only を使用します。

本番環境へのデプロイ

本番環境では、アプリケーションは必ずリバースプロキシの背後で実行する必要があります。Flask 開発サーバーをインターネットに直接公開しないでください。

リバースプロキシは、TLS 終端、正しい Host ヘッダー、パスおよびドメインのルーティング、管理トラフィックとキャンペーントラフィックの分離を担当します。アプリは localhost または内部ポートで待ち受け、プロキシがパブリック HTTPS を処理し、構成に応じて管理サーバー（例：ポート 8000）とフィッシングサーバー（例：ポート 1234）に転送します。

推奨： リバースプロキシとして Caddy を使用してください。deploy.sh は APT 経由で Caddy をインストールします。プロジェクトには Caddyfile の例（例：Caddyfile.minimal）が含まれています。deploy.sh 実行後、Caddy を起動し（例：caddy run --config /path/to/Caddyfile.minimal）、その後 ./start.sh またはプロセスマネージャでアプリケーションを起動します。アプリを直接公開しない限り、同等のリバースプロキシ（nginx、Traefik など）でも問題ありません。

プロジェクトの目的

Reel はフィッシングシミュレーションとセキュリティ意識向上フレームワークです。オペレーターは管理 UIを使用して、キャンペーン、ワークフロー、テンプレート、ターゲットを管理します。フィッシングサーバーはキャンペーンのランディングページを配信し、各リクエストでワークフロー（プラグインのノードベースのグラフ）を実行します。

app.py には2つのアプリケーションエントリポイントがあります。フィッシングサーバー用の create_app() と管理 UI 用の create_admin_app() です。キャンペーンはインバウンド（訪問者がリンクをたどる。GET および POST ワークフローがページビューとフォーム送信を処理）またはアウトバウンド（システムが送信ワークフロー経由でメールや電話を送信）のいずれかになります。Caddy を使用して、キャンペーンのドメインベースのルーティングを行うことができます。認証情報プロキシは Playwright によるブラウザ自動化を使用して、取得した認証情報をターゲットサイトで再生します。

ワークフローの概念

インバウンド

ユーザーがキャンペーン URL（例：/<campaign_uid>）にアクセスします。フィッシングサーバーはキャンペーン UID でルーティングします。GET リクエストではキャンペーンのGET ワークフロー（例：ランディングページのレンダリング、CAPTCHA）を実行し、POST リクエストではPOST ワークフロー（例：入力の検証、認証情報の取得、リダイレクト）を実行します。ワークフローはキャンペーンタイプであり、対応する HTTP メソッド（GET、POST、または BOTH）を宣言します。実行コンテキストには campaign、request、session、variables が含まれます。レスポンスは _response_html、_response_redirect、_response_json などのコンテキストキーから取得されます。インバウンドワークフローは、ランディングページ、CAPTCHA、認証情報の取得、リダイレクト、ロギングに使用されます。

アウトバウンド

オペレーターは管理 UI から、キャンペーンにリンクされた送信ワークフロー（キャンペーンの「Workflow」/送信ワークフロー）を実行します。送信エグゼキューターは送信タイプの単一ワークフローを実行します。ターゲットを選択し（例：CSV または追跡ユーザーから）、オプションでコンテンツを検証または事前レンダリングし、その後ターゲットを反復処理してメールをレンダリングし、レート制限を適用し、プラグイン（例：SMTP）経由で送信します。訪問者向けの GET/POST はありません。ワークフローはコンテンツを生成し、ターゲットのリストに送信します。

概要：

• インバウンド： 訪問者主導。GET および POST リクエストがキャンペーンワークフローをトリガーします。ランディングページとフォーム処理に使用されます。
• アウトバウンド： オペレーター主導。単一の送信ワークフローが管理コンテキストで実行され、ターゲットに一括送信します（メール、音声など）。

ワークフロー変数

ワークフローを構築する際は、補間のために {{variable}} 構文を使用します。ネストされたパスはドット記法を使用します：{{nested.key}}。

ターゲットデータ（CSV / ループから）

CSV 例： email,first_name,last_name,company,landing_page → {{target.email}}、{{target.first_name}}、{{target.company}}、{{target.custom_data.landing_page}} を使用します。

キャンペーン / 設定

URL

URL 難読化： ソースとして url または target.landing_page を使用するか、http://{{target.ip}}/login のように補間します。

HTML / BERT フィッシング検出器

フィッシング検出器： html_content に {{template_html}}、{{campaign.template_html}}、または {{email_html}} を設定します。

プラグイン出力

シンプルな送信ワークフローの例

Target Selector (CSV) → Loop (array_source: targets, item_key: target) → Render Template → SMTP Sender

テンプレート内の一般的なタグ：{{target.email}}、{{target.first_name}}、{{target.last_name}}、および追加の CSV カラムには {{target.custom_data.X}}。

プラグイン

ワークフローはノードから構築されます。各ノードは設定を持つプラグインです。以下の組み込みプラグインが利用可能です。

開発

• テストを実行：make test-fast または ./run_tests.sh
• カバレッジ付きテスト：make test-coverage または ./run_tests.sh --coverage
• リント：make lint
• フォーマットチェック：make format-check

追加のターゲット（単体/統合/機能テストの分割、DB の初期化/リセット、管理サーバーまたはフィッシングサーバーのみの実行）については Makefile を参照してください。

ドキュメント

• DEVELOPMENT.md — カスタムプラグインを開発するための詳細な手順。
• AGENT_README.md — AI エージェント向け：コードベースの概念、プラグインシステム、スタイルガイド、プロンプト。