Windowsのタスクバーから、SwitchBotを操作したい。最初のきっかけは、それだけだった。
テレビの入力切り替えを呼び出す小さなショートカットを作り、照明・カーテン・換気扇もまとめてみた。便利にはなったけど、毎回メニューが出るまで1〜2秒ほど待つのが、だんだん気になってきた。
「右クリックメニューくらい、一瞬で出てほしい」。そこで2026年10月3日、起動のたびに画面を作る方式から、裏で待機している常駐型へ作り直した。今回は、その完成形だけでなく、テレビ操作からここまで育てた流れも実スクショと一緒に残しておく。
このプロジェクトはほとんどChatGPTに丸投げしてそのまま実現できた内容だ。
ほとんど＠＠して、＠＠暗くして、といった感じの適当プロンプトのみで作成した。
AIの進化が身にしみて感じた。
この記事の通りにしたい人は理解して作業するよりこの記事をAIになげて「俺もしたい」って言うと出来ると思う。
作業にあたって単語の意味は理解していく必要はあるが分からない時は素直にAIに聞いて理解を深めてから作業してほしい。
ま、理解してなくても作れたよという報告記事になるのでよろしく頼む。
前にも記事にしているがテストがてら一から今までの内容を記事にしている。
完成形はタスクバーの上に出るメニュー
今のランチャーは、タスクバーのSwitchBotアイコンから開く小さなメニューになった。テレビ電源と入力切り替え、その下にカーテン、換気扇、照明。照明グループを一番下にして、その中では「くつろぎ」を最後に置いている。
白いボタンを並べた専用ウィンドウから、Windows標準のポップアップメニューへ変えた。画面の「テレビ電源」「入力切り替え」と、灰色のグループ名を見ると、操作と見出しの区別も分かる。上の画像は実際のメニュー部分とタスクバーを切り抜いたものだ。
今回は、派手な見た目より軽さ優先。操作したいときだけ開いて、項目を選ぶ。このくらいの小さな道具の方が、普段のWindows操作に混ぜやすい。
ただし、メニューが出る速さと、家電が動き終わる速さは別。改善したのは主に前者で、SwitchBotのAPI通信や家電側の反応までゼロ秒になるわけではない。そこを分けるのが、今回の改良のポイントだった。
最初はテレビの入力切り替えから
最初から家中の操作をまとめようとしていたわけではない。まずは、テレビの入力切り替えをWindowsから実行できればよかった。
使ったのはPowerShellとSwitchBot API。SwitchBot側にある「入力切り替え」シーンを指定して実行する。シーンというのは、アプリ側で用意してある操作のまとまりだ。PCからテレビへ独自の赤外線信号を送る仕組みを一から作るのではなく、すでにある操作の呼び出し口をPCに作った。
上は当時の開発者向けオプション画面。「トークン」と「クライアントシークレット」の欄があり、APIを使うための認証情報を確認していた。認証欄は記事用画像で広めに伏せている。この値をスクショや配布コードに載せないことは、作る前から大事だ。
大まかな順序は、認証情報を用意し、シーン一覧で対象の名前とIDを確認し、そのIDを指定して実行すること。SwitchBotの公式API資料でも、手動シーンの一覧取得と実行が別のAPIとして説明されている。
最初のPowerShellでは、Token・Secretと時刻・nonceから署名を作り、必要なヘッダーを付けてリクエストしている。仕組みを知らずに文字列だけ差し替えるより、「認証」と「どの操作を呼ぶか」を分けて考える方が追いやすかった。
もちろん、最初から全部すんなりではない。9月22日の画面には、シーン実行のPOSTで「415」「Unsupported Media Type」が返っている。ここで見るのは赤いエラーの種類と、その直前の送信指定だ。
現在残っているtv-input.ps1では、JSONのContent-Typeと空のJSON本文を指定している。エラー画面の送信では、その指定が見えていない。少なくとも、最終的に使っているコードでは送信形式を明示する形になっていた。すべての失敗を認証の問題として扱うより、何のエラーが返ったのかを確かめる必要があった。
# 署名を含む $headers と、対象の $sceneId を用意した後の実行部分
Invoke-RestMethod `
-Uri "https://api.switch-bot.com/v1.1/scenes/$sceneId/execute" `
-Method POST `
-Headers $headers `
-ContentType "application/json" `
-Body "{}"これは呼び出し部分の抜粋で、単独で動く完成コードではない。Token・Secret・シーンIDは自分の環境で管理する。また、実行すると設定したシーンの操作が走るので、対象を確かめてから使う。
その後の実スクショでは、tv-input.ps1を実行してstatusCode 100、message successが返っている。個人パスは伏せた。これでAPIが成功を返すところまでは確認できる。画面だけでテレビの切り替わる瞬間まで撮れているわけではないが、最初の呼び出し口ができた段階の記録だ。
APIという言葉自体が分かりにくい場合は、こちらに仕組みをまとめている。今回も「別のソフトに操作を頼む窓口」と考えると、やっていることは追いやすい。
テレビ入力切り替えだけを作った時点の手順は、こちらにも残してある。本記事はそこを出発点に、現在の常駐型までつなげたものだ。
黒い画面を出さず、タスクバーへ固定
PowerShellで動くようになっても、毎回黒い実行画面が出ると、普段使いのボタンとしては落ち着かない。そこでtv-input.vbsを作り、PowerShellを非表示で呼び出すようにした。
実スクショでも、ファイルの種類は「VBScript Script File」になっている。現在残っているVBSは、同じフォルダーを作業場所にしてtv-input.ps1を呼び、shell.Runの表示指定を0にしている。つまり、API処理そのものをVBSへ全部移したのではなく、PowerShellを見せずに起動する役割を持たせた。
ここまでで、「テレビ操作のPowerShell」と「それを静かに呼ぶVBS」がそろった。次は、毎回フォルダーを開かなくて済むようにショートカットを作る。
初期のアイコン変更画面では、Windows標準のテレビ型アイコンを選んでいた。今のSwitchBot用アイコンが、最初から完成していたわけではない。この段階ではテレビ操作のボタンだったので、テレビの絵で十分分かりやすかった。
ショートカットの見た目を整えると、「これは何をするボタンか」がタスクバー上でも分かる。ランチャーへ発展させた後には、赤いSのSwitchBotアイコンを設定することになる。
当時のショートカットの右クリックメニューには「タスクバーにピン留めする」が出ている。この位置に置けば、作業中に別のアプリを開き直さずにテレビ操作へ進める。
最初の起動経路は、タスクバーのショートカットからVBSを呼び、VBSがPowerShellを非表示で実行する形。単純だけど、目的には合っていた。Windows上に、普段のアプリと同じ感覚で触れる家電操作の入り口ができた。
8項目のランチャーと最初の高速化
テレビだけ動かせるようになると、「せっかくなら、ほかのSwitchBot操作もまとめたい」となる。そこで、1つのアイコンから複数のシーンを選べるランチャーへ広げた。
9月24日に保存された実画面には、照明の「くつろぎ」「シーリング ON」「シーリング OFF」「シーリング 全灯」、カーテンの「開ける」「閉める」、換気扇の「ON」「OFF」が並ぶ。合計8項目だ。これは現在の暗いメニューになる前の、PowerShell＋WinFormsで作った白いボタン型の画面。
ここで単発のテレビ操作から、家電操作を選ぶ道具に変わった。シーンの名前と表示名を持ち、選んだ操作を別のPowerShell処理へ渡す。全部を1つの大きなスクリプトに詰めるより、表示する部分と操作する部分を分ける構成になっている。
当時のフォルダーには、scenes.json、scene-cache.json、SwitchBotLauncher.ps1、SwitchBotAction.ps1、VBS、ショートカット、アイコンがそろっている。ファイル名を見ると、表示・設定・実行・キャッシュという役割が分かる。
scenes.jsonは登録するシーンと表示名の設定。scene-cache.jsonは、シーン名とIDを対応付けて保存するキャッシュだ。毎回メニューを開く前にAPIから一覧を取り直すと、通信の待ちが表示に入り込む。その一覧をローカルに持たせ、必要なときだけ更新する形にした。
9月23日の作業ログには、「8シーン構成を維持」「通常起動時のAPIアクセスなし」「キャッシュと設定の8シーンが完全一致」と残っている。シーンを変更したら設定を直し、Update-SceneCache.vbsでキャッシュを更新する案内も見える。
つまり、今回の常駐化の前に、一度は高速化していた。現在残る旧WinForms版のソースでも、画面起動時は認証情報やキャッシュを読まず、シーンを押した後に実行用処理を起動する。起動の遅さをすべて「API通信が原因」と決め付けられる状態ではなかった。
なお、このログには実機へ操作を送るPOSTは未テストとも書かれている。メニューを出せたこと、設定が合うこと、家電が実際に動くことは、確認する範囲がそれぞれ違う。
便利になったのは確か。でも、実際に使うと、タスクバーを押してから画面が出るまでの1〜2秒が気になってきた。一度だけなら短い。毎回触るボタンになると、その小さな待ちが意外と目立つ。
1〜2秒の待ちを減らすため常駐型へ
そこで10月3日に、目標をはっきりさせた。「Windowsの右クリックメニューみたいに、押したらすぐ出てほしい」。見た目を豪華にするより、表示までにする仕事を減らしたい。
最終的にできたのは、C#で作ったSwitchBotResident.exe。起動するたびにPowerShellでフォームを組み立てるのではなく、ランチャーを裏で常駐させ、呼ばれたら準備済みのメニューを出す。
現在のタスクバーのショートカットを確認すると、起動先はEXEそのもの、引数は--showだった。途中では既存VBSを入口にする構成もあったが、完成形のタスクバーはVBSを経由しない。残っているSwitchBotLauncher.vbsもEXEの--showを呼ぶ内容だが、互換の入口として別に存在している。
Windowsログイン時には、スタートアップのショートカットから同じEXEを--residentで起動する。常駐中に--showが呼ばれると、既存の常駐プロセスへメニュー表示のメッセージを送って終了する。常駐していなければ、最初の起動で常駐側も立ち上がる。
メニューはWin32のCreatePopupMenuとTrackPopupMenuExを使っている。専用ウィンドウをそれっぽく飾ったというより、Windowsのメニューの仕組みを使った形だ。タスクバーのボタン位置を裏で調べておき、押したアイコンの上に表示するための位置も持っている。
大きく変わったのは、次の役割分担。
| タイミング | 現在の処理 |
|---|---|
| Windowsへのログイン | EXEを常駐させ、メニューを準備する |
| タスクバーをクリック | 常駐EXEへ表示を要求する |
| メニューを表示 | キャッシュ・認証情報の読取やAPI通信を行わない |
| 照明などの項目を選択 | 別のPowerShell処理を起動してシーンを実行する |
| 入力切り替えを選択 | 既存のtv-input.vbsからテレビ用PowerShellを実行する |
APIの呼び出しをなくしたわけではない。必要な操作を選んでから呼ぶ。そのため、通信に時間がかかる場合でも、メニューを見せるところへは持ち込まない。
完成時の計測ログには、EXEの表示要求開始からメニュー表示イベントまで、3回で117.9ms、104.7ms、106.7msと残っていた。約0.1秒台だ。
ただし、これは物理的にタスクバーをクリックした瞬間からの全体計測ではない。クリックの受付待ちは含まず、家電の操作完了時間でもない。常駐側の描画区間は別に62.8ms、27.1ms、17.8msと記録されている。この2つを足すものでもない。
以前の1〜2秒は俺が普段使って気になっていた体感なので、厳密な同条件の比較として「何倍速くなった」とは言わない。それでも、起動のたびに作り直す部分を外す、という改良の方向は分かりやすい。目指していたのは大きなアプリではなく、いつでもすぐ出てくる小さな操作メニューだった。
テレビ電源を追加し、完成構成を整理
ここまで来たら、テレビをつける操作も追加したい。APIのシーン一覧には、以前から「テレビ電源」と「入力切り替え」がある。画像では、その名前が見えるようにしてシーンIDだけ伏せた。
今回の改修途中では「テレビON」として追加していたが、最終ソース、設定、実メニューを確認すると、ラベルは「テレビ電源」になっている。対象設定のtv-target.jsonも「テレビ電源」シーンを指定する形だ。入力切り替えは別の項目として、そのすぐ下へ追加された。
テレビ電源はON専用の信号ではなく、ON/OFF共通の電源信号。すでにテレビがONなら、押すとOFFになる。 メニュー名だけ見て「必ずつける操作」だと思わないようにしたい。今の「テレビ電源」という名前の方が、その動きに合っている。
APIのシーン名だけで赤外線信号の中身が判別できるわけではない。このON/OFF共通という注意は、今回の操作仕様として残しておく。また、本記事を作るための確認では、実機にAPI操作を送っていない。
現在の操作順は、テレビ電源→入力切り替え→カーテンの開ける・閉める→換気扇のON・OFF→照明のシーリングON・OFF・全灯・くつろぎ。グループ見出しを除くと、8項目から10項目になった。
今回の完成構成で、主に見るファイルは次のものになる。
| ファイル | 役割 |
|---|---|
| SwitchBotResident.cs / .exe | 常駐、メニュー表示、選択した処理の起動 |
| SwitchBot.lnk | タスクバーからEXEの–showを呼ぶ |
| SwitchBotAction.ps1 | 照明などの8シーンとテレビ電源を実行 |
| scene-cache.json | 既存8シーンの名前とIDの対応 |
| scenes.json / Update-SceneCache.vbs | 既存シーンの設定とキャッシュ更新 |
| tv-target.json | テレビ電源シーンの指定 |
| tv-input.vbs / tv-input.ps1 | 従来のテレビ入力切り替え処理 |
| SwitchBot.ico | ショートカットや常駐アイコン |
旧SwitchBotLauncher.ps1やVBSも残っているが、現在の表示と並び順を決めるのはC#側の固定メニューだ。scenes.jsonを変えるだけで、常駐メニューの項目まで自動で増える構成ではない。項目を変えるならソース側との整合も必要になる。
テレビから8項目へ広げた段階の記録も残している。現在版との違いを見たい場合はこちら。
Codexに任せたときの使用量も残しておく
今回はCodexに、既存構成の調査から常駐型への改修、検証まで進めてもらった。途中で撮った「残り使用量」の画面も残っている。9時47分の記録では、5時間100％、1週間100％だった。
10時02分には、5時間90％、1週間98％。その後も表示位置やメニューの並びなどを調整している。
10時14分の画面では、5時間84％、1週間98％になっていた。この3枚の範囲では、5時間の残量が16ポイント、週間が2ポイント減ったことになる。
これはあくまで今回の途中経過の実測例。「この改修なら必ず16％使う」という見積もりではないし、後続の作業まで含めた最終消費量でもない。実際、その後の10時25分の別画像には、さらに残量が減った表示も残っている。
また、ログには「実機操作テストは行っていない」と明記されている。設定の照合や通信を送らない検証と、テレビや照明が本当に意図どおり動くかの確認は分けて受け取る。そこまで含めて、自分で最後に見るところが分かる記録になった。
最初は、テレビの入力切り替えをタスクバーから押せればよかった。そこから黒い画面を隠し、アイコンを整え、複数のシーンをまとめ、一度待ちを減らして、それでも気になった表示時間を常駐化で削るところまで来た。
こういう道具は、最初から大げさに作るより、使って気になったところを少しずつ直す方が自分に合う。今回も「もっと機能を増やしたい」だけでなく、「毎回の1〜2秒を減らしたい」が次の改良につながった。
今の完成形は、タスクバーから呼び出す小さな常駐メニュー。テレビ電源のON/OFFには注意しつつ、Windowsを触る流れの中で家電操作へ進める。見た目より軽さを選んだ、今回のSwitchBotランチャーはそんな形に落ち着いた。
3キーのマクロキーボードをAIで魔改造！SwitchBotもモニターもノブ1つで操作
Amazonセールで今の俺が本気で欲しいもの13選｜今使っている物から考えた
SwitchBotをWindowsタスクバーにまとめてみた｜1つのアイコンから照明・カーテン・換気扇を操作
Windows 11のタスクバーからSwitchBotを操作！ワンクリックでテレビの入力切り替えを実行してみた