itdojp · ootakazuhiko · May 22, 2026 · May 22, 2026
diff --git a/docs/appendices/appendix-resources/index.md b/docs/appendices/appendix-resources/index.md
@@ -17,6 +17,11 @@ order: 102
 | リソース | URL | 内容 | 推奨レベル |
 |---|---|---|---|
 | GitHub Docs | https://docs.github.com/ | 最新の公式ドキュメント | 全レベル |
+| GitHub Docs: 2FA | https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/about-two-factor-authentication | 2要素認証の現在仕様 | 初心者〜中級 |
+| GitHub Docs: Personal access tokens | https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens | fine-grained / classic token の管理 | 中級 |
+| GitHub Docs: Branch protection / rulesets | https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets | PR必須化、status checks、ruleset | 中級 |
+| GitHub Docs: GITHUB_TOKEN | https://docs.github.com/en/actions/concepts/security/github_token | Actions の一時 token と権限 | 中級 |
+| GitHub Docs: Secret scanning | https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning | secret scanning alerts / push protection | 中級 |
 | GitHub Skills | https://skills.github.com/ | インタラクティブ学習コース | 初心者〜中級 |
 | GitHub Training | https://training.github.com/ | 公式トレーニングプログラム | 中級〜上級 |
 | GitHub Community | https://github.community/ | 公式コミュニティフォーラム | 全レベル |

diff --git a/docs/chapters/chapter-account-security/index.md b/docs/chapters/chapter-account-security/index.md
@@ -209,7 +209,19 @@ GitHubへのアクセスに問題がある場合、ネットワーク設定、
 **第2要素：所有認証（Something you have）**
 - スマートフォンアプリで生成されるコード
 - SMS で送信される認証コード
-- ハードウェアトークン
+- セキュリティキー
+- パスキー（passkey）
+
+### 2026-05-23時点の設定方針
+
+GitHub 公式ドキュメントでは、2023年3月以降、GitHub.com でコードを投稿する利用者に 2FA の有効化が求められる運用になっています。初心者でも「あとで設定する」ではなく、アカウント作成直後に 2FA と復旧手段を設定する前提で進めてください。
+
+**推奨する優先順位**
+
+1. パスワードマネージャーで一意なパスワードを管理する。
+2. TOTP 認証アプリ、セキュリティキー、パスキーなど、少なくとも 1 つ以上の強い第2要素を設定する。
+3. バックアップコードをパスワードマネージャーまたは安全な保管場所に保存する。
+4. SMS は使える場面がある一方、電話番号移転や端末紛失の影響を受けやすいため、単独の主要手段にしない。
 
 **認証フロー：**
 ```text
@@ -253,13 +265,13 @@ GitHubの各種設定やローカル環境の問題は、作業効率に大き
 
 GitHubやGitに関連する問題を解決するためには、適切な診断ツールを使用することが重要です。上記のフローチャートに従って、状況に応じたツールを選択しましょう。
 
-### 認証アプリの設定手順
+### 2FA 方式の設定手順
 
-**推奨認証アプリ：**
-- **Google Authenticator**：無料、シンプル、広く対応
-- **Microsoft Authenticator**：Microsoft製品との連携
-- **Authy**：クラウド同期、複数デバイス対応
-- **1Password**：パスワードマネージャーと統合
+**推奨認証方法：**
+- **TOTP 認証アプリ**：Google Authenticator、Microsoft Authenticator、1Password など
+- **セキュリティキー**：物理キーを使った強い認証
+- **パスキー**：対応ブラウザ/OS で、パスワード入力と 2FA を簡略化できる認証方式
+- **SMS**：利用できる場合は補助手段として扱い、主要手段は TOTP / セキュリティキー / パスキーを優先
 
 **設定手順（Google Authenticator の例）：**
 
@@ -659,7 +671,7 @@ Get-Content ~/.ssh/id_rsa.pub
 
 **2段階認証の実装**
 - 2段階認証の仕組みと重要性
-- 認証アプリの設定手順
+- 2FA 方式（TOTP 認証アプリ、セキュリティキー、パスキーなど）の設定手順
 - バックアップコードの適切な管理
 - 緊急時の対応方法
 

diff --git a/docs/chapters/chapter-branch-operations/index.md b/docs/chapters/chapter-branch-operations/index.md
@@ -239,11 +239,26 @@ gh pr create --base <default-branch> --head feat/<topic> --title "..." --body ".
 ```
 
 ### よくある失敗と回避（最小）
+
 - `main` のまま作業してしまう: `git branch --show-current` でブランチ名を確認してから編集する
 - 意図しないファイルまでコミットする: `git status` で差分を確認し、`git add <file>` または `git add -p` を使う
 - `git push` で upstream エラーになる: 初回は `git push -u origin <branch>` を使う
 - PR が肥大化する: 目的を 1 つに絞り、無関係な整形やリファクタを混ぜない
 
+### PRをマージする前の最小ゲート
+
+Pull Request は「作ったら終わり」ではありません。初心者向けの最小ゲートとして、少なくとも次を確認してからマージします。
+
+| ゲート | 確認すること | 証跡の残し方 |
+| --- | --- | --- |
+| 目的と範囲 | PR が 1 つの目的に絞られている | PR body に概要、変更範囲、関連 Issue を書く |
+| レビュー | 指摘本文、inline comment、suggestion を全件確認した | 修正した場合は返信し、不要な場合は理由を書く |
+| conversation | 未解決の review thread が残っていない | GitHub 上で Resolve / Unresolve の状態を確認する |
+| CI | 必須チェックが成功している | Checks タブで失敗 job がないことを確認する |
+| merge 後 | main のチェックと公開先に反映された | merge 後の Actions / Pages / 動作確認を Issue に記録する |
+
+ブランチ保護や ruleset を使うと、レビュー、status checks、conversation resolution などをマージ条件として機械的に要求できます。個人学習では任意ですが、チーム開発では早めに導入すると事故を減らせます。
+
 ### 作業用ブランチの削除
 
 マージが完了したら、不要になった作業用ブランチを削除できます：
@@ -260,7 +275,7 @@ gh pr create --base <default-branch> --head feat/<topic> --title "..." --body ".
 
 ---
 
-## 7.4 コンフリクト（競合）の理解と解決
+## 7.4 PRレビューと運用（テンプレート / CODEOWNERS）
 
 ### PRテンプレートの構造
 
@@ -284,24 +299,71 @@ AI 支援の運用ルール（機密入力の禁止、確認観点など）は
 
 - AI利用ポリシー（テンプレ）：https://github.com/{{ site.repository }}/blob/main/AI_USAGE_POLICY.md
 
+### PRレビュー状態
+
+![PRレビュー状態]({{ '/assets/images/diagrams/chapter08/05_pr_review_states.svg' | relative_url }})
+
+Pull Requestのレビュープロセスでは、様々な状態があります。各状態の意味を理解し、適切なアクションを取ることが重要です。
+
+### PRディスカッション管理
+
+![PRディスカッション管理]({{ '/assets/images/diagrams/chapter08/06_pr_discussion_management.svg' | relative_url }})
+
+Pull Requestでのディスカッションを効果的に管理することで、チーム全体のコミュニケーション品質と開発効率を向上させましょう。
+
+### AI生成PRのレビュー観点（最小セット）
+
+AI生成のPull Requestは「速く作れる」一方で、意図・検証・安全性が省略されがちです。レビューでは「AIが作ったか」ではなく、次の観点で確認すると、主観ではなく手順として運用できます。
+
+- **変更意図の一致**：Issueの背景/目的・受入基準に一致しているか
+- **検証の証跡**：テスト結果や手動確認手順（ログ/スクリーンショット）が残っているか
+- **差分の過剰さ**：関係ないリファクタやフォーマット変更が混ざっていないか
+- **依存関係/設定変更**：更新理由と影響（リスク）が説明されているか
+- **Secrets/個人情報**：トークン・秘密鍵・顧客情報・ログの貼付がないか
+- **ロールバック可能性（例：`git revert`で戻しやすいか）**：PRが小さく、ロールバック手順が明記されているか
+
+これらは、PRテンプレート（`.github/PULL_REQUEST_TEMPLATE.md`）のチェック欄としても運用できます。
+
 ### CODEOWNERSでレビュー担当を自動で割り当てる（発展）
 
 チームで運用する場合、「誰がレビュー責任を持つか」を仕組みで決めておくと、レビューが詰まりにくくなります。その代表例が **CODEOWNERS** です。
 
 - 設定ファイル: `.github/CODEOWNERS`
 - できること: 特定のパス（例：`docs/`）の変更が入ったときに、担当者（ユーザー/チーム）へレビュー依頼を自動化できる
 
-このリポジトリでは、`manuscript/**`（本文）と `src/**`（元原稿）を例として `CODEOWNERS` に記載しています。自分のプロジェクトで使う場合は、まずは **「docs/ は文書担当」** だけ決めると運用しやすくなります。
+このリポジトリでは、例として `manuscript/**`（本文）・`docs/**`（公開サイト）・`src/**`（元原稿）を `CODEOWNERS` に記載しています。自分のプロジェクトで使う場合は、まずは **「docs/ は文書担当」** だけ決めると運用しやすくなります。
+
+また、`CODEOWNERS` は **パターンの順序が重要**で、複数マッチする場合は「最後にマッチした行」が優先されます。
 
 **レビューが詰まるときの対処（例）**
 - 代替担当（バックアップ）を決め、CODEOWNERSに追加する
 - ローテーション（当番表）で担当を回す（人に依存しない）
 - 必須レビュー数や必須チェック（CI）と組み合わせ、例外運用の手順も決める
 
-### コンフリクトが発生する原因
+### PRマージ戦略
+
+![PRマージ戦略]({{ '/assets/images/diagrams/chapter08/07_pr_merge_strategies.svg' | relative_url }})
+
+Pull Requestをマージする際には、様々な戦略があります。プロジェクトのポリシーや履歴管理の方針に応じて、適切なマージ戦略を選択しましょう。
+
+### PR自動化ツール
+
+![PR自動化ツール]({{ '/assets/images/diagrams/chapter08/08_pr_automation_tools.svg' | relative_url }})
+
+効率的なチーム開発のために、PRプロセスの一部を自動化することができます。CI/CD、自動テスト、コード品質チェックなどのツールを活用しましょう。
+
+### ブランチワークフローパターン（参考）
+
+![ブランチワークフローパターン]({{ '/assets/images/diagrams/chapter06/16_branch_workflow_patterns.svg' | relative_url }})
+
+---
+
+## 7.5 コンフリクト（競合）の理解と解決
 
 コンフリクト（競合）は、同じファイルの同じ箇所が、異なるブランチで別々の内容に変更された場合に発生します。
 
+### コンフリクトが発生する原因
+
 **発生例：**
 ```text
 main ブランチ：
@@ -369,18 +431,6 @@ Welcome to Our Website (mainブランチの内容)
 - GitHub Desktopで「Mark as resolved」
 - 「Continue merge」でマージ完了
 
-### PRレビュー状態
-
-![PRレビュー状態]({{ '/assets/images/diagrams/chapter08/05_pr_review_states.svg' | relative_url }})
-
-Pull Requestのレビュープロセスでは、様々な状態があります。各状態の意味を理解し、適切なアクションを取ることが重要です。
-
-### PRディスカッション管理
-
-![PRディスカッション管理]({{ '/assets/images/diagrams/chapter08/06_pr_discussion_management.svg' | relative_url }})
-
-Pull Requestでのディスカッションを効果的に管理することで、チーム全体のコミュニケーション品質と開発効率を向上させましょう。
-
 ### コンフリクト予防のベストプラクティス
 
 **1. 頻繁なマージ**
@@ -399,20 +449,6 @@ Pull Requestでのディスカッションを効果的に管理することで
 - 機能ごとにファイルを分離
 - 共通部分の変更は慎重に
 
-### PRマージ戦略
-
-![PRマージ戦略]({{ '/assets/images/diagrams/chapter08/07_pr_merge_strategies.svg' | relative_url }})
-
-Pull Requestをマージする際には、様々な戦略があります。プロジェクトのポリシーや履歴管理の方針に応じて、適切なマージ戦略を選択しましょう。
-
-### PR自動化ツール
-
-![PR自動化ツール]({{ '/assets/images/diagrams/chapter08/08_pr_automation_tools.svg' | relative_url }})
-
-効率的なチーム開発のために、PRプロセスの一部を自動化することができます。CI/CD、自動テスト、コード品質チェックなどのツールを活用しましょう。
-
-![ブランチワークフローパターン]({{ '/assets/images/diagrams/chapter06/16_branch_workflow_patterns.svg' | relative_url }})
-
 ---
 
 ## まとめ
@@ -447,7 +483,7 @@ Pull Requestをマージする際には、様々な戦略があります。プ
 
 ![PR品質ゲート]({{ '/assets/images/diagrams/chapter08/10_pr_quality_gates.svg' | relative_url }})
 
-コード品質を維持するために、PRに品質ゲートを設定しましょう。自動テスト、コードレビュー、セキュリティチェックなどを組み合わせた包括的な品質管理が可能です。
+コード品質を維持するために、PRに品質ゲートを設定しましょう。自動テスト、コードレビュー、セキュリティチェックに加えて、未解決の review thread が 0 件であること、必須 status checks 成功、merge 後確認を組み合わせると、変更の説明責任を保ちやすくなります。
 
 ### PRメトリクス分析
 

diff --git a/docs/chapters/chapter-github-actions/index.md b/docs/chapters/chapter-github-actions/index.md
@@ -116,6 +116,24 @@ jobs:
 - `uses:` は「既製品（action）を呼び出す」指定です（例: `actions/checkout`）
 - `run:` は「シェルコマンドを実行する」指定です（例: `npm ci`）
 
+### `GITHUB_TOKEN` と権限の最小化
+
+workflow の各 job では、GitHub が一時的な `GITHUB_TOKEN` を自動発行します。通常の CI では、まず読み取り中心の権限から始め、必要な job だけに追加権限を与えます。
+
+```yaml
+permissions:
+  contents: read
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v6
+      - run: npm test
+```
+
+Pull Request へコメントを書く、Pages へデプロイする、packages を発行するなどの操作では追加権限が必要です。その場合も、workflow 全体へ広い権限を付けるのではなく、対象 job に必要な権限だけを付与します。
+
 ### つまずきやすい点（npm）
 
 - `npm ci` は `package-lock.json` がある前提です。ない場合は `npm install` を使うか、ロックファイルを作成してください。
@@ -167,6 +185,7 @@ YAML はインデント（空白）に敏感です。コピペ後に動かない
 
 - **Secrets をログに出さない**: `echo` や `set -x`（シェルのデバッグ出力）で漏洩しやすくなります。
 - **fork からの Pull Request**: 原則として Secrets は渡りません（安全のため）。この制約を回避しようとして危険なトリガー（例: `pull_request_target`）を安易に使わないでください。
+- **AI/外部サービスへログを貼らない**: 失敗ログにはトークン、URL、内部パス、顧客情報が混ざることがあります。共有前にマスクし、必要最小限だけ貼り付けます。
 
 ### ログの読み方（最短）