画像から3Dモデルをローカル生成するOSS「Modly」の仕組み

画像 1 枚から 3D アセットを作りたい。しかもクラウドに素材を上げずローカルで完結させたい。この要件で選択肢を探し始めると、最初に見つかるのはモデル本体の研究リポジトリか、ComfyUI 向けのノード群です。どちらも強力ですが、Python 環境の構築、モデル重みの入手、依存パッケージのバージョン合わせといった作業が「使い始める前」に立ちはだかります。

さらに厄介なのは、環境構築を終えて生成できるようになった後で「このモデルの出力、商用案件で使っていいんだったか」という問いが出てくることです。画像から 3D を生成するモデルはライセンス条件が提供元ごとにばらばらで、ツール自体が無料・オープンソースであることと、生成物を業務で使えることは別の問題です。動かす前に判断材料が欲しい、というのが実務側の本音ではないでしょうか。

こうした状況で参照する価値があるのが、GitHub で公開されている Modly（lightningpixel/modly）です。Modly はモデル本体ではなく、モデルの入手・切り替え・生成・エクスポートまでを 1 つのデスクトップアプリに閉じた OSS で、GUI だけでなく CLI と MCP サーバーによる自動化経路も持っています。

本記事は、Modly の README・公式ドキュメント・公式サイト・GitHub API から取得できる公開情報のみを根拠として整理したものです。インストール・実行・生成といった動作検証は行っていません。そのため生成品質や実効性能の評価は扱わず、代わりにアーキテクチャ、拡張によるモデル差し替えの仕組み、自動化インタフェース、ライセンスの積層構造、類似 OSS との違い、メンテナンス状況という「採用可否を判断するための材料」に絞って解説します。数値は特記がない限り 2026 年 8 月 29 日時点の GitHub API 取得値です。

Modlyとは｜画像とプロンプトから3Dメッシュをローカル生成するOSS

Modly は、画像またはテキストプロンプトから 3D メッシュを生成するデスクトップアプリケーションです。リポジトリの description には「Desktop app to generate 3D models from images or prompt using local AI — runs entirely on your GPU」と記載されており、推論をユーザーの GPU 上で完結させる点が設計の前提になっています。ソースコードは GitHub リポジトリ lightningpixel/modly で公開され、配布・機能紹介は公式サイト modly3d.app が担っています。

Modlyが引き受ける範囲

画像から 3D を生成する OSS は数多くありますが、Modly が引き受けている範囲は「モデルそのものを提供すること」ではありません。README や公式サイトの記載から読み取れる守備範囲は、次の 4 つを 1 つのアプリに束ねることです。

• モデルの入手: 拡張機能をインストールすると、対応するモデルの重みが自動的にダウンロードされます
• モデルの切り替え: 複数のモデルを拡張として並存させ、アクティブなモデルを切り替えられます
• 生成: 「Workflows」タブで Image → Generate Mesh → Add to Scene といったグラフを組み、「Generate」タブで実行する流れが README に示されています
• エクスポート: 公式サイトによれば GLB / OBJ / STL / PLY で書き出せ、Blender・Unity・Unreal でそのまま利用できるとされています

README の Platform notes には、インポートしたメッシュに対してアプリ内でスムージングやデシメーション（面数削減）を適用し、結果をワークスペースに書き戻せることも記載されています。生成した直後のメッシュをそのまま使うのではなく、簡易的な後処理まではアプリ内で完結する設計です。

一方で、日本語の紹介記事では出力について「プロダクション品質ではなくベース生成品質であり、多くの場合トポロジー調整が必要」という評価が示されています（MODELING HAPPY の紹介記事）。本記事では動作検証をしていないため品質の断定は避けますが、少なくとも「ラフな 3D アセットや検証用モデルを素早く用意する用途」に位置づけて評価するのが妥当な出発点になりそうです。

対応プラットフォームについては、README が Windows / Linux / Apple Silicon macOS を挙げ、Intel Mac は対象外としています。ただし公式サイトのシステム要件は「NVIDIA GPU」と記載されており、両者の粒度は一致していません。後述する Apple Silicon 対応の設計文書がリポジトリ内に存在することを踏まえると README 側がより新しい状況を反映していると考えられますが、断定はできないため、macOS 環境での利用を前提にする場合は Releases のインストーラと実機構成で改めて確認することをおすすめします。

リポジトリの基本情報

判断材料として、GitHub API で取得できる基本情報を整理します。

取得日は 2026 年 8 月 29 日です。アーカイブ済みリポジトリやフォークではなく、本家として現在も更新が続いている点は、採用検討の前提として確認しておく価値があります。なお GitHub 上のライセンス表示が NOASSERTION（未確定）になっている理由は後述します。

Modlyのアーキテクチャ｜ElectronとFastAPIの二層構成

Modly は見た目こそ 1 つのデスクトップアプリですが、内部は明確に二層に分かれています。この構造を理解しているかどうかで、「単体で使う GUI ツール」と見るか「パイプラインに組み込める部品」と見るかが変わります。

リポジトリのルートには electron/（Electron の main プロセス）、src/（レンダラ）、api/（Python バックエンド）、tools/（CLI）、arch/（設計判断記録）、docs/ が並びます。言語構成も TypeScript 約 92 万行、Python 約 34 万行、C++ 約 8 万行に加えて CUDA と Metal が含まれており、UI・デスクトップ層を TypeScript、推論バックエンドを Python、GPU ネイティブ処理を C++ / CUDA / Metal が担う役割分担が読み取れます。

Electronが起動・管理するFastAPIバックエンド

推論側の実体は FastAPI サーバーです。api/README.md は冒頭で「Local Python server started and managed by Electron.」と述べており、Electron がローカルの Python サーバーを起動・管理する構成であることが明示されています。開発時の起動コマンドと主要エンドポイントは次のとおりです。

uvicorn main:app --host 127.0.0.1 --port 8765 --reload

出典: api/README.md

| Method | Path | Description |
|--------|------|-------------|
| GET | `/health` | Health check (used by Electron to detect readiness) |
| GET | `/model/status` | Model download / load status |
| GET | `/model/download` | SSE stream of download progress |
| POST | `/generate/from-image` | Start image-to-3D job |
| GET | `/generate/status/{job_id}` | Poll job status |

出典: api/README.md

注目したいのは、/health が「Electron が起動完了を検知するために使う」と説明されている点です。デスクトップ側とバックエンド側は共有メモリや埋め込みインタプリタではなく、127.0.0.1:8765 の HTTP で疎結合につながっています。ダウンロード進捗が SSE ストリームとして公開されているのも、GUI 以外のクライアントから同じ情報を購読できることを意味します。

つまり Modly のバックエンドは、GUI に強く依存しない独立した HTTP サービスです。この設計の帰結は後述する CLI・MCP サーバー、そして GUI を持たない環境での運用にまで一貫して波及しています。

なお、デフォルトで使われるモデルは api/README.md に TripoSR（stabilityai/TripoSR、約 2.4 GB）と記載されており、初回起動時に ~/.modly/models/TripoSR/ へダウンロードされます。変更したい場合は services/model_manager.py を編集する、と同ドキュメントは案内しています。

Apple Silicon対応のADRから読み取れるメモリ設計

リポジトリの arch/decisions/ には設計判断記録（ADR）が置かれています。中でも arch/decisions/APPLE-SILICON-SUPPORT.md（Status: proposed、Date: 2026-04-23）は、GPU メモリをどう扱うかという判断が言語化されており、採用検討時に読む価値の高い文書です。

同 ADR に記載されている主な決定事項は次のとおりです。

• Apple Silicon（darwin/arm64）を第一級プラットフォームとして扱い、Intel macOS・ユニバーサルバイナリ・Rosetta フォールバックはスコープ外とする
• モデルの重みは拡張コードと分離し、ノード単位でインストールする
• Mac 上のワークフローは逐次実行とし、メモリ予算を制御する。重い生成ステージは同時に 1 つだけ常駐させる
• ダウンロードやインストールの状態は観測可能かつ再開可能でなければならない
• GPU メモリの解放は、所有プロセスの終了によって行う

背景として ADR が挙げているのは、ユニファイドメモリのため重い GPU ステージが重なると 16 GB クラスのマシンでは全体が不安定になること、Metal / MPS のメモリは Python 側のクリーンアップだけでは確実に返らずプロセス終了が信頼できる解放境界になること、大きなモデルのダウンロードにはバイト単位の可視性・停滞検知・レジューム挙動が必要になること、そして 1 つの拡張が重みや既定値の異なる複数バリアントを公開するため拡張マニフェストにノード単位の配布メタデータが必要になることです。

「プロセス終了を GPU メモリの解放境界として設計する」という判断は、ローカル推論アプリを自作あるいは評価する立場から見ると示唆的です。同時実行数を絞る前提のアプリなので、複数ジョブを並列に流すバッチ処理を期待している場合は、この設計方針との相性を先に確認しておく必要があります。

拡張機能でモデルを差し替える仕組み｜manifest.jsonの構造

Modly の中核は、生成モデルを本体から切り離し「拡張」として着脱できるようにした点にあります。README によれば、拡張は Models ページの「Install from GitHub」に拡張リポジトリの HTTPS URL を入力してインストールし、モデルノードを持つ拡張であればモデル（またはバリアント）がダウンロードされます。

manifest.jsonが宣言していること

拡張の実体は manifest.json と、種別に応じたランタイムのエントリファイルを含む GitHub リポジトリです。この manifest.json は単なる識別情報ではなく、モデルの配布元と UI に表示するパラメータのスキーマまでを宣言しています。公式拡張の 1 つである modly-triposg-extension の manifest.json から冒頭部分を引用します。

{
  "id": "triposg",
  "name": "TripoSG",
  "source": "https://github.com/lightningpixel/modly-triposg-extension",
  "description": "High-quality image-to-3D via flow matching diffusion. Sharper geometry and finer details than TripoSR. Requires ~8GB VRAM.",
  "version": "1.0.1",
  "author": "Lightning Pixel",
  "generator_class": "TripoSGGenerator",
  "tags": ["image-to-3d", "high-quality", "diffusion"],
  "nodes": [
    {
      "id": "generate",
      "name": "TripoSG",
      "input": "image",
      "output": "mesh",
      "hf_repo": "VAST-AI/TripoSG",
      "download_check": "model_index.json",
      "params_schema": [
        {
          "id": "num_inference_steps",
          "label": "Inference Steps",
          "type": "int",
          "default": 50,
          "min": 8,
          "max": 50,
          "tooltip": "Number of diffusion steps. More steps = better quality but slower."
        },

出典: modly-triposg-extension の manifest.json

読み取れる要素を整理すると次のようになります。

• generator_class: 実行時に呼び出す生成クラス名。ランタイム側の実装との接続点
• nodes[].input / nodes[].output: ノードが受け取る型（image）と返す型（mesh）。ワークフローグラフ上での配線可否を決める情報
• hf_repo: 重みの取得元（ここでは Hugging Face の VAST-AI/TripoSG）
• download_check: ダウンロード完了を判定するためのファイル名
• params_schema[]: UI に表示するパラメータの定義。id・ラベル・型・既定値・範囲・ツールチップまでが宣言的に記述される

つまり拡張側は「どのモデルを、どこから取得し、どんなパラメータで公開するか」を JSON で宣言するだけで、本体の UI にパラメータフォームが生成される構造になっています。TripoSG 拡張では Inference Steps（既定 50、範囲 8〜50）、CFG Scale（既定 7.0、範囲 0.0〜20.0）、Foreground Ratio（既定 0.85）、Max Faces（既定 -1 で無効）、Seed、Decoder（DiffDMC / Marching Cubes の選択）が定義されています。新しいモデルを追加したい場合に、本体を改造せず拡張リポジトリだけで完結できる点が設計上の要になっています。

公式拡張5種とVRAMの目安

README には公式拡張として次の 5 つが挙げられています。実務上重要なのは、必要 VRAM の目安が本体 README や公式サイトのシステム要件ではなく、各拡張の manifest.json の description に書かれているという点です。初見では気づきにくい情報の置き場所なので、GPU 選定を検討する場合は各拡張リポジトリを直接確認する必要があります。

デフォルトの TripoSR（約 2.4 GB）から始めて、品質を上げたい場合に TripoSG や Trellis2 へ移行するという段階的な検証が可能な構成です。逆に言えば、手元の GPU の VRAM 容量によって選べる拡張が限られるため、「Modly が動くか」ではなく「どの拡張まで動かせるか」で環境要件を考える方が実態に近くなります。

CLIとMCPサーバーによるModlyの自動化

ここまで見てきた「バックエンドが HTTP で分離されている」という設計は、自動化インタフェースの形にそのまま現れています。Modly を単発の生成ツールと見るか、パイプラインの部品と見るかを分ける材料がこの領域です。

JSON優先のCLI契約

リポジトリには tools/modly-cli/agent.py という CLI が同梱されています。位置づけは tools/modly-cli/SKILL.md に明記されており、起動中の Modly デスクトップアプリを UI を介さず呼び出すための、標準ライブラリのみで動くエージェント向けヘルパーです。正規（canonical）コマンドは health / model / workflow-run / capability / process-run の 5 つで、最終的な機械可読 JSON は stdout に、進捗の JSON 行は stderr に出力されます。

python tools/modly-cli/agent.py generate \
  --image ./input.png \
  --output ./export.glb \
  --progress

出典: tools/modly-cli/SKILL.md

この generate について SKILL.md は、POST /workflow-runs/from-image と GET /workflow-runs/{run_id} のラッパーであり、旧来の /generate/* へ暗黙にフォールバックしないと明記しています。返却される JSON には、後から状態確認やキャンセルを行うためのメタデータが含まれます。

{
  "ok": true,
  "run": {"kind": "workflowRun", "id": "..."},
  "workspace_path": "Default/model.glb",
  "export_path": "/absolute/path/to/export.glb",
  "meta": {
    "status_command": "python tools/modly-cli/agent.py workflow-run status ...",
    "cancel_command": "python tools/modly-cli/agent.py workflow-run cancel ...",
    "legacy": false
  }
}

出典: tools/modly-cli/SKILL.md

レスポンスに「次に叩くべきコマンド文字列」自体を含めるのは、呼び出し側がエージェントであることを前提にした設計です。同様に、アプリに到達できない場合は {"ok": false, "code": "API_UNAVAILABLE", ...} という構造化エラーを返し、サーバー側が正規の契約を公開していない場合は UNSUPPORTED_PROCESS として fail closed する、と SKILL.md は説明しています。曖昧に成功したように見せず、機械が分岐できる形で失敗させる方針です。

モデル指定も同じ思想で貫かれています。--model auto は /model/status が報告するアクティブモデルを使い、その ID を /model/all に対して検証します。SKILL.md は「モデル名・ラベル・文字列の断片から隠れた能力を推測しない」と明示しており、名前のパターンマッチで挙動を変えるような実装を避けていることが読み取れます。

互換性・補助的な機能は正規コマンドから明確に隔離されています。旧 /generate/* 系は legacy サブコマンド（レスポンスに meta.legacy: true が付く）、FastAPI バックエンドのみを起動する dev serve-api / dev ensure-server（Electron ブリッジの準備完了は保証しないと明記）、外部 ComfyUI との連携は experimental comfy-image / experimental generate-from-workflow、といった具合です。「どこまでが公式に保証された契約なのか」がドキュメント上で線引きされているため、自動化を組む側は依存してよい範囲を判断しやすくなっています。

MCPサーバーで外部エージェントに公開されるツール

もう 1 つの自動化経路が MCP サーバーです。api/mcp_server.py の冒頭には「Exposes Modly's capabilities as MCP tools for external agents (Claude Desktop, Codex CLI, etc.).」と記されており、外部の AI エージェントから Modly の機能を呼び出すことを意図した実装であることがわかります。同ファイルのヘッダには設定例も併記されています。

  {
    "mcpServers": {
      "modly": {
        "command": "python",
        "args": ["C:/path/to/modly/desktop/api/mcp_server.py"]
      }
    }
  }

出典: api/mcp_server.py

同ヘッダには、FastAPI バックエンドが http://localhost:8765 で稼働していることが前提であるとも書かれています。実装は mcp.server.Server と stdio_server を使い、HTTP クライアントには httpx を用いる構成です。公開されているツールには、利用可能な 3D 生成モデルを列挙する modly_list_models、model_id を指定してアクティブモデルを切り替える modly_switch_model、画像ファイルのパスから 3D メッシュ生成を開始し job_id を返す modly_generate_from_image が含まれます。

CLI と MCP という 2 つの経路が用意されていることは、Modly を「人が GUI で操作するアプリ」だけでなく「他のプログラムやエージェントが呼び出すサービス」として位置づけられることを意味します。既存のアセット制作パイプラインに組み込む余地があるかを検討する際は、この 2 つのドキュメントが最初に読むべき一次情報になります。

導入前に確認したいModlyのライセンス積層構造

ここが本記事で最も強調したい論点です。Modly は無料で使えるオープンソースですが、それは「生成した 3D モデルを自由に商用利用できる」ことを意味しません。Modly を使う場合、ライセンスは少なくとも 3 つの層に分かれて存在します。

本体はMITだがGitHubの判定はNOASSERTION

前述のとおり、GitHub API が返す Modly のライセンスは NOASSERTION、つまり自動判定では特定できない状態です。一方で公式サイトは「MIT ライセンス」と表記しており、LICENSE ファイルの本文も標準的な MIT License（Copyright (c) 2026 Lightning Pixel）です。両者が食い違って見える理由は、MIT の本文の後ろに追加の条項が置かれているためです。

If you fork this project and build your own application from it, you must
credit the original project and its creator in your app's UI or documentation:

    Based on Modly (https://github.com/lightningpixel/modly)
    by Lightning Pixel (https://github.com/lightningpixel)

出典: LICENSE

標準テキストからの逸脱があるため GitHub のライセンス検出は NOASSERTION を返す一方、実体は「MIT + フォークして自作アプリを作る場合の帰属表示要件」という構造になっています。Modly をそのまま使うだけであれば MIT の範囲で考えられますが、フォークして自社プロダクトに仕立てる想定がある場合は、UI もしくはドキュメントへのクレジット表示が運用要件として発生します。ここは法務確認の対象に含めておくべき箇所です。

なお、公式拡張リポジトリ側はさらに注意が必要です。確認した範囲では、公式拡張リポジトリはライセンスファイルを持たず、GitHub 上のライセンス判定も未設定（null）でした。拡張コードそのものを改変・再配布する計画がある場合は、条件が明示されていない状態であることを前提に、リポジトリ作者への確認を含めた判断が要ります。

商用可否はどのモデル拡張を選んだかで決まる

3 層目がモデルの重みです。Modly は複数のモデルを拡張として読み込む構造のため、生成物に適用される条件は「Modly のライセンス」ではなく「そのとき使ったモデルのライセンス」に従います。日本語の紹介記事でも、Modly が単体ツールではなく複数の 3D 生成 AI を読み込むラッパーであり、選んだモデルによって生成結果とライセンス条件が変わる点が指摘されています（MODELING HAPPY の紹介記事）。

Hunyuan3D 2 系の制約については、リポジトリの Issue でも商用利用の可否が繰り返し議論されています（Issue #254、Issue #6）。ライセンス比較をまとめた解説記事も存在しますが（triposr.org の比較記事）、これらは一次情報ではありません。実務で使う場合は、各提供元のリポジトリの LICENSE と Hugging Face のモデルカードを直接確認することを前提にしてください。

判断の順序としては、次のように考えると整理しやすくなります。

1. その案件で生成物を商用利用するのか、社内検証にとどめるのかを確定する
2. 商用利用するなら、条件の明快なモデル（MIT 系）に絞って拡張を選ぶ
3. Hunyuan3D 系を使いたい場合は、対象地域・利用規模・出力の二次利用方針を含めて法務確認を通す
4. Modly をフォークして自社アプリ化する計画があるなら、本体 LICENSE の帰属条項と、拡張リポジトリのライセンス未設定を別途確認する

「Modly は無料の OSS だから安心」で止まらず、モデル単位まで降りて確認できるかどうかが、この種のツールを業務に持ち込むときの分かれ目になります。

類似OSSとの違い｜ComfyUI-3D-Pack・TRELLIS・Hunyuan3D-2との比較

「Modly と ComfyUI はどちらがいいのか」という比較のされ方をよく見かけますが、両者は同じ土俵に乗っていません。比較する際はレイヤーの違いを先に押さえると判断が早くなります。数値はいずれも 2026 年 8 月 29 日時点の GitHub API 取得値です。

3つのレイヤーで整理する

構造としては、モデル本体（TRELLIS / Hunyuan3D-2 / TripoSG）→ ノード基盤（ComfyUI + 3D-Pack）→ 完結型デスクトップアプリ（Modly） という積み上げになります。Modly は最上位のアプリ層に位置し、下の層を拡張として取り込むことで、モデルの入手から生成・エクスポートまでを 1 つの GUI に閉じているという整理ができます。

用途別の選び分け

レイヤーの違いを踏まえると、選択の目安は次のように置けます。

• モデルを細かく比較検証したい／既存の画像生成ワークフローと組み合わせたい: ComfyUI + ComfyUI-3D-Pack。ノードの自由度とエコシステムの広さが利点ですが、環境構築コストとライセンス（ComfyUI 本体は GPL-3.0）を前提に判断が必要です
• 論文の手法を再現したい／モデルそのものを改造したい: TRELLIS や Hunyuan3D-2 の本体リポジトリ。GUI やエクスポート整備は自前で用意することになります
• 非エンジニアを含むチームで、ラフな 3D アセットを短いサイクルで量産したい: Modly。インストーラ配布・モデル自動ダウンロード・GUI 上のワークフロー編集が揃っており、導入の摩擦が小さい構成です。加えて CLI と MCP があるため、後から自動化に寄せる余地も残ります

「Modly か ComfyUI か」ではなく、「アプリ層の完結性を優先するか、ノード基盤の自由度を優先するか」という問いに置き換えると、要件との照合がしやすくなります。

Modly採用前に確認したいメンテナンス状況と成熟度

最後に、継続的に使えるプロジェクトかどうかの判断材料を整理します。ここは評価ではなく事実の提示にとどめ、判断は読者の要件に委ねます。

リリース頻度とコントリビュータ構成

Modly のリポジトリ作成日は 2026 年 3 月 17 日です。そこから約 5 か月でスター 7,308・フォーク 690 に達しており、伸びは速いと言えます。Releases ページを見ると、v0.3.5（2026-05-08）、v0.3.6（2026-05-11）、v0.4.0（2026-06-21）、v0.4.1（2026-07-16）、v0.4.2（2026-08-28）と、おおむね 1〜2 か月間隔でリリースが続いています。最終 push も 2026 年 8 月 28 日で、開発は止まっていません。

一方で、採用判断において重く見るべき事実が 2 つあります。

1. すべてのリリースが「Beta」表記の 0.x 系であること。API・拡張仕様が今後変わる可能性を前提に置く必要があります
2. コントリビューションが特定個人に集中していること。GitHub API で取得できる上位コントリビュータは lightningpixel が 333、次点が 26、その次が 19 という分布で、作者 1 名が全体の大半を占めます

後者はいわゆる bus factor の論点です。オープン Issue は 62 件あり、Discord コミュニティも運営されていますが、開発の継続性が実質的に 1 名に依存している構造は変わりません。社内の基幹的なパイプラインに組み込む場合は、フォークして自社で保守できる体制まで想定しておくか、あるいは代替手段を確保したうえで採用するかの判断が必要になります。逆に、検証用途やアセットの下ごしらえのような「止まっても業務が止まらない」位置づけであれば、このリスクは受け入れやすいものです。

環境依存の落とし穴

もう 1 つ、判断材料として有用なのが docs/running-on-jetson.md です。このドキュメントは「Running Modly headless on an NVIDIA Jetson (AGX Orin, JetPack 6)」と題され、冒頭で Modly が公式にターゲットしていないプラットフォームであることが明記されています。

技術的に興味深いのは、FastAPI バックエンドが完全にスタンドアロンかつ HTTP 駆動であるため、Electron もディスプレイも GUI も不要で、バックエンドだけを動かして curl から駆動できる、と説明されている点です。冒頭のアーキテクチャで触れた疎結合の設計が、GUI を持たない運用形態にまで波及していることの一次情報にあたります。

同時に、このドキュメントは既知の要対応事項を 3 点挙げており、環境依存の落とし穴が実在することも示しています。

1. ピン留めされた torch 2.5.1+cu124 の SBSA ホイールに sm_87 カーネルが含まれていないため、jetson-ai-lab のビルドに差し替える必要がある
2. Jetson 版 torch が NumPy 1.x 向けにビルドされているため、numpy < 2 にピン留めする必要がある
3. ONNX Runtime が Tegra CPU 上でクラッシュするため、rembg による背景除去を NumPy / SciPy 実装に置き換える必要がある

これらは非公式プラットフォーム固有の話ではありますが、「GPU アーキテクチャ・PyTorch のホイール・NumPy のメジャーバージョン・ONNX Runtime」という、ローカル推論アプリでつまずきやすい箇所が一通り並んでいます。標準的な NVIDIA GPU 環境や Apple Silicon であれば公式インストーラで完結する想定ですが、変則的な環境で動かす計画がある場合は、この種の調整が発生し得ることを見込んでおくのが現実的です。

まとめ｜Modlyが向いているケースと確認すべき論点

Modly は、画像やプロンプトから 3D メッシュをローカル生成する OSS デスクトップアプリです。モデル本体ではなくアプリ層に位置し、モデルの入手・切り替え・生成・エクスポートを 1 つに束ねている点が、モデル本体リポジトリや ComfyUI 系との最大の違いでした。

向いていると考えられるケースは次のとおりです。

• 素材を外部に送らず、ローカル完結でラフな 3D アセットを短いサイクルで用意したい
• 複数の生成モデルを拡張として並べ、切り替えながら比較したい
• CLI や MCP サーバー経由で、既存の制作パイプラインや AI エージェントから呼び出したい

着手前に確認しておくべき論点も、判断の順に整理しておきます。

• ライセンス: Modly 本体は MIT + 帰属条項（GitHub 判定は NOASSERTION）。公式拡張はライセンス未設定。生成物の商用可否は、選んだモデル拡張のライセンスに従う
• 必要 VRAM: 本体 README や公式サイトではなく、各拡張の manifest.json の description に記載されている（TripoSG は約 8 GB、Trellis2 GGUF は約 6〜10 GB）
• 成熟度と体制: 全リリースが Beta 表記の 0.x 系で、コントリビューションは作者 1 名に集中している
• プラットフォーム: README は Windows / Linux / Apple Silicon macOS を挙げるが、公式サイトのシステム要件は NVIDIA GPU と記載。利用予定の環境で改めて確認する

本記事はドキュメントと公開情報のみに基づく整理であり、生成品質や実効性能は扱っていません。採用を具体的に検討する段階では、上記の論点を確認したうえで、対象案件の要件に合わせた検証を行うことをおすすめします。

関連情報

ローカル推論を前提としたツールの選定や、生成 AI を組み込んだ制作パイプラインの設計をご検討中の方は、お問い合わせフォーム からご相談いただけます。要件の整理段階からのご相談にも対応しています。

出典・参考リンク

Modly の一次情報

• lightningpixel/modly（GitHub リポジトリ）
• Modly 公式サイト（modly3d.app）
• api/README.md（FastAPI バックエンド）
• arch/decisions/APPLE-SILICON-SUPPORT.md（ADR）
• tools/modly-cli/SKILL.md（CLI 仕様）
• api/mcp_server.py（MCP サーバー）
• LICENSE
• docs/running-on-jetson.md
• Releases ページ
• modly-triposg-extension（公式拡張）

類似 OSS・モデル提供元

• MrForExample/ComfyUI-3D-Pack
• comfyanonymous/ComfyUI
• microsoft/TRELLIS
• Tencent-Hunyuan/Hunyuan3D-2
• VAST-AI-Research/TripoSG

ライセンス制約に関する参考情報（二次情報）

• Hunyuan3D-2 Issue #254（商用利用の可否）
• Hunyuan3D-2 Issue #6（商用ライセンス）
• Hunyuan3D / TRELLIS / TripoSR のライセンス比較

日本語での紹介記事

• MODELING HAPPY「画像1枚から3Dモデル生成！ローカルで動く無料AIツール「Modly」ただし商用利用は注…