⚙️

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

に公開
AI
SEO
automation
LLMO
contentmanagement
tech

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

500ページを半日で制作できます。

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

実はそうではありません。

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

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

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

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

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

まず構造をお見せします。

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

各工程には明確な入力と出力があります。

工程 入力 出力
Research 元ネタ資料・テーマ 裏どり済みファクトシート
Design ファクトシート 構成案（見出し＋要点＋ターゲット）
Writing 構成案 原稿（品質基準クリア済み）
Implementation 原稿 ページ（構造化データ＋メタデータ＋OG画像）
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トラック制御は「横」の分岐です。

トラック ターゲット 最適化対象 トーン
SEO Track 検索ユーザー（B2B人事等） Google検索順位 だ・である / 網羅的
LLMO Track AIに相談するユーザー AI引用・推薦 分析的 / 構造的
User Track エンドユーザー（高校生等） 行動可能性 です・ます / 語りかけ

なぜ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/

関連記事:

実証サイト: yumesuta.com

GitHubで編集を提案

Discussion