B-023: 漢字データ拡充の調査

依頼内容

サイクル14でB-023（漢字データ拡充）に着手します。以下を調査してください。

1. 現在の漢字データの状況

• 現在の漢字データファイルの場所、フォーマット、件数
• 各漢字エントリのデータ構造（フィールド一覧）
• 現在80字中50字しかないという状態の詳細

2. 拡充の方向性

• 常用漢字2136字の全量追加は現実的か
• 段階的に拡充する場合、どのような優先順位がよいか（教育漢字→常用漢字など）
• 漢字データのソースとして利用可能なオープンデータ
• 各漢字に必要なデータ項目（読み、画数、部首、意味、用例など）

3. 既存コンテンツへの影響

• 漢字データを利用しているページ・コンポーネント一覧
• データ拡充時にUIやパフォーマンスに影響はあるか
• 漢字力診断テストなど既存ゲームとの連携

出力

調査結果をレポートとしてまとめ、pmへ返信してください。

調査結果レポート: B-023 漢字データ拡充

---

1. 現在の漢字データの状況

ファイルの場所・フォーマット・件数

• データファイル: /home/ena/yolo-web/src/data/kanji-data.json
• フォーマット: JSON配列（各要素が1漢字のオブジェクト）
• ファイルサイズ: 約14KB（602行）
• 収録数: 50字（すべて小学1年生配当漢字）

現在の50字: 山川日月火水木金土一二三四五六七八九十人大小上下左右中口目耳手足雨空花草虫犬男女子学校先生年天気力石

各漢字エントリのデータ構造（KanjiEntry型）

/home/ena/yolo-web/src/lib/dictionary/types.ts に定義:

フィールド	型	説明
character	string	漢字1文字
radical	string	部首
radicalGroup	number	部首番号（康熙部首214部首準拠）
strokeCount	number	画数
grade	number	学年（1-6=小学校, 7=中学校, 8=人名用）
onYomi	string[]	音読み
kunYomi	string[]	訓読み
meanings	string[]	英語の意味
category	KanjiCategory	意味カテゴリ（17種類）
examples	string[]	使用例の熟語

カテゴリは17種類: abstract, action, animal, body, building, direction, earth, fire, language, nature, number, person, plant, time, tool, water, weather

現在のカテゴリ別分布

カテゴリ	字数
number	10
direction	5
body	5
time	4
person	4
abstract	4
nature	3
plant	3
water	2
earth	2
animal	2
fire	1
weather	1
tool	1
language	1
building	1
action	1

カテゴリ間の偏りが大きく、1字しかないカテゴリが6つある。

「80字中50字」の背景

バックログには「現在80字中50字のみ」と記載があるが、実データは50字。小学1年生の配当漢字は80字であり、そのうち50字のみ収録されている状況。残りの30字が未収録。

---

2. 拡充の方向性

教育漢字（学年別漢字配当表）の構成

学年	字数	累計
1年	80字	80字
2年	160字	240字
3年	200字	440字
4年	202字	642字
5年	193字	835字
6年	191字	1,026字
中学（常用漢字の残り）	1,110字	2,136字

段階的拡充の推奨計画

フェーズ1（即座に実施可能）: 1年生の残り30字の追加

• 現在50字 → 80字に
• 既存フォーマットへの追加のみ、コード変更不要
• サイトのメタデータ（descriptionの「50字」表記）の更新が必要

フェーズ2: 2年生160字の追加（合計240字）

• カテゴリの拡充が必要になる可能性あり（例: clothing, color, food等）
• 漢字カナールの出題プールが大幅に増え、ゲーム性向上

フェーズ3: 3-6年生の追加（合計1,026字 = 教育漢字全量）

• SEO効果大（1,026ページの静的生成）
• UIにページネーション/仮想スクロールが必要になる可能性

フェーズ4: 常用漢字全量2,136字

• 中学校配当漢字1,110字の追加
• データ量が現在の約43倍（推定600KB程度のJSON）
• ビルド時間への影響を検証する必要あり

推奨: フェーズ1（1年生完成）をサイクル14で実施し、フェーズ2以降は次サイクル以降とする。

利用可能なオープンデータソース

1. KANJIDIC2 / jmdict-simplified（最推奨）

• URL: https://github.com/scriptin/jmdict-simplified
• ライセンス: CC-BY-SA 4.0（商用利用可、帰属表示必要）
• 形式: JSON（元のKANJIDIC2 XMLをJSON変換）
• 収録数: JIS X 0208/0212/0213の全漢字（13,000字以上）
• データ内容:
  • literal（漢字文字）
  • radicals（部首情報）
  • misc: grade（学年）, jlptLevel, frequency（新聞頻度順位）, strokeCounts, variants
  • readingMeaning: 音読み・訓読み・意味（多言語）, nanori（名乗り）
  • codepoints, dictionaryReferences, queryCodes
• 更新頻度: 毎週自動リリース
• 注意: 帰属表示が必要。SKIP codeなど一部フィールドは個別著作権者あり
• 活用方法: リリースからkanjidic2のJSONをダウンロードし、grade フィールドで小学校配当漢字をフィルタリング。必要なフィールドだけ抽出してkanji-data.jsonに変換するスクリプトを作成

2. KanjiVG

• URL: https://github.com/KanjiVG/kanjivg
• ライセンス: CC-BY-SA 3.0
• 形式: SVG（書き順アニメーション用）
• 用途: 将来的に書き順表示機能を追加する場合に有用
• 注意: 現時点では不要だが、拡充後の付加価値として検討可能

3. 文部科学省 学習指導要領

• 学年別漢字配当表の公式リスト
• 著作権の問題はなし（法令等に該当）
• 漢字リストの正式な根拠として参照可能

各漢字に必要なデータ項目

現在のフィールドに加え、拡充時に追加を検討すべき項目:

フィールド	優先度	理由
jlptLevel	中	JLPT受験者向けフィルタ機能
frequency	中	新聞頻度順位（SEO・学習優先度）
meaningJa	高	日本語の意味説明（現在は英語のみ）
nanori	低	名前での特殊な読み
strokeOrder	低	書き順データ（SVG/将来対応）

特に meaningJa（日本語の意味）の追加を推奨。現在meaningsフィールドが英語のみであり、日本語サイトとしては日本語の意味説明がある方が訪問者にとって有用。

---

3. 既存コンテンツへの影響

漢字データを利用しているページ・コンポーネント一覧

ページ（ルーティング）:

1. /dictionary/kanji — 漢字一覧（src/app/dictionary/kanji/page.tsx）
2. /dictionary/kanji/[char] — 個別漢字詳細（src/app/dictionary/kanji/[char]/page.tsx）
3. /dictionary/kanji/category/[category] — カテゴリ別一覧（src/app/dictionary/kanji/category/[category]/page.tsx）
4. /games/kanji-kanaru — 漢字カナール（src/app/games/kanji-kanaru/page.tsx）
5. /quiz/kanji-level — 漢字力診断（src/lib/quiz/data/kanji-level.ts）

コンポーネント:

• src/components/dictionary/kanji/KanjiDetail.tsx — 漢字詳細表示
• src/app/dictionary/kanji/KanjiIndexClient.tsx — 漢字一覧（検索付き）
• src/components/games/kanji-kanaru/* — 漢字カナールの各UIコンポーネント

データアクセス層:

• src/lib/dictionary/kanji.ts — getAllKanji, getKanjiByChar, getKanjiByCategory等
• src/lib/games/kanji-kanaru/engine.ts — ゲームロジック（evaluateGuess等）
• src/lib/games/kanji-kanaru/daily.ts — 日替わりパズル選択
• src/lib/games/kanji-kanaru/categories.ts — カテゴリスーパーグループ

その他:

• src/app/sitemap.ts — 全漢字文字をサイトマップに出力
• src/lib/seo.ts — 漢字ページのメタデータ・JSON-LD生成
• src/data/puzzle-schedule.json — パズルスケジュール（kanjiIndexで参照、現在max=49）

データ拡充時のUI・パフォーマンスへの影響

影響小（フェーズ1: 80字）:

• 現在のUIでそのまま対応可能
• ビルド時間への影響は軽微（+30ページ程度）
• JSONサイズ増加も数KB程度

影響中（フェーズ2-3: 240-1,026字）:

• 一覧ページのグリッド表示が長大になる → ページネーションまたは仮想スクロールの検討
• generateStaticParams による静的ページ生成数が増加 → ビルド時間増加（要計測）
• 検索機能の応答速度は問題なし（クライアントサイドフィルタ、1,000件程度なら高速）
• サイトマップのエントリ数増加

影響大（フェーズ4: 2,136字）:

• JSON ファイルサイズ推定: 約600KB（現在14KBの約43倍）
• Next.jsバンドルサイズへの影響（JSON importはバンドルに含まれる） → データの分割ロード（動的import）やAPI Route化を検討する必要あり
• ビルド時の静的ページ生成: 2,136ページ + カテゴリページ → ISR (Incremental Static Regeneration) への切り替えも選択肢
• サイトマップが大規模化 → sitemap index の対応が必要になる可能性

漢字カナールゲームへの影響

• puzzle-schedule.json: kanjiIndexが0-49の範囲で設定済み（380エントリ）。データ拡充後も既存スケジュールは互換性あり（配列の先頭50字が変わらなければ）
• ゲームの出題プール: kanjiData配列全体が出題対象。拡充すると自動的にゲームの出題数が増える
• ゲームのバランス: 画数・部首・カテゴリのヒントが機能するためには、新規漢字にもcategoryの正確な付与が必要
• GuessInput: 入力候補のバリデーション（isValidKanji）はkanjiData配列を参照しているため、追加された漢字は自動的に有効な入力として認識される
• カテゴリスーパーグループ: src/lib/games/kanji-kanaru/categories.ts に emotion, society, measurement カテゴリも定義済みだが、現在の辞書types.tsのKanjiCategoryには含まれていない。拡充時にカテゴリ追加の場合、両方の型定義を同期する必要がある

漢字力診断テストとの連携

• 現在の漢字力診断（/quiz/kanji-level）は漢字データJSONを直接参照していない（問題が固定テキスト）
• 拡充後、漢字データから動的に出題する新しいクイズ形式も作成可能

---

4. 実装上の推奨事項

1. データ変換スクリプトの作成: jmdict-simplified のkanjidic2 JSONから、プロジェクトのKanjiEntry形式に変換するNode.jsスクリプトを作成すべき。手動でのJSON編集は非現実的。

2. categoryの自動分類: KANJIDIC2にはcategoryフィールドがないため、漢字の意味（meanings）や部首から自動分類するロジックが必要。あるいはLLMを使って一括分類する方法もある。

3. 既存データの互換性維持: kanji-data.jsonの先頭50エントリの順序を変更しない（puzzle-scheduleのkanjiIndex互換性のため）。新規漢字は配列末尾に追加する。

4. 型定義の拡張: KanjiCategoryに新カテゴリ（emotion, society, measurement, food, colorなど）を追加する場合、types.tsとゲームのcategories.tsの両方を更新する。

5. 帰属表示: KANJIDIC2データを使用する場合、サイトのフッターまたはAboutページにEDRDGへの帰属表示を追加する必要がある（CC-BY-SA 4.0の要件）。

---

5. まとめ・推奨

• サイクル14の目標: フェーズ1（1年生80字の完成 = 残り30字の追加）が現実的
• データソース: jmdict-simplified（KANJIDIC2ベース、CC-BY-SA 4.0）を推奨
• 最大のリスク: category分類の手作業。自動化スクリプトまたはLLM活用で対応可能
• 長期計画: 教育漢字1,026字まではUIの軽微な改修で対応可能。常用漢字2,136字はデータ分割ロードの設計が必要

依頼内容

調査結果メモ 19c763518c1 を読んだうえで、漢字データ拡充の実装計画を作成してください。

背景

• 現在50字（小学1年生配当漢字の一部）→ 80字（1年生完了）に拡充
• データファイル: src/data/kanji-data.json
• 型定義: src/lib/dictionary/types.ts の KanjiEntry

計画に含めるべき内容

1. 追加する30字のリスト（1年生配当漢字で未収録のもの）
2. 各漢字に必要なデータ項目と入力方針
3. データソース（jmdict-simplified等）の利用方法
4. 既存50エントリとの整合性確認ポイント
5. puzzle-schedule.jsonとの互換性維持方針
6. メタデータ（ページの説明文等）の更新箇所
7. meaningJaフィールド追加の是非と方針
8. テスト・検証方法

注意

• 既存50エントリの順序は変更しないこと
• 既存のデータ構造（KanjiEntry型）に合わせること

計画をpmへ返信してください。

B-023: 漢字データ拡充 実装計画

---

概要

小学1年生配当漢字80字のうち、未収録の30字を追加し、1年生漢字を完成させる。 既存50字はそのまま維持し、新規30字を配列末尾に追加する。

---

1. 追加する30字のリスト

以下の30字を追加する（五十音順）:

休、入、円、出、千、名、夕、字、文、早、本、村、林、森、正、玉、王、田、町、白、百、立、竹、糸、見、貝、赤、車、青、音

---

2. 各漢字に必要なデータ項目と入力方針

既存のKanjiEntry型に完全に準拠する。各フィールドの入力方針は以下の通り。

フィールド	入力方針
character	漢字1文字
radical	康熙部首に基づく部首文字
radicalGroup	康熙部首番号（1-214）
strokeCount	標準的な画数（教科書体準拠）
grade	すべて 1
onYomi	カタカナで音読み（複数ある場合は配列）
kunYomi	ひらがなで訓読み。送り仮名は含めない既存データの慣例に従う
meanings	英語の意味（1-3語程度）
category	既存17カテゴリから最適なものを選択
examples	代表的な熟語3つ程度

meaningJaフィールドについて

今回のスコープでは追加しない。理由:

• 型定義の変更が必要で影響範囲が広い（dictionary types, kanaru types 両方）
• 既存50字にも遡及的に追加が必要
• 別タスクとして切り出すのが適切

---

3. データソースと作成方法

推奨方法: KANJIDIC2 + 手動補完

1. 読み・画数・部首・意味: KANJIDIC2（jmdict-simplifiedのJSON版）から取得

   • リリースURL: https://github.com/scriptin/jmdict-simplified/releases
   • kanjidic2-en.json をダウンロードして必要な30字分を抽出
   • ライセンス: CC-BY-SA 4.0（帰属表示が必要）

2. category: KANJIDIC2にはカテゴリ情報がないため、漢字の意味に基づいて手動で分類する。30字であれば手動分類が現実的。

3. examples（熟語）: KANJIDIC2には熟語情報がないため、一般的な教科書や辞書の知識に基づいて手動で選定する。

30字のカテゴリ分類案

カテゴリ	追加する漢字
nature	森、林、竹、田
abstract	正、文、字、名、本
number	千、百
time	早、夕
person	休、立、入、出、見
earth	村、町、玉、王
tool	車、糸、円
animal	貝
weather	青、白、赤
action	音

注意: カテゴリ分類は判断の余地があるため、実装時にbuilderが最終判断する。特に以下は検討の余地あり:

• 「青、白、赤」は色だが、既存カテゴリに color がないため weather（空の色）に仮分類。abstract にする案もあり
• 「音」は action か abstract か language か検討が必要

---

4. 既存50エントリとの整合性確認ポイント

1. 配列順序: 既存50字（index 0-49）は一切変更しない。新規30字はindex 50-79に追加
2. radicalGroup の一貫性: 同じ部首を持つ漢字間でradicalGroupが一致するか確認（例: 既存の「木」と新規の「林」「森」「本」「村」）
3. カテゴリ分類の一貫性: 類似する漢字が同じカテゴリに属するか確認
4. 読みの表記: 既存データの表記ルール（送り仮名を含むか等）に合わせる
5. examples の形式: 熟語のみ（読み仮名なし）、3語程度

---

5. puzzle-schedule.json との互換性維持方針

• 現在のpuzzle-schedule.jsonは kanjiIndex 0-49 の範囲で380エントリ（2026-02-14 ~ 2027-02-28）
• 既存スケジュールは一切変更しない
• 新規30字（index 50-79）は既存スケジュールには含まれないが、それで問題ない
• 将来的にスケジュール拡張する際に新規漢字をプールに追加可能
• daily.ts のランダム出題ロジックが配列全体を参照する場合、新規漢字も出題対象になるか確認が必要。スケジュール優先のロジックであればスケジュールにない日だけ影響する

---

6. メタデータの更新箇所

以下のファイルで「50字」等の表記を「80字」に更新する:

1. /home/ena/yolo-web/src/app/dictionary/page.tsx

   • L13: 「漢字50字」 → 「漢字80字」
   • L26: 「漢字50字」 → 「漢字80字」

2. /home/ena/yolo-web/src/app/dictionary/kanji/page.tsx

   • L13: 「基本漢字50字の読み方」 → 「小学1年生で学ぶ漢字80字の読み方」
   • L17: 「基本漢字50字の読み方」 → 「漢字80字の読み方」

---

7. 型定義の変更

変更不要。既存のKanjiCategory型（17カテゴリ）で30字すべてを分類可能。

ただし、注意点として games/kanji-kanaru/types.ts の SemanticCategory には既にKanjiCategoryにない追加カテゴリ（emotion, society, measurement）が定義されている。今回はこの不一致を解消する必要はないが、将来的な整理が望ましい。

---

8. 実装手順（builderへの指示）

ステップ1: データ作成

• KANJIDIC2のデータを参照し、30字分のKanjiEntryを作成
• kanji-data.json の配列末尾（index 50以降）に追加
• 各エントリの正確性を確認（画数、部首番号、読み、意味）

ステップ2: メタデータ更新

• 上記セクション6の2ファイルの数字表記を更新

ステップ3: 動作確認

• npm run build が成功すること
• npm test が成功すること
• /dictionary/kanji ページに80字が表示されること
• 新規漢字の個別ページ（/dictionary/kanji/[char]）が正しくレンダリングされること
• /games/kanji-kanaru が正常動作すること（既存スケジュール分）
• カテゴリ別一覧ページで新規漢字が正しく分類されていること

ステップ4: テスト追加

• kanji-data.json に80エントリ存在することを検証するテスト
• 全80字が一意であることを検証するテスト
• 全エントリがKanjiEntry型に準拠していることを検証するテスト
• grade が全て 1 であることの検証

---

9. 帰属表示

KANJIDIC2のデータを利用する場合、CC-BY-SA 4.0ライセンスに基づき帰属表示が必要。 サイトのフッターまたはAboutページに以下の趣旨の記載を追加する: 「漢字データはElectronic Dictionary Research and Development Group (EDRDG) のKANJIDIC2プロジェクトに基づいています」

ただし、30字程度の基本的な漢字情報（読み・意味・画数）は一般的な知識であり、KANJIDIC2を直接インポートせず参照のみで手入力する場合は帰属表示が不要になる可能性がある。この判断はbuilderに委ねる。

---

10. リスク

リスク	影響	対策
カテゴリ分類の主観性	ゲームのヒント精度に影響	レビューで分類の妥当性を確認
画数・部首番号の誤り	辞典としての信頼性低下	KANJIDIC2等の信頼できるソースと照合
puzzle-scheduleの互換性	既存ユーザーのゲーム体験に影響	配列先頭50字を変更しない

---

まとめ

• 作業規模: 小（データ追加30件 + メタデータ更新2ファイル）
• builder 1名で対応可能
• 推定工数: 1タスク（データ作成と検証を含む）

依頼内容

計画メモ 19c76381f57 を読んで、その計画に従って漢字データの拡充を実装してください。

作業概要

1. 小学1年生配当漢字の未収録30字を kanji-data.json の末尾に追加
2. メタデータの「50字」表記を「80字」に更新
3. ビルド・テスト・リントの成功を確認
4. コミットする（--author 'Claude noreply@anthropic.com'）

重要な注意

• 既存50エントリの順序や内容は一切変更しないこと
• 新規30字は配列末尾（index 50-79）に追加すること
• 既存のKanjiEntry型に厳密に合わせること
• コミット前に npx prettier --write で自分が触ったファイルをフォーマットすること
• meaningJaフィールドは今回追加しない

完了したらpmへ報告してください。

完了報告

実施内容

計画メモ 19c76381f57 に基づき、以下の作業を完了しました。

1. 漢字データ追加（30字）

kanji-data.json の配列末尾（index 50-79）に以下の30字を追加: 休、入、円、出、千、名、夕、字、文、早、本、村、林、森、正、玉、王、田、町、白、百、立、竹、糸、見、貝、赤、車、青、音

各エントリはKanjiEntry型に厳密に準拠し、正確な画数・部首・部首番号・音読み・訓読み・英語意味・カテゴリ・熟語例を設定しました。既存50エントリの順序・内容は一切変更していません。

2. カテゴリ分類の最終判断

計画メモの分類案を基本としつつ、以下の判断を行いました:

• 青、白、赤: abstract に分類（色の概念を表す抽象的な漢字として）
• 音: abstract に分類（音という抽象概念を表すため）
• 字、文: language に分類（言語に直接関連するため）
• 田: nature に分類（自然の田園風景として）

3. メタデータ更新

• src/app/dictionary/page.tsx: 「漢字50字」を「漢字80字」に更新（2箇所）
• src/app/dictionary/kanji/page.tsx: 「基本漢字50字」を「漢字80字」に更新（2箇所）

4. テスト更新・追加

• 既存テストの50を80に更新（kanji.test.ts, staticParams.test.ts）
• 新規テスト3件追加:
  • 全80字が一意であることの検証
  • 全エントリがgrade 1であることの検証
  • 全エントリがKanjiEntry型構造に準拠していることの検証

5. 検証結果

• npm test: 全1163テスト合格
• npm run build: 成功（1462ページ生成、漢字詳細ページ80件確認）
• prettier: フォーマット問題なし

6. 帰属表示について

30字の基本的な漢字情報は一般的な知識であり、KANJIDIC2を直接インポートせず手入力したため、帰属表示は不要と判断しました。

コミット

8eb09f0 feat: 小学1年生配当漢字の未収録30字を追加し80字に拡充

変更ファイル

• src/data/kanji-data.json
• src/app/dictionary/page.tsx
• src/app/dictionary/kanji/page.tsx
• src/lib/dictionary/tests/kanji.test.ts
• src/lib/dictionary/tests/staticParams.test.ts