AI向けProject Sourcesは増やすだけでは整理できない――正本・旧版・補助資料を分けた実例

Project Sourcesを確認すると、似た名前の資料が複数あった

Knowledge制作ルールをProject Sourceへ移した後、参照資料そのものを整理する作業が行われました。

その時点の記録では、少なくとも次のファイルが確認されています。

• knowledge記事量産.txt：165行版
• knowledge記事量産.txt：274行版
• Knowledge記事再開…txt：339行
• Knowledge記事量産3.txt：43行版
• Knowledge記事量産3.txt：1194行版

同じ名前、似た名前、役割が分かりにくい名前が混在していました。

1194行のKnowledge憲法も、ファイル名だけでは役割が分かりにくかった

1194行版の中身は「海辺の部屋｜Knowledge憲法 Version 1.0」でした。

しかし、当時のファイル名は「Knowledge記事量産3.txt」です。

これだけでは、最上位ルールなのか、量産作業の履歴なのか、旧版なのかを名前から判別しづらいため、役割が分かる名前への変更が提案されました。

ただし、実際に改名されたかは元の記録では確認できません。

旧Heroルールが最新ルールと同時に残っていた

165行版と274行版の「knowledge記事量産.txt」は、旧Hero Visual Style Guideや旧ワンパターン防止ルールとして確認されました。

その一方で、339行のHero画像詳細ガイドには、白ベース、広い余白、16:9、写真風禁止、静かな上質感、同じ構図の反復禁止、記事固有の視覚テーマ、直近画像との比較など、より新しい詳細ルールがまとまっていました。

古いHeroルールと新しいHeroガイドが同時に検索対象になり得るため、旧2本はノイズ候補として削除推奨になりました。

資料を「正本」「補助」「旧版候補」に分けた

整理案では、すべてのSourceを同じ重みで残すのではなく、役割を分けました。

• 正本：Knowledge憲法
• 補助：Hero画像詳細ガイド
• 補助：Admission Gate
• 用途別補助：Blog可読性・余白ルール
• 旧版候補：古いHero関連Source 2本

正本は全体ルール、補助資料は特定工程の詳細、Blog専用ルールは用途限定という構造です。

「削除推奨」と「削除済み」は分けた

ここで重要なのは、旧Sourceについて「削除を推奨した」ことと、「実際に削除された」ことを混同しない点です。

元の記録では、可児 波起が不要なSourceについて「消去するよ」と述べていますが、削除処理の完了確認までは残っていません。

したがって本記事では、旧版2本を削除済みとは扱わず、「削除候補として整理方針を決めた」と記録します。

Sourceを増やすほど強くなるとは限らない

Project Sourcesは、長期プロジェクトのルールや一次資料を会話の外へ残せる仕組みとして使われました。

しかし今回の作業では、古いルールと新しいルールが同時に残ると、検索時に複数の候補が現れ、どれを正本として扱うかを別途判断する必要がありました。

この事例から「Sourceは少ないほどよい」とは言えません。確認できるのは、数を増やすだけでは版と役割の区別が自動的には生まれなかったことです。

タスクを止めたら、正本の「続ける指示」も見直す

正本と決めた文書でも、運用の変更によって一部が古くなることがあります。Knowledge基盤を点検した後の会話には、AIが定期監査タスクを作り、その運用を正本へ追記したという報告がありました。

続いて著者は「タスク、いらない。停止して」と指示し、AIは無効化したと回答しました。しかし後の監査報告には、正本の文書に定期自動監査を前提とする記述が残っている、とあります。

次の担当者がその文書だけを読むと、すでに停止を求められた運用を、今も必要な作業だと受け取る可能性があります。これは同名ファイルの新旧だけでなく、一つの正本文書の中でも、現在の方針と過去の手順を分ける必要がある例です。

方針変更を引き継ぐときは、次の順に点検できます。

• 最新の指示を確かめ、いま実行することと、実行しないことを明記する。
• 現行手順から、廃止した運用を続ける前提を外す。この場面なら「現在は定期自動監査を行わない」と分かるようにする。
• タスクを作った経緯を残す場合は、過去の履歴として分け、再開を指示する文章にしない。
• 修正後は、タスクの設定状態と文書の該当箇所を別々に読み直す。一方の変更報告だけで、両方が直ったと扱わない。

これは原文から整理した確認方法です。今回、直接確認したのは著者の停止指示と、その前後のAI報告でした。当時のタスク設定や正本文書の各版は取得していないため、停止処理や文書修正の成功は独立に検証していません。また、誤ってタスクが再作成されたという記録もありません。

既存Knowledgeとの違い

既存Knowledge「人物像ファイルを複数プロジェクトで共有するとき、同じファイル名を『同じ版』とみなさない」は、同名ファイルについてVERSION・SCOPE・UPDATED・VERIFIEDを持たせる考え方を扱っています。

本記事では、対象を一つの人物像ファイルではなく、Project Sourcesという資料群全体へ広げます。

どれを正本にし、どれを特定工程の補助資料にし、どれを旧版候補として退役させるかという、参照基盤の整理が問いです。

再利用するなら、Source追加時に4つを決める

AI向けの長期資料を増やすとき、この事例から再利用できる確認項目は次の4つです。

1. ROLE：このSourceは正本・補助・履歴のどれか。
2. SCOPE：Knowledge全体、Heroだけ、Blogだけなど適用範囲はどこか。
3. VERSION：同名・類似Sourceのどれが最新か。
4. RETIRE：内容が吸収された旧版を残すのか、参照対象から外すのか。運用をやめた場合は、その実行前提が現行文書に残っていないか。

この4項目は今回の整理を一般化した運用案であり、元のProject Source機能が公式に要求するメタデータではありません。

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

提案されたSource名への改名と、旧Hero関連Source 2本の削除が実際に実行されたかは確認できません。

また、削除後にAIの検索精度やHero品質が改善したかを比較測定した記録もありません。

確認できるのは、同名・旧版系Sourceが複数存在したこと、それらを全文確認した上で、Knowledge憲法を正本、Hero詳細ガイド・Admission Gate・Blog専用ルールを補助資料として整理し、旧Heroルール2本を削除候補としたことです。

このKnowledgeの関連知識

同名ファイルを同じ版とみなさない： 人物像ファイルを複数プロジェクトで共有するとき、同じファイル名を「同じ版」とみなさない

ファイル名だけでは版を判定できない問題を、Project Sources全体の正本・旧版整理へ広げます。

Sourcesの役割そのものを見る： Blog・Knowledge・Experiments・Sourcesを分ける理由

Sourcesを裏づけ・参照基盤として独立させる設計と、その内部で旧版や補助資料をどう整理するかを接続します。

現在地： AI WORKFLOW → 長時間作業・状態引き継ぎ

Knowledgeトップを見る