ホームページの制作を外部に依頼するとき、デザインやページ構成は細かく決めても、セキュリティは「ちゃんとやってください」の一言で済ませてしまうことがあります。しかし、公開後に改ざんや情報漏えいが起きたとき、何をどこまで約束していたかが曖昧だと、原因の調査も費用の負担も揉めやすくなります。
この記事の要点
- セキュリティ要件は「開発」「サーバー」「管理画面」「運用」「事故時の対応」の5つに分けて決めると、抜け漏れが減ります。
- 要件は発注前の提案依頼の段階で示し、見積もりと契約書に反映させます。公開後に追加すると費用が膨らみます。
- IPAの「安全なウェブサイトの作り方」や「中小企業の情報セキュリティ対策ガイドライン」を共通の物差しにすると、制作会社と話がかみ合います。
- 取引先からの評価制度（SCS評価制度）に備える会社は、サイトの管理方法を説明できる記録を残しておきます。
この記事は、コーポレートサイトや採用サイト、会員ページのあるサービスサイトを発注する情報システム・総務・広報の担当者向けです。制作会社に渡す確認表と、提案や見積もりで確かめるポイントを整理します。結論を先に言うと、セキュリティは制作会社に任せきりにするものではなく、「何を求めるか」を発注側が決め、「どう実現するか」を制作会社に提案してもらうものです。
なぜ発注の段階で要件を決めるのか
セキュリティの対策は、作り方そのものに関わります。例えば、問い合わせフォームで受け取った内容をサーバーに保存するのか、メールで送るだけにするのかで、守るべき情報と対策が変わります。管理画面に社外から入れるようにするのか、社内からだけにするのかも、設計の段階で決める事項です。
公開した後に「管理画面への接続元を制限したい」「脆弱性診断を受けたい」と追加すると、作り直しや再見積もりが必要になります。最初に要件を示しておけば、制作会社は対策を工数に含めて見積もるため、比較もしやすくなります。
もう一つの理由は、取引先からの要求です。経済産業省は、取引先の対策状況を共通の基準で示すサプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）について、★3・★4の制度開始を2026年度末頃に目指すとしています（2026年11月時点）。サイトやサーバーの管理は会社のIT基盤の一部として確認されうるため、どんな対策をしているかを説明できる状態にしておくことが求められます。
セキュリティ要件の確認表（5つの分類）
次の表は、提案依頼書（RFP）や見積もり依頼に添えて使える確認表です。すべてを必須にする必要はありません。サイトの目的と、扱う情報の重さに合わせて「必須」「推奨」「不要」を選びます。
| 分類 |
確認する要件 |
決めるときの考え方 |
| 開発 |
入力欄の検証、SQLインジェクションやクロスサイト・スクリプティングへの対策、使うプラグインやライブラリの選定基準 |
IPAの「安全なウェブサイトの作り方」に沿っているかを確認する |
| サーバー |
常時HTTPS、サーバーのOSやPHPの更新方針、WAF、バックアップの頻度と保管先、ログの保存期間 |
サーバーの名義と管理者を決める。契約は自社名義が基本 |
| 管理画面 |
二段階認証、接続元の制限、アカウントの発行と削除の手順、権限の分け方 |
退職者や制作会社のアカウントを誰が削除するかまで決める |
| 運用 |
CMS本体・プラグインの更新の頻度、監視（停止・改ざん）、脆弱性情報の確認、定期的な点検 |
公開後の保守契約で誰が行うかを決める |
| 事故時の対応 |
連絡先と連絡の期限、初動の範囲、復旧の目標時間、原因調査の報告、費用の負担 |
個人情報を扱う場合は、報告義務への協力も含める |
Service
コーポレートサイト制作のご相談はフェニックスデザインへナレッジベースを運営するフェニックスデザインが、今のサイトの数字を見るところから対応します。URLを入れるだけの無料簡易診断から。
開発の要件：共通の物差しを使う
開発の要件は、専門用語が多く、発注側が細かく指定するのは難しい分野です。そこで、公的な資料を共通の物差しとして使います。IPAの「安全なウェブサイトの作り方」は、ウェブアプリケーションの代表的な11種類の脆弱性について、原因と対策、確認用のチェックリストをまとめた資料です。提案依頼書に「この資料のチェックリストに沿って実装し、確認結果を納品物に含めること」と書けば、要件として具体的になります。
WordPressなどのCMSを使う場合は、プラグインの選び方も要件になります。更新が長く止まっているプラグインや、提供元が不明なものは避ける、使う数を必要最小限にする、といった方針を制作会社と共有します。WordPressでの具体的な対策はWordPressのセキュリティ対策チェックリストで、優先度ごとに整理しています。
サーバーと管理画面の要件：名義と鍵を自社で持つ
サーバーとドメインの契約が制作会社の名義のままだと、制作会社との契約が終わったときや連絡が取れなくなったときに、サイトを動かせなくなるおそれがあります。セキュリティの観点からも、契約は自社の名義にし、管理画面のIDとパスワードを自社で管理することを要件にします。考え方はドメイン・サーバーは自社と制作会社どちらの名義で管理するかで詳しく説明しています。
管理画面は、攻撃者が最初に狙う場所です。二段階認証と、社内のネットワークなど決まった場所からだけ入れる接続元の制限を、必要に応じて組み合わせます。テレワークがある会社では、接続元の制限と働き方が両立するかも確認します。
- 管理画面のアカウントは、担当者ごとに発行し、共用しない。
- 権限は「公開できる人」と「下書きだけ書ける人」に分ける。
- 制作会社のアカウントは、公開後の保守を頼まない場合は削除するか、使う期間だけ有効にする。
- 退職や異動のときに、アカウントの削除を誰が行うかを決めておく。
運用の要件：公開後に誰が何をするか
制作の契約は公開で終わることが多く、公開後の更新や監視は別の保守契約になります。セキュリティの事故の多くは、公開後に更新が止まったCMSやプラグインの脆弱性から起きます。制作の段階で、公開後の運用を誰が担うかを決めておくことが大切です。
| 作業 |
頻度の目安 |
担当の決め方 |
| CMS本体・プラグイン・テーマの更新 |
月1〜2回と、緊急の修正が出たとき |
更新後の表示確認まで含めて誰が行うか |
| バックアップの確認 |
月1回は復元できるかを確認 |
サーバーの自動バックアップに加え、別の場所に保管するか |
| 稼働と改ざんの監視 |
常時 |
異常を検知したときの連絡先と初動 |
| アカウントの棚卸し |
四半期ごと |
不要なアカウントの削除と権限の見直し |
| 脆弱性診断・点検 |
年1回や大きな改修のとき |
外部の診断会社を使うか、制作会社の点検で足りるか |
外部の脆弱性診断を頼む場合は、経済産業省の基準に適合したサービスをIPAの情報セキュリティサービス基準適合サービスリストで調べることができます。診断の種類と頼み方はWebサイトの脆弱性診断とはで説明しています。
事故時の対応の要件：連絡と役割を先に決める
改ざんや情報漏えいは、起きてから役割を決めると初動が遅れます。制作会社や保守の会社と、次の点を契約や運用ルールで決めておきます。
- 異常に気づいたときの連絡先（平日・休日）と、連絡の手段。
- サイトを一時的に止める判断を誰がするか。
- 初動の作業の範囲（ログの保全、パスワードの変更、改ざんされたファイルの特定など）。
- 原因調査の報告の形と期限。
- 費用の負担（保守契約の範囲内か、別途の見積もりか）。
問い合わせフォームなどで個人情報を扱う場合、漏えいの内容によっては個人情報保護委員会への報告が必要になります。期限があるため、ログの提供や原因の説明に制作会社が協力することを契約に入れておくと安心です。初動の流れはホームページ改ざん・WordPress乗っ取りの対処で解説しています。
発注する側が社内で決めておくこと
セキュリティは、制作会社の対策だけでは完結しません。発注する会社の側でも、次のことを決めておく必要があります。制作会社に要件を渡す前に、社内で担当と方針を確かめておくと、打ち合わせが短く済みます。
- サイトの責任者: 公開の判断、事故時の判断をする人。広報や総務の部長など、決裁できる人にします。
- 技術の窓口: 情報システムの担当者がいれば、サーバーやメール、社内のネットワークとの関係を確認してもらいます。いない場合は、制作会社に説明を求める項目を一覧にしておきます。
- 扱う情報の一覧: 問い合わせフォーム、資料請求、採用の応募、会員登録など、サイトで受け取る個人情報と、その保存先を書き出します。
- 社内の規程との関係: 情報セキュリティの基本方針や、外部に委託するときの規程があれば、その内容と矛盾しないか確認します。
中小企業の場合は、IPAの「中小企業の情報セキュリティ対策ガイドライン」が参考になります。2026年3月公開の第4.0版では、自社診断の項目にウェブサイトの安全な運用が加わり、SCS評価制度の考え方にも沿った内容になっています。
提案と見積もりで確かめること
要件を示したら、制作会社の提案と見積もりで次の点を確かめます。対策の名前が並んでいるだけでなく、どう確認し、何を納品するかが書かれているかが判断の分かれ目です。
- 確認表の各項目に、対応する作業と担当が書かれているか。
- 公開前のセキュリティの確認方法（チェックリスト、ツールによる確認、外部の診断）と、その結果を納品物に含めるか。
- 公開後の保守の内容と、含まれない作業の一覧。
- 事故時の連絡と初動の範囲、費用の考え方。
- 使うプラグインやサービスの一覧と、更新が止まった場合の代わりの方針。
- サーバー、ドメイン、管理画面の情報を、公開時にどの形で引き渡すか。
複数の制作会社を比べるときは、確認表の項目ごとに各社の回答を横に並べると、対策の範囲と費用の差がはっきりします。回答が空欄の項目は、対応しないのか、費用に含めていないのかを質問して確かめます。
よくあるご質問
小さな会社でも、ここまでの要件が必要ですか？
すべての項目を必須にする必要はありません。問い合わせフォームしかない会社案内のサイトなら、常時HTTPS、管理画面の二段階認証、CMSの更新、バックアップの4つを最低限の要件にし、ほかは「推奨」とする方法があります。扱う情報の重さに合わせて選んでください。
要件を書くための社内の知識がありません
確認表の分類だけを示し、各項目の対策を制作会社に提案してもらう方法があります。そのうえで、提案の内容をIPAの資料と照らし合わせると、抜け漏れを確かめやすくなります。
脆弱性診断は毎回必要ですか？
会員情報や決済など重要な情報を扱うサイトでは、公開前と大きな改修のときに受けることが多くなります。会社案内が中心のサイトでは、公開前のチェックリストの確認と、公開後の更新と監視を優先する考え方もあります。
クラウド型のサービスやノーコードで作る場合も同じですか？
サーバーの管理はサービスの提供元が行うため、サーバーの項目は「提供元の対策を確認する」に置き換わります。一方で、管理画面のアカウントと権限、フォームで受け取る情報の扱い、事故時の連絡は、自社で決める必要がある点は変わりません。提供元の利用規約とセキュリティの説明を確認し、足りない部分を要件として補います。
保守を別の会社に頼むと、責任があいまいになりませんか？
制作と保守を別の会社に頼むことはできますが、引き継ぎの範囲と、公開前の不具合と公開後の事故の切り分けを契約で決めておく必要があります。引き継ぎの際は、管理画面やサーバーの情報、使っているプラグインの一覧を必ず受け取ります。
セキュリティ要件の整理から相談する場合
フェニックスデザインでは、制作の段階でのセキュリティ要件の整理と実装、公開後の更新・監視・事故時の初動までを担当しています。どこまでを要件にするか迷っている段階でもご相談いただけます。対応範囲はWEBサイトのセキュリティ対策のページで紹介しています。
まとめ
- セキュリティ要件は、開発・サーバー・管理画面・運用・事故時の対応の5つに分けて、発注前に決めます。
- IPAの資料を共通の物差しにし、確認の方法と結果を納品物に含めてもらいます。
- サーバーとドメインは自社名義にし、管理画面のアカウントと権限を自社で管理します。
- 公開後の更新と監視を誰が行うかを決め、事故時の連絡と初動の範囲を契約に入れます。
- 取引先からの評価制度に備え、対策の内容を説明できる記録を残しておきます。