複数サイト運営の知見を、再利用可能なデータへ変える

複数サイトを運営すると、知見は増えます。しかし「前にも似た診断を作った」「どこかでupload同期に失敗した」という記憶のままでは、次の制作で検索できず、比較できず、検証にも使えません。

解決策は、すべてを共通コンポーネントにすることではありません。サイトごとの違いを残したまま、判断の単位だけを共通データにすることです。

先に結論：経験を検索できる判断データへ分ける

記憶やチャットをそのまま保存するのではなく、目的、対象、問題、導線、技術、失敗、学びを分離します。Project Atlasが参照するのは、作品を褒める文章ではなく、次の企画で比較・検証できる判断材料です。

記憶とチャットだけでは再利用しにくい

会話ログは背景を豊かに残せますが、後から「診断型で、FTP配信で、結果ページを持つProject」を一覧するには向きません。READMEも一つのリポジトリを理解するには役立ちますが、複数Projectを横断して比べる構造ではありません。

再利用したい情報を、まず六つに分けます。

1. 何のために作ったか。
2. 誰が使うか。
3. どの問題を解くか。
4. どの導線と操作を使ったか。
5. どの技術と配信制約があったか。
6. 何を学び、何に失敗したか。

Project dataへ移すときも、チャット全文を公開データへ貼り付けません。個人情報、APIキー、Cookie、ローカルパス、非公開URL、未確認の数値は入れず、公開できる要約と確認日だけを残します。

完成画面のスクリーンショットだけでは、6番が残りません。次の制作へ効くのは、採用理由と不採用理由です。

Projectデータの最小形

BUILD ORBITでは、Projectを次のような型で持ちます。

interface Project {
  slug: string;
  title: string;
  summary: string;
  url?: string;
  kind: ProjectKind[];
  status: "active" | "maintenance" | "draft" | "archived";
  audience: string[];
  problems: string[];
  interactionPatterns: string[];
  contentPatterns: string[];
  technologies: string[];
  lessons: string[];
  relatedProjectSlugs: string[];
  lastReviewed: string;
}

数値実績を必須にしていません。PVや収益が公開できないProjectでも、設計パターンと学びは比較できるためです。確認できないURLは推測で埋めず、status: draftにします。

lastReviewedは、Projectが更新された日ではなく、Atlasへ載せた情報を最後に確認した日です。外部URLや現状が変わる可能性を明示できます。

kind、status、interactionPatterns、contentPatternsのような統制語彙は、表記ゆれを減らし、ProjectsやPatternsのfilterとreverse indexを同じ値で動かすために使います。新しい言葉を追加するときは、既存語彙で表せない差分か、単なる言い換えかを先に確認します。

失敗を別欄に追いやらない

成功例だけをデータ化すると、同じ失敗を繰り返します。失敗は反省文ではなく、条件と症状と回避策に分けます。

条件: distを手動でuploadへコピーする運用
症状: 古いhash assetとsitemapが残った
原因: 削除と一致確認が手順に含まれていなかった
回避: prepare:uploadとdelivery hash checkを一つのverifyへ含める

この形なら、次のFTP型Projectで品質ゲートへ変換できます。単なる「気をつける」ではなく、再発条件を自動で止められます。

検証では、関連slugの存在、自分自身を参照していないこと、statusと公開URLの整合、語彙の許可値、dist/とupload/のhash一致をtestします。文字列が書けたことではなく、データが既存の表示・filter・内部リンクへ安全につながることを確認します。

共通コンポーネント化との違い

共通コンポーネントは、同じ組織、同じブランド、同じ更新周期で効果を発揮します。異なるサイトへ無理に同じカードやHeaderを配ると、世界観と情報密度まで均一になります。

共通化する対象を三層に分けます。

コードを共有しなくても、判断と検証は共有できます。この方が、サイトごとの声を守りながら制作速度を上げやすくなります。

Atlasへ接続すると見えるもの

ProjectデータをAtlasで並べると、個別READMEでは見えなかった偏りが見えます。

• 診断型が増えているのに、結果後の導線が共通化されていない。
• 安全系コンテンツでは、強い断定より段階別行動が有効だった。
• 計算ツールでは、結果と前提条件を同じ視界に置く必要がある。
• 記事サイトでは、検索語より困っている状態から入口を作ると回遊しやすい。

これらは架空の成果数値ではなく、実装と運用から得た設計上の経験則です。外部事実と混ぜず、「このProject群での学び」として扱います。

Projectデータをページ改善へ戻す

データを集計して終えると、数字が新しい飾りになります。改善へ戻すときは、1つの傾向を1つのページ責務と1つの検証へ結び付けます。現在の30件では、静的配信・生成・HTMLのいずれかを持つProjectが29件、公開リポジトリが23件、関連Projectの辺が35本あります。これは市場の割合ではなく、今回照合したデータのスナップショットです。

この対応表は「静的だから優れている」「関連が多いほど回遊する」といった結論を証明しません。観測値から次に読む場所を選び、実装・本文・検証の三つが同じ判断を指しているかを確認するための地図です。

次の企画へ使う手順

新しいサイトを始めるとき、ゼロからアイデアを出す前にAtlasを次の順で見ます。

1. 対象ユーザーとproblemが近いProjectを探す。
2. interaction patternが目的に合うか比べる。
3. 同じ配信環境で起きた失敗を確認する。
4. 再利用できる品質ゲートを選ぶ。
5. 今回は何が違うかを一文にする。

似たProjectがあればコピーするのではなく、既存の強い入口を更新するか、役割の違う親ハブを作るか、新規を見送るか判断します。薄い重複ページを増やさないためです。

更新時のチェックリスト

• URLとstatusは現在確認できるか。
• summaryは宣伝文ではなく役割を説明しているか。
• audienceとproblemが混ざっていないか。
• interactionとcontentのpatternを分けたか。
• lessonは抽象的な感想で終わっていないか。
• 関連slugが実在し、自分自身を参照していないか。
• 公開できない数値や個人情報を入れていないか。
• 失敗を次の品質ゲートへ変換できたか。

更新日と確認日の違い

ProjectのlastReviewedは、公開URLやAtlas表示を最後に確認した日です。サイトの本文や実装を更新した日とは限りません。NoteのupdatedAt、ProjectのlastReviewed、外部sourceのaccessedAtを一つの日付にまとめると、何が変わったのか分からなくなるため、役割を分けて保持します。

Atlasへ戻って整合性を見る

実際の関係はProject Atlasで、全件のstatus・確認日はAll Projectsで確認できます。判断の型はPatterns、診断・ガイド・静的配信の役割分担はLocal AI Compass Case Studyへ接続しています。

よくある質問

知見をデータに変える目的は、過去を美しく整理することではありません。次の企画で、同じ調査と同じ失敗を繰り返さず、それでも前のサイトとは違う体験を作ることです。Project Atlasは作品棚ではなく、その判断を始める索引です。