feat(ci): 週次 schedule と workflow_dispatch を追加し外界の変化を検知する (v1.8.169)

[hideyukiMORI]

なぜ

CI が push と pull_request にしか結合していなかったため、コードが動かない限り外界の変化を検知できなかった。

2026-05-30 から 2026-08-12 まで 74 日間 1 コミットも無く、その間にコードは 1 行も変わっていないのに pip-audit の検出数は 0 → 22 件（pyjwt / cryptography / starlette を含む＝認証と TLS の面）へ増えていた。advisory は我々のコミットではなく、それ自身の時計で公開される。

何を入れたか

追加	値
schedule	cron: '30 0 * * 1'（月曜 00:30 UTC = 09:30 JST）
workflow_dispatch	併設
concurrency.group	ci-${{ github.workflow }}-${{ github.ref }}-${{ github.event_name }}

nene-origin #412 からの翻訳（写経していません）

参照実装は npm 系の艦なので、Python 側の形に翻訳しました。後続の Python 系リポはこちらを参照実装にできます。

論点	nene-origin（npm）	nene2-python（Python）
盲点の機構	paths-ignore: internal-docs/** により、内部ドキュメントだけの変更が続いた 8 日間 CI が一度も走らなかった	paths-ignore は無い。 盲点は「コミット自体が 74 日間無かった」こと
検知器	フロントエンド依存監査（npm）	pip-audit
固定の仕組み	package-lock.json	uv.lock（コミット済み・uv sync が尊重する）
cron 時刻	0 0 * * 1（毎時 00 分）	30 0 * * 1（下記）

• 同じ根、違う機構: どちらも「CI が push に結合している」ことが根。origin は filter で穴が開き、こちらは 沈黙 で穴が開いた。paths-ignore を持たないリポでも同じ穴が開くというのが翻訳して分かったことです。
• uv.lock をコミットしている効果: uv sync が lock を尊重するので、週次実行は「いま固定している版に対する既知脆弱性」を正確に測ります。npm 側の lockfile と同じ役割ですが、Python では pip-audit が lock された環境をそのまま監査するため検知器として精度が高い。
• 毎時 00 分を避けた理由: GitHub 公式ドキュメントに「schedule イベントは高負荷時に遅延しうる。高負荷時間帯には毎時の開始が含まれる」「遅延の可能性を下げるには毎時の別の時刻にスケジュールせよ」と明記されているため、意図的に 30 分にずらしました。origin とも時刻がずれるので、フリートで同時発火する事態も避けられます。

🔴 concurrency の地雷（指摘どおり対処）

github.event_name を group に含めています。含めないと schedule / workflow_dispatch の実行が push の実行に cancel され、**「設定したのに走らない」**状態になります。設定ファイルは正しく見えるのに動かないため気づきにくい罠です。

監査専用 workflow を別に作らなかった理由

別ファイルにすると PR のマージ関門と週次チェックが別々に育って乖離します。同じ ci.yml を週次で回せば「週次で確認しているもの」＝「マージに必要なもの」が定義上一致します。週次で check（3.12 / 3.14）・integration-db・package-build の 3 ジョブがすべて回ります。

🔴 この装置自身の限界（未解決・リポジトリ単体では解決できない）

GitHub 公式ドキュメント:

In a public repository, scheduled workflows are automatically disabled when no repository activity has occurred in 60 days.

本リポジトリは PUBLIC で、空白は 74 日（2026-05-30 → 2026-08-12）＝ しきい値を 14 日超過。

この装置は、それが検知しようとしている状態そのものによって停止させられうる。

「週次が動いていること」を外側から確かめる仕組みは、この workflow の中では解決できません。docs/todo/current.md の優先タスクと日報 §4 に限界として明記し、フリート全体の装置設計へ回します。

失敗通知の実測（別途提案します）

週次で回しても失敗が誰にも届かなければ「CI が走っていなかった」が「走ったが誰も見なかった」に化けるだけなので実測しました。

測定項目	実測値
通知の配信	機能している（ci_activity 通知が実際に生成されている）
未読通知の総数	1,828 件
うち ci_activity	634 件
本リポジトリの未読 ci_activity	128 件
最古の未読	2026-05-11（3 ヶ月前）

配信は届いている。届いた先が飽和している。 経路設計は本 PR の射程外として提案に回します。

検証

チェック	結果
YAML パース	トリガー 4 種・concurrency に event_name 含有を確認
scripts/check_docs_nav.py	Sidebar coverage OK
npm run docs:build	build complete（下記の事故を修正後）
pytest	471 passed, 9 skipped / 93.35%
mypy / ruff check / ruff format --check	すべて緑
pip-audit --ignore-vuln PYSEC-2025-183	No known vulnerabilities found

途中で 1 回踏みました: 日報の表セルに書いた ${{ github.event_name }} を Vue が補間構文と誤認し、TypeError: Cannot read properties of undefined (reading 'event_name') で docs ビルドが停止。この repo は 0f2704d で同じ事故（{{{）を <code v-pre> で修正済みだったので、既存の対処パターンに揃えて直しました。

マージ後に workflow_dispatch で 1 回手動実行し、緑を確認するまでが完了です（workflow_dispatch はデフォルトブランチに存在して初めて発火できるため）。

🤖 Generated with Claude Code