Bohrbug：その概要、原因、および修正方法

Bohrbugとは？

Bohrbugとは、決定論的に現れるソフトウェアエラーの一種です。同じ入力データに対して、常に同じ障害を引き起こします。この用語は、研究者のジム・グレイとアンドレアス・ロイターが著書『Transaction Processing: Concepts and Techniques』（1993年）で学術的に導入しました。

動作がカオス的に変化するMandelbugとは異なり、Bohrbugは安定しています。開発者はシステムに同じパラメータを与えることで、目をつぶっても再現できます。そのため、IDEでのステップバイステップのデバッグに最適です。

Bohrbugはソフトウェアのライフサイクル全般（開発から運用まで）で発生します。多くの場合、QAエンジニアが繰り返しシナリオを実行して障害を確実に誘発するテスト段階で発見されます。

グレイとロイターによる定義

グレイとロイターの分類によると、Bohrbugは3つの条件を満たす欠陥です：固定された入力データセット、同じシステム状態、同じ障害結果。少なくとも1つの条件が満たされない場合、そのバグはもはや「ボーア的」ではありません。

著者らは、Bohrbugが必ずしも単純なエラーではないことを強調しています。論理的には任意に複雑になり得ますが、その決定論性によって分類上の他のすべての障害タイプと区別されます。

Bohrbugという名称の由来

Bohrbugという名称は、惑星原子モデルの創始者であるデンマークの物理学者ニールス・ボーアに由来します。類推は単純です：ボーアモデルの電子が厳密に固定された軌道を動くように、このバグは実行のたびに同じ動作を繰り返します。

グレイとロイターは、決定論的エラーを混沌としたエラーと対比させるためにこの名称を選びました。混沌としたエラーは、フラクタル理論とカオス理論の創始者である数学者ブノワ・マンデルブロにちなんでMandelbugと名付けられました。

興味深いことに、英語圏の文献では、Bohrbugという用語は「決定論的エラー」の同義語としてよく使われますが、日本語環境ではあまり一般的ではありません。ほとんどの開発者は、単に「再現可能なエラー」と呼んでいます。

Bohrbugの主な特徴

Bohrbugには、他のソフトウェア欠陥タイプの中から識別するのに役立つ特徴的な特性のセットがあります。各特徴を詳しく見ていきましょう。

決定論性

Bohrbugの主な特徴は完全な予測可能性です。開発者のマシンで特定の入力データによってアプリケーションがクラッシュした場合、テスト担当者のマシンや本番環境でもまったく同じようにクラッシュします。ランダムな要因はありません。

再現性

Bohrbugは100%の試行で再現します。つまり、特別なツールを必要とせず、標準的なIDEとデバッガで十分です。開発者がブレークポイントを設定し、アプリケーションを起動し、入力データを提供して、コードをステップバイステップで進めるだけです。

経時的安定性

Bohrbugを修正しない限り、修正されるまでプログラムのどのバージョンでも再現します。CPU負荷、月の満ち欠け、時間帯などの時間的要因は、その発生に影響を与えません。

Bohrbugが発生する主な原因

Bohrbugの原因はいくつかのカテゴリに分類できます。これらのカテゴリを理解することで、問題の根本をより早く見つけられます。

論理エラー

誤って構築された条件分岐は、Bohrbugの最も一般的な原因です。たとえば、開発者が`&&`の代わりに`||`演算子を使用した場合、特定の引数で関数が呼び出されるたびにコードブランチが誤って実行されます。

境界条件のエラー

`<=`の代わりに`<`演算子を使用する、またはその逆の状況は、Bohrbugの古典的な原因です。ループが正しい条件では10回実行されるべきところ、誤った条件のために11回実行される場合、これは実行のたびに発生する決定論的エラーです。

誤った定数とマジックナンバー

ビジネスロジックと一致しないハードコードされた定数は、安定した障害を生み出します。たとえば、サーバー接続のタイムアウトが5000ミリ秒ではなく100ミリ秒に設定されている場合、接続はリクエストのたびに切断されます。

コード内でBohrbugを発見する方法

Bohrbugの発見は、他のバグタイプと比較して開発者にとって最も簡単なタスクです。決定論的な性質により、標準的なデバッグ手法を適用できます。

public class DiscountCalculator {
    public double calculate(double amount, boolean isPremium) {
        // バグ：プレミアムユーザーが10%ではなく5%の割引を受け取る
        if (isPremium) {
            return amount * 0.95;
        }
        return amount * 0.90;
    }
}

この例では、Bohrbugは明らかです：`calculate(1000, true)`を呼び出すと、メソッドは常に900ではなく950を返します。固定された入力データによる単純な単体テストで、瞬時に問題が明らかになります。

主要な手法としての単体テスト

Bohrbugを発見するには、単体テストが最も効果的なツールです。さまざまな境界値を持つテストセットで関数をカバーすれば、最初の実行で決定論的エラーが現れます。

ステップバイステップのデバッグ

Bohrbugが発見されたら、IDEでのステップバイステップのデバッグが根本原因を見つける最良の方法です。開発者は関数の入口にブレークポイントを設定し、変数の値を観察しながら各行を進めます。

Bohrbugと他のバグタイプの違い

Bohrbugは、決定論性という重要な特性によって他のソフトウェアエラータイプと区別されます。表で比較してみましょう。

Bohrbugは、制御された条件下で確実に再現できる唯一のエラータイプです。そのため、診断の観点からは最も安全ですが、ユーザーにとっては同様に危険です。

BohrbugとHeisenbugが混同される理由

Heisenbugは、デバッグしようとすると消えるバグです。Bohrbugとは異なり、Heisenbugはコード実行のタイミング変化によりデバッガで再現しない場合があります。初心者の開発者はしばしばこの2つを混同します。

コード内のBohrbugの例

EコマースアプリケーションにおけるBohrbugの実際の例を見てみましょう。この関数は、税金を含む注文の合計コストを計算します。

public double calculateTotal(double subtotal, double taxRate) {
    // バグ：開発者がtaxRateをパーセンテージとして設定した
    // が、100で割るのを忘れた
    return subtotal + (subtotal * taxRate);
}

`calculateTotal(1000, 20)`を呼び出すと、関数は期待される1200ではなく21000を返します。これは古典的なBohrbugです：同じ入力データが常に同じ誤った結果を導きます。修正は簡単で、100で割る処理を追加するだけです。

修正後のバージョン

修正後、関数は税率を正しく処理します：

public double calculateTotal(double subtotal, double taxRatePercent) {
    return subtotal + (subtotal * taxRatePercent / 100.0);
}

この例は、Bohrbugが単純な数学的エラーによって引き起こされる可能性があることを明確に示しています。そのため、コードレビューと単体テストが、このような欠陥を防ぐ主要なツールなのです。