AIコーディングを活用したレガシーコード適応への道
はじめに
数週間前から業務でコーディングエージェント系の生成AIを使い始めました。これまではChatGPTなどのチャット系のAIを使用していましたが、本格的な開発支援ツールの導入により、レガシーシステムの移行に取り組んでいます。
プロジェクト概要
現在の技術環境
- Java 8
- jQuery
- Glassfish
- VB.net 2010
抱えている課題
現状のシステムは以下の課題を抱えています：
- VB.net側で型定義が存在せず、全てがObjectマッピングで処理されている
- APIのエンドポイントすら共通化されておらず、各機能で個別実装となっている
- レガシーな技術スタックによる保守性の低下
移行の目標と戦略
現段階の目標：
- VB.netの型なしObjectマッピングから、型安全なAPIへの移行
最終目標：
- VB.netタブレットアプリケーションをReact Webアプリケーションへ移行
段階的アプローチを選択した理由：
当初は直接的な移行を試みましたが、Object型の問題によりAPIなどの移行がスムーズに進まなかったため、段階を踏むアプローチに変更しました。
使用したAIツール
- Claude Code
-
GitHub Copilot Agent
- VB.netのサポートを考慮し、Cursorではなくエディタとの親和性を優先
AIコーディング支援ツール活用の知見
直面した課題
実際にAIツールを活用する中で、以下の課題に直面しました：
- AIが重要な情報を見落とし、予期しない情報の欠落が発生する
- 一度に大量のエラーを仕込んでしまい、その修正に時間を要する
- 全ての修正をAIに一任すると、システム全体の整合性が損なわれる
学んだ教訓と改善策
1. 修正範囲の細分化
人間から見て十分に細かい修正範囲でも、さらに細かく区切ることで精度が向上します。
2. 単一作業への集中
「APIを共通化し、型をバックエンドから取得する」など、複数の作業を同時に指示すると作業漏れが発生します。
3. 推奨される作業手順
- まず必要なAPIをバックエンドから作成
- 次に型定義を作成
この順序により、ミスが大幅に減少し、大量のエラーを仕込まれるリスクが軽減されます。
4. 人間による品質管理の重要性
段階的なアプローチと人間による品質管理が不可欠であることが判明しました。
導入効果と成果
AIツールの導入により、以下の成果を得ることができました：
- これまで困難だった大規模な画面単位でのAPIマッピングが、2日程度で実施可能になった
- データ型の作成が大幅に効率化された（ただし、一部手動での調整が必要）
- 型安全なAPIへの移行が段階的に進行している
具体的な作業例とプロンプト
実際に使用したプロンプトの例
初期の問題のあるプロンプト（非推奨）
型を利用した汎用APIが @{hoge}\API\ フォルダに作成されています。
これで置換できるものは全て置換してください。
APIがないものに関しては作成し、データ型もVBでないものは作成してください。
また、これらの型とAPIのJavaとVBの紐づけをプロジェクトファイルに記載してください。
このプロンプトの問題点：
- 複数の作業を同時指示（置換 + 新規作成 + ドキュメント更新）
- 前提条件の確認がない
- 成果物の品質確認手順がない
改善されたプロンプト（推奨）
# レガシーAPIの型安全な汎用APIへの移行作業
## 対象ファイルの限定
**作業対象ファイル**: {target_files}
**汎用APIフォルダ**: `@{project_root}\Common\API\`
**型定義フォルダ**: `@{project_root}\Common\Types\`
## 前提条件の確認
1. 指定された対象ファイル内のAPI呼び出しパターンを分析してください
2. `Common\API\` フォルダ内の汎用API一覧を確認し、既存の機能を把握してください
3. `Common\` フォルダ内の処理でAPIがラップされている可能性があるため、以下も確認してください：
- `Common\Services\` フォルダ内のサービス層実装
- `Common\Utils\` フォルダ内のユーティリティ関数
- 既存の共通処理が個別実装をラップしていないか
## 作業手順（段階的に実行）
### 段階1: 対象ファイル内のAPI使用状況分析
- 指定されたファイル: {target_files} 内のAPI呼び出しを全て抽出
- 各API呼び出しの機能と目的を分析
- 汎用APIで置換可能なものと、新規作成が必要なものを分類
- **重要**: Commonフォルダ内の既存処理で既にラップされていないか確認
### 段階2: 置換可能なAPIの段階的置換
- 分類した置換可能なAPIから、影響範囲の小さいものから順に置換
- 1つのAPI置換ごとにコンパイルエラーの確認とテスト実行
- 置換完了したものはリストアップして進捗を報告
### 段階3: 不足している汎用APIの作成
- 段階1で新規作成が必要と分類されたAPIについて、汎用API仕様を設計
- 既存の汎用APIの命名規則とアーキテクチャに従って実装
- 作成後は必ずテストコードも併せて作成
- CommonフォルダのServices層から呼び出せるように設計
### 段階4: VB.net型定義の作成と更新
- Java側に対応するVB.net型定義が不足している場合のみ作成
- 型名は Java側との一貫性を保つ（PascalCase等の命名規則に注意）
- nullable型や配列型、コレクション型の扱いに注意
- 作成した型は `Common\Types\` フォルダに配置
### 段階5: ドキュメント更新と依存関係の整理
- プロジェクトファイル `API_Migration_Log.md` に以下を記載：
- 対象ファイル: {target_files}
- 新規作成したAPI一覧
- JavaクラスとVB.net型の対応表
- 移行完了した個別実装の一覧
- Common層の依存関係図
## 成果物の確認
- 指定されたファイル {target_files} のコンパイルエラーがないこと
- 影響を受ける関連ファイルのコンパイルエラーがないこと
- 既存のテストが通ること
- 新規作成したAPIのテストが通ること
- Common層の依存関係が整理されていること
各段階完了後に報告してください。エラーが発生した場合は次の段階に進まず、まず現在の段階を完了させてください。
カスタムコマンド用のテンプレート:
Claude Codeで以下のようにカスタムコマンドとして保存することを推奨します：
プロンプト改善のポイント
-
対象ファイルの明確化:
{target_files}パラメータで作業範囲を限定 - カスタムコマンド対応: Claude Codeでの再利用を前提とした設計
- Common層の考慮: 既存のラッパー処理や共通機能の存在を確認
- 段階的アプローチ: 5つの明確なステップに分割（分析→置換→作成→型定義→ドキュメント）
- 品質管理: 各段階でのテスト・確認を組み込み
- 依存関係の整理: Common層のアーキテクチャを意識した設計
- 進捗の可視化: 各段階での報告を義務化し、エラー時の停止ルールを明記
失敗事例と学習した対処法
失敗例1: 複数の作業を同時に指示
状況:
APIの共通化、型定義の作成、VBとJavaのマッピングを一度に指示した。
結果:
- 作業漏れが発生し、システム全体の整合性が取れなくなった
- 大量のエラーが一度に発生し、原因の特定が困難だった
改善策:
単一作業に絶対に分割する。まずAPI作成、次に型定義の順で段階的に進める。
失敗例2: コード品質を無視したAI活用
状況:
変数名が不適切で、メソッド名が処理内容と一致しないコードにAIで型安全性を適用しようとした。
結果:
AIがデータの意味を正しく理解できず、間違ったマッピングや型変換が多発した。
改善策:
AIを使用する前に、必ずコード品質の確認と基本的なリファクタリングを実施する。
失敗例3: キャッシュ問題の看過
状況:
Claude Codeで修正したファイルを手作業で編集後、再度Claude Codeにファイルを指定して作業させた。
結果:
手作業で修正した部分が元の状態に戻されてしまった。
改善策:
手作業編集後にAIツールを再利用する際は、/clearコマンドでキャッシュをクリアしてから作業する。
移行プロセスの詳細な手順
段階1: コード品質の確認と前処理
移行作業を始める前に、元のコードの品質を確認することが重要です。
品質チェックポイント:
- 変数名が意味を成しているか
- メソッド名が処理内容を適切に表現しているか
- データの流れが理解しやすいか
対処法:
元のコード品質が悪い場合、AIの生成結果が不安定になります。特に変数名が不適切だと、AIが正しいデータを取得できないことが频繁に発生します。
段階2: APIの作成と置換
- 既存の汎用APIで置換可能な箷所を特定
- 不足しているAPIを新規作成
- 段階的に置換してテストを実施
段階3: 型定義の作成
- VB.net側の型定義を作成
- Java側とのマッピングを確立
- プロジェクトファイルに紐づけをドキュメント化
判断基準
- 次の段階へ進むタイミング: 現在の段階のエラーがゼロになった時点
- 品質確認: コードレビューとテストで確認
- ロールバック基準: エラーが多発した場合は前の段階に戻る
時間とコストの改善効果
AI導入前後の比較
導入前（手作業のみ）:
- 1画面のAPIマッピング: 3-5日
- データ型の作成: 1-2日/型
- エラー修正: 予測困難な時間
導入後（AI活用）:
- 1画面のAPIマッピング: 0.5日
- データ型の作成: ほぼ自動化（数時間）
- エラー修正: 約50%短縮（段階的アプローチにより）
ROIの概算
- 時間短縮率: 約50%の時間短縮を実現（APIマッピングでは約70%短縮）
- 品質向上: 型安全性によるバグ減少
- 学習コスト: 初期は試行錯誤で時間を要したが、3日程度で効果的な活用方法を習得
同様の課題を抱える開発者へのアドバイス
適切な活用範囲の見極め
細かい部分まで生成AIに任せると、かえって時間を浪費する場合があります。以下のアプローチを推奨します：
- 8割程度の完成度で生成AIによる作業を停止
- 残りの細かい調整は手作業で実施
- その後、CursorやGitHub Copilotなどの支援系AIツールを活用
効率的な使い分け
- 大規模な作業: 生成AIをフル活用
- 細かい調整: 手作業の方が効率的
今後の展望
- カスタムプロンプトをコマンド化して、作業の標準化を図る
- Claude Codeの機能をより活用した開発プロセスの確立
- React移行に向けた次段階の準備
生成AI時代のソフトウェア開発に対する所感
生成AI技術の進歩、特にKiroのようなツールの登場により、プログラミングの世界が大きく変わりつつあります。プロンプトエンジニアリングのような技術も次々と更新される現状を目の当たりにし、技術の進歩の速さを実感しています。
生成AIがもたらす変革
技術の民主化
生成AIは技術の垣根を超える強力なツールとして機能し、プログラミング開始以来最も大きな衝撃をもたらしています。
開発スタイルの変化
生成AIを活用したコーディングスタイルが定着していく中で、この技術に慣れることが重要だと考えています。特に以下の点で価値を発揮します：
- 単純作業に近いリファクタリングの自動化
- 大規模なコード変更の効率化
- 型安全性の向上支援
実務での注意点
適切な使用範囲の認識
- 全てを生成AIに任せることは現実的ではない
- 手作業での編集後にAIツールを再利用する際は、
/clearコマンドでキャッシュをクリアすることが有効
効果的な活用方法
- 具体例があれば高精度な修正が可能
- 例がない場合は精度が低下する傾向
- 大きな変更は生成AI、細かい調整は手作業という使い分けが効率的
おわりに
本記事では、レガシーシステムの移行におけるAIコーディング支援ツールの実践的な活用方法を、実体験に基づいて詳細に解説しました。
記事の要点まとめ：
- 段階的アプローチの重要性（一度に複数作業を行わない）
- プロンプト設計の改善（対象ファイル限定、カスタムコマンド化）
- 失敗事例からの学習（品質管理、キャッシュクリア等）
- チーム開発での標準化とリスク管理
AIツールは確実に開発効率を向上させる強力な技術ですが、適切な使い方を理解することが成功の鍵です。特にレガシーシステムの移行のような複雑な作業では、人間による品質管理とAIの生産性を組み合わせたアプローチが効果的です。
今後もAI技術の進歩により開発スタイルは変化し続けるでしょうが、エンジニアの役割は決してなくならず、むしろより創造的で価値の高い作業にシフトしていくと考えています。
AI時代のエンジニアの役割変化
新しい開発スタイルの登場
エンジニアの必要性は依然として高いですが、求められるスキルが大きく変化しています。以下のようなサイクルが一般的になると予想されます：
- AIが大範囲のコードを生成
- エンジニアが細かい修正や品質向上を実施
- 方法論が確立されたら、再びAIが次の段階を担当
AI活用のメリット
- 生産性の大幅向上: 一人当たりの開発効率が大幅に向上
- 単純作業の短縮: 面倒な部分を大幅にショートカット
- 開発体験の向上: 近未来感のある楽しい開発体験
AI生成コードと向き合う際の課題
「知らない会社のシステム保守」のような戸惑い
初期開発でAIが生成したコードを手直しする際は、いきなり別のプロダクトの開発を任されるような戸惑いを感じることがあります。
しかし、ノーコードツールとは異なり、努力すればコードの内容を理解できる点が大きなメリットです。
Discussion