aws-summit-online-2020-session-report-cus-32

【レポート】CUS-32：「PB 級のコンテンツ管理」のチャレンジとして 2 つの事例をリレー形式でご紹介！ #AWSSummit

こんにちは、CX事業本部の夏目です。

今回はAWS Summit Onlineのオンデマンドセッション 「CUS-32：「PB 級のコンテンツ管理」のチャレンジとして 2 つの事例をリレー形式でご紹介！」 についてのセッションレポート(文字起こし)になります。

タイトル

• 本セッションでは、株式会社 TBS テレビ田邉様、株式会社テレビ東京北村様より、 PB 級のコンテンツ管理のチャレンジとして、二つの事例をリレー形式でご紹介させていただきます。

マルチユースのための映像ファイルベース「TBS Fileland」の企画から導入まで

• はい。初めまして、 TBS テレビの田邊哲平と申します。
• 本日はマルチユースのための映像ファイルベースを AWS 上で構築したお話をしたいと思います。
• よろしくお願いいたします。
• ということで私からのお話はですね、マルチユースのための映像ファイルベースの TBS Filelandの企画から導入までのお話をいたします。

アジェンダ

• 本日のアジェンダ、以下の通りになっております。

自己紹介

• はい。まず自己紹介です。

• 私田邊哲平と申します。
• TBS テレビの中で VOD 事業、 SVOD であったり TV VOD の事業に従事しております。
• 得意なことですが、コンシューマーサービスの企画開発運用、映像コンテンツのマネタイズ、映像ファイルののハンドリングで一番最後業務におけるワークフローデザインというのをここ数年強調してお話をしてございます。
• 私キャリアとして2018年の4月に TBS テレビにジョインしてるんですけれども、そこまでの10年間、2008年からは NTTドコモで映像配信サービスの運営をやってございました。
• こちらもあって映像の配信事業に関して、 TBS テレビでもやっておりますということです。

TBS Filelandとは?

• 次早速ですが、 TBS Filelandとは? という話をいたします。

• そもそも TBS の TBS Filelandは社内でマルチユースファイルベースというふうに呼ばれていて、番組二次利用ビジネスのための映像ファイルの管理システムでございます。
• これを2019年6月から構想に着手いたしまして今年の4月に利用開始をしております。
• 本日はこちらの TBS File ランドの導入までのお話ができればと思っております。

企画の背景と経緯

• まず企画の背景と経緯です。

• TBSを取り巻く環境は、ここ数年劇的に変わっております。
• これまではですね、地上波放送とラジオ放送がメインの事業会社でした。
• 開局後開局65年なんですけれども、地上波放送ラジオ放送が中心でしたが、ここ数年市場の環境が大きく変わりまして、配信の事業、海外事業、パッケージでの販売、そして新たなここにはない新たなその他様々な手段で視聴者へと視聴者様に番組を届ける、つまり1ソース一つ作った番組コンテンツをですね、複数の手段に出して視聴者に届けるということが求められている時代になっております。

• そこで TBS が2020年策定しました企業理念とブランドプロミスについてお話したいと思います。
• こちら右に書かせてもらってるんですけれども、こちらがホームページから持ってまいりました弊社の企業理念とブランドプロミスです。
• これを私なりに私のポジションから解釈をしますと「TBS は愛されるコンテンツを作ります。作ったものを様々な手段でお届けするというミッションがございます。これを結果として最高の時で、明日の世界を作る」というゴールを求めて我々は業務をしていこうという次第でございますが、この中で今課題が大きくございます。

• 先ほど申し上げました通り、大きく変わっている状況でして、これまでとこれからの繋ぎ込みのところが今求められております。
• 現状ですね、配信事業であったり、海外事業、CS、DVDそれぞれで番組を出そうと思いましたら、それぞれの事業向きの納品の先があって、そのためのマスタリング、つまり CM 感を黒みを詰めるであったり、ファイルの形式を変えるといったことがマスタリングとして行われてます。
• そのマスタリングをするためのプレビューっていうのがあって、それぞれがそれぞれの場所で行っております。
• ということは、持ってくるテープであったり XD Com、物理の媒体を、地上波番組の制作であったりライブラリーだったり、各担当者から取り寄せて行っております。
• これは背景としてそれぞれの事業のリーガルポリシーが存在しその、そのせいもあって事業セクションがわかれています。
• それによってそれぞれ業務システムが違っていたり、そもそも納品ファイルのフォーマットが違っているという状況でして、この背景があり、現状こういったそれぞれが多重化されている業務を行ってしまっているという状況です。
• この結果制作の現場に負担が増ということと、あと管理コスト、それぞれの人的リソースであったりそもそものファイル、の管理コストが増大しております。
• そして重複の作業先ほども申し上げましたが同じことを同じようなことをそれぞれのセクションで行っているという状況になっていて、デリバリーするタイミングが遅くなったり、そもそも気づけなかったりしてビジネスの機会を損失してございます。

• そこで我々はこう考えました。
• 様々な手段でお届けするということをするための手段です。
• ここ、ウェブ上に集約されたワークスペース、こちらを構築することによってここだけにものをアップロード集約さしていただければ、そこから権利プレビューであったりリマスタリングをこのワークスペースで完結させて、それぞれの完パケファイルを作ることになります。
• で作ったものをそれぞれのサーバーに納品するという一つのワークスペースを作りたいというふうに我々考えました。
• なのでポイントとしましては、ここにアップする搬入は1ヶ所に1回だけで済みます。
• そしてこれウェブ上に構築したいなと思ってますので、映像の確認はいつでも簡単にできるというポイントがございます。
• 次に納品後のファイル、こちらにそれぞれの事業向けに納品したファイルがここに集約されるわけですので、保管管理、あれどこ行ったってのは TVer 完パケであったり、あれ CS に放送したパケどこだっけなという手間が省けます。
• つまり、映像を探すだったり取り寄せるという業務からの解放を意味しております。
• さらには、それぞれの業務、事業向けにどういった編集を行ったかであったり、留意事項も集約することができます。
• 次に開発の支援、こういったシステムを作るには何分リソースは限られますがその開発資源の集中投下が可能になっており、こいつを右に進み左に進めるというふうにハンドリングをすることによって、未来の経営判断つまり大きな転換期が未来来る場合に柔軟に対応することが可能であるというふうに考えております。
• こういったワークプレースを今回作りたくて、 TBS Filelandという形で実現をいたしました。

検討の課題およびその解決

• さて、それを作るにあたっての課題でございます。

• まず直面した課題は、これはどのシステムでも会社でもあると思いますが、クラウドに作るのそれともオンプレで作るのという二元論です。

• こちらはそれぞれ可用性であったり、性能・拡張性、運用・保守性で様々な観点で議論がなされましたが、最終的に最終的にはですね、こちらです。

• 結論はクラウド、決まり手は早く運用開始がしたかったということでございます。

• これが決まれば後はもう芋づる式に決まっていきます。
• イチから開発、クラウド上にイチから開発っていうのは当面やらないでおきたいなと思って、パッケージがございますのでそちらを導入しようと考えました。
• その上で現在の市場でのプレゼンス、現在のシェアであったりプレゼンスと将来の査定のアビリティこれは様々なパッケージとして、どういった未来を描けるかを勘案して、まずベースとなるクラウドは AWS の Amazon Web Service で行いたいというふうに考えました。
• その上でIMAGICA Lab さんのTASKEEというパッケージがございましてこちらをベースにして最低限の TBS 向けのカスタマイズで、ミニマムのカスタマイズを行って運用開始をするという方針を今回決めさせてもらいました。

• そこから構想を着手して、社内オーソライズをかけたところまでが2019年の話でして実際には10月から仕様検討の着手をしております。
• そこから約半年間で試験運用が開始できましてその後4月、2010年4月から本番の利用を開始してございます。

導入、その後

• ではその導入されたもののご紹介と、その後の展望のお話です。

• こちらが実際の TBS Filelandの画面です。

• このように番組を選ぶことによって、

• その番組の中にあるエピソードが存在してます。

• 3エピソード単位でファイルが放送完パケここでは TVer完パケやParavi完パケのように三つ存在しております。

• 一つクリックをしますと、こうやってプレビューが即可能です。
• あのテープを引っ張り出してきて、それを再生機に入れてプレイを押すという手間が全く必要ございません。

• ここで確認しさらに配信完パケの次 放送完パケですが、

• こういったふうに素材が入っておりますと、即プレビューが可能です。

• やってみて便利だなあと思うのはこちらのメタ情報をすぐに参照できます。
• つまり、音声チャンネルがいくつ入ってる、トラックがいくつ入っていて、チャンネルがいくつ入ってるか、これ意外に素材だけだとわからない部分なので、それがファイルベースになることで、こういった形ですぐに見れるっていうのがメリットだというふうに我々感じております。

• 導入後の利用状況ですけれども、ファイル数ですね3ヶ月で3000弱のファイル数をすでにアップロードしてデリバリーに用いております。
• ファイルの全体の容量ですけれども現状全部で47TBが現状アップされていて、これがどんどんどんどん使うことによってあれの容量が大きくなっていくというふうに思っております。

• 今後の展望、今はもうここまででも大分これまでできていなかったワークフローができるようになったんですけれども、ここからさらにこれからも AWS を使うことによって、実現していきたい業務ファンクションがございます。
• まず一つ目クラウド上での編集を行いたいなというふうに考えておりまして、EC2を使うことによってクラウド上で NLE、Adobe のPremiereであったり、 Grass ValleyのEDIUSであったり、そういったものをクラウド上で動かして、ここで編集できちゃえば、もうそもそも全てクラウドでワンストップで行えるというふうに未来を描いております。

• その上では編集後のクオリティチェック、QCが必要になるんですけれども、これもクラウド上で実現できるかなというふうに今チャレンジをしております。
• 具体的にはパカチェックであったり、黒みの検知、ブロックノイズ等々の検出を、もうこのファイルランド内で行いたいなというふうに考えており業務の大幅削減を目指してます。
• 最後、インジェストですけれども先方が S3の受け口があるようであればそもそもFilelandでは S3にファイルが存在しているので、もう直接ダイレクトにインジェストができるんじゃないかなというふうにとらえておりまして、こちらも実装にチャレンジをこれから進めております。

• 他にもですね、主に技術面ではないんですけれども、既存のこれまですでにデリバリーされている1.2PB のファイルがございますのでこちらの保存保管を目的としてアップロードしていくことを考えております。
• さらには、 TBS 内での利用の事業の部門の拡大、より多くの人多くの部門が使うことによってどんどん集約されて価値が上がっていくと思いますのでこちらの方の拡大も狙っていきます。
• さらには地上波放送の送出も最終的にはファイリングをされてデジタルで送りうることになりますので、こことも連携をしていくことによって更にワンストップにできればというふうに思ってます。

• こういった形で TBS はより速いスピードよりダイナミックな動きでクラウドを使うことによってこれまで出来てる業務の効率化、さらにはできなかった業務の実現をしていきたいと思っております。
• ご清聴いただきありがとうございました。

民法キー局で国内最大級、5年で13PBのメディアアーカイブをAWSで実現

• 「民法キー局で国内最大級、5年で13PBのメディアアーカイブをAWSで実現」これに関しましてテレビ東京の北村より説明させていただきたいと思います。
• では内容に入ってきます。

アジェンダ

• 本日話す内容としてはこのような流れで進めさせていただければと思います。

• それでは初めに、アーカイブのメイン業務をスライド1枚で説明させていただきます。
• アーカイブは各番組の放送に必要なメディアを用意しています。
• ロケやスタジオ収録、編集など様々なことに利用されていますが、アーカイブとしては、オンエア用と白、その他といった分け方で管理しておりまして、各番組の要望に応じてメディアを貸し出しています。
• アーカイブセンター内で1点在庫を貯蔵品として管理しています。
• 番組制作は生放送除いて放送設備に完成品のメディアを局に納品していきます。
• また生放送の場合も、放送中に流れる映像を事前に収録編集することが多々ありますのでそのためにメディアが必要となります。
• 放送された番組に関しては放送終了後にアーカイブセンターが回収し保存処理を行っています。
• 収録や編集をして、使用したメディアに関しては、番組担当者がオンエア終了後に保存申請と共にアーカイブに返却する場合と、消去可として返却する2パターンありまして、保存申請されたものに関してはオンエアと同様倉庫に保存していってます。
• 消去可とされたものに関しては、エラー発生頻度を確認し、廃棄するかクリーニング処理を行った上で、再び貯蔵品としてアーカイブで管理しております。
• おおざっぱになりますが年間1万本以上の新規保存を行っております。
• つまり、メディアが不足しないように毎年1万本以上のメディアを購入し続けていることになります。

• 放送を維持するためにアーカイブセンターで購入しているメディアの推移をここ10年見ていきますとこのようになりました。
• 近年放送に運用しているものはHDCAMテープとXDCAMディスクになります。

• HDCAMテープはこのようなもの、

• XDCAMディスクはこのような形のものです。

• 保存対象となったメディアをアーカイブで倉庫保管している思いますが、現時点で全部足すとだいたい26万本から27万本になります。
• テレビ東京では2016年以降、本社移転の転換期としまして段階的にオンエア向け納品はXDCAMにシフトするため、2015年以降、 XDCAMの購入数が増えました。
• 一本数千円のメディアを毎年1万6000本前後、継続的に購入しています。
• HDCAMに関してはこの後触れますが、収録再生機の保守終了期限が近づいてきているため、新規購入をやめました。
• 手前の方2010年以降、XDCAMの購入数が一度上がって、14年に一度落ち込んでいるものに関しては、HDCAMテープの前に流通していたメディアの収録再生できる機械がメーカー保守切れとなったため、当時ですね、次期メディアとして目されていたHDCAMに一対一ダビングしたんです。
• これは俗にマイグレーションと呼んでいます。
• 放送向けメディアはアナログ放送からデジタル放送といった放送形態変更など様々な影響を受け、対応するメディアが変遷し続けているため、そのたびに費用をかけてマイグレーションを続けてきました。
• 2010年には3万本項にしてHDCAMテープに関しても収録再生機の保守切れが2023年に予定されているため、2018年以降、変換作業をスタートさせます。
• このHDCAMテープのファイル化に関しては、 IMAGICA Lab さんに業務委託しています。

• 昨年のセミナーでもお見せしたんですけども、上段にずらっと並んでるのがHDCAMになってまして、下にデッキと収録機が並んでます。
• 機械アームで一本ずつつかんでファイル化を行ってくれてます。
• これをですね、土日問わずに24時間稼動で変換作業をいただいております。

• しかし機械が24時間体制で稼働していても、マイグレーション作業は相当の時間を要します。
• また、できるだけ自動化効率化を追求いただきましたが、対応いただく費用は相当のものでした。
• ということで、アーカイブが抱えていた課題としては、毎年放送を維持するために、高額な業務用専用メディアを大量に購入していること。

• 加えて放送規格、機器の保守終了といった外的要因に対して保管していたメディアのマイグレーションが大量に発生し続けていたということがあります。
• しかも保守終了の連絡を受けて行うマイグレーションでは、データを取り出した大本のメディアは再生保証を失うためリユースもできませんでした。

• しかしですね、ファイル化が進んでいる今なら、製作所の運用は別としても、保存はメディアに縛られることなくできるだろうと考えました。

• ということで、コンテンツをファイル管理に移行したらと検討していきまして、結果AWSさんのサービスを活用することになりましたが、メリットを挙げていきたいと思います。
• まず保存中のメディアからデータを AWS クラウドに格納できれば、メディアの物的破損紛失含め、データ損失のリスクが極めて低くなります。
• AWS S3を活用すれば99.999と高い耐久性が得られます。
• 次にコストに関して、業務用メディアは民生のものと比べ高額のものを使用していますが、これまでオンエア後、使用していましたメディアのまま倉庫保管していました。
• これはダビングなどを行ってもですね、費用対効果が上がらなかったためです。
• しかしファイル化が進み、クラウド上の管理が進めば、入れ物となるメディアは簡単リユースでき、倉庫保管の費用も削減できます。
• 直近3年の平均で年間1万6,000本ほど新規にXDCAMメディアを購入していましたが、保守終了が発表されてませんXDCAMメディアであればどんどん利活用することができますので、年間のメディア購入費を大幅に削減できると考えています。
• ただしですね保管中のメディアのリユースに関しては再放送や二次利用などを貸し出しに対してファイルダウンロードの仕組みなどを新たに構築する必要があります。
• 別途来年度に向けて新しい仕組みを構築すべく作業を進めています。
• そのため、現時点ではまだ保管中のXDCAMメディアのリユースはできていません。

• 次にですね、離れた倉庫からメディアを交通機関を使って配送する対応に比べ、クラウドからのファイル取得は、悪天候や交通事故の不確定な要素が少ないのもメリットだろうと考えています。
• 弊社は1日2便のメディア配送で対応を行っているということもあるんですけども、普段からメディアの貸し出し申請などを渡しできるまでそこそこ時間がかかってました。
• 保管費を抑えるためにS3に格納したファイルは1,2日でGlacierに移動させていますので、GlacierからS3に戻す時間が多少不透明ですが、現状のメディアの配送よりも早くファイルが取得できる可能性があると考えています。
• この辺りも今テスト的に確認を進めています。
• またクラウドに対してセキュリティを心配する声もありますが、物理的にデータを持ち歩かずに取り込む届けられる点におきまして、セキュリティ上がる面もあると考えています。
• 車やタクシー電車を使って移動中、メディアやハードディスクを忘れるといったといったことに比べれば、安全と考えることもできると考えてます。

• BCP 対応としてもクラウドは有効であると今回改めて認識しました。
• クラウドサービスを提供している様々な企業の中でも、特にAWSはデータセンター3拠点わかれているため、冗長性が高いと思ってますし、これまで想定していた BCP 対応というのは正直なところ、関東県内でも大地震、大雪といった大規模災害、交通機関のトラブルといったところまででしたが、これもウイルスのような感染症対策としてもクラウドは優位性があると再認識しました。
• アーカイブでもですね、メディアの受け渡しに必ず人が介在していますが、クラウド経由であれば端末越しに作業ができるように変わりまして人的接触を抑えることができないんじゃないかと考えています。
• 弊社コロナの対応は出社比率の2割まで削減という大胆な目標のもと、ほとんどの人が在宅ワークを経験しました。
• アーカイブセンターでも可能な限り削減してきましたが配信現場ではクラウド編集のテストをしていました。
• 4月初旬にクラウド編集と素材管理の環境を持たれてます IMAGICA Lab さんがご相談させていただき、オンライン打ち合わせを実施、打ち合わせ後、2日後にはテスト環境を構築いただきました。
• その後に2, 3週間の動作検証を挟みましたが正式に弊社の AWS アカウントと連携した形でTASKEYとEDIUSクラウドの環境整備いただくまであっという間でした。
• 物理的にハードを手配する場合と比べスピード感が違うと思います。

• クラウドは BCP 対応となりうる、この話題先ほどの話で終わるつもりでしたが、今年もう一つの問題が起きましたので、余談として話をさせていただければと思います。

• ビルの空調を起因として天井から水漏れが発生しましたと。
• 今回天井の中に隠蔽されていた空調機から出る結露水が下層で詰まりまして、排水できなくなりました結露水が天井まで逆流して溢れたという比較的ひどい話で、はじめは空調の吹き出し口付近から流水して一度止まり、その後何もないと思われた天井から水が落ちてきました。
• お見せしました動画は天井から水を排水する作業中の絵になります。
• 幸い実被害は見た目の映像から想像できない低いレベルで抑えられましたので、良かったんですけども、対処が遅れましたら集荷含め大惨事になりかねませんでした。
• さすがにこのような事態はまれだと思いますが、水を直接かぶった機器を放送しましたし、対処中はラック前の脚立を立てられていたので、関連業務を止めざるを得ませんでした。
• このような事態まで BCP 対応を考えますと、もはや何をどこまでやれば想像もできませんし、クラウドデータセンターを使って、全くこういったことが起きないとは言い切れませんけども、AWSさんは1リージョンごとにデータセンターが3拠点で冗長されてますので、やはり安心感が違うと思います。

• ということですね。長い前置きになりましたが改めてアーカイブのファイル保管に関しましてAWSのシステム構成を説明していきたいと思います。
• 弊社六本木に本社がありますが、アーカイブセンターが隣町の神谷町にあります。
• 本社機能はほとんど六本木に集約されていますが、神谷町のスタジオの方にも関連会社やスタジオなどが集められてますので、対AWSの通信経路は六本木/神谷町/AWSの三角形構造とし、それぞれ1本の専用線で接続しました。
• 不停止を考えますと、拠点ごとに二本を経路を作るべきかという話が出ましたが、それぞれ1本三角形の形で繋ぐことで、ここ(六本木-AWS間)が消えても、ここ(神谷町-AWS間)が切れても、ここ(六本木-神谷町間)が消えても通信が取れる冗長のとれた構成にしていただきます。
• このような通信環境のもとの六本木と神谷町その双方からデータ転送を行っています。
• 当初ですね、アップにEC2でプロキシサーバーを立てS3の特定パケットにデータ格納、Lambdaがそのパケットを監視してファイルの拡張子が MX ファイル、映像ファイルだった場合に、特定のタグ値を付与して S3 のライフサイクルルールによってGlacierへ移動ということを行っていましたが、ファイル件数が1万数千件を超えたあたりで Lambda がタイムアウトする事態にはまってしまいました。

• 処理時間を調整しようとしたところ、 Lambdaは最大15分までしか設定できませんでしたので、現在構成を変えておりまして、Fargate変更しております。
• ポイントは15分以上処理が可能でコストを抑えるためページ処理できるという点です。
• この辺りの処理に関しましては、 AWS の担当営業の方に紹介いただきました、株式会社アンドゲート様と AWS Batchなどいろいろ試しつつ、できるだけ安価な方法を構築しました。

• またですね、AWSの標準画面では数万件のファイルを見ていくのは大変ですので、アップロードしたファイルの管理ができるように、別途AWS上でサービスが稼働していますIMAGICA LabさんのTASKEYをテスト的にかぶせています。

• タイトル/サブタイトル/メディア番号、などですね、そういった簡易的なメタ情報を付与して検索また低解像度映像のプレビューを取得したいファイルのGlacierからの復元処理、ダウンロードといった一連の流れをテストしています。

• こちらは六本木側から行ってますXDCAMのクラウド上のデータ格納の対応です。
• 概要だけお伝えしますと、1日120枚のXDCAMディスクをセットしたら翌日全て転送が終わっているという仕組みです。
• 1枚ずつ解像度映像を生成して、揃ったら転送ということをやってます。
• 1日120枚としたのは年間今2万5000枚程度取り込むの実力があれば、新規のメディア購入費を抑えるのに十分な実力であると判断したためです。
• 低解像度生成をオンプレで行った理由もあるんですけども、ちょっと割愛させていただきます。

• ファイルを一個ずつ低解像度生成しながら転送するので、プロキシサーバにあたりますEC2のモニタリングを見てみますと、このような形になりました。
• まばらに転送が発生してます。
• こちらEC2のスペックは m5.largeで構築しました。

• 一方ですね、神谷町からは先程のスライドでお見せしました、IMAGICA Labさんにて行っていますHDCAMのファイル化対応いただいた、ものの成果物にあたります LTO テープを使って、クラウドにデータ格納を行っています。
• LTO ドライブは、3つ用意していますが1つは検品用で、2台を検査用に使っています。

• ファイルが全て揃ってる状態で転送を開始するため、プロキシサーバーにあたりますEC2のモニタリングをしますと、このようになりました。
• 転送開始するとある程度の時間スパイク的に件数が伸び、その後平準化されています。

• またこのときの PC 側の LAN の稼働状況を見ますとほぼ1 Gbps 出ていることが確認できました。
• AWSの Direct Connect は10G 契約していますが、この PC が繋がっている LAN ハブがですね、ポートが1Gだったため、これで理論値通りとなります。
• こちらのプロキシサーバーもm5.largeで構築しました。
• EC2のスペックはいろいろなパターンを試してやっております。
• またタスクマネージャーを見ると、 CPU の負荷率が転送速度影響を与えていることに気がつきました。
• これはm5.largeのプロキシサーバーに対してデータ転送をしていたときに裏でCPUを使う4 K ファイルを転送 PC 上で再生してもなんですけども、 CPU が100%上にがってしまうと転送速度が800MB代に落ちました。

• 再生を止めますと、また1Gに戻りました。
• これはですね一度転送用の操作PC として安価なノートを使ったことがあるんですけども、ファイル転送以外にタスク何もさせていなかったにもかかわらず、転送速度が概ね300 Mbps では頭打ちしたという事象を確認したため気がつきました。
• LANポート自体はですね、有線の1Gのものだったんですけども、 CPU が先に100%に張り付いていたんです。
• このようにボトルネックになる要素はいろいろありましたが、AWS側の EC2などはマウス数クリック設定変更できたり、イメージを作ってすぐに別のサーバーを立てるなどいろいろ試しやすかったので、大変助かりました。

• 今回ご用意できました資料につきましては、ここでまとめさせていただきたいと思います。
• クラウドサービスの台頭や施設を見ましてテレビ東京のアーカイブ素材の管理は、倉庫からクラウドへシフトすることとをしました。
• また運用はワークフローの見直しをしている最中ですが、物理的な巨大な空間を専有しますメディア管理に目処をつけ、費用対効果と緊急事態に強いクラウドに運用を切り替えていきたいと思います。

• また、コロナ下の影響もありますが、これまで通りという考えは改め、オンラインでファイル貸し出しやクラウド編集など、今取り込めるも積極的に取り込み、ユーザーがこれまでより良くなったと感じられるようなワークフローを構築していきたいと考えています。
• クラウドサービスは自由度が高いんでしっかりしたものを作っていけるんじゃないかととても期待しています。

• あとですね、AWSさんは本当に様々なサービスを展開されています。
• 勉強会なども開催いただいていますし、クラウドの知識不足を解消するために事例の共有などをやっていただいております。
• より良いものを作っていきたいと考えてますので今後もいろいろと試していくために各サービスで安く提供いただければと思っております。