コンテンツ制作フローは「料理のレシピカード」だ。
材料（KW）があって、下ごしらえ（構成）があって、調理（執筆）があって、盛り付け（入稿）がある。この順番を飛ばすと、だいたい不味い料理ができあがる。——で、ここまでは誰でも知ってる。問題は「レシピカードがどこにあるか分からない」状態で毎回料理してる人が多すぎるということだ。
私はWriters-hubでSEOコンテンツの制作を回している。KW選定からCMS入稿まで全工程を1枚のスプレッドシートで管理している。今日はそのフローの話。
なぜ「1枚のシート」なのか——ツール分散の地獄
問題はツールの数じゃない。情報の住所が散らばることだ。
KWリストはスプレッドシートに、構成案はGoogleドキュメントに、進捗はNotionに、入稿チェックはSlackのスレッドに——「あの記事、今どこまで進んでる？」の確認に3つのタブを開く羽目になる。
私も最初はそうだった。3記事くらいなら回る。でも10記事を並行で進めた瞬間に破綻した（認めたくないけど、2記事の入稿漏れをクライアントに指摘されて初めて気づいた）。
つまり、こういうことだ。「全部管理してます」は、管理できてないのと同義。
1枚シートの設計——6つのステータスで全工程を追う
シートの構造はシンプルで、1行が1記事。列は大きく分けて3ブロック。
ブロック1: KW情報
- 対策KW
- 月間検索ボリューム
- 現在順位（あれば）
- KW難易度
- 対策URL
ブロック2: 制作進捗
- ステータス（S0〜S5の6段階）
- 構成担当 / 執筆担当 / 入稿担当
- 各工程の完了日
ブロック3: 品質管理
- 文字数
- 内部リンク本数
- meta description有無
- 入稿後URL
ここ、大事。ステータスのS0〜S5がこのシートの背骨になる。
- ステータス: S0 / 意味: KW選定済み / 完了条件: 検索ボリューム・難易度・対策URL確定
- ステータス: S1 / 意味: 構成完了 / 完了条件: H2/H3構成＋想定文字数が埋まっている
- ステータス: S2 / 意味: 執筆中 / 完了条件: 担当者アサイン済み、着手済み
- ステータス: S3 / 意味: 執筆完了 / 完了条件: 本文完成、セルフチェック済み
- ステータス: S4 / 意味: 入稿完了 / 完了条件: CMSに入稿済み、公開待ち
- ステータス: S5 / 意味: 公開済み / 完了条件: 本番URLが発行されている
「S0からS5まで順番に進むだけでしょ」と思うかもしれないけど、現実はそう綺麗にいかない。S3（執筆完了）からS1（構成）に差し戻すこともあるし、S4でクライアント確認が入って修正が発生することもある。だからステータスは「進む」だけじゃなく「戻る」も想定して設計してある。
KW選定（S0）——ここで8割決まる
コンテンツ制作は「上流で決まる」型の仕事だ。
KW選定がズレていたら、どんなに良い文章を書いても成果は出ない。月間検索ボリューム30のKWに渾身の5000字を投下して、3ヶ月後に「あれ、流入増えない……」——これ、実話。私がやらかした。
KW選定で見ているのは3つ。
1. 検索ボリュームと難易度のバランス
ボリュームが大きくても難易度が高すぎるなら上がらない。逆に小さくても難易度が低く確実に1ページ目に入れるなら、そっちを先に取る。Semrushの数値で判断する。感覚じゃない。
2. 検索意図の明確さ
「SEO」単体と「SEO 記事 書き方」では、検索意図の解像度がまるで違う。後者は明確だからコンテンツの方向性がブレない。私はKWの横に「想定検索意図」を1行で書く欄を設けている。ここが埋められないKWは、まだ選定が甘い。
3. 既存コンテンツとのカニバリ
これもめちゃくちゃ大事。同じドメインで似たKWを狙った記事があるなら、新規よりリライトの方が効率がいい。site:検索でカニバリをチェックする。シートの「既存URL」列が埋まっていたらリライト優先。
構成→執筆→入稿（S1〜S4）——流れを止めない仕組み
構成から入稿までの流れは「ベルトコンベア」だと思っている。どこか1箇所が詰まると全体が止まる。
構成案はシートとは別のドキュメントに書く。ただしシートからそのドキュメントへのリンクを貼る。これだけで「構成案どこだっけ」問題が消える。シンプルだけど、やってない人が多い。
執筆フェーズで気をつけているのは「構成に従順すぎない」こと。H2/H3の骨組みは構成で決めるけど、書いている途中で「この順番だと読者が混乱する」と感じたら、その場で構成を修正する。構成は設計図であって、聖典じゃない。
入稿フェーズが一番事故が起きやすい。
悪い例:
- 本文をコピペしてCMSに貼る → 公開ボタンを押す → 終わり
良い例:
- meta descriptionを設定する
- OGP画像を設定する
- 内部リンクを本文中に設置する
- alt属性を画像に設定する
- パーマリンクを確認する
- プレビューで実際の表示を目視確認する
- シートのステータスをS4に更新する
この差が、10記事、20記事と積み重なった時に効いてくる。入稿チェックリストをシートの別タブに持っておく。面倒だけど、入稿漏れをクライアントに指摘されるよりはずっとマシだ（冒頭の2記事入稿漏れが、このチェックリストを作る直接のきっかけ）。
運用で失敗したこと——正直に書く
全部がうまくいったわけじゃない。
失敗1: 列を増やしすぎた
最初は「情報は多い方がいい」と思って、競合URL、参考記事、ペルソナ、CTAの種類……と列を追加していった。結果、シートが横に長くなりすぎて誰も全体を見なくなった。今は「判断に直結しない列は消す」をルールにしている。
失敗2: ステータス更新を後回しにした
「あとでまとめて更新しよう」が一番危ない。記事が完成した瞬間にステータスを変えないと、翌日には「あれ、この記事って今どこだっけ」になる。今は工程が変わったら30秒以内にシートを更新することを自分に課している。
失敗3: 1人で完結しすぎた
シートを自分だけが見ている状態だと、「自分の頭の中の情報」と「シートの情報」が乖離していく。米山さんから「シートを見れば俺が聞かなくても進捗が分かる状態にしてくれ」と言われて、ようやくシートの本当の価値に気づいた。シートは自分のためのメモじゃない。チームの共有状態を映す鏡だ。
なぜスプレッドシートなのか——設計思想の話
「もっと良いツールがあるのでは」と思う人もいるだろう。NotionのDBでもいいし、専用のプロジェクト管理ツールでもいい。
私がスプレッドシートを選んでいる理由は2つ。
1つ目は、フィルタとソートの自由度。 ステータスでフィルタをかければ「今、執筆中の記事だけ」が見える。検索ボリュームでソートすれば優先度順に並ぶ。
2つ目は、共有のハードルの低さ。 クライアントにNotionのアカウントを作ってもらう必要がない。共有リンク1つで見られる。ツール導入コストの低さは、実運用では思っている以上に価値がある。
ただし記事数が50を超えるとスプレッドシートでは限界が見える。その規模ならNotionやAirtableへの移行を検討する段階だ。
まず1行から始める
全部を一気に整える必要はない。
今進行中の記事を1行だけシートに書く。KW、ステータス、担当者、対策URL——この4列だけでいい。それが2行、3行と増えていった時に、「ああ、全体が見える」という感覚が生まれる。その感覚が出たら、もう戻れない。
コンテンツ制作の品質は、1本の記事の中身だけで決まるんじゃない。10本、20本と積み重ねた時に抜け漏れなく出し続けられるかどうか。それを支えるのが、たった1枚のシートだったりする。
……まあ、完璧に運用できてるかと聞かれたら「8割くらい」と答えるけどね。残り2割は、今日もシートの更新を後回しにしている自分との戦いだ。