Microsoft Garage版「Mouse without Borders」を複数ユーザーが利用する共有PCで運用すると、ログオンユーザーが変わるたびにセキュリティキーが新規生成され、PC間の再設定が必要になることがあります。キーの保存場所、ユーザー間で使い回せない理由（DPAPI暗号化）、運用負荷を下げる現実的な対策を整理します。
共有PCで起きる「キーが毎回変わる」現象とは
Mouse without Borders（Microsoft Garage版）は、複数PC間でマウス・キーボードを共有できる便利なツールですが、共有端末（1台のPCを複数ユーザーでログオンして使う環境）では、次のような問題が起きやすくなります。
| 構成例 | 状態 | 困る点 |
|---|---|---|
| PC1：ユーザー1 PC2：ユーザー2 | PC1/PC2双方に同じセキュリティキーを入力すると正常に接続 | 初回はスムーズに使える |
| PC2：ユーザー3でログオン | PC2側で別のキーが生成され、PC1とのペアリングが崩れる | ユーザー3用に再度PC1のキーを入力し直しが必要 |
| 各PCに複数ユーザー（例：5人） | 同じ作業をユーザー数×PC数ぶん繰り返す | 運用が破綻しやすい（設定漏れ・問い合わせ増） |
この現象の本質は、「PC単位で共通のキーを持てる設計」ではなく、「ユーザー単位でキーが保護される設計」になっている可能性が高い点にあります。見た目は“同じPCの同じアプリ”でも、ログオンユーザーが変わると別インスタンスのように振る舞ってしまいます。
セキュリティキーの保存場所（Microsoft Garage版）
調査例として、セキュリティキーは次のレジストリ配下に保存されていることが確認されています。
レジストリ例：
HKLM\SECURITY\Policy\MouseWithoutBorders\devicename\user-MyKey
ここで重要なのは、HKLM\SECURITY という場所が、一般的なアプリ設定が入る領域（HKCUやHKLM\Softwareなど）とは性質が異なることです。HKLM\SECURITY はWindowsのセキュリティ関連情報を扱う保護されたハイブで、通常の手順で内容を閲覧・編集することを前提にした場所ではありません。
| よくある推測 | 実態（整理） | 運用への影響 |
|---|---|---|
| settings.json等の設定ファイルに平文で保存されている | 該当しないケースが多い（少なくともキー本体は別管理） | ファイルコピーでの横展開は期待しにくい |
| HKCU（ユーザーごとのレジストリ）にあるはず | ユーザーごとの挙動だが、保存先がHKLM\SECURITY配下という報告がある | 「場所がHKLMだから共有できる」は誤解になりやすい |
| HKLMならPC内の全ユーザーで共通にできる | 値が暗号化され、復号にユーザー情報が絡むと共通化できない | コピーしても他ユーザーで使えず、再入力が必要になりやすい |
注意点：HKLM\SECURITY 配下の値を、目的が曖昧なまま編集・削除するのは避けてください。Windowsのセキュリティ機構に関わる領域のため、トラブル時の影響範囲が大きくなりがちです（アプリだけでなくOS側の動作にも波及する可能性があります）。
なぜユーザー間でキーを使い回せないのか：DPAPI（データ保護API）の考え方
調査結果として、該当レジストリの値は暗号化されており、その暗号化には Windows の DPAPI（Data Protection API） が使われていると考えられます。ここを理解すると、「なぜコピー運用が成立しないのか」が腑に落ちます。
DPAPIは「ユーザー（またはPC）に紐づけて暗号化する」仕組み
DPAPIは、アプリが「秘密情報（パスワード、トークン、鍵など）」を保存するときに、Windowsに暗号化・復号を任せられる仕組みです。特徴は大きく2つあります。
- ユーザー単位で保護：あるユーザーの資格情報（プロファイル）を前提に暗号化すると、別ユーザーでは復号できません。
- PC単位で保護：マシンコンテキストで暗号化すると、原則として別PCでは復号できません。
今回の挙動（同じPCでもログオンユーザーが変わるとキーが変わる／既存値が使えない）から推測すると、少なくとも「ユーザー単位で復号に必要な情報が変わる」設計になっている可能性が高いです。つまり、
- ユーザー2で保存された「暗号化されたキー」をユーザー3にコピーしても、ユーザー3側では復号できない
- 結果として、アプリは「復号できない＝キーが無い／壊れている」と判断し、新しいキーを生成する
という流れが起きやすくなります。見た目には「同じレジストリ値を入れたのに動かない」ですが、実態は「鍵束が違うので開けられない金庫を移動している」ような状態です。
保存先がHKLMでも、実質は“ユーザー専用”になり得る
レジストリのパスだけを見ると「HKLM＝PC全体」と感じますが、暗号化の方式次第で“ユーザーにしか開けられないデータ”をHKLMに置くことは可能です。今回のようにHKLM\SECURITY配下で管理されている場合、見た目はマシン全体でも、中身はユーザー情報ベースで保護されている、ということが起こり得ます。
結論：Microsoft Garage版は「ユーザーごとに初回設定」が基本になりやすい
実際の検証コメントとしても、Microsoft Garage版のMouse without Bordersでは、この挙動を簡単に回避する方法は見つかりにくい、という結論になりがちです。特に次の条件が重なる環境では、運用側での吸収がほぼ前提になります。
- 同一PCを複数ユーザーが利用する（共有PC、教室PC、端末室、検証端末など）
- PC台数も多い（2台だけでなく3台以上、複数セグメントなど）
- ユーザー切替が頻繁（シフト制、短時間利用、日替わりなど）
この前提を受け入れないまま「全ユーザーで同じキーを一発で配布したい」と考えると、作業コストと問い合わせが雪だるま式に増えます。ここからは、現実的に負荷を下げる工夫を紹介します。
運用負荷を下げる実践策：完全共有が無理でも“手戻り”は減らせる
初回セットアップを「最短・最少ミス」に標準化する
ユーザーごとに1回は入力が必要になりやすい以上、重要なのは「1回の設定で確実に終わる」状態を作ることです。おすすめは、社内Wikiや配布資料に“迷わない手順”として固定化することです。
| 標準化ポイント | 狙い | 具体例 |
|---|---|---|
| 入力項目を固定 | ユーザーがどこを見ればよいか迷わない | PC1名・PC2名・セキュリティキー・レイアウト（画面配置）をテンプレ化 |
| 確認手順をセット | 「設定したつもり」を排除 | 接続後にカーソル移動／クリップボード共有／ショートカット動作をチェック |
| 失敗時の分岐を明記 | 問い合わせ前に自己解決できる | キー不一致、同一ネットワーク、Firewall、PC名変更などのチェックリスト |
特に共有PCでは「誰がいつ設定したか」が曖昧になりやすいので、チェックリスト形式にすると効果が出やすいです。
キーの取り扱いを「安全に」「間違えにくく」する
手入力が前提なら、次に効くのは“入力ミスを減らす”対策です。
- コピペできる形で保管：手打ちよりコピペの方が事故が減ります（ただし貼り付け先を誤らない運用が前提）。
- 短縮形で管理しない：途中省略や口頭伝達は誤入力の原因になります。
- 閲覧範囲を絞る：キーは端末操作権限に直結するため、必要な人だけが見られる場所に置くのが基本です。
共有の仕方としては、組織のルールに沿ったパスワード管理ツールや、アクセス制御されたドキュメント（閲覧権限を最小化した社内ストレージ等）に保存し、作業者がコピペできるようにするのが現実的です。
「サービスとして実行」を再検証する価値はある（ただし期待しすぎない）
回避策としてよく挙がるのが、Mouse without Bordersの設定にある「サービスとして実行（Use service）」系のオプションです。理屈としては、サービス（システムコンテキスト）で動けばユーザーの切替に影響されにくくなる可能性があります。
ただし、環境によってはうまく動かない／期待した共有にはならない、という報告もあります。試すなら次の観点をまとめて確認すると、原因切り分けがしやすくなります。
| 確認項目 | 見たいポイント | 補足 |
|---|---|---|
| 管理者権限 | サービス登録や通信許可が不足していないか | 共有PCでは権限が制限されがち |
| 常駐の状態 | ログオフ/ユーザー切替でプロセスが落ちていないか | ログオンユーザー依存で落ちると効果が薄い |
| Firewall/ネットワーク | サービス経由の通信がブロックされていないか | アプリ許可とサービス許可は扱いが変わる場合がある |
検証時は「うまくいけば儲けもの」くらいの温度感で、うまくいかなかった場合に備えて次の代替案も同時に検討しておくのがおすすめです。
どうしても共通キー運用が必要な場合の代替案
「全ユーザー×全PCで毎回設定」は現場負荷が大きいため、要件が強い場合は最初から別アプローチに切り替える方が、長期的にコストが下がることがあります。PowerToys版への切り替えが難しい前提でも、方向性としては次の3つが現実的です。
類似ツール（Synergy / Barrier）を検討する
Mouse without Bordersと同じく、複数PC間でマウス・キーボードを共有するためのツールとして、SynergyやBarrierが候補に挙がることがあります。これらは設計思想や設定の持ち方が異なるため、多端末・多ユーザーの運用に向いているケースがあります。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| Synergy | 組織で継続運用し、設定やサポートも含めて管理したい | ライセンスや管理方針に適合するか確認が必要 |
| Barrier | 検証・小規模から始めたい、コストを抑えたい | 運用体制（更新・問い合わせ先）をどう持つかが鍵 |
ポイントは「設定をどこに持つか」「暗号化や認証の仕組みをどう扱うか」です。共有PCでは“ユーザー切替に強い”ことが最重要要件になるため、ツール選定時は操作性よりも運用設計（初期展開、設定配布、障害時の復旧）を優先して評価すると失敗しにくくなります。
RDPなど「リモート接続」ベースに切り替える
複数PCを横断して操作したい目的が、実は「別PCの画面を触りたい」「アプリを起動したい」というリモート操作要件である場合、マウス共有ツールにこだわるより、リモートデスクトップ（RDP）等の方が運用に合うことがあります。
- ユーザー管理（誰が接続できるか）をOS側の仕組みに寄せやすい
- 監査やアクセス制御の設計がしやすい
- 共有PCでも、アカウント単位の運用ルールを適用しやすい
一方で、複数モニタを“跨いで”操作するような直感的な体験は薄れるため、用途が「常時2台を1つの机で行き来する」なのか「必要なときだけ別PCに入る」なのかで判断するとよいです。
ハードウェアKVMや周辺機器で割り切る
ソフトウェアのキー管理が運用ボトルネックになるなら、ハードウェアKVM（切替器）やマルチペアリング対応のキーボード・マウスで割り切るのも手です。ユーザー切替の影響を受けにくく、「設定の再入力」という概念そのものを減らせます。
ただし、端末台数や設置環境によって配線が増えたり、ディスプレイ構成が複雑になる場合があるため、机上の運用（設置・故障対応・在庫）まで含めて判断が必要です。
補足：キーの問題と切り分けたい“別の原因”
「キーを入れ直しても繋がらない」「ユーザーによって繋がったり繋がらなかったりする」場合、キー以前に環境要因が絡んでいることがあります。共有PCではユーザーごとにプロファイルやポリシーが異なり、結果として通信条件も変わるため、次の観点を合わせて確認しておくと手戻りが減ります。
| チェック項目 | 確認内容 | 対処の方向性 |
|---|---|---|
| ネットワーク | PC同士が同一ネットワークで相互到達できるか | ゲストWi-Fiやセグメント分離だと通信できないことがある |
| Windows Defender Firewall | アプリの通信許可がユーザー/プロファイルで変わっていないか | プライベート/ドメインプロファイルで許可ルールを整理 |
| PC名/解決 | PC名が変わっていないか、名前解決できるか | PC名変更後は再設定が必要になりやすい |
| 権限/制限 | 共有ユーザーにインストールや常駐が許可されているか | 運用ルールとして「初回設定は管理者が実施」を徹底 |
特にFirewallは「同じPCでもユーザーやネットワークプロファイルによって挙動が変わる」代表例です。キー共有の議論と切り離して、まず“通信経路として成立しているか”を確認すると、問題が整理しやすくなります。
セキュリティ観点：共有キー運用が抱えるリスクも知っておく
「全員が同じキーを使えたら楽」という発想は自然ですが、同時にリスクも増えます。Mouse without Bordersは入力デバイスを共有する性質上、キーが漏れたり、意図しない端末が参加できる状態になると影響が大きくなります。
- 共有キーが広く知られるほど、事故（誤接続・誤操作）の範囲が広がる
- 端末増加とともに“どの端末がどの端末を操作できるか”が把握しづらい
- 共有PCではログオンユーザーが変わりやすく、責任境界が曖昧になりやすい
結果的に、DPAPIでユーザーに紐づく形で守られているのは、運用目線では面倒でも、セキュリティ設計としては一定の合理性があります。運用を軽くしたい場合でも、「キーを無制限に横展開する」より「初回設定を標準化してミスを減らす」「代替方式を選ぶ」方が安全に着地しやすいです。
まとめ
- Microsoft Garage版 Mouse without Bordersでは、セキュリティキーがレジストリ（例：HKLM\SECURITY\Policy\MouseWithoutBorders\…）に保存され、暗号化されているケースがあります。
- 暗号化にDPAPIが関与していると考えられ、ユーザー情報に紐づくため、ユーザー間でレジストリ値をコピーしても復号できず、結果としてキーを使い回せない可能性が高いです。
- 現実的な解としては「各ユーザーが初回に一度キーを設定」する運用になりやすく、標準化（手順書・チェックリスト・安全なキー保管）で負荷を下げるのが効果的です。
- どうしても共通キー運用が必要なら、「サービスとして実行」の追加検証、Synergy/Barrier等の類似ツール、RDP等のリモート接続、KVMなど別方式への切り替えを含めて再設計すると長期コストを抑えやすくなります。
コメント