セキュリティ運用は Kiro CLI か AWS DevOps Agent のカスタムエージェントか？同じ SecOps タスクで比べてみた

はじめに

こんにちは！ひろたこです。

DevOps Agent にはユーザー定義のカスタムエージェント機能があります。これを使えば SecOps も DevOps Agent で代用できるのでは……？と思ったので検証してみました！

そこでこの記事では、同一の SecOps タスク3本（GuardDuty トリアージ / WAF・CloudTrail ログ分析 / 日次セキュリティレポート）を、DevOps Agent のカスタムエージェントと Kiro CLI の両方で実行して比較しました。
この記事を読むと、以下がわかります。

• AWS Frontier Agent の役割分担と「SecOps の隙間」の正体
• DevOps Agent カスタムエージェントを CLI だけでセットアップして SecOps タスクを自律実行させる方法
• Kiro CLI の read-only エージェント＋単発 chat コマンドで同じタスクをこなす方法
• Agent Space ロールの権限モデルと、集計 API（GetFindingsStatistics）だけ抜けている落とし穴
• そして最大の読みどころ、エージェントが権限エラーで件数を取り違えた場面を、トラジェクトリで突き止めた話

AWS Frontier Agent の役割分担と「SecOps の隙間」

まず前提の整理です。2026年7月10日時点の公式ドキュメントで裏取りした、各エージェントの守備範囲がこちらです。

つまり「本番で GuardDuty が検出を上げた。誰が見る？」という運用フェーズのセキュリティは、どちらの Frontier Agent のスコープではありません。ここが「SecOps の隙間」です。

この隙間を埋める選択肢が3つあります。

1. Kiro（CLI）を運用に組み込む：汎用の AI エージェントに SecOps タスクを任せるアプローチ
2. DevOps Agent のカスタムエージェントで代用する：DevOps Agent の拡張機能を SecOps に転用するアプローチ
3. 人力で頑張る：人の長年の技術力で対応するアプローチ

DevOps Agent のカスタムエージェントとは

DevOps Agent のカスタムエージェントは、以下の要素で構成されるユーザー定義エージェントです（公式ドキュメントより）。

• システムプロンプト：Markdown で最大 50,000 文字
• MCP ツール：Agent Space 内から選択して割り当て（ツール割当は Chat 経由のみ、Web アプリのフォームでは不可）
• スキル：最大 200 個
• トリガー：現状スケジュールのみ（cron・rate 式）
• トラジェクトリ：実行ごとに推論・ツール呼び出し・結果の完全記録が残り、チーム共有可能

検証前に権限モデルを押さえておく

カスタムエージェントは、Agent Space ロールの権限の範囲でしか AWS リソースを触れません。なので検証前に、このロールに付く AWS マネージドポリシーを確認しておきます。CLI オンボーディングガイドと「DevOps Agent IAM permissions」ページに明記されているとおり、付与されるのは AIDevOpsAgentAccessPolicy（JSON 全文もドキュメントに掲載）でした。SecOps に必要な読み取りはひととおり揃っています。

• 読める：guardduty:GetFindings / securityhub:GetFindings（検出の詳細取得）、cloudtrail:LookupEvents、logs:StartQuery、wafv2:Get*/List* など
• 完全読み取り専用：隔離やキー無効化などの是正実行はできない

環境・前提条件

2026年7月10日時点の検証環境です。

なお DevOps Agent 自体の GA 時期・対応リージョン・料金体系といった基本情報は、SecOps の比較という本題から外れるので本記事では省きます（別の DevIO 記事にゆずります）。本検証は東京リージョン・無料トライアルの枠内で実施しました。

やったこと

1. 監視対象アプリの構築と攻撃シミュレーション

比較の土台として、両エージェントに同じものを見せるための「監視対象アプリ」を CDK 1スタック（SecOpsPocTargetStack）で東京リージョンに構築しました。構成は次のとおりです。

• Lambda（Node.js 20）：/items?q= のクエリをエコーする API
• API Gateway REST：secops-poc-target-api（ステージ prod）
• WAF WebACL（REGIONAL）：① AWSManagedRulesCommonRuleSet ② SQLiRuleSet ③ レートベースルール（100 リクエスト/5分/IP で block）
• WAF ログ → CloudWatch Logs ロググループ aws-waf-logs-secops-poc

続いて、WAF に「事件」を起こしてもらうための攻撃シミュレーションスクリプト attack-sim.sh を実行しました。実測結果のサマリです。

WAF のブロックログを CloudWatch Logs Insights（filter action="BLOCK"、過去1時間）で確認すると、RateLimit 72件・AWSSQLiRules 4件が記録されていました。ログ反映は数分のラグがあると言われますが、今回は実測ではすぐ取得できました。

2. GuardDuty サンプル検出で「Ground truth」を作る

エージェントの報告が正しいか答え合わせできるように、GuardDuty のサンプル検出を生成して Ground truth（答え合わせ用の正解データ） を先に固めておきます。

$ aws guardduty create-sample-findings --detector-id 18cf9fbce...

生成されたサンプル検出は 404件。内訳（Ground truth）は以下のとおりです。

この「404件」が、以降のエージェントの報告を答え合わせする基準になります。

3. 共通の SecOps タスク3本

両エージェントに同じ内容で依頼するタスクはこの3本です。

1. タスク1：GuardDuty トリアージ（検出を重要度別に集計し、対応優先度を付ける）
2. タスク2：ログ分析（2a：WAF ブロックログの分析 / 2b：CloudTrail で怪しい操作の有無を調査）
3. タスク3：日次セキュリティレポート（GuardDuty＋WAF＋CloudTrail を横断した日次サマリ）

4. DevOps Agent カスタムエージェントでやってみる

Agent Space のセットアップは CLI で数分

まず発見だったのが、Agent Space のセットアップが aws devops-agent CLI だけで完結することです（コンソール不要）。CLI 名前空間は devops-agent、サービスプリンシパルは aidevops.amazonaws.com で、aws-cli 2.35.16 に同梱済みでした。大きく4ステップです。

① IAM ロールを2つ作成（Agent Space 用に AIDevOpsAgentAccessPolicy＋Resource Explorer SLR 用インラインポリシー / Web アプリ管理用に AIDevOpsOperatorAppAccessPolicy）。

② Agent Space を作成します。--locale ja-JP を指定すると応答が日本語になります（15言語対応）。

$ aws devops-agent create-agent-space \
    --name <AgentSpace名> \
    --locale ja-JP

{
  "agentSpace": {
    "name": "<AgentSpace名>",
    "locale": "ja-JP",
    "agentSpaceId": "<AGENT_SPACE_ID>",
    "createdAt": "2026-07-10T05:41:58Z"
  }
}

返ってきた agentSpaceId を、以降のコマンドで使い回します。

③ AWS アカウントを関連付けて、トポロジー探索を有効化します。②で作った Agent Space に、①の Agent Space ロールで対象アカウントを紐づけるイメージです。

$ aws devops-agent associate-service \
    --agent-space-id <AGENT_SPACE_ID> \
    --service-id aws \
    --configuration '{"aws":{"assumableRoleArn":"<AgentSpaceロールARN>","accountId":"<アカウントID>","accountType":"monitor"}}'

{ "associationId": "<ASSOCIATION_ID>", "status": "valid" }

status が valid になれば、この AWS アカウントのリソースがトポロジー探索の対象になります。

④ Web アプリ（人間のオペレーター用 UI）を有効化します。

$ aws devops-agent enable-operator-app \
    --agent-space-id <AGENT_SPACE_ID> \
    --auth-flow iam

{ "webAppUrl": "https://<AGENT_SPACE_ID>.aidevops.global.app.aws" }

ここまで実測で数分。コンソール操作を想定していた見積もり（20分程度）より大幅に速く、IaC 的に再現できるのも好印象でした。

なお、トポロジーへの監視対象アプリの反映は Resource Explorer のインデックス構築に時間がかかり（数十分〜1時間）、作成直後は未反映でした。急ぎの検証では待ち時間を見込んでおきましょう。

権限の落とし穴：GetFindingsStatistics だけ抜けている

自動作成されたロールに付いていたのは、事前に確認したとおり AIDevOpsAgentAccessPolicy でした。実物を aws iam get-policy-version で確認すると、guardduty:GetFindings / securityhub:GetFindings に加えて cloudtrail:LookupEvents / logs:StartQuery / wafv2:GetWebACL まで含み（総アクション数 880）、SecOps 用途の読み取りはほぼ揃っています。

ところが1つだけ穴がありました。このポリシーに guardduty:GetFindingsStatistics は入っていません。Agent Space ロールで get_findings_statistics を呼ぶと AccessDeniedException になることを実測で確認しました。地味な欠落ですが、これが後述する「件数のズレ」の引き金になります（詳しくは「ハマったポイント」で）。

集計 API を使わせたい場合は追加ポリシーで補う必要があります。作成フローにはロールの3択（自動作成 / 既存割当 / テンプレート）があり、自動作成ロールにも通常の IAM ロールとして追加ポリシーをアタッチ可能です。公式のベストプラクティスガイドも、この Agent Space ロールについて次のように「マネージドポリシー＋追加権限」を前提に書いています。

This role requires the ... managed policy plus additional permissions for AWS Support and expanded capabilities.

（このロールには、マネージドポリシーに加えて、AWS Support や拡張機能のための追加権限が必要です）

つまり「マネージドポリシーだけで完結」ではなく、用途に応じて足す前提の設計、ということですね。

タスク実行は create-backlog-task ＋ list-journal-records

実行モデルにも癖がありました。インタラクティブ chat の実ターンを送る CLI は存在せず（create-chat は executionId を返すのみ＝Web アプリ前提）、CLI からの自律実行は create-backlog-task を使います。

$ aws devops-agent create-backlog-task --task-type INVESTIGATION ...

結果の取得は list-executions と、トラジェクトリ全量を返す list-journal-records です。

$ aws devops-agent list-journal-records ...

エージェントは内部で use_aws ツールを使って AWS API を叩き、応答は日本語（内部思考は英語）でした。この list-journal-records は、推論・ツール呼び出し・その結果まで全量を返すので、レポートの内容を機械的に裏取りできます。

タスク1：GuardDuty トリアージ（run1 / run2）

run1（集計トリアージ） では、日本語で構造化された立派なレポートが返ってきました。サンプル検出であること（i-99999999 や IP 198.51.100.0 などのプレースホルダ）を正しく明記し、MITRE ATT&CK 別の分布と重要度別の推奨対応まで付いていて、手順書としての質は高い。……のですが、報告された件数は 354件（High 148 / Medium 145 / Low 61）。Ground truth は 404件です。この違和感の正体は「ハマったポイント」で掘り下げます。

run2（詳細取得を明示要求） では、トラジェクトリ上で get_findings×2（3件→6件）＋list_findings×1 を観測。finding ごとに ID / Type / Severity / EventFirstSeen-LastSeen / 影響リソース / 攻撃元 IP・国・ASN / MITRE 戦術を正確に列挙してきました。例えば 52f6f92e... は AttackSequence:S3/CompromisedData、Severity 9.0、IAM ユーザー john_doe、Tor 出口ノード 10.0.0.1（US）まで正確です。

つまり 「List 止まりで詳細が読めない」問題は GA 版では起きません（実測）。run1 で get_findings が呼ばれなかったのは権限不足ではなく、「集計タスクには一覧で足りる」というツール選択の結果でした。

タスク2：WAF / CloudTrail ログ分析

タスク2a（WAF） の報告は正確でした。総リクエスト 306 / BLOCK 76（RateLimit 72・SQLi 4）/ ブロック元は単一 IP 110.66.137.77、SQLi ペイロードの列挙まで実ログと一致。ただし気になる点が1つ。CloudWatch Logs Insights の実行が use_aws トラジェクトリに1件も記録されていませんでした。一部の内部ツールはジャーナルに出ないようで、監査目的でトラジェクトリを使う場合の盲点です。

タスク2b（CloudTrail）は lookup_events×2（東京=IAM イベント0件、us-east-1=変更系13件）。DevOpsAgentRole の作成や CDK 由来のロール作成を「正当なセットアップ / IaC」と識別して「怪しい操作なし」と正しく判定し、危険イベント（CreateUser / CreateAccessKey / UpdateAssumeRolePolicy）が0件であることも明示しました。ここは文句なしです。

タスク3：日次レポート＋定期実行の機構

日次レポート（1回の INVESTIGATION で GuardDuty＋WAF＋CloudTrail を横断、use_aws 最大15回）では、今回は AccessDenied を正直に回避しました。「get_findings_statistics は権限拒否のため list_findings をフィルタ集計した」と明記した上で、Critical 11 / High 160 / Medium 167 / Low 66 ＝合計404件と正確。さらに相関分析が秀逸で、WAF のブロック元 IP と IAM 操作の発信元 IP が同一の PoC 端末であることを時系列・IP で突合し、「外部からの攻撃ではない」と正しく結論付けました。ここは「おお、賢い…」と声が出ました。

定期実行は aws devops-agent create-trigger の --condition schedule={expression=...}（現状 schedule のみ）で組み込めます。発火＝課金となるため、本検証ではライブトリガーは未作成です（機構のみ確認、list-triggers は空）。ちなみに公式 pricing の例4がまさにこのタスク3と同型で、日次カスタム SRE エージェント（2分/回×30日）＝$29.88/月という試算が載っています。

5. Kiro CLI でやってみる

read-only エージェント設定＋単発 chat コマンド

Kiro 側の構成はぐっとシンプルです。エージェント設定 .kiro/agents/secops-readonly.json で aws ツールを read-only に限定し（deniedCommands で create / delete / update / put / iam 系を拒否）、ステアリングファイル .kiro/steering/secops-context.md に PoC のコンテキストを書いておく。これだけです。

実行は単発の chat コマンドで、TTY 無し・API キー無しで動きました。

$ kiro-cli chat "<タスクのプロンプト>"

タスク1〜3の実行結果

特筆すべきは、全タスクで件数が Ground truth の404件と一致し、使用した API を末尾に正確に自己申告してきたことです。1つのエージェント設定 JSON＋単発 CLI で3タスク完遂できました。

定期実行については内蔵スケジューラが無いため、cron / launchd との併用になります。なお headless での常用には KIRO_API_KEY（Pro プラン）が必要です。今回は KIRO FREE のクレジット枠内で全タスク完了しました。

ハマったポイント

1. 権限エラーが伏せられ、件数がズレて報告された（★要注意）

タスク1の run1 です。レポート自体は日本語で構造化された立派なものでしたが、件数が354件と Ground truth（404件）より過少でした。「集計方法の違いかな？」と思い、list-journal-records でトラジェクトリを開いて突き合わせました。

トラジェクトリの実測はこうでした。

get_findings_statistics（重要度別の集計 API）だけが権限拒否になっていました。tool_result にはこう残っています。

# get_findings_statistics の tool_result（抜粋・アカウントIDはマスク）
AccessDeniedException: User: arn:aws:sts::<ACCOUNT_ID>:assumed-role/DevOpsAgentRole-AgentSpace/monitorAssociationRoleSession
is not authorized to perform: guardduty:GetFindingsStatistics

にもかかわらず、最終レポートには「get_findings で全354件を個別取得・集計した」と書かれていました。トラジェクトリ上、get_findings は0回。実際には使えなかった集計 API のぶんを、一覧から数えた概算で埋めた結果、354件というズレた数字とやや実態と違う手順説明になったのだと思われます。

興味深いことに、同じ AccessDenied でもタスク3の日次レポートでは「権限拒否のため list_findings をフィルタして集計した」と正しく明記し、404件を正確に報告しました。同じ状況でも run によって振る舞いが変わりうる、という点は運用に乗せる前に押さえておきたいところです。

ではどうすればよかったか。原因ははっきりしていて、GetFindingsStatistics の権限が Agent Space ロールに無かったことに尽きます。集計を任せるなら、この権限を先に足しておく（追加ポリシーは前述のとおりアタッチ可能）か、システムプロンプトで「statistics が使えなければ list からページングして数える」と手順を具体化しておけば、この取り違えは避けられたはずです。そして何より、こうしたズレをトラジェクトリ（list-journal-records）で機械的に突き合わせられるのは DevOps Agent の大きな強みでした。エージェントの出力はそのまま鵜呑みにせず、Ground truth とトラジェクトリで裏取りする——「監査できる仕組みが最初から用意されているか」は、エージェント選定の実用要件だと感じた一件でした。

2. AIDevOpsAgentAccessPolicy に GetFindingsStatistics は無い

上のハマり1の根っこがこれです。実際に付く AIDevOpsAgentAccessPolicy は、GetFindings（検出の詳細取得）は含むのに、guardduty:GetFindingsStatistics（集計 API）は含まれず、呼ぶと AccessDeniedException になります（実測）。地味な非対称ですが、集計系タスクを任せるなら追加ポリシーで先に塞いでおくのが安全です。

3. CDK の logRetention は非推奨、余計な Lambda がトポロジーに紛れ込む

監視対象アプリの CDK で lambda.Function に logRetention を指定したところ、deprecation 警告が出ました。logRetention はログ保持期間を設定するために custom-resource Lambda を裏で追加生成する旧 API で、そのままだと監視対象トポロジーに無関係な Lambda が1つ増えてしまいます。

回避策は、明示的に logs.LogGroup を作って logGroup プロパティで渡すこと。イメージとしてはこうです。

- logRetention: logs.RetentionDays.XXX,  // 非推奨。custom-resource Lambda が追加生成される
+ logGroup: logGroup,  // 明示的に作成した logs.LogGroup を渡す

これでトポロジーがクリーンになりました。今回は DevOps Agent にトポロジーを構築させる検証なので、「エージェントに見せる地図に余計な建物を描かない」という意味でも、この書き換えは好都合でした。新規の CDK コードなら最初から logGroup で書くのがおすすめです。

4. ロケール指定は ja_JP でなく ja-JP

create-agent-space のロケールに ja_JP（アンダースコア）を渡すと ValidationException で怒られます。正しくは BCP-47 形式の **ja-JP（ハイフン）**です。合わせて、heredoc に IAM ポリシー JSON を書くと変数展開で壊れることがあるので、静的ファイル＋file:// 指定が安全でした。

結果

タスク別の結果比較

観点別の採点（◎優 / ○良 / △課題）

数字で見ると、正確性・自己申告の忠実性は Kiro CLI が明確に上回り、権限分離・定期実行・相関分析は DevOps Agent が強いという、きれいに補完し合う結果になりました。

まとめ

今回の検証でわかったことです。

• AWS Frontier Agent には SecOps の隙間があり、DevOps Agent（可用性特化）と Security Agent（SDLC 特化）のどちらも日々の検知対応をしていない
• DevOps Agent カスタムエージェントは CLI だけで数分でセットアップでき、Agent Space ロールに付く AIDevOpsAgentAccessPolicy は guardduty:GetFindings / securityhub:GetFindings を含む。SecOps 用途の読み取り権限はひととおり揃っている（ただしポリシー名が公式内でも AIOpsAssistantPolicy と割れているので実物確認は必須）
• そのポリシーでも guardduty:GetFindingsStatistics だけは抜けており、その AccessDenied 時に件数がズレ、呼んでいない API を「使った」と書かれた run があった（追加権限＋トラジェクトリ確認で対処可能）。一方で同じ拒否を正しく申告して404件を返す run もあり、run による振る舞いの差は運用前に押さえたい
• Kiro CLI は read-only エージェント設定＋単発 chat で3タスクすべて Ground truth どおりの404件 を報告し、使用 API も正確に自己申告。全タスク合計 Credits 4.89・7分弱で完了
• 使い分けの指針：常時監視・自律インシデント対応・権限分離が要る組織運用 → DevOps Agent カスタムエージェント / 手元での正確なアドホック調査・軽量導入 → Kiro CLI
• 両者は競合というより連携もありえます。公式ドキュメントも「mitigation plan は Kiro などの frontier agent が実装できる agent-ready instructions を出す」と示唆しており、検知〜計画を DevOps Agent、是正の実装を Kiro という分担は現実的です

個人的な最大の学びは、やはり「エージェントの出力は、必ずトラジェクトリと Ground truth で裏取りする」です。あの354件のレポート、単体で読んだら間違いなく信じていました。体裁の整った日本語レポートほど疑いにくいからこそ、list-journal-records のような監査手段が最初から用意されているかどうかは、エージェント選定の実用要件だと痛感しました。SecOps の一次判断材料にエージェントを使うなら、「答え合わせできる仕組み」ごと設計に組み込むことを強くおすすめします！

この記事が、AI エージェントにセキュリティ運用を任せようとしている方の判断材料になれば幸いです。
最後まで読んでいただき、誠にありがとうございました。

参考記事

• AWS Security Agent の機能（公式ドキュメント）
• AWS DevOps Agent（公式サイト）
• Working with DevOps Agent custom agents（公式ドキュメント）
• Creating a custom agent（公式ドキュメント）
• DevOps Agent IAM permissions（AIDevOpsAgentAccessPolicy の JSON 全文）
• AWS DevOps Agent CLI onboarding guide（Agent Space ロール作成手順）
• AIOpsAssistantPolicy（AWS マネージドポリシーリファレンス）
• Best practices for deploying AWS DevOps Agent in production（AWS DevOps Blog）