ここにある制限はすべて恒久的で、設計によるものです。どれもバグではなく、 早く知っていれば設定のやり方を変えられます。
特定の 1 通のメールに答えなかった、という話なら、それは制限ではなく診断です: AI が返信しなかった理由。
接続の時点で始まる。履歴はない。
メールボックスを接続すると、新しいメールの監視が始まります。接続より前の ものは取り込まれず、あとから何をしても遡って埋めることはできません。
実務上の帰結: カバーしたい期間の前に接続すること。金曜に接続したメールボックスは、 木曜のことを何も知りません。それより前の文脈を与える唯一の方法が ナレッジベースです。
それを通して出ていった返信しか数えない
プラットフォームが記録するのは、自分が送った外向きのメールです。同僚が Gmail や Outlook で打った返信は、実在の顧客への実在の返事なのに、ここでは数えられず、 スレッドは待ち状態に見え続けることがあります。
2 つのプロバイダーの失敗の仕方は違って、どちらももう片方と同じだと言うのは 危険です。Gmail では監視が受信トレイの上に置かれているので、その返信は こちらに届きさえしません。Outlook では送信済みアイテムのサブスクリプションが 届けてはくるのに、スレッドはそれでも返信済みと印を付けられません。
だからここでの「返信なし」は常に 自分に見える最後のメッセージは相手のもの という意味であって、あなたはこの人に返信を負っている という意味では決して ありません。
Gmail では受信トレイしか見えない
監視は特に INBOX の上に置かれます。受信トレイを素通りするメール — ラベルに
直行するフィルタや、到着即アーカイブ — は見えません。強めのフィルタを
運用しているなら、いちばん処理してほしいメールが、届かないメールなのかも
しれません。
指示はメールボックスではなく、エージェントのもの
チャネルごとの指示はありません。エージェントに伝えたことは、そのエージェントが 答えるどこでも適用されます。指示の言葉で自分の適用範囲を狭めることはできます — “support@ のメールに答えるときは…” — が、それは設定が強制するものではなく、 モデルへの頼みごとです。
本当に違う振る舞いが要る 2 つのメールボックスには、違うエージェントが要ります。
指示では、下書きが書かれるのを止められない
最初に試したくなるのがこれで、見た目のようには動きません。エージェントに “マーケティングメールには返信するな” と言っても、返信の言い回しが 変わるだけで、存在するかどうかは変わりません。プロンプトが下書きを生まない 唯一の道は、モデルが 0 文字を出力することで、静かにいろと言われたモデルは たいてい丁寧な断りを書く — それが下書きになります。
実際に返信を止めるものは決定論的で、モデルが走る前のコードの中にあります:
自分を自動送信と名乗るメールは落とされ、no-reply アドレスからのメールは
表示されるだけで、決して下書きされません。これらはフィルタであって指示ではなく、
メールボックスごとに設定できるものでもありません。
下書きはどこにでもあるわけではない
ほとんどのメールボックスでは、保留中の返信はプロバイダの下書きフォルダにも 書き込まれます。Microsoft 365 グループ ではそうなりません — Graph にはグループ会話用の下書き API がないので、 ダッシュボードにしか住みません。
下書きごとの確信度スコアもありません。トリアージが印を付けるか、付けないかで、 モデルがどれだけ確信していたかを評価するものはなく、それがあるように見せる インターフェースは捏造していることになります。
未設定の返信モードは自律を意味する
保存されたモードが欠けていたり認識できなかったりすると、フォールバックは 自律 — AI が送ります。どちらの失敗のほうが悪いかについての意図的な選択で、 空の欄は「何もしない」を意味すると仮定するより、既定を明示的に設定するほうが 良いということです。
配信は私たちのものではない
ここから送られた返信が届かなかったなら、それは SPF、DKIM、あなたのドメインの 評判、または受信側のスパムフィルタです。それらはメールプロバイダと DNS の 側にあります。このプロダクトはそれらを管理せず、監視せず、報告もせず、 メッセージがスパムと判定されたことを伝えるものもここにはありません。