i-Willink
|実務|✍️ i-Willink

テンプレ量産の受託サイトに、要らないものまで付いてくる

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がフルサポートします。まずはお気軽にご相談ください。

無料で相談する

最新記事をメールで受け取る