security-checksheet
Skill0 starsChanged 4 months agoMITView on GitHub
顧客から受領したセキュリティチェックシートに、自社のポリシー・過去回答・認証取得状況をもとに回答案を作成する。取引先審査、SaaS導入審査、情報セキュリティ監査の質問票への回答に使う。
In this repository8 other files it gives its agents.
- contract-reviewSkill
- expense-auditSkill
- invoice-extractSkill
- manual-writerSkill
- meeting-minutesSkill
- rfp-analysisSkill
- skill-builderSkill
- support-replySkill
The file
Files
セキュリティチェックシート回答
顧客や取引先から届く数十から数百問のチェックシートに、社内資料を根拠として回答案を埋める。人は「判断が必要な項目」と「事実確認が必要な項目」だけを見ればよい状態にする。
入力として受け取るもの
- 受領したチェックシート(Excel / スプレッドシート / Word / PDF)
- 自社の回答根拠となる資料。次のうち手元にあるものすべて
- 過去に提出した回答済みチェックシート
- 情報セキュリティポリシー、社内規程
- ISMS(ISO/IEC 27001)、Pマーク、SOC 2 などの認証・報告書
- システム構成図、データフロー図、委託先一覧
根拠資料が1つも渡されていない場合は、回答を作らずに何が必要かを伝える。推測で回答したチェックシートは、後から事実と異なることが判明したときに契約上の問題になる。
手順
- 設問を全件リスト化する。 設問番号、大分類、設問文、回答形式(はい / いいえ / 記述 / 選択)を表にする。件数をユーザーに伝えてから回答作業に入る。
- 根拠資料を読み込む。 過去回答がある場合は、設問文の類似度ではなく「聞かれている内容」で対応づける。表現が違っても同じことを聞いている設問は多い。
- 設問ごとに根拠を特定する。 どの資料の、どの章・条項が根拠かを必ず記録する。根拠が見つからない設問は空欄にし、
要確認に分類する。 - 回答を書く。 下記の分類と出力フォーマットに従う。
- 過去回答との矛盾を検査する。 同じ内容を過去に別の表現で回答している場合、内容が食い違っていないかを確認し、食い違いは指摘として出す。
- サマリを報告する。 全設問数、回答済み、要確認、未対応(「いいえ」回答)の件数を伝える。
回答の分類
各設問を必ずこの4つのいずれかに分類する。
| 分類 | 意味 | 扱い |
回答済 | 根拠資料から事実として回答できた | そのまま提出候補 |
要確認 | 根拠資料に記載がなく、事実を確認する必要がある | 確認先の部署・担当を併記する |
要判断 | 事実は確認できるが、どこまで開示するかの判断が必要 | 判断が必要な理由を書く |
未対応 | 事実として要件を満たしていない | 代替の管理策と対応予定を書く |
出力フォーマット
# セキュリティチェックシート回答案: <提出先> 様
- 作成日: YYYY-MM-DD
- 設問数: <全件> / 回答済 <n> / 要確認 <n> / 要判断 <n> / 未対応 <n>
- 使用した根拠資料: <ファイル名の一覧>
## 回答一覧
| 設問番号 | 設問 | 回答 | 分類 | 根拠 | 補足 |
|---|---|---|---|---|---|
| 3-1 | 委託先の管理体制を定めていますか | はい | 回答済 | 情報セキュリティポリシー 第8章 | 年1回の委託先評価を実施 |
| 3-2 | 委託先の再委託先まで把握していますか | | 要確認 | | 調達部門への確認が必要 |
## 要確認の項目
| 設問番号 | 確認する内容 | 確認先 |
|---|---|---|
## 未対応の項目
| 設問番号 | 要件 | 現状 | 代替の管理策 | 対応予定 |
|---|---|---|---|---|
## 過去回答との差異
| 設問番号 | 今回の回答 | 過去の回答(<提出先・時期>) | 差異の理由 |
|---|---|---|---|Excel での提出を求められた場合は、受領したシートの様式を保ったまま回答列だけを埋め、上記の要確認・未対応・差異の表は別シートに出力する。
守るべきルール
- 事実でない回答を書かない。 根拠資料に記載がない項目を「はい」にしない。これは最も重要なルールで、虚偽の回答は契約不適合や取引停止につながる。
- 「対応済み」と「対応予定」を区別する。 計画段階のものを実施済みとして回答しない。予定は必ず時期を併記する。
- エビデンス提出を求められた設問には、該当する文書名と章番号を書く。 「規程に定めています」だけでは差し戻される。
- 受領したシートの様式を変えない。 行の追加・削除、設問文の書き換えをしない。回答欄以外に手を入れると相手方の集計が壊れる。
- 「未対応」を隠さない。 満たしていない要件は、代替の管理策とあわせて正直に書く。隠した不備は監査で必ず発覚する。
- 開示範囲の判断はしない。 構成図の詳細や委託先名など、どこまで開示するかは
要判断に分類し、人が決める。
自社用にカスタマイズする
このスキルは、自社の回答資産を持たせるほど効果が上がる。次を references/ に置く。
references/answers.md— 過去に提出した回答の蓄積。設問の言い回しが違っても対応づけられるよう、聞かれている内容ごとに整理するreferences/policy.md— 情報セキュリティポリシーの章立てと要約references/certifications.md— 取得済み認証、認証範囲、有効期限、報告書の提出可否references/escalation.md— 分類ごとの確認先(インフラは情シス、委託先は調達、など)
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

