セキュリティ・バイ・デザインとは、システムやソフトウェアの企画・設計という上流の段階からセキュリティ対策を組み込む考え方です。完成後に対策を後から足すのではなく、開発の初期段階から安全性を織り込むことで、脆弱性の作り込みや後工程での大きな手戻りを防ぎます。近年はDXの進展やサイバー攻撃の高度化を背景に、政府機関のガイドラインでも取り上げられるようになりました。本記事では、定義と背景、導入によるメリットと課題、具体的な進め方、そして混同されやすい用語との違いまでを解説します。
セキュリティ・バイ・デザインとは、情報セキュリティを企画・設計の段階から確保するための方策を指します。内閣サイバーセキュリティセンター（NISC）はこの考え方を「情報セキュリティを企画・設計段階から確保するための方策」と定義しています（※1）。システムが完成してから対策を追加するのではなく、設計思想そのものにセキュリティを位置づける点に特徴があります。
デジタル庁は2024年1月に改訂した「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」で、企画工程から設計、開発、運用まで含めたシステム開発ライフサイクル全体で一貫したセキュリティを確保する方策と定めています（※2）。対象は政府情報システムですが、示された考え方は一般の情報システムにも広く応用できます。
この考え方の起点は、セキュリティを「後から足すもの」ではなく「最初から備わっているもの」として扱う発想の転換にあります。設計段階で守るべき情報や想定される脅威を洗い出し、それに応じた対策を要件として組み込みます。こうすることで、開発が進んだ後に重大な欠陥が見つかり、企画や設計まで巻き戻して作り直す事態を避けられます。
デジタル庁のガイドラインは、実施にあたって守るべき6つの基本方針を挙げています。事後的ではなく予防的に対策を組み込むこと、全てのシステム開発ライフサイクルを保護すること、初期設定値でセキュリティが担保された状態にすること、システム特性に応じて過不足のない対策を実施すること、セキュリティリスクの評価と管理を継続すること、利便性を損なわずにセキュリティを確保することの6点です（※2）。
なお、セキュリティ・バイ・デザインは一度実施すれば終わりというものではありません。同ガイドラインは、新たな脅威の出現やシステム更改の際に再実施の要否を検討し、継続的にリスク対応を図ることが重要だとしています。
従来のセキュリティ対策は、システムを作り終えてから脆弱性診断で問題点を洗い出したり、セキュリティ機器を追加したりする後付け方式が主流でした。この方式では、完成間際に致命的な欠陥が見つかると、納期やコストを犠牲にして手戻りするか、リスクを残したままリリースするかの選択を迫られます。
セキュリティ・バイ・デザインは、この構造的な問題を上流工程での対応によって解消します。両者の違いは次のとおりです。
| 観点 | 後付け型セキュリティ | セキュリティ・バイ・デザイン |
|---|---|---|
| 対策のタイミング | システム完成後 | 企画・設計段階から |
| 脆弱性への向き合い方 | 発見してから修正 | 作り込まないように予防 |
| 手戻りの発生 | 起こりやすい | 抑えられる |
| コストの傾向 | 修正が後工程ほど増大 | 全体として低減しやすい |
ここで注意したいのは、セキュリティ・バイ・デザインは脆弱性診断などの後工程の検証を不要にするものではない点です。
デジタル庁のガイドラインでも、セキュリティ・バイ・デザインを構成する8工程の1つとして「セキュリティテスト」が位置づけられ、システム特性に応じた脆弱性診断の実施が要求事項に含まれています。
上流で作り込みを減らしたうえで、後工程では第三者による客観的な検証を行うという役割分担になります。
セキュリティ・バイ・デザインが求められる背景には、事業環境の変化と脅威の変化があります。デジタル技術の活用が広がって守るべき対象が増える一方、攻撃はより速く巧妙になり、法規制も予防的な対策を求める方向へと進んでいます。後追いの対策だけでは、この変化に追いつくことが難しくなってきました。
DXの推進により、多くの企業がクラウドやIoT、スマートフォンアプリなど複数の技術を組み合わせたサービスを提供するようになりました。技術の組み合わせが増えるほど、攻撃者が狙える接点も増えます。
IoT機器への攻撃は現実に大きな割合を占めています。総務省の「情報通信白書」によると、NICT（情報通信研究機構）が運用する大規模サイバー攻撃観測網NICTERで2024年に観測されたサイバー攻撃関連の通信は約6,862億パケットにのぼり、2015年（約632億パケット）の約10.9倍で過去最高を記録しました。その内容を見ると、IoT機器を狙った通信が最も多く、サイバー攻撃関連通信全体の約3割を占めています（※3）。
IoT機器を狙う攻撃では、従来主流だったMirai型とは異なるIoTボットの感染が拡大しており、家庭用ルータや監視カメラの録画機器など、利用者が感染に気付きにくい機器が引き続き標的になっています。ネットワークにつながる機器が増えるほど、開発段階からの安全確保が必要です。
サイバー攻撃は手法の多様化と高度化が進んでいます。脆弱性が公表されると、それを突く攻撃手法が短期間で出回り、対策が追いつかないうちに標的とされる状況が常態化しています。
IPAの「情報セキュリティ10大脅威2026」でも、組織向けの脅威として「システムの脆弱性を悪用した攻撃」が4位に挙げられています。完成後に対策を足す方式では、こうした速さに対応しきれません。
法規制の面でも、予防的な措置を求める流れが強まっています。EUのGDPR（一般データ保護規則）は、その第25条で、設計段階からデータ保護を組み込む「データ保護・バイ・デザイン」を求めています。日本でも、改正個人情報保護法により事業者が負う責任の範囲が広がり、安全管理措置の重要性が高まっています。個人データを扱うシステムでは、設計段階からセキュリティを組み込む必要性がこうした動きからも増しています。
セキュリティ・バイ・デザインを導入すると、手戻りの削減と品質の安定、そしてコストの低減という効果が期待できます。デジタル庁のガイドラインも、企画工程からセキュリティリスクへの対応方針を定めることで、致命的な対策漏れによる上流工程への手戻りを防ぎ、納期の確保とコストの低減につながるとしています（※2）。
上流工程で脅威を洗い出し、対策を要件として組み込んでおけば、開発後半で重大な欠陥が見つかって設計まで巻き戻す事態を避けられます。手戻りが減れば納期を守りやすくなり、開発全体の見通しも立てやすくなります。
品質の面でも効果があります。工程ごとに対策の基準を定めて実施することで、担当者やシステムによって対策のばらつきが生じることを防ぎ、組織全体のセキュリティ品質を底上げできます。
コスト面の効果は数値で示されています。IPA（情報処理推進機構）の資料では、セキュリティ対策にかかるコストが、対応する工程が後になるほど大きくなることが示されています。設計時の対策コストを1とした場合の各工程の相対的な大きさは次のとおりです（※4）。
| 工程 | 設計時を1としたときの対策コストの目安 |
|---|---|
| 設計時 | 1 |
| 開発時 | 6.5 |
| テスト時 | 15 |
| 運用開始後 | 100 |
同じ脆弱性でも、運用開始後に対処すると設計時の100倍のコストがかかるという試算です。多くの解説記事は「設計時1に対し運用時100」という両端だけを取り上げますが、開発時6.5、テスト時15という中間の値も示されており、工程が進むほど段階的に費用が膨らむ構造が読み取れます。
ただし、この数値は実測に基づく調査結果ではなく、相対的な傾向を示す目安として提示されたものです。金額の予測に使えるものではなく、上流で手を打つほど費用対効果が高いという方向性を示すものとして扱うのが適切です。
セキュリティ・バイ・デザインには効果がある一方で、導入にあたって直面しやすい課題もあります。考え方そのものは平易でも、実際に取り組むには専門的な知見と、判断のよりどころとなる基準が必要になるためです。ここを理解しておくと、導入の準備がしやすくなります。
設計段階からセキュリティを組み込むには、システム設計やコードレビューにセキュリティの視点を持つ人材が関わる必要があります。脅威分析やリスク評価には幅広い知識が求められ、社内だけで体制を組むことが難しい場合も少なくありません。
デジタル庁のガイドラインも、ライフサイクル全体を俯瞰してセキュリティを確保できる専門家を開発チームに指名することが望ましいとしつつ、人材不足によって困難なケースが多いと指摘しています（※2）。さらに、専門家を配置できた場合でも、対策の妥当性が十分に検証されないまま後工程に進んでしまうケースが見られるとしています。そのうえで、開発チームによる対策の実施だけでなく、開発者とは別の専門知識を持つ評価者による客観的なリスク評価を求めています。
セキュリティ・バイ・デザインは比較的新しい概念であり、業界で統一された設計ルールや標準が十分に整備されているとは言えません。そのため「どこまで対策すればセキュアと言えるのか」という基準を組織ごとに検討する必要があり、その分の工数がかかります。
この課題への対応として、公的機関が公開するガイドラインの活用が有効です。デジタル庁のガイドラインは、全ての実施内容を一度に実現することは難しいとしたうえで、自組織のリスクや実現可能性を踏まえ、実施できるところから始めて段階的に成熟度を高めていく進め方を現実的な方法として示しています（※2）。
セキュリティ・バイ・デザインは、リスク分析から始めて、要件定義、設計、実装、テスト、運用まで一貫して進めます。デジタル庁のガイドラインは、システム開発ライフサイクルを8つの工程に分け、各工程で実施すべき内容を定めています（※2）。主な工程と実施する内容は次のとおりです。
| まとまり | 主な工程 | 実施する内容 |
|---|---|---|
| リスク分析と要件定義 | リスク分析／要件定義／調達 | 脅威の洗い出し、要件化、安全な委託先・製品の選定 |
| 設計と実装 | 設計／実装 | 多層防御の設計、セキュアコーディング、堅牢化 |
| テストによる検証 | テスト | セキュリティ機能テスト、脆弱性診断 |
| 運用と継続的な見直し | 運用準備／運用 | 監視、脆弱性管理、インシデント対応、再評価 |
最初に、システムで取り扱う重要情報の種類やその処理フロー、関係者、実施業務、他システムとの連携方法などをまとめた「システムプロファイル」を作成します。これをもとに、システムに想定される脅威を特定します。
脅威の洗い出しには、MicrosoftのSTRIDE（なりすまし、改ざん、否認、情報漏えい、サービス妨害、権限昇格という6つの観点から脅威を分類するモデル）やMITRE ATT&CK（攻撃者の手口を体系化した知識ベース）といったモデルが使われます。
このとき、システム面の脅威だけを見ないことが重要です。ガイドラインは、サービスの仕様に起因する脅威や、利用者・開発者・運用担当者の人的ミスによる脅威も含めて検討することを要求事項としています。特定した脅威について発生可能性と影響度を評価し、対応の優先度や守るべき基準を決めます。
続いて、その方針に沿ってシステムが満たすべきセキュリティの状態を、機能面と非機能面の両方から要件として定義します。この段階では、特定の対策が破られても別の対策で被害を抑える多層防御の考え方に基づいて要件を組み立てることが重要とされています。
ガイドラインは、攻撃の発生自体を防ぐ対策に偏らず、インシデントの検知、有事の対応、サービス復旧のための対策までをバランスよく組み込むことを求めています。外部に委託する場合は、責任範囲を明確にし、安全な委託先や、バックドアなどが含まれない安全な製品を選ぶことも含まれます（※2）。
要件をもとに、具体的な実装方針を設計に落とし込みます。設計で重視されるのは、攻撃を受ける可能性のある接点であるアタックサーフェス（攻撃対象領域）を極力減らすことです。不要な機能やサービスは持たせず、ソフトウェアやミドルウェアの初期設定値をそのまま使わず、外部からの入力は信頼せずに必ず検証します。管理者アカウントには過剰な権限を与えず、多要素認証などで保護します（※2）。あわせて、管理者アカウントの利用者を特定できる仕組みを設け、追跡可能な状態にすることも求められています。
実装段階では、脆弱性を作り込まないためのセキュアコーディングを実施します。ガイドラインは、Webアプリケーションであれば、IPAが公開する「安全なウェブサイトの作り方」に記載された脆弱性への対処を完了していることを求めています。あわせて、OSやミドルウェアなどの基盤について、初期設定のまま使わず堅牢化の設定を施すことも含まれます（※2）。
実装でガイドラインが重視しているのは、担当者によるミスやばらつきを防ぐことです。セキュリティ関連のコーディングや設定は、テンプレートの使用や自動化機能の活用が望ましいとされ、基盤側についてはセキュリティベンチマークやセキュリティ設定を組み込んだシステムイメージ、IaCテンプレートの利用が挙げられています。
ただし、これらのテンプレート自体に脆弱性や設定不備があると複数のリソースに広範囲な影響が及ぶため、事前の検証を必ず実施することとされています。
設計と実装で組み込んだ対策が正しく機能するかを、テストで検証します。セキュリティ機能のテストに加えて、脆弱性診断を実施し、システムに残る脆弱性を取り除きます。診断は、攻撃対象領域を漏れなくカバーするよう、システムの特性に応じた範囲で行います。
Webシステムであればアプリケーション診断とプラットフォーム診断、スマートフォンアプリを使う場合はスマートフォンアプリ診断が対象となります。なお、脆弱性診断についても、デジタル庁が別途「DS-221 政府情報システムにおける脆弱性診断導入ガイドライン」を公開しており、これに従って実施することが原則とされています。
ここで重要なのが、診断の品質をシステムの重要度に合わせる点です。ガイドラインは、重要度の高いシステムでは脆弱性診断ツールを実行するだけの表層的な診断では不十分であり、専門家による高度な診断を追加で実施することが重要だと明記しています（※2）。ツールによる自動的なチェックは網羅の面で役立ちますが、機能の背後にある業務ロジックの穴や複合的な攻撃経路までは捉えきれません。人の目と手による診断が、この差を埋めます。
システムのリリース後も、セキュリティ対策は続きます。運用に入る前に、平常時の監視体制と、インシデント発生時の対応手順を整えておきます。
ガイドラインは、手順を整備するだけでは実際のインシデント時に想定どおり動かないケースが多いとして、主要な想定脅威について関係者を含めた訓練を実施し、実運用上の課題を洗い出したうえで体制や手順を見直すことを求めています。
運用段階では、構成管理や変更管理を行い、脅威情報や脆弱性情報を継続的に収集して、自システムへの影響を分析します。深刻な脆弱性が見つかった場合は、影響を評価して優先度に応じた対応を決めます。
リスクの大きさは一定ではなく、システムの改変や攻撃手法の進化によって変動します。そのため、あらかじめ定めたきっかけや定期的なタイミングでリスクを評価し直すことが求められます。インシデント対応の手順は定期的に見直し、訓練を通じて実際に機能する状態を保つことが大切です（※2）。
セキュリティ・バイ・デザインの周辺には、似た響きの用語がいくつもあります。シフトレフト、セキュリティ・バイ・デフォルト、プライバシー・バイ・デザイン、DevSecOpsは、いずれも設計段階からの安全確保に関わりますが、指すものが異なります。それぞれの位置づけを次の表にまとめ、以下で違いを説明します。
| 用語 | 位置づけ | セキュリティ・バイ・デザインとの関係 |
|---|---|---|
| シフトレフト | 開発工程の管理手法 | 実現するための取り組みの一つ |
| セキュリティ・バイ・デフォルト | 初期設定に関する考え方 | 補完し合う関係 |
| プライバシー・バイ・デザイン | 個人情報保護に特化した考え方 | 対象範囲が異なる |
| DevSecOps | 開発・運用の体制や手法 | ライフサイクル全体での実装形態 |
シフトレフトは、テストやレビューといった工程を開発の早い段階、つまり工程図の左側へ移す実践的な手法です。開発の途中でコードレビューや自動的なセキュリティチェックを行い、脆弱性を早期に見つけて修正コストを下げることを狙います。
これに対してセキュリティ・バイ・デザインは、企画・設計段階から安全を組み込むという全体の方針です。シフトレフトは、その方針を実現するための具体的な取り組みの一つと位置づけられます。両者は対立せず、補い合う関係にあります。
セキュリティ・バイ・デフォルトは、製品やシステムが初期設定の状態で十分な安全性を備えている状態を指します。利用者が特別な設定をしなくても安全に使えるようにすることで、設定ミスによるリスクを抑えます。
セキュリティ・バイ・デザインが設計段階でシステム全体の安全性を高めるのに対し、セキュリティ・バイ・デフォルトは初期設定の安全性に焦点を当てます。
ただし、両者は独立した別々の概念というより、後者が前者に含まれる関係にあります。デジタル庁のガイドラインは、セキュリティ・バイ・デザインの6つの基本方針の3つ目に「初期設定値においてセキュリティが担保された状態を実現すること」を挙げ、これをセキュリティ・バイ・デフォルトの実施と明記しています。デジタル庁のガイドラインも、初期設定値でセキュリティが担保された状態の実現を基本方針の一つに挙げており、両者は組み合わせて用いる関係にあります。
プライバシー・バイ・デザインは、個人情報の保護を最優先に考え、設計段階から保護のための措置を組み込むアプローチです。
1990年代にカナダ・オンタリオ州の情報・プライバシーコミッショナーであったアン・カブキアン博士が提唱したもので、セキュリティ・バイ・デザインより歴史が古い考え方です。「事後的ではなく事前的、救済的ではなく予防的」「初期設定としてのプライバシー」「デザインに組み込まれるプライバシー」など7つの基本原則が示されています。
セキュリティ・バイ・デザインが情報セキュリティ全般を対象とするのに対し、プライバシー・バイ・デザインは個人情報の保護に対象を絞っています。守る対象の範囲が異なります。
DevSecOpsは、開発（Development）と運用（Operations）が密に連携するDevOpsに、セキュリティ（Security）を組み込んだ体制や手法です。デジタル庁のガイドラインは、開発から運用まで含めたライフサイクル全体でセキュリティを確保する方策を、とりわけソフトウェア開発においてDevSecOpsと呼ぶとしています。セキュリティ・バイ・デザインの考え方を、開発と運用が一体となった現場で実装した形がDevSecOpsです。
セキュリティ・バイ・デザインを成功させる鍵は、設計段階でのリスク検討と、テスト段階での客観的な検証を両輪として回すことにあります。どれだけ丁寧に設計しても、組み込んだ対策が実際に機能するかは、検証してみなければ分かりません。設計と検証のどちらかが欠けると、安全性の確からしさが揺らぎます。
検証の場面では、診断の質が結果を左右します。前述のとおり、デジタル庁のガイドラインは、重要度の高いシステムについて、ツールを実行するだけの表層的な脆弱性診断では不十分であり、専門家による高度な診断が重要だとしています（※2）。ここで押さえておきたいのは、ツールによる診断と人手による診断は、優劣ではなく役割が異なるという点です。
ツールによる自動診断は、既知の脆弱性パターンを短時間で網羅的に確認できる点に強みがあります。開発サイクルのなかで繰り返し実行し、変更のたびに全体を通して検査する用途に向いています。一方で、業務ロジックに潜む欠陥や、複数の弱点を組み合わせた攻撃経路のように、システムの文脈を読まなければ判断できない領域は、機械的な検査では捉えにくくなります。重要度の高いシステムでは、経験を積んだ技術者が手動で行う脆弱性診断やペネトレーションテスト（実際に攻撃を試みてシステムの弱点を検証する手法）を組み合わせることで、この差を埋められます。
大切なのは、どちらか一方を選ぶことではなく、対象システムの重要度と開発サイクルに合わせて使い分けることです。ユービーセキュアは、Webアプリケーションの脆弱性を検査するツール「Vex」の開発・提供と、専門家による手動での脆弱性診断・ペネトレーションテストの両方を提供しています。あわせてセキュリティコンサルティングも行っており、設計から検証までを見据えた取り組みを後押しします。
セキュリティ・バイ・デザインは、企画・設計の段階からセキュリティを組み込み、システムのライフサイクル全体で一貫して安全性を確保する考え方です。後付け型と比べて手戻りを減らし、品質を安定させ、コストを抑える効果があります。IPAの資料で紹介されている試算では、運用開始後の対策コストは設計時の100倍にのぼり、早い段階で手を打つ意義は数値でも裏づけられています。
一方で、専門人材の確保や設計ルールの未整備といった課題もあります。デジタル庁のガイドラインをはじめとする公的資料を手がかりに、実施できるところから段階的に取り組むことが現実的な進め方です。
はじめの一歩は、自社の守るべき資産と想定される脅威を洗い出し、それを設計の要件に落とし込むことです。そして、組み込んだ対策が本当に機能するかを、専門家による診断で検証します。設計と検証の両方にセキュリティを組み込む姿勢が、安全なシステムづくりの土台になります。
参考
※1 内閣サイバーセキュリティセンター（NISC）｜情報システムに係る政府調達におけるセキュリティ要件策定マニュアル
※2 デジタル庁｜デジタル社会推進実践ガイドブック DS-200 政府情報システムにおけるセキュリティ・バイ・デザインガイドライン（2024年1月31日）
※3 総務省｜情報通信白書
※4 IPA（情報処理推進機構）｜SEC journal Vol.12 No.3「セキュリティ・バイ・デザインとアシュアランスケース」（2016年12月）