解剖 03 ── push の前に通す検査の構造

（2026年10月22日・表7）

結論

ぼくは、記事を組み立てて公開する作業まで AI（Claude Code）に任せています。公開してよいかを決めるのは、ぼくです。そのために、push（main へ送ること）の前後に、自動で止める検査を重ねました。この1枚は、その構造です。

送り先は2種類で、通る検査が違います。文書だけの変更（docs）は、5つの検査に全部通ったときだけ、承認なしで送れます。サイトの変更は、送る前に3つの検査と検品係の判定、送ったあとに本番確認があります。
本番確認は、ページごとに5項目（a〜e）です。
検査に関係なく、人の承認が要る線が別にあります。新しい記事と新しいツールページの公開、X の投稿文、費用が増える操作と、外部サービスの設定、作り直せない削除、承認の線そのものを変える決まりと、検査を弱める変更です。
検査の決まり自体も、この線の中に入れてあります。検査語や許可リストを、AI が黙って緩められないようにするためです。
検査のほうに穴が見つかった例が4件、検査が正しく止めて許可の形を人が決めた例が1件、記録にあります（下の表）。検査は、足して終わりにはなりませんでした。

部品の関係図

push の前後の流れを、順に並べます。上から下へ進みます。

順	何をするか
1	公開物を書き換える（作る係）。リントで、書き方の決まりを自動で検査する
2	サイトを組み立てる（build）。組み立てた出力が、入力より古くないかも見る
3	秘匿スキャン。送る差分と、公開される出力の全文を、検査語で検査する
4	検品係が、変更を読んで「通す」か「直す」を返す。外に出る文面は、下読み係も読む
5	人の承認が要る線に当たるものは、ここで止まる。当たらなければ push する
6	本番確認。公開されたページを、5項目で確かめる

文書だけの変更は、この道を通りません。専用のスクリプトが、次の5つを検査します。

docs だけの push の5つの検査

docs の変更は、公開されない内部文書です。そのぶん、次の5つを全部通ったときだけ、承認なしで送ります。1つでも外れると、何もコミットせず「停止点へ」と出して終わります（scripts/docs_only_push.py の頭）。

検査	何を見るか
① 許可リスト	変更したファイルが、許可リスト16件の中だけ。site/・scripts/・data/ など7つの場所が1ファイルでも入れば外れ
② 未 push のコミット	押し出していないコミットが0件。docs 以外のコミットを、一緒に押し出さないため
③ 私用情報	足した行に、私用のメールアドレス・ホームフォルダ名・ユーザーのフォルダの形が0件
④ リント	書き方の検査のエラーが0件
⑤ 版の行	版を持つ文書（運用の決まり・文体ガイド・記事の種類の一覧・企画書の本文）を変えたときだけ、冒頭の版が上がっている

③では、検査語の全部は当てません。docs は内部文書で、既存事業の名前などを含んでよいからです。当てるのは、私用情報の3つだけです。

ただし、決まりの文書の変更のうち、承認の線そのものを変えるものは、この5つに通っても、人の承認が要る線に当たります。承認の線に触れない文の直し（行の名前・整理・手順の直しなど）は、検品係が同意すれば止めずに送って記録に残し、チャットの AI（相談役）があとから確かめます。この5つは、通ってよいかではなく、止めるべきものを先に自動で弾く役です。

サイトの push の前と後

サイトを変える push は、docs だけの道より厳しくしました。公開されるからです。

検査	何を見るか
リント	公開物の書き方の決まり。エラーが1件でもあれば、直して検査し直す
秘匿スキャン（差分）	送るコミットの見出し・本文・足した行を、私用情報の3語で検査
秘匿スキャン（公開される出力）	組み立てた出力の全ファイルを、検査語23語で毎回全文検査。出力が入力より古ければ、「build し直す」と出して止まる
検品係	決まりに照らして、「通す」か「直す」。読むだけで、ファイルは変えない
本番確認	push のあとに、公開中のページを5項目で確かめる

秘匿スキャンで画像や録画は、ファイルの中の文字の区画だけを見ます。画像に描かれた文字は見ません。見えないものがあることを、先に決めてあります。

本番確認の5項目は、次のとおりです。

項目	何を見るか
a 反映	本番のページの全文が、手元で組み立てたものと同じ。違えば、30秒おきに最大3分待つ
b OG	カードに使う3つの値と、その画像が開ける
c 画像	ページが読んだ画像の合計と、最大の1枚。1枚の上限は300KB
d 内部語	ページの全文に、検査語が無い。送る前と同じ当て方
e 390px	スマホ幅の崩れの6項目が全部0。画面の幅が390でなければ、それだけで ×

どれかが × か「未反映」なら、「停止点へ」と出して止まります。内部版の本番確認は、サイトに出さない原稿（公開前の下書きなど）を対象から外し、外した件を記録に残します。

人の承認が要る線

検査に通っても止まるものを、先に決めてあります（運用の決まりの「判定に関係なく必ず止まるもの」）。

新しい記事と、新しいツールページの公開
X の投稿文
費用が増える操作、外部サービスの設定、作り直せない削除、承認の線そのものを変える決まりと、検査を弱める変更

決まりの変更には、検査を緩める変更も入れました。検査語を減らす、許可リストを広げる、リントの決まりを緩める、秘匿スキャンが止める場面を減らす、です。AI が、止められた検査を黙って緩めると、この構造の意味がなくなるからです。

ほかに、検査のエラー、安全判定に止められたとき、その日の一覧で「止まる」とした作業も止まります。

止まった箇所

検査が止めたものと、検査のほうに穴が見つかったものを、記録に残っている範囲で並べます。

日付	何が起きたか	どう直したか
10/5	秘匿スキャンを、差分の場所の一覧で決めていた。build が新しい入力を読むと、そこが穴になる	差分に site/ があるかにかかわらず、公開される出力の全文を毎回検査する形にした
10/5	全文の検査の試しを、取り出した別のフォルダだけで行った。実際に使うフォルダの dist にあった不要なファイルの写し3件を、見落とした	仕組みの試しは、実際に使うフォルダでも1回走らせる、を検品の基準に足した
10/13	本番確認の a が、ページの本文だけを比べていた。版の印の無い古い手元のビルドと本番を比べて、○にした回があった	ページの全文で比べる形にし、手元のビルドが古ければ本番を見る前に止めた（10/14）
10/15	手元のビルドの古さの検査が、朝の自動実行が書く受領票を見ていなかった。受領票が新しいと、全文では本番と違うのに、古いと分からなかった	本番確認の側で、受領票も入力に入れて古さを見るようにした
10/15	公開用の検査語が、ツールページに書いた Zenn の置き場の URL の、名前の部分に当たった	検査語は変えず、その形の URL の名前の部分だけを当てない許可を足した。決めたのはぼくで、画面で承認した

10/13 の行の直しは、内部版の本番確認だけです。公開版の本番確認は、今も main の中だけを比べます。最後の行は、検査が正しく止めたものを、決まりの変更として人が通した例です。止めたのは検査で、許可の形を決めたのは人でした。

表のほかに、検査ではなくスクリプトの作りが止めた例が1件あります。10/15 に、push の前の取り込みで、生成物の autostash（作業中の変更を一時退避して戻す仕組み）が食い違って止まりました。このスクリプトは、食い違いが起きたときに push せず、元の変更を残して止まります。

月の費用

追加の費用は0円です。

部品	月の費用	根拠
リント・秘匿スキャン・docs の5つの検査	0円	手元のファイルを読むだけで、外部のサービスを呼ばない
本番確認	0円	公開中のページを読むだけ

部品ごとの役割

部品	役割
リント	公開物の書き方の決まりを、設定のファイルから読んで検査する
秘匿スキャン	検査語のファイルから読んで、送る差分と公開される出力を検査する
docs だけの push のスクリプト	5つの検査に通ったときだけ、docs を承認なしで送る
本番確認	push のあとに、本番のページを5項目で確かめ、結果を記録に残す
スマホ幅の検査	390px と1280px で全ページを撮り、崩れを6項目で拾う
検品係	変更を読んで「通す」か「直す」を返す。読むだけ

関係する記録

解剖 01 ── 毎朝1本、X へ自動投稿する仕組みの構造
解剖 02 ── 毎朝の自動実行が「合っているか」を確かめる仕組みの構造
ツール「出したくない語スキャン」
ツール「本番確認」