問い合わせメールは、受信、仕分け、担当通知、返信下書きまでは自動化しやすい業務です。ただし、価格、納期、契約、苦情、個人情報を含む返信を、最初から自動送信にしません。AIが作るのは回答候補であり、根拠が足りないメールを人へ戻す経路と、送信前の承認を先に作ります。
17時50分、代表アドレスへ「明日の納品に間に合わないなら契約を見直す」というメールが届いたとします。本文には注文番号がなく、添付された写真にだけ製品ラベルが写っています。「納期問い合わせ」と分類できても、回答に必要な受注情報は足りません。この場面で正しい自動化は、それらしい納期を返すことではなく、緊急キューへ置き、当番へ通知し、確認すべき項目を下書きに示すことです。
問い合わせメールは、どこまで自動化できるのか？
受信、分類、情報取得、返信下書き、担当通知までをつなぎ、外部送信は承認後から始めます。
メール自動化を「AIが返信するか」で二択にしません。仕事を六段階に分け、段階ごとに権限を決めます。
| 段階 | 自動化する処理 | 最初の運用 |
|---|---|---|
| 受信 | 対象メールを取得し重複を除く | 自動 |
| 仕分け | 用件、緊急度、担当候補を付ける | 自動、低確信は共通キュー |
| 根拠取得 | FAQ、価格表、顧客台帳を検索する | 閲覧のみ |
| 下書き | 根拠を添えて返信候補を作る | 自動 |
| 承認 | 宛先、本文、添付、根拠を確認する | 人 |
| 送信・記録 | 送信し、担当と履歴を台帳へ残す | 承認後に自動 |
GoogleのGmail APIは、メッセージやスレッドの取得、ラベル変更、下書き作成、既存下書きの送信を別の操作として提供しています。技術上も「下書きを作れる」と「送信できる」は別権限です。利用中のメール製品でも同じ分離ができるかを確認します。
まず仕分ける用件は、どう決めるのか？
現在の担当表と期限から少数の用件を決め、複数用件と判断材料不足を別枠で残します。
最初に過去メールを眺めてAIへ自由な分類名を作らせるのではなく、社内の行き先から分類を決めます。
| 用件 | 担当候補 | 期限の基準 | 人へ戻す例 |
|---|---|---|---|
| 新規相談 | 営業 | 営業時間内の一次確認 | 対応地域やサービスが不明 |
| 見積・価格 | 営業、管理 | 有効な価格表を確認 | 個別値引き、旧価格の引用 |
| 納期・在庫 | 受注、物流 | 希望日を確認 | 注文番号なし、緊急 |
| 契約・請求 | 管理、経理 | 締日と契約を確認 | 解約、返金、法的主張 |
| 不具合・苦情 | サポート、責任者 | 緊急度を判定 | 安全、人身、重大障害 |
| 採用・営業連絡 | 人事、確認不要 | 社内方針に従う | 本来の顧客相談が混在 |
| 判断材料不足 | 共通キュー | 確認者へ通知 | 本文なし、添付のみ、複数用件 |
一通に「請求書を再送してほしい。来月から解約もしたい」と書かれていれば、請求と解約の両方です。一つへ押し込まず、主担当と確認先を二つ持たせます。分類名を増やすより、迷った時の共通キューを機能させるほうが先です。
返信下書きは、何を根拠に作るのか？
承認済みFAQ、最新版の規程、価格表、顧客・案件情報だけを検索し、根拠を下書きへ添えます。
学習済みモデルの一般知識だけで、自社の価格や納期は答えられません。参照先ごとに管理者、更新日、有効期間を持たせます。
| 返信内容 | 参照するもの | 下書きに表示する確認情報 |
|---|---|---|
| サービス説明 | 公開ページ、承認済みFAQ | 参照ページと更新日 |
| 価格 | 現行価格表、見積条件 | 版、有効期限、個別条件 |
| 納期 | 受注台帳、在庫、配送条件 | 注文番号、在庫時刻、確約可否 |
| 契約 | 締結済み契約、社内規程 | 契約版、担当者、要確認箇所 |
| 顧客固有の回答 | CRM、過去スレッド | 顧客ID、案件、最終対応 |
根拠が見つからないときは、文章を埋めません。「注文番号を確認してください」「契約担当者の判断が必要です」と、不足している情報を下書きへ出します。古い価格表を検索対象から外す仕組みも、モデル調整より先に必要です。
自動送信へ進めてよいのは、どんなメールか？
定型で根拠が一つに定まり、誤送信の影響が小さく、直ちに止められる返信だけに限定します。
自動送信の候補は、受付通知、営業時間案内、資料受領の連絡などです。それでも宛先、差出人、スレッド、添付、重複送信を機械的に検査します。
次を含むメールは、人が承認します。
- 金額、値引き、返金、支払い条件
- 納期、在庫、サービス水準の確約
- 契約変更、解約、法的な主張
- 苦情、安全、事故、重大な障害
- 個人情報や機密情報を含む添付
- 複数の担当部署にまたがる相談
- 過去の回答と矛盾する可能性がある内容
- AIが根拠を特定できない内容
承認者が休暇中なら、自動送信へ切り替えません。副承認者へ回すか、受付通知だけを送り、回答期限を社内へ通知します。承認待ちの滞留を見えるようにすることも自動化の一部です。
添付ファイルと転送メールは、どう扱うのか？
許可形式、隔離、容量、暗号化、引用範囲を決め、読めない添付は本文だけで回答しません。
添付には注文書、名刺、診断書、履歴書、契約書、実行ファイルなどが混ざります。画像やPDFを読める仕組みでも、すべてを生成AIへ渡してよいわけではありません。
実装前に次を決めます。
- 読み取るファイル形式と最大容量
- パスワード付き、破損、未知形式の戻し先
- マルウェア検査と隔離場所
- 本文へ引用してよい項目
- 保存期間と削除方法
- 転送履歴に含まれる第三者情報の扱い
- 添付を読めなかったことを下書きへ表示する方法
添付だけ届いたメールを「内容不明」と分類できても、勝手にファイル内容を要約して外部へ返しません。まず送信者へ用途を確認するか、担当者へ回します。
個人情報を生成AIへ渡す前に、何を確認するのか？
利用目的、入力範囲、保存、学習利用、再委託、権限、削除を確認し、不要な情報は渡しません。
問い合わせメールには、氏名、メールアドレス、電話番号、署名、注文履歴、健康や採用に関する情報が入ります。本文全体をそのまま外部の生成AIサービスへ貼り付ける運用は避けます。
個人情報保護委員会の生成AIサービスに関する注意喚起は、個人データを入力する際、生成AIサービス提供者が機械学習へ利用しないことなどを十分確認するよう求めています。契約、管理設定、データ処理地域、保持期間を確認し、目的に不要な署名や過去履歴はマスキングします。
「学習されない」だけで安全が決まるわけではありません。メールへアクセスできるサービスアカウント、管理者、開発会社、ログ保管先を一覧にし、退職や委託終了時に権限を外します。
誤分類や誤返信を、どう止めるのか？
禁止条件、確信不足、件数急増、連携失敗を検知し、送信権限を外して人のキューへ戻します。
停止条件は、AIが「自信がない」と言った時だけでは足りません。次を機械的に監視します。
| 停止条件 | 動作 | 通知先 |
|---|---|---|
| 禁止語や重大用件 | 下書きのみ、外部送信しない | 業務責任者 |
| 根拠文書なし・期限切れ | 不足情報を表示して保留 | 情報管理者 |
| 宛先や顧客IDの不一致 | 送信と台帳更新を止める | 担当者 |
| 同一スレッドの二重処理 | 後続処理を止める | 運用担当 |
| メール・CRM API障害 | 再送せず結果不明キューへ置く | システム担当 |
| 通常を超える処理集中 | 自動送信を停止する | 業務責任者 |
AISIのAIセーフティに関する評価観点ガイド第1.20版は、AIエージェントの自律的な挙動と外部環境との相互作用について、観測と制御を評価観点に加えています。文章だけでなく、どのメールを読み、何を検索し、送信や更新を試みたかを追える状態にします。
監査ログには、何を残すのか？
受信ID、分類、根拠、下書き、修正、承認、送信結果、失敗と再処理を一続きで残します。
最低限、次を一つの処理IDで結びます。
- 対象メールとスレッドのID
- 受信時刻、処理時刻、担当候補
- 分類結果と人が直した分類
- 参照したFAQ、価格表、顧客情報の版
- AIの下書きと人が修正した箇所
- 承認者、承認時刻、送信権限
- 宛先、送信結果、メール側のID
- 連携失敗、再処理、手動対応
メール本文や個人情報を必要以上に複製しません。ログの閲覧権限、保持期間、削除、調査時の取り出し方も決めます。Gmail APIにはメールボックスの変更履歴を取得する機能がありますが、自社の承認判断や参照根拠は別途記録が必要です。
導入前に、社内では何を決めるのか？
対象窓口、分類、期限、参照資料、承認者、禁止返信、停止条件、ログ責任者を決めます。
代表アドレス、サポート、採用など、窓口ごとに目的と扱う情報が違います。最初は一つの窓口、一つの担当チームに絞ります。
社内で決める項目は次のとおりです。
- 対象メールアドレスと除外フォルダ
- 用件の分類、担当、一次対応期限
- 正式なFAQ、価格表、契約、顧客情報
- 下書きまでと自動送信の境界
- 通常承認者、副承認者、営業時間外の扱い
- 絶対にAIへ入力しない情報
- 誤送信、苦情、API障害の停止と連絡
- ログを確認する人と頻度
正解が部署ごとに違うなら、AI導入前に担当表を決めます。未返信が多い原因が承認者一人への集中なら、返信生成より承認経路の変更が効くこともあります。
開発会社へは、何を渡せばよいのか？
匿名化した実例、担当表、回答根拠、例外、権限、停止条件と受入シナリオを渡します。
成功した短い問い合わせだけでなく、次の実例を個人情報を除いて用意します。
- 本文なしで添付だけ届いたメール
- 一通に複数の用件があるメール
- 旧価格を引用した再問い合わせ
- 期限を過ぎた未返信メール
- 苦情と通常質問が混在するメール
- 承認者が不在の時間帯
- CRMに顧客が二重登録されているケース
- API送信後に結果を取得できないケース
成果物には、分類表、権限一覧、参照データ一覧、プロンプトだけでなく、テスト結果、誤りの分類、承認画面、監視、停止手順、ログ、削除手順を含めます。受入テストは誰が何を確認するかを先に決めます。
一次情報は、どの資料を確認したか？
メールAPI、個人情報、AIエージェントの制御、組織の運用責任を扱う一次資料を確認しました。
- Google for Developers「Gmail API」
- Google for Developers「Create and send draft emails」
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」
- AISI「AIセーフティに関する評価観点ガイド（第1.20版）」
- 経済産業省「AI事業者ガイドライン（第1.2版）」
Gmail APIは実装可能な操作の一例であり、他社メール製品へ一般化していません。実際の権限、監査、データ保持は、利用中のサービスと契約プランで確認します。
関連記事と相談先は、どこから確認できるか？
権限設計、PoCの終了条件、受入テスト、要件整理を往復し、対象窓口を絞って相談できます。
- AIエージェントにどこまで権限を渡してよいか？
- AIエージェントのPoCをいつ終える？
- システム開発の受入テストは誰が何を確認する？
- 要件書がなくてもシステム開発を相談できるか？
- AI開発・業務自動化
- お問い合わせ
Heygoodは、返信文を作るデモだけでは完成と考えません。メールの取得、根拠、例外、承認、送信、記録を一続きで確認し、まず下書きまでで運用します。自動送信へ進む理由が足りなければ、分類と担当通知だけを残す判断も含めて相談できます。