本記事に登場する
HUMAN_INPUTマーカーとは、AI 執筆 skill が記事本文に残す「ここは人間が後で確定値を埋めるべき」を示すプレースホルダー（形式例:<!-- HUMAN_INPUT: 数値を記入 -->）。
fact-check は review とは別の責務 — 数字・時系列・体験事実の照合設計
→ AI エージェントを使った業務設計の全体像 でこのトピックの背景を確認する
「Stage 3 にある」「2026-03 に開始した」「処理時間が大幅に短縮された」——これらの断定が本文に含まれていても、blog-review はそのまま通過させる。review skill の責務は文体・構造・ブランド規約・HUMAN_INPUT チェックであり、数字が git log と一致するかを確認する機能を持っていないからだ。その結果、推測で書かれた時系列が review をすり抜けて公開される可能性が構造的に残る。
この記事では、blog-review の責務を文体・構造・ブランド規約に限定し、数字・時系列・体験事実の照合を独立した blog-fact-check skill として pipeline に組み込む設計を解説する。責務分離によって、捏造が review をすり抜ける構造的リスクを排除できる。
review と fact-check — 混在すると何が起きるか
blog-review が持つ本来の責務
blog-review は以下の 4 領域を担う:
| 責務 | 具体的な確認内容 |
|---|---|
| 文体チェック | BRAND.md の voice / tone / NG 表現への適合 |
| 構造チェック | 6 ステップ構造の遵守、H2 の論理的な流れ |
| ブランド規約チェック | 「弊社」「画期的」等の禁則語、八雲の自称ルール |
| HUMAN_INPUT チェック | マーカーが最低数を満たしているか、未解決の {{HUMAN_INPUT: ...}} が残っていないか |
これらは「書き方」の問題だ。文体・構造・ブランドが正しくても、書いてある内容が事実と異なる場合は別の問題になる。
「数字・時系列・体験記述」を同じ review に混ぜるとコンテキストが混濁する
review に「git log との照合」を追加すると、skill が担う責務が 2 種類の異なる axis を持つことになる。
- axis A: 「どう書いているか」（文体・構造・ブランド）→ 本文テキストだけを見れば判断できる
- axis B: 「何が書いてあるかが事実か」（数字・時系列・体験の正確性）→ 外部ソース（git log / ファイル）との照合が必要
axis A と axis B を同じ skill に混ぜると、skill のプロンプトが肥大化し、各観点の判断精度が落ちる。また、責務が不明確になることで「review が通ったから事実は正しい」という誤認が生まれやすい。責務を明確に分離することで、それぞれの skill が担う範囲が明示される。
fact-check 実装前（2026-05-19 以前）は、synapse の git log を main thread が手動で参照して Stage 1〜3 の時系列を推測していた。構造的に事実確認が不完全になる状態だったが、具体的な誤情報が公開まで到達した事例の詳細は記録されていない（blog-ops/retros/2026-05-19-cross-repo-fact-tracking.md の「発見した issue」セクション参照）。
fact-check skill の責務設計 — 何を・どうやって照合するか
照合対象の 3 分類
blog-fact-check が照合する対象を 3 分類で定義する:
1. 数字 具体的な数値（件数・時間・コミット数・%）が本文に含まれる場合、その数字の根拠を確認する。根拠となる git log 行やファイルの記述が存在しない場合は WARN を出す。数字が HUMAN_INPUT マーカー内にある場合は照合対象外（人間が後で確認する扱い）。
2. 時系列
「2026-03 に始まった」「Stage 3 にある」のような時期・フェーズの断定は、git -C {path} log の出力と照合する。initial commit の日付、特定のキーワードを含む commit の日付と照合して一致を確認する。
3. 体験事実
「retro に記録されている通り」「past に経験した」のような体験の引用は、blog-ops/retros/ 配下の retro ファイルとの照合対象になる。retro に記載のない体験事実は WARN 扱いとする。
git log / file を根拠にした決定論的な検証パターン
fact-check の検証ロジックは次のパターンで動作する:
# 本文中の時系列断定を抽出して git log と照合する例
REPO_PATH=$(python3 -c "import json; repos=json.load(open('blog-ops/config/related-repos.json')); print(repos['repos']['synapse']['path'])")
# 「2026-03」の記述があるか確認
CLAIM_DATE="2026-03"
GIT_LOG=$(git -C "${REPO_PATH}" log --format="%ad %s" --date=short | grep "${CLAIM_DATE}" | head -5)
if [ -z "${GIT_LOG}" ]; then
echo "WARN: 本文中の '${CLAIM_DATE}' に対応する commit が見つかりません"
else
echo "OK: '${CLAIM_DATE}' の根拠 commit: ${GIT_LOG}"
fi曖昧表現（「数日〜数週間」「大幅に短縮」）を warning にする設計
具体的な数字がなく曖昧表現のみの場合も warning の対象とする。対象パターン:
- 「数日」「数週間」「数ヶ月」（具体的な数値を伴わない）
- 「大幅に」「著しく」「劇的に」（比較基準のない相対表現）
- 「多く」「少なく」（定量化されていない）
これらは HUMAN_INPUT マーカーに置き換えることを推奨する警告として出力する。強制的に fail にはせず WARN に留めるのは、narrative の都合で曖昧表現が適切な文脈もあるためだ。最終的な判断は人間に委ねる。
blog-fact-check skill は実装済みで .claude/skills/blog-fact-check/SKILL.md が存在する。pipeline の phase 3.5 として new-article-spoke.json に組み込まれており、review（phase 3）の直後・meta（phase 4）の前に配置されている。
pipeline DAG への組み込み — phase 3.5 の設計
fact-check の配置: review 直後・write 直前の gate
fact-check を pipeline に組み込む位置は phase 3.5（review の直後）とする。
phase 1: classify
phase 2: pattern / case
phase 3: write（blog-tech-write / blog-case-write）
phase 3.5: fact-check（新設）← ここ
phase 4: meta
phase 5: translate
phase 6: publishreview（文体・構造）が通った後に、fact-check（事実の正確性）を gate として挟む設計だ。review と fact-check の順序は入れ替えても構わないが、事実確認は文体が整った後の方が本文内の断定箇所を正確に抽出しやすい。
fact-check fail 時の制御フロー（write に差し戻す）
fact-check が FAIL を返した場合、pipeline の制御は phase 3（write）に戻る。WARN の場合は継続して次 phase に進む（人間が後で HUMAN_INPUT マーカーを補完する扱い）。
fact-check 結果
├── OK: → phase 4（meta）へ進む
├── WARN: → 警告を _state.json に記録して phase 4 へ進む
└── FAIL: → write step に差し戻す（FAIL 箇所を blockers に記録）FAIL の条件は「具体的な数値または日付が本文に断定として書かれており、かつ git log / file に根拠が見当たらない」場合。これは明確な捏造リスクであり、人間の判断なしに先に進ませない。
fact-check 追加後の new-article-spoke パイプラインの総 phase 数は 11 step（phase 0〜10）。seo → plan → write → fill-ssot → review → fact-check → meta → translate → publish-prep → human-review → publish → schedule → graph-regenerate の順で実行される。
fact-check が FAIL を返すと、pipeline DAG の制御で write ステップに戻す設計になっている。blog-ops/retros/2026-05-19-cross-repo-fact-tracking.md の「実装したこと」に「pipeline DAG 拡張: phase 3.5 として fact-check を review 直後に新設。fact-check fail は write に戻る制御を追加」と記録されている。
実装後の効果 — 何が変わるか
fact-check が pipeline に入ることで変わる点を具体的に示す。
変更前: 執筆 skill が推測で時系列を書く → review が文体のみ確認 → 捏造が公開される可能性がある
変更後: 執筆 skill が git log を参照して書く → review が文体のみ確認 → fact-check が時系列を git log と照合 → 捏造が FAIL として検出される
review と fact-check の責務境界:
| 確認項目 | review | fact-check |
|---|---|---|
| NG 表現（「画期的」等）が使われていないか | ✓ | — |
| HUMAN_INPUT マーカーが最低数あるか | ✓ | — |
| H2 の構造が 6 ステップに沿っているか | ✓ | — |
| 「2026-03 に開始」が git log と一致するか | — | ✓ |
| 「Stage 3」という記述の根拠があるか | — | ✓ |
| 数値断定に git log の根拠があるか | — | ✓ |
| 曖昧表現（「大幅に短縮」等）が含まれるか | — | ✓（WARN） |
この表が両 skill の責務境界を示している。review が YES と言っても fact-check が FAIL を出せる。逆も同様だ。それぞれが独立した gate として機能することが、品質の多重担保になる。
→ permission allow-list の事前整備については permission の事前整備が前提 を参照