--- title: 一般性とドメイン固有性 description: " 加藤淳 さんとの雑談のまとめ。文章としてあまりまとまってない。 むしろ研究としての一般性を求めるがゆえに、生の創作現場で起こっている有象無象のわちゃわちゃを（スライダーツールのように）モデルとして単純化していたことへの自省として Griffth や SIGCCC (Special Interest" date: 2024-06-15T15:34:36.000Z updated: 2026-01-08T14:51:00.652Z tags: - diary - Memo url: https://baku89.com/Jun_16%EF%BC%8C_2024%EF%BC%9A_%E4%B8%80%E8%88%AC%E6%80%A7%E3%81%A8%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E5%9B%BA%E6%9C%89%E6%80%A7 --- # 一般性とドメイン固有性 [加藤淳](/jun-kato)さんとの雑談のまとめ。文章としてあまりまとまってない。 むしろ研究としての一般性を求めるがゆえに、生の創作現場で起こっている有象無象のわちゃわちゃを（スライダーツールのように）モデルとして単純化していたことへの自省として[Griffth](https://dl.acm.org/doi/10.1145/3613904.3642121)や[SIGCCC (Special Interest Group on Creativity and Cultures in Computing)](https://chci.pages.dev/chi2023)のようなご活動があるのかなと考えていました。一般性の乏しさが良くないというよりは、ある特定の地域や文化に偏った研究がツールという形に結実し、それがあまりに広範に画一化圧力として作用していることが良くない。（e.g. 仏製のTVPaint）そのためには、抽象化された枠組みでもって多様性を包含しようとするのではなく、別の固有性、パースペクティブを無数に立ち上げ続けることで、その絶対性を脱構築し、権力性を簒奪する必要がある。そして創作支援に携わる研究者は、そうしたサブジャンルや個別具体的なシーンへの思い入れをどこかで引き受けるべきなのではないか。というアジテーションとして[加藤淳#icon](/%E5%8A%A0%E8%97%A4%E6%B7%B3#icon)さんの研究を捉えていた節がありました。 一方で、ツール開発者として、現場の要求に具体的な形で答えてしまうほど、その現場の中から生まれ得たかもしれない多様な発想の種を、ツールが規定する潜在空間の内側に閉じ込めてしまう可能性を孕むことになります。例えば撮影処理における照明効果の自動化をグラデーションとディフュージョンベースのフィルター処理としてハードコードしてしまうと、ハッチングのようなノンフォトリアリスティックな陰影表現が難しくなってしまう。いや、これが難しいぞ！と現場がフィードバックとして突き上げてくれるうちはまだマシでかもしれません。恐ろしいのは、そうした機能を現場が深く内面化した結果、「じゃない」ことをやろうとする選択肢自体が作り手の脳内から取り去らわれてしまうことのほうです。 顧客の声に耳を傾けながらアドホックに機能を追加していくという従来のプロダクト開発の方法論は、一見ユーザーを尊重しているように思えるかもしれません。眼前に示されたプロダクトを弄くり回しながら沸いて出た感情の中で、言語的に分節可能な形で表出した意見しか取り込むことが出来ないのです。そうして開発者自身も気づかないままにツールの中に立ち現れた[normative ground](/normative_ground)によって使い手の発想が少しずつ狭窄され、そこから絞り出される要望が個別具体的なままにツールに実装され、それ再び作り手に渡る。そうしたフィードバックループの中で、ツールと使い手との双方に必ずしも良くない意味での共進化、収斂進化をもたらしている、というのが僕の見立てです。 ![](https://wp.baku89.com/wp-content/uploads/2021/01/terrain_6.gif) ソフトウェア開発者は常々「魚を与えるか」「釣具を与えるか」との間で常に揺り動いてきました。ことさら創造性支援ツールのような、目的達成のための手段としてだけではなく、道具をあてもなく弄り回しながら、偶発性と作為との間で目的そのものを使い手が探索的に紡いでいくような世界においては、その釣具がもつアフォーダンスに対して開発者は一層意識を持つ必要があると思っています。確かにその釣具は、魚を釣りたいという漁師のニーズをさしあたり叶えてくれます。だけど、その便利さは、漁師が釣ろうと思う魚介の種類を将来にわたって無意識レベルで規定してしまうかもしれない。本当は釣具を自作するための冶金・鍛冶技術こそを与えるべきじゃないのか。そうはいっても漁師はあくまで魚を捕ることが本懐であって、鍛冶屋じゃないし…。そういう難しさがデザインツール設計にはありますよね。加藤さんは道具鍛冶研究者を名乗られていますが、本当はその鍛冶技術自体を、道具の使い手に対し、文字通り「ソフトウェアの可鍛性」（[Malleable Software](/Malleable_Software)）として開放していかなくてはいけないという課題意識をもお持ちだと思います。 かといって、いきなりプログラミングというハードコアな鍛冶技術を伝授するのも現実的じゃありません。その一つの解決策がUNIX思想のようなモジュラー性の導入かもしれません。組み合わせる対象として使い手が意識すべき機能の粒度をある程度高めることで、使い手の意識を「アルミ塊」という物質性にではなく、「リール」や「竿」といった漁具のDIYに必要十分な構成単位へと向けることが出来る。漁具が取りうる可能空間全体に比べると、その組み合わせ順列がもたらす直積空間ははるかに小さいですが、それでも魚を釣るという究極の目標を邪魔すること無く、ツールに関する主権を作り手に明け渡すことができます。しかしそれは同時に、どの程度のモジュラー粒度が望ましいかに恣意性が残ることを意味します。Rustのようなコンパイラ言語と異なり、GUIベースのアプリケーションにおける機能の抽象化、モジュラー化のコストはゼロじゃない。 ![](https://scrapbox.io/files/666dc63d30d129001c81c23b.png) 可鍛性のある道具は、初めから一体成型されたものに比べて確実に性能も落ちるし、得てして不格好なものになります。例えばモジュラーシンセをアコーディオンのように手に抱えて演奏することは出来ないし、LEGOのBrainstormで作ったラジコンは既製品に比べて剛性に劣る。もちろんこの例えはハードウェアゆえの限界でしかありませんが、僕はソフトウェアにおいても道具としての「剛性」のようなものはあると思っています。ことさらアニメのようなイメージが絡む表現に関しては、ローレイヤーな最適化、具体的な目的に適った機能設計が欠かせません。どれだけNumPyやOpenCVを使うことでプロセッサの持つ本来の性能によりモジュラーな形で肉薄できようと、現実的には「ラスター画像のコンポジット」という固有の問題における[よさ](/%E3%82%88%E3%81%95)のチューニングに特化した道具が必要となってくる。そこには作り手への共感と慮る心が試されるわけですが、そこにおける作り手というペルソナの推定が過剰なものになってしまうと、それはツールのnormative groundとして作り手の発想を狭窄してしまう。 ![](https://wp.baku89.com/wp-content/uploads/2026/06/color.jpg) 最近、撮った実写案件の編集のために、DaVinch Resolveを勉強しています。元がカラーグレーディングツールとして開発されたのもあり、カット編集における色調補正においてはとてつもなく快適に動くんです。だけど、大概僕がやりたいのって、カット同士が映像の最初から最後まで癒合しているような技法だったりするんで、Resolveが前提とするモンタージュ技法という表現空間からはあぶれてしまった。だから、より柔軟性の高いFusionやAfter Effectsをコンポジットにも色補正にも使うことにしたのですが、モジュラー性の高いゆえに、Resolveほどのハードウェア最適化がなされていないんですよね。確かにトーンカーブもカラーホイールもある。機能的には不足ない。だけど、Resolveみたいにグレーディングに必要なUIがパネルとしてハードコードされていないために、エフェクトパネル上からいちいちツリーを展開しないと色調補正パラメーターにたどり着けない。あとほんのちょっとプレビューがラグい。そんな些細な手触りの積み重ねが、どこかで[よさ](/%E3%82%88%E3%81%95)の最適化の山登りのラストワンマイル、ワンメーターの見極めを面倒くさがらせるよう作用している実感がどこかであるんですよね。そしてそこで詰めきれなかったクオリティというのが、薄っすらと作品全体をスポイルしているのではないか、と。 そんなことをウジウジと考えるうちに、いっそのことプログラミングを通してメタメディアとしてのコンピューターの可能性なんてものに気づきとうなかった、なんて気持ちにもなったりします（笑）　だったらAdobe製品になんの疑問を抱くこともなく、晴耕雨読な心持ちでチマチマと制作に打ち込めたのに、と。実際、映像業界で仕事をする上で、ツール開発が出来て、色んな実験をしたくなってしまうこの気質は、必ずしもキャリアとしていい方向には作用していないですからね。（いや、その気質が悪いというよりも、その実験性に適った説明力や自己管理能力が無いのが悪いというのも自覚しています。メディア・アーティストがどれだけ自分の構想のプレゼンテーションの為に手を尽くしているかを鑑みると、人に説明するのも面倒だし期限も設けず独りで手を動かそっか、とつい考えてしまう自分の癖はとても褒められたものではないです。） さっきから同じようなテーマを繰り返し言っているような気がしますが、問題は「malleableかどうか」ではなく「どの程度malleableであるべきか」にあると思います。ツールの作り手と使い手との間の権力勾配をあぶり出す、ツールの主権を使い手に取り戻すのは大切です。だけど、その主権には責任と、そして認知負荷をも伴います。 > **前提4**\ > 「どの程度コントロール可能な要素を知覚しようとするのか」という最上位パラメータから逃れることはできない。 > > _[第２回　コントロールについて１ アノーイング・クリエーション /](http://www.kaminotane.com/2024/04/03/25654/) [細金卓矢](/%E7%B4%B0%E9%87%91%E5%8D%93%E7%9F%A2)_ ある意味で、[malleable software](/malleable_software)というのは、そうした知覚を使い手に強制するという権力性をも孕むのかもしれません。現代美術やメディアアートのように「巧さ」が脱構築され、職人的技芸よりも思弁性が重視されるような分野と異なり、アニメはある種の様式、美的体系を引き受けたうえで、その中の至高の局所解に向けて猛進するジャンルといえます。そして一つの憧れに向けて、反復的な鍛錬を通してでしか到達し得ない凄み（=神作画、神演出）が価値とされる世界です。信じるものへと突き進むにあたって、「じゃなさ」の可能性の広さを知り、その上で自由を手放すのと、初めからその可能性すらチラつかずに成すべきことに集中出来るのとでは、実は後者のほうが作り手のQuality of Lifeは高いのかもしれません。現に僕が前者が故に作り手としてはイップスになっているわけですし。そもそもそうした不自由さ、視野狭窄の中で引き起こされるハレーションと先鋭化こそが、畢竟「シーン」と呼べるものなのではないかとすら思ったりもします。その道具が規定とする表現空間に揺るぎない信頼があるからこそ、人はF Majorを練習するし、盤にも針にもダメージがあるのを承知でターンテーブルでスクラッチをする。音楽経験無いのでだいぶ適当言ってますが。 話がとっ散らかっちゃいましたが、研究としての一般性とドメイン固有性、ツールとしての剛性と可鍛性との狭間で、無批判にいずれかを称揚するわけでもなく、[自己反映的](https://garden.matsuuratomoya.com/%E8%87%AA%E5%B7%B1%E5%8F%8D%E6%98%A0%E6%80%A7)な（[reflection](/reflection)）態度をもってして開発に望む日々のプロセス自体が、成果物と同じくらい実りのある経験になりそうだなと期待しています。ムチャクソつまらない締めですみません。