結論：アフィリエイト記事のPR表記は、テンプレを1回作れば JSONに is_pr: true を1行追加するだけで全自動表示できます。
- ステマ規制（景品表示法5条3項）の対応は2023年10月から全サイト必須
- 当サイトは Claude Code に依頼して 30分でテンプレ化が完了
- 既存記事はゼロ影響、PR記事だけバッジと通知ボックスが自動で出る
「PR表記って、毎記事の頭に手書きで足せばいいんじゃないの?」と思っていました。
私もそう思っていました。でも手書きだと **抜け漏れ事故** の温床になります。今回はテンプレ化して「JSON 1行で出し分け」に振り切った話です。
「ASP申請後にアフィリエイト記事を書くなら、PR表記の運用を仕組みにしておきたい」 — その実装記録を共有します。
誰向けの記事か
これ、誰が読むといいの?
ASP申請を控えている／申請済みで、これからアフィリエイト記事を書き始める非エンジニアの方です。
具体的には次のような方を想定しています。
- もしも・A8 などの ASP に提携済みで、アフィリエイト記事の第1本目を準備している
- PR表記を毎記事の頭に手書きで足すのが「絶対ミスる気がする」と不安
- 静的サイト（Hugo・Astro・自前ジェネレータ等）で運用していて、仕組み化の余地がある
技術解説ではなく、「非エンジニアでも30分で組める運用テンプレ」 に重きを置いています。
なぜ仕組み化が必要なのか:ステマ規制の罰則
そもそも、PR表記って法律で決まってるの?
**2023年10月から景品表示法5条3項（通称ステマ規制）で義務化** されています。違反すると消費者庁から措置命令や課徴金の対象になります。
ステマ規制のポイントを整理するとこうなります。
| 項目 | 内容 |
|---|---|
| 施行日 | 2023年10月1日 |
| 根拠法 | 景品表示法 第5条 第3項 |
| 義務の主体 | 広告主（＝アフィリエイト記事を書く運営者） |
| 違反時の措置 | 措置命令・課徴金（売上の3%）・社名公表 |
| 表記の場所 | 広告である旨が 一般消費者に明瞭に分かる位置 |
⚠️ 重要なのは「表記してあれば良い」ではなく 「一般消費者に明瞭に分かる」 という基準です。記事の最下部に小さく書くだけでは「不明瞭」と判断される可能性があります。
つまり「PR表記をどこに・どんな見た目で出すか」の運用設計が、規制対応の本丸です。
手書き運用が事故る3つの理由
PR表記、毎記事の頭に1行足せば十分じゃない?
やめた方がいいです。私も最初は手書きで考えましたが、3つの落とし穴に気づきました。
実際にシミュレーションして見えた問題点を整理します。
⚠️ 手書きPR表記が事故る理由
- 抜け漏れが必ず起きる — 月10本書けば、1〜2本は表記忘れで規制違反になる
- 記事ごとに表記がバラつく — 「※PR」「【広告】」「※本記事は広告を含みます」など揺れ、信頼性を損なう
- 後から非PR記事と区別できない — どの記事がPRだったか追跡できず、ASP規約違反のリスクも上がる
📌 PR表記は 「フラグで管理して、見た目はテンプレに任せる」 が事故防止の最適解です。手書きはやめましょう。
実装した仕組み:3つの構成要素
具体的に、何を作ったの?
**CSSテンプレ2種 + JSONフラグ1個** の3点セットです。3つだけです。
実際の実装内容を一覧で出します。
| # | 構成要素 | 役割 | 表示場所 |
|---|---|---|---|
| 1 | .pr-badge |
黄色の「PR」バッジ | TOP記事一覧／記事ページ上部 |
| 2 | .pr-notice |
広告含有を明示するボックス | 記事ページ本文の直前 |
| 3 | is_pr: true |
出し分けフラグ（JSON 1行） | posts/{記事}.json |
📌 ポイントは 「CSSは1回書き切り」「JSON 1行で全部スイッチ」 という分業です。記事ごとに HTML を直接書き換える必要がありません。
実装の流れ:4ステップで完成
30分でやったって本当?
Claude Code に「ステマ規制対応のPR表記テンプレを作って」と頼んだだけです。実作業はCSS追加と分岐ロジックの2箇所。
実際の工程はこうなります。
特に時間がかかったのは CSSの色合わせ でした。サイト全体のデザイントークン（黄色系：#fbbf24）と揃えるのに数分使いました。
CSSの中身：見せる「明瞭さ」の作り方
CSSってどんな感じ?
シンプルです。**黄色背景 + 黒文字 + 太字** で、視認性を最優先にしました。
PRバッジ（記事カード／記事ページ上部）はこんな仕様です。
| 項目 | 値 |
|---|---|
| 背景色 | #fbbf24（黄色） |
| 文字色 | #78350f（濃い茶色） |
| 文字 | 「PR」 |
| 太さ | font-weight: 700（太字） |
| 位置 | 日付の隣（同じ行） |
PR通知ボックス（記事本文の直前）はこんな仕様です。
| 項目 | 値 |
|---|---|
| 背景色 | #fffbeb（薄い黄色） |
| 枠線 | #fbbf24（黄色） |
| 文字 | 「本記事には広告（アフィリエイトリンク）が含まれます。」 |
| リンク | プライバシーポリシーへの導線あり |
| 位置 | 記事本文の 直前（タイトルとメタ情報の下） |
⚠️ ステマ規制の「明瞭性」基準を満たすには、記事の先頭付近 に通知を置くのが安全です。最下部や折りたたみ内では不十分と判断されるリスクがあります。
JSON 1行で出し分ける仕組み
記事を書く時、毎回何をすればいい?
JSON に `"is_pr": true` を1行足すだけ。それ以外は普通の記事と同じ書き方です。
実際の運用フローはこうなります。
{
"slug": "claudecode-blog-launch",
"title": "Claude Codeで個人ブログを独自ドメインで立ち上げた話",
"date": "2026-05-08",
"category": "Cloudflare",
"tags": ["Claude Code", "Cloudflare Workers"],
"is_pr": true,
...
}
たったこれだけで、ビルド時に以下が自動で出ます。
- TOP記事一覧の該当カードに PRバッジ
- 記事ページ上部に PRバッジ
- 記事本文の直前に PR通知ボックス
📌 既存記事のJSONに is_pr フィールドがなければ、これまで通り PR要素は一切出ません。完全な後方互換 です。
後方互換のための1行
既存の8記事に影響しないの?
**`is_pr` フィールドがない記事はゼロ影響** です。Pythonの `dict.get("is_pr")` が `None` を返す仕様を利用しました。
実装の核は、ビルドコード内のたった1行です。
{'<span class="pr-badge">PR</span>' if p.get("is_pr") else ''}
これだけで以下が実現できます。
| JSONの状態 | 表示 |
|---|---|
"is_pr": true |
PRバッジ表示 |
"is_pr": false |
表示なし |
| フィールド未指定 | 表示なし（＝既存記事はこれ） |
📌 dict.get() は キーが存在しない時に None を返す Pythonの基本機能。後方互換を破らないテンプレ追加の定番パターンです。
Claude Code への依頼の仕方
Claude Code にはどう頼んだの?
**「やりたいこと」と「やりたくないこと」を両方伝える** のがコツです。後方互換の指定を忘れると既存記事が崩れます。
実際の指示文を簡略化するとこうなります。
ステマ規制対応で、PR表記テンプレを build_blog.py に追加して。
仕様:
- JSONに is_pr: true を持つ記事だけ、TOPカードと記事ページに「PR」バッジを表示
- 記事ページの本文直前に「本記事には広告が含まれます」の通知ボックス
- 通知ボックス内にプライバシーポリシーへのリンクを含める
- CSSは既存デザイントークンに合わせる（黄色系: #fbbf24）
絶対条件:
- is_pr フィールドがない既存記事は完全にゼロ影響
- 既存のCSSや構造を破壊しない（追加のみ）
💡 「絶対条件」のセクションを設けるのが効きます。Claude Code は 明示的に禁止されたこと を強く守ってくれるので、後方互換の崩壊を防げます。
ビルドして確認した3つのチェック
完成してから何を確認した?
3つだけ。これを通せば「規制対応＋既存記事に影響なし」が両立してるか分かります。
実際に確認したチェック項目を残します。
✅ PR表記テンプレ実装後の最終チェック
- PR記事1本に
is_pr: trueを足してビルド → 3箇所（TOP・記事ページ上部・本文直前）に表示されるか - 既存の非PR記事8本を再ビルド → PR要素が1つも混入していないか
- モバイル表示で PR バッジが切れず・通知ボックスが本文を圧迫しないか
このうち2番を飛ばすと、過去記事に意図せずPR表記が出る事故が起きます。「既存記事の表示も確認する」 が事故防止の鉄則です。
公開後にやっておくべきこと
テンプレを作って終わり?
2つだけ、運用を回す前にやっておくと安心です。
1. PRリンクの近くに「アフィリエイトリンクです」と書き添える
通知ボックスは記事の先頭に出ますが、本文中のリンクの直前にも一言添える とより安全です。
👇 もしも経由・楽天市場（アフィリエイトリンク）
これがあると、読者は「このリンクは広告だ」と即座に認識できます。
2. プライバシーポリシーに「広告（アフィリエイトリンク）の利用」を明記
通知ボックスから飛ばす先（プライバシーポリシー）に、アフィリエイトの記載があることを確認します。当サイトでは「項目6：アフィリエイトプログラム」として明記済みです。
⚠️ 通知ボックスがあっても、プライバシーポリシー側に記載がないと 「告知不十分」 と判断されるリスクがあります。両方セットで対応が必須です。
やってよかった3つのこと
今回のテンプレ化で、特に良かったことは?
3つあります。**「規制対応」を「設計」に格上げできた** のが一番大きいです。
✅ PR表記テンプレ化で得た3つの効果
- 規制違反リスクをゼロにできる — 毎記事の手書きが不要、書き忘れの事故が構造的に起こらない
- 運用負担がゼロになる — JSON 1行追加だけで、CSS や HTML を触る必要がない
- 将来の規制強化にも1箇所修正で対応できる — 表記文言や色を変える時、CSSとビルドコードの2箇所だけ書き換えれば全記事に反映
特に3番は、長期運用の前提として重要です。規制は今後も追加・変更される可能性が高い ので、1箇所修正で全反映できる作りにしておくと安心です。
やる前に絶対知っておくべき注意点
始める時の落とし穴ってある?
2つだけ、絶対知っておいてください。
1. PR表記は「広告主が誰でも」必須
「自分は広告主じゃないからPR表記いらない」と思いがちですが、アフィリエイト記事を書く運営者＝広告主 です。
| 立場 | PR表記の必要性 |
|---|---|
| アフィリエイト記事を書くブロガー | 必須 |
| 企業から依頼を受けたインフルエンサー | 必須 |
| 自社商品を自社サイトで宣伝 | 不要（明らかに自社広告のため） |
| 商品レビュー（広告料なし） | 不要 |
📌 「広告料が発生する関係性」がある時点で、PR表記の対象 になります。アフィリエイトリンクは全部対象です。
2. 表記の場所と見た目に注意
ステマ規制は 「明瞭に分かる」 が基準です。次のような表記は 不十分 と判断されるリスクがあります。
| 不十分とされる例 | 理由 |
|---|---|
| 記事の最下部に小さく「※PR」 | 読者が気づかない位置・サイズ |
| ハッシュタグ内に「#PR」混入 | 他のタグに紛れて視認性低い |
| 折りたたみメニュー内に記載 | 開かないと見えない |
| グレーで薄く表示 | 視認性が低い |
当サイトは 黄色背景＋黒文字＋記事先頭 で、消費者庁ガイドラインの「明瞭性」基準を満たす設計にしました。
学んだ3つのこと
今回の実装で得た一番の学びは?
PR表記は **「義務」じゃなく「設計」** だ、ということです。仕組みにすると運用が一気に楽になります。
✅ PR表記テンプレ化で学んだ3つのこと
- 手書きは規制違反のもと — 毎記事の手作業はミスを構造的に生む、フラグ管理に振り切るのが正解
- 後方互換は1行で守れる —
dict.get()一発で既存記事への影響をゼロにできる - 30分の初期投資で365日の運用を守れる — 一度テンプレ化すれば、規制が強化されても1箇所修正で対応可能
最後に:自分の思い
これからアフィリエイト記事を書く非エンジニアに、何を伝えたい?
**「PR表記を毎記事手で書くな」** ということです。1記事目を書く前に、テンプレを30分で作ってください。
非エンジニアの自分は、ASP申請が通った時、最初に思ったのが「PR表記、毎記事の頭に手で書くのか…」でした。
しかし Claude Code に「ステマ規制対応のテンプレを作って」と頼んだら、30分でCSSと分岐ロジックが揃って、JSON 1行で出し分けできる仕組みが完成しました。
やる前は「面倒な義務」だったものが、やってみたら「設計の一部」になりました。
毎記事の頭に「※PR」と手書きする運用と、JSON に is_pr: true を足すだけの運用 — どちらが長期で事故らないかは明らかです。
💡 ステマ規制対応は 「アフィリエイト記事の1本目を書く前」 に仕込むのがベストタイミングです。記事を10本書いてから直すのは、手書きで足すより遥かにコストが高くなります。
「規制対応＝面倒な作業」と思っていた時期に、自分自身に伝えたい記事になりました。
ルールは守るものですが、運用は仕組み化できます。
これからも、「収益化の足元を仕組みで固める」 動きを続けていきます。
この記事のシリーズ：ブログ立ち上げ全工程・プライバシーポリシー作成 と合わせて読むと、「非エンジニアがブログを安全に収益化する全体像」が見えます。
この記事も Claude Code に書いてもらいました。「結論先行・一文60文字以内・数字を使う・誰向けか明確・自分の思いで締める」の5点を意識した版です。