re:Invent 2024: AWSがAmazon Q Developerで.NETのLinux移行を加速
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Accelerate .NET porting from Windows to Linux with Amazon Q Developer (DOP208-NEW)
この動画では、WindowsからLinuxへの.NETアプリケーションの移行を支援するAmazon Q Developerの機能について解説しています。Linuxへの移行によって最大40%のライセンスコスト削減やパフォーマンスが1.5-2倍向上するメリットがあることを示しながら、Visual Studio拡張機能とWebコンソールという2つのインターフェースを通じた変換プロセスをデモで紹介しています。Amazon Q Developerは、Large Language Modelとドメインエキスパートなエージェントを活用して.NETコードを自動解析・変換し、人による監督とガードレールを組み合わせることで、数百のアプリケーションを同時に4倍のスピードで移行できる機能を提供します。SignaturitやCockroach Labsなどの導入事例も紹介されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon Q Developerによる.NETアプリケーションのLinux移行：概要
Amazon Q Developerを使用してWindowsからLinuxへの.NETポーティングを加速する方法についてのセッションへようこそ。私はMurtaza Chowdhuryです。AWS Migration and Modernizationチームでプロダクトマネジメントを率いています。私のチームは、本日ご紹介するAmazon Q Developerの変換機能として提供されている生成AIの機能を開発してきました。本日は、2人の素晴らしい同僚が参加しています。まもなくご紹介しますが、Principal Engineerで本日ご紹介する機能のアーキテクトであるRaviprasad Mummidiと、プロダクトリードのNits Jeganathanです。
本日は、なぜ.NETアプリケーションをLinux対応にする必要があるのかについてお話しします。.NET Frameworkからクロスプラットフォームの.NETへの移行について、お客様がどのように考え、どのような課題があるのかを見ていきます。そして、Amazon Q Developerの変換機能、特に.NET向けの機能についてお話しします。これらの機能は、.NETコードをポーティングしてLinuxインスタンス、コンテナ、サーバーで実行できるようにするというビジネス目標の達成を支援します。複数のデモをご用意していますので、これらの機能をご紹介するとともに、これらの機能の開発の背景や、生成AIやLLMをどのように活用したか、私たちの考え方についてもお話しします。
WindowsからLinuxへの移行：背景と課題
まず、AWSでは2008年からMicrosoftのワークロードを実行してきました。お客様は自社のワークロードを正常に実行し、ビジネスを成長させてきました。しかし、お客様からは、ライセンスソフトウェアから脱却してオープンソースに移行したいという声を聞いています。その理由はいくつかあります。まず第一に、コストの面でのライセンス費用の削減です。WindowsからLinuxに移行することで、最大40%のライセンスコストを削減できます。第二に、パフォーマンスの向上です - Linuxでの実行はWindowsと比べて1.5倍から2倍速くなります。Windowsで実行する際のメンテナンス、運用の負担、パッチ適用などを考えてみてください。これらはすべて、Linuxに移行すれば解消されます。
お客様が次に注目するのはスケーラビリティです。変革全体を考えた場合、アプリケーションをLinux対応にして移行した後は、モノリスをマイクロサービスに分解し、可能な限りスケーラブルにして、開発者の生産性向上と迅速なイノベーションによるビジネスの成長を実現したいと考えます。これらの理由から、お客様のWindowsからLinuxへの移行の緊急性がさらに高まっているのを目にしています。実際に、お客様がLinuxを採用することでWindows使用率を70%以上削減した事例も見ています。
この変革の旅は、様々な方法で考えることができます - アプリケーションをリアーキテクト、リライト、リデザインすることができます。しかし、できるだけ早くオープンソースとLinuxのメリットを享受するには、.NET Frameworkからクロスプラットフォーム.NETへのポーティングという、より簡単な、より短い道があります。まず第一に、クロスプラットフォームであることから、アプリケーションに最適な展開方法を選択できます。第二に、より高いパフォーマンスが得られ、運用負荷が軽減され、パフォーマンスが向上し、マイクロサービスアーキテクチャへの移行が容易になり、コミュニティのサポートを受けられます。クロスプラットフォーム.NETは巨大なユーザーグループによってサポートされており、コスト効率も優れています。
お客様からは、次に構築したい大きなプロジェクトのための資金調達についてよく相談を受けます。コスト効率は、お客様が重視する重要な要素です。このTransformation journeyによって得られる40%のコスト削減は、次のイノベーションの資金源となり、アプリケーションの成長を支援できます。新しいテクノロジーに精通したチームがいる一方で、変革が必要なレガシーアプリケーションも維持しているかもしれません。お客様からは、この課題を時間をかけずに解決する方法が必要だと伺っています。
典型的な.NETのポーティングプロセスについてご説明します。お客様は最初に、コードベースやプロジェクトの種類、互換性の問題などを分析することから始めます。これは手作業で行うか、リンキングツールを使用して行います。分析が終わると、これまで手作業で行われてきたコードの変換作業を含むポーティング作業を開始します。ポーティング後は、組織の準備態勢、検証、テスト、セキュリティの耐性確認、選択したターゲットへのワークロードのデプロイメントに取り組む必要があります。適切なターゲットの決定や、どのワークロードを実行するかの判断も、さらなる複雑さを生み出します。
数百のアプリケーションで構成される企業のポートフォリオを考えてみましょう。この作業は各アプリケーションに対して繰り返し行う必要があります。アプリケーション間の依存関係は、変革の優先順位や順序に影響を与え、さらなる複雑さを生み出します。お客様の事例から、通常は大規模な事業部門、多数の部署、そして組織全体でこの取り組みを主導する中央のITチームやDevOpsチームが存在することがわかっています。まず、各チーム間で調整を行い、全員の同意を得てTransformation journeyを開始する必要があります。この作業は人材のスキルに大きく依存するため、エラーが発生しやすく、特に依存関係が絡む大規模な環境では、必要な連携の量が膨大になり、非常に困難で時間のかかるプロセスとなります。
Amazon Q Developerの.NET変換機能：Visual Studioでのデモ
基調講演で、Matt GarmanがAmazon Q Developerの.NET向けTransformation機能について発表しました。これらの機能についての私たちの考え方をご紹介したいと思います。私たちは、すべてのMigrationとModernizationのニーズに応える一元的な体験としてこれを構想しています。このサービスは、MigrationとModernizationにおける長年の経験に基づいて学習し、基盤となる大規模言語モデルとドメインエキスパートAIエージェントを構築しています。これは、お客様のチームを拡張するものとして、お客様の監督のもとで専門知識を提供するものと考えています。組織のプロセスや基準に従う必要がある場合は、これらの機能を監督し、お客様の設定を提供することができます。これについてより詳しく説明するために、Raviprasad Mummidiをステージにお招きし、いくつかの機能とその基盤について説明してもらいましょう。
では、Amazon Q Developerエージェントの実際の動作をご覧いただきましょう。時間を節約するために、デモを事前に録画させていただきました。ここでご覧いただいているのは、オープンソースの.NET Frameworkショッピングカートアプリケーション、Bob's Bookstoreが読み込まれたVisual Studioです。また、Amazon Q Developer用のVisual Studio拡張機能も読み込んでおり、Solution Explorerでプロジェクトを右クリックすると、「Amazon Q Developerでプロジェクトをポートする」という新しいオプションが表示されます。
クリックすると、ポート先の.NETのバージョンを選択できるダイアログボックスが表示されます。この場合は.NET 8です。また、後方互換性のために.NET Standardプロジェクトをそのまま維持するか、新しいバージョンの.NETにポートするかを選択することもできます。私はすべてのプロジェクトを.NET 8にしたいので、.NET Standardプロジェクトをポートするオプションを選択して開始します。ここで見ているように、Amazon Qは、Bookstore.Webプロジェクトを変換するために、Bookstore.Common、Bookstore.Data、Bookstore.Domainという3つのプロジェクトも必要だと判断しました。「Bookstore.Web code group」という名前をメモしておいてください。後で説明します。
変換プロセスが始まると、進行状況が表示されます。通常のビルド出力からAmazon Q Language Clientの出力ウィンドウを開いて、より詳細な進行状況を確認できます。Q変換の進行状況バーの通知が表示されましたが、これはQ変換がバックグラウンドで実行できるようになったことを示しています。プロジェクトのサイズによってQ変換にかかる時間は様々なので、もうVisual Studioウィンドウを開いたままにしておく必要はありません。このデモでは、Qの進行状況を確認できるように開いたままにしています。
Qがバックグラウンドで異なるプロジェクトを変換する際の各ステップが表示されます。右側では、プロジェクトごとの進行状況も確認できます。プロジェクトの変換が完了すると、変換サマリーを生成し、結果をダウンロードしてコードの差分を生成します。次に、変換プロセス中に何が起こったのかを確認したいので、これらの通知をいくつかクリアして場所を空けます。通知バーを閉じたら、コード変換サマリーを表示します。
これを開くと、Qが実行したことが表示されます。Qは変換した各プロジェクトを表示し、変更されたファイル数、更新されたパッケージ、変更されたAPIの概要を提供します。実際のコードの変更内容をより詳しく見たいので、上部にある差分表示ボタンをクリックします。クリックすると、Qが行ったコードの変更が表示されます。まず、追加または変更されたファイルのリストが表示されます。Program.csファイルを見てみましょう。このファイルは、アプリケーションが新しいバージョンの.NETで機能するために実際に必要なものです。Qは、このアプリケーションが新しいバージョンの.NETで動作するために必要だと判断し、自動的にこのファイルを生成しました。新しいファイルを確認したので、既存のファイルにどのようなコード変更が加えられたのかも確認したいと思います。
このAuthenticationController.csファイルを選択すると、左側に.NET Frameworkのコード、右側に変換された.NETのコードが表示されるサイドバイサイドの差分ビューで確認できます。ここで見られるように、Amazon QはSystem.WebとSystem.Web.MVCが新しいバージョンの.NETと互換性がないと判断し、置き換えを行いました。このファイルには他の変更点もありますので、それぞれの変更内容を確認して、満足できるものかどうかを判断できます。この場合は問題ないので、これを閉じることにします。
このウィンドウを閉じると、差分を適用するオプションが表示されます。ここでコードの変更を選択的に適用したいファイルを選ぶか、すべての差分を選択して適用することができます。差分を適用すると、これらの変更はVisual Studioにチェックアウトされているコードのローカルバージョンにのみコミットされます。ファイルが再読み込みされたら、正しく処理されたことを確認しましょう。ファイルを再読み込みして、新しいファイルを確認してみましょう。先ほどAuthenticationControllerを見ましたが、今度はHomeControllerを見てみましょう。ご覧の通り、このファイルは修正され、新しいバージョンの.NETで動作するようになっています。
Amazon Qの動作を確認したところで、その裏側で何が起きているのか詳しく見ていきましょう。目的志向型エージェントであるAmazon Qは、Bookstore.Webプロジェクトを変換するために、Bookstore.Domain、Bookstore.Data、Bookstore.Commonという3つの追加プロジェクトも必要だと判断しました。これはコードグループと呼ばれるものを形成することで実現されます。先ほどBookstore.Webコードグループに注目するように言いましたが、まさにそれがここで行われたことです。3つの他のプロジェクトを依存関係として持つコードグループを作成したのです。この場合、Bookstore.Webが他のプロジェクトに直接依存するという形でした。Amazon Qは、他の依存パターンやその組み合わせも理解できる高度な機能を備えています。
Amazon Qが様々なプロジェクトとコードグループを特定すると、アプリケーションの異なる部分の作業を開始します。.NET Frameworkのスタートアップ設定とweb.configから始めて、新しいバージョンの.NETでアプリケーションが機能するようにする.NETミドルウェアコードを生成します。同様に、ビジネスロジックと付随するユニットテストを新しいバージョンの.NETで動作するように変換します。Amazon Qはこれを分析、修正、検証のループ、いわゆるトリアージプロセスを通じて行います。
この分析、修正、検証のトリアージプロセスについて、さらに詳しく見ていきましょう。Amazon Qが.NET Frameworkのコードブロックを取り上げると、まず非互換性と呼ばれるものを分析します。非互換性とは、新しいバージョンの.NETでそのままでは動作しない1行以上のコードを指します。Amazon Qは、キュレーションされた.NETポーティングのナレッジベースを使用して、新しいバージョンの.NETで動作する置換コードを特定し生成します。新しいバージョンのコードを生成し、これらのコード修正を適用します。コード修正を適用した後、検証プロセスを実行します。検証プロセスからは2つの結果が得られます - コードがクリーンで検証が成功し、コードを新しいバージョンの.NETに変換するという目標を達成するか、あるいは検証が失敗するかです。失敗した場合、プロセスは再び開始され、置換コードの特定と生成を行い、このプロセスを繰り返し適用します。これを私たちはAmazon Q .NETエージェントの自己デバッグ機能と呼んでいます。
Amazon Q Developerの評価システムと現在のサポート範囲
コードがどのように変換されるかを確認できたところで、変換プロセス全体をどのように評価できるかを知りたいと思いました。変換プロセス全体を評価するための評価基準の構成要素を考え出すことにしました。2つのポイントを考え出しました。1つ目は、Amazon Qが非互換性のあるコード行を正常に移植できるかどうかです。
第二に、Amazon Q Developerの非決定論的な性質、特に成功を一貫して再現できるかという点です。これら2つの評価基準を基に、私たちは評価システムの構築に着手しました。
評価システムは小規模からスタートしました。最初は少数のプロジェクトを選び、変換されたコードの構文エラーをチェックしました。規模を拡大していく中で、対象を広げて様々な種類の.NET Frameworkプロジェクトを含めていきました。例えば、クラスライブラリから始めて、コンソールアプリケーション、Web API、WCFにまで拡張しました。.NET Frameworkから新しいバージョンの.NETへのコード変換に自信が持てるようになると、設計パートナーのお客様と密接に協力して、何千ものプロジェクトに対してシステムの検証を行いました。
現在のAmazon Q Developer transform for .NETのプレビューバージョンでサポートされている内容について、簡単にご説明します。現在サポートしている様々なプロジェクトタイプ、ソースバージョン、ターゲットバージョンについてはすでにお話ししました。ここで疑問に思われるかもしれません。1つの.NETアプリケーションの変換に成功した後、何百もの.NETアプリケーションをどうするのか？ソースコードリポジトリにアクセスして、それぞれをチェックアウトし、Visual Studioに読み込んで、一つずつ変換作業を行う必要があるのでしょうか？それとも、もっと良い方法があるのでしょうか？おそらくお察しの通り、より良い方法が用意されています。.NETアプリケーションを大規模に移行する方法について、Nitsをステージにお招きしてお話しいただきましょう。
大規模.NET移行のためのWebコンソールエクスペリエンス
ありがとう、Ravi。ご覧の通り、Amazon Q Developerは.NET Frameworkから.NET 8への移行に強力な機能を提供しています。しかし、これはすべてのお客様に対応できるのでしょうか？Raviが言及したように、私たちは何百ものアプリケーションを持つお客様と話をしてきました。彼らは一つずつアプリケーションを変換するために専任の開発者の時間を割り当てたくないと考えています。ソースコードリポジトリから始めて、コードを分析し、プロジェクトタイプと依存関係を特定し、可能なものすべてを変換し、必要な場合は変換を監督・指導できるようなソリューションはないかと尋ねられました。変換が完了したら、同じソースコードリポジトリの新しいブランチにコミットし、開発者がコードをレビューして、必要に応じてマージやデプロイの次のステップに進めるようにしたいとのことでした。
私たちが受けた重要なフィードバックの1つは、このプロセスを担当するユーザーペルソナの変更についてでした。開発者を割り当てる代わりに、DevOpsエンジニア、ITアドミン、またはITリーダーがこれらのアクションを開始し、必要な場合にのみ開発者が関与し、選択したアプリケーションに応じて専任チームと協力するという方法を検討していました。Raviと同様に、私もデモを録画しましたが、体験をよりよく理解していただくために、順を追って説明させていただきます。
このケースでは、体験はVisual Studioではなく、Webコンソールから始まります。まず認証情報を入力すると、ワークスペースにアクセスできます。これがすべてのポーティングジョブのコンテナとして機能します。リポジトリから選択したい特定のアプリケーションについて、1つのジョブを持つことも、数百のジョブを持つこともできます。これがあなたの自由に使えるワークスペースです。最初にやりたいことは、意味のある名前に変更することでしょう。そして、Amazon Q Developerにジョブの作成を依頼することができます。この時点では、まだ何にもアクセス権を与えていません - 純粋にAmazon Q Developerとの対話を通じて、目的を伝え、やりたいことを特定し、システムを理解するだけです。
ジョブの作成を依頼すると、チャットウィンドウが開きます。Mattのキーノートで発表されたように、私たちは3つのユースケースをサポートしており、.NET modernizationはそのうちの1つです。
これらのユースケースには、.NET modernization、VMware modernization、そしてMainframe modernizationが含まれます。この特定の聴衆向けには、.NET modernizationに焦点を当てています。具体的に何をしたいのかを確認するオプションが提示され、私たちはオプション1を選択しています。 これはAmazon Qが自動的に行っていることで、ジョブタイプを設定し、達成したい目的を設定し、デフォルトのプロジェクト名を設定して、すぐに始められるようにしています。このジョブを開始した後でも、これらすべてをカスタマイズするオプションは常にあります。
Amazon Q Developerが行ったのは、フォローすべき手順のシーケンス、つまり高レベルな軌道を作成することです。Raviprasad Mummidiが Visual Studioでデモンストレーションしていたものに戻ると、同じステップがありましたが、それは単一のアプリケーション向けでした。ここでは、大規模な変換レベルでそれを抽象化しています。ソースコードリポジトリから始めることができます。最初に行うことは、ソースコードリポジトリをAmazon Q Developerに接続することです。
そのためには、AWSアカウント と、Code Connectorと呼ばれるものから始めます。AWS CodeConnectionsは、GitHub、GitLab、Bitbucketなどの既存のソースコントロールとの相互作用と接続を可能にする既存のサービスです。この特定のリリースでは、GitHub接続をサポートしています。CodeConnectionsでGitHubコネクタをセットアップするための手順に従い、リソース番号を取得したら、ここでこのリンクを確立します。これにより、ソースコードリポジトリとの既存の相互作用メカニズムをスケールアップし、統合することができます。
接続が確立されると、コピー検証用のリンクが提供されます。この手順は非常に重要です。なぜなら、Amazon Qはソースコードリポジトリに直接アクセスして操作を開始することを望まないからです。適切なアクセスレベルと適切なリポジトリ、アカウントを確保したいのです。Amazon Q Developerでは、Qがリポジトリにアクセスする前に、管理者がこれをレビューして承認する必要があります。
管理者が承認すると、元の画面に戻ると、コネクタが承認されたことが確認できます。この時点で、Amazon Q Developerは管理者が接続を承認したことを確実に把握し、あなたが何が起きているかを確認できる状態を保ちながら、リポジトリの数やプロジェクトタイプの数を特定するための評価を開始できます。
このプロセスは、Qに送信することから始まり、Qは自動的にディスカバリーを開始します。ここで見られるように、作業ログの項目には、どのユーザーがこのアクションを開始し、どのような入力を提供したかが表示されます。これを使用して、実行されたアクションを遡って追跡することができます。Amazon Qはディスカバリーを開始し、GitHubアカウント内のリポジトリのリストを特定しました。必要であれば、これらのリポジトリすべてを変換することもできます。ただし、すべてを変換したくない場合は、特定のリポジトリだけを選択するオプションもあります。
この例では、複数のリポジトリを選択しています。もう一つの重要な点は、このケースでは私がこのQ Developer環境の管理者であるため、検証は必要ありません。しかし、もしあなたが単なる貢献者の立場である場合、リポジトリを選択した後でも、変換対象として選択されたリポジトリを管理者がレビューするために、その要求が管理者に送られます。変換プロセスが開始されるのは、その後になります。これは重要なポイントです。なぜなら、Q変換は一括で実行されるため、許可されていないものを変換しないようにする必要があり、この人による監督とガイダンスは、それを実現する方法の一つだからです。
この例では、変換を開始し、作業ログが更新され、変換が進行していく様子が表示されます。ご覧のように、作業ログは0行から1,000行、6,000行へと進むにつれて更新されていきます。作業ログを通じて何が起きているかを継続的に追跡できますが、常に作業ログを通じて確認する必要はありません。
私たちには、同時に実行されているこれらのBulk変換の現在のステータスに関する情報を表示するダッシュボードがあります。 この場合、サポートされているプロジェクトタイプで変換している数百のリポジトリがある可能性があります。特定のリポジトリを確認して、その中で何が起きたのか、完全に変換されたのか、部分的に変換されたのか、あるいは対処が必要な失敗があるのかを確認したい場合があるでしょう。それぞれをクリックして詳細を確認することができます。
ここでは、.NETのバージョンが6.0であること、特定された行数と実際に変換した行数を確認できます。削除した行もあれば、追加した行もあるかもしれません。これは非常に重要です。なぜなら、これらは長時間実行されるジョブになる可能性があり、お客様やIT管理者が常にコンソールの前に座っているわけではないからです。戻ってきたときに、Work Logsを確認するか、このダッシュボードで進捗状況を確認することができ、いつでもダウンロードしてエクスポートすることができます。
変換が完了した後の最後の確認事項として、ターゲットブランチの宛先として新しいブランチを作成し、レビュー用にGitHubリポジトリにコードをコミットします。 これは私のGitHubアカウントで、リポジトリに移動すると、ここに複数のブランチがあります。 D05ブランチにコピーすると指定したブランチを選択できます。そこで1つのコミットが行われたことが確認できます。Qがこの特定の変更をコミットしたことがわかります。
Visual Studioで見るのと同じものを、一括で確認するオプションがあります。これは、この特定のブランチをローカル環境にクローンして、Visual Studio IDEで行ったのと同じことができるということでもあります。 この場合、Qがコミットを行い、このファイルでは.NET 6.0から.NET 8に更新されたことがわかります。 同様に、CSプロジェクトについても、.NET 6から始まり、現在は.NET 8に更新されています。これらはすべてQがデフォルトで行う変更であり、マージして既存のビルドシステムCI/CDパイプラインで実行できるかどうかを確認できます。
ダッシュボードとWork Logsが必要な理由を強調しておきたいと思います - Amazon Qはお客様に代わって多くのことを行います。先ほど申し上げたように、お客様は長時間実行されるジョブで何が起きたのかを確認するために、常にWebコンソールの前に座っているわけではありません。お客様には2つの主要な手段があります。1つ目は、すべての順序付けられたステップ、どのユーザーが何を行ったのか、タイムラインを示すCloud Trailに相当するWork Logで、これは価値の証明と監査証跡を提供します。2つ目は、全体的に何が起きているのか、介入の準備ができているのか、完了しているのかを把握するためのダッシュボードです。
Amazon Q Developerの利点とお客様の声：まとめと今後の展望
それでは、締めくくりとしてMurtazaにバトンを渡したいと思います。まず、素晴らしいデモを見せてくれたNitsとRaviに感謝します。先ほどの2つのデモで見ていただいたのは、実際に活用できる2つのエクスペリエンスです。先ほど説明したシナリオを思い出してください - WindowsからLinuxへの.NETアプリケーションの移行を主導する中央ITチームやDevOps管理者がいて、開発者を含むビジネスユニットやアプリケーションチームがいる状況です。
これら2つのエクスペリエンスは、異なるペルソナによって使用できます。ITアドミンやDevOpsアドミンの場合は、Amazon Q Developer for .NETの変換機能を直接ソースコードリポジトリに接続してアプリケーションの移行を開始できます。アプリケーションチームの開発者の場合は、Visual Studio IDE拡張機能を使用できます。
基盤となる機能、Large Language Model、そして手法は、同様の結果を提供するために共通のファブリックを共有しています。一方は個々のアプリケーションプロジェクトやソリューションを一度に処理し、もう一方はWebエクスペリエンスで数百のアプリケーションを一括で移行できる大規模な処理を行います。これらはすべて、デモでご覧いただいたのと同じジャーニーを経ています - コードを分析し、変換を開始します。最も重要なのは人による監督の側面で、ダッシュボードやワークログを通じて、いつでもコントロールと可視性を確保できます。コンプライアンス上の義務があり、監査証跡を示す必要がある場合は、ワークログを活用して詳細な履歴を確認できます。
移行の過程で、ダッシュボードを使用して進捗状況を確認できます。これらすべてが進行する中で、 チームとうまく統合できるシステムを慎重に設計しています。人による監督とガードレールは、AIとそれをチームに導入する方法における重要な側面です。私たちが慎重に設計したものの中には、作業の進行に応じてレビュー、調整、承認、変更を行うためのコントロールレベルがあります。
先ほどのデモを振り返ってみると、コネクタをソースコードリポジトリに接続した際、ブランチを選択する機会があり、その後承認フローが開始されました。複数のチームメンバーが作業している場合 - 一人が選択を行い、別の一人がレビューと承認を行うといったシナリオ - これらのシナリオはシステムで対応可能で、その承認と選択のプロセスの監査証跡が維持されます。さらに、変換が進行する中で入力が必要な場合、アプリケーション内で通知が提供され、アクションを取ることができます。Visual Studioのデモに戻ると、元のコードと変換後のコードの違いを確認する機会があり、同様にGitHubリポジトリ内で大規模に実行することもできます。
ここで、この製品がどのようにお客様のお役に立てるかについてお話ししたいと思います。私たちのテストとベンチマークによると、処理速度が最大4倍に向上し、数百のアプリケーションを同時に移行できる大規模な並列処理が可能になります。また、大規模な可視性が得られ、人による監視も重要な要素となっています。移行プロセスが完了すると、先ほどお話しした、Linux対応アプリケーションへの移行後に得られる40%のライセンスコスト削減というメリットを享受できます。
この製品の開発にあたり、私たちは設計パートナーや早期採用者として多くのお客様と協力してきました。彼らは結果を見て非常に興奮し、フィードバックを提供し、このプロセスで私たちと協力してくださいました。ここで、お客様からいくつかの声を紹介させていただきます。1つ目は Signaturit Groupからです。彼らはヨーロッパのデジタルセキュア取引企業で、データアプリケーションに Amazon Q Developer の変換機能を活用し、先ほど説明した高速化のメリットを実現しています。
もう1社は Cockroach Labsで、SQL Server互換の機能を備えた分散型SQLサーバーDBを提供する業界のリーダー企業です。彼らも私たちの製品を活用しています。
本日お話しした内容を振り返ってみましょう。お客様がWindowsからLinuxへ移行している状況と、.NETアプリケーションの移行がその journey を加速させている点について説明しました。Webインターフェースを使用して大規模に移行できる製品についてお話しし、アプリケーションチームの場合は Visual Studio IDE拡張機能を使用できることをご紹介しました。これらすべては、お客様が完全にコントロールを保持し、プロセスを監視しながら、アプリケーションをWindowsからLinuxへ移行し、コスト最適化のメリットを得て、そこからさらなるイノベーションを実現できるようになっています。
ぜひ、Amazon Q Developerをチームに迎え入れ、ドメイン特化型AIエージェントとしてチームを強化し、.NETアプリケーションをWindowsからLinuxへより迅速に変換するお手伝いをさせてください。これにより、より速いイノベーション、ビジネスの成長が可能になり、スケーラビリティのメリットとアプリケーションに必要なすべてのパフォーマンスを実現しながら、規模を拡大することができます。
このプロダクトを実際に試せる別のセッションについてお伝えしたいと思います。明日の正午にワークショップを開催する予定です。実際に試してみたい方のために、ユースケースやシナリオをご用意しています。チームと一緒にウォークスルーを行うことができ、チームメンバーの何人かも参加しますので、直接お話しすることもできます。プロダクトについてのご意見もぜひお聞かせください。
それでは、Raviprasad MummidiとNits Jeganathanをお迎えしたいと思います。本日の午後のセッションにご参加いただき、ありがとうございました。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion