はじめに
こんにちは。SREチームの侘美です。
弊社ではLLM（大規模言語モデル）を活用したコーディング、特にDevinやClaude Codeのようなエージェント型ツールを積極活用する方針を打ち立て、各種ツールを利用できる環境を整備しています。
また、習熟やノウハウの獲得のため各チームで一定期間AIエージェント縛りで開発を行い、得られた知見や課題を共有する活動も進めています。
我々SREチームでも2週間にわたってAIエージェント縛りで開発する実証実験を行いました。 本記事では、この実証実験を通じて得られた、通常のプロダクト開発チームとは異なるSREチームならではの課題や知見を共有します。
前置き
弊社SREチームの特徴
- 5人チーム
- 5名で社内の全プロダクトを分担して担当
- 主な業務:
- AWS/GCP/Azureの構築・メンテナンス
- GitHubや各種SaaSの管理
- プロダクトのアラート対応やフォロー
- データ分析基盤の構築
- 使用する言語・ツール
- HCL(Terraform)
- JavaScript/TypeScript
- Python
- etc
利用したAIエージェントツール
- Claude Code
- Devin
- Gemini CLI
AIエージェント縛りに関するルール
- 手動でのコーディングは原則禁止
- 障害対応や納期的に厳しいものは例外
- 任意のAIエージェントツールを利用可能
- コミットメッセージ、Git操作、PR作成等は人間が実施してOK
- 週の終わりに振り返り会を実施する(2週で計2回)
AIエージェントの得意領域
メリットや有効に活用できた場面をメンバー内で共有した結果、いずれのメンバーもほぼ同じ結論となっていました。その中で意見が多かったものを以下に記載します。
1. シェルスクリプト生成
全メンバーが一致して評価したのは、シェルスクリプト生成の精度の高さです。
特に以下のような作業で威力を発揮しました。
- AWS CLI一括処理: RDSメトリクス取得、複数アカウントの管理作業
- データ分析スクリプト: CloudWatch metricsの統計処理、CDC スループット計算
- コード生成用スクリプト: removed block一括生成、設定ファイル自動生成
Aurora MySQL から Confluent Cloud への CDC スループット分析という複雑な要件に対し、400行を超える高度なシェルスクリプトを一発で生成することもできました。（手動では2-3時間かかる作業が30分で完成）
2. ドキュメント・PR説明文の生成
文書作成系の作業でも有効に活用できました。
- プルリクエスト説明文: コミット履歴から適切な説明を自動生成
- 技術ドキュメント: 実装内容をもとにした分かりやすい手順書作成
- コミットメッセージ: Conventional Commits準拠の体裁の良いメッセージ
以下のようにClaude Code用のカスタムコマンドを作成してPR説明文生成を自動化するとかなり捗ったと紹介しているメンバーもいました。
---
allowed-tools: Bash(git log:*), Bash(git diff:*), Bash(git fetch -a:*), Bash(cat:*), Bash(pbcopy:*), Read(*.md), Fetch(*)
description: "現在の作業ブランチからプルリクの説明文を作成します。"
---
* この作業ブランチに含まれるコミットとコミットメッセージをまとめて, プルリクエストに記載するdescriptionをmarkdownで作成してください。
* 作業ブランチとorigin/masterもしくはorigin/mainブランチと比較することで, その作業ブランチに含まれるコミットとコミットメッセージを抽出します。
* ローカルのorigin/masterもしくはorigin/mainブランチが古い可能性も考慮してgit fetch -aを事前に実行してください。
* descriptionの書式
* Claude Codeで作成したことがわかりやすいように, description内にClaude Codeの署名を末尾に含めてください。
* 可読性を上げるために以下の対応を行なってください。
* またタイトル等で絵文字を多用してぱっと見で見やすい方にしてください。
* 可能な限り箇条書きとして閲覧しやすくします。
* 箇条書きにした項目の関連性によって, 適切な範囲で段落を下げてください。
* 以下の情報は不要なので省略してください。
* プルリクエストを見るとわかる, 変更ファイルの一覧や統計情報は冗長であるため不要です。
* GitHub ActionsのCIによってチェックされる項目はdescriptionには不要です。
* 作成完了しましたら, クリップボードに格納してください。
* 末尾にEOF等のdescriptionとは関係のない文字列が入らないようにしてください。
3. JSON・設定ファイルの編集
構造化データの編集作業においても手作業に比べてかなりの効率化が見られました。
- Slack通知のJSONペイロード: 複雑な条件分岐やフォーマット調整
- Lambda関数の軽微な修正: ESM形式への変更、パッケージ設定の調整
4. 小規模の修正を広範囲に実施するケース
大量のファイルに似た小さい修正を行うような作業でも効果的に感じました。
- アカウント削除: 複数サービスからの特定ユーザー一括削除
- 設定ファイル更新: 複数環境への同一設定適用
- リソース名変更: 命名規則に合わせた一括リネーム
AIエージェントの苦手領域・課題
一方でうまく実装できない領域や課題も多く発見されました。 特にこの実証実験前から懸念していた、Terraformなどに代表される宣言的コードとの相性の悪さが浮き彫りになりました。
1. Terraformとの相性の問題
全メンバーが一致して指摘していました。
古いリソース・非推奨属性の提案
- TerraformのProvider更新が頻繁なためか、AIの精度が低い
- 推奨されない属性や廃止予定のリソースタイプを提案
- 最新のベストプラクティスに従わないコード生成
- MCPを利用してもそこまで改善されない
宣言的コードの特性による非効率性
Terraformなどの宣言的コードでInfrastructure as Codeを実現するケースにおいては、設計が完了すれば後はその設計をそのままコード化するだけなので実装上で悩むシーンはそこまで多くありません。
一方、Ruby等のプログラミング言語でバックエンドサービスを構築する場合、設計が完了した後もメソッドの分割の仕方や同じ処理系でも実装方法が無限にあるなど、詳細設計〜実装〜テストとまだまだ考慮すべき点が山程あります。この工程をAIに行わせることでかなりの生産性向上が見込めます。
そのため「自然言語で作業を指示する」というAIエージェントの利用方法とTerraformの相性の悪さを感じる結果となりました。
学習データ不足
Terraformのコードはそこまで複雑ではないのにもかかわらず、LLMによるコーディングの精度が悪いことは各所で言及されています。
一般的なプログラミング言語はOSSとして質の高いコードがいくつもWeb上で公開されています。 Terraformの場合もAWSが提供する公式モジュール等、良いコードがいくつも公開されています。 ですが私達サービスを構築するSREチームが参考にすべきような、『実際に運用されている大規模サービスのTerraformコード』が公開されている例は多くないと思います。
このように、実用に耐えうるレベルの質の高い学習のためのコード不足がそのまま他の言語と比べて精度が悪いといった結果を引き起こしているのでは？という考察もメンバー内で上がっていました。
2. 指示作成コストの高さ
複雑な要件の言語化が困難
- 正確な実装を得るために、自然言語でterraformを記述することになる
- プロンプト作成時間が実装時間を上回るケースが頻発
- 大きい作業は1プロンプトより細かく小出しに指示した方が正確だが、これは結局、自然言語でコードを書いているようなもの
3. editorconfig・Linterルールの無視
設定ファイルの強制適用が困難
.editorconfigの設定をAIに従わせる効果的な方法がない- コード生成後に手動でフォーマット修正が必要
- 自動修正（fix）ツールの不足
こちらはHooksの登場により、整備することである程度解消できる目処が見えてきましたね。 （実証実験中にHooksが発表されました）
一貫性のないコードスタイル
- チームの規約に合わないインデントや改行
- 命名規則の不統一
- コメントスタイルの不一致
4. git操作の危険性と制御の困難さ
予期しない操作の実行
このあたりはAIエージェントあるあるで有名だと思いますが、実際に期間中にメンバーがいくつか遭遇していました。
- rebase指示すると作業がループする
- 追加実装したコードを消される
- PRが勝手にクローズされる
（SREチームがコミットメッセージやコミットの粒度に厳しいメンバーが多く、より綺麗なコミットに修正しようとしたため遭遇率が高かった可能性もあります）
5. コストと経費処理の複雑さ
Claude Codeの支払いを会社側が行い、社員をメンバーとして利用させるようなチームプラン的なものが現状ありません。 そのため弊社では「AWS/GCPでClaudeを従量課金で動かして一人 100USD/月 を超えないように管理する」or「個人でProプランやMAXプランを契約して経費精算」という少々手間のかかる運用になっています。
その他知見
AWSコスト分析
AWS Cost Explorerから取得したデータを使い、アカウント別コスト比較や増減理由の分析を素早く行うことができました。
mise.toml活用
asdfからmiseに移行し、タスクランナー機能でvalidate, fmt, lint, trivyを統合実行できる環境を構築することで、指示やカスタムコマンドを簡略化できて効率的でした。
まとめ
2週間実装の全てをAIエージェントにすることで、得意不得意や有効的な活用方法が見えてきました。 特に現状の精度では、SRE領域のタスク全てを無理にAIエージェントに任せようとすると、かえって生産性が落ちる状況です。そのため、これらの知見をチームで共有できた点でも、かなり有用な実証実験だったと考えられます。
現状、ある程度の使い分けの方針は見えてきましたが、AIに関しては日進月歩で進化している領域なのでこれら苦手領域を克服してくる日も遠くないのでしょう。 随時エージェントの性能改善に関する情報をキャッチアップしつつ最も業務効率が上がる使い方を模索し続ける必要がありそうです。
是非読者になってください！
メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております！
■募集ポジションはこちら medpeer.co.jp
■エンジニア紹介ページはこちら engineer.medpeer.co.jp
■メドピア公式YouTube www.youtube.com
■メドピア公式note
style.medpeer.co.jp
