re:Invent 2024: AWSが紹介するAmazon Q Developerによるサーバーレス開発
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Develop serverless applications with Amazon Q Developer (SVS213)
この動画では、AWS Senior Solutions ArchitectのMichelle ChismonがAmazon Q Developerの機能と活用方法について解説しています。Amazon Qは開発者向けの大規模言語モデルアシスタントで、Visual Studio CodeやJetBrains IDEsで利用可能です。DEV Agentを使うことで、コードの提案だけでなく、ファイルの作成や編集も自動で行えます。デモでは、Pythonアプリケーションの作成からSAMを使ったAWSへのデプロイまでを、コードを書かずに実現。さらに昨日リリースされた新機能を使って、READMEの自動生成やUnit Testの作成も行っています。LLMの特性上、出力結果のサニティチェックは必要ですが、開発作業を大幅に効率化できる可能性を示しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon Qの紹介：開発者の強力な味方
みなさん、こんにちは。ある日出勤してきたら、知らないプログラミング言語でアプリケーションを1日で書かなければならないと言われた状況を想像してみてください。優先度の高いタスクが山積みの中で、それを完成させなければならない - 髪が白くなってしまいそうですよね？今日は、Amazon Qについて、そしてAmazon Q Developerがどのようにしてそういったデッドラインを守り、未知のコードを書く手助けをしてくれるのかについてお話ししたいと思います。私はAWSのSenior Solutions ArchitectのMichelle Chismonです。それでは早速始めていきましょう。
これからライブデモをお見せしますので、デモの神様にお祈りして、うまくいくことを願いましょう。Amazon Qは私たちの大規模言語モデルアシスタントです。IDE上でリアルタイムに対話しながら、コードの作成やインフラの構築をサポートしてくれる会話型アシスタントです。こちらにある拡張機能の1つを使ってインストールします。私は今Visual Studio Codeを使用していますが、JetBrains IDEsもサポートしています。Amazon Qをインストールしたら、Amazon Qを検索して、とても簡単にインストールできます。そうすると、左側の下の方にQのシンボルマークが表示されます。
そのアイコンを開くと、このようなチャットインターフェースが表示されます。時々自動的にチャットが開くこともありますが、それは問題ありません。このような感じになります。Amazon Qには複数の対話方法がありますが、今日は主にこのチャットインターフェースに焦点を当てていきます。そして時間があれば、インラインコード提案などの他の対話方法もお見せしたいと思います。
このチャットインターフェースでは、Amazon Qについて質問をすることができます。例えば、LambdaやPythonアプリケーションを作成するためのステップを知りたい場合などです。すると、Amazon Qが質問に対する回答を考え始めます。そしてすぐに、 Pythonの環境設定に関する分かりやすいステップバイステップの手順が表示されます。 ベストプラクティスに従った方法で、Pythonアプリケーションの構築を始めるために使用できるコードスニペットまで提供してくれます。これは本当に便利なフィードバック機能で、何をすべきかを調べるためにGoogleを使う必要がありません。
しかし、実はQを使用するより強力な方法の1つは、エージェントを使用することです。ここでスラッシュを入力すると、Amazon Qで呼び出すことができる様々なエージェントのリストが表示されます。これまでQ for Developerを使用したことがある方は、このリストが昨日までずっと短かったことをご存じかもしれません。昨日、いくつかの新機能が追加され、このトークでそのいくつかについても触れていきたいと思います。
Amazon Q DEV Agentを使ったアプリケーション開発のライブデモ
Transform は既に一定期間提供されており、Java コードをモダナイズすることができます。Java 8 や 11 のコードをアップグレードすると、全ての変換を自動的に行い、コード変換やモダナイズのプロセスを加速させるのに役立ちます。 しかし、ここで私が最初に注目したいのは、この DEV Agent です。DEV Agent は Chat インターフェースと非常によく似ています。プロンプトを入力して何かを指示するのですが、Chat インターフェースとは少し異なります。実際に変更を加えてくれるのです。単に提案するだけでなく、ファイルへの書き込み、新規ファイルの作成、さらにはファイルの削除まで代わりに行うことができます。
つまり、チャットとの対話よりもさらにパワフルなのです。これから、何もない状態から完全に動作するアプリケーションを作るまでの過程を、どれだけ素早く行えるかお見せしましょう。Python 3.12 を使ってアプリケーションを構築し、Serverless Application Model を使って AWS にデプロイします。これについては後ほど触れます。サイコロの目を1から6の間に制限することも確認します。そうしないと少し暴走して、時には100面ダイスのようになってしまうこともあります。そして、API の背後からアクセス可能にすると指定しますが、具体的なアクセス方法は指定しません。それは Amazon Q に任せることにします。そして、そのエンドポイントにアクセスできるように、エンドポイントを作成するよう依頼します。
これで、何を行うか決定する間、このボックスが更新されていきます。ここでは本当に多くの作業が行われており、数分かかります。
ここで実際に何が起きているのか詳しく見てみましょう。Amazon Q は LLM に対して、このタスクを完了するために必要な適切なステップは何かを尋ねています。そしてそれらのステップを受け取り、「これは理にかなっているか？これは実行可能か？」と検証し、その後、各ステップを一つずつ実行して、各タスクが元のプロンプトで設定された要件を満たしているかを確認します。
ご想像の通り、これにはある程度の時間がかかるので、 大規模なコードベースでこれを行うのは避けた方がよいでしょう。かなり長い時間待つことになってしまいます。時には、何が実際に文脈として有用で、何が不要なのかを判断するために、ディレクトリ内のすべてのファイルを開く必要があります。そのため、何百ものファイルがある場合は、かなりの待ち時間が発生します。しかし、小規模で簡単なものを構築する場合には、これは素晴らしいツールです。 このボックスが更新されているのがわかると思いますが、変更を加える際に何を行っているのかを透明性を持って正確に伝えてくれ、このひとつのボックスでリアルタイムに更新されていきます。
チャットウィンドウ全体をスクロールして状況を把握し続ける必要はありません。システムは、レビューしたファイル、作成、変更、または削除したファイルの概要を表示して、何が行われているかを追跡できるようにしています。そして最終的に完了すると、ちょうどいいタイミングで下にウィンドウが表示されます。 このウィンドウには、実際に行われた変更が表示されます。この場合、2つの新しいファイルを追加することになります。まず、Pythonファイルを追加します。 そして見事なことに、1から6までのランダムな数字を生成するたった1行のコードがあります。素晴らしい、これが私たちが望んでいたものです。
次に、Infrastructure as Codeファイルがあります。 これは明らかにCloudFormationですが、SAM（Serverless Application Model）用にフォーマットされているため、通常のCloudFormationとは少し異なって見えます。AWS Lambda functionの代わりにAWS serverless functionという記述が見られます。これにより、Serverlessアプリケーションのデプロイがより簡単になります。なぜなら、特定のインフラ部分のデプロイ方法が簡素化されるからです。例えば、このLambda functionでは、個々の要素に対して別々のリソースを定義する必要なく、Lambda functionの定義に直接APIを組み込むことができます。そして、わずか17行のコードで、IAM role、API Gateway、Lambda functionをデプロイすることができます。
このように、CloudFormationよりもコンパクトでシンプルなため、私たちはSAMを愛用しています。これで問題なさそうです - デプロイしてみれば動作するかどうかわかりますが、これらの変更を承認することにします。変更を承認すると、ディレクトリを見てみると、 新しいファイルのapp.pyとtemplate.yamlが表示されています。素晴らしいですね。すべてが揃いました。SAMを使ってデプロイしましょう。最初にSAM buildを実行します。SAM buildは、ファイル内のすべてが正しく、機能していて、気にする必要のある構文エラーがないことを確認します。そして見事に、ビルドが成功したことが表示されています。
それでは、guidedメソッドを使用してデプロイを進めていきましょう。プロセスの途中でいくつかのプロンプトが表示されます。 いくつかの詳細を入力します。標準的な命名規則であるSAM appとus-east-1を使用します。 ここではデフォルト値をそのまま使用します。ロールバックを無効にする必要はありません。 ここで見ているのはデプロイメントの進行状況で、CloudFormationを使用したことがある方にはお馴染みの光景です - スタックをデプロイしています。このボックスでは、変更セットと作成されているものが表示され、その後CloudFormationの ステータス更新がコンソールで表示され、リアルタイムで更新されます。もちろん、CloudFormationなのでデプロイには数分かかることがあります。
デプロイを待っている間に、このapp.pyを簡単に見てみましょう。Amazon Qの他の 便利な機能をご紹介します。このコードの一部をハイライトして右クリックすると - 小さくて見づらいですが、Amazon Qという項目があることを信じてください。Amazon Qにスクロールすると、他にもたくさんの機能がサブメニューにあります。コードの説明を求めることができ、それをクリックするとQが開いて、そのコードが何をしているのかの説明を生成します。そのため、馴染みのないコードベースを扱っている場合でも、 コードをハイライトするだけで、そこで何が起きているのかすぐに理解することができます。
もう一度下に戻ると、RefactorとFixがあります。コードに問題があることに気付いた場合、提案をしてもらえますし、実際にファイルを編集して問題を修正することもできます。非常に便利なツールですね。さて、CloudFormationのデプロイが完了しましたので、このURLを使って呼び出してみましょう。うまくいけば、ロールバックが返ってきます。コードは正常に動作し、Infrastructure as Codeは正常に作成され、デプロイも成功しました。そして、私たちはまだ実際のコーディングを何もしていません。
Amazon Qによるドキュメント作成とテスト生成：可能性と課題
これは確かにシンプルなアプリケーションです。たった1行のコードですが、スケールアップが可能で、より複雑なコードやアプリケーションを作成して、機能をプロダクションに展開することができます。ここで、これが実際よりも複雑だと仮定してみましょう。コードを作成する際は、必ずドキュメント化が必要です。馴染みのないコードベースに出会って、ドキュメントがなかった経験のある方はどれくらいいますか？開発者として経験する最も frustrating なことの1つで、何が起きているのかを理解するのに、必要以上の時間を費やすことになります。
元々このデモでは、forward slash devを使って、コードのドキュメント化をお願いする予定でした。それもうまく機能するのですが、昨日のKeynoteをご覧になった方はご存知の通り、まさにそれを行う新しいAgentがリリースされました。では、新しいAgentを試してみましょう。これらのチャットを閉じて、新しいものを開きます。ドキュメント化したいapp.pyがここにありますので、docに移動します。docに移動すると、実は追加の入力は必要ありません。Enterを押すだけで、いくつかの選択肢が表示されます。
最初のオプションはREADMEの作成で、2番目は既存のREADMEの更新です。READMEがないので、当然READMEの作成を選択します。そして、このプロジェクトに対して実行したいのかを確認されるので、yesをクリックします。そして再び、何をする必要があるのかを理解し、ステップバイステップで分解して、目の前のタスクを実行するプロセスが始まります。このボックスは少し異なって見えます。新機能なので新しいレイアウトですが、やっていることは同じです。
ソースファイルをスキャンしていると表示されています。この場合は非常にシンプルなapp.pyだけです。これらを要約して、ドキュメントを作成します。そして再び、これには数分かかる可能性があります。過去24時間の実験では、その日の調子によって2〜4分ほどかかることがあります。これが実行されている間に、別のAgentをお見せしましょう。もう一度ここに戻って、forward slashを入力し、testを実行します。皆さんはドキュメント化されていないコードは嫌いですよね。Unit Testを書くのが嫌いな方はどれくらいいますか？私はあまり創造的ではないので、テストフレームワークの観点からうまく考えられません。そのため、これが発表された時は非常に興奮しました。これはシンプルなLambda functionですが、それでも問題が発生する可能性はあります。そのため、テストを確実に行い、Unit Testを用意しておきたいのです。
その処理が実行されている間（実際にはかなり早く終わりますが）、READMEを見てみましょう。ドキュメント生成のためのAgentとの最初のチャットに戻ると、完了したと表示されています。ファイルを開いて確認してみましょう。閉じてみると、ディレクトリ内のすべての項目のツリーが含まれた、きちんとフォーマットされたREADMEファイルができているのが分かります。各ファイルの役割や、インフラストラクチャのデプロイ方法、APIの呼び出し方について説明されています。しかも、私たちは退屈なドキュメント作成作業を自分でする必要がありませんでした。自動的に作成されたのです。これは本当にエキサイティングですね。
変更を承認すると、READMEファイルがドキュメントに作成され、Markdownでプレビューできるようになります。テストに戻ってみると、これも完了していて、test_app.pyという新しいファイルが作成されています。このファイルを開くかdiffを見ると、多くの異なるUnit Testを含む完全に新しいファイルが作成されているのが分かります。Lambda関数たった1行に対して89行ものコードというのは少し過剰な気もしますが、まあ、非常に安全なLambda関数になることは間違いありません。十分にテストされているので、pytestを実行しても何も問題は起きないはずです。
pytestと言えば、これが実際に動くかどうか確認してみましょう。テストを書くのは一つのことですが、そのテストが成功するか、あるいは期待通りに動作するかは別問題です。試してみましょう。ターミナルを開いて、test_app.pyを実行します。pytestでtest_app.pyを実行してみましょう。どうなるか見てみましょう。あれ、ファイルを承認していなかったからですね。では、ファイルを承認したので、今度はうまくいくはずです。うまくいきませんね。ええと、何が起きているんでしょう？どこにいるんだろう？testディレクトリにいますね。なるほど、そういうことでした。
さて、まだエラーが出ていますね。でも、エラーは1つだけで、「no module is called q_demo」というものです。明らかにテストのどこかでq_demoをimportしようとしているのが問題です。これこそが、Generative AIの出力を必ずサニティチェックする理由です。時々こういうことが起こります。特にNodeの場合、SDK全体をインポートしようとすることがありますが、Node 18ではそれができなくなっています。Lambdaでは特定のモジュールをインポートする必要がありますが、LLMはそのようなコンテキストを必ずしも持っているわけではありません。
だからこそサニティチェックが必要なのです。このデバッグ作業をお見せするのは止めておきましょう。私の大好きな作業の一つですが、皆さんが見たいものではないでしょう。計画通りにはいきませんでしたが、それでも問題ありません。テストは書けましたし、たとえ動作しなくても、Unit Testに馴染みがない人にとっては、Unit Testがどのように構成されるべきか、何をテストすべきかについての良いアイデアを提供してくれます。特にGoogleで検索しても、何を検索すればいいのか分からない場合には素晴らしい出発点となります。そこから、修正を依頼することもできます。時には本当に上手く修正してくれます。特に複雑なbashコマンドで、様々な他のコマンドにパイプで接続するような場合には、修正が非常に役立つことを経験しています。
Context の扱いには注意が必要です。というのも、会話全体が Context に取り込まれていくため、一度正解だと判断した回答は、たとえ実際には間違っていても、その会話の中では正しいと認識し続けてしまうからです。そのような循環に陥ってしまった場合は、その会話を終了して新しい会話を始め、もう一度試してみることをお勧めします。これは Q に限らず、どの LLM でも同じことが言えます。私は Claude でも ChatGPT でも同様の経験をしています。
以上が、Amazon Q の概要と、アプリケーションの構築方法についての手短な説明でした。たった20分で、コードを一切書かずにアプリケーションを構築することができました。テストについては限定的な成功でしたが、テストコードを自動生成することもできました。これらの作業は、スキルレベルによっては丸一日かそれ以上かかる可能性もある内容です。このように、開発作業が大幅に加速され、私自身も毎日活用しています。
ぜひ皆さんも試してみてください。どのような機能が使えるのか、何がうまくいって何がうまくいかないのか、ご自身で体験してみてください。もし面白い発見があれば、LinkedIn で私にご連絡ください。皆さんの発見をぜひ聞かせていただきたいと思います。ご清聴ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion