本番確認を公開します ── 20回の確認で止まったのは7ページ、本当の不具合はスマホの幅の1ページだった

（一体記事・2026-10-12・表6・実物3）

結論

push のあとに、公開中のページを1ページずつ確かめるツール「本番確認」を公開します。本番確認は、公開したページが正しく出ているかの確認です。ぼくは2026年9月27日に、この作業をスクリプトにしました。10月10日までの記録に残る20回（のべ502ページ）で、止めたのは7ページです。そのうち本当の不具合は1ページで、スマホの幅で、押す部分の高さが足りませんでした。確かめたページの中に、本番に出ていなかったページはありませんでした。

本番確認で見ているもの

push が通っても、公開の仕組みの build（公開するページを組み立てる処理）が終わるまで、本番のページは変わりません。本番確認は、その build のあとに、公開中のページを1ページずつ開いて確かめます。

1つでも × か「未」があれば、止まります。直すのは人です。

20回の記録

内部版は、確かめた結果を、○ でも × でも1行ずつ記録のファイルに残しています。10月10日までに20行ありました。

止めたのは、20回のうち2回です。

残りの18回は、全部のページが ○ でした。

20回に含めていないものが2つあります。9月27日の初回は、結果の書き方に穴が見つかり、その日の手元の変更ごと捨てたので、結果が残っていません（書き先を作り直したのは翌日の9月28日です）。記録を残さない試しの回は、回数も結果も残らない作りです。

本当の不具合だった1ページ（10月2日）

10月2日の4時57分に、解剖 02 ── 毎朝の自動実行が「合っているか」を確かめる仕組みの構造の末尾にある箇条3行を、行まるごとのリンクにして push しました。4時59分の本番確認で、このページだけが止まりました。

実物1: 10月2日4時59分の記録の、要約と詳細（原文）

× 1／48 ページ（2026-10-02 04:59）

/kousei/morning-receipt/ e: 押す部分が 44px 未満 1

文の中の語のリンクは、この項目では数えません。箇条の1行がまるごとリンクだと、押す部分は、その行の高さか幅になります。足りなかったリンクの数は1つでした（どのリンクかは、記録に残していません）。

5時01分に、リンクを文の中の語2か所に置き直し、行まるごとのリンク3本は元の字に戻して push しました。同じ5時01分に、このページだけを確かめ直して通りました。止まってから、およそ3分です。

誤って止めた6ページ（9月28日）

9月28日の19時08分は、サイトを組み立てる仕組みを変えた push のあとで、公開中の46ページ全部を見た回です。6ページで止まり、6ページとも、確かめる側が誤って止めたページでした。

5ページは、d（出したくない語）の確かめでした。読者向けの文にも普通に出てくる語と、ほかの語の一部に当たる短い英字の語を、出したくない語に入れていたためです。中身は出したくない語スキャンを公開します（2026年10月5日）に書きました。

残りの1ページは、a の本文の比べ方の誤りでした。そのページの本文には、問い合わせ用のメールアドレスが1つあります。ぼくのサイトは Cloudflare Pages で出していて、独自ドメインでは、Cloudflare のメール保護（Email Address Obfuscation。ページの中のメールアドレスを、ボットに読まれにくい形のリンクに書き換える機能）が、そのアドレスを書き換えていました。手元の出力と一字も同じにならないので、3分待っても「未」のままでした。ページそのものは、本番に出ていました。

Cloudflare の説明では、この機能は登録したときに自動で有効になります。ドメインごとの設定です。同じページを、Cloudflare Pages が最初に付けるアドレス（pages.dev）で開くと、アドレスは書き換わっていませんでした（2026年10月11日に確かめた）。

実物2: 10月11日に、独自ドメインのページから取り出した、書き換え後のリンク（属性の値の長い文字列は「…」で略した）

<a href="/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="…">[email&#160;protected]</a>

直し方は、比べる前に、手元と本番の両方の本文から、@ を含む語と、メール保護のリンクを外すことにしました。19時26分に、止まった6ページだけを確かめ直して、6ページとも通りました。最初の止まりから18分です。

確かめたページの中で、本番に出ていなかったページはありませんでした。本番確認を作る前の9月24日には、Cloudflare Pages の build が途中で失敗したことが1回あります（やり直しで直りました）。

内部版から公開版へ

内部版は、ぼくのサイトの書き方に合わせて作っていました。公開版では、ほかのサイトでも使えるように、次を変えました。

ほかに、d（出したくない語）・画像の上限を build の設定から読む作り・朝の自動実行に結果を渡す仕組みを外しました。記録のファイルは、渡したときだけ書きます。

公開版で確かめたこと

10月11日に、公開版を7回走らせました。止まる回と通る回の両方です。

6回目の「未」は、手元の出力が本番より古かったためです。手元の出力は、その日の17時18分に push した版から作っていました。走らせる2分前の18時17分に、別の作業で、ほかの記事（note転載キットを公開します ── 初めて使った日、AIの「そろっています」の下に空白が2つあった）に追記を1段足した版が push されていて、本番はその追記の入った版になっていました。出力の詳細に出た最初の違いの場所も、その追記の頭（本番「追記（2026年10月11日）: …」）でした。手元の出力をその版から作り直した7回目は、51ページとも ○ でした。

実物3: 2回目の出力（抜粋。表の1行と、詳細の1行〈行の頭の「- 」は外した〉と、最後の1行）

| /posts/hello/ | 未 | 未 | 未 | 未 |

/posts/hello/ a: 3分待ってもそろわない。200 だが <main> が手元の出力と違う。最初の違いは 27字目のあたり: 本番「/h1> <p>まめ太が、棚を1つ作った日の記録です（架空）。</p> <h2 」／手元「/h1> <p>まめ太が、棚を2つ作った日の記録です（架空）。</p> <h2 」

[prod_check] 1ページのうち 1ページで止まった（未 1・× 0）（2026-10-11 18:18・Chromium 起動せず）

「未」のページはブラウザで開かないので、最後の行の Chromium の版は「起動せず」になります。

6回目と7回目の51ページには、9月28日に「未」で止めた、メールアドレスのあるページも入っています。今の比べ方では、2回とも ○ でした。

配布物と、できないこと

配布先は GitHub の haif-tools。中身は本体（prod_check.py）・スマホの幅の6項目の判定（check_390.js）・架空のサイト（2ページ）・README の4つです。使い方は①Playwright と Chromium を入れる ②push して、build が終わるころに、サイトの URL と手元の出力を渡して走らせる ③止まったら詳細を見て直し、止まったページだけをもう一度確かめる。

できないこと: 「未」は、build の失敗と遅れを見分けません。手元の出力と比べるのは main の中だけです。見た目と、SNS のカードの出方は見ません。スマホの幅は 390px だけです。出したくない語は見ません。外れた所は直さず、push を止める設定も入っていません。公開中のサイトで確かめたのは、Cloudflare Pages で出しているぼくのサイトだけで、環境は macOS だけです。詳しくはツールページに書きました。

この記事のツール

• 配布物（GitHub）: github.com/mhitori/haif-tools/tools/prod-check
• ツールページ: 本番確認
• push の前に使うツール: 出したくない語スキャン