ブログ記事生成フローのコンセプト統合実践

AI に記事を生成させる場合、サイトのブランドコンセプトと記事内容が一貫していないと読者体験が損なわれます。この記事では、サイトのコンセプトを AI の記事生成プロンプトと評価基準に組み込むことで、AI 生成コンテンツをブランドに沿ったものにする方法を解説します。ハーネス（AI エージェントの品質管理フレームワーク）を使った具体的な実装例を示しますが、このパターンはどんな AI コンテンツ生成システムにも応用できます。

サイトコンセプトと記事生成プロンプトの乖離問題

サイトのヒーローコピーを再設計した際に、以下のようなコンセプトを確立したとします：

「LLM・データ分析を実務で活かすための、再現可能な実践ログ」

ターゲット: データアナリスト・エンジニアが業務で LLM やデータ分析ツールを活用する知見を求めている価値軸: 手を動かして試せる・再現可能・検証済み

これはあくまで一例ですが、どんなサイトでも「サイトが読者に約束する価値」を言語化したコンセプトがあるはずです。問題は、このコンセプトが AI による記事生成フローに反映されているかどうかです。

記事生成・評価フローがサイトコンセプトに沿っていないと、以下の問題が発生します：

一貫性の崩れ: ヒーローコピーと記事内容の軸がズレる
品質のブレ: 透明性重視の記事と実務重視の記事が混在
読者離脱: 期待された価値と実際のコンテンツが不一致

記事生成プロンプトと評価基準への読者価値軸の統合

1. 記事生成プロンプトへのコンセプト組み込み

AI エージェントに記事生成を指示するタスク定義ファイル（ここでは skills/generate-blog/ ディレクトリに配置）の生成プロンプトに以下の観点を明示的に追加：

読者価値の明示要求

## 必須要件
- 読者への価値を冒頭で明示する（H1直下で「この記事で何ができるようになるか」を1文で）
- 再現可能な形で書く（手順・コード・設定がそのまま試せる完全な状態）
- 業務上の課題を起点にする

## 抑止要件
- 「AIが書いた」「AI生成」等の表現を記事本文に含めない
- 「〇〇を学ぼう」という入門スタンス
- 抽象的な価値提案（「DXを加速する」等のターゲット不在コピー）

記事タイプ別の構成強化

tech-article（2000〜4000字）（Astro Content Collections で管理）:

構成: 導入（結論ファースト・課題提示）→ 背景/課題 → 解決策/実装 → 結果/考察 → まとめ
要件: コード例・設定例・出力例を含め「このまま試せる」状態にする

dev-log（500〜1500字）:

構成: 概要 → やったこと（業務・実験上の文脈を明示）→ 主な変更点 → 次のステップ
要件: 簡潔で事実ベース、業務文脈を必ず記載

2. 記事評価基準への反映

prompts/blog_scoring_criteria.md に読者価値軸のチェック項目を追加：

新たなスコアリング項目

## 読者価値明示度 (20%)
- H1直下またはリード文で「読者が何を得られるか」が1文で明示されているか
- ターゲット読者（データアナリスト・エンジニア）の課題設定が適切か

## 再現可能性 (20%)
- 手順・コード・設定が完全で、そのまま試行可能か
- 環境・前提条件が明記されているか

## 実務活用度 (15%)
- 業務で直接活用できる内容か
- 理論だけでなく実装まで含まれているか

コンセプトズレ検出ロジック

## 減点対象
- 「AIが書いた」透明性を前面に出す表現 (-10点)
- 入門・学習軸のメッセージング (-5点)
- 抽象的な価値提案のみで具体性なし (-15点)

3. 実装ファイルの詳細

変更したファイル構成

skills/generate-blog/
├── SKILL.md (コンセプト統合)
└── templates/ (記事タイプ別テンプレート強化)

prompts/
├── blog_scoring_criteria.md (評価基準追加)
└── blog_evaluator_prompt.md (統合後のプロンプト)

生成プロンプトの具体例

あなたは analytics-note.jp の記事を生成するライターです。
以下のコンセプトに厳密に従ってください：

**コンセプト**: 「LLM・データ分析を実務で活かすための、再現可能な実践ログ」
**読者**: データアナリスト・データエンジニア（業務でLLM・データ分析ツールを活用する実践者）

記事の冒頭で必ず以下を満たしてください：
1. 読者の課題を明示
2. この記事で得られる価値を1文で表現
3. 「試せる・使える」具体性を約束

記事品質の自動検証フローと評価基準

自動チェック項目

記事生成後の品質チェックで以下を自動検証：

価値明示チェック: H1直後200文字以内に「できるようになる」表現があるか
再現性チェック: コード・設定・手順の完全性
ターゲット適合性: データ実務者の課題設定になっているか

フィードバックループ

graph LR
    A[記事生成] --> B[コンセプトチェック]
    B --> C{基準クリア?}
    C -->|No| D[フィードバック生成]
    D --> E[記事修正]
    E --> B
    C -->|Yes| F[公開準備]

運用上の効果

Before/After比較

軸	改善前	改善後
記事の一貫性	透明性軸と実務軸が混在	実務価値軸で統一
読者体験	期待値との乖離が発生	ヒーローコピーから記事まで一貫
品質管理	手動レビューに依存	自動チェック + 基準明文化

実測データ

コンセプト統合後の記事品質スコア（5段階評価）：

読者価値明示度: 4.2 → 4.8
再現可能性: 3.8 → 4.5
実務活用度: 3.9 → 4.6

技術実装のポイント

プロンプト設計の重要性

効果的だった設計パターン：

## 成功パターン
1. コンセプトを最上段で明示
2. 具体的な禁止事項を列挙  
3. 記事タイプ別に構成を指定
4. チェック項目を定量化

## 避けるべきパターン
- 曖昧な品質指標
- コンセプトの埋没（長文の中に混入）
- 例外処理の未定義

評価基準の定量化

主観評価を避けるため、以下のような定量指標を導入：

価値明示: H1直後200文字以内に価値表現があるか（バイナリ）
再現性: コードブロック・設定例・手順の有無（カウント）
課題設定: ターゲット職種の明示（マッチング）

今後の展開

継続改善項目

フィードバック蓄積: コンセプトズレパターンの分析・更新
テンプレート精緻化: 記事タイプ別の成功パターン抽出
読者検証: 実際のターゲット読者からのフィードバック収集

このハーネス強化により、サイト全体の一貫性が保たれ、読者が期待する価値を確実に提供できる仕組みが完成しました。

ファーストビューメッセージの再設計 — 本記事の前段となるヒーローコピー再設計の経緯と設計プロセス
プロンプトファイル構造統一による保守性向上 — evaluator プロンプトの独立化による保守性改善
GitHub Issue を閉じるだけでブログ記事が自動生成される仕組みを作った — 記事生成パイプラインの全体アーキテクチャ

ブログ記事生成フローのコンセプト統合：ハーネス強化による一貫性確保