Code-to-Knowledge-Graph解説｜LSPでコードをナレッジグラフ化するJVMツールキット

コードのナレッジグラフ化に興味があるなら、RAG全般の地図として RAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップ も合わせて読むと位置づけが掴みやすい。

Code-to-Knowledge-Graph（以下Bevel）は、ソースコードを問い合わせ可能なナレッジグラフに変換するKotlin/JVMのツールキットだ。特徴は解析の入口にある——tree-sitterのようなAST（抽象構文木）パーサーを自前で持つのではなく、VS CodeのLSP（Language Server Protocol、言語サーバー）を使ってコードを解析する。エディタで「定義へジャンプ」「参照を検索」が効くのと同じ仕組みで、関数・クラス・ファイルといったノードと、呼び出し・継承・参照といったエッジを抽出し、グラフに組み上げる。ライセンスはMozilla Public License 2.0（MPL-2.0）で、GitHubスターは本記事執筆時点で約251だ。

Code-to-Knowledge-Graphとは——LSPでコードを意味解析するナレッジグラフ基盤

大規模なコードベースを人間もAIも一度に把握するのは難しい。数十万行のプロジェクトで「この関数を変えたら何が壊れるか」「認証はどのクラスを経由してDBにつながっているか」を追うには、ファイルを行き来しながら定義と参照をたどり続けることになる。この「コードの構造・依存・影響範囲」を、あらかじめグラフとして持っておこうというのがコード知識グラフの発想だ。

この記事を読む開発者が知りたいのは、突き詰めれば次の3点だろう。①Bevelは結局何ができるのか、②どんな課題を解決するのか、③既存の何を代替するのか。先に結論を示す。

・①何ができる：VS Codeの言語サーバーを使ってコードを解析し、関数・クラス・ファイルのノードと、呼び出し・継承・参照のエッジからなる知識グラフを構築する。グラフはNeo4jにエクスポートして探索したり、自作ツールから読み出したりできる
・②何を解決する：構造・依存・影響範囲の把握を、正規表現やAST推定ではなく、言語サーバーによる実際のシンボル解決に基づいて行える。「定義へジャンプ」相当の精度でグラフを組める
・③何を代替する：コード理解のために毎回grepやファイル横断で追う運用や、tree-sitterパーサーを自前実装してグラフを組む手間を、既存の言語サーバーの再利用で置き換える

Bevelの核心を一言でいえば、「エディタがすでに持っている言語知識を、グラフとして取り出す」ことにある。VS Codeで定義ジャンプや参照検索が動くのは、背後で各言語の言語サーバーがシンボルを解決しているからだ。Bevelはその言語サーバーに問い合わせて結果をグラフ化するため、対応言語の言語サーバーさえ用意すれば、原理的には多言語に同じ仕組みで対応できる。READMEはこれを「VS CodeのLSPを活用した堅牢なマルチ言語パース」と説明している。

なお、Bevelは単体で完結するCLIツールというより、Kotlin/JVMのライブラリ（ツールキット）として設計されている。後述するように、Gradleの依存として取り込み、Javaやkotlinのコードから parse() を呼んでグラフを得る使い方が中心だ。「グラフを作る部品」であって、「グラフを作って見せる完成品」ではない——この位置づけの違いが、後述する類似ツールとの差につながる。

tree-sitter系との違い：構文解析（AST）と意味解析（LSP）

コード知識グラフというジャンルには、すでにいくつものOSSがある。当サイトでも Graphify入門：コード・ドキュメント・画像をナレッジグラフ化し、AIの検索トークンを71.5倍削減するOSS をはじめ、Code Review Graph や CodeGraph といったツールを扱ってきた。これらとBevelは、同じ「コード→グラフ」でも解析の土台が根本的に違う。

graphify・CodeGraph・Code Review Graphはいずれも、tree-sitterのAST（抽象構文木）解析でグラフを組む。tree-sitterはソースを構文木にパースするライブラリで、LLMもエディタも不要でローカル完結し、非常に高速だ。一方Bevelは、VS Codeの言語サーバー（LSP）にコードを渡し、その解析結果をグラフ化する。両者の違いを整理すると次のようになる。

重要なのは、これは優劣ではなくトレードオフだという点だ。LSPを使う長所は、正規表現やAST推定では取りこぼしがちな「実際にどの定義を指しているか」を、言語サーバーの解決結果として正確に得られること。短所は、対象言語の言語サーバーとVS Code環境を用意する必要があり、その分だけ重く、セットアップの前提が増えることだ。

逆にtree-sitterの長所は、自己完結で軽く、APIキーも外部サーバーも要らず高速に走ること。短所は、あくまで構文木からの抽出なので、複雑なオーバーロード解決や型に基づく参照など、意味レベルの解決はヒューリスティックに頼りやすい点にある。「速さと手軽さ」を取るか、「シンボル解決の正確さ」を取るか——グラフの用途によって最適解は変わる。AIに読ませてトークンを削るのが主目的ならtree-sitter系の完成ツールが手早く、コードの依存や影響を厳密に追う独自ツールを作りたいならBevelのLSPアプローチが噛み合う。

この違いは、セットアップの手触りにもそのまま表れる。tree-sitter系は文法定義さえバンドルしていれば単体で走るため、pip install や npm install の直後にコマンドを叩けば、その場でグラフが得られる。対してBevelは、対象言語の言語サーバーが動くVS Code環境を前提にする。つまり「Pythonを解析したいならPythonの言語サーバー、TypeScriptならTypeScriptの言語サーバー」というように、エディタ側の言語対応がそのままBevelの対応言語になる。これは追加の準備が要る一方で、エディタで正しく解決できているシンボルは、Bevelのグラフでも正しく解決されるという一貫性を生む。「エディタでは定義ジャンプできるのに、グラフでは繋がっていない」といったズレが起きにくいのは、同じ言語サーバーを土台にしていることの利点だ。どちらの流儀が正しいという話ではなく、解析の正確さをエディタの言語知識に委ねるか、自己完結の軽さを優先するかという、設計の分岐点だと理解しておくとよい。

何が抽出されるのか：ノードとエッジのグラフモデル

Bevelが構築するのは、コードの要素をノード、それらの関係をエッジとして表した有向グラフだ。READMEは「コードのエンティティと関係を包括的に表現するリッチなグラフモデル」と表現している。ここが「何ができるか」を最も具体的に体感できる部分になる。

グラフに載る主な要素を、代表的なものとして挙げると次のようになる。

・ノード：関数・メソッド、クラス・インターフェース、ファイル・モジュール、変数・シンボルなど、コードを構成するエンティティ
・エッジ：関数Aが関数Bを呼ぶ「呼び出し」、クラスの「継承・実装」、モジュール間の「import・依存」、シンボルへの「参照」など、エンティティ間の関係

こうしたグラフができると、「このクラスを継承しているのはどれか」「この関数を呼んでいるのはどこか」「このファイルはどのモジュールに依存しているか」といった問いを、ファイルを開いて追う代わりにグラフの探索として解ける。READMEは主な用途として、コード構造の理解・影響分析（Impact Analysis）・アーキテクチャの俯瞰・カスタムツールの構築・AIやLLMの補強を挙げている。

Bevelにはこのグラフモデルに加えて、いくつかの補助機能がREADMEに記載されている。ファイルの変更に応じてグラフを部分的に更新するインクリメンタル更新、.gitignore のパターンを尊重してスキャン対象を絞るスマートなファイル探索、そしてMinHashingによるコード類似度検出だ。MinHashは大量の集合同士の類似度を高速に近似する手法で、コードの重複や似た実装を見つける用途に使われる。インクリメンタル更新があることで、初回に全体を解析したあとは変更ファイルの周辺だけを組み直せばよく、巨大なリポジトリでもグラフを最新に保ちやすい。

こうしたグラフが「影響分析（Impact Analysis）」で具体的にどう効くかを、簡単な例で考えてみる。あるユーティリティ関数 formatDate() の仕様を変えたいとき、知りたいのは「これを直接・間接に呼んでいるのは誰か」だ。グラフがあれば、formatDate ノードへ入ってくる呼び出しエッジを逆向きにたどるだけで、影響の及ぶ関数・クラスの一覧が得られる。ファイルを開いて formatDate をgrepし、ヒットした箇所を一つずつ確認する作業を、グラフの近傍探索一発に置き換えられるわけだ。LSP由来のグラフであれば、同名の別関数や無関係な文字列マッチに惑わされにくく、「本当にその定義を呼んでいる箇所」だけを拾える点も効いてくる。継承関係やインターフェース実装がからむ大規模コードほど、この正確さの差は無視できない。

グラフの構築フローを、コードから知識グラフができるまでの流れとして図にすると次のようになる。

このフローの入口が言語サーバーである点が、繰り返しになるがBevelの肝だ。tree-sitter系がソースを直接パースするのに対し、Bevelは「エディタと同じ目線」でコードを見る。

Neo4j可視化・テスト生成・シーケンス図——エコシステムで何ができるか

Bevelのグラフは、それ単体で終わらず、いくつかの周辺ツールの土台として使われる設計になっている。READMEはこれを「エコシステム＆ユースケース」として整理しており、グラフを開発者向けツールに変換する例を挙げている。

READMEに挙げられている主な活用先は次のとおりだ。

・インタラクティブなコード可視化：グラフをNeo4jにエクスポートし、専用のBevel Neo4j Visualizationでコードベースを視覚的に探索する
・AI支援のテスト生成：VS Code拡張のBevel Test Generatorで、グラフをもとに包括的なテスト用プロンプトを生成する
・シーケンス図・ドキュメント生成：Bevel拡張から、対話的な図やドキュメントを生成する
・カスタムツールの構築：グラフAPIを使い、自前の解析ツールを組み上げる

ここで効いてくるのが、前述した「Bevelは完成ツールではなく部品」という位置づけだ。グラフという共通の土台を一度作れば、その上に可視化・テスト生成・図生成・独自解析を載せられる。tree-sitter系の多くが「トークン削減」という単一の出口に最適化されているのに対し、Bevelはグラフを再利用可能な基盤として置き、複数のツールがそれを共有する構造になっている。

一方で、周辺ツールの多くはVS CodeマーケットプレイスのBevel拡張やNeo4jの存在が前提になる点は押さえておきたい。手元でコマンド一発、という手軽さより、「言語サーバー＋グラフDB＋拡張」という環境を組んだうえで使う想定に近い。この重さは、LSPアプローチを選んだことの裏返しでもある。

AI・LLMのコンテキストとして使う——コードのナレッジグラフの狙いどころ

コード知識グラフというジャンルが盛り上がっている背景には、AI・LLMの事情がある。大規模コードをそのままAIに読ませると、トークンは膨れ、コンテキストウィンドウはすぐ飽和する。そこで「生ファイルを毎回読ませる」代わりに、あらかじめ作った知識グラフに問い合わせ、質問に関連する部分だけを構造化されたコンテキストとしてAIに渡すという発想が広がった。RAG（検索拡張生成）をコードに応用した形で、位置づけの全体像は RAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップ が詳しい。

Bevelの立ち位置は、このジャンルの中でもやや独特だ。READMEは主要ユースケースに「AIやLLMの補強（Augment AI & LLMs）」を明記しているものの、graphifyやCodeGraphのようにMCPサーバーやフック連携、トークン削減の測定値をパッケージとして同梱しているわけではない。つまりBevelは、「AIに渡すための正確なグラフ」までを提供し、そのグラフをどうAIのコンテキストに流し込むかは利用者側で組む前提に見える。ここでも「完成品ではなく部品」という設計が一貫している。

具体的には、次のような組み合わせ方が考えられる。いずれもBevel単体で完結するものではなく、グラフを土台にした設計例として捉えてほしい。

・影響分析をAIエージェントの判断材料にする：「この関数を変えたら壊れるのはどこか」を、グラフの呼び出し・参照エッジをたどって列挙し、その結果だけをAIに渡す。ファイル全体を読ませずに、変更の波及範囲を根拠つきで説明させられる
・アーキテクチャの俯瞰をコンテキスト化する：どのモジュールがハブになっているか、依存の集中がどこにあるかをグラフから抽出し、オンボーディングやリファクタ提案の前提としてAIに与える
・シンボル解決の正確さを活かす：LSP由来のグラフは「実際にどの定義を指すか」に基づくため、同名メソッドのオーバーロードや継承関係が絡む複雑なコードでも、AIに渡す依存情報の取り違えを減らしやすい

裏を返せば、「インストールして数字がすぐ出る」手軽さを求めるなら、MCPサーバーやトークン削減パイプラインを最初から備えたtree-sitter系ツールのほうが立ち上がりは速い。Bevelは、AIコード理解の土台となるグラフを、正確さ優先で自前のパイプラインに組み込みたいケースで真価を発揮する。この違いは優劣ではなく、「出来合いの成果を使うか、土台から組むか」という選択の問題だ。

導入と使い方：VS Code拡張とJVMライブラリの2ルート

Bevelの使い方は、大きく2ルートに分かれる。READMEは「ビルド済みのVS Code拡張を使う（推奨）」と「直接組み込む」の2つを示している。

ルート1：VS Code拡張を使う。 もっとも手軽なのは、VS CodeマーケットプレイスのBevel拡張を入れ、コードベースを開いて解析コマンドを実行する方法だ。READMEの手順は次の通り。

1. VS Code マーケットプレイスから「Bevel」拡張をインストール
2. 対象のコードベースを開く
3. コマンドパレットで「Bevel: Re-/Analyze Project」を実行
4. Bevel Neo4j Visualization などの周辺ツールでグラフを探索

ルート2：JVMライブラリとして組み込む。 自作ツールにグラフ構築を組み込みたい場合は、Mavenで配布されているライブラリ（software.bevel:code-to-knowledge-graph）を依存に追加する。READMEのGradle例ではバージョン 1.1.3 を指定している（コミット履歴には 1.2.0 の記録もあるが、本記事では検証していないためREADME記載の値を示す）。

// build.gradle.kts
dependencies {
    implementation("software.bevel:code-to-knowledge-graph:1.1.3")
}

依存を追加したら、Java／Kotlinのコードからパーサーを生成し、プロジェクトのパスを渡してグラフを得る。READMEの基本例は次のようなものだ。VS Code由来のパーサーを作り、parse() にプロジェクトパスを渡すと、ノードとエッジを持つグラフオブジェクトが返る。

import software.bevel.code_to_knowledge_graph.FactoriesKt;

String projectPath = "/path/to/your/project";
Parser parser = FactoriesKt.createVsCodeParser(projectPath);
Graphlike graph = parser.parse(List.of(projectPath));

System.out.println("Nodes: " + graph.getNodes().size());
System.out.println("Connections: " + graph.getConnections().getAllConnections().size());

parse() が返す Graphlike は、ノード集合と接続（エッジ）集合を持つグラフオブジェクトだ。上の例のように graph.getNodes() でノード一覧、graph.getConnections().getAllConnections() でエッジ一覧にアクセスできる。ここから先は普通のJVMコードなので、特定のクラスを起点に呼び出しエッジをたどって影響範囲を集めたり、ノードをフィルタして自作のレポートを吐いたりと、用途に合わせて自由に処理を組める。「グラフを配列やオブジェクトとして手元で扱える」という素直さが、ライブラリとして組み込むときの扱いやすさにつながっている。

得られたグラフをNeo4jにエクスポートすれば、Cypherでコードの関係を問い合わせられる。たとえば「あるクラスを継承しているノードを全部挙げる」といったクエリは、Cypherでは次のように書ける（クエリ例はNeo4j一般の書き方であり、実際のラベル名やプロパティ名はBevelのスキーマに合わせて調整する）。

MATCH (child)-[:INHERITS]->(parent {name: 'BaseService'})
RETURN child.name, child.file
ORDER BY child.name;

このように、Bevelは「グラフを作るところ」までを担い、その先の可視化・クエリ・ツール化は利用者側で組む。手軽なCLIを期待すると面食らうが、自分のツールにコード知識グラフを埋め込みたい開発者にとっては、この部品としての素直さがむしろ扱いやすい。

どんなチームに向くか——プロジェクトの実体と選定の注意点

最後に、導入を検討するうえで避けて通れない「プロジェクトの実体」を、数字で正直に見ておく。派手なスター数だけで判断すると、実態を見誤るからだ。

このように、Bevelは小規模で、直近の更新が止まっているプロジェクトだ。数万スター級のgraphifyやCodeGraphのような勢いはなく、活発なプロダクトというより、「LSPでコード知識グラフを作る」という設計アイデアを形にしたリポジトリ、と捉えるのが実態に近い。裏取りできない将来性を誇張しても仕方がないので、ここは正直に記しておく。

そのうえで、Bevelが噛み合う場面と、そうでない場面を整理する。

・向いている：コードの依存や影響範囲を、シンボル解決に基づいて厳密に扱う独自ツールを作りたい／グラフをNeo4jに載せてCypherで自由に問い合わせたい／JVM（Kotlin・Java）環境でコード解析基盤を組みたい
・向いていない：とにかく手早くAIコーディングのトークンを削りたい（それならtree-sitter系の完成ツールが速い）／メンテナンスが活発で長期サポートが期待できるツールを求めている／VS Codeや言語サーバーを前提にしたくない

ライセンスのMPL-2.0は、ファイル単位のコピーレフトを持つ寛容寄りのライセンスだ。改変したBevel由来のファイルは同ライセンスでの公開が求められる一方、それを利用する自作コード全体までコピーレフトが伝播するわけではない（GPLとの違い）。商用ツールへの組み込みも、この性質を理解したうえでなら現実的だ。ただしライセンス適用の最終判断は、必ずLICENSE原文を確認してほしい。

総じてBevelは、「AIのトークンを削る完成ツール」を探している人より、「コードを意味解析してグラフにする部品」を探している開発者に向いた、ニッチだが芯のあるツールだ。スター数の勢いや更新頻度だけを見て候補から外すのはもったいないが、逆に「これさえ入れれば全部解決する」と過大に期待するのも実態に合わない。あくまで、LSPで正確なコードグラフを得るための土台として、その一点を評価して使うのが正しい距離感だろう。まずはVS Code拡張で挙動を掴み、腰を据えてライブラリとして組み込むかどうかは、上記の実体と自分たちの用途を照らし合わせて判断するのがよいだろう。コード知識グラフというジャンルの全体像は、あわせて Graphify入門 や、ナレッジ系OSSを俯瞰した ドキュメント/ナレッジ系OSSの選び方｜知識グラフ・図解生成・構造化抽出マップ と読み比べると、それぞれの設計思想の違いがより立体的に見えてくるはずだ。

参照ソース

• Bevel-Software/code-to-knowledge-graph — GitHub（README・LICENSE）
• Bevel Neo4j Visualization — GitHub
• Bevel 拡張 — Visual Studio Marketplace
• Language Server Protocol 公式
• Mozilla Public License 2.0 — 原文