ソースコードRAGの精度が劇的向上？「意味」で切るASTチャンキング導入の現実解

なぜ、あなたのRAGは「コードの意味」を理解できないのか？

「社内のコードベースを検索できるようにしたけれど、肝心なロジックがヒットしない」
「質問とは関係ない、似たような変数名の箇所ばかりが表示される」

実務の現場でRAG（Retrieval-Augmented Generation）を導入した際、このような課題に直面することは少なくありません。もし今、同様の悩みを抱えているなら、それは検索モデル（Embeddings）の性能不足が原因ではない可能性が高いです。多くの場合、根本的な原因はデータの前処理、すなわちデータの切り方（チャンキング）にあります。

これまで、ソースコードを扱うRAGにおいて、一般的なドキュメントと同じ「固定長チャンキング」を採用してしまうケースが散見されます。しかし、これはコードという高度に構造化された情報を、単なる文字列として扱ってしまうことを意味します。

テキスト分割の限界：関数が真っ二つになる悲劇

具体的な例で考えてみましょう。精巧なアルゴリズムを含む関数があるとします。これを「500文字ごと」などの単純なルールで機械的に分割すると、どのような事態が起こるでしょうか。

単純な文字数分割では、関数のシグネチャ（定義部分）と、その内部の重要な条件分岐ロジックが、別々のチャンク（塊）に分断されるリスクが高まります。検索エンジンが「条件分岐のロジック」を見つけ出したとしても、それが「どの関数の、どのような引数に対する処理なのか」という重要な文脈はすでに失われています。

これでは、推論能力に優れた最新のLLMを用いたとしても、正確で実用的な回答を生成することは困難です。コードは一般的な文章とは異なり、上から下へ読まれるだけでなく、ネスト（入れ子）構造やスコープといった論理的なつながりを持っています。物理的な文字数で区切るアプローチは、精密機械をノコギリで切断して保管するようなものであり、後から組み立てて機能させることは不可能です。

「検索しても欲しいコードが出ない」原因の9割はチャンキングにある

近年、RAGの技術は急速に進化しており、GraphRAG（ナレッジグラフを活用した検索）やエージェント型RAGといった高度な手法が次々と登場しています。しかし、どれほど高度な検索手法を導入したとしても、基礎となるデータ（チャンク）が「意味の単位」で適切に区切られていなければ、投資対効果（ROI）は半減してしまいます。

コードにおける「意味」とは何でしょうか。
それは「特定の処理を行う関数」であったり、「データの構造を定義するクラス」であったりします。これらはプログラミング言語の構文規則に基づいた論理的なブロックです。

従来の単純なテキスト分割（CharacterTextSplitterなど）では、この論理ブロックが無視されます。結果として、ベクトル化されたデータは「中途半端なコードの断片」となり、検索クエリ（質問）との意味的なマッチング精度が著しく低下します。これが、RAGがコードの意図を正確に理解できない根本原因です。

この記事で目指すゴール：構造を保ったまま分割する

では、プロジェクトを成功に導くためにはどうすればよいのでしょうか。答えはシンプルです。コードの構造（構文）に合わせて分割を行うことです。

これを実現する技術が、今回解説するAST（抽象構文木）チャンキングです。「AST」や「構文解析」と聞くと、コンパイラ構築のような難解な理論を想像されるかもしれません。しかし、現代のAI開発エコシステムにおいては、高度な専門知識がなくても実装可能な環境が整いつつあります。

本記事では、学術的な理論の深掘りよりも「実務の現場でどう活用するか」に焦点を当て、明日からプロジェクトに組み込める実践的なアプローチを共有します。

AST（抽象構文木）を「プログラミングの地図」として理解する

「AST（Abstract Syntax Tree）」という用語にハードルを感じる必要はありません。RAG構築の文脈において、ASTは単なる「コードの地図」として捉えてください。

難しい理論は不要！木構造で捉えるコードの姿

開発現場で普段扱っているソースコードは、エディタ上に並ぶ「行」の集まりに見えます。しかし、コンピュータ（コンパイラやインタプリタ）は、これを「行」ではなく「ツリー（木）構造」として認識しています。

例えば、ある家（クラス）の中に、キッチン（メソッドA）とリビング（メソッドB）があり、キッチンの中に冷蔵庫（変数）がある、といった階層構造です。この構造をデータとして表現したものがASTです。

• ルート（根）: ファイル全体
• ノード（節）: クラス定義、関数定義、if文などのブロック
• リーフ（葉）: 変数名、文字列、数値などの具体的な値

ASTチャンキングとは、文字数で機械的に切るのではなく、この「部屋（ノード）」の境界線に沿ってデータを分割する手法です。「キッチンを丸ごと一つのチャンクにする」ことができれば、その内部の冷蔵庫や調理器具（ロジック）の関係性は正確に保たれます。

コンパイラが見ている世界を覗いてみる

なぜこの構造的な視点が重要なのでしょうか。それは、LLMがコードを理解するプロセス自体が、構造的理解に基づいているからです。

プログラミング言語には厳密な文法が存在します。ASTベースで分割するということは、この文法的に正しい「意味のまとまり」を維持したままベクトル化することを意味します。

例えば、Pythonのコードであれば、インデントの深さが変わる場所が意味の切れ目になることが一般的です。ASTを活用すれば、「現在のインデントブロックが終わるまで」を一つの単位として抽出できます。これにより、検索エンジンは「中途半端なコード片」ではなく、「完結した機能ブロック」をインデックス化できるようになります。

AIにとって「意味のある塊」とは何か

人間がコードを読む際、関数名から「何をする処理か」を推測し、内部のロジックを読み解きます。AIの処理プロセスもこれと本質的に同じです。

• 悪い分割: 関数の後半10行だけが含まれるチャンク
  • AIの解釈：「この処理はどの関数の続きか？ 変数 x の定義元が不明確である」
• 良い分割（AST）: 関数全体が含まれるチャンク
  • AIの解釈：「関数 calculate_tax の定義である。引数に金額をとり、税率を掛けて返却する処理を行っている」

この「文脈の完結性」こそが、RAGの回答精度（Generation Quality）を劇的に左右します。ASTチャンキングは、AIに対して「読みやすく整理された参考書」を提供するための不可欠な前処理と言えます。

AIベースのASTチャンキング：面倒なパーサー実装を回避する近道

「理論は理解できるが、全言語のパーサー（解析器）を自前で実装するのは現実的ではない」

プロジェクトマネジメントの観点からも、その懸念は極めて妥当です。実務において、言語ごとに厳密なASTパーサーをゼロから構築するのは、コストと保守性の面で見合いません。しかし現在は、「AIベース」や「モダンなライブラリ」を活用することで、この実装ハードルを効果的に回避できます。

従来の手法 vs AIベースの手法

かつて、コード解析といえば複雑な正規表現を記述するか、言語仕様書を参照しながらLexer/Parserを独自実装するのが一般的でした。

• 正規表現: 変化に弱く脆い。コメント内に特定の単語が含まれるだけで誤検知を引き起こす。
• 厳密なパーサー: 正確だが実装コストが高い。言語のバージョンアップへの追従が負担となる。

これに対し、現在はLangChainやLlamaIndexといったフレームワークが、主要言語（Python, JavaScript, Go, Javaなど）に対応したコード分割機能（Code Splitter）を標準で提供しています。

特にLangChainの最新バージョンでは、セキュリティ対策や最新のLLMモデルへの統合が強化されています。外部データの読み込み処理における安全性が向上しており、エンタープライズ環境での信頼性も確保されています。開発チームは複雑なパーサーの保守から解放され、フレームワークが提供する標準的なスプリッターを利用するだけで、一定レベルの構造化を迅速に実現できます。

また、LlamaIndexもRAG構築に特化したフレームワークとして、コードを含む多様なデータソースの構造化を強力にサポートしています。これらのツールは継続的にアップデートされており、最新の言語仕様やAIモデルへの対応が期待できるため、自前実装よりもはるかに持続可能でROIの高い選択肢となります。最新の仕様については、各公式ドキュメントを参照してプロジェクトに適用してください。

LLMに「構文の区切り」を判断させるアプローチ

さらに先進的なアプローチとして、LLM自体を活用してチャンキングを行う手法（Semantic Chunkingの一種）も実用化されつつあります。

LLMはすでに多様なコードの構造を学習しています。「このコードファイルを、関数やクラスごとの意味ある単位に分割してJSON形式で出力せよ」とプロンプトで指示することで、専用のパーサーなしに精度の高い分割が可能です。

トークンコストや処理速度の課題は存在しますが、バッチ処理でのインデックス作成時や、既存パーサーが適用しにくい複雑なレガシーコードを扱う際には、LLMの文脈理解力を活用した分割が非常に有効な手段となります。

Tree-sitterなどのツールとAIの役割分担

実務における現実的な最適解として推奨されるのは、「軽量なパーサーライブラリ」と「AIによるメタデータ付与」のハイブリッドアプローチです。

例えば、Tree-sitterのような高速な増分解析ツールを用いて物理的なブロック（関数、クラス）を切り出し、その要約や依存関係の説明をLLMに生成させてメタデータとして付与します。これにより、処理速度と検索精度の最適なバランスを実現できます。

すべてをAIに依存するのではなく、構造的な切り出しは専用ツールに任せ、意味的な補足や文脈の付与をAIに行わせる。この適材適所の設計こそが、AI駆動開発を成功に導く原則です。

失敗しないための導入3ステップ：小さく始めて効果を実感する

大規模なリポジトリに対して、いきなり高度なASTチャンキングを全面適用しようとすると、インデックス作成のオーバーヘッドが大きくなり、プロジェクトが停滞するリスクがあります。PoC（概念実証）の基本に立ち返り、まずは小さく始めて効果を検証しましょう。

Step 1：対象言語の選定とライブラリの準備

最初に、プロジェクト内で最もドキュメント化が不足している、あるいは検索ニーズが高い言語を一つ選定します（例：PythonやTypeScript）。

ツール選定においては、LangChainやLlamaIndexといった主要フレームワークが第一候補となります。ここでは実践的な第一歩として、LangChainの RecursiveCharacterTextSplitter.from_language を試してみましょう。これは厳密なAST解析ではありませんが、言語ごとのセパレーター（クラス定義、関数定義など）を優先的に使用して分割するため、ASTに近い効果を低コストで得ることができます。

また、LlamaIndexもコード解析において強力な選択肢です。最新の対応言語や推奨される分割手法については、公式ドキュメント（docs.llamaindex.ai）で確認し、要件に合ったものを選択してください。

from langchain.text_splitter import RecursiveCharacterTextSplitter, Language

# Pythonコード用のスプリッターを作成
# ※最新のAPI仕様は公式ドキュメントを参照してください
python_splitter = RecursiveCharacterTextSplitter.from_language(
    language=Language.PYTHON, chunk_size=1000, chunk_overlap=200
)

このシンプルな実装だけでも、単なる文字数分割と比較して、検索精度は明確に向上します。

Step 2：クラス・関数単位での分割を試す

次に、精度をさらに高めるため、関数やクラス単位での明確な分割を検証します。ここでは、生成された各チャンクが「自己完結」した意味を持っているかを確認してください。

もし、一つの関数が巨大すぎて（例えば数千行に及ぶファットクラスなど）、チャンクサイズの上限を超える場合はどう対処すべきでしょうか。ここでASTの階層構造が活きてきます。関数全体を一つの親チャンクとして扱い、その内部の論理ブロック（if文やループなど）を子チャンクとして分割する設計を取り入れます。

Step 3：メタデータを付与して検索性を高める

ここが、実用的なAIアプリケーションを構築する上で最も重要なテクニックです。コードを分割すると、どうしても「親のコンテキスト情報」が失われがちです。例えば、method_A というチャンク単体を見ても、それが UserClass に属していることは判別できません。

そこで、チャンクを生成するプロセスにおいて、メタデータとして「ファイルパス」「クラス名」「親関数名」を明示的に付与します。

• Chunk Content: def method_A(self): ...
• Metadata: {"file": "user.py", "class": "UserClass", "parent": "method_A"}

このようにメタデータを構造的に充実させることで、検索実行時に「どのクラスのメソッドであるか」をLLMが正確に把握できるようになり、最終的な回答精度と実用性が劇的に向上します。