【20260326 AI×DevOpsStudy #9】AI駆動開発で人事管理アプリの作成をした話 × ClaudeCode SKILLs & Rules

■AI×DevOps Study #9 の概要
2026年3月26日に開催した「AI×DevOps Study」第9回の勉強会資料です。

「AI×DevOps Study」は、AI駆動開発やそこに関係するマイクロサービスについて理解を深める場になります。
株式会社ScalarではAIを使ったチーム開発を進めており、参画しているメンバーや協力会社の方から、具体的なAI駆動開発を実施する方法、その中で生まれたマイクロサービスアーキテクチャを使用したAI駆動開発の事例や実際に使えるエージェントについてお話頂き、参加者の皆様と知識の共有や交換を目的としています。
（弊社製品であるScalarDBも絡んだお話も一部出てきますが、汎用的な内容となっておりますのでフラットにお楽しみいいただけます）

■今回のテーマ
「AI駆動開発で作成したアプリを効率的にデプロイ・運用するインフラの仕組み」

AI駆動開発（AIDD）の普及により、アプリ開発のスピードは飛躍的に向上しています。しかしその一方で、「マイクロサービスの爆発的な増加」「複数データベース間のデータ整合性」「手動では追いつかないデプロイ・運用」という新たな課題が生まれています。

本勉強会では、こうした課題を解決するために構築したインフラ基盤を解説します。

具体的には、GitLab CI／ArgoCD による全自動デプロイ、Blue/Green デプロイによるゼロダウンタイムリリース、Kong Gateway・Keycloak・HashiCorp Vault によるセキュリティ基盤、そして Loki・Tempo・Grafana を活用した可観測性スタックを取り上げます。

■登壇者情報（敬称略）
岩崎
株式会社ラクスパートナーズ クラウドエンジニア。異業界の営業職を経て、2025年7月よりエンジニアとしてのキャリアをスタートし、エンジニア歴8ヶ月。現在は株式会社Scalarにて、ScalarDBをCI/CDパイプラインに組み込んだクラウドインフラ構築テンプレートの開発に従事している。GitLabを活用した自動化の実践を通じ、ScalarDBの導入をより円滑にするための最適なアーキテクチャ設計と運用の効率化を探求中。

樋口
株式会社ラクスパートナーズ クラウドエンジニア。株式会社ラクスパートナーズ クラウドエンジニア。異業界の看護師を経て、AIの可能性に惹かれてこの世界に飛び込みました。2025年10月よりエンジニアとしてのキャリアをスタートし、エンジニア歴5ヶ月。現在は監視スタックを中心にクラウドインフラ構築テンプレートの開発を行っています。わからないことだらけの中でも、「なぜこの仕組みが必要なのか」を大切にしながら日々探求しています。

■関連コンテンツ
Youtube
www.youtube.com/@scalar-labs

Zenn ブログ
https://zenn.dev/p/scalar_sol_blog

Transcript

1. AIDDで作ったアプリを効率的に デプロイ‧運⽤するインフラの仕組み
2. 2 ⾃⼰紹介 岩崎 准⽮ (Junya Iwasaki) 株式会社ラクスパートナーズ所属 / 株式会社Scalar アサイン中 エンジニア歴 8ヶ月。 去年の 11月から株式会社 Scalar様にSESという形でアサイン 、ScalarDBを CI/CDパイプラインに組み込んだクラウドインフラ構築テンプレートの開発に従事している。 樋⼝ 亜美 (Ami Higuchi) 株式会社ラクスパートナーズ所属 / 株式会社Scalar アサイン中 エンジニア歴 5ヶ月。 今年の 1月から株式会社 Scalar様にSESという形でアサイン 、現在は監視スタックを 中心にクラウドインフラ構築テンプレートの開発を行っています。
3. 3 アジェンダ 01 AI駆動開発（ AIDD）の課題 速さがもたらす 5 つのリスク 02 AI駆動開発（ AIDD）のためのインフラストラクチャ なぜこのアーキテクチャを作ったのか 03 AIDD のためのインフラ詳細 テスト・セキュリティ・デプロイ・コスト・可観測性 04 まとめ AI開発時代の運用最適化基盤
4. AI駆動開発（AIDD）の課題 4
5. AI駆動開発（AIDD）の Pros/Cons Pros 5 Cons コードが高速に生成される ⇒数ヶ月かかる開発が、数日になることも デプロイ頻度が激増する ⇒1日何十本もデプロイが発生する システムの機能維持が難しくなる ⇒AIは完成した機能をまるごと書き直す 大規模なシステムでは統合が失敗することが多い ⇒コンテキストサイズを超える修正は難しい AI駆動開発（ AIDD: AI Driven Development）を従来型の開発プロセスに載せて効率化させることは難しい AIDDを前提とした新しい開発プロセスと、インフラが求められている 機能を独立性を維持した状態で実装し、高速かつ安全にデプロイし、 機能を効率的に統合できるインフラが求められている
6. AI駆動開発（AIDD）でよく起きる問題 6 変更してはいけないコードや設定を変更する ゴールを達成するために、”ズル”をする • 認証が通らないので、認証機能を外す • 動くように見せかけるモックでごまかす • 処理を通すために、呼び出し先を変更してしまう 脆弱性のあるライブラリを取り込む モデルが学習した時点の情報を使うと古いライブラリが取り 込まれます。この際、脆弱性のある古いライブラリを取り込 んだりします。 効率の悪いコードを出力してしまう AIは必ずしも効率の良いコードを出力するとは限りません。 このため、出力したコードが非効率なものだったりすることが あります。このため、パフォーマンスやコスト効率が悪いこと があります。 異常系を正しく処理しないコードを出力してしまう 障害やエラーを考慮したコードを出力させるためには、指示 者が細かく障害やエラーなどの処理方法を網羅的に指示す る必要があります。 「高速な開発とデプロイと高品質なシステムの実現」 を実現するためには、 AIでの実装以外の仕組みをインフラを構築し、AIが生成したコードの品質をモニタリングし、 効率的に運用できる仕組みを構築する必要があります。
7. AIDDでは、開発プロセスの発想を変える必要がある 7 要件定義 設計 開発 テスト リリース 要件定義/設計 開発・テスト リリース 従来型の開発 AI駆動型の開発 開発・テストを 高速に実行する 機能設計 実装 テスト レビュー E2E 機能設計 実装 テスト レビュー マイクロサービスごとに並列実装 機能設計を⼈がしっかりレビューし、設計に基づい た実装とテストを、AIエージェントに任せること で、⾼速にシステム開発が⾏える。 ただし、以下の仕組みを構築しておく必要がある。 • 機能設計に最も時間をかけて、詳細化してお くことで、以後を⾃動化できる。 • AIエージェントが想定外の機能を破壊しない 仕組みにする。 • レビューエージェントを多⾓的に作り込んで おき、早い段階で問題点を潰しこむ。 • AIエージェントが並列実装できるように、 アーキテクチャを設計し、⾼速に実装とテス トを⾏えるようにする。 • AIが実装したコードの安全性や効率性を評価 できるプラットフォームを⽤意する。
8. 機能の独⽴性を担保する 8 ユーザー管理 認証 注文管理 在庫管理 ユーザー管理 認証 注文管理 在庫管理 AI Agent AI Agent モノリス/モジュラーモノリス マイクロサービス 対象のコード以外も修正してしまう リスクがある。また、コンテキスト が大きくなるため、コード全体が破 壊される可能性が高くなる。 対象のマイクロサービスのみに注目して 修正が行われる。コンテキストも小さく なるため、コード全体が破壊されるリス クが小さく、テストも高速に行える。 AI Agent 機能が独立してお り、並行して高速 に開発することが できる。 観測 マイクロサービス 単位で観測するこ とができる 観測 大きな機能単位で の観測になり、ボ トルネックを見つ けにくい。
9. マイクロサービスの実装の注意点 9 強整合性パターン 結果整合性パターン データ伝播 コレオグラフィ オーケストレーション 分散合意 同一DB内の トランザクション処理 Sagaパターンでの実装の注意点 • ビジネスプロセスを理解し、中間状態が見えてしまう ことを考慮して実装する必要がある。 • べき等性の担保を行う必要がある。 • 処理が中断した際のリカバリロジックをすべてのパ ターンで実装する必要がある。 • 障害パターンをすべて実装する必要がある。 ScalarDBで実装が容易になる 同一DB内トランザクション処理の場合の注意点 • トランザクションを呼び出す部分の依存関係が強く残 り、機能の独立性を損なうためなるべく避ける必要が ある。 分散合意の場合の注意点 • XAを使う場合、繋がるサービスで同じRDBMSを利用 する必要がある。NoSQLなどは利用できない。 ⇒ ScalarDBは上記問題を解決することができる
10. AIDDでの開発のポイント 10 アーキテクチャ設計と機能設計に時間をかける 機能の独立性を考慮した設計を行い、重複機能を持たせない AIエージェントが自律的に開発できるような仕組みを構築する 自己評価ができる仕組み作りと、並列実装・並列テストを行えるようにする 単体テスト、 E2EテストをCI/CDのパイプラインに組み込む 実装した機能が壊れないように、CI/CDにテストをきっちり組み込んでおく セキュリティ診断、依存分析は、 AIエージェントと役割を分ける セキュリティ診断は、AIによるレビューだけでなくインフラでも行う AIDDで開発したアプリケーションの運用を効率化するインフラを用意する 効率的に運用しやすい基盤を先に作っておくことで運用を最適化しておく 高速な開発とデプロイ と 高品質なシステムの実現 • AI主体の開発 • 品質の自動保証 • 安全性の担保 • 機能の独立性 • デプロイの独立性 • 高コスト効率 • 非機能の担保 本⽇のテーマ
11. AI駆動開発（AIDD）のための インフラストラクチャ 11
12. 12 なぜこのインフラを作ったのか — 課題×ツール対応マップ AIDDで起きる課題と、それを解決するインフラコンポーネントの対応関係 テスト テスト漏れ・品質の劣化 > 既存機能が壊れても気づかない → GitLab Coverage Test セキュリティ セキュリティ脆弱性の混入 > 古いライブラリ・認証バイパスが発生 → SAST /DAST /Dependency Scan /Secret（Vault）/Kong Gateway /Keycloak コスト コストが見えない・爆発する > AIが意図しないサイズでリソースを生 成、サービス量増加 → OpenCost / OpenMeter デプロイ デプロイが怖い・追跡できない > 誰が何をデプロイしたか不明になる → ArgoCD (GitOps) / Blue/Green / Backstage 監視 本番障害時に原因が見えない > 調査できず復旧に時間がかかる → Loki / Tempo / prometheus / Grafana ※ Kong はセキュリティ・可観測性も兼務（横断インフラ）
13. AI駆動開発によるインフラアーキテクチャ Managed Database IT資産の管理 Internal Developer Portal （Backstage.io） Code 管理 （GitLab） CI/CD 単体テスト （GitLab Coverage Test） セキュリティテスト （GitLab SAST） 依存関係スキャン （GitLab Dependency Scan） AI駆動開発 （Claude Code） コンテナ・デリバリー （ArgoCD） Kubernetes Platform（EKS/AKS/GKE, etc） ScalarDB API Gateway（Kong） API Gateway（Kong） Grafana Loki Tempo Prometheus OpenCost API API API API API API IAM（OIDC/SSO） Secret（Vault） Policy Application Plane Control Plane
14. 14 AIDDのための インフラ詳細
15. 15 テスト‧セキュリティ 品質の安定化 GitLab Coverage Test SAST /DAST /Dependency Scan /Secret（Vault）/Kong Gateway /Keycloak
16. 16 GitLab CI ─ コードを品質チェックして自動ビルド 1 2 Code Coverage（テストカバレッジ） テストがコードの何 %をカバーしているか測定。品質の目安。 3 4 DAST 動作中のアプリに実際に攻撃を試みて、外から見た脆弱性を検出。 SASTで見つけられない実行時の問題を発見。 SAST（セキュリティスキャン） コードに脆弱性がないか AIが自動チェック。早期発見が大事。 Dependency Scan アプリが使用しているライブラリに既知の脆弱性がないか自動 チェック。古いライブラリの混入を防ぐ。
19. 19 HashiCorp Vault 　HashiCorp Vault 秘密情報（パスワード、APIキーなど）を安全に保管・配布する金庫ツール。 【役割】 • Key Management（暗号鍵の管理） • Transit Secrets Engine（データを暗号化して送る） • AES256-GCM / DEK管理（暗号化アルゴリズムの管理）
20. 20 Kong Gateway Kong Gateway = 全てのAPIリクエストが最初に通る「門番」。 2つのゲートウェイが役割を分担している。 Kong Gateway ①（外向き） • CorrelationId発行（リクエスト＝1ID） • TLS終端（HTTPS→HTTP変換） • Rate Limiting（過剰アクセス防止） • /api/ → BFF へルーティング • JWT検証（本物のトークンか確認） Kong Gateway ②（内向き） • hrm-user-service へルーティング • Proxy Cache（社員名簿を最大10分キャッシュ） • OpenMeter へAPI使用量を送信 • X-Correlation-ID を転送
21. 21 Keycloak ─ ログインをまるごと管理 Keycloak = 「ログイン機能をアプリに作らなくていい」にするための認証基盤。 OIDC（OpenID Connect）という標準プロトコルを使う。 ROLE_ADMIN 全機能アクセス可能。システム管理者向け。 ROLE_INTERNAL 社内ユーザー。通常業務の機能が使える。 ROLE_EXTERNAL 外部（取引先など）。限定的な機能のみ。 認証フロー: ユーザー → Keycloak（ログイン） → SessionId発行 → hrm-frontend → API呼び出し
22. 22 デプロイ リリースの効率化 ArgoCD (GitOps) / Blue/Green / Backstage
23. 23 ArgoCD ─ GitOps で全自動デプロイ ArgoCD = GitリポジトリをSSoT（唯一の正解）として、 Kubernetes の状態を自動で合わせ続けるツール GitOps とは？ ─ 「設定ファイルを Gitで管理し、変更があれば自動適用する」運用スタイル Dev K8s (On-demand) 開発中のテスト 必要な時だけ起動 Test K8s (E2E) E2Eテスト 本番同等の環境 Staging K8s (Spot) リリース前確認 コスト削減Spot使用 Production K8s (Blue/Green) 本番環境 ゼロダウンタイム デプロイ
26. 26 Blue/Green デプロイ ─ ゼロダウンタイム 新バージョンを「別の環境（ Green）」に用意し、問題なければ一瞬で切り替える手法。 Blue（現行バージョン） 現在ユーザーが使っている v1.0 のアプリ 安定稼働中 Green（新バージョン） テスト済みの v2.0 を用意 確認完了したら 一瞬で切り替え！ 切り替え ←→
27. 27 Backstage ─ 全サービスの地図帳 マイクロサービスが増えると「どんなサービスがあるか」わからなくなる。 Backstage = 全サービスの情報を1か所に集めた「開発者ポータル」。 Service Catalog 全マイクロサービスの一覧・説明・オーナー情報を管理。「この APIは誰が担当？」がわかる。 catalog-info.yaml サービスの情報を定義するファイル。 Gitに置くだけで自動的にカタログに登録される。 APIドキュメント連携 OpenAPI Spec（APIの仕様書）と連携。Backstage からそのままAPIの使い方を確認できる。
28. 28 コスト コストの最適化 OpenCost / OpenMeter
29. 2 9 OpenMeter & OpenCost で見える化　 KEDA & Karpenter で最適化 AIDDでサービスが増えると、クラウドコストも爆発しやすい。 「どのサービスがいくら使っているか」を常に把握しなければならない。  OpenMeter API の「使⽤量」を計測‧追跡する ツール。 Kong Gateway から使⽤量データを 受け取り、 「誰がどのAPIをどれだけ使った か」を記録。 将来的にAPI従量課⾦なども可能。 　 OpenCost Kubernetes のPod（サービス）単位 でクラウドコストを可視化するツー ル。 「このサービス、⽉いくらかかって る？」が Grafana ダッシュボードでわ かる。 無駄なリソースを削減しやすくなる。 KEDA‧Karpenter KEDA：キュー（処理待ちの行列）に溜まっ たメッセージ数や APIリクエスト数など、細 かい条件でPodを増減させる。 Karpenter：必要なPodのサイズに合わせ て、最適なサイズのサーバー（ノード）を自 動で選んで増減させる。 オートスケーリングによるコストの最適化。
32. 32 監視 品質の安定化 Loki / Tempo / prometheus / Grafana
33. 33 可観測性スタック ─ 何が起きているか「見える」ようにする 可観測性（Observability）= 「システムの内部状態を外から把握できる」こと。3本柱で実現。 📋 Loki ログ集約 全サービスのログを一か所に集める。 CorrelationIDで操作の詳細追跡をする。 🔍 Tempo 分散トレーシング 「このリクエストがどのサービスを通ったか」を可視化。ボトルネックや遅延の原因を すぐ特定できる。 📊 Grafana 統合ダッシュボード Loki・Tempo・OpenCost 等のデータを1画面で確認。ログとトレースを同時に見ながらト ラブルシューティング。
34. 34 Correlation ID（相関ID）─ リクエストを⼀本の⽷でつなぐ マイクロサービスでは、 1つのリクエストが複数のサービスを渡り歩く。 Correlation ID= 全サービスを通る「共通の番号タグ」。 👤 ユーザー ブラウザから操作 → 🚪 Kong GW CorrelationId=001 を生成・付与 → 🔄 BFF （Backend For Frontend） ID=001 を そのまま転送 → 🔀 Kong GW ID=001 を 転送 → ⚙ User Service ID=001 で ログ記録 障害時の活用例 Loki（ログ検索ツール）で「X-Kong-Request-ID=001」を検索すると、 全サービスの処理履歴が追跡できる。どこで失敗したかのトラブルシューティングが容易になる。
35. 35 OpenTelemetry Trace ID ー処理の「時間」と「経路」 KongからアプリA、アプリBと移動するごとに、通信にかかった時間（ミリ秒単位）を計測。 👤 ユーザー ブラウザから操作 → 🚪 Kong GW Trace ID=abc を発行 ここからタイマー計測ス タート⏱ → 🔄 BFF Trace ID=abc 処理時間：50ms → 🔀 User Service Trace ID=abc 処理時間：500ms → 🔐 ScalarDB (DB) Trace ID=abc 処理時間：20ms 障害時の活用例 Tempo（分散トレースツール）で「Trace ID=abc」を検索すると、 各サービスの処理時間が「ガントチャート（階段状のグラフ）」で可視化される。 ログには出ない「エラーはないけど、ただ遅い」という原因（ボトルネック）が一目でわかる。
39. 39 ScalarDB AIDD でアプリが増えても、データ整合性の担保とDB管理の複雑さを解消する ① ACID トランザクション 複数 DB をまたいでも整合性を⾃動保証 → AI が⽣成したコードでも安全に動く ② DB管理の複雑さの解消 バラバラなDBでも統⼀的に扱える 引っ越しはエンドポイントを繋ぎ直すだけ アプリはDBの種類を意識しなくていい POS の ScalarDB namespace の使⽤⽅法 ScalarDB が解決すること
40. 40 Kubernetes─ サービスを管理する Kubernetes（K8s）= コンテナ（Dockerの箱）を⼤量に管理‧⾃動復旧するプラットフォーム。 AIDDで爆発的に増えるサービスを「ほぼ⾃動で」動かし続けてくれる。 🔁 ⾃動復旧（Self-healing） サービスが落ちたら⾃動で再起動。 📈 ⾃動スケーリング（HPA） アクセスが増えたら⾃動でサービスを増 やし、減ったら減らす。コスト最適化に も貢献。（KEDA・Karpenter） 📦 ローリングアップデート 順番に新バージョンに切り替えるた め、ダウンタイムなしでアップデート できる。 負荷‧性能試験 Chaos Test：わざと障害を起こし、自動復旧するか確認。 Load Test：1000人の同時アクセス等を再現。 Performance：レスポンスが何秒以内に返るか確認。 Scaling：HPAが正しく動くか確認。 → k6・ChaosMonkeyでテストする
41. 41 デプロイパイプライン全体フロー — コードから本番まで AIが書いたコードが本番に届くまでの時間軸と各環境でのゲート AI並列開発 (マイクロサービス) 開発中 ▶ GitLab CI 〜1時間 ▶ Dev/Test 環境 2〜3時間 ▶ Staging 環境 数日〜 ▶ 本番 Blue/Green 即時切替 CI フェーズ（GitLab → ArgoCD） MR作成 → カバレッジ / SAST / Dependency Scan → Review → Merge → CD起動 Test環境（2〜3時間/サービス） UT / E2E / DAST → Security Scan → 結果レポート Staging環境（Daily / Weekly） Chaos Test / Load Test / Performance / Scaling確認 → Blue/Green切り替え → 本番
42. まとめ
43. 43 まとめ AIDD で多量にアプリを届け続けるために、3つを最初から整える ① 品質 AIが作っても ⼈間が責任を持てる状態 • 誰が何を作ったかわかる • 変更が追跡できる • テストが自動で走る • 共通機能は一か所で管理 Backstage / GitLab Keycloak / ScalarDB GitLab CI（SAST・カバレッジ） ② ケイデンス MRをマージするだけで 毎⽇本番にリリースできる状態 • Dev→Test→Stg→Prodが自動 • 切り戻しがいつでもできる • 負荷・カオステストで耐久確認 • 障害が起きたら即座に原因がわかる ArgoCD / Blue-Green Prometheus / Loki / Tempo k6 / ChaosMonkey → Grafana ③ コストマネジメント コストが⾒えるから スケールできる状態 • Infra コストを namespace単位で把握 • API使用量・収益を可視化 • スケーリングを自動最適化 OpenCost / Karpenter / KEDA OpenMeter / Kong Grafana
44. 44 今後の展望 現在地 インフラの設計をやり直し中 今⽇話した 品質‧ケイデンス‧コスト の3つを担保できる設計に作り直している ① 設計完了 テンプレートとして完成させる アプリを乗せるだけで 品質‧ケイデンス‧コストが 最初から⾃動で回る状態 → MRをマージするだけで本番に届く ② アプリを乗せる 3つの軸が実際に機能するか検証 負荷テストを実施し、 監視から実際に数値で確認‧耐久性や性能 を改善する → 数値で品質‧コストを証明する ③ 展開 テンプレートを他プロジェクトへ パラメータを変えるだけで 新しいプロジェ クトのインフラが⽴つ → ゼロから設計‧実装する必要がない、横 展開できる → →
45. GitHub scalar-labs/scalardb connpass Scalar Please give us a star on GitHub! AIxDevOps Study 毎週⽕曜開催