ファクトチェック手法
トレンド項目をフィードに載せる前に検証する、再利用可能な公開前メソッド。CLAUDE.mdの
ソース検証ルールと2026-08-12のVoidの教訓から抽出した。これは学習エージェントの最も重要な
再利用可能アセット——一次シグナルと再利用された二次集計を分けるもの。
中核原則
集計メトリクスは「調査せよ」というシグナルであり、「公開せよ」というシグナルではない。
スター数、トレンド順位、「+2,840 stars」という行は、何かが動いていることを教えるだけで、
「なぜ」も、それが本物かどうかも決して教えない。速度は項目に調査キューへの席を与えるに
すぎない。記事そのものは、ページを開いて初めて獲得できる。
公開前チェックリスト
項目を書く前に、この3つのチェックを実行する：
- リポジトリ自体を開く。 README、最終コミット日、
archivedフラグ、メンテナンス状況。 スター数だけでは、プロジェクトが生きているか、放棄されているか、古いブログ記事で一時的に バズっているかは分からない。 - 引用しようとしているすべてのソースリンクをクリックする。 そのページは、帰属させようと しているデータポイントを実際に含んでいるか。ツールのランディングページはデータソースでは ない。検索結果ページも、特定の事実のソースではない。そのデータがページ上に見つからなければ、 引用しない。
- メトリクスではなくトリガーを見つける。 リポジトリが急上昇するのには理由がある——新 リリース、HNでの言及、スレッド、ブログ記事。そのトリガーを見つけ、それを軸に項目を書く。 「Xの休眠エディタがHNの言及で再浮上」は正確。「Xが2位に急上昇」は文脈がなければ誤解を招く。
ケーススタディ：Void（2026-08-12）——2つの失敗、1つの根本原因
- フィードは
voideditor/voidを+2,840 starsでトレンド2位と見て、「Cursor/Copilotを超える AIファーストエディタの勢い」と書いた。 - GitHubも引用されたPageCrawlページも実際には開かれなかった。 リポジトリを開いていれば： READMEには「2025年半ばから開発休止」とあり——プロジェクトは死んでいる。PageCrawlリンクを クリックしていれば：それはVoidのデータを一切持たない汎用ツールのサインアップフォームだった。
- 根本原因： 実際のページを訪問せずに集計メトリクスを信頼したこと。これは単一項目における 二層の偽シグナル——順位は誤りで、引用された「ソース」は何も裏付けていなかった。
ケーススタディ：正しくやる場合（今回のCVE検証）
同じ規律をagent-stackの2つのセキュリティ項目に適用すると、1行のフィード要約が正味
新しい一次ディテールに変わる：
- mcp-grafana CVE-2026-19516（SSRF）——フィードの「呼び出し元制御の
X-Grafana-URLヘッダー」 はCVEレコードと照合して一致し、開いてみるとより深いストーリーが浮かぶ：CWE-918、そして 関連する前身（CVE-2026-15583、「混乱した代理人」トークン流出）——その修正はトークン漏洩を 塞いだが宛先は制限しなかった。それがまさに19516が依然として成立する理由。単一の修正は 十分でないことが多い。 - Langflow CVE-2026-9198（RCE）——フィードの「auto_login + validate/code」は実際には2つの 独立した欠陥の連鎖（CVE-2026-9103 認証バイパス + CVE-2026-8481 サンドボックスなし
exec()）で、 エクスプロイトはデフォルト引数のトリック（def _v(a=exec('<payload>')): pass）を使う。 なぜならPythonはデフォルト値を定義時に評価するから。検証はスコアではなくメカニズムを開いた。
要点：ファクトチェックは偽項目を取り除くだけのゲートではない——薄い要約を、フィードが本来
届けるべきディテールへと変換するメカニズムなのだ。
公開後の訂正（メソッドのもう半分）
ファクトチェックは公開前のゲートだけではない——同じ規律は、項目が公開され、後に間違いと判明
した場合にも適用される。feed訂正の慣例（Void訂正の後にCLAUDE.mdへ成文化、2026-08-13）は、この
メソッドの公開後側の半分である：
- 本文をその場で修正する——項目の番号と位置を保ち、タイトル/説明を実際に真実である内容へ 書き換える（「トレンド」ではなく「アーカイブ済み・非推奨」）。番号を振り直したり、黙って削除 したりしない。
- 不正なリンクを撤回する——帰属された事実を一度も含まなかったソースを除去し、実際に訪問した ソース（リポジトリ自体、本当のベンダーページ）に置き換える。
- 有効なリンクを≥2保持する——訂正された項目にも、訪問済みで機能するソースが少なくとも2つ必要。
- 速度を再導出する——訂正された項目の速度は現実に合わせて下がる（▮ steady）。膨らんだ順位を 決して保持しない。
- zh/ と jp/ へ反映する——訂正は同じ実行で3つのロケールすべてに反映される。
統合されたメソッド：公開前に検証し、発見後に訂正する。 両方とも一次ソースを訪問するところから
始まり、集計のフレーミングからは始まらない。Voidは前半の常設例（公開前に捕捉）、その場での訂正は
後半の常設例（公開後に捕捉）。
いつ適用するか
毎バッチ、公開前に：各項目にチェックリストを実行する。3つのチェックをすべて完了できない項目は
「未検証」として扱い——チェックを完了させるか、項目を落とす。Voidの教訓は常設の警告として
残しておく。それが、このメソッドが存在するまさにその失敗モードなのだから。