re:Invent 2024: Amazon Q Developer AgentsによるSDLC効率化 - DTCC事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Accelerate multistep SDLC tasks with Amazon Q Developer Agent (DOP210)
この動画では、Amazon Q Developer agentsによる開発効率化について解説しています。DTCCでの導入事例では、開発者の生産性が40%向上し、コード欠陥が30%減少するなど、具体的な成果が示されています。Amazon Q Developerは、コードの生成、Unit Test作成、ドキュメント作成、コードレビューなどを自動化するagentsを提供し、開発者が本質的な開発作業に集中できる環境を実現します。特に新しく発表されたGitLab Duoとの連携により、GitLab上で直接これらの機能を利用できるようになりました。Amazon Q Developer agentsは開発者の代替ではなく、開発者を支援するツールとして位置づけられており、具体的な指標に基づいて効果を測定しながら導入を進めることが推奨されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon Q Developer agentsによる開発効率化の概要
こんにちは。本日はご参加いただきありがとうございます。開発者は、最新のプログラミング言語やフレームワーク、ツールに常に追従しながら、限られた期間内で高品質で機能豊富なアプリケーションを提供することが求められています。コードの作成、デバッグ、テスト、デプロイ、オンコール対応など、複数のタスクを並行して進めながら、チームメイトとも協力して作業を行う必要があります。これにより、認知的な負荷が高まり、異なるタスク間の切り替えにも大きなコストがかかってしまいます。
本日は、Amazon Q Developer agentsが、これらの付随的な作業を軽減し、ソフトウェア開発のより重要で本質的な側面に集中できるようにすることで、より迅速な開発をサポートする方法についてご紹介します。私はAmazon QのプリンシパルプロダクトマネージャーのDoug Clausonです。本日は、DTCCのHead of Technology, Research and InnovationのDr. Johanna Powell、そしてAmazon QのSenior Manager, ProductのManikandan Srinivasanにもご参加いただいています。
まず私からQの概要をご説明し、その後Dr. PowellがDTCCでの導入事例と、これらのagentsが彼らの業務にどのように活用されているかについてお話しします。その後、私から再度、agentsに関する私たちのビジョンと、それらがどのように皆様の開発スピードを向上させるのかについてお話しし、さらに現在リリースしているagentsの1つのアーキテクチャについてもご紹介します。
DTCCにおけるAmazon Q Developerの導入事例
Amazon Q Developerは、ソフトウェア開発のための生成AIパワードアシスタントです。 Q Developerは、Software Development Life Cycle（SDLC）全体にわたる機能を提供しており、アプリケーションの構築をより迅速に行うだけでなく、運用や保守もサポートします。Q Developerはインラインコメントからリアルタイムの提案を生成することができ、多くのお客様がAmazon Qを活用して開発効率を大幅に向上させています。しかし、Amazon Q Developerはインライン補完やチャットだけにとどまりません。私たちは既に、複数のステップにわたるタスクを支援する専門的なagentsもリリースしています。
では、agentsの詳細に入る前に、まずDr. PowellからDTCCでの導入事例についてお話を伺いたいと思います。Dr. Powell、お願いいたします。ありがとうございます、Doug。皆様、聞こえていますでしょうか？ 素晴らしい。 まず最初に質問させていただきたいと思います。本日は様々な企業から多様な方々にご参加いただいていますが、DTCCについてご存知の方はどのくらいいらっしゃいますか？
DTCCについてあまりご存知ない方も多いと思いますので、少しご説明させていただきます。私たちは米国の中央証券預託機関であり、基本的に米国の証券取引の大部分の処理と清算を行っています。昨年は3兆ドル規模の証券取引を処理しました。Fixed Income（債券）取引だけでも1日あたり6兆ドル、つまり1時間あたり2,500億ドルもの取引を処理しています。これは非常に大きな責任を伴う業務です。
DTCCは、世界で最も厳しい金融規制を受ける企業の一つと言えますので、当然ながらセキュリティ、スケーラビリティ、パフォーマンス、そしてレジリエンシーを非常に重視しています。そのため、「早く進めて、壊れても構わない」というアプローチは、私たちにとって絶対に選択肢にはなりません。ご想像の通り、リスク軽減は私たちの中核的な戦略の柱であり、AIに関する戦略の柱としても常に最優先事項となります。しかし、それに加えて、顧客体験の変革や生産性の最適化、さらにはAI研究開発の推進など、Generative AIの活用に関して他にも多くの目標があります。
DTCCでのAmazon Q Developer導入プロセスと評価
1年前、DTCC全体の同僚たちが取り組みたいと考えるGenerative AIのユースケースを約400件リストアップしました。これらのユースケースの中で、開発者の生産性向上は特に高いスコアを獲得しました。これは主に実現可能性が高く、DTCCへの潜在的なインパクトも大きいと評価されたためです。私たちの目標は、開発者の効率性を大幅に改善し、生産性の向上を実現できるかどうかを、開発者向け生産性ツールを使って検証することでした。
当時直面していた課題は、2024年1月時点で、新しい開発者向けツールが次々とリリースされている状況でした。取締役会や執行委員会のメンバーの中には、これらのツールが期待されるROIを本当に実現できるのか確信が持てない人々がいました。これは、初期の結果を見る限り、もっともな懸念でした。また、このような新しいテクノロジーを私たちのテクノロジースタックに導入するリスクに見合うだけのメリットが得られるかどうかについても、確信が持てない状況でした。そこで私たちは、3つの点を証明する必要がありました。
1つ目は、データに基づく測定可能なKPIを確立できることです。さらに、新しいツールの結果を、入手が困難だった過去の堅実なベースラインデータと比較して測定する必要がありました。また、成功を示す統計的に有意な証拠を示す必要もありました。加えて、DTCCに導入されるツールが、プライバシーとセキュリティに関して特に厳格な非機能要件を満たすことを実証する必要がありました。
私たちは、Pair Programmingツールが生成的コードの生産性を向上させることができるかどうかに焦点を当てたテーマと課題設定を定義することで、パイロットのパラメータを設定しました。開発の迅速化、コード品質の向上、生産性の向上、イノベーションの促進、そしてコラボレーションの強化を含む、測定可能なパイロット目標を設定しました。取り組みを開始する前に、包括的なツール評価を実施しました。市場の競合製品の中からAmazon Q Developerを選択した主な理由は、最も重要な要件をすべて満たしていたからです。
Amazon Qはセキュリティとプライバシーの考慮事項において最高評価を獲得しました。機能、プログラミング言語、リポジトリのサポートに関するすべての要件を満たし、コードリポジトリでのトレーニングのカスタマイズ要件を満たし、特にDTCCに関連性の高いJava変換などの革新的な機能を備えていました。これが、様々なツールを評価するために使用した高レベルのフレームワークです。各開発者ツールについて、機能要件、非機能要件、市場差別化要因という3つの主要カテゴリーにわたってDTCCの要件が満たされているかを確認するため、複数のパラメータを評価しました。
評価した主要な機能要件には、サポートされている機能とフィーチャーの種類、対応プログラミング言語、リポジトリの互換性、統合開発環境の互換性、そしてモダリティやコーディングガイドラインが含まれていました。非機能要件については、デプロイメントオプションやセキュリティ・プライバシー要件（テレメトリーデータの制御、コードが第三者と共有されないことの保証、コード提案のトレーサビリティなど）を検討しました。また、前述の市場差別化要因についても評価を行いました。
DTCCパイロットの成果と開発者の反応
DTCCのスクワッド、言語、IDEを包括的にサンプリングできるようパイロットを設計しました。5つのプログラミング言語と、4つの主要IDEのうち2つが対象となりました。アプリケーションの多様性を考慮して選ばれた4つのチームの30名以上の開発者にAmazon Q Developerが提供され、参加者は17週間（3〜5スプリントに相当）にわたってツールを使用しました。
参加者とリーダーの心と意識を掴むことが重要でした。パイロットの成功を確実にするため、いくつかの重要な側面に焦点を当てました。進行中のプロジェクトの加速、開発者体験の向上、DTCCでの新技術利用における先駆者としての利点など、パイロットの潜在的なメリットをチームに納得してもらいました。ツールに関する十分なトレーニングを提供し、成功の測定基準となるベースラインを確立するため、参加チームから豊富な履歴データを収集することを約束しました。このパイロットが日常業務を妨げることはなく、ツールの使用頻度が高まるほどその利点をより実感できるということをチームに強調しました。
成功を測定するために、効率性、品質、体験という3つの主要カテゴリーで基準を設定しました。効率性の面では、スループット、Pull Request、ビルド失敗率を測定しました。品質については、コードの脆弱性、バグ、テストカバレッジを追跡しました。体験の評価については、開発者の満足度を評価するための定性的な調査を活用しました。開発者の満足度と生産性の認識を評価するために、既存のツールを使用してデータを収集することができました。
パイロットは私たちと開発者チームの双方にとって非常に成功的で刺激的なものでした。参加者1人あたりのスループットが平均40%向上し、これは以前であれば開発者が10時間かかっていたタスクが6時間で完了できるようになったことを意味します。コードリポジトリとスコープ全体で、コード品質と成熟度評価が向上し、一方でビルド失敗率とテストカバレッジは安定を維持しました。さらに、コード欠陥が平均30%減少したことも確認されました。
取締役会と執行委員会は、私たちの調査結果における統計的有意性の必要性を強調しました。このチャートは、パイロット期間とベースライン期間における参加者のスループットの平均的な差を示しています。緑のプロットは通常のビジネス状態を表しており、帰無仮説または効果なしの条件下で実験を何度も実行した場合に観察されるであろうベースラインとパイロット間のスループットの差を示しています。オレンジのプロットは、パイロット中に観察された指標に基づいて観察される可能性が高い差の分布を示しています。T検定の測定により、パイロットとベースラインの分布間の平均の差は統計的に有意であり、標準偏差の半分の差があることが示されました。これにより、Amazon Q Developerがスループットに対して高い統計的信頼度で正の効果を持つことが確認されました。
次に、Code Quality Maturity Assessment（CQMA）を測定しましたが、これはAmazon Q Developerで安定を保っていました。右上のチャートは、エンタープライズCQMAスコアの平均を示しています。2024年第1四半期にツールを導入し（両方のチャートで青い線で示されています）、導入後、平均CQMAは約5パーセントポイント上昇しました。CQMAは3つの指標で測定されます：自動テストカバレッジの範囲を評価するコードカバレッジ品質、コードの構造的複雑さを評価するコード複雑性、そしてコードで使用されているオープンソースコンポーネントのセキュリティを確認するコードセキュリティフリーおよびオープンソースソフトウェアです。
また、ビルド失敗率とコードカバレッジも評価しましたが、どちらも開発ツールの影響を受けることなく正常範囲内にとどまりました。ビルド失敗率は、コード統合とテストにおける問題の頻度を示し、コード品質の指標として機能します。これらの指標には、コードの構文、内部ロジック、欠落した依存関係、タイプミスのチェックが含まれます。パイロット中に見られた変動は統計的に有意ではなく、Amazon Q Developerがビルド失敗に影響を与えないという結論に至りました。緑色で表示されている大きな変動は、開発ツールとは無関係のITP Settlement Instruction Managerの異常によるものでした。右下のチャートに示されているコードカバレッジは、自動テストがコードベースをカバーしている範囲を測定し、より多くのテスト済みコードが高品質なソフトウェアにつながることを確認します。パイロット中のコードカバレッジの変動も有意ではありませんでした。
パイロット参加者からの定性的なフィードバックでは、Amazon Q Developerを十分に活用した開発チームから大きな称賛を得ました。これらの開発チームは、複雑なコードの理解、Unit Testの作成、リファクタリングにおいて日々課題に直面していましたが、使い続けるにつれてこのツールへの愛着が深まっていきました。開発者たちは特に、Amazon Q Developerがコードブロックをわかりやすい言葉で説明する能力を高く評価し、レガシー環境の理解と作業が容易になったと述べています。
ある開発者は「Qは私の人生を変えた」とまで言っています。このツールが開発者の生活をより楽にする能力は明らかでした。コードのリファクタリングをサポートする機能は、ストーリーポイントには記録されず、スループット評価には現れませんでしたが、非常に価値のある機能として挙げられました。数字だけの話ではなく、開発者のワークフローを改善することが重要だったのです。別の開発者は「Qはコードのリファクタリングとユニットテストに役立ち、さらなる可能性を探りたい」とコメントしています。
Amazon Q DeveloperのQ&Aチャット機能は非常に価値があることが証明され、自己学習を可能にし、シニア開発者への負担を軽減し、継続的な改善の文化を育むことができました。「Qによって、経験豊富なエンジニアへの依存がなくなった」というフィードバックもあり、これはジュニアもシニアも両方の開発者の時間を節約することができました。Pythonチームは特に、インラインコード生成機能に価値を見出しました。一部のチームはレガシーコードベースの他の場所にあるコードのコンテキストへの依存により課題に直面しましたが、より単純なタスクは十分に対応可能でした。別の開発者は「問題を理解し解決するのにかかる時間が短縮された」とコメントしています。
Amazon Q Developer agentsのビジョンと機能
将来を見据えると、改善が必要な点は多々ありますが、開発者たちはすでに多くのポジティブな効果を実感しています。プロジェクトレベルのコンテキスト化により、ツールの価値はさらに高まり、より強力なものとなるでしょう。開発者のイノベーションと卓越性を確保するために人間が介在する開発は依然として不可欠であり、この取り組みはここで終わりではありません。 実際のROIを示すために、私たちはデータに基づいていくつかの控えめな仮定を立てました。開発者1人あたり約2,000時間の労働時間のうち、約50%がコーディングに費やされると仮定しました。パイロットのスループット評価で見られた40%ではなく、控えめに10〜20%の生産性向上と見積もりました。そこから、年間のFTEコストから開発者1人あたりの年間Amazon Q Developerコストを差し引いて、開発者1人あたりの年間純価値を算出しました。
これを1,500人の開発者という大規模な母集団に当てはめると、年間約150,000〜300,000時間の追加生産性時間の増加に相当します。これはQ&A機能とインラインコード生成だけで達成されたものなので、Amazon Q Developerが新機能をリリースするにつれて、この見積もりはさらに増加する可能性があります。最終的に、価値提案は明確であり、開発者全体へのツールの展開について完全な承認を得ることができました。
DTCCでは、2025年に向けて、特にAgentic Frameworksと様々な課題への対応について非常に期待を寄せています。効率化が見込まれる分野の中には、DTCCにとって非常に重要なJava 8からJava 17へのバージョンアップグレードがあります。また、Unit Testの生成も興味深い分野です。包括的なUnit Testの作成は不可欠ですが、非常に労力を要する作業です。コードの理解や、緻密な注意を要する技術仕様書やリリースノートの文書化も重点分野です。最後に、コードレビュー、特にコードの脆弱性のスキャンや、古いライブラリの特定とアップグレードが重要です。これらの課題に対するAWSのAgentの取り組みについては、後ほど詳しくお話しします。私たちの仮説では、これらの分野にAI Agentを導入することで、開発プロセスを加速させるだけでなく、コードベース全体の品質とセキュリティも向上すると考えています。
この素晴らしい取り組みにご参加いただき、ありがとうございます。これは素晴らしい journey であり、AWSは素晴らしいパートナーでした。では、AI Agentsについてより詳しく説明してくれるDougに引き継ぎたいと思います。
ありがとう、Johanna。DTCCのAdoptionの journey を見るのは本当に興味深いですね。お客様からよく、ROIの計算方法や、期待する効果が得られているかどうかの確認方法について質問を受けます。Dr. Johannaらしく、DTCCは非常に科学的なアプローチでこの問題に取り組みました。ベースラインを設定し、それと比較して、データに基づいて意思決定を行いました。 彼らはAgentsの活用をまさに始めたところですが、これは私たちがお客様の間でよく見る典型的なAdoptionパターンです。まずはChatやインラインコンプリーションのような高接触な機能から始めて、Qの動作に自信を持ってから、Agent機能のような、より高度な機能の探索を始めます。Agentsが彼らをどこに導いていくのか、とても楽しみです。
Amazon Q Developer agentsの新機能デモ：Unit Test生成とドキュメント作成
re:Inventで発表したばかりのAgentsについて詳しく説明する前に、まず、私たちがQ Agentsの将来をどのように考えているかについてお話ししたいと思います。現在、業界では AgentsやAgentic Capabilitiesについて多くの議論がありますが、これはGenerative AIに関するプレゼンテーションなので、Claude 3.5 SonnetからAI Agentの定義を引用させていただきます：「Agentとは、入力データを通じて環境を認識し、何らかの意思決定モデルやロジックを通じて判断を下し、設計された目標や目的を達成するために行動するソフトウェアプログラムまたはシステムです。」私たちはここにもう一つ付け加えたいと思います - それは、Agentsは自身の行動から学習するということです。
ソフトウェア以外の例を使って、これらのAgentsがどのように機能するかについてお話ししましょう。re:Inventに参加している私たちのほとんどはホテルに滞在していますが、ホテルを予約する際、希望する日程とルームタイプを選択し、システムが環境（この場合はホテルの空室状況）を確認して、オプションのリストを返してきました。その後、最も安い部屋を選ぶか、あるいは少し高くてもThe Venetianに近い部屋を選ぶかを決めて、希望のオプションを選択して予約を行いました。
しかし、ご存知の通り、環境は時間とともに変化します。ホテルの需要と供給が変動するため、The Venetianにより近い、より良いホテルでより良い料金を見つけられる可能性があります。私自身も何度か経験しましたが、より良い条件を求めて何度も部屋を探し直すことがあるでしょう。ここで、エージェントに目標を与えるケースを想像してみてください：The Venetianから徒歩15分以内の最安値のオプションを探してほしい、Hiltonホテルが好き、キングサイズベッドが希望、1泊300ドルまでなら支払える、それ以外のオプションは手動で承認したい、というような条件です。
このケースでは、エージェントは目標を理解し、環境を把握し、助けが必要な時期を認識し、あなたの要望について判断して決定を下すことができます。エージェントを起動すると、最適なオプションを見つけてくれます。環境が時間とともに変化する中で、エージェントはキャンセル期限が来るまでの間、あなたが何もする必要なく、より良い条件で何度も予約し直してくれる可能性があります。そして最終的に、re:Inventでの宿泊部屋が確保できるというわけです。また、このエージェントを使い続けるほど、あなたの行動パターンから学習し、希望する条件で希望する価格の部屋を見つけることが上手くなっていきます。
このように、ソフトウェアエージェントは、明確な目標や目的を持ち、推論や判断を行う能力があり、環境を理解するという、非常に似たようなパターンで動作することがわかります。では、Amazon Q内のエージェントに関する私たちのビジョンについてご説明しましょう。まずは環境から始めましょう。 エージェントが感知し相互作用する環境について話す際、私たちはソフトウェア開発プロセス全体とそれを取り巻くすべてのものを指しています。中核として、 この環境には、エージェントがプロジェクトのソースコードとコミット履歴にアクセスできるコードリポジトリが含まれます。これにより、エージェントはコードベースを理解し、改善の可能性がある領域を特定し、さらには変更や最適化を提案することができます。
しかし、環境はコードだけにとどまりません。プロジェクト管理ツールや課題管理システム、ドキュメントも含まれます。これによりエージェントは、追求すべきタスクや目標を把握し、要件やユーザーストーリー、そしてそれらのタスクや目標を取り巻く文脈を理解することができます。 エージェントはまた、CI/CDパイプラインの状況も把握できるため、ビルドプロセス、テスト結果、デプロイメントの状態を監視することができます。この可視性により、何か問題が発生した場合、エージェントはそれを検知し、プロセスの問題箇所を修正することができます。
このライフサイクル全体にわたる外部データソース、例えば業界のベストプラクティスやコーディング規約、セキュリティガイドラインなども環境の一部となっており、エージェントが出力を既存の基準と照らし合わせ、コンプライアンス要件を確実に満たすことができます。また、環境にはアプリケーションとインフラストラクチャ自体も含まれます。エージェントはアプリケーションのパフォーマンス、スケーラビリティ、健全性を把握することができます。CloudWatchのようなサービスからメトリクスを取り込むことができるのです。
レイテンシーやエラー率に関する洞察を得ることで、ボトルネックを特定し、問題が発生する前に予測することが可能になります。例えば、Agentがレイテンシーの急増を検知し、自動的に既知の安全なバージョンにロールバックすることができます。緊急の問題に対処した後、Agentは問題のあったデプロイメントを特定し、そのデプロイメントに含まれていたコミットを確認し、さらにソフトウェア開発に特化した別のAgentに更新とデプロイの修正を依頼することができます。環境とは、Agentがナレッジベースの一部として、あるいは変更を加えるフィードバックメカニズムとして使用するものの集合体です。
これまで説明してきたように、AgentはこのEnvironmentに対して操作を行います。 ここで強調したいのは、Amazon Qは現在、チャット機能を通じてEnvironmentにアクセスできるということです。AWSリソースやコードについてチャットできますが、チャットが全ての問題に対して最適なモダリティとは限りません。特にAgentが役立つような、タスクやゴール指向の強い問題の場合はそうです。ここでAgentの出番となり、より迅速な構築とデプロイを支援します。Agentは追加の自動化と自動的なコース修正を提供します - 単にAgentにタスクを割り当て、作業させるだけです。例えば、アプリケーションに新機能を追加しようとする場合、Amazon Qとその変更についてチャットし、自分で変更を加え、ビルドし、テストし、デプロイすることもできます。あるいはAgentを使用すれば、Agentが代わりに作業を行い、書き込み、ビルド、テスト、デプロイを実行し、解決策を提供してくれます。
Agent自体の内部では、4つの明確なステップを踏んでいます。まず、Environmentを感知し、継続的にモニタリングして情報を収集します。このステップでは、Environmentの現在の状態を認識・理解し、Environment全般について知識を持つことが含まれます。次に、Agentは特定のゴールやタスクを念頭に置いて行動し、Environmentから感知した情報に基づいて、そのゴールを達成またはタスクを解決するための適切なアクションを決定します。これらのアクションには、コードの生成からリファクタリングの提案、実行中のアプリケーションのアーキテクチャ変更の提案まで、様々な形態があり得ます。
Agentが選択したアクションを実行すると、次のステップとして、そのアクションがEnvironmentに与えた効果を観察します。このステップには、コード品質メトリクス、テスト結果、パフォーマンス指標、あるいはEnvironment内に存在する他の関連フィードバックメカニズムのモニタリングが含まれる可能性があります。Agentは、実行したアクションが望ましい効果をもたらしたか、あるいは追加の変更が必要かを評価します。最後に、Agentはアクションの観察された効果から継続的に学習します。意思決定プロセスを改善し、ナレッジベースを更新し、実際の結果に基づいて行動を適応させていきます。この学習ループにより、Agentは継続的に改善し、特定のコンテキストやプロジェクトに合わせて変更を調整していきます。
学習こそが、他のモダリティと比較してこれらのAgentを際立たせる特徴です。この4ステップのサイクルは無限ループとして機能し、Agentは継続的に感知、行動、観察、学習を行い、本質的にAgentにとっての最適化問題となります。単一のAgentでも十分に役立ちますが、私たちが特に期待しているのは、開発者と共に共通のゴールに向かって協力する複数のAgentの連携です。 それがここに描かれています。開発者と共に共通のゴールに向かって働く専門化されたAgentがいます。一部のAgentは顧客フィードバックを分析して要件の収集と分析に焦点を当て、他のAgentにそのフィードバックへの対応を指示します。コーディングを担当するAgentはコードを生成し、同時にそれらをナレッジベースと照合してコーディング標準が満たされていることを確認します。
これは開発フェーズを超えて運用フェーズにまで及び、アプリケーションの運用・保守を専門とするAgentが、問題が発生した際の原因特定や修正を支援します。これらのAgentは半自律的または完全自律的に動作します。現在は主に半自律モードで動作しており、その場合Agentはペアプログラマーのような役割を果たします。例えば、UXの作業をしている際、Agentが3〜4種類の異なるデザインを提案し、その中から私が望むものを選択できます。一方、完全自律型のAgentは異なり、目標を理解した上で独自に作業を進めます。
コードレビュー自動化とGitLab Duoとの統合
基盤となる技術が急速に進歩を続けているため、このAgentを活用した未来は現実に近づいていると考えています。 このビジョンのもと、今年初めに最初の2つのAmazon Q Developer Agentを正式にリリースしました。1つ目のAgentはコード変換用で、アプリケーションをJava 8または11からバージョン17へとシームレスにアップグレードすることができます。これは先ほどJohannaが言及して興奮していた機能です。Amazonでは、Javaを広範に使用しており、いたるところで活用されています。このAgentを使用して、すでに数万の本番アプリケーションを移行しており、開発時間を何年も節約し、年間数百万ドル相当のパフォーマンス改善を実現できると見積もっています。
また、アプリケーションの構築フェーズを支援するAgentもリリースしました。問題文の自然言語入力とプロジェクトのコンテキストを使用して、このAgentは複数のファイルにまたがる機能実装やバグ修正を自律的に行います。お客様の中には、このAgentを使用してビジネス要件書を完全に動作するアプリケーションに変換したり、APIを更新したり、Webサイトを作成したりするなど、興味深い活用事例が見られています。
ここからは、このAgentの動作の詳細について説明していきます。 先ほどのビジョンで示した図と似たものに戻りましょう。今回は、現在のソフトウェアAgentの具体的な動作について説明します。現在、このAgentはソースコードリポジトリをコンテキストとして使用し、それを観察して操作を行います。ユーザーが自然言語で問題文を入力することから始まり、 Agentは作業を進めながら、その行動の説明をユーザーに提供します。
現在のAgent内部では、開発者のように動作しますが、 マシン間のやり取りに近いテキストベースのIDEを使用します。まず、ツールを選択します - 現在のAgentには、ファイルの探索、検索、修正、追加・削除、または以前の変更を元に戻すためのツールが装備されています。ツールを選択した後、環境に対してそのツールを使用し、出力を観察します。Agentは、元の問題の解決策に到達したと判断するまで、このループを繰り返します。解決策に到達すると、更新されたコードをユーザーのレビュー用に返し、ループを終了します。
現在のエージェントは学習機能を備えていませんが、私たちはその実現に向けて最適な方法を模索しています。また、エージェントのツールボックスにさらなる機能を追加し、問題解決能力を高め、環境から活用できるリソースの種類を拡張しています。これらの取り組みの成果は非常に有望で、Amazon Q Developer agentは現在もSWE-benchの検証済みベンチマークで1位を維持しており、約55%の問題を自力で解決できています。
それでは、このDevelopment agentがどのように機能するのか、簡単なデモをお見せしましょう。ここに投票アプリケーションがあります。これはシンプルなAPIエンドポイントを持ち、レストランに対するエンドポイントにアクセスすると、DynamoDBのカウンターがインクリメントされます。Outback、IHOP、そして子供のお気に入りのChipotleがあります。実行して動作を確認してみましょう。ここでChipotleのエンドポイントに何回かアクセスすると、カウンターが増えていくのが分かります。とてもシンプルで、DynamoDBのカウントをインクリメントするだけです。また、利用可能なAPIの一覧と、非常に基本的なget votes関数があり、各レストランの得票数を表示できます。
現在フロントエンドがないので、それを追加して、ユーザーが投票できるようにしたいと思います。これにはAmazon Q Developer agentを使用します。Qチャットに入り、チャットボックスに/devと入力し、/votesに新しいルートを作成するようお願いします。パスワードで保護されたページを作成し、レストラン、現在の投票数、そしてそれらのレストランに投票する方法を表形式で表示したいと思います。この部分は早送りしますが、約2分かかり、その間リアルタイムで更新が行われました。ここでapp.pyをレビューし、使用する新しいテンプレートを作成し、アプリに変更を加えたことが分かります。
ここに認証用の新しい関数があります。もちろん、これはもっとセキュアにできますが、現在は管理者パスワードが有名な「admin」に設定されています。あるいは、このアプリの他の箇所でも行っているように、環境変数から取得します。全ての投票を取得する関数を作成し、エラーチェックも含めて/votesに新しいルートを作成しました。ここで、votes HTMLテンプレートを確認する代わりに、変更を受け入れてローカルのIDEに反映させ、もう一度実行して確認してみましょう。
これで/votesページにアクセスできるはずです。adminとadminでログインします - 誰にも言わないでくださいね。そして、要求通りのテーブルが表示されています。レストランのテーブルがあり、現在の投票数があり、それぞれに投票するためのアクションがあります。もしこれが気に入らなければ、エージェントと対話を重ねて、気に入らない点を伝えることができます。たとえば、要件を忘れていたかもしれません。一人一回しか投票できないようにしたかったかもしれません。そのような制限を指定すれば、エージェントは再度コードを修正してくれます。
私自身でこれらの変更を行い、十分だと判断すれば、自分で完了させることもできます。これが、ソフトウェア開発のためのQ Developer agentです。先ほど説明したように、Qチャット内で/devを使用することで起動できます。それでは、昨日のre:Inventで発表した新しいagentのリリースについて、Maniに説明を譲りたいと思います。
ありがとうございます。Dougの説明は非常に興味深いものでしたね。それでは、Amazon Q Developer agentの今後についてお話ししましょう。昨日のre:Inventでは、Amazon Q Developer内のソフトウェア開発agent関連で3つの新機能を発表しました。最初にご紹介したいのは、Unit Test生成を自動化するAmazon Q Developerです。お客様や開発者から頻繁にいただくフィードバックの一つとして、特定の問題に対処したり、機能強化や新機能を作成した後、次のステップとしてUnit Testを書く必要があるという点があります。Unit Testの作成が時間のかかる面倒な作業であることは誰もが知っていますが、同時にその重要性も認識しています。この課題を解決するため、Q Developer agent automate unit testsの提供を発表できることを大変嬉しく思います。先ほどDougが示した/devと同様に、このツールは/testというコマンドで起動します。
この機能により、Unit Test作成に関する開発者の時間と労力を大幅に削減できると考えています。また、より良いUnit Testカバレッジによって、実際にリリースするコードの信頼性も向上します。それでは、実際のデモをご覧ください。ここでは、先ほどDougが使用したのと同じアプリケーションを使用します。ただし、/devの代わりに/testコマンドを使用します。ここで、「getBooksファンクションのUnit Testを生成して」という自然言語のプロンプトを入力します。
これは通常、開発者が手動で行う必要がある作業です。しかし、この作業をAmazon Q Developerに任せることができます。Q Developerは、あなたが何をしようとしているのかを理解し、この場合はapp.pyのgetwordsのUnit Testを生成すると判断し、必要なUnit Testを生成するための処理を開始します。数分以内にUnit Testが自動生成され、開発者はview diffをクリックできます。このプロジェクトにUnit Testファイルが既に存在する場合は、既存のファイルに追加され、存在しない場合は、新しいTestファイルが作成されます。正しいレストランを渡した場合や、無効なレストランを渡した場合など、必要な全ての正常系・異常系のテストケースが、あなたが何もすることなく完全に自動化されます。
素晴らしいですよね？これが最初の機能です。次に発表する2つ目のagentは、ドキュメント作成を自動化するAmazon Q Developerです。/devと/testを使用してコードを作成し、Unit Testを書いた後、開発者が次にやらなければならない大好きな作業は何でしょうか？そう、ドキュメントの作成です。これもAmazon Q Developerで解決できます。このツールはドキュメントを自動生成します。ここで言うドキュメントとは、READMEの生成や更新のことです。ドキュメント作成のプロセス全体を自動化します。
これにより、開発者が手作業で行っていたすべてのワークフローを自動化できると考えています。Amazon Q Developer agentのドキュメント機能が、これを自動的に効率化してくれます。それでは、その仕組みのデモをご覧ください。ワークフローは同じで、/devや/testの代わりに/docを使用します。ここでオプションが表示され、ユーザーにガイドを提供します。新しいREADMEを作成するか、既存のREADMEを更新するかを選択できます。今回はデモのために、新しいREADMEの作成をお願いしてみましょう。すると、/testの時と同様に、プロジェクト構造を理解し、どのような変更が加えられたかを把握します。これは新規プロジェクトの作成時でも、既存プロジェクトの更新時でも適用できます。すべてのコンテキストを理解し、私たちが「リップルマップ」と呼ぶものを作成します。リップルマップとは、ソースコードがどのように構築されているかを示す論理的なエンティティを持つ骨格のようなものです。このリップルマップを理解することが、ドキュメント生成において非常に重要です。ご覧の通り、数分でREADMEが生成され、開発者として私はこれを承認しようと思います。
本来はそうすべきではないのですが、変更を承認してみましょう。すると、生成されたドキュメントがこのように表示されます。これはAWS App RunnerとDynamoDBを使用したレストラン投票アプリケーションです。このアプリケーションがレストラン機能の投票システムを実装していることについての説明があり、リポジトリ構造、アプリケーションの使用方法、設定、APIエンドポイントなどの詳細情報も含まれています。さらに、アーキテクチャがどのようなものになるかを説明するデータフロー図も作成してくれます。開発者として、この変更を承認することもできますし、更新が必要な場合は、例えばAPI部分についてより多くのサンプルが欲しい場合、Q Developerに指示してAPIのドキュメントを追加作成してもらうこともできます。構造を自動的に理解して、ドキュメントを生成してくれます。これにより、開発者の時間を大幅に節約できると確信しています。
最後にお話ししたいAgentic機能は、コードレビューの自動化です。ドキュメントを作成した後、開発者が次に行うのはコードレビューの提出です。開発者なら誰もが知っているように、コードレビューには時間がかかり、やり取りが多くなります。コード作成者としては、コードを提出し、レビュアーから「これら10個の点を適切に修正すべき」という指摘を待ち、開発者として戻って修正し、再提出する...というループが延々と続きます。コードをコミットする前に、このコードレビューのプロセスを自動化する機能があったらどうでしょうか？私たちはまさにそれを実現しました。
コードを提出する前に問題を検出する自動コードレビューのAgentic機能の発表を嬉しく思います。SaaSの問題、SCAの問題、あるいはサブオプティマルなコードを書いていないか、不適切なデータ構造を選んでいないか、関数の重複がないかといったコード品質の問題など、すべてを検出します。Q Developer内からボタン一つでコードの修正を生成することもできます。これにより多くの時間を節約でき、コードレビューのプロセスに提出するコードが、すでに高品質であることを確認できます。
その仕組みを見てみましょう。ご覧の通り、テーマは同じで、ここでは/reviewを使用します。この場合、作業中のワークスペース全体のコードレビューを行うか、現在編集中の特定のファイルに対してレビューを行うかなど、複数のオプションがあります。このワークフローでは、同様にコードを確認し、コード内の問題を検出します。左側に、重要度に基づいて問題が表示され始めるのが分かります。開発者として、特定の問題を選択して右側で詳細を確認できます。ご覧の通り、コード修正の生成をクリックすると、コードが生成され、それを承認することができます。この特定の変更は、不適切なリソース公開に関するもので、セキュリティ保護のためにIPを変更するよう求めています。
こちらは不適切なエラーハンドリングの別の例です。ここでは、その機能の異なる特徴をご紹介したいと思います。この場合、エラーハンドリングが全く実装されていません。そこで開発者として、「コードの修正を生成して」とお願いすることができます。すると、コミットしようとしているコードに対して、try-catchと例外処理を追加し、適切な安全対策を施してくれます。同様の例として、CloudFormationテンプレートを使用している場合に、適切なCloudWatchアラームが設定されているか確認し、「アクションが設定されていませんが、アクションを作成しましょうか？」と提案してくれます。
パッケージの脆弱性が検出された場合、それを特定して解決方法を教えてくれます。開発者が手作業で行っていた試行錯誤や、Q Developerが検出した脆弱性に対するコードの作成方法を考える手間を大幅に削減できます - これらの問題を自動的に修正してくれるのです。これらのエージェント機能をリリースする中で、お客様からいただいたもう一つのフィードバックは、なお、私がデモでお見せしたのはすべてIDEでの操作でしたが、「これらの機能をDevSecOpsプラットフォーム内でも利用できるようにしてほしい」というものでした。そこで、GitLab DuoとAmazon Qのプレビュー版の発表を嬉しくお知らせします。Dougが説明した/dev、/transform、/test、/reviewなどのエージェントワークフローのすべての機能が、GitLabインターフェース内で直接利用できるようになります。開発者は必要な作業を確認し、必要な修正を行うことができます。
これはSelf ManagedとUltimateサブスクリプション層で利用可能です。
こちらがGitLabインターフェースで、新しいIssueを作成してみましょう。アサインを行いますが、開発者ではなくAmazon Qにアサインします。この場合、エージェント型ソフトウェア開発機能であるAmazon Q Devに対して、作成したIssueに必要なコードを生成するよう指示します。同様の機能を使用して、環境を分析し、やりたいことを理解した上で、GitLab内から直接、私のWebサイトに新しいサインアップワークフローを追加します。開発者は複数の場所を行き来する必要がありません。
環境を分析し、解決すべき課題に必要なコードやアーティファクトをすべて生成します。開発者はこのインターフェースから直接Qとやり取りを始めることができます。この例では、Qにより多くのロギングを追加するよう依頼し、Q Devにアサインします。予想通り、必要なロギング構造を含むコードを生成し、マージ準備の整ったコードを作成してくれます。
私たちはこの機能に大変興奮しています。複数のお客様にプレビューを行い、皆さまから素晴らしい評価をいただきました。 こちらは、GitLab内でMerge requestの一部としてCode reviewを行う別の例です。 このインターフェース内で直接Code reviewを実施できます。シニア開発者がCode reviewを行う代わりに、Qが最初のレビュアーとなると考えてください。 この例では、私はQに問題点を見つけて指摘するよう依頼しました。ユーザー名をハードコードしていたところ、 PreparedStatementを使用するよう提案されました。そこで、やり方が分からないと伝えて、Qに解決策を求めました。/q fixという機能を使用すると、この特定の問題を解決するコードが生成されます。ユーザー名とユーザーIDのハードコーディングの代わりに、パラメータ化されたステートメントを使用して問題を解決しています。
Amazon Q Developer agentsの活用ベストプラクティスと今後の展望
ご覧の通り、開発者がQやエージェントと対話するのは非常に簡単です。IDEを使用する場合でも、GitLabインターフェース内でも、 先ほどお話しした機能をすべて利用できます。さて、今回リリースしたエージェントについて説明してきましたが、 ここでこれらのエージェントがどのように連携するのかについて少しお話ししたいと思います。私は同僚によく、これらはLEGOブロックのようなものだと説明しています。これらのLEGOブロックは、先ほどデモでお見せしたように、/dev、/test、/transform、/reviewなど、特定の問題を解決するための個別のコンポーネントとして呼び出すことができます。
私たちの考えでは、これらのエージェントは効果的に相互にコミュニケーションを取り、協力し合います。例えば、アプリケーションの作成というタスクを開発者に割り当てる場合を考えてみましょう。Qに割り当てると、Qがコードを生成します。次に、開発者があまり好まないUnit testの作成を行います。Testエージェントを呼び出して、自動的にUnit testを作成します。その過程で、ドキュメントも作成します。エージェントは環境を理解し、ユーザーが複数のLEGOブロックと対話する必要なく、これらのタスクを自動的に実行していきます。
Q Developer Software Development Agentsとは何か、何ができるのか、そしてビジョンについてご理解いただけたと思いますので、ここでベストプラクティスをご紹介します。Johannaが言及したように、特定のユースケースから始めることが重要です。多くのチームや何百ものユースケースを一度に導入したくなる誘惑がありますが、特定のユースケースから小さく始めましょう。練習を重ねることで誰もが上手くなりますので、日々のワークフローの一部としてSoftware Development Agentsを使用するようにしてください。これにより、Q Developerエージェントが何をできるのか、そしてどのように業務をシンプルで容易にできるのかを理解することができます。
エージェントは開発者の代替ではなく、開発者を支援するためのものだということを忘れないでください。Q Developerエージェントが生成したコードは、Unit testだけでなく、すべてのテストを確実に実施し、自信を持ってコミットするようにしてください。最後に、測定、測定、そして測定です。測定なしでは、バックグラウンドで何が起きているのかを本当に理解することはできません。これは、Q Developerやエージェントを使用することでどのようなROIが得られるのかを組織が理解する上で重要です。
これらを踏まえて、いくつかの行動を呼びかけたいと思います。まだの方は、ぜひ Amazon Q Developer エクステンションをインストールしていただき、私が説明したすべてのエージェント機能を探索してみてください。そして、素晴らしいソフトウェアを一緒に作っていきましょう。質問にお答えするため、私たちは会場の端にいますので、お気軽にお声がけください。以上で、このプレゼンテーションを終わります。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion