0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

人が書いたコードをAIが読み解く時代:Q Developerで始める再構築プロジェクト

Last updated at Posted at 2025-10-16

C&CA(Cloud Custom Application)のPlatform & Enabling Sectionのリードをしています高安 厚思(たかやす あつし)と申します。よろしくお願いいたします。
今回、いくつかのプロジェクトでQ Developerを用いているのでそれらの内容を取りまとめてこの記事を書きました。

はじめに

近年、AIを活用した開発支援ツールが急速に普及し、開発現場での生産性向上に大きく貢献しています。その中でも、Amazon Q Developer(以下、Q Developer)は、コード生成から解析、テスト作成まで幅広い開発タスクをサポートする強力なツールとして注目を集めています。

本記事では、Q Developerを実際のプロジェクトで試用した経験をもとに、具体的な活用方法や得られた知見、そして実際の開発現場での効果について詳しくご紹介します。特に、レガシーシステムのモダン化という複雑なプロジェクトにおいて、Q Developerがどのような価値を提供したかを中心に説明していきます。

記載する内容は、守秘義務の関係から抽象化したりフェイクを入れたりしてます。また、複数のプロジェクトでの利用事例を統合したものです。そのため、項目間に若干の整合性のズレがある可能性がありますが、実際の開発現場での生の体験として参考にしていただければと思います。


ユースケース:レガシーシステムのモダン化

ある業務において、10年以上運用されている老朽化したソフトウェアをモダンな技術スタックへ置き換えるプロジェクトがありました。対象のシステムは私たちが開発したものではなく、ドキュメントも断片的にしか残っていない状況でした。

このような状況では、従来であれば膨大な時間をかけてコードを読み解き、仕様を推測しながら進める必要がありましたが、Q Developerの活用により、この解析フェーズを大幅に効率化することができました。

対象システムの規模は約数十万行のJavaコードで構成されており、複数のバッチ処理とWebアプリケーションが混在する複雑な構成でした。まずは既存プログラムの解析から始める必要がありました。

そのため、以下の図のような手順で進めることにしました。

Javaプログラムの解析

対象はJavaで構築されたバッチ処理中心のシステムでした。Q Developerを活用し、以下のような観点から体系的に解析を進めました:

入力データの解析

  • CSVファイル、XMLファイル、データベースからの入力パターンを特定
  • 各入力データの形式、必須項目、バリデーションルールを抽出
  • データの依存関係や処理順序を明確化

ビジネスロジックの抽出

  • 複雑な計算処理や条件分岐のロジックを自然言語で説明
  • 業務ルールの変更履歴をコメントから推測
  • 例外処理やエラーハンドリングのパターンを整理

出力・更新処理の可視化

  • データベースの更新パターンとトランザクション境界を特定
  • ファイル出力の形式と出力先を整理
  • 他システムとの連携ポイントを明確化

特にバッチ処理においては、どのようなデータを受け取り、どのように変換・更新されるかをフローチャート形式で可視化することができ、後続の設計作業を容易にしました。

データベースの解析

レガシーシステムでは、データベースアクセスが複雑に絡み合っており、テーブル間の関係性を把握することが重要でした。Q Developerを活用して以下の解析を実施しました:

テーブル構造の理解

  • 数百のテーブルとそれらの関係性をER図として可視化
  • 外部キー制約やインデックスなどの設計情報を抽出

SQLクエリパターンの分析

  • 複雑なJOINクエリやサブクエリの処理内容を解析
  • パフォーマンスボトルネックとなりそうなクエリを特定
  • CRUD表の自動生成

データアクセス層の設計パターン

  • DAOパターンの実装状況と一貫性を確認

これにより、データの流れや依存関係を効率的に把握することができ、新システムでのデータモデル設計に活かすことができました。


プログラムの生成準備

解析フェーズで得られた知見をもとに、モダンな技術スタックを用いた新システムの構築に着手しました。ここでは、単純な移植ではなく、現代的な設計原則に基づいた再設計を行いながら、Q Developerを活用してコード生成の効率化を図りました。

新システムでは、各機能を独立したモジュール構成にして、モジューラモノリスの形で作り直し、保守性と拡張性の向上を目指しました。

アーキテクチャ定義とモジュールのひな型作成

プロジェクトでは、以下の技術スタックを採用したモダンなアーキテクチャを構築しました

アーキテクチャ

フロントエンド

  • Remix: サーバーサイドレンダリングとクライアントサイドナビゲーションの最適化
  • TypeScript: 型安全性の確保と開発効率の向上
  • Tailwind CSS: 一貫したデザインシステムの構築

バックエンド

  • Spring Boot 3.x: RESTful APIを提供するための基盤フレームワーク
  • Doma2: SQLを利用しやすいORマッピング
  • Spring Security: 認証・認可の実装(JWTを利用した認証)

ビルド

  • Gradle: ビルドとデプロイメントの自動化

インフラストラクチャ

  • Docker: コンテナ化による環境の統一
  • AWS EKS: スケーラブルなコンテナオーケストレーション

アプリケーションのひな型

アーキテクトがこれらの技術に準じたモジュールのひな型を作成しました。

アーキテクチャ定義ファイルの生成

QDeveloperでひな型のアプリケーションを解析して以下の要素を含むアーキテクチャ定義ファイルを作成しました。

  • レイヤードアーキテクチャの構成方針
  • 依存性注入のパターン(インタフェースと実装の分離)
  • エラーハンドリングの統一方針
  • ログ出力の標準化
  • セキュリティ担保のルール
  • クラスやWebコンポーネントの分離方針

これにより、Q Developerが一貫した品質でコード生成できる準備をしました。

プログラムの生成

Q Developerを活用したコード生成では、以下のアプローチを採用しました:

段階的な生成アプローチ

  1. バックエンドとフロントエンドの境界に対するインタフェース仕様: OpenAPI形式によりフロントとバックの間のインタフェース仕様
  2. バックエンドの生成: REST APIエンドポイント
  3. フロントエンドの生成: Remixを使用したページコンポーネント

生成されたコードの品質

  • おおよそコンパイルは通り、動作可能な状態
  • チャットインタフェースにおける試行錯誤によりおおよそ動作できるようになった
  • 人(チームリーダ)がコードレビューを実施することで最終チェック

効率化の効果

  • 従来の手作業と比較してフレームワークをどうやって利用すればいいのか?(APIの選定とか)という調査工数を削減できた
  • ベースのコードやアノテーションといった決まったコードを生成してから実施することで工数が削減できた

初期構築の効率化に大きく貢献し、開発チーム全体の生産性向上を実現しました。

テストコードの生成と実施

機能的な品質を担保するために単体テストとE2Eを組み合わせて実現しました。
APIのテストはQDeveloperでは作りませんでした。

単体テストの自動生成

  • JUnit 5とMockitoを使用したテストコードを自動生成
  • テストパターンの洗い出しとその実装もの出力
  • テストデータの準備とクリーンアップ処理も自動生成

E2Eテストの自動化

  • PlaywrightのMCPサーバを活用し、開発者の自然言語によるE2Eテストを実施

これにより、品質保証プロセスの大幅な効率化と、リグレッションテストの自動化を実現しました。


画面設計と設計書の生成

UXの向上と保守性の確保を目的として、以下のような画面設計の方針・進め方としました

設計方針

Atomicデザインによる画面設計
いわゆるAtmoicデザインを意識し、画面設計をおこなうためにデザインシステムを準備し、そのデザインシステムを利用した実装となるようにプロンプトを工夫しました。

進め方

Figmaを活用した設計プロセス

  • デザインシステムの構築と共有
  • プロトタイプによるユーザビリティ検証

アジャイル開発への対応

  • 詳細な画面設計書は作成せず、メモやFigmaからプログラムを生成して実装
  • 迅速な仕様変更への対応を重視
  • ユーザーフィードバックの早期取り込み

運用保守の観点から、完成したシステムに対してリバースエンジニアリングによって設計書を生成するアプローチを採用しました。

設計書の作成

リバースエンジニアリングによる設計書生成では、以下の成果物を作成しました

処理設計書の自動生成

  • 入力パラメータと出力結果の詳細仕様
  • 例外処理とエラーハンドリングの説明
  • CRUD図の生成

画面設計書の生成

  • 各画面の項目定義と入力制約
  • バリデーションルールとエラーメッセージ

API仕様書の作成

  • OpenAPI 3.0形式での自動生成
  • リクエスト・レスポンスの詳細定義の生成

Q Developerの出力をベースに、必要な情報を整理・補完することで、ドキュメント化工数削減を実現できました。


Q Developerを使ってみての感想

便利だった点

開発効率の大幅向上

  • CLIベースでの利用により、解析結果や設計情報をローカルファイルとして出力できるのが非常に便利でした
  • バッチ処理による大量ファイルの一括解析が可能
  • 既存のビルドツール(Gradle、Maven)との統合が容易
  • CRUD図などメンテナンスの大変な文書も解析して、生成できた

コード生成も便利ですが、解析に関する性能が高いと感じました。ここは人間が読みながら、理解し、メモを取る、まとめるという段階を経て、工数のかかるところなので便利に思いました。

可視化機能の充実

  • draw.ioやMermaid形式での出力により、技術者以外とのコミュニケーションが円滑化
  • アーキテクチャ図、シーケンス図、ER図の自動生成
  • PlantUMLとの連携による詳細な設計図の作成
  • AWS Diagram MCP Serverによる構成図の生成(試行中)

といった図示における機能もとても便利でした。

品質の一貫性

  • コーディング規約の適用しやすい
  • 設計パターンの統一がしやすい
  • セキュリティベストプラクティスの組み込みしやすい

人が対応すると属人性が高くなりがちな部分を安定化できました。

学習コストの低減

  • 自然言語での指示が可能
  • フレームワークの使い方の調査工数の削減
  • 段階的な機能追加による習熟度向上
  • 豊富なサンプルコードとテンプレート

成果物の生成には効果的

上記のような便利さを感じていました。一方で完全な成果物ではないことをデメリットに感じるメンバーはいました。特に中身を確認できない若手が利用することに関する懸念でした。ただ、一つ言えることは完全な成果物ではないものの、ゼロから人が作るよりも圧倒的に早く初期構築が可能で、開発チーム全体の生産性向上に大きく貢献できたと思います。

改善してほしい点

スペック駆動開発に近い開発をしたいと考えているため、以下のような改善があったらうれしいと考えています。ただ、まだKiroを触れていないのでこのあたりができているのかもしれません。

コマンドの拡張性

エージェント指向での利用を前提とすると、コマンドを柔軟に追加できる仕組みがあると理想的です。個人開発ではClaude Codeの「Super Claude」が非常に便利で、同様のエコシステムがQ Developerにもあると嬉しいです。

プロンプト管理と分析

プロンプトエンジニアリングの重要性が高まる中、以下の機能強化を期待しています:

プロンプト品質管理

  • プロンプトは成果物の品質に直結するため、管理・分析機能がほしい

現在はS3にログを保存し、手動で分析できると思いますが、機能としてあると便利だと思います

  • プロンプトの改善提案機能
    ログを用いて、チャットによる試行錯誤してプロンプトからの出力結果を修正している箇所を分析して、プロンプトを統合するレコメンデーションしてくれる機能があるといいと思ってます。

バージョン管理とコラボレーション

  • プロンプトの統合・比較・バージョン管理機能
  • チーム内でのプロンプト共有とナレッジベース化
    チームで利用している場合、チームを管理し利用しているプロンプトを共有できる機能があるといいと思いました。

業務要件の参照性

業務ドメイン知識の統合は、システム開発の精度向上に不可欠です

ドキュメント統合の課題
現在はGenUによるRAG(Retrieval-Augmented Generation)を活用し、業務知識の確認を行っていますが業務要件やマニュアルなどをQ Developerから直接参照できるようになると、設計の精度が向上します。RAGをツールとして用いるころができるので同等のことはできますが、直接参照、指示ができると便利と思いました。

より統合された仕組みがあることで、業務要件の理解度向上と設計品質の向上が期待できます。


今後の展望

私たちは、今後以下のようなことに取り組んでいきたいと考えています。

仕様駆動開発の実現

スペック駆動開発の観点からKiroの活用も検討しており、以下の取り組みを予定しています:

  • 標準プロセス・標準手順の確立: 要件定義からコード生成までの中間成果物を定義、それぞれを出力するシステムプロンプトを準備して実施する
  • テスト仕様の自動生成: 仕様書からテストケースの自動作成
  • ドキュメント駆動開発: 設計書とコードの双方向同期
  • 組織的な活用拡大: プロジェクトだけではなく、組織全体でガバナンスを利かせた利用を推進
  • 開発標準の策定: Q Developer活用のベストプラクティス集約
  • 教育プログラムの構築: チーム全体のスキル底上げ
  • 品質管理プロセス: AI生成コードの品質保証体制
  • 自動リファクタリング: 技術的負債の検知と自動修復(プルリクエストまでを自動実行)
  • 継続的学習: プロジェクト知見の蓄積と活用
  • プロンプト管理と共有: 標準的なプロンプトを用いて、人での修正を減らすことのできる進め方を実現

これらの取り組みを通じて、AI駆動開発の新たな可能性を探求し、開発現場の更なる進化を目指していきます。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?