【AI×DevOps Study #18】AI駆動におけるモダナイゼーション by Claude CodeとAI活用のヒント

■AI×DevOps Study #18 の概要
2026年7月10日に開催した「AI×DevOps Study」第18回の発表資料です。

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

■今回のテーマ
「インフラ作業を生成AI（ClaudeCode）にどこまで任せるか」

生成 AI でコードを書く話は増えましたが、「インフラを生成 AI でどこまで任せていいのか」は、まだ手探りの人が多いのではないでしょうか。

本 LT では、実際の IaC リポジトリで Claude をどう使っているかを、設定・スキル・運用そのままに共有します。設計書づくりや実装をどう任せ、Terraform や Helm のリソース差異をどうレビューし、devcontainer による再現環境や CLAUDE.md・Skill でチーム知識をどう固定化しているか。また、API Gateway の構成変更を通じて、生成 AI をどのように使ったかの実例を紹介します。目的・差異・方針から設計・実装までをタスクガイドに整理して段階的に進めました。設計と実装を生成 AI に任せつつ、人間が差分を確認しながら破壊的変更を伴うクラウド環境への適用を実施しています。ここまでの issue 駆動・差分レビュー・Skill を組み合わせると、こういう検証がどう回るのか、をお見せします。

誤っても回収できる作業から任せ、危ない操作は人間が承認する という、現場で回している線引きの話が中心です。生成 AI をインフラ作業に持ち込みたい方に、明日から試せる具体を持ち帰ってもらえる内容にします。

こんな人におすすめ

・インフラで生成 AI を使い始めたい / 使い方を見直したい方
・Claude Code や devcontainer を実務でどう構成しているか知りたい方
・生成 AI を使って、破壊的変更を伴う移行をどう安全に進めるか知りたい方

話すこと

・IaC と生成 AI が相性のいい理由と、適用しやすい / 慎重に扱う領域
・設計書作成・実装・差分レビューの実際の回し方
・devcontainer / Skill / Hook / MCP による環境とチーム知識の固定化
・API Gateway の構成変更を通じて、issue 駆動・レビュー・Skill でどう進めたか

■登壇者情報（敬称略）
佐々木 亮輔
株式会社電通総研に在籍。現在は Azure・Kubernetes・Terraform を中心としたクラウドインフラ開発のテックリードとして、アーキテクチャ設計や IaC による基盤構築を推進。これまでに Hadoop/Spark を活用したビッグデータ基盤のインフラ構築や、Golang を用いたバックエンド開発のアーキテクチャ設計に携わる。

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

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

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

Transcript

1. インフラ作業を⽣成 AI に どこまで任せるか 2026/7/10 株式会社電通総研 佐々⽊ 亮輔
2. 今日話すこと 2 インフラ作業で生成 AI を "実際どう使っているか " を共有する • 今日の流れ ・なぜインフラと生成AIは相性が良いのか ・AIを組み込んだ開発フロー ・安全に使うためのガードレール ・実案件（Kong移行）の事例 ・まとめ
3. なぜインフラと生成 AI は相性がいいのか 3 相性の良さは構造的要因、判断は人間の役割 生成 AI と相性が良い理由 • 宣言的：あるべき状態をコードで宣言 • 設計パターンが定型化されている • API 仕様が明確 • 正解が一意で探索空間が小さい • ベストプラクティス・ガイドラインでレビュー可能 • エラー原因が限定されやすい • 公開情報（事例・ドキュメント）が豊富 → 定型化・検証可能な領域は AIに委譲、トレードオフを伴う判断は人間が担う 人間の判断が必要な領域 • ネットワーク設計のトレードオフ • 可用性設計（冗長化とコストのバランス） • セキュリティポリシーの策定 • コスト最適化の意思決定 • 顧客固有の制約条件 • 組織・運用体制と責任分解
4. インフラ作業の適用マップ 4 適用領域 適用しやすさ 主な前提条件 要件整理・論点整理 高い 機密情報の扱い 調査・要約・比較 高い 出典確認・人による検証 設計たたき台 中程度 前提の明示・レビュー体制 実装支援 中程度 リポジトリ文脈・テスト・実行環境 本番影響のある操作 低い 権限設計・承認フロー "可逆性・レビュー可能性 " で適用可否を見る 文章生成に向くかより "誤っても回収できるか " で見る
5. インフラ設計書を生成 AI で作る 5 文章起点でAIに任せ、図は必要な時だけ mermaidで • 説明文・設計書を先に書く。図から書き起こすことはしない • 文章だけでは伝わりにくいと感じた時だけ図を作成 • 図は基本 mermaid。コストの大きい drawio は必要な時だけ使う • drawio 使用時はスキルで手順化・精度を補強 • 発展途上だが、一から手書きするより段違いに速い • シーケンス図・フローチャートは mermaid で生成 • 出力はあくまでドラフト、人が確定させる 1 説明文・設計書を ドラフト 2 文章だけで伝わるか を判断 3 必要な時だけ図に (mermaid 優先) 4 人間レビューで 確定 ※ イメージが湧きにくい場合は、実装 → 設計書 → 図 の順で書き起こすこともある Drawio のスキル
6. 実装を任せる 6 "要件 → 方針 → 実装 → 検証" のループで回す • 要件をざっくり渡す。規模が大きければ先に設計方針を 立てさせる • 方針に問題なければ実装させる • ループ内の検証は fmt / validate / lint など軽い 検査(ローカルでも CI でも自動) • エラーはそのまま渡して直させ、完了まで反復 • 仕上げの差分レビュー 1 要件 2 方針 3 実装 4 検証 エラーは戻して直す 変更規模が 大きい場合 変更規模が 小さい場合
7. devcontainer で実行環境を揃える 7 実行環境をコンテナ化して提案を同条件で再現する • 人・AI で環境差をなくすコンテナ化 • 再現性・一貫性・移植性・可搬性が高い • AI の提案を同じ条件で再現・検証できる • きちんとした Linux 環境を前提にでき、新メンバーも AI もす ぐ作業に入れる • 要件を伝えれば生成 AI がすぐ構築。他案件にも持っていき やすい ホスト OS (人によって違う) devcontainer IaC ツール群 VS Code + 拡張 AI (Claude Code) → 同条件で再現・検証 プロジェクト固有の スキル devcontainer の 設定 マルチルートワーク スペースによる サブリポジトリ devcontainre の構成
8. devcontainer の中身とマルチルート構成 8 "lint / fmt / validate を即実行 " と "リポ横断 " が効率の肝 検査 (lint / fmt / validate) ドキュメント生成・接続 VS Code 拡張 マルチルートワークスペース docs リポ (sub/設計) AI 行き来 Volume • Claude の state / 履歴 (永続化) • ホストのホームディレクト リにあるスキル (~/.claude/skills) • サブリポジトリ tenv terraform helm deck kubectl terraform- docs helm-docs azure-cli drawio terraform markdown lint claude-cod e infra リポ (main/実装) Volume マウントしたうえで VSCode のマルチルートワー クスペースを使って複数リポジトリを同時に開く ※ workspacefolder は infra リポになるので、プロジェクト ルートにある .claude フォルダが正常に認識される docker-compose.yml
9. チーム知識の固定化 9 "最初の数分で判断を誤らせない情報 " を仕組みに残す • CLAUDE.md: コマンド / 命名規約 / 触ってはいけない 領域 / 落とし穴 • Hook: markdownlint で md の文法違反を自動修 正 • MCP: GitLab を read で接続(issue 読込) • 長い仕様書より、運用で迷わせない情報を優先 リポジトリ CLAUDE.md 文脈ファイル Hook md 自動修正 MCP GitLab read → AI の挙動を揃える
10. [実例] API Gateway のアーキテクチャー構成変更 10 検証環境を Kong 固有の Hybrid 構成へ。影響範囲が広い変更 •Control Plane 用 DB の設計・構築・バックアップ・復旧 •Control Plane ↔ Data Plane 間の mTLS と証明書運用 •Admin API / Kong Manager を書き込み経路にするための権限・監査・公開制御 •Helm upgrade 中心の静的反映を、 deck の差分確認・同期前提のフローへ組替 •切替後の障害点増加に伴う監視の整備 Hybrid 移行で発生した主要な作業 deck yaml KIC gateway dataplane controll plane database DBless Hybrid Kong の設定 httproute service
11. issue 駆動で進める 11 issue を文脈として渡し、1 テーマ 1 セッションで回す • 取り組むべき課題が発生したら AI に課題の件名と概要を作って Issue を起票する • インフラ系の実装は宣言的な記述が中心であるため、専用の Skill を使わなくても、モデルの標準的な能力で 十分に実装可能 • 途中から作業をするときは MCP で issue を read し、文脈を AI に渡す • read は MCP、write は人間、という線引き • 長期間にわたる作業では、プロジェクトの前提や設計方針などを Claude のメモリに記憶しておくと、セッショ ンをまたいだ引き継ぎがしやすくなる GitLab issue AI に文脈を 渡す MCP read session-recap で構造化 issue コメント へ転記 (人間 write)
12. 実装後にレビューする — 差分で確かめる 12 仕上げの段階で "意図と合っているか" を差分で確かめる • 実装が一通り終わった仕上げの段階で差分を最終確認 • terraform plan / helm diff upgrade / deck diff で意図と差分をチェック • terraform plan は差異が多すぎて見切れないので、Skill (tf-plan-review 等) で要約・リスク評価し、破壊的変 更の内容や想定外の変更が混入していないかを炙り出す • CI の自動 diff と組み合わせ "人間が全部見なくてよい状態" に近づける 実装完了 差分取得 • terraform plan • helm diff upgrade • deck diff Skill で要約・リスク評価 破壊的変更や想定外の変更を炙り 出す 人間レビュー
13. 判断を固定化するスキル群 13 "毎回同じ判断" ほど先に Skill 化する 毎回同じ判断 → Skill 化 version-scan ツール / プロバイダ / バージョン棚卸し tf-plan-review plan のリスク評価 / 破壊的変更の検出 session-recap セッションの背景 / 方針 / 結果を構造化 うまいプロンプトを毎回書くより、繰り返し作業を Skill 化 → 再現性が高く、チームの立ち上がりも速い 設計や実装を進めていると ツールのバージョンが更新さ れている Terraform の差分が数百あ り、チェックしきれない GitLab に対応内容の結果 だけを整理してコメントした い
14. [実例] Kong 移行をどう進めたか 14 タスクガイドで段階化し、 issue 駆動・レビュー・スキルで慎重に進める 移行タスクガイド (目的→方針→設計→実装で段階化 ) 目的 主要な差異 確定方針 設計 実装 アーキテクチャ セキュリティ 構成管理 運用 Kong CI-CD Helm Terraform 破壊的変更を伴う terraform → helm → kong の順に慎重に適用 issue 駆動 × レビュー × スキル を組み合わせて段階的に進めた
15. シークレットと権限境界 15 実行権限が強いエージェントほどガードを厚くする • .env は read させない(deny に登録) • allow は read 寄りに絞る(WebFetch / WebSearch、GitLab は read のみ) • 書き込み・更新系の操作は人間が担当 • "何を読ませ / 実行させ / どこから人間承認か " を 設計する AI 許可 (read 系) WebFetch / WebSearch / GitLab read 等 人間承認 書き込み・更新系の操作 deny .env など秘密情報の読込 × 実線=許可 点線=承認 ×=拒否
16. まだ任せていないこと 16 不可逆操作は人間承認。ただし "禁止" ではなく "経路を広げる " • 本番適用・不可逆操作 (apply / クラウド書き込み) は人間承認 • ガイドラインは "禁止事項の一覧" ではなく、安全に使うための最低条件 • 一律禁止せず、PR / MR 経由・dry-run 必須など安全な経路を開ける • 任せられる範囲を少しずつ広げていく 今 人間がレビュー・承認 安全な経路 PR / MR 経由 dry-run 必須 承認付き apply これから 任せる範囲を 少しずつ拡大
17. まとめ & 今後 17 価値は最新モデルより、環境・秘密管理・文脈共有・運用ルール 最新モデルを追うだけでは価値にならない — 効くのは次の 4 つ 環境整備 devcontainer で同条件 秘密管理 deny と権限境界 文脈共有 CLAUDE.md・issue・recap 運用ルール PR・dry-run・承認 • モデルの賢さより、チーム文脈をどれだけ構造化できるかで差が出る • 検証を自動化し "見なくていい差分" を増やす • 判断系の繰り返しを Skill 化し、任せる範囲を安全に広げる • 適用しやすい領域から始め、危険な領域は権限と承認を前提に
18. GitHub scalar-labs/scalardb connpass Scalar Please give us a star on GitHub! AIxDevOps Study 毎週⽕曜開催