Security Hubの検知項目をお客様への課題起票文にするスキルをClaude Code自身に作ってもらった
こんにちは、クラウド事業本部 コンサルティング部の林です。
皆さんはSecurity Hubで検知された項目への対応をどのように進めていますか？
Security Hubは、AWS環境の設定をセキュリティのベストプラクティスに照らして自動チェックし、「EC2.9」のようなID付きで違反を検知してくれるサービスです。
この検知への対応をお客様と進める際は、課題管理ツール（弊社ではBacklogを使っています）に課題を起票するのですが、起票文の構成は毎回ほぼ同じ。「前も似たようなこと書いたな…」と思いながら、作業を繰り返していました。
「これ、Claude Codeのスキルにしたら楽になるのでは？」と作ってみたところ、コントロールIDと対象リソースを渡すだけで、ほぼそのまま使える文章が出てくるようになったので紹介します。
ちなみにスキル自体もClaude Codeに作ってもらいました。
スキル（Agent Skills）とは
ざっくり言うと、Claude Codeに独自の手順やルールを覚えさせる仕組みです。
手順や出力ルールを書いた SKILL.md を ~/.claude/skills/ 配下に置いておくだけで、依頼内容に合うスキルをClaude Codeが自動で読み込み、その内容に従って動いてくれます。
仕組みや作り方の詳細は、既にDevelopersIOに良記事があるので本記事では説明しません。
スキルの仕組み・作り方はこちらの記事が参考になります。
作ったもの
~/.claude/skills/securityhub-issue/ というフォルダを作成し、以下の2ファイルを置いています。
securityhub-issue/
├── SKILL.md # 入力の受け取り方・出力ルール
└── templates/
└── issue-template.md # 起票文の雛形
入力はコントロールIDと対象リソース一覧の2つだけです。
リソース一覧はマネコンからのコピペでもOKで、スキル側がパースして整形してくれます。
コントロールのタイトルと重要度はIDごとに決まっているので任意入力としました。
入力すればそれを正とし、未入力ならスキル側で補完して「補完した」と明示したうえで確認を促してくれます。
出力は、以下の構成のMarkdownです。課題管理ツールに貼り付けて使います。
- 課題概要（ID / タイトル / 重要度）
- 詳細
- 目的
- 検知理由
- 実施内容
- 完了条件
- 参考情報
- 末尾コメント
使ってみる
EC2.9を例にします。Claude Codeに次のように依頼します。
EC2.9の起票をお願い。対象は以下。
# ここにコンソールからコピペしたリソース一覧を貼り付け
生成される起票文がこちらです。ポイントは「実施内容」で修復と抑止の2方針を併記しているところです。
アカウントID・リソース名・Nameタグは、架空のものに置き換えています。
## 課題概要
Security Hubで検知しているコントロールの対処を行います。
- **ID**：EC2.9
- **タイトル**：EC2 インスタンスは、パブリック IPv4 アドレスを未設定にすることをお勧めします
- **重要度**：HIGH
## 詳細
### 目的
インターネットから直接到達可能なEC2インスタンスの削減による、攻撃対象領域の最小化
### 検知理由
対象のEC2インスタンスにパブリックIPv4アドレスが割り当てられています。
パブリックIPを持つインスタンスはインターネットから直接アクセス可能なため、セキュリティグループの設定次第では意図しないアクセスを受けるリスクがあります。
### 実施内容
対象インスタンスについて、パブリックIPの要否をご確認ください。
- **方針A（修復対応）**：パブリックIPが不要な場合、割り当てを解除します。再発防止として、サブネットの自動割り当て設定もあわせて確認します。
- **方針B（抑止対応）**：業務要件上必要な場合、Security Hubの検出結果のワークフローステータスを **`SUPPRESSED`（抑止済み）** に変更します。
なお、新規に起動したインスタンスは再度検知されるため、継続的に抑止する場合はSecurity Hubの自動化ルールの利用をご検討ください。
手順は「参考情報」をご参照ください。
> **補足**
> パブリックIPを解除した場合、外部からの接続に加えて、NAT Gateway等を経由しないインスタンスから外部への通信もできなくなります。
> 事前に利用状況のご確認をお願いいたします。
#### 対象インスタンス一覧
| アカウントID | リージョン | インスタンスID | Nameタグ |
| --- | --- | --- | --- |
| 123456789012 | ap-northeast-1 | i-0123456789abcdef0 | bastion-server |
| 123456789012 | ap-northeast-1 | i-0fedcba9876543210 | web-server-01 |
### 完了条件
- [ ] パブリックIPが不要なインスタンスについて、割り当てが解除され、検出結果が **`PASSED`** となっていること
- [ ] 業務要件上必要なインスタンスについて、検出結果が **`SUPPRESSED`** となっており、抑止理由がノートに記録されていること
## 参考情報
- **修復手順**
[【Security Hub修復手順】[EC2.9] Amazon EC2 インスタンスは、パブリック IPv4 アドレスを未設定にすることをお勧めします | DevelopersIO](https://dev.classmethod.jp/articles/securityhub-fsbp-remediation-ec2-9/)
ほぼそのまま登録できるレベルの文章が出力されました。
正直、最初に動かしたときは「もう自分で書かなくていいのでは」と思いました。
と言いたいところですが、いきなりこの品質が出てきたわけではありません。
最初の頃の出力は、丁寧ではあるもののどこか「AIっぽい」文章で、毎回あちこち手直ししていました。
そこからSKILL.mdにルールを追記し続けて、今の形に育てています。
SKILL.mdの工夫ポイント
SKILL.mdの全文は業務固有の記述が含まれるため割愛しますが、全体はこのような構成です。
# Security Hub 修復対応 課題起票スキル
## 入力として受け取る情報
## 出力ルール
### 文体・トーン
### 踏み込みの度合い（初回対応）
### 構成（必須セクション）
### 補足（業務影響）の書き方
### 対象一覧の書き方
### 参考情報の書き方
### 抑止（SUPPRESSED）方針の併記
### コントロール種別ごとの考慮
## テンプレート
このうち、特に効いているルールを抜粋して紹介します。
文体・トーンを細かく縛る
AIによって生成される文章は、丁寧ではありますがそのままだとどこか「AIが書いた感」が残ります。
過剰な言い回し、不安を煽る表現、同じお願いを本文と末尾で繰り返すなどがありました。
お客様にお出しする文章なので、こうした癖を出力ルールとして明文化し、潰していきました。
### 文体・トーン
- お客様との課題管理用のため、丁寧な「ですます調」で記述する
- 「目的」は体言止め（名詞止め）で記述し、「〜いたします」等の動詞では終わらせない
- 不安を過度に煽る表現は避け、事実ベースで簡潔に書く
- 「お聞かせください」のような対面的すぎる表現は避け、課題管理ツール上のテキストコミュニケーションに適した表現にする
- 同じ依頼・説明（影響確認のお願い等）を、実施内容の本文・補足・末尾コメントで重複させない。1か所に集約する
- 「存じます」のようなへりくだった表現は使わない
細かいルールが並んでいますが、どれも実際に出力されて直した痕跡です。
たとえば「存じます」を禁止しているのは、単純に自分が普段使わない言い回しで、課題に並ぶと自分の文章として馴染まないからです。こうした個人の言葉づかいの癖まで書いておけるのが、スキルの地味に便利なところでした。
ルール一覧がそのまま「文章がAIっぽく見える理由の一覧」になっていて、見返すとちょっと面白いです。
「修復」と「抑止」の2方針を併記させる
Security Hubの対応では、検知＝即修復ではなく、EC2.9のパブリックIPのように「業務要件上必要」なケースがあります。
その場合は設定を直すのではなく、検出結果のステータスを SUPPRESSED に変更して、「確認のうえ受容した検知」として扱う、抑止という運用が一般的です。
こちらで勝手に修復方針を決め打ちせず、お客様が判断できる形で出すようにルール化しました。
- **方針A（修復対応）**：設定を是正し、コントロールを **`PASSED`** にする
- **方針B（抑止対応）**：要件上必要な場合、Security Hubの検出結果の ワークフローステータスを **`SUPPRESSED`（抑止済み）** にする
- 完了条件は方針A・Bの両ケースを記載する
- 最終判断は顧客に委ねる旨を明記する
初回起票では踏み込みすぎない
AIは「踏み台サーバはSession Managerへの切替をお勧めします」のような提案まで書きがちです。
提案自体は正しくても、利用状況をヒアリングできていない初回の起票時では的外れになりかねません。
そういった先走った文章が出てきたので、このルールを足しました。
### 踏み込みの度合い（初回対応）
- 顧客の利用状況をヒアリングできていない初回の起票では、踏み込んだ運用提案は前面に出さない
- まずは「利用状況・必要性の確認」と「対応方針の判断のお願い」に留める
対象一覧のテーブルはリソース種別ごとに変える
コントロールによって対象が「アカウント・リージョン」「インスタンス」「バケット」などと異なるため、種別に応じて見出しと列を変えるよう指示しています。あわせて、識別性のためにNameタグ列を必須にしました。
また、マネコンの情報のコピペだと行の順序がバラバラになりがちなので、「行はNameタグでグルーピング／ソートして並べる」というルールも入れています。
### 対象一覧の書き方
対象はコントロールの性質によって異なるため、種別に応じて見出しとテーブルの列を変える。
- アカウント／リージョン単位の設定（SSM、Config等）：見出し「対象アカウント・リージョン一覧」、列 アカウントID | リージョン
- EC2インスタンス：見出し「対象インスタンス一覧」、列 アカウントID | リージョン | インスタンスID | Nameタグ
- セキュリティグループ：見出し「対象セキュリティグループ一覧」、列 アカウントID | リージョン | セキュリティグループID | Nameタグ
- S3バケット：見出し「対象バケット一覧」、列 アカウントID | リージョン | バケット名
- IAMユーザー／ロール：見出し「対象IAMリソース一覧」、列 アカウントID | リソース名（ARN）
上記は例であり、入力されたリソース情報に応じて適切な見出し・列を判断して構成する。
並び順・列の補足：
- インスタンス等は **Nameタグ列を含める**。リソースの識別性を高めるため。
- 行はNameタグでグルーピング／ソートして見やすく並べる（IDの羅列順のまま貼らない）。
入力が足りなければ生成前に聞き返す
SKILL.mdには次のルールも入れています。
入力に不足がある場合は、生成前に不足項目をユーザーに確認する。
特に「検知理由」「業務影響」「修復手順」が不明な場合は、コントロールの内容から一般的な情報を補完しつつ、
推測部分は明示してユーザーに確認を促す。
お客様にお出しする文章では、推測を事実のように書かせないことが何より重要です。
推測部分を明示させるルールは早い段階で入れました。
スキル自体もClaude Codeに書かせて、レビューで育てる
冒頭に書いたとおり、このSKILL.mdは私がゼロから書いたものではありません。Claude Codeに「Security Hubの起票文を作るスキルを作って」と依頼して作らせました。
最初はちゃんと作成されるのか半信半疑でしたが、フォルダ構成からテンプレートまで一通り揃ったものが数分で出てきました。
その後の運用は単純で、
- スキルで起票文を生成する
- 気になる箇所を手動で直す or 指摘する
- 「今の指摘を
SKILL.mdのルールに反映して」と依頼する
の繰り返しです。
「目的は体言止め」「依頼文の重複禁止」といった文体まわりのルールはすべてこのループで追記されたもので、回を重ねるごとに手直しが減っていくのが体感できました。
毎回プロンプトを工夫するのではなく、指摘がスキルに蓄積されていく。これが一番気に入っているところです。
自分の「文章のこだわり」が言語化されてファイルに残っていくのは、地味に嬉しいポイントです。
注意点
スキルが代わりにやってくれるのは「文章化」の部分だけです。使用するにあたって、次の2点は守るようにしています。
- 生成された起票文は、必ず人がレビューしてから起票する
コントロールIDやタイトル、対象一覧が入力と一致しているか、参考リンクが実在するかを毎回確認しています。
技術的な判断と起票内容への責任は、あくまで人間側にあります。 - お客様の情報は、生成AIの利用ポリシーの範囲で扱う
アカウントIDやリソース名はお客様の構成情報です。
所属組織のルールや契約上のデータ取り扱い条件を確認した上でご利用ください。
まとめ
- 定型的だが「毎回ちょっとずつ違う」文書作成はスキル化と相性が良い
- 文体・トーンのような暗黙知も、明文化してルールに落とせば出力品質が安定する
- スキル自体もClaude Codeに書かせて、レビューのたびにルールを追記する運用が楽
「毎回似たような文章を書いてるな」という業務に心当たりのある方は、ぜひスキル化を試してみてください。
最初の雛形はClaude Codeに作ってもらえばいいので、思ったより簡単に始められます。
この記事がどなたかの参考になれば幸いです。
以上、クラウド事業本部 コンサルティング部の林でした！
