Devin AIを活用したAIエンジニアによるレガシーAPI移行プロジェクト [DeNA インフラ SRE]

こんにちは。IT 本部 IT 基盤部第一グループの山本です。

2025 年 10 月末から 11 月末にかけて、2018 年に実装された約 6,000 行の Perl 製サーバー資産管理 API を Go へ移行するプロジェクトに取り組みました。このプロジェクトでは、自律型 AI ソフトウェアエンジニア「Devin」と対話型エージェント「Claude Code」という、特性の異なる 2 つの AI エージェントを活用しました。

本稿では、AI エージェントをどうマネジメントし、チームとして機能させたのか。その具体的なプロセス、直面した課題、そして得られた教訓について解説します。AI エージェントを開発プロセスに取り入れることを検討されている方々の参考になれば幸いです。

注：本稿は 2025 年 10 月〜11 月時点での経験に基づいています。AI エージェントの能力は日進月歩で改善されているため、本稿で述べる特性や課題は将来的に変化する可能性があります。

AI エージェントとの協業により、以下の成果を得ることができました。

Perl 約 6,000 行 → Go 約 10,000 行

約 1 ヶ月 (2025 年 10 月末〜11 月末)

Devin 80% / Claude Code 15% / 人間 5%※

Perl 版と Go 版の完全互換性をテストで担保

※ この 5% は実装・レビュー工程における割合です。プロジェクト全体で見ると、テスト計画の策定、AI への指示出し、テスト修正の依頼といったプロジェクトマネジメント業務を含めて、人間の関与は約 30% となります。

特筆すべき点として、Devin による大量の Pull Request 作成（80% の実装）と Claude Code による品質向上（15% の改善）を組み合わせることで、開発速度と品質担保を両立できました。

Go 版の行数が増加（約 1.7 倍）した主な理由は以下の通りです：

明示的なエラーハンドリング: Go の if err != nil

型定義の追加：構造体とインターフェイス定義による型安全性の向上

階層構造の導入：レイヤードアーキテクチャ（Handler/Service/Repository 層）による保守性の向上

1. プロジェクト概要：移行対象のレガシー API

本プロジェクトの挑戦の大きさを理解いただくために、まずは移行対象となった「Admintool API」の概要からご紹介します。この API の背景、規模、そして技術スタックを把握することは、後に続く AI との協業戦略の重要性を理解する上で不可欠です。

以下に、このレガシー API の主な特徴をまとめました。

役割：物理サーバーおよび仮想サーバーのライフサイクル全体（資産登録、構成変更、廃棄など）を管理する、サーバー資産管理システムの根幹をなす API

コード規模：合計 約 6,000 行

技術スタック：Perl 5, Amon2 (Web フレームワーク), Teng (O/R マッパー)

この規模と複雑性を持つ API を、仕様を維持したまま正確に移行するには、膨大な工数と緻密な品質管理が求められます。この大きな壁を乗り越えるため AI エンジニアの力を借りる決断をしました。

1. 我々の AI チームメイト：Devin と Claude Code の役割分担

プロジェクト成功の鍵は、適切な人材を適切なタスクに割り当てることです。これは AI に対しても同様です。特性の異なる2つの AI エージェント、Devin と Claude Code を採用し、それぞれの長所を最大限に活かす役割分担を行いました。これは、単一の AI にすべてを任せるのではなく、AI による「チーム」を編成し、マネジメントするアプローチです。

両者の特性と役割は、以下の表のように対比できます。

複雑なタスクを自律的に完遂する独立した AI ソフトウェアエンジニア

開発者と対話しながら開発する実務特化型エージェント

曖昧さの少ない作業、大量の Issue や Pull Request の並列作成

対話を通じた詳細な修正、エッジケースのバグ修正

指示を一度受けると最後まで自律的に完遂させる

対話形式で試行錯誤を繰り返しながら品質を高める

ざっくりした依頼で及第点の成果を納品する「外部の発注会社」

横で方針を伝えながら一緒に実装を進める「ペアプログラマー」

Devin にはプロジェクト全体の骨格を作る大規模な作業を、Claude Code には細部の品質を高める精密な作業を任せる。この戦略的な役割分担が、後の開発プロセスを円滑に進めるための土台となりました。

1. AI との協業プロセス：スキーマ駆動開発の実践

Step 1: OpenAPI 仕様書の生成

まず、プロジェクトの出発点として、Devin に既存の Perl コードベース全体を解析させ、API の仕様を定義する openapi.yaml

タスク：OpenAPI 仕様書の生成 既存の Perl コードベース（lib/Admintool/API/Controller/）を解析し、OpenAPI 3.0 形式の仕様書を作成してください。 ## 要件 - すべての HTTP エンドポイントを網羅的に抽出 - リクエスト/レスポンスのスキーマを定義 - 各エンドポイントの説明とパラメータを記載 ## 成果物 - openapi.yaml ファイル - エンドポイント一覧のドキュメント

Step 2: AI によるコード理解度の壁

しかし、ここで最初の課題に直面します。Devin が生成した仕様書には、いくつかのエンドポイントが欠落していました。

実際のコードと照らし合わせて原因が分かりました。Perl では予約語 delete

試しに同じタスクを Claude Code に投げてみると、こちらは Perl の文脈を理解して正確に検出してくれました。AI によって得意な言語・苦手な言語があることを、ここではじめて実感しました。

Step 3: 最適なワークフローの確立

最終的に人間と Claude Code で完成させた openapi.yaml

試行錯誤の結果、以下の分業体制に落ち着きました：

必ず JSON 形式で返してください。translation フィールドのみ。他のフィールド (technical_terms 等) は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:

{"translation": "翻訳全文"}

タスク：エンドポイントの実装

openapi.yaml に基づいて、各エンドポイントの Golang 実装を行ってください。

作業手順

1. エンドポイント毎に GitHub Issue を作成
2. 各 Issue ごとに Pull Request を作成
3. Gin フレームワークを使用してルーティングを実装
4. SQLx でデータベースアクセスを実装
5. テストコードを作成（既存の Perl テストケースを参考に）

実装ルール

• データベーストランザクション管理を適切に行う
• Perl 版の挙動を忠実に再現する

注意事項

• CI/CD でテストが失敗した場合は修正を試みること

この「80-15-5」のワークフローにより、開発速度と品質担保を高いレベルで両立させることができました。

1. 品質の生命線：AI 時代のテスト戦略と CI 環境

AI が生成したコードは、一見すると正しく動作しているように見えます。しかし、その信頼性を担保するには、人間による目視レビューだけでは不十分です。AI との協業において、堅牢な自動テスト環境こそが品質の生命線であると確信しました。

プロジェクトでは、移行元と移行先の API を厳密に比較検証するためのテスト基盤を構築しました。特筆すべき点として、このようなテスト結果の比較検証フレームワークは本来であれば後回しになりがちですが、AI エージェントの力を借りることで数時間で実装を完了できたことが、プロジェクト全体の成功を支える重要な要因となりました。

このテスト基盤では、専用の比較検証ツールを開発し、テスト実行後に Perl 版と Go 版の差分を視覚的に確認できるようにしました。

実際のテスト結果比較画面（レスポンスと DB 状態の差分を並列表示）

AI エージェントの支援により構築したテスト基盤の規模は以下の通りです：

185 件（正常系: 143 件 / 異常系: 34 件 / その他: 8 件）

テスト環境：Perl 版 API と Go 版 API、そしてそれぞれが使用するデータベースを Docker コンテナー化。これにより、完全に同一の条件下で両者を比較できるテストベッドを実現しました。

シナリオテスト：テストケースを YAML ファイルで定義し、テストランナーがそのシナリオに基づき Perl 版と Go 版の両方の API にまったく同じリクエストを送信する仕組みを構築しました。

成功の三箇条：テストが成功と見なされるには、以下の3つの条件がすべて満たされる必要があります。

• Perl 版 API がシナリオ通りのレスポンスを返すこと（正解の定義）
• Perl 版と Go 版のレスポンスが完全に一致すること
• Perl 版と Go 版の DB 更新内容が完全に一致すること

この厳格なテストの仕組みは、プロジェクトにおける品質確保に繋がりました。異常系まで網羅したテストケースにより、移行後の API が元の Perl 版と完全に互換性があることを自動的に検証できるようになりました。

「AI に自律的な作業を安心して任せるには、品質を自動で検証する仕組み（ガードレール）を整備することが極めて重要である」

ということです。

1. 総括：AI エンジニアと効果的に協業するための4つの教訓

この挑戦的なプロジェクトを通して、AI をソフトウェア開発の現場で最大限に活用するための、いくつかの普遍的な教訓を得ました。これらを4つのポイントに整理してご紹介します。

教訓1：適材適所で AI を使い分ける

Devin は「外部の発注会社」のように、一度指示を与えれば自律的に大量のタスクをこなしますが、途中の軌道修正は得意ではありません。一方、Claude Code は「ペアプログラマー」として、対話を通じて細かなニュアンスを汲み取り、共に品質を高めていく作業に適しています。今回のプロジェクトではこれらのツールを使い分けることで生産性を最大化できました。

教訓2：AI を計画パートナーとし、明確なルールを共創する

プロジェクトを振り返って最大の反省点は、初期の指示が曖昧だったことです。「このレガシープロジェクトを移行して」という漠然とした指示では、AI も曖昧な成果物を生成しました。対策としては、実装を始める前に、「計画のパートナー」としても活用することが必要でした。「PR やテストなど成果物の出力を定義する」「どのような進め方が最適か」といったプロジェクトのルールや方法論そのものを、最初に AI と対話しながら固めることも有用と考えます。明確なルールを AI と共創する、この「メタワーク」はプロジェクトの成否を分ける鍵となると思います。

教訓3：人間の役割は「アーキテクト」と「プロジェクトマネージャー」へ

AI との協業は、エンジニアの役割を根本から変えます。実装・レビューでの人間の関与は5%でしたが、プロジェクト全体では約30%の工数を費やしました。その内訳は、以下のようなプロジェクトマネジメント業務です。

プロジェクトマネジメントの具体例：

テスト戦略の策定: どのようなテストケースが必要か、どの粒度でテストを書くべきかの方針決定

AI への指示出し: Devin に対する明確なタスク定義と期待する成果物の仕様作成

品質基準の設定: CI/CD で何をチェックするか、どこまでの互換性を担保するかの基準決め

テスト修正の依頼: AI が生成したテストの不備を見つけ、修正指示を出す

進捗管理: 各エンドポイントの実装状況の追跡と優先順位の調整

エンジニアの仕事は、Devin と Claude Code が協業する「80-15-5」のようなワークフロー全体を設計する「アーキテクト」になること。そして、Devin が生成し、Claude Code がレビューした成果物に対し、AI ペアが見落としがちな最後の数パーセントのニュアンスやビジネス上の機微をチェックする「最終品質保証人」としての役割を担うことでした。今回は移行プロジェクトで正解を既存の振る舞いとしたことにも起因しますが、より高次のシステム設計と最終責任へと人間の役割がシフトできることを意味します。

教訓4：CI/CD は「学習する AI」を活かすための信頼の砦

まだ AI の生成物を盲信すべきではありません。今回の移行プロジェクトでは互換性を担保する CI/CD という揺るぎない「ガードレール」があるからこそ、AI に自律的な作業を安心して任せることができます。さらに興味深いことに、このガードレールは、AI の「学習能力」を安全に引き出すための土台ともなりました。プロジェクトが進むにつれて Devin が提出する Pull Request からミスが減っていき、レビューが件数が減少したことで明らかにコードが改善されていると感じられました。

本稿では、約6,000行のPerl製レガシーAPIをGoへ移行する際の、AIエージェントとの協業事例を紹介しました。

開発速度と品質の両立: 80-15-5のワークフロー（Devin 80% / Claude Code 15% / 人間 5%）により、約1ヶ月で実装を完了

AI の適材適所: 自律型 AI と対話型 AI の特性を活かした役割分担が有効

品質担保の重要性: CI/CD（継続的インテグレーション・継続的デリバリー）による自動テストが AI との協業における信頼の砦となる

明確な指示の必要性: AI に対する曖昧な指示ではなく、明確なルールと期待値の設定が成功の鍵

AI のプログラミング実装はまだ万能ではありません。とくにPerl固有の文脈理解では課題が見られました。一方で、Devin のプロジェクト全体を一貫して参照できる能力は、長期タスクにおいて大きな強みとなりました。

AI エージェントを開発プロセスに導入する際は、以下の点に留意することをオススメします。

段階的導入: 小規模タスクから開始し、品質を確認して徐々に範囲を拡大

明確な品質基準: テスト自動化などのガードレール（安全装置）を事前に整備

適切な役割分担: AI の特性を理解した上でタスクを割り当て

本稿が、AI エンジニアとの協業を検討されている方々の参考になれば幸いです。

最後まで読んでいただき、ありがとうございます！この記事をシェアしていただける方はこちらからお願いします。