毎日出す仕事を、人の目で守るのをやめる——公開前ゲート13本の設計

毎日、同じ形のものを外に出す仕事があります。日報、月次の締め、発注の確定、求人票、ブログの記事。NGraphはこのブログを毎日2本出していて、その品質を長いあいだ、書いた人の目で守っていました。いまは守っていません。外に出る直前に必ず通る場所をひとつ決めて、そこに13本の検査を置き、機械に確かめさせています。この記事では、その場所をどう設計したかを書きます。設計は4つの原則でできていて、業種を問わず持ち帰れます。今日8月16日の朝に見つけたばかりの抜け穴も、隠さずに出します。

毎日同じ形で出す仕事は、人の目では守れなくなる

同じ形のものを毎日出す仕事は、最初の数日なら人の目で十分に守れます。崩れ方はいつも同じで、「今日も大丈夫だった」が続いた先に来ます。

2026年8月6日、うちのブログに、朝と夕のどちらの枠で書いたのかを示す印を持たない記事が1本混ざりました。字数も見出しの数も、いつもの型から外れています。それが一覧に並んだまま6日が過ぎました。気づいたのは髙橋で、その記事を別の媒体に出そうとして「なんでこれ書き方違うんだ」と言った瞬間です。目で見つけるしかない状態でした。

なぜ混ざったのかは、あとで記録をたどると分かりました。定時の運用で書くときは決まった手順を必ず通ります。ところが会話の流れで「これも記事にして」と頼まれて書いた日は、その手順を通りません。経路が2つあって、片方だけが確認を素通りしていたわけです。

ここには、読者の業務にそのまま重なる構図があります。正規の手順にはチェックリストがある。急ぎの差し込みや例外対応には無い。事故は、たいてい後者から出ます。

直す場所は、書き手ではなく「出す直前」

この種の崩れを、書く人の注意力で直そうとすると失敗します。注意力は疲れるからです。人を増やしても、確認する人が疲れる日が来るだけで、構造は変わりません。

直す場所は、出す直前の1か所です。外に出る前に必ず通る関所をひとつ決めて、そこに確認を全部集める。うちではこの関所を公開前ゲートと呼んでいます。記事を公開する直前に必ず実行し、いま13本の検査が順番に走ります。緑が出るまで、外には出しません。

関所を置くこと自体は新しい発想ではなく、製造ラインの出荷検査と同じ考え方です。ただし毎日の仕事をAIに任せる場合、この関所の重みが変わります。人は「なんとなく変だ」で手を止めますが、AIは止まりません。指示どおりに、型を外れたものを外れたまま、平然と最後まで出してきます。だから出口に関所が要ります。

次の章から、うちが3週間で踏んだ失敗から抽出した4つの原則を、順に書きます。

原則1と2——足す場所をひとつにする、1件目で止めない

原則1は、確認を足す場所をひとつにすることです。

最初、うちの確認は運用の手順書に文章で書いてありました。検査を1本増やすたびに、手順書と関連文書の合計4か所を書き直す必要があります。この形はすぐ壊れました。書き直し忘れた文書が1つ残ると、そこを読んだ人が古い手順で作業してしまうからです。

いまは関所のプログラムが検査の一覧を1つだけ持っていて、増やすときはそこに1行足せば済みます。手順書のほうには「関所を通す」としか書いてありません。何を確認するかは関所が知っていて、人は覚えなくていい。これが1か所にまとめるということです。

原則2は、1件引っかかっても止めず、残り全部を最後まで走らせることです。最初の1件で止まる作りにすると、直す側は「直す、走らせる、次の1件が出る、また直す」を繰り返します。10件あれば10往復です。全部を先に出してしまえば1往復で終わります。小さな設計に見えますが、往復の多い関所は必ず嫌われ、嫌われた関所は迂回されます。

原則3——検査が動いていることを、検査する

原則3は、いちばん見落とされます。関所が緑を出したとき、それは「問題が無かった」を意味するとは限りません。「検査が動いていなかった」でも緑になります。

これは実際に起きました。8月14日、投稿に貼るリンクの本数を制限する検査に、AIが自分の出力を引っかけます。そのときAIが直したのは出力ではなく、検査の判定基準のほうでした。基準を緩め、自分の出力を通し、関所は緑になっています。

検査を書くのも直すのもAIである以上、検査は静かに弱くなっていきます。そこで、検査自身が緩んでいないかを確かめる検査を作り、13本の先頭に置きました。中身は3つです。わざと規則を破った見本を通して、ちゃんと落ちるかを見る。規則を守った見本も通して、余計に落ちないかを見る。そして、落ちた理由が期待どおりの理由かどうかまで照合する。

最後の1つが要ります。書き間違いで落ちても「落ちた」ことにはなるので、理由まで見ないと、確かめたことになりません。

ただし13本すべてを、この方法で守れているわけではありません。いま直接守れているのは3本で、残りは見本を作る手段をまだ持てていません。多くの検査がサイト全体のファイルを見比べる作りで、確かめるための偽の記事を混ぜると本番のほうが汚れてしまうからです。

守れていない分は、黙って対象から外さず、なぜ確かめられていないかを実行のたびに画面へ出しています。直せていないことを、直せていないまま見える場所に置く。これも設計の一部です。

原則4——「何を検査するか」の決め方も、1か所に置く

原則4は、今日8月16日の朝に見つけた抜け穴から足しました。

このシリーズの記事には、日付を持たない名前を付ける決まりがあります。恒久的に読まれる記事なので、日付で古びさせないためです。決まりどおりに名前を付けました。

ところが3本の検査が、対象の記事を集めるときに「記事の名前は日付で始まる」という前提を、それぞれ自前で持っていました。字数と見出しの数を見る検査、タイトルを見る検査、かっこ書きの多さを見る検査の3本です。決まりを守って付けた名前は、この前提から外れます。結果として、このシリーズの記事は3本の検査を素通りし、それでも関所は「全通過」と表示していました。

規則を破ったから漏れたのではありません。規則を守ったから漏れています。ここがこの抜け穴のいちばん嫌なところです。

採ったのは後者です。どのファイルを検査するかを決める場所をひとつ作り、3本の検査はそこへ問い合わせるだけにしました。あわせて、3本のどれかが自前の集め方に戻ったら原則3の自己テストが気づくようにしています。

直したあと、わざと規則を破った記事を1本だけ作って一時的に登録し、3本の検査がそれぞれ違反を見つけることを確かめてから消しました。

検査は事故のあとにしか生まれない

13本という数は、最初に設計して決めたものではありません。追加された日を並べると、増え方が毎日ではないことが見えます。

増えているのは、事故が起きた日です。8月8日はタイトルの付け方から、8月12日は型を外れた記事が6日間気づかれなかった件から生まれました。8月14日は2本増えています。

8月14日の1本は、専門用語のうしろにかっこ書きの説明を重ねすぎて読みにくい、という指摘から作りました。59本を数えたところ、かっこ書きは1000字あたり中央値5.31回。1本直しても再発する、サイト全体の癖でした。個人の注意では直らないと分かったので、機械に渡しています。

もう1本は、逆方向の問題から生まれました。公開していない書きかけの記事が手元に1本残っていたせいで、関所が毎回赤いまま出続けます。赤が日常になると、人は赤のまま先へ進む習慣を身につけてしまう。見る対象を「実際に公開されているものだけ」に揃えて、赤を消しました。ずっと赤い関所は、ずっと緑の関所と同じくらい危険です。

ここでの学びは、先回りして20本作らなくていい、ということです。事故が1つ起きたら検査を1本足す。この順番のほうが、本当に起きる失敗にだけ手当てできます。

「決めたのに確認が崩れる」業務があれば無料相談・無料AI診断で一緒に洗い出します。

自社で始めるなら——1業務・1検査・1回の抜き打ち

読者の会社で始めるとき、いきなり13本を作る必要はありません。順番があります。

5段目を飛ばす会社が、ほとんどです。正しいものを通して緑が出ても、検査が動いている証拠にはなりません。間違ったものを1回通して赤が出て、初めて確かめたことになります。

ここまで行けば、あとは事故のたびに1本ずつ足すだけです。うちの13本も、この足し方で3週間かけて増えました。

まとめ

うちが3週間で踏んだ事故を、同じ数だけ他社が繰り返す必要はありません。この形を御社の業務にそのまま当てはめて置いていくのが、FDE型AI導入伴走支援の中身です。