AI-Native SDLCとは──Anthropicが「コードの80%をClaudeが書く」現場から逆算した開発フロー

「コードを書く速度」がボトルネックでなくなったら、ソフトウェア開発の工程はどう組み替わるのか。Anthropicが2026年7月21日と8月21日に相次いで公開した2本の公式ブログは、この問いに対する自社の実践を具体的な数字とともに公開している。

Anthropicのエンジニアは今日、マージされるコードの約80%をClaudeに書かせており、四半期あたりの出荷量は2021〜2025年平均の8倍に達したという。この前提から逆算して同社が定義した開発フローが「AI-Native SDLC」で、要件定義から運用までを6ステージ（Plan / Design / Build / Test / Deploy / Maintain）に分け、各ステージの完了をintent.md・spec.md・plan.mdという版管理対象ドキュメントのコミットで区切り、次のステージの起動条件にしている。

前提となる数字

7月21日付けのセキュリティブログ（著者：Anthropic副CISOのJason Clinton氏）は、次のように書いている。

"Our software engineers on average ship 8x as much code per quarter as they did from 2021 to 2025." "Claude authors about 80% of the code merged into our codebase today."

Anthropicのエンジニアは、2021〜2025年平均と比べて四半期あたり平均8倍のコードを出荷しており、今日マージされるコードの約80%はClaudeが書いているという。さらに「マージされる全コードの半分以上は、社内版のClaude Tagによってマージされている。人間のエンジニアは、方向づけ・意図の設定・最終責任の保持に集中している」ともある。

この数字が前提としてあるからこそ、8月21日付けの「The AI-Native SDLC playbook」は、「レビュー待ちの列が伸びるか、コードが十分レビューされないまま出荷されるかのどちらかになる」という危機感から出発する。規制業界の企業はどちらの結果も受け入れられないため、セキュリティとポリシーのチェックもエージェントのペースに合わせる必要がある、という論旨だ。

何が変わるのか：直線的な工程から「ループ」へ

Playbookが描く変化の核心は、開発工程が直線（要件定義→設計→実装→QA→リリース→運用）から、ループへと変わるという点だ。原文はこう説明する。

ある工程が終わるとき、次の工程を起動する成果物（artifact）がコミットされる。承認された intent.md が要件定義・設計パスを起動し、承認された spec.md がプランモードを起動し、マージされたPRがパイプラインを起動し、本番環境で管理帯域（control band）を逸脱した状態が次の intent.md を書く。こうしてループが続く。

つまり、各工程の完了を「ドキュメントのコミット」という明示的なイベントとして扱い、それが次の工程の起点になる設計だ。人間の注意力は、各ゲート（関門）に集中する──エージェントがゼロから始めるのではなく、エージェントが検知・提起した内容をレビューする形に変わる、としている。

6つのステージと「Plays」

Playbookは開発サイクルを非線形な6ステージ（Plan / Design / Build / Test / Deploy / Maintain）に分け、それぞれに具体的な実践項目（Plays）を割り当てている。各Playには「何が変わるか」「始め方」「実装の具体的な手順」「ガバナンス上の考慮点」「効果測定の方法」が記載されている。原文を全文確認した範囲で、6ステージの成果物と主なPlayを整理すると次のようになる。

Stage 1: Plan（計画）

Playbookが示す最初の変化は、アイデアの扱い方だ。従来型では、アイデアはバックログのエントリ・ユーザーストーリー・ストーリーポイント・リファインメントミーティングを経て、誰かが着手できる状態になるまでに何段階もの引き継ぎを経る。AI-nativeなアプローチでは、アイデアを思いついた本人がClaudeとブレインストーミングし、その結果を intent.md（意図を記した版管理対象のドキュメント）として書き出す。原文いわく、「アイデアの発案者自身の言葉で書かれた、次の工程がすぐに扱えるプロトスペック」になる。プロダクトオーナーは、これがコミットされる前にレビューし修正する。

Stage 2: Design（設計）

intent.mdが承認されると、Claudeはそれを受けて要件・設計仕様（spec.md）を起草する。この際、組織が定義したブランド・セキュリティ・コンプライアンス・UXに関するSkillsを参照させる。プロダクトオーナーはこの仕様書をレビューするが、自分で書くわけではない。フロントエンド作業では、intent.md承認後にプロダクトオーナーがベータ版の「Claude Design」でモックアップを作り、それをClaude Codeにエクスポートして実装させるという流れが具体例として挙げられている。実行手順としては、まずプロダクトオーナーが手動でこのプロセスを回し、その後スラッシュコマンド化、さらにintent.mdのマージをトリガーとする非対話ジョブへと段階的に自動化していく想定だ。spec.mdはintent.mdと並べてコミットされ、この2つのファイルが「何を求められ、何が決定されたか」の記録になる。

Stage 3: Build（実装）

エンジニアはClaude Codeを「プランモード」で起動し、承認済みのspec.mdを渡して実装計画を作らせる。Claudeに「何を変更するファイルか」「作業の順序」「変更を証明するテスト」を含む計画を書かせ、エンジニアは「この変更が何を壊しうるか」「最もリスクが高いステップはどれか」「Claudeが選ばなかった他の選択肢は何か」を尋ねながら計画を練り直す。承認された計画はplan.mdとしてコミットされ、これも監査証跡の一部になる。プランモードでは、エンジニアが計画を承認するまでClaudeはファイルを編集できない仕様になっている（Claude Code公式ドキュメント「Common workflows」でも、プランモードは--permission-mode planで有効化でき、承認されるまで編集が発生しないと説明されている）。

計画が固まったあとは「オートモード」に進み、Claudeが逐一の確認なしに変更を適用できるようにする。ガードレール（チューニングされたCLAUDE.md、ポリシーを組み込んだSkills、危険な操作をブロックするHooks、Claudeが実行できるテストスイート）が整うほど、定型作業ではオートアクセプトがデフォルトになっていく、としている。

レガシーシステムでは、CLAUDE.mdが「新しく参加したメンバーが必要とする情報」（ビルド・テスト・lintコマンド、守るべき規約、Claudeが繰り返し間違えるポイント）を集約する場所になる。Playbookが示す運用ルールは明快で、「Claudeが同じ間違いを2回したら、その修正はCLAUDE.mdに書く」というものだ。CLAUDE.mdは1ページ以内に収めることが推奨されている（セッション開始のたびに全文読み込まれるため）。

組織固有の知識を運用可能にする仕組みとしては、SKILL.mdファイルによる「Skills」がある。一貫して適用すべきポリシー（セキュリティ標準、API設計規約、ブランドルールなど）をSkillとして書き、.claude/skills/<name>/配下に置くかプラグインとして組織全体に配布する。ただしPlaybookは、Skillはあくまで「advisory（助言的）」なコントロールであり、絶対に守らせたいポリシーには、危険な操作をブロックする「Hooks」を背後に置く必要がある、と明記している（Claude Code公式ドキュメント「Hooks reference」でも、Hookの終了コード2は他の出力に優らず必ず操作をブロックする、という仕様が確認できる）。

並列作業については、1人のエンジニアが複数のClaude Codeセッションを同時に走らせる「並列セッション」（それぞれ独立したgit worktree上で動作）と、1つのセッション内でスコープを絞った補助タスクを担う「サブエージェント」（.claude/agents/配下にmarkdownで定義）を区別している。Claude Code公式ドキュメント「Subagents」でも、サブエージェントは専用のコンテキストウィンドウと限定されたツールセットを持つと説明されており、Playbookの記述と整合する。

Stage 4: Test（検証）

Playbookが強調するのは「Claude自身に検証手段を与える」ことだ。テスト・ビルド・スクリーンショット差分など、セッションが自分の作業を自分で確認し、エンジニアの目に触れる前に間違いを直せる仕組みを指す。バグ修正では、まず失敗するテストを書かせてバグを再現させ、そのテストをコミットしたうえで、テストファイルを変更せずにテストを通させる（Hookでテストファイルへの変更をブロックすることもできる、としている）。

さらに、CIで継続的に走らせる「eval」の仕組みも定義している。プラットフォームエンジニアが直近の実タスクから20〜50件を集めてevalとして書き起こし、CLAUDE.md・Skills・Hooksが変更されるたびにCI上で非対話的に実行する。設定変更でeval合格率が下がれば、マージ前にレビューされる。本番インシデントが起きるたびに、そのインシデント用のevalを追加し、回帰テストとしてスイートに残す運用も示されている。

Stage 5: Deploy（デプロイ）

ClaudeはPRレビューを「する側」にも「される側」にもなる。テックリードがレビュー方針をREVIEW.mdとしてリポジトリ直下に書き、「バグと論理エラー」「セキュリティと脆弱性」「spec.md・plan.md・設計原則との整合性」という3つのパスをClaudeに走らせる。REVIEW.mdは「Important」と「Nit（些末な指摘）」の線引きも定義し、Nitは1レビューあたり最大5件までに制限するといった運用例も示されている。ClaudeのレビューはPRを単独で承認・ブロックする権限を持たず、ブランチ保護によるコードオーナーの承認が別途必要、という分離が明記されている。

Hooksは、Stage 3で見た「危険な操作をブロックする」用途に加えて、「特定の人物の承認があるまで操作を保留する」用途にも使われる。原文が示す設定例では、.claude/settings.jsonのPreToolUseフックが本番デプロイを検知し、環境変数RELEASE_APPROVALが未設定であれば終了コード2で操作をブロックする、というシェルスクリプトが掲載されている。チーム単位のHookはgit管理下の.claude/settings.jsonに、組織として無効化させたくないHookは管理者権限の管理設定に置く、という運用の使い分けも書かれている。

CI/CD統合については、Claude CodeをCI/CDパイプライン内で非対話的に（claude -pで）実行し、失敗したビルドのトリアージや変更ログのドラフト作成といった読み取り専用の判断作業から始め、書き込みを伴う作業（lint修正、生成ドキュメントの更新、レビューコメントへの対応）は既存のゲートの背後に追加していく、という段階的な導入順序が示されている。エージェントのジョブはコンテナでサンドボックス化され、短命のスコープ付きトークンで動き、デフォルトでは本番の認証情報を持たない。デプロイ・ステータス確認・ロールバックはMCP経由のツールとして公開し、環境ごとにスコープを絞る。開発環境ではエージェントが自由にデプロイできる一方、本番環境ではエージェントがリリースを準備しリリースマネージャーが承認する、という環境ごとの自律性の階層化（development／staging／production）も定義されている。

Stage 6: Maintain（運用・保守）

最終ステージでは、それまでの「人間がまず着手する」形から、Claudeが自律的にループを閉じる形へと焦点が移る。決定論的なスクリプトが本番環境を監視し、「管理帯域（control band）」の逸脱を検知するとClaudeを呼び出す、という仕組みが具体例として示されている。CIテスト失敗率や本番の5xxエラー率といった、安定したベースラインを持つ指標を1つ選び、移動平均と標準偏差（Western Electricルールなど）で監視する。原文が示すbands.yamlの例では、1σで「ログ記録のみ」、2σで「Claudeを読み取り専用で呼び出して診断」、3σで「ClaudeがPRを開くか、事前承認済みのrunbookを起動する」という3段階のティアが設定されている。検知そのものは決定論的（モデルを介さない）に保ち、帯域を逸脱した時点で初めてClaudeが呼ばれる、という設計だ。

定期的なコードベーススキャンについては、「Claude Security」というホスト型のスキャン機能が紹介されている。GitHubリポジトリを接続すると、Anthropicのインフラ上でモデル（原文表記は"Claude Mythos 5"）を使ってスキャンが走り、各所見は報告前に検証され、信頼度スコアが付与される。修正パッチはClaude Code on the Webでレビュー・適用できる。運用では、まず最重要リポジトリの初回フルスキャンをベースラインとし、開発が活発なサービスには毎週のスキャンをデフォルトとする、という導入手順が示されている。

インシデント対応の入口としては、Slack・Teamsなどのチャットツール経由の呼び出しに応答する「Claude Tag」（Slackでパブリックベータ提供中）が紹介されている。インシデントチャンネルにClaudeを独自のIDを持つメンバーとして参加させ、対応の会話そのものが将来のインシデントのための記憶になる、という位置づけだ。

セキュリティ側の視点：レビューの「ゲート」をどう保つか

7月21日のセキュリティブログは、AIが書くコードの割合が急増する中でどうレビュー・監視の質を落とさずに済ませるかという課題を扱っている。要点は、AIが生成量を増やすなら、レビュー・モニタリング・その他のセキュリティプロセスも同じペースでスケールしなければ、レビュー待ちのボトルネックになるか、レビューが不十分なまま出荷されるかのどちらかに陥る、という指摘だ。

日本語圏でまだ薄い理由

「AI-Native SDLC」という語自体は英語圏のソフトウェア開発コミュニティで徐々に使われ始めているが、Anthropic自身が公式に体系立てて用語と6段階フレームワークを定義したのは2026年8月21日と最近であり、日本語での解説記事はまだほとんど出回っていない。Claude Codeを使った開発フローの解説は増えているが、「開発サイクル全体をどう再設計するか」という組織論のレベルまで踏み込んだ日本語資料は本記事執筆時点（2026年8月27日）で見当たらなかった。

関連する動き

Anthropicが独自に体系化した6段階フローだが、企業のAI基盤を全社員に配って業務の仕組み自体をAIに覚えさせるという発想は、同じ2026年8月に発表されたCloudflare OSにも共通する部分がある。Claude Codeそのものの基本についてはClaude Codeとは──コード生成に留まらない「仕事を渡せる」AIエージェント、AIエージェントに渡す情報をどう設計するかという観点ではコンテキストエンジニアリングとはも参照してほしい。

「8倍」「80%」の算出根拠は開示されていない

• 「8倍」「80%」はいずれもAnthropic自身の社内データにもとづく自己申告の数値であり、算出方法（比較対象年度の定義、コード行数かPR数か、対象リポジトリの範囲、等）の詳細はブログ記事からは分からない。第三者による検証は確認できていない。
• このフレームワークはAnthropic自身の内部実践から逆算されたものであり、Claude Code・Claude Enterprise・Claude Tag・Claude Designといった同社製品を前提に設計されている。他社のツールチェーンや、Anthropic製品を使わない組織にそのまま適用できるかどうかは、本記事のソースだけでは判断できない。
• 「規制業界の企業はレビュー品質を落とせない」という問題意識は書かれているが、実際に規制業界の顧客がこのフレームワークを採用した事例（社名・業種を伴う実例）は、本記事で確認した3本の一次資料には記載がなかった。原文が示す設定例（bands.yaml・REVIEW.md・Hookのシェルスクリプトなど）も、Anthropic社内または想定シナリオとして提示されたサンプルであり、外部企業での導入実績を示すものではない。
• Stage 6で紹介されている「Claude Security」（コードベースの定期スキャン機能）と「Claude Mythos 5」というモデル名は、本記事執筆時点でこのPlaybook記事以外の一次資料での裏取りはできていない。Claude Securityの提供形態・料金体系・対応言語などの詳細は、本記事のソースの範囲では確認できなかった。
• Claude Codeのプランモード・Hooksの終了コード2の挙動については公式ドキュメントで直接照合したが、SkillsのYAMLフロントマター仕様やサブエージェントのツール制限の詳細な設定項目までは、本記事では突き合わせていない。