Aioright Technologies
AI・生成AI

AI時代の開発手法 実践 Anthropic AI-Native SDLC playbook

AnthropicのAI-Native SDLCを、フロントエンド・バックエンドを開発するチームを例に、成果物・Human Gate・検証・CI/CDまでわかりやすく具体化します。

公開日 著者 Aioright Technologies
紫と紺のグラデーションを使用した共通イメージ

Anthropicが2026年8月に公開したThe AI-Native SDLC playbookは、ソフトウェア開発をPlan（計画）・Design（設計）・Build（実装）・Test（テスト）・Deploy（デプロイ）・Maintain（保守）の6段階で捉え直し、各段階へAIを組み込む方法を提示しています。

AI-Native SDLCは、AIに開発を一任する手法ではなく、人・AIの双方が読める成果物を工程間で引き継ぎ、定型作業をAIへ移しながら、要件の承認・本番デプロイなどの重要な意思決定を人間が担う開発プロセスだとされています。

本記事では原典の考え方を、フロントエンドとバックエンドを独立したリポジトリで開発し、REST APIで連携するプロジェクトへ適用します。フレームワーク、認証方式、ビルドツール、データベース、監視製品などは固定せず、各プロジェクトの既存の構成を維持する前提とします。

対象プロジェクトの前提

項目前提
ステークホルダービジネス部門、デザイン部門、エンジニア、開発部門マネージャー
プロジェクト管理JIRA
ソース管理・レビューGitHub
SDLC成果物の共有AI-Native SDLC用共通リポジトリ
UIデザインFigma
コミュニケーションSlack
クラウドAWS
CI/CDAWS CodePipeline
フロントエンドWebフロントエンド（1リポジトリ）
バックエンドREST API（1リポジトリ）

目的は、AI導入のために新しい工程を大量に追加することではありません。まずは必要最小限の成果物と人間による承認（Human Gate）から始め、効果を確認できた作業から自動化します。

成果物で開発工程を繋ぐ

工程間の引き継ぎを会議やチャットだけで行わず、後続工程がそのまま利用できる成果物として残します。

JIRA
  ↓
intent.md
  ↓
spec.md ←→ Figma
  ↓
フロントエンド plan.md / バックエンド plan.md
  ↓
コード + テスト + 検証証跡
  ↓
Pull Request（PR、GitHub）
  ↓
CodePipeline（AWS） / ステージング環境
  ↓
本番環境
  ↓
監視 / フィードバック
  └────────────→ JIRA / 次のintent.md

主要な成果物は次のとおりです。

成果物問い主な内容主な承認者
intent.md何を実現するか、なぜ実現するのか問題、対象ユーザー、価値、範囲、制約、成功条件ビジネス部門
spec.mdシステムが何を提供するか受入条件、画面・APIの振る舞い、例外、非機能、セキュリティビジネス・デザイン・エンジニア
plan.mdどう実装するか変更対象、作業順序、テスト、影響、リスクエンジニア
コード・テスト計画をどう実現したか実装、テスト、必要なドキュメントエンジニア
検証証跡何を根拠に完了とするか実行コマンド、終了コード、結果、未検証事項エンジニア

intent.md、spec.md、plan.mdは、粒度だけを変えて同じ内容を繰り返す文書ではありません。それぞれが異なる問いに答えることで、ビジネス要求と実装の対応関係を追跡できるようにします。

正本（Source of Truth）を決める

JIRA、GitHub、Figma、Slackへ同じ情報を複製すると、どれが正か分からなくなります。情報の種類ごとに正本を一つ決める必要があります。

以下はAnthropicの原典を基に、本記事のプロジェクト前提に合わせて具体化した例です。使用するツールや成果物の保管場所については、個々のプロジェクトに合わせて検討してください。

情報正本
優先順位、担当者、ステータス、期限JIRA
intent.md、spec.md共通リポジトリ（project-sdlc）
plan.mdフロントエンド・バックエンド各リポジトリ
UIデザインFigma
API契約プロジェクトで定めた一つのAPI定義
ソースコード、PR、レビュー証跡GitHub
CI/CDの状態CodePipeline
本番状態AWS・監視基盤

運用原則は、本文はGit、状態はJIRAとします。Slackは通知、相談、障害時の初動に使用しますが、仕様の正本にはしません。Slackで決まったAPIの挙動や例外処理は、必ずspec.mdやAPI契約へ反映します。

STEP 0：Foundationを整える

案件ごとの開発を始める前に、フロントエンドとバックエンドの両方でAIが安全に作業できる土台を整備します。

リポジトリごとにCLAUDE.mdを作る

CLAUDE.mdには、Claudeがそのリポジトリで作業する度に従うべき、プロジェクト固有の指示を記載します。

  • ビルド、テスト、Lintの正確な実行方法と成功条件
  • コードの配置や依存方向に関する重要な規則
  • リポジトリ固有のコーディング規約
  • 編集不可のファイル、領域
  • 認証・認可、ログ、機密情報の取り扱いに関する規則
  • 完了報告前に実行する検証作業

一般的なプログラミングの知識や一度だけ行う指示は含めないようにします。AIが同じ誤りを繰り返したとき、その再発防止に必要となる規則を追加します。また、内容が古くなるとAIが誤る恐れがあるため、CLAUDE.mdもコードと同様にPRで更新し、内容を現在の運用に合わせます。CLAUDE.mdの詳細については、Claude Code公式ドキュメントを参照してください。

検証コマンドを一本化する

AIが自分の作業を検証できるよう、プロジェクト標準の検証方法を用意します。

./scripts/verify.sh

内部で実行する処理は既存構成に合わせます。

  • フロントエンド: ビルド、Type Check、Lint、Unit Test、必要なUIテスト
  • バックエンド: ビルド、Unit Test、Integration Test、静的解析
  • 共通: 依存関係や、シークレットの取り扱いなど既存のセキュリティ検査

成功時は終了コード0、失敗時は0以外とし、AIと人間が同じ基準で検証できることが重要です。

GitHubと本番環境の強制機構を設定する

少なくともmainブランチには、GitHubのブランチ保護（Branch Protection）を設定し、PR、CI成功、人間によるレビューを必須とします。本番デプロイにはCodePipelineの手動承認（Manual Approval）を使用し、AI用の権限と本番デプロイ実行用の権限を分離します。

STEP 1：JIRAからintent.mdを作る

新しい機能や改善要求が発生したら、最初にJIRAチケットを起票します。JIRAには優先度とステータスを置き、詳細な要求は共通リポジトリproject-sdlcのintent.mdへ分離します。

JIRA: PRJ-123
  ↓
project-sdlc/intent/PRJ-123.md

intent.mdには実装方法を書かず、次の内容を明確にします。

  • 現在の問題と影響を受ける利用者
  • 望ましい状態とビジネス上の価値
  • 対象範囲と対象外（スコープ）
  • 制約
  • 成功条件
  • 未解決の論点

AIにはintent.mdのドラフト作成を依頼します。その際、技術的な実装方法を定めず、情報が不足している点を推測で補わないよう指示します。不明点は「未解決の論点」として残します。

PRJ-123についてintent.mdのドラフトを作成してください。

現在の問題、対象ユーザー、望ましい状態、ビジネス上の価値、
対象範囲、対象外、制約、成功条件、未解決の論点を整理してください。

技術的な実装方法は決めず、判断できない点は未解決の論点として残してください。

AIが出力したintent.mdは、まだ承認前のドラフトです。起票者とビジネス部門が内容を確認し、問題、対象範囲、制約、成功条件が意図どおりに整理されていることを承認してから、spec.mdの作成へ進みます。

STEP 2：spec.mdとFigmaを並行して具体化する

承認済みのintent.mdから、AIがspec.mdのドラフトを作成します。UI変更がある場合は、同じintent.mdを基にFigmaのドラフト作成も進めます。

intent.md
  ├────────────┐
  ↓            ↓
specドラフト  Figmaドラフト
  └──────┬─────┘
         ↓
  spec.mdを承認

spec.mdでは、実装ファイルやクラス構成ではなく、システムの振る舞いを定義します。

  • スコープとユーザーストーリー
  • 受入条件
  • 正常、ローディング、空、エラーなどのUI状態
  • APIの入出力とエラー時の振る舞い
  • 認証・認可
  • 性能、可用性、セキュリティ、ログ、監視などの非機能要件
  • 未解決事項と対象外
承認済みintent.mdを読み、spec.mdのドラフトを作成してください。

受入条件、UI上必要な状態、APIの振る舞い、エラー処理、
認証・認可、非機能要件、セキュリティ、ログ・監視を含めてください。

実装ファイルやコード構成はまだ決めず、矛盾や判断できない点は
懸念事項として明示してください。

ビジネス部門は「intent.mdを満たすか」、デザイン部門は「UXとして成立するか」、エンジニアは「技術的に実現可能か」を確認します。認証・認可、個人情報、DB構造、外部公開API、AWS構成などを変更する場合は、開発部門マネージャーも承認者へ加えます。

STEP 3：フロントエンドとバックエンドのplan.mdをそれぞれ作成する

承認済みのintent.mdとspec.mdはproject-sdlcで管理し、フロントエンドとバックエンドの双方から参照します。plan.mdは各リポジトリのコード・アーキテクチャに基づくため、フロントエンドとバックエンドで別々に作成します。

project-sdlc/
├── intent/PRJ-123.md
└── spec/PRJ-123.md

frontend/
├── CLAUDE.md
└── docs/plans/PRJ-123.md

backend/
├── CLAUDE.md
└── docs/plans/PRJ-123.md

Plan Mode（計画モード）など、コードを変更せずにリポジトリを調査できる方法で実装計画を作成します。

PRJ-123のintent.mdとspec.mdを読み、このリポジトリの
実装計画を作成してください。

変更対象、新規作成対象、作業順序、必要なテスト、既存機能への影響、
リスク、完了を証明する方法を含めてください。

まだコードは変更しないでください。

エンジニアは、実装内容、既存機能への影響、リスクを確認します。AIとの会話を見ていない別のエンジニアが「plan.mdだけで実装できるか」が、承認の指標となります。

後工程の実装作業中にファイル分割やテスト追加が必要になった場合は、plan.mdと実装を同時に更新します。一方で、DB構造、認証方式、インフラ構成、利用ライブラリ、セキュリティ境界を変更する場合は実装を中止し、plan.mdを再度承認します。

API契約を一つに保って並行開発する

フロントエンドとバックエンドが別リポジトリの場合、両者を繋ぐAPI契約の二重管理を避ける必要があります。

                API Contract
                /          \
               /            \
            REST API     Webフロントエンド

既にOpenAPIなどのドキュメントが存在する場合は、その既存定義を正本にします。OpenAPIを使っていないプロジェクトへ、本プレイブックのためだけに導入する必要はありませんが、次の内容はフロントエンドとバックエンドが同じ定義を参照できるようにします。

  • エンドポイントとHTTPメソッド
  • リクエストとレスポンス
  • エラー形式
  • 認証・認可
  • 後方互換性

API契約が確定すれば、バックエンドの完成を待たず、モックを使用してフロントエンドを並行開発できます。

STEP 4：承認済みplan.mdに基づいて実装する

実装時は、AIへspec.md、対象リポジトリのplan.md、CLAUDE.mdを読ませます。

承認済みのspec.mdとplan.mdに従って実装してください。

CLAUDE.mdと関連するSkillを遵守し、作業を論理的な単位に分けてください。
各単位の完了後に影響するテストを実行してください。

未計画の重要変更が必要になった場合は、実装を止めて報告してください。

フロントエンドとバックエンドがそれぞれ異なるファイルを変更する場合は、別セッションやGit worktreeで並行化できます。一方、同じファイルや同じAPI契約を同時に変更するケースでは、一つのセッションで順番に進めます。詳しくはClaude Codeの並列実行に関する公式ドキュメントを参照してください。

なお、並列数を増やすこと自体はKPIとせず、人間が計画と差分を確認できる量を上限にします。

STEP 5：実行結果を検証証跡として残す

AIから「テストしました」という報告を受け取るだけでは、完了の証跡と言えないため、実際に実行したコマンド、終了コード、結果を記録します。

- 実行したコマンド
- 終了コード
- ビルド・テスト結果
- spec.mdとの差異
- plan.mdとの差異
- 未検証事項
- 最終判定：成功 / 失敗 / 未検証

バグ修正は再現テストから始める

再現可能な不具合は、次の順序で修正します。

再現テストを追加
  ↓
期待した理由で失敗することを確認
  ↓
実装を修正
  ↓
同じテストが成功することを確認

再現テストで失敗することを確認し、実装コードを修正します。同じ再現テストが成功すれば、不具合が解消されたことを確認できます。

UIはFigmaと実表示を比較する

UI変更ではコードだけでなく、ブラウザ上の表示を確認します。正常、ローディング、空、エラー、レスポンシブ、アクセシビリティを対象とし、Figma、実装、スクリーンショットを比較します。

自動的な画像差分テストは後から追加できるため、初期段階では、人間とAIが実表示をFigmaと比較し、差分を記録する方法でも問題ありません。

STEP 6：AIと人間でレビューを分担する

PRには、JIRA、intent.md、spec.md、plan.md、Figma、変更内容、リスク、検証結果へのリンクを含めます。これにより、レビュー担当者はコード差分だけでなく、変更の理由と承認済みの計画まで遡ることができます。

AIによるレビューは下記の観点で行います。

  • 正しさと境界値
  • セキュリティ
  • 既存機能への回帰リスク
  • spec.mdの受入条件への適合
  • plan.mdと実装の差異

Formatter、import順序、単純なLintなどは各種ツールへ任せます。軽微な指摘を大量に生成させず、利用者、データ、セキュリティ、主要機能へ影響する問題を優先します。

人間によるレビューでは、次の点を重点的に確認します。

  • intent.mdを満たしているか
  • アーキテクチャとして妥当か
  • 高リスクなコードを受容できるか
  • テスト内容が仕様を証明しているか
  • AIレビューの重大指摘へ対応できているか
  • plan.mdからの逸脱に合理的な理由があるか

AIがレビューしたPRをAIの判断だけでマージ可能とせず、ブランチ保護でコードオーナーなどの承認を必須にします。

STEP 7：CodePipelineからステージング環境、本番環境へ進める

mainへのマージをCodePipelineのトリガーとします。CI/CDでは、ビルド、テスト、静的解析など、成功・失敗をあらかじめ定めた基準で自動的に判定できる処理を実行します。

GitHub
  ↓
CodePipeline
  ↓
ビルド
  ↓
静的解析 / セキュリティチェック
  ↓
テスト
  ↓
ステージング環境へデプロイ
  ↓
スモーク / 統合 / E2Eテスト
  ↓
手動承認
  ↓
本番環境

ステージング環境では、エンジニアがSmoke Test、API Integration、エラー処理を確認します。UI変更があればデザイン部門がFigmaとの差異やレスポンシブ表示を確認し、ビジネス部門が受入条件を確認します。変更に関係しない担当者まで一律に承認者へ加える必要はありません。

フロントエンドとバックエンドのリリース時点が異なる場合は、APIを可能な限り後方互換にし、（多くの場合）バックエンド、フロントエンドの順にデプロイします。

バックエンドをデプロイ
  ↓
バックエンドをステージング環境で確認
  ↓
フロントエンドをデプロイ
  ↓
フロントエンドをステージング環境で確認
  ↓
本番デプロイ前の承認

本番環境反映の最終承認は人間が行います。AIへの指示やHookだけを本番環境のセキュリティ境界にせず、AWS IAMとCodePipelineの手動承認で強制します。

STEP 8：監視結果を次のintent.mdへ戻す

本番リリースを開発の終了とせず、メトリクス、ログ、問い合わせ、ユーザーのフィードバックを次の改善へ繋げます。

本番環境
  ↓
メトリクス / ログ / ユーザーのフィードバック
  ↓
問題
  ↓
JIRA
  ↓
intent.md

初期段階では、人間が監視結果や問い合わせを判断してJIRAを起票すれば十分です。運用が成熟した後は、異常を検知し、AIがログや関連コードを調査してintent.mdのドラフトを作る構成へ拡張できます。

自動化した場合も、AIが本番環境を無制限に操作できる状態にはしません。読み取り専用の調査、PRの作成、事前承認された手順（Runbook）の実行など、リスクに応じて許可する操作を限定します。

Skills、Hooks、Evals、Subagentsは段階的に導入する

AI-Native SDLCを始めるために、すべての自動化機能を最初から導入する必要はありません。

レベル導入するもの
最低限intent.md、spec.md、plan.md、CLAUDE.md、検証コマンド、PR、ブランチ保護、本番デプロイ前の人間による承認
標準Skills、AIによるレビュー、軽量なHooks、UI検証、API契約チェック、worktreeによる並行作業
拡張Evals、Subagents、MCP連携、CI/CD内の非対話AI、障害一次調査、監視からのintent.md生成

Skillsは、セキュリティ基準やAPI設計、コーディング規則など、毎回の作業で同じように適用する規約に使用します。リポジトリ固有の情報はCLAUDE.md、一度だけ使う指示はプロンプトに記載します。

Hooksは、保護対象ファイルの編集拒否、フォーマッティング、シークレット検出など、AIの操作前後に「条件・内容をあらかじめ定めた」処理を行う場合に利用します。ただし、重要な制御をHookだけに依存させないように注意する必要があります。

Evalsは、モデル、CLAUDE.md、Skills、Hooksを変更したときに、AIの作業品質が低下していないかを検査します。Subagentsは検証や調査など、繰り返し発生する限定作業へ適用します。

ガードレールはリスクに応じて強くする

ガードレールには強度の違いがあります。

AIへの個別指示
  ↓
CLAUDE.md / Skills
  ↓
Hooks
  ↓
CI
  ↓
GitHubのブランチ保護
  ↓
AWS IAM / CodePipelineの手動承認

例えば、自動生成ファイルの編集禁止はCLAUDE.md、Hook、CIを組み合わせます。mainへの直接push禁止はブランチ保護、本番環境への無断デプロイ禁止はAWS IAMとCodePipelineの手動承認で強制します。

プロンプトはAIの判断を誘導できますが、必ず守られるセキュリティ境界ではありません。影響が大きい制御ほど、AIの判断に依存しない強制機構でも担保します。

完了の定義（Definition of Done）と効果測定

各プロセスを完了と判断する条件を、チームで共通化します。「承認済み」・「確認済み」とするだけでなく、何を確認すれば完了と判断できるかまで定めます。

項目完了条件（例）
JIRA対象チケットに成果物、PR、検証結果へのリンクがあり、現在の工程に合わせてステータスが更新されている
intent.md内容をビジネス部門が確認し、承認履歴が残っている
spec.md受入条件とシステムの振る舞いを各関係者が確認し、承認履歴が残っている
UIデザインデザイン担当者が実装着手可能と判断した記録が残っている
plan.md変更対象、テスト、影響、リスクを確認したplan.mdがあり、承認履歴が残っている
実装plan.mdに記載した変更が反映され、計画との差異がある場合はplan.mdまたはPRに理由が記録されている
検証変更に応じた標準検証コマンドが終了コード0で完了し、UI変更がある場合は必要な表示確認の結果が記録されている
レビュー人間によるPR承認があり、未解決の重大な指摘が残っていない
CIブランチ保護で必須としたすべてのCheckが成功している
ステージング環境必要なテストとspec.mdの受入条件を確認し、結果が記録されている
本番環境CodePipelineで人間による承認を経てデプロイが成功し、重大な異常がない
追跡可能性JIRAからintent.md、spec.md、plan.md、PR、検証結果、デプロイ結果を辿れる

導入効果はAIが生成したコード量ではなく、品質を維持したまま、企画から本番リリースまでの時間（リードタイム）と人間の待ち時間を減らせたかで測定します。

  • intent.mdから本番リリースまでのリードタイム
  • 初回CI成功率
  • PRのレビュー所要時間
  • 仕様やplan.mdへの手戻り回数
  • 本番環境変更失敗率

指標を工程別に確認すると、AIによって実装が速くなった結果、仕様策定、レビュー、ステージング環境など別の工程が新しいボトルネックになっていないか判断できます。

実践の要点

フロントエンドとバックエンドを別々に開発するプロジェクトでは、次の情報の流れを維持することが中心になります。

intent.md
  ↓
spec.md + Figma
  ↓
フロントエンド plan.md / バックエンド plan.md
  ↓
共有するAPI契約
  ↓
コード + テスト + 検証証跡
  ↓
AIによるレビュー + 人間によるレビュー
  ↓
ステージング環境 + 本番デプロイ前の人間による承認
  ↓
フィードバック

AIには「情報整理、草案、実装、テスト、調査、機械的なレビュー」を任せ、人間は「目的、優先順位、重要な設計、リスク受容、本番デプロイ」を判断します。各工程で「誰が判断し、何を証拠として次へ進んだか」を追跡できることが、実践する上での要点です。

さらに具体的な開発プロセスが知りたい、AI活用方法を自社に合わせて整理したい場合は、セキュリティ・ITコンサルティングでご相談いただけます。

参照資料

関連するサービス・ご相談

コンサルティングを見る セキュリティサービスを見る お問い合わせ