Agent フレンドリーなブログへ

（記事は中国語） 中文 →

ブログを agent フレンドリーに改造した：llms.txt、Markdown エンドポイント、構造化コンテンツ API を追加。改造の動機、具体的実装、そして agent 時代への自分の考えを記録する。

最近このブログに改造を施した。目標は AI agent フレンドリーにすることだ。改造自体は大きくなく、半日で完了したが、その背景にある思考は記録に値する。

なぜ改造するのか

この一年、AI agent の研究と構築に多くの時間を費やしてきた。最も基礎的なモデル呼び出しから、ツールチェーンの設計、マルチステップ推論システムまで、多くの坑を踏み、不少判断を蓄積してきた。この過程で、ますます明確になってきた認識がある：agent がインターネットの新しいユーザーになりつつあるということだ。

従来の Web は人間のために設計されていた。人間がブラウザを開き、上から下に読み、リンクをクリックして移動し、目でページをスキャンしてほしい情報を見つける。HTML、CSS、JavaScript、ビジュアルレイアウト、技術スタック全体が「人間がスクリーンを見る」という仮説を中心に構成されている。

しかし agent はこのように情報を消費しない。レイアウトを見ず、リンクをクリックせず、「ブラウジング」しない。構造を解析し、セマンティクスを抽出し、プログラム的な操作を実行する。agent があなたのサイトにアクセスするとき、必要なのは：ここにどんなコンテンツがあるか、各記事は何を語っているか、ユーザーの問題に最も関連する部分をどう見つけるか。agent に必要なのはインデックスとセマンティクスであり、ビジュアルデザインではない。

現在の大多数のサイトは agent にとってほぼブラックボックスだ。このブログも以前はそうだった。HTMLページにはCSSスタイル、JavaScriptスクリプト、ナビバー、パンくずリスト、フッターが混在しており、agent がノイズから本文を抽出するのは、コーヒーの中から砂糖の粒を取り出すようなものだ。できなくはないが、非効率だ。

より深い問題は、Web の情報発見メカニズムが検索エンジン向けに設計されていることだ。sitemap.xml はクローラーに「ここにこれらのURLがある」と伝え、robots.txt は「どれがアクセス可能か」を伝える。しかし agent に必要なのはURLリストではなく、コンテンツのセマンティックマップだ。ここにどんなテーマがあるか、各記事の核心的な視点は何か、どのコンテンツに関連性があるか。

今回の改造はこの問題を解決するためだ。

何をしたか

改造は三層に分かれる。シンプルなものから深いものへ。

llms.txt：agent に地図を渡す

llms.txt は fast.ai 創設者 Jeremy Howard が2024年に提唱した標準で、現在 Anthropic、Cloudflare 等の企業が採用している。その考え方はシンプルだ：サイトのルートパスに純粋な Markdown ファイルを置き、人間と LLM の両方が理解できるフォーマットで、サイトの構造と重要なコンテンツを描述する。

このファイルの役割は robots.txt に似ているが、向き先は agent だ。robots.txt は「どれがアクセス可能か」を言い、llms.txt は「ここに何があるか」を言う。

自分の llms.txt に何を入れたか：サイトの説明、すべての記事へのリンクと一言の説明、構造化データ API のエントリ、RSS と Sitemap のリンク。agent が fanshikun.com/llms.txt にアクセスすれば、サイト全体の認知を素早く構築し、どのページを深く見るかを判断できる。

このファイルはビルド時に自動生成される。コンテンツは各記事の frontmatter から取得する。新しい記事が公開されるたびに、llms.txt は自動的に更新される。

Markdown エンドポイント：ノイズを除く

第二層は、各記事の Markdown バージョンを生成することだ。/model-first-then-agent/index.md にアクセスすると、クリーンな Markdown ファイルが得られる。HTMLタグもCSSもナビバーもない。

実装方法は、ビルド時に各記事の index.md ファイルを生成し、対応する dist ディレクトリに配置することだ。ファイルの先頭にはタイトル、日付、要約、キーワードなどのメタデータが含まれ、本文はビルド処理済みのデータから生成される。テンプレート変数は置換済み、関連記事はリンクとして解決済みだ。生成されるのは静的ファイルで、追加のサーバールーティングは不要。

agent が受け取るのはクリーンで構造化されたコンテンツだ。タイトルはタイトル、段落は段落、引用は引用、リンクはリンクだ。フィルタリングすべきノイズは何もない。

構造化コンテンツ API：プログラム的なエントリ

第三層は、ビルド時にJSONインデックスファイル /api/posts.json を生成することだ。これにはサイトのメタデータとすべての記事の構造化情報が含まれる：タイトル、公開日、要約、タグ、URL、関連記事。

agent は一度のリクエストでサイト全体のコンテンツインデックスを取得でき、ユーザーの質問に基づいてどの記事の全文を取得すべきかを判断できる。HTMLのホームページから記事リストを解析するよりはるかに効率的で正確だ。JSONはプログラム的な消費に最適なフォーマットで、曖昧さがない。

改造の背後にある思考

これらの技術的変更を施した後、改めて考えた：これは一体何を解決しているのか？

答えは：Web の消費パターンが「人間が読む」から「agent がプログラム的にアクセスする」へ拡張しているということだ。これは取代ではなく、新しい層の追加だ。人間は引き続きブラウザでページを見るが、agent には独自の消費インターフェースが必要だ。

このトレンドは加速している。マイクロソフトは2025年に NLWeb プロジェクトを発表した。コアコンセプトは「すべてのサイトが対話可能であるべき」だ。agent は自然言語でサイトに質問でき、サイトは構造化された回答を返す。NLWeb の各インスタンスは同時に MCP サーバーでもある。正式名称は Model Context Protocol だ。agent は標準プロトコルを通じてサイトの能力を直接呼び出せる。HTMLをクロールする必要はない。

MCP は agent 相互接続のデファクトスタンダードになりつつある。Anthropic が2024年に提唱し、OpenAI、Google、Microsoft が相次いで採用した。agent と外部ツール間の通信プロトコルを定義する。agent があなたのサイトの見た目を知る必要はなく、あなたが公開しているツール、各ツールが受け付けるパラメータ、返す結果を知るだけでいい。

これらの標準はまだ初期段階だ。llms.txt は主要LLMベンダーのクローラーに正式に採用されておらず、MCP のエコシステムも構築中だ。しかし方向性は明確だ：Web は「ドキュメントネットワーク」から「agent がプログラム可能なネットワーク」へと進化しつつある。今準備を始める方が、標準が成熟してから追いかけるより良い。

Agent への理解

agent への理解について少し触れておきたい。これは技術選択だけではなく、この分野を見る自分の方式だ。

agent はチャットボットのアップグレード版ではない。チャットボットは質問に答え、agent はタスクを完了する。この違いは小さく見えるが、実際には根本的だ。質問に答えるには理解能力だけでいいが、タスクを完了するには理解、計画、実行、フィードバック、修正の完全なループが必要だ。

agent の構築で最も難しい部分はモデル呼び出しでも、ツールチェーンの設計でも、記憶システムの設計でもない。それらには既製のフレームワークがある。最も難しいのは具体的なシナリオで判断することだ。どのステップをagent に自律的に判断させ、どこに人間のチェックポイントを設けるか。モデル能力の境界はどこにあるか、いつよりシンプルな方案に切り戻すべきか。ツールの粒度はどう決めるか。粗すぎるとagent がうまく使えず、細かすぎるとエラー確率が上がる。

これらの判断に一般的な答えはなく、一つひとつの具体的なプロジェクトの中で蓄積するしかない。このブログで記録しているモデルファースト原則、漸進的アーキテクチャ、可観測性は、すべて実際の構築から抽出した経験だ。

最近の実感は：agent の価値は派手なデモができることではなく、反復的で確定的な作業をどこまで自動化できるかにある。毎日三つのデータソースをチェックし、要約を生成し、通知を送信するagent を安定的に動作させる方が、たまに素晴らしいコードを書くが頻繁にエラーを起こすagent よりずっと有用だ。信頼性が agent の第一優先事項だ。

次のステップ

今回の改造は第一歩だ。llms.txt、Markdownエンドポイント、構造化APIの三つにより、ブログは現在の標準でagent が消費可能になった。

次のステップとして、ブログを MCP サーバーにし、agent が標準プロトコルで検索やクエリ能力を直接呼び出せるようにすることが考えられる。ただし MCP エコシステムの実際の発展速度次第であり、急ぐ必要はない。

自分で agent を構築したい、あるいは既存のシステムをより agent フレンドリーにしたい場合は、連絡してほしい。それが自分の最もやりたいことだ。

参考文献

更新履歴

  • 公開