kotonoha 0.1.2 → 0.1.4

package/skills/presentation-planner/references/handoff-contract.md

@@ -0,0 +1,49 @@
+# PPTX handoff contract
+
+Use this structure for
+`.presentation/<deck-slug>/pptx-handoff.md`.
+
+## Inputs
+
+- Brief: `<path>/presentation-brief.md`
+- Scenario: `<path>/presentation-scenario.md`
+- Slide outline: `<path>/slide-outline.md`
+- Design specification: `<path>/design-spec.yaml`
+- Source materials: `<paths>`
+
+## Output
+
+- PPTX path: `<path>/<filename>.pptx`
+- Aspect ratio: `<16:9 / 4:3 / custom>`
+- Expected slide count: `<count or range>`
+
+## Rendering requirements
+
+- Preserve slide order and assertion titles.
+- Preserve the approved scenario stages and audience reasoning journey.
+- Require every slide to map to at least one scenario stage; preserve
+  multi-stage mappings recorded with ` / ` in the outline.
+- Treat evidence and citation fields as content requirements.
+- Apply semantic design tokens from `design-spec.yaml`.
+- Add speaker notes where specified.
+- Add alt text or an equivalent description for informative visuals.
+- Do not invent quantitative claims or citations.
+
+## Required visual QA
+
+- Render every slide to an image or thumbnail.
+- Check clipping, overlap, off-canvas objects, font substitution, and
+  unreadable contrast.
+- Check charts for legible labels, units, legends, and source notes.
+- Check diagrams for readable flow direction and connector attachment.
+- Report every deviation from the outline or design specification.
+
+## Completion report
+
+Return:
+
+1. Output path and final slide count
+2. Visual QA result
+3. Missing or substituted assets/fonts
+4. Deviations from the scenario, outline, or design and their reasons
+5. Remaining manual-review items

package/skills/presentation-planner/references/responsibility-boundary.md

@@ -0,0 +1,32 @@
+# Responsibility boundary with the PPTX creation skill
+
+`presentation-planner` and the host's PPTX skill are complementary.
+
+| Concern | presentation-planner | PPTX creation skill |
+|---|---:|---:|
+| Audience, outcome, and decision | Owns | Consumes |
+| Scenario and audience reasoning journey | Owns | Preserves |
+| Storyline and slide sequence | Owns | Preserves |
+| Assertion titles and evidence mapping | Owns | Renders |
+| Design tokens and layout intent | Owns | Implements |
+| `.pptx` binary creation and editing | Never | Owns |
+| python-pptx/PptxGenJS/COM code | Never | Owns |
+| Theme/layout extraction from an existing PPTX | Requests and consumes summary | Owns |
+| Rendering and thumbnails | Never | Owns |
+| Overlap, clipping, and font checks | Defines acceptance criteria | Executes |
+| Speaker notes insertion | Specifies content | Implements |
+
+## Conflict rule
+
+If both skills could act, `presentation-planner` runs first and creates the
+handoff package. The PPTX skill starts only after the planning artifacts are
+complete. For a simple mechanical edit to an existing presentation where
+the storyline and design are unchanged, skip `presentation-planner` and use
+the PPTX skill directly.
+
+## Failure rule
+
+If the PPTX skill cannot implement a requested visual instruction, it must
+report the constraint and proposed fallback. The planning skill may update
+the design spec or slide outline, but it must not work around the constraint
+by manipulating the PPTX binary itself.

package/skills/presentation-planner/references/scenario-templates.md

@@ -0,0 +1,55 @@
+# Presentation scenario templates
+
+A presentation scenario defines the audience's reasoning journey between the
+brief and the slide-by-slide outline. It is not a script and does not repeat
+all slide content. It records the assertions, evidence, transitions,
+objections, and final action that make the deck persuasive and coherent.
+
+## Artifact boundary
+
+| Artifact | Question it answers |
+|---|---|
+| `presentation-brief.md` | Who is the audience, and what outcome is required? |
+| `presentation-scenario.md` | What reasoning journey moves them to that outcome? |
+| `slide-outline.md` | Which slides deliver each assertion and piece of evidence? |
+| `design-spec.yaml` | Which visual system expresses the content? |
+| `pptx-handoff.md` | How must the PPTX skill generate and validate the deck? |
+
+Do not use the scenario as a second slide outline. A scenario stage may span
+several slides, or two stages may share one slide when the argument remains
+clear.
+
+## Choose a template
+
+| Template | Use when | Avoid when |
+|---|---|---|
+| `executive-decision.md` | The audience must approve an option, investment, roadmap, or policy | The goal is purely educational |
+| `technical-briefing.md` | The audience must understand or review architecture and technical behavior | The deck is primarily KPI analysis |
+| `data-report.md` | Findings, trends, research, or experiments must support an action | Credible data is unavailable |
+
+Copy the closest template to
+`.presentation/<deck-slug>/presentation-scenario.md`, then remove stages that
+do not advance the required outcome. Do not add stages or slides merely to
+match the template.
+
+If none fits, create `presentation-scenario.md` from the generic fallback in
+`SKILL.md`, preserving the same stage, audience-question, assertion, evidence,
+transition, and suggested-slide-range fields used by packaged templates.
+
+## Adaptation rules
+
+- Express each stage as an assertion the audience must accept.
+- Record the audience question answered by each stage.
+- Map factual claims to sources or mark them as assumptions.
+- State the transition: why accepting one stage makes the next relevant.
+- Include objections, uncertainty, and trade-offs before the final action.
+- Keep the final decision or call to action singular and testable.
+- Set suggested slide counts only as planning ranges, never quotas.
+
+## Validation
+
+- Reading only stage assertions reconstructs the argument.
+- Every stage changes what the audience knows, believes, or is ready to do.
+- Evidence strength matches the certainty of the assertion.
+- The slide outline maps every slide to a scenario stage.
+- No slide introduces a new conclusion absent from the approved scenario.

package/skills/tech-writer/SKILL.md

@@ -3,15 +3,25 @@ name: tech-writer
 description: >-
   Helps structure and polish technical documents: README, design docs/ADRs,
   API reference, PR descriptions/commit messages/issue reports, release
-  notes/CHANGELOG, user manuals/how-to guides, code comments/docstrings, and
-  Qiita/Zenn articles. Use for requests like "write a README", "draft a
-  design doc", "write this PR description", "clean up my commit message",
-  "make this how-to guide clearer", "write API docs", "summarize the release
-  notes", "write a Zenn article", "write this up for Qiita", as well as
+  notes/CHANGELOG, user manuals/how-to guides, code comments/docstrings,
+  requirements definitions, system designs, test plans, operations runbooks,
+  migration plans, security designs/threat models, technical proposals,
+  RFI/RFP procurement documents, and Qiita/Zenn articles. Use for requests
+  like "write a README", "draft a design doc", "define system requirements",
+  "write a system design", "create a test plan", "write an operations
+  runbook", "plan a migration", "create a threat model", "write a technical
+  proposal", "draft an RFI", "create an RFP", "write this PR description",
+  "clean up my commit
+  message", "make this how-to guide clearer", "write API docs", "summarize
+  the release notes", "write a Zenn article", "write this up for Qiita", as
+  well as
   Japanese-language equivalents (「READMEを書いて」「設計ドキュメントを作って」
-  「PRの説明文を書いて」「コミットメッセージを整えて」「手順書を分かりやすくして」
-  「APIドキュメントを整備して」「リリースノートをまとめて」「Zennの記事を書いて」
-  「Qiitaに投稿する記事を書いて」). Especially useful when
+  「要件定義書を作って」「システム設計書を書いて」「テスト計画書を作って」
+  「運用設計書を書いて」「移行計画を作って」「脅威モデルを作って」
+  「技術提案書を書いて」「RFIを作って」「RFPを作って」「PRの説明文を書いて」
+  「コミットメッセージを整えて」「手順書を分かりやすくして」
+  「APIドキュメントを整備して」「リリースノートをまとめて」
+  「Zennの記事を書いて」「Qiitaに投稿する記事を書いて」). Especially useful when
   the request is a bare goal without enough context to start (e.g. "I want
   to write a README" / "○○を書きたい"), since this skill drives a one
   question-at-a-time intake before writing. Supports both Japanese and
@@ -31,7 +41,10 @@ argument-hint: "[write|review|score] [doctype] <target file or request>"
 Structures technical documents so readers reach the information they need
 with the shortest path. Covers README, design docs/ADRs, API reference, PR
 descriptions/commit messages/issue reports, release notes/CHANGELOG, user
-manuals/how-to guides, code comments/docstrings, and Qiita/Zenn articles.
+manuals/how-to guides, code comments/docstrings, requirements definitions,
+system designs, test plans, operations runbooks, migration plans, security
+designs/threat models, technical proposals, RFI/RFP procurement documents,
+and Qiita/Zenn articles.
 
 Default format: Markdown for every doctype in this skill, except a git
 commit message body (plain text by convention — light "-" bullets are
@@ -90,7 +103,13 @@ hand the user a checklist to fill in. Instead:
    past this doctype without knowing which one applies. Similarly, a bare
    "write a tech blog post" request doesn't by itself say Qiita, Zenn, or
    neither — ask which platform (or "no platform, just a plain document")
-   as part of this same first question.
+   as part of this same first question. For a "technical proposal", ask
+   whether it is an internal approval proposal or a supplier response to an
+   RFP; only the internal approval proposal maps to `technical-proposal`.
+   For a supplier response, structure the document against the supplied
+   RFP's requirement IDs, requested proposal contents, pricing format, and
+   contract deviations, then apply the general principles in
+   `references/style-constitution.md`.
 2. Open the matching reference file and note its target reader and any
    "settle before writing" items. Combined with the general musts below,
    this is your information checklist — but never show it to the user as a
@@ -104,7 +123,12 @@ hand the user a checklist to fill in. Instead:
    doctype (and subtype, for `pr-commit`), and (d) any doctype-specific
    musts (e.g. the decision and alternatives for a design doc, the
    prior-knowledge floor for a user manual, breaking-change status for
-   release notes, the related issue for a PR description or bug report).
+   release notes, the related issue for a PR description or bug report,
+   measurable acceptance conditions for a requirements definition, the
+   approved requirements baseline for a system design, exit criteria for a
+   test plan, RTO/RPO for an operations runbook, rollback conditions for a
+   migration plan, assets and trust boundaries for a threat model, market
+   unknowns for an RFI, or evaluation rules for an RFP).
 5. **A "don't know" / "not applicable" / "no ticket for this" answer
    satisfies a must — it is not a reason to keep asking.** Ask that must
    at most once; if the answer is a non-answer, record it as a stated
@@ -130,6 +154,15 @@ hand the user a checklist to fill in. Instead:
 | Release notes / CHANGELOG | release-notes | `references/doctypes/release-notes.md` |
 | User manual / how-to guide / tutorial | user-manual | `references/doctypes/user-manual.md` |
 | Code comments / docstrings | code-comments | `references/doctypes/code-comments.md` |
+| Requirements definition / 要件定義書 | requirements-definition | `references/doctypes/requirements-definition.md` |
+| System design / システム設計書 | system-design | `references/doctypes/system-design.md` |
+| Test plan / テスト計画書 | test-plan | `references/doctypes/test-plan.md` |
+| Operations design / Runbook / 運用設計書 | operations-runbook | `references/doctypes/operations-runbook.md` |
+| Migration plan / 移行計画書 | migration-plan | `references/doctypes/migration-plan.md` |
+| Security design / Threat model / セキュリティ設計書 | security-design | `references/doctypes/security-design.md` |
+| Internal technical proposal | technical-proposal | `references/doctypes/technical-proposal.md` |
+| Request for information / RFI | rfi | `references/doctypes/rfi.md` |
+| Request for proposal / RFP | rfp | `references/doctypes/rfp.md` |
 | Zenn article | zenn | `references/doctypes/zenn.md` |
 | Qiita article | qiita | `references/doctypes/qiita.md` |
 
@@ -140,9 +173,12 @@ one-question-at-a-time intake for reader and outcome.
 ## 2. Outline first for long documents
 
 For documents likely to run long — design docs/ADRs, user manuals with
-multiple steps, API references covering several endpoints, or anything the
-user calls "long"/"detailed"/"comprehensive" — draft a table of contents
-(heading outline) before writing any body prose.
+multiple steps, API references covering several endpoints, requirements
+definitions, system designs, test plans, operations runbooks, migration
+plans, security designs, technical proposals, RFI/RFP documents, or anything
+the user calls
+"long"/"detailed"/"comprehensive" — draft a table of contents (heading
+outline) before writing any body prose.
 
 1. Build the heading outline from the reader and outcome gathered in §1 and
    the doctype's recommended skeleton (in its reference file).
@@ -168,7 +204,9 @@ document and needs the outline step below.
 ## 3. Write — under the structure constitution
 
 For living, multi-section documents (README, design doc, API reference,
-release notes, user manual, Zenn/Qiita article), write under the 8 rules
+release notes, user manual, requirements definition, system design, test
+plan, operations runbook, migration plan, security design, technical
+proposal, RFI/RFP, Zenn/Qiita article), write under the 8 rules
 in `references/style-constitution.md`. Summary: state "what this is" and
 "the outcome for the reader" in the first three lines; make headings
 labels that preview content (not "Overview", but "Overview of what");
@@ -272,7 +310,10 @@ for `write` mode; do not run it for `review` or `score` mode.
 
 See each reference file for detail. The items below are for living,
 multi-section documents (README, design doc, API reference, release notes,
-user manual, Zenn/Qiita article). Atomic artifacts (commit message, PR
+user manual, requirements definition, system design, test plan, operations
+runbook, migration plan, security design, technical proposal, RFI/RFP,
+Zenn/Qiita article). Atomic
+artifacts (commit message, PR
 description, issue report, code comment/docstring, a single appended
 release-notes entry) are already covered by their own doctype checklist
 via step 2 in §4 — these common items don't add extra requirements on top

package/skills/tech-writer/assets/templates/migration-plan.md

@@ -0,0 +1,173 @@
+# <システム・データ名> 移行計画書
+
+<何をどこからどこへ、どの停止許容時間と品質基準で安全に移行するかを3文以内で要約する。>
+
+- 文書版: <例: 1.0>
+- 作成日: <YYYY-MM-DD>
+- 最終更新日: <YYYY-MM-DD>
+- 移行責任者: <氏名・チーム>
+- Go / No-Go判断者: <氏名・会議体>
+- ステータス: Draft / In Review / Approved
+- 本番移行予定: <YYYY-MM-DD HH:mm–HH:mm TZ>
+- 関連要件・設計: <文書名・版・URL>
+
+## この移行計画で合意する事項
+
+- 移行対象: <データ、利用者、機能、外部接続>
+- 移行方式: <一括、段階、並行稼働など>
+- 許容停止時間と品質基準: <値>
+- 承認を求める事項: <日程、体制、判定、ロールバック>
+
+## 現行と移行後の状態
+
+| 項目 | 現行 | 移行後 | 主な変更 | 利用者への影響 |
+|---|---|---|---|---|
+| システム | <現行> | <移行先> | <変更> | <影響> |
+| データ | <形式・量> | <形式・量> | <変換> | <影響> |
+| 業務 | <手順> | <手順> | <変更> | <教育・周知> |
+
+## 対象範囲と対象外
+
+### 対象範囲
+
+- <移行するデータ・設定・利用者・接続先>
+
+### 対象外
+
+- <廃止しないもの・後続フェーズへ送るもの>
+
+## 前提条件と制約
+
+| ID | 条件・制約 | 確認方法 | 期限 | 所有者 |
+|---|---|---|---|---|
+| MIG-CON-001 | <停止時間・契約・技術制約> | <確認> | <期限> | <担当> |
+
+## 移行対象の棚卸し
+
+| 対象ID | 対象 | 移行元 | 移行先 | 件数・容量 | 所有者 | 依存関係 | 移行要否 |
+|---|---|---|---|---:|---|---|---|
+| MIG-001 | <データ・設定> | <場所> | <場所> | <値> | <担当> | <依存先> | Yes / No |
+
+## データマッピングと変換
+
+| 移行元項目 | 移行先項目 | 変換ルール | 必須・既定値 | 検証ルール | エラー時の扱い |
+|---|---|---|---|---|---|
+| <項目> | <項目> | <変換> | <条件> | <型・範囲・参照整合性> | <除外・補正・中止> |
+
+## 移行方式と移行単位
+
+- 方式: 一括 / 段階 / 並行稼働 / Blue-Green / <その他>
+- 選定理由: <停止時間、整合性、ロールバックとの関係>
+- 差分同期: <CDC、二重書き、再実行など>
+- 冪等性: <再実行しても重複・欠損しない仕組み>
+
+| Wave | 対象 | 実施日時 | 完了条件 | 次Waveへの判定 |
+|---|---|---|---|---|
+| 1 | <対象> | <日時> | <条件> | <条件> |
+
+## 体制と役割
+
+| 役割 | 担当 | 責任 | 当日の連絡方法 | 代行者 |
+|---|---|---|---|---|
+| 移行指揮 | <担当> | Go / No-Go、進行 | <方法> | <担当> |
+| データ移行 | <担当> | 抽出・変換・投入 | <方法> | <担当> |
+| 業務確認 | <担当> | 業務受入 | <方法> | <担当> |
+| 運用・監視 | <担当> | 監視・障害対応 | <方法> | <担当> |
+
+## リハーサル計画
+
+| 回 | 目的 | 対象・データ量 | 実施日 | 目標時間 | 合格条件 | 改善事項 |
+|---|---|---|---|---:|---|---|
+| 1 | <手順・性能・復旧の検証> | <範囲> | <日付> | <時間> | <条件> | <記録> |
+
+## 移行開始条件
+
+- <リハーサルが合格している>
+- <対象版が承認され、変更凍結されている>
+- <バックアップとリストア試験が完了している>
+- <監視、連絡網、ロールバック環境が準備されている>
+- <利用者通知と業務側の準備が完了している>
+
+## 本番移行タイムライン
+
+| 時刻 | 手順ID | 作業 | 実行者 | 想定時間 | 完了条件 | 証跡 |
+|---|---|---|---|---:|---|---|
+| <HH:mm> | STEP-001 | <作業> | <担当> | <分> | <確認可能な条件> | <ログ・画面> |
+
+## 検証と照合
+
+| 検証ID | 対象 | 検証方法 | 移行前値 | 移行後値 | 許容差 | 判定者 |
+|---|---|---|---:|---:|---:|---|
+| VAL-001 | 件数 | <SQL・レポート> | <値> | <値> | 0 | <担当> |
+| VAL-002 | 金額・集計 | <照合方法> | <値> | <値> | <値> | <担当> |
+| VAL-003 | 参照整合性 | <孤立・重複・外部キー検査> | <値> | <値> | 0 | <担当> |
+| VAL-004 | 業務シナリオ | <操作> | <期待> | <実結果> | なし | <担当> |
+
+## Go / No-Go判定
+
+| 判定時点 | Go条件 | No-Go条件 | 必要な証跡 | 判断者 |
+|---|---|---|---|---|
+| 移行開始前 | <条件> | <条件> | <チェックリスト> | <担当> |
+| 切替前 | <条件> | <条件> | <移行・照合結果> | <担当> |
+| サービス再開前 | <条件> | <条件> | <業務確認・監視> | <担当> |
+
+## ロールバック計画
+
+- ロールバック可能期限: <時刻・条件>
+- ロールバック判断条件: <時間超過、欠損、重大障害など>
+- 判断者: <役割>
+- データ整合性方針: <移行後更新の扱い>
+
+| 手順 | 作業 | 実行者 | 想定時間 | 完了条件 |
+|---:|---|---|---:|---|
+| 1 | <新環境への書き込みを停止する> | <担当> | <分> | <条件> |
+| 2 | <切替後に新環境へ書き込まれた差分を退避し、再適用・補償対象を確定する> | <担当> | <分> | <差分が固定され証跡がある> |
+| 3 | <旧環境を復旧し、必要な差分を再適用または補償する> | <担当> | <分> | <整合性基準を満たす> |
+| 4 | <データと業務を確認して旧環境を再開する> | <担当> | <分> | <再開条件を満たす> |
+
+## 業務継続と利用者コミュニケーション
+
+| 対象 | 通知内容 | 通知時期 | 手段 | 担当 |
+|---|---|---|---|---|
+| 利用者 | <停止・変更・再開> | <時期> | <メール・画面> | <担当> |
+| 問い合わせ窓口 | <FAQ・既知問題> | <時期> | <手段> | <担当> |
+| 経営・顧客 | <進捗・障害> | <条件> | <手段> | <担当> |
+
+- 停止中の代替業務: <手作業・受付停止など>
+- 再開後の問い合わせ増加対応: <増員・期間>
+
+## セキュリティと監査
+
+- 移行データの暗号化: <転送時・保存時>
+- 一時ファイル: <保管場所・アクセス・削除期限>
+- 特権アクセス: <申請・有効期限・監査>
+- 個人情報・機密情報: <マスキング・取扱い>
+- 操作証跡: <記録内容・保存期間>
+
+## 移行後の安定化
+
+| 期間 | 監視強化項目 | 判定基準 | 担当 | 通常運用への移行条件 |
+|---|---|---|---|---|
+| <期間> | <エラー率・照合・問い合わせ> | <閾値> | <担当> | <条件> |
+
+- 旧環境の扱い: <参照専用、保持期間、廃止日>
+- 一時データ・権限の削除: <期限・証跡>
+- 未移行・エラーデータの処理: <方法・期限>
+
+## リスクと未解決事項
+
+| ID | 内容 | 影響 | 発生可能性 | 対策・期限 | 所有者 | ステータス |
+|---|---|---|---|---|---|---|
+| MIG-RSK-001 | <内容> | High / Medium / Low | High / Medium / Low | <対策> | <担当> | Open |
+
+## 承認記録
+
+| 版 | 承認日 | 承認者 | 判断 | 条件・コメント |
+|---|---|---|---|---|
+| <版> | <YYYY-MM-DD> | <氏名・会議体> | Approved / Rejected / Deferred | <条件> |
+
+## 変更履歴
+
+| 版 | 日付 | 変更内容 | 変更理由 | 作成者 |
+|---|---|---|---|---|
+| 0.1 | <YYYY-MM-DD> | 初版 | <理由> | <氏名> |

package/skills/tech-writer/assets/templates/operations-runbook.md

@@ -0,0 +1,202 @@
+# <サービス名> 運用設計書・Runbook
+
+<サービスを安定して監視・変更・復旧するために、運用担当者が実行する判断と手順を3文以内で要約する。>
+
+- 文書版: <例: 1.0>
+- 作成日: <YYYY-MM-DD>
+- 最終更新日: <YYYY-MM-DD>
+- サービス所有者: <チーム・責任者>
+- 運用責任者: <チーム・責任者>
+- ステータス: Draft / In Review / Approved
+- 対象環境: Production / Staging / <その他>
+- 関連設計書: <文書名・版・URL>
+
+## この運用設計で合意する事項
+
+- 運用対象とサービス時間: <対象・時間帯>
+- 運用体制: <担当、当番、委託先>
+- サービス目標: <SLO・復旧目標>
+- 承認を求める事項: <監視、権限、手順、残余リスク>
+
+## サービス概要と依存関係
+
+| 項目 | 内容 |
+|---|---|
+| 利用者・業務 | <対象利用者と重要業務> |
+| 主要機能 | <機能> |
+| サービス時間 | <曜日・時間・計画停止> |
+| 依存サービス | <クラウド、外部API、ネットワークなど> |
+| データストア | <種類・場所> |
+| 構成管理 | <IaC・設定リポジトリ> |
+| ダッシュボード | <URL> |
+| Issue・問い合わせ | <URL・窓口> |
+
+```mermaid
+flowchart LR
+    U[<利用者>] --> S[<対象サービス>]
+    S --> D[(<データストア>)]
+    S --> E[<外部依存サービス>]
+    M[<監視基盤>] --> S
+```
+
+## サービスレベルと運用指標
+
+| SLI | 測定方法 | SLO | 集計期間 | エラーバジェット | 未達時の対応 |
+|---|---|---:|---|---:|---|
+| <可用性・遅延など> | <式・データソース> | <値> | <期間> | <値> | <変更停止・改善> |
+
+## 運用体制と連絡経路
+
+| 役割 | 担当 | 対応時間 | 責任 | 連絡方法 |
+|---|---|---|---|---|
+| サービス所有者 | <担当> | <時間帯> | <判断・予算> | <方法> |
+| オンコール | <担当> | <時間帯> | <一次対応> | <方法> |
+| セキュリティ | <担当> | <時間帯> | <事故対応> | <方法> |
+
+### エスカレーション
+
+| 条件 | 一次連絡 | 二次連絡 | 経営・顧客連絡 | 期限 |
+|---|---|---|---|---|
+| <重大度・継続時間> | <担当> | <担当> | <担当> | <時間> |
+
+## 監視・ログ・アラート
+
+| 監視ID | 対象 | シグナル | 閾値・条件 | 重要度 | 通知先 | Runbook節 |
+|---|---|---|---|---|---|---|
+| MON-001 | <対象> | <メトリクス・ログ> | <条件と継続時間> | Critical / Warning | <通知先> | <節名> |
+
+- ログ保存期間: <期間>
+- トレース・相関ID: <方式>
+- 機密情報のマスキング: <対象・方式>
+- 通知抑制・重複排除: <方式>
+- アラート試験: <頻度・方法>
+
+## 日次・週次・月次の定常作業
+
+| 頻度 | 作業 | 手順 | 完了条件 | 証跡 | 担当 |
+|---|---|---|---|---|---|
+| 日次 | <作業> | <コマンド・URL・手順> | <確認結果> | <保存先> | <担当> |
+| 週次 | <作業> | <手順> | <確認結果> | <保存先> | <担当> |
+| 月次 | <作業> | <手順> | <確認結果> | <保存先> | <担当> |
+
+## インシデントの重大度と初動
+
+| 重大度 | 定義 | 例 | 応答期限 | 更新頻度 | 指揮権 |
+|---|---|---|---|---|---|
+| SEV-1 | <全停止・重大漏えいなど> | <例> | <時間> | <間隔> | <役割> |
+| SEV-2 | <主要機能障害など> | <例> | <時間> | <間隔> | <役割> |
+| SEV-3 / 4 | <限定影響> | <例> | <時間> | <間隔> | <役割> |
+
+### 共通初動
+
+1. <アラートと利用者影響を確認する。>
+2. <インシデントを起票し、指揮担当と記録担当を決める。>
+3. <直近変更、依存先、主要メトリクスを確認する。>
+4. <影響拡大を止めるための緩和策を実施する。>
+5. <定めた頻度で関係者へ状況を更新する。>
+6. <復旧を検証し、事後レビューを登録する。>
+
+## 症状別Runbook
+
+### <症状・アラート名>
+
+- 検知条件: <アラート・問い合わせ>
+- 利用者影響: <影響>
+- 安全上の注意: <実行禁止条件・承認が必要な操作>
+
+1. <ダッシュボード・ログで事象を確認する。>
+2. <切り分けコマンドまたは画面操作を実行する。>
+3. <一時的な緩和策を実行する。>
+4. <正常化をSLIと利用者操作で確認する。>
+
+- エスカレーション条件: <条件>
+- 復旧しない場合: <代替手段・停止判断>
+- 証跡: <保存するログ・時刻・操作>
+
+## 起動・停止・再起動
+
+| 操作 | 実行条件 | 手順 | 正常性確認 | 失敗時の対応 | 承認 |
+|---|---|---|---|---|---|
+| 起動 | <条件> | <手順> | <ヘルスチェック> | <復旧> | <要否> |
+| 停止 | <条件> | <手順> | <停止確認> | <復旧> | <要否> |
+| 再起動 | <条件> | <手順> | <正常性確認> | <ロールバック> | <要否> |
+
+## バックアップとリストア
+
+| 対象 | 方式 | 頻度 | 保持期間 | 暗号化 | 復元目標 | 復元試験 |
+|---|---|---|---|---|---|---|
+| <データ・設定> | <方式> | <頻度> | <期間> | <方式> | RTO / RPO | <頻度・証跡> |
+
+### リストア手順
+
+- 前提・承認: <障害状況、復元時点、影響範囲、実行承認者>
+- 復元先: <原則として隔離環境へ先行復元し、検証後に本番へ適用する>
+- 失敗時の対応: <中止条件、再試行上限、エスカレーション先>
+- 証跡: <承認、スナップショット、ログ、検証結果の保存先>
+
+1. <復元時点、影響範囲、復元先について承認を得る。>
+2. <現在状態のスナップショットと操作開始時刻を記録する。>
+3. <隔離環境へ復元し、バックアップの完全性と復元手順を検証する。>
+4. <本番への書き込み停止または対象データの隔離を実施する。>
+5. <承認済みの復元先へバックアップを復元する。>
+6. <件数、参照整合性、アプリケーション動作を検証する。>
+7. <サービスを再開し、監視結果と利用者影響を確認する。>
+8. <関係者へ結果を通知し、すべての証跡を保存する。>
+
+## セキュリティ運用
+
+- 特権アクセス: <申請、承認、有効期限、記録>
+- シークレット・鍵・証明書: <保管、更新、失効、期限監視>
+- 脆弱性対応: <検知元、重大度、修正期限>
+- 監査ログ: <対象、保存期間、確認頻度>
+- セキュリティ事故: <隔離、証拠保全、連絡先>
+
+## 変更・リリース・ロールバック
+
+| 変更区分 | 承認 | 実施時間帯 | 検証 | ロールバック条件 |
+|---|---|---|---|---|
+| 標準変更 | <承認者> | <時間帯> | <確認> | <条件> |
+| 通常変更 | <承認者> | <時間帯> | <確認> | <条件> |
+| 緊急変更 | <承認者> | <時間帯> | <事後確認> | <条件> |
+
+- リリース手順: <パイプライン・段階展開>
+- 変更前確認: <バックアップ・依存先・エラーバジェット>
+- 変更後確認: <SLI・ログ・利用者シナリオ>
+- ロールバック手順: <復旧先・データ互換性>
+
+## 容量・性能・コスト管理
+
+| 指標 | 現在値 | 警告閾値 | 上限 | 拡張方法 | 確認頻度 |
+|---|---:|---:|---:|---|---|
+| <CPU・容量・件数・費用> | <値> | <値> | <値> | <方法> | <頻度> |
+
+## 災害復旧と事業継続
+
+- 災害シナリオ: <リージョン障害・拠点喪失など>
+- RTO / RPO: <値>
+- 切替判断者: <役割>
+- 切替・切戻し手順: <手順参照>
+- 代替業務: <手作業・縮退運転>
+- 訓練頻度と証跡: <頻度・保存先>
+
+## リスクと未解決事項
+
+| ID | 内容 | 影響 | 対応・期限 | 所有者 | ステータス |
+|---|---|---|---|---|---|
+| OPS-RSK-001 | <内容> | <影響> | <対応> | <担当> | Open |
+
+## Runbookの有効性と陳腐化検知
+
+- 定期レビュー期限: <例: 90日ごと>
+- 臨時レビュー条件: <構成、依存先、権限、アラート、復旧方式の変更>
+- 期限超過時の扱い: <警告、利用停止、再検証が必要な手順>
+
+| Runbook・手順 | 最終実行・訓練日 | 検証した構成版 | 次回期限 | 所有者 | 状態 |
+|---|---|---|---|---|---|
+| <手順名> | <YYYY-MM-DD> | <バージョン・構成> | <YYYY-MM-DD> | <担当> | Current / Review Due / Stale |
+
+## レビューと変更履歴
+
+| 版 | 日付 | 変更内容・訓練結果 | レビュー担当 | 次回見直し |
+|---|---|---|---|---|
+| 0.1 | <YYYY-MM-DD> | 初版 | <担当> | <YYYY-MM-DD> |