インフラ基本設計における Kiro Powers の活用
目次：インフラ基本設計における Kiro Powers の活用
- 1. はじめに
- 2. インフラ基本設計における課題
- 3. Kiro Powers によるインフラ基本設計支援
: Kiro Powers の概要とカスタム Power の利用
- 4. カスタム Power 設計上の工夫
: 動的コンテキスト管理の詳細 - 5. 具体的な使用例
: アカウント構成設計のワークフロー - 6. おわりに
1. はじめに
インフラ構築プロジェクトにおける基本設計フェーズは、プロジェクト全体の品質と成功を左右する重要な工程です。AWS Well-Architected Framework（以降「W-A」と表記する）の 6 本柱（運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性）に基づいた設計検討、技術選定の根拠整理など、多岐にわたる作業が必要となります。経験豊富なアーキテクトであっても、これらの作業には多くの時間を要します。特に以下のような課題があります。
- AWS 公式ドキュメントの調査と最新情報のキャッチアップ
- W-A 6 本柱の観点を漏れなく検討する網羅性の確保
- 社内やプロジェクト固有のルール、設計指針による制約事項の把握
特に、社内やプロジェクト固有の設計ルールに初めて触れるエンジニアにとっては、それらの理解が大きな壁となり、ベテラン社員への問い合わせが頻発し、双方の生産性を低下させる要因となっていました。本記事では、これらの課題に対して、Kiro Powersを活用したインフラ構築時の基本設計の効率化と品質向上の取り組みを紹介します。
2. インフラ基本設計における課題
インフラ構築プロジェクトにおける基本設計フェーズの課題について説明します。
① 最新情報のキャッチアップ
AWS は頻繁にサービスのアップデートやベストプラクティスの更新を行っており、常に最新の情報を把握し、設計に反映することは大きな負担となっていました。
● ベストプラクティスの調査負担
W-A 6 本柱それぞれのベストプラクティスは日々更新されており、以下の観点で最新情報を調査することに多大な労力がかかる。
- 情報の分散: AWS 公式ドキュメント、ブログなど情報源が多岐にわたる
- 調査時間: 特定のサービスのベストプラクティスを調べるだけで、数時間を要することもある
- 情報の鮮度: 過去の知識が古くなっている可能性があり、常に最新情報を確認する必要がある
② 検討項目の漏れによる手戻り
W-A は、6 本柱から構成される包括的な設計フレームワークです。これらの観点を漏れなく検討することは、品質の高いインフラ設計に不可欠です。
しかし、基本設計では各設計要素間に多様な依存関係が存在します。例えば、以下のような依存関係があります。
- アカウント構成で決めたマルチアカウント戦略が、ネットワーク設計の VPC 構成に影響
- ネーミングルールで定めた命名規則が、すべてのリソース設計に波及
- セキュリティ統制方針で決めた暗号化要件が、データベース設計やストレージ設計に制約を与える
これらの依存関係を把握し整合性を保ちながら設計を進めるには、相応の労力と時間を要し、検討漏れが発生すると後工程での手戻りリスクが高まります。
③ 社内やプロジェクト固有のルールによる制約事項の把握と設計への反映
多くの企業では、AWS 標準サービスに加えて、社内やプロジェクト固有のルールを運用しています。これらの固有のルールを理解し、設計に反映するには、相応の学習時間と労力が必要です。特に、社内やプロジェクト固有の設計ルールに初めて触れるエンジニアにとって、この学習コストは大きな壁となっています。
これらの課題に対して、Kiro Powers を活用した新しいアプローチを導入することで、基本設計フェーズの効率化と品質向上を図ることが可能です。 次章では、その具体的な解決策について解説します。
3. Kiro Powers によるインフラ基本設計支援
本章では、Kiro Powers の概要と、インフラ基本設計のために作成したカスタム Power の構成について解説します。
3.1 Kiro Powers の概要
Kiro Powers は、プロジェクト特化型の支援機能をパッケージ化したものです。ドキュメント、ワークフローガイド（steering files）、MCP（Model Context Protocol）サーバーを組み合わせることで、特定のタスクを効率化します。
● Kiro Powers の構成要素
Kiro Powers は以下の 3 つの要素で構成されます。
| 構成要素 | 役割と機能 |
|---|---|
| 1. ドキュメント（POWER.md） | Power の概要と使い方を記述 AI エージェントが参照するメタデータとして機能 利用可能な機能やワークフローの一覧を提供 |
| 2. ワークフローガイド （steering files） |
具体的な作業手順や設計指針を記述 社内やプロジェクト固有のルールの組み込み 必要なタイミングで動的に読み込まれる |
| 3. MCP サーバー | 外部システムやデータソースとの連携 リアルタイムな情報取得 AWS 公式ドキュメントなどの最新情報へのアクセス。 |
● 従来のプロンプトベースのアプローチの限界
従来の AI エディタでは、社内ルールや作業手順などの前提情報をプロンプトに都度埋め込む運用が一般的です。この運用スタイルが、2 つの構造的な問題を引き起こします。
- コンテキスト肥大化 → 品質劣化・コスト増大: 前提情報をすべてプロンプトに含めるほど、コンテキストは膨らみ続けます。トークン数が増えるにつれて重要な情報が埋もれ、AI の応答精度が落ちます。さらに、大量のコンテキストを毎回送信するため、LLM の API コストも比例して増大します。
- プロンプトの属人化・肥大化 → 保守性の低下: プロンプトへの都度埋め込みを続けると、誰がどの情報を追加したのか把握しにくくなり、属人化が進みます。結果として以下の問題が発生します。
- プロンプトの更新・メンテナンスが困難
- どの情報が実際に使われているか不明確
- プロジェクトごとのカスタマイズが煩雑
● Kiro Powers による解決
Kiro Powers は、これら 2 つの問題の原因である「前提情報の都度埋め込み」というプロンプトベースの運用課題を解消します。
動的コンテキスト管理：必要な情報を必要なタイミングで動的に読み込みます。POWER.md がメタデータとして機能し、LLM が状況に応じて適切な steering ファイルを選択・参照します。常に最小限のコンテキストで動作するため、品質劣化とコスト増大を防ぎます。
構造化された外部ファイル管理：前提情報は steering ファイルとして外部化・構造化して管理します。更新箇所が明確になり、プロジェクトごとのカスタマイズも容易になるため、保守性の低下を解消します。
3.2. カスタム Power の概要
Kiro Powers は、AWS が提供する Power をインポートして使用できるほか、サードパーティーが提供する Power を Git の Public リポジトリからインポートしたり、自身で作成した Power をローカルフォルダからカスタム Power としてインポートすることも可能です。今回はインフラ基本設計の効率化と品質向上を目的として、以下の特徴を持つカスタム Power を独自に作成しました。
3.2.1. カスタム Power の特徴
①10 階層・2 段階ワークフロー
インフラ構築プロジェクトにおける基本設計フェーズのプロセスを、10 の階層に分けて定義しました。各階層は依存関係を考慮して順序付けられており、段階的に設計を進めることができます。
10 階層の構成：
各階層では、2 段階のワークフローを実施します。
- Phase1（技術調査）: 内部レビュー用の技術資料を作成。W-A 6 本柱の検討項目一覧、アーキテクチャ提案（パターン A/B/C）、AWS 公式ドキュメント参照、W-A 準拠チェックリストを含む
- Phase2（顧客説明資料）: Phase1 の内部レビュー完了後、顧客への説明と合意形成のための資料を作成。打合せアジェンダ、説明資料を含む
②W-A 6 本柱に基づく設計支援
W-A の 6 本柱に基づいた設計支援を提供します。各階層の設計において、6 本柱の観点から検討すべき項目を明示し、検討漏れを防ぎます。
③AWS 公式ドキュメントの組み込み
AWS Documentation MCP Server を使用することで、設計時に最新の AWS 公式ドキュメントから以下の情報を参照することができます。
- サービスのベストプラクティス
- 最新機能の情報
- セキュリティガイドライン
- アーキテクチャパターン
これにより、日々更新される AWS の情報を効率的にキャッチアップし、設計に取り込むことができます。
④ 社内やプロジェクト固有のルールの組み込み
社内やプロジェクト固有のルールや設計指針を steering ファイルとして組み込み、組織固有の制約を設計に取り込むことができます。
これにより、社内やプロジェクト固有のルールに詳しくないエンジニアでも、それらを効率的に設計に取り込むことができます。
3.2.2. カスタム Power の構造
今回作成したカスタム Power のディレクトリ構成は以下の通りです。
powers/architect-helper/
├── POWER.md # Powerの概要とメタデータ
├── mcp.json # MCPサーバー設定
└── steering/
├── 00-output-format.md # 出力フォーマット定義
├── 01-intake.md # 情報抽出（提案書/見積書）
├── 10-layer1-account-separation.md # 第1階層: アカウント分離
├── 20-layer2-user-management.md # 第2階層: ユーザー管理
├── 30-layer3-naming-rules.md # 第3階層: ネーミングルール
├── 40-layer4-security-control.md # 第4階層: セキュリティ統制
├── 50-layer5-network-separation.md # 第5階層: ネットワーク分離
├── 60-layer6-compute-service.md # 第6階層: コンピュート
├── 70-layer7-domain-configuration.md # 第7階層: ドメイン構成
├── 80-layer8-backup-restore.md # 第8階層: バックアップ
├── 90-layer9-log-collection.md # 第9階層: ログ取得
└── 100-layer10-operation-monitoring.md # 第10階層: 運用・監視
各 steering ファイルには、以下の情報を記載しています。
- 階層の目的と検討範囲
- W-A 6 本柱の観点からの検討項目
- 依存する階層との関係性
- 社内やプロジェクト固有のルールや設計指針
- AWS 公式ドキュメント参照の指示
このように、Kiro Powers のカスタム Power を活用することで、各階層で検討すべき事項を明確に定義し、技術調査に必要な情報とワークフローをパッケージ化しました。次章では、このカスタム Power の作成における工夫点について詳しく解説します。
4. カスタム Power 設計上の工夫
前章で紹介したカスタム Power の作成において、いくつかの重要な設計上の工夫を行いました。本章では、これらの工夫点について詳しく解説します。
第 3 章で述べた通り、従来のプロンプトベースのアプローチでは、コンテキスト肥大化による品質劣化・コスト増大と、プロンプトの属人化・肥大化による保守性の低下が課題でした。Kiro Powers は、動的コンテキスト管理によってこれらの課題を解決します。
4.1. POWER.md による段階的な情報読み込み
Kiro Powers を使用する際、AI エージェントはまず POWER.md を読み込みます。POWER.md はフロントマター（ヘッダー）とメインコンテンツで構成されています。フロントマター（YAML 形式）には、Power の基本情報が記載されています：
--- name: "architecture-design-assistant" displayName: "基本設計アシスタント" description: "提案/見積資料から、AWS Well-Architected Framework 6本柱に基づいた階層的な基本設計を支援する" keywords: ["基本設計", "インフラ設計", "アーキテクチャ", "Well-Architected", "W-A"] ---
このヘッダー情報により、AI エージェントは以下のように動作します。
- Power の目的と適用範囲を理解
- キーワードから関連性を判断
- 適切な Power を選択
メインコンテンツには、以下の情報が記載されています。
- Power の目的と全体像
- 利用可能な steering ファイルの一覧とリンク
- 各階層の目的と検討範囲
- 階層間の依存関係
- 基本的な使い方（ワークフローの概要）
POWER.md の設計方針
POWER.md は、Power の「目次」や「インデックス」としての役割に徹するように記述しています。詳細な手順や具体的な検討項目は、各 steering ファイルに記述しています。この設計により、詳細情報は必要なときだけ steering ファイルから読み込み、コンテキストの肥大化を防いでいます。AI エージェントは、この POWER.md を参照することで、どの steering ファイルを読み込むべきかを判断します。
LLM による動的判断
AI エージェントが現在の作業内容を理解し、必要な情報を動的に判断します。例えば、
- ネットワーク設計時には、第 5 階層の steering ファイルのみを読み込む
- 依存関係がある場合は、関連する階層の決定事項を参照
- AWS の最新情報が必要な場合は、MCP サーバーを通じてドキュメントを検索
必要な情報を必要なタイミングで読み込み
以下の仕組みにより、常に最小限のコンテキストで作業を進めることができます。
- 現在の階層に関連する情報のみをロード
- 過去の決定事項は必要に応じて参照
- AWS 公式ドキュメントはリアルタイムで検索
- 社内やプロジェクト固有のルールは該当する場合のみ参照
上記の工夫により、コンテキストの肥大化を防ぎながら、必要な情報にアクセスできる環境を実現しています。次に具体的な steering ファイルの工夫点について解説します。
4.2. steering ファイルの設計における工夫
設計の品質と効率を両立するため、steering ファイルに以下 4 つの工夫を組み込みました。
① 階層的アプローチによる設計の構造化
10 階層に分けた段階的な設計プロセス
インフラ基本設計を 10 の階層に分割することで、従来の設計プロセスを構造化しました。
階層分割の利点
- 段階的な設計: 各階層を順番に進めることで、設計の抜け漏れを防止
- コンテキストの分割: 1 つの階層に必要な情報のみを読み込むことで、AI エージェントのコンテキスト肥大化を防止
10 階層の構成（再掲）
- アカウント分離・管理方針
- ユーザー管理・認証方針
- ネーミングルール
- セキュリティ統制方針
- ネットワーク分離・管理方針
- コンピュート・サービス設計
- ドメイン構成方針
- バックアップ・リストア方針
- ログ取得方針
- 運用・監視方針
依存関係の明確化
各階層は、前の階層の決定事項に依存する構造になっています。
依存関係の例
- 第 3 階層（ネーミングルール） は、第 1 階層（アカウント分離） で決定したアカウント構成を前提とする
- 第 5 階層（ネットワーク分離） は、第 1 階層（アカウント分離） と 第 4 階層（セキュリティ統制） の決定事項を考慮する
- 第 10 階層（運用・監視） は、すべての階層の決定事項を統合する
この依存関係を明確にすることで、以下を実現しています。
- 設計の整合性を保ちやすい
- 手戻りを最小限に抑える
- レビュー時に確認すべきポイントが明確になる
② 2 段階ワークフローによるヒューマンレビュープロセスの挿入
各階層の設計を 2 段階のワークフローで進めることで、AI エージェントが生成した設計案に対して、適切なタイミングでヒューマンレビューを挿入し、品質を担保します。
Phase1: 技術調査資料の作成
AI エージェントが、W-A 6 本柱に基づく検討項目の整理、複数のアーキテクチャパターン提案、AWS 公式ドキュメント参照を含む技術資料を生成します。レビュアーがこれを検証し、技術的な妥当性を確認します。
Phase2: 顧客説明資料の作成
Phase 1 のレビュー完了後、AI エージェントが顧客向けの説明資料、打ち合わせアジェンダのテンプレートを生成します。これにより、顧客との合意形成をスムーズに進めることができます。
AI エージェントは設計案の作成を支援しますが、最終的な判断と承認は人間が行います。この仕組みにより、AI の効率性と人間の判断力を組み合わせた高品質な設計プロセスを実現しています。
③ MCP 利用によるリアルタイム情報取得
AWS Documentation MCP Server の利用
AWS の公式ドキュメントは日々更新されており、最新の情報を常に把握することは困難です。AWS Documentation MCP Server を利用することで、この課題を解決しました。
各 steering ファイルには、AWS のベストプラクティスやサービスの詳細は記載していません。AI エージェントは、設計の各段階で必要に応じて MCP Server を通じて AWS 公式ドキュメントを検索・参照します。
この設計により、以下を実現しています。
- コンテキストの節約: steering ファイルは簡潔に保たれ、AI エージェントのコンテキストを圧迫しない
- 最新情報の活用: MCP Server を通じて、常に最新の AWS ドキュメントを参照でき、古い情報に基づく設計を防ぎ、最新のベストプラクティスを適用できる
- 検索効率化: AI エージェントが自動的に関連ドキュメントを検索。複数のドキュメントを横断的に参照し、見落としがちな関連サービスの情報も見逃さない
④ 社内やプロジェクト固有のルールや設計指針の組み込み
社内やプロジェクト固有のルールや設計指針を steering ファイル化
多くの企業では、AWS 標準サービスに加えて、社内やプロジェクト固有のルールや設計指針を運用しています。これらの情報を steering ファイルとして Power に組み込むことで、組織固有の制約を考慮した設計が可能になります。
組み込んだ固有のルール、設計指針の例
- プロジェクト固有のネーミング規則
- 社内標準の VPC 構成
この設計により、以下を実現しています。
- 問い合わせ削減: ベテラン社員への問い合わせが減少
- 設計品質の均質化: 経験の浅いエンジニアでも、steering ファイルのガイドに従うことで一定水準以上の設計品質を確保
カスタム Power 作成時のこれらの設計上の工夫により、品質とスピードを両立した基本設計プロセスを実現しました。
5. 具体的な使用例：アカウント構成設計のワークフロー
本章では、第 1 階層「アカウント分離・管理方針」を例に、カスタム Power を使った実際のワークフローを紹介します。第 2 階層以降も同様のワークフローで進めます。
事前準備として、カスタム Power をインポートし、見積資料・提案書をプロジェクトフォルダに配置します。
① 技術調査資料の作成
Kiro IDE のチャットでインフラ基本設計をしたい旨を入力するとカスタム Power が有効化され、POWER.md が読み込まれます。さらに、アカウント構成設計をしたい旨を入力すると Phase 1 が開始し、AI エージェントが自律的に以下の作業を行います。
- 見積資料・提案書から設計インプット（背景・スコープなど）を抽出
10-layer1-account-separation.mdを参照し、W-A 6 本柱の観点から検討項目を整理- AWS Documentation MCP サーバーで公式ドキュメントを調査し、設計の根拠を整理
- 複数のアーキテクチャパターン（A/B/C）を提案
- W-A 準拠チェックリストで各パターンを評価
00-output-format.mdに従って技術調査資料を作成
最後に、生成された技術調査資料をレビュアーが確認します。技術的な正確性、公式ドキュメント引用の妥当性、評価の適切さを検証する、品質担保の重要なプロセスです。レビュー完了後、Phase 2 へ移行します。
② 顧客説明資料の作成と設計判断
顧客説明資料の作成
レビュー済みの技術調査資料と 00-output-format.md の出力フォーマットに基づき、AI エージェントが顧客説明用の資料を作成します。ここでもヒューマンレビューを挿入し、技術的な妥当性と期待したフォーマットへの準拠を確認します。
顧客説明と設計判断
Phase 2 で作成した説明資料をベースに構成案を顧客に説明し、設計判断を行います。決定事項は決定ログとして記録します。
決定ログの例:
| 決定日 | 決定事項 | 採用パターン | 決定理由 |
|---|---|---|---|
| 2026/01/25 | アカウント分離方針 | 顧客企業別完全分離 | セキュリティ要件と将来の高セキュリティ要件業種への展開を考慮 |
| 2026/01/25 | Control Tower 利用 | 利用する | ガバナンス自動化と運用効率化のため |
| 2026/01/25 | IAM Identity Center | 利用する | SSO による認証管理の効率化のため |
この決定ログを後段の設計（第 2 階層以降）で参照することで、設計全体の整合性を保ちます。例えば、第 3 階層「ネーミングルール」では、ここで決定したアカウント分離方針に基づいてアカウント命名規則を設計します。
6. おわりに
本記事では、Kiro Powers を活用したインフラ基本設計フェーズの効率化と品質向上について解説しました。
今後の展望
本記事ではインフラ構築の基本設計フェーズに焦点を当てましたが、今後は構築フェーズやテストフェーズへと展開していきます。基本設計で作成した成果物を起点として、IaC コードの自動生成支援、テストケースの自動生成など、プロジェクト全体を通じた効率化を目指します。段階的なアプローチで各フェーズの支援用のカスタム Power を作成し、最終的にはプロジェクト全体を統合的に効率化する仕組みを構築していく予定です。
最後に
Kiro Powers は、単なる作業効率化ツールではありません。組織的なナレッジを体系化し、誰もが活用できる形で提供することで、組織全体の設計品質を向上させる基盤となります。会社や過去のプロジェクトのノウハウを若手が活用でき、教訓が次のプロジェクトに活かされる、このような組織的なナレッジ管理の仕組みが、持続的な業務効率化と品質向上に寄与します。Kiro Powers を通じて、多くの組織で、業務効率化とナレッジ管理の新しい形を実現していただければ幸いです。
著者：並木 飛鳥
前職は空調機器メーカーの機械系 CAE（振動解析）エンジニア。現在は AWS を活用したクラウドインフラの設計・構築に携わり、マルチアカウント標準環境の整備や DR 対応などの業務を通じ、お客様のクラウド基盤を支えている。
