論文「Less Is More: Measuring How LLM Involvement Affects Chatbot Accuracy in Static Analysis」の技術的サマリー

この論文は、静的解析ツール（Joern）の自然言語インターフェースにおいて、大規模言語モデル（LLM）の関与度をどの程度に抑えるべきかを実証的に検証した研究です。LLM に直接クエリ生成を任せるのではなく、構造化された中間表現を介して決定論的なコードに委任するアプローチが、最も高い精度を達成することを示しています。

以下に、問題定義、手法、主要な貢献、結果、および意義について詳細をまとめます。

---

1. 問題定義 (Problem)

静的解析ツール（例：Joern）は、抽象構文木（AST）、制御フローグラフ（CFG）、データフローグラフを統合した「コードプロパティグラフ（CPG）」を基盤としており、これらをクエリ言語（CPGQL）で操作することで高度な分析が可能です。しかし、CPGQL はニッチなドメイン固有言語（DSL）であり、構文や意味論の習得が困難なため、開発者の利用障壁となっています。

近年、LLM を用いて自然言語を CPGQL に変換する試みが増加していますが、以下の課題があります：

• LLM の限界: LLM は確率的な近似であり、形式意味論に基づいた推論が苦手です。特に、トレーニングデータに少ない DSL においては、構文は正しくても意味が異なる「ハルシネーション」を起こしやすい。
• 設計の欠如: 既存システムは LLM の関与度（直接生成か、ツール利用か等）を独立変数として体系的に比較・評価しておらず、どの程度の delegation（委任）が最適か不明確でした。

本研究は、**「LLM の出力空間をどの程度制約するか」**が静的分析タスクの精度にどう影響するかを明らかにすることを目的としています。

2. 手法とアーキテクチャ (Methodology)

自然言語から CPGQL への変換タスクにおいて、LLM の自律性のスペクトルに沿って 3 つのアーキテクチャを比較しました。

評価対象アーキテクチャ

1. A1: 直接生成 (Direct Generation)
   • LLM が自然言語要求を受け取り、ドキュメントや例を参照して直接 CPGQL クエリ文字列を生成します。
   • 出力空間は非制限的（任意の文字列）であり、LLM は Scala 風の DSL 構文、メソッドチェーン、グラフ走査意味論をすべて処理する必要があります。
2. A2: 構造化中間表現 (Structured Intermediate)
   • LLM は CPGQL ではなく、事前に定義された JSON スキーマに準拠したオブジェクトを生成します。
   • この JSON（クエリタイプ、スコープ、フィルタ、出力カラムなど）は、決定論的なマッパーによって正しい CPGQL へ変換されます。
   • LLM は DSL 構文を扱わず、型付きフィールドの選択とエンティティ名の抽出のみを行います。
3. A3: ツール拡張エージェント (Tool-Augmented Agentic)
   • LLM は ReAct パターンに従い、分析機能（find_methods, trace_data_flow など）をツールとして呼び出します。
   • 多段階のループでツールを選択し、結果を解釈して最終回答を生成します。

評価設定

• ベンチマーク: 20 件のコード分析タスク（構造的、データフロー、複合の 3 つの複雑度レベル）を定義。Apache Commons Lang と OWASP WebGoat の 2 つの Java プロジェクトで評価。
• モデル: 4 つのオープンウェイトモデル（Llama 3.1/3.3, Qwen 2.5）を使用。
  • 大規模モデル: 70B-72B パラメータ
  • 小規模モデル: 7B-8B パラメータ
• 指標: 結果の一致率（Result match）、実行成功率、トークン消費量、LLM 呼び出し回数。

3. 主要な貢献 (Key Contributions)

1. 自然言語から CPGQL への翻訳タスク用ベンチマークの公開: 20 件のタスクと、Joern 4.0 による機械検証されたグランドトゥルースを含む。
2. LLM 関与度の制御された比較: 自律性の異なる 3 つのアーキテクチャを、一貫したリトライポリシー下で公平に比較。
3. 構造化中間表現の優位性の実証: 形式化されたドメインにおいて、LLM の出力を構造化された中間表現に制約し、クエリ構築を決定論的コードに委任することが、直接生成やエージェントアプローチよりも優れていることを示した。
4. モデルサイズとアプローチの相互作用の発見: 構造化中間表現の恩恵は大規模モデルで顕著だが、小規模モデルではスキーマ準拠の失敗がボトルネックになることを明らかにした。

4. 結果 (Results)

精度の結果

• A2（構造化中間）が最優秀: 全てのモデルで A2 が最高精度を記録しました。
  • 大規模モデル: A1（直接生成）に対し、15〜25 ポイントの精度向上（例：Qwen 72B で 43.3% → 58.3%）。
  • 小規模モデル: 改善は modest（3〜5 ポイント）ですが、依然として A1 よりも優れています。
• A3（エージェント）が最悪: 大規模モデルでも A2 の半分以下の精度（Qwen 72B で 25.0%）であり、小規模モデルではさらに低下（15.0%）。
  • コスト対効果の欠如: A3 はタスクあたり平均で A2 の8 倍のトークンを消費し、実行時間も 6 倍長くかかりながら、精度は最も低かった。

重要な洞察

1. モデルサイズとの相互作用:
   • 大規模モデルは JSON スキーマを 100% 正しく生成でき、アーキテクチャの恩恵を最大限享受しました。
   • 小規模モデルは A2 において 35〜47% の確率で JSON パースやスキーマ検証に失敗しました。これは、LLM が意図を正確に表現する精度が、構造化された出力の要件を満たすのに不十分であることを示しています。
2. エージェントの失敗パターン:
   • A3 は、構造的な単純タスク以外（データフローや複合タスク）で性能が劇的に低下しました。
   • 多段階のツール呼び出しにおいて、誤ったツール選択や結果の解釈ミスが累積し、最終的な正解に至らないケースが多発しました。
   • 包含関係: A3 が正解したタスクは、A2 が正解したタスクの厳密な部分集合でした。A3 が A2 にはできないタスクを解決したケースは一つもありませんでした。
3. トークン量と精度の非相関:
   • 多くの計算リソース（トークン）を消費しても、アーキテクチャのミスマッチ（LLM に複雑な推論を強いること）を補うことはできませんでした。
4. 評価指標の重要性:
   • 文字列完全一致（Exact Match）ではなく、クエリ実行結果の一致（Result Match）で評価することが重要であることが示されました。LLM は構文は異なっても意味的に同等のクエリを生成できるため、文字列一致だけでは実用性を過小評価します。

5. 意義と結論 (Significance & Conclusion)

本研究は、**「Less Is More（少ない方が多い）」**という原則を静的分析の文脈で実証しました。

• 設計指針: 形式化されたドメイン（DSL 生成など）において、LLM の役割を「自然言語理解とスキーマへの分類」に限定し、構文生成や論理構築を決定論的なコードに任せるアーキテクチャ（A2）が最も効果的です。
• LLM の限界の克服: 論文で引用された Anand らの研究（LLM は構文トークンと識別子の間の関係性をエンコードできない）を裏付け、LLM に DSL 構文そのものを生成させるのではなく、制約された中間表現を生成させることで、この限界を回避できることを示しました。
• エージェントアプローチへの警鐘: ツール利用型のエージェントアプローチは、タスクが複雑になるほどエラーが累積し、コスト対効果が著しく低下することを示しました。特に静的分析のような厳密な形式意味論が求められる領域では、エージェントの自律性は害になる可能性があります。

結論として、静的分析チャットボットの構築においては、LLM を「クエリ生成機」としてではなく、「構造化された意図の抽出機」として位置づけ、その出力を堅牢なマッパーに渡す設計が、精度、コスト、信頼性のすべてにおいて最適であることが示されました。