ドキュメント作成が苦手な人へ：
Kiro CLIで作るAWS構成ドキュメント

はじめに

こんにちは！クラウド活用推進担当の安田です。

AWS管理マニュアル、作るのが面倒だと感じたことはないでしょうか？今回はAIでドキュメント作成を効率化してみた内容を紹介します。

ドキュメント作成には発表されたばかりのKiro CLIを利用しました。AWS CLIで環境を調査しながら、自動的にドキュメントを作成してくれます。これだけでも十分便利だったのですが、ある日カスタムエージェント機能の存在を知りました。特定タスク専用にカスタマイズしたAIエージェントを作れる機能です。

さらに「ドキュメント作成専用エージェントを作ったら、もっと楽になるのでは？」と思い、実際に検証してみました。同じシステムに対して、通常のKiro CLIとカスタムエージェント、両方でマニュアル作成を依頼し、情報収集の完全性、作業時間、ドキュメント品質を比較しました。

目次

1. 検証内容
2. エージェントなし vs エージェントあり
3. カスタムエージェントの効果
4. まとめ
5. 参考リンク

検証内容

対象システム

Microsoft Teamsに毎日AWS SAA練習問題を投稿するBot。平日8:30に問題、12:30に解答を自動投稿します。

使用サービス

・Lambda（問題生成・解答生成、本番2関数+テスト2関数）
・EventBridge Scheduler（定期実行）
・DynamoDB（問題保存）
・Amazon Bedrock（Claude 3.5 Sonnet、Nova Pro）
・Systems Manager（平日判定）

以下の構成で問題投稿を行います。

検証方法

同じシステムに対して、以下の2パターンでドキュメント作成を依頼しました：

パターン1：エージェントなし
通常のKiro CLIに上記の指示を出す

パターン2：エージェントあり
AWS構成ドキュメント作成専用エージェントに上記の指示を出す

エージェントなし vs エージェントあり

情報収集の完全性

エージェントなし

エージェントあり

ドキュメントの構成

エージェントなし

情報は収集できるものの、構成は毎回指示する必要がありました：

・「運用手順は不要です」
・「本番環境とテスト環境を分けて記載してください」
・「表形式で整理してください」

エージェントあり

エージェントに以下の様式を事前に設定していたため、最初から整理されたドキュメントが生成されました：

作業時間の比較

カスタムエージェントの効果

1. 情報収集の確実性

今回は比較的シンプルな構成のシステムでしたが、エージェントありでは情報が取れなかったり見逃したりすることがありませんでした。

より複雑なシステムでの効果：

・VPC、サブネット、セキュリティグループが複雑に絡むシステム
・複数リージョンにまたがるシステム
・10以上のAWSサービスが連携するシステム

このような複雑なシステムになると、エージェントの「網羅的に情報を収集する」という特性がより力を発揮すると感じました。

2. 様式の統一

エージェントに様式を事前設定しておくことで、以下のメリットがあります：

3. 段階的な確認プロセス

エージェントには「ステップごとに進め、各ステップ完了後にユーザーに確認を求める」という動作を設定していました。これにより、以下のような安心感がありました：

各ステップで確認できるため、途中で方向性を修正したり、不要な調査を止めたりできます。

カスタムエージェントの設定例

今回作成したエージェントには、以下のような指示を設定していました：

調査の基本原則

### 1. 正確なサービス識別
- 類似名称のサービスを明確に区別
  （例：EventBridge Rules vs Scheduler、EC2 vs ECS）
- ユーザーが指定したサービス名を正確に使用
- リージョンを含めた完全な識別情報を取得

### 2. 多層的な情報収集
- リソースのメタデータと設定値
- 実行コードやスクリプトの内容
- 環境変数、ハードコーディングされた値、外部参照
- IAMロール、ポリシー、権限設定

### 3. 関連性の把握
- 指定されたリソースから連鎖的に関連サービスを特定
- サービス間のデータフローと依存関係を明確化
- 環境の区別（本番、テスト、開発等）を識別

ドキュメント構成の指定

### 構成順序
1. 概要
   - システムの目的と用途
   - 投稿先や対象ユーザー（該当する場合）
   - 環境の概要（本番/テスト等）

2. 各AWSサービスの詳細
   - サービスごとに見出しを分ける
   - 表形式で設定項目を整理
   - 環境別に分けて記載（該当する場合）
   - 必須項目: 名前、ARN、リージョン、主要設定、IAMロール

3. 環境の違い（複数環境がある場合）
   - 環境間の差異を表形式で比較

4. システムフロー
   - Mermaid記法でフロー図を作成
   - 基本的に縦方向（TD: Top Down）で記述

5. 参考情報
   - AWSアカウントID
   - 作成日
   - セキュリティ上の注意事項

### 除外要素
- 運用手順
- トラブルシューティング
- メンテナンス手順

調査プロセスの段階化

ステップ1：情報収集の計画
- 調査対象リソースとリージョンを確認
- 調査範囲を明示してユーザーに確認
- ユーザー確認後、次のステップへ

ステップ2：基本情報の取得
- 指定されたリソースの基本情報を取得
- 関連するAWSサービスを特定
- ユーザー確認後、次のステップへ

ステップ3：詳細設定の収集
- 各サービスの詳細設定を収集
- コードや設定ファイルの内容を確認
- 環境変数、外部参照を確認
- ユーザー確認後、次のステップへ

ステップ4：関連リソースの調査
- IAMロール、ポリシー、権限設定を確認
- ネットワーク設定、セキュリティグループを確認
- ユーザー確認後、次のステップへ

ステップ5：情報の整理と検証
- リージョン別情報の対応関係を検証
- セキュリティ上の問題を評価
- ユーザー確認後、次のステップへ

ステップ6：ドキュメント作成
- ドキュメントの出力先をユーザーに確認
- マークダウン形式でドキュメントを作成

このような詳細な指示を事前に設定しておくことで、毎回同じ品質のドキュメントが作成できます。

まとめ

カスタムエージェントを使うべき場面

エージェントなしで十分な場合

・1回限りの調査
・シンプルな構成のシステム
・ドキュメントの様式にこだわらない

エージェントを使うべき場合

・定期的に同じタスクを実行する
・複雑なシステムの調査
・ドキュメントの様式を統一したい
・情報の取りこぼしを防ぎたい

最後に

AIでドキュメント作成すると、ver1としてのファイルが簡単に作れます。完璧ではなくても、叩き台があるだけで修正作業が格段に楽になります。

正直、エージェントを使わなくても十分便利だと思っていました。でも今回試してみて、いろんなエージェントを作って試してみたくなりました。セキュリティ監査用、コスト分析用、パフォーマンス調査用…可能性は無限です。

初めから理想の動きをするエージェントはなかなか作れません。なので、まずは作ってみて色々試行錯誤してみてください。その過程で、自分の業務に最適なエージェントが見えてきます。

ここまで読んでいただきありがとうございました。

参考リンク

Kiro