Windowsでユーザーがログインしたときにメール通知を受け取る方法
目的と適用範囲
この手順は複数アカウントや複数台のPCを管理している管理者、あるいは第三者にログインされないか監視したい個人向けです。要点は次のとおりです。
- イベント: ユーザーがWindowsにログインしたとき
- 結果: 管理者（または指定したメールアドレス）に通知メールが送信される
- 使用するツール: SendEmail（コマンドライン）、Windows タスクスケジューラ
重要: メール送信にメールアカウントの認証情報が必要になります。平文でのパスワード保存はリスクがあるため、後述する代替方法や安全対策を必ず検討してください。
準備: SendEmailの入手と設置
- SendEmailはシンプルでポータブルなコマンドラインのメール送信ツールです。TLS対応のバイナリを公式サイトからダウンロードしてください。
- ダウンロード後、Program Filesなど管理者アクセスが必要なフォルダへ展開すると、他のユーザーが勝手に実行できないように制限できます（例: C:\Program Files\SendEmail）。
代替ツール: Blat などもありますが、ほとんどの主要メールサービスで必須のTLSをサポートしていない場合があります。
タスクスケジューラで「ログオン時」にメール送信を実行する手順
1) タスクスケジューラを開く
スタートメニューで「タスクスケジューラ」を検索して起動します。
2) 新しいタスクを作成する
右側の「タスクの作成」をクリックします。
- 「名前」と「説明」を入力します（例: User Login Email Notification）。
- 「ユーザーがログオンしているかどうかに関係なく実行する」を選択します。
重要: 「ログオンしているかどうかに関係なく実行する」を選ぶと、タスクはユーザーの資格情報で実行されます。保存時にアカウントのパスワード入力が必要です。
3) トリガーを設定する
「トリガー」タブで「新規」をクリックし、次を選択します。
- 開始: 「ログオン時」
- 任意のユーザー: 「任意のユーザー」を選択
4) アクションを設定する
「操作」タブの「新規」をクリックします。
- プログラム／スクリプト: SendEmail.exe のフルパス（例: C:\Program Files\SendEmail\sendemail.exe）
- 引数: 以下のコマンドを引数欄にコピーして、メールアドレスとパスワードを実際の値に置き換えます。
-f [email protected] -t [email protected] -xu [email protected] -xp PASSWORD -s smtp.gmail.com:587 -o tls=yes -u "System Login Activity" -m "A user logged into your system!"オプションの意味:
- -f: 送信元メールアドレス
- -t: 宛先メールアドレス
- -xu: SMTPユーザー名
- -xp: SMTPパスワード
- -s: SMTPサーバーとポート（例: smtp.gmail.com:587）
- -o tls=yes: TLSを有効化
- -u: 件名
- -m: 本文
設定後、アクションがリストに表示されます。
5) 条件と電源設定
ノートPCなどで使用する場合は「AC電源接続時のみタスクを開始する」のチェックを外すと、バッテリ稼働時でも動作します。
6) 保存とテスト
すべての設定を終えたら「OK」を押してタスクを保存します。タスク一覧で作成したタスクを選び「実行」をクリックすると、すぐにテストメールが送信されます。
問題がなければ、このタスクでユーザーがログインするたびに指定したメールアドレスへ通知が届きます（インターネット接続が必要）。
安全性とプライバシーの注意点
- パスワードの平文保存は危険です。SendEmailコマンドにパスワードを直接書くとディスク上に残る可能性があります。
- Gmail等を使用する場合、通常のパスワードではなく「アプリパスワード」やOAuth2を利用してください。一般的に「安全性の低いアプリのアクセス」は無効化されています。
- より安全な方法は、Windows資格情報マネージャーや暗号化ストアからスクリプト実行時に認証情報を取得する方法です。
- 社内環境では、社内SMTPリレーを利用して外部への資格情報漏洩を防ぐことをおすすめします。
Important: 個人のログイン情報やアクセス履歴を送信する場合は、組織のプライバシーポリシーや適用される法規（例: GDPR）に従ってください。
より安全な代替アプローチ
- OAuth対応のスクリプトやサービスを使う（Microsoft Graph API、SendGrid等のAPIキー）
- Webhook経由で監視ツール（Slack、Microsoft Teams、IFTTT、Zapier）へ通知し、そこからメール配信を行う
- ログオンイベントを監視して、ローカルでログを記録し、集中ログ管理システム（SIEM）へ送る
これらはパスワード平文の保存を避け、管理や監査を行いやすくします。
トラブルシューティング（よくある問題と対処法）
- メールが届かない
- SMTPサーバー、ポート、TLS設定を確認
- 認証情報（ユーザー名、パスワード）を確認
- ファイアウォールやネットワークが外部SMTPをブロックしていないか確認
- タスクが実行されない
- タスクの「履歴」を有効化してエラーを確認
- 実行するユーザーの権限と「最上位の特権で実行する」設定を確認
- Gmail固有の問題
- 普通のパスワードが使えない場合、2段階認証設定後に「アプリパスワード」を作成して使用
テストケースと受け入れ基準
- テスト1: ログイン直後にメールが届く
- 期待結果: 指定した件名と本文でメール受信
- テスト2: バッテリ駆動時の動作（ノートPC）
- 期待結果: 電源条件を無効にしている場合、バッテリ時でも実行
- テスト3: 複数ユーザーが順次ログイン
- 期待結果: 各ログインで少なくとも1通の通知が届く
管理者・セキュリティ担当者向けチェックリスト
- SendEmailのTLS対応バイナリを入手している
- バイナリは管理者権限が必要なフォルダに設置している
- タスクは「任意のユーザー」のログオンをトリガーにしている
- 認証情報の保存方法を明確にしている（推奨: アプリパスワードや資格情報マネージャー）
- テストメールで受信確認を行った
- 監査ログや履歴の保存ポリシーを定めた
ロール別簡易SOP（箇条書き）
- 管理者: SendEmailインストール → タスク作成 → テスト実行 → ログ保管
- セキュリティ担当: 認証方法レビュー → パスワード管理方針適用 → 監査設定
- エンドユーザー: 目的を理解し、個人情報流出の可能性を把握して同意
いつこの方法が適していないか（例外例）
- パスワードをタスクに平文で保存できない厳格なセキュリティ要件がある場合
- 大規模な施設で多数のログイン通知が運用コストやメールノイズになってしまう場合
- 監査要件で証跡を集中管理する必要がある場合は、SIEM連携や中央ログ方式の方が適切
追加のスニペット（参考: Webhookを使う軽量代替）
Task SchedulerからPowerShellスクリプトを呼び出し、Webhook URLへPOSTすることでメール代替の通知を行えます（認証情報を平文で持たない場合に有効）。
例: PowerShellの簡易POST（Webhook受け側でメール転送設定）
$uri = 'https://example.com/your-webhook-url'
$body = @{ event = 'UserLogon'; user = $env:USERNAME; time = (Get-Date).ToString('u') } | ConvertTo-Json
Invoke-RestMethod -Uri $uri -Method Post -Body $body -ContentType 'application/json'Webhook受け側（例: Zapier／IFTTT／内部サービス）でメール送信を行えば、クレデンシャル管理を外部に委ねられます。
まとめ
- タスクスケジューラとSendEmailを組み合わせれば、ログオン時に自動でメール通知が可能です。
- セキュリティ上の懸念（認証情報の保存や転送）は無視できないため、アプリパスワードやOAuth、Webhook経由などより安全な手段を検討してください。
- 大規模運用や監査要件がある場合は、集中ログ管理やSIEM連携を優先するのが望ましいです。
重要: 実運用に入れる前に必ずテストし、組織のポリシーに従ってください。
よくある質問
Q: Gmailでこの方法を使うとき、通常のパスワードで大丈夫ですか？
A: Gmailはセキュリティ上、通常のパスワードを使えない設定になっている場合があります。2段階認証を有効化して「アプリパスワード」を作成するか、OAuthベースの認証を使ってください。
Q: パスワードを平文で保存しない方法はありますか？
A: はい。Windows資格情報マネージャーやAzure Key Vault、外部のシークレット管理サービスを使い、スクリプト実行時に安全に取得する方法があります。またWebhook経由でメールを外部サービスに任せる方法もリスク低減になります。
Q: サーバー側でSMTPがブロックされている場合は？
A: ネットワーク管理者に外部SMTPの許可を依頼するか、社内SMTPリレーを使用してください。別案としてWebhookやAPIベースのメールサービスを利用することを検討してください。
掲載内容の感想や、実際に試してみた結果をコメントで共有してください。
