シフトレフト

シフトレフトとは

シフトレフト (Shift Left) は、テスト、セキュリティ、品質チェックを開発プロセスの早い段階 (左側) に移動させるアプローチである。左側というのは、工程を左から右へ並べた図の上での位置を指す。Larry Smith が Dr. Dobb's Journal 誌 26 巻 9 号 (2001 年) に寄せた記事「Shift-left testing」で使われた語である。

前倒しが効くのは、問題が見つかる時点が遅いほど、直すために必要な作業が増えるためである。増えるのは直す手間そのものではなく、その問題を前提にして積み上げたものを解きほぐす手間である。

従来の並べ方との違い

違いは、検証をどこにまとめるかである。

従来 (検証を後段にまとめる):
  設計 → 実装 → テスト → セキュリティ診断 → デプロイ
                  ↑ 設計に起因する問題もここで初めて見える

シフトレフト (各段階に検証を埋め込む):
  設計     → 実装             → 結合               → デプロイ
  脅威の洗い出し  型チェック・単体テスト  結合テスト・依存の検査   段階的公開・監視

前倒しといっても、テスト工程の日程を前へずらすわけではない。各段階で「ここまでは正しいと言えるか」を答えられる状態にし、答えられない部分だけを次へ渡す形に変える。設計時に脅威を洗い出しておけば、実装が終わってから設計をやり直す事態を避けられる。

後になるほど直しにくくなる理由

見つかる時点が遅いほど費用がかかると言われる根拠は、時間の経過そのものではなく、その間に積み上がったものの量である。

発見の時点	直すときに追加で必要になる作業
設計時	図と文書の書き直し
実装時	書いたコードの手直しと、その前提で書いた周辺コードの見直し
テスト時	原因の切り分け、修正、テストのやり直し、修正した版の作り直し
本番リリース後	影響を受けた利用者とデータの特定、切り戻しか緊急修正かの判断、告知、再発防止の説明

工程が進むごとに費用が何倍になるという数字がしばしば引かれるが、倍率は対象の規模・体制・切り戻しの容易さで大きく変わる。桁を覚えるよりも、自分たちの工程で上の表のどこから作業が増え始めるかを見るほうが判断に使える。切り戻しが数分で済む仕組みを持っているかどうかで、最下段の重さは大きく変わる。

シフトレフトの実践

前へ移すのは工程ではなく判断である。同じ確認を誰がいつ行うかが変わる。

領域	従来	シフトレフト
テスト	QA チームが手動テスト	開発者が自動テストを書く
セキュリティ	リリース前にペネトレーションテスト	コミット時に SAST/DAST
コード品質	コードレビューで指摘	ESLint + Prettier で自動修正
インフラ	手動構築後に検証	IaC + テスト

具体的なツールチェーン

実体は、確認を人の記憶や心がけから、通らなければ進めない仕掛けへ移すことである。Web アプリでよく使われる並べ方を例に挙げる。

コーディング時:
  TypeScript (型チェック) + ESLint (静的解析) + Prettier (フォーマット)
  ↓
コミット時:
  Husky + lint-staged (Git フック)
  ↓
プッシュ時:
  GitHub Actions (CI: テスト + ビルド + セキュリティスキャン)
  ↓
マージ時:
  コードレビュー + 自動テスト通過必須
  ↓
デプロイ時:
  自動デプロイ + スモークテスト

セキュリティのシフトレフト (DevSecOps)

セキュリティの前倒しは DevSecOps と呼ばれる。要点は、運用側の対策を開発工程へ持ち込むことではなく、開発中に判断できる検査を開発中に済ませ、本番でしか判断できないものだけを後段へ残す切り分けである。

チェック	ツール	タイミング
依存パッケージの脆弱性	Dependabot, Snyk	PR 作成時
シークレットの検出	git-secrets, TruffleHog	コミット時
SAST (静的解析)	CodeQL, Semgrep	CI
コンテナイメージスキャン	ECR スキャン, Trivy	ビルド時
IAM ポリシーの検証	IAM Access Analyzer	デプロイ前

シフトレフトの限界

シフトレフトは万能ではない。実際の負荷や利用者の使い方に依存する問題 (性能の劣化、想定を超える同時アクセス、外部サービスとの相性、実データ特有の形) は、本番に近い環境でしか現れない。そのため、本番の監視や段階的な公開で早く気づいて素早く戻す方向 (シフトライト) と組み合わせる。前倒しは本番で初めて分かることを減らす取り組みであり、ゼロにする取り組みではない。

つまずきやすい点

• 前倒ししただけでは作業の総量は減らない。確認の場を早い段階へ移せば、その段階に必要な時間は増える。減るのは後段でのやり直しである。増えた分を引き受ける余裕が無いまま導入すると、検査を飛ばす抜け道が定着して数字の上だけ整う。
• 誤検知を放置すると仕掛けそのものが無視される。静的解析やスキャンの警告に、対処されないものが混ざり続けると、開発者は警告全体を読み飛ばすようになる。検査を増やす前に、出た警告を必ず処理できる水準まで対象を絞る。
• 確認を早い段階へ足すほど 1 回の往復が遅くなる。すべてをコミット時に走らせると手が止まるため、コミット時・変更提案時・統合時のどこで何を見るかを分けて配置する (CI/CD)。
• 開発者に検証を寄せることは、検証の専門性が不要になることではない。どの層で何をどこまで確かめるかの設計は別の判断であり、テストの配分を決める作業は残る (テスト戦略)。