PROJECTからCATEGORY記事を増やす。1つの実験を複数の知識に変える方法

2026年10月7日

GROW

一つのPROJECTを作り終えると、時系列の記事が残ります。しかし、その中で見つけた設定方法や不具合の原因は、PROJECTを最初から読まない人にも役立つ知識です。

MANIARUでは、PROJECT 002で社内向けWordPressを作った記録から、ユーザー権限、検索、業務フロー、バックアップ、コード上の問題などをCATEGORY記事へ分けました。実験の流れを残す記事と、特定の疑問から読める記事を両方作るためです。

この記事では、一つの実験を複数の記事へ機械的に分割するのではなく、再利用できる知識を見つけてCATEGORY記事へ変える方法を整理します。

PROJECT記事とCATEGORY記事は役割が違う

PROJECT記事は、目的を決めてから完成まで進んだ順番を残します。何を作り、どこで判断し、次に何をしたかをたどれる記録です。

CATEGORY記事は、一つのテーマだけを入口にします。「WordPressでバックスラッシュが消える」「複数人の権限をどう分ける」といった疑問から読んでも、必要な内容が分かる形にします。

記事	中心にするもの	読み方
PROJECT	実験全体の流れと判断	STEPを順番にたどる
CATEGORY	一つの問題・方法・学び	知りたいテーマから読む

同じ出来事を扱っても、記事の入口が違います。PROJECT本文を短く言い換えるだけでは、CATEGORY記事を作った意味がありません。

PROJECT 002の公開後、各STEPと制作中の記録から、独立して説明できそうな出来事を拾いました。

この段階ではタイトルを量産しません。まず「何が起きたか」「なぜ困ったか」「どう確認したか」を短く並べました。出来事が具体的であれば、記事の中心も決めやすくなります。

候補を出したあと、その内容だけを知りたい読者がいるかを確認しました。

読者の疑問を一文で表せない候補は、範囲が広すぎる可能性があります。反対に、数行で終わる内容は別記事の一部として扱います。

候補が決まったら、タイトル、slug、記事一覧、既存本文を確認しました。同じ言葉を使っていなくても、結論が同じなら新しい記事にはしません。

PROJECTとCATEGORYの両方に同じ事実が出る場合も、PROJECTでは時系列上の意味、CATEGORYでは仕組みや再現条件を中心にします。互いの記事は、続きではなく別の入口として内部リンクでつなぎました。

PROJECT 002から生まれた記事を、すべてBUILDへ入れたわけではありません。記事が答える内容に合わせて分類しました。

元になったPROJECTではなく、CATEGORY記事そのものの主題で決めます。これにより、PROJECTを知らない読者も普段使うカテゴリーから記事を見つけられます。

候補が多いときは、思いついた順に公開しませんでした。公開済み記事の数と内容を確認し、入口が少ないカテゴリー、既存記事から自然につながるテーマ、具体的な実体験がそろっているテーマを優先しました。

今回は17本だったCATEGORY記事へ13本を追加し、合計30本にしました。まとめて下書きを作って一括公開するのではなく、各記事で本文、アイキャッチ、設定、公開ページを確認してから次へ進めています。

PROJECTには、完成した機能だけでなく、判断、失敗、修正、確認が残ります。そのままでは長い流れの中に埋もれる内容も、一つの疑問へ絞ると別の制作で使える知識になります。

PROJECTで実験の流れを残し、CATEGORYで問題ごとの知識を取り出し、互いをリンクでつなぐ。

この形にしたことで、一つの制作記録を繰り返すのではなく、時系列で読みたい人と、答えから探したい人の両方に入口を作れました。PROJECTとCATEGORYをつなぐ基本設計は、PROJECTとCATEGORYをつなぐ知識システムでまとめています。