Kiro CLI Custom Agent で SOC 2 証跡収集を自動化する

Last updated at 2026-05-06Posted at 2026-05-05

Zenn の連続投稿制限にかかったので、Qiita に変更。

サマリ

2026/4 に Kiro 公式ブログが公開した Planview 事例（"Planview saves 40+ hours per audit cycle by automating SOC 2 compliance with Kiro CLI"）は、SOC 2 証跡収集を Kiro CLI Custom Agent で自動化した実装報告。本記事は、事例の定量効果と、Planview が公開した JSON 構成を起点に、SOC 2 証跡自動化向けの Custom Agent 設計を整理する。

Planview が報告した効果:

指標	効果
監査サイクルあたりの工数削減	40+ 時間
全体効率化	60%
監査依頼への対応速度	3-4 倍
SDE sprint 節約	1-1.5 sprint / 人

技術的な骨子は以下のとおり。

~/.kiro/agents/soc2-compliance.json に Custom Agent を 1 つ定義するだけ
aws ビルトインツールに IAM / CloudTrail / Config / GuardDuty / SecurityHub / Inspector / KMS / S3 の 8 サービスをホワイトリスト化
allowedTools × aws.autoAllowReadonly × write.allowedPaths の三層設計で、証跡収集は承認不要・インフラ変更は物理的に不可能
/help Help me create a custom agent ... で Kiro CLI 組み込みの [help] エージェントが初稿を自動生成
SaaS コンプラ（SOC 2 / ISO 27001）の証跡運用は Kiro CLI Custom Agent の得意領域。FISC / ISMAP のようなデータレジデンシー厳格要件下では Claude Code on AWS、証跡運用は Kiro CLI Custom Agent と役割で棲み分ける

はじめに

先行記事「規制業界のデータレジデンシー要件下で AI エージェントの推論を日本国内に閉じる」では、FISC 11 版 / ISMAP / 3 省 2 ガイドライン / 個情法 28 条のようなデータ所在地の厳格な規制下では、inference profile（jp.anthropic.* 等）を明示指定できない Kiro CLI は構造的に選択肢から外れ、JP CRIS 対応の Claude Code on AWS が実務的な解になる、と論じた。

しかし SaaS ベンダーが海外顧客向けに取得する SOC 2 / ISO 27001 のようなコンプライアンスでは、データ所在地よりも「統制の運用証跡を収集・整理する作業」そのものが重い負担になる。Planview 事例は、この領域で Kiro CLI Custom Agent が力を発揮する具体例だ。

想定読者:

SOC 2 Type II の年次監査を経験した SaaS 開発チーム
証跡収集を自動化したい CCoE / SRE / Platform Engineering 担当
Kiro CLI Custom Agent の実装例を具体的に知りたい
データレジデンシー規制下以外で Kiro CLI が効く領域を理解したい

構成:

Planview 事例の骨子
SOC 2 向け Custom Agent の設計（JSON 完全版から読み解く）
Agent の作成・起動・運用
規制業界 vs SaaS コンプラ — 役割分担で使い分ける
免責と運用上の注意

1. Planview 事例の骨子

Planview は「3,000 社以上のグローバル顧客を持つ Strategic Portfolio Management の SaaS リーダー」とブログに記載されている。

1.1 Before / After

	Kiro 導入前	Kiro CLI Custom Agent 導入後
証跡収集方法	コンソール / API から手動で抽出、スプレッドシート管理	`soc2-compliance` エージェントが会話ベースで抽出・整形
必要スキル	クラウドサービスと SOC 2 の両方に精通した複数人の連携	プロンプトを書けるエンジニア 1 人
所要時間	40+ 時間 / サイクル	オンデマンドで数分〜数十分
頻度	年 1 回の大仕事	継続収集（必要時にいつでも）

定量効果は冒頭の表のとおり（40+h / 60% / 3-4x / 1-1.5 sprint）。

1.2 継続的コンプライアンスプラットフォームとの関係

ブログは Planview が「継続的コンプライアンスの採用を長期的に計画しており、Q1 2025 に商用の継続的コンプライアンスプラットフォームを評価した」と述べる（具体的な製品名はブログ内では挙げられていない）。つまり Kiro CLI Custom Agent は 重厚な commercial platform を導入する前の橋渡し として機能しており、「GRC ツールが整う前に証跡収集の重労働を先に解消する」という運用実績を持つ。

2. SOC 2 向け Custom Agent の設計

まず完成形の JSON を示し、そこから仕様と設計意図を読み解く。

2.1 JSON 完全版

~/.kiro/agents/soc2-compliance.json（またはプロジェクト配下の .kiro/agents/soc2-compliance.json）:

{
  "name": "soc2-compliance",
  "description": "SOC 2 Type II 証跡収集と監査準備を支援するエージェント",
  "prompt": "file://./prompts/soc2-expert.md",
  "tools": [
    "read",
    "write",
    "aws"
  ],
  "allowedTools": [
    "read"
  ],
  "toolsSettings": {
    "write": {
      "allowedPaths": [
        "./compliance/**",
        "./policies/**",
        "./audits/**",
        "./security/**"
      ]
    },
    "aws": {
      "allowedServices": [
        "iam", "cloudtrail", "config", "guardduty",
        "securityhub", "inspector", "kms", "s3"
      ],
      "autoAllowReadonly": true
    }
  },
  "resources": [
    "file://./policies/**/*.md",
    "file://./compliance/**/*.md",
    "file://./audits/**/*.json",
    "file://./security/controls/**/*.yaml"
  ],
  "hooks": {
    "preToolUse": [
      {
        "matcher": "use_aws",
        "command": "{ echo \"$(date -Iseconds) - AWS CLI call:\"; cat; echo; } >> /tmp/soc2_agent_audit.log"
      }
    ]
  },
  "model": "claude-sonnet-4-6"
}

Kiro Custom Agent の主要フィールドのうち、本設計で利用しているのは name / description / prompt / tools / allowedTools / toolsSettings / resources / hooks / model。他にも toolAliases / mcpServers / keyboardShortcut / welcomeMessage / includeMcpJson があるが、証跡収集用途では上記で十分。

設定ファイルの配置:

プロジェクト配下 .kiro/agents/（チームで共有、Git 管理）
グローバル ~/.kiro/agents/（個人用）
両方に同名があれば ローカル優先

SOC 2 証跡収集は組織的な運用なのでリポジトリ配下に置き、Git で差分レビュー可能にするのが推奨。

2.2 セキュリティ設計の三層構造

このエージェントの安全性は、3 つのフィールドが噛み合うことで成立している。

層 1: allowedTools — 承認不要ツールの境界

Kiro CLI のデフォルトは「read-only のみ pre-approve、write 系は都度承認」。本設計でも allowedTools: ["read"] としてファイル読み取りのみ承認不要にしている。write と aws は tools には含めつつ allowedTools には入れない。

層 2: toolsSettings.aws.autoAllowReadonly: true — AWS read-only の自動許可

aws を allowedTools に入れずに read-only 操作だけを通すための設定。describe-* / list-* / get-* は自動承認、それ以外（delete-* / put-* 等）は都度承認になる。結果:

aws iam list-users / aws cloudtrail describe-trails 等の証跡収集 → 承認不要で連続実行
aws iam delete-user / aws s3api put-bucket-policy 等の変更系 → 都度承認ダイアログ

層 3: toolsSettings.write.allowedPaths — ファイル書き出し先の限定

write ツールの書き込み先を ./compliance/** など証跡保存先に限定。仮にエージェントが暴走して任意のファイルを書き換えようとしても、~/.ssh/ や /etc/ には手が出せない。

この 3 層で、証跡収集は承認不要でスムーズに流れ、インフラ変更とリポジトリ外ファイルの破壊は物理的に不可能 という状態を作る。これが Planview 事例の安全性の核。

2.3 AWS 8 サービスと SOC 2 コントロールのマッピング

Planview ブログで挙げられた 8 サービスを SOC 2 Trust Services Criteria にマッピング:

サービス	SOC 2 での用途
IAM	ユーザー・ロール・ポリシー（CC6.1 論理アクセス、CC6.2 ID 管理）
CloudTrail	管理操作の証跡（CC7.2 モニタリング）
Config	構成変更履歴（CC8.1 変更管理）
GuardDuty	脅威検出（CC7.3 セキュリティイベント）
Security Hub	コントロール状況の集約（CC3 リスク評価）
Inspector	脆弱性スキャン（CC7.1 脆弱性管理）
KMS	暗号鍵管理（CC6.7 データ保護）
S3	ストレージの暗号化・アクセス制御・ロギング設定

他サービス（EC2 / Lambda / RDS 等）への拡張は必要時に追加する。広げすぎるとエージェントの責務が曖昧になるため、最小構成からの増分運用が実務的。

2.4 `resources` で自社コンテキストを注入

プロジェクトに SOC 2 関連のドキュメントがあれば resources で自動ロードさせる。社内ポリシー（./policies/）、コンプラ関連ドキュメント（./compliance/）、過去監査の証跡（./audits/）、セキュリティコントロール定義（./security/controls/）。これでエージェントが自社の文脈を踏まえて証跡を収集・整理できる。

2.5 `hooks` でエージェント自身のメタ監査ログ

JSON 例の hooks.preToolUse は、エージェントが aws ツールを使うたびにタイムスタンプ + 実行内容を /tmp/soc2_agent_audit.log に追記する。matcher は内部ツール名（fs_read / fs_write / execute_bash / use_aws）を指定する必要がある点に注意。

SOC 2 Type II は運用証跡の継続性（最低 6 ヶ月）が求められるため、メタ監査 として別アカウントの S3 に長期保管する運用を組むと内部統制的に整合性がとれる。ライフサイクルフックは他にも agentSpawn / userPromptSubmit / postToolUse / stop があり、用途に応じて使い分けられる。

3. Agent の作成・起動・運用

3.1 `/help` エージェントで初稿を自動生成

JSON を手書きするのが面倒な場合、Kiro CLI 組み込みの [help] エージェントを使う。Planview ブログも以下のコマンドを例示している:

kiro-cli
> /help Help me create a custom agent for soc-2 compliance

動作は、/help でカレントエージェントから [help] に一時切替 →[help] が Kiro CLI の内部ドキュメントを参照して agent config の初稿を生成 → ユーザーがレビュー・微調整 → もう一度 /help で元のエージェントに戻る、という流れ。

実機で /help を起動すると [help] エージェントが提供できる機能を明示する:

Slash commands (/agent, /context, /tools, etc.) / Built-in tools / Configuration settings / Features like MCP, Tangent Mode, Code Intelligence / Create/modify agents, prompts, and LSP configs in .kiro/

「Create a new agent for me」は公式のサンプル質問としてもメニューに並んでいる。JSON スキーマを完全に覚える必要はない。ターミナルから直接スケルトンを生成したい場合は kiro-cli agent create を使う。

3.2 起動と切替

Planview ブログが示す起動コマンドをそのまま引用する:

# 新 UX（TUI モード）
kiro-cli --tui --agent soc2-compliance

# classic（従来のターミナル UX）
kiro-cli --classic --agent soc2-compliance

# 対話セッション中に切替
kiro-cli
> /agent soc2-compliance

--agent で起動時にエージェントを指定、/agent <name> で対話中に切り替え（picker UI を使いたい場合は /agent swap）。デフォルトエージェントを固定したい場合は kiro-cli agent set-default <name>。

3.3 典型プロンプトと期待動作

Planview ブログからの引用（原文ママ）:

"Generate a SOC 2 CC6.1 compliance report showing all S3 buckets with their encryption status, public access settings, and access logging configuration."

このプロンプトに対する想定動作:

aws s3api list-buckets で全バケット列挙
各バケットに対して get-bucket-encryption / get-public-access-block / get-bucket-logging
タイムスタンプ付きで整形（CC6.1 要件にマッピング）
./compliance/ 配下に Markdown / JSON で保存

allowedTools: ["read"] + autoAllowReadonly: true + write.allowedPaths により、このワークフローは 承認ダイアログなしで一気に流れる。一方、delete-* のような破壊操作を書いてしまってもエージェント側で都度ブロックされる。

3.4 監査サイクルへの組込み

年次監査 3 ヶ月前: Custom Agent で証跡収集ドライランを実行、不足項目を特定
監査 1 ヶ月前: 不足項目を是正（IaC 修正、ポリシー更新）
監査フィールドワーク: エージェントに最新の証跡を収集させ、監査担当に提出
監査後: 同じエージェントで次サイクル準備を開始（継続運用）

オンデマンド化により「年 1 回の大仕事」から「継続的な状態確認」へ監査準備のリズムが変わる。

4. 規制業界 vs SaaS コンプラ — 役割分担で使い分ける

先行記事「規制業界のデータレジデンシー要件下で AI エージェントの推論を日本国内に閉じる」で示した規制業界フィルターは、データレジデンシー要件で Kiro CLI を構造的に除外する。一方、本記事の SOC 2 文脈では Kiro CLI Custom Agent が活躍する。両者は対立ではなく 役割分担 で整理するのが実務解。

観点	規制業界（データレジデンシー）	SaaS コンプラ（本記事のスコープ）
主な規制	FISC / ISMAP / 3 省 2 / 個情法 28 条	SOC 2 / ISO 27001 / HIPAA
重視される統制	データ所在地・推論処理所在地	論理的アクセス制御・証跡運用
Kiro CLI の適合性	✗ inference profile 指定不可で構造的に不可	◯ Custom Agent で証跡収集に適合
Claude Code on AWS の適合性	◯ JP CRIS / In-Region 対応	◯ ただし Custom Agent 同等機能は別検討
主な使いどころ	AI による開発支援（国内完結）	監査証跡収集の自動化

金融・医療のような厳格な規制業界でありながら SaaS 的に海外顧客に売るプロダクトを持つ組織では両立が必要になる。その場合の割り当て:

開発環境の AI コーディング支援 → Claude Code on AWS（JP CRIS / Tokyo In-Region、先行記事の構成）
SOC 2 証跡収集の自動化 → Kiro CLI Custom Agent（本記事の構成、社外流通しないメタ運用として扱う）

1 つのツールに全てを委ねるとどちらかの要件で不整合が起きる。ツールは道具、統制は組織の責務 という原則で役割分担する。

5. 免責と運用上の注意

Planview 公式ブログも明記する注意事項。本記事でも強調する。

AI 生成証跡 ≠ deterministic コンプライアンスツール

Planview ブログからの引用:

"AI-generated compliance outputs are highly dependent on the specificity and scope of the prompts provided to the agent... All AI-generated recommendations, policy text, and audit evidence should be reviewed and validated by qualified compliance professionals before being used in production."

Kiro CLI Custom Agent は監査プロセスを加速するツールであり、deterministic なコンプライアンスプラットフォーム（GRC ツール）の代替ではない
AI が生成した recommendation / policy text / audit evidence は、qualified compliance professional によるレビュー・validation が必須
本番環境への適用や監査人への提出前に、人間の最終確認を経ること
エージェントが誤った証跡を生成する可能性（誤解・省略・古い情報）を前提に運用設計する

運用チェックリスト:

プロンプトの具体性を上げる: 「SOC 2 の準備をして」ではなく「CC6.1 に該当する S3 のアクセス制御と暗号化設定を一覧化して」
出力のレビュー: 収集した証跡は必ず人間が spot check、特に CC6 / CC7 系
API 権限の最小化: aws.allowedServices は最小構成で維持。拡張は影響分析を経てから
write tool の制限維持: allowedPaths で証跡保存先のみに絞る。インフラ変更権限は持たせない
Agent 自身の audit log を保全: hooks.preToolUse で取った log は別アカウントの S3 に長期保管（SOC 2 Type II は最低 6 ヶ月の運用証跡が必要）

将来パス

Planview も想定するとおり、継続的コンプライアンスプラットフォーム（Vanta / Drata / Secureframe / AWS Audit Manager 等、一般論として）への移行は視野に入れてよい。Kiro CLI Custom Agent は 初期立ち上げ や 小規模組織での継続運用 に向いた軽量な選択肢であり、組織成長と要件複雑化に応じて他のツールと併用・置換を検討する。

まとめ

Planview 事例 は SOC 2 証跡収集を Kiro CLI Custom Agent で自動化し、40+ 時間 / サイクル、60% 効率化、3-4x 早い audit response を達成した
設計の核は allowedTools: ["read"] × aws.autoAllowReadonly: true × write.allowedPaths の三層構造。証跡収集は承認不要で流れ、インフラ変更とリポジトリ外ファイル破壊は物理的に不可能
AWS 8 サービス（IAM / CloudTrail / Config / GuardDuty / SecurityHub / Inspector / KMS / S3）を SOC 2 CC コントロールにマッピングして aws.allowedServices で絞り込む
/help Help me create a custom agent ... で組み込みの [help] エージェントが agent config の初稿を自動生成。JSON スキーマを完全に覚える必要はない
規制業界 vs SaaS コンプラは役割分担で使い分ける: データレジデンシー要件 = Claude Code on AWS、SOC 2 / ISO 27001 的な証跡運用 = Kiro CLI Custom Agent

Kiro CLI は規制業界で使えないツールではなく、規制業界とは別カテゴリの用途で本領を発揮する。データ所在地を重視するならモデル呼び出しの基盤を選び、証跡運用を重視するならエージェント機構そのものを選ぶ。評価軸を分けて考えることで、どちらのツールも適切な場所で使える。

Kiro CLI Custom Agent で SOC 2 証跡収集を自動化する

サマリ

はじめに

1. Planview 事例の骨子

1.1 Before / After

1.2 継続的コンプライアンスプラットフォームとの関係

2. SOC 2 向け Custom Agent の設計

2.1 JSON 完全版

2.2 セキュリティ設計の三層構造

2.3 AWS 8 サービスと SOC 2 コントロールのマッピング

2.4 `resources` で自社コンテキストを注入

2.5 `hooks` でエージェント自身のメタ監査ログ

3. Agent の作成・起動・運用

3.1 `/help` エージェントで初稿を自動生成

3.2 起動と切替

3.3 典型プロンプトと期待動作

3.4 監査サイクルへの組込み

4. 規制業界 vs SaaS コンプラ — 役割分担で使い分ける

5. 免責と運用上の注意

将来パス

まとめ

参考リンク

公式情報

筆者の関連記事（シリーズ）

Kiro CLI Custom Agent で SOC 2 証跡収集を自動化する

サマリ

はじめに

1. Planview 事例の骨子

1.1 Before / After

1.2 継続的コンプライアンスプラットフォームとの関係

2. SOC 2 向け Custom Agent の設計

2.1 JSON 完全版

2.2 セキュリティ設計の三層構造

2.3 AWS 8 サービスと SOC 2 コントロールのマッピング

2.4 resources で自社コンテキストを注入

2.5 hooks でエージェント自身のメタ監査ログ

3. Agent の作成・起動・運用

3.1 /help エージェントで初稿を自動生成

3.2 起動と切替

3.3 典型プロンプトと期待動作

3.4 監査サイクルへの組込み

4. 規制業界 vs SaaS コンプラ — 役割分担で使い分ける

5. 免責と運用上の注意

将来パス

まとめ

参考リンク

公式情報

筆者の関連記事（シリーズ）

2.4 `resources` で自社コンテキストを注入

2.5 `hooks` でエージェント自身のメタ監査ログ

3.1 `/help` エージェントで初稿を自動生成