導入部：レガシーシステムに囲まれた日常と、AIへの憧れ
こんにちは。39歳の中国人エンジニアです。もしかすると、この記事を読んでいるあなたも、僕と同じような環境にいるのではないでしょうか。
.NET Framework 4.5で書かれた巨大なWindowsアプリケーション。Visual Studio 2013の古いプロジェクトファイル。NuGetパッケージは古いバージョンで固定され、最新のライブラリは「互換性の問題で導入できません」。そんな環境で、日々バグ修正と機能追加に追われている。
一方で、TwitterやQiitaでは「AI駆動開発」「生産性3倍」「Devinすごい」という華々しい話題が飛び交っています。僕も、そんな最新技術の波に乗り遅れたくない。でも現実は、8年前のコードベースと格闘する毎日です。
2025年の春、僕は日本の基幹産業・製造業のDXをリードするnexta社に、業務委託として参画しました。フルリモートという現代的な働き方ができるこの会社で、僕に与えられたミッションは、「AI利活用を推進し、開発チームの生産性を劇的に向上させる」という、なんとも胸躍るものでした。
「ついに僕も、AIの力を借りて、この古いシステムを現代的に生まれ変わらせることができる」
僕の頭の中は、当時話題沸騰中だった自律型AIエージェント「Devin」のことでいっぱいです。「Devinを使えば生産性3倍は固いだろう」「チケットを渡して、あとはポチポチするだけでコードが完成するらしい」。そんな、まるで魔法のようなツールに対する期待を、僕は疑いもなく信じていました。
しかし、そんな僕の甘い期待は、業務開始初日にして、木っ端微塵に打ち砕かれることになります。僕が対峙することになったのは、想像以上に手強い相手でした。8年以上前に.NET Framework 4.5で書かれた、複雑に絡み合った依存関係を持つ巨大なレガシーWindowsアプリケーション。Devinがその真価を発揮できるような、モダンな開発環境とは程遠い、まさに「AI泣かせ」の現場だったのです。
この記事では、そんな僕が「Devinへの幻想」と現実のギャップに苦しみながらも、レガシーシステムとAIをいかにして共存させ、現実的な価値を引き出していったのか、そのリアルな奮闘の記録をお届けします。もし、あなたも同じような環境で、AIの導入に悩んでいるなら、この記事が少しでも参考になれば幸いです。
第1章：幻想その1「Devinを使えば生産性3倍になる」の嘘
「生産性3倍」という魔法の言葉。しかし、現実はそう甘くありませんでした。確かに、単純なバグ修正や定型的なリファクタリングといった、明確に定義されたタスクにおいては、Devinは人間を遥かに凌駕するスピードを発揮しました。これまで1時間かかっていた作業が、わずか10分で完了することも珍しくありませんでした。
しかし、それはあくまで「Devinがスムーズに作業できる環境」が前提の話です。僕たちのレガシーシステムでは、まずその前提が崩れていました。Windows固有のAPIに依存したコード、複雑に絡み合った依存関係、そして何より、Devinの仮想マシン上ではビルドすらできないという根本的な問題。これらの障壁が、Devinの生産性を著しく低下させたのです。
結果として、プロジェクト全体での生産性向上は、当初期待していた「3倍」には遠く及ばず、よくて1.2倍程度というのが現実でした。この経験から僕が学んだのは、AIの生産性は、タスクの性質だけでなく、それを取り巻く「環境」に大きく左右されるという、至極当然の事実でした。
第2章：幻想その2「ポチポチすればコードは完成する」の罠
次に僕を打ちのめしたのが、「ポチポチすればコードは完成する」という幻想です。確かに、Devinは驚くほど自律的にタスクをこなします。しかし、それは決して「魔法の杖」ではありません。むしろ、Devinは「非常に優秀だが、文脈理解に限界がある新人のエンジニア」と捉えるのが適切でしょう。
曖昧な指示では、Devinは平気で頓珍漢なコードを生成します。期待する動作、修正すべき範囲、考慮すべき制約条件。これらを人間が正確に、そして具体的に「プロンプト」として与えて初めて、Devinはその能力を発揮できるのです。
例えば、「ユーザー情報更新機能を改善して」という曖昧な指示では、Devinは的外れな修正を延々と繰り返すばかりでした。しかし、「ユーザー情報更新時の電話番号フォーマット検証機能を追加。日本の市外局番から始まる形式（例：03-1234-5678）を正規表現で検証し、不正な場合はエラーメッセージを表示すること」と具体的に指示することで、初めて期待通りのコードが生成されたのです。
「ポチポチするだけ」どころか、Devinを使いこなすには、高度なプロンプトエンジニアリングの技術と、システムの仕様を深く理解した上での的確な指示が不可欠でした。AIとの「協働」とは、決して楽をすることではなく、より質の高いコミュニケーションを求められる、新たな挑戦だったのです。
第3章：レガシーシステムという現実の壁
Devinとの付き合い方が少しずつ見えてきた僕の前に、改めて大きく立ちはだかったのが、レガシーシステムそのものという、分厚く、そして高い壁でした。
- Windows固有の制約: DevinはLinuxベースの環境で動作するため、Windows固有のAPIやライブラリに依存したコードは、CI/CDパイプラインを介しても、根本的な解決にはなりません。ビルドはできても、実行時に予期せぬエラーが発生することが頻発しました。
- 古い技術スタック: .NET Framework 4.5という古い技術スタックは、現代的な開発ツールやライブラリとの互換性が低く、Devinが生成したコードがそのままでは動かないケースも多々ありました。
- 環境構築の困難とドキュメント不足: そもそも、この巨大なアプリケーションの完全な開発環境をローカルで再現すること自体が、もはや不可能に近い状態でした。手順書は存在せず、すべてはベテランエンジニアの頭の中。フルリモート環境では、この暗黙知をDevinに伝える術がありませんでした。
これらの問題は、Devinの能力以前の、もっと根深い問題です。僕は、AIという最新鋭の戦闘機を手にしながら、ぬかるんだ沼地で戦っているような無力感を覚えていました。
第4章：現実的なDevin活用戦略
このままでは、Devinは宝の持ち腐れになってしまう。僕は、戦略の転換を迫られました。Devinに「魔法」を期待するのではなく、あくまで「ツール」として、現実的な範囲で最大限に活用する方法を模索したのです。
- Jenkins CI/CDパイプラインによる間接的活用: これまでお話ししてきた通り、Devinが直接触れない環境は、Jenkinsを介して間接的に操作させる。これが、レガシーシステムと付き合う上での基本戦略となりました。
- タスクの粒度調整とACU効率化: Devinの課金単位であるACUの消費を抑えるため、僕は戦略的なアプローチを採用しました。まず、無料で利用できる「Ask Devin」機能を活用し、実際のセッションを開始する前に、仕様確認、計画立案、タスク分割、そして最適なプロンプトの作成を済ませるのです。
例えば、「ユーザー管理機能の改修」という大きなタスクがあった場合、Ask Devinで以下のような事前準備を行います：
- 仕様確認: 「現在のユーザー管理機能の構造と、改修が必要な理由を整理してください」
- 計画立案: 「この改修を段階的に進めるための最適なアプローチを提案してください」
- タスク分割: 「この改修を、それぞれ1-2時間で完了できる小さなタスクに分割してください」
- プロンプト作成: 「各タスクに対する、具体的で曖昧さのないプロンプトを作成してください」
この事前準備により、実際の有料セッションでは、Devinが迷うことなく効率的に作業を進められるようになりました。結果として、タスクあたりのACU消費量は平均で約40%削減することに成功しました。
3. 得意な領域への集中: Devinには、環境依存の少ない、独立したロジック部分の修正や、単体テストコードの生成といった、得意なタスクに集中してもらう。苦手なUI周りや、複雑な依存関係を持つ部分は、引き続き人間が担当する。この役割分担が、チーム全体の生産性を最大化する鍵でした。
これらの戦略によって、僕たちはDevinを「高価だが、特定の作業においては非常に優秀なアシスタント」として、チームに組み込むことに成功しました。しかし、僕の心の中には、まだ満たされない思いが残っていました。「もっと根本的な解決策があるはずだ」と。
第5章：技術的負債という根本問題と、Blazor化という解決策
「戦場を変えよう」
僕がたどり着いた結論は、シンプルでした。しかし、その背景には、もっと深刻な問題への気づきがありました。それは、僕たちが直面している本当の敵は、Devinとの相性の悪さではなく、「技術的負債」という、もっと根深い問題だったということです。
技術的負債という「システムの借金」
レガシーWindowsアプリケーションを前に、僕は一つの重要な事実に気づきました。僕たちが抱えている問題は、まさに「技術的負債」の典型例だったのです。技術的負債とは、簡単に言えば「システムの借金」です[1]。現実の借金と同じように、元本があり、利息が発生し、時間が経てば経つほど複利で増えていきます。
僕たちのレガシーシステムは、まさに「高金利の技術的負債」の塊でした[1]：
- 特定の人しか理解できないシステム: ベテランエンジニアの頭の中にしかない暗黙知。この人が退職すれば、金利が一気に跳ね上がる変動金利型の危険な借金です。
- 実態に即していないデータ構造: 8年前の想定で作られたデータ構造が、現在の運用実態と乖離している。修正するたびに高額な利息を支払うことになります。
- 重要な部分の品質チェック不足: 古いコードベースでは、自動テストが不十分。いつか必ず「事故」という形で高額な利息を払うことになる時限爆弾です。
一方で、Devinが得意とするモダンな開発環境は、「低金利の技術的負債」[1]、もしくは負債そのものが少ない環境です。標準的な開発環境、シンプルな依存関係、容易なテスト。これらが揃っているからこそ、AIは水を得た魚のように能力を発揮できるのです。
なぜ「戦場を変える」必要があるのか
技術的負債の管理には、4つのアプローチがあります[1]：
- フルリプレース（全額借り換え）: システム全体を新しく作り直す
- 部分リプレース（部分的な借り換え）: 最も高金利な部分から優先的に対処
- 継続的改善（繰り上げ返済）: 既存システムを少しずつ改善
- 機能削除（債務整理）: 採算の合わない機能を削除
僕たちがこれまで取り組んできたJenkins CI/CDパイプラインの構築は、「継続的改善」のアプローチでした。確かに一定の効果はありましたが、根本的な問題は解決されていません。高金利の技術的負債は、依然として僕たちの開発速度を蝕み続けていたのです。
そこでチームが選択したのが、「部分リプレース」戦略でした。最も高金利な部分から段階的に、モダンな技術スタックに借り換えていく。そのための武器として僕たちが選んだのが、Blazorだったのです。
Blazor化：新しい戦場の構築
チームがBlazorを選んだ理由は、単純にモダンだからではありません。既存の.NET資産を活かしながら、技術的負債を大幅に削減できる、戦略的な選択だったのです。
Blazorがもたらすと期待される技術的負債の削減効果：
- 標準的な開発環境: プラットフォーム依存を排除し、「環境構築の困難」という高金利負債を解消
- コンポーネントベースのアーキテクチャ: 複雑に絡み合った依存関係を整理し、「実態に即していないデータ構造」を改善
- 自動テストの容易な組み込み: 品質チェック不足という高金利負債を低金利に転換
- 属人化の排除: 標準的な技術スタックにより、「特定の人しか理解できない」状況を解消
段階的移行への挑戦
現在、僕たちは段階的なBlazor化に取り組んでいます。まず影響範囲の少ない小さな機能から移行を開始し、同時に不要な機能の積極的な削除も進めています。月に数人しか使わない古い機能、複雑すぎて保守コストが見合わない機能。これらを思い切って削除することで、技術的負債の総量を削減しようとしているのです。
機能削除は、一見すると後ろ向きな取り組みに見えます。しかし、実際には「債務整理」という、経営上極めて重要な意思決定です[2]。採算の合わない機能を維持し続けることは、スタートアップの唯一の武器である「スピード」を奪うことに他なりません。
この取り組みは、まだ始まったばかりです。しかし、僕たちには確信があります。この新しい戦場が完成すれば、Devinは水を得た魚のようにその能力を発揮し、これまで頭を悩ませていた環境依存の問題は解消され、開発速度は飛躍的に向上するはずだと。
第6章：幻想を捨てた先にある真の価値
Devinとの奮闘を通じて、僕はAI駆動開発の本質を学びました。それは、決して「魔法」ではありません。AIは、人間の仕事を奪うものでも、楽をさせてくれるものでもなく、あくまで人間の能力を拡張するための「強力なツール」です。
- 人間: 複雑な問題の定義、アーキテクチャの設計、そして最終的な意思決定を行う。
- AI: 明確に定義されたタスクを、高速かつ正確に実行する。
この適切な役割分担ができて初めて、AI駆動開発は真の価値を発揮します。幻想を捨て、AIの得意なこと、苦手なことを理解し、人間が賢く使いこなす。その先にこそ、僕たちが目指すべき、生産性の高い未来があるのです。
結び：レガシーシステムとAIの現実的な付き合い方
もし、あなたが僕と同じように、レガシーシステムを前に、AIの導入をためらっているのなら、伝えたいことがあります。
まず、「幻想」を捨ててください。AIがすべてを解決してくれるわけではありません。しかし、絶望する必要もありません。
- 現状を分析し、現実的な活用法を探る: CI/CDパイプラインの構築など、今ある環境でできることから始める。
- AIとの適切な役割分担を見つける: AIの得意な領域に集中させ、人間はより創造的な仕事に取り組む。
- 戦場を変える勇気を持つ: 長期的な視点で、レガシーシステムからの脱却（モダナイゼーション）を計画する。
レガシーシステムとAIの共存は、決して平坦な道のりではありません。しかし、そこには、組織を、そして開発の未来を大きく変える、確かな可能性があります。この記事が、あなたの挑戦の第一歩を踏み出す、小さなきっかけとなれば幸いです。
参考文献
[1] すてぃお「スケールしたプロダクトにおける技術的負債の適切な管理方法」note, 2025年8月18日. https://note.com/suthio/n/n5f1398581ca4
[2] すてぃお「スタートアップにおいて『積極的に機能削除をする』ことの重要性」note, 2025年7月22日. https://note.com/suthio/n/n6e39ebcad611
Discussion