【20260612 AI×DevOpsStudy #16】AI DevOps の基盤を作ってみたら、設計は人間の仕事だとわかった話

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

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

■今回のテーマ
「AI DevOps の基盤を作ってみたら、設計は人間の仕事だとわかった話」

「AIがあるなら作れるでしょ」——そう思ってインフラ構築を始めました。 5ヶ月間、EKS・CI/CD・監視・セキュリティと向き合いながら気づいたのは、AIはコードを書いてくれるけど、Why（なぜそれを作るか）と前提（どんな環境か）は人間が渡さないといけないということでした。 ツギハギになったインフラ、初めて見たプロの設計書、GitLab RunnerをEKSに構築したら——3つの失敗談を通じて、AIとの付き合い方を一緒に考えます。

■登壇者情報（敬称略）
樋口
前職は看護師。10月にIT研修をスタートし、Terraformという言葉すら知らない状態から、1月よりScalarでAI DevOps のインフラ基盤を構築することにになりました。「AIがあるなら作れるでしょ」という気持ちでインフラ構築に飛び込み、毎日何かしら詰まりながらも、設計や前提の大切さを身をもって学んでいます。

■関連コンテンツ
・Youtube（過去の勉強会動画も公開中！）
www.youtube.com/@scalar-labs

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

・イベントページ（connpass）
https://scalar.connpass.com/

Transcript

1. AI DevOps の基盤を作ってみたら、 設計は⼈間の仕事だとわかった話
2. 2 「インフラ、全部 AI に作ってもらいました。 でも、使えなかったです。」 今⽇は 5ヶ⽉でやらかしたことを全部話します "
3. 3 毎⽇詰まりながら、設計の⼤切さを学んでいま す。 前職：看護師 2025年10⽉：ラスクパートナーズ（SES) IT 研修スタート 2026年1⽉：Scalar にアサイン AI DevOps の基盤インフラ担当に 「AI があるなら作れるでしょ」と挑戦 ⾃⼰紹介
4. 4 「ツギハギ」のインフラ ⽬的を⾒失い、ツールを並 べただけの失敗談。 「プロの設計書」の衝撃 理由とトレードオフを⾔語 化する重要性。 AIとの付き合い⽅ 「前提」を伝えないとAIは 間違った答えを出す。 今⽇話すこと
5. 5 AI DevOps の基盤ってなに？ 構築した「⼟台」の構成要素 コンテナ ＆ CI/CD セキュリティ ＆ API管理 ＆ トランザクション管理 AWS リソース ＆ データ分析 あえてAWSマネージドを使わない理由 「AIが⾃動⽣成する無数のアプリ」を、 安全かつ効率的に⾃動で稼働‧管理するためのプ ラットフォームです。 • EKS: アプリを動かすコンテナ基盤 • GitLab CI / ArgoCD: ⾃動でテスト‧デプロイするパイプライン • Vault / ESO: パスワード等の機密情報を守る⾦庫 • Keycloak: ユーザーの認証システム • Kong: 通信の⽞関⼝（API Gateway） • VPC / EC2 (GitLab Runner): ネットワークと⾃動化サーバー • IRSA: プログラムごとの細かな権限管理 • EMR / Scalar Analytics: ⾼速なデータ分析環境 • ベンダーロックの回避 AWSに縛られず、他クラウドへも移⾏可能に • ⼤幅なコスト削減 ⾃前で組むことで⻑期的なランニングコストを抑え る ScalarDB: トランザクション •
6. 6 「コードは AI が書いてくれる。 では、⼈間は何をするのか？」 "
7. 7 エピソード① 「ツギハギになった」 Loki ⼊れて、Tempo ⼊れて、 できたのはバラバラのインフラでした
8. 8 設計も全体像も考えず、ひたすら「点」で実装。 「Loki（ログ管理）⼊れて」→ AIに聞いてデプロイ 「Tempo（追跡）も便利そう」→ AIに追加を依頼 「次はこのツールを…」 全体像なき実装
9. なぜ背景を理解できなかったのか？ 「これ、そもそも何を⽬指して作ってい るシステムかわかってる？」 ⸺ 社⻑からの⼀⾔ ホワイトボードに描かれた全体像を⾒て初めて、 システムの真の⽬的と「インフラ設計の重み」を理解した。 具体イメージの⽋如 サービスがどんなふうに動いてい て何が必要なのか、基本的な知識がない。 「他⼈事」のタスク化 「⾔われた通り監視ツールを ⼊れる」こと⾃体がゴールになり、設計の重みを汲み 取れなかった。 これからのステップ 正直、今も完全には理解できて いない。だからこそ、アプリが乗り始めるこれか ら、まだまだ勉強。 突きつけられた課題 "
11. 11 1 AIは How しか教えられない ツールを「便利そう」で選ぶとバラバラになる 「なぜ‧なにを作るか」を把握して初めて、AI に正しい指⽰が出せる 学び：Whyを把握してから始める
12. 12 エピソード② 「設計書ってなに？」 設計書を初めて⾒たとき 設計の詳細さに衝撃を受けました
13. 13 AIは「理由は不要」と⾔った。でも設計書は「理由」を最も⼤切にしていた。 ADR（Architecture Decision Record）：採用した理由だけでなく、選ばなかった理由まで書く 私の想像 「このAWSサービスとこのツールを使いま す」という構成図だけのもの。 設計書のほんと 各ツールの「採⽤理由」がびっしり。数ドル 単位のコスト試算。異常時の挙動まで明記。 想像を絶する「細かさ」
14. 14 項⽬ 私が書こうとしたこと 設計書で書いていたこと 技術選定 使うツール名の列挙 選ばなかった理由も含めた⽐較検討 コスト なんとなく安い L4 LB vs L7 LBの重複課⾦回避など具体策 挙動 動けばOK Spotインスタンスが落ちた際の復旧⼿順 ルール 命名規則など ビジネスの⽂脈に基づいた判断基準 設計書の中⾝の⽐較
15. 15 最初の間違い：「ルール集」 学び：要件整理から始める 実装の判断基準と構造 *スネークケース：snake_case のように単語をアンダースコアで繋ぐ形式 指摘：それは設計書ではなく、単なるコーディング規約 要件が決まれば、ディレクトリ構造は⾃ずと決まる 機能要件 ⾮機能要件 最⼩権限 ＆ セキュリティ IAMは必要な権限のみ。バージョン管 理を1箇所に集約。 環境の分離とモジュール化 と切ることで将来のマルチクラウ ド対応を考慮。 等で環境を完全分離。 Terraform 設計への挑戦
16. 16 2 設計 ＝ 理由の⾔語化 MECE（モレなく、ダブりなく）書く ⾔語化することで、⾃分の理解の⽢さが⾒える 「なぜ？」に答えられない箇所が、リスクになる 設計は⾔語化すること
17. 17 エピソード③ 「Runner を EKS に置いたら、 設計の問題に気づいた話」 レビューで「それ EKS ⽌めたら死にますよ」 と⾔われました
18. 18 AIの「ベストプラクティス」を実装 「これでいける！」と実装開始 VPC 内の Vault に CI から触りたかった GitLab の Shared Runner は VPC の外 → 届かない 「VPC 内のリソースに CI から触るには？」 「EKS に self-hosted Runner を置けばいいですよ」 公式ドキュメントにも手順がある
19. 19 「循環参照」の罠 テスト環境は「壊す前提」。AIはこの前提を知 らなかった。 指摘：「EKSが⽌まったら、Runnerも⽌ま るよね？」 Runnerが⽌まると、EKSを直すためのCIも 動かない。 「卵が先か、鶏が先か」の状態に。
20. 20 ⾜りなかった情報 「EKSそのものを頻繁に壊 したり⽌めたりする運⽤で あること」 AIの性質 コンテキストがリセットさ れるため、毎回「前提」を リマインドする必要があ る。 解決策 まず依存関係を⾒る 「何が⽌まったら何が死ぬかを把 握する」 ⾔語化してAIに渡す「把握し たものを前提としてAIに伝える」 依存関係を把握して、AIに渡す
21. 21 「ツギハギ」の失敗 失敗の内容 得られた気づき 「設計書」の失敗 失敗の内容 得られた気づき 「Runner」の失敗 失敗の内容 得られた気づき • ⽬的（Why）がないまま、⼿段 （How）だけを積み上げてしまっ た。 • AIは「どうやるか（How）」しか答 えられない。 • 「なぜやるか（Why）」を決めるの は⾃分（⼈間）の役割である。 • 理由や背景（Why）を書かない設計 書を作ってしまった。 • 設計書とは「Whyを⾔語化するも の」である。 • 「選ばなかった理由」まで書いて初 めて設計書になる。 • 書こうとすることで、⾃分の理解の ⽢さに気づける。 • 環境の前提（Why）をAIに伝えず、 AIを誤誘導（ミスリード）してし まった。 • ※Runner = 処理を実⾏する環境の こと • AIに渡す「前提条件」も⼈間の重要 な仕事である。 まとめ 依存関係を把握してから⾔語化する
22. 22 実際 ① ディレクトリ構造
23. 23 実際 ② modules分離
24. 24 実際 ③ CIテンプレート
25. 25 実際 ④ スケジュール
26. 26 ※5ヶ⽉間の実践を通じて⾒えてきた、現時点での⼀つの答え 「AIはコードを書いてくれる。でも、 なぜ作るのか、何を作るのか（Why）を⾔語化するのは、 全部⼈間の仕事だった。」 • AIは「どう作るか（How）」を⼤量に知っているが、前提が抜けると間違える。 • 設計とは、そのAIの加速に耐えられる「正しい前提」を⾔語化すること。 コードはAIが書く。では⼈間は何をするのか？ "
27. 27 設計書に理由を書こうとして、理解の⽢さに気づいた。 構成図を描いてみて、初めて全体像が⾒えた。 AIに丸投げせず、⽂字にすることでやっと⾃分のスキルになった。 ⾔語化は理解への近道
28. 28 • AI に任せてインフラを作ったら、ツギハギになった話 • 設計書を読んでわかった、設計9割の意味 • Terraform 設計書編（前編‧後編） • GitLab Runner で学んだ、AI との付き合い⽅ Zenn Blog
29. GitHub scalar-labs/scalardb connpass Scalar Please give us a star on GitHub! AIxDevOps Study 毎週⽕曜開催 ご質問、感想などお気軽にどうぞ！