行政書士のWordPress集客｜問い合わせ情報を守る5つの点検項目
WordPressサイトから相談は届いているものの、その内容がデータベース、メール、外部サービスのどこに保存されているか分からない。更新やバックアップを誰が担当しているか尋ねられても、保守会社に任せているとしか答えられない。このような状態では、問い合わせ経路に問題が起きたとき、確認先や復旧方法の特定に時間がかかります。
行政書士のWordPress集客では、フォームを設置するだけでなく、相談者が継続して利用できる受付経路として管理することが重要です。本記事では、問い合わせ情報の流れを起点に、管理画面、アカウント、更新、バックアップ、ログを点検する手順を解説します。行政書士本人が設定を変更しなくても、確認項目を一枚にまとめれば、Web制作会社や保守担当者との役割分担を整理できます。
なお、本記事は個別サイトの安全性や法令適合性を判定するものではありません。個人情報保護委員会のガイドラインでは、個人データを扱う情報システムについて、アクセス制御、不正アクセスの防止、ログの分析、通信の暗号化などが安全管理措置の例として示されています。ただし、フォームへ入力された情報が法令上の「個人データ」に該当するかは、保存、検索、利用の方法によって異なります。個別の該当性や必要な措置は、個人情報保護委員会の相談窓口または有資格者へご確認ください。本記事では、問い合わせ経路を維持するために、WordPressと運用体制の側で何を確認するかを扱います。
行政書士のWordPress集客は問い合わせ情報の流れから確認する
セキュリティ用のプラグインを探す前に、フォームから送信された情報がどこを通り、どこへ残るのかを確認します。保存先が分からなければ、誰のアクセスを制限するのか、何をバックアップするのかも決められないためです。
フォーム送信後の保存先を書き出す
相談者がフォームへ氏名、メールアドレス、電話番号、相談内容を入力したとします。送信後の扱いは、サイトの構成によって異なります。
通知メールだけが行政書士事務所へ送られる構成もあれば、同じ内容がWordPressのデータベースへ保存される構成もあります。外部の顧客管理システムやフォームサービスへ連携している場合もあります。また、バックアップやログに問い合わせ情報の一部が含まれる可能性もあります。
まずは、管理画面のフォーム設定、通知先メールアドレス、利用中の外部サービスを保守担当者と確認します。自分で設定画面を操作する必要はありません。「フォームの送信内容は、WordPress、メール、外部サービスのどこに保存されますか」と質問し、回答を記録します。
フォームが複数ある場合は、「初回相談」「見積依頼」「資料請求」など、フォームごとに分けてください。入力項目や保存先が異なる可能性があるためです。
閲覧できる人物と利用目的を照合する
次に、各保存先を誰が閲覧できるかを確認します。対象には、行政書士本人や職員だけでなく、Web制作会社、保守担当者、外部サービスの管理者も含めます。
確認の基準は、肩書ではなく担当業務です。たとえば、記事更新だけを担当する職員に、プラグインの追加やユーザー管理まで行える権限が必要とは限りません。一方、障害対応を担う保守会社には、一時的または継続的に広い権限が必要な場合があります。一律に人数を減らすのではなく、「その人が行う作業」と「現在付与されている権限」が一致しているかを照合します。
複数人で同じアカウントを使っている場合も記録してください。共有アカウントでは、不審な変更が見つかったときに、誰が操作したのかを確認しにくくなると考えられます。
一枚の情報フロー表を作る
問い合わせ情報の流れは、次の項目を一枚の表にすると把握しやすくなります。
- フォーム名
- 入力項目
- 保存先
- 通知先
- 閲覧できる人
- 現在の保存・削除方法
- バックアップへの収録の有無
- 確認担当者
- 最終確認日
不明な欄は推測で埋めず、「保守担当者へ確認」と記載します。この表はセキュリティ点検だけでなく、問い合わせメールが届かない、担当者へ引き継がれないといった集客導線の不具合を調べる際にも役立ちます。
管理画面への到達範囲とアカウント権限を点検する
問い合わせ情報の流れを整理したら、WordPress管理画面への入口と、ログイン後にできる操作を確認します。
IPAは、外部からWordPressの管理画面へ容易にアクセスできる状態では、パスワードの総当たりを試される可能性が高くなると説明しています。対策として、アクセス範囲の制限、初期的な管理ユーザー名の変更、WordPressの更新、多要素認証、管理操作ログの保存と確認などを挙げています。
管理画面へ外部から到達できる範囲を確認する
保守担当者へ、次の3点を尋ねます。
- インターネット上のどこから管理画面へ到達できるか
- IPアドレスによる制限、VPN、ホスティングサービス側の制御などを利用しているか
- 行政書士本人と制作会社が、どこから管理作業をしているか
IPAの資料には、管理画面を社内からのみアクセス可能にする方法が示されています。ただし、行政書士本人が外出先から更新する場合や、制作会社が遠隔で保守する場合は、利用環境に合わせた設計が必要です。WordPress公式文書も、すべてのサイトへ一律の接続方式を指定しているわけではありません。具体的な制御方法は、ホスティング環境と作業場所を保守担当者へ伝えたうえで決めます。
管理用URLの変更も補助的な対策にはなりますが、URLを隠すことだけに依存するのは適切ではありません。アクセス制御、認証、権限管理、更新などと組み合わせて考えます。
ユーザー、担当者、ロールを照合する
WordPress管理画面の「ユーザー」一覧を開くか、保守担当者から一覧を受け取ります。各アカウントについて、利用者、所属、必要な作業、現在のロールを記録してください。
WordPressの「管理者」は、プラグインやテーマの追加・更新、ユーザー管理、サイト設定の変更など、サイト全体へ影響する広い権限を持ちます。「編集者」は他者の記事を含む投稿を管理できますが、標準状態ではプラグインの追加やサイト設定の変更権限を持ちません。
ただし、「管理者は必ず1名」といった共通の人数基準は、今回確認した一次情報には示されていません。必要な保守作業があるのに権限だけを停止すると、更新や障害対応が滞る可能性があります。人数ではなく、担当業務に必要な権限かどうかで判断します。
特に確認したいのは、退職した職員、契約を終了した制作会社、担当者が分からないアカウントです。停止または権限変更を行う前に、そのアカウントが自動処理や保守作業に使われていないかを確認します。
認証方法とアカウント共有を見直す
各アカウントについて、強いパスワードと多要素認証の設定状況も確認します。多要素認証とは、パスワードに加え、認証アプリのコードなど別の要素を使って本人を確かめる方法です。WordPress公式文書は、強いパスワードに加える対策として二段階認証を推奨しています。
ただし、多要素認証を設定しても、不要な管理者権限、古いソフトウェア、未確認のログが自動的に解消されるわけではありません。認証は複数ある点検項目の一つとして扱います。
共有アカウントを利用している場合は、利用者ごとのアカウントへ分けられるかを保守担当者と検討します。分離が難しい場合も、利用者と用途を台帳へ記録し、パスワード変更時の連絡手順を決めておきます。
WordPress本体・テーマ・プラグインの更新手順を決める
WordPress公式文書は、本体を最新バージョンへ更新するよう案内しています。脆弱性を修正したバージョンが公開されると、古いバージョンの問題点が知られる可能性もあるため、更新状態を継続して確認する必要があります。
一方、更新によってテーマやプラグインとの互換性に問題が起きる場合もあります。行政書士サイトでは、更新の実施だけでなく、問い合わせフォームが更新後も動くかまでを一つの作業にします。
バージョンと自動更新の成否を分けて確認する
WordPress管理画面の「ダッシュボード」から「更新」を開くか、保守報告書を確認し、次の状態を分けて記録します。
- WordPress本体の現在のバージョン
- 利用中のテーマとプラグインのバージョン
- 自動更新が有効か
- 直近の自動更新が成功したか
- 主要バージョンの更新が保留されていないか
- 利用していないテーマやプラグインが残っていないか
WordPressには、対応可能なサイトへマイナー更新やセキュリティ更新を自動適用する仕組みがあります。ただし、自動更新の設定が有効であることと、直近の更新が成功していることは別です。また、更新通知が見当たらないという理由だけで、すべてが最新だとは断定できません。
更新前にバックアップと復元担当者を確認する
WordPress公式文書は、更新前にバックアップを作成し、問題が起きた場合に復元できるようにすることを案内しています。更新作業を依頼するときは、次の内容を一組で確認します。
- ファイルとデータベースのうち、必要な対象がバックアップされているか
- 更新前バックアップの最終成功日時
- 更新に問題が起きた場合の復元担当者
- 復元担当者への連絡方法
- 更新を中止または保留する条件
バックアップがあることと、古いソフトウェアを更新することは、互いを代替するものではありません。また、サイト構成によって互換性の確認方法が異なるため、すべてを一律に自動更新する設定が適切だとも限りません。
更新後に問い合わせ経路を動作確認する
更新後は、公開ページが表示されることだけで作業を終えず、フォームを実際にテストします。
- テスト用であることが分かる氏名と相談内容を入力します。
- 送信完了画面または完了メッセージが表示されるか確認します。
- 担当者へ通知メールが届くか確認します。
- 自動返信を設定している場合は、送信者側にも届くか確認します。
- WordPressや外部サービスへ保存する構成では、記録内容を確認します。
- エラーが出た場合は、発生時刻、操作した画面、表示された文言を記録して担当者へ連絡します。
この確認は、問い合わせ経路を安定して運用するための集客上の点検でもあります。フォームの見た目に問題がなくても、通知や保存が失敗していれば、相談への返信につなげられないためです。
バックアップとログを「使える状態」にする
バックアップは、保存されているだけでは復旧に使えるとは限りません。ログも、取得しているだけでは異常の発見や原因調査につながりません。それぞれについて、対象、担当者、確認方法まで決めます。
バックアップは有無以外の項目も確認する
保守担当者の管理画面や報告書で、次の項目を確認します。
- バックアップの対象
- 保存先
- 暗号化などの保護状況
- 保存している世代数
- 最終成功日時
- 失敗時の通知先
- 復元手順
- 復元テストの実施状況
WordPress公式文書では、データベースを含む定期的なバックアップや、サイト全体のスナップショットを信頼できる場所へ保存する方法が示されています。一方、すべての行政書士サイトに共通する保存頻度、世代数、保存期間の公式基準は、今回確認した一次情報にはありません。
たとえば、固定ページを年に数回しか更新しないサイトと、問い合わせ内容をWordPress内へ毎日保存するサイトでは、失いたくないデータと更新頻度が異なります。問い合わせ情報の保存先とサイトの更新頻度を示し、保守担当者と保存条件を決めてください。
複数世代と復元可能性を確認する
不審な変更や改ざんの発見が遅れた場合、直近のバックアップにも問題のある状態が含まれている可能性があります。そのため、WordPress公式文書では複数世代を残す考え方が例示されています。
ただし、世代数を増やすだけで復元できるとは限りません。必要なファイルが対象外だった、データベースが破損していた、保存先へアクセスできなかったという場合も考えられます。「バックアップがありますか」だけでなく、「どの時点の状態へ、誰が、どの手順で戻せますか」と確認します。
バックアップは、障害や改ざん後の復旧に用いる対策です。それ自体が不正アクセスや情報漏えいを防止するものではない点にも注意が必要です。
取得できるログと確認方法を整理する
ログとは、システムへのアクセスや操作の記録です。WordPress公式文書では、ログからIPアドレス、時刻、実行された操作などを確認でき、侵害後の調査に役立つと説明されています。IPAも、管理操作のログを残して定期的に確認することを対策として示しています。
ただし、WordPressの標準機能だけで「誰が、いつ、何を変更したか」という必要な履歴をすべて保存できるとは限りません。次の記録がどこにあるかを保守担当者へ確認します。
- WordPress上の記録
- ログイン履歴
- Webサーバーログ
- ホスティングサービスのログ
- 更新や設定変更の記録
- 監査ログ用プラグインなどの記録
特定のプラグインやサービスが、すべてのサイトに適しているわけではありません。欲しい記録、利用中のホスティング環境、運用負担を確認してから記録手段を決めます。
異常とみなす条件と連絡先を決める
ログの保存期間や確認頻度についても、行政書士サイト共通の公式基準は確認されていません。少なくとも、次の運用項目を決めておきます。
- ログを確認する担当者
- 通常と異なるログインや設定変更など、要確認とする条件
- 異常を見つけたときの一次連絡先
- 発生時刻、画面、ログなど初動で保存する情報
- ログの保存期間
- 定期確認の頻度
確認頻度は、問い合わせ情報の保存方法、更新作業の回数、保守契約の範囲を踏まえて決めます。すべてを行政書士本人が読む必要はありません。保守担当者が確認し、「問題なし」「要確認」「要対応」の区分と根拠を報告する形も考えられます。
保守担当者との責任分担を一枚にまとめる
制作会社へ保守を依頼している場合でも、必要な作業がすべて契約に含まれているとは限りません。「任せている」という認識だけでなく、作業ごとの担当者を確認します。
保守契約に含まれる作業を確認する
契約書、見積書、保守サービスの説明資料を開き、次の作業が含まれるかを照合します。
- アカウントの追加、変更、停止
- 多要素認証の設定支援
- WordPress本体、テーマ、プラグインの更新
- 更新前のバックアップ
- 更新後のフォーム動作確認
- バックアップ失敗時の対応
- ログの取得と確認
- 異常検知時の一次連絡
- 復旧作業
- 保守終了時のアカウント整理
「保守一式」としか記載されていない場合は、作業名ごとに実施の有無、頻度、報告方法を確認します。契約対象外の項目には、行政書士側の担当者または別の委託先を記入します。
定期報告を判断しやすい形にする
保守報告は技術用語を並べるだけでなく、行政書士本人が次の対応を判断できる形式にします。報告項目の例は次のとおりです。
- 点検対象期間
- 更新の実施結果
- 更新失敗または保留事項
- バックアップの最終成功日時
- アカウント変更の有無
- ログ確認の実施状況
- 対応が必要な事項
- 担当者
- 対応期限
各項目を「問題なし」「要確認」「要対応」に分け、理由を一文添えると確認しやすくなります。たとえば「要確認：プラグインAの更新を互換性確認のため保留。確認担当は制作会社、期限は8月15日」のように、状態、理由、担当者、期限を一緒に記載します。
担当変更と保守終了を見直しの契機にする
アカウントや連絡先は、一度整理しても古くなります。次の出来事があったときは、情報フロー表とアカウント台帳を再確認します。
- 制作会社を変更した
- 制作会社または事務所の担当者が退職・異動した
- 職員が入所または退所した
- サイトを改修した
- フォームや顧客管理システムを変更した
- 保守契約を終了または更新した
特に保守終了時には、制作会社のアカウント、バックアップの引き継ぎ、ログの保存先、障害時の連絡先を確認します。これらを契約終了後に調べ始めると、必要な情報へアクセスできない可能性があります。
まとめ
行政書士のWordPress集客では、セキュリティ対策を一つの設定や製品だけで捉えないことが重要です。最初に問い合わせ情報の保存先と閲覧者を明らかにし、管理画面への到達範囲、アカウント権限、更新、バックアップ、ログを組み合わせて点検します。
本記事で示した順序は、IPA、WordPress公式文書、個人情報保護委員会の資料を基に、編集部が「情報の流れ」「到達経路」「権限」「更新」「復旧と追跡」の順で整理したものです。公的機関がすべてのサイトへ一連の順番として指定した手順ではなく、個別サイトの安全性を保証するものでもありません。
今日から着手するなら、次の5項目を一枚の点検表へ書き出してください。
- 問い合わせ情報の保存先と閲覧者
- 管理画面へアクセスできる人物と各ロール
- WordPress本体、テーマ、プラグインの更新担当者
- バックアップの最終成功日時と復元担当者
- ログの確認担当者と異常時の連絡先
分からない項目には推測を書かず、「保守担当者へ確認」と記入します。そのうえで、点検表を添えて確認依頼を一度に送ります。回答を受け取ったら、「担当者」「確認方法」「次回確認日」の3欄を埋めてください。これにより、行政書士本人が技術設定を行わない場合でも、問い合わせ経路を誰がどのように維持しているかを判断できる状態へ近づけます。
出典一覧
- IPA「中小企業のための実例で学ぶサイバーセキュリティリスク事例集」（2026-03）
- WordPress.org「Hardening WordPress」（2026-01-07）
- WordPress.org「Roles and Capabilities」（2024-09-20）
- WordPress.org「Updating WordPress」（2024-09-15）
- 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」（2024-12）
この記事はAIが生成し、編集長のチェックを受けて公開しています。
