LabHub

ブログ

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

2026-05-16 · 38 分で読めます · #vscode#vscode-extensions#gitlens#path-intellisense#error-lens#pretty-typescript-errors#vscode-icons#material-icon-theme#indent-rainbow#dependi#tailwind-intellisense#prisma#eslint#prettier#biome#even-better-toml#live-server#rest-client#thunderclient#shellcheck#editorconfig#polacode#quokka-js#code-tour#project-manager#github-pull-requests#deep-dive#japanese

한국어English日本語

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

本記事は 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系は「なぜこのコードはこうなっているのか」を示し、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を真剣に使うなら必ず入れる」拡張機能になった。

主な機能:

// .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の強み:

GitLensの弱み:

誰が入れるべきか: 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 チーム)

Material Icon Theme (Philipp Kief)

{
  "workbench.iconTheme": "material-icon-theme",
  "material-icon-theme.folders.theme": "specific",
  "material-icon-theme.activeIconPack": "nest",
  "material-icon-theme.hidesExplorerArrows": true
}

選択ガイド:

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)"
}

長所:

短所:

代替としては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
}

長所:

短所:

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

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

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

VSCodeVim (vscodevim)

{
  "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)

{
  "vscode-neovim.neovimExecutablePaths.darwin": "/opt/homebrew/bin/nvim",
  "vscode-neovim.neovimInitVimPaths.darwin": "~/.config/nvim/init.lua",
  "vscode-neovim.useWSL": false
}

選択ガイド:

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

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

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

GitHub Copilot (GitHub/Microsoft)

Codeium (Codeium Inc., 現 Windsurf)

Tabnine (Tabnine Ltd.)

Cody (Sourcegraph)

Continue (Continue Dev)

Cline (旧 Claude Dev)

// 同時に1つだけ有効にしておくと心の平和が保てる
{
  "github.copilot.enable": {
    "*": true,
    "plaintext": false,
    "markdown": true
  },
  "github.copilot.editor.enableAutoCompletions": true,
  "continue.enableTabAutocomplete": false,
  "codeium.enableConfig": {
    "*": false
  }
}

選択ガイド:

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

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

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

Tailwind CSS IntelliSense (Tailwind Labs)

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

{
  "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を使うなら問答無用で入れる。

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

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

10. ESLint / Prettier / Biome — linter + formatter

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

ESLint (ESLintチーム)

Prettier (Prettierチーム)

Biome (Biomeチーム, 旧 Rome)

// .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年の選択ガイド:

重要: 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"
  }
}

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

Markdown All in One (Yu Zhang)

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

{
  "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万回超。

代替:

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"
}

長所:

短所:

代替:

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

長所:

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

ThunderClient (Ranga Vadhineni)

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

長所:

短所:

2026年の選択ガイド:

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"]
}

長所:

短所:

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

長所:

短所:

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

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

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

Polacode (P. Cong)

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

代替: 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, ... }

代替: 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の順序が重要。"
    }
  ]
}

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

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

Project Manager (Alessandro Fragnani)

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

{
  "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を作成・レビューする。

{
  "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カンファレンス資料ベース):

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

カカオ (Kakao)

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

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

メルカリ (Mercari)

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

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

ZOZO (ZOZOTOWN)

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

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

共通パターン:

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

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

新規開発者(学習中)

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

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

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

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

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

Rust開発者

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

DevOps / SRE

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

データエンジニア / ML

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

全職種共通の追加推奨

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

参考 / References

原文を読む: https://www.youngju.dev/blog/culture/2026-05-16-vs-code-essential-extensions-2026-gitlens-error-lens-pretty-typescript-errors-tailwind-prisma-biome-deep-dive.ja

コメント

まだコメントはありません。

ログインするとコメントできます