AST

LLMのコード理解精度を高めるASTの基本概念

LLMに数万行のソースコードをそのまま読み込ませて絶望した経験はないだろうか。文脈は途切れ、存在しない関数をでっち上げる。言語モデルはコードを単なる文字列の連続として確率的に処理しているにすぎないからである。

ここでASTが登場する。

ASTはコードを抽象構文木というツリー構造に変換し、変数や関数の依存関係を明確にする。Code Agentがコードの意図を正確に把握し、的確な修正案を提示できるのは、裏でこのASTがコードの骨格をAI向けに翻訳しているからである。テキストの表面的なパターンマッチングではなく、構造そのものを理解させるアプローチである。

ソースコードがツリー構造に変換される仕組み

テキストのコードがASTになる過程は、経理部門がバラバラの領収書を処理する手順に似ている。まず字句解析によって、コードという文字列の塊を変数名や演算子といった最小単位のトークンに切り分ける。次に構文解析が働き、プログラミング言語の文法規則に従ってトークン同士を繋ぎ合わせ、階層的なツリーを組み上げる。

この静的解析のプロセスを経ることで、AIはこの変数がどこで定義されどの関数で使われているかを瞬時に辿れるようになる。ただの文字列が、意味を持ったデータベースに生まれ変わる瞬間である。これを自前で実装しようとすると泥沼にハマるのだが、そこをどう乗り切るかは悩ましい。

ASTを活用した最新AIツールの実用例

現場でエンジニアが日常的に使っているGitHub CopilotやCursor、あるいは自律型AIソフトウェアエンジニアと呼ばれるDevin。これらのツールが魔法のように文脈を読んだコードを生成できるのは、背後でASTをフル活用しているからである。

カーソルを合わせた関数の定義元や、影響を受ける呼び出し先をASTで特定し、その部分だけを抽出してLLMのプロンプトに忍ばせる。コンテキストウィンドウの無駄遣いを防ぎ、ハルシネーションを抑え込む。素のLLMに丸投げするだけのツールとは、出力の精度がまるで違う。あなたの現場で導入しているツールは、本当にコードの構造を理解しているだろうか。

ASTを用いたコード解析のメリットと技術的な限界

ASTの最大の強みは、安全なリファクタリングを可能にすること。変数名の変更や関数の切り出しを行う際、文字列置換のような事故は起きない。ツリー構造のノードを操作するだけで済む。

だが、万能ではない。

PythonやJavaScriptのような動的型付け言語を相手にする場合、実行時にならないと型や挙動が確定しない要素が多く、ASTによる静的解析だけでは追いきれない壁にぶつかる。AIが提示した修正案が、特定の条件下でクラッシュを引き起こすリスクは常につきまとう。静的解析の限界をどこまで許容してAIにコードを書かせるかは、プロジェクトの性質によって判断が分かれるところである。

製造業の組み込み開発現場における導入のリアル

製造業のファームウェア開発などで、数十年前のC言語のレガシーコードを解析するプロジェクトを想像してほしい。担当者が退職し、ドキュメントもない。ここでASTベースの解析ツールを導入してコードの依存関係を可視化し、AIにリファクタリングを任せるというアプローチが考えられる。

しかし、ハードウェア固有の割り込み処理やメモリ管理の泥臭いビジネスロジックまで、ASTとAIの組み合わせで完全に解読できるわけではない。情報セキュリティの観点からクラウドのLLMにソースコードを出せない場合、ローカル環境で動く軽量モデルとAST解析器をどう連携させるか。現場の制約と技術の限界を天秤にかけ、どこまで内製化の工数を割くか、泥臭い決断を迫られる日々が続く。