「セキュリティ対策は、開発をお願いする会社に任せておけば大丈夫」——システム開発を外部に発注するとき、つい、そう考えてしまいがちです。しかし、もし納品されたシステムに脆弱性が見つかり、情報漏えいが起きてしまったら、その責任と損失は誰が負うのでしょうか。賠償や信用の失墜、そして大規模な作り直し（手戻り）が発生したとき、最終的に困るのは発注した側です。
とはいえ、社内にセキュリティの専門家がいない状態で、開発会社の進め方に口を出すのは難しいものです。「何を、いつ、どこまで要求すればいいのか分からない」——この判断基準のなさが、発注者にとって一番の不安ではないでしょうか。
この不安に対する答えとなる考え方が「セキュリティバイデザイン」です。これは、システムが完成してからセキュリティ対策を後付けするのではなく、企画・設計という一番最初の段階からセキュリティを組み込んでおくという発想です。そして近年、政府の調達ガイドラインや金融分野の規制でも、この考え方を前提とすることが求められるようになってきました。
本記事では、セキュリティバイデザインとは何かをビジネス担当者向けに平易に解説したうえで、「なぜ後付けの対策は高くつくのか」をコストの観点から示します。さらに、発注者として開発の各工程で「何を要求し、何を確認すべきか」を具体的なチェックポイントに落とし込んでお伝えします。セキュリティを開発会社に丸投げするのではなく、発注者として安心して意思決定できる状態を目指しましょう。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
セキュリティバイデザインとは？発注者がまず押さえる基本
セキュリティバイデザイン（Security by Design）とは、システムやサービスの企画・設計という上流の段階から、セキュリティ確保をあらかじめ組み込んでおく考え方です。「セキュア・バイ・デザイン」と呼ばれることもありますが、ほぼ同じ意味で使われています。
ひとことで言うと「最初から作り込む」発想
家を建てる場面を想像すると分かりやすいかもしれません。完成して住み始めてから「やっぱり鍵を強化したい」「窓に防犯対策を加えたい」と思っても、壁を壊して工事し直すには大きな手間と費用がかかります。一方、設計図を引く段階で防犯を考慮しておけば、無理なく頑丈な家が建てられます。
システム開発でもこれと同じことが起きます。セキュリティバイデザインは、対策を「後から付け足すもの」ではなく「最初の設計図に書き込んでおくもの」として扱う発想です。具体的には、企画段階で「何を守るべきか（守るべき情報資産）」を洗い出し、「どんな脅威があるか」を想定したうえで、その対策を要件や設計に織り込んでいきます。
この「最初から」という時間軸こそが、セキュリティバイデザインの核心です。完成後のセキュリティテストで問題を見つけて慌てて直すのではなく、問題が生まれない作りを最初から目指す——この違いが、後ほど解説するコストとリスクの差を生みます。
なぜ今、発注者にも関係するのか
「それは開発する側が考えることでは？」と感じるかもしれません。しかし、セキュリティバイデザインはいま、発注する側にとっても無視できないテーマになっています。
理由のひとつは、公的なガイドラインで明確に位置づけられたことです。デジタル庁は「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」を策定し、企画から運用までのライフサイクル全体で一貫してセキュリティを確保することを求めています（デジタル庁 DS-200 ガイドライン）。政府のシステム調達では、この考え方の徹底が前提とされています。
さらに、金融分野でも金融庁のガイドラインでセキュリティバイデザインの考え方が求められるなど、規制や取引先からの要求として広がりつつあります（NRIセキュア）。つまり、自社が発注するシステムについても、取引先や監督官庁から「どのようにセキュリティを担保しているか」を問われる時代になっているということです。
発注者がセキュリティバイデザインを理解しておくことは、自社を守るためだけでなく、対外的な説明責任を果たすうえでも重要になっています。なお、発注者として押さえておきたいセキュリティの土台については、ITガバナンスとは？発注者が知るべき情報セキュリティ基礎でも詳しく解説していますので、あわせてご覧ください。
なぜ重要なのか｜後付け対策が招くコストとリスク
セキュリティバイデザインがなぜ重要なのか。それを最も分かりやすく示すのが「対策にかかるコスト」です。同じセキュリティ対策でも、いつ手を打つかによって費用が大きく変わります。
工程が進むほど対策コストは跳ね上がる
情報処理推進機構（IPA）の「セキュリティ・バイ・デザイン導入指南書」では、セキュリティ対策にかかるコストが工程ごとにどう変化するかが試算されています。設計時のコストを「1」とすると、次のように膨らんでいきます（IPA セキュリティ・バイ・デザイン導入指南書）。
対策のタイミング | 設計時を1とした場合のコスト |
|---|---|
設計時 | 1 |
開発段階 | 約 6.5 倍 |
テスト工程 | 約 15 倍 |
運用開始後 | 約 100 倍 |
言い換えれば、設計の段階で手を打っておけば、テスト工程で対応する場合の約15分の1、運用開始後に対応する場合の約100分の1のコストで済むということです。後になればなるほど、すでに組み上がったシステムを部分的に作り直す必要が生じ、影響範囲の確認や再テストも含めて費用が雪だるま式に増えていきます。
経営層に「なぜ最初からセキュリティに投資するのか」を説明する場面では、この数字が強力な根拠になります。上流での投資は、コストの先食いではなく、将来の大きな出費を避けるための合理的な判断なのです。
後付けで起きる典型的な手戻り・トラブル
コストの問題は、単なる金額だけにとどまりません。後付けの対策は、次のような形で発注者を直接困らせます。
- 納期の遅延: 完成間近やリリース直前に脆弱性が見つかると、設計の見直しや作り直しが発生し、予定していた稼働日に間に合わなくなります。事業計画やキャンペーンのスケジュールにも影響します。
- 予算の超過: 当初の見積りに入っていなかった追加対策の費用が発生します。「誰が負担するのか」をめぐって開発会社とトラブルになることもあります。
- インシデントによる損失: 対策が不十分なまま運用を始めてしまい、情報漏えいや不正アクセスが起きた場合、賠償や顧客対応、システム停止による機会損失など、開発費をはるかに上回る損害につながります。
- 信用の失墜: セキュリティ事故は報道や口コミで広がりやすく、一度失った顧客や取引先の信頼を取り戻すには長い時間がかかります。
これらはいずれも、「最初の設計段階で考えておけば防げたはずのもの」が、後工程で表面化したケースです。
セキュリティを開発会社に丸投げしてよいか？
ここで、多くの発注者が抱く疑問に正面からお答えします。「専門知識がないのだから、セキュリティは開発会社に任せるべきでは？」という考えは、半分正しく、半分危ういものです。
技術的な実装そのものは、当然ながら開発会社の領域です。しかし、「何を守るべきか」「どこまでの安全性を求めるか」を決められるのは、その業務やデータの中身を知っている発注者だけです。開発会社は、扱う情報がどれほど重要か、漏えいしたときに自社がどれだけのダメージを受けるかまでは分かりません。
ここを伝えないまま「よろしくお願いします」と丸投げしてしまうと、開発会社は一般的な水準の対策しか組み込めません。その結果、自社にとって本当に守るべきものが守られていない、というすれ違いが生まれます。さらに、契約や要件にセキュリティの取り決めを明記していなければ、いざ事故が起きたときに「どちらの責任か」をめぐって争いになりかねません。
つまり、丸投げの不安を解消する方法は「開発会社を信頼しないこと」ではなく、「守るべきものと求める水準を発注者がきちんと伝え、協働の枠組みを作ること」です。その具体的な進め方を、次の章以降で見ていきましょう。
セキュリティバイデザインのメリットとデメリット
セキュリティバイデザインの全体像をつかむために、発注者にとってのメリットと、知っておくべきデメリット・限界の両面を整理します。良い面だけを見て過度に期待したり、逆に「難しそう」と敬遠したりせず、現実的な判断ができるようにしておきましょう。
発注者が得られるメリット
- トータルコストの低減: 前章で見たとおり、上流での対策は後付けに比べて大幅に安く済みます。開発費だけを見ると初期費用は増えますが、手戻りやインシデント対応まで含めた総額では有利になります。
- 手戻りの防止と納期の安定: 設計段階で問題を潰しておくことで、リリース直前の大きな作り直しを避けられ、スケジュールが読みやすくなります。
- 保守・運用のしやすさ: セキュリティを考慮した設計は構造が整理されており、運用開始後の改修や機能追加もしやすくなります。
- 対外的な信頼の獲得: 「企画段階からセキュリティを組み込んでいる」と説明できることは、取引先や顧客、監督官庁に対する信頼につながります。前述のとおり、規制や調達要件として求められる場面も増えています。
知っておくべきデメリット・限界
一方で、現実的な制約もあります。これを踏まえておくことで、開発会社との会話がかみ合いやすくなります。
- 「どこまでやれば安全か」の基準が曖昧: セキュリティに「これで100%安全」という終わりはありません。コストとリスクのバランスをどこで取るかは、案件ごとに判断が必要です。後述するように、公的ガイドラインを共通の物差しとして使うと判断しやすくなります。
- 初期コストと工数の増加: 上流で脅威の分析や要件の検討を行う分、企画・設計フェーズの作業量と費用は増えます。ここを「無駄なコスト」と捉えず「将来の出費を抑える投資」と位置づけることが重要です。
- セキュリティ人材の不足: 発注者・開発会社の双方で、セキュリティに詳しい人材が限られていることが少なくありません。社内に専門家がいない場合は、開発会社の体制や、外部の脆弱性診断サービスの活用を前提に進める必要があります。
メリットとデメリットを天秤にかけると、多くのシステムにおいて「上流で投資しておくほうが結果的に得」という結論になります。ただし、その投資を正しい場所に振り向けるには、発注者が工程ごとに適切な関与をすることが欠かせません。
開発工程別｜発注者がやるべきこと・確認すべきこと
ここからが本記事の核心です。セキュリティバイデザインを実現するために、発注者が開発の各工程で「何を要求し、何を確認すればよいのか」を具体的に整理します。専門用語が並ぶ技術の中身まで踏み込む必要はありません。発注者の役割は、「守るべきものを伝える」「約束を明文化する」「約束が守られたかを確認する」の3点に集約されます。
まず全体像を表で示します。
工程 | 発注者がやること | 確認・要求のポイント |
|---|---|---|
企画 | 守るべき情報資産とリスクの洗い出し | RFP（提案依頼書）にセキュリティの方針を記載する |
要件定義 | セキュリティ要件の明文化と合意 | 対策項目を具体的にリスト化し、開発会社と合意する |
設計・実装・テスト | 設計レビューと脆弱性診断の確認 | 診断の実施範囲と結果報告を受け入れ条件にする |
運用 | 脆弱性対応・責任分界の取り決め | 運用後の対応体制と費用負担を契約で定める |
それぞれの工程を見ていきましょう。
企画フェーズ｜守るべきものを決め、RFPに記載する
最初の工程である企画フェーズでは、「このシステムで何を守るのか」を発注者自身が言語化します。ここが曖昧なまま進むと、後のすべての工程がぶれてしまいます。
具体的には、次のような粒度で情報資産を洗い出します。
- 扱うデータの種類: 個人情報（氏名・住所・連絡先）、決済情報（クレジットカード・口座）、社内の機密情報（取引データ・営業秘密）など、システムが保持・処理するデータを具体的に列挙する。
- データの重要度: それぞれのデータが漏えい・改ざん・消失した場合に、自社や顧客がどれだけの被害を受けるかをランク付けする。
- 想定される脅威: 不正アクセス、情報漏えい、なりすまし、サービス停止など、起こると困る事態を想定する。
これらを整理したら、RFP（提案依頼書）に「セキュリティに関する方針」として記載します。「個人情報を扱うため高い水準のセキュリティを求める」「準拠してほしいガイドラインがある」といった方針を最初に示しておくことで、開発会社は提案段階からセキュリティを織り込んだ見積り・体制を提示できます。逆にここで触れずに進めると、後から要件を追加することになり、前述の「後付けコスト」が発生します。
要件定義フェーズ｜セキュリティ要件を明文化し合意する
企画で示した方針を、要件定義フェーズで具体的な「要件」に落とし込みます。ここで発注者が確認すべきは、セキュリティ対策の項目が漏れなくリストアップされ、開発会社と合意できているかどうかです。
発注者として最低限おさえておきたいセキュリティ要件の項目には、次のようなものがあります。
- 認証: ログインの仕組み（パスワードの強度ルール、多要素認証の要否など）
- アクセス制御: 利用者の役割に応じて、見られる・操作できる範囲を制限する仕組み
- 通信・データの暗号化: 通信経路や保存データを暗号化し、盗み見・流出を防ぐ
- ログの取得・監視: 「いつ・誰が・何をしたか」を記録し、不正の検知や事故後の追跡を可能にする
- 脆弱性診断: 開発したシステムに弱点がないかを専門的にチェックする工程の組み込み
- インシデント対応: 事故が起きたときの検知・通報・復旧の手順
これらの項目を要件定義書に明記し、「どこまで対応するか」を開発会社と一つずつ合意していきます。専門的な書き方が不安な場合でも、項目の抜け漏れがないかを発注者がチェックすることには大きな意味があります。発注者が仕様書に入れるべきセキュリティ要件の具体的な書き方は、セキュリティ要件の書き方ガイドで項目ごとに詳しく解説しています。
設計・実装・テストフェーズ｜診断の実施を受け入れ条件にする
設計から実装、テストにかけては、開発会社が主体的に作業を進める工程です。発注者は技術的な作業そのものには関与しませんが、「約束した対策が実際に組み込まれているか」を確認する役割があります。
特に重要なのが、脆弱性診断です。これは、完成したシステムに既知の弱点や設定ミスがないかを専門的に検査する作業です。受け入れ（検収）の前に、次の観点を確認しましょう。
- 診断を実施したか: そもそも脆弱性診断を行ったかどうか。ツールによる自動診断だけか、専門家による手動診断も含むかで精度が変わります。
- 診断の範囲: システムのどの部分を診断したか。重要な機能やデータを扱う箇所がカバーされているか。
- 結果と対応: 見つかった問題（指摘事項）が、納品前にきちんと修正されているか。修正されていない項目があれば、その理由と対応予定を確認する。
これらを口頭ではなく「診断結果の報告書」として提出してもらい、受け入れの条件にしておくことが大切です。報告書があれば、後から「対策していたはず」「いや聞いていない」という水掛け論を避けられます。
運用フェーズ｜運用後の対応体制と責任を契約で定める
システムは納品して終わりではありません。運用を始めた後にも、新しい脆弱性が発見されたり、攻撃の手口が進化したりします。そのため、運用フェーズで「誰が・どこまで対応するか」をあらかじめ取り決めておく必要があります。
契約や保守契約で確認・合意しておきたいポイントは次のとおりです。
- 脆弱性発見時の対応: 運用開始後に新たな脆弱性が見つかったとき、誰が対応し、その費用は誰が負担するのか。
- インシデント時の責任分界: 万一セキュリティ事故が起きた場合、原因の調査・復旧・通知などの責任を発注者と開発会社のどちらが、どこまで負うのか。
- 対応のスピード（SLA）: 緊急の脆弱性が公表されたとき、どのくらいの期間で対応してもらえるのか。
- 保守の範囲と費用: 定期的なセキュリティ更新や監視が保守契約に含まれているか。含まれない場合の追加費用はどうなるか。
これらを契約書に落とし込んでおくことで、運用中のトラブルで「想定外の請求が来た」「対応してもらえなかった」という事態を防げます。契約に盛り込むべきセキュリティ条項の具体的なチェックリストは、システム開発の外注契約で押さえる情報セキュリティ条項チェックリストにまとめています。
セキュリティバイデザインを成功させる発注者の3つのポイント
ここまで工程ごとの具体的なアクションを見てきました。最後に、それらを貫く「発注者としての姿勢・考え方」を3つのポイントに集約します。工程別のアクションが「何を・いつ・どうするか」だとすれば、こちらは「どんなスタンスで臨むか」の指針です。
ポイント1｜企画段階から「何を守るか」を開発会社と共有する
最もありがちな失敗は、要件定義や設計が進んでから、あるいは完成間近になってからセキュリティの話を持ち出すことです。それでは後付けになり、コストもリスクも跳ね上がります。
成功する発注者は、企画というもっとも早い段階で「自社が何を守りたいのか」を開発会社と共有します。守るべき情報資産と、許容できないリスクを最初にテーブルに乗せることで、開発会社はそれに見合った提案・設計ができます。セキュリティは「最後に確認するもの」ではなく「最初に共有するもの」だと捉え直すことが出発点です。
ポイント2｜セキュリティ要件・費用負担・責任分界を契約で明確にする
「言った・言わない」を避けるために、口約束に頼らず文書で残すことが鉄則です。具体的には、セキュリティ要件（何をどこまで対策するか）、費用の負担（追加対策が発生したときに誰が払うか）、責任の分界（事故が起きたときにどちらがどこまで責任を負うか）の3点を、要件定義書や契約書に明記します。
これは開発会社を疑うためではなく、お互いが安心して協働するための土台づくりです。明確な取り決めがあれば、開発会社も対応範囲がはっきりして見積りやすくなり、発注者も「ここまでは守られる」という安心を持って運用に臨めます。
ポイント3｜公的ガイドラインを共通言語として活用する
「どこまでやれば安全か」という基準の曖昧さは、セキュリティバイデザインの最大の難しさです。これを補うのが、公的機関が示すガイドラインです。
IPA、デジタル庁、NISC（内閣サイバーセキュリティセンター）などが、セキュリティバイデザインの考え方や具体的な要件策定の手引きを公開しています。社内に専門家がいなくても、これらを「共通の物差し」として開発会社との会話に持ち込めば、感覚的な議論ではなく、根拠のある水準合わせができます。「このガイドラインに沿って進めたい」と伝えるだけでも、議論の質は大きく変わります。
よくある質問（FAQ）
Q1. セキュリティバイデザインとは簡単に言うと何ですか？
システムの企画・設計という一番最初の段階から、セキュリティ対策をあらかじめ組み込んでおく考え方です。完成してから後付けで対策するのではなく、「最初から安全に作る」ことを目指します。後付けに比べてコストとリスクを大きく抑えられるのが特徴です。
Q2. セキュア・バイ・デザインとの違いは何ですか？
「セキュリティ・バイ・デザイン（Security by Design）」と「セキュア・バイ・デザイン（Secure by Design）」は、ほぼ同じ意味で使われています。どちらも「設計段階からセキュリティを組み込む」という考え方を指します。文脈や提唱する組織によって表記が異なるだけで、発注者として両者を厳密に区別する必要はありません。
Q3. メリット・デメリットを一言でいうと？
メリットは「後付けに比べてコスト・手戻り・事故リスクを大きく減らせること」です。デメリットは「企画・設計段階の作業量と初期費用が増えること」と「どこまで対策すれば十分かの基準が一概に決められないこと」です。総合的には、上流で投資するほうが結果的に得になるケースが多くなります。
Q4. 発注者（発注側）は具体的に何をすればよいですか？
「守るべき情報資産を洗い出してRFPに記載する」「セキュリティ要件を明文化して開発会社と合意する」「受け入れ前に脆弱性診断の結果を確認する」「運用後の対応体制と責任分界を契約で定める」の4点が基本です。技術的な実装は開発会社に任せつつ、何を守りどこまで求めるかを発注者が主導します。
Q5. なぜ後からセキュリティ対策をすると高くつくのですか？
すでに組み上がったシステムを部分的に作り直す必要が生じ、影響範囲の確認や再テストの手間も加わるためです。IPAの試算では、設計時の対策コストを1とすると、テスト工程では約15倍、運用開始後では約100倍に膨らむとされています（IPA セキュリティ・バイ・デザイン導入指南書）。
Q6. 中小企業でもセキュリティバイデザインは実践できますか？
実践できます。むしろ専任のセキュリティ人材がいない中小企業ほど、「守るべきものを最初に決め、要件と契約で明文化する」という発注者主導の進め方が効果的です。すべてを完璧にやろうとせず、公的ガイドラインを物差しに優先順位をつけることが現実的です。中小企業のセキュリティ対策の優先順位や費用目安については、中小企業のセキュリティ対策完全ガイドもあわせてご覧ください。
まとめ｜セキュリティは「発注の最初」から考える
セキュリティバイデザインとは、システム開発の企画・設計という最も早い段階からセキュリティを組み込む考え方です。本記事の要点を振り返ります。
- 上流での作り込みがコストとリスクを最小化する: IPAの試算では、設計時の対策は運用開始後に対応する場合の約100分の1のコストで済みます。後付けは高くつき、納期遅延や事故のリスクも招きます。
- セキュリティは開発会社に丸投げしない: 技術的な実装は開発会社の領域ですが、「何を守るか・どこまで求めるか」を決められるのは発注者だけです。企画・要件定義の段階から関与することが、安全な発注の前提になります。
- 工程ごとに役割を果たす: 企画で守るべきものを洗い出し、要件定義で対策を明文化し、受け入れ前に脆弱性診断を確認し、運用後の責任分界を契約で定める——この4つが発注者の基本アクションです。
- 公的ガイドラインを共通言語にする: IPA・デジタル庁・NISCのガイドラインを物差しとして使えば、専門家がいなくても根拠のある水準合わせができます。
セキュリティを「最後に確認するもの」から「最初に共有するもの」へと捉え直すこと。それが、後悔のない発注への第一歩です。発注時のセキュリティ要件・契約・基礎知識については、本記事内で紹介した関連記事もあわせてご活用いただき、安心してシステム開発の意思決定を進めてください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
