2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Codexで画像からVoxelアートを生成するパイプラインを作ってみた

2
Last updated at Posted at 2026-06-01

昨今、CodexやClaude CodeのようなAIエージェントツールが非常に話題になっています。私自身も使うことはありますが、まだコーディングのサポート用途が中心で、もう少し色々な使い方を試してみたいと思っていました。

そこで、基本的な考え方を一から学ぼうと思い、Claude Code 101 を見てみました。SubAgentやSlash Command、MCPなどの用語は一通り分かった気になったものの、やっぱり実際に使ってみないと腹落ちしません。

実験にはClaude CodeとOpenAIのCodexのどちらを使うか少し迷いましたが、ちょうどOpenAIを課金中だったこともあり、今回はCodexで試してみることにしました。

次に悩んだのが、何を題材にするかです。普段の開発では「これは明確にSubAgentに分けないと厳しい」というほど巨大なタスクをいつも扱っているわけではありません。そこで今回は、GPT-5.5の画像理解能力や、構造化データを生成する力のベンチマークも兼ねて、1枚の画像からVoxelアートを生成する小さな3D生成パイプラインを作ってみることにしました。

実装や生成フローはCodex上で組みつつ、その中でSubAgent的な役割分担も試してみる、という位置づけです。

SubAgentの書き方や、そもそもどういう役割に分けるとよいのかも最初はよく分かっていなかったので、そのあたりの相談もCodexと一緒に進めています。

最終的には、CodexのUIに画像を渡すパターンと、スマホやQuestで撮った画像を使うパターンの2つを試しました。

作ったもの

作ったのは Snap2Voxel という小さなローカルWebアプリです。

入力画像をCodexに渡すと、Codexが画像の内容を読み取り、Voxelアートとして解釈し、静的なThree.jsビューアで見られるJSONデータを生成します。

やっていることは、正確な3D復元やフォトグラメトリではありません。あくまで「画像をもとに、それっぽくてかわいいVoxelアートとして解釈する」ためのパイプラインです。

生成されたモデルは、だいたい次のようなファイルとして保存されます。

data/
  models/
    <model-id>/
      meta.json
      voxels.json
      source-note.md
  index.json

voxels.json には立方体の座標と色、meta.json にはタイトルやタグ、source-note.md には画像をどう解釈したかを書きます。data/index.json はギャラリー用の一覧です。

興味がある方は、こちらのリポジトリを確認して各自お試しください。試す場合はCodexのクレジットを消費する点だけご注意ください。

GitHubリポジトリはこちら

全体像

今回やりたかったのは、単に「画像から何かを生成する」ことではなく、Codexに作業を任せるための流れを作ることでした。

具体的には、1つの大きな依頼をそのまま投げるのではなく、次のような観点に分けています。

  • 入力画像を見て、何を残すべきか整理する
  • Voxelアートとして成立する形と色に落とし込む
  • JSONデータや表示結果が壊れていないか確認する

この構造を、記事用に抽象化したものが下の図です。

コンテンツ生成エージェントの全体像

今回のSnap2Voxelでは、Codexをオーケストレーターとして使い、その中で必要に応じてSubAgentに観点別の仕事を任せることにしました。つまり、一気通貫で丸投げするのではなく、見る人、作る人、確認する人を分けて進めるイメージです。

Voxel生成フロー

具体的なVoxel生成では、次の3つの観点に分けています。SubAgentが使える場合は、このうち画像理解やVoxel生成のような独立しやすい部分を役割として切り出します。

  1. Subject Interpreter
    入力画像を見て、主題、姿勢、シルエット、色、残すべき特徴を整理します。

  2. Voxel Artist
    解釈メモをもとに、voxels.jsonmeta.json を作ります。

  3. Validator
    JSONとして正しいか、座標や色の形式が合っているか、ビューアで表示できるかを確認します。

Validatorで問題が見つかった場合は、その指摘をもとにCodexがデータを修正します。厳密な自動ループというより、生成と検証を同じ作業フローの中で行き来するイメージです。

この流れを、もう少しSnap2Voxel寄りに描いたものが下の図です。

ボクセル生成フローの例

図にすると大げさに見えるかもしれませんが、やっていることはかなり素朴です。
画像を見る役、作る役、壊れていないか見る役。まずはこのくらいに分けることで、他のコンテキストに引きずられすぎず、それぞれの役割に集中してもらいやすくしています。

Codexに任せたこと

今回、Codexに任せた作業はだいたい次の通りです。

  • 入力画像の主題や特徴の整理
  • Voxelアートとしての形状設計
  • voxels.json の生成
  • meta.jsonsource-note.md の作成
  • data/index.json への登録
  • ローカルビューアでの表示確認

ポイントは、生成だけでなくデータ検証とブラウザでの表示確認まで含めたことです。

ただし、スマホやQuest経由の入力では環境によってブラウザ表示確認まで自動で行えないこともあるので、その場合はデータ検証までを必須にしています。

AIにファイルを書かせるだけなら簡単ですが、JSONが壊れていたり、ビューアで開けなかったりすると、結局あとで人間が直すことになります。

そこで、AGENTS.mddocs/photo-to-voxel-workflow.md に「通常のモデル生成で触ってよいファイル」「画像をどう解釈するか」「検証で見るべき項目」を書いておきました。

Codexには、単発のプロンプトだけで頑張ってもらうというより、リポジトリ内のルールを読んで、そのルールに沿って動いてもらう形にしています。

入力経路

入力経路は大きく2つ用意しました。

1つ目は、CodexのUIに画像を渡して、そのままモデル生成を依頼する方法です。これがいちばん素直で、普段のCodexの使い方に近いです。

2つ目は、スマホやQuestのカメラで撮影した画像をPC側へ送り、PC上のCodexに処理してもらう方法です。ここではカメラ映像そのものを処理しているわけではなく、カメラ映像から1フレームをJPEGとして送っています。Quest側で受け取って表示する部分は、今回の実験用に試した構成です。

全体の流れはこんな感じです。

スマホやQuestから送る部分ではWebSocketも使っていますが、今回の本質はそこではありません。あくまで「手元の端末で撮った画像を、PC上で動いているCodexへ渡すための橋」くらいの位置づけです。

結果

まずは、CodexのUIに画像を渡す、またはスマホアプリから撮影画像を渡して、Voxelアートを生成する流れです。
動画の前半では、牛の画像からVoxelアートを作っています。途中で足の本数が8本になってしまうミスもありますが、3D生成専用のAIではないので、そこはご愛嬌ということで。
もう1つは、Questのカメラで撮影した画像を渡し、生成された結果をQuest側で受け取って表示する実験です。

どちらもやっていることは同じで、入力は1枚の画像です。その画像をCodexが読み取り、Voxelアートとして解釈し、表示可能なデータに変換しています。

やってみて分かったこと

一番の学びは、SubAgentは「複雑な開発だけのもの」ではないということでした。

今回のような小さな制作タスクでも、画像理解、生成、検証のように観点を分けるだけで、かなり使いどころが見えてきます。

オーケストレーションやSubAgentの書き方を0から考えようとすると、正直けっこう手が止まります。どこまでを親エージェントに持たせるのか、どこからをSubAgentに任せるのか、最初は判断しづらいです。

その点、今回は「どういう役割分担にするとよさそうか」「AGENTS.mdやワークフローにはどんな粒度で書けばよいか」もCodexに相談しながら進められました。SubAgentを使う練習をしつつ、SubAgentの設計方法自体もAIと一緒に学べたのがよかったです。

特に、Voxelアート生成のような「正解が1つではない」タスクでは、最初に何を大事にするかを整理する工程が効きました。Subject Interpreterが、姿勢、シルエット、色、特徴パーツを言語化してから、Voxel Artistがそれをデータに落とし込む。これだけでも、いきなりJSONを書かせるより結果を見やすくできます。

また、Validatorの存在も大事でした。生成物がかわいいかどうかだけでなく、データとして壊れていないか、ビューアで見られるかを最後に確認することで、実験として終わらず、ちゃんと使える形に近づきます。

今回は自分の好きな3D技術に寄せて試しましたが、日常業務でも同じ考え方は使えそうです。たとえば顧客ヒアリングメモから提案書のたたき台を作るなら、ヒアリング整理担当 が要望や制約を抜き出し、提案構成担当 が章立てと訴求ポイントに落とし込み、レビュー担当 が抜け漏れや言い過ぎを確認する、という分け方ができます。いきなり完成物を書かせるより、最初に大事な要素を整理してから作り、最後に確認する方が、AIにも頼みやすそうです。

まとめ

今回は、Codexだけで画像からVoxelアートを生成する小さなパイプラインを作ってみました。

最初の目的はSubAgentを勉強することでしたが、実際にやってみると、SubAgentそのものよりも「AIエージェントに任せる仕事をどう分解するか」がかなり重要だと感じました。

画像を理解する、Voxelアートとして作る、データと表示を検証する。この3つに分けるだけでも、Codexに任せる範囲がぐっと扱いやすくなります。

AIエージェントツールの用語を覚えたあとに、実際の手触りを得るための題材として、こういう小さな生成パイプラインを作ってみるのはなかなか良かったです。

おまけ

さらに続きとしてQuestで撮影した写真をPCに渡すインタラクションや、AIが作ったVoxelアートの見せ方などをブラッシュしました。

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?