Webコンテンツを作る前にページ目的ブリーフを書く方法

Webページの制作前に、対象読者、ユーザーの問い、ページの役割、要点、必要な根拠、期待する行動、形式、責任者、見直し日を整理する9項目の目的ブリーフを紹介し、既存コンテンツの点検から更新・統合・リダイレクト・却下・新規作成の選択、執筆を依頼する前の承認基準までを実務に沿って解説します。

WebChorus Editorial Team2026年7月25日10 分で読めます

コンテンツ戦略
コンテンツブリーフ
コンテンツガバナンス
Webサイト企画
コンテンツライフサイクル
編集ワークフロー
ページ目的

執筆を始める前に、対象読者、ユーザーの問い、ページの役割、キーメッセージ、必要な根拠、期待する行動、形式、責任者、見直し日の9項目を、1枚のページ目的ブリーフにまとめて承認します。ただし、新規ページを前提にしてはいけません。既存サイトと利用導線を確認した結果、妥当な判断は既存ページの更新、複数ページの統合、リダイレクト、依頼の却下、新規作成のいずれにもなり得ます。タイトルや動画といった希望は提案された解決策であって、ページの必要性を示す根拠ではありません。

要点

ページ依頼は、根拠のあるニーズと固有の役割が確認されて初めて執筆依頼になります。
目的ブリーフの結論は、更新、統合、リダイレクト、却下、新規作成のいずれかです。
対象読者から見直し日まで、9項目を1つの意思決定記録として扱います。
期待する行動は、読む、比較する、判断する、探す、次の作業へ進むことでも構いません。
ブリーフは調査、アクセシビリティ対応、事実確認、専門審査の代わりにはなりません。

なぜ執筆前にページの目的を決めるのか

女性と男性が丸い木製テーブルの白紙を見つめ、男性は資料の印刷物を1枚手に持っている。

執筆前に目的を決めるのは、依頼を文章制作の問題に変える前に、妥当なニーズ、既存コンテンツと異なる役割、必要な証拠、読者に生じてほしい結果、公開後の責任を確定するためです。GOV.UKの公式ガイダンスも、公開項目には妥当なユーザーニーズが必要で、想定利用者、達成したいこと、裏付け、受け入れ基準を記録するよう示しています。これらが曖昧なままでは、書き手が対象、問い、根拠、導線を推測することになります。なお、次の9項目は複数のガイダンスを編集実務向けに統合したもので、公式の普遍的な標準ではありません。

コピーして使える9項目のページ目的ブリーフ
項目	記入する問い	承認時の確認
対象読者	どの状況や知識段階にいる人か	ページ要件を変える具体性があるか
ユーザーの問い	読者が解決したい中心的な問いは何か	利用者の言葉と根拠で示せるか
ページの役割	利用導線の中で何を担当するか	既存ページやツールと役割が重ならないか
キーメッセージ	読者が持ち帰る結論は何か	見出しと冒頭で明確に伝えられるか
必要な根拠	ニーズと掲載内容を何で裏付けるか	情報源と確認担当を特定できるか
期待する行動	読後に何を判断・実行・発見できるか	達成を確認できる表現になっているか
形式	案内、比較、ツールなど何が適するか	好みではなく役割から説明できるか
責任者	正確性と保守に誰が責任を持つか	確認者や承認者と区別されているか
見直し日	いつ、どの変化を契機に確認するか	日付と変更契機が現実的か

新しいページを承認する前に何を調べるべきか

女性が黒い壁面ボードの前に立ち、色分けされた5つの幾何学形カード群の中で青いカードを動かしている。

承認前には、現在のサイトと利用導線を検索し、同じ問いに答えるページ、資料、検索機能、申請や設定の画面、問い合わせ窓口などを確認します。公式ガイダンスも、既存情報を早期に調べ、更新できるページ、重複、タスク遂行に欠ける情報を見つけてから追加するよう勧めています。似たページの並存は正式な情報源を分かりにくくする一方、手続きの直前など利用地点で必要な短い反復まで機械的に消すべきではありません。調査結果は次の5つの判断へ結び付けます。

更新：既存ページがすでにニーズと役割を担っている。
統合：複数ページの断片が同じ答えを競合している。
リダイレクト：別ページが正式な情報源となり、旧ページが不要になった。
却下：ニーズや固有の役割を裏付けられない、または別の手段が適する。
新規作成：ニーズ、役割、根拠、行動、形式、責任、見直し計画が一貫している。

書き手にページ制作を依頼する前に、組織にそのページの仕事を説明させる。
WebChorus編集部

対象読者とユーザーの問いをどう定義するか

女性が本棚のある作業室で、白紙のカードを中心に印刷された図表や色付きメモを並べ替えている。

対象読者は、ページの内容や説明順を実際に変えるタスク、状況、知識段階で定義し、ユーザーの問いは、その人が解決したい中心的な課題を認識できる言葉で記します。「すべてのお客様」のような無限定な表現では、何を省き、何を説明すべきか判断できません。中心的な問いには密接な小問を含められますが、1ページで一貫したニーズを解決できる範囲に保ちます。根拠の候補はアクセス解析、問い合わせ記録、過去の調査、関連する外部データです。ただし、閲覧数だけでは来訪の意図を証明できず、担当者の要望、仮タイトル、希望形式もニーズの証拠にはなりません。

ページの役割、キーメッセージ、必要な根拠をどう連動させるか

3人の同僚がスタジオの作業台で、長い工程図の帯、ベージュ色のカード、4枚の参考写真を順番に並べている。

3項目は順に、ページが導線内で担う仕事、読者が持ち帰る結論、その結論を支える証拠を定めます。役割欄には、既存ページ、取引画面、ツール、別チャネルでは担えない理由まで書きます。たとえば、連携機能の設定前ガイドは権限や互換性などの前提条件を説明し、実際の設定はツールに任せるという分担が可能です。キーメッセージは重要な結論を先に示し、主要タスクに役立たない詳細を増やさないための基準になります。必要な根拠には、ニーズの存在を示す材料と、公開する主張を支える製品資料、業務記録、データ、実演、専門家の確認を分けて記します。

公開時には、タイトル、主見出し、冒頭がブリーフの結論と一致し、読者がページの話題、目的、自分との関係を判断できるか確認します。WCAG 2.4.2も、ページタイトルがトピックまたは目的を説明することを求めています。ただし、タイトルが適切であることはアクセシビリティ全体への適合を意味しません。ブリーフは目的を内部で合意する記録であり、公開ページでは、その目的を利用者に伝わる形へ編集する必要があります。

期待する行動からコンテンツ形式をどう決めるか

女性が工程を示す大きな用紙の横で折り畳んだ紙模型を持ち、バインダーやカードの束、木製模型と比較している。

形式は、読者が利用後に何をできるべきかを定めてから選びます。期待する行動は購入や問い合わせに限らず、条件を理解する、選択肢を比較する、可否を判断する、必要情報を探す、次の作業地点へ進むことでも構いません。これを受け入れ条件として使えば、完成原稿が目的を果たせる構成かを評価できます。その後で、案内、比較表、参照資料、解説、取引ステップ、ツール、動画などを候補にします。ツールの改修、取引画面への説明追加、電話など別チャネルの方が適切なら、新規ページへ押し込まず、その判断を記録します。引用資料はこの原則を支えますが、企業サイトに共通する万能の形式分類は示していません。

ページの責任者は誰で、いつ見直すべきか

男性が中央の女性に紙の資料を手渡し、右側の女性は卓上カレンダーに木製の目印を置いている。

責任者には、ページの正確性と保守について説明責任を持つ1人または1チームを指定し、見直し日は既知の変更契機とリスクから決めます。執筆者、情報提供者、製品担当、アクセシビリティ担当、法務・規制担当、技術担当、承認者は必要に応じて別欄で管理し、責任者にすべての専門判断を負わせません。見直し時期は、製品リリース、制度や料金の変更、情報の変動性、誤りの影響、根拠の更新予定、公開時の約束から設定します。全ページ一律の四半期または年次周期を置く根拠はなく、日付と変更契機を併記する方が判断を再現しやすくなります。

公開記録に最終更新日と予定した見直しを残せば、期限を過ぎたコンテンツを把握し、更新、修正、統合、リダイレクト、廃止を検討できます。ただし、日付の入力だけで保守が実行されるわけではありません。責任者には、変更情報を受け取る経路、レビューを開始する権限、必要な専門家へ確認を依頼できる運用環境も必要です。

完成した9項目のブリーフはどのようなものか

木製テーブルを真上から見ると、9つの枠と独立した欄があるワークシートの周囲に、5枚のメモ、ノート、ペンが置かれている。

完成したブリーフは、9項目が互いを支え、なぜその判断で執筆へ進めるのかを短時間で説明できる状態です。仮に、法人向けサービスの連携機能を設定する前のサポートページを検討するとします。以下は形式を示す架空例であり、閲覧数、完了率、売上、費用削減などの成果を主張するものではありません。実案件では、自社の調査結果、現行製品、運用体制に置き換えてください。

対象読者：対応する連携機能の設定を準備する顧客企業の管理者。
ユーザーの問い：設定を始める前に何を確認する必要があるか。
ページの役割：設定ツールへ進む前に前提条件を説明する。
キーメッセージ：開始前にアクセス権、互換性、必要記録を確認する。
必要な根拠：現行製品資料、問い合わせ記録、製品担当者による確認。
期待する行動：準備状況を判断し、正しいツールまたはサポート窓口へ進む。
形式：短い説明と前提条件のチェックリスト。
責任者：製品サポートコンテンツチーム。製品担当者とアクセシビリティ担当者を確認者とする。
見直し日：次回の予定日を記し、文書化された製品リリースも変更契機とする。

承認時は、対象読者と問いに根拠があるか、5つの判断から選んだ結論とページの役割を説明できるか、キーメッセージと必要な証拠が対応しているかを確認します。さらに、意味のある次の行動、形式を選ぶ理由、説明責任を持つ責任者、見直しの変更契機と日付がそろっているかを点検します。重要な回答が未検証、矛盾、空欄のままなら、原稿を割り当てず調査または修正へ戻します。アクセシビリティ、法務、規制、技術、データ、専門分野の判断が必要な主張は、該当する有資格者や担当専門家へ確認を依頼します。