AI 3D生成API — 複数のエンジンを、ひとつのAPIで
製品にAI 3D生成を組み込みたい。でも、エンジンの切り替えやジョブのキュー、エクスポート、アセット配信まで自前で組むのは大変ですよね。その部分をPicoBerryが非同期API 1本で引き受けます。テキストから3D、画像から3Dはもちろん、仕上げの工程やダウンロードできるゲームアセットの出力まで対応します。
# 画像から3Dモデルを生成
curl -X POST https://api.picoberry.ai/v1/models/from-image \
-H "Authorization: Bearer ***" \
-H "Content-Type: application/json" \
-d '{"imageUrl":"https://.../ref.png","engine":"tripo"}'自社サービスにAI 3D生成を組み込むには？
PicoBerryのダッシュボードでAPIキーを作り、サーバー側に置きます。プロンプトや画像URLに、使うエンジンと出力の指定を添えて/v1エンドポイントへPOSTすると、タスクIDが返ってきます。そのIDでポーリングするか、Webhookを登録してジョブ完了時にバックエンドへ通知させます。完了したらモデルをダウンロードして、自社プロダクトに組み込みます。
パイプラインを組まなくても、3D生成機能を載せて出せます
モデルのエンドポイントだけでは、なかなか足りません。製品にきちんと組み込むには、これだけのものが必要です。
- アップロード処理
- エンジン選択
- 非同期ジョブ追跡
- 結果の保存
- エクスポート形式
- 使用量の管理
- アセット配信
PicoBerryは、このパイプライン全体をAPI 1本にまとめています。
# prompt/image → 3D
POST /v1/models/from-image
{ "imageUrl": "ref.png", "engine": "tripo" }テキストや画像から3Dを生成
テキストプロンプトかリファレンス画像を渡すと、3Dの候補ができます。そのままリメッシュやリテクスチャ、リギング、エクスポートまで一か所で完結するので、複数のサービスを行き来してファイルをやり取りする必要がありません。
# same request, switch engines
{ ..., "engine": "tripo" }
{ ..., "engine": "meshy" }
{ ..., "engine": "hunyuan3d" }エンジンは複数、扱うAPIはひとつ
リクエストごとに、その仕事に合ったエンジンへ振り分けます。あるプロンプトはTripo、別のものはMeshy、また別のものはHunyuan3Dへ。それでも、コード側で認証してジョブを投げ、結果を受け取ってエクスポートする流れは常に同じです。
# submit → get a task id
{ "taskId": "job_a1b2", "status": "queued" }
# poll/webhook until succeeded最初から非同期で設計
3D生成はすぐには終わりません。そこで、実際のプロダクションのキュー動作を前提に設計しました。ジョブを投げてtask IDを保存し、ポーリングで確認するかWebhookを受け取り、結果が用意できたらアプリの処理を先に進めます。
パイプラインを自前で組むか、APIを1回呼ぶか
どちらでも、できあがる3Dアセットは同じです。違うのは、キューやエンジンの配線、保存、配信をどこまで自分で抱えるかです。
APIキーの発行から、アセットのダウンロードまで
まずは小さく始めれば大丈夫です。APIキーを作り、生成ジョブを投げて、状態を確認したら、できあがったアセットをユーザーフローやワークスペース、インベントリ、エディター、パイプラインなど必要な場所につなぎます。
APIキーを取得
PicoBerryのダッシュボードでキーを作成します。権限は必要な範囲だけに絞り、サーバーサイドで保管してください。使用量を分けて把握したいときは、環境やツール、チームごとにキーを分けておくとよいでしょう。
ジョブを投げる
/v1エンドポイントに、プロンプトや画像URL、エンジンの選択、出力オプションを送ります。レスポンスにはタスクやアセットの識別子がすぐ返ってくるので、UIが止まることはありません。
ポーリング、またはWebhookで受け取る
task IDでジョブの状態を確認するか、Webhookを登録しておきます。Webhookが届くと、バックエンドからユーザーに通知したり、ワークスペースを更新したり、自動コンテンツパイプラインの次の工程をトリガーしたりできます。
アセットをダウンロード
できあがったモデルを取得して、自分の製品に渡します。Webビューアーで表示したり、プロジェクトに紐づけたり、ゲームエンジンのワークフローへ送ったり、あとで編集するために保存しておいたりできます。
開発者目線でつくった機能
アセットを繰り返し生成し続ける必要がある製品やチームのための機能です。一度きりのデモではなく、こうした現場で回り続けることを想定してつくりました。
OpenAPIスペックと型付きクライアント
リクエストとレスポンスの正典として、OpenAPIスペックをそのまま使えます。試しながら学ぶ段階ではPostmanにインポートし、本番に載せる段階では、バックエンドの言語に合わせた型付きクライアントを生成して使えます。
Webhookで通知を受け取る
署名付きコールバック方式のWebhookを使います。これで、ポーリングをやめてイベント駆動のワークフローに移れます。生成が終わると、サービス側でプロジェクトの状態を更新したり、ユーザーに通知したり、レビューをキューに入れたり、エクスポート処理を開始したりできます。
AIエージェント向けMCPサーバー
PicoBerryのMCPサーバーを使えば、生成機能をAIコーディングツールやエージェントのワークフローにつなげます。エージェントは、より大きなアプリやゲーム、ツールを組み立てる流れの中で、アセットの候補を直接リクエストできます。
使用量とクレジットの確認
ダッシュボードからクレジットの使用量を確認できます。生成ワークフローを拡大する前に、開発用・社内ツール・顧客向け機能・実験を切り分けて把握できます。
API 1回で、3D生成を組み込めます
サーバー側にキーを作り、最初のジョブを投げるだけ。モデルの準備ができるとWebhookがバックエンドに知らせるので、そこでダウンロードします。
APIキーはサーバーサイド · 使用量はダッシュボードで確認
実際に動くゲームアセットのワークフロー
下のデモを見ると、このAPIが生成結果ひとつで終わらない理由がわかります。作ったアセットを実際のシーンに移し、エンジンのワークフローとかみ合わせて動かし、プレイの文脈で使えるかどうかを見極めます。
デモ動画：生成・編集した3DアセットがUnityのシーンに収まっていく様子です。アセット生成からインゲーム検証まで、ひと続きの流れを収めています。
候補をすばやく生成
プロンプトやリファレンス画像から、プロップやアイテム、キャラクター、環境要素を作ります。選んだ結果はアセットの記録として残しておけば、あとから追跡できます。
アセットをゲームのシーンに合わせる
デモでは、生成のあとに来る実践的な工程を見せます。作った3DアセットをUnityのワークフローに置き、スケールやシルエット、ライティング、マスク、シーン構成が合っているかを確かめて、シーンで使えるかどうかを見極めます。
プレイテストでループを締める
単体のモデルプレビューが目的ではありません。生成→統合→テストのループをより速く回し、実際のゲーム体験の中でアセットを評価できるようにするのが狙いです。
開発者ひとりがこのAPIで12時間にどこまで行けるか？
『デラーの伝説』は、開発者ひとりがPicoBerry APIをコーディングエージェントにつないで作ったアイソメトリックのアクションRPGです。村の建物、ダンジョンの構造物、小道具、NPC、ボスまで、ゲーム内の3DアセットはすべてこのAPIで生成しました。アイデアからプレイできるビルドまで約12時間です。
制作者が作り方を自分で解説します — 狙う雰囲気をエージェントに言葉で伝え、APIでアセットを生成し、配置と動きを手で整えるまで。英語のナレーションと字幕です。
村のハブ、レインミスト・ヘイブン。建物も小道具もNPCも動物も、すべてAPIで生成してthree.jsのシーンに配置したアセットです。
ダンジョンの聖所。アーチも旗も壺もランタンも、村と同じAPI契約で作っています。
アリーナの雨の守護者 — キャラクターと大剣、アリーナの構造物を生成してからアニメーションを付けました。
アセットより先にコンセプト
村・ダンジョン・ボスの聖所という三つの空間を先に決め、それぞれのルックを生成しました。以後のアセットが合わせるべき基準ができたわけです。
APIをコーディングエージェントに接続
PicoBerry APIをエージェントにつなぎました。参考画像がないときは、狙う雰囲気とオブジェクトを説明すればエージェントが生成用プロンプトを書きました。
配置は結局人が詰めた
エージェントはシーンを組み立てる程度には3D座標を理解しましたが、位置と回転、スケールは人の手が要りました。そこでエージェントに配置エディタを作らせ、画面を見ながら村を整えました。
DCCを往復せずアニメーション
PicoBerryのアニメーションで基本動作を作って目で確かめ、three.jsに持ち込んでボーン位置とキーフレームを直接調整しました。あいだにBlenderでのリギング工程はありません。
エージェントが作った配置エディタ
シーン内のすべてのオブジェクトの位置・回転・スケールを、スナップとアンドゥ付きで調整します。APIが代わりにやってくれない部分で、DCCパッケージを往復する代わりにエージェントにツールを作らせて解きました。
ブラウザで動いている画面
完成した村のプレイ画面。NPCの会話、スキルバー、ミニマップが並び、生成したアセットがモデルビューアではなく実際のゲームを支えています。
リギングとウェイトに費やすはずだった時間を削り、その時間をゲーム画面で動きがどう見えるかに使えたことが、速さの源でした。
制作した開発者
同じ本人が、まだ完成ではないこともはっきり言っています。アニメーションはさらに詰める必要があり、アセットも最終形ではなく出発点です。変わったのは作業が消えたことではなく、その12時間がどこに使われたかです。
動いている様子を見る
APIの価値は、それを使って製品で何ができるかで決まります。候補を作り、結果を比べ、アセットの記録を残し、次の工程で使えるファイルを渡すところまでです。
製品側でレビュー・選択・調整・下流へのエクスポートに回せる、さまざまな3D候補を並べた画面です。
Quickstartの流れ：認証して、最初のリクエストを送り、レスポンスを確認したうえで、生成機能を自前のバックエンドフローにつなぎます。
{ "success": true, "data": {
"id": "019f3a39-0db2-…",
"taskStatus": 0,
"type": "model_3d"
} }
# later
{ "modelUrls": { "glb": ".../model.glb" } }非同期フローの例：ジョブを投げ、返ってきた識別子を保存し、ポーリングで確認するか完了通知を受け取ったあと、生成されたモデルのURLを取得します。
よくある質問
PicoBerry APIは何をするものですか？
PicoBerry APIは、AI 3D生成のための非同期REST APIです。バックエンドから生成ジョブを投げ、状態を確認し、完了イベントを受け取り、生成されたモデルファイルを取得できます。製品にもパイプラインにも組み込んで使えます。
ひとつのAPIで複数の生成エンジンを使えますか？
はい、使えます。リクエストは適したエンジンへ振り分けられますが、製品側で相手にするのはPicoBerry APIひとつだけです。認証やジョブの追跡、アセットの記録、エクスポートの流れは、どのエンジンを使っても変わりません。
このAPIはゲーム専用ですか？
いいえ。ゲームを前面に出しているのは、ゲームツールと3DアセットのパイプラインがPicoBerryの中心的なワークフローだからです。同じAPIのパターンは、クリエイターツールやマーケットプレイス、社内の自動化、AIエージェント、教育ツールなど、3Dを扱う他の製品にもそのまま使えます。
生成されたアセットは、そのまま製品版として使えますか？
生成されたアセットは、候補としてとらえるのが安全です。プロトタイピングや反復作業、レビュー、次の工程への受け渡しに向いています。最終版として使えるかはプロジェクトによって異なり、トポロジーやマテリアル、スケール、リギングが適切か、コリジョンやライセンス、エンジンごとの要件に問題がないかを、別途確認する必要があります。
PicoBerryはWebhookに対応していますか？
はい、対応しています。APIのワークフローは非同期です。生成ジョブを投げると識別子が返ってくるので、それを保管しておき、ポーリングで状態を確認するか、完了時にWebhookを受け取ります。
開発者はどう始めればよいですか？
有料プランのPicoBerryアカウントを作るか、クレジットパックを一度でも購入すれば、ダッシュボードで自分でAPIキーを発行できます。申請や順番待ちはありません。支払い履歴のない無料アカウントはダッシュボードは見られますが、/v1の呼び出しは403になります。最初の呼び出しはサーバーサイドに組み込み、APIキーはクライアント側のコードに置かず、必要に応じて環境や製品ごとにキーを分けておいてください。
3D生成レイヤーは、一度つくれば十分。 アセットが必要な場所なら、どこでも使えます。
API呼び出し1回から始めましょう。あとは生成機能を、アプリやツール、エージェント、ゲームアセットのパイプラインにつなぐだけです。
ひとつの非同期API · エンジンを変えても連携はそのまま