オウンドメディアの編集方針は、理念や文体を並べるだけでは機能しない。必要なのは、会社が伝えたい企画を、読者が使える記事として「公開する」「直して公開する」「見送る」に分ける基準である。
企業の目的を消す必要はない。目的は、媒体が扱う領域と優先順位を選ぶ。一方、読者の用事は、その企画を記事として公開してよいかを決める。本稿では、この二つを混同せず、企画判断に使える編集方針へ落とし込む。

編集方針は、記事の採否を決められて初めて機能する
編集方針、媒体理念、スタイルガイドは役割が違う。媒体理念は「なぜ発信するか」を示し、スタイルガイドは表記や語調をそろえる。編集方針は、個別の企画を記事にするかどうかを決める。
英国国家統計局(ONS)のコンテンツ手順は、誰が何をする必要があり、なぜ必要かという「user need」を証拠から定める。明確な需要と上位目的がなければ公開しない。GitLabのブログ運用も、企画を approve、improve、not a fit に分け、ブログチームの確認なしに公開しない。[1][2]
両者の組織目的は企業メディアと同じではない。ただし、「よい記事にする」という曖昧な合意ではなく、公開しない条件まで決めている点は参考になる。編集方針に「誠実である」とだけ書いても、発売情報を急いで載せるべきか、根拠を待つべきかは決められない。
たとえば事業部から「受賞を記事にしてほしい」と依頼されたとする。これは架空の例だ。受賞名と担当者の喜びだけなら、ニュースリリースの役割に近い。審査基準、評価された取り組み、読者が応用できる条件、限界まで確認できるなら、記事として成立する余地が生まれる。編集方針は、この分岐を担当者の好みから切り離す。
企業目的はテーマを選び、読者の用事は公開条件を決める
企業は、自社が知見を持つ領域、事業上重要な課題、専門家へアクセスできるテーマを選んでよい。むしろ、目的が曖昧な媒体は企画が散らばる。先に「誰のどの判断を助けるか」を定める考え方は、コンテンツ戦略の記事でも整理した。
ただし、事業目標だけでは公開理由にならない。読者の用事は「経営者に読んでほしい」ではなく、「新しい発注先を選ぶ担当者が、比較条件と導入リスクを判断する」のように、行動まで書く。そうすれば、必要な根拠と削ってはいけない条件が見える。
| 企業が決めてよいこと | 編集方針で制限すること |
|---|---|
| どの事業課題や専門領域へ資源を置くか | 読者の用事がない社内報告を記事へ見せかけない |
| どの時期に情報需要が高まるか | 発売日だけを理由に根拠不足で公開しない |
| どの専門家や一次資料へアクセスするか | 不利な条件や代替案を落として宣伝へ変えない |
| 何を成果として測るか | PVのために誤認を招く見出しや主張を使わない |
読者価値は、企業に不利な内容だけを書くことではない。製品が向く条件と向かない条件、判断の過程、根拠の限界を同時に示せば、企業の専門性と読者の判断は両立する。境界は「企業を出すか」ではなく、「読者が判断するための重要事項を企業都合で落としていないか」にある。
公開・修正・見送りを六つの欄で決める
理念を実務へ変えるには、企画ごとに六つの欄を埋める。空欄があれば、原稿の長さや表現を直す前に、企画そのものへ戻る。

- 企業の目的:なぜ今、この媒体が扱うのか。
- 読者の用事:誰が、何を判断・実行するために読むのか。
- 記事の答え:発表文や営業資料にはない、確認できる答えは何か。
- 根拠と限界:一次資料、比較対象、数字の条件、未確認事項は何か。
- 利害と権利:自社・取引・広告の関係と、画像・引用条件をどう示すか。
- 公開後:訂正窓口、更新条件、責任者は誰か。
| 判定 | 条件 | 次の行動 |
|---|---|---|
| 公開する | 六欄が埋まり、反対材料を含めても答えが成立する | 最終確認と公開へ進む |
| 直して公開する | 読者の用事はあるが、根拠・比較・開示・権利の一部が不足する | 不足欄、責任者、期限を記録する |
| 見送る | 社内告知だけ、検証不能、重要な利害や限界を示せない | リリースや社内報など本来の形式へ戻す |
一つの記事に採用、営業、技術共有を同時に背負わせると、六欄の答えが複数になる。技術ブログの記事で見たように、目的を分けることは情報量を減らすためではなく、読者の用事を明確にするためである。
事業部は事実を確認し、編集責任者は記事の答えを決める
編集方針があっても、レビューする人の権限が曖昧なら機能しない。ONSはpeer reviewで構成やuser needを見て、stakeholder reviewでは誤り、誤解、不足の指摘を求める。GitLabも編集責任者をDRIとして置き、法務などの確認が必要な場合には保留できる仕組みを持つ。[1][2]

企業メディアでは、事業部や専門家が数字、製品条件、機密、不足を確認する。法務・コンプライアンスは公開リスク、必要な表示、許諾を確認する。編集責任者は、読者の問い、構成、タイトル、根拠の十分性、公開判定を決める。事実確認を受けることと、都合のよい結論へ書き換えることは別である。
Thomson Reutersは、独立性を理念だけでなく組織上の権限へ結びつけている。[5] これは報道機関の制度であり、企業メディアが同じ独立性を名乗れる根拠ではない。学べるのは、方針の実効性には「誰が止められるか」が必要だという点だ。経営が媒体目的と重大リスクの範囲を決めても、個別記事から不都合な事実を消す依頼は例外として記録し、編集責任者が公開判定をやり直す。
利害・訂正・更新を、公開後の付記にしない
利害関係は、読了後に見つかる奥付へ隠さない。米国FTCの公式解説は、広告を独立・中立なコンテンツのように見せないこと、誤認を避けるための開示を明瞭かつ目立つ形で示すことを求める。[3] これは米国の事業者向け資料であり、日本法の助言ではない。それでも、自社記事、広告、寄稿、取引関係を読む前に判断できるようにする編集原則は採用できる。
訂正も同じである。APは、オンライン情報を検証して原典へ帰属させ、事実誤認の訂正を読者に見える形で示し、単なる「軽微な編集」と呼ばない。[4] 企業メディアが報道機関と同じ規則を持つ必要はないが、重要な誤りを黙って上書きすれば、読者は変更前後を判断できない。訂正日、訂正内容、影響範囲を記事末尾へ残す。

GDSとDWPの事例では、チームごとに異なるガイドが利用者体験を分断した。過去の標準化が定着しなかった反省から、企画段階の協働、何を証拠とするかの合意、変更を記録する仕組みを組み込んだ。[6] 編集方針も、公開後を六つ目の欄として先に設計する。訂正が起きたとき、事業が変わったとき、読者の用事や根拠が変わったときに見直し、変更理由を履歴へ残す。
編集方針の完成形は、美しい宣言文ではない。「この企画はなぜ公開でき、別の企画はなぜ直すのか」を同じ六欄で説明できる状態である。企業の目的を入口にし、読者の用事、根拠、利害、権利、公開後の責任を通過させる。そこで初めて、企業都合と読者価値の境界が、毎回使える判断になる。
まず一枚の判断票で、直近の企画三件を再判定するとよい。公開済みの記事を一括で書き換えるのではなく、これから出す企画について、六欄のうち答えられない箇所を記録する。見送りが続くなら、担当者を責める前に、媒体目的が広すぎないか、必要な一次資料へアクセスできるかを見直す。修正が続くなら、不足欄と修正責任者が結びついているかを確認する。方針の価値は、公開本数を増やすことではなく、公開しない理由と直せば公開できる条件を共有できることにある。
Sources / 参考資料
2. GitLab:Blog Handbook
3. Federal Trade Commission:FTC issues Enforcement Policy Statement and business guidance on native advertising
4. Associated Press:Telling the Story
5. Thomson Reuters:The Trust Principles
6. Government Digital Service:Creating a single, shared content standard for the Department for Work and Pensions
7. Government Digital Service:Ten tips for getting the best from workshops