こんにちは、開発グループの寺田です。
皆さんはAWSのアーキテクチャ図をどのように作っていますか？ Draw.ioやLucidchartを使っている方も多いと思いますが、「もっと楽に、かつ品質の高い図を作れないか」と感じたことはないでしょうか。
そこで今回はKiroとDraw.ioで楽にAWSのアーキテクチャ図を生成できるか検証してみます。今回の検証ではハイブリッドアプローチ（人間とKiroで役割分担する方法）に落ち着きましたが、ステアリングファイルの整備やプロンプトの工夫次第ではさらに自動化できる可能性を感じています。躓いた点も含めて共有します。
- この記事でわかること
- 前提条件
- Step 1：Draw.io拡張機能のインストール
- Step 2：.drawio ファイルの初期化
- Step 3：AWSアイコンライブラリの追加
- Step 4：今回の検証で躓いた点とステアリングによる改善
- Step 5：ステアリングファイルの配置
- Step 6：ハイブリッドアプローチで品質を高める
- 2ファイル構成の設計思想
- レイアウト方向の考察
- まとめ
- 参考リンク
この記事でわかること
- Kiroだけで完全生成しようとしたときに躓いた点とその原因
- ステアリングファイルを使った品質改善のアプローチ
- 現時点での現実的な落とし所（ハイブリッドアプローチ）
前提条件
- Kiroがインストール済みであること
- Draw.io拡張機能がインストール済みであること
Step 1：Draw.io拡張機能のインストール
KiroはVSCode互換の拡張機能をサポートしています。 Draw.ioをKiro内で動かすには 発行元がhediet の拡張機能を使います。
- Kiroの拡張機能パネルを開く（左サイドバーの四角いアイコン）
Draw.io Integrationで検索- hediet 製（ダウンロード数131K、★5）をインストール
Step 2：.drawio ファイルの初期化
拡張機能のコマンドから新規作成するのが最もシンプルです。
Ctrl+Shift+Pでコマンドパレットを開くDraw.io: New Fileと入力して実行- ファイル名を入力して保存
Draw.io GUIが起動すれば成功です。
Step 3：AWSアイコンライブラリの追加
Draw.ioにはAWSアイコンが組み込みライブラリとして内蔵されています。
- Draw.ioエディタ左サイドバー下部の「+ その他の図形」をクリック
- 検索ボックスに
AWSと入力 - AWS 19 にチェックを入れて「OK」
これで左サイドバーにAWS全カテゴリのアイコンが追加されます。
補足： AWS公式サイト（
https://aws.amazon.com/architecture/icons/）から最新のIcon packageをダウンロードして手動インポートする方法もありますが、AWS 19の組み込みライブラリで大半のユースケースをカバーできます。
Step 4：今回の検証で躓いた点とステアリングによる改善
Kiroにdraw.io XMLの生成を指示すると、レイアウトや接続線はある程度生成できます。 レイアウトや接続線はある程度生成できます。ただし今回の検証では、以下の問題が起きました。
| 問題 | 内容 |
|---|---|
| アイコンの色が出ない | AWS公式アイコンの色（fillColor）が正確に出力されない |
| 矢印ラベルが見づらい | ラベルが矢印の線の下に隠れてしまう |
| コンポーネントが枠からはみ出す | swimlaneの座標計算が不正確でコンポーネントが枠外に出る |
| 矢印が重なる | 複数のコンポーネントが同じ接続先を持つ場合に矢印が束になって重なる |
左：ステアリング設定前（汎用シェイプ・色なし） 右：ステアリング設定後（AWS公式アイコン・色付き）
各サービスのstyle値が長く複雑なため、正確な値が出力されないケースがあるようです。
たとえばLambdaの正確なstyle値はこうなります：
sketch=0;...gradientColor=#F78E04;gradientDirection=north; fillColor=#D05C17;strokeColor=#ffffff;... shape=mxgraph.aws4.resourceIcon;resIcon=mxgraph.aws4.lambda;
Before ステアリング設定前
After ステアリング設定後
この問題はステアリングファイルに正確な情報を与えることで改善できました。
Step 5：ステアリングファイルの配置
以下の2つのファイルを .kiro/steering/ に配置します。
ステアリングファイルの読み込みタイミング
Kiroのステアリングファイルには3つの読み込みモードがあります。ファイル先頭のフロントマターで設定します。
| モード | 読み込みタイミング | 設定方法 |
|---|---|---|
| Always | 全プロンプトで毎回 | フロントマターなし（デフォルト） |
| Conditional | 指定ファイルパターンに一致するとき | fileMatch を指定 |
| Manual | #ファイル名 で明示的に呼び出したとき |
inclusion: manual を指定 |
今回の2ファイルはそれぞれ以下のモードを推奨します。
drawio-aws-architecture.md（必須・汎用ルール）
.drawio ファイルを操作するときだけ自動読み込みされる fileMatch モードを設定します。コンテキストウィンドウへの影響を最小化するため、style値はハードコードせずルールのみを定義しています。
--- inclusion: fileMatch fileMatch: - "**/*.drawio" - "**/*.dio" description: "draw.ioでAWSアーキテクチャ図を生成する際のアイコン・レイヤー・エッジ・レイアウトのルール" --- # draw.io AWS アーキテクチャ図 生成ガイド Kiroが draw.io 形式のAWSアーキテクチャ図を生成する際に参照するガイドです。 --- ## 出力形式 - ファイル形式: `.drawio`（XML） - ルート構造は `<mxfile>` → `<diagram>` → `<mxGraphModel>` → `<root>` の順 --- ## アイコンの使用ルール ### 基本方針 - AWSサービスは必ず `shape=mxgraph.aws4.resourceIcon` を使用する - `style=rounded=1` や `style=shape=rectangle` などの汎用シェイプは使用禁止 - `resIcon=mxgraph.aws4.general` は汎用アイコンのため使用禁止 ### 変換・再生成時の必須ルール - 既存の `.drawio` ファイルや画像からの変換時も例外なく公式アイコンに置き換えること - コンポーネント名からサービスを判断し、下記の対応表を必ず参照すること ### スタイル設定 - アイコンの正確な style 値が不明な場合は、draw.io上で該当アイコンを配置し 「スタイルを編集」で取得してから使用する - アイコンサイズは `width="60" height="60"` に統一する（余白確保のため） - ラベルはアイコン下部に配置する（`verticalLabelPosition=bottom;verticalAlign=top`） > 詳細な style 値一覧が必要な場合は `drawio-aws-styles.md`（オプション）を参照 --- ## ラベルの視認性ルール - ラベルの文字色は `fontColor=#232F3E` に統一する - ラベルの背景色は `labelBackgroundColor=#ffffff` を必ず指定する（暗い背景色との重なりを防ぐ） - フォントサイズは `fontSize=11` 以上を維持する - レイヤー名は `fontStyle=1;fontSize=13` で太字表示する - swimlane のヘッダーテキストは `fontColor=#000000` で黒字に統一する ### 矢印ラベルの配置ルール（必須） - ラベルは矢印の中央ではなく上側にオフセットして配置する（同一図内で統一する）： `<mxGeometry x="0" y="-20" relative="1" as="geometry">` - 全エッジのラベルに `labelBackgroundColor=#ffffff;labelBorderColor=none;fontSize=10;` を必ず付与する （線がラベルの上を通っても白背景でラベルが読める状態を保つ） - 複数の矢印が重なる箇所ではラベルの y 値をずらして重ならないようにする - 矢印ラベルのテキストは10文字以内に収める - 同一図内で全ラベルのオフセット方向を上側に統一する ### アイコンとラベルの分離ルール - アイコンの `value` は空文字（`""`）にしてアイコン自体にラベルを持たせない - ラベルは別途 `style=text;html=1;align=center;verticalAlign=top;fontSize=11;` の テキスト要素としてアイコンの直下に配置する - ラインはアイコン本体のみに接続し、テキスト要素には接続しない - これによりラインがラベルの上を通ることを根本的に防ぐ 例： <!-- アイコン本体（ラベルなし） --> <mxCell id="lambda1" value="" style="shape=mxgraph.aws4.resourceIcon; resIcon=mxgraph.aws4.lambda;..." vertex="1" parent="1"> <mxGeometry x="100" y="100" width="60" height="60"/> </mxCell> <!-- ラベルをテキスト要素として分離 --> <mxCell id="lambda1_label" value="Lambda（削除）" style="text;html=1;align=center;verticalAlign=top;fontSize=11;" vertex="1" parent="1"> <mxGeometry x="70" y="162" width="120" height="20"/> </mxCell> ### 矢印の接続点ルール - 接続元・接続先ともに `exitPerimeter=0;entryPerimeter=0;` を付与する （アイコン本体の辺から線が出入りするようにし、ラベル領域を避ける） - アイコン真下から線を引く場合は `exitX=0.5;exitY=1;exitDx=0;exitDy=0;exitPerimeter=0;` を指定する - アイコン真上に線を引く場合は `entryX=0.5;entryY=0;entryDx=0;entryDy=0;entryPerimeter=0;` を指定する --- ## レイヤー構成ルール - 関連するサービスは swimlane でグループ化する - レイヤーは上から下へ、処理の流れに沿って配置する - 推奨レイヤー構成（上から順に縦に並べる）： 1. クライアント / ブラウザ（AWS Cloud枠の外側・上部中央） 2. API層 3. コンピューティング層 4. データカタログ層 5. ストレージ層 - クライアントは必ずAWS Cloud枠の外側・上部中央に配置する（枠内に入れない） - レイヤーの背景色はカテゴリごとに統一する（同系色でも可） - レイヤー内のコンポーネントは必ず `parent="レイヤーのid"` で定義する - 全コンポーネントをAWS Cloud枠内に収めること（枠のサイズを内容物に合わせて調整する） --- ## エッジ（矢印）ルール - 全エッジは `edgeStyle=orthogonalEdgeStyle` で直角ルーティングに統一する - 用途に応じて以下を使い分ける： | 用途 | スタイル | |---|---| | 通常のデータフロー | 実線 | | ログ・モニタリング | 破線（`dashed=1`） | | 参照・読み取り | 点線（`dashed=1;endArrow=open`） | - レイヤーをまたぐエッジは `parent="1"` で定義する --- ## レイアウト原則 1. フローは上から下を基本とする 2. 同一レイヤー内のアイコン間隔は 40px 以上確保する 3. レイヤー間の間隔は 60px に統一する（均等間隔を保つ） 4. 矢印がレイヤー枠や他コンポーネントを横切らないようにルーティングする 5. 出力前に全コンポーネントの座標チェックを必ず行う： - 子コンポーネントの `x + width` が親 swimlane の `width` を超えていないこと - 子コンポーネントの `y + height` が親 swimlane の `height` を超えていないこと - swimlane の `height` = 最も下の子コンポーネントの `y + height + 40` - swimlane の `width` = 最も右の子コンポーネントの `x + width + 40` 6. AWS Cloud枠の `width` と `height` は全レイヤーを内包するサイズに設定する ### レイヤー横幅の統一ルール - 図内の主要レイヤー（コンピューティング層・データカタログ層・ストレージ層など）は 横幅を必ず統一する（異なる横幅は禁止） - 横幅の基準は全レイヤーの中で最も幅が必要なレイヤーに合わせる - 横幅を決定してから各レイヤーの width をその値に揃えてXMLを生成する - サブレイヤー（アクセスログ層など補助的な層）は例外として小さくて良い ### エッジの重なり防止ルール - 同一の接続先に複数のエッジが集まる場合、接続先の entryX を均等に分散させる： - 2本：0.3 / 0.7 - 3本：0.2 / 0.5 / 0.8 - 4本：0.1 / 0.35 / 0.65 / 0.9 - 同一の接続元から複数のエッジが出る場合、接続元の exitX も同様に分散させる - エッジ同士が視覚的に重なっていないことを出力前に確認すること ### テーブル・子リソースの配置ルール - 親リソース（S3 Tables等）に紐づくテーブル類（Inventory Table・Journal Table等）は 親リソースと同じ行に横並びで配置する - 縦に積み重ねる配置は避ける（レイヤーの縦幅が無駄に広がるため） --- ## グループ枠のスタイルルール - AWS Cloud枠のラベルは `fontSize=16;fontStyle=1` で太字・大きめに表示する - AWS Cloud枠のラベルは枠の上部中央に配置する（`verticalAlign=top;align=center`） - VPC・可用性ゾーンなどの枠ラベルは `fontSize=13;fontStyle=1` で統一する --- ## エクスポート設定 - PNG出力時は背景色を白（`#ffffff`）に設定する - 透過背景は使用しない ---
drawio-aws-styles.md（オプション・style値一覧）
manual モードを設定することで、#drawio-aws-styles と明示的に呼び出したときだけ読み込まれます。高品質な図が必要なときだけ参照させる運用に最適です。
--- inclusion: manual ---
主要サービスのstyle値（抜粋）：
# Lambda（オレンジ） sketch=0;...gradientColor=#F78E04;fillColor=#D05C17;strokeColor=#ffffff; ...shape=mxgraph.aws4.resourceIcon;resIcon=mxgraph.aws4.lambda; # S3（緑） sketch=0;...gradientColor=#60A337;fillColor=#277116;strokeColor=#ffffff; ...shape=mxgraph.aws4.resourceIcon;resIcon=mxgraph.aws4.s3; # API Gateway（紫） sketch=0;...gradientColor=#945DF2;fillColor=#5A30B5;strokeColor=#ffffff; ...shape=mxgraph.aws4.resourceIcon;resIcon=mxgraph.aws4.api_gateway;
style値の更新方法： AWSがアイコンを更新した際は、Draw.ioでアイコンを配置 → 右クリック →「スタイルを編集」でstyle値を取得して更新してください。
Step 6：ハイブリッドアプローチで品質を高める
ステアリングファイルを使っても、完全自動生成では以下の点に限界があることが検証を通じてわかりました。
| 限界点 | 内容 |
|---|---|
| アイコンの色 | style値が複雑なため正確な色が出ないケースがある |
| 矢印の重なり | 複数コンポーネントが同じ接続先を持つ場合に束になりやすい |
| ラベルの重なり | アイコンのラベルと矢印ラベルが重なりやすい |
| 枠のサイズ | swimlaneの座標計算がずれてコンポーネントが枠外に出ることがある |
これらを踏まえ、以下のハイブリッドアプローチを推奨します。
① Kiroがアイコン一覧と構成を指示
↓
② KiroがXMLを生成（レイアウト・接続線・レイヤー構成）
↓
③ Draw.ioで手動微調整
- 色付きアイコンへの差し替え
- 矢印の重なり解消
- ラベル位置の調整
- 枠からはみ出したコンポーネントの修正
↓
④ 完成図をエクスポート（PNG/SVG）
Kiroが担うのは構成の把握・XMLの生成・ルールの適用であり、細かい座標やビジュアルの仕上げは人間が担当する役割分担です。この分業により、ゼロから手動で作るよりも大幅に工数を削減できます。
Kiroへの指示例（初回）
architecture.drawioを生成してください。 drawio-aws-styles.md を参照し、 以下の構成でAWS公式アイコンを使ったアーキテクチャ図を作成してください。 構成： - API Gateway → Lambda × 3 → CloudWatch（ログ） - Lambda → Athena → Glue → Lake Formation - Athena結果 → S3バケット - S3 Tables → Inventory Table / Journal Table
2ファイル構成の設計思想
ステアリングファイルを2つに分けた理由はコンテキストウィンドウの効率化です。
| ファイル | 役割 | 読み込みモード |
|---|---|---|
drawio-aws-architecture.md |
汎用ルール・原則 | fileMatch（.drawio操作時のみ） |
drawio-aws-styles.md |
style値一覧 | manual（明示的に呼び出した時のみ） |
汎用ルールは .drawio ファイル操作時のみ自動で読み込まれ、style値は #drawio-aws-styles と明示的に呼び出したときだけ参照されます。この設計により、普段のコンテキストを節約しつつ必要なときに詳細な情報を参照できます。 また今回の検証でわかったことですが、ステアリングファイルは一度書いて終わりではなく、生成結果を見ながら繰り返し改善していくものです。新たな問題が見つかるたびにルールを追加・修正することで品質が徐々に安定していきます。
レイアウト方向の考察
今回は上から下（トップダウン）のレイアウトを採用しましたが、これはAWSの公式ドキュメントやホワイトペーパーでも最もよく使われる形式で、リクエストフローやAPI構成の可視化に適しています。
ただし構成の性質によってレイアウト方向を使い分けると、より伝わりやすい図になります。
| レイアウト | 適したユースケース | 例 |
|---|---|---|
| 上から下 | リクエストフロー・API構成 | API Gateway → Lambda → DB |
| 左から右 | データパイプライン・ETL | S3 → Glue → Athena |
| 中心から外側 | ネットワーク・VPC構成 | Transit Gateway中心の構成 |
今回のアーキテクチャは「クライアントのリクエストが各レイヤーを経由してストレージに至る」フローなので、上から下が自然な選択でした。
ステアリングファイルを用途別に分ける構成も有効です。たとえばデータパイプライン専用の drawio-aws-pipeline.md を別途用意しておくと、構成の種類が増えても汎用ファイルを肥大化させずに済みます。
まとめ
| 課題 | 解決策 |
|---|---|
| Kiroが生成するアイコンに色がつかない | ステアリングファイルにstyle値を定義する |
| style値の更新が大変 | draw.ioで「スタイルを編集」から随時取得する |
| ステアリングファイルが肥大化する | ルールとstyle値を2ファイルに分離する |
| 矢印が交差して見づらい | orthogonalEdgeStyle をルールとして定義する |
| 矢印ラベルが線に隠れる | ラベルを矢印の上側にオフセット配置・白背景を指定する |
| 矢印ラベルが線の下に隠れる | ラベルを矢印の上側にオフセット配置し白背景を付与する |
| 複数の矢印が束になって重なる | 接続先の entryX を分散させる・ラベルの y 値をずらす |
KiroとDraw.ioの組み合わせは、一度環境を整えてしまえばアーキテクチャの変更をプロンプト1つで図に反映できるようになります。ステアリングファイルは今回紹介した内容をベースに、プロジェクトの構成に合わせてカスタマイズしてみてください。
