ANSWER
【結論】
可児波起が運営する「海辺の部屋」では、知識記事60本の分類や関連記事の登録データを検査し、調べた項目では問題0という記録を残しました。一方、公開ページの全リンクを開く確認などは対象外でした。監査報告を使うときは、「いつ・何を対象に、どの条件で調べ、何が分かり、何が未確認か」を結果と一緒に残します。これが、この過去のサイト監査と運用報告の比較から整理した方法です。
Explanation
【詳しく解説】
記事を増やす前に、分類や関連記事のつながりを確かめた
「海辺の部屋」では、経験から得た知識をKnowledgeという記事群にまとめ、テーマ別の一覧や関連記事でつないでいます。記事が増えると、どこにも分類されていない記事や、関連記事への案内がない記事が生じていないかを確かめる必要があります。
そこで、Knowledgeが60本だった時点で、CMS（記事や分類を保存する管理システム）のデータをAPI経由で検査した記録を残しました。APIは、プログラムから保存データを読み出すための窓口です。目的は、記事を増やした後に比較できる、変更前の状態を残すことでした。
この記事・分類・関連のつながりを、ここではKnowledge Graphと呼びます。難しいのは名称ではなく、「そのつながりを何で確認したのか」という点です。
登録データの検査で「問題0」でも、公開ページの確認は残る
当時の検査では、記事にタイトル・本文・根拠などが入っているか、各記事の主な所属先が一つか、関連付けの登録があるか、分類ごとの件数と集計が合うかを調べました。結果は、検査した項目について問題0でした。
たとえば、関連記事のつながりでは、入ってくる関連付けが0件の記事は0本、出ていく関連付けが0件の記事も0本と集計されました。これは、関連付けそのものが0件だったという意味ではありません。各記事に入る関連・各記事から出る関連の登録がある、という検査結果です。
ただし、CMSに関連記事の登録があることと、読者が公開ページのリンクを押して正常に移動できることは、確認する対象が違います。当時の検査は、全内部URLへのアクセス、公開ページの全リンク切れ、自分自身への関連付けの網羅確認までは含んでいませんでした。
この報告を受け取った人が、次に全リンクの動作確認を行うか判断するには、「問題0」だけでは足りません。どの検査で得た0なのかが必要になります。
自分の仕事では、報告をこの形で残す
この記録から、監査や一括作業の報告には、次の内容をまとめて残す方法を提案します。
- 対象と時点：いつの、どの記事やデータを調べたか。全件か一部か、公開・未公開の内訳も書く
- 比較の基準と検査条件：変更前の件数や状態、調べた保存場所、項目、検索語や判定方法を示す
- 結果：何を何件確認し、どこに不一致があったか。本文と表の数字も照合する
- 未確認と次の作業：未検査の対象や保留を残し、次工程の予定を完了件数に含めない
たとえば今回の60記事の記録を短く報告するなら、「保存データ上の分類・関連・件数を検査した範囲では問題0。公開ページの全リンクの動作確認は未実施」となります。これは報告形式の例として要約したもので、当時の原文引用ではありません。
報告を受けて原稿の修正へ進むときは、レビューの指摘が次の原稿に入ったかを照合する方法が次の確認になります。
変更前の基準と、未確認も一緒に残す
比較の出発点となる記録を、基準点（Baseline）と呼びます。この事例では、60本の記事と分類・関連・一覧の件数を残しました。細かな構成件数は根拠欄にまとめています。現在の件数を示すものではありません。
後から何が増え、何が消えたかを比べるには、数値とともに、その時点で行った検査と未検査の項目も必要です。当時は、基準点との差を自動で検出する仕組みまでは実装していませんでした。
ほかの場面へ応用する：数字の範囲を確かめる
ここからは、60本のKnowledge監査とは別に、同じサイトの固定ページやブログを整備した際の、ChatGPTの報告文を読み比べた例です。対象や作業は違いますが、結果の数字を読むには確認範囲が必要、という点でつながります。
1．本文と表が食い違うなら、元データへ戻る
見出しの監査報告には「固定9ページ中8ページに問題」とありました。一方、直後の9行の表では2ページが「問題なし」で、表から数えると問題ありは7ページです。ここで分かるのは報告内の不一致です。実際に7ページか8ページかは、元のスキャン結果へ戻って確かめる必要があります。
2．228本と229本は、数えた対象が違えば両立する
ブログの著者情報を整えた報告には、公開済み228本、未公開1本、合計229本という内訳がありました。公開記事だけの数と、未公開を含む全記事数を比べていたのです。数える対象の全体を母数と呼びます。数字をそろえる前に、この母数をそろえて比較します。
3．「古い紹介0本」には、何を探したかが必要
229記事を再照合して、特定の旧プロフィール表現が残る記事は0本とする報告がありました。後の代表6記事の比較では、共通著者欄とは別の古い紹介が残るという報告もありました。検索した場所・語句・判定条件・時点が同じか不明なので、同じ検査の矛盾とは確定できません。「どこから何を探して0本だったか」を確認する場面です。
4．45本の完了報告に、次に行う90本を足さない
ブログ改稿の報告では、優先的に全面改稿するグループ（Tier A）45本の完了と、次のグループ（Tier B）90本の改善予告が並んでいました。報告上の完了は前者です。完了した工程と、これから行う工程を分けて記録します。
この記録の確認範囲
60記事の数値は過去の監査記録を示しています。四つの運用例で今回確認したのは、保存されたAIの報告文の内容と、その間の整合です。元のスキャン結果、過去の更新操作、全記事の現在の状態を再検証したものではありません。現在のサイト全体の正常性や、検索・AI引用への効果を示す記事ではありません。
日付と、今回確認した範囲
過去の60記事監査の正確な実施日は、今回の資料だけでは確定していません。ページ上部の「確認日」は従来の記事に登録されていた日付の表示で、この記事全体を再検証した日とは扱いません。追加した四つの運用例は、2026年9月30日〜10月1日（UTC）に保存した原文を、10月1日に読み比べた結果です。「更新日」は本文の更新を示し、過去の監査を再実行した日ではありません。
このKnowledgeの関連知識
検証状態の段階を分ける： 出典URLがあることと、内容を事実確認したことを分ける
URLの存在と本文確認を分けるのと同じように、監査も「何を実際に検査したか」まで明示します。
公開前の検査を、記事の完成条件の中で見る： 「文章を書いた」でKnowledgeを完成扱いしない――CMS登録＋Graph統合までを1本の完了条件にした
記事を保存し、分類や関連記事へ組み込んだ後に、どこまで確認すれば完成と呼べるかを整理します。
数値監査に加えて、人間の実使用フィードバックを運用へ戻す： 「PCでも大きい」「治った」「引き継ぎを上手く出来てない」――短いフィードバックを仕様変更へつなげた実例
API監査で問題を探すだけでなく、「大きい」「治った」「引き継ぎできてない」といった短い反応を次の仕様変更へ使った実例です。
現在地： CONTENT & EVIDENCE → Evidence・検証状態
EVIDENCE
【根拠・検証】
過去の監査記録にある数値と検査項目
「海辺の部屋」のKnowledgeが60本だった時点の保存記録です。比較の基準点は、記事60本、大分類（Pillar）4件、テーマ分類（Cluster）17件、有効な関連記事の関係83件、分類への所属72件、一覧ページ21件、おすすめ記事6本でした。これらは過去値であり、2026年10月1日の現行件数ではありません。
検査で数えた問題は0件（problemsCount＝0）。入ってくる関連がない記事は0本（noIncoming＝0）、出ていく関連がない記事も0本（noOutgoing＝0）でした。双方向の関係は両方向に計上する検査です。関連付けそのものが0件だったという意味ではありません。
分類ごとの件数の不一致は0件（clusterCountMismatches＝0）。全体集計にも不一致はなく（statsMismatch＝false）、本文の欠落が検出された一覧ページは0件（indexBodyMissing＝0）でした。
記事では、タイトル、URL用の名前、冒頭の答え、本文、根拠、記事上部の位置案内、著者下の案内、メイン画像、著者の各項目が入力されているかを調べました。各記事の主な所属先が1件か、分類件数・全体集計の整合、一覧本文の有無、画面幅に応じた文字サイズの指定があるかも検査対象でした。項目の存在確認は、分類の意味の正しさや公開画面の実表示まで保証するものではありません。
四つの運用例の出所と、日付の扱い
人物ページ制作とブログ整備に関する非公開会話から、2026年9月30日〜10月1日（UTC）に保存した原文を、10月1日に読み比べました。見出し監査の本文と9行表、公開・未公開の内訳、旧紹介の残存に関する前後の報告、改稿の完了と次工程予告が対象です。本文と表の不一致、件数の内訳、報告の順序は原文比較による確認です。報告形式と四つの読み分け方は、これらの記録から整理した提案です。
過去の60記事監査の正確な実施日は、今回の資料では確定していません。ページ上部の「確認日」は従来の記事の登録値を維持しており、今回の原文比較日や、記事全体の再検証日を表すものではありません。原文の保存日、原文を比較した日、本文の更新日、過去の監査実施日は別に扱います。
SOURCES
【情報源】
出典：二種類の非公開作業記録
- Knowledgeの分類・関連構造を検査した基準点監査記録。既存記事に保存された過去の数値と検査範囲を使用しました。正確な監査実施日時は今回確認できていません。
- 固定ページ・人物ページ・ブログを整備したChatGPTとの会話の保存原文。四つの運用報告の比較に使用しました。原文保存日は、各作業の実施日ではありません。
いずれも非公開資料のため、原会話の公開リンクは掲載していません。
Author
【著者】
可児波起
マーケティングデザイナー / DXコンサルタント / 音楽家
次に読む
検証状態の段階を分ける
情報源の確認レベルと同じように、監査も何を実際に確認したかを段階として残します。
公開前の検査を、記事の完成条件の中で見る
「文章を書いた」でKnowledgeを完成扱いしない――CMS登録＋Graph統合までを1本の完了条件にした
分類や関連記事への組み込みを含め、記事の公開前に確認する範囲を整理します。
数値監査に加えて、人間の実使用フィードバックを運用へ戻す
「PCでも大きい」「治った」「引き継ぎを上手く出来てない」――短いフィードバックを仕様変更へつなげた実例
短い反応を一回の会話で終わらせず、次回以降の運用仕様へ反映した実例です。
このテーマをもっと見る
事実、仮説、出典、結果、解釈、確認範囲を分離して検証状態を残すTopic Clusterです。