ADR 0001: grok 自動投稿は DeepSeek で精査・リライトしてから公開する

背景

トップページの「情報」タブ (_layouts/home.html の grok-generated タグ絞り込み) に並ぶ記事は、 scripts/grok-post.mjs が Grok の応答を内容の精査なしにそのまま _posts/ へ書き出したものだった。

既存の検査はすべて体裁のみ:

• 文字数レンジ (400〜20000)
• Grok UI サイドバー語彙の混入検出 (#96 の再発防止)
• citation バッジ・字数メタコメントの除去 (#98 / #100)

書かれている内容が正しいかは一切見ておらず、末尾の「事実確認を行っていない」ラベルで免責していた。 これは親 #84 Decision Log #1「AI で裏付けをしない」(トークン節約と自立性を優先) に基づく 意図的な設計だったが、公開面の品質を優先して方針を転換する (issue #108)。

決定

投稿前に DeepSeek API で記事を精査し、本文自体をリライトしてから _posts/ に書き出す。

工程

Grok 応答 → sanitize → title/body 抽出
  → link-check.mjs      : 本文全体の URL を HEAD/GET で生存確認
  → deepseek-review.mjs : 死リンク情報を添えて DeepSeek に精査・リライトさせる
  → findIntroducedUrls  : 元記事に無い URL が増えていたらリライトを棄却
  → link-check.mjs      : 公開される本文を再検査。死リンクが残っていれば棄却
  → renderPost(reviewed): ラベルと tags を精査の成否で切り替える

• モデルは deepseek-v4-pro 既定 (DEEPSEEK_REVIEW_MODEL で上書き可)
• API キーは pass から scripts/grok-post-run.sh が注入する (参照先は DEEPSEEK_PASS_PATH 既定 knowledge-fabric/DEEPSEEK_API_KEY)
• --no-review で精査を切って従来動作に戻せる

失敗時は fail-open、ただしラベルは偽らない

DeepSeek 呼び出しが失敗したとき (キー不在 / HTTP エラー / タイムアウト / 空 content / リライト結果が文字数レンジ外) は、Grok 原文＋従来の「事実確認を行っていない」ラベルで投稿する。

• 自動投稿の稼働率を落とさない (精査は品質の上乗せであって、投稿の前提条件ではない)
• 精査していない記事に「精査済み」ラベルを付けない。ai-reviewed タグと末尾ラベルは 精査に成功した記事にだけ付き、読者が区別できる状態を保つ

リンク生存判定は「誤って殺さない」側に倒す

404 / 410 だけを死と判定する。403 (bot 遮断)・5xx (一時障害)・タイムアウト・DNS 失敗は 「判定不能」として死リンク扱いしない。生きている URL を誤って削除させる方が害が大きいため。

さらに、死判定は必ず GET で確認してから確定する。HEAD を未実装のまま 404 を返し GET なら 200 を返すサーバーが実在し、HEAD だけで確定すると生きた出典を記事から 消してしまう。GET が届かなかった場合も「判定不能」として死リンク扱いしない。

捨てた案

• 精査メモを追記する方式 (本文は Grok 原文のまま、末尾に検証結果を注記): 原文が残るので 対比できる利点はあるが、誤りを含んだ本文が公開面に残り続ける。品質改善の目的に対して弱い。
• 棄却ゲート方式 (精査で fail なら投稿しない): 記事本数が減るだけで、記事の質は上がらない。
• Claude (Sonnet) で精査する: 当初案。ネットワークに出られるため URL 実在確認までモデルに 任せられる利点があったが、コストと運用 (systemd から headless CLI を回す) を嫌って DeepSeek API 直叩きにした。URL の生死は link-check.mjs が決定論的に確認して補う。
• repo 専用の pass エントリ rengotaku.github.io/DEEPSEEK_API_KEY を新設: 秘密を複製すると ローテーション時に片方が取り残される。既存エントリを参照し、パスは env で差し替え可能にした。

変えてよい前提 / 壊すと危ない前提

• 変えてよい:
  • モデル名 (DEEPSEEK_REVIEW_MODEL)、MAX_COMPLETION_TOKENS、タイムアウト値
  • 精査プロンプトの編集方針 (buildUserPrompt)
  • 死判定に使うステータス集合 (DEAD_STATUSES)
  • リトライ間隔と回数 (RETRY_DELAYS_MS)
  • pass の参照先 (DEEPSEEK_PASS_PATH)
• 壊すと危ない:
  • reviewed フラグとラベル・tags の対応。精査していない記事に精査済みラベルが付くと、 読者に対する虚偽表示になる (この ADR の存在意義そのもの)
  • reviewAndRewrite() が例外を投げないこと。投げると 1 記事の精査失敗が その日の投稿全体を落とす
  • リトライ対象を「通信系の失敗」に限ること (#115)。対象は通信断・タイムアウト・ 5xx・429・408・JSON デコード失敗 (ボディ途中切れ) まで。応答は返っていて中身が使えない ケース (空 content・文字数レンジ外・記事のパース失敗) は再試行しても同じ結果になり、 トークンを無駄に使うだけなので対象外。分類は明示的に書くこと — 実装時に extractTitleAndBody の例外を汎用 catch に落として通信断と同じ扱いにする穴を踏んだ
  • onRetry / sleep の例外を外へ出さないこと (#115)。リトライの通知や待機が 失敗しただけで例外が伝播すると、上の「例外を投げない」契約が破れてその日の投稿が 丸ごと落ちる。onRetry は await して呼ぶこと — async コールバックの rejection は await しないと try/catch をすり抜け、unhandled rejection でプロセスごと落ちる
  • 本文は choices[0].message.content からのみ取ること。DeepSeek v4 系は reasoning モデルで、reasoning_content には思考過程が入る。混ぜると記事に独り言が載る
  • 空 content の reject。max_tokens が不足すると finish_reason: "length" で content が空のまま返る (実測)。空を採用すると記事が消える
  • リンク検査を「参考」節スコープに戻さないこと (#110)。当初は参考節だけを見ていたが、 Grok が裸の 参考 行で返す・DeepSeek が URL を節の外へ動かす・見出しを変える、の いずれでも検査が素通りする (#108 では実際に全記事で 0 件になりサイレントに無効化された)。 本文全体の URL を対象にすることで、見出し表記への依存ごと無くしてある
  • リライト後の URL 集合が元記事の URL 集合の部分集合であること (#110)。 「捏造するな」はプロンプトの指示にすぎず担保が無い。混入を検出したらリライトごと 棄却して Grok 原文に落とす。精査済みラベルを付けた記事に未検証 URL を載せない
  • 公開される本文 (リライト後) に対してもリンク検査を掛けること (#110)。入力側しか 検証しないと、リライトで移動・改変された URL が未検証のまま公開される。 死リンクが残っていたらリライトを棄却する — 死んだ出典を含む記事に「事実確認済み」 ラベルを貼るのはラベルの虚偽。ただし検査自体が失敗した (生死不明の) ときは棄却しない
  • URL 抽出が括弧を途中で切らないこと (#110)。https://…/Foo_(bar) を …/Foo_ まで しか取らないと、切断点より後ろを書き換えられても混入検出をすり抜け、リンク検査も 別物 (切り詰めた URL) を叩く。閉じ括弧は開き括弧とのバランスで判定する