9月3日、DevOps.comが「From the Horse's Mouth: Anthropic Says AI Has Changed the SDLC」と題した記事を公開した。この記事では、AnthropicがAIエージェント時代におけるSDLC（ソフトウェア開発ライフサイクル）の変化と、それに対応するための「AI-Native SDLCプレイブック」について詳しく解説されている。
ボトルネックはコーディングではなくなった
Anthropicが公開した「The AI-Native SDLC Playbook」は、AnthropicのApplied AIチームでエンジニアリング実践の普及を担うLouis Claxtonが執筆し、同チームと顧客企業の実践をもとにまとめた文書だ。その中心的な主張はシンプルだ。コードはもはや開発のボトルネックではない。
AIコーディングエージェントは、リポジトリを探索し、実装計画を立て、複数ファイルを修正し、テストを生成し、プルリクエストを作成するまでを従来の何分の一かの時間でこなす。しかし組織全体が同じ速度で動けるわけではない。
コードレビューのキューは積み上がり、セキュリティチームは捌ききれない量のコードを受け取り、テスト基盤は過負荷になり、変更承認フローが大量の完了済み作業を滞留させる。コードの生産量が増えても、信頼できるソフトウェアの出荷量が増えるとは限らない。
この見立てはDORAの2025年調査とも一致する。DORA（DevOps Research and Assessment）はGoogleが主導するDevOps実践の大規模研究プログラムであり、毎年の調査レポートは業界の基準指標として広く参照されている。2025年版では、AI導入が生産性と出荷スループットを改善する一方で、ソフトウェア配信の安定性と負の相関を持つ可能性があると指摘している。AIは増幅器であり、強固な基盤を持つ組織はその恩恵を受け、脆弱な基盤を持つ組織は既存の機能不全を増幅させる。
AI-Native SDLCの構造
Anthropicが提案するのは、従来の6段階（Plan → Design → Build → Test → Deploy → Maintain）の線形プロセスを、人間とエージェントの間で成果物が流れ続ける継続的なループに変えることだ。
各段階が次の段階への入力となる成果物を生成する：
Intent → Specification → Plan → Code & Tests → Review & Deployment Evidence → Incident Record → New Intent
各ステージの要点は以下の通りだ。
Plan：意図をソースで捕捉する
プロセスはintent.mdファイルから始まる。ビジネスユーザーやプロダクトオーナーが自然言語でClaudeに問題を説明し、Claudeが達成目標・対象ユーザー・制約・未解決の問いを整理する。人間がこれをレビューして承認したうえで開発プロセスに入る。複数の組織的ハンドオフを経て意図が歪んでいくリスクを、発生源で押さえる発想だ。
Design：ガバナンスを設計段階に前倒しする
承認された意図は要件・設計仕様に変換される。セキュリティ、コンプライアンス、アーキテクチャに関するポリシーをエージェントへの命令として事前に組み込み、設計段階で自動適用する。「レビュー時に初めてセキュリティ要件の見落としが発覚する」という状況を防ぐ。
Build：コード生成の前にプランを承認する
エージェントが実装計画（変更ファイル、実装順序、リスク、必要なテスト）を作成し、エンジニアが承認してから初めてコード生成が始まる。コード生成コストが劇的に下がった今、計画を修正するコストはさらに相対的に低い。
リポジトリにはCLAUDE.mdファイル（プロジェクト固有の指示ファイルで、ビルドコマンドやアーキテクチャ規約などをエージェントが参照できる形式で記述する）を置き、繰り返し発生する修正指示もここに集約する。かつてWikiや熟練エンジニアの頭の中にあった知識を、機械可読な組織知として提供する仕組みだ。
Test：自信ではなく証拠を要求する
バグ修正では、エージェントはまず失敗を再現するテストを作成する。修正前にそのテストが期待通りの理由で失敗することを確認してから実装に入る。エージェントがグリーンにするためにテストを弱めたり削除したりすることは許容しない。「強力なモデルが生成したコードだから」という理由だけで信頼するな、証拠を要求せよ、という原則だ。
Deploy：ガバナンスを実行環境に組み込む
自動フックがアクションを許可・ブロック・保留する。ルーティンな低リスク変更は素通しし、本番デプロイやインフラ変更は名前を指定した担当者の承認を必須とする。ガバナンスがポリシー文書や後付けの委員会から、実行環境そのものに移動する。
Maintain：本番をフィードバックループに組み込む
エージェントが本番を監視し、アラートを調査し、インシデント対応を補助する。本番で問題が発生すれば、その診断が新たなintent.mdとして計画プロセスに戻る。線形プロセスの末端だったメンテナンスが、開発サイクル全体のフィードバック源になる。
現実との距離
DevOps.comの調査データは、現状とAnthropicのビジョンの乖離を示している。
- コード生成にAIを活用：40.17%
- コードレビューに活用：37.66%
- テストに活用：28.01%
- CI/CDに活用：13.23%
- セキュリティスキャンに活用：12.40%
- デプロイ判断に活用：6.20%
- エンドツーエンドの自律的開発：5.84%
本番に近づくほど採用率が急落する。また42.43%がガバナンスの不備をAI導入の障壁と挙げ、75.2%が過去12ヶ月に少なくとも1件のソフトウェアインシデントを経験している。AIをコード生成には使い始めているが、それを安全に届けて運用するシステムにはまだ統合できていない状態だ。
AIはDevOpsを不要にしない
このプレイブックが提示することの多くは、DevOpsが長年説いてきたことと重なる。ハンドオフの削減、テストとセキュリティの前倒し、変更の追跡可能性、本番からの継続的な学習。AIはDevOpsを無効化するのではなく、未完のDevOps変革を完成させる圧力を高める。
プレイブックはClaudeの機能（Claude Code、CLAUDE.md、Claude Skills（Claudeにカスタムツールや外部サービス連携を組み込むための拡張機能）など）を前提に書かれているが、アーキテクチャの考え方自体はClaudeに限定されない。別のエージェントが仕様を作成し、別のエージェントがコードを生成し、さらに別のエージェントがレビューするという構成も成立する。生成と審査に独立して開発されたエージェントを使い分けることで、モデルが自分の出力を採点するリスクも低減できる。
また誰がAI-Native SDLCを制御するのか、という問いにはこのプレイブックだけでは答えが出ない。モデルプロバイダーか、既存のDevOpsプラットフォームか、社内のプラットフォームエンジニアリングチームか。その答えは業界がこれから決めていくことになる。
詳細はFrom the Horse's Mouth: Anthropic Says AI Has Changed the SDLCを参照していただきたい。
