「監査で問題0」と「全部確認した」は違う――Knowledge Graphに基準点と監査範囲を残す

量産を始める前に、まず「正常な状態」を数値で残した

新規Knowledgeを増やす前に、既存60記事のKnowledge GraphをAPIで監査しました。

目的は、将来の記事追加後に「何かがおかしい」と感じたとき、変更前の状態と比較できる基準を持つことです。

その時点の数値は、60 Knowledge、4 Pillars、17 Clusters、83 Active Relations、72 Memberships、21 Indexes、Featured 6でした。

監査結果はproblemsCount 0だった

監査返却では、problemsCount 0でした。

• noOutgoing：0
• noIncoming：0
• clusterCountMismatches：0
• statsMismatch：false
• indexBodyMissing：0

この結果は、監査コードが対象にした項目について問題を検出しなかったことを意味します。

必須フィールドは、9項目を確認した

各Knowledgeについて、監査コードでは少なくとも次の必須フィールドの存在を確認しました。

• title
• urlKey
• directAnswer
• body
• evidence
• breadcrumb
• richtext
• heroImage
• author

Primary Membershipは1記事1件であることを確認した

KnowledgeClusterMembersでは、各KnowledgeについてmembershipTypeがPRIMARYの件数を数え、1件ではない場合を問題として扱うコードが実行されました。

監査結果では、この項目の問題は0件でした。

これは「Primary Clusterが正しい意味で選ばれている」ことまで保証するものではなく、少なくともPRIMARY Membershipが1件という構造条件を満たしていたことを示します。

IncomingとOutgoingの両方を見た

KnowledgeRelationsについては、各KnowledgeのIncomingとOutgoingを計算しました。

bidirectionalがtrueの場合は逆方向もIncoming／Outgoingへ計上し、孤立回避の観点から双方が0ではないか確認しています。

結果はIncoming 0なし、Outgoing 0なしでした。

「問題0」でも、見ていない項目は残っていた

ここが本記事の中心です。

元の作業記録には、監査コードで直接検査していなかった項目も明記されています。

• すべての内部URLへ実際にアクセスしてHTTP 200を確認すること。
• Self Relationの網羅確認。
• 公開サイト上でのリンク切れの網羅確認。

したがって「problemsCount 0」を「サイト全体のあらゆる問題を確認して0件だった」と読み替えることはできません。

Quality Gateという名前も、実際の検査範囲より広く見えることがある

「監査」「Quality Gate」「リンク監査」という言葉は、聞き手によってはサイト全体を完全検査したように受け取られる場合があります。

今回の記録では、返却値だけでなく、何を検査し、何を検査していないかも残しました。

これにより、後から「問題0」という結果だけが独り歩きするのを避けやすくなります。

基準点は、将来の差分監査のためのBeforeになる

60／4／17／83／72／21／6という数字は、それ自体が理想値だという意味ではありません。

その時点で正常と判断したGraphの状態をBeforeとして残したものです。

新規記事追加後にCluster件数が合わない、Featuredが増えた、孤立記事が出た、といった変化を見つける際に比較対象として使える設計でした。

ただし、自動差分比較までは実装していない

元の採掘記録では、基準点からの差分を自動で検出・比較する機構そのものは未実装とされています。

確認できるのは、量産開始前にBaseline Auditを実行し、その時点の数値と監査結果を保存したことです。

「基準点がある」と「差分監査が完全自動化されている」は別です。

既存Knowledgeとの違い

既存Knowledge「出典URLがあることと、内容を事実確認したことを分ける」は、情報源の検証レベルを扱います。

本記事は、その考え方をシステム監査へ広げた実例です。

監査結果だけを残すのではなく、検査対象と非対象を一緒に残し、「どこまで確認した0件なのか」を追える状態にします。

再利用するなら、監査結果を4点セットで残す

AIに長期運用を任せる情報基盤では、監査結果を次の4点で保存できます。

1. Baseline：監査前の件数・状態。
2. Scope：実際に検査した項目。
3. Result：問題数・不一致数などの返却値。
4. Out of Scope：今回の監査では確認していない項目。

「0件」という数字だけではなく、この4点を一緒に残すことで、後から監査結果の強さを誤解しにくくなります。

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

元の監査では、全内部URLのHTTP 200確認、Self Relationの網羅確認、公開ページ上のリンク切れ確認までは実行していません。

また、Baselineとの差分を自動比較する仕組みも未実装です。

確認できるのは、既存60記事のGraph状態を数値化し、監査対象項目では問題0を確認し、その一方で監査対象外の項目も明示していたことです。

このKnowledgeの関連知識

検証状態の段階を分ける： 出典URLがあることと、内容を事実確認したことを分ける

URLの存在と本文確認を分けるのと同じように、監査も「何を実際に検査したか」まで明示します。

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

本記事は、その完成条件に含まれるQuality Gateを、基準点と監査範囲という観点から具体化します。

数値監査に加えて、人間の実使用フィードバックを運用へ戻す： 「PCでも大きい」「治った」「引き継ぎを上手く出来てない」――短いフィードバックを仕様変更へつなげた実例

API監査で問題を探すだけでなく、「大きい」「治った」「引き継ぎできてない」といった短い反応を次の仕様変更へ使った実例です。

現在地： CONTENT & EVIDENCE → Evidence・検証状態

Knowledgeトップを見る