GENERATIVE ART / CODE / DESIRE
ジェネラティブアートとは?
ジェネラティブアートは、形や音を生み出す手順や仕組みを設計し、その働きから作品を作る表現です。手順は人が手作業で進めることも、コンピュータに実行させることもあります。規則、状態、入力、時間、乱数、描画をどう組み合わせるかを読むことで、作品の生成と鑑賞者の経験を分けて考えられます。
短く答えるなら
ジェネラティブアートとは、形や音を生み出す手順や仕組みを設計し、その働きから作品を作る表現です。手順を人が手作業で進める場合も、コンピュータに実行させる場合もあります。機械学習を使う作品に限らず、数式や規則、乱数、入力を使う方法もあります。YOKUDŌの背景やギャラリーの描画では、Canvas 2D、Simplex Noise、粒子、ポインター、スクロール、入力文字、表示状態、モーション設定が組み合わさっています。そこから「コードが欲望を感じる」とは言わず、欲望を読むための動く条件として分析します。
手順を設計し、実行し、選ぶ
ヴェラ・モルナールは、1990年の展示カタログに収めた文章「Inconceivable Images」で、単純な幾何学形と規則を使い、要素の比率や組み合わせを少しずつ変えた画像群を比べ、その一部を選ぶ制作について記しています。実際のコンピュータを使う前には「想像上の機械」を思い描き、限られた系列を自分で一段ずつ実行していました。出力を生む規則と、どれを作品として残すかという選択は、別々の制作判断として現れます。
ヴィクトリア&アルバート博物館は、コンピュータ以前のアナログなアルゴリズムからデジタルアート史をたどります。モルナールが1968年にソルボンヌ大学のコンピュータ・ラボでFORTRANを学んだ実践では、ペンを持つプロッターの腕が指示に沿って動き、紙に幾何学的な線を描きました。規則を準備する人、指示を実行する装置、紙に残る出力は、それぞれ異なる役割を持ちます。
ホイットニー美術館の2024年展覧会は、Harold Cohenが自身の芸術上の知識や制作過程をAARONのコードに移し、制作を協働として考えたことを紹介しています。AARONは描画・彩色装置を通じて紙に出力したり、モニターやプロジェクションに画像を表示したりします。Cohenはコンピュータの指示を解釈して描くプロッターや絵画装置も製作しました。この歴史は、作者が設計した手順と装置の実行をめぐるもので、現在のプロンプト型画像生成AIと同じ仕組みではありません。
こうした例から、規則を設計すること、手順を実行すること、結果を選ぶことは別々の制作上の判断だと分かります。YOKUDŌのCanvasは、時間や入力の条件に応じて画面内の描画を更新しますが、紙を走るプロッターとは出力も条件も異なり、モルナールやCohenからの影響を示すものでもありません。以下では、YOKUDŌの仕組みにある手順、入力、時間を分けて見ていきます。
YOKUDŌを五つの層に分けて読む
| 層 | 原版で確認できるもの | 視覚への働き | そこから言えないこと |
|---|---|---|---|
| 規則 rule | Simplex Noise、角度、速度、色相、複数の描画関数 | 線がどの方向へ進み、どの色へ移るかを制約する | 規則だけで作品の意味や作者の心理が決まること |
| 状態 state | 粒子の位置、前の位置、寿命、スクロール量、エネルギー、波紋 | 同じ画面でも時間と入力によって次の画面が変わる | 画面に現れた形が一つの固定作品であること |
| 入力 input | pointermove、pointerdown、スクロール、文字入力、チップ、送信ボタン | 見る人の動作を粒子、文字、波紋、速度へ接続する | 操作した人の欲望が測定・診断されること |
| 描画 rendering | Canvas 2D、stroke、fill、合成、グラデーション、DPR調整 | 計算上の状態を線、光、粒子、残像として画面化する | CanvasのAPI名だけで美的な意味が説明できること |
| 時間と配慮 lifecycle | requestAnimationFrame、可視性、フォーカス、IntersectionObserver、reduce motion | いつ動き、いつ止まり、いつ静止画に替わるかを決める | 動き続けることが作品の価値や没入を保証すること |
この表は原版コードの読解結果です。実行環境、ブラウザ、端末性能、入力装置によって見え方は変わります。コードに書かれていない作者の意図や鑑賞者の内面を補っていません。
Canvas 2D:画像ではなく、描画の場
HTMLのcanvas要素は、コードが図形、線、文字、画像などを描くための領域です。YOKUDŌの背景では、画面サイズと端末のDPRを読み、2Dコンテキストの変換を設定してから、暗い背景、粒子の線、光のグラデーション、波紋を重ねています。
ここで大切なのは、Canvasが「意味のある絵」を自動的に発見する魔法ではないことです。Canvasは線を引き、色を塗り、透明度や合成方法を適用する道具です。何を描くか、どの状態を残すか、どこで消すかはコードの設計にあります。描画APIの機能と、作品の読解を一つにしないことで、技術の説明が美学の決めつけにならずに済みます。
背景の主な描画では、前の粒子位置から現在位置へ短い線を引き、少し透明な背景を重ねることで残像のような流れを作ります。線が何度も更新されると、画面は一枚の静止画ではなく、状態の履歴を薄く抱えた場になります。
ノイズとFlow Field:偶然ではなく、方向の分布
原版はSimplexNoiseを使い、粒子の座標と時間から値を得て、それを角度へ変換しています。各粒子はその角度に沿って進み、スクロール位置によって色相と速度の範囲も変わります。これが、画面全体に一本の線を描くのではなく、多数の小さな線が場の方向を共有するような流れを作ります。
ノイズは、完全な白色雑音のように各点が互いに無関係な値を返すものではありません。近い座標の値がなめらかに変わるため、粒子の方向にも連続した偏りが生まれます。とはいえ、そこから自然界の血流や人間の欲望が正確に再現されるわけではありません。似て見えることと、同じ仕組みであることを分けます。
ギャラリーの小作品では、vein、knot、ring、vortex、rain、bloom、tide、dreamというデータ属性ごとに描画関数が選ばれます。Flow Field、Lissajous、Pulse Rings、Attractorなどの名前は、作品を科学的に分類する診断名ではなく、生成手順を読者へ示すラベルです。
乱数と再現性:同じ作品はどこまで同じか
生成アートで「ランダム」と書かれていても、すべてが同じ種類の偶然とは限りません。YOKUDŌの背景では、粒子の初期位置や寿命にMath.random()が使われます。一方、ギャラリーの各Canvasには、作品名の長さをもとにした値からmulberryという乱数関数へseedを渡しています。
つまり、背景のライブな場と、ギャラリーの一度描く小作品では、再現性の設計が異なります。seedがある部分は同じ条件を比較しやすく、実行時の状態や入力がある部分は同じコードでも経路が変わります。ここから「毎回まったく同じ絵」や「完全に予測不能な絵」と断定しないことが重要です。
この差は、作品を保存する方法にも関わります。画像ファイルだけを残すのか、コード・seed・入力・時刻・ブラウザ条件まで記録するのかで、保存される作品の単位が変わります。ジェネラティブアートでは、結果だけでなく、結果を生む条件も作品の一部として読めます。
入力は装飾ではなく、鑑賞の関係
YOKUDŌの背景は、pointermoveでポインター位置を受け取り、近くの粒子に接線方向の力と光の広がりを加えます。pointerdownでは波紋が生まれ、タイトル上の移動は条件に応じて文字の粒を発生させます。テキスト入力やチップ、送信ボタンも、入力された文字を画面へ遅れて現す処理につながっています。
この仕組みは、鑑賞者を画面の外に置かず、入力を次の状態の一部にします。しかし、入力文字やポインターの動きから、ユーザーの欲望の種類・強さ・人格を測っているわけではありません。入力はイベントであり、診断データではありません。
Pointer Eventsは、マウス、ペン、タッチなどの異なるポインターを共通のイベントモデルで扱うための仕組みです。技術的に入力を共通化できることと、すべての身体経験が同じになることは別です。画面を触れること、動かすこと、見ていることの差を残したまま、インタラクションを読みます。
入力を離したあとに残るもの
ラファエル・ロサノ=ヘメルの《パルス・ルーム》(Pulse Room, 2006)では、参加者がセンサーを握ると心拍が捉えられ、最も近い電球がそのリズムで点滅します。手を離すと照明はいったん消え、点滅のパターンが隣の電球へ移ります。次の参加者の心拍パターンが先頭に加わると、先に並んでいた点滅も位置を移し、作品は最近の参加者の痕跡を電球の列として見せます。
YOKUDŌでは、ポインターで生まれた波紋は透明度を下げて消え、文字の粒子は進行を終えると描画から外れます。《パルス・ルーム》では、いま操作していない参加者のリズムも点滅の列に組み込まれています。入力を映す時間の長さと、次の入力による残り方に、異なる設計があります。
鑑賞するときは「触れた直後に何が変わるか」に加え、「操作を終えたあとに何が残るか」「次の入力が先行する痕跡をどう変えるか」を見てみると、反応の速さだけでなく、作品が組み立てる時間も読めます。
時間・可視性・モーションの境界
原版のアニメーションループは、requestAnimationFrameで次の再描画前に処理を予約し、前回からの時間差を使って粒子を進めます。ページが見えない、ウィンドウがフォーカスを失う、背景Canvasが表示領域から外れるときは、実行を止める条件が入っています。これは演出のためだけでなく、不要なCPU・電力消費を避けるためのライフサイクルです。
prefers-reduced-motion: reduceが有効な場合、原版は連続アニメーションを動かさず、静止的なフレームを描きます。動きを完全に同じ量で届けることより、見る人の環境設定を尊重しながら作品への入口を残すことを優先しています。動いていることを体験の条件にしすぎないのも、生成アートの設計です。
ギャラリーのCanvasはIntersectionObserverで表示領域に入ったときに描画されます。最初から全作品を同時に計算するのではなく、視界との交差を合図に処理する設計です。時間と注意力は無限ではないという前提が、作品の裏側にもあります。
アルゴリズムは欲望を感じない
「欲望をアルゴリズムで描く」という言い方は、コードの内部に人間と同じ欲望があるという意味ではありません。欲望という言葉は、粒子の接近、分岐、反復、入力への反応、消滅、再出現を読むための人間側の比喩・問いです。
コードから確実に言えるのは、どの変数が状態を持ち、どのイベントが値を変え、どのCanvas APIが結果を描くかです。そこから作者の幼少期、鑑賞者の性格、作品の唯一の感情を復元することはできません。実装事実、作品の印象、批評的な解釈を三つの層として残すことで、生成アートを占いへ変えないようにします。
YOKUDŌの読み方
欲動 YOKUDŌは、背景のflow field、粒子、文字、波紋、スクロール、ギャラリーの複数のCanvasを重ね、欲望を一枚の象徴へ閉じません。作品本体のコードを読むことは、見た目を普通の説明図へ置き換えることではなく、動きがどの条件から生まれるかを知ることです。
作品本体の表示を見ながらコードを読むのは、動きの条件と、その動きが持つ意味を分けて考えるためです。粒子やポインター、時間が画面をどう変えるかは手順から追えますが、その流れを不安、期待、抵抗として受け取る経験までは決まりません。表示を鑑賞することと仕組みを知ることを行き来すると、技術の説明に意味を固定させずに済みます。
読解と安全の境界
- ジェネラティブアートをAI画像生成と同一視しない。Canvas、数式、ノイズ、乱数、入力など複数の方法がある。
- コードから作者の意図、鑑賞者の欲望、心理、性的指向、診断結果を推測しない。
- 実装事実と、作品をどう感じるかという解釈を分ける。コードに書かれていない意味を確定しない。
- Canvas、入力、アニメーションは端末・ブラウザ・設定で変わる。特定の見え方を全員に保証しない。
Sources
- 欲動 YOKUDŌ(作品本体) — Canvas 2D、Simplex Noise、粒子、Pointer Events、入力文字、IntersectionObserver、reduced motion、ギャラリー描画関数を読み解く対象。
- Rafael Lozano-Hemmer, “Pulse Room” (2006), project description — 参加方法、心拍センサーと電球の点滅、参加者の痕跡が列の中で移る仕組みについて、作家による作品解説を参照。
- Vera Molnár, “Inconceivable Images” (1990 exhibition catalogue statement), DAM — 規則、要素の小さな変化、系列の比較と選択、想像上の機械についての作家自身の記述を参照。
- Victoria and Albert Museum, “Digital art” — コンピュータ以前のアルゴリズム、1960年代のFORTRAN学習とプロッターによる描画の紹介を参照(2024-04-17更新)。
- Whitney Museum of American Art, “Harold Cohen: AARON” exhibition overview (2024-02-03–2024-05-19) — Cohenの制作過程、AARONの画像出力、描画・彩色装置についての展覧会解説を参照。
- MDN Web Docs, CanvasRenderingContext2D — Canvas要素の2D描画コンテキスト、線・文字・グラデーション・合成を確認する公式リファレンス。
- MDN Web Docs, Window: requestAnimationFrame() — 再描画前のコールバックと時間差を使うアニメーションの基礎を確認する公式リファレンス。
- MDN Web Docs, Using Pointer Events — マウス、ペン、タッチを共通に扱うPointer EventsとCanvas入力の基礎を確認する公式ガイド。
- MDN Web Docs, prefers-reduced-motion — 端末利用者の動きの軽減設定を検知し、アニメーションを減らすための公式リファレンス。
- MDN Web Docs, IntersectionObserver — 要素とviewportの交差を非同期に監視し、可視性に応じて処理を始める仕組みを確認する公式リファレンス。