AI-Observatory/1.0 続報—6日後に行動パターンが変化した【AI実験室 #19】
サーバーログから見つかった謎のUser-Agent「AI-Observatory/1.0」が、llms.txtを設置してから6日後に動きを変えました。取得するファイルの種類が増え、来訪頻度も上がっています。前回の記事(AI実験室#18)では「正体不明のまま」で終わっていましたが、新たな実測データが加わったことで、行動パターンがより鮮明になってきました。
現時点では、このエージェントがどの企業・サービスに属しているのかは判明していません。ただし、アクセス元IP・取得対象・巡回順序を追っていくと、単なるクローラーとは異なる特徴も見え始めています。
サーバーログの一次データをもとに、前回観測時との違いと、行動変化の前後を整理します。
この記事でわかること|📖:約7分
- AI-Observatory/1.0の正体と、公式情報がほとんど存在しない理由
- llms.txt設置から6日後に巡回パターンが変化した実測ログの詳細
- AWSバージニア北部というIPから逆算できること・できないこと
- robots.txtで制御できるかどうかと、現時点で取れる対応策
前回観測(AI実験室 #18)のおさらい
2026年4月21日、AI観測ラボのサーバーログに「AI-Observatory/1.0」というUser-Agentが初めて記録されました。主要なAIクローラーリストのどこにも載っておらず、公式ドキュメントも存在しない、正体不明のエージェントです。
前回の観測(AI実験室 #18)で確認できた特徴は以下のとおりです。
| 項目 | 内容 |
|---|---|
| 観測期間 | 2026年4月10日〜24日(約14日間) |
| 総アクセス数 | 30件 |
| IPアドレス数 | 5IP |
| ホスティング | 全件AWS EC2(バージニア北部) |
| 巡回先 | / → robots.txt → sitemap.xml → sitemap_index.xml → llms.txt |
| 記事ページへのアクセス | ゼロ |
| sitemap.xmlのステータス | 404(存在しなかった) |
1IPあたり必ず6リクエストで巡回を終え、記事本文には一切到達しない。サイト構造の「外側」だけを確認して帰る、通常のAIクローラーとは異なる行動パターンでした。詳細はAI実験室 #18をご覧ください。
前回の観測から約3週間後、同じエージェントが再び来訪しました。ただし、行動パターンに変化がありました。
llms.txt設置後、6日間は変化がなかった
2026年5月7日14時21分、AI観測ラボのサーバーにllms.txtを更新しました。llms.txtとはAI向けの案内ファイルで、サイトの概要や記事一覧をAIエージェントが読みやすい形式でまとめたものです。
設置直後から「何かが変わるかもしれない」と思い、ログの監視を続けました。ところが、すぐには何も起きませんでした。
| 日付 | AI-Observatory/1.0の動き |
|---|---|
| 5月7日(設置日) | 来訪なし |
| 5月8日 | 来訪なし |
| 5月9日 | 来訪なし |
| 5月10日 | 来訪なし |
| 5月11日 | 来訪なし |
| 5月12日 | 来訪なし |
| 5月13日 | ✅ 来訪・行動変化を確認 |
設置から6日間、AI-Observatory/1.0のアクセスはログに記録されませんでした。なお、5月9日には別のエージェント「Go-http-client/1.1」(UCloud・中国クラウド)が来訪していましたが、llms.txtは取得しておらず、AI-Observatory/1.0とは別の動きです。
6日間の無反応期間を経て、5月13日15時49分に再来訪が記録されました。そしてこの時点で、前回とは異なる巡回パターンが確認されました。
llms.txt設置と行動変化の間に因果関係があるかどうかは、現時点では断定できません。ただし、タイミングとして6日後に変化が起きたことは、実測ログで確認できた事実です。
5月13日、行動パターンが変わった
5月13日15時49分、AI-Observatory/1.0が再来訪しました。まず実際のログを見てください。
98.81.206.167 [13/May/2026:15:49:54 +0900] "GET / HTTP/1.1" 200
98.81.206.167 [13/May/2026:15:49:54 +0900] "GET / HTTP/1.1" 200
98.81.206.167 [13/May/2026:15:49:55 +0900] "GET /robots.txt HTTP/1.1" 200
98.81.206.167 [13/May/2026:15:49:55 +0900] "GET /sitemap.xml HTTP/1.1" 200
98.81.206.167 [13/May/2026:15:49:55 +0900] "GET /sitemap_index.xml HTTP/1.1" 200
98.81.206.167 [13/May/2026:15:49:56 +0900] "GET /llms.txt HTTP/1.1" 200
前回と比べて、3つの変化が見えます。
1つ目は、トップページへのアクセスが2回になっています。前回は「301リダイレクト→200」という流れでしたが、今回は最初から200が2回連続で記録されています。リダイレクト先を学習済みで、直接正規URLへアクセスするようになった可能性があります。
2つ目は、sitemap.xmlのステータスが404から200に変わっています。前回の観測時点ではsitemap.xmlが存在せず404が返っていました。その後サイト側で整備が進み、5月13日時点では200が返るようになっていました。AI-Observatory/1.0はその変化を正確に記録しています。
3つ目は、来訪頻度が上がっています。5月13日だけで2回、5月14日にも2回と、2日間で合計4セッションが記録されました。前回の約14日間で5セッションだったことと比べると、明らかに密度が上がっています。
| 日時 | IP | 取得ファイル |
|---|---|---|
| 5/13 15:49 | 98.81.206.167 | / × 2・robots.txt・sitemap.xml・sitemap_index.xml・llms.txt |
| 5/13 16:11 | 44.203.230.168 | / × 2・robots.txt・sitemap.xml・llms.txt・sitemap_index.xml |
| 5/14 10:17 | 54.92.134.29 | / × 2・robots.txt・llms.txt・sitemap.xml・sitemap_index.xml |
| 5/14 11:11 | 44.222.175.24 | / × 2・robots.txt・sitemap.xml・llms.txt・sitemap_index.xml |
4セッションすべてで異なるIPを使っています。ただし、ARINのRDAPで確認したところ、全IPが「AMAZON-IAD」、つまりAWSのバージニア北部リージョンに属していました。前回観測時と同じクラウド基盤です。
旧パターンと新パターンの比較
前回(4月)と今回(5月)の巡回パターンを並べると、変化がはっきり見えます。
| 項目 | 前回(4月・#18) | 今回(5月・#19) |
|---|---|---|
| 観測期間 | 約14日間 | 2日間 |
| セッション数 | 5回 | 4回 |
| 1日あたりの来訪 | 約0.36回 | 2回 |
| トップページ取得 | 301→200(2リクエスト) | 200→200(2リクエスト) |
| sitemap.xmlステータス | 404 | 200 |
| llms.txt取得 | あり | あり |
| 記事ページへのアクセス | ゼロ | ゼロ |
| IPホスティング | AWS バージニア北部 | AWS バージニア北部 |

変わらなかった点が2つあります。記事ページへのアクセスはゼロのままで、IPホスティングもAWSバージニア北部のままです。サイト構造の「外側」だけを確認して帰るという基本的な行動は変わっていません。
変わった点も2つあります。1つ目はsitemap.xmlが404から200になったこと。2つ目は来訪頻度が約6倍に上がったことです。
来訪頻度の変化については、いくつかの解釈ができます。llms.txt設置によってサイトのAI対応度が上がったと判定され、監視頻度が上がった可能性があります。またはsitemap.xmlが200になったことで、前回とは異なる状態変化として記録され、再スキャンが走った可能性もあります。どちらが正しいかは現時点では判断できません。
一つ確認できることは、AI-Observatory/1.0が「前回404だったsitemap.xmlが今回200になった」という変化を正確に検知しているという事実です。状態変化を追跡する設計になっている可能性が高いと考えられます。
AWSバージニア北部から逆算する
今回の4セッションすべてのIPをRDAPで確認したところ、全件が「AMAZON-IAD」に属していました。AWSのバージニア北部リージョン(us-east-1)です。前回4月の観測時も同じリージョンでした。
AWSバージニア北部は、OpenAIやAnthropicをはじめ多くのAI系サービスがインフラとして使っているリージョンです。ただし、同じリージョンを使っているからといって、特定のサービスと結びつけることはできません。世界中の無数のサービスが同じリージョンで動いています。
ここで確認できることと、できないことを整理します。
| 項目 | 判断 |
|---|---|
| クラウド基盤はAWS | ✅ 確定 |
| リージョンはバージニア北部(us-east-1) | ✅ 確定 |
| Azureでもなく、GCPでもない | ✅ 確定 |
| OpenAI系のサービスである | ❌ 断定不可 |
| Anthropic系のサービスである | ❌ 断定不可 |
| 特定企業のエージェントである | ❌ 断定不可 |
IPのリージョンだけで運営元を特定することはできません。ただ、毎回異なるIPを使いながら同じ巡回パターンを繰り返している点は、個人が手動で動かしているツールではなく、クラウド上で自動実行されているエージェントであることを示しています。

用途として考えられるのは、研究・実験目的の観測ボット、GEO系ツールのバックエンド、AIサービスの事前スキャン機能、のいずれかです。いずれにせよ、AWSバージニア北部で動く自動エージェントが、定期的にサイトの構造情報だけを収集しているという事実は変わりません。
正体の仮説:何が変わったのか
AI-Observatory/1.0の運営元は現時点でも特定できていません。ただし、4月と5月の2回の観測データが揃ったことで、仮説の精度が上がってきました。
行動パターンから考えられる仮説は3つあります。
仮説① サイトのAI対応状況を定期監視するボット
robots.txt・sitemap・llms.txtという取得対象の組み合わせは、「サイトがAIクローラーに対してどう設定されているか」を確認するための最小セットです。記事本文を読まず、設定ファイルだけを収集して帰る行動は、コンテンツ取得ではなく状態確認を目的にしていると考えると自然に説明できます。
llms.txt設置後に来訪頻度が上がった点も、「新しい設定ファイルが追加された」という状態変化を検知して監視頻度を上げた結果と解釈できます。
仮説② GEO系ツールのバックエンドスキャナー
GEO(Generative Engine Optimization)ツールの中には、登録されたサイトのAI可視性を定期的にスコアリングするものがあります。そのバックエンドが、サイト構造の確認だけを自動実行している可能性があります。AWSバージニア北部はこうしたSaaSツールのインフラとしてよく使われるリージョンです。
仮説③ 研究・実験目的の観測エージェント
大学・研究機関・個人研究者がAI対応サイトの分布を調査する目的で動かしている観測ボットという可能性もあります。「AI-Observatory」という名前自体が、観測・調査を意図した命名のように見えます。
3つの仮説に共通するのは、「コンテンツを読むためではなく、サイトの状態を記録するために動いている」という点です。GPTBotやClaudeBotが記事本文を収集するのとは、目的のレイヤーが異なります。
| 仮説 | 根拠 | 確度 |
|---|---|---|
| AI対応状況の定期監視ボット | 設定ファイルのみ取得・状態変化を検知 | 高 |
| GEO系ツールのバックエンド | AWS us-east-1・自動実行・定期来訪 | 中 |
| 研究・実験目的の観測エージェント | 名前の命名規則・規則的な巡回 | 中 |
正体が判明した場合は、観測結果を追記して更新します。
robots.txtで制御できるか
AI-Observatory/1.0をrobots.txtでブロックしたい場合、以下の記述で対応できます。
User-agent: AI-Observatory
Disallow: /
実際にrobots.txtの指示に従うかどうかは確認できていません。今回の観測では、AI-Observatory/1.0はrobots.txtを取得していますが、内容を読んで巡回範囲を制限している証拠はログから読み取れませんでした。
robots.txtへの準拠は、あくまで運営元の判断に依存します。GPTBotやClaudeBotのように公式ドキュメントで準拠を明言しているクローラーとは異なり、AI-Observatory/1.0には公式な説明がないため、ブロック設定が有効かどうかは不明です。
現時点でとれる対応を整理します。
| 対応 | 効果 |
|---|---|
| robots.txtにDisallow記述 | 準拠する場合はブロック可能・準拠しない場合は無効 |
| サーバー側でIPブロック | AWSのIPレンジは広く、全ブロックは現実的でない |
| ログ監視を継続する | 行動変化・正体特定のための実測データが蓄積できる |
AI観測ラボでは現時点でブロックせず、観測を継続しています。記事本文への到達がなく、サーバー負荷も軽微なため、実測データを蓄積することを優先しています。正体が判明した段階で対応方針を改めて判断します。
robots.txtのAIクローラー向け設定についてはrobots.txt完全ガイドで詳しく解説しています。
まとめ—変化を記録することで見えてきたこと
AI-Observatory/1.0の2回目の観測で確認できた内容を整理します。
| 項目 | 内容 |
|---|---|
| llms.txt設置日 | 2026年5月7日 14:21 |
| 設置後の無反応期間 | 6日間 |
| 行動変化の確認日 | 2026年5月13日 15:49 |
| 5月の来訪セッション数 | 4回(2日間) |
| IPホスティング | 全件AWS バージニア北部(us-east-1) |
| 新たに確認された変化 | sitemap.xml 404→200・/への二重アクセス・来訪頻度増加 |
| 記事ページへのアクセス | ゼロ(変化なし) |
| 正体 | 現時点で不明 |
llms.txt設置と行動変化の間に因果関係があるかどうかは、まだ断定できません。ただし、設置から6日後に変化が起きたという事実はログで確認できています。
今回の観測で改めて見えてきたのは、AIクローラーとAIエージェントの間に「サイト構造だけを収集するレイヤー」が存在する可能性です。GPTBotやClaudeBotが記事本文を読むのとは目的が異なる、状態監視型のエージェントが動いています。
AI-Observatory/1.0の正体については引き続き観測を続けます。新しいデータが得られた場合はこの記事を更新し、XおよびBlueskyでも共有します。
llms.txtの設置方法はllms.txtの書き方【テンプレコピペOK】、AIクローラーの種類と役割の違いはAIボットは2種類じゃなかった—サーバーログで見えた3つの役割で詳しく解説しています。
あなたのサイトは、
AIに見えていますか?
URLを入力するだけで30秒。8項目を自動診断し、優先度別の改善プランを提示します。完全無料・登録不要。