上流工程でも！開発の各フェーズでAmazon Q Developerはどう使えるか？
シフトレフトにも有効……というだけあって、Amazon Q Developerは実装フェーズ以外、アイデアや企画などの上流工程でも使えます。セッションでは開発工程を「Plan」「Create」「Test ＆ secure」「Operate」「Maintain & modernize」の5つのプロセスに分けて、使い方について解説がありました。
●Plan
システムを改修したい、新しいシステムを構築したい、というときはセキュリティを考慮しながら新しいアーキテクチャを検討しなければなりません。Amazon Q Developerだと会話ベースで確認しながら、ベストプラクティスを模索できる、ということですが、特にすごいのは、Amazon Q Developerが自社アカウントのコンテキストを理解しながら会話してくれるということ。すでに起動しているEC2インスタンスやコンテナ、AWS Lambdaの状況などを踏まえて、新しいアーキテクチャをどうすればよいかを提案してくれるというのは、かなり魅力的だなと思いました。
●Create
続いては実装フェーズですが、ここもエージェントと会話しながら作業できます。このあたりは前回のコラム（GitLabとAmazon Qで開発はどう変わる？気になる導入効果をレポート）でも紹介したところですが、おもしろいなと思ったのは、「既存コードの全体像把握にも便利ですよ」というあたり。本来は、各コードにつけられたReadMeを読んだりして全体を把握して開発するわけですが、ReadMeが必ず最新とは限らず、現状とは乖離していることもありがち……というわけで、Amazon Q Developerを使ってGitリポジトリの概要を生成させたりもできるのだとか。セキュリティに直結する感じではないかもしれませんが、「古い情報を参照してコーディングしていた」といった事態はなくせそうですし、きちんと最新の状況を踏まえて開発できるのは、リスクを避けるためにも結構大事なところなのかも、という印象です。
●Test & secure
Amazon Q Developerのレビュー機能、というのは前回コラムでも触れましたが、ここでセキュリティ観点でのチェックも可能です。コードスキャンをおこない、致命的なクラッシュを起こすものから、「for文が多くて分かりにくい」のようなものまで指摘してくれるのだとか。セッションでは例として、ログインジェクションのリスクがあるコードが指摘されているケースが紹介されていました。Amazon Q Developerでは問題点の説明として、どのようなリスクがあるかとあわせて、コードの修正案（エスケープしてログインジェクションを回避する）まで提示されていて、この修正案に問題がなければFIXを選んで終了です。
ちなみにこのセキュリティチェックの裏側で動いているのが、「Amazon CodeGuru Security」。これは、コードの脆弱性を可視化する静的アプリケーションセキュリティ検査（SAST）ツールで、たとえば「機密情報がコードに記載されている」みたいなことも検知できる、ということでした。
●Operate
運用は大きく2つのテーマがあり、まずはデプロイに失敗したときのトラブルシューティングに使えますよというもの。
もうひとつは、運用調査機能として、運用中にトラブルが発生したときに、Amazon CloudWatchと連携して根本原因を分析して、教えてくれる機能があります。ログをひとつずつチェックして、怪しいところを深堀調査してとか、必要とはいえ結構手間がかかるので、Amazon Q Developerである程度、目途をつけられるなら、かなり便利そうです。
●Maintain ＆ modernize
ここで紹介されたのは、「AWS Transform」というサービスでして、これはモダナイズをサポートするエージェント型AIサービス。Amazon Q Developerじゃないじゃん！という感じではあるのですが、AWS Transform自体は基調講演でも触れられていて、たぶん今注目のサービスなのかと思われます。
具体的には、言語のバージョンアップや、フレームワークのモダナイズができる、ということで、確かに新しいものを使った方がセキュリティリスクも減らせるとはいえ、地道に変換するのはなかなか厄介、ということでそこを生成AIでよしなにやってくれるなら、それはぜひお願いしたいところ。「開発者が競争力を生むための作業ではない部分を支援する」と言っていて、それもおもしろいなと感じました。
コードの脆弱性診断も継続的にチェックする「Amazon Inspector」
……と、ここまで開発ライフサイクルの各フェーズでセキュリティをどう担保するかを解説してきましたが、それとは別に、開発が完了したコードが本当に安全なのかを“継続的に”チェックする必要もあります。
ちょっと前になりますが、かなり使われている有名なライブラリに致命的な脆弱性が見つかって、結構な騒動になったのを覚えていますが、新しい脆弱性は次々見つかるものですし、見つかったらきちんと対応して、「ソフトウェアがセキュリティ要件を継続的に満たしている」状態を担保しなければなりません。
そしてそのために使えるのが、Amazon Inspectorです。Amazon Inspectorは確かに脆弱性診断のサービスとは思っていたのですが、コードの脆弱性まで診断してくれるとは……！Amazon EC2、AWS Lambda、Amazon Elastic Container Service（Amazon ECS）、Amazon Elastic Kubernetes Service（Amazon EKS）などさまざまな環境で有効化しておけば、どのアカウント、どのリージョン、どのリソースで脆弱性があったのか、その重大性とあわせて可視化してくれるのだそう。もちろん、利用したいリソースだけオンにすることも可能ですし、それぞれモードがあったりするので、そのあたりは自社の環境や要件にあわせて検討するのがよいのかなと。
Amazon Inspectorの便利機能「SBOM（ソフトウェア部品表）の自動生成」
そしてもうひとつ！Amazon Inspectorの便利機能がSBOM（Software bill of materials/ソフトウェア部品表）を自動で作成できること！SBOMは、ソフトウェアでどんなライブラリを使っているかなどを依存関係含めて一覧化したもの。全体を把握するためにも重要……とはいえ、常に最新の状態を維持するのはなかなか大変。ライブラリに脆弱性が見つかったから、急遽それを使っている箇所を洗い出して！とか、そういうときのために更新しないといけないのは分かってる……分かってるんですけどねぇ。
と、それをAmazon Inspectorなら、アカウント単位でSBOMを生成できる、しかもAmazon AthenaやAmazon QuickSightでの分析もできると。こうなると検索して影響範囲の特定とかもかなりラクになりそうですし、相当便利なのではないでしょうか。
生成AIをうまく活用して、全員がセキュリティを意識できることを目指す
ソフトウェア開発でもセキュリティは大事なんて、重々承知ですが、セキュリティ対策的なところって、正直、あまり面白みがあるところではないような気がして（個人の感想です）、対処方法などもある程度定まっているものではありますし、こういうところはどんどん生成AIに任せられるといいのかなと思いました。
今回のセッション自体は、ライフサイクル全体でいろいろ活用できるよという紹介ではありましたが、まとめとして「全部いきなりやるのではなく、肝になるところからやるとよい」というメッセージもありました。「“ツールを入れたから安心”ではない。たくさんエラーが検出された結果、無視、というのもよくあるが、それでは対策できたとは言えない」とのことで、なんだか耳が痛い……。「生成AIで理解しやすい環境にしながら、セキュリティは全員の責任であるという理念に向けて踏み出す一歩になれば」ということで、生成AIはあくまでもツール、それをどう使って、使う人がどう考えていくかが重要になるのだと改めて感じました。
次回は少しテーマを変えて、Amazon Connect周りの生成AI活用について、紹介したいと思います。
