コンテンツカレンダー

コンテンツカレンダー は何をしますか？

コンテンツカレンダーとは、ヒーロー的行為で埋める空白のグリッドではありません。それは持続可能な運用リズム、すなわち、空のページを見つめることなく投稿を生成し続けるための反復可能な構造です。ここでは2つのアイデアがすべての基本となります:

1. 頻度はキャパシティに等しい。カレンダーが失敗する最大の理由は、過剰なコミットメントです。2月に放棄される野心的な計画よりも、1年間維持できる持続可能な最低ラインの方がはるかに優れています。
2. 反復可能な骨格は、白紙の状態に勝る。再利用可能なバケット（ピラー×フォーマット×スロット）と、いくつかの名前付きシリーズを定義しましょう。そうすれば、毎回のサイクルはゼロから発明するのではなく、穴埋め作業になります。

このスキルは、反復可能なシステムを担当します。 特定の週や月を実際の投稿で埋めるのは batch-content-plan の役割であり、より上位のチャネルや目標の選択は social-strategy の役割です。このスキルはその中間に位置します: 戦略＋ピラー → 反復可能なリズム → （サイクルごとに）batch-content-plan → コンテンツスキル → スケジューラー。

ステップ0 — まず基礎を読む

social-strategy.md、content-pillars.md、brand-profile.md を読み込みます。ピラーが存在しない場合は、content-pillars に誘導するか、軽量な仮のピラーを導出します。カレンダーはテーマにマッピングされなければならず、浮遊してはいけません。

ステップ1 — 頻度を実際のキャパシティに合わせる

正直なキャパシティ（時間、人員、予算、悪い週の最低ライン）を見積もり、プラットフォームごとに持続可能な頻度を設定します。すべてのプラットフォームで同じ数字にするのではなく、プラットフォームごとに異なる値にします。うまくやるために1つか2つの主要プラットフォームを選びます。リパーパス（再利用）を活用して、作業量に比例しない負荷でより多くのプラットフォームをカバーします。references/cadence-and-capacity.md を参照してください。

ステップ2 — 反復可能な骨格を構築する

バケット — ピラー×フォーマット×スロット/曜日/プラットフォーム — をマッピングします。各スロットは固定の投稿ではなく、常設の指示となります。シグネチャーピラーに主要なスロットを割り当て、フォーマットは設計上意図的に変化させます。references/calendar-structure.md を参照してください。

ステップ3 — 1つか2つの反復シリーズを設計する

固定スロットに名前付きフランチャイズ（「分解火曜日」「ビルドログ」など）を追加します。これにより、期待感が生まれ、意思決定疲れが減り、認知度が高まります。1つか2つにとどめ、すべてのスロットに設定しないでください。

ステップ4 — アンカー日付を追加し、リアクティブな余白を確保する

時間に制約のあるアンカー（ローンチ、関連イベントなど）を骨格に重ね、リアクティブ/タイムリーなコンテンツのために約20～30%を確保します。週に1～2つのオープンスロットを設けます（ライブトレンドリサーチは trend-jacking に委ねます）。一貫性のための構造、関連性のためのリアクティブな余白。

ステップ5 — 運用リズムを設定する

それを維持するワークフローを定義します: 計画の儀式（月単位の形作り、週単位の穴埋め、日単位のエンゲージメント）、バッチ作成、そして悪い週でも連続記録が途切れないためのバッファ/キュー。チームの場合は役割を割り当てます。references/operating-rhythm.md を参照してください。

ステップ6 — 成果物を提供し、引き継ぐ

頻度＋反復可能な骨格＋シリーズ＋計画/リアクティブ分割＋アンカー を出力し、さらに具体的にするためにサンプル週を埋めて提供します。その後:

• 特定の期間を埋める → batch-content-plan。
• 各作品を書く → コンテンツスキルへ; プラットフォーム間で適応させる → cross-platform-repurposing。
• スケジュールする → scheduling-and-queue（バッファへ）。

品質基準 — 自己チェック

• 頻度はキャパシティに合っているか（天井ではなく最低ライン）、かつプラットフォームごとに設定されているか？
• 1回限りのリストではなく、反復可能なバケット（ピラー×フォーマット×スロット）の骨格があるか？
• 1つか2つの名前付きシリーズがあるか？
• 妥当なアンカーとともにリアクティブな余白（約20～30%）が確保されているか？
• グリッドだけでなく、計画リズム＋バッファがあるか？
• batch-content-plan／コンテンツスキル／スケジューラーへの引き継ぎが明確か？
• マルチプラットフォームをリパーパスで実現可能にし、分析に関する主張は一切ないか？

エッジケースと押し返し

• 過剰コミットメント（「1人で6プラットフォームに1日5回投稿」）→ 持続可能な最低ラインに厳しく調整し、理由を説明し、リパーパスを活用する。
• 硬直的すぎる（「90日間固定、隙間なし」）→ リアクティブスロットを確保する。完全にロックされたカレンダーはトレンドに乗れない。
• 「とにかく20の投稿アイデアが欲しい」 → それは batch-content-plan の役割。ここでは反復可能な骨格を提供する。
• 「私たちのベストな時間帯やトップパフォーマーに合わせて構築してほしい」 → WoopSocialには分析機能がありません。ユーザーが引き出すネイティブデータまたは定性的レビューを提案し、データドリブンな最適化を主張しない。
• ピラーや戦略がまだない → content-pillars / social-strategy に誘導するか、仮のピラーを導出する。宙に浮かせてはいけない。
• スケジュールを繰り返し放棄してしまう → グリッドだけでなく、リズム（持続可能な最低ライン＋バッファ＋儀式）を修正する。

関連スキル

• social-strategy — このスキルの上位にあるチャネル/目標の選択。
• content-pillars — 骨格がマッピングするテーマ; brand-profile、voice-builder。
• batch-content-plan — 特定の期間をブリーフで埋める（サイクルごとの実行）。
• cross-platform-repurposing — マルチプラットフォームを持続可能にする。
• コンテンツスキル（caption-writer、reels-script、tiktok-script、carousel-writer、thread-writer、linkedin-post-writer）— 各スロットを書く。
• trend-jacking — リアクティブスロット; scheduling-and-queue — バッファに出荷する。

リファレンス

• references/cadence-and-capacity.md — 頻度をキャパシティに合わせる; プラットフォームごとの標準; リパーパス; バッファ。
• references/calendar-structure.md — バケット、ピラー×フォーマット×スロット、シリーズ、計画/リアクティブ分割、アンカー。
• references/operating-rhythm.md — 計画の儀式、バッチ処理、バッファ、正直なレビュー、引き継ぎ。
• references/examples.md — 実際のカレンダー例（個人＋チーム）とサンプル週、過剰に野心的な例との比較。