Breadcrumbを60記事へ手入力しない――Primary Cluster→Pillarから一括生成した方法

60記事へBreadcrumbを一つずつ書く方法は採用しなかった

Knowledgeの動的ページに、読者が現在地をたどれるBreadcrumbを追加することになりました。

対象は既存60記事です。

記事ごとに「Knowledge > Pillar > Cluster」を手入力するのではなく、すでにKnowledge Graphに保存されている分類情報を使って、一括生成する方式を採用しました。

まずKnowledgeコレクションへ専用フィールドを追加した

Knowledgeコレクションには、新しくbreadcrumbフィールドを追加しました。

• key：breadcrumb
• displayName：Breadcrumb｜記事上部ナビ
• type：RICH_TEXT

Breadcrumbをページデザイン側へ直接書き込むのではなく、各Knowledgeが持つCMSデータとして保存する設計です。

基準にしたのは、記事タイトルではなくPrimary Membership

Breadcrumb生成では、KnowledgeClusterMembersを読み、対象記事のmembershipTypeがPRIMARYのMembershipを探しました。

そこからPrimary Clusterを特定し、そのClusterのparentPillarを取得しています。

つまり、表示する現在地を別の一覧表から手作業で決めるのではなく、Knowledge Graphですでに「この記事の主所属」として確定している分類を再利用しました。

表示順は「Knowledge > Pillar > Cluster」

生成されたBreadcrumbの形式は、Knowledge > Pillar > Clusterです。

Knowledgeトップ、Pillar、Primary Clusterの各階層へリンクを設定しました。

内部ではPrimary ClusterからparentPillarをたどって情報を取得しますが、画面上では読者が上位から下位へ理解しやすい順に並べています。

60件を一括生成し、スキップも失敗も0だった

API返却では、totalKnowledge 60、prepared 60、skipped 0。Bulk Actionはsuccess 60、failure 0でした。

この結果から、少なくとも実行時点の60記事について、Breadcrumb用データの生成と保存処理は全件成功したことを確認できます。

ただし、この数字は公開ページ60枚をブラウザで一つずつ開いて表示確認した結果ではありません。

Editor側で触ったのは、動的ページの1要素だった

CMS側で60記事分を生成した後、Wix Editorでは既存Knowledge Datasetから「Breadcrumb｜記事上部ナビ」へ表示要素を接続する手順を案内しました。

可児 波起はこの接続作業を行い、その後「できた」と報告しています。

つまり、CMS/API側の大量データ処理はAIが担当し、Editor上の視覚的な接続操作は人間が一度行う、という役割分担になりました。

分類データを、分類のためだけに閉じ込めなかった

Primary ClusterやPillarは、記事を整理するための内部データとして作られていました。

今回の実装では、その分類情報を読者向けのナビゲーションへ再利用しています。

同じ情報を「分類用」と「表示用」で二重管理しなかった点が、この実装の中心です。

ただし、Primary Clusterを変えたら再生成が必要になる

このBreadcrumbは、生成時点のPrimary Membershipを元に保存されたRich Textです。

そのため、将来ある記事のPrimary Clusterを変更した場合、Breadcrumbが自動的に新分類へ追従する仕組みまで、この作業記録では確認されていません。

分類変更時にBreadcrumbを再生成する運用が守られるかは、採掘時点の未確認事項として残っています。

既存Knowledgeとの違い

既存Knowledge「Wixの動的ページで記事タイトルを変えてもURLを変えない方法」は、タイトルとURLを分離するためのurlKey設計を扱います。

本記事は、動的ページ上の現在地ナビをどう作るかが問いです。

どちらも、表示要素を人間がページごとに直すのではなく、CMS上の安定した構造データからページを組み立てる点で共通しています。

再利用するなら、「表示したい情報がすでにGraphにないか」を先に見る

大量ページへ同じ種類のナビを追加するとき、この実例から再利用できる考え方は次の順番です。

1. 正本を決める：現在地の根拠となる分類データを一つにする。
2. 表示専用フィールドを用意する：動的ページが接続できる形へ変換する。
3. 一括生成する：既存記事数が多くても同じルールで処理する。
4. Editor操作は一度にする：動的ページの1要素をCMSへ接続する。
5. 分類変更時の再生成を設計する：Graph更新と表示データ更新を分離しない。

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

作成後に公開サイトの全60記事を再クロールし、各Breadcrumb表示を個別確認した記録はありません。

また、Primary Cluster変更時にBreadcrumbを自動再生成するイベント駆動の仕組みも、この時点では確認されていません。

確認できるのは、Primary Membership→Primary Cluster→parentPillarの分類データから60記事分のBreadcrumbを生成し、API処理が60／60成功し、Wix EditorでDataset接続後に可児 波起が「できた」と報告したことです。

このKnowledgeの関連知識

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

Breadcrumb一括生成は、CMSの構造データをAPIで読み、表示用データへ変換する具体例として位置づけられます。

動的ページのURL設計と合わせて見る： Wixの動的ページで記事タイトルを変えてもURLを変えない方法

動的ページのURLとBreadcrumbを別々に手入力せず、安定したCMSデータから組み立てる情報設計として接続します。

Breadcrumbを含むGraph全体を完了条件にする： 「文章を書いた」でKnowledgeを完成扱いしない――CMS登録＋Graph統合までを1本の完了条件にした

Breadcrumb一括生成という一工程から、Membership・Relation・Index・Statsまでを含むKnowledge完成条件全体へ進みます。

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

Knowledgeトップを見る