ChatGPTからWixサイトをどこまで直接運用できるか

実際にどこまでできたのか

海辺の部屋では、ChatGPTからWixへ直接アクセスし、実際のサイトを使って運用可能範囲を検証しました。

最初に別のテストサイトを作り、Knowledge、Experiments、Sources、SiteContentという4つのCMSコレクションを作成しました。その後、記事データの新規登録、同一データの更新、動的ページとの接続、URL構造の変更まで実行しています。

Wix Blogでは、下書き記事の作成だけでなく、本文、抜粋、カテゴリ、タグ、SEOタイトル、SEOディスクリプション、URLスラッグまでChatGPT側から設定できることを確認しました。

CMSとBlogは役割を分ける

すべての記事を同じ仕組みに入れる必要はありません。海辺の部屋では、読み物やコラムはWix Blog、一定の構造で情報を蓄積するKnowledgeやExperimentsはWix CMSに分けています。

CMSでは、タイトル、直接回答、本文、根拠、出典、確認日、更新日、SEOディスクリプションなどを別々のフィールドとして保存できます。これにより、ページデザインを変えても記事データそのものを再編集する必要がありません。

人間が残した方がいい作業

実際に運用してみると、ChatGPTへ任せる価値が高いのは、調査、文章作成、構造化、CMS入力、更新、SEO情報の管理など、繰り返し発生する作業です。

一方で、文字サイズ、余白、写真の見せ方、ページ全体の空気感などはWix Editor上で人間が調整した方が速く、意図も反映しやすいと判断しました。

海辺の部屋では「見た目は人間、中身の運用はChatGPT」という役割分担を基本にしています。

「確認できた範囲」を対象ごとに残す

AIに「ページを見て」と頼むときは、何を読めたのかまで確認します。ページ名や検索結果向けの説明文を取得できたことと、本文を一字一句読んだこと、画面の見た目を確認したことは違うからです。

可児波起が人物ページ /namikikani を制作していた過去の会話では、ChatGPTはページID、URL、検索用の説明文、画像の代替テキストの問題などを確認したと報告しました。一方で、同じ応答の末尾には、Wix内部から本文全文を取得できず、公開URLからも本文を取得できなかったと明記されていました。この応答だけを根拠に「人物ページの全文をレビュー済み」と扱うことはできません。

また、固定ページの画像点検でも、問題箇所の特定と、画像の中身を見て適切な説明を付け、Editorへ反映する作業は分けて報告されています。点検で問題が見つかったことは、修正済みという意味ではありません。

作業を依頼・報告するときは、次の項目を分けて残せます。
読んだもの：記事本文、保存データの特定項目、公開HTML、画面のどれか。
変更したもの：どの記事の、どの項目・要素を変えたか。
変更後に確かめたもの：保存値、公開HTML、PC画面、スマホ画面のどれか。
残っているもの：まだ取得できない本文、Editorでの作業、未確認の画面など。

たとえば「検索用の説明文は更新して保存値を確認。本文は未取得、スマホ表示は未確認」と書けば、次に必要な確認が分かります。これは説明用の記載例であり、人物ページを今回その状態まで修正したという報告ではありません。

分析データにも同じ区別が必要です。過去の会話では、Wix Analyticsを読めるという説明と、Google Analytics 4の接続はまだないという説明が並んでいました。どちらもアクセス解析を扱いますが、片方を取得できたことから、もう片方のデータも確認したとは言えません。報告にはサービス名と対象期間を添えます。

ここで引用したのは当時の会話に書かれた取得・作業範囲です。当時のAPIの生応答やモデル名は確認できておらず、現在のChatGPT・dot・Wixで可能な操作の上限を示すものではありません。以下の2026年9月30日の直接更新例は、それとは別に、実際に行った変更と確認を記録したものです。

既存サイトにも追加できる

検証後、この仕組みを新規サイトだけでなく、既存の海辺の部屋にも追加しました。既存のBlogや固定ページを壊さず、新しいCMSコレクションを追加し、Knowledgeの動的ページを /knowledge/{urlKey} という独立したURL構造で作成しています。

つまり、サイト全体を作り直さなくても、既存ドメインの中に新しい情報レイヤーを追加できます。

2026年9月30日：dotから既存Knowledgeを直接更新した

可児波起は、自身が運営する「海辺の部屋」で、OpenAIのパーソナルアシスタントdotに、既存Knowledgeの修正から公開反映の確認までを依頼しました。対象はECの「商品粗利」と「送料差引後」を分けて見る実例です。

対象記事は、上部のパンくずが「コンテンツと根拠」を示す一方、本文末の「現在地」と著者下の「上位カテゴリ」には旧「WEB & CMS」へのリンクが残っていました。dotはCMSの有効なPRIMARY所属、所属Cluster、その親Pillarを順に取得し、正式な所属がCONTENT & EVIDENCEであることを確認しました。

そのうえで、Wix連携を通じた部分更新で、2か所のリンク先と表示名、上位カテゴリの説明文を修正しました。このWix修正を行うための別のWork・Codexタスクは起動せず、既存のWix Editorのレイアウトも編集していません。

保存されたことと公開HTMLに反映されたことを分けて確認した

修正リクエストは成功し、CMSを読み戻してbodyと著者下ナビのrichtextが意図した内容と一致することを確認しました。更新対象と更新日時以外のフィールドも、変更前と一致しました。

ただし、直後の公開URLから取得したHTMLには旧リンク2か所が残っていました。その後、確認用パラメータを付けたURLで修正後のHTMLを取得し、さらに通常の公開URLでも、パンくずを含む3か所のリンクがCONTENT & EVIDENCEを指すことを確認しました。リンク先ページもHTTP 200で応答しました。

これは取得時点によって公開HTMLが異なったという観測です。どのキャッシュ層や配信処理による差だったかは調べていません。また、HTTP応答とHTMLの確認は、PC・スマホの画面で余白や文字の欠けを確認することとは別です。この修正実例の完了報告時点では、両画面の視覚確認は未実施でした。

直接更新の成功だけでクレジット消費ゼロとは判断しない

可児波起の目的は、これまでChat中心で行っていた記事更新を、クレジット消費を抑えながら自動化することでした。ただし、この実例では利用量画面や課金明細の前後比較を取得していません。

確認できたのは、1記事の限られたナビゲーション修正を、dotからWix連携で実行し、保存内容と公開HTMLまで確かめたことです。「別のWork・Codexタスクを起動しなかった」という実行経路と、「クレジットが減らなかった」という費用の測定結果は、別の主張として扱います。

この1件から、すべての記事更新が同じ手順で完了すること、無料で継続運用できること、24時間の大量制作が検証済みであることは導けません。

実務との接続：生成AIやDXを実際のWeb・マーケティング業務へ組み込む支援の全体像は、海辺の部屋のデジタルマーケティング・DX・生成AI支援にまとめています。

このKnowledgeの関連知識

dotによる更新の具体例：dotから実際に修正した対象記事。商品粗利の結論ではなく、ナビゲーション2か所の修正対象を確かめる具体例として参照する。

ECの「商品粗利」と「送料差引後」を分けて見る

Wix運用の具体例： Media Manager検索が0件でも、商品データなど別の参照経路から画像へ到達できる実例。

Wix Media Managerで画像が見つからないとき、商品データから参照をたどる方法

現在地： WEB & CMS → Wix・CMS・API自動運用

Knowledgeトップを見る