G-gen の菊池です。当記事では、 Looker のスケジュール配信機能で配信されたデータが古いままになっており、バッチ更新された最新のデータが反映されない問題の解決方法を解説します。 事象 原因 対処法 概要 手順1. データグループの定義 手順2. Explore への適用 手順3. 永続的な派生テーブル（PDT）への適用 手順4. ダッシュボードでのトリガー設定変更 事象 BigQuery のデータを可視化する Looker のダッシュボード環境を想定します。BigQuery のテーブルデータは、毎朝バッチ処理によって、前日分のデータが自動的に更新・追加される設計です。 バッチ処理が正常に完了し、BigQuery のデータが最新化されたタイミングで、Looker のダッシュボードを定期配信するスケジュール機能（メール送信など）を実行しています。 しかし、BigQuery のデータが最新になっているのにもかかわらず、スケジュール機能で自動配信されたレポートには前日分のデータが反映されておらず、古い内容のままで届いてしまう事象が発生しました。 ユーザーが Looker のダッシュボード画面を開き、手動で「キャッシュをクリアして更新」を実行した場合は、前日分を含む最新のデータがダッシュボード上に正しく表示されました。このため、配信レポートが古いままであることを防ぐために、担当者が毎朝わざわざダッシュボードを開いて手動で更新をかけるという、余計な手間や運用コストが発生してしまいます。 原因 この事象が発生する原因は、Looker が備えるクエリキャッシュ機能です。Looker はデータベースへのクエリ負荷を下げるために、過去に実行したクエリ結果を一時的にキャッシュします。Looker のデフォルト設定では、クエリのキャッシュ保持期間は 1 時間です。 参考 : クエリのキャッシング - Lookerにおけるキャッシュされたクエリの用途 手動でダッシュボード上の「キャッシュをクリアして更新」を実行すると、Looker はキャッシュを無視してデータベースに直接クエリを発行するため、データソースの最新のデータが表示されます。一方で、時間指定で動作するスケジュール配信は、 キャッシュ保持期間内だった場合、Looker に保存されている有効期限内のキャッシュ（古いデータ）をそのまま利用してレポートを作成して、送信してしまいます。 これが、スケジュール配信のレポートだけが古くなってしまう原因です。 参考 : ダッシュボードの表示 - ダッシュボードのデータの更新 対処法 概要 スケジュール配信で常に最新のデータを表示させるためには、データベースの更新タイミングと Looker のキャッシュ期限を同期させる必要があります。 これらを実現する機能が、Looker の データグループ （datagroup）です。 データグループを使用することで、データベースの更新を Looker が自動的に検知し、キャッシュをリセットできます。 Looker では、スケジュール配信の起動条件として「時間指定」だけでなく「データグループの更新完了」を指定できます。 データグループの更新完了をスケジュール配信のトリガーに設定すると、以下の順番で配信処理が行われます。 データベースの更新完了を Looker が検知する 最新のデータでキャッシュを再構築・クリアする キャッシュの更新プロセスが完了した後に、スケジュール配信を送信する これにより、バッチ処理の完了を待ってからレポートが送信されるため、データが古いまま送信されるリスクを完全に排除できます。 参考 : クエリのキャッシング - キャッシュ保持ポリシーを変更する 参考 : ダッシュボードのスケジューリングおよび送信 - データグループの更新によってトリガーされるスケジュール 手順1. データグループの定義 LookML のモデルファイルにデータグループを設定します。 datagroup : bigquery_daily_datagroup { sql_trigger : SELECT MAX(insert_timestamp) FROM `your_project.your_dataset.your_table` ; max_cache_age : "24 hours" label : "BigQuery Daily Batch Trigger" description : "毎朝のBigQueryデータ更新を検知しキャッシュをリセットするデータグループ" } BigQuery のデータ更新を検知するために、 sql_trigger パラメータを使用します。 sql_trigger に指定する SQL クエリは、バッチ処理の完了時に結果の値が変化するクエリを設定します。例として、更新タイムスタンプの最大値や、最新レコードの ID が挙げられます。この値が前回のチェック時から変化したことを Looker が検知すると、データグループがトリガーされます。 また、バッチ処理が失敗した際のセーフティとして、キャッシュの有効期限を定義する max_cache_age パラメータを組み合わせて設定します。クエリがキャッシュされてから max_cache_age に設定した期間を過ぎると、キャッシュは無効となり、次回のクエリ発行時に、データベースから最新の結果が取得されます。 ここで注意すべきなのは、Looker は sql_trigger 内の SQL クエリに対して、 タイムゾーン変換を自動で行わない という仕様です。 通常の Explore を介したクエリでは、 Looker のユーザータイムゾーン（User Time Zone）などの設定により、データベースに送信される日時の値が自動的に日本時間（JST）などに変換されます。 しかし sql_trigger で実行されるクエリは、データベース接続のバックグラウンドプロセスでそのまま実行されるため、Looker による自動的な変換処理が行われません。 たとえば、 BigQuery の標準のタイムゾーンは UTC です。 以下のように単純な SQL クエリを記述した場合、意図しないタイミングでトリガーが評価されてしまいます。 sql_trigger : SELECT CURRENT_DATE() ; 上記の例は、本来は日付が変わることをトリガーにした例です。しかし上記の SQL は BigQuery 上で実行され、デフォルトの UTC で処理されます。その結果、日本時間（JST）の午前9時にようやくトリガーが実行されることになり、朝一の配信に間に合わなくなります。 これを防ぐためには、以下のように SQL クエリ内で明示的にタイムゾーンを指定してください。 sql_trigger : SELECT CURRENT_DATE("Asia/Tokyo") ; また、バッチ処理の完了を検知するためにテーブルの最新のタイムスタンプを参照する場合も、以下のようにタイムゾーンを考慮した変換を組み込みます。 sql_trigger : SELECT DATE(MAX(insert_timestamp), "Asia/Tokyo" ) FROM `your_project.your_dataset.your_table`; このように、 sql_trigger に記述する SQL では常にデータベース本来の基準時間（UTC 等）で実行される前提で、クエリ自体に明示的なタイムゾーン指定を含める必要があります。 参考 : datagroup - sql_trigger 手順2. Explore への適用 定義したデータグループを、ダッシュボードが参照している Explore に紐付けます。 紐付けには persist_with パラメータを使用します。 特定の Explore に設定する場合は、以下のように記述します。 explore : your_explore_name { persist_with : bigquery_daily_datagroup } モデル全体（すべての Explore）に一括して適用する場合は、モデルファイルのトップレベルに記述します。 persist_with : bigquery_daily_datagroup 参考 : クエリのキャッシング - データグループを使用してExploreのクエリキャッシュリセットを指定する 参考 : persist_with (for Explores) 参考 : persist_with (for models) 手順3. 永続的な派生テーブル（PDT）への適用 ダッシュボード内の要素が、永続的な派生テーブル（以下、 PDT）を参照している場合は、保存された View ファイル内の derived_table 定義にもデータグループを適用します。 これにより、データベースの更新を検知した直後に PDT も自動的に再構築されます。 view : your_view_name { derived_table : { datagroup_trigger : bigquery_daily_datagroup sql : SELECT ... ; } } 参考 : クエリのキャッシング - データグループを使用してPDTの再構築トリガーを指定する 手順4. ダッシュボードでのトリガー設定変更 LookML での記述が完了したら、 Looker のユーザーインターフェース上で、ダッシュボードのスケジュール配信設定をデータグループの更新に同期させます。 具体的な設定手順は以下のとおりです。 対象のダッシュボードを開き、右上にあるその他メニュー（縦の3点リーダー）から「配信をスケジュール設定」を選択 「スケジュール配信」ウィンドウが開いたら、「繰り返し」のプルダウンメニューから「データグループの更新」を選択 新たに表示される「データグループ」の選択フィールドから、定義した bigquery_daily_datagroup を指定 宛先や形式（PDF、CSV zip 等）を必要に応じてカスタマイズし、ウィンドウ下部にある「保存」ボタンをクリック これで、毎朝のバッチ処理完了から、Looker のキャッシュクリアと PDT の再構築、スケジュール配信送信、という一連の流れが自動的に同期され、常に最新データが含まれるレポートを配信できます。 参考 : ダッシュボードのスケジューリングおよび送信 - データグループの更新によってトリガーされるスケジュール 菊池 健太 (記事一覧) 事業開発部クラウドサポート課。2024年7月より、G-genに入社。群馬出身のエンジニア。前職でLookerの使用経験はあるが、Google Cloudは未経験なので現在勉強中。

LINEヤフーでは、ユーザーの目的に応じてさまざまなサービスや機能をつなぐAIエージェントサービス「Agent i」の開発を進めています。Agent iで多様なニーズに応えるには、現場のアイデアを素早...

本記事は 2026 年 4 月 19 日 に公開された「 EngineLab AI: Production-ready AI for studios and creators on AWS 」を翻訳したものです。 スタジオは今、重大なジレンマに直面しています。AI ツールは制作ワークフローの加速を約束する一方で、導入にあたってはセキュリティ、知的財産 (IP) 保護、制作の安定性に関する現実的な懸念と向き合わなければなりません。本記事では、このトレードオフを解消するソリューションを紹介します。 ComfyUI のような AI ツールを活用すると、AI コンテンツ生成向けのオープンソースなノードベースのインターフェースを通じて、モデル、処理ツール、クリエイティブな操作を組み合わせ、本番グレードのワークフローとして複雑な AI 機能を視覚的に設計・制御できます。しかし、制作ワークフローの加速や新たな効率化をもたらす新興技術にありがちなように、リスクも伴います。急速に進化する AI の世界では、標準化、パイプライン統合、アプリケーションの安定性といった課題が生じます。セキュリティ面の懸念はさらに複雑です。使用するモデルの出所を把握して法的要件に対応しつつ、AI ワークフローを流れる IP を厳格なセキュリティ基準に従って保護する必要があるからです。モデルや関連アーティファクトを適切に審査・承認しなければ、未承認の、場合によっては悪意あるツールやコードが作業環境に持ち込まれるリスクがあります。 これまでクリエイターは、AI を本番環境に導入するにあたって、こうしたメリットとリスクのバランスを取ることを余儀なくされてきました。 AWS のメディア・エンターテインメント専門パートナーである EngineLab は、 EngineLab AI というマネージドデプロイメントプラットフォームを提供開始しました。AWS インフラストラクチャ上に構築され、ComfyUI などの AI アプリを安定した、セキュアで本番対応のツールセットとしてパッケージ化しています。メディア・エンターテインメント業界に特化して設計されており、ワークフローの特性を理解したうえで、ワークフローを高度に構築するユーザーから定型プロセスを活用したい一般ユーザーまで、チームのすべてのアーティストが強力な AI 機能を使えるようにします。 「スタジオからは、AI を本番環境で使いたいが、現状の不安定さとリスクは受け入れられないという声を聞いています。私たちは、そのハードルを取り除くプラットフォームを構築しています。業界が求めるセキュリティとコントロールを備えた形で、AI ツールをスタジオのワークフローに組み込んでいきます。」— Sam Reid、EngineLab 共同創業者 兼 CEO 本記事では、EngineLab AI でこれらの課題を解決する方法を紹介します。具体的には、完全なデータ主権を確保するために AWS アカウントへ直接デプロイする方法、最適な可用性とコストを実現するために AWS が提供するグローバル GPU リソースを活用する方法、そして IP を保護しながらワークフローに必要なクリエイティブな柔軟性を損なわないセキュリティ制御を統合する方法を説明します。 安定したスケーラブルな AI ワークフローの実現 スタジオにとって、高性能な GPU ハードウェアの調達はますます困難かつ高コストになっています。部品不足、価格上昇、オンプレミスインフラの維持管理にかかる負担により、AI ワークロードが必要とする GPU 容量を構築・維持することが難しくなっています。ハードウェアを調達できたとしても、多様なプロジェクトやチームにわたって安定的かつ効率的に割り当てるという課題が残ります。 ComfyUI の Web ベースアーキテクチャは、従来のリモートデスクトップソリューションに対して大きな優位性を持ちます。一般的なクラウドワークステーションは Virtual Desktop Infrastructure セッションを使用し、キーボード、マウス、Wacom タブレットなどの入力操作を含むデスクトップ画面をリモートからローカルクライアントにストリーミングします。一方、ComfyUI はローカルの Web ブラウザ上で動作し、処理負荷の高い演算はサーバー側で実行されます。ユーザーインターフェースはレイテンシーの影響を受けないため、重要なアーキテクチャ上の優位性が生まれます。つまり、レイテンシーを気にせずコンピューティングリソースをリモートでプロビジョニングできるのです。 EngineLab AI はこの柔軟性を活かし、 AWS グローバルインフラストラクチャ を動的に活用します。利用可能な Amazon Elastic Compute Cloud (Amazon EC2) 容量 (コンピューティング集約型ワークロード向けにオンデマンドの GPU インスタンスを提供する AWS のスケーラブルな仮想サーバーサービス) を持つ AWS リージョン (地理的に分離された AWS データセンターのクラスター) を活用します。これにより EngineLab AI は、 GPU 搭載の Amazon EC2 インスタンスタイプ のグローバルプールにアクセスできます。Blackwell、Ada Lovelace、Ampere などの NVIDIA GPU アーキテクチャを幅広くサポートし、vCPU 数やメモリ構成も多様なため、複数のリージョンにわたって可用性を高め、固定のローカルハードウェアをめぐるリソースの取り合いを減らせます。Amazon EC2 インスタンスを活用することで、AI ワークフローの固定費を削減し、必要なときに必要なだけ GPU リソースにオンデマンドでアクセスできます。 また、現在のタスクに合わせてコンピューティングリソースを最適化できます。クラウドインフラストラクチャが各ジョブに適切なリソースを動的に割り当てられるなら、すべてのアーティストがデスクの下に高性能グラフィックカードを置く必要はありません。GPU リソースを複数ユーザーで分割することでコストをさらに削減でき、パフォーマンスを犠牲にすることなく、オンプレミスハードウェアの固定費や運用負担なしに、大規模な GPU コンピューティングへの安定したアクセスを実現します。 EngineLab AI: スタジオとクリエイター向けマネージドプラットフォーム EngineLab は AWS グローバルインフラストラクチャを基盤に、メディア・エンターテインメント向けに一から設計されたマネージドプラットフォームを開発しました。AI ツールを本番環境に導入する際にスタジオが直面する固有の課題に対応しています。 図 1 に示すように、プロジェクト管理インターフェースではワークフローを一元的に把握できます。管理者はここから、アクティブなワークフローの確認、リソース使用状況の監視、アーティストのアクセス管理を行えます。 図 1: EngineLab AI のプロジェクト管理インターフェース。管理者がワークフローを追跡し、リソースを監視し、アーティストのアクセスを管理する様子を示しています 複雑な操作なしに即座にセッションを開始 AI ツールを使うためにクラウドインフラストラクチャの知識は不要です。EngineLab AI では、アプリを選択して起動するだけで AI アプリを使い始められます。適切なコンピューティングのプロビジョニング、環境の読み込み、安定したセッションの提供まで、すべてが自動で処理されます。セットアップも、トラブルシューティングも、待ち時間も不要です。スタジオはプロジェクト単位で作業を整理し、アーティストは必要なアプリをその中で起動するだけです。締め切りのある作業では、セッションが起動しなかったり途中で止まったりすることは許されません。一貫性と信頼性のある操作性が重要です。 アーティスト UI: すべてのアーティストが使える高度なワークフロー どのスタジオにも、複雑なノードグラフを使って高度なワークフローを構築する ComfyUI のエキスパート (技術的なパワーユーザー) がいます。しかし、大規模な運用では、アーティストは自分がエキスパートになることなく、そうしたワークフローの恩恵を受けたいと考えるのが一般的です。Artist UI は、入力・プロンプト・出力といった基本的なエンドポイントを提供することで、このギャップを埋めます。アーティストは画像をアップロードし、求めるものを言葉で伝えるだけで結果を得られます。ノードグラフを操作することなく、裏側でエキスパートのワークフローが動いているのです。 これはスタジオにとって重要な課題、すなわち IP の保護も解決します。カスタムワークフローは実質的な競争優位性を持つ資産であり、ワークフローとユーザーの間に何も介在しなければ、フリーランサーが次の仕事先にそれを持ち出すことを防ぐ手段がありません。Artist UI は境界として機能し、スタジオ全体がその機能を利用できる一方で、内部のワークフローが外部に露出することはありません。 データ主権: セキュリティの確保 本ソリューションはお客様自身の AWS アカウントおよび環境にのみデプロイされるため、包括的な制御とデータ主権が確保されます。顧客データがトレーニングに使用されることはなく、スタジオが制作したものはそのスタジオのものとして扱われます。その利用方法について曖昧さは一切ありません。多くのプラットフォームがデータの取り扱いについて意図的に曖昧な表現を用いる中、EngineLab AI は意図的に明確な姿勢を取っています。またこのアプローチは、コミュニティが開発した AI ワークフローを実行する際に生じるセキュリティリスク、特に不正かつ悪意のあるコードインジェクションへの対策も含んでいます。厳格なデータ要件を持つ主要クライアントと取引するスタジオにとって、これは本番環境に不可欠な要素です。 モデルトレーニング: セキュアな環境と完全な制御 プラットフォームにはトレーニングアプリが含まれており、スタジオは独自のコンテンツを取り込んで、ファインチューニング済みの基盤モデルや、特定のパラメーターのみを変更する Low-Rank Adaptation (LoRA) をトレーニングできます。LoRA はスタイルのカスタマイズにおいて、より高速かつコスト効率に優れています。トレーニングはプラットフォーム環境内で実行されるため、トレーニングデータがプライベートアカウントの外に出ることはありません。トレーニング完了後、カスタムモデルは ComfyUI ワークフローから直接利用可能になり、モデルとその作成に使用したデータの両方をスタジオが完全に管理します。これは、カスタム AI モデルの能力を活用しながらも、独自データが他の場所でのモデルトレーニングや競合他社への利益供与に使われるリスクを避けたいスタジオの重要なニーズに応えるものです。 完全な制御: アクセス管理とプロベナンス 管理者は最小権限モデルによってプラットフォームをきめ細かく制御できます。ユーザーとリソースには各タスクの実行に必要な権限のみが付与され、エキスパートと管理者はモデルのアップロードと承認が可能な一方、その他のユーザーのアクセスは制限されます。ベンダー固有の承認にも対応しており、特定のプロジェクトでは承認済みモデルのみが使用されます。これは、厳格なコンプライアンス要件を持つクライアントと取引するスタジオにとって不可欠な要件です。包括的な監査証跡によってプロジェクトごとのモデル使用状況を追跡し、クライアントへの報告やコンプライアンス検証に活用できます。また、プロベナンス追跡により、モデルの出所と組織全体での使用状況を正確に把握できます。 図 2 の AI Model Library インターフェイスは、モデルと LoRA の分類・承認・管理を一元的に行うビューを提供します。 図 2: EngineLab AI の AI Model Library 管理ページのスクリーンショット パイプライン統合: スタジオワークフロー全体でのコンピューティング EngineLab は、パイプラインに関する深い専門知識とハイエンドなクリエイティブワークフローにおける豊富な経験を持つチームをプラットフォームに結集しています。アーティストの時間が最も重要であるという認識のもと、チームは ComfyUI に関連する GPU および CPU コンピューティングを既存のレンダーファームワークフローに直接統合する取り組みを進めています。これには、ワークフローの需要に応じてコンピューティングリソースを自動的にスケールする完全マネージド型レンダーファームサービス AWS Deadline Cloud を活用しています。この統合により、ComfyUI フロントエンドは軽量なマシンで動作しながら、重い GPU タスクをレンダーファームにオフロードでき、インターフェイスと処理能力を切り離すことが可能になります。これは、ツールを本番環境に統合するための知見を持つ EngineLab が、その複雑さを引き受けることでスタジオの負担を軽減する、自然な進化の形です。 「私たちは EngineLab がプラットフォームを開発する過程でパートナーシップを築いてきました。社内にはすでに強力な ComfyUI の専門知識がありますが、スタジオ全体にそれをスケールできる、管理されたセキュアな環境、そしてクライアント業務に必要な制御とガバナンスを備えた環境こそ、私たちが求めていたものです。」– Sean Costelloe、マネージング・ディレクター、Selected Works まとめ EngineLab AI は ComfyUI を実験的なツールから本番対応のプラットフォームへと進化させ、スタジオが AI ツールを導入する際に直面する重要な課題に対応します。スタジオの AWS アカウントに直接デプロイすることで、包括的なデータ主権とセキュリティを確保しながら、AWS が提供するグローバルな GPU リソースを活用して最適な可用性と価格を実現します。スタジオは従来のアプローチに伴うリスクやコストなしに、本番グレードの AI 機能を手に入れられます。安定してセキュアな AI 生成へのアクセス、クライアント業務に必要な制御、そして使い慣れたワークフローへの統合が実現します。 AWS インフラストラクチャの詳細 EngineLab AI は、コンピューティング集約型のクリエイティブワークロード向けに設計された実績ある AWS サービス上に構築されています。 Amazon EC2 – AI およびレンダリングワークロード向け GPU インスタンスを備えたスケーラブルな仮想サーバー AWS Deadline Cloud – コンピューティングリソースのスケーリングに対応したマネージドレンダースケジューリングサービス 次のステップ AWS およびクリエイティブワークフローへのクラウドインフラストラクチャ活用の開始方法については、AWS アカウントチームにお問い合わせいただくか、 AWS for Media & Entertainment をご覧ください。 EngineLab AI にアクセスして、AWS 上でセキュアかつスケーラブルな AI ワークフローをスタジオで活用する方法をご確認ください。 Andy Hayes Andy Hayesは、AWSのシニア・ビジュアル・コンピューティング・ソリューション・アーキテクトです。VFX（視覚効果）とアニメーションの分野で20年にわたる経験を持ち、芸術・科学・技術の融合によって魅力的な映像を生み出すことに情熱を注いでいます。 Sam Reid SamはEngineLabのCEOであり、世界初となる完全クラウドネイティブなクリエイティブスタジオの立ち上げを主導しました。Untold StudiosではCTOとしてインフラをゼロから構築し、ロンドン、ロサンゼルス、ムンバイに拠点を置く500名以上のクリエイターを支える体制を整えました。現在は、テクノロジーを通じてクリエイティブなインパクトを生み出すことに注力し、EngineLabのビジョンと成長を牽引しています。 翻訳は Visual Compute SSA 森が担当しました。原文は こちら をご覧ください。