Google ドライブの動画再生数を AWS で計測！サーバーレス動画再生カウンターの構築

こんにちは、AWS グループの尾谷です。

今日は、社内情報共有動画サイト「ナレ活 STUDIO」の動画再生カウンターをリニューアルした話をご紹介します。

本ブログで紹介する Amazon CloudFront KVS (KeyValueStore) は、Amazon DynamoDB よりもライトに利用できて、更新も楽だったので、今後も活用していきたいと感じました。

このブログで紹介すること

Google ドライブの動画は再生回数をカウントできない
Google Analytics も埋め込み Player のクリック数をカウントできない
CloudFront Functions と KVS でリダイレクトの仕組みだけを作った

「ナレ活 STUDIO」をローンチ

以下のような経緯があり、2025 年の 5 月に社内 YouTube ショート風の共有動画サイト「ナレ活 STUDIO」を立ち上げました。

上司
「なんとかして、社員が AI を活用しないと時代に取り残されてしまう。」
上司
「よし、毎週水曜日に交代で AWS チームのみんなに AI 活用方法を発表してもらおう！」
僕
「せっかくなら、発表内容を収録して社内に配信しても良いですか？」
僕
「ナレ活 STUDIO スタートします！」

僕は、動画編集を 25 年ほどやってきたノウハウがあったのと、最近流行りの YouTube ショート動画的なのを作ってみたくて提案しました。
提案は難なく受け入れられて「ナレ活 STUDIO」は 2025 年 5 月にローンチ。AWS チームのメンバーが発表した AI 活用事例を 1 分以内のショート動画に編集して、5 ヵ月の間に 47 本 もの動画が揃いました。

その後、応援してくれる上司や、賛同してくれるエンジニアもいたので、活動は継続・拡大していき、2025 年 10 月に社内で「編集部」を立ち上げることになりました。

動画再生数をカウントしたい

「編集部」立ち上げにあたり、以下目標を掲げました。

KGI: 動画再生数
KPI: 動画編集数と広報活動

KGI は、今振り返ると非常に安直なのですが、1 名体制からメンバーが 2 人増えて 3 人増えたという理由で、「再生回数: 3 倍」としました。

動画再生数が取得できない

ところが、Google Analytic では、どうしても動画再生回数が取得できませんでした。
毎週のように設定変更して、試行錯誤しましたが、Google ドライブのファイルを Analytics の対象にできないようでした。
Google Workspace の管理者に相談したところ、アクセスログを提供してもらえたのですが、集計の度に管理者に出力をしてもらう必要があり、届いたデータの量も膨大だったのと誰がいつどのファイルにアクセスしたか？詳細に見えるため、データの取り扱いが難しいと感じました。

いろいろ調査をしていると、動画ファイルのインフォメーションにアナリティクスという項目があり、ファイルが開かれた回数が表示されると気づきました。

この値を GAS で取得できないか調査しましたが、これも API が公開されておらず Gemini からもアクセスができないようでした。
動画本数も当初は 50 本程度と少なかったので、半月に一度、この値を手動で書き出して集計することにしました。

手動運用の限界

2025 年 10 月から手動による再生回数を集計していきました。

動画を選択して、1 秒ほど待ち、表示された回数を Notion データベースに手打ちします。
不安定なのか、ファイルにアクセスすると、10 回に一度は読み込みが長く時間がかかり、値が取得できません。

動画本数が増えるにつれて、集計のつらみが積み上がっていきました。
（先ほどカウントしたら、動画はなんと 156 本まで増えていました。）

経緯のまとめ

ここまでの経緯をまとめます

社内向けに Google Site を活用した限定動画ポータル「ナレ活 STUDIO」を運用
Google Analytic は、Google ドライブに保存された動画の再生数を追跡できない
ファイルのアナリティクスに（ファイルが）開かれた回数が存在するが、API が公開されていない（と思われる）

AWS で計測する

動画がどれくらい見られているかを把握できないと、コンテンツ改善のモチベーションや評価が難しくなります。
定期的なアンケートを取得するのも考えましたが、視聴者の負担になるし、定量的データとして扱いたいづらいです。

そこで、AWS のサーバーレスサービスを活用して、手軽に動画の再生数をカウント・可視化するシステムを構築しました。

解決策のアプローチ

アプローチはシンプルで、「動画の直リンクの代わりに、AWS を経由する短縮 URL を発行し、リダイレクトのログを利用して再生数をカウントする」という方法です。
全体のインフラ構築（IaC）には AWS CDK (Python) を使用しています。

システムのアーキテクチャ - リダイレクト層

システムは大きく「リダイレクト層」と「カウント集計層」の 2 層構成になっています。
まずはリダイレクト層から。

利用者が Google Workspace の認証認可を経て、Google サイトにアクセスする。
サイトに埋め込まれた CloudFront 向けの URL リンクをクリックすると、CloudFront Functions が CloudFront Key Value Store を検索し、動画の URL をブラウザにレスポンスする
リダイレクトした動画の URL にアクセスする
動画が再生される

使用技術など

Amazon CloudFront + CloudFront Functions + CloudFront KeyValueStore (KVS) を利用しています。
CloudFront Functions は Python 3.14 でコーディングしました。
関数はリクエスト URI からショートコードを抽出し、KVS を参照して対応する Google ドライブのファイル ID を解決します。そして、ユーザーに対して 302 リダイレクトレスポンスを返します。

DynamoDB ではなく、CloudFront KVS を利用

Amazon CloudFront KeyValueStore は、2023 年にリリースされた CDN 向けのキーバリューストアです。
CloudFront Functions が参照できる軽量なデータベースで、最大 5MB のデータを保存でき、キーの最大サイズは 512 バイト、値の最大サイズは 1KB です。
リダイレクトさせるだけなら、最適なソリューションだと思います。

コツとして、確実にログを残す必要があったのでキャッシュを無効化しました。

システムのアーキテクチャ - カウント集計層

カウント集計層では、CloudWatch ダッシュボードを使いました。

CloudFront のアクセスログが S3 に格納される
S3 イベントで、Lambda が発火し、HTTP ステータスコードが 302 のレコードからショートコードごとのアクセス数を集計
集計したデータを、CloudWatch カスタムメトリクスに PUT
CloudWatch のダッシュボード上で動画別の再生数として可視化

Bot による徘徊や攻撃を見分けるため、純粋にリダイレクトしたものだけを抽出しました。

運用規模とパフォーマンス

今回のシステムは、社員約 200 名、動画数 150〜2000 本の社内ポータルを想定して設計しました。
リアルタイムな集計は求めておらず、週に 1 回程度ダッシュボードを確認する運用を想定しているため、CloudFront 標準ログの配信遅延（数分〜最大24時間）も許容できます。また、 Lambda のメモリは 128MB で十分であり、サーバーレス構成のため維持費や負荷も最小限に抑えることが可能です。