AI Digestの生成と編集における自動化と人間による公開判断

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

生成にはn8nとCodex CLIを使い、情報収集から下書き生成までを自動化しています。ただし、公開するかどうかは人間が判断します。

この記事で紹介するのは、どこまでを自動化し、どこからを人間が確認するのか、その仕組みと現在の限界です。

AI Digestでは、AIにニュースを渡して、そのままMDXを書かせる構成にはしていません。

AIにMDXを書かせないのは、AIの出力を公開物へ直結させず、途中に検査できる箇所を置くためです。

この構成へ変えたきっかけは、Codex CLIの--output-schemaで形式を指定しても、標準出力が常にJSONだけになるとは限らなかったことでした。実際に、Markdownのコードフェンスや前置き文を伴う出力がありました。

現在、AIが担当するのは決められたJSON Schemaに沿ってJSONを返すところまでです。受け取ったJSONを検証し、同じ入力から同じMDXを作る変換処理を通して、必ず下書きとして保存します。私は、出典と下書きを確認したうえで、公開するかどうかを判断します。

私が重要視しているのは、AIの出力をどこで止め、どの根拠まで人間が確認して公開するのかを説明できることです。

AIから受け取るJSONの形式はStructured Outputを使って固定し、公開前にはHuman-in-the-Loopとして人間による確認を入れています。

生成から公開までの責任範囲

この境界は、リポジトリ内のpackages/digest-core/schemas/shortlist.schema.json、research.schema.json、enriched.schema.jsonという三つのJSON Schemaと、各処理をつなぐスクリプトで固定しています。スキーマを共有パッケージに集約し、CLIとWebが別の定義を参照しない構成です。

図の読み方

1. AIは候補選定、事実調査、編集を別々に実行し、Schemaに沿ったJSONを返します。
2. 決定論的な処理がJSONの抽出、Schema検証、根拠URLの照合、MDX変換を順に行います。
3. 変換結果は必ずpublished falseの下書きで止まり、品質検査を通っても自動公開されません。
4. 人間が出典と本文を確認して公開可否を決め、公開後の訂正と撤回も判断します。

収集では取りこぼしをゼロにできない

収集元は、リポジトリに記録したn8n/workflows/editorial/digest-generate.jsonのRSS・JSON情報源と、RSSを持たない公式変更履歴を差分検出する収集経路です。公式発表・公式文書・リリース・論文・二次報道に加え、Hacker NewsやRedditなどコミュニティで注目されている情報も候補に入れます。

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

1日の対象期間は、前日06:30 JSTから当日06:30 JSTの直前までです。記事の公開時刻または更新時刻で判定し、時刻を解析できない候補は除外します。URLは追跡用パラメーターとフラグメントを外してから重複を判定します。

収集直後の未加工JSONは監査用に残します。その後の前処理では、arXivやリリースフィードなど情報源ごとに上限を設け、明らかにAIと無関係なGitHub Trending候補を落とします。

ただし、CVEや脆弱性を示す候補は情報源ごとの上限を超えても残します。ここで抑えているのは、情報源の偏りと入力の膨張です。

それでも、重要な情報の取りこぼしをゼロにはできません。

AIの処理を一度にまとめない

三つのAI処理を、一度の長いプロンプトには詰め込みません。候補選定、事実調査、編集を別々に実行します。

候補選定

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

セキュリティアドバイザリやCVEの可能性があるもの、公式発表や原著論文、実装や運用への影響が具体的なものを優先します。同じ情報源やパッチリリースだけで枠が埋まらないことも選定条件に入れています。

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

• Web検索は行わず、入力候補の範囲内だけで選ぶ
• セキュリティ、一次情報、実装・運用への具体的な影響を優先する
• 同じ情報源やパッチリリースだけで25件を埋めない

事実調査

候補選定で選んだ各URLは、公開ネットワークだけに限定した取得処理で内容を補います。本文取得は10秒でタイムアウト・2 MiBまで・抽出テキストは12,000文字まで・同時実行は5件です。プライベートネットワークやループバックへ向かうURLとリダイレクトは拒否します。

Web検索を代替手段として使うのは、取得した本文が不完全な場合、取得元が二次情報やコミュニティ情報だった場合、一次情報への接続が不足している場合だけです。

検索結果の抜粋だけで事実を確定することはしません。

調査結果は、一次情報を確認したprimary、複数の情報源で裏付けたcorroborated、二次情報だけのsecondary-only、未検証のunverifiedに分類します。日本語の各主張が、どの出典URLに基づくかもJSONに残します。

primaryには公式情報・原著論文・CVE・公式アドバイザリのいずれかが必要です。corroboratedには最低2件の情報源が必要で、secondary-onlyの信頼度は0.7以下に丸めます。

候補選定で選んだ項目を、事実調査の結果から黙って落とすこともできません。

編集

編集処理が受け取るのは、主張単位の調査結果と過去のDigest見出しです。ここではWeb検索をせず、調査結果にない事実も補いません。

公開候補は、主要記事のhero、関連記事のsupporting、短報のbrief、一行で触れるmentionsへ分けます。記事本文に出さない候補も、除外項目のexcludedへ理由付きで残します。

unverifiedは公開候補にできません。主要記事にはprimaryまたはcorroborated、セキュリティ分類にはCVEか公式アドバイザリが必要です。

AIから受け取ったJSONを検証してMDXへ変換する

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

--output-schemaは出力形式をLLMへ伝える手段であり、受け取ったデータが検証済みであることの証明ではありません。

そこでagents/workflows/digest/postprocess-enriched.tsから共有実装のpackages/digest-core/src/digest-enriched.tsを呼び、JSONをもう一度検証しています。JSONとして直接解析できなければ、まずコードフェンスの中身を取り出し、次にオブジェクト部分を抽出します。取り出した値は、あらためてJSON Schemaで検証します。

この処理では、記事に使う根拠URLが調査記録に存在するか、主要記事の根拠が一次情報または複数の情報源か、読者向けの文章に生成処理内部の言い訳が混ざっていないかも確認します。

見出しについても、過去記事との完全一致と近似を比較し、主要記事の具体語を含む候補だけから選びます。

検証を通過したJSONは、agents/workflows/digest/render-mdx.tsが読み直して同じスキーマで再検証します。そのうえで、定めたテンプレートから同じ入力に対して同じMDXを生成し、URLのプロトコルを確認し、MDXで意味が変わり得る記号をエスケープします。

この失敗があったため、現在は抽出・検証・根拠照合・MDX変換を一つの処理にまとめていません。

1. 標準出力をJSONとして直接解析し、失敗した場合だけコードフェンスやオブジェクト部分を抽出する
2. 抽出した値をJSON Schemaで検証する
3. 記事の主張と調査記録の根拠URLを照合する
4. 検証済みJSONを読み直し、定めたtemplateからMDXへ変換する
5. published: falseの下書きとして保存する

出典種別と公開形式は変換処理で決める

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

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

この出典種別をAIには選ばせません。packages/digest-core/src/digest-source-type.tsは出典URLを優先し、既知の情報源IDを補助情報にして出典種別を決めます。分類できないURLには表示名を付けず、下書きレビュー時の警告にします。

変換処理が作るフロントマターは、必ずpublished: falseです。excludedはローカルJSONの監査記録には残しますが、公開MDXには出しません。

JSON-LDも生成処理では作りません。公開後に、サイト共通の記事テンプレートがフロントマターから生成します。

掲載数を埋めることを目標にしない

情報源と実装上の意味を説明できるか。私は、掲載数よりもここを優先しています。

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

ベンダーのベンチマークや性能に関する主張も同じです。独立再現がない限り、ベンダー自身の主張として扱います。

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

品質検査を通っても自動公開しない

品質検査とpnpm buildを通っても、記事は下書きのままです。信頼度が高いという理由だけで自動公開する経路はありません。

設計時には、信頼度が0.9を超えた記事を自動公開する案も検討しました。ただ、信頼度では、情報源の読み違い・重要な但し書きの欠落・読者にとって自然な表現になっているかまでは判断できません。

数値を公開判断へ直結させる案は採用せず、変換処理がpublished: falseを固定する形にしました。

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

• 未加工データからMDXまで候補の行方を追う
• 同じ24時間を対象に外部検索し、収集漏れを確認する
• 主要記事と関連記事は本文の各事実、短報と一行更新は題名・出来事・URLを情報源で確認する
• 候補を見つけた情報源と本文の根拠を分け、引用URLに合う情報源名と出典種別へ直す
• 誤った分類、バージョンの提供元が抜けている箇所、誇張、未確認事項、内部リンクを修正する
• 公開を止める問題が0件になったことを確認してからpublished: trueへ変える

公開状態へ変えた後は、型検査・静的解析・テスト・ビルドを通します。ビルドで検査するのは、HTML・RSS・サイトマップ・llms.txt・Markdown版・Pagefind・OGP・JSON-LD・下書き除外の整合です。

ここでのpublished: trueはローカルの原稿が公開準備できた状態です。本番公開は、検証済みコミットがmainへ取り込まれ、Cloudflareのビルドとデプロイが完了して初めて成立します。

訂正と撤回も人間が判断する

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

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

公開継続が不適切な場合の撤回は、人間が明示的に判断します。公開記事一覧と検索・発見経路から外し、元のURLはリダイレクトせず404にします。信頼度や生成処理が自動で撤回を決める経路はありません。

現在のサイトには、撤回済みURLへ理由を表示するページも、訂正履歴を一覧化した公開ページもありません。訂正内容は更新された本文とGit履歴で追えますが、読者が一か所で確認できる仕組みにはなっていません。ここは今の限界です。

現時点で残っている限界

• 情報源一覧は選定済みの集合であり、全媒体と全言語を網羅しません。フィード停止、取得失敗、時刻欠落、情報源ごとの上限により候補を見落とす可能性があります。
• 本文取得と検索にはタイムアウト、容量、文字数、件数の上限があります。長い資料、JavaScript依存ページ、アクセス制限のあるページは十分に読めない場合があります。
• 出典種別は既知のホストと情報源IDで判定します。新しいドメインは未分類になり、既存の公開済みDigestへ表示名を遡及追加していません。
• excluded、調査結果、品質記録のアーカイブはローカルのout/に保存し、Gitには含めません。現在は別の場所へのバックアップがなく、マシン移行で失われます。
• 人間によるレビューは公開前の時点確認です。情報源が後から修正・削除されたことを継続監視する仕組みではありません。
• 下書きから始める運用、スキーマ、品質検査、人間によるレビューは誤りを減らすための境界です。情報の完全性や、誤りがないことまでは保証しません。

AIにMDXを書かせないこと自体が目的ではありません。

AIの出力をどこで止め、どの処理で検査し、最後に誰が判断したのか。そこを説明できる状態にしておくことが、私にとっては大事です。

AIの出力をそのまま公開しない。誤りを完全に防げるとも書かない。

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