セキュリティ要件の書き方ガイド｜発注者が仕様書に入れるべき10項目とフォーマット例

システム開発を外注するとき、「セキュリティ対策はベンダーさんにお任せすれば大丈夫だろう」と考えていませんか。機能要件は書けても、セキュリティ要件となると何を書けばいいか分からず、仕様書が空欄のまま――そんな状況に心当たりがある方は少なくないはずです。

実際、セキュリティ要件は「専門知識がないと書けないもの」というイメージが根強く、多くの発注者が具体的な記載を避けてしまいがちです。しかし、セキュリティ要件を曖昧にしたまま発注すると、責任の所在が不明確になり、インシデント発生時に想定外のコストや法的リスクを負う可能性があります。

安心してほしいのは、セキュリティの専門家でなくても「発注者として最低限書くべき項目」は整理できるということです。必要なのは、ゼロから技術を学ぶことではなく、「何を・どの粒度で・どう書くか」のフレームワークを知ることです。

本記事では、システム開発のセキュリティ要件について、発注者が仕様書に記載すべき10項目を具体的な書き方例とともに解説します。受託開発会社である秋霜堂株式会社の視点から「こう書いてもらえると設計・見積もりがスムーズになる」というベンダー側のリアルな声も交えながら、コピー&カスタマイズできるフォーマット例、OWASP Top 10の発注者向け解説、開発会社への確認チェックリストまで、実務で使える情報をまとめました。

読み終わるころには、「自分でもセキュリティ要件が書ける」という手応えを感じていただけるはずです。

「セキュリティはお任せします」が招くリスクとは

システム開発の発注時に「セキュリティはお任せします」と伝えるケースは珍しくありません。しかし、この一言が後々の大きなトラブルの原因になることがあります。セキュリティ要件を明確にしないまま開発を進めることのリスクを、3つの観点から整理します。

責任の所在が曖昧になる（契約上のリスク）

セキュリティ要件を仕様書に明記していない場合、インシデントが発生したときに「誰の責任か」が分からなくなります。発注者は「当然対策しているはず」と考え、ベンダーは「要件になかったので対象外」と主張する――この食い違いは、契約書や仕様書にセキュリティ要件が書かれていないことが原因で起こります。

2024年には国内で587件のセキュリティインシデントが公表され、前年の383件から大幅に増加しました（出典: デジタルアーツ、2025年）。委託先がサイバー攻撃を受けて委託元の個人情報が漏洩する事案も頻発しており、発注者であっても損害賠償責任や信用失墜のリスクを免れません。仕様書に「何を・どのレベルで対策するか」を書いておくことは、自社を守るための最低限の備えです。

後から対策すると費用は3〜5倍に膨らむ

内閣サイバーセキュリティセンター（NISC）が提唱する「セキュリティ・バイ・デザイン」の考え方では、企画・設計段階からセキュリティを組み込むことで、トータルコストを大幅に削減できるとされています。逆に言えば、開発が進んでから「やっぱりセキュリティ対策を追加したい」となると、設計の見直し・コードの改修・再テストが必要になり、費用が当初の3〜5倍に膨らむケースも珍しくありません。

「後から足せばいい」という考え方は、結果的に最もコストがかかる選択肢です。

セキュリティ要件は「発注者が決めるもの」

「セキュリティは技術的な話だから、開発会社が決めるもの」と思われがちですが、実はそうではありません。どのレベルのセキュリティを求めるかは、発注者のビジネス判断です。たとえば、多要素認証を必須にするか、ログの保存期間を何年にするかといった判断は、事業のリスク許容度やコンプライアンス要件に基づいて発注者が決めるべき事項です。

開発会社の役割は、その要件を技術的に実現すること。要件そのものを決めるのは発注者の仕事です。この認識を持つだけで、仕様書の書き方は大きく変わります。

セキュリティ要件の基本 ― 非機能要件としての位置づけ

セキュリティ要件を書く前に、まず「セキュリティ要件とは何か」の全体像を押さえておきましょう。位置づけが分かれば、「何を書けばいいか」の見通しが立ちます。

機能要件と非機能要件の違い

システム開発の要件は、大きく「機能要件」と「非機能要件」に分かれます。機能要件は「このシステムで何ができるか」を定義するもので、たとえば「ユーザーが商品を検索できる」「管理者が注文履歴をCSV出力できる」といった内容です。

一方、非機能要件は「そのシステムがどのように動くか」を定義するもので、性能・可用性・セキュリティなどが含まれます。機能要件が「What（何をするか）」であるのに対し、非機能要件は「How（どう実現するか）」を決めるものだと考えると分かりやすいでしょう。

セキュリティ要件は非機能要件の一部です。機能要件は書けるけれど非機能要件は苦手、という方は多いですが、セキュリティに関しては「守るべきルールのリスト」として整理すれば、特別な技術知識がなくても記載できます。要件定義の全体像について詳しく知りたい方は、要件定義の進め方ガイドもあわせてご覧ください。

非機能要件6大項目の中のセキュリティ

IPA（独立行政法人情報処理推進機構）が公開している「非機能要求グレード」では、非機能要件を以下の6つのカテゴリに分類しています。

1. 可用性: システムが継続的に利用可能であること
2. 性能・拡張性: 応答速度や同時接続数などの性能基準
3. 運用・保守性: 監視体制やバックアップ、メンテナンスの方法
4. 移行性: 既存システムからのデータ移行や切り替え方法
5. セキュリティ: 不正アクセス防止、データ保護、認証・認可の仕組み
6. システム環境・エコロジー: 設置環境や消費電力への配慮

本記事で扱うのは、5番目の「セキュリティ」に該当する要件です。この枠組みを意識することで、「セキュリティ以外の非機能要件もあわせて検討すべきだ」という視点が持てます。

セキュリティ・バイ・デザインの考え方

セキュリティ・バイ・デザインとは、「システムの企画・設計の段階からセキュリティ対策を組み込む」という考え方です。NISCが策定したガイドラインでも推奨されており、後付けの対策よりもコストが低く、効果が高いとされています。

発注者にとってのポイントは、RFPや仕様書を作成する段階で――つまり開発が始まる前に――セキュリティ要件を明確にしておくことです。「開発が始まってからベンダーと相談する」のではなく、「最初の仕様書にセキュリティ要件を含める」ことが、セキュリティ・バイ・デザインの第一歩になります。

発注者が仕様書に書くべきセキュリティ要件10項目

ここからが本記事の核心です。発注者が仕様書に最低限記載すべきセキュリティ要件を10項目に整理しました。各項目について「なぜ必要か」「何を書くか」「ベンダーにはこう伝える」の3点セットで解説します。

受託開発会社の視点から言えば、これらの要件が仕様書に書かれていると、見積もりの精度が上がり、設計段階での手戻りが減ります。結果として、プロジェクト全体がスムーズに進みます。

認証方式（パスワードポリシー・多要素認証）

なぜ必要か: 認証はシステムの「玄関の鍵」です。弱いパスワードや認証の不備は、不正アクセスの最も一般的な入り口になります。

仕様書への書き方例: 「パスワードは8文字以上、英大文字・小文字・数字・記号を含むこと。ログインには多要素認証（MFA）を導入し、管理者アカウントはMFAを必須とする。5回連続でログインに失敗した場合、アカウントを30分間ロックすること。」

ベンダーへの伝え方: MFAの具体的な方式（SMS、認証アプリ、メール）までは指定せず、「MFA必須」とだけ書いて方式はベンダーに提案してもらうのがスムーズです。

認可・アクセス制御（権限管理の粒度）

なぜ必要か: 「ログインできる」ことと「すべての情報にアクセスできる」ことは別です。権限管理が不適切だと、一般ユーザーが管理者向けの機能にアクセスできてしまうリスクがあります。

仕様書への書き方例: 「ユーザー権限は最低3段階（管理者・編集者・閲覧者）を設け、各権限でアクセス可能な機能・データ範囲を明確に定義すること。権限の変更履歴を記録すること。」

ベンダーへの伝え方: 自社の業務フローに基づいて「誰が何をできる必要があるか」をリスト化して渡すと、ベンダーが適切な権限設計を提案しやすくなります。

通信の暗号化（TLS/SSL要件）

なぜ必要か: 暗号化されていない通信は、第三者に傍受される可能性があります。特に個人情報やログイン情報をやり取りする画面では必須です。

仕様書への書き方例: 「すべてのページでHTTPS（TLS 1.2以上）を適用すること。HTTP接続は自動的にHTTPSへリダイレクトすること。SSL証明書の有効期限管理と更新手順を納品物に含めること。」

ベンダーへの伝え方: 「TLS 1.2以上」と具体的なバージョンを指定することで、古いプロトコルの使用を防げます。

データの暗号化と保管ルール

なぜ必要か: 通信だけでなく、データベースやファイルに保管されるデータの暗号化も重要です。万が一データベースに不正アクセスされた場合でも、暗号化されていれば情報の悪用リスクを低減できます。

仕様書への書き方例: 「パスワードはハッシュ化（bcryptまたは同等以上のアルゴリズム）して保管すること。個人情報（氏名、住所、メールアドレス等）はAES-256で暗号化して保管すること。暗号鍵の管理方法を設計書に記載すること。」

ベンダーへの伝え方: 「どのデータを暗号化対象とするか」のリストを作成しておくと、ベンダーとの認識のずれを防げます。

セッション管理

なぜ必要か: セッション管理の不備は、他人のアカウントへのなりすましや、ログアウト後も操作可能な状態の放置につながります。

仕様書への書き方例: 「セッションの有効期限は最長60分とし、無操作30分でタイムアウトすること。ログアウト時にサーバー側のセッション情報を無効化すること。セッションIDはログイン成功時に再生成すること。」

ベンダーへの伝え方: 有効期限の時間設定は業務の実態にあわせて調整してください。長時間の入力作業がある業務では、タイムアウトが短すぎると使い勝手が悪くなるため、バランスが大切です。

入力値の検証（SQLインジェクション・XSS対策）

なぜ必要か: ユーザーが入力するフォームは、攻撃者にとって最も狙いやすいポイントです。SQLインジェクションやクロスサイトスクリプティング（XSS）といった攻撃は、入力値の検証が不十分な場合に成功します。

仕様書への書き方例: 「すべてのユーザー入力に対してサーバー側でバリデーションを実施すること。SQLインジェクション対策としてプリペアドステートメントを使用すること。XSS対策として出力時のエスケープ処理を実施すること。」

ベンダーへの伝え方: 技術的な対策方法の詳細はベンダーに委ねつつ、「SQLインジェクション・XSSへの対策は必須」と明記しておくことが重要です。

ログの取得と監視

なぜ必要か: セキュリティインシデントが発生した際、「いつ・誰が・何をしたか」を追跡するためにはログが不可欠です。ログがなければ、原因の特定も再発防止もできません。

仕様書への書き方例: 「以下の操作についてログを取得すること: ログイン・ログアウト、権限変更、個人情報へのアクセス、データの作成・更新・削除。ログには日時、操作者、操作内容、IPアドレスを含めること。ログの保管期間は最低1年間とし、改ざん防止措置を講じること。」

ベンダーへの伝え方: ログの保管期間は、業界の規制や自社のコンプライアンス要件に基づいて決めてください。金融業界や医療業界では、より長期の保管が求められる場合があります。

脆弱性診断の実施要件

なぜ必要か: 開発したシステムにセキュリティ上の弱点がないかを、リリース前に専門的にチェックするプロセスです。仕様書にセキュリティ要件を書いただけでは不十分で、それが正しく実装されているかを検証する必要があります。

仕様書への書き方例: 「リリース前に第三者機関による脆弱性診断を実施すること。診断範囲はWebアプリケーション全体とし、OWASP Top 10に含まれる脆弱性を網羅的に検査すること。検出された脆弱性のうち、高リスク・中リスクについてはリリース前に修正すること。」

ベンダーへの伝え方: 脆弱性診断の費用と実施主体（ベンダー側で実施するか、発注者側で別途手配するか）を事前に確認しておきましょう。費用の詳細はH2-6で後述します。

インシデント対応の取り決め

なぜ必要か: どれだけ対策をしても、セキュリティインシデントのリスクをゼロにすることはできません。重要なのは、発生時に迅速に対応できる体制を事前に決めておくことです。

仕様書への書き方例: 「セキュリティインシデント発生時の連絡体制・初動対応手順を運用マニュアルに含めること。インシデント発生から24時間以内に発注者へ第一報を行うこと。原因分析と再発防止策を報告書として提出すること。」

ベンダーへの伝え方: 「インシデントの定義（何をインシデントとみなすか）」を事前にベンダーとすり合わせておくと、報告基準のずれを防げます。

セキュリティに関する納品物（ドキュメント・テスト結果）

なぜ必要か: 開発完了時にソースコードだけを納品されても、セキュリティ対策の内容を後から確認できません。セキュリティ関連のドキュメントを納品物に含めることで、運用フェーズでの対策継続が可能になります。

仕様書への書き方例: 「以下をセキュリティ関連の納品物として提出すること: セキュリティ設計書、脆弱性診断報告書、セキュリティテスト結果、運用保守時のセキュリティチェックリスト、インシデント対応マニュアル。」

ベンダーへの伝え方: 納品物リストを仕様書に明記しておかないと、「追加料金が必要」と言われるケースがあります。見積もりの段階で納品物の範囲を確認しておくのがポイントです。

OWASP Top 10を発注者の言葉に翻訳する

前章の10項目をさらに根拠づけるフレームワークとして、OWASP Top 10を紹介します。ここではエンジニア向けの技術解説ではなく、「発注者として何を押さえておけばよいか」に焦点を当てます。

OWASP Top 10とは（30秒で分かる概要）

OWASPとは、Webアプリケーションのセキュリティ向上を目的とした国際的な非営利コミュニティです。その代表的な成果物である「OWASP Top 10」は、Webアプリケーションにおける最も深刻なセキュリティリスクを10項目にまとめたもので、世界中の開発者・セキュリティ専門家に参照されています。

2025年版が最新で、17万5,000件以上のCVE（共通脆弱性識別子）レコードの分析に基づいて策定されました。発注者がこのリストを知っておくメリットは、「業界標準の脅威リスト」を根拠にしてセキュリティ要件の妥当性を示せることです。

発注者が特に注意すべき脅威と対応要件

OWASP Top 10:2025の全10項目のうち、発注者が仕様書に反映しやすい6つの脅威と、前章の10項目との対応関係を整理します。

A01: アクセス制御の不備（Broken Access Control） 2025年版でも1位を維持しており、テストされたアプリケーションの100%で何らかの問題が検出されています。前章の「認可・アクセス制御」に対応します。仕様書には「権限を持たないユーザーが他人のデータにアクセスできないこと」と明記しましょう。

A02: セキュリティの設定ミス（Security Misconfiguration） 2021年版の5位から2位に上昇しました。デフォルト設定のまま本番環境で稼働させる、不要な機能が有効なまま放置されるといった問題です。仕様書には「本番環境にデバッグ機能やデフォルトアカウントを残さないこと」と書いておくだけでも効果があります。

A03: ソフトウェアサプライチェーンの失敗（Software Supply Chain Failures） 2025年版で新設された項目で、OWASPコミュニティ調査で回答者の50%が1位に選んだ注目度の高い脅威です。2021年版の「脆弱で古くなったコンポーネント（A06）」を拡張し、OSSライブラリの脆弱性だけでなく、悪意あるパッケージの混入やCI/CDパイプラインの侵害など、ソフトウェア供給網全体のリスクをカバーしています。発注者としては、開発会社が使用するOSSやサードパーティライブラリの管理方針を確認することが重要です。仕様書には「使用しているOSSの一覧（SBOM: Software Bill of Materials）を納品物として提出すること」「既知の脆弱性があるライブラリを本番環境で使用しないこと」と記載しておくと、サプライチェーンリスクへの対策を明確にできます。

A04: 暗号化の不備（Cryptographic Failures） 前章の「通信の暗号化」「データの暗号化と保管ルール」に対応します。古い暗号アルゴリズムの使用や、暗号鍵の不適切な管理がリスクになります。

A05: インジェクション（Injection） 前章の「入力値の検証」に対応します。フレームワークの進化により順位は下がりましたが、依然として深刻な脅威です。

A07: 認証の不備（Authentication Failures） 前章の「認証方式」に対応します。弱いパスワードの許可や、セッション管理の不備が該当します。

このように、前章で解説した10項目の多くはOWASP Top 10が指摘するリスクへの対策と重なっています。ベンダーとの打ち合わせで「OWASP Top 10を踏まえた対策を求めます」と伝えるだけでも、セキュリティ対応の基準が明確になります。

OWASP要件定義書を発注に活用する方法

OWASPは「OWASP ASVS（Application Security Verification Standard）」というセキュリティ要件の検証基準も公開しています。ASVSは3つのレベルに分かれており、扱う情報の機密性に応じて適用レベルを選べます。

• レベル1: すべてのアプリケーションに推奨される基本的なセキュリティ対策
• レベル2: 機密データを扱うアプリケーション向け（多くの業務システムが該当）
• レベル3: 高度なセキュリティが求められるシステム（金融・医療等）

発注者としては、仕様書に「OWASP ASVS レベル2準拠」などと記載することで、セキュリティ要件のベースラインを明確にできます。具体的な項目は、自社のシステム特性にあわせてカスタマイズしてください。

開発会社に確認すべきセキュリティ対応力チェックリスト

セキュリティ要件を仕様書に書けるようになったら、次はその要件を「きちんと実現できるベンダーかどうか」を見極める段階です。ここでは、開発会社の選定や契約前の打ち合わせで確認すべきポイントを、質問形式で整理します。

セキュリティ開発実績の確認ポイント

• 「過去にセキュリティ要件が厳しいプロジェクト（金融・医療・個人情報を扱うシステム等）の開発実績はありますか？」
• 「セキュリティに関するインシデントが過去に発生したことはありますか？その際どのように対応しましたか？」
• 「ISMS（ISO 27001）やプライバシーマークなど、セキュリティ関連の認証を取得していますか？」

実績があるかどうかだけでなく、「具体的にどのようなセキュリティ対策を講じたか」を聞くことで、ベンダーの理解度と実行力が見えてきます。

開発プロセスにおけるセキュリティ施策（コードレビュー・静的解析等）

• 「開発プロセスの中で、セキュリティに特化したコードレビューを実施していますか？」
• 「静的解析ツール（SAST）や動的解析ツール（DAST）を導入していますか？」
• 「セキュリティ・バイ・デザインの考え方に基づいた設計プロセスはありますか？」

開発プロセスにセキュリティチェックが組み込まれているかどうかは、最終的な品質に大きく影響します。

テスト・脆弱性診断の実施体制

• 「リリース前の脆弱性診断は自社で実施しますか？外部の診断会社に依頼しますか？」
• 「脆弱性診断の結果、問題が見つかった場合の修正対応は見積もりに含まれますか？」
• 「定期的なセキュリティテスト（年次の脆弱性診断等）に対応できますか？」

費用や見積もりに関する質問は、コスト面の詳細とあわせて確認しておくと安心です。

インシデント発生時の対応フロー

• 「セキュリティインシデントが発生した場合の連絡体制と初動対応の手順を教えてください」
• 「運用保守契約を結んでいる場合、インシデント対応の範囲と追加費用の基準はどうなっていますか？」
• 「過去のインシデント対応事例を（NDAの範囲内で）共有していただくことは可能ですか？」

これらの質問を打ち合わせで投げかけることで、ベンダーのセキュリティに対する姿勢と実力を見極めることができます。すべてに完璧な回答がなくても、「真摯に回答してくれるか」「改善の意思があるか」は重要な判断材料です。

脆弱性診断・ペネトレーションテストの基礎知識と費用感

セキュリティ要件10項目の中で「脆弱性診断の実施」を挙げましたが、「実際にどんなものか」「費用はいくらくらいか」が分からないと、仕様書に書くかどうかの判断ができません。ここでは、発注者が意思決定するために必要な情報を整理します。

脆弱性診断とペネトレーションテストの違い

この2つは混同されがちですが、目的とアプローチが異なります。

脆弱性診断（Vulnerability Assessment）は、システム全体をスキャンして既知の脆弱性を網羅的に洗い出す検査です。ツールによる自動診断と、セキュリティエンジニアによる手動診断があります。「弱点の一覧表を作る」イメージです。

ペネトレーションテスト（Penetration Test）は、実際の攻撃者と同じ手法でシステムへの侵入を試みるテストです。脆弱性を見つけるだけでなく、「その脆弱性を悪用して実際にどこまで侵入できるか」を検証します。「泥棒の視点でセキュリティを試す」イメージです。

多くのWebシステムでは、まず脆弱性診断をリリース前に実施し、必要に応じてペネトレーションテストを追加する形が一般的です。個人情報や決済情報を扱うシステムであれば、両方の実施を推奨します。

実施タイミングと要件への記載方法

脆弱性診断の実施タイミングは主に3つあります。

1. 開発中（結合テスト〜総合テスト段階）: 早期に脆弱性を発見・修正できるため、修正コストが低い
2. リリース前: 本番環境に近い状態で最終チェックを行う。最も一般的なタイミング
3. 運用中（定期診断）: 年1回〜四半期に1回の頻度で、新たな脆弱性や設定ミスを検出する

仕様書には「リリース前に脆弱性診断を実施すること。診断結果報告書を納品物に含めること」と記載するのが基本です。運用フェーズでの定期診断は、保守契約に含めるか別途契約するかをベンダーと相談してください。

費用の目安と予算計画への組み込み方

脆弱性診断の費用は、診断の種類・範囲・手法によって大きく異なります。以下は2025〜2026年時点の一般的な相場です（GMOサイバーセキュリティ等の公開情報を参考）。

診断種別	費用目安	特徴
ツール診断（自動スキャン）	数万円〜数十万円	安価だが、ビジネスロジックの脆弱性は検出しにくい
手動診断（Webアプリケーション）	50万円〜200万円	専門家がシステムの用途を理解した上で診断。精度が高い
ペネトレーションテスト	100万円〜300万円以上	侵入テスト。規模や対象範囲により大きく変動する

SCROLL→

予算計画のポイントは、脆弱性診断の費用をシステム開発費の一部として最初から見込んでおくことです。「開発費の5〜10%をセキュリティ対策費として確保する」というのが一つの目安です。後から追加で予算を取るよりも、最初から含めておく方がスムーズに進みます。見積もりの全体像についてはシステム開発の見積もりガイドを参考にしてください。

セキュリティ要件の仕様書記載フォーマット例

ここまで解説してきた内容を、実際に仕様書に落とし込む際のフォーマット例を提示します。このテンプレートをコピーして自社のプロジェクトに合わせてカスタマイズしてください。

セキュリティ要件一覧表のテンプレート

要件ID	カテゴリ	要件内容	優先度	備考
SEC-001	認証	（具体的な要件を記載）	必須/推奨	（補足事項）
SEC-002	認可	（具体的な要件を記載）	必須/推奨	（補足事項）
SEC-003	通信暗号化	（具体的な要件を記載）	必須/推奨	（補足事項）
...	...	...	...	...

SCROLL→

各列の意味は以下のとおりです。

• 要件ID: 一意の番号を振ることで、ベンダーとの会話で「SEC-003について質問があります」と具体的に指し示せます
• カテゴリ: 前章の10項目（認証、認可、通信暗号化など）に対応します
• 要件内容: 「何を・どのレベルで実現するか」を明記します
• 優先度: 「必須（Must）」と「推奨（Should）」を分けることで、コスト調整の余地を残します
• 備考: 例外条件やベンダーへの質問事項などを記載します

記入例：個人情報を扱うWebシステムの場合

以下は、ECサイトやお問い合わせフォームなど、個人情報を扱うWebシステムを想定した記入例です。

要件ID	カテゴリ	要件内容	優先度	備考
SEC-001	認証	パスワードは8文字以上、英大文字・小文字・数字・記号を含む。管理者アカウントはMFA必須	必須	MFA方式はベンダー提案を求める
SEC-002	認可	ユーザー権限を管理者・編集者・閲覧者の3段階で設定。権限変更履歴を記録	必須	権限一覧表を別途添付
SEC-003	通信暗号化	全ページHTTPS（TLS 1.2以上）。HTTPからHTTPSへの自動リダイレクト	必須	-
SEC-004	データ暗号化	パスワードはbcryptでハッシュ化。個人情報はAES-256で暗号化保管	必須	暗号化対象データのリストを添付
SEC-005	セッション管理	セッション有効期限60分。無操作30分でタイムアウト。ログアウト時にセッション無効化	必須	-
SEC-006	入力値検証	全入力にサーバー側バリデーション。プリペアドステートメント使用。XSS対策のエスケープ処理	必須	-
SEC-007	ログ・監視	ログイン、権限変更、個人情報アクセス、CRUD操作のログ取得。保管期間1年以上	必須	ログ項目: 日時、操作者、操作内容、IP
SEC-008	脆弱性診断	リリース前に第三者機関による脆弱性診断を実施。高・中リスクはリリース前に修正	必須	費用負担は別途協議
SEC-009	インシデント対応	発生24時間以内に第一報。原因分析と再発防止策の報告書を提出	必須	インシデント定義は別途すり合わせ
SEC-010	納品物	セキュリティ設計書、脆弱性診断報告書、テスト結果、運用チェックリスト、インシデント対応マニュアル	必須	-

SCROLL→

記載時の注意点（曖昧な表現の避け方・優先度の付け方）

仕様書でありがちな失敗は、「適切なセキュリティ対策を講じること」「十分な安全性を確保すること」といった曖昧な表現を使ってしまうことです。これでは、ベンダーが何をすればよいか判断できず、結果的に「ベンダー任せ」と変わりません。

良い要件の書き方のポイントは3つです。

1. 具体的な基準を数値で示す: 「適切なパスワードポリシー」ではなく「8文字以上、英大文字・小文字・数字・記号を含む」
2. 技術的な方式名を含める: 「暗号化すること」ではなく「AES-256で暗号化すること」
3. 検証可能な形で記載する: 「セキュリティテストを実施すること」ではなく「OWASP Top 10の各項目について検証し、報告書を提出すること」

優先度の付け方としては、「法規制やコンプライアンスに関わるもの」と「個人情報保護に直結するもの」は原則「必須」とし、それ以外は「推奨」にすることで、予算に応じた調整の余地を残せます。

まとめ ― セキュリティ要件は「発注者の武器」になる

本記事では、システム開発のセキュリティ要件について、発注者が仕様書に記載すべき10項目を中心に解説しました。

重要なポイントを振り返ります。セキュリティ要件を曖昧にすると責任の空白地帯が生まれること。セキュリティは「後から追加」するとコストが跳ね上がること。そして、発注者がセキュリティ要件を主体的に定義することで、プロジェクトのリスクを大幅に下げられることです。

「完璧な要件を書かなければ」と構える必要はありません。まずは以下の3ステップから始めてみてください。

1. 現状を整理する: 自社のシステムで扱うデータ（個人情報、決済情報など）と、想定されるリスクをリストアップする
2. 10項目でチェックする: 本記事のセキュリティ要件10項目を参考に、仕様書に記載すべき内容を埋めていく
3. ベンダーとすり合わせる: 作成した要件リストをベンダーに共有し、技術的な実現方法と費用を確認する

セキュリティ要件を書くことは、ベンダーへの「注文」ではなく、プロジェクトを成功に導くための「共通言語」を作る作業です。この共通言語があることで、発注者とベンダーの間に信頼関係が生まれ、結果として高品質なシステムが完成します。

過去の外注における失敗パターンについては外注開発の失敗事例も参考にしてください。セキュリティ要件の整備は、こうした失敗を防ぐための最も確実な手段のひとつです。