Anthropicが示すAIネイティブSDLC｜開発6段階の再設計3論点

齋藤竹紘2026年9月5日2026年9月5日AIニュース

Anthropic が2026年8月、AI前提の開発工程の手引きを公開しました。

Anthropic は2026年8月21日、ソフトウェア開発の全工程をAIエージェント前提で組み直すための手引き「The AI-Native SDLC playbook」を公開しました。主張は明快で、コードを書く速度が上がった結果、ボトルネックはコードそのものではなく、その前後にある計画・レビュー・承認へ移動した、というものです。開発会社の話に見えますが、社内システムや基幹連携の改修をベンダーに任せている事業会社にとっても、発注と検収の前提が変わる内容です。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）が解説します。

コードはもうボトルネックではない、と言い切った

このプレイブックの出発点は、開発の制約条件が入れ替わったという指摘です。従来のSDLC（ソフトウェア開発ライフサイクル、企画から本番運用までの一連の工程）は、計画・設計・実装・テスト・デプロイ・保守の6段階を、それぞれ別の担当者が受け持ち、ドキュメントとチケットと承認で受け渡す形が主流でした。この設計は、実装に数週間から数か月かかることを前提に、その手戻りを減らすために組まれたものだと整理されています。

ところが実装が数時間で終わるようになると、前提が崩れます。プレイブックは、実装が速くなったときに起きることを3点挙げています。第一に、ボトルネックが実装の左右、つまり計画とレビューやデプロイへ移ること。これらは依然として人間の速度で動きます。第二に、1行ずつ人の目で確認するという統制が現実に合わなくなること。差分の大半をエージェントが書く状況では追いつきません。第三に、例外承認が週次や月次の会議体を通るため、ガバナンスのコストが上がることです。

例として挙がっているのはセキュリティ部門です。人間の産出量に合わせて人員が組まれているため、エージェントが生成量を増やすと、レビュー待ちの行列が伸びるか、確認が不十分なまま出荷されるかのどちらかになります。規制業種の企業はどちらも許容できないので、統制側もエージェントの速度に合わせて作り替えるしかない、という論理です。

6段階を直線からループへ、鍵は「コミットされた成果物」

具体策として示されているのは、6段階を直線の受け渡しではなく、ループとして回す設計です。各段階は最後にひとつの成果物をバージョン管理へコミットし、次の段階はそれを読んで始まります。計画段階では要望を intent.md として書き残し、設計では spec.md、実装では plan.md と差分とテスト、デプロイではレビュー所見つきのプルリクエスト、保守では障害記録、という並びです。前半の段階が Markdown ファイル中心なのは、担当者とエージェントの双方が同じファイルを読んで動けるからだと説明されています。

この積み重ねが、そのまま監査証跡になる点が肝心です。誰が何を依頼し、エージェントが何を出力し、誰が承認したかがコミット履歴に残ります。従来は会議の議事録や承認ワークフローに散っていた記録が、コードと同じ場所に集まる形です。

段階ごとの変化も整理されています。計画は、委員会で要件を集めてワークショップと承認を経て手書きする方式から、Claude が一次情報から論点を抽出して intent.md にまとめる方式へ。実装では、組織の暗黙知を Claude Code の CLAUDE.md や Skills としてバージョン管理し、機械可読な形で持ち続けます。テストは、工程の境目に置くQAゲートから、実装の中に織り込む継続的な評価へ。デプロイは、全行を人が読む運用から、エージェントによる多層レビューと、Hooks を承認ゲートとして機械的に効かせる運用へ。保守は、人が本番を見張る形から、エージェントが監視し、逸脱を次の intent.md として書き戻す形へ移ります。

人間が判断から外れるわけではありません。判断を要する決定の責任は人間に残り、注意を向ける場所がゲートに集中する、という整理です。Anthropic は「ループは回り続け、人間の判断はその上に置かれ続ける（The loop keeps running. Human judgement stays above it.）」と締めくくっています。

今後の動き、そして発注側が見ておくべき点

この種の手引きが出てくること自体が、AI活用の焦点が「エージェントに書かせる」から「エージェントが書いた前提で組織を組み直す」へ移った証拠だと見ています。注目したいのは、統制をドキュメントではなく実行時の仕組みで担保する流れです。プレイブックが Hooks を承認ゲートとして扱い、CI に評価を組み込み、Claude Tag で障害対応まで同じループに入れているのは、規約を文章で配るのではなく、実行環境で強制するという発想の表れです。同種のガイドや、監視・権限管理・監査ログまわりの製品機能は、今後さらに増えると考えられます。

もうひとつ、注意しておきたいのは適用範囲です。今回の内容はAnthropicのApplied AIチームが顧客支援で実践している事例をまとめたものと明記されており、規制業種の大企業を強く意識した構成になっています。数名規模の内製チームがそのまま真似ると、統制の作り込みが重すぎる可能性があります。まずは、CLAUDE.md にあたる社内知識の明文化と、レビュー観点の言語化から着手するのが現実的です。

事業会社の視点で1点だけ触れると、システム改修を外部に発注している場合、見積もりの根拠が「実装工数」からレビューと承認の設計へ移っていく可能性があります。実装が速くなっても、要件の言語化と検収の設計が甘ければ全体は速くなりません。発注側が intent.md にあたる「何を、なぜ、どこまで」を自分の言葉で書けるかどうかが、今後の開発スピードを左右します。

まとめ

Anthropic のAIネイティブSDLCは、6段階を直線からループへ組み替え、各段階がバージョン管理された成果物を残すことで、速度と統制を両立させる設計です。人間の判断はゲートに集中させ、記録はコミット履歴に残します。エージェントに書かせる話ではなく、書かせた後の組織の作り替えの話として読むと、示唆が多い資料です。

参考文献

※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/

引用元: Anthropic

【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）

齋藤竹紘

株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。

投稿者: 齋藤竹紘

株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。齋藤竹紘のすべての投稿を表示