編集現場を変える 映像管理システム「TAMS」を AWSで構築してみた

TAMSとは

みなさん、TAMSという言葉を聞いたことはありますか？

TAMS（Time-Addressable Media Store）とは、日本語にすると「時間で指定できるメディアの保存場所」となります。放送やメディア業界における映像の編集・活用を大きく変えられる可能性を持ったソリューションで、気になって実際に試してみたので、この記事でご紹介します。

野球中継のような試合映像を例に考えてみましょう。

従来、野球中継を収録して活用する場合、映像・音声・メタデータがすべてまとまった1本の映像ファイルとして保存されています。ディレクターがその素材を番組で使いたい、あるいはSNSで展開したいとなったとき、まず収録が終わるまで本格的な作業に入ることができません。
社内に追っかけ編集（リアルタイム編集）システムを備えている場合もありますが、基本的には素材をダウンロードするか、大きなサイズの映像を扱うために高スペックなPCと専用の編集ソフトを用意する必要がありました。

TAMSでは、映像・音声など全ての情報が特定のタイムスタンプを持った短いセグメント（チャンク）としてクラウド上に保存されます。収録しながらリアルタイムにチャンクが生成されるため、収録の終了を待たずに編集を始めることができます。

また、TAMSでは高画質の素材とブラウザで扱いやすい軽量版（プロキシ）を同時に自動生成します。編集中はプロキシを使い、最終的な書き出しは高画質で、という使い分けが最初から設計されているので、高スペックなPCや高額な編集ソフトも必要ありません。

さらに、素材そのものをコピーせず必要な部分だけを参照して編集する「Edit by Reference」の仕組みがあるため、ディレクター・編集マン・SNS担当など何人が同じ素材を使っても、元のファイルは1つのまま。コピーが増えてバージョン管理が煩雑になる、といった悩みも解消されます。

編集現場の痒いところに手が届く、そんなシステムがTAMSなんです。

このTAMSのAPI仕様は、イギリスの公共放送局BBCが放送現場の課題をもとに設計したものです。現場のユーザーファーストの理念で作られており、2023年にオープンソースとして公開されました。その後AWSをはじめ各社がこの仕様に対応したソリューションやサンプル実装を提供しており、オープンソースコミュニティで発展を続けています。

TAMSのメリット

改めてTAMSの公式サイトに掲載されているメリットを整理すると、以下のとおりです。

• 統合
  • TAMSひとつで、多様な目的や部門に対応できます。放送・ポスプロ・SNS・VODチームがそれぞれ別々にシステムを持つのではなく、単一のTAMSストアからコンテンツを取得できます。
• 費用対効果
  • クラウドベースの技術と標準的なオブジェクトストレージを活用することで、高性能なファイルシステムや重複したストレージが不要になります。さらにサーバレス技術を組み合わせることで、従来のアプローチと比べてコストを大幅に削減できます。
• 相互運用性
  • 多くのベンダーがTAMS APIに対応することで、製品間の相互運用性が確保されます。特定のベンダーに縛られることなく、使いたいツールを自由に選べるようになります。
• オープンフレームワーク
  • TAMS APIはオープンソースの仕様です。特定ベンダーの独自技術やライセンス料なしに、誰でもシステムを構築できます。
• ライブとファイルの統合
  • TAMSはNMOS（Networked Media Open Specifications）と同じコアアーキテクチャに基づいています。これにより、リアルタイムの生放送信号と収録済みのファイルの間で、タイミングや情報を維持したままシームレスに扱えるため、ワークフローがシンプルになります。
• 柔軟性
  • クラウドベースの設計により、ビジネスの需要に応じて簡単にスケールアップ・スケールダウンができます。ライブ配信のようにワークロードが一定でない環境では特にメリットが大きいです。
• 作業の高速化
  • セグメントが書き込まれた瞬間からアクセスできること、そして「Edit by Reference（参照編集）」によってコピーを作らずに編集できることで、従来のファイルベースのワークフローより大幅に作業を高速化できます。

実際に使ってみる

百聞は一見にしかず、ということで実際に構築してみます。

環境構築には2つのリポジトリが必要です。

• time-addressable-media-store : TAMSサーバ本体
• time-addressable-media-store-tools : Web UIや各種ツール

本体をデプロイしてからToolsを入れる流れになります。

① TAMSサーバ本体のデプロイ

SAM CLIとDockerをインストールしてから以下のコマンドを実行します。

sam build --use-container
sam deploy --guided

デプロイ時にいくつかパラメータを設定します。StackNameの命名と、WAFのデプロイ（デモなのでNo）以外はデフォルトで進めました。

aws-sam-cliのアップデートなど適宜、エラー文章を見て解決していただき(生成AIなどに尋ねればすぐ解決できるレベルです)、無事デプロイが完了するとAPI GatewayのエンドポイントURLが表示されます。

② Tools（Web UI）のデプロイ

リポジトリをクローンしてbackendディレクトリに移動し、デプロイします。

cd backend
sam build --use-container
sam deploy --guided --capabilities CAPABILITY_IAM CAPABILITY_AUTO_EXPAND

StackNameはtams-demo-toolsとしました。ApiStackNameには、先ほどデプロイした本体のスタック名tams-demo-apiを入力します。

オプションコンポーネントはデモなので一旦すべてYesにしています。

• DeployIngestHls: Yes
• DeployIngestFfmpeg: Yes
• DeployReplication: Yes
• DeployLoopRecorder: Yes

ただしDeployHlsApiについては、2025年11月以降、S3 Object Lambdaは新規アカウントでは利用できなくなったため、Noにしないとエラーになります。ご注意ください。

③ フロントエンドのセットアップ

CloudFormationのOutputsから環境変数を取得して.env.localファイルを自動生成するスクリプトを実行してから、Viteの開発サーバを起動します。

cd ../frontend
npm ci
npm run envLocal
npm run dev

これでブラウザにWeb UIが表示されました。

mp4をTAMSに取り込んでみる

TAMSへの取り込み方法には以下の2種類があります。

• MediaLive → HLS変換 → TAMS：ライブ映像のリアルタイム取り込み
• MediaConvert → HLS変換 → TAMS：mp4などのファイルをHLS変換してから取り込み

ライブ映像の取り込みに関しては、他のサービスもいくつか必要となりそうだったので今回は手元にあったmp4動画を使って、後者の方法で進めます。

まずS3にmp4をアップロードし、マネージメントコンソールからAWS Elemental MediaConvertでApple HLSに変換します。変換が終わると、MediaConvertのジョブを監視していたToolsのHLS Jobs ステータスがCOMPLETEになります。「 + 」ボタンを選択してTAMSに取り込みます。

チェックボックスはm3u8ファイルの最終更新日時をTAMSの時間軸の起点にするかどうかの設定です（チェックしなければ1970年1月1日起点）。デモではどちらでも構いません。Labelも任意のもので大丈夫です。

取り込みが終わると、Flowsに表示されました。

Videoの詳細ページでSegmentsを確認すると、それぞれのオブジェクト（チャンク）にタイム情報が紐づいていることがわかります。

もう少し詳しく説明すると、Manifest URIにm3u8のURLを入力することで、TAMSはそのm3u8を読み込んでHLSのセグメント（TSファイル）を1つずつFlowとして登録します。TSファイル自体は普通のTSファイルのままで、グラフデータベースであるAmazon Neptuneにフローやソースの関係性が、Amazon DynamoDBにセグメントのタイムレンジとS3 URLのマッピング等が保存されています。

具体的には1レコードあたりこのようにNeptuneに登録されています。

{
	"object_id": "e0ccd4c0-...",
	"timerange": "[1771734473:0_1771734483:0)",
	"get_urls": [
		{ "url": "s3://...", "label": "aws.ap-northeast-1:s3:tams" },
		{ "url": "https://...presigned...", "label": "s3.presigned:tams" }
	]
}

URLは2つ存在し、1つ目が通常のS3 URL、2つ目がpresigned URLで認証なしでも一時的にアクセスできます。NeptuneとDynamoDBには「どの時間範囲にどのS3オブジェクトがあるか」といったメタデータが登録されており、実際の映像データはS3に置いたまま。これがEdit by Referenceの仕組みの核心です。

MultiのFlowの詳細画面からView Playerを開くと、プレビュー画面が表示されます（VideoのView Playerからでも再生できますが、切り出しに失敗するのでMultiからの利用をおすすめします）。

このプレイヤーはOmakase Playerといい、TAMSネイティブ対応の初のWebプレイヤーです。フレーム精度の再生・編集が可能で、React用のパッケージとしても提供されています。

IN点・OUT点を設定してEXPORTを選択すると出力の設定画面が表示され、処理が始まります。

MediaConvert > TAMS Jobsで処理状況を確認でき、しばらく待つとCOMPLETEになってダウンロード可能になりました。

プロキシを使った編集

今回は4K素材を使っていたため、チャンクごとに切り分けたTSファイルのサイズが10〜20MBと大きく、編集時の読み込みに時間がかかります。そこで冒頭でも説明したプロキシ機能を試してみます。

FlowのVideoを選択し、Actions > FFmpeg > Create FFmpeg Jobを開きます。FFmpeg Commandのドロップダウンから目的の形式を選択してCreateすると、Flowにプロキシの行が追加されました。

View Playerを開くと、先ほど20MB程度あったファイルが3MB程度に。プロキシを読み込んでいることが確認できます。また、同様に書き出しを行うと4K画質で出力されたことから、編集中はプロキシ、書き出しは高画質という冒頭で説明した使い分けが、実際に機能していることを確認できました。

最後に

今回はTAMSの概要紹介と、SAMを使ったデプロイ・動作確認をおこないました。

今回使ったToolsには他にも以下の機能があります。

• HLS API : 既存のプレイヤーでTAMSのコンテンツを再生するためのエンドポイント（アカウント次第）
• MediaLive連携 : ライブ映像をTAMSに取り込む
• レプリケーション : TAMS間でコンテンツを複製する
• ループレコーダー : 古いセグメントを自動削除して一定時間分だけ保持する

次回は追っかけ編集などで使うのに効果的と書いたこともありますし、MediaLiveなどのサービスも使いながらリアルタイムの映像を編集してみたいと思います。

BBC発のソリューションとして、放送局のクラウド編集のゲームチェンジャーになり得るTAMS、引き続き深掘りしていきます。

(c) copyright 2008, Blender Foundation / www.bigbuckbunny.org