※本記事は、AWS re:Invent 2024で行われたセッション「Boosting productivity with Amazon Q Developer agents (DEV202)」の内容を基に作成されています。このセッションでは、Matt Lewis氏（AWS HeroおよびAWSアンバサダー）がAmazon Q Developerの機能と活用方法について解説しています。セッションの全容はYouTube（https://www.youtube.com/watch?v=25bzJ-4RWH8 ）でご覧いただけます。本記事では、セッションの内容を要約・構造化しておりますが、原著作者の見解を正確に反映するよう努めています。より詳細な情報については、オリジナルの動画をご視聴ください。AWS re:Inventの詳細は https://go.aws/reinvent 、その他のAWSイベントについては https://go.aws/3kss9CP でご確認いただけます。
1. はじめに
1.1. 講演者紹介: Matt Lewis (AWS HeroおよびAWS Ambassador)
皆さん、ようこそ。私の名前はMatt Lewisです。AWSヒーローおよびAWSアンバサダーを務める特権を持っています。イギリスでIBMに勤務しており、AWS関連のあらゆる業務に携わっています。本日は、Amazon Q Developerについて、特に生産性向上の分野に焦点を当ててお話できることを非常に嬉しく思います。今日のアジェンダはかなり内容が濃く、テンポの速いものになります。セッションを通じて、Q Developerのさまざまな機能や能力、そして利用方法をできるだけ多く紹介したいと考えています。皆さんが帰る頃には、これらの機能についてより深く理解し、自分で試してみたいという気持ちになっていただければと思います。
1.2. Amazon Q Developerの無料試用について
私の視点から見て素晴らしいニュースは、もし試してみたいと思われたら、このセッションで見ていただく全てのデモや小さな実演は、Amazon Builder IDにサインアップするだけで、Amazon Q Developerを使って無料でお試しいただけるということです。コストの面での参入障壁はありません。つまり、本日ご紹介する機能や能力は、追加費用なしで実際に皆さんご自身で試すことができるのです。このことは特に重要で、Q Developerのパワーを体験するのに財政的な制約がないことを意味しています。
1.3. AI コーディングアシスタントの普及状況（会場調査）
AIコーディングアシスタントについて高いレベルから話を始めたいと思います。会場の皆さんに手を挙げていただきたいのですが、AIコーディングアシスタントを日常的に使用している方はどれくらいいらっしゃいますか？Q Developerである必要はなく、Copilotでも、Cursorでも構いません。そして手を挙げた方の中で、それが生産性を向上させていると思う方はもう一度手を挙げてください。まだ判断がついていない方は手を下ろしておいてください。
結果を見ると、おそらく40〜50%の方が定期的に使用しており、それより少し少ない人数が望んでいる生産性向上を得ていることがわかります。つまり、AIコーディングアシスタントを使っている人は半数弱で、その中でも実際に生産性向上を実感しているのはさらに少ないという状況です。これは、AIツールの有用性とその活用方法について、まだ改善の余地があることを示しています。
1.4. Gartnerの予測: 2028年までに75%のエンタープライズソフトウェアエンジニアがAIコードアシスタントを使用
数ヶ月前にGartnerが発表したプレスリリースからの引用から始めたいと思います。これは彼らの調査や調査、研究から出てきたものです。彼らの予測によると、2028年までに75%のエンタープライズソフトウェアエンジニアがAIコードアシスタントを使用するようになるとのことです。昨年は約10%だったことを考えると、これは普及率の指数関数的な成長といえるでしょう。
そして、これはエンタープライズソフトウェアエンジニアの話です。スタートアップや小規模組織を見始めると、その数はさらに大きくなるでしょう。ここから私が受け取るメッセージは、もしあなたがまだAIコーディングアシスタントを使用していない、あるいは少なくともAIコーディングアシスタントを既存の開発ライフサイクルに導入・統合する方法を検討していないなら、競合他社に対して不利な立場に自らを置いているということです。なぜなら、彼らは間違いなく導入しているからです。
2. AI コーディングアシスタントの基本概念
2.1. 非決定論的性質の理解
martinfolwer.comのウェブサイトの記事からのこの引用も、私は非常に気に入っています。この引用はAIコーディングアシスタントの役割について語っており、本質的に「通常のソフトウェアに対して持つのと同じ期待を持ってそれらを使用することはできない」と述べています。これは、通常のソフトウェアを扱うとき、それは決定論的だからです。
つまり、値を渡すと、特定の値が返ってくることを期待します。そして私たちは皆、AIコーディングアシスタントに関しては、それがGenerative AIと基盤となる大規模言語モデル、ファウンデーションモデルに基づいていることを知っています。これらは本質的に非決定論的です。つまり、コードの生成を例にとると、特定の関数を生成するようにプロンプトを渡して依頼すると、生成されるコードはコンパイルして実行できるかもしれませんが、組織内のコーディング標準に従っていないかもしれません。あるいは、最適でない場合や、パフォーマンスが出ない場合、さらには脆弱性を含んでいる可能性もあります。コードは生成されても、そのコードの正確性にはレベルがあるのです。
AIコーディングアシスタントの見方として私が好むのは、それを盲目的に100%正確なものを生成すると期待する「ブラックボックス」として見るのではなく、要件の完了に至る道のりを加速させるために協力するツールとして扱うことです。AIコーディングシステムがその道のりの60%、70%、80%まで到達させることができるという事実は、それが信じられないほど有用であることを意味し、より安く、より速く物事を提供できることを意味します。
2.2. 生成されたコードの正確性レベル
AIコーディングアシスタントが生成するコードは、さまざまなレベルの正確性を持ちます。生成されたコードがコンパイルして実行できるという事実だけでは、それが最適なコードであるという保証にはなりません。実際には、組織内のコーディング標準に従っていない可能性があります。また、最適化されていないため、パフォーマンスが低い場合もあります。さらに悪いことに、コードに脆弱性が含まれている可能性もあります。
私たちは、AIコーディングアシスタントが正しいコードを生成したとしても、そのコードの「正確性のレベル」はさまざまであるという事実を理解する必要があります。コードが技術的に機能するかもしれませんが、プロダクションレベルの品質に達していない場合があるのです。
このような非決定論的な性質を持つツールを使用する際には、開発者自身が最終的なコード品質に責任を持ち、生成されたコードをレビューして必要に応じて修正する必要があります。AIツールはプロセスを大幅に加速させることができますが、人間の監督と判断は依然として不可欠なのです。
2.3. 開発プロセスを加速するツールとしての位置づけ
私がAIコーディングアシスタントを見る好ましい方法は、それを「ブラックボックス」として見るのではなく、要件の完了への道のりを加速させるために一緒に作業するツールとして扱うことです。AIコーディングシステムがその道のりの60%、70%、80%まで到達させることができるという事実は、それが信じられないほど有用であることを意味し、より安く、より速く物事を提供できることを意味します。
AIコーディングアシスタントは、完璧なコードを生成することを盲目的に期待するものではありません。むしろ、プロセスを開始し、適切な方向に進むための足場として機能します。開発者は依然として最終的な監督と判断を提供し、生成されたコードを微調整し、組織の標準に合わせ、最適化する必要があります。
このようなアプローチにより、AIコーディングアシスタントは開発ライフサイクル全体を通じて真の生産性向上ツールとなります。コードを最初から書くのではなく、AIが提供する基盤から始めることで、開発者は詳細な実装よりも高レベルの設計と問題解決に集中できます。結果として、より迅速な開発サイクル、コスト削減、および最終的には高品質なソフトウェアの提供が可能になります。
3. Amazon Q Developerの機能と特徴
3.1. コンテキストと複雑さの軸による機能マッピング
ここでQ Developerのポジショニングを説明してみます。このチャートでは、実行できるタスクを2つの軸で分類しています。縦軸はコンテキストに関するもので、これは入力コンテキストを意味しています。低コンテキストとは、コードの単一行を選択する場合や、関数やメソッド、クラス、あるいはファイル全体を選択する場合を指します。高コンテキストについて話し始めると、それは複数のファイルやプロジェクト構造全体にわたって何かを操作したい場合です。
そして横軸は複雑さに関するものです。これは、達成しようとしているタスクの複雑さです。チャットのような機能は、単純なタスクに非常に適しています。しかし、複雑な、複数のステップを必要とするタスクを実行したい場合、私たちはエージェントの世界に入ります。そして昨日の朝のMatt Garmanの基調講演をご覧になった方はご存知の通り、現在Q Developerには5つのエージェントが利用可能です。
つまり、エージェントが今後の方向性であることは非常に明確です。コードを生成するエージェント、ユニットテストを生成するエージェント、コードレビューを実行するエージェント、ドキュメントを生成するエージェント、そしてコード変換のためのエージェントがあります。これらのエージェントはそれぞれ特定の複雑なタスクに特化しており、高いコンテキスト理解と複雑な処理能力を組み合わせることで、開発プロセスをより効率的にサポートします。
3.2. チャット機能: 単発の質問や簡単なコード生成
Q Developerに馴染みのない方のために簡単に説明すると、これはチャットウィンドウを示しています。チャットウィンドウは左上にあり、あらゆる種類のことに使用できます。私は通常、アーキテクチャに関する質問をするために使用しています。つまり、IDE内のAWS Solution Architectとして機能させることができます。簡単なコードの生成を依頼したり、あるプログラミング言語から別の言語へコードを翻訳したりすることもできます。しかし基本的には、これは一回の動作で実行されます。
プロンプトを入力し、Enterキーを押すと、推論が実行され、結果が返ってきます。このシンプルなインターフェースは、開発中に素早く質問したり、アドバイスを求めたりするのに最適です。AWSアーキテクチャに関する質問からシンプルなコード生成まで、チャットウィンドウは基本的なサポートツールとして機能します。ただし、このチャット機能は単一ショットでの操作に限られており、複雑な対話や多段階のタスクには他の機能が適しています。
3.3. インラインチャット: コード内での直接的な対話
ここ1、2ヶ月の間に、インラインチャットがリリースされました。これは実際、IDE内でコードと直接対話するという点で、はるかに直感的です。これにより、直接チャットすることができ、これは良いことです。私が通常使用する方法は、コードのスニペットを選択し、Macではコマンド+Iを押してからプロンプトを入力することです。
この機能が優れている理由は、コードを最適化したり、新機能を追加したり、何らかの方法で変更したりしたい場合、差分（diff）をインラインで生成し、その差分を受け入れるか拒否するかを選択できるからです。これは大きな改善です。なぜなら、チャットウィンドウだけを使用してこれを行おうとすると、生成されたコードを手動でコピーしてファイルに貼り付ける必要があるためです。このインラインチャットは、コードとやり取りするためのずっと直感的な方法なのです。
3.4. @Workspaceコンテキスト: プロジェクト全体の理解
現在利用可能になった特別なコンテキストとして@Workspaceがあります。プロンプトに@Workspaceを含めると、Q Developerはコードファイル、設定、プロジェクト構造全体を取り込みインデックス化することで機能します。これにより、チャットで作業するとき、IDE内のアプリケーション全体にわたる包括的なコンテキストが得られます。
これはプロジェクト全体を理解するのに最適です。プロンプトに@Workspaceを含めることで、Q Developerはファイルのインデックスを作成し、プロジェクト構造を理解するため、アプリケーション全体に関する質問に答えることができます。これはプロジェクトの全体像を把握したい場合や、特定の機能がどこで実装されているかを理解したい場合に非常に役立ちます。
@Workspaceコンテキストを使用することで、開発者は新しいコードベースに迅速に適応したり、大規模なプロジェクトで特定の関心領域を見つけたりするのに必要な時間を大幅に削減できます。これは特に新しいチームメンバーのオンボーディングやレガシーコードの理解に役立ちます。
3.5. エージェント: 複雑なタスクを自律的に実行する機能
最後にエージェントの世界に入ります。これはForbesからの引用で、私は気に入っています。agentic AIについて話し始めると、「特定の目標を達成するために、ある程度の自律性を持ち、独自に接続する人工知能システムを指す」と述べています。これはまさにQ Developerのエージェントが行うことです。
コードの機能を生成するタスクであれ、コードを変換するタスクであれ、エージェントを設定すると、それらは実装計画を生成するという意味で自律的に行動します。目標を達成する方法を探し、特定のタスクのために訓練されているため、単一のファウンデーションモデルでの推論を実行するだけでなく、実際には複数の異なるファウンデーションモデルを使用します。
彼らはカスタムモデルを使用し、RAG（検索拡張生成）を使用することもできます。そしてこれらすべてにより、チャットウィンドウだけを使用するよりもはるかに豊かで正確なレスポンスが得られます。昨日の朝の発表で明らかになったように、現在Q Developerには5つのエージェントがあります。これらのエージェントはそれぞれが特定のタスクに特化しており、複数のモデルとテクニックを組み合わせることで、単一のチャットインターフェースでは不可能なレベルの精度と複雑さを実現しています。
4. コード理解の強化
4.1. 未知のコードベースへの対応方法
コード生成について考えがちですが、その前にコード理解について始めたいと思います。その理由の一部は、私の経歴がアプリケーションをサポートしてきたソフトウェアエンジニアだからです。多くの場合、サポートするアプリケーションに出会うと、新しい組織であれ、新しいアプリケーションであれ、それは馴染みのないコードベースで、本当に理解していないものです。
あまりにも多くの場合、ドキュメントが実際に本番環境にデプロイされているものと一致していません。この実験を実行するために、私は基本的にGitHubからサンプルアプリケーションをクローンしました。これにはバックエンドとフロントエンドのパッケージ、つまりバックエンドとフロントエンドのコンポーネント、そしてBedrockのインフルエンスとナレッジベースがあります。
しかし、READMEファイルを削除してしまいました。これは、このプロジェクトについて何も知らない状態でデモを行う試みでした。クローンした後、IDEにクローンし、チャットに行き、「このアプリケーションは何をするのですか？」と尋ねることができます。チャットはコンテキストを持たないので、「申し訳ありませんが、お手伝いできません」と返ってきます。
実際、ファイルを開いていれば、開いているファイルのコンテキストを使用し、そのファイルについて少し教えてくれるでしょうが、それからアプリケーションがどのようなものかについて推測することしかできません。このような状況では、コードベースを理解するために、@Workspaceコンテキストや新しいドキュメント生成エージェントなどのQ Developerの機能が非常に役立ちます。
4.2. ドキュメント生成エージェントの活用例
昨日の早朝まで、このスライドでは@Workspaceコンテキストを使ってREADMEファイルを生成する方法や、アプリケーションについてもっと知る方法について説明していました。しかし昨日から、ドキュメント用の開発者エージェントが利用可能になりました。
これを実行するとき、「/doc」と入力してEnterキーを押すだけで、READMEを作成するように依頼します。READMEの更新を依頼することも可能ですが、今回はプロジェクト全体のドキュメントを作成するように依頼しました。エージェントはドキュメントを生成し、私はそれを受け入れました。変更内容を確認することもできます。
そして作成されたファイルを見ると、その徹底ぶりがわかります。プロジェクト構造、アプリケーションのデプロイ方法、テスト方法、設定、トラブルシューティング方法について説明し、データフローについて説明し、最後に組み込まれている主要なコンポーネントについて説明しています。
これらすべてがドキュメントエージェントによって生成され、20〜30秒程度で完了しました。つまり、このエージェントはコードベースを分析し、最新のアプリケーションREADMEファイルを作成しています。これにより、新しいプロジェクトやコードベースに参加したときに、迅速に全体像を把握することができます。
4.3. @Workspaceを使ったプロジェクト構造の探索
@Workspaceが本当に優れているのは、機能を実装するよう依頼された場合に、それが馴染みのないコードベースであるため、その機能がプロジェクトやアプリケーションのどこで実装または使用されているのかが完全には分からない場合です。
この例では、@Workspaceを使用して、Bedrockと対話するファイルはどこにあるかについてアプリケーションを調査するようQ Developerに依頼しています。@Workspaceを使用してこれを送信できます。ファイルをインデックス化しているため、プロジェクト構造とそれらのファイルすべてについて知っており、調査して、アプリケーション内でBedrockと対話するすべての異なるファイルについて教えてくれます。
ナレッジベースのBedrockを作成するCDKスタックから、それと対話するLambda関数まで、すべてを教えてくれます。これにより、新しい機能を実装する必要がある場所を迅速に特定できるようになります。
@Workspaceコンテキストを活用することで、大規模なコードベースでも特定の関心領域を素早く見つけ出すことができます。例えば、特定のAWSサービスを使用しているファイルや、特定のライブラリを呼び出している部分を見つけることができます。これにより、新しい機能の追加やバグ修正の際に、どのファイルに焦点を当てるべきかを迅速に特定できるのです。
4.4. Bedrockとの連携ファイルの特定
前の例を続けると、コード理解の例として、コードから自然言語やテキスト記述への変換方法をお見せしようとしています。私は可視化が本当に好きで、アプリケーションがどのように構築されているかを視覚化し、個々のコンポーネントとそれらの相互作用を示すことができます。
前回の例を取り上げて、@Workspaceコンテキストを使用してQ Developerに、ワークスペース内のすべてのファイルを理解し、シーケンス図を生成するよう依頼することで、より良い理解を得ようとしています。シーケンス図を生成したいと指定し、PlantUML形式で指定します。そのため、VS code IDE内に拡張機能をインストールし、フロントエンドとバックエンド間のデータフローを説明して見ることができます。
これをプロンプトとして入力できます。Q Developerが処理し、PlantUML図形式を生成します。ここから、PlantUMLは.pmlファイルまたはdot.pmlファイルです。空のファイルを開き、チャットウィンドウに戻り、生成されたコードを挿入するだけで、それを図としてプレビューし、ソースコードにも保持できます。
このように、10〜20秒程度で、Q Developerはフロントエンドからバックエンドへの流れだけでなく、すべてのコンポーネントとすべてのメソッド呼び出しを示すシーケンス図を生成しました。これはコードベースを調査し始め、シーケンス図、クラス図、さまざまな種類のアーキテクチャ図を作成する本当に価値のある方法です。
5. コードの可視化
5.1. PlantUMLによるシーケンス図の自動生成
可視化に関してさらに続けると、私は本当に視覚化が好きで、アプリケーションがどのように構築されているか、個々のコンポーネントとそれらがどのように相互作用するかを示すことができます。前回の例を取り上げて、より良い理解を得ようとしています。@Workspaceコンテキストを使用してQ Developerに依頼し、ワークスペース内のすべてのファイルを理解した上で、シーケンス図を生成するよう頼みます。
私はシーケンス図を生成したいと指定し、PlantUML形式で指定します。この目的のためにVS Code IDE内に拡張機能をインストールしました。フロントエンドとバックエンド間のデータフローを説明して可視化したいのです。これをプロンプトとして入力すると、Q Developerが処理して、PlantUML図形式を生成してくれます。
PlantUMLは.pmlファイルまたはdot.pmlファイルとして扱われます。そこで、空のファイルを開き、チャットウィンドウに戻って、生成されたコードを単純に挿入します。その後、図としてプレビューでき、ソースコードにも保持できます。
こうして、わずか10〜20秒ほどで、Q Developerはフロントエンドからバックエンドへの流れを示すだけでなく、すべてのコンポーネントとすべてのメソッド呼び出しを明示したシーケンス図を生成しました。これはコードベースを調査し始め、シーケンス図、クラス図、さまざまな種類のアーキテクチャ図を作成する非常に価値のある方法です。シンプルなプロンプトだけで、複雑なコードベースの構造と動作を視覚的に理解できるようになります。
5.2. Infrastructure Composer（旧Application Composer）の活用
ここでは別のプロジェクトを選びました。これも同様にGitHubのAWSサンプルの一つで、もう少しさまざまなAWSサービスを使用しています。この場合、Infrastructure Composerというサービスを使用します。これは数ヶ月前までApplication Composerと呼ばれていましたが、最近名前が変更されました。
Infrastructure Composerは、クラウド変換テンプレートからAWSサービスを視覚化するのに非常に優れています。私がすべきことは、右クリックしてInfrastructure Composerで開くだけです。すると、AWSアイコンを使って定義されているすべてのリソースとそれらの間の接続を即座に表示してくれます。
しかし多くの場合、ドキュメントにこれを含めたい場合は、スナップショットを撮る必要があるでしょう。そこで、そのCloudFormationテンプレートを別の方法で視覚化する方法を考えてみましょう。ここでは、CloudFormationテンプレートを開いています。これが入力コンテキストとして使用され、Mermaid形式でアーキテクチャ図を生成するよう依頼します。これは別の人気のある図表形式です。
Q Developerはこのリクエストを処理し、CloudFormationに基づいてアーキテクチャ図を生成します。Mermaidはマークダウンファイルに含めることができます。Mermaid図としてこれを注釈付けしたマークダウンファイルがあり、そこにコードを挿入するだけです。そこから、そのマークダウンファイルをプレビューするだけで済みます。
プレビューすると、CloudFormationから自動生成されたものが表示され、今回はそのフローについてもう少し詳しく見ることができます。ユーザーがAmplifyフロントエンドとやり取りし、Alexaボットに行き、Lambda関数がさまざまなDynamoDBテーブルと通信する様子が見えます。これにより、少しよりインタラクティブになり、アプリケーションに命を吹き込みます。同じことをPlantUMLでも行うことができます。複数の異なる図表形式をコードベースやCloudFormationテンプレートから生成できるのです。
5.3. CloudFormationテンプレートからのMermaid図の生成
CloudFormationテンプレートを別の方法で視覚化する方法を見てみましょう。ここではCloudFormationテンプレートを開いています。これが入力コンテキストとして使用され、Mermaid形式でアーキテクチャ図を生成するよう依頼します。Mermaidは人気のある別の図表形式です。
Q Developerはこれを処理し、CloudFormationに基づいてアーキテクチャ図を生成します。Mermaidはマークダウンファイル内に直接含めることができるという利点があります。そこで、Mermaid図として注釈を付けたマークダウンファイルを用意し、そこに生成されたコードを挿入するだけです。そして、そのマークダウンファイルをプレビューします。
プレビューすると、CloudFormationから自動生成された図が表示されます。今回は、アプリケーションのフローについてより詳細な情報が得られます。ユーザーがAmplifyフロントエンドとどのように対話し、Alexaボットに進み、Lambda関数がさまざまなDynamoDBテーブルとどのように通信するかが視覚的に表現されています。これによりアプリケーションがより対話的になり、生き生きとしたものになります。
同様のことをPlantUMLでも実行できます。Q Developerは、コードベースやCloudFormationテンプレートから複数の異なる図表形式を生成する柔軟性を提供しているのです。この機能により、技術的なドキュメントの作成が大幅に簡素化され、アーキテクチャの理解が促進されます。
5.4. Draw.io図面からのCloudFormationテンプレート生成
最後の可視化に関する例は、個人的に本当にワクワクするものです。私が現在行っている作業の多くは、スケッチや小さな設計から始まります。なぜなら、「何を実装する必要があるのか？どれくらいのコストがかかるのか？」を理解したいからです。そこで設計をスケッチします。
この場合、draw.ioを使用します。これはデモとして非常にシンプルなdraw.io図です。draw.ioはダイアグラミングツールとして、基礎となるXML形式を持っています。このDraw.io図では、VPCを持つアカウントを定義し、CIDR範囲を指定し、3つのパブリックサブネットと3つのプライベートサブネットを3つのアベイラビリティゾーンにまたがって持っています。
私がすることは、図を編集して、XMLファイルを取得し、それを入力コンテキストとして使用できるファイルに貼り付けるだけです。そこからQ Developerに行き、「このファイルのアーキテクチャを説明してください」と依頼できます。これはどのDraw.io図でも、どのMermaid図でも、どのPlantUML図でも機能します。渡した図を分析することで、アーキテクチャの説明を開始できます。
さらに進んで、「この図からCloudFormationテンプレートを生成してください」と依頼することもできます。Q Developerはさらに進んで、アカウントにテスト用に直接デプロイできる有効なCloudFormation YAMLファイルの生成を開始します。
特に気に入っている点は、スクロールダウンしていくと見えるかもしれませんが、サブネットに適用されているすべてのCIDR範囲とサブネットを取り込んでいることです。つまり、VPC、インターネットゲートウェイ、すべてのサブネットを作成し、Draw.io図で定義されている正確なCIDRブロックを使用しています。
これは、アーキテクチャ図から作業コードへの移行がいかに迅速になるかを見る上で、非常に印象的です。従来は手作業でインフラを記述する必要があったのが、単純な図面からコードを自動生成できるようになったのです。これにより、設計から実装までの時間が大幅に短縮され、人為的なエラーも減少します。
6. コード変換エージェント
6.1. Java 8/11からJava 17への移行事例
次にコード変換エージェントについて少し見ていきます。現在、このエージェントはJava 8/Java 11からJava 17への移行に対応しています。昨日から、.NET、メインフレーム、VMwareワークロードのパブリックプレビューも開始されました。
これを実演するために、別のサンプルアプリケーションを用意しました。これは私が約5年前に書くのを手伝ったアプリケーションです。AWSテックトークで発表しました。これは架空の自転車免許のアプリケーションです。このアプリケーションの良い点は、実際にJava 11で書かれていたことです。
ここで覚えておくべき重要なことは、Java 11からJava 17にアプリケーションを更新する際、これらすべてのライブラリとフレームワークがあり、より最新のJavaバージョンを見ると、実際にはライブラリとフレームワークのすべてのバージョンを、最新バージョンに準拠したバージョンに更新する必要があるということです。
通常起こることは、更新が複雑になっていくことです。アプリケーションを更新しようとするにつれて、この長い依存関係チェーンが生じ、最終的には未パッチのまま放置されることになります。その課題は、それが脆弱性につながるということです。
このケースでは、これをクローンすると、DynamoDBを裏で使用しているため、グローバルセカンダリインデックスを持つDynamoDBテーブルを作成するCloudFormationテンプレートが見つかります。これにより、Java 11アプリケーションを実行し、その後コード変換エージェントを使用してJava 17に移行する準備が整います。
6.2. 依存関係チェーンの複雑さへの対応
Java 11からJava 17にアプリケーションを更新する際の主な課題の一つは、依存関係チェーンの複雑さです。アプリケーションには多数のライブラリとフレームワークがあり、Javaの最新バージョンに移行する場合、これらのライブラリとフレームワークのバージョンをすべて、最新のJavaバージョンに互換性のあるバージョンに更新する必要があります。
この更新プロセスは、進むにつれてますます複雑になります。アプリケーションを更新しようとすると、長い依存関係チェーンが発生し、一つの更新が他の多くのコンポーネントに波及効果をもたらします。その結果、多くの組織ではアップデートが困難すぎると判断し、アプリケーションが古いバージョンのままパッチが適用されない状態で放置されることがよくあります。
この状況の大きな問題点は、未パッチのアプリケーションが脆弱性を持つ可能性が高まることです。アプリケーションが古いバージョンのJavaや関連ライブラリで動作し続けると、既知のセキュリティの脆弱性にさらされたままになる可能性があります。これは組織にとって重大なセキュリティリスクとなります。
これらの依存関係の複雑さを手動で管理するのは非常に時間がかかり、エラーが発生しやすいプロセスです。そのため、コード変換エージェントのような自動化ツールが非常に価値があります。これらのツールは依存関係チェーンを分析し、必要な更新を特定し、互換性の問題を解決するのに役立ちます。これにより、アプリケーションを最新バージョンに安全に移行するプロセスが大幅に簡素化されます。
6.3. コード変換の実行手順と実行時間
コード変換エージェントの実行方法を見てみましょう。これは今朝撮影したスクリーンショットで、Q内での現在の表示を正確に示しています。まず、「/transform」を選択すると、システムはJava 11モジュールを検出します。そこで変換を実行し、ユニットテストを実行することを選択します。一括差分と複数差分のどちらかを選択できますが、今回は一括差分を選びます。
この段階で、Amazon Qはプロジェクトをローカルでビルドします。すべての依存関係をダウンロードし、コンパイルしてからユニットテストを実行します。ローカルでビルドして全てが正常に完了すると、ビルド成果物としてアップロードします。これには、ソースコード、プロジェクトの依存関係、ビルドログが含まれ、AWS内の安全なビルド環境にアップロードされます。
この時点で、コード変換エージェントは安全なビルド環境内でプロジェクトをビルドし、AIを使用してコードベースの分析を開始します。コードベースを分析した後、変換計画を作成します。これが初期変換計画で、実行する必要があると考えるステップが示されています。新しい依存関係バージョン、主要なコード変更、非推奨コードの代替案などが含まれています。
進行中に見られる興味深い点として、エージェントは異なるライブラリやフレームワークを更新し、Java 17に対してコンパイルしようとします。スクリーンショットでは、更新しようとするとコンパイルに失敗しているのが分かります。エージェントの内部では、実際には複数エージェントシステムが動作しており、デバッガーがあります。問題が発生すると、それを返して AIを使用してそのエラーを修正します。コードベースを変更し続け、Java 17アプリケーションとしてコンパイルできるようになるまで調整を続けます。
変換が完了すると差分を確認でき、今回は単一の差分を選びました。もし複数差分オプションを選んでいた場合、「差分1/2」または「1/3」、「1/4」のように表示されます。ファイルの1つをクリックすると、内部動作の概要が分かります。新しいメソッドが完全に追加されており、これはspringフレームワークのCRDリポジトリインターフェースを実装するクラスだからです。Java 17対応のspringフレームワークバージョンでは、新しいインターフェースメソッドが追加されており、これは破壊的な変更です。Java 11コードではこのインターフェースメソッドがないためコンパイルできませんでしたが、エージェントはメソッドだけでなく、その実装も追加しています。
このプロセス全体は約10〜12分で完了し、全てのユニットテストに合格して、正常に動作するJava 17アプリケーションが得られます。これは、手動で行うと何時間もかかる可能性がある変換作業を、短時間で自動的に完了できる素晴らしい例です。
6.4. コード変換後の検証と実行
コード変換が完了したら、変換サマリーを確認できます。この変換サマリーは、実装計画とは少し異なります。いくつかの依存関係が追加され、アップグレードする必要のない依存関係もありました。変換サマリーを最後に確認すると、10分、11分、12分程度実行され、すべてのユニットテストに合格したことがわかります。
そこで、アプリケーションをテストすることができます。Mavenファイルが更新されたことを確認できます。プロジェクト構造に移動し、私はAmazon Correttoを使用しています。これをJava 17バージョンに更新します。それを保存し、Mavenクリーンとコンパイルを実行して、pom.xmlファイルに加えられた最新の変更を確実に更新し、その依存関係を取り込みます。
次に、起動構成に移動して、起動構成がJava 17に設定されていることを確認します。それを適用してから実行できます。これにより、アプリケーションがJava 17アプリケーションとして起動します。起動したら、戻って、動作するアプリケーションであることを確認するためにテストできます。
私が最も印象的だと思うのは、変換サマリーから見て、これが約12分間実行されたという事実です。わずか15分で、ライブラリとフレームワークのすべてを含むアプリケーション全体をJava 11からJava 17に更新し、発生したすべてのコンパイルエラーを修正し、現在Java 17で実行されているアプリケーションがあります。
これは本当に印象的です。以前は、このような移行作業には何時間も、場合によっては何日もかかっていたものが、わずか数分で完了し、すぐに新しいバージョンで運用可能になります。これにより、定期的なアップデートが現実的になり、アプリケーションのセキュリティと機能を最新の状態に保つことができます。
7. ユニットテスト生成
7.1. 新しいテスト生成エージェントの紹介
こちらは少しここに入れ込むような形になりますが、昨日、テストまたはユニットテスト用の新しいQ Developerエージェントが発表されました。現在はJavaとPythonをサポートしており、他の言語もすぐに追加されると思います。
このJavaアプリケーションを使ってこれがどのように機能するかをお見せしようと思いました。テスト用エージェントの仕組みは、実行すると、IDE内で現在開いているアクティブファイルを使用します。そのファイル内の関数を選択するオプションがあります。あるいは、私の場合のように「test/test」と入力してEnterを押すだけで、このクラス内のすべてのメソッド、すべての関数に対してユニットテストを生成します。
これが現在利用可能なので、差分を表示することができます。実際、ユニットテストの数、その長さ、品質に驚かされました。これらすべてが作成され、受け入れることができます。そして、作成されたユニットテストが手に入ります。
これは、チャットウィンドウを使用してユニットテストを生成しようとするよりも、はるかに優れた豊かな方法です。このエージェントは、テスト対象のコードを深く理解し、個々の関数の振る舞いを適切にテストする包括的なテストスイートを自動的に作成します。これにより、開発者はテスト作成の労力を大幅に削減でき、より多くの時間を実際の機能開発に費やすことができます。
7.2. クラス全体のユニットテスト自動生成
ユニットテスト用エージェントの仕組みは、実行すると、IDE内で現在開いているアクティブファイルを使用します。そのファイル内の特定の関数を選択するオプションがありますが、「test/test」と入力してEnterを押すだけで、このクラス内のすべてのメソッド、すべての関数に対してユニットテストを一括で生成することができます。
これを実行すると、エージェントは選択したファイル内のすべてのメソッドを分析し、それぞれに適切なユニットテストを自動的に作成します。このプロセスは非常に迅速で、複雑なクラスであっても数分以内に完了します。
エージェントは各メソッドの役割、入力パラメータ、予想される出力、および可能性のあるエッジケースを理解して、それぞれに対応するテストケースを生成します。さらに、モックオブジェクトや依存関係の注入など、高度なテスト技術も適切に使用します。
生成されたテストは単にコードカバレッジを満たすだけでなく、実際の機能を意味のある方法でテストするように設計されています。これにより、テスト駆動開発のプラクティスも容易になり、コードの品質と信頼性を高めることができます。
7.3. 生成されたテストの質と量
ユニットテストエージェントを実行すると、差分を表示できるようになります。私は実際、生成されたユニットテストの数、その長さ、そして何よりも品質に驚かされました。これらすべてが自動的に作成され、私はその変更を受け入れるだけでよかったのです。そして、完全に機能するユニットテストスイートがすぐに手に入りました。
これは、チャットウィンドウを使用してユニットテストを生成しようとするよりも、はるかに優れた方法です。チャットウィンドウでは、コンテキストの制限やテストのフレームワーク全体の理解の限界から、断片的なテストしか作成できないことがあります。一方、専用のテストエージェントでは、コードの全体像を把握し、クラス間の関係性や依存関係を考慮に入れたテストを生成します。
生成されたテストには、正常系のテストだけでなく、境界値テストやエラーケースも含まれています。これはコードの堅牢性を確保するために非常に重要です。また、テストは読みやすく、適切に構造化されており、将来のメンテナンスも容易です。
コードカバレッジの観点からも、エージェントが生成するテストは非常に包括的で、通常は手動で作成するよりも高いカバレッジ率を達成します。これにより、バグの早期発見と、リファクタリング時の安全性確保に貢献します。
8. セキュリティ強化と脆弱性スキャン
8.1. 自動レビューと完全なプロジェクトスキャン
最後に脆弱性スキャンについて触れておきます。一般的な不満や懸念事項だと思うからです。Generative AIを使用して、それから出てくる非決定論的なコードを生成する場合、それが脆弱性だらけでないことをどうやって確認するのでしょうか？
Q Developerの素晴らしい点は、コードスキャンとセキュリティスキャンが組み込まれていることです。スクリーンショットでは、自動レビューを実行するか、一時停止して完全なプロジェクトスキャンを実行できることがわかります。自動レビューをデフォルトで設定していると、ファイルに変更を加えて保存するたびに、そのファイルに対してスキャンが実行され、実質的には裏側でCodeGuruディテクターライブラリを使用してテストします。
このプロセスは基本的に3つのことを検査します。まず、SAST（静的アプリケーションセキュリティテスト）を実行します。これは、ソースコードに対して静的分析を実行することで、クロスサイトスクリプティングやSQLインジェクションなどの問題を探します。次に、シークレット検出を行います。シークレットアクセスキーやコードベースにハードコードされたものがないか確認します。最後に、インフラストラクチャアズコードのスキャンを行います。CloudFormationテンプレート、Terraform、CDKなどをスキャンし、設定ミスやAWSのベストプラクティスに準拠していない領域がないか確認します。
この一環として、完全なプロジェクトレビューを実行することもできます。昨日リリースされた別の新しいエージェントは、プロジェクト内の問題を検出して修正するものでした。これについて話せるように今朝実行しました。コードの品質については判断しないでください、4〜5年前に書かれたものですから。
8.2. 静的アプリケーションセキュリティテスト(SAST)
Q Developerのセキュリティスキャン機能の最初の主要コンポーネントは、静的アプリケーションセキュリティテスト(SAST)です。このプロセスでは、ソースコードに対して静的分析を実行し、実行前にコード内のセキュリティ脆弱性を検出します。
SASTは特に、クロスサイトスクリプティング(XSS)とSQLインジェクションの脆弱性に焦点を当てています。これらは最も一般的で危険なWeb脆弱性の一部であり、多くのセキュリティ侵害の原因となっています。静的分析によってコードのパターンを調査することで、これらの脆弱性を開発プロセスの早い段階で特定できます。
例えば、SASTはユーザー入力が適切にサニタイズされずにHTMLコンテンツに挿入されている場所を特定してXSS脆弱性を検出したり、ユーザー提供のデータがデータベースクエリに直接連結されているケースを探してSQLインジェクションを見つけたりします。
これらの問題は、コードがプロダクション環境に到達する前に特定されることで、セキュリティリスクを大幅に低減します。Q Developerは各問題について詳細な説明を提供するだけでなく、修正方法についての具体的なガイダンスも提供します。これにより、開発者は単に問題を把握するだけでなく、適切な修正方法を学ぶことができます。
8.3. シークレット検出機能
Q Developerのセキュリティスキャンの2番目の重要な要素は、シークレット検出機能です。このプロセスでは、コードベース内でハードコードされたシークレットや機密情報を探します。具体的には、AWSのシークレットアクセスキー、APIキー、パスワード、認証情報などの機密データがソースコードに直接含まれていないかを確認します。
これは非常に重要な機能です。なぜなら、ソースコード内にハードコードされた認証情報は、コードがバージョン管理システムにチェックインされた時点で、深刻なセキュリティリスクとなるからです。たとえプライベートリポジトリであっても、アクセス権を持つ誰もがこれらの認証情報を見ることができ、悪用する可能性があります。
シークレット検出機能はパターンマッチングや特定のシグネチャを使用して、シークレットの可能性がある文字列を識別します。例えば、AWSアクセスキーのパターンやデータベース接続文字列などを検出します。この機能は、環境変数やシークレット管理サービスを使用するべき場所でハードコードされた認証情報を使用していることを開発者に警告します。
この早期検出により、認証情報が公開リポジトリに公開されるなどの重大なセキュリティインシデントを防止することができます。シークレットが誤って公開された場合、それらを無効化して新しいものを発行するプロセスは煩雑で時間がかかりますが、この機能によってそのようなリスクを事前に軽減できるのです。
8.4. インフラストラクチャアズコードのスキャン
Q Developerのセキュリティスキャンの3番目の主要要素は、インフラストラクチャアズコードのスキャン機能です。この機能は、CloudFormationテンプレート、Terraform構成ファイル、CDK（Cloud Development Kit）などのインフラストラクチャ定義ファイルをスキャンします。
このスキャン機能は主に2つの重要な領域を検査します。1つ目は設定ミスです。例えば、パブリックにアクセス可能なS3バケット、不適切に構成されたIAMポリシー、または不必要に広範なセキュリティグループルールなどがないかを確認します。これらの設定ミスは、インフラストラクチャのセキュリティを大きく損なう可能性があります。
2つ目はAWSベストプラクティスへの準拠状況です。これには、リソースに適切なタグ付けがされているか、効率的なリソース設定がされているか、冗長性が適切に設定されているかなどの確認が含まれます。ベストプラクティスに従うことで、セキュリティだけでなく、コスト効率、メンテナンス性、スケーラビリティなど、インフラストラクチャの多くの側面が向上します。
このスキャン機能により、インフラストラクチャのコードがデプロイされる前に潜在的な問題を特定できるため、本番環境での問題を事前に防ぐことができます。クラウドインフラストラクチャの構成ミスは多くのセキュリティ侵害の主要な原因となっているため、この事前検証は非常に価値があります。
8.5. 問題の検出と修正の自動化
昨日リリースされた別の新しいエージェントは、プロジェクト内の問題を検出して修正するためのものでした。今朝、これについて話せるように実行してみました。書かれたコードの品質については判断しないでください、4〜5年前に書かれたものですから。
「/review」と入力するだけで、現在のファイルまたはプロジェクト全体をレビューするかを選択できます。今回はプロジェクト全体をレビューしたいと選びました。これによりコードレビューが開始され、結果が返ってきます。嬉しいことに、重大なエラーは見つからず、高レベルのエラーが18〜19個程度でした。
しかし、それらを見つけただけでは始まりに過ぎません。各所見をクリックすると、右側に適用できる修正が表示されます。これはCloudFormationだったので、修正を生成するためのコードがあります。これにより、受け入れるか無視してコードに直接移動するかを選択できる差分が生成されます。
このようにして、完全なプロジェクトスキャンを実行し、コードを分析し、問題を特定し、CWEや脆弱性へのリンクを提供し、そのコードをどのように修正するかの修正を生成して、コードベースに自動的に適用できるようにする自動化された方法が提供されます。これは非常に強力な機能です。
コードの修正が単に提案されるだけでなく、修正を直接適用できる点が特に便利です。これにより、セキュリティ問題の修正プロセス全体が合理化され、開発者はより安全なコードを迅速に作成できます。また、修正とともに説明や参考リンクが提供されるため、なぜその変更が必要なのかを理解する教育的な側面もあります。
9. コード生成の最適化
9.1. プロンプトエンジニアリングの重要性
次にコード生成について話しましょう。コード生成は、コーディングアシスタントについて話すとき、おそらく多くの人が考えることです。まず、プロンプトの重要性について触れておきます。
ここでは、Q Developerのチャットウィンドウに、2つの数値を取り、その合計を返すPython関数を生成するよう依頼しました。見ての通り、適切にコメントされたコードが生成され、生成されたコードの詳細、実行方法の説明が始まります。
実は、友人や同僚と話していて、例えばPythonプログラミングの専門家であれば、このような詳細な説明が少しイライラすることがあるという意見を聞きました。エンターキーを押すだけで、どんな関数を呼び出す必要があるかだけを知りたいのに、突然、出力が非常に冗長になり、詳細に説明されるからです。
そこで「これをどう変更できるか？」という疑問が生まれました。これは興味深い例です。同じプロンプトを実行して、最後に「説明なしで」という単語を追加するだけで、結果がどれほど違って見えるでしょうか？ これを実行すると、返されるのはコード2行だけです。
プロンプトをほんの少し変更するだけで、出力が大きく変わることがわかります。プロンプトエンジニアリングは、AIツールから望ましい結果を得るための重要なスキルです。適切な指示、適切なキーワード、適切な構造を使用することで、出力の詳細度、フォーマット、そして究極的には有用性を大幅に向上させることができます。
9.2. 「with no explanation」による簡潔な出力の取得
プロンプトがどれほど重要かを示す興味深い例をご紹介します。同じプロンプトを実行して、最後に「with no explanation（説明なしで）」という単語を追加するだけで、結果がどのように変わるか見てみましょう。
最初の例では、「2つの数値を受け取り、その合計を返すPython関数を生成してください」というシンプルなプロンプトを使用しました。Q Developerはコメント付きのコードを生成し、さらに関数の使い方や動作原理について詳細な説明を加えてきました。多くのコンテキストを提供してくれますが、経験豊富な開発者にとっては冗長に感じることもあります。
そこで、同じプロンプトの最後に「with no explanation」という単語を追加して実行してみました。その結果、返されたのはコードの2行だけでした。余分な説明やコメントはなく、純粋に必要なコードのみが提供されたのです。
プロンプトのこの小さな変更により、出力に大きな違いが生まれました。これはPythonのような高度なプログラマーには非常に有用です。彼らはコードがどのように機能するかを既に理解しており、基本的な関数について詳細な説明は必要としないからです。彼らが求めているのは、単にタスクを実行するための最小限の効率的なコードだけなのです。
このテクニックは、簡潔さを好む場合や、生成されたコードを直接コピーして使用したい場合に特に効果的です。必要なのはシンプルなコードスニペットだけで、詳細な説明や解説は不要という場合に最適です。
9.3. パーソナライズしたプロンプトの作成方法
次に考えるのは、個々の好みに基づいてQ Developerをカスタマイズする方法はあるのかということです。少しハックのようなものですが、これを行う方法があります。基本的に@Workspaceコンテキストを使用して、個々のファイルを参照できます。
この例では、Node.jsコードを生成したいと言っています。基本的に、personalizationファイルをNode.jsという名前のマークダウンファイルとして作成します。その中で非常に具体的に指定して、「明示的に指示がない限り、Node.jsのコードのみを提供してください。常にAWS SDK バージョン3を使用してください。」と書いています。この例では詳細な説明が欲しいと指定しています。
そして、@Workspaceコンテキストを使用してそのマークダウンファイルを参照しながらプロンプトを渡せば、「S3にファイルをアップロードするにはどうすればよいですか？」のような質問ができます。これが返ってきて、最初に「Node.jsを使用し、AWS SDK バージョン3を使用し、詳細な説明を提供しています」と書かれているのがわかります。
つまり、基本的にマークダウンファイルで渡された情報を入力コンテキストとして取り込んでいるのです。これにより、出力で見たい詳細レベルにパーソナライズされたコードを生成し、アドバイスを求めることができます。
このアプローチを使うと、よく使うプロンプトパターンを保存したり、プロジェクト固有の要件を定義したり、チーム全体で一貫したコーディングスタイルを維持したりすることができます。たとえば、エラー処理の方法、ログレベル、ドキュメント形式など、プロジェクトの標準を定義するパーソナライゼーションファイルを作成できます。
この方法は簡単なハックですが、AIコーディングアシスタントを真に個人化され、一貫性のあるツールに変えることができ、あなたやあなたのチームの特定の好みやガイドラインに沿ったコードを生成できるようになります。
10. 実践デモ：プロトタイプ開発の効率化
10.1. Infrastructure Composerを使ったバックエンド開発
最後に、いくつかのデモを実行する例を紹介していきます。私の現在の役割で行っている多くのことは、小さな概念実証を書くことになります。それらの多くは、サービスが互いに連携するかどうかの実行可能性を証明するものです。私は「言うよりも見せる」という考えの強い信奉者です。図を描いたり、長い説明を書いて誰かに渡すのではなく、「私はこれがこのように機能すると考えている。これが見ていただける実行中のコードだ」と言える方がはるかに良いと思います。
今回は、フロントエンドとバックエンドを構築することを目標に設定しました。フロントエンドはAmazon Builders libraryの記事からURLを受け取るウェブページ、そのURLをAPIに投稿し、そのAPIはLambda関数を呼び出してデータをスクレイピングし、Bedrockによってホストされているファウンデーションモデルに投入して要約し、フロントエンドにレンダリングして返します。
この場合、Infrastructure Composerを使用します。Infrastructure Composerは有効なAWS SAM（Serverless Application Model）テンプレートを生成します。バックエンドから始めるなら、APIゲートウェイとLambda関数を構築したいと考えており、AWS最良の実践に従った簡単な方法を見つけたいと思っています。
空のファイル、つまりテンプレートYAMLファイルを作成でき、これがCloudFormationファイルになります。右クリックしてInfrastructure Composerで開きます。これによりビジュアルエディタにこのパレットが開き、APIゲートウェイコンポーネントをドラッグ＆ドロップできます。POSTにしたいので変更できます。CORSを有効にする必要があることもわかっているので、すべてのオリジンを許可し、Content-Typeヘッダーを許可するように設定できます。POSTメソッドも許可するように設定します。Infrastructure Composerを使ってこれを設定し、保存できます。
そして、APIゲートウェイからLambda関数を呼び出したいと考えています。Lambda関数をドラッグ＆ドロップし、論理IDを変更できます（これはCloudFormationテンプレートで参照されます）。必要に応じてランタイムを変更することもできます。今日なら、node 22まで上げることもできるでしょう。その関数を保存し、Infrastructure Composerの素晴らしい点は、それらの間に接続を描くことができることです。これにより、APIゲートウェイからLambda関数へのLambdaプロキシ統合が自動的に設定されます。
template.yamlファイルに戻ってみると、Lambea関数が定義され、APIゲートウェイからのPOSTによってトリガーされることがわかります。次のステップは、そこにビジネスロジックを入れることです。
10.2. SAMテンプレートの自動生成と展開
次に、そこにビジネスロジックを入れることです。これには開発者エージェントを使用しますが、実際にはかなり長いプロンプトを入力することになります。通常、私は2つのセクションに分けて考えます。最初のセクションでは、実装したいビジネスロジックについて質問します。HTTPポストを受け入れてURLを取得し、そのURLをスクレイピングしてデータを抽出し、Bedrockを呼び出すなど、それらすべてのビジネスロジックを記述します。
そして下部では、READMEファイル、ライセンスファイルを含めること、依存関係を含めること、package.jsonファイルを含めること、コメントを含めること、ユニットテストを含めることなど、指示を与えています。これを開発者エージェントを使って渡すことができます。
開発者エージェントはプロンプトを受け取り、コードベース内のすべてのファイルを分析し、どのような変更が必要かを判断し始めます。進行していくにつれて、エージェントシステムなので、変更のステップを考え出し、ステップ2、ステップ3、ステップ4と進んでいくのが見えます。各ステップの後で、現在の状態を再評価します。ステップ4の終わりで「次のステップではユニットテストをまだ追加する必要がある。すべてのドキュメントが完成していることを確認する」と認識しているのがわかります。
このようにステップバイステップで進み、再評価し、最後には全てのファイルの変更と作成された新しいファイルを表示できます。コードの一部を変更したい場合は、フィードバックを提供するボタンをクリックし、コードを再生成してもらうこともできます。
これを受け入れたら、次の計画はデプロイすることです。Infrastructure Composerを使用し、AWSのSAMをサポートしているので、SAM deployを実行するだけで済みます。ガイド属性を使用し、template.yamlファイルを参照してSAM deployを実行します。これが先に進み、必要なのはスタック名を設定することだけです。これはCloudFormationスタック名となります。デプロイしたいリージョンを指定します。そして多くのデフォルトがあります。
コードがデプロイされ、スタックが展開されましたが、テストに必要なURLがわかりません。template.yamlファイルに戻り、インラインチャットを使って「APIエンドポイントを出力して」と依頼できます。Qがインラインチャットに表示され、CloudFormationファイルに差分として生成します。差分として受け入れ、再デプロイできます。戻ってくると、APIエンドポイントのURLが表示されるようになります。
これでcurlコマンドを実行してテストを開始できます。これらのステップにより、手動で多くのコードを書くことなく、完全に機能するバックエンドAPIをデプロイできました。エージェントが生成したコードと、Infrastructure Composerの視覚的アプローチにより、プロセス全体が大幅に効率化されました。
10.3. エラーの特定と修正の迅速化
テストを開始する時がきましたが、最初に起こったのは、curlコマンドを実行して「内部エラーがあります、ここに問題があります」というメッセージが返ってきたことです。ここで選択肢がいくつかあります。AWSコンソールに行き、ロググループを調べ、CloudWatchを検索してみて問題を検出する方法もありますが、IDEに留まりながらそれを行う方法がないか、Qに聞いてみることにしました。
基本的に「AWS SAMを使用してログをtailする方法はありますか？」とQに尋ねたところ、SAM log CLIコマンドを使用できると教えてくれ、実行するコマンドも提供してくれました。そのコマンドを実行すると、そのLambda関数からのロググループの末尾が表示されます。
上にスクロールすると、実際のエラーが何であるかが非常に明確です。アクセス拒否例外があり、Bedrockのモデル呼び出しを実行する権限がないと表示されています。ここでも、非決定論的であり、毎回完璧なコードを生成することは保証されていないことを示しています。そのコードをデバッグして修正することは非常に重要です。
ここで必要なことは、権限がCloudFormationテンプレートのYAMLファイルで適用されていることを知っているので、ログからエラーメッセージを選択し、リソースとして定義されているSummary関数を選択します。再度コマンド+Iを押してインラインチャットを開き、「このエラーを修正して、Bedrock invoke modelを呼び出す権限があることを確認してください」と依頼することができます。私が通常行うのは、そのエラーメッセージを貼り付けることです。
これにより差分が生成され、特定のファウンデーションモデルに対するBedrock invoke modelを許可するポリシーが追加されました。これを受け入れてデプロイすることができます。今回はログに別のエラーメッセージが表示され、Bedrockの呼び出し方法に関する検証エラーがあります。
再び同じプロセスで、Lambda関数を選択し、呼び出していることがわかっているコードを選択し、インラインチャットに入り、「このエラーを修正して」と言ってログからのエラーメッセージを貼り付けます。これにより再び差分が生成され、受け入れることができます。
これでさらに進みましたが、まだレスポンスにいくつかのエラーメッセージが表示されています。ここで、もっと多くのログステートメントを取得する必要があることに気づきました。Lambda関数全体を選択して「この関数にログステートメントでインストルメント化してください」と依頼するだけです。戻ってくるレスポンスもログに記録したいと伝えます。
これにより差分が生成されます。通常なら、Lambda Power Toolsなどのロギングライブラリを使用するでしょうが、今はプロトタイプなので単にコンソールログステートメントを使用しています。これが返ってきたら、curlコマンドを再度実行すると、Bedrockからのレスポンスが実際に返ってきていることがわかります。
問題は戻り値の方法にあります。コードを選択して、Bedrockから返されるJSONメッセージ全体を選択し、インラインチャットに入り、「このJSONメッセージからtextアトリビュートだけを返したい」と伝えるだけです。このようにコードとチャットし、コードベースにまだ内在する小さなレイヤーやバグを修正するよう依頼できます。
これがコードを修正し、その変更を受け入れ、保存してもう一度SAM deployを実行できます。今回テストすると、完全に機能するバックエンドAPIが手に入ります。このようなインタラクティブなデバッグと修正プロセスにより、開発サイクルが大幅に短縮され、問題の診断と解決が効率化されます。
10.4. Reactフロントエンドの開発と改善
課題は今度はフロントエンドを構築することです。私はフロントエンドエンジニアではなく、私を怖がらせるものの一つです。「フロントエンドをどのように構築するか」を考え始めました。ここでも、チャットから始めて基本的な質問をします。「AWSで最も人気のあるJavaScriptフレームワークは何ですか？」というように、ウェブフロントエンドを構築したいと思っています。
いくつかの選択肢が返ってきます。Angular、Vue、Next.jsなどがあり、最初に返ってきたのがReactでした。そこで「ReactのUIを構築しよう」と思いました。「Reactウェブアプリケーションを作成する最も簡単な方法、最も簡単な方法は何ですか？」と尋ねると、create-react-appのようなコマンドを使用できると教えてくれました。
これにより本質的にプロジェクトをブートストラップし、必要なすべてのパッケージと依存関係を持つスタートプロジェクトを作成できます。そのコマンドを実行し、プロジェクトを指定して、すべてのパッケージをインストールし、依存関係をインストールして、Reactフロントエンドを稼働させることができます。
作成されたばかりのプロジェクトに移動し、npm startを実行して開発サーバーを起動できます。これは素晴らしいことで、Reactフロントエンドができましたが、明らかに私が本当に望む見た目ではありません。
次に開発者エージェントに入り、同様なプロンプトを使用します。2つの部分があります。最初の部分では、URLを貼り付けるためのテキストフィールドを持つホームページ、「要約」というボタンをクリックしてエンドポイントをターゲットにし、レスポンスが戻ってきたら下に表示するという指示を与えます。
プロジェクト要件として、READMEの更新、依存関係の更新、package.jsonファイルの更新、ユニットテストの追加などを確認します。これを実行すると、変更の概要が返ってきます。今回はREADMEの更新があることがわかります。依存関係をインストールして、もう一度npm startを実行する必要があることを教えてくれます。
npm installまたはnpm iを実行して依存関係をインストールします。npm startが開発サーバーを起動し、アプリケーションが更新されます。これにより完全に機能するウェブフロントエンドが得られましたが、望む見た目ではないかもしれません。
開発者エージェントをもう一度使用して、今度はスタイリングを少し改善したいと思いました。CSSやスタイルシートについて何も知らないので、「テキストボックスをもっと広くしてください。側面に余白が欲しい。そんなに広がってほしくない」というように基本的に依頼しました。また、レスポンスをクリアする方法がわからなかったので、クリアボタンも追加したいと依頼しました。
これをプロンプトとして渡して実行すると、Q開始が分析し、開いているファイルや変更する必要のあるファイルを把握します。スタイルシート、CSSファイル、フロントエンドに変更が必要だと検出します。
ステップごとに進み、すべての要件を満たしたと判断すると、変更されたファイルのリストが表示されます。スタイルの変更とapp.jsの変更が行われていることがわかります。新しい依存関係は追加されていないので、もう一度npm startを実行するだけです。
今度は更新され、はるかに見栄えの良いものになります。URLを入力し、要約をクリックすると、下に記事の200語の要約が表示されます。クリアをクリックすることもできます。これにより、ロゴを追加したり、色を変更したり、他の変更をしたりする場合でも、自信を持って対応できます。CSSを学ぶ代わりに、Q Developerを使用してフロントエンドをカスタマイズできます。
10.5. プロンプトテンプレートを活用したプロジェクト構築
これらの例を進める中で気づいた最後の点として、個人エンジニアとしての私向けのパーソナライゼーションファイルは良かったですが、スクワッドのエンジニアリングリードとして働いている場合はどうなるでしょうか？全員が「常にユニットテストを更新し、常にREADMEを更新し、常にコメントを追加する」などといった長いプロンプトを渡す必要はないと思います。
Q Developerを使用したプロンプトテンプレートを作成する方法はないかと考え始めました。これにより、要件ファイル内にこれらすべてを指定できるかどうかを検討するようになりました。基本的に要件を記載したマークダウンファイルを作成し、そこにすべてを追加しました。
そして開発者エージェントへのプロンプトを作成するときには、「要件マークダウンファイルに記載されているように、すべてのコードを含む完全なAWS CDK実装を作成してください」という具合にビジネスロジックを指定するだけです。この要件マークダウンファイルには、作成したいアプリケーションを示すMermaid図も含まれています。
これが処理され、すべての変更の概要が表示され、ファイル構造全体と私が単に受け入れるだけの新しいファイルが作成されます。戻ってきたら、試してみることにしました。まず「CDK synth」を実行し、次にアカウントをブートストラップするために「CDK bootstrap」を実行します。これはこのために設定した一時的なAWSアカウントです。その後「CDK deploy」を実行できます。これによりスタック全体がデプロイされます。
デプロイに問題はなく、スタック全体がデプロイされます。清算して、動作するかテストを開始できます。今回はcurlコマンドを実行してみました。最初はアクセス権限エラーが出ましたが、テンプレートYAMLファイルと同様に、これはCDKスタックを定義するPythonファイルで定義されていることを知っていました。
そのファイルを開き、すべてのコードを選択してインラインチャットに入り、「このエラーを修正してください」と依頼するだけです。素晴らしいことに、Q Developerはインラインチャットで、すべてのLambda関数の権限を更新する必要があることを認識していました。差分として生成され、それを受け入れることを選択します。
受け入れた後、もう一度「CDK deploy」を実行できます。画面をクリアし、CDK deployを実行すると、新しい権限がLambda関数に適用された新しい変更がデプロイされます。ここからcurlコマンドを実行すると、今度はDynamoDBに書き込まれたアイテムが表示されます。そのアイテムIDを取得して、アイテムIDでGETリクエストを実行し、取得できるか確認できます。これは機能します。
これには本当に驚かされました。プロジェクトをブートストラップするために使用しているのは要件ファイルとアーキテクチャ図だけなのです。数週間前に同じプロセスをTerraformで行うブログ記事を書きました。これがインフラストラクチャコードの生成、CDK、Terraform、CloudFormationを使用した自動デプロイの作成においていかに強力であるかがわかります。
このアプローチにより、開発者は最初からコードを書くのではなく、高レベルの要件やアーキテクチャ図から始めることができます。これは特に新しいプロジェクトの立ち上げ時や、標準的なアーキテクチャパターンを複数のプロジェクトで再利用する場合に非常に効率的です。プロンプトテンプレートを使用することで、チーム全体で一貫した方法でコードを生成でき、開発の一貫性と品質を向上させることができます。
11. まとめと今後の展望
11.1. Amazon Q Developerの多様な活用法
最後に、私のキーとなる提言をいくつか紹介します。まず最初に、機能を探索してみてください。Amazon Q Developerをコードを生成する方法としてだけ考えないでください。現在、5つのエージェントがあり、ユニットテストの生成、ドキュメントの生成、アーキテクチャ図と視覚化の生成が非常に強力だと思います。
また、図からインフラストラクチャコードを生成することも強力です。基本的なアーキテクチャに関する質問をするためにも使用してください。これを行う正しい方法は何ですか？それを行うAWSサービスは何ですか？AWSのベストプラクティスは何ですか？そして、コード生成に関しては、プロンプトエンジニアリングが非常に重要です。
これは遊ぶ価値のあるものです。そして私にとって、将来の道筋としては、これらのプロンプトテンプレートを作成できる方法が見えています。そうすれば、新しいプロジェクトを作成する必要があるときは、プロンプトテンプレートでブートストラップでき、生成されるコードの一貫性を得ることができます。
そして最も重要なのは、私が最初に言ったように、今日示したこれらすべてのこと、5つのエージェント、さまざまなヒントとコツなど、それらすべてがAmazon Builder IDでサインアップすることで、Q Developerを無料でお試しいただけます。だから、ぜひ構築してみてください。
この機能の多様性は、開発プロセス全体を通じてQ Developerがどれほど価値を提供できるかを示しています。単なるコード生成ツールではなく、コードの理解、可視化、変換、テスト、セキュリティチェックなど、開発ライフサイクル全体をサポートする包括的なツールとなっています。これにより、開発者はより少ないリソースでより多くを達成し、より高品質なソフトウェアをより迅速に提供できるようになります。
11.2. プロンプトエンジニアリングの継続的な改善
コード生成においては、プロンプトエンジニアリングが非常に重要です。これはぜひ試してみる価値があります。私たちは「説明なし」というシンプルなフレーズを追加するだけで、出力が大きく変わることを見てきました。このようなプロンプトの微調整は、Q Developerから得られる結果の質と関連性を大きく向上させることができます。
効果的なプロンプトを作成することは、AIコーディングアシスタントを使用する際の重要なスキルです。うまく構成されたプロンプトは、望ましい結果を得るための鍵となります。明確な指示、具体的な要件、そして期待する出力形式を指定することで、生成されるコードの質を大幅に向上させることができます。
プロンプトエンジニアリングは継続的な学習プロセスです。異なるタスクには異なるプロンプト戦略が効果的である場合があります。時間をかけてさまざまなプロンプト技術を試し、特定のユースケースに最も効果的なアプローチを見つけることが重要です。
また、プロンプトテンプレートを作成し、チーム内で共有することで、組織全体でのベストプラクティスを確立できます。これにより、チームメンバー全員が一貫した高品質な結果を得ることができるようになります。プロンプトエンジニアリングへの投資は、AIコーディングアシスタントから最大の価値を引き出すための重要なステップです。
11.3. プロンプトテンプレートの将来性
私にとって、将来の方向性として見えてくるのは、プロンプトテンプレートを作成できる方法です。これにより、新しいプロジェクトを作成する必要がある場合、プロンプトテンプレートを使ってブートストラップし、生成されるコードに一貫性を持たせることができます。
このアプローチの可能性は非常に大きいと考えています。個人の開発者がパーソナライズしたプロンプトを使うことは素晴らしいことですが、チームやエンタープライズレベルでは、標準化されたプロンプトテンプレートがさらに大きな価値を提供できるでしょう。
例えば、組織のコーディング標準、エラー処理のアプローチ、ログ記録の戦略、セキュリティベストプラクティスなどをすべて組み込んだテンプレートを作成できます。新しい開発者がチームに参加した場合でも、これらのテンプレートを使用することで、すぐに組織の基準に合ったコードを生成し始めることができます。
また、異なるタイプのプロジェクトに対して異なるテンプレートを用意することもできます。マイクロサービス用のテンプレート、ウェブアプリケーション用のテンプレート、ETLジョブ用のテンプレートなど、それぞれのユースケースに最適化された設定を提供できます。
将来的には、これらのテンプレートをバージョン管理し、組織の知識リポジトリの一部として扱うことで、チーム全体の生産性を向上させる強力なツールになるでしょう。プロンプトテンプレートは、AIコーディングアシスタントを組織の開発プロセスにより深く統合するための重要な架け橋となる可能性があります。
11.4. 無料トライアルの案内とリソース紹介
最も重要なのは、冒頭でもお伝えしたように、今日ご紹介したすべてのこと、5つのエージェント、さまざまなヒントとコツ、それらすべてがAmazon Builder IDでサインアップするだけで、Q Developerを無料でお試しいただけるということです。ぜひ構築してみてください。
役立つリソースもいくつかあります。Amazon Q Developerの変更ログがあり、ここ数日でかなり更新されているはずです。また、シニア開発者アドボケイトのNathanが提供するヒント集もあります。Massimoが書いた興味深いブログ記事も、DIYパーソナライゼーションに関するものも含めてあります。
また、AWSコミュニティビルダーのChristianは、Amazon Q Developerに関する記事やヒント、コツのキュレーションリストを維持しており、これに目を通しておくと役立ちます。
このようなリソースは、Q Developerの最新機能や使用方法を学ぶのに非常に役立ちます。特にこのツールは急速に進化しているため、常に最新の情報を把握しておくことが重要です。コミュニティの知識を活用することで、より効果的にツールを使用する方法を学び、自分自身の開発プロセスを向上させることができます。