| name | create-kakitori-questions |
| description | kakitori.page の question 素材 (漢字・かな・数字・アルファベットの書き取り問題) を「1問1ファイルのJSON」として作成・検証する。https://kakitori.page/schemas/question.json に準拠し、サーバーの整合性ルール (表層形ふりがな・segments連結・例文の語包含・字形データ存在) を登録前にローカルで満たすことを保証する。ユーザーが「問題を作って」「漢字ドリルの問題ファイル」「kakitori.pageに登録する問題」「question JSONの検証・修正」などに言及したら、語リストだけ渡された場合や学年・単元指定 (小2の漢字など) の場合も含めて必ずこのスキルを使うこと。ふりがなの付け方 (促音化・連濁・熟字訓) の判断が必要な時点でこのスキルの領分。 |
kakitori.page question ファイルの作成
kakitori.page の question は「問題素材」で、サーバー登録時に JSON Schema と整合性ルールで厳密に検証される。このスキルは登録時に一発で通るファイルをローカルで作るためのもの。検証は同梱スクリプトで行い、手作業で規則を思い出す必要はない。
出力契約
- 1問 = 1ファイル。ファイル名は
<word>-<reading>.json (例 学校-がっこう.json)。word + reading はノート内の一意キーなのでファイル名も必ず一意になる
- 保存先はユーザーの指示に従う。指示がなければ
questions/ を提案する
- ファイルの中身は question オブジェクトそのもの + 先頭に
$schema:
{
"$schema": "https://kakitori.page/schemas/question.json",
"word": "学校",
"reading": "がっこう",
"segments": [
{ "text": "学", "reading": "がっ" },
{ "text": "校", "reading": "こう" }
],
"sentences": ["あたらしい学校にかよう", "学校のプールでおよぐ"]
}
$schema はエディタ補完・検証のために入れる。kakitori.page への登録時には取り除くこと (サーバーは additionalProperties: false のため $schema を拒否する)。登録は import key で POST /api/v1/notes/:key/questions。リクエストボディは { "questions": [ ... ], "mode": "append" | "replace" } の形 (wrapperスキーマは https://kakitori.page/schemas/question-import.json、1リクエストで最大100件)segments はサーバー補完に頼らず常に明示的に書く。ふりがなの質がこの素材の価値だから
フィールドの制約 (スキーマ由来)
| フィールド | 制約 |
|---|
word | 1〜16文字。漢字・かな・数字・アルファベット |
reading | 1〜32文字。ひらがなと長音符 ー のみ (数字・アルファベットの語も読みはひらがな。例 ABC → えーびーしー) |
segments[].text | 1コードポイント (1文字) |
segments[].reading | 1〜8文字。ひらがなと ー のみ。任意 |
sentences | 任意。最大8件、各1〜40文字 |
表層形ふりがなの規則 (最重要)
segments[].reading は辞書の音訓ではなく、その語の中で実際にその文字に振るふりがな (表層形) を書く。サーバーは「各segmentの読み寄与の連結 = reading」を検証するので、辞書読みを書くと登録に失敗する。
- 促音化。「学校」の「学」は「がく」ではなく 「がっ」。「切手」の「切」は「きっ」
- 連濁。「花火」の「火」は「ひ」ではなく 「び」。「三日月」の「月」は「づき」
- 送り仮名・助詞などのかな文字。
reading を付けない (text自身が読み)。付けるとエラー
{ "word": "大きい", "reading": "おおきい",
"segments": [ { "text": "大", "reading": "おお" }, { "text": "き" }, { "text": "い" } ] }
- 熟字訓 (五月雨=さみだれ など文字単位に読みを割れない語)。漢字segmentの
reading をすべて省略する。一部だけ付けると連結検証に落ちる
{ "word": "五月雨", "reading": "さみだれ",
"segments": [ { "text": "五" }, { "text": "月" }, { "text": "雨" } ] }
- 数字・アルファベット。読みを付けるかは任意。付けるなら全部の非かな文字に付ける (一部だけだと連結検証がスキップされ、ふりがな表示ができない素材になる)
- カタカナはかな扱い。
reading を付けない (読み連結の照合はひらがな化して行われる)
分けて書く vs 熟字訓ルート (「学校」を「がっこう」のまま置きたくなったとき)
判断基準はただひとつ、「per-char の読み対応が言語的に成立するかどうか」。ふりがなの描画のしやすさや部分提示ができるかどうかといった下流の都合は根拠にしない。
- 学校: 学の音読み「がく」が促音化して「がっ」, 校は「こう」。文字と音の対応が実在するので、それを書き写して 学(がっ)/校(こう) が正解。ふりがな慣習で「がっこう」を1塊で振ることが多いのは表記上の話で、per-char の言語構造とは別レイヤ。学校を熟字訓ルートで書くのは「対応が付くのに付けていない」ので誤り (登録は通ってもデータの意味が違う)
- 五月雨=さみだれ, 大人=おとな, 今日=きょう などの熟字訓: per-char の対応が言語的に決まらないので, 漢字segmentの
reading を全省略するのが正解。無理に一部の文字に割り当てると, その割り当て自体が事実に反する
- 一部の漢字segmentだけ
reading を付ける (中間状態): 常に誤り。per-char 対応が付くならすべての漢字に付ける、付かないなら全部省略する。混在は言語的にも整合しない (副次的に読み連結の検証もスキップされる)
参考:
- 促音化の機序 (学「ガク」+ 校「コウ」→ ガッコウ の由来): Wikipedia「音便」 —「漢字の入声韻尾, いわゆる『フクツキチ』については, 漢熟語において, 後続する漢字の語頭音によっては『学会: ガク + クヮイ → ガッカイ』のように促音化する」
- 熟字訓の定義 (per-char に割れないこと): Wikipedia「熟字訓」 —「単字に分解してもそれぞれに熟字訓の要素は現れず, その読み方でも分節不可能なものが多い」
- 公式の熟字訓リスト: 文化庁「常用漢字表」付表 (五月雨・大人・今日 などが列挙)
例文 (sentences) の規則
- 各例文は
word をそのままの表記で部分文字列として含むこと (サーバーの整合性ルール7)。「がっこうにいく」はNG、「学校にいく」がOK
- 同一 question 内で例文を重複させない
- 子ども向けの語彙・文長にする。句読点は使ってよい (字形データチェックの対象外)
- 例文は小学校の教科書・塾の問題・国語辞書に出てくるような文にする。規範的で自然な用例は語の意味と使い方の手本になり、読み取り・書き取り問題の文脈としても質が高くなる
- ユーザーが例文を渡してきたら、正しいか (語をそのままの表記で含むか、日本語として自然で誤りがないか、上記の制約を満たすか) を確認したうえでそれも採用する。満たさない例文は直すか、ユーザーに確認する
- ゲームは例文中の語の位置を機械的に見つけて「語だけ空欄の書き取り」「例文つき読みテスト」を合成する。語の前後に自然な文脈がある文が良い例文
字形データの存在
word の各文字は @k1low/hanzi-writer-data-jp に字形データが必要 (ないと登録時に422)。JIS第1水準の漢字・かな・数字・基本ラテン文字はほぼ揃っているが、珍しい字は検証スクリプトの chardata チェックで確認する。
ワークフロー
- 作る question を決める (ユーザーの語リスト、または学年・単元から選定)。読み・表層形ふりがな・例文を組み立てる
<word>-<reading>.json を書く- 検証する:
$ node <このスキルのディレクトリ>/scripts/validate.mjs questions/
スクリプトはスキーマ制約、整合性ルール (segments連結・かなsegmentのreading禁止・読み連結・例文の語包含と重複)、ファイル名規約、字形データの存在 (unpkgへ問い合わせ。ネットワークなしなら --offline) をまとめて検査する
- 失敗があれば修正して再実行。全ファイルがpassするまで完了としない
読みに自信がないとき
促音化・連濁は機械的に判定できない (「一階=いっかい」だが「二階=にかい」)。語の実際の発音を思い浮かべて表層形を決め、確信が持てない語はユーザーに確認する。誤ったふりがなは登録エラーにならないケースもある (連結さえ合っていれば通る) ため、検証パス = 正しい読み、ではないことに注意。
