re:Invent 2024: AWSがGenerative AIで Java アプリケーション更新を加速
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Accelerate application maintenance and upgrades with generative AI (DOP209)
この動画では、AWSがGenerative AIを活用してJavaアプリケーションのメンテナンスとアップグレードを加速させる取り組みについて解説しています。Amazon Q Code Transformationを使うことで、Java 8からJava 17へのアップグレードやSpring Bootなどのフレームワーク更新を効率化できます。Canada Lifeの事例では、Amazon Qの活用により40%の生産性向上を達成し、1,000万ドルのプロジェクトで25万ドルのコスト削減を実現しました。また、マルチエージェントデバッガーの導入により85%のデバッグ性能向上を達成し、Command Line Interfaceのプレビュー提供により大規模な自動化も可能になっています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
re:Invent 2024: Generative AIによるアプリケーションメンテナンスの加速
みなさん、こんにちは。re:Invent 2024へようこそ。会場の皆様にお会いできて、また最初の講演者の一人として登壇できることを大変嬉しく思います。今日は、AWSがGenerative AIを活用してアプリケーションのメンテナンスとアップグレードをどのように加速させているかについてお話しさせていただきます。始めに簡単にお伺いしたいのですが、現在Javaを使用したアプリケーションのメンテナンス、アップグレード、もしくはモダナイゼーションプロジェクトに携わっている方は手を挙げていただけますか？かなりの方がいらっしゃいますね。素晴らしいです。
私はAdnan Bilwaniと申します。AWSのNextGen Developer ExperienceチームのPrincipal Specialistを務めております。 本日は同僚のElio Damaggioも同席しております。彼はAmazon QのPrincipal Product Ownerです。 また、Canada LifeのAVP EngineeringのAmber Birdもお迎えしています。彼女には、実際の現場でこのユースケースにどのように取り組んできたかについて共有していただく予定です。
では、本日のアジェンダを簡単に確認させていただきます。まず、レガシーアプリケーションのアップグレードとモダナイゼーションについてお話しします。はじめに、本日の議論の基礎となる共通認識を持つため、アプリケーションとその様々な層について説明させていただきます。その後、Generative AIとは何か、そしてAWSがどのようにそれを活用しようとしているのかについて説明します。現在の作業方法について話し合い、皆様がどのようにツールを活用されているのかもお聞きしたいと思います。次に、AWSがGenerative AIを活用してこれらのプロセスをどのように加速させようとしているのかについてお話しします。その後、Amberから、Canada Lifeがこのユースケースをどのように捉え、チームがプロセスを加速させようとしているかについてお話しいただきます。最後に、Elioからre:Inventでの新機能と今後の開発についてお話しさせていただきます。
レガシーアプリケーションのアップグレード：課題と解決策
レガシーアプリケーションのアップグレードは、企業が競争力と効率性を維持するために重要な検討事項となっています。 パフォーマンスと効率性の向上、セキュリティリスクの解決、ベンダーサポートの最新化、スケーラビリティの追加など、様々な理由で検討されています。私が見落としている理由は他にありますでしょうか？まだ朝早いですかね？
より詳しい方法についてお話しする前に、アプリケーションの構造と、今日お話しするアップグレードについて共通の理解を持ちましょう。これには様々なアプローチがありますが、シンプルに考えていきましょう。アプリケーションを4つの層に分けてみました。 まず、コンピューティングリソース、ネットワークインフラ、そして周辺機器で構成されるインフラストラクチャ層から始めます。 その上にWindows、Linuxなどのオペレーティングシステム層があります。そして、プログラミング言語、フレームワーク、パッケージの選択へと進みます。
これが最上位のアプリケーション層の基盤となり、そこにはアプリケーションコードやデータ、データスキーマが存在します。エンドユーザーの視点からすると、ここで魔法が起きているわけです。しかし、アプリケーションの観点からすると、 これらの層はすべて、いずれかの時点でメンテナンスやアップグレードが必要になります。ただし、それぞれの扱い方は異なります。メンテナンス成熟度モデルや組織の状況によって、その対応方法も様々です。
まず、インフラストラクチャ層から見ていきましょう。アップグレードは通常3〜5年ごとに行われます。これにはサーバー、ハードウェア、ネットワーク設定が含まれます。負荷状況に応じて、この期間を短縮したり延長したりすることもあります。オペレーティングシステムについては、 定期的なセキュリティパッチやマイナーバージョンのアップデートがあります。システムはより成熟しており、自動化も進んでいるため、それらの適用はスムーズです。もちろん、約2年ごとにメジャーアップデートもありますが、それは課題となることもあります。ただし、通常の定期アップデートはそれほど難しくありません。
次に、フレームワークのアップグレードとプログラミング言語の要件に焦点を当てましょう。Javaアプリケーションを使用している場合、Spring Boot、Hibernate、Strutsなど、お好みのフレームワークがあるでしょう。パフォーマンスアップデートやセキュリティリスクへのパッチが適用されますが、組織によって対応は様々です。セキュリティアップデートは頻繁に適用されますが、パフォーマンスの改善や機能要求については、ビジネス上の判断で遅延することもあります。メジャーアップデートも通常1年ごとにあり、これも課題となることがあります。
アップデートを適用する際の最大の課題の1つは、特に長期間待った場合、非推奨APIによる互換性の問題が発生し、 最上位層での変更を余儀なくされることです。アプリケーション層に移ると、バグ修正やセキュリティアップデートはより頻繁に適用されます。ただし、リファクタリングやパフォーマンスの改善は、ビジネス要件によって優先順位が下がることがあります。通常、機能追加やビジネス革新を推進する部分を優先的に作業し、その他の改善には時間がかかることもあります。Generative AIの活用について話す際には、これら2つの層で行う、見つけにくい、あるいはメンテナンスが困難なアップデートについて議論します。
さて、 これらの変更をまだ進めているとしましょう。変更を先送りにし始めると、それはメンテナンスからモダナイゼーションプロジェクトへと変化する傾向があります。これは非常に面倒で時間のかかる重要な懸念事項となり、開発者が避けたがる差別化されていない重労働に戻ってしまいます。現在、人々はどのようにこれを行っているのでしょうか？ 簡単に言えば、自動化と手作業を組み合わせて対応しています。皆さんの中で、現場での割合をご存知の方はいますか？80-20で自動化が多いという人もいれば、20-80という人もいます。これは本当にメンテナンスの進捗状況や成熟度モデルの段階によって異なります。
主要なフレームワークをアップデートするために適用できるツールが用意されています。Spring Frameworkを更新してある程度まで進めてくれるレシピがありますが、それでもそれらのツールの学習と保守が必要です。熱心な開発者の中には、これをさらに進めるためにカスタムスクリプトを作成している人もいます。手動での変更が必要となるのは、主に非推奨コード、ファーストパーティパッケージ、ユニットテストの追加、そしてドキュメントの部分です。典型的なJavaのワークフローを見てみましょう。Java 8からJava 17に移行する場合、そのJava 8アプリケーションを取り、スクリプトを使用してそれらの変更の一部を適用します。フレームワークと依存関係をアップグレードし、既知の手動変更を行い、コンパイルしてテストします。おそらくエラーや問題が発生し、Java 17との互換性が確保され、UATと本番環境に向けて全てが良好になるまで、修正とテストのサイクルを繰り返すことになります。でも、もしこの部分も自動化できたらどうでしょうか？
Amazon Q Code Transformationの機能と実装例
AIを活用してこれらの更新を分析し、変更を加え、スクリプトの可能性を超えて必要な作業を確認し、コンパイルしてテストし、さらにユニットテストを実行して状況を確認し、ユニットテストを追加することができたらどうでしょうか？これはビジョンの話なので、そういった可能性を探って、どこに行き着くか見てみましょう。そして、それこそが今日のAmazon Q Code Transformationが目指しているところなのです。
この1年間、私たちはAmazon Q Developer Agentの開発に取り組んできました。年初にプレビューとしてリリースし、それ以来開発を続けています。 Q Code TransformationはすべてのMavenリポジトリの知識を適用し、ビルド、実行、テストを行う内部ツールにアクセスし、基本的にそのLLMの知識を活用して問題を解決し、自動的にリンスアンドリピートのサイクルを構築します。今日は本当にワクワクしていて、Elliotがこのリンスアンドリピートのサイクルをどのように改善してきたかについて、もう少し共有してくれると思います。
さて、ここで面白い部分です - 会場の皆さんに聞いてみましょう：これは完全なアプリを出力する魔法のボタンだと思いますか？私は「いいえ」と言います。ええ、何人かの方から「いいえ」という声が聞こえましたね。素晴らしい。全体的な計画は、このプロセスを加速させることです。ステップ0から始めるのではなく、うまくいけば40%か50%のステップから始められます。スクリプトなどのツールのメンテナンスを行うことなく、自動化された方法で残りの部分を完了できるように、その加速を提供しているのです。
では、話はこれくらいにして、今日のIDEでこれがどのように機能するのか、簡単に見てみましょう。そしてAmberにバトンタッチします。 はい、これがサンプルプロジェクトです。現在、Q Code Transformationはプロセスを進める中でまだ変更が必要なため、IDE体験として提供されています。Javaプロジェクトを開くだけで、サイドにQ Chatが利用可能になります。スラッシュtransformと入力し、そのツールを選択してEnterを押すと、プロセスが開始されます。
それでは詳しく説明していきましょう。ビルドプロセスが開始され、ビルドが進んでいくのが分かります。時間の節約のため、少し早送りしました。完了すると、プロジェクトをスキャンし、すべての依存関係をパッケージ化して、コンパイルを開始するためにサービスにアップロードします。まず、サンドボックス内で正常に動作することを確認するため、Java 8でコンパイルします。その後、変更の適用を開始します。 最初に、どのような変更を行う可能性があるかを示す変換計画を提供し、 その後、それらの変更の適用を開始します。
興味深い点は、最初に変換計画を提示しますが、Generative AIの観点から実際の処理を開始すると、さらに多くの変更が行われる可能性があることです。依存関係を更新し、先に進み、Java 17のビルドを開始します。このサイクルを繰り返しながら、正常にコンパイルできるようさらなる変更を加えていくのが分かります。完了すると、変換の概要が表示され、クリックすることでより詳細な情報を確認できます。 そして、すべての変更が表示され、このプロジェクトでJava 17への変換が部分的に成功したことが示されます。魔法のボタンはありません。
509証明書に関する例外など、更新できなかった部分についてログを取るように指示されますが、 依存関係や追加された項目、 修正されたすべてのファイルに関する変更内容が提供されます。これらのファイルはすべて表示可能です。View Diffをクリックすると、すべての詳細の差分が表示されます。開発者として、ファイルごとに確認し、 Log4jの修正内容や、JavaxからJakartaへの変更、その他のコード変更を確認することができます。 これらのファイルのいくつかを確認して、詳細を見てみましょう。この機能がどのように動作するかをお見せしているところです。Math.javaを開いて、 その変更も進めていきます。ファイルを見てみましょう。Spring Bootフレームワークが 3.3.6にアップデートされ、Javaバージョンも更新され、POM XMLの他のライブラリも更新されています。
ただし、変換は完全には完了していないので、ビルド出力を確認してみましょう。 コンパイラエラーが表示されています。私のプロジェクトは単純ですが、皆さんのプロジェクトはより大規模で、おそらくより多くのエラーが発生するでしょう。しかし、ここで止まる必要はありません。そのエラーをコピーできます - 昨晩実際に試してみました。OKをクリックして、 これらの問題の1つを修正する必要があります。すべてのファイルを閉じて、Security Javaファイルを開きます。最初はUtilにあると思っていましたが、実際にはServiceにありました。そのファイルを開いて、 サイドのQ Chatで@workspaceコマンドを使用します。これによりプロジェクト全体のコンテキストをQ Developer Chatに提供できます。Security Search Javaのコンパイルエラーを修正するように依頼します。見つかったことを確認するため、そのエラーからコピーしたものを貼り付けてEnterを押します。驚くべきことに、 問題を解決するために必要なコードや修正方法を提供してくれました。手動での変更は必要ですが、Qを活用することで そのプロセスを加速し、変更を進めることができます。
Canada LifeにおけるAmazon Qの活用事例
ありがとう、Anand。皆さん、おはようございます。まず、私の勤務先について説明させていただきます。Canada Lifeは175年以上にわたり、カナダ、イギリス、マン島、ドイツ、そしてIrish Lifeを通じてアイルランドで、保険、資産管理、ヘルスケア給付商品 およびサービスを提供してきました。Canada Lifeでは、カナダ人の身体的、経済的、精神的な健康の向上に焦点を当てています。保険金請求の処理、退職金や投資資産の改善・成長・保護、職場のメンタルヘルスの提供やより強固なコミュニティの構築など、Canada Lifeはすべての活動において顧客を第一に考えることを約束しています。私たちのカナダにおけるテクノロジー戦略は、デジタルワークプレイスにおける優れた顧客アドバイザーと従業員体験をサポートすることです。本日は、AWSとAmazon Qがこの戦略をサポートする方法についてお話ししたいと思います。
2023年半ばに話を戻しましょう。私たちは100万人以上の新規顧客をデジタルエクスペリエンスに一度にオンボーディングしたのですが、期待通りにはいきませんでした。Legacy Platformで安定性の問題が発生したのです。
このスライドに示されているように、APIは完全に別個のホスティングレイヤープラットフォームでホストされており、トラブルシューティングは悪夢のようでした。これは私にとって、危機を無駄にせず、上級管理職に対してプラットフォームを戦略的なプラットフォームに改善するためのアプリケーションモダナイゼーションの資金を承認してもらう絶好の機会でした。そして2024年に500万ドルの予算を獲得することができました。最初に行うのは、1つのAPI Gatewayに統一することです。次にLegacy Platformをすべて廃止してAWS Cloudの新しいプラットフォームに移行し、データベースもクラウドに移行します。最後にメッセージングとイベンティングのプラットフォームを1つに統一します。
明確な具体的なメリットは年間100万ドルの削減でしたが、それ以外にも多くの間接的なメリットがありました。明らかに障害やシステム停止のリスクを減らし、運用コストを削減できます。これだけ多くのプラットフォームの中で、どのAPIがどこでなぜ失敗しているのか、どのプラットフォームで問題が起きているのかをトラブルシューティングすることがいかに困難だったか想像できるでしょう。そして最後に、アーキテクチャーを簡素化し、顧客の可用性、レジリエンス、パフォーマンス - つまり顧客体験を向上させることができます。
私たちのアプローチは、これらのAPIをリフト＆シフトすることでした。数百のAPIがありましたが、まだ再設計はせずにクラウドへリフト＆シフトする計画でした。このイニシアチブを開始した時、当然セキュリティチームに相談したところ、「それはダメだ」と言われました。APIをクラウドに移行するなら、リフト＆シフトだけでなく、セキュリティ対策も行い、既存の脆弱性をすべて取り除く必要があると。これらのAPIの中には10年近く手付かずのものもあったので、やることは山積みでした。これは大きな問題となりました。なぜなら、API1つあたりの見積もりが50%以上増加し、新たに1,000万ドルのコストが発生し、完了までに2025年末までかかることになったからです。
明らかに、これを緩和して作業を加速する方法を考える必要がありました。Java 8からJava 17へのアップグレード、関連するフレームワーク、ライブラリ、依存関係のアップグレードなど、すべて手作業で繰り返し作業が必要でした。開発者が大量の作業に追われることになります。どうすればいいでしょうか？そこで戦略的ベンダーに相談し、AWSとAmazon Qが登場しました。 まずパイロットプロジェクトを実施して、どのように機能するか確認することにしました。Amazon Qはまだプレビュー段階だったので、次のような取引をしました：AWSが私のパイロットプロジェクトを支援してくれる代わりに、私がそのプロダクトに対するフィードバックを提供することになりました。
私たちのパイロットの目的は、Amazon Qがアップグレードと脆弱性の修復にかかる時間をどれだけ短縮できるかを判断することでした。先ほどのスライドで示した3つの異なるプラットフォーム上で、3つの異なるAPIをアップグレードする計画を立てました。具体的には、Nucleusプラットフォーム、Docker Swarm、そしてRancher Kubernetesです。まず1人の開発者が手作業でAPIのアップグレードと全ての作業を行い、その後、同じ開発者がコードをTransform処理にかけ、必要な手作業を行って、それぞれの所要時間を記録することにしました。このパイロットの目標は、手作業と比較して25～45%の生産性向上を達成することでした。
これが結果です。Docker上で稼働していた最初のAPIは順調で、すぐに50%の改善を達成し、Java 8から17へのアップグレードを完了しました。また、Spring Bootもアップグレードされました。
Spring Bootの依存フレームワークもアップグレードされました。少し戻って説明させていただきますが、必要な手動介入について触れると、Amazon Qを使用したり、パイロットを実施したりする予定がある方々には、開始前にアプリケーションのセキュリティやネットワークの変更、承認に必要な時間を確保することをお勧めします。
最初に実行したAPIは50%の効率化を達成し、これは素晴らしい結果で、目標の範囲内でした。2番目は、かなり以前に構築された最も古いAPIの1つでした。 アップグレード自体は上手くいきましたが、CamelフレームワークとOSGIがツールでカバーされていませんでした。 3番目のAPIはRancher上でホストされていました。JavaのバージョンとSpring Bootはアップグレードされましたが、JHipsterやLiquibaseなどの一部の依存関係やフレームワークはアップグレードされませんでした。
私たちの実験、経験、加速に投資していたAWSと協力し、これらのAPIを正常に変換するために必要なフレームワークと依存関係をより多くサポートできるよう、製品の改善に焦点を当てました。 改善後、同じAPIをAmazon Qで再実行したところ、効率が48%向上という、はるかに良い結果を得ることができました。今回はJHipsterフレームワークのアップグレードも成功しました。Nucleus APIを再実行した際には、Camel依存関係が追加され、 30%の向上を達成できました。これは素晴らしい結果でした。
Amazon Qの今後の展望についてお話しします。 2025年を通じて、すでに計画されているAPI近代化イニシアチブで本製品を活用していく予定です。修正やアップグレードに関するガイダンスの提供など、その他の機能を活用することで、Canada Lifeにおける生成AIの活用範囲を拡大していきたいと考えています。最終的な目標は、Amazon Qを私たちのソフトウェア開発スタックと開発パイプラインに統合し、開発を進める中で脆弱性を自動的に修正できるようにすることです。
Amazon Q Developer Agentの進化：デバッグ性能の向上
振り返りますと、Amazon Qを使用したパイロットプロジェクトを成功裏に実施し、 3つのAPIすべてにおいて平均40%の生産性向上を達成しました。さらに、Canada Lifeのアプリケーション環境のセキュリティ態勢も向上させています。1,000万ドルのイニシアチブと比べると25万ドルの削減は大きな額には見えないかもしれませんが、これは控えめな数字であり、今後さらに改善されていくでしょう。このパイロットは、将来の開発における可能性を示してくれました。
では、パイロット期間中に製品がどのように進化したのか、そして今後どのような展開が予定されているのかについて、Elioにバトンを渡したいと思います。ありがとうございます、Amber。皆様、このプレゼンテーションの最後のパートへようこそ。ここではAmazon Qのjava変換機能に関する改善点についてお話しします。まず品質の改善から始めましょう。 変換の品質、つまりQのコード変換能力の向上は、Canada Lifeの事例で示されたような生産性向上を実現するための基盤となるものです。変換品質の改善のため、私たちはデバッグフェーズから着手しました。ここで、Q Developer Agentのコード変換の仕組みを振り返ってみましょう。
この変換プロセスでは、Java 8または11からJava 17へとアプリケーションを移行し、すべての依存関係とフレームワークをアップグレードし、コードベース内の非推奨APIの使用をすべて排除します。変換の大部分は、コストと再現性の観点から、ナレッジベース適用フェーズで行われます。このナレッジベースには、どのライブラリをアップグレードするか、その方法、非推奨APIのアップグレード方法などの情報が含まれており、決定論的な変換と生成AIベースの変換の両方が含まれています。その後、コードベースの多様性や特定の一次利用方法により、ビルドエラーや、これらのローカライズされたナレッジベース変換では修正できない問題が残る可能性があります。これを解決するため、私たちのフローにはデバッグエージェントAIによる複数回のビルドとデバッグを実行するフェーズを設けています。
数週間前までのデバッグエージェントについて理解しておくべき重要な点は、ビルドエラーを1つずつ分析していたということです。ビルドが完了すると、ビルドログを分析し、エラーを見つけ、コードベース内のファイルでエラーの位置を特定して修正し、このプロセスを繰り返していました。これには多くの制限がありました。そこで、 数週間前に本番環境にリリースしたアップグレード版のAIでは、1つずつのエラー修正を超えた機能を実現しています。このために、変換フェーズにいくつかの機能を追加しました。まず第一に、エージェントにマルチエラーコンテキストを提供しました。 つまり、1つのエラーだけでなく、ビルドログ全体を提供することで、より広いコンテキストに基づいてより良いソリューションを見つけられるようになりました。
また、AIに複数のツールを使用する能力を与えました。単一ファイルでのローカライズと修正だけでなく、コードベースの閲覧、特定のパラメータの変更、複数ファイルの同時修正が可能になり、エージェントはより包括的なプランを立てて、ミスを修正し、マルチファイルのソリューションを実行できるようになりました。もう一つの基本的な追加機能は、イテレーション間のメモリです。ビルドのたびにゼロからやり直すのではなく、エージェントは以前何が効果的だったかを記憶し、それが後のソリューションにどのように影響するかを理解するための文脈を蓄積していきます。これにより、何が効果的で何が効果的でなかったかがより明確になるため、一貫性が向上し、ハルシネーションが減少します。また、以前のエラーのソリューションが、新しいデバッグの際に活用されることも可能になります。
メモリを持つようになったことで、エージェントは行き詰まりに遭遇したことを理解できるようになり、バックトラックする能力も与えました。このルームにいる開発者の皆さんなら、特定のデバッグの方向性がうまくいかず、以前のバージョンのコードにロールバックして最初からやり直さなければならない状況に遭遇したことがあるはずです。そして、これがまさにAmazon Qがデバッグ中に行うことを可能にした機能です。では、これがどのように機能するのか、もう少し詳しく見ていきましょう。これはエージェントのデバッグ部分です。Knowledge Baseによってコードが大規模に修正され、ビルドされた後、コードベースにビルドエラーが発生すると、それはMemory Management Agentに入ります。このエージェントの役割は、これらの結果からバグ修正に有用なコンテキストを特定することです。
次に、Self-Critic Agentに移ります。このエージェントの役割は、実行されていることが適切かどうかを判断し、その時点までに起こったことについてフィードバックやコメントを追加したり、新しいアイデアを試したり、うまく機能していない提案を指摘したりすることです。これは行き詰まりを特定するエージェントでもあり、その場合はロールバックを行います。Debugger Agentは、Self-Critic Agentからコンテキストを受け取り、すべてを分析して、ミスを修正するプランを立てます。
これを実現するために、エージェントは一連のツールにアクセスできます。これらのツールには、ファイル編集やファイルブラウジングなどの汎用的なものや、依存関係の追加やビルドの検証に関連する専門的なものがあります。重要な点として、私たちはAmazon Q Developerに、たとえ自社のSandbox内であっても、コードベースで任意のコマンドを実行する能力は与えていません。このアプローチにより、ハルシネーションを防ぎ、プランをバグ修正により焦点を当てたものに保つことができます。
ツールの実行により、通常は新しいビルド、ビルドエラー、または成功といった結果が生成され、プロセスが再び開始されます。これは、ビルドが成功するかリソースを使い果たすまで続きます。例を見てみましょう。これは、Knowledge BaseがVectorとEnumerationクラスの古い従来の使用法をCollectorsに置き換えた事例です。これらのメソッドを非慣用的な方法で使用している特定の関数呼び出しのローカライズされたコンテキストで、大規模に実行されました。ここでは、コレクション、カウント処理、結合操作に関するケースが見られます。
このビルドログがデバッグエージェントに入ると、「cannot resolve symbol collectors」を示す一連のエラーが発生します。これは、ナレッジベースがこれらのファイルにCollectorsのインポートを追加しなかったためで、多くのファイルで同時に一貫性を保つために非常にローカライズされた処理となっています。 エラーを1つずつ対処してファイルごとに異なる解決策を生み出すリスクを冒したり、同じバグを完全なリビルドで何度も解決するリソースを無駄にしたりする代わりに、改良されたエージェントはすべてのエラーを同時に認識し、すべてのファイルに対する解決策を計画して実行します。
これで、すべてのファイルに必要なインポートが追加されたことが確認できます。しかも、その間にビルドを実行する必要がなく、そのリソースを他のバグの解決に活用できます。その結果は顕著でした。以前の1つずつ処理するデバッガーと比較して、デバッグのパフォーマンスが85%向上しました。 この測定結果は、それぞれ10万行以上のコードを含むオープンソースアプリケーションを使用した社内ベンチマークから得られたものです。数週間前に本番環境にデプロイされたこの新しいエージェントのパフォーマンスを、私たちは継続的にモニタリングしています。
Amazon Q Code Transformationの新機能と今後の展望
この分野の今後の展開はどうなるでしょうか？ 複数のファイルにまたがって計画を立て、複数のツールを活用できるこのエージェントのアプローチは、デバッグ以外にも拡張できます。そして、それが私たちの現在の計画です。また、このエージェントを今後のコード変換開発のすべての基盤として活用することも計画しています。 ここで話題を変えましょう。品質の向上に取り組む一方で、Amazon Q Code Transformationをより効果的に、そしてより多くのユースケースで使用できるようにすることも目指しています。
昨年、お客様から寄せられた重要なフィードバックの1つは、大規模なコードベースに対するQの変換で出力される大きな差分のレビューが困難だということでした。これに応えて、複数ステップの変換を要求してQを実行するオプションを実装しました。これにより、1つずつレビューできる複数の差分が生成されます。例えば、最初の差分で最小限のJava 17へのアップグレード、2番目の差分でJakarta EEやHibernateなどのエンタープライズライブラリ、そして他のWeb Frameworkという具合です。これにより、開発者はすべての変更を一度に把握する必要がなく、各ステップでの変更に集中できます。
私たちが繰り返し耳にした2つ目の質問は、 すでにJava 17で動作しているJavaアプリケーションでのライブラリアップグレードについてです。古いバージョンのSpring BootやHibernate、JUnitを使用している場合、Amazon Q Developer Agentによるコード変換をレガシーアプリケーションでしか使用できないという制限は、実際の使用可能性を制限していました。数週間前にリリースしたのは、すでにJava 17で動作しているアプリケーションのライブラリやフレームワークのみをアップグレードする機能です。そのために、Amazon QはMaven Centralの50万以上のライブラリをスキャンし、相互依存関係とセキュリティの脆弱性を考慮して最適なバージョンを選択し、最も有望なアップグレードパスを提供します。
これにより、以前の部分的な変換で発生した問題を修正した後に、変換エージェントを再度実行することができます。これは、Amazon Qが修正できない独自の依存関係を持つアプリケーションで時々発生します。そのため、最初の部分的な成功の後で立ち往生してすべてを手動で行わなければならない状況ではなく、手動で修正を行い、Amazon Qにまだ更新可能な他のライブラリをアップグレードする追加のチャンスを与えることができます。この短いデモを見てみましょう。時間の都合上、ここではビデオを進めていきます。
これから、ライブラリのみのステップバイステップのレビューとアップグレードの方法についてのデモをご覧いただきます。このアプリケーションはすでにJava 17で動作していますが、Spring Boot 2.7をアップグレードしたい状況です。現在、Amazon Qはこのアプリケーションを処理できます。ソースのJavaランタイムバージョンとして17を設定できます。速度を重視する場合はユニットテストをスキップすることができ、また結果として複数の差分を要求することもできます。これは先ほどのデモと全く同じプロセスを経て、基本的に計画を表示します。実行する予定のすべての内容を示します。
JDKアップグレードについては、Spring 2.7から3.3へ移行することがわかります。追加項目と削除項目があり、非推奨APIはなく、変更予定の項目リストが提供されます。このプロセスが実行されると、全く同じステップを踏みます。ビルドを試み、依存関係を更新し、その間に非推奨となった項目を探し、変更内容をダウンロードする機能を提供します。
そして大きな変更が見えてきます。単一の差分ではなく、4つのパッチのうちの最初のパッチが表示されます。これはJava 17へのアップグレードで、Spring Bootの3.3へのアップデートも含まれています。すべてのファイルでJava XからJakartaへの移行が行われ、その他の変更も行われます。開発者はこれらのパッチを1つずつ承認できます。次にMavenの更新があります。これはハッシュを生成するためのより良い慣用的な使用方法です。POMファイルの差分もあります。
これにより、アプリケーションを最新の状態に保つことができます。Java 17を使用している場合、Amazon Q変換はレガシーアプリケーションのモダナイゼーションキャンペーンだけに限定されません。すでにJava 17を使用しているアプリケーションでも、最新の状態を保つことができます。Amazon Qは最新リリースを追跡し、最近プレビューでリリースしたこの新機能を使用してこのプロセスを自動化できます。多くのお客様から明確に聞いた要件の1つは、この変換を大規模に自動化することでした。
現在のエクスペリエンスはIDEベースのもので、パイロットプロジェクトや少数のアプリケーションを扱う場合には最適です。しかし、お客様が数百のパッケージをアップグレードする必要がある場合、アプリケーションの変換を自動化し、開発者が確認できるように差分を生成したいと考えています。これは、手の届きやすい部分からより効率的に対応できるアプローチです。一部のアプリケーションはすぐに成功するか、非常に簡単に変換できる場合があり、現在プレビュー版として提供しているCommand Line Interfaceを使用することで、大規模に自動化することができます。 これは、シンプルなPythonベースのCLIで、独自のスクリプトに組み込むことができ、さらにCI/CDパイプラインにも統合して、アプリケーションを最新の状態に保ち、変更があった場合にはそれを示し、差分をPRとしてソース管理システムにプッシュすることができます。
スケーリング時にもう一つ要望があったのは、独自のカスタムフレームワークや、Amazon Qのナレッジベースでは対応できない特定の変換など、コードベースに特有の変換が必要な場合があるということです。プレビュー版として提供しているのは、Qのブロックを解除し、大規模に実行するための決定論的な変換を定義する機能です。これはYAMLファイルとして定義され、 現在、複数のフォーマットをサポートするよう取り組んでいます。この機能の目的は、特定のコードを変換する能力をQに与えることです。これを行うと、先ほど見たスマートデバッガーの利点を、カスタム変換でも活用することができ、そのためのコーディングは必要ありません。単に、カスタム変換の後に実行され、結果として得られるコードベースのデバッグを修正してくれます。
今日、私たちは何をお見せしたでしょうか？まず最初に示したのは、改良されたAIです。 これは、Q変換エージェントの変換品質を向上させるという私たちのコミットメントにおいて非常に重要です。これは、お客様のプロジェクトで見られる加速の基礎となるものです。マルチエージェントデバッガーにより、既存のQ Developer Agentのデバッグ性能が85%向上しました。 また、Java 8や17の古いアプリケーションのモダナイゼーションプロジェクトだけでなく、すでにJava 17上にあるアプリケーションのモダナイゼーションと継続的なメンテナンスを可能にしたいと考えています。そのため、ライブラリのみのアップグレード、開発者のレビュー体験を向上させるためのステップバイステップの差分表示、部分的な成功と修正後にQを再実行して変換機能を最大限に活用する機能を追加しました。
最後に、Java変換のためのCommand Line Interface のプレビューを行いました。これは、Javaアプリケーションのアップグレードとメンテナンスを自動化するために重要です。これには、ファーストパーティやコードベースに特有の要素に対してQのブロックを解除するために、お客様が提供するカスタム変換を大規模に実行する機能が含まれています。どのように始めることができるでしょうか？ 今すぐTransform for Java applicationsを評価して、アップグレードを開始することができます。Amberが話していたように、これは計画的なメンテナンスとアップグレードサイクルの文脈で行う必要があります。これは、コードベース全体を魔法のように自動的にアップグレードする魔法の杖ではありません。しかし、私たちは一貫して30〜40%の生産性向上を確認しており、最近リリースした新機能によってこれらの数値がさらに改善されることを期待しています。また、ソフトウェア開発ライフサイクルのメンテナンスとモダナイゼーションフェーズだけでなく、すべてのフェーズをアップグレードするためにAmazon Q Developerを試すことをお忘れなく。
ここにいらっしゃる皆様、そして登壇者の皆様に感謝申し上げます。 ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion