soc2-audit-prep
作成者 alirezarezvanisoc2-audit-prep は、SOC 2 Type II の準備状況をレビューするためのコンプライアンス確認 skill です。`/cs:soc2-audit-prep <scope>` で、観察期間に関する6つの踏み込んだ質問を実行します。フィールドワーク前に、スコープ、TSC の選択、抜けている統制サイクル、証跡の不足、インシデント、監査対応状況を事前に洗い出すために使えます。
この skill の評価は 68/100 で、軽量な SOC 2 Type II 準備状況確認プロンプトとしてディレクトリ掲載に適しています。ディレクトリ利用者は、いつ呼び出すべきか、どのような観点で圧力テストを行うのかを理解できます。ただし、テンプレート、参考資料、自動化を備えた包括的な監査準備パッケージではなく、チェックリスト型の skill として捉えるのが適切です。
- 起動しやすい設計です。frontmatter と本文で `/cs:soc2-audit-prep <scope>` という明確なコマンド形式と、Type II サイクルのどのタイミングで実行すべきかが示されています。
- エージェント活用の焦点が明確です。SOC 2 Type II の準備状況を、観察期間に関する6つの強制質問として整理しており、汎用的なコンプライアンス用プロンプトより構造化されています。
- 実務に関係する内容を扱っています。抜粋では、TSC のスコープ設定、観察期間中の一貫性、省略された統制サイクル、Type II 準備でよく確認されるポイントがカバーされています。
- サポートファイル、参考資料、スクリプト、テンプレート、インストール手順は含まれていないため、監査対応に使える準備キットではなく、単体の SKILL.md として利用する形です。
- リポジトリ上の情報には experimental/test を示す要素があり、実務で使える成果物の範囲も限られます。チームでは、完全な SOC 2 準備ワークフローではなく、プロンプト/チェックリスト補助として扱うべきです。
soc2-audit-prep skill の概要
soc2-audit-prep ができること
soc2-audit-prep は、SOC 2 Type II の準備状況を、観察期間に焦点を当てた 6 つの質問で厳しく点検するためのコンプライアンスレビュー skill です。/cs:soc2-audit-prep <scope> として呼び出す設計で、証跡収集の前、監査人のフィールドワーク前、スコープ変更前などに、構造化されたチャレンジセッションを行いたい場合に特に役立ちます。
一般的な「SOC 2 の準備を手伝って」というプロンプトとは異なり、この skill は Type II で例外につながりやすい論点にレビューを絞ります。たとえば、スコープの曖昧さ、Trust Services Criteria の判断漏れ、コントロール実施サイクルの抜け、弱い証跡、観察期間中の変更などです。
向いているユーザーと利用タイミング
主な対象は、SOC 2 Type II 監査に向けて準備している創業者、セキュリティ責任者、GRC 担当者、コンプライアンスコンサルタント、エンジニアリングマネージャーです。特に、観察期間の開始前、6 か月目のチェックポイント付近、10 か月目のフィールドテスト前、重大インシデント後、または Availability、Confidentiality、Processing Integrity、Privacy など新しい TSC カテゴリを追加するタイミングに適しています。
ポリシー作成支援ではなく、監査人のような突っ込みを受けたいときに、Compliance Review 用途で soc2-audit-prep を使うのが適しています。
この skill の違い
最大の特徴は、「答えを強制する質問」の構造です。この skill は、ゼロから完全なコンプライアンスプログラムを生成しようとはしません。代わりに、Type II の観察期間中に本当に問題になるギャップをユーザーに明らかにさせます。そのため、一般的なコントロール、ベンダー質問票、セキュリティポリシーを書く用途よりも、準備状況の検証に向いています。
導入時に確認すべきこと
リポジトリ内のパスは compliance-os/skills/soc2-audit-prep で、利用できるソースは主に SKILL.md に集約されています。バンドルされたスクリプト、リファレンスパック、補助リソースはないため、価値の中心はプロンプトロジックそのものです。チーム側で、コントロールマトリクス、証跡インベントリ、スコープ記述、監査タイムライン、監査人からの依頼事項を用意して使う前提です。
soc2-audit-prep skill の使い方
soc2-audit-prep のインストールとソース確認
GitHub の skill リポジトリからインストールします。
npx skills add alirezarezvani/claude-skills --skill soc2-audit-prep
その後、まず次のソースファイルを確認します。
compliance-os/skills/soc2-audit-prep/SKILL.md
この skill には付随する rules/、resources/、references/、scripts/ フォルダがないため、自動化された SOC 2 証跡スキャナーだとは考えないでください。自社の監査資料を持ち込み、AI アシスタント内で実行する構造化レビュー用プロンプトとして扱うのが適切です。
出力の質を大きく左右する入力情報
弱い呼び出し例は次のようなものです。
/cs:soc2-audit-prep our SaaS app
より良い呼び出しでは、モデルが有効に突っ込めるだけの監査コンテキストを与えます。
/cs:soc2-audit-prep B2B SaaS platform pursuing SOC 2 Type II, Security and Availability in scope, 12-month observation period starting Feb 1, quarterly access reviews, monthly vulnerability scans, AWS production environment, Stripe and customer support tools in scope, recent SSO rollout in month 4, auditor fieldwork expected in month 10
可能であれば、次の情報を含めてください。
- システム境界と除外対象システム
- スコープに含まれる TSC カテゴリ
- 観察期間の日付
- コントロール頻度: monthly、quarterly、annual、continuous
- 証跡の担当者と保管場所
- 既知のインシデント、移行、ツール変更
- 監査人の懸念事項や顧客へのコミットメント
実務での soc2-audit-prep 活用フロー
最初から整ったレポートを求めるのではなく、準備状況への問い詰めを依頼します。まず skill に弱点を洗い出させ、その後で検出事項をアクションリストに変換させます。
実務的な流れは次のとおりです。
- 監査タイムラインと TSC スコープを含めて
/cs:soc2-audit-prep <scope>を実行する。 - 6 つの質問に対して、実際のコントロールと証跡の詳細で回答する。
- ギャップを、例外になりそうなもの、監査人から追加確認されそうなもの、文書整理で済むものに分類させる。
- 出力を担当者、期限、証跡リクエストに落とし込む。
- 是正後、またはフィールドワーク前に skill を再実行する。
この順序にすると、Type II 監査が失敗する実態に近いレビューになります。問題は「ポリシーが存在するか」ではなく、観察期間を通じて一貫して運用されていたかどうかだからです。
より鋭いレビューにするプロンプトパターン
より踏み込んだ結果が必要な場合は、次のパターンを使います。
Act as a SOC 2 Type II readiness reviewer using soc2-audit-prep. Challenge our scope, TSC category choices, control frequency, evidence completeness, skipped cycles, incidents, and changes during the observation period. Do not write generic policy text. Ask follow-up questions where evidence is missing, and produce a prioritized remediation list.
このように指定すると、アシスタントが一般的な SOC 2 解説に流れるのを防ぎ、監査で説明可能かどうかに焦点を保てます。
soc2-audit-prep skill FAQ
soc2-audit-prep は SOC 2 プログラム全体を作る skill ですか?
いいえ。soc2-audit-prep は準備状況とコンプライアンスをレビューする skill であり、完全なコントロールライブラリ、ポリシー一式、証跡自動化ツール、監査人の代替ではありません。既存の SOC 2 計画や進行中の Type II サイクルに対して、厳しく確認を入れる用途に最も向いています。
通常の SOC 2 プロンプトより何が優れていますか?
通常のプロンプトでは、広めのチェックリストが出てくることがあります。soc2-audit-prep skill はより対象が絞られており、観察期間、スコープ、TSC カテゴリ、実施されなかったコントロールサイクルを中心に扱うため、Type II の準備状況確認により実用的です。この構造により、監査例外につながる問題を早めに見つけやすくなります。
初心者でも使えますか?
はい。ただし、初心者でも基本的な SOC 2 のコンテキストは用意するべきです。どのシステムが監査対象なのか、どの Trust Services Criteria がスコープ内なのか、観察期間がいつ始まりいつ終わるのか、どのコントロールが月次または四半期で運用されるのか、といった情報です。これらがないと、出力は高レベルな内容にとどまります。
この skill を使うべきでない場面は?
AICPA 基準の解釈、法的助言、最終的な監査結論、証跡の認証について、唯一の情報源として使うべきではありません。また、システム境界をまだ定義していない段階で使うのも避けたほうがよいです。スコープの曖昧さがレビュー全体を支配してしまうためです。
soc2-audit-prep skill を改善する方法
実際の監査成果物で soc2-audit-prep を改善する
soc2-audit-prep の結果を最も早く改善する方法は、願望ではなく実物に近い情報を渡すことです。コントロールマトリクス、システム記述、TSC スコープ、証跡トラッカー、インシデントログ、アクセスレビューのカレンダー、脆弱性スキャンのスケジュール、主要な変更履歴を貼り付けるか要約してください。
より良い入力例:
- “Quarterly access review for Q2 was completed 19 days late”
- “We changed ticketing systems in month 5 and lost historical approval links”
- “Availability is in scope because contracts promise 99.9% uptime”
こうした詳細があると、skill は SOC 2 の基礎を繰り返すのではなく、Type II のリスクを特定できます。
よくある失敗パターンに注意する
最もよくある失敗は、準備を「文書がそろっているか」と捉えてしまい、「運用有効性」を見落とすことです。Type II では、初日にポリシーが存在していても、四半期コントロールの抜け、証跡不足、文書化されていない本番変更があれば救いにはなりません。
明示的に洗い出したいその他の失敗パターン:
- 期間の途中で追加された新製品や新地域
- スコープから漏れている委託先やサポートツール
- ポストモーテムや顧客連絡記録のないインシデント
- オーナーが不明確なコントロール
- 監査人がアクセスまたは検証できないシステムに保管された証跡
質問から是正へ反復する
初回実行後は、監査で使える言葉で是正計画を作らせます。
Convert the soc2-audit-prep findings into a remediation table with issue, audit risk, likely evidence needed, owner, deadline, and whether it affects the current observation period.
次に、2 回目の確認を行います。
Re-check only the high-risk items and tell me which are likely exceptions versus items that can be remediated before fieldwork.
これにより、この skill を一度きりのチェックリストではなく、監査準備の反復ループとして使えるようになります。
自社環境に合わせて skill を拡張する
チームにとって SOC 2 の重要度が高い場合は、この skill の横に自社用のローカルメモを追加することを検討してください。たとえば、コントロール ID、監査人の好み、証跡の命名規則、スコープ内システム、標準的なスクリーンショットやエクスポートなどです。上流の soc2-audit-prep skill は意図的にコンパクトに作られているため、レビューを具体的で説明可能なものにし、監査人から同じ質問を受ける前に役立てるには、ローカルコンテキストが重要です。
