シナリオ
📄 CHANGELOG.md · security-policy-update.md
昨日のエンジニアリング全体会議（Day 051）でSOC 2対応セキュリティ変更をプレゼンした後、 今度はその内容を公式ドキュメントとして整備する。 SOC 2監査では「変更管理の証跡（change management audit trail）」が求められるため、 「誰が・いつ・なぜ・何を変えたか」を英語で明確に文書化する。
タスクA
CHANGELOG.md セクション
標準フォーマットで変更履歴を記録（50〜100語）
タスクB
Security Policy Update Notice
背景・変更・施行日・必要なアクションを記載（150〜250語）
あなた
Daishi Kainuma（シニアエンジニア、Security WGメンバー）
エンジニアリング部門 · 変更管理ドキュメントの作成担当
読者
エンジニアリングチーム全員（10名）+ 将来のSOC 2監査官
内部チームだけでなく外部監査官も読む — 背景を知らない人でも理解できる文書が必要
今回の変更内容（Day 051から継続）
アクセスログ 90日間保存義務化
施行: 2026-07-01
施行: 2026-07-01
本番SSH直接接続禁止・踏み台サーバー経由のみ
施行: 2026-07-01
施行: 2026-07-01
サードパーティ依存ライブラリの月次セキュリティ監査
施行: 2026-07-01
施行: 2026-07-01
タスク
以下の2種類のドキュメントを英語で作成する。
タスクA: CHANGELOG.md
タスクB: Security Policy Notice
タスクA: CHANGELOG.md セクション
- 日付・変更種別（Security）を含む標準CHANGELOGフォーマット（Keep a Changelog形式）
- 変更の"what"を
Added/Changedラベルで簡潔に箇条書き - 各変更に施行日
(effective 2026-07-01)を含める
タスクB: Security Policy Update Notice
- Title / Date / Author / Status のメタデータブロック
- Summary — なぜこの変更が必要か（SOC 2・エンタープライズ契約）
- Changes — 3点を番号付きで構造化
- Effective Date / Affected Teams / Required Actions / Contact
タスクA: CHANGELOG.md セクションをここに書いてみましょう...
タスクB: Security Policy Update Notice をここに書いてみましょう...
使える表現・フレーズ
カードをクリックすると英語フレーズを表示します。
施行される・発効する
クリックで英語を表示 →
take effect / go into effect
💡 "This policy takes effect on July 1." — "starting from" より格式が高い。法務・コンプライアンス文書の標準
〜に準拠して / コンプライアンス要件を満たすために
クリックで英語を表示 →
in compliance with / to comply with
💡 "in compliance with SOC 2 Type II requirements" — 名詞形の "in compliance with" は文書の書き出しに最適
義務的な保存期間
クリックで英語を表示 →
mandatory retention period
💡 "mandatory" = 義務的な。"required" より法務文書の標準語。"retention" = 保存・保持
変更管理 / 監査証跡
クリックで英語を表示 →
change management / audit trail
💡 SOC 2審査で必ず問われる概念。"maintain an audit trail" = 監査証跡を維持する
以前の版を廃止・差し替える
クリックで英語を表示 →
supersede / replace
💡 "This policy supersedes the previous version dated X." — ポリシードキュメントの定番表現。"supersede" の方が格式が高い
例外を書面で承認する
クリックで英語を表示 →
grant an exception in writing
💡 "Exceptions may be granted in writing by the Security WG." — "in writing" = 文書による。口頭不可を示す重要な条件
影響を受けるチーム
クリックで英語を表示 →
affected teams / stakeholders
💡 "All affected teams must update their workflows by June 30." — 責任範囲を明確にする表現
監査可能な状態で
クリックで英語を表示 →
in an auditable state
💡 単に "saved" ではなく、監査官が確認できる形式・場所に保存することを意味する。SOC 2特有の表現
ヒント（段階的開示）
ヒント 1 — 構成・方向性
タスクA: CHANGELOG.md フォーマット（Keep a Changelog形式）
## [Security Update] — YYYY-MM-DD ### Security - **Added** [変更1] - **Changed** [変更2] - **Added** [変更3]
"Added" / "Changed" / "Security" の慣例ラベルを使う。
タスクB: Security Policy Update Notice の構成
- Title / Date / Author / Status — メタデータブロック
- Summary — 背景（SOC 2・エンタープライズ契約）
- Changes — 3点を番号付きリストで
- Effective Date — 日付を明記
- Affected Teams — 誰が影響を受けるか
- Required Actions — チーム別の具体的な行動
- Contact — 問い合わせ先
重要: SOC 2監査では「なぜ変更したか（背景）」と「いつ施行するか（日付）」が文書に明記されていることが求められる。
ヒント 2 — キーフレーズ・表現
"As part of our SOC 2 Type II certification process, the following security controls have been updated."— 背景説明の書き出し"Effective July 1, 2026, the following policies will be enforced:"— 施行日の明記"All engineers must route production access through the designated bastion host."— 必要なアクションの指示"Exceptions may be granted in writing by the Security Working Group."— 例外プロセスの明記"For questions or concerns, contact the Security WG at #security-wg on Slack."— 問い合わせ先
ヒント 3 — 骨格テンプレート
タスクA 骨格:
## [Security Update] — 2026-06-05
### Security
- **Added** mandatory [N]-day retention of [何の] logs, in compliance with [認証名] (effective [日付]).
- **Changed** production environment access: direct SSH connections are prohibited; all access must be routed through [方法] (effective [日付]).
- **Added** monthly [何の] audits for [対象] dependencies (effective [日付]).
タスクB 骨格:
Title: [Security Policy Update タイトル]
Date: [日付]
Author: [名前, 役割]
Status: Active
Summary:
As part of [理由: SOC 2/エンタープライズ契約], the following security controls will take effect on [日付].
Changes:
1. [変更1タイトル] — [内容]
2. [変更2タイトル] — [内容]
3. [変更3タイトル] — [内容]
Effective Date: [日付]
Affected Teams: [チーム名]
Required Actions:
- [チーム1]: [アクション]
- [チーム2]: [アクション]
Contact: [連絡先]
モデル解答（B2〜C1相当）
タスクA: CHANGELOG.md セクション
## [Security Update] — 2026-06-05
### Security
Added
mandatory 90-day retention policy for all production access logs,
in compliance with SOC 2 Type II audit requirements (effective 2026-07-01).
Changed
production environment access: direct SSH connections are now prohibited;
all access must be routed through the designated bastion host or an approved access management tool (effective 2026-07-01).
Added
monthly security audit requirement for all third-party dependencies;
results must be reviewed by the Engineering Lead and documented (effective 2026-07-01).
タスクB: Security Policy Update Notice
Security Policy Update — SOC 2 Type II Compliance Controls
Summary
As part of TechBridge Inc.'s SOC 2 Type II certification process — initiated following our recent enterprise contract — the Security Working Group has updated three core security controls. These changes are designed to meet the audit requirements for access control, log management, and third-party risk management.
Changes
1. Access Log Retention (90-Day Minimum)
All production access logs must be retained for a minimum of 90 days and kept in an auditable state. Automated log archiving will be handled by the infrastructure team.
2. Production SSH Access — Bastion Host Required
Direct SSH connections to production environments are prohibited effective July 1, 2026. All production access must be routed through the designated bastion host or an approved access management tool. Exceptions may be granted in writing by the Security Working Group.
3. Monthly Third-Party Dependency Audits
All third-party libraries and dependencies must undergo a monthly security vulnerability scan. Results must be reviewed by the Engineering Lead and findings documented in the security log.
Effective Date
July 1, 2026
Affected Teams
Engineering
Infrastructure
DevOps
Required Actions
All Engineers
Update your workflow to use bastion host access before July 1.
Infrastructure Team
Confirm automated log archiving is configured by June 25.
Engineering Leads
Schedule the first dependency audit for the week of June 30.
Contact
For questions or concerns, contact the Security Working Group via
#security-wg on Slack or by email at security-wg@techbridge.example.com.
解説
構成分析
A
CHANGELOG は "what" のみ記録する — CHANGELOGの役割は「何が変わったか」の履歴記録。"why" は別のNotice文書に委ねる。Keep a Changelog形式では
Added / Changed / Deprecated / Removed / Fixed / Security の標準ラベルを使い、読み手がパッと変更の種別を判断できるB
Policy Notice はメタデータブロックから始める — Title / Date / Author / Status を最初に配置することで「誰が・いつ・どのステータスで」発行したかが記録される。SOC 2監査官が最初に確認するセクション
3
Required Actions でチーム別に行動を明確化 — 「エンジニアリングチーム全員」という漠然とした指定ではなく、「All Engineers / Infrastructure Team / Engineering Leads」のように役割別に具体的なアクションと期限を示す。英語文書では「責任の所在」を明確にすることが重要
4
例外プロセスを明記する — "Exceptions may be granted in writing by the Security WG" の1文を追加することで、ポリシーの現実的な運用設計を示す。例外プロセスのない厳しすぎるポリシーは守られない — この1文がコンプライアンス率を上げる
重要表現まとめ
| 表現 | 意味・ポイント |
|---|---|
in compliance with | 〜に準拠して。法務・監査文書の定番。"to comply with" の名詞形で文書に適した格式 |
effective [date] | 〜から施行。"starting from" より格式が高い。文頭・文末どちらでも使える |
in an auditable state | 監査可能な状態で。単に "saved" より法務・SOC 2文脈で意味が明確 |
Exceptions may be granted in writing | 例外は書面で許可される。"in writing" = 文書による。口頭不可の条件 |
mandatory retention period | 義務的な保存期間。"required saving period" は不自然。コンプライアンス文書の標準語 |
supersedes | 以前の版を廃止・差し替える。ポリシードキュメントに不可欠な表現（今回は使わなかったが重要） |
third-party dependencies | 外部依存ライブラリ。"external libraries" より技術的・法務的に正確 |
文化的ポイント
監査証跡の思想（Audit Trail）
英語圏のコンプライアンス文書は「後で外部の監査官が読む」ことを前提に書かれる。「誰が・なぜ・いつ」を明記することが日本語文書より重要視される。日本語では「関係者は背景を知っている」を前提にしがちだが、英語文書は「背景を知らない第三者が読んでも理解できる」が原則
英語圏のコンプライアンス文書は「後で外部の監査官が読む」ことを前提に書かれる。「誰が・なぜ・いつ」を明記することが日本語文書より重要視される。日本語では「関係者は背景を知っている」を前提にしがちだが、英語文書は「背景を知らない第三者が読んでも理解できる」が原則
CHANGELOGとNoticeの役割分担
CHANGELOGは"what（何が変わったか）"の履歴記録。Policy Noticeは"why（なぜ）・who（誰に影響）・how（どう対応）"を説明するコミュニケーション文書。この2つを混在させないのが英語技術文書の原則
CHANGELOGは"what（何が変わったか）"の履歴記録。Policy Noticeは"why（なぜ）・who（誰に影響）・how（どう対応）"を説明するコミュニケーション文書。この2つを混在させないのが英語技術文書の原則
Required Actions で「誰が・何を・いつまでに」を明確に
"よろしくお願いします"ではなく、役割別・期限付きの具体的なアクションを指定する。英語圏のビジネス文化では責任の明確化が礼儀の一形態。曖昧な指示はむしろ失礼とされることがある
"よろしくお願いします"ではなく、役割別・期限付きの具体的なアクションを指定する。英語圏のビジネス文化では責任の明確化が礼儀の一形態。曖昧な指示はむしろ失礼とされることがある
例外プロセスを設けることの重要性
「例外なし」と書くより「書面承認で例外可」と書いた方が、実際のコンプライアンス率が上がる（too rigid なポリシーは守られない）。SOC 2審査でも「現実的な運用設計」が評価される
「例外なし」と書くより「書面承認で例外可」と書いた方が、実際のコンプライアンス率が上がる（too rigid なポリシーは守られない）。SOC 2審査でも「現実的な運用設計」が評価される
よくある日本人のミス
❌ "This policy will be effective from July 1."
"effective from" は不自然な前置詞の使い方
→
✅ "This policy takes effect on July 1." / "effective July 1" — 前置詞 on を使う
❌ "Please refer to the following changes."
和訳調の冒頭。英語文書では用件を先に（BLUF）
→
✅ "The following security controls will take effect on July 1:" — 結論から始める
❌ "All staffs must follow these policies."
staff は不可算名詞。複数形 staffs は誤り
→
✅ "All staff must..." / "All engineers must..." / "All team members must..."
❌ CHANGELOGに背景・理由を長文で書く
CHANGELOGは"what"の記録。"why"は別文書に分離するのが原則
→
✅ CHANGELOG: 簡潔に変更内容のみ / Policy Notice: 背景・理由・Required Actionsを詳述
❌ "Please contact to #security-wg for any questions."
contact は他動詞。to は不要
→
✅ "For questions, contact #security-wg on Slack." / "contact the Security WG"
❌ "We will do monthly audit for libraries."
冠詞の脱落・動詞の使い方が不自然・前置詞のミス
→
✅ "Monthly security audits will be conducted for all third-party dependencies."
ワンランク上の表現（Phase 3 以降）
Basic
## Changes — 2026-06-05
Security
- We added log retention 90 days.
- We stopped direct SSH.
- We added library audit every month.
↓ 標準フォーマット・明確な動詞・コンテキストを加えると
B2（今回のレベル）
## [Security Update] — 2026-06-05
### Security
- **Added** mandatory 90-day retention policy for all production access logs, in compliance with SOC 2 Type II audit requirements (effective 2026-07-01).
- **Changed** production environment access: direct SSH connections are now prohibited; all access must be routed through the designated bastion host (effective 2026-07-01).
- **Added** monthly security audit requirement for all third-party dependencies (effective 2026-07-01).
↓ SOC 2コントロール番号を追加するとプロレベルに
C1
## [1.4.0] — 2026-06-05
### Security
- Enforced 90-day log retention for all production access (SOC 2 CC6.1, CC7.2); logs must be retained in an auditable, tamper-evident state.
- Restricted production SSH to bastion-host-only access; all exceptions require written approval from the Security WG (SOC 2 CC6.6).
- Mandated monthly CVE scans for third-party dependencies; findings classified P0/P1 must be remediated within 14/30 days respectively (SOC 2 CC7.1).
SOC 2 CC6.1, CC6.6, CC7.1, CC7.2
（SOC 2の具体的なコントロール番号。監査官が一目で対応関係を確認できる。プロフェッショナルレベルの証跡管理に必要）
"tamper-evident state"
（改ざんが検知できる状態で。"auditable" より強いセキュリティ要件を示すC1表現）
"findings classified P0/P1 must be remediated within 14/30 days"
（P0/P1の優先度ラベルと修正期限の明記。セキュリティエンジニアリングの実務語彙。CVE脆弱性対応の標準的なSLAの書き方）
Document Control ブロック（Version / Date / Author / Changes）
（ポリシードキュメント自体のバージョン管理表。大企業やエンタープライズ契約先の監査官が最も重視するセクションの一つ）
次のステップ
- 発展: エンジニアから「SSH bastion経由は開発効率が落ちる。例外申請プロセスを整備してほしい」というメールが来た場合、Security WGとして例外申請フォーム（Exception Request Form）を定義した追加ドキュメントを英語で作成する
- 次回 (Day 053 · 土): 1on1/Conversation × Legal/Compliance — SSH制限で作業効率が落ちたと不満を持つエンジニアと1on1でコミュニケーションを取る
自己評価（解いた後に記入）
理解度
自分の回答
タスクA: CHANGELOG.md セクション
タスクB: Security Policy Update Notice