Skip to main content
Google ChromeWebMCPИИ автоматизация

WebMCP у Chrome знижує вартість браузерної ШІ-автоматизації

Google почав розгортати експериментальний WebMCP у Chrome версії 146+. Тепер браузерні веб-додатки можуть передавати ШІ-агентам структуровані інструменти напряму, повністю уникаючи крихкого скрейпінгу DOM та імітації кліків. Для бізнесу це критично важливо: будь-яка автоматизація через браузер стає значно надійнішою, працює швидше і обходиться дешевше у довгостроковій підтримці.

Технічний контекст

Я уважно розібрав ранню документацію Google щодо WebMCP і бачу дуже конкретне зрушення: Chrome починає перетворювати веб-сторінки на нативний шар інструментів для ШІ-агентів. Замість крихкого DOM-скрейпінгу, XPath та емуляції кліків браузер отримує API, через який сторінка сама публікує доступні дії.

У центрі цієї моделі знаходиться navigator.modelContext. Через нього я можу зареєструвати інструмент з ім'ям, описом, JSON Schema для вхідних параметрів та обробником, який повертає структуровану JSON-відповідь. Це вже не «автоматизація поверх інтерфейсу», а повноцінний контракт між веб-додатком та агентом.

Я окремо відзначу два режими. Перший — імперативний JavaScript API з registerTool, unregisterTool, provideContext та clearContext. Другий — декларативний: звичайну HTML-форму можна анотувати атрибутами на кшталт toolname та tooldescription, а Chrome сам будує схему введення.

Для мене це особливо важливо, оскільки WebMCP використовує JSON Schema, сумісну зі звичними стандартами Claude, GPT та Gemini. Отже, архітектура ШІ-рішень стає чистішою: менше проміжних адаптерів, менше нестабільних браузерних сценаріїв, менше ручної підтримки після релізу.

Але я не переоцінюю зрілість технології. Станом на березень 2026 року це все ще рання версія: Chrome 146+, прапорці для розробників, експериментальні можливості та часткова нестабільність декларативного режиму. Я б не закладав WebMCP як єдиний production-контур без fallback-шару.

Вплив на бізнес та автоматизацію

З практичної точки зору я бачу тут удар по цілому класу дорогих інтеграцій. Якщо раніше, щоб зробити ШІ автоматизацію в браузері, команді доводилося будувати Playwright-сценарії, тримати селектори, відстежувати зміни верстки та лагодити ланцюжки після кожного редизайну, то тепер частину логіки можна винести в керовані інструменти сторінки.

Виграють компанії з особистими кабінетами, B2B-порталами, e-commerce та travel-платформами. Там, де агенту потрібно шукати товар, збирати кошик, оформлювати заявку, бронювати або запускати внутрішні операції, WebMCP знижує операційну крихкість. Програють підрядники, які досі продають «розумну автоматизацію» як набір нестабільних скриптів без нормальної AI-архітектури.

Я також бачу пряму користь для команд, які вже роблять впровадження ШІ, але впираються в останній метр інтеграції. Коли агенту потрібен доступ до дій всередині веб-додатка, WebMCP дає більш чистий спосіб, ніж проксіювати все через окремий backend-MCP сервер. Для частини кейсів сторінка сама стає MCP-поверхнею.

При цьому впровадження штучного інтелекту тут не зводиться до включення прапорця в Chrome. У нашій практиці в Nahornyi AI Lab головне питання завжди одне: які дії агенту взагалі можна довірити, як описати контекст, де ставити права, валідацію, аудит та відкат. Без цього будь-яка красива демо-схема швидко перетворюється на ризикований продакшен.

Стратегічний погляд і глибокий розбір

Я вважаю, що WebMCP — це не просто нова API-функція Chrome. Це ранній сигнал, що браузер стає стандартним середовищем виконання для агентних сценаріїв, а веб-продукти будуть змушені проектувати не лише UI для людини, а й tool interface для моделі.

На проектах Nahornyi AI Lab я вже бачив повторюваний патерн: бізнес спочатку просить «підключити агента», а потім з'ясовується, що 70% бюджету з'їдає нестабільна ШІ інтеграція з фронтендом. WebMCP потенційно зрізає цей шар витрат, якщо продуктова команда готова описувати дії як контракт, а не як набір візуальних елементів.

Мій прогноз простий. У найближчі 12–18 місяців ринок розділиться на два класи веб-систем: готові до агентів та ворожі до агентів. Перші отримають дешевшу автоматизацію за допомогою ШІ, швидше впровадять self-service сценарії та знизять вартість підтримки. Другі залишаться заручниками RPA-підходу, де будь-яка зміна кнопки ламає весь бізнес-процес.

Я б уже зараз закладав у roadmap три кроки: виділити критичні дії, формалізувати їх у схеми, а потім побудувати гібридну архітектуру з fallback на класичні браузерні сценарії. Саме так я підходжу до розробки ШІ рішень для бізнесу, коли потрібна не лабораторна демонстрація, а керована система з SLA, безпекою та економікою впровадження.

Цей розбір підготував Вадим Нагорний — ключовий експерт Nahornyi AI Lab з AI-архітектури, впровадження ШІ та промислової ШІ автоматизації. Якщо ви хочете обговорити, як перетворити ваш веб-продукт на agent-ready платформу без зайвого технічного боргу, я запрошую вас на предметну розмову з нашою командою в Nahornyi AI Lab.

Поділитися статтею