@claude — 定期メンテナンス bot の自動タスク（依存パッケージのセキュリティ更新＝既知の脆弱性のみ／機能向上の更新はしない）。エンドユーザーの問い合わせ起点ではありません。
🤖 bot 向けの詳細手順 — 人間は読まなくて OK（クリックで展開）
進め方（共通ルール）
- この Issue には Slack スレッド（slackmeta）はありません。CLAUDE.md のスレッド返信ヘルパー
post_slack は使わないでください（返信先スレッドが無いため）。
- リポジトリの
CLAUDE.md のルールに従い、新しいブランチで変更を行い、PR を作成してください（merge しない／デフォルトブランチへ直接 push しない／force-push しない）。
- 変更が不要・安全に行えない場合は、当て推量の PR を作らず、所見をこの Issue にコメントしてから クローズ してください。
- 作成する PR の説明本文に
Closes #<この Issue の番号> を含めてください（merge 時に自動クローズされます）。
- コミット（PR 作成）を行った場合は、最後に下記「Slack 通知」の手順でチャンネルへ新規投稿してください。
- Issue を open のまま残す場合（PR を作って merge 待ち／所見コメントだけ残して人手判断に委ねる、のいずれか）は、仕事を終える前に
gh issue edit <この Issue の番号> --title "<新しいタイトル>" で タイトルを「具体的に何を扱ったか」が分かる形に書き換えること。クローズする場合は不要（初期タイトルのままで OK）。
- 先頭の
[auto:deps] プレフィックスは必ず残す（ワークフローの重複チェックがこの前方一致で動くため）。末尾の (YYYY-MM-DD) も残しておくと履歴を追いやすい。
- 例:
[auto:deps] 依存パッケージの定期更新チェック (2026-06-24) → [auto:deps] axios の CVE-2024-XXXX を 1.7.x で修正 (2026-06-24)
タスク: 依存パッケージのセキュリティ更新
このリポジトリの依存パッケージのうち、既知の脆弱性（セキュリティ的に問題のあるもの）だけを更新してください。
機能を上げるためのバージョンアップ（通常のパッチ／マイナー／メジャー更新）は行いません。 脆弱性への対応のみが目的です。
このリポジトリの種別:
テンプレ派生ではありません。 → 下記 A) 通常 repo（テンプレ派生でない）の場合 の手順に従ってください。
上の種別に従い、A) 通常 repo または B) テンプレ派生 repo のいずれかの手順を実施してください。
脆弱性の調べ方（共通）
そのリポジトリで実際に使っているエコシステムに合わせて、既知の脆弱性を持つ依存を特定する:
- Node:
npm audit / pnpm audit / yarn npm audit
- Python:
pip-audit（または uv pip audit）、poetry 環境なら pip-audit を仮想環境で
- Rust:
cargo audit
- Go:
govulncheck ./... / nancy
- PHP:
composer audit
- Dart/Flutter:
dart pub outdated（advisory 確認）
- 横断:
osv-scanner -r .、GitHub Dependabot/Advisory の指摘
- 対象マニフェスト＋lock の例:
package.json＋lock（package-lock.json/yarn.lock/pnpm-lock.yaml）、Cargo.toml＋Cargo.lock、requirements*.txt/pyproject.toml＋poetry.lock、go.mod＋go.sum、composer.json＋composer.lock、pubspec.yaml＋pubspec.lock など。
脆弱性が見つからなければ、その旨をコメントして Issue をクローズしてください（PR は作らない）。
重複の確認（PR を作る前に必ず・重要）
同じ更新を何度も作らないため、着手前に過去の bot 提案を確認する。
# 過去の同種メンテナンス Issue（オープン/クローズ両方）
gh issue list --state all --label "auto-deps" --limit 30 --json number,title,state,closedAt,url
# 直近の PR（オープン=レビュー待ち / クローズ=却下 or マージ済み）
gh pr list --state all --limit 50 --json number,title,state,url,headRefName
- 今回上げようとしている脆弱性修正（対象パッケージ・バージョン）が、オープンな PR（レビュー待ち）や過去にクローズされた PR / Issue（＝一度見送られた、あるいは既にマージ済みで対応済み）と実質同じなら、同じ PR を作り直さない。
- 過去にクローズされた提案は「見送られた」ものとして尊重し、新たな根拠（新規の advisory 等）が無い限り蒸し返さない。
- 確認の結果、新しく対応すべき脆弱性が無い（残っているものがすべて既出＝オープン放置 or クローズ済みの焼き直し）場合は、PR を作らず、該当する既存 Issue / PR の番号を挙げて「既出のためスキップ」とこの Issue にコメントしてから、この Issue をクローズする。
A) 通常 repo（テンプレ派生でない）の場合
基本は AI で判断せず、パッケージマネージャの自動修正に任せる。 バージョンを当て推量で選ばない。AI の出番は「自動で直せない分（＝破壊的変更を伴うメジャー更新）」だけ。
- まず決定的に直す。 そのエコシステムの「自動修正」を実行し、安全に直る脆弱性はここで解消する（マニフェストと lock の両方が更新される）:
- Node:
npm audit fix（pnpm は pnpm audit --fix / yarn は yarn npm audit の指摘を bump）。破壊的変更を伴う npm audit fix --force は自動では使わない。
- Python:
pip-audit --fix（poetry 環境は該当依存を poetry update <pkg>）。
- Rust:
cargo update -p <pkg>（cargo audit fix が使えれば利用）。
- PHP:
composer update <vendor/pkg>。Go: go get <module>@<fixed> → go mod tidy。
- Dart/Flutter:
dart pub upgrade <pkg>。
- 自動で直りきらなかった脆弱性だけを AI で対処する（ここが AI の本来の出番）:
- 直接依存・推移的依存（transitive）どちらも対象。推移的なものは overrides/resolutions や lock の更新で対処。
- 脆弱性修正がメジャー更新（破壊的変更）でしか入手できない場合のみ、影響範囲を見極めて最小限で追随し、PR 説明にその旨を明記する（リスクが高ければ見送り、所見をコメント）。
- 可能なら ビルド／テスト／lint が通ることを確認する。通らなくなる更新は含めない。
- 脆弱性対応のための更新だけをまとめて PR を作成（無関係な更新・整形は混ぜない）。
B) テンプレ派生 repo の場合
このリポジトリは別のテンプレート repo から派生しています（テンプレ repo は上の「種別」に記載）。
テンプレ管理のパッケージはここで直接 bump せず、テンプレ repo の更新を merge で取り込むことで反映します。
テンプレ repo は変更しません（PR も作りません）。 作業はすべてこの派生 repo 側で行います。
- デフォルトブランチから更新用ブランチを切る（例
chore/deps-security-sync）。
git fetch origin
git switch -c chore/deps-security-sync origin/<デフォルトブランチ>
- テンプレの更新を取り込む。 テンプレ repo は CI（
claude.yml）が読み取り専用トークンで origin-template リモートとして追加・fetch 済みです（派生 repo とテンプレは git 履歴を共有している前提）。新しい remote は足さず、そのまま merge する:
git remote -v # origin と origin-template があることを確認
git merge --no-edit origin-template/<テンプレのデフォルトブランチ> # 既定は main
origin-template が無い場合は CI で GH_CLONE_TEMPLATES_TOKEN が未設定の可能性。手動で remote やトークンを足さず、所見をこの Issue にコメントして人手に委ねる。
- lock ファイルの conflict は「削除してから入れ直し」で解決する。
マニフェスト（package.json 等）側の conflict はテンプレ側の内容を優先して解決し、その後 lock を作り直す:
rm -f package-lock.json pnpm-lock.yaml yarn.lock # 該当するものだけ
npm install # or pnpm install / yarn / cargo build / poetry lock など
- テンプレに無い「この repo 固有」の依存に既知の脆弱性が残っていれば、その分だけ A) と同じ要領で security 更新する（テンプレ管理パッケージは触らない）。
- 可能なら ビルド／テスト／lint が通ることを確認する。
- この更新ブランチから PR を作成する（テンプレ取り込みのため通常より差分が大きくなるのは想定どおり。
git merge は履歴の取り込みであり force-push ではないので問題ない）。
Slack 通知（PR を作成した場合のみ・フォーマット厳守）
実際に PR を開いた場合のみ投稿します（変更が無く所見コメントのみのときは投稿不要）。
PR は必ず gh pr create で 本物の PR を作成すること。compare / ?quick_pull=1 の「作成用リンク」は PR ではないので 使わない。
- 通知先チャンネルID:
C0B7T6B8X9R
- 下記の
TEXT を そのまま厳守。可変は末尾 〇〇（内容の一言）だけで、絵文字・タグ・2つのリンク（リポジトリ／PR）は必ず含め、書式は変えないこと。
- リンクは Slack 記法
<URL|表示テキスト> を使う（リポジトリ名と PR 番号がクリック可能になる）。
# 1) 作成した PR の URL を取得（未作成なら作成。作成済みならそれを取得）
PR_URL="$(gh pr view --json url -q .url 2>/dev/null || gh pr create --fill)"
PR_NUM="${PR_URL##*/}"
# 2) フォーマット厳守で Slack へ新規投稿（thread_ts は付けない＝チャンネル直下）
TEXT="🤖 [定期メンテナンス/deps] <https://github.com/${GITHUB_REPOSITORY}|${GITHUB_REPOSITORY}> の依存の脆弱性を修正する <${PR_URL}|PR #${PR_NUM}> を作成しました（内容: 〇〇）"
curl -s -X POST https://slack.com/api/chat.postMessage \
-H "Authorization: Bearer $SLACK_BOT_TOKEN" \
-H "Content-Type: application/json; charset=utf-8" \
--data "$(jq -n --arg c "C0B7T6B8X9R" --arg x "$TEXT" '{channel:$c, text:$x}')"
@claude — 定期メンテナンス bot の自動タスク（依存パッケージのセキュリティ更新＝既知の脆弱性のみ／機能向上の更新はしない）。エンドユーザーの問い合わせ起点ではありません。
🤖 bot 向けの詳細手順 — 人間は読まなくて OK（クリックで展開）
タスク: 依存パッケージのセキュリティ更新
このリポジトリの依存パッケージのうち、既知の脆弱性（セキュリティ的に問題のあるもの）だけを更新してください。
機能を上げるためのバージョンアップ（通常のパッチ／マイナー／メジャー更新）は行いません。 脆弱性への対応のみが目的です。
このリポジトリの種別:
テンプレ派生ではありません。 → 下記 A) 通常 repo（テンプレ派生でない）の場合 の手順に従ってください。
上の種別に従い、A) 通常 repo または B) テンプレ派生 repo のいずれかの手順を実施してください。
脆弱性の調べ方（共通）
そのリポジトリで実際に使っているエコシステムに合わせて、既知の脆弱性を持つ依存を特定する:
npm audit/pnpm audit/yarn npm auditpip-audit（またはuv pip audit）、poetry環境ならpip-auditを仮想環境でcargo auditgovulncheck ./.../nancycomposer auditdart pub outdated（advisory 確認）osv-scanner -r .、GitHub Dependabot/Advisory の指摘package.json＋lock（package-lock.json/yarn.lock/pnpm-lock.yaml）、Cargo.toml＋Cargo.lock、requirements*.txt/pyproject.toml＋poetry.lock、go.mod＋go.sum、composer.json＋composer.lock、pubspec.yaml＋pubspec.lockなど。脆弱性が見つからなければ、その旨をコメントして Issue をクローズしてください（PR は作らない）。
重複の確認（PR を作る前に必ず・重要）
同じ更新を何度も作らないため、着手前に過去の bot 提案を確認する。
A) 通常 repo（テンプレ派生でない）の場合
基本は AI で判断せず、パッケージマネージャの自動修正に任せる。 バージョンを当て推量で選ばない。AI の出番は「自動で直せない分（＝破壊的変更を伴うメジャー更新）」だけ。
npm audit fix（pnpm はpnpm audit --fix/ yarn はyarn npm auditの指摘を bump）。破壊的変更を伴うnpm audit fix --forceは自動では使わない。pip-audit --fix（poetry 環境は該当依存をpoetry update <pkg>）。cargo update -p <pkg>（cargo audit fixが使えれば利用）。composer update <vendor/pkg>。Go:go get <module>@<fixed>→go mod tidy。dart pub upgrade <pkg>。B) テンプレ派生 repo の場合
このリポジトリは別のテンプレート repo から派生しています（テンプレ repo は上の「種別」に記載）。
テンプレ管理のパッケージはここで直接 bump せず、テンプレ repo の更新を merge で取り込むことで反映します。
テンプレ repo は変更しません（PR も作りません）。 作業はすべてこの派生 repo 側で行います。
chore/deps-security-sync）。claude.yml）が読み取り専用トークンでorigin-templateリモートとして追加・fetch 済みです（派生 repo とテンプレは git 履歴を共有している前提）。新しい remote は足さず、そのまま merge する:origin-templateが無い場合は CI でGH_CLONE_TEMPLATES_TOKENが未設定の可能性。手動で remote やトークンを足さず、所見をこの Issue にコメントして人手に委ねる。マニフェスト（
package.json等）側の conflict はテンプレ側の内容を優先して解決し、その後 lock を作り直す:git mergeは履歴の取り込みであり force-push ではないので問題ない）。Slack 通知（PR を作成した場合のみ・フォーマット厳守）
実際に PR を開いた場合のみ投稿します（変更が無く所見コメントのみのときは投稿不要）。
PR は必ず
gh pr createで 本物の PR を作成すること。compare /?quick_pull=1の「作成用リンク」は PR ではないので 使わない。C0B7T6B8X9RTEXTを そのまま厳守。可変は末尾〇〇（内容の一言）だけで、絵文字・タグ・2つのリンク（リポジトリ／PR）は必ず含め、書式は変えないこと。<URL|表示テキスト>を使う（リポジトリ名と PR 番号がクリック可能になる）。