Microsoft Graph SDKで予定表（カレンダー）やメール送受信まで含めたエンドツーエンド（E2E）テストを自動化したい一方で、個人/業務の本番Outlookアカウントを使うと誤送信やデータ汚染のリスクが残ります。この記事では、テスト専用の「ダミーOutlook（メール/予定表）アカウント」を安全に用意し、安定して回す運用までをまとめます。
Microsoft GraphのE2Eテストで「ダミーOutlookアカウント」が必要になる理由
Graph連携のE2Eテストは、単体テストやモックでは拾えない“実サービス起因の不具合”を早期に発見できるのが魅力です。たとえば、予定のタイムゾーン差分、繰り返し予定の扱い、メールの本文（HTML/テキスト）や添付の処理、権限同意（Consent）、スロットリングなどは、実環境でしか再現しないことが多いです。
しかし、実運用のOutlookアカウントをテストに使うと、次のような事故が起きやすくなります。
- 誤送信：テストが外部アドレスにメールを送ってしまい、情報漏えいや迷惑行為になり得る
- データ汚染：本番の予定表や受信トレイにテストデータが混ざり、復旧が困難（検索もノイズだらけ）
- 権限が強すぎる：テスト用アプリが本番テナントの全メールボックスへアクセスできる設計になり、監査的に危険
- テストが不安定：本番運用の予定やメール流量に影響され、再現性が落ちる
だからこそ「本番テナントと分離したテスト専用テナント」＋「テスト専用ユーザー（メールボックス付き）」を用意し、Graphで予定表/メール操作を行うのが安全で、長期的に運用コストも下がります。
結論：Microsoft 365 Developer Tenantを使うのが最短で安全
最も定番で、現場でも採用されやすいのが Microsoft 365 Developer Program を使って「開発・検証専用のテナント（Developer Tenant）」を作り、その中にテストユーザーを作成する方法です。Qualified memberであれば、無料・更新可能なMicrosoft 365 E5開発者サブスクリプション（サンドボックス）をセットアップでき、サンプルデータ入りの環境も用意できます。
| 選択肢 | 向いているケース | メリット | 注意点 |
|---|---|---|---|
| Microsoft 365 Developer Tenant（推奨） | GraphのE2Eを継続的に回したい | 本番から完全分離できる。E5開発者サブスクリプションなら機能範囲が広い | 参加/資格条件がある。更新条件（開発利用）が必要 |
| Microsoft 365の試用版テナント | 短期のPoC/検証で十分 | すぐ作れることが多い | 期限が短い。更新や再作成を見越した設計が必要 |
| 有料サブスクリプションでテスト専用テナント | 組織ポリシーでDeveloper Programが使えない | 安定運用しやすい。契約上の制約が明確 | コストが発生。必要サービス（Exchange/Teams等）を含むプラン選定が必要 |
| 本番テナント内でテストユーザーだけ分離 | テナントを増やせない（監査/運用の都合） | 管理が一元化できる | 誤操作時の影響が大きい。強いガードレール設計が必須 |
Developer ProgramのE5開発者サブスクリプションは、25ユーザーライセンスが含まれ、アクティビティに応じて最大90日間で更新されます（開発目的の利用が前提）。また、商用取引（有料サービス購入など）はサポートされない旨が案内されています。
Developer Tenantの種類：Instant sandboxとConfigurable sandbox
Developer Tenantを作る際、選べることが多いのが「Instant sandbox（即時サンドボックス）」と「Configurable sandbox（構成可能サンドボックス）」です。迷ったら、E2Eテスト用途では Configurable sandbox が扱いやすいことが多いです（ドメイン名のカスタマイズ可・空の環境から構成できるため）。
| 項目 | Instant sandbox | Configurable sandbox |
|---|---|---|
| 立ち上げ速度 | 速い（秒〜） | 時間がかかることがある（最大2日と案内） |
| サンプルデータ | プリセット（Teamsサンプルデータ、Graphのユーザー/メール/予定表データ等） | 必要に応じてデータパックを後から投入 |
| ドメイン名 | カスタマイズ不可 | カスタマイズ可 |
| E2Eの向き/不向き | すぐ試すには最適。初期データが多く、テストデータの掃除設計が必須 | テスト用ユーザー/ポリシーを自分で設計しやすい |
なお、サンドボックス作成時に携帯電話番号のSMS認証が求められ、VoIPは不可、電話番号は1つのDeveloper Programアカウントにのみ紐づく、といった注意点も案内されています。チームで複数テナントを作る予定がある場合は、先に運用ルールを決めておくと詰まりにくいです。
Developer Tenantで「ダミーOutlookアカウント」を作る手順
サンドボックスを作成し、管理者でAdmin centerに入る
大まかな流れは「Developer Programに参加 → サンドボックス（開発者テナント）を作成 → 管理者でMicrosoft 365管理センターへログイン → テストユーザー作成」です。Instant sandboxならTeams/SharePoint/Outlook/Officeがプリセットで、サンプルデータも含まれる旨が案内されています。
- Microsoft 365 Developer Programにサインアップする（Microsoftアカウントで参加）
- ダッシュボードからサンドボックス（Microsoft 365 E5開発者サブスクリプション）をセットアップする
- 作成したテナントの管理者アカウント（[email protected]）でサインインする
- Microsoft 365管理センターで、ユーザー/ライセンス/ドメインなどを構成する
Developer Programは「Qualified member」が対象で、Visual Studio Professional/Enterpriseサブスク経由のベネフィットが案内されていることもあります。参加条件や提供形態は変わる可能性があるため、最新要件は公式ページで確認してください。
テストユーザーを作成し、Exchange Online（メールボックス）を有効にする
Graphでメール/予定表を操作するうえで本質的に重要なのは、「対象ユーザーにExchange Onlineのメールボックスが存在する」ことです。GraphのOutlook（メール/予定表）APIは、Exchange Online上のメールボックスに保存されたデータ（カレンダー/メール/連絡先）を扱います。共有メールボックスも対象になり得ますが、E2Eではまずユーザー郵便受け（User mailbox）で揃えると管理が簡単です。
実務でよくあるつまずきが「ユーザーは作ったのに、メールボックスがまだ作られていない/ライセンスが足りない」パターンです。メールを送る/受け取る、予定を作成する、といったE2Eを回すなら、ユーザーにExchange Onlineを含むライセンスが割り当たっているかを必ず確認してください。
| テストしたい操作 | 最低限必要になりやすいもの | チェックポイント |
|---|---|---|
| 予定（イベント）の作成/更新/削除 | Exchange Onlineのメールボックス（カレンダー） | ユーザーにExchange Onlineを含むライセンスが付与され、Outlook on the webで予定表が開ける |
| メール送信（sendMail） | Exchange Onlineのメールボックス | 送信先はまず内部ユーザーに限定し、外部宛ては仕組みでブロックする |
| メール受信・検索・削除 | Exchange Onlineのメールボックス | 識別子（件名プレフィックス/カテゴリ）とクリーンアップ設計が必須 |
テストユーザーは、最低でも「送信側」「受信側」の2人を用意すると、メール送受信のE2Eが自然に組めます（例：e2e-sender@～、e2e-receiver@～）。
アプリ登録（Microsoft Entra ID）とGraph権限の決め方
Graph SDKでテストを自動化するには、通常はMicrosoft Entra ID（旧Azure AD）でアプリ登録し、必要なGraph APIアクセス許可（Permissions）を付与します。テストで悩むのが「Delegated（委任）権限で実ユーザーとして動かすか」「Application（アプリケーション）権限でバックエンドとして動かすか」です。
| 方式 | 特徴 | E2Eテストでの使いどころ | 注意点 |
|---|---|---|---|
| Delegated（ユーザー代理） | サインインしたユーザーの権限で動く | 実際のUXに近い（ログイン必須のアプリ、ユーザー単位の検証） | CIでの自動化が難しい。MFA/条件付きアクセスの影響を受けやすい |
| Application（アプリ単独） | ユーザーなしでアプリとして動く（クライアント資格情報フロー） | CI/CDで安定して回しやすい。バックエンド連携のE2Eに強い | 権限が強くなりがち。アクセス範囲を制限するガードレールが必須 |
メール/予定表のE2Eでよく使われる権限の例は以下です（実際のAPIと要件に応じて最小権限に絞ってください）。
- カレンダー：Calendars.Read / Calendars.ReadWrite
- メール：Mail.Read / Mail.ReadWrite / Mail.Send
Graph SDKでE2Eテストを組むときの最小実装イメージ
ここでは「予定を作る」「メールを送る」「後片付け（削除）」の最小例を、Graph SDK for .NETの雰囲気で示します。実際の認証（MSAL）や例外処理は省略し、E2Eテスト設計の要点だけ掴む目的のサンプルです。
前提：E2E用の送信者（e2e-sender）と受信者（e2e-receiver）が同一テナント内に存在し、アプリに必要な権限（Calendars.ReadWrite / Mail.Send など）が付与されている。
予定（イベント）を作成する
// /users/{id}/events に相当（アプリ単独権限の例）
var ev = new Event
{
Subject = "[E2E][build-1234] 会議予定",
Body = new ItemBody { ContentType = BodyType.Text, Content = "E2E test event" },
Start = new DateTimeTimeZone { DateTime = "2026-01-05T10:00:00", TimeZone = "Tokyo Standard Time" },
End = new DateTimeTimeZone { DateTime = "2026-01-05T10:30:00", TimeZone = "Tokyo Standard Time" },
Location = new Location { DisplayName = "Online" }
};
var created = await graphClient.Users["[[email protected]](mailto:[email protected])"].Events.PostAsync(ev);
var eventId = created.Id; // 後で削除するために保持 カレンダーはタイムゾーンがズレやすいので、E2Eでは DateTime + TimeZone を明示し、テスト用ユーザーのタイムゾーンも固定しておくと安定します。
メールを送信する
// /users/{id}/sendMail に相当
var message = new Message
{
Subject = "[E2E][build-1234] 受信確認",
Body = new ItemBody { ContentType = BodyType.Text, Content = "E2E test mail" },
ToRecipients = new List<Recipient>
{
new Recipient
{
EmailAddress = new EmailAddress { Address = "[email protected]" }
}
}
};
await graphClient.Users["[[email protected]](mailto:[email protected])"].SendMail.PostAsync(
new SendMailPostRequestBody { Message = message, SaveToSentItems = true }
); 最初は組織内（同一テナント）宛てだけで送受信E2Eを固めるのが安全です。外部宛ての送信E2Eは、外部送信ブロックのルール設計とセットで検討します。
後片付け（削除）を必ず行う
// 予定の削除（/users/{id}/events/{event-id}）
await graphClient.Users["[email protected]"].Events[eventId].DeleteAsync();
// メールの削除は messageId を保持して /messages/{id} を Delete
// もしくは件名プレフィックスで検索して一括削除（ただし誤削除防止の識別子設計が必須） E2Eでは「作ったIDで消す」が最も安全です。検索削除は便利ですが、条件が甘いと関係ないメール/予定を巻き込むので、識別子（件名/カテゴリ/実行ID）を強く設計してから使うのが鉄則です。
事故防止の最重要ポイント：アプリのメールボックスアクセスを「テスト用だけ」に制限する
Application権限（アプリ単独）を使うと、設計によってはテナント内の全メールボックスへアクセス可能になってしまいます。そこで強力な安全策が Exchange Online側のアプリ範囲制御です。
代表的に知られているのが Application Access Policies（アプリケーションアクセス ポリシー） で、Microsoft Graph/Outlook REST/EWSを使うアプリのメールボックスアクセスを、特定のメールボックス集合（メール有効なセキュリティグループ）に限定できます。
ただし重要な注意として、公式ドキュメントではApplication Access Policiesはlegacy機能であり、将来的にdeprecationが案内される可能性があるため、新規のアクセス構成は Role Based Access Control for Applications（App RBAC / Exchange Applications向けRBAC） を使うよう促されています。既存のE2E基盤でApplication Access Policiesを採用する場合は、移行を見据えて「スコープ（対象メールボックス）を小さく保つ」「構成をコード化して再現可能にする」などの工夫を入れておくと安心です。
Application Access Policiesの基本手順（概念）は次のとおりです。
- （Exchange Online PowerShellで）メール有効なセキュリティグループを作成する
- グループに「E2E用メールボックス（ユーザー）」だけを追加する
- New-ApplicationAccessPolicyで、対象アプリ（AppId）のアクセスをRestrictAccessにする
- Test-ApplicationAccessPolicyで動作確認する
# 例：Exchange Online PowerShell（概念例）
# 1) Exchange Onlineへ接続
Connect-ExchangeOnline -Organization yourtenant.onmicrosoft.com
# 2) メール有効なセキュリティグループを作成
New-DistributionGroup -Name "E2E-Graph-MailboxScope" -Type "Security"
# 3) E2E用ユーザーをグループに追加
Add-DistributionGroupMember -Identity "E2E-Graph-MailboxScope" -Member "[email protected]"
Add-DistributionGroupMember -Identity "E2E-Graph-MailboxScope" -Member "[email protected]"
# 4) アプリのアクセスをグループ内に限定（AppIdはアプリ登録のクライアントID）
New-ApplicationAccessPolicy -AccessRight RestrictAccess -AppId "<アプリのクライアントID>" -PolicyScopeGroupId "E2E-Graph-MailboxScope" -Description "Restrict Graph app to E2E mailboxes"
# 5) 動作確認（Identityはテスト対象ユーザー）
Test-ApplicationAccessPolicy -Identity "[email protected]" -AppId "<アプリのクライアントID>"
ポリシー作成直後は、GraphのREST呼び出しに反映されるまで時間がかかることがあります。公式ドキュメントでは、Test-ApplicationAccessPolicyで肯定結果が出ても、Graph REST API側への反映には1時間以上かかる場合がある、と注意書きがあります。E2Eテスト基盤を作るときは、初回セットアップ後に反映待ち時間を見込んでおくとトラブルが減ります。
誤送信を“仕組みで”潰す：外部宛てメールをブロックする
もう一段、安全性を上げるなら「E2E用ユーザーからの外部宛て送信を拒否する」ルールをテナント側で作ってしまうのが効果的です。運用ルールだけだと、いつか必ず事故が起きます。
- 送信者が「E2E用ユーザー」または「E2E用グループ」なら、組織外ドメイン宛ては拒否
- 必要がある場合でも、許可リスト（特定の検証用ドメイン）だけ通す
これを入れておくと、テストコードのバグで宛先がすり替わっても、メールが外部へ出ません。「本番アカウントを使わない」ことと同じくらい効果があります。
E2Eテストを安定させるための実務ノウハウ
テストデータの識別ルール（命名規約）を決める
予定やメールを作成するE2Eでは「作ったものを確実に見つけ、確実に消す」ことが品質に直結します。おすすめは、件名/タイトルにプレフィックスを付け、さらにカテゴリや拡張プロパティでタグ付けする方法です。
| 対象 | おすすめ識別子 | 例 | 狙い |
|---|---|---|---|
| メール件名 | 固定プレフィックス + 実行ID | [E2E][build-1234] 受信確認 | 検索しやすく、誤消ししにくい |
| 予定タイトル | 固定プレフィックス + 実行ID | [E2E][build-1234] 会議予定 | 予定表にノイズが残っても視認性が高い |
| カテゴリ | E2E固定カテゴリ | E2E-AUTO | 一括削除/調査が簡単 |
| 本文 | 実行環境情報 | commit, branch, run url | 障害解析の時間を短縮 |
テスト後のクリーンアップは「削除漏れ前提」で二段構えにする
理想は各テストで作成物を都度削除することですが、ネットワークエラーやスロットリングで後処理が落ちるとゴミが残ります。そこで以下の二段構えが現実的です。
- テストの最後に、作成したID（messageId/eventId）を追跡して削除する
- さらに、定期ジョブで「[E2E]」や「E2E-AUTO」タグを持つ古いデータをまとめて掃除する
特に予定（イベント）は、繰り返し予定やタイムゾーンの影響で“意図した期間外”に作成されると気づきにくいので、定期清掃が効きます。
スロットリング（429）と遅延反映を前提にリトライを設計する
Microsoft Graphは状況によりリクエストがスロットリングされる可能性があります。429が返ったら、レスポンスヘッダーのRetry-Afterに従って待機し、再試行するのが基本方針です。
// 疑似コード：Graph呼び出しのリトライ方針（概念）
for (attempt = 1..maxAttempts) {
res = callGraph()
if (res.status != 429) return res
wait(res.headers["Retry-After"] seconds)
}
throw "Throttled"また、メールや予定の作成直後に検索すると、インデックス反映のタイミングで“見つからない”ことがあります。E2Eテストでは「作成→即検索」を避け、IDで取得する、またはリトライ付きの待機を入れると安定します。
タイムゾーンの罠：テスト用ユーザーの設定を固定する
予定表テストで多い失敗が、実行環境（CIのUTC）とユーザーのタイムゾーン差で期待値がズレるパターンです。対策として、テスト用ユーザーのタイムゾーンを固定し、GraphリクエストではISO 8601とタイムゾーン指定を徹底します。さらに、レスポンスで特定タイムゾーンを期待する場合は、GraphのPreferヘッダー（outlook.timezone）も活用します。
手動検証の味方：Graph Explorerで最小リクエストを先に当てる
権限やスキーマが怪しいときは、いきなりSDK側を疑うよりも、Graph Explorerで同じリクエストを投げて挙動を確認すると切り分けが早くなります。Graph Explorerはサインインして自分のテナントに対してリクエストを試せます。
Developer Programが使えない場合の代替案
組織ポリシーや資格条件の都合でDeveloper Programが使えない場合でも、E2Eテスト用のテナント/ユーザーを用意する道はあります。ここでは現実的な代替案を整理します。
試用版（トライアル）でテスト専用テナントを作る
短期の検証なら、Microsoft 365の試用版でテナントを作り、テストユーザーを作成するのが手早いです。ただし、期限切れで突然止まる前提で「作り直し可能な自動化（IaC的な再現性）」を意識してください。
有料サブスクリプションでテスト専用テナントを用意する
長期運用なら有料が最も安定します。Graphそのものは無料でも、メール/予定表のデータはExchange Onlineのメールボックスに依存するため、Exchange Onlineを含むプラン（Business/Enterprise/Education等）を選定します。
| 例として検討されやすいプラン | 含まれやすい要素 | 向くケース |
|---|---|---|
| Microsoft 365 Business Basic / Standard / Premium | Exchange Online（メール/予定表） | Outlook中心のE2Eを安定運用したい |
| Microsoft 365 Apps for business | 主にOfficeアプリ（メールボックスが必要な検証では不足する場合あり） | アプリ利用が主で、別途Exchange Onlineを用意できる場合 |
| Microsoft 365 Enterprise（E1/E3/E5） | より広範な機能（特にE5） | Teamsや高度なセキュリティ機能まで含めて検証したい |
| Microsoft 365 Education（A1/A3/A5） | 教育機関向け機能 | 教育向けソリューションの検証 |
Teamsの一部の高度なAPIやセキュリティ機能など、検証対象によっては上位ライセンスが前提になることがあります。メール/予定表だけのつもりでも、将来のテスト拡張を見越して「必要なサービスがプランに含まれるか」を最初に棚卸ししておくと、後戻りを減らせます。
Outlook.com（個人向け）アカウントで代用できる？
個人向けのMicrosoftアカウント（Outlook.com/Hotmailなど）でも、委任シナリオではGraphにサインインして使えるケースがあります。ただし、全ての委任権限が個人アカウントで有効とは限らず、企業テナントのように管理者が“組織として”ユーザーやポリシーを制御することもできません。E2Eを安全に運用する観点では、原則としてテスト専用テナント（職場/学校アカウント）を推奨します。
CI/CDで回すときの推奨構成（事故らないE2E設計）
最後に、継続的インテグレーションでGraph E2Eを回すときの“事故らない”設計チェックをまとめます。
| チェック項目 | 推奨 | 狙い |
|---|---|---|
| テナント分離 | 本番と別テナント（Developer Tenantや試験テナント） | 誤操作の影響範囲を物理的に分離 |
| 認証方式 | Application権限 + 証明書（可能なら） | CIで安定。秘密情報の漏えいリスクを下げやすい |
| アクセス制限 | App RBAC（推奨）またはApplication Access PoliciesでE2Eメールボックスのみ許可 | 最悪の事故（全メールボックスアクセス）を防ぐ |
| 誤送信対策 | 外部宛て送信ブロック（テナント側ルール） | 宛先バグでも外に出ない |
| テストデータ | 件名/タイトルの規約 + 定期清掃 | 環境が汚れても復旧可能 |
| スロットリング | Retry-Afterに従うリトライ | 不安定な失敗を減らす |
よくあるエラーと原因の切り分け
| 症状 | ありがちな原因 | 対処 |
|---|---|---|
| メール送信/取得が失敗する | メールボックス未作成、Exchange Onlineライセンス未付与 | ユーザーにExchange Onlineを含むライセンスを付与し、メールボックスが作成されるまで待つ |
| 403 / Insufficient privileges | Graph権限不足、管理者同意が未実施 | 必要な権限を最小で追加し、テナント管理者でConsentする |
| 429 / Too Many Requests | スロットリング | Retry-Afterに従って待機・再試行する |
| 作成直後の検索で見つからない | 反映遅延、検索条件が曖昧 | IDで取得する、または待機+リトライを入れる。識別子（件名プレフィックス）を固定 |
まとめ：テスト専用テナント＋テスト専用ユーザーで、安全にGraph E2Eを回す
Microsoft Graphのメール/予定表まで含めたE2Eテストは、実装品質を大きく上げられる一方で、環境設計を誤ると誤送信やデータ汚染に直結します。基本は「本番から分離したDeveloper Tenant（または試験テナント）」を用意し、Exchange Onlineメールボックス付きのテストユーザーで検証すること。そして、App RBACや（必要に応じて）Application Access Policies、外部送信ブロックなど“仕組み”で事故を封じ込めることが、継続運用の近道です。
コメント