【ITニュース解説】Free AWS, Azure and GCP architecture icons as SVG

現代のシステム開発において、クラウドサービスの利用は当たり前となり、AWS、Azure、Google Cloudといった主要なプロバイダーのサービスを組み合わせてシステムを構築する機会が増えている。システムエンジニアにとって、自分が設計したシステムの構造を正確かつ分かりやすく伝えることは非常に重要であり、その際に役立つのが、各クラウドサービスが提供する「アーキテクチャアイコン」である。これらのアイコンを使うことで、複雑なシステム構成図も一目で理解しやすくなる。

しかし、これらのアイコンを利用する際にはいくつかの課題が存在する。現在、Amazonは739個、Microsoftは626個、Googleは214個ものアーキテクチャアイコンを提供しており、合計で1,579個にも上る。これらはそれぞれ異なるダウンロードページや圧縮ファイルで提供されているため、例えばAWSのLambdaとGoogle CloudのBigQueryを同じ図に表示したい場合、それぞれのサイトからアイコンを探し、ダウンロードしてくる手間がかかる。また、各プロバイダーでアイコンのスタイルや命名規則が異なり、統一感がなく、管理も煩雑になりがちだ。

そんな課題を解決してくれるのが「thesvg.org」というサービスである。このサイトは、これら主要クラウドサービスのアーキテクチャアイコンを一元的に集約し、開発者やデザイナーが簡単に検索・利用できるようにしている。このサイトでは、提供元別にAWSが739個、Azureが626個、Google Cloudが214個、そしてKubernetesが38個のアイコンを管理していることがわかる。これらの情報はJSON形式のレジストリとして公開されており、プログラム的にアイコンの検索や取得が可能になっている。

特にAWSのアイコンセットは、多くの人が想像するよりも大規模だ。単なるサービスアイコンだけでなく、サービス内の特定のリソースを表す小さなアイコンや、システム全体のカテゴリ、グループ分けを示すアイコンなど、4種類に分類される。例えば、「Service」アイコンは一般的に使われるカラフルな四角いアイコンで、Amazon Bedrockのようなサービスを表す。「Resource」アイコンはLambda関数といった、より具体的な機能を示す小さな絵文字のようなアイコンだ。さらにAWSアイコンには16、32、64ピクセルのサイズ違いが用意されており、用途に応じて適切なサイズを選べるのも特徴である。

アイコンのファイル名、いわゆる「スラッグ」は、各プロバイダー独自の製品名に沿っているが、これが時に直感的ではない命名規則を生み出すことがある。例えば、AWS Lambdaのアイコンは「aws-lambda」ではなく「aws-aws-lambda」というスラッグになる。最初の「aws」はコレクションのプレフィックスであり、2番目の「aws」は製品名の一部として扱われるためだ。このように、アイコンの名前を推測するのは難しいため、thesvg.orgが提供するJSON形式のレジストリを使って、必要なアイコンのスラッグを正確に検索することが推奨されている。このレジストリには、すべてのアイコンのスラッグ、タイトル、カテゴリが含まれており、これを利用すれば目的のアイコンを効率的に見つけることができる。一度スラッグが分かれば、/icons/{スラッグ}/{バリアント}.svgという決まったパスでアイコンにアクセスできる。

アイコンを利用する上で最も注意すべきは「ライセンス」の問題である。特にAWSのアイコンは「CC-BY-ND-2.0」というライセンスが適用されており、これは「表示-継承-改変禁止（No Derivatives）」を意味する。平たく言えば、アイコンはそのままの形で利用し、著作権表示をすれば共有できるが、アイコンの色を変更したり、一部を切り取ったりといった「改変」は許可されていない。例えば、システムのテーマカラーに合わせてAWSアイコンを再着色することはできない。一方、AzureのアイコンはMITライセンス、Google CloudのアイコンはApache-2.0ライセンスが適用されているが、いずれにしても各プロバイダーが別途公開している利用規約を必ず確認する必要がある。社内向けのアーキテクチャ図ではリスクが低いかもしれないが、顧客向けの製品ページなどでアイコンを使用する場合は、特に注意が必要となる。

これらのSVG形式のアイコンファイルは、さまざまな場面で役立つ。例えば、GitHubのREADMEファイルにシステムの構成図を埋め込みたい場合、HTMLの<img>タグを使ってthesvg.orgのURLを直接指定するだけで、アイコンを表示できる。プレゼンテーション資料やデザインツール（Figmaなど）で、拡大しても劣化しないベクター画像として利用することも可能だ。また、設定ファイルから自動的に構成図を生成するようなスクリプトを組む場合にも、安定したファイルパスでアイコンを取得できるのは大きな利点となる。アイコンのファイルサイズも比較的小さいため、ウェブページへの埋め込みによる表示速度への影響もほとんど心配ない。安定した利用のためには、必要となるアイコンファイルを一度ダウンロードし、プロジェクトのドキュメントと一緒にバージョン管理システムにコミットしておくのが良い方法である。これにより、ネットワークの状況に左右されず、いつでも図が正しく表示されるようになる。

複数のクラウドプロバイダーのアイコンを一つの図にまとめる「マルチクラウド構成図」を作成する際には、見た目の不統一が課題になることがある。AWSのアイコンは色付きのバッジの中に収まっている一方、Azureのアイコンはより平坦なデザインで、Google Cloudのアイコンは枠がなく、より広い色使いが特徴だ。これらを並べると、デザインスタイルの違いが読み手に混乱を与える可能性もある。しかし、AWSのアイコンはライセンスの制約により改変できないため、色を統一することは難しい。この問題に対処するには、レイアウトの工夫が重要となる。例えば、各プロバイダーのサービス領域を明確に線で区切ったり、それぞれにラベルを付けたりすることで、意図的なグループ分けであることを示すことができる。また、すべてのアイコンを同じレンダリングサイズで表示することで、統一感を出すことも可能だ。このように、レイアウトを工夫することで、アイコンスタイルの違いが図のメッセージを妨げることなく、情報を整理して伝えることができるだろう。

クラウドサービスのアーキテクチャアイコンは、システム設計を視覚的に表現するための強力なツールである。ファイル自体の入手はthesvg.orgのようなサービスを利用すれば簡単だが、アイコンのスラッグの命名規則や、特にライセンス条件、中でもAWSの「改変禁止」ライセンスには細心の注意を払う必要がある。これらの点を理解し、適切にアイコンを活用することで、システムエンジニアとしての設計能力やコミュニケーション能力をさらに高めることができるだろう。必要なアイコンは、ドキュメントと一緒にバージョン管理システムにコミットし、いつでも参照できるようにしておくのが賢明な方法だ。