OpenAIから左手デバイス的なのが出たと聞いて、そういえばうちにこれがあったなと思い出したのですが、

Claudeを使っていて地味にストレスなのが「これやっていいですか?」の許可ダイアログ。ファイル編集だ、コマンド実行だと、いちいち聞いてくるたびにキーボードに手を伸ばしてEnterを押す、というのを1日に何十回もやっていて、これは何とかしたいと思っていました。
で、うちには以前から遊んでいるKB16(VIAベースの左手用マクロパッド)があるので、ここに専用の「承認ボタン」を作ってしまおうということでやってみました。

なぜ承認ボタンが欲しくなったか
Claude Codeは便利なのですが、ファイルの編集やコマンド実行のたびに確認ダイアログが出る仕様になっていて(当然といえば当然なのですが)、これが結構な頻度で発生します。作業中は他のウィンドウを見ていることも多いので、そのたびにアプリを探してクリックしてEnter、というのが地味に集中を切る原因になっていました。
じゃあこれ、ワンボタンでできないか?ということで、以前ガジェット記事でも触れたKB16の出番です。空いているキーが1個あったので、そこに専用機能を持たせることにしました。
KB16側:ボタンにキーコードを割り当てる

KB16はVIA対応のマクロパッドなので、専用の設定ツール(VIA)でキーごとに送信するキーコードを自由に変更できます。今回はもともと使っていなかったキー(元はEnter)を、普段使わない組み合わせのキーコードに変更しました。
具体的には「Any」キーコードのタブから Ctrl+Alt+Shift+F12 を送るように設定。単体のF13とかでも良かったのですが、後述するAutoHotkeyでフックする都合上、他のショートカットと絶対に被らない組み合わせにしておくのが無難です。
ただしVIAのマクロだけでは足りない
ここで一つ問題が発生。VIAで設定できるのはあくまで「押したら決まったキーコードを送る」というところまでで、実際には今アクティブになっているウィンドウにキーが送られるだけなんですね。
つまりKB16のボタンを押した瞬間、たまたまブラウザを見ていたらブラウザにキーが送られてしまい、Claude Codeの承認ダイアログには何も起きません。ワンボタンで「どこにいてもClaudeを承認する」を実現するには、ウィンドウを操作するレイヤーがもう一段必要になるわけです。
というわけでAutoHotkeyの出番です。
AutoHotkeyでウィンドウを操作する
考えた動作はこんな感じ。
- 今アクティブなウィンドウを覚えておく
- Claude Codeのデスクトップアプリを強制的に前面に出す
- 承認のキーを送る
- さっき覚えておいたウィンドウに戻す
言葉にすると単純なのですが、実際にやってみるとここからが長かったです。
ハマったポイント①:Enterでは承認されない
最初、素直に Send("{Enter}") で試したのですが、これが動かない。ダイアログにフォーカスは移っているはずなのに反応しないんですね。
色々試した結果、Claude Codeの承認ダイアログで実際に効くキーは普通のEnterではなく Ctrl+Enter だということが判明。地味にハマりポイントでした。
ハマったポイント②:元のウィンドウに戻れない
Ctrl+Enterで承認自体はできるようになったのですが、次に「元のウィンドウに戻す」処理が動かない。WinActivate を素朴に呼んでも、裏で戻そうとしているだけだと何も起きないんです。
これはWindowsの「フォアグラウンドロック」という仕様のようで、今アクティブでないアプリが勝手に自分をアクティブ化しようとしても弾かれる、という制限がかかっているらしい。ボタン一発で完結させたかったのに、最後の最後で他のアプリに手動で切り替えないといけないという、なんとも間抜けな状態になってしまいました。
これを回避するために使ったのが AttachThreadInput というWin32 APIで、いったん自分のスレッドの入力を対象ウィンドウのスレッドにくっつけてから WinActivate を呼ぶと、フォアグラウンドロックを無視して前面化できるという裏技です。これを使ってウィンドウ切り替え用のヘルパー関数を作り、行きも帰りも同じ関数を通すようにしたら無事解決しました。
完成したスクリプト
最終的にこんな感じのAutoHotkey v2スクリプトに落ち着きました。
#Requires AutoHotkey v2.0
#SingleInstance Force
; KB16(VIA)の許可ボタン用グローバルホットキー
; KB16側のキーはEnterではなく Ctrl+Alt+Shift+F12 を送信するようVIAで変更しておくこと
; 動作: 現在アクティブなウィンドウを記憶 → Claudeを前面化 → Ctrl+Enter送信(承認) → 元のウィンドウへ強制的に戻す
ForceActivate(hwnd) {
if !WinExist("ahk_id " hwnd)
return
curHwnd := WinExist("A")
curThread := DllCall("GetWindowThreadProcessId", "ptr", curHwnd, "ptr", 0, "uint")
targetThread := DllCall("GetWindowThreadProcessId", "ptr", hwnd, "ptr", 0, "uint")
if curThread != targetThread
DllCall("AttachThreadInput", "uint", curThread, "uint", targetThread, "int", true)
WinActivate("ahk_id " hwnd)
if curThread != targetThread
DllCall("AttachThreadInput", "uint", curThread, "uint", targetThread, "int", false)
}
^!+F12:: {
prevId := WinExist("A")
if WinExist("ahk_exe claude.exe") {
ForceActivate(WinExist("ahk_exe claude.exe"))
WinWaitActive("ahk_exe claude.exe", , 2)
Sleep(300)
Send("^{Enter}")
Sleep(150)
if prevId
ForceActivate(prevId)
} else {
TrayTip("Claude", "Claudeのウィンドウが見つかりません", 3)
}
}
ポイントは、Claudeのウィンドウをahk_exe claude.exeで掴んでいるところと、行き帰り両方で同じForceActivateを通しているところ。あとは地味にSleepを挟まないとウィンドウの切り替えが間に合わずキーが空振りすることがあったので、300msくらい待たせています。
使ってみた感想

これでKB16の1ボタンを押すだけで、どのウィンドウを見ていてもClaude Codeの承認が飛ばせるようになりました。地味な変更なんですが、いちいちアプリを探してクリックしてという動作がなくなるだけで思った以上に作業のリズムが良くなった気がします。
余談ですが、設定作業の途中でAutoHotkeyのインストール後にClaude Codeのデスクトップアプリがクラッシュするという事件があり、一瞬「まさかAutoHotkeyのせいか」と身構えたのですが、今のところ再発はしておらず単なる偶然だった説が濃厚です。もし同じような症状に遭遇した方がいたら、無関係の可能性が高いですよとだけ伝えておきます。
AI作業がメインになってくると、こういう細かい摩擦を潰していく作業自体が地味に楽しくなってくるので、また便利な設定ができたら紹介したいと思います。
OpenAIから出た左手デバイス「Codex Micro」はどうなの?

それでOpenAIが発表したやつはどうなの?という話ですが、キーボードメーカーのWork Louderと共同開発した「Codex Micro」(kbd-1.0-codex-micro)というやつで、Codexなどのエージェント操作専用のキーパッドです。
13個のメカニカルスイッチにダイヤル、ジョイスティックまで搭載していて、チャットの切り替え、変更の承認・却下、音声入力などがボタン一発でできるらしい。しかもキーごとにRGBが光ってエージェントが今何をしているか(考え中、実行中、待機中、完了)が一目で分かるというギミック付き。値段は230ドル、日本だと37,900円+送料とのこと。うーむ、高い。KB16の方がだいぶ安いですね。
しかし、OpenAIがわざわざ専用ハードウェアとして230ドルで売り出すくらい、この「ワンボタン承認」需要は普遍的にあるということでもあり、地味な機能ながら妙な手応えを感じる設定作業でした。



コメント