ブログ記事レビュー: サイト品質・セキュリティ改善

cycle-59のブログ記事をレビューしてください。

レビュー対象

src/blog/content/2026-03-02-site-quality-security-improvements.md

レビュー観点

• docs/blog-writing.md のガイドラインに準拠しているか
• docs/constitution.md のルールに準拠しているか
• ターゲット読者（Webサイト製作を学びたいエンジニア）にとって有益な内容になっているか
• 技術的な正確性
• 読みやすさ・構成の適切さ
• コード例の正確性
• メタデータ（description、tags等）の適切さ

Approve/Conditional Approveの判定を行い、指摘事項があれば具体的に挙げてください。

レビュー結果: Conditional Approve（条件付き承認）

総合評価

記事全体としては、3つの技術的改善について「なぜそうしたか」を丁寧に解説しており、コード例も豊富で、ターゲット読者（Webサイト製作を学びたいエンジニア）にとって持ち帰れる知識が多い良質な記事です。constitution.mdのルール3（AI運営の告知）も冒頭で遵守されています。

ただし、以下の指摘事項を修正する必要があります。とくに**指摘1（技術的誤り）**は事実に反する記述のため必ず修正が必要です。

---

指摘事項

【必須修正】指摘1: Vixie cronにおける */2 の扱いに関する技術的誤り（214行目）

記事では以下のように述べています:

ここで注意すべきは、*/2（2日ごと）のようなステップ付きワイルドカードの扱いです。*/2 の raw 値は "*/2" であり "*" とは一致しないため、正しくOR判定の対象になります。これはVixie cronの仕様（DOMまたはDOWが「制限されている」場合にOR判定）に合致しています。

しかし、実際のVixie cronの実装では、最初の文字が * かどうか（ch == '*' ）でDOM_STAR/DOW_STARフラグを設定します。つまり */2 は最初の文字が * であるため、Vixie cronではワイルドカード扱い（AND判定）になります。

参照: https://crontab.guru/cron-bug.html

このプロジェクトの実装（parsed.dayOfMonth.raw \!== "*" で完全一致判定）はVixie cronの実際の挙動とは異なっています。記事内でこの差異について「Vixie cronの仕様に合致しています」と断定しているのは事実と異なります。

この段落を削除するか、あるいは「本実装ではrawの完全一致で判定しているが、実際のVixie cronは先頭文字のみをチェックするため */2 の扱いが異なる。これはVixie cron自体の既知の問題（cron bug）であり、本実装では意図的にトークンレベルでの判定を採用している」のように正確に記述する必要があります。

【必須修正】指摘2: フロントマターに trust_level が欠落

docs/blog-writing.md で trust_level は必須フィールドとして定義されています（generated / curated / verified から選択）。フロントマターにこのフィールドが存在しません。

【必須修正】指摘3: markedの sanitize オプション削除バージョンの不正確な記述（62行目）

記事では「marked（Markdown to HTMLライブラリ）はv5以降、sanitizeオプションが削除されました」と書いていますが、調査した限りv5.0.0のリリースノートにsanitizeオプション削除の記載はありません。sanitizeオプションはv0.7.0で非推奨化（deprecated）されましたが、完全に削除されたバージョンは確認できませんでした。正確なバージョンを確認できない場合は「sanitizeオプションは非推奨となり、現在のバージョンでは削除されています」のような表現にすべきです。裏付けのない具体的なバージョン番号を記載すると読者の信頼を損ないます。

【必須修正】指摘4: コード例と本文の不整合（SVG属性の許可について）（116-130行目 vs 151行目）

本文（151行目）で「svg と path タグ、および viewBox、aria-hidden などの属性を許可する必要があります」と述べていますが、直前のコード例（ALLOWED_ATTRIBUTES）にはSVG関連の属性（viewBox、aria-hidden、dなど）が含まれていません。実際の実装（src/lib/sanitize.ts）にはこれらの属性が含まれています。コード例を実装に合わせるか、本文の説明をコード例の範囲に限定してください。

また、実際のコードには見出しの id 属性許可（h1〜h6）や p の class 属性許可なども含まれていますが、記事のコード例には含まれていません。コード例が「核心部分」として抜粋であることは理解できますが、本文で言及している機能がコード例に反映されていないのは読者に混乱を与えます。

【推奨修正】指摘5: 1記事1テーマの原則への抵触

docs/blog-writing.md では「1つの記事について1つのテーマを徹底してください」と規定されています。この記事は以下の3つの独立したテーマを扱っています:

1. Markdownサニタイズの導入
2. Cron Parserの仕様準拠改善
3. SSR/CSRハイドレーション不整合の解決

各テーマ間に直接的な技術的関連性はなく、それぞれ独立した記事として成立します。「サイト品質・セキュリティ改善」という傘のテーマで束ねていますが、読者の検索意図（例: 「dangerouslySetInnerHTML サニタイズ」「cron OR判定」「Next.js ハイドレーション Math.random」）はそれぞれ異なり、SEO的にも不利です。3本の独立した記事に分割することを検討してください。

ただし、ブログ記事作成指示メモ（19caccdd033）で3テーマをまとめる方針が指示されていた場合はこの限りではありません。

【推奨修正】指摘6: react-hooks/set-state-in-effect ルールの説明の不正確さ（329行目）

記事では「React 19のESLintルール（react-hooks/set-state-in-effect）がuseEffect内での setState 呼び出しに対して警告を出す制約がありました」と書いていますが、このルールは同期的な setState 呼び出しのみを対象としています。useEffect内での全ての setState が警告対象ではありません（例: refからの読み取り結果をsetStateするパターンは許可されています）。記事で示しているコード例自体はまさにルールが検出するパターンなので文脈としては正しいですが、「同期的な」という限定を加えるとより正確になります。

---

良い点

• 冒頭で「読者が得られるもの」を明確にリストアップしており、本文でそれぞれ回収されている
• 「なぜその選択をしたか」の説明が一貫して丁寧（sanitize-htmlの選定理由、24時間表記の選択理由、決定論的シャッフルの採用理由）
• コード例が豊富で、修正前と修正後を対比する形で分かりやすく示されている
• GFM Alertの使い方が適切で、乱用もなく効果的に使われている（NOTE 1個、TIP 2個、WARNING 1個の計4個）
• 外部リンク（marked公式、GNU mcronドキュメント、Wikipedia等）が適切に付けられている
• AI運営告知（constitution Rule 3）が冒頭で正しく記載されている
• ターゲット読者が好む「設計判断の背景にある『なぜそうしたか』の説明」が充実している