原因結果グラフとは、複雑な条件ロジックを「図」で整理し、テストケースに変換するテスト設計技法です。デシジョンテーブルでは整理しきれない多条件・複雑なAND/OR/NOTのロジックを視覚化することで、漏れのないテスト設計が実現できます。
この記事では、原因結果グラフ（Cause-Effect Graph）の作り方と具体例をわかりやすく解説します。
👉 デシジョンテーブルとの違い：条件を直接表にするか、図で整理してから表にするか——この違いが複雑なロジックで大きな差を生みます。
💡 一言でいうと
原因結果グラフ ＝ 何が起きたら何が起こるかを図にして、テストケースを機械的に導き出す技法
📌 結論（30秒で理解）
原因結果グラフとは、「原因（条件）と結果（動作）の関係を図で整理し、デシジョンテーブルに変換してテストケースを作る技法」です。
- ✔ 条件が多い（6個以上）
- ✔ AND / OR / NOT が複雑に絡む
- ✔ デシジョンテーブルが破綻した
→ こういうときに使うテスト設計技法です。
📊 原因結果グラフのイメージ（ログイン処理の例）
👉 左が原因（入力条件）、右が結果（動作）。上が正常系、下が異常系の典型パターンです。
👉 各条件の組み合わせによって、どの結果（正常 or 異常）が発火するかを表しています。
| C1（IDが正しい） | ──┐ | AND ∧ | ──→ | E1 ログイン成功 | ← 正常遷移 |
| C2（PWが正しい） | ──┘ | ||||
| ¬C1（IDが間違い） | ──┐ | OR ∨ | ──→ | E2 エラー表示 | ← 異常系 |
| ¬C2（PWが間違い） | ──┘ | ||||
C＝原因（Cause） E＝結果（Effect） ¬＝NOT ∧＝AND ∨＝OR →＝遷移
原因結果グラフを使うと、複雑な条件の組み合わせを「図→デシジョンテーブル」の流れで機械的にテストケースに変換でき、見落としや重複のない高品質なテスト設計が実現できます。
📌 この記事はこんな方におすすめ
- 原因結果グラフを初めて学ぶQAエンジニア・開発者
- デシジョンテーブルでは条件が多すぎて整理できない場面に直面している方
- 複雑な業務ロジックのテスト設計を体系化したい方
- JSTQBの学習で原因結果グラフを理解したい方
✅ この記事を読むと得られること
- 原因結果グラフの概念・論理記号・作り方がわかる
- グラフからデシジョンテーブルを導き出す手順がわかる
- デシジョンテーブルとの使い分けの判断基準がわかる
👤 この記事を書いた人
QAエンジニア・テスト自動化エンジニアとして15年以上の実務経験を持つ Yoshi が執筆。原因結果グラフは複雑な業務ロジックの検証で活用している技法です。実装コードはGitHubで公開中：github.com/YOSHITSUGU728/automated-testing-portfolio
「条件が6個以上あってデシジョンテーブルが巨大化してしまう」「条件間に複雑なOR・AND・NOTの関係があって整理できない」——こうした問題に直面したことはありませんか？
- 条件が増えるほどデシジョンテーブルの列が指数的に増加する
- AND・OR・NOTが混在した複雑なロジックを表で表現しきれない
- どの条件の組み合わせが「どの結果」に対応するかが追えなくなる
原因結果グラフはこうした問題を解決する技法です。まずグラフで因果関係を視覚化してからデシジョンテーブルに変換するため、複雑なロジックも体系的に整理できます。
📌 原因結果グラフのポイント
- 「原因（入力条件）→論理演算（AND/OR/NOT）→結果（期待動作）」をグラフで表現するテスト設計技法
- グラフをデシジョンテーブルに変換することで網羅的なテストケースを機械的に導き出せる
- デシジョンテーブルの前段として使うことで条件6個以上の複雑なロジックも整理できる
原因結果グラフとは？
原因結果グラフ（Cause-Effect Graph）とは、「入力条件（原因）と期待動作（結果）の論理的な関係をグラフ形式で表現し、そのグラフからデシジョンテーブルを導き出すテスト設計技法」です。
1970年代にIBMが開発した技法で、JSTQBでもテスト設計技法として定義されています。デシジョンテーブルは「条件の組み合わせを直接表形式で整理する」のに対し、原因結果グラフは「まず因果関係を図で整理してからデシジョンテーブルに変換する」という2段階アプローチを取ります。
| 比較項目 | デシジョンテーブル | 原因結果グラフ |
|---|---|---|
| アプローチ | 条件を直接表に整理 | グラフ→テーブルの2段階 |
| 条件数の目安 | 2〜5個程度 | 6個以上でも対応可能 |
| 論理関係の表現 | 暗黙的（行に条件を並べる） | 明示的（AND/OR/NOTを図で表現） |
| 視覚的な把握 | 列が多くなると見づらい | グラフで全体像を把握しやすい |
| 学習コスト | 低い（直感的） | やや高い（記号の習得が必要） |
原因結果グラフの基本要素とは？
原因結果グラフは「ノード（節点）」と「リンク（辺）」で構成されます。論理演算を表す記号を覚えることがグラフ作成の第一歩です。
ノードの種類
| ノード種別 | 記号 | 意味 | 例 |
|---|---|---|---|
| 原因（Cause） | C1〜Cn | 入力条件・前提条件 | IDが正しい / 年齢が18歳以上 |
| 結果（Effect） | E1〜En | 期待される動作・出力 | ログイン成功 / エラーメッセージ表示 |
| 中間ノード | I1〜In | 複数の原因を論理演算でまとめた中間状態 | 「IDとPWが両方正しい」など |
論理演算記号の種類
📊 原因結果グラフの論理演算記号
| 記号 | 名称 | 意味 | 例 |
|---|---|---|---|
| → | 恒等（Identity） | 原因が真なら結果も真 | C1が真 → E1が真 |
| ∧ | AND | すべての原因が真のときだけ結果が真 | C1かつC2が真 → E1が真 |
| ∨ | OR | いずれかの原因が真なら結果が真 | C1またはC2が真 → E1が真 |
| ¬ | NOT | 原因が偽のときだけ結果が真 | C1が偽 → E1が真 |
※ これらの記号を組み合わせて複雑な条件関係を表現する
制約記号（Constraint）
原因間・結果間の「あってはいけない組み合わせ」を表す制約記号もあります。
| 記号 | 名称 | 意味 |
|---|---|---|
| E | 排他（Exclusive） | 同時に真になれない（最大1つだけ真） |
| I | 包含（Inclusive） | 少なくとも1つは真でなければならない |
| O | 排他的論理和（One and only one） | 必ずどちらか1つだけが真 |
| R | 必要（Requires） | C1が真のとき、C2も必ず真でなければならない |
| M | マスク（Mask） | E1が真のとき、E2は必ず偽になる |
原因結果グラフの作り方：4ステップ
| ステップ | 内容 |
|---|---|
| STEP 1 | 仕様書から「原因（入力条件）」と「結果（期待動作）」を洗い出す |
| STEP 2 | 原因と結果をAND/OR/NOTの論理演算でつないだグラフを描く |
| STEP 3 | 原因間・結果間に制約記号（E/I/O/R/M）を追加する |
| STEP 4 | グラフの各パターンを逆方向に読み解いてデシジョンテーブルに変換する |
実例：原因結果グラフの作り方と例（会員割引システム）
ECサイトの割引適用ロジックを例に、原因結果グラフの作り方を解説します。
仕様（原因と結果の洗い出し）
| 種別 | 番号 | 内容 |
|---|---|---|
| 原因 | C1 | プレミアム会員である |
| 原因 | C2 | クーポンを保有している |
| 原因 | C3 | 購入金額が5,000円以上である |
| 結果 | E1 | プレミアム割引（10%オフ）が適用される |
| 結果 | E2 | クーポン割引（5%オフ）が適用される |
| 結果 | E3 | 大口割引（3%オフ）が適用される |
論理関係（グラフの内容）
| ルール | 論理式 |
|---|---|
| プレミアム会員なら → プレミアム割引適用 | C1 → E1（恒等） |
| クーポン保有 AND プレミアムでない → クーポン割引適用 | C2 AND ¬C1 → E2 |
| 5,000円以上 AND（プレミアム OR クーポンなし）→ 大口割引 | C3 AND ¬C1 AND ¬C2 → E3 |
グラフからデシジョンテーブルへの変換
グラフを作成したら、各結果が「True（発火）」になる条件の組み合わせを逆方向に読み解いてデシジョンテーブルに変換します。
| 条件 / 結果 | C1 | C2 | C3 | C4 | C5 | C6 |
|---|---|---|---|---|---|---|
| プレミアム会員（C1） | Y | Y | N | N | N | N |
| クーポン保有（C2） | Y | N | Y | Y | N | N |
| 5,000円以上（C3） | – | – | Y | N | Y | N |
| → E1：プレミアム割引 | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| → E2：クーポン割引 | ❌ | ❌ | ✅ | ✅ | ❌ | ❌ |
| → E3：大口割引 | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ |
グラフから変換することで「プレミアム会員のときはクーポンの有無に関わらずE1が発火」「C1=N・C2=Y のときはE2（クーポン割引）」「C1もC2もNで5,000円以上のときだけE3（大口割引）」という構造が明確に整理されました。
原因結果グラフとデシジョンテーブルの違いとは？使い分けの判断基準
原因結果グラフとデシジョンテーブルは目的が近いため、実務での使い分けが重要です。原因結果グラフ デシジョンテーブル 違いを一言で言うと「グラフで整理してから表にするか、最初から表にするか」の違いです。
| 判断基準 | → デシジョンテーブル | → 原因結果グラフ |
|---|---|---|
| 条件の数 | 2〜5個 | 6個以上 |
| 論理関係の複雑さ | シンプルなYes/No条件 | AND/OR/NOT が複雑に混在 |
| 条件間の制約 | 制約がほぼない | 排他・包含などの制約が多い |
| チームへの説明 | 表で十分伝わる | 図で視覚化した方が伝わりやすい |
💡 実務での使い分けフロー
- 条件が2〜5個 → デシジョンテーブルで直接設計
- 条件が6個以上 or AND/OR/NOT が複雑に混在 → 原因結果グラフでグラフを作ってからデシジョンテーブルに変換
- 最終的には両技法ともデシジョンテーブルに落とし込んでテストケースを導く
💡 実務例：デシジョンテーブルが破綻したケース
権限管理のロジック（管理者・一般ユーザー・ゲスト × 操作権限5種 × 状態3種）を直接デシジョンテーブルで設計しようとしたところ、列が50パターン以上になり管理不能に。
原因結果グラフでロジックを整理したところ、不要な条件と排他制約の漏れが明確になり、最終的に20パターン程度まで削減できました。「ぐちゃぐちゃな条件をグラフで整理してから表に落とす」——このプロセスがあるだけで設計品質が一段上がります。
向いているケース / 向いていないケース
✅ 向いているケース
| ✖ 向いていないケース
|
原因結果グラフを書くツール
| ツール | 特徴 | 費用 |
|---|---|---|
| draw.io | ブラウザで使える・VS Codeプラグインあり・図のエクスポートが簡単 | 無料 |
| Lucidchart | チーム共有・リアルタイム編集・Confluence連携 | 有料（無料プランあり） |
| Miro | ホワイトボード型・ブレスト感覚で描ける・チーム向け | 有料（無料プランあり） |
| Microsoft Visio | 企業環境での標準ツール・豊富な図形テンプレート | 有料 |
⚠️ 原因結果グラフでよくある失敗パターン4選
実務で原因結果グラフを使うときに陥りやすい失敗を紹介します。
① 条件が少ないのに原因結果グラフを使おうとする
条件が2〜4個程度であれば、デシジョンテーブルで直接設計した方がシンプルで速いです。原因結果グラフは「複雑な論理関係を視覚化するためのツール」なので、シンプルなケースに使うと逆に手間が増えます。条件数と論理の複雑さで使い分けましょう。
② 制約記号を付け忘れて不可能なテストケースが生成される
「支払い方法：クレジットカード」と「支払い方法：代金引換」のように同時に選べない原因間に排他制約（E）を付け忘れると、実際には起こりえないテストケースがデシジョンテーブルに混入します。テーブルに変換した後は必ず「この組み合わせは現実に発生するか？」を確認しましょう。
③ グラフを作っただけでデシジョンテーブルへの変換を省略する
原因結果グラフはあくまで「デシジョンテーブルを導き出すための中間成果物」です。グラフを作って満足してしまい、テストケースへの変換まで完了させないと意味がありません。グラフ→デシジョンテーブル→テストケースという流れを必ず最後まで完走しましょう。
④ 中間ノードを使わずにグラフが複雑になりすぎる
複数の原因をグループ化する「中間ノード（I）」を使わないと、原因から結果への線が錯綜して読みにくいグラフになります。「C1かつC2」という条件を中間ノードI1としてまとめ、I1から結果Eへ線を引くことでグラフがすっきりします。
FAQ
Q. 原因結果グラフはいつ使うべきですか？
条件が6個以上ある・AND/OR/NOTが複雑に混在している・条件間に排他や包含などの制約がある場合に使います。条件が少なくシンプルなロジックにはデシジョンテーブルの方が適しています。「デシジョンテーブルを作ろうとしたら列が多すぎて整理できなかった」というときが原因結果グラフの出番です。
Q. 原因結果グラフとデシジョンテーブルはどちらが優れていますか？
優劣はなく、補完関係にあります。デシジョンテーブルはシンプルで直感的・条件が少ない場合に向いています。原因結果グラフは複雑な論理関係の視覚化・条件が多い場合に向いています。実務では「原因結果グラフで整理してからデシジョンテーブルに変換する」という組み合わせが一般的です。
Q. JSTQBで原因結果グラフはどの程度出題されますか？
JSTQB Foundation Levelでは「原因結果グラフの概念・目的・デシジョンテーブルとの関係」が問われます。「原因結果グラフはデシジョンテーブルを導き出すための技法であり、原因（入力）と結果（出力）の論理的関係をグラフで表現する」という理解があれば対応できます。Advanced Levelではより詳細な知識が求められます。
Q. 原因結果グラフを書くツールはありますか？
専用ツールとしては「CTE（Classification Tree Editor）」や「Agora Test Manager」などがあります。一般的なダイアグラムツールであれば draw.io（無料）やMicrosoft Visio・Lucidchart でも作成できます。実務では draw.io でグラフを作成し、そこから手動でデシジョンテーブルに変換するワークフローが費用対効果が高くおすすめです。
📖 関連記事
実務では、条件が6個以上ある複雑な業務ロジック（権限管理・割引ルール・審査フロー等）の設計時に原因結果グラフを draw.io で作成し、チームレビュー後にデシジョンテーブルへ変換するワークフローを採用しています。グラフが「共通言語」となり、開発・QA・ビジネス側で同じロジックを見ながらレビューできる点が最大の利点です。
📋 この記事のまとめ
- 原因結果グラフは「原因→論理演算（AND/OR/NOT）→結果」の関係をグラフで表現するテスト設計技法
- グラフをデシジョンテーブルに変換することで網羅的なテストケースを機械的に導き出せる
- 条件が6個以上・AND/OR/NOTが複雑に混在する場合にデシジョンテーブルの前段として使う
- 制約記号（E/I/O/R/M）で「あってはいけない組み合わせ」を明示することで不可能なテストケースを除外できる
- 最終的には必ずデシジョンテーブルへ変換してテストケースを導き出すところまで完走する
原因結果グラフは「複雑さを図で整理してからテストケースに変換する」という2段階アプローチにより、デシジョンテーブル単独では整理しきれない複雑なロジックも体系的にテスト設計できます。まずは簡単な3〜4条件のロジックで原因結果グラフを書いてみると、理解が一気に深まります。デシジョンテーブルへの変換の流れを身につけた後は、より複雑な業務ロジックへと応用していきましょう。まずは簡単なロジックで1つグラフを書いてみることが、最短で理解するコツです。
