セキュリティバイデザインを開発プロセスの中で実践する

切れ目なくつなげる開発プロセスの構築

第1章・第2章では、社会的要請としての背景と、設計・要件定義の考え方を整理しました。しかし実際の開発現場では、すべてのセキュリティ施策を最初から理想的な形でそろえられるとは限りません。すでに運用しているもの、試行の中で有効性を確認したもの、これから導入するものが混在するのが一般的です。そのため、既存の開発プロセスや関係部署の役割をふまえながら、無理なく続けられる形で少しずつ整えていく必要があります。

つまり、セキュリティバイデザインを機能させる鍵は、設計書を埋めることではありません。そこで整理した対策方針を、実装、レビュー、運用まで切れ目なくつなげることです。

当社では、継続的なセキュリティ対策を実現するために、図1のようなセキュリティ確認を組み込んでいます。

リリース前の確認だけでは手戻りが大きい

従来から、図1の❹に該当するリリース前の脆弱性診断や各種レビューは、重要なセキュリティ対策として実施されてきました。特に高い信頼性が求められるシステムでは、こうした後工程の確認は現在も不可欠です。ただし、近年の開発では、後工程中心の確認だけでは対応しにくい場面が増えています。

開発速度と変更頻度の上昇

背景には、開発速度と変更頻度の上昇があります。アジャイル開発やクラウド活用が一般化し、機能追加や改修は短い単位で繰り返されるようになりました。さらに、生成AIによる実装支援によって、開発者が扱うコード量そのものも増えています。

環境では、問題を終盤でまとめて見つけると、コード修正だけでは済みません。設計の見直しや、テストのやり直し、関係者との再調整などが必要になることもあり、発見が遅いほど手戻りは大きくなります。

終盤の指摘が開発に与える影響

これは単に工数が増えるという話ではありません。終盤での指摘は、開発側から見ると予定外の作業の差し込みとして受け止められやすく、開発の優先順位やリリース計画に影響し、本来進めたかった改善や機能追加にも影響が及びやすくなります。こうした状態が続くと、セキュリティ対策は重要だと理解されていても、日々の開発プロセスの中では受け身の対応になりがちです。

どのタイミングで何を確認し、どう開発の流れへ組み込むかまで考えて初めて、セキュリティバイデザインは実務上の意味を持ちます。

ここからは、図1の❶～❸、および❺に該当する、設計段階で整理した対策方針を実際の開発プロセスの中で継続的に機能させるための「運用」について、筆者の所属するウェルスナビで実際に行っている進め方をもとに説明します。

設計段階で見えた気になる点をヒアリングと開発要件につなげる

ヒアリングの標準化と案件の切り分け

設計段階の確認は、すべての案件に一律の厳密さで適用するのではなく、まず案件ごとのリスクを切り分けることから始めます。扱う情報、外部公開の有無、利用者数、外部連携の有無などを確認し、リスクが高い、あるいは構成が複雑な案件では設計上の懸念点をより深く整理します。

次の項目は案件ごとに一から考えるのではなく、ヒアリングのたたき台として持っておくと実務で扱いやすくなります。

• 扱う情報の種類：個人情報、認証情報など、保護の重要度が高い情報を扱うか
• 認証・認可の設計：認証方式、権限設計、利用者ごとに実行できる操作の分け方
• 接続環境：外部連携の有無、ネットワークの公開範囲
• 利用規模：想定利用者数、一般公開の有無

第2章で示されたセキュリティリスク分析や脅威モデリングの観点を、こうしたヒアリング項目に置き換えていると考えるとわかりやすいでしょう。こうした切り分けをしたうえで、リスクが高い、あるいは構成が複雑な案件では、開発チームから構成や処理フローをヒアリングし、どの点を重点的に見るべきかを整理します。

脅威モデリングの本来の目的は、脅威一覧を作ることではなく、守るべきものと優先順位について認識をそろえることです。したがって、セキュリティ担当だけで完結させるのではなく、開発側とどこが危ないか、何を先に押さえるべきかを合わせることが求められます。

脅威モデリングによる実装方針の具体化

対策の優先順位と実装上の考慮点の合意

脅威モデリングの観点で設計段階の確認すべき点を整理すると、開発チームと認識を合わせやすくなります。まずセキュリティ担当側で気になる点を整理し、それをたたき台として開発チームと会話することで、機能のどこにリスクがあり、どの対策を優先すべきかを具体化できます。このとき大切なのは、対象機能で何を守るべきか、どのリスクを優先して対策すべきかを共有することです。対策の優先順位や実装上の考慮点を会話しながら決めることで、設計段階での話を、そのまま開発時の確認事項にしやすくなります。

この進め方の利点は、設計段階のリスクが開発チームにとって具体的な確認事項へ変わる点にあります。たとえば、

• 認可漏れが懸念されるなら操作ごとの権限確認をレビュー項目に入れる
• 公開範囲が広く影響が大きいなら入力検証やログ確認を要件に加える
• 外部連携が多いなら接続先ごとの認証方式や失敗時の扱いを先に詰める

といった形です。脅威モデリングを考え方として理解するだけでなく、設計段階で見えた気になる点をヒアリング項目や開発要件に変えることで、開発時の確認事項として扱いやすくなります。

後続工程へ引き継ぐ確認観点の整理

設計段階で確認した論点は、その場で議論して終わりにせず、後続工程で参照できる形にしておくことも重要です。当社では、ヒアリング時に出てきた気になる点を、開発チームが見返しやすい粒度で整理するようにしています。たとえば、

• どの利用者がどの操作を実行できるか
• 外部公開されるエンドポイントはどこか
• 認証済みであっても追加の認可確認が必要な操作は何か
• 入力値やアップロードファイルの取り扱いで注意すべき箇所はどこか

といった観点です。こうした観点は、案件ごとの設計レビューで都度確認するだけでなく、ヒアリングシートや確認項目として持っておくことで、抜け漏れを減らしやすくなります。

セキュリティ要件を機能⁠・非機能要件へ落とし込む

要件へ落とし込む際には、セキュリティ要件という独立した塊として扱うより、機能要件や非機能要件と並ぶ形で書き下したほうが、開発プロセスに馴染みやすいです。たとえば、

• 権限のない利用者は当該操作を実行できない
• 外部公開APIでは入力値検証を必須とする
• 監査ログとして残すべきイベントを定義する

といった形で、実装側が判断しやすい表現にするほうが運用しやすいでしょう。抽象的な指摘にとどめず、仕様や確認項目として扱える形に変えることが、設計段階の議論を実務へつなげるうえで欠かせません。

設計段階の確認は単独の作業ではありません。設計段階で見えてきた気になる点を、その後のヒアリングやレビュー、開発時の確認事項として「使える形」にすることは、後続工程の精度を上げる起点になります。後述するAI診断やコードレビューでも、設計段階で気になった点を持ち込むことで、一般的な脆弱性確認だけではなく、その案件固有の懸念点が実装に残っていないかを見やすくなります。

ガードレールとして静的解析と依存ライブラリ対策を組み込む

静的解析（SAST）を既存プロセスへ統合する運用

当社では、SAST（Static Application Security Testing：静的アプリケーションセキュリティテスト）の観点を含む静的解析のしくみとしてJetBrains Qodana（以下、Qodana）を用い、ソースコードを継続的に確認しています[1]。Qodanaはもともと開発プロセスの中で利用されていたツールでしたが、本取り組みではそれをセキュリティバイデザインの文脈でも活用する形としました。既存の開発プロセスを大きく変えずに済むため、追加コストや開発者への負荷を抑えながら組み込みやすい点もメリットでした。

重大リスクに絞ったブロックルールの整備

既存の運用では、誤検知による過度なブロックを避けるため、指摘はアラートとしてpull request上に表示し、対応の判断は開発側に委ねる形がとられています。これは、開発速度との両立を考えた運用です。一方で、セキュリティ上の重大リスクについては、通知だけではなく、より強い扱いが必要になる場面もあります。

そのため現在は、Qodanaの運用を主管するチームと連携しながら、すべてを一律にブロックするのではなく、セキュリティ上の重大度が高いものに絞ってpull request段階で扱えるよう、運用ルールとしくみの整備を進めています。誤検知の影響を抑えつつ、重大な問題は開発フローの中で確実に扱うことを目指した調整です。既存のアラート運用を否定することではなく、その前提を尊重しながら重大リスクに限って扱いを変えることが肝要なのです。

セキュリティ対策を「日常のワークフロー」にする工夫

Qodanaのような既存ツールを活用する利点は、単に新しい製品を増やさずに済むことだけではありません。開発者にとって見慣れたワークフローの中で扱えるため、セキュリティ対策が別の特殊な手順になりにくい点も大きいです。セキュリティ施策は、正しさだけでなく、日常的な開発の中で無理なく扱えることが定着の前提であると考えています。

その意味で、すでに使われているツールやプロセスを活用しながら、セキュリティ上の確認を追加していく進め方は、現場に定着させやすい方法です。これは通常の開発だけでなく、AI駆動開発のように実装速度が上がる環境でも、危険なコードや依存関係を早い段階で見つけ、必要に応じて対処するためのガードレールとして機能します。

サプライチェーンリスクを抑える多層的な対策

依存ライブラリについても、同様に開発中から継続的に確認し、必要に応じて制御する必要があります。現在の開発ではOSSの利用が前提となる一方、脆弱なライブラリや悪性パッケージの混入といったサプライチェーンリスクも無視できないからです。

この点については、Orca Security[2]のクラウドセキュリティプラットフォームを用いて、クラウド環境全体のリスクを継続的に把握しています。その中で、SCA（Software Composition Analysis：ソフトウェア構成分析）相当の機能を利用し、利用中のパッケージやバージョン、関連する脆弱性を確認できるようにしています。これにより、特定の脆弱性や悪性パッケージが話題になった際にも、自社環境で該当するコンポーネントを利用しているかを確認しやすくなります。

SCAによる依存コンポーネントの把握と影響確認

SCAは、利用中のOSSやサードパーティコンポーネントを把握し、既知の脆弱性などのリスクを確認するための手段です。利用中のコンポーネントやバージョンを継続的に追えるようにしておくことで、新たな脆弱性や悪性パッケージの情報が出た際にも、影響範囲を比較的短時間で確認しやすくなります。依存ライブラリ管理は、導入後に一度確認して終わりではなく、平時の把握と有事の確認を支えるしくみとして考えたほうがよいでしょう。

依存ライブラリ対策についても、重要なのはサプライチェーンリスクがあると説明することではなく、開発中のどの場面でそれを扱うかを明確にすることです。具体的には、次のように役割を分けて考えると整理しやすくなります。

• 利用状況の把握：平時から利用中のコンポーネントやバージョンを可視化する
• 脆弱性公表時の影響確認：話題化した脆弱性が自社環境に影響するかを確認する
• パッケージ取得時の制御：悪性パッケージが入り込む前に止める入口対策として機能する

これらを分けて考えることで、依存ライブラリ管理が単なる棚卸しではなく、継続的なセキュリティ対策として運用しやすくなります。

入口対策としての悪性パッケージの遮断

悪意のあるパッケージの混入対策としては、GMO Flatt Security株式会社が提供するTakumi byGMO（以下、Takumi）のソフトウェアサプライチェーンリスク対策機能であるTakumi Guardの活用を進めています[3]。Takumi Guardは、パッケージ取得時にプロキシとして間に入り、取得しようとしているパッケージを検査し、悪意のあるものと判断された場合にはインストールをブロックするしくみです。執筆時点（2026年5月）でnpm、PyPI、RubyGems、Goに対応しています。

Takumi Guardを採用した理由は、後述するAIを用いたコード診断でもTakumiのセキュリティ診断機能を利用しており、運用をそろえやすく、既存の開発フローへ組み込みやすかったためです。

当社ではTakumiを導入しているため、単にブロックするだけでなく、ログを監視できる体制も併せて整備している段階です。依存ライブラリの問題は、導入後に把握するだけでなく、取得の段階で止めることにも意味があります。ソースコードに対するSASTと同様に、依存ライブラリも後から確認するのではなく、開発中に把握し、必要に応じてその場で対処できるようにしておく必要があります。

このように、SASTと依存ライブラリ対策は、いずれも第2章で述べられたガードレールを実装段階で具体化したものです。Qodanaによるコード確認、Orca Securityによる依存関係の把握、Takumi Guardによる取得時の制御を組み合わせることで、後工程だけに依存しないセキュリティ対策へつなげています。

AIでコードを広く確認し⁠、人が内容を判断する

AIエージェントで脆弱性調査の確認範囲を広げる

ソースコードがある程度そろった段階では、セキュリティAIエージェントによるソースコード診断も取り入れました。具体的には、Takumiのセキュリティ診断機能を利用しています。

この診断を実装がある程度進んだ段階で実施するのは、ルールベースの静的解析だけでは見つけにくい点（認可漏れ、複数処理にまたがる不整合、例外処理経由の情報露出、ビジネスロジックに依存する問題など）を、コード全体の文脈をふまえて広く確認しやすいためです。

ただし、AIの出力をそのまま開発へ渡す運用には注意が必要です。問題がないコードを危険と判定する誤検知もあれば、本来見つけるべき問題を見逃すこともあります。また、同じ入力でも出力が変わる揺らぎがあるため、一度の実行結果だけで判断するのは容易ではありません。そのため、Takumiのセキュリティ診断機能は、自動判定装置ではなく、確認範囲を広げる補助として使うのが現実的です。

AIの出力を精査する人間側の専門性

指摘の妥当性を判断するためのスキル

AIによる診断結果を開発へ渡す前には、セキュリティ担当によるレビューが欠かせません。ただし、このレビューには一定の専門性が必要です。AIは込み入った指摘を返すことがあるため、その指摘が本当に妥当か、実装や仕様をふまえて問題として扱うべきかを判断するには、脆弱性診断の経験やソースコードを読む力が求められます。AIが広い範囲を確認できるようになるほど、人間側にはその出力を見極める力が必要になるでしょう。

AIによるソースコード診断の精度は、対象システムの仕様や構成をどれだけふまえて確認できるかにも左右されます。認可や状態遷移、外部連携の前提がわからなければ、精度が下がりやすいです。一方で、マルチプロダクト化が進む環境では、セキュリティ担当がすべてのプロダクトを開発者と同じ深さで理解するのは現実的ではありません。事業会社におけるセキュリティの業務は、脆弱性診断やレビューだけではなく、相談対応、ルール整備、インシデント対応など多岐にわたるためです。

開発側と連携した診断精度の向上

当社では、最初から完全な理解を前提にするのではなく、まず簡易的な構成や仕様をヒアリングし、その情報をもとにAI診断の観点を調整する進め方をとりました。得られた結果はセキュリティ担当が精査したうえで開発へ共有し、開発側には仕様をふまえたフィードバックを返してもらいます。このやり取りを通じて、どのような情報をAIに渡すと有効か、どの観点を重点的に確認させるべきかといったノウハウが、セキュリティ担当側にも少しずつ蓄積されます。

当社では、同じ対象に対して複数回実行し、結果を比較・統合することで見逃しの低減を図りました。さらに、診断結果はセキュリティ担当が内容を確認し、優先度や修正方針を整理したうえで開発へ共有しています。必要に応じて修正例も合わせて提示することで、開発側は調査の負担を抑えながら改修に集中しやすくなると考えています。AIの出力をそのまま渡さず、人が責任を持って整理してから渡す形が、実務上は無理のない運用です。

開発側の調査負荷を減らすフィードバックの工夫

「修正の方向性」まで踏み込む連携

修正例を提示することには、単に親切という以上の意味があると考えています。セキュリティ上の指摘事項は、問題の意味がわかっても、どう直すのが妥当かを判断するのに時間がかかることがあります。特にAIの診断結果は、論点の発見には強くても、開発側にとってそのまま実装に移せる形とは限りません。そこで、セキュリティ担当が実装の方向性まで整理して伝えることで、開発側は診断結果の解釈よりも改修に時間を使いやすくなります。指摘して終わりではなく、修正しやすい形で渡すことが、AIを活用したレビューでは重要でした。

この運用では、開発者に対して仕様上の不明点を質問しやすい関係を作っておくことも重要です。セキュリティを優先するあまり、開発側の事情をふまえずに対応を求めたり、指摘だけを返して改善案や修正の方向性を示さなかったりすると、やり取りが続きにくくなります。AIを活用したレビューを機能させるうえでも、単に診断結果を返すのではなく、改善しやすい形で伝えることが求められます。

設計段階の懸念を実装レビューへつなぐ

「設計段階で見えた気になる点をヒアリングと開発要件につなげる」節で整理した点をAIレビューへ反映することも有効でした。たとえば、設計段階で認可や公開範囲に注意が必要だとわかっていれば、その観点を持ってTakumiに確認させることができます。こうすることで、一般的なコード診断だけでなく、その案件で特に気をつけるべき点が実装に残っていないかを見やすくなります。脅脅威モデリングとAIレビューは別の活動ではなく、前者で見えた点を後者で再確認する関係にある、ということです。

AIは万能ではありませんが、人が見るべき点を広く拾い上げる手段としては有効です。重要なのは、AIに丸投げしないことと、人が責任を持つ範囲を明確にすることです。設計責任も最終判断も人に残しつつ、確認範囲を広げるためにAIを活用する役割分担が、現場で運用しやすい形になります。

PoCで検証し⁠、継続運用へつなげる

開発フローへの適合性を検証するPoCの実施

新しい統制を導入する際には、いきなり全体導入せず、構想段階で現場開発者、開発リーダー、CTOへ内容を説明し、意見をもらったうえでPoC（Proof of Concept：概念実証）を実施しました。PoCでは、精度だけでなく、開発フローに組み込みやすいかも重視しました。具体的には、次のような観点で評価しています。

• CI/CDと無理なく連携できるか
• レビュー待ち時間が増え過ぎないか
• 開発者が結果を理解しやすいか

セキュリティ施策は、検出性能だけ高くても、現場で使われなければ意味がありません。

PoCを通じた合意形成と信頼関係の構築

運用面の合意と前提の共有

PoCはツールや手法の評価に加えて、前提認識をそろえる役割も果たしました。どこまで自動化できるのか、どこからは人が判断するのか、どの程度の精度なら現場で許容できるのか、といった点は、実際に試してみないと見えにくいものです。PoCを通じてこうした前提を共有できると、本番導入後の想定より厳しい、想定より使いにくいといったずれを減らしやすいです。技術面だけでなく、運用面の合意を作る場としてPoCを考えることが重要でした。

社会的要請を開発現場のメリットとして伝える

実務上のすり合わせを行うことにはもう1つ大きな意味があります。現場に対して、セキュリティ施策を外から持ち込まれた制約ではなく、一緒に改善する対象として見てもらいやすくなることです。実際の案件に対して試しながら、何が有効で、何が負担になるのかを開発側と一緒に確認することで、導入後の納得感は大きく変わります。

第1章で紹介されたCISAのSecure by Design PledgeやEUのCRAなど、ベンダーに求められる設計責任は重要です。こうした社会的な流れは、現場へ取り組みを説明するうえでも重要な材料になります。しかし、開発チームにとって直接の関心事は、日々の開発をどう進めるかです。「⁠規制対応だから必要」という言い方だけでは十分ではありません。そのため、説明の際には次のような開発現場にとっての利点として伝えることを意識しました。

• 設計段階で確認しておけば後からの差し戻しが減る
• レビュー観点が明確になることで開発側の判断負荷を下げられる
• 重大な問題を早く見つけることで終盤の修正コストを下げられる

社会的な要請を背景にしつつも、現場では開発上のメリットとして伝えるほうが受け入れられやすいです。

早期発見の実績が生む信頼関係

実際、脅威モデリングを取り入れたPoCでは、開発初期の段階から重点的に確認すべき箇所を特定できました。また、別のPoCでは、従来より約3週間早い段階で脆弱性を把握し、開発側と修正方針を協議できた案件もありました。早い段階で問題を見つけられれば、設計や実装の大きな方向を変えずに対応できる場合が多く、手戻りを抑えやすくなります。これは制度への対応のためだけではなく、開発を円滑に進めるうえでも有効な取り組みであることを示しています。

PoCの意義は、技術的な有効性の確認だけではありません。開発チームとの関係づくりにもあります。いきなりルールを持ち込むのではなく、考え方を説明し、一緒に試し、改善しながら導入する。この過程を経ることで、セキュリティ部門は最後に確認する部署ではなく、安全に進めるために相談できる相手として認識されやすくなると考えています。セキュリティを単発のチェックではなく、開発文化の一部として扱ううえでも、この進め方は重要でした。

継続運用するための課題

継続的な取り組みを広げていくうえでは、導入時の工夫だけでなく、運用し続けられる形を考える必要もあります。レビュー観点の標準化、ナレッジ共有、人材育成、AIによる一次整理の活用などを通じて、属人性を下げながら運用を広げていくことが今後の課題です。

設計責任を果たすことは、単に規制や社会要請に応えることではありません。それを無理なく続けられる運用の形にすることまで含めて考える必要があります。

継続運用・改善の段階では、導入したしくみを一度作って終わりにせず、運用状況を見ながらルールや確認観点を見直していく必要があります。

おわりに

セキュリティバイデザインは、設計や実装の考え方として理解するだけでは定着しません。脅威モデリングやガードレールの考え方は、

• ヒアリング項目
• 開発要件
• Qodanaによるコードチェック
• Orca Securityを用いた依存ライブラリ把握
• Takumiのセキュリティ診断機能によるレビュー

といった具体的な形へ落とし込むことで初めて、開発の現場で機能します。また、設計責任も、単なる制度対応ではなく、手戻りの削減や品質向上といった現場の言葉へ置き換えて説明することで導入しやすくなります。

本章で紹介した取り組みは、完成された理想モデルの紹介ではありません。実務の中で、すでに運用しているもの、PoCで有効性を確認したもの、導入に向けて整備を進めているものを組み合わせながら、開発プロセスの中へセキュリティ確認を組み込んでいく実践例です。設計で考えたことを、実装、レビュー、診断、運用につなげ、開発中に回り続ける形にしていく。そのうえで、自動化と人の判断を適切に分担し、相談しやすい関係を作ることが、継続的な運用につながります。

セキュリティバイデザインを現場で機能させるとは、設計書に項目を追加することではなく、開発プロセスの中で安全性を継続的に扱える状態を作ることにあるのだと、本章で実感していただけたのなら幸いです。