家にいる間は、リビングのWindows PCを起動したままにしていることが多い。あるとき、ふと思った。「どうせ電源が入っているなら、その裏でAIに何か作業してもらえたら面白そうだな」と。
最初からモニター切替ツールを作るつもりはなかった。AIを日常的に使いたくて、外からでも家のPCに触れるように環境を整えた。その延長で、タスクバーから画面構成を選べる、自分専用のランチャーまで作った。使ったのは、いつもの中古リビングPCだ。
| 手持ちPCの構成 | 使っているもの |
|---|---|
| OS | Windows 11 |
| CPU | Core i5-10500 |
| メモリ | 16GB |
| GPU | 内蔵GPU中心 |
最新の高性能PCではないけれど、普段使いやYouTube、Moonlightでのリモート操作には十分使えている。テレビで動画を流しながら、空いている時間をAIに使えないか。今ある中古PCで、できることを少しずつ試している。
AIを使うために、家のPCへ外からつなぐ
自宅PCを外から使うため、こんな組み合わせにしている。
iPadやMacBook Air、iPhoneから家のPCへつなげる環境だ。製品の設定手順を並べる記事ではないので、ここでは「家のPCを外から触れる状態にした」くらいの紹介にしておく。
外出先からPCを使いたいときは、iPhoneのショートカットからAlexaを経由し、Wake on LANで起動する仕組みも作った。ワンボタンで電源を入れられるのは便利だけど、これだけで別記事になりそうなので、今回は脇役にしておこう。
VDDを使うと、リモート画面の収まりがよくなる
VDD（仮想モニター）は、Windowsに実物の画面とは別の仮想ディスプレイを追加する仕組みだ。
俺の場合は、リビングTVで動画を流したまま、もうひとつの画面をMoonlightから操作したくて使い始めた。
- TV側：動画をそのまま流す。
- MacBookやiPad側：別の作業画面に入る。
使い始めると、物理モニターと仮想モニターのどちらを使うかを気軽に変えたくなってくる。
仮想の画面をひとつ増やすだけでも便利だけど、VDDは解像度を選んで作れる。iPadやMacBookなど、リモート側の画面サイズや縦横比に近い設定を用意できるのが気に入っている。画面の比率が合うと、黒帯や妙な拡大縮小が減って、接続先の画面をそのまま使っているような感覚になることもある。もちろん、回線の状態や端末の性能にも左右される。
解像度は上のXML Editorで登録し、ドライバーの状態はVirtual Driver Controlで確認する。
接続先の画面サイズに合わせてみる
VDDの設定では、2560×1600や1280×800といった解像度を使っている。設定画面で解像度を変え、Moonlightで接続すると、iPadやMacBookの画面に合わせやすい。Virtual Display Driverの公式プロジェクトでも、Windows上に仮想モニターを追加し、カスタム解像度を使える仕組みとして案内している。
VDDは、俺の使い方では「画面を増やすため」だけの機能ではない。リモート先の画面に合わせて表示を整えられるところが大きい。だからこそ使う頻度が上がり、リビングTVとVDDを切り替える回数も増えていった。
切替のひと手間を減らしたくなった
VDDとリビングTVの使い分け自体はできても、毎回Windowsの設定画面を開いて画面の有効・無効や解像度を切り替えるのは面倒だった。特に、iPadで少し作業したいときと、テレビだけに戻すときで必要な状態が違う。
複数の手順を思い出して操作するより、使う場面の名前を選ぶだけにしたかった。
そこでAIに、タスクバーからモニター構成を切り替えられる専用ランチャーを作ってもらうことにした。MultiMonitorToolのような既存ツールも使いながら、PowerShellやC#、.NETでつなぎ合わせてもらった形だ。
俺がこれらを一からプログラミングしたわけではない。既存ツールを含む構成なので、完成したランチャーを一般公開する予定もない。
今はタスクバーに固定したアイコンからメニューを開き、「FHD」「2560」「1280」「iPad」「FHD + 2560」などのモードを選んでいる。
- リビングTVだけを使う。
- VDDだけを使う。
- リビングTVとVDDの両方を使う。
用途に合わせてDPIも100%や200%へ変更する。
数字のバッジも、実際に使ってから直した
さらに、今何画面が有効か分かるように、タスクバーのアイコン右上へ「1」か「2」の小さなバッジを出すようにした。
最初は表示できて満足したけれど、実際に使うと、気になる挙動がふたつあった。
- ウィンドウをスナップしたあと、バッジが後ろへ回る。
- 動画を全画面表示にすると、タスクバーは隠れるのにバッジだけ残る。
数秒待てば戻る場合もあったが、全画面のときだけは残り続けた。
ここはコードを眺めているだけでは気づけなかった。
バッジは一度描画できたら終わりではなく、Windowsのウィンドウの重なり方やタスクバーの状態にも影響される。最初の実装が間違いというより、実際の使い方を重ねて初めて条件が見つかった感じに近い。
AIに原因を調べてもらい、タスクバーが隠れているか、画面ごとの前後関係はどうか、といった条件を見直した。今は片方の画面で動画を全画面にすると、その画面のバッジだけが消え、もう一方は残る。全画面を解除すると、消えたバッジも戻る。
Windows APIの細部を説明するつもりはない。ただ、こういう挙動は、実際の使い方を試して初めて問題として見えてきた。完成したと思っても、使い続けると次の「ここが気になる」が出てくる。
AIに任せても、実機で確かめるのは自分
最初はGPT-6 Luna 高を中心に使った。仕様がはっきりしている機能追加やモード追加、バッジ、キャンセル機能などを頼むと、かなり作業が進んだ。「タスクバーから開きたい」「このモードではTVだけにしたい」といった使い方を言葉で伝え、画面を見て違和感を伝える。
コードはほとんど読めなくても、使う側としての希望は出せる。
一方、「なぜ動画の全画面表示でだけバッジが残るのか」のように原因を切り分ける段階では、GPT-5.6 Sol 中に切り替えた。
今回使った範囲では、こんな使い分けがしっくりきた。
- Luna：やることが明確な機能追加やモード追加。
- Sol：原因が見えず、判断や実機確認が必要な作業。
モデルの優劣を断定する話ではなく、作業の種類で変えると進めやすかったという実感だ。
SolとComputer Useで、Windowsの画面を実際に操作しながら、全画面表示、スナップ、メニュー、モニター切替を試したときのこと。動画がかなりコマ落ちした。
最初はCPUが足りないのかと思ったけれど、その場で使用率を見るとこうだった。
| その場で見た項目 | 使用率 |
|---|---|
| CPU | 約40% |
| メモリ | 約80% |
| GPU | ほぼ100% |
少なくともこのときは、動画再生とリモート操作、画面キャプチャなどが重なり、GPU側に余裕がなかったように見えた。AIを使うなら必ず高性能GPUが必要、という話ではない。今回のように画面を操作・取得しながら動画も流す使い方では、CPUやメモリだけでなくGPUの余裕も気にした方がよさそうだと思った。
この開発ではGitで変更を残し、Codexから実機を操作して確認する場面もあった。AIがコードを書いて終わりではなく、俺が「この場面で変」「こういう動きがいい」と伝え、直したものをまた試す。その往復に時間も、モデルの利用量も使った。
Gitで途中の状態を残しておくのも助けになった。動かなくなったときに前の状態へ戻りやすく、どこを変えたのかを追いかけやすい。これもGitの仕組みを全部理解したうえで使いこなしているというより、Codexと一緒に変更を記録し、必要なときに参照している。
本当はAIをもっと使いたかっただけなのに、振り返るとWOL、Moonlight、Tailscale、VDD、モニター切替、タスクバーランチャー、バッジ、Codex、Git、モデルの使い分けと、環境づくりそのものにかなり時間を使っている。
「AIを使うための環境づくりが目的になってないか」と、自分でも思う。
それでも、家にいる間にPCを起動しておき、外からも同じ環境へつなぎ、面倒だった切替を自分用の道具で減らせるようになった。こういう土台があれば、次にAIへ頼める作業も増えていくはずだ。環境を整える時間も、これはこれで面白い。
何でも一発で完成したわけではない。それでも、自分専用の環境が少しずつ形になっていくのは楽しい。
「これを作るために、ここまで環境を作ったのか」と笑いつつ、次はもう少し余裕のあるPCで試してみたくなる。
マックミニほしいな。
iClever DK02レビュー｜iPad用に買ったらPCのセットアップでも出番があった
Amazonセールで今の俺が本気で欲しいもの13選｜今使っている物から考えた
AlexaとMoonlightのWOLが同時に失敗。原因不明のまま復旧した記録
テレビでYouTubeを流したままWindowsを裏で操作｜Moonlight＋VDDで仮想モニターを作った