独立と排反を業務で活かす：問い合わせ・障害分析の実例

5分で確認するポイント

排反：2つの事象が同時に起こらない。問い合わせ件数の二重計上防止に役立つ。

独立：一方の発生を知っても、もう一方の確率が変わらない。障害の関連分析・リスク評価に役立つ。

条件付き確率：「Aが起こったとき、Bはどれくらい起こるか」を考える。

覚え方：排反は「重複の有無」、独立は「確率への影響」。

この記事の例について

この記事の業務例・件数・確率はすべて説明用の架空データです。実在の企業、システムの運用実績や障害情報ではありません。

1. 最初に：独立と排反はまったく別の性質

観点	排反	独立
意味	2つの事象 A と B が同時に起こらない	A が起きたかどうかが、B の起こる確率に影響を与えない
数学的な条件	\(P(A\cap B)=0\)	\(P(A\cap B)=P(A)P(B)\)
業務での主な役割	カテゴリ分類や集計の重複チェック	トラブル同士の関連性や同時発生リスクの評価

日常会話では「独立」と「別々に起きている」を混同しがちですが、統計学的には意味が異なります。2つの事象が同時に起こり得る関係であっても、互いに独立であることは十分にあります。

サイコロを1回だけ振る身近な例で違いを整理してみましょう。

排反の例: A＝「1が出る」、B＝「2が出る」
- 1と2が同時に出ることは絶対にないので排反です。ただし、「1が出た」と分かった瞬間、2が出る確率は 0 に変わるため、独立ではありません（一方の結果が他方の確率を左右している）。
独立の例: A＝「偶数が出る」、B＝「3の倍数が出る」
- 6が出れば両方の条件を満たすため、排反ではありません（同時に起こり得る）。一方、確率を計算すると \(P(A\cap B) = 1/6 = (1/2) \times (1/3) = P(A)P(B)\) となり、独立が成り立ちます。

なお、どちらの事象も起こる確率が 0 より大きい場合、「排反」と「独立」が同時に成立することは絶対にありません。

2. 排反の実務活用：問い合わせ件数の二重計上を防ぐ

ある月、カスタマーサポートに寄せられた100件の問い合わせを分析するケースを考えます。

問い合わせ分類（複数タグ付与可）	該当件数
CSV連携に関係する問い合わせ（事象A）	30件
承認ワークフローに関係する問い合わせ（事象B）	20件
両方に関係する問い合わせ（AかつB）	8件

ここで、「CSV連携または承認ワークフローに関係する問い合わせの総数」を算出したいとします。単純に \(30 + 20 = 50\) 件と足し算してしまうと、両方のタグが付いている8件を二重にカウントしてしまいます。

正しくは、重複分を差し引いて計算します。

\[ |A\cup B| = |A| + |B| - |A\cap B| = 30 + 20 - 8 = \mathbf{42\text{件}} \]

現場で活かすポイント: - マルチタグ集計の注意点: 1件のレコードに複数の原因タグを付与できる設計の場合、タグごとの件数を単純合算した値を「問い合わせ全体の総数」と見なしてはいけません。 - 主原因の単一化: レコードごとに「最も支配的な主原因」を1つだけ選ばせる運用にすれば、各分類は互いに排反となり、単純な足し算で全体の総数と一致させることができます。 - ダッシュボード設計: 集計画面では「ユニーク問い合わせ件数（実件数）」と「タグ別延べ件数」の定義を明確に分けて表示することで、関係者間の認識ズレを防げます。

[!NOTE] 「排反かどうか」はカテゴリの名称ではなく、「1つのデータに対して複数のフラグが同時に立ち得る運用設計になっているか」で判断します。

3. 独立の実務活用：トラブル原因同士の関連性を探る

先ほどの100件の問い合わせデータから、無作為に1件を取り出す状況を考えます。

CSV連携に関連する確率: \(P(A) = 30 / 100 = 0.30\)
承認ワークフローに関連する確率: \(P(B) = 20 / 100 = 0.20\)
両方に関連する確率: \(P(A\cap B) = 8 / 100 = 0.08\)

もし、このシステムにおいてCSV連携と承認ワークフローが完全に独立して動いているなら、両方が同時に発生する確率は掛け算になるはずです。

\[ P(A)P(B) = 0.30 \times 0.20 = 0.06 \; (6\%) \]

つまり、理論上は6件程度になるはずですが、実績値は8件（8%）ありました。

条件付き確率で捉え直すと、より直感的に違いが分かります。

\[ P(B\mid A) = \frac{8}{30} \approx 26.7\% \]

全体でのワークフロー関連割合（20%）に比べ、「CSV連携の問い合わせである」と分かっているグループの中では、ワークフロー関連の割合が約26.7%へと跳ね上がっています。つまり、この手元のデータ上では両者は独立していません。

ここから読み取れること: CSV連携処理とワークフロー機能の間でデータ連携の不備や、ユーザーの誤操作を招きやすい共通の導線・仕様がないかなど、調査の手がかりとして活用できます。
注意すべき落とし穴: ただし、手元の100件だけで「CSV連携のバグがワークフロー障害を引き起こしている」といった因果関係を決めつけてはいけません。背後に共通の原因（例: ユーザー管理マスタの不整合など）が隠れている可能性や、単なるサンプルの偶然のばらつきも疑う必要があります。より本格的な検証には、クロス集計表やカイ二乗検定を活用します。

4. 独立の実務活用：システムの同時障害リスクを見積もる

例えば、あるクラウドサービスの月間停止確率が以下のように見積もられていたとします。

認証システムAの月間停止確率: \(2\%\)
決済システムBの月間停止確率: \(3\%\)

もし両システムが完全に独立して稼働していると保証・仮定できるなら、同じ月に両方が同時に停止する確率は単純な掛け算で求められます。

\[ P(A\cap B) = 0.02 \times 0.03 = 0.0006 = \mathbf{0.06\%} \]

しかし、両システムが「同じクラウド事業者の同一リージョン」「共通のDNS基盤」「共通のデータベース」に依存している場合、共通の単一障害点（SPOF）によって共倒れする可能性があります。独立性を確認せずに安易に掛け算を行うと、同時停止リスクを致命的に過小評価してしまう危険性があります。

実務における確認ステップ: 1. 停止の定義と期間の整合: 対象期間や「停止」の判定基準（完全ダウン、レスポンス遅延、ログイン不可など）が揃っているか確認する。 2. 共通の依存関係の洗い出し: インフラ構成図やミドルウェア、外部API連携先などに共通の依存先がないかを点検する。 3. 過去の障害履歴の照合: 片方のシステムに障害が発生した際、もう片方にもエラーが波及していなかったか実績ログを精査する。 4. 根拠なき独立仮定の排除: 独立性を客観的に説明できない場合は、掛け算による楽観的なリスク数値を確定値として報告しない。

5. 検定への接続：日々の問い合わせデータは独立か？

業務改善施策の効果を検証するために「施策前後の日別問い合わせ件数」を統計的に比較する場合も、独立性のチェックは極めて重要です。

例えば、「月曜日に発生した大規模障害の影響が火曜日・水曜日にも尾を引いて問い合わせが高止まりしている」ような状況では、日々の観測データ同士が互いに影響し合っており（自己相関が存在し）、データが独立ではありません。

独立性の前提が崩れたまま一般的な平均値の差の検定（t検定など）を行うと、標準誤差やp値が歪み、施策の効果を誤って判断してしまうリスクがあります。時系列データ特有の連動や曜日要因、障害の継続影響を慎重に見極める姿勢が求められます。

6. 仕事中の5項目チェック

今求めているのは「AかつB」か「AまたはB」か？
分類は排反か？同じレコードを二重に数えていないか？
独立と仮定する根拠はあるか？共通原因はないか？
条件付き確率 \(P(B\mid A)\) と全体の確率 \(P(B)\) を比較したか？
関連が見つかっても、因果関係や統計的な確かさを早合点していないか？