SARUCREWの広告運用を裏側で支える社内プロダクト「AdXaru」（アドザル）

Meta広告の入稿作業を自動化するこのツールを開発したMONKEY TECHのエンジニアの箱守さんにインタビューを実施しました。

事業会社のエンジニアって、何を考えてコードを書いてるんだろう？

——そんな素朴な疑問から、話を始めました。

——AdXaruって聞き慣れない名前ですけど、そもそも何を解いたプロダクトなんですか？

広告運用チームが毎日1〜2件、手作業でやっていたMeta広告の入稿を自動化したものです。
1件あたり1〜2時間。キャンペーン設定、ターゲティング、クリエイティブ紐づけ、予算——ひとつひとつは難しくない。けど、絶対にミスできない。

運用担当者にとって入稿は「作業」でした。本来やるべき施策設計やPDCAに使う時間が、設定画面のクリックに削られていく。

導入後の変化です。

• 入稿時間が約1/3に
• 基本設定のヒューマンエラーがゼロ
• 副次効果でCR管理が整い、地域別出し分けが気軽にできるように。検証量が増えてPDCAが加速

副次効果のほうは、AdXaruを使うにはクリエイティブをGoogle Driveに置く必要があるので、自然とCR管理が整理された結果です。狙ってなかったボーナスですね。

>（毎日1〜2時間×複数人、ですか。それだけで人ひとり分の時間が消えてた計算ですね。）

——開発自体の話も聞きたいんですが、一番時間を食ったのはどこですか？

「運用者ごとに違う業務フローを、どうUIや体験に落とし込むか」です。

入稿フローは一見同じに見えて、運用者ごとに微妙に違う。Aさんはこの順番、Bさんはこの項目を先に——暗黙のやり方が人の数だけある。

最初は「全員のやり方を再現できる柔軟なUI」を検討しましたが、これは捨てました。

柔軟性をUIで持たせる設計は破綻する。代わりに、業務フローの差分をデータモデル側で吸収するアプローチを取りました。

設定値を3つに分けます。

• 固定：誰がやっても変わらない値 → 自動セット、画面に出さない
• 可変：施策ごとに必ず変える値 → ユーザーが必ず触る
• 条件付き可変：特定の条件で変わる値 → 条件判定して必要な時だけ表示

「人によって違う」と思われていた手順の大半はこの分類に落ちて、UIに残った項目は大幅に削減できました。

> （UIで頑張らずにデータモデルで吸収する。発想の起点が違うんですね。）

——ちなみに、捨てた機能もあるんですか？

あります。ごく稀にしか発生しないパターンは作らない、と決めました。

後から「やっぱり必要だった」と戻すコストもゼロではないですが、毎日入稿する人の認知負荷を下げるほうを優先しました。

——技術スタックを見るとモダンですよね。それでも詰まるところはあるんですか？

地味にキツかったのが、Meta Marketing APIとの実装でした。

詰まったポイントは大きく4つ。

ひとつ目はレート制限。大量入稿時のスロットリング設計です。
Meta側のレート制限ロジックは公開情報だけでは予測しきれず、実挙動を見ながら調整しました。

ふたつ目はデータ構造の複雑さ。
Campaign / Ad Set / Adの3階層と、各階層の属性の多さ。そのままアプリ内モデルに持つとUIにも露出するので、AdXaruとしての抽象を別途設計しました。

3つ目はMeta側のエンティティを運用者の業務語彙に翻訳すること。
APIの名前空間をそのまま見せると運用者が迷うので、翻訳レイヤーを置きました。ここはエンジニアが事業を理解していないと、精度が出ない領域です。

4つ目はドキュメントの不正確さ。
書いてある通りに実装しても動かないケースに何度も遭遇しました。

> （えっ、それ結構ストレスじゃないですか……？）

慣れます（笑）

最終的にはドキュメントは「最初の手がかり」、APIを叩いて実挙動で確認する、という運用に落ち着きました。
派手さはないんですが、ここで手を抜くと運用者の信頼を一瞬で失うので、地味な作り込みを徹底しています。

——逆に意外だったんですが、「あえて作らなかった機能もある」とか？

社内から「AdXaruの使い方を聞ける問い合わせチャットボットがほしい」という案が出たことがあります。作りませんでした。

理由はシンプルで、運用者は直接Slackでエンジニアに聞いたほうが早いから。

隣の席にいる人間より、不完全なチャットボットを間に挟むと、解決までの時間が伸びる。社内プロダクトの強みは「ユーザーが隣にいる」こと。その強みを殺してまで作る理由はない。

「あったら便利」と「あるべき」は違う、という判断です。

同じ思想で、Google Drive連携のファイル命名規則やフォルダ構造も、プロダクト側では強制せず運用ルールで回しています。

プロダクトの硬直性が将来の改善のボトルネックになるリスクを避ける判断です。

フィードバックは運用チームとの定例MTGとSlackで集めて、「入稿作業へのインパクトが大きい順」で優先順位づけ。
リリースから現在までの大きなイテレーションは10〜20回。ユーザーが隣にいる強みを最大化する運用にしています。

> （あー、わかります。社内って "あったら便利" の声が強くなりがちなので、これを止められるのは強い。）

——でも正直なところ、外部SaaS使ったほうが早くないですか？

率直に言うと、市場ツールに関しては運用チームのほうが詳しいです。

それでも自社で作る理由は、自社特有の運用パターンがあって、チーム内で統制したまま運用組織を拡大したいから。

運用チームが10人、20人、50人と増えるとき、各人が自己流で動くと統制が取れない。マニュアルで縛れば現場が機能しない。

プロダクトが標準フローを体現することで、人を増やしても運用品質を保てる——これがAdXaruの戦略的な役割です。

エンジニアからすると、自分の書いたコードが組織の拡大可能性そのものを左右する。

これは事業会社のエンジニアリングの面白さだと思っています。

> （技術の話というより、人材戦略の話でもあるんですね。）

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

技術判断を事業文脈で語れるエンジニアです。具体的には、

• ドキュメントが不正確な領域でも、自分でAPIを叩いて挙動を掴みにいける方
• UIで吸収するか、データモデルで吸収するか——設計の引き出しを持っている方
• 機能を増やすより、本質を見極めて引き算できる方

事業会社のエンジニアリングは、自分のコードが翌日に隣の席の仕事を変える距離で働けます。

広告運用者がAdXaruを使って数字を動かす、その最短距離にいる。
技術選定も、引き算の判断も、現場のフィードバックを直接受けながら回せる環境です。

「事業に効くコードを書きたい」と思ってきたエンジニアには、刺さる場所だと思います。

> （「自分のコードが翌日に隣の席の仕事を変える」——この距離感は、確かに事業会社ならでは。今日はありがとうございました。）

▍技術スタック

社内プロダクトだからと安易な構成にはせず、スケールと保守を見据えた構成にしています。

• フロントエンド：Next.js（App Router）/ React / Tailwind CSS / shadcn/ui / next-intl
• バックエンド：NestJS / Prisma / PostgreSQL（Aurora）/ Redis（ElastiCache）/ Passport / Swagger
• インフラ：AWS ECS Fargate / Lambda / SQS / S3 / KMS / DynamoDB / AWS CDK / Docker
• 言語：TypeScript
• テスト：Vitest / Playwright / Supertest
• 認証：Google OAuth + Auth.js

少数チームでAIを活用しながら開発するからこそ、TypeScript / IaC / E2Eまで含むテストで変更時の安全性を担保しています。

▍MONKEY TECHについて

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

私たちと一緒に働くメンバーを募集しています。

まずはお気軽に話を聞きに来てください。