40以上のGitHub Actionsワークフローを持つ自動化基盤で、「日次で機会を探索し提案キューに積む」 という中核パイプラインが、ログだけ見ると成功しているように見えながら、実際には数日間まったく 動いていませんでした。この記事はその調査・修正の記録と、同じ状態に陥っていないか自分で確認する 方法のメモです。
起きていたこと
スケジュール実行の生ログを直接確認したところ、session_config_rejected という基盤側のエラーが 同一条件で複数日にわたり再現していました。単発の障害ではなく、設定・設計に起因する再現性のある 問題でした。
ついでに全ワークフローを棚卸しした
原因調査のついでに40本のワークフローを一通り確認したところ、以下が見つかりました。
「ワンクリック統合」ワークフローが、既存の個別ワークフロー数本の処理を内部で再実装していて、 同じ修正を2箇所に入れる必要がある状態になっていた
ほぼ同一の処理を持つワークフローが2本存在していた(統合できる)
現行のどのワークフローからも参照されていない、遺物化したスクリプト群が手つかずで残っていた
キュー番号のハードコードが原因で、実際に処理すべきキューとコード上で参照しているキューが ずれる状態ドリフトの痕跡もあった
直したこと
壊れていた日次実行を、実行結果が確実に残る方式(Draft PRベース)に置き換え
キューの参照をハードコードからタイトル検索に変更し、ドリフトの再発を防止
重複・遺物スクリプトは影響範囲が大きいため、この監査では「削除はせず一覧化するだけ」に留めた (削除はオーナー確認後)
同じことをセルフチェックしたい人へ
同じようにAIエージェント/自動化ワークフローを多数運用しているチーム向けに、こうした棚卸しを 自動でやるツールを作りました。公開リポジトリを1つ指定するだけで、重複ワークフロー・死んだ スクリプト参照・スケジュール実行の失敗傾向をチェックします。
→ Workflow Automation Audit ($29、公開リポジトリ限定)
プライベートリポジトリや、もっと広い範囲の監査が必要な場合は contact@vakoya.com までご連絡ください。