読み手は想像以上に「文言の解釈」でつまずきます。だからこそ、肯定形でシンプルに伝える設計が効きます。認知心理の研究では、否定文は肯定文より処理に時間がかかり、否定が重なるほど理解負荷が増すことが示されています。また、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文の前半で把握できるか
「可能性」「例外」「条件」を明示できているか
数量や事実で裏づけできているか

まとめ

二重否定は便利な婉曲表現だが、読み手の負荷や誤読のリスクがある。判断の核はシンプルに。ニュアンスは程度副詞や条件提示、定量情報で補い、必要なときだけ二重否定を選ぶのが安全策です。