誰でも使いこなせるAmazon Q Developer [後編]学習用データ可視化アプリケーション作成
Amazon Q Developerの実践的な活用方法を知りたい方へ、いよいよ連載の後編です。本記事では、Spotifyの再生履歴データを可視化するダッシュボードアプリを題材に、Amazon Q Developerを使ったアプリケーション作成の流れを詳しくご紹介します。AIへの具体的な指示方法や、人間が確認・判断すべきポイントも解説します。
はじめに
こんにちは、JTPのAWSエンジニア、太田です。「誰でも使いこなせるAmazon Q Developer」の後編ということで、実際にAmazon Q Developerを利用しながらアプリケーションを作成する過程をご紹介していきます。
この記事で分かること
アプリケーション作成の事例を通じて、
- AIへの指示の出し方
- AIを使う際に人間が確認・判断すべきポイント
この2点をイメージできる内容となっています。
今回の記事は3本立ての後編となります。前編、中編の内容を理解している方向けの内容となりますので、まだ前編と中編を読んでいない方はこちらのリンクからぜひご一読ください。
- 後編: 学習用データ可視化アプリケーション作成
作成するアプリケーションについて
今回は題材として、Spotifyの再生履歴データを可視化するダッシュボードを作成してみます。
この題材を選んだ理由は、データ分析について知見を深めるためです。ここ数年でAIが広く普及し、業務に取り入れている企業も増えてきているかと思いますが、ただAIに「利益を増やすにはどうしたらいい？」と聞くだけではあまり有効な答えは返ってきません。実情に即した回答を生成させるためには、データを蓄積し、AIが理解できる形に整えたうえでAIに質問する必要があります。
このデータの事前準備にあたるのがいわゆる“データエンジニアリング”と呼ばれる領域です。データソースから情報を取得し、最終的なゴールに応じた加工を行ってデータを出力する、という一連の流れを個人レベルで体験できる例として、Spotify APIから取得できる再生履歴データを利用してみます。
ただ再生履歴の情報を保管していくだけでも、加工方法によっては「一番再生回数の多い曜日はいつか」「一日の中で一番音楽を聴く時間は何時か」といった情報を得ることができます。ビジネスに置き換えれば「一番来客数が多い曜日はいつか」「売上が一番低い時間は何時か」といった情報になるわけで、これらのデータを活用しない手はありませんよね。
今回はAIではなく人間が利用するため、グラフ化してダッシュボードを作るところを目的とします。自分自身がコードを書くことなく、どれだけ価値のあるダッシュボードを作ることができるのか。ぜひ最後までご覧ください。
序盤（構成検討～プロトタイプ版作成）
今回作成するアプリケーションの内容は上記の通りですので、Amazon Q DeveloperにはこのアプリをAWS上で実行するための環境を考えてもらうところからお願いします。
＜入力した内容＞
AWSの学習のために、個人用のアプリケーションを作成したいです。
作成するアプリについて
SpotifyのAPIから、個人の再生データを取得し、直近1週間の再生データを元に「Spotifyまとめ(ミニ版)」のようなものを作る。 取得したデータは可視化できるようにする。
質問
この機能をもつアプリを作成するには、どのようなサービス/ツールが必要か？
＜出力された内容＞
AWS学習用のSpotify再生データ可視化アプリを作成するために必要なサービス/ツールをご提案します。
必要なAWSサービス
バックエンド
フロントエンド・可視化
認証・セキュリティ
監視・ログ
技術スタック
フロントエンド
バックエンド
アーキテクチャの流れ
学習ポイント
このアプリケーションを通じて、AWSの主要サービスを実際に組み合わせて使用する経験が得られます。
さっそく、利用するサービスの一覧を考えてくれました。
この出力を見た瞬間、私は「思っていたより使うサービスが多いな…」と感じたのですが、利用者の規模やセキュリティ要件などをプロンプトに含めていなかったのが原因です。こういった認識のずれは人間が指摘しないとそのまま進んでしまいますので、自分が気付いたタイミングで「ここはこの要件に変えてください」とお願いしましょう。
この後数回やり取りをして構成を固め、試しにCDKコードを作成してもらうところまでお願いし、最終的に以下のような構成になりました。
＜入力した内容＞
今作成したリソースのアーキテクチャ図を書いてください。
＜出力された内容＞
Mermaidを使用してSpotifyアプリのAWSアーキテクチャ図を作成
architecture.md +84-0
Spotifyアプリのアーキテクチャ図を作成しました。
アーキテクチャの特徴
フロントエンド層
API層
データ層
自動化
このアーキテクチャにより、個人利用に最適化された低コスト・高可用性のアプリケーションが実現できます。
（Amazon Q Developerが作成してくれたMermaidの図）
いかがでしょうか。
先ほど、構成検討をお願いした際の回答では「どのサービスを何のために使うのか」「何と何が繋がっているのか」というのがイメージしづらかったかと思いますが、このようにMermaidで図を書くようお願いすると非常に分かりやすい図を作成してくれます。
CDKコードを作成した後に構成図を書いてもらうという、普段開発を行わない私の段取りの悪さが露呈してしまいましたが（笑）、次に進めていきましょう！
中盤（バグを修正する過程）
AWSリソースを作成するCDKコードは作成してもらっているので、あとはエラーを解消しながら動作するところまで持っていきます。CDKでリソースをデプロイし、Spotify APIの設定も終えるとAIからこんな回答が。
実装が完了しました！以下のコンポーネントを作成・デプロイしました：
作成したコンポーネント
Lambda関数
フロントエンドアプリ
アクセス方法
CloudFront URL: https://xxxxxxxxxxxxxx.cloudfront.net
次のステップ
現在はデモ用の実装ですが、基本的なアーキテクチャとUI/UXは完成しています。
この言葉を信じてリンクを開くと、
うーん、明らかに上手くいってなさそう。とはいえどこから見直したらよいか分からないので今の状況を伝えてAIに直してもらいます。
＜入力した内容＞
ページを開いてみましたが、"エラー: Failed to fetch"というメッセージが出ました。これはなぜでしょうか。
（Amazon Q DeveloperがAWS CLIのコマンドを実行し、API Gatewayのログを取得している様子）
回答
🔧 エラーの原因
Node.js 18ではaws-sdkが標準で含まれていない
✅ 解決済み
🎯 現在の状況
CloudFront URL: https://xxxxxxxxxxxxxx.cloudfront.net
ページを再読み込みすると、テストデータを使用したSpotifyダッシュボードが表示されるはずです！
解決したようです！ログを元に原因を探る作業を人間が行うとかなり時間がかかってしまいますが、ログ調査を行いコードの修正が完了するまでには3分もかかっていません。
私がAmazon Q Developerを使ってみて感動したのがこの点です。AI開発支援ツールというとただコードを書いてくれるだけなのだろう、と思っていました。しかし、Amazon Q Developerはトラブルシューティングとその対応まで自動かつ短時間で行ってくれるので、圧倒的に効率化することができます。私が自力でやっていたら丸一日は費やしていたでしょう。
このように、Amazon Q Developer は実装支援だけでなく、ログ調査から原因特定、修正まで短時間で進められる点が大きな強みでした。
終盤（完成形になるまで）
CloudFrontのページを開けるようになったので、この調子でAmazon Q Developerに作業をお願いし続けます。
DynamoDBにデータが格納されない問題を直してもらい、
かと思いきやデモデータを格納する設計になってしまったので再度修正し、
Spotify API利用時の認証情報の設定について教えてもらい、
📝 手順4で置き換える値
必要な3つの値:
YOUR_CLIENT_ID
YOUR_CLIENT_SECRET
YOUR_AUTHORIZATION_CODE
📍 重要な変更点
🔄 実行例
curl -X POST https://accounts.spotify.com/api/token \
-H "Content-Type: application/x-www-form-urlencoded" \
-H "Authorization: Basic $(echo -n 'abc123:def456' | base64)" \
-d "grant_type=authorization_code&code=AQC1234567890&redirect_uri=http://127.0.0.1:8888/callback"
レスポンスから refresh_token の値をコピーして、手順5のSecrets Managerに保存してください。
ついに実際の再生履歴をもとにしたダッシュボードの作成に成功しました！
ここまでの所要時間はたったの1時間です。
開発経験のない私なら自力で完成させることすら難しいでしょうし、できたとしても数日は確実にかかります。それが1時間で終わってしまうというのはとてつもない衝撃です。
最後は認証情報の設定やデータの流し込みなど、人間が確認しながら詰める必要はありましたが、完成までの速度は非常に速いものでした。
データという切り口での余談
この事例の本質は、ダッシュボードを作れたことだけではありません。Amazon Q Developer を使うことで、データ取得から可視化、さらに活用アイデアの検討まで一気通貫で進めやすくなる点にあります。
このダッシュボードはグラフの数こそ多くありませんが、直近でハマっているアーティストや、日ごとの再生数が分かることで「自分の好きなアーティストの傾向」や「家にいる日か出かけた日ではどちらのほうが音楽を聴く時間が多いか」といった情報が分かるのではないでしょうか。ここからアクションにつなげるとしたら、外出先で音楽を聴くことが多いなら高級なイヤホンを買う、自宅で音楽をよく聴くならいいスピーカーを買う…といった判断材料になりそうですね。
また、これらの情報を元にAmazon Bedrockを利用してAIに情報を言語化してもらう、といったこともできるはずです。DynamoDBに蓄積されているデータを元に、再生数の多いアーティストTop5の情報を渡して自分がどういったジャンルが好きなのか、他に似たアーティストはいないか…などなど。
人間が「なんとなく」で理解しているつもりのことも、こうして可視化すると意外なことが見えてきます。今回こうして簡単に可視化が出来るということがご理解いただけたかと思うので、ぜひいろいろなデータを可視化する習慣をつけてみてはいかがでしょうか。
この事例から学ぶAIツールの使い方
非常に強力で便利なツールであるというのはお分かりいただけたかと思いますが、やはり完璧ではないというのも見えたかと思います。
- 想定していたより過剰な構成
- 本番データを格納するための修正中にデモデータの格納で完了としてしまう
こういった点は、AIのミスというより、人間が頭の中にあることを伝えきれていない、すなわち人間がAIを使いこなせていないことが理由かと思います。
つい「いい感じにしておいて！」と雑に頼みたくなってしまうかもしれませんが、効率的にAIを利用するにはきちんと指示を詳細に出すことをお勧めします。でないと余計な時間がかかってしまいますし、今度は人間が「何が誤りなのか」を言語化してAIに修正を依頼するという、難易度の高いタスクが発生してしまいます。
人間と違いAIはどれだけ誤りを指摘されても嫌な顔をしません。ですから、想定と違った出力があった際にはきちんと指摘したり、そもそもそういったことが起きないように指示をMarkdownで整理しておくといった習慣を身に着けると、より一層AIツールを便利に活用できるのではないでしょうか。
最後に
3本の記事に渡ってAmazon Q Developerの使い方をお伝えしてきましたが、使い方のイメージはついたでしょうか。
コードを書くだけではなく、ドキュメント作成、トラブルシューティングなど様々な用途で使えるAmazon Q Developer。課金していない状態でも今回作成したアプリ程度なら作れますので、ぜひ気軽に触ってみてください！
