自動化の失敗には、派手な例外で止まるものと、起動前に入力が壊れていて何も始まらないものがあります。

今回扱うのは後者です。カード側には、今回の題材が次のように記録されていました。

"id": "AUTO-W3-CT-QIITA-20260902-pm"

emitのslot注入が publish カードの参照パスを二重接尾辞に壊し、配信5本が起動前に死んでいた

この時点で見るべき対象は、投稿APIでも、Qiitaの本文でもありません。content から publish へ渡すカードIDと参照パスの整合です。

事象

配信レーンでは、Qiita は技術ストックとして扱われています。運用メモにも次のようにあります。

Qiita | @SciCos | 稼働 | 技術ストック・信頼蓄積→送客

同時に、投稿上限は次の設定です。

"qiita": { "per_day": 1 }

つまり、1日に1本の枠を使う publish カードが、参照先不整合で起動前に落ちると、その日の配信枠を丸ごと失います。

今回のカードにも、前段の publish が失敗する前提が明示されています。

既存のQIITA publishは参照先が存在せず必ず落ちるので撃ち直し

ポイントは「記事が悪い」のではなく、「記事へ到達するための参照パスが壊れていた」ことです。

再現条件

再現条件は、IDやファイル名を文字列として組み立てる処理で、同じ意味の接尾辞を2回付けられる状態にしてしまうことです。

今回の作業カードは、成果物を次のように指定しています。

"deliverable": "qiita-posts.md"

一方で、過去のQiita公開ログには、上流contentカードとpublishカードが別IDとして残っています。

"path":"_share/outputs/banto/2026-09-01/AUTO-C1-CT-QIITA-20260901-am/AUTO-C1-CT-QIITA-20260901-am-qiita-post.md"

"source":"AUTO-C1-PUB-QIITA-20260901-am"

この構造では、CT 側の成果物名と PUB 側の参照先が少しでもずれると、publish は本文を読む前に失敗します。

再現しやすいのは、次のような考え方を混ぜたときです。

slot = qiita
baseId = AUTO-W3-CT-QIITA-20260902-pm
deliverable = qiita-posts.md

baseId にすでに QIITA が入っているのに、slot注入側でも qiita 接尾辞を足す。さらに成果物名にも qiita が入っている。こうなると、人間には「Qiita用」と読めても、機械的な参照パスでは二重接尾辞になりやすいです。

許可された素材内に残っている実コード断片として、直近のQiita publish修正ログに parser の正規表現が記録されています。

正規表現: ^TITLE:s*\r?\n(.+?)\r?\n\r?\nTAGS:s*\r?\n(.+?)\r?\n\r?\nBODY:s*\r?\n([sS]*)$

このログは別件、つまり TITLE: / TAGS: / BODY: のラベル形式を読めず、タイトルやタグが壊れた事故の修正記録です。記録にはこうあります。

上流原稿のTITLE:/TAGS:/BODY:ラベル形式(コロン区切り・複数行値)に未対応

タイトルがファイル名(AUTO-C1-CT-QIITA-20260901-am-qiita-post)・タグが既定値(GAS,Gemini)・本文にTITLE:/TAGS:/BODY:ラベル行が生混入

ここから分かるのは、本文パーサとカード参照は別の場所で壊れていても、根は同じだということです。

文字列の境界を、正規表現の都合やファイル名の都合に寄せすぎると、構造化データだったものが「たまたま一致する文字列」になります。

今回の参照パス不整合でも、危ないのはこの形です。

既にslotを含むID + slot由来の接尾辞 + deliverable由来の接尾辞

ID生成、成果物名、publish側の参照先を別々の正規表現で処理すると、どこか1か所の「補正」が別の場所では「二重付与」になります。

修正方針は、文字列を後から削ることではなく、境界を1か所に決めることです。

今回のカードは、最終成果物の形式を明示しています。

出力形式= TITLE= / TAGS= / BODY=

この場合、publish 側に渡すべきものは「Qiitaっぽいファイルを探す」ことではありません。カードの deliverable を正として、その1ファイルを読むことです。

"deliverable": "qiita-posts.md"

また、公開ログの修正例では、パーサ不一致を投稿後に緩和するのではなく、ツール側の分岐を追加してPATCHで訂正しています。

ツールにtitleColonMatch分岐を追加

既定回避せずツール修正=[[feedback_fix_tool_not_relax_rule]]

参照パスの問題でも同じです。publishカードごとに「存在しそうな別名」を探すのではなく、生成側と消費側で次を固定します。

content card id
deliverable path
publish source id
publish input path

この4つを1つの構造として渡せば、slot注入は表示や分類のための値になり、ファイル参照の再生成ロジックではなくなります。

この事故の教訓は、検知器を作るだけでは足りない、という点です。

配信レーンには、公開後の台帳追記や投稿上限確認のルールがあります。

公開したら published-ledger に1行追記

投稿数=稼働保証KPI（評価KPIでない）

しかし、publishカードが参照先不整合で起動前に死ぬ場合、公開後の検証には到達しません。だから検知器は、投稿処理の中ではなく、カード生成直後から publish 起動前までの間に配線する必要があります。

最小限見るべきなのは、次の3点です。

1. card.json の deliverable が存在するか
2. publish カードの参照パスがその deliverable と一致するか
3. slot注入後のIDに同じ接尾辞が重複していないか

正規表現は便利ですが、ID、slot、ファイル名、本文ラベルを全部同じ文字列処理で扱うと壊れます。

今回のような自動化では、正規表現を増やす前に、どの値を正本にするかを決めるほうが効きます。deliverable が正本なら、publish はそれを読む。slot は分類に使う。IDは一意性に使う。役割を混ぜない。

参照整合のバグは、見た目には小さな接尾辞の重複です。しかし、配信では起動前停止になります。記事本文の品質以前に、本文へたどり着く線を決定論的に保つ。そこを外すと、よくできた原稿も公開レーンには乗りません。