StRuCom: A Novel Dataset of Structured Code Comments in Russian

生成日: 2026-05-24 02:20

# StRuCom: A Novel Dataset of Structured Code Comments in Russian
- ロシア語の構造化コードコメント生成に向け、153,181 件のコード・コメント対からなる StRuCom を作成した。
- 対象は Python、Java、JavaScript、C#、Go の 5 言語で、各言語の実務上の文書化形式に合わせてコメントを検査している。
- Qwen2.5-Coder をこのデータで微調整すると、多くの設定で BERTScore と人手代替評価が改善した。

## 論文の面白いところ

この論文は、コードコメント生成を英語中心の課題として扱わない点に価値がある。既存の大規模コードデータセットには多言語コードが含まれていても、自然言語としてのコメントは英語に偏りやすい。ロシア語のコメントを単に英語から機械翻訳すると、技術用語の借用語、直訳、文書化形式のタグが崩れることがある。著者らはその問題を、ロシア語 GitHub リポジトリからの収集、構造の検査、Large Language Model（LLM）による補完を組み合わせて扱った。とくに、コメントが「ある」だけではなく、引数、返り値、例外などが各言語の形式に沿って書かれているかを見ている点が実務に近い。Python の GoogleDoc、JavaScript の JSDoc、Java の JavaDoc、C# の XML コメント、Go の GoDoc を同じ目的のもとで扱うため、単純なコード要約よりも細かい整形と検査が必要になる。実データだけでは十分でない部分を合成データで補うが、その際にも完全な構造化コメントとして検査する。小規模なコードモデルでも改善が見えるため、局所的な言語資源を整えることの効果が読み取りやすい論文である。

## 問題設定

対象は、関数に対してロシア語の構造化コメントを生成する課題である。構造化コメントとは、短い説明だけでなく、引数、返り値、例外、必要に応じた型情報を、各プログラミング言語で慣用的な形式に従って書いたコメントを指す。英語では CodeSearchNet や The Vault などの資源があるが、これらは検索や短い説明に寄ったものが多く、ロシア語の docstring 生成にそのまま使いにくい。MCoNaLa にはロシア語の例もあるが、規模は 345 件で、関数単位の詳細な文書化を学習するには小さい。ロシア語話者がローカルなプロジェクトで保守しやすいコードを書くには、母語で正しく整ったコメントを作る支援が必要になる。問題は自然言語だけでなく、コメント形式の問題でもある。Python と JavaScript では型やタグの扱いが難しく、Go では形式が簡素であるなど、言語ごとに検査すべき条件が異なる。したがって本研究は、ロシア語のコードコメント本文と、言語ごとの構造規則を同時に扱うデータセット構築の課題として位置づけられる。

## 提案手法

著者らは StRuCom というデータセットと、そのための抽出・検査手順を提案している。まず、Python、Java、JavaScript、C#、Go のロシア語 GitHub リポジトリを集め、関数と既存コメントを抽出する。リポジトリの自然言語を GitHub API だけで直接得ることはできないため、ロシア語の説明をもつリポジトリや許容的なライセンスを手がかりに収集している。コメントの言語判定には Lingua を用い、短いコメントやコード由来の記号が混じる場合にもロシア語を判定しやすくしている。次に、各言語のコメントを標準形式へ寄せ、docstring_parser、javalang、Code-Text などで構造を検査する。最終データには、構造化され、かつ必要な要素の説明を備えた完全なコメントだけを入れる。実コメントだけでは数が足りないため、Miqu-70B で既存コメントを改善し、Qwen2.5-Coder-32B-Instruct でコメントのない関数に対するコメントも生成した。最終的な 153,181 件は、改善されたコメント 79,548 件、ゼロから生成されたコメント 65,914 件、実コメント 7,719 件からなる。

## 結果

データセットは 5 言語を含み、Python 25,062 件、Java 29,438 件、Go 27,849 件、C# 49,767 件、JavaScript 21,091 件で構成される。元の GitHub データを見ると、完全な構造化コメントの割合は言語によって大きく異なった。Go は形式が簡素なためロシア語コメント中の 56.4% が完全と判定されたが、Python は 1.5%、JavaScript は 1.4% にとどまった。LLM による改善でも同様の傾向があり、Go と C# では改善が通りやすく、Python と JavaScript では型やタグをそろえる難しさが残った。評価では、Qwen2.5-Coder の 0.5B、1.5B、3B、7B を、合成部分から抽出した 7,500 件で 5 エポック微調整した。実コメントから抽出した 500 件のテスト集合で見ると、BERTScore は全サイズ、多くの言語で基礎モデルより高くなった。たとえば Qwen2.5-Coder 3B は、Java で 0.829 から 0.881、C# で 0.817 から 0.859 に上がっている。chrF++ も多くの設定で上がるが、著者らは意味的な近さを示す BERTScore の改善のほうが安定していると見る。GPT-4o-mini を判定器にした GitHub Copilot との比較でも、微調整後のモデルは、とくに小型モデルで勝ちが増えた。

## 具体例

たとえば Java の関数 `codeToOneLine` があり、`MainS.java` を読み込み、行ごとに正規表現で対象部分を取り出し、文字列 `MainS` を `MainS2` に置換し、行コメントやタブを消して 1 行の文字列として返すとする。入力として手法に与えられるのは、この関数本体と、既にある不完全なロシア語コメントである。不完全なコメントには「ファイルからコードを読み込む」とだけ書かれ、引数 `linePattern` や `lineM` の説明が空で、返り値の意味も説明されていないかもしれない。StRuCom の改善手順では、LLM が関数本体を読み、既存コメントを補いながら JavaDoc 形式のコメントを作る。期待される出力は、関数の目的、各引数の役割、返される文字列の内容、入出力エラー時の `IOException` を、ロシア語でそろえた構造化コメントである。この例で間違えやすいのは、引数 `s` を「ファイルから得られた結果」と説明してしまうことである。実際には `s` は読み込み中の行を受ける作業用の文字列であり、最終的な返り値は別に組み立てられる。もう一つの誤りは、`MainS` から `MainS2` への置換や、`//` コメントの削除を見落とすことである。論文の狙いは、このような細部を、ロシア語の自然な説明と各言語の文書化形式の両方で満たす学習データを作ることにある。

StRuCom: A Novel Dataset of Structured Code Comments in Russian

ロシア語の構造化コードコメント生成に向け、153,181 件のコード・コメント対からなる StRuCom を作成した。
対象は Python、Java、JavaScript、C#、Go の 5 言語で、各言語の実務上の文書化形式に合わせてコメントを検査している。
Qwen2.5-Coder をこのデータで微調整すると、多くの設定で BERTScore と人手代替評価が改善した。

論文の面白いところ

この論文は、コードコメント生成を英語中心の課題として扱わない点に価値がある。既存の大規模コードデータセットには多言語コードが含まれていても、自然言語としてのコメントは英語に偏りやすい。ロシア語のコメントを単に英語から機械翻訳すると、技術用語の借用語、直訳、文書化形式のタグが崩れることがある。著者らはその問題を、ロシア語 GitHub リポジトリからの収集、構造の検査、Large Language Model（LLM）による補完を組み合わせて扱った。とくに、コメントが「ある」だけではなく、引数、返り値、例外などが各言語の形式に沿って書かれているかを見ている点が実務に近い。Python の GoogleDoc、JavaScript の JSDoc、Java の JavaDoc、C# の XML コメント、Go の GoDoc を同じ目的のもとで扱うため、単純なコード要約よりも細かい整形と検査が必要になる。実データだけでは十分でない部分を合成データで補うが、その際にも完全な構造化コメントとして検査する。小規模なコードモデルでも改善が見えるため、局所的な言語資源を整えることの効果が読み取りやすい論文である。

問題設定

対象は、関数に対してロシア語の構造化コメントを生成する課題である。構造化コメントとは、短い説明だけでなく、引数、返り値、例外、必要に応じた型情報を、各プログラミング言語で慣用的な形式に従って書いたコメントを指す。英語では CodeSearchNet や The Vault などの資源があるが、これらは検索や短い説明に寄ったものが多く、ロシア語の docstring 生成にそのまま使いにくい。MCoNaLa にはロシア語の例もあるが、規模は 345 件で、関数単位の詳細な文書化を学習するには小さい。ロシア語話者がローカルなプロジェクトで保守しやすいコードを書くには、母語で正しく整ったコメントを作る支援が必要になる。問題は自然言語だけでなく、コメント形式の問題でもある。Python と JavaScript では型やタグの扱いが難しく、Go では形式が簡素であるなど、言語ごとに検査すべき条件が異なる。したがって本研究は、ロシア語のコードコメント本文と、言語ごとの構造規則を同時に扱うデータセット構築の課題として位置づけられる。

提案手法

著者らは StRuCom というデータセットと、そのための抽出・検査手順を提案している。まず、Python、Java、JavaScript、C#、Go のロシア語 GitHub リポジトリを集め、関数と既存コメントを抽出する。リポジトリの自然言語を GitHub API だけで直接得ることはできないため、ロシア語の説明をもつリポジトリや許容的なライセンスを手がかりに収集している。コメントの言語判定には Lingua を用い、短いコメントやコード由来の記号が混じる場合にもロシア語を判定しやすくしている。次に、各言語のコメントを標準形式へ寄せ、docstring_parser、javalang、Code-Text などで構造を検査する。最終データには、構造化され、かつ必要な要素の説明を備えた完全なコメントだけを入れる。実コメントだけでは数が足りないため、Miqu-70B で既存コメントを改善し、Qwen2.5-Coder-32B-Instruct でコメントのない関数に対するコメントも生成した。最終的な 153,181 件は、改善されたコメント 79,548 件、ゼロから生成されたコメント 65,914 件、実コメント 7,719 件からなる。

結果

データセットは 5 言語を含み、Python 25,062 件、Java 29,438 件、Go 27,849 件、C# 49,767 件、JavaScript 21,091 件で構成される。元の GitHub データを見ると、完全な構造化コメントの割合は言語によって大きく異なった。Go は形式が簡素なためロシア語コメント中の 56.4% が完全と判定されたが、Python は 1.5%、JavaScript は 1.4% にとどまった。LLM による改善でも同様の傾向があり、Go と C# では改善が通りやすく、Python と JavaScript では型やタグをそろえる難しさが残った。評価では、Qwen2.5-Coder の 0.5B、1.5B、3B、7B を、合成部分から抽出した 7,500 件で 5 エポック微調整した。実コメントから抽出した 500 件のテスト集合で見ると、BERTScore は全サイズ、多くの言語で基礎モデルより高くなった。たとえば Qwen2.5-Coder 3B は、Java で 0.829 から 0.881、C# で 0.817 から 0.859 に上がっている。chrF++ も多くの設定で上がるが、著者らは意味的な近さを示す BERTScore の改善のほうが安定していると見る。GPT-4o-mini を判定器にした GitHub Copilot との比較でも、微調整後のモデルは、とくに小型モデルで勝ちが増えた。

具体例

たとえば Java の関数 codeToOneLine があり、MainS.java を読み込み、行ごとに正規表現で対象部分を取り出し、文字列 MainS を MainS2 に置換し、行コメントやタブを消して 1 行の文字列として返すとする。入力として手法に与えられるのは、この関数本体と、既にある不完全なロシア語コメントである。不完全なコメントには「ファイルからコードを読み込む」とだけ書かれ、引数 linePattern や lineM の説明が空で、返り値の意味も説明されていないかもしれない。StRuCom の改善手順では、LLM が関数本体を読み、既存コメントを補いながら JavaDoc 形式のコメントを作る。期待される出力は、関数の目的、各引数の役割、返される文字列の内容、入出力エラー時の IOException を、ロシア語でそろえた構造化コメントである。この例で間違えやすいのは、引数 s を「ファイルから得られた結果」と説明してしまうことである。実際には s は読み込み中の行を受ける作業用の文字列であり、最終的な返り値は別に組み立てられる。もう一つの誤りは、MainS から MainS2 への置換や、// コメントの削除を見落とすことである。論文の狙いは、このような細部を、ロシア語の自然な説明と各言語の文書化形式の両方で満たす学習データを作ることにある。