テンプレ量産の受託サイトに、要らないものまで付いてくる
WordPressテーマの雛形から複製した受託リポジトリに、使っていない実験的なCIが伝播し、毎時エラー通知を量産していました。原因の切り分けから、雛形側で根っこから直した手順まで、一人会社の実例で書きます。
受託サイトを雛形から量産するなら、雛形に足すものは全部「全クライアントへの一括配布」だと考えてください。
ある日、GitHubの通知欄が毎時のエラーで埋まっていました。犯人は、テーマの雛形にこっそり入れていたAIレビュー用のCI。複製するたびに、それが全クライアントのリポジトリへ付いて回っていたんです。
――便利な雛形は、そのまま「伝播経路」でもある。
この記事は、その切り分けと、雛形側で根っこから直した記録です。一人会社が実際にやらかして、実際に直した話として書きます。
🔔症状 — 毎時、静かに失敗し続ける通知
プッシュもプルリクもしていないのに、スケジュール実行のCIが毎時勝手に落ちて、失敗通知だけが積み上がっていました。
最初の違和感は、たったこれだけでした。「なんだか通知が多いな」。
開いてみると、どのクライアントのリポジトリでも同じワークフローが定期的に走り、そのたびに赤くなっています。プッシュもしていない。プルリクも出していない。なのにスケジュール実行で勝手に動いては、静かに失敗している。
サイトに実害はありません。表示は正常で、お客様も気づかない。でも――失敗通知が積み上がると、本当に見るべき通知がその下に埋もれていきます。
「オオカミ少年」状態のCIは、あるだけでこちらの注意力を少しずつ削っていくんです。
🔍原因 — 雛形のCIが複製先へ伝播していた
落ちていたのは、鍵が無いと動かないAIレビューCIでした。雛形ごとコピーされ、全リポジトリに伝播していたんです。
追いかけると、失敗していたのは.github/workflowsに置いたAIコードレビュー用のワークフローでした。もともとは雛形リポジトリで「試しに」入れたもの。scheduleトリガーで定期的にトリアージを回す設計で、動かすにはAPIキーが要ります。
でも、複製先のクライアントリポジトリに、そのシークレットは入れていません。鍵が無いまま起動する。だから毎回、そこで落ちる。
本質は、CIのバグではありませんでした。「雛形から複製する」という運用そのものです。
テーマのコードだけでなく.github/workflowsごとコピーされる。だから雛形に入れた実験的なCIが、意図せず全クライアントへ配られていたんです。
一つのリポジトリで直しても、次に複製すればまた付いてくる。この構造に気づかないうちは、モグラ叩きが延々と続きます。
🩹止血 — まずワークフローを無効化する
根治の前に、まず出血を止めました。CLIのコマンドでファイルは消さず、失敗し続ける実行だけをオフにできます。
GitHub CLIには、走っているワークフローを止めるコマンドがあります。リポジトリごとにgh workflow disableを実行して、失敗し続けているワークフローをオフにしました。
いいのは、ファイルを消さずに実行だけ止められること。原因を確定させる前の応急処置として、これなら安全です。手順は GitHubの公式ドキュメントにまとまっています。
これで通知は静まりました。でも、あくまで対症療法です。次に複製したリポジトリには、また同じCIが付いてきます。
🛠️根治 — 雛形から要らないCIを外す
本当に直すべきは複製元でした。雛形から実験的なCIを削れば、以降に複製するリポジトリにはもう付いてきません。
本当の直しどころは、複製元――雛形リポジトリでした。使う予定のないAIレビュー用ワークフローを.github/workflowsから削除。雛形には「そのテーマで本当に必要なCIだけ」を残す方針にそろえました。
伝播元をきれいにすれば、これ以降に複製するリポジトリには、そもそも余計なものが付いてきません。既に複製済みのものは止血で止めてあるので、順次同じ形に寄せていけば揃います。
ここで痛感したのは、当たり前すぎる事実でした。雛形は「足したもの」が、全部下流に配られる。
便利そうだから、と雛形に実験を置く。それは、全クライアントへの一括デプロイと同じ意味を持ちます。
だから雛形に入れてよいのは、この3つを満たすものだけにしました。どのサイトでも確実に動く。シークレット無しでも失敗しない。そこにあって当然だと説明できる。
💡教訓 — テンプレは資産であり、同時に伝播経路
テンプレは効率化の資産であると同時に、ミスも一括配布する経路。足すものは全下流に配られる前提で選びます。
- 失敗し続けるCIは、放置しない。 実害ゼロでも、失敗通知は「本当に見るべき通知」を埋もれさせます。
- 止血と根治は、分けて考える。 まず
gh workflow disableで止める。原因を確定してから、複製元を直す。順番が大事です。 - 雛形に足すものは、全下流に配られる。 実験的なワークフローは雛形に置かない。置くなら、シークレット未設定でも落ちない設計にする。
- 一つ直したら、必ず伝播元も直す。 複製で増える問題は、複製元を直さないかぎり必ず再発します。
i-Willinkは一人会社です。だからこそ、通知一つ・CI一本の無駄を、早めに潰すことを大切にしています。
効率化のためのテンプレートが、別のノイズを生んでいないか。あなたの手元の雛形にも、いつの間にか「全員に配られている実験」が眠っているかもしれません。
一度、複製元をのぞいてみませんか。
開発パートナーを探していますか?
AIでプロダクトを最速で形にしませんか?
最短1週間でMVPを開発。アイデアの検証から本番リリースまで、i-Willinkがフルサポートします。まずはお気軽にご相談ください。
無料で相談する