ホームページ情報の正本はどこに置く？更新元・担当者・確認日の管理方法

ホームページの情報が食い違う原因は、更新作業が遅いことだけではありません。料金は見積書、営業時間は店内掲示、サービス内容は営業資料、採用条件は求人票というように、元になる情報が別々の場所で決まり、ホームページだけが個別に書き換えられていることが大きな原因です。

対策は、すべての情報を一つのファイルへ移すことではありません。情報項目ごとに、どこを確認すれば確定内容が分かるかを一つ決め、その場所を示す台帳を作ることです。台帳には、正本の場所だけでなく、内容を決める責任者、公開前の承認者、最終確認日、次に確認する条件、反映先、変更履歴を残します。

この形なら、ホームページ、紙の案内、SNS、外部サービスに同じ情報を載せていても、「どれが最新か」を媒体同士で多数決する必要がありません。まず元情報を直し、掲載用の表現を確認し、各公開先へ順番に反映できます。

正本は一冊に集めるのではなく、情報項目ごとに決める

ここでいう「正本」とは、その情報について最終的に確認する更新元です。ホームページ全体の原稿ファイルを一冊作り、何でもそこへ集めるという意味ではありません。会社名は登記や会社情報台帳、料金は承認済み料金表、営業時間は運営責任者が管理する営業日程、採用条件は人事が確定した求人票というように、項目ごとに正本が異なっていて構いません。

むしろ、現場で実際に更新されている場所と別に「Web用の正本」を作ると、二重管理になりやすくなります。営業部が料金表を改定しても、Web用原稿へ伝わらなければ、ホームページには旧料金が残ります。正本を一か所へ寄せることより、どの情報はどこで決まり、誰が変更を知らせるかを明確にする方が重要です。

情報は、次の三つの層に分けると整理しやすくなります。

1. 元情報：事業側で確定した事実や条件。料金、受付時間、対象地域、サービス範囲、採用条件など。
2. 公開文：元情報を利用者に伝わる表現へ整え、公開してよいと承認された文章や表。
3. 掲載先：ホームページ、PDF、パンフレット、SNS、地図サービス、予約サービスなど、公開文を反映する場所。

たとえば「電話受付は平日17時まで」という元情報が決まっていても、ホームページでは「平日9:00〜17:00」、自動返信メールでは「翌営業日までに確認します」など、媒体の役割に合わせて表現が変わることがあります。表現が違うこと自体は問題ではありません。どちらも同じ元情報から作られ、変更時に一緒に確認できる状態なら、運用上の整合性を保てます。

図：元情報を確定し、掲載用の文章を承認してから各掲載先へ反映します。台帳は三つの層をつなぐ索引として使います。

最初に作る台帳は、ページ一覧ではなく情報項目の一覧

ホームページの管理表というと、トップページ、会社案内、サービスページといったページ一覧を作りがちです。しかし、一つの情報が複数ページへ出る場合、ページ単位の表だけでは変更漏れを見つけにくくなります。会社名や電話番号はヘッダー、フッター、会社概要、問い合わせ完了メール、PDFなどに重複していることがあります。料金や受付条件も、サービスページだけでなく比較表、FAQ、申込フォームの説明文に出ているかもしれません。

そこで、台帳の一行は「ページ」ではなく「情報項目」にします。最初から全項目を完璧に洗い出す必要はありません。間違ったときの影響が大きい情報から始め、更新が発生するたびに行を追加します。

最低限、次の項目があると実務で使えます。

台帳の項目	記録する内容
管理ID・情報項目	「料金A」「電話受付時間」など、変更対象を特定できる名称
正本・参照先	元情報が確定するファイル、システム、担当部署、保管場所へのリンク
内容責任者	事業上の内容を決め、正しさに責任を持つ人または部署
承認者	外部へ公開してよい表現かを確認する人
反映担当	CMS、PDF、SNSなどへ実際に反映する人。外部制作会社でもよい
最終確認日	正本と公開内容を見比べた日。変更がなかった場合も記録する
次回確認条件	定期確認日、価格改定、休業決定、採用開始など、再確認する時点
掲載先	URL、PDF名、フォーム画面、自動返信、外部サービスの該当箇所
状態	未確認、確認中、承認済み、反映中、反映済み、差し戻しなど
変更記録	変更理由、変更前後、承認日、反映確認、直前版の場所

台帳は、正本そのものを複製する場所ではありません。たとえば料金表が業務システムで管理されているなら、台帳へ全料金を転記せず、「料金マスターのどの画面を確認するか」を記録します。転記を増やすほど、正本と台帳のどちらを直すべきかが曖昧になるからです。

一方、口頭で決まる情報は、そのままでは正本になりません。「社長が言っていた」「前回の会議で決まった」という状態では、担当者が変わったときに確認できません。承認済みの議事録、決裁記録、共有ファイルなど、後から同じ内容を確認できる形へ残します。

台帳へ最初に入れたいのは、会社名・所在地・連絡先、価格や支払条件、営業時間・休業日、申込条件、サービス範囲、採用条件、法令上必要な表示、終了日のあるキャンペーンなどです。誤りが問い合わせ、契約、来店、応募に直接影響する項目を優先します。ブログ記事の細かな表現や更新頻度の低い紹介文は、その後で構いません。

なお、台帳へパスワードや秘密鍵を直接書くのは避けます。アカウントの管理者、保管方法、権限申請先までを台帳に示し、認証情報はアクセス制御された別の仕組みで管理します。情報の正本管理と認証情報の管理は、同じ一覧で無理に兼用しない方が安全です。

正本の置き場所は、更新される現場と履歴の残し方で選ぶ

正本を置く道具は、共有スプレッドシート、文書、社内データベース、販売管理システム、予約システム、CMSなど、組織によって異なります。「ホームページに関する情報だからWordPressを正本にする」と決める必要はありません。料金を日常的に管理しているのが販売管理システムなら、そこを正本とし、ホームページは公開先として扱う方が自然です。

置き場所を選ぶときは、機能の多さより次の条件を確認します。

• 内容責任者が日常業務で使っており、変更時に無理なく更新できる
• 正本の場所を台帳から迷わず開ける
• 閲覧、編集、承認の権限を役割に合わせて分けられる
• 誰がいつ変更したか、または少なくとも版を戻せる履歴が残る
• 担当者が不在でも、代行者が必要な範囲へアクセスできる
• ファイル名や保存場所が頻繁に変わらず、リンク切れを起こしにくい
• バックアップや復旧方法が分かっている

共有ドライブのファイルや文書管理サービスには、変更履歴や過去版の確認機能があるものがあります。ただし、「履歴機能があるから安心」とは限りません。保存期間や保持件数、復元権限はサービスや設定で変わります。重要な変更では、利用中の仕組みで直前版をいつまで保持できるか、誰が復元できるかまで確認します。

正本を一つのツールへ統一できない場合は、台帳を「索引」にします。台帳の各行から、料金マスター、営業日程、求人票、会社情報、商品データなど、実際の正本へ移動できるようにします。これなら、各部署が使い慣れた仕組みを保ちつつ、Web担当者は更新元を探し回らずに済みます。

紙の契約書や承認印のある書類が正本になる情報もあります。その場合は、保管部署、文書名、版、決裁日を台帳に記録し、公開文の作成時に参照できるコピーを用意します。紙を無理に廃止することより、変更がWeb担当者へ届く連絡経路を決めることが先です。

担当者は「決める・承認する・反映する」に分けて考える

「更新担当」を一人だけ決めても、その人が内容の正しさまで判断できるとは限りません。Web担当者や制作会社は文章や画面を更新できますが、料金改定、営業日の変更、サービス提供条件、採用条件を独自に決める立場ではないことが多いからです。

役割は、少なくとも次の三つに分けます。

• 内容責任者：元情報を決める。営業、店舗運営、人事、総務など、該当業務を担当する人や部署。
• 承認者：公開文が元情報と一致し、外部へ出してよいかを確認する。必要に応じて経営者、部門責任者、法務確認者などを置く。
• 反映担当：承認済みの内容をホームページや各媒体へ反映し、表示結果を確認する。社内担当者または外部パートナー。

小規模な組織では、同じ人が二つ以上の役割を兼ねても問題ありません。ただし、役割名は分けて記録します。たとえば経営者が内容を決めて承認し、制作会社が反映する場合、「経営者・制作会社」とだけ書くより、誰が何を終えれば次へ進めるかが明確になります。

個人名だけで管理すると、異動や退職のたびに台帳全体を書き換える必要があります。まず「営業責任者」「店舗運営担当」「採用責任者」のように役割や部署を決め、その欄に現担当者と代行者を紐づけると引き継ぎやすくなります。休暇や急な不在に備え、重要情報には代行者または最終判断者も決めます。

変更連絡の入口も一つ決めます。口頭、個人チャット、メール、会議メモから別々に依頼が来ると、承認前の案と確定内容が混ざります。「変更依頼は台帳の該当行へ記録する」「承認済みになったら反映担当へ通知する」など、確定状態が分かる経路を使います。急ぎの電話連絡が必要な場合も、作業後に同じ台帳へ理由と結果を追記します。

反映担当は、曖昧な依頼を推測で補いません。「来月から値上げします」だけでは、対象サービス、税込・税別、適用日、既存顧客の扱い、申込フォームやPDFへの反映範囲が分かりません。内容責任者へ確認し、元情報と公開文が確定してから更新します。更新速度より、判断権限の境界を守ることが食い違い防止につながります。

最終確認日と「次に確認する条件」を分けて残す

最終更新日だけでは、その情報が現在も正しいか判断できません。三年前に公開した料金が一度も変わっていない場合、最終更新日は三年前のままですが、先月に現行料金と照合していれば、情報の信頼性は高まります。反対に、昨日ページを編集していても、誤字を直しただけなら料金を確認したことにはなりません。

そこで、台帳では「最終変更日」と「最終確認日」を分けます。

• 最終変更日：内容が実際に変わった日
• 最終確認日：正本と公開内容を照合し、変更の有無を確認した日

確認結果が「変更なし」でも、確認日と確認者を残します。これにより、担当者が交代したときに、古い表示を一から疑う範囲を狭められます。

次回確認は、日付だけでなく出来事でも設定します。情報によって変わり方が違うためです。会社概要や恒常的なサービス説明は半年ごと・年ごとでも運用できますが、休業日、採用募集、期間限定企画は、決定や終了のたびに確認する必要があります。

たとえば、次のように設定します。

情報の種類	次に確認する条件の例
料金・支払条件	価格改定の決裁時、見積書のひな形変更時、定期確認日
営業時間・受付時間	休業日決定時、季節営業への切替時、担当体制変更時
サービス内容・対応範囲	新サービス開始時、提供停止時、契約条件変更時
採用情報	募集開始・停止時、条件変更時、求人媒体の更新時
キャンペーン	公開前、内容変更時、終了直後
会社情報	移転、代表変更、組織変更、連絡先変更の決定時

日付による定期確認と、出来事による臨時確認を併用すると、重要な変更を次の棚卸しまで放置しにくくなります。台帳に「毎年4月確認」とだけ書くのではなく、「料金改定決裁時にも確認」のように、事業上のきっかけを加えます。

状態欄も役立ちます。「未確認」「元情報確認中」「公開文承認待ち」「反映中」「反映済み」「再確認が必要」など、組織で使う状態を少数に絞ります。細かく増やしすぎると入力が負担になるため、次に誰が動くか分かる程度で十分です。

公開先は媒体名ではなく、URL・画面・部品まで特定する

「ホームページへ反映」とだけ書いても、どこを直すかは分かりません。同じ情報が、トップページ、サービスページ、料金表、FAQ、フッター、問い合わせフォーム、完了画面、自動返信メールに出ていることがあります。PDFの会社案内や画像内の文字は、CMS内検索で見つからない場合もあります。

掲載先は、後から同じ場所を開ける粒度で記録します。

• 公開ページのURLと、見出し名・表の行・画面内の位置
• 共通ヘッダー、フッター、サイドバーなどの共通部品
• 問い合わせ・予約フォームの入力前説明、確認画面、完了画面
• 自動返信メール、通知メール、予約完了メールのテンプレート
• PDF、画像、ダウンロード資料のファイル名と掲載ページ
• SNSの固定投稿、プロフィール、リンク先案内
• Googleビジネスプロフィールや予約サービスなどの外部画面
• 検索結果用のタイトル・説明、構造化データなど、ページ本文以外の表示

URLだけでは特定できない場合は、管理画面のメニュー名、テンプレート名、ファイル名も添えます。ただし、管理画面URLや内部パスを公開用の資料へ混ぜず、アクセス権のある運用台帳で管理します。

反映順は、元情報の変更、公開文の承認、影響の大きい掲載先、残りの掲載先、全体照合の順にします。先にホームページだけ直し、後から元資料を直す流れにすると、途中で作業が止まったときにWebの内容だけが先行します。元情報を先に確定すれば、他媒体の担当者も同じ内容を参照できます。

複数人で同時に反映する場合は、「反映済み」の一言ではなく、掲載先ごとに結果を記録します。ホームページは完了、PDFは差し替え待ち、SNSは予約投稿済みというように分ければ、全体が終わっていないのに完了扱いになることを防げます。最後に、公開画面を正本と見比べ、日付、単位、税込・税別、リンク先、申込条件など、利用者の判断に影響する部分を確認します。

営業時間、電話受付、予約申込、返信目安のように、似ていても意味が異なる時間情報を整理する場合は、ホームページの営業時間・電話受付・予約申込・返信目安はどう分ける？掲載場所と更新の整理表で、項目の分け方を先に確認できます。本記事の台帳は、そのように分けた各項目の正本と反映先を継続管理するために使います。

変更履歴には、変更理由と戻し方まで残す

変更履歴で必要なのは、「誰が更新したか」だけではありません。後から見た人が、なぜ変えたのか、どの範囲へ反映したのか、誤りが見つかったときにどこまで戻せばよいかを判断できることが大切です。

一回の変更について、次の情報を残します。

• 変更日と依頼者
• 対象の管理ID・情報項目
• 変更前と変更後の内容、または差分を確認できる版
• 変更理由と根拠になった決裁・資料
• 内容責任者と承認者
• 反映したURL、ファイル、外部サービス
• 公開後に確認した人と確認日時
• 直前版の保管場所、差し戻し時の連絡先

文書管理サービスやCMSに版履歴があっても、「なぜその変更をしたか」までは自動で残らないことがあります。更新記録には、「価格改定のため」「休業日決定のため」「誤記訂正のため」のように、後から判断できる理由を短く書きます。

差し戻しでは、ページ全体を古い版へ戻せばよいとは限りません。古い版へ戻すと、その後に追加した別の修正まで消える可能性があります。料金だけを戻すのか、公開文全体を戻すのか、PDFやSNSも同時に戻すのかを、情報項目と掲載先の一覧から判断します。重要な更新では、変更前の表示やファイルを保存し、反映後に問題があった場合の戻し方を作業前に確認します。

誤りが公開された場合は、まず影響の大きい掲載先を訂正し、次に同じ情報を使う場所を台帳で洗い出します。その後、なぜ漏れたかを「担当者の注意不足」で終わらせず、正本が曖昧だったのか、承認状態が分からなかったのか、掲載先が台帳に足りなかったのかを見直します。履歴は責任追及のためではなく、次の変更を安全にするための材料です。

重要な10項目から始め、更新のたびに台帳を育てる

正本管理を始めるために、大規模なシステム導入や全ページの一斉棚卸しは必須ではありません。まず、問い合わせや契約に影響しやすい情報を十項目ほど選びます。各項目について、現在の正本、内容責任者、承認者、最終確認日、掲載先を書き出します。分からない欄は推測で埋めず、「未確認」として、誰に確かめるかを決めます。

次に、正本と公開中の内容を見比べます。食い違いがあれば、ホームページの文だけを先に直すのではなく、どちらが正しいかを内容責任者が確定し、公開文を承認してから各掲載先へ反映します。完了後に確認日と変更理由を残せば、その一回の更新が台帳の整備にもなります。

運用開始後は、新しい料金、休業案内、採用募集、サービス変更などが発生するたびに、台帳へ行や掲載先を追加します。更新依頼の受付、承認、反映確認を同じ流れへ載せると、台帳は作って終わる資料ではなく、日々の更新手順になります。

ホームページを情報の正本にするべき場合もあります。たとえば、公開ページでのみ管理するお知らせ本文や、Web上で確定する記事コンテンツです。しかし、事業上の条件が別の業務資料やシステムで決まるなら、ホームページは正本ではなく公開先です。情報項目ごとに正本を決め、担当者、確認日、次の確認条件、掲載先、変更理由を一つの台帳で結ぶことが、複数人・複数媒体でも更新を止めない管理方法です。