【20260206 AI×DevOpsStudy #4】AI駆動で構築する_AI駆動開発のためのマイクロサービスCI_CD基盤の作り方

■AI×DevOps Study #4 の概要
2026年2月06日に開催した「AI×DevOps Study」第4回のアーカイブ動画です。

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

■今回のテーマ
「AI駆動で構築する、AI駆動開発のためのマイクロサービスCI/CD基盤の作り方」

【背景と課題】
マイクロサービスアーキテクチャの採用において、Kubernetes（K8s）を中心としたコンテナ環境と、堅牢なCI/CDパイプラインの構築は不可欠です。しかし、K8s特有の学習コストの高さや設定の複雑さは、多くのエンジニア、特に経験の浅い層にとって大きな参入障壁となっています。また、AWS、Google Cloud、Azureなど、異なるクラウド間で同様の環境を再現・維持することも容易ではありません。

【AIによる解決策】
本セッションでは、生成AIを「熟練のインフラエンジニア」のようなパートナーとして活用し、これらの課題を突破する手法を解説します。AIを活用することで、複雑なマニフェスト作成やパイプライン定義を自動化・標準化し、深い専門知識がなくとも高度な基盤を構築できることを示します。

【使っている技術】
GitLab.
Terraform.
Ansible.
AWS, Azure, GCP.
AntiGravity + Terraform MCP.

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

■勉強会動画
AI駆動で構築する、AI駆動開発のためのマイクロサービスCI/CD基盤の作り方【20260206 AI×DevOpsStudy #4】
https://youtu.be/pDaqmLa1onI?si=q4hJwSL53oVZ6d9I

Transcript

1. AI駆動で構築する、AI駆動開発のための マイクロサービスCI/CD基盤の作り⽅ 2026/2/6 ラクスパートナーズ 岩崎
2. 2 岩崎 准⽮ (Junya Iwasaki) 株式会社ラクスパートナーズ所属 / 株式会社Scalar アサイン中 ▪ キャリアの歩み：営業からエンジニアへの転⾝ 「知らない」を「仕組み」で補完する 専⾨知識が追いつかない部分は、AI（Gemini/AntiGravity）による 「知識の補助」と、GitLabによる「⾃動的な検証」を徹底して活⽤。 「エンジニア歴が短くても、AIとツールを正しく使いこなせば、ここ まで⾼度なインフラを安全に構築できる」という実体験を共有したい と考えたため。 私のスタンス：IT未経験という特性 なぜこのテーマで登壇するのか 2023.04  2025.05 リユース業界での買取営業 IT業界とは全く無縁の世界で、2年間 接客‧査定業務に従事。 2025.07 株式会社ラクスパートナーズ ⼊社 「未経験」からエンジニアとしてのキャリア をスタート。3ヶ⽉間の集中研修でITの基礎 （NW/Server/Cloud）を習得。 2025.11 - 現在 株式会社Scalarへアサイン 実務初案件として、いきなり「マルチクラウ ドでのKubernetes（K8s）基盤構築」という ミッションに直⾯。 ⾃⼰紹介 (Profile)
3. インフラの概要
4. マルチクラウドでのk8s環境の構築 GitLab Azure - AKS AWS - EKS GCP - GKE クラウドに依存しないデプロイの仕組みを構築するために GitLab Runnerを 使って、開発したアプリケーションを⾃動で各クラウドに展開できるようにする。
5. クラウド⾮依存のデータベースの実現 AWS クラウドのデータベースに依存しないインターフェイスをScalarDBを使って実現 し、どのクラウドでも同じアプリケーションが動作する環境を構築する。 ScalarDB RDS DynamoDB S3 Azure PostgreSQL Cosmos DB GCP PostgreSQL AlloyDB Storage ScalarDB ScalarDB Applications Applications Applications
6. AI駆動開発のためのCI/CD環境の構築 Dev Test Staging 単体テスト （ローカル） 結合テスト ⾮機能テスト （性能、障害） Blue Green 本番環境 ローリング アップデート 切り替え Merge Request ⼿動 ⼿動 AI駆動開発では、ローカルテスト実⾏後、GitLabのコードリポジトリのmain ブランチにマージした後、各環境に順次デプロイし 最後にBlue/Greenを切り替えて本番環境で公開することを⾃動化する。
7. 技術選定の理由と背景
8. 最初の壁：EKS構築における「挫折」の記録 8 成功と新たな懸念 GUIを断念しCLI（eksctl等）で構築に成功したが、それ は「⼿順のブラックボックス化」や「属⼈化」を⽣む⼀ 歩⼿前であると感じた。 実際に触ってみた気づき 「⼿作業による構築は再現性の⽋如を招く」 個⼈のスキルに依存しない、持続可能な仕組みの必要性 を確信した瞬間。
9. ⽐較で⾒えた「クラウド間のハードル」の差 9 クラウド 構築時の所感（初⼼者視点） 共通の課題 AWS (EKS) 設定項⽬が多く、依存関係の理解に 時間がかかる クラウド間の差異（⽅⾔） 各クラウド独⾃の作法をすべて 覚えるのは極めて困難であり 再現性の維持も容易ではない。 GCP (GKE) ⽐較的設定が簡潔で、UIでの構築が スムーズ Azure (AKS) 独⾃の設定体系があり、サイズ選択 等がやや複雑 AWSに比べ、GCPのUIは設定事項が整理されており、手動構築時の「優しさ」に大きな差を感じた。ま た、共通の課題も浮き彫りになった。
10. WHY 01：なぜAIを「パートナー」に選んだのか 10 調査‧環境構築の理解を深める⼀助として ・ 独⼒では数⽇かかるような調査や⼿順の理解を、AIが整理して提⽰してくれることで、学習の質とスピードが向上した。 ‧AIが⽰す正解を元に、公式ドキュメント等で「なぜこうなるのか」を裏取りしながら書き直す学習プロセスが、⾃⾝の知識 定着に寄与した。 「実装のドラフト」としてのAIへの期待 ・ 複雑なマニフェスト（YAML）作成やパイプライン定義をAIが⽀援することで、経験の浅い私でも⾼度な基盤構築の全体像 を把握しやすくなると考えた。 AIとの「対話」を通じた思考の整理 ・エラーメッセージや構成上の悩みについてAIと壁打ちを⾏うことで、問題の切り分けがスムーズになり、構築作業の停滞を 防ぐことができた。
11. WHY 02：なぜGitLabによる「統合管理」が必要か 11 情報の分断を解消 タスク、コード、CI/CD環境がバラバラだと、情報の⾏き 来だけで時間が費やされ、「なぜこの設定にしたのか」 という⽂脈が失われやすい。 Single Source of Truth 企画からセキュリティ、デプロイ、運⽤改善までを⼀つ のプラットフォームで完結させることで、迷いのない開 発体験を⽬指す。 属⼈性の排除と⽇本語化 ⾃分が苦労した⼿順やデバッグの記録をWikiに集約し、 情報を最適化することで、組織的な基盤作りを可能にす る。 チーム開発への布⽯ 単なるツールの統合ではなく、開発の⽂脈をチーム全員 が共有できる状態（透明性）を確保することが重要と考 えた。
12. AI活⽤の裏に潜む「⾒えないリスク」への懸念 12 AIが⽣成するコードの「危うさ」 AIはもっともらしいコードを⽣成するが、そこには設計者の意図に反するミスや、セキュリティ上 の脆弱性が含まれるリスクが常に伴う。 初⼼者の⽬による精査の限界 AIの出⼒スピードに対し、経験の浅いエンジニアが⽬視ですべての不備を⾒抜くことは、現実的に は極めて困難である。 実例としての違和感 不要なバイナリが141MBも含まれそうになる等、AI特有の「おかしな挙動」をどう検知し、制御す るかが⼤きな課題となった。
13. WHY 03：なぜ「⾃動検証」が不可⽋なのか 13 セキュリティの⺠主化 専⾨知識が不⾜している段階でも、スキャン機能が「ガイド役」となることで、意識せずとも安全な コードを書ける⽂化を作りたい。 機械的な「ガードレール」 ⼈間が全量チェックできないのであれば、 GitLabのSAST（静的解析）等を⽤いて、機械 的にリスクを炙り出し、マージ前にブロック する仕組みが必要。 「攻め」を⽀える「守り」 ⾃動チェックという盤⽯な守りがあるからこ そ、AIを使って⾼速に構築するという積極的な 挑戦が可能になる。
14. 14 「専⾨知識を補い、AIを適切に制御しGitLabで守る ことで、より⾼度な基盤構築が可能になる」 ‧技術の難解さを属⼈化で解決するのではなく、AIの⼒を学習と実装の助 けとし、GitLabの⼒で安全性を担保する。 ‧経験の浅いエンジニアであっても、着実に⾼品質なサービス基盤を構築 できるテンプレート開発を⽬指しました。
15. 使⽤した技術 15 • Gemini • GitLab • Terraform • Ansible • AWS, Azure, GCP • AntiGravity + Terraform MCP
16. まとめ：WHYの再定義 16 K8sの難解さ EKS構築での挫折から、個⼈の⼒量に頼らない⾃動化‧ 共通化の必要性を痛感。 AIのポテンシャル 2週間の⼯数を⼀瞬で解決するスピードへの期待と、⼀ ⽅で⽣じる精査の限界。 GitLabの必然性 断⽚化した情報を統合し、機械的な検証で「安⼼」して AIを活⽤するための基盤。 結論 AIとGitLabによる⾃動化の統合が、マルチクラウド環境 におけるK8s運⽤の難所を突破する鍵となる。
17. AIによるインフラ構築の効果
18. AIとのコンテキスト共有：状況を理解させる 18 狙い AIと⾃⾝のスキル‧状況を同期させ、出⼒の不整合を減らす試み。構築作業の開始前に、AI（AntiGravity等）に対して⾃⾝の「詳細な 経歴」や「過去の作業実績‧速度」をインプットしました。
19. 実際に出⼒されたIssue 19
20. エラーの確認とタスク管理 20

21. 作業にかかった時間や 躓いたポイントを フィードバックした結果 全体の⼯数は、 当初から50%削減 ⾒積もり精度も向上 AIと対話し、スキルに 合わせて作業タスクを ⾒積もった上で実施 AIによる⼯数⾒積もりと実際の⼯数 21

22. AIへの制約：⼈間が主導権を握るためのルール 22 「勝⼿に直さない」制約の徹底 エラー発⽣時にAIが独断でコードを修正することを制限し、 必ず⼈間に確認させるガバナンスをプロンプト等で設定した。 具体的な指⽰の内容 狙い AIを⾃律的な動作主体とするのではなく、あくまで ⼈間の管理下にある「設計補助ツール」として機能 させることで、構築のコントロール権の維持を⽬指 す。 修正前に必ず修正箇所と理由を提⽰させる 他リソースや環境（Dev/Stg等）への影響範囲を⾃⼰評価 させる
23. GitLab CI/CDによる「機械的なガードレール」 23 AIが⽣成するコードの量とスピードに対し、⽬視のみで脆弱性を完全に排除するのは困難であるため、GitLabの統合 機能を活⽤し、⼈間による全量チェックの限界を補完した。 SAST（静的解析）を 実⾏し、リスクを 浮き彫りに
24. 初期設定の簡素化：GitLab Managed Stateの活⽤ 24 管理の統合と安全性 インフラの状態（State）をGitLab上で⼀元管理 チーム内での共有が容易 多重実⾏による競合（State Lock）の⾃動防⽌
25. 実例：AIのミスと⼈間の「違和感」 25 「Git Commit時の遅延。通常のコード更新ではあり得ない141MBの増⼤。」 原因の特定 調査の結果、.terraform ディレクトリ内のバイナリ等が 誤ってコミット対象に含まれていたことが判明。 教訓 AIが構成ファイルを⽣成する際、.gitignore の設定漏れ等 の副次的なミスを⾒落とすことがある。ツールに頼り切 らず、最終的な出⼒を⼈間が確認する重要性を再認識し た。
26. 実例：SASTによる脆弱性検知と修正プロセス 26 検知から修正までの推移
27. まとめ：AIによるインフラ構築の効果 27 AIとの並⾛ スキル共有と精緻なIssue定義で⼯数を削減。AIを単なる ⾃⾝のスキルに同期した「パートナー」へ。 ⼈間による統制 「勝⼿に直さない」制約と、⼈間の統制で精度を担保。 AIを⾃律主体にせず、「設計補助ツール」として制御。 仕組みによる防衛 SAST等の機能活⽤で属⼈性を排除。脆弱性を50件から 5件に削減し、仕組みによる安全な構築プロセスを確⽴。 結論 AIを「GitLabによる守り」で⽀えることで、経験の浅い エンジニアでも⾼品質な基盤構築を⾼速に完遂できる。
28. 構築したインフラの仕組み
29. 再現性を⾼めるための反復検証とタイムアタック 29 構築⼿法 所要時間 備考 ⼿動構築 (GUI等) 27分 ⼿順の漏れやミスのリスクが⾼い GitLab CI 化後 18分 約33%の短縮。 再現性が100%担保された状態 結果：初⼼者であっても、安定して成功するまで検証を繰り返すことで、 再現性の⾼い⼿順を確⽴できた。
30. 情報の外部化：Wikiによる知⾒の集約と標準化 30 Wikiに書き留める意義 実体験に基づくトラブルシュート: EKSのノード作 成失敗、Ansibleエラー、証明書設定ミスなど、直 ⾯した課題と解決策を詳細に記録。 ドキュメントの⽇本語化: 公式情報を⾃⾝の⾔葉で まとめ、チームメンバーが迷わず作業できる環境を 整備。 属⼈化の徹底排除: 特定個⼈への依存を減らし、将 来的な教育コストを削減するための「重要な投資」 として位置づけ。 ※Wiki作成の⼯数は、将来のデバッグ時間と教育コストを⼤幅に削減 する先⾏投資になる。
31. 情報の外部化：Wikiによる知⾒の集約と標準化 31
32. 責任の境界線：⼿動承認フローの導⼊ 32 AIに「構築」を任せ、⼈間は「決断」と「責任」を担う。 ガバナンスの維持 承認ステップを設けることで、「誰が‧いつ‧デプ ロイを許可したか」の証跡（Audit Trail）を確実に 残す運⽤を試みている。
33. マルチクラウド共通ワークフローの実現 33 ポータビリティの追求と抽象化 AWS、Azure、GCPへの展開を、同⼀の操作感（共通ワーク フロー）で実⾏できる環境の構築。GitLab CI/CDを司令塔と し、Terraform（インフラ定義）とAnsible（構成管理）を組 み合わせることで、各クラウドの固有設定を抽象化した。 「⽅⾔」を意識させない開発体験 クラウドごとのパラメータの差異はAIで整理。⼈間は「どの クラウドに作るか」を選択するだけで済むワークフローを⽬ 指した。 【共通パイプラインの構成】
34. AWSにおける構築成果：EKS環境の⾼度化 34 初期の挫折を教訓にした安定構築 GUIでの設定ミス（IAMロールやSGの不整合）による失敗経験を反映し、IaCによる再現性を確保。 技術的なブラックボックス化を防ぎ、属⼈性を排除した⼿順を確⽴。 技術的な到達点 効率化の実証 (構築時間⽐較) マネージド型ノードグループ: ⾃⼰管理型からの移⾏によ り、パッチ適⽤等の運⽤管理負荷の低減を図った。 OIDC連携 (IRSA): 静的なアクセスキーを排除。IAMロールの 動的割り当てによるセキュアな最⼩権限管理を実装。
35. GCPにおける構築成果：GKE環境の最適化 35 「分かりやすさ」を活かしたスピード AWSと⽐較して設定項⽬が整理されているGCPの特性を活か し、短期間で構築を完了。UIの親和性を活かしつつ、本質的 なセキュア構成の実装に注⼒した。 実装されたセキュアな構成 AIとの対話で得た知⾒ Autopilotモード特有の制約（NAT要否やリソース制限 等）をAIとの検証で事前に特定。実機での試⾏錯誤を 減らし、構成の適正化を迅速に⾏うことができた。 完全閉域網 (Private Cluster): パブリックIPを持たない ノード構成。Cloud NAT経由の通信に限定。 Cloud KMSの活⽤: データベース等の機密情報の⾃動暗 号化設定を、AIの⽀援を得て短時間で実装。
36. Azureにおける構築成果：AKS独⾃性への対応 36 独⾃仕様の壁とIaCによる解決 ⾃⾝にとって最も難易度が⾼かったAzureにおいても、 Terraformによる⾃動構築を完遂。複雑な設定体系をコード 化することで再現性を担保した。 主な成果 苦労した点と対策 VMサイズの枯渇やDNS設定の要件など、Azure特 有の挙動への対処法をWikiに集約。これにより、 初⼼者でも迷わない再構築フローを維持。 VNet統合: PostgreSQLをVNet内に閉じ、外部から遮断 されたプライベート通信経路を構築。 サービスプリンシパル: 最短スコープの権限で、GitLab CIからAzureへ安全に認証するフローを確⽴。
37. 三⼤クラウド構成図 37 AWS EKS GCP GKE Azure AKS
38. データ層の抽象化：ScalarDBによる共通化 38 インフラ⾮依存のデータ管理の実現 コンテナ基盤（Kubernetes）だけでなく、データベースへのアク セス層まで「ScalarDB Cluster」で抽象化し、マルチクラウド対 応の質を⾼めた。 アプリ開発への集中 アプリ側からクラウド固有のDB SDK（DynamoDB SDK等） を意識せずに開発が可能となるため、コードのポータビリ ティが⼤幅に向上した。 将来的な価値: これにより、将来的な環境移⾏や複数クラウドの併⽤に対 する、実装レベルの障壁を下げることが可能になると考えて いる。 共通インターフェースによるポータビリティ: AWS（DynamoDB + RDS）やGCP（AlloyDB等）といった、 クラウドごとに異なるストレージの仕様をScalarDBで吸収し ている。
39. データ層の抽象化：ScalarDBによる共通化 39 AWS GCP Azure
40. まとめ：構築したインフラの仕組み 40 再現性と標準化 18分での⾃動構築とWikiへの徹底した知⾒外部化によ り、個⼈の⼒量に依存しない⼿順を実現。 統制と共通化 ⼿動承認で責任の境界線を明確化。AIで各社の「⽅⾔」 を吸収し、3⼤クラウドの操作感を統⼀。 抽象化の完遂 ScalarDBによる抽象化でDB固有のSDKを排除。インフラ に依存しないデータ管理を達成。 結論 「共通ワークフロー」と「データ層の抽象化」によって マルチクラウドの壁を突破できる。
41. 実現したデプロイの仕組み
42. デプロイまでの流れ 42 AI駆動の構築と⾃動検証 指示/Issue作成

43. 事前準備 43
44. イシュー作成 44
45. パイプライン 45 プッシュ
46. パイプライン 46
47. 構築後の最終確認：⽬視と「違和感」の価値 47 ⾃動化を過信しないエンジニアの姿勢 パイプライン成功後も、必ず各クラウドのマネジメントコンソールで「意図通りの構築」かを確認。 最後は⼈間が実機を確認することが、責任ある構築と安⼼感に繋がる。 結論 機械的な「正常終了」だけでなく、設計者の意図が正しく各リソース（SG設定等）に反映されて いるかを「⽬視」で確認する⼯程が、品質の最後の砦となる。
48. 構築の効率化と品質の標準化の実感 48 ⽣産性向上の⼿応え 複雑なマニフェスト作成や調査をAIが⽀援することで、エンジニアは本質的な「設計意図の管理」に集中できるように なった。 品質の安定化 GitLabの検証機能（ガードレール）が常に稼働することで、⾃⾝の習熟度に関わらず、最低限守るべきセキュリティラ インを維持できている。 ⺠主化への寄与 属⼈性を排除した「仕組みによる品質担保」が、チーム全体の技術レベルのボトムアップに寄与する可能性を実感し た。
49. 継続的な運⽤管理：クリーンアップとコスト 49 「クラウド破産」の防⽌ インフラを壊しては作るプロセスを繰り返す中で、リソースの消し忘れ（特にNAT GatewayやLB）を防ぐため、AIに 作成させた⼀括クリーンアップ⽤スクリプトをdestroyに組み込んだ。 コストの可視化と制御 Terraformによるコストタグ（Cost Allocation Tags）の⾃動付与を調査し、管理者権限が必要な設定等についても検討 を実施した。 コスト意識の醸成 ⾃動化によって構築が容易になったからこそ、不要な時は即座に破棄し、パイプラインスケジュール等も活⽤してコス トパフォーマンスを最⼤化するマインドセットを重視している。
50. エンジニアの役割の変化：実装から「判断」へ 50 役割のシフトと再定義 ⼀からコードを書く作業時間をAIが短縮してくれる 分、エンジニアは「AIの出⼒を精査し、最終的な安 全性を判断する能⼒」を求められる。 適切なツールとAIを「使いこなす側」に⽴つことで 経験の浅いエンジニアであっても ⾼度なシステム基盤を安全に 統制できる可能性が⾒えてきた
51. まとめ：構築したインフラの仕組み 51 ワークフローの統合 AIによるタスク細分化と⼀連のパイプライン化により、 準備からアプリ設定までを確実に完遂。 最終判断の重要性 ⾃動化を過信せず、⼈間の「⽬視」と「判断」で品質を 担保。実装作業から「判断」へ役割をシフト。 運⽤ガバナンスの確⽴ ⾃動クリーンアップやコスト可視化を実装。⽣産性向上 と健全な「コスト意識」の醸成を両⽴。 結論 AIに「実務」を任せ、⼈間が責任を持つ。この役割分担 こそが、安全な統制を実現する⼀つの答えである。
52. まとめ
53. 振り返り 53 「難しい」を財産に変える 複雑な依存関係を根性で乗り越えるのではなく、ツー ルと仕組みで「誰でも再現可能」な形に落とし込むプ ロセスこそが、⾃⾝の成⻑に繋がった。 「属⼈化」から「コードによる管理」へ CLIでの成功に満⾜せず、GitLab CI上に環境を移したこ とで、誰が実⾏しても 18分 でサンプルレコード確認ま で到達できる再現性を確保した。 当初、AWSマネジメントコンソールで設定ミスを繰り 返し、ノードが起動しない状況に直⾯した際の「難し さ」が、現在の⾃動化‧再現性を重視する姿勢の原動 ⼒となった。 曖昧な記憶や⼿元の環境に依存せず、常にコードを正 解（マスター）として扱う⽂化の重要性を、最初の失 敗から学んだと考えている。
54. 54 AIを「盲信」しないための距離感 AIを「⾃分の状況を理解したパートナー」として機能 させる様々な⼯夫を⾏ったが、完全ではないことを念 頭に置き、最終的なGoサインを出すのは常に⾃分であ るという意識を⼤切にした。 「判断」こそがエンジニアの役割 AIが提案したコードをそのまま使うのではなく「なぜ この構成なのか」を⾃分が納得できるまで問い直す。 AIは⾮常に強⼒だが、丸投げしてしまうと「もっとも らしい間違い」に気づけないリスクがある。 この「問い直すプロセス」こそが、AIを野放しにせず、 エンジニアとしてプロジェクトの主導権を握り続けるた めに不可⽋だった。 AIとの関係：あくまで「判断」の主体は⾃分に置く
55. AIとの関係：あくまで「判断」の主体は⾃分に置く 55 AIのおかしな挙動:具体例 ‧GKEのNAT構成:その時の構成には必要なかった Cloud NATを無理やり組み込んでデプロイしようと していた ‧YAMLのハルシネーション: AIが「構⽂は正しい」 と回答したYAMLに潜むインデントミスを、⽬視の デバッグで⾒つけ出した。 ‧141MBの誤コミット: Commitが重いという直感 を信じて確認した結果、AIが⾒落とした .terraform ディレクトリの混⼊を防ぐことができた。 改⾏必須 このままだと エラーの原因に
56. GitLabがもたらした「守り」の⽂化 56 安⼼感という価値 SASTやSecret Detectionといった「機械的なガードレー ル」が常に稼働していることで、失敗を恐れずに新しい インフラ構成に挑戦できる⽂化が醸成されたと感じた。 情報の透明性と継続性 すべての「なぜこの設定にしたのか」という意図がWiki やMerge Requestに残ることで、情報の断⽚化が防がれ た。 単なるツールとしてではなく、⾃分の試⾏錯誤をすべて受け⽌めてくれる 「活動の記録場所」があったことが、今回の完遂には不可⽋だった。
57. 次なる挑戦：可観測性とFinOpsの融合 57 NEXT：「構築」の先にある「運⽤」と「最適化」へのロードマップ Observability GrafanaやPrometheusを⽤いた「監 視」をさらに深め、サービスの健全性 を多⾓的に可視化したい。 FinOps OpenCost等を活⽤し、リソース消費 を「⾒える化」することで、無駄のな いインフラ運⽤を⽬指す。 GitOpsへの踏み込み Argo CD 等のツールを導⼊し、 Gitリポジトリの設定とK8sクラスタの 状態を常に⾃動同期させる 仕組みを作りたい。
58. インフラ構築をもっと「開かれたもの」にしたい 58 技術のハードルを仕組みで下げる Kubernetesは依然として難解な部分も多い が、適切なツールやAIを組み合わせることで、 その⼊り⼝を広げられる可能性を感じた。 チーム全体の底上げへの貢献 歴の浅いエンジニアでも、AIのドラフトと GitLabの検証を借りることで、チームが求める 品質に最短距離で近づけるようになる。 「難しいから⼀部の⼈しか触れない」状態を、 仕組みによって「誰もが安全に貢献できる」状 態へと変えていきたい。 これによって、ベテランの⽅がより⾼度な設計 や意思決定に集中できるような、ポジティブな 循環を作れるのではないか。
59. ⾃⼰の挑戦：AIとGitLabをもっと使いこなす 59 経験豊富な⽅々のアドバイスも頂きながら、ツールとAIを「パートナー」として より安全で効率的な開発⽂化を追求していきたいと考えています。 AIとの対話術の探求 「AIをどう導けば、より精度の⾼い設計を引き出せる か」。⾃らの経歴の伝え⽅や制約条件の持たせ⽅を、 試⾏錯誤しながらさらに磨いていきたいと考えていま す。 GitLabポテンシャルの最⼤化 GitLabが持つ豊富な機能を使いこなし、チーム全体の開発サ イクルをより良くするための⼯夫を続けていきます。 承認ルール（Approval Rules）の⾼度化 パイプライン分析とDORA指標の活⽤
60. Thank you for your attention. 2026/2/6 #AIxDevOps 勉強会 第4回 株式会社ラクスパートナーズ 岩崎 准⽮ 60

61. GitHub scalar-labs/scalardb connpass Scalar Please give us a star on GitHub! AIxDevOps Study 毎週⽕曜開催