PowerShellでScroll Lock送信しTeams離席を回避できるか検証

Teams 離席 回避 PowerShellの組み合わせで、「Scroll Lockキーを定期的に送れば、Microsoft Teamsが離席（Away）やオフラインっぽく見えなくなるのでは」と試す人は少なくありません。
本記事は、Windows初心者向けに、PowerShellスクリプトと起動用バッチ（.bat）の作り方・実行・停止までを手順どおりに解説します。

最初に重要な注意です。
確実に離席やオフラインを防げるとは断言しません。
Scroll Lock送信は「キーボード入力があったように見せる検証手段」であり、Teamsのプレゼンス判定・組織ポリシー・クライアント版によって効果が無いことがあります。

また、会社のPCではセキュリティ設定や実行ポリシーの変更が規則で禁じられている場合があります。
本記事の手順は個人の検証・学習を想定し、規則に反する利用は推奨しません。

TeamsのプレゼンスとPCスリープは別の仕組み

検証の前に、Teamsの状態表示と、Windowsのスリープ／画面ロックを混同しないことが大切です。
前者はTeamsクライアント（やクラウド側のプレゼンス）が決める表示です。
後者はOSの電源・アイドル設定です。

Microsoftのサポート記事では、デスクトップでコンピューターをロックした場合や、アイドル／スリープに入った場合に、AvailableからAwayへ自動変更されると説明されています。

Teams will automatically set your status from Available to Away when you lock your computer or when it enters idle or sleep mode.

引用：Change your status in Microsoft Teams – Microsoft Support

トラブルシューティング向けのMicrosoft Learnでも、デスクトップが5分を超えて非アクティブだとAwayになる例が挙げられ、ロック・アイドル／スリープ・モバイル利用などが非アクティブ例として示されています。

Your presence status changes to Away if your desktop is inactive for more than five minutes. … Your desktop is inactive in the following scenarios: You lock your computer. The computer enters idle or sleep mode. You’re actively using the Teams mobile app instead of Teams on the desktop.

引用：The correct presence status isn’t reflected in Teams – Microsoft Learn

つまり「PCがスリープしない設定にした」ことと「TeamsがAvailableのまま」はイコールではありません。
逆に、キー入力シミュレーションが効いても、ロック画面や組織側の制限でAwayになることもあります。
検証では「電源設定」と「Teamsの表示」を別々に観察してください。

検証の方針と限界（断言しない理由）

コミュニティでは、Scroll Lockのトグルを数分おきに送り、OSやアプリのアイドル判定をリセットする例が広く紹介されています。
一方、Microsoft公式が「Scroll Lock送信でTeams Awayを防ぐ」と保証しているドキュメントは見当たらません。

効果が薄い・無いケースの例は次のとおりです。

• Teamsが「ユーザー操作」ではなく別条件（カレンダー、通話、モバイル優先、管理ポリシー）で状態を決めている
• PCがロック／スリープに入ると、キー送信よりロック状態が優先されてAwayになる
• SendKeysが期待どおり届かない（フォーカス・権限・仮想環境の入力まわり）
• 組織がプレゼンスやスクリプト実行を制限している

本記事のコードについて、次のように区別します。
動作確認済みに近い部分：WScript.ShellのSendKeysで{SCROLLLOCK}を送る構文は、MicrosoftのSendKeys説明にキー名が掲載されています（キー送信そのもののAPI仕様）。
未検証／環境依存：あなたのTeamsテナントでAwayが止まるか、オフライン表示が変わるか。
必ず自分の環境で観察してください。

Mac上の仮想Windowsで試す場合は、ホストとゲストのどちらでTeamsを動かしているかで結果が変わります。
仮想マシン側の手順は次の記事も参考にしてください。

準備するもの

Windows 10／11、メモ帳（または任意のエディタ）、PowerShell、デスクトップのMicrosoft Teams（サインイン済み）があれば足ります。
管理者権限は、後述の「バッチからBypassで起動」だけなら通常は不要です。
会社PCでは、IT部門の許可なくスクリプトを動かさないでください。

PowerShellスクリプトを作成する

デスクトップなどにフォルダを作り、次の内容をKeepAlive-ScrollLock.ps1として保存します。
一定間隔（固定）とランダム間隔の両方に対応し、Scroll Lockを短時間でON→OFF（トグル2回）してLED表示を元に戻しやすくし、コンソールに実行状況を出します。

# KeepAlive-ScrollLock.ps1
# 検証用: Scroll Lock を定期送信する
# Teams の離席・オフライン回避を保証するものではありません
# 会社の規則に反する利用はしないでください

param(
    [ValidateRange(10, 3600)]
    [int]$MinSeconds = 60,

    [ValidateRange(10, 3600)]
    [int]$MaxSeconds = 180,

    [switch]$FixedInterval,

    [ValidateRange(10, 3600)]
    [int]$IntervalSeconds = 120
)

$ErrorActionPreference = 'Stop'

if (-not $FixedInterval -and $MinSeconds -gt $MaxSeconds) {
    throw "MinSeconds ($MinSeconds) は MaxSeconds ($MaxSeconds) 以下にしてください。"
}

$WShell = New-Object -ComObject WScript.Shell
$counter = 0

Write-Host "=== Scroll Lock 送信スクリプト（検証用） ===" -ForegroundColor Cyan
Write-Host "停止方法: このウィンドウで Ctrl+C"
Write-Host "注意: Teams 離席回避を保証しません。組織ポリシーを優先してください。"
if ($FixedInterval) {
    Write-Host "間隔モード: 固定 $($IntervalSeconds) 秒"
} else {
    Write-Host "間隔モード: ランダム $($MinSeconds)〜$($MaxSeconds) 秒"
}
Write-Host ""

try {
    while ($true) {
        $counter++
        $timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"

        # Scroll Lock ON（トグル）
        $WShell.SendKeys("{SCROLLLOCK}")
        Start-Sleep -Milliseconds 100
        # Scroll Lock OFF（もう一度トグルして元に戻す）
        $WShell.SendKeys("{SCROLLLOCK}")

        if ($FixedInterval) {
            $wait = $IntervalSeconds
        } else {
            $wait = Get-Random -Minimum $MinSeconds -Maximum ($MaxSeconds + 1)
        }

        Write-Host "[$timestamp] #$counter SCROLLLOCK ON/OFF 送信 / 次まで ${wait} 秒" -ForegroundColor Green
        Start-Sleep -Seconds $wait
    }
}
finally {
    Write-Host ""
    Write-Host "スクリプトを終了しました。送信回数: $counter" -ForegroundColor Yellow
}

ポイントは次のとおりです。

• {SCROLLLOCK}はSendKeys公式のキー名です（Microsoft Learn／旧ドキュメント）
• 100ミリ秒空けて2回送り、ONのまま残しにくくします（キーボードLEDがある機種では点滅が短い）
• -FixedIntervalで一定間隔、-MinSeconds/-MaxSecondsでランダム間隔
• コンソールに時刻・回数・次の待ち時間を表示します

Teamsの無操作目安がおおよそ5分前後とされるため、検証の初期値は2〜3分以内（例: 固定120秒、または60〜180秒のランダム）から始めると観察しやすいです。
短すぎるとログが煩雑になり、長すぎるとAwayに入ったあとにしか気づけません。

起動用バッチファイル（.bat）を作成する

同じフォルダにStart-KeepAlive.batを作ります。
エクスプローラーからダブルクリックで起動できるようにします。

@echo off
chcp 65001 >nul
cd /d "%~dp0"

echo ========================================
echo  Scroll Lock 送信（検証用）を起動します
echo  停止: 開いた PowerShell 窓で Ctrl+C
echo  ※Teams離席回避を保証しません
echo ========================================
echo.

REM マシン全体の ExecutionPolicy は変更せず、この起動だけ Bypass
powershell.exe -NoProfile -ExecutionPolicy Bypass -File "%~dp0KeepAlive-ScrollLock.ps1" -FixedInterval -IntervalSeconds 120

echo.
echo 終了コード: %ERRORLEVEL%
pause

ランダム間隔で試す場合は、batのpowershell行を次のように差し替えます。

powershell.exe -NoProfile -ExecutionPolicy Bypass -File "%~dp0KeepAlive-ScrollLock.ps1" -MinSeconds 60 -MaxSeconds 180

cd /d "%~dp0"でbatと同じフォルダに移動するため、作業ディレクトリがずれにくくなります。
pauseがあるので、エラーで即ウィンドウが閉じて読めなくなることも減ります。

ExecutionPolicyエラーの原因と最小限の実行方法

PowerShellで.ps1を直接実行すると、次のようなエラーが出ることがあります。

このシステムではスクリプトの実行が無効になっているため、ファイル ... を読み込むことができません。

これはExecutionPolicy（実行ポリシー）によるものです。
Microsoft Learnでは、実行ポリシーは悪意あるスクリプトの実行を抑える安全機能であり、セキュリティ境界そのものではない、と説明されています。

会社PCでマシン全体や全ユーザー向けにSet-ExecutionPolicyを変えるのは影響が大きく、グループポリシーで上書きされることもあります。
検証では、上記batのようにその起動プロセスだけ-ExecutionPolicy Bypassを付ける方法が、変更範囲を小さくしやすいです。
公式にも、起動時の-ExecutionPolicyでセッション限定にできる旨が書かれています。

現在の有効ポリシーを確認するだけなら、次を使います。

Get-ExecutionPolicy
Get-ExecutionPolicy -List

グループポリシーで制限されている場合、ローカルのBypassが効かないことがあります。
そのときは無理に回避せず、IT部門の方針に従ってください。

実行・確認・停止の手順

手順をまとめます。

1. Teamsをデスクトップで起動し、ステータスがAvailableなど観察しやすい状態にする
2. Start-KeepAlive.batをダブルクリックし、PowerShell窓に送信ログが出ることを確認する
3. 10〜15分以上、キーボードを触らずにTeamsのステータスを観察する（別アカウントや同僚からの見え方も可能なら確認）
4. 比較のため、一度スクリプトを止め、同じ時間無操作でAwayになるかも確認する
5. 終わったらPowerShell窓でCtrl+Cを押し、必要ならbat側の「続行するには何かキーを押してください」で閉じる

停止は基本的にCtrl+Cです。
ウィンドウの×ボタンでも止まりますが、ログのfinallyメッセージが見えないことがあります。
バックグラウンド常駐やスタートアップ自動起動は、意図しないキー送信や規則違反につながりやすいので、本記事では扱いません。

うまくいかないときの切り分け

コンソールに送信ログが出ているのにTeamsがAwayになる場合、Scroll Lockでは足りないか、ロック／スリープ／ポリシーが支配的な可能性が高いです。
SendKeysはアクティブウィンドウ向けの仕組みでもあるため、環境によっては想定どおりに「ユーザー活動」として扱われないことがあります。

batを起動してもすぐ終わる場合は、ファイル名やパス、文字化け、実行ポリシー、グループポリシーを疑います。
エラー全文を控えてから調べると早いです。

組織が「常に応答可能に見せかける」行為を勤務規則で禁じている場合もあります。
技術的に動いても、利用してよいかは規則が優先です。

まとめ

PowerShellのSendKeysでScroll Lockを一定間隔またはランダム間隔で送り、コンソールに状況を出しながら、Teamsの離席表示がどう変わるかを自分の環境で検証できます。
起動用.batでは-ExecutionPolicy Bypassをそのプロセスに限り、マシン全体のポリシー変更を避けやすくできます。

ただし、公式ドキュメントが保証する「Away防止策」ではないこと、プレゼンスとPCスリープは別であること、効果なし・組織制限があり得ることを前提にしてください。
停止はCtrl+C、利用は会社規則の範囲内に留め、観察結果をもとに判断するのが安全です。