発注者が押さえるべきセキュリティ要件

システム開発を外注するとき、セキュリティは「開発会社がやってくれるもの」と考えていないでしょうか。発注者が要件として書かなければ、対策の範囲は開発会社ごとにばらばらになります。この記事では、発注者が押さえるべきセキュリティ要件として、RFPや要件定義に書く項目、個人情報を扱う場合の追加要件、公的なチェックリストの使い方、委託先の確認方法を解説します。

発注者がセキュリティ要件を決めるべき理由

セキュリティ対策は、非機能要件（機能そのものではなく、性能や安全性など品質に関する要件）の一つです。非機能要件は見積に直結します。書かれていない対策は見積に入らず、後から追加すると費用も期間も増えます。

また、何をどこまで守るべきかは、扱う情報の重要度で決まります。それを判断できるのは、情報の持ち主である発注者です。

IPA（情報処理推進機構）の情報システム・モデル取引・契約書第二版でも、発注者と開発会社がやり取りしながらセキュリティ仕様を作るプロセスが整理されています。発注者は「お任せ」ではなく、仕様作りの当事者になることが求められています。

RFPや要件定義に書くべきセキュリティ項目

RFP（提案依頼書）や要件定義には、少なくとも次の項目を書いておきます。

すべてを最高水準にする必要はありません。IPAの非機能要求グレードは、システムの性格に合わせて求める水準を選ぶための道具です。社内向けの小さなツールと、顧客が使う会員サイトでは、必要な水準が違います。RFP全体の書き方はRFPの書き方で解説しています。

個人情報を扱う場合の追加要件

顧客や従業員の個人情報を扱う場合は、上の項目に加えて次の点を決めます。

• 集める項目を必要最小限にする（不要な項目は最初から持たない）
• 保持期間と、期間を過ぎたデータの削除方法
• 本人確認書類などは、画像を保存するか、確認した事実だけを記録するか
• 閲覧できる担当者の範囲と、閲覧の記録
• 開発やテストで本番の個人データを使わない（匿名化したデータを使う）
• 海外のサーバーや海外の事業者がデータを扱うかどうか

個人情報保護法では、個人データの取扱いを外部に委託する場合、委託先に対して「必要かつ適切な監督」を行う義務があります（第25条）。具体的には、委託先の選定、委託契約の締結、委託先での取扱状況の把握が求められます。詳細は個人情報保護委員会のガイドライン（通則編）で確認できます。再委託がある場合の扱いも、契約で決めておきましょう。

IPAなどが公開しているチェックリストの使い方

公的機関や業界団体は、無料で使える資料を公開しています。代表的なものを紹介します。

• 安全なウェブサイトの作り方（IPA）：Webシステムで起きやすい脆弱性と対策をまとめた資料です。付属の「セキュリティ実装チェックリスト」を、開発会社に記入してもらう使い方ができます。
• 中小企業の情報セキュリティ対策ガイドライン（IPA）：2026年3月に第4.0版が公開されています。付録の「5分でできる！情報セキュリティ自社診断」は、自社の体制を点検するのに使えます。
• 非機能要求グレード（IPA）：上の章で紹介したとおり、求める水準を選ぶ道具です。
• JNSA（日本ネットワークセキュリティ協会）も、セキュリティに関する調査報告やガイドを公開しています。

使うときのコツは3つです。

1. 全項目を求めず、システムの重要度に合わせて必要な項目を選ぶ
2. 選んだ項目をRFPに添付し、開発会社に「対応する・しない・代替策」を回答してもらう
3. 回答を契約書や仕様書に反映し、記録として残す

回答を残しておけば、提案の比較にも、納品時の確認にも使えます。

委託先のセキュリティ体制の確認方法

開発会社を選ぶ段階では、次の点を質問して確認します。

• ISMS（情報セキュリティマネジメントの第三者認証）やプライバシーマークを取得しているか
• 開発環境やソースコードへのアクセスを、誰にどう許可しているか
• 再委託の有無と、再委託先の所在国
• 本番データを開発環境に持ち出すことがあるか
• リリース前の脆弱性診断を、誰がどの方法で行うか
• 事故発生時、何時間以内に誰へ報告するか
• 退職者や契約終了者のアカウントをいつ削除するか
• AIツールにソースコードや顧客データを入力するときのルール

認証の有無だけで判断せず、実際の運用を具体的に聞くことが大切です。答えがあいまいな会社は、運用も整っていない可能性があります。開発会社の選び方全般は開発会社の選び方もご覧ください。

受託開発の現場から

ある受託開発会社が、セキュリティ要件について商談や提案で伝えていることを紹介します。

• 非機能要件は、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境まで検討します。ただし全部を一から作り込むと工数が大きくなります。そこで、標準的なテンプレートで代替できる部分は確認だけにとどめる、という選択肢も示しています。
• ほかの開発会社に構築を任せる場合、クラウドの認証基盤の設定値やAPIまわりのセキュリティ設定まで指示しないと、「よしなに」済まされるリスクがあると注意しています。
• AIでコードレビューを行う際、どの国のどのAIにソースコードを見せるかは慎重に判断すべきだと話しています。安価なAIを使うかどうかは、コストと信用のトレードオフになると説明しています。
• インフラの強化やセキュリティ対策には別途費用がかかります。そのため、月々のランニング費用や原価と合わせて、どこまで対策するかを決めるよう勧めています。

まとめ

• セキュリティ要件は見積に直結するため、発注者がRFPや要件定義に書く
• 必要な水準はシステムの重要度で変わる。非機能要求グレードで水準を選ぶ
• 個人情報を扱うなら、最小限の収集、保持期間、委託先の監督を決める
• 公的チェックリストは取捨選択して添付し、開発会社の回答を記録に残す
• 委託先は認証の有無だけでなく、運用の具体的な手順を確認する

どこまで対策すべきか分からない段階でも、FastProposal の無料AI相談で案件の内容を入力すると、検討すべき論点と費用の目安を数分で整理できます。開発会社への相談前の準備にご活用ください。