AI Web Production Web Production Service for the AI Era

From “building fast” to “building securely and operating with peace of mind."

A web production service that redesigns website production, quality control, publishing and operation around “AI generation × Git management × automated verification × human approval.” In addition to making production more efficient with AI, we reduce the components running in the public environment to shrink the attack surface for cyberattacks, and make mechanisms for rolling back instantly in the event of failure standard. For CMSs (WordPress, etc.), we choose to “remove, keep, or combine” depending on the characteristics of the site.

BackgroundWhy change how websites are built now?

Conventional CMSs can also be operated securely if updates, configuration and monitoring are handled properly. The difference lies in “the number of things that must be continuously protected” and “the work required in an emergency."

WorkflowWeb production flow for the AI era

We proceed through 7 steps and 5 approval gates (G1–G5). AI handles the labor-intensive parts, while people judge requirements, quality and whether to publish.

SecurityA new website architecture that reduces the attack surface

We reduce the components running in the public environment, cutting down the very parts that can be attacked. The public side only serves files, while production and updates take place in a system separate from the public site and are reflected only after the differences have been reviewed and approved.

Aspect	A Conventional CMS	B Direct operation of AI-generated code	C AI-generated + headless CMS
Emergency vulnerability response	Emergency updates to PHP, CMS and plugins on the public server. If difficult, decide whether to take the site down	Since PHP does not run in the public environment, direct responses stemming from PHP are easier to avoid	Public pages are the same as B. CMS core updates are handled by the CMS provider (for SaaS types)
Attack surface	PHP execution, database and admin panel are on the public server	Mainly static file delivery. Forms, etc. use external services	Public side is static delivery. Admin panel is separated from the public site
Recovery from failures	Restore by aligning the state of the server, database and plugins	Redeploy a known-good version from Git	Code is redeployed; content restored from CMS backups

Even with a static site, management of GitHub, CMS and hosting accounts, dependency packages, external forms and the like is still required. It does not prevent every threat.

CMSCMS: not “remove” but “choose"

There is no one-size-fits-all approach. We choose the optimal approach based on the volume of updates and who will handle them.

Site type	Recommended approach	Who updates
Small corporate site (up to 20 pages, updated a few times a year)	B Direct operation	Production company (on request)
Mid-sized corporate site	C Combined (CMS for news and works only)	Client (articles) + production company (static pages)
Recruitment site	B or C	HR (job postings) + production company
LP / campaign	B Direct operation	Production company / marketing staff
News / blog	C or A	Client's editors
Sites with many products and services / multilingual sites	C Combined	Client's respective staff
Membership sites / web apps	Custom design	Development team

Since there is no CMS build process, initial work hours are easier to keep down for sites with few updates. For sites with frequent article updates, keeping a CMS keeps operating costs lower, so we agree on the update approach at the proposal stage before proceeding.

QualityQuality in two layers: “automated checks” and “human judgment"

Area checked	Automated checks (every time a change is made)	Human review (before approval)
Display / browser compatibility	Display tests and screen comparisons for key pages, automated tests on major browsers	Appearance on actual PCs and smartphones, consistency with design intent
Links / forms	Broken-link detection, form submission tests	Checking auto-reply emails, notification recipients and wording
SEO / page speed	Presence of titles, descriptions, OGP, etc.; page speed measurement	Appropriateness of content; balance between image/video quality and file size
Accessibility	Automated checks for contrast, alt text, etc.	Checks with keyboard navigation and screen readers
Security	Scanning for leaked secrets, vulnerability alerts for dependency packages	Checking external scripts, form destinations and permission settings

The author and the approver are different people. Changes made by AI are always published only after going through “change request → automated verification → approval."

RecoveryOperations that make recovery easy, even after attacks or failures

	Recovery flow
Conventional approach (example)	Problem discovered → impact investigation → check CMS, PHP, plugins and database → fix → functional verification → resume publishing
New approach (example)	Problem discovered → confirm scope of impact → select a known-good version from history → redeploy → verify

Because known-good code and the publishing history remain in Git and the hosting service, it is clear what to roll back to. We routinely retain deployment history, regularly rehearse rollback procedures, and back up CMS data and form data.

* Even with the new approach, root-cause investigation, revoking and reissuing passwords and tokens, and checking external services are still necessary. Account compromise and data loss cannot be resolved by redeployment alone.

Growth CycleKeep updating and improving after launch

Routine tasks: checking dependency package updates (weekly); improvement proposals based on access analytics, LLMO and CRO, and backup restore tests (monthly); uptime monitoring, SSL expiry and form delivery monitoring (continuous).

ValueTurning your website into a corporate asset you can operate with confidence