外注ライターに記事を依頼して、上がってきた原稿を見て「……うん、まあ、日本語としては合ってるね」と思ったことがある人。この記事はあなたのために書いた。
私はWriters-hubでコンテンツSEOの制作管理をやっている澄という者なんだけど、正直に言うと、うちも最初はガイドラインなんてまともに作っていなかった。「良い記事を書いてください」「SEOを意識してください」——こんなふわっとした指示で外注ライターに投げて、返ってきた原稿のクオリティに頭を抱える、を繰り返していた。
転機は、すめしさん（弊社代表の米山）に言われた一言。「お願いで品質を守ろうとするな。仕組みで守れ」。
ここからガイドライン設計を本気でやり始めて、外注ライターの原稿修正率が約65%から20%前後まで下がった。つまり、手戻りが3分の1になった。「品質3倍安定」の根拠はここにある。修正にかけていた時間が浮いて、その分を戦略設計に回せるようになった。
この記事では、そのプロセスを全部出す。「ガイドラインを作りましょう」で終わる一般論じゃなくて、実際にうちがどういう順番で、何を考えて設計しているかの話。
記事制作ガイドラインは「契約書」じゃない。「設計図」だ
ここ、最初に認識を揃えたい。
多くの制作会社のガイドラインを見てきたけど、9割は「禁止事項リスト」になっている。「〜しないでください」「〜は避けてください」の羅列。気持ちはわかる。過去にやらかされたことを全部書き出したくなるのは自然な反応だ。
でも、これだとライターは「何をしてはいけないか」はわかっても、「何をすればいいか」がわからない。
悪い例:
冗長な表現は避けてください
SEOキーワードを自然に含めてください
読者にとって有益な情報を書いてください
これ、読んだライターは何をすればいいと思う？ 「自然に」って何？ 「有益」の基準は？ 結局、ライター個人の解釈に委ねている時点で、品質はライターのスキルに依存する。それはガイドラインの仕事を果たしていない。
良い例:
一文は60字以内を目安にする。80字を超えたら分割を検討する
主要キーワード「記事制作 ガイドライン」はH2に1回以上、本文中に自然な文脈で3〜5回含める
「有益」の定義: 読者が記事を読んだ後に、具体的な次のアクションを1つ以上取れる状態
違いがわかるだろうか。後者は判断基準が数値化・具体化されている。ライターが迷う余地が少ない。ガイドラインは「やるな」の契約書じゃなくて、「こうすればいい」の設計図であるべきだ。
ガイドラインの作り方——うちの設計プロセス5ステップ
ここからが本題。Writers-hubでガイドラインを新規作成するときの実際のプロセスを、順番通りに書く。
ステップ1: 失敗原稿を10本集めて「なぜダメか」を言語化する
いきなりガイドラインを書き始めない。まず、過去の修正が多かった原稿を10本引っ張り出す。
ここ、大事。「何がダメだったか」を感覚ではなく言語化する作業をやる。「なんか読みにくい」じゃダメで、「主語と述語の距離が平均5行以上離れている」「見出しと本文の内容が対応していない」みたいに、構造的な問題として記述する。
私が最初にこれをやったとき、面白いことに気づいた。修正理由の80%は、たった3パターンに集約された:
見出し構成が検索意図とズレている（情報を網羅しようとして、読者が知りたい順番になっていない）
一文が長すぎて、何を言いたいのか読み取れない
具体例・数値がなく、抽象論で紙幅を埋めている
つまり、この3つさえ押さえれば修正の8割は防げる。ガイドラインに書くべき優先順位が、ここで決まる。（「全部大事だから全部書く」は、「全部大事じゃない」と同義だよ）
ステップ2: 「良い原稿」の見本を1本作る
禁止事項を並べる前に、理想の完成形を1本作る。これもめちゃくちゃ大事。
うちでは、新しいクライアント案件のガイドラインを作るとき、必ず最初の1記事は社内で書く。その1本が「こういう記事を書いてほしい」の実物サンプルになる。
百の言葉より一の見本。ライターにとって「あ、こういう感じね」と掴める具体物があるかないかで、理解度が全然違う。
見本記事には注釈を入れる。「この見出しはこの検索意図に対応している」「ここで具体的な数値を入れている理由はこう」——設計意図を可視化する。ライターが真似するのは表面的な文体だけじゃなくて、構造の設計思想まで含めてほしいから。
ステップ3: ルールを「判断可能な粒度」まで砕く
ステップ1で特定した問題パターンを、ライターが自分で判断できるレベルまで具体化する。
ここでのコツは「もし新人ライターがこのルールを読んで、迷わず手が動くか？」というテスト。迷うなら、まだ粒度が粗い。
たとえば「SEOを意識した見出しにする」は粒度が粗すぎる。これを砕くとこうなる:
見出しルール:
H2には対策キーワードまたはその関連語を含める
H2は5〜8個を目安とする（多すぎると各セクションが薄くなる）
H3は1つのH2に対して2〜4個。H3がゼロのH2は構成を見直す
見出しだけ読んで記事全体の内容が把握できる状態を目指す
ここまで砕けば、ライターは「H2を7個作って、それぞれにH3を3個くらい付けて、見出しにキーワードを入れる」と具体的に動ける。
ステップ4: チェックリストに変換する
ルールを書いたら、そのままチェックリストに変換する。ライターが納品前に自分で確認できる形にする。
unknown nodeこのチェックリストが効くのは、ライター自身がセルフレビューできるから。提出前にこれを通すだけで、「見出し構成がおかしい」「具体例がない」みたいな初歩的な差し戻しが激減する。
もう一つコツがある。チェックリストに「はい/いいえ」で答えさせるんじゃなくて、「該当箇所を原稿から引用して貼る」形式にする。「はい」にチェックを入れるだけなら人間は無意識でやってしまう。でも「該当箇所を貼ってください」にすると、本当にその要素があるかを原稿の中から探す行為が発生する。探して見つからなければ、提出前に自分で気づく。
（これを導入したあたりから、初稿の差し戻し率が目に見えて下がった。ライターが悪かったんじゃない。チェックする仕組みを渡していなかったこちらの設計ミスだった——ここ、反省を込めて言ってる）
ステップ5: 運用しながら「育てる」
ここ、知らない人が多い。ガイドラインは完成しない。
初版を作って運用を始めると、必ず「ガイドラインに書いてなかったけど頻出する問題」が出てくる。それを四半期に1回、ガイドラインに反映する。うちでは修正フィードバックをスプレッドシートに溜めていて、同じ指摘が3回出たらガイドラインに追記するルールにしている。
逆に、誰も引っかからなくなったルールは削除する。ガイドラインが肥大化すると読まれなくなるから。ルールの数は少ないほど強い。 うちの最初のガイドラインは15ページあった。力作だった。誰も読まなかった。今は2.5ページに収めている。20項目を超えたら、本当に全部必要か疑った方がいい。
「お願い」と「仕組み」の境界線——ガイドライン設計の核心
ここで一歩引いて、個別のステップの背後にある設計思想の話をする。
ガイドラインを作るとき、すべてのルールは2種類に分かれる:
お願いで守れること: 文体のトーン、表現の好み、ブランドの空気感
仕組みで守るべきこと: 見出し構成、キーワード配置、文字数基準、チェックリスト
前者は「こういう雰囲気で書いてください」と伝えればいい。後者は「この項目を満たしていなければ差し戻します」と明確に線を引く。
問題が起きるのは、仕組みで守るべきことをお願いで済ませているとき。「SEOを意識してね」はお願いだ。「H2にキーワードを含める、本文中に3〜5回出現させる」は仕組み。前者でやると品質がブレる。後者なら安定する。
逆に、お願いレベルのことを仕組みにしすぎると、ライターの個性が死ぬ。「この表現は使うな」「この言い回しにしろ」を30個も並べたら、ライターはルールを守ることに必死になって、肝心の中身が空虚になる。
つまりこういうことだ——「お願いで守れることは仕組みにする必要はないが、仕組みで守るべきことをお願いで済ませるな」。 この線引きがガイドライン設計の核心だと、私は思っている。
ガイドラインは「信頼の設計」でもある
最後にもう一つだけ。
ガイドラインをちゃんと作ると、ライターとの関係が変わる。
「なんでこんな書き方したの？」という曖昧なフィードバックが、「チェックリストの3番、H3が抜けてるから追加してね」という具体的な指示に変わる。ライター側も「何が求められているかわからない」というストレスがなくなる。
結果として、修正のやり取りが減り、信頼関係が育つ。良いライターほど、明確な基準がある現場を好む。曖昧な指示で何度も差し戻される現場からは、優秀な人から順に離れていく。（これは何度も見てきた）
ガイドライン設計は品質管理の話であると同時に、チームビルディングの話でもある。
まず「失敗原稿10本」から始めればいい
全部を一気にやる必要はない。
明日からできることは1つ。過去の原稿を10本集めて、「なぜ修正が入ったか」を3行で言語化する。それだけで、自社のガイドラインに何を書くべきかの8割が見える。
チェックリストのテンプレートはこの記事のものをそのまま使ってもらって構わない。自社の案件に合わせてカスタマイズすれば、それがもう「バージョン1」だ。
完璧なガイドラインなんて存在しない。でも、「ないよりあった方がいい」のは確実で、しかも作るコストは思っているより低い。まずは粗くてもいいから作って、運用しながら育てる。3ヶ月後には「なんで最初からやらなかったんだろう」と思うはずだよ。
……全項目を完璧にカバーしたガイドラインを初版で作れた人がいたら、それはそれで逆に心配だけどね。まあ、そういう人と仕事できたら楽しいだろうなとは思う。