シフトレフトでセキュリティを強化！メリットや導入のポイントとは？

シフトレフトとは、テストやセキュリティ対策を開発の終盤にまとめて行うのではなく、要件定義や設計など上流工程から段階的に組み込んでいく考え方です。従来のウォーターフォールモデルでは、品質確認が後工程に集中しがちなため、問題の発覚が遅れるほど修正コストが膨らむ課題がありました。

シフトレフトを導入することで、不具合や脆弱性を早期に検出・修正でき、手戻りを減らしながら品質向上やコスト削減を実現しやすくなります。近年では、アジャイル開発やCI/CDの普及に伴いリリースサイクルが短期化する中で、DevOpsの実践とあわせてシフトレフトの採用が広がっています。本記事では、シフトレフトの意味、注目される背景、メリット・デメリット、具体的な導入手順に加え、セキュリティ対策への適用やシフトライトとの違いまでを解説します。

シフトレフトとは何か

シフトレフトは、品質確認やセキュリティ対策を開発の終盤に集約するのではなく、上流工程から段階的に組み込む考え方を指します。ソフトウェア開発の工程を左（上流）から右（下流）への流れとして見たとき、品質に関わる活動をより左側（上流）に移す（シフトする）ことが名称の由来です。

開発工程を左に寄せるという考え方

開発の流れを、要件定義、設計、実装、テスト、リリースの順に並べると、テストや品質確認は終盤にまとめて行われるのが従来の一般的な進め方でした。シフトレフトは、こうしたテストや確認作業を、設計や実装など、より早い段階に前倒しして組み込む考え方です。

例えば、設計段階でレビューを実施し、仕様上の矛盾や考慮漏れを早期に洗い出したり、実装直後にユニットテストを実行して、変更が既存機能に影響を与えていないかを確認したりします。早い段階でこまめに確認を挟むことで、問題の影響範囲が小さいうちに対処でき、手戻りによる開発の停滞を防ぐのがシフトレフトの考え方の基本です。

従来のウォーターフォールモデルとの違い

ウォーターフォールモデルは、要件定義から設計、実装、テストと開発工程を順番に進める手法で、基本的に前の工程へ戻りません。そのため、テスト工程ではじめて問題が見つかると、設計や実装まで戻って直すことになり、手戻りが大きくなりやすい傾向です。

独立行政法人 情報処理推進機構（以下、IPA）の「セキュリティ・バイ・デザイン導入指南書」^※1によれば、要件定義・設計段階での脆弱性対策コストを「1」とした場合、テスト工程では15倍、運用開始後の修正では100倍にまで膨れ上がるとされており、早期修正の経済的合理性が極めて高いことが示されています。

シフトレフトは、終盤に集中しがちな確認作業やセキュリティ対策を上流工程へ前倒しすることで、手戻りの規模とコストを抑えるアプローチです。セキュリティの観点では、「セキュリティ・バイ・デザイン」が設計段階からセキュリティを確保する考え方として対応します。

また、V字モデルの観点からもシフトレフトの効果は説明できます。V字モデルでは、左側の工程（要件定義・設計）と右側の工程（各種テスト）が対になっており、例えば要件定義の内容はシステムテストで、設計の内容は結合テストで検証されます。左側の工程で品質やセキュリティの作り込みを徹底するほど、右側のテスト工程で重大な欠陥が発見されるリスクが低減し、大規模な手戻りを防げることが特徴です。

シフトレフトが今注目される背景

シフトレフトが求められる背景には、ソフトウェア開発を取り巻く環境の変化があります。短い開発サイクルで計画・実装・改善を繰り返し、変化する要件に素早く対応するアジャイル開発や、コードの自動ビルド・テスト・統合からデプロイまでを自動化し、継続的に行うCI/CD（継続的インテグレーション／継続的デリバリー）が普及し、開発からリリースまでを短い周期で回す手法が主流になりつつあります。

こうした開発スタイルで、品質確認やセキュリティ対策を終盤にまとめて行う従来のやり方を続けると、リリースのたびにテスト工程がボトルネックとなり、開発全体のスピードが損なわれてしまいます。

開発スピードの加速と品質維持の両立

アジャイル開発やCI/CDの普及により、ソフトウェア開発のリリースサイクルは大幅に短期化しています。DX推進でもアジャイル開発の有効性が注目されており、短い反復単位で開発・リリースを繰り返す手法は今後さらに広がると見られています。

アジャイル開発のような開発スタイルの場合、リリースのたびに外部のセキュリティベンダへ診断を委託したり、テスト工程に品質確認を集中させたりする従来の進め方では、確認待ちの時間がリリース回数に比例して積み上がり、スピードと品質の両立が困難になりがちです。

現状求められているのが、品質確認やセキュリティ対策を開発プロセスの中に組み込み、チーム自身が継続的に検証できる体制へ移行することです。デジタル庁が2024年に公開した「CI/CDパイプラインにおけるセキュリティの留意点に関する技術レポート」^※2でも、CI/CDパイプラインにセキュリティ検証を自動化の範囲に組み込むことの重要性が指摘されています。

シフトレフトは、開発の高速化と品質維持を両立させるための基本的なアプローチといえます。

後工程で発覚するバグの修正コスト増大

不具合は、見つけるのが遅いほど直す範囲が広がりやすくなります。例えば、設計上の誤りが原因だった場合、実装が進んだ段階で発覚すると、ソースコードの修正だけでは済みません。仕様書、画面設計、データ定義、テスト項目にまで修正が連鎖し、工数が大幅に膨らみます。さらに、リリース後に不具合が発覚した場合、利用者への影響調査や緊急パッチ適用に加え、損害賠償やブランド価値の失墜、法的責任の追及といった経営リスクが波及し、修正コストは指数関数的に増大します。

ソフトウェア品質の業界団体CISQ（Consortium for Information & Software Quality）が2022年に公表したレポートによれば、米国における低品質ソフトウェアによる損失は年間約2.41兆ドルに達すると試算されています^※3。このうち、後から手直しが必要になる技術的負債（テクニカルデット）の累積だけでも約1.52兆ドルにのぼります。同レポートは、バグの発見と修正が開発ライフサイクル全体で最大の単一コスト要因であると指摘しており、問題を後工程に持ち越すほど経済的影響が拡大することを示しています。

DevOpsの普及と継続的な改善文化

DevOpsは、開発と運用が分断されることなく連携し、リリース後も継続的にシステムを改善し続ける開発文化です。この前提では、運用中に検知した問題や利用者からのフィードバックを、次の開発サイクルに素早く反映する仕組みが不可欠です。一方で、品質確認やセキュリティ対策が終盤の工程に集中していると、フィードバックを受け取ってから改善が反映されるまでに時間がかかり、DevOpsが目指す迅速な改善サイクルが機能しません。

シフトレフトは、開発の早い段階からテストやセキュリティ検証を組み込むことで、問題の検知から修正までのリードタイムを短縮し、DevOpsの継続的な改善サイクルを支える基盤として機能します。開発プロセス全体を通じて品質を確認し続ける体制を整えることが、DevOps文化の定着にもつながるといえます。

シフトレフト導入がもたらすメリット

シフトレフトの利点は、単にテストを前倒しすることではありません。問題が小さいうちに見つかり、直す範囲が小さくなることで、品質、コスト、スピードがそろいやすくなります。ここでは、現場で実感しやすい3つのメリットを、バグ、品質、リードタイムの観点から整理します。

バグの早期発見と修正コストの削減

シフトレフトの最も直接的なメリットは、不具合を開発の早い段階で発見・修正できることです。要件や設計のレビュー、実装直後の小さなテスト、変更のたびの自動チェックなどを通じて、不具合の芽を上流工程のうちに検出・除去します。

前述のとおり不具合は下流工程で発見されるほど修正コストが増大するため^※3、早期に発見できれば修正の対象は局所的であり、影響範囲の調査や関連ドキュメントの修正など付随作業も最小限に抑えられます。IPAは上流工程の品質について「設計レビュー・要件定義強化のススメ」^※4を公開し、レビュー活動を通じた上流工程での欠陥検出の重要性を、定量的なデータに基づいて提言しています。早期発見が増えるほど、直す対象が局所的になるため、作業の見通しも立てやすくなります。

ソフトウェア全体の品質が向上する

ソフトウェアの品質は、最終テストの結果だけで決まるものではありません。要件定義、設計、実装という各工程での判断と作り込みの積み重ねが、最終的な製品の信頼性や堅牢性を左右します。

シフトレフトでは上流での確認が増えるため、仕様のあいまいさや設計の無理を早い段階で検出できます。結果として、コードの修正にとどまらず、仕様や設計方針そのものの見直しにもつながり、ソフトウェア全体の品質底上げが可能です。

また、国際規格ISO/IEC 25010（国内ではJIS X 25010）は、製品品質を「機能適合性、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性」という8つの特性で体系化しており、シフトレフトによって上流工程から品質を意識した活動を行うことは、これら多面的な品質向上に寄与します。なお、2023年に改訂されたISO/IEC 25010:2023では、安全性（Safety）が独立した品質特性として追加されて9特性に再編されており、安全性が問われる領域での重要性が一段と高まっています（国内のJIS化は本稿執筆時点で進行中）。

深刻な問題を後工程に持ち越さないために、開発の早い段階から検知と修正のサイクルを回すことが、製品全体の品質安定に直結するポイントです。

開発のリードタイムを短縮できる

開発におけるリードタイムとは、アイデアの着想から機能が利用者に届くまでの時間を指します。後工程で大きな手戻りが発生すると、修正・再テスト・再レビューといった作業が集中し、リリーススケジュールの見通しが立てられません。

シフトレフトを導入することで、要件や設計の段階で問題を検出・解消できるため、後工程での大規模な手戻りが減少し、開発プロセス全体の流れがスムーズになります。上流工程で品質を作り込んでいればテスト工程での欠陥が減り、結果としてテスト工程の負荷が軽減されるため、リリースまでの所要時間も短縮されます。

さらに、CI/CDパイプラインによるテストの自動化とシフトレフトを組み合わせることで、コード変更のたびに品質確認が即座に実行され、確認待ちの時間の大幅な削減が可能です。早期の品質確認と自動化の仕組みがかみ合うことで、開発の各工程で生じていた待ち時間やボトルネックが解消され、アイデアからリリースまでのリードタイムを短縮できます。

シフトレフト導入のデメリットと注意点

シフトレフトの導入は、従来の開発工程を再構築する取り組みであり、初期段階では既存業務の負荷増大などが発生し、役割分担の調整が必要な場合があります。メリットだけを期待して始めると、現場が回らず形骸化しがちです。ここでは、導入時に起きやすい3つの課題を、負荷、スキル、道具の観点で整理します。

開発初期段階の業務負荷が増加する

これまで後工程で実施していた確認作業を前倒しすると、要件や設計の段階で対応すべきタスクが増加します。例えば、レビューの回数が増えたり、テスト設計の準備を早期に開始したりする必要が生じます。短期的には、開発初期の工数が増大したと感じられることも少なくありません。

Carnegie Mellon大学ソフトウェア工学研究所（SEI）は、テストの前倒しには意識の転換だけでなく、人材・プロセス・技術にまたがる支援的な仕組みづくりが必要であり、テスト活動は相互に関連する多層的な取り組みだと述べています^※5。

最初から広げすぎず、まずは前倒しする作業の範囲を決めて、負荷が急に増えない形に整えることがポイントです。チーム全体でシフトレフトの目的と進め方について合意を形成し、段階的に導入することで、初期負荷の増加を抑えながらメリットを得られます。

開発者に求められるスキルセットの変化

シフトレフトでは、開発者がコードを書くことに加えて、テストコードの実装やセキュリティ上の指摘を理解して修正する場面が増加します。別の担当が最後に確認する前提で運用していた組織ほど、役割の境界が変わり、現場に戸惑いが生じます。

従来はテスト専任チームが担っていたテスト設計を開発者自身が行うケースや、静的解析ツールが検出したセキュリティ上の脆弱性を開発者が自ら修正するケースも増えるでしょう。

CISQは、ソフトウェアテストの改善には標準化されたテスト手法や自動テストの仕組み、品質計測の基盤を組織的に整える必要があると提言しています^※3。組織としては、チーム内で共通のチェックリストや手順書を用意し、短い研修や勉強会で「なぜその指摘が出るのか」「どこを直すのか」などの判断基準を共有することが有効です。

組織的な学習支援の仕組みを整えることで、個人の経験差が出にくくなり、チーム全体として安定した品質を維持できます。

適切なテスト自動化ツールの導入

シフトレフトを効率的に実践するうえで、テスト自動化は不可欠な要素です。早い段階で頻繁に確認を行うには手作業だけでは限界があり、変更のたびに自動でチェックが実行され、結果がすぐフィードバックされる仕組みを構築することで、前倒しの効果を最大限に引き出せます。

CI（継続的インテグレーション）ツールを活用してコード変更時にユニットテストや静的解析を自動実行する、テストフレームワークを導入してテストコードの作成・管理を効率化するなどの方法が有効です。デジタル庁の技術レポートでも、CI/CDパイプラインにセキュリティ検証を自動化の範囲に組み込むことの重要性が指摘されており、ツール選定にあたっては自社の開発環境や目的に合ったものを見極めなければなりません^※2。

また、導入にあたっては初期コストの発生、自動化に対応できる人材の確保、社内での理解促進などの課題も想定されます。まずは効果が見えやすい範囲から段階的に自動化を進め、運用までを見据えた体制づくりを行うことが、シフトレフトの定着に向けた現実的なアプローチといえます。

セキュリティ対策におけるシフトレフト

開発初期から脆弱性対策を組み込む

セキュリティ対策は開発の終盤ではなく、設計段階から組み込むことが重要です。NISTのSSDF（SP 800-218）^※6やIPAの「セキュリティ・バイ・デザイン導入指南書」^※1でも、各開発工程にセキュリティの実践を統合する必要性が示されています。

上流工程で実施すべき主なセキュリティ対策の例は次の通りです。

対策	内容
脅威モデリング	設計段階で攻撃対象となりうる箇所を洗い出す
セキュアコーディング規約の策定	情報の扱い方、権限設計、ログ方針などを事前に定める
IaCによるクラウド構成管理	Terraform等でインフラをコード化し、設定ミスを自動検知する

上流工程からセキュリティを組み込むことで、リリース後に重大な脆弱性が発覚するリスクを大幅に抑えられます。

SAST（静的アプリケーションセキュリティテスト）

SAST（静的アプリケーションセキュリティテスト）は、プログラムを動かす前に、ソースコードを解析して潜在的な脆弱性を検出する手法です。例えば、入力値の検証が不十分な記述や、認証情報のハードコーディングといったセキュリティ上の問題を、早い段階で発見できます。

シフトレフトの目的は、開発プロセスの中で継続的に脆弱性診断を行い、修正コストを抑えることです。そのため、開発者が主体となって対応し、セキュリティエンジニアがサポートする体制が基本となります。SASTを開発の流れに組み込むと、開発者がコーディングの延長線上で脆弱性を修正できる場面が増え、セキュリティ対策を特別な工程としてではなく、日常的な開発作業の一部として定着させられます。

DAST（動的アプリケーションセキュリティテスト）

DAST（動的アプリケーションセキュリティテスト）は、実際に動いているアプリケーションに対して外部から攻撃をシミュレートし、脆弱性を検出する手法です。コードの記述だけでは発見しにくい、設定の不備や動作の組み合わせによる問題を検出できるため、SASTとは異なる種類の脆弱性をカバーできます。

SASTが「書いたもの」を見るイメージ、つまりプログラムの実行前にソースコードの構造的な欠陥を特定するのに対し、DASTは「動いた結果」を見るイメージ、つまり実行中のアプリケーションに対して外部から疑似攻撃を試行し、動作上の脆弱性を検証します。

セキュリティ診断のセルフサービス化では、SASTやDASTを導入してプロジェクト内で診断を実施できるようにし、ツール選定に加えて診断業務の運用設計、コスト管理、人・物・プロセスの運用定義範囲を整え、最終的に診断を内製化することが目標です。DASTも、回し方まで含めて設計すると、リリース前のセキュリティ確認を現実的な負荷で続けやすくなります。

シフトレフト導入を成功させる手順

シフトレフトは、考え方を知るだけでは定着しません。目的、計画、自動化の土台、効果測定までを順番にそろえると、現場の動きとして回りやすくなります。ここでは、導入を4段階に分けて、何を決め、何を作り、何を見れば良いかを具体化します。

手順1：目的と導入範囲を明確にする

シフトレフトの導入にあたり、最初に行うべきことは「なぜ導入するのか」という目的の明確化です。例えば、リリース直前の修正が多い、セキュリティ確認がボトルネックになっている、品質のばらつきが大きいなど、現状の課題を具体的に言語化し、チーム内で共有します。目的があいまいなままでは、何を前倒しすべきかの判断基準も定まりません。

次に、導入範囲を絞り込みます。いきなり全社規模で変更を進めると、ルールの整備や教育が追いつかず、現場の混乱や反発が起こるでしょう。まずは特定のプロジェクトやチームを対象に小規模に試し、効果が確認できた進め方を段階的に広げるほうが現実的です。

手順2：テスト戦略と計画を具体化する

次に、どの段階で何を確かめるかを具体的に計画します。要件定義や設計段階ではレビューで仕様のあいまいさを解消し、実装段階ではユニットテストで変更の影響をすぐ確認し、結合段階では機能間の連携を検証する、といった各テスト活動の役割分担を明確にします。

実施体制も重要です。開発者、テスター、セキュリティ担当の役割を「後工程に引き渡す」のではなく、各工程に早期から関与し協働する形に設計します。

IPAの「ソフトウェアテスト見積りガイドブック」^※7によれば、上流工程での不具合摘出比率を高めることで製品の信頼性が向上することが示されており、W字モデルの採用によってテスト担当者が設計段階から関与することが、品質の早期安定に大きく寄与すると提言されています。なお、W字モデルとは、V字モデルの各設計・開発工程にテスト設計やレビューを並走させ、テスト担当者を上流工程から関与させる考え方です。

手順3：CI/CDパイプラインを整備する

シフトレフトを継続的に機能させるための土台となるのが、変更のたびに自動で確認が実行される仕組み、すなわちCI/CDパイプラインです。CI/CDは、コードの変更を取り込み、ビルド、テスト、パッケージ、デプロイといった一連の工程を自動化された流れとしてつなぐ仕組みであり、シフトレフト成功の鍵といえます。

NISTは、DevSecOps（開発・セキュリティ・運用の連携）で開発されることが多いアプリでは、CI/CDパイプラインと呼ばれるフローを使い、ビルド、テスト、パッケージ、デプロイなどの段階を経て新しい版を提供すると説明し、CI/CDパイプラインにソフトウェア供給網のセキュリティ対策を組み込む戦略を概説しています^※8。

CI/CDパイプラインの整備により、開発者は迅速なフィードバックを受け取りながら開発を進めることが可能になり、品質とスピードの両立を実現する基盤が構築されます。

手順4：スモールスタートで効果を測定する

シフトレフトを試験的に導入したら、その効果を定量的に確認します。例えば、以下のような指標で導入前後を比較することが有効です。

測定指標	確認する内容
リリース直前の不具合検出数	終盤に発見される不具合が減少しているか
手戻り工数	修正にかかる工数が削減されているか
修正リードタイム	不具合や脆弱性の指摘から修正完了までの所要日数が短縮されているか
リリース後の障害発生率	本番環境で発見される問題の割合が低下しているか

ここで重要なのは、完璧な指標のセットではなく、同じ物差しで前後を比べられる状態です。

効果測定の結果、改善が確認できた進め方や、逆に想定どおりの成果が得られなかった箇所を整理し、全社展開に向けた改善点や課題を洗い出します。ツールの選定だけでなく、診断業務の運用設計、コスト管理、担当者・ツール・プロセスの運用定義範囲を段階的に整備し、最終的に品質・セキュリティの確認体制を組織として内製化していくことが、シフトレフト定着のポイントです。

シフトライトとの違いとは？

シフトレフトが「リリース前に品質と安全を作り込む」考え方だとすると、シフトライトは「リリース後の実際の利用状況から学ぶ」考え方です。どちらか一方だけで完結するものではなく、役割が違います。ここでは、シフトライトが何を重視するのか、そしてシフトレフトとどう組み合わせるのかを整理します。

本番環境でのテストを重視する考え方

シフトライトは、本番環境での監視や実験を通じて、実際の利用者の動きから品質を評価し、改善につなげる発想です。開発中の想定だけでは把握しきれない、現実の利用パターンや負荷状況、運用上の制約を可視化できる点に特徴があります。例えば、特定の操作で応答が遅延する、特定の環境でのみエラーが発生するといった問題は、本番ではじめて顕在化することが少なくありません。

具体的な手法としては、一部のユーザにのみ新機能を段階的に公開するカナリアリリースや、異なるバージョンの効果を比較するA/Bテスト、本番環境の挙動をリアルタイムで追跡する継続的モニタリングなどが挙げられます。

NISTの継続的モニタリングの考え方（SP 800-137）^※9でも、セキュリティ管理策が時間の経過とともに有効であり続けているかを継続的に評価・分析することの重要性が示されており、リリース後の検証を体系的に行う考え方はセキュリティ領域でも確立されています。本番環境からの学びを開発プロセスにフィードバックする仕組みを整えることで、シフトレフトで構築した品質基盤をさらに強化し、ソフトウェアの信頼性を継続的に高めることが可能です。

シフトレフトと相互に補完しあう関係

シフトレフトは、リリース前に不具合や脆弱性を検出・除去し、製品の品質と安全性を高めます。しかし、どれだけ対策を講じても、本番環境でしか判明しない問題は残ります。そこでシフトライトによって運用データやユーザの挙動を分析し、そこから得られた改善点を次の設計や実装へフィードバックすることが必要です。

両者の関係は、以下のように整理できます。

観点	シフトレフト	シフトライト
対象フェーズ	リリース前（上流工程）	リリース後（本番環境）
主な活動	レビュー、テスト自動化、静的解析、脅威モデリング	モニタリング、A/Bテスト、カナリアリリース
目的	不具合・脆弱性の早期検出と除去	実環境でのフィードバック収集と改善
フィードバックの方向	開発中の迅速な修正	運用知見の次サイクルへの反映

シフトレフトとシフトライトは対立する概念ではなく、リリース前の品質向上とリリース後の品質保証を両輪で支える補完関係にあります。

シフトレフトで品質とスピードを両立

シフトレフトは、テストやセキュリティ対策を開発の早い段階へ寄せ、問題を小さいうちに見つけて直すことで、品質とスピードを両立させる考え方です。シフトレフトの導入では、初期の負荷増加やスキルの変化、自動化の整備といった課題も同時に扱わなければなりません。

アジャイル開発への移行やオープンソースライブラリの活用が進む一方で、セキュリティゲートで脆弱性が見つかると手戻りが発生し、生産性低下やリリース遅延が起きる課題があります。まずは目的と範囲を小さく決め、早期確認と自動化を組み合わせ、効果を数字で確認しながら広げると、経営目線でも判断しやすくなります。

参考情報

※1 IPA - セキュリティ・バイ・デザイン導入指南書

※2 デジタル庁 - CI/CDパイプラインにおけるセキュリティの留意点に関する技術レポート

※3 Cost of Poor Software Quality in the U.S.: A 2022 Report - CISQ

※4 IPA - ソフトウェア開発データが語るメッセージ「設計レビュー・要件定義強化のススメ」

※5 Enabling Shift-Left Testing from Small Teams to Large Systems | CMU Software Engineering Institute

※6 SP 800-218, Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities | CSRC

※7 IPA - ソフトウェアテスト見積りガイドブック

※8 SP 800-204D, Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines | CSRC

※9 NIST Special Publication 800-137「Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations」