CLARC: C/C++ Benchmark for Robust Code Search

既存のコード検索ベンチマークが Python に偏り、語彙的な特徴への依存を十分に検証していない課題を踏まえ、実世界の C/C++ コードから構築され、コンパイル可能性の保証や識別子の匿名化、低レベル言語への変換など多様な頑健性テスト環境を提供する新しいベンチマーク「CLARC」を提案し、最先端モデルが依然として意味理解ではなく語彙的特徴に依存していることを実証した。

要約

この論文は、**「CLARC（クラーク）」**という新しいテスト基準（ベンチマーク）を紹介するものです。

一言で言うと、**「AI がコード（プログラミング言語）を理解しているつもりでも、実はただの『単語の並び』を覚えているだけではないか？」**という疑問を、C/C++ という難しい言語を使って徹底的に検証した研究報告書です。

以下に、専門用語を排し、身近な例え話を使って解説します。

---

1. 問題点：AI は「意味」を理解しているのか？「単語」を覚えているだけなのか？

プログラミングの検索（「この機能を持ったコードを探して」と入力すると、適切なコードが出てくる機能）は、開発者の生産性を高めるために不可欠です。

しかし、これまでのテストでは、AI が本当にコードの**「意味（ロジック）」を理解しているのか、それとも単に「変数名や関数名」**という表面的な単語の一致で答えを出しているだけなのか、見分けるのが難しかったです。

• 例え話：
  料理のレシピ検索で、「卵と小麦粉を使うケーキの作り方」を検索するとします。
  • 本当の理解： 「卵と小麦粉を使っているから、これはケーキのレシピだ」と理解している。
  • 表面的な理解： 「『卵』という文字と『小麦粉』という文字が並んでいるから、これはケーキだ」と勘違いしている。
  • 今の AI の問題： 多くの AI は、後者の「文字の並び」だけで判断してしまい、名前を変えられたり、書き方が変わったりすると、パニックを起こして正解を見つけられなくなってしまうのです。

2. 解決策：CLARC（クラーク）という新しいテスト

この論文の著者たちは、CLARCという新しいテストセットを作りました。これは、実際の GitHub（世界中のプログラマーがコードを共有する場所）から集めた、**「本当にコンパイル（実行）できる C/C++ のコード」**を使っています。

CLARC の最大の特徴は、AI に**「あえて難易度を上げる」**というテストをさせる点です。

3 つの「あえて難易度を上げる」テスト

1. 名前を消すテスト（Neutralized/Randomized）

   • やり方： コード内の「変数名」や「関数名」を、意味のない「func_a」「var_b」や、完全にランダムな文字列に書き換えます。
   • 例え話： レシピの「卵」を「A 材料」、「小麦粉」を「B 材料」と書き換えて、それでも「これはケーキの作り方だ」と言えるか？
   • 結果： 多くの AI は、名前が変わっただけで、全く同じコードなのに「これは違うコードだ」と判断してしまい、検索精度がガクンと落ちました。

2. 機械語にするテスト（Assembly/WebAssembly）

   • やり方： 人間が読む C/C++ のコードを、コンピューターが直接実行する「機械語（アセンブリ言語）」に変換して出します。
   • 例え話： 日本語で書かれた料理レシピを、コンピューターが理解する「0 と 1 の羅列」や、複雑な回路図のような言語に変換して、それでも「これはケーキの作り方だ」と言えるか？
   • 結果： 人間には読めないレベルの言語になると、AI は完全に手詰まりになり、検索が失敗しました。

3. 依存関係を複雑にするテスト

   • やり方： コードが他の多くの部品（関数や型）に依存している場合、その部品も含めて検索できるかテストします。
   • 結果： 複雑なコードになると、AI は文脈を理解できず、正解を見つけられなくなりました。

3. 実験結果：AI は「表面的な記憶」に頼りすぎている

6 つの最先端 AI モデルを使ってテストした結果、以下のようなことがわかりました。

• 名前が変わると、AI はバカになる： 変数名を隠すだけで、AI の性能は半分以下に落ちました。これは、AI が「コードの意味」ではなく、「変数名というヒント」に頼って答えを出していたことを示しています。
• 機械語には弱い： 人間が読めないレベルの言語になると、AI はほとんど役に立ちませんでした。
• 学習（ファインチューニング）でも解決しない： せっかく新しいデータで学習させても、名前が変わったコードや機械語への対応力は改善されませんでした。

4. この研究の意義：なぜ重要なのか？

この研究は、**「今の AI は、コードを『理解』しているわけではない」**という痛烈な警告を発しています。

• セキュリティへの影響： もし AI が名前を変えられただけでコードの意味を見失うなら、悪意のあるハッカーがコードの名前を隠して（難読化して）ウイルスを作っても、AI はそれを検知できない可能性があります。
• 今後の開発： 開発者は、AI が「表面的な単語」ではなく「深い意味」を理解できるように、新しい学習方法やテスト基準を作る必要があります。

まとめ

この論文は、**「AI がコード検索で高いスコアを出しているのは、実は『単語の暗記』に過ぎないのではないか？」という疑問を、「名前を消す」「機械語に変える」**という過酷なテストで暴き出しました。

AI が本当に賢く、安全に使えるようになるためには、単に「正解を当てる」だけでなく、「名前が変わっても、書き方が変わっても、本質を理解できる」ような、より強靭な AI を作っていく必要があると訴えています。

CLARC という新しいテスト基準は、そのための重要な「物差し」として公開されています。

技術概要

CLARC: 堅牢なコード検索のための C/C++ ベンチマーク（技術的サマリー）

本論文は、ICLR 2026 にて発表された「CLARC (C/C++ LAnguage Retrieval with Anonymized Code)」という新しいコード検索ベンチマークと、その構築パイプラインに関する研究です。既存のベンチマークが抱える課題を克服し、コード検索モデルの「堅牢性（Robustness）」、特に表面的な語彙的特徴への依存度を評価することに焦点を当てています。

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

1. 問題定義と背景

既存のコード検索ベンチマークには、実用的な評価を行う上で以下の重大な限界が存在します。

1. 言語の偏り: 多くのデータセットが Python 中心であり、システムプログラミング言語である C/C++ のテキスト・ツー・コードタスクが軽視されている。
2. コンパイル不可能なコード: 多くのベンチマークのコードスニペットは、インクルード文やヘルパー関数が欠落しており、コンパイルできない。これは、実際の開発現場における依存関係の理解という重要な要素を欠いている。
3. 堅牢性の欠如: 変数名の変更（匿名化）やコードの難読化、低レベル言語（アセンブリ等）へのコンパイルなど、テキスト的な摂動に対するモデルの耐性を評価するテストが不足している。その結果、モデルがコードの意味（セマンティクス）を理解しているのか、単に識別子名などの表面的な語彙的特徴に依存しているのかを区別できない。

2. 手法と CLARC の構築

CLARC は、GitHub の実プロジェクトから自動的に抽出された、完全にコンパイル可能な C/C++ コードに基づいて構築されています。

データセットの特性

• 規模: 評価用 1,245 ペア、学習用 5,472 ペア（合計 6,717 ペア）。
• 依存関係の複雑さによる分類:
  • Group 1: 標準ライブラリのみを使用。
  • Group 2: 標準ライブラリ＋カスタム定義変数型を使用。
  • Group 3: ユーザー定義のヘルパー関数を呼び出すコード（さらに「Short」と「Long」に分割）。
• 堅牢性評価のための設定（Settings）:
  • Neutralized: 識別子を汎用的なプレースホルダー（例：func_a, var_b）に置換。構造的役割は維持。
  • Randomized: 識別子をランダムな文字列に置換。すべての語彙的情報を排除。
  • Assembly / WebAssembly (Wasm): コードを x86 アセンブリまたは WebAssembly にコンパイル。識別子がほぼ完全に消去される低レベル表現。

クエリ生成と検証

• LLM による生成: 抽出された関数に対して、LLM（o3-mini, grok-4）を用いて自然言語クエリを自動生成。
• 厳密な検証: 生成されたクエリの品質を確保するため、熟練エンジニアによる人間評価と、統計的仮説検定（Hypothesis Testing）を実施。その結果、LLM 生成クエリは人間作成クエリと同等かそれ以上の品質であることが確認されました。

3. 主要な貢献

1. CLARC ベンチマークの導入: 依存関係の複雑さや匿名化、低レベル言語コンパイルなど、多様な設定下での検索堅牢性を評価できる、完全にコンパイル可能な C/C++ データセット。
2. スケーラブルな自動化パイプラインの設計: 仮説検定による検証プロセスを組み込んだ、高品質で多様な評価リソースを効率的に生成するパイプライン。
3. モデルの限界の解明: 現在の最先端モデルが、コードの意味理解ではなく、表面的な語彙的特徴（識別子名など）に過度に依存していること、および低レベル言語への一般化能力が限られていることを実証。

4. 実験結果

6 つの最先端モデル（BM25, CodeT5+, OASIS, Nomic-emb-code, OpenAI-text-embedding-large, Voyage-code-3）を評価しました。

• 標準設定 vs. 匿名化設定:
  • 識別子を匿名化（Neutralized/Randomized）すると、すべてのモデルで検索性能が劇的に低下しました。
  • 例：Voyage-code-3 や Nomic-emb-code などの高性能モデルでも、Group 3（複雑な依存関係）において Neutralized 設定では性能が急落しました。
  • 結論: モデルはコードのセマンティクスではなく、識別子名などの語彙的特徴に強く依存している。
• 低レベル言語（Assembly/Wasm）:
  • アセンブリや WebAssembly へのコンパイルにより、性能はさらに大幅に低下しました。
  • 高レベル言語の論理が低レベルの命令に展開されることで、意味的なシグナルが希薄化し、モデルが処理できなくなることが示されました。
• ファインチューニングの影響:
  • 標準設定や匿名化データでファインチューニングを行っても、標準設定と匿名化設定の間の性能格差は解消されませんでした。
  • 結論: 従来の教師ありファインチューニングだけでは、この種の堅牢性の欠陥を克服することは困難です。

5. 意義と将来展望

CLARC は、コード検索モデルが「表面的な語彙」ではなく「コードの意味」を本当に理解しているかを検証するための重要な基準を提供します。

• セキュリティと逆工学: 識別子匿名化や低レベル言語への耐性を評価することは、コード難読化やマルウェア分析、逆工学の文脈でも重要です。
• 今後の研究方向:
  • 低レベル言語（アセンブリ、Wasm）に対する堅牢な検索モデルの開発。
  • 大規模な学習データを用いた、語彙的特徴に依存しないセマンティック理解の強化。
  • 同様にコンパイル可能で多様な評価が可能なデータセットのコミュニティへの普及。

本論文は、現在のコード検索技術が直面している「意味理解の欠如」という根本的な課題を浮き彫りにし、より堅牢なシステム開発のための道筋を示す重要な研究です。