107 Knowledge監査で91件にlegacy categoryが残っていた――分類のSource of TruthをPrimary Clusterへ一本化した実例

結論――分類の正本は1つにする

分類情報が複数の場所にあること自体が、すぐ不具合になるわけではありません。問題は、それぞれを同じ「現在の分類」として更新し続けることです。

海辺の部屋では、初期Knowledgeの多くに `category` が入っていました。その後Knowledge Graphを構築し、Primary ClusterとparentPillarを持つ構造へ移行しました。現在はPrimary Cluster側だけを正式分類として使い、新しいKnowledgeではcategoryを設定していません。

監査時点で、categoryは91件に残り、16件は空欄だった

107 KnowledgeをWix CMSから取得して確認すると、legacy `category` に値が入っていた記事は91件、空欄は16件でした。

categoryの値は16種類あり、「生成AI・業務活用」「AI・Web実務」「生成AI・映像制作」「コンテンツ・Evidence」など、初期運用で使っていた分類名が残っています。

一方、107本を監査した時点で、作成日時が新しい16本はすべてcategory=nullでした。つまり、旧フィールドを削除したわけではないものの、新規Knowledgeの分類経路からは外れています。

Primary Clusterは107 / 107で全Knowledgeに存在していた

同じ監査で、KnowledgeClusterMembersの active=true かつ membershipType=PRIMARY を確認すると、107 KnowledgeすべてにPrimary Membershipが1件ずつ存在しました。欠落も重複もありませんでした。

Primary ClusterにはparentPillarがあり、現在の正式分類は Knowledge → Primary Cluster → parentPillar という一つの経路で表現できます。

BreadcrumbとCluster/Pillar Indexの分類はこのPrimaryを基準にし、KnowledgeStatsはWixの現在データから再計算します。

旧categoryとPrimary Clusterは、同じ分類体系ではない

legacy categoryには16種類のテキスト値があります。一方、2026年9月28日の監査では、Primary Clusterは18 Topic Clustersで構成され、その上に5 Pillarがありました。

たとえば旧categoryが「生成AI・業務活用」の記事でも、現在は「思考・実行・確認の分離」「判断基準・レビュー設計」など別々のPrimary Clusterへ所属しています。

これは必ずしも旧categoryが間違っているという意味ではありません。監査時点では、旧categoryの16種類と監査時点の18 Topic Clustersは一対一対応しない別の分類体系として残っていました。だからこそ、両方を同じ正本として更新し続けない方が安全です。

直近記事でcategoryを空欄にしたのは、Primaryだけを更新すればよい状態にするため

2026年9月27日以降の正式フローでは、Primary Clusterを必ず1つ持たせ、そのparentPillarまでを分類の正本としています。旧categoryはlegacyとして残し、新規Knowledgeの正式分類には使いません。

この方法なら、新規記事作成時にcategoryとPrimary Clusterの両方へ同じ意味を二重入力する必要がありません。分類変更が起きた場合も、Primary Membershipと親Pillarを直し、そこからBreadcrumbやIndexを再生成できます。

BreadcrumbをPrimary Clusterから生成する設計と相性がよい

Breadcrumbを60記事へ手入力しない――Primary Cluster→Pillarから一括生成した方法では、Primary MembershipからClusterとPillarをたどり、各KnowledgeのBreadcrumbを生成しています。

このようにナビゲーションまでPrimary分類から生成するなら、categoryを別の分類正本として維持する必要はありません。分類と表示を同じSource of Truthから作る方が、変更箇所を減らせます。

Pillar再編が起きても、Primary Clusterを基準に追える

101 Knowledge時点で4 Pillar構成を見直し、AI CREATIVEを独立させた実例では、Knowledgeの増加に合わせてPillar自体を再編しました。

このときも、KnowledgeごとのPrimary Clusterと各ClusterのparentPillarを基準にすれば、記事単位の分類を維持したまま上位構造を変更できます。

分類のSource of Truthを複数持つより、1つの構造からPillar、Breadcrumb、Indexへ派生させる方が、変更の影響範囲を追いやすくなります。

Project Sourceでも、正本・旧版・補助資料を分けた

分類だけでなく、ルール文書でも同じ問題が起きます。AI向けProject Sourcesは増やすだけでは整理できない――正本・旧版・補助資料を分けた実例では、複数の資料をすべて同じ強さで参照せず、どれを正本として扱うかを分けています。

今回のcategoryも同様で、フィールドが残っていることと、現在の正本であることは別です。残っているlegacy情報を、現在の運用判断へ自動的に昇格させません。

確認できたことと、まだ確認できていないこと

確認できたこと：監査時点で107 Knowledge中91件にlegacy categoryがあり、16件は空欄だったこと。categoryは16種類存在したこと。直近16本はcategory=nullだったこと。107 KnowledgeすべてにPrimary Membershipが1件ずつ存在したこと。現在の正本ルールではPrimary Cluster → parentPillarを正式分類とし、categoryを新規正式分類に使わないこと。

確認できていないこと：過去91件のcategoryをすべて削除すべきか、残しておくことで将来別用途に使えるかは、このKnowledgeでは判断していません。また、Source of Truth一本化による運用時間短縮やエラー率低下も測定していません。

したがって本Knowledgeは、legacy categoryを一括削除する提案ではありません。現在の分類判断・集計・ナビゲーションで使う正本をPrimary Clusterへ一本化した運用を記録するものです。

このKnowledgeの関連知識

分類以外の正本管理へ広げる：AI向けProject Sourcesは増やすだけでは整理できない――正本・旧版・補助資料を分けた実例。categoryとPrimary Clusterのような構造化データの正本管理から、Project Sourcesの正本・旧版・補助資料の区別へ一般化する。

Primary分類を保ちながら上位Pillarを再編する：101 Knowledge時点で4 Pillar構成を見直し、AI CREATIVEを独立させた――増えたKnowledgeに合わせて分類を再編した実例。KnowledgeごとのPrimary Clusterを正本にしたまま、Knowledge増加後にparentPillar側の構造を再編する運用を補完する。

Primary Clusterをナビの正本として再利用する：Breadcrumbを60記事へ手入力しない――Primary Cluster→Pillarから一括生成した方法。Primary MembershipからClusterとPillarをたどってBreadcrumbを生成する実例として、分類Source of Truth一本化の具体的な利用先を見る。