CangjieBench: Benchmarking LLMs on a Low-Resource General-Purpose Programming Language

本論文は、データ不足に直面する汎用プログラミング言語「Cangjie」を対象とした汚染のないベンチマーク「CangjieBench」を提案し、大規模言語モデルの性能を多角的に評価することで、低リソース言語への一般化に関する洞察を提供しています。

要約

新しい言語「倉颉（そうけつ）」と AI の挑戦：CANGJIEBENCH の解説

この論文は、**「AI が、誰もまだ十分に知らない新しいプログラミング言語を、どうやってマスターできるか？」**という面白い実験について書かれています。

まるで、**「誰も住んだことのない新しい国（言語）に、AI という旅行者を送り込み、地図も辞書もなしに家を建てられるか？」**という冒険物語のようなものです。

以下に、専門用語を排して、わかりやすく解説します。

---

1. 背景：なぜ「倉颉（そうけつ）」なのか？

まず、**「倉颉（Cangjie）」**というプログラミング言語が登場します。
これは中国の Huawei が開発した、スマホや家電、クラウドまで何でも動かせる「万能言語」です。

• Python や C++：すでに世界中に何億もの本（データ）があり、AI はこれらを完璧に覚えています。
• 倉颉：生まれたばかりの言語なので、AI が学習できる「本」がほとんどありません。

【問題】
AI は、本がたくさんある言語なら得意ですが、本がほとんどない言語だと、まともなコードが書けません。
これまでの研究は、「特定の目的だけ使う言語（DSL）」に焦点を当てていましたが、「何でもできる万能言語」でデータが少ない場合の研究は不足していました。

2. 実験の舞台：「CANGJIEBENCH」というテスト

そこで研究者たちは、**「CANGJIEBENCH（倉颉ベンチ）」**というテストを作りました。

• ** contamination-free（汚染なし）**：
  既存のインターネットからデータを拾うと、AI が「答えを丸暗記」してしまっている可能性があります。それを防ぐため、人間が手作業で、有名なテスト問題（Python の問題）を倉颉に翻訳しました。

  • 例え話：「暗記した答えを写す」のではなく、「新しい言語のルールを初めて見て、ゼロから解く」状態を作ったのです。

• 248 問のテスト：
  簡単な計算問題から、複雑なクラス設計まで、幅広い難易度の問題を準備しました。

3. 4 つの「攻略法」を比較

AI にこの新しい言語を解かせるために、4 つの異なるアプローチを試しました。

① 直接生成（Direct Generation）

• やり方：「倉颉でこの問題解いて」と言うだけ。辞書もなし。
• 結果：大失敗。
  • 例え：「日本語を話せない外国人に、いきなり日本語で料理のレシピを書け」と言うようなもの。文法がバラバラで、コードが動かない（コンパイルエラー）ばかりでした。

② 文法制約付き生成（Syntax-Constrained Generation）

• やり方：「倉颉の文法ルール（辞書の要約版）」を AI に見せてから解かせます。
• 結果：大成功（コストパフォーマンス最高）。
  • 例え：「料理のレシピは日本語でいいけど、**『鍋は火にかけないといけない』『塩は小さじ 1 杯』**という基本的なルールだけ教えてあげたら？」と教える方法。
  • AI は「料理のロジック（何をどうするか）」はすでに知っているので、「文法ルール」さえ教えれば、驚くほど上手に書けることがわかりました。

③ 検索強化生成（RAG）

• やり方：AI が「倉颉の公式マニュアル」や「過去のコード例」を検索して、それを見ながら解かせます。
• 結果：少し良くなりましたが、②の「文法ルール」には劣りました。
  • 理由：マニュアルや断片的なコード例だけでは、AI が混乱して、ルールを正しく適用できないことが多かったようです。

④ エージェント（Agent）

• やり方：AI に「自分でマニュアルを読み、試行錯誤して、間違ったら直す」という自律的な開発者のような役割を与えます。
• 結果：**最も正確（SOTA）**ですが、非常に高コスト。
  • 例え：「料理が作れる人」に「自分で図書館に行って本を読み、試作して、失敗したらまた本を読み直す」ことをさせたら、完璧な料理ができました。
  • しかし、時間とコスト（トークン消費）が膨大にかかりました。

4. 意外な発見：「翻訳」は「ゼロから書く」より難しい？

通常、「Python のコードを倉颉に翻訳する（Code-to-Code）」の方が、「倉颉でゼロから書く（Text-to-Code）」の方が簡単だと思われがちです。

しかし、実験では逆の結果が出ました。

• 翻訳の方が失敗しやすい：
  AI は「Python の書き方」に強く引きずられてしまい、倉颉のルールを無視して Python 風に書いてしまう（これをネガティブ転移と呼びます）。
• ゼロから書く方が成功しやすい：
  逆に、問題文だけを見てゼロから書かせると、AI は「Python の癖」に縛られず、与えられた「倉颉のルール」に従って素直に書けるのです。

5. 結論：何がわかったのか？

この研究から、以下の重要なことがわかりました。

1. AI は「論理」は持っている：新しい言語でも、ロジック（計算の仕組み）は理解しています。
2. 必要なのは「文法ルール」：AI が新しい言語をマスターするために必要なのは、大量のデータではなく、**「簡潔で正確な文法ルール」**です。
3. コストと性能のバランス：
   • 一番バランスが良いのは**「文法ルールを教える方法」**。
   • 一番正確だが高コストなのは**「エージェント（自律型 AI）」**。
4. 翻訳の罠：既存のコードを翻訳する際、元の言語の癖が邪魔をして、かえって失敗しやすくなることがあります。

まとめ

この論文は、**「新しいプログラミング言語が登場したとき、AI をどう育てるか」の指針を示しました。
「莫大なデータで学習させる」のではなく、「必要なルールだけを教えて、AI に考えさせる」**というアプローチが、低資源言語（データが少ない言語）には最も効果的であることが証明されました。

これは、今後、世界中に次々と生まれる新しい言語や技術に対して、AI をどう適応させるかという未来への重要なヒントとなっています。

技術概要

CANGJIEBENCH: 低リソース汎用プログラミング言語における LLM のベンチマーク評価

論文の技術的サマリー（日本語）

本論文は、大規模言語モデル（LLM）が、データが不足している「低リソース」かつ「汎用」のプログラミング言語においてどのように振る舞うかを評価するための新しいベンチマーク「CANGJIEBENCH」を提案し、その上で複数の生成手法を体系的に評価した研究です。対象言語は、華為（Huawei）が開発した HarmonyOS エコシステムの基盤となる新しい汎用言語「Cangjie」です。

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

---

1. 問題定義と背景

• 低リソース言語の課題: 既存の LLM は Python や C++ などの高リソース言語では高い性能を示しますが、学習データが極めて少ない低リソース言語では性能が大幅に低下します。
• 既存研究の限界: 従来の低リソース言語研究は、Verilog や Solidity などの「ドメイン固有言語（DSL）」に焦点が当てられていました。DSL は特定の分野（ハードウェアやブロックチェーン）に密接に関わるため、モデルの失敗が「構文知識の欠如」によるものか「ドメイン知識の欠如」によるものかを区別することが困難でした。
• Cangjie の特殊性: Cangjie は汎用言語であり、アルゴリズム的普遍性を持ちつつ、2025 年 7 月にリリースされたばかりの新しい言語です。そのため、事前学習データに存在せず、モデルの「構文適応能力」を純粋に評価する理想的な対象となります。また、既存の翻訳ベンチマークは高リソース言語間（例：Java-Python）が中心であり、高リソース言語から低リソース言語への翻訳（Python → Cangjie）の評価は不足していました。

2. 提案手法：CANGJIEBENCH

本研究では、Cangjie 向けに汚染（Contamination）のない高品質なベンチマーク「CANGJIEBENCH」を構築しました。

• データセット構築:
  • 既存の Python ベンチマーク「HumanEval」（関数レベル）と「ClassEval」（クラスレベル）を、専門家が手動で Cangjie に翻訳しました。
  • ゼロ汚染: インターネットからコードを収集するのではなく、手動翻訳を採用したため、モデルが既存データから暗記している可能性を排除し、真の汎化能力を測定できます。
  • 構成: 合計 248 件の高品質サンプル（HumanEval 164 件、ClassEval 84 件）で構成され、難易度やタスクの多様性をカバーしています。
  • タスク: 「テキストからコード生成（Text-to-Code）」と「コードからコード翻訳（Code-to-Code）」の 2 つのタスクを定義しました。
• 評価フレームワーク:
  • Docker 環境内で Cangjie ランタイムを isolated 実行し、生成されたコードのコンパイル可否とテストケースの通過率を自動評価するサンドボックスを構築しました。

3. 評価手法（4 つのパラダイム）

パラメータ更新（ファインチューニング）を行わず、既存の LLM がどのように新しい言語を習得できるかを検証するため、以下の 4 つの手法を比較評価しました。

1. 直接生成（Direct Generation）: 自然言語の説明や Python ソースコードのみをプロンプトに与え、ゼロショットで生成させる。
2. 構文制約付き生成（Syntax-Constrained Generation）: 専門家が作成した簡潔な Cangjie の文法ルールをプロンプトに注入し、コンテキスト学習（In-Context Learning）を支援する。
3. 検索拡張生成（RAG）: 公式ドキュメントや収集した Cangjie コードスニペットを検索し、コンテキストとして提供する方法（ドキュメント検索とコード検索の 2 種類）。
4. エージェント（Agent）: CLI ベースのエージェントが、必要に応じてドキュメントを自主的に検索・学習し、自己修正や反復的な開発プロセスをシミュレートする。

4. 主要な実験結果

複数の SOTA モデル（GPT-5, DeepSeek-V3, Kimi-K2, Qwen3 など）を用いた評価により、以下の知見が得られました。

• 直接生成の限界: 支援なしの直接生成では、ほとんどのモデルの Pass@1（1 回で正解する確率）は 5% 未満であり、コンパイルエラーが多発しました。これはモデルが Cange の構文を全く知らないことを示しています。
• 構文制約の優位性: 文法ルールを注入する「構文制約付き生成」は、コストと精度のバランスが最も優れていました。例えば GPT-5 は、この手法により平均 Pass@1 が 4.3% から 53.8% へと劇的に向上しました。LLM はアルゴリズム的ロジックは既に習得しており、ボトルネックは表面の構文知識であることを示唆しています。
• エージェントの性能とコスト: エージェント手法（特に GPT-5 駆動の Codex CLI）は、Pass@1 77.6% という最高精度を達成しましたが、トークン消費量が膨大（数十万トークン）であり、実用的なコストパフォーマンスは低かったです。
• RAG の限界: 低リソース言語において、断片的なコードやドキュメントを検索しても、構文の複雑さをゼロショットで一般化するのは難しく、構文制約法には劣る結果となりました。
• 負の転移（Negative Transfer）の発見: 驚くべきことに、「コードからコード翻訳（Python → Cangjie）」タスクは、「テキストからコード生成」タスクよりも性能が低下する傾向がありました。モデルがソース言語（Python）の動的なパターンに過剰適合し、Cangjie の静的な構文を正しく変換できなくなる「負の転移」現象が観測されました。

5. 主要な貢献

1. CANGJIEBENCH の提案: 初となる Cangjie 向けの高品質ベンチマーク。手動翻訳によるゼロ汚染と、関数・クラスレベルの多様なタスクをカバー。
2. 低リソース汎用言語という新たな視点: DSL ではなく汎用言語を対象とし、ドメイン知識の干渉なしに LLM の構文学習能力を厳密に評価する枠組みの確立。
3. 実用的なタスクの定義: 実際の産業ニーズ（HarmonyOS への移行など）を反映した「生成」と「翻訳」の 2 タスクの導入。
4. 包括的な手法評価: 構文制約、RAG、エージェントなど 4 つの戦略を比較し、低リソース言語への適応において「構文制約付き生成」がコスト対効果の面で最も有効であることを実証。

6. 意義と将来展望

本研究は、新しいプログラミング言語が登場する際、大規模なデータ収集やファインチューニングが不可能な状況でも、高品質な文脈（構文ルールなど）を提供することで LLM を即座に適応させることができることを示しました。

• 実用性: 開発者は、新しい言語の文法ルールをプロンプトに含めるだけで、既存の LLM を活用してコード生成が可能になるため、開発コストを大幅に削減できます。
• 研究の方向性: 「ソースコードからの翻訳」が必ずしも有効ではないという発見は、意味に焦点を当てた中間表現を介した翻訳手法の重要性を提起しています。また、単純なタスクには構文制約を、複雑なタスクにはエージェントを動的に使い分けるハイブリッドなアプローチが将来の方向性として示唆されています。

CANGJIEBENCH は、低リソース言語における LLM の汎化能力と適応戦略を研究するための重要な基盤となり、今後のソフトウェア工学における AI 活用を推進するものと考えられます。