この章の使い方
初めての投稿なら順番に進めてください。一部だけ困っている場合は目次から該当手順へ移動できます。例は既存項目に出典付きの情報を追加する修正です。架空の日付や告知 URL は用意していません。実際に確認できた資料を使ってください。旧版ガイドの「経路を選ぶ → ファイルを確認 → 必要な構文を調べる → 差分を見る → PR を提出 → チェックと審査を追う」という流れを、サイト内の投稿にも当てはめます。
先に四つの材料をそろえる
- 対象の項目。 データベースで名前と別名を検索し、原文の言語で項目を開きます。絞り込み結果が空でも、項目が存在しないとは限りません。
- 一次資料。 公式告知などのタイトル、発行元、URL、公開日、今回書く事実を直接裏付ける箇所を残します。画像だけでなく、可能なら元ページへのリンクを付けます。
- 修正したい一文。 現在の文、変更案、理由を先に書き出します。資料に月しかなければ日付を補いません。事実と解釈を分けます。
- 素材の権利。 画像の出所と使用根拠が分からない場合は、まず文章だけを投稿します。文章のライセンスは写真、ジャケット、歌詞、映像には及びません。出典と権利を確認してください。
手順 1：項目から編集を開く
本文と参考資料を読み、同じ情報がまだ追加されていないことを確認します。「項目を改善」または「ソースを編集」からエディターを開き、上部の対象項目、言語、ファイルを確かめます。新規項目は投稿選択で百科項目を選び、実体の種類と原文言語を指定します。同じ実体の中国語・日本語・英語の原稿には同じ安定 ID を使います。繁体字は中国語の原稿から生成されます。
GitHub では項目のソースリンクから src/content/ 以下の対象を探します。dist/、.astro/、node_modules/ は編集しません。旧版で勧めた人物項目の構成（概要、活動の位置付け、経歴、代表作、関連企画、参考資料、公式リンク）は今も参考になります。ただし実体の種類と既存本文に合わせ、確認済みの情報は残してください。
手順 2：資料が裏付ける範囲だけ直す
サイト内エディターは既存本文を読み込みます。言語を選び、適切な節に事実を追加してください。日付、関係、クレジットなどに専用欄があれば、本文だけでなくその欄にも入力します。知らない拡張記法は理解してから変更します。内容と表記の完全ガイドには構成、分類、出典、日付、プライバシー、多言語の基準があります。構文と属性の完全ガイドには frontmatter、Markdown、ルビ、折りたたみ、メディア、歌詞の例があります。
たとえば資料が「2026 年 9 月に企画がイベントを告知した」としか示さない場合、「2026 年 9 月」は書けますが「9 月 1 日」は書けません。資料にない出演者、場所、名称も追加しません。引用は事実の近くに置き、参考資料に元のタイトルと URL を残します。不確かな点は確認待ちと明記し、推測で欄を埋めないでください。
項目の添付画像と画像アーカイブは別の投稿です。 項目の画像はその項目の GitHub 提案に含まれます。アーカイブには単独の画像を直接投稿するか、設定セットを作成できます。人物や種類は後から提案できますが、画像ごとの作者・出典・利用根拠は必要です。設定画一式を項目の添付画像として投稿しないでください。根拠のある公式ビジュアルから局所的なテーマ色を選べますが、根拠がなければ既定の UI を使います。UI の配色は作品画像の色を失わせません。
手順 3：プレビューと差分を確認する
エディターのプレビューで見出し、目次のアンカー、画像、リンク、引用を確認します。変更差分では今回の意図した箇所だけが変わっているか調べます。端末への下書き保存は審査への提出ではありません。 通信が切れたら、更新前に下書きを書き出すかコピーしてください。
GitHub では自分のブランチまたは Fork で変更し、YAML frontmatter の引用符と字下げ、id・locale・entityType を確かめます。新しい言語ファイルでも同じ実体 ID を保ちます。pnpm test、pnpm check、pnpm build を実行し、PR の Files changed で差分を見直します。失敗したときは実際のエラー行を読み、無関係なファイルを変更しないでください。
手順 4：提出、審査、公開確認
サイトでは「審査に提出」を押し、記録番号または PR のリンクが表示されるまで待ちます。クリエイターセンターで同じ記録を確認してください。「保存済み」「一時アップロード済み」はまだ前の段階です。タイムアウト後は重複投稿の前に既存記録を確認します。修正依頼を受けたら同じ投稿を開いて対応します。
GitHub では対象項目、出典、修正理由、実行した確認を書いて Pull Request を作成します。同じ PR で審査コメントに返信し、同じブランチに修正を push します。GitHub だけの投稿はサイトのクリエイターセンターに自動で現れない場合があります。CI 成功、承認、マージ、サイト公開は別々の段階です。公開後に実際の項目を開いて内容を確認してください。年表の修正では公開イベントの版も確認します。
他の投稿への当てはめ
| 種類 | 先に準備するもの | 結果の確認場所 |
|---|---|---|
| 記事 | 論点、著者、出典、関連項目 | プレビュー、審査記録、公開記事 |
| 画像アーカイブ | 画像ごとの作者・出典・利用根拠。人物・種類・タグ・セットは後から追加可能 | 非公開の一時保存、画像ごとの審査、分類提案、公開画像 |
| 年表 | 日付の精度、トラック、関連項目、確認可能な出典 | イベントのプレビュー、PR、公開版 |
一日だけの出来事は点、継続する出来事は実際の期間に応じた長さになります。年または月までしか分からない場合は不確定な区間として扱います。サイト内から新規追加も修正もできます。GitHub では新しいイベントを独立した YAML ファイルに置き、修正時は対象のイベントだけを変更します。
AI には整理と確認を頼む
集めた資料を AI に渡して構成や不足を確認できます。AI の回答は一次資料の代わりにならず、資料にない日付、人物、権利、翻訳を補えません。 次の文を自分の資料に合わせて使ってください。
KAMITSUBAKI Wiki の [項目名と言語] について [主張] を修正します。以下に貼る資料だけを使い、①直接確認できる事実と該当箇所、②年・月・日のどこまで分かるか、③追加で確認すべき点、④掲載する節を列挙してください。出典のタイトルと URL を残し、引用や画像の使用許諾を作り出さないでください。資料：[タイトル、URL、関連する原文]
修正前後の文章を出典と照らし、資料にない主張、離れた引用、誤って削除した正確な情報、推測を事実として書いた箇所を一文ずつ指摘してください。新しい事実は追加しないでください。修正前：[文] 修正後：[文] 出典：[文]
提案は必ず元ページで人が照合します。歌詞、翻訳、画像の署名、タイムスタンプは特に再確認してください。旧版の歌詞整形用プロンプトと拡張記法は完全構文ガイドに残しています。
最後の確認
- 名前と別名を検索し、重複した項目・イベントを作っていない。
- 新しい事実に元資料があり、日付の精度も資料に一致する。
- 正しい既存本文、引用、分からない拡張記法を誤って削除していない。
- 画像、歌詞、第三者の文章について使用の根拠を確認した。
- プレビューで見出し、画像、リンク、目次が使える。
- 投稿記録または GitHub PR を実際に作成した。下書き保存だけでは提出にならない。
- マージ後も公開ページを確認してから「公開済み」と判断する。