🎧 Listen to this article: हिंदी · English · தமிழ் · తెలుగు · ಕನ್ನಡ · മലയാളം · ଓଡ଼ିଆ · 日本語 · 中文
🌍 Read this in your language: हिंदी · தமிழ் · తెలుగు · ಕನ್ನಡ · മലയാളം · ଓଡ଼ିଆ · 日本語 · 中文
AIエージェントをデプロイしてメールを読み取り、返信させると、そのエージェントが使用するメールボックスには、顧客名、住所、注文履歴、サポートへの苦情などの個人データが蓄積されます。これはデモでは問題ありませんが、実在の人物の情報がその受信トレイに届いた瞬間に、GDPRのような規制の下で法的義務を負うことになります。
なぜこれが今(2026年7月)重要なのか
データ保護はもはやオプションではありません。顧客のメールを処理する組織は、防御可能な保持ポリシーがあり、要求された場合に実際に個人のデータを削除できることを証明しなければならないという圧力が高まっています。ほとんどのAIメールのデモではこれを完全に省略しており、エージェントは読み取り、ファイルに保存し、受信トレイはただ大きくなっていきます。これは、コンプライアンス担当者や顧客の弁護士から「私のデータをどのように削除しますか?」と尋ねられるまではうまく機能します。もしあなたの答えが「すべてを永久に保持しています」であれば、あなたはトラブルに巻き込まれます。
エージェントのメールボックスは何が違うのか
Agent AccountはAIモデルが所有するメールボックスであり、人間の代わりに [email protected] モデルに応答します。すべての受信メッセージはそこに届き、実在の人物の個人データを保持しているため、そのデータにはGDPRの下で2つのことが必要です。永久に残らないように文書化された保持ウィンドウと、要求されたときに特定の人物のメッセージを削除できるように証明された消去パスです。
良いニュースは、メールのリスト表示、読み取り、削除など、いずれにせよ使用するAPIのプリミティブが、通常のNylas統合とまったく同じように機能することです。新しいのは、 コントロールプレーンの保持ポリシー で、メールが自動的に存続する期間を設定し、 データプレーンの消去操作 で、オンデマンドで1人のデータのみを削除することです。
これら2つのレイヤーは異なる質問に答えます。保持は「すべてをどのくらいの期間保持するか」という包括的な期限に答えます。消去は「この人のデータを今すぐ削除する」というターゲットを絞った要求に答えます。コンプライアントなエージェントのメールボックスには両方が必要であり、一方が他方の代わりになることはありません。
2つのレイヤーを理解する
保持 は、制限とスパム設定をバンドルするアプリケーションスコープのリソースであるポリシーに存在するコントロールプレーンの設定であり、Agent Accountが属するワークスペースにアタッチされます。メールが存続する期間を制限する2つのフィールドがあります:
limit_inbox_retention_period— プラットフォームが自動的に削除するまでにメッセージが受信トレイにとどまる日数。limit_spam_retention_period— 削除されるまでにメッセージがスパムにとどまる日数。
これらを一度設定すれば、プラットフォームが代わりに実施してくれ、こちら側にcronジョブは必要ありません。そのワークスペース内のすべてのアカウントがウィンドウを継承します。
消去 はデータプレーンの操作です。1人の人物の消去権の要求を受け入れるには、送信者でフィルタリングされたメッセージを見つけ、それぞれをハードデリートします。通常の削除ではメッセージをゴミ箱に移動するだけですが(復元可能)、ハードデリートは真の消去です。
1つの重要な注意事項:APIはメールボックスからメッセージを削除できます。データベースの行、アプリケーションログの行、ベクトルストアのエンベディングなど、あなたが作成した派生コピーは、別途破棄する必要があります。Nylasの削除はPostgresには届きません。
ポリシーへの保持ウィンドウの設定
無料プランでは、保持期間はデフォルトで受信トレイで30日、スパムで7日であり、これらのデフォルトは設定できません。有料プランでは、独自のウィンドウを設定できます。いずれにせよ、推測した数値ではなく、監査人のために書き留める数値である、文書化された保持スケジュールと一致するウィンドウを選択してください。
ステップ1: 保持ポリシーを作成する
curlを使用する:
curl --request POST \
--url "https://api.us.nylas.com/v3/policies" \
--header "Authorization: Bearer REPLACE_WITH_NYLAS_API_KEY" \
--header "Content-Type: application/json" \
--data '{
"name": "Support Agent Retention Policy",
"limits": {
"limit_inbox_retention_period": 365,
"limit_spam_retention_period": 30
}
}'
またはNylas CLIを使用する:
nylas agent policy create --data '{
"name": "Support Agent Retention Policy",
"limits": {
"limit_inbox_retention_period": 365,
"limit_spam_retention_period": 30
}
}'
どちらも次を返します policy_id。それを保持しておいてください — ワークスペースがそれを指し示すまで、ポリシー自体は何もしません。
ステップ2: ポリシーをワークスペースにアタッチする
Agent Accountは、プロビジョニング時にデフォルトのワークスペースを自動作成します。ポリシーをそのワークスペースにアタッチして、そこにあるすべてのアカウントが保持ウィンドウを継承するようにします。
curlを使用する:
curl --request PATCH \
--url "https://api.us.nylas.com/v3/workspaces/REPLACE_WITH_WORKSPACE_ID" \
--header "Authorization: Bearer REPLACE_WITH_NYLAS_API_KEY" \
--header "Content-Type: application/json" \
--data '{
"policy_id": "REPLACE_WITH_POLICY_ID"
}'
またはCLIを使用する:
nylas workspace update REPLACE_WITH_WORKSPACE_ID --policy-id REPLACE_WITH_POLICY_ID
これでプラットフォーム側の保持ストーリーは完了です。ここからNylasは独自にウィンドウを実施します — 作成、監視、またはトラブルシューティングするスケジュールされたジョブはありません。
消去パスの構築
保持は、スケジュール通りにメールが古くなるというパッシブなケースを処理します。消去は、誰かがデータの削除を求めたときにそれを削除するというアクティブなケースを処理します。
特定の人物のメッセージを削除するには、送信者アドレスでメールを見つけ、それぞれをハードデリートします:
curl --request DELETE \
--url "https://api.us.nylas.com/v3/grants/REPLACE_WITH_GRANT_ID/messages/REPLACE_WITH_MESSAGE_ID?hard_delete=true" \
--header "Authorization: Bearer REPLACE_WITH_NYLAS_API_KEY"
完全なアイデンティティのワイプ — グラント自体を削除する — には次を使用します:
curl --request DELETE \
--url "https://api.us.nylas.com/v3/grants/REPLACE_WITH_GRANT_ID" \
--header "Authorization: Bearer REPLACE_WITH_NYLAS_API_KEY"
この hard_delete=true パラメータは重要です。これがないと、メッセージをゴミ箱に移動しているだけであり、真に消去しているわけではありません。
分割が重要な理由
保持(コントロールプレーン)を消去(データプレーン)から分離することで、2つの異なる問題について考えるようになります。保持は、一度設定して忘れる包括的な期限です。消去は、個々の要求に応答するために構築するワークフローです。どちらも必要です。保持ウィンドウはあるが消去パスがないメールボックスでは、要求されたときに個人のデータの削除を拒否する可能性があります。消去パスはあるが保持ウィンドウがないメールボックスは、誰も削除を求めなければメッセージを永久に保持する可能性があります。
結論
コンプライアントなエージェントのメールボックスを構築するということは、データ保護を後付けではなくインフラストラクチャとして扱うことを意味します。ポリシーを設定すると、Nylasは自動的に保持を処理します。消去には、誰かが要求したときにメッセージを見つけて削除する、文書化されたプロセスが必要です。この2つを合わせることで、期限と削除パスの両方があることを規制当局(または弁護士)に証明できます。2026年において、これは実際のメールに触れるあらゆるAIエージェントにとっての必須条件です。
メリット
- 保持はスケジュールされたジョブではなくプラットフォームによって実施されるため、cronがサイレントに失敗するリスクはありません。
- 2つの別々のレイヤー(保持と消去)により、「包括的な期限」と「この人のデータを削除する」が明確に分離されます。
- APIは通常のNylas統合と同じであり、学ぶべき新しい概念はありません。
- 無料プランには組み込みの30日間の受信トレイデフォルトがあるため、デモでさえいくらかの保護があります。
- 有料プランは完全に設定可能であり、法務チームの保持スケジュールに合わせることができます。
- ポリシーのアタッチは1回限りのアクションであり、保持ウィンドウを更新すると、ワークスペース内のすべてのアカウントに自動的に適用されます。
デメリット
- APIはメールボックス内のメッセージのみを削除し、自身のデータベース、ログ、またはベクトルストア内のコピーは削除しません。それらは個別に追跡して破棄する必要があります。
- 無料プランの保持期間は受信トレイ30日、スパム7日に固定されているため、コンプライアンスのニーズに合わない場合があります。
- 消去は自動ではなく手動のデータプレーン操作であり、削除要求を受け取り、それを実行するワークフローを構築する必要があります。
- ポリシーがアタッチされていないワークスペースでは、プランのデフォルトの制限でアカウントが実行されますが、有料プランでは保持期限がまったくないことを意味する場合があります。
- プラットフォームは保持ウィンドウを実施しますが、監査を受けた場合のコンプライアンス証明の責任は引き続きあなたにあります。
注意
この記事は教育的なものであり、文書化されているNylas APIを説明しています。法的アドバイスではありません。本番環境で保持と消去を実装する前に、選択した保持ウィンドウ(例:365日)が、文書化されたコンプライアンスポリシーと法務チームの要件に一致していることを確認してください。コマンドを実行する前に、すべてのプレースホルダー値(REPLACE_WITH_NYLAS_API_KEY、REPLACE_WITH_WORKSPACE_ID、REPLACE_WITH_POLICY_ID、REPLACE_WITH_GRANT_ID、REPLACE_WITH_MESSAGE_ID)を実際の値に置き換えてください。このガイダンスに依存する前に、公式のNylasドキュメントと組織の法務またはコンプライアンスチームに相談してください。
よくある質問
通常の削除とハードデリートの違いは何ですか? — 通常の削除はメッセージをゴミ箱に移動し、そこで復元できます。ハードデリート (?hard_delete=true) は真の消去であり、元に戻すことはできません。
無料プランでも保持ポリシーを設定する必要がありますか? — いいえ、無料プランにはデフォルトで組み込みの30日間の受信トレイ保持と7日間のスパム保持があります。これらのウィンドウがニーズに合っている場合は、ポリシーを設定する必要はありません。有料プランでは保持を明示的に構成する必要があります。
データベースにすでにコピーしたデータをNylasで削除できますか? — いいえ。Nylas APIはメールボックス内のメッセージのみを削除します。データベースの行、ログ、またはエンベディングなどの派生コピーを破棄するのはあなたの責任です。
スパムウィンドウより短い保持ウィンドウでポリシーをアタッチするとどうなりますか? — APIはそれを拒否します。スパムが正当なメールより先にクリアされるように、スパムの保持期間は受信トレイの保持期間より短くなければなりません。
ワークスペース内のすべてのアカウントは同じ保持ポリシーを継承しますか? — はい。ワークスペース内のすべてのAgent Accountは、そのワークスペースにアタッチされたポリシーから保持ウィンドウを継承します。
後で保持ウィンドウを変更する必要がある場合はどうなりますか? — 単純にポリシーをPATCHしてウィンドウを変更します。そのワークスペース内のすべてのアカウントは直ちに新しいスケジュールに従います。
特定のメッセージをハードデリートせずに削除できますか? — はい、しかし通常の削除はゴミ箱に移動するだけです。真に消去する(復元不可能にする)には、次の ?hard_delete=true パラメータを使用します。
消去プロセスを自動化する方法はありますか? — APIは自動削除をサポートしていますが、プラットフォームによれば、削除要求を受け取り、メッセージごとにハードデリートエンドポイントを呼び出す独自のワークフローを構築する必要があります。
タグ
#gdpr #email #dataprotection #compliance #retention #api #erasure #agentmail
Incident Response: First Hour
A calm, evidence-preserving checklist for establishing control, bounding impact, communicating clearly, and containing an incident safely.
Free. No spam — unsubscribe in one click.


Responses
Sign in to leave a response.