GitHub の `pushed_at` は 35 件中 14 件で誤解を招いた、3 件ではボット関与も確認

GitHub のリポジトリページには pushed_at というタイムスタンプがありますが、これはどのブランチに push があっても更新されます。そのため、デフォルトブランチの最新コミット日時と食い違うことがあります。デフォルトブランチの日付はリポジトリの保守状況を示す指標ではありますが、パッケージマネージャーが実際に取り込むコードそのものを意味するわけではありません。

通常、パッケージマネージャーはレジストリ上の成果物やモジュールのバージョンを参照します。そこで今回の監査では、リポジトリの活動状況と公開済み成果物を分けて確認しました。どちらか一方は新しくても、もう一方は古いまま、ということは普通にあるからです。

そこで、いまもおすすめに出てくる 35 個のリポジトリを抽出し、GitHub がヘッダーに表示しない数字、つまりデフォルトブランチ上の最新コミット日を調べました。

結果はかなりはっきりしています。35 件中 14 件では、pushed_at がデフォルトブランチの最新コミットより 180 日以上先に見えており、最大差は 1,802 日 でした。その 14 件のうち 3 件はボット起因であることを確認済みです。さらに、アーカイブ済みかどうかと人間の活動状況で絞り込むと、候補 9 件のうち確認済みボット事例は 2 件になります。より大事なのは、リポジトリの新しさと公開済み成果物の新しさは一致しないことがある、という点です。

何を、何で測ったのか

公式参照: GitHub repository API。

ここで示す数値はすべて、2026-07-27 の UTC 15:44〜15:53 のあいだにライブ API 応答から取得し、キャッシュしたものです。35 行のデータセット、リポジトリ一覧、生成済み行データ、そして artifacts/ 内の取得・生成スクリプトが、監査の入力と変換コードをそのまま残しています。

取得したデータカテゴリは 4 つですが、レジストリと活動履歴は一律 4 回の呼び出しではなく、必要に応じた条件付き取得です。

• GET /repos/{owner}/{repo} — stars、archived、pushed_at、ライセンス、default_branch。
• GET /repos/{o}/{r}/commits?sha={default_branch}&per_page=1 — デフォルトブランチ上の最新コミット。リポジトリ保守状況の指標として使用。
• GET /repos/{o}/{r}/activity?per_page=30 — 2 つの日時が食い違うリポジトリについて、実際に何が pushed_at を動かしたのかを確認。
• GET /repos/{o}/{r}/releases と PyPI / npm のレジストリ — 成果物 が最後にいつ出たか。実はこれが、前 2 つ以上に重要でした。

staleness_days は、デフォルトブランチのコミットから基準時点までの経過日数です。pushed_at とそのコミットの差が、この“見かけ”のズレです。180 日超を警告対象としています。

結果を左右したので、ここで明示しておくべき点が 2 つあります。

パッケージの帰属は推測せず、必ず検証しました。 README にあるリポジトリ名だけで、そのパッケージだとは扱いません。対応付けはすべて、レジストリ自身の repository / project_urls、またはリポジトリ内にコミットされた manifest など、構造化された情報で裏取りしています。もっともらしく見えた対応付け 6 件はこの条件を満たせず、ダウンロード数は意図的に割り当てていません。

その却下例の 1 つは、このルールの正しさをよく示しています。curl-cffi は月 35,763,529 ダウンロードあり、遠目には lwthiker/curl-impersonate の Python バインディングのように見えます。ところがそのリポジトリは 875 日止まっています。もしこれをそのまま帰属させれば、newspaper3k の 44 倍という数字になっていたはずですが、それは誤りです。curl-cffi の PyPI メタデータは lexiforest/curl_cffi を指しており、別プロジェクトとして継続的に保守され、最後の公開日は 2026-04-03 でした。ここで見つかった最大の数字は、正しい数字ではなかったのです。

7 件目のケースはさらに変わっています。steel-dev/steel-mcp-server は自分の package.json に @steel-dev/mcp-server を宣言していますが、npm では 404 が返ります。そもそも公開されていないので、「まだインストールされている」とは言えません。

数値が取れないものは、そう明記しました。 Go、JVM、.NET、PHP のツールは PyPI も npm も存在しないため、N/A (no PyPI/npm package) としています。ゼロではありません。また、35 件中 17 件は GitHub Releases を一切出していませんが、これは欠損値ではなく none と記録しました。

これらの項目は、あえて 1 つの「健全性スコア」にまとめていません。古いデフォルトブランチ、最近のサイドブランチ、GitHub Release の欠如、古いレジストリ成果物は、それぞれ別の問いに答えるからです。行ごとの証拠は 35 行のデータセット にあり、リポジトリ入力 と 生成レコード もあわせて確認できます。これらは「その次に何を確認すべきか」を決めるトリアージ信号として読むべきで、プロジェクトが生きているかどうかを決める 4 票ではありません。

先に sampling の注意点

これは、私が「評判だけで延命していそうだ」と疑ったツールを手作業で集めたリストです。スクレイピング全体から無作為抽出したものではないので、「35 件中 31 件が古い」はエコシステム全体の率ではありません。 私の選び方がどれだけ当たったかを示す、ほぼそれに近い数字です。面白いのは古い件数そのものではなく、この現象を狙って選んだサンプルでさえ、私が検証したメカニズムで説明できたのは一部だけで、しかも確証を持てたのはさらに少ない、という点です。

見かけのズレは本物で、その最悪例

sjdirect/abot は .NET のクローラーで、stars は 2,308。GitHub は 2026-07-17 に push があったと表示します。基準日より 10 日前です。しかし、デフォルトブランチの最後の更新は 2021-08-09 でした。

差は 1,802 日。5 年です。ヘッダーだけ見ると「先週更新」と出ます。

35 件中 14 件で、180 日超のギャップがありました。

14 / 35。実際に起きていて、知っておく価値があり、しかもその現象を含むよう選んだサンプルの中では少数派です。

3 件ではボットが確認でき、絞り込み後に残るのは 2 件

この手の話では、よく dependabot の名前が挙がります。そこで、各フラグ付きリポジトリの activity feed を取り、最後のデフォルトブランチコミット以降に push された ref をすべて分類しました。この「以降」が重要です。最後のコミットより前のイベントは、その差を膨らませた原因にはならず、フィード全体を数えると問い自体が変わってしまうからです。

ポストコミット方式でボット起因と確認できたのは 3 件。 scrapinghub/splash（post-commit の 4 / 4 が dependabot/pip/*）、geziyor/geziyor（5 / 5 が dependabot/go_modules/*）、apache/any23（16 / 16 が dependabot/maven/*）です。この 3 件のうち any23 は正式にアーカイブ済みなので、フィルター後の対象には入りません。結果として、他の条件もすべて満たす確認済み事例は 2 件 です。

明確に違うものが 2 件。 しかもどちらも、ボット説より面白いです。

dragnet-org/dragnet の 1,520 日ギャップは、人間が mp/py3.10 というブランチを push したことに由来します。これはマージされなかった Python 3.10 への移植です。誰かが更新を試み、途中で止まった。これは自動ノイズでタイムスタンプが膨らんだのではなく、失敗した救済試行の記録が見えているのです。むしろこのデータセットの中で最も有用なシグナルとも言えますし、「dependabot がやった」とまとめてしまうと消えてしまいます。

混在していて、しかもどちらよりも大きいものが 2 件。 crawlab-team/crawlab は stars 12,250 で、サンプル中 2 番目に star が多いリポジトリです。main には 488 日のギャップがあります。activity feed には dependabot のブランチに加えて、人間による post-commit push が 24 件あり、しかも全部 develop と test に向けられていました。ヘッダーだけ見れば 2026 年 2 月で「まだ元気そう」に見えますが、main だけ見れば 2024 年 10 月で「終わった」と見えます。どちらも違います。開発はデフォルトブランチの外へ移っており、これは実際に起こることですが、GitHub の要約表示では表現できません。sjdirect/abot も同じく混在事例です。見出しの pushed_at を作った push 自体は dependabot でしたが、2024 年に人間が upgrade1 を push しているため、後の絞り込みでは除外されます。

Rhizome-Conifer/conifer は判断が難しく、最初の読みでは私も誤りました。デフォルトブランチは master ではなく main で、main は 2023-10-12 以降止まっています。feed 内の main イベントは 2025 年 1 月のブランチ作成のみで、これはリネームと整合的です。一方で、1 つのアカウントが 2026-07-22 に conifer-twilight と twilight/read-only に push しており、基準日の 5 日前です。これは本物の人間活動ですが、「活発に開発されている」と言い切るには refs が弱いです。1 人の貢献者が、read-only と名付けたブランチで作業しているのは、継続開発というより、管理された終了のほうとも十分に整合します。ここで言えることはもっと狭いですが、それでも意味があります。つまり、1,013 日のギャップはボットノイズではないが、だからといって放棄の証拠でもない、ということです。

不明が 7 件。 php-html-parser、simhash-py、internetarchive/wayback、boilerpipe、waybackurls、wpull、crawler4j は、いずれもギャップは確認できましたが、activity feed は空で返ってきました。

つい考えたくなるのは、GitHub の activity feed は永遠には遡れないので、単なる保持期間の問題ではないか、という説明です。ところがキャッシュを見ると、多くのケースでそれは否定されます。123 件のレスポンスの中で最も古いイベントは 2023-03-10 で、7 件中 5 件は pushed_at がこの範囲内に余裕で入っています。php-html-parser は 2024-08-09、wpull は 2024-04-29、waybackurls は 2024-05-01、internetarchive/wayback は 2024-03-01、simhash-py は 2023-05-15 です。これらのタイムスタンプを動かした何かは feed に出ているはずなのに、出ていません。保持期間で説明できるのは boilerpipe（2018）と crawler4j（2021）だけです。

したがって、正直な言い方はもっと細くなります。7 件について、ギャップがあるのは確認済みだが、その原因は未確定です。エンドポイントは何も返さず、しかもそのうち 5 件は理由を特定できません。「dependabot がやった」というのは 7 件すべてに対する憶測です。

14 件のフラグ付きリポジトリをまとめると、こうなります。

合計は 14 件です。これは pushed_at を動かしたものを分類しただけで、プロジェクトが放棄されたかどうかを独立に証明するものではありません。

フィルターをすべて通るものと、「通る」の意味

元の主張には 4 条件が同時に必要です。1 年超の停滞、pushed_at が 180 日以上膨らんでいること、アーカイブされていないこと、そしてその膨らみが人間作業ではない兆候があること。35 件中 9 件がこの 4 条件すべてを満たし、その右に、特に重要な 2 つの除外例を並べるとこうなります。

この数字には、フィルターだけでは持てない注釈が必要です。9 件のうち、ボットが膨らませたと積極的に示せるのは splash と geziyor の 2 件だけです。残り 7 件は、どちらの方向の証拠もないという理由で条件を通っています。つまり、主張を生き延びたケースではあっても、確認済み事例ではありません。そして、この監査全体で最も強い確認である any23（dependabot イベント 16 / 16） は、リポジトリがアーカイブ済みのため除外されます。

また、1,802 日のケースである abot はこの 9 件には含まれません。レコードに人間の push があるため、4 条件目を満たさないのです。つまり、データセットの中で最も派手な見かけのズレは、その仕組みの“きれいな例”ではありません。

35 件中 21 件は、GitHub が停滞をそのまま示していた

私の仮説に最もダメージを与えたのは、この結果でした。14 件はギャップがちょうど 0 で、さらに 7 件は 180 日未満です。35 件中 21 件では、pushed_at がそのままデフォルトブランチの最新コミットです。GitHub が何かを隠しているわけではありません。

サンプル中でも特に古いものを含めると、こうなります。

BuilderIO/gpt-crawler は 22,374 stars で、ヘッダーは 2025-07-07 からずっと同じことを言っています。何も隠されておらず、インストール数は今も伸びています。

つまり、主張はもっと狭い形に落ちます。GitHub が停滞を見えにくくしているのは少数派で、むしろ多数派では停滞をそのまま示しているのに、インストールは続いている、ということです。なぜ続くのかはこのデータでは分かりません。ここで数えているのは「誰が使っているか」ではなく「どれだけ入っているか」だからです。ただし、UI を変えても多数派には効きません。問題はむしろそちらです。

リポジトリ活動と公開済み成果物はずれることがある

データセットの中で最も印象的な 1 行は、この見方自体を崩します。

codelucas/newspaper は stars 15,126 で、アクティブです。最新のデフォルトブランチコミットは 2026-07-21、基準日 2026-07-27 の直前で、しかも maintainer 自身のコミットでした。リポジトリレベルのチェックはすべて通っています。

しかし、誰もがインストールしているのは newspaper3k 0.2.8 で、公開日は 2018-09-28。つまり 2,858 日前 です。それでも月 813,513 ダウンロードあります。

デフォルトブランチは新しいのに、PyPI の成果物は 2018 年以来出ていません。これはリリースの空白を示しているのであって、なぜリリースされないのか、あるいはパイプラインが壊れているのかまでは分かりません。ただ、pip install newspaper3k の後に普通は動くのがレジストリ上の成果物である以上、リポジトリだけを見て保守状況を判断する方法では見逃されるリスクがあります。

パッケージ視点で見ると、このパターンはあちこちにあります。帰属が確認できた 17 個のパッケージのうち、16 個は最後の公開が 1 年以上前 で、その 16 個だけで月間インストール数およそ 230 万件中 228 万件 を占めています。

tls-client は別枠で触れる価値があります。月 790,305 インストール あり、しかも 905 日止まったリポジトリから配布されています。こういうカテゴリでは、最新性を保つこと自体が仕事です。ブラウザの TLS 挙動は変わるので、2024 年前半で止まったライブラリは 2024 年前半の前提で動いてしまいます。

この表には 2 つ注意点があります。レジストリのダウンロード数には CI 実行やミラーも含まれ、重複排除はされません。つまり、これは「人間の利用数」ではなく「インストール量」です。また、集計の対象期間の終了日がそろっていません。npm は 2026-07-24 に近く、pypistats は取得時点基準です。そのため、合計は少しずれた月の和であり、桁まで厳密に読むより「およそ 228 万件」と見るべきです。

知っておくべき名前の衝突

internetarchive/wayback は古い Java の OpenWayback で、1,916 日止まっています。PyPI の wayback はまったく別のプロジェクト、edgi-govdata-archiving/wayback で、基準日の 5 週間前、2026-06-19 に 0.5.1 を出しており健全です。同名で、状態は正反対、関係はありません。これは却下した 6 件の帰属の 1 つですが、実ユーザーにとっては特に危険です。名前で検索すると両方出てきて、どちらを見つけたのかはどちらのページにも書いてありません。

アーカイブ済み、非推奨、そして月 127,232 回インストールされ続けるもの

サンプルの 6 件には archived: true が付いており、GitHub では全幅のバナーとして表示されます。最初は「大きな警告があっても人は無視する」という証拠かと思いました。しかしキャッシュを見てみると、話はそれよりもっと悪いものでした。

公式参照: npm download-count API documentation。

公式参照: npm の deprecation ドキュメント。

@modelcontextprotocol/server-puppeteer は modelcontextprotocol/servers-archived から月 127,232 回インストールされています。しかし npm の repository フィールドは null で、パッケージページからリポジトリへのリンクがありません。つまり、インストーラーがバナーを見落とした、という話ではないのです。多くの人はこのパッケージにたどり着く導線自体を持っていませんでした。

npm が実際に出している警告は deprecation です。このパッケージの最新バージョンには deprecated: "Package no longer supported. Contact Support at https://www.npmjs.com/support for more info." が入り、インストール時にターミナルへ表示されます。つまり警告は、ユーザーが実際にいる場所に届いています。それでも月 127,232 回のインストールが続いている。これはバナーの話よりも強い事実で、示している問題も違います。つまり、信号が無いのではなく、誰も読むことを強制されないインストール出力の海の中に届いている、ということです。

browserbase/mcp-server-browserbase は、きれいな終了例です。最後のデフォルトブランチコミットは 2026-07-20 で、内容は文字通り "Mark repository as archived and unmaintained (#198)" でした。保守終了を明言し、日付も入れ、API 上でもフラグを立てています。とはいえ、20,389 回のインストールは注意して読むべきです。npm の集計期間は 2026-06-25〜2026-07-24 なので、この 30 日のうち 26 日はアーカイブコミットより前 です。数字の大半は終了告知前の需要であり、告知への反発ではありません。その後どうなったかは、このスナップショットからは本当に分からないので、何かを断定するなら 1 か月後にもう一度見るべきです。

57 stars で月 204,025 インストール

Janpot/microdata-node は 57 stars しかないのに、2020-05-11 公開の成果物から月 204,025 回ダウンロードされています。

57 stars という低いリポジトリ可視性に対して、レジストリの規模はかなり大きいです。インストール対 stars の比率 3,579:1 は、間接利用、CI の繰り返し、ミラー、あるいはマシンによる直接消費と整合しますが、この監査では依存グラフを取得していないため、どれか 1 つに決めることはできません。

この行は、間接的な露出を棚卸しする必要があることを示すきっかけにはなりますが、実際に間接依存かどうかを証明するには、逆依存や lockfile の証拠が必要で、今回の監査ではそこまで集めていません。

古いことは、壊れていることと同じではない

正直な監査なら、ここははっきり言う必要があります。ここで測っているのは、何かが壊れているかどうかではありません。 ここで測っているのは、誰かがまだそこにいるかどうかです。

この中には、単に役目を終えたものもあります。SetSimilaritySearch は集合類似度アルゴリズムを実装しており、そう簡単には腐りません。simhash は 2007 年の論文です。boilerpipe のコンテンツ抽出アルゴリズムは、2026 年でも 2015 年でも同じように動きます。現代のページに対する精度は別として、コードが足元から崩れているわけではありません。

一方で、時間とともに腐るのは、相手側が動き続けるものです。

• ブラウザ自動化 — Chrome の更新 1 回で壊れることがあります。
• 実ブラウザに近い HTTP クライアント — ブラウザは変化し、固定されたライブラリは追従できなくなります。tls-client がこれに当たります。
• サイト固有のパーサーや抽出ルール — サイトが少し設計変更するだけでバグになります。
• 第三者 API を包むもの — ベンダーがスキーマを変え、初めて本番で気づきます。
• LLM を包むもの — モデルの非推奨化は、このどれよりも速く進みます。

つまり、「1,606 日古い」はあるカテゴリでは緊急事態ですが、ハッシュ系ユーティリティにとってはほぼ無関係です。ここでは壊れているかどうかは試していませんし、その主張もしていません。自分の依存先を、どのカテゴリに属するかで並べ替えるだけで、停滞日数の数字単体よりはるかに役立ちます。

本当に答えを出す 4 つのチェック

リポジトリのヘッダーは、その中のどれでもありません。

check 1、2、3 は高速トリアージとして使います。そこから、リポジトリメタデータがない、パッケージの対応付けが曖昧、活動がデフォルト以外のブランチへ移っている、レジストリ成果物がリポジトリとずれている、のいずれかなら深掘りします。GitHub の認証なし制限とレジストリの遅延を考えると、1 秒で終わる約束は現実的ではありません。

もし何かが、動きの速いカテゴリで古くなっていたら、その分野で保守された代替手段は私たち自身の検証でも示しています。dragnet や boilerpipe が担っていたコンテンツ抽出には Trafilatura、クローリング基盤には Scrapy や Crawlee、LLM 向け抽出には Crawl4AI と Firecrawl、耐性が重要なら Scrapling が候補です。より広い一覧は open-source scraper の包括記事 にまとめています。これらは一次情報としてのレビューです。私たちのおすすめを含め、何かを信じる前に、まず 4 つのチェックを自分で回してください。

このデータの限界

• サンプル選択。放棄が疑われるものを手で選んでいます。エコシステム全体の率はここから読めません。
• 壊れているかの検証なし。35 個のツールは 1 つも実サイト相手に動かしていません。古さは保守シグナルであって、機能の判定ではありません。
• ダウンロード数には機械が含まれる。CI、ミラー、重複排除なし、しかも期間の終了日がそろっていません。ユーザー数でも意思決定数でもなく、インストール量です。
• 7 件の原因不明は、そのまま不明。activity feed は空で、7 件のうち 5 件は保持期間でも説明できません。空欄のままにするほうが、人気の推測で埋めるよりましです。
• staleness_days はコミッター日付を使う。履歴の書き換えや backdate があれば歪みます。検出はされませんでしたが、存在しないことの証明ではありません。
• 基準日は 1 つ。2026-07-27 です。これを読む頃には、いくつかのリポジトリはすでに動いているはずです。特に newspaper は定期的にコミットがあります。私の日付を引用せず、4 つのチェックを再実行してください。

マネージドサービスで何が変わるか

ここで挙げた各チェックは、セルフホストのライブラリを使う限り、停滞を自分で抱える から必要になります。固定された HTTP クライアントが今のブラウザのように振る舞わなくなったら、その障害は、何時に表面化してもあなたの事故です。

著者注: Thunderbit は当社のマネージド型スクレイピング製品です。マネージドサービスは保守責任の一部をベンダーに移しますが、カバレッジ、応答時間、ロックイン、ベンダー継続性がリスクモデルに入ってきます。Thunderbit 自体は今回のリポジトリ監査では評価していません。

率直に言えば、ソースを読めること、バージョンを固定できること、自分で 2 時に直せることを手放す代わりに、保守の一部を任せることになります。すでにスクレイパーを維持しているチームにとっては、オープンソースのほうが正しい判断であることも多いです。その判断を、思い込みではなく判断にするための方法が、この 4 つのチェックです。

Thunderbit で Web データ抽出を試す

要点だけ

GitHub が放棄を隠していることを示すためにリストを作りました。14 / 35 のリポジトリで見かけのズレは本物で、1 件は特に派手です。sjdirect/abot は 2021 年以降止まったデフォルトブランチに対して「先週 push があった」と表示され、1,802 日のギャップがありました。

しかし、仕組みは話ほど広くありません。9 件が主張に必要な 4 条件をすべて満たし、そのうちボットが膨らませたことを積極的に示せるのは splash と geziyor の 2 件だけです。残りは証拠がないから通っているにすぎません。2 件は、人間が復活させようとして失敗したケースでした。crawlab は stars 12,250 で、単に開発先を develop に移していました。7 件は activity feed が空で、そのうち 5 件は保持期間では説明できず、原因は未確定です。そして 35 件中 21 件では、GitHub は停滞を正確に示していました。

データセットで最悪のケースは、リポジトリレベルのチェックをすべて通過します。codelucas/newspaper は 2026-07-21 にコミットされており、2018-09-28 を最後に公開された newspaper3k はその月だけで 813,513 回 配布されました。サンプル全体では、1 年超前のリリースを持つ 16 パッケージが、月およそ 228 万インストール を占めています。

まずはデフォルトブランチのコミット日、レジストリの公開日、archived フラグ、npm の deprecation フィールドを確認してください。そのうえで、パッケージとリポジトリの対応関係、デフォルト以外のブランチでの開発状況を見てから結論を出すべきです。

Thunderbit で Web データ抽出を試す Get Started Free

FAQ

pushed_at とは何ですか？ なぜ「最終更新」と同じではないのですか？
pushed_at は GitHub API のフィールドで、リポジトリページのアクティビティ時刻の元になっています。どのブランチにでも push があると更新されます。一方、デフォルトブランチの最新コミットはリポジトリ保守状況の 1 つの指標にすぎません。パッケージマネージャーは通常、レジストリ成果物や解決済みモジュールのバージョンをインストールします。この監査では、35 件中 14 件でこの 2 つの GitHub 日付が 180 日以上ずれていました。

そのタイムスタンプを膨らませているのは、いつも dependabot なのですか？
いいえ。むしろそれが、よくある説明の弱いところでした。最後のデフォルトブランチコミット以降に起きたイベントだけを数えると、ボットが確認できたのはフラグ付き 14 件中 3 件です（splash は 4 / 4、geziyor は 5 / 5、any23 は 16 / 16）。2 件は明確に違っていて、dragnet のギャップは、人間が未マージの Python 3.10 移植を push したことによるものです。さらに 2 件は混在型で、crawlab では 24 件の人間による push が develop と test に向かいましたが、main は止まったままでした。そして 7 件は activity feed がまったく返らなかったため原因は未確定で、そのうち 2 件だけが保持期間で説明できます。

古いリポジトリは、そのツールが壊れていることを意味しますか？
この証拠だけではそうは言えません。ここでは実サイトに対する実行テストはしていません。古さが問題になる度合いは、対象がどれだけ速く変化するか次第です。ブラウザ自動化、ブラウザ挙動を模した HTTP クライアント、サイト固有パーサー、API/LLM ラッパーはすぐ古くなりますが、SetSimilaritySearch や simhash のようなアルゴリズム系ライブラリは何年古くても問題ないことがあります。サンプル中で最も厳しいケースは tls-client で、905 日止まったリポジトリから月 790,305 回インストールされています。

リポジトリはアクティブなのに、パッケージは古いまま、ということはどう起こるのですか？
それが codelucas/newspaper で、この監査で最も重要な発見でした。デフォルトブランチは基準日の数日前である 2026-07-21 にコミットされていますが、PyPI の newspaper3k は 2018-09-28 の 0.2.8 を最後に出したままで、しかも今でも 月 813,513 回 ダウンロードされています。リポジトリレベルのチェックはすべて通りますが、実際に入る成果物は 8 年前のものです。コミットログとは別に、レジストリの最新公開日を必ず確認してください。

アーカイブ済みのリポジトリなら解決しますか？ GitHub にはバナーが出ますよね。
それだけでは不十分です。@modelcontextprotocol/server-puppeteer がその理由を示しています。npm の repository フィールドは null なので、パッケージからアーカイブ済みリポジトリへのリンクがなく、バナーを見落とすという話にもなりません。npm が実際に表示するのはパッケージの deprecated 文字列 — "Package no longer supported" — で、これはインストール時に出力されますが、それでも 月 127,232 回 のインストールは続いています。browserbase/mcp-server-browserbase は最終コミットで正式に終了を告知しており、その 20,389 回のインストールの大半はその前のものなので、どちらの意味でも多くは語りません。

自分の依存関係を素早く確認するには？
まず、デフォルトブランチのコミット日、レジストリのバージョン／公開日、npm の deprecation フィールド、リポジトリの archived フラグを確認してください。次に、パッケージとリポジトリの対応付けを検証し、活動がずれているならデフォルト以外のブランチを見て、露出が間接的かどうかは dependency graph や lockfile で判断します。無関係な Java 版と PyPI 版の wayback のような名前衝突があるので、この段階的な確認は必須です。