Claude Codeで「GCPアーキテクチャ図スキル」を作ってみた — AWSスキルの移植で見えたアイコン形式の根本的な違い

Claude Codeのスキル機能でGCPアーキテクチャ図を自動生成するスキルを作りました。AWS版からの移植で見えた、Draw.ioのGCPアイコンがBase64 SVGインライン埋め込み方式であるという根本的な違いと、その対処法を紹介します。

lin-yuchen

2026.07.12

 はじめにClaude Codeのカスタムスキルで、AWSのアーキテクチャ図をDraw.io形式で自動生成するスキルを以前作りました。「GCPアーキテクチャ図を描いて」と言うだけで、正確なアイコン付きの .drawio ファイルが出力される、というものです。
AWS版が便利だったので、「同じものをGCPでも作ろう」と思い立ちました。
結論から言うと、GCPのDraw.ioアイコンはAWSとは根本的に仕組みが違い、単純な移植では済みませんでした。AWSアイコンが1行のshape参照で済むのに対し、GCPアイコンはBase64エンコードされたSVGデータをstyle属性にインラインで埋め込む方式です。この違いにどう対処したかを紹介します。
 前提：AWS版スキルの仕組みまず既存のAWSスキルがどう動くかを簡単に説明します。
 ディレクトリ構成.claude/skills/aws-architecture-diagram/
├── SKILL.md                    # メインの指示書
├── references/
│   ├── aws-icons-compute.md    # EC2, Lambda, ECS等のアイコン定義
│   ├── aws-icons-networking.md # VPC, CloudFront, Route 53等
│   ├── layout-guidelines.md    # レイアウトルール
│   └── ...（7ファイル）
└── templates/
    └── base.drawio.xml         # Draw.ioの骨格テンプレート
 AWSアイコンの記法AWSのDraw.ioアイコンは、短いshape参照で指定できます：
<mxCell style="...shape=mxgraph.aws4.resourceIcon;resIcon=mxgraph.aws4.lambda;"
        vertex="1" parent="grp-subnet">
  <mxGeometry width="48" height="48" as="geometry" />
</mxCell>
ポイントは resIcon=mxgraph.aws4.lambda の部分。Draw.ioが内蔵しているAWSステンシルライブラリへの参照なので、アイコン名さえ分かれば済みます。LLMにとっても扱いやすく、リファレンスファイルも軽量です。
 GCPアイコンの問題：インラインSVG方式GCP版を作ろうとDraw.ioのソースコードを調べたところ、根本的な違いが見つかりました。
 GCPアイコンの記法<mxCell style="...shape=image;image=data:image/svg+xml,PHN2ZyB4bWxucz0i..."
        vertex="1" parent="grp-region">
  <mxGeometry width="42" height="42" as="geometry" />
</mxCell>
image=data:image/svg+xml,PHN2Zy... — これはBase64エンコードされたSVGデータそのものです。Draw.ioのGCP2ライブラリは、AWSのようなステンシル参照ではなく、各アイコンのSVG画像をstyle属性に直接埋め込む方式を採っています。
 これがLLMにとって何を意味するか

観点
AWS
GCP


アイコン指定
resIcon=mxgraph.aws4.lambda
image=data:image/svg+xml,PHN2Zy...（数百文字のBase64）

LLMが生成可能か
shape名を覚えれば可能
Base64 SVGは生成不可能

スタイル文字列の長さ
約200文字
約500〜2000文字

色の指定方法
fillColorで外部指定
SVGデータ内に色が焼き込み済み

つまり、LLMがGCPアイコンのstyle文字列を「記憶」や「推測」で生成することは不可能です。Base64エンコードされたSVGを1文字でも間違えると、アイコンが壊れて表示されません。
 業界のアプローチを調査「GCPのDraw.ioスキル」を作る先例がないか調べてみました。
 Ruban Siva / Google Cloud の記事Google Cloud公式ブログに近い形で、Draw.ioとMCPを組み合わせてGCPアーキテクチャ図を自動生成するアプローチが紹介されていました。ポイントは事前にコンポーネントライブラリを構築し、正確なstyle文字列をそこからコピーする方式です。
 Agents365 / drawio-skillGitHubで公開されているDraw.ioスキルで、10,000以上のshape定義を持つ shapesearch.py を含んでいます。ただし、Python依存が追加される点と、GCPアイコンのカバー範囲が不明でした。
 採用したアプローチ両方の調査結果から、AWS版と同じパターン — 事前抽出したリファレンスファイルにstyle文字列を丸ごと格納する方式が最も堅実と判断しました。LLMはリファレンスファイルからstyle文字列をコピペするだけなので、Base64 SVGを「理解」する必要がありません。
 実装：Draw.ioソースからのアイコン抽出 SVGデータの入手元Draw.ioのGCPアイコンは、GitHubの jgraph/drawio リポジトリにある2つのファイルに格納されています：
Sidebar-GCP2.js（2432行） — 163個のモダンGCPアイコン（インラインSVG方式）
gcp2.xml — 約200個のステンシルシェイプ（汎用アイコン）
Sidebar-GCP2.js の中身は、パレットごとにアイコンを登録する関数群です：
// addGCP2IconsComputePalette, addGCP2IconsNetworkingPalette, ...
this.createVertexTemplateEntry(
  'editableCssRules=.*;sketch=0;html=1;...image=data:image/svg+xml,PHN2Zy...',
  42, 42, 'Compute Engine', null, null, null, ...
);
各 createVertexTemplateEntry 呼び出しから、style文字列、幅、高さ、ラベルを抽出すればよいわけです。
 抽出スクリプトPythonスクリプトで Sidebar-GCP2.js をパースし、16カテゴリ × 163アイコンを抽出しました：
PALETTES = {
    "addGCP2IconsAIAndMachineLearningPalette": ("gcp-icons-ai-ml.md", "AI / Machine Learning"),
    "addGCP2IconsComputePalette": ("gcp-icons-compute.md", "Compute"),
    "addGCP2IconsNetworkingPalette": ("gcp-icons-networking.md", "Networking"),
    # ... 16パレット
}
各パレット関数から正規表現でエントリを抽出し、カテゴリ別のMarkdownファイルに書き出します。出力形式はAWS版と揃えました：
### Cloud Run

- **Width**: 34
- **Height**: 42
- **Style**: `editableCssRules=.*;sketch=0;html=1;...image=data:image/svg+xml,PHN2Zy...`
style文字列は一切加工せず、完全にそのまま格納します。改行もインデントも入れません。1文字でも変えるとアイコンが壊れるためです。
 完成したスキルの構成最終的なディレクトリ構成は以下の通りです：
.claude/skills/gcp-architecture-diagram/
├── SKILL.md                              # メインの指示書（212行）
├── templates/
│   └── base.drawio.xml                   # Draw.ioテンプレート（AWS版と共通）
└── references/
    ├── layout-guidelines.md              # GCP固有のレイアウトルール
    ├── gcp-icons-common.md               # ゾーン、パス、GCPロゴ、汎用アイコン
    ├── gcp-icons-compute.md              # Compute Engine, GKE等（11アイコン）
    ├── gcp-icons-serverless.md           # Cloud Functions, Cloud Run等（5アイコン）
    ├── gcp-icons-databases.md            # Cloud SQL, Spanner等（9アイコン）
    ├── gcp-icons-storage.md              # Cloud Storage, Filestore等（4アイコン）
    ├── gcp-icons-networking.md           # VPC, Load Balancing等（19アイコン）
    ├── gcp-icons-data-analytics.md       # BigQuery, Dataflow等（16アイコン）
    ├── gcp-icons-ai-ml.md                # Vertex AI, AutoML等（29アイコン）
    ├── gcp-icons-security.md             # IAM, KMS, Chronicle等（10アイコン）
    ├── gcp-icons-operations.md           # Logging, Monitoring等（17アイコン）
    ├── gcp-icons-cicd.md                 # Cloud Build, Artifact Registry等（15アイコン）
    ├── gcp-icons-integration.md          # Eventarc, Workflows等（7アイコン）
    ├── gcp-icons-api-management.md       # Apigee, Endpoints等（5アイコン）
    ├── gcp-icons-migration.md            # Transfer Appliance等（7アイコン）
    ├── gcp-icons-hybrid-multicloud.md    # Anthos等（4アイコン）
    ├── gcp-icons-iot.md                  # Cloud IoT Core（1アイコン）
    └── gcp-icons-opensource.md            # OSS関連アイコン（4アイコン）
合計: 20ファイル、163アイコン、約380KB
AWS版は7リファレンスファイルだったので、GCP版は18リファレンスファイルと大幅に増えました。これはGCP2ライブラリのカテゴリ分けがより細かいためです。
 AWS版との主な設計差分 コンテナのネスト階層

AWS
GCP


AWS Cloud → Region → VPC → Subnet
Google Cloud Project → VPC Network → Region → Zone

GCPではプロジェクトが最上位のコンテナで、中にVPC Networkが入ります。AWSではCloudが最外層で、VPCはRegionの下です。
 コンテナスタイルAWSはグループごとに個別のshapeを持ちますが、GCPはshape=mxgraph.gcp2.zonesという共通shapeにfillColorを変えるだけで表現します：


コンテナ
fillColor


Google Cloud Project
#F6F6F6（グレー）

VPC Network
#E1F5FE（ブルー）

Region
#F1F8E9（グリーン）

Zone
#ffffff（ホワイト）

 エッジの色AWSはオレンジ系が多いですが、GCPはGoogleブランドカラーを使います：


用途
GCP
AWS


Primary
#4284F3（Google Blue）
#147EBA

Secondary
#9E9E9E（Gray）
#AAB7B8

Success
#34A853（Google Green）
—

Error
#EA4335（Google Red）
—

 Managed ServicesパターンGCPのマネージドサービス（BigQuery, Vertex AI, Cloud Storage等）はVPCの外に存在します。これを視覚的に表現するため、Two-box layoutパターンを設計しました：
+--- Google Cloud Project --------------------------------+
|                                                          |
|  +--- VPC Network ---+   +--- Managed Services --------+|
|  | GKE, Compute     |   | Cloud SQL, BigQuery,         ||
|  | Engine, etc.     | →  | Vertex AI, Cloud Storage    ||
|  +-------------------+   | (GCP-managed, outside VPC)  ||
|                           +-----------------------------+|
+----------------------------------------------------------+
VPCボックスにはユーザーがデプロイしたリソース、Managed Servicesボックスには破線ボーダーでGCPマネージドサービスを配置します。矢印はソースからターゲットに直接引き、Private Google AccessやPrivate Service Connectの詳細はコンパニオンガイドに記載する設計です。
 テスト：3層サーバーレスアーキテクチャスキルの動作確認として、シンプルな3層構成を生成しました：
Users → Cloud Load Balancing → Cloud Run → Cloud SQL / Cloud Storage
生成されたDraw.ioファイルで確認したポイント：
アイコンの描画 — Cloud Load Balancing、Cloud Run、Cloud SQL、Cloud StorageのGCPカラーアイコンが正しく表示される
コンテナのネスト — Project（グレー）→ VPC（ブルー）→ Region（グリーン）が正しく入れ子になる
GCPロゴ — プロジェクトコンテナの左上に小さなGoogle Cloudロゴが表示される
エッジ — Google Blue（#4284F3）の直交ルーティング矢印が正しく接続される
 工夫した点 SKILL.mdの設計AWS版のSKILL.mdをベースに、GCP固有の要素を追加しました：
15のルール — style文字列のverbatimコピー、正確なサイズ指定、GCPロゴの配置等
Non-Technical Audience Mode — ステップ番号付きエッジ（①②③④）で非技術者向けの図も生成可能
Managed Servicesパターン — VPC内リソースとマネージドサービスの境界を視覚化するレイアウトパターン
 リファレンスファイルのフォーマット統一AWS版とGCP版で同じフォーマットを使い、LLMが「パターン」として学習しやすくしました：
### サービス名

- **Width**: 42
- **Height**: 42
- **Style**: `完全なstyle文字列...`
style文字列の中身がshape参照かBase64 SVGかは、LLMにとっては「コピペするもの」という点で変わりません。
 セルID規約メンテナビリティのため、描画要素に説明的なIDを付ける規約を定めました：
グループ: grp-project, grp-vpc, grp-region, grp-zone-a
アイコン: svc-gke, svc-cloud-sql, svc-bigquery
エッジ: edge-1, edge-2
ロゴ: logo-gcp
 学んだこと 同じパターンが異なるプロバイダーに適用できるAWSとGCPのアイコン形式は根本的に異なりますが、「リファレンスファイルからstyle文字列をコピーする」というスキル設計パターンは両方に適用できました。LLMに求めるのは「正しいファイルを読んで、正しい値をコピーすること」だけ。Base64 SVGを「理解」する必要はありません。
 アイコンの形式を調べるのが重要Draw.ioスキルを作る際は、まず対象ライブラリのアイコン形式を確認すべきです。ステンシル参照型（AWS、Azure）とインラインSVG型（GCP）では、リファレンスファイルの設計が大きく変わります。Draw.ioのGitHubリポジトリ（jgraph/drawio）のSidebar系JSファイルを読むのが最も確実です。
 SVGデータは一切触らないGCPアイコンのBase64 SVGデータは、抽出時もリファレンスファイル格納時も、一切修正してはいけません。改行の追加、再エンコード、トリミング — どれもアイコンの破損につながります。「触らない」がルールです。
 まとめClaude Codeで「GCPアーキテクチャ図を描いて」と言うだけで正確なDraw.ioファイルが出力されるスキルを作りました。AWSとGCPのアイコン形式の違い（shape参照 vs インラインSVG）という技術的な壁がありましたが、Draw.ioのソースコードからSVGデータを事前抽出しリファレンスファイルに格納するアプローチで解決しました。
20ファイル、163アイコン、約380KBのスキルセットで、GCPの主要サービスをほぼカバーしています。AWS版と設計パターンを揃えたことで、将来Azure版を作る際にも同じ手法が使えるはずです。

Claude Codeで「GCPアーキテクチャ図スキル」を作ってみた — AWSスキルの移植で見えたアイコン形式の根本的な違い

はじめに

前提：AWS版スキルの仕組み

ディレクトリ構成

AWSアイコンの記法

GCPアイコンの問題：インラインSVG方式

GCPアイコンの記法

これがLLMにとって何を意味するか

業界のアプローチを調査

Ruban Siva / Google Cloud の記事

Agents365 / drawio-skill

採用したアプローチ

実装：Draw.ioソースからのアイコン抽出

SVGデータの入手元

抽出スクリプト

完成したスキルの構成

AWS版との主な設計差分

コンテナのネスト階層

コンテナスタイル

エッジの色

Managed Servicesパターン

テスト：3層サーバーレスアーキテクチャ

工夫した点

SKILL.mdの設計

リファレンスファイルのフォーマット統一

セルID規約

学んだこと

同じパターンが異なるプロバイダーに適用できる

アイコンの形式を調べるのが重要

SVGデータは一切触らない

まとめ

Claudeならクラスメソッドにお任せください

関連記事

AWSで探す

注目のテーマ

プロダクトやサービスで探す

特集やシリーズから探す

EVENTS

観点	AWS	GCP
アイコン指定	`resIcon=mxgraph.aws4.lambda`	`image=data:image/svg+xml,PHN2Zy...`（数百文字のBase64）
LLMが生成可能か	shape名を覚えれば可能	Base64 SVGは生成不可能
スタイル文字列の長さ	約200文字	約500〜2000文字
色の指定方法	`fillColor`で外部指定	SVGデータ内に色が焼き込み済み

コンテナ	fillColor
Google Cloud Project	`#F6F6F6`（グレー）
VPC Network	`#E1F5FE`（ブルー）
Region	`#F1F8E9`（グリーン）
Zone	`#ffffff`（ホワイト）

用途	GCP	AWS
Primary	`#4284F3`（Google Blue）	`#147EBA`
Secondary	`#9E9E9E`（Gray）	`#AAB7B8`
Success	`#34A853`（Google Green）	—
Error	`#EA4335`（Google Red）	—