VS Codeのキーバインドはどこで変更する？

コマンドパレットから「基本設定: キーボードショートカットを開く (JSON)」でkeybindings.jsonを開き、key・command・whenの3つを書いた1エントリを足す。GUIで1個ずつ変えたいなら (JSON) なしの方を選ぶ。

VS Codeで既存のショートカットを無効化するには？

keybindings.jsonに、commandの頭に - を付けたエントリを書く。ctrl+dに -editor.action.addSelectionToNextFindMatch を書けば「同じ単語の次を選択」が外れる。その行を消せば元に戻る。

キーバインドのwhen句は何のためにある？

そのキーが新しいコマンドとして働く場面を絞る条件。inlineSuggestionVisible を付ければインライン補完が出ている時だけ確定キーになり、それ以外の場面では元の動きのまま残せる。

VS Codeのキーバインドカスタムは3つでいい

標準のショートカットを一通り覚えて、実際に毎日使い始めると、別のモヤモヤが出てくるはず。補完の確定とかマルチカーソルとか、1日に何十回も押すキーに限って、指が届きにくい位置にある。「押せるけど、毎回ちょっとストレス」というやつだ。

VS Codeにはkeybindings.jsonという仕組みがあって、キー割り当てを自分用に書き換えられる。変えるのは最小限だけ、壊さずに変えれば足りる。

目次 / INDEX

まず結論：全部いじらない。「頻度×距離」で3つだけ選ぶ

先に結論。キーバインドは全部いじっちゃダメだ。

変えるのは「押す回数が多くて、かつ指が遠い」ものだけ。僕の基準では3つまで。

理由はシンプルで、デフォルトから離れるほど覚え直しのコストがかかるから。キーを1個変えると、そのキーの新しい位置を体に入れ直す期間が必ず発生する。しかも他人のマシンや解説記事のキーが自分の環境と食い違っていく。

だから、変える対象は「毎日何十回も押すのに、ホームポジションから指が遠い」キーに絞る。週に数回しか押さないキーは、遠くても放置でいい。デフォルトの9割はそのままが正解だと思う。

ちなみに、そもそもどのショートカットを覚えるべきかの話は、VS Codeの拡張と設定の記事の後半にまとめてある。

あと身も蓋もない話だけど、押しやすさはキー配置だけの問題でもない。キーボード自体が打ちにくいと、どこに割り当てても遠い。打ち心地で選ぶならキーボードの選び方に3,000円台からまとめている。

keybindings.json の開き方と最小の書き方

開き方は2つある。GUIで変えるなら、コマンドパレット(Ctrl+Shift+P)から「基本設定: キーボードショートカットを開く」。JSONを直接書くなら、同じパレットで「基本設定: キーボードショートカットを開く (JSON)」だ。

僕はJSON直編集をすすめる。GUIは1個ずつポチポチ変える分には楽なんだけど、JSONなら「自分が何をどう変えたか」がファイル1枚で全部見える。変更が3つしかないなら、3行読めば全容が分かる。

1エントリの形はこれだけ。keyに押すキー、commandに実行するコマンドID、whenに発動条件を書く。

{
  "key": "ctrl+enter",
  "command": "editor.action.inlineSuggest.commit",
  "when": "inlineSuggestionVisible"
}

この例だと「インライン補完(ゴーストテキスト)が出ている時にCtrl+Enterを押したら確定」という意味になる。whenの話は後でちゃんとやる。

keybindings.jsonはユーザー単位で、OSごとに保存される。プロジェクトごとに書き分ける必要はない。

変える価値が高い候補（AI補完を使う人向け）

じゃあ具体的にどのコマンドが候補になるか。AI補完を毎日使う人向けに、動かす価値がありそうなものを表にした。

コマンドID	デフォルトのキー(Win)	何に効くか
editor.action.inlineSuggest.commit	Tab	インライン補完(ゴーストテキスト)を確定
editor.action.inlineSuggest.showNext	Alt+]	インライン補完の次の候補
editor.action.inlineSuggest.showPrevious	Alt+[	インライン補完の前の候補
acceptSelectedSuggestion	Tab または Enter	補完候補ウィンドウの選択を確定
editor.action.addSelectionToNextFindMatch	Ctrl+D	同じ単語の次を選択(マルチカーソル)
editor.action.selectHighlights	Ctrl+Shift+L	同じ単語を全部選択
cursorColumnSelectDown	Ctrl+Shift+Alt+↓	縦の列選択(ボックス選択)を下へ
editor.action.rename	F2	シンボル名の一括リネーム

AI補完が中心の人なら、最優先は「補完の確定」と「候補めくり」だ。押す頻度が桁違いに多いから。特に候補めくりのAlt+]は、日本語キーボードだと「]」の位置の関係で押しにくく感じる人が多いはず。

逆にF2のリネームみたいに、頻度がそこまで高くないものは、遠くても後回しでいい。頻度×距離、この掛け算で並べると優先順位は勝手に決まる。

壊さないための when 句とキー衝突チェック

ここが一番大事なところ。キーバインドのカスタムで事故る原因はほぼ2つで、「発動条件を絞ってない」か「既存の割り当てと衝突してる」だ。

まずwhen句。さっきの例に付いていた "when": "inlineSuggestionVisible" は「インライン補完が表示されている時だけ」という条件だ。これを付けないと、そのキーはエディタのどんな場面でも新しいコマンドに取られてしまう。

whenに書ける条件（文脈キー）は他にもある。editorTextFocus(エディタにフォーカスがある時)、suggestWidgetVisible(補完候補ウィンドウが出ている時)あたりを使い分ける。「補完が出ている時だけ確定キーとして働き、それ以外の時は元の動きのまま」に絞れるのがwhenの価値だ。

次に、既存の割り当てをどうしても外したい時。commandの頭に「-」を付けたエントリを書くと、その割り当てを無効化できる。

{
  "key": "ctrl+d",
  "command": "-editor.action.addSelectionToNextFindMatch"
}

これでCtrl+Dから「同じ単語の次を選択」が外れる。元のデフォルト定義を書き換えるんじゃなくて、自分のファイルに「打ち消しの1行」を足す方式だから、消したくなったらこの行を消せば元に戻る。安全だ。

衝突チェックの手順も決まっている。GUIのキーボードショートカット画面を開いて、検索窓に割り当てたいキーをそのまま打つ。

するとそのキーに今何が割り当たっているかが一覧で出る。新しいキーを決める前にここを見る、を習慣にすれば「知らないうちに別の機能を潰してた」は防げる。

Mac と Windows でキーが違う点

MacとWindowsの両方でVS Codeを使う人は1つ注意。keybindings.jsonは端末ごとに別々に保存される。つまりWindowsで書いたkeybindings.jsonが、Macに勝手に反映されるわけじゃない。

読み替えも必要になる。Windowsのctrlは、Macだと多くの場面でcmdに相当する。altはoptionだ。

だから片方の環境で作ったkeybindings.jsonをそのままもう片方に持っていくと、修飾キーの意味がずれて合わないことがある。両方使うなら、それぞれの環境で同じ「意図」のエントリを書き直すつもりでいた方がいい。

これも、変えるキーを3つに絞っておく理由の1つだ。3つなら両環境のメンテも3行で済む。20個変えていたら、たぶん管理しきれない。

まとめ

やることは4つだけ。

頻度×距離で変えるキーを3つまでに絞る
keybindings.jsonに1エントリずつ書く
whenで発動条件を絞る
割り当てる前にGUIの検索窓でそのキーの衝突を確認する

デフォルトの9割はそのままでいい。

まずは今日、自分が一番「遠いな」と感じているキーを1個だけ書き換えてみてほしい。1個変えて数日使えば、2個目を変えるべきかどうかは指が教えてくれる。

同じ「打鍵を減らす」発想の続きとして、毎回同じコード片を打ってるならスニペット自作の話、毎回同じコマンドを打ってるならtasks.jsonの話もどうぞ。