8月21日、Anthropicが「The AI-Native SDLC playbook」と題した記事を公開した。コードを書く工程はもはやボトルネックではない——この逆説的な事実から出発し、SDLC（ソフトウェア開発ライフサイクル）の全フェーズをAI前提で再設計するための実践的なプレイブックを公開している。GitHub CopilotをはじめとするAIコーディングツールが普及し、「実装フェーズを高速化する」だけでは不十分だという認識がエンジニアリング組織に広がるなか、Anthropicはより根本的な問い——開発プロセスの構造そのものをどう変えるか——に答えようとしている。
コードはもはやボトルネックではない
AIによるコード生成が劇的に速くなった今、皮肉なことにボトルネックはコードを書く工程ではなくなった。Anthropicはこの構造的な問題を正面から指摘する。
従来のSDLCは「コードを書くことが最も時間とコストのかかる工程」という前提で設計されていた。PRD（製品要求仕様書）、見積もり会議、セキュリティレビューといったプロセスは、数週間〜数ヶ月に及ぶ開発期間中の合意形成を強制するために存在していた。
ところがClaude Codeのようなエージェント型コーディングツールが登場し、実装フェーズが「数時間」に圧縮されると、周囲の工程がそのまま取り残される。
Build is no longer the constraint — the human-speed steps around it are. Human-speed stages keep their length while build collapses to hours.
記事中の図が示すのは、Buildフェーズだけが劇的に短縮される一方、Plan・Review・Deployは従来と同じ「人間のスピード」で動き続けるという構図だ。
セキュリティを例に取ると明快だ。セキュリティチームの規模は人間の生産量を前提に設計されている。エージェントがコード出力を何倍にも増やせば、レビューキューが積み上がるか、レビュー不足のままコードが出荷されるかのどちらかになる。規制産業ではどちらも受け入れられない。
AI-Native SDLCとは何か
Anthropicが提唱するAI-Native SDLCは、従来の「線形フロー」をループ構造に置き換え、AIを各フェーズに組み込んだプロセスだ。各フェーズの終わりにコミット可能なアーティファクト（intent.md、spec.md、plan.mdなど）をバージョン管理に書き込み、次のフェーズはそれを読み込むことで開始する。このアーティファクトの連鎖がそのまま監査証跡になる設計だ。
従来と新しいアプローチの対比は以下の通りだ：
| フェーズ | 従来のSDLC | AI-Native SDLC |
|---|---|---|
| Plan | 委員会によるワークショップと承認で要件定義 | ClaudeがJiraチケット・Slackスレッド・メールといった既存ソースから課題を合成し intent.md として出力 |
| Design | アナリストがスペックを記述 | エージェントとの1セッションで要件とデザインを同時完成 |
| Build | コードとテストを手書き | AIがコードとテストを生成、CLAUDE.md で知識を管理 |
| Test | フェーズ境界でのQAゲート | 実装を通じた継続的な評価 |
| Deploy | 全コードを人間がレビュー | エージェントによる多層レビュー、規制コードのみ人間が確認 |
| Maintain | 人間が本番環境を監視 | エージェントが監視し、異常を新たな intent.md として書き戻す |
最も面白いPlay：intent.md から始まるループ
このプレイブックで特に注目したいのがStage 1（Plan）の intent.md だ。
従来、誰かがアイデアを持っても、バックログ登録→ユーザーストーリー作成→ストーリーポイント見積もり→リファインメント会議というプロセスを経て、ようやくエンジニアが動ける状態になる。この間、アイデアの原意は何度もの「伝言ゲーム」を経て薄れていく。
AI-Native SDLCでは、アイデアの発案者（エンジニアでなくていい）がClaudeと会話し、その場で intent.md を生成してバージョン管理にコミットする。
# Intent: claims status self-service
Author: J. Ortiz (claims operations). Status: draft.
## Problem
Customers phone the contact center to ask where their claim is.
Handlers spend roughly a third of call time on status-only queries.
## Proposed outcome
Customers see claim status, next step and expected date in the portal.
## Affected users and systems
Claims handlers, portal team, claims-core API.
## Constraints
No new PII in the portal session. Existing authentication only.
## Open questions
Do third-party loss adjusters need access too?
このファイルは「人間が読める」かつ「エージェントが処理できる」形式になっている点がポイントだ。プロダクトオーナーが承認してマージすれば、それが次のフェーズ（Design）のトリガーになる。「マルチウィークの要件定義サイクルを数時間に」 というのが、Anthropicが設定している目標値だ。
ループの末端では、本番環境でエージェントが検知した異常が自動的に新たな intent.md として書き戻され、次のサイクルが始まる。人間の介入は「ゲート」に集中し、白紙から始めるのではなくエージェントがフラグを立てたものをレビューする形になる。
このプレイブックの使い方
各Playはモジュール式で、全フェーズを一度に変える必要はない。記事では「clay playから始めよ」と推奨している。clay playとは依存関係を持たないPlay——依存グラフ上で他のPlayを前提としないため、既存プロセスへの影響を最小化しながら単独で試せるPlay——を指す。チームは最もリスクの低い箇所から導入を始め、効果を確かめながら段階的に広げていける。
アーティファクトの連鎖は以下のようになる：
- 承認された
intent.md→ DesignフェーズのトリガーAになる - 承認された
spec.md→ Plan modeのトリガーになる - マージされたPR → パイプラインのトリガーになる
- 本番での制御帯域違反 → 次の
intent.mdとして書き戻される
ガバナンスの観点では、承認・却下の判断がすべてgitの履歴に記録されるため、「誰が何を依頼し、エージェントが何を生成し、誰が承認したか」が自動的に監査証跡となる。金融・医療・公共といった規制産業でのAI活用において、このトレーサビリティは特に重要な要件となる。
なお、AI時代のソフトウェア開発プロセス再設計という文脈は、Anthropicに限らず業界全体のテーマになりつつある。DORA（DevOps Research and Assessment）が継続的に調査するデリバリーパフォーマンスの指標や、OpenAI DevDayでの開発者向け発表など、エージェント時代のエンジニアリング組織設計に関する議論は急速に活発化している。本プレイブックはその中でも、フェーズ間のアーティファクト連鎖とガバナンスの両立という点で、具体性の高い提案となっている。
詳細はThe AI-Native SDLC playbookを参照していただきたい。
