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

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

Canonical URL: https://labs.eastbraver.com/blog/digest-editorial-transparency
Published: 2026-07-30T20:55:00+09:00
Updated: 2026-07-30T21:40:24+09:00
Category: ai-development
Tags: software-engineering, governance, evaluation

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

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

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

JSONの境界には[Structured Output](/guides/structured-output)を使い、最後の公開判断には[Human-in-the-Loop](/guides/human-in-the-loop)を置いています。

> [!IMPORTANT]
> この記事は2026年7月30日時点のrepository実装、validator、運用skillを基準にしています。運用実績を推測で補わず、現在の仕組みで保証できることと保証できないことを分けて説明します。

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

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

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

### AI Digestの生成と公開の責任境界

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

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

*収集から公開までを分離し、AIの出力をそのまま公開しない流れ*

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

収集元は、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情報、または一次情報への接続が不足している場合だけです。

結果は`primary`、`corroborated`、`secondary-only`、`unverified`に分類します。日本語の各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にない事実も補いません。

公開候補は、詳しく扱う`hero`・`supporting`・`brief`と、一行で触れる`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が`primary`、`corroborated`、`secondary-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一覧](/digest)から確認できます。