「文章を書いた」でKnowledgeを完成扱いしない――CMS登録＋Graph統合までを1本の完了条件にした

最初に変えたのは、完成の定義だった

Knowledgeを量産するとき、本文を書いてCMSへ保存すれば「1記事完成」と数えることもできます。

しかし「海辺の部屋｜デジタルと波の音」では、Knowledgeを単独の記事ではなく、Pillar・Cluster・Relation・Indexでつながる知識ノードとして運用する方針を採用しました。

そのため、制作ルールの中で「文章を書いた＝Knowledge完成ではない」と繰り返し定義しています。

完了条件には、記事本文以外の構造更新も入れた

作業記録で、Knowledge完成に含めると定義された項目は次の通りです。

• Pillar
• Cluster
• Membership
• Relation
• Breadcrumb
• 関連Knowledge
• 著者下ナビ
• Index
• Stats
• Typography
• Quality Gate

文章制作とサイト構造の保守を別作業にせず、同じ1本の追加工程へ含めています。

なぜ本文保存だけでは不足するのか

新規KnowledgeだけをCMSへ追加すると、本文自体は公開できても、Graph側では別の状態が残る可能性があります。

たとえばPrimary Clusterが未設定ならBreadcrumbの根拠がなく、Relationがなければ孤立ノードになり、Indexへ追加しなければ一覧から辿りにくくなります。Statsを更新しなければ全体件数も古いままです。

このため、記事単体の完成とKnowledge基盤全体の整合を同じ完了条件へまとめました。

監査は完了条件に含めるが、詳細は別Knowledgeで扱う

新規Knowledgeを追加する前後には、本文だけでなくGraph全体の整合も確認します。元の量産フロー設計時には、60 Knowledge、4 Pillars、17 Clusters、83 Active Relations、72 Memberships、21 Indexes、Featured 6を基準点とし、必須フィールド、Primary Membership、Incoming／Outgoing、Cluster件数、Stats、Index body、clamp()など、監査コードで実際に指定した項目を確認しました。監査対象では問題0でした。

ただし、全内部URLのHTTP 200、Self Relation、公開サイト上のリンク切れまでを当時の監査が網羅したわけではありません。監査範囲とOut of Scopeの詳細は、「監査で問題0」と「全部確認した」は違う――Knowledge Graphに基準点と監査範囲を残すへ分離します。

記事追加を「Graph更新トランザクション」と見る

この運用を一段抽象化すると、新規Knowledgeの追加は、文章ファイルを1件増やす操作ではなくなります。

新しいノードを作り、その所属を決め、他ノードとつなぎ、一覧と件数を同期し、表示形式を揃え、最後に整合を確認する一連の更新です。

元のネタ帳では、これを「Knowledgeを記事ではなく、知識グラフの更新トランザクションとして扱う」という分析仮説として整理しています。これは実装上の事実そのものではなく、複数の更新工程をまとめたAIによる抽象化です。

ただし、設計時点では61本目の実地試験はまだだった

このフローを設計し、既存60記事の基準点監査までは実行されました。

一方、元の作業記録時点では「61本目を1本、この新フローで通してテストする」案が出た後、別の引き継ぎ作業へ進んでいます。

KnowledgeStats更新、Index更新、Relation追加、既存記事ナビ再生成、Quality Gateまでを、61本目の新規記事でエンドツーエンド実行した実績は、その作業記録の範囲では未確認でした。

既存Knowledgeとの違い

既存Knowledge「ChatGPTとWixでCMS運用を自動化する設計」は、Wix運用全体を壊れにくくするためのスキーマ・ID・API・監査設計を扱います。

本記事は、Knowledgeを1本追加するときの「何をもって完成とするか」に限定しています。

文章品質ではなく、Graph全体の整合まで含めて完了条件にした運用ルールが問いです。

再利用するなら、完了条件を先に書き出す

複数コレクションや内部リンクを持つ情報基盤でAIに記事追加を任せる場合、先に完了条件を列挙できます。

1. ノード：本文・Evidence・Sourcesが揃ったか。
2. 所属：Primary Clusterと必要なSecondaryがあるか。
3. 接続：Incoming／Outgoing Relationがあるか。
4. 表示：Breadcrumb・関連ナビ・Typographyが揃ったか。
5. 一覧：Cluster／Pillar Indexへ反映したか。
6. 集計：件数・Featuredなどの基準を更新したか。
7. 監査：実際に検査した項目と未検査項目を分けたか。

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

元の作業記録時点では、設計した量産フローを61本目の新規Knowledgeでエンドツーエンド実行した実績は確認できません。

また、当時のQuality Gateは公開サイトの全内部URLへのHTTPアクセスや、すべてのリンク切れを網羅する監査ではありませんでした。

確認できるのは、「文章を書いた＝Knowledge完成ではない」と定義し、CMS登録だけでなくGraph統合・Index・Stats・Typography・Quality Gateまでを完了条件へ含めたことと、既存60記事の監査対象項目では問題0を確認したことです。

このKnowledgeの関連知識

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

Knowledge Graph更新を含む完了条件を、CMSスキーマ・ID・API・監査まで含むWix運用全体の中へ位置づけます。

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

CMSへ書き込んだことと、Graph整合・表示・公開状態まで確認したことを同じ「完了」にしない考え方と接続します。

ルールを別チャットでも実行できる状態へ引き継ぐ： ルールをProject Sourceに保存しただけでは引き継げなかった――全文読解と実行直前の再読を工程化した

Knowledge完成条件をルール化した後、そのルールをProject Sourceへ保存し、必要な工程の直前に再読する設計へ進みます。

完了条件に含めたStats更新の中身を見る： 画面の数字が自動表示されても、元データが自動更新とは限らない――KnowledgeStatsで分けた3種類の自動化

Knowledge追加時に更新していたStatsが、画面の自動表示・エージェント運用・イベント駆動のどの層だったかを具体化します。

現在地： WEB & CMS → 情報資産・サイト構造設計

Knowledgeトップを見る