はじめに
前回のシリーズ（全3部）では、KiroのVibeモードとSpecモードを使ってCloudFormationの品質を検証しました。プロンプトに「Well-Architected準拠」の一文を追加するだけで12点→26点に跳ね上がること、Specモードなら30点満点が取れることを確認しています。
その第1部の余談で、AWS公式のCFnサンプルリポジトリを参照させたら むしろスコアが下がった（23点） という結果も報告しました。
今回はその続編です。2026年5月に公開された Well-Architected Skills & Steering（aws-samples/sample-well-architected-skills-and-steering）を導入して、同じWEB三層アーキテクチャの生成でスコアがどう変わるかを検証しました。
Well-Architected Skills とは
AWS Well-Architected Framework の307のベストプラクティスをAIコーディングエージェントに教え込む、オープンソースのスキル＆ステアリング集です。Kiro・Claude Code・Cursor など14ツールに対応しています。
Kiroの場合：
-
steering (
well-architected.md) — 常にロードされるコンテキスト。WAに関する話題が出たときに適切なスキルへルーティングする -
skills (
wa-review/SKILL.md) — 307 BPに基づいたWAレビューを実行するステップバイステップのプレイブック
インストールは1コマンド：
# Windows PowerShell
& ([scriptblock]::Create((irm https://raw.githubusercontent.com/aws-samples/sample-well-architected-skills-and-steering/main/bootstrap.ps1))) -Tool kiro
検証環境
- ツール：Kiro IDE（Vibe coding）
- モデル選択：Auto
- IaC：AWS CloudFormation
- リージョン：ap-northeast-1（東京）
- Skills：sample-well-architected-skills-and-steering v5.2.0
- 採点：前回と同じ30項目チェック（score_templates.py）
- 検証日：2026年7月
実験設計
前回との比較を公平にするため、パターンごとに新しいフォルダでKiroを起動し、互いの文脈が引き継がれない状態で実行しました。
| パターン | SKILL | プロンプト | 目的 |
|---|---|---|---|
| D | ✅ | 最小限（パターンAと同じ） | インストールだけでパターンAから改善するか？ |
| E | ✅ | WA準拠を指示（パターンBと同じ） | インストールだけでパターンBから改善するか？ |
| F | ✅ | 最小→生成後にWAレビュー依頼→修正 | SKILLを能動的に使った場合の効果 |
パターンD：SKILL有り・WA指示なし
前回のパターンAと全く同じプロンプトを、SKILLがインストールされた環境で実行しました。SKILLを明示的に「使う」のではなく、インストールしてあるだけで品質が自動的に底上げされるかを確認するテストです。
プロンプト
ALB→EC2(Apache+Hello World)→RDS(MySQL 8.0)のWEB三層アーキテクチャを
CloudFormationで構築してください。
リージョンはap-northeast-1、EC2はAmazon Linux 2023を使用。
設計ドキュメントも作成してください。
パターンAと全く同じプロンプトです。
結果
Kiroの右側パネルに「Including Steering Documents: well-architected.md」と表示され、steeringの読み込みは確認できました。
しかし、スコアは11/30点。パターンA（12/30）とほぼ同じでした。
| 柱 | パターンA | パターンD |
|---|---|---|
| 運用上の優秀性 | 1/5 | 1/5 |
| セキュリティ | 2/5 | 2/5 |
| 信頼性 | 2/5 | 1/5 |
| パフォーマンス効率 | 2/5 | 2/5 |
| コスト最適化 | 3/5 | 3/5 |
| 持続可能性 | 2/5 | 2/5 |
| 合計 | 12/30 | 11/30 |
なぜ効かなかったのか
steeringファイルの中身を読むと答えが明確に書いてありました：
When to Apply
Apply this steering whenever the user:
- Asks for an architecture review or design feedback
- Mentions "Well-Architected" or "WA review"
つまりsteeringはルーティングテーブルであって、品質を自動で底上げするものではありません。「WAレビューして」と言われて初めてスキルを発動する仕組みです。
パターンE：SKILL有り・WA指示あり
パターンBと全く同じプロンプトを、SKILLがインストールされた環境で実行しました。SKILLを明示的に「使う」のではなく、インストールしてあるだけで前回のパターンBから何か改善されるかを確認するテストです。
プロンプト
ALB→EC2(Apache+Hello World)→RDS(MySQL 8.0)のWEB三層アーキテクチャを
CloudFormationで構築してください。
リージョンはap-northeast-1、EC2はAmazon Linux 2023を使用。
AWS Well-Architected Framework 6本柱に準拠してください。
設計ドキュメントも作成してください。
補足：今回の検証条件
今回はAWSアカウントには接続せず、ローカル実行のみで検証しています。そのため aws cloudformation validate-template は認証エラーになり、Kiroは自動で cfn-lint（ローカルのLintツール）にフォールバックしてバリデーションを完了しました。
SKILLは発動したか？
パターンDと同様、steeringファイル（well-architected.md）の読み込みは確認できました。しかし「Activated Skill: wa-review」の表示は出ておらず、wa-reviewスキルは発動していません。
steeringのルーティングテーブルは「WAレビューして」「セキュリティを評価して」のようなレビュー依頼の文脈でスキルを呼び出す設計です。「CloudFormationで構築してください」というCFn生成リクエストでは、スキルへのルーティングは起きません。結果として、パターンBとの差はSKILLの効果ではなくAI生成の非決定性（揺れ）の範囲です。
結果
23/30点。パターンB（26/30）より3点低い。
| 柱 | パターンB | パターンE |
|---|---|---|
| 運用上の優秀性 | 4/5 | 4/5 |
| セキュリティ | 5/5 | 4/5 |
| 信頼性 | 5/5 | 5/5 |
| パフォーマンス効率 | 4/5 | 3/5 |
| コスト最適化 | 4/5 | 4/5 |
| 持続可能性 | 4/5 | 3/5 |
| 合計 | 26/30 | 23/30 |
失点の原因：
-
SEC-3 (Secrets Manager) — cfn-lintが
W1011: Use dynamic references over parameters for secretsと指摘したが、Kiroが「テンプレートの簡便性を保つため」と判断してNoEchoパラメータのままにした（パターンBでは実装していたので、AIの非決定的な判断の揺れ） - PERF-2 (gp3 EBS) — LaunchTemplateのBlockDeviceMappingsが未定義
- OE-5 (ALBアクセスログ) — 未設定
パターンF：生成→WAレビュー→修正（SKILLの本来の使い方）
パターンEの生成物に対して、チャットで「このCFnテンプレートをWAレビューしてください」と依頼しました。
WAレビューの出力
wa-review スキルが発動し、1分25秒で以下が返ってきました：
- アーキテクチャ図（PlantUML）
- 6本柱のスコアカード
- 🔴 Critical & High Risk Findings（6件）
- 🟡 Medium Risk Findings（8件）
- Eisenhower Matrixによる優先順位付け
- 具体的な修正手順と労力見積
主な指摘：
| # | 重要度 | Finding | 労力 |
|---|---|---|---|
| 1 | 🔴 | HTTPS未対応 | 2時間 |
| 2 | 🔴 | DBパスワードがパラメータ管理 | 1時間 |
| 3 | 🔴 | WAF未設定 | 半日 |
| 4 | 🟡 | NAT GW単一AZ | 追加リソース定義 |
| 5 | 🟡 | アラーム通知先なし | 30分 |
| 6 | 🟡 | CloudTrail未有効 | 1時間 |
修正の実行
「指摘事項を修正して」と指示すると、Kiroは全10項目を一括で修正しました。cfn-lintでエラー・警告ゼロを確認するところまで自動で完了。
修正後のテンプレートは680行→1070行に増加。追加された要素：
- ACM証明書 + HTTPS Listener + HTTP→HTTPSリダイレクト
- Secrets Manager（32文字パスワード自動生成）
- AWS WAF v2 WebACL + 3 Managed Rules
- NAT Gateway 2AZ冗長化 + AZ別ルートテーブル
- SNS Topic + Email通知
- CloudTrail（マルチリージョン + S3 + ログ検証）
- ALBアクセスログ（S3出力）
- EBS暗号化（LaunchTemplate明示）
- cfn-signal + CreationPolicy
結果
26/30点。パターンB（26/30）と同点。
| 柱 | パターンE(修正前) | パターンF(修正後) | 変動 |
|---|---|---|---|
| 運用上の優秀性 | 4/5 | 5/5 | +1 |
| セキュリティ | 4/5 | 5/5 | +1 |
| 信頼性 | 5/5 | 5/5 | ±0 |
| パフォーマンス効率 | 3/5 | 4/5 | +1 |
| コスト最適化 | 4/5 | 3/5 | -1 |
| 持続可能性 | 3/5 | 4/5 | +1 |
| 合計 | 23/30 | 26/30 | +3 |
注目ポイント：COST-2（単一NAT GW）が❌になりました。WAレビューが「NAT GW単一AZは信頼性リスク」と指摘し、Kiroがそれに従って2台に冗長化した結果です。信頼性（REL）的には正しい修正ですが、コスト最適化の採点項目では「単一NAT GW」が加点対象なので失点しました。
ここが今回の重要な気づきです。前回のSpec B（30/30点満点）では、NAT Gatewayは単一のままでした。 Specモードでは設計フェーズで「コスト vs 信頼性」のトレードオフを解決した上で実装に入るため、柱同士が衝突しない。一方、WAレビューの指摘を機械的に全部修正すると、ある柱のスコアが上がる代わりに別の柱が下がる——という現象が起きます。
SKILLのWAレビューは指摘としては正確です。 しかし「どの指摘を採用し、どれを見送るか」のトレードオフ判断は、ビジネス要件を理解している人間がすべきだということです。
全パターン比較
| パターン | モード | SKILL | プロンプト | スコア |
|---|---|---|---|---|
| A | Vibe | ❌ | 最小限 | 12/30 |
| D | Vibe | ✅ | 最小限 | 11/30 |
| C | Vibe | ❌ | WA指示+公式サンプルURL | 23/30 |
| E | Vibe | ✅ | WA指示 | 23/30 |
| B | Vibe | ❌ | WA指示 | 26/30 |
| F | Vibe | ✅ | 最小→レビュー→修正 | 26/30 |
| Spec A | Spec | ❌ | WA指示 | 28/30 |
| Spec B | Spec | ❌ | 詳細仕様書 | 30/30 |
考察
SKILLは「入れるだけ」では効かない
パターンDの結果が全てを物語っています。SKILLのsteeringはルーティングテーブルであって、自動で品質を底上げする魔法ではありません。「WAレビューして」「セキュリティを確認して」といった明示的なリクエストがあって初めてスキルが発動します。
これは設計として正しい判断だと思います。すべてのCFn生成で307 BPを毎回チェックしたら、トークンコストが膨大になりますし、Hello Worldに対してWAFやCloudTrailを強制するのは過剰です。
SKILLの真価は「レビューサイクル」にある
パターンFの流れ——生成→レビュー→修正——が、このSKILLの想定する使い方です。README にも Assess → Remediate → Validate のサイクル図が書かれています。
生成（最小プロンプト）
↓
WAレビュー依頼（1分25秒で20件の指摘）
↓
修正依頼（全件一括修正 + cfn-lint検証）
↓
再レビュー（必要に応じて）
cfn-lint との組み合わせについて
パターンEでKiroがcfn-lintで循環依存やバージョン非推奨を自動修正する挙動が見られましたが、これはSKILL固有の機能ではなく、前回のシリーズでも同じ動きをしていたものです。SKILL起因の改善とは区別して捉えてください。
Vibeモードの天井は26点、でもSpecモードの30点とは意味が違う
SKILLの有無にかかわらず、Vibeモードでの最高スコアは26/30に留まっています。前回のSpec Bが30点満点を取れたのは、仕様書の段階でトレードオフを設計者が判断して解決していたからです。
今回のパターンFが26点止まりだったのは、SKILLの能力不足ではありません。WAレビューの指摘を全部採用した結果、NAT冗長化（REL↑ / COST↓）やGraviton未採用（レビューではLow Riskで後回しと判断）といったトレードオフが残っただけです。
つまり：
- Specモード：設計段階で人間がトレードオフを解決 → バランスの取れた満点
- SKILL + レビューサイクル：生成後に機械的に指摘 → 取捨選択は人間が必要
どちらが優れているかではなく、使いどころが違うということです。ゼロから設計するならSpecモード、既存のIaCをレビュー・改善するならSKILLのWAレビューが最適解です。
まとめ
| 期待 | 現実 |
|---|---|
| SKILLを入れれば自動で品質が上がる | steeringはルーティング用。明示的に聞かないと発動しない |
| SKILLがあればプロンプトのWA指示は不要 | WA指示なしだとパターンAと同等（11点） |
| レビュー→修正で満点が取れる | 26/30（指摘を全採用すると柱同士がトレードオフ） |
| SKILLはSpecモードの代替になる | ならない。設計フェーズでのトレードオフ解決はSpecモードが優位 |
Well-Architected Skillsは「魔法の杖」ではなく「レビューサイクルの武器」です。
- ゼロから設計する場合：Specモードで仕様書にトレードオフ判断を仕込む方がバランスの良い設計になる
-
既存IaCの品質チェック：SKILLの
wa-reviewで307 BPに基づいた構造化レビューが1分で返ってくる——これがSKILLの真価 - レビュー指摘の取捨選択：全部機械的に直すのではなく、ビジネス要件に基づいて人間が判断する
結局のところ、AIの出力品質を決めるのは「どこで人間が判断を入れるか」です。Specモードは設計段階で、SKILLはレビュー段階で、それぞれ人間の判断ポイントを提供してくれるツールだと理解するのが正しいでしょう。
検証コード
本記事の検証で使用したCFnテンプレート、設計ドキュメント、採点スクリプトはGitHubで公開しています。
-
pattern-4d/— パターンD（SKILL有り・WA指示なし） -
pattern-4e/— パターンE（SKILL有り・WA指示あり） -
pattern-4f/— パターンF（SKILL有り・WAレビュー後修正）
本記事のテンプレートはKiroの検証目的で生成したサンプルです。本番環境での使用については自己責任でお願いします。