シフトレフトとは、ソフトウェア開発ライフサイクルのより早い段階で品質と明確さを確保する実践である。Shift Left & Right：AI 統合はいかにコーディングを超えて広がるか によれば、この用語は 2001 年に Larry Smith が、当時よく見られた問題への対応として作り出した。テストがサイクルの最後に行われていたため、手戻りのコストが高く品質も低くなっており、早い段階でテストすることで高くつく反復を避けられたのである。同記事は、テスト駆動開発、テストピラミッド、そして最終的には CI/CD を、この考え方から発展した実践であり、本質的にはシフトレフトの動きであると数えている。
用法
この用語は DevOps とテストの世界に由来する。codecentric の記事はこれを AI 支援開発に適用し、そこでは仕様が決定的なレバーになると論じている。AI コーディングループが明確で一貫した完全な仕様を入力として受け取れば、生成・確認・破棄のサイクルの回数は減る。一方、穴のある仕様では、ループは複数のバリエーションを生成し、その大半が捨てられることになる。記事がこの段階で挙げる AI 支援の種類は、要件の一貫性を確認し、矛盾を見つけ、テストケースを提案する LLM による仕様レビュー、新しい要件を既存の要件と照らし合わせる自動的な一貫性チェック、そして各機能に合わせて AI が提案する、テスト可能な受け入れ基準である。記事はさらに、仕様の策定により多くの人が関わるようになると付け加えている。技術的な実現可能性が最初から仕様に入るようにエンジニアが、ユーザー体験に関する判断が仕様のレベルで下されるようにデザイナーが、そしてコーディングエージェントのために、適切なコンテキストを伴って十分に正確に要件を定義しなければならないプロダクトマネージャーが関わる。
デプロイ後に適用される対になる概念は シフトライト である。
適用される場面
codecentric の記事は、この実践の AI 時代版を、加速したコード生成への対応として提示している。取り組むべきことを示すシグナルとして記事が挙げるのは、コーディングループの加速はすでに実現しているのに、ビジネス側が目に見える付加価値を感じていない状況であり、たとえばプロダクトオーナーや要求エンジニアがもはやペースについていけない場合である。この実践は、仕様を次のコーディングサイクルに入る前に磨き上げ、継続的に洗練していくことを前提としており、すべてを事前に仕様化することを前提とはしていない — 記事は、そう捉えるのは誤読であり、この実践をウォーターフォールのように聞こえさせてしまうと述べている。記事が AI 支援版について示す根拠は、記事が報告する実務経験であり、その中には LLM を用いた仕様レビューによって機能あたりのコーディングループの反復回数が半減したと報告された、匿名化された顧客プロジェクトが 1 件含まれている。記事は、ドイツにおけるこの実践の成熟度を、まだ芽生えたばかりの段階と評価している。