メールの宛先と添付を送信前に点検して、誤送信を止める

処理の起点を決める

トリガーを3つに分けることが、この構成の設計の核です。

送信時にLLMを呼ばないでください。

Smart Alerts のアドインは、短時間・軽量であるべきとされています。処理が5秒を超えると「時間がかかっている」という画面が出て、送信モードの設定によっては利用者が「そのまま送信」を選べてしまいます。 5分を超えるとタイムアウトします。

Microsoft のドキュメントでも、送信イベントのハンドラに重い検証を詰め込まず、他のイベントで事前に処理することが推奨されています。

送信モードの選び方。

Smart Alerts には、条件を満たさなかったときの挙動を決める「送信モード」が3つあります。

block を選ぶと、Microsoft Marketplace には公開できず、組織の管理者が展開する必要があります。 社内利用であれば問題ありません。

既定は soft block にし、条件を絞ってください。 すべての社外メールを止める設定にすると、利用者が「そのまま送信」を押すのが習慣になります。

なお、送信モードは実行時に上書きできます（Mailbox requirement set 1.14 以降）。危険度に応じて、注意喚起と強制を切り替える設計が取れます。

入力データを集める

「顧客ドメイン台帳」が、この構成の前提です。 どのドメインがどの顧客企業かが分からないと、「複数の顧客が宛先に混在している」ことを検出できません。1,200社分のドメインを整備する作業が、最初の関門です。

「送信履歴」も重要です。 その送信者が過去に一度も送ったことのないドメインへの送信は、注意すべき合図です。類似ドメインへの誤送信（1文字違い）を拾えます。

データの取得方法を決める

メールの内容： Outlook アドインから Office.js のAPIで取得します。本文全体を取得できますが、判定に必要な範囲に絞ってください。

添付ファイル： ファイル名・サイズ・種類は取得できます。中身の取得は、サイズと処理時間の制約があります。 添付が変わったタイミングで、必要なものだけ中身を読みます。

分類ラベル： Microsoft Purview の秘密度ラベルが設定されていれば、それを使います。ラベルの運用がない場合は、この構成の効果が大きく下がります。 ラベルの整備を先に行うことを推奨します。

顧客ドメイン台帳： 顧客管理システムからエクスポートし、判定サービス側に持ちます。日次の更新で足ります。

AIへ渡す前に整形する

ここでいう前処理は、送信の瞬間より前に行う下ごしらえです。

宛先が変わったとき：

1. 各宛先を「社内」「顧客A」「顧客B」「未知のドメイン」に分類する
2. TO・CC に複数の顧客企業が含まれていないかを確認する
3. その送信者が過去に送ったことのないドメインを特定する
4. 似たドメイン（1〜2文字違い）が顧客台帳にないかを確認する

添付が変わったとき：

1. 添付の分類ラベルを確認する
2. ファイル名から、対象の顧客を推定する
3. 添付の中身の要点を抽出する（LLMを呼ぶのはここ）
4. 個人情報が含まれそうかを判定する

送信の瞬間は、これらの結果を照合するだけにします。

AIに処理させる

ルールで書けることは、プログラムで判定します。

これらにLLMを使う理由はありません。 速く、確実で、根拠が明確です。

LLMにさせること（添付が変わったタイミングで実行）：

「本文に出てくる社名と、宛先の顧客が違う」は、ルールでは書きにくく、LLMが効く典型です。 「株式会社◯◯様の賃金台帳をお送りします」と書いて、宛先が別の会社、というケースを拾えます。

LLMに「送ってよいか」を判断させないでください。 出すのは「本文には◯◯社とありますが、宛先は△△社です」という事実です。送るかどうかは送信者が決めます。

指示内容を固定する

あなたは、メールの送信前の点検を支援する担当者です。
本文と添付と宛先の整合を確認してください。

【厳守事項】
- 送ってよいかどうかを判断しないでください。
  「送信を中止してください」「問題ありません」と書かないでください。
  食い違っている事実だけを示してください。
- 本文と添付と宛先のうち、どれが正しいかを決めないでください。
  「本文の社名が誤りです」と書かないでください。
- 添付の中身について、要約以上のことを書かないでください。
  個人の氏名、金額、健康に関する記載を、指摘文に転記しないでください。
  「個人情報を含む書類です」とだけ書いてください。
- 本文に社名が出てこない場合は、宛先との照合を行わず、
  company_in_body を null にしてください。
  「おそらく〇〇社宛てと思われます」と推測しないでください。
- 指摘文は、下記の制約に従ってください。
  ・1つの指摘は60文字以内
  ・何が、何と食い違っているかを具体的に書く
  ・「確認してください」だけの指摘を作らない
- 添付が複数ある場合は、それぞれについて別の指摘にしてください。
- 送信者の注意力や過去の誤りについて言及しないでください。

【宛先（分類済み）】
{recipients_classified}

【件名】
{subject}

【本文】
{body}

【添付ファイルの情報（要点のみ）】
{attachments_summary}

【顧客ドメイン台帳の該当行】
{customer_domains}

「送ってよいかどうかを判断しない」の1行が重要です。 これを書かないと「このまま送信して問題ありません」という出力が出ます。それを見た送信者が確認を省きます。

「個人の氏名、金額、健康に関する記載を指摘文に転記しない」も必ず入れてください。 指摘のダイアログは画面に表示され、記録にも残ります。そこに個人情報を書くと、防ごうとしている漏えいを自分で起こすことになります。

「1つの指摘は60文字以内」の制約は、表示の都合です。 Smart Alerts のダイアログに表示できるメッセージは500文字以内とされています。複数の指摘を並べるため、1件を短くします。

出力形式を固定する

下ごしらえ（プログラム＋LLM）の出力：

{
  "draft_id": "",
  "prepared_at": "",
  "recipients": [
    {
      "address_hash": "",
      "domain": "",
      "classification": "internal | customer | unknown | similar_to_customer",
      "customer_name": "",
      "sent_before": true
    }
  ],
  "rule_findings": [
    {
      "type": "multiple_customers | label_blocked | unknown_domain | similar_domain | to_should_be_bcc | unencrypted",
      "severity": "block | soft_block | prompt",
      "detail": ""
    }
  ],
  "llm_findings": [
    {
      "type": "body_vs_recipient | body_vs_attachment | attachment_missing | attachment_customer_mismatch",
      "message": "",
      "company_in_body": "",
      "company_in_recipient": "",
      "attachment_name": ""
    }
  ],
  "contains_personal_data": false,
  "prepared_complete": true
}

送信時（アドイン）の判定：

{
  "send_mode": "block | soft_block | prompt",
  "dialog_message": "",
  "findings_shown": [],
  "prepared_complete": true
}

prepared_complete を持つのは、下ごしらえが終わっていない状態を区別するためです。宛先や添付を変えた直後に送信ボタンを押すと、下ごしらえが間に合わないことがあります。その場合は「確認できていません」と伝え、送信モードは prompt にします。 止めてはいけません。

address_hash（メールアドレスのハッシュ）を持ち、アドレスそのものを記録に残さない設計にできます。 ドメインは残し、ローカル部は残さない、という選択もあります。

なお、Claude API には出力をJSONスキーマに沿わせる構造化出力の機能があります（2026-09-16時点ではベータ機能として提供）。件数が多く機械処理なので、利用できると安全です。

システムへ連携する

送信を自動でキャンセルしないでください。 送信モードで制御し、利用者が明示的に「送らない」を選ぶ形にします。 黙って送信が消えると、利用者は何が起きたか分かりません。

対応クライアントに注意してください。 Smart Alerts は、Outlook on the web（モダンUI）、新しい Outlook on Windows、クラシック Outlook on Windows（Version 2206 以降）、Outlook on Mac（Version 16.65 以降）で動作します。Android と iOS では動作しません。 モバイルからの送信は、この構成の対象外になります。

人が確認する

判定は自動ですが、修正するかどうかは必ず送信者が決めます。

送信モードの使い分けは次のとおりです。

「そのまま送信」を選んだ記録を必ず残し、月次で集計してください。

同じ指摘に対して「そのまま送信」が続いているなら、その判定は誤検知です。 条件を見直します。この集計をしないと、警告が形骸化していることに気づけません。

例外に対処する

記録を残す

• 指摘の内容と、そのときの送信モード
• 送信者の選択（修正した／そのまま送った／送らなかった）
• 判定に使ったルールと、その根拠
• 下ごしらえが未完了だった件数
• 処理時間（5秒を超えた件数）
• 月次の集計（指摘の種類別の件数、「そのまま送信」の割合）

メールの本文と添付の中身を記録に残さないでください。 判定のために一時的に読むことと、記録として保管することは別です。保管すれば、そのログ自体が新しい漏えいの対象になります。

「そのまま送信」の割合が、この構成の健全性の指標です。 種類別に見て、8割を超える指摘は誤検知として扱ってください。