Claude Media
Claude Codeでパッチノートをgitログから起こしSteamニュースに載せる
Claude Codeチュートリアル

Claude Codeでパッチノートをgitログから起こしSteamニュースに載せる

gitのコミットとIssueからプレイヤー向けの変更点だけを抜き、内部名を言い換えてSteamのSmall Update / Patch Notesに載せるまでの流れを、Claude Codeの設定例つきでまとめます。

読了目安 約15分

ゲームのパッチノートは、コミットログをそのまま貼ると読まれません。fix: NPE in InventoryManager.Rebuild はプレイヤーに何も伝えないからです。Claude Codeでgitログを読ませ、プレイヤー向けの言葉に直した下書きを作り、SteamのSmall Update / Patch Notesに載せるまでを手順にします。

Steamのパッチノートは、タイトルと本文の2項目だけで公開できる軽いイベントです。書く側の負担は、下書きを作る工程のほうに偏ります。そこをClaude Codeに任せ、人間は「出してよい内容か」を確かめる役に回る構成です。

Steamのパッチノートはどこに表示され、何を書けば足りるか

Steamのイベントと告知(Events & Announcements)には、ゲーム更新の区分が3つあります。Patch Notes、Regular Updates、Major Updatesです。パッチノートは最も軽い区分で、更新内容を最も熱心なプレイヤーに知らせる位置づけです。

表示される場所は限られています。

  • Steamクライアントのダウンロード画面から更新内容を開いたとき
  • ゲームのNews Hub(コンパクト表示)
  • ライブラリのゲーム詳細画面(コンパクト表示)
  • ストアページ(直近のパッチノートへのリンク)

ライブラリのホームにある「What's New」には出ません。大きな告知の枠を押し出さないための仕様です。つまりパッチノートは、細かい変更を気兼ねなく並べてよい場所です。

必須項目はタイトルと説明の2つだけで、箇条書きを貼って公開タブから公開できます。画像などは任意です。SteamPipeでビルドをアップロードすると、パッチノートを投稿するよう促す小さなプロンプトも出ます。

パッチノートに求められる最低限

  • 必須はタイトルと説明の2項目
  • 箇条書きを貼るだけでも公開できる
  • ライブラリのホーム画面には出ず、ダウンロード画面とゲーム詳細に出る

gitログからプレイヤーに関係する変更だけを集める

下書きの品質は、Claude Codeに渡す材料で決まります。リリース間の全コミットを渡すと、リファクタリングやCI設定が混ざってノイズになります。先に機械的に絞ってから渡します。

直前のリリースタグから現在までのコミットを、マージコミットなしで取り出します。

git describe --tags --abbrev=0
git log v1.4.1..HEAD --no-merges --extended-regexp \
  --grep='^(feat|fix|balance)(\(.*\))?:' \
  --pretty=format:'%h %s'

1行目で直近のタグを確かめ、2行目の範囲指定(v1.4.1..HEAD)に当てはめます。--grep はコミット規約が feat: fix: balance: の接頭辞で揃っている前提の絞り込みです。接頭辞を使っていないリポジトリでは、この絞り込みが効かないので、全件を渡して除外基準を指示文に書く運用になります。

Issueの番号がコミットに入っているなら、症状の説明はIssue側にあります。番号を拾っておくと、Claude Codeが本文を読みに行けます。

git log v1.4.1..HEAD --no-merges --pretty=format:'%s %b' \
  | grep -oE '#[0-9]+' | sort -u

コミットメッセージは開発者向けの文です。「再現条件」や「プレイヤーが見た症状」はIssueに書かれていることが多く、パッチノートの「修正」に必要なのは後者です。

CLAUDE.mdに用語集と書き方の規約を置く

毎回の指示文に規約を書くと、実行のたびに揺れます。リポジトリの CLAUDE.md に置けば、claude -p でも読まれます。規約が増えて長くなったときの扱いはCLAUDE.md is too long警告の解説にあります。--bare を付けない claude -p は、作業ディレクトリの CLAUDE.md を含む自動検出を対話セッションと同じように行うためです。

## パッチノート作成
- 読者はプレイヤー。クラス名・関数名・チケット番号・ブランチ名は書かない
- 用語は docs/glossary.md の「表示名」列を使う
- 見出しは「新要素」「調整」「修正」の3つ。該当がなければ見出しごと出さない
- 数値の調整は「変更前 → 変更後」を併記する
- コミットとIssueに書かれていない効果を推測で足さない
- 判断できない項目は末尾に「要確認」として並べる

最後の2行が肝です。コミットメッセージから効果を推測して書かせると、実際の挙動と食い違う一文が混ざります。「書かれていないことは書かず、迷う項目は要確認に回す」と決めておくと、人間が見る範囲が「要確認」の数行に絞られます。

claude -pで下書きを作る

ログを標準入力で渡し、-p で非対話実行します。結果をJSONで受け、jq で本文だけを取り出します。

git log v1.4.1..HEAD --no-merges --pretty=format:'%h %s' \
  | claude -p "このコミット一覧からv1.4.2のパッチノートの下書きを作る" \
      --output-format json \
  | jq -r '.result' > patchnotes-draft.txt

標準入力にログを流し、指示文を引数に置く形は、公式のCLI解説にあるパイプ入力の使い方と同じです。Issueの本文まで読ませたいときは、許可するコマンドを絞って渡します。gh が入っている環境の例です。

claude -p "コミット一覧とIssue #212 #230 からパッチノートの下書きを作る" \
  --allowedTools "Bash(git log *),Bash(gh issue view *)"

--allowedTools は権限ルールの記法で、末尾の * で前方一致になります。読み取り系のコマンドだけを許可しているので、無人で回しても書き込みは起きません。オプションの組み合わせと非対話実行の注意点はclaude -pオプションの解説にまとめています。

内部名をプレイヤー向けの言葉に直す

パッチノートで最も事故が起きやすいのは、内部名の漏れです。コード上の名前とゲーム内の表示名が違うゲームでは、対応表を用意しておくのが確実です。

docs/glossary.md を次のように作っておくと、CLAUDE.md の規約から参照できます。以下は架空のゲームの例です。

コード上の名前ゲーム内の表示名メモ
InventoryManagerゲーム内の表示名持ち物画面メモ画面名で書く
EnemyType.Goblin02ゲーム内の表示名ゴブリン斥候メモ図鑑の名称に合わせる
SaveSlotLegacyゲーム内の表示名旧形式のセーブデータメモ「レガシー」は使わない
NPE / null参照ゲーム内の表示名(書かない)メモ症状で書く

最後の行のように、名前を言い換えず症状に置き換える項目もあります。次の例は、規約を渡したときに目指す書き換えの方向です。実行結果の再現ではなく、考え方を示す例示です。

前と後

コミットメッセージとパッチノートの違い

BEFORE

コミットログ

a1b2c3d fix: NPE in InventoryManager.Rebuild (#212)
e4f5a6b balance: Goblin02 hp 40->34
c7d8e9f feat: SaveSlotLegacy migration
AFTER

パッチノート

【修正】
・持ち物画面を開いたときにゲームが停止することがある問題を修正
 
【調整】
・ゴブリン斥候の体力を40から34に変更
 
【新要素】
・旧形式のセーブデータを新形式へ引き継げるようになりました

注意したいのは、言い換えで意味を増やさないことです。「停止することがある」は、Issueに書かれた症状から取った表現です。Issueに症状がなければ、「要確認」に回します。

公開前に確かめる3点

下書きは人間が読んでから公開します。パッチノートは公開の場に出るので、見る観点を固定しておきます。

確認

公開前に見る3点

  • 内部情報の混入

    ブランチ名、社内のチケット番号、未発表の機能名、ビルド用のパスが入っていないかを見ます。

  • 数値の裏取り

    「40から34」のような数値は、差分のコードやデータで一致を確かめます。文章だけから拾った数値は誤りやすい部分です。

  • 書かれていない効果

    コミットにない「快適になった」「安定した」のような評価語は削ります。

1点目には機械的な補助が使えます。ログやIssueに認証情報が混ざっていると、下書きにも写る恐れがあります。コミット時点で止める方法はgitleaksとhookの組み合わせで扱っています。

落とし穴

「要確認」を消して公開すると、推測の一文が残る

CLAUDE.md の規約で迷う項目を「要確認」に回していても、そこを読まずに公開すれば意味がありません。公開前の作業は「要確認」の行を埋めるか削ることだと決めておくと、見落としが減ります。

Steamのイベントエディタに載せてビルドに紐づける

下書きが固まったら、Steamworksで投稿します。手順は次のとおりです。

手順

パッチノートの投稿手順

  1. 1

    投稿画面を開く

    Steamworksでアプリのランディングページを開き、下にある「Post/Manage Events & Announcements」を選びます。

  2. 2

    種別を選ぶ

    「Create new Event or Announcement」から「A Game Update」を展開し、「Small Update / Patch Notes」を選びます。

  3. 3

    下書きを貼る

    タイトルと説明を入力します。箇条書きをそのまま貼れます。HTMLで作った文書は、エディタ上部のHTML取り込みアイコンからBBCodeに変換して取り込めます。

  4. 4

    ビルドに紐づける

    説明タブの「Link to Build」で、対象のブランチを選びます。

  5. 5

    公開する

    公開タブで公開します。

ビルドへの紐づけは、ダウンロード画面から「PATCH NOTES」リンクで読めるようにするために必要です。過去のビルドに後から紐づける方法はなく、現在と今後のビルドだけが対象です。ビルドを公開する前に投稿画面を用意しておくと、この制約に引っかかりません。

投稿には、いくつか知っておくと詰まりにくい点があります。

  • 投稿したアカウントが作成者として表示される。アカウントの名前やアバターも公開部分に出る
  • 投稿できるのは、パートナーアクセスを持つ発行元グループのメンバーか、Steamコミュニティハブの管理者・役員
  • ライブラリに表示されるまで、1時間ほどの遅れが出ることがある。内容のレビューとカテゴリー判定が入るため
  • 公開後に保存した編集は、すぐプレイヤーに反映されることがある

HTML取り込みでは、<html> <head> <div> <hr> などのタグは取り込まれません。表や入れ子の多いHTMLを貼るときは、プレビューで崩れを確かめます。

多言語に出すとき

イベントのテキストと画像は、言語ごとに翻訳版を用意できます。用意のない言語のプレイヤーには英語版が表示されます。翻訳はCSVで一括取り込みでき、™のような特殊記号を含むときはCSV-UTF8形式で保存します。

英語版の下書きをClaude Codeに作らせる場合も、docs/glossary.md に英語の表示名の列を足しておくと、用語がぶれません。

Small UpdateとMajor Updateのどちらで出すか

更新の大きさで、出す区分を選びます。

観点Small Update / Patch NotesMajor Update
向く更新Small Update / Patch Notesバグ修正、細かな調整Major Update年間でも大きな更新
必須項目Small Update / Patch Notesタイトル、説明Major Updateタイトル、説明、カバー画像(800×450px)
ライブラリのWhat's NewSmall Update / Patch Notes出ないMajor Update出る(条件あり)
ストアページSmall Update / Patch Notes直近のパッチノートへのリンクMajor Update表示される2件のイベントに入る

Major Updateは画像と本文の作り込みが前提です。gitログから起こした下書きは「修正と調整の一覧」であって、更新の魅力を伝える文章ではありません。小さな更新はこの記事の流れで足ります。大きな更新は、一覧を土台にして見せ場を人間が書く分担になります。

Steamの更新ガイドは、自社タイトルの経験から、Major Updateは多くても1〜2か月に1回に収めるやり方を挙げています。その間の細かい更新を、パッチノートが受け持ちます。

自動化するときの線引き

パッチノートの下書き作成は、タグを打つタイミングで回すジョブにできます。claude -p が出力した下書きをファイルに保存するところまでを自動にし、Steamへの投稿は人間が行う線引きが扱いやすいです。投稿はプレイヤーに見える操作で、公開後の編集も、すぐ反映されることがあるからです。

リリース手順の中に置くなら、次の3段にします。

  1. タグを打つ
  2. 下書きをファイルに出力する(自動)
  3. 人間が読み、Steamworksで投稿する

どこまで自動化するかは、チームの許容度で決まります。下書きの精度が安定してから、要確認がゼロのときだけ人間の確認を軽くする、といった段階的な運用もできます。

まとめ

Steamのパッチノートはタイトルと説明だけで出せるので、負担の中心は「コミットをプレイヤーの言葉に直す」工程です。ここを CLAUDE.md の規約と用語集で固定し、迷う項目を「要確認」に集めると、人間が読む範囲を絞れます。

投稿だけは自動にせず、内部情報・数値・推測の混入を人間が見てから公開する。この線引きが、パッチノートの事故をいちばん減らします。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →