自動デプロイをやめて、4サイト全部"手動"に戻した — 中小企業 × AI 経営（2026年7月）

はじめに：この記事の前提

Koinobori 代表取締役の杉﨑です。 社員数名の会社を経営しながら、このコーポレートサイトも自分の手で作り、AI を相棒に毎日更新しています。

少し前、このコラムで「自動デプロイが止まった日、最後は自分の PC から公開した」という話を書きました。あの時は、公開しようとしたコラムがどうしても本番に届かず、最終的に自分の PC から手で公開して乗り切った、という一回限りの応急処置の記録でした。

今回はその完結編です。あの応急処置から間もなく、別のサイトで、同じ種類の失敗が1日に2回起きました。今度は「その場をしのぐ」のではなく、自社で運用する4サイト全部の公開経路そのものを作り直すという判断をしました。技術の話であると同時に、「一度対処した問題が形を変えて戻ってきた時、どう向き合うか」という経営判断の話として書きます。

1. 課題：もう一つのサイトで、同じ失敗が起きた

1-1. 「1日に2回」、同じ場所で止まった

自社で運営するもう一つのサイトで、自動公開が同じ日に2回失敗しました。ログを見ると、原稿の組み立て（ビルド）と事前の動作確認（スモークテスト）はどちらも成功しています。失敗していたのは、最後の「本番へ送り届ける」一手前だけでした。海外で動く自動化の仕組みから、契約しているサーバーへの接続が断続的に切れる。4回リトライさせても、4回とも通らない。

原稿には問題がない。サーバー自体にも問題がない。だとすれば疑うべきは、その間をつなぐ経路です。6月のコラムで書いた事故と、まったく同じ構図でした。

1-2. これは「たまたま」ではなかった

1つのサイトで一度起きただけなら、「運が悪かった」で済ませたかもしれません。契約しているサーバー側の受け入れ設定を疑って調べても、原因は見当たりませんでした。そして思い出したのは、6月に経験したもう一つのサイトの障害も、まったく同じ「海外の自動化の仕組み → 契約サーバー」という経路で起きていたことです。

2つの独立したサイトで、同じ経路が、同じように壊れる。 ここに気づいた時点で、「またリトライを増やそう」という発想を捨てました。個別のサイトの障害ではなく、エコシステム全体が抱える構造的な弱点だと考え直したのです。

2. 取り組み：直す前に、経路そのものを変える

2-1. リトライ強化ではなく、経路を変える

4回のリトライが全滅した時点で判断しました。「もっと粘り強く」ではなく「別の道を使う」。

6月の一件で分かっていたのは、海外の自動化からは詰まりやすいが、国内の手元のコンピューターからなら安定して繋がるという事実です。ならば普段の公開作業そのものを、最初からこの安定した経路に載せ替えればいい。1サイトの応急処置だった手法を、4サイト全部の標準手順に格上げする決断をしました。

2-2. 4サイトを1つの手順に統一する

自社で運営している4つのサイトの公開手順を、1つの共通の実行手順にまとめました。狙いは「サイトによってやり方が違う」状態をなくすことです。バラバラだと、障害が起きるたびに「このサイトはどう直せばいいんだっけ」を毎回考え直すことになります。

海外の自動化の仕組みは完全になくしたわけではありません。役割を変えました。 原稿の組み立てと動作確認までは今まで通り自動で行い、その先の「本番に反映する」作業だけを、手元のコンピューターからの手作業に切り替えました。品質のチェックは自動、届ける作業は手動という分業です。

2-3. 安全弁は5つ。手動に戻す＝雑に戻すではない

ここで一番気を配ったのは、「自動をやめる＝丁寧さも手放す」にしないことでした。手作業には、確認を飛ばして事故を起こすリスクが伴います。そこで、公開作業そのものに次の5つの歯止めを組み込みました。

歯止め	内容
① 作業中はスキップ	手元で編集中のファイルが残っている時は、公開を実行しない（作業途中を巻き込まない）
② 変更なしはスキップ	前回公開時から中身が変わっていなければ、何もしない（無駄な通信をしない）
③ 組み立て失敗なら配らない	原稿の組み立てに失敗した状態のものは、絶対に本番へ送らない
④ 中身が空なら中止	送ろうとしている中身が空っぽの場合は、そこで止める（本番を丸ごと消す事故の防止）
⑤ 削除が多すぎたら中止	消える予定のファイルが一定数を超えたら、実行せず一覧を見せて止める

とくに④と⑤は、6月のコラムでも触れた「元に無いものは向こうからも消す」という同期の仕組みに対する保険です。手作業にすればするほど、こうした歯止めは省略したくなります。急いでいる時ほど外してはいけないというのが6月の教訓でしたので、それをそのまま作り込みました。

3. 山場：仕組みを外す直前に見つけた「隠れた仕事」

3-1. 「ただの定期実行」だと思っていた

海外の自動化の仕組みを役割変更するにあたり、4サイトのうち1サイトには、「毎朝決まった時刻に自動で動く」設定が組み込まれていました。てっきり「定期的に念のため公開し直しているだけ」の、外しても問題のない設定だと思っていました。

3-2. 引き継ぎメモが教えてくれたこと

作業を任せていた AI エージェントの引き継ぎメモに、一文が添えられていました。

「機能面で見落とされやすい点なので、特にご確認ください」

読んで、はっとしました。そのサイトには、日付が変わった瞬間に公開対象になる記事（あらかじめ日付を指定して仕込んでおく、いわば予約投稿）があります。その「予約分を本番に反映する」役目を、まさにこの毎朝の定期実行が黙って担っていたのです。

もしそのまま外していたら、何が起きたか。予約していた記事は、指定した日になっても永遠に公開されません。エラーは出ません。誰かが「あれ、あの記事まだ出てないな」と気づくまで、誰にも分からない障害になっていたはずです。原因の見えない不具合の中でも、一番たちの悪い部類です。

3-3. 外さずに、条件を1つ足す

安全弁②（変更なしはスキップ）とも正面から衝突していました。原稿に変更がなくても、日付が変わっただけで公開すべき対象が増えるサイトがある。「変更なしなら何もしない」を機械的に適用すると、この予約公開がまた同じように埋もれてしまいます。

そこで、「日付に依存するサイト」という区分を1つ足しました。 該当するサイトだけは、原稿に変更がなくても毎回きちんと組み立て直して送る。特別扱いは1サイトだけに絞り、他の3サイトは通常どおり「変更なしはスキップ」のままにしました。

4. 結果：4サイトが同じルール、同じ考え方で動くようになった

海外の自動化は品質チェック専任に、本番への反映は手元のコンピューターからの一手順に一本化されました。5つの歯止めは全サイト共通、例外は「日付に依存するサイト」の1点だけ、という形に整理できました。この考え方は、社内の開発ルールにも明文化して残しています。

そして数日のうちに、この一連の仕組みを毎朝自動で起動する設定も整いました。海外の自動化は品質保証に専念し、本番へ届けるのは安定した経路から、しかも毎朝決まって動く——応急処置だった手法が、標準の運用に育った形です。

5. 学び

トラブルは「どの段階で止まったか」を見る。 原稿の組み立てと事前確認が通っていて、最後の一手前だけが落ちるなら、疑うべきはコードではなく経路や権限です。今回、リトライを4回とも失敗させた時点で「強化」ではなく「経路変更」に踏み切ったのは、正しい切り替えでした。

仕組みを外す時は、その仕組みが黙って担っていた仕事を探す。 「ただの定期実行」に見えたものが、実は予約公開という別の役目を持っていました。名目と実体がズレている仕組みは、思っている以上によくあります。

AI エージェントの引き継ぎメモは、必ず読む。 今回の落とし穴は、実装を任せていた AI が「ここは特にご確認を」と書き残してくれたことで気づけました。任せきりにせず、報告には目を通す。当たり前のことですが、忙しい時ほど流し読みしがちです。

手動に戻すことは、雑に戻すことではない。 5つの歯止めを作り込んだことで、手作業のほうがむしろ「何を確認してから動かすか」が明文化された状態になりました。

おわりに

6月に書いたコラムでは、「自動化の隣に、自分で出せる手段を残しておく」という話をしました。今回はその先で、「自動」を主役の座から降ろし、「手動だが規律のある手順」を主役に据え直した、という報告です。

派手な技術ではありません。やったことは、経路を1つに揃え、歯止めを5つ作り、外す前に「本当に外していいものか」を確認しただけです。それでも、2つのサイトで同じ失敗を経験しなければ、この判断には踏み切れなかったと思います。

もし社内に「毎日動いているけれど、何のために動いているか誰も正確には説明できない仕組み」があれば、一度、それを止める前に立ち止まって確認してみることをお勧めします。名目と実体がズレている仕組みほど、外した後に静かに困ることになります。