歴史写真からインタラクティブ3Dへ：Gemini 4 Carbon がひとつのプロンプトでエッフェル塔の建設過程を再現

著者メモ：本記事では、GoogleのエッフェルTowerデモを出発点に、複数のAgentが歴史的な写真や工学資料をどのように組み合わせてインタラクティブな3D展示にするのかを解説します。

用語クイックガイド（to know）

• Agent（エージェント）：ツールを呼び出してタスクを実行できるAIプログラムです。質問に答えるだけでなく、計画・実行・結果の確認まで行います。
• マルチAgent連携：複数のエージェントがサブタスクを分担し、それぞれの中間結果をやり取りしながら進める方式です。
• Antigravity：Googleが提供するAI開発ツールで、Gemini 4 Carbonがすでに利用可能になっています。
• Swarm（/swarm）：Antigravityで複数のエージェントを連携させるプレビュー機能で、2026年11月10日に公開されました。
• 工学図面：設計を図形や寸法で表した資料で、3D再構築における重要なジオメトリの情報源です。
• Three.js：Webページ上で3Dシーンを構築できるJavaScriptライブラリです。ブラウザ上で直接レンダリングやインタラクションができます。
• 格子構造（ラティス構造）：多数の部材を組み合わせた構造で、エッフェル塔は鉄製の格子構造の代表例です。

Googleは2026年11月10日にGemini 4 Carbonを正式公開し、公式発表のなかで非常に絵になる事例を紹介しました。複数のCarbon Agentが、Antigravityの/swarm機能を使って歴史的な写真や工学図面をインタラクティブなThree.js製3D展示に変換し、1887〜1889年のエッフェル塔建設の過程を再現したというものです。このタスク全体は、たった1つのプロンプトで開始されています。

これは「AIが適当にエッフェル塔を描いた」という話ではありません。 この事例とSwarmの仕組みについては、Googleの公式発表とAntigravityのブログで説明されています。本記事では、情報を次の3種類に分けて扱います。歴史的事実、Google公式デモでの説明、そして私たちの分析・推測です。

この記事で得られること：このデモがどんな技術的課題を解決しているのか、マルチAgentがそこでどんな役割を果たしているのか、そして開発者がAPIを使って似たような「図面から3Dへ」のワークフローを試すにはどうすればよいのかが分かります。

Gemini 4 Carbon エッフェル塔デモのポイントまとめ

まずは、Google の公式発表で確認できる情報を整理します。下の表には、公式が明確に言及している内容だけを載せています。公開されていない詳細については、別途触れます。

ここで注意したいのは、「1 つのプロンプト」が「1 回の生成」を意味するわけではない、という点です。ユーザーが指示を出すのは一度だけですが、その後のタスク分解、並列処理、チェックは、Swarm フレームワークの中で複数の Agent が行います。この前提を押さえておくと、今回の事例が理解しやすくなります。

エッフェル塔が Gemini 4 Carbon の高難度テーマである理由

単に「エッフェル塔っぽいモデル」を生成するだけなら、このデモはそれほど珍しいものではありません。本当の難しさは、エッフェル塔そのものが、膨大な資料に裏打ちされた複雑な構造物であることにあります。以下のデータは、エッフェル塔公式サイトの歴史アーカイブによるものです。

施工のタイムラインも明確に残っています。1887 年 1 月 26 日に正式に着工し、同年 7 月 1 日から塔脚の組み立てが始まりました。1888 年 4 月 1 日に 1 階部分が完成し、8 月 14 日に 2 階部分が完成。そして 1889 年 3 月 31 日に、塔の頂上部分と全体の組み立てが完了しています。「建設過程を再現する」展示にとって、これらの節目はそのまま時間軸の骨格になります。

エッフェル塔の格子構造と耐風設計

公式の歴史資料によると、塔の設計構想は、もともと技術者の Maurice Koechlin と Émile Nouguier から生まれました。建築家の Stephen Sauvestre が外観デザインに加わり、最終案を推し進めたのがギュスターヴ・エッフェルです。当初の案では、4 本の格子状の塔脚が使われており、下部は大きく広がり、上に向かって少しずつ寄り合う形になっていました。

塔脚の曲線は数学的に設計されており、風の力に対する構造の強さを高める役割を果たしています。金属部材はすべて工場で事前に製作され、一つひとつ専用に設計・計算されたもので、図面の精度は 10 分の 1 ミリに達していました。つまり、これを作り直すということは「幾何学的な立体を積み上げる」ことではなく、部材や曲線、階層のあいだにある厳密な関係を理解することが求められるのです。

Gemini 4 Carbon はどうやって2次元の歴史資料を3次元構造に変えるのか

ここからは本記事の分析です。Googleはこのタスクの内部ステップを公開していません。入力と出力から逆算すると、少なくとも3つのハードルを越える必要があります。

1. 歴史写真を理解する：施工写真は撮影角度がバラバラで、解像度にも限りがあります。そのため、画面の中で何階まで建っているのか、塔柱がどの段階にあるのかを見分け、写真を時間軸上のどの節目に対応させるかを判断しなければなりません。
2. 図面から幾何情報を抽出する：工学図面には立面図、断面図、寸法表記などが含まれます。ここから塔柱の傾斜角、プラットフォームの高さ、部材の配置といったパラメータを読み取る必要があります。
3. 空間関係を推論し、再構築可能なデータにまとめる：写真も図面も2次元です。複数の視点の情報を突き合わせて部材が3次元空間のどこにあるかを推論し、さらにモデリングコードを動かせる構造化された記述に整理しなければなりません。

Gemini 4 Carbon のモデルカードによると、入力はテキスト、画像、音声、動画に対応し、出力はテキストです。総コンテキスト容量は 1,048,576 トークンです。このことから、展示は Three.js コードという「テキスト」の形で納品されていると考えるのが妥当でしょう。3次元の表現は、ブラウザがコードを実行して描画したもので、モデルが3Dファイルを直接出力しているわけではありません。

Googleは同じ発表の中で、参考になる別の事例も紹介しています。Carbon が公開されている7件の都市計画PDFを処理して206枚の工学図面ビューを抽出し、10回の夜間イテレーションを経て、約90.6万個の三角形ポリゴンからなるインタラクティブな Three.js 建築モデルを生成したというものです。2つの事例は発想が似ていて、どちらも「異種混在の資料 → 空間情報 → インタラクティブな3D」という流れになっています。

Gemini 4 Carbon のマルチエージェントはエッフェル塔の展示をどう実現したのか

Google は、このデモが複数の Carbon エージェントによる /swarm での協調作業で完成したと認めています。ただし、今回のタスクで具体的にどう役割分担したのかは公開されていません。そのため、以下で紹介するのは Antigravity 公式ブログに書かれている Swarm の一般的な仕組みであり、このデモの実際の記録ではありません。

Google によると、エージェントが待機中でアイドル状態のときは Token を消費しません。ただし、複数エージェントの並列実行では全体の使用量が目に見えて増える点にも注意するよう呼びかけています。公式はさらに、役割ごとにモデルを使い分けることも勧めています。アーキテクチャ設計、タスクの調整、複雑な監査は Carbon に任せ、通常の実装や並列でのファイル修正は、より高速で軽量なモデルに任せるという考え方です。

この分担は、工学資料の再構築にとても理にかなっています。コーディネーターは「どの資料がどの段階に対応するのか」を理解するために深い推論が必要です。一方、部材の一括生成やシーンの組み立てのような繰り返し作業は、毎回最も高価なモデルを使う必要がありません。そして検証工程は品質の保険です。単一のモデルが三次元構造を連続して生成すると、比率が少しずつずれていきやすいからです。

Gemini 4 Carbon APIで似たような「図面→3D」タスクを試す方法

Antigravityの /swarm は製品内の機能なので、開発者がAPIパラメータひとつで直接再現することはできません。ただ、APIを使って簡易版のフローを組めば、「画像を読み取る → パラメータを抽出する → Three.jsを生成する」という一連の流れを体験できます。公式のモデルIDは gemini-4-carbon です。

最小構成のサンプル：Carbon に工事中の写真を解析させる

import base64
from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # OpenAI互換の統一インターフェース
)

with open("eiffel_1888.jpg", "rb") as f:
    img_b64 = base64.b64encode(f.read()).decode()

resp = client.chat.completions.create(
    model="gemini-4-carbon",
    messages=[{"role": "user", "content": [
        {"type": "text", "text": "判断照片中铁塔建到了哪一层，估算塔柱倾角与平台高度比例，输出 JSON。"},
        {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{img_b64}"}}
    ]}]
)
print(resp.choices[0].message.content)

import base64
import json
from concurrent.futures import ThreadPoolExecutor
from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)
MODEL = "gemini-4-carbon"


def encode(path: str) -> str:
    with open(path, "rb") as f:
        return base64.b64encode(f.read()).decode()


def ask(content, system: str = "") -> str:
    messages = []
    if system:
        messages.append({"role": "system", "content": system})
    messages.append({"role": "user", "content": content})
    resp = client.chat.completions.create(model=MODEL, messages=messages)
    return resp.choices[0].message.content


def worker_extract(path: str) -> str:
    """並列ワーカー：1枚の写真または図面から構造パラメータを抽出する"""
    return ask([
        {"type": "text", "text": "提取该资料中的结构信息：所属施工阶段、塔柱倾角、平台高度比例、可见杆件排布，只输出 JSON。"},
        {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{encode(path)}"}}
    ], system="你是结构工程资料分析员，数据不确定时标注 uncertain，不要编造。")


def builder(merged: str) -> str:
    """ビルダー：統合後のパラメータから Three.js ページを生成する"""
    return ask(
        "根据以下结构参数，生成单文件 HTML，使用 Three.js 构建四根格构塔柱与两层平台，"
        "并提供 1887—1889 时间轴滑块按阶段显示结构：\n" + merged
    )


def verifier(merged: str, html: str) -> str:
    """検証者：コードとパラメータが一致しているかをチェックする"""
    return ask(
        "检查下列 Three.js 代码是否与结构参数一致，列出比例错误、阶段错误和无法运行的代码：\n"
        f"参数：{merged}\n代码：{html}"
    )


sources = ["photo_1887.jpg", "photo_1888.jpg", "drawing_elevation.jpg"]

with ThreadPoolExecutor(max_workers=3) as pool:
    results = list(pool.map(worker_extract, sources))

merged = json.dumps(results, ensure_ascii=False)
html = builder(merged)
report = verifier(merged, html)

with open("eiffel_exhibit.html", "w", encoding="utf-8") as f:
    f.write(html)
print(report)

このコードは、通常の API を使って Swarm の考え方を再現した簡易的な実装で、Google の内部方式ではありません。注意点は2つあります。Carbon は temperature や top_p などのサンプリングパラメータを無視します。また、thinking_budget を渡すと HTTP 400 が返ります。デフォルトの推論レベルは MEDIUM で、高いレベルの推論ほどトークンを消費し、応答も遅くなります。

🚀 はじめるときのヒント：複数の画像や複数のステップを扱う実験では、まず小さなサンプルでプロンプトの効果を確かめておくのがおすすめです。APIYI（apiyi.com）なら無料のテスト枠を受け取れて、1つの APIキーで Gemini、Claude、OpenAI などのモデルを切り替えられます。「軽量モデルで一括抽出し、高い推論能力を持つモデルで計画と検証を行う」という役割分担も、コードに落とし込みやすくなります。

Gemini 4 Carbon インタラクティブ3D展示と従来の提供形式の比較

Three.jsの役割は、3Dシーンをブラウザ上でそのまま動かせるようにすることです。観客はソフトをインストールしなくても、視点を回転させたり、細部をズームしたり、タイムラインをドラッグして年ごとの施工状況を確認したりできます。下の表は、歴史資料でよく使われる表現方法を比較したものです。

インタラクティブ展示の最大の価値は「追跡可能性」にあります。本質的にはコードなので、各階層のプラットフォームや塔柱の各区間が、読み取れるパラメータとして対応しています。後から図面との食い違いが見つかっても、ピンポイントで修正でき、一から作り直す必要はありません。これは、検証Agentが力を発揮するための土台にもなっています。

Gemini 4 Carbon エッフェル塔デモがもたらす影響の分析

まず前提として押さえておきたいのは、これは Google が公式に披露した事例であり、第三者による独立した検証結果ではないという点です。Carbon と Swarm で何ができるのかは示されていますが、「どんな建築資料でも安定して再構築できる」という一般的な結論までは導けません。

開発者への影響

• ワークフローが単発の呼び出しからオーケストレーションへ移行する：1つのプロンプトの裏では複数の Agent が役割分担して動いています。開発者はタスクの分解、中間結果のフォーマット、検証の仕組みに目を向ける必要があります。
• コストは単価ではなくタスク単位で見積もる：Carbon の発売時の価格は、入力が100万トークンあたり2ドル、出力が10ドルで、12月1日から2倍になります。思考トークンは出力に含まれ、複数 Agent の並列実行によって使用量がさらに膨らむ場合もあります。
• 複数モデルの併用がより現実的になる：公式は、Carbon には計画立案・調整・監査だけを任せ、大量の実行処理は軽量モデルに委ねることを推奨しています。コストを抑えるうえで、これは非常に重要です。

業界への影響

• 歴史的建造物のデジタル化：写真や図面にしか残っていない多くの建築物が、より低いハードルでインタラクティブなモデルに変換できるようになり、研究者が比較検討に使える可能性があります。
• 工学資料の再構築：都市計画 PDF の事例とエッフェル塔の事例は、どちらも同じ方向性を指しています。つまり、形式の異なる文書から空間情報を抽出するという方向です。
• デジタル展示と教育の可視化：博物館や教師は、「5,300枚の図面、250万本のリベット」といった抽象的な数字を、生徒がタイムラインをドラッグしながら観察できるシーンに変えられます。

一方で、制約にも目を向けておく必要があります。/swarm は現時点ではまだプレビュー機能です。また、モデルカードには、Carbon がハルシネーションを起こす可能性があること、高い推論レベルでは応答が遅くなったりタイムアウトしたりする場合があることが明記されています。厳密な精度が求められる工学の現場では、AI による再構築結果は引き続き専門家が確認すべきです。

よくある質問 FAQ

Gemini 4 Carbon エッフェル塔デモの重要ポイント Key Takeaways

• 事例の本質：複数の Carbon Agent が、歴史的な写真や図面を Three.js のインタラクティブな展示に変換します。
• 1つのプロンプトは1回の生成ではない：裏では Swarm によるタスク分解と並列協調が動いています。
• エンジニアリング上の難しさは本物：18,038点の部材と5,300枚の図面があり、構造には極めて高い精度が求められます。
• 成果物はコード：Carbon が出力するのはテキストで、展示は修正可能な Three.js コードとして提供されます。
• コストは全体で考える：マルチ Agent の並列実行は使用量を押し上げるため、役割ごとにモデルを使い分けるほうが経済的です。
• 限界を明確に：公式デモは一般的な性能を保証するものではなく、Swarm もまだプレビュー機能です。
• 始め方：APIYI（apiyi.com）の統一インターフェースを使い、少量のサンプルで画像の読み取りとモデリングの流れを検証できます。

まとめ

Gemini 4 Carbon のエッフェル塔デモには、注目すべき点が3つあります。

1. 入力は異種混在の歴史資料：写真とエンジニアリング図面を理解して位置合わせし、空間パラメータへ変換する必要があります。
2. プロセスはマルチ Agent の協調：1つのプロンプトで Swarm を起動し、調整・実行・検証を分担してタスクを完了します。
3. 成果物はインタラクティブな3Dの展示：Three.js により、1887〜1889年の建設過程をブラウザ上で自由に見て回れます。

開発者にとって特に参考になるのは、「深い推論ができるモデルが計画を立て、軽量なモデルが実行し、検証工程で最終的な品質を担保する」というオーケストレーションの考え方です。まずは APIYI（apiyi.com）を使って小規模な資料で一連の流れを動かしてみて、そのうえでさらに大きなマルチ Agent タスクに投資するかどうかを判断することをおすすめします。

📚 参考資料

1. Google 公式発表：Gemini 4 Carbon is now available：エッフェル塔の事例と /swarm のリリース情報
2. リンク： blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-4-carbon-now-available/

3. 説明： 事例の元の説明、提供範囲、価格の変更点

4. Google Antigravity 公式ブログ：Gemini 4 Carbon in Google Antigravity

5. リンク： antigravity.google/blog/gemini-4-carbon-in-google-antigravity/

6. 説明： Swarm の調整、並列処理、敵対的検証、メッセージボードの仕組み

7. Gemini 4 Carbon Model Card：Google DeepMind のモデルカード

8. リンク： deepmind.google/models/model-cards/gemini-4-carbon/

9. 説明： 入出力のモダリティ、コンテキストの上限、既知の制限事項

10. Gemini 4 Carbon 開発者ガイド：Google Cloud ドキュメント

11. リンク： docs.cloud.google.cn/gemini-enterprise-agent-platform/models/guides/gemini-4-carbon

12. 説明： Thinking Level、パラメータの制限、長いデコードについての解説

13. エッフェル塔公式の歴史資料：La tour Eiffel

14. リンク： toureiffel.paris/en/the-monument/history
15. 説明： 部材の数、図面の枚数、施工のタイムライン、構造設計の背景

著者: APIYI 技術チーム
技術交流: マルチエージェントのオーケストレーションやマルチモーダルな3D生成についてご質問がありましたら、APIYI（apiyi.com）のトップページからお気軽にお問い合わせください

関連記事

• モデルにThree.jsを書かせて直接3Dファイルを生成しない：コード中間層ワークフローの5つの示唆:Qwen3.5-4B-GLB-3D-Coderを例に、「テキスト→Three.js→GLB」のコード中間層ワークフローを分解し、ローカルデプロイ、クラウド接続、Godot検証の実践手順を示してください。
• Gemini 4 Carbonリリース解説：59点でOpus 5.5を逆転、17項目中15項目で勝利も呼び出せない:Gemini 4 CarbonはArtificial Analysisの総合知能指数で59点を獲得して首位となり、公式の17項目の比較で15項目に勝利しましたが、APIモデルIDも公開予定もなく、この記事では評価基準ごとにスコアを整理し、現時点で呼び出せない理由と、中国の開発者が今はgemini-4-argonを先に利用できることを説明します。