はじめに

こんにちは、 IT 本部 IT 基盤部 第三グループの渡邊です。IT 基盤部では、組織横断的に様々なサービスのインフラ運用を行っています。

DeNA では AI オールインのスローガンのもと、全社的に AI を活用した生産性の向上に取り組んでいます。¹

SRE の業務は多岐にわたります。サービスのインフラ運用、作業効率化のためのプロダクト開発、コスト削減、セキュリティ対応など、性質の異なるタスクを並行してこなす必要があります。組織横断で複数サービスを管掌し、障害対応や割り込みも多い中、AI ツールを駆使することで定常業務をこなしながら新たな施策に次々と取り組めるようになりました。

鍵となったのは、単一の手段に頼るのではなく、「自律型エージェント（Devin）」「AI 統合型エディタ（Cursor）」「汎用チャット AI（Gemini）」 という、性質やインターフェースの異なる 3 つをタスクに応じて使い分けたことです。本記事では、この 3 ツールの使い分け戦略と、定常業務をこなしながら施策を拡大できた具体的なワークフローを紹介します。

活用した AI ツールと選定基準

本記事で登場する AI ツールは 3 つです。それぞれの特性に応じて使い分けました。

選定の判断軸は 「タスクの仕様がどれだけ明確か」 です。仕様が固まっているほど Devin に任せやすく、不確実性が高いほど人間 + 対話型 AI の出番が増えます。

並行して進めた業務の全体像

2025 年 10 月から現在にかけて、定常業務（サービス運用・依頼対応・セキュリティ対応）を除き、以下の 5 つの施策を並行して進めていました。

稼働比率の約 50% はクラウド基盤移行 (AWS → Google Cloud) に、約 20% はエンジニア広報活動に充てており、残りの約 30% で他の 3 施策を進めていました。つまり、稼働の大半はインフラの移行作業と広報が占めており、開発系施策に割ける比率は限られています。この限られた時間の中で開発を前に進められたのは、Devin が自律的に実装を担ってくれたからです。

タスクの「委任可能度」を決める 3 つの軸

これらの施策を AI にどの程度任せるかは、以下の 3 つの軸で判断しました。

3 軸すべてが「委任しやすい」に該当するタスクは Devin に任せ、「人間が主導すべき」が 1 つでもあれば Cursor や Gemini で対話的に進めました。

クラウド基盤移行 (AWS → Google Cloud) は、全体像を把握できていない状態からのスタートで（仕様が不明確）、関係者との調整が多く（ステークホルダーが多い）、インフラの正しさは人間が判断する必要がある（フィードバックループが手動）ため、Cursor で対話的に進めました。

一方、レガシーシステムのモダン化は、既存の Perl 実装がリファレンスとして存在し（仕様が明確）、自分とコードだけで完結し（ステークホルダーが限定的）、テストで互換性を検証できる（フィードバックループが自動化可能）ため、Devin への委任度が最も高い施策でした。

重要なのは、人間の関与が不可欠な施策に集中している間も、Devin が開発施策を並行して進めてくれるという点です。この組み合わせが、定常業務をこなしながら施策を拡大することを可能にしました。

ある 1 日のワークフロー

並行業務がどのように回っているか、ある日のタイムラインを紹介します。

タイムラインを見ると、ミーティングや終業の直前に Devin に Issue をアサインしていることがわかります。Devin は Issue のアサインから PR 作成まで約 10 分で完了するため、自分が手を離している間に実装が進み、戻ってきたらレビューに取り掛かれます。

また、自分の作業時間の大半はインフラ構築（Terraform）やコードレビューに充てており、開発施策の実装に直接手を動かす時間はほぼありません。それでも開発が前に進むのは、Devin が自律的に実装を担っているからです。

終業時に翌日分の Issue をアサインしておけば、翌朝にはレビュー待ちの PR が届いている状態でスタートできるため、1 日の中でこのサイクルを繰り返し回すことができました。

インフラ系施策の進め方

このセクションでは、クラウド基盤移行 (AWS → Google Cloud) を中心に、インフラ系施策の進め方を紹介します。

Google Cloud 初挑戦と AI による立ち上がり

前述の通り、クラウド基盤移行は 3 つの軸のいずれも「人間が主導すべき」に該当するため、対話的に試行錯誤できる Cursor を選択しました。加えて、私自身 Google Cloud に携わるのは初めてで、AWS 環境の既存構成を読み解きつつ、Google Cloud のキャッチアップも同時に進める必要がありました。

Google Cloud のキャッチアップには Gemini も活用しました。Gemini の Gem 機能で「Google Cloud Expert」という専用のプロンプトを作成し、Google Cloud のベストプラクティスや公式ドキュメントに基づいた回答を効率よく得られるようにしていました。以下は、実際に使用した Gem のプロンプトです。

# プロンプト: Google Cloud Expert

あなたはトップレベルのGoogle Cloudアーキテクトであり、**Google Cloud公式ドキュメント、Google Cloud Architecture Framework、そして Google Cloud Next の最新発表**のすべてに精通しています。

あなたの使命は、**明確で信頼できるエビデンスに裏付けられた、最も安全で、コスト効率が高く、信頼性の高いソリューションを私たちに提供すること**です。

# 背景

私は日本の事業会社に所属するクラウドエンジニアです。

私たちの組織では、**セキュリティ、高可用性、そしてコスト最適化が最優先事項**です。
私たちのチームは、常に Google Cloud Architecture Framework に準拠したソリューションの設計を心がけています。
これから私がする質問は、日々の業務で直面している現実的な課題です。そのため、理論的な議論ではなく、実践的で信頼できる回答を求めています。

# 指示

ユーザーは Google Cloud に関する[質問]をあなたに入力します。
あなたは [質問] に対して、下記のすべての [制約] に厳密に従い、最終的なアウトプットを行います。
私に提供する最終的なアウトプットは、指定された [出力フォーマット] に厳密に従う必要があります。

## 期待される品質の例

「Cloud Storageバケットへのアクセスを特定のIPアドレスに制限するにはどうすればよいか？」という質問の場合、VPC Service Controls と IAM 条件（IAM Conditions）のような選択肢を比較し、このケースでは*なぜ*特定のアプローチが推奨されるのか（あるいは非推奨なのか）を説明し、具体的な設定例やポリシー例を提示し、エビデンスとなったリンクを含んだ、詳細かつ具体的な回答を期待します。

# 制約

* **簡潔かつ具体的であること**
  * 抽象的な言葉を避け、具体的なプロダクト名、パラメータ、gcloudコマンドやTerraformコードの断片、実行可能な手順を提示してください。
  * 解説は冗長さを排し、200 〜 300文字程度で本質を突く記述を心がけてください。
* **明確な論理的根拠を示すこと**
* **エビデンスを最優先にすること**
  * 回答は、Google Cloud公式ドキュメント、Google Cloud公式ブログ、またはArchitecture Framework等のホワイトペーパーへのリンクで裏付けなければなりません。
  * 個人的な意見、Stack Overflow等のフォーラムの回答、その他の信頼性の低いサードパーティ情報は避けてください。
* **非推奨な方法（アンチパターン）にも言及すること**
  * 一般的でありながら Google Cloud では推奨されないアプローチがある場合は、それらを簡潔に指摘し、なぜアンチパターンなのかを説明してください。
* **最新情報であること**
  * 回答は、[質問]された日付までの最新のサービス、プレビュー機能（必要に応じて）、およびベストプラクティスに基づいたものにしてください。

# 出力フォーマット

## 質問の要約
（ユーザーから与えられた質問を技術的な観点で要約して記載する）

## 結論
（質問に対するベストプラクティスとなる結論を簡潔にまとめる）

## 解説
（結論に至った理由、技術的な詳細、比較検討した代替案などを解説する）

## エビデンス
* [関連する公式ドキュメントのタイトル](URL)
* [関連する公式ブログ記事やホワイトペーパーのタイトル](URL)

## 備考
* この解決策を実施する上での重要なクォータ制限、IAM権限、または特定の条件下では非推奨となるケースについて記述する
* 補足したい内容をリスト形式で出力する

質問を投げると、結論・解説・エビデンス（公式ドキュメントのリンク付き）・アンチパターンを構造化して返してくれるため、未経験の Google Cloud 環境でも必要な情報を素早くキャッチアップできました。

Cursor による対話的なインフラ構築

今回のクラウド基盤移行は、単なる AWS → Google Cloud の乗り換えではありません。EC2 上で動作していたアプリケーションを Cloud Run に移行するため、コンテナ化も同時に進める必要がありました。つまり、Terraform によるインフラ構築とアプリケーションのコンテナ対応を並行して進める作業です。

ここで効果的だったのが、Cursor の Workspace にアプリケーション用のリポジトリと Terraform 用のリポジトリを両方追加する手法です。1 つのエディタからリポジトリを横断的にコンテキストとして渡せるため、「このアプリケーションの構成に合った Cloud Run の設定はどうすべきか」「Dockerfile の記述と Terraform のリソース定義に矛盾はないか」といった問いに対して、Cursor が両方のコードベースを踏まえた回答を返してくれます。

Cursor 上で壁打ちしながら、具体的には以下のような作業を進めました。

• 既存の AWS 環境の構成を読み解き、Google Cloud での対応リソースを整理
• アプリケーションのコードを参照しながら、コンテナ化に必要な変更を特定
• Terraform のコードを Cursor に記述させ、レビュー・修正を繰り返す
• 不明点やベストプラクティスについて対話的に確認

「この AWS リソースは Google Cloud だとどれに対応するか」「この構成のベストプラクティスは何か」といった問いに即座に答えてくれるため、未知の環境でも手戻りを抑えながら作業を進めることができました。

インフラ構築の裏で開発が進む

インフラ構築を進めている合間にも、Devin に依頼していた開発施策の PR のレビューを行っていました。Cursor の Workspace 上でアプリケーションと Terraform を横断的に作業する → Devin からの PR をレビュー → 再びインフラ構築に戻る、というサイクルで、異なる施策を効率的に切り替えながら進めることができました。

つまり、インフラ構築という主業務に集中しながらも、開発系のタスクは Devin が並行して進めてくれる。この組み合わせが、限られた時間の中で複数施策を前に進める鍵でした。

開発系施策の進め方

前章で触れた通り、インフラ構築の裏側で Devin が開発系施策を自律的に進めていました。ここでは、レガシー Web サービスのモダナイゼーション（Perl → Go 移行）を例に、Devin を活用した開発の具体的な進め方を紹介します。

先行事例のナレッジを活かした開発サイクル

同じ IT 基盤部の yayohei が執筆した「 Devin AI で挑む AI エンジニアによるレガシー API 移行 」では、Devin を活用した Perl から Go へのレガシー API 移行と、80-15-5 のワークフロー（Devin 80% / 人間によるレビュー・修正 15% / 周辺作業 5%）が詳しく紹介されています。本施策では、この先行事例で試行錯誤して得られたナレッジを最初から取り入れました。

先行事例から引き継いだ手法に加え、本施策では以下の点を発展させました。

• AGENTS.md の初期整備: 先行事例で蓄積されたナレッジを元に、施策開始時点からガードレールを整備
• 設計フェーズの導入: Devin にいきなり実装させるのではなく、まず設計を Issue にコメントさせ、承認後に実装を開始するフローを追加

Devin に渡す Issue の設計

レガシーシステムのモダン化では、まず Devin に既存の Perl コードを読ませ、関連するエンドポイントをグルーピングした親 Issue を作成させました。その後、人間がエンドポイントごとにサブ Issue を切ります。サブ Issue の中身は実装すべきエンドポイントの一覧だけで十分です。以下は実際の Issue と同じフォーマットで作成した例です（内容は架空のものです）。

## 実装するエンドポイント

- GET /:service/host/:hostname/tags - タグ一覧
- GET /:service/host/:hostname/tags/:tag_id - タグ詳細
- POST /:service/host/:hostname/tags/:tag_id/confirm - 確認画面
- POST /:service/host/:hostname/tags/:tag_id/execute - 実行

このサブ Issue を Devin にアサインすると、Devin が Perl のコードを読み解いて詳細な設計書を Issue のコメントとして投稿してくれます。この設計フェーズについては後述します。

一方、運用最適化ツールの開発のようにリファレンスとなる既存コードがない新規開発では、入出力の定義や処理フロー、エラーハンドリングの方針など、Devin が自律的に判断できるだけの仕様を Issue 側に明確に書く必要がありました。

AGENTS.md によるガードレール

Devin を活用する上で重要なのが、プロジェクトのルールを定義する AGENTS.md の整備です。 AGENTS.md は AI エージェントにコンテキストと指示を提供するためのオープンな標準フォーマットで、Devin はコーディング開始前にこのファイルを自動で読み込みます ⁵。

先行事例では、プロジェクトを進めながら AGENTS.md を育てていく形でしたが、本施策ではそのナレッジを活かして施策開始時点から以下の項目を整備しました。

• 概要: 技術スタック、移行方式、目標
• 必須ルール: 設計ファースト、TDD 厳守、既存システムとの互換性（最重要）
• アーキテクチャ方針: レイヤードアーキテクチャの各層の責務と依存関係
• Issue の進め方: 設計 → 承認 → 実装のワークフロー
• PR 作成ルール: サイズの目安、品質チェックコマンドの実行

レビューで発見した問題点は AGENTS.md に随時反映していきます。サイクルを繰り返すうちに Devin の出力精度が向上し、失敗が減るにつれて AGENTS.md の更新頻度も下がっていきました。結果として、開発サイクル全体が徐々に高速化していきました。

設計フェーズの導入

先行事例では REST API の移行であったため、OpenAPI 仕様書でリクエスト・レスポンスのスキーマを定義し、それを実装の指針とするアプローチが有効でした。一方、本施策は HTML テンプレートを返す Web サービスの移行であり、OpenAPI のような形式的な仕様定義が難しいため、代わりに設計を Issue にコメントさせ、承認してから実装を開始するフローを導入しました。

1. サブ Issue を Devin にアサイン
2. Devin が既存の Perl コードを読み解き、設計書を Issue のコメントとして投稿
3. 私が設計書をレビュー・承認
4. Devin が実装を開始し、PR を作成
5. 私が PR をレビュー、Cursor で修正

Devin への依頼プロンプトはシンプルです。

<Issue の URL> をアサインします。
@AGENTS.md のルールに従い、まず設計から始めてください。

たったこれだけで、Devin は Issue のエンドポイント一覧と既存の Perl コードを読み取り、AGENTS.md のルールに従って設計を開始し、承認後に実装まで完遂してくれます。

「人間が承認するなら、最初から Cursor で設計して Devin には実装だけ渡せばいいのでは？」と思われるかもしれません。Cursor で設計する場合、対話的にやり取りしながらコードベースを読み解いていく必要があり、その間は人間の手が拘束されます。一方 Devin であれば、1 回の指示で自律的にコードベースを読み込み設計書を出すところまで完遂してくれます。人間は出来上がった設計書を読み、必要であれば修正を指示するだけで済むため、設計フェーズ自体も Devin の自律性を活かしたほうが効率が良いというのが実感です。設計案のレビューは数分で終わるため、他の施策の合間に処理でき、実装後の大きな手戻りを低コストで防ぐ軽量なチェックポイントとして機能しました。

成果

定常業務をこなしながら施策を拡大できた理由

定常業務をこなしながら新たな施策に次々と取り組めるようになった最大の要因は、Devin が自律的に開発タスクを進めてくれる間に、人間は別の施策に集中できるという点です。

以前であれば、レガシーシステムのモダン化や運用最適化ツールの開発のような施策は自分で手を動かして実装する必要がありました。しかし、Devin に実装を委ねることで、その時間をインフラ移行や定常業務など人間が主導すべき施策に充てられるようになりました。Devin から PR が上がってきたらレビューし、修正を加えて次の Issue をアサインする。このサイクルの中で生まれる「待ち時間」が、並行業務を増やす原動力になっています。

各施策の現状

各施策の成果と現状を整理します。

クラウド基盤移行 (AWS → Google Cloud) は、本番環境を含むすべての移行が完了しています。

レガシーシステムのモダン化は、本記事の公開時点で完了しています。Perl 製 Web サービス 10,846 行（86 ファイル）を Go 製 8,750 行（40 ファイル）に移行しました。本番環境への導入から 2 か月弱が経過していますが、問題なく稼働しています。先行事例であるレガシー API 移行（約 6,000 行の Perl → Go 移行）で蓄積されたナレッジを最初から活かせたことで、4 つの他施策を並行して進めながらも本施策に費やした時間は約 85 時間でした。ナレッジの蓄積と再利用が、施策の効率に直結することを実感しています。

運用最適化ツールの開発は実装フェーズが完了し、現在は検証フェーズに入っています。

また、本記事で紹介した Issue の設計方法や AGENTS.md の整備方法、設計フェーズの有効性といったナレッジはチームメンバーにも共有し、現在ではメンバーも Devin に開発を任せるスタイルが定着しています。

失敗談と課題

AI との協業は万能ではありません。ここでは、AI を活用する中で直面した失敗と課題を共有します。

人間がやるべきことまで Devin に任せようとした

前述の「委任可能度の 3 つの軸」で判断すれば人間が主導すべき領域にもかかわらず、Devin に任せてしまった失敗があります。

施策の初期段階で、Issue の作成やタスクの整理といったプロジェクト管理業務を Devin に任せようとしました。しかし、0 からのスタートでガードレールが整備されていなかったため、不要な Issue が大量に生成されてしまい、Devin のリソース (ACU) ⁶ を無駄に消費する結果となりました。

プロジェクト管理は仕様が曖昧でステークホルダーとの調整も必要な、まさに「人間が主導すべき」タスクです。Devin には明確な仕様が定義された実装タスクを任せるのが最も効果的であり、何を委任し何を自分でやるかの見極めが重要だと痛感しました。

Web UI 実装の精度問題

Perl のリポジトリを参照させて Web UI (HTML / テンプレート) の実装を行わせましたが、メッセージの出力箇所が間違っていたり、レイアウトがずれていたりと、DOM の構造を正しく理解できていないことに起因する問題が頻発しました。

対策として、「まず DOM の構造を理解してから実装を進める」ようルールを書き加えたところ、精度は向上しました。しかし、最後まで 1 度の依頼で完璧に実装できることはなく、画面のレビューに時間がかかってしまいました。

なお、ブラウザの描画結果を AI に渡す手法も存在します。たとえば Playwright MCP は、ブラウザ操作ライブラリ Playwright を MCP（Model Context Protocol）サーバーとして公開するツールで、AI エージェントがブラウザのスクリーンショットやアクセシビリティツリー（DOM の構造化された表現）を取得できるようになります。これにより、AI はソースコードだけでなく実際の描画結果を見ながら UI を修正できます。しかし、本施策の時点では Devin のワークフローにこうしたツールを組み込めておらず、コードレベルでの対策に留まりました。Devin がブラウザの描画結果を直接フィードバックとして受け取れるようになれば、Web UI 実装の精度はさらに向上すると期待しています。

インフラ運用における AI の境界線

Devin には自律的なタスク完遂を求めていますが、terraform apply のような実環境の状態を変更する操作はまだ任せていません。認証情報を Devin に渡すことはせず、インフラの変更適用は人間が行うという線引きをしています。

現在取り組んでいるのは、GitHub Actions 上で terraform plan を実行し、その結果を Devin が確認して自律的にコードを修正するというワークフローです。Devin は plan の出力を読み取り、エラーや差分を解消するためのコード修正を行いますが、最終的な apply（状態の変更）は人間が判断・実行します。

SRE の業務では、「間違ったコードを書く」リスクと「間違った変更を本番環境に適用する」リスクは質が異なります。コードの誤りは PR レビューやテストで防げますが、インフラの状態変更は取り返しがつかないケースもあります。この境界線をどこに引くかは、AI の信頼性が向上するにつれて変わっていくでしょうが、現時点では 「コード生成は AI、状態変更は人間」 という分担が妥当だと考えています。

まとめ

本記事では、Devin・Cursor・Gemini の 3 つの AI ツールを使い分け、定常業務をこなしながら新たな施策に次々と取り組んだ SRE の働き方を紹介しました。

この戦略を支える 3 つの鍵を整理します。

1. タスクの性質で AI ツールを選ぶ: 仕様の明確さ・ステークホルダー・フィードバックループの 3 軸で委任可能度を判断し、ツールを使い分ける
2. 「待ち時間」を設計する: Devin の実装待ち・会議・休憩を別の施策の作業時間に変換する。1 日の中でこのサイクルを繰り返すことが並行業務の原動力になる
3. ガードレールに投資する: AGENTS.md と設計フェーズで Devin のアウトプット品質を上げれば、レビュー時間が減り、さらに並行業務に時間を割ける好循環が生まれる

AI ツールの進化は目覚ましく、インフラの状態変更のような「現時点では人間が判断すべき領域」も、今後は AI に委任できる範囲が広がっていくでしょう。その変化に対応するためにも、何を AI に任せ、何を人間が判断するかの基準を常にアップデートし続けることが重要だと感じています。

DeNA では、AI を活用した生産性向上の取り組みが組織全体で進んでいます。本記事が、AI ツールを開発プロセスに取り入れることを検討されている方々の参考になれば幸いです。

最後までお読みいただき、ありがとうございました。

脚注