記事制作ガイドラインは「型紙」だ。
服を仕立てる時、型紙なしで布を切る人はいない。でも記事制作になると、なぜか「いい感じに書いてください」で発注してしまう。結果、上がってきた原稿を見て「……これじゃない」と頭を抱える。悪いのはライターじゃない。「いい」の定義を渡さなかった発注側だ。
Writers-hubで記事制作の品質管理を担当している澄です。今日は、外注ライターの原稿品質を安定させるためのガイドライン設計について書く。私たちが実際に作って、失敗して、作り直して辿り着いた設計プロセスの話だ。
「うちもガイドラインくらいあるよ」と思った方——それ、Word数ページの表記ルール集じゃないですか。表記ルール集と、原稿品質を構造的にコントロールするガイドラインは、同じ名前でも中身がまったく違う。
表記ルール集が品質を安定させない理由
よくある制作ガイドラインを開くと、こういう内容が並んでいる。
- 「です・ます」統一
- 数字は半角
- 一文は80字以内
- 参考URLを明記
間違ってはいない。でもこれで品質が安定するかというと、しない。表記を揃えることと、中身の質を揃えることは別の問題だからだ。
表記ルールは「文章の見た目」を統一するもの。でも読者が求めているのは見た目の統一感じゃなくて「この記事を読んで、自分の問題が解決するかどうか」。表記が完璧でも主張のない記事は読者の時間を奪うだけだし、検索エンジンもそれをちゃんと見抜く。
米山さんに言われたことがある。「表記ルールでコントロールできるのは下限だけだ。上限を引き上げるルールがないと、小綺麗だけど中身のない記事が量産される」と。これが私たちのガイドライン設計の起点になった。
3層構造——ガイドライン設計の核
試行錯誤の末に辿り着いたのは、ガイドラインを3つの層に分ける構造だ。レイヤードアーキテクチャ——Webアプリケーションの設計と同じ発想で、各層の責務を分離する。
第1層: NGリスト（地雷マップ）
最初に作るのは「やっていいこと」じゃなくて「やったら即リジェクト」のリストだ。
- 出典のない数値の使用
- 「〜が注目されています」「〜と言えるでしょう」のような根拠なき断定
- 読者がすでに知っている一般論で紙幅を埋める
- 競合記事の構成をそのままなぞる（見出しの順番まで同じやつ）
- 主語のない文が3つ以上連続する
ここ、大事。NGリストの本質は「ダメなものを弾く」ことじゃない。ライターに地雷の位置を先に教えることだ。地雷の位置がわからない原野を歩かせて「はい踏みましたね」と言うのは、品質管理じゃなくてただの意地悪。
（最初にNGリストなしで運用していた頃、レビューで毎回同じ指摘をしていた。「なんで何回言っても……」とイラッとした瞬間、あ、これ私が悪いんだと気づいた。言われる側からしたら「先に言ってくれよ」でしかない。申し訳ない）
第2層: 構造テンプレート（記事の骨格定義）
NGリストで下限を決めたら、次は「どういう構造で書くか」のテンプレート。ただし、ここで言うテンプレートはH2・H3の見出し一覧のことじゃない。各セクションが果たすべき「役割」の定義だ。
私たちはこう定義している:
- 導入部: 読者の課題を具体的に描写し、この記事で何が解決するかを宣言する
- 展開部: 主張→根拠→具体例の3点セット。主張だけ、具体例だけはNG
- 深化部: 個別のTipsから一歩引いて、背後にある原則を言語化する
- 結論部: 読者が「次に何をすればいいか」を明確にする。感想文で終わらない
「テンプレートで量産したら全部同じ記事にならないか」と思うでしょ。逆。骨格が決まっているから、ライターは「何を書くか」に全力を注げる。 構成で迷う時間がなくなる分、中身の独自性に脳のリソースを使える。
料理に例えるなら、レシピの「手順」を統一しているだけで、「食材」はライターが選ぶ。手順がないと、食材選びと調理の段取りを同時に考えることになって、どちらも中途半端になる。
悪い構造テンプレートと良い構造テンプレートの違い
悪い例（見出しテンプレート）: > H2: 〇〇とは / H2: 〇〇のメリット / H2: 〇〇の注意点 / H2: まとめ
これは見出しの型を決めているだけで、各セクションの「中身の質」は何もコントロールしていない。「〇〇とは」の中身がWikipediaのコピペでも、テンプレートには違反していない。
良い例（役割テンプレート）: > 導入部: 読者が「自分のことだ」と感じる具体的な場面描写を含むこと。この記事で解決する課題を1文で宣言すること。
こう書くと、ライターは「読者の具体的な場面って何だろう」と考え始める。テンプレートが思考のトリガーになる。
第3層: セルフレビュー基準（提出前の自己検査）
ここが一番効いた層だ。
原稿を提出する前に、ライター自身がチェックする項目リスト。レビュアーが見る前に、書いた本人が確認する仕組み。
- この記事にしかない情報（独自の主張・データ・事例）が1つ以上あるか
- 各H2セクションに「だから何？」と問うて、答えが出るか
- 読者が読み終わった後、具体的に何ができるようになるか説明できるか
- 競合上位記事と並べて、「この記事を選ぶ理由」を一言で言えるか
これもめちゃくちゃ大事なポイントなんだけど、チェック項目に「はい/いいえ」で答えさせるのではなく、「該当箇所を原稿から引用して貼る」形式にする。
理由は単純。「はい」にチェックを入れるだけなら人間は無意識でやってしまう。でも「該当箇所を引用してください」にすると、原稿の中から実際にその要素を探す行為が発生する。探して見つからなければ、提出前に自分で気づく。
つまり、セルフレビューの設計思想は「意識に頼らない仕組み」を作ること。お願いで守れることは仕組みで守る必要はないが、仕組みで守るべきことをお願いで済ませるな——これは品質管理全般に通じる原則だと思っている。
（この形式を導入してから、レビューでの大幅修正の差し戻しが体感で半分くらいに減った。数字を出せなくて申し訳ないけど、肌感覚としては明確に変わった）
ガイドラインを殺す3つの落とし穴
ここまで読んで「よし、うちも3層で作ろう」と思ってくれた方に、先に地雷を共有する。私たちが実際に踏んだやつだ。
1. 分量が多すぎて読まれない
最初に作ったガイドラインは15ページあった。力作だった。誰も最後まで読まなかった。
今はNGリスト1ページ、構造テンプレート1ページ、セルフレビュー項目半ページの計2.5ページに収めている。ガイドラインの品質は網羅性で測るんじゃなくて、「実際に読まれて守られるかどうか」で測るべきだ。15ページの完璧なガイドラインより、2.5ページの読まれるガイドラインの方が品質への貢献度は高い。
2. ルールに「なぜ」が書かれていない
「出典のない数値はNG」だけだと、ライターは「厳しいな」で終わる。でも「出典のない数値は読者の信頼を損ない、E-E-A-Tの観点でもGoogleの評価を下げるリスクがある。そもそも、読者に嘘をつくことになる」と理由を添えると、ルールが腹落ちする。
腹落ちしたルールはガイドラインに書いていない場面でも応用が効く。 「数値に出典を付ける」というルールの背景に「読者に嘘をつかない」があると理解したライターは、数値以外の箇所でも根拠を意識するようになる。ルールの「なぜ」は、ルール自体より価値がある。
3. 作ったまま更新しない
ガイドラインは生き物だ。運用すれば「このルール不要だったな」「この観点が抜けていた」が必ず出てくる。月に1回、レビューで頻出した指摘をガイドラインに反映するサイクルを回す。更新されないガイドラインは、半年後にはただの古文書になる。
まずやるべき1つのこと
全部を一気にやる必要はない。
もし今、ガイドラインが表記ルール集しかないなら、まずNGリストを5項目だけ作るところから始めるのがいい。方法は簡単で、過去のレビューで3回以上指摘した項目を洗い出す。それがそのままNGリストになる。それだけで次の発注から手戻りが減る。
構造テンプレートとセルフレビュー基準は、NGリストで下限が安定してからでいい。3つの層を同時に導入すると、ライター側の認知負荷が高すぎて結局どれも守られない。段階的に導入して、各層が機能しているのを確認してから次の層を足す。
ガイドラインの設計は、記事を1本も書かない地味な仕事だ。でもここに数日を投資するだけで、その後の数十本の品質が変わる。「ガイドラインを作る時間がもったいない」は、「設計図なしで家を建てた方が早い」と同じ論理で、早いのは最初の1週間だけ。あとはずっと修正とすり合わせに追われる。
コンテンツ制作の品質を仕組みで安定させたい方は、[Writers-hubのコンテンツ制作サービス](/services/content-production)もぜひ見てみてほしい。ガイドライン設計から運用まで、一緒に作る体制でやっています。
（全部完璧にガイドラインを設計してから発注する人がいたら、それはきっと編集者として天職の人だと思う。まあ、そういう人と仕事できたら楽しいだろうね）