【レポート】生成型AIを活用してアーキテクチャ図を作成し、理解する #ARC308

【レポート】生成型AIを活用してアーキテクチャ図を作成し、理解する #ARC308

 「Japan AWS Top Engineers Advent Calendar 2024」(4日目)も兼ねて「 ARC308 | Harnessing generative AI to create & understand architecture diagrams 」のセッションレポートをお届けします
Clock Icon2024.12.04

お疲れさまです。とーちです。re:Invent2024に参加してます。
この記事では「 ARC308 | Harnessing generative AI to create & understand architecture diagrams 」のセッションレポートをお届けします。

セッションの概要

タイトル

Harnessing generative AI to create & understand architecture diagrams

概要

This builders’ session explores using generative AI to create and comprehend architecture diagrams, a critical aspect of software design and communication. Diagrams are often image data, custom formats of drawing programs, or text-based representations from diagram-as-code tools. Techniques are used from two different layers of the generative AI stack, Amazon Q Developer and foundational models on Amazon Bedrock. Chat-based workflows first understand and analyze existing diagrams, and then ask follow-up questions about best practices. New diagrams are created using diagram-as-code formats. Leave with practical strategies for harnessing generative AI in your software architecture workflows. You must bring your laptop to participate.

※日本語訳
このビルダー向けセッションでは、ソフトウェア設計とコミュニケーションの重要な側面であるアーキテクチャ図の作成と理解にジェネレーティブAIを使用する方法を探ります。図は、多くの場合、画像データ、描画プログラムのカスタム形式、または図をコード化したツールによるテキストベースの表現です。ジェネレーティブAIスタックの2つの異なるレイヤー、Amazon Q DeveloperとAmazon Bedrockの基礎モデルから技術が使用されます。チャットベースのワークフローでは、まず既存の図を理解し分析し、次にベストプラクティスに関する追加の質問を行います。新しいダイアグラムは、ダイアグラム・アズ・コード形式を使用して作成されます。ソフトウェアアーキテクチャのワークフローで生成型AIを活用するための実践的な戦略を習得して帰りましょう。参加するには、ノートパソコンを持参してください。

スピーカー

Tom Romano, Sr. Solutions Architect, Amazon Web Service

Mark Curtis, Senior Solutions Architect, Amazon Web Services

Swapnil Singh, Solutions Architect, AWS

Kevin Hakanson, Sr. Solutions Architect, Amazon Web Services

Jenna Pederson, Principal Developer Advocate, AWS

セッションタイプ

Builders' session

概要

Generative AIを使ってシステム構成図の分析や作成までやってしまうという内容のセッションでした。
主にAmazon Q DeveloperとBedrockを使って進めていく内容になっていました。
以下が実際に実施した内容の流れになります。

  1. 「アーキテクチャ図の必要性」のセクション:Amazon Q developerチャットを使って、アーキテクチャ図についての質問をします
  2. 「ダイアグラムの分析」のセクション:Amazon Bedrock APIを使って、アーキテクチャ図を分析させてみます
  3. 「図の生成」のセクション:Amazon Q developerの支援を受けながら、コードを使ってアーキテクチャ図を作成します
  4. 「ワークフロー」のセクション:これまでに学んだ分析・生成・要約の技術を組み合わせて、より実践的なワークフローを作成します

1時間枠なのですが、なかなか盛りだくさんな内容ですね。実はまだ続きがあったりしましたが、自分が体験できたのはここまででした。

実際のワークショップで体験したこと

IDEは私が前に受けたセッションと同様にVisual Studio Code Server(以下VSCode)を使っていました。
VSCodeにAmazon Q DeveloperとJupyter notebookが入っており、Amazon Qに質問をしたり、Bedrockに図を生成させたりして進めていきます。

「アーキテクチャ図の必要性」のセクション

上記でも書きましたがAmazon Q developerはVSCode拡張としてハンズオン環境にすでに組み込まれています。最初に下記の画面からAWS Builder IDにログインすることでVSCode上で使用可能になります。

image.png

使用可能になると、画面左からAmazon Q developerのアイコンを選択することでチャットすることができます。

チャット欄に @workspace と入力することでIDE上で開いているワークスペース(≒フォルダ)内の関連性の高い部分をコンテキストとして追加してくれるようです。

image.png

Amazon Q developerに質問をしていくのですが、面白かったのがまず先に質問に対する回答を自分で書いてみて、その後にAmazon Q developerに回答をしてもらうという流れになっていました。
例えば以下のような質問があり、

What tools should I use to create architecture diagrams?(システム構成図を作成するにはどのようなツールを使えばいいですか?)

これに対して自分の回答はこれでした

draw.ioとかCacoo

Amazon Q developerの回答が以下です(※筆者が日本語訳したものを記載)

# AIからの回答
ここでは、アーキテクチャ図を作成するための一般的で効果的なツールをいくつか紹介します: [1]
無料のオプション:
    Draw.io (diagrams.netとしても知られている): [2]
        豊富なテンプレートライブラリ
        ブラウザベースまたはデスクトップアプリケーション
        複数のエクスポート形式をサポート
        クラウドストレージオプションを内蔵
    yEd グラフエディター:
        無料のクロスプラットフォームツール
        強力な自動レイアウト機能
        UML やフローチャートに最適
        Java ベースで、すべてのプラットフォームで動作

プロフェッショナル/有料オプション:
    ルシッドチャート
        コラボレーション機能
        リアルタイム編集
        豊富な図形ライブラリ

他のツールとの統合
    Microsoft Visio:
        プロ仕様のダイアグラム作成
        Windows との深い統合
        豊富なテンプレート
        多くの組織における業界標準

クラウドネイティブオプション
    Miro:
        コラボレーティブホワイトボード
        リアルタイムコラボレーション
        チームワークショップに最適
        投票とコメント機能付き
        エンタープライズアーキテクト
        包括的なモデリングツール
        複数のダイアグラムタイプをサポート [3]
        強力なバージョン管理
        チームコラボレーション機能

選択基準
    使いやすさ
    利用可能なテンプレートと図形
    エクスポートオプション
    コラボレーション機能
    コスト制約
    既存ツールとの統合
    プラットフォームの互換性

初心者や個人開発者にとって、Draw.ioはその使いやすさとコストゼロのため、しばしば最良の出発点となります。チームや企業で使用する場合は、特定の組織のニーズや予算の制約によって選択することが多い。

Amazon Q developerと比べて自分の回答精度の低さを思い知らされましたw

個人的には以下のように情報のソースを示してくれるのが良かったです。

[[1] Best tool to create "Architecture Diagrams" (not UML)](https://stackoverflow.com/questions/5013996)[stackoverflow.comquestions5013996](https://stackoverflow.com/questions/5013996)



[[2] Architecture Diagram: Best Strategy to Build One. | by Apoorv Tomar | Geek Culture | Medium](https://medium.com/@apoorv-tomar/architecture-diagram-best-strategy-to-build-one-7a3509509eeb)[medium.com@apoorv-tomararchitecture-diagram-best-strategy-to-build-one-7a3509509eeb](https://medium.com/@apoorv-tomar/architecture-diagram-best-strategy-to-build-one-7a3509509eeb)

「ダイアグラムの分析」のセクション

ここではPython コードを使用して Amazon Bedrock API を呼び出し、アーキテクチャ図を分析するといったことをしました。
なおモデルにはClaude3.5 Sonnetを使っていました。

ワークスペースには以下のシステム構成図が含まれています。

image.png

この構成図に対して以下のようなプログラムでアーキテクチャ図に対する質問をします。png図を読み込ませるのはこうやってやるのか、と思いました。

# Set up the conversation agent and select model
png_conversation = Conversation(CLAUDE_V35_SONNET, bedrock_client)
png_conversation.system("You are an expert in AWS services and serverless architecture.")

# the PNG export from draw.io
response = png_conversation.chat(
 "Describe the key components and services in the attached diagram.",
 filename="apiendpoint.drawio.png"
)

Bedrockからの回答が以下の通りです

この図は、AWSの様々なサービスを使ったサーバーレス・アーキテクチャを示している。以下に主要なコンポーネントとサービスを示す:

User: フローの開始点であり、プロセスを開始するエンドユーザーまたはクライアントを表す。

Amazon API Gateway: アプリケーションのエントリーポイントで、ユーザーからのAPIリクエストの処理とルーティングを行う。

AWS Lambda: イベントに応答してコードを実行するサーバーレスのコンピュートサービス。この図ではAPI Gatewayからのリクエストを処理するために配置されている。

Amazon DynamoDB: フルマネージドNoSQLデータベースサービス。Lambda関数はDynamoDBからデータを読み込んでいる。

Amazon Simple Storage Service(Amazon S3): オブジェクトストレージサービス。Lambda関数はS3にデータを書き込むように描かれている。

操作の流れは次のようになる:

ユーザーがAPI Gatewayにリクエストを送る。
API GatewayがLambda関数をトリガーする。
Lambda関数がDynamoDBからデータを読み込む。
Lambda関数はS3にデータを書き込む。
このアーキテクチャは、AWSにおける典型的なサーバーレスアプリケーションのセットアップを示しており、マネージドサービスを活用してスケーリングやインフラ管理を行い、可用性とコスト効率の高いソリューションを提供している。特に、ワークロードが変動するアプリケーションや、迅速な開発とデプロイが必要なアプリケーションに適している。

また、私は知らなかったのですが、pngファイルにxmlで書かれたメタデータを含めることができるらしく、以下のプログラムでpngからxmlの抽出といったことを行った後に

filename = "apiendpoint.drawio.png"
im = PIL.Image.open(filename)
im.load() # needed for .png EXIF data

# https://www.drawio.com/blog/xml-in-png says zTxt but looks like mxfile
mxfile = urllib.parse.unquote(im.info['mxfile'])
im.close()

element = ET.XML(mxfile)
ET.indent(element)
drawio_xml_string = ET.tostring(element, encoding='unicode') 

xmlデータの説明をBedrockにさせていました。

# Set up the conversation agent and select model
xml_conversation = Conversation(CLAUDE_V35_SONNET, bedrock_client)
xml_conversation.system("You are an expert in AWS services and serverless architecture.")

diagram_prompt=f"""Describe the key components and services from the DrawIO XML in the <example> below.

<example>
{drawio_xml_string}
</example>
"""
response = xml_conversation.chat(diagram_prompt)

Bedrockからの回答はこんな感じでした。

提供されたDrawIO XMLに基づくと、このアーキテクチャの主要なコンポーネントとサービスは以下の通りである:

Amazon API Gateway: これはアプリケーションのエントリーポイントで、ユーザーからのAPIリクエストを処理する。

AWS Lambda: イベントに応じてコードを実行するサーバーレス・コンピュート・サービス。このアーキテクチャでは、API Gatewayによってトリガーされ、リクエストを処理する。

Amazon DynamoDB: フルマネージドNoSQLデータベースサービス。Lambda関数はDynamoDBからデータを読み込み、リクエストの処理に必要な情報を取得する。

Amazon S3(Simple Storage Service): オブジェクトストレージサービス。Lambda関数はS3にデータを書き込み、ファイルや他のオブジェクトを保存する。

User: ユーザーアイコンで表され、リクエストフローの開始点を示す。

アーキテクチャーフローは1から4まで番号が振られており、以下のような流れになる:

ユーザーがAPI Gatewayにリクエストを送信する。
API GatewayがLambda関数をトリガーする。
Lambda関数がDynamoDBからデータを読み込む。
Lambda関数がS3にデータを書き込む。
このサーバーレスアーキテクチャは、APIリクエストを処理し、Lambdaを使って処理し、データ検索のためにデータベース(DynamoDB)とやり取りし、結果やファイルをS3に保存するように設計されている。サーバーを管理せずにWebアプリケーションやサービスを構築するための、スケーラブルでコスト効率の高いソリューションだ。

xmlとpngでは、pngのほうがBedrockが解析するトークン数は少なくなるようです

print("PNG\n---")
png_conversation.print_usage()

print("\nXML\n---")
xml_conversation.print_usage()
PNG --- Tokens: 611 (334 input, 277 output) Price: 0.005157 USD 
XML --- Tokens: 3308 (3013 input, 295 output) Price: 0.013464 USD

しかし、xmlを分析させることで例えばラベルがついてないアイコンを見つけるなどメタデータに基づく解析が出来るようなので使い分けかなという感じです。

「図の生成」のセクション

このセクションでは、Amazon Q Developer と Amazon Bedrock API を呼び出す Python コードを使用してアーキテクチャ図を生成するといった内容だったのですが、Bedrockのほうまで手が回らずでした。

Amazon Q Developerでは以下のように、ワークスペースの情報を元にMermaid 図を生成といったことをやりました。私も生成AIにMermaidで図を書いてもらったことがあるのですが、これはとても便利な使い方ですよね。

  • Amazon Q Developerへの指示:@workspace create a mermaid formatted class diagram for conversation.py

Amazon Q Developerからの回答

I'll create a Mermaid class diagram based on the Conversation class from conversation.py. Here's the diagram:
classDiagram class Conversation { +dict image_formats -BedrockModel model -bedrock_client -List message_list -List system_prompts -dict tool_config -dict tool_models -dict inference_config -int input_tokens -int output_tokens -int total_tokens +__init__(model: BedrockModel, bedrock_client) +system(system_prompt: str) void +add_tool(tool_name: str, tool_desc: str, tool_model: BaseToolModel) void +send(user_prompt: str) -_converse() +update_usage(response) void +token_usage() dict +print_usage() void +extract_codefence(identifier: str, filename: str) str } class BedrockModel { <<interface>> } class BaseToolModel { <<interface>> } Conversation --> BedrockModel : uses Conversation --> BaseToolModel : uses 
CopyInsert at cursor

This class diagram shows:

	The 
Conversation

 class with its main attributes and methods

	The relationships with 
BedrockModel

 and BaseToolModel



	The main methods including:

		Constructor

		System prompt management

		Tool management

		Conversation handling

		Usage tracking

		Code fence extraction
Key features represented:

	Private attributes are marked with 
-



	Public attributes/methods are marked with 
+



	Method parameters and return types are included

	Dependencies are shown with arrows

	External interfaces (BedrockModel and BaseToolModel) are marked as interfaces
The diagram reflects the main functionality of the Conversation class as shown in the source code, including its ability to manage conversations, handle tools, track token usage, and process code fences.

「ワークフロー」のセクション

このセクションでは、マークダウンベースのアーキテクチャレポートを自動生成するワークフローを作成しました。

ツールの使用(関数呼び出し)

Amazon Bedrockでは、Converse APIを通じてツールを使用します。以下のような特徴があるとのこと

  • モデルは直接ツールを呼び出すことはできない
  • Converse APIが一貫したインターフェースを提供
  • Claudeモデルでツールの使用がサポートされている

実装例:サービス検索ツール

架空の会社のシステム構成図や情報などがワークスペースに事前に用意されています。
それらの情報を使って、架空の会社の内部で使用されているサービス名を検索し、その説明をするツールを作成しました。
Converse APIは外部ツール(InternalService)を呼び出すのに使われているようです。

conversation.add_tool(
 "internal_service_name", 
 "Gets the description of the internal service name from the proper name.",
 InternalService
)

実行結果

ツールを使用すると、以下のような情報が表示されていました

  • 主要コンポーネント(Customer、Search Microservice、Display Microserviceなど)の役割
  • データフローの詳細な説明
  • アーキテクチャの特徴(データベースの使い分けなど)

## まとめ

最後までは出来なかったのですが、生成AIを使って構成図の作成や分析といったところまで出来るのがわかりました。
Amazon Q DeveloperもVSCode拡張にいれるとなかなか良さそうです。

以上、とーちでした。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.