読み手は想像以上に「文言の解釈」でつまずきます。だからこそ、肯定形でシンプルに伝える設計が効きます。認知心理の研究では、否定文は肯定文より処理に時間がかかり、否定が重なるほど理解負荷が増すことが示されています。また、Plain Languageのガイドラインでも二重否定は誤解の温床とされ、肯定形への書き換えが推奨されています。
- なぜ「つまずき」が起きるのか
- 人間の理解は“デフォルトで肯定形が速い”という傾向があるため、否定や二重否定は瞬時の把握を難しくする（認知負荷の増大）。[1]
- 行政・公共向けのPlain Language指針でも、二重否定は読み手の誤解や不安を招くため避けるべきとされる。[2]
- これは読者の資質の問題ではなく、人間一般の情報処理特性による“仕様”である。だからこそ、書き手が肯定形・単純化・順序の工夫で守るのが筋、という立場を本稿は採る。
二重否定とは（前提のごく短い解説）
二重否定は「否定×否定」で意味が反転したり曖昧になったりする表現です。文章では回りくどさや誤読を招き、コードでは可読性の低下やバグの温床になりがちです。
- 文章の例：
- 「安全でないとは言い切れない」→ 結論が読み取りづらく、判断が曖昧に伝わる（肯定か否定か即時に把握しにくい）
- 訂正例（意図別）：
- 結論を肯定形で先に出す：
- 「現時点では安全と評価する。ただし、◯◯の条件下では再評価が必要」
- 可能性に留める（断定回避）：
- 「安全性に懸念が残る可能性がある」
- エビデンスとセットで保守的に：
- 「重大なリスクは確認されていない（検証サンプルn=◯、閾値△△、期間□□）」
- 責務分解して明確化：
- 「当該構成については安全要件を満たす。運用上のリスクは別途モニタリングで管理する」
- 結論を肯定形で先に出す：
- コードの例：
→ 対策は「肯定形で言い切る」「条件を分解して名前を与える」「二重否定の命名を避ける」です。
if文（条件分岐）での二重否定を避ける
- 悪例
// 何を満たしたときに実行されるのか、一瞬で読み取りづらい
if (!isNotValid(user) && !(errors.length === 0)) {
// ...
}
- 良例（肯定形に命名・条件を寄せる）
if (isValid(user) && hasErrors(errors)) {
// ...
}
- 良例（ドメインの意図を関数名に上げる）
const canReceiveEmail = (user) =>
user.isActive && user.subscription.isActive() && !user.isBanned;
if (canReceiveEmail(user)) sendEmail(user);
- 指針
- 変数・関数は肯定名で表現する（isDone, hasPermission, canX）。
-
!isNotXのような否定の否定は避ける。 - 読み手の負荷を減らすために、条件は短く分解し名前を与える。
参考: ダブルネガティブを避ける指針や可読性の議論。[^
][^
]
ドキュメント（document）の文言での二重否定
- 推奨スタイル
- まず結論を肯定形で述べ、例外や条件を後置する。
- 「〜でないとは言い切れない」のような入れ子否定は言い換える。
- 例: 「〜の可能性がある」「条件次第で例外がある」。
- スタイルガイドの明示的な禁止・回避方針
- Google Technical Writing: Double negatives を避ける。[^
]
- Datadog Docs: “Do not use double negation”。[^
]
- OpenStack Docs: 明快な英語を推奨（否定の簡素化を含む）。[^
]
- Sumo Logic / Harness など、各社スタイルガイドでも回避が通例。[^
][^
]
-
テンプレ言い換え
- 「〜しないわけではない」→「〜する場合もある」
- 「〜でないとは言い切れない」→「〜の可能性がある」「〜と断定できない」
- 「必ずしも〜とは限らない」→「条件次第で例外がある」
さらに最適化：最小パターン集（変換レシピ）
-
if (!isNotEmpty(arr))→if (isEmpty(arr)) -
if (!(errors.length === 0))→if (errors.length > 0) -
if (!user.isNotAdmin())→if (user.isAdmin()) -
if (!(!ok))→if (ok)もしくは否定ごと削除 - 名前リファクタ例
-
isNotValid→isInvalid -
isNotOnTime→isLate -
notAuthorized→unauthorizedあるいはauthorizedを正に反転
-
参考: 肯定的ブール命名と可読性に関する知見。[^
][^
]
Lint／レビューでの検出（例）
- レビュー観点
- 条件式に
!が2つ以上出てこないか - 変数名に
notを含む関数やプロパティが無いか
- 条件式に
- ルール例（静的解析）
- 「二重否定を禁止」のスタイルルールを有効化。[^
参考文献（スタイルガイドと実務知見）
- Google Testing Blog: Improve Readability With Positive Booleans[1]
- Principles.dev: Logic should be in the positive[2]
- ESLint ルール: no-negated-condition[3] および Oxlint の解説[4]
- Datadog Code Security ルール: do not use double negation[5]
- Styra Regal ルール: double-negative（ポリシー言語 Rego のスタイル）[6]
- Java Code Geeks: Double Negatives — The Enemy of Clear Code[7]
]
チェックリスト
- 主語・述語の否定が二段以上に重なっていないか
- 結論（肯定/否定）が1文の前半で把握できるか
- 「可能性」「例外」「条件」を明示できているか
- 数量や事実で裏づけできているか
まとめ
二重否定は便利な婉曲表現だが、読み手の負荷や誤読のリスクがある。判断の核はシンプルに。ニュアンスは程度副詞や条件提示、定量情報で補い、必要なときだけ二重否定を選ぶのが安全策です。