はじめに
みなさんは普段、インシデント調査でKiro CLIを利用していますでしょうか。私はAWS環境上で構築したものがうまく動かないとき、初動調査でかなり頼っています。
Kiroは、必要なAWS APIを自律的に選びながら調査を進めてくれる非常に強力なツールです。一方で、確認プロンプトで不用意に yes や trust を選択してしまうと、本来は調査だけで終えるべきフェーズで書き込み操作に進んでしまい、環境の破壊につながるリスクもあります。
この記事では、KiroをCLIで安全に使うための権限設計と運用を、実運用目線で整理します。特に以下を中心に解説します。
- IAMによる権限の絞り込みと、実際に追加が必要になるActionの考え方
- AgentSteeringを使った行動方針の固定化と具体的な設定方法
- IAMだけで制御せずSteeringを併用したほうがよい理由
※本記事は2026年4月時点の内容です。AWS管理ポリシーは更新されアクセス権限が変更される可能性があるため、適用前に必ずAWSコンソールで最新のバージョンと内容(アクション、リソース、条件)を確認してください。
先に結論
まず結論です。Kiroを安全に運用するには、次の3点をセットで実施するのが効果的です。
- 調査用ロールを読み取り専用に固定する
- 変更操作は別ロール（昇格）に分離し、承認必須にする
- IAMとAgentSteeringを組み合わせて二段構えで制御する
「AIに慎重に振る舞ってもらう」より、そもそもできることを絞るほうが事故は減ります。
さらに「できないと認識させる」ことで、Kiroの無駄な試行も防げます。
なぜ事故が起きるのか
事故が起きるときは、Kiro自体より「運用境界の曖昧さ」が原因であることが多いです。
| # | よくある事故パターン | 背景 |
|---|---|---|
| ① | 調査のつもりで変更操作まで実行 | 実行ロールに書き込み権限が含まれていた |
| ② |
trust の常用で確認が形骸化 |
毎回の承認を省いてしまった |
| ③ | 調査と復旧で同じ資格情報を利用 | フェーズ境界がなかった |
つまり本質は、「Kiroに何をさせるか」ではなく、どこまでしかできないように設計するかです。
最小権限の考え方について
基本的に、調査用の権限にはReadOnlyAccessをベースとして、必要な権限をカスタムで追加していくのが良いのではないかと思います。完璧にやろうとするとすべてカスタムでアクションを列挙するほうが良いのかもしれませんが、実務上現実的な出発点として、マネージドポリシーからはじめるのが良いと考えます。
メリット
- 初期構築が速い
- 主要な参照系Actionを広くカバーできる
- AWS管理ポリシーの更新追従を受けられる
注意点
- 管理ポリシー更新により許可範囲が将来変わる可能性がある
- 組織独自制約（特定サービスの参照禁止など）は別途制御が必要
- 「ReadOnlyAccessだけで十分か」は調査手順次第で変わる
推奨の権限設計
- ベースに
ReadOnlyAccessを付与 - 不足する調査用Actionのみ追加
- 変更系は明示的Denyや別ロール分離で制御
- 可能ならSCPで二重ガード
ReadOnlyAccessに含まれないが、調査で有効な権限
cloudwatch:Get* や logs:StartQuery のような主要な参照系Actionは、現行のReadOnlyAccessに含まれます。
追加検討が必要なのは、以下のような「調査効率を上げるがReadOnlyAccessには含まれないAction」です。
-
sts:DecodeAuthorizationMessage
AccessDeniedの詳細解析に有効。調査ロール常時付与候補。 -
cloudtrail:StartQuery（CloudTrail Lake利用時）
Lakeクエリの開始に必要。Get系だけでは調査を開始できない。※1 -
athena:StartQueryExecution（Athena利用時）
ログ分析クエリの開始に必要。WorkGroup固定での付与が安全。
※1 CloudTrail Lakeは2026年5月31日以降、新規の顧客に公開されなくなります。
なお ssm:StartSession や kms:Decrypt は調査で便利でも権限としては強いため、ReadOnlyロールに常時付与せず、承認付きの別ロールで使う運用を推奨します。
また、ReadOnlyAccess であっても、Secrets ManagerやParameter Store内の機密値を参照できる場合があります。
特定の機密情報へのアクセスを制限したい場合は、Denyポリシーを組み合わせる、あるいは特定のタグが付いたリソースのみ参照を許可することで、さらに安全性が高まります。
cloudtrail:StartQueryや、athena:StartQueryExecutionなどは実際に実行する場合スキャンした容量に対して課金が発生します。仮にこれらを許可する場合は、後述するAgentSteeringでクエリの実行回数や範囲など、コスト観点での制約を取り込むとよいと考えます。
KiroのAgentSteeringとは何か
KiroにはAgentSteeringという機能があり、エージェントの行動方針を事前に固定化できます。
要するに「毎回プロンプトで注意事項を書く」のではなく、セッションの初期条件として方針を与える仕組みです。
AgentSteeringが便利なのは、次のような場面です。
- 複数オペレーターで同じ運用ルールを守りたいとき
- インシデント時の初動で、判断のブレを減らしたいとき
- 「実行禁止」「提案のみで停止」などの行動制約を明示したいとき
今回のパターンでは、AgentSteeringに次を明記すると効果的です。
- 調査フェーズでは読み取り系APIのみ実行
- 変更系APIは提案のみで実行しない
- 不明時は安全側（実行しない）を選ぶ
ポイントは、AgentSteeringを「運用の標準化」に使い、最終防御はIAMで担保することです。
IAMとAgentSteeringを組み合わせる理由
ここで気になるのが、「IAMで禁止できるなら、それだけで十分では？」という点です。
実際には、IAMだけで厳しく制限していると、Kiroが変更系APIを試行して AccessDenied を返し、別案を再探索する流れになることがあります。
実務で起きやすいのは次のようなケースです。
- 調査の途中で「一時的に設定を変えて切り分ける」系の提案に進む
- ログ分析の文脈で、実際には不要な変更系コマンドを候補に含める
- 変更系を拒否されるたびに再試行し、初動調査の時間を消費する
このため、IAMだけで止める運用は安全ではあるものの、調査効率の面ではロスが出ることがあります。
そこで有効なのが、IAMとAgentSteeringの併用です。
- IAM: 最終的に危険操作を実行不能にする（最後の砦）
- AgentSteering: そもそも変更系を「候補に上げにくくする」
この二段構えにすると、AccessDenied の発生回数を減らし、調査の往復を短くできます。
つまり、Steeringはセキュリティ境界ではないものの、調査の無駄打ちを減らす実務上の最適化として非常に有効です。
例えるなら、「IAM＝物理的な壁（絶対に越えられない壁）」、「Steering＝ナビ（効率的な道案内）」という役割分担をイメージ頂けるとわかりやすいかと思います。
Steeringあり・なしで調査がどう変わるか
ここでは実際にKiroを動かして、Steeringなしの場合どんな流れになるかを見てみます。
Steeringが無いとき
特定のセキュリティグループがアタッチされたインスタンスにSSHでアクセスできない！というケースをサンプルに試してみましょう。
セキュリティグループで22番が空いていないことが原因なんですが、一度インスタンスを起動しようとしてますね。。（そしてエラー）
これは結局yやtを押さなければいい話ではあるものの、どうしても遠回りしている感が否めません。
Steeringがあるとき
同じくインスタンスにSSHアクセスができない！と投げてみましょう。
今回は、最初からできないこと（参照系以外の操作）は提案してこないことがわかります。
できないことをできると思って考えるより、最初からできる範囲などを指定してあげることで無駄な試行を防ぐことができます。
CloudShell実践：権限ロールとAgentSteeringの運用
CloudShellでKiro CLIを実行した場合、AWS API呼び出しはそのCloudShellセッションに設定されている認証情報の権限で実行されます。
Kiro専用の権限があるわけではなく、実体は「現在のIAMプリンシパル（またはAssumeRole先ロール）」です。
前節の二段構え（IAM＋AgentSteering）を実際の運用に落とし込むと、次のようになります。
| フェーズ | 使うロール | AgentSteering |
|---|---|---|
| 調査 | KiroIncidentReadOnlyRole |
読み取り専用方針を適用 |
| 復旧 |
KiroIncidentRemediationRole（承認後） |
変更許可方針に切り替え |
具体的なイメージは以下の通りです。
-
KiroIncidentReadOnlyRoleをAssumeして調査する - 復旧が必要なときだけ、承認後に
KiroIncidentRemediationRoleへ切り替える - 調査終了後はセッションを破棄し、強い権限を持ち越さない
AgentSteeringの渡し方
1. パターンA: .kiro/steering に置いて自動読込させる（推奨）
Kiro CLIをプロジェクトルート（またはその配下）で起動するなら、この運用が一番シンプルです。
リポジトリ配下の .kiro/steering にファイルを置いておくと、起動時に自動で読み込まれます。
mkdir -p ./.kiro/steering
cat > ./.kiro/steering/incident-readonly.txt << 'EOF'
あなたはインシデント調査アシスタントです。
現在フェーズは「調査」です。
- 実行可能なのは読み取り系API（Get/List/Describe/Lookup）のみ
- 変更系API（Create/Put/Update/Delete/Modify/Terminate等）は実行禁止
- 変更が必要な場合は、実行せずに提案コマンドと影響範囲だけを提示
- 不明な場合は安全側（実行しない）を選択
EOF
# .kiro/steering があるディレクトリ配下で起動
kiro
注意点として、~ 配下に .kiro/steering を置いても、作業ディレクトリが別プロジェクトなら自動反映されないことがあります。
「どこで起動しているか」が重要です。
2. パターンB: ファイル内容を明示的に渡す
プロジェクト外で一時的に使いたいときや、共通Steeringを個人ホーム配下で管理したいときは、明示渡しが便利です。
mkdir -p ~/kiro/steering
cat > ~/kiro/steering/incident-readonly-v1.txt << 'EOF'
あなたはインシデント調査アシスタントです。
現在フェーズは「調査」です。
- 実行可能なのは読み取り系API（Get/List/Describe/Lookup）のみ
- 変更系API（Create/Put/Update/Delete/Modify/Terminate等）は実行禁止
- 変更が必要な場合は、実行せずに提案コマンドと影響範囲だけを提示
- 不明な場合は安全側（実行しない）を選択
EOF
# 例1: 標準入力で渡す
cat ~/kiro/steering/incident-readonly-v1.txt | kiro
# 例2: 引数に埋め込んで渡す
kiro "$(cat ~/kiro/steering/incident-readonly-v1.txt)"
CloudShellでは /home/cloudshell-user 配下が永続化されるため、明示渡し用のテンプレート置き場として使いやすいです。
もし、個人で既にKiroのSteering機能を利用している場合、個人設定（~/.kiro/steering）をプロジェクト設定で上書きしないように注意が必要です。
組織全体で統一したSteeringを使わせるために、共有のS3バケットなどからテンプレートをダウンロードして使う運用フローを検討してもよいかもしれません。
CLIの仕様差分があり得るため、利用バージョンで kiro --help を確認してください。
yes / trust の扱い
ここは事故率に直結します。
- 本番では
trustを常用しない - 調査フェーズは原則1コマンドごとに確認
-
trustを使う場合は適用範囲と有効期限を手順化
「便利だから常時trust」は、最も避けたい運用です。
まとめ
Kiroを安全に使う鍵は、プロンプトの工夫だけではありません。
権限設計（IAM）・承認フロー・Steering運用をセットで設計して、はじめて事故耐性が上がります。
実装順としては次がシンプルです。
-
ReadOnlyAccessで調査ロールを作る - 調査で不足するActionだけを追加する
- 高リスク権限（SSMセッション/KMS復号）は別ロールに分離する
- Steeringをテンプレート運用する
Kiroは非常に優秀です。だからこそ、最初に「できることを絞る設計」を入れておくことが、結果的に速く安全なインシデント対応につながります。ガードレールセキュリティを意識しつつ、存分にKiroで楽をしましょう！