システムやアプリは、画面上では問題なく動いているように見えても、利用環境や操作手順によって思わぬ不具合が発生することがあります。 リリース後に不具合が見つかれば、利用者からの信頼低下や問い合わせの増加、改修コストの発生、キャンペーン機会の損失など、事業に大きな影響を及ぼしかねません。 こうした不具合をリリース前に見つけ、 システムの品質を支える のが、ソフトウェアテストの仕事です。 株式会社モンテカンポ は、ソフトウェアやWEBシステム、キャンペーンサイト、外部サービスとの連携、QRコードの生成・検証まで幅広く対応する 第三者検証機関 です。 そして、その品質保証を担うテスト専門チームの中心では、 障害者手帳を持つテストエンジニアが専門職として活躍しています 。 開発に集中したい企業を、第三者テストチームが支援します システム開発の現場では、次のような課題が少なくありません。 「開発業務に専念したいが、テストまで手が回らない」 「社内の若手社員が片手間でテストを担当しており、本来必要な品質を保ちきれない」 「外注先を探しているものの、品質とコストのバランスが取れる会社が見つからない」 「テストの進捗や網羅性が見えず、リリース判断に不安がある」 テストは、単に画面を操作して動作を確認するだけの仕事ではありません。 利用者の操作、システムの仕様、外部サービスとの連携、端末やブラウザなどの利用環境を踏まえ、問題が起こる可能性を洗い出す必要があります。 モンテカンポでは、 専門の第三者テストチーム が開発組織とは異なる視点から検証を行い、開発担当者が本来の業務に集中できる環境づくりを支援します。 モンテカンポが対応するテスト・検証業務 ソフトウェア・WEBシステムの機能検証、品質検証 仕様どおりに機能するかを確認するだけでなく、 利用者の操作を想定した検証 を実施します。 機能の不足や表示上の問題 、 想定外の操作による不具合 などを発見し、システムやサービスの品質向上につなげます。 キャンペーンサイト、LINE施策、外部サービス連携の検証 キャンペーンサイトやLINEを活用した施策では、公開期間や応募条件が決まっていることが多く、公開後の不具合が重大な機会損失につながります。 画面表示や応募フロー、条件分岐、外部サービスとのデータ連携などを事前に検証し、 施策を安心して開始できる状態 を目指します。 QRコードの生成・検証 印刷物に掲載するQRコードは、印刷後に誤りが判明しても簡単には修正できません。 読み取れない、異なるURLへ遷移する、パラメータが正しく付与されていないといった事故を防ぐため、モンテカンポではQRコードの生成から検証まで対応します。 チラシ、ポスター、商品パッケージなどが印刷された後では取り返しのつかない事態を、事前の検証によって防ぎます。 テスト管理ツール「PractiTest」による品質の可視化 テスト管理ツール「PractiTest」を活用し、テストの網羅性、進捗状況、不具合の検出状況などを データとして可視化 します。 「どこまでテストが完了しているのか」「どの機能に不具合が集中しているのか」「リリース判断ができる状態なのか」を関係者間で共有しやすくなります。 PractiTestは、 楽天グループなどにおいてテスト工数を半分以下に削減した実績 もあり、属人的になりやすいテスト業務の標準化と効率化を支援します。 開発に集中したい企業を、第三者テストチームが支援します システム開発の現場では、次のような課題が少なくありません。 「開発業務に専念したいが、テストまで手が回らない」 「社内の若手社員が片手間でテストを担当しており、本来必要な品質を保ちきれない」 「外注先を探しているものの、品質とコストのバランスが取れる会社が見つからない」 「テストの進捗や網羅性が見えず、リリース判断に不安がある」 テストは、単に画面を操作して動作を確認するだけの仕事ではありません。 利用者の操作、システムの仕様、外部サービスとの連携、端末やブラウザなどの利用環境を踏まえ、 問題が起こる可能性を洗い出す 必要があります。 モンテカンポでは、専門の第三者テストチームが開発組織とは異なる視点から検証を行い、 開発担当者が本来の業務に集中できる環境づくり を支援します。 守秘と品質管理 システムテストでは、開発中のサービス情報や仕様書、テスト用アカウント、顧客情報に関わるデータなど、機密性の高い情報を取り扱う場合があります。 モンテカンポでは、ご発注いただいたシステムや情報について 守秘義務を遵守 するとともに、 テストプロセスの標準化による品質管理を徹底 しています。 再委託の有無や情報を取り扱う範囲についても、案件ごとに事前にお取り決めしたうえで業務を進めます。 障害者手帳を持つテストエンジニアが活躍するテスト専門チーム モンテカンポは2012年に創業し、2016年から障害のある人を「戦力」として雇用する取り組みを開始しました。 以来10年以上にわたり、障害者手帳を持つテストエンジニアとともに、品質保証を本業として提供してきました。 モンテカンポの職場は、福祉的な配慮だけを目的とした場ではありません。障害のある社員が、ソフトウェアテストという実務に直結する専門業務を担い、経験と技術を積み重ねる職場です。 担当するエンジニアが専門職として品質に向き合い、企業や利用者にとって価値のある成果を提供する。この実態を伴った障害者雇用への取り組みは、行政や外部機関からも評価されています。 受賞・認定 2019年度 障害者雇用エクセレントカンパニー賞（東京都知事賞）受賞／東京都 　 https://www.hataraku.metro.tokyo.lg.jp/shogai/shien/award/award19.html 2021年 もにす認定／厚生労働省 東京労働局 　 https://jsite.mhlw.go.jp/tokyo-roudoukyoku/newpage_00603.html 　 https://jsite.mhlw.go.jp/tokyo-hellowork/list/shinagawa/jigyounushi/news_topics_2/monisu_00001.html 2025年度「港区ワーク・ライフ・バランス推進認定企業」／港区 産業振興課 　 https://minato-sansin.com/worklifebalance/suisinkigyou2024/ 　記事： https://minato-sansin.com/extra/montecampo/ 委託訓練事業 2019年 障害者委託訓練事業「スマートフォンやパソコンを使ったソフトウェアテスト技能習得」／東京しごと財団 講演等 2017年9月 障害者雇用推進トップセミナー「表彰事業所等における障害者雇用の最前線」／栃木県 2019年1月 多様性委員会1月例会「障害者雇用促進支援事業活用事例報告」／東京中小企業家同友会 2019年6月 立正大学 経営学部 経営特論「異業種からの転向と経営者としての葛藤」／立正大学 経営学部 2021年8月 「もにす認定制度」認定・申請企業、各県代表による事例発表／神奈川県中小企業家同友会 2021年10月 三多摩・府中・町田合同11月例会「山野雅史物語」／東京中小企業家同友会 2022年6月 ～障害者雇用を進めるための～障害者雇用支援セミナー／厚生労働省 東京労働局・ハローワーク 2025年9月 令和7年度第1回 中小企業向け障害者雇用セミナー／東京しごと財団 メディア 障害者雇用企業インタビュー／東京都障害者雇用ポータル 　 https://www.shougai-portal.metro.tokyo.lg.jp/interview/ ［障がい者雇用］株式会社モンテカンポ 代表取締役 山野雅史さん／HABILIS Agency（YouTube） 　 https://youtu.be/eZ9fpW4UOQY 「明確にする」ことがポイント①／中小企業のための障害者雇用推進室（Podcast） 　 https://kinoshita.koelab.work/63-2/ 　 https://kinoshita.koelab.work/64-2/ 外部委託が生む、もう一つの価値 モンテカンポにテストをご発注いただくことは、開発現場の負担を減らし、システムの品質を高めるだけではありません。 発注を通じて、 実態を伴う障害者雇用を支える ことにもつながります。 モンテカンポでは、障害のあるエンジニアが実務に直結する専門業務の中で品質を担っています。単に雇用人数を確保するための仕事ではなく、 顧客のシステムやサービスを守る責任ある仕事 です。 モンテカンポへの業務委託は、発注企業における障害者雇用率の算定には含まれません。 一方で、障害のある人が専門性を持って働く企業への発注は、サプライチェーンにおける社会性への取り組みとして、 CSR 、 サステナビリティ 、 人的資本 、 調達方針 などの中で示すことができる実績になります。 「数合わせ」ではなく、障害のあるエンジニアが実務で品質を担う企業への発注であることを、社内外に自信を持って説明していただけます。 品質 、 コスト 、 社会的価値 。 モンテカンポへのシステムテストの外部委託は、 この3つを同時に実現するための選択肢 です。 自社の障害者雇用・業務の切り出しにお悩みの方へ モンテカンポでは、システムテストのご依頼だけでなく、障害者雇用や業務の切り出しに関するご相談も承っています。 「障害者雇用を本業の中で進めたいが、社内で切り出せる業務が見つからない」 「雇用は進めたいが、実態のない仕事をつくることには抵抗がある」 「どのような業務であれば、障害のある社員が専門性を持って担当できるのか分からない」 「合理的配慮を、どこまで、どのように行えばよいのか判断できない」 モンテカンポには、障害者手帳を持つエンジニアにテスト業務を切り出し、専門職として育成してきた 10年以上の知見 があります。 テスト業務に限らず、 どの業務を、どのような単位で切り出せば 、障害のある人が専門性を持って担えるのか。 必要な合理的配慮 や、 業務手順の明確化 をどのように進めるのか。 システムの仕様や確認項目を整理する「テスト設計」の観点を生かし、 貴社と一緒に考えます 。 まずはぜひ、お問合せください！ [contact-form-7]

株式会社 G-gen の菊池です。Looker では LookML （Looker Modeling Language）を用いてデータモデルを定義しますが、これらのコードはすべて Git リポジトリで管理されます。当記事では、Git 連携の仕組みや品質管理設定について解説します。 Looker におけるバージョン管理の概要 LookML プロジェクトと Git リポジトリの連携 開発モードと本番環境の分離 IDE 内での Git 操作 Git リポジトリとの接続方法 概要 HTTPS を使用した接続 SSH を使用した接続 ベア Git リポジトリ デフォルトのワークフロー 概要 開発ブランチへの変更のコミット 開発ブランチを本番環境ブランチにマージする Looker 本番環境への本番環境ブランチのデプロイ 品質と安全性を高める設定 概要 LookML バリデーションの必須化 データテストの必須化 プルリクエスト（PR）の統合 高度なデプロイモード Looker におけるバージョン管理の概要 LookML プロジェクトと Git リポジトリの連携 Looker の LookML プロジェクトは、 Git リポジトリと 1 対 1 に紐づけることでバージョン管理を構成します。バージョン管理構成にすることで、複数人での共同開発や変更履歴の追跡、安全な本番環境へのデプロイができます。 リモートリポジトリが準備できていない場合や素早く開発を始めたい場合は、Looker サーバー上にローカルの Git リポジトリを作成して単独でバージョン管理を開始することも可能です。 参考 : Git 接続の設定とテスト 開発モードと本番環境の分離 Looker には Development Mode （開発モード）と Production Mode （本番環境モード）という 2 つの環境が分離して存在します。 Development Mode は開発者が LookML を安全に編集、テストできる個人のサンドボックス環境であり、各ユーザーには他のデベロッパーに影響を与えない独自の開発ブランチ（dev- で始まりデベロッパー名を含むブランチ）が割り当てられます。 対して Production Mode はすべての一般ユーザーがアクセスする共有環境であり、ユーザーはこの環境でデータモデルを探索しダッシュボードを構築します。デフォルトの構成では、本番ブランチ（通常は master または main）の最新コードが本番環境で実行されますが、高度な設定を用いることで、特定のリリースバージョン（コミットやタグ）のコードを実行するよう厳密に管理することも可能です。 開発モードの場合、画面上部に「現在は Development Mode です。」というテキストが表示されたバナーが配置されます。右上にある「Exit Development Mode（Development Mode を終了）」という部分をクリックすると、本番環境モードへ切り替わり、このバナーは消えます。 開発モードから本番環境モードへの切替 本番環境モードから開発モードへ切り替える場合は、画面左上にあるメインメニューをクリックして開き、メニューの下部にある「Development Mode」をオンにします。開発モードと本番環境モードのオン・オフは、キーボードショートカット Mac : Control + Shift + D / Windows : Ctrl + Shift + D でもすばやく切り替えることが可能です。 本番環境モードから開発モードへの切替 LookML を変更する場合は、開発モードで作業する必要があります。LookML のコードを修正すると、「Save Changes」というボタンが表示されます。 LookMLの修正（例：列名の修正） このボタンをクリックすると変更内容が保存され、作業している個人の開発環境に変更が反映されます。 開発モードのダッシュボード 一方で、すべてのユーザーが共有する本番環境モードには、まだこの変更内容は反映されません。 本番環境モードのダッシュボード 個人の開発環境での変更を本番環境モードのユーザーにも見えるようにするためには、保存した変更を Git に「コミット」し、本番ブランチへ「デプロイ」するバージョン管理のステップを踏む必要があります。 参考 : Development Mode and Production Mode（開発モードと本稼働モード） IDE 内での Git 操作 Looker の統合開発環境（IDE）には、Git コマンドを操作するための GUI ボタン（IDE 右上、またはメインナビゲーションメニューの「Git Actions」パネル）が備わっています。開発者は複雑な Git コマンドを直接入力することなく、ボタン操作のみでコミットやリモートからのプル、本番環境へのデプロイといった一連のワークフローを実行できます。 特に便利なのは、この Git ボタンが現在の開発ステータス（ファイルの変更有無や他の開発者による更新状況など）に応じて、次に必要なアクションのみを動的に表示する点です。これにより、開発者は手順に迷うことなく、安全かつスムーズにバージョン管理を行うことができます。 参考 : Using version control and deploying（バージョン管理機能の使用とデプロイ） 参考 : Git コマンドのリファレンス Git リポジトリとの接続方法 概要 新規にプロジェクトを作成する際、まず Git リポジトリの構成設定を行います。 Git リポジトリは、外部の Git プロバイダと連携する「HTTPS を使用した接続」、「SSH を使用した接続」、または外部連携を行わずに Looker サーバー上にローカルリポジトリを作成する「ベア Git リポジトリ」の 3 つの構成オプションのいずれかを選択できます。 HTTPS を使用した接続 HTTPS 接続では、ユーザー名と 個人用アクセストークン（Personal Access Token） を使用して認証を行います。 運用方法として、プロジェクト全体で 1 つの Git アカウントを共有する設定と、Looker の「ユーザー属性」機能を用いてデベロッパーごとに個別の Git アカウントを使用する設定が選択可能です。 なお、単一の Git アカウントを共有する場合でも、Looker は各デベロッパーの Looker ユーザー名を使用してコミットを行うため、誰が変更を加えたかの履歴は正しく追跡されます。 ただし、注意点として Looker は現在、GitHub の きめ細かい個人用アクセス トークン（Fine-grained personal access tokens） をサポートしていません。そのため、GitHub を利用する場合は、必ず 「Tokens (classic)」 のオプションを使用してトークンを作成してください。 参考 : HTTPS を使用した Git への接続 参考 : GitHub - Managing your personal access tokens SSH を使用した接続 SSH 接続では、 Looker が生成する公開鍵を Git プロバイダー側に登録することで認証を行います。手順としては、 Looker 側で SSH 公開鍵を生成してコピーし、 Git プロバイダーのリポジトリ設定画面で「Deploy Key」として登録します。この際、 Looker からリポジトリへ変更をプッシュできるよう、書き込みアクセスを許可（Allow write access）を有効にする必要があります。 参考 : SSH を使用した Git への接続 ベア Git リポジトリ リモートの Git プロバイダーを準備していない場合や、すぐに開発を開始したい場合、 Looker サーバー上にローカルリポジトリを作成する ベア Git リポジトリ 構成も選択できます。 ただし、ベア Git リポジトリではプルリクエストの作成など一部の機能が使用できないため、あくまで一時的な利用にとどめることが推奨されます。最初はベアリポジトリで開始し、後からリモートの Git プロバイダーへ接続し直すことも可能ですが、その場合は「まだ Git 履歴を持たない空のリポジトリ」に接続する必要がある点に注意してください。 参考 : ベア Git リポジトリの構成 デフォルトのワークフロー 概要 Looker の標準的なデプロイフローは、開発モード（個人の開発ブランチ）での作業から、共通のリモートリポジトリを経由して、本番環境へと反映される一連のステップで進行します。 開発ブランチへの変更のコミット 開発モードで LookML の修正が完了したら、LookML の検証（Validate LookML）ボタンをクリックします。 LookML にエラーが見つからなければ、ボタンは「Commit Changes & Push」に変わります。 エラーがあった場合は、LookML の検証欄にエラー内容が表示されます。 LookMLの検証 「Commit Changes & Push」ボタンをクリックすることで、コミットのメッセージを入力する画面が表示されます。 コミットの内容をメッセージ欄に入力して、「Commit」ボタンをクリックすることで、変更を開発ブランチに保存（コミット）します。 この操作により、作業内容に名前を付けて保存し、後から履歴を追えるようになります。 メッセージを入力してコミット プロジェクトの設定によっては、変更をコミットする前に LookML Validator によるエラー修正や、データテストへの合格が必須となる場合があります。 開発ブランチを本番環境ブランチにマージする コミットされた変更は、共有のリモートリポジトリへプッシュされます。デフォルト設定の Looker では、IDE 上の「本番環境にデプロイ（Deploy to Production）」ボタンをクリックすることで、開発ブランチの内容が本番ブランチ（通常は master または main ）へマージされます。 本番環境にデプロイ Looker 本番環境への本番環境ブランチのデプロイ IDE での「本番環境にデプロイ」操作を行うと、マージに続いて Looker の本番環境（Production Mode）が自動的に本番ブランチの最新コミットを参照するように更新されます。これにより、エンドユーザーが参照するダッシュボードや Explore に最新の定義が即座に反映されます。 本番モード環境のダッシュボード 品質と安全性を高める設定 概要 「プロジェクト構成（Project Configuration）」ページの設定を変更することで、より厳格なリリース管理を実現できます。これらは、複数人での大規模開発においてコードの品質と環境の安定性を維持するために重要です。 参考 : Configuring project version control settings（プロジェクトのバージョン管理の設定） LookML バリデーションの必須化 LookML Validator によるエラーチェックを、変更をローカルブランチに コミットする前の必須条件 として設定できます。設定により「エラーと警告の両方を修正」または「エラーのみを修正」を必須にすることが可能です。これにより、構文エラーを含んだ不正なコードがプロジェクトの履歴に混入することを未然に防ぐことができます。 データテストの必須化 LookML 内に test パラメータを定義してモデルのロジックを検証するデータテストを作成している場合、本番環境へデプロイする前にこれらのテストに合格することを必須条件に設定できます。なお、新しく作成された LookML プロジェクトでは、このオプションがデフォルトで有効になっています。 プルリクエスト（PR）の統合 Pull Request Required 設定を有効にすると、デベロッパーは Looker IDE 内で直接本番ブランチへマージすることができなくなります。変更を本番環境に反映させるためには、必ず GitHub 等の外部サービス上でプルリクエストを作成し、第三者によるコードレビューを経てマージする必要があります。これにより、開発ガバナンスを大幅に高めることができます。 Looker は「マージコミット」方式のみをサポートしているため、この機能を利用する場合は、Git プロバイダ側で「スカッシュマージ」や「リベースマージ」のオプションを使用不可にしておくことが推奨されます。 参考 : プロジェクトの pull リクエストを統合する 高度なデプロイモード Advanced Deploy Mode（高度なデプロイモード） を有効にすると、常に本番ブランチの最新状態を自動デプロイするデフォルトの動作が解除されます。代わりに、デプロイ権限を持つ担当者が特定のコミット SHA や Git タグ（リリースバージョンなど）を明示的に指定して本番環境へ反映させることが可能です。 この機能により、Git 上でのマージと Looker へのリリース反映タイミングを完全に切り離し、Webhook や API を利用した複雑なリリースパイプラインを構築できます。ただし、このモードを有効にした場合、本番環境への「最初の1回目」のデプロイは、必ず Looker IDE 内の Deployment Manager から手動で実行する必要がある点に注意してください。 参考 : 高度なデプロイモード 菊池 健太 (記事一覧) 事業開発部クラウドサポート課。2024年7月より、G-genに入社。群馬出身のエンジニア。前職でLookerの使用経験はあるが、Google Cloudは未経験なので現在勉強中。

AWS は 2026 年 4 月 18 日 – 22 日にラスベガスで開催された世界最大の放送機器展「NAB Show 2026」に出展し、 30 を超えるデモを展示 しました。全デモの 83% に AI が組み込まれ、 そのうちの半分の展示に AI エージェントが採用されるなど、さまざまなメディアワークフローに AI が組み込まれていました。 AWSメディアセミナーでは、NAB Show に参加したソリューションアーキテクトの井村紀彦と小南英司が登壇し、AWS ブース展示の中から注目度の高いトピックを厳選してご紹介しました。 本セミナーは AWS Black Belt Online Seminar シリーズ として資料を公開しています。 NAB Show 2026 recap メディア & エンターテインメント業界編 [ 資料 ][ 動画 ] Multiplatform Distribution — クラウド × IP × AI でライブ配信を再定義 MXL（Media eXchange Layer）— 11 社相互運用で業界標準が現実に 本エリアで最もインパクトが大きかったのが MXL v1.0 の正式リリースです。非圧縮メディアを超低遅延で交換するクラウド共通規格が存在しなかったために、これまでのライブ制作では環境がベンダーロックインされてしまったり複雑なインテグレーションを自前で行う必要があったりと困難が生じていました。NAB Show のデモでは、 Amazon EC2 上の共有メモリと EFA RDMA を活用し、11 社が映像や音声、メタデータを放送品質で相互に共有しました。多くの製品間で相互運用性が成立することを示した点が画期的です。 3つの AI エージェントでライブ配信障害を End-to-End で診断 ライブ配信の障害特定はこれまで時間と専門知識を要する課題で、視聴者から「映像が止まった」との問い合わせが来た際に、エンコーダーや途中経路、CDN などのどこが原因なのか、切り分けに多大な時間を要していました。会場で常に人だかりができていたこのデモでは、 Amazon Bedrock AgentCore と Strands SDK で実装した 1 つの Supervisor と 3 つのサブエージェントが、MCP（Model Context Protocol）を介して各データソースを統一的に分析します。本デモはこれらのバックエンドを 2 つの UI から利用できる点も特徴的で、非技術者向けの AI アシスタント Amazon Quick と技術者がトラブルシューティングやデプロイを行う AI IDE の Kiro を、利用者のスキルに応じて入口を選べます。実装サンプルは GitHubで公開 されており、任意の AWS アカウントへのデプロイが可能です。 その他の注目展示 AWS Elemental MediaConnect Router は、SDI マトリクスや IP ルーターを使わずにクラウド上でライブ映像フィードのルーティングや切替を API 経由で制御することが可能な AWS サービスです。TAMS（Time-addressable Media Store）は BBC が開発をしたオープンソースプロジェクトで、 Amazon S3 上に保存したライブ素材を TAMS 対応ソリューションを介して追っかけ編集したりプレビューしたりすることを紹介しました。また、AI ブランドセーフティのデモでは Amazon Bedrock と Amazon Rekognition 、 Amazon Transcribe でライブニュース映像をリアルタイムにカテゴリ分析して、適合した広告のみを配信する仕組みを展示しました。 Content Creation — コンテンツ制作 AWS Elemental Inference — 複数デモで存在感を示した今年最大の注目サービス AWS Elemental Inference は、AWS 初のライブ映像向け AI サービスで、追加の制作チームや特別な AI 専門知識を準備することなく、リアルタイムに縦型フォーマットに自動変換し重要シーンのハイライトクリップを自動抽出可能です。 AWS Elemental MediaLive や AWS Elemental MediaConvert と統合されており、既存ワークフローにそのまま組み込めます。Fox Sports での採用も発表されています。 その他の展示 Kiro を用いて Adobe Premiere Pro のネイティブプラグインを半日で開発するデモや、ComfyUI を Amazon EKS 上でコンテナ化することで GPU 環境を安価に実現する AI クリエイティブ環境、 AWS Deadline Cloud による最大 85% コスト削減のレンダリング最適化、Avid Content Core によるクラウド MAM 環境なども展示されました。 Media Lifecycle Management — アーカイブを収益源へ 本テーマは「アーカイブをコストセンターから収益源へ」で、メタデータの自動付与やメタレス検索などの検索の高度化、コンプライアンスや契約のチェックを行う利用可否の判定、多言語翻訳やニュース自動編集を行う作業の自動化の 3 軸で展示が行われました。 AI エージェントによるコンテンツ審査・契約書チェックの自動化 利用可否の判定で多くの来場者の注目を集めていた展示はコンテンツ審査の自動化です。 Amazon Nova で映像全体を分析してレーティングとモデレーションフラグを検出し、Amazon Bedrock Agents で権利検証とメタデータ品質管理を自動化することで、審査サイクルを大幅に短縮し、コンプライアンス基準への一貫した準拠を実現します。また契約書の構造化も多くの来場者を集める展示でした。膨大な PDF に埋もれた権利契約やライセンス、人材契約を、25 種のAI エージェントが分析し、 Amazon OpenSearch Service で検索可能なメタデータに変換します。これにより数十年分の契約を数秒で検索でき、権利判断の意思決定を大幅に加速することが可能です。 その他の展示 検索の高度化では Media2Cloud によるフレームレベル動画分析と、 MediaLake による自然言語によるマルチモーダル検索が展示されました。どちらもオープンソースで公開されており、すぐにデプロイ可能です。作業の自動化では Amazon Bedrock などを用いた 20 言語以上の字幕や吹替自動化が展示されました。 Revenue Generation — 収益の創出 本エリアでは、AI を用いることで中小企業が数分でテレビ広告を自動生成するデモ、広告エージェントによるメディアプラン立案の短縮、ライブスポーツ配信における文脈判断による広告挿入などが展示されました。 Builder Zone 製品開発チームによる高度な技術ディスカッションエリア「 Builder Zone」では、AWS Elemental Inference による縦型動画やハイライト自動生成、 AWS Elemental MediaConnect によるライブ配信品質監視（MQAR）と自動フェイルオーバー、AWS Elemental MediaConnect Router によるクラウドネイティブ映像ルーティング、 Amazon CloudFront の CBOR Web Token (CWT)/Common Access Token (CAT) によるミリ秒以下の認証トークンの展示がありました。 おわりに 本ブログでは、NAB Show 2026 の AWS のブース展示を 4 つのテーマで振り返りました。今年の展示が示した方向性は、(1) AI がリアルタイムを制す (2) IP × クラウドでソフトウェア化を加速 (3) アーカイブが”動く資産”になる (4) コンテンツ制作の民主化でした。セミナーにご参加いただいた皆さま、ありがとうございました。メディアチームでは、業界の皆様に役立つ情報を引き続きセミナーやブログで発信してまいります。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメールマガジンをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 この記事は SA 小南英司が担当しました。