Files

Akira 7a1aa81f9f 実装完了

作成・変更したファイル
バックエンド（新規）:

apps/mail/models.py — MailSender, MailEmail, MailNotificationToken
apps/mail/serializers.py
apps/mail/views.py — Windmill用API、フィードバック、ルール管理
apps/mail/urls.py
apps/mail/admin.py
マイグレーション（自動生成・適用済み）
バックエンド（変更）:

settings.py — apps.mail 追加、MAIL_API_KEY/FRONTEND_URL 環境変数
urls.py — /api/mail/ 追加
フロントエンド（新規）:

mail/feedback/[token]/page.tsx — 認証不要、フィードバック3択＋スコープ選択
mail/rules/page.tsx — ルール管理（一覧・追加・削除）
フロントエンド（変更）:

Navbar.tsx — 「メールルール」メニュー追加
types/index.ts — MailSender, MailEmailFeedback 型追加
次のステップ（Windmill側）
Keinaシステム側の実装は完了しています。次はWindmillにIMAPポーリングスクリプトを書く必要があります。Windmillのスクリプトが必要になったタイミングでお声がけください。

2026-02-22 09:27:27 +09:00

4.8 KiB

Raw Blame History

最適化フィルタ仕様書 (v2.1)

1. システム目的

Gmailから取得した生データを、プログラムによる**「脊髄反射的処理（静的フィルタ）」で徹底的に選別・加工し、人間と同等の判断が必要な「思考的処理（LLM判定）」**へ渡すトークン量を極限まで削減する。

2. 処理フロー概略

静的除外: ドメイン・キーワードによる即時廃棄。
定型処理: 認証・通知・配送状況などの「構造が既知」なメールの自動抽出。
クレンジング: HTML・署名・引用の完全除去による軽量化。
LLM判定: 絞り込まれたテキストのみを最小トークンで判定。

3. 詳細仕様

3.1. フェーズ1：静的フィルタ（LLMバイパス）

以下の条件に合致する場合、LLMステップを呼び出さず処理を完了させる。

ブラックリスト判定: 以下のドメイン・送信元は即時廃棄（または「通知不要」としてDB記録）。
mail.aliexpress.com, instagram.com, facebookmail.com, 各種メルマガ（件名に「PR」「メルマガ」を含むもの）。
認証・セッション系:
対象キーワード: 認証コード, セキュリティコード, ログインのお知らせ, ワンタイムパスワード.
処理: From と Subject を結合した文字列のみをLINE通知へ送り、終了。
重複排除（Deduplication）:
過去24時間以内に同一の「送信者＋送り状番号（ヤマト等）」または「送信者＋件名」を処理済みの場合、ステータス更新のみを行い、新規通知としては扱わない。

3.2. フェーズ2：定型データ抽出（正規表現エンジン）

LLMに文脈を読ませるのではなく、正規表現で特定の値を抜き出し、通知文を自己生成する。

配送状況（ヤマト運輸・Amazon等）:
[0-9]{4}-[0-9]{4}-[0-9]{4}（伝票番号）を抽出。
「お届け予定」「完了」などのキーワードを抽出し、固定フォーマット化。
金融・決済（JAバンク・カード会社）:
[0-9,]+円（金額）および [0-9/]{5,10}（日付）を抽出。
「支払金額：〇〇円、期日：〇〇」として構造化。

3.3. フェーズ3：テキスト・プリプロセッサ（クレンジング）

LLMに渡す場合でも、以下の処理を「必ず」事前に行う。

HTML剥離: BeautifulSoup 等を用い、タグ・スタイル・スクリプトを完全除去。
ノイズ除去:

https?://\S+ → [URL] へ置換。
行頭の >（引用）および、空行・連続スペースの削除。
定型フッター（「本メールに心当たりがない場合」「配信停止は」等）をキーワードリストに基づき一括削除。

ペイロード制限:

From, Subject, Body（先頭300文字）をJSON形式にパックする。

4. LLM判定フェーズ（最終関門）

4.1. プロンプト定義

出力トークンを最小化するため、LLMには**「1文字のランク」**のみを返させる。

Input: {"from": "...", "sub": "...", "body": "..."}
System Prompt: 「このメールが吉田さんの業務（農業・システム開発）や資産保護において、即座に確認すべき『重要』なものか判定せよ。
1: 即時通知が必要（重要・緊急）
2: 1日の終わりにまとめて通知（低緊急・要確認）
3: 通知不要出力は数字1文字のみとせよ。」

5. フィードバック・学習仕様

システムを改善し続けるためのデータ循環構造。

通知インターフェース: LINE通知の下部に「不要」「毎日」のリンクを設置。
データベース（PostgreSQL）:
feedback_table: sender_domain, subject_pattern, user_decision を記録。
動的更新: user_decision が ignore になったドメインは、自動的に「3.1. ブラックリスト」へ同期される。

6. 実装上の留意点（Antigravity等）

タイムアウト対策: 1通あたりの処理時間を最小化するため、DB照会はインデックスを貼った高速なものにすること。
エラーハンドリング: Gmail APIの取得失敗時や、LLMが数字以外を返した際のデフォルト値は「通知（1）」として、重要なメールの消失を防ぐ。

仕様書は以上となります。Antigravityでの実装において、具体的なPythonコードの記述や、LINE Botとの連携部分でサポートが必要になりましたら、いつでもお声がけください。

次は何をお手伝いしましょうか？

4.8 KiB Raw Blame History Unescape Escape