論文「Toward Linking Declined Proposals and Source Code: An Exploratory Study on the Go Repository」の技術的サマリー

本論文は、オープンソースソフトウェア（OSS）開発において、却下された提案（Declined Proposals）とソースコードの間にトレーサビリティリンクを確立するという新たな課題に焦点を当て、大規模言語モデル（LLM）を活用したアプローチを提案・検証した研究です。Go 言語の公式リポジトリを対象とした実証研究を通じて、却下された提案から設計の根拠や意思決定の基準をソースコードに紐付ける手法の有効性と課題を明らかにしています。

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

---

1. 問題定義 (Problem)

ソフトウェア開発におけるトレーサビリティ（要件、設計、実装間のリンク）は、バグ特定やコード理解に不可欠です。しかし、既存の研究の多くは**採用された提案（Accepted Proposals）に焦点を当てており、議論の末に却下された提案（Declined Proposals）**は軽視されてきました。

• 現状の課題:
  • 却下された提案には、採用されなかった設計案、失敗した意思決定、トレードオフの理由など、将来の開発者や維持者にとって貴重な知識（設計根拠）が含まれている。
  • しかし、実装されなかったため、これらの議論はコードベースに直接反映されず、開発者がコードを参照する際に却下された議論へのアクセスが困難である。
  • 著者の先行研究では、却下された提案の約 14.7% が後に再提出されていることが示されており、過去の却下議論へのトレーサビリティは重要である。
• 研究目的:
  • 却下された提案と関連するソースコード（ディレクトリ、ファイル、関数レベル）の間に自動でトレーサビリティリンクを生成する手法を開発し、その有効性を検証する。

2. 手法 (Methodology)

Go 言語の公式リポジトリ（GitHub Issues）から収集された却下提案をデータセットとして、LLM 駆動のパイプラインを設計しました。このパイプラインは、従来の情報検索（IR）ベースの手法や RAG（Retrieval-Augmented Generation）ベースの手法を改良し、却下提案の特性（実装コードが存在しない）に適合させています。

提案された LLM 駆動パイプライン

図 2 に示されるように、3 つのフェーズ（0, 1, 2）で構成されます。

1. フェーズ 0: 粒度決定 (Granularity Decision)
   • 各提案がどのレベル（ディレクトリ、ファイル、関数）のコード変更を意図しているかを LLM が判断します。
   • 粒度の定義:
     • ディレクトリレベル: ファイル/ディレクトリの追加、削除、移動など。
     • ファイルレベル: 既存ファイル内での関数追加など（ファイル構造変更なし）。
     • 関数レベル: 既存関数内のロジック変更のみ。
2. フェーズ 1: 局所化 (Localization)
   • 決定された粒度に基づき、関連するコードを特定します。
   • Agentless 手法の応用: LLM のコンテキストウィンドウ制限を回避するため、リポジトリ構造を階層的に処理します。
     • ディレクトリ局所化: リポジトリツリー構造と提案テキストから関連ディレクトリを特定。
     • ファイル局所化: 特定ディレクトリ内の関連ファイルを特定。
     • 関数局所化: 特定ファイル内の関数シグネチャのみを抽出し、関連関数を特定。
   • 従来の埋め込み（Embedding）ベースの類似度検索ではなく、LLM の文脈推論能力を活用して、提案で議論されているが実装されていないコードを文脈から推測します。
3. フェーズ 2: リンク判定 (Link Decision)
   • 局所化されたコード要素と提案のペアに対して、LLM が「関連があるか（Yes/No）」を二値分類します。
   • 任意の類似度閾値に依存せず、LLM の判断に基づいて最終的なリンクを生成します。

実験設定

• データセット: Go 公式リポジトリの却下提案 341 件（検証用 40 件、評価用 300 件程度）。
• モデル: DeepSeek-V3.1（温度 0.0）。
• 評価指標: 粒度選択の精度（Granularity Accuracy）、リンク生成の適合率（Precision）。
• ベースライン: 採用提案に対する既存の RAG ベース手法（LiSSA）との比較。

3. 主要な貢献 (Key Contributions)

1. 新規タスクの提案:
   • 却下された提案とソースコードの間にトレーサビリティリンクを確立する初の研究です。これにより、実装されていない議論から得られる設計知識をコードベースから直接アクセス可能にします。
2. LLM 駆動アプローチの設計と評価:
   • 粒度を考慮した LLM パイプラインを設計し、Go リポジトリで実証しました。
   • 従来の埋め込みベースの局所化よりも、LLM を用いた文脈理解に基づく局所化の方が優れていることを示しました。
3. 失敗分析と課題の特定:
   • パイプラインが失敗するケースを詳細に分析し、議論の「具体性の欠如」や「冗長性」が主要な要因であることを明らかにしました。

4. 結果 (Results)

性能評価 (RQ1)

• 粒度選択の精度: 提案されたパイプラインは、適切なコード粒度（ディレクトリ/ファイル/関数）を 83.6% の精度で選択できました。
  • ファイルレベルで最も高く（88.7%）、関数レベルで低かった（40.7%）。
• リンク生成の適合率: 選択された粒度において、正しいリンクを生成する適合率は平均 64.3% でした。
  • ファイルレベル：68.8%
  • ディレクトリレベル：52.9%
  • 関数レベル：25.3%（粒度選択の失敗が主な要因）
• ベースラインとの比較: 採用提案に対する既存の RAG ベース手法と比較し、提案されたパイプラインは全ケースで F1 スコアが向上し、22 件中 21 件で適合率が向上しました。

失敗分析 (RQ2)

パイプラインがリンク生成に失敗する主な要因は以下の通りです。

1. 粒度誤分類の原因:
   • 実装ガイドの不足 (42.9%): 「何を実装するか」は述べられているが、「どこで・どのように」実装するかという具体的な情報が欠けている場合。
   • 矛盾する提案: 複数の矛盾する実装方法が提示されている。
   • 隠れた情報: 重要な手がかりが長い議論の中に埋もれている。
2. リンク精度への影響:
   • 粒度が正しく選択された場合でも、議論内でターゲットコードへの言及が明示的（Level-1）か、間接的（Level-2）か、暗黙的（Level-3）かによって精度が異なります。
   • 明示的な言及がある場合、適合率は 84% 以上ですが、暗黙的な場合（Level-3）は 40% 程度まで低下します。
   • 議論の長さは性能に有意な影響を与えませんでした。

5. 意義と将来展望 (Significance & Future Work)

• 知識の保存と活用: 却下された提案に含まれる「なぜそれが採用されなかったか」という設計根拠をソースコードにリンクすることで、将来的な開発者が同じ過ちを繰り返すのを防ぎ、意思決定の文脈を維持できます。
• LLM の可能性: 実装コードが存在しない状況でも、LLM は議論の文脈からコードの意図を推論し、適切な粒度でリンクを生成できることを示しました。
• 今後の課題:
  • 情報の補完: 議論に実装詳細が不足している場合、関連する他の提案やコードコメントなどの外部コンテキストを補完する技術の検討。
  • 要約による入力最適化: 冗長な議論から重要なリンク情報を抽出・要約し、LLM の入力品質を向上させる技術の検討。

本論文は、OSS 開発プロセスにおける「失敗（却下）」から価値ある知識を抽出し、それをコードベースと統合するための新たな視点と技術的基盤を提供する重要な研究です。