CIで落ちる前に、同じ検査を手元で回す

🔢直す場所を決める前に、落ちた理由を数えた

感覚で手を入れる前に、まず何が何件落ちているのかを数えました。

開いたままの記事PRは42本ありました。そこで起きているCIの失敗を種類ごとに分けてみると、いちばん多かったのは構造や表記の決定論的な検査で18件。AIによる採点で落ちていたものは4件でした。

数えて分かったのは、落ちている理由のほとんどが「手元でそのまま再現できるもの」だったということです。ネットワークもクラウドも要らない。ファイルを読んで判定するだけの検査に、いちばん多く引っかかっていました。

それをPRを開いた後のCIで初めて知る、という設計になっていた。原因は検査の中身ではなく、鳴るタイミングの方にありました。

🧩検査を2つ持たない、というルール

手元用にもう一本書く——それがいちばんやりたくなる作り方で、いちばん危ない作り方でした。

前倒しすると決めたとき、最初に浮かんだのは「ローカル用の軽い検査を書く」でした。CIのものは重いので、同じことをする小さいスクリプトを別に用意する。手軽です。

でもそれをやると、検査が2つになります。2つになった瞬間から、片方だけ直して片方を忘れる日が来る。そして「手元は緑なのにCIは赤」が起きます。もっと悪いのはその逆で、手元だけ厳しくなって、直す必要のないものを直し始めることです。

なので、前倒し用のスクリプトは判定を一切持たないことにしました。やるのは、CIが呼んでいる本体をそのまま呼んで、結果を受け取ることだけ。検査の中身はひとつのまま、鳴る場所だけを手前に移した形です。

🔗手元に持ってきたからこそ足せた検査もあった

出典として置いたリンクが、今も本当に開けるのか。これはCI側では見ていませんでした。

記事には出典のリンクを置きます。そのURLが生きているかどうかは、実際に叩いてみないと分かりません。手元で回すようになったので、記事を出す前に一本ずつHTTPで確認するようにしました。

ここで、思っていなかった落とし穴を踏みます。ブラウザでは普通に開けるのに、こちらが何も名乗らずに叩くと拒否を返すサイトがあったのです。実際、あるサイトはブラウザの名乗りを付けると通り、付けないと403が返ってきました。

最初はこれを「リンクが壊れている」と読んでしまいました。危なかったのはその次で、検査の言うとおりに直すなら、私たちは正しい出典を記事から消すところだったのです。

ゲートの誤検知は、ただの雑音ではありませんでした。人を「正しいものを削る」方向へ動かします。検査を増やすときは、通してはいけないものを止められるかと同じくらい、止めてはいけないものを通せるかを見る必要がありました。

📚参考

「フィードバックを短くする」という発想自体は、ずっと前から語られてきたものです。

壊れた状態を長く放置しない、失敗をできるだけ早く知る、という考え方はMartin Fowler の継続的インテグレーションの解説に整理されています。今回やったことは新しい発明ではなく、その原則を自分たちの記事の工程に当てはめ直しただけです。

リンク検査で踏んだ落とし穴の背景については、MDN の User-Agent ヘッダの解説が参考になりました。何を名乗るかで応答が変わり得る、という前提を知らないまま検査を書いていたのが原因でした。

🧭まとめ: ゲートを増やすのではなく、同じゲートを早く鳴らす

前倒しでやったのは、新しい関門を作ることではありませんでした。すでにある関門を、出した後ではなく出す前に鳴らしただけです。判定は一箇所のまま、知るのを早くする。それだけで、承認の列に不合格が溜まらなくなりました。

もし同じことをやるなら、順番はこうだと思っています。まず落ちている理由を数える。数え終わるまで手を入れない。そして前倒しするときは、検査を書き直さずに、いま動いているものをそのまま呼ぶ。

手戻りを減らす工夫は、たいてい仕組みを足す形になりがちです。今回は、足さずに位置を変えるだけで済みました。