Appearance
クラウド深度推定 — AM3D Cloud API 技術ガイド
概要
クラウド深度推定は、通常の 2D 動画を AI で解析し、Looking Glass で立体表示しやすい RGBD SBS 動画へ変換する AM3D の中核機能です。従来は GPU 搭載 PC 上で実行していた深度推定処理を、クラウド GPU 上の API として実行することで、iPad などのクライアント端末から利用できる構成を目指しています。
本記事では、AM3D Cloud API の仕組み、API の概念仕様、クライアント連携、運用上の考え方、制約、製品方針を公開可能な範囲で整理します。初学者でも理解できるよう、深度推定、RGBD SBS、Looking Glass、クラウド GPU などの前提知識から説明します。
はじめに — 初学者向け 前提知識
AM3D とは
AM3D は、2D 動画を AI で深度推定し、Looking Glass 向けに立体表示できる動画形式へ変換するシステムです。ここでいう「深度」とは、映像内の各ピクセルや物体がカメラからどれくらい近いか・遠いかを表す情報です。
AM3D の目的は、ステレオカメラや 3D カメラで撮影していない通常の単眼動画でも、AI によって奥行き情報を推定し、疑似的に立体表示できるようにすることです。
深度推定とは
深度推定とは、1 枚の画像または動画から「どこが手前で、どこが奥か」を AI が推定する処理です。AM3D では、動画の各フレームに対して深度マップを生成します。
深度マップは、奥行き情報を白黒画像として表したものです。一般的には、白に近い部分を手前、黒に近い部分を奥として扱う方式があります。ただし、実際の白黒方向はアプリや表示設定によって切り替えられる場合があります。
Looking Glass とは
Looking Glass は、専用メガネなしで立体映像を表示できるライトフィールドディスプレイです。社内資料や技術メモでは LKG と略されることがあります。
AM3D では、AI で生成した深度情報を使って、Looking Glass 上で立体的に見える動画を表示します。AM3D の変換結果は Looking Glass 上での立体視を前提としており、通常の 2D ディスプレイでは奥行き表現の効果を確認しづらい点に注意が必要です。
RGBD SBS とは
RGBD SBS は、カラー映像と深度マップを左右に並べた動画形式です。
| 用語 | 意味 |
|---|---|
| RGB | 通常のカラー映像 |
| D | Depth、つまり深度情報 |
| SBS | Side by Side。左右に並べる形式 |
AM3D の出力 MP4 では、左側にカラー映像、右側に深度マップを配置する構成を基本とします。Looking Glass 側はこの RGBD SBS 動画をもとに立体映像として表示します。
なぜクラウド化が必要だったのか
従来の AM3D では、深度推定処理をローカル PC 上のデスクトップアプリで実行していました。この方式には、以下の課題がありました。
| 課題 | 内容 |
|---|---|
| GPU が必要 | 深度推定 AI の実行には高い計算性能が必要 |
| セットアップ負荷 | Python、GPU ドライバ、依存ライブラリ、アプリの準備が必要 |
| 端末制約 | iPad などのモバイル端末単体では重い推論処理を実行しづらい |
| 利用者の限定 | 高性能 PC を用意できる利用者に限られる |
| 運用拡張性 | 端末ごとに環境構築する方式では提供・保守が難しい |
このため、深度推定処理のみをクラウド GPU へ移し、クライアント端末は動画送信・結果受信・ローカル再生に専念する構成へ移行しました。
現在の結論
AM3D のクラウド深度推定は、クラウド GPU 上の API として構築・検証されています。2D 動画の選択、クラウド送信、GPU 処理、結果受信、Looking Glass 表示までの一連フローが確認されています。
一方で、現行方針では AM3D を独立した単体製品として扱うのではなく、3D ビューアー機能の一部として組み込む方向です。クラウド深度推定は、展示・デモ、個別案件、単眼映像の立体化が必要な用途に向けた機能として位置づけます。
公開・外部提供を行う場合は、認証、利用上限、レート制限、動画長制限などを前提とします。未制限の API 公開は、セキュリティ面・コスト面の両方で避けるべきです。
システム全体像
AM3D Cloud API でクラウド化しているのは 深度推定部分のみ です。メッシュ化、キルト生成、レンチキュラー変換、Looking Glass 表示などのレンダリング処理は、iPad または PC 側で行います。
レンダリングまでクラウドで行う「フルクラウド方式」も検討されましたが、GPU コストやレスポンス時間が大きくなりやすいため、現時点では深度推定のみをクラウド化する構成を基本とします。
処理フロー
| ステップ | 処理内容 | 実行場所 |
|---|---|---|
| 1 | 2D 動画を選択 | iPad / Windows |
| 2 | 動画ファイルを API に送信 | iPad / Windows |
| 3 | クラウド側で GPU 実行環境を起動 | クラウド |
| 4 | フレームごとに深度推定 | クラウド GPU |
| 5 | カラー映像と深度マップを並べた RGBD SBS MP4 を生成 | クラウド |
| 6 | 生成 MP4 を返却 | クラウド |
| 7 | クライアント側で再生・Looking Glass 表示 | iPad / Windows |
採用技術
基本構成
| 項目 | 内容 |
|---|---|
| インフラ | クラウド GPU 実行環境 |
| 深度推定 AI | Video-Depth-Anything 系モデル |
| フレームワーク | PyTorch |
| 動画処理 | OpenCV、FFmpeg |
| API 方式 | HTTPS ベースのファイル送受信 |
| 出力形式 | RGBD SBS MP4 |
| 実行方式 | リクエスト時に GPU 処理を実行し、処理完了後に結果を返却 |
実装では、GPU インスタンスの起動時間、モデル読み込み時間、動画デコード・エンコード時間が全体処理時間に影響します。短尺動画でも、コールドスタートやモデルウォームアップが入ると一定の待ち時間が発生します。
なぜ Video-Depth-Anything を採用したか
AM3D では、深度推定 AI として複数のモデルを比較しました。Looking Glass 表示では、フレーム間の深度ブレや歪みが目立つため、速度だけでなく時間的整合性を重視しています。
| モデル | 速度 | 品質 | 時間的整合性 | 採否 | 理由 |
|---|---|---|---|---|---|
| FlashDepth 系 | 非常に速い | 良い | 低い | 不採用 | フレーム間で深度が揺れやすい |
| Depth-Anything-V2 系 | 速い | 良い | 中程度 | 不採用 | 動画として見たときの安定性が不足 |
| Video-Depth-Anything 系 | 遅い | 非常に良い | 高い | 採用 | Looking Glass 表示時のブレが少ない |
Video-Depth-Anything 系モデルの導入により、従来課題だったフレーム間のちらつきや輪郭の不安定さは改善されています。ただし、素材によっては深度推定の誤りや不自然な奥行きが残る場合があります。
参考リンク
- Modal
- OpenFaaS AWS EKS Scale to Zero GPUs - 2025
- Microsoft Learn - Azure Container Apps Serverless GPU
- RunPod Pricing Update - 2024/2025
- Modal Pricing & Performance Data - 2026
出典
- 0304
- 0323:公開方法と課金モデルの選択肢
- 0421:AM3D(クラウド深度推定) LKG販売戦略 検討
- 会議議事録まとめ(0304&0306)
- 0224クラウド検証:AM3D Cloud API 構築
- AM3D_Cloud_API_Report
- 0225クラウド処理、API化
- 0224山本再調査
- 0225クラウド費用コスト概算
- 0304議事録