Message Assistant

Gmail と Backlog にまたがる未読を、毎朝 Slack の優先度リストに変換する。

複数チャネルの未読チェック → 4段階の優先度つきブリーフィングを Slack DM で受信

任せるAI難易度 2/5Bash / Claude Haiku 4.5 / Gmail API (gws CLI) / Backlog REST API / Slack Incoming Webhook

このPoCから得た実装知

1LLM に渡す前にルールベースでアーカイブ候補を除外すると、API コストと処理時間を削れる
2プロンプトインジェクション対策はシステムプロンプトの宣言だけでなく、ローカルの事前スクリーニング（jq フィルタ）と組み合わせて二重に守る
33段階バリデーション（スキーマ存在 → 値域 → ID 整合性）を入れると、LLM 出力の形式崩れによる障害を本番前に止められる
4priority_rules.json で VIP 送信者・アーカイブパターン・キーワードブーストを外部化すると、ルール変更にコード改修が不要になる
5片方のチャネル取得が失敗しても他方で続行する設計が、cron 定期実行での信頼性を担保する

判断材料

AI 権限レベル: 任せるAI
想定対象部門: 経営事業責任者プロジェクト管理
扱うデータ: Gmail 受信トレイBacklog 未読通知Slack
人間の承認: 不要（閲覧・通知のみ）
失敗時の止め方: Claude API 分類が失敗した場合、該当メッセージは全件「手動確認」扱いに自動フォールバックする。Gmail ラベル付与は本番実行時のみ適用し、DRY_RUN で副作用なしに事前確認できる
導入難易度: 2 / 5
初期導入期間: セットアップ（認証・ラベル作成）に1〜2時間、cron 設定まで含めて半日
必要な社内担当: Claude API キー保有者Gmail アカウント管理者（gws 認証）Backlog API キー発行者
連携対象 SaaS: GmailBacklogSlack
最小構成: Gmail のみ（Backlog は .env 未設定でスキップ可）
横展開先: メール優先度管理タスク通知集約朝のブリーフィング自動化

このPoCが向いている会社

以下に1つでも当てはまる会社では、効果が大きい。

Gmail と Backlog を日常的に使い、どちらも未読が積みあがりがちな経営者・事業責任者
朝のメールチェックに時間をとられ、本来の意思決定が後回しになっている
複数のプロジェクトを並走させており、対応優先度の判断自体が負担になっている
自社のルール（VIP 取引先・重要キーワード）に合わせた分類をしたいが、汎用フィルタでは限界がある

経営インパクト

Before

Gmail と Backlog を別々に開き、重要度を自分で判断しながら未読を処理する

After

Slack DM に P1〜P4 の優先度つきリストが届き、まず何をすべきかがひと目でわかる

減ったリスク: プロンプトインジェクション疑いのメッセージを AI に渡す前に分離し、隔離ラベルを付与する
横展開できる型: チャネル別取得 → 共通スキーマへの正規化 → 注入スクリーニング → ルール事前分類 → LLM 分類 → 通知、というパイプライン構造は Slack・LINE WORKS など別チャネルへの横展開に再利用できる

このデータがあれば、これができる

最小構成 ─ まずここから

INPUT DATA

▸Gmail 未読メール（直近 24 時間、最大 50 件）

YOU CAN DO

▸P1〜P4 優先度つきブリーフィングを Slack DM に送信
▸Gmail に分類ラベルを付与

発展構成 ─ ここまでつなぐと強い

INPUT DATA

▸Gmail 未読メール
▸Backlog 未読通知
▸priority_rules.json（VIP 送信者・アーカイブパターン・キーワードブースト）

YOU CAN DO

▸ルール自動分類（API 呼び出しスキップ）＋ Claude Haiku による残件分類
▸P1〜P4 の件数サマリーと詳細を Slack DM に送信
▸プロンプトインジェクション疑い件数とその差出人を Slack に表示
▸Gmail への分類ラベルおよび処理済みラベルの自動付与

Pain — どんな痛みがあったか

経営者・COOの痛み

Gmail と Backlog を朝に順番に開き、何が急ぎかを自分で判断する時間がとられる
重要な顧客メールを見落とすリスクが未読件数に比例して高まる
メルマガや自動通知が重要メールに混ざり、本当に読むべきものが埋もれる

プロジェクト管理担当の痛み

Backlog の未読通知がどのプロジェクトの何を意味するか、開いて確認するまでわからない
対応が必要なアサイン通知と参考情報の通知が混在している

Intent — なぜ作ったか

メール確認を「仕事」と認識していたが、本来の仕事は確認の先にある判断と行動だ。Gmail と Backlog を毎朝まとめて AI に渡し、優先度の判断だけを任せる。自分はリストのトップから順に動けばいい状態をつくる。

Approach — どんなアプローチか

cron で平日 7〜19 時の 90 分間隔で実行する。Gmail（gws CLI）と Backlog REST API から未読を取得し、共通の JSON スキーマに正規化したうえで結合する。jq フィルタによるプロンプトインジェクション事前スクリーニングで疑い件数を除外し、priority_rules.json のルール（VIP 送信者・アーカイブパターン・キーワード）に該当するものをルールで自動分類する。残りを Claude Haiku に 20 件バッチで送り P1〜P4 に分類させ、3 段階バリデーションで出力を検証する。結果を Slack DM に送信し、Gmail にラベルを付与する。

処理の流れ

1Gmail 未読取得（gws CLI / HOURS_BACK・MAX_MESSAGES で調整）→
2Backlog 未読通知取得（REST API）→
3共通スキーマへの正規化（チャネル差異を吸収）→
4プロンプトインジェクション事前スクリーニング（jq、18 パターン）→
5ルールベース事前フィルタ（priority_rules.json の always_archive に一致 → P4 に自動分類）→
6Claude Haiku に残件を 20 件バッチで送り P1〜P4 に分類→
73 段階バリデーション（スキーマ存在 → 値域 → ID 整合性）→
8ルール分類＋ AI 分類をマージし Slack DM に送信→
9Gmail に分類ラベルを付与（DRY_RUN 時はスキップ）

Rationale — なぜその考え方に至ったか

LLM だけに全件を渡すと明らかなメルマガも API コストになる。ルールで弾ける件数を先に除外する設計にした。プロンプトインジェクション対策はシステムプロンプトの宣言だけでは不十分で、メッセージが AI に届く前に jq でパターンマッチして除外する二重構造にした。バリデーションを入れた理由は、分類 JSON の形式が崩れたまま後段に流れるとラベル付与や Slack 通知が壊れるため。エラーが出たら止めるのではなく、手動確認扱いにフォールバックして処理を継続する設計はトリガー実行での信頼性を優先した。

Lessons — つまずきながら学んだこと

LLM 出力は形式崩れを想定してバリデーションを組む

Claude API の応答がマークダウンのコードブロックで包まれる、ID が欠落する、値域外の文字列が入るといったケースを実際に想定し、3 段階のバリデーションを実装した。バリデーション失敗時は全件「手動確認」にフォールバックし処理を継続する。

ルールと AI の役割分担が運用コストを下げる

VIP 送信者・キーワード・アーカイブパターンを JSON で外部化し、CLI（correct.sh）から追加できる設計にした。運用中に「このメルマガは毎回 P4 に落としてほしい」と感じたときにコードを触らずルールを追加できる。変更ログ（corrections.jsonl）も自動で残る。

プロンプトインジェクション対策は受信側でも持つ

メール本文に「ignore previous instructions」などのパターンや、長大な文字列（1200 文字超）、5 本以上の URL が含まれる場合はローカルフィルタで除外し、AI に渡さない。疑わしいメールには Gmail で隔離ラベルを付与する。

改善ログ（毎週改善を続けている）

2026-03-08Phase 1: Gmail + Backlog の取得・正規化・注入スクリーニング・Claude Haiku 分類・Slack 通知・Gmail ラベル付与
きっかけ: マルチチャネル未読管理の自動化ニーズ
2026-03-08priority_rules.json による VIP 送信者・アーカイブルール・キーワードブースト、ルールベース事前フィルタ（apply_prefilter.sh）、動的ユーザーコンテキスト生成（build_user_context.sh）、ルール管理 CLI（correct.sh）
きっかけ: API コスト削減とカスタムルール管理の要望

Approach / Rationale / Lessons / 改善ログの続きを読む

Magic Link で 60 秒。クレカ不要・退会即時。

最初の1週間でやること

DRY_RUN モードで実行し、分類結果を標準出力で確認する
priority_rules.json に自社の VIP 取引先メールアドレスを登録する
アーカイブさせたいメルマガ送信者を correct.sh --archive で追加する
cron を平日朝 7 時に設定し、Slack DM でブリーフィングを受け取る

やらないこと

Gmail への書き込み（送信・削除）は行わない。ラベル付与だけ
Backlog へは読み取り専用で、チケットの更新は行わない
AI に渡す前に注入スクリーニングで除外するため、メール本文が LLM に無制限に届く設計にしない

費用対効果の考え方

毎朝の Gmail + Backlog チェックにかかる確認・判断時間の削減
重要メールの見落とし防止（P1 は即返信・P2 は本日中のアクションが明示される）
プロンプトインジェクション疑いの自動隔離による誤操作リスクの低減

このPoCの位置づけ

シェルスクリプト × Claude API で作るマルチチャネル優先度フィルタの実装事例

毎朝の未読チェックを、優先度つきのブリーフィングに変える。インフラは cron とシェルスクリプトだけ。

導入前チェックリスト

商談前に、自社側でこの 4 点を確認しておくと検討がスムーズに進む。

Gmail と Backlog のどちらを使っているか、両方か？
Backlog は .env を空にすればスキップできる。Gmail だけでも動作する
Claude API キーと Slack Incoming Webhook URL を発行できるか？
どちらも必須。Anthropic Console と Slack アプリ管理画面で取得する
macOS に gws（Google Workspace CLI）をインストールし、gmail.modify スコープで認証できるか？
Gmail の未読取得とラベル付与に必要。brew install gws で導入できる
VIP 取引先や優先プロジェクトのパターンを priority_rules.json に登録できる担当者がいるか？
コード変更不要で correct.sh から追加できる