システム開発の発注でどんなセキュリティ対策を求めればいい？個人情報を扱うサイトの要件の決め方

2025年10月5日2026年10月1日

会員登録やお問い合わせフォームなど、個人情報を扱うWebサイトやシステムを開発会社に発注するとき、「セキュリティはしっかりお願いします」と伝えたものの、それ以上何を言えばいいのか分からない。システム開発のセキュリティ要件は、発注者が判断に迷いやすいテーマです。

「発注時にどんなセキュリティ対策を求めればいいのか分からない…」

先に結論をお伝えします。発注者が技術的な対策の中身を細かく指定する必要はありません。発注者が決めるべきなのは、「何を守るのか」「どの基準に沿って作ってもらうのか」「完成後は誰が何をするのか」「対策できていることをどう確認するのか」の4点です。これを見積もり依頼の段階で伝え、公的機関のガイドラインを”共通の物差し”として使うと、開発会社との認識のずれを大きく減らせます。

この記事では、個人情報を扱う会員サイトなどを発注する方に向けて、セキュリティ要件の決め方と伝え方を、チェックリストと開発会社への質問例つきで解説します。

発注時のセキュリティ要件があいまいになりやすい3つの理由

まず、なぜセキュリティの話は「しっかりお願いします」で止まってしまうのかを整理しておきます。理由が分かると、発注者が押さえるべきポイントも見えてきます。

理由1：完成しても「目に見えない」

画面のデザインや機能は完成品を見れば確認できますが、セキュリティ対策は画面に表れません。対策が十分かどうかは、外から見ただけでは判断できないのです。そのため発注者も開発会社も「きっと大丈夫だろう」と互いに思い込んだまま進んでしまうことがあります。

理由2：対策の範囲によって費用が変わる

セキュリティ対策は、どこまでやるかによって作業量が変わります。発注者が何も言わなければ、開発会社は「一般的な水準」で見積もるしかありません。その「一般的」の中身が会社ごとに違うため、相見積もりの金額差の一因にもなります。「求める水準」を言葉にしておくことは、見積もりを正しく比べるためにも必要です。

理由3：本番はむしろ「公開した後」

Webシステムは公開した後も、使っている部品（ソフトウェア）の弱点が新たに見つかり、更新が必要になります。開発時の対策だけでなく、公開後に誰が更新や監視をするのかまで決めておかないと、時間とともに守りが薄くなっていきます。

「『セキュリティしっかり』とだけ言われると、どこまでやるか私たちも判断に迷います。守りたい情報と、運用の体制を教えてもらえると提案しやすいんです」

個人情報を扱うなら、発注者自身の責任も知っておく

個人情報を扱うシステムでは、法律上の観点も押さえておきましょう。ここでは一般的な考え方を紹介します。個別のケースの判断は、弁護士などの専門家や個人情報保護委員会の相談窓口に確認してください。

📰 出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」

個人情報保護委員会のガイドラインでは、個人データの取扱いを外部に委託する場合、委託元は委託先を監督する必要があるとされています。具体的には「適切な委託先の選定」「委託契約の締結」「委託先での取扱状況の把握」の3つが挙げられています。開発会社が公開後の保守でデータベースに触れるような場合などは、この考え方が関わってくる可能性があります。

また、同ガイドラインでは、事業者が講ずべき安全管理措置として、基本方針の策定、取扱いの規律の整備、組織的・人的・物理的・技術的な安全管理措置、外的環境の把握といった項目が示されています。技術的な措置の例としては、アクセス制御や、アクセスする人の識別と認証、外部からの不正アクセスの防止などが挙げられています。

さらに、漏えいした本人の数が1,000人を超える場合など一定の事態では、委員会への報告と本人への通知が求められます。つまり、システムを作るのは開発会社でも、個人情報を預かる責任は発注者（運営する会社）にあるという点が出発点です。

発注時にセキュリティ要件を決める5つのステップ

ここからは、具体的な進め方です。専門知識がなくても進められるよう、発注者が決めることに絞っています。

ステップ1：守る情報を棚卸しする

最初に、システムでどんな情報を扱うのかを書き出します。対策の強さは、守る情報の重要度で決まるからです。

どんな項目を扱うか（氏名、メールアドレス、住所、電話番号、生年月日など）
会員数はどのくらいを想定しているか（開始時と数年後）
病歴などの特に配慮が必要な情報や、決済に関わる情報を扱うか
誰がその情報を見られるべきか（本人、社内の担当者、管理者のみなど）

ここで大切なのは、「そもそも持たなくていい情報は持たない」という視点です。たとえば生年月日が本当に必要か、クレジットカード情報を自社で保存せず外部の決済サービスに任せられないか、といった検討は、守る対象そのものを減らすもっとも確実な対策です。

ステップ2：公的なガイドラインを「基準」として指定する

発注者が対策の中身を一から書く必要はありません。公的機関が公開している資料を「この基準に沿って作ってください」と指定するのが現実的です。

📰 出典：IPA（情報処理推進機構）「安全なウェブサイトの作り方」

IPAの「安全なウェブサイトの作り方」は、ウェブサイトの開発者や運営者が、セキュリティを考慮したウェブサイトを作るための資料です。代表的な脆弱性（＝システムの弱点）11種類とその対策が解説されており、巻末には「セキュリティ実装チェックリスト」も用意されています。

発注者はこの資料の中身をすべて理解する必要はありません。「この資料に沿った対策と、チェックリストでの確認をお願いします」と依頼書に一文入れるだけでも、開発会社と同じ物差しで話せるようになります。

📰 出典：IPA「非機能要求グレード」紹介ページ

もう少し本格的に要件を整理したい場合は、IPAの「非機能要求グレード」も参考になります。非機能要求（＝機能以外の性能・信頼性・セキュリティなどの要求）について、ユーザと開発者の認識の行き違いを防ぐことを目的としたツール群で、項目が網羅的に整理されています。すべてを使う必要はなく、開発会社に「セキュリティの項目だけでも一緒に確認したい」と相談する使い方もできます。

ステップ3：最低限そろえたい要件を分野ごとに伝える

基準を指定したうえで、発注者の言葉で「求めること」を伝えます。次の表は、個人情報を扱う会員サイトで話し合っておきたい分野の例です。

分野	発注者が伝えたいこと（例）
ログイン・認証	会員・管理者のログイン方法、パスワードのルール、管理画面に二段階認証（＝パスワード＋もう一つの確認）を入れるか
権限	社内の誰がどの情報を見られるか、管理者を何人に限るか
通信・保存	通信の暗号化、パスワードなど重要な情報の保存方法
記録（ログ）	誰がいつ何をしたかの記録を残すか、どのくらいの期間保存するか
バックアップ	どのくらいの頻度で取り、何日分を保管し、どれくらいで復旧したいか
公開前の点検	脆弱性診断（＝専門家による弱点の点検）を行うか、誰が行うか

表のすべてを発注者が決めきる必要はありません。「この分野についての提案をください」と伝えれば、開発会社から具体策と費用が返ってきます。提案を受けてから、予算と相談しながら優先順位をつければ大丈夫です。

ステップ4：公開後の運用と責任分担を決める

先ほど触れたとおり、セキュリティは公開後も続きます。開発契約とは別に、次のような運用面を誰が担うのかを決めておきましょう。

サーバーや使っているソフトウェアの更新（アップデート）は誰がいつ行うか
不審なアクセスや障害の監視をするか、誰が見るか
万が一の事故（インシデント）が起きたときの連絡先と連絡手順
保守契約の範囲と費用、対応時間（平日日中のみかなど）

「開発は開発会社、運用は発注者」と思い込んだまま公開してしまい、誰も更新をしていなかったというのは、起こりがちなパターンです。どちらが悪いという話ではなく、決めていなかったことが原因です。

ステップ5：「対策できていること」の確認方法を決める

最後に、対策が実施されたことをどう確かめるかを決めます。目に見えないものだからこそ、確認の方法を事前に合意しておくことが大切です。

「安全なウェブサイトの作り方」のチェックリストなどに記入して提出してもらう
公開前に脆弱性診断を行い、結果と対応状況を報告してもらう
受け入れ（＝納品物の確認）の項目にセキュリティ関連の確認を含める

脆弱性診断は開発会社自身が行う場合と、別の専門会社に依頼する場合があり、費用も変わります。どちらにするかは、扱う情報の重要度と予算を踏まえて開発会社と相談するのがよいでしょう。

発注者がやりがちな失敗パターン

「セキュリティは当然入っていますよね」で済ませる：何が含まれているかを確認しないまま契約すると、後から「それは見積もりに入っていません」となりがちです
見積もりの安さだけで比べる：セキュリティ対策や診断の有無で金額は変わります。金額差の理由を確認しましょう
管理画面のパスワードを社内で使い回す：システム側の対策が十分でも、運用のルールが甘いと守りが崩れます。退職者のアカウント削除も忘れずに
「これで絶対安全」を求める：どれだけ対策をしても、リスクをゼロにはできません。「起きにくくする」と「起きたときに被害を小さくする」の両方を考えるのが現実的です