2026年開発者向けVSCode拡張機能トップ5

私は「Code - OSS」と呼ばれていた頃からVS Codeを使っています。拡張機能のエコシステムが、私がこれにこだわり続けている主な理由です。毎年、インストールされている拡張機能を監査し、実際に使っていないものは削除しています。この5つは、どんな整理でも生き残ってきました。

1. GitHub Copilot

これは当然ですね。リリース当初は懐疑的でした（以前にもタブ補完ツールを使ったことがありましたが、便利というよりは気が散るだけだと感じていました）。Copilotは、単なる一行だけでなく、ブロックを生成するという点で異なりました。関数シグネチャとコメントを書くと、本体を生成してくれます。半分は正しく、そのまま次に進めます。残りの半分は、ゼロから書くよりも編集する方が速い出発点となります。

コツは、タイピングは速いけれどあなたのコードベースを知らないペアプログラマーのように扱うことです。生成されたものをレビューしましょう。インターフェースを狭く保ち、無意味なものを生成する余地を減らしましょう。

2. ESLint

ESLintについてはもう考えません。ただそこにあり、未定義の変数がランタイムエラーになる前にフラグを立て、一貫したインポートを強制し、些細だけど厄介な種類のバグを捕捉してくれます。私が気にする唯一の設定は、保存時の"source.fixAll.eslint": trueです。これにより、ESLintが尋ねることなく修正できるものはすべて自動修正されます。

3. Prettier

Prettierの価値は、どのスタイルを強制するかではありません。私が保存するたびに、常に自動的にたった一つのスタイルが強制されることです。コードレビューで末尾のカンマやシングルクォートについて議論する必要はありません。"editor.defaultFormatter": "esbenp.prettier-vscode"をチーム設定に入れた時点で議論は終わりました。

4. GitLens

GitLensは主にインラインのblameアノテーションのために使っています。行にカーソルを合わせると、誰がいつ書いたかがわかります。混乱するコードを見ていて、それがまだチームにいる誰かが書いたものなのか、それとも3年前のインターンが書いたものなのかを知る必要があるまでは、些細なことに聞こえるかもしれません。バグがいつ導入されたかを追跡する際には履歴ビューが役立ちますが、私が毎時間使っているのはインラインのblameです。

5. Playwright Test

エンドツーエンドテストを書く場合、この拡張機能はフィードバックループを許容できるものにします。テスト結果がインラインで表示され、テストファイル内でブレークポイントを使ってデバッグでき、codegen機能はブラウザのインタラクションをテストコードに記録します。新しいテストを書くよりも、不安定なテストのデバッグに使うことが多いですが、両方に役立ちます。

おまけ: 私のSettings.json

これらがあなたの人生を変えることはないでしょうが、ちょっとした煩わしさを解消してくれます。

{
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  },
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.tabSize": 2,
  "editor.wordWrap": "on",
  "editor.minimap.enabled": false,
  "explorer.confirmDelete": false,
  "typescript.updateImportsOnFileMove.enabled": "always"
}

ミニマップの設定は賛否両論あります。熱心な人もいるのは知っています。私は、有用な情報を提供せずにスペースを占有していると感じます。1週間オフにしてみて、恋しくなるか試してみてください。

こちらもおすすめ

• 技術文書のための生成エンジン最適化 (GEO)
• 技術ブログにタグのタクソノミーが必要な理由（そして長続きするタクソノミーの作り方）
• Google Search Console活用術：開発ブログを成長させる秘訣
• 副業と不労所得についてこれまでに実際に学んだこと

よくある質問