こんにちは。
ファインディのPlatform開発チームでSREを担当している大矢です。
私たちのチームでは現在、SREのトイル削減を目指して様々な施策に取り組んでいます。今回はその1つとして、AIエージェント「Devin」を活用したユーザー管理の自動化についてご紹介します。
今回のお話
ファインディではクラウドサービスのユーザー管理の一部をPlatform開発チームが担当しています。具体的にはAWSのユーザー作成、グループへの追加、GitHubのOrganizationへのユーザーの招待などが該当します。
2025年12月現在、AWSのユーザーとグループはTerraformによるIaC管理に加え、Slackのワークフローを利用した申請受付からDevinによるPull Request(以下、PR)作成まで自動化を実現しています。
本記事では、かつて手動で行われていた管理フローがどのような課題を抱え、Terraform x Devinの導入によってどう改善されたのか、その経緯と改善内容についてお話しします。
本記事で触れること
- ユーザー管理自動化までの経緯と課題感
- なぜDevinを採用したのか
- IaC x Devinの実装内容とメリット
本記事で触れないこと
- Terraformコードの詳細な実装
- Devinのセットアップに関する細かい技術仕様
自動化までの歩み
AWSユーザー管理の手段は、組織の成長に合わせて次のように変わってきました。
- 手動管理期: 情シスがマネジメントコンソールから手動で作成
- IaC導入期: 申請者またはSREメンバーがPRを作成
- AIエージェント導入期: DevinによるPR作成の自動化
1. 手動管理期
かつては、情シスがユーザー追加の依頼を受け、AWSマネジメントコンソールから手動でIAMユーザーを作成していました。転機となったのはファインディのAWSアカウント構成を見直すタイミングです。ユーザー管理をIAM Identity Centerへ移行し、これを機にTerraformによるIaC管理を開始しました。
2. Iac導入期
IaC化により、ユーザー管理はソースコードベースでおこなわれるようになりました。フローとしては、申請者がSlackのワークフローからの申請と、Terraformのリポジトリへ申請の内容に基づいたPRを作成するという形です。
ユーザーが作成されるまでの流れは次のとおりです。申請者がTerraformの構造を理解する必要はなく、所定のYAMLに所定のフォーマットを追加するだけです。
これにより、ユーザー管理の透明性は向上しましたが、運用を続ける中で新たな課題が浮き彫りになりました。
- 非エンジニア対応の負荷: エンジニアであれば自分でPRを作成できるが、非エンジニアの場合はGit操作が難しく、SREメンバーが代行してPRを作成する必要があった
- コンテキストスイッチの発生: 社員数の増加に伴い、特に月末月初にはユーザー追加申請が集中する。1件あたりの作業時間は短くても、申請内容の確認、Git操作、PR作成、レビュー依頼といった作業が五月雨式に発生することで、本来の業務が頻繁に中断されていた
「作業自体は単純だが、頻度が高く集中力を削ぐ」。これはまさにSREが削減すべき「トイル」そのものでした。
3. AIエージェント導入期
これらの課題から、「ユーザー追加業務は定型化された繰り返し作業であり、人間が手を動かす必要はない」という結論に至りました。そこで、自律的にタスクをこなせるAIエージェント「Devin」にこの業務を任せることにしました。
やったこと
具体的な実装例として、AWSユーザー追加におけるDevinの設定とフローを紹介します。
1. Devinのセットアップ
Machineのセットアップをおこないます。Devin導入当初、KnowledgeやPlaybookは使用できず、Repo Noteに次のような自然言語による指示を記述しました。
- ユーザーの追加
- ユーザーの情報は以下のファイルで管理している
- <ユーザー管理ファイルへのPATH>
- ユーザーを追加する際は、以下の4項目が必要
- display_name
- email
- user_name
- group
- 前述の4項目には以下の情報を入れる
- display_name はAWSのユーザのコンソールに表示される名前
- email はユーザのメールアドレス
- user_name はAWSのユーザの名前
- group はAWSのユーザが登録されるグループ名
- ユーザーを追加する際は、display_nameをアルファベット順で並べる
- ユーザーの削除
- 対象となる項目はユーザー追加時と同じ
- 下記のユーザーを管理するファイルからAWSユーザーを削除
- <ユーザー管理ファイルへのPATH>
- PRのコミットメッセージのタイトルはConventional Commitsに従うこと
- ユーザーの追加、削除、変更は`chore: `とする
- 申請者をPRのAssigneesに設定して
- 申請者はSlackのIDだが、次のリポジトリにGitHubのIDとのマップがあるので、それに従い変換して
- <SlackとGitHubのIDをマップしたファイルへのPATH>
- 申請者のGitHubユーザーが特定できなかった場合、PRにコメントを残して
- 処理は必ずPRを作成するところまで完了させて
上記のとおり、しっかり構造化されていない状態でもほぼ期待どおりに動きます。まずは実践するとよいでしょう。
2. Slackワークフローの整備
Devinを操作するためのインターフェースとして、専用のチャンネルとSlackワークフローを用意しました。 エンジニアだけでなく非エンジニアも利用するため、CLIツールなどではなく、誰もが使い慣れたSlackを入り口にすることが重要でした。
Slackワークフローには次の入力項目を設けています。(抜粋)
| 項目 | 設定・入力内容 |
|---|---|
| 変更種別 | 追加、変更、削除から選択 |
| 表示名(ローマ字の氏名) | ローマ字の氏名 |
| メールアドレス | 申請対象者のメールアドレス |
| グループ | 事前に作成したグループ名 |
| 特記事項 | イレギュラーな要望など |
このワークフローから投稿された内容をトリガーに、Devin（@devin）がメンションされ、指示通りにコードを修正してPRを作成します。
セットアップを終えて
DevinとSlackの設定を終えた後は、次のフローでAWSユーザーの申請をおこないます。
DevinとSlackのセットアップは、初めて触る状態からでも半日もかからず完了しました。導入後は人間が対応する時間を少なくとも半分以下に削減でき、セットアップにかけた時間を大きく上回る効果を得られました。まずは小規模な定型業務から試してみることをお勧めします。
なぜDevinなのか
AIによるコーディング支援ツールは多々ありますが、なぜDevinを選んだのか。その理由は主に2点あります。
1. 非エンジニアでも利用可能なインターフェース
例えばClaude CodeのようなCLIベースのツールも強力ですが、非エンジニアが利用するにはハードルが高いです。「Slackでフォームに入力するだけ」という体験を提供するためには、Slackと統合しやすく、自律的にGit操作まで完結できるDevinが最適でした。
2. AIならではの柔軟性
定型的なスクリプト処理では、例外的なケース(例: 1回の申請で2名以上追加したい場合)へ対応するため条件分岐の実装コストがかかります。
Devinの場合、ワークフローの「特記事項」に自然言語で注釈を入れるだけで、よしなに判断して処理してくれます。この「人間の曖昧な指示を汲み取れる柔軟性」は、運用コストを下げる上で非常に大きなメリットです。
今後の展望
現在はAWSやGitHubのユーザー管理だけでなく、次のような領域にもDevinの活用を広げています。
- 新規AWSアカウント作成時に発生する初期設定(繰り返し作業)
- WordPressの簡単な文言変更
- DNSレコードの登録
私たちのチームでは、単純な自動化ではなくSRE x AIという視点を強く持ち、トイル削減と全社的な運用改善を推進していきます。
おわりに
今回は、ファインディで実践しているTerraformとDevinを組み合わせたユーザー管理の自動化についてご紹介しました。 「誰でもできる作業」をAIに任せることで、SREが「人間にしかできない価値ある活動」に集中できる環境作りを、これからも進めていきます。
ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。
