エージェントは賢い。問題はウェブが汚れていることだ。
午前2時、あなたのAIエージェントが競合他社の価格を確認するためにサイトへアクセスする。ところが、そのサイトはCAPTCHAを表示し、HTML構造を変え、ボットを遮断する。エージェントは慌てない。その代わり、もっともらしく作り上げる。ユーザーはその幻覚を事実だと信じる。
エージェントをランタイムでウェブに送り出した瞬間、あなたは不確実性をユーザーの目の前まで届けたことになる。
問題の核心は「どれだけ多く取得するか」ではない。エージェントが消費するデータインターフェースをどのように契約(contract)するかだ。この記事は性能ではなく、インターフェース契約の話だ。
TL;DR
- AIエージェント・MCPサーバーにウェブデータを接続する真の勝負どころは、収集規模ではなくエージェントが消費するデータ契約(machine-facing interface)の設計だ。
- エージェントが呼び出しのたびに直接ブラウジングすると、遮断・遅延・幻覚のリスクが応答にそのまま乗る。あらかじめ整備されたフィードをMCPリソースとして参照すれば、応答は一貫し、引用も容易になる。
- 不確実性をエージェントランタイムに載せず、バックエンド契約へ移せ。ハッシュスクレイパーは管理型バックエンドとして収集・遮断対応を吸収し、エージェントには契約済みのフィードだけを渡す。
目次
- MCPとは何か — エージェントの標準コンセント
- 2つの道：直接ブラウジング vs 契約済みフィード
- 比較表：性能ではなく責任の所在
- スキーマを契約書のように書け — toolとresource
- 幻覚を防ぐグラウンディングの4原則
- マシンのための契約要素5つ
- 接続設計の5段階
- 自己診断5問
- FAQ
- 結論
- 今すぐ始める
MCPとは何か — エージェントの標準コンセント
定義1. MCP(Model Context Protocol)は、AIエージェントが外部ツール(tool、動作)とデータ(resource、参照)を標準化された方法で接続するよう定義したプロトコルだ。
コンセントを思い浮かべればわかりやすい。国ごとにプラグの形が異なれば、毎回アダプターを作らなければならない。MCPはその規格を一つに統一した標準コンセントだ。エージェントはこのコンセントに差し込むだけで、どのバックエンドとも同じ方法でやり取りできる。
MCPは2種類のケーブルを公開する。toolは「何かを実行しろ」という動作であり、resourceは「何かを参照しろ」というデータだ。ウェブデータ接続で私たちが注目するのは後者、resourceだ。ここで設計の方向が分かれる。
2つの道：直接ブラウジング vs 契約済みフィード
エージェントにウェブをつなぐ方法は、大きく2つある。
道A — エージェントが呼び出しのたびに直接ブラウジングする。 ユーザーが尋ねると、その瞬間にエージェントがサイトへアクセスする。柔軟に見えるが、サイトの遮断・CAPTCHA・構造変更・遅延がすべて応答品質へ流れ込む。同じ質問でも、昨日と今日で答えが異なる。サイトが遮断されてもエージェントは止まらず、もっともらしく作り上げる。幻覚の温床だ。
道B — あらかじめ収集・整備されたフィードをMCPリソースとして参照する。 収集はバックエンドが事前に完了させ、エージェントは構造化された結果だけを契約に従って受け取る。応答は一貫し、出典が付いているため引用も容易だ。
直接ブラウジングはエージェントが毎回荒野へ出ていくことであり、契約済みフィードは整備された窓口で書類を受け取ることだ。
ここで誤解してはいけない。これは「どちらが速いか」の問題ではない。不確実性がどこに積み上がるかの問題だ。道Aは不確実性をエージェントランタイム、すなわちユーザーの目の前に積み上げる。道Bは不確実性をバックエンド契約の裏側へ押しやる。
比較表：性能ではなく責任の所在
定義2. データ契約(data contract)とは、エージェントが受け取るデータのフィールド・型・意味・メタデータをあらかじめ固定し、双方がその規格を信頼できるようにするmachine-facingな約束だ。
| 軸 | 直接ブラウジング（道A） | MCPリソースフィード（道B） |
|---|---|---|
| 遮断リスク | エージェントランタイムにそのまま露出 | バックエンド契約の裏側へ隔離 |
| 遅延 | 呼び出し時点で発生、予測不能 | 参照は整備済みフィード基準で安定 |
| コスト | 呼び出しのたびに再収集 | 収集1回、多数の参照に分散 |
| 応答の一貫性 | 呼び出しごとに揺れる | 同じ入力 → 同じ結果 |
| 幻覚リスク | 失敗時に作り上げる | 空の結果・出典明示により抑制 |
| 保守性 | エージェントロジックに収集が結合 | 契約層で分離管理 |
表を貫く結論は一つだ。違いは性能軸ではなく、責任の所在にある。遮断・遅延・幻覚の責任をエージェントに負わせるのか、契約に負わせるのか。
エージェントは薄く、契約は厚く。
スキーマを契約書のように書け — toolとresource
契約が信頼を得るには、文言が正確でなければならない。MCP tool・resourceスキーマも同じだ。
フィールドの型と意味を固定する。 priceが文字列なのか整数なのか、通貨は何か、「売り切れ」をどの値で表現するかをスキーマで明記する。エージェントが値の意味を推測した瞬間、契約は壊れる。
引用を可能にするメタデータを必須で付ける。 次の3つは必ず入れる。
- 出典URL — エージェントが「どこから来たか」を回答で引用できるようにする。
- 収集時刻 — 鮮度を判断して表記できるようにする。
- 識別子(id) — 同じ対象を再参照・重複排除できるようにする。
出典・時刻・識別子のないデータは、エージェントにとって根拠のない噂と同じだ。
このメタデータ3行が引用可能性(citability)を生む。エージェントが「価格は12,000ウォンです」ではなく、「価格は12,000ウォンです（出典：X、収集：本日午前9時）」と答えられるようにすることが契約の目的だ。
幻覚を防ぐグラウンディングの4原則
エージェントの幻覚は、たいてい「手ぶらで戻ったときに、手ぶらだと言えないため」に生じる。契約がこの余地をなくす。
- 構造化JSONで応答する。 自由テキストではなく、スキーマに合ったJSON。エージェントがパースする際に想像する余地をなくす。
- 出典フィールドを強制する。 出典のないレコードは契約違反。引用できないデータは回答に載らないようにする。
- 空の結果を明示する。 「結果なし」を明確な値として返す。沈黙は幻覚を呼ぶ。
- 鮮度を表記する。 収集時刻をともに渡し、エージェントが「いつ時点か」を自ら明らかにできるようにする。
幻覚はデータが間違っているからではなく、空欄を埋めるよう放置することで生じる。
マシンのための契約要素5つ
人間向けAPIとは異なり、エージェントが繰り返し呼び出すmachine-facing契約には5つの要素が必要だ。
- 冪等性(idempotency) — 同じリクエストを複数回送っても、結果・副作用が同一でなければならない。再試行が多いエージェント環境の基本だ。
- rate limit — 呼び出しの急増を契約レベルで制御し、バックエンドとエージェントの双方を保護する。
- トークン・権限スコープ — どのエージェントがどのリソースにアクセスできるかをスコープで限定する。
- スキーマバージョニング — フィールドが変わる際はバージョンで知らせる。契約を黙って変えない。
- エラー規約 — 失敗を定められたコード・形式で返す。エージェントが失敗を「成功した空データ」と誤認しないようにする。
契約はうまくいくときではなく、うまくいかないときに真価を発揮する。
接続設計の5段階
- 用途の定義 — エージェントがこのデータで何をするかから決める。価格比較か、評判要約か。用途がスキーマを決める。
- アーキテクチャの決定 — 直接ブラウジング（道A）か、契約済みフィード（道B）か。ほとんどのプロダクションエージェントは道Bだ。
- スキーマの確定 — フィールドの型・意味を固定し、出典・収集時刻・識別子メタデータを必須化する。
- 契約要素の付加 — 冪等性・rate limit・権限スコープ・バージョニング・エラー規約を付ける。
- グラウンディングの検証 — 空の結果・出典フィールド・鮮度が実際に強制されているか、エージェントが作り上げないかをテストする。
良い接続はコードではなく、契約から始まる。
一つ明確にしておく。この5段階はすべてインターフェース契約層の話だ。「どれだけ大量に、どれだけ速く取得するか」という収集性能は別の層であり、それは[リアルタイム大量収集パイプライン(023)]の記事で扱う。ここでは、エージェントが消費する契約だけを設計する。
自己診断5問
あなたのエージェント・ウェブデータ接続が契約らしいものかを点検しよう。
- [ ] エージェントに渡すデータには出典URL・収集時刻・識別子が常に付いているか？
- [ ] 結果がないとき、「結果なし」を明示的な値として返しているか？（エージェントが作り上げていないか）
- [ ] 応答は自由テキストではなく、スキーマ固定JSONか？
- [ ] 同じリクエストを繰り返しても結果が同じ冪等契約か？ rate limit・権限スコープはあるか？
- [ ] フィールドが変わる際、スキーマバージョン・エラー規約でエージェントに知らせているか？
該当するものが3つ以下なら、あなたはデータを接続したのではなく、不確実性をエージェントランタイムに載せてユーザーへ届けている。
FAQ
Q. AIエージェントやMCPサーバーにリアルタイムのウェブデータを接続するにはどうすればよいですか？
A. エージェントが呼び出しのたびにサイトを直接ブラウジングするのではなく、あらかじめ収集・整備されたデータをMCPリソースとして参照するよう設計してください。核心はデータ契約です。フィールドの型・意味を固定し、出典URL・収集時刻・識別子をメタデータとして必須化したうえで、冪等性・rate limit・権限スコープ・スキーマバージョニング・エラー規約を付けます。収集と遮断対応は管理型バックエンドが吸収し、エージェントには契約済みフィードだけを消費させるのが安定的です。
Q. toolとresourceは何が違いますか？
A. toolは「実行しろ」という動作であり、resourceは「参照しろ」というデータです。ウェブデータ接続で整備済みフィードを渡す際は、主にresourceとして公開します。状態を変える動作（例：収集トリガー）はtoolとして分離するほうが、契約がすっきりします。
Q. エージェントが存在しないデータを何度も作り上げます。何を直すべきですか？
A. グラウンディング契約を強制してください。構造化JSONで応答し、出典フィールドを必須にし、空の結果を明示的な値として返し、収集時刻で鮮度を表記します。幻覚はたいていデータが間違っているからではなく、「空欄を埋めるよう放置すること」で生じます。
Q. サイトが何度も遮断する問題は、エージェントでどう処理すればよいですか？
A. エージェントで処理しないでください。遮断対応は契約の裏側にある管理型バックエンドへ移すのが定石です。ハッシュスクレイパーは管理型バックエンドとして収集・遮断対応を吸収し、エージェントにはすでに整備されたフィードだけを契約に従って渡します。エージェントランタイムに不確実性を載せない構造です。
結論
エージェントはウェブ全体を受け止めるよう設計された存在ではない。ウェブの汚さを受け止めるのはバックエンドの役割であり、エージェントの役割は契約済みの窓口で整備された書類を受け取り、正確に引用することだ。
だから設計の重心は「どれだけ取得するか」ではなく、「どのように契約するか」にある。フィールドを固定し、出典・時刻・識別子を付け、空の結果を明示し、冪等性・バージョニング・エラー規約を備えた契約。この契約書1枚が、エージェントの幻覚と応答の揺らぎをバックエンドの裏側へ押しやる。
不確実性をエージェントランタイムに載せるな。バックエンド契約へ移せ。エージェントは薄く、契約は厚く。
収集・遮断対応は管理型バックエンドが吸収する。ハッシュスクレイパーは収集・遮断対応・整備を吸収する管理型収集を提供し、エージェントは契約済みフィードだけを消費すればよい。
より広い文脈は国内データ収集サービス比較（2026年の実際の地図）とモニタリングは収集ではなく通知だ — 価格・評判データで対応ループを作るへと続く。
今すぐ始める
AIエージェント・MCPサーバーに安定したウェブデータ契約を付けたいなら、収集・遮断・整備を吸収する管理型バックエンドから始めるのが早い。エージェントには契約済みフィードだけを消費させ、荒野のウェブはバックエンドに任せよう。
ハッシュスクレイパーは国内5,000以上のサイト収集経験と195か国のプロキシ、99.7%の精度で荒野のウェブをバックエンドで吸収し、エージェントには整備されたフィードだけを契約に従って渡す。500社以上の企業と協業し、法的問題0件を守り続けてきた。新規登録時には5万クレジットを提供する。
