Serenaってなんだろう
「Claude Codeを使っているなら、Serenaも使うといいぞ」
Xの投稿を見てから、使っているSerena。確かに動きがいいかもしれない。ただ、なんとなくでいれているので私はその仕組みがよくわかりません。
そして、やはりAI界隈。数日も立たないうちにSerenaを解説する記事が増えてきました。そのうち、Zenn記事やコムテさんがピックアップした記事を読んでみたものの、よくわかりません。
そこで、SerenaとClaude Codeをつなげるとなぜいい感じになるのか？調べてみることにしました。
本稿ではSerenaの具体的な技術解説はしません。
SerenaとClaude Codeをつなげるといい感じになる理由
結論から言えば、Claude CodeがLanguage Server Protocol(LSP)＋αを使ってコードを理解できるようになるからとわかりました。
LSPとは？
Claude Codeがいい感じになる立役者、LSPとはなんなのでしょうか。これは2016年にMicrosoftが標準化したプロトコル、約束事です。主にコードの構造を正確に理解し、シンボル間の関係を把握します。
ここでの「シンボル」とは、
- 関数名
- 変数名
- クラス名
- メソッド名
- プロパティ名
- 定数名
など名前がついているもの全般を指します。
例えば、LSPがuser.getName()を見たとき、「userは Userクラスのインスタンスで、getNameはそのクラスの5行目に定義されているメソッドで、string型を返す」情報を把握します。LSPは人間がコードを読む理解プロセスを機械的に再現しています。
SerenaがClaude CodeにLSPを提供するため、Claude Codeの動きがよくなる=いい感じになる、という理屈でした。
よくある質問
Q：そもそも、なぜSerenaは開発されたの？
その回答はSerenaのREADMEにありました。
IDE-based tools often use a RAG-based or purely text-based approach, which is often less powerful, especially for large codebases.
README.md:760-761
直近、CursorやWindsurf、Devinなどの主要AIコーディングツールはコード把握においてRAGを推しています。Serenaはそれに対するアンチテーゼとして開発、公開されたのかもしれません。
RAG (Retrieval-Augmented Generation)は、大規模言語モデル（LLM）の回答精度を向上させるための技術、LLMによるテキスト生成に、外部情報の検索を組み合わせることで、回答精度を向上させます。
ちなみにClaude CodeはLSPもRAGも実装されておらず、代わりにAnthropic独自のエージェント検索を使いコードを把握しています。そのアプローチについて、Serenaは次を主張しています。
効率性に関する言及(11-12行目)
You can think of Serena as an IDE for a coding agent. With it, the agent no longer needs to read entire files, perform grep-like searches or string replacements to find and edit the right code.
トークン効率の改善について (39-40行目)
A demonstration of Serena efficiently retrieving and editing code within Claude Code, thereby saving tokens and time. Efficient operations are not only useful for saving costs, but also for generally improving the generated code's quality.
コンテキストの節約に関する指摘(687-690行目)
Moreover, Serena is instructed to be frugal with context (e.g., to not read bodies of code symbols unnecessarily), but we found that Claude is not always very good in being frugal (Gemini seemed better at it).
要はClaude Codeのアプローチは非効率と言っているわけです。事実SerenaはClaude Codeの基本ツールであるファイル作成、読み込み、シェル実行などを除外した上で、LSPベースのセマンティック操作に特化させた実装になっています。
セマンティック(Semantic)とは、「意味論的な」「意味に関する」を表す単語で、プログラミングにおいては、表面的な形式ではなく、その背後にある意味や概念を扱うことを指します。
公式ドキュメントおよびClaude Codeで確認したところ、「LSPもRAGありません」とハッキリ示しました。
SerenaのLSPとRAGの比較
SerenaはClaude Codeの足りない機能を補いつつも、主要AIコーディングエージェントのCursor、Windsurfの強烈なRAG推しに対するアンチテーゼと解説しました。ただ、SerenaのREADMEはLSPの優位性を強調するものの、RAGの具体的な技術的問題点を解説していません。
そこでSerena、従来LSP、RAGのアレコレを調べることにしました。その結果が次です。
アプローチの比較
| 比較項目 | Serena のアプローチ | アプローチ |
|---|---|---|
| コード理解の基盤 | ASTとシンボルテーブル（構造を保持） | ベクトル埋め込み（構造を平坦化） |
| シンボル解決 | 名前空間とスコープを正確に理解 | 文字列の類似性で判断 |
| 依存関係追跡 | find_referencing_symbolsで正確に追跡 | チャンク分割で関係性が失われる |
| メモリ効率 | 必要な部分だけ読み込み（include_body=false） | 全体をベクトル化して保持 |
| プロジェクト切り替え | activate_projectで即座に切り替え | 再インデックスが必要 |
| インクリメンタル更新 | ファイル変更を即座に反映 | バッチ処理での再インデックス |
AST (Abstract Syntax Tree / 抽象構文木)とは、ソースコードの構文構造を木構造で表現したデータ構造を指します。
Serenaが示した従来LSPにある問題の解決策
| 問題領域 | 従来LSPの課題 | Serenaの解決策 | RAGの状況 |
|---|---|---|---|
| AI統合 | エディタ向けでAIには不向き | MCPでAIに最適化 | AIネイティブなものの低精度 |
| トークン効率 | 全文読み込みが前提 | 段階的読み込み（概要→詳細） | 関連チャンク全て取得 |
| マルチプロジェクト | プロジェクトごとにプロセス起動 | プロジェクト切り替え機能 | プロジェクト区別なし |
| メモリ永続化 | セッション終了で消える | メモリ機能で知識保持 | ベクトルDBに永続化 |
Serenaが示すパフォーマンス
| 評価軸 | Serena | 従来LSP | RAG |
|---|---|---|---|
| シンボル検索精度 | 100%（名前空間考慮） | 100% | 60-75% |
| 初期化時間 | 数秒（オンデマンド） | 数分（全体解析） | 数時間（ベクトル化） |
| メモリ使用 | 最小限（段階的読み込み） | 1-4GB（全体保持） | 数GB（ベクトルDB） |
| 更新反映 | 即時 | 即時 | バッチ処理待ち |
| クロスファイル解析 | ✅ 正確 | ✅ 正確 | ❌ チャンク境界で断絶 |
クロスファイル解析とはファイル間の依存関係や相互作用を含めた分析を指します。
Serenaから見たRAG決定的な違い
| 観点 | Serena/LSP | RAG |
|---|---|---|
| 同名シンボルの識別 | utils.process@file1 vs utils.process@file2 を区別 | すべて同じに見える |
| 型情報の保持 | LSP経由で保持 | 失われる |
| リファクタリング安全性 | 全参照箇所を特定 | 見逃しのリスク高 |
| 実行パスの理解 | 制御フローを追跡可能 | 不可能 |
まとめ
SerenaとClaude CodeをMCPで接続するとClaude Codeの動きがよくなるのは、MCP経由でAIにLSP＋αを使えるようなるからでした。本当にただそれだけで変わるのは驚きでした。
また何かしらのGithubリポジトリを使うときは、Deepwikiを使いつつREADMEから思想設計を探るのはいいかもしれませんと気づいたので、今後は習慣づけられるようにしたいトコです。
