サービス開発2課の山田です。
Cloud Automator では、Terraform からジョブを管理できるようにするための Terraform Provider（terraform-provider-cloudautomator）を提供しています。
Cloud Automator では日々アクションの追加や改善が行われており、新機能が登場するたびに、Terraform からもそれらを扱えるよう Provider 側を追従させる必要があります。
この追従作業には、スキーマ定義の追加・受け入れテストの作成・ドキュメントの生成などが含まれ、1アクションあたりの作業時間は1〜2時間ほどですが、定型化されているとはいえ地味な工数負担となっていました。
そこで本記事では、コーディングエージェントを利用して、新アクション追加する際に必要な Provider の更新作業をどこまで自動化できるかを検証した結果と、実際に運用へ組み込んだフローについてご紹介します。
- 背景
- 検証対象としたコーディングエージェント
- 検証結果 (Amazon Q Developer for GitHub)
- 検証結果 (Claude Code GitHub Actions）
- 導入した自動化フロー
- 運用して分かったこと
- まとめ
背景
Cloud Automator に新しいアクションを追加した際に、Terraform Provider 側で発生する作業は、ざっくりと以下の通りです。
- 新アクションのスキーマ定義追加
- Provider のリソース／データソースとの統合
- 受け入れテストの追加
- ドキュメントの生成
どれも決まった手順ではあるのですが、毎回ゼロから人の手で実装する必要があります。
また、「気づいた人がやる」運用になっていたので、Terraform Provider への反映が後回しになり、Cloud Automator 側のリリースと Terraform 対応にタイムラグが発生することもありました。
こうした背景があり、型が決まっている作業はエージェントに任せて、Provider の更新作業を自動化できないかというのが今回の取り組みの出発点です。
検証対象としたコーディングエージェント
今回の検証では、社内で利用実績や検証環境が整っていたものとして、以下の 2 つを比較対象としました。
Amazon Q Developer for GitHub
GitHub Apps - Amazon Q Developer · GitHub
Amazon Q Developer for GitHub は、GitHub App としてリポジトリに導入し、Issue や Pull Request 上の指示をトリガーに動作します。
Issue に対してラベル付けやスラッシュコマンド（例：/q dev）で依頼すると、リポジトリを解析したうえで変更を生成し、ブランチ作成から Pull Request 作成までを行ってくれます。
Claude Code Action
GitHub - anthropics/claude-code-action
Claude Code Action は、Claude Code を GitHub Actions 上で動作させるための Anthropic 公式アクションです。
バックエンドとして Anthropic API のほか Amazon Bedrock などを選択可能で、GitHub 上でのメンションやワークフローで指定したプロンプトに応じて、リポジトリの解析からコードの実装、テストの実行などを自律的に行ってくれます。
今回は、バックエンドに AWS Bedrock を使って検証を行いました。
検証結果 (Amazon Q Developer for GitHub)
良かった点
良かった点として、API ドキュメントから Terraform スキーマへの変換はかなり正確でした。
- 型（string / int / bool / list など）の判定
- Required / Optional の設定
- コメントや説明文の埋め込み方
といった部分は期待通りに動作しており、この部分だけを見ると十分実用レベルだと感じました。
課題として感じた点
一方で、実際に作成された PR を確認したところ、以下の点が気になりました。
バックアップファイルがコミットに混ざる
一時的なバックアップファイルなど、本来コミットに含める必要のないファイルが差分に含まれることが多々ありました。
結果の揺れが大きい
PR ごとに完成度にばらつきがあり、完璧な出力ですぐにマージできるような結果を出力することもあれば、全く無関係なファイルを書き換えたりして、結局人間が手動で修正する手間が発生してしまうこともありました。
検証結果 (Claude Code GitHub Actions）
良かった点
差分が必要な箇所にきれいに収まっている
追加・変更が必要なファイルにだけ差分が入っており、意図しないファイルへの変更がほとんどありませんでした。
また、複数回試行しても出力結果に大きなブレがなく、一貫性のあるコードを生成してくれました。
既存パターンの踏襲が正確
Terraform Provider にはこれまでの PR による実装パターンが存在するのですが、Claude が生成したコードはそれをかなり正確に理解して踏襲して実装していました。
ただ、このあたりは Claude Code に渡しているプロンプト側で、「どのディレクトリを対象に、既存のどの実装パターンを踏襲するか」をあらかじめ詳細に明示していることも効いていそうです。
ちなみに、実際に使っているプロンプトは以下のような内容になっています。
フォーマットやテストも整っていた
生成されたコードは go fmt や make fmt を通したような整った状態になっており、テストコードも既存アクションと同じ粒度で記述されていました。
CI を通すうえでも大きな手戻りはなく、そのままマージできるレベルの出力になっていました。
導入した自動化フロー
検証の結果、Claude Code を採用し、Provider 更新の流れを GitHub Actions に組み込みました。
Cloud Automator の API 仕様は別リポジトリで管理しているため、「API 仕様リポジトリの PR が main にマージされたタイミング」を起点にして、Terraform Provider 側の更新処理が自動で走るようにしています。
流れは次の通りです。
- API ドキュメントを管理しているリポジトリで PR が
mainブランチにマージされる - PR の差分情報を取得し、
repository_dispatchイベントで Terraform Provider リポジトリに通知する - Terraform Provider 側の GitHub Actions が起動する
- 差分を一時ファイルに書き出す
- AWS 側の認証（OIDC）を設定し、Bedrock を呼び出せる状態にする
- 用意しているプロンプトを読み込んで、Claude Code に編集方針を渡す
- Claude Code が実装・テスト・フォーマット・ドキュメント生成まで実行する
- ブランチの作成と PR の作成
作成された PR のレビューとマージだけ、人間側で行っています。
運用して分かったこと
パターン化された作業とは相性が良い
今回の Terraform Provider 更新作業のように、構造や実装パターンが明確で、既存のコードを横展開する形で進められる作業は、コーディングエージェントとの相性が非常に良いと感じました。
逆に、パターンが固まっていない領域の作業だと、期待する結果を出力できるようにするためにはプロンプトの調整コストが上がるだろうなと感じました。
進捗が見える
GitHub Actions 上で処理が進むため、各ステップの実行状況や失敗箇所がサマリーとして整理される点も、運用面では大きなメリットでした。
GitHub Actions の実行ログ自体は、特に何も工夫しないとコマンドの標準出力・標準エラーがそのまま記録されるだけなので、特に今回のような初期導入時の試行錯誤している段階だと、どこで失敗したのかが分かりやすい (そこに至るまでの実行ログが見やすくまとまって残る) のが非常に助かりました。
完全放置ではないが、負荷は確実に減った
例外ケースの対応 (特定の組み合わせでしか指定できないパラメータの追加) やプロンプトのメンテナンスは必要で、すべてを完全にエージェント任せにできるわけではありません。
それでも、毎回ゼロから差分を作るのと比べると、更新作業に割いていた時間はかなり減ったかなと思います。
まとめ
本記事では、Terraform Provider の更新作業をコーディングエージェントで自動化する取り組みについて、検証結果と実際の導入内容を紹介しました。
同じように「構造が決まった定型作業が多くてつらい」という悩みを持っている方にとって、何かヒントになれば幸いです。
