AIと表現媒体の相性考察 (2026-05-16)
Piとの対話より。LLMの音楽生成の難しさから発展し、AIが得意とする表現領域と不得意な領域、そしてツールとの統合の理想形まで議論した。
発端: 音楽生成はなぜ難しいのか
オープンソースの音楽生成LLM「ACE-Step 1.5」を試したが、音楽は言語による指定が難しい。 ACE-Step 1.5の公式にプロンプトのコツが書いてあるが、思い通りになる感じがあまりなかった。
- データの課題: 音楽は「離散記号（MIDI/音符）」と「連続波形」の両方を扱う必要がある。著作権の壁が厚く、ラベリングコストが高い。
- 評価が難しい: 好みの個人差が大きく、客観評価が確立していない。
- 時間軸構造: 30秒〜3分の構造物を1発推論で仕上げるのが難しい。自己回帰か拡散か、どちらにもトレードオフがある。
画像・動画生成の難しさ
「プロンプト入れれば出てくる」は簡単だが、意図したものを出させるのが桁違いに難しい。
- 構図の指定が苦手（「右手に剣、左手に盾」を確実に守らせられない）
- ControlNet / IP-Adapter でガイドしても想定外のディテールを埋めてくる
- 動画は数秒のクリップは出せてもテンポやカット割りのコントロール手段がほぼない
- トークン（時間フレーム）増加に伴う推論コスト爆上がり
- 現状は「良いとこ取りの短いクリップを大量生成→選別→つなぐ」ワークフローが主流
自然言語プロンプトの本質的限界
- 表現の解像度が低い: 「左上に大きめの雲を入れて」がモデル内部でどう解釈されるかはブラックボックス
- 詳細すぎるプロンプトはむしろ逆効果: モデルの自由度を奪い、平均的で面白みのない出力になる
- シンプルなプロンプトのほうが良い結果が出る傾向: モデルが解釈の余地を持ち、予想外の良い補完が生まれる
結論: AIに求めるべきは「人間の代わりに細かく指示を実行するロボット」ではなく、「こちらの意図を汲んで適宜補完してくれるパートナー」。
生成AIのツール統合という方向性
Krita AI Diffusion が理想形
- レイヤー構造に統合 → キャンバス上で選択範囲を塗ってInpaint、マスク管理も既存のレイヤーシステムで完結
- 既存の描画操作とシームレスに混ざる → 自分で線画を描いて苦手な部分だけAIに塗らせる
- ControlNetをGUIで設定可能 → 線画保持・ポーズ固定などの制約を直感的に与えられる
- プロンプトはあくまで補助: 主役はツールの操作
「AIが主役で人間はプロンプトを打つだけ」ではなく、「人間が主役でAIは普段使ってるツールの中で自然に使えるアシスタント」 という形。
生成AI専用ツールのジレンマ
- ComfyUIはノードベースで強力だが、「AI生成のためのツール」であって「絵を描くためのツール」ではない
- ノードを組むことが目的化し、できあがった画像よりノードが動いたことに満足してしまう
- 一方でBlenderのノードも同様の壁があるが、ジオメトリノード・シェーダーノードは制作ツールの系統として理解できる
AIとの相性マップ
| 得意（言語・数値で記述可能） | 不得意（連続的・感覚的） |
|---|---|
| テキスト生成・要約 | 画像の構図制御 |
| コード生成 | 音楽の時間構造制御 |
| Webデザイン（HTML/CSS） | 動画の一貫性維持 |
| TTS（言語→音声） | ラスター画像のピクセル単位編集 |
| SVG・ベクター画像 | 複雑な物理シミュレーション |
| 3D（数値パラメータ） | 連続的な「感じ」の調整 |
| Webアニメーション（CSS/JS） | 長尺の自然な音声生成（←もうすぐ来る） |
得意な理由
- 出力が離散的で検証可能（動く／動かないが明確）
- 編集・リファクタリングが前提の世界（生成結果を部分書き換えできる）
- バージョン管理・差分管理が効く（Git）
- モジュール性・抽象化との親和性が高い
不得意な理由
- プロンプトの解像度と操作の精密さにギャップがある
- 修正が「ピクセル単位」や「波形単位」になりがちで、意図の伝達が困難
- 「思い通りにしよう」とするほど細かくプロンプトを書き、結果的に面白みを殺すジレンマ
3D・ベクター画像の可能性
- SVGは数値で定義されたパス・制御点・色情報の集合 → コードと同じ扱いができる
- 3D（GLTF/OBJ）はメッシュ頂点座標・マテリアル数値・ボーントランスフォームが全て数値
- BlenderのPython APIが充実しており、AI→Python→Blender操作のパイプラインが組みやすい
- 「この曲線をもう少し左に」「この角のRを10pxに」が厳密に意味を持つ
TTSと言語との関係
TTS（Text-to-Speech）がここ数年で劇的に品質向上したのも、言語が絡むから。
- テキストという離散的入力 → 音声という連続的出力
- 入力テキストと言語モデルがあることで「文脈を読んだ抑揚」が付けられる
- 画像や音楽の「こういう感じ」という曖昧さがない分、学習と制御がしやすい
Irodori TTS（2026年話題の日本語特化TTS）
- 開発者: Aratako 氏
- ライセンス: MIT（商用利用OK）
- モデルサイズ: 500Mパラメータ（VRAM約7.7GB）
- 2モード: 参照音声モード / VoiceDesignモード（日本語キャプションだけで声をゼロから生成）
- 絵文字で感情制御可能（😊 → 嬉しそうに）
- インターフェース: CLI / Gradio Web UI / Python API
AI音声対話の課題
情報効率の観点
- 人間の話す速度: 300〜400字/分
- 人間のタイピング速度: 100〜200字/分
- → 入力は音声のほうが効率的
しかしLLMの1ターンが長すぎる問題
- 自然な人間の会話: 1ターン3〜10秒
- LLMの1回の応答: 100〜300字（TTS再生で30秒〜1分）
- → 「会話」ではなく「一方通行の講義」になる
解決策の方向性
- LLMに短く返す指示 → 「短く」の程度がわからない
- ストリーミング再生＋割り込み機能
- ターン長を動的に調整（話題の複雑さに応じて出力トークン数を制御）
- テキストチャットUIは「人間は好きな速度で読み、好きなタイミングで返す」自由度があり、考察を深める対話には適している
雑感
- 生成AIそのものより、それを囲むControlNet・IP-Adapter・LoRA訓練・フレーム間補完・プロンプト分解といった周辺技術の方が重要になりつつある
- 「完全に思い通りにする」を目指すと自分でやるのが最速だが、「自分の意図の範囲からちょっとはみ出た面白いものを見つける」スタンスなら粗めの指示でAIに出させて拾うほうが生産的
- Web表現はAIとの協業に最も適した領域で、コードがコンパイル可能な設計図になる未来が見える