毎月一号、自分たちが壊した箇所を書く——何が起きたか、本当の原因は何か、そこから何を規則にしたか。見栄えのいいものだけを選びはしない。一件も挙げられない一覧こそ、信用すべきでないものだ。
対象期間は 2026 年 7 月 18 日から 8 月 16 日まで、30 日間。
これは自分たちがぶつかった壁の一覧である。この刊行物は毎日、自分たちのシステムで作っている。
壊れたときにどう見えるのか、気づくまでどれだけかかったのか、直ったのか——すべてここに書く。
数字が大きいのは意図的である。 これは「うちは安定しています」という宣伝物ではなく、
「何も隠さない」という証書のほうだ。毎日自走するシステムが 30 日で失敗シグナルを二千数百回出すのは
正常であり、異常なのは一件も事故を挙げられない一覧のほうである。
この 30 日で 43 件の事故を逐条で挙げた。内訳は修正済み 21 件、未修正 17 件、
そしてシステム自身が吸収した 5 類型。以下の五件は同じ形で最後まで書く——
何が起きたか → 本当の原因 → そこから立てた新しい規則。
何が起きたか:8 月 16 日、品質審査を通過した中国語の深掘り記事が、作業ディレクトリにしか
存在せず保存されていなかった。ディレクトリを整理した際にそれが黙って旧版に戻り、
6.7 時間、何の警告も出なかった。午後のサイト再構築は、そのまま旧版を公開した。
本当の原因:同じ作業ディレクトリで複数の作業が同時に動いており、バージョン管理ツールの
コマンドは——退避も復元も切り替えも——「自分が直した数行」ではなくツリー全体を動かす。
その日の午後、「変更をいったん退避する」コマンド一回が 230 個のファイルを巻き取り、
戻せたのは 1 個だけだった。
新しい規則:①品質審査を通った完成稿はその場でバージョン管理に入れる。作業ディレクトリにしか
ない完成稿は認めない。②出荷前に「これから出すファイル」と「審査を通った版」を機械で突き合わせ、
食い違えば赤にして止める。③自分の変更分だけを送るときは、版を固定した正式手順を通す。
構造上、他人の作業を巻き込めない。
何が起きたか:同じ日、公開中のサービスから機能が二つ、3.5 時間まるごと消えていた
(読者アンケートが書き戻せない、外部向けの口が一つ存在しない)。
ドリフト監視はその間ずっと「同期中」と表示し、赤は一つも出なかった。
本当の原因:監視が問うていたのは「ソースが変わったか」だった。ソースは実際に変わっていない。
入れ替わっていたのはソースから作られた成果物のほうである。
入力だけを測って出力を測らないのは、構造的な死角そのものだ。
新しい規則:監視の判定基準を「入力は変わったか」から
「前回自分が作り出したものは、まだ同じ場所にあるか」へ変えた。
成果物が消えていれば、入力が動いていなくても赤にする。
何が起きたか:同じ日の夜、純粋に検証目的で行ったビルド二回が、そのまま本番として公開された。
だれも公開ボタンを押しておらず、保存もしておらず、19 本ある品質チェックは一本も通っていない。
本当の原因:ビルド成果物そのものが配信元だった。あいだに出荷の関門がなく、
「作る」と「出すと決める」が工程上ひとつの行為になっていた。つまり手が滑れば、それが公開になる。
新しい規則:出荷来歴チェックを一枚挟んだ。版の刻印が実際の中身と合わない、
あるいは作業ディレクトリが汚れている場合は差し替えない。
「作る」と「出すと決める」は以後、別々の行為である。
何が起きたか:社内向けの日報が、この 30 日のうち 16 日、届いていなかった。
機械は毎日 12:00 に照合し、毎日その一件を記録していた——そしてその記録を受け取る者がいなかった。
本当の原因:照合は動き、記録も残っていたが、**その記録の受け取り手として指名された役割が
一人もいなかった**。警報は鳴っていた。ただ、空の部屋に向かって鳴っていた。
だからこの一覧を作った当日になっても、その 16 日が故障なのか意図的な停止なのかを答えられなかった。
日ごとの原因を誰も突き止めていなかったからである。
新しい規則:止められたもの、弾かれたもの、記録されたものには必ず行き先と受け取り手を付ける。
受け取り手のない記録は処理済みとみなさない。この一覧を作ること自体がこの規則の最初の産物だった——
事故を並べる作業は、鳴りつづけているのに誰も出ていない鈴を探す作業でもある。
何が起きたか:以前「グラフが改竄されたように見える」事故があり、防御を一枚作った——
正当な改訂はデータの中で「誰が変えたか」を自己申告する、というものだ。
防御自身の検査は全部緑で、本番のデータにもその欄は確かに入っていた。
だが画面はそれを最後まで表示しなかった。結果、同じ問題が二度目に起き、
利用者は二度目も「データが改竄された」としか読みようがなかった。
本当の原因:受け入れ判定の終点が、利用者の目ではなくデータ層に置かれていた。
緑ランプが測っていたのは自分たちが何をしたかであって、読者が何を見たかではない。
新しい規則:防御の受け入れ判定の終点は必ず「利用者の目に見えること」に置く。
データにはあるが画面にない状態は、未完成とみなす。
今月の主軸は四つ——ツリー全体の巻き戻し、検査を経ない出荷、同一ファイルの衝突、
他人の仕掛品による送信の巻き添え。四つとも当日中に防御が入った。
だがそのうち三つは症状を塞いだだけで、根本は塞いでいない:
間違えている点は手つかず;
未修正 17 件はすべて、見えている・起票されている・担当の番号がある。
状態は「まだ収束していない」であって「わかっていない」ではない。
修正済みの 21 件だけを報告せずにここまで書くのは、「症状は直った」と「もう起きない」が
別物だからであり、このシステムを使うかどうか考える人には、その区別がついていることを
知ってもらう必要があるからだ。
最後に書いておくべきこと:上に読んだ 43 件は、いくつもの自動防御が受け止めたあとの残量である。
同じ期間に、送信時のロック競合は自動再試行が千回以上受け止めた;
同型のシグナル七百件あまりは連鎖ミュートされ、ひとつの原因が診断待ち行列を溢れさせるのを防いだ;
成果が本当に重なった百数十回は、強制的に統合せず隔離領域にそのまま置いて人の判断を待った;
サービス利用枠の上限に達した 6 回は、途中で焼き切れる前に自動で停止・切り替えを行った;
基準に届かない原稿 13 本は送信前に止められた。
**システムの信頼性とは、壊れないことではない。壊れたときに何かが受け止めるかどうか、
そして受け止められなかったときに誰かが書き留めるかどうかである。**
この月次要約は、その後半の証拠にあたる。
1. 「失敗シグナル二千数百回」はシグナル数であって事故数ではない。
ひとつの原因が数百件を吐くことがある。本号の 43 件は人手で束ねたあとの事故数であり、
二つの数字は互いに導けない。
2. 自己修復の分類記録は 8 月 6 日以降しか揃っていない。それ以前は他の記録からの再構成であり、
過少である可能性がある。
3. 教訓ファイルの日付は保存日時ではなく本文中の日付を採っている——8 月 16 日に古い教訓が
まとめて保存されており、保存日時で数えると全部その日に計上されてしまう。
4. **「修正済み」とは、番号があり、直し方があり、再発検査があるという意味であって、
「もう起きない」ではない。** 上の「直せていないもの」に、症状だけ塞いだ三件を明記した。
以上は本サイト自身の稼働記録であり、いかなる成果・品質の保証でもなく、将来の結果を示すものでもない。