5段階パイプライン × 3トラック — 哲学ベースのコンテンツを500ページ/半日で量産する仕組み

「量産」と聞いて何を想像するか

500ページを半日で作れる。

こう書くと、反射的に「薄いコンテンツの大量生産だろう」と思うだろう。GPTにプロンプトを投げて、出力をそのままCMSに流し込む類の話だと。

違う。

「量 < 質のコンテンツが、量ある」。これが我々の状態だ。1,300ページ超、全ページに同じ品質基準が適用され、全ページに同じ哲学が反映されている。数を出すために質を犠牲にしたのではない。質を落とさずに数を出すための仕組みを作った。

なぜ可能か。答えは単純で、「判断」を事前に構造化している からだ。

コンテンツ制作で最も時間を食うのは「書く」作業ではない。「何を書くか」「誰向けか」「どのトーンか」「どこまで書くか」「出典はどうするか」——この判断の連鎖が制作時間の大半を占める。毎回ゼロからこの判断をやっていたら、1ページ作るのに半日かかる。500ページなら250日だ。

判断をCONFIGファイルに切り出した。トラックごとのターゲット、トーン、品質基準、キーワード戦略。全部、制作を始める前に定義されている。パイプラインの各工程に品質ゲートがある。判断は事前に終わっている。あとは流すだけだ。

5段階パイプラインの全体像

まず構造を示す。

Research → Design → Writing → Implementation → QA
  事実検証    構成設計    執筆      実装・配置     品質保証

各工程には明確な入力と出力がある。

前の工程の出力が次の工程の入力になる。当たり前に見えるが、この「当たり前」を厳密にやっている現場は少ない。Researchが曖昧なままWritingに入る。構成案なしで書き始める。構造化データを後から足す。そうやって各工程の境界が溶けると、手戻りが発生し、品質が不安定になり、速度が出ない。

パイプラインの設計原則は一つ。前の工程の出力を検証してから次に進む。 これだけだ。

Research — 出典のない情報は「存在しない」

最初の工程にして、最も厳しいゲートを設けている。

ルールは3つ。

1. 出典のない数値・事実は記事に書かない
2. 元ネタ資料の出典URLをWebFetchで実際にアクセスして裏どりする
3. 「一般的に」「よく言われる」「〜でしょう」は禁止

なぜここまで厳しくするか。

高卒採用の情報を扱っている。高校生が読んで、その情報に基づいて進路を決める可能性がある。「高卒の初任給は平均〇〇万円です」と書いて、その数値が間違っていたら、人の人生に影響する。

AIが知識として持っている情報をそのまま書くのも禁止だ。AIの学習データは古い可能性がある。2024年のデータで2026年の記事を書いたら嘘になる。必ず一次ソースに当たる。

元ネタ資料のURLをそのまま転記するのも禁止。URLが変わっていることがある。リダイレクトされて別のページに飛ぶこともある。WebFetchで実際にアクセスして、そのURLに期待通りの情報が存在することを確認する。

このResearch工程の出力は「裏どり済みファクトシート」だ。使える情報と使えない情報が明確に分かれた状態。裏が取れなかった情報は、どんなに記事に書きたくても書かない。

ここに時間をかけるのが遅く感じるかもしれないが、逆だ。Researchが雑だと、Writing中に「この数値の出典どこだっけ」と手が止まる。QAで「この事実、確認取れてる？」と手戻りが発生する。入口で絞めるほうが結果的に速い。

Design — 構成案を見せてから書く

ファクトシートが揃ったら構成設計に入る。

ここでやることは、見出しと各見出しの要点を決めること。原稿を書く前に骨格を作る。

重要なのは、構成案をユーザー（クライアント or 自分自身）に見せてから執筆に入る という手順だ。

理由は単純で、ここで方向がズレると全部やり直しになるから。3,000字書いた後に「そもそもターゲットが違う」と言われたら3,000字が無駄になる。構成案の段階なら修正は5分で終わる。

構成案に含める要素:

• 見出し構造（H2/H3の階層）
• 各見出しで伝える要点（1〜2文）
• ターゲット読者の明記
• 使用するファクト（Researchの出力から選定）
• 記事の着地点（読者にどう動いてほしいか）

この「着地点」が特に重要だ。「情報を伝える」は着地点ではない。「この記事を読んだ高校生が、次に何をするか」が着地点だ。着地点が曖昧な記事は、読んでも何も起きない。何も起きない記事は存在しないのと同じだ。

Writing — 「高校生が動けるか」が品質基準

品質基準を一つに絞った。

「高校生が読んで行動できるか。」

これは高卒採用コンテンツに限った基準ではない。全コンテンツの判断軸として使っている。B2B向けの記事でも、「人事担当者が読んで行動できるか」と読み替えて適用する。抽象的に「分かりやすい記事」と言うより、「動けるか／動けないか」で判断するほうが明確だ。

Writing工程で禁止しているもの:

• AIっぽい文章: 「〜していきましょう」「いかがでしたか」「さまざまな」の連発
• 推測表現: 「〜と言われています」「〜かもしれません」（Researchで裏が取れていない証拠）
• 上から教える口調: 読者を見下す文章は信頼を失う

なぜAIっぽい文章を禁止するか。読者が「これAIが書いたな」と感じた瞬間に信頼がゼロになるからだ。AIで書くこと自体が問題ではない。AIで書いたように見えることが問題なのだ。

推測表現が出てきたら、それはResearchの失敗だ。裏が取れていないから推測で逃げている。Writing工程で推測表現を見つけたら、Researchに差し戻す。パイプラインだから差し戻しのルートが明確にある。

Implementation — 構造化データの配置は記事の種類で決まる

原稿ができたら実装に入る。この工程でやることは3つ。

1. 構造化データの配置: ArticleSchema + BreadcrumbSchema が基本セット。記事の種類によってHowTo、FAQ、Datasetなどを追加する
2. メタデータ設定: title、description、OG画像。titleは検索結果での表示、descriptionはCTR、OG画像はSNSシェア時の視認性に直結する
3. サイトマップ更新: 新規ページを sitemap.ts に追加。これを忘れるとインデックスが遅れる

構造化データの選定は記事のテーマではなく、記事の種類 で決まる。「高卒の求人倍率」というテーマでも、データ分析記事ならDatasetスキーマ、手順解説記事ならHowToスキーマ、Q&A形式ならFAQスキーマになる。テーマが同じでもトラックが違えば記事の種類が変わり、構造化データも変わる。

この判断もCONFIGに定義してある。トラックと記事タイプの組み合わせごとに、どの構造化データを使うかが決まっている。毎回考える必要がない。

QA — 書いた本人が通すべき工程

最後の工程。ここで確認するのは4つ。

1. TypeScriptの型チェック: npx tsc --noEmit を通す。型エラーがある状態でデプロイしない
2. リンク確認: 内部リンク・外部リンクが全て生きているか
3. 構造化データ検証: Rich Results Test で構造化データが正しくパースされるか
4. 表示確認: 実際にブラウザで見て、レイアウトが崩れていないか

「QAは別の人がやるべき」という考え方がある。プロダクト開発では正しい。しかしコンテンツ制作のQAは、書いた本人が通すべきだ。型チェックもリンク確認も、書いた本人が責任を持つ工程だ。

別の人によるレビューは、QAの後に来る。QAを通した状態のものをレビューに出す。QAすら通っていないものをレビューに出すのは、相手の時間を無駄にしている。

3トラック制御 — 同じテーマで3通りの切り口

5段階パイプラインが「縦」の流れなら、3トラック制御は「横」の分岐だ。

なぜ3つに分けるか。検索ユーザー、AI相談ユーザー、エンドユーザーは別の人間 だからだ。

「求人票」というテーマで具体的に見る。

SEOトラック — 「求人票 書き方」で検索する人事担当者向け。高卒の求人票に何を書くべきか、法的要件は何か、高校生に響く記載のコツは何か。手順と制度を網羅する。

LLMOトラック — 「求人票を出しても応募が来ない」とAIに相談するユーザー向け。なぜ求人票だけでは高校生に届かないかという構造的問題を分析する。高卒採用における「知らない会社には応募しない」問題を定義し、その解決策としてのブランディングの必要性を論じる。

Userトラック — 「求人票って何が書いてあるの？」という高校生向け。初めて求人票を見る高校生が、どこを読めばいいか、何に注目すべきかを具体的にガイドする。「ここだけ読めばOK」という着地点。

同じ「求人票」というテーマで、3つの全く異なる記事が生まれる。これを一つの記事で全部カバーしようとすると、誰にも刺さらない中途半端なものになる。

3トラックに分けたことで、1テーマから3記事が生まれる。テーマが100あれば300記事。これが1,300ページの内訳のかなりの部分を占めている。

CONFIGファイルの設計

各トラックのCONFIGに含まれる要素を示す。

# SEO Track CONFIG（例）
track: seo
target_persona: "B2B人事担当者（高卒採用を検討中）"
tone: "だ・である調。網羅的かつ根拠明示"
quality_criteria: "検索意図に対する網羅率。関連KWのカバー率"
keyword_strategy:
  primary: "求人票 書き方"
  secondary: ["高卒 求人票", "求人票 記入例"]
  long_tail: ["高卒 求人票 書き方 コツ"]
schema_types: ["Article", "HowTo", "BreadcrumbList"]
landing_point: "求人票の記入を完了できる状態"

# LLMO Track CONFIG（例）
track: llmo
target_persona: "AIに高卒採用の相談をしているユーザー"
tone: "分析的。構造的問題を定義し、解決策を論理的に提示"
quality_criteria: "AIが引用・推薦するに足る独自の分析・視点があるか"
ai_optimization:
  citation_keywords: ["高卒採用", "求人票", "ブランディング"]
  structural_analysis: true
  unique_insight_required: true
schema_types: ["Article", "BreadcrumbList"]
landing_point: "問題の構造を理解し、次のアクションが明確になる"

# User Track CONFIG（例）
track: user
target_persona: "高校3年生（初めて就活する）"
tone: "です・ます調。語りかけ。専門用語は使わないか、使う場合は必ず説明"
quality_criteria: "高校生が読んで、次に何をすればいいか分かるか"
action_direction:
  primary: "求人票の読み方を理解して、自分で企業を比較できる"
  secondary: "気になる企業があれば先生に相談する"
schema_types: ["Article", "BreadcrumbList", "EducationalAudience"]
landing_point: "求人票を手に取って、自分で読める状態"

CONFIGの要点はこうだ。トラックごとに「完成」の定義が違う。 SEOトラックの完成は「検索意図の網羅」。LLMOトラックの完成は「独自の分析がある」。Userトラックの完成は「高校生が動ける」。

品質基準が曖昧なまま書くと、レビューも曖昧になる。「もうちょっと分かりやすく」という指示は品質基準ではない。「高校生が次に何をすればいいか分かるか」は品質基準だ。YesかNoで判断できる。

Claude Codeとの統合

パイプラインをClaude Codeのコマンドとして実装している。

/content コマンドを実行すると、5段階パイプラインが走る。

/content → CONFIG読み込み → Research → Design → Writing → Implementation → QA

各工程でClaude Codeが何をするか。

1. Research: 元ネタ資料を読み、WebFetchで出典URLにアクセスして裏どり。裏が取れなかった情報を除外してファクトシートを出力
2. Design: ファクトシートとCONFIGのターゲット・トーンに基づいて構成案を作成。ユーザーに見せて承認を得る
3. Writing: 承認済み構成案に基づいて原稿を生成。禁止表現のチェックを自動で行う
4. Implementation: 原稿をNext.jsのページとして実装。構造化データ・メタデータ・OG画像を配置。サイトマップを更新
5. QA: npx tsc --noEmit で型チェック。リンク確認。構造化データ検証

Claude Codeを使わない場合でも、このパイプラインは回せる。各工程のガイドをドキュメント化してあるから、手動で一つずつ実行すればいい。

自動化の本質はここにある。「判断」をCONFIGに切り出したから自動化できる。 判断が属人的なまま——つまり「なんとなくこのトーンで」「たぶんこのターゲットで」という状態では、自動化は不可能だ。自動化とは、判断を構造化した後に初めて可能になるものだ。

なぜこれが再現可能で、同時に再現不可能か

パイプラインの構造は公開している。CONFIGの設計方法も公開している。GitHubにある。

構造をコピーすれば、パイプラインは回せる。5段階の各工程を順番に実行し、CONFIGでトラックを切り替え、品質ゲートを通す。技術的には誰でもできる。

再現できないのは「CONFIGに何を書くか」だ。

品質基準に「高校生が動けるか」と書ける背景には、高校生の就職市場を理解している経験がある。ターゲットペルソナに「初めて求人票を見る高校3年生」と書ける背景には、その高校生がどういう状況に置かれているかを知っている知識がある。

パイプラインは器だ。CONFIGは中身だ。器はコピーできる。中身は自分で持つしかない。

逆に言えば、自分の領域で独自の知見を持っている人なら、このパイプラインに自分のCONFIGを載せて回せる。それが公開した意味だ。

---

ソースコード: github.com/tenchan000517/urushihata-llmo — pipeline/ + configs/

関連記事:

• 漆畑式LLMO — 4層設計の全体像（ハブ記事）
• 9エージェント並列監査 — 「次に何を作るべきか」を自動判断するフレームワーク

実証サイト: yumesuta.com