つくるものと仕事の全体地図

一枚の画像から、動くサービスまでを区別する

読む目安：約8分。教材としての制作提案です。生成・性能・料金の比較実験は実行していません。

この章でできるようになること

• 成果物の種類を説明できる
• 工程と担当者を結びつけられる
• AIに任せる作業を小さく分けられる

成果物を四つの層で見る

素材（asset）は、PNG画像、音、3Dモデルなど、再利用する部品です。シーン（scene）は、素材をどこに置き、どの光とカメラで見るかを決めた状態です。ランタイム（runtime）は、その場で操作や時間に応じてシーンを動かすアプリです。動画（video）は、見せる順番を決めて書き出した連続画像と音です。同じ海を表現しても、背景画像、3Dの海のシーン、触れる海のWebアプリ、海の映像では必要な技術も納品物も違います。

業界より先に工程を読む

広告、ゲーム、アニメ、映画、SNS、Webサービスでは担当名や分業の粒度が違います。それでも「目的を決める→案を出す→素材を作る→動かす→仕上げる→公開する→反応を見る」という流れで整理できます。個人制作では一人が何役も担当します。AIはこの流れの各工程を助けますが、誰に何を伝えるか、どの案を採用するか、公開してよいかという判断まで自動的に正解になるわけではありません。

形容詞を納品条件へ翻訳する

「かわいい3Dのキャラ」だけでは、画像が欲しいのか、回転できるモデルが欲しいのか分かりません。「サービスの空状態に置く、透過PNG、正面と喜びの2種類、小さく表示しても表情が分かる」のように使う場所と合格条件を書きます。3D風の画像は、奥行きらしい陰影を持つ2D画像です。そこから自動的に編集可能な3Dモデルが手に入るわけではありません。

学習ルート

ルート	読む順番	目標
まず共通の土台	つくるものと仕事の全体地図 → AIを条件付きの提案器として使う → 見た目を言葉と仕様にする	欲しい成果物と入力、判断基準を言葉にできる
サービスに使う画像	つくるものと仕事の全体地図 → AIを条件付きの提案器として使う → 見た目を言葉と仕様にする → キャラクターを一人の存在にする → 実写風ポートレートを設計する → ドット絵を小さな設計図として作る → 作品をSNSとサービスへ届ける → 品質と費用を測って次へつなぐ	使い回せる画像と一貫性のある差分を作る
触れる3Dと海	つくるものと仕事の全体地図 → AIを条件付きの提案器として使う → 3Dモデルを使える素材にする → シェーダーと見え方の仕組み → 海を部品ごとに組み立てる → 動きと動画を別の工程で作る → 品質と費用を測って次へつなぐ	形・材質・光・動き・負荷を分けて改善する
作品を発信する	つくるものと仕事の全体地図 → 見た目を言葉と仕様にする → キャラクターを一人の存在にする → 動きと動画を別の工程で作る → 作品をSNSとサービスへ届ける → 品質と費用を測って次へつなぐ	制作の意図と過程が伝わる公開物を作る

成果物の四層

要素	意味	例	区別する点
素材 Asset	他の制作で使う部品	PNG、テクスチャ、GLB、効果音	3D風PNGは回転できる3Dモデルではない
シーン Scene	部品と配置、光、カメラを組んだ状態	キャラ、床、照明、カメラがある空間	シーンを作っただけでは操作や公開までは完成しない
ランタイム Runtime	端末で入力と時間に応じて動く仕組み	波の高さを変えられるWebアプリ	録画した動画ではユーザーが別の角度を選べない
動画 Video	時間順に固定して書き出した映像と音	作品紹介のMP4	元シーンや編集可能なデータを含むとは限らない

3Dが一枚の画像になるまで

要素	意味	例
Geometry	どんな形か	球、キャラのメッシュ、分割した海の平面
Material	表面をどう見せるか	マット、金属、水
Texture	場所ごとの画像や数値データ	色、法線、粗さ。写真だけとは限らない
Shader	GPUで位置や色などを計算するプログラム	時間で頂点を上下させる、表面の反射を計算する
Light	どこからどう照らすか	太陽、面光源、環境光
Camera	どこからどう切り取るか	視点、画角、向き
Render	設定から画像を計算する	リアルタイムの1フレーム、静止画の書き出し
Composite	画像や層を組み合わせ仕上げる	背景合成、色調整、輝き、字幕

AI制作の制御を増やす順番

要素	意味	例
文章	意味と条件を指定	主役、用途、構図、色
参照	見た目や構造の手がかり	基準キャラ、ポーズ、許可のある素材
局所編集	採用部分を残し必要箇所を変える	服の色、手、小物
手作業・コード	厳密さが必要な箇所を制御	文字組み、正確なピクセル、UI状態、3D形状
検証	意図通りか独立に確かめる	比較画像、全周確認、実端末測定

業界ごとの仕事と成果物

仕事の名前が違っても、成果物、成功の問い、AIの担当、人が確認する箇所に分けると比較できます。

分野	成果物	典型的な担当	成功の問い	AIの用途	人の確認
Web・アプリ	ヒーロー画像、空状態のキャラ、触れる3D、UIモーション	プロダクトデザイナー、フロントエンドエンジニア、モーションデザイナー	利用者が内容を理解して操作できるか	方向性の案、素材ラフ、コードの補助	読みやすさ、状態設計、性能、アクセシビリティ
ゲーム	スプライト、3Dキャラ、背景、リアルタイムVFX	ゲームアーティスト、モデラー、リガー、テクニカルアーティスト	視点と操作が変わっても成立するか	コンセプト、ラフ、テクスチャ候補	一貫性、接地、変形、容量、動作
アニメ・映像	設定画、ショット、合成素材、完成映像	監督、絵コンテ担当、アニメーター、コンポジター、編集者	時間を通じて人物と物語が伝わるか	絵コンテ候補、背景案、ショット素材	連続性、演技、編集、音、権利
広告・ブランド	キービジュアル、商品画像、短い映像、展開素材	アートディレクター、デザイナー、コピーライター、プロデューサー	伝えたい価値とブランドの約束が一致するか	方向性探索、構図候補、サイズ展開の補助	事実、商品の正確さ、表示、権利、媒体仕様
SNS・個人発信	投稿画像、短編動画、サムネイル、制作解説	クリエイター、編集者、SNS運用担当	対象の人に見る理由が伝わるか	企画の補助、素材案、字幕の下書き	事実確認、開示、出所、反応の解釈

共通の制作工程

工程	問い	入力	出力	次へ進む条件
企画	誰に何を伝えるか	目的と制約	制作ブリーフ	用途と合格条件が明確
プリプロダクション	どう見せるか	ブリーフと参照	ラフ、構図、設定、絵コンテ	高コスト工程へ進む前に方向を合意
素材制作	必要な部品は何か	採用案と仕様	画像、モデル、音、コード	用途別の形式と品質
組立と動き	配置と時間でどう伝えるか	素材と動作設計	シーン、UI、ショット	一貫性と動作
仕上げ	見やすく整っているか	シーンや編集途中の素材	最終画像、動画、アプリ	文字、色、音、性能
公開と検証	目的を達成したか	完成物と利用条件	公開パッケージと改善記録	開示、権利、実測、次の仮説

用語辞典

• ブリーフ（brief）：目的、対象、制約、納品物、合格条件をまとめる短い仕様
• アセット（asset）：再利用する素材。画像、音、3Dモデルなど
• レンダリング（rendering）：形、材質、光、カメラなどから画像を計算すること
• リアルタイム（real-time）：ユーザー操作や時間に応じ、実行中に出力を更新すること
• オフラインレンダー（offline rendering）：その場の操作応答より完成画像を優先し、フレームを書き出す方法
• マテリアル（material）：表面の見え方を決める設定。テクスチャを使わないものもある
• テクスチャ（texture）：表面などの場所ごとに値を与える画像やデータ
• シェーダー（shader）：GPUで形や色などを計算するプログラム
• 法線（normal）：表面がどちらを向くかを表す方向
• UV（UV coordinates）：立体の表面と2Dテクスチャの対応を決める座標
• リグ（rig）：骨や制御点など、モデルを動かす仕組み
• ベイク（bake）：計算した見た目などをテクスチャや別のデータへ固定すること
• スプライト（sprite）：主に2D描画で使う画像素材やその表示単位
• キーフレーム（keyframe）：時間の要所に指定する位置や値
• コンポジット（composite）：画像や層を組み合わせ、完成画面へ仕上げること
• 推論（inference）：学習済みモデルへ入力を渡して出力を得る処理
• トークン（token）：モデルが扱う処理単位。文字、単語、画像、秒との換算は方式依存
• seed（seed）：乱数を初期化する値。対応しないサービスもあり、単独で再現保証にはならない
• プロンプト（prompt）：モデルへ渡す指示や文脈。画像等の条件と組み合わせる場合もある
• インペイント（inpainting）：指定した領域を周囲の文脈に合わせて作り直す編集
• レイテンシ（latency）：要求から結果までの待ち時間。動画の尺や課金時間とは別
• フレーム時間（frame time）：1フレームにかかった時間。平均だけでなく遅いフレームも確認する

結果の状態を区別する

状態	記録値	意味
実測	measured	実行日時・条件・ログまたは成果物がある結果
例示	illustrative	説明のための仮の値やデモ。実測ではない
未実行	not-run	設計または課題のみ。結果はまだない
未取得	not-collected	実行したが当該の値を取得できなかった

未知の値は null で残し、表示では「未取得」または「未実行」と示します。0と混同しません。

実行条件と記録方法は 品質と費用を測って次へつなぐ で学びます。

仕事の役割

• プロデューサー：目的、予算、納期を決める
• アートディレクター：見た目の判断基準を揃える
• デザイナー／アーティスト：素材を作る
• エンジニア／テクニカルアーティスト：素材を動作へつなぐ

入力から出力まで

入力	工程	出力
サービスの画面または用途、誰に何を伝えるかを一文、表示サイズと操作の有無	1. 使う場面を一つに絞る、2. 成果物を素材・シーン・ランタイム・動画のどれかに分類する、3. 目的、形式、枚数や尺、変更可能にしたい箇所を書く、4. 生成・手作業・コードの担当を分ける、5. 完成判定を3項目に絞る	制作ブリーフ1枚、工程ごとの入出力メモ

品質チェック

• 納品形式を開ける人が明確
• 見た目と動作の条件が分かれている
• 成功の判断が好みだけで終わらない

失敗を切り分ける

症状	考えられる原因	直し方
画像はきれいなのに実装できない	必要な成果物の種類が違う	必要形式と編集箇所を先に定義する
修正が終わらない	用途と合格条件が曖昧	最重要条件を三つに限定して優先順位をつける

実験課題：海のヒーロー画面を分解する

状態：未実行（not-run）。 ここにあるのは計画と完成条件です。成果物、所要時間、費用、性能、成功率はまだ記録していません。

海を使ったトップ画面を、静止画版・動画版・操作できる版の3案に分け、各案の入力、出力、担当技術、負荷を書こう。

提出物： 3案の制作ブリーフ

完成条件： 見た目が似ていても実装と費用の測り方が違う理由を説明できる

実行したときは予想と結果を分け、条件と証拠を 実験ノート に残します。

次に試す

テーマ別テンプレート（Catalog候補として原本を保管）で用途と成果物を選び、見た目を言葉と仕様にする で指示を整えます。

技術資料と根拠の範囲

技術資料は2026-10-03に確認しています。出典は技術的な仕組みの参照です。課題設定、ワークフロー、評価基準は教材としての提案で、出典元が実験した結果ではありません。更新されるAPI・料金・投稿規則は利用時に再確認します。

• Three.js Mesh — メッシュは形状とマテリアルを組み合わせる
• Khronos glTF — 実行環境へ3Dアセットを配布する形式の位置づけ

制作の流れを読む

1. 1目的と読者
2. 2素材の仕様
3. 3シーン
4. 4実行環境または書き出した動画
5. 5納品の確認

自作の工程図。矢印は確認の順番を示し、非公開モデルの内部構造を表すものではない。