deploy

name	deploy
description	ZpDIC Online を新しいバージョンとしてリリース (デプロイ) するための手順。develop ブランチで開発が一段落し、バージョンを上げて master に反映・公開したいときに使う。「デプロイして」「リリースして」「新しいバージョンを出して」「バージョンを上げて公開して」など、リリース・デプロイ・バージョン更新に関する依頼が出たら必ずこの skill を使うこと。git のバージョンインクリメント・master へのマージ・タグ付け・origin への push という一連の定型作業を、固定のコミットメッセージとタグメッセージで正確に実行する。

デプロイ手順

ZpDIC Online を新しいバージョンとしてリリースする。 develop で開発した内容のバージョンを上げ、master にマージしてタグを付け、origin に push する。

各コミットメッセージ・マージメッセージ・タグメッセージは固定の文言を使う。 勝手に言い換えたり、英語にしたりしないこと。

全体の流れ

1. 事前確認 (ブランチ・working tree)
2. ビルドが通るかの確認
3. バージョン番号のインクリメント
4. バージョン変更のコミット
5. 実行前の最終確認 (確認ゲート)
6. master へのマージ
7. タグ付け
8. origin への push
9. develop に戻る
10. Notion のマイルストーンのページを編集する (major / minor アップデートのときのみ)
11. リリース内容のお知らせ文をまとめて提案する

破壊的・外部反映を伴う操作 (マージ・タグ・push) に入る前に、後述の「実行前の最終確認」でユーザーに一度確認してから進めること。

Step 1: 事前確認

現在のブランチと working tree の状態を確認する。

git status

確認する内容:

• develop ブランチにいることを確認する。違うブランチにいる場合は、ここで中断してユーザーに報告する (勝手に develop に切り替えない)。
• working tree が clean であることを確認する。未コミットの変更がある場合は中断してユーザーに報告する。

両方を満たしている場合のみ次に進む。

クラウド環境で実行中の場合

クラウド環境 (Claude Code on the web) では、セッションは develop ではなく自動生成された作業ブランチ (claude/...) 上で開始する。 この場合に限り、以下の両方を満たすときは、確認を挟まずに自動的に develop に移動して手順を続行して良い。

• クラウド環境で作業していること。
• 現在のブランチと develop の間に差分がないこと (現在のブランチの内容が origin/develop と一致していること)。まず git fetch origin develop してから比較する。

この条件を満たす場合は、develop に移動し、ローカル develop が古ければ origin/develop に揃えて (fast-forward) 続行する。 上記のいずれかを満たさない場合 (develop との間に差分がある, ローカル環境である, working tree が clean でない等) は、これまで通り中断してユーザーに確認する。

Step 2: ビルドが通るかの確認

リリース前に、本番ビルドが正常に通ることを確認する。

npm run build

注意点:

• ビルドが失敗した場合は、ここで中断してユーザーにエラー内容を報告する。バージョンインクリメント以降の操作には進まない。
• ビルドが成功した場合のみ次に進む。

Step 3: バージョン番号のインクリメント

package.json の version フィールドを読み取る。 値は semver 形式 (X.Y.Z)。

AskUserQuestion を用いて、major, minor, patch のうちのどの部分をインクリメントするかをユーザーに確認する。

• major (X) — X.Y.Z → (X+1).0.0
• minor (Y) — X.Y.Z → X.(Y+1).0
• patch (Z) — X.Y.Z → X.Y.(Z+1)

インクリメント後のバージョン番号 (以降この手順では X.Y.Z と表記) を確定させ、package.json の version の値だけを更新する。 他のフィールドには触れない。

Step 4: バージョン変更のコミット

package.json の変更のみをコミットする。 他のファイルを巻き込まないよう、明示的に package.json だけをステージする。

git add package.json
git commit -m "バージョン番号を変更"

コミットメッセージは バージョン番号を変更 で固定。

Step 5: 実行前の最終確認 (確認ゲート)

ここから先 (マージ・タグ・push) は取り消しが難しく、push は外部 (origin) への反映を伴う。 実行前に、これから行う内容を簡潔にユーザーへ提示して一度確認を取る。

確認は AskUserQuestion を使い、ワンクリックで進められるようにする。 質問文や選択肢の説明の中で、以下の内容が伝わるようにする。

伝える内容:

• インクリメント後のバージョン (X.Y.Z)。
• これから master に develop をマージし、vX.Y.Z タグを付け、develop・master・タグを origin に push すること。

選択肢は「進める」「中止する」のような 2 択にし、ユーザーが「進める」を選んだ場合のみ次に進む。

Step 6: master へのマージ

master をチェックアウトし、develop を fast-forward なし (--no-ff) でマージする。

git checkout master
git merge --no-ff develop -m "developブランチをマージ"

注意点:

• --no-ff を必ず付け、マージコミットを作る (fast-forward させない)。
• マージコミットメッセージは developブランチをマージ で固定。

Step 7: タグ付け

直前のマージコミットに注釈付きタグを付ける。

git tag -a vX.Y.Z -m "verX.Y.Zをリリース"

注意点:

• タグ名は vX.Y.Z (例: バージョンが 3.25.0 なら v3.25.0)。
• タグメッセージは verX.Y.Zをリリース で固定 (例: ver3.25.0をリリース)。

Step 8: origin への push

develop ブランチ・master ブランチ・作成したタグを origin に push する。

git push origin develop master
git push origin vX.Y.Z

クラウド環境で実行中の場合

クラウド環境では GitHub 連携 (GitHub App) の権限が作業ブランチへの push に限定されており、タグ ref (refs/tags/*) の push は 403 Forbidden で失敗する可能性が高い (ブランチの push は成功する)。 これは一時的な問題ではなく恒常的な制約である。

そのため、クラウド環境ではタグの push (git push origin vX.Y.Z) は無理に試みず、スキップする。 ブランチ (develop・master) の push のみ行う。 タグはローカルに作成したまま残し、最後にユーザーへ「タグはローカル権限のある環境で以下を実行して push してほしい」と、コマンドを添えて報告する。

git fetch origin master
git tag -a vX.Y.Z origin/master -m "verX.Y.Zをリリース"
git push origin vX.Y.Z

ローカル環境で実行している場合は、従来どおりタグも push する。

Step 9: develop に戻る

作業ブランチを develop に戻して終了する。

git checkout develop

最後に、リリースしたバージョン (X.Y.Z) と付けたタグ (vX.Y.Z) をユーザーに報告する。

Step 10: Notion のマイルストーンのページを編集する

開発マイルストーンを管理している Notion のデータベースに、今回のリリースを反映する。 Notion の操作には Notion の MCP ツール (notion-query-data-sources, notion-update-page, notion-create-pages など) を用いる。

Step 3 で major もしくは minor バージョンをインクリメントした場合のみ行う。 patch アップデートの場合はこのステップをスキップし、そのまま Step 11 に進む。

対象のデータベース:

• マイルストーンのデータソース — collection://08baa6dd-18b0-430a-83fb-5c4e0fd3a3ce
• 関連するプロパティ:
  • 名前 (タイトル) — ver X.Y.Z の形式 (ver の後に半角スペース, 例: ver 3.27.0)
  • ステータス (select) — Released を設定する
  • リリース日 (date, 表示形式 YYYY/MM/DD) — 更新・作成時は展開プロパティ date:リリース日:start に ISO 形式の日付 (YYYY-MM-DD) を渡す
  • プロジェクト (relation) — 「ZpDIC Online (version 3)」プロジェクトのページ (https://app.notion.com/d044b0bb27c3486a80a22e291fe99062), 値は URL の JSON 配列文字列 ["https://app.notion.com/d044b0bb27c3486a80a22e291fe99062"] で渡す。

まず対象ページが既に存在するか確認する。 notion-query-data-sources で、プロジェクト が「ZpDIC Online (version 3)」(d044b0bb27c3486a80a22e291fe99062) かつ 名前 が ver X.Y.Z のページを検索する。

SELECT url, "名前", "ステータス" FROM "collection://08baa6dd-18b0-430a-83fb-5c4e0fd3a3ce"
WHERE "名前" = 'ver X.Y.Z' AND "プロジェクト" LIKE '%d044b0bb27c3486a80a22e291fe99062%'

ページが存在するかどうかに応じて、以下の操作を行う。

ページが存在する場合

そのページを notion-update-page (command: "update_properties") で更新する。 「今日の日付」は実際の現在の日付を用いる。

• ステータス = Released
• date:リリース日:start = 今日の日付 (YYYY-MM-DD)

ページが存在しない場合

notion-create-pages で新たにページを追加する (parent は data_source_id: "08baa6dd-18b0-430a-83fb-5c4e0fd3a3ce")。 「今日の日付」は実際の現在の日付を用いる。

• 名前 = ver X.Y.Z
• ステータス = Released
• date:リリース日:start = 今日の日付 (YYYY-MM-DD)
• プロジェクト = ["https://app.notion.com/d044b0bb27c3486a80a22e291fe99062"]

Step 11: リリース内容のお知らせ文をまとめて提案する

今回のリリースに含まれる変更内容を確認し、ユーザーが告知に使えるお知らせ文をまとめて提案する。

変更内容は、前回のリリースタグから今回のタグまでの差分から把握する。

git log <前回のタグ>..vX.Y.Z --no-merges --pretty=format:"%h %s"

コミットメッセージが簡素な場合は、git show などで実際の差分を確認し、ユーザーに見える機能追加・機能変更を中心に把握する。

お知らせ文の形式:

• 日本語で記述する。
• 主要な機能追加や機能変更 1 つにつき 1 段落でまとめる。純粋な内部リファクタリングでも、動作の安定性向上など利用者に関係する形で書けるものは含めて良い。
• 導入の前置き段落は書かず、いきなり最初の機能の説明から始める。
• 絵文字は使わない。また、太字や見出しなどの装飾も使わない (見出しによるセクション分けもしない)。
• ただし、リンクとインラインコード (` で囲む) は Markdown の書式を使って良い。特定の記法や記号 (例: { と }) に言及するときはインラインコードを使うと良い。
• 段落と段落の間には空行を 1 つ空ける。
• 全体をコードブロックに入れて、ユーザーがそのままコピーしやすいようにする。

以下に過去のお知らせ文を 2 つ記載しておくので、文章の形式やトーンの参考にしてください。

過去のお知らせ文の例 1:

単語カードや例文カードの共有メニューから、その内容をスクリーンショット (PNG 画像) として保存できるようになりました。
辞書の内容を SNS などで紹介したいなどにご利用ください。
なお、画像の生成には数秒から十数秒ほどかかります。

API キー周りの UI も刷新しました。
これまで発行した API キーの最終使用日時を確認できるようになり、API キーが不要になった場合は削除することもできるようになりました。

辞書のインポート機能やエクスポート機能も強化しました。
これまでの OneToMany-JSON 形式に加え、「ZpDIC API 形式」と呼ばれる新しい形式でのインポートやエクスポートが可能になりました。
ZpDIC API 形式とは ZpDIC 内部の構造をそのまま保持した独自形式で、これを使うことで、OneToMany-JSON 形式では失われてしまう構造や情報を保ったままデータのやり取りができます。

過去のお知らせ文の例 2 (インラインコードの使用例を含む):

Markdown 機能で利用できるマークアップ記法の種類を増やし、辞書ごとにどの記法を利用するか選択できるようになりました。 特に、`{` と `}` で囲まれた部分を専用フォントで表示するという記法を追加しました。
後述する専用フォントの範囲設定とともにご利用ください。

専用フォントの設定において、そのフォントをどこに適用するかを辞書ごとに選択できるようになりました。
これまでは専用フォントは見出し語のみに利用されましたが、変化形や例文なども専用フォントで表示できます。
また、先述の通り、Markdown に `{`～`}` という記法が追加されています。
この記法を有効にした上で、専用フォントの適用範囲として「内容」を選択することで、内容欄の好きな箇所を専用フォントで表示させることができます。

なお、設定の「Markdown」項目は、「編集」タブから「表示」タブに移動していますので、ご注意ください。