AI クローラの負荷に耐えるオープンアーカイブの設計

オープンな技術アーカイブには、人が根拠を確かめ、機械がページごとに許可を求めず情報を取得できるという約束があります。人向けの画面を無制限の抽出 API のように使うクライアントが現れると、その約束は脆くなります。kernel.org が公表した計測は、公開データを閉じるべきだという話ではありません。アクセス表現の選択によって、開放性のコストを誰が負担するかが決まるという警告です。

同サイトは、Git の本来の転送方式ではなく、レンダリング済みのコミットページを継続的に要求するトラフィックを説明しています。そこから全リクエストの発信者や、特定の AI 企業の関与までを断定することはできません。しかし、コードブラウザ、文書サイト、公開データベース、課題管理システムに共通する問題は分かります。有限の資料でも、サーバーにとって高価なページ表示の組み合わせはほぼ無限になり得ます。

リクエスト数ではなく表現ごとのコストを測る

二つの URL の処理量が大きく違うなら、リクエスト数だけでは容量を判断できません。リポジトリの clone は整理済みオブジェクトを転送し、利用者がローカルで辿れます。一方、コミットページは履歴解決、レンダラ、ナビゲーション生成、新しい HTML の作成を要求することがあります。どちらも公開読み取りですが、CPU、キャッシュ、運用上の注意の消費は同じではありません。

まず公開ルートを棚卸しします。静的配信、キャッシュ参照、DB 検索、履歴走査、全文検索、差分生成、サーバー側レンダリングのどれを起こすかを記録し、中央値・末尾遅延、CPU 時間、キャッシュヒット率、クライアントごとの固有 URL 数を重ねます。同じ記録に対する並べ替え、絞り込み、ページ番号をクローラが別ページと見なす前に、等価な URL 群を把握することが重要です。

低コストな一級の経路を用意する

フッターに隠れた一括ダウンロードはアクセス戦略ではありません。ネイティブプロトコル、スナップショット、文書化した API、RSS/Atom、署名済みダンプがあるなら、何に使え、いつ変わるかを明示します。人向け画面の近くと、適切な機械可読の発見点から案内し、ページを一枚ずつ取得するより望ましい経路を容易にします。

ソースアーカイブならコミット画面の巡回ではなく clone や fetch、公開記録なら日付付きエクスポートと増分フィード、文書なら安定 ID の版付きバンドルが候補です。いずれも再現性を高めます。ただし代替経路にもページサイズ、カーソル、フィールド、変更意味論の上限が必要です。無制限検索や任意結合を許せば、高価な処理を別 URL に移すだけになります。

人のページを守り、機械の仕事に予算を置く

人が読むページは検証、リンク、アクセシビリティ、通常の検索に必要です。安定応答をキャッシュし、無害な URL 変種を正規化し、ページングに上限を置き、無限のフィルター組み合わせを作らないことで守れます。canonical URL は利用者とクローラを同じ文書へ集め、キャッシュキーの増殖も抑えます。

制限はコストに応じて設定します。軽量ページとオンデマンドの差分や検索は別の耐性を持ちます。高価な操作そのものに同時実行数とタイムアウトを設け、匿名の急増が閲覧者や協力者の容量を奪わないようにします。キャッシュ結果、Retry-After、バルク経路へのリンクを返す方が、レンダラを予測不能に失敗させるより良い場合が多いでしょう。

防御がアクセスを壊していないか測る

robots の規則は希望を伝えられますが、RFC 9309 の下で認可制御ではありません。クローラ指針、レート制限、観測と組み合わせる必要があります。協力的なクライアントには識別子、連絡先、文書化した制限、最も安い表現を期待できます。識別子がない、または誤っている場合にも機能する技術的な制御は別途必要です。

チャレンジ画面や広い IP ブロックは負荷を下げる一方、読者、支援技術、ミラー、正当な自動化も締め出し得ます。高価なルート量、固有パスの増加、レンダラ飽和と、通常訪問の失敗、既知の有用ルートの遅延、承認済みバルク利用者の体験を並べて評価してください。公開性は壁の有無ではなく設計です。データを持ち運べるようにし、人のページを読みやすくし、計算集約的な経路に確かな予算を置けば、アーカイブは人とツールの双方に開かれ続けます。