メインコンテンツへスキップ

AI DigestでAIにはMDXを書かせない理由

AI Digestの収集からshortlist、research、editorial、人間承認までを、schema-bound JSONと決定的rendererの責任境界から公開します。

(更新日:)11分で読めます
AI DigestでAIにはMDXを書かせない理由

AI Digestは、AI関連の発表や更新を集め、実装と運用の観点から整理する日次記事です。

私が重く見ているのは「AIを使ったか」よりも、AIの出力をどこで止め、どの根拠を人間が引き受けて公開したかを説明できることです。

AIにニュースを渡して、そのまま記事を書かせる構成にはしていません。AIが担当するのは、決められたschemaに沿ったJSONを返すところまで。公開用のMDXは決定的なrendererが生成し、公開するかどうかは人間が判断します。

JSONの境界にはStructured Outputを使い、最後の公開判断にはHuman-in-the-Loopを置いています。

AIと人間の責任範囲を先に分ける

段階主な責任自動化していること自動化しないこと
収集と前処理n8nと決定的scriptRSSやJSONなどの取得、時間窓の適用、重複排除、sourceごとの上限世界中のAI情報を漏れなく集めること
shortlistAI調査候補を最大25件へ絞り、優先度と理由をJSONで返すことWebを追加調査すること
researchAIと取得script候補URLの本文取得、必要時のWeb検索、主張とsource URLの対応付け検索snippetだけで事実を確定すること
editorialAIverified researchだけを材料に、記事構成と日本語の分析をJSONで返すことMDXやJSON-LDを書くこと
rendererとquality gate決定的scriptschema再検証、evidence照合、source type判定、MDX生成、build検証confidenceだけで公開を決めること
公開人間source確認、事実と表現の修正、掲載判断、訂正と撤回の判断自動publish

この境界は、repository内のpipelines/digest/shortlist.schema.jsonpipelines/digest/research.schema.jsonpipelines/digest/enriched.schema.jsonという三つのJSON Schemaと、pipelineをつなぐscriptで固定しています。

MermaidAI Digestの生成と公開の責任境界収集から公開までを分離し、AIの出力をそのまま公開しない流れ

AIはshortlistとresearchとeditorialの各段階でschema-bound JSONを返します。決定的rendererがそのJSONからdraft MDXを生成し、quality gateを通過しても公開状態にはしません。最後の公開判断はsourceを確認する人間が担います。

  1. n8nと決定的scriptが候補を収集して前処理する
  2. AIがshortlistとresearchとeditorialのJSONを別々に返す
  3. validatorとrendererがdraft MDXを決定的に生成する
  4. 人間がsourceと記事を確認して公開可否を決める

収集で何を拾い何を落とすか

収集元は、repositoryに記録したn8n/workflows/editorial/digest-generate.jsonのRSS・JSON sourceと、RSSを持たない公式changelogを差分検出するscrape laneです。公式発表・公式document・release・論文・二次報道に加え、Hacker NewsやRedditなどのcommunity signalも候補に入れます。

ただし、communityで注目されていること自体は事実の根拠にしません。候補を見つける手掛かりとして使い、最終的な記述はリンク先の公式情報や信頼できる二次報道までたどります。

1日の対象期間は、前日06:30 JSTから当日06:30 JSTの直前まで。記事の公開時刻または更新時刻で判定し、時刻を解析できない候補は除外します。URLはtracking parameterとfragmentを外して重複判定します。

収集直後のraw JSONは監査用に残します。その後の前処理では、arXivやrelease feedなどsourceごとに上限を設け、明らかにAIと無関係なGitHub Trending候補を落とします。

ただし、CVEやvulnerabilityを示す候補はsource上限を超えても残します。この処理で抑えるのは、sourceの偏りと入力の膨張です。重要な情報の取りこぼしをゼロにはできません。

shortlistからeditorialまでをschemaで区切る

三つのAI処理を、一度の長いpromptには詰め込みません。shortlist、research、editorialを別々に実行します。

shortlist

前処理済みのmetadataから、調査対象を最大25件に絞ります。ここではWebを検索しません。

security advisoryやCVEの可能性があるもの・公式発表や原著論文・実装や運用への影響が具体的なものを優先します。また、同じsourceやpatch releaseだけで枠が埋まらないようにします。

出力URLが入力候補に存在するか、metadataが入力と一致するか、URLが重複していないかはpostprocessで再検証します。AIが新しい候補URLを足すことはできません。

research

shortlistした各URLは、public networkだけに限定した取得処理でhydrateします。本文取得は10秒timeout・2 MiBまで・抽出textは12,000文字まで・同時実行は5件です。private networkやloopbackへ向かうURLとredirectは拒否します。

Web検索をfallbackとして使うのは、取得した本文が不完全・二次情報・community情報、または一次情報への接続が不足している場合だけです。

結果はprimarycorroboratedsecondary-onlyunverifiedに分類します。日本語の各claimが、どのsource URLに基づくかもJSONに残します。

primaryには公式情報・原著論文・CVE・公式advisoryのいずれかが必要です。corroboratedには最低2 sourceが必要で、secondary-onlyのconfidenceは0.7以下に丸めます。

shortlistした候補を、research結果から黙って落とすこともできません。

editorial

editorialが受け取るのは、claim単位のresearchと過去のDigest headlineです。ここではWeb検索をせず、researchにない事実も補いません。

公開候補は、詳しく扱うherosupportingbriefと、一行で触れるmentionsへ分けます。記事本文に出さない候補も、excludedへ理由付きで残します。

unverifiedは公開候補にできません。heroにはprimaryまたはcorroborated、Security分類にはCVEか公式advisoryが必要です。

AIにはMDXを書かせない

JSON Schemaが保証するのは、AIの正しさではありません。必要なfieldと型を固定し、その後の決定的処理で検査できる形にするための境界です。

src/lib/digest-enriched.tsのpostprocessでは、記事に使うevidence URLがresearch recordに存在するか、heroの根拠が一次情報または複数sourceか、reader向け文章にpipeline内部の言い訳が混ざっていないかを検査します。

headlineは過去の完全一致と近似を比較し、heroの具体語を含む候補だけから選びます。

その後、pipelines/digest/render-mdx.tsの決定的rendererがJSONを読み直し、同じschemaを再検証します。固定templateからMDXを生成し、URLのprotocolを検査し、MDXとして危険な記号をescapeし、source名と出典種別を引用URLから決定します。

出典種別は、現在の実装では次の六つです。

  • 公式情報
  • 公式ドキュメント
  • 公式アドバイザリ
  • 原著論文(プレプリント)
  • 二次報道
  • コミュニティ情報

このlabelをAIには選ばせません。引用URLを優先し、既知のsource IDをfallbackにして決定的に分類します。分類できないURLにはlabelを付けず、draft reviewのwarningにします。

rendererが作るfrontmatterは、必ずpublished: falseです。excludedはlocal JSONの監査記録には残しますが、公開MDXには出しません。

JSON-LDもpipelineでは作りません。公開後に、site共通のarticle templateがfrontmatterから生成します。

掲載数よりsourceと実装上の意味を優先する

sourceと実装上の意味を説明できるか。掲載数を埋めることより、ここを優先します。

判断主な基準
掲載対象時間内で、AI実装・運用・modelやplatformの判断に関係し、researchがprimarycorroboratedsecondary-onlyのいずれか
heroその日の中心論点で、primaryまたはcorroboratedの根拠があり、具体的な確認事項まで示せる
mention本文ほどの深さは不要でも、時刻と根拠を確認でき、周辺動向として残す価値がある
除外重複、対象期間外、時刻不明、rumor、根拠不足、低signal、Securityとして扱うためのCVEまたは公式advisory不足

二次報道だけでも、限定した主張として掲載する場合はあります。その場合はimportanceとconfidenceに上限を設け、一次情報を確認できたようには書きません。

vendor benchmarkやperformance claimも同じです。独立再現がない限り、vendor自身の主張として扱います。

このDigestは「採用すべき」「見送るべき」を自動判定するrecommendation engineではありません。何が変わったか・誰に関係するか・導入前に何を確認するか・public sourceに何が書かれていないかを整理するためのradarです。

人間承認で公開を止める

quality gateとpnpm buildを通っても、記事はdraftのままです。confidenceが高いという理由だけでauto-publishする経路はありません。

公開前は、.claude/skills/reviewing-digest-before-publish/SKILL.mdに定義した日付指定のreview workflowを通します。確認するのは次の項目です。

  • rawからMDXまで候補の行方を追う
  • 同じ24時間窓を外部検索し、収集漏れを確認する
  • heroとsupportingは本文の各事実、briefとmentionは題名・出来事・URLをsourceで確認する
  • discovery元と引用根拠を分け、引用URLに合うsource名と出典種別へ直す
  • 誤った分類、versionのowner欠落、誇張、未確認事項、内部linkを修正する
  • auditのblockerを0件にしてからpublished: trueへ変える

公開状態へ変えた後は、typecheck・lint・test・buildを通します。buildで検査するのは、HTML・RSS・sitemap・llms.txt・Markdown alternate・Pagefind・OGP・JSON-LD・draft除外の整合です。

ここでのpublished: trueはlocal sourceの公開準備ができた状態です。production公開は、検証済みcommitがmainへ取り込まれ、Cloudflareのbuildとdeployが完了して初めて成立します。

公開後の訂正と撤回を人間が引き受ける

公開後に誤りが見つかったら、記事を公開状態のまま訂正します。元のdateは保持し、事実や解釈に関わる訂正ではupdatedAtを設定して、prepublication auditとbuild gateを通し直します。

通常の訂正を理由に、公開記事を黙ってdraftへ戻すことはしません。

公開継続が不適切な場合の撤回は、人間が明示的に判断します。publication inventoryとdiscovery surfaceから外し、元のURLはredirectせず404にします。confidence scoreやpipelineが自動で撤回を決める経路はありません。

現在のsiteには、撤回済みURLへ理由を表示するtombstoneも、訂正履歴を一覧化する公開ledgerもありません。訂正内容は更新された本文とGit履歴で追えますが、reader向けに一か所で確認できる仕組みではない。ここは今の限界です。

既知の限界

  • source listはcuratedな集合であり、全媒体と全言語を網羅しません。feed停止、取得失敗、時刻欠落、source上限により候補を見落とす可能性があります。
  • hydrationと検索にはtimeout、容量、文字数、件数の上限があります。長い資料、JavaScript依存page、access制限のあるpageは十分に読めない場合があります。
  • source typeは既知のhostとsource IDで判定します。新しいdomainは未分類になり、既存の公開済みDigestへlabelを遡及追加していません。
  • excluded、research、qualityのarchiveはlocalのout/に保存し、Gitには含めません。現在はremote backupがなく、machine移行で失われます。
  • 人間reviewは公開前の時点確認です。sourceが後から修正・削除されたことを継続監視する仕組みではありません。
  • draft-first、schema、quality gate、人間reviewは誤りを減らす境界であり、完全性や無誤謬を保証しません。

AIの出力をそのまま公開しない。完全性や無誤謬も保証しない。

これが、現在のAI Digestで守っている境界です。日々の更新はAI Digest一覧から確認できます。

Written by

柿添貴士(TakashiKakizoe) profile photo

柿添貴士(TakashiKakizoe)

Webエンジニア/テックリード

Fukuoka, Japan

  • PHP
  • Laravel
  • Next.js
  • AWS
  • Cloudflare
  • AI Agent