Skip to content
Published on

VS Code 必須拡張機能 2026 — GitLens / Error Lens / Pretty TypeScript Errors / Tailwind / Prisma / Biome 深掘りガイド

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

「エディタは骨格で、拡張機能は筋肉だ。筋肉がなければ骨格は椅子に座ったままだ。」— あるシニアフロントエンドエンジニア

本記事は 2026年5月時点のVS Code拡張機能市場の地図 である。2024〜2025年にかけてAI拡張機能が主流になり、市場の重心が一気にずれた。GitHub Copilotがデフォルトになり、Codeium/Cody/Tabnineといった無料の選択肢がその隣に並び、ContinueとClineがBYOK(Bring Your Own Key)陣営を作った。一方の非AI領域では、GitLens(GitKraken)がGit UIの事実上の標準として固まり、Error LensとPretty TypeScript Errorsが「エラーはインラインで見るべき」というUXの合意を成立させた。

本記事はGit系(GitLens, GitHub Pull Requests)、UI改善(Path Intellisense, Error Lens, Pretty TypeScript Errors, Indent Rainbow, vscode-icons, Material Icon Theme)、言語/フレームワーク(Tailwind CSS IntelliSense, Prisma, ESLint, Prettier, Biome, Even Better TOML, Dependi)、AI(Tabnine, Codeium, Cody, GitHub Copilot, Continue, Cline)、ワークフロー(REST Client, ThunderClient, ShellCheck, EditorConfig, Polacode, Quokka.js, Code Tour, Project Manager, Live Server, Markdown All in One, Vim/Neovimモード)に分類して比較する。最後に韓国のトス/カカオ、日本のメルカリ/ZOZOの推奨拡張を確認し、「あなたは何を入れるべきか」という意思決定ガイドで締める。

1. 2026年のVS Code拡張機能マップ — 4分類

2026年のVS Code拡張機能を理解するには、まず分類が必要だ。Marketplaceには60,000を超える拡張機能があり、「全部入れる」は答えにならない。拡張機能はメモリであり、拡張機能ホストプロセスのCPU消費であり、起動時間そのものだ。

  • Git系: GitLens(GitKraken), GitHub Pull Requests, Git Graph, Git History
  • エラー/UI改善: Error Lens, Pretty TypeScript Errors, Path Intellisense, Indent Rainbow, vscode-icons, Material Icon Theme
  • 言語/フレームワーク: Tailwind CSS IntelliSense, Prisma, ESLint, Prettier, Biome, Even Better TOML, Dependi
  • AIアシスタント: GitHub Copilot, Codeium, Tabnine, Cody, Continue, Cline
  • ワークフロー系: REST Client, ThunderClient, ShellCheck, EditorConfig, Polacode, Quokka.js, Code Tour, Project Manager, Live Server, Markdown All in One
  • エディタモード: Vim, Neovim, VSCodeVim

分類が重要なのは、それぞれが負う責任の境界が違うからだ。Git系は「なぜこのコードはこうなっているのか」を示し、UI改善は「いま画面で何を見ればよいのか」を明確にし、言語/フレームワーク系は「タイピングを助けてくれ」を担う。AIアシスタントは「コードを代わりに書いてくれ」を引き受け、ワークフロー系は「エディタから出させないでくれ」を担当する。

最も多い失敗は 同じカテゴリで機能が重複する拡張を同時に入れる ことだ。2026年に典型的な衝突は、ESLint + Prettier + Biomeを3つ全部入れる(Biomeは単体使用で本領発揮)、vscode-icons + Material Icon Themeの両方を有効化(同じcontribution pointを取り合うのでどちらか一方しか動かない)、GitHub Copilot + Codeium + Tabnineの3つ全部で自動補完を有効化(トリガーが衝突して提案がどちらも消える)など。1カテゴリにつき1つだけ が2026年のベストプラクティスだ。

もう一つの大きな流れは AI拡張が非AI拡張を吸収する 動きだ。Tabnineは最初は単純な自動補完だったが、いまはAI ChatとCode Reviewも提供する。Codeiumは無料AIから始まり、自社IDE「Windsurf」まで作った。GitHub CopilotはWorkspaceとAgent Modeを追加し、事実上の小型エージェントになっている。この流れにより、「AIアシスタント拡張1つ」の比重がどんどん大きくなる。

2. GitLens — Git履歴の標準

GitLensは2016年にEric Amodioが作った拡張機能で、2022年にGitKrakenに買収された。2026年現在、Marketplaceダウンロード3,500万回を超え、事実上のGit拡張機能の標準となっている。VS Codeの標準Git UIが意図的にミニマルなため、GitLensは「Gitを真剣に使うなら必ず入れる」拡張機能になった。

主な機能:

  • インラインblame: カーソル行の最終コミット情報を行末にグレーで表示
  • ホバー情報: 行にマウスを乗せるとコミットメッセージ、作成者、diffプレビューを表示
  • File / Line history: 1ファイルまたは1行の全変更履歴を1画面で
  • Compare view: 任意のブランチ/コミット/スタッシュを比較
  • Repositories view: ワークスペース内のすべてのリポジトリのブランチ/リモート/タグ/スタッシュをツリー表示
  • Worktree管理: worktreeの作成/切替/削除をUIで
  • Commit Graph: コミットグラフ専用タブ。一時Pro機能だったが2024年に無料化
  • Visual File History (Pro): ファイルの変化を時間軸で可視化
// .vscode/settings.json — GitLensを軽くする設定
{
  "gitlens.codeLens.enabled": false,
  "gitlens.currentLine.enabled": true,
  "gitlens.hovers.currentLine.over": "line",
  "gitlens.statusBar.enabled": true,
  "gitlens.blame.format": "${author|agoOrDate}",
  "gitlens.views.repositories.files.layout": "tree"
}

GitLensの強み:

  • 視覚的なblameで責任追跡が30秒: 「この行なんでこうなってんの?」に即答できる
  • GUIでのWorktree管理: 他にほぼ存在しないツール。2025年にClaude Code/Cursorがworktreeワークフローを後押ししたことで再注目
  • GitKraken買収後もコアは無料。ProはVisual File History/Workspaceなど高度な機能のみ

GitLensの弱み:

  • デフォルト設定がうるさい: CodeLensが全関数の上に小さな文字を出すのでブロックノイズになりがち → codeLens.enabled: false を推奨
  • 低スペックマシンで重い: 大きなリポジトリ(10万コミット超)ではインデックスに時間がかかる
  • Pro機能の増加: 2022年の買収以降、一部機能が有料へ。ただしコア機能(blame, hover, history)は無料維持

誰が入れるべきか: Gitを毎日使う全開発者。事実上のデフォルト。代替としてはGit Graph(軽量)、Git History(ファイル/行履歴特化)、GitLensの3択で、GitLensが最も総合的だ。

3. Path Intellisense / Error Lens / Pretty TypeScript Errors — UI改善3兄弟

この3つは「VS Codeの素のUIを一段上に」引き上げる拡張機能だ。2026年時点で新規開発者が最初にインストールする束でもある。

Path Intellisense (Christian Kohler)

importやrequireの中でファイルパスを自動補完する。VS Codeの組み込み補完もあるが、Path Intellisenseの方が高速かつ正確で、モノレポの@workspace/...のようなエイリアスにも対応する。

{
  "path-intellisense.mappings": {
    "@app": "${workspaceFolder}/src/app",
    "@components": "${workspaceFolder}/src/components"
  },
  "path-intellisense.showHiddenFiles": false,
  "path-intellisense.extensionOnImport": true
}

ダウンロード1,000万回超え。2026年時点で大半のワークフローで初日に入る拡張機能だ。

Error Lens (Alexander)

AlexanderによるError Lensは、診断メッセージ(error/warning/info)を行末にインラインで表示する。標準のVS Codeは診断メッセージを見るためにマウスを乗せる必要があるが、Error Lensはそれを画面に貼り付ける。

{
  "errorLens.enabled": true,
  "errorLens.fontSize": "12px",
  "errorLens.messageBackgroundMode": "none",
  "errorLens.gutterIconsEnabled": true,
  "errorLens.followCursor": "allLines",
  "errorLens.excludeBySource": [
    "cSpell"
  ]
}

賛否が分かれる拡張機能だ。「画面がうるさい」という批判と、「一度慣れたら戻れない」という擁護が並走する。折衷案として followCursor: "activeLine" で現在行のみ表示する方法がある。ダウンロード700万回超。

Pretty TypeScript Errors (yoavbls)

TypeScriptのエラーメッセージは悪名高い。長く、ネストし、どこから読めばよいのか分からない。Pretty TypeScript Errorsはそれを構造化して表示する。型の比較、欠落プロパティ、関数シグネチャの不一致を色とインデントで表現する。

// 標準のTSエラー — 一行で長すぎる
// Type 'NewUser' is not assignable to type 'User'. ... missing the following properties from type 'User': id, createdAt

// Pretty TypeScript Errors が見せるもの
// type mismatch: NewUser vs User
//   Missing properties:
//   - id: number
//   - createdAt: Date

特にReact/Next.js/tRPCで毎日ジェネリック型エラーに会う開発者には必須。ダウンロード500万回超。

この3つの共通点は 「既存の情報をもっとよく見せる」 ことだ。新機能を追加するのではなく、既にある診断/型/パスの情報を読みやすく再配置している。だからほぼ全てのワークフローに無害に追加できる。

4. vscode-icons vs Material Icon Theme — アイコン戦争

VS Codeのサイドバーのファイルアイコンを変える2つの拡張機能。どちらか1つしか有効化できない(同じcontribution pointを取り合う)。2026年時点で両者はほぼ互角で市場を二分している。

vscode-icons (icons-for-visual-studio-code チーム)

  • ダウンロード1,800万回超 (2026年5月時点)
  • 対応ファイルタイプのバリエーションが豊富
  • フォルダアイコンが平面的で単純
  • React/Vue/Angularなどフレームワーク別アイコンの厚みが深い
  • 彩度が比較的高い

Material Icon Theme (Philipp Kief)

  • ダウンロード2,500万回超 (2026年5月時点)
  • Material Designガイドラインに準拠
  • フォルダアイコンが立体的で塗りつぶされた形状
  • 新規フレームワーク対応が速い(Next.js App Router, Astro, Bunなど)
  • 落ち着いた配色でダークテーマと相性が良い
{
  "workbench.iconTheme": "material-icon-theme",
  "material-icon-theme.folders.theme": "specific",
  "material-icon-theme.activeIconPack": "nest",
  "material-icon-theme.hidesExplorerArrows": true
}

選択ガイド:

  • ダークテーマ + Next.js/Astro/Bunなど新規ツール: Material Icon Themeが馴染む
  • ライトテーマ + 多言語混在: vscode-iconsが直感的
  • モノレポでフォルダ階層が深い: Material Icon Themeのフォルダ立体感が役立つ
  • 好み: 結局どちらも良い。1週間ずつ試して決めるのが正解

2026年のトレンドはMaterial Icon Themeが微差で優勢。ただしフォルダの立体感が強すぎるとして「素朴なvscode-iconsが好き」というユーザーも依然多い。

5. Indent Rainbow — 視覚補助の元祖

oderwatのIndent Rainbowはインデントレベルを色分けする。Pythonのようにインデントが文法の言語で特に有効だ。2025年時点ではVS Code組み込みの「bracket pair colorization」が似た効果を提供するため必須度は下がったが、Python/YAML開発者には依然人気がある。

{
  "indentRainbow.colors": [
    "rgba(255,255,64,0.07)",
    "rgba(127,255,127,0.07)",
    "rgba(255,127,255,0.07)",
    "rgba(79,236,236,0.07)"
  ],
  "indentRainbow.ignoreLinePatterns": [
    "/[ \t]* [*]/g"
  ],
  "indentRainbow.tabmixColor": "rgba(255,127,127,0.3)"
}

長所:

  • Python/YAML/Kubernetesマニフェスト でインデントレベルを瞬時に把握
  • アルファ値を下げると邪魔にならない
  • tab/space混在の検出(tabmixColor)

短所:

  • 画面がうるさくなる可能性あり → アルファ値を0.05〜0.1に抑えて使うのが推奨
  • VS Codeのbracket pair colorizationと視覚的に重なる場合がある

代替としてはBracket Pair Color DLW(deprecated、組み込み機能で代替)、Rainbow CSV(CSV専用)など。2026年の推奨: Python/Kubernetesを頻用するなら入れる、それ以外は必須ではない。

6. Dependi (旧 Crates) — Rustの依存をインラインで

RustのCargo.tomlでcrateバージョンの隣に最新版情報をインライン表示する拡張機能だ。もともとの名前は「crates」だったが、2023年にメンテナが交代した際に「Dependi」へリブランドし、Rustだけでなくnpm(package.json)、PHP(composer.json)、Python(pyproject.toml/requirements.txt)、Go(go.mod)など複数のパッケージマネージャに対応するようになった。

# Cargo.toml — Dependiが最新版をインライン表示
[dependencies]
serde = "1.0.197"     # latest: 1.0.219
tokio = "1.36.0"      # latest: 1.41.0
clap = "4.5.4"        # latest: 4.5.21

{
  "dependi.npm.indexServerURL": "https://registry.npmjs.org",
  "dependi.rust.indexServerURL": "https://crates.io",
  "dependi.vulnerability.ghsa.enabled": true,
  "dependi.vulnerability.osv.enabled": true
}

長所:

  • バージョン更新の判断が速い: Cargo.tomlで直接見て直す
  • 脆弱性表示: GHSA/OSVデータベースを照会し、CVEがあるバージョンを赤くハイライト(2024年追加)
  • 多言語対応: Rust以外にnpm/Python/Go

短所:

  • プライベートレジストリは別途設定が必要
  • 大きなモノレポで全ファイルをインデックスすると遅くなる

Rust開発者なら問答無用で入れる。Node開発者も入れておくと便利(ただしRenovate/Dependabotの自動化と重複する場合あり)。

7. Vim / Neovimモード — マウスなしで

VS CodeでVimキーバインドを使うには2つの選択肢がある。

VSCodeVim (vscodevim)

  • ダウンロード7,000万回超、事実上の標準
  • 純粋なJavaScriptでVimモードをエミュレート
  • Visual/Normal/Insert/Commandモード、exコマンド、マクロ、leaderキー定義などほぼ全Vim機能をサポート
  • 一部 .vimrc 互換
{
  "vim.useSystemClipboard": true,
  "vim.useCtrlKeys": true,
  "vim.hlsearch": true,
  "vim.leader": "<space>",
  "vim.normalModeKeyBindingsNonRecursive": [
    {
      "before": ["<leader>", "w"],
      "commands": ["workbench.action.files.save"]
    },
    {
      "before": ["<leader>", "f"],
      "commands": ["workbench.action.quickOpen"]
    }
  ],
  "vim.handleKeys": {
    "<C-d>": true,
    "<C-f>": false
  }
}

短所: 本物のNeovimのLuaプラグインは使えない。複雑なマクロ/プラグインは無理。

vscode-neovim (asvetliakov)

  • ダウンロード200万回超
  • 実際のNeovimバイナリをバックエンドとして起動し、init.lua/init.vimをそのまま使える
  • VSCodeVimよりも互換性が高い(TelescopeなどUIプラグインの一部を除く)
  • セットアップが少し複雑(Neovim 0.10+ が必要)
{
  "vscode-neovim.neovimExecutablePaths.darwin": "/opt/homebrew/bin/nvim",
  "vscode-neovim.neovimInitVimPaths.darwin": "~/.config/nvim/init.lua",
  "vscode-neovim.useWSL": false
}

選択ガイド:

  • Vimキーバインドだけ欲しい: VSCodeVim
  • 既にNeovim init.luaを管理している: vscode-neovim
  • 会社の方針で外部バイナリ禁止: VSCodeVim一択

2026年時点で新規Vim利用者はVSCodeVimから始め、既存のNeovimユーザーがVS Codeに片足を置くときにvscode-neovimを使うパターンが一般的だ。

8. AI拡張機能 — Tabnine / Codeium / Cody / Copilot / Continue / Cline

2026年のAI拡張機能市場は6つの主要プレイヤーで整理された。それぞれポジションが違う。

GitHub Copilot (GitHub/Microsoft)

  • 事実上のデフォルト。月10ドル(個人)、無料ティアも追加(2024年12月)
  • Chat / Workspace / Agent Mode の3インターフェース
  • モデル: GPT-4o, Claude Sonnet 3.5/3.7, Geminiなどを選択可能(Pro+以上)
  • 強み: Microsoftインフラ統合、MFA/SSO、エンタープライズガバナンス
  • 弱み: コンテキストウィンドウがCursor/Continueより小さい

Codeium (Codeium Inc., 現 Windsurf)

  • 個人利用は無料
  • 70言語以上の自動補完
  • 2024年からCascade Chat (long-context)、2025年から自社IDE「Windsurf」をリリース(Cursorと直接競合)
  • 強み: 無料、補完応答が速い、エンタープライズ価格も合理的
  • 弱み: コードベースインデキシングがCopilotより弱い

Tabnine (Tabnine Ltd.)

  • 最古参のAI自動補完(2018年から)
  • ローカルモデルオプション: 個人データをクラウドに送らないワークフロー
  • 2024年にTabnine Chat、2025年にTabnine Code Reviewを追加
  • 強み: セキュリティ要件の厳しい環境(金融/医療/防衛)に安全
  • 弱み: 自動補完の品質はCopilot/Codeiumより弱い

Cody (Sourcegraph)

  • Sourcegraphのコード検索インフラを活用
  • コードベースコンテキストが最強: モノレポ全体をコンテキストに取り込む
  • 2024年にAgentic Context(関連ファイルを自動探索)
  • 強み: 大規模コードベースで精度が高い
  • 弱み: Sourcegraphのセットアップが前提

Continue (Continue Dev)

  • OSS, BYOK (Bring Your Own Key)
  • OpenAI/Anthropic/Ollama/ローカルモデルを接続可能
  • 2025年に .continue/config.yaml でチーム別ルール設定をサポート
  • 強み: モデル費用を直接管理、自社LLMゲートウェイを使う企業に好相性
  • 弱み: 設定の複雑さ、UXがCopilotより粗い

Cline (旧 Claude Dev)

  • OSS, エージェント中心: 単純な補完ではなく「このタスクをやって」に最適化
  • 主にAnthropic Claudeを使うが、OpenRouter経由で多数のモデルに対応
  • 2025年にPlan/Actモード分離、MCPサーバー統合
  • 強み: タスクを委任できる実用的エージェント
  • 弱み: トークンコストが高い(エージェント特性)
// 同時に1つだけ有効にしておくと心の平和が保てる
{
  "github.copilot.enable": {
    "*": true,
    "plaintext": false,
    "markdown": true
  },
  "github.copilot.editor.enableAutoCompletions": true,
  "continue.enableTabAutocomplete": false,
  "codeium.enableConfig": {
    "*": false
  }
}

選択ガイド:

  • 基本選択: GitHub Copilot。会社が買ってくれるならなお良い
  • 無料優先: Codeium、またはContinue + 無料モデル
  • セキュリティ重視: Tabnine(ローカルモデルオプション)
  • 大規模モノレポ: Cody
  • エージェント作業必要: Cline
  • 自社LLMゲートウェイあり: Continue

重要: 自動補完拡張を2つ以上同時に有効化するとトリガーが衝突し両方の提案が消える。一度に1つだけ有効化しよう。

9. Tailwind CSS IntelliSense / Prisma — フレームワーク密着型

フレームワークが提供する公式拡張機能のうち最もよくできた2つだ。

Tailwind CSS IntelliSense (Tailwind Labs)

Adam Wathanを含むTailwindチーム公式の拡張機能。Tailwindを使うなら問答無用で入れる。

  • クラス自動補完(現在の設定ベース)
  • ホバーで実CSSプレビュー
  • カラークラスの隣に色見本
  • 未ソートのクラスへの警告
  • カスタムクラス(apply, theme function)対応
  • 2024年からTailwind v4 alphaサポート、2025年から v4 正式サポート
{
  "tailwindCSS.experimental.classRegex": [
    ["cva\\(([^)]*)\\)", "[\"'`]([^\"'`]*).*?[\"'`]"],
    ["cx\\(([^)]*)\\)", "(?:'|\"|`)([^']*)(?:'|\"|`)"]
  ],
  "tailwindCSS.includeLanguages": {
    "typescript": "javascript",
    "typescriptreact": "javascript"
  },
  "editor.quickSuggestions": {
    "strings": "on"
  }
}

cva/cx/clsx/twMerge のようなヘルパー関数の中でも補完を効かせるには、上のような正規表現設定が必要だ。

Prisma (Prisma)

Prisma公式の拡張機能。schema.prismaのシンタックスハイライト、自動補完、フォーマット、モデル間リレーションのjump-to-definitionに対応する。

{
  "[prisma]": {
    "editor.defaultFormatter": "Prisma.prisma",
    "editor.formatOnSave": true
  },
  "prisma.fileWatcher": true
}

特にschema.prismaのmodel間のリレーション補完と、@@index/@relationオプションの補完が強力。Prismaを使うなら問答無用で入れる。

他のフレームワーク密着型拡張:

  • Vue / Volar (Vue Tooling): Vue公式、Vue 3 + TypeScriptに必須
  • Svelte (Svelteチーム): Svelte公式
  • Astro (Astroチーム): Astro公式
  • Solid (community): Solid.js
  • Angular Language Service (Angularチーム): Angular公式

共通パターン: フレームワーク本家チームの公式拡張機能は、ほぼ常にサードパーティ代替より良い。

10. ESLint / Prettier / Biome — linter + formatter

2026年のJS/TSエコシステムで最も騒がしい領域。3ツールのポジションが分かれた。

ESLint (ESLintチーム)

  • JavaScript標準リンター
  • 2024年に v9 flat config に移行(eslint.config.js)
  • 拡張機能は dbaeumer.vscode-eslint
  • 強み: プラグインエコシステムが圧倒的(@typescript-eslint, eslint-plugin-react, eslint-plugin-importなど)
  • 弱み: 遅い、設定が複雑

Prettier (Prettierチーム)

  • JS/TS/HTML/CSS/JSON/Markdown フォーマッタ
  • 拡張機能は esbenp.prettier-vscode
  • 強み: 「選択肢のなさ」哲学が大半のプロジェクトで標準化
  • 弱み: 一部オプションが少ない(Biome比較)、プラグインシステムが弱い

Biome (Biomeチーム, 旧 Rome)

  • Rust製の統合ツール (linter + formatter)
  • 2024年に v1 stable、2025年に v2 リリース(TypeScript type-aware ルール追加)
  • 拡張機能は biomejs.biome
  • 強み: 速い(Rust)、単一ツール、設定がシンプル
  • 弱み: プラグインエコシステムがESLintより貧弱、一部のESLintルール未対応
// .vscode/settings.json — ESLint + Prettier の組み合わせ
{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit"
  },
  "eslint.experimental.useFlatConfig": true,
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  }
}

// .vscode/settings.json — Biome 単体 (ESLint + Prettier を置き換え)
{
  "editor.defaultFormatter": "biomejs.biome",
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "quickfix.biome": "explicit",
    "source.organizeImports.biome": "explicit"
  },
  "[typescript]": {
    "editor.defaultFormatter": "biomejs.biome"
  }
}

2026年の選択ガイド:

  • 新規プロジェクト、シンプルさ重視: Biome単体
  • 既存ESLintルールが多いプロジェクト: ESLint + Prettier 維持
  • モノレポ + 高速CI必要: Biome(Rust速度の優位)
  • React Native, Expoなど特殊環境: ESLint + Prettier(プラグイン依存)

重要: ESLint + Prettier + Biome の3つ全部を入れると、保存時にフォーマットが衝突しコードが行ったり来たりする。1カテゴリにつき1つだけ有効にしよう。

11. Even Better TOML / Markdown All in One — マークアップ

Even Better TOML (tamasfe)

TOMLファイル(Cargo.toml, pyproject.toml, netlify.tomlなど)用の拡張機能。シンタックスハイライト、自動補完、検証、フォーマットに対応。

{
  "[toml]": {
    "editor.defaultFormatter": "tamasfe.even-better-toml",
    "editor.formatOnSave": true
  },
  "evenBetterToml.schema.associations": {
    "Cargo\\.toml": "https://json.schemastore.org/cargo.json",
    "pyproject\\.toml": "https://json.schemastore.org/pyproject.json"
  }
}
  • JSON Schema連携: Cargo.tomlで間違ったキーを書くと赤い波線
  • Tombi という別のLSPバックエンドを使用(2024年から)
  • フォーマットの安定性: コメント保持、ソートオプションが豊富

Rust/Python開発者に必須。ダウンロード800万回超。

Markdown All in One (Yu Zhang)

Markdownファイルの編集に必要なほぼすべての機能を集めた拡張機能。

  • キーボードショートカット(Ctrl+B 太字、Ctrl+I イタリック)
  • 自動目次生成/更新
  • リスト自動連番
  • テーブルフォーマット
  • 数式プレビュー(KaTeX)
  • プレビューとエディタの同期
{
  "markdown.extension.toc.levels": "2..6",
  "markdown.extension.toc.updateOnSave": true,
  "markdown.extension.preview.autoShowPreviewToSide": false,
  "markdown.extension.list.indentationSize": "adaptive",
  "markdown.extension.tableFormatter.normalizeIndentation": true
}

ブログをMDXで書く人、READMEを頻繁に更新する人、技術文書を書く人みんなに有用。ダウンロード1,300万回超。

代替:

  • Markdown Preview Enhanced: より強力なプレビュー(mermaid, plantuml, presentation mode)
  • markdownlint: リント専用

12. Live Server (Ritwick Dey) — HTMLプレビュー

Ritwick DeyのLive Serverは静的HTMLをローカルサーバーで立ち上げ、ファイル変更で自動リロードする。ダウンロード4,000万回超で、VS Code Marketplaceでも最上位レベルの拡張機能だ。

{
  "liveServer.settings.port": 5500,
  "liveServer.settings.donotShowInfoMsg": true,
  "liveServer.settings.donotVerifyTags": true,
  "liveServer.settings.CustomBrowser": "chrome"
}

長所:

  • クリック1回でローカルサーバー: index.html上で右クリック → 「Open with Live Server」
  • 自動リロード: HTML/CSS/JS変更時にブラウザが自動再読み込み
  • モバイルテスト: 同一ネットワークでIP接続可

短所:

  • 積極的なメンテナンスが停止状態: 2022年以降の大きな更新なし
  • モジュールimport対応が弱い: ES module importは別途設定が必要
  • HTTPS非対応 (コミュニティforkのFive Serverは対応)

代替:

  • Five Server: Live Server fork、HTTPS/HTTP2対応
  • Live Preview (Microsoft公式): 組み込みプレビュー、外部ブラウザ不要
  • Vite/Next.jsなどフレームワークのdevサーバ: フレームワークを使うならLive Serverは必須ではない

2026年の推奨: 純粋なHTML/CSS学習段階なら入れる、フレームワーク案件はdevサーバで十分。

13. REST Client / ThunderClient — APIテスト

VS Code内でPostman/Insomniaを代替する。

REST Client (Huachao Mao)

.httpまたは.restファイルにHTTPリクエストをプレーンテキストで書いて実行する。

### GET ユーザー情報
GET https://api.example.com/users/1
Authorization: Bearer {{token}}
Accept: application/json

### POST 新規ユーザー
POST https://api.example.com/users
Content-Type: application/json

{
  "name": "Alice",
  "email": "alice@example.com"
}

### 環境別変数
@baseUrl = https://api.example.com
@token = abc123

長所:

  • プレーンテキストファイル: Gitにコミットしてチームと共有可
  • Postman コレクション import 可
  • 変数/環境: settings.jsonに環境別変数
  • レスポンス保存: 後続リクエストで前のレスポンス値を参照可

ダウンロード800万回超。APIテストをGitに残したいチームに最適。

ThunderClient (Ranga Vadhineni)

GUIベースのAPIクライアント。PostmanをVS Code内で直接模した雰囲気。

長所:

  • UIが直感的: Postman利用者に馴染む
  • コレクション/環境管理: フォルダツリー構造
  • テストスクリプト: JSでレスポンス検証

短所:

  • 2023年から相当部分が有料化: コレクション5個まで、チーム同期は有料
  • Open Source姿勢の後退: 一時OSSだったが徐々にクローズ化

2026年の選択ガイド:

  • プレーンテキスト + Git共有: REST Client
  • GUI志向、Postmanからの移行: ThunderClient(ただし課金方針を確認)
  • チーム共通のAPIカタログ: 両方とも力不足、Bruno/Hoppscotchの検討を

14. ShellCheck / EditorConfig — スタイル番人

ShellCheck (Timon Wong)

bash/shスクリプトの静的解析。ShellCheck本体はOSSツールで、VS Code拡張はその結果を表示する役割。

#!/bin/bash
# ShellCheckが検出する典型例

# SC2086: クォート漏れ(単語分割の危険)
files=$1
ls $files          # warning

# SC2046: $()の結果をクォート無しで利用
files=$(ls *.txt)
echo $files        # warning

# 正しい書き方
ls "$files"
echo "$files"

{
  "shellcheck.enable": true,
  "shellcheck.run": "onSave",
  "shellcheck.exclude": ["SC2086"],
  "shellcheck.customArgs": ["-x"]
}

長所:

  • bashの落とし穴をほぼ網羅: クォート、変数展開、exit code処理
  • CI連携可: 同じルールをローカルとCIで適用

短所:

  • ShellCheckバイナリのインストールが必要(brew install shellcheck)
  • POSIX以外のシェルは部分サポート: zsh/fishは限定的

DevOps/SRE職に必須。ダウンロード200万回超。

EditorConfig (EditorConfig チーム)

.editorconfigファイルを読み取り、インデント/改行/エンコーディングをプロジェクト単位で統一する。ほぼ全IDE/エディタがサポートするので、IDEが混在するチームに必須。

# .editorconfig
root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.{md,mdx}]
trim_trailing_whitespace = false

[Makefile]
indent_style = tab

長所:

  • エディタ統一: VS Code/IntelliJ/Vim/Sublime全てに対応
  • 言語別ルール: Markdownは末尾空白保持、Makefileはタブ
  • 設定がシンプル: 1ファイル、1度書くだけ

短所:

  • Prettier/Biomeと一部重複 → 優先順位を決めておく

2026年の推奨: 全新規プロジェクトに .editorconfig を追加。拡張機能は無料 + 無害。

15. Polacode / Quokka.js / Code Tour — デモ/スクラッチ/ツアー

この3つは「珍しいが、特定の状況では唯一解」となるツール群だ。

Polacode (P. Cong)

コードブロックを綺麗な画像でキャプチャする。Twitter/ブログ/発表資料にコードを載せる用途。

  • 選択範囲をPNGとして保存
  • 背景グラデーション/パディング/影をカスタマイズ
  • 現在のVS Codeテーマ/フォントをそのまま反映

代替: Carbon (carbon.now.sh), Ray.so, CodeSnap (VS Code拡張)。2026年時点ではCarbonの方が人気だが、Polacodeはエディタ内で完結する利点がある。

Quokka.js (Wallaby.js)

JavaScript/TypeScriptスクラッチパッド。コードを書くと同時に行ごとの結果がインラインで表示される。

// Quokkaが評価結果をインラインで表示
const arr = [1, 2, 3, 4, 5]
const sum = arr.reduce((a, b) => a + b, 0)  // 15
const avg = sum / arr.length                  // 3

const fetched = await fetch('https://api.example.com/data').then(r => r.json())
console.log(fetched)                          // { id: 1, ... }
  • 無料(Community Edition)と有料(Pro)に分離
  • ProはImport自動追加、リッチな出力、JSXプレビューなど
  • アルゴリズム練習/デバッグ/APIレスポンス探索に有用

代替: Node REPL、ブラウザコンソール、replit、Observable。Quokkaは「エディタ内ですぐに」という強みがある。

Code Tour (Microsoft)

コードベースにガイドツアーを作る拡張機能。スライドのように「このファイルのこの行を見て、次はこの関数」と段階的に案内する。

// .tours/onboarding.tour
{
  "title": "新メンバーのオンボーディング",
  "steps": [
    {
      "file": "src/app.ts",
      "line": 1,
      "description": "アプリ起点。dotenv読み込み後、server.tsへ委譲する。"
    },
    {
      "file": "src/server.ts",
      "line": 24,
      "description": "Expressミドルウェア登録。CORS/auth/errorの順序が重要。"
    }
  ]
}
  • オンボーディング自動化: 新入社員が自分のペースでコードベース探索
  • PR説明: 大きなPRの変更点をツアーにまとめる
  • OSSチュートリアル: 外部コントリビュータに「ここから読んで」ガイド

ダウンロード100万回超。使用頻度は低いが、一度作れば半年〜1年は価値がある。

16. Project Manager / GitHub Pull Requests — ワークフロー

Project Manager (Alessandro Fragnani)

複数プロジェクトを高速に切り替える拡張機能。VS Code組み込みの「Recent Workspaces」より強力。

  • お気に入りプロジェクトの保存: タグ/色でグループ化
  • Gitリポジトリ自動検出: 指定フォルダ配下の全gitリポジトリを自動認識
  • VSCode Remote対応: SSH/WSL/Container環境の切替
{
  "projectManager.git.baseFolders": [
    "~/dev",
    "~/work"
  ],
  "projectManager.git.maxDepthRecursion": 3,
  "projectManager.sortList": "Recent",
  "projectManager.openInNewWindowWhenClickingInStatusBar": true
}

ステータスバーに現プロジェクト名が表示され、クリックすると一覧が出る。複数クライアント/副業プロジェクトを並行する開発者に必須。

代替: Workspace Explorer, Peacock(プロジェクト毎の色を自動変更)。Project Managerが最も完成度が高い。

GitHub Pull Requests (GitHub)

GitHub公式の拡張機能。VS Code内でPRを作成・レビューする。

  • PR作成/checkout/レビュー/マージをエディタ内で
  • インラインコメント: GitHub.comのレビューUIをエディタに再現
  • Copilot for Pull Requests連携 (Pro+)
  • Codespaces連携: PRをCodespaceで開く
{
  "githubPullRequests.pullBranch": "always",
  "githubPullRequests.defaultMergeMethod": "squash",
  "githubPullRequests.notifications": "pullRequests"
}

長所: GitHubで作業するほぼすべてのチームに有用。CLI(gh)と併用するとキーボード/GUIの両方が速い。

短所: GitLab/Bitbucketは未対応(別途拡張機能が必要)。

代替: GitLensのPR連携(一部機能)、GitHub CLI(ターミナル派)。

17. 韓国 / 日本 — トス、カカオ、メルカリ、ZOZO

会社別の推奨拡張プールを比較する。出典は各社の技術ブログと公開カンファレンス資料。

トス (Toss / Viva Republica)

トスのフロントエンドチャプターが公開した拡張機能パック(2024〜2025年のToss SLASHカンファレンス資料ベース):

  • ESLint + Prettier(Biomeは一部新規プロジェクトで試験運用)
  • GitLens
  • Tailwind CSS IntelliSense(デザインシステムtdsに紐付く)
  • Error Lens, Pretty TypeScript Errors
  • GitHub Copilot(全社導入)
  • Code Spell Checker(英文タイポチェック)
  • 自社製拡張: TDS Component Snippet(デザインシステムコンポーネントの自動補完)

トスは「フロントエンドファンダメンタルチャプター」単位で道具を標準化した。新入社員は初日に同じ拡張機能パックを入れる。

カカオ (Kakao)

カカオはFE/BEチャプターごとに推奨が異なる(Kakao Tech Blog参照):

  • 共通: GitLens, Error Lens, ESLint, Prettier
  • BE (Java/Spring): Spring Boot Tools, Lombok, Maven for Java
  • FE: Tailwind CSS IntelliSense, Vue Volar, Pretty TypeScript Errors
  • DevOps: ShellCheck, Kubernetes, Even Better TOML, HashiCorp Terraform
  • AI: KakaoTalk Channel社内AIツール + GitHub Copilot(選択)

カカオは社内LLMゲートウェイを運営しているため、Continue + 社内モデルの組み合わせを一部チームが使う。

メルカリ (Mercari)

メルカリのマイクロサービスチームが公開しているdotfiles参照:

  • GitLens
  • Error Lens
  • ESLint + Prettier
  • Even Better TOML(一部Rust利用)
  • ShellCheck
  • Go(Google公式拡張)
  • Protobuf(gRPC利用)
  • GitHub Copilot(2024年に全社導入を発表)
  • メルカリ内部拡張: マイクロサービスカタログ/Backstage連携

メルカリは100超のマイクロサービスを運用するため、Project Manager利用率が高い。

ZOZO (ZOZOTOWN)

ZOZO TECH BLOG (2024〜2025年)で公開されている推奨拡張:

  • GitLens
  • ESLint + Prettier
  • Tailwind CSS IntelliSense
  • Pretty TypeScript Errors
  • vscode-icons(社内標準)
  • Material Icon Themeも自由選択
  • GitHub Copilot

ZOZOはデザインシステム「ZOZO Design System」用の自社製拡張を作って社内配布している(Materialコンポーネント補完)。

共通パターン:

  • GitLensは日韓両国でほぼデフォルト
  • GitHub Copilotは2024年前後に大手IT各社が全社導入(セキュリティレビュー通過後)
  • 言語/フレームワーク拡張はチーム別に自由
  • 社内デザインシステムを持つ企業は社内拡張を作って配る 傾向

18. 誰が何を選ぶべきか — 新規 / TS / Rust / フルスタック

最後の意思決定ガイド。「全部入れる」は答えではない。役割に合う束を入れる。

新規開発者(学習中)

ミニマルな束。画面を騒がしくしない。

  • GitLens: Gitを視覚的に覚える最短ルート
  • Path Intellisense: importミスを減らす
  • Error Lens: エラーを見逃さない(ただし followCursor: activeLine で静かに)
  • Material Icon Theme: ファイル種別の高速識別
  • GitHub Copilot 無料ティア または Codeium: AI補完に慣れる
  • EditorConfig: チームプロジェクト参加時に自動適用
  • Live Server: 純粋HTML/CSS学習用

合計7個。慣れたら1つずつ追加。

TypeScriptフルスタック(Next.js / tRPC / Prisma)

毎日型エラーと戦う職種。UI改善拡張がコア。

  • 上記の新規開発者バンドル +
  • Pretty TypeScript Errors: ジェネリックエラー解読に必須
  • Tailwind CSS IntelliSense: Next.js + Tailwindがデフォルト
  • Prisma: schema.prisma 編集
  • ESLint + Prettier または Biome
  • GitHub Copilot Pro: モデル選択可、Workspace使用
  • REST Client または ThunderClient: APIテスト
  • GitHub Pull Requests: PRワークフロー

合計14個前後。ContinueやClineを追加するとさらに強力だが、Copilotとの衝突に注意。

Rust開発者

  • 新規開発者バンドル +
  • rust-analyzer (Rust公式、事実上IDEそのもの)
  • Dependi: Cargo.tomlのバージョン管理
  • Even Better TOML: Cargo.toml編集
  • CodeLLDB: Rustデバッガ
  • crates.io (任意)
  • Better TOMLよりEven Better TOMLを推奨
  • ShellCheck: ビルドスクリプトがbashの場合
  • GitHub Copilot または Codeium: Rustもよくサポートする

合計12個前後。rust-analyzerがRust開発の事実上ほぼ全てを占めるため比重が大きい。

DevOps / SRE

  • 新規開発者バンドル +
  • ShellCheck: bashスクリプト必須
  • HashiCorp Terraform: HCL編集
  • Kubernetes (Microsoft): YAML検証、kubectl連携
  • Docker (Microsoft): Dockerfile/compose編集
  • Even Better TOML
  • Remote-SSH / Remote-Containers / Dev Containers: リモート作業
  • YAML (Red Hat): JSON Schema検証
  • GitHub Pull Requests

AI拡張機能は任意。DevOps作業は「この環境で実際にどう動くか」が本質で、コマンドレベルの補完はそこまで価値が高くない。

データエンジニア / ML

  • 新規開発者バンドル +
  • Python (Microsoft): 公式
  • Pylance (Microsoft): 高速IntelliSense
  • Ruff (Astral): 高速リンター + フォーマッター
  • Jupyter (Microsoft): ノートブック編集
  • Data Wrangler (Microsoft): pandas DataFrameの視覚編集(2024年公開)
  • GitHub Copilot または Codeium: pandas/sklearn補完が強い
  • Even Better TOML: pyproject.toml

合計11個前後。Python開発はMicrosoft公式パック(Python + Pylance + Jupyter)が事実上の標準。

全職種共通の追加推奨

  • EditorConfig: 常に入れる
  • GitLens: 常に入れる
  • GitHub Pull Requests: GitHubを使うなら常に入れる
  • Project Manager: 3つ以上のプロジェクトを並行するなら入れる
  • Markdown All in One: READMEや文書を書くなら入れる

VS Code拡張機能の選定はツールの問題ではなく ワークフローの問題 だ。2026年の差分はAI拡張がデフォルトになったこと、同時にBiomeのような統合ツールが登場し「複数の道具を入れず1つに集約する」流れが始まったことだ。1カテゴリ1つ、デフォルト設定を30分整え、半年に1度棚卸しすれば、拡張機能は味方になる。その棚卸しを怠れば、拡張機能は徐々にメモリを食い、起動時間を増やす負債になる。拡張機能は追加は簡単で、外すのは難しい資産だということを覚えておこう。

参考 / References

Discuss on Twitter • View on GitHub