Webサイトは公開した瞬間より、その後に更新が止まったときから古くなります。
アクセス解析を開いても、数字の意味を考える時間がない。改善案は思いついても、制作会社への依頼や社内承認で数週間かかる。
ようやく変更しても、何が効いたのか記録されない。小規模な運営ほど、この繰り返しが起きがちです。
AIを入れれば更新速度は上がります。
しかし「アクセスを増やして」と指示し、文章、CTA、レイアウト、SEOを一度に変えれば、成果が上がっても理由を説明できません。
下がったときも、戻すべき箇所が分からなくなります。
2026年7月23日に発表されたRobynn Website Studioは、ページへ測定可能な目標を設定し、分析、変更提案、承認、公開、再計測を7日単位で繰り返すAuto Loopを案内しています。
公式説明では、変更は人の承認前に公開されず、WordPressでは下書きとして戻す運用も示されています。
特定製品を導入すれば自動的に売上が伸びるわけではありません。
ただ、この設計には小規模サイトでも使える考え方があります。
AIは仮説と下書きを速く作り、人は目的、リスク、公開可否を判断する。
本稿では、その分担を毎週回せる8段階へ落とし込みます。
従来のAIサイト制作は、初回公開までの時間短縮が中心でした。
質問へ答えるとページが生成され、文章や画像もそろう。
制作の入口は速くなりましたが、公開後にどのページを直すべきか、変更が成果へつながったかは別の仕事として残りました。
次に増えているのが、公開済みサイトを継続的に診断する仕組みです。
Robynnの公式ページは、ページごとにorganic traffic、conversion、sign-upなどの目標を置き、分析データを読み、毎週一つの変更を提案すると説明しています。
Website StudioのField Guideでは、SEO・GEOの監査結果を人が確認し、承認前はdraft-safeに保つ流れが示されています。
ここで注目すべきなのは「自動で直す」という表現より、変更単位の小ささです。
一ページに一つの目標、一週間に一つの変更であれば、公開前の差分を読みやすく、公開後の数字も比較できます。
複数要素を同時に書き換えるより、検証可能性が高まります。
一方、提供者が掲げる改善実績は、そのまま自社へ当てはめられません。
流入量、商材、既存ページ、計測期間によって結果は変わります。
公式サイトが示す匿名顧客の成果は製品側の事例であり、一般的な保証ではないと分けて読みます。
継続改善の価値は、AIが正解を知っていることではありません。
仮説を出すまでの時間を短縮し、承認、公開、計測、復旧を同じ周期で回せる点にあります。
週次運用は、分析から始める前にページ目的を固定します。
商品ページなら購入、サービスページなら問い合わせ、記事なら次の記事への遷移や資料ダウンロードなど、主目的を一つ選びます。
目的が違えば、改善すべき数字も変わるからです。
基準値は、変更前7日だけでは曜日差の影響を受けます。
流入が少ないサイトでは直近28日を基本にし、前年や前月の同曜日、広告配信、キャンペーンも併記します。
訪問数が数件しかないページなら、一週間で勝敗を決めず、観測期間を延ばします。
仮説には「変える場所」「変える理由」「期待する指標」「悪化とみなす条件」を含めます。
たとえば、ファーストビューの見出しを短くするなら、理由は理解速度、期待指標はCTAクリック率、停止条件はフォーム到達率の低下です。
公開時には変更ID、担当者、対象URL、公開日時、元の版、確認項目を残します。
AIの提案文だけが記録されても、実際に何を公開したか分からなければ検証できません。
AIへの権限は三段階で考えます。第一は提案のみ。
解析結果やページを読み、問題候補と改善案を出しますが、編集権限は持たせません。
導入初期、重要ページ、法規制のある業種はここから始めます。
第二は下書きまで。
文章やレイアウト案を作り、分岐、下書き、ステージングへ保存します。
本番公開は人が行います。
週次運用では最も扱いやすく、速度と確認可能性のバランスを取りやすい範囲です。
第三は承認後の実行です。
人が選んだ変更だけをAIや連携ツールが公開します。
公開権限を与える場合も、削除、ドメイン、決済、フォーム通知先、CMS構造、共通ナビゲーションなど、依頼と無関係な操作は制限します。
文章の誤字、代替テキスト候補、非公開の説明文案は下書きまで任せやすい領域です。
価格、契約条件、法的注記、個人情報フォーム、robots、canonical、構造化データ、計測タグは、人が根拠と差分を確認します。
公開後に影響が広がる共通コンポーネントも自動実行から外します。
Robynnは公式上、分析に基づく提案を人が承認し、二行のJavaScriptで既存サイトへ導入できると説明しています。
Website StudioのField GuideではWordPressへの更新を下書きとして送る流れが示される一方、対応方法はCMSによって同一とは限りません。
契約前に、公開権限、下書き先、変更履歴、復元方法、接続解除後の挙動を実機で確かめます。
一度に変える領域は一つを原則にします。
CTAの文言を直す週に、見出し構造やレイアウトまで変更すれば、クリック率が上がった理由を判別できません。
改善速度を上げたいときほど、変更単位を小さく保ちます。
CTAでは、文言、配置、遷移先、入力負荷を確認します。
文章では、冒頭回答、見出し、具体例、冗長さを扱います。
SEOはtitle、meta description、内部リンク、見出し階層、構造化データを対象にし、表示領域はスマートフォン幅、画像、余白、速度、アクセシビリティへ分けます。
A/Bテストができない小規模サイトでは、変更前後の比較を使います。
ただし、同じ長さの期間、同じ曜日構成、広告や季節要因をそろえます。
公開直後の一日だけで成果を決めず、流入量に応じて7日、14日、28日と観測期間を決めます。
指標は変更内容に近いものを選びます。
見出し変更ならCTAクリック率やスクロール到達、フォーム改善なら開始から完了までの離脱、SEO変更なら表示回数、CTR、対象クエリです。
サイト全体の売上だけを見ると、小さな改善の影響が他要因に埋もれます。
数値が改善しても、問い合わせの質が下がる場合があります。
CTAクリックが増えた一方で対象外の相談が増えたなら、表面的な率だけで採用しません。
定量指標と、問い合わせ内容、営業担当の評価、ユーザーからの質問を組み合わせます。
第1週は計測と権限を整えます。
主要ページを三つ選び、それぞれの目的、基準値、CTA、公開方法、復旧版を記録します。
AIには改善を実行させず、問題候補と根拠だけを出させます。
提案がページの目的を理解しているかを見る期間です。
第2週は一ページで一つの変更を下書きします。
問い合わせページなら、フォームそのものではなく導入文や安心材料など、復旧しやすい部分を選びます。
スマートフォン、リンク、フォーム、SEO、計測を確認し、承認後に公開します。
第3週は変更を維持したまま計測します。
数字が弱くても、計測漏れ、曜日差、広告、検索順位を確認する前に次の修正を重ねません。
明確な不具合や停止条件に触れた場合は、期間を待たず元の版へ戻します。
第4週は結果を三つへ分類します。
目標指標が改善し副作用がなければ維持。方向性は良いものの母数不足や一部悪化があれば修正。
主要成果の低下、フォーム不具合、表示崩れ、検索設定の事故があれば巻き戻します。
停止条件は公開前に数値と事象で決めます。
フォーム送信が一件でも失敗する、主要ページで404が出る、GA4のキーイベントが記録されない、スマートフォンで横スクロールが発生する、主要成果が通常範囲を大きく下回る、といった条件です。
一か月後に見るべき成果は、AIが何件提案したかではありません。
承認までの時間が短くなったか、変更理由と結果が残ったか、悪化時に戻せたか、次の仮説を選べるかです。
この運用が安定してから、対象ページや自動実行の範囲を広げます。
AIによるサイト改善で価値が出るのは、大量の変更を自動公開できたときではありません。
ページの目的を固定し、小さな仮説を下書きし、人が承認した変更だけを公開し、結果を次の判断へ戻せたときです。
毎週一つの変更でも、目的、基準値、差分、結果が残れば学習が積み上がります。
反対に、何を変えたか分からない自動更新は、速度が上がるほど復旧と説明を難しくします。
まずは提案のみ、次に下書き、最後に承認後の実行へ。
権限を段階的に広げる方が、AIを長く使える運用につながります。
.png){kind=logo}
