以下は、提示された論文「InEx-Bug: A Human Annotated Dataset of Intrinsic and Extrinsic Bugs in the NPM Ecosystem」に基づく技術的な要約です。

論文概要：InEx-Bug

タイトル: InEx-Bug: NPM エコシステムにおける内在的・外在的バグの人間による注釈付きデータセット
著者: Tanner Wright, Adams Chen, Gema Rodríguez-Pérez (University of British Columbia)
発表: MSR '26 (Mining Software Repositories 2026)

1. 背景と課題 (Problem)

現代のソフトウェア開発は、サードパーティのパッケージやライブラリに依存する動的なエコシステム（特に NPM）に支えられています。しかし、この依存関係構造には以下の重大な課題が存在します。

• バグの起源の混同: 既存のバグデータセットは、プロジェクト内部のコード欠陥（内在的バグ: Intrinsic Bugs）と、依存関係の更新や環境要因による外部起因の問題（外在的バグ: Extrinsic Bugs）を区別していません。
• メンテナンスの困難さ: 報告された問題が自社のコードにあるのか、外部要因によるものかを特定することは困難ですが、修正に必要なコード変更の規模や対応方針が両者で大きく異なるため、区別は不可欠です。
• ラベルの誤り: 既存の研究では、バグトラッキングシステム内の約 33.8%〜40% の報告が「誤ったラベル」（実際はバグではないもの、機能リクエスト、ユーザーエラーなど）であることが示されています。
• 既存データセットの限界: 内在的・外在的バグを区別したデータセットは過去に存在しましたが（OpenStack のコミットレベルデータに限定）、多様な NPM エコシステムにおける「イシュー（Issue）レベル」での分析は不足していました。

2. 手法とデータセット構築 (Methodology)

本研究では、NPM エコシステムにおけるバグの起源を人間が手動で注釈したデータセット「InEx-Bug」を構築しました。

• データ収集とサンプリング:
  • 元データ: 依存度が高い NPM パッケージ 500 件から収集された約 30,000 件の GitHub イシューとプルリクエスト（PR）。
  • フィルタリング: PR を除外し、バグ報告に焦点を当てた 23,682 件のイシューから、95% 信頼区間、誤差範囲±5% で母集団を推定できる377 件を無作為に抽出。
  • 対象リポジトリ: 103 件の NPM リポジトリ。
• メタデータ抽出:
  • GitHub REST API v3 を使用し、2025 年 10 月に収集。
  • 収集項目: タイトル、本文、状態、タイムスタンプ、ラベル、アサイン、マイルストーン、コメント、タイムラインイベント（クローズ、再オープン、参照など）、PR/コミット情報（コード変更量、レビューアなど）。
  • クローズ判定: PR やコミットによるクローズを特定するため、イシュー作成から 7 日以内のマージ/コミットを「コードベースの修正」として検出する戦略を採用。
• 手動注釈プロセス:
  • 分類カテゴリ: 以下の 4 分類に手動でラベル付けを行いました。
    1. Intrinsic (内在的): パッケージ内部のコード欠陥（リグレッション、ロジックエラーなど）。
    2. Extrinsic (外在的): 依存関係のアップグレード、OS 差異、ブラウザ仕様など外部要因による問題（プロジェクト内のコードは以前は正常だった）。
    3. Not-a-Bug: 実際の欠陥ではないもの（ドキュメント、機能リクエスト、設定ミス、誤ったリポジトリへの報告など）。
    4. Unknown: 原因を特定する情報が不足しているもの。
  • 信頼性: 2 名の注釈者が 5 回の反復ラウンドで 161 件を共同ラベル付けし、合意形成を行いました（Cohen's kappa > 0.80）。残りの 216 件は独立してラベル付けされ、第三者による検証も実施されました。

3. 主要な結果 (Key Results)

377 件のイシューを分析した結果、以下の統計的傾向が明らかになりました。

• 分布:

  • Not-a-Bug: 58.9% (222 件) - 最も多い。
  • Intrinsic: 27.9% (105 件)。
  • Extrinsic: 9.8% (37 件)。
  • Unknown: 3.4% (13 件)。
  • 実際のバグ報告（Intrinsic + Extrinsic）において、内在的バグは外在的バグの約 3 倍の割合を占めました。

• 解決時間とクローズ率:

  • 解決速度: 内在的バグの方が外在的バグよりも速く解決されます（中央値：8.9 日 vs 10.2 日）。
  • クローズ率: 内在的バグは 92.4%、外在的バグは 78.4% と、内在的バグの方が高いクローズ率を示しました。
  • Not-a-Bug: 非常に速く解決され（中央値 0.7 日）、93.2% がクローズされました。

• 再オープン (Reopen) 傾向:

  • 外在的バグは再オープン率が有意に高く（11.8% vs 内在的 3.8%）、再オープンまでの遅延も長いです（中央値：157 日 vs 内在的 87 日）。これは依存関係の問題が時間を経て再発しやすいことを示唆しています。

• コード変更の規模:

  • Intrinsic: クローズされたイシューの 56.7% がコード変更を伴い、平均 369 行（中央値 51 行）、4.6 ファイルにまたがって変更されました。
  • Extrinsic: クローズされたイシューの 28.1% のみでコード変更を伴い、変更量は非常に少なかった（平均 34 行、中央値 11 行、3.2 ファイル）。これは外在的問題が「適応」や「設定変更」で済む場合が多いことを示しています。

• メンテナーの関与:

  • 内在的・外在的バグともにメンテナーの反応率は高く（それぞれ 86.7%、89.2%）、議論の深さも同程度でした。

4. 貢献と意義 (Contributions & Significance)

• 初のイシューレベルの注釈データセット: コミットレベルではなく、GitHub イシュー（問題報告）の段階で、内在的・外在的バグを区別した人間による注釈付きデータセットを初めて提供しました。
• 豊富なメタデータ: ラベルだけでなく、時間的メトリクス、メンテナーの参加状況、コード変更の特性など、エコシステムの維持管理ダイナミクスを分析するための多角的なメタデータを統合しています。
• 実用的なインサイト:
  • ツール開発: バグの自動分類ツールや依存関係リスク分析ツールの開発・評価に利用可能。
  • コミュニティ改善: 「Not-a-Bug」が半数以上を占める事実から、より良いイシューテンプレートや自動診断ツールの必要性が示唆されました。
  • メンテナー支援: 内在的・外在的バグのライフサイクルの違いを理解することで、メンテナーの意思決定やリソース配分を最適化する指針となります。

5. 結論

InEx-Bug は、NPM エコシステムにおけるバグの起源（内部 vs 外部）とその維持管理プロセスを定量的に理解するための基盤となるデータセットです。このデータセットは、ソフトウェア工学における実証研究、特に大規模な依存関係を持つシステムにおけるバグの発生、伝播、管理メカニズムの解明に重要な貢献を果たすことが期待されます。