AIネイティブSDLC入門｜コードが速くなった後、次に詰まる場所

原典：Anthropic『The AI-native SDLC playbook』（2026年8月21日公開） https://claude.com/blog/the-ai-native-sdlc-playbook

本記事は上記を読み解き、日本の開発現場向けに再構成した解説です。訳文ではありません。 原典の主張と、AIGO Lab としての補足は、本文中で区別して書いています。

この記事でわかること

• 実装だけを速くしたチームで、次に詰まるのがどこか
• 「AIネイティブSDLC」が、実際には何を置き換えているのか
• CLAUDE.md・skills・hooks の役割の違い（助言と強制）
• 6つの工程を「成果物の受け渡し」という1本の線で読む方法
• 前提が要らない起点はどれで、どの順に手を付ければいいか
• 既存の Jira や要件管理ツールと、どう共存させるか

対象は、Claude Code をすでに日常的に使っている方です。自分の手元では実装が明らかに 速くなった。でも、チーム全体のリリースサイクルは前と変わっていない ―― この記事は そのギャップの正体と、そこを抜けるための順番の話です。

実装だけが速くなったチームで、次に詰まるのはどこか

「速くなったはずなのに、リリースは変わらない」

原典の最初の見出しは、この一言です。

Code is no longer the bottleneck （コードを書くことは、もはやボトルネックではない）

— Anthropic『The AI-native SDLC playbook』

心当たりのある方は多いはずです。たとえば2日かかっていた実装が半日で終わる。 そういうことは、本当に起きています。ところが、リリースまでの日数を数えてみると、前とほとんど変わって いない。

理由は単純で、速くなったのが1工程だけだからです。実装の前には要件を固める工程が あり、後にはレビューとリリースの工程があります。そちらは人間の速度のまま残っています。 仮に実装が2日から半日になっても、レビュー待ちが3日、リリース枠が週1回のままなら、 全体はほとんど縮みません。

原典の指摘は、ここからもう一歩進みます。前後の工程が「変わらない」のではなく、 むしろ悪化するというものです。

実装が速くなると起きる3つのこと

原典は、実装が従来のSDLCの想定を超えて速くなったとき、次の3つが同時に起きるとしています。

1. ボトルネックが、実装の左右へ移動する 計画・レビュー・デプロイという、人間の速度で動く工程に詰まりが移ります。実装を さらに速くしても、全体はもう縮みません。
2. 統制が現実に追いつかなくなる 「変更点を1行ずつ人が読む」というレビューは、人がその行を書いていた時代には 妥当なやり方でした。差分の大半をエージェントが書くようになると、同じやり方は 物理的に回らなくなります。
3. ガバナンスのコストが上がる 例外の判断が、週次や月次でしか開かれない会議に滞留します。開発が数時間単位で 動いているのに、承認だけが週単位のままなので、待ち時間の比率が跳ね上がります。

ここで大事なのは、3つとも「AIの精度が足りない」という話ではないことです。AIの出力が 正しくても起きる、プロセス側の問題です。

セキュリティレビューで考えるとわかりやすい

原典が挙げているのは、セキュリティレビューの例です。

セキュリティチームの人数は、人間が書くコード量に合わせて決まっています。そこへ エージェントがコード量を数倍にしてくると、起きることは2つに1つです。レビュー待ちの 行列が伸びるか、レビューが十分でないまま本番へ出るか。

規制のある組織は、どちらも選べません。だから、セキュリティと ポリシーのチェック自体をエージェントの速度に合わせる必要がある ―― これが原典の 出発点になっています。

図の「構築」は、ここまで「実装」と呼んできた工程のことです。6つの工程の呼び方は、 次の章で整理します。

AIネイティブSDLCとは、何を作り直す話なのか

直線からループへ

まず用語を整理します。SDLC（Software Development Lifecycle／ソフトウェア開発 ライフサイクル）は、アイデアが本番稼働に至るまでの一連の工程のことです。多くの組織は 呼び方こそ違え、おおむね次の6つに分かれています。

計画 → 設計 → 構築 → テスト → デプロイ → 保守

日本の現場の言葉に置き換えるなら、要件定義／基本設計／製造／テスト／リリース／ 運用保守に近いと考えてください。従来のSDLCでは、この6つが直線に並びます。工程ごとに 担当者が変わり、文書とチケットと承認印で仕事が受け渡されていきます。

原典が「AIネイティブSDLC」と呼ぶのは、この直線をループに組み替えたものです。 6つの工程それぞれにAIが入り、ある工程の完了が次の工程を自動的に呼び出す。保守で 見つかった問題は、そのまま計画の入口へ戻ります。

なお、同じものが「エージェンティックSDLC」「AI SDLC」などとも呼ばれます。原典自身が 「呼び名は違うが、指しているものは同じ」と明記しています。用語の違いに悩む必要は ありません。

工程ごとに何がどう変わるのかを、原典の記述をもとに整理すると次のようになります。

捨てるのは「統制」ではなく「統制のやり方」

この表を見て「AIに任せてレビューを省く話か」と読むと、原典の主張を取り違えます。

原典が明確に分けているのは、**統制の目的（control objective）とその強制手段 （enforcement）**です。

• 目的は変えない。誰が承認したのか。ポリシーは守られたのか。何が根拠なのか。
• 手段を差し替える。会議とレビュー会でやっていたことを、ファイルとコードでやる。

たとえば「外部公開APIには必ず認証をかける」というルールがあるとします。従来は 設計レビューで人が確認していました。AIネイティブSDLCでは、これをAIが読む形の 社内ルールとして書き、さらに破れないチェックをコードとして置きます。守らせたい 中身は1ミリも変わっていません。守らせる方法だけが変わっています。

むしろ、統制は強くなる方向です。会議での確認は担当者と当日の状況に左右されますが、 コードとして書かれたチェックは毎回同じように効きます。

ループを支える1本の線 ―― 成果物をコミットして次へ渡す

ここが、原典を読むうえで一番の骨格です。ここさえ掴めれば、残りの章はすべて 「この線の上のどこか」として理解できます。

各工程が受け渡すもの

AIネイティブSDLCでは、**各工程は「読んで始まり、書いて終わる」**という形に統一されて います。工程の終わりに成果物を1つバージョン管理へコミットし、次の工程はそれを読んで 始まる。人づての説明や、担当者の頭の中に残る前提が、途中に入りません。

起点になる intent.md は、こういうものです。書くのは発案者本人で、決まった書式は 要りません。

# Intent: 請求状況のセルフサービス化
作成者: 請求オペレーション部門　状態: draft

## 問題
顧客が請求の進捗を電話で問い合わせてくる。担当者の通話時間の
約3分の1が、状況確認だけに費やされている。

## あるべき姿
顧客がポータルで、状況・次のステップ・完了予定日を見られる。

## 影響範囲
請求担当者、ポータルチーム、請求コアAPI

## 制約
ポータルのセッションに新しい個人情報を増やさない。認証は既存のものだけ。

## 未解決の疑問
外部の損害査定人にもアクセスを与えるか。

エンジニアが書いた文書ではない、という点が大事です。困っている本人が、自分の言葉で AIと壁打ちしながらまとめる。原典が想定しているのは、そういう入り方です。

前半（計画・設計・構築の入口）でマークダウンファイルが使われるのには理由があります。 プロダクトオーナーとAIが、同じ1つのファイルを読んで、同じように動けるからです。 仕様書ツールの中に閉じた文書では、AIに渡すたびに変換が要ります。構築より後は、 成果物がコードとその記録に変わります。

用語についてintent.md spec.md plan.md といったファイル名は、原典が提案している命名の 取り決めであって、Claude Code の機能名ではありません。公式ドキュメントを探しても 出てきません。一方で CLAUDE.md、skills、hooks、サブエージェント、プランモードは 実在する機能です。ここは混ぜないでください。

spec.md ―― 書くのはエンジニアではない

受理された intent.md から spec.md を起こすのは、エンジニアではありません。 プロダクトオーナー自身です。intent.md と社内基準（skills）をAIに渡し、要件と設計を まとめて1つのセッションで出させます。エンジニアリングのスキルは要りません。

このとき、AIに「満たせない制約があれば印を付けろ」と指示しておきます。人が最初に見るのは、 その印が付いた箇所です。矛盾するポリシーや判断が要る点を先に潰してから、エンジニアに 渡す ―― 従来なら数週間後のレビューで発覚していたものを、仕様を書いている最中に処理する 形になります。

plan.md ―― 実装の前に、計画をレビュー可能にする

6つの成果物のうち、個人が今日から試せるのは plan.md です。AIGO Lab の見立てですが、 手戻りの量が一番わかりやすく変わるのもここです。

従来、レビュアーが最初に目にするのは完成した差分でした。「どのファイルを、どの順で 直すつもりか」はエンジニアの頭の中か、良くてチケットのコメントにしかありません。 だから、方針そのものが違っていた場合、気づくのは実装が終わった後になります。

計画を先にコミットしておくと、方向転換が文書の編集で済みます。原典が挙げている plan.md の項目は、変更するファイル／作業の順序／リスク／それを証明するテスト、の4つです。

Claude Code のプランモードは、計画が受理されるまでファイルを編集できません。つまり この順序が仕組みとして強制されるようになっています。

プランモード自体の使い方は別記事で詳しく扱っています。 → Claude Code プランモード入門｜「動くけど違う」を減らす3ステップ

コミット連鎖が、そのまま監査証跡になる

成果物を毎回コミットしていくと、副産物が1つ手に入ります。

誰が何を求め、AIが何を出し、誰が承認したのかが、git の履歴として1本につながる ことです。原典は、このコミットの連なりがそのまま監査証跡（audit trail）になるように 設計されている、としています。

証跡のために別途エビデンス資料を作る、という作業が要らなくなる ―― これは、監査対応に 工数を割いている組織にとって、地味ですが大きい変化です。

ただし、この形が日本の監査実務でそのまま受け入れられるかどうかは、原典も保証して いません。「そう設計されている」という段階の話として読んでください。実際に通せるかは、 自組織の監査部門や外部監査人との相談になります。

AIに渡す知識と、AIに守らせる規則を分ける

ここが、多くの人がつまずくところです。CLAUDE.md、skills、hooks ―― 名前は聞いた ことがあるけれど、どれに何を書けばいいのか分からない。原典はこの3つを、はっきり 別の層として扱っています。

CLAUDE.md：毎回読まれる常駐知識

CLAUDE.md は、新しくチームに入った人に初日に渡す資料にあたります。ビルドと テストのコマンド、守ってほしい規約、システムの構成、そして「AIがよく間違えること」。

# 決済サービス

## コマンド
- ビルド: make build
- テスト: make test（単体）/ make itest（結合、docker が要る）
- 静的解析: make lint（CI でも走る。push 前に直す）

## 規約
- 金額は必ず BigDecimal。double は使わない
- エンドポイントを追加したら src/itest に結合テストを1本足す

## よく間違えるところ
- 依存ライブラリのバージョンは上げない（基盤チームの管轄）
- 旧 v1/ パッケージは凍結。変更は v2/ に入れる

原典が挙げている運用ルールは2つです。

• 1ページに収める。 セッションの開始時に全文が読まれるので、古い記述はそのまま 無駄なコンテキスト消費になります。
• 同じ間違いを2回されたら、その時点で追記する。 3回目を防ぐのが目的です。

/init を実行すれば下書きが自動生成されますが、そのままにしないこと。生成された ものは情報が多すぎるので、初日に必要な分まで削ってからコミットします。

1ページに収まらなくなったときの分割方法は、こちらで扱っています。 → CLAUDE.mdは「4層」に分けると安定する

skills：必要なときだけ読まれる制度的知識

CLAUDE.md が「毎回読まれる」のに対して、skills は条件に合ったときだけ読み込まれる 知識です。

社内のAPIセキュリティ基準、命名規約、ブランドガイドライン。こうした「一貫して適用され なければ困るが、毎回必要なわけではない」ものが skills の担当範囲になります。実体は SKILL.md を含むフォルダで、冒頭にいつ発動するかを、本文に何をするかを書きます。

---
name: secure-api-review
description: APIセキュリティ基準を適用する。外部公開エンドポイントの
  作成・変更時、APIコードのレビュー時、OpenAPI 定義の生成時に使う
---
# セキュアAPIレビュー

1. 認証: /health 以外に匿名アクセス可能な経路を作らない
2. 入力検証: リクエストボディを OpenAPI スキーマで検証し、未知の
   フィールドは拒否する
3. 監査: 状態を変えるエンドポイントは監査イベントを出す
4. データ分類: pii タグのついたフィールドをログとエラーに出さない

原典の使い分けの目安は明快です。一貫して適用されなければならない制度的知識は skill に書く。CLAUDE.md やその場のプロンプトで足りるものは、skill にしない。

skills はリポジトリの .claude/skills/<名前>/ に置けばコードと一緒に配布されますし、 プラグインの形にすれば組織全体へ配れます。ポリシーが変わったら skill を直す。 エンジニアは次のセッションから自動的に新しい版を使います。

hooks：唯一「守らせられる」層

ここが原典で最も実務的に効く指摘です。

skills は助言的な統制（advisory control）にすぎません。 ポリシーを適用させやすく はしますが、セッションに遵守を強制する仕組みは入っていません。

必ず守らせなければならないルールには、その裏に決定論的な仕組みが要ります。それが hooks です。hook は、AIが何か操作をする直前に走るスクリプトで、許可する／人に聞く／ ブロックするのいずれかを返します。

原典の言い方を借りるなら、skill は違反を「稀」にし、hook は違反を「ほぼ不可能」に します。

構築中の hook が担当するのは、たとえばこういう仕事です。

• 生成されたクラスや凍結パッケージなど、触ってほしくないパスへの編集をブロックする
• ファイル編集のたびにフォーマッタと静的解析を走らせ、ズレを溜めない
• 認証情報が差分に混ざるのを止める

構築中に走る hook は、変更されたファイルだけを見て、速く終わるように作ります。 テストスイート全体のような重い検査は、コミット時かPR時に回します。

そしてもう1つ、「人に承認を聞く」タイプの hook を構築中に置いてはいけません。 並列で走っている全セッションのクリティカルパスに、人間が戻ってきてしまうからです。 承認を挟むならデプロイ側 ―― これは後の章で扱います。

3つの使い分け

判断は、次の3つの問いで足ります。

3つ目が特に重要です。守らせたいルールは、skill と hook の両方に書くのが原典の 考え方です。skill が「そもそも違反しにくくする」役、hook が「万一のときに止める」役 として、二段構えになります。

人間が見る前に、AIに自分の仕事を検算させる

検証手段を渡していないツケは、人間のレビューに回る

エージェントに作業を頼むとき、結果が正しいかどうかをそのセッション自身が確かめられる 手段を必ず渡す。これが原典の主張です。テストでも、ビルドでも、スクリーンショットの 比較でも構いません。

渡していない場合、そのコストは消えません。人間のレビューに回るだけです。動くかどうか 分からないものが人のところへ来るので、レビュアーが動作確認から始めることになります。

具体的な作り方として、原典は次を挙げています。

1. 確認手順を1コマンドにまとめる。 環境変数の設定やらコマンドの並びやらが要るなら、 make test のような形にまとめ、失敗したら非ゼロで終了するようにします。
2. CLAUDE.md に、正常時の出力例まで書く。 「何が出れば成功なのか」が分からないと、 AIは判断できません。
3. 完了条件を定量的に書く。 「うまく動くこと」ではなく、「test_status.py の テストが全部通ること」「エンドポイントが200と新しいフィールドを返すこと」のように 書きます。
4. 検証を「完了」の定義に入れる。 テストを走らせてから完了報告する、出力を貼る、 というルールを CLAUDE.md に書きます。

## 作業の確認方法

- ビルド: make build（"Build succeeded" で終わること）
- テスト: make test（全て緑。失敗したテストをスキップも削除もしない）
- 静的解析: make lint（警告ゼロ）

完了報告の前に3つとも実行し、出力を貼ること。
テストが落ちたら、テストではなくコードを直すこと。

UI の作業なら、ブラウザ操作かスクリーンショットの手段を渡します。実装 → 撮影 → 見比べ → 調整、を2〜3周させると仕上がる、というのが原典の書きぶりです。

バグ修正は「落ちるテスト」から始める

バグ修正には、原典が別の手順を用意しています。

1. まずバグを再現するテストを書かせる
2. 実行して、期待どおりの理由で落ちることを確認する
3. そのテストをコミットする
4. テストを書き換えずに通るよう、修正させる

そして4番目を確実にするために、修正作業の間はテストファイルの編集を hook でブロック します。

理屈は単純です。修正する側が採点基準を書き換えられる状態では、「通った」に意味が ありません。修正の前から存在していて、エージェントが手を出せなかったテストが通ったこと だけが、バグが消えた証拠になります。

検証ループと verifier サブエージェントは別物

ここは混同されやすいので、原典もわざわざ節を割いています。

• 検証ループは、作業中ずっと回り続けるものです。書いては試し、直しては試す。
• verifier サブエージェントは、セッションが「終わった」と判断した時点で、 新しいコンテキストで1回だけ走らせる最終確認です。

分ける理由は、そのコードを書いた前提に汚染されていない判定が欲しいからです。 書いた本人（本エージェント）は、自分の想定の中で動作確認をしてしまいます。何も 知らない状態から起動した検証役に、アプリを実際に動かして報告だけさせる。原典の サブエージェント定義の例では、「修正はするな、報告だけしろ」と明示的に指示しています。

設定そのものも回帰テストする（継続的Eval）

もう一段上の話です。

CLAUDE.md、skills、hooks ―― これらはエージェントの振る舞いを決める設定です。 コードと同じで、変更すれば挙動が変わります。にもかかわらず、これらを変更したときに 「前と同じ品質で動くか」を確かめる仕組みは、たいてい存在しません。

原典が提案するのは、設定に対する回帰テストです。

1. 最近の実作業から、20〜50件のタスクを集める
2. 各タスクを、プロンプトと合格条件（テストが通る／静的解析が綺麗／ポリシーに沿う） の組にする
3. CI で非対話モードのClaude Codeを走らせ、CLAUDE.md や .claude/** が変更された PR と、定期スケジュールの両方で実行する
4. 合格率が下がる変更は、マージ前にレビューする
5. 本番で起きたインシデントは、毎回1件この評価セットに足す

5番目が効きます。同じ問題をきちんと拾えるかどうかを、以後ずっと自動で 確かめ続けられます。

なお、この評価セットは生き物だと原典は書いています。モデルが良くなると、 かつては差がついた課題で差がつかなくなる。監視から見つかった新しいケースを 足していく必要があります。

レビューと承認を、AIの速度に合わせて作り直す

AIはレビューする側にも回る

AIがコードを書くようになると、レビューの需要が供給を上回ります。原典の答えは、 レビューする側にもAIを立てることです。

ポイントは、レビュー方針をファイルに書くことにあります。原典は REVIEW.md という 名前で、リポジトリのルートに置く例を示しています。中身は、

• どの観点で何回見るか（バグ／セキュリティ／仕様と計画への準拠、の3パス）
• 何を「重要」と呼ぶか（挙動が壊れる、データが漏れる、ポリシー違反。命名や スタイルは「些細」に分類する）
• 些細な指摘の上限（1レビューあたり5件まで、残りは件数だけ報告）
• 報告しなくていいもの（生成ファイル、CIがすでに検査しているもの）

原典が「報告しないもの」まで定義させているのは、指摘の量そのものがレビューを機能不全に するからです。AIGO Lab としても、何を報告しないかを決めることが、実運用で最初に効く 設定だと考えています。

もう1つ、原典が挙げている運用があります。レビューで見つかった間違いが2回目なら、 CLAUDE.md に書き戻す。レビュー自身が CLAUDE.md を読むので、次のPRからは レビューが自動で拾ってくれます。

職務分離：書いたエージェントは、自分のコードを承認できない

ここは、社内で説明を求められたときの要になる部分です。

AIレビューの所見は、PRを承認も却下もしません。ブランチ保護によるコードオーナーの 承認は、そのまま残ります。人間は所見を読んだうえで判断します。

つまり、コードを書いたエージェントには、それを承認する経路がありません。職務分離 （separation of duties）は保たれたままです。

「AIに任せる＝統制を捨てる」ではない、という話の一番具体的な根拠がこれです。変わったのは 人間が見る対象で、行単位の読み合わせから、意図とリスクの判断へ一段上がっています。

並列で走らせるときの上限は、レビューできる本数

Claude Code は、git の worktree（同じリポジトリを別ディレクトリに複数チェックアウト する仕組み）を使って、1人が複数のセッションを同時に走らせられます。触るファイルが 重ならないタスクに分けて、別々のセッションへ渡す形です。

原典が示す実務的な上限は、はっきりしています。1人がきちんとレビューできる本数です。

出発点は2〜3本。レビューが追いついている間だけ増やす。ここを外すと、実装のボトルネックを レビューのボトルネックに付け替えただけになります。

エージェントは本番ゲートの手前まで、越えない

デプロイ側の原則は、原典の言葉でいえば「エージェントは本番ゲートの手前まで全部やり、 ゲートは越えない」です。

これを支えているのは3つの仕組みです。

• ブランチ保護：エージェントが書いたものは必ずPRになり、main への直接の経路がない
• 本番デプロイの hook：リリース責任者の承認がない限り、本番へのデプロイを止める
• 環境ごとの権限段階：開発環境は自由に、ステージングは中間、本番は承認必須

そして原典は、ロールバックをパイプラインで最も演習された経路にしておけと書いて います。後の保守フェーズで、エージェントがこれを呼ぶことになるからです。使うときに 初めて試す、では間に合いません。

ループを閉じる ―― 人が起動しなくても回る状態

ここまでは、どの工程も人が最初のひと押しをする前提でした。最後の工程で、その ひと押しがなくなります。

検知は決定論的に、判断だけをAIに渡す

この設計で一番重要なのは、監視する側にAIを入れないことです。

本番のメトリクスを見て「いつもと違う」と判定するのは、決定論的なスクリプトの仕事です。 移動平均と標準偏差を取り、統計的なルールで逸脱を判定する。このスクリプトはバージョン 管理され、単体テストも書かれます。モデルは一切関与しません。

AIが呼ばれるのは、逸脱が検知された後です。しかも、逸脱の度合いによってできること が段階的に制限されます。原典が示す設計は次のとおりです。

3σでも、勝手に本番を触ることはありません。PRを出すところまでか、あらかじめ 承認された手順（ロールバックなど）を呼ぶところまでです。

段階の定義そのものも設定ファイルとしてバージョン管理されます。「AIにどこまで 任せるか」が、レビュー可能な形で1箇所に書かれている状態です。

見つけたものは、計画の入口に戻る

エージェントが診断した結果は、計画工程と同じ形式の intent.md として書き出されます。 何が起きたか、根拠は何か、どうなれば解決か、影響範囲はどこか、未解決の疑問は何か。

そこから先は、ほかの案件とまったく同じ道を通ります。設計され、計画され、実装され、 レビューされ、承認されて出ていく。ループが閉じます。

人間がいなくなるわけではありません。役割が変わります。「起動する係」から 「トリアージして承認する係」へ。夜中のアラートも、チャットに飛んできた障害報告も、 朝には診断済みの案件としてキューに並んでいる、という状態がゴールです。

どこから始めるか

前提が要らない起点は5つある

原典は、工程の順番と導入の順番は別物だとはっきり書いています。計画から順に手を 付ける必要はありません。

依存関係を整理すると、何も前提を持たない起点が5つあります。

• 意図を記録する（intent.md）
• CLAUDE.md を整える
• 検証ループを渡す
• hooks を置く
• プランモードを既定にする

このどれから始めても構いません。他の施策は、この5つのどれかを前提にしています。

個人・小チームなら、この順

ここからは AIGO Lab としての補足です。原典は大企業の導入まで視野に入れて書かれて いますが、日本の読者の多くは数人から数十人のチームでしょう。その規模で効く順番を 考えると、次の4つになります。

1. CLAUDE.md を書く。 1人でも今日できます。効果が出るのも一番早い。
2. 検証ループを渡す。 make test の1コマンド化と、完了条件の明文化。ここまでで 「動くか分からないものが上がってくる」状態は、かなり減ります。
3. プランモードを既定にする。 手戻りの量が変わります。
4. hooks を1つ置く。 まずはフォーマッタの自動実行など、影響の小さいものから。 仕組みに慣れてから、保護したいパスのブロックへ広げます。

ここまでは、社内の承認も予算も要りません。1人で始めて、効いたらチームに広げる、 という進め方ができます。

既存の Jira・要件管理ツールとどう共存させるか

日本の開発現場で、この記事を読んで最初に出てくる疑問はこれだと思います。

「うちはチケットがJira、要件はトレーサビリティ対応の専用ツール、変更は変更管理委員会。 マークダウンファイルに移せない」

原典もそこは織り込み済みで、節を1つ割いています。既存システムは、監査人と規制当局が すでに受け入れていて、他のチームもそれに依存しているため、簡単には動かせません。だからAIネイティブSDLCの 側が、既存の形に合わせにいきます。

原則は1つ。成果物の種類ごとに、正（source of truth）を1つだけ決める。残りは コピーかリンクにする。取りうる形は3つです。

3つ目は「妥協案」に見えますが、原典は移行の出発点として妥当だと位置づけています。 まずリンクだけ張っておいて、どちらを正にするかは後で決める。現実的な選択肢です。

組織フェーズで効いてくるもの

以下は、チームを越えて展開する段階になってから必要になるものです。最初から要る わけではありません。

• 管理者設定による強制 ―― 個々のエンジニアが無効化できない権限設定や hook を、 組織の管理側から配布する。規制業界向け。
• CIでの非対話実行 ―― パイプラインの中でエージェントを走らせ、ビルド失敗の原因 切り分けや変更履歴の下書きを任せる。
• 継続的Eval ―― 設定変更に対する回帰テスト。
• 定期的なコードベーススキャン ―― 脆弱性検査を「リリース前のイベント」ではなく スケジュール実行に変える。

なお、原典で紹介されている一部の製品（チャットツール連携、ホスト型のセキュリティ スキャン、デザイン連携など）は、2026年8月時点でベータまたはプレビュー段階です。 提供状況は変わりますので、導入検討の際は公式ドキュメントで最新の状態を確認してください。

上段の5つがすべて起点です。そのうち色の付いた4つが、個人・小チームで今日から 始められるものにあたります。

まとめ

• AIで速くなったのは実装だけです。ボトルネックは、計画とレビューとデプロイへ移動 しました。
• AIネイティブSDLCが変えるのは統制のやり方であって、統制そのものではありません。 むしろ、会議で確認していたものをコードにする分、効き方は安定します。
• 全体を貫くのは成果物の受け渡しです。各工程が読んで始まり、書いて終わる。その コミットの連なりが、そのまま記録になります。
• CLAUDE.md は常駐知識、skills は条件付きの知識、hooks だけが強制できる層です。 守らせたいルールは、skill と hook の両方に書きます。
• 人間はいなくならず、位置が変わります。行を読む人から、意図とリスクを判断する人へ。
• 前提が要らない起点は5つあります。どこから始めても構いません。

最後に1つ、正直に書いておきます。原典には、導入効果の定量的な数字が一切出てきません。 「数週間が数時間になる」といった記述は期待値として書かれたもので、測定結果ではありません。 そのかわり、各施策について何をどう測るか（gitのタイムスタンプ、PRのメタデータ、 CIのログ、DORA指標など、すでに手元にあるデータ）が具体的に示されています。自分の現場で 効いたかどうかは、自分で測ることになります。

ループは回り続けます。人間の判断は、その上に残ります。

出典

原典：Anthropic『The AI-native SDLC playbook』（2026年8月21日公開、著者 Louis Claxton） https://claude.com/blog/the-ai-native-sdlc-playbook

本記事は原典を読み解き、日本の開発現場向けに再構成したものです。「どこから始めるか」の 章に含まれる導入順の提案は AIGO Lab による補足で、原典の記述ではありません。図版は すべて AIGO Lab のオリジナルです。

関連記事

• CLAUDE.mdは「4層」に分けると安定する
• Claude Code プランモード入門｜「動くけど違う」を減らす3ステップ
• AIコーディングのセキュリティ設計｜AIが8割書く時代の境界線