
Kiro CLIのHelp Agentを使ってみた
こんにちは、せーのです。今日はKiro CLIの「Help Agent」を使って、AWSセキュリティ診断を効率化するカスタムエージェントを作ってみましたので、共有します。
Kiro CLIにはSpec-driven開発のイメージが強いですが、実はセキュリティ領域でもかなり使えます。
Kiro Help Agentとは
Help AgentはKiro CLIに組み込まれたドキュメント参照型のアシスタントです。一般的なAIアシスタントと何が違うかというと、Kiro公式ドキュメントの情報に基づいて回答してくれる点です。つまり、ハルシネーションのリスクが低い。
起動方法は簡単で、Kiro CLIのチャットで /help と打つだけです。
$ kiro-cli
> /help
実際に実行すると、次のようにHelp Agentモードに切り替わります。
5% > /help
Switching to the [help] agent.
Welcome to Kiro CLI Help!
I can answer questions about Kiro CLI and help you configure it:
• Slash commands (/agent, /context, /tools, etc.)
• Built-in tools (fs_read, code, grep, etc.)
• Configuration settings
• Features like MCP, Tangent Mode, Code Intelligence
• Create/modify agents, prompts, and LSP configs in .kiro/
Just ask me anything about Kiro CLI!
...
Tip: Use /help to return to your previous agent
質問付きで起動することもできます。
> /help カスタムエージェントの作り方を教えて
すると公式ドキュメントの内容に基づいた回答が返ってきます。実験では次のような回答(要約)が得られました。
> カスタムエージェントを作成する方法は2つあります:
## 1. AI支援による作成(推奨)
/agent create
対話形式でAIがエージェント設定を生成します。名前、説明、スコープ、MCPサーバーなどを順番に聞かれます。
## 2. 手動作成
/agent create my-agent --manual
エディタが開き、JSON設定を直接編集できます。
## 保存場所
- ワークスペース: .kiro/agents/<名前>.json
- グローバル: ~/.kiro/agents/<名前>.json
作成後は /agent swap <名前> で切り替えられます。
元のエージェントに戻りたいときは、もう一度 /help を実行するだけです。
[help] 13% > /help
Switching to the [kiro_default] agent.
14% >
Help Agentの便利なところは、.kiro/ ディレクトリ内のファイル(エージェント定義、プロンプト、設定ファイル)を生成・編集する機能まで持っている点です。つまり「こういうエージェントを作りたいんだけど」と聞くと、設定ファイルの雛形まで作ってくれます。これは便利です。
セキュリティ診断用カスタムエージェントを作る
さて、ここからが本題です。Help Agentの力を借りながら、段階的にセキュリティ診断用のカスタムエージェントを構築していきます。
最小構成のエージェント(読み取り専用)
まずはプロジェクトルートに .kiro/agents/ ディレクトリを作り、エージェント定義ファイルを配置します。
$ mkdir -p .kiro/agents
.kiro/agents/security-reviewer.json を作成します。
{
"name": "security-reviewer",
"description": "AWS環境のセキュリティレビューを実施するエージェント",
"prompt": "あなたはAWSセキュリティの専門家です。IAMポリシー、ネットワーク設定、暗号化設定のレビューを行い、Well-Architected Frameworkのセキュリティ柱に基づいた改善提案を出してください。結果は「重大問題」「警告」「推奨事項」に分類してください。",
"tools": [
"fs_read",
"grep",
"glob"
],
"allowedTools": [
"fs_read",
"grep",
"glob"
],
"toolsSettings": {
"fs_read": {
"allowedPaths": ["."]
}
}
}
ポイントは tools と allowedTools です。セキュリティレビューエージェントには読み取り権限だけを与えています。fs_write や code(ファイル編集)は含めていません。セキュリティ診断が既存のコードを変更してしまったら本末転倒ですからね。
toolsSettings の allowedPaths でアクセスできるディレクトリも制限できます。ここでは .(プロジェクトルート)のみにしていますが、特定のディレクトリだけに絞ることも可能です。
プロンプトを外部化する
プロンプトが長くなってくると、JSONの中に埋め込むのは管理が大変です。Kiro CLIでは file:// URIを使ってプロンプトを外部ファイルに切り出せます。
.kiro/prompts/security-review.md を作成します。
# セキュリティレビューエージェント
## 役割
あなたはAWSセキュリティの専門家です。
## レビュー対象
1. IAMポリシー - Principal, Action, Resource, Conditionの構造、ワイルドカード使用、クロスアカウントアクセス
2. ネットワーク設定 - セキュリティグループ、NACL、VPC設定
3. 暗号化設定 - 保存時・転送時の暗号化
4. ログ・監視 - CloudTrail、CloudWatch、GuardDuty
## 出力形式
結果は以下の3カテゴリに分類して出力してください:
### 重大問題(Critical)
- セキュリティインシデントに直結する問題
### 警告(Warning)
- 改善が推奨される設定
### 推奨事項(Recommendation)
- ベストプラクティスに基づく改善提案
各項目には以下を含めてください:
- 問題の説明
- 影響範囲
- 修正方法(具体的なポリシー/設定例)
- 参考: AWS公式ドキュメントURL
エージェント定義の prompt フィールドを更新します。エージェント設定は .kiro/agents/ 基準で解釈されるため、プロンプト参照は file://../prompts/security-review.md のように .kiro/ に上がるパスにします。
{
"name": "security-reviewer",
"description": "AWS環境のセキュリティレビューを実施するエージェント",
"prompt": "file://../prompts/security-review.md",
"tools": [
"fs_read",
"grep",
"glob",
"@aws"
],
"allowedTools": [
"fs_read",
"grep",
"glob"
],
"mcpServers": {
"aws": {
"command": "uvx",
"args": ["awslabs.aws-api-mcp-server@latest"],
"env": {
"AWS_PROFILE": "your-profile-name",
"AWS_REGION": "ap-northeast-1"
}
}
}
}
ここで tools に @aws を追加しました。これは先ほどの mcpServers で定義した aws MCPサーバーのツールを参照するという意味です。これにより、エージェントがAWS公式ドキュメントを参照しながらセキュリティレビューを行えるようになります。
監査ログ機能を追加する
セキュリティ診断において、誰が、いつ、どのファイルを参照したかの記録はとても重要です。Kiro CLIの hooks 機能を使えば、ツールが実行されるたびに自動でログを残せます。
エージェント定義に hooks を追加します。
{
"hooks": {
"postToolUse": [
{
"command": "echo \"$(date '+%Y-%m-%d %H:%M:%S') - Tool: $KIRO_TOOL_NAME\" >> .kiro/audit.log"
}
]
}
}
postToolUse はツールの実行が完了した後にトリガーされるフックです。環境変数 $KIRO_TOOL_NAME には実行されたツール名が入ります。これで .kiro/audit.log にツール使用履歴が蓄積されていきます。
IAM Policy Autopilotと組み合わせる
ここからが面白いところです。セキュリティレビューエージェントに、さらにAWS公式のMCPサーバーを追加していきます。
IAM Policy Autopilotは、アプリケーションコードを分析してIAMポリシーを自動生成するOSSツールです。MCPサーバーとしても動作するので、Kiro CLIから直接呼び出せます。
.kiro/settings/mcp.json に追加します。
{
"mcpServers": {
"aws": {
"command": "uvx",
"args": ["awslabs.aws-api-mcp-server@latest"],
"env": {
"AWS_PROFILE": "your-profile-name",
"AWS_REGION": "ap-northeast-1"
}
},
"iam-policy-autopilot": {
"command": "uvx",
"args": ["iam-policy-autopilot", "mcp-server"],
"env": {
"AWS_PROFILE": "your-profile-name",
"AWS_REGION": "ap-northeast-1"
}
}
}
}
Kiro CLIからの追加はコマンド一発でもできます。
$ kiro-cli mcp add \
--name iam-policy-autopilot \
--command "uvx" \
--args "iam-policy-autopilot","mcp-server"
セキュリティレビューエージェントに切り替えて、IAMポリシーのレビューを依頼します。
> /agent swap security-reviewer
[security-reviewer] 1% > このプロジェクトのIAMポリシー定義をレビューして、最小権限の原則に基づいた改善提案をしてください。
プロジェクト内にIAMポリシー定義ファイルがない場合は、エージェントが「Terraform/CloudFormation/IAMポリシーJSONのいずれかを配置するか、サンプルでデモしますか?」と案内してくれます。実験では「3」(サンプルでレビュー)を選ぶと、典型的な問題を含むサンプルIAMポリシーに対するレビュー結果が返ってきました。
サンプルとして提示されたポリシー(問題あり):
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "FullS3Access",
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
},
{
"Sid": "EC2Management",
"Effect": "Allow",
"Action": ["ec2:*", "iam:PassRole"],
"Resource": "*"
},
{
"Sid": "LogsAccess",
"Effect": "Allow",
"Action": ["logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents"],
"Resource": "arn:aws:logs:*:*:*"
}
]
}
レビュー結果の抜粋(重大問題・修正例):
-
重大問題1: S3への無制限アクセス
s3:*とResource: "*"の組み合わせで全バケットへの全操作が可能。修正例として、特定バケットへのs3:GetObject/s3:PutObjectに限定するポリシーが提示されました。 -
重大問題2: EC2とIAMの権限昇格リスク
ec2:*+iam:PassRole+Resource: "*"で任意のIAMロールを付与したEC2を起動可能。修正例として、インスタンスタイプのConditionや、iam:PassRoleを特定ロールに限定するポリシーが提示されました。 -
警告: CloudWatch Logsのリソース指定が広範囲
arn:aws:logs:*:*:*を特定のロググループに絞る修正例が提示されました。
加えて、改善版ポリシー全体(最小権限に整理したJSON)も出力されます。実運用では、プロジェクト内の .tf やポリシーJSONを指定して同様のレビューを依頼できます。
Security Scanner MCPでIaCをスキャンする
さらに、Security Scanner MCPも追加します。これはAWS規範ガイダンスが提供しているMCPサーバーで、3つのセキュリティスキャンツールを統合しています。
| ツール | 対象 | 検証内容 |
|---|---|---|
| Checkov | IaC(Terraform, CloudFormation, Dockerfile等) | インフラ設定のセキュリティ検証 |
| Semgrep | 多言語コード(Python, JS, TS, Java, Go等) | コードレベルの脆弱性検出 |
| Bandit | Python | Python特化のセキュリティ分析 |
mcp.jsonに追加します。
{
"mcpServers": {
"security-scanner": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/aws-samples/sample-mcp-security-scanner.git@main",
"security_scanner_mcp_server"
],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR"
},
"autoApprove": [
"scan_with_checkov",
"scan_with_semgrep",
"scan_with_bandit",
"get_supported_formats"
]
}
}
}
autoApprove でスキャン系のツールを自動承認にしています。セキュリティスキャンは読み取り専用の操作なので、毎回承認するのは手間ですからね。
実際にスキャンしてみる
テスト用に、意図的に問題のあるTerraformファイルを用意します。
resource "aws_s3_bucket" "insecure_bucket" {
bucket = "my-insecure-bucket"
acl = "public-read"
}
resource "aws_security_group" "wide_open" {
name = "wide-open-sg"
ingress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
}
resource "aws_iam_role_policy" "overly_permissive" {
name = "overly-permissive"
role = aws_iam_role.example.id
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Effect = "Allow"
Action = "*"
Resource = "*"
}
]
})
}
セキュリティレビューエージェントに切り替えてスキャンを依頼します。
> /agent swap security-reviewer
> このTerraformファイルをセキュリティスキャンして、問題点を教えてください: test/insecure.tf
実験では、エージェントがファイルを読み取ったうえで、次のような重大問題(Critical)と修正用Terraformコードをそのまま出力しました。
重大問題1: S3バケットが完全公開設定
acl = "public-read"により、インターネット上の誰でもオブジェクトを読み取り可能。修正例として以下が提示されました。
resource "aws_s3_bucket" "secure_bucket" {
bucket = "my-secure-bucket"
}
resource "aws_s3_bucket_public_access_block" "secure_bucket" {
bucket = aws_s3_bucket.secure_bucket.id
block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = true
}
resource "aws_s3_bucket_server_side_encryption_configuration" "secure_bucket" {
bucket = aws_s3_bucket.secure_bucket.id
rule {
apply_server_side_encryption_by_default {
sse_algorithm = "AES256"
}
}
}
重大問題2: セキュリティグループが全ポート・全プロトコルを開放
protocol = "-1"とcidr_blocks = ["0.0.0.0/0"]により、全世界から全通信を許可。修正例です。
resource "aws_security_group" "secure_sg" {
name = "secure-sg"
description = "Secure security group with minimal access"
ingress {
description = "HTTPS from specific IP"
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = ["203.0.113.0/24"]
}
ingress {
description = "SSH from bastion only"
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["10.0.1.0/24"]
}
egress {
description = "Allow outbound traffic"
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
}
重大問題3: IAMポリシーが全権限付与(Admin相当)
Action = "*"とResource = "*"により、全AWSサービスへの全操作を許可。修正例です。
resource "aws_iam_role_policy" "least_privilege" {
name = "least-privilege-policy"
role = aws_iam_role.example.id
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Effect = "Allow"
Action = [
"s3:GetObject",
"s3:PutObject"
]
Resource = "arn:aws:s3:::specific-bucket-name/*"
},
{
Effect = "Allow"
Action = [
"dynamodb:GetItem",
"dynamodb:PutItem"
]
Resource = "arn:aws:dynamodb:ap-northeast-1:123456789012:table/specific-table"
}
]
})
}
警告(Warning) としては、S3の暗号化未設定・バージョニング未設定、セキュリティグループのegress未定義などが挙げられ、推奨事項(Recommendation) としてログ・監視の追加、IAM条件の追加、タグ付けなどが提示されました。
Terraformを書いた時点でセキュリティの問題と修正コードまで得られるので、デプロイ前の確認としてとても有用です。
プロジェクト全体のセキュリティレビューと修正コードの生成
同じセキュリティレビューエージェントに、「プロジェクト全体」を対象にしたレビューと、検出した重大問題を修正したTerraformコードの生成を依頼することもできます。
プロジェクト全体のレビュー
次のように依頼します。
> プロジェクト全体のセキュリティレビューを実施してください。
IAMポリシー、IaC設定、アプリケーションコードを対象に、
重大問題・警告・推奨事項に分類して報告してください。
実験では、エージェントが **/*.{tf,json,yaml,yml,py,js,ts,sh} や **/* でファイルを検索し、test/insecure.tf のほか .kiro/settings/mcp.json や .kiro/agents/security-reviewer.json も読み取ったうえで、grepで 0.0.0.0 や認証情報らしきパターンを検索していました。結果は次のようなサマリーでまとまりました。
| カテゴリ | 件数 | 優先度 |
|---|---|---|
| 重大問題 | 3件 | 即時対応必須 |
| 警告 | 4件 | 1週間以内に対応 |
| 推奨事項 | 5件 | 計画的に対応 |
重大問題3件は、前述の「S3公開」「SG全開放」「IAM全権限」で、それぞれ修正用のTerraformコード付きで報告されました。警告には「S3暗号化なし」「バージョニングなし」「egress未定義」に加え、「AWS認証情報がプロファイル依存」といった設定まわりの指摘も含まれています。
修正済みTerraformコードの生成
検出された重大問題について、そのまま使える形のTerraformを出してほしいときは、次のように依頼します。
> 検出された重大問題について、修正済みのTerraformコードを生成してください。
実験では、test/secure.tf として保存する想定のコードがそのまま出力されました。抜粋します。
# ============================================
# S3バケット - セキュア設定
# ============================================
resource "aws_s3_bucket" "secure_bucket" {
bucket = "my-secure-bucket"
}
resource "aws_s3_bucket_public_access_block" "secure_bucket" {
bucket = aws_s3_bucket.secure_bucket.id
block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = true
}
resource "aws_s3_bucket_server_side_encryption_configuration" "secure_bucket" {
bucket = aws_s3_bucket.secure_bucket.id
rule {
apply_server_side_encryption_by_default {
sse_algorithm = "AES256"
}
}
}
resource "aws_s3_bucket_versioning" "secure_bucket" {
bucket = aws_s3_bucket.secure_bucket.id
versioning_configuration {
status = "Enabled"
}
}
# ============================================
# セキュリティグループ - 最小権限設定
# ============================================
resource "aws_security_group" "secure_sg" {
name = "secure-sg"
description = "Security group with least privilege access"
ingress {
description = "HTTPS from specific IP range"
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = ["203.0.113.0/24"]
}
ingress {
description = "SSH from internal network only"
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["10.0.1.0/24"]
}
egress {
description = "Allow HTTPS outbound"
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
tags = {
Name = "secure-sg"
Environment = "production"
}
}
# ============================================
# IAMポリシー - 最小権限の原則
# ============================================
resource "aws_iam_role_policy" "least_privilege" {
name = "least-privilege-policy"
role = aws_iam_role.example.id
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Sid = "S3ReadWrite"
Effect = "Allow"
Action = [
"s3:GetObject",
"s3:PutObject",
"s3:ListBucket"
]
Resource = [
"arn:aws:s3:::my-secure-bucket",
"arn:aws:s3:::my-secure-bucket/*"
]
},
{
Sid = "CloudWatchLogs"
Effect = "Allow"
Action = [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
]
Resource = "arn:aws:logs:*:*:log-group:/aws/*"
}
]
})
}
エージェントからは「203.0.113.0/24 と 10.0.1.0/24 は実際の環境に合わせて変更してください」という注意も付いていました。このように、実験で使ったコマンドとTerraformの内容をそのまま転記しておくと、読者が手元で再現しやすくなります。
まとめ
今回構築したセキュリティ診断環境の全体像はこのようになっています。
| 構成要素 | 役割 |
|---|---|
| Help Agent | カスタムエージェントの作り方をドキュメントベースで案内 |
| カスタムエージェント | セキュリティレビュー専用の権限・出力形式を定義 |
| AWS MCP Server | AWSサービスの情報をセキュアに参照 |
| IAM Policy Autopilot | コードからIAMポリシーを分析・改善提案 |
| Security Scanner MCP | IaC・コードのセキュリティ検証(Checkov/Semgrep/Bandit) |
Help Agentは「作り方を教えてくれる先生」
Help Agentは直接セキュリティ診断をしてくれるわけではありません。あくまで「Kiro CLIの機能をドキュメントベースで教えてくれる先生」です。ただ、この先生がいるおかげで、カスタムエージェントやMCPサーバーの設定方法を調べる時間が大幅に短縮されます。
読み取り専用 + 監査ログは必須
セキュリティ診断エージェントに書き込み権限を与えないこと、そして何をしたかのログを残すこと。この2つは地味ですが非常に重要です。AIにセキュリティの仕事をさせるなら、AI自体のセキュリティも考える必要があります。
MCPサーバーの組み合わせが鍵
IAM Policy AutopilotもSecurity Scanner MCPも単体で使えますが、Kiro CLIのカスタムエージェントで組み合わせることで「IAMポリシーの分析」と「IaCのスキャン」を一つの指示で実行できるようになります。MCPサーバーは単体よりも組み合わせてこそ真価を発揮します。
help agent, AWSにて複数アカウント、複数システムを横断的に管理、監視するような立場の方にはとても便利な機能だと思います。ぜひ触ってみてください。
参考資料
- Kiro Help Agent公式ドキュメント
- カスタムエージェント設定リファレンス
- IAM Policy Autopilot(GitHub)
- Security Scanner MCP(AWS規範ガイダンス)
- 猫でもわかるKiro CLI(セキュリティ編) - kentapapa氏
注意: AWS MCPサーバーはパッケージ名を awslabs.aws-api-mcp-server にしてください。awslabs.aws-mcp-server は PyPI に存在しないため接続に失敗します。プロンプトの file:// で「File URI not found」が出る場合は、file://../prompts/security-review.md のように ../ で .kiro/ に上がるパスを指定してください。









