AIEndpoint — AIエージェントがあらゆるWebサービスを即座に理解できる /ai エンドポイントのオープン標準
(github.com/aiendpoint)こんにちは。
AIと一緒に開発を進めたり、ほかのサイトのレビューなどをしていると、すぐにトークンが尽きてリセット待ちになることがよくありました。
考えてみると、AIは「人が人間の目で読める画面を見ているのではないか」と思ったんです。
そこで、トークンを減らし、AIの応答速度を速くできる標準的な代替案が必要なのではないかと考えました。
AIエージェントがWebサービスを読むために、今はおおよそ次の3つの方法が使われています。
- HTMLスクレイピング — 返ってくる内容の80%以上が広告・ナビ・スクリプトのノイズ（数万トークン規模）
- APIドキュメントを読んでハードコーディング — サービスが変わるたびに毎回壊れる
- MCPの利用 — 対応しているサービスがごく少なく、開発者向け
そこで、次のような流れのコンベンションを提案したくて、オープンソースとして作りました。
- robots.txt (1994) → クローラーに「ここには来るな」
- sitemap.xml (2005) → クローラーに「ここにある」
- /ai (2026) → AIエージェントに「私たちが何をできるか」 ← これがなかったもの
（作業しながら調べてみると、robots.txt も最初に提案したのはオランダのソフトウェアエンジニア、マルティン・コスター（Martijn Koster）だったそうです。当時、初期のWebクローラーがサーバーに過大な負荷をかける問題を解決するために考案されたとのことです。）
Webサービスを所有している側が GET /ai を実装して、
- AIエージェントが即座に構造化情報を読み取り
- APIを直接呼び出せるように変えていきたいと思いました。
- スクレイピングなし。ドキュメント解析なし。トークンの無駄遣いなし。
こちらで確認できます。
curl https://api.aiendpoint.dev/ai | jq .
これまでに次の作業をしました（with claude, codex）
- オープンスペック（Apache 2.0） — https://github.com/aiendpoint/platform
- レジストリ — aiendpoint.dev（登録・検索）
- バリデーター — aiendpoint.dev/validate（0〜100点のスコアリング）
- MCPサーバー — Claude/Cursorからレジストリを直接検索
- Claude Codeスキル — 既存サービスに /ai を自動追加（10分）
MCPサーバーがなければ、レジストリは単なるWebサイトです。
MCPサーバーがあれば、Claudeに「認証なしで使える天気APIを探して」と言うと、
すぐに構造化された答えを返してくれます。 このループを閉じることが核心でした。
スペックへのフィードバックを歓迎します。
みなさんのサービスに /ai を実装してもらうには、何が必要でしょうか。
一緒に参加して規格を作っていけたらと思います。
オランダで robots.txt が最初に提案されたように、私たちも流れを作れるのではないでしょうか。
7件のコメント
llm.txtはすでに提案されており、その有効性を研究した論文もあります。NAVERによると、少なくとも今のところはエージェントたちもあまり見えていないようです。NAVERによると…って、寝ながら書いたのか……。「その論文によると」です。
はは、その通りです。
llms.txt がエージェントがサービスを「理解」することにおいて説明に重点を置くなら、
/aiは AI がサービスを「利用」することにフォーカスしたものです。つまり、「うちのサービスの API はこう呼び出してね」と伝えるためのものです。ここに MCP を使えば、そのサイトの利用方法をまず「ざっと見て」から（トークンを節約して）始められるでしょう。どうしても直接参加が難しいため、「直接登録」版と「コミュニティ」版を分けて、まず
/aiMCP 利用時に「すでに誰かが search してみた」ことのあるサイトなら、より軽く速くアクセスできる構造にはなっています！ありがとうございます〜
/aiが規格化されるなら、逆に/aiだけをクロールして、広告のない見やすいページを表示するツールが出てくる可能性もあるのではないでしょうか？面白いですね！ では、
/aiに広告を混ぜ込むようなことも起こりそうですねでは、広告内容が見つかった場合にスコアを下げるロジックを追加する必要がありそうですね！
はい。十分に可能性はあります。また、agent の利用量（トラフィック）、処理、トークンコストなどの理由から、Web 自体が一方では昔の telnet 時代のように light になっていく可能性もあると思います。（装飾より内容に集中）今の GeekNews のようにですね。（推測です！）