［開発者向け］AnthropicがAIネイティブな「開発ライフサイクル(SDLC)」を提唱——コードが速くなった先で何を変えるべきか

2026-08-24

はじめに

　Anthropicが2026年8月21日、公式ブログにて「The AI-Native SDLC playbook」と題した長編ガイドを公開しました。本稿では、AIによってコード実装が高速化した現在、計画から運用までのソフトウェア開発ライフサイクル(SDLC)全体をどう作り替えるべきかを整理したこの発表内容を解説します。

参考記事

タイトル: The AI-Native SDLC playbook
著者: Louis Claxton
発行元: Anthropic(Claude公式ブログ)
発行日: 2026年8月21日
URL: https://claude.com/blog/the-ai-native-sdlc-playbook

要点

従来のSDLCは計画・設計・実装・テスト・デプロイ・運用の6段階を人手のリレーで進める前提で設計されており、実装(ビルド)フェーズがボトルネックだった時代の産物である
AIエージェントによって実装速度が上がった結果、ボトルネックは計画・レビュー・デプロイなど人間の速度に依存する前後の工程に移動したとされる
各段階の成果物をintent.md、spec.md、plan.mdなどバージョン管理された文書として引き継ぐことで、人手の会議や承認待ちを減らす設計が提案されている
CLAUDE.mdやスキル、フックといった仕組みを使い、レビューや承認ゲートをコードとして運用する方法が具体例とともに示されている
本番環境の異常検知からインシデント対応、修正提案までを人の介在なく回し、最終的な承認のみ人間が行う「ループを閉じる」運用パターンが紹介されている

詳細解説

なぜ実装フェーズだけを速くしても意味がないのか

　Anthropicによれば、多くの組織はAIによってコードを書く速度を劇的に上げている一方で、その周辺にある承認プロセスやレビュー体制は従来のままだといいます。ソフトウェア開発ライフサイクル(SDLC)は、計画・設計・実装・テスト・デプロイ・運用という6段階からなり、伝統的にはそれぞれ別の役割が担当し、書類やチケットを介して引き継がれてきました。

　この体制は、実装がもっとも時間とコストのかかる工程だった時代に、各段階で足並みを揃えるために設計されたものだと説明されています。実装だけが速くなると、計画・レビュー・デプロイといった人間の速度で動く工程に負荷が集中し、従来のレビュー体制が現実に追いつかなくなる、というのが記事の中心的な問題提起です。たとえばセキュリティ審査は人手の処理量を前提に人員が配置されているため、エージェントがコード量を増やすと、審査待ちの行列が伸びるか、審査が不十分なままリリースされるかのどちらかに傾きやすいと指摘されています。

計画・設計フェーズ:意図を文書として引き継ぐ

　記事では、企画段階のアイデアを「intent.md」というバージョン管理されたMarkdownファイルとして記録することが提案されています。担当者がClaudeと対話しながら課題・対象ユーザー・制約条件を整理し、その内容をそのまま次の設計工程に引き渡す発想です。これにより、要求定義がバックログや会議を何度も経由するうちに内容が薄まっていくという、従来型の課題を避けられるとしています。

　設計工程でも同様に、承認されたintent.mdをもとにAIが要件と設計を一体化した「spec.md」を作成し、担当者はそれを確認・修正する役割に回るという流れが示されています。ブランドやセキュリティ、UXに関する社内ルールを「スキル」として組み込み、設計段階からポリシーを反映させる点が特徴的です。ここでいうスキルとは、特定の業務知識や手順を再利用可能な形でAIに与える仕組みを指し、Cursor・Claude Code・Codexが3層構造のAIコーディングスタックを形成しているという分析でも触れられているような、AIコーディングツール群に共通する拡張の仕組みと位置づけられます。

実装フェーズ:計画モードとフック、並列セッション

　実装工程では、Claude Codeの「プランモード」をエンジニアの標準的な出発点とすることが提案されています。プランモードでは、AIがコードベースを読み込みながら変更方針を対話的に詰め、承認された計画のみが「plan.md」として記録されます。計画が承認された後にAIが実装まで担う「自動モード」も紹介されており、テストや型チェックといった仕組みが整うほど、この自動モードが日常的な作業のデフォルトになっていくとされています。

　組織固有の知識を蓄積する仕組みとしては「CLAUDE.md」というファイルが挙げられています。ビルド・テスト・リントのコマンドや設計方針、AIが繰り返しやすいミスなどを記録し、セッション開始時にAIが読み込む形です。加えて、恒常的に守るべきルールは「スキル」として明文化し、実際にファイル操作やコマンド実行を止める・確認を求める仕組みは「フック」という決定的な制御として別に用意する、という役割分担も説明されています。スキルはあくまで推奨に近い制御であり、確実に強制したいルールにはフックを組み合わせる必要があるという整理は、実務上参考になる考え方だと思います。

　また、1人のエンジニアが複数の作業ツリー(worktree)で並行してAIセッションを走らせる運用や、決まった検証作業を担う「サブエージェント」を用意する運用も紹介されています。セッション数が増えるほどレビューが追いつかなくなる懸念があるため、レビューの質が保てる範囲でセッション数を調整することが前提とされている点は、実務導入を検討する際に押さえておきたいポイントだと考えられます。

テスト・デプロイフェーズ:レビューと承認をコード化する

　テスト工程では、AIの設定やスキルが変わるたびに一定のタスク集合で品質を検証する「継続的な評価(eval)」の仕組みが説明されています。本番で起きたインシデントを新たな評価項目として追加していくことで、同種の不具合を継続的に検出できるようにする発想です。

　デプロイ工程では、AIがプルリクエストのレビューを行い、指摘に応じて自ら修正を加える「レビューループ」と、人間の承認が必要な操作を「フック」で明示的に止める「承認ゲート」の2つが軸になっています。特に、本番環境への反映など後戻りしにくい操作については、AIが提案までを担い、最終承認は必ず人間が行うという線引きが一貫して強調されています。この点は、エージェントが議論よりパッチのコストを下げつつあるという別の視点とも重なる部分であり、「どこまでAIに任せ、どこから人が判断するか」という線引きが、今後のチーム運営における実務的な論点になっていくと考えられます。

運用フェーズ:異常検知からインシデント対応までのループ

　運用段階では、CI失敗率やデプロイ後のエラー率といった指標を常時監視し、あらかじめ定めた閾値を超えた場合にAIが自動的に診断や対応案の作成に乗り出す仕組みが示されています。軽度な逸脱ではログに残すだけ、深刻な逸脱ではプルリクエストの作成や既存のロールバック手順の実行まで許可するなど、逸脱の度合いに応じて権限を段階的に広げる設計です。ここで見つかった問題は再びintent.mdとして計画工程に戻り、一連の工程がループとして回り続ける構成になっています。

　この一連の流れをまとめると、各段階が生成する成果物(intent.md、spec.md、plan.md、差分とそのテスト、レビュー内容、インシデント記録)をバージョン管理システムに残すこと自体が、誰が何を求め、AIが何を作り、誰が承認したかを追える監査証跡になるという考え方が、記事全体を貫く軸になっています。

まとめ

　本稿では、Anthropicが公開した「AIネイティブなSDLC」の考え方を、計画から運用までの6段階に沿って紹介しました。実装の高速化に合わせ、レビューや承認の仕組み自体をコード化していく発想は、AI導入を検討する組織にとって参考になる視点だと思います。エージェントとスコープ判断の関係は、過去記事でも整理していますので、あわせてご覧ください。