SREの積み重ねが AI駆動開発のガードレールになった ― 7つの実践 2026.07.10 SRE Next KDDIアジャイル開発センター　北浦 智也 

自己紹介 北浦 智也（@kitta0108） KDDIアジャイル開発センター リードSRE 勉強会の運営 JAWS-UG SRE支部 JAWS-UG コンテナ支部 NRUG SRE支部 Observability Conf Tokyo 著書 俺たちのSREとNew Relic KAG Tech Book Vol1 SRE Magazine（物理版） 2 

What is リードSRE? 3 

今日お伝えしたいこと 背景：AIがコードを高速に生成する時代、 開発者の注力ポイントは 「コードを書くこと」 から 「AIの出力を検証し、安全に届けること」 へ移った そこで今日お伝えしたいのは—— SREで積み重ねてきたプラクティスが、 そのままAI駆動開発の「ガードレール」になる 私たちのチームで試行錯誤しながら続けている 7つの実践 を、 一つの事例として紹介します 4 

7つの実践 ― 全体像 # 実践 役割 1 仕様駆動開発（OpenSpec） AIへのインプット品質向上 2 受け入れ試験 デプロイ後の仕様準拠確認 3 リグレッションテスト 既存APIの後方互換性 4 k6 + ECS Fargate性能試験 非機能要件の検証 5 JIT-PAM 本番アクセスの時限制御 6 ボーイスカウトルール 触れたコードを来たときより良くして返す 7 モブプログラミングとレビュー チーム全員での理解と意思決定 ※ バックエンドAPIサービスの開発で培った実践です ※ 今日は土台となる 第1章（仕様駆動開発）を中心に お話しします 5 

第1章　仕様駆動開発（OpenSpec） 6 

基本姿勢 ― AIは「増幅器」である AIは与えられたものを増幅する装置であって、ゼロから正解を当てる装置ではない 増幅する元（目的・制約・仕様）が存在しなければ、出力は ギャンブル になる 出力がギャンブルだと、改善ができない だからこそ、正しく増幅させるもの＝仕様をしっかり作り込む 7 

仕様駆動開発 ― 認知を実装より先に固定する 本来の開発は 認知（考える）→ 実装（書く） の順 AI時代はこれが 実装 → 認知 に逆転しがち （AIが先に書き、人間が後から理解する） 仕様駆動開発（Spec-Driven Development）は、 増幅の元となる認知を 実装より先に固定する ためのプロセス 8 

仕様駆動開発のフロー ― 「認知が先」の構造を作る 曖昧で抽象度の高い要件 ↓ 優先度の高いものを【人間】が決める 仕様の作成 ―― AIの力を借りながら【人間】が作る ↓ 実装 ―――― 【AI】が実装する ↓ レビュー ――― 【人間】がレビューし、【AI】もレビューする ↓ テスト ―――― 【AI】が各種テストを実行し、【人間】が監督する ↓ デリバリー レビューの進め方については 第7章 で触れます 9 

OpenSpecとは ― 「変更」と「現行仕様」を分けて管理 人間が判断した意図を、AIに蒸留させたかった → それを Specというドキュメントとして残す OpenSpec を採用 openspec/ ├── changes/ ← 進行中の変更提案（proposal / design / tasks / spec差分） └── specs/ ← 現行仕様。変更のアーカイブ時に差分が反映され、育っていく 過去の判断に更新があれば specs/ も追従する → 常に現実と一致した 「生きたドキュメント」 が育つ https://github.com/Fission-AI/openspec 10 

仕様の作成 ― AIとの壁打ちで要件の解像度を上げる You: ユーザー新規登録機能を作りたい AI : 認証方式はどうしますか？ ［メール+パスワード ／ OAuth ／ パスキー ／ 自由入力］ You: メール+パスワードで。後でOAuthも足せる構造に AI : 想定流量と許容レイテンシは？ ［書き込み系APIと同じ 10tps・p95 2秒 ／ 参照系APIと同じ 2,000tps・p95 100ms ／ 自由入力］ You: 書き込み系APIと同じで AI : では要件を整理します → 要件1: ユーザーを新規登録する... AIが 一度に1つずつ質問 し、目的・制約・成功基準を引き出す 揃ってから仕様を生成する ─ HOW（実装方法）はこの段階では書かない ※ superpowers:brainstorming から着想を得たスキルをOpenSpecに導入して実現 https://github.com/obra/superpowers 11 

ガードレールは実行計画のなかで作り上げる 実行計画は単なるコーディング作業のリストではなく、 開発から本番リリースまでの工程を定義 1. 受入試験項目作成（開発開始前） 2. ローカル開発（機能実装 + 監視・アラート設定） 3. DEV環境デプロイ・各種テストの作成 4. STG環境デプロイ・受入テスト・リグレッションテスト 5. STG環境での正常性確認・性能試験 6. 人間が読む用のドキュメント更新 7. PRD環境デプロイ準備 8. PRD環境デプロイ・正常性確認 実行計画そのものが、テストや監視を飛ばした近道を防ぐ ガードレール さらにその工程の中で、受入試験・各種テスト・監視という ガードレールの実装 も進んでいく 12 

第2章　受け入れ試験 13 

デプロイされた環境で仕様を検証する ユニットテストだけでは不十分 AIが生成したコードがユニットテストをすべてパスしていても、 インフラ設定やデプロイ構成の問題で動かないケースがある 受け入れ試験 = デプロイされた環境に実際のリクエストを送り仕様準拠を確認 コーディングの前に受け入れ試験を設計する 要件の受け入れ基準: 「登録リクエストを受け付けた場合、一意なユーザーIDを 自動生成し、ユーザー情報を永続化すること」 ↓ 受け入れ試験項目に変換 試験項目ID: AT-001 期待結果: HTTP 201, userId: UUID v4形式, createdAt: ISO 8601形式 14 

TypeScriptで自動化する試験 受け入れ試験は、可能な範囲で TypeScriptのテストコード として実装 正常系 ― 応答・ログ・データの三点で「正常」を定義 APIを叩くと 期待どおりのレスポンス が返る（HTTP 200/201、仕様への準拠） 正常系のアプリケーションログ が出力される DBに 期待値どおりのレコード が追加される リクエストで再現できる異常系 も自動化 認証エラー（401） 、バリデーションエラー（400）など 15 

環境の異常系は、AIによるマニュアル操作で試験する 例：DBに接続するための権限を 一時的に剥奪 し、 期待どおりの振る舞いをするかを確認 受け入れ試験はのちに、リグレッションテストとして 必ず回り続ける仕組み に流用される（→ 第3章） → コストが高く、環境に影響を与える試験は その仕組みに残さない 方針 → マニュアル操作で行う。ただし、操作を実施するのはAI 16 

受け入れ試験実行用のSkillを自前実装 以前は、マニュアル操作の試験は 人間の手で 行っていた 実行が単調になり、AIに任せられる領域まで仕上がった と判断して実行をAIに移譲 Claude Codeの /goal （ゴールを与えると達成まで自律的に動く機能）を 上手に使ってくれる、受け入れ試験実行用のSkill を自前で実装 試験項目をゴールとして与えると、AIが環境操作・実行・確認まで進める 実行結果は 人間が読むためのMarkdown として出力される 実行したコマンド・そのレスポンス・結果の判定などが記述されたレポート 人間はそのレポートを確認して判断する 17 

第3章　リグレッションテスト 18 

受け入れ試験がそのままリグレッションテストになる 機能Aの受け入れ試験 → 機能B開発時の回帰検証に 機能が増えるたびにテストコードが積み重なり、テストの守備範囲が自然と広がっていく { "scripts": { "regression:dev": "npm-run-all --parallel test:acceptance:*:dev", "regression:stg": "run-s test:acceptance:*:stg" } } DEVは並列実行 ― 開発中は素早いフィードバックを優先 （各試験が異なるリソースを対象なので干渉しない） STGは直列実行 ― CIで回すので時間をかけてよい 並列だとどこで失敗したか分かりづらくなるため、失敗箇所の特定しやすさ を優先 Drizzleでテストデータを 冪等に自動投入 19 

CI/CDパイプラインへの組み込み STGデプロイ完了後、GitHub Actionsからリグレッションテストを自動実行 name: Regression Test (STG) on: workflow_run: workflows: ["Deploy to STG"] types: [completed] jobs: regression: if: ${{ github.event.workflow_run.conclusion == 'success' }} runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: pnpm/action-setup@v4 - uses: actions/setup-node@v4 - run: pnpm install --frozen-lockfile - run: pnpm run regression:stg env: API_KEY: ${{ secrets.STG_API_KEY }} BASE_URL: ${{ secrets.STG_BASE_URL }} 20 

テスト種別と守備範囲 テスト種別 検証範囲 ユニットテスト コンポーネント内部の振る舞い 受け入れ試験 単一APIの仕様準拠 リグレッションテスト 既存APIの後方互換性 3層のテストでAI生成コードの品質を担保 21 

第4章　k6 + ECS Fargateによる性能試験 22 

非機能要件を「テスト可能」にする 「2,000TPSを5分間、p95で100ms以内で応答する」は、 検証する手段がなければ単なる願望 export const options = { scenarios: { users_get: { executor: 'constant-arrival-rate', rate: 2000, // 2,000リクエスト/秒 timeUnit: '1s', duration: '5m', preAllocatedVUs: 200, maxVUs: 400, }, }, thresholds: { 'http_req_duration{scenario:users_get}': ['p(95)<100'], 'http_req_failed{scenario:users_get}': ['rate<0.001'], }, }; Requirementsの性能要件を k6の閾値としてコード化 23 

ECS Fargate実行基盤とGitHub Actionsトリガー ローカルマシンからの実行 → ネットワーク環境で結果がばらつく ECS Fargate上のk6コンテナ → 再現性のある実行環境 API レスポンスタイム閾値 エラーレート閾値 想定TPS 書き込み系API p95 < 2,000ms < 1% 10 非同期処理API p95 < 500ms < 0.1% 100 参照系API p95 < 100ms < 0.1% 2,000 GitHub Actions workflow_dispatch で ワンクリック実行 シナリオ・実行時間・TPSをUI上で選択 チームの誰でも性能試験を実行できる状態を作る 24 

25 

第5章　JIT-PAMによる本番アクセス制御 26 

本番環境へのアクセスをどう管理するか AI駆動開発で開発速度が上がる → デプロイ頻度も高くなる しかし本番環境への常時アクセスはセキュリティリスク Claude Code使用時に 意図せず本番リソースを操作してしまう可能性 「AIの力を抑える」のではなく 「安全な境界を明確にしてAIの力を引き出す」 本番環境が確実に守られていれば、 開発環境やSTG環境では AIに思い切り力を発揮させることができる 27 

GitHub Actions + IAM Trust Policyによる時限制御 JIT-PAM = 「必要なときに、必要な時間だけ」本番アクセスを許可 AWSの IAM Trust Policy に有効期限付きの条件を動的に追加する仕組み 開発者: workflow_dispatchでアクセス要求（15〜720分） ↓ GitHub Actions: Environment Protection Rulesで管理者承認を要求 ↓ 管理者: 承認 or 却下 ↓ 承認された場合のみ Trust Policy更新 → 時限的アクセス開始 28 

自動失効する仕組み: DateLessThan条件 { "Condition": { "DateLessThan": { "aws:CurrentTime": "2026-03-20T18:00:00Z" }, "Bool": { "aws:MultiFactorAuthPresent": "true" } } } DateLessThan により、指定時刻を過ぎると 自動的にアクセス拒否 手動での取り消し不要 → 取り消し忘れリスクを排除 MFA必須条件で認証強度も確保 29 

第6章　ボーイスカウトルール 30 

ボーイスカウトルール ― 来たときより良くして返す 「触れたコードを、来たときより少し良くして返す」という古くからのプラクティス 以前は「直したいが、今やると本題が進まない」と積み残されがちだった AI駆動開発でこれが変わった → 改善コストが激減し、 「見つけた瞬間に直す」が現実的になった 31 

見つけた瞬間が、いちばん安く直せる あるべきではない実装の改修コストは、時間が経つほど大きくなる → だったら、見つけた瞬間に直してしまえばいい 「少し良くして返す」にとどまらず、割と大きい改修もその場で行う 改善事項を積んで、計画して、優先度を決める…その 管理コストの方が高くつく モブでのレビュー中に気づいたら、その場でAIに指示して直す 対象はコードに限らない テストコード・仕様（specs/） ・ドキュメント・AIへの指示書まで、触れたものすべて 32 

安心して直せるのは、ガードレールがあるから 受け入れ試験・リグレッションテストがあるので、壊れればすぐ分かる（→ 第2・3章） → 怖がらずに直せる 綺麗に保たれたコードは、AIが読む 「増幅の元」 になる（→ 第1章） → 生成の精度が上がり、次の改善もさらに楽になる 小さな改善を回すほど、ガードレールとAIの精度が両方育っていく 33 

第7章　モブプログラミングとレビュー 34 

コードを書くのはAI、人間は理解と意思決定に集中 ドライバー（AIとの対話を進める人）とナビゲーター（方向性を決める人） ただし コードを書くのはAI メンバー全員が 議論と判断に集中 ドライバーは「その領域の理解に一番自信がない人」の立候補制 「やれる人」よりも「やるべき人」を優先する価値観 ナビゲーターの議論を咀嚼してプロンプトに落とし込む = 最も学習効果が高い チーム全体の知識の偏りを減らす 35 

プルリクエストを廃止 レビューは、AI駆動開発において 最も大事にしている工程 しかし非同期で行うプルリクエストは、 膨大な出力をレビューするのに適さない と判断した モブの中で どのような指示 を投げたのか その指示によって どのような結果 が返ってきたのか を リアルタイムでレビュー することが大事 36 

チーム全体への共有は、毎日の定例で 開発タスクが完了したら、 10:00の朝会 または 13:00のリファインメント（毎日実施）で やったことを情報共有する モブの外のメンバーにも、この場で共有される仕組み その中のフィードバックで修正が計画されることもある 37 

まとめ 38 

ガードレールが増えるほど、AIに任せられる範囲が広がる 仕様 でAIのインプットを整え テスト でアウトプットを検証し JIT-PAM で安全な境界を作る モブプログラミング で判断をチーム全員で行う ガードレール 効果 仕様駆動開発 AIに正しい方向を示す 受け入れ試験 + リグレッションテスト AIの出力を多層的に検証 k6性能試験基盤 非機能要件を「願望」から「検証済み」に JIT-PAM AIの力を安全に引き出す境界を作る ボーイスカウトルール 触れたコードを来たときより良くして返す モブプログラミングとレビュー 理解と意思決定にチーム全員で集中 39 

最後に AIの性能は日々進化するが、 それを活かせるかどうかは、周りの仕組み次第 SREとして積み重ねてきたプラクティスが、 AI駆動開発の文脈でその価値を一層増している 私たちの試行錯誤が、 皆さまのチームにとって何かのヒントになれば嬉しいです 40 

最後にちょっとだけ宣伝 来週月曜日から「KAG AI Week」が始まります！ 一週間、毎日12:00〜13:00のお昼時間に、 KAGのメンバーがAIに関わることを発信するお祭り 最終日には 高輪ゲートウェイでの現地開催 もあり ご興味のある方は 「KAG AI Week」で検索 してください！ 41 

42