Kernel.orgの不気味なクローラーが、オープンアクセスをCPU税に変えている
Konstantin Ryabitsevによると、不気味なクローラーは、自動スクレイピングのコストを高めるために設計された防御策にもかかわらず、git.kernel.org全体で14〜16個のCPUコアを常時稼働させている。クローラーは基盤となるGitリポジトリをクローンする代わりに、数百万もの個別コミットページを要求する。この選択により、効率的な公開アーカイブが、正体不明のマシン向けの恒久的なHTMLレンダリングサービスへと変えられている。
kernel.orgのインフラに関わるLinux Foundationのシステム管理者であるRyabitsevは、2026年8月29日にこの数値を公表した。Simon Willisonは、Datasetteにも同様のリスク特性があるとして、9月7日にこれを取り上げた。Datasetteはデータベースを、膨大な数の有用でクロール可能なページとして公開できる。
当面の話題はLinuxのインフラだが、この対立ははるかに広い範囲に及ぶ。オープンな技術アーカイブは、人々が情報を調査し、参照し、保存できるよう設計されてきた。マシン規模のクライアントは、その開放性を、対価の設定されていないコンピューティング負担へと変え得る。
この逆転は、とりわけgit.kernel.orgで際立っている。管理者はすでに、履歴全体を効率的に転送するために作られたプロトコルであるGitを通じて、完全なリポジトリ履歴を提供している。それでもスクレイパーは、コミット、パッチ、差分ごとに個別レンダリングされたページを要求するという、計算コストの高い経路を選んでいるとされる。
この振る舞いは、正当な開発者が利用するインターフェースを管理者に制限させる圧力となる。Ryabitsevによれば、サービスは依然として応答性を保っているが、すでに機能の無効化や、より多くの操作をアクセス制御の背後に置く対応が進んでいる。したがってクローラー急増のコストは、CPU時間だけでなく、失われる開放性としても測られる。
不気味なクローラーが1日600万リクエストを生み出す
規模は、サイトが人間の訪問者には健全に見える場合でも、インフラを継続的に消費するほど大きい。
Ryabitsevのクローラー計測では、一見ランダムなコミットに対するリクエストが1日約600万件に達すると説明されている。メインサイトの前に配置されたブラウザチャレンジであるAnubisは、それらのリクエストのおよそ66%を即座に拒否する。残りの33%はチャレンジを解き、git.kernel.orgへ進む。
この数値は、チャレンジを受けたすべてのリクエストがAI企業からのものだと証明するわけではない。Ryabitsevは、運用者がすべてのクライアントを確実に特定できるわけではないと明言している。人間が古いコミットを開くこともあれば、ボットが最新のブラウザを装うこともある。
最も強い証拠となるのはリクエストのパターンだ。古く活動していないフォークの無関係なコミットをたどるクライアントは、パッチシリーズを追う開発者には見えない。Ryabitsevは、利用者に有利な仮定を置いた後でも、正当な活動は総トラフィックの約2%にすぎないと見積もっている。
結果として生じる負荷は、地理的に分散した5つのノードにある90個のCPUコアのうち、14〜16個を占有している。これは平均でサービス全体の処理能力のおよそ20%に相当する。実際の需要は波のように到来するため、負荷は固定的な20%の割り当てほど整然としてはいない。
それらのコアは限定的な作業を行っている。GitオブジェクトをHTMLページに変換し、クライアントはそのレンダリング結果を解析する。Ryabitsevによると、この活動はGitクローンを含むあらゆる正当なアクセス形態を合計したよりも多くのCPU時間を消費している。
この違いは重要だ。クローンはGit本来のオブジェクトモデルを通じてリポジトリを転送する。クライアントは履歴を受け取り、ローカルでコミットをたどれる。サーバーは、クライアントが調べたい各オブジェクトのために表示用ページを再構築する必要がない。
HTMLリクエストはこの効率性を反転させる。各リクエストは、サーバーにリポジトリデータの検索、cgitの実行、人間が読める応答の構築を求める。クライアントは欲しいテキストを抽出した後、周囲のインターフェースの大部分を捨てる。
数百万のURLにまたがって繰り返されると、個別には妥当に見えるページが高コストなマシン向けエンドポイントになる。従来のキャパシティプランニングでは、ページビューを同程度の作業単位として扱うことが多い。git.kernel.orgの事例は、URLごとに引き起こす計算量が大きく異なり得る場合、そのモデルがなぜ破綻するかを示している。
サービスは現在のバックグラウンド負荷で停止してはいない。Ryabitsevによると、設計の不十分な継続的インテグレーションシステムは、特に多数のノードが同時に浅いクローンを実行する場合、より深刻な障害を引き起こし得る。クローラーのトラフィックは、運用上の余力を恒常的に奪うという別種の問題を生む。
失われた余力は、トラフィック急増、保守イベント、正当な自動化への耐性を低下させる。また、運用者はカーネル開発者向けサービスの改善ではなく、敵対的な振る舞いの調査に時間を費やさざるを得なくなる。そのため、一見安定しているウェブサイトにも、かなりの隠れたコストが存在し得る。
決定的な変化は、公開ソースコードをダウンロードできることではない。Kernel.orgはその利用を意図的に支援している。変化したのは、正体不明のクライアントがコストの高い表現形式を選び、それを産業規模で要求していることだ。
Gitはデータを安価にするが、HTMLは高コストにする
中心的な対立は、アクセスと秘密保持の間のものではない。効率的な一括アクセスと、無駄の多いページ単位の抽出との対立だ。
Linux開発は常に複製の恩恵を受けてきた。Gitリポジトリはクローンでき、メーリングリストのアーカイブはコピーでき、ミラーは単一サーバーの寿命を超えて資料を保存できる。Kernel.orgは、すべてのダウンロードを脅威として扱うのではなく、この冗長性を奨励している。
Gitは、オブジェクト間の関係に従って転送することで、このモデルを経済的なものにしている。リポジトリはコミット、ツリー、ファイル内容をアドレス可能なオブジェクトとして保存する。クライアントとサーバーは、クライアントに不足しているオブジェクトを交渉し、各コミットの周囲にウェブページを再作成せずに必要なデータを転送する。
ウェブインターフェースには別の目的がある。開発者が一つの変更を確認し、安定したリンクを共有し、リビジョンを比較し、大規模なリポジトリをクローンせずにパッチをダウンロードできるようにすることだ。git.kernel.orgが使用するインターフェースであるcgitは、それぞれが正当な人間のワークフローを支えるため、複数の表示を提供している。
こうした選択肢は、クロール可能な表面積も増加させる。Ryabitsevの説明によると、Linuxのメインリポジトリには約148万件のコミットがある。Git.kernel.orgには、同じ基盤オブジェクトを大部分で共有する約922のフォークがホストされている。
そのためクローラーは、重複するコミット内容へつながる多数のURLを発見できる。パッチ表示、プレーンテキストのレンダリング、リポジトリツリー、任意の比較も要求できる。コンテンツは有限だが、可能なURL空間ははるかに大きくなる。
これはデータベース駆動型ウェブサイトでよく見られる失敗モードだ。データベース内のレコード数は管理可能でも、そのインターフェースが無数のフィルター、並べ替え、ページネーション、比較の組み合わせを許すことがある。無差別なクローラーには、生成されるすべてのルートが別のドキュメントに見える。
Willisonはこのパターンを、ウェブ上で検索可能なデータベースを公開するための彼のオープンソースツール、Datasetteに結び付けた。Datasetteインスタンスは構造化情報を閲覧可能なページやクエリ結果に変換できる。このアクセス性は、人々、検索エンジン、研究者、支援ツールにとって価値がある。
一方で、コストの高いパラメーターの組み合わせを公開する可能性もある。ボットが有害な負荷を生み出すのに悪意あるコードは必要ない。アプリケーションが低コストで処理できる速度を上回って、リンクを列挙するか有効なURLを組み立てるだけでよい。
同じリスクは、ドキュメントシステム、課題トラッカー、コードブラウザ、公共記録ポータル、個人アーカイブにも当てはまる。構造化データをオンデマンドで変換するサイトは、各取得でデータベース処理やサーバーサイドレンダリングが発生し得るため、静的ページより脆弱だ。
多数のクライアントが同じリソースを要求する場合、キャッシュは役立つ。しかしクローラーが意図的に、または偶発的に、一意のURLへリクエストを分散させる場合には効果が薄い。クエリパラメーター、任意の差分、古いフォークは、キャッシュの価値を生む再利用を妨げ得る。
運用者は人気のページを事前レンダリングできるが、可能な比較をすべて事前レンダリングすることは不可能だ。一括エクスポートを提供することもできるが、ウェブリンクを基準に設計されたクローラーは、効率的な経路を発見も選択もしないかもしれない。技術的に利用可能であることは、クライアントが合理的に振る舞うことを保証しない。
検索可能なアーカイブを構築する開発者にとって、これはアーキテクチャ上の警告だ。マシンアクセスには、可能な限り境界の定められたAPI、フィード、エクスポート、リポジトリプロトコルを使うべきである。人間向けインターフェースには、各応答を生成するコストを反映した制限が必要だ。
こうした選択を文書化するチームは、コードと並行して運用上の判断も保存すべきだ。検索可能なエンジニアリング・ナレッジベースは、次のトラフィック波が到来する前に、クローラーポリシー、高コストなルート、インシデントの証拠を結び付けられる。
kernel.orgの事例は、帯域幅が請求書の一部にすぎないことを示している。自動クライアントが動的な表現を繰り返し要求する場合、CPU時間、キャッシュの攪乱、可観測性のコスト、運用者の注意が支配的になり得る。
Anubisはクローラーが支払うまでコストを引き上げた
Proof of workは悪質なトラフィックを一時的に減らしたが、基盤データに価値が残る限り、執拗なクローラーは適応した。
Kernel.orgはまず、よく知られた防御策を用いた。運用者は不審なユーザーエージェント文字列を特定し、ログを調べ、明らかな自動収集に関連するアドレスをブロックした。この方法は、クローラーが自らを識別していた、または管理可能なネットワーク群から発信していた間は有効だった。
その後、トラフィックの分類は難しくなった。Ryabitsevは、通常のブラウザを名乗り、クラウドのサブネット全体にリクエストを分散するクライアントについて説明している。ネットワーク全体をブロックすれば悪用を止められるかもしれないが、同じプロバイダー上でホストされる正当な自動チェックも拒否する可能性がある。
次の変化により、アドレスベースの制御はさらに弱体化した。リクエストは、多数の住宅回線やモバイル回線のアドレスから届くようになった。Ryabitsevによると、各アドレスはログから消えるまでに4〜5件のリクエストしか生成しなかった。
このパターンは、消費者向けデバイスを経由してトラフィックをルーティングするプロキシネットワークに似ている。サイトには、集中したスクレイピング操作ではなく、無関係な利用者からなる幅広い集団が見えているように映る。アドレスが不審に見える頃には、その特定の発信元は二度と戻らない可能性がある。
Kernel.orgは、クライアントがアップストリームサービスに到達する前にチャレンジを課すオープンソースのウェブファイアウォール、Anubisで対応した。その中核となる仕組みはproof of workであり、クライアントには比較的コストがかかる一方、サーバーにとっては検証コストが低い小さな数学的課題だ。
Anubisプロジェクトは、このソフトウェアを、持続的なAIクローラーのトラフィックに直面する小規模なインターネットサービス向けの防御策として説明している。そのメンテナーは、チャレンジが小規模なスクレイパーや正当なアーカイブボットもブロックし得るため、これを厳しい対応とも呼んでいる。
git.kernel.orgでは、チャレンジは当初、経済性を変えた。人間の訪問者はわずかな遅延を受け入れる一方で、自動クライアントはアクセス試行をやめた。この期間は数カ月続いた。
その後、ボットは難易度レベル4を解くようになった。運用者はチャレンジをレベル5に引き上げ、クライアント側により多くの計算を要求した。Ryabitsevによると、この設定ではモバイルデバイスで数秒かかることがあり、スマートフォンが目に見えて熱くなる。
より高い難易度は再び数カ月の猶予をもたらした。しかし同時に、チャレンジを受けるすべての正当な訪問者により大きな負担を課した。古いハードウェア、プライバシー重視のブラウザ、無効化されたJavaScript、不安定な接続では期待されるフローを完了できない場合があり、アクセシビリティが損なわれる。
クローラーは最終的にレベル5も突破した。Ryabitsevが報告した時点で、1日あたり600万件のコミットリクエストのうち約3分の1がチャレンジを通過していた。Proof of workは依然として残り3分の2を阻止していたため無力化されたわけではないが、以前の均衡を取り戻すには至らなかった。
この結果は、経済的抑止の根本的な弱点を示している。チャレンジが機能するのは、コストがスクレイパーにとっての期待価値を上回る間だけだ。価値が高く、整理された技術史は、収集者がより多くのリソースを投じる理由になる。
Ryabitsevは、Linuxのコミット履歴が特に魅力的だと主張する。その多くは、生成テキストが急増する以前に作られたものだからだ。研究者は、合成素材による反復的な学習がモデル品質を低下させたり、アーティファクトを増幅したりする可能性を懸念している。そのため、人間が作成した構造化された技術記録は、望ましい学習素材となる。
クライアントの正確な身元や目的は、依然として検証されていない。モデル学習を支援しているものもあれば、検索インデックス、コードデータセット、セキュリティ製品、商用アーカイブを構築しているものもあるだろう。運用上は、その名称よりも共有された挙動の方が重要である。
Anubis開発者のXe Iasoも、proof of workが完全な解決策ではないと認めている。technical discussionでIasoは、この仕組みが大規模スクレイピングの経済性を狙ったものだと説明する一方、高度な分散クライアントに対する有効性には懐疑的な見方を示した。
ブラウザ自動化を備えたクライアントは、JavaScriptを実行し、Cookieを保存し、人間と同じ公開チャレンジを解ける。分散クライアントは、多数のデバイスに作業を分割できる。難易度を上げれば、十分な資源を持つ収集者を抑止するより早く、正当な訪問者を罰するリスクがある。
Kernel.orgの経験は、本番データによってこのトレードオフを裏づけている。防御は成功し、敵対的クライアントは適応し、運営者はコストを引き上げた。攻撃側と防御側の双方に、変更できる別の設定が残されていたため、この争いは終わらなかった。
オープンアーカイブは有用な機能の削減を迫られている
最も深刻な結果はサーバー料金の上昇ではない。匿名で人間に優しいアクセスが、徐々に後退していくことだ。
Kernel.orgは、クロール可能なURLの数を減らし、実行コストの高い操作にゲートを設ける計画だ。Ryabitsevは、匿名ユーザーは一部の機能が利用できなくなると考えるべきだと警告している。基盤となるデータはダウンロード可能な状態に維持されるが、取得には追加の手順が必要になる可能性がある。
この対応は、インフラ運営者にとって合理的だ。あるインターフェースが不釣り合いな負荷を生むなら、それを制限することはサービス全体を守る。Gitクローンや開発者のワークフローは、任意の比較を無制限かつ匿名でレンダリングすることより重要である。
しかし、あらゆる制限は、誰がアーカイブを利用できるかを変える。Gitをインストールしている開発者は、リポジトリをクローンしてローカルで調べられる。リンクをたどる学生、1件のコミットを確認するジャーナリスト、あるいは制約のあるデバイスを使う人は、ブラウザインターフェースに依存する場合がある。
自動化された調査ツールにも正当な目的があり得る。検索インデックスはユーザーが古い修正を見つける助けになる。アーカイブシステムは証拠を保存する。セキュリティサービスはコミットと脆弱性を関連付ける。アクセシビリティツールは、従来のブラウジングとは異なる形でページを取得する可能性がある。
広範な制限では、こうしたクライアントと悪質な収集者を明確に分離できない。認証は説明責任を生むが、管理作業を増やす。レート制限は急増を抑えるが、リクエストが分散したアドレスから届く場合には機能しないことがある。
住宅回線をブロックすれば実際の家庭を排除することになる。クラウドプロバイダーをブロックすれば、開発者の自動化を妨げる。proof of workを要求すれば、サーバーがリクエストの有用性を判断する前に、すべての訪問者が電力と時間を消費することになる。
Robots.txtはポリシー上のシグナルにはなるが、アクセス制御の仕組みではない。公式のrobots standardは、そのルールが認可ではないと明記している。協調的なクローラーは宣言された意向に従う一方、身元不明のクライアントはこれを無視したり、ブラウザになりすましたりできる。
その結果、非対称性が生まれる。責任ある組織はクローラーを識別し、文書を公開し、除外指定に従うため、ブロックしやすい。責任感に乏しい収集者は身元を隠し、トラフィックを分散させるため、阻止しにくい。
これにより、準拠するクローラーがアクセスを失う一方、回避的なクローラーは動作を続けるという逆説的な結果になり得る。また、トラフィックの帰属も信頼できなくなる。運営者は、特定のモデル開発者へリクエストを結び付けられなくても、ある行動クラスをAIスクレイピングと合理的に表現できる。
この不確実性こそ、この話における主要な懐疑的論点である。Ryabitsevのトラフィック計測は直接的な運用上の証拠だが、すべてのリクエストの目的が独立して確認されたわけではない。98%という推計は、検証済みのAI企業一覧ではなく、見かけ上のスクレイピング挙動に関するものだ。
この区別は、政策と報道の双方を形作るべきである。ネットワーク上の証拠なしに、すべての負荷を特定ベンダーに帰すのは不正確だ。同様に、すべてのクライアントに公的な身元がないからといって問題を退けるのも不正確である。
測定可能な損害は、アプリケーション層で発生している。数百万件のリクエストが古いコミット、重複したフォーク、高コストなレンダリングを選択する。防御チャレンジは多くのリクエストを阻止するが、相当量は計算上の負担を支払って通過し続ける。
Cloudflareは、サイト所有者に検索、エージェント、学習用クローラーに対するより細かな制御を提供することで、この広範な問題に取り組んできた。そのAI traffic controlsは、モデル学習用クローラーとユーザーが要求したアシスタントが同じ目的を果たすわけではないという重要な違いを反映している。
大規模なエッジネットワークは、アドレス情報、ブラウザシグナル、トラフィック履歴、顧客全体からの観測を組み合わせられる。小規模なオープンソースサービスに、その可視性はめったにない。彼らはローカルログと不完全な識別子で判断しなければならない。
この格差は、損害を最も吸収しにくい組織に集中させる。大規模な商用プラットフォームは、より多くの容量を購入し、専門的なボット管理を導入できる。ボランティアプロジェクト、学術アーカイブ、独立系出版社は、単に高コストな経路を閉鎖するかもしれない。
そうしてオープンウェブが失うのは、いくつかのインターフェース機能だけではない。有用でリンク可能な情報を公開することが経済的に安全だという前提そのものを失う。ページは技術的には公開されたままだが、アクセスは条件付き、チャレンジ付き、または一括データのワークフロー経由でしか利用できなくなる。
本当の対立は、オープン性と価格付けされていない計算処理の間にある
オープンデータであっても、可能なあらゆる表現を無料、匿名、無制限のまま維持する必要はない。
クロールをめぐる倫理的議論は、コンテンツをコピーする許可に焦点を当てがちだ。Kernel.orgは、第二の問いを提示している。収集者が望む形式へコンテンツを変換する費用は、誰が負担すべきなのか。
Linuxリポジトリは、すでに効率的な転送手段を通じて利用可能である。運営者は履歴を隠したり、それを独占的に管理しようとしたりしているわけではない。彼らが異議を唱えているのは、公開サービスに対し、より高コストな表現を繰り返し計算させるクライアントだ。
この違いにより、この事例は知識の制限をめぐる単純な議論とは区別される。効率的なクローンでは、転送後の処理コストの多くを収集者が負担できる。コミットごとのHTMLスクレイピングは、繰り返し行われる処理を情報源側に押し付ける。
責任ある収集者は、まず一括エクスポート、リポジトリアクセス、フィード、サイトマップ、文書化されたAPIを探すべきだ。取得済みの素材をキャッシュし、フォークを重複排除し、任意のパラメーター組み合わせを避けるべきである。また、自らを識別し、機能する連絡先を提示すべきだ。
レート交渉も重要である。異例の量を必要とするクローラーは、ミラーや定期エクスポートを運営者に求めることができる。Kernel.orgは、匿名インターフェースがより制限的になっても、リクエストする人々には引き続きデータを提供する意向だとしている。
こうした実践が初歩的に聞こえるのは、成熟した検索エンジンが何十年もかけてそれを発展させてきたためだ。AI需要は、ウェブ規模のデータセットを収集する組織の数を増やした。すべてのチームが同じ運用規範を受け継いでいるようには見えない。
インセンティブも異なる。希少なAI以前の素材を急いで取得する収集者には、迅速に動く利益がある。非効率な収集のコストは、無関係な数千のサイト運営者に降りかかる。契約、執行、信頼できる身元確認がなければ、クローラーがその外部コストを自動的に支払うことはない。
Proof of workは、費用の一部をリクエスト元に戻そうとする試みだ。git.kernel.orgの結果は、このモデルの魅力と限界の両方を示している。限界費用は引き上げるが、価値ある人間のリクエストと、価値ある自動化リクエストを区別することはできない。
クロールごとの課金も別の可能性を生むが、支払いだけではシステム設計の問題を解決しない。価格設定、クォータ、容量制御の整合が取れていなければ、クローラーは依然として動的エンドポイントを過負荷にできる。小規模サイトには、マシンアクセスを交渉するために必要な課金システムもない。
より優れたプロトコルの発見機構が役立つだろう。機械可読なページは、収集者をリポジトリクローン、圧縮アーカイブ、または範囲を限定したデータエクスポートへ誘導できる。クローラーには、依然としてその指示を尊重するためのインセンティブまたは要件が必要となる。
アプリケーション設計は、トラフィックが到着する前に露出を減らせる。開発者は結果サイズを制限し、不合理な比較を拒否し、同等のURLを正規化し、高コストな経路に個別の制限を設定できる。一般的なビューを事前計算し、通常でないクエリに認証を要求することも可能だ。
可観測性では、リクエスト数だけでなく処理量を測定しなければならない。100万件のキャッシュ済み静的レスポンスは、数千件のキャッシュされていないデータベースクエリより低コストになり得る。運営者には、経路別CPU時間、キャッシュ効率、チャレンジ完了率、アドレスをまたいでグループ化されたクライアント挙動が必要だ。
より深い政策課題は、執行可能な身元確認に関わる。運営者と目的を申告するクローラーには、個別化されたアクセスを提供できる。数百万のブラウザを装う分散クライアントは交渉を妨げ、あらゆるリクエストを信頼の判断に変えてしまう。
身元確認が改善されるまでは、防御システムは行動推論に依存することになる。つまり、誤検知は避けられない。実際のユーザーを排除する保護は、それが守ろうとするサービスを損なう可能性があるため、人間へのコストもブロックされたトラフィックと同じくらい真剣に追跡すべきだ。
したがって、creepy crawliesはトラフィック問題であると同時に、ガバナンスの失敗を表している。ウェブには自主的なクローラー行動の規範があるが、その規範を無視するマシン規模のクライアントに対する信頼できる枠組みはない。
圧力が緩和しているかを示す3つのシグナル
次の局面は、トラフィックの挙動、失われた機能、そしてクローラーの説明責任の向上を通じて測定される。
最初のシグナルは、git.kernel.orgのチャレンジ通過率だ。Ryabitsevが数値を公表した時点では、ランダムなコミットリクエストの約33%がAnubisを通過していた。持続的な低下は、新たな制御によって経済的圧力が回復した、またはクライアント分類が改善されたことを示唆するだろう。
通過率が横ばいまたは上昇すれば、逆の方向を示す。収集者が、防御強化のたびに生じるコストを吸収するだけの価値をデータに見出し続けていることを意味する。チャレンジ難易度のさらなる上昇も、この争いが身元確認ではなくコストに焦点を当て続けていることを示す。
2つ目のシグナルは、kernel.orgが削除する匿名機能の量である。異常に高コストな比較に限定した制限であれば、標的を絞った対応といえる。通常のコミット、パッチ、ブラウジング表示にまで損失が広がれば、クローラー圧力が公開体験を変えつつあることを示す。
運営者は、何が、なぜ消えたのかを記録すべきだ。その記録は、他のプロジェクトが同じ状況に至る前に危険なURLパターンを特定する助けになる。また、対策が本来守るべき一般的な人間のワークフローを維持できているかどうかも明らかにするだろう。
第三のシグナルは、大手クローラー運営者が検証可能な身元と効率的な取得経路を採用するかどうかだ。公開されたアドレス範囲、目的別のユーザーエージェント、連絡先情報、そして実効性のあるレート制限ポリシーがあれば、サイトは協調的な自動化と回避的なスクレイピングを区別できるようになる。
こうした説明責任がなければ、防御市場はブラウザフィンガープリンティング、マネージド・エッジ制御、認証、有料アクセスへと移行し続けるだろう。これらのツールは処理能力を守れるが、独立系パブリッシングもより複雑にする。
開発者にとって、直ちに取るべき行動は、どの公開ルートが最も多くのCPUを消費しているか、そして同じ基礎レコードをいくつの異なるURLが公開しているかを調べることだ。バルククライアントが、より低コストなインターフェースを通じて同じ情報を取得できるかをテストする。
その経路を明確に公開したうえで、動的HTML生成には厳格な予算上限を設ける。プルーフ・オブ・ワークの完了率と正規ユーザーの失敗を分けて監視する。防御策は、すべての読者を巻き添えにすることなく、不正な計算を減らすべきだ。
AI開発者にとって、責任ある選択はより単純だ。最も低コストで認可された表現を利用し、クローラーを識別し、サイトポリシーを尊重し、規模を拡大する前に運営者へ連絡すること。オープンアクセスは共有知識を利用するための招待であって、他者のプロセッサを無制限に要求できる権利ではない。
git.kernel.orgの不気味な這い回るものたちは、その境界を可視化した。オープンウェブは機械の読者を受け入れられる。しかし、その機械がすべての公開URLを無料の計算能力として扱うのをやめる場合に限る。
