デルタメモ

AI開発

機械チェックは経路に固定する—『投稿前ゲート』と呼ぶな

任意チェックは飛ばされる。儀式名は作業を止める。安価な機械チェックとガイドのA→B→Cを混ぜない。

品質の不合格例が分かっても、「公開前に見てね」だけでは再発します。任意の手順は飛ばされるからです。一方で、安価なチェックを「投稿前ゲート」と呼ぶと、情報修正のcommit／deployまでガイド投稿の儀礼に見え、作業が止まります。放置すると、同じ不合格が本番に戻るか、直せるのに儀式モードで止まります。読み終わると、判断基準・機械チェック・経路固定の三層と、呼称の切り分けで合格／不合格を判定できます。

この記事でわかること

状況

公開物（記事、メモ、本番ビルド）には、すでに不合格の型があることが多いです。例:

是正のたびにチャットで直しても、次の投稿経路が機械チェックを通らなければ、同じ不合格がまた出ます。逆に、情報や障害の一行直しで「まず投稿前ゲートを回します」と宣言すると、本作業が進みません。

失敗1：任意チェックに頼る

状況: READMEやチャットに「公開前に確認」とだけ書く。実行されない。

悪い例: 「コミットメッセージにpassと書け」だけ。週次の手動レビューだけ。エージェント向けメモに「忘れずに」。

良い例: 実際にコマンドが走り、failならコミットやデプロイが止まる。普段使う公開経路の手前で止まる。

合格条件: 普段使う「公開・ビルド・取り込む」入口が、機械チェックなしでは完了しない。

失敗2：機械はあるが経路が別

状況: 緑のビルドとは別jobで、本番デプロイは別経路のまま。ローカルの近道で本番へ出る。

悪い例: CIは通るが、pages:deploy や定期取り込みはチェックを経由しない。本番だけ見て、プレビュー／定期取り込みは素通し。

良い例: ビルド・デプロイ・定期取り込み・「公開する」操作が、機械チェックを必ず経由する。迂回コマンドを残さない。

合格条件: 不合格のままdistが出る、本番に載る、自動コミットされる、がない。

失敗3：判定が曖昧／エージェント例外

状況: fail条件が文章だけで、機械が落とせない。「今回は小さいから」とチェックを飛ばしてpushする。

悪い例: 規範だけ更新して、ビルドもデプロイも取り込みもチェックを通らない。黙って飛ばす。

良い例: 同じ原稿でもう一度走らせると、同じpass / failになる。機械が落としている理由が、公開チェックリストの項目と対応する。「小さい変更だから」も例外にしない、とrulesに書いてある。本当に飛ばす必要があるなら、誰が・いつ・なぜかを残す。

合格条件: 判定が再現できる。人が読める規範と一致する。例外が文書化されている。エージェントも同じ規則。

失敗4：儀式名で作業を止める

状況: check:prepublish は安価なローカルスクリプトなのに、「投稿前ゲートを回します」と宣言する。情報・障害・ingestの修正後のcommit／deployでも、ガイド投稿のA→B→C全体のように振る舞う。

悪い例: 「ゲート回すな」をチェック自体の禁止と解釈する。逆に、デプロイするだけでチャットから儀式起動する。rulesの見出しが「投稿前ゲート」のまま。

良い例: 呼び方は 機械チェック または check:prepublish だけ。安価なら経路内・必要時に実行してよい。ガイドを draft: false／公開するときだけ、A→B→C→機械チェックの直列を回す。

合格条件: コマンド名／役名が儀式総称になっていない。情報修正のデプロイでA→B→Cを始めない。チェック実行＝悪、にも振らない。

三層で固定する

芯は次の三つです。どれか一つだけでは弱いです。

  1. 判断基準: 何が不合格か（並記テスト、汎化、日付の正など）。人が読める規範
  2. 機械チェック: 同じ不合格をスクリプトやCIでexit非ゼロにする（例: npm run check:prepublish）
  3. 経路固定: ビルド・デプロイ・定期取り込み・「公開する」操作が、機械チェックを必ず経由する

判断だけだと飛ばされます。機械だけだと「何が悪いか」が育たない。経路に入れないと、ローカルの近道で本番へ出ます。

機械チェックとガイド投稿の直列

機械チェックガイドのA→B→C→機械チェック
何か安価なスクリプト（トークン非消費）投稿するガイド原稿専用の役割直列
いつ経路内・必要ならいつでもガイドを draft: false／公開するときだけ
呼び方機械チェック／check:prepublishライター／チェッカー／…。投稿前ゲート禁止

「ゲート回すな」と言われたら、まず呼称と儀礼化を疑います。チェック自体を永久停止と読まないでください。

やりすぎとやり足りない

やりすぎやり足りない
毎秒の保存や、下書き専用のプレビューまで全部落とす規範だけ更新して、ビルドもデプロイも取り込みもチェックを通らない
draft の下書きまで公開チェックで止める「小さいから」で経路を迂回する
情報一行直しにA→B→Cを始める「投稿前ゲート」と呼んで儀式モードに入る

公開される面に乗るものだけ、経路に固定します。下書きは draft のままチェック対象外にしてよい場合があります。

是正が出たとき

1.不合格例を判断基準に足す（人が読める文） 2.機械チェックに同じ条件を足す（再現可能なfail） 3.まだ迂回できる入口があれば塞ぐ（経路固定） 4.一度、意図的に不合格原稿でチェックが止まることを確認する 5.チャット是正だけで終わらせない 6. rules／役名から「投稿前ゲート」を捨て、機械チェックと呼ぶ

作業前にAIへ渡す入力

人間向けの長い手順は書きません。次はすべて、作業前に AIに読ませる／貼る文 です。

AI向け：永続ルール（rules / AGENTS.md）

公開・ビルド・デプロイ・定期取り込みの経路で、機械チェック（npm run check:prepublish 等）を飛ばすな。
「小さい変更だから」も例外にしない。fail のまま draft: false／commit／push／deploy するな。
是正は判断基準・機械チェック・経路固定の三層に落とす。チャット是正だけで終わるな。
「投稿前ゲート」と呼ぶな。言い方は機械チェックまたは check:prepublish だけ。
ガイド投稿だけ A→B→C→機械チェックを直列で回す。情報・障害・ingest の commit／deploy で A→B→C を始めるな。
安価な機械チェックは経路内・必要時に実行してよい。チェック実行＝悪、と禁止に振るな。

AI向け：この作業の開始時にチャットへ貼る文

公開やデプロイに進む前に、使う入口が機械チェック経由か確認し、npm run check:prepublish を実行して結果だけ報告せよ。fail なら直し案を出せ。pass するまで公開操作はするな。「投稿前ゲート」と言うな。ガイド原稿の公開でなければ A→B→C は回すな。

人間向け

なし。上をAIに渡すだけでよい。

まとめ

参考リンク