エージェントが2つのHugging Face Spaceを連鎖させて3Dのパリ美術館を構築した方法
コーディングエージェントが Hugging Face の Spaces を連携させることで、画像生成や 3D 再構築ツールを直接操作せずとも、パリのパノラマを 3D ガウススプラット形式で構築するウェブサイトを自動生成した事例が示された。
キーポイント
エージェントによる自動化ワークフロー
ユーザーは画像生成や 3D ツールの操作を行わず、コーディングエージェントに指示を与えるだけで、必要なアセット(画像と 3D スプラット)を自動生成・連携させるプロセスが実現された。
Hugging Face Spaces の相互運用性
異なる機能を持つ 2 つの Hugging Face Spaces を「チェーン」して組み合わせることで、複雑なマルチモーダルコンテンツ(3D ガウススプラット)を構築する仕組みが実証された。
マルチメディア制作のパラダイムシフト
従来の専門ツールを手動で繋ぐ手法から、エージェントがスペースをブロックとして認識し、自動的に組み上げてコンテンツを作成する「ビルディングブロック経済」への移行を示唆している。
マルチメディアソフトウェアの構築パラダイムシフト
AI はゼロから全てを構築するよりも、既存の証明されたコンポーネント(モデルやスペース)をつなぎ合わせることに優れており、これが今後のソフトウェア開発の主流となる。
agents.md によるエージェント統合の自動化
Hugging Face Spaces は標準的な `agents.md` ファイルを公開しており、これによりエージェントは SDK の記述やハードコードなしで API スキーマ、呼び出し方法、認証情報を自動的に取得して空間を駆動できる。
スペースの連鎖による複雑なパイプラインの実現
あるスペースの出力(例:画像)を次のスペースの入力(例:3D 再構築)として繋ぐことで、プロンプトから最終的な 3D アセットまでを一連のエージェント処理で完結させることが可能になる。
エージェントによる自動化と適応
エージェントは画像の向き修正、ファイル圧縮、UI実装などの「接着作業」を自動で行い、トリックや品質の問題(例:ガラスピラミッドのスプラッティング不良)に対して即座に反応して改善を行いました。
影響分析・編集コメントを表示
影響分析
この記事は、AI エージェントが単なるコード生成を超え、既存の AI モデルやツールを自律的に組み合わせる「オーケストレーター」として機能する可能性を示す重要なマイルストーンです。これにより、3D コンテンツ制作のような専門的な領域でも、ハードルが劇的に下がり、開発サイクルが大幅に短縮される未来が現実味を帯びてきました。
編集コメント
専門的な 3D ツールを直接扱わずに高品質な成果物を生み出す事例は、AI エージェントの実用化における決定的な転換点と言えます。開発者の役割が「ツールの操作」から「エージェントへの指示と検証」へとシフトする兆候です。
- マルチメディアにおけるブロック経済の到来
- agents.md">すべての Space は、agents.md を通じてブロックとなる
- 具体的な事例:パリ記念碑 → スプラット
- なぜこれが重要なのか
- あなたも試してみよう
*エージェントが 2 つの Hugging Face Space を連携させることで、3D パリ美術館を構築しました。*
私はコーディングエージェントに、パリの記念碑を 3D ガウススプラットとして紹介する美しいウェブサイトを構築するように依頼しました。画像生成ツールを開いたことはありませんし、3D 再構成ツールに触れたこともありません。エージェントは、2 つの Hugging Face Space を直接呼び出すことですべてのアセット(画像および3D スプラット)を生成し、それらをシネマティックなビューアーに接続しました。
こちらがその結果です。静的な Space としてライブ公開されています:
この投稿では、それがどのように可能になったのか、そしてなぜこれが今後のマルチメディアソフトウェアの構築方法の予兆だと私が考えるのかについて解説します。
マルチメディアにおけるブロック経済の到来
ミッチェル・ハシモットは最近、彼が「ブロック経済」と呼ぶ転換点を記述しました。ソフトウェアへの最も効果的な道筋はもはや磨き上げられたモノリスではなく、他者(ますます*エージェント*によって)が組み立てられるよう、小型で文書化されたコンポーネントであるというものです。
彼の重要な観察点は以下の通りです。AI はゼロからすべてを構築する点では問題ありませんが、実証済みの部品をつなぎ合わせることにおいては非常に優れています。
その論文の多くはコードライブラリを通じて語られてきました。しかし、同じ力がマルチメディア AI にも押し寄せています。最先端の画像モデル、動画モデル、TTS モデル、3D 再構築モデルを使用する際の難しさは、モデル自体にあるのではなく、統合にあります:SDK、重み(weights)、GPU、入力フォーマット、ポーリングです。もし各モデルが文書化され、呼び出し可能なブロックであったなら、エージェントは npm パッケージを結合するようにそれらを接着できます。
まさにそれが、Hugging Face Spaces が静かに成し遂げたことです。
エージェント.md を通じて、すべての Space がビルディングブロックとなる
The Hub は数千の最先端モデル(その多くがオープンウェイト)をホストしており、ほとんどが対話型の Spaces としてデプロイされています。現在では、すべての Gradio Space は、エージェントに対して呼び出し方を正確に示すプレーンテキストの agents.md を公開しています。
curl https://huggingface.co/spaces/VAST-AI/TripoSplat/agents.md
は必要なすべてを一度に返します:スキーマ URL、呼び出しおよびポーリングテンプレート、ファイルのアップロード方法、そして認証ヒントです。
API スキーマ: GET .../gradio_api/info
呼び出しエンドポイント: POST .../gradio_api/call/v2/{endpoint} {"param_name": value, ...}
ポーリング結果: GET .../gradio_api/call/{endpoint}/{event_id}
ファイル入力: POST .../gradio_api/upload -F "files=@file.ext"
認証: Bearer $HF_TOKEN
クライアントライブラリも不要、ハードコードされた統合も不要。エージェントはこれを読み取り、Space をエンドツーエンドで駆動できます。
HF_TOKEN を設定すれば、あとは進むだけです。
真の鍵となるのはチェーン化です:ある Space の出力が次の Space の入力となります。プロンプト → 画像 → 3D。これがこのギャラリーを支える全体のパイプラインです。
具体的な例:パリ記念碑 → スプラット
エージェントは 2 つの Space を連鎖させました:
- Image:
ideogram-ai/ideogram4が各記念碑を、クリーンで黒背景の「標本」ショットに変換しました(エッフェル塔は台座の上にある小さなジオラマとして)。プロンプトを入力し、画像を出力します。
- Splat:
VAST-AI/TripoSplatが各単一画像から 3D ガウシアン スプラット (.ply) を再構築しました。画像を入力し、3D を出力します。
生成された画像
再構築されたスプラット
エージェントが生成した 6 つのソース画像はすべて黒背景に切り抜かれ、単一画像からの 3D 再構築の準備ができています:
そこから、エージェントは「つなぎ合わせ」作業も担当しました。TripoSplat の出力が Y 軸下向きで反転していることに気づき、それを正しく立て直しました。各記念碑を自動的にフレームに収め、.ply ファイルを .ksplat に圧縮して(約 3 分の 1 のサイズになり、高速読み込みが可能)、スクロールで切り替え、ドラッグで回転できる UI を備えた Three.js ビューアを構築し、全体を静的な Space としてデプロイしました。人間が行った入力は味覚レベルのものだけでした:「ズームアウトして」「オベリスクをスプラットに適した別のものに置き換えて」「トランジションが長すぎる」などです。
これらのステップのいくつかは、エージェントが現実に反応するものでした。広いガラス製のピラミッドが不恰好に崩れ落ち、細いオベリスクは鈍く見える。単一視点からの再構築では背面を推測することになります。これはまさに、「アウトソーシングされた R&D(研究開発)と高速な反復」というループであり、ビルディングブロック経済が予測するものそのものです。ただし、この場合の R&D は会話という形をとっていました。
なぜこれが重要なのか
- モデルがコンポーザブルになります。異なる組織から提供される SOTA(State-of-the-Art:最先端)のスプラットモデルと画像モデルを、統合コードゼロで連鎖させることができます。ハブのオープンウェイトカタログは、呼び出し可能なマルチメディアプリミティブのライブラリへと変貌します。
- エージェントは、文書化されておりアクセスしやすいものを好みます。agents.md を持つことで Space が極めて容易にアクセス可能となり、エージェントは手動でセットアップが必要なモデルよりも、その Space を選択するようになります。これは Hashimoto 氏がオープンソースライブラリに対して指摘したのと同じダイナミクスです。
- 障壁であったのは統合であり、それはほぼ消滅しました。「プロンプトを回転する 3D モニュメントに変換する」という行為は、かつてはプロジェクトそのものでしたが、ここではパイプライン内の一つのステップに過ぎません。
実際に試してみましょう
ご自身のエージェントを Space の agents.md に指向させ、実行させてみてください:
image generation
curl https://huggingface.co/spaces/ideogram-ai/ideogram4/agents.md
single-image to 3D gaussian splat
curl https://huggingface.co/spaces/VAST-AI/TripoSplat/agents.md
いずれかのリンクをコーディングエージェント(Claude Code など)に貼り付け、HF_TOKEN を設定して何か構築するように指示してください。このギャラリーのための完全かつ再現可能なパイプライン、そしてそれら 2 つの agents.md エンドポイントにアクセスするスクリプトは、Space リポジトリ にあります。
ビルディングブロックはすでに Hub のそこにあります。エージェントは既に接着する方法を知っています。
原文を表示
- The building-block economy comes for multimedia
- agents.md">Every Space is a building block, via agents.md
- The worked example: Paris monuments → splats
- Why this matters
- Try it yourself
*An agent built a 3D Paris gallery from two Hugging Face Spaces.*
I asked a coding agent to build a beautiful website showcasing the monuments of
Paris as 3D Gaussian splats. I never opened an image generator. I never touched a
3D reconstruction tool. The agent produced every asset (the images and the 3D
splats) by calling two Hugging Face Spaces directly, then wired them into a
cinematic viewer.
Here's the result, live as a static Space:
This post is about *how* that's possible now, and why I think it's a preview of
how a lot of multimedia software gets built from here on.
The building-block economy comes for multimedia
Mitchell Hashimoto recently described a shift he calls the
the most effective path to software is no longer a polished monolith, but small,
well-documented components that others (increasingly *agents*) can assemble.
His key observation: AI is okay at building everything from scratch, but it is
really good at gluing together proven pieces.
That thesis has mostly been told with *code* libraries. But the same forces are
hitting multimedia AI. The hard part of using a state-of-the-art image model,
a video model, a TTS model, or a 3D reconstruction model was never the model. It
was the integration: SDKs, weights, GPUs, input formats, polling. If each model
were instead a documented, callable block, an agent could glue them together the
same way it globs together npm packages.
That's exactly what Hugging Face Spaces have quietly become.
Every Space is a building block, via agents.md
The Hub hosts thousands of state-of-the-art models (a huge share of them
open-weights), and most are deployed as interactive Spaces. As of now,
every Gradio Space also exposes a plain-text
agents.md that tells an agent
*exactly* how to call it:
curl https://huggingface.co/spaces/VAST-AI/TripoSplat/agents.md
returns everything needed in one shot: the schema URL, the call and poll templates,
how to upload files, and the auth hint:
API schema: GET .../gradio_api/info
Call endpoint: POST .../gradio_api/call/v2/{endpoint} {"param_name": value, ...}
Poll result: GET .../gradio_api/call/{endpoint}/{event_id}
File inputs: POST .../gradio_api/upload -F "files=@file.ext"
Auth: Bearer $HF_TOKEN
No client library. No hardcoded integration. An agent reads that, and it can drive
the Space end to end. Set an HF_TOKEN
and you're going.
The real unlock is chaining: the output of one Space becomes the input to the
next. Prompt → image → 3D. That's the whole pipeline behind this gallery.
The worked example: Paris monuments → splats
The agent chained two Spaces:
- Image: ideogram-ai/ideogram4 turned each monument into a clean,
dark-background "specimen" shot (and the Eiffel Tower into a little diorama on a
plinth). Prompt in, image out.
- Splat: VAST-AI/TripoSplat
reconstructed a 3D Gaussian splat (.ply) from each single image. Image in,
3D out.
Generated image
Reconstructed splat
The six source images the agent generated, all isolated on black, ready for
single-image 3D reconstruction:
From there the agent did the "glue" work too. It noticed TripoSplat outputs are
Y-down and flipped them upright, auto-framed each monument, compressed the .ply
files to .ksplat (~3× smaller, so they load fast), built a Three.js viewer with a
scroll-to-switch and drag-to-rotate UI, and deployed the whole thing as a static
Space. The only human inputs were taste-level: "make it zoomed out," "replace the
obelisk with something better for splatting," "the transition lingers too long."
Several of those steps were the agent reacting to reality. A wide glass pyramid
splats poorly. A thin obelisk is dull. A single-view reconstruction infers the
back. That is exactly the "outsourced R&D, fast iteration" loop the building-block
economy predicts, except the R&D was a conversation.
Why this matters
- Models become composable. A SOTA splat model and a SOTA image model, from
different orgs, chained with zero integration code. The Hub's open-weights
catalog turns into a library of callable multimedia primitives.
- Agents prefer what's documented and reachable. agents.md makes a Space
trivially reachable, so an agent will pick it over a model it has to set up by
hand. That is the same dynamic Hashimoto flags for open-source libraries.
- The barrier was integration, and it's largely gone. "Turn a prompt into a
rotating 3D monument" used to be a project. Here it was a step in a pipeline.
Try it yourself
Point your own agent at a Space's agents.md and let it cook:
# image generation
curl https://huggingface.co/spaces/ideogram-ai/ideogram4/agents.md
# single-image to 3D gaussian splat
curl https://huggingface.co/spaces/VAST-AI/TripoSplat/agents.md
Paste either link into your coding agent (Claude Code, etc.), set your
HF_TOKEN, and ask it to build something. The full, reproducible pipeline for this
gallery, the scripts that hit those two agents.md endpoints, lives in the
The building blocks are sitting right there on the Hub. The agents already know how
to glue.
関連記事
Cloudflare が公開トラフィックをプライベートアプリケーションへルーティングする機能を発表
Cloudflare は、従来の CDN や WAF で保護される公開アプリと、VPN やファイアウォールで守られる内部 API・AI エージェントバックエンドなどの境界を撤廃し、両者を統合して管理する新機能を提供すると発表した。
エージェントハッチは自己修復するべきである(8 分読了)
TLDR AI は、AI エージェントが自身の不具合を検知し、自動的に修正・修復を行う仕組みの重要性について論じている。
エージェントシステムにおける意図と実行の架橋
Amazon Science は、AI エージェントのパフォーマンスはモデル自体の問題ではなく、LLM とツール間の仲介役となるハッチ(OS)の設計がボトルネックであると指摘し、意図を実行に移すシステムの重要性を強調した。
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み