2026年8月11日

Metals v2をオープンソース化：数百万行規模のコードベースに対応するDatabricksのJavaおよびScala向け言語サーバー

コードインテリジェンスのギャップを埋めることで、2,600万行のBazelモノレポでCursorを機能させた方法

によって Ólafur Páll Geirsson, Iulian Dragos 、 Alessandro Patti による投稿

Metals v2は、従来のJVM言語サーバーでは対応しきれなくなった大規模なモノレポ向けに、コードインテリジェンスを再定義します。
Metalsは長年にわたり公式のScala言語サーバーでした。v2でJavaを完全にサポートしたことで、業界最大級のJavaコードベースを持つ企業が、Java専用としてMetalsの試験導入を開始しています。
AIはLanguage Server Protocol（LSP）機能の相対的な価値を変化させています。エンジニアが手動でコードを書く機会が減る中、広範な自動補完やリファクタリングの対応範囲よりも、セットアップコストの低さ、迅速なフィードバック、そして確実なコードベースの把握がより重要になっています。

現在、Databricksのコードの大部分はエージェントによって書かれています。エンジニアが自ら手を動かす必要がある場面では、起動が早く、最小限のセットアップでコード内を移動できる軽量なエディタが好まれます。しかし、ScalaやJavaにおいては、長年にわたりIntelliJがデファクトスタンダードとなっていました。私たちのモノレポ（monorepo）の規模では、実質的に対応できる唯一のエディタでした。本記事では、広く使われているScala言語サーバーであるMetalsを拡張し、ファーストクラスのJavaサポートを追加して、大規模なモノレポに対応できる代替ソリューションをどのように構築したかをご紹介します。アップストリームのMetalsチームと協力し、大規模なJavaおよびScalaのコードベースを持つすべての人が、コーディングエージェントと軽量エディタを組み合わせて使用できるように、Metals v2をオープンソースとして公開しました。

Metals v2は現在、Cursor、VS Code、Neovimでご利用いただけます。インストール手順はMetalsのウェブサイトに掲載されています。

IDEのフライホイールを構築する

2025年5月、私たちはDatabricksにおける日々のエディタワークフローをCursorを中心に標準化し始めました。CursorとVS Codeは、フロントエンドやその他の非JVMの作業において、すでにDatabricks内で広く使用されており、どちらもクラウドベースの開発環境に対する強力なSSHリモートサポートを備えていました。しかし、私たちのサービスのほとんどはScalaとJavaで書かれており、モノレポの規模でそれらをナビゲートすることが最後の難関でした。これこそが、私たちが解決しようと取り組んだ課題です。

単一のエディタへの標準化は、個人の好みを超えた重要な意味を持っていました。統一されたIDEプラットフォームはフライホイール（好循環）を生み出します。開発チームはコードの探索と開発のための共通の基準を共有でき、プラットフォームチームは投資を1箇所に集中させることができます。Cursorは私たちのモノレポにおけるJVM作業の主要なエディタとなり、移行が十分に定着したため、今年はIntelliJのライセンスの大部分を更新しませんでした。

図1：導入が広がることでプラットフォームへの投資効果が高まり、共有IDEが改善され、さらなる導入が促進されます。

Cursorへの移行がどこまで進んだかを示す3つのシグナルがあります。それは、全体的なIDEの使用状況、Metalsがクリティカルパス上に位置するScalaおよびJavaファイルのオープンイベント、そしてDatabricks外部での導入状況です。

IDEの使用状況

最も広範なシグナルは、全体的なIDEの使用状況です。DatabricksにおけるCursorの導入は自然に拡大しましたが、2025年9月までに頭打ちになり、数ヶ月間横ばい状態が続きました。しかし、Metals v2のロールアウトに伴って成長が再開し、2026年7月までに、週アクティブIDEユーザーの92%がCursorを開くようになり、IntelliJの12%を大きく上回りました。単一のIDEのみを使用するエンジニアの間では、IntelliJの120人に対し、現在2,400人がCursorを使用しています。

ScalaおよびJavaファイルのオープンイベント

全体的なIDEの使用状況よりも直接的なシグナルは、Metals v2がクリティカルパスとなる言語であるScalaとJavaにおいて、各IDEで開かれたファイルの割合です。2025年10月にMetals v2の最初の大きな改善がCursorに導入されて以来、ScalaおよびJavaファイルのオープンイベントにおけるCursorのシェアは40%から78%に上昇しました。ScalaとJavaはIntelliJが最も強固に定着していた領域であるため、全体のIDE導入に比べると上昇は緩やかですが、Cursorのシェアは月を追うごとに上昇傾向を維持しています。

外部での早期導入

Metals v2はDatabricksのフォークとして始まりましたが、その目標は常に成果をオープンソースコミュニティに還元することでした。CursorチームおよびVirtusLabのコアMetalsメンテナーと協力し、現在の安定版v1リリースに代わる、安定したMetals v2リリースの準備を進めています。

私たちは、数百万行規模のJavaコードベースでCursorが快適に動作するようにMetals v2に貢献しており、特にBazelのサポート、デバッグ、テストの改善に注力しています。—Kevin Niparko, Cursor

AIは開発者のIDEの使い方を変えつつあり、Metals v2は正しい方向へ進んでいます。高速な起動、信頼性の高いコードベースの把握、そして大規模なコードベース向けに構築されたアーキテクチャがそれです。Databricksは極めて大規模な環境でこのアプローチを検証しました。VirtusLabは、この成果をより広範なScalaおよびJVMコミュニティに届けるお手伝いができることを嬉しく思っています。—Krzysztof Romanowski, Head of Development Productivity, VirtusLab

他の大規模なJVMコードベースを持つ企業との対話からも、Databricksで見られたものと同じパターンが裏付けられました。それは、強力なSSHリモートサポートを備えたCursor、VS Code、Neovimへの需要、ツールの統一に向けたプラットフォーム側の圧力、およびモノレポ規模において既存のJVM言語サーバーでは確実な解決策が見出せないという現状です。

StripeでMetals v2の展開を開始したのは1ヶ月足らず前ですが、Javaコードベースでの動作の素晴らしさ、エンジニアたちの熱狂、そしてメンテナーの皆さんと協力し、学び合えることの楽しさに、常に感銘を受けています。—Mahib Hosain, Developer Platform, Stripe

これこそが、私たちがMetals v2に望むモデルです。大規模なJVMコードベースのための共有インフラストラクチャであり、オープンに維持され、大規模な運用を必要とする企業によって形作られていくものです。現在も開発はVirtusLabが主導しています。質問、フィードバック、または貢献については、GitHubのイシュートラッカーまたはmetals@virtuslab.comからお問い合わせください。

ディープダイブ：Metals v2がスケールする仕組み

ここまではMetals v2の導入事例について説明しました。ここからは、2,600万行のモノレポ全体で低レイテンシのコードインテリジェンスを実現する背後にあるエンジニアリングを詳しく理解したい読者向けの内容です。

エージェントがコードの大部分を書くため、包括的なLanguage Server Protocol（LSP）の補完やリファクタリングのカバー範囲よりも、迅速にコードベースを把握できることの方が重要でした。これにより問題は絞り込まれましたが、解決策が自明になったわけではありません。これほど大規模なScalaおよびJavaのBazelモノレポに対して、セットアップが容易で低レイテンシなナビゲーションを提供する必要がありましたが、既存のLSPはそのような規模をサポートするようには設計されていませんでした。私たちは、リポジトリ規模のコードインテリジェンスを第一原理から構築し、起動直後の有用性を測定・改善可能な主要指標として扱う必要がありました。

Time-to-Initial-Intelligence（TTII）の定義

Time-to-Initial-Intelligence（TTII）は、リポジトリを開いてからエディタが使用可能になるまでの速さを測定する指標です。ユーザーの介入がないと仮定し、言語サーバーが起動した時点から計測を開始し、最も重要な機能が利用可能になった時点で停止します。これらの重要な機能には、ワークスペースシンボルのあいまい検索、定義へのジャンプ、およびリポジトリ全体にわたるシンボルの使用箇所の検索が含まれます。

Metals v2の3つのレイヤー

Metals v2は、ScalaおよびJava用の言語サーバーです。私たちは公式のScala言語サーバーであるMetals v1からスタートしましたが、TTIIの目標を達成するには、細かな調整だけでは不十分でした。私たちはこれをフォークし、リポジトリインデックス、ScalaおよびJavaのコンパイラパイプライン、ビルド統合境界という3つの中心的なレイヤーを再構築しました。

ビルド不要のリポジトリインデックス： Metals v2は、後述する独自のmbtインデックスを使用してワークスペースのソースを直接インデックス化することにより、起動時のクリティカルパスからBuild Server Protocol（BSP）を排除します。Metals v1からの主な変更点は、ビルドサーバーが提供するのを待つのではなく、Metals自体が初期プロジェクトモデルを保持するようになったことです。
コンパイラが支援するScalaおよびJavaのインタラクティブパイプライン： Metals v2は、シンボルの読み込みをビルド提供のクラスパスからMetals提供のソースパスに移行します。これにより、診断やナビゲーションが、最後に成功したコンパイル時の古いスナップショットではなく、ディスク上の実際のコードをより正確に反映できるようになります。これには、v1コードベースにおける多くの根本的な前提を再考する必要がありました。
メタデータ優先のビルド統合： Metals v2でも引き続きBSPを使用しますが、その役割は限定的です。Metals v1では診断のためにエディタのホットパス上でビルドサーバーを使用していましたが、Metals v2では日常的な診断をビルドサーバーから切り離し、主に依存関係、生成されたソース、テストの検出、デバッグランチャーなどのビルドメタデータを照会するためにBSPを使用します。この移行により、Metals v2用のBSPサーバーを実装するハードルが下がり、私たちの社内Bazel BSPサーバーは、このモデルが大規模なBazelモノレポにスケールすることを実証しています。

以下のセクションでは、各レイヤーについて順に説明します。

mbtインデックス：ビルド同期前のリポジトリ全体のインテリジェンス

mbtはMetals Build Toolの略であり、mbtインデックスはTTII、すなわち「すぐに使える」という約束を実現する主な要素です。これはコンテンツアドレス指定されたワークスペースソースのインデックスです。Metalsは、ファイルの検出にgit ls-files --stageコマンドを使用し、どのインデックスエントリを再利用できるかを判断するためにGitのblob OIDを使用します。ビルド同期の前にリポジトリ全体の情報を利用できるため、Metalsは「最初の1マイル」の疑問に答えることができます。

ファイル間参照の診断
シンボルのあいまい検索
リポジトリ全体にわたる定義へのジャンプ（ただし、外部の依存関係や生成されたコードを除く）
ドキュメントごとのブルームフィルターを独創的に活用した、広範な参照検索（find-references）および実装検索（find-implementations）

mbtインデックスは、実質的にソースファイルからファイルローカルのサマリーへのハッシュマップです。エントリには、ファイルのパッケージ宣言、ソース位置を含む定義、およびファイル内で参照されている識別子のコンパクトなブルームフィルターが記録されます。定義はワークスペースのシンボル検索と定義へのジャンプ（jump-to-definition）を強力にサポートし、ブルームフィルターにより、Metalsはより正確なチェックを行う前に、参照を含まないファイルを迅速に除外できます。各エントリは1つのファイルのみから派生するため、インクリメンタルな更新はシンプルなままです。ファイルが変更されると、Metalsはそのファイルの情報を再計算して置き換えます。

私たちのモノレポでは、永続化されたmbtインデックスは非圧縮で936MBあり、14万2,000以上のScala、Java、Protobufファイルにわたる約290万個のシンボルに関する情報が含まれています。クリーンなベンチマークビルドは、32コアのCPUをフルに活用して22秒かかりますが、ディスクからビルド済みのインデックスをパースするのには5秒しかかかりません。本番環境では、TTIIを「サーバーの起動、古いmbtインデックスの読み込み、最新のgit ls-files --stage状態に対する更新、およびScalaとJavaのプレゼンテーションコンパイラの再起動」にかかる時間として測定しており、その結果はp50 8.7秒、p90 36.7秒です。290万個のワークスペースシンボルにわたるあいまいシンボル検索は、p50 10ミリ秒、p90 95ミリ秒です。TTIIをさらに短縮する余地はありますが、これらの数値を見る限り、次に解決すべきボトルネックではありません。

Scalaパイプライン：単一のコンパイラインスタンスで2,400万行のコードを処理

Scalaパイプラインは、コンパイル実行間でシンボルテーブル情報をキャッシュして再利用するScala型チェッカーのモードであるプレゼンテーションコンパイラを中心に構築されています。この再利用と、コンパイラの遅延シンボル解決を組み合わせることで、単一のインスタンスが2,400万行のScalaコードベース全体をスコープ内に維持しながら、p50 0.9秒、p90 8.9秒で診断結果を発行できます。

この単一のScalaコンパイラインスタンスは、編集中のファイルについてMetalsがビルドサーバーから取得している情報の量に応じて、2つのモードのいずれかで動作します。ビルド同期の前は、フォールバックコンパイラが寛容なアプローチをとり、リポジトリ内のすべてのソースファイルを適格な依存関係候補として扱うため、Bazelでまだコンパイルできないコードであっても、すぐにナビゲーションを利用できます。ビルド同期の後は、高精度コンパイラがビルドサーバーの報告するクラスパスとソースパスの境界に制限されるため、診断と依存関係の情報がビルドに対して正確になります。高精度モードとフォールバックモードの両方が、これほど大規模なソースパスを扱いやすく維持するために、同じ2つの手法に依存しています。

開かれていないソースのアウトラインモード。 エディタで開かれていないソースは、型チェックの前にメソッド本体が削除されます。これにより、型チェック時間の大部分が費やされるメソッド本体での処理を回避しつつ、コンパイラが必要とする型シグネチャを維持します。
インメモリのソースレイアウトインデックス。 Scalaのソースパスはパッケージ構造を確実にエンコードしないため、Metalsはパーサーを実行してクラスをソース位置にマッピングする軽量なインデックスを構築し、ファイルシステムをスキャンする代わりにそのインデックスを介してシンボルを読み込みます。フォールバックコンパイラは、ソースから再パースするのではなく、Metalsがすでに持っているリポジトリ全体のデータを再利用して、50ミリ秒未満でmbtインデックスからこのインデックスを直接構築します。

高精度モードでは、3つ目の手法が追加されます。それは、推移的依存関係のソースをソースパス上に維持することです。これにより、異なるBazelターゲットのファイルにまたがる編集が、Bazelが新しいクラスパスを生成するのを待つことなく、エディタに即座に反映されます。これはMetals v1の制約となっていた点です。

単一のプレゼンテーションコンパイラインスタンスで2,400万行のコードベースを保持することは、Scalaコンパイラが本来想定していた設計を大きく超えています。Metals v2は、ソースパスをスケーリングするための共通の手法セットに基づいて構築された2つのコンパイラモードによってこれを実現しています。エディタで最もよく使われる機能である定義へのジャンプは、リポジトリ全体でp50 7ミリ秒、p90 575ミリ秒で動作します。Scalaは当社のエンジニアの多くが使用している言語であるため、このパイプラインは、私たちのモノレポにおいてCursorがIntelliJの真の代替手段となるために、どうしても機能させる必要があった部分でした。

Javaパイプライン：Turbineを使用して1秒あたり100万行のJavaコードを処理

Metals v2は、Java LSPサーフェスをjavac API上に直接実装しています。既存のJava言語サーバー（JDTおよびNetBeansベースの実装）の再利用も検討しましたが、どちらもMetals v1と同様にビルド中心であり、これこそがv2で排除しようとした密結合でした。代わりにjavac上に構築することで、JavaはMetals v2のソースパスとビルド同期モデルをScala（現在もモノレポの大部分を占めています）と共有できるようになり、必要だったJavaサーフェスは自分たちでメンテナンスできるほど十分に小さなものでした。

javac APIは、診断、ナビゲーション、セマンティックハイライト、およびその他の主要なLSPメソッドを実装するのに十分なコンパイラアクセスを提供し、一部が破損したコードに対しても適切に機能しました。これはインタラクティブなエディタのワークフローにおいて重要です。Scalaと同様に、リファクタリングや補完などのアクティブな編集機能は、意図的にスコープを狭く抑えました。

このアーキテクチャにおける主なスケーラビリティの問題は、シンボルアウトラインレイヤーで数百万行のコードを推移的にインポートすることにより、javacの「enter」フェーズで極端なパフォーマンス低下を引き起こすファイルで発生しました。Metals v2は、デフォルトで有効になっているjavaSymbolLoader: "turbine-classpath"モードでこれに対処します。このモードでは、カスタマイズされたバージョンのTurbineヘッダーコンパイラを使用して、名前解決エラーの適切な処理を含む、IDE環境で動作するリポジトリクラスパスを生成します。Turbineはシングルスレッドで1秒あたり100万行近いJavaコードを処理するため、MetalsはJavaコードベース全体を定期的に再コンパイルできます。これにより、ほぼすべてのファイル間シンボルがソースパスではなくクラスパス上に維持されるため、javacの「analyze」フェーズは、インタラクティブな使用における実用的な限界（ベンチマークでは1秒あたり約10万行のコード）に近い速度で実行できます。

ビルド統合：エディタのレイテンシで28万5,000個のBazelターゲットをクエリ

「ビルド同期前に役立つ」ということは、「ビルドを無視する」という意味ではありません。サードパーティの依存関係や生成されたソースへのナビゲーション、カスタムシェーディングルールの尊重、テストスイートの検出、デバッグランチャーの自動構成など、ロングテールの機能において、Metalsは依然として正確なビルドグラフを必要とします。Databricksでは、これは28万5,000個のBazel JVMターゲットからのメタデータを、エディタのレイテンシでクエリ可能にすることを意味します。

このレイヤーの本番環境での実装は、Goで書かれ、当社のBazelルールに合わせてカスタマイズされた社内BSPサーバーです。このBSPサーバーは今回のオープンソースリリースには含まれていませんが、その設計の選択肢は、他のBazel BSP実装に引き継ぐ価値が十分にあります。

第一に、ユーザーが明示的に要求しない限り、Metals v2がBSPサーバー経由でBazelを呼び出すことはありません。大規模なモノレポでは、バックグラウンドでのIDE同期がBazelロックを取得し、開発者が開始したビルドと競合する可能性があるため、ビルド同期は起動時の動作やバックグラウンドのメンテナンスプロセスではなく、ユーザーの明示的なアクションとなっています。生成されたメタデータはJSONスナップショットに保存され、繰り返されるラベル、パス、リポジトリプレフィックスの定数プールによってスケーリングされます。ユーザーが同期すると、BSPサーバーはこのスナップショットにターゲットを段階的に追加し、更新されたメタデータをBSP経由で提供します。

第二に、共有の同期設定フォーマットはありません。ユーザーは、ナビゲーションや診断の精度を向上させるために、編集時に個々のファイルやディレクトリをオンデマンドで同期します。私たちの経験では、事前定義された同期セットは時間の経過とともに肥大化し、チーム間でコピーされ、開発者が実際に必要とするピンポイントの同期よりも遅くなってしまいます。

3つのレイヤーの統合

ビルド不要のインデックス、コンパイラが支援するパイプライン、そしてメタデータ優先のビルド統合が組み合わさることで、数百万行規模のBazelコードベースにおいて低レイテンシのコードインテリジェンスが実現します。これをApache 2.0ライセンスでオープンソース化することで、私たちはより広いエコシステムに、これまで存在しなかった選択肢を提供したいと考えています。それは、既存のJVM言語サーバーでは確実な手段が提供されていなかった規模において、コーディングエージェントや軽量エディタを、豊富なScalaおよびJavaナビゲーションと組み合わせることです。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事