法人向けサービスサイトでは、料金改定や契約条件の変更が社内で決まっているのに、Webサイトだけ古いまま残ることがあります。原因は「Web担当者が更新していない」ことだけではありません。営業・事業・法務などが持つ元情報（料金や契約条件のように、社内で決まる情報の大元）が変わったとき、誰がWeb担当者へ伝え、誰が内容を確認し、いつまでに公開するかが決まっていないことが問題です。
必要なのは、すべてをWeb担当者へ集約することではありません。料金・実績・契約条件などの情報ごとに、「元情報の責任者」「変更を知らせる人」「承認者」「Web反映担当」「更新期限」を決めることです。
この記事では、法人向けサービスサイトの情報が古くならないための役割分担と更新フローを、実務で使える形に整理します。読み終えると、まず何から決めればよいかが分かり、1枚の管理表から運用を始められます。
サービス情報の更新は「Web担当者一人の仕事」にしない
法人向けサービスサイトの情報管理では、最初に情報の正しさを保証する人と、Webサイトへ反映する人を分けることが基本になります。
たとえば営業部門が新しい料金体系を最も早く把握しているなら、料金の元情報までWeb担当者が独自に管理する必要はありません。事業部がサービス仕様を決め、法務が契約条件を確認している企業であれば、それぞれの部門が自分たちの情報について責任を持ちます。
そのうえでWeb担当者は、各部門から確定情報を受け取り、サイト上で分かりやすく整理し、必要な確認を経て公開する役割を担います。
この分け方は、公的機関のWeb運用でも採用されています。Medway Councilは、専門担当者が情報の正確性を保ち、変更があればコンテンツ担当へ知らせる役割を明示しています。Westmorland and Furness Councilでも、サービス側・コンテンツオーナーが事実の正確性を担い、Webチームが利用しやすさや掲載形式を担う形としています。
つまり、サイトを触れる人を、そのまま情報の責任者にしないことが出発点です。
Web運用全体の編集フロー・役割分担・品質チェックを整理したい場合は、コンテンツ制作・運用体制の全体像も確認してください。
まず料金・実績・契約条件ごとに「元情報」の持ち主を決める
この節では、情報の種類ごとに、元情報を持つ部門を決めます。Webページから考えるのではなく、その情報が社内のどこで決まっているかから整理するのがコツです。
次の表は、Webに掲載する情報ごとに、元情報を持つ部門、確認が必要な部門、Web側の役割を整理した一例です。部門名は企業によって異なるため、自社の組織に置き換えて読んでください。
| Webに掲載する情報 | 元情報を持つ部門の例 | 確認が必要な部門の例 | Web側の役割 |
|---|---|---|---|
| 料金・初期費用・月額費用 | 営業・事業責任者 | 経理・責任者 | 表示内容を反映 |
| サービス内容・対応範囲 | 事業部 | 営業 | サービスページを更新 |
| 導入実績・件数 | 営業・事業部 | 顧客担当・広報 | 掲載可否を確認して反映 |
| 導入事例 | 営業・顧客担当 | 顧客・広報 | 原稿・画像を整理して公開 |
| 契約期間・解約条件 | 事業部・法務 | 法務 | Web上の説明を更新 |
| キャンペーン・期間限定条件 | 営業・マーケティング | 責任者 | 開始・終了日に合わせて更新 |
料金や契約条件などの正しさを判断する担当と、Webへ反映する担当を分けると、確認先が明確になります。
この表で見てほしいのは、部署名そのものではありません。自社について、「この数字・条件が正しいか最終的に答えられるのは誰か」を決めることです。
Webサイトの運用責任者だけを決めても、料金の確定権限や契約条件の判断権限までWeb担当者にあるとは限りません。情報の種類ごとに責任者を置いておけば、変更が起きたときの確認先に迷わずに済みます。
Web更新が必要な変更に、どうやって気づくか
更新責任を決めるだけでは足りません。料金改定、サービス内容の変更、契約条件の変更、新しい導入実績の追加などが起きたときに、Web更新が必要だと気づける仕組みまで決めておく必要があります。この仕組みを、次の節では「変更検知」と呼びます。
きっかけは、大きく2種類あります。社内の変更をきっかけにする場合と、定期確認で取りこぼしを見つける場合です。
社内の変更が起きたときに更新する
たとえば、次のような変更が当てはまります。
- 新料金が決定した
- プラン構成が変わった
- 提供対象地域が増えた
- 契約期間や解約条件が変わった
- 新サービスが追加された
- 掲載可能な導入実績が増えた
- サービス名称が変わった
この場合は、「料金変更が確定したら営業責任者がWeb担当者へ連絡する」といったルールを決めます。Web担当者が会議や社内チャットを見回して変更を探す運用にはしません。探す側に回すと、見落としが起きたときに誰も気づけないためです。
定期確認で取りこぼしを見つける
すべての変更をリアルタイムに伝達できるとは限らないため、定期確認も組み合わせます。
英国のDepartment for Educationのコンテンツ設計ガイドでも、コンテンツの正確性や最新性を維持する方法、変更の合意方法、メンテナンスの責任をあらかじめ決める考え方が示されています。Medway Councilでは「変更が起きたとき」に加え、少なくとも年1回のレビューも運用に含めています。
法人向けサービスサイトでは、情報の変わりやすさに合わせて確認頻度を変える方法が使えます。次の表は、情報ごとの変更時の連絡と定期確認の例です。
| 情報 | 変更時の連絡 | 定期確認の例 |
|---|---|---|
| 料金 | 必須 | 月次・四半期 |
| キャンペーン | 必須 | 終了日前にも確認 |
| 契約条件 | 必須 | 四半期・半期 |
| サービス仕様 | 必須 | 四半期 |
| 導入実績 | 随時 | 月次・四半期 |
| 会社概要 | 変更時 | 半期・年次 |
表では、料金・キャンペーン・契約条件・サービス仕様を「変更時の連絡は必須」とし、導入実績は随時、会社概要は変更時に連絡する形にしています。定期確認の頻度は、情報の変わりやすさに合わせて変えています。これは一律の正解ではありません。自社で変更頻度と誤掲載時の影響を見ながら決めます。
更新責任は「原本・変更検知・承認・反映・期限」の5項目で決める
この節では、情報ごとに最低限5つの項目を決めて、更新責任を明確にします。ここでいう原本は、正式な情報として扱う資料やデータのことです。冒頭の「元情報の責任者」は、この原本を管理する人を指します。
Web更新の担当者だけでなく、元情報の管理から公開期限まで一連の責任を決めることが更新漏れ防止につながります。
次の表は、5項目それぞれで決めることをまとめたものです。
| 管理項目 | 決めること |
|---|---|
| 原本 | 何を正式情報として扱うか |
| 変更検知 | 誰が変更発生をWeb側へ伝えるか |
| 承認 | Web掲載内容を誰が最終確認するか |
| Web反映 | 誰がCMSへ反映するか（制作会社への依頼を含む） |
| 更新期限 | 変更確定後いつまでに反映するか |
たとえば料金であれば、次のように設計できます。部門名はあくまで一例です。
- 原本：事業部が管理する正式な料金表
- 変更検知：料金改定決定時に事業責任者からWeb担当者へ連絡
- 承認：営業責任者が金額、法務担当が注記や契約条件を確認
- Web反映：Web担当者または制作会社
- 更新期限：新料金の適用開始前まで
ここまで決めると、「誰かが更新するはず」という状態から、「変更が起きたらこの流れで更新する」という状態へ変わります。
承認ルートは情報の種類ごとに分ける
すべての更新を同じ承認フローにすると、簡単な修正まで止まりやすくなります。そこで、変更の重みに応じて承認ルートを分けます。
国内のWebガバナンスに関する企業記事でも、コンテンツのリスクや種類によって承認フローを分ける設計が紹介されています。
ここでは、次の3段階に分ける例を挙げます。
変更内容の重要度に応じて承認ルートを分けると、軽微な修正まで止めずに運用できます。
レベル1：Web担当者だけで修正できる情報
元の意味や条件を変更しない範囲の修正です。
- 誤字脱字
- 明らかなリンク切れ
- 表示崩れ
- 文章の読みやすさを改善する軽微な修正
レベル2：事業部の確認が必要な情報
Web担当者だけでは事実確認できない内容を含むため、事業部に確認します。
- サービス内容
- 対応範囲
- 導入実績
- プラン名称
- サービス提供の流れ
レベル3：複数部門の承認が必要な情報
誤りがあると影響が大きい情報です。内容によって営業、事業責任者、法務などを加えます。
- 料金
- 契約条件
- 解約条件
- 保証に関する表現
- 実績数値
- 法令・規約に関係する表示
なお、実績は掲載内容の確認がレベル2、件数などの実績数値の確認がレベル3にあたります。
CMS側でも、ページの変更後に承認を求めるワークフローを設定できる仕組みがあります。Microsoft SharePointでは、更新されたページを公開する前に承認要求を行うページ承認フローが提供されています。
ただし、ツールを導入する前に「誰が何を承認するか」を決めることが先です。
料金・契約条件は、適用開始日とWeb反映日をセットで管理する
この節では、料金や契約条件の日付をどう管理するかを決めます。「最新版がどれか」だけでなく、いつからその条件を適用するのかも押さえる必要があるためです。
たとえば10月1日から料金が変わる場合、社内料金表だけ9月中に変更され、Webサイトが10月中旬まで旧料金のままであれば、営業資料とWebの情報が食い違います。
料金や契約条件は、正式決定日だけでなく適用開始日とWeb更新日までセットで管理します。
このずれは、決定日だけを管理していると見逃されます。そのため、変更管理表には次の項目を入れておくと確認しやすくなります。
- 変更内容
- 正式決定日
- 適用開始日
- Web更新予定日
- 対象ページ
- 元情報の責任者
- 承認者
- 反映担当
- 公開確認日
消費者向け表示については、消費者庁も商品・サービスの価格などの取引条件を正確かつ明瞭に表示する必要性を示しています。また、価格などの取引条件についても、表示内容を確認するための管理措置が求められると説明しています。
法人向けサービスでは取引形態や適用法令が異なるため、個別の確認が必要です。それでも、Web上の価格・条件と正式な取引条件の不一致を防ぐ運用自体は重要です。
実績は件数だけでなく、掲載の根拠と条件も管理する
導入実績は、料金とは違う更新事故が起きやすい情報です。たとえば、次のような状態があります。
- 累計導入数が古い
- 顧客ロゴの掲載許可期間が切れている
- 以前提供していたサービスの事例が残っている
- 現在とは異なる成果条件の事例が掲載されている
そのため、実績は数字だけでなく、何を根拠に掲載しているかまで管理します。次の表は、実績について確認する項目と内容です。
| 管理項目 | 確認内容 |
|---|---|
| 実績数値 | 集計元と集計期間 |
| 顧客名・ロゴ | 掲載許可の有無 |
| 成果 | 何を測定した数字か |
| サービス内容 | 現在も提供している内容か |
| 更新日 | 最後に確認した日 |
| 責任者 | 数字・事例を確認できる担当者 |
Web担当者が過去資料から数字を拾って更新するのではなく、元データを持つ担当者から確定情報を受け取る形にします。
制作会社に更新を任せても、情報の責任は社内に残す
Webサイトの更新を制作会社へ依頼している場合でも、「公開作業」と「情報の正しさ」は分けて考えます。
制作会社が担当できるのは、たとえば次の範囲です。
- CMSへの反映
- レイアウト調整
- 表や画像の修正
- 公開前の表示確認
- 更新履歴の記録
一方、料金が正しいか、契約条件が現在の社内ルールと一致しているか、実績数字が最新かどうかは、原則としてその情報を持つ社内担当者が確認できる状態にします。外注先へ「最新情報にしておいてください」とだけ依頼しても、制作会社側は社内の変更を知ることができないためです。
そこで、制作会社への依頼書にも、次の順序を明確に書いておきます。
元情報 → 承認済み情報 → Web反映 → 公開確認
この順序があれば、責任範囲を切り分けやすくなります。
更新漏れを防ぐ管理表は、1枚から始める
大規模な管理システムを最初から導入する必要はありません。まずは主要なサービス情報だけを一覧にします。次の表は、その一例です。
| 情報項目 | 原本部署 | 変更通知 | 承認者 | Web反映 | 更新期限 | 最終確認日 |
|---|---|---|---|---|---|---|
| 基本料金 | 事業部 | 事業責任者 | 営業責任者 | Web担当 | 適用開始前 | YYYY/MM/DD |
| 契約期間 | 事業部 | 事業責任者 | 法務 | Web担当 | 変更適用前 | YYYY/MM/DD |
| 導入実績 | 営業 | 営業担当 | 営業責任者 | Web担当 | 月次 | YYYY/MM/DD |
| 導入事例 | 営業 | 顧客担当 | 顧客・広報 | 制作会社 | 随時 | YYYY/MM/DD |
| 対応範囲 | 事業部 | 事業担当 | 事業責任者 | Web担当 | 変更時 | YYYY/MM/DD |
ポイントは、「Web担当」という列だけを作らないことです。誰が正しい情報を持っているか、誰が変更を知らせるか、誰が承認するかまで1枚で確認できるようにします。
まず自社サイトで確認する5つの問い
運用体制を作り直す場合は、主要サービスページを開き、次の5つの問いから確認すると始めやすくなります。
- この情報の正式な元データはどこにあるか
- 内容が変わったとき最初に知る部署はどこか
- Web掲載内容を承認できる人は誰か
- 誰がサイトへ反映するか
- 変更から何日以内に更新するか
特に料金・実績・契約条件から始めると、複数部署にまたがる情報管理上の抜けを見つけやすくなります。その後、対応地域、サービス仕様、導入フロー、よくある質問などへ対象を広げます。
まとめ
法人向けサービスサイトの情報を最新に保つために必要なのは、Web担当者へ責任を集中させることではありません。
料金・実績・契約条件などの情報ごとに、
原本を持つ部署 → 変更を知らせる人 → 承認者 → Web反映担当 → 更新期限
を決めることが基本です。
社内では新しい情報へ変わっているのに、Webサイトだけ古いという状態は、公開作業だけを改善しても解決しません。変更が発生した時点からWeb更新へつながる流れを作る必要があります。
まずは主要なサービス情報を一覧にし、「情報項目×原本部署×承認者×更新期限」を整理してみてください。
参考文献・データ元
この記事で参照した情報を確認できます。
- Department for Education「Content strategies」：https://design.education.gov.uk/content-design/content-strategies
- Medway Council「How we maintain content」：https://www.medway.gov.uk/homepage/945/how_we_maintain_content
- Westmorland and Furness Council「Publishing process」：https://www.westmorlandandfurness.gov.uk/design-and-content-guidelines/publishing-principles/publishing-process
- Microsoft Support「モダン ページの承認フロー」：https://support.microsoft.com/ja-jp/sharepoint/sites-pages/approval-flow-for-modern-pages
- 消費者庁「インターネット上の広告表示」：https://www.caa.go.jp/policies/policy/representation/fair_labeling/representation_regulation/internet
- 消費者庁「指針に関するQ&A」：https://www.caa.go.jp/policies/policy/representation/fair_labeling/faq/guideline
‹ 親記事: コンテンツ制作・運用体制とは？編集フロー・役割分担・品質チェックの仕組みを体系的に整理
関連記事
- › 記事品質チェックリストの作り方｜編集基準・校正・根拠確認・公開承認を標準化する
- › SEO記事のコンテンツブリーフ作成方法｜検索意図・見出し・根拠・内部リンクを制作前に定義する
- › オウンドメディアの著者・監修者設計｜誰が書き、誰が確認したかを記事単位で明示する方法
- › オウンドメディア編集部の作り方｜編集長・ライター・監修者・SEO担当の役割分担
- › 記事の更新期限を決める方法｜鮮度・重要度・順位下落で判断
- › 記事の出典・根拠を管理するエビデンス台帳の作り方｜更新期限・一次情報・引用箇所を追跡
- › オウンドメディアの編集権限・版管理を設計する方法｜誤公開・上書き・承認漏れを防ぐ
- › 生成AIを記事制作に使う運用ルールの作り方｜利用範囲・人間レビュー・機密情報を管理
- › 記事の出典を定期確認｜リンク切れ・情報鮮度・一次情報をチェック
- › オウンドメディアのアクセス権限を定期確認｜退職・異動時の対応
- › 生成AIを使った記事制作の検証ログを作る方法｜プロンプト・根拠確認・修正履歴を残す
- › コンテンツ制作の遅れを確認｜企画・執筆・確認・公開を可視化
- › 外注記事の受入れ基準を作る方法｜納品形式・根拠・著作権・修正責任を標準化
- › オウンドメディアの画像・図版ライセンスを管理する方法｜出典・利用範囲・期限を台帳化
- › 外注ライター・制作会社の評価スコアカードを作る方法｜品質・納期・修正回数・専門性を継続評価
- › オウンドメディアの緊急訂正・公開停止フロー｜訂正・一時非公開・削除の判断基準と復旧手順
- › 法人向けサービスページの比較表の作り方｜料金・対象・対応範囲・実績・契約条件を同じ軸で整理
- › 導入事例ページの作り方｜成果数値・導入期間・取り組み内容
- › オウンドメディア担当者の引き継ぎチェックリスト｜記事・CMS・編集ルール・分析データ・進行中企画を整理
- › 導入事例ページの作り方｜業種・課題・成果で探せる構成と導線
- › 法人向けサービスページのFAQの作り方｜料金・対象・導入条件・契約・セキュリティの質問を整理
- › 法人向けサービスページの導入フローの作り方｜期間・準備物・担当・例外条件まで整理
- › 法人向けサービスのセキュリティ情報の載せ方｜認証・データ保管・権限・問い合わせ先の整理方法
- › オウンドメディアの表記ガイドラインの作り方｜表記ゆれ・数字・固有名詞・引用ルールを統一
- › オウンドメディアのインタビュー記事の作り方｜企画・質問設計・取材・原稿確認・公開まで
- › オウンドメディアの記事テンプレートの作り方｜原稿フォーマット・出典・CTA・FAQ・著者欄を標準化
- › Claudeの料金プラン比較｜無料・Pro・Team・法人向けの選び方
- › NotebookLMの使い方｜資料の読み込み・要約・質問の基本手順
