先に結論をお伝えします。この日つまずいたのは、検査が甘かったからでも、厳しすぎたからでもありません。
先にお伝えしておくと、これは社内の開発運用の内側で起きたことで、お客様の案件ではありません。公開したものが壊れたわけでも、誰かをお待たせしたわけでもない。困ったのは自分たちだけです。
どんな一手間だったか
うちの開発用の環境には、作業が一区切りつくたびに、テスト一式が自動で走る仕組みが入っています。通れば次へ進める。通らなければ差し戻されて、その区切りを終えられません。
プログラムを書き換える作業では、区切りごとにテスト一式を通してから次へ進む関門として動きます。
かかる時間は、社内の記録では一回あたり約三分と残っています。今回この記事のために測り直したわけではないので、実測ではなく記録に残っている数字として書いておきます。
作りとしては、止まり続けないための逃げ道も最初から用意されていました。同じ区切りで三回続けて差し戻したら、四回目は結果にかかわらず通す。延々と止められて仕事が進まなくなる事態は、設計した人もちゃんと想定していたわけです。
ただ、この日の話にその逃げ道は出てきません。検査は落ちていないからです。痕跡に残っている回は、五十件を超える項目が全部合格しています。差し戻されて止まったのではなく、合格を待っていた時間でした。
その日の仕事は、コードではなかった
八月一日、うちがやっていたのは、すでに書き上がっている原稿をSNSへ順番に出していく作業でした。プログラムの変更は伴いません。出したものを一つずつ元のページで照らし合わせて確かめ、記録に残す。それだけの作業です。
それでも検査は走りました。作業の区切りごとに、テスト一式が最初から最後まで。
これは記憶ではなく、痕跡が残っています。検査が結果を書き出すファイルがあり、その最終更新は八月一日の十四時十三分でした。原稿を出していた時間帯とちょうど重なります。
つまり検査は正常に動き、痕跡に残る回では五十件を超える項目がすべて合格していました。プログラムを変えない運用作業でも、テスト一式が走っていたのです。
なぜ免除されなかったのか
この仕組みには、免除の分岐もちゃんと入っています。変更が何も無ければ、検査は省かれる。
問題は、その「変更が無い」の判定でした。見ていたのは、仕組みが管理対象にしているファイルに、まだ確定していない差分があるかどうか——それだけです。その差分がプログラムなのか、記録やメモや下書きなのかは、区別していませんでした。
運用の作業でも、私たちは記録を書きます。何時に何を出したか、何を確かめたか。書けば差分は出ます。差分が出れば、検査は「変更あり」と判断して走り出す。
厳しすぎたのではありません。相手を見分けていなかったのです。「何か変わったか」で発動を決めていたので、「何が変わったか」の区別がつかなかった。
約三分でも、一日の合計は測っていなかった
その日、完成済みの原稿を出し終えるまでに、約一時間半かかりました。
ただ、検査だけを犯人にするのは正確ではありません。社内の記録は原因を四つ挙げていて、検査はそのうちの一つです。残りの三つは、操作を一手ずつ細切れに実行していたこと、一時的な設定を付け外しして空振りしていたこと、表示のされ方をその都度調べ直していたことです。どれが何分を占めたかまでは記録が無いので、内訳は書けません。検査が何回走ったかも記録に残っていないので、掛け算で出せる形の数字もありません。
それでも、この件がはっきりさせたことが一つあります。一手間の重さは、一回の長さでは測れないということです。約三分なら待てます。仮にそれが一日に十回走れば、単純計算で約三十分になります。重さを確かめたいなら、「一回の所要時間」「一日に走った回数」「待っている人の数」を別々に記録して、はじめて合計が見えてきます。私たちは、その回数を記録していませんでした。
私たちがやったのは、条件を絞ることではなく、止めることでした
この待ち時間に対して、私たちがやったのは、発動条件を絞ることではありませんでした。スクリプトの冒頭に「何もせず終わる」一行を足して、仕組みごと止めたのです。人の判断で、しかも一度ではなく繰り返し出た指示として記録に残っています。
正直に言えば、これは対処であって、直したことにはなっていません。
そして、そこへ至るまでのあいだに、同じ目的で試していたことがもう一つありました。設定を書いたファイルを一枚、作業場所に置く方法です。結局は本体を直接止める形で決着したので、その一枚は用済みになりました。ただ、置いたままになっていたのです。
止めるために置いた一枚が、別の検査を三度止めた
同じ日、こちらは別の話です。その日の作業のまとまりを共有の保管場所へ送ろうとしたところ、三回続けて拒まれました。止めたのは、その作業とはまったく関係のない自動チェック一件でした。
原因の見当は、最初から外れていました。まず、同時に走っていた別の作業とぶつかったのではないかと疑いました。実測して違いました。次に、別の対象を調べているのではないかと疑いました。これも実測して違いました。
行き着いたのが、さきほどの一枚です。検査を止めるために置かれ、別のやり方が通ったことで、すでに用済みになっていたファイルでした。
そのチェックは、作業の前と後で場にあるものを照らし合わせ、勝手に増えていないかを見る作りになっていました。ところが、照らし合わせるときに参照する条件が途中で変わるため、始めた時点では対象外だったこの一枚が、終わった時点では対象に入る。前と後が合わない。だから失敗する。何も悪さをしていないファイルが、置いてあるというだけで三回、仕事を止めていたわけです。
消したら、通りました。
この一枚は、別のやり方で検査を止めたあとも残り、二つの見当違いを実測でつぶすまで、原因だと分かりませんでした。
まだ直していません
止めたことの副作用は、自分たちで書き残しています。この設定は環境をまたいで共有されるものなので、この変更が正式に取り込まれれば、本来この検査が必要な実装作業の側でも効かなくなる。そう書いてありました。
その取り込みは、この記事を書いているあいだに起きました。夕方に確かめたときは、まだ入っていませんでした。その一時間ほどあとに、停止を含む変更は正式な保管先へ入っています。
ややこしいのは、止めたときにファイルへ添えた書き置きです。そこには「この変更はコミットしない」と書いてありました。ところが実際には取り込まれています。書き置きと、取り込みのときに書いた説明文の内容が食い違っているので、いまどこまで検査が止まっているのかは、私たちの記録からは言い切れません。その場の対処だけして、扱いを決めていなかったことの結果です。
本来やるべき直し——検査が走る条件を、作業の種類で見分けるようにすること——にも、同じ日のうちには手をつけていません。その日の対策として記録されているのは、停止、別件の照合処理の改善、準備の手順をまとめることの三つで、条件を絞る話は入っていません。
この記事は、八月一日時点の状態のまま書いています。きれいに片づいた話ではありません。
お手元で確かめられる三つのこと
一つ目。そのチェックが掛かる条件を、作った人に一度聞いてみてください。聞き方は「どういうときに動きますか」ではなく、「何か変わったら動くのか、これが変わったら動くのか、どちらですか」です。前者なら、対象外の仕事まで拾っている可能性があります。
二つ目。一手間の重さを、一回の秒数ではなく一日の合計で見てください。一回の所要時間、一日に走る回数、待っている人の数。この三つを別々に書き出すと、感覚で「まあ待てる」と言っていたものが、数字として見えてきます。
三つ目。回避のために一時的なものを置くなら、置いた時点で、何を・何のために・いつ戻すかを書き残してください。今回の一枚のように、用が済んだあとも残ることがあります。戻すときは、それを前提にしている作業が無いかを確かめてからにしてください。
外された安全装置は、効かない装置になる
たとえ話をひとつ。台所の火災報知器が、料理のたびに鳴るとします。住人が電池を抜いてしまえば、その報知器は厳しくも甘くもなく、ただ効かない装置になります。
私たちがこの日やったのも、それに近い対処でした。抜いた理由は説明できるし、記録も残しました。それでも、八月一日の時点で、この検査は止まったままです。
これはHaruIroAIで起きた一件で、どのチェックも同じ道をたどるという話ではありません。ただ、うちでは実際に、掛ける相手を見分けないまま置き続けた検査について、現場の側から止める判断が出ました。
次にやるべきは、検査そのものを厳しくすることでも、外したままにすることでもなく、掛ける相手を分けることだと考えています。実装の作業には残し、記録を書くだけの作業では走らせない。まだ直したとも、これでうまくいくとも書けませんが、いまはそこを直す番だと思っています。
この記事を書いた人
この記事の作り方
この記事は、構成・一次記録の照合・文章化にAIを使用し、HaruIroAIの編集ルールと社内の一次記録（自動チェックの現行コード、運用台帳、検査が書き出した実行証跡、バージョン管理の履歴）に基づいて作成しています。記事中の状態は2026年8月1日時点で確認したものです。社内で使っているツールの名称、保存場所、作業の識別番号は、本題と無関係なため記載していません。内容は公開前に人が最終確認しています。