VSCodeが“エディタ戦争”を制した理由。立役者は「TypeScript」？【フォーカス】

コーディング環境において、事実上の標準となっている「Visual Studio Code（VSCode）」。かつてテキストエディタは長らく群雄割拠の様相を呈し、一部で「エディタ戦争」と呼ばれることもありましたが、なぜ2015年に後発として登場したVSCodeは、世界において大きなシェア（※1）を得るようになったのでしょうか？

その最大の要因は米Microsoft社の資本力でもエディタ自体の性能でもなく「実は、TypeScriptの存在なのでは」――。

こう語るのは、『Emacs実践入門』『Atom実践入門』の著者で、技術コミュニティ生まれの音声番組「vim-jpラジオ」主催を務めるなど、テキストエディタや各コミュニティについて深い知見を持つ大竹智也さんです。

一体、どういうことなのか？　長年のEmacsユーザーでもあり、かつてはAtomも愛用していた大竹さんの視点から、「VSCode一強時代」の背景をどのように分析しているのか、お話を聞きました。

（※1）Stack Overflowの2025年度調査によれば、「開発用IDE」（エディタ含む調査）の項目では、ユーザーが過去1年以内に利用した、あるいは今後1年以内に利用したいと答えたIDEの1位がVSCode（75.9％）だった。2位Visual Studio（29％）、3位Notepad++（27.4％）。なお、同2015年度調査の「TEXT EDITOR」の項目によると、使用しているエディタは1位Notepad++で34.7％、2位Sublime Textで25.2％、3位Vimで15.2％。なお、4位のEmacs（3.8％）を挟んで、5位には既に開発を終了したAtom（2.8％）が名を連ねていた。

• keyboard_arrow_down 群雄割拠時代と「Atom」がもたらしたもの
• keyboard_arrow_down 「TypeScriptという“相棒”」と、Microsoftの逆襲
• keyboard_arrow_down AI時代における「手馴染みのエディタ」の行方

――VSCodeが登場する以前、エンジニアたちの開発環境を取り巻く「エディタ勢力図」はどのようなものだったのでしょうか。大竹さんのご経験から教えてください。

大竹：国内では厳密で大規模な調査が見当たらないためあくまで肌感覚ですが、VSCodeの登場前は、OSによって選択肢が大きく異なってくる時代がしばらく続いていたと思います。

もちろん、エディタ戦争という文脈において二大巨頭として語られがちな、UNIX/Linux由来の「Vim」と「Emacs」は当時から強力な選択肢でした。ただ、どちらもUNIX、Linux環境で育ってきたエディタなので、WindowsでのGUI環境に慣れたユーザーからすると導入ハードルが高かった。そのため、当時のWindowsユーザーの間では、動作が軽快で日本語環境にも適した「サクラエディタ」や「秀丸エディタ」といった国産ツールを愛用する人が少なくなかったかと思います。

そして2000年代中盤以降にWeb開発用のマシンとしてMacが普及すると、Windowsから移行してVimやEmacsに挑戦する層や、Macネイティブな「CotEditor」(※2）や「mi（ミミカキエディット）」(※3）、あるいは「Sublime Text」(※4）などのモダンなGUIエディタを選ぶ層も出てきました。

あとは当然、Javaなど特定の言語を扱うなら、「IntelliJ IDEA」をはじめとするJetBrainsのプロダクトや、「Eclipse」といった統合開発環境（IDE）も強力な選択肢でした。

ただ、「これを使えばいい」という決定打となるツールが存在せず、皆がそれぞれの環境で、手に馴染むソフトウェアを探していた時期だったといえます。ちなみに僕の場合は、2000年代前半はWindowsで「Xyzzy」というEmacsライクなエディタを使い、2006年ごろにMacに移行してから、本家のEmacsを使い始めたという経緯があります。

（※2）CotEditor：2009年にリリースされた日本発のmacOS専用テキストエディタ。軽量で高速な起動やシンプルなUIが特徴。
（※3）mi：1996年ごろに登場し、Macユーザーに親しまれているテキストエディタ。以前は「ミミカキエディット」の名称で知られていた。
（※4）Sublime Text：2008年に登場したクロスプラットフォームのテキストエディタ。海外を中心に大きな人気を博した。

――そんな中、2014年にGitHub社から「Atom」が登場しました。「21世紀のためのハッカブルなテキストエディタ」という触れ込みでリリースされ、急速にシェアを伸ばしていましたが、歴史的な意義をどう分析されますか。

大竹：僕自身一時期はAtomユーザーだったのですが、Atomの最大の功績は「プロジェクト」という概念をWeb開発者にとって身近なものにし、エディタの標準的なUIとして定着させた点にあると考えています。

特にVimやEmacsといったそれまでのエディタは、基本的に「ファイル」をどう開くか、どう編集するかという点に主眼が置かれていました。しかしAtomは、「Gitリポジトリ（Git管理フォルダ）」をひとつの単位として扱い、サイドバーにツリー構造を表示し、プロジェクト内のファイルを横断的に検索したり、移動したりするスタイルを「当たり前」のものとして提示しました。

もちろん、Sublime Textなど、従来のエディタにも同様のスタイルはありました。そうしたモダンなスタイルを、AtomがWeb技術ベースのUIとGitとの標準統合を前提として豊富な機能性を提供することで、さらに推し進めた部分があると思います。これにより「エディタを開く＝特定のプロジェクトと向き合うこと」という現代的な開発のワークフローが、視覚的にも機能的にも定義されていったのではないか、と。

また、HTML、CSS、JavaScriptといったWeb技術でデスクトップアプリをつくれる「Electron」を採用したことで、見た目のカスタマイズや拡張機能の作成が、Webエンジニアにとって劇的に容易になった点も革新的でした。

――しかしAtomは普及しきれず、2022年に開発終了を迎えました。革新的な魅力を持ちながら、なぜ「覇権」を握れなかったのでしょうか。

大竹：動作の重さなど要因は複合的ですが、決定打はやはり2018年の「MicrosoftによるGitHubの買収」でしょう。

すでにElectronという共通の技術基盤を持ち、猛烈にシェアを伸ばしていたVSCodeが存在する以上、Atomの開発を打ち切ってVSCodeにエディタの開発リソースを一本化したというのは企業として合理的な判断です。

もしAtomがVSCodeを圧倒していれば、逆にVSCodeが消えていた未来もあり得ましたが、当時の勢いの差は歴然でした。結果として、Atomが切り開いた「Web技術でつくるエディタ」という道は、競合であったVSCodeによって完成を見ることになっていきます。

――VSCodeがAtomをはじめとする競合を抑え、急速にシェアを拡大できた「決定的な理由」は何だとお考えですか。一般的にはMicrosoft社の資本力や、動作の軽快さ、プラグインの豊富さなどを要因として耳にします。

大竹：私見ですが、VSCodeが市場を席巻できた背景は、まず「LSP（Language Server Protocol）」という技術的な発明があったこと、そして何より最大の要因として、TypeScriptというプログラミング言語の存在があるように考えています。

――詳しく教えてください。

大竹：まず、LSPについてお話しさせてください。かつてのエディタ開発には「M×N問題」と呼ばれる課題が存在していました。世にM個のプログラミング言語と、N個のエディタがあり、それぞれの言語の補完機能や定義ジャンプを各エディタで動かすためには、各コミュニティの有志が「M×N」通りの組み合わせで個別にプラグインを開発しなければならなかった、というものです。これでは労力が分散し、機能の質も安定しない。

MicrosoftはVSCodeにおいてこの問題を解決するために、言語の解析を担う「サーバー（言語サーバー）」と、ユーザーが操作する「エディタ」との通信規格を「LSP」として統一し、オープンにしました。「この規格に合わせてくれれば、どのエディタでも高度な補完や定義ジャンプが共通して使えますよ」と宣言したわけです。

これにより、各言語コミュニティは、例えば「VSCodeのため」「Vimのため」と個別に開発するのではなく、「LSP対応」として言語サーバーをひとつ開発するだけで、あらゆるエディタに対応できるようになりました。

しかしそのLSPの手本となるリファレンス実装を行っており、最もLSPが安定して動作するのは、いわば言い出しっぺにあたるVSCodeです。結果として、「Ruby」や「Python」、「Go」のコミュニティがLSP対応を頑張れば頑張るほど、VSCodeでの開発体験も自動的に向上していく。「他言語のコミュニティの努力を、自然と自社製品の魅力へと変換できるシステム」をつくり上げたといえます。

――LSPの恩恵をどのエディタも受けられるようになったとはいえ、構造上VSCodeが一歩抜きん出る仕組みになっていたのですね。ただ、規格が標準化されているなら、そこまで決定的な差にはならない気もします。

大竹：そこを決定づけたのが、TypeScriptだと僕は考えています。

Microsoftは単に「良いエディタ」をつくったのではなく、「TypeScriptという言語を普及させるための、最高の実行環境」としてVSCodeをリリースしたといえるのではないか。このように思うのです。

VSCodeがリリースされた2015年ごろを振り返ると、当時はWebフロントエンド開発の複雑化に伴い、JavaScriptの自由な仕様に疲弊したエンジニアたちの間で、“altJS”（代替JavaScript言語）を求める機運が高まっていました。

そこで大きなシェアを握るようになっていたのが、Microsoftが2012年に開発したTypeScript＜(※5）です。

ここからが重要なのですが、そのTypeScriptが持つ「型安全性」や「補完機能」といった強力な開発体験を、最も100％に近い形で享受できる環境だったのが、他ならぬVSCodeでした。

（※5）TypeScriptは2012年の公開当初はシェアが低かったものの、2017年にStack Overflowの調査で多くのユーザーに使用されている言語として存在感を示し始め（9.5%）、2022年には5位で34.83%に達し、Javaを上回る人気言語となった。2025年度調査では1位JavaScript（66％）、2位HTML/CSS（61.9％）、3位SQL（58.6％）、4位Python（57.9％）、5位Bash/Shell（48.7％）、6位TypeScript（43.6％）という並びだった。

――TypeScriptを書くならVSCodeが一番いい、というのは感覚的に分かりますが、具体的には、他のエディタと何が違ったのでしょうか。

大竹：実はTypeScriptは公式でLSPに準拠した言語サーバーを公開しておらず、tsserverという独自のプロトコルで動くサーバーのみを公開しています。VSCodeの拡張はこのtsserverを利用して快適に動くようになっていますが、他のエディタがLSPを使おうとすると、外部の有志が作成したtsserverを中継する言語サーバーを介してLSPの機能を使うしかなく、速度面や機能面でどうしてもVSCodeの拡張よりも劣る面もありました。そこが最大の違いだったといえます（※6）。

つまり、VSCodeであれば、何もしなくても最高のTypeScriptの開発環境が使えます。一方で、例えばVimやEmacsといった他のエディタはたとえLSPを使っても、VSCodeと完全に同じ機能性では使えず、何より、導入にあたって設定のひと手間が必要だった点は否めません。

他のエディタでは環境構築に多少の知識や手間が必要だった一方で、VSCodeを使えば、面倒な設定なしでTypeScriptの高度な補完が効き、変数名の一括変更などのリファクタリングも一瞬で終わる。もっといえば、VSCodeという強力な支援環境があったからこそ、TypeScriptの「型による安全な開発」のメリットが誰の目にも明らかになった面もあるでしょう。もしエディタによるサポートが貧弱であれば、TypeScriptは単に「記述が面倒な言語」として敬遠されていた可能性もあった。

このように、単に「良いエディタ」をつくったのではなく、エディタ単体で勝負するでもなく、「言語とエディタ」をセットにして押し出していったから、VSCodeが大きなシェアを獲得するに至ったのでは、と僕はみています。

つまり、「TypeScript＋VSCode」の開発者体験の良さが、当時の代替JavaScript言語への需要にマッチした。そして、そのまま「TypeScriptを書きたい人の間ではVSCodeが採用されていき、またVSCodeが普及するにつれ、VSCodeと相性の良いTypeScriptの採用も開発現場で加速した」という好循環が生まれたのでは、と。

（※6）VSCodeの拡張機能をTypeScriptの言語サーバーとして使う「vtsls」というLSPラッパーもあり、他のエディタでもVSCodeとほぼ同等のパフォーマンスで同等の機能を利用すること自体は可能。

――LSPで多言語を取り込みつつ、モダンな言語であるTypeScriptの開発体験にも最適化されていたのが強みだった、と。ただ、かつてのMicrosoft社は、基本的にプロプライエタリなソフトを出す、「クローズド」な企業という典型的なイメージも強かったかと思います。OSS文化に親しんできたエンジニアの間に、VSCodeへの心理的な抵抗感はなかったのでしょうか。

大竹：確かに、以前であれば「Microsoft社製のエディタ」というだけで敬遠する層は一定数いたかもしれません。

ただ、サティア・ナデラ氏がCEOに就任して以降のMicrosoftは、「MicrosoftはLinuxを愛する」とのメッセージを打ち出すなど、OSSに対する姿勢を大きく転換させました。そして実際にオープンな活動を推し進めていった。

GitHubにMicrosoftが公式の組織（Organization）を持つということ自体が当時は驚きでしたし、実際にVSCode自体もオープンソースとしてGitHub上で開発が進められ、無料で提供され、しかも、デスクトップアプリに強いMicrosoftのノウハウが生かされたのもあってか、使ってみると驚くほど便利だった。こうした実態が、懐疑的だった人たちの目をも好意的なものに変えていったのではないでしょうか。

さらに、GitHubの買収後は「VSCodeで書き、GitHubで管理し、Azure基盤のActionsでデプロイする」という一連のエコシステムも完成しました。こうした企業としてのブランドイメージの転換と、実利的な開発環境の構築が噛み合い、VSCodeは名実ともに標準の座を不動のものにしていったのだと分析しています。

――ちなみに、大竹さん自身は現在もEmacsをお使いになられているんでしょうか？

大竹：それがですね、今も使っているんですよね。

――なぜでしょうか？

大竹：やはり、長年染み付いたEmacsのキーバインド（操作体系）への慣れが大きいですね。

結局、LSPや「Tree-sitter」(※7）のような解析ツールが生まれたことで、各エディタにおける入力補完やシンタックスハイライトといったコーディングにおける機能面での差は標準化されていきました。かつては言語とエディタの相性によって速度面などで多少の差異はあったでしょうけれど、現在では進化したマシンスペックでカバーできるので、実用上の差はほぼ感じません。

それぞれの機能的なアドバンテージが以前より薄まってきた今、何がユーザーのエディタ選びを分けるかというと、結局そうした慣れによるものだと思うんです。僕にとってはEmacsのキーバインドでコーディングができることが非常に重要ですし、他のユーザーならプレーンテキストで文書作成やタスク管理までできる「Org Mode」から離れられないという人も多い。Vimユーザーの場合はあの独特な「モード切り替え」による操作がコーディング時の手癖と直結していて手放せないという人をよく見かけます。

逆にこれからプログラミングを始める方からすると、学習コストをそこまで払う必要なく手軽に始められるVSCodeが入り口として優れているのは間違いありません。標準でできることが圧倒的に多いですからね。

ただ、僕自身これまでにXyzzyやEmacs、Atomを触ってきた経験からいうと、新しいツールが出るたびに闇雲に乗り換えるよりは、ひとつのエディタが持つ思想や本来の機能を100%引き出せるよう「自分がツールに合わせて変化する」ことの方が、長期的には生産性が高まるのではないか、とも感じます。

（※7）Tree-sitter：汎用的なパーサージェネレータ。高速、正確にソースコードを解析し、シンタックスハイライトやインデントなどの機能を提供する。AtomやVSCode、Neovimなどで採用されている。

――最後に、これから先の未来についてどう考えるか、お聞かせください。「GitHub Copilot」のようなAI支援が当たり前になり、「Cursor」のようなAI特化型エディタも台頭しています。エディタというツールのあり方は、今後どう変わっていくと予測されますか。

大竹：非常に予測が難しい、過渡期にあると感じています。ものすごいスピードで新たなツールが出てきていますからね。

例えば、VSCodeをフォークしてつくられた「Cursor」は、AIとの対話やコード生成において本家を超える体験を提供して支持を集めています。一方で「Claude Code」のようにターミナル上でAIが自律的にコーディングを行うというようなツールも出てきました。もし、AIが完全にコードを書ききる時代が来るなら、人間が文字を入力する「エディタ」というインターフェース自体が不要になる可能性すらあるでしょう。

しかし、現時点での僕の感覚としては、やはり「コードを直接触りたい」「テキストを意図通りに素早く操作したい」という人の欲求はなくならないのではないか、と思います。

AIがコードを生成するとしても、最終的な微調整、あるいはプロンプト文の作成など、テキストを編集する局面は必ず残ります。そのとき、文字列の置換や行の入れ替えといったプリミティブな「編集」操作が、いかに直感的かつ高速に行えるかがやはり重要になってくるはずです。

ツールがVSCodeになろうがAIエディタになろうが、あるいはEmacsのままであろうが、エンジニアにとって「コードを書く」という行為の本質は変わらないのではないかと思うのです。だからこそ、AIに任せる部分と、自分の手で素早く編集する部分、それぞれを最大限活かせるエディタを、ひとりひとりが自分の中で見つけていく形になっていくんじゃないかな、というのが僕の所感です。

取材・執筆・編集：田村 今人
撮影：赤松 洋太