手で反映していたのを、倉庫に届けたら勝手に反映される形に乗り換えた話
📌 記事の取り扱いについて（公開当時の内容を含みます — タップで詳細）
本記事は公開当時の体験・気づきをまとめたものです。現在のツール数・プラン数・対象年齢・記事数・仕様とは異なる場合があります。最新の内容は各ツールページをご確認ください。ツールや外部サービスの仕様・料金は変更されることがあるため、利用前には各公式情報も併せてご確認ください。記載に誤りを見つけられた場合はお問い合わせフォームよりご連絡いただけると助かります。
2026年8月の追記：この記事を公開した当時、自動で反映できていたのはまだ一部のサイトだけでした。その後ほかのサイトにも広げ、いまはコンテンツ系の5サイトを本体側でまとめて組み立てる形に変わっています。以下は、その入口にあたる時期の記録です。
ツール工房.ai を作りはじめたばかりの頃、私はサイトを更新するたびに、自分の手で「えいっ」とコマンドを叩いて反映していました。
最初のうちは、それで困ることもなさそうに思えていました。でも、しばらく続けてみると、地味なうっかりが積み重なってくるのです。
反映のたびに「手元は最新かな」「必要な手順を飛ばしていないかな」と自分で確かめる必要があって、そのたびに小さく気を張るのが地味に効いてきました。
今日は、その手作業を手放して、「決まった置き場に変更を届けたら勝手に反映される」形に乗り換えた、その移行の話を書きます。
「公開用の置き場」に届けたら反映される、にした
やったことは、サイトに反映する作業を、自分の手から手放すことでした。
具体的には、「ここを公開用の置き場と決める」と宣言した倉庫を用意して、そこに変更を届けたら、あとは決められた手順書に沿って、公開できる形に組み立ててサイトへ反映してくれる仕組みを組みました。
私がやるのは「変更を倉庫（GitHub という、変更履歴も残るネット上の置き場）に届ける」だけ。あとは、サイトごとに決めた条件に合う変更なら、自動で動く仕組みが粛々と進めてくれます。
頭の中の手順が一つ減っただけなのに、思っていたより身軽になりました。手で叩いていた頃は「本当にこの順番で合ってる？」「最新のファイルを送れてる？」と、反映のたびに小さな不安があったのです。
いきなり通知メールが5通届いた事件
ところが、最初に組んだ仕組みには、ちょっとした穴がありました。
新しい記事が公開された日に、お知らせメールが5通も連続で届いたのです。スマホを見て「えっ、なにこれ」とちょっと焦りました。
原因は、お知らせメールを送る判定がゆるすぎたこと。その日に別の理由でちょっと反映が走るたびに、毎回「新しい記事が出ました！」と元気よく通知してしまっていたのです。
修正は、通知を送る条件をかなり厳しくすること。「本当に新しい記事を公開したときだけ送る」と決め直したら、ぴたりと止まりました。
通知系は「ちゃんと飛ぶか」より「余計なときに飛ばないか」のほうが大事だな、と勉強になりました。飛びすぎる通知は、結局そのうち誰も読まなくなるので。
日本語まじりのメモで詰まった日
もう一つ、思いがけない落とし穴がありました。
倉庫に変更を届けるときには、「今回はこういう変更ですよ」と一言メモを添えます。私はずっとそのメモを日本語まじりで書いていました。
ある日、なんの心当たりもないのに、反映処理が突然ぜんぶコケるようになりました。直前に変な操作をした覚えもないので、最初はかなり戸惑いました。
ログを追っていったら、自動反映の仕組みが、私の添えた日本語まじりの一言メモをうまく扱えない場面があると分かりました。仕組みの裏側が新しくなったあたりから、日本語が混ざったメモを受け付けなくなっていたようです。
そこからは、変更につけた日本語のメモはそのまま残しつつ、公開先へ渡すときだけ英数字の別のメモを使うように、手順書を直しました。
一度仕込んでおけば、新しいサイトを増やすときに同じ事故を踏まずに済みます。こういう「一度きりの仕込みで、以降ずっと効く」直し方は、けっこう好きです。
失敗してくれることのありがたさ
この仕組みのいいところは、失敗したときにメールで知らせてくれるところだと思っています。
人がやっていると、失敗に気付くのが遅れがちです。「あれ、ちゃんと反映されてる？」と確認しに行くまで分かりません。
失敗の知らせを設定してある処理なら、止まったときにメールが届きます。早めに気づけるぶん、直し始めやすくなりました（まだ知らせを設定できていない処理も残っています）。
その知らせには処理の記録への入口も付けてあって、どこで止まったのかをすぐ確認できるようにしました。朝に失敗の知らせを見ても、慌てずに原因を見に行けます。
サイトごとに前作業が違う
ツール工房.ai は、サイトによって、公開できる形に組み立てる前にやる「下ごしらえ」が違います。
子連れスポット系はデータが大きいので分けてから組み立てる、ホテル系は前もって画面の中身を作っておく、楽天系は集めてきたデータを並べ替えてから渡す、といった具合です。
この下ごしらえの違いを揃えないまま自動化すると、サイトごとに手順書がてんでバラバラになって、自分で見直すときに頭がこんがらがります。
なので、サイトごとに違う下ごしらえは手順書の冒頭にひとまとめにして、そこから先の「組み立てて反映する」本体の手順は、どのサイトでも同じ形に保つようにしました。
入り口だけ各サイトに合わせ、そこから先はなるべく共通の形に寄せた。こう整えておくと、新しいサイトを自動化に乗せるときも、下ごしらえの部分だけ書けばよくなります。
なお、複数のサイトをまたいで「どれを今日反映したか」を取り違えない運用は、それはそれで別の悩みどころで、こちらは複数ツールのサイト反映管理にまとめました。
合言葉は中身に直書きしない
反映処理の中では、外のサービスへの「合言葉」を使う場面があります。
これを画面の中身に直接書いてしまうと、倉庫を覗いた人に見られてしまいます。なので、合言葉は別の場所にこっそり預けておいて、必要なときだけ取り出して使う形にしました。
漏れた場合は古い合言葉を無効にして、新しいものを発行し直す必要があるので、ここは念入りに気を付けています。自動反映に乗せるときの、最低限の作法という感じです。
「手で送り間違える」種類の事故は減った
自動の仕組みに任せて一番うれしかったのは、「最新でないファイルを手で送ってしまう」種類のミスが減ったことです。
いまは、公開の元にする置き場を決めておいて、反映が成功したあとに公開画面も確かめる、という形にしています。「どれを送ったんだっけ」で迷うことは、ずいぶん減りました。
ただ正直に書いておくと、巻き戻し自体がなくなったわけではありません。古い作業コピーや、ファイル同期が原因の巻き戻しにはその後も何度かぶつかっていて、そちらには別の対策を重ねています。
途中で通知の暴発も日本語メモの事故も踏みましたが、振り返ると、踏んだぶんだけ手順書が丈夫になった気がします。
個人で趣味のように作っているサイトでも、反映の手順だけは早めに自動の側へ寄せておくと、後から積もっていく事故が大きく減るな、というのが今回の学びでした。
← 他の制作記を見る ｜ トップ ｜ お問い合わせ