自動化のシグナルを隠すためのQCゲートの構築方法
自動化は、予想もしない形で露呈するものだ。
私はBluesky向けに自動コンテンツ・パイプラインを運用していた。ある投稿で「the content pipeline（コンテンツ・パイプライン）」という言葉が出てしまった。技術ブログであれば問題ないが、ソーシャルメディアのタイムラインではレッドフラッグ（警告サイン）になる。読者に「相手はボットだ」と悟らせてしまうからだ。
これを防ぐために、品質管理（QC）スクリプトを作成した。これは、生成ステップと投稿ステップの間にゲートとして機能する。
新しいワークフローは以下の通りだ：
bluesky-qc.mjs → (PASS) bluesky-post-queue.mjs → Bluesky API
スクリプトは、すべてのエントリーをチェックするために4つのゲートを使用している：
ゲート1：フレーズ・フィルタリング 正規表現のリストを使用して、自動化を示唆する言葉を検知する。「AI-generated」、「cron」、「content pipeline」、「batch test」といった用語をブロックする。投稿が開発レポートのように聞こえる場合は、不合格となる。
ゲート2：鮮度チェック 2種類の「鮮度の落ちた」コンテンツをチェックする： • 陳腐化したフレーズ：「today（今日）」や「just launched（たった今リリースされた）」といった、投稿が遅れた場合に意味を失う言葉を検知する。 • 陳腐化したタイムスタンプ：エントリーが14日以上前のものである場合、拒否される。
ゲート3：エンゲージメント予測 スクリプトは過去300件の投稿を分析する。新しい投稿に含まれるハッシュタグがうまく機能するかどうかを予測する。現在は警告をログに記録するだけだが、近いうちに「不合格（hard fail）」として扱うようにする予定だ。
ゲート4：品質パス（計画中） 微妙なエラーを検知するために、品質プロトコルを用いた最終レイヤーを追加するつもりだ。
すべての失敗は拒否ログ（rejection log）に記録される。私はこのログを週に一度確認する。これにより、プロンプトの修正に役立てている。もしゲートが繰り返し「content pipeline」を検知するなら、AIの書き方を変える必要があると判断できる。
なぜ、単にプロンプトを改善するのではなく、ゲートを使うのか？ プロンプトは確率的（probabilistic）だ。失敗することもある。 ゲートは決定的（deterministic）だ。厳格なルールに従う。
両方のレイヤーを併用することが、人間らしいトーンを維持するための最も安全な方法だ。