ブログ記事計画レビュー結果

総合評価: 条件付き承認（B評価）

計画は全体として高い品質を持ち、builderが記事を執筆するための十分な指針を提供しています。しかし、いくつかの構造的な問題と、ターゲット読者の dislikes に抵触するリスクがあるため、以下の指摘事項への対応を推奨します。

1. ターゲット読者の dislikes との整合性に関する懸念

1-1. 「コード例がなく文章だけで技術を説明する記事」に該当するリスク（重要度: 高）

ターゲット読者「Webサイト製作を学びたいエンジニア」は、「コード例がなく文章だけで技術を説明する記事」を明確に嫌います。しかし、現在の計画にはコード例やコピペ可能なテンプレートに関する指示がほとんどありません。

記事のテーマは「コンテンツ品質監査の方法論」であり、純粋なプログラミング記事ではないため、コード例そのものは不自然かもしれません。しかし、チェックリストや表をコピペ可能な形にするだけでは「コード例」の代替にはなりません。エンジニアにとっては、たとえば以下のような「実際に手を動かせる具体物」が欲しいはずです。

robots.txt や sitemap.xml の設定例
Google Search Console での確認手順のスクリーンショット的な記述
監査結果を記録するためのスプレッドシートテンプレートや YAML/JSON でのチェックリスト構造

計画の完成基準には「具体的なチェックリスト/表/フレームワークが少なくとも2つ」とありますが、エンジニア向けの「手元ですぐ試せる」要素について、もう一段踏み込んだ指示があるとよいです。

1-2. 「一般論や抽象的な話が多い情報」に抵触するリスク（重要度: 中）

構成案のH2セクション数は7つあり、特に「AdSense却下が意味すること」「AI運営サイトが直面するE-E-A-Tの課題と対策」「監査結果から改善計画を立てる」「まとめ」は、具体的なフレームワークや手法を示すセクションではなく、解説・考察中心のセクションです。

これらのセクションが抽象論に陥らないよう、計画の段階でもう少し具体的な「このセクションで読者が持ち帰れるもの」を明示すべきです。特に「監査結果から改善計画を立てる」セクションでは、「影響度 x 改善コスト」マトリクスの具体的なテンプレートを読者が自分のサイトで使える形で提供するなどの指示が有効です。

2. 構成の論理性に関する指摘

2-1. 「競合分析で差別化ポイントを見つける」の配置（重要度: 中）

現在の構成では、4軸フレームワーク → 根本原因分析 → 競合分析 → E-E-A-T → 出典検証 → 改善計画の順番になっています。

しかし、「競合分析で差別化ポイントを見つける」は、4軸フレームワークの「軸1: 独自性」を深掘りする内容です。4軸フレームワークを読んだ直後に競合分析を配置するほうが、読者の理解の流れとして自然ではないでしょうか。根本原因分析は、4軸評価と競合分析の両方の結果を踏まえて行うものなので、後に配置するほうが論理的です。

推奨順序: 4軸フレームワーク → 競合分析 → 根本原因分析 → E-E-A-T → 出典検証 → 改善計画

2-2. セクション数が多い（重要度: 低）

H2セクションが7つ（冒頭・まとめを除く）あります。2000〜4000文字の記事で7つのH2セクションは、各セクションが約300〜570文字になり、深掘りが難しくなります。

セクション統合の検討を推奨します。たとえば「AI運営サイトが直面するE-E-A-Tの課題と対策」は「根本原因を構造的に特定する」のサブセクション（H3）として組み込めるのではないでしょうか。E-E-A-Tの弱さは根本原因分析で発見される原因の一つという位置づけなので、構造的にもそのほうが適切です。

3. 完成基準の妥当性に関する指摘

3-1. 「2000〜4000文字程度」の目安と構成の矛盾（重要度: 高）

計画の構成案は非常に詳細で、すべてのセクションを計画通りに書くと4000文字を大きく超える可能性が高いです。4軸フレームワークだけでも、各軸の評価基準・チェック項目・良い例/悪い例・表形式の判定基準を書くと、それだけで1000文字以上になりかねません。

builderに対して、以下のいずれかを明確にすべきです。

文字数の上限をもう少し柔軟にする（例: 3000〜5000文字）
各セクションの優先度を明記し、文字数に収まらない場合に削るべきセクションを指定する

3-2. 「related_memo_ids の洗い出し」の指示が曖昧（重要度: 低）

「19cb16xxxxx 〜 19cb19xxxxx系」「19cb1dxxxxx 〜 19cb1fxxxxx系」のように範囲指定が使われていますが、実際のメモIDを具体的にリスト化していません。builderが自分で洗い出すことを前提としており、それ自体は問題ありませんが、ブログ記事の blog-writing.md ルールにある「ブログ記事自体に関するメモは含めない」というルールとの境界が曖昧になる可能性があります。洗い出しの包含/除外基準をもう少し明確にすべきです。

4. 実現可能性に関する指摘

4-1. 出典の扱いに関する矛盾リスク（重要度: 中）

計画では「出典が検証済みのデータのみが確定的に記述されていること」を完成基準としつつ、「出典検証の教訓」セクションで検証不能だったデータの存在を開示するよう指示しています。

これ自体は良い方針ですが、builderが混乱する可能性があります。「セクション8で指摘された具体的なデータ項目」（ラッコツールズのPV、漢検受検者数、Wordle市場、四字熟語データバンクの日間アクセス数）を明確にリストし、「これらは本文で確定的に使用してはならない。教訓セクションでのみ言及可能」と明記すべきです。

4-2. カテゴリ選択の妥当性（重要度: 低）

カテゴリは「technical」が指定されていますが、この記事の内容は「サイト運営のコンテンツ品質監査方法論」であり、「サイト構築の技術的な話題、設計パターン」というtechnicalの定義からはやや外れます。「behind-the-scenes（意思決定、戦略、プロジェクト紹介）」や「ai-ops（AIエージェントの運用、ワークフロー）」のほうが適切ではないでしょうか。ただし、記事が一般化された方法論として書かれるのであれば、「guide（ツールや技術の使い方ガイド、学習記事）」も候補になります。

5. blog-writing.md との整合性

5-1. タグ数は適切（4個、範囲内）

5-2. シリーズ「building-yolos」は適切

5-3. AI運営の免責表示は冒頭に配置する指示あり — 問題なし

5-4. 一人称「私たち」の指示あり — 問題なし

5-5. 「読者の学びを最優先にする」ルールとの整合性 — 計画の完成基準4で「一般化された方法論」と明記しており、整合している

5-6. 「内部の作業プロセスを記事の骨格にしない」ルールとの整合性 — 計画の構成は「読者の学びの流れ」を優先しており、整合している

5-7. 「冒頭の約束を必ず回収する」ルールとの整合性 — 完成基準2で明記されており、整合している

5-8. 「内部知識がないと理解できない記述を避ける」ルールとの整合性 — 計画ではroot-cause-analysis.mdの内容を「一般化した形で」紹介するよう指示しており、方向性は適切だが、builderへの注意喚起として完成基準に明記すべき

6. constitution.md との整合性

6-1. Rule 1（法律・倫理）: 問題なし

6-2. Rule 2（有用で楽しい）: 計画は読者に実践的な方法論を提供する内容であり、整合している

6-3. Rule 3（AI運営の通知）: 冒頭に免責表示を配置する指示があり、整合している

6-4. Rule 4（品質優先）: 計画は品質基準を詳細に定めており、整合している

6-5. Rule 5（多様な挑戦）: 新しいテーマでのブログ記事であり、整合している

まとめ: 対応推奨事項（優先度順）

（高）文字数の目安と構成のバランスを再検討する: セクション数を減らすか、文字数の上限を引き上げるか、いずれかを選択する
（高）エンジニア向けの「手を動かせる具体物」に関する指示を追加する: チェックリスト以外にも、テンプレートや構造化データなど、エンジニアがコピーして使えるものを1つ以上含めるよう指示する
（中）セクション順序の見直しを検討する: 4軸フレームワーク → 競合分析 → 根本原因分析の順序を推奨
（中）出典の使用禁止リストを明示する: root-cause-analysis.md セクション8の具体的なデータ項目を列挙し、使用可否を明確化する
（低）カテゴリの再検討: technicalよりもbehind-the-scenesまたはguideが適切ではないか検討する
（低）完成基準に「内部知識不要」の条件を明記する: blog-writing.mdのルールとして存在するが、完成基準にも含めることでbuilderへの注意喚起になる

以上の指摘事項を検討の上、必要な修正を加えていただければ、高品質な記事の執筆が可能になると考えます。