セキュリティ・バイ・デザイン (G検定)

1. 定義と概要

セキュリティ・バイ・デザインとは、システムやIoT（あらゆるモノがインターネットにつながる仕組み）製品、ソフトウェアの企画・設計段階から情報セキュリティ対策を組み込み、開発から運用までのライフサイクル全体を通じて安全性を確保する考え方です。英語では「Security by Design」と表記され、その名のとおり安全性をあらかじめ設計に組み込むという意味を持つ用語で、頭文字をとって「SBD」と略されることもあります。

IPA（情報処理推進機構）は、情報セキュリティやIT人材育成に関する国の施策を担う独立行政法人です。IPAは「セキュリティ・バイ・デザイン導入指南書」の中で、脅威分析（システムがどのような攻撃や被害を受けうるかをあらかじめ洗い出す作業）やセキュリティ要件定義（システムに求められるセキュリティ上の仕様をあらかじめ定める作業）を挙げています。これらを上流工程（企画・設計など開発の早い段階）に組み込む具体的な進め方を、同書は示しています。

従来のシステム開発では、機能を作り上げた後の完成間際やリリース後にセキュリティ対策を追加する「後付け」の対応が一般的でした。作りたい機能を先に形にし、安全性の確認は最後にまとめて行うという進め方です。

しかし、脆弱性（システムやソフトウェアに存在する、攻撃者に悪用されうる弱点）の発見が遅れるほど手戻りの範囲が広がり、修正コストが跳ね上がるという課題があります。IPAの試算では、設計段階のセキュリティ対策コストを1とした場合、運用段階で発覚した脆弱性への対応コストは100倍に達するとされ、この課題を踏まえて上流工程からセキュリティを組み込む考え方が広まりました。

2. 試験対策ポイント

セキュリティ・バイ・デザインの定義における要点は、セキュリティ対策を運用開始後に追加するのではなく、企画・設計段階からあらかじめ組み込むという順序にあります。IPAの試算（設計時のコストを1とすると運用時は100倍）は、対策を先送りするほど修正コストが膨らむことを示す具体的な根拠として整理しておきたい数値です。

AIシステムの文脈では、企画・設計段階からあらかじめ想定しておくべき脅威があります。代表的なものを並べると、次のように整理できます。

AI特有の脅威	どのような攻撃・行為か
敵対的攻撃	AIモデルの入力データに人間が気づきにくい細工を加え、判断を誤らせる攻撃
データ汚染（ポイズニング攻撃とも呼ばれます）	AIが学習する前のデータに細工をして、学習結果をゆがめる攻撃
モデルの盗用	学習済みAIモデルの中身や挙動を不正にコピー・模倣する行為

敵対的攻撃は、モデルそのものには手を加えず、入力の側から判断をゆがめる攻撃です。いっぽうデータ汚染は、学習の前段でデータを汚すことによってモデルの性質そのものをゆがめます。細工が入り込む場所が違うため、設計段階で想定しておく備えも別ものになります。モデルの盗用は、判断をゆがめるのではなく、学習済みモデルという成果物そのものを不正に持ち出される行為です。これらは、G検定の「安全性とセキュリティ」の項目でセキュリティ・バイ・デザインと並んで扱われる背景にあたる論点です。

推進主体としては、IPAの導入指南書のほか、デジタル庁が政府情報システム向けに策定したガイドライン（2022年）が挙げられます。加えて、国家サイバー統括室（2025年7月に内閣サイバーセキュリティセンター＝NISCを改組して発足した、政府のサイバーセキュリティ政策をまとめる組織）による普及啓発も進んでいます。官民双方から上流工程でのセキュリティ組み込みが呼びかけられている点も、押さえておきたいポイントです。

3. 関連概念との比較・相違点

プライバシー・バイ・デザインとの最大の違いは、保護する対象にあります。セキュリティ・バイ・デザインは外部からの攻撃や脅威に対する防御を主眼に置くのに対し、プライバシー・バイ・デザインは個人情報やプライバシーの保護に焦点を絞った考え方です。

どちらも設計の上流工程で対策を組み込む点は共通していますが、何を守るために組み込むのかという軸で区別する必要があります。組み込むタイミングが同じでも、守ろうとしているものが違うわけです。

バリュー・センシティブ・デザインとの違いは、対象範囲の広さに表れます。バリュー・センシティブ・デザインは、公平性や自律性といった人間の価値観全般を設計段階で考慮する広い概念であり、セキュリティ・バイ・デザインはそのうち脅威からの防御という一領域にあたる位置づけです。両者の詳細な関係については本記事では立ち入らず、対象範囲の広さという軸だけを示すにとどめます。

3つを、設計段階で何を目的に組み込むのかという軸で並べると、位置づけの違いがはっきりします。

概念	設計段階で組み込む目的	扱う範囲
セキュリティ・バイ・デザイン	外部からの攻撃や脅威への防御	脅威からの防御という一領域
プライバシー・バイ・デザイン	個人情報やプライバシーの保護	個人情報の保護に焦点を絞った範囲
バリュー・センシティブ・デザイン	公平性や自律性など人間の価値観の尊重	価値観全般を扱う広い概念

いずれも「あとから足す」のではなく「はじめから織り込む」という発想を共有しています。混同を避ける手がかりは、その設計が何を守るためのものかという一点にあります。

4. ビジネス・実務での活用シナリオ

IoT機器メーカーでは、製品の企画段階から通信の暗号化や認証方式といったセキュリティ要件を設計に組み込む取り組みが進んでいます。出荷後にファームウェア（機器に組み込まれた基本的な制御用ソフトウェア）の脆弱性が発覚すると、大規模な回収や現地での修正対応が必要になり、費用も期間も膨らみます。設計段階での組み込みは、こうした事後対応の規模を抑えることにつながります。

AI・機械学習の開発現場では、AIシステムの企画・設計段階で敵対的攻撃やデータ汚染を想定した脅威分析を行い、学習データの管理体制やモデルの監視方法をあらかじめ設計に反映する取り組みが進んでいます。学習が終わってから対策を検討するのでは、汚染されたデータの混入経路を特定するだけでも大きな手間がかかります。設計段階での想定は、こうした後戻りを避ける効果を持ちます。

金融機関や重要インフラの分野では、システム開発の要件定義・設計フェーズにセキュリティ要件を組み込み、開発工程全体で継続的にセキュリティ検証を行う体制が構築されています。この体制はDevSecOps（開発と運用の全工程にセキュリティ対策を組み込む開発の進め方）と呼ばれ、リリース後に一括で検証する方式に比べて、問題の早期発見につながります。障害や情報漏えいが社会的な影響を及ぼしやすい業界であるからこそ、上流工程からの作り込みが意義を持ちます。

5. 要点まとめ

• セキュリティ・バイ・デザインとは、システムやIoT製品の企画・設計段階からセキュリティ対策を組み込む考え方で、後付け対応との違いが定義の核心です。
• IPAの試算では設計段階のコストを1とすると運用段階での対応コストは100倍に達するとされ、上流工程での対策が修正コストの抑制につながります。
• AIシステムでは敵対的攻撃・データ汚染・モデルの盗用といった脅威を企画・設計段階から想定しておく必要があり、G検定の「安全性とセキュリティ」の項目で扱われます。

6. 確認問題