【雑記】Mesをアイコントーク対応させるためのあれこれ【遅々開発】

Ci-enでも時々取り上げてきましたが、個人的な趣味で脚本に特化した軽量記述言語Mesを研究開発しています。
簡単に説明するなら「セリフをデコレーション（装飾）するように、キャラ名やト書きといった情報をセリフに付与していくような記述言語で、JSONなどの構造化されたデータフォーマットに変換できる」のがMesの特徴です。

詳しく知りたい人はここをみてください

前の記事からもう１年以上過ぎてしまった事実に驚愕してますが、あれからも裏では報告しても何も面白くない実験やらプログラミングを黙々としていました。
新機能の実装というよりは概念実証とか思考実験とか。

そんなある日、Mesをアイコントークに対応させるための概念実証をしていたら、あることに気づきました。

キャラクターデコレーター”＠”が持てる情報はキャラ名だけじゃん……

元々、（舞台や音声ドラマなどを意識した）脚本向けの記述言語として作ってきたので、従来はキャラ名だけで十分だと考えていました。
実際にチャットスタイルの出力はキャラ名だけで良かったので。

ですが、アイコントークでセリフ毎にキャラの喜怒哀楽のアイコンを使い分けたいと思った場合、現状のMesではキャラクター名を「いらにか（泣）」とか「いらにか（怒）」のようにするしかありません。

そうすると「いらにか（泣）」と「いらにか（怒）」は別々のキャラクターとして識別されるので、区別して別々のアイコンに紐づけることができるようになりますが、今度はキャラのセリフを集計しようとするときに「いらにか（泣）」と「いらにか（怒）」を合算するような集計ロジックを別途定義して書き換える必要が出てきます。
（自然言語を柔軟に読み取れる人間なら上記でも、キャラ名＝いらにか、表情＝泣、のように読み取れますが、機械にはパターンを覚えさせる必要があり少し厄介なのです）

まぁ集計が別々に分かれるくらいなら致命的ではないですが、すっきりとしない気持ち悪さが残ります。
（キャラクター名とアイコンの情報という違うデータを個別に保持できていないのが気持ち悪い）

というわけで、この問題を解消するために新しい言語使用の案をいくつか考えました。
その一つがアトリビュート案です。HTMLのタグの属性っぽいイメージです。

＠いらにか ::img=泣きアイコン
生ぎたいっ!!!  //これがセリフ

↓データ構造はこんな感じ？
`
{

Charactor: {
    value: "いらにか",
    img: "泣きアイコン"
},
Dialogue: "生ぎたいっ!!!"

}
`

上記は安直な初期案で、::img="" のような形式だと速記性が悪い（imgを日本語入力のままだと”いｍｇ”のように打ってしまう）ので記述方法はもっと練らないといけません。
そして、記述仕様が変わると解析プログラムも変更が必要になります。
この記述仕様に変更が加わるときのプログラムの修正コストが結構デカイので、どうにか軽減できないかという問題も実証実験したりしています。

完全に趣味の研究開発なので、単に実現することよりも「どうスマートに実装するか」を重視しているため進捗は著しく遅いです。
商業（仕事）だったら絶対にこんなやり方はしないですが、知的好奇心を満たしてスキルを磨くためなので、それを言い訳にして遅々として開発をしています。

実現重視のスピード開発はすでにシンプルMesエディタで散々やったので……

【雑記】会話の思考はシーンに依存している説、それがTL精神汚染の要因？【メディア性質論】

前々からTwitter(現X)のタイムラインに（相手は悪くないけど）不快なポストが流れてくる現象について、個人的に「タイムライン精神汚染」と名前をつけて色々と原因を考えたりしていた。

一応、僕の環境ではTwitterのセーフティーフィルター設定をONにしていて、センシティブなR-18画像やグロ画像は基本的に自分で画像を開かない限り閲覧できないようにしている。
僕の性格上、公序良俗的に閲覧に場所を選ぶようなセンシティブな情報（エロ画像等）を不適切なシーン（例えば外出先のショッピングモール等）で摂取してしまうことにイラッとしてしまうので、事故を避けるためにもフィルターを自主的にONにしている。
アダルト系のリポストが多いフォロワーもリポストをOFFにしていることが多い。

なので”基本的”にはタイムラインにセンシティブな画像が強○表示されることはあまりない。
ただ、完璧には防げていないので稀にフィルターを貫通してセンシティブな画像が流れてくる。

一応誤解のないように前置きするが、「そういうポストをするな！」と言いたいわけじゃない。
僕だってTwitterでエッチな画像みたいときがるので、好きなエロ漫画家さんをフォローしてたりする。
Twitterの規約に違反するようなポストでない限り、そういうポストに罪はないし、センシティブフラグをちゃんとつけてくれている人もいるので、情報を取得する側（自分）が不快にならないようタイムラインを設定・構築することが望ましいと思っている。
SNSは自己防衛が基本だ。

ただ、少し前からある疑問を感じていた。

なぜ投稿を読む時のシーン（状態）で、そのポストに対する好感や嫌悪感が違ってくるんだろうか？

情報を摂取するときの精神状態によって、反応が違ってしまうのはよく知られている。
それがSNSだと顕著に現れているような気がする理由はなんだろうかと考えていた。

それについてひらめいた仮説がある。

まず前提として、人の会話時の思考はシーンにも依存していることを理解してもらわないとけない。
※理解している人は読み飛ばしていいです

会話の思考はシーンに依存している仮説

僕がこのことを学んだのは学生時代に人に近い会話Botを作ろうとした時のこと。
より人に近い思考をトレースしようと思った僕はフレーム問題に悩まされた。

このフレーム問題をざっくり説明すると、「状況を”深く”理解して行動しようとすると考慮すべき事項が多すぎて可能性が無限に発散するため、計算機では演算できなくなる」という話。
これは人間にも起こる問題で、状況を深く理解しようとすればそれだけ時間がかかる。
ただ、人間には「妥協」のような割り込み処理で計算を途中で終わらせることができ、その時点でのベターだと判断した行動を取ることができるので計算が無限に終わらない状態にはならないと考えられている。

ここですごいのは、人間は会話において相手の言葉から瞬時に状況を理解して自分の言葉を導き出しているということ。
しかも、ほぼ無意識のレスポンス速度で会話をしている人が多いのではないだろうか。

当時学生の僕は「なぜ会話で瞬時に結果を出力できるのか？」が疑問だった。
そこで導き出した仮説が「シーンエンジン」だった。
人間は脳の演算エンジンをシーン別に切り替えることで、その状況にあった最適な思考判断ができるようになっているのではないか？という仮説で、今風に言うなら学習モデルを利用シーンごとに切り替えているようなイメージだと伝わりやすいかもしれない。
それまで、自分の思考は1つのモデルであると思っていたが、よくよく観察してみると仮説は結構いい線なのではないかと思った。
なので汎用的な会話モデルよりは、シーンを限定することで、軽量かつ良質な会話モデルが作れると思って、「バレンタイン前日に彼女と喧嘩してしまったのでどうにか仲直りしてチョコをゲットしたいシーン」というギャルゲみたいなアホ設定で同級生の力を借りて、マンパワーで会話パターンを作り込んだ人工無脳を作ったのだった。

この会話パターンを作り込んでいて一番おもしろいと思ったのが、このシチュエーションだとシーンにそぐわない発言は一蹴しても会話が成立するという点。
喧嘩していて怒っている＝理性を多少失っている状態で、関係ない話をしようとすると大抵の人は「いまそんな話してないよね？💢」と反感を覚えるはず。
シーンに関係ない話＝シーンを転換させるような話題をキャンセルすることで、シーン固定ができるという点が非常に面白いなと思った。

そして「シーンに関係ない話＝シーンを転換させるような話題」というのが今回の本題につながってくる。

【本題】SNSでタイムラインを見ている時、我々はどういう状態（シーン）なのか？

長い間、人のコミュニケーションは対面が基本だった。
そして会話には、トークテーマという話者間に共通した前提事項があった。
共通したトークテーマがあるからこそ、話者同士は相手の言葉に備えることが出来た。
インターネット掲示板でも、スレッドタイトル（スレタイ）がトークテーマの役割を果たしていたと思う。
つまり、会話においてシーンを（ある程度）固定することができた。

では、Twitterのタイムラインはどうか。
人によっては趣味別にアカウントを使い分けて、タイムラインをコントロールしているかもしれない。
そういう人は「この趣味（シーン）の話題」としてタイムラインを見ることができるので、投稿を読む時のシーンが定まっていて基本的に同じシーンモデルで思考・会話をしている可能性がある。

対して、趣味別に分けていないようなフォロワーが様々なトークテーマでポストしているタイムラインの場合、投稿を読む時のシーンモデルが定まっていないのでは無いだろうか。
つまり、ポストのトークテーマごとに異なるシーンモデルで思考・会話をしている可能性がある。
リアルに比べてインターネットは状況に関する情報量も少ないため、もしかすると、シーンモデルを適切に切り替えられないまま、投稿を読んで思考している可能性がある。
リアルでも会話のトークテーマが急に切り替わったとき、思考が追いつかずに混乱することはないだろうか？もしくは、誤解したまま話がアンジャッシュ状態になることはないだろうか。
こういう状態がタイムラインを見ている時に発生している可能性がある。

僕の場合、現実のシーンモデルをそのままタイムラインに持ち込んでいる可能性があり、公共の空間（シーン）でタイムラインを見た時にNSFWな画像が強○的に表示されると、公共空間のシーンモデルが強い嫌悪の反応をしている可能性が高い。
逆に寝る前のオフモードな状態で、NSWFな画像が強○的に表示されるとオフモードのシーンモデルではあまり嫌悪しないように思う。

この仮説を元にすると、例えば見る時間帯等によってタイムラインに流すユーザーを制限するだけでも（事故的な）嫌悪や不快感を軽減できる可能性がある。
もっと高度なアイデアとしては、スマホの位置情報などで「家にいる時」「公共施設」「職場」「電車の中」などリアルの状況（シーン）にあわせてタイムラインを構成できたら面白そうだと思ったところで気づいた。

これ、広告と同じ考えじゃん。

「ターゲット」に「適切な環境」で「効果的な情報」を宣伝すること。
言い換えれば、ターゲットの置かれた状況での思考（シーンモデル）をイメージして、効果的だと思う情報発信をすることが（事故的な）嫌悪や不快感を軽減する方法なのかもしれない。
そう考えると、ターゲットのシーンモデルが推察しにくい状態のタイムラインで、プロモーションすることは（事故的な）嫌悪や不快感につながってるのではないだろうか。
※もしかするとTwitterのプロモーションに嫌悪感覚える一因になってるかもしれない

そう考えると、SNSで見ている人が多いと言われる時間帯でもターゲットのシーンが推察しにくい場合では上手く刺さらない、もしくは真逆の反応になってしまうリスクもあるのではないかと思った。
もちろん、このプロモーションの仮説には穴が多くあるので有効性は怪しいが。

ただ、タイムラインにおけるシーンモデル問題は個人的に結構当てはまるので、時間帯やシーンごとにOKなユーザーリストを作ってホームTLの代わりに利用するのを検討してみようと思った。

やはり、メディア特性論に関する思考実験は面白い。

【雑記】ソフトウェアの進化論【遺伝子】

長くソフトウェアの開発をしていると、ある壁にぶつかります。

それは 刷新 とか リプレース など色々な呼ばれ方をしているのですが、より抽象的に言うならば 進化 とか 世代交代 が表現として一番しっくりきます。

アップデートや機能拡張も類似するものですが、それらは 成長 という枠の中にいて、進化とは少し異なります。
皆さんにわかりやすく説明するなら、Windowsの遍歴を思い浮かべてもらうのが簡単かもしれません。
Windows10は月次アップデートで段々と成長していきますが、Windows10からWindows11に変わるようなアップグレードではUIや操作系、機能など様々なものが変わって、明らかにWindows10とは異なるものに進化しています。

一般の方は、なぜこのような進化をするのか疑問に思うかもしれません。
Windows10のままWindows11のように機能拡張することはできないのか。
特に、Windows7からWindows8系への移行では散々な言われ方をされてました。

これらの前提として、そもそもソフトウェア開発は生み出した後が本当のスタート地点であるという特殊さがあります。
現代のソフトウェアはリリースされた後も修正パッチやアップデートなどで、バグを修正したり機能追加したり、成長させることが当然になっています。
逆に不具合などが修正されず、メンテナンスがされていないソフトウェアは忌避される傾向すらあります。

「ソフトウェアはリリース後も継続的にメンテナンス（保守）される」という文化は、ソフトウェアの発展に大きく寄与してきましたが、同時に開発者の負担にもなっていました。
開発者が保守しなくなったことで、使われなくなっていったソフトウェアも沢山みてきました。
（その度に代替になるような派生ソフトウェアが台頭してきたりしました）

たぶん、この記事を読んでいる人も使わなくなったアプリやサービスがあるんじゃないでしょうか。

ソフトウェアの死というのは、誰にも使われなくなることだと思っています。
そして開発者は「自分」と「その他ユーザ」のことを考えてソフトウェアを成長させていきます。
ですが、大きくなりすぎたソフトウェアは次第に成長が遅くなり始めます。

自己を作り上げているソースコードが膨大になり複雑化し、不具合が増え、動作が遅くなり、過去のコードが足を引っ張って思ったように機能が実装できなくなり、Etc...といった感じで、膨大に積み上げてきた積木の上にさらにブロックを積むのが困難になるのはソフトウェアの宿命とも言える問題です。
もちろんこの問題と向き合うための学問や哲学などのエトセトラが多く存在しますが、少し脱線するので割愛します。気になる人はソフトウェア工学で調べてみてください。

こうなってくると、開発者は現状を整理して、より理想的に積み上げたソフトウェアが欲しくなります。開発者の多くは理想状態を好みます。
大抵はリファクタリングと呼ばれる整理・修正作業によって改善を試みますが、手が付けられないような致命的な欠陥があると、最早イチから作り直したほうが一番早いという結論にたどり着くことがあります。
そして、古いソフトウェアから良いものを受け継ぎつつ悪いものを排除した、新しいソフトウェアが生まれます。

これらに生命の進化論に通じる部分があると感じているので、冒頭の表現として進化がしっくりきているわけです。

ここまでの説明で、感の良い人は「ソフトウェアの退化」や「モダナイゼーション（近代化）」が起こることの必然性を受け入れられるかもしれません。
端的に言えば生命ですら現在の環境に最適化しようとして退化のような進化をしてしまうのだから、ソフトウェアでも同様の事が起こりえるということです。

Windows8で不評だったModernUI（MetroUI)は、当時の世界を席巻しつつあったモバイルデバイス（スマホやタブレット）を念頭に開発された経緯があり、WindowsがモバイルデバイスのOSに進出するための試行錯誤でもありました。
マルチデバイスでの統一を図るためにモバイルデバイスにおける当たり前（強○フル画面、横スクロール、タッチ操作など）をPCの世界にも持ち込もうとしたことで混乱が大きかった印象が個人的に強いですが、Windowsにおけるウィンドウの利便性が損なわれていたことが一番の失敗だったと思います。あとWindowsボタンのスタートメニュー。
まぁ話が脱線するので戻しますが、ここで重要なのはWindows8.1以後では操作系やUIをWindows7っぽく戻しつつもアイコンのデザイン面ではWindows8のフラットデザインの要素がモダナイズがされて残った点です。

Windows7からWindows10へ移行する人の中で、当時はよくアイコンのデザインの好き嫌いの話がされていました。
Windows7時代は立体感や質感の強いデザインのアイコンで、iPhoneも初めの頃は同様に立体感や質感の強いアイコンでした。
立体感を出すことで押せるものと認識させる意図があったりしたそうです[要出典]。

フラットデザインへの転換期にあたる2012～2014年頃、PCやスマホなどデバイスによって画面解像度やサイズが多種多様すぎることで、アイコンのデザインは苦しめられていました。
例えばリアルな写真のような128x128サイズのドット絵を16x16サイズにしようとすると、情報の欠如が多すぎて元の絵と印象がだいぶ変わってきます（そもそも同じように表現できないかも）
この問題を解消するため当時はフラットデザインやマテリアルデザインなど、マルチデバイスを意識したデザインがいくつか生まれました。
フラットデザインでは、元がシンプルであるためにサイズを変えても印象があまり変わりません。
ですが以前のアイコンの立体感・物体感が持っていた「押せる印象」がフラットデザインで失われたことで、ユーザの違和感に繋がり、前述の好き嫌い論争の一因になりました。
（一応フラットデザインでは薄いシャドウなどの浮遊感によって押せる印象をもたせていたりします）

このようにアイコンの進化があったおかげで、多種多様な解像度への耐性値があがりました。
もしかすると、この転換が無ければ近年のスマホの超高解像・巨大化は無かったかもしれません。

ユーザは以前のままで良かったと思っていても、開発者側に以前のままではいられなかった理由があったりします。
このギャップが（ユーザー視点での）ソフトウェアの退化につながる一因なのかなと思います。
X（旧Twitter）とか、まさにその例かなと。

Windows8はサポート終了しているので（おそらく）滅びを迎えました。
ソフトウェアとして死んだと思いますが、その遺伝子は残り続けています。

そう考えると、死にゆくソフトウェアたちもどこかに遺伝子を残しているのだろうなと思いました。

了。

【雑記】あっという間に2月が終わった

雑記

あっという間に2月が終わった。
何もしてなかったかというと、そうでもなくて、

シュクメルリ食べたり、
A5和牛の焼肉食べたり、
弘前にクラフトビール飲みに行ったり、
同級生と久しぶりに飲みに行ったり、
喫茶＆バーで飲んだくれたり、

振り返ってみると、結構いろんなことをしていた。

ただ2月はたくさん外に出たことで、考えさせられることも多かった。
そして、プライベートな時間でパソコンを起動しなかったという事実が一番の衝撃だったかもしれない。
一応、仕事ではパソコン使うし、日常生活ではスマホとかタブレットは使っていた。
なのであまり共感はしてもらえないかもしれないが、プライベートな目的でパソコンを全く使わないというのは「ずっと一緒だったテディベアを失くしてしまったのに、他のおもちゃでも日常を過ごせてしまう。でも高度に遊ぶ習慣が消え失せた」みたいな感覚だった。

正直、スマホ（タブレット）とパソコンそんな変わらないやろという人も多いと思う。
でもパソコンは日常の様々なことのハックに使いやすいのが楽しい。

例えばCi-enのマイページにNSFW画像が表示されるのを防いだり、
DLsiteの作品ページから直接ギフトページを開けるようにしたり、
桃色CODEのサイトにみちくさびゅあーを直接埋め込む機能作ったり、
Etc...

こういうことはスマートヒョンだけでは中々できないので、パソコンの便利さを実感する。

ちなみに私物のデスクトップパソコンはあまりにも使わなすぎたので、離れて暮らす兄に貸し出している。
なので手元にあるパソコンはSurfaceGo(初代)という開発には向かない貧弱パソコンだけ。
こうやってCi-enの記事書いたりする程度には使えるのだが、タブレットでもできるからなぁ……みたいな。

そういえば久しくノートパソコンを買っていないので、アマゾンを徘徊していたら中古のリテール品がWindows11のノートPCが大量に出ていた。
しかし、CPUをみてびっくり。

Win11が正式サポートしてない世代のCPUじゃん……

ネットでの買い物も難しくなってきているなと思った。

Mes

.NET8がリリースされたら移行しようと思っていたMes。
結構致命的な設計ミスにも悩まされていて、イチから再設計しています。
正直なところ勉強も足りてなくて、このまま再実装するのも得策じゃない気がして勉強しながら設計してはバラしてを繰り返しています。

Mesの言語自体は初期の頃からコンセプトは素晴らしいと自負しています。
「デコレーション」という概念でメタ情報を扱い、それを構造化されたデータとして簡単に扱うことができ、既存のシナリオテキストをMesに書き直すのは非常に簡単なのもコンセプトが洗練されているおかげです。

テキストシナリオをプログラムで扱いやすいように構造化されたデータとして提供することで、「【Mes】ADVで使えそうな分岐管理を試験的に組み込んでみた【試験実装】」みたいな機能も比較的スムーズに開発できました

一方で、Mesの開発で一番苦労しているのはコアライブラリの実装です。
しかも、Mes本体の解析処理ではなく、Mesを便利にするための外野のフラットレイヤーとコンフィグレイヤーと呼んでいる部分で一番苦労しています。

フラットレイヤーはMesとして解析する前に、テキストに前処理を施す層です。
脚本でよく使われる表記方法の一部をMes形式に変換したり、削除していいコメントアウト部分を消したりします。
そうすることで一般的なシナリオ記述でもMesで解析できるような工夫がされています。
置換ルールと処理を書くだけなのでフラット処理単体の実装は難しくありません。
問題はコンフィグレイヤーとの関係にあります。

Mesではヘッダーと呼ばれる記述エリアに各種設定用の変数を記述することができます。
キャラ名も省略したときのデフォルト名や、各種デコレーターの記号などMesに関する設定をMesテキスト内で設定できる仕組みです。
この仕組みはMesのヘッダー部分の解析時にコンフィグへ情報の上書き処理を行います。以降の処理では上書きされたコンフィグ情報で解析されるので、デコレーター文字などの設定書き換えも可能になっています。

フラットレイヤーはヘッダー解析よりも前の段階なので、このコンフィグ書き換えの恩恵を受けられません。
フラットレイヤーでもヘッダーの変数解析をするしかありませんが、そうするとヘッダーの役割と重複します（このような役割の重複がバグの温床になります）
そうなると、ヘッダーの変数解析はフラットレイヤーに移譲するのが正しい気がしてきますが、フラットレイヤーは必ず実行されるような仕様ではなく、ライブラリ利用者が任意に外すことができる使用になっています。
（元々がテキストの前処理をしたいケースでの拡張機能的な役割なのでこのような仕様になっています）

というわけで、フラットレイヤーの前にコンフィグレイヤーを新たに作り、コンフィグレイヤーを通過したときはヘッダー解析で変数解析をスキップできるような仕様なら効率よくできそうだなとか。
そういった再設計をしています。
特にコンフィグレイヤーはまだ仕様が固まっていないのもありますが、MesEditorのようなサードパーティツール製作者がコンフィグ設定用の機構を実装しなくても機能するような柔軟な仕組みづくりを念頭にして考えています。

まだまだ時間がかかりそうですが、ここさえ満足いく作り方ができればサードパーティツールの開発はすごく楽になるのでスキルアップも兼ねてじっくり作り込もうと思います。

【雑記】芸術じゃない芸術の話【学びの咀嚼】

著作権法について学習している時から、芸術という言葉は非常に厄介だなと思っていた。
芸術は「思想(美しさ、感性等)を人が表現する活動とその活動から生まれた作品」という意味に位置づけできる。
要するに人が生み出した思想の塊が芸術であり、芸術作品と言ってもよいだろう。

しかし、私たちは人が生み出したもの以外からも芸術性のようなものを享受する機会があるように思う。
自然が生み出した雄大な富士山の姿。
ウユニ塩湖の景色。
満天の星空。
ブロッコリーのフラクタル構造。

人工的でないものからも、芸術に通じる何かを私たちは享受するが、芸術性に替わって、人工的でないそれらを的確に表す言葉が未定義だと私は思った。
（もしくは私が不学で適切な言葉があるのかもしれない）

「自然が生み出した芸術」と言ってしまえば万人には通じるだろうが、それはWord to Vector的な意味合成で、

芸術 - 人工的 + 天然(自然)

の式から得られるニュアンスでしかない。

仮に、狭義の芸術を人による創作物とし、広義には感動するものを指すと位置づけても芸術の意味解釈的範囲を広げただけに過ぎず、狭義の芸術以外の芸術には依然として名前が無いままだ。これを暫定的に狭義外の芸術と呼ぶことにする。

狭義の芸術と狭義外の芸術は、人によって両者を同列で評価したり、違うものとして評価したりと個人差があるはずだ。
同じ人でもケースバイケースでこの価値観がスイッチしたりするかもしれない。
綺麗や美しいという言葉は評価の結論であり、至ったゴール地点を指す。
狭義の芸術という入口だろうが、他の入り口だろうが、その先は同じ場所に通じているかもしれない。
感情という結論で言えば喜怒哀楽のどれかに帰結するだろう。
もっと単純なら、好き or 嫌いのどちらかに帰結するかもしれない。

話を本筋の戻すが、
人が創作したものは芸術であり、芸術性を語ることができるだろう。
しかし、狭義外の芸術にも芸術性のようなものがあり、そこに適切な名前がなく、その性質を説明するために芸術の名を借りているせいで混乱してしまう状況がある。AIの生成物が芸術なのか否かみたいな議論のディスコミュニケーションもこの混乱が一因だと勝手に推測している。
本来なら芸術という言葉のスコープは人工物に限るはずなのに、スコープ外の人工的でないものから芸術に似た感動を得たとき、我々は芸術の概念を使って言葉にしてしまう。
飛躍する例えかもしれないが、斧を知らずナイフを知っている人に「木を切るナイフ」と斧を説明することに近いかもしれない。
または、タコみたいな姿の火星人がいたとして、明らかに人類とは違う生命体なのに人の概念に当てはめて火星人と呼んでいることに似ていると思う。

Contemporary Artを現代美術と定義してしまったように、こと芸術分野においては混乱を招くような言葉が多すぎる。
芸術自体が明確に意味を定義したりするのが難しい概念であるという側面もあるだろうが、いずれにせよ、価値観や定義などが人によって独自実装されているのに同じプロトコルとみなしてコミュニケーションに使っていたら、そりゃぁコミュニケーショントラブル起きるでしょという話。

芸術の前提議論として、（狭義の）芸術自体が自然の模倣でしかないとか、哲学的な議論はあると思うがその話はまた別の機会に考える。
僕はしばらく、狭義の芸術じゃない芸術（人の介在しない芸術領域）について色々考えたいなと思った。

参考文献
https://www.rs.tus.ac.jp/makita/stellung/stell_phi_kunst_j.html
https://natgeo.nikkeibp.co.jp/atcl/web/15/427954/090400006/