構造認知 番外編 #3

AI創作環境を設計する

― フォルダ整理ではなく「認知」を設計するという考え方 ―

最近、ComfyUIを導入し、AIイラストの作成（というか勉強）を始めた。

NovelAIという選択肢もあった。しかし、Checkpointという概念そのものが私の認知と非常に相性がよかったため、ComfyUIを選択した。

最初は「画像を生成するソフト」という認識だったが、使い始めて数日で考え方が変わった。

私が設計したくなったのは、AIではなくAIを使う人間の認知だった。

AIは道具である

ComfyUIは非常によくできたソフトウェアだ。

しかし、毎回

• ComfyUIを起動する

• Outputを確認する

• Workflowを保存する

• Checkpointを追加する

• LoRAを管理する

この一連の流れを考えると、

「フォルダを開く」

という行為そのものが認知コストになっている。

つまり、

AIより先に、人間が迷っている。

フォルダ整理ではなく操作設計

一般的な構成はこのようになる。

ComfyUI
├─models
├─output
└─workflows

もちろん間違ってはいない。

しかしこれは

データをどこへ置くか

という設計である。

私は少し違う視点で考えた。

人間はどう操作するのか？

ランチャーという発想

例えば

ComfyUI
├─▶ Run ComfyUI
├─📁 Output
├─📁 Workflows
├─📁 Models
└─📁 Character

これは実体ではない。

すべてショートカットである。

つまり

Storage
    ↓
Launcher
    ↓
Operation

という構造になる。

私はこれを

操作レイヤー

と呼びたい。

Characterという単位

ここでさらに面白いことに気付いた。

Character Prompt と LoRA は別物である。

Prompt は

「キャラクターの定義」

LoRA は

「キャラクターの実装」

だから

Character
├─Character_A
│   ├─Prompt
│   ├─LoRA
│   ├─Reference
│   └─History
│
└─Character_B
    ├─Prompt
    ├─LoRA
    ├─Reference
    └─History

という構造が自然になる。

あるいは

Character
├─OriginalCharacter01
└─OriginalCharacter02

でもよい。

重要なのは名前ではない。

Characterという単位で

Prompt・LoRA・Reference・履歴を一つの概念として管理することである。

これはオブジェクト指向にも似ている。

Characterという概念の中へ

必要なものを集約する。

LoRAは差分である

LoRAは新しいAIではない。

Checkpointへ追加される

「差分データ」

である。

だから私は

LoRAを

「学習モデル」

ではなく

「パッチ」

として認識した。

Windows Updateが変更点だけを配布するように、

LoRAも変更点だけを保持する。

世代管理

すると次に考えたくなるのは

世代である。

例えば

Character_A
├─v1.0
├─v1.1
├─v1.2
└─v2.0

こう管理すると

何が改善されたのか

何が退化したのか

履歴が分かる。

これはGitのようでもあり、

ソフトウェア開発にも似ている。

さらに

CHANGELOG

v1.1
・髪型修正

v1.2
・瞳修正

v2.0
・表情改善

まで残せば、

Characterそのものの進化を追跡できる。

Promptも資産になる

Promptは一回使って終わりではない。

Character Prompt

Style Prompt

Scene Prompt

Expression Prompt

これらは全て再利用できる。

つまり

Promptもまた

資産（Asset）

になる。

構造認知から見たAI創作

AIイラストを始めると

モデルを探し

LoRAを探し

Promptを書き始める。

しかし私は

先に

構造

を設計した。

それは

AIのためではない。

人間が迷わないためである。

フォルダ命名規則を書いた時もそうだった。

重要なのは

名前ではない。

認知コストを減らす構造である。

※「なぜフォルダ命名ではなく"認知コスト"という考え方になるのか」については、以前まとめた 『構造認知 #10』 に関連します。興味のある方は、先にそちらを読んでいただくと、本記事の意図がより伝わりやすいかもしれません。

AIDEという考え方

プログラマにはIDE（Integrated Development Environment：統合開発環境）がある。

• Visual Studio

• Eclipse

• VSCode

• マイナーなものではHEW（High-performance Embedded Workshop）

など。

これらは

「プログラムを書く環境」

である。

ならば

AI創作にも

「AIを創る環境」

があってよい。

私はこれを

AIDE（AI Development Environment）*

と呼ぶことにした。

AIDEとは、

• Character

• Prompt

• LoRA

• Workflow

• Model

• Output

これらを

人間の認知構造に合わせて設計・管理する統合環境

という考え方である。

AIそのものを設計するのではない。

AIを扱う人間の認知を設計するのである。

フォルダは情報ではなく「認知」を設計する

ここで一つ、面白いことに気付いた。

私が設計していたのは

フォルダではなかった。

AIでもなかった。

認知そのものだったのである。

一般的には

ComfyUI
├─models
├─output
└─workflows

という構造で終わる。

しかし私は

ComfyUI
├─▶ Run
├─📁 Output
├─📁 Models
├─📁 Workflows
└─📁 Characters

という

操作の入口

を設計したくなった。

つまり

ファイルを整理したいのではない。

人間が

「何をしたいのか」

という行動を整理したかったのである。

これはフォルダ設計ではなく、

認知設計

と言った方が近い。

最後に

私は珍しいAIの使い方をしているつもりはない。

珍しい認知はしているとは思う。

だから

フォルダを見ても

「データ」

とは認識しない。

「人間がどう操作するか」

を考える。

それが結果として

ランチャーになり、

Character管理になり、

LoRA管理になり、

AIDEという考え方へ繋がった。

AIはこれからも進化する。

Checkpointも変わる。

LoRAも増える。

Workflowも複雑になる。

だからこそ、

管理する対象はAIではなく、

人間の認知である。

私はこれからも

構造認知という視点で

AI創作環境そのものを設計していきたいと思う。

* AIDE（AI Development Environment）

AI創作に必要なキャラクター、プロンプト、LoRA、モデル、ワークフロー、出力を、人間の認知構造に基づいて設計・管理するための統合環境。

AIDEという名前は、AIとIDE（Integrated Development Environment：統合開発環境）を掛け合わせて生まれた造語である。

しかし私にとって重要なのは名前ではない。

AIを設計するのではなく、AIを扱う人間の認知を設計する。

その思想そのものを、私はAIDEと呼びたい。