Anthropic が発表：AI ネイティブ SDLC（ソフトウェア開発ライフサイクル）実装ガイド

全体像：ボトルネックはコードではなく「待ち時間」

従来の SDLC は、Build に最もコストがかかることを前提としています。要件は会議と承認を経て、設計は仕様書になり、エンジニアは数週間かけてコードを書き、テスト、レビュー、リリースはこの長いサイクルを中心に展開されます。Build が十分に遅ければ、他のフェーズでの待ち時間はそれほど目立ちません。

しかし、エージェントによってこの比率は変わりました。コードは数時間で生成されるかもしれませんが、要件の明確化、セキュリティレビュー、テスト設計、変更承認、本番リリースの承認は、これまで通りの人的プロセスのペースで進みます。Build だけが短縮され、プロセスの両側は短縮されていないのです。

その結果、ボトルネックは「誰がコードを書くか」から「誰が意図を説明し、結果を検証し、リスクを負い、本番リリースを承認するか」へと移行しました。もし人間がすべての diff を一行ずつレビューし、すべてのコマンドを承認し続けるなら、チームは自分たちでコードを書く代わりに、エージェントがコードを書くのを見るために列に並ぶだけになってしまいます。

Anthropic は六つのフェーズを廃止したのではなく、人間による伝言ゲームを、読み取り可能で、コミット可能で、トリガー可能な成果物へと変えました。Git を信頼できる情報源とする場合、最小限のフィードバックループは次のように記録できます。

構造化された Markdown 成果物 → Git にコミットしてバージョン管理 → 次のフェーズのエージェントをトリガー → システムが先に検証 → 人間が重要なゲートで判断 → 本番からのフィードバックを新しい intent.md に書き戻す。

元図では線形プロセスを閉ループに変更。下の日本語トラックは、閉ループが実際に依存する成果物とゲートを示します。

計画 intent.md プロダクト責任者が承認

→

設計 spec.md 仕様とリスクが承認される

→

実装 plan.md エンジニアが計画を承認

→

テスト コード＋テスト結果 検証に合格

→

リリース PR＋レビュー記録 コード所有者が承認

→

運用 リリース／障害記録 制御範囲を逸脱

↩ 新しい intent.md 本番で見つかった問題が計画に戻り、ループが閉じます

Markdown と Git はあくまで実装手段です。重要なのは、各フェーズに一意で追跡可能な承認状態が存在することです。初期段階では intent.md、spec.md、plan.md が適しています。Build 以降は、コード、テスト、PR、パイプラインログ、インシデント記録も正式な成果物となります。Jira、ServiceNow、Figma を信頼できる情報源として使い続けることも可能ですが、最低限、レコード ID とコミット SHA を使ってリポジトリと相互に参照できるようにする必要があります。

次の表で六つのフェーズの全体像を示します。詳細については、この後、ガイドの順序に厳密に従って説明します。

各フェーズでは、次の四つの問いに答える必要があります。次の段階に何を引き渡すのか、機械は何を使って検証するのか、どの判断を人間が行うのか、そして、その変革が実際に効果を上げているかどうかをどうやって知るのか。このうち一つでも欠けると、自動化は単に処理待ちの出力をより速く生み出すだけになります。

一、Plan：曖昧なアイデアを intent.md にする

従来の計画プロセスは、プロダクトマネージャーが何度もインタビューや会議を重ね、ユーザーストーリーを整理し、ビジネス担当者の言葉を正式な要件に翻訳することに依存していました。この何度も繰り返される伝言の過程で情報は失われ、問題を提起した本人も、自分の意図が最終的にどのような形になったのかを確認することが難しくなります。

AI ネイティブなアプローチでは、アイデアの提案者が自然言語で、問題、影響を受ける対象、期待される結果、制約、未解決の問題を直接説明します。エージェントは質問を重ねて整理し、人間が読めるだけでなく、後続のエージェントが実行できる intent.md を生成します。プロダクトオーナーが修正して受け入れた後、Design フェーズに進みます。

• 提出成果物：intent.md。提案者、日時、問題、対象、制約、未解決の問題を保持します。
• 機械による検証：ファイルのバージョン、改訂履歴、および元の会話から提出された内容へのトレーサビリティ。
• 人間によるゲート：プロダクトオーナーが、これが次のフェーズに進む価値のある真の意図であるかどうかを判断します。
• 推奨指標：最初の会話から intent が提出されるまでの時間、および提出後に実際に Design フェーズに進んだ割合。

このステップの価値は、「AI がプロダクトマネージャーの PRD 作成を支援する」という点だけにとどまりません。最初の引き渡しの時点で、機械が読み取り可能な元の意図が残されるため、後続のフェーズで会議の参加者の記憶に頼ってコンテキストを補完する必要がなくなります。

二、Design：ポリシーを spec.md 生成時に適用する

従来の設計プロセスでは、ブランド、セキュリティ、コンプライアンス、UX、アーキテクチャに関するルールは、後期のレビュー段階まで持ち越されることがよくありました。仕様書が完成した後、あるいはコードが完成した後でさえ、ポリシー担当者が矛盾を発見するため、手戻りが発生し、コストがかさみます。

このガイドでは、エージェントに、承認された intent.md を読み取らせると同時に、企業ポリシーと設計ガイドラインを読み込ませ、同じ作業セッション内で spec.md を生成することを推奨しています。ポリシーの矛盾が発生した場合、エージェントは問題を指摘しますが、担当者に代わって最終的な取捨選択は行いません。

• 提出成果物：spec.md。要件、設計上の選択、境界、リスク、未解決の矛盾を含みます。
• 機械による検証：どのポリシーまたはスキルが使用されたか、どの要件が満たされたか、どの矛盾が残っているか。
• 人間によるゲート：プロダクトオーナーは仕様が意図を実現しているかを判断し、ポリシー担当者はセキュリティ、コンプライアンス、ブランドに関する矛盾を処理します。
• 推奨指標：intent から spec までのリードタイム、および仕様提出後に発生した要件の手戻り。

このステップにより、ポリシーの適用が前倒しされます。ルールは事後的なチェックリストから、仕様生成時の入力へと変わります。

三、Build：まず plan.md を承認してから、エージェントにコードを書かせる

Build は原文で最も多くのページ数を割いているセクションです。「エージェントにコードを書かせる」ことは出発点に過ぎず、難しさは、エージェントが何に基づいて行動するのか、何を変更できるのか、どのように並列化するのか、そしてどのシステムが最終的な判断を下すのかという点にあります。

最初のステップはプランモードです。エージェントはまずコードベースを読み、変更予定のファイル、実装順序、リスク、検証方法を書き出し、plan.md を作成します。エンジニアは計画をレビューしてから、実行を許可します。これにより、大量のコードが生成される前に、人間が方向性を修正できます。

第二のステップは、異なる種類の知識を異なる制御層に配置することです。

• CLAUDE.md には、ビルドコマンド、アーキテクチャの規約、繰り返し発生するプロジェクトのエラーを保存します。一ページ程度に収め、プロジェクトの変更に合わせて更新するのが理想的です。
• スキル には、安全基準、設計ガイドライン、反復的なプロセスを保存し、エージェントが組織のポリシーに従う可能性を高めます。
• フック、テスト、CI は、凍結されたディレクトリを変更しない、バグ修正中にテストを書き換えないなど、確実に実行される必要があるルールを担当します。
• 設定、サンドボックス、ネットワークホワイトリスト、短期間の認証情報は、エージェントが認識しアクセスできる環境を制限します。

これらの層は、互いの役割を代替できません。CLAUDE.md とスキルはプロンプトと知識の層に属します。常に維持されなければならない境界は、フック、CI、ブランチ保護、権限システムによって強制されるべきです。ハードルールも自動的に正しくなるわけではなく、書き込まれたルールを安定して実行するだけです。

第三のステップは、情報源と並列化の扱いです。リポジトリもレガシーな業務システムも、どちらも権威となり得ますが、リンクされていない二つの「真実」を同時に維持することはできません。並列セッションは、独立したワークツリーで、互いに干渉しない完全なタスクを実行するのに適しています。サブエージェントは、メインセッション内の狭い責務を持つアシスタントであり、独立したコンテキストと制限されたツールを持ちます。共有ファイルが多い作業は引き続きシリアルに行うべきであり、並列処理の上限は、最終的に人間がレビューできる結果の数によって決まります。

• 提出成果物：承認された plan.md、コードの diff、テスト。
• 機械による検証：ビルド、テスト、計画との整合性、フックによる許可またはブロックの記録。
• 人間によるゲート：エンジニアが計画を承認し、実装が意図に沿っているか、リスクが許容可能かを判断します。
• 推奨指標：初回実装でのマージ率、手戻りの回数、diff と plan の整合性。

四、Test：エビデンスをコード作成エージェントから独立させる

エージェントは、人間に引き渡す前に、自分自身でビルド、テスト、型チェック、ビジュアル検証を実行し、失敗した結果に基づいて修正を続けることができるべきです。これはフィードバックループです。失敗は即座に実行主体に戻り、最初に人間のレビュー待ちキューに入ることはありません。

しかし、「エージェントの自己テストが通った」だけでは不十分です。検証のエビデンスは、コードを生成したのと同じ実行プロセスによって随意に書き換えられるべきではありません。バグ修正の場合、まず確実に失敗するテストを作成してコミットし、フックまたはレビュールールによって、エージェントが修正プロセス中にそのテストを変更することを阻止します。そうしないと、エージェントがアサーションを緩めたり、境界条件を削除したり、テストを書き換えたりして、グリーンの結果をでっち上げる可能性があります。

継続的なフィードバックループと独立した検証者は異なります。前者は同じセッション内で迅速にエラーを修正します。後者は新しいコンテキストと独立したツール権限を使用して結果を再検証し、コード作成時に引き継がれた想定を継承することを避けます。実行ログ、スクリーンショット、セッション記録、OpenTelemetry、PR チェックランがまとまってエビデンスの連鎖を構成します。これは単なる「テストは通しました」という言葉ではありません。

テスト範囲はエージェントの設定もカバーする必要があります。原文では、最近の実際の作業から20～50個のタスクを収集することを推奨しています。モデル、プロンプト、CLAUDE.md、スキル、フックが変更されるたびに、同じ評価セットを実行します。また、本番で発生したインシデントはすべて、恒久的な評価に変換されるべきです。

• 提出成果物：テストログ、スクリーンショットの差分、独立した検証結論、評価結果。
• 機械による検証：ワンコマンドで実行できる検証コマンド、保護された失敗テスト、継続的な回帰テストセット。
• 人間によるゲート：コードオーナーが、エビデンスが期待される動作とリスクを本当にカバーしているかを判断します。
• 推奨指標：エージェントの自己チェック後の初回 CI 通過率、評価の通過率、本番での回帰件数。

五、Deploy：エージェントは本番ゲートの手前まで自動で進む

Deploy の章では、三つのレベルの機能について説明しています。AI による PR レビューへの参加、フックによる承認ゲート、CI/CD 内でのエージェントの非対話的な実行です。共通する原則は、エージェントは本番ゲートの前までのすべてを自動化できるが、本番リリースの承認を自分で通過する経路を持たないということです。

AI レビューは、バグ、セキュリティ、コンプライアンスなどの観点ごとに PR を複数回チェックできます。また、@claude コメントに応答してコードを修正し、失敗したチェックを直して更新をプッシュすることもできます。REVIEW.md は、何が Important で、何が単なる Nit で、どの生成ファイルや CI がカバーする内容をスキップすべきかを定義します。

職務分掌はなくしてはいけません。AI レビューの指摘は判断に影響を与えることはできますが、PR を自分で承認したりブロックしたりすることはできません。ブランチ保護は引き続きコードオーナーの承認を要求し、コードを書いたエージェントが自分の変更を承認する経路はありません。

リリース機能は環境に応じて段階分けされます。開発環境ではより自由に、ステージング環境は中間、本番環境ではリリースの準備のみを行い、指名されたリリース担当者の承認を待ちます。エージェントのジョブはサンドボックス内で実行され、短期間でスコープが制限された認証情報を使用し、デフォルトでは本番環境への常時アクセス権限を持ちません。

ロールバックは、パイプライン全体で最も念入りに訓練しておくべき手順です。理想的には単一のコマンドで実行でき、ステージング環境で定期的に練習します。ロールバックが実際に機能すると確認できて初めて、Maintain フェーズで深刻な異常時に呼び出せます。

• 提出成果物：PR、AI レビューの指摘、人間による承認記録、リリースログ、ロールバックログ。
• 機械による検証：統一されたレビューパス、フック、ブランチ保護、サンドボックス、パイプラインのチェック。
• 人間によるゲート：コードオーナーがコードのリスクを判断し、リリース担当者が本番環境へのアクションを承認します。
• 推奨指標：初回レビューまでの時間、レビュー指摘の解決時間、各ゲートでの待ち時間、DORA 指標。

六、Maintain：本番の異常を再び intent.md に戻す

Maintain は、六つのフェーズの中で、「人間がエージェントを起動する」から「イベントが自動的にエージェントを起動する」へと移行する唯一のフェーズです。そのため、原文では成熟の前提条件を重視しています。可観測性、安定したベースライン、低ノイズのトリガー、独立した権限境界、そして訓練済みのロールバック。これらが一つでも欠けている場合、自動対応を直接導入すべきではありません。

異常検知自体は決定論的なままです。バージョン管理されたスクリプトが、CI 失敗率、5xx エラー、リリース後のエラーレート、またはプロセス指標を監視し、コントロールバンドを超えた場合にのみエージェントを呼び出します。軽度の異常は記録のみ、中程度の異常は読み取り専用の診断を許可、深刻な異常でも PR を開くか、事前に承認されたランブックをトリガーするだけです。

エージェントは、異常、エビデンス、影響を受けたシステム、提案された結果、未解決の問題を新しい intent.md として書き出し、Plan フェーズに再び入ります。修正がリリースされた後、インシデントは評価セットに追加され、本番からのフィードバックが開発プロセスに組み込まれます。

原文では、Claude Tag を使用したインシデントチャネル内の完全なフィードバックループも示しています。夜間に緊急メッセージが届くと、Claude は自分の ID で議論に参加し、チャネルの履歴を読み、指標をチェックして診断を提案します。本番環境でのアクションは、人間の明示的な承認を待ちます。承認後、承認済みのロールバックを実行し、MCP を使用して指標がベースラインに戻ったことを確認し、振り返りをバージョン管理されたレッスンファイルに書き込みます。小さく明確な問題は直接 PR を作成し、より大きな問題は新しい intent.md を生成します。

元のケース図です。チャンネルには依頼、診断、人による承認、アクション、検証の記録が残るため、チャンネル自体がインシデントの監査証跡になります。

• 成果物：診断結果、インシデント記録、修正PR、バージョン管理された振り返り、新しい intent.md
• 機械的な証拠：決定論的なコントロールバンド、指標の復旧検証、インシデントに対応する恒久的なeval
• 人間によるゲート：サービス担当者がトリアージし、リスクの高いアクションを承認し、即時修正、スケジュール調整、却下のいずれかを決定します
• 提案される指標：異常発生からintentまでの時間、発見がマージされた修正に転換する割合、同種インシデントの再発率

実装の順序：12のプレイは六つのフェーズのリストではない

ガイドは六つのフェーズに分けて説明されていますが、実際の導入順序は依存関係によって決まります。公式の依存関係グラフには12のプレイがあり、Planの自動化からMaintainまで機械的に進めることはできません。

元図の矢印は採用の依存関係を示し、6段階の実行順序ではありません。

1. 基盤層・並行して開始可能 意図の捕捉・CLAUDE.md・フィードバックループ・フック・プランモード

   まず読み取り可能な入力、実行可能な証拠、動作の境界を得る

2. 再利用層・基盤の上に拡張 スキル・サブエージェント・評価

   ポリシーの再利用、検証の独立性、設定の回帰テスト

3. 組織層・正式な納品に接続 要件と設計・PRレビュー

   成果物と証拠を部門間の意思決定とコード承認に統合

4. 自律層・最後に開放 CI/CD・ループを閉じる

   非対話実行から本番ゲートまで、本番イベントは計画に戻る

最初の層は同時に開始できます。Capture intent、CLAUDE.md、Feedback loop、Hooks、Plan Modeです。これらはまず、読み取り可能な入力、プロジェクトのコンテキスト、実行可能な証拠、アクションの境界、コード作成前の計画を確立します。

第二層では、Skills、Subagents、Evalsを追加し、ポリシーを再利用可能にし、検証をより独立させ、設定を回帰テストできるようにします。第三層では、これらの機能をRequirements & designとPR reviewに組み込みます。第四層で、ようやく非対話型のCI/CDとClosing the loopに進みます。

原則は単純です。まずエージェントが局所的なタスクで信頼できる証拠を残せることを証明してから、より長い実行時間を与えます。まず境界が迂回できないことを証明してから、より多くのツールと権限を与えます。本番の異常の自動修正から直接始めることは、意図、テスト、承認、権限、ロールバックの前提をすべてスキップすることになります。

このガイドが証明していないこと、そしてチームがどう始めるか

このプレイブックは実用的ですが、ベンダーの主張に埋もれてはいけない三つの限界があります。

第一に、青写真は効果の証拠ではありません。原文では、サイクルタイム、自己チェック後の初回CI通過率、PRレビュー、DORA、インシデント再発率を確認することを推奨していますが、顧客の前後比較は公開されていません。チームは自社のパイロットデータで検証する必要があります。

第二に、追跡可能性はコンプライアンスを意味しません。GitとPRは記録を残せますが、信頼できる監査には、本人確認、迂回不能な権限、事実源のマッピング、ログの保持、職務分離、組織の承認も必要です。

第三に、決定性は正しさを意味しません。Hookは書き込まれたルールを安定して実行し、CIは既存のテストを安定して実行します。ルールやテストの設計が間違っていれば、システムは誤った判断をより確実に実行するだけです。インシデントは、テスト、eval、Skill、権限ポリシーを修正するきっかけとなる必要があります。

したがって、六つのフェーズをカバーする大規模なプラットフォームを最初に構築しないでください。コピー修正、内部の小規模ツール、または既に成熟したテストがある部分的なバグなど、リスクが低く、頻度が高く、検証が容易な変更を一つ選び、以下の四つのステップを実行します。

受け入れ時に、エージェントがどれだけのコードを書いたかを尋ねるのではなく、意図の受け入れからPRまでのリードタイム、エージェントの自己チェック後の最初のCI合格率、人間のレビュー時間とやり直しの回数、マージ後のエスケープ欠陥やロールバックの回数を確認します。リードタイムが短縮され、品質とレビュー負担が悪化していなければ、タスクの範囲、並行セッション、権限を徐々に増やします。

このガイド全体は、最終的に三つの質問に集約できます。各フェーズでどのような証拠を残すのか、どの境界が迂回できないのか、最終的な判断に誰が責任を持つのか。まず一つの変更を完全に、検証可能に、追跡可能な形でPRまで進め、それからループ全体を自律的に動かすことを考えます。