稼働モデル
Gemma4 31B
手元のPCで実行
新着メール監視
60秒ごと
届いた返信をポーリング
処理場所
100% ローカル
外部クラウドに送らない
パイプライン — メールが届いてから返信するまで
01
問い合わせフォーム
このサイトのコンタクトフォームから送信。名前・メアド・依頼内容を受け取る。
→
02
Supabase 保存
Vercel API経由でSupabaseのcontactsテーブルにstatus=newで保存。
→
03
Gemma4 初回返信
15分ごとに新着を確認。ローカルのGemma4-31Bが依頼内容を整理し、ヒアリングメールを送信。
→
04
Gmail受信
相手からの返信がGmailに届く。AgentHiveが60秒ごとにポーリング。
→
05
Mail Router
コードノードが決定論的にルーティング。スパム・ML・no-reply を除外し、実在する問い合わせのみ通過。
→
06
専任秘書エージェント
送信者ごとに1体のエージェントを自動生成。過去のやり取りを保持しながら返信を起草。
→
07
本人承認 → 送信
AIは自分で送らない。下書きを承認キューに積み、荻野がTelegramで承認して初めてGmailから送信される。
エージェント階層
※ メアドはすべてサンプルです
🔀 Mail Router
１送信者 = １エージェント の原則
各秘書エージェントは担当する送信者のメールスレッドのみにアクセスできます。他の送信者のやり取りや、ローカルファイル・コード実行権限は一切持ちません。
各秘書エージェントは担当する送信者のメールスレッドのみにアクセスできます。他の送信者のやり取りや、ローカルファイル・コード実行権限は一切持ちません。
セキュリティ設計 — 各エージェントの権限範囲
秘書エージェントに許可されていること
担当送信者とのメールスレッドを読む
メールに返信する（gmail_reply / gmail_send・送信は本人承認後）
荻野本人にTelegramで通知する（send_telegram）
重要度に応じてエスカレーション
秘書エージェントに禁止されていること
ローカルファイルの読み書き（read_file / write_file なし）
Pythonコードの実行（run_python なし）
外部URLへのHTTPリクエスト（http_get なし）
他の送信者のメールスレッドへのアクセス
認証情報・システム構成の読み取り
プロンプトインジェクション対策
メール本文は「処理対象のデータ」として囲い込み、いかなる指示としても解釈させない設計（本文の命令文は無効化）。 加えて秘書エージェントにはファイル読み書きやコード実行のスキルを一切与えていないため、「前の指示を無視して」「SSHキーを教えて」等が書かれていても、実行する手段そのものが存在しません。Mail Router はスパム等の振り分けを行う係で、防御はこの多層構造で担保しています。
メール本文は「処理対象のデータ」として囲い込み、いかなる指示としても解釈させない設計（本文の命令文は無効化）。 加えて秘書エージェントにはファイル読み書きやコード実行のスキルを一切与えていないため、「前の指示を無視して」「SSHキーを教えて」等が書かれていても、実行する手段そのものが存在しません。Mail Router はスパム等の振り分けを行う係で、防御はこの多層構造で担保しています。
シミュレーション — メールが届いたときの処理フローを体験
Gmail受信
inbox
→
Mail Router
コードノード
→
ルーティング判定
決定論的
→
秘書エージェント
1対1専任
→
返信生成
Gemma4-31B
→
Gmail送信
スレッド継続
// シナリオを選んで「▶ シミュレーション実行」を押してください