はじめに
はじめまして。金沢大学大学院修士1年の萬年俊行です。
2026年9月3日〜9月30日の1ヶ月間CyberAgentが主催するインターンシップ「CA Tech JOB」に参加しました。
私が配属されたのは株式会社AbemaTV Buisiness Development Headquaters Product DIvision Technology Section_AdtechGroup(以下AdtechGroup)でABEMA広告システムを開発しました。
本記事では、既存インフラコスト削減に向けた移行先を設計し、新旧システムの並行稼働までをやり切った経験から得られた学びと、1ヶ月間のインターンを通じて肌で感じたCyberAgentの文化についてまとめます。
背景
AdtechGroupでは、ABEMA広告システムを開発しています。ABEMAで視聴者が広告を視聴している時、広告システムに広告視聴ログを送るようになっています。このログは広告主に広告費を請求するために必要不可欠で、売り上げに直結するため、失ってはならないものです。
課題
広告視聴ログはABEMA広告システム内のログ収集サーバーから最終的にGoogle CloudのBigQueryに保存されます。その経路のインフラコストが課題でした。
既存システムの構成(青の矢印はログの流れを示す)
この設計が適用されていた当時は、Pub/SubからBigQueryに書き込む場合のソリューションとして、Dataflowを用いることがベストプラクティスでした。
それに加え、BigQueryとのスキーマ不整合によるログ欠損を防ぐために、中間にCloud Storageを置いて日次ジョブでBigQueryに書き込む手法が取られていました。
（参考：Pub/Sub to BigQueryテンプレート）
Dataflowは、流れてくるデータの複雑な加工や集計をする上で非常に強力な製品です。しかし、今回の構成のように「Cloud Storageへ書き出すだけ(あるいは単純な転送のみ)」の目的に対して利用するにはコストが高く、システムの構成要素が増えることで運用上の複雑性をもたらしていました。
（参考：Dataflowの概要）
調査と設計
この課題を解決するため、まずはGoogle Cloudのキャッチアップを始めました。
最初は公式の解説動画などでPub/Subがどのような役割を持つサービスなのかインプットし、さらに個人プロジェクトで実際に手を動かすことで、その強みを体感しながら理解を深めていきました。
（参考：Cloud Pub/Subとは?）
その中で、「Dataflowを挟まない、よりシンプルなソリューションはないのか？」という視点で調査を進めました。その結果、Pub/SubからBigQueryへ直接データを書き込める「BigQuery Subscription」という機能に辿り着きました。これによって既存のフローよりシンプルな設計ができると思い、この機能を軸に進めることに決めました。
（参考：BigQuery サブスクリプション）
また、BigQueryへの直結に移行するにあたって、トレーナーから「トピックスキーマを活用してほしい」という提案がありました。これはPublisherとSubscriberでデータの構造に不整合がないことを保証するためです。
（参考：スキーマの概要）
トピックスキーマを使用する前提だと、「サーバーから送信されたメッセージがトピックスキーマとの不整合でデータを欠損してしまうのではないか」という懸念がありましたが、その検証はCIによって自動化されており、デプロイ前に整合性が担保される仕組みになっていました。
整合性を担保した開発フロー
一方で、Pub/SubからBigQueryへ直接書き込む構成にすると、テーブルスキーマの不整合やBigQueryの長時間障害が発生した場合にデータが欠損する可能性があります。
そのため、BigQuery側の短時間障害はPub/Subによる配信の自動リトライで対応し、テーブルスキーマの不整合や長時間障害による最大配信試行回数の超過にはDead Letter Topic経由でCloud Storageに保存する救済ルートを設計しました。
なお、「Pub/Subの障害によってPublishが失敗するリスク」も検討しましたが、旧構成でもPublishはPub/Subに依存していたので、この移行によってリスクは増えていません。
加えて、Pub/Subが持つ極めて高い可用性と信頼性を鑑みて、サーバー側でのCloud Storageへのフォールバック実装は棄却しました。
（参考：Pub/Sub：信頼性の概要）
これにより、既存構成におけるコストや運用の複雑性を削減した設計をすることができました。移行にあたっては新旧システムの並行稼働まで実装を完了させ、両テーブルの比較検証によってログの欠損がないことを確認できました。
並行稼働時の全体像
学び
この1ヶ月で大きな学びを得ることができました。
具体的には以下の4つがあります。
1. 要件を正確かつ精緻に把握する
最初からシンプルな設計に辿り着けたわけではありませんでした。最初は要件が曖昧なまま、「どんな状況にも耐えうるように」と必要以上に複雑な設計をしていました。要件とは与えられるのを待つものではなく、自ら関係者を巻き込んで磨き上げていくものだと痛感しました。
2. 早期にプロトタイプを作成し、フィードバックを得る
設計・実装のいずれにおいても、自分の仮説や構想を小さく形にし、早い段階でトレーナーやチームに共有することの重要性を学びました。早期にアウトプットを出してフィードバックを得ることで、認識のズレや大きな手戻りを防ぎ、確実かつスピーディーに開発を進めることの重要性を実感しました。
3. 運用・保守を見据えたシンプルな設計を追求する
システムは作って終わりではなく、存在するだけで将来的な保守・運用のコストになり得ます。新しい構成や技術を導入する際には確固たる理由が必要です。要件を正しく捉えた上で、それを満たす最もシンプルなシステムを設計する意識が身につきました。
4. 歴史的経緯や不確実な点は自発的に確認する
AI技術の発展によりコード解読や一般的な技術調査は非常に高速化していますが、歴史のあるプロダクトにおける過去の意思決定の背景やコンテキストは、経験豊富なエンジニアに直接尋ねることでしか得られません。疑問点や不確実な部分をうやむやにせず、素直に質問・確認する姿勢の大切さを実感しました。
1ヶ月働いたCyberAgentの環境
1ヶ月間のインターンを通して、CyberAgentの環境や文化の素晴らしい点を肌で実感しました。特に印象に残っているのは以下の3点です。
1. 徹底したフィードバックによるスキルアップ
設計レビューでは、変更の妥当性やその根拠が徹底的に問われます。「技術的にこんなことができるのでは」というアイデアが先行しがちな自分にとって、議論を地に足のついたものにするための思考法や、調査スキル、技術研鑽の重要性を深く学ぶことができました。
2. 視座の高い社員の方々とのフラットなコミュニケーション
上司や視座の高い社員の方々と気軽に話すことができる環境があり、自分一人では気づけないような価値観や視点に出会うことができました。親身になって相談に乗ってくださる心強い方々ばかりで、非常に恵まれた環境だと感じました。
3. 仕事を心から楽しみ、誇りを持っている
社員の皆さんがご自身の仕事に誇りを持ち、心から楽しんで取り組んでいる姿が非常に印象的でした。まるで大学のサークルに熱中しているような熱量と楽しさを持って仕事に向き合っている雰囲気が、組織全体に活気を与えていると感じました。
おわりに
この1ヶ月間、Google Cloudのキャッチアップから始まり、実際のインフラ移行における設計や実装まで一貫して経験できたことは、自分にとって大きな成長となりました。また、広告ログのような膨大なトラフィックを扱い、データの欠損が許されないミッションクリティカルな環境下で設計を行えたことは、大変貴重な経験です。
最後に、手厚くサポートしてくださったトレーナーやメンターをはじめ、チームの皆様に心より感謝申し上げます。本当にありがとうございました！