はじめに
レバレジーズ株式会社 テクノロジー戦略室 SRE チームの中野です。レバレジーズでは「SRE 化を通して、Developer Experience の改善、事業の拡大への対応、お客様に信頼されるサービスの提供を実現する」をミッションとして、サービス改善の文化的土俵の構築や開発生産性の向上を進めています。
過去記事 (= Terraform による IaC の標準化を通じた、全社規模の開発体験の向上への取り組み) では、社内標準となる IaC ツールの選定と、IaC 化の作業負荷の軽減を狙ったライブラリ・テンプレートの作成についてご紹介しました。
今回はその続編として、これらの製品を Template as a Service として提供する中で見えてきたユーザペインと、AI Agent Skills によるペインの解消・製品強化の取り組み、そして今後の展望についてご紹介します。
現在、SRE・Platform Engineering の取り組みで Template as a Service を社内展開しているが、製品を使いこなすまでのハードルが高く製品普及が思う様に進まない。この様なペインを抱える開発組織の参考になれば幸いです。
なお、本記事で紹介する取り組みは、2026年4月開催の AWS Container Platform Engineering Meetup のパネルディスカッションでご紹介した話の詳細版です。当日話し切れなかった部分を本記事でお伝え出来ればと思います。
背景
現在は、下表の Template as a Service を提供中です。初めにインフラ作業の効率化・省力化を狙って Terraform Modules、GitHub Composite Actions、GitHub Repository Template を作成し、学習による知識強化も狙って Terraform Handson というハンズオン形式の学習教材も作成しました。これらの製品により、IaC 化推進の環境を整えてきました。
| 提供製品 | 概要 |
|---|---|
| Terraform Modules (AWS Provider 向け) | ELB・ECS・RDS 等の単体リソースに対応する Component Modules、CloudFront・WAF 等の複数のリソース群を組み合わせた Catalog Modules の2種類がある |
| GitHub Composite Actions | Terraform 用の CI/CD、アプリ用の CI/CD 等の共通処理をパッケージ化したものが多い |
| GitHub Repository Template (Terraform 向け) |
Terraform Backend の環境構築、CI/CD 用の IAM リソース設定、Slack 関連設定、アラート用のリソース設定等の手順・設定を同梱しており、IaC 導入時の初期作業を低工数で済ませられる |
| Terraform Handson | Terraform 用のハンズオン教材であり、Terraform の基礎から発展までを短期間で学習出来る |
一方、製品利用が進むにつれて、製品の改善点が見え始めました。以下は、ヒアリングやフィードバックを通して得られた代表的なペインです。
当初は Embedded SRE 等の手慣れたエンジニアを対象に製品のファンを増やすことを目的としていましたが、今後のユーザ拡大を考えると、ペインを解消して製品の使い勝手を強化することを優先すべきだと考えました。
- Terraform Modules
- モジュールの使い方や必要な変数の組み合わせが、仕様や利用例だけでは判断しにくい
- モジュール毎の使い分け基準は書かれているが、どのモジュールを使うかの判断が難しい
- GitHub Repository Template
- 初期整備の手順資料・作業工程が多く、作業全体の流れや進捗を把握しにくい
- 設定項目が多く、必須なものが分からないため、何を埋めるべきか判断しにくい
AI の活用方針の検討
社内では AI Agent の利用が広がっており、これを活用すれば作成コストを抑えながらペインを十分に解消可能だと考えました。実際、社内要件・命名規則やクラウドのベストプラクティスに沿って提供製品が作り込まれており、AI による代行が十分に可能でした。そこで、AI Agent Skills の作成を決めました。
次に、先述のペインを起点に Skill で解決可能なことを整理して製品案を考え出し、次の基準をもとに作成優先度を決めました。その結果、下表の「Terraform コード生成 Skill」及び「GitHub Repository Template の初期整備 Skill」を高優先で作成すべきだと判断し、これらの作成から始めることにしました。
作成優先度の決定基準
- ペインの程度や発生頻度
- 負荷・コスト等の削減効果
- 直近の利用予定、社内要望
作成候補の優先度一覧
| 作成候補 | 優先度 | 対象者 | 判断理由 |
|---|---|---|---|
| コード生成 Skill | 高 | ユーザ | Terraform コードの実装・修正が他の作業よりも高頻度である |
| 初期整備 Skill (GitHub Repository Template 用) |
高 | ユーザ | IaC 関連の初期作業のみの利用だが、自動化の効果が大きい |
| スタイルガイド Skill、 製品仕様ガイド Skill |
中 | ユーザ | 運用フェーズでの実装・仕様把握の負荷を継続的に下げられる |
| モジュール開発 Skill、 コードレビュー Skill |
中 | メンテナー | 開発・レビューの作業負荷を下げ、省力化・体制分散に繋がる |
| Terraform Ops Skill、 コスト試算 Skill、 インフラ構成図 Skill |
低 | ユーザ、メンテナー | 発生頻度・現在の負荷が比較的小さく、将来の開発対象とする |
AI Agent Skills の作成
ここでは、高優先で作成した「Terraform コード生成 Skill」及び「GitHub Repository Template の初期整備 Skill」の概要・ワークフローや設計・工夫についてご紹介します。
前者は Terraform Modules の「使い方・使い分けの判断が難しい」というペインに、後者は GitHub Repository Template の「初期整備の工程が多く進捗や設定値の判断が難しい」というペインに、それぞれ対応するものです。
Terraform コード生成 Skill (AWS / Google Cloud)
概要・ワークフロー
Terraform コード生成 Skill とは、ユーザへのヒアリングに基づいて Terraform コードを生成する Skill です。AWS・Google Cloud の Provider 毎に Remote Skill (= terraform-codegen-aws / terraform-codegen-google) として提供しており、EC2・RDS 等の単体サービスから、静的サイト (CloudFront・WAF・S3) や Web システム (ALB・ECS・RDS 等) といったインフラ構成のコードまで生成出来ます。処理フローは次の通りです。
| No | ステップ | 概要 |
|---|---|---|
| 1 | ユーザへのヒアリング | サービス名・環境名・リージョン等の要件情報を聞き出し、必要なインフラリソースを洗い出した上でリソース設定の追加確認を行う |
| 2 | Terraform コードの生成 | ヒアリング結果に基づき、必要なインフラリソースに関する Terraform コードを生成し、実行場所にコードを書き込む |
| 3 | Terraform コードの検証 | 生成したコードに対して terraform fmt/validate のコマンドを実行し、エラーが無くなるまで検証・修正のサイクルを繰り返す |
| 4 | 完了報告と追加確認 | 設定の判断理由を含めて作業結果を報告し、コードの追加・修正の要望を確認する |
ヒアリングでは、推測可能な情報は聞かないことを原則として、要件等の推測が難しい情報だけを AI Agent がユーザへ確認します。また、どのリソース・モジュールを用いるか、変数設定をどう組み合わせるか等のコード生成に必要な判断を AI Agent が担います。この様な設計により、ユーザの確認負荷を抑えています。
コード生成では、下記の優先順位で生成方法を選択します。terraform-codegen-aws は、該当する社内向け Terraform Modules があれば必ず利用し、無い場合はモジュールを用いずに生成します。一方、terraform-codegen-google は、社内向け Terraform Modules を提供していないため、モジュールを用いない生成を基本としています。
なお、Public Modules の利用については、両方の Skill に共通で、バージョン更新時の追従負荷を考慮して要望があった場合のみ利用可能なオプションとしています。
- terraform-codegen-aws の生成方法の優先度
- (a) 社内向け Terraform Modules を利用する
- (b) モジュールを用いずにコードを生成する
- (c) Public Modules を利用する (要望時のみ)
- terraform-codegen-google の生成方法の優先度
- (a) モジュールを用いずにコードを生成する
- (b) Public Modules を利用する (要望時のみ)
この優先順位には、社内標準の資産を AI のコード生成経路そのものに組み込む狙いがあります。ユーザが社内モジュールの存在や使い分けを知らなくても、生成されるコードは自然と社内標準に沿ったものになり、個々のエンジニアの習熟度に依存していた社内標準への準拠を仕組みの側で担保出来ます。
設計・管理のポイント
各々の Terraform コード生成 Skill に共通する設計・方針の枠組み (= SSoT の管理方針、検証の実施方針等) を定めており、これに基づいて各 Skill が作り込まれています。
まず、Skill では SSoT の管理方針を明確に決めています。モジュールの仕様・バージョン等は外部情報として Skill 内で持たずに CLI コマンドで取得し、ヒアリングの進め方・コーディング規約・組織固有の情報等は Skill 内で参照情報やテンプレートとして管理します。この方針で外部情報の更新への Skill の追従が最小限になり、Skill の管理・運用のコストを抑えられました。
また、参照情報を取得出来なかった場合に AI が推測で値を埋めることを禁止しており、ユーザへの確認に基づくコード修正かプレースホルダの残置に必ず倒す設計としています。
コード検証では、terraform plan の実行を意図的にスコープ外としています。コード生成の段階では静的なコード検証さえパスすれば問題無く、クラウド上での検証までスコープを広げると検証が複雑になり、副作用のリスクが生まれると考えたからです。そのため、terraform fmt/validate の実行によるコード検証として設計しています。
動作検証時の挙動改善
動作検証で、簡単なコード生成でも一律に時間・トークンを大きく消費するという挙動面の課題が判明しました。実測したところ、主な原因は「参照情報を何度も取得しに行っていること」及び「簡単なコード生成でも複雑な手順で処理していること」にあり、次の改善を行いました。
これらを「修正、検証、品質チェック」の処理サイクルで適用したところ、ユーザの入力・待機等を除いた処理自体の所要時間やトークン消費を、改善前よりも 30% 〜 40% 程度削減出来ました。
- 参照情報の取得方法の見直し
- 参照の度に発生していた取得処理を、最初に一括で取得・保存する方式に変更した
- 参照情報の取得の繰り返しを防ぎつつ、必要な情報を適切・十分に参照可能にした
- 生成内容に応じた処理の使い分け
- コード生成の進め方に応じた処理群のパターン分けを、生成モードとは別に設けた
- 生成処理の複雑さに応じて処理パターンを当てはめ、適切な処理をさせる様にした
- 機械的なチェックへの移行
- 文章ルールに基づくチェックを、スクリプトを用いたチェック処理に置き換え、照合のやり取りを削減した
- チェックルールは機械可読な一覧表で管理し、ルールの追加・変更が表の編集だけで済む様にした
- AI モデルの能力や実行毎のばらつきに品質が左右されにくくなり、安定化に繋がった
GitHub Repository Template の初期整備 Skill
概要・ワークフロー
初期整備 Skill は、Terraform 向け GitHub Repository Template から作成した GitHub Repository の初期整備を AI Agent が代行する Skill です。現在提供中の4種類の Repository Template に Local Skill (= terraform-repo-init) として導入しており、Repository の作成後に Skill を発動するだけで初期整備を簡単に進められます。
この Skill により、人間が対応すべき箇所は「ヒアリングへの応答、残りの限られた手動作業の消化」だけに絞られ、その他の作業を AI Agent が代行してくれます。手順書に沿った作業で起きがちなミスも、スクリプトを用いた機械的なチェックにより極力発生しない様にしています。処理フローは次の通りです。
| No | ステップ | 概要 |
|---|---|---|
| 1 | ユーザへのヒアリング | 構成・仕組みの要否 (= 開発環境、定期チェック、通知設定) や設定値等の初期整備で決めるべき情報を冒頭で一括して確認する |
| 2 | クラウド認証の確認・実施 | 実行環境やクラウド認証の状態を確認し、未認証だった場合に認証コマンドを実行する |
| 3 | 初期整備の自動実行 | 雛形の削除、テンプレート情報の置換、Terraform Backend の環境構築、GitHub Repository Secrets の登録、CI/CD の有効化、作業のセルフチェック等の自動化可能な作業を実行し、GitHub PR の作成まで進める |
| 4 | 残作業リストの出力 | 実行するだけで済む様な文面・スクリプト等を用意した上で、残りの手動作業に関するチェックリストを出力して終了する |
設計・管理のポイント
Repository の初期整備には、自動化が難しい作業 (= 外部への依頼・承認等) や、統制の観点から人間が担うべき作業 (= 秘匿情報の設定、PR のマージ判断等) が含まれます。そこでまず、AI Agent とユーザの作業分担を明確に定めました。
具体的には、環境検証・テンプレート置換・Backend 構築・Secrets 登録・PR 作成までを AI Agent が実行し、それ以外の作業は意図的に人間側に残しています。この線引きが、AI による作業代行を安心して組織展開するための前提だと考えています。
この分担を前提に、自動化可能な作業を先に進めて手動作業を最後にまとめる形へ作業全体の流れ・手順資料を再整理し、初期整備の自動実行とユーザへの残作業の提示を AI Agent に行わせる Skill を作りました。どの工程でも開始時に完了状態・前提条件・スキップ条件等を確認してから進行させる様になっており、途中で中断した場合でも安全に再開出来ます。
なお、コード生成 Skill と同様に SSoT の管理方針も定めています。手順・コマンド等の具体値は Repository Template の資料・スクリプトを SSoT として参照し、Skill 自体は判断ロジックと工程の順序のみを持つ構成としています。
Skills の管理・配布
Terraform コード生成 Skill は、特定の GitHub Repository に依存しない用途のため、Skill 専用の GitHub Repository で Remote Skill として管理しています。一方、GitHub Repository Template 用の初期整備 Skill は、Template 内の手順資料・スクリプトと一体で動く用途のため、Template 内で Local Skill として管理しています。
配布についても、管理方式に合わせて分けています。Terraform コード生成 Skill は GitHub CLI コマンド (gh skill install) で利用可能にしており、GitHub Copilot・Claude Code 等の AI Agent 間の仕様差異を GitHub CLI が吸収してくれるため、統一的な手順で配布出来ます。初期整備 Skill は、Template から Repository を作成した時点でそのまま利用可能なため、配布作業が不要です。
今後の展望
今後は、作成候補の優先度一覧で中優先以下とした Skill を順次作成し、ユーザ向けのインフラ作業のペイン解消だけでなく、製品メンテナーの開発・改善における作業負荷の軽減にも AI を活用していく予定です。これにより、Template as a Service の提供サイクルを現在の開発体制でも十分に回せる様に強化したいと考えています。
過去記事では「Template as a Service を作り、IaC 化を推進する」をご紹介しました。今回は「AI Agent が Template as a Service を使いこなし、エンジニアの代わりに作業する」への進化をご紹介しました。Template as a Service × AI の組み合わせで、AI を前提としたゴールデンパスを引き続き提供し、利用の障壁の無いプラットフォームへと育てていきます。
最後に
レバレジーズでは、全社の SRE・プラットフォームエンジニアリングの推進に向けて、開発生産性の向上に一緒に取り組んでいただけるエンジニアを募集しています。
SRE の文化・体制に興味があったり創っていきたい方や、プラットフォームエンジニアリングの実践による開発生産性の向上に興味がある方は、是非ともご応募をお待ちしております。
