IT用語集 2024/08/06

ド・モルガンの法則とは？ 10分でわかりやすく解説

コラム

ド・モルガンの法則は、否定を含む条件式を扱うときの基本法則です。ITシステムの設計や開発では、条件分岐、アクセス制御、検索条件（SQL）、監視ルールなどで複雑な条件式を日常的に扱います。この法則を理解しておくと、「否定（NOT）」を含む式を意味を変えずに書き換えやすくなり、読み違いによるバグや運用トラブルを減らしやすくなります。

ド・モルガンの法則を一言でいうと、NOTが括弧をまたぐときにANDとORが入れ替わる法則です。本記事では、その基本、よくある変形パターン、実務での使いどころ、そしてどこまで一般化できるか／何に注意すべきかを順に整理します。式の意味を保ったまま、分かりやすい形へ変形できるようになることがゴールです。

ド・モルガンの法則とは？

ド・モルガンの法則とは、命題論理における「否定（NOT）」と「論理積（AND）・論理和（OR）」の関係を示す法則です。要点は、NOTが括弧をまたぐときにANDとORが入れ替わり、各項にNOTが分配されるという2つの等価変形にあります。

ド・モルガンの法則の定義

ド・モルガンの法則は、次の2つで表されます。

¬(P ∧ Q) ≡ (¬P) ∨ (¬Q)
¬(P ∨ Q) ≡ (¬P) ∧ (¬Q)

ここで、PとQは命題（真/偽をもつ条件）を表します。¬は否定、∧はAND、∨はORです。

言い換えると、次のように覚えると実務で使いやすくなります。

NOT (A AND B) は (NOT A) OR (NOT B)
NOT (A OR B) は (NOT A) AND (NOT B)

なぜ重要か（否定を含む条件式の誤読を防ぐ）

実務では、否定が絡む条件式が読みづらくなりがちです。たとえば「この条件を満たさない場合」のように、仕様が“否定形”で与えられることは珍しくありません。

ド・モルガンの法則を使うと、否定を括弧の外から中へ移して、条件を読みやすい形に分解できます。これにより、条件式が短くなることもありますが、それ以上に人間が読みやすくなり、バグの予防に直結します。

命題論理との関係

ド・モルガンの法則は、命題論理（真偽値と論理演算）における基本的な同値変形です。論理式を同値変形しても意味（真偽が成立する条件）は変わらないため、設計・レビュー・テストの場面で「仕様の意味を保ったまま表現を変える」ための共通言語になります。

ド・モルガンの法則の基本的な使い方

ここでは、ド・モルガンの法則をどんな式に、どの順で適用すると分かりやすいかを、変形の手順に沿って見ていきます。見るべき点は、括弧の外にあるNOTを内側へ移すときに、ANDとORがどの段階で入れ替わるかです。

論理式の簡単化（NOTを内側へ分配する）

例として、次の式を考えます。

¬(P ∧ (Q ∨ R))

括弧の外のNOTを内側へ入れていきます。まず外側のANDに対してド・モルガンを適用します。

¬P ∨ ¬(Q ∨ R)

次に、残った ¬(Q ∨ R) に対して、ORのド・モルガンを適用します。

(¬P) ∨ ((¬Q) ∧ (¬R))

このように、NOTが括弧をまたぐたびにAND/ORが入れ替わることを意識すると、手続き的に変形できます。

プログラミングでの活用（否定を減らして読む）

たとえば次の条件式は、否定が括弧をまたいでいて読みにくくなりがちです。

if (!(a && (b || c))) { ... }

ド・モルガンの法則で変形すると、次の形になります。

if (!a || (!b && !c)) { ... }

どちらが良いかは状況次第ですが、実務では「否定が外側に大きくかかっている」よりも「各条件の近くに否定が付いている」ほうが、レビューで読み解きやすいことがあります。

なお、変形は可読性や仕様理解のために行うのが基本で、実行速度が必ず上がるとは限りません（コンパイラ最適化や短絡評価の影響もあるため）。まずは読み間違いを減らすことを優先するのが安全です。

論理回路設計への応用（NAND/NORでの実装）

論理回路では、NAND（NOT-AND）やNOR（NOT-OR）が部品として使いやすいことがあります。ド・モルガンの法則は、AND/ORとNOTの構造を入れ替えられるため、同じ機能をNANDだけ／NORだけで実現するといった設計の基礎にもなります。

たとえば、¬(P ∧ Q) は、そのままNANDです。逆に、(P ∨ Q) をNORとNOTの組み合わせで表現する、といった変形が可能になります。

具体的な適用例（ありがちな“仕様の言い換え”）

アクセス制御（権限チェック）
- 「AとBの両方を満たすユーザーだけ許可」を否定すると、¬(A ∧ B) となります。
- ド・モルガンを使えば、(¬A) ∨ (¬B) ＝「Aがない、またはBがない」に分解できます。
- ログやエラー理由（どの条件が不足か）を出したい場合、この形のほうが扱いやすいことがあります。
SQLの検索条件（NOTの押し出し／押し込み）
- WHERE NOT (A AND B) は、WHERE (NOT A) OR (NOT B) に同値です。
- SQLでもAND/OR/NOTの範囲ではド・モルガンの法則を使えます。ただし、比較演算にNULLが混ざると結果がUNKNOWNになるため、IS NULL/IS NOT NULLの明示や、NOT IN などNULLで誤読しやすい構文への注意が必要です。
監視・アラート条件（“異常ではない”を分解する）
- 「CPUが高くないかつエラーが出ていない」など、“正常条件”をまとめてNOTで囲みたくなる場面があります。
- その逆（異常条件）を作るときにド・モルガンで分解すると、アラート理由が明確になり、運用が楽になることがあります。

ド・モルガンの法則の一般化と注意点

この章では、複数条件への拡張と、SQLのNULLのように二値では済まない場面での注意点を見ていきます。まずは、どこまでそのまま使えて、どこから前提確認が必要になるのかを切り分けることが重要です。

ド・モルガンの法則の一般化（n個への拡張）

ド・モルガンの法則は2項だけでなく、複数項にも自然に拡張できます。

¬(P1 ∧ P2 ∧ ... ∧ Pn) ≡ (¬P1) ∨ (¬P2) ∨ ... ∨ (¬Pn)
¬(P1 ∨ P2 ∨ ... ∨ Pn) ≡ (¬P1) ∧ (¬P2) ∧ ... ∧ (¬Pn)

実務では、長いAND条件をまとめてNOTで囲った仕様（「全部満たさないなら…」）を、読みやすいOR条件へ分解する、といった形で登場します。

三値論理（NULLなど）では注意が必要

プログラミング言語の多くは二値（true/false）ですが、SQLのNULLや、一部の仕様（未知・未判定）を扱う世界では、論理が三値になることがあります。

SQLのようにNULLを含む三値論理でも、AND/OR/NOTの真理値表に従う範囲ではド・モルガンの法則は成り立ちます。注意が必要なのは法則そのものより、比較演算の結果がUNKNOWNになり得ることや、NOT INのようにNULLで直感とズレやすい構文があることです。

実務上は、次のような対策が現実的です。

NULLを取り得る列には、IS NULL / IS NOT NULL を明示する
「未知」を許容するのか、排除するのかを仕様として先に決める
変形後は、境界ケース（NULL/空/未設定）を含むテストデータで結果を比較する

ファジィ論理・量子・AIへの言及は“前提”を切り分ける

ド・モルガンの法則は古典的な二値論理の基本法則です。ファジィ論理や量子計算、AIなどの分野で“類似の関係”が議論されることはありますが、そこでのAND/OR/NOTは古典論理と同じ定義ではない場合が多く、前提を揃えずに一般論として語ると誤解が生まれやすい領域です。

実務で使ううえでは、まず「古典論理の範囲（true/false）で確実に使える」ことを軸に理解するのが無難です。ファジィ論理や量子計算などの話題は、前提が違うため単純には同じものとして扱えないと考えておくと混乱を避けやすくなります。

まとめ

ド・モルガンの法則は、NOTが括弧をまたぐときにAND/ORが入れ替わり、各項に否定が分配されることを示す基本法則です。覚える形は2つだけですが、条件式を読みやすくしたり、仕様の否定形を分解して扱いやすくしたりする場面で、実務上の価値が大きい法則です。

一方で、SQLのNULLのように三値論理が絡む世界では、比較演算の結果がUNKNOWNになることや、NOT INのようにNULLで直感とズレやすい構文に注意が必要です。ド・モルガンの法則そのものではなく、NULLを含む比較の意味を確認し、境界ケースをテストすることが重要です。こうした前提まで含めて押さえておくと、論理式の設計やレビューで条件の読み違いを減らしやすくなります。