投稿者 投稿日: カテゴリー AIニュース
Linuxカーネルの公式リポジトリ git.kernel.org は、サーバ能力の約20%をAIクローラー対応だけに奪われています。運用者のKonstantin Ryabitsevが2026年8月29日に公開した実測値によれば、1日約600万リクエストのうち正当なアクセスはおよそ2%にすぎません。これは巨大OSSだけの話ではなく、商品ページと絞り込みURLを大量に持つEC自社サイトにそのまま当てはまる構造です。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）が解説します。
AIクローラーの負荷とは、正規アクセスを上回るサーバ消費のことです
AIクローラーの負荷とは、学習データ収集目的の自動巡回が、人間の利用を上回るサーバ資源を食う状態のことです。git.kernel.org の実測では、5拠点に分散した合計90コアのうち14〜16コアが、常時スクレイパー向けにコミットをHTML描画するためだけに回り続けています。平均すると全体の約20%で、しかも波状に押し寄せるため実際のグラフは平坦ではなく激しく上下します。Ryabitsev はこれを「背景放射」と表現し、スクレイパー向けの描画に使うCPU時間が、git cloneを含む正規アクセス全体よりも多いと述べています。
なぜ狙われるのかという理由も明快です。生成AIの学習では、AIが書いた文章で学習させると品質が劣化するため、生成AI普及前に人間が書いたと保証できるデータの価値が高まっています。カーネルの全コミット履歴やメーリングリストの記録は、その条件を満たす希少な素材というわけです。
問題は集め方の非効率さにあります。git.kernel.org はリポジトリの丸ごと複製を誰にでも開放しており、git clone すれば履歴を一括で取得できます。にもかかわらずクローラーは、1コミットずつHTMLとして描画させて解析するという最も重い方法を選んでいます。linux.git は約148万コミットあり、同サイトには約922のフォークが存在します。バックエンドでは実体を共有しているので負担は小さいのですが、URLとして数えると数十億通りになり、クローラーは同じ148万コミットを922回重複して取りに来ている計算です。差分表示やパッチ形式の出力も加われば、有効URLの数はさらに桁が上がります。
日本のEC事業者にとっての論点は、URL爆発と判別困難とGEOの三つです
日本のEC事業者が受け取るべき論点は三つあります。第一に、URL空間の爆発はEC特有の弱点でもあるという点です。カーネル側で問題になった「同じ実体に無数のURLが割り当たる」構造は、色とサイズと価格帯と並び替えを掛け合わせるファセットナビゲーション、検索結果ページ、ページ送りを持つ商品一覧とまったく同じです。148万コミットが数十億URLに膨らんだのと同じ理屈で、実質1,000商品の店舗が数十万から数百万の有効URLを露出させている例は珍しくありません。総当たりで巡回されれば、CPUと転送量はそこに吸われます。
第二に、ブロックによる自衛が年々難しくなっている点です。カーネル側の対策は、ユーザーエージェントでの判別から始まり、IP単位、サブネット単位、ASN単位へと段階的に強化されましたが、最終的にクローラーは住宅回線やモバイル回線の膨大なIPに分散し、1つのIPあたり4〜5リクエストだけ投げて二度と現れない形に変わりました。背景には、アプリに埋め込まれたプロキシSDKで一般家庭の回線を中継地点として収益化する市場があり、SpurはスマートTVアプリがその供給源になっている実態を報告しています。IPの評判だけで弾く運用が通用しない点は、うるチカラでも住宅プロキシとボット判別の記事で取り上げたとおりです。
第三に、AI検索経由の流入を捨てるのかという判断です。学習用クローラーを止めたいという動機と、AI検索に引用されて指名検索や購入につなげたいという動機は、同じ「AIボット」という言葉の中で衝突します。ここを一括遮断で処理すると、AIボットを用途別に制御する設定で得られるはずだった露出まで一緒に失います。実際にPatreonがコンテンツ保護のためにAIボットを遮断した事例もありますが、商品を売る側が同じ判断をしてよいかは別問題です。
なお、楽天市場、Amazon、Yahoo!ショッピングに出店している場合、モール側のインフラで受けるためこの負荷を直接は負いません。影響を受けるのはShopifyやBASE、STORES、MakeShop、カラーミーショップ、自社構築サイト、そして自社ドメインのブランドサイトやオウンドメディアです。日本のECサイトでAIクローラーが占める割合を示した公的統計は確認できていないため、自社の数値は自分で測る必要があります。この点は要確認としておきます。
初動は実測とURL整理、そして人間への摩擦を増やさないことです
最初にやるべきは実測です。CDNやサーバのアクセスログから、ボット比率、消費CPU、転送量、対象URLの偏りを出します。体感で「重い」と判断してブロックを追加する運用は、カーネル側が通ってきた失敗の再現になります。
次にクロール可能URLの整理です。並び替え、絞り込み、検索結果、印刷用ページといった派生URLに noindex と canonical を適切に当て、robots.txt でパラメータ付きURLの巡回を抑えます。カーネル側も現在は、機能をオフにしてクロール可能URLそのものを減らす方針に舵を切りました。掛け算の元を減らすほうが、入口で弾き続けるより費用対効果が高いという判断です。
三つ目に、人間側の摩擦を増やさないことです。カーネル側は総当たりを止めるため、アクセス前に計算を課す仕組みのAnubisを導入しました。当初は有効でしたが、数か月でボットが難易度4を突破し、難易度5に上げると今度は正規利用者のスマートフォンで数秒かかり端末が発熱するようになり、やがてその難易度5もボットに解かれています。現在は1日約600万リクエストのうち66%をこの仕組みで弾き、33%は計算を解いて通過している状態です。ECでこの手の待ち時間を商品ページやカート導線に置けば、かご落ちに直結します。摩擦をかけるとしても、対象は商品一覧の深いページ送りやAPI的なエンドポイントに限るべきです。
四つ目に、犯人を外部と決めつけないことです。Ryabitsev は、サイトを実際に落とすのはスクレイパーよりも、20台のノードから同時に浅い複製を実行するような設計の悪い自動処理だと指摘しています。ECでも、在庫連携、価格改定、広告フィード生成、レビュー収集といった自社バッチが同時刻に集中して自滅している例は多く、AIクローラーの話題に飛びつく前に自社の定期実行を並べ直すほうが早い場合があります。
まとめ
AIクローラーは、正規アクセスの数十倍のリクエストで自社サーバの2割を持っていく水準に達しています。EC事業者に必要なのは、一括遮断でも放置でもなく、実測、クロール可能URLの削減、AI検索用と学習用の切り分け、そして人間には摩擦をかけないという四つの運用です。まずは自社ログのボット比率を1回測るところから始めてください。
参考文献
- Konstantin Ryabitsev「Creepy crawlies」（2026年8月29日）
- Simon Willison’s Weblog「Creepy crawlies」（2026年9月7日）
- Anubis 公式サイト
- Spur「Smart TV Apps and Residential Proxy SDKs」
- git.kernel.org
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
引用元: Konstantin Ryabitsev「Creepy crawlies」
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
