Perl 6000行のレガシーAPIを、AIエージェントを駆使してGoへ移行する。DeNAのエンジニアリングブログで公開されたこの事例は、AIコーディングの可能性と限界の両面を鮮やかに描いています。
結果として移行は成功しましたが、それでも約1ヶ月を要しました。この事例が突きつけているのは「AIにコードを読ませれば移行できる」という楽観への、データに基づいた反証です。
AIエージェントがPerl固有の文脈を読めなかった
DeNAの事例で象徴的だったのは、Devinが既存のPerlコードからOpenAPI仕様書を生成する際、一部のエンドポイントを取りこぼした件です。
原因は、Perlの予約語 delete との衝突を避けるために使われていた delete_ というサフィックス。この命名慣習はPerlコミュニティでは一般的ですが、Devinはこの関数をHTTPのDELETEメソッドとして認識できず、仕様書からスキップしてしまいました。
同じタスクをClaude Codeに投げたところ、Perlの文脈を理解して正確に検出できたとのことです。ここで浮き彫りになるのは、コードの構文を読めることと、コードの意図を読めることは別の能力であるという事実です。
delete_ という命名にはWhyがあります。「Perlの予約語と衝突するから」という設計判断です。しかしこのWhyはコードのどこにも明示されていません。コメントにも、ドキュメントにも。コードを読めるAIエージェントでさえ、この暗黙の文脈を見落としました。
テスト比較という「正解の定義」
DeNAのチームがこの課題を乗り越えた方法は、徹底的なテスト戦略でした。
Perl版とGo版の両方に同一のリクエストを送り、レスポンスとデータベースの更新内容が完全に一致することを検証する比較検証フレームワークを構築。185件のテストケースで正常系・異常系を網羅し、「Perl版と同じ振る舞いをすること」を自動的に担保しました。
このアプローチは極めて実践的です。移行プロジェクトでは「正しい動作」の定義が既存システムの振る舞いそのものになるため、差分比較が品質の生命線になります。PRの承認基準も「テストが全パスすること」に集約され、人間のレビュー負荷を大幅に軽減しています。
テストだけでは埋まらないギャップ
しかし、この成功事例を裏返すと、ひとつの問いが浮かびます。
テストは「What（何が正しいか）」を検証できますが、「Why（なぜそうなっているか）」は検証できません。
たとえば、移行後のGoコードを将来的に改修する際、「この処理はなぜPerl版と同じ振る舞いを維持しているのか」を知る手段は何でしょうか。テストは「変えてはいけない」ことは教えてくれますが、「なぜ変えてはいけないのか」は教えてくれません。
DeNAの事例でも、プロジェクトの教訓として「初期の指示が曖昧だったことが最大の反省点」「明確なルールをAIと共創する"メタワーク"が成否を分ける」と振り返られています。これはまさに、実装の外側にある設計意図の伝達が、AIとの協業において本質的に重要であることを示唆しています。
コードから独立した設計記録という発想
sqlewが提唱するのは、設計意図をコードから切り離して構造化し、永続化するアプローチです。
DeNAの事例に当てはめると、たとえば以下のような情報が方針・誓約として記録されていれば、Devinの取りこぼしは防げた可能性があります。
方針: Perlの予約語と衝突する関数名には
_サフィックスを付与する慣習がある。delete_はHTTP DELETEメソッドに対応するエンドポイントである。誓約: OpenAPI仕様書の生成時には、サフィックス付き関数名をHTTPメソッドに正しくマッピングすること。
コードを読み解く能力がどれほど高くても、コードに書かれていない情報はコードからは得られません。テストは出力の正しさを検証しますが、意図の伝達は別の仕組みが必要です。設計記録をコードから独立させることで、言語移行の前後を問わず、AIエージェントが「なぜそうなっているか」を参照できるようになります。
レガシーコードの移行は、技術的負債の返済であると同時に、散逸した設計意図を再構築する好機でもあります。コードは書き換わっても、Whyは引き継がれるべきものです。
参考文献
- DeNA Engineering Blog「Devin AI で挑む AI エンジニアによるレガシー API 移行」 — https://engineering.dena.com/blog/2025/12/legacy-code-migration-using-devin/
- "Rediscovering Architectural Decision Records: How Persistent Design Context Improves LLM Code Generation" — Shingo Kitayama (2026) — https://doi.org/10.36227/techrxiv.177205025.54351571/v2
