Joy-ConをStream Deck代わりにしてパソコンとターミナルを操作できるか調べた
Joy-ConをStream Deck代わりにしてパソコンとターミナルを操作できるか調べた
Nintendo SwitchのJoy-ConをStream Deckのようなパソコン操作デバイスとして使えないか調べた。
結論から言うと、初代Nintendo Switch用Joy-ConならWindowsにBluetoothで接続し、ボタンをキーボード操作やプログラム起動へ割り当てられる。 既存のオープンソースソフトウェアを使えば、試作段階からすべて自作する必要もない。
一方、「ターミナルを操作する」がキー入力だけを指すのか、コマンドの完了や出力の取得までを指すのかで、必要な仕組みは大きく変わる。
この記事では、2026年7月21日時点の公開情報をもとに、最短の検証手順と自作が必要になる境界を整理する。 Joy-Con 2は通信方式や対応状況が異なるため、今回の調査対象には含めていない。 また、今回はドキュメントとソースコードを調べた段階であり、Joy-Con実機での全ボタン検証は次の作業になる。
結論
まず試すなら、Windows向けのQKeyMapperが用途に最も近い。
ゲームパッドの入力をキーボードやマウスの操作、マクロへ変換でき、Run(...)でPowerShellや任意のプログラムも起動できる。
ただし、Joy-Con固有のSL／SRボタン、左右の結合、ジャイロまで確実に使えるとは明記されていない。 Joy-Conらしい入力を優先する場合は、JoyShockMapperが有力になる。 公式READMEでは任意のOSコマンドを直接起動する機能を確認できないため、AutoHotkeyや小さな常駐アプリとの橋渡しが必要になる。
ターミナルの出力を読み、成功や失敗に応じてJoy-Conを振動させたい場合は、既存の割り当てソフトだけでは完結しにくい。 小さな常駐ブリッジを追加する方法が現実的である。 このブリッジの入力部分には、Joy-Con対応が公式に組み込まれているSDL3が使いやすい。
「ターミナルを操作する」には3段階ある
1. 開いているターミナルへキー入力を送る
Joy-ConのAボタンをEnterに、BボタンをEscに、XボタンをCtrl+Cに変換する方法である。
WindowsのSendInputを使えば実装でき、QKeyMapperやAntiMicroXでも同じような操作を試せる。
この方法は手軽だが、フォーカスが別のウィンドウへ移ると入力先も変わる。 ターミナルの出力は取得できず、管理者権限で動くアプリへの入力にはWindowsの制限もある。
2. ボタンから決められたコマンドを直接起動する
ビルド、テスト、Gitの状態確認など、用途が決まっているならこの方法が安定する。 アプリからPowerShellや実行ファイルを直接起動すれば、現在のフォーカスに依存しない。
.NETで自作する場合は、ProcessStartInfo.ArgumentListへ引数を一つずつ渡す。
コマンド文字列を連結してシェルへ丸投げするより、空白や引用符を安全に扱える。
標準出力と標準エラーを受け取るには、UseShellExecuteをfalseにし、RedirectStandardOutputとRedirectStandardErrorを有効にする。
デッドロックを避けるために両方を非同期で読み、プロセスの終了を待ってから終了コードを確認する。
3. 対話中のターミナルと双方向に通信する
単発コマンドの出力と終了コードを得るだけなら、前節のProcessStartInfoで足りる。
ConPTYが必要になるのは、対話シェル、TUI、ANSI端末の表示や操作をアプリ内で扱いたい場合である。
Joy-Conでコマンドを選び、途中経過を画面に表示し、終了結果に応じて振動を変えるなら、アプリ側でターミナルセッションを所有する必要がある。 Windows 10 バージョン1809およびWindows Server 2019以降では、ConPTYという疑似コンソールAPIを使い、入力と端末出力をパイプで接続できる。 受け取るのはUTF-8の文字列とVTシーケンスを含む端末出力であり、通常のリダイレクトのように標準出力と標準エラーを分けて受け取るものではない。 ConPTYは、対話シェル内で実行した各コマンドの完了や成否も通知しない。 子プロセスのハンドルから取得できる終了コードは、通常はホストしたPowerShell自体が終了したときの値である。 各コマンドの成否で振動させるには、コマンドを個別プロセスとして実行するか、シェル側からセンチネルや名前付きパイプで状態を通知する。
ここまで来ると、単なるキー割り当てソフトではなく、Joy-Con付きの小型ターミナルフロントエンドになる。
使えそうなオープンソースを比較する
| 候補 | 評価 |
|---|---|
| QKeyMapper GPLv3 | できること: キー、マウス、マクロ、プログラム起動 Joy-Con: 標準ゲームパッドとして認識できれば使える可能性が高い 注意: SL／SR、左右結合、ジャイロは実機確認が必要 |
| AntiMicroX GPLv3 | できること: キー、マウス、スクリプト、実行ファイル、プロファイル切替 Joy-Con: SDL2経由で左右Joy-Conを扱える可能性がある 注意: Joy-Con固有入力は実機確認が必要。新メンテナーを募集中で、現在は限定的なサポートのみ。外部貢献を除き新機能は追加されない予定 |
| JoyShockMapper MIT | できること: 左右結合、SL／SR、ジャイロ、長押し、同時押し、レイヤー Joy-Con: 固有機能に強い 注意: 独自の内部コマンドはあるが、公式READMEでは任意のOSコマンド実行機能を確認できない |
| SDL3 zlib License | できること: Joy-Con入力をアプリから取得するライブラリ Joy-Con: 左右の結合・分離、Capture、SL／SR、センサーを公式APIで扱える 注意: 完成アプリではないため、画面と割り当て機能は自作する |
| BetterJoy MIT | できること: Joy-ConをXInputへ変換 Joy-Con: 対応実績がある 注意: 最終公開版が古く、依存するViGEmBusもサポート終了済みのため、新規開発の土台には選びにくい |
低水準のHID通信から自作する方法もあるが、初期化、入力レポートの解析、スティック補正まで抱えることになる。 今回の目的では、SDL3を入力ライブラリの第一候補にできる。 最初からHIDAPIを直接使うと実装範囲が広がるため、実機検証でSDL3に不足が見つかってから検討すればよい。
ViGEmBusのサポート終了は、既存のBetterJoy環境が直ちに動かなくなるという意味ではない。 ただし、継続的な保守を期待できず、過去のアップデーター設定に関するセキュリティ上の注意も公開されているため、新規導入では依存しない構成を選びたい。
最短の検証手順
1. Joy-ConをWindowsへ接続する
WindowsのBluetooth設定でJoy-Con LとJoy-Con Rをそれぞれペアリングする。 ペアリング時は側面のシンクロボタンを長押しし、ランプが流れる状態にする。
2. QKeyMapperで基本ボタンを確認する
最初は追加の仮想コントローラードライバーを入れず、Joy-Conが通常のゲームパッドとして見えるか確認する。 左右が別々のデバイスとして認識されるか、1組のコントローラーとして扱えるか、SL／SRまで入力が届くかを順番に記録する。
3. 安全な割り当てから始める
たとえば、次の割り当てならターミナル操作の感触をすぐ試せる。
| Joy-Con入力 | パソコン側の操作 |
|---|---|
| スティック | 矢印キー |
| A | Enter |
| B | Esc |
| X | Ctrl+C |
| Y | Tab |
| ZL + A | 許可済みのPowerShellスクリプトを起動 |
| + 長押し | プロファイル切替または操作ロック |
単押し、長押し、同時押しを分ければ、小さなコントローラーでもかなり多くの操作を割り当てられる。 現在のプロファイルはJoy-Con本体に表示できないため、パソコン側に小さなステータス表示を出すと誤操作を減らせる。 XボタンへのCtrl+Cの割り当ては、ターミナル操作用プロファイルだけで使う。 別のアプリが前面にあるときに送れば処理を中断する可能性があるため、文脈に依存する割り当てである。
4. Joy-Con固有ボタンが足りなければ構成を変える
QKeyMapperでSL／SRや左右結合を扱えない場合は、JoyShockMapperへ切り替える。 JoyShockMapperからF13〜F24のような普段使わないキーを送り、AutoHotkeyや常駐受信アプリでコマンド起動へ変換すると役割を分けやすい。 PowerShell内だけで操作するなら、PSReadLineのキー割り当ても候補になる。
自作するなら入力と副作用を分ける
専用アプリを作る場合は、次の構成にすると機能を増やしやすい。
Joy-Con
↓ Bluetooth
SDL3
↓ ボタン、スティック、ジャイロ
入力の正規化
↓ Action ID
割り当て判定
├─ キー入力 → SendInput
├─ コマンド実行 → ProcessStartInfo
└─ 対話ターミナル → ConPTY
↓
端末出力、シェルプロセスの終了結果
↓
画面表示、Joy-Con振動
入力の正規化と割り当て判定は、副作用のない関数として作る。 キー送信、プロセス起動、ターミナル通信、振動だけを外側へ分離すると、Joy-Conを接続しなくても割り当てロジックをテストできる。
SDL3のボタン名は物理的な位置を基準にしているため、NintendoのA／B表記とSOUTH／EASTの対応を実機で確認する。
画面上の一般的なゲームパッド表記だけを見て割り当てると、AとBを取り違えやすい。
別のターミナルから結果を通知したい場合は、名前付きパイプなどのローカル通信を追加できる。
たとえば、自作のjoyctl notify successコマンドを受け取った常駐アプリが短く振動し、失敗時は異なるパターンで振動する仕組みである。
SDL3にはSDL_RumbleGamepadがあるが、個々のJoy-Conで振動できるかはAPIの戻り値と実機で確認する必要がある。
このAPIは一般的なゲームパッド振動の入口であり、NintendoのHD Rumble固有の表現を保証するものではない。
コマンド実行では許可リストを使う
Joy-Conから任意の文字列をシェルへ渡す設計は避ける。
ボタンにはbuild、test、git-statusのようなAction IDだけを割り当て、アプリ側で実行ファイルと引数を固定する。
割り当てソフトは各プロジェクトの公式GitHubリポジトリから入手し、まず通常権限で起動する。 管理者権限のターミナルへ入力を送るためだけにソフト全体を昇格させず、追加ドライバーも必要性を確認してから導入する。
削除やデプロイなどの危険な操作と、管理者権限が必要な操作には、同時押し、長押し、画面確認のいずれかを加える。 普段の入力プロファイルからは起動できないように分けると、コントローラーを置いた拍子にボタンを押す誤操作も防ぎやすい。
まとめ
Joy-Conは、Stream Deckのようにボタンへ処理を割り当てる入力デバイスとして使える。 まずはQKeyMapperでキー入力と安全なスクリプト起動を試し、Joy-Con固有入力が必要ならJoyShockMapperを組み合わせるのが早い。
コマンドの終了判定、出力の取得、振動による通知まで欲しくなった時点で、SDL3にプロセス実行機能を組み合わせた専用アプリへ進めばよい。
対話端末まで必要なら、ConPTYとコマンドの成否を通知する仕組みも加える。
ただし、対話端末が不要ならConPTYを使わず、ProcessStartInfoによる小さな常駐ブリッジから始められる。
最初の実機検証では、左右のJoy-Conが別々または1組として認識されるか、SL／SRを含む全ボタンの入力が届くかを確認する。 Bluetoothアダプターによる差、左右2台を同時に使ったときの遅延、スリープ後の再接続も確認項目に加える。