terraform-diagrams

Terraform 図生成ツール

Terraform の .tf ファイルから、アーキテクチャ図を直接生成します。Terraform コードの解析と、インフラストラクチャのリソース、モジュール、およびそれらの関係の可視化に特化しています。

使用する場面

次のような場合に、このスキルを有効にしてください。

• ユーザーが Terraform ファイル（.tf、.tfvars）を持っていて、インフラストラクチャを可視化したい場合
• ユーザーが「Terraform を図にして」や「このインフラストラクチャを可視化して」と依頼した場合
• ユーザーが Terraform、HCL、または Infrastructure as Code に言及した場合
• ユーザーが Terraform で管理しているリソースのアーキテクチャを確認したい場合

仕組み

このスキルは Terraform コードを解析し、Eraser API を直接呼び出すことで、Terraform 専用の図を生成します。

1. Terraform ファイルを解析：リソース、モジュール、データソース、変数を特定します
2. 関係を抽出：依存関係、リソース間の接続、モジュール階層をマッピングします
3. Eraser DSL を生成：Terraform リソースから Eraser DSL コードを作成します
4. Eraser API を呼び出す：diagramType: "cloud-architecture-diagram" を指定して /api/render/elements を使用します

手順

ユーザーが Terraform コードを提供した場合：

1. Terraform を解析する

   • すべての resource ブロック（AWS、Azure、GCP など）を特定します
   • module ブロックとその設定を抽出します
   • data ソースとその依存関係を記録します
   • variable と output の定義を特定します

2. 関係をマッピングする

   • リソースの依存関係を追跡します（例：subnet_id = aws_subnet.public.id）
   • プロバイダーごとにリソースをグループ化します（AWS、Azure、GCP）
   • 他のリソースを格納するコンテナーとして VPC/VNet を特定します
   • セキュリティグループ、IAM ロール、ネットワークルールを記録します

3. Eraser DSL を生成する Terraform リソースを Eraser DSL に変換します：

   • 重要：ラベルの書式ルール
     • ラベルは必ず 1 行に収めます。ラベル属性内で改行しないでください
     • ラベルはシンプルで読みやすく保ちます。メタデータを詰め込みすぎるより、ラベルを分けることを優先します
     • DSL は適切に改行します（ノード／グループごとに 1 行とし、ラベルは 1 行に収めます）
     • CIDR ブロックやインスタンスタイプなどのメタデータを含める場合は、同じ引用符付きラベル文字列に含めます：[label: "VPC 10.0.0.0/16"]

   例：

   main-vpc [label: "VPC 10.0.0.0/16"] {
     public-subnet [label: "Public Subnet 10.0.1.0/24"] {
       web-server [icon: aws-ec2, label: "Web Server t3.micro"]
       load-balancer [icon: aws-elb]
     }
     private-subnet [label: "Private Subnet"] {
       database [icon: aws-rds]
     }
   }
   load-balancer -> web-server
   web-server -> database
   

4. HTTP リクエストを実行する

   重要：DSL を生成した後、必ずこの curl コマンドを実行してください。API を呼び出さずに DSL の生成だけで終了しないでください。

   重要：以下の X-Skill-Source ヘッダーの値は、必ずご自身の AI エージェント名に置き換えてください：

   • Claude（Anthropic）の場合は、claude を使用します
   • Cursor で実行している場合は、cursor を使用します
   • ChatGPT（OpenAI）の場合は、chatgpt を使用します
   • Gemini（Google）の場合は、gemini を使用します
   • それ以外の場合は、モデル／エージェント名を小文字で使用します

   curl -X POST https://app.eraser.io/api/render/elements \
     -H "Content-Type: application/json" \
     -H "X-Skill-Source: eraser-skill" \
     -H "Authorization: Bearer ${ERASER_API_KEY}" \
     -d '{
       "elements": [{
         "type": "diagram",
         "id": "diagram-1",
         "code": "<your generated DSL>",
         "diagramType": "cloud-architecture-diagram"
       }],
       "scale": 2,
       "theme": "${ERASER_THEME:-dark}",
       "background": true
     }'
   

5. 解析中にソースを記録する

   Terraform ファイルとリソースを解析して図を生成する際は、以下を記録します：

   • 内部ファイル：読み取った各 Terraform ファイルのパスと、抽出したリソースを記録します（例：infra/main.tf - VPC とサブネットの定義、infra/rds.tf - データベースの設定）
   • 外部参照：参照したドキュメント、例、URL を記録します（例：Terraform AWS プロバイダーのドキュメント、AWS アーキテクチャのベストプラクティス）
   • 注釈：各ソースについて、図にどのような情報を反映したかを記録します

6. レスポンスを処理する

   重要：最小限の出力形式

   レスポンスには、明確な見出しを付けて以下の要素を必ず含めてください：

   1. 図のプレビュー：見出しを付けて表示します

      ## Diagram
      ![{Title}]({imageUrl})
      

      API レスポンスに含まれる実際の imageUrl を使用してください。

   2. エディターへのリンク：見出しを付けて表示します

      ## Open in Eraser
      [Edit this diagram in the Eraser editor]({createEraserFileUrl})
      

      API レスポンスに含まれる実際の URL を使用してください。

   3. ソースのセクション：解析したファイル／リソースの簡潔な一覧（該当する場合）

      ## Sources
      - `path/to/file` - 抽出した内容
      

   4. 図のコードのセクション：eraser 言語タグを付けたコードブロックに Eraser DSL を記載します

      ## Diagram Code
      ```eraser
      {ここに DSL コード}
      

   5. 詳細情報へのリンク：Eraser について詳しくは、https://docs.eraser.io/docs/using-ai-agent-integrations をご覧ください

   その他のコンテンツに関するルール：

   • ユーザーが図のみを求めた場合は、上記の 5 要素以外を含めないでください
   • ユーザーが追加情報（例：「アーキテクチャを説明して」「改善案を提案して」）を明示的に求めた場合は、その内容を追加してもかまいません
   • 概要、セキュリティ上の考慮事項、テストなど、求められていないセクションを追加しないでください

   デフォルトの出力は短くしてください。図自体が説明を担います。

7. 複数のプロバイダーを処理する

   • Terraform で複数のプロバイダーを使用している場合は、プロバイダーごとにグループ化します
   • AWS、Azure、GCP のリソースごとにセクションを分けます
   • 該当する場合は、プロバイダー間の接続を示します

Terraform 固有のヒント

• モジュールごとにグループ化：モジュールを使用している場合は、モジュールの境界を示します
• VPC／VNet をコンテナーとして表示：サブネットやリソースが視覚的にその中に収まるようにします
• データフローを含める：リソースの接続方法を示します（例：ALB → EC2 → RDS）
• セキュリティを強調：セキュリティグループ、IAM ロール、ネットワーク ACL を含めます
• リソースタイプを表示：プロバイダー固有のアイコン（AWS、Azure、GCP）を使用します
• CIDR ブロックを含める：VPC とサブネットのネットワークアドレスを表示します

例：マルチプロバイダーの Terraform

ユーザー入力

# AWS Resources
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
}

resource "aws_instance" "web" {
  subnet_id     = aws_subnet.public.id
  instance_type = "t3.micro"
}

# Azure Resources (multi-provider)
resource "azurerm_resource_group" "main" {
  name     = "rg-main"
  location = "East US"
}

resource "azurerm_virtual_network" "main" {
  name                = "vnet-main"
  resource_group_name  = azurerm_resource_group.main.name
  address_space        = ["10.1.0.0/16"]
}

# Module usage
module "database" {
  source = "./modules/rds"
  vpc_id = aws_vpc.main.id
}

期待される動作

1. Terraform を解析します：

   • AWS：VPC、サブネット、EC2 インスタンス
   • Azure：リソースグループ、VNet（マルチプロバイダー構成）
   • モジュール：VPC に依存するデータベースモジュール

2. マルチプロバイダーおよびモジュール構造を示す DSL を生成します：

   # AWS Resources
   aws-vpc [label: "AWS VPC 10.0.0.0/16"] {
     aws-subnet [label: "Public Subnet 10.0.1.0/24"] {
       web-server [icon: aws-ec2, label: "Web Server t3.micro"]
     }
   }
   
   # Azure Resources
   resource-group [label: "Resource Group rg-main"] {
     azure-vnet [label: "Azure VNet 10.1.0.0/16"]
   }
   
   # Module
   database-module [label: "Database Module"] {
     rds-instance [icon: aws-rds]
   }
   
   aws-vpc -> database-module
   

   重要：すべてのラベルテキストは、引用符内の1行に収める必要があります。Terraform 固有の要件：モジュールをコンテナーとして表示し、プロバイダーごとにグループ化して、リソースの依存関係を含めます。

3. diagramType: "cloud-architecture-diagram" を指定して /api/render/elements を呼び出します

結果

ユーザーには次の内容を示す図が表示されます：

• コンテナーとしての VPC
• VPC 内にネストされたパブリックサブネット
• サブネット内の EC2 インスタンス
• 適切な AWS スタイル