WebMCPブラウザAPIは、AIエージェントのウェブスクレイピングの必要性を軽減する可能性があります。

WebMCPがWeb自動化にもたらす変化
Googleは最近、WebMCPという2つの新しいブラウザAPIをリリースしました。これにより、ウェブサイトはAIエージェントが直接呼び出せるツールを登録できるようになります。DOM要素をスクレイピングしたり、ボット対策システムと戦ったりする代わりに、サイトは標準化されたインターフェースを通じて機能を公開できます。
技術的な仕組み
サイトはnavigator.modelContext.registerTool()を使用して、名前、説明、入力スキーマ、実行関数とともにツールを登録します。ソースでは以下の例を提供しています:
navigator.modelContext.registerTool({
name: "search_flights",
description: "利用可能なフライトを検索",
inputSchema: { /* JSONスキーマ */ },
execute: async (input) => {
return await internalFlightAPI(input);
}
});このアプローチにより、WebMCPを実装するサイトでは、CSSセレクタチェーン、リトライロジック、ヘッドレスブラウザセッション管理、DOMスクレイピングが不要になります。
現在の実装状況
仕様はまだ初期段階にあります - W3Cドラフトにはメソッド定義に文字通り「TODO: これを埋める」というコメントが含まれています。現在はChrome 146でのみ早期プレビューとして利用可能です。著者は、既存のスクレイピングコードのどれだけを置き換えられるかをテストするために早期プレビューに登録しました。
開発者への実用的な影響
すでにMCPサーバーを構築している開発者にとって、メンタルモデルは同じです:ツール+スキーマ+実行。ローカルリソースをMCPツールとして公開することから、ウェブサイトがMCPツールとして自身を公開することへの移行は小さなステップです - 同じアーキテクチャで、異なるトランスポートです。
既存の内部APIを持つ大規模サイト(Booking、Amazon、航空会社など)は、最小限の変更でAPIをWebMCPを通じて公開できるため、最初に採用する可能性が高いです。スクレイパーが完全になくなるわけではありません - WebMCP実装のないサイトでは、従来のアプローチが引き続き必要です。
著者は段階的なアプローチを提案しています:エージェントはまずWebMCPを試し、利用できない場合はDOM自動化にフォールバックし、最後の手段として生のスクレイピングにフォールバックする - サイトごとに利用可能な最良の方法を使用します。
📖 完全なソースを読む: r/ClaudeAI
👀 See Also

ローカルLLMをClaudeコードサブエージェントとして使用してコンテキスト使用量を削減する
Redditユーザーが、Claude CodeがLM Studioを介して実行されるローカルLLMにタスクを委譲し、ファイルの内容をClaudeのコンテキストから除外する方法を実演しています。このセットアップでは、LM Studioのツール呼び出しAPIを使用してファイル操作をローカルで処理する約120行のPythonスクリプトが用いられています。

Hippo v0.21.0:マルチツール対応AIエージェントのための生物学的に着想を得たメモリ
Hippo v0.21.0では、Claude Code、OpenCode、OpenClaw、Codex、Cursor、Piを含む複数のAIコーディングツールのワンコマンドセットアップを導入しています。メモリシステムは、減衰、検索強化、統合の機能を備え、ランタイム依存関係がゼロです。

エージェントリコール:永続的なClaudeコードメモリのためのローカルSQLite MCP
agent-recallは、ローカルのSQLiteファイルを使用してClaude Codeにセッション間での永続的なメモリを提供するMCPサーバーです。9つのMCPツールを提供し、エンティティ、関係性、観察結果を保存でき、セッション開始時には生データのダンプではなくLLMで要約されたブリーフィングが行われます。

マルチエージェント開発のためのコーディネーターサーバーによる上書き防止
開発者がNode.jsコーディネーターサーバーを構築し、同じコードベースで作業するAIエージェント間の行範囲ロック、行シフト追跡、リアルタイムメッセージングを管理しています。HTTPベースのロックと競合検出を使用することで、エージェントが互いの作業を上書きするのを防ぎます。