画面の数字が自動表示されても、元データが自動更新とは限らない――KnowledgeStatsで分けた3種類の自動化

最初の問題は、トップページの「60」が静的文字だった

Knowledgeトップには、当時「現在：60 Knowledge ／ 4 Pillars ／ 17 Topic Clusters」と表示していました。

しかし、この数字をページ上へ直接書いたままでは、61本目以降を追加するたびに手作業で直す必要があります。

そこで、件数そのものをCMSデータとして持つためにKnowledgeStatsコレクションを新設しました。

KnowledgeStatsは1レコードの集計用CMSとして作った

作成したコレクションはKnowledgeStats、表示名は「Knowledge Stats｜全体件数」です。

フィールドはtitle、knowledgeCount、pillarCount、clusterCount、countDisplay。権限はinsert／update／removeがADMIN、readがANYONEでした。

集計値を保存するレコードIDはglobalです。

globalには60・4・17を保存した

作成時点のglobalレコードには、knowledgeCount 60、pillarCount 4、clusterCount 17を保存しました。

表示用Rich Textには「現在：60 Knowledge ／ 4 Pillars ／ 17 Topic Clusters」を入れています。

API返却ではこのレコードの保存アクションがINSERTEDとして確認されています。

件数取得は100件を超えても読めるようにした

Knowledge数は当時60件でしたが、集計コードは1回の取得で終わる設計にはしていません。

limit 100で取得し、offsetを増やしながら、取得件数が100件未満になるまで繰り返す方式が使われました。

「現在60件だから十分」という実装ではなく、将来100件を超えても全件集計できるようにした設計です。

KnowledgeトップはCMSレコードを読むだけで表示できるようになった

その後、Knowledgeトップの静的件数テキストを、KnowledgeStatsのcountDisplayへCMS接続する手順を案内しました。

可児 波起は接続後に「できた」と報告しています。

この時点で、画面側はCMSのglobalレコードに保存された数字を表示する構造になりました。

しかし「画面が自動表示」しても「元データが自動更新」とは限らない

ここで自動化の意味を分ける必要があります。

Knowledgeトップは、一度CMS接続すればglobalレコードの内容を画面へ表示できます。

しかし、Knowledgeが61件になった瞬間にknowledgeCountが60から61へ自律的に変わるイベント処理は、この作業記録では実装されていません。

画面がCMSを自動表示することと、CMSレコードそのものが自動再計算されることは別です。

実際の設計は「新規Knowledge作成フローの中で更新する」だった

KnowledgeStatsは、API処理で件数を計算し、その結果をglobalへ保存する方式でした。

以後については、「新しいKnowledgeを追加するたびに件数更新を量産フローへ含める」という運用設計になっています。

つまり、Wix内部だけで完結する常時自律処理ではなく、AI／エージェントがKnowledge追加工程を実行するとき、その工程の一部としてStatsも更新する方式です。

3種類の『自動』を分ける

元の採掘記録では、この違いを次の3段階に分ける分析が置かれています。

1. UI自動表示：保存済みのCMS値を画面が自動で表示する。
2. エージェント運用自動化：AIが新規Knowledge制作フローの中で件数を計算・更新する。
3. イベント駆動自動更新：Knowledge追加などのイベントを検知し、システム側が自律的に再集計する。

この3分類は、実装記録を整理するためのAIによる分析です。Wixの公式用語として定義された分類ではありません。

今回実装したのは、1と2だった

この作業記録で確認できるのは、KnowledgeトップがCMS値を表示する仕組みと、AIが量産フロー内でStats更新を行う運用設計です。

一方、Knowledge追加をトリガーにしてWix側で自律集計するWebhook、hook、automationは実装されていません。

そのため、AIの量産フローを通さず、別経路でKnowledgeだけを追加した場合にKnowledgeStatsが自動更新されることは確認できません。

「自動更新」という言葉だけでは、実装レベルが分からない

画面上では、CMSにつながった数字が常に表示されるため、「自動化された」と感じやすくなります。

しかし運用設計を再現するには、何が自動なのかを分ける必要があります。

表示が自動なのか、エージェントが毎回更新しているのか、イベントが発生した瞬間にシステム自身が動くのかで、保守方法も失敗条件も変わります。

既存Knowledgeとの違い

既存Knowledge「AIに外部サービスを操作させるとき『送信した・保存された・表示された』を分けて確認する」は、外部サービス操作の検証状態を扱います。

本記事は、その考え方を自動化の粒度へ広げた実装例です。

「表示されている」という状態から、「元データまで自律更新されている」と推測しないために、どの層が動いているのかを分けます。

再利用するなら、自動化を説明するときにトリガーを書く

CMSやAIエージェントの運用を設計するとき、「自動更新です」とだけ書かず、次の4点を残せます。

1. 表示元：画面はどのレコード・フィールドを読んでいるか。
2. 更新主体：人間、AIエージェント、Wix内部処理のどれが値を書き換えるか。
3. トリガー：新規記事作成フロー、時刻、イベントなど何が更新を始めるか。
4. 経路外の挙動：通常フローを通さずデータを追加した場合にも追従するか。

このKnowledgeで確認できないこと

元の作業記録では、61本目追加時に60→61へ更新される実地テストはまだ行われていませんでした。

また、Wix側のイベントトリガーを利用した完全自律の集計更新も実装されていません。

確認できるのは、KnowledgeStatsとglobalレコードを作り、60／4／17を保存し、KnowledgeトップをCMS接続して可児 波起が「できた」と確認したこと、そして以後の件数更新を新規Knowledge作成フローへ含める運用設計だったことです。

このKnowledgeの関連知識

「保存された」と「表示された」を分ける： AIに外部サービスを操作させるとき「送信した・保存された・表示された」を分けて確認する

KnowledgeStatsでも、レコード保存・CMS接続・画面表示・次回更新を別の状態として扱う必要があります。

Wix自動運用の全体設計を見る： ChatGPTとWixでCMS運用を自動化する設計

KnowledgeStatsの1レコード運用を、CMSスキーマ・API・更新フロー全体の具体例として確認できます。

件数管理の次に正常基準点と監査範囲を残す： 「監査で問題0」と「全部確認した」は違う――Knowledge Graphに基準点と監査範囲を残す

KnowledgeStatsの数値管理から、Graph全体のBaselineと「どこまで監査したか」を記録する工程へ進みます。

現在地： AI WORKFLOW → 思考・実行・確認の分離

Knowledgeトップを見る