自動化を書いていると、いつのまにか「番人」が増えていきます。

送信する前に中身を検査する関数。対象が条件を満たしているか確かめる関数。危ないものを弾く関数。どれも「事故を防ぐために」書いたはずのものです。

先日、その番人がまったく仕事をしていなかったことに気づきました。しかも2つの、まったく別の理由で。

どちらも「エラーが出ない」タイプの壊れ方でした。ログはきれいで、処理は最後まで走り、結果も返ってきます。ただ、弾くべきものを1件も弾いていなかった。

同じ型は他の自動化でも起きるので、記録として残します。

起きたこと

複数のブログに機械的にコメントを送る仕組みを作っています。相手を選ぶ工程があり、そこには「送ってはいけない相手」を除外する関門を置いてありました。

ある日、候補の上位5件を人の目で確認したら、5件とも除外対象でした。関門を通ってきたはずなのに、1件も落ちていない。

ここで「除外条件が甘いのだろう」と考えるのが自然です。実際、最初はそう考えました。条件を足そうとしてコードを開き、そこで気づきました。

除外する関数は、どこからも呼ばれていませんでした。

型①：定義したのに呼ばれていない

関数はちゃんとありました。中身も正しく、単体で動かせば期待どおりに動きます。

def is_referral_blog(url):
    """本文に宣伝マーカーがあれば除外対象とみなす。"""
    ...

書いた本人（自分です）は、これを「実装した」と記憶していました。しかし呼び出しが1行もない。

さらに悪いことに、2つある経路のうち片方だけ、別の除外関数を呼んでいました。だから完全な無風ではなく、「たまに何か落ちている」状態に見えていた。これが発見を遅らせます。

なぜ気づけないのか。理由ははっきりしています。

番人は「何も弾かなかったとき」に何も言わない。

弾いたら「1件除外しました」と出ます。弾かなかったら、出力は静かなままです。そして「静か」は正常時とまったく同じ見た目をしている。

テストがあれば防げた、と言いたいところですが、この関数には単体テストがありました。関数の中身は正しかったから、テストは通ります。呼ばれていないことは、関数のテストでは絶対に検出できません。

型②：判定不能を「シロ」として通す

呼び出しを足して、これで直ったと思いました。もう一度動かすと、除外できたのは5件中1件だけでした。

出力を見ると、こう出ていました。

[WARN] 取得失敗 https://.../entry/... : IncompleteRead(0 bytes read)
[WARN] 取得失敗 https://.../entry/... : The handshake operation timed out
[WARN] 取得失敗 https://.../entry/... : Remote end closed connection

判定するには相手の中身を取りに行く必要があります。その取得が半分以上失敗していました。

そして関数はこう書かれていました。

def is_referral_blog(url):
    h = get(url)
    if not h:
        return None          # 判定不能
    ...
    return hits if hits else []

呼び出し側はこうです。

hits = is_referral_blog(r["url"])
if hits:
    continue                 # 除外

None は偽です。つまり「判定できませんでした」が「問題ありませんでした」として扱われていた。

取得が失敗した瞬間に、番人は黙って全部通します。しかも通信が不安定な日ほど、たくさん通す。いちばん危ない日にいちばん効かなくなる作りでした。

これを fail-open と呼びます。安全側に倒れないほうへ倒れる、という意味です。

なぜこの2つは同じ根から生えているのか

型①も型②も、表面的にはまったく違う不具合です。片方は呼び出し漏れ、もう片方は戻り値の解釈です。

ただ、見え方は完全に同じでした。

・エラーは出ない

・処理は最後まで走る

・出力は「候補が並んでいる」だけ

・除外0件と、除外する必要が無かった状態が、区別できない

つまり両方とも「守るものが無かったときと、守れなかったときが同じ見た目になる」という一点で同じです。

自動化の関門を書くときに本当に設計すべきなのは、条件式ではなくここでした。

対処：番人に3つの状態を持たせる

真偽の2状態で持つのをやめました。

・クロ：条件に当たった：落とす。理由を出す

・シロ：条件に当たらなかった：通す

・不明：判定できなかった：通すが印を付ける。そのまま次の工程へ進ませない

コードにするとこうなります。

if hits:                     # クロ
    dropped.append((blog_id, ",".join(hits)))
    continue
if hits is None:             # 🔴 不明をシロにしない
    mark = "⚠"
    title = "[未確認・判定できず] " + title

if hits: と if hits is None: を別々に書く。これだけです。ただ、書いていなければ永遠に起きません。

対処：落としたものを必ず出す

もうひとつ変えたのは、除外した件数と理由を必ず表示するようにしたことです。

-- 同業として除外 6件 --
   blog-a       r10.to, 従業員紹介
   blog-b       a8.net, px.a8
   blog-c       (同ブログの別記事で判明)

これが無いと、候補が減ったときに「今日はネタが少ない」と読み違えます。黙って減らすのは、黙って通すのと同じくらい危ない。

実際、この表示を足したことで「1回のスカウトで6件も除外している」＝除外対象がそれだけ多い環境だ、という事実が初めて見えました。関門を直す前は、その6件が全部素通りしていたわけです。

対処：呼び出しの存在そのものをテストする

型①はここが肝です。関数のテストでは検出できないので、ソースコードを検査するテストを書きました。

考え方は単純で、「main のソース文字列の中に、その関数の呼び出しが含まれているか」を assert します。

行儀の良いやり方ではありません。リファクタで関数名を変えれば落ちます。ただ、落ちてほしいのはまさにそのときです。名前を変えて呼び出しを消してしまう事故を、次に書く自分が起こすので。

具体的なテストコードは付録に置きました。汎用のテンプレートにしてあるので、そのまま自分の関門に当てられます。

まとめ

・関門は「ある」と「効いている」が別物。定義しただけの番人が実在する

・番人は何も弾かなかったときに何も言わない。静かさは正常と区別できない

・判定不能を真偽の2値に押し込むと、取得が失敗した瞬間に全部通る（fail-open）

・直し方は3つ。第3の状態を持たせる／落としたものを必ず出す／呼び出しの存在をテストする

・関数の単体テストは、呼ばれていないことを絶対に検出できない

「動いているように見える」は、自動化でいちばん高くつく状態でした。