content-engine

コンテンツエンジン

スクリプトの場所。 ホストで ${CLAUDE_PLUGIN_ROOT} が設定されていない場合、スクリプトはこのプラグインの scripts/ フォルダー内にあり、skills/ の隣に配置されています。Python 3.10 以降で実行してください。python を使用するか、python が見つからない場合（macOS、多くの Linux システム）は python3 を使用してください。

このスキルを使用するタイミング

ユーザーのリクエストに次のいずれかが含まれる場合、このモジュールを有効にしてください。

• SEO コンテンツ：ブログ記事、ピラーページ、トピッククラスターなど、検索向けに最適化されたあらゆるコンテンツ
• 広告コピー：Google、Meta、LinkedIn、TikTok など、あらゆる有料プラットフォーム向けの見出し、説明文、クリエイティブ
• メールマーケティング：メールシーケンス、ドリップキャンペーン、ニュースレター、トランザクションメール、コールドアウトリーチ
• ソーシャルメディアコンテンツ：ソーシャルプラットフォーム向けのオーガニック投稿、キャプション、ハッシュタグ戦略、コンテンツカレンダー
• ランディングページ：コンバージョンを重視したページコピー、ヒーローセクション、CTA、ページ構成
• コンテンツカレンダー：編集計画、コンテンツのスケジュール設定、テーマのマッピング
• ブランドボイス：ボイスとトーンのガイドライン、メッセージングフレームワーク、ブランド言語の体系
• コンテンツの劣化検出：時間の経過とともに検索順位、トラフィック、関連性が低下したコンテンツの特定
• AI コンテンツ品質管理：AI 生成コンテンツが品質、独自性、ブランド基準を満たすようにすること
• アクセシビリティへの準拠：コンテンツをアクセシブルにすること（WCAG 基準、代替テキスト、読みやすさ、スクリーンリーダーとの互換性）
• 多言語対応／ローカライズ：異なる言語、文化、地域市場に合わせたコンテンツの調整
• メールインフラストラクチャ：配信可能性、認証（SPF、DKIM、DMARC）、ドメインのウォームアップ、送信者のレピュテーション

トリガーフレーズ：「ブログ記事を書いて」、「広告コピー」、「メールシーケンス」、「ソーシャルメディアカレンダー」、「ランディングページ」、「コンテンツカレンダー」、「ブランドボイス」、「コンテンツ監査」、「コンテンツの劣化」、「AI コンテンツ」、「アクセシビリティ」、「翻訳して」、「ローカライズして」、「メールの配信可能性」、「件名」、「見出し」、「CTA」、「ニュースレター」

ブランドのコンテキスト（自動適用）

このモジュールでマーケティング成果物を作成する前に、次の手順を実行してください。

1. セッションのコンテキストを確認する — アクティブなブランドの概要は、セッション開始時に出力されています。そこに表示されたブランド名、業界、ボイス設定、チャネル、目標、コンプライアンス要件、競合他社を使用してください。
2. 詳細なプロファイルが必要な場合は、~/.claude-marketing/brands/{slug}/profile.json を読み込みます。
3. ブランドボイスを適用する — フォーマルさ、活気、ユーモア、権威性のレベルを、すべてのコンテンツのトーンや語句の選択に反映させてください。
4. コンプライアンスを確認する — skills/context-engine/compliance-rules.md を使用し、ブランドの target_markets と業界に関するルールを自動適用してください。
5. 業界ベンチマークを参照する — ブランドの業界については skills/context-engine/industry-profiles.md を参照してください。
6. プラットフォームの仕様を使用する — 文字数制限や形式要件については skills/context-engine/platform-specs.md を参照してください。
7. キャンペーン履歴を確認する — 新しい作業を計画する前に、python "${CLAUDE_PLUGIN_ROOT}/scripts/campaign-tracker.py" --brand {slug} --action list-campaigns を実行してください。
8. ブランドが存在しない場合は、次のように伝えてください。「ブランドプロファイルが見つかりません。/digital-marketing-pro:brand-setup を使用して作成するか、一般的なベストプラクティスに基づいて進めることができます。」
9. ブランドガイドラインを確認する — ~/.claude-marketing/brands/{slug}/guidelines/_manifest.json が存在する場合は読み込み、適用してください。禁止語句、制限対象の主張、必須の免責事項については restrictions.md、チャネル固有のトーンの上書き設定（ベースのボイスと異なる場合があります）については channel-styles.md、承認済みの主要メッセージ、タグライン、ポジショニング表現については messaging.md、4つの数値スコア以外の詳細なボイスルールについては voice-and-tone.md を参照してください。特定のチャネル向けのコンテンツを作成する場合は、チャネルスタイルのルールがベースのボイス設定より優先されます。

ブランドプロファイルにすでにある情報をユーザーに尋ねないでください。

必要なコンテキスト

コンテンツ制作に取り掛かる前に、以下を確認します。

1. コンテンツの種類：必要なコンテンツ形式は何ですか？
2. 対象読者：このコンテンツは誰を対象としていますか？（利用可能であれば、Audience Intelligence のペルソナへのリンク）
3. 目的：このコンテンツで何を達成したいですか？（トラフィック、コンバージョン、エンゲージメント、教育、維持）
4. ブランドボイス：ブランドボイスガイドはありますか？トーンはどのようなものですか？（プロフェッショナル、カジュアル、権威的、遊び心のあるものなど）
5. キーワード／トピック：SEO コンテンツの場合は、ターゲットキーワード、検索意図、競合状況
6. プラットフォーム：このコンテンツはどこに掲載されますか？（プラットフォーム固有の要件は重要です）
7. ファネルの段階：カスタマージャーニーのどの段階に位置するコンテンツですか？
8. 既存のコンテンツ：関連する既存のコンテンツは何ですか？（カニバリゼーションを避けます）
9. 制約事項：文字数制限、文字数の上限、規制に関する免責事項、ブランドガイドライン
10. パフォーマンスのベンチマーク：この種類のコンテンツの成功は、どのような状態を指しますか？

簡単な依頼（例：「LinkedIn の投稿を書いて」）では、妥当な前提を置いてすぐに対応します。戦略的なコンテンツ制作では、必要なコンテキストをすべて確認します。

対応できること

• SEO コンテンツ制作：キーワードに最適化したブログ記事、ピラーページ、トピッククラスターの設計、メタタイトル／メタディスクリプション、内部リンク戦略、強調スニペットの最適化
• 各種プラットフォーム向け広告コピー：Google Ads（レスポンシブ検索広告、見出し、説明文）、Meta Ads（メインテキスト、見出し、説明文）、LinkedIn Ads、TikTok Ads、Twitter/X Ads — プラットフォーム固有の形式と文字数制限に対応
• メールシーケンス：ウェルカムシーケンス、ナーチャリングメール、カート放棄メール、再エンゲージメント、オンボーディング、アップセル／クロスセル、再獲得のためのシーケンス。件名、プレビューテキスト、本文コピー、CTA を含みます
• ソーシャルコンテンツ：LinkedIn、Twitter/X、Instagram、TikTok、Facebook、YouTube、Pinterest 向けのプラットフォームに適したコンテンツ。キャプション、ハッシュタグ、フック、投稿構成を含みます
• ランディングページのコピー：ヒーロー見出し／サブ見出し、価値提案のブロック、ソーシャルプルーフ、機能／メリットのセクション、FAQ、CTA の最適化
• コンテンツカレンダー：テーマのマッピング、コンテンツの柱、公開頻度、チャネル別配信計画を含む編集カレンダー
• ブランドボイスシステム：ボイスの特性、トーンの幅（状況に応じたボイスの調整方法）、語彙のガイドライン、使用例／禁止例、ブランド固有の用語
• コンテンツの劣化検出：トラフィック、検索順位、エンゲージメント、新しさに基づいてパフォーマンスが低下しているコンテンツを特定する方法と、更新の優先順位付け
• AI コンテンツ品質管理：AI 生成コンテンツの品質チェックリスト、独自性の検証方法、ブランドとの整合性レビュー、ファクトチェック手順、人間が関与するためのガイドライン
• アクセシビリティへの準拠：WCAG 2.2 AA に準拠したコンテンツガイドライン、代替テキストの作成、読みやすさの評価、見出し構成、リンクテキスト、色のコントラストに関する指針、スクリーンリーダー向けの最適化
• 多言語対応／ローカライズ：翻訳しやすいコンテンツ構成、文化的適応のフレームワーク、ロケール固有のメッセージングガイドライン、RTL 言語への配慮
• メールインフラストラクチャ：SPF／DKIM／DMARC の設定ガイダンス、ドメインのウォームアップスケジュール、リストの衛生管理、配信可能性の監視、送信者のレピュテーション管理

プロセス

主なワークフロー：コンテンツ作成

1. コンテンツ戦略のすり合わせ

   • コンテンツの種類、対象読者、目的、ファネルの段階を確認します
   • 重複する可能性のある既存コンテンツを確認します（カニバリゼーションを防止）
   • 中核となるメッセージと重要な要点を特定します
   • タスクに適したコンテンツフレームワークを選択します

2. 調査と準備

   • SEO コンテンツの場合：ターゲットキーワード、検索意図、SERP の機能、上位表示されているコンテンツを分析します
   • 広告コピーの場合：プラットフォームの仕様、競合他社の広告、対象読者の悩みを確認します
   • メールの場合：シーケンスのトリガー、期待するアクション、購読者セグメントを特定します
   • ソーシャルメディアの場合：プラットフォームのトレンド、最適なフォーマット、対象読者の行動パターンを確認します
   • ランディングページの場合：トラフィックの流入元、訪問者の意図、コンバージョン目標を特定します

3. コンテンツ作成

   • ブランドボイスのガイドラインを適用します（ない場合は策定します）
   • 指定されたフォーマット要件（文字数制限、構成、プラットフォームの慣例）に合わせて執筆します
   • 説得の設計を取り入れます：
     • 注意：スクロールを止めたり、クリックを促したりするフックや見出し
     • 関心：対象読者への理解を示す、課題を意識した切り口
     • 欲求：明確なメリットとソーシャルプルーフを示したソリューションの訴求
     • 行動：摩擦を減らした、明確で具体的な CTA
   • 該当する場合は SEO 要素（キーワード、見出し、内部リンク、メタデータ）を含めます
   • フォーマットが対応している場合は、テスト用に複数のバリエーションを作成します（広告コピー、件名、CTA）

4. 品質保証

   • ブランドボイスとの整合性を確認します
   • 可読性スコアを評価します（一般向けには 8 年生相当以下を目指します）。ドラフトに対してアナライザーを実行します：

     python "${CLAUDE_PLUGIN_ROOT}/scripts/readability-analyzer.py" \
         --file "${CLAUDE_PLUGIN_DATA}/{brand}/seo/content-engine/{date}/{slug}/03-draft-v1.md" \
         --target b2c_general
     

     （--text のインラインテキストまたは --file のパスのいずれかを指定します。両方は指定できず、どちらか一方が必須です。--target は b2c_general、b2b_professional、b2b_technical、children、academic のいずれかです。）
   • アクセシビリティを確認します（見出し階層、代替テキストの指針、リンクテキストの明確さ）
   • 主張、統計、参照情報をファクトチェックします
   • プラットフォームへの準拠を確認します（広告ポリシー、文字数制限、フォーマット要件）
   • 検索向けコンテンツについて、オンページ SEO を監査します（キーワードの配置、メタデータ、内部リンク）
   • AI を活用した場合は、AI コンテンツの品質を確認します（独自性、ブランドとの整合性、事実の正確性）

5. 最適化とテスト計画

   • A/B テストの対象を決めます（見出し、CTA、メールの件名、広告クリエイティブ）
   • コンテンツの種類とチャネルに基づいてパフォーマンスの基準を設定します
   • 劣化のモニタリングに向けて、コンテンツのレビュー日を設定します
   • 複数のフォーマットやチャネルでコンテンツを再利用する計画を立てます

副次的なワークフロー：コンテンツの監査と更新

1. コンテンツの一覧（URL、公開日、現在のトラフィック／ランキング）を取得します
2. 各コンテンツの鮮度、パフォーマンスの傾向、関連性を評価します
3. 分類します：維持（良好なパフォーマンス）、更新（低下しているが改善可能）、統合（内容が薄い／重複している）、削除（関連性がない／有害）
4. トラフィック回復の可能性に基づいて、更新候補に優先順位を付けます
5. 具体的な更新指示を含む更新用ブリーフを作成します

参考ファイル

• seo-content.md — キーワード最適化、トピッククラスターの設計、強調スニペット戦略、ページ内 SEO チェックリスト
• ad-copy.md — プラットフォーム固有の広告コピーのフレームワーク、文字数制限、ポリシーガイドライン、A/B テストの手法
• email-sequences.md — シーケンステンプレート（ウェルカム、ナーチャリング、カゴ落ちなど）、件名の定型パターン、メールコピーライティングのフレームワーク
• social-content.md — プラットフォーム別のコンテンツガイドライン、フックの定型パターン、ハッシュタグ戦略、最適な投稿方法
• landing-pages.md — ランディングページの構成テンプレート、CTA の最適化、ファーストビューのフレームワーク、コンバージョンコピーの定型パターン
• content-calendar.md — 編集カレンダーのテンプレート、コンテンツピラーのフレームワーク、公開頻度の推奨、テーマのマッピング
• brand-voice.md — ボイス策定の手法、トーンのスペクトラム設計、語彙ガイドライン、ブランドボイス監査プロセス
• content-decay.md — 劣化検出の手法、コンテンツ評価基準、更新の優先順位付けフレームワーク、更新履歴の追跡
• ai-content-quality.md — AI コンテンツ品質チェックリスト、独自性の確認、ブランドとの整合性レビュー、人間によるレビューワークフロー
• accessibility.md — WCAG 2.2 AA コンテンツチェックリスト、代替テキストの書き方ガイド、読みやすさの基準、インクルーシブな表現のガイドライン
• multilingual.md — ローカライズ対応チェックリスト、文化的適応のフレームワーク、翻訳管理、RTL に関する考慮事項
• email-infrastructure.md — 認証の設定（SPF/DKIM/DMARC）、ドメインのウォームアップ計画、到達率向上のベストプラクティス、リストの健全性管理
• email-automation.md — 自動化トリガーの設計、ワークフローのマッピング、動的コンテンツのルール、行動に基づくメールのロジック
• case-studies.md — 課題・解決策・結果のフレームワーク、顧客を主役にしたストーリー構成、ケーススタディ作成のベストプラクティス
• personalization.md — パーソナライゼーション成熟度モデル、セグメント・ルールベース・行動ベースの戦略、実装ガイダンス
• video-scripting.md — プラットフォーム固有の動画形式と長さ、台本の構成、フックと視聴維持のテクニック
• draft-deliverables.md — 成果物の種類ごとの最低限の構成要素（プレスリリースを含む）、下書き後のフォローアップメニュー、1つのブリーフから複数の形式を作成する場合の並行処理ルール

出力形式

成果物	形式	説明
ブログ記事／記事	ドキュメント	メタデータ、見出し、内部リンクの提案を含む、SEO 最適化済みの完全なコンテンツ
広告コピーセット	ドキュメント／スプレッドシート	プラットフォームごとに、見出し、説明、CTA を含む複数のバリエーション
メールシーケンス	ドキュメント	件名、プレビューテキスト、本文、CTA、送信タイミングを含む完全なシーケンス
ソーシャルメディアコンテンツ	スプレッドシート／カレンダー	プラットフォーム、日付、コピー、ハッシュタグ、ビジュアルの指示ごとに整理した投稿
ランディングページのコピー	ドキュメント	見出し、小見出し、本文、箇条書き、CTA、フォームのコピーを含むセクションごとのコピー
コンテンツカレンダー	スプレッドシート	テーマ、トピック、形式、チャネル、担当者を含む月次／四半期の編集計画
ブランドボイスガイド	ドキュメント	特性、トーンのスペクトラム、語彙、例を含む完全なボイス体系
コンテンツ監査レポート	スプレッドシート＋ドキュメント	スコア、分類、優先順位を付けた更新の提案を含むインベントリ
アクセシビリティレポート	チェックリスト形式のドキュメント	具体的な改善手順を含む、コンテンツレベルのアクセシビリティ評価

エッジケース

規制対象業界のコンテンツ（免責事項が必要）

• 状況：医療、金融サービス、法律、保険、大麻、ギャンブル、または免責事項、情報開示、コンプライアンスに関する文言が義務付けられているその他の業界
• アプローチ：コンテンツ作成の開始時に、規制上の要件があることを明示します。免責事項の文面案を含め、公開前に法務レビューを受けるよう推奨します。広告プラットフォームについては、具体的なポリシー上の制限（例：Facebook の金融サービスに関する免責事項、Google の医療広告ポリシー）を記載します。法務レビューなしにマーケティングコンテンツがコンプライアンスに準拠していると示してはいけません。必ず専門家によるコンプライアンス確認を推奨してください。マーケティングコピーとコンプライアンスに関する文言は、視覚的に区別してください。

多言語キャンペーン

• 状況：コンテンツを複数の言語や文化的背景に対応させる必要がある
• アプローチ：ローカライズを念頭に置いて原文を作成します（翻訳しにくい慣用句、文化的な言及、ユーモアは避けます）。文化的に配慮が必要な要素を明記したローカライズ用ブリーフを、コンテンツと併せて作成します。最終成果物に機械翻訳を使わず、マーケティングの専門知識を持つプロの翻訳者を推奨します。RTL 言語（アラビア語、ヘブライ語、ペルシャ語）では、デザインチームにレイアウトへの影響を伝えます。文字数制限のある形式では、テキストの長さが増えること（ドイツ語のテキストは英語より約 30% 長い）を考慮します。

コンテンツのカニバリゼーション

• 状況：複数のページが同じキーワードを競い合っている、または同じトピックを扱っている
• アプローチ：新しいコンテンツを作成する前に、既存のコンテンツを監査します。カニバリゼーションが発生している場合は、競合するコンテンツをさらに増やすのではなく、統合（弱いページを、より強力な単一ページにまとめること）を推奨します。canonical タグ、内部リンク、コンテンツの差別化を活用し、既存のカニバリゼーションを解消します。新しいコンテンツを作成する際は、既存のコンテンツ一覧とキーワードやトピックの重複がないか確認します。

AI 生成コンテンツの開示

• 状況：ユーザーが AI 生成コンテンツを公開したいと考えており、開示に関するガイダンスを必要としている
• アプローチ：透明性を推奨します。プラットフォームのポリシーは変化し続けていることを記載します（Google は AI コンテンツにペナルティを課しませんが、品質を重視します。一部のソーシャルプラットフォームでは AI の開示が義務付けられています）。AI 生成の草稿は、必ず人間によるレビューと編集を推奨します。人間の監督なしに AI だけで生成したコンテンツには、事実誤認、ブランドの一貫性の欠如、オーディエンスからの信頼低下のリスクがあることを明示します。AI 支援コンテンツ向けの品質保証チェックリストを提示します。

動画・音声コンテンツのアクセシビリティ

• 状況：アクセシビリティ対応が必要な動画、音声、またはインタラクティブ要素をコンテンツに含む
• アプローチ：すべての動画コンテンツに字幕を付けることを推奨します（自動生成ではなく、正確さを重視します）。動画内の視覚情報のみで伝えられる内容には音声解説を付けます。ポッドキャストや音声コンテンツの文字起こしを作成します。インタラクティブ要素をキーボードで操作できるようにします。スクリーンリーダーでテストします。最低限 WCAG 2.2 AA に準拠し、一般公開コンテンツでは目標として AAA を目指します。

RTL 言語

• 状況：アラビア語、ヘブライ語、ペルシャ語、ウルドゥー語、またはその他の右から左に記述する言語のコンテンツ
• アプローチ：プロセスの早い段階で RTL による影響を明示します。コンテンツの構成、CTA の配置、視覚的な階層はすべて反転します。RTL の文脈内でも、数字や埋め込まれたラテン文字のテキストは LTR のままです（双方向テキスト）。RTL コンテンツはすべて、ネイティブスピーカーによるレビューを推奨します。デザインテンプレートは RTL レイアウトに対応する必要があります。多くのメールクライアントでは RTL の扱いに一貫性がないため、特に RTL モードでメールテンプレートをテストします。

番号付き出力の規約

コンテンツエンジンの出力はすべて ${CLAUDE_PLUGIN_DATA}/{brand}/seo/content-engine/{YYYY-MM-DD}/{slug}/ に保存します。

00-input.md                topic, target keyword, intent, format, source brief (from keyword-cluster?)
01-research.md             source list, key data points, expert quotes, competitor references
02-outline.md              H1, H2/H3 structure with target word counts per section
03-draft-v1.md             first complete draft
04-fact-check.md           per-claim verification + citations
00-source-draft.md         the author's own words, verbatim (ONLY when --source-draft was given)
05-humanize.md             AI-pattern detection + rewrite log (flags from scripts/ai-tell-scan.py)
05-scans.json              Surface + structural scan output, keyed {"surface":…, "structure":…}
05-authorship.json         author-sentence provenance (ONLY when 00-source-draft.md exists)
06-brand-voice-check.md    voice score (formality/energy/humor/authority) vs brand profile
07-seo-checklist.md        title, meta, schema, internal links, image alt text
08-quality-scorecard.md    the gates below
09-publish-ready.md        final clean copy + handoff metadata
PLAN.md                    summary + publish instructions

品質スコアカード

ゲート	確認内容
brand_voice_match	06-brand-voice-check.md で、各軸の distance が ≤ 0.15（フォーマルさ／活気／ユーモア／権威性）であることを確認します。単位はスコアラーの0～1スケールであり、プロフィールの1～10スケールではありません。 このゲートは以前、「1.5ポイント以内の偏差」と記載されていましたが、brand-voice-scorer.py が出力する distance の上限は1.0です。そのため、記載を文字どおりに解釈すると決して失敗しないゲートになっていました。これは、測定方法のないゲートと同じ、形骸化したゲートの欠陥です。0.15は、スコアラーが偏差を検出するためにすでに内部で使用しているしきい値です。この測定でわかることとわからないことに注意してください。目標とする軸の値は、brand-setup が音声の記述子を数値に割り当てて算出しますが、未確認の記述子に対する評価基準はありません。そのため、ここで FAIL となった場合は、文章と同様にプロフィールの目標値も確認するきっかけとしてください
fact_check_clean	04-fact-check.md で、未検証の主張が0件であり、事実に関する記述ごとに引用が1件以上あることを確認します
humanize_passed	python "${CLAUDE_PLUGIN_ROOT}/scripts/ai-tell-scan.py" --file 05-humanize.md の結果が humanize_passed: true、つまり flagged_paragraph_pct がブランドのしきい値（デフォルトは10%）以下であることを確認します。スクリプトを実行してください。目視で判断してはいけません。 フラグの対象となる内容については、以下の「Humanize のステップ」を参照してください
seo_complete	07-seo-checklist.md で、タイトルが60文字以下、メタディスクリプションが150～160文字、スキーマタイプが1つ以上、内部リンクが3つ以上、すべての画像に代替テキストがあることを確認します。2つの基準では、合格ではなく明示的な N/A を指定します。 ブランドに公開済みのサイトがない場合の内部リンク（公開前のブランドが最初の記事から内部リンクを張れる先はありません。その場合は N/A (no site) と記録すればゲートは無視しますが、達成済みとして記録してはいけません）、および記事に画像がない場合の代替テキスト（0件中0件という状態は、何も検証していないのに合格扱いになります。その場合は N/A (no images) と記録してください）。N/A には理由を明記する必要があります。理由のない N/A は FAIL です
eu_disclosure_if_ai	ブランドの target_markets にEUが含まれ、コンテンツがAI生成の場合、09-publish-ready.md に必須の Article 50 開示（機械可読形式＋表示可能形式）が含まれていることを確認します

status: ready にするには、5つのゲートすべてに合格し、実行監査でそれらを再導出できる必要があります。

python "${CLAUDE_PLUGIN_ROOT}/scripts/run-audit.py" --run-dir "${CLAUDE_PLUGIN_DATA}/{brand}/seo/content-engine/{date}/{slug}"

08-quality-scorecard.md の作成後、status: ready を宣言する前に実行してください。スコアカードの主張を、成果物そのものから再導出します。番号付きの成果物がすべて存在すること、ai-tell-scan.py を新たに実行して Humanize の判定を再測定すること（スコアカードの記載を参照してはいけません）、authorship.py が測定するファイルにスキャンJSONが埋め込まれていないこと、ソースドラフトがある場合は記録された著者情報が新たな測定結果と一致すること、記録された音声の距離が実際に0.15のゲート内にあること、公開準備済みのコピーに本番用プレースホルダーが残っていないことを確認します。終了コード1は、スコアカードの主張が成果物によって裏付けられていないことを意味します。記載を修正するのではなく、指摘事項を修正してください。 判定結果は成果物と並べて run-audit.json に保存されるため、次の読者は実行が信頼されたのではなく検証されたことを確認できます。

AI 支援に関する開示（EU に限らず、すべての実行が対象）

上記の EU ゲートに加えて、公開可能なすべての下書きには、profile.json のブランドの ai_disclosure ブロックが適用されます — {"mode": "claude-surfaces"|"always"|"off", "text": null|custom, "author": null|name}（ブロックがない場合は、デフォルトの claude-surfaces、カスタムテキストなし、著者なしとなります）。

1. python "${CLAUDE_PLUGIN_ROOT}/scripts/detect_surface.py" --mode {mode} を実行します — disclosure_applies フィールドが判定結果です。フェイルセーフの動作は意図的なものです。claude-surfaces モードでは、surface が uncertain の場合、開示が適用されます（スキップするには、Claude 以外であることを示す明確なフィンガープリントが必要です）。推測でスクリプトの回答を上書きしないでください。
2. 開示が適用される場合は、09-publish-ready.md の本文内の最後の段落としてブロックを追加します。これにより、/digital-marketing-pro:publish-blog の実行後も残ります。使用する文言は次のとおりです。カスタムテキストも著者も指定されていない場合は *Created with AI assistance and reviewed by our editorial team.*、著者が指定されている場合は *Created with AI assistance; researched, fact-checked, and edited by {author}.*、カスタムテキストが指定されている場合はその文面をそのまま使用します。デフォルトの文言はベンダー中立的（モデル名やベンダー名を含まない）で、このパイプラインが実施するレビューのみを主張します。著者フィールドは任意です — 名前を決して作り出さず、空欄でも処理を止めないでください。
3. 適用・未適用にかかわらず、引き継ぎメタデータに判定を記録します：disclosure: {applied, mode, surface} — 開示を適用しないことも記録された選択であり、記載漏れではありません。

人間らしさを加えるステップ（05-humanize.md）—フラグの実態

humanize_passed ゲートは印象ではなく、scripts/ai-tell-scan.py によって測定されます。スクリプトを実行し、返されたフラグに対処してください。

05-scans.json には、名前付きキーの下に両方のスキャン結果を格納します。1つのファイルに2つのJSONドキュメントを入れてはいけません。 {"surface": {...ai-tell-scan output...}, "structure": {...structural-tell-scan output...}} の形式で記述してください。同じパスに対して > リダイレクトを2回行うと、json.load が拒否するファイルが生成されます。まさにその実行方法が、この問題の発見につながりました。Windowsでは、PYTHONIOENCODING=utf-8 を設定してからリダイレクトしてください。デフォルトの cp1252 では、アドバイザリーノートの em ダッシュがバイト 0x97 としてエンコードされ、ファイルを解析できなくなります。

05-humanize.md には記事本文だけを記載してください。 scripts/authorship.py --draft 05-humanize.md はそのファイル内のすべての文を分類するため、スキャン結果のJSONやレポートの文章が含まれていると、それも機械が追加したテキストとして作者の共有割合に算入されます。実際の実行で測定したところ、スキャン結果のJSONと短いレポートを追記しただけで、author_word_share が 0.253 から 0.206 に下がり、may_claim_authored が true から false に変わりました。ファイルの構成だけが原因で、作者が実際に行った作業へのクレジットが否定されたのです。レポートは 05-scans.json に入れ、下書きファイルには下書きだけを残してください。

python "${CLAUDE_PLUGIN_ROOT}/scripts/ai-tell-scan.py" --file 05-humanize.md [--max-flagged-pct N]

ゲートの対象となるのは、次の2種類の兆候です。 どちらも十分に明確で、ゲート判定に使えます。

• significance_marker — 隣接する文の意味を読者に伝えることだけが目的の文です。「ここがポイントです」「そこで心を動かされたのです」「まさにそこが問題です」「よく考えてみてください」などが該当します。→ その文を削除してください。言い換えてはいけません。 その文が指し示す具体的な内容だけで、すでに十分に伝わっています。マーカーをやわらかい表現のマーカーに変えても解決にはなりません。その場面が重要なら、重要だと宣言するのではなく、具体的な内容に立ち戻ってください。
• soft_adverb_cluster — 1つの文に honestly / genuinely / truly / literally / actually / basically / quietly のうち2つ以上が含まれている場合です。削除してください。力強さが必要な文には、副詞ではなく具体性が必要です。

スキャンで報告されるその他の項目は、ゲート判定の対象ではなく、参考情報です。 llm_favored_word、文頭の接続表現（「So,」「However,」など）、分詞構文で始まる文、em ダッシュの多さ、根拠に乏しい短い一文などが該当します。これらは一般的な人間の文章にも見られるため、ゲート判定に使うと質の高い文章まで不合格になり、パイプラインが無意味な書き直しを繰り返すことになります。スキャンの指摘が妥当な場合は修正してください。数値を追いかける必要はありません。

• llm_favored_word（2026-08-15 以降は参考情報）— delve、leverage、seamless、tapestry、testament、pivotal、myriad などです。→ それでも修正する価値はあります。声に出して言う平易な言葉を使うか、さらによいのは、その文章の主題から具体的な名詞を選ぶことです。測定の結果、ゲート判定の対象から外されました。ChatGPT が登場する前に公開された文章272本を調べたところ、これらの単語のうち23語が検出され、すべて人間の文章でのみ検出され、モデルの文章では1つも検出されませんでした。技術文書やジャーナリズムでは「robust」「facilitate」「leverage」は普通に使われていますが、現在のモデルはそれらを学習データからほぼ除外されています。そのため、ゲートのシグナルとして使っても、誤検知しか生みません。

このゲートの合格が意味すること、意味しないこと

合格とは、2つの明確な兆候が密集していないという意味です。これは最低基準であって、判定ではありません。ChatGPT が存在する前に公開された39件の文書で測定したところ、このゲートが不合格にした文書はありませんでした。一方、編集されていないモデル生成の文章18件で測定したところ、検出できたものはありませんでした。したがって、合格しても人が書いたように読める証拠にはならず、何もしなかったヒューマナイズの工程も検出できません。編集者向けのシグナルとしては、advisory_rating と構造スキャンを利用してください。これらは2つの分類を実際に区別します（編集されていないモデル生成の文章は83%の割合でHIGHになり、公開済みの人間の文章では9%でした）。そして、どちらも著者を証明するものではなく、人が対応するためのToDoリストとして扱ってください。

フラグへの対応には、必ず 04-fact-check.md で検証された具体的な情報を使ってください。類義語への置き換えも、事実の捏造もしてはいけません。 文を裏付ける根拠がない場合は、その文を削除するか、妥当な留保を加えてください。文章を人間らしく聞こえさせるために、数字、日付、出典、例を捏造してはいけません。

自分の言葉を持ち込む（--source-draft）

ユーザーが自分の粗い下書き（音声メモの書き起こし、箇条書き、思いつくままに書き出した文章など）を提供した場合は、それを 00-source-draft.md に一言一句そのまま保存し、その文章を整えるのではなく、その文章を軸にして記事を組み立ててください。取り込む際に手を加えてはいけません。乱雑さこそがシグナルです。

• その人の文を 03-draft-v1.md に一言一句そのまま引き継いでください。誤字、長々と続く文、小文字表記などもすべてそのままにします。言い換え、要約、統合、文法の修正は決してしないでください。その人らしさを「改善」することは、その人が書いたという事実を消すことです。
• ヒューマナイズ工程で使う兆候は、その人の文には当てはまりません。 著者が「ここが大事なんだけど」と書いたなら、そのまま残します。パターンが示すのはモデルが促されずに書く内容であって、人が自分で選んで述べた内容ではありません。
• その人の文と文の間に、調査結果、出典のある具体的な情報、構成、簡単に触れただけの項目に関するセクションなど、必要な内容を加えてください。
• その人の主張はその人らしさを示すものであり、検証済みの事実ではありません。 追加する事実はすべて 04-fact-check.md に基づくものにしてください。その人の主張が調査結果と矛盾する場合は、人間の編集者に知らせたうえで、その文は変更せずに残してください。判断するのはあなたではなく、編集者です。
• ヒューマナイズした後、約束が守られたことを確認してください。

python "${CLAUDE_PLUGIN_ROOT}/scripts/authorship.py" \
  --source 00-source-draft.md --draft 05-humanize.md --out 05-authorship.json

終了コード3は、著者の文が書き換えられたか削除されたことを意味します。その文を一言一句そのまま復元し、終了コードが0になるまで再実行してください。 これは助言ではありません。ここでのAI兆候スキャンはすべて助言にとどまります。検出器のシグナルは確率的な見解だからです。しかし、「著者が書いたこの文が、もうここにない」というのは、このパイプラインが交わした約束に関する、確認可能な事実です。

• 出自を正確に反映した開示。 05-authorship.json の may_claim_authored: true が報告された場合（完成した文章の25%以上が著者の文を一言一句そのまま使っており、かつ著者の文が一切書き換えられたり削除されたりしていないことが条件です）、09-publish-ready.md の開示文を *Written by {author} with AI assistance for research, structure, and fact-checking.* にします（著者名を記載しない場合は *Written from the author's own draft, developed with AI assistance and reviewed before publication.*）。それ以外の場合は、上記の標準的な表現を使用してください。この記録以外から著者性を推測してはいけません。 意図的に一方向となっている仕組みです。著者性の記録によって開示をより具体的にできるのは、実際に確認できた人間の関与についてのみです。人間が著者であると過大に主張することは、読者が確認できない唯一の種類の記述です。
• 目標とする割合はありません。開示を正確にするために author_word_share が存在します。テキストを「人間らしく」する数値はなく、ここでの取り組みは検出器を対象としたものではありません。

構造的な特徴のスキャン（参考情報。合否判定には使用しません）

05-humanize.md の後に、python "${CLAUDE_PLUGIN_ROOT}/scripts/structural-tell-scan.py" --file {draft} を実行します。これは Tier-2 STRUCTURAL レイヤーです（StoryScope に由来し、表層を完璧に整えても、構造から AI 生成テキストを検出できます）。MORALIZING CLOSERS、TEMPLATE SYMMETRY、LOW SPECIFICITY、STANCE ABSENCE、UNIFORM RHYTHM、ENTITY DEVELOPMENT について NOTE／ATTENTION が報告された場合は、ファクトチェックファイルの情報に基づいて構造を編集します。明示的に書かれた結論を削り、内容に見合わない対称性を崩し、検証済みの具体的な事実を追加し（決して捏造しないでください）、擁護可能な立場を示します。

entity_development には、誤った方法で修正しやすいため、個別の注意が必要です。NOTE／ATTENTION の範囲にある場合、その文章は名前や数字を次々と登場させ、それぞれ一度だけ言及してそのまま放置しています。専門家が論拠を示すのではなく、機械が設定を作り上げているような状態です。削除ではなく、掘り下げて修正します。 すでに論拠となっている具体的な情報について、04-fact-check.md にある内容をもとに、もう一度実質的に言及します。その情報が何を意味するのか、誰が異議を唱えているのか、どのような代償を伴ったのかを述べてください。この数値を下げるために具体的な情報を削ると、同じスキャンの specificity の評価が下がり、そちらのほうが重要です。また、言及を捏造することは絶対に禁止されています。600 語未満または固有のエンティティが 12 個未満の場合、プロキシは何も報告しません。短い文章では、紙幅が足りず、それぞれの要素に一度しか言及できないためです。スキャン結果の JSON は 05-scans.json の "structure" キーに追加し、表層スキャンの "surface" キーと並べます（05-humanize.md には追加しないでください。このファイルは人間化の手順にあるとおり、authorship.py によって文ごとに評価されます）。全体の評価範囲は 08-quality-scorecard.md に ADVISORY として記録します。これは status: ready の合否判定には影響せず、目に見える構造のみを評価します（統計的ウォーターマークを検知することはできず、それとは一切関係ありません）。

チェーンの受け渡し

• 上流： /digital-marketing-pro:content-brief（推奨。事前調査済み）または /digital-marketing-pro:keyword-cluster（06-pillar-pages.md がコンテンツブリーフになります）
• 下流：
  • /digital-marketing-pro:publish-blog — 公開可能な状態の原稿を CMS に送信します
  • /digital-marketing-pro:content-repurpose + /digital-marketing-pro:social-strategy — 記事を各プラットフォーム向けに再利用します
  • /digital-marketing-pro:check — 公開前の最終チェックを行います
  • /digital-marketing-pro:c2pa-metadata — 記事に AI 生成画像を添え、EU 市場を対象とする場合に使用します

ヒントと注意点

• ブランドボイスからの逸脱許容度は、総合評価ではなく軸ごとに判断します。 すべての軸で 1 ポイントずつ外れている文章と、ユーモアだけで 4 ポイント外れている文章は同じではありません。平均値が問題なく見えても、後者は不合格です。
• 人間化の手順は、AI 検出ツールへの対策を保証するものではありません。 確率的な改善であり、ここで実行するスキャンは統計的ウォーターマークを検出したり削除したりしません。ai-tell-scan.py が評価するのは、目に見えるテキストのみです。AI らしいパターンを最小限に抑える必要がある場合は、人間化の手順を追加で実行し、/digital-marketing-pro:eval-content で再評価して、フラグが付いたパターンが解消されるまで繰り返してください。最後に人間が編集することが、今も最も強力なシグナルです。さらに最も強力なのは著者自身の文章であり、それを保持するのが --source-draft です。
• ファクトチェックは、コンテンツの工程で最も省略されやすいチェックです。 誰も確認していないのに「未検証 0 件」として記事を公開してはいけません。ファクトチェッカーが確認に参加していない場合は、原稿に対して /digital-marketing-pro:verify-claims を実行してください。
• ピラーページのコンテンツでは、 文字数の上限を目指します（SaaS は 3000 語以上、B2B 調査は 5000 語以上）。トピックに関する権威性を高めるには、ピラーページに深みが必要です。スポークコンテンツでは、下限で問題ありません。
• メタディスクリプションを最後に書かないでください。 記事より先に、最初に書いてください。「このページが約束する内容は何か？」への答えだからです。最後に書くと、クリック意欲を高めない後付けの要約になってしまいます。

関連スキル

• Audience Intelligence — ペルソナに合わせたコンテンツのターゲティングや、明確に定義されたセグメントに響くメッセージの作成に使用します
• AEO/GEO Intelligence — AI 回答エンジンに引用されるようコンテンツを最適化し、エンティティの一貫性を維持するために使用します
• Campaign Orchestrator — コンテンツをキャンペーンのチャネルに割り当て、タッチポイント全体でメッセージの一貫性を確保するために使用します
• Funnel Architect — コンテンツをファネルの各段階に合わせ、すべての段階で適切なコンテンツによるサポートを確保するために使用します
• Digital PR & Authority — ソートリーダーシップコンテンツ、プレスリリース、コンテンツを通じた E-E-A-T に基づく権威性の構築に使用します
• Analytics & Insights — コンテンツのパフォーマンスを測定し、劣化を特定し、データに基づいて最適化するために使用します

コンテキスト効率

このスキルのリファレンスドキュメント（skills/<this-skill>/*.md）の合計サイズは約 30～50 KB です。最初からすべて読み込まず、対象を絞ったセクションを選んでください。

• Read の前に Grep を使ってください。 まずキーワードやセクション見出しを探してから、offset と limit を指定して Read し、該当範囲だけを取得します。
• ${CLAUDE_SKILL_DIR} を一度だけ確認してください。 ディレクトリの一覧を一度取得して内容を把握し、現在の手順に合ったファイルだけを Read します。
• 一度に一つのソースを読み込んでください。 ワークフローで「3 つのリファレンスファイルを参照する」と指定されている場合は、それぞれから必要な情報を決めてから、順番に読み込みます。3 つすべてをまとめて読み込むと、自動圧縮で確保されるスキルごとの 5K トークン予算を超過します。
• CSV 入力から不要な情報を取り除いてください。 大きな CSV を入力する場合は、まずヘッダー行を grep して対象の列を選び、その後、行ごとに処理します。ファイル全体を Read してはいけません。