■ 1. 発表の背景と主旨
- 発表者: KDDIアジャイル開発センター リードSRE 北浦智也（@kitta0108）
- 背景: AIがコードを高速生成する時代において、開発者の注力ポイントが「コードを書くこと」から「AIの出力を検証し、安全に届けること」へ移行した
- 主旨: SREとして積み重ねてきたプラクティスが、そのままAI駆動開発の「ガードレール」になる
- 対象: バックエンドAPIサービスの開発で培った7つの実践を事例として紹介
■ 2. 7つの実践: 全体像
- 実践一覧:
- 第1章: 仕様駆動開発（OpenSpec）― AIへのインプット品質向上
- 第2章: 受け入れ試験 ― デプロイ後の仕様準拠確認
- 第3章: リグレッションテスト ― 既存APIの後方互換性
- 第4章: k6 + ECS Fargate性能試験 ― 非機能要件の検証
- 第5章: JIT-PAM ― 本番アクセスの時限制御
- 第6章: ボーイスカウトルール ― 触れたコードを来たときより良くして返す
- 第7章: モブプログラミングとレビュー ― チーム全員での理解と意思決定
■ 3. 第1章: 仕様駆動開発（OpenSpec）
- AIに対する基本姿勢:
- AIは与えられたものを増幅する装置であり、ゼロから正解を当てる装置ではない
- 増幅する元（目的・制約・仕様）が存在しなければ、出力はギャンブルになる
- 出力がギャンブルだと改善ができないため、正しく増幅させる仕様を作り込む必要がある
- 仕様駆動開発（Spec-Driven Development）の目的:
- 本来の開発は「認知（考える）→ 実装（書く）」の順だが、AI時代は「実装→認知」に逆転しがち
- 増幅の元となる認知を実装より先に固定するためのプロセスが仕様駆動開発である
- 仕様駆動開発のフロー:
- 曖昧で抽象度の高い要件から、優先度の高いものを人間が決める
- AIの力を借りながら人間が仕様を作成する
- AIが実装する
- 人間がレビューし、AIもレビューする
- AIが各種テストを実行し、人間が監督する
- デリバリー
- OpenSpecの構造:
- 人間が判断した意図をAIに蒸留させ、Specというドキュメントとして残す仕組み
changes/: 進行中の変更提案（proposal / design / tasks / spec差分）specs/: 現行仕様。変更のアーカイブ時に差分が反映され、育っていく- 過去の判断に更新があれば
specs/も追従し、常に現実と一致した「生きたドキュメント」が育つ- 仕様作成の手法:
- AIが一度に1つずつ質問し、目的・制約・成功基準を引き出す
- 情報が揃ってから仕様を生成する（HOW（実装方法）はこの段階では書かない）
superpowers:brainstormingから着想を得たスキルをOpenSpecに導入して実現- 実行計画によるガードレール:
- 実行計画は単なるコーディング作業リストではなく、開発から本番リリースまでの工程を定義する
- 工程の例: 受入試験項目作成（開発開始前）→ ローカル開発（機能実装 + 監視・アラート設定）→ DEV環境デプロイ・各種テスト作成 → STG環境デプロイ・受入テスト・リグレッションテスト → STG環境での正常性確認・性能試験 → ドキュメント更新 → PRD環境デプロイ準備 → PRD環境デプロイ・正常性確認
- 実行計画そのものが、テストや監視を飛ばした近道を防ぐガードレールとなる
■ 4. 第2章: 受け入れ試験
- ユニットテストだけでは不十分な理由:
- AIが生成したコードがユニットテストをすべてパスしていても、インフラ設定やデプロイ構成の問題で動かないケースがある
- 受け入れ試験の定義: デプロイされた環境に実際のリクエストを送り仕様準拠を確認すること
- 受け入れ試験の設計タイミング: コーディングの前に設計する
- 要件の受け入れ基準を受け入れ試験項目（試験項目ID・期待結果）に変換する
- TypeScriptによる自動化の範囲:
- 正常系: APIレスポンス（HTTP 200/201、仕様準拠）、正常系アプリケーションログ、DBへの期待値どおりのレコード追加を三点で検証
- リクエストで再現できる異常系（認証エラー401、バリデーションエラー400など）も自動化
- 環境の異常系の試験方法:
- DB接続権限を一時的に剥奪するなど、環境に影響を与える試験はリグレッションテストの仕組みに残さない方針
- マニュアル操作で行うが、操作を実施するのはAI
- 受け入れ試験実行用Skillの自前実装:
- 以前は人間の手でマニュアル操作を行っていたが、AIに任せられる領域まで仕上がったと判断して実行をAIに移譲
- Claude Codeの
/goal（ゴールを与えると達成まで自律的に動く機能）を活用する受け入れ試験実行用Skillを自前実装- 試験項目をゴールとして与えるとAIが環境操作・実行・確認まで進める
- 実行結果は人間が読むためのMarkdown（実行コマンド・レスポンス・結果判定を記述したレポート）として出力される
■ 5. 第3章: リグレッションテスト
- 受け入れ試験とリグレッションテストの関係:
- 機能Aの受け入れ試験が機能B開発時の回帰検証に転用される
- 機能が増えるたびにテストコードが積み重なり、テストの守備範囲が自然と広がる
- 実行方式の使い分け:
- DEV環境: 並列実行（開発中は素早いフィードバックを優先、各試験が異なるリソースを対象なので干渉しない）
- STG環境: 直列実行（CIで回すので時間をかけてよい、失敗箇所の特定しやすさを優先）
- Drizzleでテストデータを冪等に自動投入
- CI/CDパイプラインへの組み込み: STGデプロイ完了後、GitHub Actionsからリグレッションテストを自動実行
- テスト種別と守備範囲の整理:
- ユニットテスト: コンポーネント内部の振る舞い
- 受け入れ試験: 単一APIの仕様準拠
- リグレッションテスト: 既存APIの後方互換性
- 3層のテストでAI生成コードの品質を担保する
■ 6. 第4章: k6 + ECS Fargate性能試験
- 非機能要件をテスト可能にする考え方:
- 「2,000TPSを5分間、p95で100ms以内で応答する」は検証する手段がなければ単なる願望
- 性能要件をk6の閾値としてコード化する
- 実行基盤:
- ローカルマシンからの実行はネットワーク環境で結果がばらつく
- ECS Fargate上のk6コンテナにより再現性のある実行環境を実現
- API種別ごとの閾値設定:
- 書き込み系API: p95 < 2,000ms、エラーレート < 1%、想定TPS 10
- 非同期処理API: p95 < 500ms、エラーレート < 0.1%、想定TPS 100
- 参照系API: p95 < 100ms、エラーレート < 0.1%、想定TPS 2,000
- 実行フロー:
- GitHub Actions の
workflow_dispatchでワンクリック実行（シナリオ・実行時間・TPSをUI上で選択）- 開発者がk6シナリオファイルを作成・コミット → GitHub UIでワークフロー実行をトリガー → ECS Fargateでk6コンテナが実行 → 結果JSONをS3にアップロードし、Slackに通知 → 開発者が結果をダウンロードして分析
- チームの誰でも性能試験を実行できる状態を作る
■ 7. 第5章: JIT-PAMによる本番アクセス制御
- 課題の背景:
- AI駆動開発で開発速度が上がるとデプロイ頻度も高くなる
- 本番環境への常時アクセスはセキュリティリスクであり、Claude Code使用時に意図せず本番リソースを操作してしまう可能性がある
- 基本方針: 「AIの力を抑える」のではなく「安全な境界を明確にしてAIの力を引き出す」
- 本番環境が確実に守られていれば、開発環境やSTG環境ではAIに思い切り力を発揮させることができる
- JIT-PAMの仕組み:
- 「必要なときに、必要な時間だけ」本番アクセスを許可する
- AWSのIAM Trust Policyに有効期限付きの条件を動的に追加する
- 開発者がworkflow_dispatchでアクセス要求（15〜720分）
- GitHub ActionsのEnvironment Protection Rulesで管理者承認を要求
- 管理者が承認した場合のみTrust Policyを更新し、時限的アクセスを開始
- 自動失効の仕組み:
DateLessThan条件により指定時刻を過ぎると自動的にアクセス拒否- 手動での取り消し不要により取り消し忘れリスクを排除
- MFA必須条件で認証強度も確保
■ 8. 第6章: ボーイスカウトルール
- ボーイスカウトルールの定義: 「触れたコードを来たときより少し良くして返す」という古くからのプラクティス
- AI駆動開発での変化:
- 以前は「直したいが今やると本題が進まない」と積み残されがちだった
- AI駆動開発により改善コストが激減し、「見つけた瞬間に直す」が現実的になった
- 実践方針:
- あるべきではない実装の改修コストは時間が経つほど大きくなるため、見つけた瞬間に直す
- 「少し良くして返す」にとどまらず、割と大きい改修もその場で行う
- 改善事項を積んで計画し優先度を決める管理コストの方が高くつく
- モブでのレビュー中に気づいたら、その場でAIに指示して直す
- 対象範囲: コードに限らず、テストコード・仕様（specs/）・ドキュメント・AIへの指示書まで、触れたものすべて
- ガードレールとの相乗効果:
- 受け入れ試験・リグレッションテストがあるので壊れればすぐ分かり、怖がらずに直せる
- 綺麗に保たれたコードはAIが読む「増幅の元」になるため生成の精度が上がる
- 小さな改善を回すほどガードレールとAIの精度が両方育っていく
■ 9. 第7章: モブプログラミングとレビュー
- 役割分担:
- ドライバー: AIとの対話を進める人
- ナビゲーター: 方向性を決める人
- コードを書くのはAIであり、メンバー全員が議論と判断に集中する
- ドライバーの選出方針:
- 「その領域の理解に一番自信がない人」の立候補制
- 「やれる人」よりも「やるべき人」を優先する価値観
- ナビゲーターの議論を咀嚼してプロンプトに落とし込むことが最も学習効果が高い
- チーム全体の知識の偏りを減らす効果がある
- プルリクエストを廃止:
- レビューはAI駆動開発において最も大事にしている工程
- 非同期で行うプルリクエストは膨大な出力をレビューするのに適さないと判断
- モブの中でどのような指示を投げたのか、その指示によってどのような結果が返ってきたのかをリアルタイムでレビューすることが重要
- チーム全体への情報共有:
- 開発タスク完了後、10:00の朝会または13:00のリファインメント（毎日実施）でやったことを情報共有する
- モブの外のメンバーにも共有される仕組みであり、フィードバックで修正が計画されることもある
■ 10. まとめ
- ガードレールが増えるほどAIに任せられる範囲が広がる
- 各ガードレールの効果:
- 仕様駆動開発: AIに正しい方向を示す
- 受け入れ試験 + リグレッションテスト: AIの出力を多層的に検証
- k6性能試験基盤: 非機能要件を「願望」から「検証済み」に変える
- JIT-PAM: AIの力を安全に引き出す境界を作る
- ボーイスカウトルール: 触れたコードを来たときより良くして返す
- モブプログラミングとレビュー: 理解と意思決定にチーム全員で集中する
- AIの性能は日々進化するが、それを活かせるかどうかは周りの仕組み次第であり、SREとして積み重ねてきたプラクティスがAI駆動開発の文脈でその価値を一層増している