ホームへ戻る 完全な貢献ガイドを見る

CONTRIBUTOR GUIDE

はじめての投稿でも、大丈夫。

コードも Git も、先に覚える必要はありません。現在の経験に合うルートを選べば、GitHub アカウントの作成から Wiki の編集、そして Pull Request の送信まで順番に案内します。

間違えても、すぐに公開サイトが壊れることはありません。Pull Request は「変更を確認してください」という依頼で、反映前にメンテナーが確認します。

1回の投稿は3段階

  1. 01 アカウント準備
  2. 02 内容を編集
  3. 03 PRを送信

今回の対象ファイル

記事ページから来た場合、ここに実際に変更するファイルが表示されます。違う場合は記事へ戻り、「ソースを編集」から入り直してください。

対象ファイルが指定されていません。学習は続けられますが、実際の編集時は各記事から入ってください。

01 / Route

いま、どこから始めますか?

技術に詳しいかを判断する必要はありません。現在の状況に一番近いものを選んでください。ルートはいつでも変更でき、進捗はこのブラウザに保存されます。

完全初心者ルート · コーディング不要

一番詳しく、安心して進められるルートです。必要なのは受信できるメールとブラウザだけ。すべて Web 上で完結し、Git、ターミナル、コードエディタのインストールは不要です。

最初は順番に進み、次回からは短い「Web編集」ルートを利用できます。

GitHub アカウントを持っていない

完了 0 / 10

01

Step 01

必要なものを準備する

GitHub も Wiki 投稿も無料です。メール、ブラウザ、変更したい情報、信頼できる出典を用意します。

長く使えるメールアドレス、Chrome / Edge / Safari / Firefox などのブラウザ、変更したい内容とそれを確認できる出典を準備します。

クレジットカード、有料プラン、Git、ターミナル、開発アプリは不要です。変更はまず自分の安全なコピーに保存し、PR で確認を依頼します。

パスワード、認証コード、2段階認証コード、復旧コードは本人だけが管理します。メンテナーも AI も必要としません。

完了の目安: 受信できるメールがあり、ブラウザだけで無料で完了できると理解できた。

このステップを AI に手伝ってもらう

現在見えている画面、エラー、迷っている点を補足すると、このステップの目的・対象ファイル・リポジトリ制約と組み合わせた質問を作ります。

画面の公開情報とエラー文だけを書き、パスワード、認証コード、Cookie、トークン、メール、個人情報は入力しないでください。

コピーされる完全な質問

0 / 600
ファン Wiki に初めて投稿します。GitHub はまったく分かりません。Repository、Fork、Commit、Pull Request を非常にやさしい日本語で説明し、PR では公開サイトをすぐ壊せない理由も教えてください。プログラミング経験を前提にせず、パスワードや認証コードを求めないでください。

受信できるメールがあり、ブラウザだけで無料で完了できると理解できた。

02

Step 02

無料の GitHub 個人アカウントを作る

画面に従って登録し、公開されるユーザー名を決め、メール認証を完了します。

  1. 下の GitHub 登録ページを開きます。
  2. メール、または GitHub が表示する Google / Apple ログインで登録します。
  3. 投稿記録の横に公開されてもよいユーザー名を決めます。
  4. 他サイトと異なる強いパスワードを作り、安全に保管します。
  5. GitHub が求める確認を完了します。

プランを聞かれたら無料の個人アカウントで十分です。登録後、GitHub から届くメールのリンクを開いて認証してください。未認証だと Fork や PR などが制限されます。

メールが届かない場合は迷惑メールを確認し、右上のアイコン → SettingsEmailsResend verification email を使います。

完了の目安: GitHub にログインでき、Settings → Emails で主要メールが認証済みになっている。

このステップを AI に手伝ってもらう

現在見えている画面、エラー、迷っている点を補足すると、このステップの目的・対象ファイル・リポジトリ制約と組み合わせた質問を作ります。

画面の公開情報とエラー文だけを書き、パスワード、認証コード、Cookie、トークン、メール、個人情報は入力しないでください。

コピーされる完全な質問

0 / 600
GitHub の無料個人アカウントを作っています。現在の登録画面で一般的に必要な項目を一つずつ説明し、何が公開情報になるか教えてください。パスワードやメール認証コード、2段階認証コード、復旧コードを作成・収集・要求しないでください。

GitHub にログインでき、Settings → Emails で主要メールが認証済みになっている。

03

Step 03

4つの言葉で流れを理解する

Gitを学ぶ必要はありません。「リポジトリ → Fork → Commit → PR」だけ覚えます。

編集部への原稿投稿にたとえると、リポジトリは共有の原稿庫、Fork は自分用の作業コピー、Commit は1回の保存記録、PR は編集部へ戻して確認を頼む提出です。

PR は公開サイトへの直接編集ではありません。修正依頼は失敗ではなく、共同編集の普通のやり取りです。

Checks / CI は自動確認です。緑は通過、赤は具体的な修正点がある状態です。

完了の目安: Commit は保存、PR はメンテナーへの確認依頼だと自分の言葉で説明できる。

このステップを AI に手伝ってもらう

現在見えている画面、エラー、迷っている点を補足すると、このステップの目的・対象ファイル・リポジトリ制約と組み合わせた質問を作ります。

画面の公開情報とエラー文だけを書き、パスワード、認証コード、Cookie、トークン、メール、個人情報は入力しないでください。

コピーされる完全な質問

0 / 600
Repository、Fork、Branch、Commit、Pull Request、Checks/CI を「編集部への原稿投稿」にたとえて、非技術者向けに説明してください。最後に編集から統合までの文字だけの流れ図を作ってください。

Commit は保存、PR はメンテナーへの確認依頼だと自分の言葉で説明できる。

04

Step 04

対象ファイルと言語、出典を確認する

間違った記事を編集しないよう、パスとロケール、根拠を先に確認します。

上部の対象は src/content/ で始まる必要があります。

src/content/artists/vwp/kaf/ja.md

zh.md は中国語、ja.md は日本語、en.md は英語です。artists/ はアーティスト、songs/ は楽曲、albums/ はアルバム、projects/ は企画、logs/ は記録、site/ はサイト共通文言です。

新しい事実には追跡可能な出典を用意します。公式サイト・公式告知を優先し、AI 出力、噂、確認できないファン投稿を事実の根拠にはしません。

完了の目安: 対象とロケールが正しく、新しい情報を支える信頼できる出典がある。

このステップを AI に手伝ってもらう

現在見えている画面、エラー、迷っている点を補足すると、このステップの目的・対象ファイル・リポジトリ制約と組み合わせた質問を作ります。

画面の公開情報とエラー文だけを書き、パスワード、認証コード、Cookie、トークン、メール、個人情報は入力しないでください。

コピーされる完全な質問

0 / 600
KAMITSUBAKI FAN WIKI の {{TARGET_PATH}} を編集します。このパスの内容種別と言語、変更すべき場所が frontmatter か本文かを説明してください。人物情報を作らず、出典が不足なら公式情報を探すよう明示してください。dist、.astro、node_modules や無関係なコードは変更しないでください。

対象とロケールが正しく、新しい情報を支える信頼できる出典がある。

05

Step 05

GitHub の Web エディタを開く

最後の編集ボタンから進みます。ログインや自動 Fork の確認が出ても正常です。

このルート末尾の編集ボタンを使います。書き込み権限がない場合、GitHub は Fork this repository を表示するか、変更提案時に自動で Fork を作ります。

ファイルパスを再確認してください。ボタン表記は変わることがありますが、流れは次の通りです。

ファイル → Edit → Preview → Commit / Propose changes → Pull Request

編集ボタンが使えない場合は、ログインとメール認証を確認し、Wiki 記事から入り直します。

完了の目安: GitHub の編集欄が見え、そのパスが本ページ上部と完全に一致している。

このステップを AI に手伝ってもらう

現在見えている画面、エラー、迷っている点を補足すると、このステップの目的・対象ファイル・リポジトリ制約と組み合わせた質問を作ります。

画面の公開情報とエラー文だけを書き、パスワード、認証コード、Cookie、トークン、メール、個人情報は入力しないでください。

コピーされる完全な質問

0 / 600
他の人の公開 GitHub リポジトリで {{TARGET_PATH}} を Web 編集しています。私が説明する画面の文字から、次に押すボタンを一度に一つだけ教えてください。自動 Fork は正常です。パスワード、認証コード、Cookie、トークン、完全なアカウント情報を求めないでください。

GitHub の編集欄が見え、そのパスが本ページ上部と完全に一致している。

06

Step 06

frontmatter と本文を安全に編集する

多くの投稿は文章修正です。ファイル先頭の構造を保ち、不明な項目は削除しません。

Markdown ファイルは、--- で囲まれた frontmatter と、その後の本文に分かれます。両方の ---、既存キー、引用符、インデントを維持してください。

locale はファイル名と一致し、同じ記事の多言語ファイルは同じ translationKey を使います。YAML の字下げは Tab ではなく空白です。

必要な箇所だけ変更し、新しい事実には出典を付けます。仮文、推測、AI が作った事実、パスワード、トークン、個人情報は追加しません。

完了の目安: 変更範囲が明確で構造が残り、事実には出典があり、秘密情報が含まれていない。

このステップを AI に手伝ってもらう

現在見えている画面、エラー、迷っている点を補足すると、このステップの目的・対象ファイル・リポジトリ制約と組み合わせた質問を作ります。

画面の公開情報とエラー文だけを書き、パスワード、認証コード、Cookie、トークン、メール、個人情報は入力しないでください。

コピーされる完全な質問

0 / 600
慎重な Markdown 編集者として、{{TARGET_PATH}} の断片と信頼できる出典を確認してください。出典が直接支える箇所だけ変更し、YAML のキー、インデント、--- を維持し、事実や仮文を作らず、無関係な段落を変えないでください。根拠不足なら編集を止めて不足を説明してください。

変更範囲が明確で構造が残り、事実には出典があり、秘密情報が含まれていない。

07

Step 07

差分を確認して Commit する

Preview / Changes を見て、変更内容を表す短い説明で保存します。

緑は追加、赤は削除を示すことが一般的です。誤削除、壊れた ---、言語違い、不自然なインデント、リンク・日付・固有名詞を確認します。

Commit changes… を押し、docs: 花譜記事の活動日を修正 のような説明を書きます。外部投稿者には Propose changes と表示されることがあります。

Commit は Fork/ブランチへの保存で、PR はまだ完了していません。次の画面も続けてください。

完了の目安: 差分は意図した内容だけで、Commit message が変更を正確に表している。

このステップを AI に手伝ってもらう

現在見えている画面、エラー、迷っている点を補足すると、このステップの目的・対象ファイル・リポジトリ制約と組み合わせた質問を作ります。

画面の公開情報とエラー文だけを書き、パスワード、認証コード、Cookie、トークン、メール、個人情報は入力しないでください。

コピーされる完全な質問

0 / 600
{{TARGET_PATH}} の GitHub diff を確認してください。誤削除、YAML、言語、根拠のない事実、個人情報を検査し、短い日本語の Commit message を3案ください。貼っていない内容は推測しないでください。

差分は意図した内容だけで、Commit message が変更を正確に表している。

08

Step 08

最初の Pull Request を作る

元リポジトリの main を対象にし、タイトル・変更・出典・言語を書いて送信します。

base repository が LinkTh1rsty/kamitsubaki-wiki-site、base branch が main、head/compare が自分の Fork とブランチであることを確認します。

PR には変更内容、資料出典、言語と範囲を書きます。通常の内容修正は Draft にする必要はありません。Create pull request を押し、番号付き PR ページが表示されたら提出完了です。

完了の目安: 番号付きの Pull Request ページにタイトル、説明、Commits、変更ファイルが表示されている。

このステップを AI に手伝ってもらう

現在見えている画面、エラー、迷っている点を補足すると、このステップの目的・対象ファイル・リポジトリ制約と組み合わせた質問を作ります。

画面の公開情報とエラー文だけを書き、パスワード、認証コード、Cookie、トークン、メール、個人情報は入力しないでください。

コピーされる完全な質問

0 / 600
{{TARGET_PATH}} の KAMITSUBAKI FAN WIKI Pull Request を作ります。私が実際の変更と出典を渡すので、短いタイトルと「変更内容 / 資料出典 / 言語と範囲」を含む Markdown 説明、提出前チェックを作ってください。変更や出典を作らないでください。

番号付きの Pull Request ページにタイトル、説明、Commits、変更ファイルが表示されている。

09

Step 09

Checks とレビューに対応する

自動チェックを待ち、赤なら Details を開き、同じ PR で修正を続けます。

黄・灰は実行中、緑は通過、赤は失敗です。Details を開き、最初の具体的エラーから確認します。YAML の字下げ、必須項目、locale、Markdown 構造が代表的な原因です。

同じ Fork / ブランチを編集して Commit すれば、既存 PR に自動追加されます。CI 修正のために新しい PR は作りません。レビューコメントを修正したら、短く返信してください。

完了の目安: 現在の状態を理解し、失敗やコメントがあれば具体的な修正箇所を見つけた。

このステップを AI に手伝ってもらう

現在見えている画面、エラー、迷っている点を補足すると、このステップの目的・対象ファイル・リポジトリ制約と組み合わせた質問を作ります。

画面の公開情報とエラー文だけを書き、パスワード、認証コード、Cookie、トークン、メール、個人情報は入力しないでください。

コピーされる完全な質問

0 / 600
{{TARGET_PATH}} の PR にチェック失敗またはレビューコメントがあります。公開されているエラー文を貼るので、やさしい日本語で意味と最小修正を説明し、同じブランチと PR を更新するよう案内してください。秘密情報を求めないでください。

現在の状態を理解し、失敗やコメントがあれば具体的な修正箇所を見つけた。

10

Step 10

投稿を完了し、結果を確認する

PR を送れば中核作業は完了です。通知を確認し、Merged または Closed まで追跡します。

Open は確認中、Merged は統合済み、Closed は未統合で終了です。レビューには時間がかかることがあります。待っているだけなら PR を閉じる必要はありません。

修正が必要なら同じブランチを更新します。1か所の誤字や正確な日付、信頼できる出典の追加も大切な貢献です。

完了の目安: PR が送信され、状態の見方と次に確認する場所が分かる。

このステップを AI に手伝ってもらう

現在見えている画面、エラー、迷っている点を補足すると、このステップの目的・対象ファイル・リポジトリ制約と組み合わせた質問を作ります。

画面の公開情報とエラー文だけを書き、パスワード、認証コード、Cookie、トークン、メール、個人情報は入力しないでください。

コピーされる完全な質問

0 / 600
私が説明する GitHub PR の状態が Open、Merged、Closed のどれかを説明し、必要な次の操作だけを初心者向け日本語で教えてください。認証情報を求めないでください。

PR が送信され、状態の見方と次に確認する場所が分かる。

Pull Request

あなたの投稿をメンテナーへ送る

最後に、対象ファイル、検証可能な内容、出典、仮文・推測・個人情報がないことを確認します。その後は Edit → Preview → Commit / Propose changes → Create pull request の順です。困った場所では各ステップの AI 用質問を使えます。

02 / 必要なときに参照

編集に必要な答えを、このページだけで。

貢献フローから離れたり、すべての構文を暗記したりする必要はありません。まず現在の変更に必要な部分を進め、書式・メディア・frontmatter で迷ったときに目次から該当章へ移動してください。

  1. 01自分に合うルートを選ぶ
  2. 02対象ファイルと言語を確認
  3. 03編集中に構文を参照
  4. 04差分を確認して PR を送る

これは最初から最後まで暗記する教材ではなく、必要なときに参照するリファレンスです。初めての貢献では上のルートを選び、編集中に見出し、リンク、画像、メディア、frontmatter で迷ったときだけ該当章へ移動してください。

編集を始める前に

最短で確実な流れは次のとおりです。

  1. 対象が src/content/ 配下にあり、zh.mdja.mden.md が目的の言語と一致することを確認します。
  2. 今回の目的に必要な箇所だけを変更し、新しい事実には追跡可能な出典を用意します。
  3. frontmatter の両方の ---、既存フィールド、インデント、引用符を保ちます。
  4. Pull Request を作成する前に Preview / Changes で差分を確認します。

本サイトは Wikitext ではなく Markdown を使用します。構文記号は半角 ASCII で入力してください。日本語・中国語入力の全角記号は Markdown として機能しません。

初心者の原則:小さく正確な変更を優先してください。無関係な段落をついでに整理せず、AI の出力を事実の出典として扱わないでください。

見出し

# で見出しを作成します。記号の数が階層に対応し、最大6階層まで使えます。# の後ろには半角スペースが必要です。ページタイトルは frontmatter から表示されるため、記事本文は通常 ## から始めます。

記述例:

## レベル2の見出し
### レベル3の見出し

表示例:

レベル3の見出し例

テキストの書式

記述例:

**太字テキスト**
*斜体テキスト*
***太字斜体テキスト***
~~取り消し線テキスト~~
`インラインコード`

表示例:

太字テキスト斜体テキスト太字斜体テキスト取り消し線テキストインラインコード

リスト

箇条書きリスト

- または + を使用します。

記述例:

- 項目1
- 項目2

表示例:

  • 項目1
  • 項目2

リスト記号の後ろには、必ず半角スペースを入れてください。

番号付きリスト

数字の後ろにピリオドを付けます。

記述例:

1. 手順1
2. 手順2
3. 手順3

表示例:

  1. 手順1
  2. 手順2
  3. 手順3

ハイパーリンク

記述例:

[本サイト](https://kamitsubaki.wiki/ja/)

表示例:

本サイト

| で列を区切り、- で見出し行との区切りを定義します。

記述例:

| アーティスト | 楽曲名 | 歌詞 |
| :--- | :---: | ---: |
| KAF | 糸 | 省略 |
| RIM | 1999 | 省略 |

表示例:

アーティスト楽曲名歌詞
KAF省略
RIM1999省略

配置方法:

  • :---:左揃え
  • :---::中央揃え
  • ---::右揃え

Frontmatter

ファイル上部のFrontmatterには、編集する記事の属性を記述します。

Frontmatterの開始記号と終了記号には、どちらも --- を使用します。

例:

---
locale: ja
translationKey: example-entry
title: 記事の例
---

表示結果: ページはこれらのフィールドからタイトル、言語間の関連、メタデータを生成します。YAML ブロック自体は記事本文に表示されません。

画像の挿入

記述例:

![花譜「糸」のカバー画像](/images/songs/shi.webp)

表示結果: この位置に画像が表示されます。画像がまだ追加されていない場合も、代替テキストが内容を説明します。

画像ファイルは public/images/ に配置しますが、Markdown の URL は /images/ から始め、public を含めません。情報を持つ画像には内容を説明する代替テキストを付け、装飾画像では ![](...) のように空にできます。

Markdown エディターについて

Markdown形式のファイルを作成するために、特別なエディターは必要ありません。

メモ帳などの基本的なテキストエディターでも、保存時に拡張子を .md に変更すればMarkdownファイルを作成できます。

Markdownに慣れていない方には、リアルタイムプレビューに対応したエディターの方が使いやすい場合があります。

本ページの作成者は、機能が充実しており、複数のプラットフォームに対応しているObsidianを推奨します。

Wiki 短縮構文と管理されたメディア

Markdown の基本を学んだ後は、ルビ、折りたたみ、意味付けのために、サイトが対応する一部の HTML を使用できます。本文の HTML はビルド時に安全化されるため、ブラウザーが対応するすべての要素を利用できるわけではありません。

安全境界

本文では次の種類の要素だけを許可します。

  • 構造:ph1h6blockquotehrbrdivspan
  • テキストの意味付け:aabbrbstrongiemusdelmarksmallcodeprekbdsampvarsubsupciteqtime
  • リストとデータ:ulollidldtddtabletheadtbodytfoottrthtd
  • Wiki 向け表現:rubyrtrpdetailssummaryfigurefigcaptionpictureimgsource

属性もホワイトリスト方式です。通常のリンク、画像の代替テキスト、表のセル結合などは保持されますが、class はサイト側で実装済みの用途だけに制限されます。次の内容は削除されます。

  • scriptstyleiframeobjectembedform など、コード実行や任意の外部コンテンツ読み込みにつながる要素。
  • onclickonmouseoveronerror などすべての on* イベント属性と、インライン style
  • javascript: など危険な URL スキーム。本文で指定した id / name には安全な接頭辞が付き、ページ側のオブジェクトを上書きできません。

投稿者がこの HTML を直接書く必要は通常ありません。下記の Wiki 短縮構文を優先してください。サイト側のコードが対応する要素を生成し、その結果も同じホワイトリストで検査されます。新しい操作が必要な場合は PR で再利用可能な短縮構文を提案し、スクリプトや外部プレイヤーのコードを記事へ貼り付けないでください。

Wiki 短縮構文一覧

短縮構文は関数に似た {{名前::引数}} 形式です。名前と引数の数は固定されています。

用途構文
ルビ{{ruby::本文::読み}}
読みとローマ字{{ruby::本文::かな::romaji}}
ネタバレ / 伏せ字{{spoiler::隠す文字}}
強調表示{{mark::重要}}
略語の説明{{abbr::V.W.P::Virtual Witch Phenomenon}}
キーボード入力{{kbd::Ctrl+K}}
機械可読の日付{{time::表示文字::2026-07-19}}
小文字、上付き、下付き{{small::文字}}{{sup::2}}{{sub::2}}
歌詞切り替えボタン{{lyrics-controls::ja}}(各ファイルでは zh / en に変更)

インライン構文の引数はプレーンテキストです。内部に Markdown や HTML を入れず、二重コロン :: を引数の区切りとして使います。Markdown 表の中でも列を壊しません。名前や引数数が誤っている場合は元の文字列が表示されるため、Preview で間違いを確認できます。

記述例:

{{mark::重要な内容}}
{{abbr::V.W.P::Virtual Witch Phenomenon}}
{{kbd::Ctrl+K}} を押す
{{time::2026年7月19日::2026-07-19}}
H{{sub::2}}O と x{{sup::2}}
{{small::補足説明}}

表示例:

重要な内容V.W.PCtrl+K を押す、、H2O と x2補足説明

楽曲ページでは {{lyrics-controls::ja}} を独立した段落にし、.my-lyric-box 歌詞コンテナの直前に置きます。サイトが各言語用のルビ、翻訳、ローマ字、同期歌詞ボタンを生成し、日本語版では翻訳ボタンを自動的に省略します。引数はファイルの locale と一致させてください。

歌詞ページの完全な書き方

歌詞ページは、ローカライズされた切り替えボタン、歌詞コンテナ、繰り返す歌詞行の3部分で構成します。ボタンは独立した段落としてコンテナの直前に置き、各 lyric-line に原文1行を記述します。

コード構文

{{lyrics-controls::言語}}

<div class="my-lyric-box">

<div class="lyric-line">
<div class="jp-lyric">
<ruby>原文<rt class="furi">かな</rt><rt class="roma">romaji</rt></ruby>
</div>
</div>

</div>
  • 言語 は現在のファイルに合わせて zhjaen のいずれかにします。
  • furi は「注音を表示」ボタンで切り替えるかな、roma はローマ字トラックです。
  • 中国語訳は cn-lyric、英語訳は trans-lyric を使い、日本語ファイルでは翻訳用 <div> を記述しません。
  • かな自体にルビが不要な場合は、ローマ字だけを書けます:<ruby>なら<rt class="roma">nara</rt></ruby>
  • 行を増やすたびに lyric-line 一式を複製します。この生 HTML ブロック内に {{ruby::...}} 短縮構文を置かないでください。HTML ブロック内部では Markdown 短縮構文が再解析されません。

書き方

日本語の楽曲ファイルへコピーできる、1行分の完全な例です。

{{lyrics-controls::ja}}

<div class="my-lyric-box">

<div class="lyric-line">
<div class="jp-lyric">
<ruby>間違<rt class="furi">まちが</rt><rt class="roma">machiga</rt></ruby><ruby>い<rt class="roma">i</rt></ruby>
</div>
</div>

</div>

実例

上のコードは、操作できる歌詞練習コンポーネントとして表示されます。

同期歌詞のタイムライン

カラオケ風の単語アニメーションを表示する場合は、各歌詞単位の直前に [mm:ss.xx] または [mm:ss.xxx] のタイムタグを記述します。時刻は歌詞タイマーの開始点を基準とした、その単位の開始時刻です。再生中は隣り合うタイムタグの間を左から右へ連続的に塗り進めます。「再生」で 00:00.00 から計時し、タイムタグ付きの行をクリックするとその行へ移動して再生を続け、「リセット」で先頭へ戻ります。

  • mmss はそれぞれ2桁、小数部は2桁または3桁です。例:[00:03.50][01:02.345]
  • タイムタグは対象の <ruby> またはプレーンテキストへ空白を入れず直結します。個別に強調する単位ごとに開始時刻が必要です。
  • .jp-lyric の最初のタイムタグは、その行をクリックしたときの移動先にもなります。翻訳行がある場合は、先頭に原文と同じ行開始時刻を付けることを推奨します。
  • 各単位は次のタイムタグまで塗り進みます。行末の単位は次の行まで続き、最終行には短い自動終了時間が適用されます。
  • 時刻は再生順に増加させます。一部の行だけにタイムタグを付けることもでき、タグのない行は通常表示のままです。
  • 投稿者が書くのは角括弧のタイムタグだけです。サイト生成後の lrc-taglrc-word、スクリプトを手書きしないでください。時刻は実際に試聴して調整し、AI に推測させないでください。
  • 現在の歌詞タイマーは独立しており、上部の YouTube、bilibili、その他の試聴プレイヤーの再生位置を自動取得しません。

書き方

{{lyrics-controls::ja}}

<div class="my-lyric-box">

<div class="lyric-line">
<div class="jp-lyric">
[00:00.00]<ruby>間違<rt class="furi">まちが</rt><rt class="roma">machiga</rt></ruby>[00:00.80]<ruby>い<rt class="roma">i</rt></ruby>
</div>
</div>

</div>

実例

同期歌詞を有効にすると、次の2つの日本語単位が 0 秒と 0.8 秒から順に左から右へ塗られます。

歌詞 HTML を生成する AI プロンプト

長い歌詞では、手元にある原文、読み、ローマ字、翻訳を AI に機械的に整形させられます。AI を歌詞・翻訳・読みの出典にはせず、貼り付け前に全行を確認し、入力内容の出典が今回の投稿に利用できることも確認してください。

プロンプト構文

次の全文を AI にコピーし、最後の5つの入力欄だけを置き換えます。

あなたは KAMITSUBAKI Wiki の歌詞 HTML 整形アシスタントです。私が提供した歌詞トラックだけをサイト形式へ変換してください。

必須条件:
1. 入力だけを変換し、歌詞の追加、翻訳、書き換え、不足する読みの推測をしない。
2. Markdown に直接貼り付けられる内容だけを出力し、説明やコードフェンスを付けない。
3. 先頭に {{lyrics-controls::ファイル言語}} を出力し、その後に <div class="my-lyric-box"> を1つだけ生成する。
4. 入力1行につき <div class="lyric-line"> を1つ使い、日本語原文を <div class="jp-lyric"> に入れる。
5. かなとローマ字がある場合は <ruby>原文<rt class="furi">かな</rt><rt class="roma">romaji</rt></ruby> を使う。
6. ローマ字だけなら <ruby>原文<rt class="roma">romaji</rt></ruby> を使い、信頼できる読みがなければ原文をそのまま残す。
7. 中国語訳は cn-lyric、英語訳は trans-lyric を使う。日本語ファイルまたは翻訳未入力では翻訳 div を生成しない。
8. 行数、順序、句読点、文字を厳密に維持する。単語単位の対応が不明な場合は、提供された1行分の読みを1つの ruby にまとめ、勝手に分割しない。
9. テキスト中の <、>、& をエスケープする。style、すべての on* 属性、script、iframe、id、指示されていない要素を出力しない。
10. すべての div、ruby、rt が正しく閉じていることを確認し、ボタンと歌詞コンテナの間には空行を1つだけ置く。

【ファイル言語】
zh / ja / en

【日本語原文:1行につき歌詞1行】
ここに貼り付け

【かな:任意、行数を原文と一致させる】
ここに貼り付け

【ローマ字:任意、行数を原文と一致させる】
ここに貼り付け

【翻訳:任意、行数を原文と一致させる】
ここに貼り付け

書き方

入力欄だけを次のように置き換えます。

【ファイル言語】
ja

【日本語原文】
間違い

【かな】
まちがい

【ローマ字】
machigai

【翻訳】

出力例

正しい AI 出力は次のようになり、そのまま楽曲本文へ貼り付けられます。

{{lyrics-controls::ja}}

<div class="my-lyric-box">
<div class="lyric-line">
<div class="jp-lyric">
<ruby>間違い<rt class="furi">まちがい</rt><rt class="roma">machigai</rt></ruby>
</div>
</div>
</div>

Ruby ルビ

表示する本文と読みだけを記述します。

{{ruby::局部壊死::きょくぶえし}}

文字単位で正確に対応させる場合は、短縮構文を続けて記述します。

{{ruby::観::かん}}{{ruby::測::そく}}{{ruby::所::じょ}}

表示結果:

  • かんそくじょ

初期状態で隠したい補足内容

短い内容には伏せ字構文、長い補足には次のブロック形式を使います。どちらも記事固有の JavaScript を必要としません。

spoiler の引数はプレーンテキスト専用です。{{spoiler::...}} の内側に **太字**、Markdown リンク、HTML を入れると、短縮構文がソースのまま表示されます。伏せ字全体を太字にする場合は **{{spoiler::隠す文字}}** と記述してください。見出し、リスト、リンクなどを隠す内容に混在させる場合は、次節の details ブロックを使用します。

記述例:

物語の結末:{{spoiler::初期状態では隠れる文字}}

表示例:

物語の結末:初期状態では隠れる文字

折りたたみと展開

対になる details マーカーを使います。開始・終了マーカーはそれぞれ独立した段落にし、前後に空行を置いてください。内部では通常の Markdown を使用できます。

{{details::全曲リストを表示}}

1. 1曲目
2. **2曲目**

{{/details}}

表示結果:

全曲リストを表示
  1. 1曲目
  2. 2曲目

通常の段落は空行で分けます。表のセルなど特殊な場所だけ、ホワイトリストに含まれる <br> を使用してください。

音声・動画の埋め込み

本サイトでは共通のメディア短縮構文を使用できます。次の構文を1行だけで記述すると、ビルド時にレスポンシブで安全な遅延読み込み iframe が生成されます。

@[プロバイダー](メディア ID または共有 URL "任意のタイトル")

プロバイダー名は youtubebilibiliapple-musicspotifyneteaseqq-music に対応しています。YouTube、bilibili、NetEase Cloud Music、QQ Music は動画・楽曲 ID の直接指定にも対応し、すべてのプロバイダーで一般的な共有 URL を使用できます。

@[youtube](3Wtx6k2vInU "花譜 - 糸")
@[bilibili](BV1CJ411b7Ym "花譜 - 糸")
@[apple-music](https://music.apple.com/cn/song/example/123456789)
@[spotify](https://open.spotify.com/track/4cOdK2wGLETKBW3PvgPWqT)
@[netease](2637083551)
@[qq-music](001ABCDEF)

表示例:

YouTube花譜 - 糸

集約メディア切り替え

同じ作品に複数プラットフォームの公式コンテンツがある場合、既存のメディア短縮構文を一つの集約ブロックにまとめられます。ページには選択中のソースと切り替えボタンが表示され、従来の単独 @[provider](...) 構文はそのまま利用できます。

コード構文
{{media-switcher::切り替えタイトル}}
@[1つ目のプロバイダー](メディアIDまたは共有URL "任意のキャプション")
@[2つ目のプロバイダー](メディアIDまたは共有URL "任意のキャプション")
{{/media-switcher}}
書き方
  • 作品名や「公式視聴」など、現在の言語に合うタイトルが必須です。
  • 各項目は従来のメディア構文を使い、対応プロバイダーと URL の検証規則も同じです。
  • 各行は空行を挟まず続けて記述できます。一行にまとめても解析されますが、レビューと保守のため、プラットフォームごとに一行で書くことを推奨します。
  • 一つのブロックには異なる 2–6 プラットフォームを指定できます。同じプロバイダーの重複、集約ブロックの入れ子、通常段落の混在はできません。
  • すべてのソースが有効である必要があります。不明なプロバイダー、危険な URL、不正な ID が一つでもある場合、ブロック全体は iframe を生成せず、修正できるようソーステキストを表示します。
  • JavaScript がない場合は検証済みプレイヤーを順番に表示します。JavaScript がある場合はボタン、方向キー、Home、End で切り替えられます。
実例
{{media-switcher::花譜 - 糸}}
@[bilibili](BV1CJ411b7Ym "花譜 - 糸")
@[youtube](3Wtx6k2vInU "花譜 - 糸")
{{/media-switcher}}

表示例:

花譜 - 糸

bilibili花譜 - 糸
YouTube花譜 - 糸

同じ Markdown 表のセルに複数の短縮構文を続けて記述すると、記述順に縦方向へ表示されます。そのセルには短縮構文と空白だけを記述し、説明文を混在させないでください。

| 作曲 | 作詞 | プレイヤー |
| --- | --- | --- |
| Wiz_nicc | Wiz_nicc | @[bilibili](BV13ZZNYQEQx) @[netease](2637083551) |

認識できないプロバイダーや URL は通常のリンクとして残り、任意の第三者 iframe は生成されません。新規コンテンツでは、許可プロバイダー、プライバシー属性、サイズ、スタイルを統一するため短縮構文を使用し、第三者サイトの生の <iframe> を貼り付けないでください。

アーティストページの外部リンク・ブランドカード

アーティストページでは、2 か所に公式リンクを記述できます。どちらも同じプラットフォーム判定とブランド表示を使いますが、記述方法は異なります。

情報欄の公式リンク

情報欄では frontmatter の officialLinks を使用します。各項目には表示名 label と完全な URL href の両方が必要です。

officialLinks:
  - label: "公式サイト"
    href: "https://kaf.kamitsubaki.jp/"
  - label: "YouTube"
    href: "https://www.youtube.com/@virtual_kaf"

本文の外部リンク

本文では、独立したレベル2見出し ## 外部リンク を正確に記述し、その直下に通常の Markdown 箇条書きリストを置きます。各リンクの文字列にはプラットフォーム名またはページ名を含めてください。

## 外部リンク

- [公式サイト](https://kaf.kamitsubaki.jp/)
- [YouTube](https://www.youtube.com/@virtual_kaf)
- [X (Twitter)](https://x.com/virtual_kaf)
  • - YouTube:<https://...>- <https://...>、説明文だけの項目は使用しないでください。これらの形式では完全なカードを生成できません。
  • 「出典と外部リンク」のような複合見出しは使用しないでください。根拠資料は独立した ## 出典 に、読者向けの公式サイトや SNS は ## 外部リンク に分けます。
  • 中国語・日本語・英語のアーティスト本文では、それぞれ 外部链接外部リンクExternal Links を使用します。サイトが認識できるよう、見出しを正確に記述してください。
  • JavaScript が有効な場合、アーティストページではリストがプラットフォーム Logo、ブランド色、外部リンク矢印を備えたレスポンシブなリンクカードになります。フォーム用ボタンではなく、移動用リンクとしての意味は保たれます。JavaScript がない場合は、読みやすくクリック可能な通常のリストとして残ります。
  • Bilibili、YouTube、X/Twitter、TikTok、Instagram、Weibo、Niconico、Spotify、Apple Music、NetEase Cloud Music、pixiv、piapro、Steam、Wikipedia、KAMITSUBAKI 公式サイトを識別できます。その他の URL には汎用サイト表示を使用します。
  • プラットフォームの SVG やリモート Logo 画像を本文へ貼り付けないでください。アイコンはサイト側で一元管理します。

PR 前チェック

  • ファイルパスと locale が対応し、各言語版で同じ translationKey を使っている。
  • 2 つの ---、YAML のインデント、フィールド型を壊していない。
  • 日付は YYYY-MM-DD、再生時間は MM:SS または HH:MM:SS
  • 新しい事実に信頼できる出典があり、リンクが開き、情報画像に適切な代替テキストがある。
  • アーティスト本文のリンクは独立した ## 外部リンク- [表示名](URL) のリストを使い、生の URL や複合見出しがない。
  • メディアは @[provider](...) を使用し、本文にスクリプト、イベント属性、認証情報、トークン、個人情報がない。
  • Preview / Changes に今回の変更だけがあり、他言語や無関係な内容を誤って削除していない。

属性ブロックガイド

記事を編集する際に、Frontmatterの属性が何を意味するのか分からない場合は、以下の説明を参照してください。

共通部分

以下の属性は、すべての記事カテゴリーで共通して使用されます。

  • locale:文書の言語版を示します。zh は中国語、en は英語、ja は日本語を表します。編集している記事の言語に対応する値を入力してください。
  • translationKey:同一記事の多言語版を関連付ける共通識別子です。同じ記事の中国語・日本語・英語ファイルには、同一の値を設定してください。

記述例:

locale: ja
translationKey: kaf-originals-shi

結果: このファイルは日本語コレクションに入り、同じ translationKey を持つ中国語・英語ファイルと関連付けられます。

アーティスト部分

最小例:

name: 花譜
romanizedName: KAF
statusLabel: 活動状態
status: 活動中
image: /images/artists/kaf.webp

表示結果: アーティストページに「花譜 / KAF」、活動状態、人物画像が表示されます。

属性必須役割と入力内容
localezh / ja / enはい現在の記事の言語
translationKey文字列はい同一人物の各言語版で共通して使用する識別子
code文字列いいえ人物番号、資料番号、または内部コード
name文字列はい現在の言語で表示する人物名
romanizedName文字列はいローマ字名、ラテン文字名、または国際表示名
categoryTitle文字列いいえ所属カテゴリーのメインタイトル
categorySubtitle文字列いいえ所属カテゴリーのサブタイトル、または英語による説明
categoryOrder数値いいえカテゴリー間の並び順。通常は小さい値ほど先に表示されます
itemOrder数値いいえ現在の人物を所属カテゴリー内で並べるための値
meta文字列いいえ一覧カードに表示する短い補足情報。役割、所属、短い概要などを記述します
debutDate文字列いいえデビュー日。YYYY-MM-DD 形式を推奨しますが、Schemaでは強制されません
profileTagline文字列いいえ人物詳細ページに表示する紹介用の短い文
designCredits文字列配列いいえキャラクターデザイン、ビジュアルデザイン、モデリングなどを担当した制作者の一覧
affiliations文字列配列いいえ所属レーベル、グループ、企画、または組織
officialLinksオブジェクト配列いいえ公式サイトおよび公式SNSへのリンク
officialLinks[].label文字列はいOfficial SiteYouTube などのリンク名
officialLinks[].href文字列はい公式リンクのURL
featuredEntriesオブジェクト配列いいえ人物ページで重点的に関連付ける他の記事
featuredEntries[].label文字列はい関連コンテンツの表示名
featuredEntries[].href文字列はい関連記事へのパス
featuredEntries[].kind固定列挙値はい関連コンテンツの種類。artistprojectalbumsong のいずれかのみ使用できます
theme共通テーマオブジェクトいいえ人物詳細ページで使用する個別の配色
statusLabel文字列はい「活動状況」など、状態欄に表示する見出し
status文字列はい「活動中」「活動終了」などの実際の状態
inactiveブール値いいえ非活動状態かどうか。通常、true は活動終了済み、またはアーカイブ済みであることを示します
image文字列はい人物のメイン画像、アイコン、または立ち絵へのパス
seo共通SEOオブジェクトいいえ現在の記事の検索エンジンおよび共有用情報

企画部分

最小例:

kind: project
title: 神椿市建設中。
description: 神椿の世界観プロジェクト
order: 10

表示結果: 企画は order 順に並び、タイトルと説明が一覧カードに使われます。

属性必須役割と入力内容
localezh / ja / enはい現在の企画記事の言語
translationKey文字列はい同一企画の各言語版で共通して使用する識別子
kind文字列はいprojectgamevirtual-world などの企画種類。Schemaでは固定値に制限されていません
title文字列はい企画名
description文字列はい企画の短い説明。通常は一覧カードやページの概要に使用されます
order数値はい企画一覧における並び順
seo共通SEOオブジェクトいいえ検索エンジンおよび共有用情報

ログ部分

最小例:

date: "2026-07-19"
type: update
title: サイト内容の更新
order: 10

表示結果: ログページに日付、種類、タイトルが表示され、order 順に並びます。

属性必須役割と入力内容
localezh / ja / enはい現在のログ記事の言語
translationKey文字列はい同一ログの各言語版で共通して使用する識別子
date文字列はいログの日付。YYYY-MM-DD 形式を推奨しますが、Schemaでは検証されません
type文字列はいupdatenoticemaintenance などのログ種類
title文字列はいログのタイトル
summary文字列いいえログの短い概要
order数値はいログの並び順
seo共通SEOオブジェクトいいえ検索エンジンおよび共有用情報

楽曲部分

楽曲ファイルは アーティスト ID / カテゴリ / 楽曲 ID / 言語.md の構造にします(例:songs/kaf/originals/shi/ja.md)。第1階層のアーティストフォルダが記事の正規保存先となり、カテゴリフォルダは関連する全アーティストの一覧で共通して使われます。推奨フォルダは originals(オリジナル曲)、covers(カバー曲)、genealogy(系譜曲)、suites(組曲)、collaborations(コラボ曲)、projects(企画曲)です。独自のフォルダも自動的に新しいカテゴリになります。

最小例:

title: 
artist: 花譜
artistId: kaf
releaseDate: "2018-12-06"
duration: "03:52"

複数アーティストで記事を共有する場合: 同一録音には楽曲フォルダを1つだけ作成します。代表となるアーティストを正規保存先に選び、artistId をパスの第1階層と一致させたうえで、掲載先となる全アーティスト ID を artistIds に記述します。たとえば「古傷」は songs/harusaruhi/collaborations/古傷-furukizu/ だけに保存します。

title: 古傷
artist: 幸祜×春猿火
artistId: harusaruhi
artistIds:
  - harusaruhi
  - koko
code: apple-1678038919

この場合、同じフォルダ内の zh.mdja.mden.md だけを管理すれば、同じ記事が春猿火と幸祜の「コラボ曲」一覧に表示され、どちらからも同じ正規ページへ移動します。songs/koko/ に本文、translationKey、画像情報を複製しないでください。artistIds には必ず artistId を含め、重複させないでください。artistId を先頭に置くことを推奨します。code を使う場合は録音ごとに一意とし、別の楽曲フォルダで再利用しないでください。

表示結果: 楽曲ページにタイトル、アーティスト、公開日、再生時間が表示され、artistIds に記載した各アーティストの楽曲一覧に分類されます。artistIds を省略した場合は artistId の一覧だけに表示されます。

属性必須役割と入力内容
localezh / ja / enはい現在の楽曲記事の言語
translationKey文字列はい同一楽曲の各言語版で共通して使用する識別子
title文字列はい楽曲タイトル
artist文字列はいメインアーティストまたは歌唱者名
artistId小文字英数字 IDはい正規保存先のアーティスト ID(例:kaf)。パスの最初のフォルダと一致させます
artistIds小文字英数字 ID のリストいいえ同じ記事を掲載する全アーティストの一覧。複数アーティスト曲では必須で、artistId を含め、重複させません
composer文字列いいえ作曲者
lyricist文字列いいえ作詞者
album文字列いいえ収録アルバム
duration文字列いいえ楽曲の長さ。03:45 形式を推奨しますが、Schemaでは検証されません
releaseDate文字列いいえリリース日。YYYY-MM-DD 形式を推奨します
code文字列いいえ録音固有の番号、資料番号、または内部コード。別の楽曲フォルダで重複させません
categoryTitle文字列いいえ所属カテゴリーのタイトル
categorySubtitle文字列いいえ所属カテゴリーのサブタイトル
categoryOrder数値いいえカテゴリー間の並び順
itemOrder数値いいえ所属カテゴリー内での楽曲の並び順
image文字列いいえ楽曲画像、シングルジャケット、またはアルバムジャケットへのパス
seo共通SEOオブジェクトいいえ検索エンジンおよび共有用情報

アルバム部分

最小例:

title: 観測α
artist: 花譜
type: Album
releaseDate: "2019-09-11"
tracks:
  - number: 1
    title: 
    songId: kaf/originals/shi

表示結果: アルバム情報と収録曲一覧が生成され、songId のある曲は本サイトの楽曲ページへ移動できます。

属性必須役割と入力内容
localezh / ja / enはい現在のアルバム記事の言語
translationKey文字列はい同一アルバムの各言語版で共通して使用する識別子
title文字列はいアルバムタイトル
romanizedTitle文字列いいえローマ字、ラテン文字、または国際表示用のタイトル
artist文字列はいメインアーティスト
type文字列いいえAlbumEPMini Album などの作品種別
description文字列いいえ詳細ページの見出し付近に表示する短い説明
releaseDate文字列いいえリリース日。YYYY-MM-DD 形式を推奨します
label文字列いいえリリースレーベル
catalogNumber文字列いいえ規格品番またはカタログ番号
trackCount数値いいえ総曲数
duration文字列いいえアルバムの総時間
code文字列いいえ一覧番号、資料番号、または内部コード
categoryTitle文字列いいえ所属カテゴリーのタイトル
categorySubtitle文字列いいえ所属カテゴリーのサブタイトル
categoryOrder数値いいえカテゴリー間の並び順
itemOrder数値いいえ所属カテゴリー内でのアルバムの並び順
image文字列いいえアルバムジャケットへのパスまたは URL
officialLinksオブジェクト配列いいえ公式ページ、購入、配信リンク。各項目に labelhref を指定します
tracksオブジェクト配列いいえ収録曲一覧。各項目の title は必須で、discnumberartistdurationsongId も指定できます
tracks[].songId文字列いいえ本サイト内の楽曲記事へのパス。例:kaf/originals/shi
theme共通テーマオブジェクトいいえアルバム詳細ページの配色
seo共通SEOオブジェクトいいえ検索エンジンおよび共有用情報

楽曲・アルバム補完基準

補完作業には、個別にレビューできる2段階の完成度があります。

  • カタログ掲載可能: パス、必須メタデータ、公式出典、ローカルの高解像度画像、公式リンク、最小限の本文が信頼できる状態です。曲目リンク、歌詞、長文の3言語化が未完成でも、不足範囲を明示すれば受け入れられます。
  • 完成記事: 確認済み曲目、サイト内楽曲リンク、本文、利用可能な歌詞資料、3言語を補います。不明な項目を埋めることは完成ではありません。
ディレクトリのコード構文
songs/<artistId>/<category>/<songId>/<locale>.md
albums/<artistId>/<albumId>/<locale>.md
書き方

楽曲はアーティスト、次に曲種で分類します。アルバムはアーティストとアルバム ID のみで整理し、アーティスト分類 UI をアルバムのフォルダに重複させません。artistIdsongIdalbumId は安定した小文字 slug を使い、3言語で同じ translationKey を共有します。

実例
src/content/songs/kaf/originals/shi/
├── zh.md
├── ja.md
└── en.md

src/content/albums/kaf/kansoku-alpha/
├── zh.md
├── ja.md
└── en.md
楽曲記事の受け入れ基準
  • パスの artistId、カテゴリ、songId がメタデータと一致する。該当する場合は originalscoversgenealogysuitescollaborationsprojects を再利用する。
  • 曲名、日付、クレジットは公式サイト、公式投稿の説明欄、正規リリースページ、信頼できるインタビューで確認する。AI 出力は出典ではない。
  • categoryOrderitemOrder は既存項目と衝突せず、公開順またはサイト内順序を安定させる。
  • image はリポジトリ内の実在する画像を参照し、期限付き URL、検索サムネイル、仮画像、不要な複製を使わない。
  • @[bilibili](BV...) など管理されたメディア構文を使い、生の <iframe>、自動再生、非公式再投稿を追加しない。
  • 本文で作品の概要と追跡可能な出典を示す。歌詞は任意。追加する場合は原文・翻訳・ローマ字を区別し、歌詞コントロールを再利用し、出典と著作権範囲を確認する。
  • zh.mdja.mden.md の同時追加を優先する。不足する翻訳や事実は PR に列挙し、架空の文章や仮文で埋めない。
アルバム記事の受け入れ基準
  • カタログ掲載可能の最低条件: 作品名、アーティスト、種類、確認済みリリース情報、公式ジャケット、少なくとも1件の公式または正規配信リンク、3言語共通の translationKey、出典に基づく短い本文。
  • Apple Music などの正規サービスまたは公式商品ページから取得できる最高品質のジャケットを優先する。可能なら正方形で 1500 × 1500 以上とし、検索サムネイル、スクリーンショット、仮画像、人工的な拡大画像を使わない。
  • ジャケットは public/images/albums/<artistId>/<albumId>.jpg に保存し、frontmatter では /images/albums/<artistId>/<albumId>.jpg を参照する。第三者画像 URL に依存しない。
  • trackCount は確認済み総曲数と一致させる。tracks を記載する場合はディスク番号、順序、曲名、アーティスト、時間を公式曲目表と照合する。
  • tracks[].songId はリンク先の楽曲記事が存在するときだけ追加する。未作成曲は title のみで保持し、壊れたリンクを作らない。
  • 通常盤、再発盤、リミックス盤、ライブ盤は公式に別リリースの場合のみ分け、別版の日付や曲目を混在させない。
  • 曲目や本文が不完全なら記事と PR の両方で範囲を示す。架空データで埋めず、完全収録と誤認させない。
  • 構造メタデータ、曲順、画像、リンクは3言語で揃え、表示名と本文だけを自然に翻訳する。
本文のコード構文
## 作品について

作品の位置づけ、リリース背景、確認済みの制作情報を説明します。

## 公式視聴

@[bilibili](BVxxxxxxxxxx)

## 補完状況

基本情報と公式リンクは完了済みです。曲目リンクは対応する楽曲記事の作成後に追加します。

## 出典

- [公式作品ページ](https://example.com/official)
- [Apple Music](https://music.apple.com/example)
書き方

出典が支える内容だけを断定します。補完状況では、何が完了し何が不足しているかをレビュー担当者と次の編集者に伝え、計画や推測を百科事実として書きません。

実例

現在の参考として src/content/songs/kaf/src/content/albums/kaf/public/images/albums/kaf/ を確認してください。提出前に次を実行します。

pnpm check
pnpm test
pnpm build

チェック通過は技術上の最低条件であり、出典、曲順、リンク、画像品質のレビューを代替しません。

高度な使い方:対応する生 HTML

通常は短縮構文が簡単ですが、旧記事の保守や細かなマークアップのため、従来の安全な HTML 形式も引き続き利用できます。HTML は前述のホワイトリスト内に限定され、styleonmouseoveronclickscript、生の iframe はサニタイザーによって削除されます。

HTML Ruby ルビ

記述例:

<ruby>局部壊死<rt>きょくぶえし</rt></ruby>
<ruby>観<rt>かん</rt>測<rt>そく</rt>所<rt>じょ</rt></ruby>

表示例:

局部壊死きょくぶえしかんそくじょ

HTML 伏せ字

インラインスタイルやマウスイベント属性に依存した旧形式は利用できません。安全な生 HTML では、サイト定義の wiki-spoiler クラスを使用します。

記述例:

<span class="wiki-spoiler" tabindex="0">初期状態では隠れる文字</span>

表示例:

初期状態では隠れる文字

HTML 折りたたみ

記述例:

<details>
  <summary>全曲リストを表示</summary>
  <p>この補足内容は初期状態では閉じています。</p>
</details>

表示例:

全曲リストを表示

この補足内容は初期状態では閉じています。

HTML の意味要素と改行

記述例:

<mark>重要</mark>
<abbr title="Virtual Witch Phenomenon">V.W.P</abbr>
<kbd>Ctrl+K</kbd> を押す<br>
H<sub>2</sub>O と x<sup>2</sup>

表示例:

重要V.W.PCtrl+K を押す
H2O と x2

生 HTML はホワイトリスト内の静的マークアップ専用です。メディアには @[provider](...)、歌詞操作には {{lyrics-controls::ja}} を使い、操作機能はサイトコードで一元管理してください。