法人向けサービスサイトでは、料金改定や契約条件の変更が社内で決まっているのに、Webサイトだけ古いまま残ることがあります。原因は「Web担当者が更新していない」ことだけではありません。営業・事業・法務などが持つ元情報の変更を、誰がWeb担当へ伝え、誰が内容を確認し、いつまでに公開するか決まっていないことが問題です。
必要なのは、すべてをWeb担当者へ集約することではなく、料金・実績・契約条件などの情報ごとに「元情報の責任者」「変更を知らせる人」「承認者」「Web反映担当」「更新期限」を決めることです。
この記事では、法人向けサービスサイトの情報が古くならないための役割分担と更新フローを、実務で使える形に整理します。
サービス情報の更新は「Web担当者一人の仕事」にしない
法人向けサービスサイトの情報管理では、情報の正しさを保証する人と、Webサイトへ反映する人を分けることが基本です。
たとえば営業部門が新しい料金体系を最も早く把握しているなら、料金の元情報までWeb担当者が独自に管理する必要はありません。事業部がサービス仕様を決め、法務が契約条件を確認している企業であれば、それぞれの部門が自分たちの情報について責任を持ちます。
Web担当者は、各部門から確定情報を受け取り、サイト上で分かりやすく整理し、必要な確認を経て公開する役割を担います。
公的機関のWeb運用でも、情報の専門担当者が事実の正確性を持ち、Web・コンテンツ担当が掲載形式や公開を担当する分業が採用されています。Medway Councilは、専門担当者が情報の正確性を保ち、変更があればコンテンツ担当へ知らせる役割を明示しています。Westmorland and Furness Councilでも、サービス側・コンテンツオーナーが事実の正確性を担い、Webチームが利用しやすさや掲載形式を担う形です。
重要なのは、「サイトを触れる人=情報の責任者」としないことです。
Web運用全体の編集フロー・役割分担・品質チェックを整理する場合は、コンテンツ制作・運用体制の全体像も確認してください。
最初に料金・実績・契約条件ごとの「元情報」を決める
情報更新の仕組みを作るときは、Webページから考えるのではなく、その情報が社内のどこで決まっているかから整理します。
一例として、次のように分けられます。
| Webに掲載する情報 | 元情報を持つ部門の例 | 確認が必要な部門の例 | Web側の役割 |
|---|---|---|---|
| 料金・初期費用・月額費用 | 営業・事業責任者 | 経理・責任者 | 表示内容を反映 |
| サービス内容・対応範囲 | 事業部 | 営業 | サービスページを更新 |
| 導入実績・件数 | 営業・事業部 | 顧客担当・広報 | 掲載可否を確認して反映 |
| 導入事例 | 営業・顧客担当 | 顧客・広報 | 原稿・画像を整理して公開 |
| 契約期間・解約条件 | 事業部・法務 | 法務 | Web上の説明を更新 |
| キャンペーン・期間限定条件 | 営業・マーケティング | 責任者 | 開始・終了日に合わせて更新 |

料金や契約条件などの正しさを判断する担当と、Webへ反映する担当を分けると、確認先が明確になります。
この表で大切なのは、部署名そのものではありません。
自社について、「この数字・条件が正しいか最終的に答えられるのは誰か」を決めることです。
Webサイトの運用責任者だけ決めても、料金の確定権限や契約条件の判断権限までWeb担当者にあるとは限りません。情報の種類ごとに責任者を置いた方が、変更時の確認先が明確になります。
変更を検知できなければ更新フローは機能しない
更新責任を決めるだけでは不十分です。
料金改定、サービス内容の変更、契約条件の変更、新しい導入実績の追加などが起きたときに、Web更新が必要だと気づける仕組みまで決めます。
更新を始めるきっかけは、大きく2種類あります。
社内の変更をきっかけに更新する
たとえば、次のような変更です。
- 新料金が決定した
- プラン構成が変わった
- 提供対象地域が増えた
- 契約期間や解約条件が変わった
- 新サービスが追加された
- 掲載可能な導入実績が増えた
- サービス名称が変わった
この場合、「料金変更が確定したら営業責任者がWeb担当へ連絡する」といったルールを決めます。
重要なのは、Web担当者が会議や社内チャットを見回して変更を探す運用にしないことです。
定期確認で取りこぼしを見つける
すべての変更をリアルタイムに伝達できるとは限らないため、定期確認も必要です。
英国のDepartment for Educationのコンテンツ設計ガイドでも、コンテンツの正確性や最新性を維持する方法、変更の合意方法、メンテナンスの責任をあらかじめ決める考え方が示されています。Medway Councilでは「変更が起きたとき」に加え、少なくとも年1回のレビューも運用に含めています。
法人向けサービスサイトでは、情報の変わりやすさに合わせて確認頻度を変える方法が使えます。
| 情報 | 変更時の連絡 | 定期確認の例 |
|---|---|---|
| 料金 | 必須 | 月次・四半期 |
| キャンペーン | 必須 | 終了日前にも確認 |
| 契約条件 | 必須 | 四半期・半期 |
| サービス仕様 | 必須 | 四半期 |
| 導入実績 | 随時 | 月次・四半期 |
| 会社概要 | 変更時 | 半期・年次 |
これは一律の正解ではありません。自社で変更頻度と誤掲載時の影響を見ながら決めます。
「原本・変更検知・承認・反映・期限」の5項目を決める
各情報について、最低限5つの項目を整理すると更新責任が明確になります。

Web更新の担当者だけでなく、元情報の管理から公開期限まで一連の責任を決めることが更新漏れ防止につながります。
| 管理項目 | 決めること |
|---|---|
| 原本 | 何を正式情報として扱うか |
| 変更検知 | 誰が変更発生をWeb側へ伝えるか |
| 承認 | Web掲載内容を誰が最終確認するか |
| Web反映 | 誰がCMSへ反映するか(制作会社への依頼を含む) |
| 更新期限 | 変更確定後いつまでに反映するか |
たとえば料金であれば、次のように設計できます。
原本
事業部が管理する正式な料金表
変更検知
料金改定決定時に事業責任者からWeb担当へ連絡
承認
営業責任者が金額、法務担当が注記や契約条件を確認
Web反映
Web担当または制作会社
更新期限
新料金の適用開始前まで
ここまで決めると、「誰かが更新するはず」という状態から「変更が起きたらこの流れで更新する」という状態へ変わります。
情報によって承認ルートを変える
すべての更新を同じ承認フローにすると、簡単な修正まで止まりやすくなります。
国内のWebガバナンスに関する企業記事でも、コンテンツのリスクや種類によって承認フローを分ける設計が紹介されています。
たとえば、次の3段階で分けられます。

変更内容の重要度に応じて承認ルートを分けると、軽微な修正まで止めずに運用できます。
レベル1:Web担当だけで修正できる情報
- 誤字脱字
- 明らかなリンク切れ
- 表示崩れ
- 文章の読みやすさを改善する軽微な修正
元の意味や条件を変更しない範囲です。
レベル2:事業部の確認が必要な情報
- サービス内容
- 対応範囲
- 導入実績
- プラン名称
- サービス提供の流れ
Web担当だけでは事実確認できない内容を含みます。
レベル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・著者欄を標準化



