こんにちは！

今回は、GeminiのカスタムGem機能を使って、「要件を話すだけでいい感じのAWS構成図を描いてくれるGem」を作ってみましたので、その紹介とプロンプトエンジニアリングの裏側を共有します。

AWSの構成図を描くのって、地味に時間がかかりませんか？

PowerPointやDraw.ioでアイコンを並べて、矢印を引いて、整列させて……。

「とりあえずたたき台が欲しい」「アイデアを可視化したい」という時に、チャットだけで図が生成できたら最高ですよね。

ということで、「AWS構成図イメージ作成Gem」 を作ってみました！

「AWS構成図イメージ作成Gem」について

機能

Geminiのチャット欄に「スケーラブルなWebサイト」や「サーバーレスな画像処理基盤」といった自然言語を入力すると、AWS公式アイコンを使った構成図画像をすぐに生成してくれます。

特徴

  • 公式アイコン準拠
    • 最新のAWS公式アイコンを使用。
  • クリーンなスタイル
    • 白背景で見やすいスタイル。
  • アーキテクト視点
    • ただアイコンを並べるだけでなく、VPCやサブネットなどの全体的な構成を考慮

Gemの知識学習

このGemが単なる「お絵かきツール」で終わらないよう、GemのKnowledge（知識源）として、以下のAWS公式ドキュメントやベストプラクティス集を学習させています。

  1. AWS Architecture Icons (最新版)
    • 最新のアイコンセット（Compute, Database, Storageなど）の形状やカラーコードを認識させ、適当な図形ではなくAWS公式のアイコンが出力されるようにしています。
  2. AWS Well-Architected Framework
    • 運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性の6つの柱に基づいた構成を提案させるため、アーキテクチャの評価基準としての知識を持たせています。
  3. Cloud Design Patterns (CDP)
    • 「Multi-AZ」や「Floating IP」といった定番の設計パターンを理解させることで、ユーザーが「可用性重視で」と言った瞬間に適切な冗長構成をイメージできるようにしました。
  4. SaaS Architecture Fundamentals
    • マルチテナント環境やSaaS特有の分離モデル（サイロ、プール）などの知識もインプットし、現代的なSaaS要件にも対応可能です。

これにより、Gemは単に図を描くだけでなく、「AWSのベストプラクティスに沿った構成」を意識して描画を行うよう調整しています。

プロンプトエンジニアリングの工夫

Geminiに意図通りの図を描かせるために、以下の3つのルールを徹底させました。

1. 役割の明確化 (ペルソナ)

単なる「お絵かきAI」ではなく、「熟練したAWSソリューションアーキテクト 兼 テクニカルイラストレーター」という役割を与えました。
これにより、構成の論理的な正しさ（アーキテクト）と、視認性の高さ（イラストレーター）の両立を狙っています。

2. ビジュアルルールの言語化

AIは放っておくと独自のカラフルな図を描きがちです。
そこで、以下のような制約をプロンプトに埋め込みました。

  • スタイル（クリーンで見やすく）
  • アイコン（AWS公式アイコンを意識する）
  • 配置（左から右へ、または上から下へ、データの流れがわかるように論理的に配置する）
  • 背景（白色）

特にアイコン指定は重要で、プロンプトに含めるまではAIが独自の謎アイコンを作成してしまうケースが頻発しました。

3. 「文字崩れ」への対策 (最大の課題)

Nano Banana Proになって大幅に改善されましたが、画像生成AIにとって「文字を含む画像」は苦手です。
複雑な説明文を入れると、謎の古代文字が生成されてしまいます。

そこで、「文字は最小限にする」というルールを設け、サービス名（EC2, S3など）のみの描写に留めるよう指示しました。

では実際に動かしてみます

以下の指示を出します

大量のデバイスから効率よくデータを収集してDynamoDBに保存して、Quicksightで可視化するアーキテクチャ図を作成してください。

10秒ほどで画像が生成されました！


処理中の思考プロセス

  • プロセスを日本語訳で見ると、以下のように処理内部でアーキテクチャの検討を進めてから画像を生成していることが分かります。

・建築ニーズの洗練
現在、コア要件である、多数のデバイスからデータを効率的に収集し、DynamoDBに保存してQuicksightで可視化することに注力しています。AWSアーキテクチャを検討しており、このデータフローを最適な方法で処理し、システムのスケーラビリティとコスト効率を確保する方法を模索しています。

・主要コンポーネントの特定
現在、主要なAWSコンポーネントを特定しています。MQTT経由のデバイスデータ取り込みにはAWS IoT Core、データスパイクのバッファリングと処理にはKinesis Data Streams、そしてデータの変換とDynamoDBへのロードにはLambdaを選択しました。

・フローの最終決定
データパイプラインの強化を進めています。現在、データ可視化の最適な方法を検討しており、DynamoDB から QuickSight への直接接続と、より複雑な分析を行うために Athena を利用すること、そして代替手段として DynamoDB Streams、Lambda、Firehose、S3 の利用を検討しています。目標は、スケーラブルで効率的なソリューションを実現することです。

・データパスの改良
現在、代替のデータパスウェイを検討しています。リアルタイムアクセスとバッチ分析機能のバランスに焦点を当てています。Kinesis Data Firehoseを使用してS3にデータをルーティングし、AthenaとQuickSight経由で分析を行うとともに、DynamoDBに直接アクセスして即時のインサイトを得ることを検討しています。

・データパスの微調整
現在、データフローアーキテクチャの改良に注力しています。データにはデュアルパスアプローチを採用することにしました。1つのパスは、DynamoDBへの直接接続によるリアルタイムアクセスを提供し、可視化を実現します。もう1つのパスは、Kinesis Data Firehoseを利用してS3にデータをストリーミングし、AthenaとQuickSightによる包括的な分析を可能にします。この設計により、システムは即時の運用インサイトと詳細な分析機能の両方を備えることができます。

・建築マップの構築
データフローは明確になりました。DynamoDBからのリアルタイムインサイトと、Kinesis Data FirehoseからS3への堅牢な分析機能を備えたデュアルパスアーキテクチャを構築しています。Athenaでクエリを実行し、QuickSightで可視化します。システム全体を分かりやすく図示することを目標としています。

・デュアルパスデータフローの定義
この設計は堅牢なアーキテクチャに重点を置いています。データはIoTデバイスからAWS IoT Coreへ、そしてKinesis Data Streamsへと流れます。この流れは2つのパスに分岐します。1つはLambdaとDynamoDBを介したリアルタイムインサイト用、もう1つはKinesis Data Firehose、S3、Athena、QuickSightを用いたバッチ分析用です。このプロセスを分かりやすく図示することを目標としています。

・データフローの可視化
現在、データフローアーキテクチャに注力しています。AWS IoT Core、Kinesis、Lambda、DynamoDB、QuickSightといったデバイス間のインタラクションを視覚的に表現する方法については、明確なアイデアが浮かびました。

・アーキテクチャの改良
現在、アーキテクチャの視覚的表現を改良中です。この図は、データ収集から可視化まで、様々なAWSサービスを用いた完全な統合を示しています。「ホットパス」と「コールドパス」の両方を明確に示しています。明瞭性を重視し、AWSアイコンとクリーンなデザインを採用することで、テキストを最小限に抑え、論理的な流れを強調しました。目指すのは、分かりやすいアーキテクチャ概要を作成することです。

追加の指示

  • 作成されたアーキテクチャ図について変更してほしい部分があれば、自然言語で指示できます。
  • シンプルなアーキテクチャになりました。

ユースケース

このGemは、詳細設計書にそのまま貼り付ける「完成品」を作成することを目的としたツールではありません。
活用を想定したケースは以下のようなシーンです。

  • ブレインストーミング
    • 「コンテナベースの分析基盤ってどんな構成だっけ？」と投げかけて、議論のたたき台にする。
  • 構成の抜け漏れチェック
    • 生成された図を見て、「あ、NAT Gateway忘れてた」と気付く。
  • 非エンジニアへの説明
    • 「大まかにこんな感じでデータが流れます」と視覚的に伝えるためのポンチ絵作成。
  • 構成の検討時
    • 「RDSをDynamo DBに変更して」と変更した際にベストプラクティスに従った構成に柔軟に変更し確認することが出来る。

及第点・今後の課題

正直なところ、まだ完璧ではありません。

  • 修正時の整合性
    • 修正を依頼した際にDynamoDBがVPCの中に入っているなど、修正時に整合性が崩れるケースがありました。
  • 複雑なルーティング
    • VPC PeeringやTransit Gatewayなど、線が交錯する複雑なネットワーク図は苦手です。

まとめ

完璧な構成図が作成できる訳ではありませんが、「テキストから数秒でAWS構成図が生成される」体験は、アーキテクチャ検討の初速を劇的に上げてくれます。

みなさんも自分だけの「Gem」、育ててみてはいかがでしょうか？