システム開発を外注するとき、セキュリティは「開発会社がきちんとやってくれるもの」と考えられがちです。たしかに、まともな開発会社であれば基本的な対策は行います。しかし、どこまでの対策を行うかは、発注側が求めなければ開発会社の判断に委ねられます。そして、発注時に明文化されていない対策は、見積もりにも含まれず、テストもされず、運用の段階で抜けていたことに気づく、ということが起こります。
結論から言うと、発注時にセキュリティ要件として明文化すべき領域は、大きく分けて六つです。認証（誰がログインできるか）、権限（誰が何をできるか）、ログ（誰が何をしたかの記録）、データ保護（暗号化とバックアップ）、脆弱性対策（攻撃への備えと診断）、運用体制（障害や事故のときの対応）です。これらを要件定義書や提案依頼書に書き込み、見積もりとテストの対象にすることで、抜け漏れを防げます。
この記事は、システム開発の発注を担当する事業部門の方や、情報システム部門がない会社でセキュリティ要件を決めなければならない担当者に向けて書いています。発注時に指定すべき項目をチェックリストの形で整理し、システムの重要度に応じた要件の決め方、開発会社への確認のしかた、よくある失敗まで説明します。
なぜ発注時にセキュリティ要件を明文化すべきなのか
セキュリティ要件を発注時に明文化すべき理由は三つあります。
一つ目は、見積もりの比較ができるようにするためです。セキュリティ対策には工数がかかります。要件を示さずに見積もりを取ると、ある会社は二段階認証や操作ログを含めて見積もり、別の会社は含めずに見積もる、ということが起こります。金額だけを比べると、対策の薄い見積もりが安く見えてしまいます。
二つ目は、テストと検収の対象にするためです。要件として書かれていない対策は、受入テストでも確認されません。たとえば「一般の担当者が管理者向けの画面を開けないこと」を要件にしていなければ、それが漏れていても検収で気づかない可能性があります。
三つ目は、取引先や顧客への説明に使うためです。法人向けのサービスや、取引先のデータを扱うシステムでは、取引先からセキュリティチェックシートへの回答を求められることがあります。開発時にどのような対策を行ったかが記録されていなければ、回答に困ります。チェックシートへの対応は、取引先のセキュリティチェックシートに答えるための開発・運用体制で詳しく扱っています。
システムの重要度に応じて要件の水準を決める
すべてのシステムに最高水準の対策を求める必要はありません。対策を厚くすれば、その分だけ費用と期間がかかり、使い勝手にも影響します。大切なのは、システムが扱う情報と、問題が起きたときの影響の大きさに応じて、水準を決めることです。
| 観点 | 水準を高くすべき例 | 標準的な水準でよい例 |
|---|---|---|
| 扱う情報 | 個人情報、決済情報、健康情報、取引先の機密情報 | 公開情報、社内の一般的な業務情報 |
| 利用者 | 社外の不特定多数、顧客、取引先 | 限られた社内の担当者 |
| 停止の影響 | 売上や顧客対応が止まる、取引先に迷惑がかかる | 一時的に手作業で代替できる |
| 改ざんの影響 | 金額や契約内容が変わる、誤った情報が顧客に届く | 内部の参考情報が変わる |
| 取引先の要求 | セキュリティチェックシートへの回答や監査を求められる | 特に求められない |
まずは自社のシステムがどちらに近いかを考え、高くすべき観点が多いほど、以下のチェックリストの項目を厚く要件化していきます。判断が難しい場合は、開発会社に「この情報を扱うシステムとして、どの程度の対策が妥当か」を提案してもらい、その理由を説明してもらうのも有効です。
認証・権限・ログの要件
認証（ログイン）の要件
認証は、システムを使う人が本人であることを確かめる仕組みです。発注時には、次の点を指定または確認します。
- パスワードの長さや文字の種類など、設定できる条件
- 一定回数ログインに失敗した場合の扱い（一時的なロックなど）
- 二段階認証（多要素認証）の要否と、対象とする利用者
- パスワードを忘れたときの再設定の方法
- ログイン状態が続く時間と、自動でログアウトする条件
- 社内の既存のID管理の仕組みとの連携（シングルサインオンなど）の要否
特に、管理者や大量の個人情報にアクセスできる利用者には、二段階認証を求めるかどうかを明確に決めておきましょう。認証を自前で作らず、実績のある外部の認証サービスを使う選択肢もあります。
権限の要件
権限は、ログインした人が何をできるかを決める仕組みです。権限の設計が甘いと、本来見えてはいけない情報が見えたり、操作できてはいけない処理ができたりします。
権限の要件を決めるときは、まず利用者の種類（役割）を洗い出し、役割ごとに見られる情報と操作できる処理を一覧にします。この考え方はRBAC（ロールベースアクセス制御）と呼ばれます。たとえば、一般の担当者は自分の担当顧客の情報だけを見られる、管理者はすべての顧客情報を見られるが削除はできない、システム管理者だけが利用者の追加と削除をできる、といった形です。
この一覧は、受入テストで「権限ごとに見える画面と操作が正しいか」を確認するための基準にもなります。
ログと監視の要件
ログは、システムの中で誰が、いつ、何をしたかの記録です。問題が起きたときに原因を調べる、不正な操作がなかったかを確かめる、取引先に説明する、といった場面で欠かせません。
ログの要件として、次の点を決めておきます。
- 記録する操作の範囲（ログイン、データの閲覧・作成・変更・削除、データの出力、設定の変更など）
- 記録する内容（日時、利用者、操作の種類、対象のデータ、接続元など）
- ログの保存期間
- ログを見られる人と、ログ自体が改ざんされない仕組み
- 不審な操作（短時間の大量出力、深夜のログイン失敗の連続など）を検知して通知する仕組みの要否
特に、個人情報や機密情報を扱うシステムでは、データの閲覧や出力の記録である監査ログを残すかどうかが重要になります。後から「誰がこの情報を見たか」を調べられるようにしておくことで、万が一の際の影響範囲の特定が早くなります。
あわせて、システムが正常に動いているかを見張る監視の仕組みも決めておきます。サーバーが止まっていないか、エラーが急に増えていないか、応答が遅くなっていないかを監視し、異常があれば誰に通知するかを決めます。
データ保護と脆弱性対策の要件
データ保護では、データが盗まれたり、失われたりしないための対策を決めます。
暗号化
通信の暗号化（HTTPSの利用）は、今では標準的な対策です。発注時には、それに加えて、保存しているデータの暗号化の要否を確認します。特に、パスワードは元に戻せない形で保存されているか、個人情報や決済に関わる情報がどのように保存されているかを確認しましょう。決済のカード情報は、自社のシステムで保持せず、決済代行サービスに任せる設計にするのが一般的です。
バックアップと復旧
データが失われた場合に備えて、バックアップの要件を決めます。どのくらいの頻度でバックアップを取るか、どのくらいの期間保存するか、どこに保存するか、そして実際に復旧できることを確認しているか、が主な項目です。バックアップを取っているだけで、復旧の手順を一度も試していない、というのはよくある落とし穴です。
開発・テスト環境での本番データの扱い
開発やテストのために、本番の個人情報を開発会社の環境にコピーしてよいかを決めておきます。原則としては、架空のデータや加工したデータを使い、本番データの持ち出しが必要な場合は、範囲と管理方法、作業後の削除を取り決めます。
外部サービスに預けるデータの確認
最近のシステムは、メール配信、ファイル保存、問い合わせ管理、生成AIなど、多くの外部サービスと連携して作られます。外部サービスにデータを送る場合は、そのサービスにどのデータを預けるのか、データがどの地域で保管されるのか、送ったデータがサービス側でどう扱われるのかを確認します。特に生成AIのサービスに業務データを送る場合は、入力したデータがサービスの改善に使われない設定になっているかを確認しておきましょう。開発会社には、連携する外部サービスとそこに送るデータの一覧を作ってもらうと、全体像を把握しやすくなります。
脆弱性対策と診断の要件
脆弱性とは、攻撃者に悪用される可能性のあるシステムの弱点です。代表的なものに、入力欄から不正な命令を送り込まれる、他人になりすまして操作される、画面に不正なスクリプトを埋め込まれる、といったものがあります。
発注時には、次の点を要件として示します。
- 一般的に知られている脆弱性への対策を、開発の標準として行うこと
- 使用するライブラリやフレームワークを、サポートが続いているものから選ぶこと
- 公開前に、脆弱性診断を行うかどうか、行う場合は誰が行うか（開発会社か、第三者の診断会社か）
- 診断で見つかった問題の修正を、どの範囲まで納品前に行うか
- 公開後に、使用しているライブラリの脆弱性情報を確認し、更新する体制
第三者による脆弱性診断は、別途費用がかかります。扱う情報の重要度が高いシステムや、取引先から診断結果の提出を求められる場合は、診断を計画に含めておきましょう。
運用体制と事故対応の要件
セキュリティは、システムを公開した後も続く取り組みです。開発の段階で、運用時の体制も決めておきます。
- 障害やセキュリティ事故が起きたときの連絡先と、連絡の手順
- 開発会社が事故に気づいた場合に、発注側へ報告するまでの目安の時間
- 原因の調査、影響範囲の特定、復旧の役割分担
- ソフトウェアの更新やセキュリティ修正を、保守契約のどの範囲で行うか
- 開発会社の担当者がシステムにアクセスする際のルール（アカウントの個人ごとの発行、退職時の削除など）
- 再委託先がある場合、再委託先にも同じ水準の管理を求めること
保守の段階でどこまで対応してもらうかは、システム保守契約に含めるべき内容もあわせて確認してください。
発注時に指定すべきセキュリティ要件チェックリスト
ここまでの内容を、発注時のチェックリストとしてまとめます。要件定義書や提案依頼書に、それぞれの項目について「必要／不要／開発会社に提案を求める」のいずれかを書き込んで使ってください。
| 領域 | 確認・指定する項目 |
|---|---|
| 認証 | パスワードの条件、ログイン失敗時のロック、二段階認証の対象、再設定の方法、自動ログアウト、シングルサインオン |
| 権限 | 役割の一覧、役割ごとに見られる情報と操作できる処理、権限の変更を行える人 |
| ログ | 記録する操作と内容、保存期間、ログの閲覧者、改ざん防止、不審な操作の検知 |
| 監視 | 監視する対象、異常時の通知先、対応時間 |
| 暗号化 | 通信の暗号化、保存データの暗号化、パスワードの保存方法、決済情報を保持しない設計 |
| バックアップ | 頻度、保存期間、保存場所、復旧手順と復旧の確認 |
| 開発環境 | 本番データの持ち出しの可否と管理方法 |
| 脆弱性 | 一般的な脆弱性への対策、使用ライブラリの選定、脆弱性診断の実施と修正範囲、公開後の更新体制 |
| 運用 | 事故時の連絡手順と報告の目安、役割分担、アクセス管理、再委託先の管理 |
| 記録 | 実施した対策の一覧の納品、取引先への説明資料の作成支援の要否 |
要件を決めて開発会社に伝える手順
チェックリストを使って、次の順番で進めると、要件の抜け漏れと開発会社との認識のずれを防げます。
- 扱う情報と利用者を書き出す：システムが扱うデータの種類と、誰が使うかを一覧にします。
- 重要度を判断する：重要度の表をもとに、要件の水準をどの程度にするかを社内で決めます。
- チェックリストに記入する：項目ごとに「必要／不要／開発会社に提案を求める」を書き込みます。
- 要件定義書や提案依頼書に載せる：記入したチェックリストを添付し、見積もりの前提として示します。
- 提案内容を比較する：各社の対策の内容と、その費用がどこに含まれているかを確認します。
- 設計の段階で具体化する：権限の一覧やログの項目など、設計書に落とし込んだ内容を確認・承認します。
- 受入テストで確認する：権限ごとの画面と操作、ログの記録、自動ログアウトなどをテストケースに含めます。
- 実施した対策を記録として受け取る：納品物として、実施した対策の一覧を提出してもらいます。
7の受入テストについては、受入テストの進め方で、テストケースの作り方を説明しています。
架空の例：顧客向けポータルの発注
ここでは架空の例で、セキュリティ要件の決め方を見てみます。
ある保守サービスの会社が、顧客企業が自社の契約内容と点検報告書を確認できるポータルサイトを外注することになりました。扱う情報は顧客企業の設備情報と担当者の連絡先で、取引先からはセキュリティチェックシートへの回答を求められることが予想されました。
担当者は、チェックリストをもとに要件を整理しました。顧客企業の利用者には二段階認証を選べるようにし、社内の管理者には必須としました。権限は、顧客企業ごとに自社の情報だけが見えること、社内の営業担当は担当顧客の情報だけを見られることを明記しました。報告書のダウンロードはすべて記録に残し、短時間に大量のダウンロードがあれば管理者に通知することにしました。公開前には第三者による脆弱性診断を行い、重大な指摘は公開前に修正することを要件にしました。
見積もりを依頼した三社には同じ要件を示したため、金額の差がどの対策の違いから来ているかを比較でき、公開後には実施した対策の一覧を、取引先への説明にそのまま使うことができました。
よくある失敗と避け方
「セキュリティは万全に」とだけ書く
要件定義書に「セキュリティに十分配慮すること」とだけ書き、具体的な項目を示さないケースです。開発会社によって「十分」の解釈が異なるため、見積もりの比較も、検収での確認もできません。上のチェックリストの項目ごとに、必要かどうかを具体的に書きましょう。
管理画面の権限を後回しにする
利用者向けの画面には気を配る一方で、社内の管理画面の権限設計を後回しにするケースです。管理画面は多くの情報にアクセスできるため、権限が甘いと影響が大きくなります。管理画面も、役割ごとの権限を最初から設計しておきます。
公開後の更新を考えていない
開発時には最新のライブラリを使っていても、公開後に更新しなければ、時間とともに脆弱性が見つかり、危険な状態になります。保守契約の中で、更新の頻度と範囲を決めておきます。
開発会社の担当者のアカウントを共有している
開発会社の複数の担当者が、一つの管理者アカウントを共有して作業しているケースです。誰が何をしたかが記録に残らず、担当者が交代しても使い続けられてしまいます。アカウントは個人ごとに発行し、不要になったら速やかに削除するルールにします。
よくある質問
Q. セキュリティ要件をどこまで指定すればよいか分かりません。
まずは本記事の重要度の表で、自社のシステムがどの水準に近いかを判断してください。そのうえで、チェックリストの項目ごとに、自社で決められるものは決め、判断が難しいものは「開発会社に提案を求める」として、提案の理由を説明してもらいましょう。
Q. 脆弱性診断は必ず必要ですか？
すべてのシステムに必須というわけではありません。社外の不特定多数が使う、個人情報や決済に関わる情報を扱う、取引先から診断結果を求められる、といった場合は、実施を検討する価値が高くなります。社内の限られた担当者だけが使うシステムであれば、開発会社による確認で足りる場合もあります。
Q. セキュリティ対策を厚くすると、使い勝手が悪くなりませんか？
対策によっては操作の手間が増えます。そのため、すべての利用者に一律で厳しい対策を求めるのではなく、管理者や重要な情報を扱う利用者には厚く、一般の利用者には負担の少ない対策にする、といったメリハリをつけるのが現実的です。
Q. 開発会社のセキュリティへの取り組みは、どうやって確かめればよいですか？
提案や面談の段階で、開発時に標準で行っている対策、使用するライブラリの更新方針、社内の情報管理のルール、過去に同程度の重要度のシステムを開発したときの進め方などを聞いてみましょう。具体的に答えられるかどうかが、判断の材料になります。
Otsumuに相談できること
扱う情報の重要度がそれほど高くなく、本記事のチェックリストをもとに要件を書き出せるなら、セキュリティ要件の整理は自社で十分に進められます。判断が難しい項目は、見積もりを依頼する開発会社に提案を求め、理由とあわせて比較してみてください。
一方で、個人情報や取引先の機密情報を扱う、取引先からセキュリティチェックシートへの回答を求められている、社内にセキュリティを判断できる人がいない、といった場合は、要件の整理の段階から外部の力を借りた方が、抜け漏れと手戻りを防げます。
Otsumuは、構想から開発・運用・改善まで一気通貫で支援する中で、システムの重要度に応じたセキュリティ要件の整理と、それを踏まえた開発・運用体制づくりをお手伝いしています。開発全般はシステム開発、会員向けのサービスは会員サイト開発、社内向けの管理機能は管理画面開発のページもご覧ください。
まずは30分の無料相談で、作ろうとしているシステムと扱う情報についてお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01