AI時代のサイバーリスク―クローラーとAIエージェント〈サイバー防衛研究会3月例会報告〉
3月例会では、米国 Cloudflare のField CTO Japanである乙部 幸一朗氏を講師に迎え、「AI時代のサイバートレンド〜AIクローラー問題からAIエージェントまで〜」と題した講演が行われた。AIの急速な進展を背景に、AIクローラーによるスクレイピングの拡大がインターネットのビジネスモデルに与える影響や、AIエージェントの登場によって変化する通信構造と新たなサイバーリスクについて、技術的観点から解説がなされた。
本講演では、AIの急速な普及がインターネットの技術基盤とビジネス構造にどのような変化をもたらしているのかについて、主として「AIクローラーによるスクレイピング問題」と「AIエージェントの台頭」という二つのテーマで解説された。
講演冒頭では、AI市場の驚異的な勢いでの拡大について提示された。代表例として、ChatGPTは、その公開後、約60日で1億ユーザーに到達したとされる。これは過去のPC（16年）やインターネット（7年）の普及と比べても極めて速い。
こうした急激な普及は、単に新しいアプリケーションが増えたというだけではなく、インターネット上のアクセス主体や通信の性質そのものを変え始めていることが示唆された。
講演会データ サイバー防衛研究会3月例会
「AI時代のサイバートレンド〜AIクローラー問題からAIエージェントまで〜」
講演者／乙部 幸一朗（米Cloudflare社 Field CTO Japan）
司会／齋藤 孝道 開催日／2026年3月27日（金）
クローラーとボットの違い
本講演を理解するうえで、まず「ボット」と「クローラー」を分けて考える必要がある。
ボットとは、自動化された処理を行うソフトウェア、ないし通信主体全般を指す広い概念である。たとえば、検索エンジンの巡回プログラム、監視用のアクセス、価格比較システム、予約代行プログラム、さらには不正アクセスや脆弱性探索を行う攻撃ツールまで、いずれも広義にはボットに含まれる。
これに対してクローラーは、Web上のページを巡回し、コンテンツを取得することに主眼を置くボットである。従来の代表例は検索エンジンのクローラーであり、HTMLを取得し、リンクをたどり、ページ構造やテキストを解析 し、検索インデックスを作成するために用いられてきた。
以前は、クローラーとコンテンツ提供者の関係には一種の共生関係があった。検索エンジンはサイトをクロールするが、その代わり検索結果を通じて対象となるWebサイトへの流入を促していた。コンテンツ提供者は、自らのページが検索結果に出ることで閲覧者のアクセスを得て、広告収入や会員登録につなげることができた。つまり、クローラーは一方的な（情報の）搾取ではなく、ある程度は集客を伴う構造の中に位置づけられていた。
しかし、生成AI時代に入り、クローリングの意味は変わってきた。現在のAIクローラーは、単に検索結果を構築するためではなく、学習データや要約生成の素材を収集するために稼働する。処理の流れを単純化すれば、
①Webページの取得
②本文や構造情報の抽出
③データセット化
④大規模言語モデルの学習
⑤推論時の回答生成
という段階をたどる。
ここでは、クローリングされた情報が、最終的に元サイトへの導線としてではなく、AIの回答の一部として再構成される。この点が、従来の検索エンジンとの決定的な違いである。
生成AIの登場によりWebクローリングの意味が変わった
講演では、現在のインターネット通信の約31％がボットによるものであり、人間による通信は69％程度であるという数字が示された。ここで重要なのは、ボットの総量だけではなく、その中身が変質していることである。検索エンジンのような従来型クローラーだけではなく、生成AIの学習や推論支援のためのクローラーが急速に存在感を高めている。
特に印象的だったのは、「クロール回数に対してどれだけ人間の訪問が返ってくるか」という比率の悪化である。講演では、かつてGoogleのクローラーはおおむね2回のクロールで1人の訪問者を送り返していたのに対し、現在ではGoogleで18対1、OpenAIで1000対1から1500対1、Anthropicでは42000対1から60000対1といった水準にまで乖離しているという説明があった。
もちろん、これらは厳密な指標というより、観測に基づく問題提起として受け取るべきだが、示唆するところは大きい。生成AIは大量に情報を取り込む一方で、元サイトへの誘導が極端に少ない。利用者は検索結果上のAI要約や対話型の回答に満足し、原典ページまで行かない。つまり、従来の「クロールする代わりに人を連れてくる」という関係が崩れつつある。
コンテンツ提供者のインセンティブが失われる構造へ
この変化は、コンテンツ制作者にとって極めて大きな意味を持つ。ニュースサイト、専門メディア、ブログ、各種解説ページの多くは、閲覧数や滞在時間、広告表示、あるいは有料会員化によって収益を得ている。ところが、AIが内容を要約し、利用者がその場で答えを得てしまえば、元のサイトは読まれない。広告も表示されず、ブランド認知も進まず、課金にもつながらない。
しかも、生成AIの出力は複数ソースを統合して提示されることが多いため、個々のコンテンツ提供者の寄与は見えにくくなる。一次情報を丁寧に取材した側と、それをもとに後から整理した側との差も、利用者には判別しにくい。こうして、情報を作る側の費用負担だけが残り、便益は別の層に吸い上げられる構図が生じる。
講演では、
『このままではインターネットのビジネスモデルそのものが壊れかねない』
という指摘があった。
これは単に「コンテンツ作成者が困る」という話ではない。信頼できる一次情報や専門的解説を継続して生み出す主体が弱体化すれば、長期的にはAIが学習する基盤そのものも痩せていく。すなわち、情報の再利用モデルが情報の供給基盤を侵食しているという、かなり構造的な問題である。
従来のボット対策では足りない——AIクローラー制御の技術的背景
こうした問題への対応として講演で紹介されたのが、AIクローラーの制御である。ここで技術的に重要なのは、従来のrobots.txtの限界である。robots.txtは、クローラーに対してアクセス可否や巡回範囲の希望を伝えるための規約であり、法的・技術的に強制する仕組みそのものではない。したがって、相手がこれを無視すれば、それだけで取得を防げるわけではない。また、HTTPのUser-Agentヘッダーはアクセス元が自ら名乗る識別情報にすぎず、これだけで相手の正体を信頼することはできない。
そのため、現実の制御には、より多層的な判別が必要になる。講演では、ボット判定技術として、User-Agent文字列だけではなく、アクセス頻度、遷移パターン、接続元の特性、TLSやHTTPの振る舞い、フィンガープリンティングなどを組み合わせて判定していることが示唆された。つまり、「名乗り」だけではなく「振る舞い」も含めて識別する方向である。
また、AI Crawl ControlやPay per Crawlの話も興味深かった。前者は、サイト運営者がどのAIクローラーを許可し、どれを遮断するかを管理する考え方であり、後者はクロールそのものに対価を求めるモデルである。
技術的には、HTTP 402 Payment Requiredのような仕組みが参照されていたが、要するに「取得してよいデータ」と「対価が必要なデータ」を機械的に扱えるようにする方向である。
従来のWebが、人間による閲覧を前提にした無料アクセスモデルを基本としてきたのに対し、AI時代には「自動取得主体にどう課金し、どう制御するか」がプロトコル設計上の論点になりつつあることが分かる。
AIエージェントとは何か―生成AIとの違いとMCPの位置づけ
後半では、AIエージェントの話題に移った。ここでも、生成AIとAIエージェントを分けて理解することが重要である。
生成AIは、基本的には入力された質問に対して文章やコードを返す「（数学の）関数」のような仕組みである。これに対してAIエージェントは、与えられた目的に対して必要な手順を分解し、外部ツールやサービスを呼び出しながら、自律的に作業を進める。
たとえば「大阪出張の交通手段とホテルを手配してほしい」という指示が与えられた場合、AIエージェントは単に候補を列挙するだけではなく、移動日時を確認し、予約サイトにアクセスし、価格を比較し、条件に合う宿を探し、場合によっては予約処理まで行う。このとき、背後では検索、API呼び出し、フォーム操作、決済連携など、複数の処理が連鎖している。
このような外部連携を支える仕組みとして講演で言及されたのがMCP1である。細部の実装は今後も変化しうるが、少なくとも概念としては、AIが外部のツール（アプリケーション）、データソース、サービスとやり取りするための接続規約、ないし文脈共有のための枠組みと理解できる。
AIエージェントが単体で閉じた存在ではなく、さまざまなサービスと接続し、その接続先の能力を組み合わせながら仕事をする以上、そこには標準的な接続インターフェースが必要になる。その意味で、MCPはAIエージェントの実用化を支える周辺技術の一つとして位置づけられる。
講演の文脈では、これからは人間が直接ブラウザで操作するのではなく、エージェントが複数のサイトやサービスにアクセスして処理を代理する世界が広がるという見通しが示されていた。これは、Webのトラフィック主体が人間から機械へ移ることを意味する。
AIエージェントのリスク
AIエージェントの利便性と同時に、乙部氏はそのリスクについても言及した。たとえば、攻撃者がAIエージェントを使えば、従来は人手を要した作業の多くを自動化できるという点である。標的の調査、アタックサーフェス（＝攻撃面）の探索、脆弱性の洗い出し、攻撃コードの生成、さらには侵入後の情報収集までが、一連のワークフローとしてつながっていく可能性がある。
講演では、偽のMCP接続先に誘導するリスクや、人間には見えないがAIには解釈される命令を埋め込む「Shadow Escape」のような手法も紹介された。これは、従来のフィッシングやマルウェアとは少し性格が異なる。人間の判断ミスだけを突くのではなく、AIそのものの解釈過程や自動処理の連鎖を悪用するからである。人が気づかない形でAIだけを誤誘導するという発想は、今後の防御側にとってかなり厄介である。
また、AIエージェントは複数のデータ源に同時接続し、場合によっては継続的に監視・判断・実行を行うため、権限管理の難しさも増す。一つのエージェントに与えた権限が大きすぎれば、侵害時の被害も大きくなる。逆に権限を絞りすぎれば実用性が下がる。ここには、単なるアプリケーションセキュリティではなく、自律的主体にどこまで判断を委ねるのかという設計論が関わってくる。
見えない技術基盤を知らずに、サイバーリスクは語りにくい
講演全体を通じて感じたのは、今日のサイバーセキュリティやサイバーリスクは、従来型の「不正アクセス対策」「マルウェア対策」だけでは捉えきれないということである。
ボットトラフィック、クローラーの振る舞い、CDN2による分散配置、Anycastによる負荷分散、DDoS吸収の仕組み、DNSの使われ方、TLSやHTTPレベルでのフィンガープリンティング、そしてAIエージェントと外部接続の制御。こうした、利用者からは見えにくいさまざまな技術が、現実の防御やリスク管理の前提になっている。
たとえば、多くの利用者はWebサイトを「利用する」だけであり、その背後でCDNがどう動いているのか、どのようにボットが判別され、どの規模のDDoSが分散処理されているのかを意識しない。しかし、現実にはそうした見えない技術がインターネットの安定運用や安全性を支えている。逆に言えば、それらを知らずにサイバー防衛を論じることは、地図を見ずに地形を語ることに近い。
今後、この傾向はさらに強まるだろう。表面上は便利な対話サービスや自動化機能として見えていても、その背後では大量のスクレイピング、AIエージェント、権限制御、マシン間接続が動いている。
サイバーリスクを考えるうえでは、アプリケーションの表層だけでなく、その下で何が起きているのかに目を向ける必要がある。今回の講演は、そのことを示唆していたと言える。
注
