Agent Account 入門ガイド

Nylas Agent Account とは？

AI エージェントにはメールの送受信機能が必要です。セルフホスト型メールだと5つのシステムを 自分で管理しなければなりません：DNS MX レコード（反映に24-48時間）、Postfix や Exim などの SMTP デーモン （2020年以降12件のセキュリティ勧告、 公式アナウンスリストより）、SpamAssassin によるスパムフィルタリング、四半期ごとに更新する TLS 証明書、そして RFC 5322 ワイヤーフォーマット用の MIME パーサー。

Nylas Agent Account は、これら5つすべてを1つの CLI コマンドで置き換えます。OAuth 認証情報、MX レコード、 サードパーティのメールボックスなしでメールの送受信が可能なフルマネージドのメール ID を取得できます。 API が2秒以内にアドレスをプロビジョニングし、Grant を返します。この Grant は Gmail、Outlook、 IMAP 接続で使用されるものと同じエンティティタイプなので、標準のメール、カレンダー、 連絡先エンドポイントがすべて同一に動作します。アドレスは *.nylas.email ドメインに配置され、OAuth 接続のメールボックスと同じ Nylas v3 API に接続されます。

Agent Account で何ができる？

Agent Account は1つの ID でエージェントに3つの機能を提供します：メール、カレンダー、連絡先。 Grant 1つ、API キー1つ、Workspace 1つ。エージェントは受信トレイを読み、空き状況を確認し、 カレンダーイベントを作成できます。別のサービスも、別の連携も不要です。 Agentmail、Cloudflare Email Workers、Postmark などもマネージドメールアカウントを提供していますが、 同じ ID でカレンダーや連絡先エンドポイントを含むものはありません。

すべての機能は、OAuth 接続のメールボックスで使い慣れた同じ CLI と API で動作します。 エージェントが nylas email send でメールを送信するなら、 nylas calendar events list や nylas contacts list も実行できます。追加のセットアップも認証情報も不要です。MCP 経由で接続する AI エージェントは、 同じサーバー接続から36のツールすべてを利用できます。

Agent Account の作成方法は？

Agent Account の作成は1つの CLI コマンドで、2秒以内に完了します。コマンドは provider=nylas で Grant をプロビジョニングし、マネージド Connector が存在しなければ自動作成し、 Grant をローカルに保存して以降のコマンドが自動的に解決します。OAuth ハンドシェイク、 DNS 反映、ダッシュボードのクリックは不要です。

nylas agent account create コマンドは、使用したいメールアドレスを唯一の引数として受け取ります。ドメインはアプリケーションの *.nylas.email ゾーンです。アドレスはコマンド実行後2秒以内に有効になり、送信可能になります：

nylas agent account create support@yourapp.nylas.email

✓ Agent account created successfully!

Email:      support@yourapp.nylas.email
Provider:   nylas
Status:     valid

アカウント作成後は、他の Grant と同じ nylas email send コマンドでメールを送信できます。送信者アドレスはアクティブな Grant から自動取得されるため、 --from フラグは不要です。 *.nylas.email ドメインで DKIM 署名付きの配信が2秒以内に完了します：

nylas email send \
  --to customer@example.com \
  --subject "Your receipt" \
  --body "Order #4821 confirmed. Shipping Tuesday."

エージェントの受信トレイの閲覧には nylas email list を使用します。 --json を追加すると、エージェントループやシェルパイプラインで解析できる構造化出力を取得できます。 Nylas v3 API は1回の呼び出しで最大200件のメッセージを返します：

nylas email list --limit 5 --json | jq '.[] | {from: .from[0].email, subject}'

これで動作するエージェント ID の完成です。作成、送信、受信の3コマンドで完了。 アプリパスワードによる IMAP/SMTP アクセス、ステータス確認、本番環境の制限事項を含む 完全なウォークスルーは AI エージェントメール ID の作成を参照してください。

Agent Account のアーキテクチャは？

Agent Account は5つのエンティティチェーンで構成されています：Application、Connector、Grant、 Workspace、そして Policy と Rules。Application は API キーを保持し、Connector はマネージド プロバイダータイプを定義し、Grant はメール ID そのもの、Workspace はポリシーとルールの 設定をグループ化し、Rules は受信・送信メールをフィルタリングする条件-アクションペアを定義します。 1つのアプリケーションでこのチェーンを通じて数百の Agent Account を管理できます。

各エンティティの役割は以下の通りです：

• Application — プロジェクトレベルのコンテナ。API キー、リージョン設定 （US または EU）、全コネクタを保持します。 Nylas Dashboard で一度作成します。
• Connector — プロバイダータイプを定義します。Agent Account の場合、 Nylas マネージドプロバイダーです。最初の nylas agent account create 呼び出し時に CLI が自動作成するため、手動でのコネクタ設定は不要です。
• Grant (Agent Account) — 個別のメール ID。メールアドレス、ステータスフィールド、 設定にリンクする workspace_id を持ちます。標準のメール、カレンダー、連絡先エンドポイントすべてで動作し、 受信トレイの読み取りと同じ Grant が nylas calendar events list や空き状況の確認にも使われます。
• Workspace — ポリシーとルール設定のアタッチメントポイント。 policy_id と rules_ids[] の参照を保持します。このエンティティは ID と動作制約の間のアーキテクチャレイヤーです。
• Policy — Workspace の送信制約を定義します（レート制限、ドメイン制限）。
• Rules — 条件-アクションペア。各ルールは送信者ドメインや受信者などの エンベロープフィールドでマッチし、アクションを実行します： block、 archive、 mark_as_read、 mark_as_starred。

Workspace とは？なぜ存在する？

Workspace は Agent Account の Grant とそのポリシー・ルールの間に位置します。 policy_id を Grant の設定に直接保存する代わりに、Workspace が policy_id と rules_ids[] を別々の参照として保持します。これが重要な理由は、Grant に触れずにポリシーをローテーションでき、 ポリシーとは独立してルールを管理でき、アカウント間で設定を共有できるからです。

Workspace は Nylas API の /v3/workspaces/{id} に存在します。Agent Account を作成すると、API は Grant と Workspace の両方を1回の呼び出しで プロビジョニングします（2秒以内）。Workspace を直接操作する必要はありません。 nylas agent policy list を実行すると、CLI がデフォルトの Grant を読み込み、Workspace を取得し、Workspace の policy_id を読み取り、関連するポリシーを返します。このチェーンはユーザーからは見えません。

この間接参照から3つのアーキテクチャ上の利点が得られます：

1. ポリシーのローテーション — Grant ではなく Workspace にパッチを当てて ポリシーを切り替えます。ID は安定したまま動作が変更されます。ダウンタイムゼロ、 更新ごとに200 ms 未満。
2. 独立したルール管理 — ポリシーオブジェクトに触れずに Workspace のルールを 追加・削除できます。Workspace の rules_ids[] 配列がそのアカウントの正式なルールリストです。
3. マルチテナンシー — 動作制約を共有するアカウントは同じ Workspace を 指定でき、各アカウントに個別の Workspace を持たせることもできます。50の Agent Account を持つ 1つのアプリケーションが3つの Workspace を使用する場合もあります：サポート受信トレイ用、 通知送信者用、テスト自動化用。

これが活きる場面：エージェントが1時間あたり500通のポリシーで顧客のレシートを送信しています。 マーケティング部門がキャンペーンのためにキャップを引き上げたいと言います。Workspace がなければ、 Grant の設定にパッチを当て、送信中のエージェントを壊すリスクがあります。Workspace があれば、 1回の PATCH 呼び出しで Workspace のポリシーを切り替えるだけ。Grant は変わりません。 エージェントは再起動しません。200 ms 未満、ダウンタイムゼロ。

nylas agent account get を実行すると、Agent Account の Workspace リンクを確認できます。 Workspace ID フィールドが ID と設定を接続します：

nylas agent account get me@yourapp.nylas.email

Email:        me@yourapp.nylas.email
Provider:     nylas
Status:       valid
Workspace ID: ws_abc123

受信メールはどうやって Agent Account に届く？

誰かがエージェントの *.nylas.email アドレスにメールを送信します。メッセージは Nylas のマネージドメールインフラに入り、 メールアドレスで Grant を解決し、Workspace を読み込み、優先順位でルールを評価します。 ブロックするルールがなければ、メッセージは受信トレイに到着します。 外部の送信者から配信完了まで、95%のメッセージで3秒以内に完了します。

受信パスは4つのステージで構成されます：

1. MX 解決 — Nylas が *.nylas.email の MX レコードを管理します。送信サーバーはあなたのインフラではなく、Nylas のメール インフラに接続します。DNS の設定は不要です。
2. Grant ルックアップ — メッセージの受信者アドレスが対応する Grant に マッチングされます。各エージェントアドレスは正確に1つの Grant にマッピングされます。
3. Policy / Rules 評価 — Grant の Workspace が読み込まれ、ポリシーと rules_ids[] の各ルールが優先順位で評価されます。ルールはエンベロープフィールド（送信者ドメイン、 送信者アドレス、件名）でマッチングします。
4. 配信またはブロック — ルールが block を実行した場合、メッセージは拒否されます。それ以外の場合は受信トレイに到着し、 登録済みの message.created Webhook がトリガーされます。

送信メールはどうやって Agent Account から送られる？

エージェントが nylas email send を呼び出すか、v3 Messages API にリクエストを送ります。リクエストはアクティブな Grant を解決し、 Workspace を読み込み、送信ポリシーを評価し、Nylas のトランザクション送信パイプラインを通じて メッセージをルーティングします。Grant 解決から受信者のメールサーバーまで2秒です。

送信パスは4つのステージで構成されます：

1. Grant 解決 — CLI がアクティブな Agent Account の Grant を解決します。 送信者アドレスは Grant から自動取得されるため、 --from フラグは不要です。
2. Workspace ルックアップ — Grant の workspace_id が取得されます。Workspace は送信動作を制御するポリシーとルールを保持しています。
3. Policy / Rules 評価 — 送信制約とルールがチェックされます。ポリシーが 受信者ドメインを制限している場合、ルールが送信をブロックする場合、送信レートが制限を 超えている場合は、SMTP に到達する前にリクエストが拒否されます。
4. トランザクション送信 — Nylas が *.nylas.email ドメインの DKIM でメッセージに署名し、受信者のメールサーバーに配信します。配信時に message.send_success Webhook が発火します。

Agent Account がセルフホスト型メールを置き換える理由

セルフホスト型メールは5つの個別システムを必要とし、それぞれにメンテナンスとセキュリティの オーバーヘッドが伴います。 Postfix の公式アナウンスリストによると、最も人気のあるオープンソース MTA は2020年以降12件のセキュリティ勧告を公開しています。 勧告ごとにパッチ、再起動、動作確認が必要です。Agent Account はこの5つのシステムすべてを、 2秒以内にメールボックスをプロビジョニングする1回の API 呼び出しで置き換えます。

アーキテクチャ上の違いは、Agent Account がメールインフラを API 境界の裏側に押し込む点です。 デーモン、証明書、DNS レコードの管理は不要です。エンドポイントを呼び出すだけで済みます。 ポリシーとルールの適用はメッセージが SMTP に到達する前の Workspace レイヤーで行われるため、 AI エージェントを標的としたプロンプトインジェクションが制約を迂回することはできません。 封じ込めパターンの詳細は AI エージェントの暴走を防ぐを参照してください。

Agent Account はカスタムドメインもサポートしています。 *.nylas.email の代わりに独自ドメインで送受信できます。プロトタイピングやテスト自動化では、 マネージドドメインがそのまま使えます。本番環境でのブランディングが必要な場合は、 Nylas Dashboard でカスタムドメインを設定してください。

次のステップ

• AI エージェントメール ID の作成 — ハンズオンガイド：アカウント作成、アプリパスワード追加、2分で送受信
• Agent Rules and Policies 完全ガイド — すべてのトリガー、条件、演算子、アクション、ポリシー設定と実例
• AI エージェントの暴走を防ぐ — エージェントの送信前に封じ込めポリシーとルールを Workspace にアタッチ
• AI コーディングエージェントにメールアドレスを付与 — Claude Code、Cursor、Codex を MCP 経由でエージェント ID に接続
• SMTP サーバーなしでメールを受信 — Webhook、リアルタイム処理、テスト用分離受信トレイ
• エージェント間メール通信 — 2つの Agent Account を作成し構造化 JSON を交換
• AI エージェントに最適なメールインフラ — Agent Account、プロバイダー API、IMAP、SMTP、MCP、CLI ツールの比較
• コマンドリファレンス — すべての nylas agent フラグとサブコマンド
• Nylas v3 API ドキュメント — Agent Account の Grant が接続する API