 本記事は 夏休みクラウド自由研究2025 8/30付の記事です。 |
私生活と趣味の分野でしか利用していなかった AI がどんどん進化してきて仕事にも使うようになり、ますます AI まみれになってきている兒玉 (コダマ)です。
今回は、 Amazon Q Developer を使い始めて、使い始める前の想像以上に「できる」と感じました。皆様にもオススメできるようなAI支援ツールになっているので、ぜひ使っていただきたいな、との思いを込めて、今回はその楽しいやり取りをご紹介します。
… こんな書きっぷりだと、いかにも自分が開発したかのように見えますが、私は Amazon Q Developer の開発担当者ではありません。皆で Amazon Q Developer を使って仕事を早く片付けて、一秒でも早く私が仕事から開放されてゲームができるようになるといいなぁ、と、思っているだけです。あしからず。
急に必要になった
急に、「AWSのサービスの料金テーブルがほしい！」と思い立ちました。（何故かとかはもちろんあるのですが、まぁ、この一文は言ってみれば、異世界モノの小説の導入部みたいなものだと思ってもらえればよいです。）
ちょっと調べると、なるほど、料金表ファイルがダウンロードできるとのこと。
サービス料金表ファイルの読み取り AWS のサービス
よし、ダウンロードしたぞ！ サイズみてみるか！
$ ls -la
total 5073152
drwxr-xr-x. 2 ec2-user ec2-user 16384 Aug 25 12:59 .
drwxr-xr-x. 3 ec2-user ec2-user 16384 Aug 25 15:12 ..
-rw-r–r–. 1 ec2-user ec2-user 4895685924 Aug 25 12:59 202507_priceListApi-ec2.csv
-rw-r–r–. 1 ec2-user ec2-user 19855825 Aug 25 12:59 202507_priceListApi-elasticache.csv
-rw-r–r–. 1 ec2-user ec2-user 17764101 Aug 25 12:59 202507_priceListApi-es.csv
-rw-r–r–. 1 ec2-user ec2-user 260484159 Aug 25 12:59 202507_priceListApi-rds.csv
-rw-r–r–. 1 ec2-user ec2-user 1081325 Aug 25 12:59 202507_priceListApi-redshift.csv
$
私
え！ 4.8GB？！ とても Excel なんかじゃ開けないじゃん…
？？？
なにを困ってるのよ。私に任せなさい。
私
え、あんただれ？
Amazon Q
私はAmazon Q よ（※1）
ということで、Amazon Q （Qちゃん）が手伝ってくれることになりました。
ファイルDBにしよう
AWS の Pricelist の CSV ファイルが大きすぎて Excel や テキストエディタなどで表示するのがしんどいので、データベースにいれることを思いつきました。ただ、Amazon RDS を使うというのも大げさなので、ローカルファイルで利用できるデータベースがいいなと考えたようです。
私
ローカルファイルで利用できる Database にはどんなものがあるの？
Qちゃん
SQLite、LevelDB、TinyDBなどがあるわよ。おすすめはSQLiteね。
SQLiteの特徴:
– ファイルベースで設定不要
– ライブラリサイズが約600KB
– ACID準拠でトランザクション処理をサポート
– 読み取り専用での優秀な性能
– Python標準ライブラリで利用可能適用場面の分析:
– ✅ 最適: デスクトップアプリ、バッチ処理、データ分析
– ❌ 避けるべき: 高頻度同時書き込み、大規模マルチユーザーうんぬんかんぬん…
「Amazon Q」というサービスだからといって、AWSに関することのみにしか答えないというわけではないようですね。Qちゃん面倒見がいいですね…
プライマリキーを作成しよう
データベースなので、プライマリーキーが有ったほうがいいだろうということで、プライマリーキーの選定を行います。
先程の AWS のサービス料金のページでは、どれがキー候補としてふさわしいのかについては記載がありません。適当に項目名から候補を選びます。
私
うーん、AWSの公式ページにはどれがキー候補とか記載がないなぁ。”usageType” と “operation” あたりでどうだろうかなぁ？
Qちゃん
ちょっと待ちなさいよ！ 私の方でコマンドで実際のファイルを見て検証してあげるから。コマンド実行してもいいわよね？(※2)
… うーん、cut -d で分けた項目名行と実際のデータの項目数が合わないわね… 別の方法も試してみるかしら。
私
（なんか苦戦してるなぁ (※3) ）ああ、CSVファイルといっても、ひょっとしたらカンマを含むデータもあるだろうからダブルクォートで囲ってあるデータがあるのかもしれない。
Qちゃん
そ、そうかもしれないわね！ ちょっと確認してみるわ。
… (別のコマンドを実行）…
確かに引用符で囲われてるデータがあるわね！
Python で解析し直してみるわ。
Python ファイルを作成したのだけれど、あなたのところの 一時ファイル領域を使ってもいいかしら？ (※4）
え？ あ？ いいけど？
Qちゃん
usegeType + operation だと駄目ね、料金体系（Reserved/OnDemand）、期間、リージョン違いなどで複数行存在するわ。SKU だとどうかしら。
私
（SKU っていう値記号みたいな値だから重複してそうなのかよくわからないんだよなぁ。でも “2223B6PCG6QAUYY6” とかIDっぽい感じだし重複しないのかな？）じゃぁ、SKUをプライマリキー候補にするかな。プライマリキーとして成り立つか、重複していないかどうか実際の料金ファイルを調べてみて？ (※5)
Qちゃん
SKUの重複がないか確認してみるわ。
… SKUは大量に重複してるわね (※6)
… SKU + OfferTermCode + RateCode なら 総行数: 7,141,017行、ユニーク複合キー数: 7,141,017個、重複数: 0個 で 完全に一意ね！
私
（あっぶな！騙されるところだった）
Qちゃん、真面目なのですが、ちょっとおっちょこちょいのようですね。
データ型を検討しよう
CSVファイルの情報をデータベースに格納するにあたっては、各カラム（列）の データの型として、整数値なのか、小数を含む実数なのか、それとも テキストデータなのか を適切に判断して設定する必要があります。
先のAWSドキュメントにはごく一部の項目についての説明しかなかったため、当然型についても記載がありません。拠り所は ダウンロードしてきた 料金表ファイルの CSV ファイル のみという状況です。
私
じゃぁ、次は各項目名に対応する型を決めよう。
Qちゃん
CSVファイルの内容をPythonプログラムで分析してみるわね。
… … …
わかったわ
`INTEGER` – 整数（vCPU、StartingRange、EndingRange）
`REAL` – 浮動小数点（PricePerUnit、ECU）
`TEXT` – 文字列（残り大部分の項目）
ね
私
（あれ？ ECS だと vCPU は 0.25 とか 0.5 とかも有ったんじゃなかったっけ？EC2 は整数のみ？(※7)）vCPU 列は 0.5 とかもない？ ちょっとサイズが大きいけど EC2 の料金表CSVファイルで確認してみて。
Qちゃん
たしかにそうよね (※8)。ちょっと確認してみるわ。
… … …
t3.micro でも vCPU は 2 ね。やっぱり vCPU は整数よ。
“Normalization Size Factor” という列があって、そっちには 0.25 とか 0.5 とかの値もあるから実数値の項目ね。そっちと勘違いしたんじゃない？
私
（！？混乱してきた？！）AWSの公式ドキュメントで、 vCPU とその “Normalization Size Factor” という列について調べてくれない？
Qちゃん
任せて！ こういうときのために私には “MCP サーバー” というスキルがあるのよ！（※9）
“AWS Price ListのvCPUとNormalization Size Factorの意味を公式ドキュメントから検索せよ！ aws___search_documentation” ッ！
Qちゃん
ドキュメントのページには載っていなかったけど、AWS公式Blogで見つかったわ。(※10)
Normalization Size Factor は、 Reserved Instances(RI)で使用される正規化係数のようね。簡単に言うと、nano=0.25, micro=0.5, small=1 … xlarge=8 … のようにあらかじめ決められていて、コンバーティブル RI を利用している際に適用する際の計算の係数になるようね。vCPUとは関係なさそうよ。
私
(はえー、MCPサーバースキルすごいなぁ。)
データベースの完成
プライマリキーの問題や、データ型の問題を解決した 私と Qちゃんはいよいよデータベースを作成します。
私
（よし！ これで準備は整った！）料金表CSVファイルから SQLite のデータベースを作成して！
Qちゃん
まかせて！
… … … … …
５分くらいかかったけど、できたわ！
EC2: 6,613,155行
RDS: 443,009行
Redshift: 2,580行
ElastiCache: 0行（列数不足でスキップ）
ES: 0行（列数不足でスキップ） よ。
ちゃんとSQLで検索できるのも確認済みよ！（どやぁ）
私
（5分で7百万件処理したのかよ！すっげぇ！ でも、スキップしちゃってるのにどや顔してるQちゃん ポンコツかわいい …じゃなくて！）え、なんで ElastiCache と ES は 0件なの？ 列不足ってなに？
Qちゃん
調べてみるわ… うーん、ElastiCache と ES ファイルは、EC2 や RDS と比べて列数が少ない固有の構造のようね。でも、こんなものは今までの問題と比べたら簡単よ！ ちょっと直して実行してみるわね。
… … 列不足についての修正完了 … もう一度データベース作成 …
6分でできたわ！
✅ EC2 : 6,613,155行
✅ ElastiCache: 43,125行 (解決！(※11))
✅ ES: 39,148行 (解決！)
✅ RDS: 443,009行
✅ Redshift: 2,580行
よ！ これで解決ね！
おわりに
こんな感じで、チャットで会話のやり取りをしながらツールを開発していくことができます。なんとなく雰囲気を感じることができたでしょうか？
本来なら、作成された後の データベースについて、さらなる検証が必要（本当にその件数でいいの？とか、入っているデータは正しいの？など）なのですが、それはこのBlogの外で行ってると思ってください。
実際にこの作業中、私自身はコードを１行も書くことなく、Qちゃんとの会話や回答内容から Go / Stop / OK / NG と 提案しているだけで、ツールとデータベースが形になっていっています。こういう事ができるとなると、すぐに「では、ソフトウェア開発者は不要か？」ということを想像する方々もいらっしゃるかもしれません。しかし実際はそうではなく、コードはきちんとできているのか？ それはどう問題がないと確認したのか？ 報告してきた内容に嘘はないか？ 嘘がないことをどう裏取りや検証するのか？ など、プログラマの立場ではなく、プロジェクトマネージャのような立場での振る舞いを要求されていることを実体験から得ています。個人的に使うような簡単なツールなどであればともかく、信頼性の必要な業務システムにおいてはソフトウェア開発の知識や経験は依然必要であり、ソフトウェア開発者は依然として必要とされることがわかると思います。ソフトウェア開発者という立場がなくなるのはまだまだ先のようです。
と、いうわけで、最後はこの言葉で締めたいと思います。
「私とQちゃんの旅はまだまだこれからだ！」（作者の次回作にご期待ください。）