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

Azure Bicep ファイルから直接アーキテクチャダイアグラムを生成します。Bicep は Azure リソースを宣言的にデプロイするための専用言語 (DSL) です。

使用する場合

以下の場合にこのスキルを有効化します：

• ユーザーが Bicep ファイル (.bicep) を持っており、インフラストラクチャを可視化したい
• ユーザーが「Bicep をダイアグラム化して」または「この Bicep インフラストラクチャを可視化して」と尋ねる
• ユーザーが Bicep または Azure Bicep について言及する
• ユーザーが Bicep でデプロイされたリソースのアーキテクチャを見たい

仕組み

このスキルは Bicep コードを解析し、Eraser API を直接呼び出すことで Bicep 固有のダイアグラムを生成します：

1. Bicep ファイルの解析：リソース宣言、モジュール、パラメータ、出力を識別
2. 関係の抽出：依存関係、リソース参照、モジュール階層をマッピング
3. Eraser DSL の生成：Bicep リソースから Eraser DSL コードを作成
4. Eraser API の呼び出し：diagramType: "cloud-architecture-diagram" で /api/render/elements を使用

手順

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

1. Bicep を解析

   • すべての resource 宣言を識別（Microsoft.Compute/virtualMachines など）
   • module 宣言とその構成を抽出
   • param と output 定義を記録
   • var 変数とその使用法を識別

2. 関係をマッピング

   • リソース依存関係を追跡（例：dependsOn または暗黙的依存関係）
   • リソースをタイプ別にグループ化（コンピュート、ネットワーク、ストレージなど）
   • VNet をサブネットとリソースのコンテナとして識別
   • ネットワークセキュリティグループ、Key Vault、その他のセキュリティリソースを記録

3. Eraser DSL を生成 Bicep リソースを Eraser DSL に変換：

   • 重要：ラベルフォーマットルール
     • ラベルは必ず 1 行内 - ラベル属性内で改行を使用しない
     • ラベルはシンプルで読みやすく - 過度なメタデータの連結より別々のラベルを優先
     • DSL を適切に改行フォーマット（1 ノード/グループは 1 行だが、ラベルは 1 行に保つ）
     • CIDR ブロックや VM サイズなどのメタデータを含める場合、同じクォート文字列内に含める：[label: "VNet 10.0.0.0/16"]

   例：

   myVNet [label: "VNet 10.0.0.0/16"] {
     subnet1 [label: "Subnet 1"] {
       myVM [icon: azure-vm, label: "Virtual Machine"]
       gateway [icon: azure-app-gateway]
     }
     subnet2 [label: "Subnet 2"] {
       database [icon: azure-sql]
     }
   }
   storage [icon: azure-storage]
   myVNet -> myVM
   myVM -> 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. 分析中にソースを追跡

   Bicep ファイルとリソースを分析してダイアグラムを生成する際に、以下を追跡します：

   • 内部ファイル：読み込んだ各 Bicep ファイルパスと抽出されたリソースを記録（例：infra/main.bicep - VNet とサブネット定義、infra/sql.bicep - SQL Database 設定）
   • 外部参照：参照したドキュメント、例、URL を記録（例：Azure Bicep ドキュメント、Azure アーキテクチャベストプラクティス）
   • 注釈：各ソースについて、ダイアグラムへの貢献を記録

6. レスポンスを処理

   重要：最小限の出力フォーマット

   レスポンスには常に以下の要素を明確なヘッダー付きで含める必要があります：

   1. ダイアグラムプレビュー：ヘッダー付きで表示

      ## ダイアグラム
      ![{Title}]({imageUrl})
      

      API レスポンスから実際の imageUrl を使用します。

   2. エディタリンク：ヘッダー付きで表示

      ## Eraser で開く
      [Eraser エディタでこのダイアグラムを編集]({createEraserFileUrl})
      

      API レスポンスから実際の URL を使用します。

   3. ソースセクション：分析されたファイル/リソースの簡潔なリスト（該当する場合）

      ## ソース
      - `path/to/file` - 抽出された内容
      

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

      ## ダイアグラムコード
      ```eraser
      {DSL code here}
      

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

   追加コンテンツルール：

   • ユーザーが単にダイアグラムだけを要求した場合、上記 5 つの要素以外は一切含めない
   • ユーザーが明示的により詳しい情報を要求した場合（例：「アーキテクチャを説明して」、「改善案を提案して」）、その追加コンテンツを含めてもよい
   • 概要、セキュリティ考慮事項、テストなど、要求されていないセクションを追加しない

   デフォルト出力は短くします。ダイアグラム画像が自ら語ります。

7. モジュールを処理

   • モジュールが使用されている場合、モジュール境界を表示
   • モジュールのパラメータと出力を含める
   • モジュールがメインリソースとどう接続されているかを表示

Bicep 固有のヒント

• リソースグループを表示：Bicep デプロイメントはリソースグループをターゲット
• VNet をコンテナとして：VNet がサブネットとリソースを含む形で表示
• 依存関係を含める：dependsOn 関係を表示
• モジュール構造：モジュールが使用されている場合、その境界を表示
• パラメータ：リソース設定に影響する主要パラメータを記録
• Azure アイコンを使用：Azure 固有のスタイリングをリクエスト

例：パラメータとモジュールを含む Bicep

ユーザー入力

@description('The name of the Virtual Network')
param vnetName string = 'myVNet'
@description('The address prefix for the VNet')
param vnetAddressPrefix string = '10.0.0.0/16'
@description('The address prefix for the subnet')
param subnetAddressPrefix string = '10.0.1.0/24'
@description('VM size')
param vmSize string = 'Standard_B1s'

// Main VNet resource
resource virtualNetwork 'Microsoft.Network/virtualNetworks@2021-05-01' = {
  name: vnetName
  location: resourceGroup().location
  properties: {
    addressSpace: {
      addressPrefixes: [vnetAddressPrefix]
    }
    subnets: [
      {
        name: 'subnet1'
        properties: {
          addressPrefix: subnetAddressPrefix
        }
      }
    ]
  }
}

// VM resource with dependsOn
resource virtualMachine 'Microsoft.Compute/virtualMachines@2021-11-01' = {
  name: 'myVM'
  location: resourceGroup().location
  properties: {
    hardwareProfile: {
      vmSize: vmSize
    }
  }
  dependsOn: [virtualNetwork]
}

// Module usage
module storageModule './modules/storage.bicep' = {
  name: 'storage'
  params: {
    location: resourceGroup().location
  }
}

予期される動作

1. Bicep を解析：

   • パラメータ：vnetName、vnetAddressPrefix、subnetAddressPrefix、vmSize
   • リソース：dependsOn 関係を持つ VNet とサブネット、VM
   • モジュール：パラメータを持つストレージモジュール

2. Bicep 固有機能を表示する DSL を生成：

   myVNet [label: "VNet 10.0.0.0/16"] {
     subnet1 [label: "Subnet 1 10.0.1.0/24"] {
       myVM [icon: azure-vm, label: "VM Standard_B1s"]
     }
   }
   
   storage-module [label: "Storage Module"] {
     storage-account [icon: azure-storage]
   }
   
   myVNet -> myVM
   

   重要：すべてのラベルテキストはクォート内で 1 行に保つ必要があります。Bicep 固有：モジュールをコンテナとして表示、dependsOn 関係を含める、リソース設定でのパラメータ使用を記録。

3. diagramType: "cloud-architecture-diagram" で /api/render/elements を呼び出し

4. diagramType: "cloud-architecture-diagram" で /api/render/elements を呼び出し

結果

ユーザーは以下を表示するダイアグラムを受け取ります：

• コンテナとしての VNet
• VNet 内にネストされたサブネット
• サブネット内の VM
• 表示される依存関係
• 適切な Azure スタイリング