itdojp · ootakazuhiko · Jun 27, 2026 · Jun 27, 2026 · Jun 27, 2026
diff --git a/BOOK-PROPOSAL.md b/BOOK-PROPOSAL.md
@@ -2,12 +2,12 @@
 
 ## 目的
 
-未経験〜初級が、実務で求められるドキュメント成果物（README/手順書/Runbook/ADR/障害報告・ポストモーテム）を“作れる”状態にする。
+未経験〜初級が、実務で求められるドキュメント成果物（README / 手順書 / Runbook / ADR / 障害報告・ポストモーテム）を“作れる”状態にする。
 
 ## 対象読者
 
 - ソフトウェア/インフラ問わず、実務経験が浅いエンジニア
-- OJTや研修でドキュメントの型を揃えたいチーム
+- OJT や研修でドキュメントの型を揃えたいチーム
 - レビュー観点や責任分界を明確化したいリード層
 
 ## 前提知識
@@ -33,11 +33,11 @@
 - 第4章: 技術文体（曖昧さ排除・手順の書き方・例外系）（狙い: 技術文体（曖昧さ排除・手順の書き方・例外系）を実務判断/成果物に落とす）
 - 第5章: 図解（構成図/フロー/シーケンスの最小セット）（狙い: 図解（構成図/フロー/シーケンスの最小セット）を実務判断/成果物に落とす）
 - 第6章: 手順書（実行前提/検証/ロールバック/リスク）（狙い: 手順書（実行前提/検証/ロールバック/リスク）を実務判断/成果物に落とす）
-- 第7章: Runbook（平常時/異常時/エスカレーション）（狙い: Runbook（平常時/異常時/エスカレーション）を実務判断/成果物に落とす）
+- 第7章: Runbook（平常時 / 異常時 / エスカレーション）（狙い: Runbook（平常時 / 異常時 / エスカレーション）を実務判断/成果物に落とす）
 - 第8章: ADR（意思決定記録：背景→選択肢→決定→影響）（狙い: ADR（意思決定記録：背景→選択肢→決定→影響）を実務判断/成果物に落とす）
-- 第9章: 障害報告・ポストモーテム（タイムライン/真因/再発防止）（狙い: 障害報告・ポストモーテム（タイムライン/真因/再発防止）を実務判断/成果物に落とす）
-- 第10章: Docs-as-Code運用（レビュー/版管理/CI/公開）（狙い: Docs-as-Code運用（レビュー/版管理/CI/公開）を実務判断/成果物に落とす）
-- 第11章: ドキュメント品質の守り方（陳腐化対策/Owner/KPI）（狙い: ドキュメント品質の守り方（陳腐化対策/Owner/KPI）を実務判断/成果物に落とす）
+- 第9章: 障害報告・ポストモーテム（タイムライン / 真因 / 再発防止）（狙い: 障害報告・ポストモーテム（タイムライン / 真因 / 再発防止）を実務判断/成果物に落とす）
+- 第10章: Docs-as-Code 運用（レビュー / 版管理 / CI / 公開）（狙い: Docs-as-Code 運用（レビュー / 版管理 / CI / 公開）を実務判断/成果物に落とす）
+- 第11章: ドキュメント品質の守り方（陳腐化対策 / Owner / KPI）（狙い: ドキュメント品質の守り方（陳腐化対策 / Owner / KPI）を実務判断/成果物に落とす）
 
 ## 付録
 

diff --git a/README.md b/README.md
@@ -2,9 +2,9 @@
 
 ## 概要
 
-実務で使える技術ドキュメント成果物（README/手順書/Runbook/ADR/障害報告・ポストモーテム等）の設計と運用を扱う。
+実務で使える技術ドキュメント成果物（README / 手順書 / Runbook / ADR / 障害報告・ポストモーテム等）の設計と運用を扱う。
 
-## オンライン版（公開URL）
+## オンライン版（公開 URL）
 
 - GitHub Pages: `https://itdojp.github.io/engineering-documentation-book/`
 - 入口: `docs/index.md`

diff --git a/_config.yml b/_config.yml
@@ -1,5 +1,5 @@
 title: エンジニアリングドキュメント実践ガイド：README・手順書・Runbook・ADR・ポストモーテム
-description: 実務で使える技術ドキュメント成果物（README/手順書/Runbook/ADR/障害報告・ポストモーテム等）の設計と運用を扱う。
+description: 実務で使える技術ドキュメント成果物（README / 手順書 / Runbook / ADR / 障害報告・ポストモーテム等）の設計と運用を扱う。
 author: 株式会社アイティードゥ
 version: "0.1.0"
 lang: ja

diff --git a/book-config.json b/book-config.json
@@ -1,12 +1,12 @@
 {
   "title": "エンジニアリングドキュメント実践ガイド：README・手順書・Runbook・ADR・ポストモーテム",
-  "description": "実務で使える技術ドキュメント成果物（README/手順書/Runbook/ADR/障害報告・ポストモーテム等）の設計と運用を扱う。",
+  "description": "実務で使える技術ドキュメント成果物（README / 手順書 / Runbook / ADR / 障害報告・ポストモーテム等）の設計と運用を扱う。",
   "author": "株式会社アイティードゥ",
   "version": "0.1.0",
   "metadata": {
     "genre": "技術書 / 実務ドキュメンテーション",
     "targetAudience": [
-      "README/手順書/Runbook/ADR/ポストモーテムを初めて体系化する初級〜中級エンジニア",
+      "README / 手順書 / Runbook / ADR / ポストモーテムを初めて体系化する初級〜中級エンジニア",
       "レビュー観点を揃えたいテックリード/EM",
       "Docs-as-Code を導入したい開発チーム"
     ],
@@ -63,23 +63,23 @@
       },
       {
         "id": "chapter-07",
-        "title": "第7章：Runbook（平常時/異常時/エスカレーション）"
+        "title": "第7章：Runbook（平常時 / 異常時 / エスカレーション）"
       },
       {
         "id": "chapter-08",
         "title": "第8章：ADR（意思決定記録：背景→選択肢→決定→影響）"
       },
       {
         "id": "chapter-09",
-        "title": "第9章：障害報告・ポストモーテム（タイムライン/真因/再発防止）"
+        "title": "第9章：障害報告・ポストモーテム（タイムライン / 真因 / 再発防止）"
       },
       {
         "id": "chapter-10",
-        "title": "第10章：Docs-as-Code運用（レビュー/版管理/CI/公開）"
+        "title": "第10章：Docs-as-Code 運用（レビュー / 版管理 / CI / 公開）"
       },
       {
         "id": "chapter-11",
-        "title": "第11章：ドキュメント品質の守り方（陳腐化対策/Owner/KPI）"
+        "title": "第11章：ドキュメント品質の守り方（陳腐化対策 / Owner / KPI）"
       }
     ],
     "appendices": [

diff --git a/docs/_config.yml b/docs/_config.yml
@@ -1,5 +1,5 @@
 title: エンジニアリングドキュメント実践ガイド：README・手順書・Runbook・ADR・ポストモーテム
-description: 実務で使える技術ドキュメント成果物（README/手順書/Runbook/ADR/障害報告・ポストモーテム等）の設計と運用を扱う。
+description: 実務で使える技術ドキュメント成果物（README / 手順書 / Runbook / ADR / 障害報告・ポストモーテム等）の設計と運用を扱う。
 author: 株式会社アイティードゥ
 version: "0.1.0"
 lang: ja

diff --git a/docs/_data/navigation.yml b/docs/_data/navigation.yml
@@ -13,15 +13,15 @@ chapters:
     path: "/chapters/chapter-05/"
   - title: "第6章：手順書（実行前提/検証/ロールバック/リスク）"
     path: "/chapters/chapter-06/"
-  - title: "第7章：Runbook（平常時/異常時/エスカレーション）"
+  - title: "第7章：Runbook（平常時 / 異常時 / エスカレーション）"
     path: "/chapters/chapter-07/"
   - title: "第8章：ADR（意思決定記録：背景→選択肢→決定→影響）"
     path: "/chapters/chapter-08/"
-  - title: "第9章：障害報告・ポストモーテム（タイムライン/真因/再発防止）"
+  - title: "第9章：障害報告・ポストモーテム（タイムライン / 真因 / 再発防止）"
     path: "/chapters/chapter-09/"
-  - title: "第10章：Docs-as-Code運用（レビュー/版管理/CI/公開）"
+  - title: "第10章：Docs-as-Code 運用（レビュー / 版管理 / CI / 公開）"
     path: "/chapters/chapter-10/"
-  - title: "第11章：ドキュメント品質の守り方（陳腐化対策/Owner/KPI）"
+  - title: "第11章：ドキュメント品質の守り方（陳腐化対策 / Owner / KPI）"
     path: "/chapters/chapter-11/"
 
 appendices:

diff --git a/docs/appendices/templates/adr/index.md b/docs/appendices/templates/adr/index.md
@@ -100,7 +100,7 @@ order: 905
 
 - Issue: `#123`（例）
 - PR: `#456`（例）
-- 参考: SLI/SLO の設計メモ（社内Wiki等）
+- 参考: SLI/SLO の設計メモ（社内 Wiki 等）
 
 ## 具体例（悪い例→良い例）
 
@@ -116,7 +116,7 @@ order: 905
 
 ```md
 背景: 誤検知が多く一次対応が逼迫
-選択肢: A=閾値調整 / B=SLI再設計
+選択肢: A=閾値調整 / B=SLI 再設計
 決定: B（説明責任と誤検知削減を両立）
 影響: ダッシュボード/アラート定義の変更が必要
 未決事項: 通知先ローテーションは別 Issue へ分離

diff --git a/docs/appendices/templates/architecture-diagram/index.md b/docs/appendices/templates/architecture-diagram/index.md
@@ -12,7 +12,7 @@ order: 902
 
 ```mermaid
 flowchart LR
-  %% 境界（社外/社内、VPCなど）
+  %% 境界（社外/社内、VPC など）
   subgraph Internet["社外（インターネット）"]
     User[利用者]
   end
@@ -51,7 +51,7 @@ flowchart LR
   end
   App --> Log
 
-  %% 注釈: 重要な境界（社内/社外、VPC/インターネット）を明示する
+  %% 注釈: 重要な境界（社内/社外、VPC / インターネット）を明示する
 ```
 
 ## 補足（記載観点）

diff --git a/docs/appendices/templates/audit-memo/index.md b/docs/appendices/templates/audit-memo/index.md
@@ -20,7 +20,7 @@ order: 906.5
 
 - 対象文書:
 - 対象章/テンプレート:
-- 対象公開URL:
+- 対象公開 URL:
 - 対象外:
 
 ## 根拠

diff --git a/docs/appendices/templates/ci-minimum/index.md b/docs/appendices/templates/ci-minimum/index.md
@@ -1,12 +1,12 @@
 ---
-title: "最小CIテンプレ（markdownlint + link check）"
+title: "最小 CI テンプレ（markdownlint + link check）"
 layout: book
 order: 909
 ---
 
-# 最小CIテンプレ（markdownlint + link check）
+# 最小 CI テンプレ（markdownlint + link check）
 
-Docs-as-Code の最小CIは「形式チェック（lint）」と「リンク切れ検出」を自動化し、レビュー前に破綻を止めることです。
+Docs-as-Code の最小 CI は「形式チェック（lint）」と「リンク切れ検出」を自動化し、レビュー前に破綻を止めることです。
 
 本リポジトリでは `npm test` が `markdownlint` と `markdown-link-check` を実行する想定です。
 
@@ -67,7 +67,7 @@ jobs:
 
 ### `.markdown-link-check.json`（例）
 
-外部サイトの制限（403/429）や一時的な不安定さでCIが落ちる場合は、必要最小限の ignore を入れて運用する。
+外部サイトの制限（403/429）や一時的な不安定さで CI が落ちる場合は、必要最小限の ignore を入れて運用する。
 
 ```json
 {

diff --git a/docs/appendices/templates/incident-report/index.md b/docs/appendices/templates/incident-report/index.md
@@ -22,7 +22,7 @@ order: 907
 
 ## タイムライン
 
-- 原則: タイムゾーン付き（RFC3339形式）を推奨（例: `2020-01-01T00:00:00+09:00`）
+- 原則: タイムゾーン付き（RFC3339 形式）を推奨（例: `2020-01-01T00:00:00+09:00`）
 - 代替: 相対時刻（00:00 など）を使う場合は、先頭に基準タイムゾーン（JST/UTC）を明記
 
 例:
@@ -84,7 +84,7 @@ order: 907
 ### 良い例
 
 ```md
-事象: 2026-02-23T10:12:00+09:00 決済 API で 5xx/タイムアウトが増加
+事象: 2026-02-23T10:12:00+09:00 決済 API で 5xx / タイムアウトが増加
 影響: 決済 API、10:12〜10:35、最大8%失敗
 タイムライン: 10:12 検知 → 10:25 暫定対応 → 10:35 収束
 暫定対応: 接続プール上限を引き上げ（成功条件: エラー率が基準値に戻る）

diff --git a/docs/appendices/templates/index.md b/docs/appendices/templates/index.md
@@ -38,4 +38,4 @@ order: 900
 - [変更記録（ChangeLog）テンプレ](changelog/)
 - [障害報告テンプレ](incident-report/)
 - [ポストモーテムテンプレ](postmortem/)
-- [最小CIテンプレ（markdownlint + link check）](ci-minimum/)
+- [最小 CI テンプレ（markdownlint + link check）](ci-minimum/)
diff --git a/docs/appendices/templates/postmortem/index.md b/docs/appendices/templates/postmortem/index.md
@@ -35,7 +35,7 @@ order: 908
 
 ## 手順改善
 
-- Runbook/手順書の更新点
+- Runbook / 手順書の更新点
 
 ## フォローアップ管理
 

diff --git a/docs/appendices/templates/readme/index.md b/docs/appendices/templates/readme/index.md
@@ -21,7 +21,7 @@ README は「入口」であり、読者が最短で動かすための情報を
 
 ### 前提
 
-- （例: OS/必要ツール/権限）
+- （例: OS / 必要ツール / 権限）
 
 ### 最小手順
 
@@ -67,13 +67,13 @@ README は「入口」であり、読者が最短で動かすための情報を
 
 ### 依存関係
 
-- 外部サービス、権限、秘密情報（取得手段/保管場所）を明確にする
-- README に秘密情報を直接書かない（値は伏字/参照先リンク）
+- 外部サービス、権限、秘密情報（取得手段 / 保管場所）を明確にする
+- README に秘密情報を直接書かない（値は伏字 / 参照先リンク）
 
 ### 運用
 
-- 定常作業の入口と、障害時の導線（Runbook/手順書/連絡先）を貼る
-- 「誰が/いつ/何をするか」まで落とすと運用で使える
+- 定常作業の入口と、障害時の導線（Runbook / 手順書 / 連絡先）を貼る
+- 「誰が / いつ / 何をするか」まで落とすと運用で使える
 
 ### FAQ
 

diff --git a/docs/appendices/templates/runbook/index.md b/docs/appendices/templates/runbook/index.md
@@ -65,11 +65,11 @@ order: 904
 
 - 初動（確認順）:
   1. 外形確認（主要ユーザー操作が成立するか）
-  2. 直近変更の有無（デプロイ/設定変更/依存サービスの変更）
-  3. 依存関係（DB/キュー/外部API）の健全性
+  2. 直近変更の有無（デプロイ / 設定変更 / 依存サービスの変更）
+  3. 依存関係（DB / キュー / 外部 API）の健全性
 - 切り分け（例）:
-  - 影響範囲を縮小（特定の機能/リージョン/テナントに限定されるか）
-  - 正常時との差分比較（昨日同時刻/直近リリース前）
+  - 影響範囲を縮小（特定の機能 / リージョン / テナントに限定されるか）
+  - 正常時との差分比較（昨日同時刻 / 直近リリース前）
   - ログ/メトリクスでボトルネック候補を列挙する
 
 ### エスカレーション
@@ -90,7 +90,7 @@ order: 904
 
 ### 保守情報
 
-- Owner: SRE/インフラチーム
+- Owner: SRE / インフラチーム
 - 最終確認日: `2026-05-23`
 - 再確認条件:
   - オンコール体制または外部ベンダー窓口が変わった
@@ -106,7 +106,7 @@ order: 904
 ### 連絡先
 
 - オンコール: Slack #oncall / 電話（要組織定義）
-- 主管部署: SRE/インフラ
+- 主管部署: SRE / インフラ
 - 外部ベンダー: 契約窓口（要組織定義）
 
 ## 具体例（悪い例→良い例）
@@ -122,8 +122,8 @@ order: 904
 ### 良い例
 
 ```md
-初動: 1) エラー率 2) 直近変更 3) 依存関係（DB/キュー）
-エスカレーション: 15分以上、復旧見込みなし→IC/主管へ
+初動: 1) エラー率 2) 直近変更 3) 依存関係（DB / キュー）
+エスカレーション: 15分以上、復旧見込みなし→IC / 主管へ
 連絡先: オンコール、主管、外部ベンダー
 保守情報: Owner、最終確認日、再確認条件を明記
 ```
diff --git a/docs/chapters/chapter-01/index.md b/docs/chapters/chapter-01/index.md
@@ -8,8 +8,8 @@ order: 10
 
 ## この章で学ぶこと
 
-- README/手順書/Runbook/ADR/障害報告の使い分け基準を理解する
-- 目的（理解/実行/判断）に応じて成果物を選ぶ
+- README / 手順書 / Runbook / ADR / 障害報告の使い分け基準を理解する
+- 目的（理解 / 実行 / 判断）に応じて成果物を選ぶ
 - 成果物を「マップ」として整理する
 - 監査メモを、修正判断と変更不要判断の証跡として位置づける
 
@@ -21,7 +21,7 @@ order: 10
 
 ## 本文
 
-実務で起きがちな失敗は、成果物が混在すること（例: READMEに運用手順が埋もれる）。まず「何のための文書か」を固定する。
+実務で起きがちな失敗は、成果物が混在すること（例: README に運用手順が埋もれる）。まず「何のための文書か」を固定する。
 
 ### 使い分け（最小）
 
@@ -66,21 +66,21 @@ README は入口に絞る
 - Quick Start
 - 依存/権限
 - 運用導線（Runbook へのリンク）
-デプロイは手順書、障害対応はRunbook/障害報告、判断はADRに分離
+デプロイは手順書、障害対応は Runbook / 障害報告、判断は ADR に分離
 ```
 
 ## チェックリスト
 
-- [ ] 目的（理解/実行/判断）が明確
+- [ ] 目的（理解 / 実行 / 判断）が明確
 - [ ] 成果物が混ざっていない
 - [ ] 入口（README）から導線がある
 - [ ] 変更判断と変更不要判断を残す場所がある
 
 ## まとめ
 
-- 目的（理解/実行/判断）から成果物を選び、1つの文書に混在させない
-- README を入口にし、手順書/Runbook/ADR/障害報告へ導線を用意する
-- 監査メモは「何を確認し、なぜ変更した/しなかったか」を残す成果物として扱う
+- 目的（理解 / 実行 / 判断）から成果物を選び、1つの文書に混在させない
+- README を入口にし、手順書 / Runbook / ADR / 障害報告へ導線を用意する
+- 監査メモは「何を確認し、なぜ変更した / しなかったか」を残す成果物として扱う
 
 ## 次章への接続
 

diff --git a/docs/chapters/chapter-05/index.md b/docs/chapters/chapter-05/index.md
@@ -27,7 +27,7 @@ order: 50
 - フロー: どの順に処理が流れるか
 - シーケンス: 誰が誰に何を送るか
 
-図には「境界（社内/社外、VPCなど）」を必ず入れる。
+図には「境界（社内/社外、VPC など）」を必ず入れる。
 
 ## 具体例（悪い例→良い例）
 
@@ -49,7 +49,7 @@ flowchart LR
   end
 
   subgraph VPC[社内/VPC]
-    Web[Webフロント]
+    Web[Web フロント]
     API[Orders API]
     DB[(DB)]
     Obs[ログ/メトリクス]
@@ -68,7 +68,7 @@ flowchart LR
 
 注釈（最低限）:
 
-- 境界（社内/社外、VPCなど）
+- 境界（社内/社外、VPC など）
 - 認証点（どこで認証/認可するか）
 - ログ出口（どこへ送るか、マスキング方針）
 
@@ -79,7 +79,7 @@ flowchart TD
   A[注文確定] --> B[入力検証]
   B -->|OK| C[決済リクエスト]
   B -->|NG| E[エラー表示（項目別）]
-  C -->|成功| D[注文確定（DB保存）]
+  C -->|成功| D[注文確定（DB 保存）]
   C -->|失敗/timeout| F[再試行案内 or 失敗通知]
 ```
 
@@ -88,7 +88,7 @@ flowchart TD
 ```mermaid
 sequenceDiagram
   actor U as User
-  participant W as Webフロント
+  participant W as Web フロント
   participant A as Orders API
   participant P as 決済プロバイダ
   participant D as DB

diff --git a/docs/chapters/chapter-06/index.md b/docs/chapters/chapter-06/index.md
@@ -45,7 +45,7 @@ order: 60
 
 ```md
 手順: 設定を変えてデプロイする
-検証: 問題なければOK
+検証: 問題なければ OK
 ロールバック: そのとき考える
 ```