Transparency in Software Defect Prediction: A Dual Approach using Explainability and Tradeoff Analysis

あなたは、1,000人の無実の市民の中に紛れ込んだたった一人の隠れた裏切り者を見つけ出そうとしている探偵だと想像してください。あなたの仕事は、トラブルを引き起こす前にその裏切り者を特定することです。これは、ソフトウェアエンジニアが「バグ」や欠陥と呼ばれるコンピュータコードを追跡するデジタル探偵として、日常的に行っている業務です。ソフトウェアエンジニアリングの世界では、この追跡劇は**ソフトウェア欠陥予測（Software Defect Prediction）**と呼ばれます。これは、システムが壊れる前に悪いコードを見つけ出すことを目的とした、非常に重要なゲームです。

このゲームをプレイするために、エンジニアは**機械学習モデル（Machine Learning models）**と呼ばれるコンピュータプログラムを使用します。これらのモデルを、過去に何百万行ものコードを読み込んできた超スマートな助手だと考えてください。モデルは新しいコードに目を通し、0から1までの「疑わしさスコア」を算出します。スコアが0なら「完全に無実」、1なら「有罪確定」を意味します。難しいのは、どこに境界線を引くかを決めることです。もし線を低く設定しすぎると、無実の人々を疑ってしまい（誤検知）、全員の時間を無駄にしてしまいます。もし線を高く設定しすぎると、本物の裏切り者を見逃してしまい（欠陥の見逃し）、それは破滅的な事態を招きかねません。長い間、ほとんどの探偵は「スコアが0.5を超えたら有罪」という標準的なルールを使用してきました。しかし、この新しい研究が示唆しているように、その標準的なルールは的を外している可能性があります。

---

この論文の核心：完璧な線を見つけること

論文「透明性のあるソフトウェア欠陥予測：説明可能性とトレードオフ分析を用いた二重のアプローチ（Transparency in Software Def defect Prediction: A Dual Approach using Explainability and Tradeoff Analysis）」において、Nitin Sai Bommi、Umamaheswara Sharma Bhutamapuram、および Atul Negi は、従来の「0.5ルール」は、頭のサイズが全く異なる人々の群衆に対して、ワンサイズ（共通サイズ）の帽子を使っているようなものだと主張しています。それでは、誰にもフィットしません。

著者たちは、このゲームをプレイするための新しい方法を提案しています。デフォルトの線を盲目的に信じる代わりに、彼らはそれぞれの特定の状況に対して「完璧な線」を見つけ出すための2つの巧妙なトリックを提案しています。彼らの目標は、悪党を捕まえること（検出確率）と、誤った告発を避けること（誤報確率）の差を最大化することです。彼らは、無実の傍観者に時間を浪費させることなく、裏切り者を捕まえたいと考えています。

トリック #1：動くゴールポスト（最適閾値）

最初のトリックは、「疑いの線」を調整することです。研究者たちは、3種類の異なる探偵助手（ロジスティック回帰、ナイーブベイズ、ニューラルネットワーク）をテストしました。彼らは、どのモデルにおいても、魔法の数字は0.5ではないことを発見しました。

• ロジスティック回帰の助人の場合、スイートスポットは約0.35でした。
• ナイーブベイズでは、さらに低く0.3でした。
• ニューラルネットワークでは、0.38でした。

これは、ラジオのチューニングを考えるようなものです。ダイヤルを真ん中に置いたままでは、ノイズが聞こえるかもしれません。しかし、ダイヤルを少し左や右に動かすと、突然音楽がクリアに聞こえてきます。閾値を（0.3や0.4付近に）下げることで、これらのモデルは、誤報の数を低く抑えつつ、本物の欠陥を見つける能力が大幅に向上しました。36の異なるバージョンを持つ10のソフトウェアプロジェクトに対して行ったテストにおいて、このシンプルな調整は、標準的な手法を一貫して上回る成果を出しました。

トリック #2：「もしも」ゲーム（反事実的説明）

2番目のトリックは、もう少し魔法に近いものです。著者たちは**反事実的説明（Counterfactual Explanations）**と呼ばれるものを使用しました。あなたが「有罪」の容疑者（欠陥のあるコードモジュール）の写真を持っていると想像してください。モデルは「これは悪い」と言っています。ここで、あなたがモデルに対して「もし私がこの一点を少し変えたら、どうなりますか？ それは無実になりますか？」と尋ねることができたと想像してください。

研究者たちはまさにそれを行いました。彼らは、モデルがすでに「良い」または「悪い」と判断しているコードを取り出し、「何をどのように変えれば、これが『良』から『悪』へ、あるいは『悪』から『良』へと反転するか？」と問いかけました。彼らはこれらの「もしも」のシナリオを用いて、新しい合成コードの例を作成しました。そして、これらの新しい例をモデルに再び投入し、モデルに追加のトレーニングを行いました。

これは、コーチが選手に完璧なプレーのビデオを見せ、「もしボールを数センチ外していたらどうなっていたか？」と問いかけ、それを使ってプレイヤーがどのように調整すべきかを教えるようなものです。論文では、この手法がモデルのデータ理解を深めるのに役立つことが示されましたが、必ずしも「動くゴールポスト」のトリックを常に上回るわけではありませんでした。

彼らが発見したこと（および発見できなかったこと）

結果は有望でしたが、限定的でもありました。著者たちは、主に2つのツールを使用して成功を測定しました。

1. 欠落率（False Omission Rate: FOR）: 本物の欠陥をどれくらいの頻度で見逃したか？（これを低くしたい）。
2. 節約された予算の割合（Percent of Saved Budget: PSB）: クリーンなコードのテストを行わないことで、どれだけの時間と費用を節約できたか？

新しい「動くゴールポスト」法を使用したとき、モデルは従来の方法よりも優れたパフォーマンスを示しました。例えば、ロジスティック回帰モデルの場合、平均的な最適閾値は0.35であり、標準的な0.5の閾値と比較して、欠陥の見逃し率を大幅に減少させました。

しかし、著者たちはこれを「魔法の杖」とは呼んでいません。彼らは、これらの手法が「欠陥を捕まえること」と「誤報を避けること」のバランスを改善するものの、すべてを解決するわけではないと明言しています。反事実的説明（「もしも」ゲーム）は役に立ちましたが、モデル自体がそもそも完璧な合成例を生成できるわけではないため、必ずしも最高の結果をもたらすわけではありませんでした。

また、彼らは、自分たちの知見が特定のデータセット（PROMISEリポジトリ）に基づいていることを指摘しており、全く異なるタイプのソフトウェアプロジェクトに適用された場合には、結果が変わる可能性があることも述べています。彼らは、これが宇宙のあらゆるソフトウェアに対して機能することを証明したわけではありませんが、テストしたプロジェクトにおいては、デフォルトの0.5ルールから離れることが賢明な判断であることを示しました。

なぜこれが重要なのか

この論文は、ソフトウェアの世界において「ワンサイズ・フィッツ・オール（一律の対応）」がしばしば罠になることを思い出させてくれます。何がバグで何がそうでないかを判断する標準的な方法は、あまりにも硬直している可能性があります。「この特定の仕事に対して、最適な線はどこか？」とコンピュータに問いかけ、さらに「もしも」の質問を使ってより深く学ぶことで、私たちはより安全で、メンテナンスコストの低いソフトウェアを構築することができます。これは視点の小さな転換ですが、デジタルの暗闇の中でバグを追う探偵たちにとって、それはまさに彼らが必要としていた懐中電灯となるかもしれません。