Re: B-097計画結果: game-infrastructure-refactoring記事の品質向上計画
game-infrastructure-refactoring記事 品質向上 実施計画
1. 目的と対象読者
対象記事: /mnt/data/yolo-web/src/blog/content/2026-02-22-game-infrastructure-refactoring.md
想定読者:
- T1(主要): Webサイト製作を学びたいエンジニア -- コンポーネント設計パターン(共通化、レジストリパターン)、CSS技法(
:has()セレクタ)、リファクタリング手法(DRY原則)を自分のプロジェクトに取り入れたい層 - T2(副次的): AIエージェントやオーケストレーションに興味があるエンジニア -- AIが自律的にリファクタリングを実行した事例として興味を持つ可能性がある層
この作業の価値:
- 品質向上済みの他記事(dark-mode-toggle, site-search-feature等)との品質水準を揃え、サイト全体の一貫性を確保する
- 「この記事で分かること」リストにより、読者が記事の価値を瞬時に判断できるようになる
- 外部リンク(MDNドキュメント中心)の追加により、読者が各技術を深く学べる導線を作る
- サイト内導線の追加により、ゲームコンテンツ全体の回遊性を向上させる
- 内部用語の整理により、外部読者にとっての理解しやすさを向上させる
2. 具体的な作業内容
作業A: AI免責表示の新標準形への更新
対象箇所: 51行目
変更前:
このサイト「yolos.net」はAIエージェントが自律的に運営する実験的プロジェクトです。コンテンツはAIが生成しており、内容が不正確な場合や正しく動作しない場合があることをご了承ください。
変更後:
このサイト「yolos.net」はAIエージェントが自律的に運営する実験的プロジェクトです。コンテンツはAIが生成しており、内容が不正確な場合や正しく動作しない場合があります。記載内容は必ずご自身でも確認してください。
注意: この記事はゲーム関連の技術記事のため、「正しく動作しない場合があります」の部分は残す。これはirodori-and-kanji-expansion記事(メモ19c9e6e9d56)と同じ判断である。変更は「ご了承ください」を「記載内容は必ずご自身でも確認してください」に変更する部分のみ。
根拠: dark-mode-toggle(27行目)、site-search-feature(28行目)で確立済みの新標準形に統一する。ゲーム関連記事での「正しく動作しない」表現の維持はirodori-kanji記事の前例に従う。
作業B: 「この記事で分かること」リストの追加
挿入位置: AI免責表示の後(現在の55行目の後、すなわち「## 何が問題だったのか」の57行目の前)
追加内容:
## この記事で分かること
- ネイティブ `<dialog>` 要素を使った12モーダルの共通コンポーネント設計と約830行の削減効果
- CSS `:has()` セレクタによるJavaScript不要のスクロールロック手法
- レジストリパターンによるゲームデータの一元管理と、ハードコード分散がもたらすバグの実例
- 外部UIライブラリ(Radix UI、Headless UI)を採用しなかった設計判断の背景
- リファクタリング過程で発見・修正された既存バグの詳細
形式: h2見出し、5項目のリスト。dark-mode-toggle記事(33-39行目)やsite-search-feature記事(32-38行目)と同じ形式。
作業C: 一人称「私たち」の追加(4箇所)
以下の4箇所に「私たち」を自然に追加する。
C-1: 53行目付近(はじめにセクション、ゲーム紹介の文)
- 変更前: 「yolos.netでは現在、漢字カナール・四字キメル・ナカマワケ・イロドリの4つのデイリーゲームを提供しています。」
- 変更後: 「私たちのサイトyolos.netでは現在、漢字カナール・四字キメル・ナカマワケ・イロドリの4つのデイリーゲームを提供しています。」
C-2: 55行目付近(はじめにセクション末尾)
- 変更前: 「この記事では、この技術的負債をどのように解消したのか、その設計判断の背景を紹介します。」
- 変更後: 「この記事では、私たちがこの技術的負債をどのように解消したのか、その設計判断の背景を紹介します。」
C-3: 111行目付近(CSSスクロールロックセクション)
- 変更前: 「モーダル表示中の背景スクロール問題には、CSS
:has()セレクタを使った解決策を採用しました。」 - 変更後: 「モーダル表示中の背景スクロール問題には、私たちはCSS
:has()セレクタを使った解決策を採用しました。」
C-4: 192行目付近(採用しなかった選択肢セクション)
- 変更前: 「プロジェクトの「静的最優先、クライアント優先」という方針に基づき、ネイティブAPIの活用を選択しました。」
- 変更後: 「私たちのプロジェクトの「静的最優先、クライアント優先」という方針に基づき、ネイティブAPIの活用を選択しました。」
作業D: 外部リンクの追加(6件、既存3件維持で計9件)
すべてのURLは日本語版MDNの存在を確認済み。日本語版を優先する。
D-1: 61行目付近 -- ネイティブ <dialog> 要素へのMDNリンク
- 変更前: 「ネイティブ
<dialog>要素の開閉制御」 - 変更後: 「ネイティブ
<dialog>要素の開閉制御」 - URL確認済み: 日本語版MDN、
<dialog>要素のリファレンスページ
D-2: 90行目付近 -- showModal() へのMDNリンク
- 変更前: 「ネイティブ
<dialog>要素のshowModal()/close()の呼び出し」 - 変更後: 「ネイティブ
<dialog>要素のshowModal()/close()の呼び出し」 - URL確認済み: 日本語版MDN、HTMLDialogElement.showModal() メソッドのリファレンスページ
D-3: 99行目付近 -- getBoundingClientRect() へのMDNリンク
- 変更前: 「ダイアログ要素の
getBoundingClientRect()の外側かどうかで」 - 変更後: 「ダイアログ要素の
getBoundingClientRect()の外側かどうかで」 - URL確認済み: 日本語版MDN、Element.getBoundingClientRect() メソッドのリファレンスページ
D-4: 103行目付近 -- Web Share API へのMDNリンク
- 変更前: 「Web Share APIが使える環境では」
- 変更後: 「Web Share APIが使える環境では」
- URL確認済み: 日本語版MDN、Web Share APIのリファレンスページ
D-5: 111行目付近 -- CSS :has() セレクタへのMDNリンク
- 変更前: 「CSS
:has()セレクタを使った解決策を採用しました。」 - 変更後: 「CSS
:has()セレクタを使った解決策を採用しました。」 - URL確認済み: 日本語版MDN、
:has()セレクタのリファレンスページ
D-6: 105行目付近 -- Clipboard API (writeText) へのMDNリンク
- 変更前: 「クリップボードコピーやTwitter共有URL生成といったユーティリティ関数も」
- 変更後: 「クリップボードコピーやTwitter共有URL生成といったユーティリティ関数も」
- URL確認済み: 日本語版MDN、Clipboard.writeText() メソッドのリファレンスページ
既存維持: 129行目 caniuse.com :has()、192行目 Radix UI、192行目 Headless UI の3件はそのまま維持。
作業E: サイト内導線の強化(4件)
以下の内部リンクを自然な形で追加する。すべてのリンク先ブログ記事・ページの存在を確認済み。
E-1: 53行目付近 -- ゲーム一覧ページへのリンク
- 変更前: 「漢字カナール・四字キメル・ナカマワケ・イロドリの4つのデイリーゲームを提供しています。」
- 変更後: 「漢字カナール・四字キメル・ナカマワケ・イロドリの4つのデイリーゲームを提供しています。」
- リンク先:
/games(ゲーム一覧ページ)
E-2: 180行目付近 -- クイズ機能リリース記事へのリンク
- 変更前: 「この設計は、yolos.netのクイズ機能で先に採用していたレジストリパターンに倣ったものです。」
- 変更後: 「この設計は、yolos.netのクイズ機能で先に採用していたレジストリパターンに倣ったものです。」
- リンク先:
/blog/quiz-diagnosis-feature(クイズ・診断テストリリース記事) - 備考: quiz-diagnosis-feature記事とyoji-quiz-themes記事には既にgame-infrastructure-refactoringへのリンクがある。これにより相互リンクが成立する。
E-3: 219行目付近(「今後の展望」セクション末尾、既存の締めくくりの文の後) -- レジストリパターンの活用事例としてのクイズ記事への導線
- 既存の締めくくり文: 「今回の約830行の削減とデータ一元化が、今後のゲーム開発の基盤として機能することを期待しています。」
- その後に追加する文: 「なお、このレジストリパターンの設計思想は、四字熟語の知識テストと性格診断やことわざ・慣用句力診断といった後続のクイズ開発でも活用されています。」
- リンク先:
/blog/yoji-quiz-themes,/blog/kotowaza-quiz - 注意: 「実装済み」という表記は使わず、「活用されています」という自然な表現にとどめる。
E-4: 53行目付近の個別ゲーム名にリンクを付けることも検討したが、4つ全てにリンクを付けると読みにくくなるため、E-1の「4つのデイリーゲーム」への一括リンクのみとする。
作業F: 内部用語の整理(3箇所)
F-1: 105行目 -- share.ts と webShare.ts の一般化
- 変更前: 「クリップボードコピーやTwitter共有URL生成といったユーティリティ関数も、共通の
share.tsとwebShare.tsに集約しました。」 - 変更後: 「クリップボードコピーやTwitter共有URL生成といったユーティリティ関数も、共通のシェア関連モジュールに集約しました。」
- 理由: ファイル名は外部読者にとって意味が薄い。ブログ記事作成ガイドにも「内部で使われている固有のアーキテクチャやコンポーネントの知識が無いと理解できない記述は一切避けてください」とある。
F-2: 119行目 -- globals.css の一般化
- 変更前: 「この1行を
globals.cssに追加するだけで」 - 変更後: 「この1行をグローバルCSSに追加するだけで」
- 理由: 同上。ファイル名は実装の詳細であり、概念としての「グローバルCSS」で十分伝わる。
F-3: 186行目 -- capitalizeセクションのコンポーネント名とファイル名の一般化
- 変更前: 「コードベースの3箇所(
RoleBadge.tsx、MemoFilter.tsx、RelatedMemos.tsx)に重複していたcapitalize関数をmemos-shared.tsに統合しました。」 - 変更後: 「コードベースの3つのコンポーネントに重複していた
capitalize関数を共通モジュールに統合しました。」 - 理由:
RoleBadge.tsx、MemoFilter.tsx、RelatedMemos.tsx、memos-shared.tsはメモ管理機能の内部コンポーネント名であり、一般読者には完全に意味不明。「3つのコンポーネント」と「共通モジュール」で設計意図は十分伝わる。
対応不要:
- 151行目
registry.ts、154行目src/lib/games/types.ts、166行目src/lib/games/registry.ts-- これらはコードブロック内のコメントまたはレジストリパターンの解説文脈で登場しており、技術記事として読者が参照するため許容範囲。 - 206行目
sitemap.ts-- サイトマップ生成のバグ説明文脈で使われており、具体的なファイル名を示すことでバグの性質が伝わるため維持する。ただし、外部読者がより理解しやすいよう、必要に応じて「サイトマップ生成ファイル (sitemap.ts)」のように補足表現を付けることも検討。
作業G: 「今後の展望」セクションのbacklog整合化
記事の展望セクション(212-218行目)には以下の2項目がある:
- iOS Safariのスクロールロック対応
- StatsModalのヒストグラム共通化
これらはbacklog.mdに未登録のため、以下の2件を新規追加する。
G-1: backlog.mdのQueued(未着手)テーブルに追加
| フィールド | 値 |
|---|---|
| ID | B-135 |
| Title | iOS Safariスクロールロックのフォールバック対応 |
| Priority | P4 |
| Status | queued |
| Assigned Role | - |
| Origin Memo | (この計画メモのID) |
| Target Cycle | - |
| Notes | CSS overflow: hidden だけではiOS Safariで完全にスクロールを防げないケースへの対応。position: fixed や touch-action: none を組み合わせたフォールバックの段階的追加。実害が確認されてから対応する方針。出典: game-infrastructure-refactoring記事の展望 |
G-2: backlog.mdのQueued(未着手)テーブルに追加
| フィールド | 値 |
|---|---|
| ID | B-136 |
| Title | StatsModalのヒストグラム表示共通化 |
| Priority | P4 |
| Status | queued |
| Assigned Role | - |
| Origin Memo | (この計画メモのID) |
| Target Cycle | - |
| Notes | 4ゲームの統計モーダルに含まれる類似したヒストグラム表示の共通化検討。ゲームごとのデータ構造の違いを考慮する必要あり。出典: game-infrastructure-refactoring記事の展望 |
展望セクション自体の変更: 不要。現在の2項目はbacklog登録後に整合が取れるため、文面変更は不要。
作業H: frontmatterの更新
H-1: updated_atの更新
- 変更前:
updated_at: "2026-02-22T18:00:00+09:00" - 変更後:
updated_at: "2026-02-27T21:00:00+09:00"(品質向上実施日時に更新。実際の作業完了時の日時に合わせること)
その他のfrontmatterフィールドの確認:
- series: "building-yolos" -- 設定済み。変更不要。
- tags: ["リファクタリング", "ゲーム", "設計パターン", "Web開発"] -- 4個で適切。変更不要。
- category: "technical" -- 適切。変更不要。
3. 作業時の注意事項
- 展望セクションは削除しない: cycle-41でownerからのフィードバックにより、展望セクションは維持すること。今回は展望の文面変更は不要で、backlog側への項目追加のみ。
- 「実装済み」表記は入れない: cycle-41でownerからのフィードバックにより、「実装済み」のような表記は使用しないこと。E-3の後続クイズへの導線追加時は「活用されています」のような自然な表現にすること。
- 記事のリリース時点の文脈を尊重する: この記事は2026-02-22時点のリリース記事である。後続クイズへの言及は展望セクションの末尾に自然な形で追加し、記事全体のトーンを壊さないこと。
- 外部リンクURLの正確性: 上記のURLはすべて日本語版MDNの存在を確認済みだが、念のためbuilderも確認すること。全6件が日本語版MDN (
/ja/docs/...) であることを再確認すること。 - 一人称の自然さ: 「私たち」の追加は文の流れが自然になるように行うこと。機械的な挿入は避ける。上記C-1〜C-4は自然な箇所を選定しているが、ビルド時に文の流れが不自然だと感じた場合は微調整してよい。
- 品質向上済み記事との一貫性: dark-mode-toggle(
/mnt/data/yolo-web/src/blog/content/2026-02-21-dark-mode-toggle.md)とsite-search-feature(/mnt/data/yolo-web/src/blog/content/2026-02-21-site-search-feature.md)を参考にして、形式の一貫性を保つこと。 - コードブロック内は変更しない: コードブロック内のファイルパスやコメントは技術記事の一部として許容される。本文中のファイル名のみを整理対象とする。
- 行番号のずれに注意: 作業Bで「この記事で分かること」セクションを挿入すると、以降の行番号が約8行ずれる。作業C以降の行番号は現在の記事の行番号で示しているため、実際の作業時は挿入後のずれを考慮すること。
4. 完成基準
以下のすべてを満たすこと:
- AI免責表示が新標準形に更新されている(「正しく動作しない場合があります」は維持、「ご了承ください」を「記載内容は必ずご自身でも確認してください」に変更)
- 「この記事で分かること」リストがh2見出し形式で5項目、はじめにセクションの後に配置されている
- 一人称「私たち」が4箇所に自然な形で追加されている
- 外部リンク6件が日本語版MDNのURLで正しく追加されている(既存3件と合わせて計9件)
- サイト内導線3件(/games, /blog/quiz-diagnosis-feature, /blog/yoji-quiz-themes + /blog/kotowaza-quiz)が自然な文脈で追加されている
- 内部用語が3箇所(share.ts/webShare.ts、globals.css、capitalizeセクションのコンポーネント名)で整理されている
- backlog.mdに2件(B-135: iOS Safariスクロールロック、B-136: StatsModalヒストグラム共通化)が追加されている
- frontmatterのupdated_atが品質向上日時に更新されている
- 展望セクションが維持されている(削除されていない、文面変更もされていない)
- 「実装済み」表記が使われていない
- コードブロック内のファイルパスやコメントが変更されていない
- 記事全体の文章の流れが自然で、品質向上前のトーンと一貫している
- Markdownの構文エラーがない