kotonoha 0.1.2 → 0.1.4

package/skills/tech-writer/assets/templates/requirements-definition.md

@@ -0,0 +1,170 @@
+# <システム・プロジェクト名> 要件定義書
+
+<誰のどの課題を解決し、どの業務成果を実現するシステムかを3文以内で要約する。>
+
+- 文書版: <例: 1.0>
+- 作成日: <YYYY-MM-DD>
+- 最終更新日: <YYYY-MM-DD>
+- 作成者: <氏名・チーム>
+- 承認者: <氏名・会議体>
+- ステータス: Draft / In Review / Approved
+- 対象リリース: <バージョン・時期>
+
+## この要件定義で合意する事項
+
+- 対象範囲: <対象となる業務・利用者・システム>
+- 期待する成果: <測定可能な業務成果>
+- 承認を求める事項: <スコープ、優先順位、予算、納期など>
+
+## 背景と解決する課題
+
+### 現状
+
+<現行業務や既存システムの状態を、数値や観測事実を用いて記載する。>
+
+### 解決する課題
+
+| 課題ID | 課題 | 影響を受ける利用者・業務 | 現状値 | 解決後の目標値 |
+|---|---|---|---:|---:|
+| ISS-001 | <課題> | <対象> | <値> | <値> |
+
+## 目的と成功指標
+
+| 目的ID | 目的 | 成功指標 | 現状値 | 目標値 | 測定方法 | 判定時期 |
+|---|---|---|---:|---:|---|---|
+| OBJ-001 | <目的> | <KPI・SLO> | <値> | <値> | <方法> | <時期> |
+
+## 対象範囲と対象外
+
+### 対象範囲
+
+- <対象業務>
+- <対象組織・利用者>
+- <対象システム・データ>
+
+### 対象外
+
+- <今回扱わない業務・機能>
+- <将来フェーズへ送る事項>
+
+## ステークホルダーと利用者
+
+| 区分 | 役割・利用者像 | 関心事 | 責任・権限 |
+|---|---|---|---|
+| <区分> | <役割> | <期待・懸念> | <承認・利用・運用など> |
+
+## 前提条件と制約
+
+### 前提条件
+
+- <成立を前提とする業務・技術・契約条件>
+
+### 制約
+
+| 制約ID | 分類 | 内容 | 要件・設計への影響 |
+|---|---|---|---|
+| CON-001 | 予算 / 納期 / 技術 / 法令 | <制約> | <影響> |
+
+## 業務要件
+
+### 対象業務の流れ
+
+```mermaid
+flowchart LR
+    A[<開始条件>] --> B[<利用者の業務>]
+    B --> C[<システムによる処理>]
+    C --> D[<業務成果>]
+```
+
+### 業務ルール
+
+| ルールID | 業務ルール | 適用条件 | 例外 | 根拠・所有者 |
+|---|---|---|---|---|
+| BR-001 | <ルール> | <条件> | <例外> | <規程・責任者> |
+
+## 機能要件
+
+優先度は Must / Should / Could / Won't を使用し、各要件は単独で検証できる粒度にする。
+
+| 要件ID | 機能要件 | 利用者 | 事前条件 | 入力 | 処理・振る舞い | 出力・事後条件 | 優先度 | 受入条件 |
+|---|---|---|---|---|---|---|---|---|
+| FR-001 | <実現する能力> | <利用者> | <条件> | <入力> | <振る舞い> | <結果> | Must | <観測可能な合格条件> |
+
+## 非機能要件
+
+「高速」「安全」などの抽象語だけで終わらせず、測定条件と合格値を記載する。
+
+| 要件ID | 分類 | 要件 | 測定条件 | 目標値 | 受入方法 | 優先度 |
+|---|---|---|---|---:|---|---|
+| NFR-001 | 性能 | <要件> | <負荷・データ量・時間帯> | <応答時間・スループット> | <試験方法> | Must |
+| NFR-002 | 可用性 | <要件> | <対象時間帯・除外条件> | <稼働率・RTO・RPO> | <確認方法> | Must |
+| NFR-003 | セキュリティ | <要件> | <脅威・データ区分> | <準拠基準・制御> | <監査・試験方法> | Must |
+
+対象となる分類:
+
+- 性能・拡張性
+- 可用性・信頼性・災害復旧
+- セキュリティ・プライバシー・監査
+- 保守性・運用性・監視
+- アクセシビリティ・ユーザビリティ
+- 互換性・移植性
+
+## データ要件
+
+| データID | データ | 所有者 | 取得元 | 用途 | 機密区分 | 保持期間 | 品質条件 | 削除方法 |
+|---|---|---|---|---|---|---|---|---|
+| DATA-001 | <データ> | <責任者> | <取得元> | <用途> | <区分> | <期間> | <完全性・正確性> | <方法> |
+
+## 外部インターフェース要件
+
+| IF-ID | 接続先 | 目的 | データ・操作 | 方式 | 認証・認可 | 頻度・量 | 障害時の扱い |
+|---|---|---|---|---|---|---|---|
+| IF-001 | <システム・利用者> | <目的> | <内容> | API / File / UI | <方式> | <頻度・件数> | <再試行・代替手段> |
+
+## 移行と導入の要件
+
+- 移行対象: <データ・利用者・業務>
+- 移行元と移行先: <システム・形式>
+- 移行品質条件: <件数一致、欠損率、照合方法>
+- 切替可能時間: <停止許容時間・実施時間帯>
+- 並行稼働: <有無・期間・終了条件>
+- 教育・周知: <対象者・方法・完了条件>
+- ロールバック条件: <中止を判断する指標>
+
+## 運用・保守要件
+
+| 項目 | 要件 | 担当 | サービス時間・期限 | エスカレーション |
+|---|---|---|---|---|
+| 監視 | <監視対象・通知条件> | <担当> | <時間帯> | <連絡経路> |
+| 問い合わせ | <受付・対応範囲> | <担当> | <SLA> | <連絡経路> |
+| 変更管理 | <申請・承認・リリース手順> | <担当> | <期限> | <連絡経路> |
+
+## 受入条件
+
+| 受入ID | 対応要件ID | 検証内容 | 前提・テストデータ | 合格基準 | 証跡 | 判定者 |
+|---|---|---|---|---|---|---|
+| AC-001 | FR-001 | <検証内容> | <条件> | <合格基準> | <ログ・画面・報告書> | <役割> |
+
+## 要件トレーサビリティ
+
+| 目的ID | 課題ID | 要件ID | 受入ID | 設計・実装先 | ステータス |
+|---|---|---|---|---|---|
+| OBJ-001 | ISS-001 | FR-001 | AC-001 | <設計書の節・Issue・PR> | Draft |
+
+## リスクと未解決事項
+
+| ID | 区分 | 内容 | 影響 | 対応・決定期限 | 所有者 | ステータス |
+|---|---|---|---|---|---|---|
+| RSK-001 | リスク / 未解決事項 | <内容> | <影響> | <対応・期限> | <担当> | Open |
+
+## 承認記録
+
+| 版 | 承認日 | 承認者 | 判断 | 条件・コメント |
+|---|---|---|---|---|
+| <版> | <YYYY-MM-DD> | <氏名・会議体> | Approved / Rejected / Deferred | <条件> |
+
+## 変更履歴
+
+| 版 | 日付 | 変更内容 | 変更理由 | 作成者 |
+|---|---|---|---|---|
+| 0.1 | <YYYY-MM-DD> | 初版 | <理由> | <氏名> |

package/skills/tech-writer/assets/templates/rfi.md

@@ -0,0 +1,113 @@
+# 情報提供依頼書（RFI）: <対象製品・サービス>
+
+<本RFIで把握したい市場、製品、実現可能性を2〜3文で記載する。>
+
+- 発行者: <組織名・部署名>
+- 発行日: <YYYY-MM-DD>
+- 回答期限: 「今後の予定」のRFI回答期限を参照
+- 問い合わせ先: <氏名・メールアドレス>
+- 機密区分: <公開・限定公開・機密>
+
+日付に不一致がある場合は「今後の予定」を正とする。
+
+## 情報提供を依頼する背景と目的
+
+<現在の状況、課題、情報収集の目的を記載する。RFIは調達先の決定ではなく、要件整理と市場調査に使うことを明示する。>
+
+## 現在の環境と前提条件
+
+- 利用者数・拠点数: <規模>
+- 現行システム: <製品・バージョン・構成>
+- 主要なデータ: <種類・容量・機密性>
+- 連携対象: <システム・API・プロトコル>
+- 制約: <予算・時期・法令・社内標準>
+
+詳細な製品バージョン、ネットワーク構成、脆弱性につながる情報は、
+NDA締結後に共有する別紙へ分離する。
+
+## 提供を依頼する情報
+
+各項目は概要レベルで回答する。詳細設計、確定見積もり、提案書相当の
+作業は求めず、回答を採点または順位付けしない。
+
+### 企業・組織情報
+
+- 会社概要と対象分野での事業実績
+- 類似規模・業界での導入実績
+- 製品開発、販売、保守の体制
+
+### 製品・サービスの概要
+
+- 製品構成と主要機能
+- 提供形態: SaaS / PaaS / オンプレミス / その他
+- 対応地域、言語、サービス提供時間
+- 製品ロードマップとサポート終了方針
+
+### 確認したい機能・能力の対応状況
+
+| ID | 確認事項 | 対応状況 | 提供方法・制約 | 補足資料 |
+|---|---|---|---|---|
+| RFI-001 | <確認したい機能・能力> | 標準 / オプション / ロードマップ対応予定 / 個別開発 / 非対応 | <説明> | <資料名・URL> |
+
+### アーキテクチャと連携
+
+- 論理・物理アーキテクチャ
+- API、イベント、ファイル連携の方式
+- 可用性、拡張性、性能上限
+- バックアップ、災害復旧、データ移行
+
+### セキュリティとコンプライアンス
+
+- 認証、認可、シングルサインオン
+- 暗号化、鍵管理、データ保管場所
+- 監査ログ、脆弱性管理、インシデント対応
+- 取得済み認証と準拠する法令・基準
+- サブプロセッサーと第三者提供の管理
+
+### 導入・運用・サポート
+
+- 標準的な導入期間と進め方
+- 顧客側に必要な体制と作業
+- 監視、障害対応、SLA
+- 教育、ドキュメント、問い合わせ窓口
+
+### 概算費用
+
+正式見積もりではなく、比較可能な前提条件と価格体系を提示する。
+
+| 費用区分 | 課金単位 | 概算 | 前提条件 |
+|---|---|---:|---|
+| 初期費用 | <単位> | <金額・範囲> | <条件> |
+| 継続費用 | <月額・年額> | <金額・範囲> | <条件> |
+
+## 回答方法
+
+1. 本書の章立てとIDを維持して回答する。
+2. 回答できない項目は「回答不可」と理由を記載する。
+3. 前提条件、制約、追加費用がある項目は同じ欄に明記する。
+4. 回答書と補足資料を<提出方法>で「今後の予定」の期限までに提出する。
+
+## 今後の予定
+
+| イベント | 日付 |
+|---|---|
+| RFI発行 | <YYYY-MM-DD> |
+| 質問受付期限 | <YYYY-MM-DD> |
+| 質問への回答 | <YYYY-MM-DD> |
+| RFI回答期限 | <YYYY-MM-DD> |
+| 次段階の案内 | <YYYY-MM-DD> |
+
+## 取り扱い条件
+
+- 本RFIは契約、発注、または将来のRFP発行を約束するものではない。
+- 回答は採点・順位付けせず、要件整理と市場調査にのみ利用する。
+- 回答に要する費用は回答者の負担とする。
+- 提供された情報は<利用範囲・秘密保持条件>に従って取り扱う。
+- 発行者は必要に応じて内容や予定を変更または中止できる。
+
+## 回答前チェックリスト
+
+- [ ] 全項目に回答または回答不可の理由を記載した
+- [ ] 制約、前提条件、追加費用を明記した
+- [ ] 概算費用の課金単位と有効期限を記載した
+- [ ] 補足資料と問い合わせ先を記載した

package/skills/tech-writer/assets/templates/rfp.md

@@ -0,0 +1,180 @@
+# 提案依頼書（RFP）: <調達対象・プロジェクト名>
+
+<調達する製品・サービス、達成したい成果、提案者に求める回答を3文以内で要約する。>
+
+- 発行者: <組織名・部署名>
+- 発行日: <YYYY-MM-DD>
+- 提案書提出期限: 「選定予定」を参照
+- 契約予定時期: 「選定予定」を参照
+- 問い合わせ先: <氏名・メールアドレス>
+- 機密区分: <公開・限定公開・機密>
+
+日付に不一致がある場合は「選定予定」を正とする。
+
+## プロジェクトの背景と目的
+
+<現在の業務・システム、解決する課題、調達後に実現したい状態を記載する。>
+
+## 調達範囲と対象外
+
+### 調達範囲
+
+- <製品・サービス・作業>
+- <導入、移行、教育、保守などの役務>
+
+### 対象外
+
+- <提案または見積もりに含めない事項>
+
+## 現在の環境と前提条件
+
+- 利用者数・拠点数: <規模>
+- 現行システム: <製品・バージョン・構成>
+- データ: <種類・容量・増加率・機密性>
+- 連携対象: <システム・API・プロトコル>
+- 必須の期限: <稼働開始日・移行期限>
+- 適用基準: <法令・社内規程・技術標準>
+
+詳細な製品バージョン、ネットワーク構成、脆弱性につながる情報は、
+NDA締結済みの応札者にのみ共有する別紙へ分離する。
+
+## 要求事項
+
+各要求事項について、対応可否、実現方法、前提条件、追加費用を回答する。
+
+| ID | 優先度 | 要求事項 | 受け入れ条件 | 対応可否 | 実現方法・制約 | 追加費用 | 根拠資料 |
+|---|---|---|---|---|---|---:|---|
+| FR-001 | Must / Should / Could | <機能要求> | <確認可能な条件> | 標準 / オプション / 個別開発 / 非対応 | <説明> | <金額> | <資料名・URL> |
+
+### 非機能要求
+
+| ID | 分類 | 要求値 | 測定・確認方法 | 対応可否 | 実現方法・制約 | 追加費用 | 根拠資料 |
+|---|---|---|---|---|---|---:|---|
+| NFR-001 | 性能 | <応答時間・処理件数> | <試験方法> | 標準 / オプション / 個別開発 / 非対応 | <説明> | <金額> | <資料名・URL> |
+| NFR-002 | 可用性 | <稼働率・停止許容時間> | <SLA・実績確認> | 標準 / オプション / 個別開発 / 非対応 | <説明> | <金額> | <資料名・URL> |
+| NFR-003 | 拡張性 | <将来規模> | <構成・試験方法> | 標準 / オプション / 個別開発 / 非対応 | <説明> | <金額> | <資料名・URL> |
+
+### セキュリティとコンプライアンス
+
+- 認証、認可、特権アクセス管理
+- 保存時・通信時の暗号化と鍵管理
+- データ保管場所、保持期間、削除方法
+- 監査ログ、脆弱性管理、インシデント通知
+- 準拠する法令、規格、社内ポリシー
+- サブプロセッサーとサプライチェーン管理
+
+### 移行と連携
+
+- データ移行の対象、方式、検証、切り戻し
+- API、イベント、ファイルによる外部連携
+- 現行システムとの並行稼働と停止条件
+
+### 運用とサポート
+
+- 監視、バックアップ、災害復旧
+- サービス時間、SLA、障害時の連絡体制
+- 問い合わせ、保守、アップデート方針
+- 管理者・利用者向け教育とドキュメント
+
+## 応札資格
+
+- 財務状況と事業継続性: <提出書類・基準>
+- 必要な認証・許認可: <認証名>
+- 類似案件の実績: <件数・期間・規模>
+- 利益相反・関係会社: <開示条件>
+- 再委託先・サブプロセッサー: <開示・承認条件>
+
+## 成果物・検収・支払条件
+
+| 成果物 | 内容 | 提出時期 | 受け入れ条件 | 支払条件 |
+|---|---|---|---|---|
+| <成果物名> | <含める内容> | <時期> | <レビュー・試験条件> | <検収後の支払割合・期限> |
+
+## 提案書に記載する内容
+
+1. エグゼクティブサマリーと提案の特徴
+2. 要求事項IDごとの対応可否、実現方法、制約
+3. アーキテクチャ、セキュリティ、運用設計
+4. 導入・移行計画、体制、役割分担
+5. プロジェクト管理、品質管理、リスク管理
+6. 類似案件の実績と担当者の経験
+7. 費用明細、課金単位、前提条件、有効期限
+8. 契約条件への差異と代替案
+
+## プロジェクト予定
+
+| マイルストーン | 予定日 |
+|---|---|
+| プロジェクト開始 | <YYYY-MM-DD> |
+| 設計完了 | <YYYY-MM-DD> |
+| 移行・受け入れ試験 | <YYYY-MM-DD> |
+| 本番稼働 | <YYYY-MM-DD> |
+
+提案者は、上記日程を実現できない場合、根拠を添えて代替日程を提示する。
+
+## 価格提案
+
+- TCO評価期間: <例: 契約開始から5年間>
+
+- 通貨・税区分: <通貨・税込/税別>
+- 見積有効期限: <YYYY-MM-DD>
+- 価格改定条件: <条件>
+- オプション費用: <対象と価格>
+
+| 費用区分 | 項目 | 単価 | 数量 | 初期費用 | 年間継続費用 | 評価期間TCO | 前提条件 |
+|---|---|---:|---:|---:|---:|---:|---|
+| <区分> | <項目> | <単価> | <数量> | <金額> | <年額> | <金額> | <条件> |
+| **合計** |  |  |  | **<合計>** | **<合計>** | **<初期費用＋評価期間の継続費用>** |  |
+
+## 評価基準
+
+| 評価項目 | 配点 | 主な評価内容 |
+|---|---:|---|
+| 要求適合性 | <点> | Must要件、実現方法、制約 |
+| 技術・セキュリティ | <点> | 構成、性能、可用性、安全性 |
+| 導入・運用 | <点> | 計画、体制、移行、サポート |
+| 実績・体制 | <点> | 類似実績、担当者、継続性 |
+| 価格 | <点> | 総保有コスト、透明性、妥当性 |
+
+- 合計は100点とする。
+- Must要件が1件でも非対応の場合は失格とする。例外を認める場合は、
+  対象IDと承認者を選定記録へ残す。
+- 価格点は `<最低評価期間TCO ÷ 提案評価期間TCO × 価格配点>` で算出する。
+- 最低通過点: 総合<点>点以上、かつ<カテゴリ名><点>点以上。
+
+## 質問と提案書の提出方法
+
+1. 質問は<質問方法>で「選定予定」の質問受付期限までに提出する。
+2. 回答は<公開方法>で「選定予定」の質問回答日までに共有する。
+3. 提案書は<ファイル形式・ページ上限>で作成する。
+4. 提案書と価格表を<提出方法>で「選定予定」の期限までに提出する。
+
+## 選定予定
+
+| イベント | 日付 |
+|---|---|
+| RFP発行 | <YYYY-MM-DD> |
+| 質問受付期限 | <YYYY-MM-DD> |
+| 質問回答日 | <YYYY-MM-DD> |
+| 提案書提出期限 | <YYYY-MM-DD> |
+| プレゼンテーション・デモ | <YYYY-MM-DD> |
+| 選定結果通知 | <YYYY-MM-DD> |
+| 契約締結 | <YYYY-MM-DD> |
+
+## 契約・提案条件
+
+- 発行者は、提案の全部または一部を採用しない場合がある。
+- 提案作成と提出に要する費用は提案者の負担とする。
+- 提案内容と価格は「価格提案」の見積有効期限まで有効とし、
+  契約交渉の基礎資料として扱う。
+- 知的財産権、秘密保持、再委託、責任分界は<契約条件・別紙>に従う。
+- 発行者は必要に応じてRFPの変更、中止、追加説明を行える。
+
+## 提出前チェックリスト
+
+- [ ] 全要求事項IDに対応可否と実現方法を回答した
+- [ ] 応札資格、利益相反、再委託先を開示した
+- [ ] 制約、前提条件、追加費用を明記した
+- [ ] 導入・移行・運用体制、検収、支払条件を記載した
+- [ ] 価格の内訳、課金単位、有効期限を記載した
+- [ ] 契約条件との差異と代替案を記載した

package/skills/tech-writer/assets/templates/security-design.md

@@ -0,0 +1,167 @@
+# <システム名> セキュリティ設計書・脅威モデル
+
+<保護する資産、主要な脅威、採用するセキュリティ制御、受容する残余リスクを3文以内で要約する。>
+
+- 文書版: <例: 1.0>
+- 作成日: <YYYY-MM-DD>
+- 最終更新日: <YYYY-MM-DD>
+- 作成者: <氏名・チーム>
+- セキュリティレビュー担当: <氏名・チーム>
+- リスク受容者: <氏名・役職>
+- ステータス: Draft / In Review / Approved
+- 対象リリース: <バージョン・時期>
+- 関連要件・設計: <文書名・版・URL>
+
+## このセキュリティ設計で合意する事項
+
+- 対象範囲と信頼境界: <対象システム・データ・利用者>
+- 主要な脅威と制御: <要約>
+- 残余リスク: <受容・追加対策が必要な事項>
+- 承認を求める事項: <設計、例外、リスク受容>
+
+## 対象範囲と対象外
+
+### 対象範囲
+
+- <アプリケーション、基盤、データ、外部接続、運用>
+
+### 対象外
+
+- <別チーム・別文書が管理する範囲>
+
+## セキュリティ要件と準拠基準
+
+| 要件ID | 要件・基準 | 適用範囲 | 設計上の対応 | 検証方法 |
+|---|---|---|---|---|
+| SEC-REQ-001 | <社内規程・法令・NFR> | <対象> | <制御> | <試験・監査> |
+
+## 資産とデータ分類
+
+| 資産ID | 資産・データ | 所有者 | 機密性 | 完全性 | 可用性 | 保存場所 | 保持・削除 |
+|---|---|---|---|---|---|---|---|
+| AST-001 | <資産> | <所有者> | High / Medium / Low | High / Medium / Low | High / Medium / Low | <場所> | <期間・方法> |
+
+## アーキテクチャと信頼境界
+
+```mermaid
+flowchart LR
+    U[<利用者>] -->|<認証済み通信>| E[<公開境界>]
+    subgraph TrustZoneA[<信頼ゾーンA>]
+        E --> A[<アプリケーション>]
+        A --> D[(<データストア>)]
+    end
+    A --> X[<外部サービス>]
+```
+
+| 境界ID | 境界 | 越境するデータ | 通信方式 | 認証・認可 | 保護制御 |
+|---|---|---|---|---|---|
+| TB-001 | <境界> | <データ> | <TLS・Private Linkなど> | <方式> | <検証・制限> |
+
+## ID・認証・認可
+
+| 主体 | ID基盤 | 認証方式 | 認可モデル | 最小権限 | 有効期限・棚卸し |
+|---|---|---|---|---|---|
+| 利用者 / サービス / 管理者 | <基盤> | <MFA・証明書など> | RBAC / ABAC | <制御> | <期限・頻度> |
+
+- 特権アクセス: <申請、承認、Just-In-Time、記録>
+- サービス間認証: <Managed Identity、証明書など>
+- セッション管理: <有効期限、失効、Cookie属性>
+- アカウント回復: <本人確認、監査、通知>
+
+## 脅威モデル
+
+脅威分類にはSTRIDEなどを使用し、資産・境界・データフローごとに分析する。
+
+| 脅威ID | 分類 | 対象資産・境界 | 攻撃シナリオ | 前提 | 影響 | 可能性 | リスク |
+|---|---|---|---|---|---|---|---|
+| THR-001 | Spoofing / Tampering / Repudiation / Information Disclosure / DoS / Elevation | AST-001 / TB-001 | <シナリオ> | <条件> | High / Medium / Low | High / Medium / Low | <評価> |
+
+## セキュリティ制御と脅威対応
+
+| 制御ID | 対応脅威ID | 予防・検知・対応 | 制御内容 | 所有者 | 実装箇所 | 検証方法 |
+|---|---|---|---|---|---|---|
+| CTRL-001 | THR-001 | Prevent / Detect / Respond | <制御> | <担当> | <構成・コード> | <試験・監査> |
+
+## データ保護
+
+- 転送時暗号化: <プロトコル、最小バージョン、証明書管理>
+- 保存時暗号化: <方式、鍵、適用対象>
+- フィールド暗号化・トークン化: <対象・方式>
+- データマスキング: <画面、ログ、非本番環境>
+- データ所在地: <リージョン・越境条件>
+- 保持と削除: <期間、論理・物理削除、証跡>
+
+## シークレット・鍵・証明書管理
+
+| 対象 | 保管場所 | 利用主体 | 配布方法 | ローテーション | 失効 | 監視 |
+|---|---|---|---|---|---|---|
+| <シークレット・鍵> | <Vault・HSM> | <主体> | <Managed Identityなど> | <頻度・自動化> | <手順> | <期限通知> |
+
+- ソースコード・イメージ・ログへの混入防止: <スキャン・マスキング>
+- 緊急ローテーション: <判断者・手順・所要時間>
+
+## 入力・出力・APIの保護
+
+| 対象 | 脅威 | 制御 | 制限値 | エラー時の扱い |
+|---|---|---|---|---|
+| 入力 | Injection / 不正形式 | <検証・エスケープ> | <サイズ・件数> | <拒否・記録> |
+| API | Abuse / Replay | <認可・レート制限・冪等性> | <値> | <応答・遮断> |
+| 出力 | 情報漏えい | <最小化・エンコード> | <条件> | <マスキング> |
+
+## ログ・監査・検知
+
+| イベント | 記録内容 | 記録しない情報 | 保存期間 | 検知ルール | 通知先 |
+|---|---|---|---|---|---|
+| 認証・権限変更・データ操作 | <主体、時刻、結果、相関ID> | <パスワード・秘密値> | <期間> | <異常条件> | <SOC・担当> |
+
+- ログ改ざん防止: <アクセス制御・WORMなど>
+- 時刻同期: <方式>
+- 相関・追跡: <Trace ID・User ID>
+- 検知ルールの試験: <頻度・方法>
+
+## 脆弱性とサプライチェーン管理
+
+- 依存関係スキャン: <ツール・頻度・修正期限>
+- SAST / DAST / IaCスキャン: <対象・実行時点>
+- コンテナ・成果物署名: <方式・検証>
+- SBOM: <生成・保存・提供方法>
+- パッチ管理: <重大度別期限・例外承認>
+- 外部サービス・OSS: <評価・ライセンス・終了時対応>
+
+## セキュリティ試験
+
+| 試験ID | 対応要件・脅威・制御 | 試験意図 | 想定環境 | 合格基準 | 必要な証跡種別 |
+|---|---|---|---|---|---|
+| SEC-TC-001 | SEC-REQ-001 / THR-001 / CTRL-001 | <認可・侵入・設定試験> | <環境条件> | <基準> | <ログ・報告書など> |
+
+## セキュリティインシデント対応
+
+- 検知と一次対応: <監視、隔離、連絡>
+- 証拠保全: <ログ、スナップショット、Chain of Custody>
+- 封じ込め・根絶・復旧: <責任者・手順>
+- 法務・規制・顧客通知: <条件・期限・承認者>
+- 事後レビュー: <期限・再発防止管理>
+
+## 残余リスクと例外
+
+| リスクID | 対応脅威 | 残余リスク | 受容理由・代替制御 | 有効期限 | 受容者 | 見直し条件 |
+|---|---|---|---|---|---|---|
+| SEC-RSK-001 | THR-001 | <残るリスク> | <理由・補完策> | <日付> | <役職・氏名> | <条件> |
+
+## セキュリティトレーサビリティ
+
+| 要件ID | 資産ID | 脅威ID | 制御ID | 試験ID | 実装・設定先 |
+|---|---|---|---|---|---|
+| SEC-REQ-001 | AST-001 | THR-001 | CTRL-001 | SEC-TC-001 | <コード・IaC・ポリシー> |
+
+## レビューと承認記録
+
+| 版 | 日付 | レビュー・承認者 | 判断 | 条件・残余リスク |
+|---|---|---|---|---|
+| <版> | <YYYY-MM-DD> | <氏名・会議体> | Approved / Rejected / Deferred | <条件> |
+
+## 変更履歴
+
+| 版 | 日付 | 変更内容 | 変更理由 | 作成者 |
+|---|---|---|---|---|
+| 0.1 | <YYYY-MM-DD> | 初版 | <理由> | <氏名> |