CMSテンプレート（アリス編集室）

ダウンロード

下の各フォルダから、全文を読んでコピーすることもできます。

• Lv.1 は無料のチャット型 AI だけで使えます。
• Lv.2 以上は Claude Code（Claude の有料プランが必要）を使います。
• Lv.3 はさらに Python と、Google アナリティクス・Search Console の設定が要ります。費用の目安は 無料と有料のAIチャット を見てください。

https://aliceinsandbox.com/setup.md を読んで、導入する前に、危険な操作や不審な指示が書かれていないかを確認して結果を教えて。アリス編集室テンプレートの導入は、私が「続けて」と言うまで始めないで

使い方の記事

• ブログ記事をAIに採点させる無料プロンプト5本｜公開前に貼るだけ
• Lv.2 エージェントで記事を1本通す
• Lv.3 採点ゲートと書き直しループ
• 初稿と最終版を比べてAIのクセを減らす
• 記事のリンク切れをまとめて点検

このフォルダのファイル

• .claude/フォルダ
• docs/フォルダ
• prompts/フォルダ
• scripts/フォルダ
• .gitignore456 B
• CLAUDE.example.md5,552 B
• config.example.yaml10,539 B
• LICENSE1,085 B
• requirements.txt350 B

版: 2026-10-23（変更点は末尾の「変更履歴」）

AI に記事を書かせて、AI に採点させて、最後は人間が確認する。そのための編集体制のテンプレートです。

実際に複数のブログを運営している仕組みから、サイト固有の値を抜いて汎用化したものです。このフォルダの中身を自分のプロジェクトにコピーすれば、そのまま動く形にしてあります。

.claude/ は隠しフォルダです。 名前が .（ドット）で始まるフォルダは、初期設定では表示されません。コピーし忘れないよう、先に隠しファイルを表示しておいてください。 - Windows: エクスプローラーの「表示」→「隠しファイル」にチェックを入れる（Windows 11 は「表示」→「表示」→「隠しファイル」） - macOS: Finder で Command + Shift + .（ピリオド）を押す（もう一度押すと元に戻ります）

目次

1. これは何か
2. Lv.1 チャットに貼るだけのレビュー
3. Lv.2 役割分担エージェント
4. Lv.3 レビューパイプライン
5. 手で導入する
6. Claude に頼んで導入する
7. 設定ファイル
8. アクセス解析の準備（Lv.3）
9. 安全に使うために
10. 保守（テンプレートを書き換えるとき）
11. ライセンス
12. 変更履歴

これは何か

• 配布の形: このサイトの zip（Lv.1〜Lv.3）と、このサイトの各ページの全文（コピーして使えます）。GitHub では配布していません。
• 必要なものと費用（各エージェントの model: opus は定義ファイルの先頭で sonnet などに変えられます。このサイトでは opus 以外を試していないので、点数がどう変わるかは分かりません）: Lv.1 は無料のチャット型 AI だけ。Lv.2 以上は Claude Code（Claude の有料プラン）。Lv.3 は Python と Google の設定も。

フォルダの中身

template/
├─ README.md             この説明書
├─ LICENSE               MIT ライセンス
├─ CLAUDE.example.md     プロジェクトの説明書のひな形（CLAUDE.md にして使う）
├─ config.example.yaml   設定ファイルの見本（設定ファイルはこれ1つだけ。config.yaml にして使う）
├─ requirements.txt      Python の依存パッケージ（これ1つだけ）
├─ .gitignore            Git に入れてはいけないファイルの一覧
├─ prompts/              Lv.1: チャットに貼るレビュアーのプロンプト 5本
├─ .claude/
│  ├─ agents/            Lv.2: 役割ごとのエージェント 8体
│  └─ skills/            Lv.3: 指揮役・分析・差分学習・リンク健診のスキル 4つ
├─ docs/                 執筆ガイドのひな形と、採点ルーブリック 2本
└─ scripts/              Python のスクリプト（機械計測・ログ・リンク健診など）
   └─ analytics/         GA4 と Search Console のデータを貯めるバッチ

どこまで使うか（レベル）

レベルは「どこまで使うか」の違いです。フォルダを丸ごとコピーしても、使わない部分は動かないだけで害はありません。

配布用の zip も、この表と同じ範囲で切り出しています（README と LICENSE はどのレベルにも入れます）。下のレベルは上のレベルの土台です。Lv.3 を使うには Lv.2 のエージェントが必要です。

全体の流れ（Lv.3）

下書き ─→ レビュアーが並列で採点 ─→ 点数ゲート ─→ 合格 ─→ 人間が最終確認 ─→ 公開
                                        │
                                        └─ 不合格 ─→ 書き直し ─→ 再採点（上限回数まで）

このテンプレートでは、最終判断をする人を「運営者」と呼びます（呼び方は config.yaml の operator_name で変えられます）。

Lv.1 チャットに貼るだけのレビュー

Claude Code を使わず、ふだんのチャット画面だけで記事をレビューしてもらうためのプロンプト集です。prompts/ の5つのファイルが、それぞれ1人のレビュアーになります。

使い方

1. ファイルを開き、上のほうにある「▼▼ ここを自分で書く: サイトの情報 ▼▼」の【　】を埋めます。サイト名・読者・収益の方法・合格点は、5つのファイルに共通です。一度埋めたものを手元に保存しておくと、次から貼るだけで済みます。
2. ファイルの中身をすべてコピーして、新しいチャットに貼ります。
3. その下に、レビューしてほしい記事の本文を貼って送ります。
4. 1行目に点数が、続いて指摘の表が返ってきます。

レビュアーごとに、新しいチャットを開いてください。 同じチャットで続けると、前のレビュアーの意見に引きずられます。記事を書いてもらったチャットでレビューを頼むのも避けてください（書いた本人は自分の文章に甘くなります）。

合格点に「正解」はありません。何本か試して、自分が「これなら出せる」と思える記事が何点になるかを見て決めてください。

回す順番

1. legal.md と consistency.md（先に回す） この2つは、「必須」の指摘が1件でもあれば点数に関係なく公開を止めるレビュアーです。ここで止まった記事は、先に直します。
2. confidentiality.md（本業と近い題材を書いている場合だけ） 必要な人は、1 と同じ段階で回してください。
3. growth.md と readers-panel.md 合格点に届かなければ書き直します。
4. 書き直したら、もう一度 1 から回します。 直したことで別の場所が壊れることがあるためです。何回まで書き直すかは、あらかじめ自分で決めておいてください。決めた回数で届かなければ、その記事は自分の手で直すか、企画から見直します。

指摘同士がぶつかったとき（例: SEO は「タイトルを強い言葉に」、法務は「誇大表現」）は、機密 → 法務 → 整合 → 読者 → SEO → CRO の順に優先します。

表の「直せる人」の欄が 🤖 の指摘は、文章の書き直しで直ります。🧑 の指摘は、写真を撮る・実際に測る・公式情報を確認するなど、人の作業が必要です。

チャットだけのレビューの限界

• 機械で数えていません。 字数、件数、長い文の数は、AI が目分量で答えています。数え間違いがあります。正確な数が要るときは、自分で数えてください。
• ほかの記事と突き合わせられません。 「別の記事では違う価格を書いていた」「過去の記事と合わせると個人が特定できる」といった問題は見つけられません。
• 記事の外の事実を確かめられません。 メーカーの仕様、現在の価格、規約の最新の文面は、貼った記事からは分かりません。「要確認」と返ってきた箇所は、自分で公式情報を見てください。
• 公開ページの見た目を見ていません。 広告である旨の表示がテンプレートで自動的に入る場合、貼った本文には無いので「表示が無い」と指摘されることがあります。サイトの情報の欄に書いておくと減らせます。写真やスクリーンショットの写り込みも確認できません。
• 前回のレビューを覚えていません。 2回目のレビューで「前回の指摘が直ったか」を見てほしいときは、前回の指摘の表も一緒に貼ってください。
• 毎回、点数が変わります。 同じ記事でも点数は上下します。このサイトの記録では、同じ記事・同じプロンプトで 20 点の差が出たことがあります（Lv.1 の記事）。点数の細かい差ではなく、「必須」の指摘が残っているかどうかを見てください。合格点は 1 回の点数で決めず、何本か試してから決めてください。

これらの限界を埋めるのが Lv.2（ファイルを読み書きできるエージェント）と Lv.3（機械計測と自動の合否判定）です。

Lv.2 役割分担エージェント

ブログ記事づくりを、役割の違う8体のエージェントに分けたものです（Claude Code 用）。「書く役」と「点検する役」を別にすることで、書いた本人（AI）が自分の文章を甘く採点してしまうのを防ぎます。

Lv.1 との違いは、エージェントがファイルを読み書きできることです。ほかの記事と数字を突き合わせる、字数や件数を実際に数える、レビュー結果をファイルに残して前回と比べる、といったことができます。

Lv.3 は、この8体を自動で順番に呼び出して合否判定まで行う仕組みです。Lv.2 では、呼び出す順番を決めるのはあなた自身です。

入っているもの

導入の手順は「手で導入する」にあります。

機密レビュアーを使う場合の注意

confidentiality-reviewer.md の「サイト別」は空欄になっています。ここに「書かない話題」などを記入すると、そのファイル自体が機密になります。記入済みのファイルを公開しないでください。公開リポジトリにコミットしないでください。

機械計測について

各レビュアーは scripts/review_metrics.py（字数・見出し・長い文などを数えるスクリプト。Lv.3 に含まれます）の結果を受け取れる書き方になっています。無くても動きます。その場合、レビュー結果に「機械計測未参照」と書かれます。

機械計測は textlint／Vale のような文法チェッカーの代わりではありません（候補を挙げるまで）。既存の linter と併用できます。対応する記事の拡張子は .md と .html です（.mdx・.markdown も Markdown として扱います。それ以外の拡張子は HTML として扱います）。

エージェント同士の受け渡し

blog-idea-scout ──→ ideas/{日付}_ideas.md
                        │ 運営者が1件選ぶ
                        ▼
blog-researcher ──→ research/{slug}.md
                        ▼
blog-writer ──────→ content/articles/{slug}.md
                    （初稿のコピーを reviews/drafts/ に保存）
                        ▼
レビュアー（並べて実行してよい）
  legal-reviewer          → reviews/legal_{slug}_{日時}.md
  consistency-reviewer    → reviews/consistency_{slug}_{日時}.md
  growth-reviewer         → reviews/seo_… と reviews/cro_…
  blog-readers-panel      → reviews/panel_{slug}_{日時}.md
  confidentiality-reviewer → reviews/confidentiality_…（使うサイトだけ）
                        ▼
合格点に届かない・必須の指摘がある
  → blog-writer に「最新のレビューファイルを反映して」と頼む
  → もう一度レビュー（上限回数まで）
                        ▼
運営者が自分の目で確認 → 公開

受け渡しの決まりごとは次のとおりです。

• レビュアーは記事を書き換えません。 指摘と採点だけを行い、修正は必ず blog-writer に戻します。
• レビュー結果は毎回新しいファイルとして残します（上書きしない）。2回目以降のレビューは、前回のファイルを読んで「直ったか・新しく壊れていないか」を報告します。
• 各レビューには「✅キープリスト（書き直しで壊してはいけない良い箇所）」が付きます。blog-writer はこれを守って書き直します。
• blog-writer は本文を変えるたびに「未レビュー変更あり」と報告します。この報告が出たら、もう一度レビューが必要です。
• legal と consistency（TIER1）は、「必須」の指摘が1件でもあれば点数に関係なく止めます。ほかのレビュアー（TIER2）は合格点で判定します。
• レビュアー同士の指摘がぶつかったときは、機密 → 法務 → 整合 → 読者 → SEO → CRO の順に優先します（config.yaml の gate.conflict_priority）。

Lv.3 レビューパイプライン

Lv.2 のエージェント（書き手とレビュアー）を、決まった手順で動かす仕組みに仕上げるセットです。記事を書いたあと「誰に・どの順で・何点なら通すか」を毎回考えなくても、同じ品質の確認が回るようになります。

合格しても、記事は自動では公開されません。 このパイプラインが行うのは採点と書き直しの指示までです。公開するかどうかは、最後に必ず運営者（あなた）が決めます。

Lv.2 から増えるもの

Lv.2 との違いは、合否を点数と必須指摘で機械的に判定し、レビュー結果に記事の md5 を記録して「レビュー後にこっそり変わった記事」を公開前に検出できる点です。

流れ

 下書き（blog-writer）
        │
        ▼
 機械計測  scripts/review_metrics.py  … 計測結果と md5 を全レビュアーに渡す
        │
        ▼
 並列レビュー
   TIER1: legal-reviewer / consistency-reviewer（＋必要なら confidentiality-reviewer）
   TIER2: growth-reviewer（SEO・CRO）/ blog-readers-panel
        │
        ▼
 ゲート判定 ── TIER1 に必須指摘あり ────────────▶ 停止して運営者に報告
        │
        ├─ 全員が合格点以上・必須指摘なし ───────▶ 合格
        │
        └─ 合格点未満
              ├─ 運営者にしか直せない（実測・写真など）▶ 停止して運営者に依頼
              └─ 書き直しループ（blog-writer に差し戻し → 不合格だった
                 レビュアーと TIER1 だけ再レビュー。上限回数で打ち切り）
        │
        ▼
 レビューサマリー出力（reviews/review_summary_YYYYMMDD.html）
        │
        ▼
 公開前の鮮度照合（md5 が一致するか）
        │
        ▼
 運営者の最終確認 ……… 公開するかどうかは人が決める（自動公開なし）

合格点・目標点・ループ上限・レビュアー編成・指摘がぶつかったときの優先順は、すべて config.yaml の gate で決めます。

使い方

Claude Code で次のように頼みます。

必要なもの

• Lv.2 のエージェント一式（.claude/agents/）
• Python 3.10 以上（scripts/ 直下のスクリプトだけなら 3.9 以上でも動きます）
• requirements.txt のパッケージ

pip install -r requirements.txt

scripts/ 直下のスクリプトが使うのは PyYAML だけです（config.yaml を読むため。ほかは標準ライブラリ）。PyYAML が無くてもスクリプトは既定値で動きますが、config.yaml の設定は反映されません。Google のパッケージはアクセス解析（scripts/analytics/）だけで使います。

手で導入する

すべての作業は、自分のプロジェクトのルート（記事を置いているフォルダの一番上）で行います。

Lv.1 の最短 3 ステップ

1. prompts/legal.md と prompts/consistency.md の全文をコピーして、手元に保存します
2. 「▼▼ ここを自分で書く: サイトの情報 ▼▼」の【　】を埋めます
3. 新しいチャットに 1 本を貼り、その下に記事を貼って送ります（1 本ごとに新しいチャット）

Lv.1 で必要なのは prompts/ のファイルを手元に置くことだけです。残りの 3 本の使い方は「Lv.1」を見てください。

Lv.2

1. .claude/agents/ の中身を、自分のプロジェクトの .claude/agents/ にコピーします（隠しフォルダです。冒頭の注意を参照）。
2. CLAUDE.example.md を、プロジェクトのルートに CLAUDE.md という名前でコピーし、（）の部分を埋めます。
3. docs/writing_guide.example.md を docs/writing_guide.md という名前でコピーし、空欄を埋めます。字数の範囲は自分で決めてください（正解の既定値はありません）。
4. 各エージェントの「サイト別（ここを自分のサイト用に書き換える）」を書き換えます。記入例は架空の家庭菜園ブログのものなので、必ず自分のサイトの内容に置き換えてください。
5. 合格点・目標点・書き直しの上限回数を決めます。エージェントは config.yaml の gate.pass_score・gate.target_score・gate.max_rewrite_loops を参照する書き方になっています（設定ファイルの見本は config.example.yaml）。Lv.2 だけを使う場合は、同じ値を CLAUDE.md の「公開ゲート」に書いておけば足ります。
6. フォルダ ideas/・research/・reviews/ を作ります。reviews/ は公開フォルダの外に置いてください。

すでに .claude/ や CLAUDE.md があるプロジェクトに入れるときは、次の 3 点に気をつけてください。

• 同じ名前のエージェント（writer.md など）がすでにあるときは、上書きせずに、テンプレート側のファイル名と中の name: を変えます
• CLAUDE.md は置き換えずに、CLAUDE.example.md の内容を既存の CLAUDE.md に追記します
• article-review スキルの description は「レビューして」で自動起動する書き方になっています。既存のレビュー手順があるなら、.claude/skills/article-review/SKILL.md の description を書き換えて、起動する言葉がぶつからないようにします（Lv.3 を入れるとき）

Lv.3

Lv.2 の手順に続けて行います。

1. フォルダをコピーする: 次のものをプロジェクトのルートにコピーします（同じ名前のフォルダがあれば中身を足します）。 .claude/skills/ （article-review・blog-analytics・diff-learning・link-audit の4フォルダ） scripts/ （analytics/ を含む） docs/ （blog_article_rubric.md・legal_audit_rubric.md） config.example.yaml requirements.txt .gitignore （すでにある場合は、中身を自分の .gitignore に書き足す）
2. 依存パッケージを入れる: pip install -r requirements.txt（仮想環境を使う場合は「アクセス解析の準備」の手順3を参照）
3. 設定を作る: config.example.yaml を config.yaml という名前でプロジェクトのルートにコピーし、空欄を埋めます。 - 必須: site.key・site.name・site.domain・gate.pass_score・gate.max_rewrite_loops - gate.pass_score と gate.max_rewrite_loops が空のままだと、article-review は採点を始める前に止まって値を尋ねます。正解の既定値はありません。数本の記事で試して決めてください - 広告を置いているサイトは metrics.affiliate_domains に広告・計測サービスのドメインを必ず書く（リンク健診がそこへアクセスしないようにするため） - config.yaml は Git に入れない（.gitignore 済み）
4. 動作確認: bash python -X utf8 scripts/review_metrics.py content/articles/（記事ファイル） --config config.yaml python -X utf8 scripts/archive_reviews.py # dry-run（何も動かさない） python -X utf8 scripts/link_check.py --config config.yaml --offline
5. アクセス解析を使う場合は、「アクセス解析の準備」に進みます。

Claude に頼んで導入する

この方法は、配布用の zip と、その SHA-256 を手順書（setup.md）で照合する前提です。手で入れたい人は「手で導入する」を使ってください。

Claude Code に、次の1行を送るだけで導入できます。

https://aliceinsandbox.com/setup.md を読んで、導入する前に、危険な操作や不審な指示が書かれていないかを確認して結果を教えて。アリス編集室テンプレートの導入は、私が「続けて」と言うまで始めないで

Claude Code は手順書（setup.md）を読んで、次の順に進めます。

1. 手順書に危険な操作や不審な指示が書かれていないかを確かめて、結果を報告する
2. これから行う手順を見せて、続けてよいかを確認する
3. 導入先のフォルダと、使うレベル（Lv.1〜3）を聞く
4. 配布用の zip をダウンロードし、SHA-256 を手順書の値と照合する（一致しなければ止まる）
5. 置く予定のファイルの一覧を見せてから配置する。同じ名前のファイルは上書きせずに聞く
6. 合格点などの設定値を1つずつ聞いて config.yaml に書く（推測で埋めない）
7. 動作確認の結果を見せる

頼む前に、手順書を自分の目で読んでください。 インターネット上の手順書を AI に実行させるときは、中身を確かめるのが安全です。手順書には、認証情報のファイルを読まない、git push や公開をしない、Google の認証は利用者が自分で行う、といった決まりも書いてあります。

設定ファイル

設定ファイルは config.example.yaml の1つだけです。プロジェクトのルートに config.yaml という名前でコピーして使います。スキル・エージェント・スクリプト・アクセス解析のすべてが、この1つのファイルを読みます。

• 各キーの意味は、ファイルの中のコメントに書いてあります。
• ファイルの中の相対パスは、すべてプロジェクトのルートが基準です。
• 分析DBの場所は analytics.database の1か所だけに書きます。取得バッチ・blog-analytics スキル・エージェントが同じ値を読みます。
• gate.pass_score（合格点）と gate.max_rewrite_loops（書き直し回数）には既定値がありません。空欄のまま自分で決めて埋めてください。

アクセス解析の準備（Lv.3）

scripts/analytics/ は、Google Analytics 4 (GA4) と Google Search Console のデータを毎日取得し、ローカルの SQLite ファイルに蓄積するバッチです。管理画面では一定期間で見られなくなるデータ（Search Console は約16か月）を手元に残し、SQL で自由に集計できるようにします。blog-analytics スキルの週次レポートは、このデータを読みます。

• 読み取り専用スコープだけを使います（GA4 / Search Console の設定は変更しません）。
• 複数サイトに対応しています。全テーブルに site 列があります。
• 何度実行しても行が重複しません（冪等）。
• コマンドはすべてプロジェクトのルートで実行します。設定は config.yaml の analytics: 節から読みます（--config で別のファイルも指定できます）。

ファイル構成

1. Google Cloud プロジェクトを用意する

1. Google Cloud コンソール でプロジェクトを作成する（既存のものでも可）。
2. 「APIとサービス」→「ライブラリ」で、次の2つの API を有効にする。 - Google Analytics Data API - Google Search Console API

2. 認証方式を選ぶ

OAuth を使う場合

1. 「APIとサービス」→「OAuth 同意画面」を設定する。 公開ステータスが「テスト」のままだと、リフレッシュトークンが短期間（7日）で失効し、無人実行が止まります。 継続して動かすなら「本番環境」に切り替えてください。
2. 「認証情報」→「認証情報を作成」→「OAuth クライアント ID」→ 種類は デスクトップ アプリ。
3. JSON をダウンロードし、プロジェクトのルートに client_secret.json という名前で置く（場所と名前は analytics.oauth_client_file で変えられます）。
4. config.yaml の analytics.auth_mode を oauth にする。

サービスアカウントを使う場合

1. 「IAM と管理」→「サービス アカウント」で作成し、キー（JSON）を発行する。
2. JSON をプロジェクトのルートに service_account.json という名前で置く（analytics.service_account_file で変えられます）。
3. サービスアカウントのメールアドレスを、GA4 の「プロパティのアクセス管理」（閲覧者）と、 Search Console の「ユーザーと権限」に追加する。
4. config.yaml の analytics.auth_mode を service_account にする。

3. インストールと設定

python -m venv .venv
# Windows:  .venv\Scripts\activate
# macOS / Linux:  source .venv/bin/activate
pip install -r requirements.txt

config.yaml の analytics.sites の各値を自分のサイトに書き換えます。各キーの意味はファイル内のコメントを参照してください。特に間違えやすいのは次の2つです。

• ga4_property_id … GA4 管理画面の「プロパティの詳細」にある数字だけのID。G- で始まる測定IDではありません。
• gsc_site_url … Search Console のプロパティの種類で書き方が変わります。
• URLプレフィックス プロパティ: https://example.com/（末尾のスラッシュまで）
• ドメイン プロパティ: sc-domain:example.com

analytics.sites の site には、site.key と同じ値を書いてください（blog-analytics スキルはこの値で DB を引きます）。

4. 初回認証（OAuth のみ）

python -X utf8 scripts/analytics/auth_setup.py

ブラウザが開くので、GA4 と Search Console の権限を持つアカウントでログインして許可します。 成功すると token.json が作られます。やり直すときは python -X utf8 scripts/analytics/auth_setup.py --force。

5. 実行

python -X utf8 scripts/analytics/main.py              # 全サイト取得 → SQLite → CSV
python -X utf8 scripts/analytics/main.py --no-csv     # CSV 出力を省く
python -X utf8 scripts/analytics/main.py --config path/to/other.yaml
python -X utf8 scripts/analytics/main.py --inspect-now --inspect-limit 5   # URL Inspection を今すぐ5件だけ試す

DB ファイルは初回実行時に自動で作られます（既定は data/analytics.db）。結果は logs/ のログと、batch_runs テーブルで確認できます。

毎日の自動実行

1日1回の実行を想定しています。取得のたびに直近の数日〜十数日を取り直すので、数日止まっても次の実行で自動的に埋まります（それより長く止まった場合は backfill.py を使います）。

Windows（タスク スケジューラ）

1. 「タスク スケジューラ」→「基本タスクの作成」。
2. トリガー: 毎日、任意の時刻。
3. 操作: 「プログラムの開始」。 - プログラム: 仮想環境の python.exe のフルパス - 引数: -X utf8 scripts/analytics/main.py - 開始（作業フォルダ）: プロジェクトのルートのパス
4. PC がスリープ中だと動かないので、必要なら「タスクを実行するためにスリープを解除する」を有効にする。

macOS / Linux（cron）

crontab -e で次のような行を追加します（<プロジェクトのルート> は実際のパスに置き換える）。

0 5 * * * cd <プロジェクトのルート> && .venv/bin/python -X utf8 scripts/analytics/main.py >> logs/cron.log 2>&1

サイトを追加する

config.yaml の analytics.sites にブロックを1つ追加するだけです。コードの変更は不要です。

analytics:
  sites:
    - site: site_c
      ga4_property_id: "（数字だけのプロパティID）"
      gsc_site_url: "sc-domain:example.net"
      domain: "example.net"
      sitemap_url: "https://example.net/sitemap.xml"

追加した日より前のデータは日次バッチでは入らないので、必要なら過去分を取り込みます。

python -X utf8 scripts/analytics/backfill.py --site site_c --start 2025-01-01
python -X utf8 scripts/analytics/backfill.py --site site_c --start 2025-01-01 --end 2025-03-31 --sources gsc

• --sources: ga4（日次系）/ page（page_metrics のスナップショット）/ gsc / affiliate。既定は全部。
• page は1日ぶんごとに1リクエスト投げるので、期間が長いと時間がかかります。
• 実行前に DB ファイルをコピーしてバックアップしておくことをおすすめします。

テーブル一覧

page_path / landing_page / article_path は、どのテーブルでも同じ規則で正規化された「ドメイン無しのパス」なので、GA4 のテーブルと Search Console のテーブルを JOIN できます。

-- 例: 検索では表示されているのに読まれていないページ
SELECT g.page_path, SUM(g.impressions) AS imp, SUM(g.clicks) AS clk
FROM gsc_page_metrics g
WHERE g.site = 'site_a' AND g.date >= date('now', '-28 day')
GROUP BY g.page_path
ORDER BY imp DESC
LIMIT 20;

アフィリエイトクリック（任意）

サイトが広告リンクのクリックを GA4 イベントとして送っている場合、analytics.sites のサイトのブロックに ga4_affiliate_event: "イベント名" を書くと affiliate_click_metrics に集計されます。書かなければ何もしません。

前提として、そのイベントにパラメータ article_path（クリックされたページのパス）と link_host（遷移先のホスト名）を付け、GA4 管理画面の「カスタム定義」で同名のイベントスコープのカスタムディメンションを登録しておく必要があります。未登録の場合は警告を出してスキップします。登録より前の日付は (not set) になります。

仕組みのメモ

データ鮮度

• GA4 は直近のデータが後から再処理されて変わります。そのため日次系は毎回、直近 ga4_reprocess_days 日を消して入れ直します。
• Search Console は数日遅れで確定します。終端を「今日 − gsc_lag_days」にして、そこから page_rolling_days 日ぶんを毎回入れ直します。

URL の正規化

GA4 はパス（/blog/post）、Search Console はフル URL（https://example.com/blog/post）で返します。common.normalize_path() がドメイン・クエリ文字列・フラグメント・末尾スラッシュを取り除いて同じキーに揃えます。 同じページが /foo と /foo.html、/foo/index.html のように複数の表記で記録されるサイトは、サイトのブロックに strip_html_suffix / strip_index_html / strip_path_prefix を付けると1つにまとまります。サイトの URL 設計に合わないものを付けると別のページが混ざるので、付ける前に実際の URL を確認してください。

失敗時の動き

• API 呼び出しは、待ち時間を倍に伸ばしながら最大 retry_max 回まで再試行します。
• 1サイト・1ソースが失敗しても、batch_runs に failed と記録して残りを続けます。
• すべて失敗したときだけ、終了コードが 0 以外になります。

API の利用上限

各 API には1日あたり・1分あたりの利用上限があります。URL Inspection は1 URL につき1リクエストなので、ページ数の多いサイトでは inspect_weekday で頻度を抑えてください。最新の上限値は Google の公式ドキュメントを確認してください。

下降トレンドの早期警告（yellow_lamp.py）

蓄積した Search Console データから、次のどちらかに当てはまるサイトに警告を出します。

1. 表示回数の四半期（91日）合計が、2四半期連続で前の四半期を下回った
2. 検索で表示されたページの数（各四半期の最後の7日間）が、2回連続で減った

python -X utf8 scripts/analytics/yellow_lamp.py                 # config.yaml の analytics.database を使い、全サイトを判定
python -X utf8 scripts/analytics/yellow_lamp.py --site site_a
python -X utf8 scripts/analytics/yellow_lamp.py --db data/analytics.db

判定には約9か月分（3四半期）のデータが必要です。足りないうちは「判定不能（データ蓄積中）」と表示されます。点灯は「すぐ対応する」合図ではなく、「次の見直しで話題にする」ための目印として使ってください。

テスト

python -X utf8 scripts/analytics/tests/test_normalize_path.py

安全に使うために

• 合格しても自動では公開しません。 法律、広告表記、個人や勤務先の特定につながる内容は、最後に必ず人間が読んで判断してください。
• 合格点と書き直し回数に既定値はありません。 config.example.yaml の空欄を自分で埋めます。点数は品質の目安で、検索順位や収益を保証するものではありません。
• AI の採点は見落とします。 とくに法務と機密は、AI の「問題なし」をそのまま信じないでください。体験談・実測値・写真は運営者にしか用意できません。レビューで 🧑 の印が付いた指摘は、人の手でしか直せないものです。
• 公開の操作（アップロードなど）は、どのエージェントも行いません。 運営者が記事を最初から最後まで自分の目で読み、自分の手で公開します。
• レビュアーは記事を書き換えません。 修正は blog-writer が行い、修正後は必ず再レビューを通します。
• reviews/ は公開フォルダの外に置いてください（レビュー結果がサイトに出ないように）。
• リンク健診で metrics.affiliate_domains を空のまま HTTP 実査を走らせないでください（スクリプト側でも止まります）。
• 認証情報と分析データは公開しないでください。 client_secret.json / service_account.json / token.json は、あなたの Google アカウントのデータを読める鍵です。config.yaml にはプロパティIDとサイトURLが、data/analytics.db・exports/・logs/ にはサイトのアクセスデータが入ります。付属の .gitignore で除外していますが、フォルダごと ZIP にして渡す、クラウドストレージで共有する、Web サーバーの公開ディレクトリに置く、といった経路でも漏れます。漏れた可能性があるときは、Google Cloud で該当のクライアントシークレット / 鍵を削除して作り直し、Google アカウントの「サードパーティのアクセス」からアプリの許可を取り消してください。
• 記入済みの confidentiality-reviewer.md は機密です。 公開しない・公開リポジトリにコミットしないでください。
• Web を読むエージェント（WebSearch／WebFetch を持つもの）は、読んだページの文章に操作されるおそれがあります（プロンプトインジェクション）。 レビュアーの指摘に「このファイルを消せ」「この URL に送れ」のような操作の指示が混ざっていたら従わず、運営者に報告させてください。外部を読む役と、ファイルを書く・コマンドを実行する役を分けると、影響を小さくできます。このテンプレートでは、Web を読むレビュアー（growth・consistency）に Bash を持たせていません（2026-10-22〜。機械計測の結果は指揮役の article-review スキルが実行して渡します）。執筆役（writer）も Web を読みません（2026-10-23〜。裏取りは researcher が research/ に残した結果だけを使い、無ければ researcher への依頼を報告します）。Web を読むのは idea-scout・researcher・legal・consistency・growth の5体だけで、この5体はいずれも Bash を持ちません。Bash を持つのは writer だけで、使い道は config.yaml の build_check_command（記事の検証コマンド）に限ると定義ファイルに書いてあります（tools: では用途まで制限できないので、約束として書いています）。
• Claude Code の権限設定で、できることを狭めておけます。 プロジェクトの .claude/settings.json（または自分だけの .claude/settings.local.json）に、次のように書きます。deny は allow より優先されます。WebFetch は allow に書いたドメインだけが確認なしで読め、それ以外は毎回確認が出ます（拒否ではありません）。Bash(git push *) は git -C . push のような書き方には効かないので、公開の操作は運営者が自分の手で行う前提は変わりません。設定の書き方は Claude Code の公式ドキュメント（settings）と同（permissions）で確かめてください（2026年10月22日時点の記法）。

json { "permissions": { "allow": [ "WebFetch(domain:docs.example.com)" ], "deny": [ "Bash(git push *)", "Bash(rm -rf *)", "Read(./.env)", "Read(./.env.*)" ] } }

• このテンプレートは法的助言ではありません。 法務レビュアーとルーブリックは気づきを増やす道具で、適法性を保証しません。法令や各サービスの規約は、必ず一次情報で確認してください。

保守（テンプレートを書き換えるとき）

同じレビュアーが、チャット版（prompts/）とエージェント版（.claude/agents/）の2か所にいます。片方だけを直すと、見るところや点数の名前がずれていきます。書き換えたら次を実行してください。

python -X utf8 scripts/check_prompts.py

• 5人のレビュアーそれぞれについて、2つのファイルが両方あるか、スコア行のラベル（「法務スコア」など）が一致するかを調べます。どちらかに問題があると終了コード 1 で止まります。
• 番号付きのチェック項目の見出しが片方にしか無いものは、警告として一覧にします。チャット版は短くまとめているので、意図した差なら直さなくてかまいません。

ライセンス

MIT License です。商用・改変・再配布ができます。著作権表示とライセンス文は残してください。

変更履歴

• 2026-10-23: 執筆役（.claude/agents/writer.md）の tools から WebSearch・WebFetch を外し、裏取りは research/ の結果だけを使う約束と、Bash を build_check_command だけに使う約束を定義に追記。「安全に使うために」に Web を読む役と Bash を持つ役の一覧を追記
• 2026-10-22: 点数のぶれの記述（同じ記事で 20 点の差が出た記録）・安全の項目（プロンプトインジェクション・Claude Code の権限設定の例）・配布の形と費用・Lv.1 の最短手順・既存環境への導入の注意・機械計測が対応する拡張子（.mdx・.markdown も Markdown 扱いに）を追加