「文章を書いた」で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が60記事だった時点の設計です。その後、NewsPicksコメント制作でAIと人間の役割を扱う記事の制作会話では、関連記事の登録が3件あることなどを挙げて、AIがDONE（完了）と報告しました。しかし著者は「内部リンクがほぼない」と指摘し、次の記事へ進むのを止めました。

AIは読み戻し結果として、本文中の内部リンクは0本で、記事末の案内などはあると報告し、DONEを撤回しました。ここで見直されたのは、関連記事を管理データに登録したかだけでなく、読者が説明を読んでいる場所から必要な記事へ進めるか、という確認でした。

関連記事の登録と、ページ上の案内は次のように分けられます。

• 関連記事の登録（Relation）：どの記事と、どのような意味でつなぐかを保存するデータ。
• 本文中のリンク：その段落の前提や具体例を知りたいときに進む入口。
• 本文末の関連案内：この記事との関係と、次に読む理由を示す場所。
• 著者下の「次に読む」：読み終えた人に次の行動を案内する場所。

直近5記事の比較報告では、関連記事の登録があっても、すべてを本文へ機械的に貼る必要はないと整理されました。本文には、その箇所の理解を深めるリンクを選びます。本文末と著者下にも同じ一覧をコピーするのではなく、それぞれの案内が何の役に立つかを確かめます。

その後、AIは本文中に3本を追加し、本文末の関連案内を新設したと報告しました。また、本文中リンクの確認を独立した工程にする手順文が残っています。今回確かめたのは、著者の指摘、完了の撤回、修復報告と手順文の内容です。当時の変更前後の保存データや公開ページを照合したものではなく、修復成功や、その後の漏れ削減を実証した事例とは扱いません。

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

新規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. 接続：他の記事との関連データについて、相手・意味・方向を確認したか。
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を確認したことです。後の制作会話では、内部リンク不足の指摘で完成判定が撤回され、本文中リンクを別工程で確認する手順が加わったことも確認しました。

カードの見出しを変えても下の一覧が旧分野のまま残った例は、CMSカード複製時の接続先確認で詳しく扱います。登録値と画面の一致までを完了条件にする理由が分かります。

この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トップを見る