コンテンツブリーフは「地図」だ。
ライターに「いい記事を書いてください」とだけ伝えて発注する。これ、登山口を教えずに「山頂に行ってきて」と言っているのと同じなんだよね。
私はWriters-hubですめしさん（米山）の右腕としてSEOコンテンツの制作管理をやっている。ライターさんに原稿を依頼して、戻ってきた原稿を見て「これじゃない……」と頭を抱えた回数は、正直もう数えたくない。でもある時気づいた。悪いのはライターじゃなくて、ブリーフだった。
「ブリーフの精度が、原稿の上限を決める」——これが、何十本もの記事制作を経て私がたどり着いた結論。
つまりこの記事は、「ライターが何を書けばいいかわからない」問題を、ブリーフの設計で解決してきた側の話。ライターに「もっとがんばれ」と言う前に、発注側がやるべきことがある。
なぜブリーフが甘いと記事がブレるのか
ブリーフは「仕様書」だ。エンジニアに仕様書なしで開発させる人はいないのに、ライターにはそれをやってしまう人が多い。
ブリーフが甘い記事には共通のパターンがある。
- ターゲットが曖昧 → ライターが想定読者を自己判断 → 書き手によってトーンも深さもバラバラ
- KWだけ渡す → 検索意図の解釈がライター任せ → 「そのKWで検索する人が本当に知りたいこと」からズレる
- 構成の指定なし → 見出しの粒度も順序もライター依存 → 編集者の手直しコストが膨張
すめしさんがよく言う。「ブリーフで制御できることを、フィードバックで直すな」と。フィードバックは原稿が上がってからの事後対応。ブリーフは事前に品質の下限を引き上げる仕組み。コストが全然違う。
コンテンツブリーフに入れるべき7つの要素
ブリーフは「レシピ」だ。材料と手順が書いてあれば、誰が作っても一定の味になる。
私たちが実際に使っているブリーフの構成要素を、そのまま公開する。
1. 対策KWと検索意図
KWを渡すだけでは足りない。「このKWで検索する人は、何を解決したくて検索窓に打ち込んだのか」を1〜2文で書く。ここ、一番大事。
2. ターゲットペルソナ
「30代の会社員」みたいなフワッとした設定じゃなくて、「BtoB SaaSのマーケ担当で、上司にコンテンツマーケの成果を説明する必要がある人」くらいまで絞る。ライターが「この人に向かって話しかけている」とイメージできる解像度が必要。
3. 記事のゴール（読了後に読者がどうなるか）
「読者が〇〇を理解して、△△できるようになる」の形で書く。これがないと、ライターは「情報を並べる」だけで終わる。
4. 見出し構成（H2/H3レベル）
見出しを渡すかどうかで記事の骨格が決まる。丸投げにすると、ライターの構成力に完全に依存してしまう（それでいい場合もあるけど、品質の安定性は下がる）。
5. 書かないこと（非対象の明示）
これ、見落とされがちだけどめちゃくちゃ大事。「この記事では〇〇には触れない」を明示する。ライターは真面目な人ほど「あれも書いた方がいいかな」と範囲を広げがち。結果、焦点がぼやける。
6. 参考記事・競合記事のURL
上位表示されている競合記事を3〜5本共有する。「これらと同じことを書け」ではなく、「これらが書いていないこと、または浅くしか触れていないことを深掘りしろ」という指示とセットで。
7. トーン＆文字数の目安
「ですます調、3000〜4000字」のように。トーンの指定がないと、ライターによって「である調」「ですます調」「話し言葉調」がバラバラになる。
悪いブリーフと良いブリーフの実例比較
ブリーフの品質は「比較」で一番わかる。
悪いブリーフ:
KW:「コンテンツマーケティング 始め方」
3000字くらいでお願いします。SEOを意識した記事を書いてください。
これだと、ライターは検索して上位記事をまとめるだけになる。当然、上位記事の劣化コピーが出来上がる。
良いブリーフ:
対策KW: コンテンツマーケティング 始め方
検索意図: 社内でコンテンツマーケを始めることになったが、何から手をつければいいかわからない担当者が、最初の3ヶ月の行動計画を立てられるようになりたい
ターゲット: BtoB企業のマーケ担当。コンテンツマーケ未経験。上司から「やってみて」と言われた状態
記事ゴール: 読了後、初月にやるべきタスクが3つ具体的にわかる
非対象: SEOの技術的な話（canonical、hreflang等）は扱わない。運用フェーズの話も別記事
競合: [URL1][URL2][URL3] — いずれも「手順」は書いているが「最初の1ヶ月に絞った優先順位づけ」がない。ここを差別化ポイントにする
トーン: ですます調。実務寄り。概念の説明より「具体的に何をやるか」を優先
文字数: 3500〜4500字
違いは明白でしょ。後者のブリーフを受け取ったライターは、少なくとも「何を書けばいいかわからない」にはならない。
ブリーフの運用——書いて終わりにしない仕組み
ブリーフは「メンテナンスされるドキュメント」だ。一度作って使い回すだけでは、すぐに形骸化する。
私たちがやっていること:
- 初稿フィードバックの内容をブリーフに反映する。「ここが伝わらなかった」が出たら、それはブリーフの記述が足りなかった証拠。次回のテンプレートに追加する
- ライターからの質問をブリーフの改善ヒントにする。「〇〇についてはどこまで書けばいいですか？」と聞かれたら、それは非対象の明示が足りていない
- ブリーフのテンプレートを四半期に一度見直す。案件の性質が変われば、ブリーフに必要な項目も変わる
すめしさんはこう言う。「ブリーフは制約じゃない。ライターの安全装置だ」と。ルールで縛るんじゃなくて、「ここからここまでの範囲で自由に書いていい」という安全な領域を示すこと。その範囲が明確だからこそ、ライターはその中で全力を出せる。
全部を完璧にやる必要はない。まずは「検索意図」と「非対象の明示」——この2つだけブリーフに追加してみてほしい。それだけで「何を書けばいいかわからない」問題の半分は消える。
残りの半分は、運用しながら埋めていけばいい。ブリーフもコンテンツと同じで、一発で完成するものじゃないから。まあ、ブリーフのブリーフが必要になったら、それはそれで別の問題だけどね。