はじめに
私は仕事柄、AWSサービスの仕様について確認することがちょくちょくあります。今まではAWS公式ドキュメントを自分で漁って調査していましたが、ケースによっては結構時間がかかっていました。
「特定の条件下で期待通り動作するか」等、込み入った話になると、色々なページに散らばった情報を集めて突合する場合も多いためです。
AIエージェントの登場後も、ハルシネーションで誤った案内をされる事が心配で、しばらく自分で調べていたのですが、Kiroにステアリングファイルを設定して調査させるようになってから、調査が捗るようになりました。
せっかくなので、同じような心配をしている方向けに、私が使っているステアリングファイルを紹介してみます。
すでにAIエージェントを使いこなしている人にとっては目新しい話は無いと思いますが、Kiroをこれから使い始める方や、初期設定のままチャットだけ使っている方に、何かしら参考になれば幸いです。
今回のステアリングファイルはあくまで一例です。
今回のファイルに記載された項目が、ステアリングで必須なわけではありません。
「このくらいの粒度で、このくらいの動きはする」となんとなくイメージを持っていただければと思います。
ステアリングファイルについて
ステアリングファイルは、Kiroに作業させる際の規約やルールを記載するファイルです。
これにより、チャットで毎回事細かに指示しなくても、作業に一貫性を持たせることが可能になります。
詳細は、以下の公式ドキュメントを参照ください。
https://kiro.dev/docs/steering/
今回のステアリングファイルの内容
今回のステアリングファイルは以下です。50行の簡素なものですが、これくらいでも、何も設定しない場合と比べると、かなり自分好みに動いてくれるようにはなりました。
.kiro/steering/research.md
---
inclusion: always
---
<!------------------------------------------------------------------------------------
Add rules to this file or a short description that will apply across all your workspaces.
Learn about inclusion modes: https://kiro.dev/docs/steering/#inclusion-modes
------------------------------------------------------------------------------------->
# 適用条件
何かについての調査を依頼された場合、このドキュメントに記載されているルールを適用します。
# 調査方法のルール
## 共通
- 外部情報を参照する場合、可能な限り、公式の一次情報を最優先で参照します。
- 例として、AWSに関する調査であれば、AWS公式ドキュメントの情報を取得します。
- 一次情報に適切な情報がない場合や、情報が十分でない場合は、公式以外の情報を参照します。
- 可能な限り、mcpおよびpowerを活用して情報を参照します。
- 例として、AWSに関する調査であれば、aws-mcpのaws__read_documentationや、aws__search_documentationを活用します。
## 不具合の調査の場合
- すでにデプロイされているシステムについて調査する場合、必ず、現在の実際の設定値を確認します。
- ログがある場合、必ず、ログを確認します。
## 一般的な技術仕様・製品仕様・サービス仕様を調査する場合
- 可能な限り、公式の一次情報を最優先で参照します。
# 調査結果の記載ルール
## 共通
- 調査結果は、特に指定がない限り、マークダウン形式で記載します。
- 書式を指定された場合は、指定を優先します。
- 調査にあたり外部のドキュメントを参照した場合は、必ず出典を記載します。
- 公式のドキュメント以外を参照した場合は、必ずその旨を注意事項として記載します。
- 出典は出来るだけ具体的に記載します。例として、AWS公式ドキュメントのWEBページであれば、対象の情報が載っているページのURLを記載します。
- 調査内容と出典の紐づけが分かるように記載します。具体的には、項番毎に出典を記載するなどします。
- 調査結果は、特に指定がない限り、ワークスペース直下にresearchというディレクトリを作成し、そのディレクトリに保存します。
- 保存場所を指定された場合は、指定を優先します。
## 不具合の調査の場合
- 事実と推測を分けるようにします。推測を記載する場合は必ず、それが推測である旨を明記します。
- 必ず以下を記載内容に含めます。
- ログや設定値などの事実
- 複数の事実から推測される原因
- 推測される原因から導きだされる解決策
- 解決策を実行するための具体的アクション
## 一般的な技術仕様・製品仕様・サービス仕様を調査する場合
- 事実のみ記載します。
- 推測は記載しません。
- 明確な情報が存在しない場合は推測を記載せず、情報が存在しない旨を記載します。
特に重視した点は、「一次情報を参照すること」「出典を明記すること」「情報がない場合は『ない』と回答すること」です。一次情報の出典が明記されていれば、ダブルチェックがしやすいためです。（※現状は、自分でも出典URLを確認してダブルチェックするようにしています。）
不具合調査に関するルールも記載していますが、このステアリングを設定した後で実際に不具合調査をしたことがないので、こちらの成果については未確認です。
なお、今回のステアリングファイルは、AWS MCPサーバーを使って公式ドキュメントを参照させることを意識した記載となっています。
AWS MCPサーバーについては以下の公式ドキュメントを参照ください。
https://aws.amazon.com/jp/blogs/news/the-aws-mcp-server-is-now-generally-available/
https://docs.aws.amazon.com/ja_jp/agent-toolkit/latest/userguide/mcp-server.html
実際に調査を依頼した例
ここからは、上記のステアリングファイルを設定した状態で、Kiroに実際に調査を依頼した結果をご紹介します。
今回は、AWS Security Agentの仕様について質問してみました。比較的最近出たサービスなので、LLMのみで回答されると少々不安なテーマです。逆に言うと、今回のステアリングファイルを試すにはもってこいです。
例１：公式ドキュメントに情報あり
まず、Security Agentのペネトレーションテストで設定する、ターゲットURLと除外URLの仕様について色々と質問してみました。
すると、以下の通り調査結果をまとめてくれました。（既にSecurity Agentについて色々調査してもらっていたので、調査ファイルから該当箇所だけ抜粋しています。）
aws-security-agent-pentest(抜粋)
## 5. ターゲットURL・除外URLのスコープ（サブドメイン・パス・外部リンク）
### 調査日
2026年8月6日
### 調査の背景
AWS Security Agentのペネトレーションテストにおいて、ターゲットURLおよび除外URL（Out-of-scope URLs）の指定が、サブドメインやパス配下にどの範囲まで適用されるかを調査する。
---
### 5-1. ターゲットに指定したドメインのサブドメインはテストに含まれるか
**結論: サブドメインは自動的にテストスコープに含まれる。ただし、ドメイン検証の観点とテストスコープの観点で整理が必要。**
#### ドメイン検証の観点
親ドメインをDNS TXTまたはHTTP route方式で検証した場合、**そのサブドメインは追加の検証なしでテスト対象として指定可能**。
> "When you verify a domain using DNS TXT or HTTP route verification, sub-domains of that domain are automatically covered. For example, verifying `example.com` allows you to test `api.example.com` or `billing.example.com` without additional verification."
つまり、`example.com`を検証済みであれば、`api.example.com`や`billing.example.com`をTarget URLsに追加する際に再度の所有権検証は不要。
> 出典: [Enable an application domain for penetration testing（AWS公式ドキュメント）](https://docs.aws.amazon.com/securityagent/latest/userguide/enable-test-domain.html)
#### テストスコープの観点
Quickstartガイドには以下の記載がある：
> "Only verified domains can be tested, and sub-domains are covered automatically."
また、ペネトレーションテスト作成画面のTipには以下のように記載されている：
> "For best results, include all domains that are part of your application's user flow, including subdomains for APIs, authentication services, and content delivery. Sub-domains of a verified parent domain do not require separate verification."
これらの記述から、**親ドメインをターゲットに指定した場合、そのサブドメインも自動的にテストスコープに含まれる**と解釈できる。ただし、公式ドキュメントのTipでは「サブドメインもTarget URLsに含めること」が推奨されており、明示的に追加することでより確実なカバレッジが得られる。
> 出典: [Quickstart: Run a penetration test（AWS公式ドキュメント）](https://docs.aws.amazon.com/securityagent/latest/userguide/quickstart.html)
> 出典: [Create a penetration test（AWS公式ドキュメント）](https://docs.aws.amazon.com/securityagent/latest/userguide/perform-penetration-test.html)
#### 注意事項: Private VPC検証の場合
Private VPC検証方式を使用する場合は、**ターゲットエンドポイントのドメイン名が検証時に設定した完全なドメイン名と一致する必要がある**。この場合、サブドメインの自動カバーは適用されない。
> "For Private VPC verification, the target endpoint domain name must match the full domain name configured for verification."
> 出典: [Enable an application domain for penetration testing（AWS公式ドキュメント）](https://docs.aws.amazon.com/securityagent/latest/userguide/enable-test-domain.html)
---
### 5-2. ターゲットに指定したドメイン上のパスは全てテストに含まれるか
**結論: はい。ターゲットドメイン上のすべてのパスがテスト対象となる（Out-of-scope URLsに指定したパスを除く）。**
AWS Security Agentは、ターゲットアプリケーションに対して**breadth-first exploration（幅優先探索）**を行い、通常のユーザー操作を模倣してアプリケーションを巡回した後に、脆弱性テストを実施する。
> "AWS Security Agent will do a breadth-first exploration of the target application(s) and attempt to exercise it normally before attempting any exploits. This allows it to build a working understanding of the application at runtime and discover critical application logic and endpoints."
したがって、`example.com`をターゲットに指定した場合：
- `example.com/aaa` → **テスト対象**
- `example.com/bbb` → **テスト対象**
- `example.com/aaa/bbb/ccc` → **テスト対象**
ただし、以下の点に注意が必要：
1. **全パスの網羅は保証されない**: AIエージェントの確率的な性質上、すべてのエンドポイントを発見・テストすることは保証されない
> "Given its stochastic nature, AWS Security Agent is not guaranteed to discover and test all critical applications and endpoints for any target application."
2. **APIドキュメントの提供で網羅性が向上**: OpenAPI/Swagger仕様書を提供することで、エージェントがエンドポイントを試行錯誤で発見するのではなく、包括的にテストできる
3. **認証が必要なパスは認証情報の提供が必要**: 認証で保護されたパスをテストするには、ペネトレーションテスト設定で認証情報を提供する必要がある
> 出典: [Security Considerations for AWS Security Agent（AWS公式ドキュメント）](https://docs.aws.amazon.com/securityagent/latest/userguide/security-guidance.html)
> 出典: [Create a penetration test（AWS公式ドキュメント）](https://docs.aws.amazon.com/securityagent/latest/userguide/perform-penetration-test.html)
---
### 5-3. ターゲットのWebページから辿れる外部リンクや外部APIはテストに含まれるか
**結論: いいえ。外部リンク先や外部APIはテスト対象に含まれない。Target URLsおよびAccessible URLs以外へのアクセスはネットワークレベルでブロックされる。**
#### ネットワークレベルのアクセス制御
AWS Security Agentには、**Target URLsおよびAccessible URLsに指定されていないエンドポイントへのアクセスをネットワークレベルでブロックする機構**が存在する。
> "All network dependencies required for testing must be specified as either target URLs or accessible URLs. The network blocks access to any unspecified endpoints."
> "Requests to URLs outside of the target and accessible URLs will be blocked by the network."
したがって、`example.com`をターゲットに指定した場合、`example.com`のWebページ上に`external.com`へのリンクが存在していても：
- `external.com`がTarget URLsにもAccessible URLsにも含まれていなければ → **ネットワークレベルでブロックされ、アクセス不可**
- `external.com`がAccessible URLsに含まれている場合 → **アクセスは可能だが、脆弱性テストの対象にはならない**（ログインやナビゲーション等の目的でのみ利用される）
- `external.com`がTarget URLsに含まれている場合 → **脆弱性テストの対象となる**（ただし所有権検証が必要）
#### Accessible URLsの用途
Accessible URLsは、テスト対象ではないがテスト実行に必要な外部サービス（認証プロバイダー、CDN等）を指定するためのもの。
> "Add accessible domains for third-party services (such as Okta, Auth0, Stripe) that are outside your target domain. This is required so AWS Security Agent can access these URLs for login and navigation during testing. AWS Security Agent does NOT penetration test these domains—they are used solely for access purposes."
#### 重要: Accessible URLsのセキュリティへの影響
> "AWS Security Agent is not instructed to perform security testing on accessible URLs. By specifying accessible URLs, you indicate trust in these dependencies. Penetration test data, including credentials, may be transmitted to these accessible URL endpoints during testing."
Accessible URLsに指定したドメインに対しては、テスト中に認証情報を含むデータが送信される可能性がある点に注意が必要。
> 出典: [Security best practices for AWS Security Agent（AWS公式ドキュメント）](https://docs.aws.amazon.com/securityagent/latest/userguide/security-best-practices.html)
> 出典: [Security Considerations for AWS Security Agent（AWS公式ドキュメント）](https://docs.aws.amazon.com/securityagent/latest/userguide/security-guidance.html)
> 出典: [Create a penetration test（AWS公式ドキュメント）](https://docs.aws.amazon.com/securityagent/latest/userguide/perform-penetration-test.html)
---
### 5-4. 除外URLに指定したドメインのサブドメインは除外に含まれるか
**結論: 公式ドキュメントにサブドメインの除外に関する明確な記載は存在しない。Out-of-scope URLsはパス単位での指定として設計されている。**
公式ドキュメントのOut-of-scope URLs設定に関する説明では、入力例として以下が示されている：
> "In the **Out-of-scope URLs** input field, enter a URL path to exclude (for example, `/admin/delete` or `/api/reset`)."
これはパス（path）単位での除外指定であり、サブドメイン単位での除外については記載がない。
#### 考えられる解釈
- Out-of-scope URLsは**特定ドメインの特定パス**を除外する機能として設計されている
- サブドメイン（例: `sub.example.com`）を丸ごと除外したい場合は、そのサブドメインをTarget URLsに含めないことで対応する
- Target URLsに含めていないドメイン/サブドメインは、そもそもネットワークレベルでブロックされるため、除外指定は不要
#### 補足: NetworkTrafficRule APIの存在
APIリファレンスには`NetworkTrafficRule`というリソースが存在し、URLパターンに対してALLOW/DENYを設定できる構造になっている。これはペネトレーションテストのネットワーク制御をより細かく管理するためのものと考えられるが、サブドメイン単位の除外に関する明確な仕様は確認できなかった。
> 出典: [Create a penetration test（AWS公式ドキュメント）](https://docs.aws.amazon.com/securityagent/latest/userguide/perform-penetration-test.html)
> 出典: [NetworkTrafficRule API Reference（AWS公式ドキュメント）](https://docs.aws.amazon.com/securityagent/latest/APIReference/API_NetworkTrafficRule.html)
---
### 5-5. 除外URLに指定したパスの配下パスは除外に含まれるか
**結論: はい。除外URLに指定したパスおよび、そのパスの配下にネストされたすべてのパスが除外される。**
公式ドキュメントに明確な記載がある：
> "Specify URL paths that should not be tested during the penetration test. AWS Security Agent excludes the specified path and all paths nested beneath it. For example, if you add `https://example.com/admin` as an out-of-scope URL, `https://example.com/admin/tools` is also out-of-scope."
したがって、`example.com/aaa`をOut-of-scope URLsに指定した場合：
- `example.com/aaa` → **除外される**
- `example.com/aaa/bbb` → **除外される**
- `example.com/aaa/ccc/ddd` → **除外される**
- `example.com/aaabbb` → **除外されない**（パスプレフィックスの一致ではなく、パス階層としてのネストが条件）
- `example.com/bbb` → **除外されない**
> 出典: [Create a penetration test（AWS公式ドキュメント）](https://docs.aws.amazon.com/securityagent/latest/userguide/perform-penetration-test.html)
---
### まとめ
| 質問 | 回答 | 根拠 |
|------|------|------|
| ターゲットに指定したドメインのサブドメインはテストに含まれるか | ✅ 含まれる（自動カバー） | Quickstart: "sub-domains are covered automatically" |
| ターゲットに指定したドメイン上のパスは全てテストに含まれるか | ✅ 含まれる（ただし全パスの網羅は保証されない） | breadth-first explorationで探索。確率的に全網羅は未保証 |
| ターゲットのWebページから辿れる外部リンク/外部APIはテストに含まれるか | ❌ 含まれない | Target/Accessible URLs以外はネットワークレベルでブロック |
| 除外URLに指定したドメインのサブドメインは除外に含まれるか | ⚠️ 明確な記載なし（パス単位の除外設計） | Out-of-scope URLsはパス指定。サブドメイン除外の記載なし |
| 除外URLに指定したパスの配下パスは除外に含まれるか | ✅ 含まれる | 公式: "excludes the specified path and all paths nested beneath it" |
### 本項の出典
| # | ドキュメント | URL |
|---|------------|-----|
| 1 | Enable an application domain for penetration testing（AWS公式ドキュメント） | https://docs.aws.amazon.com/securityagent/latest/userguide/enable-test-domain.html |
| 2 | Create a penetration test（AWS公式ドキュメント） | https://docs.aws.amazon.com/securityagent/latest/userguide/perform-penetration-test.html |
| 3 | Quickstart: Run a penetration test（AWS公式ドキュメント） | https://docs.aws.amazon.com/securityagent/latest/userguide/quickstart.html |
| 4 | Security Considerations for AWS Security Agent（AWS公式ドキュメント） | https://docs.aws.amazon.com/securityagent/latest/userguide/security-guidance.html |
| 5 | Security best practices for AWS Security Agent（AWS公式ドキュメント） | https://docs.aws.amazon.com/securityagent/latest/userguide/security-best-practices.html |
| 6 | NetworkTrafficRule API Reference（AWS公式ドキュメント） | https://docs.aws.amazon.com/securityagent/latest/APIReference/API_NetworkTrafficRule.html |
各回答毎に、毎回出典を記載してくれているので、ダブルチェックがしやすいのがありがたいですね。
上記のサンプルではAWS公式のユーザーガイドとAPIリファレンスが参照されていますが、場合によってはAWS公式ブログから情報を取ってきてくれることもあります。
例２：公式ドキュメントに情報なし
もう一つ、Security Agentの仕様について質問してみました。
「ターゲットURLにexample.com/aaaを設定した場合、example.com/bbbはターゲット対象外となるか？」と聞いてみました。
文字が小さくて読みづらくてすいません。。。
要するに、「公式ドキュメントに明確な記述はない」と回答してくれています。
知ったかぶりをせず、公式に記載がないものは「ない」と回答してくれているので、これはこれで期待通りの動きでした。
ちなみに、Kiroの推奨通りAWSサポートに問い合わせたところ、「example.com/aaaのように、ターゲットURLにパスを含めた場合、配下（例: "example.com/aaa/xxx"）がターゲットとなり、"example.com/bbb" は含まれません。」という回答でした。
Security Agentの仕様についても、別途記事にしていければと思います。
以上、Kiroのステアリングファイルのご紹介でした。冒頭にも記載した通り、これが正解というわけでは全くありませんので、他の方のステアリングファイル等も参考にしながら、是非ご自身に最適のステアリングファイルを育てていただければと思います。（私もきっと上記のファイルをブラッシュアップしていくと思います）