- ブラウザURL入力
- DNS名前→IP
- ルータ経路選択
- ロードバランサ振り分け
- Nginx受け口
- アプリ処理今ここ
- DB保存
このコースの芯は、書かなかったことは実装した誰かが黙って決める、でした。今回は条件付きの文の「条件が成り立たない側」という、いちばん見落としやすい書かれていない場所を見ます。
まず結論
「〜のとき、〜する」という文は、条件が成り立ったときの振る舞いだけを決めます。条件が成り立たないときの振る舞いについては何も言っていません。
書かなかった側は消えずに残り、実装した人か AI が黙って決めます。「すべて〜なら」の条件では、対象が0件のときに条件が成り立つかどうかも、依頼文ではなく実装の側で決まります。
「明細の金額がすべて100を超えていたら通知する」という依頼を、AI が `items.every(x => x > 100)` を条件にして実装しました。明細が0件のとき、この条件は何になるでしょうか。
当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。
「P のとき Q する」が決めているのは、P が真の側だけ
このコースの芯は「仕様に書かなかったことは、消えずに残り、実装した誰か(人でも AI でも)が黙って決める」でした。書かれていない場所は、書いた本人がいちばん気づきにくい場所でもあります。その代表が、条件付きの文の「条件が成り立たない側」です。
「在庫が0になったら通知する」という依頼文に、実装が違反したと言える場面を数えてみます。
在庫が0か 通知が出たか 依頼文に違反したかはい はい していないはい いいえ 違反したいいえ はい していない(書かれていない)いいえ いいえ していない(書かれていない)
違反と言えるのは「はい・いいえ」の行だけです。これは含意 p→q が偽になるのは「前提pが真で結論qが偽のとき」だけ、という真理値表と同じ形です。p が偽の行では、q が何であっても文は偽になりません。
ここを「条件が偽なら文は偽」や「条件が偽なら通知は禁止」と読むと誤りです。条件が偽のとき、文は違反されようがない。つまり何も言っていません。 在庫が5のときに通知を出すか出さないかは、依頼文の外に残ったままで、実装した側が決めます。
- ・違反と言えるのは「P が成り立ったのに Q が起きなかった」ときだけ
- ・P が成り立たない側の振る舞いは、禁止も許可もされていない
EARS は、読み方を文書の側で宣言した
要求文の書き方を型にした EARS の論文(Mavin ら、RE'09)は、この読み方を言葉で宣言しています。§4.1 で、前提条件・引き金・応答の並びについてこう書きます。
The system is required to achieve the stated system response if and only if the preconditions and trigger are true.
§4.3 は、事象で起動する要求の例文に同じ読み方を当てます。
For example: “When continuous ignition is commanded by the aircraft, the control system shall switch on continuous ignition”. This system response is required when and only when the stated event is detected at the boundary of the system.
「そのときだけ」と宣言したことで、指令が無いときに連続点火が求められないことは決まりました。けれども原文の語は required(求められる)です。してはならない、とは書いていません。 求められないことと禁止されていることは別物です。
この例文1つだけを見ても、指令が無いときに連続点火を切るとは書かれていません。すでに点いている点火をどうするかは、この文の外に残っています。EARS が決めたのは読み方までで、条件の外の振る舞いまでは決めていません。
EARS 論文 §4.3 の「この応答が求められるのは、事象を検出したとき、かつそのときだけ」(訳)という文は、事象が無いときについて何を言っていますか。
条件が成り立つかどうか自体も、書かれていないことがある
書かれていない場所は、条件が偽の側だけではありません。その条件が成り立つのかどうかを、依頼文が決めていない場面があります。
「明細の金額がすべて100を超えていたら通知する」。明細が3件なら、誰が読んでも判定は同じです。では明細が0件なら、「すべて100を超えている」は成り立つでしょうか。
依頼文はこれについて何も言っていません。「0件なら何も起きないはず」と思っている依頼者もいれば、「すべて」を数学の量化子として読む実装者もいます。どちらを選んだかは、次の具体例のように実装の1行で決まり、誰にも報告されません。
JavaScript の every は、空配列について決めてある
every の結果を Node で実行した生出力です(l4-empty.mjs、ローカル1回目。4回とも同じ結果でした)。
v24.21.0 icu 78.3[].every(x => x > 100) = true[].every(x => x < 100) = true[].every(() => false) = true[].some(x => x > 100) = false[].some(() => true) = false[,,].every(() => false) = true (holes, length 2)[200].every(x => x > 100) = true [50].every(x => x > 100) = false
空配列の every は、述語が何であっても true です。Docker の node:20-alpine(Node v20.20.2)でも同じでした。
これは実装の偶然ではありません。ECMA-262 の 23.1.3.6 は、手順の中でループを要素の数だけ回し、途中で false が出なければ最後に Return true. に届くと定めています。空配列ではループが1回も回りません。注記(Note 1)はこう明言しています。
every acts like the “for all” quantifier in mathematics. In particular, for an empty array, it returns true.
JavaScript は決めてあります。黙っていたのは依頼文のほうです。 依頼者は0件のときを決めないまま、JavaScript の決定を知らずに受け取りました。
同じ依頼文から、0件を除外する実装も書けます。手元で確かめると、結果は逆になりました(macOS の Node v24.21.0 と Docker の node:20-alpine で同じ)。
条件式 出力items.every(x => x > 100) trueitems.length > 0 && items.every(x => x > 100) false
どちらも「すべて100を超えていたら」を満たす、正しい実装です。どちらになるかは、書いた人の選択で決まります。
「明細がすべて100を超えたら通知」を every で実装し、明細0件で通知が送られました。書かれていなかったのはどこですか。
EARS の点火の例文
指令を検出したときだけ、連続点火が求められると宣言しています。指令が無いときは求められませんが、点いている点火を切るかどうかは、この1文には書かれていません。
場面 この1文が言っていること指令を検出した 連続点火を求める指令が無い 求めない(禁止ではない)指令が無く、点いている 書かれていない
「明細がすべて100を超えたら通知」
明細が1件以上なら判定は誰がやっても同じです。明細が0件のときに条件が成り立つかどうかは依頼文に無く、every を選んだ時点で JavaScript の決定(true)が入ります。
場面 依頼文が言っていること全件が100超 通知する100以下が1件以上 何も言っていない明細が0件 条件が成り立つかも書かれていない
片方は航空エンジンの要求文、片方は業務アプリの通知です。どちらでも、書かれていない場所を最終的に埋めているのは誰でしょうか。
表の「書かれていない」「何も言っていない」の行で、実際の振る舞いを決めたのが何かを探してください。
この章のまとめ
- 「P のとき Q する」が違反されるのは、P が成り立ったのに Q が起きなかったときだけ。含意 p→q の真理値表と同じ形。
- P が成り立たないときの振る舞いは、禁止も許可もされていない。書かれていない側は実装が決める。
- EARS 論文は「応答が求められるのは条件が成り立つとき、かつそのときだけ」と読み方を宣言した。求められない ≠ 禁止。
- 「すべて〜なら」では、0件で条件が成り立つかも依頼文が決めていないことがある。
- ECMA-262 は空配列の every を true と明記している。黙っていたのは JavaScript ではなく依頼文の側。
- 条件を書いたら、条件の外と、0件のような端の扱いを書くか、書かないと決めたことを書き残す。
自分の現場で確かめる
読んだだけでは身につきません。手元の環境で実際に見てみてください。
理解度チェック
読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。
「在庫が0になったら通知する」という依頼文に、実装が違反したと言えるのはどの場合ですか。
用語集(3語)
- 条件付きの文
- 「P のとき Q する」の形の文。P が成り立つときに Q を求める。P が成り立たないときの振る舞いは、この文だけでは決まらない。
- 含意 (p→q)
- 「p ならば q」。偽になるのは p が真で q が偽のときだけで、p が偽なら q が何であっても真になる。
- EARS
- Easy Approach to Requirements Syntax。要求文を決まった型で書く方式。2009年の論文は、応答が求められるのは前提条件と引き金が成り立つとき、かつそのときだけ、という読み方を宣言している。
出典(一次ソース)
- Mavin, Wilkinson, Harwood, Novak, “Easy Approach to Requirements Syntax (EARS)”, 17th IEEE International Requirements Engineering Conference (RE'09), pp. 317–322, 2009(§4.1・§4.3、p. 319) ↗
- ECMAScript® 2027 Language Specification, Draft ECMA-262 / September 20, 2026 — 23.1.3.6 Array.prototype.every(2026-09-24 取得。節番号はドラフトのもの) ↗