統一コンテンツスタイルガイド - 神椿観測所-KAMITSUBAKI Fan Wiki

このガイドは、サイト内の内容をどのように構成し、書くかを説明します。投稿の手順はコントリビューションガイド、Markdown・frontmatter・メディア構文は構文属性ガイドを参照してください。

すべての記事を同じ形にすることが目的ではありません。読者が内容を理解して出典を確認でき、次の編集者が安全に更新できる状態を目指します。記事に不要な見出しを、テンプレートを埋めるためだけに作らないでください。

適用範囲とルールの強さ

このガイドは、導入部、本文、見出し、frontmatter、情報カード、参考資料、リンク、メディア説明に適用します。歌詞原文、直接引用、作中の台詞、公式名称、コード、データフィールドの値は、本文の文体に合わせて書き換えず忠実に保持します。その周囲の説明文には本ガイドを適用します。

「必須」「してはいけない」は、事実の正確性、プライバシー、安全、出典、サイト構造に関する強制要件です。
「するべき」「優先する」は通常の推奨です。異なる形を採用する場合は、内容または可読性に関する明確な理由が必要です。
「できる」は記事に応じて選択でき、すべての記事に要求されるものではありません。
著作権、プライバシー、資料の内容、サイト schema、または構文属性ガイドと矛盾する場合は、それらを優先します。判断できない場合は原文を維持し、Pull Request で説明します。

基本原則

検証できる内容を書く

日付、作品情報、所属、経歴、発言、順位、評価などの記述には、その内容を直接裏付ける公開情報が必要です。

発売日、収録曲、出演者、公式発表などは、公式サイト、作品ページ、公式ストア、公式アカウントを優先します。
制作過程や経歴には、正式なインタビュー、イベント資料、出版物を利用します。
評価、影響、論争、業界内での位置づけには、信頼できる独立した二次資料を優先し、誰の評価なのかを明記します。
信頼できる資料が見つからない情報は書きません。AI の出力、検索結果の要約、別の Wiki、転載まとめは元資料の代わりになりません。

これは Wikipedia の検証可能性と信頼できる情報源の考え方に沿っています。リンク先には、直前の記述を実際に確認できる情報が必要です。

中立的に書き、意見の帰属を示す

記事は事実と重要な見解を説明する場所であり、アーティスト、企画、ファン、批評者の立場を宣伝する場所ではありません。「伝説的」「史上最高」「当然」「悲惨な失敗」など、評価を事実のように書く表現を避けます。

資料に評価がある場合は、その評価を行った人物や媒体を主語にします。

非推奨：この曲は時代を変えた最高傑作である。

推奨：音楽メディア X は、2025 年のレビューでこの曲をグループの作風転換を示す作品と評した。[出典](https://example.com/review)

このページの example.com リンクはすべて書式例であり、実際の記事の出典には使用できません。

意見が分かれる話題では、信頼できる資料で確認できる主要な見方を、その扱いの大きさに応じて説明します。本文で勝敗を決めたり、形式的に同じ分量を割り当てたりしません。詳しくは Wikipedia の中立的な観点を参照してください。

独自の推論を加えない

資料 A がイベント出演を伝え、資料 B が同日に楽曲公開を伝えていても、それだけで両者の因果関係は証明されません。衣装、声、投稿時間、アカウントの動き、断片的な発言から、身元、関係、動機、未発表企画を推測しないでください。

資料が明確に述べている内容は要約できますが、複数の資料を組み合わせて、どの資料にもない新しい結論を作ってはいけません。Wikipedia の独自研究は載せないも参照してください。

正確・簡潔・一貫

理解しやすい短い文を優先し、一つの段落では一つの話題を扱います。既存の記事内で名称、日付、約物の使い方が合理的に統一されている場合は維持します。変更する場合は、正確性または可読性が明確に向上する範囲で行います。

記事名と固有名詞

記事名は認識しやすく、正確で簡潔、かつ同種の記事と一貫したものにします。原則として現在の公式表記を使用し、特殊な大文字・小文字、空白、句読点、全角・半角を独自に直しません。これは Wikipedia の記事名の考え方にも沿っています。

人名、アーティスト名、グループ名、曲名、企画名は、初出時に公式原文と対象言語で一般的な表記を併記できます。
以後は明確な一つの短縮形に統一し、同じ段落でローマ字、原文、翻訳名を頻繁に切り替えません。振り仮名とローマ字を同時に示す場合は、ruby で振り仮名を付け、括弧内にローマ字を添えます。具体的な構文は構文属性ガイドに従います。
同名の記事があるときだけ、区別に必要な最小限の曖昧さ回避を追加します。
独自の略称や翻訳名を作りません。非公式訳が理解に必要な場合は暫定訳であることを示し、公式名を残します。
URL のディレクトリ名、translationKey、frontmatter の規則は構文属性ガイドに従います。表示名の変更だけを理由に安定した識別子を変更しません。

導入部と見出し構成

導入部で三つの点を伝える

ページタイトルは frontmatter から生成されるため、本文で # のタイトルを繰り返さず、短い導入文から始めます。

対象が何であるか。
KAMITSUBAKI、関連アーティスト、企画とどのような関係があるか。
信頼できる資料に基づく、最も重要な識別情報は何か。

導入部は本文の要約です。本文で説明していない新しい評価を置きません。短い記事は一段落、情報量の多い記事でも通常は二、三段落にまとめ、詳細な年表や全曲目を冒頭に詰め込みません。

本文は二級見出しから始める

主要な節には ##、その下位には ### を使い、階層を飛ばしません。見出しは短い名詞句にし、「その他」「いろいろな情報」のような内容を予測できない表現や、リンク・太字・装飾記号を避けます。

## 概要
## 活動歴
### 2024年
## 主な作品
## 参考資料
## 外部リンク

対象の説明、経歴・作品・関係、出典・外部リンクの順に、読者が理解しやすい流れで構成します。年表は原則として古い順です。最新情報を読むためのログを新しい順にする場合も、一つの一覧内では順序を統一します。

記事種別ごとの推奨構成

以下は出発点です。内容のない節は削除し、必要に応じて意味の明確な節を追加してください。

アーティスト・キャラクター

導入

## 概要
## キャラクターと創作上の位置づけ
## 基本情報・設定
## 活動歴
## 主な作品
## 関連企画
## 参考資料
## 外部リンク

実在人物の情報とキャラクター設定を区別します。作中設定、公式プロモーション上の設定、現実の活動を同じ事実として混ぜません。中の人や非公開の身元に関する記述には、後述するプライバシー基準を適用します。

楽曲

導入

## 作品概要
## リリースとバージョン
## 制作・出演
## 視聴
## 参考資料

歌詞、翻訳、ルビ、単語単位のタイムラインは構文属性ガイドの構造を使います。クレジットは正式な表記を根拠にし、聴感だけで楽器、サンプル、歌唱者を推測しません。

アルバム・リリース

導入

## 作品概要
## リリースとバージョン
## 収録内容
## 参考資料
## 外部リンク

frontmatter に収録されている発売日、品番、曲目などを本文で機械的に繰り返しません。本文では、版の違い、背景、説明が必要な事実を補います。

企画・イベント

導入

## 概要
## 沿革
## メンバーと関連項目
## 作品・活動
## 参考資料
## 外部リンク

「発表」「開始」「開催」「発売」「終了」を区別します。予告日を開催日や発売日として扱いません。まだ行われていない公演や発売は「予定」「計画」などと明記し、公式情報が変更された場合は更新します。物語や ARG では、作中の出来事、プロモーション設定、現実の出来事を明示的に分けます。

観測ログ

明確な日付と一つの出来事を中心に、何が起きたか、その出来事が記録対象とどう関係するかの順で書きます。リアルタイムの推測、ファンの噂、未確認の計画を事実として残しません。後日の発表で状況が変わった場合は、必要な時系列を残しながら記述を更新します。

Frontmatter と情報カード

frontmatter はページ、一覧、検索インデックスが利用する構造化データで、情報カードは読者向けの視覚的な要約です。中心となる事実は一致させますが、同じ文を繰り返す必要はありません。
フィールド名、型、日付形式、許可された値は構文属性ガイドと content schema に従います。認識されないフィールドを独自に追加しません。
情報カードには、すばやく確認する価値のある安定した事実だけを置き、個人的な評価、宣伝文、ファンの議論、未確認の推測を入れません。
名称、画像、所属には公式資料を優先します。掲載価値のある非公式な整理情報は、まず本文で出典と性質を説明します。未確認情報を「非公式」と表示するだけで情報カードへ移してはいけません。
アーティスト frontmatter の code は、サイトで既に使われているレーベル番号体系を引き継ぎます。Phenomenon Record は P と数字、SINSEKAI RECORD は S と数字、Girls Revolution Project は G と数字を使用します。既存記事または管理資料で確認できる番号だけを記録し、並び順から推測しません。

文体と段落

説明的で節度のある文体を使い、宣伝文、感想、読者への呼びかけ、過度な感嘆を避けます。
一段落で一つの話題を扱い、話題が変わるときは段落を分けます。
主語を明確にします。複数の人物や団体が続く箇所で、曖昧な「彼ら」「それ」を使いません。
「昨日」「最近」「今年」ではなく、絶対日付を書きます。
太字を見出しの代わりに使わず、段落全体を太字にしません。
引用は理解に必要な短い範囲にとどめ、発言者と出典を示します。それ以外は意味を変えず自分の言葉で要約します。
frontmatter、情報カード、直前の本文にある情報を、完全さを演出するためだけに繰り返しません。

日付・時刻・数値

frontmatter の日付は構文上の YYYY-MM-DD、YYYY-MM、YYYY を使います。本文では各言語に自然な表記にします。

日本語：2025年3月14日
中国語：2025年3月14日
英語：14 March 2025

月までしか判明していない場合は日を補いません。年しか判明していない場合も月を推測しません。配信、発売、発表の時刻がタイムゾーンに依存する場合は、20:00（UTC+8） や 21:00（JST） のように明記します。複数の意味を持つ CST を単独で使用しません。

年齢、順位、再生数、メンバー数など変動する数値には、基準日または集計範囲を付けます。

2026年7月時点で、公式ページには12曲が掲載されている。[出典](https://example.com/official)

箇条書き・表・年表

背景や関係の説明には段落、並列項目には箇条書き、同じ項目を横に比較するデータには表を使います。短い二文を見栄えのためだけに表へ変換しません。

一つの箇条書きでは、すべて日付から始める、すべて作品名から始めるなど文法をそろえます。
表の各列は一つの意味だけを持ち、見出しだけで内容が分かるようにします。長い説明は表の外へ移します。
年表は日付の精度と並び順を統一します。
不明な値は「未公表」と書き、0 で代用しません。
モバイルで読みにくい横長の表は、小さな表または箇条書きに分けます。
複雑な年表やイベント表では、本文で主要な出来事を先に要約し、完全なデータを付録または子ページに置くことができます。
長い表が本文の流れを妨げる場合は、構文属性ガイドで対応している折りたたみ構造を使用できます。見出しで内容を説明し、重要な結論を折りたたみ領域だけに置きません。
説明文は通常左揃え、短い状態値は中央揃え、桁を比較する数値は右揃えにできます。同じ列では一つの揃え方を維持します。

出典と参考資料

内容に合う資料を選ぶ

内容	優先する資料	注意点
発売日、曲目、メンバー、告知	公式サイト、公式ストア、作品ページ、公式アカウント	公式自身が公表した事実の範囲で使う
経歴、制作過程	正式なインタビュー、イベント資料、出版物	当事者の発言と記者の判断を区別する
評価、影響、論争	編集体制のある独立媒体、研究、専門出版物	見解の帰属を示し、扱う分量を調整する
ランキング、統計	チャートやプラットフォームの原ページ	チャート名、地域、集計日を書く
過去のウェブページ	信頼できるウェブアーカイブ	元ページ名とアーカイブであることを示す

Wikipedia は手掛かりを探すために利用できますが、最終的な出典ではありません。掲載情報を使う前に、そこで参照されている元資料を開き、自分の記述を直接裏付けているか確認します。

出典を記述の近くに置く

出典は、それが裏付ける文または段落の近くに置きます。記事末尾に用途不明のリンクをまとめるだけにせず、リンク文字にはページ内容が分かる名称を使います。

推奨：このシングルは2025年3月14日に発売された。[公式リリースページ](https://example.com/release)

非推奨：このシングルは2025年3月14日に発売された。

## 参考資料

- [ここをクリック](https://example.com/release)

一つの資料が連続する数文を支える場合は段落末に一度置けます。複数の資料や性質の異なる評価が混在するときは、個別に示します。

存命人物・プライバシー・論争

存命人物については、情報量より正確性とプライバシーを優先します。信頼できる公開資料のない本名、住所、学校、家族、健康、財産、私的アカウント、身元の推測、人間関係の争いを書きません。断片を組み合わせて本人を特定できるようにする行為も避けます。

否定的、または名誉を損なう可能性のある情報には、高品質な資料と記事主題への明確な関連性が必要です。噂、匿名投稿、ファン間の議論しかない場合は掲載しません。参考として Wikipedia の存命人物の伝記も確認してください。

多言語の記事

本サイトは中国語の zh.md、日本語、英語の三つを編集元として維持します。簡体字・台湾繁体字・香港繁体字を混在できる中国語源から、正規化された簡体字、台湾繁体字、香港繁体字ページを自動生成し、公開 locale は五つです。中国語源の字形を事前に統一する必要はありません。各言語の記事は同じ中核事実を伝えますが、語順、約物、説明の密度は各言語に合わせて構いません。逐語訳にする必要はありません。

公式名、日付、数値、カタログ番号、URL は言語間で一致させます。
翻訳時も出典を再確認し、元言語の記事にあるだけで正しいと判断しません。
一般的な訳名がない場合は公式原名を残し、初出時に短く説明します。
機械翻訳を完成稿にせず、人名、敬称、省略された主語、作品固有の文脈を人が確認します。生成 AI は翻訳の補助に利用できますが、事実や訳文の出典ではありません。出力を採用する場合は一文ずつ確認・修正し、プロジェクトの要件に従って AI 補助の使用を明記します。
重要な事実を追加・削除するときは、可能な範囲で三つの編集元を同期します。簡体字、台湾繁体字、香港繁体字ページは中国語の zh.md 源から正規化または再生成されます。
生成された zh-tw / zh-hk を直接編集しません。通常の簡繁混在は修正不要です。自動変換で判断できない少数の文脈依存語は {{zh-variant::簡体字::台湾繁体字::香港繁体字}} で指定し、複数記事で使う公式固有名詞の誤変換は public/TraditionalChineseConvert.json で管理します。
台湾・香港ページは地域で一般的な語彙を使えますが、地域差を作るためだけに事実や語調を書き換えません。
中国語の変更をレビューするときは、簡体字と両方の繁体字版で、後／後、发／發／髮、干／乾／幹、里／裡、台／臺、制／製、面／麵、复／復／複など曖昧な変換を確認します。

リンク・画像・メディア

内部リンクには対象が分かる記事名を使い、「ここをクリック」と書きません。外部リンクは主に記述直後の出典か、記事末尾の独立した「外部リンク」節に置きます。外部リンク節は公式サイト、公式アカウント、継続的に価値のあるページのためのもので、参考資料とは分けます。

画像とメディアには、明確で適法な利用根拠が必要です。代替テキストには理解に必要な画像内容を書き、「画像」やファイル名だけにしません。キャプションは事実に限定し、必要な作者、日付、出典を示します。検索・翻訳できる文字を画像だけで伝えたり、装飾目的で宣伝画像を並べたりしません。

プレイヤー、歌詞部品、ルビ、画像パスの具体的な構文は構文属性ガイドに従います。

編集範囲と共同作業

一つの変更は「発売日の公式出典を追加」「記事内のアーティスト名を統一」「長すぎる活動歴を整理」のような明確な目的にまとめます。日付を一つ追加する作業と同時に記事全体を書き換えないでください。

既存の形式が正確で読みやすく、記事内で一貫しているなら、個人の好みと違っても通常は維持します。大規模な改名、節構成の変更、出典付き内容の削除を行う場合は、Pull Request で理由を説明します。

コミットや Pull Request の説明には結果と理由を書き、「更新」「既知の問題を修正」のように審査範囲を判断できない説明を避けます。

content(kaf): 2025年の出演記録と公式出典を追加
docs(format): 楽曲記事の日付とバージョン節を統一

よくある修正例

宣伝表現を確認可能な事実へ

修正前：比類のない歌声で一気に大ブレイクした。

修正後：2024年に最初のシングルを発表し、同年12月までに同曲はXチャートのトップ10に入った。[発売資料](https://example.com/release) [チャート資料](https://example.com/chart)

相対的な時期を絶対日付へ

修正前：最近、新しい公演への出演が発表された。

修正後：公式は2026年7月18日、9月2日に開催されるX公演への出演を発表した。[公式発表](https://example.com/news)

推測を資料が支える範囲へ

修正前：同日に予告が公開されたため、二つの企画は同じ世界観である。

修正後：二つの企画はともに2025年6月1日に予告を公開した。同日時点で、公式は両企画の関係を説明していない。[企画A](https://example.com/a) [企画B](https://example.com/b)

投稿前チェック

タイトル、導入部、節の順序だけで、初めて読む人も対象を理解できますか。
新しく追加した事実に、それを直接裏付ける公開資料がありますか。
事実、資料内の評価、編集者自身の意見を区別しましたか。
独自推論、宣伝表現、噂、不要な個人情報を除きましたか。
名称、大小文字、日付、タイムゾーン、数値、約物は統一されていますか。
箇条書きや表は文章より分かりやすく、モバイルでも読めますか。
内部リンク、外部リンク、代替テキスト、メディアの出典は正確ですか。
三つの編集元と二つの繁体字派生で重要な名称、数値、リンクが一致していますか。
今回の目的に関係する箇所だけを変更し、プレビューで差分を確認しましたか。
Markdown と frontmatter は構文属性ガイドに適合していますか。

参考資料

このガイドはサイト固有の構成に合わせ、Wikipedia の次の編集原則を参考にして書き直したものです。以下のリンクは編集方法の根拠を示すもので、記事の事実に必要な元資料を代替しません。

Manual of Style：明確、簡潔、一貫した構成と文体。
Neutral point of view：重要な見解を公平に扱い、帰属を示すこと。
Verifiability：重要な記述を読者が確認できること。
Reliable sources：内容の性質に合う資料を選ぶこと。
No original research：資料にない新しい結論を編集者が作らないこと。
Article titles：認識しやすく、正確で簡潔、一貫した名称。
Biographies of living persons：プライバシー、論争、害を生む可能性のある情報を慎重に扱うこと。