本文へスキップ

AI運用の判断と根拠を引く

Enterprise AI運用辞典

トップへ戻る

Email Agentの安全な運用

用語・参照用語・参照公式仕様のみ公式仕様のみ鮮度未確認鮮度を確定できない

記事状態: 公開 · 最終確認: 未確認

要点

「Gmail APIはmessages.sendとdrafts.sendを別個のメソッドとして提供しているため、下書き作成→検査→明示的な承認→送信という制御点を設計できる。ただし、APIの存在は宛先の正確性、承認、DLP（データ漏洩防止）、法的適合性、送信後の回収を保証するものではない。」

現在の判断

Gmail APIは、直接送信（send）と下書き経由の送信（draft経由send）を別のメソッドとして公開しており、MIMEメッセージと添付ファイルの作成を要求します。これにより、「生成→検査→承認→送信」というプロセスを技術的に別々の段階として配置する設計は可能ですが、APIの仕様自体は「人間が承認したこと」「宛先が正しいこと」「添付ファイルが安全であること」「本文に機密情報が含まれていないこと」を保証するものではありません。RFC 2822はInternet Message Formatの構文を定義するものであり、添付ファイルなどはMIME拡張側の役割です。宛先の判断、業務上の承認、およびプライバシー法への準拠は、これとは別の層の問題です。

どこまで当てはまるか

アプリケーション / 相互運用性 / 組織オーバーレイ / セキュリティ / 監査

詳しく理解する

なぜ重要か

メールエージェントは、誤送信、返信スレッド、添付ファイル、機密情報、送信の不可逆性が一つのツール呼び出しに重なるため、下書き（draft）と送信（send）を分離した、証拠能力のある運用が必要です。

対象範囲と前提

アプリケーション / 相互運用性 / 組織オーバーレイ / セキュリティ / 監査

検討ポイント

Gmail API上でdraft生成と送信が別操作であることは確認できるか。それは人間承認・宛先安全・機密漏えい防止を保証するか。

根拠資料の対応表

  • 出典区分: 公式APIドキュメント; 正式名称: Create and send email messages; 著者/組織: Google for Developers; 正式なURL: https://developers.google.com/workspace/gmail/api/guides/sending 公開/更新/アクセス: 現在のページに2026-09-13 JSTにアクセス; バージョン/リリース/タグ/コミット/API改訂版/モデルID: Gmail API v1 resource/methods messages.send および drafts.send; 参照先: 93-105行目（messages.sendとdrafts.sendの直接的な2つの経路、未加工のMIME/base64URL）; 205-240行目（下書き作成サンプル）; 264-266行目、303-369行目（添付ファイルを含む下書き例）; 証拠ラベル: 検証済み仕様 + 製品の流動性あり; 関係: 支持 / 制限
  • 資料の種類: standards-track protocol; 原資料の題名: RFC 2822: Internet Message Format; 著者・組織: P. Resnick, editor / IETF Network Working Group; 原資料の正式なURL: https://www.rfc-editor.org/rfc/rfc2822 publication/update/access: 2001-04, now obsolete and 置換済み by RFC 5322 / 参照日 2026-09-13 JST; バージョン/公開・提供/tag/commit/API 改訂版/モデル ID: RFC 2822; 裏付ける該当箇所: info page lines 48-65, 82-89, 185-209（message 構文 and 適用範囲）; lines 193-201（MIME extensions are outside this RFC）; 根拠の分類: VERIFIED_SPEC + PRODUCT_VOLATILE; 対応関係: 文脈・入力情報 / limit.

利用できる条件

OAuth 適用範囲、ユーザー/ドメイン管理、Gmail API 利用枠、送信権限、外部recipient制限、DLP/情報分類、提供元の契約を確認する必要がある。実アカウントで送信・draft作成は未実施。

実装・運用

proposed two-phase mail agent（draft-only default、recipient/attachment/content lint、explicit 承認 token、send endpoint分離、post-send 監査）。実装・安全性試験未実施。

確認・評価方法

合成メールボックスのテスト用環境（fixture）を用いて、受信者の正確性、返信ヘッダー、添付ファイルのハッシュ値/名称、機密マーカーの取り扱い、承認バイパス、および重複送信/リトライ時の同じ要求の再送で処理を重複させない仕組み（重複実行を防ぐ性質）を測定する。実際の送信は行わない。

セキュリティとプライバシー

セキュリティ/プライバシー: 機密情報/個人を特定できる情報（PII）は人工的に作った文書群のみを使用し、DLP（データ漏洩防止）の事前確認を行う。監査: 下書きID、コンテンツハッシュ、受信者、承認者/承認時刻、送信結果、プロバイダーのメッセージID。コスト: APIの割り当て（利用枠）と人による確認の工数。運用管理・統制: 送信をデフォルトで拒否（fail closed）とし、失敗時に自動リトライせず下書き状態に戻す。

確認できていること

  • Gmail APIは、直接送信（send）と下書き経由の送信（draft経由send）を別のメソッドとして公開しており、MIMEメッセージと添付ファイルの作成を要求します。これにより、「生成→検査→承認→送信」というプロセスを技術的に別々の段階として配置する設計は可能ですが、APIの仕様自体は「人間が承認したこと」「宛先が正しいこと」「添付ファイルが安全であること」「本文に機密情報が含まれていないこと」を保証するものではありません。RFC 2822はInternet Message Formatの構文を定義するものであり、添付ファイルなどはMIME拡張側の役割です。宛先の判断、業務上の承認、およびプライバシー法への準拠は、これとは別の層の問題です。

よくある失敗・反証

  • RFC 2822 は廃止されており、現行の RFC 5322 への更新が必要である。Gmail API の公開ドキュメントは、特定の組織の利用環境における管理者ポリシー、DLP、送信後の取り消し、実際のUI警告を証明するものではない。誤返信、Bcc、エイリアス、スレッド、添付ファイルの差異、外部受信者、代理送信は、別の失敗クラスに分類される。

  • draft作成成功を安全な送信成功と扱わない。公開API Docsから特定組織の設定・実挙動を推定しない。 UNIT_CLOSE_STATUS: INDIVIDUAL_BOUNDED_CLOSE / EVIDENCE_RECORDED / UNKNOWN_PRESERVED

    ---

実務での使い方

  • OAuth 適用範囲、ユーザー/ドメイン管理、Gmail API 利用枠、送信権限、外部recipient制限、DLP/情報分類、提供元の契約を確認する必要がある。実アカウントで送信・draft作成は未実施。

  • proposed two-phase mail agent（draft-only default、recipient/attachment/content lint、explicit 承認 token、send endpoint分離、post-send 監査）。実装・安全性試験未実施。

  • 合成メールボックスのテスト用環境（fixture）を用いて、受信者の正確性、返信ヘッダー、添付ファイルのハッシュ値/名称、機密マーカーの取り扱い、承認バイパス、および重複送信/リトライ時の同じ要求の再送で処理を重複させない仕組み（重複実行を防ぐ性質）を測定する。実際の送信は行わない。

  • セキュリティ/プライバシー: 機密情報/個人を特定できる情報（PII）は人工的に作った文書群のみを使用し、DLP（データ漏洩防止）の事前確認を行う。監査: 下書きID、コンテンツハッシュ、受信者、承認者/承認時刻、送信結果、プロバイダーのメッセージID。コスト: APIの割り当て（利用枠）と人による確認の工数。運用管理・統制: 送信をデフォルトで拒否（fail closed）とし、失敗時に自動リトライせず下書き状態に戻す。

  • 本文改訂では、agentの自然言語能力よりもsend 利用可能な機能、OAuth 適用範囲、管理者/DLP、draft-only、承認 根拠、重複実行を防ぐ性質を表にする。RFC 5322とMIMEの現行一次資料を再採集し、提供元ごとのalias/thread挙動をTEST_PROFILE化する。

まだ確認できていないこと

  • EA-113-UNKNOWN-01

    RFC 5322の準拠範囲、Gmailの組織の利用環境ごとのDLP/外部送信設定、返信/エイリアス/Bccにおけるエージェントの失敗率、送信取消の可能性、および他のプロバイダーとの差異。

  • EA-113-UNKNOWN-CURRENTNESS

    外部根拠の再確認日が正式な本文・公開管理情報で確定していないため、現行性は未確認のまま保持する。確認日を推測して補わない。

根拠資料

出典ID・検証情報・機械可読データ

根拠の種類と情報の鮮度は、ラベルとアイコンで確認できます。

記事ID
EA-113
最終確認日
—
提供元・モデル・プラン・利用環境
—
対象地域
—
元資料の全文と収録照合記録
WHY_THIS_MATTERS_TO_UPDATE

email agentは誤宛先、reply thread、添付、機密情報、送信の不可逆性が一つのtool callに重なるため、draftとsendを分離した証拠可能な運用が必要。

SCOPE_ROUTING

application / interoperability / organization overlay / security / audit

CLAIM_OR_RESEARCH_QUESTION

Gmail API上でdraft生成と送信が別操作であることは確認できるか。それは人間承認・宛先安全・機密漏えい防止を保証するか。

EVIDENCE TABLE
  • source class: official API documentation; exact title: Create and send email messages; author/org: Google for Developers; canonical URL: https://developers.google.com/workspace/gmail/api/guides/sending publication/update/access: current page accessed 2026-09-13 JST; version/release/tag/commit/API revision/model ID: Gmail API v1 resource/methods messages.send and drafts.send; supporting locator: lines 93-105（direct messages.sendとdrafts.sendの二経路、raw MIME/base64URL）; lines 205-240（draft作成sample）; lines 264-266, 303-369（attachmentを含むdraft例）; evidence label: VERIFIED_SPEC + PRODUCT_VOLATILE; relation: support / limit.
  • source class: standards-track protocol; exact title: RFC 2822: Internet Message Format; author/org: P. Resnick, editor / IETF Network Working Group; canonical URL: https://www.rfc-editor.org/rfc/rfc2822 publication/update/access: 2001-04, now obsolete and superseded by RFC 5322 / accessed 2026-09-13 JST; version/release/tag/commit/API revision/model ID: RFC 2822; supporting locator: info page lines 48-65, 82-89, 185-209（message syntax and scope）; lines 193-201（MIME extensions are outside this RFC）; evidence label: VERIFIED_SPEC + PRODUCT_VOLATILE; relation: context / limit.
FINDINGS

Gmail APIは直接sendとdraft経由sendを別methodとして公開し、MIME messageとattachmentの作成を要求する。これにより、生成→検査→承認→送信を技術的に別段階へ配置する設計は可能だが、API仕様は「人間が承認した」「宛先が正しい」「添付が安全」「本文が秘密を含まない」ことを保証しない。RFC 2822はInternet Message Formatのsyntaxで、添付等はMIME extension側であり、宛先判断・業務承認・privacy lawは別層である。

LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE

RFC 2822はobsoleteであり、現行のRFC 5322へ更新が必要。Gmail APIの公開Docsは特定tenantのadmin policy、DLP、送信後recall、実際のUI警告を証明しない。誤reply、Bcc、alias、thread、添付版違い、外部recipient、代理送信は別failure class。

AVAILABILITY_GATES

OAuth scope、ユーザー/ドメイン管理、Gmail API quota、送信権限、外部recipient制限、DLP/情報分類、providerの契約を確認する必要がある。実アカウントで送信・draft作成は未実施。

IMPLEMENTATION_STATE

proposed two-phase mail agent（draft-only default、recipient/attachment/content lint、explicit approval token、send endpoint分離、post-send audit）。実装・安全性試験未実施。

BENCHMARK_OR_EVAL

synthetic mailbox fixtureでrecipient exactness、reply headers、attachment hash/name, confidential-marker handling, approval bypass, duplicate send/retry idempotencyを測る。実送信はしない。

SECURITY / PRIVACY / AUDIT / COST / OPERABILITY

SECURITY/PRIVACY: secrets/PIIはsyntheticのみ、DLP preflight。AUDIT: draft ID、content hash、recipient、approval actor/time、send result、provider message ID。COST: API quotaとhuman review工数。OPERABILITY: sendをdefault denyにし、失敗時に自動retryせずdraftへ戻す。

SAFE_WORDING_FOR_FUTURE_BOOK

「Gmail APIはmessages.sendとdrafts.sendを別methodとして提供するため、draft→検査→明示承認→sendという制御点を設計できる。ただし、APIの存在は宛先正確性、承認、DLP、法的適合、送信後回収を保証しない。」

UPDATE_WORK_HANDOFF

本文改訂では、agentの自然言語能力よりもsend capability、OAuth scope、admin/DLP、draft-only、approval evidence、idempotencyを表にする。RFC 5322とMIMEの現行一次資料を再採集し、providerごとのalias/thread挙動をTEST_PROFILE化する。

OPEN_UNKNOWN

RFC 5322準拠範囲、Gmailのtenant別DLP/外部送信設定、reply/alias/Bccのagent failure rate、送信取消可能性、他providerとの差。

STOP_CONDITION

draft作成成功を安全な送信成功と扱わない。公開API Docsから特定組織の設定・実挙動を推定しない。 UNIT_CLOSE_STATUS: INDIVIDUAL_BOUNDED_CLOSE / EVIDENCE_RECORDED / UNKNOWN_PRESERVED

---

  • EVD-EA-113-URL-BD90285E2563研究資料研究資料根拠の出所: SOURCE_PACKET_REFERENCE

    source class: official API documentation; exact title: Create and send email messages; author/org: Google for Developers; canonical URL:

    裏付ける内容
    —
    確認日
    —
    出典・実験ID
    SRC-EA-113-URL-BD90285E2563
    検証箇所
    EVIDENCE TABLE · - source class: official API documentation; exact title: Create and send email messages; author/org: Google for Developers; canonical URL: https://developers.google.com/workspace/gmail/api/guides/sending
    適用範囲
    EVIDENCE TABLE
    出典・来歴
    SOURCE_PACKET_REFERENCE_PROJECTED
    限界
    元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
  • EVD-EA-113-URL-9C4C1B2FCF9E研究資料研究資料根拠の出所: SOURCE_PACKET_REFERENCE

    source class: standards-track protocol; exact title: RFC 2822: Internet Message Format; author/org: P. Resnick, editor / IETF Network Working Group; canonical URL:

    裏付ける内容
    —
    確認日
    —
    出典・実験ID
    SRC-EA-113-URL-9C4C1B2FCF9E
    検証箇所
    EVIDENCE TABLE · - source class: standards-track protocol; exact title: RFC 2822: Internet Message Format; author/org: P. Resnick, editor / IETF Network Working Group; canonical URL: https://www.rfc-editor.org/rfc/rfc2822
    適用範囲
    EVIDENCE TABLE
    出典・来歴
    SOURCE_PACKET_REFERENCE_PROJECTED
    限界
    元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
  • EA-113-R11-RESEARCH研究資料研究資料根拠の出所: AUDITED_CANONICAL_RESEARCH_PACKET

    EA-113 監査済みresearch / canonical revision binding

    裏付ける内容
    Gmail APIは直接sendとdraft経由sendを別methodとして公開し、MIME messageとattachmentの作成を要求する。これにより、生成→検査→承認→送信を技術的に別段階へ配置する設計は可能だが、API仕様は「人間が承認した」「宛先が正しい」「添付が安全」「本文が秘密を含まない」ことを保証しない。RFC 2822はInternet Message Formatのsyntaxで、添付等はMIME extension側であり、宛先判断・業務承認・privacy lawは別層である。
    確認日
    —
    出典・実験ID
    COMM-040-EA0113
    検証箇所
    COMM-040-EA0113 · EA-113-R5-LEGACY-MIGRATION-20261008-R1 · content/staging/EA-113.md
    適用範囲
    監査済みEA本文・canonical revision・既存Source Graph relationの範囲。欠損currentnessは推測で閉じない。
    出典・来歴
    AUDIT_PASS_CANONICAL_BINDING
    限界
    canonical監査・revision bindingの存在を示す。外部ソースcurrentnessが本文またはcontrol-planeで確定していない場合は、currentnessをUNKNOWNのまま保持する。
  • EA-113-R11-WEB-READBACK実装資料実装資料根拠の出所: IMPLEMENTATION_READBACK

    EA-113 Web body identity / canonical readback

    裏付ける内容
    canonical staging bodyのSHA-256一致とR9 canonical ledger readbackをProduction projectionの入力として検証する。
    確認日
    —
    出典・実験ID
    WEBBODY-EA0113-R8-3BD024C0
    検証箇所
    WEBBODY-EA0113-R8-3BD024C0 · content/staging/EA-113.md · EA-113-R5-LEGACY-MIGRATION-20261008-R1
    適用範囲
    R9/R10 canonical readback後のProduction生成時body identity。
    出典・来歴
    CANONICAL_READBACK_BODY_HASH_MATCH
    限界
    body identity/readbackは本文claim自体の真偽や外部ソースの最新性を追加保証しない。
出典ID
COMM-040-EA0113, SRC-EA-113-URL-BD90285E2563, SRC-EA-113-URL-9C4C1B2FCF9E, WEBBODY-EA0113-R8-3BD024C0
追跡中のUNKNOWN ID
EA-113-UNKNOWN-01, EA-113-UNKNOWN-CURRENTNESS
再確認のきっかけ
正式な 改訂版/publication 状態 change · 本文 成果物 hash change · 出典 現行性 change · new contradiction or 実装 結果の照合

機械検査: 通過 — 機械検査の結果です。情報の正確性や実行の承認を保証するものではありません。

    同じ記事IDの機械可読データです。