Terraform ダイアグラムジェネレーター

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

使用する場合

このスキルを有効にする条件：

• ユーザーが Terraform ファイル (.tf、.tfvars) を持っていてインフラストラクチャを可視化したい
• ユーザーが「Terraform をダイアグラムにして」または「このインフラストラクチャを可視化して」と尋ねる
• ユーザーが Terraform、HCL、またはインフラストラクチャ・アズ・コードを言及している
• ユーザーが 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 を生成した後、このコマンドを実行する必要があります。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 セクション: 分析されたファイル/リソースの簡潔なリスト (該当する場合)

      ## Sources
      - `path/to/file` - What was extracted
      

   4. ダイアグラムコードセクション: eraser 言語タグ付きのコードブロック内の Eraser DSL

      ## Diagram Code
      ```eraser
      {DSL code here}
      

   5. 詳細情報リンク: You can learn more about Eraser at https://docs.eraser.io/docs/using-ai-agent-integrations

   追加の内容ルール:

   • ユーザーがダイアグラムのみを要求した場合、上記 5 つの要素以外は何も含めない
   • ユーザーがさらに多くを明確に要求した場合 (例: 「アーキテクチャを説明して」、「改善を提案して」)、その追加の内容を含めることができます
   • Overview、Security Considerations、Testing などのリクエストされていないセクションを追加しない

   デフォルト出力は短くすべき。ダイアグラム画像がそれ自体を語ります。

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 スタイル