ChatGPT Sites se posouvá od jednoduchého publikování webů k tvorbě plnohodnotných aplikací, které pracují s firemními daty, přizpůsobují se konkrétním lidem a spolupracují s jejich AI agenty. OpenAI na DevDay 2026 představilo propojení Sites s plánovanými úlohami, osobními konektory, rozšiřitelnými anotacemi a rozhraním WebMCP. Výsledkem má být web, který nejen zobrazuje informace, ale také pomáhá něco skutečně vyřídit.
Za nejpodstatnější považuji změnu samotného zadání. Místo otázky, jak rychle vytvořit stránku, se do popředí dostává otázka, jak z existujících dokumentů, týmových procesů a uživatelského kontextu sestavit užitečný pracovní nástroj. Ukázky zahrnovaly přehled produktových uvedení, práci s úkoly v Linearu i personalizovaný výběr dárků.
Nejde přitom jen o generování rozhraní. Důležitou součástí oznámení je provoz aplikace po zveřejnění: přihlášení, databáze, aktualizace dat, sdílení oprávnění a možnost, aby s aplikací vedle člověka pracoval také jeho agent.
Obsah
- 🚀 Sites už není jen místo pro zveřejnění webu
- 📊 Z tabulky vznikl týmový přehled produktových uvedení
- 🔄 Aktuální aplikace potřebuje víc než první zveřejnění
- 🗃️ Databáze odděluje obsah od změn aplikace
- 🔐 Soukromí je výchozí stav, zveřejnění je další krok
- 👤 Stejná aplikace může každému nabídnout jeho vlastní data
- ✍️ Úkol lze upravit přímo v týmovém přehledu
- 🤝 Spolupráce zahrnuje i právo měnit samotnou aplikaci
- 🎨 Vlastní anotace ukazují, co lze bezpečně a srozumitelně upravit
- 🎁 Veřejná aplikace ukázala práci s obrazovým API
- 🧰 WebMCP nabízí agentovi nástroje místo pouhého klikání
- 🐶 Osobní kontext se proměnil v konkrétní návrhy dárků
- 🧭 Co z oznámení vyplývá pro návrh dalších aplikací
🚀 Sites už není jen místo pro zveřejnění webu
Sites vzniklo z praktického problému uvnitř OpenAI. John, vedoucí vývoje této služby, původně vytvářel interní webové aplikace pro výzkumníky. Nasazování do firemní infrastruktury však považoval za zbytečně obtížné. Připravil proto prototyp jednoduššího publikování plnohodnotných webových aplikací přímo z Codexu.
Nástroj se nejprve šířil mezi vývojáři, později jej začali používat i lidé bez technické role. Z interního řešení následně vznikl samostatný tým a veřejně představená služba. Podle údajů uvedených na DevDay už platforma hostovala osm milionů Sites a vlastní aplikace v ní vytvářelo více než 70 procent zaměstnanců OpenAI.
Tato čísla chápu jako údaje prezentované firmou, nikoli jako nezávisle ověřenou statistiku. Dobře ale vystihují šíři použití, kterou OpenAI popisuje:
- rozpracování nápadů společně s kolegy,
- interaktivní prezentace namísto klasických snímků,
- specializovaná rozhraní nahrazující tabulky,
- interní nástroje přizpůsobené jednotlivým týmům,
- prototypy, produkční aplikace i hry.
Za společný jmenovatel považuji menší vzdálenost mezi člověkem, který rozumí problému, a funkčním řešením. Produktový manažer, designér nebo pracovník IT nemusí svůj nápad nejprve převést do rozsáhlého zadání pro samostatný vývojový projekt. Může začít popisem požadovaného výsledku a postupně jej zpřesňovat.
Sites je přitom prezentováno jako prostředí pro aplikace s uživatelským rozhraním i serverovou částí, nikoli pouze jako generátor statických stránek. Právě tato vlastnost propojuje všechny další předvedené novinky.
📊 Z tabulky vznikl týmový přehled produktových uvedení
První praktická ukázka vycházela z důvěrně známé situace: tým spravuje důležité informace v tabulce. V tomto případě šlo o přehled novinek připravovaných pro DevDay, jejich průběžný stav a odkazy na související dokumenty a podklady.
Tabulka poskytovala rychlý souhrn, ale hůře se v ní hledaly podrobnosti jednotlivých projektů. Katia proto zadala Codexu, aby z podkladu vytvořil aplikaci pro sledování připravovaných uvedení a publikoval ji jako Site. Součástí zadání bylo využití sdílené knihovny uživatelského rozhraní a existujícího návrhového systému.
Požadavky byly konkrétní a zaměřené na práci týmu:
- zobrazit připravovaná uvedení hned na první obrazovce,
- zdůraznit milníky a oblasti vyžadující pozornost,
- umožnit filtrování podle produktové oblasti,
- nabídnout seznam, nástěnku a kalendář,
- zpřístupnit dokumentaci a další podklady ke každé položce.
Výsledná aplikace během ukázky skutečně nabídla požadované pohledy i odpovídající vizuální styl. Za užitečné považuji zejména to, že se zadání nesoustředilo na technické detaily implementace. Popisovalo informace, které lidé potřebují vidět, a činnosti, které chtějí provádět.
Neznamená to, že každá tabulka potřebuje vlastní aplikaci. V předvedeném případě ale dávala změna smysl: stejné podklady získaly několik způsobů zobrazení a přímější cestu k detailům. Data zůstala základem, zatímco rozhraní se přizpůsobilo konkrétní práci.
Katia zároveň upozornila, že ukázková tabulka nebyla kompletním skutečným seznamem všech novinek DevDay. Popsaný způsob práce však odpovídal tomu, jak interní týmy Sites při přípravách používaly.
🔄 Aktuální aplikace potřebuje víc než první zveřejnění
Vytvořit přehled z tabulky je jen začátek. Pokud se podkladové dokumenty průběžně mění, může i hezká aplikace rychle zastarat. Druhá část zadání proto požadovala, aby Codex každé ráno aktualizoval obsah podle dokumentů odkazovaných z původního přehledu.
Tady se spojily dvě funkce: zásuvné moduly a plánované úlohy. Zásuvné moduly podle představeného modelu sdružují konektory a dovednosti, díky nimž mohou ChatGPT a Codex pracovat s daty externích služeb. V ukázce šlo o dokumenty na Google Drivu.
John uvedl také další příklady: načtení úkolů přiřazených konkrétnímu člověku v Linearu, vyhledávání zpráv ve Slacku nebo přidávání komentářů k návrhům změn na GitHubu. Podstatné je, že Codex nemusí vycházet jen z jednorázově přiloženého souboru. Může znovu sáhnout ke zdroji a získat novější informace.
Plánovaná úloha pak určuje, kdy se má tato práce opakovat. Zadání může požadovat hodinový, denní nebo týdenní interval. Vytvoření takové úlohy probíhá přímo v konverzaci, nikoli jako oddělený administrativní proces.
Na DevDay bylo oznámeno také užší propojení plánovaných úloh se Sites. Úloha a příslušná aplikace mohou být svázány pro snazší správu a Codex má plánování navrhovat v situacích, kdy dává smysl.
Za důležitý rozdíl považuji přechod od jednorázového výsledku k průběžně udržovanému nástroji. Tým nemusí pokaždé znovu žádat o sestavení přehledu. Místo toho jednou stanoví zdroje a rytmus aktualizace a aplikace podle nich dále pracuje.
🗃️ Databáze odděluje obsah od změn aplikace
Automatické doplňování informací by bylo méně praktické, kdyby každá změna vyžadovala přepsání a nové nasazení celého webu. Sites proto zahrnuje databázi SQLite. Naplánovaná úloha může aktualizovat přímo uložená data, aniž by musela měnit zdrojový kód aplikace.
Rozdíl je jednoduchý, ale podstatný. Změna termínu uvedení produktu je změnou obsahu. Přidání nového typu kalendáře je změnou aplikace. Předvedený přístup umožňuje tyto dvě věci oddělit a běžné aktualizace řešit na datové úrovni.
V praxi tak popsaný postup vypadal následovně:
- Naplánovaná úloha se spustí v určený čas.
- Pomocí příslušného zásuvného modulu načte relevantní dokumenty.
- Codex promítne nové informace do databáze aplikace.
- Site zobrazí aktualizovaný obsah bez nového nasazení zdrojového kódu.
Pro základní orientaci v použité technologii doporučuji oficiální přehled SQLite. V kontextu oznámení je však důležitější její role než technické podrobnosti: poskytuje místo pro stav aplikace, který se může průběžně měnit.
Právě zde vidím hranici mezi interaktivním dokumentem a skutečným pracovním nástrojem. Interaktivní dokument může výborně představit určitý stav věcí. Aplikace s databází a automatickou aktualizací má ambici zůstávat použitelná i poté, co se tento stav změní.
Samotná automatizace samozřejmě neříká, zda jsou zdrojové dokumenty správné. Ukázka řešila především přenos jejich aktuálního obsahu do aplikace, nikoli nezávislé ověřování všech uvedených informací.
🔐 Soukromí je výchozí stav, zveřejnění je další krok
Další část oznámení se týkala přístupu uživatelů. Nové Sites jsou podle představeného nastavení ve výchozím stavu soukromé. Než člověk do takové aplikace vstoupí, přihlásí se prostřednictvím funkce Sign in with ChatGPT a služba ověří jeho přístup.
Za důležitý detail považuji skutečnost, že po tomto ověření už člověk přichází do samotné aplikace přihlášený. Autor interního nástroje tedy nemusí pro základní vstup vytvářet samostatnou přihlašovací zkušenost.
Současně existuje možnost zpřístupnit Site veřejně na internetu. Veřejná aplikace může nabídnout vstupní stránku anonymním návštěvníkům a doplnit přihlášení přes ChatGPT pro další funkce. Nejde tedy o jediný pevně daný model publikování.
Při čtení těchto novinek rozlišuji tři samostatné otázky:
- Kdo smí aplikaci otevřít? To řeší nastavení její dostupnosti a přístupových práv.
- Jaká data se konkrétnímu člověku zobrazí? To souvisí s jeho přihlášením a připojenými službami.
- Kdo smí aplikaci měnit? To je zvláštní oprávnění pro úpravy samotného Site.
Toto rozlišení pomáhá nepovažovat přihlášení za univerzální odpověď na všechny otázky kolem oprávnění. V předvedeném řešení tvoří identita základ, na který navazuje přístup k osobním datům a případně i možnost publikovat změny aplikace.
Pro interní týmový přehled je tak možné nejprve určit konkrétní spolupracovníky a teprve podle potřeby řešit širší sdílení. Veřejné vystavení není automatickým důsledkem vytvoření webové aplikace.
👤 Stejná aplikace může každému nabídnout jeho vlastní data
Jednou z hlavních novinek je možnost přenést do soukromého Site zásuvné moduly, které má přihlášený spolupracovník dostupné v ChatGPT. Aplikace tak nemusí zobrazovat pouze společný týmový obsah. Může vedle něj načíst také informace vztahující se ke konkrétnímu člověku.
Katia tento princip předvedla rozšířením aplikace o konektor pro Linear s oprávněním ke čtení i zápisu. Zadání požadovalo, aby každý uživatel viděl své přiřazené úkoly vedle relevantních produktových uvedení a mohl změnit jejich stav nebo popis.
Po otevření aplikace se Katii zobrazily její úkoly. John poté otevřel stejný Site, ale ve stejné části rozhraní našel své vlastní položky. Data se načetla při otevření stránky prostřednictvím jeho existujícího propojení s Linearem v ChatGPT.
Personalizace zde neznamená jinou barvu nebo uvítací text. Znamená jiné pracovní informace ve společném rozhraní. Právě tento rozdíl považuji za nejpraktičtější část ukázky. Tým sdílí jeden přehled, ale každý v něm zároveň vidí, co se týká jeho práce.
Podle Johna nebylo pro tento scénář nutné samostatně implementovat integraci třetí strany, obstarávat API klíče ani procházet dokumentaci jejího rozhraní. Site využilo již existující uživatelské konektory. Stejný princip byl popsán i pro interní firemní konektory.
To ale neznamená neomezený přístup ke všem týmovým datům. Podstatou ukázky bylo právě použití propojení konkrétního přihlášeného člověka. Výsledek se proto lišil podle toho, kdo aplikaci otevřel.
✍️ Úkol lze upravit přímo v týmovém přehledu
Propojení s Linearem nezůstalo jen u načítání dat. John v aplikaci otevřel jeden ze svých úkolů a změnil jeho stav z označení zrušeného úkolu na rozpracovaný. Po uložení rozhraní potvrdilo úspěšnou změnu.
Tento drobný krok je pro význam celé aplikace zásadní. Přehled, ze kterého je nutné pokaždé odejít do původního systému, slouží hlavně jako orientační bod. Přehled umožňující provést relevantní změnu se stává místem, kde lze část práce rovnou dokončit.
V předvedeném zadání mělo být možné upravovat stav i popis úkolu. Praktická demonstrace ukázala změnu stavu. Rozlišuji to proto, aby se požadovaná funkce nezaměňovala s každým jednotlivým krokem, který byl skutečně předveden.
Za užitečnou návrhovou zásadu považuji spojení společného kontextu a osobní akce. V horní části může člověk sledovat, co tým chystá. Ve své části pak upraví úkol související s konkrétním uvedením. Nemusí si tento vztah pokaždé skládat z několika oddělených obrazovek.
Další informace o samotné službě nabízí dokumentace Linearu. V tomto scénáři ale zůstává Linear zdrojovým pracovním systémem, zatímco Site představuje přizpůsobené rozhraní propojující jeho úkoly s širším týmovým přehledem.
🤝 Spolupráce zahrnuje i právo měnit samotnou aplikaci
Sdílení Sites není omezeno na zpřístupnění hotového výsledku. Katia přidala Johna mezi konkrétní pozvané osoby a udělila mu roli editora. Tato role umožňuje oprávněným lidem v pracovním prostoru publikovat aktualizace hostované aplikace.
Je důležité nezaměňovat ji s možností upravit úkol v Linearu. Zápis do externí služby mění pracovní data. Editorský přístup k Site umožňuje měnit aplikaci, která tato data zobrazuje a zpracovává.
V tom vidím posun od osobního výtvoru ke společnému týmovému nástroji. První verzi může připravit jeden člověk, ale další úpravy nemusí zůstat závislé pouze na něm. Kolega s odpovídajícím oprávněním může pokračovat ve vývoji rozhraní.
Ukázka zároveň spojila sdílení aplikace s kontrolou její automatizace. V prostředí byla dohledatelná plánovaná úloha navázaná na konkrétní Site, která měla každý den načítat změny z dokumentů na Drivu.
Pro správu podobného nástroje považuji tuto vazbu za stejně podstatnou jako samotný odkaz ke sdílení. Nestačí vědět, kdo aplikaci používá. Je užitečné také rozumět tomu, odkud bere data, kdy je obnovuje a kdo má právo změnit její podobu.
Nově oznámené propojení úloh a Sites má právě tento provozní obraz zpřehlednit. Automatická aktualizace pak není neviditelným dodatkem, ale součástí správy konkrétní aplikace.
🎨 Vlastní anotace ukazují, co lze bezpečně a srozumitelně upravit
Pro společné úpravy rozhraní představilo OpenAI rozšiřitelné anotace v prohlížeči uvnitř ChatGPT. Vývojáři mohou do HTML aplikace vložit vlastní možnosti, které Codexu a oprávněným uživatelům napovídají, jak lze dané prvky upravovat.
Může jít o navržené zadání nebo vlastní ovládací prvky. Smyslem není jen označit kus stránky a požádat o libovolnou změnu. Aplikace sama může nabídnout srozumitelnou cestu k úpravám, které její komponenty podporují.
John například použil tlačítko pro úpravu rozhraní, které zpřístupnilo připravený návrh zadání. Následně v režimu anotací vybral stavový prvek a z nabízených možností zvolil větší variantu. Změna se okamžitě promítla do náhledu.
Náhled však nebyl totéž jako trvalé provedení změny. Aby se úprava skutečně zapsala do aplikace, bylo potřeba předat příslušný pokyn Codexu. Toto oddělení považuji za užitečné: člověk si nejprve ověří výsledek a potom požádá o jeho realizaci.
Největší přínos mají podle představení vlastní anotace pro návrhové systémy a knihovny komponent. Pokud už komponenta obsahuje více podporovaných variant, může je zpřístupnit přímo tam, kde je někdo potřebuje vybrat.
Pro tým to znamená srozumitelnější spolupráci. Místo neurčitého požadavku na výraznější stavový ukazatel lze vycházet z konkrétní nabízené možnosti. Autor komponenty předem připraví vodítka a další editor nemusí znát všechny její technické parametry.
🎁 Veřejná aplikace ukázala práci s obrazovým API
Druhá velká ukázka opustila interní týmový přehled a zaměřila se na aplikaci pro širší veřejnost. Šlo o studio pro sestavení personalizované dárkové krabičky. Katia v něm nejprve pořídila fotografii a nechala vytvořit návrh vzhledu obalu.
Generování využívalo obrazové API OpenAI. Potřebný API klíč byl uložen jako tajná hodnota v proměnných prostředí. Podle představení lze stejným způsobem připojovat i další služby, podobně jako u jiné plnohodnotné webové aplikace.
Za důležité považuji odlišit tento scénář od osobních konektorů předchozí ukázky. Tam aplikace využívala existující připojení jednotlivých uživatelů. Zde provozovatel aplikace přidal vlastní integrační údaj pro službu, kterou aplikace potřebovala ke své funkci.
První část práce byla přímočará: fotografie posloužila jako vstup a model připravil návrh krabičky. Následoval výběr předmětů z katalogu a nakonec vytvoření osobního vzkazu.
Právě tyto další kroky posloužily jako příklad aplikace navržené nejen pro ruční ovládání, ale i pro spolupráci s agentem. Člověk mohl katalog procházet sám. Nemusel však u každého kroku začínat od nuly, pokud jeho agent už znal relevantní souvislosti.
Ukázka tak propojila dvě schopnosti Sites: běžnou integraci externího API a nové rozhraní umožňující agentovi jednat uvnitř živé aplikace. Každá řeší jinou část úkolu a teprve dohromady vytvářejí celou zkušenost.
🧰 WebMCP nabízí agentovi nástroje místo pouhého klikání
WebMCP bylo na DevDay představeno jako nové webové rozhraní pro zpřístupnění nástrojů aplikace agentům. V kompatibilním prohlížeči, například v prohlížeči uvnitř ChatGPT, může agent tyto nástroje volat a provádět akce, jejichž výsledek se projeví v otevřené aplikaci.
Rozdíl proti ovládání počítače přes grafické rozhraní spočívá v cestě k výsledku. Agent nemusí vždy postupně klikat na položky, otevírat jejich detaily a vyčítat dostupné informace z obrazovky. Aplikace mu může nabídnout přímo nástroj pro potřebnou činnost nebo dotaz na data.
Podle představení to může být v závislosti na konkrétním použití rychlejší a levnější. Nejde o příslib, že každý úkol bude automaticky efektivnější. Přínos vychází z toho, zda aplikace zpřístupní vhodné nástroje pro daný postup.
Za nejdůležitější považuji, že se výsledek neodehrává pouze v oddělené konverzaci. Agent může upravit stav živé aplikace a člověk s ním následně pracuje ve stejném rozhraní.
Pro základní kontext k souvisejícímu ekosystému lze využít dokumentaci Model Context Protocol. Konkrétní role WebMCP v představené ukázce ale byla jasná: zpřístupnit agentovi činnosti webové aplikace, nikoli jej nutit napodobovat každý lidský klik.
OpenAI uvedlo, že při tvorbě přes Sites má příslušná podpora vznikat automaticky tam, kde je relevantní, protože integrační vrstva Sites umí WebMCP implementovat. Beru to jako popis zamýšleného zjednodušení vývoje, nikoli jako záruku stejné podpory v každém webovém prostředí.
🐶 Osobní kontext se proměnil v konkrétní návrhy dárků
Katia požádala svého agenta, aby ve Slacku vyhledal, co má John rád, včetně jejich přímých zpráv. Na základě zjištěných informací měl navrhnout vhodné dárky z katalogu a zobrazit je přímo nad sestavovanou krabičkou.
Agent podle ukázky zachytil Johnův vztah k jeho psovi a mezi doporučení zařadil také hračky pro psa. Podstatný nebyl jen samotný výběr. Doporučení se objevila přímo v uživatelském rozhraní, kde je Katia mohla dále upravit.
Některé položky odstranila a výběr omezila s ohledem na zamýšlený rozpočet pod sto dolarů. Poté přidala vybrané předměty do košíku a pokračovala k osobnímu vzkazu.
V závěrečném kroku požádala ChatGPT, aby navrhlo text podle předchozích diskusí a vložilo jej do rozhraní. Návrh zkontrolovala a potvrdila. Ukázka tedy zachovala viditelný prostor pro lidský výběr i závěrečné rozhodnutí.
Aplikace nabídla katalog a akce, agent dodal osobní kontext a člověk rozhodl o výsledku. Tuto dělbu rolí považuji za výstižnější než představu, že personalizaci musí vždy kompletně řešit samotný provozovatel webu.
Zároveň z ukázky nevyplývá, že by web získal neomezený přístup k soukromým zprávám. Vyhledávání prováděl agent uživatelky v rámci jejího požadavku a dostupných propojení. WebMCP mu poskytovalo způsob, jak výsledné návrhy promítnout do aplikace.
🧭 Co z oznámení vyplývá pro návrh dalších aplikací
V představených novinkách vidím tři navazující změny. První zjednodušuje vznik aplikace, druhá její další provoz a třetí způsob, jakým ji lidé používají společně s agenty. Síla Sites má spočívat právě v jejich propojení.
Pro vlastní návrh bych si z ukázek odnesl několik konkrétních otázek:
- Jaký pracovní problém řeším? Počáteční zadání má popsat potřebné informace a akce, ne jen vzhled stránky.
- Odkud přicházejí změny? Pokud existují průběžně aktualizované zdroje, dává smysl zvážit konektor a plánovanou úlohu.
- Co je společné a co osobní? Týmový přehled může doplnit individuální pohled bez vytváření oddělených aplikací.
- Kdo smí měnit data a kdo aplikaci? Tato oprávnění mají odlišný význam.
- Které úpravy lze nabídnout předem? Vlastní anotace mohou usnadnit spolupráci nad komponentami.
- Jaké činnosti má zvládnout agent? Vhodné nástroje WebMCP mohou doplnit běžné lidské ovládání.
OpenAI shrnulo Sites jako automaticky škálující plnohodnotné webové aplikace s přihlášením, databází, přístupem k uživatelským datům přes zásuvné moduly a podporou lidí i agentů. Předvedené scénáře tento směr ilustrovaly od první tabulky až po personalizovanou veřejnou službu.
Za hlavní zprávu DevDay 2026 proto nepovažuji pouze rychlejší tvorbu webů. Podstatnější je možnost vytvářet menší, konkrétně zaměřené aplikace, které zůstávají napojené na skutečnou práci. Pokud se podaří spojit aktuální data, srozumitelná oprávnění a užitečné nástroje pro agenty, web nemusí být jen místem, kde informace hledám. Může být prostředím, ve kterém je rovnou využiji.
