SARUCREWの広告運用を裏側で支える社内プロダクト群のひとつ、
社内では「一括ON OFF機能」と呼ばれているツールがあります。

Big4媒体（Google / Meta / ByteDance / SmartNews）のキャンペーンを、指定した時刻に自動でON/OFFする仕組みです。

「ミスったら金額が動く」領域の自動化って、エンジニアは何を考えて作っているんだろう？
——MONKEY TECHのエンジニアの箱守さんにインタビューを実施しました。

——まずシンプルに、これは何の機能なんですか？

Big4媒体（Google / Meta / ByteDance / SmartNews）のキャンペーンを、運用者が指定した日時に自動でON/OFFする機能です。社内では「一括ON OFF機能」と呼んでいます。

広告運用ってバジェット消化のコントロールが日常的に発生するんですが、そのために「このキャンペーンをこの時間に止めて、この時間に再開する」みたいな操作がしょっちゅう必要になる。

しかも、複数アカウントを同時に動かしている。手で全部追うのは限界がありました。

> （バジェット消化の調整って、そんなにこまめに動いているんですね。）

——具体的に、手作業時代はどんな"漏れ"が起きていました？

シート上で一括管理できていなかった頃は、特定アカウントの操作だけ抜け落ちる、ということが時々ありました。

「あのキャンペーン、止めるはずだったよね？」が、深夜帯や休日にズレ込むと特に発見が遅れます。広告運用なので、止め忘れ・再開忘れがそのままコストや機会損失につながる領域です。

そして、もうひとつの限界が時間帯でした。

たとえば「深夜2時に止めて、朝5時に再開」のような指示が普通に発生する。
手動で対応すると、運用者が深夜に起きていなければいけない。
寝落ちした瞬間アウトです。他の運用者が気づかない限り、再開はほぼ間に合わない。

「眠らない」を運用ルールにすることはできない。
だから機能で解くしかなかった、というのが出発点です。

——「間違えたら事故」の機能を作るうえで、一番神経を使った設計判断は？

処理結果を、運用者が信頼できる形で見えるようにすることです。

実行後、Slackに必ず通知を出します。

• どの広告アカウントに対して
• キャンペーンを開始したのか停止したのか
• 何件変更したのか
• 対象キャンペーン名とIDまで

失敗した場合も同じです。黙って終わらせず、エラー内容をSlackに出します。

運用者が「結局、何が起きたのか」を推測しないといけない設計は、絶対に避けました。

自動化って、信頼できる"見える化"がないと、動けば動くほど運用者の不安が増えるんですよ。"たぶん動いてるはず"が一番怖い。

> （地味なんですけど、これ一番効きますよね。）

——実際、どんな仕組みで動いてるんですか？

運用者は「一括自動再開・停止」シートに、広告アカウント、媒体、ON/OFF、実行したい日時を入力します。

ポイントは、目印を付けたキャンペーンだけが対象になるルールです。

アカウント内の全キャンペーンをON/OFFするのではなく、運用者がキャンペーン名に目印を付けて明示したものだけを、スクリプトが拾います。許可リスト方式ですね。

スクリプトは定期的にシートを読みに行って、指定時刻になったら対象キャンペーンをON/OFFします。毎日同じ時間に繰り返したい場合は、自動再チェック設定とスプレッドシートの `=TODAY()` 関数を組み合わせると、翌日分のチェックが自動で準備されます。

"全部止める / 全部動かす" は危ないので、対象は運用者の手で明示してもらう

——これが一番大事な設計の制約です。

——誤操作を防ぐためのセーフティネットは？

媒体APIが明示的に成功を返した場合だけ、成功通知をSlackに送るようにしています。

• APIがエラーを返した
• 不正なレスポンスだった
• 一部だけ成功している可能性がある

このあたりは全部"成功扱いにしない"と決めています。"たぶん成功"を成功と呼ばない、というルールです。

Slack通知の中身もセーフティの一部です。

成功時は対象アカウント・操作内容・件数・キャンペーン名/IDを出す。失敗時はAPIエラーの詳細まで出す。"何が起きたか分からないまま運用者が次の判断をする"という状態を作らないようにしています。

> （成功は厳格に、失敗は饒舌に、ですね。）

——Big4の中で、一番苦労した媒体は？

派手な大問題というより、運用範囲が広がってから見えてきた小さなつまずきが多かったです。

たとえばByteDanceは、1回のAPIリクエストでON/OFFできるキャンペーン数に上限があったので、複数回に分けて更新するように修正しました。

実運用で使われる件数が増えるごとに、都度パッチしてきた、という地道な積み上げです。

APIドキュメントだけ読んでいても気づけない、実運用に乗せて初めて見える"刺さり"が出てくる領域なので、ここはどうしても作り込みになります。

——逆に、あえて作らなかった領域は？

全媒体を対象にはしていません。現在の対応は Google / Meta / ByteDance / SmartNews の4媒体です。

理由はシンプルで、運用者から依頼があった媒体から順に対応してきたから。

"全媒体カバー"を最初に目指すのではなく、必要になった媒体を必要になった順に追加していく形で広げてきました。

網羅性を先に取りにいくと、使われない機能のメンテナンスにコストが流れ続けます。それよりも、いま使われている自動化を堅く保つほうに時間を使う、という判断です。

> （網羅性より堅さ、というスタンスなんですね。）

——導入後、運用チームの仕事はどう変わりましたか？

作業と不安からの解放ができたので「夜眠れるようになった」と冗談混じりに言われます。笑

それと、定期的にシートを確認するだけで済むので、根本的にチェックミスがなくなる。心理的負荷がかなり軽くなった、という声をもらっています。

派手な売上インパクトの数値より、運用者の生活が普通に戻った、という変化のほうが大きいかもしれません。

——この機能に込めた思想を一言で。

人間がやる必要のない、面倒で繰り返しの多い作業は自動化する。運用者の限られた貴重な時間を、もっと重要な業務に使えるようにする。

シンプルな考え方なんですが、社内プロダクトの存在理由はここに尽きると思っています。

——では最後に、どんな人と一緒に働きたいですか？

• "間違えたら事故"の領域で、地に足のついた設計判断ができる方
• 派手な機能追加より、**地味な信頼性の作り込み**に価値を置ける方
• 運用者の業務文脈を理解したうえで、「作る / 作らない」を引き算で判断できる方

事業会社のエンジニアリングは、自分の書いたコードが運用者の睡眠時間を変えるくらいの距離感で働けます。技術の話と運用の話が地続きで、その境目を行き来できる人にとっては面白い場所だと思います。

> （"睡眠時間を変える"——確かに事業会社ならではの距離感ですね。今日はありがとうございました。）

▍MONKEY TECHについて

MONKEY TECHはSARUCREWの100%子会社のエンジニア組織です。社内プロダクト開発に加え、AIやプロセス改善で全社の仕組み化を進めています。

「ちょっと話聞いてみたいな」くらいで大丈夫です。30分のカジュアル面談でエンジニアと直接話せます。「話を聞きに行きたい」ボタンからお気軽にどうぞ、お待ちしています。