運用してきて見えた事故は、次の3種類です。
- 意図しない物が一緒に公開される
- 公開ツールが「成功」と返したのに、実際は公開されていない、または消されている
- 検品に落ちた1件を飛ばした結果、その1件が永遠に公開されない
どれも、本文が正しくても起きます。AIがどれだけ良い文章を書いても、公開の操作が壊れていれば読者には届きません。
そこで、検品を公開の前と後の2か所に置いています。前は「これから出す物は想定どおりか」、後は「本当に出たか」を見ます。
公開の前に置く検品: 想定外のファイルが1件でもあれば止まる
何が起きうるか
relmea.com は、静的ファイルを丸ごとアップロードする方式のサイトです。作業フォルダに書きかけのファイルが置きっぱなしになっていると、コラムと一緒にそれも公開されてしまいます。
人が公開ボタンを押す運用なら、差分を目で見て気づけるかもしれません。毎日の無人実行では、その目がありません。
機械に見させること
コラムを1本足したときに、変わって当然の場所は3つです。
- 記事を置くフォルダ
- サイトマップ
- 転送設定
公開前に、変更されたファイルがこの3か所だけかを機械で確かめます。想定外のファイルが1件でもあれば公開せず、そのファイル名を名指しで報告して止まります。
変更が0件のときも止まります。コラムを足したはずなのに変更が無いのは、記事ができていないということだからです。
実際に作動した例
2026-09-27 から 09-29 の実行で、この検品が作動しました。コラムと無関係の未保存の変更が、4〜6件見つかったのです。対象は、メール登録の完了ページ、お礼ページ、製品ページ、サービスページでした。
実行はそこで止まりました。そのうえで、本番に出ている実物を取得し、行単位で比べました。差は、配信サービスが自動で差し込む計測スクリプトだけで、既に公開済みの内容と同一でした。これを確かめてから公開しています。
止まった時点では、問題なのか無害なのか分かりません。ファイル名が名指しされているので、比べる相手がすぐ決まり、その場で白黒をつけられます。
公開ボタンの直前で見つかった6件の欠陥を、そのまま検品項目にする
人が見て見つけた6件
note への自動公開では、2026-08-30 に「公開ボタンを押す直前の画面」で一度止めて、人が見ました。そこで6件の欠陥が見つかりました。
- 有料記事が無料のままになっている
- 有料ラインの位置が早すぎる
- URLがリンクカードにならない
- リンクカードの直後に空の段落が入る
- 本文に、手元のファイルの場所（ローカルパス）が残っている
- リンクのプレースホルダがそのまま残っている
どれも、公開後に気づくと直しにくい欠陥です。有料記事が無料で出たら、取り消せない損失になります。
検品項目に変える
この6件を、そのまま機械の検品項目にしました。人が見つけた欠陥は、次から機械が見張る項目になります。
本文側の検品は次のとおりです。
- タイトルが一致しているか
- 見出し画像があるか
- リンクカードの枚数が正しいか
- カード直後に空の段落が無いか
- 公開できない出典（ローカルパス等）が残っていないか
- プレースホルダが残っていないか
- 末尾のブロックがあるか
公開設定側の検品は次のとおりです。
- ハッシュタグの数
- マガジンへの追加
- 有料への切り替え
- 価格
- 有料ラインの位置
- メンバーシップ
同日に決めたルールは1つです。自動モードでは、全項目に合格したときだけ、自分で公開ボタンを押します。1項目でも落ちたら押さず、下書きのまま残します。
「成功」と返ってきたのに公開されていない: 公開の後に置く検品
公開ツールの「成功」は、公開された証拠になりません。2回、実際に起きています。
事例1: マガジンの上限で、公開の要求ごと拒否された
2026-09-18、note の4本が下書きのまま止まりました。原因は、記事数が上限（実測で400,000件）に達した共同運営マガジンへ追加しようとして、公開の要求ごと拒否されていたことです（エラー422）。
切り分けに丸1日かかりました。画面には警告が出ていたのですが、ブラウザ自動操作ツールがそれを自動で閉じるため、記録には「投稿は押したが公開を確認できませんでした」としか残らなかったからです。
対処は3つです。
- 公開のたびに、マガジンが上限に達しているかをAPIで判定し、達していれば除外する
- 除外した件数と名前を、報告に出す
- 押した直後に出るエラー本文を、報告に出す
事例2: APIは成功を返したのに、直後に審査で削除された
2026-08-19、Threads への投稿が API では成功（200・投稿ID付き）を返しました。ところが直後に、Threads 側の審査で削除されていました。通知は「経済的な利益に関する非現実的な主張や約束」でした。
しかも、API から投稿を削除する権限がありません。削除は人がアプリで行う必要があります。
対処は2つです。
- 投げた本数を成功と呼ばず、公開後に投稿を読み直して、残っている実数を数える
- 審査に引っかかる言い回しの型を、生成の時点で弾く。弾く型は、「稼げる」「月収」、「必ず」と成果の組み合わせ、「1時間で100案」「売上10倍」のような倍率や速度です
コラムの公開後検品
コラムの公開後には、新しい記事のURLが実際に200を返すかを確かめます。公開スクリプトが成功と言っても、それを信用しません。
正直に書くと、公開後の見た目（描画の崩れ）は、自動では確認できていません。いま機械が見ているのは構造の検査までで、ここは未確認の領域です。
落ちた1件を飛ばさない: 順番待ちを詰まらせない直し方
先頭の1本が居座った
2026-09-07、順番待ちの先頭の1本が検品に落ちたまま居座り、後ろの合格品まで止まりました。最初は「落ちた行を飛ばして次へ進む」ことで直そうとしました。
2026-09-08 に、それでは飛ばされた1本を誰も拾わず、永遠に公開されないと指摘を受けました。飛ばすのは、詰まりを消すだけで、問題を直していません。
4段の改善
改善は4段にしました。
- 落ちた項目を種類で分ける。直せるもの（タイトル、見出し画像、本文の貼り直し、公開設定の取りこぼし）は機械で直して、再検品を1回だけ行う
- 直せないもの（本文にローカルパスやプレースホルダが残っているなど、本文自体の欠陥）は、理由と直し方を名指しで台帳に残して、次へ進む
- 台帳に残った行は、見張りの仕組みが翌日以降も毎日知らせる
- 規格外の品が生まれる入口を、1本にする
あわせて、処理数は「成功した数」で数えるようにしました。飛ばした件数や試した件数を数えると、止まっていても動いているように見えるからです。
網の目の粗さは実測で決める
機械の検品には、閾値があります。この閾値を勘で決めると、止まりすぎるか、素通りするかのどちらかになります。
有料記事由来のピン文面の検査
有料記事から作った Pinterest のピン文面が、「解き方そのもの」を渡していないかを、本文との連続一致文字数で検査しています。ピンの投稿は 2026-09-05 から人の承認なしで行っているので、この検査が人の目の代わりです。
閾値を決めるため、人が承認して事故なく投稿された合格文面18件で測りました。本文との最長一致は27字でした。
最初に閾値を20字にすると、6件中5件が誤検出になりました。有料記事由来のピンがほぼ全部止まる網です。実測の最大27字に余裕を足して、40字にしました。
正直な限界
この閾値の根拠は、1バッチ18件だけです。あからさまな切り貼りを拾う粗い網で、言い換えられた解き方は通します。サンプルが増えたら測り直す前提の数字です。
明日から置ける検品チェックリスト
最後に、ここまでの内容をチェックリストにまとめます。
公開の前
- 変更されたファイルが、「1本足したら当然変わる場所」だけかを機械で確かめる
- 想定外が1件でもあれば止まり、ファイル名を名指しで報告する
- 変更0件でも止まる
- 止まった理由は、本番の実物と比べて白黒をつけてから再開する
- 人が公開直前に見つけた欠陥は、その場で検品項目に変える
- 全項目に合格したときだけ自分で公開し、落ちたら押さずに下書きで残す
公開の後
- ツールの「成功」を信用せず、URLの応答や投稿の実在を読み直して確かめる
- 投げた本数でなく、公開後に残っている実数を数える
- 公開の要求が拒否されたときのエラー本文を、そのまま記録に残す
- 画面の警告を自動で閉じる仕組みには、閉じる前に内容を記録させる
- 審査に引っかかる言い回しの型を、生成の時点で弾く
落ちた物の扱い
- 飛ばさない。種類で分けて、直せるものは直して再検品を1回だけ行う
- 直せないものは、理由と直し方を名指しで台帳に残す
- 台帳に残った行は、毎日知らせる仕組みで拾う
- 処理数は成功した数で数える
閾値
- 実測の最大に余裕を足して決める
- 根拠の件数を明記し、少なければ限界として書いておく
人に残すもの
relmea では、人が持っている部分も決めています。配信設定そのものの変更は承認待ちです（発信の制作と投稿は自動）。Threads の投稿削除は人が行います。閾値の決定と、止まったものの最終判断も人です。
機械は、止まるべきときに止まって、理由を名指しで報告します。判断は人が受け取ります。この分担が、毎日の無人公開を続けるうえでの前提になっています。