現在、スマートフォンやPCのOS、多くのアプリで当たり前のように提供されている「ダークモード」。 本記事では、ダークモードの歴史から、ダークモードが有効なケース、そして色彩設計のガイドまでを解説します。 ダークモードは原点回帰？ コンピューターの歴史を振り返ると、画面は最初からダークモード（暗い背景）でした。 1970年代から80年代前半、主流だったCRT（ブラウン管）モニターでは、画面全体を明るく発光させることは負荷が高かったため、「暗い背景に緑や白色のテキスト」を表示するのが基本でした。 しかし1970年代にGUI（グラフィカルユーザーインターフェース）が研究所で生まれ、1980年代前半から実用化・普及し始めると、画面設計の考え方は大きく変わりました。GUIを採用したパーソナルコンピューターでは、文書作成やデスクトップパブリッシング（DTP）が重要な用途となり、画面上で印刷結果を忠実に再現するWYSIWYGという考え方が広まりました。白い紙に黒い文字が印刷されていることを、画面上で表すことが基本となったのです。こうして、一般向けパソコンのGUIではライトモードが事実上の標準となりました。 この間、一般向けの画面は白くなりましたが、システムを開発するエンジニアたちは、非GUIな開発環境などで「黒い画面」を使い続けていました。 そして2010年代、スマートフォンが普及し、暗い場所でディスプレイを見る時間も増えました。スマートフォンで使われることの多い有機ELディスプレイは「黒色＝発光をオフにする」仕組みのため、黒背景にすることで消費電力を抑えることができます。OSやアプリケーションではデザインシステムが成熟し、ライトモードとダークモードの双方を前提とした設計が一般的になります。 「ダークモード＝目に優しい」は本当？ 「ダークモードは目に優しい」とよく言われますが、科学的には「無条件に目の負担が減るわけではない」というのが真実です。人間の目の「瞳孔」の働きによって、ライトモードとダークモードには一長一短があります。 ライトモードのメリット：ピント調節のしやすさ 人間は明るいものを見ると瞳孔が小さくなります。カメラの絞りを絞った時のように「焦点深度」が深くなるため（ピンホール効果）、目の筋肉に負担をかけずに文字にピントを合わせることができます。十分な照明環境では、ライトモードの方が読解速度や文字認識精度が高いという研究が報告されています。 カメラの絞りと被写界深度 ダークモードのメリット：暗所でのまぶしさ軽減 一方、ダークモードが真価を発揮するのは「周囲が暗い環境」です。暗い部屋でライトモードを見ると、強いコントラストによる「まぶしさ（光の刺激）」が強いストレスを与えます。暗所においては、発光量が少ないダークモードの方が主観的な目の疲労感が減少することが、研究で報告されています。 ダークモードと「ネオンサイン」のジレンマ ダークモードでは、白い文字やアイコンなどが光を帯びたようににじんで見えることがあります。 暗い画面を見ていると、目はより多くの光を取り込もうとして瞳孔を広げます。瞳孔が大きく開くと、目の光学収差や眼球内での光の散乱の影響を受けやすくなるため、暗い背景に表示された明るい文字などの高コントラストな要素は、輪郭がぼやけたり、光がにじんで見えたりする場合があります。 この見え方は、夜の街でネオンサインや街灯の光が周囲ににじんで見える現象と似ています。（ネオンサインや街灯のにじみには、大気中の塵や水滴による光の散乱も影響しているため、まったく同じ現象ではありません。） また、このような見え方は誰にでも起こり得ますが、乱視がある場合は光が特定の方向へ伸びたり、文字が二重に見えたりするなど、にじみがより目立つことがあります。 ダークモードが必要なケースと不要なケース こうしたメリット・デメリットを踏まえると、ダークモードはすべてのサイトやアプリで必須というわけではありません。ユーザーの「利用時間」「利用環境」「コンテンツの性質」によって優先度は大きく変わります。 ダークモードが求められるケース 夜間や暗所で利用されるアプリ ：地図、カーナビ、アラーム、電子書籍など。周囲の暗順応を妨げず、眩しさを抑える配慮が必要なため。 コンテンツ没入型（エンタメ ）：動画配信やゲーム、写真ギャラリーなど。周囲のUIを沈ませることで、メインコンテンツを際立たせるため。 U-NEXT プロ用の映像、写真編集ツール ：上記のエンタメコンテンツと同様に視線の分散を防ぐ効果に加え、周囲のUIを暗くニュートラルにすることで「目の錯覚（明るい背景に引っ張られて写真が暗く見える現象）」を防ぎ、色や明るさのディテールを正確に認識・編集しやすくなります。 ダークモードを必要としないケース 一過性のWebサイト・ランディングページ ：メーカーやキャンペーンサイトなど、ブランドの世界観を固定して伝えることが優先されるもの。 Canva ウェブページテンプレート 印刷を前提としたドキュメント ：履歴書・職務経歴書などの作成サービス、ワードプロセッサーアプリなど。印刷をすることが前提の場合、仕上がりをイメージしやすくなります。前述のWYSIWYGエディターです。 Canva 単なる「色反転」ではない、色彩設計ガイド ダークモードの配色は、ライトモードのカラーを機械的に反転したものではありません。 視認性を担保し、にじみによる目の疲労を防ぐための設計が必要です。 完全な黒の背景、完全な白の文字にはしない 背景色には完全な黒ではなく黒に近いグレーを採用します。真っ黒を避けることでコントラストを適度に抑え、目への刺激を和らげます。背景と同じく、テキストも完全な白を避けます。 白い背景に暗い文字のライトモードでは、にじんで見えることは少ないですが、暗い背景に明るい文字のダークモードで真っ白な文字にすると、前述のように滲むため、ライトモードよりもダークモードのコントラストは小さくします。 次の表は、Google Financeの背景と文字の色です。 ライトモード ダークモード 背景色 #FFFFFF：白 #101218：青系の黒に近い暗いグレー 文字色 #0A0A0A：黒に近い暗いグレー #E6E8F0：青系の明るいグレー コントラスト比 19.79 : 1 15.3 : 1 表の「コントラスト比」は、アクセシビリティ基準（WCAG）で採用されている計算方法によって算出される、2つの色のコントラストの度合いを示す指標です。「1:1」がコントラストなし、「21:1」が最大のコントラストを表します。 有彩色も明度や彩度を調整 テーマカラーやグラフの色（有彩色）は、ライトモードの色のままダークモードで利用すると、色によって、目立ちすぎたり、背景と見分けにくくなる場合があります。Google Financeの例では、ライトモードの緑と赤のグラフの色を、色相を変えずに明るい色に調整してダークモードに適用しています。 Google Finance おわりに：利用環境によって最適なUIは変わる ライトモードとダークモードは優劣の関係ではなく、それぞれ異なる利用環境に最適化されたデザインです。重要なのは「どちらが優れているか」ではなく、「ユーザーがどのような環境で、どのような目的で利用するか」を理解し、それに合わせて設計することです。 ちなみに：アナログ時代から脈々と… コンピューターよりも以前から、夜間の視認性に配慮した表示設計は、自動車や航空機の計器で発達してきました。夜間に明るすぎる計器を見ると暗順応が妨げられ、暗い道路や空など周囲の状況を視認しにくくなることがあります。また、計器の光が窓ガラスに映り込み、視界を妨げることもあります。そのため、計器には暗い背景が採用されるほか、用途に応じて赤やアンバーなど、夜間の視認性に配慮した照明色が用いられてきました。 Photo by National Cancer Institute Windows Ladislav Stercell Rui Silvestre Tyler Rooney Ed Wingate Sandisk Dragoș Grigore Nursultan Bakyt Boitumelo on Unsplash ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 脱・なんとなくのダークモード。歴史と生理学から考えるUIデザイン first appeared on SIOS Tech Lab .

1. はじめに Amazon Connect Customer は音声/ビデオとチャットを個別のチャネルとしてサポートしており、それぞれ独自の API を備えています。ネイティブウィジェットやカスタムウィジェットを使う場合、各チャネルは独立して動作します。一般的なコンタクトセンターのシナリオではこれで十分です。 しかし、顧客とエージェントのやり取りが通話だけでは済まない場合はどうでしょうか？ たとえば、顧客がローン申請の最終手続きのために電話をかけてきたとします。エージェントは事前承認を確認しますが、顧客は書類を確認して署名する必要がありますが、郵送された書類はまだ届いていない状況です。エージェントは顧客に電話を切って郵便を待つよう伝えるか、別でチャットを開始するしかありません。複数のやり取り、異なるエージェント、場合によっては数日の遅延が発生します。 もし通話中にエージェントが書類を送信できたらどうでしょうか？ 顧客はその場で署名して返送できます。同じエージェント、同じやり取りで済ませられ、数日ではなく数分で完了することができるでしょう。 本記事ではこのような課題を扱います。音声/ビデオとチャットを統合し、シームレスな顧客体験を実現するソリューションを紹介します。 1.1. Amazon Connect Customer で実現できる理由 根本的な課題はシンプルです。ライブ通話中に顧客がエージェントとテキストメッセージやファイルをやり取りするにはどうすればよいか、ということです。 Amazon Connect Customer は必要な API とツールを提供しています。StartWebRTCContact API で音声・ビデオ通話を開始し、DescribeContact API でエージェントが応答した後のエージェント ID を取得できます。コンタクトフローは特定のエージェントにルーティングするための属性をサポートしており、チャットウィジェットは初期化時にコンタクト属性を受け取れるため、チャット開始時にアプリケーションからエージェント ID を渡せます。 これらの機能はいずれも新しいものではありません。新しいのは、それらを組み合わせる方法です。カスタム UI がアクティブな通話からエージェント ID を抽出し、チャットのルーティングロジックに渡します。チャット中も顧客は同じエージェントに接続されたままで、切断や別のキューでの待機は不要です。 1.2. ビジネス価値 1 回の顧客・エージェント間のやり取りでチャネルを統合することで、具体的な効果が得られます。 顧客にとって: コールバックや転送、別のキューでの待機が不要になります。先ほどのローンの顧客は、数日ではなく数分で申請を完了できます。 運用面: エージェントが顧客対応をエンドツーエンドで完結できます。重複作業、引き継ぎの手間、フォローアップタスクによるエージェントの負荷がなくなります。 コンプライアンス面: すべての音声・チャットのやり取りが 1 人のエージェント、1 人の顧客、1 つのケースに紐づきます。規制の厳しい業界では、チャネルをまたいだコンタクトレコードの紐づけにより監査が容易になります。 2. ソリューションのアーキテクチャ このソリューションは、カスタムフロントエンドを 3 つのレイヤー (ホスティングと配信、認証と認可、リアルタイム通信) で AWS サービスに接続します。 2.1. 概要 以下の手順は、図の番号付きラベルに対応しています。 ステップ 1 — 認証。顧客がユーザーインターフェースにログインします。フロントエンドが認証情報を Amazon Cognito ユーザープール に送信し、検証後に ID トークンが返されます。 ステップ 2 — 認可。フロントエンドが ID トークンを Amazon Cognito アイデンティティプール に渡し、 AWS STS の AssumeRoleWithWebIdentity を呼び出します。IAM ロールが Amazon Connect に対する最小権限を付与し、一時的な認証情報がフロントエンドに返されます。これは重要な設計上のポイントです。フロントエンドは長期間有効なシークレットを保持せず、すべての認証情報はスコープが限定され、短期間で失効します。 ステップ 3 — 音声・ビデオ通話。顧客が通話を開始します。フロントエンドは一時的な認証情報を使って StartWebRTCContact API を呼び出し、WebRTCQueueRouting コンタクトフローをトリガーします。このフローが対応可能なエージェントに通話を割り当て、 Amazon Chime SDK のミーティング設定を返します。フロントエンドは Chime SDK セッションを初期化し、リアルタイムの音声・ビデオストリームを管理します。同時に、フロントエンドは DescribeContact API を呼び出してアクティブなコンタクトからエージェント ID を取得し、ローカルに保存します。 ステップ 4 — 同じエージェントとのチャット。顧客がチャットを開くと、フロントエンドは保存済みのエージェント ID を Amazon Connect Customer チャットウィジェット に渡します。チャットウィジェットは Amazon Connect Customer のホストエンドポイントから読み込まれます。チャットコンタクトが ChatAgentRouting コンタクトフローをトリガーし、エージェント ID を使って通話中の同じエージェントに直接ルーティングします。このステップで、音声/ビデオとチャットが 1 人のエージェントに集約されます。やり取りが終了すると、フロントエンドは StopContact と DisconnectParticipant API を呼び出してセッションを適切に終了します。 2.2. フロントエンドコンポーネント ユーザーインターフェースは 5 つのコンポーネントで構成され、それぞれ異なる役割を担います。 Authentication State Manager は、Cognito ユーザープールのフローを通じてログインを処理し、ID トークンを生成します。 Credential Manager は、そのトークンを Amazon Connect Customer API にスコープされた一時的な AWS 認証情報と交換します。 Session Manager は通話のセッション全体を管理します。暗号化されたセッションコンテキストをローカルストレージに保存し、通話の開始を制御し、チャットウィジェットのルーティング先となるエージェント ID を取得します。 WebRTC Manager はリアルタイムメディアを管理します。StartWebRTCContact の呼び出し、Chime SDK セッションの初期化、音声/ビデオストリームの管理を行います。 Chat Widget は Amazon Connect Customer のホストエンドポイントから読み込まれます。Session Manager からエージェント ID を受け取り、チャットを同じエージェントにルーティングします。コンタクトの作成、WebSocket 接続、メッセージング、ファイル添付など、チャットのライフサイクル全体を処理します。 2.3. バックエンドサービス バックエンドは 3 つのレイヤーの AWS サービスで構成されています。 ホスティングと配信: Amazon CloudFront がセキュリティヘッダーとキャッシュを使って UI をグローバルに配信します。Amazon S3 に静的アセットを保存します。 認証と認可: Amazon Cognito ユーザープール、Amazon Cognito アイデンティティプール、AWS STS、IAM が連携します。フロントエンドには必要最小限の権限のみが付与されます。 コミュニケーション: リアルタイムのやり取りが行われるレイヤーです。StartWebRTCContact API が WebRTCQueueRouting フローをトリガーしてエージェントを割り当てます。API は Amazon Chime SDK の設定を返し、フロントエンドがリアルタイムの音声・ビデオを確立します。DescribeContact API でエージェント ID を取得し、ChatAgentRouting フローがチャットを同じエージェントにルーティングします。StopContact と DisconnectParticipant API でセッションをクリーンアップします。 3. 前提条件 デプロイには、以下の準備が必要です。 AWS アカウント ファイル添付が有効化 された Amazon Connect Customer インスタンス AWS CDK v2 のインストールと設定 Node.js v20.x 以降 適切な権限で設定された AWS CLI 4. ソリューションのデプロイとクリーンアップ ソリューション全体は AWS CDK アプリケーションとして GitHub リポジトリ にパッケージ化されています。このスタックは CloudFront、S3、Cognito、IAM ロール、Amazon Connect Customer コンタクトフローなど、すべてをプロビジョニングします。 README にリポジトリのクローン、依存関係のインストール、Connect インスタンスの設定、スタックのデプロイ、テストユーザーの作成、統合体験の検証まで、各手順が記載されています。 以下のステップバイステップのデプロイ手順に沿って進めてください。テストが完了したら、不要な課金を避けるためにすべてのリソースを削除してください。 5. まとめと次のステップ 本記事では、1 回の顧客・エージェント間のやり取りで、Amazon Connect の 1 人のエージェントを通じて音声/ビデオとチャットを統合する方法を紹介しました。この方法は StartWebRTCContact と DescribeContact API、コンタクトフローのルーティング、Amazon Chime SDK、標準のチャットウィジェット、Amazon Cognito と AWS STS による短期間有効な AWS 認証情報など、既存の機能を組み合わせたソリューションです。 これは 1 つのアプローチにすぎません。完全な柔軟性を求める場合は、音声/ビデオとチャットのカスタムウィジェットをゼロから構築することもできます。Amazon Connect API ( StartChatContact でチャットを開始、 CreateParticipantConnection で WebSocket 接続を確立、 SendMessage でメッセージング、 StartAttachmentUpload と CompleteAttachmentUpload でファイル共有) を使えば、すべてのインタラクションをきめ細かく制御できますが、実装の複雑さが増します。可能な限り Amazon Connect Customer の組み込み機能を活用し、必要な部分だけカスタマイズすることをお勧めします。 まず、書類への署名、ビジュアルトラブルシューティング、フォーム送信など、顧客がタスクを完了するために複数のタッチポイントを必要とするケースを特定しましょう。 GitHub リポジトリ からソリューションをデプロイし、実際に動作を確認してみてください。その後、1 つのチームと 1 つのユースケースでパイロットを実施し、導入前後の対応時間、初回解決率、顧客の手間の変化を測定しましょう。そのデータをもとに、ソリューションが自社のカスタマーサービス運用に適しているかを評価しましょう。 6. 関連資料 ソリューションの GitHub リポジトリ Amazon Connect Customer 管理者ガイド: アプリ内、ウェブ、ビデオ通話、画面共有機能のセットアップ Amazon Connect Customer StartWebRTCContact API Amazon Connect Customer DescribeContact API Amazon Chime SDK for JavaScript Amazon Cognito デベロッパーガイド Amazon Connect Customer 管理者ガイド: ウェブサイトにチャットユーザーインターフェースを追加する 著者について Ying Qian は、コンタクトセンター技術分野で 19 年以上の経験を持ち、ソリューションアーキテクト、テクニカルプロジェクトマネージャー、ICT リードエンジニア、オペレーションエンジニアなどの経験があります。AWS ではサービス担当ソリューションアーキテクトとして Amazon Connect Telephony & Resiliency SME チームをリードし、AWS Well-Architected Framework の原則に沿った Amazon Connect の導入を支援しています。仕事以外ではジョギング、家族とのアルプスハイキング、ボーデン湖での水泳を楽しんでいます。 Nelson Martinez はシドニーを拠点とする Applied AI シニアソリューションアーキテクトです。コンタクトセンター、ユニファイドコミュニケーション、IP テレフォニー、ネットワーキングの分野でオーストラリアと米国にまたがり 31 年以上の経験を持ちます。AWS で 5 年以上にわたり、クラウドコンタクトセンターと Applied AI ソリューションを専門とし、グローバル規模で業界をリードする実装を直接お客様と進めています。 翻訳はテクニカルアカウントマネージャーの高橋が担当しました。原文は こちら です。

本記事は 2026 年 4 月 19 日 に公開された「 EngineLab AI: Production-ready AI for studios and creators on AWS 」を翻訳したものです。 AI ツールは制作ワークフローの効率化を約束する一方で、スタジオは難しいジレンマを抱えています。AIツールを利用するためにはセキュリティ、知的財産 (IP) 保護、制作の安定性に関する現実的な懸念を伴うためです。本記事では、そんな制作現場でのトレードオフを解消するソリューションをご紹介します。 ComfyUI のような AI ツールを活用すると、モデル、処理ツール、クリエイティブな操作をつなぎ合わせ、本番レベルのワークフローを視覚的に設計・構築できます。ComfyUI は 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 は、Blackwell、Ada Lovelace、Ampere など多様な NVIDIA GPU アーキテクチャを搭載した GPU 搭載 Amazon EC2 インスタンスタイプ のグローバルプールにアクセスできます。vCPU 数やメモリ構成も幅広く、複数リージョンにまたがって可用性を高めることで、固定のローカルハードウェアをめぐる競合を減らせます。Amazon EC2 インスタンスを活用することで、AI ワークフローの固定コストを削減し、必要なときに必要なだけ GPU リソースをオンデマンドで利用できます。 また、スタジオはタスクに応じてコンピューティングリソースを柔軟に選べます。クラウドインフラが各ジョブに適切なリソースを動的に割り当てられる環境では、すべてのアーティストがデスクの下に高性能グラフィックカードを搭載した機器を置く必要はありません。GPU リソースを複数ユーザーで分割することでコストをさらに削減でき、オンプレミスハードウェアの固定費や運用負担なしに、スケールした GPU コンピューティングへの安定したアクセスを実現します。 EngineLab AI: スタジオとクリエイター向けマネージドプラットフォーム EngineLab は AWS グローバルインフラを基盤に、メディア・エンターテインメント向けに一から設計されたマネージドプラットフォームを開発しました。AI ツールを本番環境に導入する際にスタジオが直面する固有の課題に対応しています。 図 1 に示すプロジェクト管理インターフェースでは、ワークフローの状況を一元的に把握できます。管理者はここからアクティブなワークフローの追跡、リソース使用状況の監視、アーティストのアクセス管理を行えます。 図 1: EngineLab AI のプロジェクト管理インターフェース。管理者によるワークフローの追跡、リソースの監視、アーティストのアクセス管理の様子を示しています。 複雑な操作なしに即座にセッションを開始 アーティストが AI ツールを使うためにクラウドインフラを理解する必要はありません。EngineLab AI では、アプリを選択して起動するだけで AI アプリが使えます。適切なコンピューティングのプロビジョニング、環境の読み込み、安定したセッションの提供まで、すべてが自動で処理されます。セットアップも、トラブルシューティングも、待ち時間も不要です。スタジオはプロジェクト単位で作業を管理し、アーティストは必要なアプリをその中で起動するだけです。締め切りを抱えた現場では、セッションが起動しなかったり途中で止まったりすることは許されません。一貫性と信頼性のある操作性が重要です。 Artist UI: すべてのアーティストが使える高度なワークフロー どのスタジオにも、複雑なノードグラフを使って高度なワークフローを構築する ComfyUI の上級ユーザーがいます。しかし規模が大きくなると、多くのアーティストは技術的な専門知識を習得することなく、そのワークフローの恩恵を受けたいと考えます。Artist UI はその橋渡しをします。入力、プロンプト、出力といった基本的なエンドポイントだけを公開することで、アーティストは画像をアップロードし、やりたいことを記述するだけで結果を得られます。ノードグラフを操作しなくても、裏側では高度なワークフローが動いています。 これはスタジオにとって重要な IP 保護の課題も解決します。カスタムワークフローは実質的な競争優位性を持ちますが、ワークフローとユーザーの間に何も介在しなければ、フリーランサーが次の仕事先に持ち出すことを防ぐ手段がありません。Artist UI が境界として機能することで、内部の実装を公開せずにスタジオ全体がその機能を活用できます。 データ主権: 安心のセキュリティ 本ソリューションは顧客自身の AWS アカウントおよび環境にのみデプロイされ、包括的なコントロールとデータ主権を提供します。顧客データはトレーニングに使用されません。スタジオが制作したものはスタジオのものであり、その利用方法に曖昧さはありません。多くのプラットフォームがデータの取り扱いについて意図的に曖昧な表現を使う中、EngineLab AI は意図的に明確な姿勢を取っています。また、コミュニティが開発した AI ワークフローを実行する際に生じるセキュリティリスク、たとえば未承認または悪意あるコードインジェクションから保護するよう設計されたコントロールも含まれています。厳格なデータ要件を持つ大手クライアントと仕事をするスタジオにとって、本番環境では不可欠な要件です。 モデルトレーニング: セキュアな環境と完全なコントロール プラットフォームにはトレーニングアプリが含まれており、スタジオは独自のコンテンツを使ってファインチューニング済みの基盤モデルや、特定のパラメーターのみを変更することでスタイルのカスタマイズをより高速かつ低コストで実現する Low-Rank Adaptation (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 for Media & Entertainment をご覧ください。 スタジオで AWS 上のセキュアでスケーラブルな AI ワークフローを活用する方法については、 EngineLab AI をご覧ください。 Andy Hayes アンディ・ヘイズは、AWSのシニアビジュアルコンピューティングソリューションアーキテクトです。ビジュアルエフェクトとアニメーションの分野で20年の経験を持つアンディは、芸術、科学、技術の融合によって生み出される魅力的な映像表現に情熱を注いでいます。 Sam Reid サムはEngineLabのCEOです。彼は世界初の完全クラウドネイティブなクリエイティブスタジオの立ち上げを主導しました。Untold StudiosのCTOとして、ロンドン、ロサンゼルス、ムンバイに拠点を置く500名以上のクリエイターを支えるインフラをゼロから構築しました。現在は、テクノロジーを通じてクリエイティブなインパクトを生み出すことに重点を置き、EngineLabのビジョンと成長を牽引しています。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は Visual Compute SSA 森が担当しました。原文は こちら をご覧ください。