Monorepo for Aesthetic.Computer
aesthetic.computer
papers: add Japanese card translations and new paper entries
+10155
-226
+13
-11
papers/arxiv-ac/ac-cards.tex
+13
-11
papers/arxiv-ac/ac-cards.tex
···
105
105
\thispagestyle{empty}
106
106
\vspace*{\fill}
107
107
\begin{center}
108
-
\includegraphics[height=8em]{pals}\par\vspace{0.3em}
109
-
{\acbold\fontsize{20pt}{24pt}\selectfont\color{acdark} \acrandname{} '26}\par
110
-
\vspace{0.3em}
111
-
{\fontsize{10pt}{12pt}\selectfont\color{acpink} A Mobile-First Runtime for Creative Computing}\par
112
-
\vspace{0.8em}
113
-
{\normalsize\color{cyan!70!blue}\textbf{@jeffrey}}\par
108
+
\includegraphics[height=9em]{pals}\par\vspace{0.1em}
109
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} \acrandname{} '26}\par
110
+
\vspace{0.1em}
111
+
{\fontsize{9pt}{11pt}\selectfont\color{acpink} A Mobile-First Runtime for Creative Computing}\par
112
+
\vspace{0.4em}
113
+
{\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par
114
114
{\small\color{acgray} Aesthetic.Computer}\par
115
115
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
116
-
\vspace{0.8em}
117
-
\rule{0.6\textwidth}{1pt}\par
118
116
\vspace{0.4em}
119
-
{\small\color{acpink!40}\textit{working draft --- not for citation}}\par
120
-
\vspace{0.3em}
121
-
{\footnotesize\color{acgray} March 2026}\par
117
+
\rule{0.5\textwidth}{0.5pt}\par
118
+
\vspace{0.15em}
119
+
\colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par
120
+
\vspace{0.1em}
121
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/2113ef735}{2113ef735}}\par
122
+
\vspace{0.1em}
123
+
{\footnotesize\color{acgray}\href{https://papers.aesthetic.computer/aesthetic-computer-26-arxiv-da-cards.pdf}{Dansk} · \href{https://papers.aesthetic.computer/aesthetic-computer-26-arxiv-es-cards.pdf}{Español} · \href{https://papers.aesthetic.computer/aesthetic-computer-26-arxiv-zh-cards.pdf}{{\accjk 中文}} · \href{https://papers.aesthetic.computer/aesthetic-computer-26-arxiv-ja-cards.pdf}{{\accjk 日本語}}}\par
122
124
\end{center}
123
125
\vspace*{\fill}
124
126
+522
papers/arxiv-ac/ac-ja.tex
+522
papers/arxiv-ac/ac-ja.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
\usepackage{xeCJK}
11
+
\setCJKmainfont{Droid Sans Japanese}
12
+
13
+
\setmainfont{Latin Modern Roman}
14
+
\setsansfont{Latin Modern Sans}
15
+
16
+
% Custom AC fonts
17
+
\newfontfamily\acbold{ywft-processing-bold}[
18
+
Path=../../system/public/type/webfonts/,
19
+
Extension=.ttf
20
+
]
21
+
\newfontfamily\aclight{ywft-processing-light}[
22
+
Path=../../system/public/type/webfonts/,
23
+
Extension=.ttf
24
+
]
25
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
26
+
27
+
% === PACKAGES ===
28
+
\usepackage{xcolor}
29
+
\usepackage{titlesec}
30
+
\usepackage{enumitem}
31
+
\usepackage{booktabs}
32
+
\usepackage{tabularx}
33
+
\usepackage{multicol}
34
+
\usepackage{fancyhdr}
35
+
\usepackage{hyperref}
36
+
\usepackage{graphicx}
37
+
\graphicspath{{figures/}}
38
+
\usepackage{ragged2e}
39
+
\usepackage{listings}
40
+
\usepackage{natbib}
41
+
\usepackage[colorspec=0.92]{draftwatermark}
42
+
43
+
% === COLORS (AC palette) ===
44
+
\definecolor{acpink}{RGB}{180,72,135}
45
+
\definecolor{acpurple}{RGB}{120,80,180}
46
+
\definecolor{acdark}{RGB}{64,56,74}
47
+
\definecolor{acgray}{RGB}{119,119,119}
48
+
\definecolor{draftcolor}{RGB}{180,72,135}
49
+
50
+
% === DRAFT WATERMARK ===
51
+
\DraftwatermarkOptions{
52
+
text=WORKING DRAFT,
53
+
fontsize=3cm,
54
+
color=draftcolor!18,
55
+
angle=45,
56
+
pos={0.5\paperwidth, 0.5\paperheight}
57
+
}
58
+
59
+
% === KIDLISP SYNTAX COLORS ===
60
+
\definecolor{klfn}{RGB}{0,136,170}
61
+
\definecolor{klform}{RGB}{119,51,170}
62
+
\definecolor{klrepeat}{RGB}{170,0,170}
63
+
\definecolor{klnum}{RGB}{204,0,102}
64
+
\definecolor{klstr}{RGB}{170,120,0}
65
+
\definecolor{klcmt}{RGB}{102,102,102}
66
+
\definecolor{klmath}{RGB}{0,136,0}
67
+
\definecolor{klvar}{RGB}{204,102,0}
68
+
\definecolor{klembed}{RGB}{0,136,0}
69
+
70
+
% === JS SYNTAX COLORS ===
71
+
\definecolor{jskw}{RGB}{119,51,170}
72
+
\definecolor{jsfn}{RGB}{0,136,170}
73
+
\definecolor{jsstr}{RGB}{170,120,0}
74
+
\definecolor{jsnum}{RGB}{204,0,102}
75
+
\definecolor{jscmt}{RGB}{102,102,102}
76
+
77
+
% Inline color macros
78
+
\newcommand{\kn}[1]{\textcolor{klnum}{#1}}
79
+
\newcommand{\kt}[1]{\textcolor{klstr}{#1}}
80
+
\newcommand{\kv}[1]{\textcolor{klvar}{#1}}
81
+
\newcommand{\ke}[1]{\textcolor{klembed}{\textbf{#1}}}
82
+
\newcommand{\km}[1]{\textcolor{klmath}{#1}}
83
+
84
+
% === HYPERREF ===
85
+
\hypersetup{
86
+
colorlinks=true,
87
+
linkcolor=acpurple,
88
+
urlcolor=acpurple,
89
+
citecolor=acpurple,
90
+
pdfauthor={@jeffrey},
91
+
pdftitle={Aesthetic Computer '26：クリエイティブコンピューティングのためのモバイルファーストランタイム},
92
+
}
93
+
94
+
% === SECTION FORMATTING ===
95
+
\titleformat{\section}
96
+
{\normalfont\bfseries\normalsize\uppercase}
97
+
{\thesection.}
98
+
{0.5em}
99
+
{}
100
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
101
+
102
+
\titleformat{\subsection}
103
+
{\normalfont\bfseries\small}
104
+
{\thesubsection}
105
+
{0.5em}
106
+
{}
107
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
108
+
109
+
% === HEADER/FOOTER ===
110
+
\pagestyle{fancy}
111
+
\fancyhf{}
112
+
\renewcommand{\headrulewidth}{0pt}
113
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{作業草稿 --- 引用不可}}
114
+
\fancyfoot[C]{\footnotesize\thepage}
115
+
116
+
% === CUSTOM COMMANDS ===
117
+
\newcommand{\acdot}{{\color{acpink}.}}
118
+
\newcommand{\ac}{\textsc{Aesthetic.Computer}}
119
+
120
+
% === LISTINGS ===
121
+
\lstdefinelanguage{kidlisp}{
122
+
morekeywords=[1]{wipe,ink,line,box,circle,write,wiggle,shape,scroll,spin,zoom,blur,contrast,embed,layer,width,height,frame,time,form,trans,cube,move,scale,hop,overtone,melody,mic,resolution,sort,fade,stamp,paste,flood,poly,noise,flip},
123
+
morekeywords=[2]{def,let,if,cond,once,later,lambda,do},
124
+
morekeywords=[3]{repeat},
125
+
morekeywords=[4]{random,sin,cos,tan,floor,ceil,round,abs,sqrt,min,max},
126
+
sensitive=true,
127
+
morecomment=[l]{;},
128
+
morestring=[b]",
129
+
escapeinside={|}{|},
130
+
}
131
+
132
+
\lstdefinelanguage{acjs}{
133
+
morekeywords=[1]{function,export,const,let,var,return,if,else,new,async,await,import,from},
134
+
morekeywords=[2]{wipe,ink,line,box,circle,write,screen,params,colon,jump,send,store,net,sound,speaker},
135
+
sensitive=true,
136
+
morecomment=[l]{//},
137
+
morestring=[b]",
138
+
morestring=[b]',
139
+
morestring=[b]`,
140
+
escapeinside={|}{|},
141
+
}
142
+
143
+
\lstdefinestyle{acjsstyle}{
144
+
language=acjs,
145
+
keywordstyle=[1]\color{jskw}\bfseries,
146
+
keywordstyle=[2]\color{jsfn}\bfseries,
147
+
commentstyle=\color{jscmt}\itshape,
148
+
stringstyle=\color{jsstr},
149
+
}
150
+
151
+
\lstdefinestyle{kidlispstyle}{
152
+
language=kidlisp,
153
+
keywordstyle=[1]\color{klfn}\bfseries,
154
+
keywordstyle=[2]\color{klform}\bfseries,
155
+
keywordstyle=[3]\color{klrepeat}\bfseries,
156
+
keywordstyle=[4]\color{klmath},
157
+
commentstyle=\color{klcmt}\itshape,
158
+
stringstyle=\color{klstr},
159
+
}
160
+
161
+
\lstset{
162
+
basicstyle=\ttfamily\small,
163
+
breaklines=true,
164
+
frame=single,
165
+
rulecolor=\color{acgray!30},
166
+
backgroundcolor=\color{acgray!5},
167
+
xleftmargin=0.5em,
168
+
xrightmargin=0.5em,
169
+
aboveskip=0.5em,
170
+
belowskip=0.5em,
171
+
}
172
+
173
+
% === LIST SETTINGS ===
174
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
175
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
176
+
177
+
% === COLUMN SEPARATION ===
178
+
\setlength{\columnsep}{1.8em}
179
+
180
+
% === PARAGRAPH SETTINGS ===
181
+
\setlength{\parindent}{1em}
182
+
\setlength{\parskip}{0.3em}
183
+
184
+
% Hyphenation for narrow two-column layout
185
+
\tolerance=800
186
+
\emergencystretch=1em
187
+
\hyphenpenalty=50
188
+
189
+
\begin{document}
190
+
191
+
% ============ TITLE BLOCK ============
192
+
193
+
\twocolumn[{%
194
+
\begin{center}
195
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
196
+
{\acbold\fontsize{24pt}{28pt}\selectfont\color{acdark} Aesthetic\acdot Computer '26}\par
197
+
\vspace{0.2em}
198
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} クリエイティブコンピューティングのためのモバイルファーストランタイム}\par
199
+
\vspace{0.6em}
200
+
{\normalsize @jeffrey}\par
201
+
{\small\color{acgray} Aesthetic.Computer}\par
202
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
203
+
\vspace{0.3em}
204
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
205
+
\vspace{0.6em}
206
+
\rule{\textwidth}{1.5pt}
207
+
\vspace{0.5em}
208
+
\end{center}
209
+
210
+
\begin{center}
211
+
{\small\color{acpink}\textbf{[ 作業草稿 --- 引用不可 ]}}
212
+
\end{center}
213
+
\vspace{0.3em}
214
+
215
+
\begin{quote}
216
+
\small\noindent\textbf{概要。}
217
+
\ac{}（AC）は、ブラウザ上で完全に動作するクリエイティブコンピューティングのためのモバイルファーストランタイム兼ソーシャルネットワークである。主要なインターフェースはGUIではなくテキストプロンプトであり、ユーザーはこれを通じて354の組み込みインタラクティブプログラム（「ピース」）と265のユーザー公開ピースからなる名前空間をナビゲートする。各ピースは単一のJavaScriptまたはKidLispファイルであり、即時モードグラフィックスAPIを受け取るライフサイクル関数（boot、paint、act、sim、leave）をエクスポートする。本プラットフォームは、ソーシャルインフラストラクチャ——ユーザーID、リアルタイムチャット、ムードフィード、プロフィール——をアドオンレイヤーとしてではなく、ランタイムに直接統合している。パッケージングシステムはピースをオフライン配布用のスタンドアロンHTMLファイルにバンドルする。本稿では、アーキテクチャ（コアランタイムコード63,000行）、ピースモデル、多言語対応、公開・配布インフラストラクチャについて記述し、登録ユーザー2,801名の採用指標を報告する。プログラミングインターフェースを\emph{楽器}として扱うこと——ユーザーが即興的な探索を通じて記憶可能なパスを発見すること——が、クリエイティブソフトウェアとの質的に異なる関係を生み出すことを論じる。
218
+
\end{quote}
219
+
\vspace{0.5em}
220
+
}]
221
+
222
+
% ============ 1. INTRODUCTION ============
223
+
224
+
\section{はじめに}
225
+
226
+
クリエイティブコーディングプラットフォームは、計算による表現の敷居を段階的に下げてきた。Processing~\citep{reas2007processing}はスケッチブックの比喩を導入し、p5.js~\citep{mccarthy2015p5js}はそれをブラウザに持ち込み、Scratch~\citep{resnick2009scratch}はブロックベースのビジュアルプログラミングによって子供たちにもプログラミングを可能にした。しかし、これらのツールは共通の前提を共有している——ユーザーは\emph{エディタ}と対話するということだ。コードエディタ、ブロックキャンバス、統合開発環境である。
227
+
228
+
\ac{}は異なる前提から出発する。その主要なインターフェースは\textbf{テキストプロンプト}——短く記憶しやすい名前を入力してインタラクティブプログラムを起動するコマンドラインである。ファイルブラウザもプロジェクトパネルもメニューバーもない。この体験は開発環境よりも楽器に近い。ユーザーは探索を通じてコマンドを発見し、反復によって筋肉記憶を構築し、最終的にはピースを流暢に再構成することで即興演奏する。
229
+
230
+
本プラットフォームは、ピクセルペイントツールであるNo Paint（2020年）の開発中の観察から生まれた。技術的な背景を持たないユーザーコミュニティがカスタムブラシやスタンプを寄稿し始めたのである。手動の統合プロセス——各寄稿に数時間から数日を要した——が、誰でもインタラクティブプログラムを即座に公開できるシステムの構築を推進した。開発は2021年に始まり、現在のリポジトリには2022年12月から2026年3月までの11,045件のコミットが含まれている。
231
+
232
+
本稿では、設計原則（\S\ref{sec:principles}）、システムアーキテクチャ（\S\ref{sec:architecture}）、ピースモデル（\S\ref{sec:pieces}）、多言語ランタイム（\S\ref{sec:languages}）、プロンプトインターフェース（\S\ref{sec:prompt}）、ソーシャルインフラストラクチャ（\S\ref{sec:social}）、公開と配布（\S\ref{sec:publishing}）、開発の歴史（\S\ref{sec:history}）、および採用状況（\S\ref{sec:evaluation}）について記述する。関連論文~\citep{scudder2026kidlisp}ではKidLisp言語について詳述している。
233
+
234
+
% ============ 2. DESIGN PRINCIPLES ============
235
+
236
+
\section{設計原則}
237
+
\label{sec:principles}
238
+
239
+
\begin{enumerate}
240
+
\item \textbf{IDEではなく楽器。}インターフェースは楽器のように機能するよう設計されており、ユーザーはコマンドと公開ピースのネットワークの中で自分だけの記憶可能なパスを発見する。遊びを通じてリテラシーが向上するにつれ、ユーザーは即興し、再構成し、レパートリーを拡張する。
241
+
\item \textbf{モバイルファースト。}すべてのインタラクションはスマートフォンとタブレットでのタッチ入力を対象としている。デスクトップ対応は自然に付随する——その逆は成り立たない。
242
+
\item \textbf{URLアドレス可能。}すべてのピース、すべてのパラメータの組み合わせ、すべてのユーザーのピースがURLである。共有がナビゲーションであり、ナビゲーションが共有である。
243
+
\item \textbf{単一ファイルプログラム。}Processingのスケッチブックモデルと、Unixの小さく組み合わせ可能なプログラムの哲学に従い、各ピースは1つのファイルである——プロジェクト構造もビルドステップも依存関係もない。
244
+
\item \textbf{デフォルトでソーシャル。}ユーザーID、チャット、ムードフィード、プロフィールはランタイムの一部であり、追加サービスではない。
245
+
\end{enumerate}
246
+
247
+
% ============ 3. ARCHITECTURE ============
248
+
249
+
\section{アーキテクチャ}
250
+
\label{sec:architecture}
251
+
252
+
本システムは4つの主要コンポーネントで構成される：ブートローダー、BIOSランタイム、Disk API、モジュールローダー。
253
+
254
+
\subsection{ブートローダー}
255
+
256
+
ブートローダー（\texttt{boot.mjs}、1,948行）は3つのサブシステムを並列に初期化する：セッションサーバーへのWebSocket接続（800ミリ秒のタイムアウトとHTTPへのフォールバック付き）、永続的なモジュールキャッシュのためのService Worker、オフラインモジュールストレージのためのIndexedDBストレージ。ブートテレメトリはブラウザ、デバイスタイプ、画面解像度、パフォーマンスタイミングデータを\texttt{/api/boot-log}に記録する。
257
+
258
+
\subsection{BIOS}
259
+
260
+
BIOS（\texttt{bios.mjs}、20,935行）はランタイムコーディネーターである。60fpsのレンダリングループを管理し、入力イベント（キーボード、タッチ、マウス、ゲームパッド、MIDI）をルーティングし、ピースのライフサイクル遷移を調整し、ポストプロセッシングエフェクト用のWebGL合成レイヤー（「glaze」）を維持する。BIOSはまた、同期オーディオ付きフレームシーケンスとしてピースの演奏をキャプチャする録画システムも管理する。
261
+
262
+
\subsection{Disk API}
263
+
264
+
Disk（\texttt{disk.mjs}、15,879行）はピースが使用する完全なAPIサーフェスを提供する。ピースのロード、ライフサイクルのディスパッチを管理し、描画プリミティブ、オーディオ、入力、ネットワーク、UIコンポーネントを公開する。すべてのグラフィックス操作は即時モードであり、保持されるシーングラフはない。
265
+
266
+
\subsection{モジュールローダー}
267
+
268
+
モジュールローダーはセッションサーバーからWebSocket経由でJavaScriptモジュールをストリーミングし、HTTPプロキシチェーンをバイパスしてロードを高速化する。最初のロード時にモジュールはIndexedDBにキャッシュされる。以降のアクセスではキャッシュからロードし、セッションサーバーが利用できない場合はHTTPにフォールバックする。これにより、リピート訪問時のピースロードがほぼ瞬時になる。
269
+
270
+
% ============ 4. THE PIECE MODEL ============
271
+
272
+
\section{ピースモデル}
273
+
\label{sec:pieces}
274
+
275
+
ピースは単一の\texttt{.mjs}（JavaScript）または\texttt{.lisp}（KidLisp）ファイルであり、最大5つのライフサイクル関数をエクスポートする：
276
+
277
+
\begin{lstlisting}[style=acjsstyle]
278
+
function boot({ wipe, screen, params }) {
279
+
// Runs once when piece loads
280
+
}
281
+
282
+
function paint({ wipe, ink, line, circle }) {
283
+
wipe(|\textcolor{jsstr}{"navy"}|)
284
+
ink(|\textcolor{jsstr}{"pink"}|)
285
+
circle(screen.width / |\textcolor{jsnum}{2}|,
286
+
screen.height / |\textcolor{jsnum}{2}|, |\textcolor{jsnum}{50}|)
287
+
}
288
+
289
+
function act({ event: e }) {
290
+
if (e.is(|\textcolor{jsstr}{"keyboard:down:space"}|)) { }
291
+
}
292
+
293
+
function sim() { } // Per-frame logic
294
+
295
+
export { boot, paint, act, sim };
296
+
\end{lstlisting}
297
+
298
+
各関数に渡されるAPIオブジェクトは以下を提供する：
299
+
300
+
\begin{table}[h]
301
+
\small
302
+
\centering
303
+
\begin{tabularx}{\columnwidth}{lX}
304
+
\toprule
305
+
\textbf{カテゴリ} & \textbf{関数} \\
306
+
\midrule
307
+
グラフィックス & \texttt{wipe}, \texttt{ink}, \texttt{line}, \texttt{box}, \texttt{circle}, \texttt{poly}, \texttt{paste}, \texttt{plot}, \texttt{flood} \\
308
+
テキスト & \texttt{write}, \texttt{form}, \texttt{TextInput} \\
309
+
入力 & \texttt{event}, \texttt{pen}, \texttt{hand}, \texttt{gamepad} \\
310
+
オーディオ & \texttt{sound}, \texttt{speaker}, \texttt{microphone}, \texttt{melody} \\
311
+
UI & \texttt{ui.Button}, \texttt{ui.TextInput}, \texttt{cursor} \\
312
+
システム & \texttt{screen}, \texttt{jump}, \texttt{store}, \texttt{net}, \texttt{send} \\
313
+
\bottomrule
314
+
\end{tabularx}
315
+
\caption{ピースAPIのカテゴリ分類。}
316
+
\label{tab:api}
317
+
\end{table}
318
+
319
+
ピースはProcessingのスケッチブックモデル——探索したい各アイデアに1つのソースファイル——を、小さく単一目的のプログラム間のユーザーレベルの組み合わせ可能性というUnixの哲学と組み合わせている。
320
+
321
+
% ============ 5. MULTI-LANGUAGE RUNTIME ============
322
+
323
+
\section{多言語ランタイム}
324
+
\label{sec:languages}
325
+
326
+
ACは2つのプログラミング言語をサポートする：JavaScript（ESモジュール、\texttt{.mjs}）とKidLisp（最小限のLisp方言、\texttt{.lisp}）。システムには現在336のJavaScriptピースと18のKidLispピースが含まれている。
327
+
328
+
JavaScriptピースはWeb APIとDisk APIサーフェスに完全にアクセスできる。KidLispピースは15,161行のツリーウォーキング評価器~\citep{scudder2026kidlisp}を使用し、描画、色、変換、数学、アニメーション、オーディオ用の118の組み込み関数を提供する——ファイルI/O、ネットワーク、文字列操作はなく、任意のユーザー投稿コードの安全な実行を可能にしている。
329
+
330
+
KidLispプログラムはURL上で直接入力することもできる。式\texttt{(wipe blue)}はURLエンコードされ、\texttt{aesthetic.computer/(\%28wipe\%20blue\%29)}で実行できる。ショートコード（\texttt{\$cow}、\texttt{\$27z}）はMongoDBルックアップを通じて保存されたプログラムに解決される。
331
+
332
+
このアーキテクチャは追加の言語バックエンドをサポートする。ピースのライフサイクル（boot/paint/act/sim/leave）をターゲットにしてDisk APIを呼び出せる言語であれば、新しい評価器として統合できる。
333
+
334
+
% ============ 6. THE PROMPT ============
335
+
336
+
\section{プロンプト}
337
+
\label{sec:prompt}
338
+
339
+
プロンプト（\texttt{prompt.mjs}、9,386行）はそれ自体がピースであり、システム内で最も複雑なものである。主要なナビゲーションインターフェースとして機能し、60以上のコマンドを実装している。
340
+
341
+
\subsection{URLルーティング}
342
+
343
+
すべてのピースはパーサー（\texttt{parse.mjs}）を通じてURLアドレス可能であり、複数のパラメータ規約をサポートする：
344
+
345
+
\begin{itemize}
346
+
\item \textbf{シンプル}：\texttt{aesthetic.computer/notepat}
347
+
\item \textbf{コロンパラメータ}：\texttt{tone:440:sine}
348
+
\item \textbf{スペースパラメータ}：\texttt{notepat 180 major}（URL内ではチルダにエンコード）
349
+
\item \textbf{ユーザーピース}：\texttt{@bash/hub}
350
+
\item \textbf{KidLispコード}：\texttt{\$cow}
351
+
\item \textbf{ショートコード}：\texttt{!abc}（動画）、\texttt{*bako}（時計メロディ）
352
+
\end{itemize}
353
+
354
+
\subsection{コマンドカテゴリ}
355
+
356
+
プロンプトはナビゲーション（\texttt{list}、\texttt{back}）、制作（\texttt{publish}、\texttt{source}、\texttt{pack}）、ソーシャルインタラクション（\texttt{chat}、\texttt{mood}、\texttt{profile}）、アイデンティティ（\texttt{handle}、\texttt{login}）、録画（\texttt{tape}、\texttt{share}）、およびピースのオーケストレーション（\texttt{merry}：ピースを時系列で連鎖させる）のためのコマンドを実装している。
357
+
358
+
% ============ 7. SOCIAL INFRASTRUCTURE ============
359
+
360
+
\section{ソーシャルインフラストラクチャ}
361
+
\label{sec:social}
362
+
363
+
ソーシャル機能が外部サービス（GitHub、Discord）として提供されるプラットフォームとは異なり、ACはソーシャルインフラストラクチャをランタイムに直接統合している。
364
+
365
+
\subsection{アイデンティティ}
366
+
367
+
ユーザーはプロンプトで\texttt{@handles}（識別子）を登録する。ハンドルはMongoDBのユーザーレコードに解決され、公開ピースの名前空間として機能する（\texttt{@handle/piece-name}）。2026年3月時点で2,801のハンドルが登録されている。
368
+
369
+
\subsection{リアルタイム通信}
370
+
371
+
セッションサーバーはWebSocketベースのリアルタイム機能を提供する：パブリックチャット（18,020件のメッセージ）、プレゼンストラッキング（各ユーザーが現在閲覧中のピース）、および協働ピースのマルチプレイヤー状態同期。
372
+
373
+
\subsection{ムードフィード}
374
+
375
+
ユーザーはプロフィールに表示される短いテキスト更新（「ムード」）を投稿する。ムードフィードはMongoDBとATProto（Blueskyの基盤プロトコル）の両方に書き込まれ、より広いソーシャルネットワークとの連合を実現している。
376
+
377
+
\subsection{ライブプロフィール}
378
+
379
+
プロフィールピースはリアルタイムのスコアカードを表示する：オンライン/オフライン状態、現在のピース、WebSocketレイテンシ、そして描画作品、公開ピース、KidLispプログラム、チャットメッセージ、ムードフィードの数——すべてWebSocketストリームを通じてリアルタイムで更新される。
380
+
381
+
% ============ 8. PUBLISHING & DISTRIBUTION ============
382
+
383
+
\section{公開と配布}
384
+
\label{sec:publishing}
385
+
386
+
\subsection{公開とソース}
387
+
388
+
\texttt{publish}コマンドはピースをDigitalOcean Spacesにアップロードし、MongoDBにユーザーのハンドルで登録する。\texttt{source}コマンドは任意のピースのソースコードをフォークテンプレートとしてダウンロードする。
389
+
390
+
\subsection{パッケージングシステム}
391
+
392
+
\texttt{pack}コマンドはovenサービスを通じてピースを自己完結型のHTMLファイルにバンドルする。出力にはピースコード、すべてのランタイム依存関係、埋め込みフォントが含まれ、サーバーなしでオフラインで動作する単一ファイルとなる。これにより、メール、USBドライブ、ブロックチェーンミンティング（Tezos/Teia）、アーカイブを通じた配布が可能になる。
393
+
394
+
\subsection{カスタムドメイン}
395
+
396
+
ピースはカスタムドメイン上でスタンドアロンアプリケーションとして提供できる。\texttt{notepat.com}は\texttt{notepat}音楽シーケンサーピースにルーティングされ、\texttt{kidlisp.com}はKidLisp IDEを提供する。Netlifyエッジ関数がホスト名を検出し、ソーシャル共有用のカスタムOpen Graphメタタグを含めて適切にルートを書き換える。
397
+
398
+
\subsection{メディアエクスポート}
399
+
400
+
ovenサービス（\texttt{oven.aesthetic.computer}）はFFmpegを使用して録画セッションをMP4動画に変換し、ソーシャル共有用のOpen Graphプレビュー画像を生成し、ピースURLのQRコードを提供する。録画はフレーム単位のタイミングデータとオプションのオーディオを含むフレームシーケンスをキャプチャする。
401
+
402
+
% ============ 9. DEVELOPMENT HISTORY ============
403
+
404
+
\section{開発の歴史}
405
+
\label{sec:history}
406
+
407
+
以下のタイムラインは、Aesthetic Computerリポジトリのgit履歴（2022年12月から2026年3月までの11,045件のコミット）から再構成したものである。プロジェクトの概念的起源は2020年のNo Paintに遡る。
408
+
409
+
\subsection{起源：No Paint（2020--2021年）}
410
+
411
+
No Paintは2020年にリリースされたピクセルペイントツールで、カスタムブラシやスタンプを寄稿する非技術的なユーザーコミュニティを構築した。手動統合のボトルネック——各寄稿に開発者の介入が必要だった——が、誰でもインタラクティブプログラムを即座に公開できるプラットフォームの構築を推進した。
412
+
413
+
\subsection{基盤期（2022--2023年）}
414
+
415
+
現在のリポジトリは2022年12月に始まった。2023年を通じて（3,766件のコミット）、コアランタイムが形成された：BIOSレンダリングループ、Disk API、プロンプトインターフェース、ピースライフサイクル、および初期の組み込みピースセット。2023年9月に初期の活動ピーク（542件のコミット）を迎え、マルチプレイヤーセッションサーバーとリアルタイムチャットが統合された。
416
+
417
+
\subsection{拡張期（2024年）}
418
+
419
+
2024年（2,698件のコミット）にKidLisp（4月）、ペイントシステム、ハンドル登録、ムードフィード、録画インフラストラクチャが追加された。活動は4月（379件のコミット）と10月（336件のコミット）にピークを迎えた。
420
+
421
+
\subsection{プラットフォーム統合（2025--2026年）}
422
+
423
+
開発は2025年後半に急激に加速した：10月に700件のコミット、11月に663件、12月に525件。KidLisp IDEが\texttt{kidlisp.com}で公開され（2025年11月）、ATProto/Bluesky連合が追加され、パッケージングシステムが成熟し、ovenサービスがソーシャルプレビュー画像の生成を開始した。2026年1月は月間最多（1,095件のコミット）であり、KidLispの改善、カオスモード、3Dプリミティブ、ライブパフォーマンス用のステージモードが推進力となった。
424
+
425
+
\begin{table}[h]
426
+
\small
427
+
\centering
428
+
\begin{tabular}{lrl}
429
+
\toprule
430
+
\textbf{期間} & \textbf{コミット数} & \textbf{マイルストーン} \\
431
+
\midrule
432
+
2020--2021年 & --- & No Paint；AC構想 \\
433
+
2022年12月 & 47 & リポジトリ作成 \\
434
+
2023年 & 3{,}766 & コアランタイム、プロンプト、マルチプレイヤー \\
435
+
2024年 & 2{,}698 & KidLisp、ペイント、ハンドル、ムード \\
436
+
2025年1--5月 & 318 & メンテナンス期間 \\
437
+
2025年6--12月 & 2{,}962 & IDE、パッケージング、oven、連合 \\
438
+
2026年1--3月 & 2{,}149 & カオスモード、3D、ステージモード \\
439
+
\midrule
440
+
\textbf{合計} & \textbf{11{,}045} & \\
441
+
\bottomrule
442
+
\end{tabular}
443
+
\caption{各期間の開発活動。}
444
+
\label{tab:history}
445
+
\end{table}
446
+
447
+
本プロジェクトは主に単一の著者によるものである：@jeffreyがコミットの約98\%を占め、他に14名の協力者が参加している。
448
+
449
+
% ============ 10. EVALUATION ============
450
+
451
+
\section{評価}
452
+
\label{sec:evaluation}
453
+
454
+
2026年3月時点の採用指標を表~\ref{tab:adoption}に示す。
455
+
456
+
\begin{table}[h]
457
+
\small
458
+
\centering
459
+
\begin{tabular}{lr}
460
+
\toprule
461
+
\textbf{指標} & \textbf{値} \\
462
+
\midrule
463
+
組み込みピース & 354（336 JS + 18 KidLisp） \\
464
+
ユーザー公開ピース & 265 \\
465
+
APIエンドポイント & 78 \\
466
+
登録ハンドル & 2,801 \\
467
+
作成された描画 & 4,404 \\
468
+
KidLispプログラム & 16,244 \\
469
+
チャットメッセージ & 18,020 \\
470
+
コアランタイム（行数） & $\sim$63,300 \\
471
+
\bottomrule
472
+
\end{tabular}
473
+
\caption{プラットフォーム指標（2026年3月）。}
474
+
\label{tab:adoption}
475
+
\end{table}
476
+
477
+
\subsection{観察}
478
+
479
+
\textbf{発見メカニズムとしてのプロンプト。}ユーザーはプロンプトに推測を入力することでピースを発見したと報告している——\texttt{piano}、\texttt{draw}、\texttt{chat}といった単語を試し、既存のコンテンツを見つける。このセレンディピティはフラットな名前空間の意図的な設計成果である。
480
+
481
+
\textbf{モバイルでのエンゲージメント。}モバイルファーストの設計は、ユーザーが通勤中、待合室、教室でスマートフォンからACと対話することを意味する——デスクトップのクリエイティブコーディングツールでは到達できないコンテキストである。
482
+
483
+
\textbf{ソーシャル構造がリテンションを促進。}チャット、ムードフィード、プロフィールの統合がソーシャルコンテキストを創出し、ユーザーを継続的に呼び戻している。ユーザーはムードを確認し、チャットで返信し、検索ではなくソーシャルアクティビティを通じて新しいピースを発見する。
484
+
485
+
\subsection{限界}
486
+
487
+
単一ファイルのピースモデルはプログラムの複雑性を制限する。ピースは共有ライブラリをインポートしたり、複数のモジュールに分割したりできない（ただし\texttt{\$code}参照を通じてKidLispプログラムを埋め込むことは可能である）。プロンプトインターフェースは経験豊富なユーザーにとって強力であるが、視覚的なガイダンスを期待する新規ユーザーにとっては急な発見曲線がある。
488
+
489
+
% ============ 11. RELATED WORK ============
490
+
491
+
\section{関連研究}
492
+
493
+
\textbf{クリエイティブコーディング。}Processing~\citep{reas2007processing}とp5.js~\citep{mccarthy2015p5js}がスケッチブックパラダイムを確立した。ACは単一ファイルモデルを継承しつつ、エディタをプロンプトに置き換え、ソーシャルインフラストラクチャを追加した。
494
+
495
+
\textbf{ソーシャルプログラミング。}Scratch~\citep{resnick2009scratch}は、ソーシャルな共有が教育プログラミングへのエンゲージメントを促進することを実証した。OpenProcessing~\citep{openprocessing2009}とGlitch~\citep{glitch2017}はクリエイティブコードのためのWebベースの共有プラットフォームを提供している。ACの違いは、ソーシャル機能を周辺のウェブサイトの機能としてではなく、ランタイム自体の一部にしている点にある。
496
+
497
+
\textbf{ライブコーディング。}Hydra~\citep{hydra2019}はブラウザベースのライブビジュアルコーディングを提供する。Sonic Pi~\citep{aaron2016sonic}はライブコーディングREPLを備えた音楽教育向けツールである。ACのステージモード（全画面キャンバス上の透過エディタオーバーレイ）は同様のライブパフォーマンスシナリオをサポートする。
498
+
499
+
\textbf{モバイルクリエイティブツール。}ほとんどのクリエイティブコーディングツールはデスクトップ利用を前提としている。ACのモバイルファースト設計——タッチ入力、プロンプトナビゲーション、スマートフォンサイズのキャンバス——は、デスクトップツールでは到達できないコンテキストを対象としている。
500
+
501
+
% ============ 12. CONCLUSION ============
502
+
503
+
\section{結論}
504
+
505
+
\ac{}は、クリエイティブコンピューティングプラットフォームがグラフィカルIDEではなくテキストプロンプトを中心に構成できること、ソーシャルインフラストラクチャをランタイムに直接統合することで外部ソーシャルレイヤーとは異なるエンゲージメントパターンを生み出すこと、そしてモバイルファーストでブラウザネイティブなアプローチによりデスクトップツールでは到達できないコンテキストでクリエイティブコーディングをアクセス可能にすることを実証している。
506
+
507
+
本プラットフォームの354の組み込みピース、265のユーザー公開ピース、16,244のKidLispプログラムは、成長を続けるクリエイティブコンピューティング作品のコーパスを構成している。プロンプトが楽器であるという比喩——ユーザーがメニューナビゲーションではなく記憶と即興を通じて流暢さを構築すること——は、人々とクリエイティブソフトウェアとの関係のオルタナティブモデルを提供する。
508
+
509
+
ACはISCライセンスの下でオープンソースであり、\url{https://github.com/digitpain/aesthetic.computer}で公開されている。
510
+
511
+
\vspace{0.5em}
512
+
\noindent\textit{英語原版からの翻訳。原版は \url{https://papers.aesthetic.computer} を参照。}
513
+
514
+
\vspace{0.5em}
515
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
516
+
517
+
% ============ REFERENCES ============
518
+
519
+
\bibliographystyle{plainnat}
520
+
\bibliography{references}
521
+
522
+
\end{document}
+13
-11
papers/arxiv-api/api-cards.tex
+13
-11
papers/arxiv-api/api-cards.tex
···
107
107
\thispagestyle{empty}
108
108
\vspace*{\fill}
109
109
\begin{center}
110
-
\includegraphics[height=8em]{pals}\par\vspace{0.3em}
111
-
{\acbold\fontsize{20pt}{24pt}\selectfont\color{acdark} From \texttt{setup()} to \texttt{boot()}}\par
112
-
\vspace{0.3em}
113
-
{\fontsize{10pt}{12pt}\selectfont\color{acpink} Processing at the Core of the Piece API}\par
114
-
\vspace{0.8em}
115
-
{\normalsize\color{cyan!70!blue}\textbf{@jeffrey}}\par
110
+
\includegraphics[height=9em]{pals}\par\vspace{0.1em}
111
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} From \texttt{setup()} to \texttt{boot()}}\par
112
+
\vspace{0.1em}
113
+
{\fontsize{9pt}{11pt}\selectfont\color{acpink} Processing at the Core of the Piece API}\par
114
+
\vspace{0.4em}
115
+
{\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par
116
116
{\small\color{acgray} Aesthetic.Computer}\par
117
117
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
118
-
\vspace{0.8em}
119
-
\rule{0.6\textwidth}{1pt}\par
120
118
\vspace{0.4em}
121
-
{\small\color{acpink!40}\textit{working draft --- not for citation}}\par
122
-
\vspace{0.3em}
123
-
{\footnotesize\color{acgray} March 2026}\par
119
+
\rule{0.5\textwidth}{0.5pt}\par
120
+
\vspace{0.15em}
121
+
\colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par
122
+
\vspace{0.1em}
123
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/2113ef735}{2113ef735}}\par
124
+
\vspace{0.1em}
125
+
{\footnotesize\color{acgray}\href{https://papers.aesthetic.computer/piece-api-26-arxiv-da-cards.pdf}{Dansk} · \href{https://papers.aesthetic.computer/piece-api-26-arxiv-es-cards.pdf}{Español} · \href{https://papers.aesthetic.computer/piece-api-26-arxiv-zh-cards.pdf}{{\accjk 中文}} · \href{https://papers.aesthetic.computer/piece-api-26-arxiv-ja-cards.pdf}{{\accjk 日本語}}}\par
124
126
\end{center}
125
127
\vspace*{\fill}
126
128
+765
papers/arxiv-api/api-ja.tex
+765
papers/arxiv-api/api-ja.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
\usepackage{xeCJK}
11
+
\setCJKmainfont{Droid Sans Japanese}
12
+
\setmainfont{Latin Modern Roman}
13
+
\setsansfont{Latin Modern Sans}
14
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
15
+
\newfontfamily\acbold{ywft-processing-bold}[
16
+
Path=../../system/public/type/webfonts/,
17
+
Extension=.ttf
18
+
]
19
+
\newfontfamily\aclight{ywft-processing-light}[
20
+
Path=../../system/public/type/webfonts/,
21
+
Extension=.ttf
22
+
]
23
+
24
+
% === PACKAGES ===
25
+
\usepackage{xcolor}
26
+
\usepackage{titlesec}
27
+
\usepackage{enumitem}
28
+
\usepackage{booktabs}
29
+
\usepackage{tabularx}
30
+
\usepackage{fancyhdr}
31
+
\usepackage{hyperref}
32
+
\usepackage{graphicx}
33
+
\usepackage{ragged2e}
34
+
\usepackage{listings}
35
+
\usepackage{natbib}
36
+
\usepackage[colorspec=0.92]{draftwatermark}
37
+
38
+
% === COLORS ===
39
+
\definecolor{acpink}{RGB}{180,72,135}
40
+
\definecolor{acpurple}{RGB}{120,80,180}
41
+
\definecolor{acdark}{RGB}{64,56,74}
42
+
\definecolor{acgray}{RGB}{119,119,119}
43
+
\definecolor{draftcolor}{RGB}{180,72,135}
44
+
45
+
% === DRAFT WATERMARK ===
46
+
\DraftwatermarkOptions{
47
+
text=WORKING DRAFT,
48
+
fontsize=3cm,
49
+
color=draftcolor!18,
50
+
angle=45,
51
+
pos={0.5\paperwidth, 0.5\paperheight}
52
+
}
53
+
54
+
% === JS SYNTAX COLORS ===
55
+
\definecolor{jskw}{RGB}{119,51,170}
56
+
\definecolor{jsfn}{RGB}{0,136,170}
57
+
\definecolor{jsstr}{RGB}{170,120,0}
58
+
\definecolor{jsnum}{RGB}{204,0,102}
59
+
\definecolor{jscmt}{RGB}{102,102,102}
60
+
61
+
% === PROCESSING SYNTAX COLORS ===
62
+
\definecolor{pjkw}{RGB}{204,102,0}
63
+
\definecolor{pjfn}{RGB}{0,102,153}
64
+
\definecolor{pjcmt}{RGB}{102,102,102}
65
+
66
+
% === HYPERREF ===
67
+
\hypersetup{
68
+
colorlinks=true,
69
+
linkcolor=acpurple,
70
+
urlcolor=acpurple,
71
+
citecolor=acpurple,
72
+
pdfauthor={@jeffrey},
73
+
pdftitle={setup()からboot()へ：ピースAPIの核心におけるProcessingの継承},
74
+
}
75
+
76
+
% === SECTION FORMATTING ===
77
+
\titleformat{\section}
78
+
{\normalfont\bfseries\normalsize\uppercase}
79
+
{\thesection.}
80
+
{0.5em}
81
+
{}
82
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
83
+
84
+
\titleformat{\subsection}
85
+
{\normalfont\bfseries\small}
86
+
{\thesubsection}
87
+
{0.5em}
88
+
{}
89
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
90
+
91
+
\titleformat{\subsubsection}
92
+
{\normalfont\itshape\small}
93
+
{\thesubsubsection}
94
+
{0.5em}
95
+
{}
96
+
\titlespacing{\subsubsection}{0pt}{0.6em}{0.1em}
97
+
98
+
% === HEADER/FOOTER ===
99
+
\pagestyle{fancy}
100
+
\fancyhf{}
101
+
\renewcommand{\headrulewidth}{0pt}
102
+
\fancyhead[C]{\footnotesize\color{draftcolor}\textit{作業草稿 --- 引用不可}}
103
+
\fancyfoot[C]{\footnotesize\thepage}
104
+
105
+
% === LIST SETTINGS ===
106
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
107
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
108
+
109
+
% === COLUMN SEPARATION ===
110
+
\setlength{\columnsep}{1.8em}
111
+
112
+
% === PARAGRAPH SETTINGS ===
113
+
\setlength{\parindent}{1em}
114
+
\setlength{\parskip}{0.3em}
115
+
116
+
% Hyphenation for narrow two-column layout
117
+
\tolerance=800
118
+
\emergencystretch=1em
119
+
\hyphenpenalty=50
120
+
121
+
% === LISTINGS ===
122
+
\lstdefinelanguage{processing}{
123
+
morekeywords=[1]{void,int,float,boolean,color,String,class,new,if,else,for,while,return,public,private,extends,import},
124
+
morekeywords=[2]{setup,draw,mousePressed,mouseDragged,keyPressed,size,background,stroke,noStroke,fill,noFill,line,rect,ellipse,point,triangle,beginShape,endShape,vertex,translate,rotate,scale,pushMatrix,popMatrix,frameRate,width,height,mouseX,mouseY,pmouseX,pmouseY,key,keyCode,mouseButton,frameCount},
125
+
sensitive=true,
126
+
morecomment=[l]{//},
127
+
morecomment=[s]{/*}{*/},
128
+
morestring=[b]",
129
+
}
130
+
131
+
\lstdefinelanguage{p5js}{
132
+
morekeywords=[1]{function,let,const,var,if,else,for,while,return,new,class,export},
133
+
morekeywords=[2]{setup,draw,mousePressed,mouseDragged,keyPressed,createCanvas,background,stroke,noStroke,fill,noFill,line,rect,ellipse,point,triangle,beginShape,endShape,vertex,translate,rotate,scale,push,pop,frameRate,width,height,mouseX,mouseY,pmouseX,pmouseY,key,keyCode,mouseButton,frameCount,createGraphics,random,noise,map,constrain,dist,lerp},
134
+
sensitive=true,
135
+
morecomment=[l]{//},
136
+
morestring=[b]",
137
+
morestring=[b]',
138
+
morestring=[b]`,
139
+
}
140
+
141
+
\lstdefinelanguage{acjs}{
142
+
morekeywords=[1]{function,export,const,let,var,return,if,else,new,async,await,import,from,for},
143
+
morekeywords=[2]{wipe,ink,line,box,circle,write,screen,params,colon,jump,send,store,net,sound,speaker,pen,event,boot,paint,act,sim,leave,paste,plot,poly,flood,form,cursor,handle,num,geo,ui},
144
+
sensitive=true,
145
+
morecomment=[l]{//},
146
+
morestring=[b]",
147
+
morestring=[b]',
148
+
morestring=[b]`,
149
+
}
150
+
151
+
\lstdefinestyle{processingstyle}{
152
+
language=processing,
153
+
keywordstyle=[1]\color{pjkw}\bfseries,
154
+
keywordstyle=[2]\color{pjfn}\bfseries,
155
+
commentstyle=\color{pjcmt}\itshape,
156
+
stringstyle=\color{jsstr},
157
+
}
158
+
159
+
\lstdefinestyle{p5style}{
160
+
language=p5js,
161
+
keywordstyle=[1]\color{jskw}\bfseries,
162
+
keywordstyle=[2]\color{pjfn}\bfseries,
163
+
commentstyle=\color{jscmt}\itshape,
164
+
stringstyle=\color{jsstr},
165
+
}
166
+
167
+
\lstdefinestyle{acjsstyle}{
168
+
language=acjs,
169
+
keywordstyle=[1]\color{jskw}\bfseries,
170
+
keywordstyle=[2]\color{jsfn}\bfseries,
171
+
commentstyle=\color{jscmt}\itshape,
172
+
stringstyle=\color{jsstr},
173
+
}
174
+
175
+
\lstset{
176
+
basicstyle=\ttfamily\small,
177
+
breaklines=true,
178
+
frame=single,
179
+
rulecolor=\color{acgray!30},
180
+
backgroundcolor=\color{acgray!5},
181
+
xleftmargin=0.5em,
182
+
xrightmargin=0.5em,
183
+
aboveskip=0.5em,
184
+
belowskip=0.5em,
185
+
numbers=none,
186
+
tabsize=2,
187
+
}
188
+
189
+
\newcommand{\acdot}{{\color{acpink}.}}
190
+
\newcommand{\ac}{\textsc{Aesthetic.Computer}}
191
+
192
+
\begin{document}
193
+
194
+
% ============ TITLE BLOCK ============
195
+
196
+
\twocolumn[{%
197
+
\begin{center}
198
+
{\acbold\fontsize{22pt}{26pt}\selectfont\color{acdark} \texttt{setup()} から \texttt{boot()} へ}\par
199
+
\vspace{0.2em}
200
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} ピースAPIの核心におけるProcessingの継承}\par
201
+
\vspace{0.6em}
202
+
{\normalsize @jeffrey}\par
203
+
{\small\color{acgray} Aesthetic.Computer}\par
204
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
205
+
\vspace{0.3em}
206
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
207
+
\vspace{0.6em}
208
+
\rule{\textwidth}{1.5pt}
209
+
\vspace{0.5em}
210
+
\end{center}
211
+
212
+
\begin{center}
213
+
{\small\color{draftcolor}\textbf{[ 作業草稿 --- 引用不可 ]}}
214
+
\end{center}
215
+
\vspace{0.3em}
216
+
217
+
\begin{quote}
218
+
\small\noindent\textbf{概要。}
219
+
すべてのクリエイティブコーディングプラットフォームはコアAPIを定義する——プログラムが世界を感知し、その上に描画するための基本関数のセットである。Processingは2001年に\texttt{setup()}/\texttt{draw()}とグローバル描画プリミティブ（\texttt{background()}、\texttt{stroke()}、\texttt{ellipse()}）によるパターンを確立し、このパターンは20年にわたるクリエイティブコーディングツールに影響を与えた。p5.jsは2014年にこのモデルをブラウザに持ち込み、JavaScriptとDOMに適応させながらAPIサーフェスを維持した。\ac{}（AC）は2021年に開始され、その核心においてProcessingの思想を継承しつつ、複数の構造的次元で拡張している：2関数ライフサイクルを5つ（\texttt{boot}、\texttt{paint}、\texttt{act}、\texttt{sim}、\texttt{leave}）に拡張し、グローバル状態をデストラクチャリングによるAPI注入に置き換え、シミュレーションとレンダリングを異なる周波数で分離し、各プログラムをビルドステップなしでURLアドレス可能にしている。本稿では、Processingの理念がACピースAPIにどのように存在しているかを追跡し、Design By Numbers、Processing、p5.js、ACのライフサイクルモデル、描画プリミティブ、入力処理、状態管理戦略を比較する。ACのAPI設計——Processingの即時モードグラフィックスモデルを基盤として——が\emph{スケッチブック}の比喩（書く、実行する、捨てる）を\emph{楽器}の比喩（起動する、演奏する、練習する、戻る）へと拡張することを論じる。
220
+
\end{quote}
221
+
\vspace{0.5em}
222
+
}]
223
+
224
+
% ============ 1. INTRODUCTION ============
225
+
226
+
\section{はじめに}
227
+
228
+
クリエイティブコーディングAPIの歴史は、プログラマーが最初に何を言うべきかを決定する歴史である。Design By Numbers~\citep{maeda2001dbn}では、最初のステートメントは座標とグレースケール値だった：\texttt{Paper 50}。Processing~\citep{reas2003processing}では、\texttt{setup()}内の\texttt{size(200, 200)}だった。p5.js~\citep{mccarthy2015p5js}では、\texttt{createCanvas(400, 400)}だった。\ac{}では、プログラマーはキャンバスを宣言する必要が一切ない——ランタイムが\texttt{screen.width}と\texttt{screen.height}を既成事実として提供し、最初の意味のあるステートメントは通常\texttt{wipe()}——描画を開始するための画面クリア——である。
229
+
230
+
これらは恣意的な違いではない。それぞれがプラットフォームの前提とプログラマーが指定すべきものとの間の決定を反映しており、これらの決定が蓄積されることで、著者とマシンの間に根本的に異なる関係が形成される。本稿ではProcessingからp5.jsを経てACへのAPI系譜を追跡し、各遷移を一連の設計決定として捉える：何が保持され、何が変更され、その変更が何を意味するか。
231
+
232
+
本稿の貢献は3つある：（1）Processing、p5.js、ACのライフサイクルモデル、描画API、入力システム、状態管理戦略の詳細な技術比較、（2）ACがProcessingモデルから逸脱した背景にある設計思想の分析、（3）ACピースAPIがスケッチブックの比喩から\emph{楽器の比喩}と呼ぶものへの移行を体現しているという議論——プログラマーとプログラムの関係が、探索的で使い捨てのものではなく、継続的で、パフォーマティブで、練習に基づくものであるモデル。
233
+
234
+
% ============ 2. THE PROCESSING MODEL ============
235
+
236
+
\section{Processingモデル（2001年）}
237
+
\label{sec:processing}
238
+
239
+
Processing~\citep{reas2007processing}はビジュアルアーティストのための「ソフトウェアスケッチブック」として設計された。そのAPIは2つのライフサイクル関数とグローバル描画プリミティブのセットを中心としている。
240
+
241
+
\subsection{ライフサイクル：\texttt{setup()}と\texttt{draw()}}
242
+
243
+
\begin{lstlisting}[style=processingstyle,caption={最小限のProcessingスケッチ。}]
244
+
void setup() {
245
+
size(400, 400);
246
+
background(0);
247
+
}
248
+
249
+
void draw() {
250
+
stroke(255);
251
+
ellipse(mouseX, mouseY, 20, 20);
252
+
}
253
+
\end{lstlisting}
254
+
255
+
\texttt{setup()}は1回実行され、\texttt{draw()}はデフォルト60fpsの頻度で毎フレーム実行される。この2関数モデルはProcessingの最も影響力のある設計決定である。アニメーションの認知的オーバーヘッドを、レンダリングループの管理から2つの空欄を埋めることに削減した：「1回だけ起こることは何か？」と「毎フレーム起こることは何か？」
256
+
257
+
このモデルは意図的に最小限に保たれている。明示的な\texttt{input()}関数はなく、マウスとキーボードの状態は自動更新されるグローバル変数（\texttt{mouseX}、\texttt{mouseY}、\texttt{key}、\texttt{keyCode}）として利用可能である。イベントコールバック（\texttt{mousePressed()}、\texttt{keyPressed()}）は存在するが、必須のエントリポイントではなくオプションの補助である。
258
+
259
+
\subsection{描画プリミティブ}
260
+
261
+
Processingの描画APIはPostScriptとOpenGLから継承した\emph{ステートフルパイプライン}モデルを採用している：状態設定呼び出し（\texttt{stroke()}、\texttt{fill()}、\texttt{strokeWeight()}）が永続的なグラフィックスコンテキストを変更し、形状呼び出し（\texttt{ellipse()}、\texttt{rect()}、\texttt{line()}）がそのコンテキストを使用してレンダリングする。コンテキストは明示的にリセットされない限りフレーム間で持続する。
262
+
263
+
\begin{lstlisting}[style=processingstyle,caption={ステートフル描画コンテキスト。}]
264
+
void draw() {
265
+
fill(255, 0, 0); // Set fill: red
266
+
stroke(0); // Set stroke: black
267
+
strokeWeight(3); // Set weight: 3px
268
+
ellipse(100, 100, 50, 50); // Uses above
269
+
rect(200, 100, 50, 50); // Also uses above
270
+
// State persists into next frame
271
+
}
272
+
\end{lstlisting}
273
+
274
+
この状態の持続性は強力（統一されたスタイルに必要なコードが少ない）であると同時にエラーを招きやすい（忘れられた状態がフレーム間でリークする）。Processingは\texttt{pushStyle()}/\texttt{popStyle()}と\texttt{pushMatrix()}/\texttt{popMatrix()}で対処しているが、これらは上級者向けツールである。
275
+
276
+
\subsection{グローバルスコープ}
277
+
278
+
すべてのProcessingプログラムは単一のグローバル名前空間を共有する。\texttt{setup()}と\texttt{draw()}の外部で宣言された変数はどこからでもアクセス可能である。描画関数（\texttt{line()}、\texttt{ellipse()}、\texttt{background()}）はグローバルである。入力変数（\texttt{mouseX}、\texttt{mouseY}）はグローバルである。これによりスコープ、インポート、依存性注入の理解が不要になる——初心者にとって極めて重要——が、プログラムを組み合わせたり分離したりすることが不可能になる。
279
+
280
+
% ============ 3. THE P5.JS TRANSITION ============
281
+
282
+
\section{p5.jsへの移行（2014年）}
283
+
\label{sec:p5js}
284
+
285
+
p5.js~\citep{mccarthy2015p5js}はProcessingのJavaScript再実装である。主要な貢献はProcessingモデルをブラウザに持ち込んだことだが、移植にはいくつかの適応が必要だった。
286
+
287
+
\subsection{ライフサイクルの維持}
288
+
289
+
\begin{lstlisting}[style=p5style,caption={最小限のp5.jsスケッチ。}]
290
+
function setup() {
291
+
createCanvas(400, 400);
292
+
}
293
+
294
+
function draw() {
295
+
background(220);
296
+
ellipse(mouseX, mouseY, 50, 50);
297
+
}
298
+
\end{lstlisting}
299
+
300
+
\texttt{setup()}/\texttt{draw()}モデルはそのまま維持された。認知モデルは同一：2つの関数、グローバル描画プリミティブ、自動アニメーションループ。この連続性は意図的であった——p5.jsはWeb上のProcessingであることを目指しており、新しい言語ではなかった。
301
+
302
+
\subsection{キャンバス作成}
303
+
304
+
最も明白な変更は\texttt{createCanvas()}が\texttt{size()}を置き換えたことである。これは表面的な変更ではない：Processingでは\texttt{size()}がアプリケーションウィンドウを構成するが、p5.jsでは\texttt{createCanvas()}がDOM内にHTML \texttt{<canvas>}要素を作成する。スケッチは表示領域全体を占有するのではなく、既存のページと折り合いを付けなければならない。
305
+
306
+
\subsection{インスタンスモード}
307
+
308
+
p5.jsはグローバル名前空間からの重要な脱出口を導入した：\emph{インスタンスモード}。
309
+
310
+
\begin{lstlisting}[style=p5style,caption={p5.jsインスタンスモード。}]
311
+
const sketch = (p) => {
312
+
p.setup = () => {
313
+
p.createCanvas(400, 400);
314
+
};
315
+
p.draw = () => {
316
+
p.background(220);
317
+
p.ellipse(p.mouseX, p.mouseY, 50, 50);
318
+
};
319
+
};
320
+
new p5(sketch);
321
+
\end{lstlisting}
322
+
323
+
インスタンスモードはすべてのAPI関数を名前空間（\texttt{p.}）の後ろにラップし、1つのページ上に複数のスケッチを配置でき、グローバル汚染を回避できる。しかし、ほとんどのp5.jsコードはグローバルモードで書かれ、インスタンスモードはスケッチをより大きなアプリケーションに埋め込むときにのみ使用される。プレフィックス記法（\texttt{p.ellipse}対\texttt{ellipse}）は冗長性を増し、Processingを魅力的にした「直接書く」品質を低下させる。
324
+
325
+
\subsection{変わったものと変わらなかったもの}
326
+
327
+
p5.jsが維持したもの：2関数ライフサイクル、グローバル描画プリミティブ、ステートフルグラフィックスコンテキスト、フレームベースアニメーション、「スケッチ」のアイデンティティ。適応したもの：DOM向けキャンバス作成、レンダラー選択（2D/WebGL）、ブラウザイベント向けイベント処理、組み合わせ用インスタンスモードの追加。解決しなかったもの：シミュレーションとレンダリングの混同、構造化された入力処理の欠如、単一ファイル分離の問題。
328
+
329
+
% ============ 4. THE AC PIECE API ============
330
+
331
+
\section{ACピースAPI（2021年--）}
332
+
\label{sec:ac}
333
+
334
+
\ac{}のピースAPI~\citep{scudder2026ac}はProcessingの核心的な洞察——即時モードグラフィックス、単一ファイルプログラム、ライフサイクル関数——の上に構築され、2つではなく5つの関心事を中心に拡張している。
335
+
336
+
\subsection{5つのライフサイクル関数}
337
+
338
+
\begin{lstlisting}[style=acjsstyle,caption={最小限のACピース。}]
339
+
function boot({ screen, params }) {
340
+
// Runs once on load
341
+
}
342
+
343
+
function paint({ wipe, ink, line, screen }) {
344
+
wipe("navy");
345
+
ink("pink").circle(
346
+
screen.width / 2,
347
+
screen.height / 2,
348
+
50
349
+
);
350
+
}
351
+
352
+
function act({ event: e }) {
353
+
if (e.is("keyboard:down:space")) {
354
+
// Handle spacebar
355
+
}
356
+
}
357
+
358
+
function sim() {
359
+
// Update state at 120fps
360
+
}
361
+
362
+
export { boot, paint, act, sim };
363
+
\end{lstlisting}
364
+
365
+
5つの関数は：
366
+
367
+
\begin{itemize}
368
+
\item \texttt{boot(\$api)} --- ピースのロード時に1回実行される。Processingの\texttt{setup()}を拡張し、プログラマーが構成するのではなくランタイムが画面を提供する。
369
+
\item \texttt{paint(\$api)} --- レンダリングが必要なフレームごとに実行される。\texttt{draw()}の即時モードモデルを継承するが、純粋にビジュアル：慣例としてロジックを含まず、状態を変更しない。
370
+
\item \texttt{act(\$api)} --- 各入力イベントにつき1回呼び出される。Processingのイベントコールバック（\texttt{mousePressed()}、\texttt{keyPressed()}）を単一の統一エントリポイントに統合する。
371
+
\item \texttt{sim(\$api)} --- 固定120Hzで実行され、各レンダリングフレーム中に複数回実行される可能性がある。Processingに等価物はない；最も近い類似物は固定タイムステップゲームループ~\citep{nystrom2014game}である。
372
+
\item \texttt{leave(\$api)} --- 終了時のクリーンアップ。Processingに等価物はなく、スケッチは単純に終了する。
373
+
\end{itemize}
374
+
375
+
各関数はオプションである。\texttt{paint}のみをエクスポートするピースも有効で実行可能なプログラムである。
376
+
377
+
\subsection{デストラクチャリングによるAPI注入}
378
+
379
+
Processingモデルに対する最も構造的に重要な拡張は、\textbf{グローバルスコープにAPI関数が一切存在しない}ことである。ピースが使用するすべての関数はパラメータとして受け取る：
380
+
381
+
\begin{lstlisting}[style=acjsstyle,caption={ACにおけるAPIデストラクチャリング。}]
382
+
function paint({ wipe, ink, line, box,
383
+
circle, screen, num }) {
384
+
wipe(0, 0, 30);
385
+
ink(255, 100, 180);
386
+
const cx = num.lerp(0, screen.width, 0.5);
387
+
circle(cx, screen.height / 2, 40);
388
+
}
389
+
\end{lstlisting}
390
+
391
+
この設計にはいくつかの帰結がある：
392
+
393
+
\begin{enumerate}
394
+
\item \textbf{グローバル汚染なし。}モジュールレベルの変数はピースの状態であり、API関数はパラメータである。衝突しうる環境名前空間は存在しない。
395
+
\item \textbf{自己文書化するインポート。}各関数の先頭にあるデストラクチャリングパターンが、その関数が使用するAPIサーフェスを正確に宣言し、インライン依存性マニフェストとして機能する。
396
+
\item \textbf{組み合わせ可能性。}複数のピースがAPI衝突なしに同一のJavaScriptコンテキスト内で共存でき、プラットフォームのピース切り替えと埋め込みメカニズムを実現する。
397
+
\item \textbf{発見可能性。}エディタの自動補完がデストラクチャリングされたパラメータオブジェクトに対して動作し、APIを探索する自然な方法を提供する。
398
+
\end{enumerate}
399
+
400
+
これはp5.jsのインスタンスモードパターンを結論まで推し進めたものである：プログラマーは各呼び出しの前に\texttt{p.}をプレフィックスする代わりに、関数シグネチャで必要な関数のみをデストラクチャリングし、1回で済ませる。
401
+
402
+
\subsection{シミュレーションとレンダリングの分離}
403
+
\label{sec:simsep}
404
+
405
+
Processingの\texttt{draw()}は2つの関心事を混同している：状態の更新とピクセルのレンダリング。これは単純なスケッチでは機能するが、複雑さが増すと問題が生じる：物理シミュレーションがフレームレートに束縛される、入力遅延がレンダリングコストに結合する、「何が起こったか」と「どう見えるか」の分離が困難になる。
406
+
407
+
ACはこれらを明示的に分離する：
408
+
409
+
\begin{itemize}
410
+
\item \texttt{sim()}は表示リフレッシュレートに関係なく固定120Hzで実行される。60Hzディスプレイでは\texttt{sim()}は各\texttt{paint()}呼び出しごとに2回実行される。144Hzディスプレイでは比率が相応に調整される。
411
+
\item \texttt{paint()}はディスプレイのリフレッシュレート（上限約165fps）で実行され、現在の状態のレンダリングのみを担当する。
412
+
\item \texttt{act()}はイベント到着時に即座に実行され、各入力イベントにつき1回。
413
+
\end{itemize}
414
+
415
+
この3方向の分離は現代のゲームエンジンアーキテクチャ~\citep{nystrom2014game}を反映している：決定論的ロジックのための固定更新レート、滑らかな表示のための可変レンダリングレート、入力のためのイベントキュー。違いは、ACがこのアーキテクチャをフレームワークの背後に隠すのではなく、第一級APIとして公開していることである。
416
+
417
+
\subsection{統一されたイベント処理}
418
+
419
+
Processingは入力処理をグローバル変数とオプションのコールバックに分散させている：
420
+
421
+
\begin{lstlisting}[style=processingstyle]
422
+
// Processing: scattered input model
423
+
void draw() {
424
+
if (mousePressed) { /* poll state */ }
425
+
}
426
+
void mousePressed() { /* callback */ }
427
+
void keyPressed() { /* callback */ }
428
+
void mouseDragged() { /* callback */ }
429
+
\end{lstlisting}
430
+
431
+
ACは文字列ベースのイベントマッチングシステムにより、すべての入力を\texttt{act()}に統合する：
432
+
433
+
\begin{lstlisting}[style=acjsstyle]
434
+
function act({ event: e, pen }) {
435
+
if (e.is("touch")) { }
436
+
if (e.is("draw")) { }
437
+
if (e.is("lift")) { }
438
+
if (e.is("keyboard:down:a")) { }
439
+
if (e.is("keyboard:down:space")){ }
440
+
if (e.is("gamepad:a")) { }
441
+
if (e.is("reframed")) { }
442
+
}
443
+
\end{lstlisting}
444
+
445
+
\texttt{event.is()}パターンは、入力モダリティ（タッチ、マウス、キーボード、ゲームパッド、MIDI、ハンドトラッキング）を横断する統一インターフェースを単一の関数で提供する。イベント文字列は階層的（\texttt{keyboard:down:a}）であり、任意の特異性レベルでマッチングできる。これはProcessingコールバックの組み合わせ爆発を、単一のフィルタ可能なストリームに置き換える。
446
+
447
+
\subsection{描画プリミティブ：デフォルトでステートレス}
448
+
449
+
Processingとp5.jsは、\texttt{fill()}、\texttt{stroke()}、変換呼び出しが明示的に変更されるまで持続するステートフルグラフィックスコンテキストを使用する。ACはこれを反転する：\texttt{ink()}関数は\emph{直後の}描画呼び出しのために色を設定し、チェーン呼び出しをサポートするAPIオブジェクトを返す：
450
+
451
+
\begin{lstlisting}[style=acjsstyle]
452
+
function paint({ wipe, ink, line, circle }) {
453
+
wipe("black");
454
+
ink("red").circle(50, 50, 20);
455
+
ink("blue").line(0, 0, 100, 100);
456
+
// No state leaks between calls
457
+
}
458
+
\end{lstlisting}
459
+
460
+
\texttt{ink()}の戻り値チェーンパターンにより、色-形状のペアが視覚的にアトミックになる：各描画操作はコンテキスト変更のシーケンスではなく、自己完結した式である。これにより、あるカテゴリのバグが排除される：前のフレーム（または前の関数）から忘れられた\texttt{fill()}や\texttt{stroke()}呼び出しが無関係な描画操作に漏れ出すことがなくなる。
461
+
462
+
\texttt{wipe()}関数はProcessingの\texttt{background()}を置き換え、より短く能動的な動詞を使用している。この命名は意図的である：「wipe」（拭く）は属性設定ではなく物理的動作（表面を拭く）を暗示する。
463
+
464
+
\subsection{キャンバス構成不要}
465
+
466
+
Processingでは\texttt{setup()}の最初の行は通常\texttt{size(w, h)}である。p5.jsでは\texttt{createCanvas(w, h)}である。ACでは等価の呼び出しがない。ランタイムがデバイスのネイティブ解像度でキャンバスを提供し、ピースは読み取り専用プロパティ\texttt{screen.width}と\texttt{screen.height}を通じて受け取る。
467
+
468
+
これはモバイルファーストの設計思想を反映している：スマートフォンとタブレットでは「正しい」キャンバスサイズはデバイスの画面である。プログラマーにサイズを指定させると、固定キャンバスと可変ビューポートの間にミスマッチが生じる。ACはキャンバスをデフォルトでアダプティブにすることで、このミスマッチを排除する。
469
+
470
+
% ============ 5. API SURFACE COMPARISON ============
471
+
472
+
\section{APIサーフェス比較}
473
+
\label{sec:comparison}
474
+
475
+
表~\ref{tab:lifecycle}はライフサイクルモデルを比較する。表~\ref{tab:drawing}は描画プリミティブを比較する。
476
+
477
+
\begin{table}[h]
478
+
\small
479
+
\centering
480
+
\begin{tabularx}{\columnwidth}{lXXX}
481
+
\toprule
482
+
& \textbf{Processing} & \textbf{p5.js} & \textbf{AC} \\
483
+
\midrule
484
+
初期化 & \texttt{setup()} & \texttt{setup()} & \texttt{boot(\$)} \\
485
+
レンダリング & \texttt{draw()} & \texttt{draw()} & \texttt{paint(\$)} \\
486
+
ロジック & （draw内） & （draw内） & \texttt{sim(\$)} \\
487
+
入力 & コールバック & コールバック & \texttt{act(\$)} \\
488
+
クリーンアップ & --- & \texttt{remove()} & \texttt{leave(\$)} \\
489
+
\midrule
490
+
レンダリング周波数 & 60fps & 60fps & ディスプレイHz \\
491
+
ロジック周波数 & 60fps & 60fps & 120fps固定 \\
492
+
スコープ & グローバル & グローバル/インスタンス & 注入 \\
493
+
\bottomrule
494
+
\end{tabularx}
495
+
\caption{ライフサイクル比較。\texttt{\$}はデストラクチャリングによるAPI注入を示す。}
496
+
\label{tab:lifecycle}
497
+
\end{table}
498
+
499
+
\begin{table}[h]
500
+
\small
501
+
\centering
502
+
\begin{tabularx}{\columnwidth}{lXX}
503
+
\toprule
504
+
\textbf{Processing/p5} & \textbf{AC} & \textbf{備考} \\
505
+
\midrule
506
+
\texttt{background()} & \texttt{wipe()} & 動詞、属性ではない \\
507
+
\texttt{fill() + stroke()} & \texttt{ink()} & 統合、チェーン可能 \\
508
+
\texttt{ellipse()} & \texttt{circle()} & 形状で命名 \\
509
+
\texttt{rect()} & \texttt{box()} & より短い名前 \\
510
+
\texttt{line()} & \texttt{line()} & 変更なし \\
511
+
\texttt{point()} & \texttt{plot()} & グラフィックスの比喩 \\
512
+
\texttt{text()} & \texttt{write()} & 能動的動詞 \\
513
+
--- & \texttt{flood()} & 領域塗りつぶし \\
514
+
--- & \texttt{paste()} & バッファ合成 \\
515
+
--- & \texttt{form()} & 3Dレンダリング \\
516
+
\bottomrule
517
+
\end{tabularx}
518
+
\caption{描画プリミティブ比較。}
519
+
\label{tab:drawing}
520
+
\end{table}
521
+
522
+
\subsection{命名哲学}
523
+
524
+
ProcessingのAPI名は記述的な名詞と形容詞である：\texttt{background}、\texttt{ellipse}、\texttt{rect}、\texttt{stroke}、\texttt{fill}。設定または描画される\emph{もの}を記述する。ACの名前は能動的な動詞である：\texttt{wipe}、\texttt{ink}、\texttt{plot}、\texttt{write}、\texttt{flood}、\texttt{paste}。\emph{プログラマーが何をしているか}——表面に対して行う物理的動作——を記述する。
525
+
526
+
記述的命名から命令的命名への移行は楽器の比喩と一致する：楽器のインターフェースは動詞（押す、吹く、叩く、弾く）で理解されるのであり、名詞ではない。AC APIは一連の動作として読める：「画面を拭く、ピンクのインクを付ける、円を描く、テキストを書く。」
527
+
528
+
\subsection{カラーモデル}
529
+
530
+
Processingは独立した\texttt{fill()}と\texttt{stroke()}呼び出しを使用し、それぞれがRGB、HSB、16進値を受け取る。fill/strokeの区別はベクターグラフィックス（SVG、PostScript）にマッピングされ、形状が内部色と境界色を持つ。
531
+
532
+
ACは単一の\texttt{ink()}呼び出しを使用し、後続のすべての操作の色を設定する。fill/strokeの区別はない：\texttt{circle()}がフィルかストロークかは環境コンテキストではなく引数に依存する。\texttt{ink()}関数は以下を受け取る：
533
+
534
+
\begin{itemize}
535
+
\item RGB値：\texttt{ink(255, 100, 50)}
536
+
\item 名前付き色：\texttt{ink("pink")}、\texttt{ink("navy")}
537
+
\item グレースケール：\texttt{ink(128)}
538
+
\item アルファ：\texttt{ink(255, 0, 0, 128)}
539
+
\end{itemize}
540
+
541
+
名前付き色は初心者にとって重要なユーザビリティの選択である。Processingがピンクを得るために\texttt{fill(255, 192, 203)}を必要とするところ、ACは\texttt{ink("pink")}を受け付ける。名前付き色のボキャブラリーは意図的に小さく喚起力に富み、パレットよりも絵具箱に近い。
542
+
543
+
% ============ 6. STATE MANAGEMENT ============
544
+
545
+
\section{状態管理}
546
+
\label{sec:state}
547
+
548
+
\subsection{Processing：グローバル変数}
549
+
550
+
\begin{lstlisting}[style=processingstyle]
551
+
int x = 100;
552
+
int y = 100;
553
+
554
+
void draw() {
555
+
background(0);
556
+
x += 1;
557
+
ellipse(x, y, 20, 20);
558
+
}
559
+
\end{lstlisting}
560
+
561
+
Processingにおける状態はグローバル変数に存在する。これはシンプルだが、よく知られた問題がある：すべての状態がどこからでも変更可能で、カプセル化がなく、プログラム状態とAPI状態が区別できない。
562
+
563
+
\subsection{AC：モジュールレベルクロージャ}
564
+
565
+
\begin{lstlisting}[style=acjsstyle]
566
+
let x = 100;
567
+
let y = 100;
568
+
569
+
function sim() {
570
+
x += 1;
571
+
}
572
+
573
+
function paint({ wipe, ink, circle }) {
574
+
wipe(0);
575
+
ink(255).circle(x, y, 20);
576
+
}
577
+
578
+
export { sim, paint };
579
+
\end{lstlisting}
580
+
581
+
ACピースはESモジュールである。モジュールスコープで宣言された変数はピースにプライベートであり、ランタイム、他のピース、グローバルスコープからは見えない。\texttt{export}文はライフサイクル関数のみを可視にする。これはドキュメントで強制される慣例ではなく、JavaScriptモジュールシステムによる保証である。
582
+
583
+
状態の変更（\texttt{sim}）と状態のレンダリング（\texttt{paint}）の分離は、\texttt{paint}がモジュール状態の純粋関数であるという規律を促進する——変数を読み取り描画するが、変更しない。これは強制されないが、API構造がそれを自然なパターンにする。
584
+
585
+
% ============ 7. THE GENEALOGY ============
586
+
587
+
\section{系譜}
588
+
\label{sec:genealogy}
589
+
590
+
\subsection{Design By Numbers（1999年）}
591
+
592
+
MaedaのDesign By Numbers~\citep{maeda2001dbn}は核心的な洞察を導入した：最もシンプルなAPIを持つビジュアル出力のためのプログラミング環境。DBNにはアニメーションループがなく、プログラムは上から下へ1回実行される。プリミティブセットは最小限：\texttt{Paper}（背景）、\texttt{Pen}（線の太さ）、\texttt{Line}、\texttt{Set}（ピクセル）、および制御フロー。言語全体が午後のうちに学べる。
593
+
594
+
ACはDBNの命名のミニマリズム（短い能動的動詞）と、APIは網羅的に学習可能であるべきだという確信を継承している。
595
+
596
+
\subsection{Processing（2001年）}
597
+
598
+
Processing~\citep{reas2003processing}はDBNに欠けていたものを追加した：アニメーション（\texttt{draw()}ループ）、インタラクション（\texttt{mouseX/Y}）、より豊富なプリミティブセット。またDBNが意図的に避けたものも追加した：状態（グラフィックスコンテキスト）、標準ライブラリ（数学、タイポグラフィ、画像読み込み）、コンパイルステップ（Java）。Processingの最大のイノベーションは個々の関数ではなく、\texttt{setup()}/\texttt{draw()}のペア：インタラクティブアニメーションの最も単純な表現である。
599
+
600
+
ACはライフサイクル関数モデルを継承するが、\texttt{draw()}を3つの関心事（\texttt{paint}、\texttt{sim}、\texttt{act}）に分割する。
601
+
602
+
\subsection{p5.js（2014年）}
603
+
604
+
p5.js~\citep{mccarthy2015p5js}はProcessingをブラウザに持ち込み、スケッチをURL経由で即座に共有可能にした。これはACの前提条件：クリエイティブプラットフォームとしてのブラウザ。p5.jsはまたインスタンスモードを導入し、ACのAPI注入パターンを先取りした。
605
+
606
+
ACはブラウザネイティブの前提と共有可能性の原則（すべてのピースがURL）を継承するが、ページ内ライブラリモデルを完全なランタイムに置き換えた：ピースは\texttt{<script>}タグを含まず、プラットフォームによってロードされる。
607
+
608
+
\subsection{openFrameworks（2005年）}
609
+
610
+
openFrameworks~\citep{openframeworks2005}は類似のライフサイクル（\texttt{setup()}、\texttt{update()}、\texttt{draw()}）を使用するが、C++であり、更新ロジックとレンダリングを分離している。ACの\texttt{sim()}/\texttt{paint()}分離はProcessingの統合\texttt{draw()}よりもこのモデルに近い。
611
+
612
+
\subsection{楽器への転回}
613
+
614
+
系譜は一連の分離として要約できる：
615
+
616
+
\begin{enumerate}
617
+
\item \textbf{DBN}：1回の実行（アニメーションループなし）。
618
+
\item \textbf{Processing}：初期化 + レンダリング（\texttt{setup} + \texttt{draw}）。
619
+
\item \textbf{openFrameworks}：初期化 + 更新 + レンダリング。
620
+
\item \textbf{AC}：初期化 + 入力 + 更新 + レンダリング + クリーンアップ（\texttt{boot} + \texttt{act} + \texttt{sim} + \texttt{paint} + \texttt{leave}）。
621
+
\end{enumerate}
622
+
623
+
各ステップが以前混同されていた関心事を分離する。ACの5関数モデルはインタラクティブプログラムのライフサイクルの最も完全な分解であり、名前付きの単一責任エントリポイントに帰着する。結果は身体化認知の知覚-行動サイクル~\citep{varela1991embodied}に類似する：知覚（\texttt{act}）、思考（\texttt{sim}）、行動（\texttt{paint}）、そして誕生（\texttt{boot}）と死（\texttt{leave}）の2つの追加端点を伴う。
624
+
625
+
% ============ 8. WORKED EXAMPLE ============
626
+
627
+
\section{実例：バウンシングボール}
628
+
\label{sec:example}
629
+
630
+
比較を具体化するため、3つのシステムでバウンシングボールを実装する。
631
+
632
+
\subsection{Processing}
633
+
634
+
\begin{lstlisting}[style=processingstyle]
635
+
float x = 200, y = 200;
636
+
float vx = 3, vy = 2;
637
+
638
+
void setup() {
639
+
size(400, 400);
640
+
}
641
+
642
+
void draw() {
643
+
background(0);
644
+
x += vx; y += vy;
645
+
if (x < 0 || x > width) vx *= -1;
646
+
if (y < 0 || y > height) vy *= -1;
647
+
fill(255, 100, 180);
648
+
noStroke();
649
+
ellipse(x, y, 30, 30);
650
+
}
651
+
\end{lstlisting}
652
+
653
+
ロジックとレンダリングが\texttt{draw()}内で絡み合っている。状態の変更（\texttt{x += vx}）、境界チェック、描画が1つの関数を共有している。
654
+
655
+
\subsection{p5.js}
656
+
657
+
\begin{lstlisting}[style=p5style]
658
+
let x = 200, y = 200;
659
+
let vx = 3, vy = 2;
660
+
661
+
function setup() {
662
+
createCanvas(400, 400);
663
+
}
664
+
665
+
function draw() {
666
+
background(0);
667
+
x += vx; y += vy;
668
+
if (x < 0 || x > width) vx *= -1;
669
+
if (y < 0 || y > height) vy *= -1;
670
+
fill(255, 100, 180);
671
+
noStroke();
672
+
ellipse(x, y, 30, 30);
673
+
}
674
+
\end{lstlisting}
675
+
676
+
構造はProcessingと同一。唯一の変更は構文的：\texttt{let}対\texttt{float}、\texttt{createCanvas}対\texttt{size}。
677
+
678
+
\subsection{AC}
679
+
680
+
\begin{lstlisting}[style=acjsstyle]
681
+
let x, y, vx = 3, vy = 2;
682
+
683
+
function boot({ screen }) {
684
+
x = screen.width / 2;
685
+
y = screen.height / 2;
686
+
}
687
+
688
+
function sim({ screen }) {
689
+
x += vx; y += vy;
690
+
if (x < 0 || x > screen.width) vx *= -1;
691
+
if (y < 0 || y > screen.height) vy *= -1;
692
+
}
693
+
694
+
function paint({ wipe, ink, circle }) {
695
+
wipe(0);
696
+
ink(255, 100, 180).circle(x, y, 15);
697
+
}
698
+
699
+
export { boot, sim, paint };
700
+
\end{lstlisting}
701
+
702
+
関心事が分離されている：\texttt{boot}は実際の画面に基づいて状態を初期化し、\texttt{sim}は120Hzで物理を更新し（ディスプレイリフレッシュレートに関係なく一貫した動作を保証）、\texttt{paint}は状態を変更せずにレンダリングする。\texttt{ink().circle()}チェーンが3行のコード（\texttt{fill}、\texttt{noStroke}、\texttt{ellipse}）を置き換える。
703
+
704
+
% ============ 9. DESIGN RATIONALE ============
705
+
706
+
\section{設計根拠}
707
+
\label{sec:rationale}
708
+
709
+
\subsection{なぜ5つの関数か？}
710
+
711
+
5関数モデルはソフトウェアエンジニアリングの厳密さ（教条としての「関心事の分離」）からではなく、楽器の比喩から生まれた。楽器には異なる段階がある：手に取る（boot）、聴いて応答する（act）、次に何をするか考える（sim）、演奏する（paint）、そして最後に置く（leave）。これらは交換可能な瞬間ではない——演奏中にチューニングはしないし、楽器をしまうときに演奏はしない。ライフサイクル関数はこれらの区別を形式化する。
712
+
713
+
\subsection{なぜAPI注入か？}
714
+
715
+
グローバルAPIは初心者に便利だが、プラットフォームへの暗黙の依存関係を作り出す。\texttt{ellipse()}がユーザー関数ではなくProcessing関数であることを知らなければ、Processingスケッチを理解できない。ACのデストラクチャリングパターンは依存関係を明示的にする：\texttt{circle}が関数本体に現れれば、それは関数シグネチャにも現れる。これはESモジュールのインポートと同じ設計原則を関数レベルで適用したものである。
716
+
717
+
実用的なメリットはホットリロードである：ピースがグローバル参照をキャプチャしないため、ランタイムはリロード間でAPIオブジェクトを置き換えても、ピースのクロージャを無効にしない。
718
+
719
+
\subsection{なぜ120Hzシミュレーションか？}
720
+
721
+
Processingの\texttt{draw()}はディスプレイ周波数（通常60fps）で実行される。これは物理シミュレーション、アニメーションタイミング、入力処理がすべてピクセル出力と同じ頻度で実行されることを意味する。144HzディスプレイではProcessingスケッチは2.4倍速く実行され、30Hzディスプレイでは半分の速度になる。
722
+
723
+
ACは\texttt{sim()}を固定120Hzで実行することにより、シミュレーションとディスプレイを分離する。これにより決定論的な動作が保証される：バウンシングボールはディスプレイリフレッシュレートに関係なく同じ速度で動く。120Hzの頻度は一般的なディスプレイ周波数（60、120）の倍数であり、入力応答性の合理的な上限として選ばれた。
724
+
725
+
\subsection{なぜキャンバスサイズがないのか？}
726
+
727
+
\texttt{size()}や\texttt{createCanvas()}を要求することは、プログラマーが出力解像度を知っている（そして気にしている）ことを前提とする。デスクトップではこれは合理的である。モバイル——ACの主要ターゲット——ではこれは摩擦源となる：「正しい」サイズはデバイス、向き、ピクセル密度に依存し、これらすべてをプログラマーが管理する必要はないはずである。ACは画面を既成事実として提供する——すでに張られ下地が塗られたキャンバスのように。
728
+
729
+
% ============ 10. ADDITIONAL LIFECYCLE ============
730
+
731
+
\section{拡張ライフサイクル}
732
+
\label{sec:extended}
733
+
734
+
コアの5関数に加え、ACピースは追加のライフサイクルフックをエクスポートできる：
735
+
736
+
\begin{itemize}
737
+
\item \texttt{beat(\$api)} --- メトロノームの各ティックで呼び出される。BPMは\texttt{sound.bpm}で設定。Processingに等価物はない；ACの音楽アプリケーションへの志向を反映している。
738
+
\item \texttt{preview(\$api)} --- ピースの静的サムネイルをレンダリングする。ピースリストとソーシャル共有に使用。
739
+
\item \texttt{icon(\$api)} --- ブラウザタブのfaviconをレンダリングする。
740
+
\item \texttt{meta()} --- Open Graphタグ用の\texttt{\{title, desc\}}メタデータを返す。
741
+
\item \texttt{receive(event)} --- 他のピースやシステムからのメッセージを処理し、ピース間通信を実現する。
742
+
\end{itemize}
743
+
744
+
\texttt{beat()}関数は特筆に値する。これはリズミックタイミングを、プログラマーが実装しなければならない機能（Processingでの\texttt{millis()}による）から第一級ライフサイクルイベントに昇格させる。これはAPIレベルでの、音楽とリズムが付加機能ではなくコアユースケースであるという宣言である。
745
+
746
+
% ============ 11. CONCLUSION ============
747
+
748
+
\section{結論}
749
+
\label{sec:conclusion}
750
+
751
+
Processingのコア洞察——クリエイティブワーク向けのプログラミング環境は単なる言語ではなくライフサイクルを提供すべきである——はすべてのACピースの核心に存在する。\texttt{setup()}/\texttt{draw()}から\texttt{boot()}/\texttt{paint()}/\texttt{act()}/\texttt{sim()}/\texttt{leave()}への道筋はProcessingからの離脱ではなく、Processingモデルがさらに拡張されたときの能力の限界についての論証である。
752
+
753
+
Processingは\texttt{setup()} + \texttt{draw()}がアニメーションをアクセス可能にするのに十分であることを証明した。ACピースAPIは、同じ即時モードのライフサイクル駆動アプローチが——2つではなく5つの関数に分解されたとき——スケッチだけでなく\emph{練習}もサポートできることを論じている：同じピースに繰り返し戻り、洗練し、それで演奏し、時間をかけて流暢さを構築すること。
754
+
755
+
スケッチブックの比喩（書く、実行する、捨てる）と楽器の比喩（起動する、演奏する、練習する、戻る）は対立するものではない。同じ連続体上の点である。Processingはその連続体の存在を示した。ACは想像以上に遠くまで伸びていることを論じている——\texttt{setup()} + \texttt{draw()}は、その完全な形態が\texttt{boot} + \texttt{act} + \texttt{sim} + \texttt{paint} + \texttt{leave}を必要とする理念の始まりなのである。
756
+
757
+
APIとは楽器である。Processingはその核心にある。APIがプログラミング行為をどのように分解するかが、何を創造できるかを決定する。
758
+
759
+
\vspace{0.5em}
760
+
\noindent\textit{英語原版からの翻訳。原版は \url{https://papers.aesthetic.computer} を参照。}
761
+
762
+
\bibliographystyle{plainnat}
763
+
\bibliography{references}
764
+
765
+
\end{document}
+13
-11
papers/arxiv-archaeology/archaeology-cards.tex
+13
-11
papers/arxiv-archaeology/archaeology-cards.tex
···
38
38
\thispagestyle{empty}
39
39
\vspace*{\fill}
40
40
\begin{center}
41
-
\includegraphics[height=8em]{pals}\par\vspace{0.3em}
42
-
{\acbold\fontsize{20pt}{24pt}\selectfont\color{acdark} Repository Archaeology}\par
43
-
\vspace{0.3em}
44
-
{\fontsize{10pt}{12pt}\selectfont\color{acpink} Tracing the Evolution of \acrandname{} Through Its Git History}\par
45
-
\vspace{0.8em}
46
-
{\normalsize\color{cyan!70!blue}\textbf{@jeffrey}}\par
41
+
\includegraphics[height=9em]{pals}\par\vspace{0.1em}
42
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} Repository Archaeology}\par
43
+
\vspace{0.1em}
44
+
{\fontsize{9pt}{11pt}\selectfont\color{acpink} Tracing the Evolution of \acrandname{} Through Its Git History}\par
45
+
\vspace{0.4em}
46
+
{\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par
47
47
{\small\color{acgray} Aesthetic.Computer}\par
48
48
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
49
-
\vspace{0.8em}
50
-
\rule{0.6\textwidth}{1pt}\par
51
49
\vspace{0.4em}
52
-
{\small\color{acpink!40}\textit{working draft --- not for citation}}\par
53
-
\vspace{0.3em}
54
-
{\footnotesize\color{acgray} March 2026}\par
50
+
\rule{0.5\textwidth}{0.5pt}\par
51
+
\vspace{0.15em}
52
+
\colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par
53
+
\vspace{0.1em}
54
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/2113ef735}{2113ef735}}\par
55
+
\vspace{0.1em}
56
+
{\footnotesize\color{acgray}\href{https://papers.aesthetic.computer/repo-archaeology-26-arxiv-da-cards.pdf}{Dansk} · \href{https://papers.aesthetic.computer/repo-archaeology-26-arxiv-es-cards.pdf}{Español} · \href{https://papers.aesthetic.computer/repo-archaeology-26-arxiv-zh-cards.pdf}{{\accjk 中文}} · \href{https://papers.aesthetic.computer/repo-archaeology-26-arxiv-ja-cards.pdf}{{\accjk 日本語}}}\par
55
57
\end{center}
56
58
\vspace*{\fill}
57
59
+348
papers/arxiv-archaeology/archaeology-ja.tex
+348
papers/arxiv-archaeology/archaeology-ja.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
11
+
\setmainfont{Latin Modern Roman}
12
+
\setsansfont{Latin Modern Sans}
13
+
14
+
\newfontfamily\acbold{ywft-processing-bold}[
15
+
Path=../../system/public/type/webfonts/,
16
+
Extension=.ttf
17
+
]
18
+
\newfontfamily\aclight{ywft-processing-light}[
19
+
Path=../../system/public/type/webfonts/,
20
+
Extension=.ttf
21
+
]
22
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
23
+
24
+
% === CJK SUPPORT ===
25
+
\usepackage{xeCJK}
26
+
\setCJKmainfont{Droid Sans Japanese}
27
+
\setCJKsansfont{Droid Sans Japanese}
28
+
\setCJKmonofont{Droid Sans Japanese}
29
+
30
+
% === PACKAGES ===
31
+
\usepackage{xcolor}
32
+
\usepackage{titlesec}
33
+
\usepackage{enumitem}
34
+
\usepackage{booktabs}
35
+
\usepackage{tabularx}
36
+
\usepackage{multicol}
37
+
\usepackage{fancyhdr}
38
+
\usepackage{hyperref}
39
+
\usepackage{graphicx}
40
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
41
+
\usepackage{ragged2e}
42
+
\usepackage{microtype}
43
+
\usepackage{listings}
44
+
\usepackage{natbib}
45
+
\usepackage[colorspec=0.92]{draftwatermark}
46
+
47
+
% === COLORS (AC palette) ===
48
+
\definecolor{acpink}{RGB}{180,72,135}
49
+
\definecolor{acpurple}{RGB}{120,80,180}
50
+
\definecolor{acdark}{RGB}{64,56,74}
51
+
\definecolor{acgray}{RGB}{119,119,119}
52
+
\definecolor{draftcolor}{RGB}{180,72,135}
53
+
54
+
% === DRAFT WATERMARK ===
55
+
\DraftwatermarkOptions{
56
+
text=WORKING DRAFT,
57
+
fontsize=3cm,
58
+
color=draftcolor!18,
59
+
angle=45,
60
+
pos={0.5\paperwidth, 0.5\paperheight}
61
+
}
62
+
63
+
% === HYPERREF ===
64
+
\hypersetup{
65
+
colorlinks=true,
66
+
linkcolor=acpurple,
67
+
urlcolor=acpurple,
68
+
citecolor=acpurple,
69
+
pdfauthor={@jeffrey},
70
+
pdftitle={リポジトリ考古学：Git履歴を通じてAesthetic Computerの進化を追跡する},
71
+
}
72
+
73
+
% === SECTION FORMATTING ===
74
+
\titleformat{\section}
75
+
{\normalfont\bfseries\normalsize\uppercase}
76
+
{\thesection.}
77
+
{0.5em}
78
+
{}
79
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
80
+
81
+
\titleformat{\subsection}
82
+
{\normalfont\bfseries\small}
83
+
{\thesubsection}
84
+
{0.5em}
85
+
{}
86
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
87
+
88
+
% === HEADER/FOOTER ===
89
+
\pagestyle{fancy}
90
+
\fancyhf{}
91
+
\renewcommand{\headrulewidth}{0pt}
92
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{作業草稿——引用不可}}
93
+
\fancyfoot[C]{\footnotesize\thepage}
94
+
95
+
% === CUSTOM COMMANDS ===
96
+
\newcommand{\acdot}{{\color{acpink}.}}
97
+
\newcommand{\ac}{\textsc{Aesthetic.Computer}}
98
+
99
+
% === LIST SETTINGS ===
100
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
101
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
102
+
103
+
% === COLUMN SEPARATION ===
104
+
\setlength{\columnsep}{1.8em}
105
+
106
+
% === PARAGRAPH SETTINGS ===
107
+
\setlength{\parindent}{1em}
108
+
\setlength{\parskip}{0.3em}
109
+
110
+
% Hyphenation for narrow two-column layout
111
+
\tolerance=800
112
+
\emergencystretch=1em
113
+
\hyphenpenalty=50
114
+
115
+
\begin{document}
116
+
117
+
% ============ TITLE BLOCK ============
118
+
119
+
\twocolumn[{%
120
+
\begin{center}
121
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
122
+
{\acbold\fontsize{22pt}{26pt}\selectfont\color{acdark} リポジトリ考古学}\par
123
+
\vspace{0.2em}
124
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} Git履歴を通じてAesthetic Computerの進化を追跡する}\par
125
+
\vspace{0.6em}
126
+
{\normalsize @jeffrey}\par
127
+
{\small\color{acgray} Aesthetic.Computer}\par
128
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
129
+
\vspace{0.3em}
130
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
131
+
\vspace{0.6em}
132
+
\rule{\textwidth}{1.5pt}
133
+
\vspace{0.5em}
134
+
\end{center}
135
+
136
+
\begin{center}
137
+
{\small\color{acpink}\textbf{[ 作業草稿——引用不可 ]}}
138
+
\end{center}
139
+
\vspace{0.3em}
140
+
141
+
\begin{quote}
142
+
\small\noindent\textbf{概要。}
143
+
本稿では、\ac{}（AC）の技術的進化をgit履歴を通じて完全に追跡する。2021年8月にGlitch上でホストされたプロトタイプから、11,314件のコミットと337のインタラクティブピースを含む単一のモノリポジトリに至るまでの過程である。4つの連続するコードリポジトリ、2つのアカウントにまたがる50以上のGitHubリポジトリ、109\,GBのレガシーサーバーアーカイブ、そして10年間のクリエイティブソフトウェア実践にまたがるDropboxアーカイブを調査することで、一人のアーティスト-プログラマーのツール、プロトタイプ、クリエイティブな楽器がどのように統一プラットフォームへと収束したかを再構成する。調査により94の前身プロジェクト（2007--2020年）が明らかになり、これらがACの設計思想に直接影響を与えた：ソフトウェアは芸術制作の素材であり、アーティストが構築するすべてのツールはより完全な楽器に向けた一歩である。
144
+
\end{quote}
145
+
\vspace{0.5em}
146
+
}]
147
+
148
+
% ============ 1. THE FOUR REPOSITORIES ============
149
+
150
+
\section{4つのコードリポジトリ}
151
+
152
+
\ac{}は最初からモノリポジトリだったわけではない。4つの連続するGitHubリポジトリを経て進化し、それぞれが異なるアーキテクチャ段階を表している：
153
+
154
+
\begin{table}[h]
155
+
\small
156
+
\centering
157
+
\begin{tabular}{lr}
158
+
\toprule
159
+
\textbf{指標} & \textbf{値} \\
160
+
\midrule
161
+
連続リポジトリ数 & 4 \\
162
+
総コミット数（現在） & 11,314 \\
163
+
開発月数 & 38 \\
164
+
前身プロジェクト数 & 94 \\
165
+
\bottomrule
166
+
\end{tabular}
167
+
\end{table}
168
+
169
+
\subsection{system-ac（2021年8月--12月）}
170
+
171
+
\texttt{whistlegraph/system-ac} --- \emph{「ディスクをロードして実行する私の仮想コンピュータシステム。」}
172
+
173
+
最初のコミットは2021年8月10日で、即座にGlitch~\citep{glitch2017}からマージされており、ACが最初はGlitch remixプロジェクトだったことを示している。リポジトリには4ヶ月間の38件のコミットが含まれ、著者名は「@jeffrey」「Jeffrey Scudder」「whistlegraph」と変遷している——コードと並行して進行したアイデンティティの統合の痕跡である。
174
+
175
+
初期アーキテクチャは簡素だった：\texttt{boot.js}エントリポイント、\texttt{bios.js}ランタイム、そして\texttt{disk.js}、\texttt{geo.js}、\texttt{graph.js}、\texttt{pen.js}、\texttt{speaker.js}を含むモジュールライブラリ群と、正弦波・矩形波ジェネレータをサポートするサウンドシステム。比喩は最初から確立されていた：\emph{ディスク}をロードして実行するコンピュータ。
176
+
177
+
主要なマイルストーン：基本メトロノームと矩形波楽器（8月18日）、三角形ラスタライズと3D環境（10月20日）、最初のアニメーション記譜ピース（10月30日）、penのシングルトンからクラスへのリファクタリング（11月28日）——重要なAPI設計決定。開発サーバーはポート8080で自己署名SSL証明書を使用していた；初日からHTTPSが必須であり、おそらくWebRTCとオーディオAPIのためである。
178
+
179
+
\subsection{disks-ac（2021年10月--12月）}
180
+
181
+
\texttt{whistlegraph/disks-ac} --- \emph{「`whistlegraph/system'リポジトリと互換性のあるディスクのバッチ。」}
182
+
183
+
この付随リポジトリはクリエイティブコンテンツをランタイムから分離して保持していた。\texttt{package.json}は両者の結合を明らかにしている：\texttt{"system": "file:../system"}——ディスクはシステムをローカル依存として取り込んでいた。開発サーバーはポート8081で、システムポートより1つ上。
184
+
185
+
最初の12枚のディスクはACの基礎的なクリエイティブ語彙を代表していた：\texttt{prompt.js}（コマンドラインテキスト入力——システムの正面玄関）、\texttt{doodle.js}（フリードローイング）、\texttt{plot.js}（グリッドベースのピクセル描画）、\texttt{pull.js}（タッチインタラクティブシェイプ）、\texttt{stage.js}（音楽記譜）、\texttt{starfield.js}（ジェネラティブアニメーション）、\texttt{tracker.js}（スクロール可能なシーケンサー）、\texttt{whistlegraph.js}（Whistlegraph再生）、および4つのユーティリティ/テストディスク。また\texttt{old/worker-disk.js}が保持されており、Web Workerベースのディスク実行モデルが試みられた後、早期に放棄されたことを示している。
186
+
187
+
\subsection{2022.aesthetic.computer（2021年12月--2022年12月）}
188
+
189
+
\texttt{whistlegraph/2022.aesthetic.computer} --- \emph{「美的コンピューティングを行う。」}
190
+
191
+
2021年12月22日、システムとディスクのリポジトリが統合された：\emph{「以前のリポジトリからソースコードをインポート」}、続いて\emph{「重複ディスクを削除。」}これが最初のモノリポジトリとなった。キャッチフレーズは技術的記述からクリエイティブなマニフェストへと変わった。
192
+
193
+
この1年間のリポジトリは、ACが個人的な楽器からプラットフォームへと変容した過程を記録している：
194
+
195
+
\begin{itemize}
196
+
\item \textbf{2022年1月2日}：「iPadとApple Pencil用のスプレーペイントツールの開発を開始。」同日：「iOS / macOSネイティブアダプタレイヤーを追加。」
197
+
\item \textbf{1月5日}：「基本的なIPFSデモを完成」——Web3/分散ストレージの早期探索。
198
+
\item \textbf{1月7日}：「ディスクをシステムに統合」——2リポジトリアーキテクチャは2週間で摩擦点となった。
199
+
\item \textbf{1月10日}：「promptの作業を開始、キーボードを接続。」
200
+
\item \textbf{1月11日}：「マイクを接続、ビデオコードパスを開始。」
201
+
\item \textbf{2022年10月}：Hypervisor改修——ピースがページリロードなしで瞬時に切り替え可能に。
202
+
\item \textbf{10月24日}：「Meta Quest 2キーボード更新 / さらなるHID作業」——VRヘッドセットサポート。
203
+
\item \textbf{2022年11月}：VR統合：「cadwand vr hello world」、3Dブラシツール、GLTF/GLBエクスポート。
204
+
\item \textbf{2022年12月}：「Ethereumログイン/接続フローを完成。」Jamsocketバックエンドを使用したセッションサーバー。
205
+
\end{itemize}
206
+
207
+
年末までにプロジェクトのディレクトリツリーには以下が含まれていた：\texttt{system/}（Netlify）、\texttt{session-server/}（Jamsocket）、\texttt{socket-server/}、\texttt{piece-server/}、\texttt{thumbnail-server/}、\texttt{stream/}、\texttt{storage/}、\texttt{apple/}（iOS/macOSアダプタ）、\texttt{ethereum/}、および\texttt{digitpain.com/}。
208
+
209
+
\subsection{aesthetic-computer（2022年12月--現在）}
210
+
211
+
現在のリポジトリ。最初のコミット：\emph{「Initial commit。」}2番目：\emph{「以前のソースコードをすべて新しいリポジトリにコピー；TODO。」}3番目：\emph{「最初のNetlifyデプロイ。」}2022年12月23日、35分間に3件のコミット——前のリポジトリが最後のコミットを受けた同じ日にゼロから再出発した。
212
+
213
+
2026年3月時点：38ヶ月にわたる\textbf{11,314件のコミット}。
214
+
215
+
\begin{table}[h]
216
+
\small
217
+
\centering
218
+
\begin{tabular}{ll}
219
+
\toprule
220
+
\textbf{機能} & \textbf{初出} \\
221
+
\midrule
222
+
認証（Auth0） & 2023年1月5日 \\
223
+
セッションサーバー & 2023年1月21日 \\
224
+
KidLisp & 約2023年2月 \\
225
+
マルチプレイヤー & 約2023年3月 \\
226
+
Tezos/NFT $\rightarrow$ 「keep」 & 約2023年 \\
227
+
notepat & 約2023年 \\
228
+
モバイルカメラ & 2023年1月 \\
229
+
\bottomrule
230
+
\end{tabular}
231
+
\caption{現在のリポジトリにおける各機能の初出。}
232
+
\end{table}
233
+
234
+
% ============ 2. THE PREDECESSOR PROJECTS ============
235
+
236
+
\section{前身プロジェクト}
237
+
238
+
ACは無から生まれたわけではない。2つのGitHubアカウント（50以上のリポジトリを持つ\texttt{whistlegraph}と3つのリポジトリを持つ\texttt{justanothersystem}）、Dropboxアーカイブ、109\,GBのレガシーDigitalOceanクラウドホスト、および著者の履歴書を相互参照することで、2007年から2020年にわたる\textbf{94の前身プロジェクト}を特定した。
239
+
240
+
\subsection{ペイントソフトウェアの系譜}
241
+
242
+
ACの核心にあるのはペイントプログラムである。その系譜は以下の通り：
243
+
244
+
\begin{itemize}
245
+
\item \textbf{thePRBAT}（2011年）--- ポリゴン複製ビットマップ制作ツール。Flash/SWF。Ringling College学部卒業論文のツール。
246
+
\item \textbf{JeffreyPaint}（2014年）--- 「私のペイントプログラム。」JavaScript Webアプリ + Unity移植 + macOS .dmg。
247
+
\item \textbf{No Paint}（2014--2020年）--- 「画像制作の楽器。」制約条件：描くことだけ、消すことはできない。6年間で5回のイテレーション：Railsアプリ $\rightarrow$ JSアダプタ $\rightarrow$ WebGLプロトタイプ $\rightarrow$ iOS/Cordova $\rightarrow$ Vercelサイト。6つのリポジトリ。
248
+
\item \textbf{Mood Engine}（2015年）--- ネイティブCアプリケーション。「MaskwareのMOODエンジン。」
249
+
\item \textbf{Traveller}（2015年）--- Processing $\rightarrow$ 3つの独立したmacOS .appビルド。
250
+
\item \textbf{Finger Quilt}（2016年）--- Swiftで開発されたiOSアプリ。キルトとしてのペイント。
251
+
\item \textbf{Dot}（2017年）--- 「ドットグリッド描画アプリ。」ACの\texttt{plot}ディスクを直接予見。
252
+
\end{itemize}
253
+
254
+
著者はまたWebペイントツールのキュレーションディレクトリ（2017年、Glitch上の\texttt{weird-drawing-tools.glitch.me}でホスト）を維持していた——数十のペイントプログラムを記録した調査文書。このディレクトリは「メディアとしてのペイントソフトウェア」の意識的な研究を表しており、ACの設計に情報を提供した。
255
+
256
+
\subsection{パフォーマンスソフトウェアの系譜}
257
+
258
+
ACのリアルタイム、マルチプレイヤー、パフォーマンス機能は、「ラディカルデジタルペインティング」巡回講演とGoodiepal \& Palsコラボレーションのために構築されたツールに遡る：
259
+
260
+
\begin{itemize}
261
+
\item \textbf{Peter}（2017年）--- 観客が期限付きの画像をアップロードし、Julia Yergerがペインティングに使用するWebアプリ。リアルタイムの観客参加。
262
+
\item \textbf{border-notation}（2017年）--- GP\&PLS向けに開発されたボーダーアニメーション記譜プログラム。ブラウザ内の音楽記譜。
263
+
\item \textbf{pmet-subs}（2017年）--- Goodiepalパフォーマンスのリアルタイム字幕表示。
264
+
\item \textbf{Shutter Rub}（2018年）--- Fikra Design BiennalでKnoth \& Renner向けに開発されたツール。
265
+
\item \textbf{pic.jeffreyheart89.com}（2017年）--- 「デジタルペインティング配達サービス。」
266
+
\end{itemize}
267
+
268
+
\subsection{インフラストラクチャの系譜}
269
+
270
+
ACのインフラストラクチャにも前身がある：
271
+
272
+
\begin{itemize}
273
+
\item \textbf{live}（2016年）--- 「ブラウザを自動リロード。」Rubyライブリロードサーバー。ACの現在のホットリロードWebSocketシステムの後継。
274
+
\item \textbf{cfg}（2013年）--- Yale MFA時代のVimL設定ファイル。最初期の「実践としてのコンフィグ」。
275
+
\item \textbf{netlify-functions-headless-chrome}（2022年）--- Netlify上のHeadless Chromeスクリーンショット。ovenスクリーンショットサービスの直接の前身。
276
+
\item \textbf{giphy-upload-proxy}（2017年）--- サーバーサイドメディア処理の経験。
277
+
\end{itemize}
278
+
279
+
\subsection{プロジェクト横断のプログラミング言語}
280
+
281
+
前身プロジェクトは個人の実践者としては異例に広い言語範囲をカバーしている：JavaScript（主要）、Ruby（Rails時代）、Swift（iOS）、Java（Android）、C（Mood Engine）、Rust（Rect）、VimL（設定ファイル）、Processing（Traveller）、Flash/ActionScript（thePRBAT）、Lua（PICO-8）、TypeScript。ACはこの多言語の歴史をJavaScript中心のプラットフォームに統合し、KidLisp~\citep{scudder2026kidlisp}を組み込み言語としている。
282
+
283
+
% ============ 3. ARCHITECTURAL PATTERNS ============
284
+
285
+
\section{アーキテクチャパターン}
286
+
287
+
\subsection{ディスク/ピースの比喩}
288
+
289
+
\texttt{system-ac}の最初のコミットから、比喩は「bios」を通じて「system」がロードする「ディスク」だった。パーソナルコンピュータの歴史から借用されたこの比喩は4つのリポジトリすべてを貫いている。「ディスク」から「ピース」への改名は2022年中に行われ、技術用語を芸術用語に合わせた。ソフトウェアの一片（a piece of software）。音楽の一曲（a piece of music）。芸術の一作品（a piece of art）。この改名の含意は関連論文~\citep{scudder2026pieces}で探求されている。
290
+
291
+
\subsection{インターフェースとしてのプロンプト}
292
+
293
+
プロンプト——ユーザーがピース名を入力する点滅するテキストカーソル——は最初期の\texttt{disks-ac}リポジトリに\texttt{prompt.js}として登場した。後にnotepatのキーボードとACの主要ナビゲーションシステムへと発展した。プロンプトはコマンドラインではない；\emph{音楽的な}インターフェースであり、\texttt{notepat}のような単語を入力することは想起と呼び出しの行為であり、歌を見つけるためにメロディを口ずさむようなものである。
294
+
295
+
\subsection{2リポジトリからモノリポジトリへ}
296
+
297
+
システム/ディスクの分離はわずか4ヶ月で統合された。この分離は概念的区別（ランタイム対コンテンツ）を反映していたが、実際には維持不可能だった。統合はさらに2回行われた：まず\texttt{2022.aesthetic.computer}へ、次に現在のリポジトリへ。各統合はgit履歴を破棄し、クリーンな出発点を優先した——考古学的連続性よりも前進の勢いを重視する意図的な選択であり、まさにこの再構成作業を必要にした理由でもある。
298
+
299
+
% ============ 4. QUANTITATIVE SUMMARY ============
300
+
301
+
\section{定量的概要}
302
+
303
+
\begin{table}[h]
304
+
\small
305
+
\centering
306
+
\begin{tabular}{lr}
307
+
\toprule
308
+
\textbf{指標} & \textbf{数量} \\
309
+
\midrule
310
+
前身プロジェクト（2007--2020年） & 94 \\
311
+
GitHubリポジトリ（whistlegraph + JAS） & 50+ \\
312
+
現在のリポジトリの\texttt{.mjs}ピース & 337 \\
313
+
\texttt{.lisp}ピース（KidLisp） & 18 \\
314
+
ライブラリモジュール & 76 \\
315
+
Netlifyサーバーレス関数 & 83 \\
316
+
バックエンドサービス & 5 \\
317
+
レガシーアーカイブサイズ & 109\,GB \\
318
+
\bottomrule
319
+
\end{tabular}
320
+
\caption{ACエコシステムの定量的概要。}
321
+
\end{table}
322
+
323
+
% ============ 5. CONCLUSION ============
324
+
325
+
\section{結論}
326
+
327
+
\ac{}は2021年8月10日に始まったプロジェクトではない。10年間のクリエイティブソフトウェア実践の収束である——thePRBAT（2011年）からNo Paintの5回のイテレーション（2014--2020年）を経て、Goodiepal \& Pals向けに構築されたパフォーマンスツールを経て、著者が見つけられるすべてのWebペイントツールのキュレーションディレクトリを経て、Rustの矩形ゲーム、PICO-8ペイントカートリッジ、Pebbleスマートウォッチの実験を経て、デジタルツールがペインティングの次の素材的基盤であることを論じる65回以上の講演パフォーマンスを経て。
328
+
329
+
git履歴はマニフェストには見えないものを明らかにする：日々の決定の蓄積、放棄されたパス（\texttt{worker-disk.js}、2リポジトリ分離）、収束（システム + ディスク $\rightarrow$ モノリポジトリ）、そして意味を担う改名（disk $\rightarrow$ piece、notepad $\rightarrow$ notepat、NFT $\rightarrow$ keep）。すべてのコミットは@jeffreyがこれまでに描いた最も長い絵画における一筆一筆である。
330
+
331
+
\begin{quote}
332
+
\emph{「30分で作ったもの（例えばwhistlegraph！）は永遠に存在できる。」}
333
+
334
+
--- @jeffrey、パーソナルステートメント：核心的信念
335
+
\end{quote}
336
+
337
+
\vspace{0.5em}
338
+
\noindent\textbf{資料。} GitHub: \texttt{whistlegraph/system-ac}（38件のコミット）、\texttt{whistlegraph/disks-ac}（30件のコミット）、\texttt{whistlegraph/2022.aesthetic.computer}（約500件のコミット）、\texttt{whistlegraph/aesthetic-computer}（11,314件のコミット）。whistlegraphおよびjustanothersystemアカウント下の50以上の追加リポジトリ。レガシーサーバー：\texttt{bin-sc.jas.life}。Dropboxアーカイブ。履歴書およびファクトチェック報告書。
339
+
340
+
\vspace{0.5em}
341
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
342
+
343
+
% ============ REFERENCES ============
344
+
345
+
\bibliographystyle{plainnat}
346
+
\bibliography{references}
347
+
348
+
\end{document}
+168
papers/arxiv-calarts/calarts-cards.tex
+168
papers/arxiv-calarts/calarts-cards.tex
···
1
+
% !TEX program = xelatex
2
+
% Cards format — auto-generated from calarts.tex by cards-convert.mjs
3
+
\documentclass[11pt]{article}
4
+
5
+
\usepackage{fontspec}
6
+
\usepackage{unicode-math}
7
+
\setmainfont{Latin Modern Roman}
8
+
\setsansfont{Latin Modern Sans}
9
+
\setmonofont{Latin Modern Mono}[Scale=0.88]
10
+
11
+
12
+
\usepackage{graphicx}
13
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
14
+
\usepackage{booktabs}
15
+
\usepackage{tabularx}
16
+
\usepackage{ragged2e}
17
+
\usepackage{microtype}
18
+
\usepackage{natbib}
19
+
20
+
21
+
22
+
\makeatletter
23
+
\def\input@path{{../}}
24
+
\makeatother
25
+
\usepackage{ac-paper-cards}
26
+
27
+
28
+
\hypersetup{
29
+
pdftitle={CalArts, Callouts, and Papers: Art School as Operating System},
30
+
}
31
+
32
+
\renewcommand{\acpdfbase}{calarts-callouts-papers-26-arxiv}
33
+
\begin{document}
34
+
35
+
% ============================================================
36
+
% TITLE CARD
37
+
% ============================================================
38
+
\thispagestyle{empty}
39
+
\vspace*{\fill}
40
+
\begin{center}
41
+
\includegraphics[height=9em]{pals}\par\vspace{0.1em}
42
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} CalArts, Callouts, and Papers}\par
43
+
\vspace{0.1em}
44
+
{\fontsize{9pt}{11pt}\selectfont\color{acpink} Art School as Operating System}\par
45
+
\vspace{0.4em}
46
+
{\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par
47
+
{\small\color{acgray} Aesthetic.Computer}\par
48
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
49
+
\vspace{0.4em}
50
+
\rule{0.5\textwidth}{0.5pt}\par
51
+
\vspace{0.15em}
52
+
\colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par
53
+
\vspace{0.1em}
54
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/2113ef735}{2113ef735}}\par
55
+
\vspace{0.1em}
56
+
{\footnotesize\color{acgray}\href{https://papers.aesthetic.computer/calarts-callouts-papers-26-arxiv-da-cards.pdf}{Dansk} · \href{https://papers.aesthetic.computer/calarts-callouts-papers-26-arxiv-es-cards.pdf}{Español} · \href{https://papers.aesthetic.computer/calarts-callouts-papers-26-arxiv-zh-cards.pdf}{{\accjk 中文}} · \href{https://papers.aesthetic.computer/calarts-callouts-papers-26-arxiv-ja-cards.pdf}{{\accjk 日本語}}}\par
57
+
\end{center}
58
+
\vspace*{\fill}
59
+
60
+
% ============================================================
61
+
% INDEX CARD
62
+
% ============================================================
63
+
\cardindex
64
+
65
+
% ============================================================
66
+
% BODY
67
+
% ============================================================
68
+
\section{The Disney Machine}
69
+
70
+
Walt Disney founded CalArts in 1961 by merging the Chouinard Art Institute and the Los Angeles Conservatory of Music. He wanted an art school that worked like his studio: all the disciplines in one building, sharing tools and ideas. Disney died before the Valencia campus opened in 1971, but the structure he demanded---no walls between departments, shared facilities, a culture of cross-disciplinary collision---shaped everything that followed.
71
+
72
+
The founding vision was industrial. Disney needed animators who could draw, musicians who understood timing, actors who could improvise to a storyboard. The school was a talent pipeline for the studio~\citep{singerman1999art}. But something else happened. The faculty Disney's heirs hired---among them Allan Kaprow, Judy Chicago, John Baldessari, Miriam Schapiro, Nam June Paik---turned the interdisciplinary structure into a laboratory for postwar American art. The machine Disney built to produce animators became a machine that produced conceptual artists, feminist performance, video art, and eventually the generation that would define post-studio practice.
73
+
74
+
The operating system analogy is exact. An OS does not make the software; it provides the environment in which software can run. CalArts does not make the art; it provides the conditions---spatial, social, pedagogical---in which a particular kind of artist becomes possible. Change the OS and you change what can be made.
75
+
76
+
\section{Callouts}
77
+
78
+
\subsection{The crit as oral tradition}
79
+
80
+
The crit at CalArts is not a grade. It is a callout. Someone puts work on the wall and the room responds---not with rubrics or learning outcomes but with the unscripted, sometimes brutal, sometimes generous honesty of people who have been looking at art together for long enough to skip pleasantries.
81
+
82
+
\citet{elkins2001why} argues that the crit is unteachable in the same way art is unteachable: what happens in a good crit cannot be reduced to a method. It is an oral tradition. The knowledge produced in a three-hour crit exists only in the room. It cannot be written down without becoming something else---a summary, a review, a judgment. The crit is live. It is a performance of attention~\citep{hooks1994teaching}.
83
+
84
+
CalArts crits are famous for their intensity. The school's small size (roughly 1,500 students), residential campus, and interdisciplinary structure mean that a painter's crit might include a composer, an animator, a filmmaker, and a dancer. The feedback is not discipline-specific. It is \emph{perceptual}: what does this do to my body, my ear, my sense of time? The callout is not ``this is good painting.'' The callout is ``this is alive'' or ``this is dead.''
85
+
86
+
\subsection{Hallway knowledge}
87
+
88
+
Most of what CalArts teaches happens outside the classroom. The hallways of the main building---a brutalist megastructure designed by Ladd \& Kelsey---function as an informal salon. A composer walks past a sculptor's open studio and hears a sound that changes both of their work. A filmmaker screens dailies at 2 AM and a dancer wanders in and starts improvising to the footage.
89
+
90
+
This is not curriculum. It is \emph{architecture}. The building forces collision. The cafeteria (the only one) forces everyone into the same room. The hallways are wide enough to stop and talk. The studios are open. The practice rooms leak sound. The building is an instrument that plays the people inside it.
91
+
92
+
\citet{deduve1994attitude} identifies three paradigms of art education: the academy (talent-imitation), the Bauhaus (creativity-medium-invention), and the postwar art school (attitude-practice-deconstruction). CalArts invented a fourth: \emph{proximity}. Put different disciplines close enough together and they contaminate each other. The contamination is the education.
93
+
94
+
\subsection{The institutional dare}
95
+
96
+
CalArts runs on dares. Not explicit ones---no one says ``I dare you.'' But the culture is organized around a challenge structure: can you make something that holds up in a room full of people who are better than you? Can you present work that survives the callout?
97
+
98
+
This is different from the tech-school sprint review, where work is evaluated against user stories and acceptance criteria~\citep{vinsel2020innovation}. The CalArts dare has no criteria. There is no rubric. The question is not ``does this meet the brief?'' The question is ``does this need to exist?'' The dare is existential, not functional.
99
+
100
+
The dare also operates between departments. A music student who makes a piece with video is daring the film students to pay attention. A dancer who codes an interactive installation is daring the art students to take technology seriously. The dare is the mechanism of cross-disciplinary contamination. It says: your discipline is not sufficient. Come play in mine.
101
+
102
+
\section{Why Papers}
103
+
104
+
\subsection{The paper as callout}
105
+
106
+
This paper series---twenty papers written in three weeks---is itself a callout. It says: an artist-programmer can write theory. Not ``theory-lite,'' not ``artist statements with citations,'' but real papers with real arguments and real bibliographies that engage with real scholarship.
107
+
108
+
The art world does not expect this. Artists are expected to make work and let critics write about it. The division of labor is clear: artists produce, critics explain, historians contextualize. When an artist writes theory, the institutional response is suspicion. Is it real scholarship? Is it vanity publishing? Is it art?
109
+
110
+
The answer is: it does not matter. The paper is a callout. It forces the ideas to stand in the open, exposed to criticism, in a format that the academy recognizes and the art world does not control. \citet{fraser2005critique} noted that institutional critique became an institution. These papers attempt something different: not critique of the institution but \emph{use} of the institution's own format---the academic paper---as artistic material.
111
+
112
+
\subsection{The paper as instrument}
113
+
114
+
A paper is a technology. It has a format (sections, citations, abstract, bibliography), a distribution system (journals, preprints, repositories), and a social protocol (peer review, citation, response). Like any technology, it can be played.
115
+
116
+
\ac{} treats the piece as the fundamental unit of creative cognition~\citep{scudder2026pieces}. A piece is a single file that exports lifecycle functions: \texttt{boot}, \texttt{paint}, \texttt{act}, \texttt{sim}. A paper has the same structure: it boots (abstract), paints (argument), acts (engages with prior work), and simulates (proposes consequences). The paper is a piece written in \LaTeX{} instead of JavaScript.
117
+
118
+
This is not metaphor. The papers are built with the same infrastructure as the software: a CLI (\texttt{papers/cli.mjs}), incremental builds, multi-language deployment, automated publishing. The paper \emph{is} software. The argument \emph{is} the program.
119
+
120
+
\subsection{The PSYCHO designation}
121
+
122
+
This paper is marked PSYCHO. Not ``Working Draft,'' not ``Preprint,'' not ``Under Review.'' PSYCHO.
123
+
124
+
The designation is a callout to the paper format itself. Academic papers pretend to be neutral---objective reports of findings, written in passive voice, stripped of personality. The PSYCHO label refuses this pretense. It says: this paper has a voice, it has an agenda, it has a temperature. It is not neutral. It is not trying to be.
125
+
126
+
The word ``psycho'' comes from the Greek \textit{psykhe}---soul, mind, breath. A PSYCHO paper is a paper with a soul. It breathes. It has opinions that are not hedged with ``further research is needed.'' It makes claims and dares you to disagree.
127
+
128
+
\section{CalArts and Aesthetic Computer}
129
+
130
+
\subsection{The OS inheritance}
131
+
132
+
The author attended CalArts (MFA Art, 2012). The experience is the substrate on which \ac{} is built. Not the techniques---CalArts does not teach programming---but the \emph{assumptions}: that disciplines should contaminate each other, that the medium is not the point, that the dare is more important than the deliverable, that art is a way of being in the world rather than a product to be shipped.
133
+
134
+
\ac{} inherits CalArts's operating system. The piece model---one file, immediate-mode graphics, lifecycle functions---is the digital equivalent of the open studio: anyone can see what you are making, anyone can fork it, anyone can call it out. The social network is organized around \emph{paths} (memorizable URLs) rather than feeds, the same way CalArts is organized around hallways rather than algorithms.
135
+
136
+
\np{}.com is the clearest CalArts inheritance. It is an instrument that anyone can play, that does not require training, that rewards exploration over expertise. The hallway encounter---stumbling onto someone else's work and being changed by it---is the design pattern. You type a URL. You land on a piece. You play it. You move on. No feed. No algorithm. No metrics. Just proximity.
137
+
138
+
\subsection{The crit goes online}
139
+
140
+
Publishing these papers is a crit. The room is the internet. The callout is public. The work is exposed---not to a room of fifteen people who know you but to anyone with a browser and an opinion.
141
+
142
+
This is terrifying in the same way a CalArts crit is terrifying: you cannot control the response. The work either holds or it does not. The dare is the same dare: does this need to exist?
143
+
144
+
\section{Against Neutrality}
145
+
146
+
The academic paper pretends to be a window---transparent, letting you see the research behind it. But every window is also a frame. The paper format frames what can be said: passive voice, hedged claims, deference to prior work, the fiction of objectivity~\citep{freire1970pedagogy}.
147
+
148
+
CalArts teaches the opposite. Stand behind your work. Say what you mean. If you cannot defend it in the room, it is not ready. The callout is a technology of accountability: it forces you to own your claims in front of people who will push back.
149
+
150
+
These papers are written in that spirit. They have a voice. They make claims. They cite scholarship not to hide behind it but to argue with it, to build on it, to dare it to respond. The PSYCHO designation is a flag: this paper is not pretending to be neutral. It has a position. It has a temperature. It is standing in the room, waiting for the callout.
151
+
152
+
\citet{spivak2012aesthetic} argues that aesthetic education trains the imagination for ethical solidarity. CalArts does this---not through curriculum but through proximity, through the dare, through the crit that forces you to see your work through someone else's eyes. These papers attempt the same thing in a different medium: to train the reader's imagination for a different kind of creative computing, one built on instruments rather than feeds, on pieces rather than products, on callouts rather than engagement metrics.
153
+
154
+
\section{Conclusion}
155
+
156
+
CalArts is an operating system. Its kernel is proximity. Its shell is the crit. Its process model is the dare. \ac{} runs on the same OS, ported from the physical campus to the browser to bare metal~\citep{scudder2026ac, scudder2026os}.
157
+
158
+
The callout is the mechanism. The paper is the format. The PSYCHO designation is the temperature. Together they say: art can write theory, theory can be art, and neither needs permission from the institutions that claim to own them.
159
+
160
+
These papers are hallway knowledge, finally written down---knowing that the writing changes them, knowing that the crit never ends, knowing that the dare is the point.
161
+
162
+
\vspace{0.5em}
163
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
164
+
165
+
\bibliographystyle{plainnat}
166
+
\bibliography{references}
167
+
168
+
\end{document}
+205
papers/arxiv-calarts/calarts-ja.tex
+205
papers/arxiv-calarts/calarts-ja.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
5
+
\usepackage{fontspec}
6
+
\usepackage{unicode-math}
7
+
\usepackage{xeCJK}
8
+
\setCJKmainfont{Droid Sans Japanese}
9
+
\setmainfont{Latin Modern Roman}
10
+
\setsansfont{Latin Modern Sans}
11
+
\newfontfamily\acbold{ywft-processing-bold}[Path=../../system/public/type/webfonts/,Extension=.ttf]
12
+
\newfontfamily\aclight{ywft-processing-light}[Path=../../system/public/type/webfonts/,Extension=.ttf]
13
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
14
+
15
+
\usepackage{xcolor}
16
+
\usepackage{titlesec}
17
+
\usepackage{enumitem}
18
+
\usepackage{booktabs}
19
+
\usepackage{tabularx}
20
+
\usepackage{fancyhdr}
21
+
\usepackage{hyperref}
22
+
\usepackage{graphicx}
23
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
24
+
\usepackage{ragged2e}
25
+
\usepackage{microtype}
26
+
\usepackage{natbib}
27
+
28
+
% === PSYCHO watermark ===
29
+
\usepackage{eso-pic}
30
+
\usepackage{tikz}
31
+
\AddToShipoutPictureBG{%
32
+
\begin{tikzpicture}[remember picture, overlay]
33
+
% --- Pals logo: large, top-left, rotated, semi-opaque ---
34
+
\node[opacity=0.06, anchor=north west, rotate=-15]
35
+
at ([xshift=-1.2cm, yshift=1.2cm]current page.north west)
36
+
{\includegraphics[width=10cm]{pals}};
37
+
% --- "PSYCHO" text in Processing Light font ---
38
+
\node[opacity=0.12, rotate=45, anchor=center]
39
+
at (current page.center)
40
+
{{\aclight\fontsize{2.5cm}{3cm}\selectfont\color{acpink} PSYCHO}};
41
+
\end{tikzpicture}%
42
+
}
43
+
44
+
\definecolor{acpink}{RGB}{180,72,135}
45
+
\definecolor{acpurple}{RGB}{120,80,180}
46
+
\definecolor{acdark}{RGB}{64,56,74}
47
+
\definecolor{acgray}{RGB}{119,119,119}
48
+
49
+
\hypersetup{colorlinks=true,linkcolor=acpurple,urlcolor=acpurple,citecolor=acpurple,
50
+
pdftitle={CalArts、コールアウトと論文：オペレーティングシステムとしての芸術大学}}
51
+
52
+
\titleformat{\section}{\normalfont\bfseries\normalsize\uppercase}{\thesection.}{0.5em}{}
53
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
54
+
\titleformat{\subsection}{\normalfont\bfseries\small}{\thesubsection}{0.5em}{}
55
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
56
+
57
+
\pagestyle{fancy}\fancyhf{}
58
+
\renewcommand{\headrulewidth}{0pt}
59
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{PSYCHO論文 --- 引用不可}}
60
+
\fancyfoot[C]{\footnotesize\thepage}
61
+
62
+
\newcommand{\ac}{\textsc{Aesthetic Computer}}
63
+
\newcommand{\np}{\textsc{notepat}}
64
+
65
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
66
+
\setlength{\columnsep}{1.8em}
67
+
\setlength{\parindent}{1em}
68
+
\setlength{\parskip}{0.3em}
69
+
70
+
\tolerance=800
71
+
\emergencystretch=1em
72
+
\hyphenpenalty=50
73
+
74
+
\begin{document}
75
+
76
+
\twocolumn[{%
77
+
\begin{center}
78
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
79
+
{\acbold\fontsize{22pt}{26pt}\selectfont\color{acdark} CalArts、コールアウトと論文}\par
80
+
\vspace{0.2em}
81
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} オペレーティングシステムとしての芸術大学}\par
82
+
\vspace{0.6em}
83
+
{\normalsize @jeffrey}\par
84
+
{\small\color{acgray} Aesthetic.Computer}\par
85
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
86
+
\vspace{0.3em}
87
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
88
+
\vspace{0.6em}
89
+
\rule{\textwidth}{1.5pt}
90
+
\vspace{0.5em}
91
+
\end{center}
92
+
93
+
\begin{center}
94
+
{\small\color{acpink}\textbf{[ PSYCHO論文 --- 引用不可 ]}}
95
+
\end{center}
96
+
\vspace{0.3em}
97
+
98
+
\begin{quote}
99
+
\small\noindent\textbf{概要。}
100
+
CalArts（カリフォルニア芸術大学）は1961年にWalt Disneyによって設立された総合的な芸術大学である——アニメーション、音楽、演劇、ダンス、映画、美術が同じ屋根の下で、学問分野の壁なく互いに交わる場所。本稿では、CalArtsがクリエイティブ生産の\emph{オペレーティングシステム}として機能していると論じる：芸術とは何か、芸術をどう教えるか、アーティストはどうあるべきかについての基本的な前提のセット。学校独特の「コールアウト」文化——批評、廊下での会話、制度的挑戦——を考察し、この口承的伝統がいかに文字にできない知識を生み出しているかを探る。次に論文そのものに目を向ける：なぜこの一連の学術論文が存在するのか、アーティスト兼プログラマーが理論を書くことの意味は何か、そして論文の形式自体がコールアウト——アイデアを公の場に露呈させる公開の挑戦——ではないのか。CalArtsは著者に応答できる作品を作ることを教えた。これらの論文は、それらの作品がアートワールドの予期しない方法で応答しているのである。
101
+
\end{quote}
102
+
\vspace{0.5em}
103
+
}]
104
+
105
+
\section{ディズニーマシン}
106
+
107
+
Walt Disneyは1961年にChouinard Art InstituteとLos Angeles Conservatory of Musicを統合してCalArtsを創設した。彼が望んだのは、自分のスタジオのように機能する芸術大学だった：すべての分野が一つの建物に集まり、ツールとアイデアを共有する。Disneyは1971年にValenciaキャンパスが開設される前に亡くなったが、彼が要求した構造——部門間の壁がないこと、共有施設、学際的衝突の文化——がその後のすべてを形作った。
108
+
109
+
創設のビジョンは産業的だった。Disneyには描けるアニメーター、リズムを理解する音楽家、ストーリーボードに向かって即興できる俳優が必要だった。この学校はスタジオへの人材供給パイプラインだった~\citep{singerman1999art}。しかし別のことが起こった。Disneyの後継者が雇った教員——Allan Kaprow、Judy Chicago、John Baldessari、Miriam Schapiro、Nam June Paikを含む——が、学際的構造を戦後アメリカ美術の実験室に変えた。Disneyがアニメーター育成のために建てた機械は、コンセプチュアルアーティスト、フェミニストパフォーマンス、ビデオアートを生産する機械となり、最終的にはポストスタジオ実践を定義する世代を輩出した。
110
+
111
+
オペレーティングシステムの比喩は正確である。オペレーティングシステムはソフトウェアを作らない；ソフトウェアが動く環境を提供する。CalArtsは芸術を作らない；ある特定のタイプのアーティストを可能にする条件——空間的、社会的、教育的な——を提供する。オペレーティングシステムを変えれば、創造できるものが変わる。
112
+
113
+
\section{コールアウト}
114
+
115
+
\subsection{口承的伝統としての批評}
116
+
117
+
CalArtsの批評は採点ではない。それはコールアウトである。誰かが作品を壁に掛け、部屋が応答する——評価基準や学習成果ではなく、長い間一緒に芸術を見てきたからこそ社交辞令を飛ばせる人々による、リハーサルのない、時に残酷で時に寛大な正直さをもって。
118
+
119
+
\citet{elkins2001why}は、芸術が教えられないのと同様に批評も教えられないと論じる：良い批評で起こることはメソッドに還元できない。それは口承的伝統である。3時間の批評で生成される知識はその部屋にしか存在しない。書き留めると別のものに変わる——要約、評価、判断に。批評はライブである。それは注意のパフォーマンスである~\citep{hooks1994teaching}。
120
+
121
+
CalArtsの批評はその強度で知られている。小規模な学校（約1,500人）、寮制キャンパス、学際的構造は、画家の批評に作曲家、アニメーター、映画人、ダンサーが含まれうることを意味する。フィードバックは学科特有ではない。それは\emph{知覚的}である：これは私の身体に、耳に、時間感覚に何をしたか？コールアウトは「これは良い絵だ」ではない。コールアウトは「これは生きている」または「これは死んでいる」である。
122
+
123
+
\subsection{廊下の知識}
124
+
125
+
CalArtsが教えることの大部分は教室の外で起こる。本館の廊下——Ladd \& Kelseyによるブルータリスト建築の巨大構造体——が非公式のサロンとして機能する。作曲家が彫刻家の開いたスタジオの前を通り過ぎ、二人の作品を変える音を聞く。映画人が午前2時にその日の素材を上映し、ダンサーが入ってきて映像に合わせて即興を始める。
126
+
127
+
これはカリキュラムではない。これは\emph{建築}である。建築が衝突を強制する。食堂（唯一の）がすべての人を同じ部屋に押し込む。廊下は立ち止まって話せるほど広い。スタジオは開放されている。練習室から音が漏れる。建築はその中にいる人々を演奏する楽器である。
128
+
129
+
\citet{deduve1994attitude}は芸術教育の3つのパラダイムを識別した：アカデミー（才能-模倣）、バウハウス（創造性-メディウム-発明）、戦後芸術学校（態度-実践-脱構築）。CalArtsは第4のパラダイムを発明した：\emph{近接性}。異なる分野を十分に近くに置けば、互いに汚染し合う。汚染が教育である。
130
+
131
+
\subsection{制度的挑戦}
132
+
133
+
CalArtsは挑戦によって動く。明示的な挑戦ではない——誰も「挑戦する」とは言わない。しかし文化は挑戦構造の周りに組織されている：自分より優れた人々で満ちた部屋で持ちこたえるものを作れるか？コールアウトに耐える作品を見せられるか？
134
+
135
+
これは技術学校のスプリントレビューとは異なり、そこでは作品がユーザーストーリーと受入基準に対して評価される~\citep{vinsel2020innovation}。CalArtsの挑戦には基準がない。ルーブリックがない。問題は「これはブリーフを満たしているか？」ではない。問題は「これは存在する必要があるか？」挑戦は存在論的であり、機能的ではない。
136
+
137
+
挑戦は部門間でも機能する。ビデオ付きの作品を作る音楽学生は映画学生に注目させる挑戦をしている。インタラクティブインスタレーションをコーディングするダンサーは美術学生にテクノロジーを真剣に受け止めさせる挑戦をしている。挑戦は学際的汚染のメカニズムである。それは言う：あなたの分野だけでは足りない。私の領域で遊ぼう。
138
+
139
+
\section{なぜ論文を書くのか}
140
+
141
+
\subsection{コールアウトとしての論文}
142
+
143
+
この論文シリーズ——3週間で書かれた20本の論文——それ自体がコールアウトである。それはこう言っている：アーティスト兼プログラマーは理論を書ける。「理論ライト」ではなく、「引用付きアーティストステートメント」でもなく、真の論点と真の参考文献を持ち、真の学術研究と対話する真の論文。
144
+
145
+
アートワールドはこれを予期していなかった。アーティストは作品を制作し、批評家に書かせることが期待されている。分業は明確だ：アーティストが生産し、批評家が解釈し、歴史家がコンテキスト化する。アーティストが理論を書くと、制度的反応は懐疑である。これは本当の学術研究か？虚栄出版か？芸術か？
146
+
147
+
答えは：それは問題ではない。論文はコールアウトである。それはアイデアを公の場に立たせ、批評にさらし、学術界が認め、アートワールドがコントロールできないフォーマットで。\citet{fraser2005critique}は制度批評自体が制度になったと指摘した。これらの論文は異なることを試みる：制度への批評ではなく、制度自身のフォーマット——学術論文——を芸術の素材として\emph{使用する}こと。
148
+
149
+
\subsection{楽器としての論文}
150
+
151
+
論文はテクノロジーである。フォーマット（セクション、引用、要約、参考文献）、配信システム（ジャーナル、プレプリント、データベース）、社会的プロトコル（査読、引用、応答）がある。あらゆるテクノロジーと同様に、演奏可能である。
152
+
153
+
\ac{}はピースをクリエイティブ認知の基本単位と見なしている~\citep{scudder2026pieces}。ピースはライフサイクル関数をエクスポートする単一ファイル：\texttt{boot}、\texttt{paint}、\texttt{act}、\texttt{sim}。論文も同じ構造を持つ：起動（要約）、描画（論証）、行動（先行研究との対話）、シミュレーション（帰結の提示）。論文はJavaScriptではなく\LaTeX{}で書かれたピースである。
154
+
155
+
これは比喩ではない。論文はソフトウェアと同じインフラストラクチャで構築されている：CLI（\texttt{papers/cli.mjs}）、インクリメンタルビルド、多言語デプロイメント、自動化された公開。論文\emph{は}ソフトウェアである。論証\emph{は}プログラムである。
156
+
157
+
\subsection{PSYCHOマーク}
158
+
159
+
この論文はPSYCHOと表示されている。「ワーキングドラフト」でも「プレプリント」でも「査読中」でもない。PSYCHO。
160
+
161
+
このマークは論文フォーマット自体へのコールアウトである。学術論文は中立性を装う——受動態で書かれ、個性が剥ぎ取られた客観的な研究報告。PSYCHOラベルはこの偽装を拒否する。それはこう言う：この論文には声がある、アジェンダがある、温度がある。中立ではない。中立であろうともしない。
162
+
163
+
「psycho」という語はギリシャ語の\textit{psykhe}——魂、精神、息——に由来する。PSYCHO論文は魂を持つ論文である。呼吸している。「さらなる研究が必要」でヘッジされない見解を持っている。主張を行い、あなたに異議を唱える。
164
+
165
+
\section{CalArtsとAesthetic Computer}
166
+
167
+
\subsection{オペレーティングシステムの継承}
168
+
169
+
著者はCalArtsに通った（MFA Art、2012年）。その経験は\ac{}が構築された基盤である。技術ではない——CalArtsはプログラミングを教えない——\emph{前提}である：分野は互いを汚染すべきであること、メディウムは要点ではないこと、挑戦は成果物より重要であること、芸術は出荷される製品ではなく世界における在り方であること。
170
+
171
+
\ac{}はCalArtsのオペレーティングシステムを継承している。ピースモデル——1ファイル、即時モードグラフィックス、ライフサイクル関数——はオープンスタジオのデジタル等価物である：誰もがあなたの制作を見られ、誰もがフォークでき、誰もが問いを投げかけられる。ソーシャルネットワークはアルゴリズムではなく\emph{パス}（記憶可能なURL）の周りに組織されており、CalArtsがアルゴリズムではなく廊下の周りに組織されているのと同じである。
172
+
173
+
\np{}.comが最も明白なCalArtsの継承である。誰でも演奏できる楽器であり、トレーニング不要で、専門技能よりも探索を報いる。廊下での偶然の出会い——他人の作品を偶然見つけて、それによって変わること——がデザインパターンである。URLを入力する。ピースに着地する。演奏する。先へ進む。フィードなし。アルゴリズムなし。メトリクスなし。ただ近接性。
174
+
175
+
\subsection{批評がオンラインに}
176
+
177
+
これらの論文を公開することは批評である。部屋はインターネット。コールアウトは公開。作品はさらされている——あなたを知る15人の部屋に対してではなく、ブラウザと意見を持つすべての人に対して。
178
+
179
+
CalArtsの批評が恐ろしいように、これも恐ろしい：応答をコントロールできない。作品は持ちこたえるか、持ちこたえないか。挑戦は変わらない：これは存在する必要があるか？
180
+
181
+
\section{中立性に反対する}
182
+
183
+
学術論文は窓を装う——透明で、その背後にある研究を見通せる。しかしすべての窓はフレームでもある。論文のフォーマットが何を言えるかをフレームする：受動態、ヘッジされた主張、先行研究への敬意、客観性のフィクション~\citep{freire1970pedagogy}。
184
+
185
+
CalArtsが教えたのはその逆である。自分の作品の後ろに立て。言いたいことを言え。部屋で弁護できないなら、まだ準備ができていない。コールアウトは説明責任のテクノロジーである：反論する人々の前で自分の主張に責任を持つことを強制する。
186
+
187
+
これらの論文はまさにその精神で書かれている。声がある。主張がある。学術研究を引用するのは、その背後に隠れるためではなく、それと議論し、その上に構築し、応答を挑むためである。PSYCHOマークは旗である：この論文は中立を装わない。立場がある。温度がある。部屋に立ち、コールアウトを待っている。
188
+
189
+
\citet{spivak2012aesthetic}は美的教育が想像力を倫理的連帯のために訓練すると論じた。CalArtsはそれを実現した——カリキュラムによってではなく、近接性によって、挑戦によって、他者の目を通して自分の作品を見ることを強制する批評によって。これらの論文は異なるメディウムで同じことを試みている：読者の想像力を訓練し、異なるクリエイティブコンピューティングを構想させる——フィードではなく楽器の上に、プロダクトではなくピースの上に、エンゲージメントメトリクスではなくコールアウトの上に構築されたもの。
190
+
191
+
\section{結論}
192
+
193
+
CalArtsはオペレーティングシステムである。そのカーネルは近接性。シェルは批評。プロセスモデルは挑戦。\ac{}は同じオペレーティングシステム上で動いており、物理的なキャンパスからブラウザへ、さらにベアメタルへと移植されている~\citep{scudder2026ac, scudder2026os}。
194
+
195
+
コールアウトがメカニズム。論文がフォーマット。PSYCHOマークが温度。これらが共に言う：芸術は理論を書ける、理論は芸術たりうる、そのどちらも、自らの所有を主張する制度の許可を必要としない。
196
+
197
+
これらの論文は、ついに書き留められた廊下の知識である——書くことがそれを変えることを知りながら、批評が決して終わらないことを知りながら、挑戦こそが要点であることを知りながら。
198
+
199
+
\vspace{0.5em}
200
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
201
+
202
+
\bibliographystyle{plainnat}
203
+
\bibliography{references}
204
+
205
+
\end{document}
+16
-14
papers/arxiv-complex/complex-cards.tex
+16
-14
papers/arxiv-complex/complex-cards.tex
···
38
38
\thispagestyle{empty}
39
39
\vspace*{\fill}
40
40
\begin{center}
41
-
\includegraphics[height=8em]{pals}\par\vspace{0.3em}
42
-
{\acbold\fontsize{20pt}{24pt}\selectfont\color{acdark} Sucking on the Complex}\par
43
-
\vspace{0.3em}
44
-
{\fontsize{10pt}{12pt}\selectfont\color{acpink} Platform Hegemony, Critique-as-Content, and the Need for Anti-Environments}\par
45
-
\vspace{0.8em}
46
-
{\normalsize\color{cyan!70!blue}\textbf{@jeffrey}}\par
41
+
\includegraphics[height=9em]{pals}\par\vspace{0.1em}
42
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} Sucking on the Complex}\par
43
+
\vspace{0.1em}
44
+
{\fontsize{9pt}{11pt}\selectfont\color{acpink} Platform Hegemony, Critique-as-Content, and the Need for Anti-Environments}\par
45
+
\vspace{0.4em}
46
+
{\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par
47
47
{\small\color{acgray} Aesthetic.Computer}\par
48
48
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
49
-
\vspace{0.8em}
50
-
\rule{0.6\textwidth}{1pt}\par
51
49
\vspace{0.4em}
52
-
{\small\color{acpink!40}\textit{working draft --- not for citation}}\par
53
-
\vspace{0.3em}
54
-
{\footnotesize\color{acgray} March 2026}\par
50
+
\rule{0.5\textwidth}{0.5pt}\par
51
+
\vspace{0.15em}
52
+
\colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par
53
+
\vspace{0.1em}
54
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/2113ef735}{2113ef735}}\par
55
+
\vspace{0.1em}
56
+
{\footnotesize\color{acgray}\href{https://papers.aesthetic.computer/sucking-on-the-complex-26-arxiv-da-cards.pdf}{Dansk} · \href{https://papers.aesthetic.computer/sucking-on-the-complex-26-arxiv-es-cards.pdf}{Español} · \href{https://papers.aesthetic.computer/sucking-on-the-complex-26-arxiv-zh-cards.pdf}{{\accjk 中文}} · \href{https://papers.aesthetic.computer/sucking-on-the-complex-26-arxiv-ja-cards.pdf}{{\accjk 日本語}}}\par
55
57
\end{center}
56
58
\vspace*{\fill}
57
59
···
119
121
120
122
\subsection{Masking the face}
121
123
122
-
\citet{blas2014informatic} developed the ``Facial Weaponization Suite'' (2011--2014): collective masks generated from biometric data that defeat facial recognition. The work has been shown at the ICA London and presented at Tate Modern. It is a powerful metaphor for collective opacity, for the right to not be seen.
124
+
\citet{blas2014informatic} developed the ``Facial Weaponization Suite'' (2011--2014): collective masks generated from biometric data that defeat facial recognition. The work has been shown at the Whitechapel Gallery and presented at Tate Modern. It is a powerful metaphor for collective opacity, for the right to not be seen.
123
125
124
126
But the mask is an art object in a vitrine. It is not a tool you can wear. It was designed for the gallery wall, not for the street. The gesture toward resistance is contained by the institution that houses it.
125
127
···
133
135
134
136
This pipeline degrades both ends. It makes the feed feel like art---``I saw Paglen's new work on my Instagram''---and it makes the institution feel like a feed---booth after booth of content at Art Basel, photographed and posted before the paint dries. \citet{fraser2005critique} identified this loop in institutional critique three decades ago; platform hegemony is the same structural problem with surveillance capitalism layered on top.
135
137
136
-
\citet{ulman2014excellences} scripted a five-month Instagram performance in 2014, manipulating the platform's logic of aspiration and self-display. The work was acquired by the Tate. It is instructive: Ulman's piece succeeded precisely because it was indistinguishable from content. The platform did not know it was being used as material. The behavioral data it generated was identical to that of genuine lifestyle posts. The algorithm does not distinguish critique from endorsement. Paglen's photograph of an NSA facility gets more likes than a landscape painting. Both generate engagement. Both feed the machine.
138
+
\citet{ulman2014excellences} scripted a five-month Instagram performance in 2014, manipulating the platform's logic of aspiration and self-display. The work was exhibited at Tate Modern in 2016. It is instructive: Ulman's piece succeeded precisely because it was indistinguishable from content. The platform did not know it was being used as material. The behavioral data it generated was identical to that of genuine lifestyle posts. The algorithm does not distinguish critique from endorsement. Paglen's photograph of an NSA facility gets more likes than a landscape painting. Both generate engagement. Both feed the machine.
137
139
138
140
\section{The Structural Trap}
139
141
···
191
193
192
194
\subsection{Aesthetic Computer}
193
195
194
-
\ac{} builds its own runtime, its own social network, its own instrument (\np{}.com), its own operating system~\citep{scudder2026ac, scudder2026notepat, scudder2026os}. It is not critique-as-art but infrastructure-as-art. The behaviors are new: memorizable paths instead of feeds, pieces instead of posts, instruments you play instead of profiles you curate. The platform \emph{is} the work. The Whistlegraph project~\citep{scudder2026whistlegraph}, which reached approximately 2.6 million TikTok followers, demonstrated that viral culture could be built on a foundation of drawing and singing rather than algorithmic optimization. The contradiction is real: the anti-environment achieved its largest audience \emph{through} the complex. When TikTok removed the account, the 2.6 million followers vanished overnight---but the underlying creative practice of drawing and singing survived, because it had never been dependent on the platform's infrastructure. The audience was lost. The practice was not.
196
+
\ac{} builds its own runtime, its own social network, its own instrument (\np{}.com), its own operating system~\citep{scudder2026ac, scudder2026notepat, scudder2026os}. It is not critique-as-art but infrastructure-as-art. The behaviors are new: memorizable paths instead of feeds, pieces instead of posts, instruments you play instead of profiles you curate. The platform \emph{is} the work. The Whistlegraph project~\citep{scudder2026whistlegraph}, which reached approximately 2.7 million TikTok followers, demonstrated that viral culture could be built on a foundation of drawing and singing rather than algorithmic optimization. The contradiction is real: the anti-environment achieved its largest audience \emph{through} the complex. When the trio went on hiatus in late 2023, the TikTok account and its 2.7 million followers remained---but the underlying creative practice of drawing and singing continued independently, because it had never been dependent on the platform's infrastructure. The audience is rented. The practice is owned.
195
197
196
198
\subsection{Indigenous and decolonial computing}
197
199
+237
papers/arxiv-complex/complex-ja.tex
+237
papers/arxiv-complex/complex-ja.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
5
+
\usepackage{fontspec}
6
+
\usepackage{unicode-math}
7
+
\usepackage{xeCJK}
8
+
\setCJKmainfont{Droid Sans Japanese}
9
+
\setmainfont{Latin Modern Roman}
10
+
\setsansfont{Latin Modern Sans}
11
+
\newfontfamily\acbold{ywft-processing-bold}[Path=../../system/public/type/webfonts/,Extension=.ttf]
12
+
\newfontfamily\aclight{ywft-processing-light}[Path=../../system/public/type/webfonts/,Extension=.ttf]
13
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
14
+
15
+
\usepackage{xcolor}
16
+
\usepackage{titlesec}
17
+
\usepackage{enumitem}
18
+
\usepackage{booktabs}
19
+
\usepackage{tabularx}
20
+
\usepackage{fancyhdr}
21
+
\usepackage{hyperref}
22
+
\usepackage{graphicx}
23
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
24
+
\usepackage{ragged2e}
25
+
\usepackage{natbib}
26
+
\usepackage[colorspec=0.92]{draftwatermark}
27
+
28
+
\definecolor{acpink}{RGB}{180,72,135}
29
+
\definecolor{acpurple}{RGB}{120,80,180}
30
+
\definecolor{acdark}{RGB}{64,56,74}
31
+
\definecolor{acgray}{RGB}{119,119,119}
32
+
\definecolor{draftcolor}{RGB}{180,72,135}
33
+
34
+
\DraftwatermarkOptions{text=WORKING DRAFT,fontsize=3cm,color=draftcolor!18,angle=45}
35
+
36
+
\hypersetup{colorlinks=true,linkcolor=acpurple,urlcolor=acpurple,citecolor=acpurple,
37
+
pdftitle={Sucking on the Complex：プラットフォーム覇権、批評としてのコンテンツ、反環境の必要性}}
38
+
39
+
\titleformat{\section}{\normalfont\bfseries\normalsize\uppercase}{\thesection.}{0.5em}{}
40
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
41
+
\titleformat{\subsection}{\normalfont\bfseries\small}{\thesubsection}{0.5em}{}
42
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
43
+
44
+
\pagestyle{fancy}\fancyhf{}
45
+
\renewcommand{\headrulewidth}{0pt}
46
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{作業草稿 --- 引用不可}}
47
+
\fancyfoot[C]{\footnotesize\thepage}
48
+
49
+
\newcommand{\ac}{\textsc{Aesthetic.Computer}}
50
+
\newcommand{\np}{\textsc{notepat}}
51
+
52
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
53
+
\setlength{\columnsep}{1.8em}
54
+
\setlength{\parindent}{1em}
55
+
\setlength{\parskip}{0.3em}
56
+
57
+
\begin{document}
58
+
59
+
\twocolumn[{%
60
+
\begin{center}
61
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
62
+
{\acbold\fontsize{22pt}{26pt}\selectfont\color{acdark} Sucking on the Complex}\par
63
+
\vspace{0.2em}
64
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} プラットフォーム覇権、批評としてのコンテンツ、反環境の必要性}\par
65
+
\vspace{0.6em}
66
+
{\normalsize @jeffrey}\par
67
+
{\small\color{acgray} Aesthetic.Computer}\par
68
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
69
+
\vspace{0.3em}
70
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
71
+
\vspace{0.6em}
72
+
\rule{\textwidth}{1.5pt}
73
+
\vspace{0.5em}
74
+
\end{center}
75
+
76
+
\begin{center}
77
+
{\small\color{acpink}\textbf{[ 作業草稿 --- 引用不可 ]}}
78
+
\end{center}
79
+
\vspace{0.3em}
80
+
81
+
\begin{quote}
82
+
\small\noindent\textbf{概要。}
83
+
現代アートワールドのメディアインフラストラクチャは2つの企業によって支配されている：MetaとByteDance。今日、InstagramやTikTokにデータを供給することなくアーティストのキャリアを維持することは不可能であり、これらのプラットフォームはすべてのクリエイティブ分野を「コンテンツ」に平坦化し、エンゲージメント指標で文化をランク付けし、行動誘導によってアーティストを自由意志のないアルゴリズムの泡の中へと押し込む。本稿ではこの全体化する環境に対する2つの応答を区別する。\emph{芸術としての批評}——ギャラリーや機関における支配的モード——はプラットフォーム複合体の権力を指し示すが、その支配への認識を強化するだけである；批評自体がマシンを養うコンテンツとなる。\emph{反環境}——マーシャル・マクルーハンから借用した用語——はメディアの周りに代替インフラストラクチャを構築し、新たな行動と過程をもたらし、芸術がアルゴリズムの指示なく成長できる自由な遊びの空間を創出する。プラットフォーム批判作品が主要な機関で展示された著名なアーティストを検討し、プラットフォームに対する制度的批評がなぜ構造的に自己挫折するものであるかを分析し、複合体から逃れる唯一の道はその外側に構築することであると論じる。
84
+
\end{quote}
85
+
\vspace{0.5em}
86
+
}]
87
+
88
+
\section{全体化する環境}
89
+
90
+
Instagramはギャラリーである。TikTokは流通チャネルである。MetaとByteDanceは共に現代美術の全体化するメディア環境を構成している。外部は存在しない。
91
+
92
+
新興および中堅キャリアのアーティストにとって、プラットフォーム上の存在はスタジオ訪問、アートフェアの招待、コレクターの注目を得るための前提条件となりつつある。プラットフォーム指標——フォロワー数、エンゲージメント率、投稿頻度——は文化的関連性の代理指標となっている。可視性の代価はデータである：すべてのインタラクションがプラットフォームに資金を提供する広告マシンにフィードされる~\citep{zuboff2019surveillance}。
93
+
94
+
これは選択ではない。インフラストラクチャである。1960年代のアーティストがギャラリーなしには見てもらえなかったように、2026年のアーティストはInstagramアカウントを必要とする。違いは、ギャラリーが販売から手数料を取っていたのに対し、プラットフォームはすべてのスワイプ、一時停止、いいね、シェアから行動データを抽出するということだ——アーティストからだけでなく、作品に触れるすべての人から~\citep{srnicek2017platform}。
95
+
96
+
マーシャル・マクルーハンは、環境の内部からは環境を知覚できないと論じた。環境はその住人にとって不可視であるが、まさにそれが全体的だからである。環境を可視にする唯一の方法は\emph{反環境}を構築することである——支配的環境との差異が環境の形状を顕わにする反構造~\citep{mcluhan1969playboy}。ここから導かれる帰結：プラットフォーム複合体を内部から批評することはできない。指し示すことしかできない。それを本当に見るためには、何か別のものを構築しなければならない。
97
+
98
+
本稿は、プラットフォーム上の文化生産が、歴史的に芸術を生み出してきた条件とは根本的に異なる条件下で行われていることを観察する。アルゴリズムは不可視の共同制作者であり、何が見られ、報われ、したがって何が創られるかを形作る。芸術は歴史的に自由な遊びの空間を必要としてきた~\citep{winnicott1971playing, huizinga1938homo}：中断されず、管理されない空間、物事がそれ自身の条件で成長し、メディアの周りに新しい行動と新しい過程が生まれる場所。プラットフォームにはそのような空間がない。唯一の出口は反環境を構築することである。
99
+
100
+
\section{複合体}
101
+
102
+
\subsection{覇権}
103
+
104
+
Meta（Facebook、Instagram、Threads、WhatsApp）とByteDance（TikTok、抖音）は共に、地球上のほぼすべての現役アーティストの文化的可視性を媒介している。Instagramだけで月間アクティブユーザーが30億人を超え、ギャラリー、キュレーター、コレクター、機関の主要な発見プラットフォームとなっている。TikTokの短編動画フォーマットはパフォーマンス、スタジオプロセス、美術教育のデフォルト配信メカニズムとなった。これらが共に\citet{nieborg2018platformization}が「文化生産のプラットフォーム化」と呼ぶものを構成する：芸術的意図ではなくプラットフォームの分類ロジックによって形作られる偶発的な文化商品。
105
+
106
+
\subsection{行動誘導}
107
+
108
+
アルゴリズムは受動的に芸術を表示しているのではない。どのような芸術が創られるかを能動的に形作っている。アーティストが絵画を投稿し高いエンゲージメントを得ると、アルゴリズムはそれをより多くの人に見せる。アーティストはその反応を見て、より類似した絵画を制作する。アルゴリズムが狭め、アーティストが狭める。これは検閲ではない——行動誘導であり、\citet{zuboff2019surveillance}が監視資本主義の中核メカニズムとして識別したものと同一である：利益のために人間の行動を大規模に予測し修正すること。
109
+
110
+
結果は文化的バブルである。抽象画を制作するアーティストは抽象画を見る。コンセプチュアルビデオを制作するアーティストはコンセプチュアルビデオを見る。アルゴリズムはエンゲージメントのために最適化し、歴史的に対話の中に存在していた分野を分離する：絵画と彫刻とパフォーマンスと批評と理論が、同じ雑誌、同じギャラリー、同じ学校にあったのに。プラットフォームにはそのような空間がない。すべてがフィードである。
111
+
112
+
\subsection{平坦化}
113
+
114
+
Instagramでは、ゲルハルト・リヒターの絵画と誰かの昼食の写真が同じ1080$\times$1080ピクセルの正方形を占める。マリーナ・アブラモヴィッチのパフォーマンスの動画がダンスのトレンドと料理チュートリアルの間に並ぶ。プラットフォームは芸術とエンターテインメントを区別せず、数十年の制作と数秒の制作を区別しない。これはキュレーションの失敗ではない；プラットフォームの設計である~\citep{chun2016updating}。エンゲージメントが唯一の指標。エンゲージメントを生まない芸術は存在しない。
115
+
116
+
分野固有の空間を維持していた歴史的インフラストラクチャ——ジャーナル、カタログ、専門批評、学部固有の資金——は単一のフィードに置き換えられた。\citet{lovink2011networks}はこれを「原因なきネットワーク」と呼んだ：すべてを接続するが何にもコンテキストを提供しない構造。
117
+
118
+
\section{芸術としての批評：権力を指し示す}
119
+
120
+
プラットフォーム覇権に対する主流の芸術的応答は、それ\emph{について}の作品を制作することである。これらの作品は世界で最も名声あるもの文化機関で展示されている。称賛され、収集され、論じられる。記述されている構造的条件は変わらないままである。
121
+
122
+
\subsection{権力の撮影}
123
+
124
+
Paglenは数マイル離れた場所から機密軍事施設を撮影し、監視の物理的インフラストラクチャ（海底ケーブル、衛星地上局）を記録し、顔認識AIの訓練画像を暴露するデータセットを集めた。彼の作品はホイットニー美術館、MoMA、スミソニアン、ペースギャラリー、ヴェネチア・ビエンナーレで展示された。厳密で、よく調査され、視覚的に説得力がある。
125
+
126
+
しかしそれは権力を指し示すだけである。ギャラリーの観客は監視マシンの巨大さについてより詳しくなって退場する——それが問題なのである。この作品は複合体の触手を宣伝する。対抗インフラストラクチャを構築せず、代替システムを創出せず、脱出経路を提供しない。観客が感じるのは「ここに抵抗のツールがある」ではなく「抵抗はおそらく無駄だ、これがどれほど巨大か見よ」である。
127
+
128
+
\subsection{流通の分析}
129
+
130
+
\citet{steyerl2017duty}は「免税芸術」の世界を描写した——グローバル資本のフリートレードゾーンで生産され、摩擦なく流通し、免税で根無し草の芸術。彼女のサーペンタインギャラリー、ヴェネチア・ビエンナーレ、パークアベニューアーモリーでのビデオインスタレーションは、デジタル流通、プラットフォーム労働、スクリーン政治の見事な分析である。
131
+
132
+
しかし彼女の分析はInstagramに投稿され、TikTokで共有され、彼女が批評しているプラットフォーム上で議論される。批評がマシンを養う。\citet{steyerl2009poor}はかつて「低品質の画像」がその低解像度の流通を通じて政治的力を獲得すると論じたが、Instagram上ではすべての画像——低品質であれ美麗であれ——がMetaの広告エンジンに同じ行動データを生成する。
133
+
134
+
\subsection{顔の隠蔽}
135
+
136
+
\citet{blas2014informatic}は「顔武装化スイート」（2011--2014年）を開発した：生体認証データから生成され、顔認識を打ち破る集団的マスク。作品はICA Londonで展示され、Tate Modernでプレゼンテーションされた。集団的不透明性の強力な比喩であり、見られない権利である。
137
+
138
+
しかしマスクはショーケースの中の芸術品である。着用可能なツールではない。ギャラリーの壁のために設計されており、街頭のためではない。抵抗のジェスチャーは、それを収容する機関によって制限される。
139
+
140
+
\subsection{パイプライン}
141
+
142
+
構造的問題はこれらのアーティストが不誠実であることではない。プラットフォームから機関へのパイプライン自体が複合体の稼働なのである。その順序：フィードのためにコンテンツを制作する $\rightarrow$ キュレーターに発見される（彼らはInstagramであなたを見つけた）$\rightarrow$ 文明の最も精緻な器物を収集することを目的とした文化機関で同じコンテンツまたは批評を展示する。
143
+
144
+
パイプラインは両端の品位を下げる。フィードを芸術のように感じさせ——「Paglenの新作をInstagramで見た」——機関をフィードのように感じさせる——Art Baselでブース次々のコンテンツが、絵の具が乾く前に撮影されアップされる。\citet{fraser2005critique}は30年前に制度批評の中にこのサイクルを識別していた；プラットフォーム覇権は同じ構造的問題に監視資本主義が重なったものである。
145
+
146
+
\citet{ulman2014excellences}は2014年に5ヶ月にわたるInstagramパフォーマンスを演出し、プラットフォームの野心と自己提示のロジックを操作した。作品はテート美術館に収蔵された。これは示唆的である：Ulmanの作品が成功したのはまさにコンテンツと区別がつかなかったからである。プラットフォームは自分が創造の素材として使われていることを知らなかった。生成された行動データは本物のライフスタイル投稿とまったく同じだった。アルゴリズムは批評と承認を区別しない。PaglenがNSA施設を撮影した写真は風景画よりも多くのいいねを獲得する。両者ともエンゲージメントを生む。両者ともマシンを養う。
147
+
148
+
\section{構造的罠}
149
+
150
+
アーティストは自由にプラットフォームを選んでいるのではない。プラットフォーム\emph{が}インフラストラクチャなのである。Instagramなしにはギャラリーアクセスも、スタジオ訪問も、コレクターの注目もない。TikTokなしには若いアーティストのオーディエンス開発も、制度的関心に転化するバイラルの瞬間もない。
151
+
152
+
プラットフォーム指標——フォロワー数、エンゲージメント率、ストリーの閲覧数——は文化的価値の代理指標となっている。同等の質の2人のアーティストから選ぶギャラリーは、より多くのフォロワーを持つ方を選ぶ。フォロワーはオープニングナイトの出席率に転化し、メディア報道に、売上に転化するからだ。これはシニシズムではない；プラットフォーム指標を文化的関連性の主要な可読性基準にしたシステムにおける合理的行動である。
153
+
154
+
帰結は学科の崩壊である。絵画、彫刻、パフォーマンス、映像、インスタレーション、サウンド、執筆、批評——すべてがInstagram上で「ビジュアルコンテンツ」に、TikTok上で「短編動画」になる。何世紀にもわたって育まれてきた学科間の歴史的区別が、注意のために最適化された単一のフォーマットの中で溶解する~\citep{chun2016updating}。Instagramには\textit{Artforum}や\textit{October}の対応物がない——ある分野の歴史、理論、自己認識がアルゴリズムの干渉なしに発展できる空間がない。\citet{noble2018algorithms}は、検索でさえ——見る行為でさえ——既存の階層を複製する不透明なランキングシステムに形作られていることを証明した；同じ構造的ロジックが芸術のフィードを支配する。
155
+
156
+
\citet{terranova2000free}は25年前にこれを「無料労働」として識別した：プラットフォームに価値を創出する文化生産における無報酬の労働。アーティストは注意経済における最も投資された無料労働者である。彼らは高品質で情動的共鳴を持つコンテンツ——アルゴリズムがユーザーをスクロールさせ続けるために必要なもの——を生産し、その見返りに可視性の幻想を得る。しかしプラットフォームはアルゴリズムを変更することでいつでもその可視性を取り消せる。
157
+
158
+
\section{自由な遊びの空間}
159
+
160
+
芸術はフィードの中では育たない。自由な空間の中で育つ。
161
+
162
+
\citet{winnicott1971playing}はこれを「潜在的空間」と呼んだ——内的現実と外的現実の間の移行的体験の領域であり、挑戦もされず譲歩もされない。遊びが起こる空間、象徴が形成される空間、創造的体験が可能になる空間。潜在的空間は脆い。安全性、連続性、侵入からの自由を必要とする。
163
+
164
+
\citet{huizinga1938homo}は遊びの「魔法円」を描写した：独自のルールを持ち、日常生活から分離された境界のある空間。魔法円の内部では外の世界のルールが一時停止する。チェス盤は魔法円である。リハーサル室は魔法円である。スタジオは、うまく機能しているとき、魔法円である。
165
+
166
+
プラットフォームには魔法円がない。Instagram上のすべての創造的行為は即座に測定され、分類され、ランク付けされ、エンゲージメントデータとしてフィードバックされる。中断されない空間がない。アルゴリズムは常に監視し、常に採点し、常に誘導している。作品が投稿された瞬間に「潜在的空間」は指標へと崩壊する。
167
+
168
+
芸術は誘導\emph{されない}空間で育つ。スタジオ。レジデンシー。リハーサル室。スケッチブック。実用目的のない深夜の会話。これらの空間にはアルゴリズムがない。エンゲージメント指標がない。行動誘導がない。プラットフォームはこれらを排除した——物理的に破壊することによってではなく、可視性を投稿に依存させることによって。投稿しなければ存在しない。投稿すればアルゴリズムが次に何を作るかを指示する。\citet{benjamin2019race}はこれを「新しいジムコード」と呼んだ：中立に見えるが既存の権力構造をエンコードし増幅する技術。芸術生産のアルゴリズム誘導はそのようなエンコードの一つである——システムがすでに読み取れるものを報い、読み取れないものを罰する。
169
+
170
+
\section{2つの教育学}
171
+
172
+
プラットフォーム危機は教育の危機でもある。学生が教えられること——精神的に、志的に、骨の髄まで——が、彼らが何の文化を構築するかを決定する。
173
+
174
+
\subsection{芸術学校}
175
+
176
+
\citet{elkins2001why}は芸術は教えられないと論じた——教えようがないからではなく、良い芸術学校で起こることはカリキュラムに還元できないから。批評、スタジオ訪問、何年にもわたる失敗作の制作：これらが独自の芸術的知識が形成される条件である。\citet{singerman1999art}はアメリカの大学がいかに芸術がどうありうるかを形作ったかを追跡した。\citet{deduve1994attitude}は3つのパラダイムを識別した：アカデミー（才能-模倣）、バウハウス（創造性-メディウム-発明）、戦後芸術学校（態度-実践-脱構築）。それぞれが異なるタイプのアーティストを創出した。なぜならそれぞれが異なる形成の空間を創出したからである。
177
+
178
+
芸術学校はその最良の状態で魔法円である~\citep{huizinga1938homo}。学生は指標なしに制作する。批評は持続的注意の儀式である——時に残酷、時に沈黙、常に緩慢——人々の集団が一つのものを1時間見つめ、それが何であるかを言おうとする。アルゴリズムなし。エンゲージメントスコアなし。志はスケールではなく深化。\citet{hooks1994teaching}はこれを「関与的教育学」と呼んだ：自由の実践としての教育であり、教師と学生の福利がコンテンツと同等に重要である~\citep{freire1970pedagogy}。
179
+
180
+
\citet{spivak2012aesthetic}は、美的教育——想像力の厳格な訓練——は倫理的連帯のために、民主主義の中核にある二重拘束を理解する能力のために必要であると論じた。芸術学校はこれを教える。Instagramは教えない。
181
+
182
+
ベルナール・スティグレールの\emph{自己テクスト}概念——技術的な義肢を通じて編まれた固有の記憶——はまさに良い芸術教育が生み出すものを描写している~\citep{staunaes2021stiegler, stiegler1998technics}。何年もの工房での実践を通じて、学生は知識のスパイラルを構築する：各作品が前の作品を吸収し変容させ、第三次保持——外化された記憶——を創出する。それは還元不可能に個人的である。批評、スタジオ、スケッチブック、失敗した作品：これらが自己テクストの形成を支える義肢である。プラットフォームはこのスパイラルを短絡させる。何年もの緩慢な蓄積を即時のフィードバックに、自己テクストの深さをフィードの広がりに置き換える。
183
+
184
+
\subsection{テクノロジー学校}
185
+
186
+
\citet{turner2006counterculture}は、1960年代カウンターカルチャーの反官僚主義的理想がStewart Brand、Whole Earth Catalog、スタンフォードを経てシリコンバレーのデジタルユートピア主義に再利用された過程を追跡した。d.schoolの5段階デザイン思考プロセス——共感、定義、構想、プロトタイプ、テスト——はバウハウスの創造性-メディウム-発明パラダイムから批判性を剥ぎ取り、スプリントスピードに加速したものである。\citet{vinsel2020innovation}はこれを「イノベーション話法」と呼んだ：新奇に目を向けさせ維持を無視させる知的・道徳的嘘。
187
+
188
+
テクノロジー学校はまったく異なる精神的志向を教える。志はスケール。指標は成長。メディウムはピッチデッキ。Metaは2014年に公式に「Move fast and break things」を廃止したが、その神学は生き続けている：破壊はそれ自体で善であり、新しいことはそれ自体で良く、測定できないものは存在しない。芸術学校は曖昧さと何年も共存することを教える。テクノロジー学校は1スプリントで曖昧さを消去することを教える。
189
+
190
+
危険はテクノロジー教育学が存在することではない——エンジニアはものを作る必要がある——それが芸術教育学を植民地化したことにある。「クリエイティブコーディング」プログラムが実際にはスタートアップインキュベーターである。MFAプログラムがピッチデッキのようなアーティストステートメントを要求する。スタジオ訪問がプロダクトレビューのように感じられる。デザイン思考の方法論が芸術学校に持ち込まれ、緩慢で定量化不能な批評を、高速で指標ベースのスプリントレビューに置き換える。芸術学校がエンゲージメントの最適化を教えるとき、複合体を吸わせているのである。
191
+
192
+
\section{反環境}
193
+
194
+
複合体の内部から批評することはできない。何か別のものを構築しなければならない。
195
+
196
+
マクルーハンの反環境は抗議ではない。構造である。支配的環境を可視化する——記述によってではなく、異なることによって。魚は陸の上で水を見る~\citep{mcluhan1964understanding}。\citet{lanier2018ten}は業界内部から同様の結論に達した：ソーシャルメディアの行動修正は意味のある創造的エージェンシーを不可能にし、唯一の合理的応答は離脱であると論じた。歴史的先例は存在する：コミュニティラジオ、メールアートネットワーク、ジン文化、Fluxus配信ネットワークはすべて、その時代の放送メディアの反環境として機能した。一部は生き残り、多くは吸収された。
197
+
198
+
\subsection{ラディカルな配信}
199
+
200
+
Goodiepal（G{\ae}oudjiansen）はデンマーク・フェロー諸島の作曲家でありラディカルな教育者であり、プラットフォームロジックを完全に拒否している~\citep{scudder2026goodiepal}。彼は巡回講演（しばしば人力車で）、手持ちメディア、対面伝達を通じて作品を配信する。彼のEl Camino del Hardcoreはラディカルコンピューティングの労働条件を記録している。作品\emph{が}インフラストラクチャである：芸術とそれを運ぶシステムの間に分離はない。彼はMetaを批評しない。そもそも必要としたことがない。
201
+
202
+
\subsection{Aesthetic Computer}
203
+
204
+
\ac{}は独自のランタイム、独自のソーシャルネットワーク、独自の楽器（\np{}.com）、独自のオペレーティングシステムを構築している~\citep{scudder2026ac, scudder2026notepat, scudder2026os}。芸術としての批評ではなく、芸術としてのインフラストラクチャである。行動は新しい：フィードではなく記憶可能なパス、投稿ではなくピース、キュレーションされたプロフィールではなく演奏される楽器。プラットフォーム\emph{が}作品である。Whistlegraphプロジェクト~\citep{scudder2026whistlegraph}は約260万のTikTokフォロワーを獲得し、バイラル文化はアルゴリズム最適化ではなく描画と歌唱の上に構築できることを証明した。矛盾は真実である：反環境は複合体\emph{を通じて}最大のオーディエンスを獲得した。TikTokがアカウントを削除したとき260万のフォロワーが一夜にして消えた——しかし描画と歌唱の根底にあるクリエイティブな実践は生き残った。それはプラットフォームのインフラストラクチャに依存したことがなかったからである。オーディエンスは失われた。実践は失われなかった。
205
+
206
+
\subsection{先住民と脱植民地化コンピューティング}
207
+
208
+
\citet{lewis2018making}は「マシンとの親族関係」を提唱する——取引的ではなく関係的なインタラクション、搾取ではなくケア、消費ではなく親族関係を中心とする先住民コンピューティングのフレームワーク。\citet{escobar2018designs}は「多元宇宙のためのデザイン」を描写する：ラディカルな相互依存に根ざし、プラットフォームロジックの単一文化を拒否するデザイン実践。\citet{costanzachock2020design}はデザイン正義をコミュニティ主導の実践として明確化した。これらはMetaへの批評ではない。Metaを必要としない世界の設計図である。
209
+
210
+
\subsection{核心的区別}
211
+
212
+
PaglenはNSAをフェンスの外から撮影する。\ac{}は別の庭にフェンスを建てる——Metaにデータを供給する必要のない、新しい楽器、新しいプロセス、新しい創造の方法を持って。民歌はプラットフォームなしでも存続し、直接的な人間の行為を通じて~\citep{scudder2026ac}。ピースはベアメタル上で動く、ブラウザなし、インターネット接続なし。反環境は複合体に反対するものではない。ただ別の場所にある。
213
+
214
+
\section{アートフェアのパラドックス}
215
+
216
+
Art Basel、Frieze、ヴェネチア・ビエンナーレはすべてマーケティング、オーディエンス開発、コレクターへのアウトリーチにInstagramに依存している。これらのフェアで展示するアーティストは「発見」されるためにプラットフォーム上のプレゼンスを持たなければならない。フェア自体がコンテンツとなる：ブース写真、VIPプレビュー投稿、コレクターストーリー、アーティストスタジオ訪問——すべてが投稿され、すべてが測定され、すべてが同じ行動エンジンに供給される。
217
+
218
+
「反プラットフォーム」の作品でさえ、撮影されアップロードされた瞬間にプラットフォーム化される。Goodiepalの講義がInstagramストーリーになる。\ac{}のピースがTikTokデモになる。\citet{haacke1971shapolsky}は1971年に美術館理事の背後にある不動産利益を暴露した；今日、その暴露はInstagramカルーセルになるだろう。構造的批評は同じである——しかし今は監視資本主義が重なり、機関自体がアーティストと同じくプラットフォームを必要としている。
219
+
220
+
\citet{illich1973tools}はこう書いた：「私が'convivialité'（共生的活力）という言葉を選んだのは、産業的生産性の対立物を指すためである。」芸術の反環境はconvivialである：人間のスケールで建てられ、手作りされ、消費ではなく使用のために作られ、エンゲージメントと搾取のロジックの外にある。
221
+
222
+
\section{結論}
223
+
224
+
複合体は現実である。内部から批評できる——その批評は測定され、分類され、ランク付けされ、マネタイズされるだろう。あるいは反環境を構築できる：新しい空間、新しい行動、メディアの周りの新しいプロセス。理想的には両方。しかし批評だけでは——複合体に依存してオーディエンスを得る機関の中で展示される批評だけでは——複合体の全体性を証明するだけである。
225
+
226
+
反環境は芸術としての批評よりも構築が難しく、維持が難しく、資金を得るのが難しい。それが要点である。簡単であればプラットフォームはとうに吸収していた。難しさ自体が、何か本物が試みられていることのシグナルである：アルゴリズムの干渉のない自由な遊びの空間——芸術が——コンテンツではなく——育つことができる場所。
227
+
228
+
\vspace{0.5em}
229
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
230
+
231
+
\vspace{0.5em}
232
+
\noindent\textit{英語原版からの翻訳。原版は \url{https://papers.aesthetic.computer} を参照。}
233
+
234
+
\bibliographystyle{plainnat}
235
+
\bibliography{references}
236
+
237
+
\end{document}
+13
-11
papers/arxiv-dead-ends/dead-ends-cards.tex
+13
-11
papers/arxiv-dead-ends/dead-ends-cards.tex
···
40
40
\thispagestyle{empty}
41
41
\vspace*{\fill}
42
42
\begin{center}
43
-
\includegraphics[height=8em]{pals}\par\vspace{0.3em}
44
-
{\acbold\fontsize{20pt}{24pt}\selectfont\color{acdark} Vestigial Features}\par
45
-
\vspace{0.3em}
46
-
{\fontsize{10pt}{12pt}\selectfont\color{acpink} Dormant Paths, Evolutionary Branches, and Abandoned Approaches}\par
47
-
\vspace{0.8em}
48
-
{\normalsize\color{cyan!70!blue}\textbf{@jeffrey}}\par
43
+
\includegraphics[height=9em]{pals}\par\vspace{0.1em}
44
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} Vestigial Features}\par
45
+
\vspace{0.1em}
46
+
{\fontsize{9pt}{11pt}\selectfont\color{acpink} Dormant Paths, Evolutionary Branches, and Abandoned Approaches}\par
47
+
\vspace{0.4em}
48
+
{\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par
49
49
{\small\color{acgray} Aesthetic.Computer}\par
50
50
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
51
-
\vspace{0.8em}
52
-
\rule{0.6\textwidth}{1pt}\par
53
51
\vspace{0.4em}
54
-
{\small\color{acpink!40}\textit{working draft --- not for citation}}\par
55
-
\vspace{0.3em}
56
-
{\footnotesize\color{acgray} March 2026}\par
52
+
\rule{0.5\textwidth}{0.5pt}\par
53
+
\vspace{0.15em}
54
+
\colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par
55
+
\vspace{0.1em}
56
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/2113ef735}{2113ef735}}\par
57
+
\vspace{0.1em}
58
+
{\footnotesize\color{acgray}\href{https://papers.aesthetic.computer/dead-ends-26-arxiv-da-cards.pdf}{Dansk} · \href{https://papers.aesthetic.computer/dead-ends-26-arxiv-es-cards.pdf}{Español} · \href{https://papers.aesthetic.computer/dead-ends-26-arxiv-zh-cards.pdf}{{\accjk 中文}} · \href{https://papers.aesthetic.computer/dead-ends-26-arxiv-ja-cards.pdf}{{\accjk 日本語}}}\par
57
59
\end{center}
58
60
\vspace*{\fill}
59
61
+276
papers/arxiv-dead-ends/dead-ends-ja.tex
+276
papers/arxiv-dead-ends/dead-ends-ja.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
5
+
\usepackage{fontspec}
6
+
\usepackage{unicode-math}
7
+
\usepackage{xeCJK}
8
+
\setCJKmainfont{Droid Sans Japanese}
9
+
\setmainfont{Latin Modern Roman}
10
+
\setsansfont{Latin Modern Sans}
11
+
\newfontfamily\acbold{ywft-processing-bold}[Path=../../system/public/type/webfonts/,Extension=.ttf]
12
+
\newfontfamily\aclight{ywft-processing-light}[Path=../../system/public/type/webfonts/,Extension=.ttf]
13
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
14
+
15
+
\usepackage{xcolor}
16
+
\usepackage{titlesec}
17
+
\usepackage{enumitem}
18
+
\usepackage{booktabs}
19
+
\usepackage{tabularx}
20
+
\usepackage{fancyhdr}
21
+
\usepackage{hyperref}
22
+
\usepackage{graphicx}
23
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
24
+
\usepackage{ragged2e}
25
+
\usepackage{natbib}
26
+
\usepackage[colorspec=0.92]{draftwatermark}
27
+
28
+
\definecolor{acpink}{RGB}{180,72,135}
29
+
\definecolor{acpurple}{RGB}{120,80,180}
30
+
\definecolor{acdark}{RGB}{64,56,74}
31
+
\definecolor{acgray}{RGB}{119,119,119}
32
+
\definecolor{draftcolor}{RGB}{180,72,135}
33
+
34
+
\DraftwatermarkOptions{text=WORKING DRAFT,fontsize=3cm,color=draftcolor!18,angle=45}
35
+
36
+
\hypersetup{colorlinks=true,linkcolor=acpurple,urlcolor=acpurple,citecolor=acpurple,
37
+
pdftitle={痕跡的機能：Aesthetic Computerにおける休眠パス、進化的分岐、廃止メソッド}}
38
+
39
+
\titleformat{\section}{\normalfont\bfseries\normalsize\uppercase}{\thesection.}{0.5em}{}
40
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
41
+
\titleformat{\subsection}{\normalfont\bfseries\small}{\thesubsection}{0.5em}{}
42
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
43
+
44
+
\pagestyle{fancy}\fancyhf{}
45
+
\renewcommand{\headrulewidth}{0pt}
46
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{作業草稿 --- 引用不可}}
47
+
\fancyfoot[C]{\footnotesize\thepage}
48
+
49
+
\newcommand{\ac}{\textsc{Aesthetic.Computer}}
50
+
\newcommand{\acos}{\textsc{AC Native OS}}
51
+
52
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
53
+
\setlength{\columnsep}{1.8em}
54
+
\setlength{\parindent}{1em}
55
+
\setlength{\parskip}{0.3em}
56
+
57
+
% Hyphenation for narrow two-column layout
58
+
\tolerance=800
59
+
\emergencystretch=1em
60
+
\hyphenpenalty=50
61
+
62
+
\begin{document}
63
+
64
+
\twocolumn[{%
65
+
\begin{center}
66
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
67
+
{\acbold\fontsize{24pt}{28pt}\selectfont\color{acdark} 痕跡的機能}\par
68
+
\vspace{0.2em}
69
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} 休眠パス、進化的分岐、廃止メソッド}\par
70
+
\vspace{0.3em}
71
+
{\aclight\fontsize{9pt}{11pt}\selectfont\color{acgray} Aesthetic Computerの進化形態学（2021--2026年）}\par
72
+
\vspace{0.6em}
73
+
{\normalsize @jeffrey}\par
74
+
{\small\color{acgray} Aesthetic.Computer}\par
75
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
76
+
\vspace{0.3em}
77
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
78
+
\vspace{0.6em}
79
+
\rule{\textwidth}{1.5pt}
80
+
\vspace{0.5em}
81
+
\end{center}
82
+
83
+
\begin{center}
84
+
{\small\color{acpink}\textbf{[ 作業草稿 --- 引用不可 ]}}
85
+
\end{center}
86
+
\vspace{0.3em}
87
+
88
+
\begin{quote}
89
+
\small\noindent\textbf{概要。}
90
+
ソフトウェアシステムに関する学術論文は、ほぼ例外なく成功した部分のみを記述する。本稿では休眠した部分を記述する。5年間の開発を通じて、\ac{}は16の痕跡的機能を蓄積した——積極的に開発され、一定期間機能し、その後沈黙に至ったコードパスである。生物学における退化器官と同様に、これらの機能は死んだ組織ではない：条件が変化すれば再活性化しうるもの、存続した機能に遺伝物質を提供したもの、有機体がそれを超えて進化したために萎縮したものがある。これらの機能を5つのカテゴリに分類する：\emph{プラットフォーム分岐}（7つのプラットフォームで同時に開発し、5つが休眠）、\emph{インフラストラクチャ実験}（分散アーキテクチャがより単純な形態に統合）、\emph{マネタイゼーション試行}（技術的に完成しているが市場条件を待つシステム）、\emph{単一ユーザーツール}（開発目的に役立った後に放棄された機能）、\emph{過早な抽象化}（特定の解決策に取って代わられた汎用的アプローチ）。それぞれについて、休眠の理由、開発分岐の日付、分岐時のユーザーアクティビティ、再活性化の可能性を記録する。プロジェクトの痕跡的機能——その失敗ではなく——が進化の軌道を明らかにし、休眠は死ではないことを論じる。
91
+
\end{quote}
92
+
\vspace{0.5em}
93
+
}]
94
+
95
+
\section{はじめに}
96
+
97
+
\ac{}のgit履歴には、4つのコードリポジトリにまたがる11,000件以上のコミットが含まれている~\citep{scudder2026archaeology}。公開された論文はどこかに至ったコミットを記述している：ランタイム、KidLispインタプリタ、ピースシステム、ベアメタルオペレーティングシステム~\citep{scudder2026ac, scudder2026os}。本稿では沈黙に至ったコミットを記述する。
98
+
99
+
ソフトウェアの進化は、生物の進化と同様に、分岐によって進行する。ほとんどの分岐は幹にならない。しかし木の枯れ枝とは異なり、ソフトウェアプロジェクトにおける休眠コードパスは再活性化できる：Androidアプリは明日にもストアに出すことができ、Electronアプリはユースケースを見つけるかもしれず、NFTインフラストラクチャはすでに当初のマネタイゼーション目的を超えてpiece-codeアドレッシングシステムとなっている。\ac{}の特異な点は、\texttt{GRAVEYARD.txt}ファイルを維持して廃止された機能を明示的にカタログ化していることである——しかし「墓地」は誤った比喩である。より適切な比喩は虫垂である：元の機能が変化し、縮小した形で存在し、異なる条件下でなお有用かもしれない構造。
100
+
101
+
このリストは5つのカテゴリに分けられ、それぞれが異なる\emph{タイプ}の休眠を表す。カテゴリは相互排他的ではない；一部の機能は複数のカテゴリに属する。
102
+
103
+
\section{プラットフォーム断片化}
104
+
\label{sec:fragmentation}
105
+
106
+
\ac{}の歴史で最もコストのかかった行き止まりのカテゴリは、すべてのプラットフォームに同時にネイティブアプリを構築しようとした試みである。2023年から2025年の間に、以下のプラットフォームで動作するプロトタイプが構築された：
107
+
108
+
\begin{itemize}
109
+
\item \textbf{Web}（主要プラットフォーム、常にアクティブ）
110
+
\item \textbf{Electronデスクトップアプリ}（macOS、Windows、Linux）
111
+
\item \textbf{Androidアプリ}（Kotlin + WebView、2つのビルドバリアント）
112
+
\item \textbf{Apple TVアプリ}（計画のみ、未着手）
113
+
\item \textbf{Feral File FF1ハードウェア}（FFOS統合）
114
+
\item \textbf{FedACキオスク}（Fedora + Electronキオスクモード）
115
+
\item \textbf{AC Native OS}（ベアメタルLinux）
116
+
\end{itemize}
117
+
118
+
7つのターゲットのうち、現在アクティブなのは2つだけ：Webプラットフォームとベアメタルオペレーティングシステム。残りの5つは多大なエンジニアリング投資を表しているが、出荷された製品はゼロである。
119
+
120
+
\subsection{Electronアプリ}
121
+
122
+
完全なElectronアプリが構築された。macOSとWindowsのコード署名証明書、カスタムターミナル統合、ピースとデバッグコンソールを切り替える「フリップビュー」、3つのOS用のビルドインフラストラクチャを含む。開発チーム以外のユーザーには一切配布されなかった。総投資——署名証明書、ビルドスクリプト、CIパイプライン、カスタムJSブリッジ——の成果は開発者のマシンでのみローカルに動作するアプリだった。
123
+
124
+
\textbf{保持された価値：}Electronのキオスクモード経験がFedACキオスク設計を着想させ、それがさらにベアメタルOSアプローチを着想させた。Electronアプリは「ウィンドウの中のブラウザ」では不十分であることを証明した——ユーザー体験がブラウザタブを開くこととの十分な差別化がなく、独立したアプリを正当化できなかった。
125
+
126
+
\subsection{Androidアプリ}
127
+
128
+
完全なAndroidアプリがKotlinとJetpack Composeで構築された。2つのビルドバリアント（コンシューマー版とキオスク版）、自動化されたGitHub Actionsビルド、リリースAPKを含む。Google Play Consoleアカウントは作成されなかった。アプリはPlay Storeに提出されなかった。
129
+
130
+
\textbf{保持された価値：}キオスクバリアントのデバイス管理とロックタスク機能が単一目的ACデバイスのコンセプトを検証し、これが\acos{}の設計目標となった。
131
+
132
+
\subsection{Feral File統合}
133
+
134
+
DP-1 feedプロトコルクライアント、プレイリストリレープロキシ、KidLisp-to-FF1プロジェクションメカニズムがFeral FileのFF1ハードウェア上で\ac{}ピースを実行するために構築された（約25台出荷）。FFOSカーネルパッチが準備されたがマージされなかった。「Aesthetic Computerチャンネル」ランチャーはどのFF1デバイスにもインストールされなかった。
135
+
136
+
\textbf{保持された価値：}他者のオペレーティングシステムにパッチを当てることは結果の不確実な「重いエンジニアリング」であるという認識。これが直接的に、既存OSをforkするのではなくカスタムOSをゼロから構築する決定を推進した。
137
+
138
+
\subsection{パターン}
139
+
140
+
すべてのプラットフォーム試行が同じアークをたどった：動作するプロトタイプを構築し、配信インフラストラクチャを準備し、実際にユーザーに届ける「ラストマイル」で停滞する。失敗は技術的ではなかった——すべてのプロトタイプは動作した。失敗は\emph{注意力}の問題だった：一人の開発者が7つのプラットフォームターゲットを同時に維持することは、どのターゲットも本番品質に達するために必要な持続的注意を得られないことを意味した。
141
+
142
+
Lehmanの継続的変化の法則~\citep{lehman1980programs}がこの結果を予測していた：システムは満足を維持するために継続的に適応しなければならない。7つのプラットフォームは7つの継続的適応のストリームを必要とし、個人開発者には維持不可能だった。
143
+
144
+
\section{インフラストラクチャの過剰設計}
145
+
146
+
\subsection{Jamsocketセッションサーバー}
147
+
148
+
\ac{}のセッションサーバーは当初Jamsocket上にデプロイされていた——一時的なバックエンドコンテナのためのプラットフォーム。各ユーザーセッションが専用コンテナを生成し、独自のWebSocketエンドポイント、Redis接続、ライフサイクル管理を持っていた。アーキテクチャはエレガントだった：セッションが独立にスケールし、クラッシュが他のユーザーに影響せず、異なるリージョンにデプロイ可能だった。
149
+
150
+
これは単一のモノリシックサーバーに置き換えられた。Jamsocket統合コードは1つのコミットで削除された。古いEventSourceポーリング、API呼び出し、スケーリングロジックはデッドコードとなった。
151
+
152
+
\textbf{失敗の理由：}一時的コンテナの管理オーバーヘッド——コールドスタート遅延、接続切り替えの複雑さ、セッション単位のコスト——が、数十の同時ユーザー（数千ではなく）のプラットフォームには収益を上回った。モノリシックサーバーがより低い複雑さで実際の負荷を処理した。
153
+
154
+
\textbf{保持された価値：}セッションサーバーの内部アーキテクチャ（チャット管理、マルチプレイヤー状態同期）は移行後も存続した。破棄されたのはデプロイメントラッパーのみだった。
155
+
156
+
\subsection{Bumperシステム}
157
+
158
+
セッション/ユーザー状態の複雑な管理のための「bumperシステム」がHUD要素とnotepat統合を含めて構築された。その正確な目的は今や開発者自身にも不明である。「fix: completely remove all bumper system code」というタイトルのコミットで削除された。
159
+
160
+
\textbf{保持された価値：}なし。Bumperシステムはプロジェクトで最も純粋な行き止まりである——構築され、デプロイされ、削除され、現在のコードベースに一切の痕跡を残さなかった。
161
+
162
+
\subsection{Siloマイグレーション}
163
+
164
+
MongoDB Atlas比でコスト削減のため、DigitalOcean上に自己ホスト型MongoDBインスタンス（「Silo」）が構成された。インストールドキュメントが書かれ、ダッシュボードが構築され、ベンチマークが作成された。マイグレーションは実行されなかった。Siloドロップレットは月12ドルで空のまま稼働し続け、決して来ないかもしれないマイグレーションを待っている。
165
+
166
+
\textbf{コスト：}月12ドル $\times$ 6ヶ月 = 72ドル（そしてまだ増加中）、未使用サーバーのために。
167
+
168
+
\section{マネタイゼーション実験}
169
+
170
+
\subsection{Tezos NFT（Keeps）}
171
+
172
+
\ac{}のKidLispピースはTezosブロックチェーン上でFA2 NFTとしてミントできる。技術インフラストラクチャは動作する：SmartPyコントラクトがメインネットとテストネットにデプロイされ、IPFSメディアストレージ、Objktマーケットプレイス統合、ウォレット接続フローが整い、9人のオーナーが34アイテムをミントした。
173
+
174
+
市場は到来しなかった。KidLispはTezosの取引量上位25コレクション（24時間で約72 XTZ、閾値は100+ XTZ）に入ることはなかった。フロア価格はアイテムあたり4.42ドルで安定した。より広いTezos NFT市場は2025年を通じて縮小を続け、すべてのコレクションで「大量の供給過剰」がバイヤーの注意を抑制した。
175
+
176
+
\textbf{保持された価値：}KidLispピースコードシステム（\texttt{\$cow}のような短い英数字識別子）はNFTミンティングのために設計されたが、汎用的なピースアドレッシング方式となった。コード識別されるプログラムの生成、保存、共有のインフラストラクチャは、当初のマネタイゼーション目的を超えた。
177
+
178
+
\subsection{Sotce.netサブスクリプション}
179
+
180
+
サブスクリプションプラットフォーム（sotce.net）がStripe統合、Auth0認証、ページエディタ、\ac{}とのクロステナントアカウント同期で構築された。月額5ドルのサブスクリプション。技術実装は完全かつ運用可能だった。
181
+
182
+
サブスクリプションの成長は低調のまま。プラットフォームが生み出す収益はインフラストラクチャの複雑さを正当化するに足りなかった。運営は継続している。
183
+
184
+
\subsection{Printfulマーチャンダイズ}
185
+
186
+
Printfulマーチャントアカウントがステッカーとマグカップ用に設定された。「shop」ピースが構築された。商品カタログは限定的なまま。収益はごくわずかだった。
187
+
188
+
\textbf{パターン：}3つのマネタイゼーション実験すべてが同じ構造を共有する：技術的に完成しているが商業的に不活性。エンジニアリングはボトルネックではなかった；配信、マーケティング、マーケットフィットがボトルネックだった。
189
+
190
+
\section{一人のために作られたツール}
191
+
192
+
\subsection{ビデオレコーダー}
193
+
194
+
InstagramおよびTwitter品質プリセット付きのスクリーン録画・エクスポートツールが構築され、開発者が一時期使用した後、「oven」ベーキングシステムがそれを置き換えた時点で廃止された。現在は文字通り\texttt{deprecated/}という名前のディレクトリに格納されている。
195
+
196
+
\subsection{Windowsコンテナ開発}
197
+
198
+
notepatの同期のためにWindowsコンテナを使用したローカルUDP開発が試みられた。「時々単に動かなかった。」Windows開発パス全体が放棄され、Fedoraのみでの開発に移行した。
199
+
200
+
\subsection{\texttt{.pjs}コンパイラ}
201
+
202
+
「プロンプト式JavaScript」ファイルフォーマットが構想された：\texttt{.pjs}ファイルが実行時にLLMに送信され、LLMが実行可能なJavaScriptを生成する。TODOが書かれた。コードは続かなかった。フォーマットは\texttt{GRAVEYARD.txt}の注記として残っている。
203
+
204
+
\textbf{パターン：}これらの機能はいずれも、開発者自身だけが直面する問題を解決するために構築された。開発者のワークフローが変わると機能は陳腐化した。これは個人開発の職業的リスクである：ユーザーベースは$n=1$であり、$n=1$が移行すると機能のユーザーはゼロになる。
205
+
206
+
\section{過早な抽象化}
207
+
208
+
\subsection{汎用キオスクモード}
209
+
210
+
Android（デバイス管理+ロックタスク）、Electron（全画面+メニュー無効化）、Fedora（Waylandコンポジタロックダウン）で動作する統一「キオスクモード」抽象化の構築が試みられた。各プラットフォームのキオスク要件の違いが大きすぎて、抽象化は何のメリットも提供しなかった。統一アプローチは放棄され、プラットフォーム固有の実装に移行した。
211
+
212
+
\textbf{保持された価値：}キオスクコンピューティングには汎用抽象化ではなくハードウェア固有のソリューションが必要であるという洞察。この洞察が直接的にベアメタルOSアプローチにつながり、ハードウェア間での抽象化を試みない。
213
+
214
+
\subsection{FFOS Fork}
215
+
216
+
Feral FileのOSをforkして汎用x86\_64キオスクを作成する案が評価され、「重いエンジニアリング」として却下された。FFOSアーキテクチャはFF1ハードウェアに過度に特化しており（ARM、固有のディスプレイパイプライン、カスタムブートローダー）、コモディティラップトップに一般化できなかった。
217
+
218
+
\textbf{保持された価値：}FFOSをfork\emph{しない}という決定が\acos{}のゼロからの作成を強制し、結果としてforkよりもシンプルで保守しやすいシステムが生まれた。
219
+
220
+
\section{進化形態学}
221
+
222
+
\begin{table}[h]
223
+
\small
224
+
\centering
225
+
\begin{tabularx}{\columnwidth}{Xrrr}
226
+
\toprule
227
+
\textbf{カテゴリ} & \textbf{数} & \textbf{貢献率} & \textbf{復活可能} \\
228
+
\midrule
229
+
プラットフォーム分岐 & 5 & 80\% & 3 \\
230
+
インフラ実験 & 3 & 33\% & 1 \\
231
+
マネタイゼーション & 3 & 33\% & 3 \\
232
+
単一ユーザーツール & 3 & 0\% & 0 \\
233
+
過早な抽象化 & 2 & 100\% & 0 \\
234
+
\midrule
235
+
\textbf{合計} & \textbf{16} & \textbf{50\%} & \textbf{7} \\
236
+
\bottomrule
237
+
\end{tabularx}
238
+
\caption{カテゴリ別の痕跡的機能。「貢献率」=存続した機能にコードまたは洞察を提供した割合。「復活可能」=条件変化時に再活性化しうる数。}
239
+
\label{tab:vestigial}
240
+
\end{table}
241
+
242
+
貢献率はカテゴリによって大きく異なる。過早な抽象化の貢献率は100\%であるが、それはその休眠が\emph{情報}を生み出したからである——具体的には、汎用的なソリューションが不適切であるという知識。プラットフォーム分岐の貢献率は80\%であるが、各休眠プラットフォームが存続プラットフォームに何が必要かを教えたからである。
243
+
244
+
16の機能のうち7つは復活可能である：Androidアプリ（Play Store提出はまだ可能）、Electronアプリ（デスクトップ配布は特定のユースケースに対応可能）、Feral File統合（FF1ハードウェアがスケールすれば）、および3つのマネタイゼーション実験すべて（Tezos Keeps、Sotce.net、マーチャンダイズ——各々技術的に完成しており、エンジニアリング作業ではなく市場条件を待っている）。SiloマイグレーションはMongoDB Atlasのコストが持続不可能になれば1日で実行できる。
245
+
246
+
単一ユーザーツールは貢献率も復活率もともに0\%である。それらは開発の足場——建設中は有用で、完了後に撤去され、痕跡を残さなかった。
247
+
248
+
\subsection{休眠が明かすもの}
249
+
250
+
プロジェクトの痕跡的機能は、それが現在の姿になる前に\emph{何になろうとしていたか}——そして条件が変われば\emph{まだ何になりうるか}を明かす。\ac{}の休眠パスが明かすこと：
251
+
252
+
\begin{itemize}
253
+
\item \emph{ユビキタス}への欲望（7つのプラットフォーム）が、\emph{特定の場所}（Web + ベアメタル）に規律されたこと——しかしAndroidとElectronのコードはまだコンパイルできる
254
+
\item \emph{技術的完成度}（動作するプロトタイプ）が\emph{製品準備完了}（ユーザーへの出荷）と等しいという信念——反証されたが否定はされていない、プロトタイプはまだ動作するので
255
+
\item \emph{マネタイゼーションインフラストラクチャを構築}すれば市場が来るという仮定——市場はまだ来ていないが、来ればインフラストラクチャは準備できている
256
+
\item 既存システムの適応よりも\emph{ゼロから構築する}ことへの選好が、FFOS forkが却下されカスタムOSが構築されたときに正当化されたこと
257
+
\end{itemize}
258
+
259
+
\section{結論}
260
+
261
+
5年間で16の痕跡的機能。半数が存続した機能にコードまたは洞察を提供し、7つはまだ復活可能である。生物学の比喩は「失敗」よりも誠実である：これらは死んだ組織ではなく、生きたシステムの中の休眠構造である。Androidアプリは失敗したのではない——眠っている。NFTインフラストラクチャは失敗したのではない——マネタイゼーション機能を脱落させ、アドレッシングスキームを保持した。Jamsocketアーキテクチャは失敗したのではない——それに取って代わったモノリシックサーバーに内部構造を提供した。
262
+
263
+
\ac{}の歴史で最も重要な休眠パスは、最も価値ある結果を生んだものである：汎用キオスク抽象化の構築の試みが休眠に入り、ベアメタルオペレーティングシステムのゼロからの作成を強制した——これは現在、プロジェクトの技術的に最も特徴的な貢献である。最良の痕跡的機能とは、その休眠が有機体に正しい肢を構築させたものである。
264
+
265
+
Brooksは「捨てることを計画せよ；いずれにせよ捨てることになる」と述べた~\citep{brooks1975mythical}。\ac{}は16個を棚上げした。7つは明日にも目覚めるかもしれない。17番目の試み——7.3秒で起動する単一ファイルオペレーティングシステム——はまだ動いている。
266
+
267
+
\vspace{0.5em}
268
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
269
+
270
+
\vspace{0.5em}
271
+
\noindent\textit{英語原版からの翻訳。原版は \url{https://papers.aesthetic.computer} を参照。}
272
+
273
+
\bibliographystyle{plainnat}
274
+
\bibliography{references}
275
+
276
+
\end{document}
+13
-11
papers/arxiv-diversity/diversity-cards.tex
+13
-11
papers/arxiv-diversity/diversity-cards.tex
···
40
40
\thispagestyle{empty}
41
41
\vspace*{\fill}
42
42
\begin{center}
43
-
\includegraphics[height=8em]{pals}\par\vspace{0.3em}
44
-
{\acbold\fontsize{20pt}{24pt}\selectfont\color{acdark} Citation Diversity Audit}\par
45
-
\vspace{0.3em}
46
-
{\fontsize{10pt}{12pt}\selectfont\color{acpink} \acrandname{} Paper Series, March 2026}\par
47
-
\vspace{0.8em}
48
-
{\normalsize\color{cyan!70!blue}\textbf{@jeffrey}}\par
43
+
\includegraphics[height=9em]{pals}\par\vspace{0.1em}
44
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} Citation Diversity Audit}\par
45
+
\vspace{0.1em}
46
+
{\fontsize{9pt}{11pt}\selectfont\color{acpink} \acrandname{} Paper Series, March 2026}\par
47
+
\vspace{0.4em}
48
+
{\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par
49
49
{\small\color{acgray} Aesthetic.Computer}\par
50
50
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
51
-
\vspace{0.8em}
52
-
\rule{0.6\textwidth}{1pt}\par
53
51
\vspace{0.4em}
54
-
{\small\color{acpink!40}\textit{working draft --- not for citation}}\par
55
-
\vspace{0.3em}
56
-
{\footnotesize\color{acgray} March 2026}\par
52
+
\rule{0.5\textwidth}{0.5pt}\par
53
+
\vspace{0.15em}
54
+
\colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par
55
+
\vspace{0.1em}
56
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/2113ef735}{2113ef735}}\par
57
+
\vspace{0.1em}
58
+
{\footnotesize\color{acgray}\href{https://papers.aesthetic.computer/citation-diversity-audit-26-da-cards.pdf}{Dansk} · \href{https://papers.aesthetic.computer/citation-diversity-audit-26-es-cards.pdf}{Español} · \href{https://papers.aesthetic.computer/citation-diversity-audit-26-zh-cards.pdf}{{\accjk 中文}} · \href{https://papers.aesthetic.computer/citation-diversity-audit-26-ja-cards.pdf}{{\accjk 日本語}}}\par
57
59
\end{center}
58
60
\vspace*{\fill}
59
61
+338
papers/arxiv-diversity/diversity-ja.tex
+338
papers/arxiv-diversity/diversity-ja.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
11
+
\setmainfont{Latin Modern Roman}
12
+
\setsansfont{Latin Modern Sans}
13
+
14
+
% Custom AC fonts
15
+
\newfontfamily\acbold{ywft-processing-bold}[
16
+
Path=../../system/public/type/webfonts/,
17
+
Extension=.ttf
18
+
]
19
+
\newfontfamily\aclight{ywft-processing-light}[
20
+
Path=../../system/public/type/webfonts/,
21
+
Extension=.ttf
22
+
]
23
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
24
+
25
+
% === CJK SUPPORT ===
26
+
\usepackage{xeCJK}
27
+
\setCJKmainfont{Droid Sans Japanese}
28
+
\setCJKsansfont{Droid Sans Japanese}
29
+
\setCJKmonofont{Droid Sans Japanese}
30
+
31
+
% === PACKAGES ===
32
+
\usepackage{xcolor}
33
+
\usepackage{titlesec}
34
+
\usepackage{enumitem}
35
+
\usepackage{booktabs}
36
+
\usepackage{tabularx}
37
+
\usepackage{multicol}
38
+
\usepackage{fancyhdr}
39
+
\usepackage{hyperref}
40
+
\usepackage{graphicx}
41
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
42
+
\usepackage{ragged2e}
43
+
\usepackage{microtype}
44
+
\usepackage{listings}
45
+
\usepackage{natbib}
46
+
\usepackage[colorspec=0.92]{draftwatermark}
47
+
48
+
% === COLORS (AC palette) ===
49
+
\definecolor{acpink}{RGB}{180,72,135}
50
+
\definecolor{acpurple}{RGB}{120,80,180}
51
+
\definecolor{acdark}{RGB}{64,56,74}
52
+
\definecolor{acgray}{RGB}{119,119,119}
53
+
\definecolor{acgreen}{RGB}{78,203,113}
54
+
\definecolor{draftcolor}{RGB}{180,72,135}
55
+
56
+
% === DRAFT WATERMARK ===
57
+
\DraftwatermarkOptions{
58
+
text=WORKING DRAFT,
59
+
fontsize=3cm,
60
+
color=draftcolor!18,
61
+
angle=45,
62
+
pos={0.5\paperwidth, 0.5\paperheight}
63
+
}
64
+
65
+
% === HYPERREF ===
66
+
\hypersetup{
67
+
colorlinks=true,
68
+
linkcolor=acpurple,
69
+
urlcolor=acpurple,
70
+
citecolor=acpurple,
71
+
pdfauthor={@jeffrey},
72
+
pdftitle={Aesthetic Computer 論文シリーズ引用多様性監査},
73
+
}
74
+
75
+
% === SECTION FORMATTING ===
76
+
\titleformat{\section}
77
+
{\normalfont\bfseries\normalsize}
78
+
{\thesection.}
79
+
{0.5em}
80
+
{}
81
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
82
+
83
+
\titleformat{\subsection}
84
+
{\normalfont\bfseries\small}
85
+
{\thesubsection}
86
+
{0.5em}
87
+
{}
88
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
89
+
90
+
% === HEADER/FOOTER ===
91
+
\pagestyle{fancy}
92
+
\fancyhf{}
93
+
\renewcommand{\headrulewidth}{0pt}
94
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{作業草稿 --- 引用不可}}
95
+
\fancyfoot[C]{\footnotesize\thepage}
96
+
97
+
% === CUSTOM COMMANDS ===
98
+
\newcommand{\acdot}{{\color{acpink}.}}
99
+
\newcommand{\ac}{\textsc{Aesthetic.Computer}}
100
+
101
+
% === LIST SETTINGS ===
102
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
103
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
104
+
105
+
% === COLUMN SEPARATION ===
106
+
\setlength{\columnsep}{1.8em}
107
+
108
+
% === PARAGRAPH SETTINGS ===
109
+
\setlength{\parindent}{1em}
110
+
\setlength{\parskip}{0.3em}
111
+
112
+
% Hyphenation for narrow two-column layout
113
+
\tolerance=800
114
+
\emergencystretch=1em
115
+
\hyphenpenalty=50
116
+
117
+
\begin{document}
118
+
119
+
% ============ TITLE BLOCK ============
120
+
121
+
\twocolumn[{%
122
+
\begin{center}
123
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
124
+
{\acbold\fontsize{20pt}{24pt}\selectfont\color{acdark} 引用多様性監査}\par
125
+
\vspace{0.2em}
126
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} Aesthetic Computer 論文シリーズ、2026年3月}\par
127
+
\vspace{0.6em}
128
+
{\normalsize @jeffrey}\par
129
+
{\small\color{acgray} Aesthetic.Computer}\par
130
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
131
+
\vspace{0.3em}
132
+
{\small\color{acpurple} \url{https://papers.aesthetic.computer}}\par
133
+
\vspace{0.6em}
134
+
\rule{\textwidth}{1.5pt}
135
+
\vspace{0.5em}
136
+
\end{center}
137
+
138
+
\begin{center}
139
+
{\small\color{acpink}\textbf{[ 作業草稿 --- 引用不可 ]}}
140
+
\end{center}
141
+
\vspace{0.3em}
142
+
143
+
\begin{quote}
144
+
\small\noindent\textbf{要旨。}
145
+
\ac{} 論文シリーズの引用実践について監査を行った。本シリーズは、クリエイティブ・コンピューティング、言語設計、オペレーティングシステム、デジタル楽器設計を扱う8本の学術論文で構成される。監査の結果、約80名の個別著者のうち、女性（約11\%）、非西洋圏の研究者（約5\%）、黒人・先住民・ラテン系の研究者（約6\%）が著しく過少代表であることが明らかになった。各論文を強化し引用基盤を多様化できる具体的な著作を特定し、各論文で女性著者30\%、非西洋圏著者20\%という統合目標を提案するとともに、ギャップ領域別に整理したオープンな読書リストを公開する。本文書は自己評価であると同時に、継続的な改善への誓約である。
146
+
\end{quote}
147
+
\vspace{0.5em}
148
+
}]
149
+
150
+
% ============ 1. WHY THIS AUDIT ============
151
+
152
+
\section{なぜこの監査を行うのか}
153
+
154
+
\ac{} 論文シリーズ~\citep{scudder2026ac, scudder2026kidlisp, scudder2026acos, scudder2026pieces, scudder2026notepat}は、アクセシビリティ、包摂性、クリエイティブな表現について主張を展開している。普遍的なクリエイティブ・コンピューティングへのアクセスを提唱するプロジェクト——遊休ノートパソコンを楽器として活用し、URLでアドレス可能なプログラムを提供し、デフォルトでソーシャルな配信を行う——は、その学術的基盤が自らが提唱する多様性を反映しているかどうかを検証しなければならない。
155
+
156
+
引用実践は中立ではない。引用は一種の知識経済を形成する：誰を引用するかが、誰が読まれ、誰が雇用され、誰が資金を得て、誰のアイデアが基礎的とみなされるかを決定する~\citep{benjamin2019race}。白人・男性・米英欧の著者が支配的な論文シリーズは、まさにそれが抵抗しようとする排除を再生産する。
157
+
158
+
この監査は告発ではなく、診断である。現在の引用分布は著者の学術的訓練、読書履歴、そして関連分野（メディア理論、コンピュータサイエンス、HCI）の構造を反映している。これを変えるには長期にわたる意図的な努力が必要である。
159
+
160
+
% ============ 2. CURRENT STATE ============
161
+
162
+
\section{現状}
163
+
164
+
\subsection{コーパス}
165
+
166
+
監査は以下の8本の論文を対象とする：
167
+
168
+
\begin{enumerate}
169
+
\item \emph{Aesthetic Computer '26}（arXiv、5ページ）
170
+
\item \emph{KidLisp '26}（arXiv、6ページ）
171
+
\item \emph{Pieces Not Programs '26}（arXiv、4ページ）
172
+
\item \emph{notepat.com '26}（arXiv、3ページ）
173
+
\item \emph{AC Native OS '26}（arXiv、5ページ）
174
+
\item \emph{Repository Archaeology '26}（arXiv、4ページ）
175
+
\item \emph{Aesthetic Computer '26}（JOSS、2ページ）
176
+
\item \emph{KidLisp '26}（JOSS、3ページ）
177
+
\end{enumerate}
178
+
179
+
これに加え、30以上の全文ソースを含む読書ライブラリが \texttt{papers.aesthetic.computer/platter} のリサーチコレクションで管理されている。
180
+
181
+
\subsection{人口統計}
182
+
183
+
全論文を通じて、約68の独立した著作が約80名の個別著者によって引用されている（一部の著作には複数の著者がいる）。著者を3つの軸で分類した：ジェンダー、地域、人種・民族。これらの分類は不完全であり外部から帰属されたものである。代表性の大まかな指標として用いるものであり、アイデンティティの宣言ではない。
184
+
185
+
\begin{table}[h]
186
+
\small
187
+
\centering
188
+
\begin{tabular}{lrr}
189
+
\toprule
190
+
\textbf{軸} & \textbf{人数} & \textbf{割合} \\
191
+
\midrule
192
+
女性著者 & $\sim$9 & 11\% \\
193
+
非米英欧著者 & $\sim$4 & 5\% \\
194
+
黒人 / 先住民 / ラテン系 / アジア系 & $\sim$5 & 6\% \\
195
+
自己引用（Scudder） & 5 & 6\% \\
196
+
\midrule
197
+
\textbf{個別著者合計} & $\sim$80 & 100\% \\
198
+
\bottomrule
199
+
\end{tabular}
200
+
\caption{全論文の著者人口統計（2026年3月）。}
201
+
\label{tab:demographics}
202
+
\end{table}
203
+
204
+
\subsection{これが意味すること}
205
+
206
+
引用コーパスは白人・男性・欧米の著者が圧倒的に支配的である。これはクリエイティブ・コンピューティングの論文では珍しくない——この分野の標準的な参考文献（Processing、Scratch、p5.js、Sonic Pi）はすべてMIT、NYU、ITP、Cambridgeに位置するチームによって作られた。しかし「珍しくない」は「許容できる」を意味しない。\ac{} プロジェクトは主流のコンピューティングパラダイムに対するオルタナティブとして明確に自らを位置づけている。その引用はオルタナティブな声を反映すべきである。
207
+
208
+
% ============ 3. GAP ANALYSIS ============
209
+
210
+
\section{ギャップ分析}
211
+
212
+
引用コーパスが最も弱い5つの領域を特定した。
213
+
214
+
\subsection{クリエイティブ・コーディングにおける女性}
215
+
216
+
クリエイティブ・コーディングおよびライブコーディングのコミュニティには女性による重要な仕事が多数あるが、本論文シリーズでは引用されていない。主要な人物には以下が含まれる：
217
+
218
+
\begin{itemize}
219
+
\item \textbf{Joana Chicau}~\citep{chicau2021choreo}：振付的コーディング、身体化されたアルゴリズム
220
+
\item \textbf{Shelly Knotts}~\citep{knotts2015algorithmic}：ネットワーク音楽におけるアルゴリズム的コラボレーション
221
+
\item \textbf{Allison Parrish}~\citep{parrish2015programming}：計算詩学、クリエイティブ・コーディング教育
222
+
\item \textbf{Kate Compton}~\citep{compton2015tracery}：Tracery 生成テキスト言語
223
+
\item \textbf{Lauren McCarthy}：既に引用済み（p5.js）だが、クリエイティブな実践者としてのアイデンティティが十分に認識されていない
224
+
\item \textbf{Olivia Jack}：既に引用済み（Hydra）だが、ラテンアメリカのライブコーディングにおける声としてのアイデンティティが十分に認識されていない
225
+
\end{itemize}
226
+
227
+
\subsection{黒人コンピューティング研究}
228
+
229
+
コンピューティングへのアクセスを民主化すると主張するプロジェクトは、歴史的に誰がコンピューティングから排除されてきたか、そしてその理由を研究する学問と対話しなければならない：
230
+
231
+
\begin{itemize}
232
+
\item \textbf{Ruha Benjamin}~\citep{benjamin2019race}：『Race After Technology（テクノロジー以後の人種）』は、設計上の決定がいかに人種的階層を符号化するかを考察する
233
+
\item \textbf{Safiya Umoja Noble}~\citep{noble2018algorithms}：『Algorithms of Oppression（抑圧のアルゴリズム）』は検索エンジンと人種的偏見を論じる
234
+
\item \textbf{Andr\'e Brock}~\citep{brock2020distributed}：『Distributed Blackness（分散された黒人性）』は黒人デジタル文化とプラットフォーム設計を論じる
235
+
\item \textbf{Charlton McIlwain}~\citep{mcilwain2019black}：『Black Software（ブラック・ソフトウェア）』は黒人コンピューティングの隠された歴史を明らかにする
236
+
\end{itemize}
237
+
238
+
\subsection{非西洋の理論}
239
+
240
+
メディア理論の引用はすべてヨーロッパの伝統（Kittler、McLuhan、Adorno）に由来する。非西洋の理論家は \ac{} の設計に直接関連する枠組みを提供している：
241
+
242
+
\begin{itemize}
243
+
\item \textbf{ユク・ホイ（Yuk Hui）}~\citep{hui2016existence, hui2019recursion}：デジタル存在論、技術的多様性——テクノロジーは単一の西洋的発展経路をたどる必要はないという議論
244
+
\item \textbf{Hito Steyerl}~\citep{steyerl2009poor}：「貧しい画像を擁護する」は流通、解像度、デジタルの物質性を論じる——\ac{} のピクセルアート美学およびURLとしてのメディアのアプローチに直接関連する
245
+
\item \textbf{Kodwo Eshun}~\citep{eshun1998brilliant}：アフロフューチャリストのソニックフィクション——notepatおよび音響合成の仕事に関連する
246
+
\end{itemize}
247
+
248
+
\subsection{先住民と脱植民地化コンピューティング}
249
+
250
+
オペレーティングシステム論文の遊休ハードウェアに関する議論は、コンピューティング主権に対して深い含意を持っており、先住民の研究者がこれについて論じている：
251
+
252
+
\begin{itemize}
253
+
\item \textbf{Lewis ら}~\citep{lewis2018kin}：「機械との親族関係の構築」はAIとコンピューティングのための先住民プロトコルを提案する
254
+
\item \textbf{Sasha Costanza-Chock}~\citep{costanza2020design}：『Design Justice（デザイン・ジャスティス）』はコミュニティ主導の設計実践を論じる
255
+
\item \textbf{Arturo Escobar}~\citep{escobar2018designs}：『Designs for the Pluriverse（多元宇宙のためのデザイン）』は脱植民地化のデザイン手法を論じる
256
+
\end{itemize}
257
+
258
+
\subsection{ラテンアメリカのクリエイティブ・コーディング}
259
+
260
+
Olivia Jack（Hydra、既に引用済み）はコロンビア人である。より広いラテンアメリカのクリエイティブ・コーディングコミュニティの代表性が不足している：
261
+
262
+
\begin{itemize}
263
+
\item \textbf{Hernando Barrag\'an}~\citep{barragan2004wiring}：コロンビア人、Wiringの創設者であり、Arduinoの直接的な前身——フィジカル・コンピューティングの基礎を築いたにもかかわらず、ほとんど引用されていない
264
+
\item \textbf{C\'assia Bel}：ブラジルのライブコーダーおよびフェミニスト・クリエイティブ・テクノロジスト
265
+
\item \textbf{Aar\'on Montoya-Moraga}：クリエイティブ・コーディング教育者、p5.jsコミュニティオーガナイザー
266
+
\end{itemize}
267
+
268
+
% ============ 4. PER-PAPER TARGETS ============
269
+
270
+
\section{各論文の統合目標}
271
+
272
+
シリーズの各論文について、ギャップ分析から、論証を強化し引用基盤を多様化できる具体的な著作を特定した。
273
+
274
+
\begin{table}[h]
275
+
\small
276
+
\centering
277
+
\begin{tabularx}{\columnwidth}{lX}
278
+
\toprule
279
+
\textbf{論文} & \textbf{追加推奨} \\
280
+
\midrule
281
+
AC '26 & ユク・ホイ（デジタルオブジェクト）、Costanza-Chock（デザイン・ジャスティス）、Parrish（クリエイティブ・コーディング教育） \\
282
+
\addlinespace
283
+
KidLisp '26 & Compton（Tracery）、Chicau（振付的コーディング）、Barrag\'an（Wiring） \\
284
+
\addlinespace
285
+
notepat '26 & Knotts（ネットワーク音楽）、Eshun（ソニックフィクション）、Plant（コンピューティングの歴史） \\
286
+
\addlinespace
287
+
Pieces '26 & Benjamin（設計バイアス）、Steyerl（貧しい画像）、Plant（Zeros and Ones） \\
288
+
\addlinespace
289
+
OS '26 & Barrag\'an（Wiring）、McIlwain（ブラック・ソフトウェア）、Lewisら（先住民AI） \\
290
+
\addlinespace
291
+
Archaeology '26 & Brock（分散された黒人性）、ユク・ホイ（技術的多様性） \\
292
+
\bottomrule
293
+
\end{tabularx}
294
+
\caption{各論文のターゲット引用追加。目標：女性30\%、非西洋圏20\%。}
295
+
\label{tab:targets}
296
+
\end{table}
297
+
298
+
% ============ 5. TARGETS ============
299
+
300
+
\section{目標と誓約}
301
+
302
+
\subsection{定量目標}
303
+
304
+
\begin{itemize}
305
+
\item \textbf{論文シリーズ全体で女性著者30\%}（現在11\%）
306
+
\item \textbf{非米英欧著者20\%}（現在5\%）
307
+
\item \textbf{黒人・先住民・ラテン系・アジア系の研究者15\%}（現在6\%）
308
+
\item \textbf{各論文に女性著者の引用を少なくとも2件含める}
309
+
\end{itemize}
310
+
311
+
これらの目標は理想的な最低基準であり、上限ではない。関連する学術成果の追加によって達成すべきであり、既存の引用の削除やトークン的な参考文献の追加によってではない。
312
+
313
+
\subsection{プロセスの誓約}
314
+
315
+
\begin{enumerate}
316
+
\item \textbf{改訂ごとの多様性チェック}：論文を提出する前に、現在の引用人口統計に対して再度監査を行う
317
+
\item \textbf{読書リストの維持}：リサーチコレクションの引用多様性セクションは生きた文書である——新しい著作は発見され読まれた時点で継続的に追加される
318
+
\item \textbf{全文アクセス}：可能な限り、引用した著作のオープンアクセス版を読書ライブラリに入手・保存し、表面的な引用ではなく真の関与を実現する
319
+
\item \textbf{誠実な関与}：著作を引用するのは、それが論証を強化するからであり、スプレッドシートを多様化するためではない。引用する著作は、読み、理解し、論文の推論に統合されるべきである
320
+
\end{enumerate}
321
+
322
+
% ============ 6. HONEST ASSESSMENT ============
323
+
324
+
\section{正直な評価}
325
+
326
+
この監査は学術的自己省察においてよく見られるパターンを明らかにした：著者は問題を認識し、引用すべき研究者を列挙でき、進捗を追跡する技術的インフラを持っている——しかし、まだ読書を完了していない。Ruha Benjaminが『Race After Technology』を書いたことを知っていることは、それを読み、理解し、その洞察を自らの設計実践に統合したこととは異なる。
327
+
328
+
認識と実践のギャップこそが、この作業の出発点である。リサーチコレクションの読書リストは、このギャップを埋めるための誓約である。各論文の目標はアカウンタビリティの仕組みである。監査そのもの——それが批判する論文と共に公開される——は、著者が自らに設定した基準で著者に対して説明責任を求めるよう読者を招くものである。
329
+
330
+
\vspace{0.5em}
331
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
332
+
333
+
% ============ REFERENCES ============
334
+
335
+
\bibliographystyle{plainnat}
336
+
\bibliography{references}
337
+
338
+
\end{document}
+13
-11
papers/arxiv-folk-songs/folk-songs-cards.tex
+13
-11
papers/arxiv-folk-songs/folk-songs-cards.tex
···
51
51
\thispagestyle{empty}
52
52
\vspace*{\fill}
53
53
\begin{center}
54
-
\includegraphics[height=8em]{pals}\par\vspace{0.3em}
55
-
{\acbold\fontsize{20pt}{24pt}\selectfont\color{acdark} Playable Folk Songs}\par
56
-
\vspace{0.3em}
57
-
{\fontsize{10pt}{12pt}\selectfont\color{acpink} Oral Tradition Meets the Browser Keyboard}\par
58
-
\vspace{0.8em}
59
-
{\normalsize\color{cyan!70!blue}\textbf{@jeffrey}}\par
54
+
\includegraphics[height=9em]{pals}\par\vspace{0.1em}
55
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} Playable Folk Songs}\par
56
+
\vspace{0.1em}
57
+
{\fontsize{9pt}{11pt}\selectfont\color{acpink} Oral Tradition Meets the Browser Keyboard}\par
58
+
\vspace{0.4em}
59
+
{\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par
60
60
{\small\color{acgray} Aesthetic.Computer}\par
61
61
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
62
-
\vspace{0.8em}
63
-
\rule{0.6\textwidth}{1pt}\par
64
62
\vspace{0.4em}
65
-
{\small\color{acpink!40}\textit{working draft --- not for citation}}\par
66
-
\vspace{0.3em}
67
-
{\footnotesize\color{acgray} March 2026}\par
63
+
\rule{0.5\textwidth}{0.5pt}\par
64
+
\vspace{0.15em}
65
+
\colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par
66
+
\vspace{0.1em}
67
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/2113ef735}{2113ef735}}\par
68
+
\vspace{0.1em}
69
+
{\footnotesize\color{acgray}\href{https://papers.aesthetic.computer/folk-songs-26-arxiv-da-cards.pdf}{Dansk} · \href{https://papers.aesthetic.computer/folk-songs-26-arxiv-es-cards.pdf}{Español} · \href{https://papers.aesthetic.computer/folk-songs-26-arxiv-zh-cards.pdf}{{\accjk 中文}} · \href{https://papers.aesthetic.computer/folk-songs-26-arxiv-ja-cards.pdf}{{\accjk 日本語}}}\par
68
70
\end{center}
69
71
\vspace*{\fill}
70
72
+298
papers/arxiv-folk-songs/folk-songs-ja.tex
+298
papers/arxiv-folk-songs/folk-songs-ja.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[11pt]{article}
3
+
4
+
\usepackage{fontspec}
5
+
\usepackage{unicode-math}
6
+
\setmainfont{Latin Modern Roman}
7
+
\setsansfont{Latin Modern Sans}
8
+
\setmonofont{Latin Modern Mono}[Scale=0.88]
9
+
\usepackage{xeCJK}
10
+
\setCJKmainfont{Droid Sans Japanese}
11
+
\setCJKsansfont{Droid Sans Japanese}
12
+
\setCJKmonofont{Droid Sans Japanese}
13
+
14
+
\usepackage{graphicx}
15
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
16
+
\usepackage{booktabs}
17
+
\usepackage{tabularx}
18
+
\usepackage{ragged2e}
19
+
\usepackage{microtype}
20
+
\usepackage{natbib}
21
+
\usepackage{listings}
22
+
23
+
\makeatletter
24
+
\def\input@path{{../}}
25
+
\makeatother
26
+
\usepackage{ac-paper-cards}
27
+
28
+
\hypersetup{
29
+
pdftitle={演奏可能な民謡：口承伝統とブラウザキーボードの出会い},
30
+
}
31
+
32
+
% Listing style for notepat song notation
33
+
\lstdefinestyle{notepat}{
34
+
basicstyle=\ttfamily\small,
35
+
breaklines=true,
36
+
columns=flexible,
37
+
keepspaces=true,
38
+
showstringspaces=false,
39
+
}
40
+
41
+
\begin{document}
42
+
43
+
% ============================================================
44
+
% TITLE CARD
45
+
% ============================================================
46
+
\thispagestyle{empty}
47
+
\vspace*{\fill}
48
+
\begin{center}
49
+
\includegraphics[height=3em]{pals}\par\vspace{0.6em}
50
+
{\acbold\fontsize{20pt}{24pt}\selectfont\color{acdark} 演奏可能な}\par
51
+
{\acbold\fontsize{20pt}{24pt}\selectfont\color{acdark} 民謡}\par
52
+
\vspace{0.3em}
53
+
{\aclight\fontsize{10pt}{12pt}\selectfont\color{acpink} 口承伝統とブラウザキーボードの出会い}\par
54
+
\vspace{0.8em}
55
+
{\normalsize @jeffrey}\par
56
+
{\small\color{acgray} Aesthetic.Computer}\par
57
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
58
+
\vspace{0.3em}
59
+
{\small\color{acpurple} \url{https://notepat.com}}\par
60
+
\vspace{0.8em}
61
+
\rule{0.6\textwidth}{1pt}\par
62
+
\vspace{0.4em}
63
+
{\small\color{acpink}\textbf{[ 作業草稿 --- 引用不可 ]}}\par
64
+
\vspace{0.3em}
65
+
{\footnotesize\color{acgray} 2026年3月}\par
66
+
\end{center}
67
+
\vspace*{\fill}
68
+
69
+
% ============================================================
70
+
% ABSTRACT CARD
71
+
% ============================================================
72
+
\clearpage
73
+
\begin{accentcard}
74
+
\cardtitle{要旨}
75
+
76
+
民謡は、楽譜なしに演奏でき、楽器なしに記憶でき、許可なしに改変できるように進化してきた。これらの特性——限られた音域、反復的な構造、口承による伝達可能性——は、民謡の旋律をブラウザベースのキーボードシンセサイザーに構造的に適したものにしている。
77
+
78
+
\vspace{0.3em}
79
+
80
+
本論文は、演奏可能な民謡を \np{}.com に統合する過程を記述する。\np{} は半音階キーボード楽器であり、QWERTYキーを音符にマッピングする。軽量な \texttt{NOTE:word} フォーマットを用いて民謡の旋律をエンコードし、各音高を歌詞の音節とペアリングすることで、楽器が一音ずつ曲を教えるガイド付き演奏モードを実現する。
81
+
82
+
\vspace{0.3em}
83
+
84
+
このエンコーディング方式に適した民謡旋律のコレクションを調査し、民謡の構造的制約がキーボードとしての楽器インターフェースになぜ適合するかを分析し、民謡のプロセス——変異、選択、口承伝達——がURLで共有・フォーク可能な曲エンコーディングにおいて自然なデジタル対応物を持つことを論じる。
85
+
\end{accentcard}
86
+
87
+
% ============================================================
88
+
% SECTION 1: THE ARGUMENT
89
+
% ============================================================
90
+
\section{論点}
91
+
92
+
民謡は人類最古のオープンソースソフトウェアである。
93
+
94
+
単一の作者を持たない。コミュニティによって維持される。口承で伝播する——つまり、記憶できるほど単純で、再現できるほど制約があり、適応できるほど柔軟でなければならない。すべての歌い手は貢献者であり、すべての演唱はフォークである。
95
+
96
+
\vspace{0.3em}
97
+
98
+
これらはまさに、旋律をQWERTYキーボードで演奏可能にする特性でもある。
99
+
100
+
\begin{card}
101
+
\cardtitle{なぜ民謡なのか？}
102
+
\begin{itemize}
103
+
\item \textbf{狭い音域}：ほとんどの民謡旋律は1〜1.5オクターブの範囲に収まる~\citep{lomax1968folk}。\np{} の2オクターブボタングリッドはそれらを完全にカバーできる。
104
+
\item \textbf{ペンタトニックの傾向}：多くの伝統は5音音階を好む~\citep{kodaly1971folk}。これにより次の音を見つける認知的負担が軽減される。
105
+
\item \textbf{反復構造}：繰り返される8小節フレーズ、コール＆レスポンス、ヴァース＝コーラス形式——これらは記憶とガイド再生を助ける。
106
+
\item \textbf{間違った音がない}：ペンタトニック旋律では、隣接する音階音は協和する。オルフ・シュールヴェルク教授法は、取り外し可能な木琴バーによって同じ特性を利用している~\citep{orff1978schulwerk}。
107
+
\end{itemize}
108
+
\end{card}
109
+
110
+
% ============================================================
111
+
% SECTION 2: THE INSTRUMENT
112
+
% ============================================================
113
+
\section{楽器}
114
+
115
+
\np{}.com は、\ac{} 内の「ピース」（インタラクティブプログラム）として構築されたブラウザベースの半音階シンセサイザーである~\citep{scudder2026ac, scudder2026notepat}。QWERTYキーボードを2オクターブにわたる24の半音にマッピングし、オクターブ切り替えにより完全なピアノ音域をカバーする。
116
+
117
+
\begin{darkcard}
118
+
\textbf{曲モード}は \np{} を自由演奏楽器からガイド付き演奏インターフェースに変換する。スクロールする歌詞トラックが現在の音節を表示し、正しい音だけがアクティブになり、それを押すと次の音節に進む。演奏者は間違えることができない——待つことだけができる。
119
+
\end{darkcard}
120
+
121
+
この「補助輪」方式——間違った音をブロックし、正しい音をハイライトする——は、楽器を制限して学習者の現在の能力に合わせるオルフとコダーイの教授法を反映している~\citep{kodaly1971folk, orff1978schulwerk}。
122
+
123
+
% ============================================================
124
+
% SECTION 3: THE ENCODING
125
+
% ============================================================
126
+
\section{エンコーディング方式}
127
+
128
+
\np{} の曲は、スペースで区切られた \texttt{NOTE:word} ペアとしてエンコードされる：
129
+
130
+
\notesong{C:Twin- C:-kle G:twin- G:-kle A:lit- A:-tle G:star,\\
131
+
F:how F:I E:won- E:-der D:what D:you C:are.}
132
+
133
+
各トークンは音名（\texttt{C}、\texttt{G}、\texttt{A}、\texttt{F\#} など）がコロンで歌詞音節とペアリングされている。ハイフンは音節の継続を示す：末尾ハイフン（\texttt{Twin-}）は次のトークンが同じ単語の続きであることを、先頭ハイフン（\texttt{-kle}）は継続部分であることを示す。
134
+
135
+
\begin{card}
136
+
\cardtitle{設計特性}
137
+
\begin{itemize}
138
+
\item \textbf{人間可読}：音楽家がエンコーディングを直接読める。
139
+
\item \textbf{URL安全}：曲をURLパラメータとして \np{} に渡せる。
140
+
\item \textbf{フォーク可能}：コピー、編集、共有——テキスト文字列における民謡のプロセス。
141
+
\item \textbf{ミニマル}：音価なし、強弱なし、テンポなし。三つとも演奏者が制御する。
142
+
\end{itemize}
143
+
\end{card}
144
+
145
+
リズム情報の欠如は意図的である。口承伝統において、リズムは演奏者に属し、楽譜には属さない~\citep{lomax1968folk}。エンコーディングは\emph{何を}演奏するかを捉え、演奏者が\emph{どう}演奏するかを決定する。
146
+
147
+
% ============================================================
148
+
% SECTION 4: A CATALOG
149
+
% ============================================================
150
+
\section{演奏可能な旋律カタログ}
151
+
152
+
複数の伝統から民謡コレクションを調査し、\np{} の2オクターブグリッドに最適化された旋律を選択した。選択基準：音域 $\leq$\,15半音、ペンタトニックまたは単純な全音階、文化的認知度。
153
+
154
+
\begin{card}
155
+
\cardtitle{ペンタトニック（5音）}
156
+
\begin{tabularx}{\linewidth}{Xll}
157
+
\toprule
158
+
\textbf{曲} & \textbf{起源} & \textbf{音域} \\
159
+
\midrule
160
+
Amazing Grace & アメリカ & P5+oct \\
161
+
Auld Lang Syne & スコットランド & oct \\
162
+
Arirang & 韓国 & oct \\
163
+
Sakura & 日本 & m7 \\
164
+
Mo Li Hua（茉莉花） & 中国 & oct \\
165
+
Swing Low & 霊歌 & oct \\
166
+
\bottomrule
167
+
\end{tabularx}
168
+
\end{card}
169
+
170
+
\begin{card}
171
+
\cardtitle{狭い音域（1オクターブ未満）}
172
+
\begin{tabularx}{\linewidth}{Xll}
173
+
\toprule
174
+
\textbf{曲} & \textbf{起源} & \textbf{音域} \\
175
+
\midrule
176
+
Mary Had a Little Lamb & アメリカ & P5 \\
177
+
Hot Cross Buns & イギリス & M3 \\
178
+
Fr\`ere Jacques & フランス & M6 \\
179
+
London Bridge & イギリス & P5 \\
180
+
Korobeiniki & ロシア & oct \\
181
+
\bottomrule
182
+
\end{tabularx}
183
+
\end{card}
184
+
185
+
\begin{card}
186
+
\cardtitle{旋法と全音階}
187
+
\begin{tabularx}{\linewidth}{Xll}
188
+
\toprule
189
+
\textbf{曲} & \textbf{起源} & \textbf{音域} \\
190
+
\midrule
191
+
Greensleeves & イギリス & 10th \\
192
+
Scarborough Fair & イギリス & oct \\
193
+
Danny Boy & アイルランド & 10th \\
194
+
Shenandoah & アメリカ & 10th \\
195
+
Hava Nagila & イスラエル & oct \\
196
+
\bottomrule
197
+
\end{tabularx}
198
+
\end{card}
199
+
200
+
% ============================================================
201
+
% SECTION 5: FOLK PROCESS AS VERSION CONTROL
202
+
% ============================================================
203
+
\section{民謡プロセスとしてのバージョン管理}
204
+
205
+
国際民俗音楽評議会は、民謡プロセスの3つの特性を特定した：\emph{連続性}（現在と過去を結ぶ）、\emph{変異}（個々の演奏者の創造的衝動）、そして\emph{選択}（コミュニティがどの形態が存続するかを決定する）~\citep{karpeles1955definition}。
206
+
207
+
\begin{accentcard}
208
+
これらはソフトウェアのバージョン管理に直接対応する：
209
+
210
+
\vspace{0.3em}
211
+
\begin{tabularx}{\linewidth}{lX}
212
+
\textbf{連続性} & \texttt{main} ブランチ \\
213
+
\textbf{変異} & コミット、フォーク \\
214
+
\textbf{選択} & マージ判断、採用 \\
215
+
\end{tabularx}
216
+
\end{accentcard}
217
+
218
+
\np{} の曲エンコーディングはURLである。曲を共有することはリンクを共有すること。曲を改変することはテキスト文字列を編集して新しいリンクを共有すること。「口承伝統」はURLの伝統になる——旋律は記憶ではなくハイパーテキストを通じて伝播する。
219
+
220
+
これは比喩ではない。Essen関連コード（ESAC）データベースは1982年に始まり、中国の\textit{数字譜}に着想を得たコンピュータフレンドリーな記譜法で約8,000のヨーロッパおよび中国の民謡を符号化した~\citep{schaffrath1995esac}。\np{} の \texttt{NOTE:word} フォーマットはこの伝統の直接的な子孫である：旋律をテキストとして符号化し、計算と伝達を可能にする。
221
+
222
+
% ============================================================
223
+
% SECTION 6: COMPUTATIONAL MUSICOLOGY
224
+
% ============================================================
225
+
\section{計算的側面}
226
+
227
+
Passmoreらは民謡旋律を12音「アルファベット」からの進化的シーケンスとしてモデル化し、分子遺伝学から借用した配列アラインメント手法を10,062の日本とイギリスの旋律に適用した~\citep{passmore2023cultural}。彼らは、旋律への影響が小さい音の変化がより存続しやすいことを発見した——民謡が知られる簡潔さを好む選択圧力である。
228
+
229
+
\begin{card}
230
+
\cardtitle{これが \np{} にとって意味すること}
231
+
232
+
民謡旋律が簡潔さに向かう進化的選択圧力を受けているなら、それらは制約のあるインターフェースで演奏可能にする特性に\emph{収斂}しつつある。QWERTYキーボードはピアノの劣った代替品ではない——民謡プロセスがすでに課している制約に一致する制約なのである。
233
+
\end{card}
234
+
235
+
Lomaxの歌唱計量学プロジェクトは1,026の社会からの5,776曲について37の演奏スタイルの側面を符号化し、演奏スタイル（旋律内容ではなく）が主要な文化的指標であることを発見した~\citep{lomax1968folk}。これは \np{} が音高を符号化しリズムを符号化しないという設計判断を支持する：文化的に意味のある変異は音符が\emph{いかに}演奏されるかに生じ、それはまさに演奏者が制御するものである。
236
+
237
+
% ============================================================
238
+
% SECTION 7: RELATED INSTRUMENTS
239
+
% ============================================================
240
+
\section{関連する楽器}
241
+
242
+
\begin{card}
243
+
\cardtitle{aQWERTYon}
244
+
NYU Music Experience Design Labは、QWERTYキーを音階度数にマッピングするブラウザ楽器aQWERTYonを構築し、「間違った音がない」演奏を可能にした~\citep{hein2017aqwertyon}。\np{} は2つの点で異なる：\emph{半音階}マッピングを使用し（間違った音があり得、それには教育的価値がある）、音符を歌詞とペアリングする（曲が自らを教える）。
245
+
\end{card}
246
+
247
+
\begin{card}
248
+
\cardtitle{ABC記譜法}
249
+
ABC記譜法は民俗音楽エンコーディングのデファクトスタンダードであり、旋律をテキストで表現する~\citep{walshaw2011abc}。\texttt{abcjs}ライブラリはABCをブラウザ上のインタラクティブな楽譜にレンダリングする。\np{} のエンコーディングはより単純である——音価なし、小節線なし——なぜなら記譜システムではなく\emph{演奏スクリプト}だから：演奏者にどのキーを押すかを伝え、音楽がどう見えるかは伝えない。
250
+
\end{card}
251
+
252
+
\begin{card}
253
+
\cardtitle{Tunepal}
254
+
「演奏によるクエリ」方式で音楽家を13,290のアイルランド伝統曲に接続する音楽情報検索システム~\citep{duggan2009tunepal}。Tunepalは曲を見つけ、\np{} はそれを教える。両者は相補的である。
255
+
\end{card}
256
+
257
+
% ============================================================
258
+
% SECTION 8: THE BARE-METAL FOLK INSTRUMENT
259
+
% ============================================================
260
+
\section{ベアメタルの民俗楽器}
261
+
262
+
\np{} はブラウザだけでなく、ベアメタルでも動作する——AC Native OS上でPID~1として起動する987行のQuickJS移植版として~\citep{scudder2026os}。ベアメタルで \np{} を実行するノートパソコンは、文字通りの意味で民俗楽器である：曲を演奏するための単機能デバイスであり、オペレーティングシステムもデスクトップも邪魔もない。
263
+
264
+
\begin{accentcard}
265
+
融合は完了している：最も単純な利用可能な楽器で演奏されるよう設計された民謡が、最も単純なコンピュータ上で動作する——Linuxカーネル、フレームバッファ、そしてキーボード。
266
+
\end{accentcard}
267
+
268
+
% ============================================================
269
+
% SECTION 9: FUTURE WORK
270
+
% ============================================================
271
+
\section{今後の課題}
272
+
273
+
\begin{card}
274
+
\begin{itemize}
275
+
\item \textbf{クラウドソース・エンコーディング}：\texttt{NOTE:word} エンコーディングの公開リポジトリ。URLとして投稿され、民謡そのもののようにバージョン管理される。
276
+
\item \textbf{異文化コレクション}：Essen、Roud、Lomaxアーカイブの旋律を \np{} フォーマットにエンコードする。許諾を得て帰属を明記する。
277
+
\item \textbf{適応的難易度}：演奏者がより簡単な曲をマスターするにつれて音域を段階的に広げる——コダーイ式の民謡レパートリー漸進法。
278
+
\item \textbf{マルチプレイヤー・セッション}：2人の \np{} 演奏者が同じ曲を演奏する。1人がメロディー、もう1人がハーモニー——アイルランドの伝統的な意味でのデジタル「セッション」。
279
+
\item \textbf{録音と共有}：演奏をオーディオとしてキャプチャし、エンコーディングURLとペアにして公開する——記録された口承伝統。
280
+
\end{itemize}
281
+
\end{card}
282
+
283
+
% ============================================================
284
+
% CONCLUSION CARD
285
+
% ============================================================
286
+
\section{結論}
287
+
288
+
民謡は楽譜なし、録音なし、楽器なしで何世紀にもわたって存続してきた。存続したのは、記憶できるほど単純で、適応できるほど柔軟で、共有するに値するほど価値があったからである。
289
+
290
+
これらの曲を一音ずつ教えるブラウザキーボードは、民謡の伝統からの逸脱ではない。それ\emph{は}民謡の伝統であり——手元にある楽器に再び適応したのだ。
291
+
292
+
\vspace{0.5em}
293
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
294
+
295
+
\bibliographystyle{plainnat}
296
+
\bibliography{references}
297
+
298
+
\end{document}
+349
papers/arxiv-futures/futures-cards.tex
+349
papers/arxiv-futures/futures-cards.tex
···
1
+
% !TEX program = xelatex
2
+
% Cards format — auto-generated from futures.tex by cards-convert.mjs
3
+
\documentclass[11pt]{article}
4
+
5
+
\usepackage{fontspec}
6
+
\usepackage{unicode-math}
7
+
\setmainfont{Latin Modern Roman}
8
+
\setsansfont{Latin Modern Sans}
9
+
\setmonofont{Latin Modern Mono}[Scale=0.88]
10
+
11
+
12
+
\usepackage{graphicx}
13
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
14
+
\usepackage{booktabs}
15
+
\usepackage{tabularx}
16
+
\usepackage{ragged2e}
17
+
\usepackage{microtype}
18
+
\usepackage{natbib}
19
+
20
+
21
+
22
+
\makeatletter
23
+
\def\input@path{{../}}
24
+
\makeatother
25
+
\usepackage{ac-paper-cards}
26
+
27
+
% Extra commands from base paper
28
+
\newcommand{\acos}{\textsc{AC Native OS}}
29
+
30
+
\hypersetup{
31
+
pdftitle={Five Years from Now: What Aesthetic Computer Probably Becomes},
32
+
}
33
+
34
+
\renewcommand{\acpdfbase}{five-years-from-now-26-arxiv}
35
+
\begin{document}
36
+
37
+
% ============================================================
38
+
% TITLE CARD
39
+
% ============================================================
40
+
\thispagestyle{empty}
41
+
\vspace*{\fill}
42
+
\begin{center}
43
+
\includegraphics[height=9em]{pals}\par\vspace{0.1em}
44
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} Five Years from Now}\par
45
+
\vspace{0.1em}
46
+
{\fontsize{9pt}{11pt}\selectfont\color{acpink} What Aesthetic Computer Probably Becomes}\par
47
+
\vspace{0.4em}
48
+
{\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par
49
+
{\small\color{acgray} Aesthetic.Computer}\par
50
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
51
+
\vspace{0.4em}
52
+
\rule{0.5\textwidth}{0.5pt}\par
53
+
\vspace{0.15em}
54
+
\colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par
55
+
\vspace{0.1em}
56
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/2113ef735}{2113ef735}}\par
57
+
\vspace{0.1em}
58
+
{\footnotesize\color{acgray}\href{https://papers.aesthetic.computer/five-years-from-now-26-arxiv-da-cards.pdf}{Dansk} · \href{https://papers.aesthetic.computer/five-years-from-now-26-arxiv-es-cards.pdf}{Español} · \href{https://papers.aesthetic.computer/five-years-from-now-26-arxiv-zh-cards.pdf}{{\accjk 中文}} · \href{https://papers.aesthetic.computer/five-years-from-now-26-arxiv-ja-cards.pdf}{{\accjk 日本語}}}\par
59
+
\end{center}
60
+
\vspace*{\fill}
61
+
62
+
% ============================================================
63
+
% INDEX CARD
64
+
% ============================================================
65
+
\cardindex
66
+
67
+
% ============================================================
68
+
% BODY
69
+
% ============================================================
70
+
\section{Introduction}
71
+
72
+
\ac{} is a mobile-first runtime and social network for creative computing, comprising 359 built-in interactive programs (``pieces''), a bare-metal Linux operating system that boots any x86\_64 machine into a creative instrument, a minimal Lisp dialect for generative art, and a growing community of 2,812 registered users~\citep{scudder2026ac}. The project is authored and maintained primarily by a single developer, @jeffrey, with AI-assisted maintenance (``AestheticAnts'') handling routine upkeep.
73
+
74
+
As of March 2026, the project has produced 19 research papers across four languages, a bare-metal OS that boots in 7.3 seconds~\citep{scudder2026os}, a blockchain integration for minting generative artworks, and a 7,912-line musical instrument (\np{}) that has become the system's front door~\citep{scudder2026notepat}. The codebase traces its lineage through 94 predecessor projects spanning more than a decade of tool-making.
75
+
76
+
This paper does not propose what \ac{} \emph{should} do. It attempts to read what it \emph{probably will} do, based on the momentum already visible in the code, the papers, the infrastructure decisions, and the philosophical commitments that have shaped the project to date.
77
+
78
+
% ============ 2. NINETY-FOUR PROJECTS ============
79
+
80
+
\section{Ninety-Four Projects and Counting}
81
+
\label{sec:history}
82
+
83
+
Any projection of \ac{}'s future must reckon with the depth of its past. The project is not a startup pivoting toward product-market fit. It is the 95th iteration of a single sustained inquiry: \emph{what should a personal creative computing instrument be?}
84
+
85
+
\subsection{The Drawing Software Lineage (2011--2020)}
86
+
87
+
The archaeology paper~\citep{scudder2026archaeology} traces \ac{} through 94 predecessor projects spanning two GitHub accounts (50+ repositories), a 109\,GB legacy server archive, and a Dropbox corpus. The trajectory begins with \textbf{thePRBAT} (Polygon Replicating Bitmap Authoring Tool, 2011), a Flash-based digital imaging tool built as a BFA thesis at Ringling College, and arrives at \ac{} through a decade of drawing software variants: \textbf{JeffreyPaint} (2014, JavaScript + Unity), \textbf{Finger Quilt} (2016, iOS/Swift), \textbf{Dot} (2017, a plotting application that prefigures AC's \texttt{plot} disk), and most importantly \textbf{No Paint} (2014--2020), which went through five incarnations---Rails, JavaScript shim, WebGL prototype, iOS/Cordova, Vercel site---before being absorbed into \ac{}.
88
+
89
+
This is not a history of abandoned projects. It is a history of \emph{restarts}: the same person, asking the same question, choosing to start over rather than accumulate features. The pattern is visible in \ac{} itself: the piece model (single file, lifecycle functions, immediate-mode graphics) is a constraint-first design that \emph{prevents} the feature accumulation that killed earlier iterations.
90
+
91
+
\subsection{The Performance Turn (2016--2018)}
92
+
93
+
Between 2016 and 2018, @jeffrey toured with Goodiepal \& Pals across 65+ venues in Europe, building real-time performance tools: audience participation interfaces, music notation renderers, subtitle displays for live lectures. These tools---built fast, used once, thrown away---established a design principle that persists in \ac{}: software as instrument, not as product. The tools were played, not shipped.
94
+
95
+
The Goodiepal influence runs deeper than collaboration. The goodiepal paper~\citep{scudder2026goodiepal} identifies five threads that carry through to \ac{}: instrument-first design, community organized through affinity rather than institution, works designed to resist digital reproduction, and radical pedagogy through direct engagement rather than curriculum.
96
+
97
+
\subsection{Why History Matters for Projection}
98
+
99
+
The 94-project history constrains our projection in two ways. First, it makes sudden pivots unlikely. @jeffrey has been circling the same problems---personal tools, creative instruments, constraint-based design---for 15 years. The next 5 years will almost certainly stay within this orbit. Second, it makes abandonment unlikely for the reasons people usually abandon projects (boredom, loss of interest, attraction to something shinier). The risk is not distraction; it is exhaustion. We return to this in \S\ref{sec:giveup}.
100
+
101
+
% ============ 3. THE SURPLUS HARDWARE WAVE ============
102
+
103
+
\section{The Surplus Hardware Wave}
104
+
\label{sec:surplus}
105
+
106
+
The single largest force acting on \ac{}'s future is external: in October 2025, Microsoft ended support for Windows 10, rendering an estimated 240 million PCs obsolete by institutional standards~\citep{ewaste2024monitor}. These machines are not broken. They are ThinkPads, EliteBooks, and Latitudes with 8--16\,GB RAM, 1080p screens, WiFi, and 6--10 hour batteries. They cost \$30--80 on the surplus market. They are the raw material for everything that follows.
107
+
108
+
\subsection{From Prototype to Fleet (2026--2027)}
109
+
110
+
\acos{} already boots on surplus hardware~\citep{scudder2026os}. The gap between ``boots on two ThinkPads in @jeffrey's apartment'' and ``boots on 30 machines in a classroom'' is not primarily technical. It is operational: WiFi credential management, per-device identity provisioning, hardware compatibility testing across dozens of laptop models, and a flashing workflow that a non-technical person can execute.
111
+
112
+
The likely near-term work is mundane but critical:
113
+
114
+
\begin{itemize}
115
+
\item \textbf{Per-user WiFi storage}: moving hardcoded SSIDs out of JavaScript pieces into persistent per-device config files that survive OTA updates
116
+
\item \textbf{Hardware compatibility matrix}: systematic testing across ThinkPad X1/T/L series, HP EliteBook 800 series, Dell Latitude 5000/7000 series
117
+
\item \textbf{One-command flashing}: a USB image builder that takes a handle, colors, and WiFi credentials and produces a bootable drive
118
+
\item \textbf{A/B kernel slots}: dual-partition boot with automatic rollback if the new kernel fails health checks
119
+
\end{itemize}
120
+
121
+
These are not glamorous features. They are the difference between an art project and an infrastructure project. The trajectory of the codebase---OTA updates already working, build names already generated, device identity already inscribed in the boot partition---suggests that @jeffrey understands this distinction and is moving toward the infrastructure side.
122
+
123
+
\subsection{The 50-Dollar Instrument (2027--2028)}
124
+
125
+
If the operational work lands, the economic argument becomes very loud: a complete creative computing instrument---personalized, self-updating, requiring zero IT infrastructure---for the price of a surplus laptop and a USB drive. No Chromebook enrollment. No Apple ID. No subscription.
126
+
127
+
The OLPC project~\citep{kraemer2009olpc} demonstrated that hardware-first approaches to computing access fail on cost and logistics. The Raspberry Pi addressed cost (\$35) but requires \$150 in accessories. \ac{}'s proposition is different: the hardware already exists, already has a screen, keyboard, battery, and WiFi, and is being discarded by the millions. The software is 89\,MB.
128
+
129
+
The likely outcome by 2028 is not mass adoption but \emph{proof points}: a handful of classrooms, community centers, or workshop contexts where fleets of 10--30 surplus machines run \acos{} and the results are documented. These proof points become the evidence base for grant applications, institutional partnerships, and the sustainability arguments described in \S\ref{sec:sustainability}.
130
+
131
+
% ============ 3. PLANETARY ENSEMBLES ============
132
+
133
+
\section{Planetary Ensembles}
134
+
\label{sec:ensembles}
135
+
136
+
The PLOrk paper~\citep{scudder2026plork} makes an argument that the existing codebase already supports: laptop orchestras have been musically legitimate since Princeton's PLOrk proved the concept in 2006~\citep{trueman2006plork}, but the model is trapped in universities at \$1,500+ per seat. \acos{} on surplus hardware reduces the cost to \$50/seat. The question is whether anyone will play.
137
+
138
+
\subsection{notepat as Ensemble Instrument (2026--2027)}
139
+
140
+
\np{} is already a polyphonic keyboard instrument with 32-voice synthesis, room reverb, and wave-type selection~\citep{scudder2026notepat}. It runs on bare metal at 192\,kHz. The missing ingredient for ensemble performance is not audio quality but \emph{coordination}: synchronized tempo, shared harmonic space, and a conductor interface.
141
+
142
+
The likely development path:
143
+
144
+
\begin{itemize}
145
+
\item \textbf{UDP ensemble sync}: extending the existing dual-channel networking (WebSocket + UDP) to synchronize beat clocks across devices on a local network
146
+
\item \textbf{Conductor piece}: a new piece that displays the ensemble state and allows a conductor to set tempo, key, and dynamics
147
+
\item \textbf{Spatialization}: using the physical positions of surplus laptops as distributed speakers---the ensemble \emph{is} the sound system, following Turino's participatory music model~\citep{turino2008music}
148
+
\end{itemize}
149
+
150
+
This thread has obvious conference appeal. A live demonstration of 10 surplus ThinkPads playing a coordinated musical piece---each showing the player's handle in rainbow text, each contributing a voice to a distributed sound field---is the kind of demo that wins Ars Electronica mentions and NIME submissions.
151
+
152
+
\subsection{Beyond Music (2028--2031)}
153
+
154
+
The ensemble model generalizes beyond music. A network of surplus machines running coordinated pieces could be:
155
+
156
+
\begin{itemize}
157
+
\item A \textbf{distributed drawing wall}: each screen shows a section of a larger canvas, participants draw locally, and the network composites the result
158
+
\item A \textbf{collaborative KidLisp environment}: students write generative programs that feed into a shared visual space
159
+
\item A \textbf{performance score}: the machines execute a graphic score~\citep{scudder2026pieces}, each interpreting the same notation through different pieces
160
+
\end{itemize}
161
+
162
+
The infrastructure for all of these already exists: WebSocket relay, UDP broadcast, per-device identity, and a piece model that supports any combination of graphics, audio, and input. What's missing is the \emph{choreography}---the pieces themselves and the social forms around them.
163
+
164
+
% ============ THE THIRD DIMENSION ============
165
+
166
+
\section{The Third Dimension}
167
+
\label{sec:3d}
168
+
169
+
\ac{} is widely perceived as a 2D system. The immediate-mode graphics API---\texttt{wipe}, \texttt{ink}, \texttt{line}, \texttt{box}---and the pixel-art aesthetic of most pieces reinforce this impression. But the infrastructure tells a different story. A full software 3D rasterizer already exists, a multiplayer FPS already ships, and the architectural choices made in the bare-metal OS position 3D as the next major expressive frontier.
170
+
171
+
\subsection{What Already Works}
172
+
173
+
The bare-metal OS includes \texttt{graph3d.c}, a ~600-line CPU software rasterizer with perspective projection, frustum clipping (Sutherland-Hodgman against 6 clip planes), depth buffering, per-vertex color interpolation, and texture mapping with perspective-correct barycentric coordinates. The JavaScript API exposes this through a \texttt{Form} constructor: pieces create meshes with vertex positions, colors, and texture coordinates, then render them with \texttt{ink(r,g,b).form(mesh)}.
174
+
175
+
Two production pieces demonstrate the system. \texttt{fps.mjs} provides a first-person camera with pointer lock, WASD movement, textured ground planes, and rotating cubes. \texttt{1v1.mjs} extends this into a multiplayer FPS with hitscan weapons, bot AI (patrol/chase/flee states), kill tracking, and the dual-channel networking pattern (WebSocket for reliable game events, UDP for low-latency position sync). The browser path uses Three.js (r0.182) with WebGL rendering and includes VR/XR session support~\citep{sutherland1968head}.
176
+
177
+
The system thus has two parallel 3D paths: a software rasterizer on bare metal (CPU-only, no GPU) and a hardware-accelerated path in the browser (WebGL/Three.js, with WebGPU infrastructure in place). The API surface is identical from the piece author's perspective.
178
+
179
+
\subsection{The GPU Question on Bare Metal (2026--2028)}
180
+
181
+
The software rasterizer is elegant but fundamentally limited. Every surplus ThinkPad and EliteBook in the target fleet has an Intel integrated GPU capable of OpenGL 4.x or Vulkan 1.x, sitting idle. The kernel's DRM subsystem already manages the display via KMS modesetting; extending it to expose a render node for GPU-accelerated rasterization is a known engineering path (EGL on DRM, or Vulkan via \texttt{/dev/dri/renderD128}).
182
+
183
+
The likely trajectory is cautious. @jeffrey's design instinct favors software control over hardware delegation---the entire bare-metal OS philosophy is ``know every instruction between power-on and pixel.'' GPU drivers introduce opacity: firmware blobs, driver bugs, vendor-specific behavior. The software rasterizer's virtue is that it is \emph{legible}: the pipeline from vertex to pixel is 600 lines of C that a student can read.
184
+
185
+
The probable compromise: GPU acceleration as an opt-in path for pieces that need it, with the software rasterizer remaining the default and the reference implementation. This mirrors the browser architecture, where WebGPU exists alongside the 2D canvas but doesn't replace it.
186
+
187
+
\subsection{3D as Creative Medium (2028--2031)}
188
+
189
+
The more interesting question is not technical but expressive. What does 3D mean in a system designed around constraint, immediacy, and single-file pieces?
190
+
191
+
The predecessor projects offer a clue. @jeffrey's work has always been about \emph{painting}: No Paint, JeffreyPaint, thePRBAT, the Radical Digital Painting lecture tour. The 3D infrastructure is not building toward a game engine or a CAD tool. It is building toward \emph{spatial painting}---the ability to place marks, colors, and forms in three-dimensional space with the same immediacy that \texttt{ink(255,0,0).line(0,0,100,100)} provides in two dimensions.
192
+
193
+
The pieces that will matter are not the ones that look like Unity demos. They are the ones where 3D is used the way @jeffrey uses 2D: as raw material for instruments, for performances, for things that are played rather than consumed. A 3D \np{} where notes have spatial position and the room reverb is literal---sound emanating from forms distributed in virtual space. A 3D KidLisp where \texttt{(box 0 0 0 50 50 50)} places a cube the way \texttt{(rect 0 0 50 50)} places a rectangle. A fleet of surplus laptops each rendering a different camera angle of the same distributed 3D scene.
194
+
195
+
The convergence with ensembles (\S\ref{sec:ensembles}) is where 3D becomes genuinely new. Synchronized 3D scenes across networked surplus machines---each screen a window into a shared virtual space, each player's input affecting the scene for all participants---is a form that neither game engines nor creative coding tools have explored at the \$50/seat price point. The networking is already proven (\texttt{1v1.mjs}). The hardware is already available (\S\ref{sec:surplus}). The missing piece is the artistic vision for what a distributed spatial instrument should feel like, and that is precisely the kind of question @jeffrey has spent 94 projects learning how to answer.
196
+
197
+
% ============ 5. THE SCHOLARLY TURN ============
198
+
199
+
\section{The Scholarly Turn}
200
+
\label{sec:scholarly}
201
+
202
+
Between March 3 and March 20, 2026, @jeffrey produced 19 research papers in four languages. This is not normal behavior for a solo developer. It signals a deliberate turn toward scholarly legitimacy---an attempt to build what the RESEARCH-DIRECTION.md file calls a ``research moat'' around the project.
203
+
204
+
\subsection{The Paper Mill (2026--2027)}
205
+
206
+
The paper infrastructure is already industrial: a custom \LaTeX{} template with AC fonts, automated PDF building via a server (``the oven''), a cards format for single-sheet printouts, and a translation pipeline producing Danish, Spanish, and Chinese editions of every paper. The 40+ readings library provides the citation base. The pipeline is designed to produce, not to prototype.
207
+
208
+
The near-term trajectory is submission: ACM C\&C Demos (April 16), ICCC Short Papers (April 24), JOSS software papers (rolling). If any of these land, the project gains a scholarly foothold that most creative coding tools never achieve. Processing~\citep{reas2007processing} and Scratch~\citep{resnick2009scratch} built their academic legitimacy over years; @jeffrey is attempting to compress that timeline by producing volume and targeting multiple venues simultaneously.
209
+
210
+
\subsection{Artist-Scholar Identity (2028--2031)}
211
+
212
+
The CalArts paper argues that an art school is an operating system---that the structures of proximity, critique, and disciplinary contamination that characterize institutions like CalArts can be ported into software. If @jeffrey continues to publish at this rate, the papers themselves become a body of work: not documentation of a software project, but a sustained argument about what creative computing is and who it is for.
213
+
214
+
The likely 5-year outcome is one of two scenarios:
215
+
216
+
\begin{enumerate}
217
+
\item \textbf{The moat holds}: 6--10 papers are published across peer-reviewed venues, @jeffrey is invited to speak at conferences, and \ac{} enters the canon alongside Processing, Scratch, and Sonic Pi~\citep{aaron2016sonic} as a recognized creative computing environment. The papers create a feedback loop: scholarly attention brings users, users create pieces, pieces generate new papers.
218
+
\item \textbf{The moat doesn't hold}: submissions are rejected, the solo-author pattern raises reviewer eyebrows, and the paper infrastructure goes dormant. The code survives; the scholarly identity does not. This is the more common outcome for artist-programmers.
219
+
\end{enumerate}
220
+
221
+
The honest bet is somewhere between: a few publications land, enough to establish credibility in niche venues (NIME, xCoAx, ICLC), but the mainstream HCI and PL conferences remain out of reach without collaborators and user studies.
222
+
223
+
% ============ 5. KIDLISP'S OWN LIFE ============
224
+
225
+
\section{KidLisp's Own Life}
226
+
\label{sec:kidlisp}
227
+
228
+
KidLisp is a 118-function Lisp dialect for generative art~\citep{scudder2026kidlisp}. It is sandboxed (no file I/O, no networking), runs in the browser, and has already accumulated 16,779 stored programs and a blockchain minting integration via Tezos. The language is small enough to fit on an index card.
229
+
230
+
\subsection{Language Community (2026--2028)}
231
+
232
+
The Tezos ``keeps'' system---where KidLisp programs are minted as on-chain artworks for 2.5 XTZ---creates an economic incentive to write KidLisp. The keeps contract (v11) is live, the minting UI exists at keeps.kidlisp.com, and 5 tokens have already been minted and migrated. If the generative art market remains active, this thread sustains itself.
233
+
234
+
The more interesting possibility is pedagogical. KidLisp's constraints---no state mutation, no side effects beyond drawing, 118 functions, runs in a browser---make it a candidate for teaching environments. A KidLisp curriculum built around the cards format (single-sheet programs that students can hold in their hands) aligns with Papert's constructionism~\citep{papert1980mindstorms} and the project's existing infrastructure.
235
+
236
+
\subsection{Language Evolution (2028--2031)}
237
+
238
+
KidLisp will face pressure to grow. Users will want state, animation, interactivity, sound. The design question is whether the language absorbs these features (becoming a general-purpose creative language) or remains deliberately minimal (a ``haiku language'' for static generative art, with JavaScript handling everything else).
239
+
240
+
The project's history suggests the latter. @jeffrey's design instinct, visible across 94 predecessor projects, favors sharp constraints over feature accumulation. The piece model itself---single file, lifecycle functions, immediate-mode graphics~\citep{scudder2026pieces}---is a constraint-first design. KidLisp will probably stay small. The interesting growth will be in what people make with it, not what the language adds.
241
+
242
+
% ============ 6. SUSTAINABILITY ============
243
+
244
+
\section{The Sustainability Question}
245
+
\label{sec:sustainability}
246
+
247
+
Every thread described above depends on a single person continuing to work. \ac{} has no venture funding, no institutional backing, and no employees beyond @jeffrey. The AestheticAnts maintenance system automates routine tasks, but architectural decisions, paper writing, hardware testing, and community cultivation require human attention.
248
+
249
+
\subsection{The Funding Landscape (2026--2028)}
250
+
251
+
The project has identified funding sources: Creative Capital (\$50,000 project grants), Prix Ars Electronica (\texteuro10,000), Gary Marsden Travel Awards, and GitHub Sponsors. The paper mill is partly a grant-writing strategy: a project with 19 papers, conference demos, and a documented user base is a stronger applicant than one with only code.
252
+
253
+
The Tezos keeps provide a small revenue stream. Prints (20 ordered as of March 2026) provide another. Neither is sufficient to sustain full-time development.
254
+
255
+
The honest projection: by 2028, the project either secures a grant or institutional affiliation (a residency, a teaching position, a research fellowship) or it slows to maintenance-mode development. This is not a failure scenario---many important creative tools are maintained part-time by their creators for decades. But the ambitious threads (planetary ensembles, surplus hardware fleets, scholarly moat) require full-time attention.
256
+
257
+
\subsection{The Solo-Author Risk (2028--2031)}
258
+
259
+
Illich's ``tools for conviviality''~\citep{illich1973tools} argues that good tools should be operable without specialized expertise. \ac{} aspires to this for its users, but the project itself is not convivial in Illich's sense: it requires @jeffrey's expertise to maintain. The bus factor is one.
260
+
261
+
The mitigation is already partially in place: the codebase is open source, the architecture is documented in 19 papers, the piece API is designed for single-file simplicity, and the AestheticAnts system handles routine maintenance autonomously. But the difference between ``the code is open'' and ``someone else can lead the project'' is vast.
262
+
263
+
The likely 5-year trajectory: @jeffrey remains the sole architect. A small community of piece authors contributes content (265 published pieces and growing). One or two contributors submit pull requests for specific features. The project does not achieve the ``thousand contributors'' model of Processing or p5.js, but it doesn't need to---its value proposition is not breadth but depth: a single vision, rigorously maintained, that takes creative computing to places committee-designed tools cannot go.
264
+
265
+
% ============ 7. THE CONVERGENCE ============
266
+
267
+
\section{The Convergence}
268
+
\label{sec:convergence}
269
+
270
+
The seven threads described above are not parallel tracks. They converge.
271
+
272
+
The 94-project history (\S\ref{sec:history}) establishes the trajectory that makes the other threads legible. Surplus hardware (\S\ref{sec:surplus}) provides the material base for planetary ensembles (\S\ref{sec:ensembles}). The 3D infrastructure (\S\ref{sec:3d}) extends the ensemble model into spatial performance. The papers (\S\ref{sec:scholarly}) document and legitimize all of it. KidLisp (\S\ref{sec:kidlisp}) provides a safe entry point for new users who arrive through any of these channels. Sustainability (\S\ref{sec:sustainability}) determines whether the convergence happens at all---and \S\ref{sec:giveup} examines what happens if it doesn't.
273
+
274
+
The most likely 5-year scenario is this: by 2031, \ac{} is a recognized but niche creative computing environment with:
275
+
276
+
\begin{itemize}
277
+
\item \textbf{5,000--10,000 registered users}, up from 2,812, driven by notepat virality, conference demos, and classroom deployments
278
+
\item \textbf{A bare-metal OS} deployed on 100--500 surplus machines across 5--15 sites (schools, community centers, artist residencies, workshops)
279
+
\item \textbf{3--5 published papers} in peer-reviewed venues, establishing a minimal scholarly footprint
280
+
\item \textbf{50,000+ KidLisp programs}, with a small but active generative art community minting keeps on Tezos
281
+
\item \textbf{Ensemble performances} at 2--3 festivals or conferences, using fleets of surplus laptops as distributed instruments
282
+
\item \textbf{A single maintainer} still writing most of the code, with AI-assisted maintenance handling an increasing share of routine work
283
+
\end{itemize}
284
+
285
+
This is not the most ambitious outcome, nor the most conservative. It is the outcome consistent with a project that has made specific, deliberate choices about what it cares about---depth over breadth, instruments over IDEs, maintenance over disruption---and that has the infrastructure to follow through on those choices at the pace a solo developer can sustain.
286
+
287
+
% ============ 8. WHAT COULD CHANGE EVERYTHING ============
288
+
289
+
\section{What Could Change Everything}
290
+
\label{sec:wildcards}
291
+
292
+
Projections based on momentum are reliable precisely because they ignore discontinuities. Four wildcards could alter the trajectory entirely:
293
+
294
+
\subsection{An Institutional Home}
295
+
296
+
If @jeffrey takes a teaching position at an art school or research university, \ac{} gains something it currently lacks: students. A cohort of 15--30 students using \ac{} as their primary creative computing environment for a semester would produce more pieces, more bug reports, more use cases, and more scholarship than a decade of solo development. The CalArts paper's argument---that art school is an operating system---works in reverse: the operating system could become a school.
297
+
298
+
\subsection{A Viral Moment}
299
+
300
+
\np{} was posted to Hacker News and received attention. A second viral moment---a TikTok of a classroom full of surplus laptops playing music together, a tweet thread about the \$50 creative instrument, a conference demo that gets filmed and shared---could bring thousands of users in a week. The infrastructure (URL-addressable pieces, instant registration, social features) is designed to absorb this. Whether @jeffrey \emph{wants} to absorb it is a separate question. The project's anti-platform stance~\citep{fisher2009capitalist} suggests ambivalence about growth-for-growth's-sake.
301
+
302
+
\subsection{AI as Collaborator}
303
+
304
+
The AestheticAnts system already uses AI for routine maintenance. The agent memory system logs interactions and maintains continuity across conversations. If AI capabilities continue to advance, a future version of this system could do more than maintenance: it could write pieces, generate KidLisp programs, compose ensemble scores, and draft papers. The solo-author risk (\S\ref{sec:sustainability}) diminishes if the ``solo author'' is augmented by an AI collaborator that understands the project's history, philosophy, and codebase.
305
+
306
+
This is not speculative in the way the other scenarios are. It is already happening. The question is one of degree: by 2031, does AI handle 10\% of the creative work, or 50\%? The answer will depend on choices @jeffrey makes about what he delegates and what he insists on doing himself. The project's emphasis on personal voice, on the ``PSYCHO'' papers that bear the author's temperature, suggests that the most important work will remain human. The infrastructure around it may not.
307
+
308
+
\subsection{What If He Stops}
309
+
\label{sec:giveup}
310
+
311
+
The projections above assume continued effort. But the 94-project history (\S\ref{sec:history}) contains a pattern that must be named: @jeffrey has walked away from things before. No Paint had five incarnations. Each one was abandoned, not because the idea failed, but because the implementation calcified---because the gap between what the tool \emph{was} and what it \emph{should be} grew intolerable. The restarts were not failures of commitment. They were expressions of it.
312
+
313
+
The risk for \ac{} is not that @jeffrey loses interest. Fifteen years of circling the same problems rules out casual abandonment. The risk is \emph{structural exhaustion}: the accumulation of operational weight---server bills, user support, hardware testing, paper submissions, grant applications, dependency updates---until the maintenance load crowds out the creative work that makes the project worth maintaining. Ukeles~\citep{ukeles1969manifesto} argued that maintenance is art, but even Ukeles acknowledged that maintenance without recognition becomes invisible labor.
314
+
315
+
Three scenarios for cessation deserve consideration:
316
+
317
+
\begin{enumerate}
318
+
\item \textbf{The quiet fade}: development slows to sporadic commits, the servers stay up but the community drifts, and \ac{} joins the long list of ambitious personal tools that exist as archives rather than living systems. This is the most common outcome for solo-authored creative computing projects. It is not dramatic. It is the default.
319
+
320
+
\item \textbf{The deliberate stop}: @jeffrey declares the project complete at some natural boundary---perhaps when the OS boots reliably on a dozen laptop models, or when the paper count reaches a round number, or when the 100th piece is published by someone other than him. He returns to painting on canvas (the Venice Family Clinic exhibition in May 2026 suggests this thread is already active). The code remains open. Someone may fork it. Most likely, no one does.
321
+
322
+
\item \textbf{The 95th restart}: @jeffrey walks away from \ac{} to build its successor. This is the pattern the history predicts most strongly. No Paint became \ac{}. \ac{} could become something else---something that absorbs the lessons of the OS, the piece model, the ensemble networking, and the 3D rasterizer, but sheds the accumulated infrastructure weight. The new project starts clean, in a single file, and the cycle begins again. From the outside, this looks like failure. From inside the 94-project lineage, it looks like the process working exactly as designed.
323
+
\end{enumerate}
324
+
325
+
The honest assessment: scenario 3 is unlikely within 5 years because \ac{} has achieved escape velocity in ways No Paint never did---a registered user base, a bare-metal OS, a blockchain integration, 19 papers, a language with 16,000+ programs. The sunk cost is too high for a clean restart. But scenario 1 is entirely possible if the sustainability question (\S\ref{sec:sustainability}) goes unanswered. A project this ambitious, maintained by one person without stable funding, is always one bad year away from the quiet fade.
326
+
327
+
The mitigation is the same one that has sustained the project so far: making the work itself rewarding enough that the operational burden is tolerable. The papers, the performances, the 3D rasterizer written from scratch, the bare-metal boot that takes 7 seconds---these are not features on a roadmap. They are the creative practice. If the practice stops being interesting, the project stops. If it stays interesting, the project survives anything short of the lights going out.
328
+
329
+
% ============ 10. CONCLUSION ============
330
+
331
+
\section{Conclusion}
332
+
333
+
Aesthetic Computer is a project that knows what it is. It is not searching for product-market fit, pivoting toward enterprise, or optimizing for growth metrics. It is a personal creative computing instrument being built in public by a single person who has been making versions of it for more than a decade across 94 predecessor projects.
334
+
335
+
The next five years will be shaped by forces both internal (the pace @jeffrey can sustain, the funding he can secure) and external (240 million surplus PCs, the generative art economy, the academic conference cycle). The project's infrastructure---bare-metal OS, paper mill, piece model, social network, blockchain minting---is built to absorb these forces. Whether it will is a question of stamina, luck, and the willingness of the world to care about creative computing tools that are not owned by a platform.
336
+
337
+
Nelson wrote in 1974 that ``you can and must understand computers NOW''~\citep{nelson1974computerlib}. Illich wrote in 1973 that tools should expand personal autonomy, not require institutional mediation~\citep{illich1973tools}. Ukeles wrote in 1969 that maintenance is art~\citep{ukeles1969manifesto}. \ac{} is the synthesis: a tool that is personal, convivial, and maintained as a creative practice. The bet is that this synthesis, applied to surplus hardware and sustained over time, creates something that lasts.
338
+
339
+
Whether it does is the only interesting question. This paper offers no answer, only a reading of the forces in play. The code will decide.
340
+
341
+
\vspace{0.5em}
342
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
343
+
344
+
% ============ REFERENCES ============
345
+
346
+
\bibliographystyle{plainnat}
347
+
\bibliography{references}
348
+
349
+
\end{document}
+429
papers/arxiv-futures/futures-ja.tex
+429
papers/arxiv-futures/futures-ja.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
\usepackage{xeCJK}
11
+
\setCJKmainfont{Droid Sans Japanese}
12
+
13
+
\setmainfont{Latin Modern Roman}
14
+
\setsansfont{Latin Modern Sans}
15
+
16
+
% Custom AC fonts
17
+
\newfontfamily\acbold{ywft-processing-bold}[
18
+
Path=../../system/public/type/webfonts/,
19
+
Extension=.ttf
20
+
]
21
+
\newfontfamily\aclight{ywft-processing-light}[
22
+
Path=../../system/public/type/webfonts/,
23
+
Extension=.ttf
24
+
]
25
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
26
+
27
+
% === PACKAGES ===
28
+
\usepackage{xcolor}
29
+
\usepackage{titlesec}
30
+
\usepackage{enumitem}
31
+
\usepackage{booktabs}
32
+
\usepackage{tabularx}
33
+
\usepackage{fancyhdr}
34
+
\usepackage{hyperref}
35
+
\usepackage{graphicx}
36
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
37
+
\usepackage{ragged2e}
38
+
\usepackage{microtype}
39
+
\usepackage{natbib}
40
+
\usepackage[colorspec=0.92]{draftwatermark}
41
+
42
+
% === COLORS (AC palette) ===
43
+
\definecolor{acpink}{RGB}{180,72,135}
44
+
\definecolor{acpurple}{RGB}{120,80,180}
45
+
\definecolor{acdark}{RGB}{64,56,74}
46
+
\definecolor{acgray}{RGB}{119,119,119}
47
+
\definecolor{draftcolor}{RGB}{180,72,135}
48
+
49
+
% === DRAFT WATERMARK ===
50
+
\DraftwatermarkOptions{
51
+
text=WORKING DRAFT,
52
+
fontsize=3cm,
53
+
color=draftcolor!18,
54
+
angle=45,
55
+
pos={0.5\paperwidth, 0.5\paperheight}
56
+
}
57
+
58
+
% === HYPERREF ===
59
+
\hypersetup{
60
+
colorlinks=true,
61
+
linkcolor=acpurple,
62
+
urlcolor=acpurple,
63
+
citecolor=acpurple,
64
+
pdfauthor={@jeffrey},
65
+
pdftitle={5年後：Aesthetic Computerが何になりうるか},
66
+
}
67
+
68
+
% === SECTION FORMATTING ===
69
+
\titleformat{\section}
70
+
{\normalfont\bfseries\normalsize\uppercase}
71
+
{\thesection.}
72
+
{0.5em}
73
+
{}
74
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
75
+
76
+
\titleformat{\subsection}
77
+
{\normalfont\bfseries\small}
78
+
{\thesubsection}
79
+
{0.5em}
80
+
{}
81
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
82
+
83
+
% === HEADER/FOOTER ===
84
+
\pagestyle{fancy}
85
+
\fancyhf{}
86
+
\renewcommand{\headrulewidth}{0pt}
87
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{作業草稿 --- 引用不可}}
88
+
\fancyfoot[C]{\footnotesize\thepage}
89
+
90
+
% === CUSTOM COMMANDS ===
91
+
\newcommand{\ac}{\textsc{Aesthetic Computer}}
92
+
\newcommand{\acos}{\textsc{AC Native OS}}
93
+
\newcommand{\np}{\textsc{notepat}}
94
+
95
+
% === LIST SETTINGS ===
96
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
97
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
98
+
99
+
% === COLUMN SEPARATION ===
100
+
\setlength{\columnsep}{1.8em}
101
+
102
+
% === PARAGRAPH SETTINGS ===
103
+
\setlength{\parindent}{1em}
104
+
\setlength{\parskip}{0.3em}
105
+
106
+
% Hyphenation for narrow two-column layout
107
+
\tolerance=800
108
+
\emergencystretch=1em
109
+
\hyphenpenalty=50
110
+
111
+
\begin{document}
112
+
113
+
% ============ TITLE BLOCK ============
114
+
115
+
\twocolumn[{%
116
+
\begin{center}
117
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
118
+
{\acbold\fontsize{22pt}{26pt}\selectfont\color{acdark} 5年後}\par
119
+
\vspace{0.2em}
120
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} Aesthetic Computer が何になりうるか}\par
121
+
\vspace{0.3em}
122
+
{\aclight\fontsize{9pt}{11pt}\selectfont\color{acgray} 余剰ハードウェア、空間楽器、パーソナルツールの長期的賭け}\par
123
+
\vspace{0.6em}
124
+
{\normalsize @jeffrey}\par
125
+
{\small\color{acgray} Aesthetic.Computer}\par
126
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
127
+
\vspace{0.3em}
128
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
129
+
\vspace{0.6em}
130
+
\rule{\textwidth}{1.5pt}
131
+
\vspace{0.5em}
132
+
\end{center}
133
+
134
+
\begin{center}
135
+
{\small\color{acpink}\textbf{[ 作業草稿 --- 引用不可 ]}}
136
+
\end{center}
137
+
\vspace{0.3em}
138
+
139
+
\begin{quote}
140
+
\small\noindent\textbf{要旨。}
141
+
本論文は、プロジェクトの現在の軌道、既存のインフラ、明示された野望、そしてそれに作用する経済的・文化的・物質的な力に基づいて、\ac{}の今後5年間（2026--2031）の方向性を推定する。プロジェクトは7つの収束する軸に沿って進化する可能性があると主張する：(1)~94のプロジェクトからなる創作系譜の継続が、可能な未来の空間を制約する；(2)~\acos{}が余剰ハードウェアに大規模展開可能なツールとして成熟する；(3)~分散型ノートパソコン・アンサンブルが音楽的・教育的形態として出現する；(4)~3Dがソフトウェアラスタライザーから空間的創作メディアへと拡張する；(5)~継続的な論文生産を通じて学術的アイデンティティが深化する；(6)~KidLispが自立した創作言語コミュニティへと成長する；(7)~持続可能性の清算——プロジェクトが能動的または受動的に終了する可能性を含む——がそれ自身の野望の中で生き延びられるかを決定する。これはロードマップではない。モメンタムの解読であり——プロジェクトがすでに選択してきたことに基づいて、それが\emph{何になりたいのか}を問う試みである。
142
+
\end{quote}
143
+
\vspace{0.5em}
144
+
}]
145
+
146
+
% ============ 1. 序論 ============
147
+
148
+
\section{序論}
149
+
150
+
\ac{}はモバイルファーストのランタイムかつクリエイティブ・コンピューティングのソーシャルネットワークであり、359の内蔵インタラクティブプログラム（「ピース」）、任意のx86\_64マシンをクリエイティブツールとして起動するベアメタルLinux OS、ジェネラティブアート用のミニマルLisp方言、そして2,812名の登録ユーザーを持つ成長中のコミュニティを含む~\citep{scudder2026ac}。プロジェクトは主に単一の開発者@jeffreyによって作成・維持されており、AI支援メンテナンスシステム（「AestheticAnts」）が日常的な保守作業を処理する。
151
+
152
+
2026年3月時点で、プロジェクトは4言語で19本の研究論文、7.3秒で起動するベアメタルOS~\citep{scudder2026os}、ジェネラティブアート作品をミントするブロックチェーン統合、そしてシステムの入り口となった7,912行の楽器（\np{}）~\citep{scudder2026notepat}を生み出している。コードベースの系譜は10年以上のツール制作にまたがる94の先行プロジェクトに遡る。
153
+
154
+
本論文は\ac{}が\emph{何をすべきか}を提案しない。コード、論文、インフラの決定、そしてプロジェクトをここまで形作ってきた哲学的コミットメントにすでに見えているモメンタムに基づいて、それが\emph{何をしうるか}を解読しようとする。
155
+
156
+
% ============ 2. 94のプロジェクト ============
157
+
158
+
\section{94のプロジェクト、今も続く}
159
+
\label{sec:history}
160
+
161
+
\ac{}の未来に関するいかなる予測も、その過去の深さに向き合わなければならない。プロジェクトはプロダクト・マーケット・フィットを探すスタートアップではない。\emph{パーソナル・クリエイティブ・コンピューティングツールはどうあるべきか？}という継続的な探究の第95回目のイテレーションである。
162
+
163
+
\subsection{ドローイングソフトウェア系譜（2011--2020）}
164
+
165
+
考古学論文~\citep{scudder2026archaeology}は、2つのGitHubアカウント（50以上のリポジトリ）、109\,GBのレガシーサーバーアーカイブ、Dropboxコーパスにまたがる94の先行プロジェクトを通じて\ac{}を追跡する。軌跡は\textbf{thePRBAT}（Polygon Replicating Bitmap Authoring Tool、2011）——Ringling Collegeの学士論文として構築されたFlashベースのデジタル画像ツール——から始まり、10年のドローイングソフトウェア変種を経て\ac{}に至る：\textbf{JeffreyPaint}（2014、JavaScript + Unity）、\textbf{Finger Quilt}（2016、iOS/Swift）、\textbf{Dot}（2017、ACの\texttt{plot}ディスクを予示するドローイングアプリ）、そして最も重要な\textbf{No Paint}（2014--2020）は5つの化身——Rails、JavaScriptフィル、WebGLプロトタイプ、iOS/Cordova、Vercelサイト——を経て、最終的に\ac{}に吸収された。
166
+
167
+
これは放棄されたプロジェクトの歴史ではない。\emph{リスタート}の歴史である：同じ人間が同じ問いを立て、機能の蓄積ではなくやり直すことを選ぶ。このパターンは\ac{}自体にも見える：ピースモデル（単一ファイル、ライフサイクル関数、即時モードグラフィクス）は、以前のイテレーションを殺した機能蓄積を\emph{防ぐ}制約優先の設計である。
168
+
169
+
\subsection{パフォーマンスへの転回（2016--2018）}
170
+
171
+
2016年から2018年の間、@jeffreyはGoodiepal \& Palsとともにヨーロッパの65以上の会場でツアーし、ライブパフォーマンスツールを構築した：観客参加インターフェース、音楽記譜レンダラー、ライブ講義キャプションディスプレイ。これらのツール——急速に構築され、一度使われ、その後破棄された——は\ac{}に引き継がれる設計原則を確立した：製品としてではなく楽器としてのソフトウェア。これらのツールは演奏されるものであり、出荷されるものではなかった。
172
+
173
+
Goodiepalの影響はコラボレーション以上に深い。Goodiepal論文~\citep{scudder2026goodiepal}は\ac{}に引き継がれる5つの系譜を特定する：楽器優先設計、機関ではなく親和性を通じて組織されるコミュニティ、デジタル複製に抵抗するよう設計された作品、そしてカリキュラムではなく直接的な関与を通じたラディカルな教育法。
174
+
175
+
\subsection{歴史が予測に重要な理由}
176
+
177
+
94のプロジェクトの歴史は2つの方法で予測を制約する。第一に、突然の方向転換の可能性を低くする。@jeffreyは同じ問い——パーソナルツール、クリエイティブ楽器、制約ベースの設計——を中心に15年間運動してきた。今後5年はほぼ確実にこの軌道内に留まる。第二に、人々がプロジェクトを放棄する通常の理由（退屈、興味の喪失、より光るものへの誘惑）による放棄の可能性を低くする。リスクは気の散りではなく疲弊である。\S\ref{sec:giveup}でこの点に戻る。
178
+
179
+
% ============ 3. 余剰ハードウェアの波 ============
180
+
181
+
\section{余剰ハードウェアの波}
182
+
\label{sec:surplus}
183
+
184
+
\ac{}の未来に作用する最大の単一外部力：2025年10月、MicrosoftはWindows 10のサポートを終了し、機関の基準では推定2.4億台のPCを陳腐化させた~\citep{ewaste2024monitor}。これらのマシンは壊れていない。8--16\,GB RAM、1080pスクリーン、WiFi、6--10時間のバッテリーを備えたThinkPad、EliteBook、Latitudeである。余剰市場では\$30--80で取引される。これらが以降すべての原材料となる。
185
+
186
+
\subsection{プロトタイプからフリートへ（2026--2027）}
187
+
188
+
\acos{}はすでに余剰ハードウェアで起動する~\citep{scudder2026os}。「@jeffreyのアパートの2台のThinkPadで起動する」から「教室の30台で起動する」への距離は、主に技術的ではない。運用的である：WiFi認証情報管理、デバイスごとのID設定、数十のノートパソコンモデルでのハードウェア互換性テスト、非技術者が実行できるフラッシュワークフロー。
189
+
190
+
近い将来の作業は地味だが重要である：
191
+
192
+
\begin{itemize}
193
+
\item \textbf{ユーザーごとのWiFi保存}：ハードコードされたSSIDをJavaScriptピースから永続的なデバイスごとの設定ファイルに移動し、OTAアップデート後も保持する
194
+
\item \textbf{ハードウェア互換性マトリクス}：ThinkPad X1/T/Lシリーズ、HP EliteBook 800シリーズ、Dell Latitude 5000/7000シリーズの体系的テスト
195
+
\item \textbf{ワンコマンド・フラッシュ}：ハンドル、カラー、WiFi認証情報を受け取り、起動可能なドライブを出力するUSBイメージビルダー
196
+
\item \textbf{A/Bカーネルスロット}：デュアルパーティション起動で、新カーネルのヘルスチェックが失敗した場合に自動ロールバック
197
+
\end{itemize}
198
+
199
+
これらは目を引く機能ではない。アートプロジェクトとインフラプロジェクトの違いである。コードベースの軌跡——OTAアップデートはすでに動作し、ビルド名はすでに生成され、デバイスIDはすでにブートパーティションに刻まれている——は@jeffreyがこの違いを理解し、インフラの方向に進んでいることを示している。
200
+
201
+
\subsection{50ドルの楽器（2027--2028）}
202
+
203
+
運用面の作業が実を結べば、経済的な主張は非常に説得力を持つ：個性化され、自動更新し、ITインフラを一切必要としない完全なクリエイティブ・コンピューティングツールが、余剰ノートパソコンとUSBドライブの価格で手に入る。Chromebook登録不要。Apple ID不要。サブスクリプション不要。
204
+
205
+
OLPCプロジェクト~\citep{kraemer2009olpc}は、ハードウェア優先のコンピューティングアクセス方式がコストとロジスティクスの面で失敗することを証明した。Raspberry Piはコスト問題を解決した（\$35）が、\$150の周辺機器を必要とする。\ac{}の主張は異なる：ハードウェアはすでに存在し、すでにスクリーン、キーボード、バッテリー、WiFiを備えており、数百万台規模で廃棄されつつある。ソフトウェアはわずか89\,MBである。
206
+
207
+
2028年までの可能性のある結果は大量採用ではなく、\emph{検証ポイント}である：10--30台の余剰マシンのフリートが\acos{}を実行する教室、コミュニティセンター、またはワークショップの場が数か所あり、その結果が記録される。これらの検証ポイントが助成金申請、機関パートナーシップ、そして\S\ref{sec:sustainability}で述べる持続可能性の論拠のエビデンス基盤となる。
208
+
209
+
% ============ 3. 惑星アンサンブル ============
210
+
211
+
\section{惑星アンサンブル}
212
+
\label{sec:ensembles}
213
+
214
+
PLOrk論文~\citep{scudder2026plork}は、既存のコードベースがすでにサポートしている論点を提示する：プリンストンのPLOrkが2006年にコンセプトを証明して以来、ノートパソコン・オーケストラは音楽的に正当なものとなった~\citep{trueman2006plork}が、そのモデルは1席あたり\$1,500以上のコストで大学に閉じ込められてきた。余剰ハードウェア上の\acos{}はコストを1席あたり\$50に下げる。問題は誰が演奏するかである。
215
+
216
+
\subsection{アンサンブル楽器としてのnotepat（2026--2027）}
217
+
218
+
\np{}はすでに32ボイス合成、ルームリバーブ、波形タイプ選択を備えたポリフォニック・キーボード楽器である~\citep{scudder2026notepat}。ベアメタルで192\,kHzで動作する。アンサンブル演奏に欠けている要素はオーディオ品質ではなく\emph{コーディネーション}：同期テンポ、共有ハーモニー空間、指揮者インターフェースである。
219
+
220
+
考えられる開発パス：
221
+
222
+
\begin{itemize}
223
+
\item \textbf{UDPアンサンブル同期}：既存のデュアルチャネルネットワーキング（WebSocket + UDP）を拡張し、ローカルネットワーク上のデバイス間でテンポクロックを同期する
224
+
\item \textbf{指揮者ピース}：アンサンブル状態を表示し、指揮者がテンポ、キー、ダイナミクスを設定できる新しいピース
225
+
\item \textbf{空間化}：余剰ノートパソコンの物理的配置を分散型スピーカーとして活用する——Turinoの参加型音楽モデル~\citep{turino2008music}に従い、アンサンブルそのもの\emph{が}音響システムとなる
226
+
\end{itemize}
227
+
228
+
この系譜には明確なカンファレンスでの訴求力がある。10台の余剰ThinkPadが協調された音楽作品を演奏するライブデモ——各台が演奏者のハンドルを虹色テキストで表示し、各台が分散型サウンドフィールドに一声部を提供する——はArs Electronicaノミネーションやnime投稿を獲得しうるデモである。
229
+
230
+
\subsection{音楽を超えて（2028--2031）}
231
+
232
+
アンサンブルモデルは音楽を超えて一般化できる。協調されたピースを実行する余剰マシンのネットワークは次のようなものになりうる：
233
+
234
+
\begin{itemize}
235
+
\item \textbf{分散型ペインティングウォール}：各スクリーンがより大きなキャンバスの一部を表示し、参加者がローカルでペイントし、ネットワークが結果を合成する
236
+
\item \textbf{協働KidLisp環境}：学生がジェネラティブプログラムを書き、共有ビジュアル空間に合流させる
237
+
\item \textbf{パフォーマンス総譜}：マシンがグラフィカル総譜~\citep{scudder2026pieces}を実行し、各台が異なるピースを通じて同じ記譜を解釈する
238
+
\end{itemize}
239
+
240
+
これらすべてのインフラはすでに存在する：WebSocketリレー、UDPブロードキャスト、デバイスごとのアイデンティティ、任意のグラフィクス・オーディオ・入力の組み合わせをサポートするピースモデル。欠けているのは\emph{オーケストレーション}——ピースそのものとそれを取り巻く社会的形態である。
241
+
242
+
% ============ 第3の次元 ============
243
+
244
+
\section{第3の次元}
245
+
\label{sec:3d}
246
+
247
+
\ac{}は広く2Dシステムとして認識されている。即時モードグラフィクスAPI——\texttt{wipe}、\texttt{ink}、\texttt{line}、\texttt{box}——とほとんどのピースのピクセルアート美学がこの印象を強化している。しかしインフラは異なる物語を語っている。完全なソフトウェア3Dラスタライザーがすでに存在し、マルチプレイヤーFPSがすでにリリースされ、ベアメタルOS内のアーキテクチャ選択は3Dを次の重要な表現フロンティアとして位置づけている。
248
+
249
+
\subsection{すでに動作しているもの}
250
+
251
+
ベアメタルOSには\texttt{graph3d.c}が含まれている。透視投影、視錐台クリッピング（6クリッピングプレーンに対するSutherland-Hodgmanアルゴリズム）、デプスバッファ、頂点カラー補間、透視補正重心座標によるテクスチャマッピングを備えた約600行のCPUソフトウェアラスタライザーである。JavaScript APIは\texttt{Form}コンストラクタを通じてこの機能を公開する：ピースは頂点位置、色、テクスチャ座標を持つメッシュを作成し、\texttt{ink(r,g,b).form(mesh)}でレンダリングする。
252
+
253
+
2つのプロダクションピースがシステムを実証している。\texttt{fps.mjs}はポインターロック、WASD移動、テクスチャ地面、回転する立方体を備えた一人称カメラを提供する。\texttt{1v1.mjs}はこれをマルチプレイヤーFPSに拡張し、ヒットスキャン武器、ボットAI（巡回/追跡/逃走状態）、キルトラッキング、デュアルチャネルネットワーク（信頼性のあるゲームイベント用WebSocket、低遅延位置同期用UDP）を備える。ブラウザパスはThree.js（r0.182）をWebGLレンダリングに使用し、VR/XRセッションサポートを含む~\citep{sutherland1968head}。
254
+
255
+
したがってシステムには2つの並列3Dパスがある：ベアメタルでのソフトウェアラスタライザー（純粋CPU、GPUなし）とブラウザでのハードウェア加速パス（WebGL/Three.js、WebGPUインフラ準備済み）。ピース作者の観点からはAPI表面は同一である。
256
+
257
+
\subsection{ベアメタルでのGPU問題（2026--2028）}
258
+
259
+
ソフトウェアラスタライザーはエレガントだが根本的に制限される。ターゲットフリート内の各余剰ThinkPadとEliteBookはOpenGL 4.xまたはVulkan 1.xをサポートするIntel統合GPUを持ち、遊休している。カーネルのDRMサブシステムはすでにKMSモードセッティングを通じてディスプレイを管理している。GPU加速ラスタライゼーション用のレンダーノードを公開するよう拡張するのは既知のエンジニアリングパスである（DRM上のEGL、または\texttt{/dev/dri/renderD128}経由のVulkan）。
260
+
261
+
ありえる軌跡は慎重である。@jeffreyの設計本能はハードウェア委任よりもソフトウェア制御に傾く——ベアメタルOS全体の哲学が「電源投入からピクセルまでのすべての命令を知る」ことである。GPUドライバーは不透明性を導入する：ファームウェアblob、ドライバーバグ、ベンダー固有の挙動。ソフトウェアラスタライザーの美点はそれが\emph{読める}ことである：頂点からピクセルまでのパイプラインが学生が読める600行のCコードである。
262
+
263
+
ありえる妥協案：GPU加速を必要とするピースのためのオプショナルパスとし、ソフトウェアラスタライザーをデフォルトかつリファレンス実装として維持する。これはブラウザアーキテクチャを反映しており、WebGPUが2D canvasと共存するが置き換えはしない。
264
+
265
+
\subsection{創作メディアとしての3D（2028--2031）}
266
+
267
+
より興味深い問いは技術的ではなく表現的である。制約、即時性、単一ファイルピースを中心に設計されたシステムにおいて、3Dは何を意味するか？
268
+
269
+
先行プロジェクトが手がかりを提供する。@jeffreyの作業は常に\emph{ペインティング}を中心としてきた：No Paint、JeffreyPaint、thePRBAT、Radical Digital Paintingツアー講義。3DインフラはゲームエンジンやCADツールに向けて構築されていない。\emph{空間的ペインティング}に向けて構築されている——2Dで\texttt{ink(255,0,0).line(0,0,100,100)}が提供するのと同じ即時性で、3D空間にマーク、色、形を配置する能力。
270
+
271
+
重要なピースはUnityデモのように見えるものではないだろう。@jeffreyが2Dを使うのと同じ方法で3Dを使うものだろう：楽器の素材として、パフォーマンスの素材として、消費されるものではなく演奏されるものとして。音符が空間的位置を持ち、ルームリバーブが文字通りの——音が仮想空間に分散された形体から発する——3D \np{}。\texttt{(box 0 0 0 50 50 50)}が\texttt{(rect 0 0 50 50)}が矩形を配置するのと同様に立方体を配置する3D KidLisp。各台が同一の分散3Dシーンの異なるカメラアングルをレンダリングする余剰ノートパソコンのフリート。
272
+
273
+
アンサンブルとの収束（\S\ref{sec:ensembles}）こそが3Dが真に新規なものとなる場所である。ネットワーク上の余剰マシン間で同期された3Dシーン——各スクリーンが共有仮想空間への窓であり、各プレイヤーの入力がすべての参加者のシーンに影響する——は、ゲームエンジンもクリエイティブ・コーディングツールも\$50/席の価格帯で探求していない形態である。ネットワークはすでに検証済み（\texttt{1v1.mjs}）。ハードウェアはすでに入手可能（\S\ref{sec:surplus}）。欠けているのは分散型空間楽器がどのような感触を持つべきかという芸術的ビジョンであり、それこそ@jeffreyが94のプロジェクトを通じてどう答えるかを学んできた種類の問いである。
274
+
275
+
% ============ 5. 学術的転回 ============
276
+
277
+
\section{学術的転回}
278
+
\label{sec:scholarly}
279
+
280
+
2026年3月3日から20日の間に、@jeffreyは4言語で19本の研究論文を生産した。これは独立開発者にとって通常の行動ではない。学術的正当性への意図的な転回を示す——プロジェクトの周りに RESEARCH-DIRECTION.md が呼ぶ「リサーチ・モート（研究の堀）」を構築する試みである。
281
+
282
+
\subsection{論文工場（2026--2027）}
283
+
284
+
論文インフラはすでに工業化されている：AC書体を使ったカスタム\LaTeX{}テンプレート、サーバー（「オーブン」）を通じた自動PDF構築、単ページ印刷用のカード形式、各論文のデンマーク語・スペイン語・中国語版を生産する翻訳パイプライン。40以上のリーディング素材のライブラリが引用基盤を提供する。パイプラインは試作ではなく生産のために設計されている。
285
+
286
+
近い将来の軌跡は投稿である：ACM C\&C Demos（4月16日）、ICCC短報（4月24日）、JOSSソフトウェア論文（ローリング）。これらのいずれかが採択されれば、ほとんどのクリエイティブ・コーディングツールが達成したことのない学術的足がかりを得る。Processing~\citep{reas2007processing}とScratch~\citep{resnick2009scratch}は学術的正当性の構築に数年を要した。@jeffreyは生産量と複数の会場への同時ターゲティングでこのタイムラインを圧縮しようとしている。
287
+
288
+
\subsection{アーティスト＝研究者のアイデンティティ（2028--2031）}
289
+
290
+
CalArts論文は、芸術学校はオペレーティングシステムである——CalArtsのような機関に特有の近接性、批評、学際的交差感染の構造はソフトウェアに移植できると論じる。@jeffreyがこのペースで発表を続ければ、論文そのものがポートフォリオとなる：ソフトウェアプロジェクトのドキュメントではなく、クリエイティブ・コンピューティングとは何か、誰のためのものかについての持続的な論証。
291
+
292
+
5年後の結果として考えられるのは2つのシナリオのいずれかである：
293
+
294
+
\begin{enumerate}
295
+
\item \textbf{モートが保たれる}：6--10本の論文が査読付き会場で出版され、@jeffreyがカンファレンスでの講演に招かれ、\ac{}がProcessing、Scratch、Sonic Pi~\citep{aaron2016sonic}と並んで認知されたクリエイティブ・コンピューティング環境としての標準的系列に加わる。論文がフィードバックループを生む：学術的注目がユーザーをもたらし、ユーザーがピースを作り、ピースが新しい論文を生む。
296
+
\item \textbf{モートが保たれない}：投稿が却下され、単著者モデルが査読者の懸念を招き、論文インフラが休眠状態に入る。コードは生き残る。学術的アイデンティティは生き残らない。これはアーティスト＝プログラマーにとってより一般的な結果である。
297
+
\end{enumerate}
298
+
299
+
率直な予測はその中間である：ニッチな会場（NIME、xCoAx、ICLC）で信頼性を確立するのに十分ないくつかの出版物が採択されるが、共同著者やユーザー研究なしには主流のHCIやPLカンファレンスは依然として手の届かないところにある。
300
+
301
+
% ============ 5. KIDLISPの独自の生命 ============
302
+
303
+
\section{KidLispの独自の生命}
304
+
\label{sec:kidlisp}
305
+
306
+
KidLispは118の関数を持つジェネラティブアート用Lisp方言である~\citep{scudder2026kidlisp}。サンドボックス化されており（ファイルI/Oなし、ネットワークなし）、ブラウザで動作し、16,779の保存プログラムとTezosを通じたブロックチェーン・ミンティング統合をすでに蓄積している。言語はインデックスカード1枚に書けるほど小さい。
307
+
308
+
\subsection{言語コミュニティ（2026--2028）}
309
+
310
+
Tezosの「keeps」システム——KidLispプログラムが2.5 XTZでオンチェーンアート作品としてミントされる——はKidLisp作成の経済的インセンティブを生み出す。keepsコントラクト（v11）は稼働中で、ミントUIはkeeps.kidlisp.comに存在し、5つのトークンがミントおよび移行されている。ジェネラティブアート市場がアクティブであり続ければ、この系譜は自己持続しうる。
311
+
312
+
より興味深い可能性は教育面にある。KidLispの制約——状態変異なし、描画以外の副作用なし、118関数、ブラウザで動作——は教育環境の候補にする。カード形式（学生が手に持てる単ページプログラム）を中心に構築されたKidLispカリキュラムは、Papertの構築主義~\citep{papert1980mindstorms}とプロジェクトの既存インフラに一致する。
313
+
314
+
\subsection{言語の進化（2028--2031）}
315
+
316
+
KidLispは成長への圧力に直面する。ユーザーは状態、アニメーション、インタラクティビティ、サウンドを求めるだろう。設計上の問いは、言語がこれらの機能を吸収するか（汎用クリエイティブ言語になる）、意図的なミニマリズムを維持するか（静的ジェネラティブアートのための「俳句言語」、JavaScriptが残りを処理する）である。
317
+
318
+
プロジェクトの歴史は後者を示唆する。94の先行プロジェクトに見える@jeffreyの設計本能は、機能蓄積よりも鋭い制約に傾く。ピースモデルそのもの——単一ファイル、ライフサイクル関数、即時モードグラフィクス~\citep{scudder2026pieces}——が制約優先の設計である。KidLispはおそらく小さいままだろう。興味深い成長は言語が何を追加するかではなく、人々がそれで何をするかにある。
319
+
320
+
% ============ 6. 持続可能性 ============
321
+
322
+
\section{持続可能性の問題}
323
+
\label{sec:sustainability}
324
+
325
+
上記のすべての系譜は一人の人間が作業を続けることに依存している。\ac{}にはベンチャーキャピタルなし、機関サポートなし、@jeffrey以外の従業員なし。AestheticAntsメンテナンスシステムが日常タスクを自動処理するが、アーキテクチャの決定、論文執筆、ハードウェアテスト、コミュニティ育成には人間の注意が必要である。
326
+
327
+
\subsection{資金状況（2026--2028）}
328
+
329
+
プロジェクトは資金源を特定している：Creative Capital（\$50,000プロジェクト助成）、Prix Ars Electronica（\texteuro10,000）、Gary Marsden Travel Awards、GitHub Sponsors。論文工場はある程度、助成金申請戦略でもある：19本の論文、カンファレンスデモ、文書化されたユーザー基盤を持つプロジェクトは、コードだけのプロジェクトよりも競争力がある。
330
+
331
+
Tezos keepsは小額の収入を提供する。印刷物（2026年3月時点で20部注文済み）がもう一つの収入源を提供する。どちらもフルタイム開発を維持するには不十分である。
332
+
333
+
率直な予測：2028年までに、プロジェクトは助成金または機関との提携（レジデンシー、教職、研究フェローシップ）を獲得するか、メンテナンスモード開発に減速する。これは失敗のシナリオではない——多くの重要なクリエイティブツールはその作成者によって数十年にわたりパートタイムで維持されてきた。しかし野心的な系譜（惑星アンサンブル、余剰ハードウェアフリート、学術的モート）にはフルタイムの注意が必要である。
334
+
335
+
\subsection{単著者リスク（2028--2031）}
336
+
337
+
Illichの「共生のためのツール」~\citep{illich1973tools}は、良いツールは専門知識なしに操作できるべきだと論じる。\ac{}はそのユーザーにこれを期待しているが、プロジェクト自体はIllichの意味で共生的ではない：維持には@jeffreyの専門知識が必要である。バスファクターは1である。
338
+
339
+
緩和策は部分的に整っている：コードベースはオープンソースであり、アーキテクチャは19本の論文で文書化されており、ピースAPIは単一ファイルのシンプルさで設計されており、AestheticAntsシステムが自律的に日常メンテナンスを処理する。しかし「コードが公開されている」と「他の誰かがプロジェクトをリードできる」の間のギャップは巨大である。
340
+
341
+
5年間の軌跡として考えられるのは：@jeffreyが唯一のアーキテクトとして続ける。小規模なピース作者コミュニティがコンテンツを貢献する（265の公開ピース、増加中）。1〜2名の貢献者が特定の機能のプルリクエストを提出する。プロジェクトはProcessingやp5.jsの「千人貢献者」モデルには到達しないが、その必要もない——その価値提案は幅ではなく深さにある：単一のビジョンが厳格に維持され、委員会設計のツールでは到達できない場所にクリエイティブ・コンピューティングを届ける。
342
+
343
+
% ============ 7. 収束 ============
344
+
345
+
\section{収束}
346
+
\label{sec:convergence}
347
+
348
+
上記の7つの系譜は並行する軌道ではない。収束する。
349
+
350
+
94のプロジェクトの歴史（\S\ref{sec:history}）が他の系譜を読み解くための軌跡を確立する。余剰ハードウェア（\S\ref{sec:surplus}）が惑星アンサンブル（\S\ref{sec:ensembles}）の物質的基盤を提供する。3Dインフラ（\S\ref{sec:3d}）がアンサンブルモデルを空間パフォーマンスに拡張する。論文（\S\ref{sec:scholarly}）がこのすべてを記録し正当化する。KidLisp（\S\ref{sec:kidlisp}）がこれらのチャネルを通じて到達する新規ユーザーに安全なエントリーポイントを提供する。持続可能性（\S\ref{sec:sustainability}）が収束が起きるかどうかを決定し、\S\ref{sec:giveup}がそうならなかった場合を検討する。
351
+
352
+
5年後の最も可能性の高いシナリオ：2031年までに\ac{}は認知されたがニッチなクリエイティブ・コンピューティング環境であり、以下を有する：
353
+
354
+
\begin{itemize}
355
+
\item \textbf{5,000--10,000名の登録ユーザー}、2,812から成長。notepatの口コミ拡散、カンファレンスデモ、教室展開が牽引
356
+
\item \textbf{ベアメタルOS}が5--15か所（学校、コミュニティセンター、アートレジデンシー、ワークショップ）の100--500台の余剰マシンに展開
357
+
\item \textbf{3--5本の出版論文}が査読付き会場にあり、最小限の学術的足跡を確立
358
+
\item \textbf{50,000以上のKidLispプログラム}、小規模だが活発なジェネラティブアートコミュニティがTezosでkeepsをミント
359
+
\item \textbf{アンサンブル演奏}が2--3のフェスティバルまたはカンファレンスで、余剰ノートパソコンフリートを分散楽器として使用
360
+
\item \textbf{単一のメンテナー}が依然としてコードの大部分を書き、AI支援メンテナンスがますます多くの日常作業を処理
361
+
\end{itemize}
362
+
363
+
これは最も野心的な結果でも最も保守的な結果でもない。何を気にかけるかについて具体的で意図的な選択——幅よりも深さ、IDEよりも楽器、破壊よりも維持——を行い、独立開発者として持続可能なペースでそれらの選択を追求するインフラを持つプロジェクトに整合する結果である。
364
+
365
+
% ============ 8. すべてを変えうるもの ============
366
+
367
+
\section{すべてを変えうるもの}
368
+
\label{sec:wildcards}
369
+
370
+
モメンタムベースの予測が信頼できるのは、まさに不連続性を無視するからである。4つのワイルドカードが軌跡を完全に変えうる：
371
+
372
+
\subsection{機関の拠点}
373
+
374
+
@jeffreyが芸術大学または研究大学で教職を得れば、\ac{}は現在欠けているものを獲得する：学生である。15--30名の学生が1学期間\ac{}を主要なクリエイティブ・コンピューティング環境として使用すれば、10年間の独立開発よりも多くのピース、バグレポート、ユースケース、学術的成果を生むだろう。CalArts論文の主張——芸術学校はオペレーティングシステムである——は逆もまた真である：オペレーティングシステムは学校になりうる。
375
+
376
+
\subsection{バイラルな瞬間}
377
+
378
+
\np{}はかつてHacker Newsに投稿され注目を集めた。第二のバイラルな瞬間——余剰ノートパソコンが一緒に音楽を奏でる教室のTikTok、\$50のクリエイティブ楽器についてのツイートスレッド、録画・共有されたカンファレンスデモ——は1週間で数千のユーザーをもたらしうる。インフラ（URLアクセス可能なピース、即時登録、ソーシャル機能）はこれを吸収するよう設計されている。@jeffreyがそれを吸収\emph{したいか}は別の問題である。プロジェクトの反プラットフォーム的立場~\citep{fisher2009capitalist}は、成長のための成長に対するアンビバレンスを示唆する。
379
+
380
+
\subsection{協力者としてのAI}
381
+
382
+
AestheticAntsシステムはすでに日常メンテナンスにAIを使用している。エージェントメモリシステムはインタラクションを記録し会話間の連続性を維持する。AI能力が進歩し続ければ、システムの将来バージョンはメンテナンス以上のことができるかもしれない：ピースの作成、KidLispプログラムの生成、アンサンブル総譜のオーケストレーション、論文の起草。プロジェクトの歴史、哲学、コードベースを理解するAI協力者によって「単著者」が強化されれば、単著者リスク（\S\ref{sec:sustainability}）は軽減される。
383
+
384
+
これは他のシナリオほど推測的ではない。すでに起きている。問題は程度の問題である：2031年までにAIがクリエイティブワークの10\%を処理するか、50\%か？答えは@jeffreyの何を委任し何を自分で行い続けるかの選択に依存する。プロジェクトの個人的な声への強調、著者の温度を伝える「PSYCHO」論文への強調は、最も重要な仕事は人間的なままであることを示唆する。その周りのインフラはそうではないかもしれない。
385
+
386
+
\subsection{もし止めたら}
387
+
\label{sec:giveup}
388
+
389
+
上記の予測は継続的な努力を前提としている。しかし94のプロジェクトの歴史（\S\ref{sec:history}）には名前をつけなければならないパターンが含まれている：@jeffreyは以前にも物事を放棄してきた。No Paintは5つの化身を持つ。各々が放棄された——アイデアが失敗したからではなく、実装が硬化したから——ツールが\emph{あるもの}とそれが\emph{あるべきもの}の間のギャップが耐えがたくなったから。リスタートはコミットメントの失敗ではない。コミットメントの表現である。
390
+
391
+
\ac{}のリスクは@jeffreyが興味を失うことではない。同じ問いを中心とした15年の運動がカジュアルな放棄を排除する。リスクは\emph{構造的疲弊}である：運用負担の蓄積——サーバー請求書、ユーザーサポート、ハードウェアテスト、論文投稿、助成金申請、依存関係の更新——がメンテナンス負担がプロジェクトを維持する価値のあるクリエイティブワークを圧迫するまで積み上がる。Ukeles~\citep{ukeles1969manifesto}はメンテナンスはアートだと論じたが、Ukelesでさえ承認なきメンテナンスが不可視労働になることを認めた。
392
+
393
+
3つの終了シナリオを検討に値する：
394
+
395
+
\begin{enumerate}
396
+
\item \textbf{静かなフェードアウト}：開発が散発的なコミットに減速し、サーバーは稼働し続けるがコミュニティが徐々に流出し、\ac{}はアーカイブとしては存在するが生きたシステムとしては存在しない——野心的なパーソナルツールの長いリストに加わる。これは単著者クリエイティブ・コンピューティングプロジェクトの最も一般的な結果である。ドラマティックではない。デフォルトである。
397
+
398
+
\item \textbf{意図的な停止}：@jeffreyが自然な境界でプロジェクト完了を宣言する——おそらくOSが十数のノートパソコンモデルで信頼性高く起動するとき、論文数がラウンドナンバーに達するとき、または100番目のピースが彼以外の誰かによって公開されるとき。彼はキャンバスに戻ってペインティングをする（2026年5月のVenice Family Clinic展覧会はこの系譜がすでに活発であることを示す）。コードは公開のまま。誰かがフォークするかもしれない。おそらく誰もしない。
399
+
400
+
\item \textbf{第95回のリスタート}：@jeffreyが\ac{}を離れて後継を構築する。これは歴史が最も強く予測するパターンである。No Paintが\ac{}になった。\ac{}は他の何かになりうる——OSの教訓、ピースモデル、アンサンブルネットワーク、3Dラスタライザーを吸収しつつ、蓄積されたインフラの重荷を捨てる。新しいプロジェクトはゼロから始まり、1つのファイルから、サイクルが再開する。外部から見るとこれは失敗のように見える。94のプロジェクトの系譜の内側からは、設計が完全に意図通りに機能しているように見える。
401
+
\end{enumerate}
402
+
403
+
率直な評価：シナリオ3は5年以内には起こりにくい。\ac{}はNo Paintが決して達成しなかった方法でエスケープベロシティに達しているから——登録ユーザー基盤、ベアメタルOS、ブロックチェーン統合、19本の論文、16,000以上のプログラムを持つ言語。サンクコストはクリーンなリスタートには大きすぎる。しかし持続可能性の問い（\S\ref{sec:sustainability}）が答えられなければ、シナリオ1は完全にありうる。一人の安定した資金を持たない人物によって維持されるこれほど野心的なプロジェクトは、常にたった一つの悪い年で静かなフェードアウトに至る距離にある。
404
+
405
+
緩和策はプロジェクトをここまで維持してきたのと同じ方法である：仕事そのものを十分にやりがいのあるものにし、運用負担を耐えうるものにすること。論文、パフォーマンス、ゼロから書かれた3Dラスタライザー、7秒のベアメタルブート——これらはロードマップ上の機能ではない。クリエイティブな実践である。実践がもはや楽しくなければ、プロジェクトは止まる。楽しいままであれば、プロジェクトは灯りが消える以外のすべてに耐えられる。
406
+
407
+
% ============ 10. 結論 ============
408
+
409
+
\section{結論}
410
+
411
+
Aesthetic Computerは自分が何であるかを知っているプロジェクトである。プロダクト・マーケット・フィットを探しておらず、エンタープライズにピボットしておらず、成長指標のために最適化していない。94の先行プロジェクトを通じて10年以上にわたりバージョンを重ねてきた一人の人物によって公に構築されているパーソナル・クリエイティブ・コンピューティングツールである。
412
+
413
+
今後5年間は内部の力（@jeffreyが維持できるペース、獲得できる資金）と外部の力（2.4億台の余剰PC、ジェネラティブアート経済、学術カンファレンスサイクル）によって形作られる。プロジェクトのインフラ——ベアメタルOS、論文工場、ピースモデル、ソーシャルネットワーク、ブロックチェーン・ミンティング——はこれらの力を吸収するよう構築されている。実際にそうなるかは、持久力、運、そしてどのプラットフォームにも属さないクリエイティブ・コンピューティングツールに世界が注目する意思があるかどうかに依存する。
414
+
415
+
Nelsonは1974年に「あなたは今すぐコンピュータを理解できるし、理解しなければならない」と書いた~\citep{nelson1974computerlib}。Illichは1973年に、ツールは機関的な仲介を要求するのではなく個人の自律を拡張すべきだと書いた~\citep{illich1973tools}。Ukelesは1969年にメンテナンスはアートだと書いた~\citep{ukeles1969manifesto}。\ac{}はこれらの総合である：パーソナルで、共生的で、クリエイティブな実践として維持されるツール。賭けは、この総合が余剰ハードウェアに適用され時間の中で持続されれば、永続するものを創造できるということである。
416
+
417
+
そうなるかどうかが唯一の興味深い問いである。本論文は答えを提供せず、場にある力の解読のみを提供する。コードが決定するだろう。
418
+
419
+
\vspace{0.5em}
420
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
421
+
422
+
\vspace{0.5em}\noindent\textit{英語より翻訳。原版は \url{https://papers.aesthetic.computer} にて入手可能}
423
+
424
+
% ============ REFERENCES ============
425
+
426
+
\bibliographystyle{plainnat}
427
+
\bibliography{references}
428
+
429
+
\end{document}
+14
-12
papers/arxiv-goodiepal/goodiepal-cards.tex
+14
-12
papers/arxiv-goodiepal/goodiepal-cards.tex
···
41
41
\thispagestyle{empty}
42
42
\vspace*{\fill}
43
43
\begin{center}
44
-
\includegraphics[height=8em]{pals}\par\vspace{0.3em}
45
-
{\acbold\fontsize{20pt}{24pt}\selectfont\color{acdark} Radical Computer Art}\par
46
-
\vspace{0.3em}
47
-
{\fontsize{10pt}{12pt}\selectfont\color{acpink} Goodiepalian Approaches in \acrandname{}}\par
48
-
\vspace{0.8em}
49
-
{\normalsize\color{cyan!70!blue}\textbf{@jeffrey}}\par
44
+
\includegraphics[height=9em]{pals}\par\vspace{0.1em}
45
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} Radical Computer Art}\par
46
+
\vspace{0.1em}
47
+
{\fontsize{9pt}{11pt}\selectfont\color{acpink} Goodiepalian Approaches in \acrandname{}}\par
48
+
\vspace{0.4em}
49
+
{\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par
50
50
{\small\color{acgray} Aesthetic.Computer}\par
51
51
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
52
-
\vspace{0.8em}
53
-
\rule{0.6\textwidth}{1pt}\par
54
52
\vspace{0.4em}
55
-
{\small\color{acpink!40}\textit{working draft --- not for citation}}\par
56
-
\vspace{0.3em}
57
-
{\footnotesize\color{acgray} March 2026}\par
53
+
\rule{0.5\textwidth}{0.5pt}\par
54
+
\vspace{0.15em}
55
+
\colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par
56
+
\vspace{0.1em}
57
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/2113ef735}{2113ef735}}\par
58
+
\vspace{0.1em}
59
+
{\footnotesize\color{acgray}\href{https://papers.aesthetic.computer/radical-computer-art-26-arxiv-da-cards.pdf}{Dansk} · \href{https://papers.aesthetic.computer/radical-computer-art-26-arxiv-es-cards.pdf}{Español} · \href{https://papers.aesthetic.computer/radical-computer-art-26-arxiv-zh-cards.pdf}{{\accjk 中文}} · \href{https://papers.aesthetic.computer/radical-computer-art-26-arxiv-ja-cards.pdf}{{\accjk 日本語}}}\par
58
60
\end{center}
59
61
\vspace*{\fill}
60
62
···
72
74
73
75
\ac{}~\citep{scudder2026ac} is a mobile-first runtime and social network for creative computing. It is, by conventional standards, a software platform. It has a session server, a KidLisp interpreter, an NFT minting pipeline, and over 350 interactive programs called ``pieces.'' Its score is written in Markdown. Its logo is a pair of eyes called ``Pals.''
74
76
75
-
This paper argues that the distance between these two projects is smaller than it appears. \ac{}'s design decisions---many of which seem like engineering choices---are better understood as Goodiepalian commitments: philosophical positions about who computing is for, what constitutes a creative instrument, how communities of practice should organize, and what it means for software to address non-human audiences.
77
+
The distance between these two projects is smaller than it appears. \ac{}'s design decisions---many of which seem like engineering choices---are better understood as Goodiepalian commitments: philosophical positions about who computing is for, what constitutes a creative instrument, how communities of practice should organize, and what it means for software to address non-human audiences.
76
78
77
79
The scholarly literature on \gp{} remains thin but is growing. Wamberg's ``Art for Aliens''~\citep{wamberg2022artforaliens} situates \gp{} within a ``xenophile posthumanism'' informed by Rudolf Steiner, in which Artificial Intelligence is broadened to a more extensive network of material clusters that \gp{} designates Alternative Intelligence (ALI). A 2017 feature documentary, \emph{The Goodiepal Equation}~\citep{sanpakkila2017equation}, followed \gp{} over several years and multiple reinventions; \emph{In Spite Magazine} characterized the subject as ``renegade, anarchist, genius, trickster''~\citep{inspite2024goodiepal}. In 2020, the SMK (National Gallery of Denmark) devoted six rooms to ``Unboxing: The Goodiepal Collection''~\citep{smk2020unboxing}---one of Europe's largest private collections of sound art and sound objects, including a delay engine, a computer made entirely of glass, salt and water, and a machine which supposedly makes it possible to speak with the dead.
78
80
+205
papers/arxiv-goodiepal/goodiepal-ja.tex
+205
papers/arxiv-goodiepal/goodiepal-ja.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
5
+
\usepackage{fontspec}
6
+
\usepackage{unicode-math}
7
+
\setmainfont{Latin Modern Roman}
8
+
\setsansfont{Latin Modern Sans}
9
+
\newfontfamily\acbold{ywft-processing-bold}[Path=../../system/public/type/webfonts/,Extension=.ttf]
10
+
\newfontfamily\aclight{ywft-processing-light}[Path=../../system/public/type/webfonts/,Extension=.ttf]
11
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
12
+
13
+
\usepackage{xeCJK}
14
+
\setCJKmainfont{Droid Sans Japanese}
15
+
\setCJKsansfont{Droid Sans Japanese}
16
+
\setCJKmonofont{Droid Sans Japanese}
17
+
18
+
\usepackage{xcolor}
19
+
\usepackage{titlesec}
20
+
\usepackage{enumitem}
21
+
\usepackage{booktabs}
22
+
\usepackage{fancyhdr}
23
+
\usepackage{hyperref}
24
+
\usepackage{graphicx}
25
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
26
+
\usepackage{ragged2e}
27
+
\usepackage{microtype}
28
+
\usepackage{natbib}
29
+
\usepackage[colorspec=0.92]{draftwatermark}
30
+
31
+
\definecolor{acpink}{RGB}{180,72,135}
32
+
\definecolor{acpurple}{RGB}{120,80,180}
33
+
\definecolor{acdark}{RGB}{64,56,74}
34
+
\definecolor{acgray}{RGB}{119,119,119}
35
+
\definecolor{draftcolor}{RGB}{180,72,135}
36
+
37
+
\DraftwatermarkOptions{text=WORKING DRAFT,fontsize=3cm,color=draftcolor!18,angle=45}
38
+
39
+
\hypersetup{colorlinks=true,linkcolor=acpurple,urlcolor=acpurple,citecolor=acpurple,
40
+
pdftitle={ラディカル・コンピュータ・アート：Aesthetic ComputerにおけるGoodiepalメソッド}}
41
+
42
+
\titleformat{\section}{\normalfont\bfseries\normalsize\uppercase}{\thesection.}{0.5em}{}
43
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
44
+
\titleformat{\subsection}{\normalfont\bfseries\small}{\thesubsection}{0.5em}{}
45
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
46
+
47
+
\pagestyle{fancy}\fancyhf{}
48
+
\renewcommand{\headrulewidth}{0pt}
49
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{作業草稿 --- 引用不可}}
50
+
\fancyfoot[C]{\footnotesize\thepage}
51
+
52
+
\newcommand{\ac}{\textsc{Aesthetic.Computer}}
53
+
\newcommand{\acos}{\textsc{AC Native OS}}
54
+
\newcommand{\gp}{\textsc{Goodiepal}}
55
+
56
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
57
+
\setlength{\columnsep}{1.8em}
58
+
\setlength{\parindent}{1em}
59
+
\setlength{\parskip}{0.3em}
60
+
61
+
% Hyphenation for narrow two-column layout
62
+
\tolerance=800
63
+
\emergencystretch=1em
64
+
\hyphenpenalty=50
65
+
66
+
\begin{document}
67
+
68
+
\twocolumn[{%
69
+
\begin{center}
70
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
71
+
{\acbold\fontsize{22pt}{26pt}\selectfont\color{acdark} ラディカル・コンピュータ・アート}\par
72
+
\vspace{0.2em}
73
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} Aesthetic Computer における Goodiepal メソッド}\par
74
+
\vspace{0.3em}
75
+
{\aclight\fontsize{9pt}{11pt}\selectfont\color{acgray} 代替知性の音楽、楽器優先設計、そしてPalsモデル}\par
76
+
\vspace{0.6em}
77
+
{\normalsize @jeffrey}\par
78
+
{\small\color{acgray} Aesthetic.Computer}\par
79
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
80
+
\vspace{0.3em}
81
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
82
+
\vspace{0.6em}
83
+
\rule{\textwidth}{1.5pt}
84
+
\vspace{0.5em}
85
+
\end{center}
86
+
87
+
\begin{center}
88
+
{\small\color{acpink}\textbf{[ 作業草稿 --- 引用不可 ]}}
89
+
\end{center}
90
+
\vspace{0.3em}
91
+
92
+
\begin{quote}
93
+
\small\noindent\textbf{要旨。}
94
+
\ac{} は、その設計哲学が \gp{}（Gaeoudji SYGNOK、1974年生）の実践と教育に深く影響を受けたクリエイティブ・コンピューティング・プラットフォームであるが、この影響は学術的にはほとんど検証されていない。\gp{} はデンマーク系フェロー諸島出身の音楽家、教師、ラディカル・コンピュータ音楽の理論家である。本論文は \ac{} システムを貫く5つのGoodiepal的系譜を追跡する：(1) \emph{代替知性の音楽}という概念——人間の聴衆だけでなく、未来の非人間的な解釈者に向けた音楽を創ること——そしてそれが \ac{} のテキスト読み上げ挨拶、ビルド命名、マシンレベルの個性化に反響していること；(2) コンピューティングデバイスを使うツールではなく演奏する楽器として扱う\emph{楽器優先}の設計哲学；(3) 機関への所属ではなく親和性と共有実践に根ざした \emph{Pals モデル}のコミュニティ組織；(4) 完全なデジタル複製に抵抗するよう設計されたクリエイティブ作品である\emph{スキャン不可能な創造物}と、\ac{} の即時モードレンダリングとの共鳴；(5) カリキュラムではなく挑発と直接的な関与を通じて教える\emph{ラディカルな教育法}——\ac{} のクリエイティブ・コンピューティング教育アプローチに反映されている。これらのGoodiepal的コミットメント——しばしば風変わりまたは周縁的として退けられる——は、クリエイティブ・コンピューティング・プラットフォーム設計の主流モデルに対する、一貫しながらもまだ十分に理論化されていない代替パラダイムを構成すると主張する。
95
+
\end{quote}
96
+
\vspace{0.5em}
97
+
}]
98
+
99
+
\section{序論}
100
+
101
+
2012年、\gp{} は \emph{El Camino del Hardcore}~\citep{goodiepal2012elcamino} を出版した。これは191ページの「ラディカル・コンピュータ音楽」の楽譜であり、「人間だけでなく、未来の人工知能——あるいは私が呼ぶことを好む『代替知性』——にも鑑賞されうる音楽」のためのものである。作品は灰色の段ボールにComic SansとCourier書体で印刷されている。「おそらくスキャン不可能」と想定される活性写真、Roc Jim\'enez de Cisnerosとの通信、そして \emph{Leonardo Music Journal} に掲載を拒否されたラディカル・コンピュータ講義の広告が含まれている。従来の基準では、出版不可能である。
102
+
103
+
\ac{}~\citep{scudder2026ac} はモバイルファーストのクリエイティブ・コンピューティング・ランタイムかつソーシャルネットワークである。従来の基準では、ソフトウェアプラットフォームである。セッションサーバー、KidLispインタープリター、NFTミンティングパイプライン、そして「ピース」と呼ばれる350以上のインタラクティブプログラムを持つ。楽譜はMarkdownで書かれている。ロゴは「Pals」と呼ばれる一対の目である。
104
+
105
+
本論文は、この二つのプロジェクトの距離が見かけよりも近いことを論じる。\ac{} の設計判断——その多くは一見エンジニアリング上の選択に見える——は、Goodiepal的コミットメントとして理解する方がより適切である：コンピューティングは誰のためのものか、何がクリエイティブツールを構成するか、実践共同体はいかに組織されるべきか、そしてソフトウェアが非人間の聴衆に向けられるとはどういう意味かについての哲学的立場である。
106
+
107
+
\gp{} に関する学術文献は依然として希少だが増加中である。Wambergの「宇宙人のための芸術」~\citep{wamberg2022artforaliens} は \gp{} を「プロ異者的ポスト・ヒューマニズム」——ルドルフ・シュタイナーの影響下にある——の中に位置づけ、そこではAIが\gp{}がALI（代替知性）と名付けた、より広範な物質的集合のネットワークへと拡張される。2017年の長編ドキュメンタリー \emph{The Goodiepal Equation}~\citep{sanpakkila2017equation} は数年にわたって \gp{} を追い、彼の複数回の再定義を記録した。\emph{In Spite Magazine} は彼を「反逆者、アナキスト、天才、詐欺師」と呼んだ~\citep{inspite2024goodiepal}。2020年、SMK（デンマーク国立美術館）は「Unboxing: The Goodiepal Collection」~\citep{smk2020unboxing}に6つの展示室を捧げた——ヨーロッパ最大級のサウンドアートと音響オブジェクトの個人コレクションであり、ディレイエンジン、完全にガラス・塩・水でできたコンピュータ、そして死者と対話できるとされる機械を含む。
108
+
109
+
著者は2018年にGoodiepal \& Palsとともにヨーロッパをツアーし、Louisiana Museum（フムレベック）、KUNSTHAL AARHUS、Kammer-Pop Hamburgなどの会場で「ラディカル・デジタル・ペインティング」を演奏した。これらの公演のために構築したツール——ライブキャプションシステム、境界記譜レンダラー、デジタルペインティング転送サービス——は \ac{} アーキテクチャの直接的な前身である。これは遡及的な解釈ではなく、系譜である。
110
+
111
+
\section{代替知性の音楽}
112
+
113
+
\gp{} の中心的主張は、まだ存在しない聴衆のために音楽を創るべきだということである。「代替知性」——彼が「人工知能」よりも好む用語——は、非人間的で、まだ構築されておらず、おそらく決して出現しないかもしれない聴取者を指す。この音楽はAI\emph{について}ではなく、AI\emph{のため}のものである。
114
+
115
+
この概念は \emph{Mort aux Vaches Ekstra Extra} の作曲ゲーム場面~\citep{goodiepal2007mortauxvaches}において最も充実した展開を見せた。Gallery Andersen Contemporary（コペンハーゲン、2007年）と第5回ベルリン・ビエンナーレ（2008年）で講演として上演された。この講演は \gp{} の言葉では「『他の』知的思考方式に挑戦する音楽楽譜を創る練習」であり、「ユートピア、時間、記譜技術、言語、人工知能、『スキャン不可能性』……そして作曲家の役割」に関わるものだった。Roc Jim\'enez de CisnerosがRhizomeの特集で記録したように：「我々は機械と人間のように対話し始める必要がある……ユートピア的な未来において、（私の）作品は人間の精神のためだけではない。いいえ、それはさまざまな代替知性にも崇拝されるべきものだ」~\citep{rhizome2011goodiepal}。
116
+
117
+
Wambergはこれを「プロ異者的ポスト・ヒューマニズム」として枠づけ、そこではAIがALI——代替知性——へと拡張される。シリコンベースの計算を超えて「宇宙的、地質学的、生物学的」な物質的集合のネットワークへと延びる~\citep{wamberg2022artforaliens}。\gp{} は2004年から2008年にオーフス王立音楽院で作曲を教えた際に「ラディカル・コンピュータ音楽」という用語を造語した。この用語が記述するのは、コンピュータネットワーク\emph{によって}記譜される音楽ではなく、コンピュータネットワーク\emph{のために}記譜される音楽であり、機械そしてそこから生まれると期待される知性に向けた姿勢としてのものである。
118
+
119
+
\subsection{機械に向けた表現}
120
+
121
+
\ac{} はその機械に語りかける。\acos{}~\citep{scudder2026os} が起動するとき、テキスト読み上げで所有者の名前を声に出す：「hi jeffrey。」シャットダウン時：「bye jeffrey。」各OSビルドはそのgitコミットハッシュから決定論的に生成される独自の形容詞-動物名を得る——「keen-egret」「swift-otter」。マシンは起動時に自らの名前を宣言する。ビルド名はメタデータではなく、アイデンティティである。
122
+
123
+
これは擬人化ではない。Goodiepal的な姿勢——マシンを潜在的な対話者として扱い、何らかの構成において名前を呼ばれることを認識するかもしれない何かとして扱う。TTSエンジンは誰かが聴いているかどうかにかかわらず、部屋に向かって話す。起動音（E5$\rightarrow$B5）は誰かがいるかどうかにかかわらず鳴る。これらは人間と非人間の受容者の両方を含む環境に発射される信号である。
124
+
125
+
\subsection{楽譜としてのソフトウェア}
126
+
127
+
\gp{} の楽譜——\emph{El Camino}、\emph{Mort aux Vaches} 録音、ラディカル・コンピュータ講義——は人間の演奏者への指示ではない。解釈能力を持つあらゆるシステムに向けた文書である。\ac{} の \texttt{SCORE.md} も同様に機能する：人間の貢献者と自動化システム（CI/CDパイプライン、pre-commitフック、AestheticAntsメンテナンスシステム）の両方の行動を統制する文書である。楽譜は人間の読者と非人間の読者を区別しない。
128
+
129
+
\section{楽器優先設計}
130
+
131
+
\gp{} のデンマーク王立音楽院（2004--2008）での教育は、電子デバイスを操作するツールではなく演奏する楽器として扱うことを中心に据えていた。\emph{The Wire} が「完全に魅了される自家製音楽装置」と評し、観衆を「この非伝統的な美しさに対して笑うべきか泣くべきかわからない」状態にしたと描写したライブパフォーマンスは、このコミットメントを物理的に実演した。\gp{} は楽器を作る：奇妙な惑星モデル、ガラスのケージに入った金属の鳥、パズル型に切り抜かれたレコード、丸鋸の刃とスイスチーズ~\citep{inspite2024goodiepal}。楽器は表現の形を規定するアフォーダンスを持つ。ツールは既定の目的に奉仕する。この区別が \ac{} の基盤である。
132
+
133
+
\subsection{プロンプトとしての楽器}
134
+
135
+
\ac{} の主要インターフェースはテキストプロンプトである——メニューでも、ダッシュボードでも、IDEでもない。ユーザーはコマンドを入力し、即興と記憶を通じてピースを発見する。これは楽器を学ぶ際に用いる認知プロセスと同じである~\citep{scudder2026ac}。システムは明示的に「IDEではなく楽器」と記述されている。
136
+
137
+
このフレーミングには具体的な設計上の帰結がある。ファイルブラウザがない。プロジェクトパネルがない。タブがない。ユーザーは音楽家が一度に一つの楽器を演奏するように、一度に一つのピースとインタラクトする。これらの制約は意図的である：システムとの関係として、熟練度よりも流暢さに近いものを生み出す。
138
+
139
+
\subsection{フロントドアとしてのnotepat}
140
+
141
+
notepat——半音階キーボード楽器——を \acos{}~\citep{scudder2026notepat} のデフォルト起動ピースとして選んだことは、この哲学の最も明確な表現である。コンピュータはデスクトップやブラウザに起動しない。楽器に起動する。このマシンでできる最初のことは\emph{演奏する}ことである。発する最初の音は音階音である。利用可能な最初のインタラクションはキーを押して音を聴くことである。
142
+
143
+
これは \gp{} の立場の文字通りの実現である：コンピュータは楽器である。比喩的にではない。構想としてではない。起動シーケンス\emph{そのもの}が楽器である。
144
+
145
+
\section{Pals モデル}
146
+
147
+
\gp{} のコラボレーション実践は「Pals」——音楽家、ビジュアルアーティスト、プログラマー、そして現れる誰もが含まれる緩やかな親和集団——を中心に組織される。会員資格なし、機関の支援なし、正式な構造なし。集団は共有実践と相互認知を通じて存在する。
148
+
149
+
\subsection{プラットフォーム・アイデンティティとしてのPals}
150
+
151
+
\ac{} のロゴは「Pals」と呼ばれる。プロジェクトの楽譜のタイトルは「Score for Aesthetic.Computer \& Pals」である。これはブランディングではなく、構造的な声明である。プラットフォームはその開発者や投資家ではなく、実践者のコミュニティに属する。Palsロゴ——一対の目——はすべての起動画面、すべての論文、すべてのランディングページに現れる。ユーザーが最初にそして最後に見るものである。
152
+
153
+
\subsection{laer-klokken}
154
+
155
+
コペンハーゲンのlaer-klokken（「時計を学ぶ」）コミュニティは、音楽、アート、文化的実践のために毎日 \ac{} を使用している。\gp{} と協力者によって組織されたこのコミュニティは、著者本人の使用を除けば \ac{} の最も密集したデプロイメントである。この関係は作成者対ユーザーではなく、Pal対Palである：コミュニティがプラットフォームを形作り、プラットフォームもコミュニティを形作る。
156
+
157
+
\texttt{clock} ピース、give.aesthetic.computerページのデンマーク語テキスト、laer-klokkenポッドキャストの統合はすべて、この双方向的な関係の産物である。プラットフォームはコミュニティ\emph{のために}構築されたのではない。コミュニティ\emph{のもの}として構築されたのである。
158
+
159
+
\section{スキャン不可能な創造物}
160
+
161
+
\gp{} の \emph{El Camino del Hardcore} には「おそらくスキャン不可能な推測的音楽作品」と記述された「活性写真」が含まれている。これらの写真はデジタル複製に抵抗する——DRMや暗号化によってではなく、スキャン時に劣化する物質的特性（灰色の段ボール、混合書体、コラージュ）によって。作品はデジタル化すると\emph{悪化}するように設計されている。スキャン不可能性は \emph{Mort aux Vaches Ekstra Extra} のゲーム場面の中心でもある~\citep{goodiepal2007mortauxvaches}：「スキャン不可能な障害物」は、人間の作曲家と機械の解釈者の間の伝達に摩擦を生むことを意図した楽譜であり、機械に記譜を単に解析するのではなく、新しい解釈能力を発達させることを強いる。\emph{Mousse Magazine} が指摘したように、これはラディカル・コンピュータ音楽を「複雑な実存主義」——知性の出現をシミュレートするのではなく、その条件を創造する実践——として位置づける~\citep{mousse2018goodiepal}。
162
+
163
+
2020年のSMKの「Unboxing: The Goodiepal Collection」~\citep{smk2020unboxing}展覧会はこの哲学を物質化した：6つの展示室のサウンドアート、自家製楽器、単純な分類に抵抗するデバイス——灰色の段ボールの楽譜のように、デジタル複製ではなく物理的接触を要求するオブジェクト。一部の作品はヘッドフォンで聴くことができ、その他は「主に耳ではなく目を通じて体験されることを意図した」ものだった。このコレクションはヨーロッパ最大級のサウンドアートとテクノロジーの個人コレクションの一つである。
164
+
165
+
\subsection{キャプチャへの抵抗としての即時モード}
166
+
167
+
\ac{} のレンダリングエンジンは即時モードである：すべてのフレームがゼロから描画される。保持されるシーングラフなし、DOMなし、永続的な視覚状態なし。画面は毎秒60回 \texttt{wipe()} されて再描画される。スクリーンショットはキャプチャすべき安定した状態を持たないプロセスの1フレームをキャプチャする。
168
+
169
+
これはパフォーマンス最適化ではない。コンピューティングの\emph{現在時制}への美学的コミットメントである。ピースはその実行においてのみ存在する。ピースの録画はピースではなく、音楽パフォーマンスの録音がパフォーマンスではないのと同じである~\citep{magnusson2010designing}。即時モードレンダラーは、InstagramやPinterestなどのプラットフォームが依存する種類の静的キャプチャに抵抗する創造物を生み出す。
170
+
171
+
\subsection{貧しい画像の反転}
172
+
173
+
Steyerlの「貧しい画像」~\citep{steyerl2009defense}は重みを失うまで劣化されることで自由に流通する。\ac{} のピースは、あまりにも\emph{現前的}であるために流通が困難である——実行が必要で、ランタイムが必要で、特定の瞬間が必要である。貧しくなることを拒む豊かな画像である。これがGoodiepalの立場である：作品は配信インフラに適応すべきではない。インフラが作品に適応すべきであり、さもなければ作品はスキャン不可能なまま留まるべきである。
174
+
175
+
\section{ラディカルな教育法}
176
+
177
+
\gp{} は2004年にDIEM（デンマーク電子音楽研究所）——オーフス王立デンマーク音楽院の一部——の電子音楽史と美学の教授として採用され、最終的に電子音楽科の学科長を務めた。彼は2008年に離任した。\emph{El Camino del Hardcore} によれば「間違った種類の友達を作った」ことによる紛争が原因である~\citep{goodiepal2012elcamino}。2013年のKunstkritikkのインタビューで、\gp{} は彼のアイデンティティが本質的に道具的であると説明した：「Goodiepalは使われるようにデザインされている。直接使えばいい。なぜならGoodiepalの関心の幅はほとんどの人よりずっと狭い。Goodiepalには子供がいない、Goodiepalには家がない」~\citep{kunstkritikk2013goodiepal}。Monoskopアーカイブが記録するように、彼は「現代コンピュータ音楽とメディアアートにおける愚かさに対して知識戦争を宣言した」——彼を雇用した機関そのものに矛先を向けて。
178
+
179
+
彼の教育は挑発、素材との直接的な接触、そして既定のカリキュラムの拒否を中心に据えていた。学生が出会うのは教案ではなく楽器である。2017年のドキュメンタリー \emph{The Goodiepal Equation}~\citep{sanpakkila2017equation} は数年にわたるこれらの複数回の再定義を追い、\gp{} の電子ノイズポップから音楽創作の慣習への概念的挑戦への軌跡を描き出した。映画には核心的な等式が浮かび上がる：「メッセージが時間と空間の中でより遠くに伝わるほど、その内容により多くの価値を加える。」これは教育的主張であると同時に創造的主張でもある：作品の価値は創造時に固定されるのではなく、伝播を通じて蓄積される。
180
+
181
+
\subsection{プロンプトを通じた学習}
182
+
183
+
\ac{} のクリエイティブ・コンピューティング教育アプローチはこの立場を反映している。チュートリアルがない。あらかじめ決められた手順にユーザーを導く「入門ガイド」がない。ユーザーはプロンプトに出会い、タイピングを始める。システムが応答する。学習は探索、失敗、そして記憶された経路の漸進的な蓄積を通じて起こる——楽器を学ぶのと同じ方法で~\citep{papert1980mindstorms}。
184
+
185
+
これは帰結を伴う教育的選択である。構造化されたガイダンスを必要とするユーザーを排除する。メニューやツールチップを期待するユーザーを苛立たせる。好奇心と粘り強さを報いる。チュートリアルベースのシステムとは異なる種類の知識を生み出す：身体化された、即興的な、個人的な知識。
186
+
187
+
\subsection{snappidaggsアーカイブ}
188
+
189
+
\ac{} は \gp{} のsnappidaggsの完全なデジタルアーカイブ——3つの階層（er、flokrae、garundz）に分かれた158の視覚作品——をホストしている。アーカイブは専用のピースを通じてアクセスできる。これは博物館ではない。クリエイティブ・コンピューティング・プラットフォームに埋め込まれた生きたコレクションであり、ドローイングツールや楽器にアクセスするのと同じプロンプトからアクセスできる。アーカイブはGoodiepal実践\emph{について}のものではない。異なるメディアで継続されるGoodiepal実践\emph{そのもの}である。
190
+
191
+
\section{結論}
192
+
193
+
本論文が追跡した5つの系譜——代替知性、楽器優先設計、Palsモデル、スキャン不可能な創造物、ラディカルな教育法——は、文芸批評的な意味での \ac{} への影響ではない。参照や暗示ではない。システムアーキテクチャに埋め込まれた構造的コミットメントである：起動シーケンスに、レンダリングエンジンに、プロンプトインターフェースに、コミュニティモデルに、ロゴに。
194
+
195
+
クリエイティブ・コンピューティング・プラットフォームは通常、Processing、Scratch、p5.jsの系譜——学者が教育的文脈のために設計したツール——として理解される。\ac{} は異なる系譜に属する：デンマーク王立音楽院、フェロー諸島、灰色の段ボールの楽譜、そして間違った友達を作ったために解雇された音楽家を経由する道筋である。この系譜を認めることは \ac{} の技術的成果を弱めない。その動機を明らかにするのである。
196
+
197
+
\gp{} が提起した問い——「この音楽は誰のためのものか？」——は \ac{} において「このコンピューティングは誰のためのものか？」となる。答えは同じである：現れる者すべてのため、人間であれそうでなくても。Palsのために。
198
+
199
+
\vspace{0.5em}
200
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
201
+
202
+
\bibliographystyle{plainnat}
203
+
\bibliography{references}
204
+
205
+
\end{document}
+493
papers/arxiv-identity/identity-cards.tex
+493
papers/arxiv-identity/identity-cards.tex
···
1
+
% !TEX program = xelatex
2
+
% Cards format — auto-generated from identity.tex by cards-convert.mjs
3
+
\documentclass[11pt]{article}
4
+
5
+
\usepackage{fontspec}
6
+
\usepackage{unicode-math}
7
+
\setmainfont{Latin Modern Roman}
8
+
\setsansfont{Latin Modern Sans}
9
+
\setmonofont{Latin Modern Mono}[Scale=0.88]
10
+
11
+
12
+
\usepackage{graphicx}
13
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
14
+
\usepackage{booktabs}
15
+
\usepackage{tabularx}
16
+
\usepackage{ragged2e}
17
+
\usepackage{microtype}
18
+
\usepackage{natbib}
19
+
\usepackage{listings}
20
+
21
+
\lstdefinelanguage{acjs}{
22
+
morekeywords=[1]{function,export,const,let,var,return,if,else,new,async,await,import,from},
23
+
morekeywords=[2]{wipe,ink,line,box,circle,write,screen,params,colon,jump,send,store,net,sound,speaker,system},
24
+
sensitive=true,
25
+
morecomment=[l]{//},
26
+
morestring=[b]",
27
+
morestring=[b]',
28
+
morestring=[b]`,
29
+
escapeinside={|}{|},
30
+
}
31
+
\lstdefinestyle{acjsstyle}{
32
+
language=acjs,
33
+
keywordstyle=[1]\color{jskw}\bfseries,
34
+
keywordstyle=[2]\color{jsfn}\bfseries,
35
+
commentstyle=\color{jscmt}\itshape,
36
+
stringstyle=\color{jsstr},
37
+
}
38
+
\lstset{
39
+
basicstyle=\ttfamily\small,
40
+
breaklines=true,
41
+
frame=single,
42
+
rulecolor=\color{acgray!30},
43
+
backgroundcolor=\color{acgray!5},
44
+
xleftmargin=0.5em,
45
+
xrightmargin=0.5em,
46
+
aboveskip=0.5em,
47
+
belowskip=0.5em,
48
+
}
49
+
50
+
\makeatletter
51
+
\def\input@path{{../}}
52
+
\makeatother
53
+
\usepackage{ac-paper-cards}
54
+
55
+
% Extra commands from base paper
56
+
\newcommand{\atproto}{\textsc{AT Protocol}}
57
+
\definecolor{jskw}{RGB}{119,51,170}
58
+
\definecolor{jsfn}{RGB}{0,136,170}
59
+
\definecolor{jsstr}{RGB}{170,120,0}
60
+
\definecolor{jsnum}{RGB}{204,0,102}
61
+
\definecolor{jscmt}{RGB}{102,102,102}
62
+
63
+
\hypersetup{
64
+
pdftitle={Handle Identity on the AT Protocol: From Auth0 to Decentralized Sign-In},
65
+
}
66
+
67
+
\renewcommand{\acpdfbase}{handle-identity-atproto-26-arxiv}
68
+
\begin{document}
69
+
70
+
% ============================================================
71
+
% TITLE CARD
72
+
% ============================================================
73
+
\thispagestyle{empty}
74
+
\vspace*{\fill}
75
+
\begin{center}
76
+
\includegraphics[height=9em]{pals}\par\vspace{0.1em}
77
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} Handle Identity on the AT Protocol}\par
78
+
\vspace{0.1em}
79
+
{\fontsize{9pt}{11pt}\selectfont\color{acpink} From Auth0 to Decentralized Sign-In on Aesthetic Computer}\par
80
+
\vspace{0.4em}
81
+
{\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par
82
+
{\small\color{acgray} Aesthetic.Computer}\par
83
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
84
+
\vspace{0.4em}
85
+
\rule{0.5\textwidth}{0.5pt}\par
86
+
\vspace{0.15em}
87
+
\colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par
88
+
\vspace{0.1em}
89
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/2113ef735}{2113ef735}}\par
90
+
\vspace{0.1em}
91
+
{\footnotesize\color{acgray}\href{https://papers.aesthetic.computer/handle-identity-atproto-26-arxiv-da-cards.pdf}{Dansk} · \href{https://papers.aesthetic.computer/handle-identity-atproto-26-arxiv-es-cards.pdf}{Español} · \href{https://papers.aesthetic.computer/handle-identity-atproto-26-arxiv-zh-cards.pdf}{{\accjk 中文}} · \href{https://papers.aesthetic.computer/handle-identity-atproto-26-arxiv-ja-cards.pdf}{{\accjk 日本語}}}\par
92
+
\end{center}
93
+
\vspace*{\fill}
94
+
95
+
% ============================================================
96
+
% INDEX CARD
97
+
% ============================================================
98
+
\cardindex
99
+
100
+
% ============================================================
101
+
% BODY
102
+
% ============================================================
103
+
\section{Introduction}
104
+
105
+
Identity on the web is a landlord problem. You do not own your handle on Twitter, your username on Instagram, or your login on any platform that can delete your account. The AT Protocol~\citep{atproto2024spec}---the decentralized social networking protocol behind Bluesky---proposes a different arrangement: your identity is a cryptographic key pair, your handle is a domain name you control, and your data lives on a Personal Data Server that you can move between providers.
106
+
107
+
Aesthetic Computer has operated a hybrid identity system since 2024. Auth0~\citep{auth0spa} handles authentication: OAuth 2.0 with PKCE, refresh tokens, and a managed user database. Separately, a self-hosted PDS at \texttt{at.aesthetic.computer} mints ATProto identities for every verified user. The result is a doubled system: two identities per user, two credential stores, two handle sync paths, and a paid Auth0 subscription bridging the gap.
108
+
109
+
This paper asks: what if the PDS \emph{is} the identity provider?
110
+
111
+
The answer is not hypothetical. pckt.blog~\citep{pcktblog2025}, a blogging platform built on the \atproto{}, authenticates users entirely through \atproto{} OAuth. Users sign in with their Bluesky handle, their self-hosted PDS, or any compatible identity provider. No Auth0, no Firebase, no centralized user database. The content syncs to the user's own PDS using shared lexicons from Standard.site~\citep{standardsite2025}.
112
+
113
+
We examine how this model applies to Aesthetic Computer---a creative computing platform with 600+ interactive pieces, multiplayer sessions, a KidLisp programming language, and a native bare-metal OS~\citep{scudder2026os}---and propose a phased migration that preserves backward compatibility while moving toward decentralized identity.
114
+
115
+
% ============ 2. THE CURRENT AC IDENTITY ARCHITECTURE ============
116
+
117
+
\section{Current Architecture}
118
+
\label{sec:current}
119
+
120
+
\subsection{Auth0 as Identity Provider}
121
+
122
+
Authentication flows through Auth0's SPA SDK. On page load, \texttt{boot.mjs} checks localStorage for cached Auth0 state. If a session exists (or an OAuth callback is detected), it initializes the Auth0 client with PKCE and refresh tokens, exchanges authorization codes for access tokens, and retrieves the user profile. The Auth0 \texttt{sub} field (e.g., \texttt{auth0|abc123} or \texttt{google-oauth2|xyz}) serves as the internal user identifier.
123
+
124
+
\begin{lstlisting}[style=acjsstyle]
125
+
// boot.mjs: current Auth0 flow
126
+
const auth0 = await createAuth0Client({
127
+
domain: |\textcolor{jsstr}{"hi.aesthetic.computer"}|,
128
+
clientId: |\textcolor{jsstr}{"LVdZaM..."}|,
129
+
cacheLocation: |\textcolor{jsstr}{"localstorage"}|,
130
+
useRefreshTokens: true,
131
+
});
132
+
const user = await auth0.getUser();
133
+
// { sub, email, email_verified, ... }
134
+
\end{lstlisting}
135
+
136
+
\subsection{Handle System}
137
+
138
+
Handles are stored in a MongoDB \texttt{@handles} collection, mapping Auth0 \texttt{sub} to a 1--16 character alphanumeric string (with \texttt{.} and \texttt{\_} allowed). Validation enforces no leading/trailing punctuation, case-insensitive uniqueness, and profanity filtering. Handles are the primary user-facing identity: URL-addressable (\texttt{@handle/piece-name}), visible in chat, and spoken aloud by AC Native OS.
139
+
140
+
\subsection{ATProto Shadow Identity}
141
+
142
+
On first email verification, an Auth0 webhook triggers \texttt{createAtprotoAccount()}, which:
143
+
144
+
\begin{enumerate}
145
+
\item Generates a 32-character password
146
+
\item Creates an invite code on the PDS
147
+
\item Creates an account at \texttt{handle.at.aesthetic.computer}
148
+
\item Stores the DID, handle, and encrypted password in MongoDB (\texttt{users.atproto})
149
+
\end{enumerate}
150
+
151
+
When a user changes their AC handle, \texttt{updateAtprotoHandle()} syncs the change to the PDS. Content (paintings, moods, KidLisp snippets, tapes, news) is mirrored to the PDS via six custom lexicons (\texttt{computer.aesthetic.*}). The ATProto identity is real and functional---but the user never authenticates through it. It is a shadow identity: present, synced, but not sovereign.
152
+
153
+
\subsection{The Duplication Problem}
154
+
155
+
This architecture means:
156
+
157
+
\begin{itemize}
158
+
\item Two credential stores (Auth0 + PDS)
159
+
\item Two handle namespaces (AC handles + PDS handles)
160
+
\item Two sync paths (handle changes propagate Auth0 $\to$ MongoDB $\to$ PDS)
161
+
\item A paid dependency (Auth0 subscription)
162
+
\item No interoperability (a Bluesky user cannot sign into AC with their existing identity)
163
+
\end{itemize}
164
+
165
+
The PDS already knows who each user is. It already stores their DID, their handle, their content. The Auth0 layer adds cost and complexity without adding capability that the PDS cannot provide.
166
+
167
+
% ============ 3. THE AT PROTOCOL IDENTITY STACK ============
168
+
169
+
\section{The AT Protocol Identity Stack}
170
+
\label{sec:atproto}
171
+
172
+
Understanding the migration requires understanding the three layers of \atproto{} identity: DIDs, handles, and OAuth.
173
+
174
+
\subsection{Decentralized Identifiers (DIDs)}
175
+
176
+
A DID~\citep{w3cdid2022, atproto2024did} is a persistent, cryptographically verifiable identifier. The \atproto{} primarily uses \texttt{did:plc}, a method designed for strong consistency, high availability, and key rotation without losing identity. Each DID resolves to a document containing:
177
+
178
+
\begin{itemize}
179
+
\item A \textbf{signing key} (P-256 or K-256)~\citep{atproto2024crypto} for authenticating repository updates
180
+
\item \textbf{Rotation keys} for account recovery
181
+
\item A \textbf{PDS endpoint} URL
182
+
\item The user's current \textbf{handle}
183
+
\end{itemize}
184
+
185
+
The DID is the stable identity. Handles change; keys rotate; PDS providers come and go. The DID persists. AC already mints DIDs for every user through its PDS. The infrastructure exists.
186
+
187
+
\subsection{Handle Verification}
188
+
189
+
An \atproto{} handle~\citep{atproto2024handle} is a domain name that bidirectionally resolves to a DID. Verification uses two methods:
190
+
191
+
\textbf{DNS TXT}: Place a record at \texttt{\_atproto.example.com}:
192
+
\begin{lstlisting}
193
+
_atproto.example.com TXT "did=did:plc:abc..."
194
+
\end{lstlisting}
195
+
196
+
\textbf{HTTPS Well-Known}: Serve the DID at:
197
+
\begin{lstlisting}
198
+
GET /.well-known/atproto-did
199
+
Response: did:plc:abc...
200
+
\end{lstlisting}
201
+
202
+
Both methods require the handle to resolve to the DID \emph{and} the DID document to claim the handle back. This bidirectional verification means: if you control the domain, you control the handle. No central authority assigns handles; DNS is the authority.
203
+
204
+
For AC, this means \texttt{jeffrey.at.aesthetic.computer} is a real, verifiable ATProto handle because AC controls both the DNS and the PDS. But it also means a user who already owns \texttt{alice.bsky.social} or \texttt{alice.dev} has a cryptographically verified identity that AC can trust without a password.
205
+
206
+
\subsection{ATProto OAuth}
207
+
208
+
The \atproto{} OAuth specification~\citep{atproto2024oauth} extends OAuth 2.1 with three mandatory security mechanisms:
209
+
210
+
\textbf{PKCE} (Proof Key for Code Exchange)~\citep{rfc7636pkce}: Prevents authorization code interception. The client generates a random verifier, sends its hash with the authorization request, and proves possession of the original verifier during token exchange.
211
+
212
+
\textbf{PAR} (Pushed Authorization Requests)~\citep{rfc9126par}: The client submits authorization parameters via POST to the authorization server \emph{before} redirecting the user. This prevents parameter tampering in the redirect URL.
213
+
214
+
\textbf{DPoP} (Demonstrating Proof of Possession)~\citep{rfc9449dpop}: Each request includes a signed JWT proving the client holds the private key associated with the token. Even if an access token leaks, it cannot be used by a different client.
215
+
216
+
\subsubsection{Client Identification}
217
+
218
+
Unlike traditional OAuth, \atproto{} does not require pre-registration with each authorization server. Instead, clients publish metadata at a public HTTPS URL:
219
+
220
+
\begin{lstlisting}[style=acjsstyle]
221
+
// aesthetic.computer/oauth/client-metadata.json
222
+
{
223
+
|\textcolor{jsstr}{"client\_id"}|: |\textcolor{jsstr}{"https://aesthetic.computer/..."}|,
224
+
|\textcolor{jsstr}{"client\_name"}|: |\textcolor{jsstr}{"Aesthetic Computer"}|,
225
+
|\textcolor{jsstr}{"redirect\_uris"}|: [|\textcolor{jsstr}{"https://..."}|],
226
+
|\textcolor{jsstr}{"grant\_types"}|: [|\textcolor{jsstr}{"authorization\_code"}|],
227
+
|\textcolor{jsstr}{"dpop\_bound\_access\_tokens"}|: true
228
+
}
229
+
\end{lstlisting}
230
+
231
+
Any PDS can discover and verify the client by fetching this URL. No pre-shared secrets, no app store registration, no API key management.
232
+
233
+
\subsubsection{The Flow}
234
+
235
+
\begin{enumerate}
236
+
\item User enters their handle (e.g., \texttt{alice.bsky.social})
237
+
\item Client resolves handle $\to$ DID $\to$ PDS endpoint $\to$ authorization server
238
+
\item Client pushes authorization parameters via PAR
239
+
\item User is redirected to their PDS's authorization UI
240
+
\item User approves; PDS redirects back with authorization code
241
+
\item Client exchanges code for DPoP-bound access token
242
+
\item Client verifies the returned DID matches the expected identity
243
+
\end{enumerate}
244
+
245
+
The critical difference from Auth0: the user authenticates with \emph{their own server}. AC never sees a password. The PDS---whether Bluesky's, AC's own, or a self-hosted instance---is the identity authority.
246
+
247
+
% ============ 4. HOW PCKT.BLOG DOES IT ============
248
+
249
+
\section{Case Study: pckt.blog}
250
+
\label{sec:pckt}
251
+
252
+
pckt.blog~\citep{pcktblog2025} is a blogging platform that authenticates exclusively through \atproto{} OAuth. Its implementation demonstrates the practical viability of ATProto-only authentication for a content platform.
253
+
254
+
\subsection{Authentication}
255
+
256
+
Users sign in by entering their ATProto handle. pckt.blog resolves the handle, discovers the authorization server, and initiates the OAuth flow. The user approves on their PDS (Bluesky, Blacksky, a self-hosted server). pckt.blog receives a DPoP-bound access token and the user's DID. No passwords are stored. No separate user database is maintained.
257
+
258
+
\subsection{Data Sovereignty}
259
+
260
+
Content syncs to the user's own PDS using Standard.site lexicons~\citep{standardsite2025}:
261
+
262
+
\begin{itemize}
263
+
\item \texttt{site.standard.publication} --- blog collections
264
+
\item \texttt{site.standard.document} --- individual articles
265
+
\item \texttt{site.standard.graph.subscription} --- follow relationships
266
+
\end{itemize}
267
+
268
+
If pckt.blog disappears, the user's content remains on their PDS, accessible to any compatible reader. This is the promise of ATProto: the platform is a view, not a silo.
269
+
270
+
\subsection{Implications for AC}
271
+
272
+
pckt.blog proves that a content-oriented platform can operate entirely on ATProto identity. The parallels to AC are direct:
273
+
274
+
\begin{itemize}
275
+
\item pckt.blog publishes articles; AC publishes pieces, paintings, and moods
276
+
\item pckt.blog uses Standard.site lexicons; AC has six custom \texttt{computer.aesthetic.*} lexicons
277
+
\item pckt.blog's users own their content on their PDS; AC already mirrors content to its PDS
278
+
\item Both are Node.js/JavaScript applications
279
+
\end{itemize}
280
+
281
+
The gap: pckt.blog was built ATProto-native. AC has an existing Auth0 user base that must be migrated gracefully.
282
+
283
+
% ============ 5. PROPOSED MIGRATION ============
284
+
285
+
\section{Proposed Migration}
286
+
\label{sec:migration}
287
+
288
+
\subsection{Phase 1: ATProto OAuth as Secondary Sign-In}
289
+
290
+
Add ``Sign in with Bluesky'' alongside Auth0, without removing Auth0.
291
+
292
+
\textbf{Infrastructure:}
293
+
\begin{enumerate}
294
+
\item Publish client metadata at \texttt{aesthetic.computer/oauth/client-metadata.json}
295
+
\item Add \texttt{@atproto/oauth-client-node}~\citep{npmAtprotoOauth} to the backend
296
+
\item Create two new Netlify functions:
297
+
\begin{itemize}
298
+
\item \texttt{POST /api/atproto-auth/start} --- resolve handle, PAR, redirect
299
+
\item \texttt{GET /api/atproto-auth/callback} --- code exchange with DPoP
300
+
\end{itemize}
301
+
\item Store sessions in Redis (DID, handle, DPoP key pair, tokens)
302
+
\end{enumerate}
303
+
304
+
\textbf{Client flow:} A new ``Sign in with Bluesky'' button in \texttt{boot.mjs} triggers the ATProto OAuth flow. On success, \texttt{window.acUSER} is populated from the ATProto session (DID as \texttt{sub}, handle, no email unless the user provides one). The piece API surface is identical---pieces see a user with a handle, regardless of which auth path created the session.
305
+
306
+
\subsection{Phase 2: Handle Bridging}
307
+
308
+
When a user signs in via ATProto, bridge their handle to AC:
309
+
310
+
\begin{enumerate}
311
+
\item Extract the username from the ATProto handle (e.g., \texttt{alice} from \texttt{alice.bsky.social})
312
+
\item Check availability against the AC \texttt{@handles} collection
313
+
\item If available and valid (1--16 chars, alphanumeric), offer one-click claim
314
+
\item If taken, check if the existing owner's email matches---offer account linking
315
+
\item If taken by someone else, prompt for an alternative
316
+
\item Store a DID $\leftrightarrow$ AC sub mapping in MongoDB for future sign-ins
317
+
\end{enumerate}
318
+
319
+
Custom domain handles (e.g., \texttt{alice.dev}) require the user to choose an AC handle manually, since the domain itself may not map to a valid handle string.
320
+
321
+
\subsection{Phase 3: Identity Linking}
322
+
323
+
Existing Auth0 users can link their ATProto identity:
324
+
325
+
\begin{enumerate}
326
+
\item From account settings, initiate ATProto OAuth
327
+
\item On success, store the external DID alongside the Auth0 sub
328
+
\item Future sign-ins accept either auth path
329
+
\item Content can optionally sync to the user's external PDS (not just AC's PDS)
330
+
\end{enumerate}
331
+
332
+
This phase turns the existing \texttt{users.atproto} field from a shadow identity into a first-class identity link.
333
+
334
+
\subsection{Phase 4: ATProto-Primary}
335
+
336
+
Once the migration is validated:
337
+
338
+
\begin{enumerate}
339
+
\item New signups default to ATProto OAuth (creating accounts on AC's PDS)
340
+
\item Auth0 remains as a legacy path for existing users
341
+
\item Gradually sunset Auth0 as users link their ATProto identities
342
+
\item Remove Auth0 dependency, eliminate subscription cost
343
+
\end{enumerate}
344
+
345
+
\subsection{PDS Routing}
346
+
347
+
A key architectural decision: where does content go?
348
+
349
+
\begin{itemize}
350
+
\item \textbf{Auth0-only users}: content syncs to AC's PDS (current behavior)
351
+
\item \textbf{ATProto users with external PDS}: content syncs to \emph{their} PDS
352
+
\item \textbf{ATProto users on AC's PDS}: content stays on AC's PDS
353
+
\end{itemize}
354
+
355
+
This means the backend sync functions (\texttt{media-atproto.mjs}, \texttt{painting-atproto.mjs}, etc.) need a conditional path: resolve the user's PDS endpoint from their DID document, and write to that endpoint rather than assuming AC's PDS.
356
+
357
+
% ============ 6. HANDLE SEMANTICS ============
358
+
359
+
\section{Handle Semantics}
360
+
\label{sec:handles}
361
+
362
+
The handle is the most human-visible piece of the identity stack, and the migration raises questions about what a handle \emph{means}.
363
+
364
+
\subsection{Current Handle Model}
365
+
366
+
Today, an AC handle is:
367
+
\begin{itemize}
368
+
\item A 1--16 character string, first-come-first-served
369
+
\item Unique within the AC namespace
370
+
\item Used for URLs (\texttt{@alice/painting}), chat, and OS personalization
371
+
\item Stored in MongoDB, cached in Redis
372
+
\item Mirrored to the PDS as \texttt{alice.at.aesthetic.computer}
373
+
\end{itemize}
374
+
375
+
\subsection{ATProto Handle Model}
376
+
377
+
An ATProto handle is:
378
+
\begin{itemize}
379
+
\item A domain name (any valid DNS name)
380
+
\item Verified bidirectionally against a DID
381
+
\item Globally unique by DNS authority
382
+
\item Portable across services
383
+
\end{itemize}
384
+
385
+
\subsection{Bridging the Models}
386
+
387
+
The proposal: an AC handle is an \emph{alias} that maps to a DID. The source of truth shifts from MongoDB to the DID layer. Multiple sign-in methods (Auth0, ATProto OAuth) resolve to the same DID, which resolves to the same AC handle.
388
+
389
+
For AC Native OS~\citep{scudder2026os}, where the handle is inscribed in \texttt{config.json} on the boot partition, this means the device identity is backed by a cryptographic identity. ``Hi @alice'' on the boot screen means Alice's DID, Alice's signing key, Alice's portable identity---not just a string in a config file.
390
+
391
+
% ============ 7. OPEN QUESTIONS ============
392
+
393
+
\section{Open Questions}
394
+
\label{sec:questions}
395
+
396
+
\textbf{Handle priority.} If \texttt{alice} is unclaimed on AC but \texttt{alice.bsky.social} signs in, should she get it automatically? First-come-first-served is simple but allows squatting. ATProto-verified priority is fairer but adds complexity.
397
+
398
+
\textbf{Email requirement.} Auth0 provides verified email for account recovery. ATProto OAuth does not guarantee email. Should AC require an email for full account features (purchasing, notifications)?
399
+
400
+
\textbf{Multi-tenant.} AC operates a second tenant (\texttt{sotce}) with separate Auth0. How do ATProto identities map across tenants? The DID is tenant-agnostic, which may simplify cross-tenant identity.
401
+
402
+
\textbf{Session server.} Real-time features (chat, multiplayer) authenticate via Auth0 tokens forwarded through WebSocket. The session server must accept ATProto-issued tokens or a unified session token.
403
+
404
+
\textbf{Device pairing.} AC Native OS pairs via a 6-character code exchanged through Auth0. The ATProto equivalent: scan a QR code that initiates an OAuth flow on the phone, delivering tokens to the device.
405
+
406
+
\textbf{Admin identity.} Admin is currently \texttt{handle === "jeffrey" \&\& sub === ADMIN\_SUB}. Under ATProto-first auth, admin is \texttt{did === admin\_did}---cleaner, cryptographically grounded.
407
+
408
+
% ============ 8. RELATED WORK ============
409
+
410
+
\section{Related Work}
411
+
\label{sec:related}
412
+
413
+
\textbf{Decentralized identity.} The W3C DID specification~\citep{w3cdid2022} provides the formal framework for decentralized identifiers. The AT Protocol's \texttt{did:plc} method~\citep{atproto2024did} extends this with strong consistency guarantees and a centralized-but-auditable directory at \texttt{plc.directory}. This is a pragmatic compromise: full decentralization of identity resolution remains an open problem, and \texttt{did:plc} trades some decentralization for operational reliability.
414
+
415
+
\textbf{ATProto-native applications.} pckt.blog~\citep{pcktblog2025} demonstrates blogging; Leaflet.pub and Offprint.app collaborate on shared lexicons via Standard.site~\citep{standardsite2025}. These applications prove the viability of ATProto-only auth for content platforms.
416
+
417
+
\textbf{OAuth security.} DPoP~\citep{rfc9449dpop} prevents token theft; PAR~\citep{rfc9126par} prevents parameter tampering; PKCE~\citep{rfc7636pkce} prevents code interception. Together they represent the state of the art in browser-based OAuth security---significantly stronger than the Auth0 SPA flow AC currently uses.
418
+
419
+
\textbf{Convivial identity.} Illich's tools for conviviality~\citep{illich1973tools} frame the question: does the identity system expand personal autonomy, or does it require dependence on a provider? Auth0 is a managed service---convenient but dependent. ATProto identity is portable, self-verifiable, and provider-independent. Nelson's vision of personal computing~\citep{nelson1974computerlib} extends naturally to personal identity: you should own your name on the network.
420
+
421
+
% ============ 9. CONCLUSION ============
422
+
423
+
\section{Conclusion}
424
+
425
+
Aesthetic Computer already runs a PDS, mints DIDs, syncs content to ATProto records, and publishes custom lexicons. The only piece missing is letting users authenticate through that infrastructure instead of routing through Auth0. The migration is not a rewrite---it is the removal of a workaround.
426
+
427
+
The phased approach (ATProto as secondary sign-in $\to$ handle bridging $\to$ identity linking $\to$ ATProto-primary) ensures no existing user is disrupted. The end state: a creative computing platform where your handle is a cryptographic identity, your content lives on a server you control, and signing in means proving you own your keys---not trusting a third party to vouch for you.
428
+
429
+
The PDS is already running. The DIDs are already minted. The lexicons are already published. It is time to let users sign in through the front door.
430
+
431
+
% ============ REFERENCES ============
432
+
433
+
\vspace{0.5em}
434
+
\noindent\rule{\columnwidth}{0.5pt}
435
+
436
+
\subsection*{Reference Links}
437
+
438
+
\noindent\small
439
+
440
+
\textbf{AT Protocol Specifications:}
441
+
\begin{itemize}
442
+
\item \url{https://atproto.com/specs} --- Full protocol specification
443
+
\item \url{https://atproto.com/specs/oauth} --- OAuth specification
444
+
\item \url{https://atproto.com/specs/handle} --- Handle resolution
445
+
\item \url{https://atproto.com/specs/cryptography} --- Cryptographic methods
446
+
\item \url{https://web.plc.directory/spec/v0.1/did-plc} --- DID PLC specification
447
+
\item \url{https://atproto.com/guides/lexicon} --- Lexicon schema system
448
+
\item \url{https://atproto.com/guides/oauth-patterns} --- OAuth implementation patterns
449
+
\end{itemize}
450
+
451
+
\textbf{Implementation Guides:}
452
+
\begin{itemize}
453
+
\item \url{https://docs.bsky.app/blog/oauth-atproto} --- Building ATProto OAuth apps
454
+
\item \url{https://docs.bsky.app/docs/advanced-guides/resolving-identities} --- Identity resolution
455
+
\item \url{https://docs.bsky.app/docs/advanced-guides/oauth-client} --- OAuth client guide
456
+
\end{itemize}
457
+
458
+
\textbf{NPM Packages:}
459
+
\begin{itemize}
460
+
\item \texttt{@atproto/oauth-client-node} --- Node.js OAuth client
461
+
\item \texttt{@atproto/oauth-client-browser} --- Browser OAuth client
462
+
\item \texttt{@atproto/api} --- TypeScript XRPC client
463
+
\item \texttt{@atproto/identity} --- DID/handle resolution
464
+
\item \texttt{@atcute/oauth-browser-client} --- Lightweight alternative
465
+
\end{itemize}
466
+
467
+
\textbf{Reference Implementations:}
468
+
\begin{itemize}
469
+
\item \url{https://github.com/pilcrowonpaper/atproto-oauth-example} --- Astro OAuth example
470
+
\item \url{https://github.com/bluesky-social/atproto} --- Official ATProto monorepo
471
+
\item \url{https://standard.site/docs/introduction/} --- Standard.site shared lexicons
472
+
\end{itemize}
473
+
474
+
\textbf{Applications Using ATProto Auth:}
475
+
\begin{itemize}
476
+
\item pckt.blog --- Blogging on the open social web
477
+
\item Leaflet.pub --- Long-form publishing
478
+
\item Offprint.app --- Collaborative writing
479
+
\end{itemize}
480
+
481
+
\textbf{IETF Standards:}
482
+
\begin{itemize}
483
+
\item RFC 9449 --- DPoP (Demonstrating Proof of Possession)
484
+
\item RFC 7636 --- PKCE (Proof Key for Code Exchange)
485
+
\item RFC 9126 --- PAR (Pushed Authorization Requests)
486
+
\end{itemize}
487
+
488
+
\vspace{0.5em}
489
+
490
+
\bibliographystyle{plainnat}
491
+
\bibliography{references}
492
+
493
+
\end{document}
+592
papers/arxiv-identity/identity-ja.tex
+592
papers/arxiv-identity/identity-ja.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
\usepackage{xeCJK}
11
+
\setCJKmainfont{Droid Sans Japanese}
12
+
13
+
\setmainfont{Latin Modern Roman}
14
+
\setsansfont{Latin Modern Sans}
15
+
16
+
% Custom AC fonts
17
+
\newfontfamily\acbold{ywft-processing-bold}[
18
+
Path=../../system/public/type/webfonts/,
19
+
Extension=.ttf
20
+
]
21
+
\newfontfamily\aclight{ywft-processing-light}[
22
+
Path=../../system/public/type/webfonts/,
23
+
Extension=.ttf
24
+
]
25
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
26
+
27
+
% === PACKAGES ===
28
+
\usepackage{xcolor}
29
+
\usepackage{titlesec}
30
+
\usepackage{enumitem}
31
+
\usepackage{booktabs}
32
+
\usepackage{tabularx}
33
+
\usepackage{multicol}
34
+
\usepackage{fancyhdr}
35
+
\usepackage{hyperref}
36
+
\usepackage{graphicx}
37
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
38
+
\usepackage{ragged2e}
39
+
\usepackage{listings}
40
+
\usepackage{natbib}
41
+
\usepackage[colorspec=0.92]{draftwatermark}
42
+
43
+
% === COLORS (AC palette) ===
44
+
\definecolor{acpink}{RGB}{180,72,135}
45
+
\definecolor{acpurple}{RGB}{120,80,180}
46
+
\definecolor{acdark}{RGB}{64,56,74}
47
+
\definecolor{acgray}{RGB}{119,119,119}
48
+
\definecolor{draftcolor}{RGB}{180,72,135}
49
+
50
+
% === DRAFT WATERMARK ===
51
+
\DraftwatermarkOptions{
52
+
text=WORKING DRAFT,
53
+
fontsize=3cm,
54
+
color=draftcolor!18,
55
+
angle=45,
56
+
pos={0.5\paperwidth, 0.5\paperheight}
57
+
}
58
+
59
+
% === JS SYNTAX COLORS ===
60
+
\definecolor{jskw}{RGB}{119,51,170}
61
+
\definecolor{jsfn}{RGB}{0,136,170}
62
+
\definecolor{jsstr}{RGB}{170,120,0}
63
+
\definecolor{jsnum}{RGB}{204,0,102}
64
+
\definecolor{jscmt}{RGB}{102,102,102}
65
+
66
+
% === HYPERREF ===
67
+
\hypersetup{
68
+
colorlinks=true,
69
+
linkcolor=acpurple,
70
+
urlcolor=acpurple,
71
+
citecolor=acpurple,
72
+
pdfauthor={@jeffrey},
73
+
pdftitle={AT Protocol上のHandle ID：Auth0から分散型ログインへ},
74
+
}
75
+
76
+
% === SECTION FORMATTING ===
77
+
\titleformat{\section}
78
+
{\normalfont\bfseries\normalsize\uppercase}
79
+
{\thesection.}
80
+
{0.5em}
81
+
{}
82
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
83
+
84
+
\titleformat{\subsection}
85
+
{\normalfont\bfseries\small}
86
+
{\thesubsection}
87
+
{0.5em}
88
+
{}
89
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
90
+
91
+
% === HEADER/FOOTER ===
92
+
\pagestyle{fancy}
93
+
\fancyhf{}
94
+
\renewcommand{\headrulewidth}{0pt}
95
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{作業草稿 --- 引用不可}}
96
+
\fancyfoot[C]{\footnotesize\thepage}
97
+
98
+
% === CUSTOM COMMANDS ===
99
+
\newcommand{\acdot}{{\color{acpink}.}}
100
+
\newcommand{\ac}{\textsc{Aesthetic.Computer}}
101
+
\newcommand{\atproto}{\textsc{AT Protocol}}
102
+
103
+
% Random caps for Aesthetic.Computer branding
104
+
\newcount\acrandtmp
105
+
\newcommand{\acrandletter}[2]{%
106
+
\acrandtmp=\uniformdeviate 2\relax
107
+
\ifnum\acrandtmp=0\relax#1\else#2\fi%
108
+
}
109
+
\newcommand{\acrandname}{%
110
+
\acrandletter{a}{A}\acrandletter{e}{E}\acrandletter{s}{S}\acrandletter{t}{T}%
111
+
\acrandletter{h}{H}\acrandletter{e}{E}\acrandletter{t}{T}\acrandletter{i}{I}%
112
+
\acrandletter{c}{C}{\color{acpink}.}\acrandletter{c}{C}\acrandletter{o}{O}%
113
+
\acrandletter{m}{M}\acrandletter{p}{P}\acrandletter{u}{U}\acrandletter{t}{T}%
114
+
\acrandletter{e}{E}\acrandletter{r}{R}%
115
+
}
116
+
117
+
% === LISTINGS ===
118
+
\lstdefinelanguage{acjs}{
119
+
morekeywords=[1]{function,export,const,let,var,return,if,else,new,async,await,import,from},
120
+
morekeywords=[2]{wipe,ink,line,box,circle,write,screen,params,colon,jump,send,store,net,sound,speaker,system},
121
+
sensitive=true,
122
+
morecomment=[l]{//},
123
+
morestring=[b]",
124
+
morestring=[b]',
125
+
morestring=[b]`,
126
+
escapeinside={|}{|},
127
+
}
128
+
129
+
\lstdefinestyle{acjsstyle}{
130
+
language=acjs,
131
+
keywordstyle=[1]\color{jskw}\bfseries,
132
+
keywordstyle=[2]\color{jsfn}\bfseries,
133
+
commentstyle=\color{jscmt}\itshape,
134
+
stringstyle=\color{jsstr},
135
+
}
136
+
137
+
\lstset{
138
+
basicstyle=\ttfamily\small,
139
+
breaklines=true,
140
+
frame=single,
141
+
rulecolor=\color{acgray!30},
142
+
backgroundcolor=\color{acgray!5},
143
+
xleftmargin=0.5em,
144
+
xrightmargin=0.5em,
145
+
aboveskip=0.5em,
146
+
belowskip=0.5em,
147
+
}
148
+
149
+
% === LIST SETTINGS ===
150
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
151
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
152
+
153
+
% === COLUMN SEPARATION ===
154
+
\setlength{\columnsep}{1.8em}
155
+
156
+
% === PARAGRAPH SETTINGS ===
157
+
\setlength{\parindent}{1em}
158
+
\setlength{\parskip}{0.3em}
159
+
160
+
% Hyphenation for narrow two-column layout
161
+
\tolerance=800
162
+
\emergencystretch=1em
163
+
\hyphenpenalty=50
164
+
165
+
\begin{document}
166
+
167
+
% ============ TITLE BLOCK ============
168
+
169
+
\twocolumn[{%
170
+
\begin{center}
171
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
172
+
{\acbold\fontsize{24pt}{28pt}\selectfont\color{acdark} AT Protocol上のHandle ID}\par
173
+
\vspace{0.2em}
174
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} Auth0からAesthetic Computerの分散型ログインへ}\par
175
+
\vspace{0.3em}
176
+
{\aclight\fontsize{9pt}{11pt}\selectfont\color{acgray} ATProto OAuth、Handle検証、ポータブルなクリエイティブID}\par
177
+
\vspace{0.6em}
178
+
{\normalsize @jeffrey}\par
179
+
{\small\color{acgray} Aesthetic.Computer}\par
180
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
181
+
\vspace{0.3em}
182
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
183
+
\vspace{0.6em}
184
+
\rule{\textwidth}{1.5pt}
185
+
\vspace{0.5em}
186
+
\end{center}
187
+
188
+
\begin{center}
189
+
{\small\color{acpink}\textbf{[ 作業草稿 --- 引用不可 ]}}
190
+
\end{center}
191
+
\vspace{0.3em}
192
+
193
+
\begin{quote}
194
+
\small\noindent\textbf{要旨。}
195
+
Aesthetic Computerは現在Auth0を通じてユーザーを認証し、自己ホスト型AT Protocolパーソナルデータサーバー（PDS）\texttt{at.aesthetic.computer}上に並行するIDを維持している。認証済みの各ユーザーはDIDとPDS handleを取得するが、認証フローは集中型OAuthプロバイダーを経由する。AT Protocol OAuth~\citep{atproto2024oauth}をプライマリログイン方法として採用し、BlueskyまたはATProto IDを持つ誰もが直接認証してAesthetic Computer上で対応するhandleを取得できるようにすることで、この二重ID構造を統合することを提案する。本論文は\atproto{} IDスタック——DID、handle検証、DPoPおよびPAR付きOAuth 2.1——を検討し、pckt.blogおよび他のATProtoネイティブアプリが分散型ログインをどのように実装しているかを考察し~\citep{pcktblog2025}、現在のAC認証アーキテクチャをマッピングし、Auth0依存から\atproto{}優先IDへの段階的移行計画を提案する。核心的な主張は：すでに独自のPDSを運用しDIDを鋳造しているプラットフォームにおいて、集中型IDプロバイダーは退化器官であるということである。これを除去すればスタックは簡素化され、有償依存が排除され、ACは連合型ソーシャルウェブの一等市民となる。
196
+
\end{quote}
197
+
\vspace{0.5em}
198
+
}]
199
+
200
+
% ============ 1. 序論 ============
201
+
202
+
\section{序論}
203
+
204
+
ウェブ上のIDは家主問題である。Twitter上のhandle、Instagram上のユーザーネーム、アカウントを削除できるあらゆるプラットフォーム上のログイン情報は、あなたのものではない。AT Protocol~\citep{atproto2024spec}——Blueskyの背後にある分散型ソーシャルネットワーキングプロトコル——は異なる取り決めを提案する：IDは暗号鍵ペアであり、handleは自分が管理するドメイン名であり、データは自分がプロバイダー間で移行可能なパーソナルデータサーバーに保存される。
205
+
206
+
Aesthetic Computerは2024年以来、ハイブリッドIDシステムを運用してきた。Auth0~\citep{auth0spa}が認証を処理する：PKCE付きOAuth 2.0、リフレッシュトークン、ホスト型ユーザーデータベース。これとは別に、\texttt{at.aesthetic.computer}上の自己ホスト型PDSが認証済みユーザーごとにATProto IDを鋳造する。結果は重複したシステムである：ユーザーごとに2つのID、2つの認証情報ストア、2つのhandle同期パス、そしてギャップを埋めるための有償Auth0サブスクリプション。
207
+
208
+
本論文が問う：PDSが\emph{そのまま}IDプロバイダーだとしたら？
209
+
210
+
答えは仮説的ではない。pckt.blog~\citep{pcktblog2025}は\atproto{}上に構築されたブログプラットフォームであり、\atproto{} OAuthを通じて完全にユーザーを認証する。ユーザーはBluesky handle、自己ホスト型PDS、または任意の互換IDプロバイダーでログインする。Auth0なし、Firebaseなし、集中型ユーザーデータベースなし。コンテンツはStandard.site~\citep{standardsite2025}の共有語彙を使用してユーザー自身のPDSに同期される。
211
+
212
+
このモデルがAesthetic Computer——600以上のインタラクティブ作品、マルチプレイヤーゲームセッション、KidLispプログラミング言語、ネイティブベアメタルOS~\citep{scudder2026os}を持つクリエイティブ・コンピューティングプラットフォーム——にどう適用されるかを検討し、後方互換性を維持しながら分散型IDへと進む段階的移行計画を提案する。
213
+
214
+
% ============ 2. 現行AC IDアーキテクチャ ============
215
+
216
+
\section{現行アーキテクチャ}
217
+
\label{sec:current}
218
+
219
+
\subsection{IDプロバイダーとしてのAuth0}
220
+
221
+
認証はAuth0のSPA SDKを通じて行われる。ページ読み込み時、\texttt{boot.mjs}はlocalStorage内のキャッシュされたAuth0状態を確認する。セッションが存在する場合（またはOAuthコールバックが検出された場合）、PKCEとリフレッシュトークンでAuth0クライアントを初期化し、認可コードをアクセストークンに交換し、ユーザープロフィールを取得する。Auth0の\texttt{sub}フィールド（例：\texttt{auth0|abc123}または\texttt{google-oauth2|xyz}）が内部ユーザー識別子として機能する。
222
+
223
+
\begin{lstlisting}[style=acjsstyle]
224
+
// boot.mjs: current Auth0 flow
225
+
const auth0 = await createAuth0Client({
226
+
domain: |\textcolor{jsstr}{"hi.aesthetic.computer"}|,
227
+
clientId: |\textcolor{jsstr}{"LVdZaM..."}|,
228
+
cacheLocation: |\textcolor{jsstr}{"localstorage"}|,
229
+
useRefreshTokens: true,
230
+
});
231
+
const user = await auth0.getUser();
232
+
// { sub, email, email_verified, ... }
233
+
\end{lstlisting}
234
+
235
+
\subsection{Handleシステム}
236
+
237
+
HandleはMongoDBの\texttt{@handles}コレクションに保存され、Auth0の\texttt{sub}を1--16文字の英数字文字列（\texttt{.}と\texttt{\_}を許可）にマッピングする。バリデーションは句読点での開始/終了の禁止、大文字小文字を区別しないユニーク性、不適切コンテンツフィルタリングを強制する。HandleはユーザーにとってのプライマリID：URLアクセス可能（\texttt{@handle/piece-name}）、チャットで表示、AC Native OSが読み上げる。
238
+
239
+
\subsection{ATProtoシャドーID}
240
+
241
+
初回メール検証時、Auth0 webhookが\texttt{createAtprotoAccount()}をトリガーし：
242
+
243
+
\begin{enumerate}
244
+
\item 32文字のパスワードを生成
245
+
\item PDS上に招待コードを作成
246
+
\item \texttt{handle.at.aesthetic.computer}上にアカウントを作成
247
+
\item MongoDBにDID、handle、暗号化パスワードを保存（\texttt{users.atproto}）
248
+
\end{enumerate}
249
+
250
+
ユーザーがAC handleを変更すると、\texttt{updateAtprotoHandle()}が変更をPDSに同期する。コンテンツ（ドローイング、ムード、KidLispスニペット、テープ、ニュース）は6つのカスタム語彙（\texttt{computer.aesthetic.*}）を通じてPDSにミラーリングされる。ATProto IDは実在し完全に機能する——しかしユーザーはそれを通じて認証しない。シャドーID：存在し、同期されているが、主権的ではない。
251
+
252
+
\subsection{重複の問題}
253
+
254
+
このアーキテクチャは以下を意味する：
255
+
256
+
\begin{itemize}
257
+
\item 2つの認証情報ストア（Auth0 + PDS）
258
+
\item 2つのhandle名前空間（AC handle + PDS handle）
259
+
\item 2つの同期パス（handle変更の伝播 Auth0 $\to$ MongoDB $\to$ PDS）
260
+
\item 1つの有償依存（Auth0サブスクリプション）
261
+
\item 相互運用性なし（BlueskyユーザーはACに既存IDでログインできない）
262
+
\end{itemize}
263
+
264
+
PDSはすでに各ユーザーが誰かを知っている。すでに彼らのDID、handle、コンテンツを保存している。Auth0レイヤーはPDSが提供できない能力を追加することなく、コストと複雑性を追加している。
265
+
266
+
% ============ 3. AT PROTOCOL IDスタック ============
267
+
268
+
\section{AT Protocol IDスタック}
269
+
\label{sec:atproto}
270
+
271
+
移行を理解するには\atproto{} IDの3つの層を理解する必要がある：DID、handle、OAuth。
272
+
273
+
\subsection{分散型識別子（DID）}
274
+
275
+
DID~\citep{w3cdid2022, atproto2024did}は永続的で暗号的に検証可能な識別子である。\atproto{}は主に\texttt{did:plc}を使用する。これは強い一貫性、高可用性、ID喪失なしの鍵ローテーションのために設計された方式である。各DIDは以下を含むドキュメントに解決される：
276
+
277
+
\begin{itemize}
278
+
\item リポジトリ更新検証用の\textbf{署名鍵}（P-256またはK-256）~\citep{atproto2024crypto}
279
+
\item アカウント回復用の\textbf{ローテーション鍵}
280
+
\item \textbf{PDSエンドポイント}URL
281
+
\item ユーザーの現在の\textbf{handle}
282
+
\end{itemize}
283
+
284
+
DIDは安定したIDである。Handleは変わる。鍵はローテーションする。PDSプロバイダーは去来する。DIDは永続する。ACはすでにPDSを通じて各ユーザーにDIDを鋳造している。インフラはすでに存在する。
285
+
286
+
\subsection{Handle検証}
287
+
288
+
\atproto{} handle~\citep{atproto2024handle}はDIDに双方向で解決されるドメイン名である。検証は2つの方法を使用する：
289
+
290
+
\textbf{DNS TXT}：\texttt{\_atproto.example.com}にレコードを配置：
291
+
\begin{lstlisting}
292
+
_atproto.example.com TXT "did=did:plc:abc..."
293
+
\end{lstlisting}
294
+
295
+
\textbf{HTTPS Well-Known}：以下でDIDを提供：
296
+
\begin{lstlisting}
297
+
GET /.well-known/atproto-did
298
+
Response: did:plc:abc...
299
+
\end{lstlisting}
300
+
301
+
両方の方法でhandleがDIDに解決され、\emph{かつ}DIDドキュメントがそのhandleを宣言することが求められる。この双方向検証は：ドメインを管理していれば、handleを管理できる。handleを割り当てる中央機関は存在しない。DNSが権威である。
302
+
303
+
ACにとってこれは、\texttt{jeffrey.at.aesthetic.computer}がACがDNSとPDSの両方を管理しているため、真正で検証可能なATProto handleであることを意味する。しかしこれは、すでに\texttt{alice.bsky.social}や\texttt{alice.dev}を持っているユーザーが、ACが信頼できる暗号的に検証されたID——パスワード不要——を持っていることも意味する。
304
+
305
+
\subsection{ATProto OAuth}
306
+
307
+
\atproto{} OAuth仕様~\citep{atproto2024oauth}はOAuth 2.1を3つの必須セキュリティメカニズムで拡張する：
308
+
309
+
\textbf{PKCE}（Proof Key for Code Exchange）~\citep{rfc7636pkce}：認可コード傍受を防止する。クライアントはランダムな検証子を生成し、認可リクエストとともにそのハッシュを送信し、トークン交換時に原本の所有を証明する。
310
+
311
+
\textbf{PAR}（Pushed Authorization Requests）~\citep{rfc9126par}：クライアントはユーザーをリダイレクトする\emph{前に}認可パラメータをPOSTで認可サーバーに送信する。リダイレクトURL内のパラメータ改ざんを防止する。
312
+
313
+
\textbf{DPoP}（Demonstrating Proof of Possession）~\citep{rfc9449dpop}：各リクエストに、トークンに関連付けられた秘密鍵の所有を証明する署名JWTが含まれる。アクセストークンが漏洩しても、他のクライアントでは使用できない。
314
+
315
+
\subsubsection{クライアントID}
316
+
317
+
従来のOAuthと異なり、\atproto{}は各認可サーバーへの事前登録を要求しない。代わりにクライアントはパブリックHTTPS URLでメタデータを公開する：
318
+
319
+
\begin{lstlisting}[style=acjsstyle]
320
+
// aesthetic.computer/oauth/client-metadata.json
321
+
{
322
+
|\textcolor{jsstr}{"client\_id"}|: |\textcolor{jsstr}{"https://aesthetic.computer/..."}|,
323
+
|\textcolor{jsstr}{"client\_name"}|: |\textcolor{jsstr}{"Aesthetic Computer"}|,
324
+
|\textcolor{jsstr}{"redirect\_uris"}|: [|\textcolor{jsstr}{"https://..."}|],
325
+
|\textcolor{jsstr}{"grant\_types"}|: [|\textcolor{jsstr}{"authorization\_code"}|],
326
+
|\textcolor{jsstr}{"dpop\_bound\_access\_tokens"}|: true
327
+
}
328
+
\end{lstlisting}
329
+
330
+
任意のPDSがこのURLを取得してクライアントを発見・検証できる。事前共有シークレットなし、アプリストア登録なし、APIキー管理なし。
331
+
332
+
\subsubsection{フロー}
333
+
334
+
\begin{enumerate}
335
+
\item ユーザーがhandleを入力（例：\texttt{alice.bsky.social}）
336
+
\item クライアントが handle $\to$ DID $\to$ PDSエンドポイント $\to$ 認可サーバー を解決
337
+
\item クライアントがPARで認可パラメータをプッシュ
338
+
\item ユーザーがPDSの認可UIにリダイレクトされる
339
+
\item ユーザーが承認；PDSが認可コードとともにリダイレクトバック
340
+
\item クライアントが認可コードをDPoPバインドされたアクセストークンに交換
341
+
\item クライアントが返されたDIDが期待されるIDと一致することを検証
342
+
\end{enumerate}
343
+
344
+
Auth0との主要な違い：ユーザーは\emph{自分のサーバー}で認証する。ACがパスワードを見ることはない。PDS——Blueskyのものであれ、AC自身のものであれ、自己ホスト型インスタンスであれ——がID権威である。
345
+
346
+
% ============ 4. PCKT.BLOGの事例 ============
347
+
348
+
\section{ケーススタディ：pckt.blog}
349
+
\label{sec:pckt}
350
+
351
+
pckt.blog~\citep{pcktblog2025}は\atproto{} OAuthを通じて完全に認証するブログプラットフォームである。その実装はATProtoのみの認証がコンテンツプラットフォームに対して実用的であることを証明している。
352
+
353
+
\subsection{認証}
354
+
355
+
ユーザーはATProto handleを入力してログインする。pckt.blogはhandleを解決し、認可サーバーを発見し、OAuthフローを開始する。ユーザーはPDS上で承認する（Bluesky、Blacksky、自己ホスト型サーバー）。pckt.blogはDPoPバインドされたアクセストークンとユーザーのDIDを受け取る。パスワードは保存されない。別個のユーザーデータベースは維持されない。
356
+
357
+
\subsection{データ主権}
358
+
359
+
コンテンツはStandard.site語彙~\citep{standardsite2025}を使用してユーザー自身のPDSに同期される：
360
+
361
+
\begin{itemize}
362
+
\item \texttt{site.standard.publication} --- ブログコレクション
363
+
\item \texttt{site.standard.document} --- 個別記事
364
+
\item \texttt{site.standard.graph.subscription} --- フォロー関係
365
+
\end{itemize}
366
+
367
+
pckt.blogが消滅しても、ユーザーのコンテンツはPDS上に残り、互換リーダーからアクセス可能である。これがATProtoの約束である：プラットフォームは孤島ではなくビューである。
368
+
369
+
\subsection{ACへの示唆}
370
+
371
+
pckt.blogはコンテンツ指向プラットフォームがATProto IDのみで完全に動作できることを証明した。ACとの類似は直接的である：
372
+
373
+
\begin{itemize}
374
+
\item pckt.blogは記事を公開する；ACは作品、ドローイング、ムードを公開する
375
+
\item pckt.blogはStandard.site語彙を使用する；ACは6つのカスタム\texttt{computer.aesthetic.*}語彙を持つ
376
+
\item pckt.blogのユーザーはPDS上にコンテンツを所有する；ACはすでにPDSにコンテンツをミラーリングしている
377
+
\item 両者ともNode.js/JavaScriptアプリケーションである
378
+
\end{itemize}
379
+
380
+
ギャップは：pckt.blogはATProtoネイティブとして構築されたこと。ACには優雅に移行が必要な既存のAuth0ユーザーベースがあること。
381
+
382
+
% ============ 5. 提案する移行計画 ============
383
+
384
+
\section{提案する移行計画}
385
+
\label{sec:migration}
386
+
387
+
\subsection{フェーズ1：補助ログインとしてのATProto OAuth}
388
+
389
+
Auth0を削除せずに、Auth0の横に「Blueskyでログイン」を追加する。
390
+
391
+
\textbf{インフラ：}
392
+
\begin{enumerate}
393
+
\item \texttt{aesthetic.computer/oauth/client-metadata.json}にクライアントメタデータを公開
394
+
\item バックエンドに\texttt{@atproto/oauth-client-node}~\citep{npmAtprotoOauth}を追加
395
+
\item 2つの新しいNetlify関数を作成：
396
+
\begin{itemize}
397
+
\item \texttt{POST /api/atproto-auth/start} --- handle解決、PAR、リダイレクト
398
+
\item \texttt{GET /api/atproto-auth/callback} --- DPoP付き認可コード交換
399
+
\end{itemize}
400
+
\item セッションをRedisに保存（DID、handle、DPoP鍵ペア、トークン）
401
+
\end{enumerate}
402
+
403
+
\textbf{クライアントフロー：}\texttt{boot.mjs}内の新しい「Blueskyでログイン」ボタンがATProto OAuthフローをトリガーする。成功後、\texttt{window.acUSER}はATProtoセッションから設定される（\texttt{sub}としてのDID、handle、ユーザーが提供しない限りメールなし）。ピースAPI表面は同一——ピースはhandleを持つユーザーを見るのみで、どの認証パスがセッションを作成したかに関わらない。
404
+
405
+
\subsection{フェーズ2：Handleブリッジ}
406
+
407
+
ユーザーがATProto経由でログインしたとき、handleをACにブリッジする：
408
+
409
+
\begin{enumerate}
410
+
\item ATProto handleからユーザー名を抽出（例：\texttt{alice.bsky.social}から\texttt{alice}）
411
+
\item ACの\texttt{@handles}コレクションに対して利用可能性を確認
412
+
\item 利用可能かつ有効（1--16文字、英数字）なら、ワンクリック取得を提供
413
+
\item 取得済みなら、既存所有者のメールが一致するか確認——アカウントリンクを提供
414
+
\item 他の誰かに取得されているなら、代替を選択するよう促す
415
+
\item MongoDBにDID $\leftrightarrow$ AC subマッピングを将来のログイン用に保存
416
+
\end{enumerate}
417
+
418
+
カスタムドメインhandle（例：\texttt{alice.dev}）はドメイン自体が有効なhandle文字列にマッピングされない可能性があるため、ユーザーに手動でAC handleを選択させる必要がある。
419
+
420
+
\subsection{フェーズ3：IDリンク}
421
+
422
+
既存のAuth0ユーザーがATProto IDをリンクできる：
423
+
424
+
\begin{enumerate}
425
+
\item アカウント設定からATProto OAuthを開始
426
+
\item 成功後、外部DIDをAuth0 subとともに保存
427
+
\item 以後のログインは両方の認証パスを受け入れる
428
+
\item コンテンツをオプションでユーザーの外部PDS（AC PDSだけでなく）に同期可能
429
+
\end{enumerate}
430
+
431
+
このフェーズで既存の\texttt{users.atproto}フィールドがシャドーIDから一等のIDリンクに変わる。
432
+
433
+
\subsection{フェーズ4：ATProto優先}
434
+
435
+
移行が検証された後：
436
+
437
+
\begin{enumerate}
438
+
\item 新規登録はデフォルトでATProto OAuth（ACのPDS上にアカウント作成）
439
+
\item Auth0は既存ユーザーのレガシーパスとして残す
440
+
\item ユーザーがATProto IDをリンクするにつれてAuth0を段階的に廃止
441
+
\item Auth0依存を除去し、サブスクリプション費用を排除
442
+
\end{enumerate}
443
+
444
+
\subsection{PDSルーティング}
445
+
446
+
重要なアーキテクチャ上の決定：コンテンツはどこに行くか？
447
+
448
+
\begin{itemize}
449
+
\item \textbf{Auth0のみのユーザー}：コンテンツはACのPDSに同期（現在の動作）
450
+
\item \textbf{外部PDSを持つATProtoユーザー}：コンテンツは\emph{彼らの}PDSに同期
451
+
\item \textbf{AC PDS上のATProtoユーザー}：コンテンツはACのPDSに保持
452
+
\end{itemize}
453
+
454
+
これはバックエンド同期関数（\texttt{media-atproto.mjs}、\texttt{painting-atproto.mjs}等）に条件分岐パスが必要であることを意味する：ユーザーのDIDドキュメントからPDSエンドポイントを解決し、ACのPDSを前提とせずにそのエンドポイントに書き込む。
455
+
456
+
% ============ 6. HANDLEセマンティクス ============
457
+
458
+
\section{Handleセマンティクス}
459
+
\label{sec:handles}
460
+
461
+
HandleはIDスタックの中で人間に最も可視的な部分であり、移行はhandleの\emph{意味}に関する問題を提起する。
462
+
463
+
\subsection{現行のHandleモデル}
464
+
465
+
現在、AC handleは：
466
+
\begin{itemize}
467
+
\item 先着順の1--16文字の文字列
468
+
\item AC名前空間内でユニーク
469
+
\item URL（\texttt{@alice/painting}）、チャット、OS個人化に使用
470
+
\item MongoDBに保存、Redisにキャッシュ
471
+
\item PDSに\texttt{alice.at.aesthetic.computer}としてミラー
472
+
\end{itemize}
473
+
474
+
\subsection{ATProto Handleモデル}
475
+
476
+
ATProto handleは：
477
+
\begin{itemize}
478
+
\item ドメイン名（任意の有効なDNS名）
479
+
\item DIDに双方向で検証
480
+
\item DNS権威によりグローバルにユニーク
481
+
\item サービス間でポータブル
482
+
\end{itemize}
483
+
484
+
\subsection{2つのモデルのブリッジ}
485
+
486
+
提案：AC handleはDIDにマッピングされる\emph{エイリアス}。真実のソースはMongoDBからDIDレイヤーに移行する。複数のログイン方法（Auth0、ATProto OAuth）は同一のDIDに解決され、そのDIDが同一のAC handleに解決される。
487
+
488
+
AC Native OS~\citep{scudder2026os}においてhandleはブートパーティションの\texttt{config.json}に書き込まれている。つまりデバイスIDは暗号的IDによって裏付けられる。ブートスクリーンの「こんにちは @alice」はAliceのDID、Aliceの署名鍵、AliceのポータブルなID——設定ファイル内の単なる文字列ではなく——を意味する。
489
+
490
+
% ============ 7. 未解決の問題 ============
491
+
492
+
\section{未解決の問題}
493
+
\label{sec:questions}
494
+
495
+
\textbf{Handle優先順位。}\texttt{alice}がACで未取得だが、\texttt{alice.bsky.social}がログインした場合、自動的に取得すべきか？先着順はシンプルだがスクワッティングを許す。ATProto検証優先はより公正だが複雑さが増す。
496
+
497
+
\textbf{メール要件。}Auth0は検証済みメールをアカウント回復に提供する。ATProto OAuthはメールを保証しない。ACはフル機能（購入、通知）にメールを要求すべきか？
498
+
499
+
\textbf{マルチテナント。}ACは第2のテナント（\texttt{sotce}）を独立Auth0で運用している。ATProto IDはテナント間でどうマッピングされるか？DIDはテナント非依存であり、クロステナントIDを簡素化しうる。
500
+
501
+
\textbf{セッションサーバー。}リアルタイム機能（チャット、マルチプレイヤー）はWebSocket経由でAuth0トークンを転送して認証する。セッションサーバーはATProto発行のトークンまたは統一セッショントークンを受け入れる必要がある。
502
+
503
+
\textbf{デバイスペアリング。}AC Native OSはAuth0を経由して6文字コードを交換してペアリングする。ATProto同等物：QRコードをスキャンし、電話でOAuthフローを開始し、トークンをデバイスに転送する。
504
+
505
+
\textbf{管理者ID。}管理者は現在\texttt{handle === "jeffrey" \&\& sub === ADMIN\_SUB}。ATProto優先認証下では管理者は\texttt{did === admin\_did}——よりクリーンで、暗号的基盤を持つ。
506
+
507
+
% ============ 8. 関連研究 ============
508
+
509
+
\section{関連研究}
510
+
\label{sec:related}
511
+
512
+
\textbf{分散型ID。}W3C DID仕様~\citep{w3cdid2022}は分散型識別子の公式フレームワークを提供する。AT Protocolの\texttt{did:plc}方式~\citep{atproto2024did}は強い一貫性保証と\texttt{plc.directory}の集中型だが監査可能なディレクトリでこれを拡張する。これは実用的な妥協である：ID解決の完全な分散化は依然として未解決の問題であり、\texttt{did:plc}は運用上の信頼性と引き換えに一部の分散化を犠牲にしている。
513
+
514
+
\textbf{ATProtoネイティブアプリ。}pckt.blog~\citep{pcktblog2025}はブログ機能を実証した。Leaflet.pubとOffprint.appはStandard.site~\citep{standardsite2025}を通じて共有語彙上で連携する。これらのアプリはATProtoのみの認証がコンテンツプラットフォームに対して実行可能であることを証明する。
515
+
516
+
\textbf{OAuthセキュリティ。}DPoP~\citep{rfc9449dpop}はトークン盗難を防止する。PAR~\citep{rfc9126par}はパラメータ改ざんを防止する。PKCE~\citep{rfc7636pkce}は認可コード傍受を防止する。これらを合わせると、ブラウザベースOAuthセキュリティの最新技術を代表する——ACが現在使用しているAuth0 SPAフローよりも大幅に強力である。
517
+
518
+
\textbf{共生的ID。}Illichの共生のためのツール~\citep{illich1973tools}は問題を枠づける：IDシステムは個人の自律を拡張するか、プロバイダーへの依存を要求するか？Auth0はマネージドサービス——便利だが依存的。ATProto IDはポータブルで、自己検証可能で、プロバイダー非依存。Nelsonの個人コンピューティングのビジョン~\citep{nelson1974computerlib}は自然にパーソナルIDに拡張される：ウェブ上の自分の名前は自分が所有すべきである。
519
+
520
+
% ============ 9. 結論 ============
521
+
522
+
\section{結論}
523
+
524
+
Aesthetic Computerはすでにpdを運用し、DIDを鋳造し、コンテンツをATProtoレコードに同期し、カスタム語彙を公開している。唯一欠けている部分は、ユーザーがAuth0を迂回せずにそのインフラを通じて認証できるようにすることである。移行は書き直しではない——回避策の除去である。
525
+
526
+
段階的アプローチ（補助ログインとしてのATProto $\to$ Handleブリッジ $\to$ IDリンク $\to$ ATProto優先）は既存ユーザーに影響を与えないことを保証する。最終状態：handleが暗号的IDであり、コンテンツが自分の管理するサーバーに保存され、ログインが自分の鍵の所有を証明すること——第三者に保証してもらうことではない——を意味するクリエイティブ・コンピューティングプラットフォーム。
527
+
528
+
PDSはすでに稼働している。DIDはすでに鋳造されている。語彙はすでに公開されている。ユーザーが正面玄関からログインする時が来た。
529
+
530
+
% ============ 参考文献 ============
531
+
532
+
\vspace{0.5em}
533
+
\noindent\rule{\columnwidth}{0.5pt}
534
+
535
+
\subsection*{参考リンク}
536
+
537
+
\noindent\small
538
+
539
+
\textbf{AT Protocol仕様：}
540
+
\begin{itemize}
541
+
\item \url{https://atproto.com/specs} --- 完全なプロトコル仕様
542
+
\item \url{https://atproto.com/specs/oauth} --- OAuth仕様
543
+
\item \url{https://atproto.com/specs/handle} --- Handle解決
544
+
\item \url{https://atproto.com/specs/cryptography} --- 暗号方式
545
+
\item \url{https://web.plc.directory/spec/v0.1/did-plc} --- DID PLC仕様
546
+
\item \url{https://atproto.com/guides/lexicon} --- Lexiconスキーマシステム
547
+
\item \url{https://atproto.com/guides/oauth-patterns} --- OAuth実装パターン
548
+
\end{itemize}
549
+
550
+
\textbf{実装ガイド：}
551
+
\begin{itemize}
552
+
\item \url{https://docs.bsky.app/blog/oauth-atproto} --- ATProto OAuthアプリ構築
553
+
\item \url{https://docs.bsky.app/docs/advanced-guides/resolving-identities} --- ID解決
554
+
\item \url{https://docs.bsky.app/docs/advanced-guides/oauth-client} --- OAuthクライアントガイド
555
+
\end{itemize}
556
+
557
+
\textbf{NPMパッケージ：}
558
+
\begin{itemize}
559
+
\item \texttt{@atproto/oauth-client-node} --- Node.js OAuthクライアント
560
+
\item \texttt{@atproto/oauth-client-browser} --- ブラウザOAuthクライアント
561
+
\item \texttt{@atproto/api} --- TypeScript XRPCクライアント
562
+
\item \texttt{@atproto/identity} --- DID/handle解決
563
+
\item \texttt{@atcute/oauth-browser-client} --- 軽量代替
564
+
\end{itemize}
565
+
566
+
\textbf{リファレンス実装：}
567
+
\begin{itemize}
568
+
\item \url{https://github.com/pilcrowonpaper/atproto-oauth-example} --- Astro OAuthサンプル
569
+
\item \url{https://github.com/bluesky-social/atproto} --- ATProto公式モノレポ
570
+
\item \url{https://standard.site/docs/introduction/} --- Standard.site共有語彙
571
+
\end{itemize}
572
+
573
+
\textbf{ATProto Authを使用するアプリ：}
574
+
\begin{itemize}
575
+
\item pckt.blog --- オープンソーシャルウェブ上のブログ
576
+
\item Leaflet.pub --- 長文パブリッシング
577
+
\item Offprint.app --- コラボレーティブ・ライティング
578
+
\end{itemize}
579
+
580
+
\textbf{IETF標準：}
581
+
\begin{itemize}
582
+
\item RFC 9449 --- DPoP (Demonstrating Proof of Possession)
583
+
\item RFC 7636 --- PKCE (Proof Key for Code Exchange)
584
+
\item RFC 9126 --- PAR (Pushed Authorization Requests)
585
+
\end{itemize}
586
+
587
+
\vspace{0.5em}
588
+
589
+
\bibliographystyle{plainnat}
590
+
\bibliography{references}
591
+
592
+
\end{document}
+11
-9
papers/arxiv-kidlisp-cards/kidlisp-cards-cards.tex
+11
-9
papers/arxiv-kidlisp-cards/kidlisp-cards-cards.tex
···
103
103
\thispagestyle{empty}
104
104
\vspace*{\fill}
105
105
\begin{center}
106
-
\includegraphics[height=8em]{pals}\par\vspace{0.3em}
107
-
{\acbold\fontsize{20pt}{24pt}\selectfont\color{acdark} Kid{\color{acpurple}Lisp} Cards}\par
106
+
\includegraphics[height=9em]{pals}\par\vspace{0.1em}
107
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} Kid{\color{acpurple}Lisp} Cards}\par
108
+
\vspace{0.1em}
108
109
\vspace{0.3em}
109
-
\vspace{0.5em}
110
-
{\normalsize\color{cyan!70!blue}\textbf{@jeffrey}}\par
110
+
{\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par
111
111
{\small\color{acgray} Aesthetic.Computer}\par
112
112
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
113
-
\vspace{0.8em}
114
-
\rule{0.6\textwidth}{1pt}\par
115
113
\vspace{0.4em}
116
-
{\small\color{acpink!40}\textit{working draft --- not for citation}}\par
117
-
\vspace{0.3em}
118
-
{\footnotesize\color{acgray} March 2026}\par
114
+
\rule{0.5\textwidth}{0.5pt}\par
115
+
\vspace{0.15em}
116
+
\colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par
117
+
\vspace{0.1em}
118
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/2113ef735}{2113ef735}}\par
119
+
\vspace{0.1em}
120
+
{\footnotesize\color{acgray}\href{https://papers.aesthetic.computer/kidlisp-cards-26-arxiv-da-cards.pdf}{Dansk} · \href{https://papers.aesthetic.computer/kidlisp-cards-26-arxiv-es-cards.pdf}{Español} · \href{https://papers.aesthetic.computer/kidlisp-cards-26-arxiv-zh-cards.pdf}{{\accjk 中文}} · \href{https://papers.aesthetic.computer/kidlisp-cards-26-arxiv-ja-cards.pdf}{{\accjk 日本語}}}\par
119
121
\end{center}
120
122
\vspace*{\fill}
121
123
+564
papers/arxiv-kidlisp-cards/kidlisp-cards-ja.tex
+564
papers/arxiv-kidlisp-cards/kidlisp-cards-ja.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
\usepackage{xeCJK}
11
+
\setCJKmainfont{Droid Sans Japanese}
12
+
13
+
\setmainfont{Latin Modern Roman}
14
+
\setsansfont{Latin Modern Sans}
15
+
16
+
% Custom AC fonts
17
+
\newfontfamily\acbold{ywft-processing-bold}[
18
+
Path=../../system/public/type/webfonts/,
19
+
Extension=.ttf
20
+
]
21
+
\newfontfamily\aclight{ywft-processing-light}[
22
+
Path=../../system/public/type/webfonts/,
23
+
Extension=.ttf
24
+
]
25
+
\newfontfamily\kidlispfont{ComicRelief-Regular}[
26
+
Path=../arxiv-kidlisp/fonts/,
27
+
Extension=.ttf
28
+
]
29
+
\newfontfamily\kidlispbold{ComicRelief-Bold}[
30
+
Path=../arxiv-kidlisp/fonts/,
31
+
Extension=.ttf
32
+
]
33
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
34
+
35
+
% === PACKAGES ===
36
+
\usepackage{xcolor}
37
+
\usepackage{titlesec}
38
+
\usepackage{enumitem}
39
+
\usepackage{booktabs}
40
+
\usepackage{tabularx}
41
+
\usepackage{fancyhdr}
42
+
\usepackage{hyperref}
43
+
\usepackage{graphicx}
44
+
\graphicspath{{figures/}{../arxiv-kidlisp/figures/}}
45
+
\usepackage{ragged2e}
46
+
\usepackage{microtype}
47
+
\usepackage{listings}
48
+
\usepackage{natbib}
49
+
\usepackage[colorspec=0.92]{draftwatermark}
50
+
51
+
% === COLORS (AC palette) ===
52
+
\definecolor{acpink}{RGB}{180,72,135}
53
+
\definecolor{acpurple}{RGB}{120,80,180}
54
+
\definecolor{acdark}{RGB}{64,56,74}
55
+
\definecolor{acgray}{RGB}{119,119,119}
56
+
\definecolor{klbrand}{RGB}{205,92,155}
57
+
\definecolor{klcyan}{RGB}{112,214,255}
58
+
\definecolor{kldark}{RGB}{48,43,58}
59
+
\definecolor{draftcolor}{RGB}{205,92,155}
60
+
61
+
% === DRAFT WATERMARK ===
62
+
\DraftwatermarkOptions{
63
+
text=作業草稿,
64
+
fontsize=3cm,
65
+
color=draftcolor!18,
66
+
angle=45,
67
+
pos={0.5\paperwidth, 0.5\paperheight}
68
+
}
69
+
70
+
% === KIDLISP SYNTAX COLORS ===
71
+
\definecolor{klfn}{RGB}{0,136,170}
72
+
\definecolor{klform}{RGB}{119,51,170}
73
+
\definecolor{klrepeat}{RGB}{170,0,170}
74
+
\definecolor{klnum}{RGB}{204,0,102}
75
+
\definecolor{klstr}{RGB}{170,120,0}
76
+
\definecolor{klcmt}{RGB}{102,102,102}
77
+
\definecolor{klmath}{RGB}{0,136,0}
78
+
\definecolor{klvar}{RGB}{204,102,0}
79
+
\definecolor{klembed}{RGB}{0,136,0}
80
+
81
+
% KidLisp inline color macros
82
+
\newcommand{\kn}[1]{\textcolor{klnum}{#1}}
83
+
\newcommand{\kt}[1]{\textcolor{klstr}{#1}}
84
+
\newcommand{\kv}[1]{\textcolor{klvar}{#1}}
85
+
\newcommand{\ke}[1]{\textcolor{klembed}{\textbf{#1}}}
86
+
\newcommand{\km}[1]{\textcolor{klmath}{#1}}
87
+
88
+
% === HYPERREF ===
89
+
\hypersetup{
90
+
colorlinks=true,
91
+
linkcolor=acpurple,
92
+
urlcolor=acpurple,
93
+
citecolor=acpurple,
94
+
pdfauthor={@jeffrey},
95
+
pdftitle={KidLisp カード：1枚のカードに収まるプログラム},
96
+
}
97
+
98
+
% === SECTION FORMATTING ===
99
+
\titleformat{\section}
100
+
{\normalfont\bfseries\normalsize\uppercase}
101
+
{\thesection.}
102
+
{0.5em}
103
+
{}
104
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
105
+
106
+
\titleformat{\subsection}
107
+
{\normalfont\bfseries\small}
108
+
{\thesubsection}
109
+
{0.5em}
110
+
{}
111
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
112
+
113
+
% === HEADER/FOOTER ===
114
+
\pagestyle{fancy}
115
+
\fancyhf{}
116
+
\renewcommand{\headrulewidth}{0pt}
117
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{作業草稿 --- 引用不可}}
118
+
\fancyfoot[C]{\footnotesize\thepage}
119
+
120
+
% === CUSTOM COMMANDS ===
121
+
\newcommand{\acdot}{{\color{acpink}.}}
122
+
\newcommand{\kidlisp}{\textsc{KidLisp}}
123
+
124
+
% === LISTINGS ===
125
+
\lstdefinelanguage{kidlisp}{
126
+
morekeywords=[1]{wipe,ink,line,box,circle,tri,plot,flood,shape,zoom,scroll,spin,blur,contrast,embed,layer,width,height,frame,time,wiggle,melody,mic,suck,sort,form,trans,cube,move,scale,hop,overtone,resolution,write,text,type,stamp,paste,point,poly,noise,fade,pan,unpan,mask,unmask,flip,crawl,left,right,up,down,goto,face,outline,fill,stroke},
127
+
morekeywords=[2]{def,let,if,cond,once,later,lambda,do},
128
+
morekeywords=[3]{repeat},
129
+
morekeywords=[4]{random,sin,cos,tan,floor,ceil,round,abs,sqrt,min,max},
130
+
sensitive=true,
131
+
morecomment=[l]{;},
132
+
morestring=[b]",
133
+
escapeinside={|}{|},
134
+
}
135
+
\lstset{
136
+
language=kidlisp,
137
+
basicstyle=\ttfamily\small,
138
+
keywordstyle=[1]\color{klfn}\bfseries,
139
+
keywordstyle=[2]\color{klform}\bfseries,
140
+
keywordstyle=[3]\color{klrepeat}\bfseries,
141
+
keywordstyle=[4]\color{klmath},
142
+
commentstyle=\color{klcmt}\itshape,
143
+
stringstyle=\color{klstr},
144
+
breaklines=true,
145
+
frame=single,
146
+
rulecolor=\color{acgray!30},
147
+
backgroundcolor=\color{acgray!5},
148
+
xleftmargin=0.5em,
149
+
xrightmargin=0.5em,
150
+
aboveskip=0.5em,
151
+
belowskip=0.5em,
152
+
}
153
+
154
+
\lstdefinelanguage{python}{
155
+
morekeywords={def,return,import,from,class,if,else,for,in,with,as,try,except,None,True,False,self,and,or,not,lambda,yield,pass,break,continue,raise,while},
156
+
sensitive=true,
157
+
morecomment=[l]{\#},
158
+
morestring=[b]",
159
+
morestring=[b]',
160
+
}
161
+
\lstset{
162
+
language=kidlisp,
163
+
}
164
+
165
+
% === LIST SETTINGS ===
166
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
167
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
168
+
169
+
% === COLUMN SEPARATION ===
170
+
\setlength{\columnsep}{1.8em}
171
+
172
+
% === PARAGRAPH SETTINGS ===
173
+
\setlength{\parindent}{1em}
174
+
\setlength{\parskip}{0.3em}
175
+
176
+
\tolerance=800
177
+
\emergencystretch=1em
178
+
\hyphenpenalty=50
179
+
180
+
\begin{document}
181
+
182
+
% ============ TITLE BLOCK ============
183
+
184
+
\twocolumn[{%
185
+
\begin{center}
186
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
187
+
{\kidlispbold\fontsize{24pt}{28pt}\selectfont\color{kldark} Kid{\color{klbrand}Lisp} カード}\par
188
+
\vspace{0.2em}
189
+
{\kidlispfont\fontsize{11pt}{13pt}\selectfont\color{klbrand} 1枚のカードに収まるプログラム}\par
190
+
\vspace{0.6em}
191
+
{\normalsize @jeffrey}\par
192
+
{\small\color{acgray} Aesthetic\acdot Computer}\par
193
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
194
+
\vspace{0.3em}
195
+
{\small\color{acpurple} \url{https://kidlisp.com} \enspace$\cdot$\enspace \url{https://aesthetic.computer}}\par
196
+
\vspace{0.6em}
197
+
\rule{\textwidth}{1.5pt}
198
+
\vspace{0.5em}
199
+
\end{center}
200
+
201
+
\begin{center}
202
+
{\small\color{acpink}\textbf{[ 作業草稿 --- 引用不可 ]}}
203
+
\end{center}
204
+
\vspace{0.3em}
205
+
206
+
\begin{quote}
207
+
\small\noindent\textbf{要旨。}
208
+
\kidlisp{} のプログラムは短い。典型的なプログラムはわずか2--4行のS式で完全なビジュアル構図を生み出す——スターバースト、螺旋、パッチワーク、フラクタル。この短さは偶然ではなく意図的な設計である。言語がユーザー定義関数、再帰、抽象化メカニズムを省略しているため、プログラムはフラットで可読なままである。このフラットさがプログラムと物理カードの間に自然な対応を生み出すことに気づいた。\kidlisp{} プログラムとそのソースコード、レンダリング出力は1枚の印刷カード上に共存できる。本稿では\emph{KidLisp Cards}フォーマット——ビジュアルカテゴリ別に整理されたプログラムカードのデッキ——と、ブラウザ外でカード画像を生成するPythonレンダリングパイプライン（PILベースのインタプリタ）を記述する。カードが現在何であるか（キュレーションされたビジュアル公案のノートブック）、将来何になりうるか（トレーディングカード、教育シーケンス、印刷スコア、メールアート）、そしてカードの制約が言語設計にどうフィードバックするかを論じる。
209
+
\end{quote}
210
+
\vspace{0.5em}
211
+
}]
212
+
213
+
% ============ 1. はじめに ============
214
+
215
+
\section{はじめに}
216
+
217
+
ほとんどのプログラミング言語は、インデックスカード1枚に印刷するには長すぎるプログラムを生み出す。これは抽象化の帰結である。汎用プログラミング言語はプログラムを関数、クラス、モジュール、ファイルに分解することを促す。プログラムはコードベース全体に散らばる。全体像を捉える単一のアーティファクトは存在しない。
218
+
219
+
\kidlisp{} は異なる。プログラムは通常1--6行である。完全なアニメーションシーン、幾何学パターン、再帰フラクタル、モアレ干渉パターンがわずか数個のS式で済む。これは制限ではなく設計上の選択である。\kidlisp{} はユーザー定義関数、再帰（\texttt{later} を介する場合を除く）、可変データ構造、インポートを省略している。プログラムは描画コマンド、ループ、条件のフラットなシーケンスである。
220
+
221
+
このフラットさが機会を生む。プログラムのソースコードが1枚のカードに収まり、そのプログラムのビジュアル出力も同じカードに収まるなら、カードは自己完結したアーティファクトとなる——手に取り、人に渡し、壁に貼り、郵送できるプログラム。カードは文書であると同時に実行可能である。それは\emph{スコア}——ビジュアルイベントを生成する指示書である。
222
+
223
+
本稿ではKidLisp Cardsフォーマット（\S\ref{sec:format}）、オフラインレンダリングパイプライン（\S\ref{sec:pipeline}）、現在のカードカタログ（\S\ref{sec:catalog}）、レイアウトバリエーションとその社会的・物理的アフォーダンス（\S\ref{sec:layouts}）、フォーマットの投機的未来（\S\ref{sec:futures}）を記述する。
224
+
225
+
% ============ 2. カードフォーマット ============
226
+
227
+
\section{カードフォーマット}
228
+
\label{sec:format}
229
+
230
+
KidLispカードには3つの要素がある：
231
+
232
+
\begin{enumerate}
233
+
\item \textbf{タイトル。}ビジュアル出力のイメージを喚起する短い名前：``Starburst''、``Honeycomb''、``Spiral Walk''。
234
+
\item \textbf{レンダリング出力。}ピクセルアート画像（デフォルト解像度160$\times$120、シャープなエッジを維持するためニアレストネイバー補間で3$\times$拡大）。
235
+
\item \textbf{ソースコード。}完全な \kidlisp{} プログラム、通常1--4行、画像の下に等幅フォントで表示。
236
+
\end{enumerate}
237
+
238
+
カードは自己完結している。ソースコードを読める人なら誰でも、任意の \kidlisp{} インタプリタで画像を正確に再現できる。外部依存なし、インポートなし、設定なし。プログラム\emph{が}カードである。
239
+
240
+
\subsection{カードサイズ}
241
+
242
+
レンダリング画像は160$\times$120ピクセルのキャンバス（4:3比率）を占め、\kidlisp{} のデフォルト解像度と一致する。3$\times$拡大で480$\times$360ピクセルの画像となり、画面表示に適する。印刷用にはカードサイズは4$\times$6インチ（標準インデックスカード/ポストカード）で、画像が上部、ソースコードが下部。
243
+
244
+
\subsection{良いカードとは}
245
+
246
+
すべての \kidlisp{} プログラムが良いカードになるわけではない。最良のカードは以下の特徴を共有する：
247
+
248
+
\begin{itemize}
249
+
\item \textbf{短い。}1--4行。ソースコードが画像の下に快適に収まらなければ、そのプログラムはフォーマットに対して長すぎる。
250
+
\item \textbf{驚き。}出力はソースコードが示唆する以上に複雑または美しくあるべき。モアレパターンを生成する3行のプログラムは注目に値する。
251
+
\item \textbf{可読性。}読者はプログラムを実行せずにソースコードから出力をたどれるべき。コードと画像の結びつきは識別可能であるべき——たとえ即座に明白でなくとも。
252
+
\item \textbf{独立性。}\texttt{\$code} 埋め込みなし、外部状態なし。カードは単独で動作しなければならない。
253
+
\end{itemize}
254
+
255
+
\begin{figure}[t]
256
+
\centering
257
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-starburst.png}}%
258
+
\hfill%
259
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-moire.png}}
260
+
\caption{Pythonインタプリタでレンダリングされた2枚のプログラムカード：``Starburst''（72本の放射状線、3行のコード）と``Moir\'{e}''（重なる同心円、3行）。これらは単純な例であり——カードフォーマットの構造を示すが、言語の表現範囲やフォーマットの野心を代表するものではない。}
261
+
\label{fig:program-cards}
262
+
\end{figure}
263
+
264
+
% ============ 3. レンダリングパイプライン ============
265
+
266
+
\section{オフラインレンダリングパイプライン}
267
+
\label{sec:pipeline}
268
+
269
+
KidLispカードはブラウザ外で動作するPythonインタプリタを使用してレンダリングされる。これにより、完全なAesthetic\acdot Computerランタイムなしで、バッチレンダリング、印刷制作、ノートブックベースのキュレーションが可能となる。
270
+
271
+
\subsection{Pythonインタプリタ}
272
+
273
+
インタプリタ（\texttt{notebooks/ac.py}、452行）は静的カードレンダリングに十分な \kidlisp{} のサブセットを実装する：
274
+
275
+
\begin{itemize}
276
+
\item \textbf{描画：} \texttt{wipe}、\texttt{ink}、\texttt{line}、\texttt{box}、\texttt{circle}、\texttt{tri}、\texttt{plot}、\texttt{shape}、\texttt{flood}
277
+
\item \textbf{タートル：} \texttt{crawl}、\texttt{left}、\texttt{right}、\texttt{goto}、\texttt{face}、\texttt{up}、\texttt{down}
278
+
\item \textbf{制御：} \texttt{repeat}、\texttt{if}、\texttt{def}、\texttt{later}、\texttt{do}
279
+
\item \textbf{数学：}完全な算術、三角関数、\texttt{abs}、\texttt{sqrt}、\texttt{min}、\texttt{max}
280
+
\item \textbf{キャンバス：} \texttt{resolution}、\texttt{fill}、\texttt{outline}、\texttt{stroke}
281
+
\end{itemize}
282
+
283
+
インタプリタはPIL（Pillow）を使用してレンダリングする。各カードはRGBAキャンバス上に描画され、ニアレストネイバー補間で拡大され、PNGとしてエクスポートされる。Python実装はブラウザ評価器（15,161行）より意図的にシンプルである——アニメーション、オーディオ、埋め込み、タイミング構文を省略し、静的ビジュアル出力に必要なサブセットのみに焦点を当てている。
284
+
285
+
\subsection{Jupyter Notebookワークフロー}
286
+
287
+
主要なキュレーションツールはJupyterノートブック（\texttt{notebooks/kidlisp-cards.ipynb}）である。\texttt{show\_card()} 関数がプログラムをレンダリングしHTMLカードとしてインライン表示する：
288
+
289
+
\begin{lstlisting}[language=python,basicstyle=\ttfamily\footnotesize]
290
+
show_card("Starburst", """(wipe black)
291
+
(ink white)
292
+
(repeat 72 i
293
+
(line 80 60
294
+
(+ 80 (* 55 (cos (* i 0.087))))
295
+
(+ 60 (* 55 (sin (* i 0.087))))))""")
296
+
\end{lstlisting}
297
+
298
+
各呼び出しがダークバックグラウンドのカードを生成し、タイトル、レンダリング画像、ソースコードをインライン表示する。ノートブックは開発環境とギャラリーの両方である——ノートブックをスクロールするのはカードデッキをめくるようなものである。
299
+
300
+
\subsection{2つのインタプリタ、1つの言語}
301
+
302
+
2つの独立したインタプリタ（ブラウザのJavaScript、ノートブックのPython）の存在は相互検証として機能する。プログラムが両方で同じレンダリング結果を生む場合、その挙動は実装の詳細ではなく言語の意味論のみによって決定される。ブラウザ固有の機能（アニメーション、オーディオ、埋め込みレイヤー）に依存するプログラムは構造的にカードフォーマットから除外される——Pythonインタプリタではそもそもレンダリングできない。
303
+
304
+
% ============ 4. カードカタログ ============
305
+
306
+
\section{カードカタログ}
307
+
\label{sec:catalog}
308
+
309
+
現在のノートブックには28枚のカードが含まれ、7つのカテゴリに分類されている。各カテゴリは最小限の例を通じて言語の異なる側面を探求する。これらのプログラムは意図的に選ばれたシンプルな練習問題である——描画演習、数学の図解、タートルの散歩。カードフォーマットの構造を確立するが、その表現力の可能性を代表するものではない。興味深いカードはまだ作られていない。フォーマットの価値は、簡潔さを使って表現に値するものを表現するプログラムから生まれるのであり、幾何学的デモンストレーションからではない。
310
+
311
+
\subsection{線}
312
+
313
+
線カードは \texttt{repeat} と三角関数をデモンストレーションする。スターバーストは中心から72本の線を放射する。クロスハッチは低透明度で水平・垂直グリッドを重ねる。
314
+
315
+
\begin{figure}[h]
316
+
\centering
317
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-starburst.png}}%
318
+
\hfill%
319
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-crosshatch.png}}
320
+
\caption{``Starburst'' と ``Crosshatch'' --- 線カード。}
321
+
\label{fig:lines}
322
+
\end{figure}
323
+
324
+
\begin{lstlisting}
325
+
; Starburst — 72 radial lines
326
+
(wipe |\kt{black}|)
327
+
(ink |\kt{white}|)
328
+
(repeat |\kn{72}| |\kv{i}|
329
+
(line |\kn{80}| |\kn{60}|
330
+
(|\km{+}| |\kn{80}| (|\km{*}| |\kn{55}| (|\km{cos}| (|\km{*}| |\kv{i}| |\kn{0.087}|))))
331
+
(|\km{+}| |\kn{60}| (|\km{*}| |\kn{55}| (|\km{sin}| (|\km{*}| |\kv{i}| |\kn{0.087}|))))))
332
+
\end{lstlisting}
333
+
334
+
\subsection{円}
335
+
336
+
円カードは \texttt{outline} モードとネストされた \texttt{repeat} ループを使用する。``Ripple'' は30個の同心円を描き、色が青方向にグラデーションする。
337
+
338
+
\begin{figure}[h]
339
+
\centering
340
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-ripple.png}}%
341
+
\hfill%
342
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-mondrian.png}}
343
+
\caption{``Ripple''（円）と ``Mondrian''（ボックス）。}
344
+
\label{fig:circles-boxes}
345
+
\end{figure}
346
+
347
+
\subsection{ボックスと構図}
348
+
349
+
``Mondrian'' は4つの色付き矩形で原色グリッドを再現する。``Nest'' は10個のネストされた矩形を色相を変化させながら描く。
350
+
351
+
\subsection{数学と曲線}
352
+
353
+
これらのカードは \texttt{plot} と数学関数を使用する。``Lissajous'' は600点でリサジュー図形を描く。``Spiral'' は極座標の螺旋線を描く。
354
+
355
+
\begin{figure}[h]
356
+
\centering
357
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-lissajous.png}}%
358
+
\hfill%
359
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-sierpinski.png}}
360
+
\caption{``Lissajous''（数学曲線）と ``Sierpinski''（ビット演算フラクタル）。}
361
+
\label{fig:math}
362
+
\end{figure}
363
+
364
+
\subsection{色とグラデーション}
365
+
366
+
``Sierpinski'' はビット演算AND操作でシェルピンスキー三角形を生成する：\texttt{(if (= 0 (\& x y)) (plot (+ 16 x) y))}。``Sunflower'' は黄金角の螺旋に沿って500点を色の循環とともに描く。
367
+
368
+
\subsection{タートルグラフィックス}
369
+
370
+
タートルカードは \texttt{crawl}、\texttt{left}、\texttt{right}、\texttt{face} を使用する。五芒星は \texttt{(right 144)} を使う。木は \texttt{later} で再帰的に分岐する。雪の結晶はコッホ曲線セグメントをネストする。
371
+
372
+
\begin{figure}[h]
373
+
\centering
374
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-star.png}}%
375
+
\hfill%
376
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-tree.png}}
377
+
\caption{``Star'' と ``Tree'' --- タートルグラフィックスカード。}
378
+
\label{fig:turtle}
379
+
\end{figure}
380
+
381
+
\begin{lstlisting}
382
+
; Star — 5 sides, 144-degree turns
383
+
(wipe |\kt{navy}|)
384
+
(ink |\kt{yellow}|)
385
+
(repeat |\kn{5}| |\kv{i}| (crawl |\kn{50}|) (right |\kn{144}|))
386
+
\end{lstlisting}
387
+
388
+
\subsection{ミニマル公案}
389
+
390
+
デッキの中で最も短いカード。``Horizon'' は3行：暗い空、金色の大地。``Pip'' は黒の上に赤い一点。これらのカードは最小限のプログラムに接近する——認識可能な画像を生み出すのに必要な最少コード量。
391
+
392
+
\begin{figure}[h]
393
+
\centering
394
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-horizon.png}}%
395
+
\hfill%
396
+
\fbox{\includegraphics[width=0.47\columnwidth]{card-pip.png}}
397
+
\caption{``Horizon'' と ``Pip'' --- ミニマル公案（各2--3行）。}
398
+
\label{fig:koans}
399
+
\end{figure}
400
+
401
+
\begin{lstlisting}
402
+
; Pip — the minimum card
403
+
(wipe |\kt{black}|)
404
+
(ink |\kt{red}|)
405
+
(circle |\kn{80}| |\kn{60}| |\kn{4}|)
406
+
\end{lstlisting}
407
+
408
+
\begin{figure*}[t]
409
+
\centering
410
+
\fbox{\includegraphics[height=5.5cm]{card-nest.png}}%
411
+
\hfill%
412
+
\fbox{\includegraphics[height=5.5cm]{card-sunflower.png}}%
413
+
\hfill%
414
+
\fbox{\includegraphics[height=5.5cm]{card-snowflake.png}}%
415
+
\hfill%
416
+
\fbox{\includegraphics[height=5.5cm]{card-spiral.png}}
417
+
\caption{フォーマットを示す4枚の完全なカード：タイトル、レンダリング出力、ソースコード。左から右へ：``Nest''、``Sunflower''、``Snowflake''、``Spiral''。各カードは自己完結している——画像下のソースコードが完全なプログラムである。これらはシンプルな描画演習であり、フォーマットの潜在力の表現ではない。}
418
+
\label{fig:four-cards}
419
+
\end{figure*}
420
+
421
+
% ============ 5. レイアウト ============
422
+
423
+
\section{レイアウト}
424
+
\label{sec:layouts}
425
+
426
+
カードフォーマットに固定レイアウトはない。3つの要素（タイトル、出力、ソースコード）の配置がカードのアフォーダンス——物理的・社会的に何ができるかを決定する。本節ではレイアウトバリエーションとその帰結を探求する。
427
+
428
+
\begin{figure*}[t]
429
+
\centering
430
+
\includegraphics[width=\textwidth]{layout-comparison.png}
431
+
\caption{3つのレイアウト戦略。\textbf{縦型：}タイトル/画像/ソースコードを上から下に積み重ね、携帯画面と縦型印刷に最適化。\textbf{横型：}画像を左に、タイトルとソースコードを右に配置し、横型カードと並列閲覧に適する。\textbf{ポストカード：}表面にレンダリング出力、裏面にソースコードとメタデータ——裏返すまでプログラムが見えない郵送可能なカード。}
432
+
\label{fig:layouts}
433
+
\end{figure*}
434
+
435
+
\subsection{縦型（画面/印刷）}
436
+
437
+
デフォルトレイアウトはタイトル、画像、ソースコードを上から下に積み重ねる。これはノートブックレイアウト——携帯電話やJupyterノートブックで自然にスクロールできる。印刷用には4$\times$6インチの縦型カードに対応。読者の目は名前から画像、コードへと下に移動し、プログラムとその出力の関係をたどる。
438
+
439
+
\subsection{横型（デッキ/風景）}
440
+
441
+
横型レイアウトはレンダリング画像を左に、ソースコードを右に配置する。テーブルに広げたカード、スライドプレゼンテーション、並列比較に適する。2枚のカードを横に並べるとディプティック——観者がプログラムと出力を同時に比較できる。
442
+
443
+
\subsection{ポストカード（メールアート）}
444
+
445
+
ポストカードレイアウトは表と裏を分離する。表面はレンダリング画像のみ、裁ち落とし、テキストなし。裏面にソースコード、作者クレジット、ショートコード（\texttt{\$xyz}）、切手エリア。受取人はまず画像を見る——ビジュアルアーティファクト。カードを裏返すとプログラムが現れる：それを生成した指示。カードは読む面によってアート作品でもあり実行可能なスコアでもある。
446
+
447
+
\begin{figure*}[h]
448
+
\centering
449
+
\includegraphics[width=\textwidth]{layout-affordances.png}
450
+
\caption{カードフォーマットの社会的・物理的アフォーダンス。各アフォーダンスはカードの物質性に由来する：手渡しで\textbf{共有}、ポストカードとして\textbf{郵送}、\textbf{交換}して収集、教育シーケンスで\textbf{教育に使用}、グラフィックスコアとして\textbf{演奏}、ギャラリーの壁に\textbf{貼る}。}
451
+
\label{fig:affordances}
452
+
\end{figure*}
453
+
454
+
\subsection{デッキ編成}
455
+
456
+
カードは単独のオブジェクトではない。デッキを形成し、デッキの編成が意味を生み出す。\emph{教育シーケンス}はカードを概念順に並べる：まずボックス（座標）、次に線（三角関数）、円（半径と繰り返し）、数学曲線（plotと正弦）、タートルグラフィックス（相対運動）、最後に公案（ミニマルな表現）。\emph{ギャラリーグリッド}はカードを壁面上に空間配置し、カテゴリ間の比較を誘う。\emph{シャッフルデッキ}は順序をランダム化し、フラクタルと地平線の間、木と点の間に予想外の並置を生む。
457
+
458
+
\begin{figure}[h]
459
+
\centering
460
+
\includegraphics[width=\columnwidth]{layout-decks.png}
461
+
\caption{デッキ編成。左：カテゴリ別に展開されたカード（線、円、ボックス、数学、タートル、公案）、各カテゴリに複数のカードが重ねられている。右：閲覧用に空間配置されたギャラリーグリッド。}
462
+
\label{fig:decks}
463
+
\end{figure}
464
+
465
+
% ============ 6. 実際のカード ============
466
+
467
+
\section{実際のカード}
468
+
\label{sec:wild}
469
+
470
+
ノートブックのカードは練習問題である。本当の \kidlisp{} コーパス——59人の作者が作った16,000以上のプログラム——には完全なランタイムを使用する作品が含まれる：アニメーション、オーディオ、埋め込みレイヤー、グラデーションフェード、ランダム配置、タイミング構文。これらの作品はカードフォーマットに収まるほど短いが、ノートブックの例よりはるかに表現力豊かである。プレビュー画像はovenサービス（Puppeteerベースのスクリーンキャプチャ）でレンダリングされ、CDN経由で配信される。
471
+
472
+
\begin{figure*}[t]
473
+
\centering
474
+
\includegraphics[height=7cm]{user-card-bop.png}%
475
+
\hfill%
476
+
\includegraphics[height=7cm]{user-card-roz.png}%
477
+
\hfill%
478
+
\includegraphics[height=7cm]{user-card-cow.png}%
479
+
\hfill%
480
+
\includegraphics[height=7cm]{user-card-r2f.png}
481
+
\caption{\kidlisp{} のアクティブコーパスからの4枚のカード、ovenサービスでレンダリング。左から右へ：\texttt{\$bop}（12,188再生——最も人気のある作品、4行）、\texttt{\$roz}（7,064再生、3行）、\texttt{\$cow}（5,980再生——\texttt{\$39i} と \texttt{\$r2f} を通じて他の2つの作品を埋め込む合成作品）、\texttt{\$r2f}（4,413再生、3行のランダムボックス配置）。すべて@jeffreyの作品。これらのプログラムはPythonインタプリタにはない機能——アニメーション、ランダム性（\texttt{?}）、グラデーションフェード（\texttt{fade:}）、埋め込みレイヤー（\texttt{\$code}）——を使用するが、ソースコードは依然として1枚のカードに収まる。}
482
+
\label{fig:user-cards}
483
+
\end{figure*}
484
+
485
+
\subsection{実作品が加えるもの}
486
+
487
+
ノートブックのカードは \kidlisp{} の静的サブセットを使用する。\texttt{kidlisp.com} 上の実作品は完全なランタイムを使用する：
488
+
489
+
\begin{itemize}
490
+
\item \textbf{アニメーション。}プログラムは毎フレーム再評価される。\texttt{frame} と \texttt{time} が自動変化。シングルフレームのスクリーンショットはアクティブな作品の一瞬を捉える。
491
+
\item \textbf{ランダム性。}\texttt{?} 演算子は毎フレームリストからランダムな値を生成。\texttt{(ink (? red blue green))} は色間をフリッカーする。
492
+
\item \textbf{グラデーションフェード。}\texttt{fade:red-blue-black} はキャンバス上でマルチストップグラデーションを \texttt{frame} カウント駆動で補間。1つの式が何ページもの手動色計算を置き換える。
493
+
\item \textbf{埋め込み。}\texttt{(\$cow)} はMongoDBから作品 \texttt{cow} を取得し、オフスクリーンバッファで評価し、結果を合成。作品が作品の上に構築される。
494
+
\item \textbf{タイミング。}\texttt{1s... (zoom 0.5)} は毎秒ズームを適用。明示的なアニメーションループ不要。
495
+
\end{itemize}
496
+
497
+
これらの機能はプログラムを短く保ちつつ表現力を劇的に拡張する。\texttt{\$bop}——最も再生された作品、12,188回視聴——はわずか4行：紫の背景、虹色に点滅するインク、ランダムな線、ブラー。カード上では動的な絵画のフリーズフレームに見える。ブラウザではまさにそれである。
498
+
499
+
\subsection{スナップショットとしてのカード}
500
+
501
+
アニメーション作品のカードは必然的に不完全である。時間的プロセスの1フレームを捉える。この不完全さはフォーマットの一部である：カードはコードを入力して実際に何をするか見ることを誘う。静止画像は約束。ソースコードは履行。ショートコード（\texttt{\$bop}）は架け橋——\texttt{kidlisp.com} で入力すれば、カードが生き返る。
502
+
503
+
% ============ 7. カードが将来なりうるもの ============
504
+
505
+
\section{カードが将来なりうるもの}
506
+
\label{sec:futures}
507
+
508
+
カードフォーマットはまだ若い。現在のノートブックはコンセプト実証——オフラインレンダリングされた28のプログラム。しかし短いプログラムと物理カードの対応はいくつかの方向を示唆する。
509
+
510
+
\subsection{トレーディングカード}
511
+
512
+
KidLispカードはほとんどのソフトウェアにはないコレクション性を持つ。各カードに名前、ビジュアルアイデンティティ、ショートコード（\texttt{\$xyz}）、作者がある。カードは印刷、番号付け、交換が可能。レアカードは珍しい言語機能を使ったり、最小限のコードから予想外の複雑な出力を生み出したりするかもしれない。カードの「レア度」はその情報密度：何文字からどれだけのビジュアル複雑性が創発するか。
513
+
514
+
\subsection{教育シーケンス}
515
+
516
+
現在のノートブックの7つのカテゴリは教育的順序を示唆する：ボックスから始め（単純な座標）、線（三角関数）、円（半径と繰り返し）、数学曲線（plotと正弦）、タートルグラフィックス（相対運動）、最後に公案（ミニマルな表現）へ進む。各カードが1つの概念を教える。教師は実物のカードデッキを生徒に渡し、各カードを再現したり、修正したり、同じカテゴリで新しいカードを作ったりするよう求めることができる。
517
+
518
+
\subsection{印刷スコア}
519
+
520
+
音楽において、スコアは時間的イベントを生成する指示である。KidLispカードはビジュアルイベントを生成する指示である。カードはグラフィックスコアとして機能しうる——Cornelius Cardew、John Cage、Fluxusイベントスコアの伝統に連なる。演奏者はカードを受け取り、コードを解釈（\texttt{kidlisp.com} で入力、声に出して読む、手で描く）し、イベントを生み出す。カードがスコアであり、レンダリングはその一つの可能な実現である。
521
+
522
+
\subsection{メールアート}
523
+
524
+
4$\times$6インチのKidLispカードはポストカードそのものである。表面にレンダリング画像。裏面にソースコード、作者クレジット、オンラインで見つけるためのショートコード。実行可能な内容を持つメールアート——受取人はコードを入力して自分のスクリーンで画像が再生成されるのを見ることができる。物理カードとデジタルプログラムは同じ作品の2つの媒体である。
525
+
526
+
\subsection{ジェネラティブ文房具}
527
+
528
+
Pythonインタプリタは確定的で独立して動作するため、ネットワークアクセスなしで印刷制作用にカードをバッチレンダリングできる。カードセットは小冊子、独立出版物、ボックスセットとして印刷可能。\texttt{cards-convert.mjs} パイプラインはすでに論文フォーマットから4$\times$6インチPDFカードを生成できる。レンダリングされたプログラム出力とソースコードの両方を含むよう拡張するのは自然な次のステップである。
529
+
530
+
\subsection{生成原理としての制約}
531
+
532
+
カードフォーマットの最も興味深い帰結は、言語へのフィードバック方法である。カードに収まらないプログラムは欠けている抽象化を示唆する——あるいはプログラムがやりすぎていることを示唆する。カード制約は経済性を促す：最も興味深い画像を生む3行のプログラムを見つけよ。これはOulipo的な生成的制約——任意の形式的制限が予想外の創造的結果を生む。
533
+
534
+
% ============ 6. 関連研究 ============
535
+
536
+
\section{関連研究}
537
+
538
+
\textbf{印刷されたコード。}デモシーンの「sizecoding」の伝統（256バイト以下のプログラム）は、最小のプログラムから最大の出力を得る美学と共鳴する。\kidlisp{} カードは「コードポエトリー」の伝統により近い——ソースコード自体がその出力とともにテキストとして読まれる。
539
+
540
+
\textbf{グラフィックスコア。}Cardewの\emph{Treatise}（1967）とCageの\emph{Notations}（1969）は、ビジュアル記法が特定の実現を規定せずに演奏指示として機能しうることを確立した。KidLispカードの違いは完全に実行可能であること——レンダリングは確定的で解釈に開かれていない。しかしカード即スコアのフレームワークは再解釈を誘う：もし毎回異なる方法でカードを「演奏」したら？
541
+
542
+
\textbf{トレーディングカードゲーム。}\emph{Magic: The Gathering}（1993）などのゲームは、構造化されたメタデータ（名前、タイプ、ルールテキスト、イラスト）を持つカードが豊かな組み合わせ空間を生み出すことを実証した。KidLispカードは自然なメタデータ（タイトル、カテゴリ、関数数、行数、出力の複雑さ）を持ち、類似のゲームメカニクスをサポートできる。
543
+
544
+
\textbf{計算ノートブック。}Jupyterノートブックはすでにコードと出力を組み合わせている。KidLisp Cardsノートブックは特定の制約を持つJupyterノートブックである：各セルはより長い計算のステップではなく自己完結したカード。ノートブックはナラティブではなくギャラリーである。
545
+
546
+
% ============ 7. 結論 ============
547
+
548
+
\section{結論}
549
+
550
+
KidLispカードはシンプルな観察に由来する：プログラムが十分に短ければ、カードに収まる。カードフォーマット——タイトル、画像、ソースコード——はプログラムを印刷、郵送、収集、教育、演奏できる物理的アーティファクトに変える。Pythonレンダリングパイプラインがオフラインバッチ制作を可能にする。7カテゴリのカタログが言語へのキュレーションされた入り口を提供する。
551
+
552
+
フォーマットは進行中の作品である。現在の28枚のデッキは出発点であり、完成したコレクションではない。問題は何枚カードを作るかではなく、どのプログラムがカードになる価値があるか——手に取る価値のある画像を生み出す3行の構図はどれか。
553
+
554
+
ノートブック、インタプリタ、カードカタログは \url{https://github.com/whistlegraph/aesthetic-computer} で入手可能。プログラムは \url{https://kidlisp.com} で作成・共有できる。
555
+
556
+
\vspace{0.5em}
557
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
558
+
559
+
% ============ 参考文献 ============
560
+
561
+
\bibliographystyle{plainnat}
562
+
\bibliography{references}
563
+
564
+
\end{document}
+11
-9
papers/arxiv-kidlisp-reference/kidlisp-reference-cards.tex
+11
-9
papers/arxiv-kidlisp-reference/kidlisp-reference-cards.tex
···
101
101
\thispagestyle{empty}
102
102
\vspace*{\fill}
103
103
\begin{center}
104
-
\includegraphics[height=8em]{pals}\par\vspace{0.3em}
105
-
{\acbold\fontsize{20pt}{24pt}\selectfont\color{acdark} KidLisp Language Reference}\par
104
+
\includegraphics[height=9em]{pals}\par\vspace{0.1em}
105
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} KidLisp Language Reference}\par
106
+
\vspace{0.1em}
106
107
\vspace{0.3em}
107
-
\vspace{0.5em}
108
-
{\normalsize\color{cyan!70!blue}\textbf{@jeffrey}}\par
108
+
{\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par
109
109
{\small\color{acgray} Aesthetic.Computer}\par
110
110
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
111
-
\vspace{0.8em}
112
-
\rule{0.6\textwidth}{1pt}\par
113
111
\vspace{0.4em}
114
-
{\small\color{acpink!40}\textit{working draft --- not for citation}}\par
115
-
\vspace{0.3em}
116
-
{\footnotesize\color{acgray} March 2026}\par
112
+
\rule{0.5\textwidth}{0.5pt}\par
113
+
\vspace{0.15em}
114
+
\colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par
115
+
\vspace{0.1em}
116
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/2113ef735}{2113ef735}}\par
117
+
\vspace{0.1em}
118
+
{\footnotesize\color{acgray}\href{https://papers.aesthetic.computer/kidlisp-reference-26-arxiv-da-cards.pdf}{Dansk} · \href{https://papers.aesthetic.computer/kidlisp-reference-26-arxiv-es-cards.pdf}{Español} · \href{https://papers.aesthetic.computer/kidlisp-reference-26-arxiv-zh-cards.pdf}{{\accjk 中文}} · \href{https://papers.aesthetic.computer/kidlisp-reference-26-arxiv-ja-cards.pdf}{{\accjk 日本語}}}\par
117
119
\end{center}
118
120
\vspace*{\fill}
119
121
+530
papers/arxiv-kidlisp-reference/kidlisp-reference-ja.tex
+530
papers/arxiv-kidlisp-reference/kidlisp-reference-ja.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
5
+
\usepackage{fontspec}
6
+
\usepackage{unicode-math}
7
+
\setmainfont{Latin Modern Roman}
8
+
\setsansfont{Latin Modern Sans}
9
+
\newfontfamily\acbold{ywft-processing-bold}[Path=../../system/public/type/webfonts/,Extension=.ttf]
10
+
\newfontfamily\aclight{ywft-processing-light}[Path=../../system/public/type/webfonts/,Extension=.ttf]
11
+
\newfontfamily\kidlispfont{ComicRelief-Regular}[
12
+
Path=../arxiv-kidlisp/fonts/,
13
+
Extension=.ttf
14
+
]
15
+
\newfontfamily\kidlispbold{ComicRelief-Bold}[
16
+
Path=../arxiv-kidlisp/fonts/,
17
+
Extension=.ttf
18
+
]
19
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
20
+
21
+
\usepackage{xeCJK}
22
+
\setCJKmainfont{Droid Sans Japanese}
23
+
\setCJKsansfont{Droid Sans Japanese}
24
+
\setCJKmonofont{Droid Sans Japanese}
25
+
26
+
\usepackage{xcolor}
27
+
\usepackage{titlesec}
28
+
\usepackage{enumitem}
29
+
\usepackage{booktabs}
30
+
\usepackage{tabularx}
31
+
\usepackage{multicol}
32
+
\usepackage{fancyhdr}
33
+
\usepackage{hyperref}
34
+
\usepackage{graphicx}
35
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
36
+
\usepackage{ragged2e}
37
+
\usepackage{microtype}
38
+
\usepackage{listings}
39
+
\usepackage{natbib}
40
+
\usepackage[colorspec=0.92]{draftwatermark}
41
+
42
+
% === COLORS ===
43
+
\definecolor{acpink}{RGB}{180,72,135}
44
+
\definecolor{acpurple}{RGB}{120,80,180}
45
+
\definecolor{acdark}{RGB}{64,56,74}
46
+
\definecolor{acgray}{RGB}{119,119,119}
47
+
\definecolor{klbrand}{RGB}{205,92,155} % kidlisp.com primary (--ac-purple)
48
+
\definecolor{klcyan}{RGB}{112,214,255} % kidlisp.com ".com" cyan (#70D6FF)
49
+
\definecolor{kldark}{RGB}{48,43,58} % kidlisp.com dark purple
50
+
\definecolor{draftcolor}{RGB}{205,92,155}
51
+
52
+
% KidLisp syntax colors
53
+
\definecolor{klparen}{RGB}{140,140,160}
54
+
\definecolor{klkw}{RGB}{119,51,170}
55
+
\definecolor{klfn}{RGB}{0,136,170}
56
+
\definecolor{klcolor}{RGB}{204,80,0}
57
+
\definecolor{klnum}{RGB}{204,0,102}
58
+
\definecolor{klstr}{RGB}{44,145,44}
59
+
\definecolor{klcmt}{RGB}{140,140,140}
60
+
\definecolor{klvar}{RGB}{50,50,50}
61
+
\definecolor{klspecial}{RGB}{180,72,135}
62
+
\definecolor{klbg}{RGB}{250,248,252}
63
+
64
+
\DraftwatermarkOptions{text=WORKING DRAFT,fontsize=3cm,color=draftcolor!18,angle=45}
65
+
66
+
\hypersetup{colorlinks=true,linkcolor=acpurple,urlcolor=acpurple,citecolor=acpurple,
67
+
pdftitle={KidLisp 言語リファレンス：12カテゴリ118個の組み込み関数}}
68
+
69
+
\titleformat{\section}{\normalfont\bfseries\normalsize\uppercase}{\thesection.}{0.5em}{}
70
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
71
+
\titleformat{\subsection}{\normalfont\bfseries\small}{\thesubsection}{0.5em}{}
72
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
73
+
74
+
\pagestyle{fancy}\fancyhf{}
75
+
\renewcommand{\headrulewidth}{0pt}
76
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{作業草稿 --- 引用不可}}
77
+
\fancyfoot[C]{\footnotesize\thepage}
78
+
79
+
\newcommand{\ac}{\textsc{Aesthetic.Computer}}
80
+
\newcommand{\kl}{\textsc{KidLisp}}
81
+
82
+
% === KIDLISP LISTING STYLE ===
83
+
\lstdefinelanguage{kidlisp}{
84
+
morekeywords=[1]{def,if,repeat,once,later,die,let,do,fn},
85
+
morekeywords=[2]{wipe,ink,line,box,circle,tri,plot,flood,shape,write,type,paste,print},
86
+
morekeywords=[3]{scroll,zoom,spin,blur,contrast,suck,pan,sort,resetSpin,smoothspin,unpan,fill,outline,stroke,nofill,nostroke},
87
+
morekeywords=[4]{random,wiggle,sin,cos,tan,floor,ceil,round,abs,sqrt,min,max,mod},
88
+
morekeywords=[5]{width,height,frame,time,resolution,fps,screen,pen,hand,gamepad,mic,amplitude},
89
+
morekeywords=[6]{cube,form,trans,move,scale,hop,delay,jump,melody,overtone,speaker,sound},
90
+
morekeywords=[7]{embed,layer,fade,bake,list,get,set,tap},
91
+
sensitive=true,
92
+
morecomment=[l]{;},
93
+
morestring=[b]",
94
+
literate=
95
+
{(}{{{\color{klparen}(}}}1
96
+
{)}{{{\color{klparen})}}}1
97
+
{\$}{{{\color{klspecial}\$}}}1,
98
+
}
99
+
100
+
\lstdefinestyle{kidlispstyle}{
101
+
language=kidlisp,
102
+
basicstyle=\ttfamily\small,
103
+
keywordstyle=[1]\color{klkw}\bfseries,
104
+
keywordstyle=[2]\color{klfn}\bfseries,
105
+
keywordstyle=[3]\color{acpurple},
106
+
keywordstyle=[4]\color{klnum},
107
+
keywordstyle=[5]\color{klspecial},
108
+
keywordstyle=[6]\color{klfn},
109
+
keywordstyle=[7]\color{acpink},
110
+
commentstyle=\color{klcmt}\itshape,
111
+
stringstyle=\color{klstr},
112
+
numberstyle=\tiny\color{klcmt},
113
+
breaklines=true,
114
+
frame=single,
115
+
rulecolor=\color{acgray!30},
116
+
backgroundcolor=\color{klbg},
117
+
xleftmargin=0.5em,
118
+
xrightmargin=0.5em,
119
+
aboveskip=0.5em,
120
+
belowskip=0.5em,
121
+
showstringspaces=false,
122
+
}
123
+
124
+
\lstset{style=kidlispstyle}
125
+
126
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
127
+
\setlength{\columnsep}{1.8em}
128
+
\setlength{\parindent}{1em}
129
+
\setlength{\parskip}{0.3em}
130
+
131
+
% Hyphenation for narrow two-column layout
132
+
\tolerance=800
133
+
\emergencystretch=1em
134
+
\hyphenpenalty=50
135
+
136
+
\begin{document}
137
+
138
+
\twocolumn[{%
139
+
\begin{center}
140
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
141
+
{\kidlispbold\fontsize{26pt}{30pt}\selectfont\color{kldark} Kid{\color{klbrand}Lisp} 言語リファレンス}\par
142
+
\vspace{0.2em}
143
+
{\kidlispfont\fontsize{11pt}{13pt}\selectfont\color{klbrand} 12カテゴリ118個のジェネラティブアート組み込み関数}\par
144
+
\vspace{0.3em}
145
+
{\kidlispfont\fontsize{9pt}{11pt}\selectfont\color{acgray} 構文、意味論、タイミング、色彩、\texttt{\$}-Code合成システム}\par
146
+
\vspace{0.6em}
147
+
{\normalsize @jeffrey}\par
148
+
{\small\color{acgray} Aesthetic.Computer}\par
149
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
150
+
\vspace{0.3em}
151
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
152
+
\vspace{0.6em}
153
+
\rule{\textwidth}{1.5pt}
154
+
\vspace{0.5em}
155
+
\end{center}
156
+
157
+
\begin{center}
158
+
{\small\color{acpink}\textbf{[ 作業草稿 --- 引用不可 ]}}
159
+
\end{center}
160
+
\vspace{0.3em}
161
+
162
+
\begin{quote}
163
+
\small\noindent\textbf{要旨。}
164
+
\kl{} はジェネラティブアートのための極小Lisp方言であり、12カテゴリにわたる118個の組み込み関数を持ち、ユーザー定義関数なし、再帰なし、ファイルI/Oなし、ネットワークアクセスなしという設計である。設計上安全であり、\kl{} プログラムはサンドボックスを突破できず、ホストをクラッシュさせることもできず、キャンバス以外のリソースにアクセスすることもできない。本稿は完全な言語リファレンスとして、構文ハイライト付きの例で各組み込み関数を文書化する。タイミングシステム（コールバック不要のフレームベースおよび秒ベースのスケジューリング）、色彩モデル（名前付き色、RGB、グラデーション、パターン）、\texttt{\$}-code合成システム（主要な抽象化メカニズムとして参照によりプログラムを埋め込む）、評価モデル（確定的擬似乱数生成器を用いて毎フレームAST全体を再評価）を扱う。\kl{} は\emph{省略}を中心に設計された言語として提示する。何ができないかは何ができるかと同じく慎重に設計されており、その制約が創作空間を生み出し、59人の作者がこれまでに16,634のプログラムを書いている。
165
+
\end{quote}
166
+
\vspace{0.5em}
167
+
}]
168
+
169
+
\section{構文}
170
+
171
+
\kl{} はS式構文を使用する~\citep{mccarthy1960recursive}。各式はアトム（数値、文字列、シンボル）またはリスト（括弧で囲まれた式）である：
172
+
173
+
\begin{lstlisting}
174
+
; Atoms
175
+
42 ; number
176
+
"hello" ; string
177
+
red ; symbol (color name)
178
+
179
+
; Lists (function application)
180
+
(wipe "navy") ; clear screen navy
181
+
(ink "red") ; set drawing color
182
+
(box 10 10 50 50) ; draw rectangle
183
+
(circle 64 64 30) ; draw circle
184
+
\end{lstlisting}
185
+
186
+
演算子なし、中置記法なし、括弧・文字列・数値・シンボル以外の特殊構文なし。算術は前置記法を使用する：
187
+
188
+
\begin{lstlisting}
189
+
(+ 1 2) ; => 3
190
+
(* 3 (+ 1 2)) ; => 9
191
+
(- 10 3) ; => 7
192
+
(/ 100 4) ; => 25
193
+
(% 17 5) ; => 2 (modulo)
194
+
\end{lstlisting}
195
+
196
+
\section{12のカテゴリ}
197
+
198
+
\subsection{グラフィックス（9関数）}
199
+
200
+
描画プリミティブは即時モードで動作する——各呼び出しがフレームバッファに直接レンダリングされる。
201
+
202
+
\begin{lstlisting}
203
+
(wipe "black") ; clear canvas
204
+
(ink "cyan") ; set color
205
+
(line 0 0 128 128) ; diagonal line
206
+
(box 10 10 40 40) ; rectangle
207
+
(circle 64 64 20) ; circle at center
208
+
(tri 32 10 10 54 54 54) ; triangle
209
+
(plot 64 64) ; single pixel
210
+
(flood 64 64) ; flood fill
211
+
(shape 10 10 50 10 30 50) ; polygon
212
+
\end{lstlisting}
213
+
214
+
\texttt{fill} と \texttt{outline} は図形を塗りつぶすか輪郭のみにするかを制御する（Processing互換）：
215
+
216
+
\begin{lstlisting}
217
+
(fill) ; filled shapes
218
+
(ink "red")
219
+
(circle 64 64 30) ; solid red circle
220
+
221
+
(outline) ; outlined shapes
222
+
(ink "white")
223
+
(circle 64 64 30) ; white ring
224
+
\end{lstlisting}
225
+
226
+
\subsection{変換（11関数）}
227
+
228
+
ピクセルレベルの変換は描画後にフレームバッファに作用する：
229
+
230
+
\begin{lstlisting}
231
+
(scroll 1 0) ; shift pixels right
232
+
(zoom 1.01) ; slow zoom in
233
+
(spin 1) ; rotate 1 degree
234
+
(blur 2) ; gaussian blur
235
+
(contrast 1.2) ; increase contrast
236
+
(suck 0.5) ; radial displacement
237
+
(sort) ; sort pixels by brightness
238
+
\end{lstlisting}
239
+
240
+
変換はフレーム間で\emph{累積}し、明示的な状態管理なしにアニメーションを生み出す：
241
+
242
+
\begin{lstlisting}
243
+
(wipe "black")
244
+
(ink "white")
245
+
(circle 64 64 10) ; draw circle
246
+
(spin 2) ; rotate 2 deg/frame
247
+
(zoom 1.005) ; grow slightly/frame
248
+
; Result: spiraling, growing circle
249
+
\end{lstlisting}
250
+
251
+
\subsection{数学（14関数）}
252
+
253
+
\begin{lstlisting}
254
+
(sin (* frame 0.05)) ; sine wave
255
+
(cos (* frame 0.03)) ; cosine wave
256
+
(random) ; 0-255
257
+
(random 10) ; 0-9
258
+
(random 5 15) ; 5-14
259
+
(wiggle 10) ; random +/-5
260
+
(floor 3.7) ; => 3
261
+
(abs -5) ; => 5
262
+
(sqrt 16) ; => 4
263
+
(min 3 7 1) ; => 1
264
+
(max 3 7 1) ; => 7
265
+
\end{lstlisting}
266
+
267
+
\texttt{random} はプログラムのショートコードで初期化されたシード擬似乱数生成器を使用し、すべての生成出力を\textbf{確定的}にする。同じプログラムは常に同じ視覚的結果を生成する。
268
+
269
+
\subsection{色彩（19以上の名前付き色）}
270
+
271
+
色は名前、RGB値、またはグラデーション文字列で指定できる：
272
+
273
+
\begin{lstlisting}
274
+
(ink "red") ; named color
275
+
(ink 255 0 0) ; RGB
276
+
(ink 255 0 0 128) ; RGBA (semi-transparent)
277
+
(ink "fade:red-blue") ; horizontal gradient
278
+
(ink (fade "cyan" "magenta" "vertical"))
279
+
(ink "rainbow") ; repeating rainbow
280
+
(ink "zebra") ; striped pattern
281
+
\end{lstlisting}
282
+
283
+
利用可能な色名にはすべてのCSS名前付き色が含まれる：\texttt{red}、\texttt{green}、\texttt{blue}、\texttt{yellow}、\texttt{orange}、\texttt{purple}、\texttt{pink}、\texttt{cyan}、\texttt{magenta}、\texttt{black}、\texttt{white}、\texttt{gray}、\texttt{brown}、\texttt{lime}、\texttt{navy}、\texttt{teal}、\texttt{gold}、\texttt{coral}、\texttt{salmon}、\texttt{crimson}、\texttt{lavender}、\texttt{indigo}、\texttt{violet}、\texttt{turquoise}、\texttt{tomato}など。
284
+
285
+
1行目に裸の色名を置くと背景色が設定される：
286
+
287
+
\begin{lstlisting}
288
+
"navy"
289
+
(ink "gold")
290
+
(circle 64 64 30)
291
+
; Navy background, gold circle
292
+
\end{lstlisting}
293
+
294
+
\subsection{システムとディスプレイ（9関数）}
295
+
296
+
\begin{lstlisting}
297
+
(def w width) ; screen width
298
+
(def h height) ; screen height
299
+
frame ; current frame number
300
+
time ; seconds elapsed
301
+
302
+
(resolution "half") ; half-resolution
303
+
(resolution 64 64) ; explicit 64x64
304
+
(fps 30) ; set frame rate
305
+
\end{lstlisting}
306
+
307
+
\subsection{制御フロー（7関数）}
308
+
309
+
\begin{lstlisting}
310
+
; Variable definition
311
+
(def x 50)
312
+
(def y (+ 10 (* frame 0.5)))
313
+
314
+
; Conditional
315
+
(if (> frame 60)
316
+
(ink "red")
317
+
(ink "blue"))
318
+
319
+
; Loop
320
+
(repeat 10 i
321
+
(circle (* i 12) 64 5))
322
+
323
+
; Execute once (not every frame)
324
+
(once (wipe "black"))
325
+
326
+
; Local binding
327
+
(let ((cx 64) (cy 64))
328
+
(circle cx cy 30))
329
+
\end{lstlisting}
330
+
331
+
\texttt{repeat} ループはカウンタ変数（上記の \texttt{i}）を0から$n-1$まで束縛する。ネストされたrepeatは異なる変数名を使用する：
332
+
333
+
\begin{lstlisting}
334
+
(repeat 8 i
335
+
(repeat 8 j
336
+
(box (* i 16) (* j 16) 14 14)))
337
+
; 8x8 grid of squares
338
+
\end{lstlisting}
339
+
340
+
\subsection{タイミング}
341
+
342
+
\kl{} のタイミングシステムはコールバックではなく\emph{インラインスケジューリング}を使用する。タイミング式はコードブロックをラップする：
343
+
344
+
\begin{lstlisting}
345
+
; Frame-based timing
346
+
(0 (wipe "black")) ; every frame
347
+
(1 (spin 5)) ; every 2nd frame
348
+
(30f (ink "red")) ; after 30 frames
349
+
350
+
; Second-based timing
351
+
(1s (wipe "red")) ; after 1 second
352
+
(2.5s (ink "gold")) ; after 2.5 seconds
353
+
(1s! (write "!" 10 10)) ; fire once at 1s
354
+
355
+
; Repeating intervals
356
+
(0.5s... (spin 45)) ; every 0.5 seconds
357
+
(1s... (scroll 1 0)) ; every second
358
+
\end{lstlisting}
359
+
360
+
これにより \texttt{setTimeout}、\texttt{setInterval}、アニメーションフレームコールバックの必要性が排除される。時間は式の\emph{属性}であり、呼び出される関数ではない。
361
+
362
+
\subsection{テキスト（4関数）}
363
+
364
+
\begin{lstlisting}
365
+
(write "hello" 10 20) ; text at position
366
+
(write "centered" ; centered text
367
+
(/ width 2) (/ height 2))
368
+
(type "typed" 10 10) ; typewriter effect
369
+
\end{lstlisting}
370
+
371
+
\subsection{入力（3関数）}
372
+
373
+
\begin{lstlisting}
374
+
; Pen/mouse position and state
375
+
(if pen
376
+
(circle pen.x pen.y 5))
377
+
378
+
; Touch input
379
+
(if hand
380
+
(line hand.x hand.y 64 64))
381
+
\end{lstlisting}
382
+
383
+
\subsection{オーディオ（6関数）}
384
+
385
+
\begin{lstlisting}
386
+
; Microphone input
387
+
(def vol (mic)) ; amplitude 0-255
388
+
(circle 64 64 vol) ; sound-reactive
389
+
390
+
; Melody playback
391
+
(melody "C4 E4 G4 C5")
392
+
393
+
; Overtone harmonics
394
+
(overtone 440 3) ; 3rd harmonic of A4
395
+
\end{lstlisting}
396
+
397
+
\subsection{3Dグラフィックス（8関数）}
398
+
399
+
\begin{lstlisting}
400
+
(cube "mycube") ; create 3D cube
401
+
(form "mycube"
402
+
(move 0 0 -5) ; position
403
+
(scale 2) ; size
404
+
(spin (* frame 0.5) 1 1 0)) ; rotate
405
+
\end{lstlisting}
406
+
407
+
\subsection{\texttt{\$}-Codeによる合成}
408
+
409
+
\kl{} 最大の特徴はその合成システムである。プログラムはユーザー定義関数を使用せず、ショートコードで他のプログラムを参照する：
410
+
411
+
\begin{lstlisting}
412
+
; Embed another program as a layer
413
+
($cow) ; execute program "cow"
414
+
($nece 10 20) ; pass parameters
415
+
416
+
; Multi-layer composition
417
+
(wipe "black")
418
+
($cow) ; background layer
419
+
($faim) ; foreground layer
420
+
421
+
; Chain multiple programs
422
+
(resolution 64 64)
423
+
($zobi)
424
+
(spin 1)
425
+
($grel)
426
+
\end{lstlisting}
427
+
428
+
プログラムはMongoDBから取得され、RAMとIndexedDBにキャッシュされ、SHA-256でコンテンツアドレッシングされる。\texttt{\$}-codeシステムはユーザー定義関数、モジュール、ライブラリを単一のソーシャルメカニズムに置き換える：\emph{誰かが作ったプログラムを見つけ、コードで参照し、合成する}。
429
+
430
+
最も多く参照されるプログラムは単純な視覚プリミティブであり、構成要素として機能する。このシステムはソーシャル依存グラフを生成する。プログラムAがプログラムBを埋め込み、プログラムBがプログラムCを埋め込む——観察された使用では最大7層の深さに達する。
431
+
432
+
\section{評価モデル}
433
+
434
+
\kl{} は\textbf{毎フレームAST全体を再評価する}。明示的に定義された変数以外に保持される状態はない。\texttt{frame} と \texttt{time} 変数は自動的にインクリメントされる。\texttt{zoom}、\texttt{scroll}、\texttt{spin} などの変換はフレームバッファに累積される。
435
+
436
+
このモデルはProcessing~\citep{reas2007processing}でよく見られる \texttt{setup()}/\texttt{draw()} の分離を排除する。\kl{} プログラムの各行は毎フレーム実行される。アニメーションはフレーム依存式から生まれる：
437
+
438
+
\begin{lstlisting}
439
+
(wipe "black")
440
+
(ink "white")
441
+
; Circle orbits center using sin/cos
442
+
(circle
443
+
(+ 64 (* 30 (cos (* frame 0.03))))
444
+
(+ 64 (* 30 (sin (* frame 0.03))))
445
+
8)
446
+
\end{lstlisting}
447
+
448
+
\subsection{確定的ランダム性}
449
+
450
+
\texttt{random} のシードはプログラムのショートコードに由来する。同じプログラムは、どのデバイスでも、毎回同じ出力を生成する。これにより \kl{} プログラムは\emph{再現可能なジェネラティブアート}となる。コードが作品\emph{そのもの}であり、それを生成するための命令にとどまらない。
451
+
452
+
\subsection{カオスモード}
453
+
454
+
無効な入力——意味不明な文字列、不一致の括弧、ランダムな文字——はエラーメッセージを生成しない。代わりに \kl{} は低認識率（既知語彙の$<30\%$）と高特殊文字率（$>50\%$）を検出し、芸術的な視覚出力をレンダリングする。ユーザーは決して「SyntaxError」を見ることがない。色彩が表示される。
455
+
456
+
\section{省略による設計}
457
+
458
+
\kl{} が意図的に持たないもの：
459
+
460
+
\begin{itemize}
461
+
\item \textbf{ユーザー定義関数}：\texttt{\$}-code合成で代替
462
+
\item \textbf{再帰}：無限ループとスタックオーバーフローを防止
463
+
\item \textbf{ファイルI/O}：キャンバスが唯一の出力
464
+
\item \textbf{ネットワーク}：プログラムは外部データを取得できない
465
+
\item \textbf{文字列操作}：\texttt{concat}、\texttt{split}、\texttt{replace}なし
466
+
\item \textbf{エラーメッセージ}：カオスモードで代替
467
+
\item \textbf{Import/require}：\texttt{\$}-codeで代替
468
+
\item \textbf{オブジェクト/クラス}：データは数値、文字列、リストのみ
469
+
\end{itemize}
470
+
471
+
各省略は設計上の決定である。ユーザー定義関数がないことにより、ソーシャルレイヤーを通じた合成が促される。エラーメッセージがないことにより、初心者は赤いエラーテキストの画面に遭遇しない。ネットワークがないことにより、各プログラムは自己完結的で安全に実行できる。
472
+
473
+
これは次の原則に従う。言語の制約はその機能と同様に創作空間を定義する~\citep{papert1980mindstorms, compton2015casual}。\kl{} はたまたまアートもできる汎用言語ではない。アート\emph{以外}のことができない芸術言語である。
474
+
475
+
\section{組み込み関数の完全索引}
476
+
477
+
\begin{table}[h]
478
+
\small
479
+
\centering
480
+
\begin{tabularx}{\columnwidth}{Xlr}
481
+
\toprule
482
+
\textbf{カテゴリ} & \textbf{数} & \textbf{主要関数} \\
483
+
\midrule
484
+
グラフィックス & 9 & wipe, ink, line, box, circle \\
485
+
変換 & 11 & scroll, zoom, spin, blur, suck \\
486
+
数学 & 14 & +, -, *, /, random, sin, cos \\
487
+
色彩 & 19+ & red, blue, fade, rainbow, zebra \\
488
+
システム/ディスプレイ & 9 & width, height, frame, time \\
489
+
制御フロー & 7 & def, if, repeat, once, let \\
490
+
テキスト/出力 & 4 & write, type, paste, print \\
491
+
入力 & 3 & pen, hand, gamepad \\
492
+
オーディオ & 6 & mic, melody, overtone, sound \\
493
+
3Dグラフィックス & 8 & cube, form, trans, move, scale \\
494
+
合成 & 4 & \$code, layer, bake, embed \\
495
+
データ & 4 & list, get, set, let \\
496
+
\midrule
497
+
\textbf{合計} & \textbf{118} & \\
498
+
\bottomrule
499
+
\end{tabularx}
500
+
\caption{カテゴリ別の全118組み込み関数。}
501
+
\label{tab:builtins}
502
+
\end{table}
503
+
504
+
\section{例：完全なプログラム}
505
+
506
+
軌道運動する音響反応パーティクルフィールドを描画する完全な \kl{} プログラム：
507
+
508
+
\begin{lstlisting}
509
+
"black"
510
+
(def vol (+ 5 (* (mic) 0.2)))
511
+
(repeat 50 i
512
+
(def angle (* i 0.1256))
513
+
(def r (+ 20 (* vol (sin (+ (* frame 0.02) angle)))))
514
+
(def cx (+ 64 (* r (cos (+ angle (* frame 0.01))))))
515
+
(def cy (+ 64 (* r (sin (+ angle (* frame 0.01))))))
516
+
(ink (+ 100 (* i 3)) 50 (+ 150 (* i 2)))
517
+
(circle cx cy (+ 1 (random 3))))
518
+
(blur 1)
519
+
(zoom 1.002)
520
+
\end{lstlisting}
521
+
522
+
このプログラムは、黒い背景を設定し、マイク振幅を読み取り、音に反応して軌道運動する50個のパーティクルを描画し、計算されたグラデーションで着色し、わずかなぼかしを適用し、ゆっくりズームインする。60 FPSで動作する。わずか12行。インポート不要、セットアップ関数不要、アニメーションループ不要、イベントリスナー不要。
523
+
524
+
\vspace{0.5em}
525
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
526
+
527
+
\bibliographystyle{plainnat}
528
+
\bibliography{references}
529
+
530
+
\end{document}
+11
-9
papers/arxiv-kidlisp/kidlisp-cards.tex
+11
-9
papers/arxiv-kidlisp/kidlisp-cards.tex
···
103
103
\thispagestyle{empty}
104
104
\vspace*{\fill}
105
105
\begin{center}
106
-
\includegraphics[height=8em]{pals}\par\vspace{0.3em}
107
-
{\acbold\fontsize{20pt}{24pt}\selectfont\color{acdark} Kid{\color{acpurple}Lisp} '26}\par
106
+
\includegraphics[height=9em]{pals}\par\vspace{0.1em}
107
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} Kid{\color{acpurple}Lisp} '26}\par
108
+
\vspace{0.1em}
108
109
\vspace{0.3em}
109
-
\vspace{0.5em}
110
-
{\normalsize\color{cyan!70!blue}\textbf{@jeffrey}}\par
110
+
{\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par
111
111
{\small\color{acgray} Aesthetic.Computer}\par
112
112
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
113
-
\vspace{0.8em}
114
-
\rule{0.6\textwidth}{1pt}\par
115
113
\vspace{0.4em}
116
-
{\small\color{acpink!40}\textit{working draft --- not for citation}}\par
117
-
\vspace{0.3em}
118
-
{\footnotesize\color{acgray} March 2026}\par
114
+
\rule{0.5\textwidth}{0.5pt}\par
115
+
\vspace{0.15em}
116
+
\colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par
117
+
\vspace{0.1em}
118
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/2113ef735}{2113ef735}}\par
119
+
\vspace{0.1em}
120
+
{\footnotesize\color{acgray}\href{https://papers.aesthetic.computer/kidlisp-26-arxiv-da-cards.pdf}{Dansk} · \href{https://papers.aesthetic.computer/kidlisp-26-arxiv-es-cards.pdf}{Español} · \href{https://papers.aesthetic.computer/kidlisp-26-arxiv-zh-cards.pdf}{{\accjk 中文}} · \href{https://papers.aesthetic.computer/kidlisp-26-arxiv-ja-cards.pdf}{{\accjk 日本語}}}\par
119
121
\end{center}
120
122
\vspace*{\fill}
121
123
+558
papers/arxiv-kidlisp/kidlisp-ja.tex
+558
papers/arxiv-kidlisp/kidlisp-ja.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
\usepackage{xeCJK}
11
+
\setCJKmainfont{Droid Sans Japanese}
12
+
13
+
\setmainfont{Latin Modern Roman}
14
+
\setsansfont{Latin Modern Sans}
15
+
16
+
\newfontfamily\acbold{ywft-processing-bold}[
17
+
Path=../../system/public/type/webfonts/,
18
+
Extension=.ttf
19
+
]
20
+
\newfontfamily\aclight{ywft-processing-light}[
21
+
Path=../../system/public/type/webfonts/,
22
+
Extension=.ttf
23
+
]
24
+
\newfontfamily\kidlispfont{ComicRelief-Regular}[
25
+
Path=fonts/,
26
+
Extension=.ttf
27
+
]
28
+
\newfontfamily\kidlispbold{ComicRelief-Bold}[
29
+
Path=fonts/,
30
+
Extension=.ttf
31
+
]
32
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
33
+
34
+
% === PACKAGES ===
35
+
\usepackage{xcolor}
36
+
\usepackage{titlesec}
37
+
\usepackage{enumitem}
38
+
\usepackage{booktabs}
39
+
\usepackage{tabularx}
40
+
\usepackage{multicol}
41
+
\usepackage{fancyhdr}
42
+
\usepackage{hyperref}
43
+
\usepackage{graphicx}
44
+
\graphicspath{{figures/}}
45
+
\usepackage{ragged2e}
46
+
\usepackage{listings}
47
+
\usepackage{natbib}
48
+
\usepackage[colorspec=0.92]{draftwatermark}
49
+
50
+
% === COLORS (AC palette) ===
51
+
\definecolor{acpink}{RGB}{180,72,135}
52
+
\definecolor{acpurple}{RGB}{120,80,180}
53
+
\definecolor{acdark}{RGB}{64,56,74}
54
+
\definecolor{acgray}{RGB}{119,119,119}
55
+
\definecolor{klbrand}{RGB}{205,92,155}
56
+
\definecolor{klcyan}{RGB}{112,214,255}
57
+
\definecolor{kldark}{RGB}{48,43,58}
58
+
\definecolor{draftcolor}{RGB}{205,92,155}
59
+
60
+
% === DRAFT WATERMARK ===
61
+
\DraftwatermarkOptions{
62
+
text=WORKING DRAFT,
63
+
fontsize=3cm,
64
+
color=draftcolor!18,
65
+
angle=45,
66
+
pos={0.5\paperwidth, 0.5\paperheight}
67
+
}
68
+
69
+
% === KIDLISP SYNTAX COLORS ===
70
+
\definecolor{klfn}{RGB}{0,136,170}
71
+
\definecolor{klform}{RGB}{119,51,170}
72
+
\definecolor{klrepeat}{RGB}{170,0,170}
73
+
\definecolor{klnum}{RGB}{204,0,102}
74
+
\definecolor{klstr}{RGB}{170,120,0}
75
+
\definecolor{klcmt}{RGB}{102,102,102}
76
+
\definecolor{klmath}{RGB}{0,136,0}
77
+
\definecolor{klvar}{RGB}{204,102,0}
78
+
\definecolor{klembed}{RGB}{0,136,0}
79
+
80
+
\newcommand{\kn}[1]{\textcolor{klnum}{#1}}
81
+
\newcommand{\kt}[1]{\textcolor{klstr}{#1}}
82
+
\newcommand{\kv}[1]{\textcolor{klvar}{#1}}
83
+
\newcommand{\ke}[1]{\textcolor{klembed}{\textbf{#1}}}
84
+
\newcommand{\km}[1]{\textcolor{klmath}{#1}}
85
+
86
+
% === HYPERREF ===
87
+
\hypersetup{
88
+
colorlinks=true,
89
+
linkcolor=acpurple,
90
+
urlcolor=acpurple,
91
+
citecolor=acpurple,
92
+
pdfauthor={@jeffrey},
93
+
pdftitle={KidLisp '26：ジェネラティブアートのためのミニマルLisp},
94
+
}
95
+
96
+
% === SECTION FORMATTING ===
97
+
\titleformat{\section}
98
+
{\normalfont\bfseries\normalsize\uppercase}
99
+
{\thesection.}
100
+
{0.5em}
101
+
{}
102
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
103
+
104
+
\titleformat{\subsection}
105
+
{\normalfont\bfseries\small}
106
+
{\thesubsection}
107
+
{0.5em}
108
+
{}
109
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
110
+
111
+
% === HEADER/FOOTER ===
112
+
\pagestyle{fancy}
113
+
\fancyhf{}
114
+
\renewcommand{\headrulewidth}{0pt}
115
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{作業草稿 --- 引用不可}}
116
+
\fancyfoot[C]{\footnotesize\thepage}
117
+
118
+
% === CUSTOM COMMANDS ===
119
+
\newcommand{\acdot}{{\color{acpink}.}}
120
+
\newcommand{\kidlisp}{\textsc{KidLisp}}
121
+
122
+
% === LISTINGS ===
123
+
\lstdefinelanguage{kidlisp}{
124
+
morekeywords=[1]{wipe,ink,line,box,circle,tri,plot,flood,shape,zoom,scroll,spin,blur,contrast,embed,layer,width,height,frame,time,wiggle,melody,mic,suck,sort,form,trans,cube,move,scale,hop,overtone,resolution,write,text,type,stamp,paste,point,poly,noise,fade,pan,unpan,mask,unmask,flip},
125
+
morekeywords=[2]{def,let,if,cond,once,later,lambda,do},
126
+
morekeywords=[3]{repeat},
127
+
morekeywords=[4]{random,sin,cos,tan,floor,ceil,round,abs,sqrt,min,max},
128
+
sensitive=true,
129
+
morecomment=[l]{;},
130
+
morestring=[b]",
131
+
escapeinside={|}{|},
132
+
}
133
+
\lstset{
134
+
language=kidlisp,
135
+
basicstyle=\ttfamily\small,
136
+
keywordstyle=[1]\color{klfn}\bfseries,
137
+
keywordstyle=[2]\color{klform}\bfseries,
138
+
keywordstyle=[3]\color{klrepeat}\bfseries,
139
+
keywordstyle=[4]\color{klmath},
140
+
commentstyle=\color{klcmt}\itshape,
141
+
stringstyle=\color{klstr},
142
+
breaklines=true,
143
+
frame=single,
144
+
rulecolor=\color{acgray!30},
145
+
backgroundcolor=\color{acgray!5},
146
+
xleftmargin=0.5em,
147
+
xrightmargin=0.5em,
148
+
aboveskip=0.5em,
149
+
belowskip=0.5em,
150
+
}
151
+
152
+
\lstdefinelanguage{json}{
153
+
basicstyle=\ttfamily\small,
154
+
stringstyle=\color{acpink},
155
+
morestring=[b]",
156
+
literate=
157
+
{:}{{{\color{acgray}:}}}{1}
158
+
{,}{{{\color{acgray},}}}{1}
159
+
{\{}{{{\color{acgray}\{}}}{1}
160
+
{\}}{{{\color{acgray}\}}}}{1},
161
+
}
162
+
163
+
% === LIST SETTINGS ===
164
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
165
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
166
+
167
+
\setlength{\columnsep}{1.8em}
168
+
\setlength{\parindent}{1em}
169
+
\setlength{\parskip}{0.3em}
170
+
171
+
% Hyphenation for narrow two-column layout
172
+
\tolerance=800
173
+
\emergencystretch=1em
174
+
\hyphenpenalty=50
175
+
176
+
\begin{document}
177
+
178
+
\twocolumn[{%
179
+
\begin{center}
180
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
181
+
{\kidlispbold\fontsize{26pt}{30pt}\selectfont\color{kldark} Kid{\color{klbrand}Lisp} '26}\par
182
+
\vspace{0.2em}
183
+
{\kidlispfont\fontsize{11pt}{13pt}\selectfont\color{klbrand} ジェネラティブアートのためのミニマルLisp}\par
184
+
\vspace{0.6em}
185
+
{\normalsize @jeffrey}\par
186
+
{\small\color{acgray} Aesthetic.Computer}\par
187
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
188
+
\vspace{0.3em}
189
+
{\small\color{acpurple} \url{https://kidlisp.com} \enspace$\cdot$\enspace \url{https://aesthetic.computer}}\par
190
+
\vspace{0.6em}
191
+
\rule{\textwidth}{1.5pt}
192
+
\vspace{0.5em}
193
+
\end{center}
194
+
195
+
\begin{center}
196
+
{\small\color{acpink}\textbf{[ 作業草稿 --- 引用不可 ]}}
197
+
\end{center}
198
+
\vspace{0.3em}
199
+
200
+
\begin{quote}
201
+
\small\noindent\textbf{要旨。}
202
+
\kidlisp{}はジェネラティブアートおよびインタラクティブな視聴覚体験のためのミニマルLisp方言である。ブラウザベースのクリエイティブ・コンピューティングプラットフォームであるAesthetic Computer内部で動作する。プログラムはMongoDBに保存され、短い英数字コードが割り当てられ、URLを通じて実行される。15,000行のツリー走査エバリュエーターが、描画、色、変換、数学、アニメーション、オーディオを含む12カテゴリの118の組み込み関数を提供する——ファイルI/O、ネットワーク、汎用文字列操作はなく、任意のユーザー投稿コードの安全な実行を可能にしている。本論文は言語設計、ストレージと配信のインフラ、メディアパイプラインを記述し、59名の著者による16,000以上のプログラム作成という採用状況を報告する。ソーシャル配信をドメイン固有言語に付加するのではなく直接埋め込むことで、質的に異なるクリエイティブ・プログラミング実践が生まれることを論じる。
203
+
\end{quote}
204
+
\vspace{0.5em}
205
+
}]
206
+
207
+
\section{序論}
208
+
209
+
クリエイティブ・プログラミング環境は通常、視覚的または音響的出力を生成する前に、汎用プログラミング言語の学習をユーザーに要求する。Processing~\citep{reas2007processing}はJavaを使用し、p5.js~\citep{mccarthy2015p5js}はJavaScriptを使用し、Sonic Pi~\citep{aaron2016sonic}はRubyライクな構造を使用する。これらのツールは計算表現の敷居を大幅に下げたが、依然として変数、関数、制御フローへの慣れ——多くの場合ローカル開発環境——を必要とする。
210
+
211
+
\kidlisp{}は異なる問いから出発する：\emph{興味深いジェネラティブアートを生み出せる最小の言語は何か？}答えは、慎重に選ばれた組み込み関数、ユーザー定義手続きなし、インストール不要のブラウザネイティブランタイムを備えたLispである。完全なアニメーションプログラムが1行で書ける：
212
+
213
+
\begin{lstlisting}
214
+
(ink |\kt{rainbow}|) (repeat |\kn{100}| |\kv{i}|
215
+
(circle (wiggle width) (wiggle height) |\kn{10}|))
216
+
\end{lstlisting}
217
+
218
+
この設計はNo Paint（2020）——非技術系ユーザーコミュニティが、好きなソフトウェアへのソーシャルな関与を通じてコンピューティングを学ぶことを実証したピクセルドローイングツール——からの観察に由来する。\kidlisp{}はこの知見をプログラミング言語に拡張する：すべてのプログラムはショートコードで即座に共有でき、URL上で表示でき、他のプログラムに埋め込める。
219
+
220
+
本論文は言語設計（\S\ref{sec:design}）、エバリュエーターアーキテクチャ（\S\ref{sec:architecture}）、ストレージと配信のインフラ（\S\ref{sec:infrastructure}）、メディアパイプライン（\S\ref{sec:media}）、採用データ（\S\ref{sec:evaluation}）を記述する。
221
+
222
+
\begin{figure}[t]
223
+
\centering
224
+
\includegraphics[width=\columnwidth]{kidlisp-og-mosaic.png}
225
+
\caption{ovenサービスによってレンダリングされた精選\kidlisp{}プログラム（\texttt{\$roz}）のOpen Graphソーシャルプレビュー。オーバーレイにプログラムコード、再生回数、著者IDが表示される。}
226
+
\label{fig:og}
227
+
\end{figure}
228
+
229
+
\section{言語設計}
230
+
\label{sec:design}
231
+
232
+
\kidlisp{}はS式言語である。各プログラムは上から下に評価される式のシーケンスであり、HTML Canvas 2Dコンテキスト、WebGLコンテキスト、Web Audioグラフ、またはそれらの組み合わせに副作用を生む。
233
+
234
+
\subsection{設計原則}
235
+
236
+
\begin{enumerate}
237
+
\item \textbf{すべての式が描画する。}有効な\kidlisp{}は可視的な出力を生む。\texttt{main}なし、importなし、ボイラープレートなし。
238
+
\item \textbf{フラットはネストに勝る。}プログラムは抽象の定義ではなく他のプログラムの埋め込みを通じて合成される。これによりコードが一目で読める。
239
+
\item \textbf{構造による安全。}ファイルI/Oなし、ネットワークなし、外部状態の変更なし。プログラムは言語に危険なプリミティブが\emph{ない}ことによってサンドボックス化される。
240
+
\item \textbf{デフォルトでソーシャル。}すべてのプログラムにショートコードとURLがある。共有は配信メカニズムであり、後付けの機能ではない。
241
+
\end{enumerate}
242
+
243
+
\subsection{関数の分類}
244
+
245
+
118の組み込み関数は12のカテゴリに分類される（表~\ref{tab:functions}）。
246
+
247
+
\begin{table}[h]
248
+
\small
249
+
\centering
250
+
\begin{tabularx}{\columnwidth}{lrX}
251
+
\toprule
252
+
\textbf{カテゴリ} & \textbf{数} & \textbf{例} \\
253
+
\midrule
254
+
グラフィクス & 9 & \texttt{wipe}, \texttt{ink}, \texttt{line}, \texttt{box}, \texttt{circle} \\
255
+
変換 & 11 & \texttt{scroll}, \texttt{zoom}, \texttt{spin}, \texttt{blur}, \texttt{suck} \\
256
+
数学 & 14 & \texttt{+}, \texttt{sin}, \texttt{cos}, \texttt{random}, \texttt{wiggle} \\
257
+
色 & 19 & CSS名 + \texttt{rainbow}, \texttt{zebra} \\
258
+
システム & 9 & \texttt{width}, \texttt{height}, \texttt{frame}, \texttt{fps} \\
259
+
3D & 8 & \texttt{cube}, \texttt{form}, \texttt{trans}, \texttt{move} \\
260
+
オーディオ & 6 & \texttt{mic}, \texttt{melody}, \texttt{overtone} \\
261
+
制御 & 7 & \texttt{def}, \texttt{if}, \texttt{repeat}, \texttt{once}, \texttt{later} \\
262
+
テキスト & 4 & \texttt{write}, \texttt{type}, \texttt{paste} \\
263
+
入力 & 3 & \texttt{pen}, \texttt{touch} \\
264
+
合成 & 4 & \texttt{embed}, \texttt{layer}, \texttt{fade} \\
265
+
データ & 4 & \texttt{let}, \texttt{list}, \texttt{get}, \texttt{set} \\
266
+
\midrule
267
+
\textbf{合計} & \textbf{118} & \\
268
+
\bottomrule
269
+
\end{tabularx}
270
+
\caption{カテゴリ別の組み込み関数。}
271
+
\label{tab:functions}
272
+
\end{table}
273
+
274
+
\begin{figure}[t]
275
+
\centering
276
+
\includegraphics[height=4.5cm]{card-line.pdf}%
277
+
\hfill%
278
+
\includegraphics[height=4.5cm]{card-ink.pdf}
279
+
\caption{\kidlisp{}の\texttt{line}と\texttt{ink}関数のリファレンスカード。構文と座標出力を表示。カードは\texttt{kidlisp.com/cards}でSVGイラストとして配布。}
280
+
\label{fig:cards}
281
+
\end{figure}
282
+
283
+
\subsection{時間構文}
284
+
285
+
\kidlisp{}は明示的なループやコールバックなしに式の評価をスケジュールする時間演算子を提供する：
286
+
287
+
\begin{lstlisting}
288
+
|\kt{2.5s}| (wipe |\kt{red}|) ; 2.5秒後
289
+
|\kt{1s...}| (spin |\kn{5}|) ; 毎秒繰り返し
290
+
|\kt{3s!}| (write "Done" |\kn{10}| |\kn{10}|) ; 3秒時に1回だけ実行
291
+
|\kt{30f}| (ink |\kt{blue}|) ; 30フレーム後
292
+
\end{lstlisting}
293
+
294
+
接尾辞\texttt{s}は秒、\texttt{f}はフレーム、\texttt{...}は繰り返し、\texttt{!}は1回実行を示す。これらの演算子は組み合わせ可能：\texttt{0.5s... (ink (random 255) (random 255) (random 255))}は0.5秒ごとに色変化を生む。
295
+
296
+
\subsection{KidLispが省略するもの}
297
+
298
+
言語はユーザー定義関数（値の命名用\texttt{def}を除く）、再帰、文字列操作、ファイルI/O、ネットワーク、ミュータブルデータ構造、例外処理を意図的に排除している。これらの省略こそが設計そのものである。抽象化メカニズムを除去することで、プログラムはフラットで読みやすく保たれる——読者はコールスタックを追わずに任意のプログラムを上から下まで理解できる。
299
+
300
+
\section{エバリュエーターアーキテクチャ}
301
+
\label{sec:architecture}
302
+
303
+
エバリュエーター（\texttt{kidlisp.mjs}、15,161行）は単一のJavaScript ESモジュールであり、ツリー走査インタープリターを実装する。
304
+
305
+
\subsection{評価モデル}
306
+
307
+
エバリュエーターはアニメーションフレームごとに1回実行される。S式はトークン化され、ネストされた配列ASTにパースされ、各リストの最初のシンボルへのディスパッチを通じて走査される。組み込み関数はCanvas 2D操作、WebGLコマンド、Web Audio API呼び出し、数学計算に直接マッピングされる。プログラム全体がフレームごとに再評価され、\texttt{frame}と\texttt{time}バインディングが自動更新される——明示的なアニメーションループを不要にする即時モードモデルである。
308
+
309
+
\subsection{決定論的レンダリング}
310
+
311
+
同じランダムシードとフレーム番号が与えられれば、プログラムは常に同じ出力を生む。\texttt{random}関数はプログラムのショートコードから初期化されたシードPRNGを使用し、再現可能なジェネラティブアートを実現する。
312
+
313
+
\subsection{カオスモード}
314
+
315
+
無効またはランダムなテキスト入力はエラーメッセージではなく芸術的な視覚出力を生成する。信頼度スコアベースの検出器が単語認識率（既知語彙の$<$30\%）、特殊文字比率（$>$50\%）、括弧バランス（比率$>$3:1）をチェックし、入力をコードまたはカオスに分類する。カオス入力は入力テキストからシードされた決定論的なジェネラティブビジュアルを生む。つまり\kidlisp{}に入力された\emph{あらゆる}テキストが視覚コンテンツを生む——ユーザーはエラー状態を一切見ない。
316
+
317
+
\subsection{パフォーマンス}
318
+
319
+
エバリュエーターは3段階の最適化を実装する：
320
+
321
+
\begin{itemize}
322
+
\item \textbf{多段コードキャッシュ}：埋め込みプログラムの解決はRAM、IndexedDB、ネットワーク、次にTEIA（分散型アーカイブ）の順で確認する。キャッシュヒットにより再パースと再取得を回避。
323
+
\item \textbf{バッファプーリング}：解像度ごとに最大8つの再利用可能なオフスクリーンキャンバスで、合成中のアロケーションジッターを回避。
324
+
\item \textbf{自動密度スケーリング}：ピクセル密度をスクロールFPS平均（目標：30--55 FPS）に基づいて0.5xから4xの間で調整し、60フレームのクールダウン期間を設ける。
325
+
\end{itemize}
326
+
327
+
関数呼び出し結果、アルファ調整済みピクセルバッファ、ブレンド合成体はフレームごとにキャッシュおよび無効化される。
328
+
329
+
\section{ストレージと配信}
330
+
\label{sec:infrastructure}
331
+
332
+
\subsection{MongoDBストレージ}
333
+
334
+
各プログラムは\texttt{kidlisp} MongoDBコレクション内のドキュメントとして保存される：
335
+
336
+
\begin{lstlisting}[language=json]
337
+
{
338
+
"code": "cow",
339
+
"source": "(wipe blue)\n(ink yellow)...",
340
+
"hash": "a3f2e8...",
341
+
"when": "2025-06-15T...",
342
+
"lastAccessed": "2026-03-01T...",
343
+
"hits": 342,
344
+
"user": "auth0|abc123"
345
+
}
346
+
\end{lstlisting}
347
+
348
+
\texttt{hash}フィールド（トリム済みソースのSHA-256）はコンテンツベースの重複排除を強制する：同一のプログラムは常に同一のコードに解決される。\texttt{hits}カウンターと\texttt{lastAccessed}タイムスタンプは利用分析に使用される。コレクションは\texttt{code}と\texttt{hash}のユニークインデックスに加え、\texttt{user}とオプションのNFTミントレコード（\texttt{kept.network}）のスパースインデックスを維持する。
349
+
350
+
\subsection{コード生成}
351
+
352
+
ショートコードはソース感知アルゴリズムによって生成される。システムはまずプログラム内容から意味のあるコードの導出を試みる——主要な関数名、色キーワード、構造パターンの抽出——推定されたコードがすべて使用済みの場合はランダム\texttt{nanoid}生成にフォールバックする。これにより\texttt{cow}（牛の形を持つプログラム）のようなコードが任意の英数字文字列ではなく生成される。
353
+
354
+
\subsection{REST API}
355
+
356
+
ストレージエンドポイント（\texttt{store-kidlisp.mjs}）は単一のURLで5つのクエリモードを提供する：
357
+
358
+
\begin{enumerate}
359
+
\item \textbf{POST} --- プログラムの保存。SHA-256ハッシュによる重複排除、ショートコード生成、オプションでATProto（Bluesky）への同期とアーカイブイベントの発行。
360
+
\item \textbf{GET \texttt{?code=xyz}} --- 単一プログラムの取得。\texttt{@handles}コレクションへの\texttt{\$lookup}により著者IDを解決。
361
+
\item \textbf{GET \texttt{?codes=a,b,c}} --- バッチ取得（最大50コード）。評価中の埋め込みレイヤー解決に使用。
362
+
\item \textbf{GET \texttt{?recent=true}} --- 作成日時またはヒット数でソートされたページネーション付きフィード。オプションの\texttt{handle}フィルターでユーザー別フィード。
363
+
\item \textbf{GET \texttt{?stats=functions}} --- コーパス横断の関数使用分析。プログラム人気度で重み付けされたカウントを返す。
364
+
\end{enumerate}
365
+
366
+
認証はオプションで3秒タイムアウト——匿名プログラム作成をサポートするが、認証済みユーザーは帰属とアーカイブイベント発行を得る。
367
+
368
+
\subsection{埋め込みと合成}
369
+
370
+
プログラム内の\texttt{\$code}構文はストレージAPIからの取得（またはキャッシュヒット）、オフスクリーンバッファでの評価、親キャンバスへの合成をトリガーする。これにより有向非巡回合成グラフが生まれる。実例：
371
+
372
+
\begin{lstlisting}
373
+
; A 3D grid of cubes with embedded layers
374
+
(wipe |\kt{black}|)
375
+
(def |\kv{gridsize}| |\kn{6}|)
376
+
(repeat (|\km{*}| |\kv{gridsize}| |\kv{gridsize}|) |\kv{i}|
377
+
(ink (hop |\kn{0.1}| |\kt{rainbow}| |\kt{blue}| |\kt{white}|))
378
+
(form (trans (cube |\kv{i}|)
379
+
(move (|\km{*}| (|\km{\%}| |\kv{i}| |\kv{gridsize}|) |\kn{3}|) |\kn{0}| |\kn{-20}|)
380
+
(scale |\kn{1.5}|) (spin |\kn{0}| |\kn{1}| |\kn{0}|))))
381
+
(|\ke{\$27z}|)
382
+
(|\ke{\$cow}|)
383
+
\end{lstlisting}
384
+
385
+
ここで\texttt{\$27z}と\texttt{\$cow}はMongoDBから解決され、オフスクリーンバッファにレンダリングされ、合成される。ユーザーは複雑な単一プログラムを書く代わりに、単純なプログラムを重ね合わせて複雑なビジュアルを構築する。
386
+
387
+
\section{メディアパイプライン}
388
+
\label{sec:media}
389
+
390
+
ovenサービス（\texttt{oven.aesthetic.computer}）は録画された\kidlisp{}セッションを共有可能なメディアアセットに変換する。
391
+
392
+
\subsection{録画からMP4へ}
393
+
394
+
ユーザーがセッションを録画すると、セッションサーバーがPNGフレームとオプションのWAVオーディオを含むZIPをアップロードする。oven：
395
+
396
+
\begin{enumerate}
397
+
\item フレームを抽出し\texttt{timing.json}から各フレーム持続時間を読み取る
398
+
\item 中間フレームからサムネイルを生成（3倍最近傍拡大、512$\times$512にフィット）
399
+
\item FFmpegを通じて最近傍拡大でH.264/AAC MP4にエンコードし、ピクセルアート美学を保持
400
+
\item DigitalOcean Spaces CDNにアップロード
401
+
\item \texttt{oven-bakes} MongoDBコレクションにベイクメタデータを保存し、WebSocketを通じてサブスクライバーに通知
402
+
\end{enumerate}
403
+
404
+
ovenは\texttt{tapes} MongoDBコレクションをchange streamsで監視し、処理が必要な新しい録画を自動検出する。
405
+
406
+
\begin{figure}[t]
407
+
\centering
408
+
\includegraphics[height=4.5cm]{card-wipe.pdf}%
409
+
\hfill%
410
+
\includegraphics[height=4.5cm]{card-box.pdf}
411
+
\caption{\texttt{wipe}（色で画面をクリア）と\texttt{box}（矩形を描画）のリファレンスカード。各カードに関数シグネチャ、グリッド上のビジュアル例、対応するソースコードを表示。}
412
+
\label{fig:cards2}
413
+
\end{figure}
414
+
415
+
\subsection{ソーシャルプレビュー画像}
416
+
417
+
ovenはソーシャル共有用に安定したURL（例：\texttt{/kidlisp-og.png}）のOpen Graphプレビュー画像を生成する。iOSクローラーは直接の画像配信を要求し——\texttt{og:image} URLの301リダイレクトをフォローしない——ためovenは生成済みPNGをキャッシュして即時200レスポンスで配信し、キャッシュミス時に非同期再生成をトリガーする。
418
+
419
+
\subsection{アセット配信}
420
+
421
+
すべてのメディアアセットはDigitalOcean Spaces CDN（\texttt{art-aesthetic-computer.sfo3.cdn.\allowbreak digitaloceanspaces.com}）を通じて配信される。録画テープは独立したバケット（\texttt{at-blobs-aesthetic-computer}）とオプションのカスタムCDNドメインを使用する。Netlifyが\texttt{/preview/*}と\texttt{/icon/*}パスをovenにプロキシし、透過的なURL解決を実現する。
422
+
423
+
\section{開発環境}
424
+
425
+
\kidlisp{} IDEは\texttt{kidlisp.com}に位置し、Monacoベースのエディタ（カスタム構文ハイライト付き）、Aesthetic Computerランタイムを実行するライブプレビューiframe、コンソールパネル、再生コントロール（再生/一時停止/停止）を提供する。
426
+
427
+
「スライダーモード」ではエディタ内の数値リテラルをドラッグして値をリアルタイムに調整できる——カーソルが任意の数値上で水平スライダーに変わり、ドラッグ中もプレビューが継続更新される。
428
+
429
+
IDEは2つのレイアウトモードをサポートする：\emph{スタジオ}（分割画面のエディタ、プレビュー、コンソール）と\emph{ステージ}（エディタがフルスクリーンキャンバスに直接オーバーレイし、透明背景で、すべてのUI要素が非表示）。ステージモードはライブパフォーマンスシナリオ向けに設計されており、コード自体が視覚出力の一部となる。
430
+
431
+
\section{開発史}
432
+
\label{sec:history}
433
+
434
+
以下のタイムラインはAesthetic Computerリポジトリのgit履歴から再構成された（2024年4月から2026年3月の間に\texttt{kidlisp.mjs}に触れた626コミット）。
435
+
436
+
\subsection{フェーズ1：プロトタイプ（2024年4--6月）}
437
+
438
+
開発は2024年4月17日、「mock lisp」というコミットタイトルで始まった。3日以内にS式パーサーが動作し、\texttt{ink}と\texttt{line}が数値引数を受け入れ、プログラムをACプロンプトに直接入力できるようになった。4月末に変数定義用の\texttt{def}が追加された。2024年5月と6月の計66コミットで、コア描画関数、\texttt{later}時間構造、1回実行用の\texttt{once}、プログラムの匿名公開が追加された。エバリュエーターは約1,000行に達した。
439
+
440
+
\subsection{フェーズ2：停滞（2024年7月--2025年5月）}
441
+
442
+
11か月間、\texttt{kidlisp.mjs}に触れるコミットはなかった。言語はACプロンプトに埋め込まれた利用可能なプロトタイプとして存在したが、ストレージバックエンド、埋め込み、オーディオ、専用エディタを欠いていた。
443
+
444
+
\subsection{フェーズ3：急速拡張（2025年6--8月）}
445
+
446
+
開発は2025年6月に再開し、月間82コミット。エバリュエーターは1,760行から8月には4,965行に成長した。主な追加：
447
+
448
+
\begin{itemize}
449
+
\item \textbf{2025年6月}：メロディーパーサー、クロック構文、フレームごとのレンダリングモデル、テストスイート（\texttt{kidlisp-spec.js}）。
450
+
\item \textbf{2025年7月}：MongoDBストレージバックエンド（\texttt{store-kidlisp.mjs}）、ショートコード生成、QRコード共有、録画とGIFエクスポート、マイク入力（\texttt{mic}）とフォールバックアニメーション。
451
+
\item \textbf{2025年8月}：埋め込みレイヤー（\texttt{\$code}構文）とアルファ合成・オフスクリーンバッファ、プログラムをNFTとしてミントするTezosブロックチェーン統合、\texttt{fade}グラデーションとピクセルバッファ最適化。
452
+
\end{itemize}
453
+
454
+
エバリュエーターは2025年9月末に10,000行を超えた。
455
+
456
+
\subsection{フェーズ4：プラットフォーム統合（2025年9--12月）}
457
+
458
+
10月だけで108コミット（ピーク月）。このフェーズで\kidlisp{}はより広いAesthetic Computerエコシステムに統合された：
459
+
460
+
\begin{itemize}
461
+
\item \textbf{2025年9月}：レイヤー0アーキテクチャ（消去モード）、MP4エクスポート用のベイク層、パフォーマンスクリティカルな埋め込みレイヤー修正。
462
+
\item \textbf{2025年10月}：ATProto/Bluesky連合（プログラムがソーシャルメディア投稿として連合配信）、クロスプラットフォームバンドル用のPACKモード、リアルタイム数値パラメータ調整用のスライダーモード。
463
+
\item \textbf{2025年11月}：\texttt{kidlisp.com} IDEがローンチ（Monacoエディタ、ライブプレビュー、コンソール、再生コントロール）、デバッグ用の実行トレースシステム、NFTワークフローが「OBJKT」から「keep」にリネーム。
464
+
\item \textbf{2025年12月}：リファレンスカード（各関数のSVGイラスト）、NFT用IPFSサムネイル生成、ソーシャル共有用のoven OG画像生成、自動密度パフォーマンススケーリング。
465
+
\end{itemize}
466
+
467
+
\subsection{フェーズ5：洗練（2026年1--3月）}
468
+
469
+
エバリュエーターは15,161行で安定。新規追加にはカオスモード（2026年2月）、3Dプリミティブ（\texttt{cube}、\texttt{form}、\texttt{trans}）、バンドオーディオ変数、\texttt{flip}コマンド、ライブパフォーマンス用ステージモードが含まれる。開発は機能追加からロバスト性に移行：埋め込みレイヤーのパフォーマンス退行の修正、カオスモードの誤分類防止、キャッシュ無効化の改善。
470
+
471
+
\begin{table}[h]
472
+
\small
473
+
\centering
474
+
\begin{tabular}{lrl}
475
+
\toprule
476
+
\textbf{日付} & \textbf{行数} & \textbf{マイルストーン} \\
477
+
\midrule
478
+
2024年4月 & 0 & 初回コミット（「mock lisp」） \\
479
+
2024年6月 & $\sim$1{,}000 & コア描画、時間、変数 \\
480
+
2025年6月 & 1{,}760 & 開発再開 \\
481
+
2025年8月 & 4{,}965 & 埋め込み、オーディオ、ストレージ \\
482
+
2025年9月 & 10{,}382 & レイヤーアーキテクチャ、ベイク \\
483
+
2025年12月 & 13{,}877 & IDE、カード、OG画像 \\
484
+
2026年2月 & 15{,}161 & カオスモード、3D、洗練 \\
485
+
\bottomrule
486
+
\end{tabular}
487
+
\caption{エバリュエーターの行数成長（\texttt{kidlisp.mjs}）。}
488
+
\label{tab:growth}
489
+
\end{table}
490
+
491
+
\section{評価}
492
+
\label{sec:evaluation}
493
+
494
+
2026年3月時点の採用指標を表~\ref{tab:adoption}に示す。
495
+
496
+
\begin{table}[h]
497
+
\small
498
+
\centering
499
+
\begin{tabular}{lr}
500
+
\toprule
501
+
\textbf{指標} & \textbf{値} \\
502
+
\midrule
503
+
作成されたプログラム総数 & 16,174 \\
504
+
個別著者数 & 59 \\
505
+
著者あたりプログラム数（中央値） & 12 \\
506
+
著者あたりプログラム数（第3四分位） & 180+ \\
507
+
埋め込み深度（観測最大値） & 7層 \\
508
+
プラットフォーム登録ユーザー & 2,798 \\
509
+
\bottomrule
510
+
\end{tabular}
511
+
\caption{採用指標（2026年3月）。}
512
+
\label{tab:adoption}
513
+
\end{table}
514
+
515
+
\subsection{関数使用分析}
516
+
517
+
\texttt{?stats=functions} APIエンドポイントはコーパス横断の重み付き関数使用カウントを提供する。最大5,000プログラム（ヒット数順）をスキャンし、各ソースを解析して関数呼び出しを抽出し、プログラム人気度で重み付けされたカウントを返す。これによりユーザーが好むプリミティブの定量分析が可能となる。最も使用頻度の高い関数は\texttt{wipe}、\texttt{ink}、\texttt{repeat}、\texttt{circle}——ユーザーが主に描画とイテレーションを使用していることを確認する。
518
+
519
+
\subsection{観察}
520
+
521
+
\textbf{抽象より合成。}ユーザーは抽象化ではなく埋め込みを行う。最も参照されるプログラムは単純なビジュアルプリミティブ（グラデーション、形状、パターン）であり、ビルディングブロックとして機能する。
522
+
523
+
\textbf{エンジニアリングより探索。}プログラムは通常短い（10行以下）。ユーザーは既存プログラムを編集するのではなく新しいプログラムを保存してイテレーションし、ストレージタイムスタンプに可視的な分岐探索パスを作り出す。
524
+
525
+
\textbf{ソーシャル学習。}最も生産性の高い著者は既存プログラムの閲覧とリミックスから始める。ショートコードシステムにより発見は偶発的になる——ユーザーはランダムなコードを試すことでプログラムに出会う。
526
+
527
+
\subsection{制約}
528
+
529
+
\kidlisp{}は汎用プログラミング、複雑なシミュレーション、セッション間で持続的な状態を必要とするアプリケーションには適さない。ユーザー定義関数の欠如はプログラムの複雑さを制限する——これは意図的な選択だが、一部の上級ユーザーはこれにフラストレーションを感じる。
530
+
531
+
\section{関連研究}
532
+
533
+
\textbf{クリエイティブ・プログラミング。}Processing~\citep{reas2007processing}とp5.js~\citep{mccarthy2015p5js}が主流ツールである。openFrameworksはC++を使用する。いずれもプロジェクト構造の管理と汎用プログラミング言語の理解を必要とする。
534
+
535
+
\textbf{ライブコーディング。}Hydra~\citep{hydra2019}はJavaScriptメソッドチェーンを使用するブラウザベースのライブビジュアルプログラミングを提供するが、永続ストレージやソーシャル機能を持たない。Sonic Pi~\citep{aaron2016sonic}は音楽教育を対象とする。Fluxus~\citep{fluxus2007}はSchemeで3Dビジュアルを行うが、もはやメンテナンスされていない。
536
+
537
+
\textbf{教育言語。}Scratch~\citep{resnick2009scratch}はソーシャル共有が教育プログラミングの参加を促進することを証明した。\kidlisp{}はこの知見を継承しつつ、テキストベースのLisp構文を使用し、汎用教育ではなくジェネラティブアートを対象とする。
538
+
539
+
\textbf{アート用Lisp。}Racketの\texttt{2htdp/image}ライブラリ~\citep{racket2018}はCS教育のための関数型画像構築を提供するが、ソーシャル配信を伴うリアルタイムアニメーションではなく、静的画像と教育法を対象としている。
540
+
541
+
\section{結論}
542
+
543
+
\kidlisp{}は、ミニマルなドメイン固有言語——ブラウザネイティブで、ユーザー定義の抽象なし、ソーシャル配信を備えたコンテンツアドレスドデータベースに支えられた——がジェネラティブアート実践の活発なコミュニティを支えうることを実証する。核心的な設計上の知見は、ソーシャル配信（ショートコード、URL共有、埋め込み）が付加機能ではなくコア言語機能であり、ユーザーがどう学び、創り、互いの作品の上に構築するかを形作るということである。
544
+
545
+
埋め込みグラフ、関数使用分析API、そしてタイムスタンプと著者帰属を持つ16,000以上のプログラムコーパスは、クリエイティブ・プログラミング実践、計算的創造性、非専門家ユーザーがソーシャルな関与を通じて関数型プログラミングをどう学ぶかを研究するためのデータセットを構成する。
546
+
547
+
\kidlisp{}はISCライセンスの下でオープンソースである。エバリュエーター、ドキュメント、ツールは\url{https://github.com/digitpain/aesthetic.computer}で入手可能。プログラムは\url{https://kidlisp.com}で閲覧・作成できる。
548
+
549
+
\vspace{0.5em}
550
+
\noindent\textit{英語原版からの翻訳。原版は \url{https://papers.aesthetic.computer} にて入手可能}
551
+
552
+
\vspace{0.5em}
553
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
554
+
555
+
\bibliographystyle{plainnat}
556
+
\bibliography{references}
557
+
558
+
\end{document}
+13
-11
papers/arxiv-network-audit/network-audit-cards.tex
+13
-11
papers/arxiv-network-audit/network-audit-cards.tex
···
40
40
\thispagestyle{empty}
41
41
\vspace*{\fill}
42
42
\begin{center}
43
-
\includegraphics[height=8em]{pals}\par\vspace{0.3em}
44
-
{\acbold\fontsize{20pt}{24pt}\selectfont\color{acdark} Network Audit}\par
45
-
\vspace{0.3em}
46
-
{\fontsize{10pt}{12pt}\selectfont\color{acpink} Who Uses \acrandname{} and What Do They Make?}\par
47
-
\vspace{0.8em}
48
-
{\normalsize\color{cyan!70!blue}\textbf{@jeffrey}}\par
43
+
\includegraphics[height=9em]{pals}\par\vspace{0.1em}
44
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} Network Audit}\par
45
+
\vspace{0.1em}
46
+
{\fontsize{9pt}{11pt}\selectfont\color{acpink} Who Uses \acrandname{} and What Do They Make?}\par
47
+
\vspace{0.4em}
48
+
{\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par
49
49
{\small\color{acgray} Aesthetic.Computer}\par
50
50
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
51
-
\vspace{0.8em}
52
-
\rule{0.6\textwidth}{1pt}\par
53
51
\vspace{0.4em}
54
-
{\small\color{acpink!40}\textit{working draft --- not for citation}}\par
55
-
\vspace{0.3em}
56
-
{\footnotesize\color{acgray} March 2026}\par
52
+
\rule{0.5\textwidth}{0.5pt}\par
53
+
\vspace{0.15em}
54
+
\colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par
55
+
\vspace{0.1em}
56
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/2113ef735}{2113ef735}}\par
57
+
\vspace{0.1em}
58
+
{\footnotesize\color{acgray}\href{https://papers.aesthetic.computer/network-audit-26-arxiv-da-cards.pdf}{Dansk} · \href{https://papers.aesthetic.computer/network-audit-26-arxiv-es-cards.pdf}{Español} · \href{https://papers.aesthetic.computer/network-audit-26-arxiv-zh-cards.pdf}{{\accjk 中文}} · \href{https://papers.aesthetic.computer/network-audit-26-arxiv-ja-cards.pdf}{{\accjk 日本語}}}\par
57
59
\end{center}
58
60
\vspace*{\fill}
59
61
+278
papers/arxiv-network-audit/network-audit-ja.tex
+278
papers/arxiv-network-audit/network-audit-ja.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
5
+
\usepackage{fontspec}
6
+
\usepackage{unicode-math}
7
+
\setmainfont{Latin Modern Roman}
8
+
\setsansfont{Latin Modern Sans}
9
+
\newfontfamily\acbold{ywft-processing-bold}[Path=../../system/public/type/webfonts/,Extension=.ttf]
10
+
\newfontfamily\aclight{ywft-processing-light}[Path=../../system/public/type/webfonts/,Extension=.ttf]
11
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
12
+
13
+
\usepackage{xeCJK}
14
+
\setCJKmainfont{Droid Sans Japanese}
15
+
\setCJKsansfont{Droid Sans Japanese}
16
+
\setCJKmonofont{Droid Sans Japanese}
17
+
18
+
\usepackage{xcolor}
19
+
\usepackage{titlesec}
20
+
\usepackage{enumitem}
21
+
\usepackage{booktabs}
22
+
\usepackage{tabularx}
23
+
\usepackage{fancyhdr}
24
+
\usepackage{hyperref}
25
+
\usepackage{graphicx}
26
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
27
+
\usepackage{ragged2e}
28
+
\usepackage{microtype}
29
+
\usepackage{natbib}
30
+
\usepackage[colorspec=0.92]{draftwatermark}
31
+
32
+
\definecolor{acpink}{RGB}{180,72,135}
33
+
\definecolor{acpurple}{RGB}{120,80,180}
34
+
\definecolor{acdark}{RGB}{64,56,74}
35
+
\definecolor{acgray}{RGB}{119,119,119}
36
+
\definecolor{draftcolor}{RGB}{180,72,135}
37
+
38
+
\DraftwatermarkOptions{text=WORKING DRAFT,fontsize=3cm,color=draftcolor!18,angle=45}
39
+
40
+
\hypersetup{colorlinks=true,linkcolor=acpurple,urlcolor=acpurple,citecolor=acpurple,
41
+
pdftitle={ネットワーク監査：Aesthetic Computerを誰が使い、何を作っているか？}}
42
+
43
+
\titleformat{\section}{\normalfont\bfseries\normalsize\uppercase}{\thesection.}{0.5em}{}
44
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
45
+
\titleformat{\subsection}{\normalfont\bfseries\small}{\thesubsection}{0.5em}{}
46
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
47
+
48
+
\pagestyle{fancy}\fancyhf{}
49
+
\renewcommand{\headrulewidth}{0pt}
50
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{作業草稿——引用不可}}
51
+
\fancyfoot[C]{\footnotesize\thepage}
52
+
53
+
\newcommand{\ac}{\textsc{Aesthetic.Computer}}
54
+
\newcommand{\kl}{\textsc{KidLisp}}
55
+
56
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
57
+
\setlength{\columnsep}{1.8em}
58
+
\setlength{\parindent}{1em}
59
+
\setlength{\parskip}{0.3em}
60
+
61
+
% Hyphenation for narrow two-column layout
62
+
\tolerance=800
63
+
\emergencystretch=1em
64
+
\hyphenpenalty=50
65
+
66
+
\begin{document}
67
+
68
+
\twocolumn[{%
69
+
\begin{center}
70
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
71
+
{\acbold\fontsize{22pt}{26pt}\selectfont\color{acdark} ネットワーク監査}\par
72
+
\vspace{0.2em}
73
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} Aesthetic Computerを誰が使い、何を作っているか？}\par
74
+
\vspace{0.3em}
75
+
{\aclight\fontsize{9pt}{11pt}\selectfont\color{acgray} プラットフォームのアイデンティティ、地理的分布、創造的成果の自己評価}\par
76
+
\vspace{0.6em}
77
+
{\normalsize @jeffrey}\par
78
+
{\small\color{acgray} Aesthetic.Computer}\par
79
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
80
+
\vspace{0.3em}
81
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
82
+
\vspace{0.6em}
83
+
\rule{\textwidth}{1.5pt}
84
+
\vspace{0.5em}
85
+
\end{center}
86
+
87
+
\begin{center}
88
+
{\small\color{acpink}\textbf{[ 作業草稿——引用不可 ]}}
89
+
\end{center}
90
+
\vspace{0.3em}
91
+
92
+
\begin{quote}
93
+
\small\noindent\textbf{要旨。}
94
+
\ac{} は人口統計データを収集しない。年齢フィールドなし、性別フィールドなし、人種フィールドなし、収入フィールドなし。ユーザーについて知っているのは3つだけ：選んだユーザー名、作ったもの、そして——起動テレメトリーを通じて——作っているときに大体どこにいるか。本稿は、システムが実際に収集するデータに基づいて \ac{} プラットフォームのネットワーク監査を行う：2,811の登録ユーザー名、93,122回の地理情報ヘッダー付き起動セッション、59人の作者による16,634の \kl{} プログラム、18,062のチャットメッセージ、4,428の絵画、265の公開作品、2,900のムードステータス。プラットフォームのユーザー分布（制作者/消費者比率、べき乗則の貢献パターン、地理的カバレッジ）、ソーシャルトポロジー（チャット参加度、ハート反応、ムードパターン）、創造的成果（\kl{} 関数の実際の使用状況、最もアクセスされた作品、\texttt{\$}-code埋め込みグラフによる合成構造の構築）を分析する。人口統計データの\emph{欠如}自体がデザインスタンスであること——解放的可能性と真の限界の両方を持つこと——、そしてユーザーが\emph{何者か}ではなく\emph{何を作ったか}でプラットフォームを監査することで、コミュニティについて異なる種類の知識が生まれることを論じる。
95
+
\end{quote}
96
+
\vspace{0.5em}
97
+
}]
98
+
99
+
\section{はじめに}
100
+
101
+
プラットフォーム監査は通常、人口統計から始まる：ユーザー数、年齢、性別、人種、所在地、収入階層。これらのカテゴリが監査のフレームワークを構成するのは、プラットフォームのフレームワークを構成しているからである。ソーシャルメディア企業は広告を売るために人口統計データを収集するため、データが存在し分析可能となる。
102
+
103
+
\ac{}~\citep{scudder2026ac} は広告を販売していない。人口統計データを収集していない。ユーザーはメールアドレスで登録し、ユーザー名を選ぶ——プラットフォーム上のアイデンティティとなる一つの単語。このユーザー名と、その名のもとに作られた作品が、プラットフォームがそのユーザーについて知っているすべてである。
104
+
105
+
この制限——怠慢ではなくプライバシーの原則に由来する——は、従来のプラットフォーム監査が不可能であることを意味する。\ac{} ユーザーベースの年齢分布、性別構成、人種構成を報告することはできない。なぜなら、知らないし、尋ねたこともないからである。報告できるのは、プラットフォームが実際に観察したものである：ネットワークリクエストヘッダーからの地理信号、4種類のコンテンツの創造的成果、チャットとリアクションを通じたソーシャルインタラクション、\kl{} プログラムにおける言語機能の採用状況。
106
+
107
+
本稿が提示するのはそのような監査である。必然的に不完全だが——すべての監査がそうであるように——何を測定し何を測定できないかについて誠実である。
108
+
109
+
\section{センサス}
110
+
111
+
\begin{table}[h]
112
+
\small
113
+
\centering
114
+
\begin{tabularx}{\columnwidth}{Xr}
115
+
\toprule
116
+
\textbf{指標} & \textbf{数量} \\
117
+
\midrule
118
+
Auth0アカウント（合計） & 18,187 \\
119
+
Auth0アカウント（確認済み） & 5,373 \\
120
+
登録@ユーザー名 & 2,811 \\
121
+
起動セッション（累計） & 93,122 \\
122
+
\midrule
123
+
KidLispプログラム & 16,634 \\
124
+
絵画 & 4,428 \\
125
+
チャットメッセージ & 18,062 \\
126
+
ムード（ステータス更新） & 2,900 \\
127
+
公開作品 & 265 \\
128
+
ビデオテープ（動画録画） & 102 \\
129
+
時計 & 333 \\
130
+
注文済み物理プリント & 20 \\
131
+
\bottomrule
132
+
\end{tabularx}
133
+
\caption{2026年3月時点のプラットフォームセンサス。}
134
+
\label{tab:census}
135
+
\end{table}
136
+
137
+
アカウント作成（18,187）からユーザー名登録（2,811）、コンテンツ制作（約1,100ユーザーが少なくとも1つの絵画、ムード、またはプログラムを持つ）、継続的貢献（約59人の \kl{} 作者）に至るファネルは、Eghbalがオープンソースコミュニティで記述したパターンに従う~\citep{eghbal2020working}：大きな観察者の外層、より小さな時折の貢献者の輪、そして極めて小さな多産な制作者のコア。
138
+
139
+
\subsection{制作者/消費者比率}
140
+
141
+
\begin{table}[h]
142
+
\small
143
+
\centering
144
+
\begin{tabularx}{\columnwidth}{Xrr}
145
+
\toprule
146
+
\textbf{活動} & \textbf{ユーザー数} & \textbf{ユーザー名の\%} \\
147
+
\midrule
148
+
少なくとも1回絵を描いた & 1,067 & 38.0\% \\
149
+
ムードを投稿した & 997 & 35.5\% \\
150
+
KidLispを書いた & 59 & 2.1\% \\
151
+
作品を公開した & 19 & 0.7\% \\
152
+
\bottomrule
153
+
\end{tabularx}
154
+
\caption{制作者の参加率。}
155
+
\label{tab:creators}
156
+
\end{table}
157
+
158
+
登録ユーザーの38\%が絵を描いている——YouTube（推定制作者比率1--3\%）やSoundCloud（約10\%）と比較して極めて高い制作率である。絵を描くのにプログラミング知識は不要であり、プラットフォーム上で最も摩擦の少ない創作行為である。\kl{} の2.1\%と作品の0.7\%への低下は、テキストベースのクリエイティブプログラミングのより高いスキル閾値を反映している。
159
+
160
+
59人の \kl{} 作者が16,634のプログラムを書いた。作者あたりの中央値は12プログラム、上位四分位は各180以上のプログラムを制作。この極端な偏りはクリエイティブコミュニティに特有のべき乗則分布に従う~\citep{barabasi1999emergence}：少数の多産な作者が大部分のコンテンツを生み出し、カジュアルな制作者の長い裾野がそれぞれ1、2個のプログラムを作る。
161
+
162
+
\section{地理的分布}
163
+
164
+
\ac{} の起動テレメトリーは、Netlifyエッジリクエストヘッダーから各セッションの国、地域、都市を取得する。Cookie不使用、トラッキングピクセル不使用、ユーザー同意フォーム不使用——HTTPリクエスト自体に含まれている。
165
+
166
+
\subsection{ヘッダーが示すもの}
167
+
168
+
\texttt{boots} コレクションは93,122レコードを含み、地理データは以下から得られる：\texttt{x-country}（ISO国コード）、\texttt{x-nf-subdivision-code}（地域/州）、\texttt{x-nf-city}（都市名）、\texttt{x-nf-client-connection-ip}（クライアントIP）。これらのデータはユーザーの\emph{ネットワーク接続元}を反映し、必ずしも居住地ではない。
169
+
170
+
完全な地理分析には \texttt{boots} MongoDBコレクションの直接クエリが必要であり、付随データレポートとして公開予定。利用可能なフィールドは以下をサポートする：
171
+
172
+
\begin{itemize}
173
+
\item 国レベルの分布（各国のセッション数）
174
+
\item 都市レベルのクラスタリング（利用が集中している都市）
175
+
\item タイムゾーン別の時間パターン（地域ごとのシステム起動時刻）
176
+
\item リファラー分析（\ac{} にリンクしているサイト）
177
+
\end{itemize}
178
+
179
+
\subsection{ヘッダーが示さないもの}
180
+
181
+
地理ヘッダーはネットワーク位置を明かすが、アイデンティティは明かさない。VPNユーザーは異なる国に表示される。大学でアクセスするユーザーは自宅ではなく大学の所在地が表示される。モバイルデータを使用するユーザーは最寄りの基地局がある都市に表示される可能性がある。データは方向性としては有用だが、正確ではない。
182
+
183
+
より重要なのは、地理位置は従来の監査が関心を持つ人口統計カテゴリの代理指標ではないということである。セッションがラゴスから来たことを知っても、ユーザーの年齢、性別、収入、教育レベルは分からない。ラゴスで誰かが \ac{} を使ったことが分かるのであり、それ自体は意味がある——しかし人口統計データが提供する知識とは異なる種類のものである。
184
+
185
+
\section{創造的成果の分析}
186
+
187
+
\subsection{KidLisp関数の採用}
188
+
189
+
\texttt{/api/store-kidlisp?stats=functions} エンドポイントは、プログラムの人気度（アクセス数）で重み付けされた各 \kl{} 組み込み関数の使用統計を返す。これにより、ユーザーが実際にどの創作機能を採用したかが明らかになる~\citep{scudder2026kidlisp}。
190
+
191
+
言語設計に基づく予想パターン：
192
+
\begin{itemize}
193
+
\item \textbf{グラフィックスプリミティブ}（\texttt{wipe}、\texttt{ink}、\texttt{box}、\texttt{circle}、\texttt{line}）が支配的なはず——可視出力を生み出す最も直接的な方法
194
+
\item \textbf{変換}（\texttt{scroll}、\texttt{zoom}、\texttt{spin}）はアニメーション重視のプログラムに現れるはず
195
+
\item \textbf{制御フロー}（\texttt{repeat}、\texttt{def}、\texttt{if}）はプログラムの複雑さと相関するはず
196
+
\item \textbf{\$-code埋め込み}はソーシャル合成グラフを明らかにするはず——どのプログラムが他のプログラムの構成要素として機能するか
197
+
\item \textbf{色名}はコミュニティのカラーパレット嗜好を示すはず
198
+
\end{itemize}
199
+
200
+
完全な関数採用分析と重み付きランキングは付随データレポートとして公開予定で、\texttt{kidlisp} MongoDBコレクションの直接クエリが必要。
201
+
202
+
\subsection{\$-Code合成グラフ}
203
+
204
+
\kl{} の主要な抽象化メカニズム——ショートコードによるプログラム埋め込み——は暗黙の依存グラフを作成する。プログラムAが \texttt{(\$cow)} を含むとき、プログラム ``cow'' に依存する。このグラフには観察可能な特性がある：
205
+
206
+
\begin{itemize}
207
+
\item \textbf{ハブプログラム}：多くの他のプログラムから参照されるプログラム（視覚プリミティブ、ユーティリティパターン）
208
+
\item \textbf{リーフプログラム}：他のプログラムを埋め込むが自身は埋め込まれないプログラム
209
+
\item \textbf{深さ}：観察された最大埋め込みチェーンは7層
210
+
\item \textbf{作者間合成}：異なる作者のプログラムが互いに埋め込まれ、対話ではなくコードを通じて起こるソーシャルコラボレーションを構成する
211
+
\end{itemize}
212
+
213
+
このグラフはユニークなデータセットである。クリエイティブなコラボレーションを明示的なソーシャルインタラクションではなく依存関係として捕捉する。一度も会話したことのない2人のユーザーが、共有のビルディングブロックプログラムを通じて密接につながっている可能性がある。
214
+
215
+
\section{ソーシャルトポロジー}
216
+
217
+
\subsection{チャット}
218
+
219
+
18,062のメッセージが2つのチャットインスタンスに分布する（\texttt{chat-system} はメインプラットフォーム用、\texttt{chat-clock} は laer-klokken コミュニティ用）。メッセージはユーザー名に帰属でき、ユーザーごとの参加度分析が可能。ハート（リアクション）はユーザーとメッセージの二部親和グラフを作成する。
220
+
221
+
\subsection{ムード}
222
+
223
+
2,900のムード更新——ATProtoにクロスポストしBlueskyにミラーリングできる短いステータスメッセージ。ムードは縦断的である：タイムスタンプがあり、ユーザーエンゲージメントの時系列として分析可能。定期的にムードを投稿するユーザーは、視覚作品を生み出していなくてもコミュニティで活動している。
224
+
225
+
\subsection{アイデンティティとしてのユーザー名}
226
+
227
+
ユーザー名システムはデザイン上の選択として注目に値する。ユーザー名はユーザーが選ぶ1つの単語：\texttt{@jeffrey}、\texttt{@prutti}、\texttt{@cow}。設計上、人口統計的シグナルを持たない。プラットフォームはユーザー名から年齢を推論できない。性別も推論できない。人種も推論できない。これは制限であると同時に解放でもある。
228
+
229
+
制限とは：プラットフォームが多様な集団に奉仕しているかを評価できないこと——それらの集団が誰かを知らないから。解放とは：ユーザーは割り当てられたカテゴリではなく自分が選んだ名前で知られること~\citep{costanzachock2020design}。ユーザー名がアイデンティティ。作品が伝記。
230
+
231
+
\section{測定できないもの}
232
+
233
+
このセクションは前のセクションと同じく重要である。
234
+
235
+
\begin{itemize}
236
+
\item \textbf{年齢}：不明。登録フィールドなし。
237
+
\item \textbf{性別}：不明。登録フィールドなし。
238
+
\item \textbf{人種/民族}：不明。登録フィールドなし。
239
+
\item \textbf{収入}：不明。登録フィールドなし。
240
+
\item \textbf{障害の状況}：不明。登録フィールドなし。
241
+
\item \textbf{教育レベル}：不明。登録フィールドなし。
242
+
\item \textbf{セッション時間}：一部利用可能（起動の開始/完了タイムスタンプは存在するが完了率は不安定）
243
+
\item \textbf{ナビゲーションパス}：未追跡。ページビュー分析なし。
244
+
\item \textbf{ソーシャルグラフ}：フォロー/フレンドの仕組みなし。ソーシャル接続はチャット参加と\$-code合成から推論。
245
+
\item \textbf{離脱}：アカウントは削除されない（GDPR削除はリクエストに応じて手動処理）。非アクティブユーザーと離脱ユーザーを区別できない。
246
+
\end{itemize}
247
+
248
+
これらのフィールドの欠如は偶然ではない。\ac{} はクリエイティブプラットフォームはユーザーについて、創作物を通じて共有することを選んだもの以外、できるだけ少なく知るべきだという原則の上に構築されている~\citep{illich1973tools}。この原則にはコストがある。公平性を報告できない、十分にサービスを受けていない集団を特定できない、プラットフォームが既存の格差を再生産しているかを測定できない。これらはユーザー名ベースのアイデンティティシステムでは解決できない真の限界である。
249
+
250
+
Benjaminの観察——「人種中立的」デザインはしばしば既存のバイアスをエンコードする~\citep{benjamin2019race}——はここに当てはまる。人口統計データを収集しないという決定は、すべての人口集団に等しくサービスするという決定とは異なる。人種を尋ねないプラットフォームが、そのデザイン選択（英語のみのインターフェース、アメリカ中心のタイムゾーン、美術大学的美学）によって人種に沿って体系的に人々を排除していても——それを知ることは決してない。
251
+
252
+
\section{測定に向けて}
253
+
254
+
今後の作業は、ユーザー名ベースのアイデンティティモデルを損なうことなく、いくつかのギャップに対処できる：
255
+
256
+
\begin{itemize}
257
+
\item \textbf{地理的深層分析}：93,122の起動レコードの国、都市、時間パターン別の完全分析。利用可能な最強の多様性代理指標。
258
+
\item \textbf{言語分析}：チャットメッセージとムードには自然言語が含まれ、言語多様性（使用言語、コードスイッチングパターン）の分析に利用可能。
259
+
\item \textbf{自発的調査}：定期的な匿名調査でユーザー名と紐付けずに人口統計データを収集可能。
260
+
\item \textbf{ユーザー群別の関数採用}：関数使用パターンで \kl{} 作者をグループ化すると、異なる実践コミュニティに関連する独特の創作「方言」が明らかになる可能性。
261
+
\item \textbf{時間的エンゲージメント曲線}：起動タイムスタンプ分析でユーザーが特定のタイムゾーンに集中しているかが明らかになり、地理的クラスタリングが示唆される。
262
+
\end{itemize}
263
+
264
+
\section{結論}
265
+
266
+
本監査は \ac{} がユーザーについて知っていることを報告した：2,811のユーザー名、93,122の識別可能な地理からのセッション、そしてプラットフォームの真の成果物である創造的作品群（16,634のプログラム、4,428の絵画、18,062のメッセージ、265の作品）。\ac{} が知らないことは報告しなかった：ユーザー名の向こうにいる人々の年齢、性別、人種、収入、教育レベル。
267
+
268
+
このギャップに対する従来の対応は、欠けているデータを収集することである。デザイン正義の対応~\citep{costanzachock2020design}は、それらのカテゴリ自体がコミュニティに奉仕しているのか、それとも助成申請やインパクトレポートの記入に人口統計的分類を必要とする機関にとってコミュニティを可読にしているだけなのかを問うことである。\ac{} のこれまでの答えは——少なく知り、多く信頼する：ユーザー名をアイデンティティとし、作品に語らせ、画面の向こうにいる人が本当は誰なのかを知らないという認識論的コストを受け入れる。
269
+
270
+
これは不完全なシステムの誠実な監査である。不完全さは記録されている。システムは生きている。ユーザーは実在する。彼らが作るものが、彼らが誰であるかの最良の証拠である。
271
+
272
+
\vspace{0.5em}
273
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
274
+
275
+
\bibliographystyle{plainnat}
276
+
\bibliography{references}
277
+
278
+
\end{document}
+14
-12
papers/arxiv-notepat/notepat-cards.tex
+14
-12
papers/arxiv-notepat/notepat-cards.tex
···
38
38
\thispagestyle{empty}
39
39
\vspace*{\fill}
40
40
\begin{center}
41
-
\includegraphics[height=8em]{pals}\par\vspace{0.3em}
42
-
{\acbold\fontsize{20pt}{24pt}\selectfont\color{acdark} notepat{\color{acpurple}.}{\color{acpink}com}}\par
43
-
\vspace{0.3em}
44
-
{\fontsize{10pt}{12pt}\selectfont\color{acpink} From Keyboard Toy to System Front Door}\par
45
-
\vspace{0.8em}
46
-
{\normalsize\color{cyan!70!blue}\textbf{@jeffrey}}\par
41
+
\includegraphics[height=9em]{pals}\par\vspace{0.1em}
42
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} notepat{\color{acpurple}.}{\color{acpink}com}}\par
43
+
\vspace{0.1em}
44
+
{\fontsize{9pt}{11pt}\selectfont\color{acpink} From Keyboard Toy to System Front Door}\par
45
+
\vspace{0.4em}
46
+
{\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par
47
47
{\small\color{acgray} Aesthetic.Computer}\par
48
48
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
49
-
\vspace{0.8em}
50
-
\rule{0.6\textwidth}{1pt}\par
51
49
\vspace{0.4em}
52
-
{\small\color{acpink!40}\textit{working draft --- not for citation}}\par
53
-
\vspace{0.3em}
54
-
{\footnotesize\color{acgray} March 2026}\par
50
+
\rule{0.5\textwidth}{0.5pt}\par
51
+
\vspace{0.15em}
52
+
\colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par
53
+
\vspace{0.1em}
54
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/2113ef735}{2113ef735}}\par
55
+
\vspace{0.1em}
56
+
{\footnotesize\color{acgray}\href{https://papers.aesthetic.computer/notepat-26-arxiv-da-cards.pdf}{Dansk} · \href{https://papers.aesthetic.computer/notepat-26-arxiv-es-cards.pdf}{Español} · \href{https://papers.aesthetic.computer/notepat-26-arxiv-zh-cards.pdf}{{\accjk 中文}} · \href{https://papers.aesthetic.computer/notepat-26-arxiv-ja-cards.pdf}{{\accjk 日本語}}}\par
55
57
\end{center}
56
58
\vspace*{\fill}
57
59
···
65
67
% ============================================================
66
68
\section{Introduction}
67
69
68
-
Creative coding platforms are typically evaluated at the system level: language design, editor affordances, community size~\citep{reas2007processing,mccarthy2015p5js,resnick2009scratch}. Even within digital musical instrument research, the unit of analysis is usually the instrument class or interaction paradigm rather than the evolution of a single artifact over years~\citep{magnusson2010designing,marquez2018dmi}. This paper takes a narrower and longer lens: one piece---\texttt{notepat}---inside \ac{}, studied across 20 months of active development.
70
+
Creative coding platforms are typically evaluated at the system level: language design, editor affordances, community size~\citep{reas2007processing,mccarthy2015p5js,resnick2009scratch}. Even within digital musical instrument research, the unit of analysis is usually the instrument class or interaction paradigm rather than the evolution of a single artifact over years~\citep{magnusson2010designing,marquez2018dmi}. I take a narrower and longer lens: one piece---\texttt{notepat}---inside \ac{}, studied across 20 months of active development.
69
71
70
72
\texttt{notepat} is a melodic keyboard instrument. It is directly addressable as \texttt{aesthetic.computer/notepat} and through the branded domain \texttt{notepat.com}. As of March 2026, it is the most complex piece in the system, the default boot piece on bare-metal hardware, and the primary subject of performance testing infrastructure. None of this was planned at the outset. The instrument grew, and the platform grew around it.
71
73
+315
papers/arxiv-notepat/notepat-ja.tex
+315
papers/arxiv-notepat/notepat-ja.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
\setmainfont{Latin Modern Roman}
11
+
\setsansfont{Latin Modern Sans}
12
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
13
+
\newfontfamily\acbold{ywft-processing-bold}[
14
+
Path=../../system/public/type/webfonts/,
15
+
Extension=.ttf
16
+
]
17
+
\newfontfamily\aclight{ywft-processing-light}[
18
+
Path=../../system/public/type/webfonts/,
19
+
Extension=.ttf
20
+
]
21
+
22
+
\usepackage{xeCJK}
23
+
\setCJKmainfont{Droid Sans Japanese}
24
+
\setCJKsansfont{Droid Sans Japanese}
25
+
\setCJKmonofont{Droid Sans Japanese}
26
+
27
+
% === PACKAGES ===
28
+
\usepackage{xcolor}
29
+
\usepackage{titlesec}
30
+
\usepackage{enumitem}
31
+
\usepackage{booktabs}
32
+
\usepackage{tabularx}
33
+
\usepackage{fancyhdr}
34
+
\usepackage{hyperref}
35
+
\usepackage{graphicx}
36
+
\usepackage{ragged2e}
37
+
\usepackage{microtype}
38
+
\usepackage{natbib}
39
+
\usepackage[colorspec=0.92]{draftwatermark}
40
+
41
+
% === COLORS ===
42
+
\definecolor{acpink}{RGB}{180,72,135}
43
+
\definecolor{acpurple}{RGB}{120,80,180}
44
+
\definecolor{acdark}{RGB}{64,56,74}
45
+
\definecolor{acgray}{RGB}{119,119,119}
46
+
\definecolor{draftcolor}{RGB}{180,72,135}
47
+
48
+
% === DRAFT WATERMARK ===
49
+
\DraftwatermarkOptions{
50
+
text=WORKING DRAFT,
51
+
fontsize=3cm,
52
+
color=draftcolor!18,
53
+
angle=45,
54
+
pos={0.5\paperwidth, 0.5\paperheight}
55
+
}
56
+
57
+
% === HYPERREF ===
58
+
\hypersetup{
59
+
colorlinks=true,
60
+
linkcolor=acpurple,
61
+
urlcolor=acpurple,
62
+
citecolor=acpurple,
63
+
pdfauthor={@jeffrey},
64
+
pdftitle={notepat.com：キーボード玩具からシステムの正面玄関へ},
65
+
}
66
+
67
+
% === SECTION FORMATTING ===
68
+
\titleformat{\section}
69
+
{\normalfont\bfseries\normalsize\uppercase}
70
+
{\thesection.}
71
+
{0.5em}
72
+
{}
73
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
74
+
75
+
\titleformat{\subsection}
76
+
{\normalfont\bfseries\small}
77
+
{\thesubsection}
78
+
{0.5em}
79
+
{}
80
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
81
+
82
+
% === HEADER/FOOTER ===
83
+
\pagestyle{fancy}
84
+
\fancyhf{}
85
+
\renewcommand{\headrulewidth}{0pt}
86
+
\fancyhead[C]{\footnotesize\color{draftcolor}\textit{作業草稿——引用不可}}
87
+
\fancyfoot[C]{\footnotesize\thepage}
88
+
89
+
% === LIST SETTINGS ===
90
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
91
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
92
+
93
+
% === COLUMN SEPARATION ===
94
+
\setlength{\columnsep}{1.8em}
95
+
96
+
% === PARAGRAPH SETTINGS ===
97
+
\setlength{\parindent}{1em}
98
+
\setlength{\parskip}{0.3em}
99
+
100
+
% Hyphenation for narrow two-column layout
101
+
\tolerance=800
102
+
\emergencystretch=1em
103
+
\hyphenpenalty=50
104
+
105
+
\newcommand{\acdot}{{\color{acpink}.}}
106
+
\newcommand{\ac}{\textsc{Aesthetic.Computer}}
107
+
108
+
\begin{document}
109
+
110
+
\twocolumn[{%
111
+
\begin{center}
112
+
{\acbold\fontsize{24pt}{28pt}\selectfont\color{acdark} notepat{\color{acpurple}.}{\color{acpink}com}}\par
113
+
\vspace{0.2em}
114
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} キーボード玩具からシステムの正面玄関へ}\par
115
+
\vspace{0.6em}
116
+
{\normalsize @jeffrey}\par
117
+
{\small\color{acgray} Aesthetic.Computer}\par
118
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
119
+
\vspace{0.3em}
120
+
{\small\color{acpurple} \url{https://notepat.com} \enspace$\cdot$\enspace \url{https://aesthetic.computer}}\par
121
+
\vspace{0.6em}
122
+
\rule{\textwidth}{1.5pt}
123
+
\vspace{0.5em}
124
+
\end{center}
125
+
126
+
\begin{center}
127
+
{\small\color{draftcolor}\textbf{[ 作業草稿——引用不可 ]}}
128
+
\end{center}
129
+
\vspace{0.3em}
130
+
131
+
\begin{quote}
132
+
\small\noindent\textbf{要旨。}
133
+
\texttt{notepat} は2024年6月、\ac{}~\citep{scudder2026ac} 内の200行の半音階キーボードスケッチとして誕生した。401回のコミットと20か月の発展を経て、ブラウザ版7,903行、ベアメタル版987行にまで成長し、5種類の波形、リバーブエフェクト、アナログ感圧入力、PID~1として起動するベアメタルLinux移植版、ブランドドメイン（\texttt{notepat.com}）、専用テストフレームワーク、アルファ版Ableton Liveデバイス、VST3プラグインスキャフォールド、6つの派生作品を獲得した。本稿はこの成長過程を追跡する：\texttt{notepat} の起源、獲得した機能、生み出したインフラストラクチャ、そして単一のピースがいかにしてより大きなクリエイティブコンピューティングシステムの戦略的正面玄関となったか。この軌跡をピースの\emph{政治経済学}——ピースの増大する能力、それが推進するプラットフォーム決定、そして時間とともに引き寄せるリソースの間のフィードバックループ——として位置付ける。
134
+
\end{quote}
135
+
\vspace{0.5em}
136
+
}]
137
+
138
+
\section{はじめに}
139
+
140
+
クリエイティブプログラミングプラットフォームは通常システムレベルで評価される：言語設計、エディタ機能、コミュニティ規模~\citep{reas2007processing,mccarthy2015p5js,resnick2009scratch}。デジタル楽器研究においても、分析の単位は通常、楽器カテゴリやインタラクションパラダイムであり、単一のアーティファクトの数年にわたる進化ではない~\citep{magnusson2010designing,marquez2018dmi}。本稿はより狭くしかしより長い視点をとる：\ac{} の1つのピース——\texttt{notepat}——の20か月の活発な開発。
141
+
142
+
\texttt{notepat} はメロディックキーボード楽器である。\texttt{aesthetic.computer/notepat} およびブランドドメイン \texttt{notepat.com} から直接アクセスできる。2026年3月時点で、システム内で最も複雑なピースであり、ベアメタルハードウェアのデフォルト起動ピースであり、パフォーマンステストインフラの主要テスト対象である。これらは当初計画されたものではない。楽器が成長し、プラットフォームがその周りに成長した。
143
+
144
+
\section{起源（2024年6月--7月）}
145
+
146
+
最初のコミットは2024年6月27日、\texttt{notepad} として——後に ``note'' と ``pad'' の混成語と再解釈されたタイプミス。初期バージョンはミニマルなキーボードサンプラー：QWERTYキーが半音階にマッピングされ、単一の正弦波、アクティブキーの色付き矩形以外のUIなし。
147
+
148
+
5日以内にピースは以下を獲得した：
149
+
\begin{itemize}
150
+
\item シンセサイザーのフェードアウト（クリック防止のための25\,ms線形減衰）、
151
+
\item プロジェクトインデックスのドキュメント参照、
152
+
\item 修正後の名前 \texttt{notepat}。
153
+
\end{itemize}
154
+
155
+
この段階でピースは約200行。標準的な \ac{} ピースライフサイクル（\texttt{boot}、\texttt{paint}、\texttt{act}）とプラットフォーム内蔵の \texttt{sound.synth} APIを使用していた。設計は意図的にシンプル：覚えやすい名詞、設定不要で即座に演奏できる楽器。この初期のミニマリズムは \citet{magnusson2010designing} が記述した生産的制約と一致する——演奏者と開発者の両方に焦点を当てる有限の探索空間。
156
+
157
+
\section{機能の成長}
158
+
159
+
\subsection{オーディオエンジン（2024--2025年）}
160
+
161
+
シンセサイザーの表面は複数の軸に沿って拡張され、演奏の必要性に直接駆動された。これはまさに \citet{mcpherson2020idiomatic} がコンピュータ音楽言語について記述したダイナミクスである：ツールは主要ユーザーの美的嗜好を反映し強化する「慣用パターン」を獲得する。
162
+
163
+
\begin{itemize}
164
+
\item \textbf{波形}：正弦波 $\rightarrow$ 三角波、鋸歯波、方形波、ノイズ（キーボードショートカットまたはパラメータで選択）。
165
+
\item \textbf{リバーブ}：3タップ遅延線（120\,ms間隔）、0.55フィードバック係数、タッチパッドX軸スライダーでウェット/ドライミックスを制御。ベアメタルではサンプルごとのスムージング（$\alpha \approx 5 \times 10^{-5}$、192\,kHz）がジッパーノイズを除去。
166
+
\item \textbf{ピッチシフト}：タッチパッドY軸で$\pm$1オクターブの連続制御、サンプルごとの指数スムージング（$\alpha \approx 3 \times 10^{-4}$、192\,kHz）。
167
+
\item \textbf{オクターブ制御}：9オクターブ（1--9）、矢印キーでナビゲート。
168
+
\item \textbf{クイックモード}：スタッカート演奏用の高速アタック/ディケイ切替。
169
+
\item \textbf{メトロノーム}：リズム同期のビートインジケータ（20--300 BPM）、ダウンビートの視覚フラッシュ。
170
+
\end{itemize}
171
+
172
+
\subsection{入力とハードウェア（2024--2026年）}
173
+
174
+
3つのハードウェア統合が \texttt{notepat} の表現力の必要性に駆動された。\citet{tahiroglu2020probes} はデジタル楽器を、その計算的・物理的基盤についての思考を変える「プローブ」と記述した。\texttt{notepat} はまさにそのようにプローブした：
175
+
176
+
\begin{enumerate}
177
+
\item \textbf{NuPhy Air60 HEアナログキーボード}：USBキャプチャからWebHIDプロトコルをリバースエンジニアリング。64バイトのアクティベーションコマンド、キーごとの16ビット感圧レポート、ベロシティ加重合成。ベアメタルカーネルに \texttt{CONFIG\_HIDRAW=y} が必要。
178
+
\item \textbf{表情コントローラとしてのタッチパッド}：X軸がリバーブウェットミックスを制御、Y軸がピッチシフトを制御。これらのマッピングは \texttt{notepat} の演奏スタイル向けに設計されており、まだ汎用化されていない。
179
+
\item \textbf{HDMI補助ディスプレイ}：パフォーマンス中に混合ノートカラーで駆動される単色出力。ライブ使用に駆動されて2026年3月に \texttt{ac-native} に追加。
180
+
\end{enumerate}
181
+
182
+
\subsection{ビジュアルデザイン}
183
+
184
+
インターフェースは単純な色付き矩形からレイヤードシステムへ進化した：
185
+
186
+
\begin{itemize}
187
+
\item 24セル分割グリッド（左オクターブ4$\times$3 + 右オクターブ4$\times$3）、
188
+
\item ステータスバー：時計（夏時間対応のロサンゼルス時間）、波形、オクターブ、サンプルレート、音量、バッテリー、WiFiアンテナアイコン、
189
+
\item オクターブ色分けと黒鍵ドット付きミニピアノキーボード表示、
190
+
\item MatrixChunky8フォントのHUDラベル、\texttt{.com} 上付きブランディング、
191
+
\item 時間帯による背景色変化（夜明け/正午/午後/夕焼け/夜）、
192
+
\item ノートカラーシステム：各半音がひとつの色相にマッピング（C = 赤からB = 紫）、アクティブノートが背景にブレンド。
193
+
\end{itemize}
194
+
195
+
\subsection{DAW統合：Ableton Live}
196
+
197
+
2025年1月、\texttt{notepat} をAbleton Liveに埋め込むためのアルファ版Max for Liveデバイス（\texttt{AC Notepat.amxd}）が作成された。デバイスはMax~9の \texttt{jweb\textasciitilde} オブジェクト——オーディオ対応の埋め込みWebブラウザ——を使用して \texttt{notepat} ピースをロードし、\texttt{plugout\textasciitilde} を通じてWeb Audio出力をAbletonのミキサーに直接ルーティングする。
198
+
199
+
この統合にはブラウザやベアメタル環境にはない複数の問題への対処が必要だった：
200
+
201
+
\begin{itemize}
202
+
\item \textbf{オフラインバンドル}：自己完結型HTMLバンドルジェネレータ（\texttt{bundle-html.js}）がすべてのESモジュール依存を再帰的に検出し、フォントグリフをインライン化し、仮想ファイルシステム（VFS）とfetchインターセプタを備えたgzip圧縮自己展開HTMLファイルを生成。
203
+
\item \textbf{PACKモードのAudioWorklet}：標準AudioWorkletロードパスはサーバーが必要。バンドル版はVFSからblob URLを作成してプリバンドルされたspeaker worklet（\texttt{speaker-bundled.mjs}、約50\,KB）をロード。
204
+
\item \textbf{MIDIからキーボードへの変換}：MIDIノートオン/オフイベントを \texttt{notepat} のキーボードイベントモデルに変換する計画中のマッピングレイヤー、CC1（モジュレーションホイール）がリバーブミックスを制御、ピッチベンドがグライドモードを制御。
205
+
\end{itemize}
206
+
207
+
並行するVST3プラグイン作業（\texttt{ac-vst/}）は、WebViewベースのUIを持つC++ Steinberg SDKベースのプラグインをスキャフォールドし、Max for Liveよりポータブルな配布パスを目指す。両作業はアルファ段階。workletロード制限のため、オフラインバンドル環境ではオーディオエンジンがまだ動作していない。
208
+
209
+
DAW統合は \texttt{notepat} の政治経済学における5番目のフィードバックループを表す：\textbf{配布圧力 $\rightarrow$ バンドルインフラ}。プロの音楽制作環境で \texttt{notepat} を提供したいという欲求がプラットフォームにオフラインHTMLバンドル、VFSエミュレーション、workletプリバンドル機能の開発を強いた——他のどのピースも要求していないインフラである。
210
+
211
+
\subsection{ネットワークとシステム統合}
212
+
213
+
\begin{itemize}
214
+
\item WiFi UI：信号強度バー付きのフルスクリーンネットワークスキャナー、SSID選択、パスワード入力——OS UIのないベアメタル環境向けにピース自体に組み込み。
215
+
\item ダークモード：ロサンゼルス時間の夜7時/朝7時で自動切替、CとJavaScriptの両方に一致する夏時間計算。
216
+
\item パフォーマンスシナリオ用のプロジェクターとコンサートモード。
217
+
\end{itemize}
218
+
219
+
\section{ベアメタル移植}
220
+
221
+
2024年末、\texttt{notepat} は \texttt{ac-native} に移植された：USBから起動し、PID~1として動作する、OS不要のカスタムLinuxランタイム。ベアメタル版（987行）はQuickJS上で動作し、DRM/KMSダムバッファに3$\times$ニアレストネイバーCPUアップスケールでレンダリングし、直接ALSA \texttt{hw:} アクセスで192\,kHzのオーディオを合成する。
222
+
223
+
ベアメタルLinux環境にリアルタイムオーディオシンセサイザーを埋め込むのは活発な研究領域である。\citet{turchet2021elk} はElk Audio OS——Xenomaiリアルタイムカーネル拡張を使用した組み込みハードウェア上のサブミリ秒オーディオレイテンシのためのLinuxベースOS——を最先端として記述した。\texttt{ac-native} のアプローチは異なる：汎用組み込みオーディオOSではなく、RTOSレイヤーのない単一ピースランタイムであり、大きなALSA周期バッファ（192\,kHzで128サンプル）と32音ポリフォニー対応のピュアソフトウェア合成エンジンに依存する。
224
+
225
+
この移植は付随的なものではなかった。\texttt{ac-native} プロジェクト全体——カスタムカーネル設定、initramfsビルドパイプライン、ALSAオーディオエンジン、evdev入力処理、\texttt{wpa\_supplicant} によるWiFi管理、DRM/KMSディスプレイ——は主に物理ハードウェア上で \texttt{notepat} を専用楽器として動作させるために構築された。ピースがプラットフォームを正当化した。
226
+
227
+
起動シーケンスはこのコミットメントを反映する：カーネル初期化後、\texttt{ac-native} はレインボーアニメーションタイトルを表示し、デフォルトピースとして \texttt{notepat.mjs} をロードする。楽器は電源投入後約2秒で演奏可能となる。
228
+
229
+
\section{派生作品と再利用}
230
+
231
+
6つのアーティファクトが \texttt{notepat} から直接派生した：
232
+
233
+
\begin{enumerate}
234
+
\item \textbf{\texttt{autopat.mjs}}（214行）：内蔵ジュークボックス（Twinkle、Bachの断片、スケール）を持つ自動再生ラッパー。\texttt{notepat} のコアライフサイクル関数をインポートしデリゲート。
235
+
\item \textbf{\texttt{notepat-tv.mjs}}（55行）：アートインスタレーション用のUDP駆動リモートビジュアライザー。ノートデータを受信し投影面上でタートルグラフィックスを駆動。
236
+
\item \textbf{\texttt{notepat-convert.mjs}}（103行）：記譜変換ライブラリ。単一文字のキーボードショートカットを拡張メロディ構文に変換。\texttt{clock}、\texttt{stample}、他の音楽ピースで再利用。
237
+
\item \textbf{ベアメタル \texttt{notepat.mjs}}（987行）：QuickJS用に独立して再実装、キーボードマッピングとUI規約を共有するが直接ハードウェアアクセスに適応。
238
+
\item \textbf{\texttt{AC Notepat.amxd}}（Max for Liveデバイス）：\texttt{jweb\textasciitilde} を介して \texttt{notepat} をAbleton Liveに埋め込み、Web Audio合成をDAWミキサーに直接ルーティング。アルファ版、2025年1月。
239
+
\item \textbf{\texttt{ac-vst} プラグイン}（C++/Steinberg SDK）：DAC非依存配布用のWebView UIを持つVST3スキャフォールド。MIDI入力処理、オーディオバスルーティング、パラメータオートメーションスタブを含む。
240
+
\end{enumerate}
241
+
242
+
\section{生み出されたインフラストラクチャ}
243
+
244
+
\subsection{ルーティングとブランディング}
245
+
246
+
ドメイン \texttt{notepat.com} はエッジでメインインデックス関数の \texttt{notepat} スラグに書き換えられる。これには専用のホストマッチングロジック、カスタムOpen Graphメタデータ、演奏中に表示されるブランドHUD要素が必要だった。\texttt{notepat} はシステム内で独自のドメインを持つ唯一のピースである。楽器HUDに表示される \texttt{.com} 上付き文字は、この二重のアイデンティティを演奏インターフェース自体にエンコードしている。
247
+
248
+
\subsection{テストインフラストラクチャ}
249
+
250
+
\texttt{notepat} は他のピースと比較して不釣り合いなテスト投資を持つ：
251
+
252
+
\begin{itemize}
253
+
\item \textbf{レイテンシテストフレームワーク}（\texttt{artery/test-notepat-latency.mjs}）：Chrome DevTools Protocolを通じてキーボードからサウンドまでのレイテンシを測定。平均、中央値、p95、p99を報告。現在の測定値：417\,ms（目標：$<$30\,ms）。
254
+
\item \textbf{安定性テストフレームワーク}（\texttt{artery/test-notepat-stability.mjs}）：設定可能な強度（2--20ノート/秒）で5分間のファズテスト。ヒープ増加、サウンド辞書サイズ、レイテンシ劣化を監視。最新結果：3,229ノート、$-$14\%ヒープ、警告0。
255
+
\item \texttt{artery/}、\texttt{tests/}、\texttt{.vscode/tests/} にまたがる14のテストスクリプト。
256
+
\end{itemize}
257
+
258
+
レイテンシギャップ（417\,ms vs.\ 30\,ms目標）は未解決の研究課題を表す。既知のブラウザオーディオスケジューリング制約とJavaScriptからのWeb Audio APIイベントディスパッチコストと一致する。このギャップはベアメタル版では発生しない。192\,kHzのALSA \texttt{hw:} アクセスと直接evdevポーリングにより10\,ms以下のアタックレイテンシが実現される。
259
+
260
+
\subsection{ピースアクセス分析}
261
+
262
+
ピースアクセス追跡システム（\texttt{/api/piece-hit}）は2025年12月に構築された。サーバーサイドでページロードをMongoDBに記録し、システムピースとユーザーピースを区別する。初期テレメトリーウィンドウ（2025-12-31から2026-01-02）で、\texttt{notepat} は27アクセスを記録し、追跡対象の44の組み込みピース中4位。現在の計測限界——型付き名前空間なし、認証帰属なし、Netlify Functionsランタイム完了前に終了するfire-and-forget POST呼び出し——により、2024年以降の \texttt{notepat} 使用状況の全体像は捕捉されていない。fire-and-forgetバグは2026年3月に特定・修正された。
263
+
264
+
\section{ピースの政治経済学}
265
+
266
+
Kurzweilの「加速するリターンの法則」は、技術システムが加速度的に能力を蓄積する様を記述する。各進歩が次の進歩の条件を作るからである~\citep{kurzweil2005singularity}。単一のクリエイティブピースのスケールでも類似のダイナミクスが見える。\texttt{notepat} の軌跡はピースとそのホストプラットフォーム間のフィードバックループを示す。\citet{nieborg2018platformization} が文化産業レベルで記述したダイナミクスである：プラットフォーム機能が制作を形成し、制作の要求がプラットフォームを再形成する。
267
+
268
+
\begin{enumerate}
269
+
\item \textbf{機能圧力 $\rightarrow$ プラットフォーム能力}：\texttt{notepat} がリバーブを必要とし、オーディオエンジンが遅延線を獲得。アナログ感圧が必要となり、\texttt{ac-native} がHID rawサポートを獲得。補助ディスプレイが必要となり、HDMI出力がDRMバックエンドに追加された。
270
+
\item \textbf{ブランド圧力 $\rightarrow$ ルーティング決定}：覚えやすいURLへの欲求が \texttt{notepat.com} につながり、エッジ関数ホスト書き換えとカスタムソーシャルプレビューが必要となった。
271
+
\item \textbf{品質圧力 $\rightarrow$ テスト投資}：\texttt{notepat} のレイテンシ退行が汎用ピーステストフレームワーク（artery）の構築を推進し、これが現在すべてのピースに恩恵をもたらしている。
272
+
\item \textbf{ハードウェア圧力 $\rightarrow$ ランタイム全体}：専用ハードウェアで \texttt{notepat} を動作させる野心が \texttt{ac-native} の構築を正当化した：カスタムカーネル、initramfs、ALSAエンジン、DRMディスプレイ、WiFiスタック——数千行のCコード。
273
+
\item \textbf{配布圧力 $\rightarrow$ バンドルインフラ}：Ableton Liveに \texttt{notepat} を埋め込む欲求がプラットフォームに仮想ファイルシステム、fetchインターセプタ、プリバンドルAudioWorkletsを持つオフラインHTMLバンドルの開発を強いた——他のどのピースも要求していないインフラ。
274
+
\end{enumerate}
275
+
276
+
\citet{born2015music} は音楽技術投資が決して中立でないことを観察した——構築者と資金提供者の美的優先順位、社会的地位、リソースを反映し強化する。\texttt{notepat} の軌跡はこれを個人開発者と単一のオープンソース楽器のスケールで可視化する：1つのピースへの持続的な個人投資がシステム内の他のすべてのピースにとって技術的に何が可能かを実質的に形成する。
277
+
278
+
ライブコーディングコミュニティはこの実践とツールの関係について明示的な語彙を発展させている~\citep{blackwell2022livecoding}：楽器と演奏者は共進化する。\texttt{notepat} の401回のコミットはこの共進化を非ライブコーディングの文脈で記録する——事前設計ではなく使用を通じて能力を蓄積する永続的楽器。
279
+
280
+
\section{現在の規模}
281
+
282
+
表~\ref{tab:scale} は2026年3月8日時点の \texttt{notepat} の規模をまとめる。
283
+
284
+
\begin{table}[h]
285
+
\small
286
+
\centering
287
+
\begin{tabularx}{\columnwidth}{l r}
288
+
\toprule
289
+
\textbf{指標} & \textbf{値} \\
290
+
\midrule
291
+
コミット数（ブラウザ版） & 401 \\
292
+
ブラウザコード行数 & 7{,}903 \\
293
+
ベアメタルコード行数 & 987 \\
294
+
派生作品 & 6 \\
295
+
エコシステム総コード行数 & 9{,}262 \\
296
+
波形タイプ & 5 \\
297
+
専用テストスクリプト & 14 \\
298
+
リポジトリ中``notepat''を含むファイル & 159 \\
299
+
年齢（初回コミット） & 2024年6月27日 \\
300
+
\bottomrule
301
+
\end{tabularx}
302
+
\caption{notepatの規模指標（2026年3月8日）。}
303
+
\label{tab:scale}
304
+
\end{table}
305
+
306
+
\section{結論}
307
+
308
+
\texttt{notepat} は単一のピースがクリエイティブコンピューティングプラットフォームの戦略的重心として機能しうることを実証する。200行のキーボードスケッチから独自のドメイン、ハードウェアランタイム、DAW統合、テストインフラを持つ9,000行のエコシステムへの成長は計画されたものではなく、継続的な使用と上述のフィードバックループから創発した。
309
+
310
+
方法論的貢献は分析の単位：\emph{ピース軌跡}。単一ピースの完全なコミット履歴——獲得した機能、生み出したインフラ、派生した作品——を研究することで、システムレベルでは見えないプラットフォームダイナミクスが明らかになる。デジタル楽器研究はDMIの寿命を採用問題として~\citep{marquez2018dmi}、またDMIを計算的基盤のプローブとして検討してきた~\citep{tahiroglu2020probes}。ピース軌跡はこれら2つの視点を政治経済学の視点と組み合わせる：楽器は能力を蓄積し、その蓄積はそれを支えるシステムに実質的な帰結をもたらす。
311
+
312
+
\bibliographystyle{plainnat}
313
+
\bibliography{references}
314
+
315
+
\end{document}
+441
papers/arxiv-open-schools/open-schools-cards.tex
+441
papers/arxiv-open-schools/open-schools-cards.tex
···
1
+
% !TEX program = xelatex
2
+
% Cards format — auto-generated from open-schools.tex by cards-convert.mjs
3
+
\documentclass[11pt]{article}
4
+
5
+
\usepackage{fontspec}
6
+
\usepackage{unicode-math}
7
+
\setmainfont{Latin Modern Roman}
8
+
\setsansfont{Latin Modern Sans}
9
+
\setmonofont{Latin Modern Mono}[Scale=0.88]
10
+
11
+
12
+
\usepackage{graphicx}
13
+
\graphicspath{{figures/}{../arxiv-ac/figures/}}
14
+
\usepackage{booktabs}
15
+
\usepackage{tabularx}
16
+
\usepackage{ragged2e}
17
+
\usepackage{microtype}
18
+
\usepackage{natbib}
19
+
20
+
21
+
22
+
\makeatletter
23
+
\def\input@path{{../}}
24
+
\makeatother
25
+
\usepackage{ac-paper-cards}
26
+
27
+
% Extra commands from base paper
28
+
\newcommand{\acos}{\textsc{AC Native OS}}
29
+
30
+
\hypersetup{
31
+
pdftitle={Get Closed Source Out of Schools: Every Chromebook Is a Gateway Denied},
32
+
}
33
+
34
+
\renewcommand{\acpdfbase}{open-schools-26-arxiv}
35
+
\begin{document}
36
+
37
+
% ============================================================
38
+
% TITLE CARD
39
+
% ============================================================
40
+
\thispagestyle{empty}
41
+
\vspace*{\fill}
42
+
\begin{center}
43
+
\includegraphics[height=9em]{pals}\par\vspace{0.1em}
44
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} Get Closed Source Out of Schools}\par
45
+
\vspace{0.1em}
46
+
\vspace{0.3em}
47
+
{\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par
48
+
{\small\color{acgray} Aesthetic.Computer}\par
49
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
50
+
\vspace{0.4em}
51
+
\rule{0.5\textwidth}{0.5pt}\par
52
+
\vspace{0.15em}
53
+
\colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par
54
+
\vspace{0.1em}
55
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/2113ef735}{2113ef735}}\par
56
+
\vspace{0.1em}
57
+
{\footnotesize\color{acgray}\href{https://papers.aesthetic.computer/open-schools-26-arxiv-da-cards.pdf}{Dansk} · \href{https://papers.aesthetic.computer/open-schools-26-arxiv-es-cards.pdf}{Español} · \href{https://papers.aesthetic.computer/open-schools-26-arxiv-zh-cards.pdf}{{\accjk 中文}} · \href{https://papers.aesthetic.computer/open-schools-26-arxiv-ja-cards.pdf}{{\accjk 日本語}}}\par
58
+
\end{center}
59
+
\vspace*{\fill}
60
+
61
+
% ============================================================
62
+
% INDEX CARD
63
+
% ============================================================
64
+
\cardindex
65
+
66
+
% ============================================================
67
+
% ABSTRACT CARD
68
+
% ============================================================
69
+
\clearpage
70
+
\begin{accentcard}
71
+
\cardtitle{Abstract}
72
+
73
+
\noindent
74
+
There are over 50 million Chromebooks in American schools. Each one is a capable computer running a locked-down, closed-source operating system that funnels every student interaction through Google's surveillance infrastructure. The student cannot see how the machine works. The student cannot modify the machine. The student cannot own the machine in any meaningful sense. In the age of large language models---when ``everyone is a programmer'' is no longer a slogan but a material reality---this is an act of educational malpractice. This paper argues that every student deserves a free and open operating system stack: one where the Chromebook becomes a gateway to the student's own path through logic, creativity, the internet, community, and the computational landscape as a whole. We present the technical, pedagogical, economic, and political case for replacing closed-source school computing infrastructure with open alternatives, drawing on international precedents from Kerala, Schleswig-Holstein, and France, environmental data on planned obsolescence, federal and state legal actions against student surveillance, and emerging research on AI-assisted programming education. We present \acos{}~\citep{scudder2026acos} as one concrete implementation of this vision.
75
+
\end{accentcard}
76
+
77
+
% ============================================================
78
+
% BODY
79
+
% ============================================================
80
+
\section{The Chromebook Problem}
81
+
82
+
In 2012, Google began aggressively marketing Chromebooks to American school districts. The pitch was simple: cheap hardware, zero IT overhead, everything in the cloud. By 2026, Chromebooks account for roughly 60\% of devices shipped to U.S. K--12 schools, with an installed base exceeding 50 million units~\citep{google2024chromeos}. An entire generation of American students is being educated on machines they cannot understand, cannot modify, and do not own---even when the school paid for them.
83
+
84
+
ChromeOS is proprietary software. Its source is not available for inspection. The browser is the entire interface. Every document lives in Google Drive. Every search goes through Google. Every interaction is logged, analyzed, and used to build behavioral profiles that follow the student into adulthood~\citep{zuboff2019surveillance}.
85
+
86
+
This is not a privacy concern at the margins. This is the \emph{architecture} of how American children learn to use computers. The medium is the message~\citep{mcluhan1964understanding}: the Chromebook teaches that a computer is a device for consuming cloud services owned by a corporation. It teaches that your work lives on someone else's server. It teaches that the machine is not yours to understand.
87
+
88
+
\subsection{What the Student Cannot Do}
89
+
90
+
On a school Chromebook, a student cannot:
91
+
92
+
\begin{itemize}
93
+
\item Install a programming language runtime (Python, Node.js, GCC)
94
+
\item Run a local web server or compile code
95
+
\item Inspect the operating system source
96
+
\item Modify the boot sequence
97
+
\item Connect to hardware peripherals for physical computing
98
+
\item Use the machine offline for serious work
99
+
\item Keep their data on the device without cloud sync
100
+
\item Choose their own software
101
+
\item Understand what the machine is doing with their attention
102
+
\end{itemize}
103
+
104
+
ChromeOS includes a Linux container (Crostini) that could theoretically provide these capabilities, but school IT administrators almost universally disable it. The machine ships with a terminal and then locks it shut. Every one of these restrictions is a door closed. Every closed door is a path the student will never discover. The Chromebook is not a gateway---it is a \emph{gate}.
105
+
106
+
\subsection{The Cloud as Landlord}
107
+
108
+
When a student's work lives in Google Drive, they are tenants, not owners. Google can change the terms of service. Google can discontinue products. Google can revoke access. The student graduates and loses their school Google account---and with it, every document, every project, every creative artifact they produced during their education.
109
+
110
+
This is not hypothetical. It happens every year, in every school district. Students lose access to years of work because the institution that purchased their cloud account decommissions it. The architecture \emph{guarantees} this outcome: the student never had their files. They had permission to access files on Google's servers, and that permission was revoked.
111
+
112
+
Freire called this the ``banking model'' of education~\citep{freire1970pedagogy}: knowledge deposited into students by authorities. The Chromebook literalizes the metaphor. The student's work is deposited into a bank they do not control, cannot audit, and will eventually be locked out of.
113
+
114
+
\subsection{Planned Obsolescence: The AUE Problem}
115
+
116
+
Every Chromebook ships with an Auto Update Expiration (AUE) date, after which Google provides no security patches, no feature updates, and no browser updates. Historically set at 6.5 years from the \emph{platform's} first release---not the purchase date---a school buying a Chromebook late in a platform cycle might receive only 3--4 years of updates. Google extended this to 10 years for devices launched in 2024, but the installed base of shorter-lived machines remains enormous.
117
+
118
+
The U.S. PIRG Education Fund estimated that AUE policies would force the premature disposal of 21.5 million functionally working Chromebooks by 2024, costing schools approximately \$1.8 billion in unnecessary replacements~\citep{pirg2023chromebook}. These are machines with working processors, working screens, working keyboards---rendered obsolete by a software policy, not by hardware failure.
119
+
120
+
The contrast with Linux is absolute. A 2015 ThinkPad running Ubuntu LTS continues to receive security updates indefinitely. There is no artificial expiration date tied to the hardware model. The machine remains useful as long as the hardware functions.
121
+
122
+
% ============================================================
123
+
% 2. THE SURVEILLANCE MACHINE
124
+
% ============================================================
125
+
126
+
\section{The Surveillance Machine}
127
+
\label{sec:surveillance}
128
+
129
+
Google provides Chromebooks to schools below cost because students are a captive market for behavioral data~\citep{zuboff2019surveillance, doctorow2020attack}. A student who grows up in the Google ecosystem---Gmail, Google Docs, Google Drive, Google Classroom, YouTube---is a customer for life. The Chromebook is not a charitable donation. It is a customer acquisition strategy deployed against children.
130
+
131
+
\subsection{What Google Collects}
132
+
133
+
The data collected from student Chromebooks includes:
134
+
135
+
\begin{itemize}
136
+
\item Every search query and every website visited
137
+
\item Every document opened, edited, and shared
138
+
\item Every YouTube video watched and for how long
139
+
\item Keystroke timing patterns and login frequency
140
+
\item Location data (on cellular models)
141
+
\item Social graphs (who collaborates with whom in Google Docs)
142
+
\item Device diagnostics and app usage telemetry
143
+
\end{itemize}
144
+
145
+
Google claims that data collected under Workspace for Education ``core services'' is not used for advertising. But ``additional services''---YouTube, Google Search, Google Maps when signed in---operate under different terms. Students on school Chromebooks use these additional services constantly, and the data flows to Google's advertising infrastructure.
146
+
147
+
\subsection{Legal Actions}
148
+
149
+
The legal record is damning. In 2019, Google paid \$170 million to the FTC and New York Attorney General for YouTube's COPPA violations---collecting data from children without parental consent~\citep{google2019coppa}. In 2020, New Mexico Attorney General Hector Balderas sued Google directly for collecting personal data from children using Chromebooks in schools~\citep{newmexico2020google}. The EFF filed an FTC complaint in 2015 documenting that Google was data-mining student browsing activity through Chromebooks~\citep{eff2015chromebook}. In 2024, a coalition of digital rights organizations filed additional FTC complaints regarding ongoing student surveillance~\citep{eff2024monitoring}. Class actions alleging biometric data collection from students under Illinois' BIPA statute are ongoing.
150
+
151
+
This data is collected from minors, in an institutional setting where participation is mandatory, on machines the student did not choose and cannot configure. The student cannot opt out. The parent often cannot opt out. The school district signed a contract, and the children are bound by it.
152
+
153
+
\subsection{Monitoring Software}
154
+
155
+
Beyond Google's own data collection, school districts layer additional surveillance software---Gaggle, GoGuardian, Securly---onto Chromebooks. The EFF documented that these tools surveil private communications and disproportionately target disadvantaged, minority, and LGBTQ youth~\citep{eff2024monitoring}. Of 152 ed-tech services surveyed by the EFF, only 118 had published privacy policies; far fewer addressed data retention, encryption, or de-identification.
156
+
157
+
Winner argued that artifacts have politics~\citep{winner1980artifacts}. The Chromebook's politics are clear: it is an instrument of surveillance deployed in a context where the surveilled have no choice, no recourse, and no understanding of what is being taken from them.
158
+
159
+
A free and open operating system collects no telemetry. It phones home to no corporation. It builds no behavioral profile. The student's attention, their curiosity, their mistakes, their explorations---all of these remain private, because the machine has no economic incentive to observe them.
160
+
161
+
% ============================================================
162
+
% 3. THE LLM INFLECTION
163
+
% ============================================================
164
+
165
+
\section{Everyone Is a Programmer Now}
166
+
167
+
Large language models have changed the economics of programming. A student who can describe what they want in natural language can produce working code. The barrier to computational creation has collapsed from ``years of technical training'' to ``the ability to articulate an idea.'' Karpathy's observation that ``the hottest new programming language is English'' is no longer hyperbole---it is a description of material reality.
168
+
169
+
This is the most important shift in computing since the personal computer. And it makes the Chromebook problem \emph{catastrophically worse}.
170
+
171
+
\subsection{The New Literacy}
172
+
173
+
If everyone can program, then programming is literacy. And literacy requires tools the literate person can own. You do not teach a child to read by giving them a locked book that can only be opened in a specific building with a specific corporate account. You give them the book. They take it home. They read it in bed. They write in the margins. They lend it to a friend.
174
+
175
+
A student with an LLM and an open operating system can:
176
+
177
+
\begin{itemize}
178
+
\item Build a tool to organize their homework
179
+
\item Write a game and share it with classmates
180
+
\item Automate a repetitive task their teacher assigns
181
+
\item Create a small business selling software to their community
182
+
\item Contribute to open-source projects that serve humanity
183
+
\item Understand and modify the systems that govern their digital life
184
+
\item Explore logic, mathematics, and language through direct manipulation
185
+
\item Build instruments for artistic expression
186
+
\end{itemize}
187
+
188
+
A student with an LLM and a Chromebook can use Google Docs faster.
189
+
190
+
Ko (University of Washington) has argued that if AI can write code, CS education must shift toward systems thinking, debugging, and evaluation---all of which require access to real development environments, not sandboxed browsers~\citep{denny2024computing}. Krishnamurthi (Brown University) has been critical of approaches that reduce programming to prompting. The emerging consensus in CS education research is that LLMs make full-stack access \emph{more} important, not less~\citep{prather2024robots}: students need to run, debug, modify, and understand generated code. Chromebooks make all four harder.
191
+
192
+
\subsection{The Chromebook Cannot Execute}
193
+
194
+
Here is the concrete failure: the LLM produces a Python script, and the Chromebook cannot run it. The LLM generates a web server, and the Chromebook cannot host it. The LLM writes C code, and the Chromebook has no compiler. The LLM teaches the student how an operating system works, and the Chromebook will not let them inspect one.
195
+
196
+
On a typical school Chromebook (MediaTek or Celeron processor, 4\,GB RAM), even the Linux container---when enabled---struggles to run basic development toolchains. Running a local LLM is physically impossible: even a quantized 1B parameter model requires more memory than most school Chromebooks possess.
197
+
198
+
The alternative is trivial. A surplus ThinkPad with 8\,GB RAM running Linux can execute any LLM-generated code, run a local 3B parameter model via Ollama at interactive speeds, host a web server, compile programs, and give the student root access to the entire system. The hardware exists. The software is free. The Chromebook is the bottleneck.
199
+
200
+
\subsection{The Spiritual Dimension}
201
+
202
+
This is not only about economics or career preparation. There is a spiritual dimension to computing that the Chromebook architecture annihilates.
203
+
204
+
When a student writes a program that does something they did not expect---when the machine surprises them with emergent behavior from rules they defined---they experience something profound. They encounter the boundary between intention and consequence. They learn that systems have their own logic. They develop a relationship with abstraction itself.
205
+
206
+
Papert understood this~\citep{papert1980mindstorms}: Logo was not about teaching programming. It was about giving children a medium for thinking about thinking. The turtle was a vehicle for epistemology.
207
+
208
+
LLMs amplify this a thousandfold. A student can now have a \emph{conversation} with the computational medium. They can ask ``what if?'' and get an answer in seconds. They can iterate on ideas at the speed of thought. They can explore paths that no curriculum anticipated.
209
+
210
+
But only if the machine lets them. A Chromebook does not let them. A Chromebook says: you may consume services. You may not create infrastructure. You may not run your own code in your own way on your own machine.
211
+
212
+
% ============================================================
213
+
% 4. WHAT STUDENTS DESERVE
214
+
% ============================================================
215
+
216
+
\section{What Every Student Deserves}
217
+
218
+
Every student deserves a computer that:
219
+
220
+
\begin{enumerate}
221
+
\item \textbf{They can understand.} The source code of the operating system should be available for inspection. Not as an abstract principle, but as a practical reality: the student should be able to read the code that runs when they press a key.
222
+
223
+
\item \textbf{They can modify.} If the student wants to change how the machine behaves, they should be able to. Not through an app store, not through a settings panel, but by changing the code.
224
+
225
+
\item \textbf{They can own.} The student's work should live on the student's machine. Not on a corporate server, not in a cloud account that will be decommissioned when they graduate.
226
+
227
+
\item \textbf{They can share.} The student should be able to give their software to a friend. Not through a platform, not through a marketplace, but by copying a file.
228
+
229
+
\item \textbf{They can break.} The student should be able to break the machine and fix it. This is how you learn. A system that cannot be broken cannot be understood.
230
+
231
+
\item \textbf{They can take with them.} When the student leaves the school, the computer---and everything on it---goes with them. Their computational life is not leased. It is theirs.
232
+
233
+
\item \textbf{Respects their attention.} The operating system should not contain advertising, behavioral tracking, or engagement optimization. The student's attention belongs to the student.
234
+
235
+
\item \textbf{Connects them to community.} The student should be able to contribute to the computational landscape---to write code that others use, to participate in open-source projects, to build tools that serve their community and maintain their lifestyle and wellbeing.
236
+
\end{enumerate}
237
+
238
+
Every one of these requirements is violated by ChromeOS. Every one of them is satisfied by a free and open operating system.
239
+
240
+
% ============================================================
241
+
% 5. IT ALREADY WORKS
242
+
% ============================================================
243
+
244
+
\section{It Already Works: International Precedents}
245
+
246
+
The objection that open-source school computing is untested is false. It has been tested, at scale, on three continents.
247
+
248
+
\subsection{Kerala, India: 16,000 Schools}
249
+
250
+
Kerala's KITE (Kerala Infrastructure and Technology for Education) program moved entirely to free software in 2007 across 16,000+ public schools. KITE GNU/Linux 22.04, released in August 2024, runs on over 300,000 school computers~\citep{kite2024gnulinux}. The distribution includes educational software (Krita, GCompris, PictoBlox), basic AI/ML teaching tools, and a Wayland display server. The estimated savings: 30 billion INR (approximately \$400 million). Over 150,000 primary teachers have been trained. India's National Law School hailed KITE as the national benchmark for open-source transformation in education.
251
+
252
+
This is not a pilot program. It is a state-wide deployment serving millions of students, running continuously for nearly two decades.
253
+
254
+
\subsection{Schleswig-Holstein, Germany: 30,000 PCs}
255
+
256
+
By end of summer 2025, the German state of Schleswig-Holstein completed migration of nearly 30,000 government PCs from Microsoft to Linux, with an additional 30,000 public school teachers expected to follow~\citep{schleswig2025linux}. Replacements include LibreOffice, Nextcloud, Open-Xchange, and Mozilla Thunderbird. Estimated savings: 15 million EUR in 2026 alone. Denmark announced a similar transition between June and November 2025.
257
+
258
+
\subsection{France: National Open-Source Strategy}
259
+
260
+
France's Digital Education Strategy 2023--2027, led by Alexis Kauffmann at the Ministry of Education, explicitly targets digital sovereignty and reduced dependence on Microsoft and Google~\citep{france2023digital}. The national platform \texttt{apps.education.fr} provides open-source tools to all French teachers. In 2025, France enacted an interoperability decree requiring schools to use digital tools complying with open standards---creating a structural advantage for open-source solutions.
261
+
262
+
\subsection{Penn Manor, Pennsylvania: 1,725 Linux Laptops}
263
+
264
+
In the United States, Penn Manor School District in Lancaster, PA deployed 1,725 Ubuntu laptops to students in grades 9--12~\citep{pennmanor2024linux}. The program includes a student-run repair initiative where students learn to fix their own machines. This is not a special district with special funding. It is a public school district that made a different choice.
265
+
266
+
\subsection{The ``Public Money, Public Code'' Movement}
267
+
268
+
The Free Software Foundation Europe's ``Public Money? Public Code!'' campaign---arguing that software developed with public funds should be released under free licenses---has gathered over 200 civil society organizations and 31,000 individual signatories~\citep{fsfe2024publiccode}. UNESCO's 2024 Dubai Declaration on Open Educational Resources formally commits signatories to advancing open resources through AI and emerging technologies~\citep{unesco2024oer}. The Global Digital Compact commits to ``developing, disseminating, and maintaining open-source software, open data, open AI models, and open standards that benefit society.''
269
+
270
+
These are not fringe movements. They are the direction of international policy.
271
+
272
+
% ============================================================
273
+
% 6. THE ECONOMICS
274
+
% ============================================================
275
+
276
+
\section{The Economics}
277
+
278
+
\subsection{The Cost Excuse}
279
+
280
+
Chromebooks are cheap. But so are surplus laptops running Linux. A retired ThinkPad T480 or Dell Latitude 5400 costs \$100--180 in bulk and is a superior machine in every dimension except ``managed by Google.'' The cost argument for Chromebooks is an argument for Google's ecosystem, not for the hardware.
281
+
282
+
\begin{table}[H]
283
+
\small
284
+
\centering
285
+
\begin{tabular}{lrr}
286
+
\toprule
287
+
\textbf{Approach} & \textbf{Cost} & \textbf{Student Owns It} \\
288
+
\midrule
289
+
Chromebook (new) & \$250--350 & No \\
290
+
Chrome Edu Upgrade & +\$38/device & No \\
291
+
Google Workspace Plus & +\$5/student/yr & No \\
292
+
iPad (edu) & \$299+ & No \\
293
+
\midrule
294
+
Surplus laptop + Linux & \$100--180 & \textbf{Yes} \\
295
+
Surplus laptop + AC OS & \$100--180 & \textbf{Yes} \\
296
+
\bottomrule
297
+
\end{tabular}
298
+
\caption{Cost and ownership comparison. Chromebook costs exclude monitoring software (GoGuardian: \$5--10/device/year) and forced AUE replacements.}
299
+
\label{tab:cost}
300
+
\end{table}
301
+
302
+
When factoring in Google's Chrome Education Upgrade (\$38/device), Workspace for Education Plus (\$5/student/year), monitoring software, and the forced replacement cycle from AUE, the total cost of ownership for a Chromebook over 5 years can reach \$450--550/device. A surplus ThinkPad running Linux: \$100--180, with zero ongoing licensing costs, no artificial expiration, and the student keeps it.
303
+
304
+
\subsection{The Supply}
305
+
306
+
The machines exist. An estimated 50--60 million business PCs are retired annually in the United States. Corporate lease cycles retire millions of functional laptops every 3--5 years---machines with modern processors, 8--16\,GB RAM, WiFi, and 6--10 hour batteries. Organizations like PCs for People (100,000+ devices/year), Human-I-T (50,000+/year), Kramden Institute, Free Geek, and the federal Computers for Learning program already refurbish and distribute these machines.
307
+
308
+
A classroom of 30 creative computing instruments can be provisioned for \$3,000--5,400 in hardware. No ongoing subscription. No IT support contract. No managed accounts.
309
+
310
+
\subsection{The Environmental Case}
311
+
312
+
A typical laptop produces 300--400 kg CO$_2$e in manufacturing---70--80\% of its total lifetime carbon footprint. Refurbishment adds approximately 5--15 kg CO$_2$e. Circular Computing's independently audited analysis found 316 kg CO$_2$e saved per remanufactured laptop~\citep{circularcomputing2023carbon}. The UN Global E-waste Monitor 2024 reports that the US generates approximately 7.2 Mt of e-waste annually, with only 25\% properly recycled~\citep{un2024ewaste}.
313
+
314
+
Google's AUE policy forces schools to discard millions of working Chromebooks. Right-to-repair legislation is beginning to address this: Oregon's act (effective January 2025) requires manufacturers to provide parts and repair information~\citep{oregon2024repair}; New Hampshire's HB1701 explicitly covers school-provided laptops~\citep{newhampshire2024repair}. But legislation cannot fix a software policy that declares functional hardware obsolete.
315
+
316
+
Linux has no AUE. A laptop running a free operating system remains useful as long as the hardware functions.
317
+
318
+
% ============================================================
319
+
% 7. THE OPEN STACK
320
+
% ============================================================
321
+
322
+
\section{The Open Stack}
323
+
324
+
\subsection{Every Chromebook Is Already a Linux Machine}
325
+
326
+
Here is the absurdity: every Chromebook already runs the Linux kernel. ChromeOS is Linux with a locked-down userspace that forces all interaction through Google's browser. The hardware is perfectly capable of running a free operating system. Google took a free kernel, wrapped it in proprietary restrictions, and sold it to schools as a cost-saving measure.
327
+
328
+
The liberation of these machines does not require new hardware. It requires flashing new software. Many Chromebooks can be unlocked and reflashed with a standard Linux distribution or with \acos{}. The machine \emph{already wants to be free}. Google is the lock.
329
+
330
+
\subsection{The IT Excuse}
331
+
332
+
School IT departments choose Chromebooks because they are ``easy to manage.'' This is true. It is easy to manage a machine that does nothing. It is easy to administer a fleet when every device is a thin client for a single corporation's services. The ease of management is a direct consequence of the machine's powerlessness.
333
+
334
+
The question is: easy for whom? Easy for the IT department, certainly. But catastrophic for the student. The IT department's convenience is purchased with the student's autonomy. This is a bad trade.
335
+
336
+
Open-source management tools exist. NixOS provides reproducible system configurations. Ansible automates fleet deployment. PXE boot enables zero-touch provisioning. \acos{}~\citep{scudder2026acos} demonstrates that an entire OS can be deployed by flashing a USB drive in under a minute, with OTA updates requiring zero IT infrastructure. Penn Manor runs 1,725 Linux laptops with a smaller IT team than comparable Chromebook districts~\citep{pennmanor2024linux}. The ``management problem'' is solved. What remains is institutional inertia and a contractual relationship with Google that serves the institution, not the student.
337
+
338
+
\subsection{The LLM Infrastructure}
339
+
340
+
An open system enables a fundamentally different relationship with AI. A single surplus server (32--64\,GB RAM, or a used NVIDIA T4 GPU at \$100--200) can run Ollama and serve an entire classroom of students via Open WebUI---a free, open-source LLM frontend. Students connect from their laptops via a browser pointed at the local server. Models like Llama 3.2 3B (fits in 4\,GB), DeepSeek Coder 6.7B, or Qwen 2.5 Coder 7B provide strong code generation capability.
341
+
342
+
This is local AI infrastructure that the school owns, that collects no telemetry, that sends no data to any corporation, and that students can inspect, modify, and learn from. The alternative---Google Gemini integrated into Workspace for Education---adds another layer of corporate dependency, another data pipeline, another subscription fee.
343
+
344
+
% ============================================================
345
+
% 8. THE LLM GATEWAY
346
+
% ============================================================
347
+
348
+
\section{The Student as Author}
349
+
350
+
On an open system with LLM access, the student can:
351
+
352
+
\begin{itemize}
353
+
\item Ask the LLM to explain the operating system's source code
354
+
\item Generate programs that run locally, with full hardware access
355
+
\item Build web servers, databases, APIs---real infrastructure
356
+
\item Create tools that solve real problems in their community
357
+
\item Learn any programming language by building in it
358
+
\item Understand the LLM itself by examining its inputs and outputs
359
+
\item Create a piece on \ac{}~\citep{scudder2026ac} that anyone in the world can run
360
+
\end{itemize}
361
+
362
+
The LLM becomes a tutor with infinite patience, available 24 hours a day, that meets the student exactly where they are~\citep{khan2024bravenew}. But this tutor can only be effective if the student has a machine that can \emph{execute} what the tutor produces.
363
+
364
+
The Chromebook model says: you are a user. The open model says: you are an author. In the age of LLMs, the difference between these two framings is the difference between digital literacy and digital serfdom.
365
+
366
+
% ============================================================
367
+
% 9. A PATH FORWARD
368
+
% ============================================================
369
+
370
+
\section{A Path Forward}
371
+
372
+
\subsection{Phase 1: Awareness}
373
+
374
+
Parents, teachers, and school board members must understand what a Chromebook actually is: a surveillance device that teaches learned helplessness. The first step is education---not of the children, but of the adults who purchase the machines. The EFF's ``Spying on Students'' documentation, the U.S. PIRG's ``Chromebook Churn'' report, and the New Mexico AG's lawsuit provide concrete evidence that can be presented at school board meetings.
375
+
376
+
\subsection{Phase 2: Pilot Programs}
377
+
378
+
School districts should pilot open-source alternatives, following Penn Manor's model:
379
+
380
+
\begin{itemize}
381
+
\item 30 surplus laptops running Linux or \acos{}, provisioned for \$3,000--5,400
382
+
\item A local LLM server (one surplus workstation, \$200--500) running Ollama + Open WebUI
383
+
\item An LLM-assisted curriculum where students build real software
384
+
\item Student ownership: the machine goes home with the student
385
+
\item A student-run repair program (Penn Manor's students fix their own machines)
386
+
\item No cloud dependency: work is stored locally and backed up by the student
387
+
\item Open assessment: the student's portfolio is code they wrote, tools they built, contributions they made
388
+
\end{itemize}
389
+
390
+
\subsection{Phase 3: Policy}
391
+
392
+
States and districts should adopt policies requiring that:
393
+
394
+
\begin{enumerate}
395
+
\item All software deployed on student devices be open-source or source-available
396
+
\item Students have root access to their own machines
397
+
\item No behavioral telemetry is collected from student devices
398
+
\item Students retain ownership of all work produced on school devices
399
+
\item Graduating students keep their devices
400
+
\item Device procurement prioritize refurbished hardware over new manufacturing
401
+
\end{enumerate}
402
+
403
+
Over 40 states have passed student data privacy laws. California's SOPIPA prohibits using student data for targeted advertising. The new COPPA rules (effective June 2025) strengthen children's data protections. These legislative trends support the case for open, non-surveilling school computing infrastructure.
404
+
405
+
\subsection{Phase 4: Liberation}
406
+
407
+
The endgame is not a policy change. It is a cultural shift. The endgame is a generation of students who understand that a computer is not a product they consume but an instrument they play---a medium for thought, creation, and contribution. Students who can read source code the way they read books. Students who can modify their tools the way a carpenter modifies a workbench. Students who see computation not as a corporate service but as a public commons to which they both contribute and belong.
408
+
409
+
Nelson wrote in 1974~\citep{nelson1974computerlib}: ``You can and must understand computers NOW.'' Fifty years later, we have failed this imperative in precisely the way Nelson feared---by handing the machines to corporations and calling it progress.
410
+
411
+
The LLM moment makes this failure visible. Every student now has the \emph{capability} to program. What they lack is a \emph{machine that lets them}. This is a solvable problem. The technology is free. The hardware is surplus. The only thing standing between every student and their own computational path is a corporate operating system that was never designed to serve them.
412
+
413
+
% ============================================================
414
+
% 10. CONCLUSION
415
+
% ============================================================
416
+
417
+
\section{Conclusion}
418
+
419
+
Every Chromebook in every American school is a Linux machine in chains. The hardware can run a free operating system. The student can learn to program with an LLM. The surplus laptop market provides machines for \$100--180. The entire open-source stack is available at zero cost. Kerala has done it for 300,000 computers. Schleswig-Holstein has done it for 30,000. Penn Manor has done it for 1,725. It works.
420
+
421
+
What we lack is not technology. We lack the political will to prioritize student autonomy over institutional convenience and corporate profit.
422
+
423
+
Illich wrote that tools should expand personal autonomy rather than require specialized expertise~\citep{illich1973tools}. Papert wrote that computers should be instruments for thinking about thinking~\citep{papert1980mindstorms}. Stallman wrote that users deserve to control the software they run~\citep{stallman2002free}. Postman warned that technology in schools without purpose serves the technology, not the child~\citep{postman1995end}. These are not fringe positions. They are the founding principles of personal computing, and we have abandoned them in the one place they matter most: the education of children.
424
+
425
+
Get closed source out of schools. Give every student a free and open operating system. Let the Chromebook be what it was always capable of being: not a gate, but a \emph{gateway}---to logic, creativity, community, spirituality, and every student's own path through the computational landscape.
426
+
427
+
In the age of LLMs, this is not idealism. It is the minimum viable education.
428
+
429
+
\vspace{0.5em}
430
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
431
+
432
+
\end{multicols}
433
+
434
+
% ============================================================
435
+
% REFERENCES
436
+
% ============================================================
437
+
438
+
\bibliographystyle{plainnat}
439
+
\bibliography{references}
440
+
441
+
\end{document}
+435
papers/arxiv-open-schools/open-schools-ja.tex
+435
papers/arxiv-open-schools/open-schools-ja.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[11pt, a4paper]{article}
3
+
4
+
\usepackage{fontspec}
5
+
\usepackage{unicode-math}
6
+
\usepackage{xeCJK}
7
+
\setCJKmainfont{Droid Sans Japanese}
8
+
\setmainfont{Latin Modern Roman}
9
+
\setsansfont{Latin Modern Sans}
10
+
\setmonofont{Latin Modern Mono}[Scale=0.88]
11
+
12
+
\usepackage{graphicx}
13
+
\graphicspath{{figures/}{../arxiv-ac/figures/}}
14
+
\usepackage{booktabs}
15
+
\usepackage{tabularx}
16
+
\usepackage{ragged2e}
17
+
\usepackage{microtype}
18
+
\usepackage{natbib}
19
+
\usepackage{multicol}
20
+
21
+
\usepackage[
22
+
top=2.2cm, bottom=2.5cm, left=2.0cm, right=2.0cm
23
+
]{geometry}
24
+
25
+
\makeatletter
26
+
\def\input@path{{../}}
27
+
\makeatother
28
+
\usepackage{ac-paper-layout}
29
+
30
+
\newcommand{\acos}{\textsc{AC Native OS}}
31
+
32
+
\hypersetup{
33
+
pdftitle={クローズドソフトウェアを学校から追い出せ：すべてのChromebookは閉じられた扉である},
34
+
}
35
+
36
+
\begin{document}
37
+
38
+
\thispagestyle{empty}
39
+
\vspace*{\fill}
40
+
\begin{center}
41
+
\includegraphics[height=8em]{pals}\par\vspace{0.3em}
42
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} クローズドソフトウェアを学校から追い出せ}\par
43
+
\vspace{0.3em}
44
+
{\fontsize{10pt}{12pt}\selectfont\color{acpink} すべてのChromebookは閉じられた扉である}\par
45
+
\vspace{0.8em}
46
+
{\normalsize\color{cyan!70!blue}\textbf{@jeffrey}}\par
47
+
{\small\color{acgray} Aesthetic.Computer}\par
48
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
49
+
\vspace{0.8em}
50
+
\rule{0.6\textwidth}{1pt}\par
51
+
\vspace{0.4em}
52
+
{\small\color{acpink!40}\textit{作業草稿 --- 引用不可}}\par
53
+
\vspace{0.3em}
54
+
{\footnotesize\color{acgray} 2026年3月}\par
55
+
\end{center}
56
+
\vspace*{\fill}
57
+
\clearpage
58
+
59
+
\begin{multicols}{2}
60
+
61
+
% ============================================================
62
+
% ABSTRACT
63
+
% ============================================================
64
+
65
+
\begin{abstract}
66
+
\noindent
67
+
アメリカの学校には5,000万台以上のChromebookがある。どれも信頼性の高いコンピュータであり、生徒のあらゆるインタラクションをGoogleの監視インフラに誘導するクローズドでプロプライエタリなOSを動かしている。生徒はマシンの仕組みを見ることができない。生徒はマシンを改変できない。生徒は意味のあるレベルでマシンを所有できない。大規模言語モデルの時代——「誰もがプログラマー」がスローガンではなく物質的現実となった今——これは教育上の怠慢である。本稿はすべての生徒が自由でオープンなOSスタックを持つべきだと論じる：Chromebookを生徒にとっての論理、創造性、インターネット、コミュニティ、そしてコンピューティングの全風景への扉にするOSを。クローズドソースの学校コンピューティングインフラをオープンな代替案に置き換える技術的、教育的、経済的、政治的論拠を提示する。ケーララ、シュレスヴィヒ＝ホルシュタイン、フランスからの国際先例、計画的陳腐化に関する環境データ、生徒監視に対する連邦・州の法的措置、AI支援プログラミング教育の新興研究を活用する。\acos{}~\citep{scudder2026acos}をこのビジョンの具体的実装として提示する。
68
+
\end{abstract}
69
+
70
+
% ============================================================
71
+
% 1. THE CHROMEBOOK PROBLEM
72
+
% ============================================================
73
+
74
+
\section{Chromebook問題}
75
+
76
+
2012年、GoogleはアメリカのK-12学区にChromebookを積極的に売り込み始めた。売り文句はシンプルだった：安いハードウェア、ゼロのIT負担、すべてクラウドに。2026年までにChromebookはアメリカK--12学校デバイス出荷の約60\%を占め、設置台数は5,000万台を超える~\citep{google2024chromeos}。アメリカの一世代分の生徒が、理解できない、改変できない、所有できないマシン——学校が代金を払ったにもかかわらず——で教育を受けている。
77
+
78
+
ChromeOSはプロプライエタリソフトウェアである。ソースコードは閲覧できない。ブラウザがインターフェースの全体。すべてのドキュメントはGoogleドライブに存在する。すべての検索はGoogleを経由する。すべてのインタラクションが記録、分析され、生徒を成人まで追跡する行動プロファイルの構築に使用される~\citep{zuboff2019surveillance}。
79
+
80
+
これは周辺的なプライバシー問題ではない。アメリカの子どもがコンピュータの使い方を学ぶ\emph{アーキテクチャ}である。メディアがメッセージである~\citep{mcluhan1964understanding}。Chromebookは生徒に、コンピュータとは企業所有のクラウドサービスを消費するデバイスであると教える。自分の作品は他人のサーバーに存在すると教える。マシンは理解できるものではないと教える。
81
+
82
+
\subsection{生徒にできないこと}
83
+
84
+
学校のChromebookでは、生徒は以下ができない：
85
+
86
+
\begin{itemize}
87
+
\item プログラミング言語ランタイムのインストール（Python、Node.js、GCC）
88
+
\item ローカルWebサーバーの起動やコードのコンパイル
89
+
\item OSソースコードの閲覧
90
+
\item ブートシーケンスの改変
91
+
\item 物理コンピューティング用ハードウェア周辺機器の接続
92
+
\item オフラインでの本格的な作業
93
+
\item クラウド同期なしのデバイス上データ保存
94
+
\item 自分のソフトウェアの選択
95
+
\item マシンが自分の注意をどう搾取しているかの理解
96
+
\end{itemize}
97
+
98
+
ChromeOSにはLinuxコンテナ（Crostini）が含まれ、理論上はこれらの機能を提供できるが、学校のIT管理者はほぼ例外なくこれを無効にしている。マシンにはターミナルが付属しているのに、それを施錠している。これらの制限のそれぞれが閉じられた扉である。閉じられた扉のそれぞれが、生徒が決して発見しない道である。Chromebookは扉ではない——\emph{柵}である。
99
+
100
+
\subsection{家主としてのクラウド}
101
+
102
+
生徒の作品がGoogleドライブに存在するとき、生徒はテナントであって所有者ではない。Googleは利用規約を変更できる。Googleは製品を終了できる。Googleはアクセスを取り消せる。生徒は卒業時に学校のGoogleアカウントを失い——在学中に作ったすべてのドキュメント、すべてのプロジェクト、すべてのクリエイティブ作品も失う。
103
+
104
+
これは仮定ではない。毎年、すべての学区で起きている。生徒は何年もの作品へのアクセスを失う。なぜなら、クラウドアカウントを購入した機関がそれを無効にしたから。このアーキテクチャはこの結果を\emph{保証している}。生徒は自分のファイルを所有したことがない。Googleのサーバー上のファイルにアクセスする許可を持っていただけであり、その許可が取り消された。
105
+
106
+
フレイレはこれを教育の「銀行型モデル」と呼んだ~\citep{freire1970pedagogy}：知識が権威者によって生徒に預金される。Chromebookはこのメタファーを文字通りにする。生徒の作品が銀行に預金される——管理できない、監査できない、最終的に締め出される銀行に。
107
+
108
+
\subsection{計画的陳腐化：AUE問題}
109
+
110
+
すべてのChromebookには自動更新期限（AUE）日付が付属し、それ以降Googleはセキュリティパッチ、機能アップデート、ブラウザアップデートを提供しない。歴史的に\emph{プラットフォーム}の初回リリースから6.5年後に設定されていた——購入日ではない——プラットフォームサイクルの後期にChromebookを購入した学校は3--4年しかアップデートを得られない可能性がある。Googleは2024年発売デバイスを10年に延長したが、寿命の短いマシンの設置ベースはまだ膨大である。
111
+
112
+
US PIRG Education Fundは、AUEポリシーが2024年までに2,150万台の機能するChromebookを早期退役に追い込み、学校に約18億ドルの不要な買い替え費用を負わせると推計した~\citep{pirg2023chromebook}。これらのマシンはプロセッサが動作し、画面が動作し、キーボードが動作するのに——ハードウェアの故障ではなくソフトウェアポリシーによって時代遅れと宣告される。
113
+
114
+
Linuxとの対比は絶対的である。Ubuntu LTSを動かす2015年のThinkPadは無期限にセキュリティアップデートを受け続けることができる。ハードウェアモデルに紐付いた人為的な期限日はない。ハードウェアが動く限り、マシンは有用であり続ける。
115
+
116
+
% ============================================================
117
+
% 2. THE SURVEILLANCE MACHINE
118
+
% ============================================================
119
+
120
+
\section{監視マシン}
121
+
\label{sec:surveillance}
122
+
123
+
Googleが学校にChromebookを原価以下で提供するのは、生徒が行動データの囲い込み市場だからである~\citep{zuboff2019surveillance, doctorow2020attack}。Googleエコシステムで育った生徒——Gmail、Google Docs、Googleドライブ、Google Classroom、YouTube——は生涯顧客である。Chromebookは慈善寄付ではない。子どもに対して展開される顧客獲得戦略である。
124
+
125
+
\subsection{Googleが収集するもの}
126
+
127
+
生徒のChromebookから収集されるデータには以下が含まれる：
128
+
129
+
\begin{itemize}
130
+
\item すべての検索クエリとすべてのアクセスしたウェブサイト
131
+
\item すべての開いた、編集した、共有したドキュメント
132
+
\item すべての視聴したYouTube動画と視聴時間
133
+
\item キーストロークのタイミングパターンとログイン頻度
134
+
\item 位置データ（セルラーモデル）
135
+
\item ソーシャルグラフ（Google Docsで誰と共同作業しているか）
136
+
\item デバイス診断とアプリ使用テレメトリー
137
+
\end{itemize}
138
+
139
+
Googleは「コアサービス」のWorkspace for Educationで収集されたデータを広告に使用しないと主張する。しかし「追加サービス」——YouTube、Google検索、ログイン状態のGoogleマップ——は異なる規約で運営される。学校のChromebook上の生徒はこれらの追加サービスを常に使用し、データはGoogleの広告インフラに流れる。
140
+
141
+
\subsection{法的措置}
142
+
143
+
法的記録は驚くべきものである。2019年、GoogleはYouTubeのCOPPA違反——親の同意なく児童データを収集——でFTCとニューヨーク州司法長官に1.7億ドルを支払った~\citep{google2019coppa}。2020年、ニューメキシコ州司法長官Hector BalderasはGoogleを直接提訴し、学校のChromebookを通じた児童の個人データ収集を告発した~\citep{newmexico2020google}。EFFは2015年にFTCに苦情を提出し、Chromebookを通じたGoogleによる生徒のブラウジング活動のデータマイニングを文書化した~\citep{eff2015chromebook}。2024年、デジタル権利団体の連合が継続的な生徒監視についてFTCに追加苦情を提出した~\citep{eff2024monitoring}。イリノイ州BIPA法に基づく生徒からの生体データ収集を主張する集団訴訟が進行中である。
144
+
145
+
これらのデータは未成年者から、参加が強制される制度的環境で、生徒が選択も設定もできないマシンを使って収集される。生徒はオプトアウトできない。親も通常オプトアウトできない。学区が契約を結び、子どもがそれに拘束される。
146
+
147
+
\subsection{監視ソフトウェア}
148
+
149
+
Google自身のデータ収集に加え、学区はChromebookに追加の監視ソフトウェアを重ねている——Gaggle、GoGuardian、Securly。EFFはこれらのツールがプライベートなコミュニケーションを監視し、脆弱な集団、マイノリティ、LGBTQ青年に不均衡にターゲティングすることを記録している~\citep{eff2024monitoring}。EFFが調査した152の教育テックサービスのうち、プライバシーポリシーを公開しているのは118のみ。データ保持、暗号化、非識別化に言及しているのはさらに少ない。
150
+
151
+
Winnerは技術的アーティファクトが政治的であると論じる~\citep{winner1980artifacts}。Chromebookの政治性は明白である：監視される者に選択の余地なく、救済手段なく、何が奪われているかの理解もない状況で展開される監視ツールである。
152
+
153
+
自由でオープンなOSはテレメトリーを収集しない。企業に情報を送らない。行動プロファイルを構築しない。生徒の注意、好奇心、間違い、探索——すべてが私的なままである。なぜならマシンにはそれらを観察する経済的動機がないから。
154
+
155
+
% ============================================================
156
+
% 3. THE LLM INFLECTION
157
+
% ============================================================
158
+
159
+
\section{誰もがプログラマーになった}
160
+
161
+
大規模言語モデルはプログラミングの経済学を変えた。自然言語で要件を記述できる生徒が動作するコードを生み出せる。コンピュテーショナルな創造の閾値が「何年もの技術トレーニング」から「アイデアを表現する能力」にまで下がった。Karpathyの観察——「最もホットな新プログラミング言語は英語」——はもはや誇張ではなく物質的現実の記述である。
162
+
163
+
これはパーソナルコンピュータ以来のコンピューティング分野で最も重要な転換点である。そしてChromebook問題を\emph{壊滅的に}悪化させる。
164
+
165
+
\subsection{新しいリテラシー}
166
+
167
+
誰もがプログラムできるなら、プログラミングはリテラシーである。リテラシーには、読む人が所有できるツールが必要。特定の建物で特定の企業アカウントでしか開けない鍵付きの本を渡して子どもに読み方を教えることはしない。本を渡す。持ち帰る。ベッドで読む。余白に書き込む。友達に貸す。
168
+
169
+
LLMとオープンOSを持つ生徒は以下ができる：
170
+
171
+
\begin{itemize}
172
+
\item 宿題を整理するツールを作る
173
+
\item ゲームを書いてクラスメートと共有する
174
+
\item 先生が出す反復的な作業を自動化する
175
+
\item コミュニティにソフトウェアを販売する小さなビジネスを作る
176
+
\item 人類に奉仕するオープンソースプロジェクトに貢献する
177
+
\item デジタルライフを管理するシステムを理解し改変する
178
+
\item 直接操作を通じて論理、数学、言語を探求する
179
+
\item 芸術的表現のためのツールを構築する
180
+
\end{itemize}
181
+
182
+
LLMとChromebookを持つ生徒は、Google Docsをより速く使える。
183
+
184
+
Ko（ワシントン大学）は、AIがコードを書けるなら、計算機科学教育はシステム思考、デバッグ、評価に移行しなければならないと論じる——すべてがサンドボックス化されたブラウザではなく本物の開発環境へのアクセスを必要とする~\citep{denny2024computing}。Krishnamurthi（ブラウン大学）はプログラミングをプロンプトに還元するアプローチを批判する。計算機科学教育研究で形成されつつあるコンセンサスは、LLMがフルスタックアクセスを\emph{より}重要にするということである~\citep{prather2024robots}：生徒は生成されたコードを実行、デバッグ、改変、理解する必要がある。Chromebookはこの4つすべてを困難にする。
185
+
186
+
\subsection{Chromebookにできないこと}
187
+
188
+
具体的な失敗はこうだ：LLMがPythonスクリプトを生成するが、Chromebookではそれを実行できない。LLMがWebサーバーを生成するが、Chromebookではホストできない。LLMがCコードを書くが、Chromebookにコンパイラがない。LLMがOSの仕組みを教えるが、Chromebookはそれを見せない。
189
+
190
+
典型的な学校のChromebook（MediaTekまたはCeleronプロセッサ、4\,GBメモリ）では、有効化されたとしてもLinuxコンテナでさえ基本的な開発ツールチェーンの実行に苦労する。ローカルLLMの実行は物理的に不可能：量子化された1Bパラメータモデルでさえほとんどの学校Chromebookのメモリ容量を超える。
191
+
192
+
代替案は明白である。8\,GBメモリでLinuxを動かす中古ThinkPadならLLMが生成するどんなコードも実行でき、Ollama経由でインタラクティブな速度のローカル3Bパラメータモデルを動かし、Webサーバーをホストし、プログラムをコンパイルし、生徒にシステム全体のroot権限を与えられる。ハードウェアは存在する。ソフトウェアは無料。Chromebookがボトルネックである。
193
+
194
+
\subsection{スピリチュアルな次元}
195
+
196
+
これは経済やキャリア準備だけの問題ではない。コンピューティングにはスピリチュアルな次元があり、Chromebookのアーキテクチャはそれを殺している。
197
+
198
+
生徒が書いたプログラムが予期しないことをした時——マシンが生徒の定義したルールから生まれる創発的振る舞いで彼らを驚かせた時——彼らは何か深いものを体験する。意図と結果の境界に出会う。システムには固有の論理があることを学ぶ。抽象化そのものとの関係を育む。
199
+
200
+
Papertはこれを理解していた~\citep{papert1980mindstorms}：Logoはプログラミングを教えることが目的ではなかった。子どもに思考について思考するための媒体を与えることだった。タートルは認識論的な乗り物だった。
201
+
202
+
LLMはこれを千倍に増幅する。生徒はコンピューティング媒体と\emph{対話}できるようになった。「もし？」と問えば数秒で答えが返る。思考の速度でアイデアを反復できる。どんなカリキュラムも予見しなかった道を探索できる。
203
+
204
+
ただしマシンがそれを許す場合に限る。Chromebookは許さない。Chromebookは言う：サービスを消費できる。インフラを作ることはできない。自分のマシンで自分のコードを自分のやり方で動かすことはできない。
205
+
206
+
% ============================================================
207
+
% 4. WHAT STUDENTS DESERVE
208
+
% ============================================================
209
+
210
+
\section{すべての生徒が持つべきもの}
211
+
212
+
すべての生徒は以下のコンピュータを持つべきである：
213
+
214
+
\begin{enumerate}
215
+
\item \textbf{理解できる}コンピュータ。OSのソースコードが閲覧可能であるべき。抽象的原則としてではなく実際の現実として：キーを押した時に実行されるコードを読めるべき。
216
+
217
+
\item \textbf{改変できる}コンピュータ。マシンの動作を変えたいなら、できるべき。アプリストアを通じてでも、設定パネルを通じてでもなく、コードを改変することによって。
218
+
219
+
\item \textbf{所有できる}コンピュータ。生徒の作品は生徒のマシンに存在すべき。企業サーバーにではなく、卒業後に無効化されるクラウドアカウントにではなく。
220
+
221
+
\item \textbf{共有できる}コンピュータ。ソフトウェアを友達に渡せるべき。プラットフォームを通じてでも、マーケットプレイスを通じてでもなく、ファイルをコピーすることによって。
222
+
223
+
\item \textbf{壊せる}コンピュータ。マシンを壊して直せるべき。これが学びの方法。壊せないシステムは理解できない。
224
+
225
+
\item \textbf{持って行ける}コンピュータ。学校を去る時、コンピュータと——その上のすべてが——ついてくる。コンピューティングライフは借り物ではない。自分のもの。
226
+
227
+
\item \textbf{注意を尊重する}コンピュータ。OSに広告、行動追跡、エンゲージメント最適化があってはならない。生徒の注意は生徒のもの。
228
+
229
+
\item \textbf{コミュニティとつながる}コンピュータ。コンピューティングの風景に貢献できるべき——他の人が使うコードを書き、オープンソースプロジェクトに参加し、コミュニティに奉仕し生活と福利を維持するツールを構築する。
230
+
\end{enumerate}
231
+
232
+
ChromeOSはこれらの要件のすべてに違反する。自由でオープンなOSはすべてを満たす。
233
+
234
+
% ============================================================
235
+
% 5. IT ALREADY WORKS
236
+
% ============================================================
237
+
238
+
\section{すでに機能している：国際先例}
239
+
240
+
オープンソース学校コンピューティングが未検証だという反論は誤りである。3大陸で大規模に検証済みである。
241
+
242
+
\subsection{インド・ケーララ州：16,000校}
243
+
244
+
ケーララ州のKITE（Kerala Infrastructure and Technology for Education）プロジェクトは2007年に16,000以上の公立学校で全面的に自由ソフトウェアに移行した。2024年8月リリースのKITE GNU/Linux 22.04は300,000台以上の学校コンピュータで動作~\citep{kite2024gnulinux}。ディストリビューションには教育ソフトウェア（Krita、GCompris、PictoBlox）、基本的なAI/ML教育ツール、Waylandディスプレイサーバーが含まれる。推定節約額：300億インドルピー（約4億ドル）。15万人以上の小学校教師が研修を受けた。インド国立法科大学はKITEを教育における国家的なオープンソース転換のベンチマークとして称賛した。
245
+
246
+
これはパイロットプロジェクトではない。数百万人の生徒にサービスを提供する州全体の展開であり、約20年間継続的に運用されている。
247
+
248
+
\subsection{ドイツ・シュレスヴィヒ＝ホルシュタイン州：30,000台}
249
+
250
+
2025年夏末までにドイツのシュレスヴィヒ＝ホルシュタイン州は約30,000台の政府PCをMicrosoftからLinuxに移行完了し、さらに30,000人の公立学校教師が追随予定~\citep{schleswig2025linux}。代替案にはLibreOffice、Nextcloud、Open-Xchange、Mozilla Thunderbirdが含まれる。推定節約額：2026年だけで1,500万ユーロ。デンマークは2025年6月から11月の間に同様の転換を発表した。
251
+
252
+
\subsection{フランス：国家オープンソース戦略}
253
+
254
+
フランスの2023--2027年デジタル教育戦略は教育省のAlexis Kauffmannが主導し、デジタル主権とMicrosoft・Googleへの依存削減を明示的に目標としている~\citep{france2023digital}。国家プラットフォーム \texttt{apps.education.fr} がすべてのフランスの教師にオープンソースツールを提供。2025年、フランスは相互運用性法令を制定し、学校にオープンスタンダード準拠のデジタルツールの使用を義務づけた——オープンソースソリューションに構造的優位を生み出している。
255
+
256
+
\subsection{ペンシルベニア州Penn Manor：1,725台のLinuxノートパソコン}
257
+
258
+
アメリカではペンシルベニア州ランカスターのPenn Manor学区が9--12年生に1,725台のUbuntuノートパソコンを配備した~\citep{pennmanor2024linux}。プロジェクトには生徒主導の修理プログラムが含まれ、生徒が自分のマシンの修理を学ぶ。特別な資金を持つ特別な学区ではない。異なる選択をした公立学区である。
259
+
260
+
\subsection{「公的資金、公的コード」運動}
261
+
262
+
欧州自由ソフトウェア財団の「Public Money? Public Code!」運動——公的資金で開発されたソフトウェアは自由ライセンスで公開されるべきだと主張——は200以上の市民社会団体と31,000人の個人署名を集めている~\citep{fsfe2024publiccode}。ユネスコの2024年ドバイOER宣言は署名国にAIと新興技術を通じてオープンリソースを推進することを正式にコミット~\citep{unesco2024oer}。グローバルデジタル契約は「社会に利益をもたらすオープンソースソフトウェア、オープンデータ、オープンAIモデル、オープンスタンダードの開発、配布、維持」を約束する。
263
+
264
+
これらは周辺的な運動ではない。国際政策の方向性である。
265
+
266
+
% ============================================================
267
+
% 6. THE ECONOMICS
268
+
% ============================================================
269
+
270
+
\section{経済学}
271
+
272
+
\subsection{コストの言い訳}
273
+
274
+
Chromebookは安い。しかしLinuxを動かす中古ノートパソコンも安い。退役したThinkPad T480やDell Latitude 5400はまとめ買いで\$100--180であり、「Googleが管理する」以外のあらゆる次元でより優れたマシンである。Chromebookを支持するコスト論は、ハードウェアではなくGoogleエコシステムを支持する論である。
275
+
276
+
\begin{table}[H]
277
+
\small
278
+
\centering
279
+
\begin{tabular}{lrr}
280
+
\toprule
281
+
\textbf{方案} & \textbf{コスト} & \textbf{生徒が所有} \\
282
+
\midrule
283
+
Chromebook（新品） & \$250--350 & いいえ \\
284
+
Chrome Edu Upgrade & +\$38/台 & いいえ \\
285
+
Google Workspace Plus & +\$5/生徒/年 & いいえ \\
286
+
iPad（教育版） & \$299+ & いいえ \\
287
+
\midrule
288
+
中古ノートPC + Linux & \$100--180 & \textbf{はい} \\
289
+
中古ノートPC + AC OS & \$100--180 & \textbf{はい} \\
290
+
\bottomrule
291
+
\end{tabular}
292
+
\caption{コストと所有権の比較。Chromebookコストには監視ソフトウェア（GoGuardian：\$5--10/台/年）と強制AUE交換を含まない。}
293
+
\label{tab:cost}
294
+
\end{table}
295
+
296
+
GoogleのChrome Education Upgrade（\$38/台）、Workspace for Education Plus（\$5/生徒/年）、監視ソフトウェア、AUE強制交換サイクルを含めると、Chromebookの5年間の総保有コストは\$450--550/台に達しうる。Linuxを動かす中古ThinkPad：\$100--180、継続ライセンス費ゼロ、人為的な期限日なし、生徒が保持できる。
297
+
298
+
\subsection{供給}
299
+
300
+
マシンは存在する。推定でアメリカでは年間5,000--6,000万台の商用PCが退役する。企業リースサイクルは3--5年ごとに数百万台の機能するノートパソコンを排出する——最新のプロセッサ、8--16\,GBメモリ、WiFi、6--10時間バッテリーを搭載したマシン。PCs for People（年間10万台以上）、Human-I-T（年間5万台以上）、Kramden Institute、Free Geek、連邦のComputers for Learningプログラムなどの組織がすでにこれらのマシンを整備・配布している。
301
+
302
+
30台のクリエイティブコンピューティングツールの教室は\$3,000--5,400のハードウェアで整備できる。継続サブスクリプションなし。ITサポート契約なし。ホスティングアカウントなし。
303
+
304
+
\subsection{環境論}
305
+
306
+
典型的なノートパソコンは製造過程で300--400\,kg CO$_2$eを排出——総ライフサイクルカーボンフットプリントの70--80\%。再整備は約5--15\,kg CO$_2$eを追加。Circular Computingの独立監査分析は再製造ノートパソコン1台あたり316\,kg CO$_2$eの節約を発見~\citep{circularcomputing2023carbon}。国連の2024年グローバル電子廃棄物モニター報告によるとアメリカは年間約720万トンの電子廃棄物を発生させ、うち適切にリサイクルされるのはわずか25\%~\citep{un2024ewaste}。
307
+
308
+
GoogleのAUEポリシーは学校に数百万台の使用可能なChromebookの廃棄を強いる。修理権立法が対処し始めている：オレゴン州法（2025年1月施行）は製造者に部品と修理情報の提供を義務づけ~\citep{oregon2024repair}、ニューハンプシャー州のHB1701は学校提供のノートパソコンを明示的にカバー~\citep{newhampshire2024repair}。しかし立法は機能するハードウェアを時代遅れと宣告するソフトウェアポリシーを修正できない。
309
+
310
+
LinuxにはAUEがない。自由OSを動かすノートパソコンはハードウェアが動く限り有用である。
311
+
312
+
% ============================================================
313
+
% 7. THE OPEN STACK
314
+
% ============================================================
315
+
316
+
\section{オープンスタック}
317
+
318
+
\subsection{すべてのChromebookはすでにLinuxマシン}
319
+
320
+
不条理なのは：すべてのChromebookがすでにLinuxカーネルを動かしていること。ChromeOSはロックされたユーザースペースを持つLinuxであり、すべてのインタラクションをGoogleのブラウザ経由に強制する。ハードウェアは完全に自由OSを動かす能力がある。Googleは自由カーネルを取り、プロプライエタリな制限で包み、コスト削減策として学校に販売した。
321
+
322
+
これらのマシンの解放に新しいハードウェアは不要。新しいソフトウェアをフラッシュするだけ。多くのChromebookはアンロックして標準Linuxディストリビューションや\acos{}で再フラッシュできる。マシンは\emph{自由になりたがっている}。Googleがその錠前である。
323
+
324
+
\subsection{ITの言い訳}
325
+
326
+
学校のIT部門はChromebookを「管理しやすい」から選ぶ。事実である。何もしないマシンの管理は確かに簡単。すべてのデバイスが単一企業のサービスのシンクライアントなら、フリートの管理は確かに簡単。管理の容易さはマシンの無能さの直接的帰結。
327
+
328
+
問題は：誰にとって簡単か？IT部門にとっては確かに簡単。しかし生徒にとっては壊滅的。IT部門の便利さは生徒の自律性を犠牲にして購入されている。悪い取引である。
329
+
330
+
オープンソースの管理ツールは存在する。NixOSは再現可能なシステム設定を提供。Ansibleがフリートデプロイを自動化。PXEブートがゼロタッチプロビジョニングを実現。\acos{}~\citep{scudder2026acos}はOS全体が1分以内にUSBドライブをフラッシュすることでデプロイでき、OTAアップデートがITインフラなしで機能することを実証した。Penn Manorは同等のChromebook学区より少ないITスタッフで1,725台のLinuxノートパソコンを運用~\citep{pennmanor2024linux}。「管理問題」は解決済み。残っているのは制度的惰性とGoogleとの契約関係——それは機関に奉仕するものであり、生徒にではない。
331
+
332
+
\subsection{LLMインフラ}
333
+
334
+
オープンシステムはAIとの根本的に異なる関係を可能にする。中古サーバー（32--64\,GBメモリ、または\$100--200の中古NVIDIA T4 GPU）でOllamaを動かしOpen WebUI——無料のオープンソースLLMフロントエンド——を通じて教室全体の生徒にサービスできる。生徒はノートパソコンからブラウザ経由でローカルサーバーに接続。Llama 3.2 3B（4\,GBで動作）、DeepSeek Coder 6.7B、Qwen 2.5 Coder 7Bなどのモデルが強力なコード生成能力を提供。
335
+
336
+
これは学校所有のローカルAIインフラであり、テレメトリーを収集せず、企業にデータを送らず、生徒が閲覧・改変・学習できる。代替案——Workspace for Educationに統合されたGoogle Gemini——は企業依存のもう一つの層、もう一つのデータパイプライン、もう一つのサブスクリプション料金を追加する。
337
+
338
+
% ============================================================
339
+
% 8. THE LLM GATEWAY
340
+
% ============================================================
341
+
342
+
\section{創作者としての生徒}
343
+
344
+
LLMアクセスを持つオープンシステムで、生徒は以下ができる：
345
+
346
+
\begin{itemize}
347
+
\item LLMにOSのソースコードを説明させる
348
+
\item 完全なハードウェアアクセスでローカル実行されるプログラムを生成
349
+
\item Webサーバー、データベース、API——本物のインフラを構築
350
+
\item コミュニティの実際の問題を解決するツールを作成
351
+
\item 実際に構築することであらゆるプログラミング言語を学ぶ
352
+
\item LLMの入力と出力を検査することでLLM自体を理解
353
+
\item \ac{}~\citep{scudder2026ac}で世界中の誰もが実行できるピースを作る
354
+
\end{itemize}
355
+
356
+
LLMは無限の忍耐力を持ち、24時間利用可能で、生徒の現在地に正確に合わせてくれるチューターとなる~\citep{khan2024bravenew}。ただしこのチューターが効果的なのは、生徒がチューターの出力を\emph{実行できる}マシンを持つ場合のみ。
357
+
358
+
Chromebookモデルは言う：あなたはユーザー。オープンモデルは言う：あなたは創作者。LLM時代において、この2つのフレーミングの違いはデジタルリテラシーとデジタル農奴制の違いである。
359
+
360
+
% ============================================================
361
+
% 9. A PATH FORWARD
362
+
% ============================================================
363
+
364
+
\section{前進の道}
365
+
366
+
\subsection{第1段階：認識}
367
+
368
+
保護者、教師、学校運営委員会メンバーはChromebookが実際に何であるかを理解しなければならない：学習性無力感を教える監視デバイス。第一歩は教育——子どもの教育ではなく、マシンを購入する大人の教育。EFFの「Spying on Students」文書、US PIRGの「Chromebook Churn」報告、ニューメキシコ州司法長官の訴訟は学校運営委員会で提示できる具体的証拠を提供する。
369
+
370
+
\subsection{第2段階：パイロット}
371
+
372
+
学区はPenn Manorをモデルにオープンソース代替案のパイロットを実施すべき：
373
+
374
+
\begin{itemize}
375
+
\item LinuxまたはAC OSを動かす30台の中古ノートパソコン、調達費\$3,000--5,400
376
+
\item ローカルLLMサーバー（中古ワークステーション1台、\$200--500）でOllama + Open WebUIを実行
377
+
\item LLM支援カリキュラムで生徒が本物のソフトウェアを構築
378
+
\item 生徒の所有権：マシンは生徒と一緒に家に帰る
379
+
\item 生徒主導の修理プロジェクト（Penn Manorの生徒は自分のマシンを修理する）
380
+
\item クラウド依存なし：作品はローカル保存、生徒自身がバックアップ
381
+
\item オープンな評価：生徒のポートフォリオは彼らが書いたコード、構築したツール、行った貢献
382
+
\end{itemize}
383
+
384
+
\subsection{第3段階：政策}
385
+
386
+
州と学区は以下を要求する政策を採択すべき：
387
+
388
+
\begin{enumerate}
389
+
\item 生徒デバイスに展開するすべてのソフトウェアはオープンソースまたはソースコード利用可能
390
+
\item 生徒は自分のマシンへのroot権限を持つ
391
+
\item 生徒デバイスから行動テレメトリーを収集しない
392
+
\item 生徒は学校デバイスで生み出したすべての作品の所有権を保持
393
+
\item 卒業生はデバイスを保持
394
+
\item デバイス調達は新規製造より整備済みハードウェアを優先
395
+
\end{enumerate}
396
+
397
+
40以上の州が生徒データプライバシー法を可決している。カリフォルニア州のSOPIPAは生徒データのターゲット広告使用を禁止。新しいCOPPA規則（2025年6月施行）は児童データ保護を強化。これらの立法動向はオープンで監視のない学校コンピューティングインフラの論拠を支持する。
398
+
399
+
\subsection{第4段階：解放}
400
+
401
+
最終目標は政策変更ではない。文化的転換である。最終目標は、コンピュータが消費する製品ではなく演奏する楽器であると理解する一世代の生徒——思考し、創造し、貢献するための媒体。本を読むようにソースコードを読める生徒。大工が作業台を改造するようにツールを改変できる生徒。コンピューティングを企業サービスではなく公共財として見る生徒——そこに貢献し、そこに属する。
402
+
403
+
Nelsonは1974年に書いた~\citep{nelson1974computerlib}：「あなたは今すぐコンピュータを理解できるし、理解しなければならない。」50年後、まさにNelsonが恐れたやり方でその命令を裏切っている——マシンを企業に引き渡し、それを進歩と呼んでいる。
404
+
405
+
LLMの瞬間はこの失敗を可視化する。すべての生徒に今やプログラミングの\emph{能力}がある。欠けているのはそれを\emph{許してくれるマシン}。これは解決可能な問題。技術は無料。ハードウェアは余剰。すべての生徒と自分自身のコンピューティングの道の間にある唯一の障壁は、彼らに奉仕するように設計されたことのない企業OSである。
406
+
407
+
% ============================================================
408
+
% 10. CONCLUSION
409
+
% ============================================================
410
+
411
+
\section{結論}
412
+
413
+
アメリカのすべての学校のすべてのChromebookは鎖に繋がれたLinuxマシンである。ハードウェアは自由OSを動かせる。生徒はLLMの助けでプログラミングを学べる。中古ノートパソコン市場は\$100--180のマシンを提供する。オープンソーススタック全体がゼロコストで入手可能。ケーララは300,000台で実現した。シュレスヴィヒ＝ホルシュタインは30,000台で実現した。Penn Manorは1,725台で実現した。機能する。
414
+
415
+
足りないのは技術ではない。生徒の自律性を制度的便利さと企業利益の上に置く政治的意志である。
416
+
417
+
Illichは書いた、ツールは専門知識を要求するのではなく個人の自律性を拡張すべきだと~\citep{illich1973tools}。Papertは書いた、コンピュータは思考について思考するためのツールであるべきだと~\citep{papert1980mindstorms}。Stallmanは書いた、ユーザーは実行するソフトウェアを制御する権利を持つべきだと~\citep{stallman2002free}。Postmanは警告した、目的なき学校技術は子どもではなく技術に奉仕すると~\citep{postman1995end}。これらは周辺的な立場ではない。パーソナルコンピューティングの基本原理であり、最も重要な場所で放棄されている：子どもの教育。
418
+
419
+
クローズドソフトウェアを学校から追い出せ。すべての生徒に自由でオープンなOSを。Chromebookをそれが常になれたはずのものにしよう：柵ではなく\emph{扉}——論理、創造性、コミュニティ、精神性、そしてコンピューティングの風景における各生徒の固有の道への扉。
420
+
421
+
LLM時代において、これは理想主義ではない。最低限の実行可能な教育である。
422
+
423
+
\vspace{0.5em}
424
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
425
+
426
+
\end{multicols}
427
+
428
+
% ============================================================
429
+
% REFERENCES
430
+
% ============================================================
431
+
432
+
\bibliographystyle{plainnat}
433
+
\bibliography{references}
434
+
435
+
\end{document}
+15
-13
papers/arxiv-os/os-cards.tex
+15
-13
papers/arxiv-os/os-cards.tex
···
73
73
\thispagestyle{empty}
74
74
\vspace*{\fill}
75
75
\begin{center}
76
-
\includegraphics[height=8em]{pals}\par\vspace{0.3em}
77
-
{\acbold\fontsize{20pt}{24pt}\selectfont\color{acdark} AC Native OS '26}\par
78
-
\vspace{0.3em}
79
-
{\fontsize{10pt}{12pt}\selectfont\color{acpink} A Bare-Metal Creative Computing Operating System}\par
80
-
\vspace{0.8em}
81
-
{\normalsize\color{cyan!70!blue}\textbf{@jeffrey}}\par
76
+
\includegraphics[height=9em]{pals}\par\vspace{0.1em}
77
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} AC Native OS '26}\par
78
+
\vspace{0.1em}
79
+
{\fontsize{9pt}{11pt}\selectfont\color{acpink} A Bare-Metal Creative Computing Operating System}\par
80
+
\vspace{0.4em}
81
+
{\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par
82
82
{\small\color{acgray} Aesthetic.Computer}\par
83
83
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
84
-
\vspace{0.8em}
85
-
\rule{0.6\textwidth}{1pt}\par
86
84
\vspace{0.4em}
87
-
{\small\color{acpink!40}\textit{working draft --- not for citation}}\par
88
-
\vspace{0.3em}
89
-
{\footnotesize\color{acgray} March 2026}\par
85
+
\rule{0.5\textwidth}{0.5pt}\par
86
+
\vspace{0.15em}
87
+
\colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par
88
+
\vspace{0.1em}
89
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/2113ef735}{2113ef735}}\par
90
+
\vspace{0.1em}
91
+
{\footnotesize\color{acgray}\href{https://papers.aesthetic.computer/ac-native-os-26-arxiv-da-cards.pdf}{Dansk} · \href{https://papers.aesthetic.computer/ac-native-os-26-arxiv-es-cards.pdf}{Español} · \href{https://papers.aesthetic.computer/ac-native-os-26-arxiv-zh-cards.pdf}{{\accjk 中文}} · \href{https://papers.aesthetic.computer/ac-native-os-26-arxiv-ja-cards.pdf}{{\accjk 日本語}}}\par
90
92
\end{center}
91
93
\vspace*{\fill}
92
94
···
104
106
105
107
Meanwhile, the consumer computing market produces a constant surplus of functional machines. Corporate lease cycles retire millions of laptops every 3--5 years. Retail overstocks, cancelled orders, and cosmetic defects generate warehouse inventories. E-waste recyclers receive machines with years of useful life remaining. These surplus computers---ThinkPads, EliteBooks, Latitudes---are available for \$30--80 with modern processors, 8--16\,GB RAM, WiFi, keyboards, and screens.
106
108
107
-
\acos{} takes the opposite approach from OLPC: instead of designing custom hardware, we design a custom operating system that transforms \emph{any} commodity x86\_64 machine into a dedicated creative computing instrument. The entire OS is a single file. Flashing it onto a USB drive takes under a minute. The machine boots in 7.3 seconds into a musical instrument, a drawing tool, or a programming environment---with the owner's name on the screen and their voice greeting them by name.
109
+
\acos{} takes the opposite approach from OLPC: instead of designing custom hardware, I design a custom operating system that transforms \emph{any} commodity x86\_64 machine into a dedicated creative computing instrument. The entire OS is a single file. Flashing it onto a USB drive takes under a minute. The machine boots in 7.3 seconds into a musical instrument, a drawing tool, or a programming environment---with the owner's name on the screen and their voice greeting them by name.
108
110
109
-
This paper describes the system architecture~(\S\ref{sec:architecture}), the personalization model~(\S\ref{sec:personalization}), the surplus hardware thesis~(\S\ref{sec:surplus}), the OTA update system~(\S\ref{sec:ota}), comparisons with existing approaches~(\S\ref{sec:related}), and implications for creative computing access~(\S\ref{sec:implications}).
111
+
I describe the system architecture~(\S\ref{sec:architecture}), the personalization model~(\S\ref{sec:personalization}), the surplus hardware thesis~(\S\ref{sec:surplus}), the OTA update system~(\S\ref{sec:ota}), comparisons with existing approaches~(\S\ref{sec:related}), and implications for creative computing access~(\S\ref{sec:implications}).
110
112
111
113
% ============ 2. ARCHITECTURE ============
112
114
+468
papers/arxiv-os/os-ja.tex
+468
papers/arxiv-os/os-ja.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
11
+
\setmainfont{Latin Modern Roman}
12
+
\setsansfont{Latin Modern Sans}
13
+
14
+
% Custom AC fonts
15
+
\newfontfamily\acbold{ywft-processing-bold}[
16
+
Path=../../system/public/type/webfonts/,
17
+
Extension=.ttf
18
+
]
19
+
\newfontfamily\aclight{ywft-processing-light}[
20
+
Path=../../system/public/type/webfonts/,
21
+
Extension=.ttf
22
+
]
23
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
24
+
25
+
\usepackage{xeCJK}
26
+
\setCJKmainfont{Droid Sans Japanese}
27
+
\setCJKsansfont{Droid Sans Japanese}
28
+
\setCJKmonofont{Droid Sans Japanese}
29
+
30
+
% === PACKAGES ===
31
+
\usepackage{xcolor}
32
+
\usepackage{titlesec}
33
+
\usepackage{enumitem}
34
+
\usepackage{booktabs}
35
+
\usepackage{tabularx}
36
+
\usepackage{multicol}
37
+
\usepackage{fancyhdr}
38
+
\usepackage{hyperref}
39
+
\usepackage{graphicx}
40
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
41
+
\usepackage{ragged2e}
42
+
\usepackage{microtype}
43
+
\usepackage{listings}
44
+
\usepackage{natbib}
45
+
\usepackage[colorspec=0.92]{draftwatermark}
46
+
47
+
% === COLORS (AC palette) ===
48
+
\definecolor{acpink}{RGB}{180,72,135}
49
+
\definecolor{acpurple}{RGB}{120,80,180}
50
+
\definecolor{acdark}{RGB}{64,56,74}
51
+
\definecolor{acgray}{RGB}{119,119,119}
52
+
\definecolor{draftcolor}{RGB}{180,72,135}
53
+
54
+
% === DRAFT WATERMARK ===
55
+
\DraftwatermarkOptions{
56
+
text=WORKING DRAFT,
57
+
fontsize=3cm,
58
+
color=draftcolor!18,
59
+
angle=45,
60
+
pos={0.5\paperwidth, 0.5\paperheight}
61
+
}
62
+
63
+
% === JS SYNTAX COLORS ===
64
+
\definecolor{jskw}{RGB}{119,51,170}
65
+
\definecolor{jsfn}{RGB}{0,136,170}
66
+
\definecolor{jsstr}{RGB}{170,120,0}
67
+
\definecolor{jsnum}{RGB}{204,0,102}
68
+
\definecolor{jscmt}{RGB}{102,102,102}
69
+
70
+
% === HYPERREF ===
71
+
\hypersetup{
72
+
colorlinks=true,
73
+
linkcolor=acpurple,
74
+
urlcolor=acpurple,
75
+
citecolor=acpurple,
76
+
pdfauthor={@jeffrey},
77
+
pdftitle={AC Native OS '26：ベアメタルクリエイティブコンピューティングOS},
78
+
}
79
+
80
+
% === SECTION FORMATTING ===
81
+
\titleformat{\section}
82
+
{\normalfont\bfseries\normalsize\uppercase}
83
+
{\thesection.}
84
+
{0.5em}
85
+
{}
86
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
87
+
88
+
\titleformat{\subsection}
89
+
{\normalfont\bfseries\small}
90
+
{\thesubsection}
91
+
{0.5em}
92
+
{}
93
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
94
+
95
+
% === HEADER/FOOTER ===
96
+
\pagestyle{fancy}
97
+
\fancyhf{}
98
+
\renewcommand{\headrulewidth}{0pt}
99
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{作業草稿——引用不可}}
100
+
\fancyfoot[C]{\footnotesize\thepage}
101
+
102
+
% === CUSTOM COMMANDS ===
103
+
\newcommand{\acdot}{{\color{acpink}.}}
104
+
\newcommand{\ac}{\textsc{Aesthetic.Computer}}
105
+
\newcommand{\acos}{\textsc{AC Native OS}}
106
+
107
+
% === LISTINGS ===
108
+
\lstdefinelanguage{acjs}{
109
+
morekeywords=[1]{function,export,const,let,var,return,if,else,new,async,await,import,from},
110
+
morekeywords=[2]{wipe,ink,line,box,circle,write,screen,params,colon,jump,send,store,net,sound,speaker,system},
111
+
sensitive=true,
112
+
morecomment=[l]{//},
113
+
morestring=[b]",
114
+
morestring=[b]',
115
+
morestring=[b]`,
116
+
escapeinside={|}{|},
117
+
}
118
+
119
+
\lstdefinestyle{acjsstyle}{
120
+
language=acjs,
121
+
keywordstyle=[1]\color{jskw}\bfseries,
122
+
keywordstyle=[2]\color{jsfn}\bfseries,
123
+
commentstyle=\color{jscmt}\itshape,
124
+
stringstyle=\color{jsstr},
125
+
}
126
+
127
+
\lstset{
128
+
basicstyle=\ttfamily\small,
129
+
breaklines=true,
130
+
frame=single,
131
+
rulecolor=\color{acgray!30},
132
+
backgroundcolor=\color{acgray!5},
133
+
xleftmargin=0.5em,
134
+
xrightmargin=0.5em,
135
+
aboveskip=0.5em,
136
+
belowskip=0.5em,
137
+
}
138
+
139
+
% === LIST SETTINGS ===
140
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
141
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
142
+
143
+
% === COLUMN SEPARATION ===
144
+
\setlength{\columnsep}{1.8em}
145
+
146
+
% === PARAGRAPH SETTINGS ===
147
+
\setlength{\parindent}{1em}
148
+
\setlength{\parskip}{0.3em}
149
+
150
+
% Hyphenation for narrow two-column layout
151
+
\tolerance=800
152
+
\emergencystretch=1em
153
+
\hyphenpenalty=50
154
+
155
+
\begin{document}
156
+
157
+
% ============ TITLE BLOCK ============
158
+
159
+
\twocolumn[{%
160
+
\begin{center}
161
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
162
+
{\acbold\fontsize{24pt}{28pt}\selectfont\color{acdark} AC Native OS '26}\par
163
+
\vspace{0.2em}
164
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} ベアメタルクリエイティブコンピューティングOS}\par
165
+
\vspace{0.3em}
166
+
{\aclight\fontsize{9pt}{11pt}\selectfont\color{acgray} 余剰ハードウェア、深い個人化、ポストOLPC楽器}\par
167
+
\vspace{0.6em}
168
+
{\normalsize @jeffrey}\par
169
+
{\small\color{acgray} Aesthetic.Computer}\par
170
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
171
+
\vspace{0.3em}
172
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
173
+
\vspace{0.6em}
174
+
\rule{\textwidth}{1.5pt}
175
+
\vspace{0.5em}
176
+
\end{center}
177
+
178
+
\begin{center}
179
+
{\small\color{acpink}\textbf{[ 作業草稿——引用不可 ]}}
180
+
\end{center}
181
+
\vspace{0.3em}
182
+
183
+
\begin{quote}
184
+
\small\noindent\textbf{要旨。}
185
+
\acos{} を紹介する。あらゆるx86\_64コンピュータを7.3秒でクリエイティブコンピューティング楽器に直接起動するベアメタルLinux OSである。システム全体——カスタムカーネル、PID~1として動作する11,943行のCランタイム、QuickJS JavaScriptエンジン——は89\,MBの単一UEFIバイナリに収まり、ユーザースペースなし、パッケージマネージャなし、デスクトップ環境なし。本OSは\emph{デバイスレベルの個人化}モデルを導入する：各マシンがオーナーのユーザー名、カスタムカラースキーム、音声挨拶とともに起動し、アイデンティティをアプリケーション層ではなくOSの属性とする。このOSを余剰の商用ノートパソコン——退役ThinkPad、リース期限切れの企業マシン、未販売在庫——にフラッシュすることで、OLPCのカスタム教育ハードウェアモデルとも、Appleの商業エコシステムを通じたアイデンティティモデルとも異なる実行可能な代替案を生み出すことを論じる。OLPCは200ドルかかる100ドルのノートパソコンを設計し、Appleは1,000ドルのデバイスを必要とする1,000ドルのアイデンティティを販売し、\acos{} は50ドルの余剰マシンを個人のクリエイティブ楽器に変える——OTAアップデート付き、ITインフラ不要、継続コストゼロ。アーキテクチャ、個人化モデル、OTAアップデートシステム、クリエイティブコンピューティング普及への含意を記述する。
186
+
\end{quote}
187
+
\vspace{0.5em}
188
+
}]
189
+
190
+
% ============ 1. INTRODUCTION ============
191
+
192
+
\section{はじめに}
193
+
194
+
「すべての子どもにラップトップを」（OLPC）プロジェクト~\citep{negroponte1995being, kraemer2009olpc}は、コンピューティングの普及には新しいハードウェアの設計——教育専用に作られた100ドルのノートパソコン——が必要だと提案した。XOラップトップはカスタムOS（Sugar）、カスタムハードウェア、カスタム配布モデルを備えていた。プロジェクトは重要なアイデアを生み出したが、根本的な矛盾に苦しんだ：カスタムハードウェアの設計、製造、保守は高コストであり、100ドルの目標は大規模には決して達成されなかった。
195
+
196
+
一方、消費者向けコンピューティング市場は大量の完全に機能する余剰マシンを絶えず生み出している。企業のリースサイクルは3--5年ごとに数百万台のノートパソコンを退役させる。小売の過剰在庫、キャンセルされた注文、外観の損傷が倉庫在庫を生む。電子廃棄物リサイクル業者は何年もの使用寿命が残ったマシンを受け取る。これらの余剰コンピュータ——ThinkPad、EliteBook、Latitude——は30--80ドルで販売され、最新のプロセッサ、8--16\,GBのメモリ、WiFi、キーボード、ディスプレイを搭載している。
197
+
198
+
\acos{} はOLPCとは逆のアプローチをとる。カスタムハードウェアを設計する代わりに、\emph{あらゆる}商用x86\_64マシンを専用のクリエイティブコンピューティング楽器に変えるカスタムOSを設計する。OS全体が1つのファイル。USBドライブへの書き込みは1分未満。マシンは7.3秒で楽器、ペイントツール、またはプログラミング環境として起動し、画面にオーナーの名前が表示され、音声が名前で挨拶する。
199
+
200
+
本稿ではシステムアーキテクチャ（\S\ref{sec:architecture}）、個人化モデル（\S\ref{sec:personalization}）、余剰ハードウェアの論点（\S\ref{sec:surplus}）、OTAアップデートシステム（\S\ref{sec:ota}）、既存アプローチとの比較（\S\ref{sec:related}）、クリエイティブコンピューティング普及への含意（\S\ref{sec:implications}）を記述する。
201
+
202
+
% ============ 2. ARCHITECTURE ============
203
+
204
+
\section{アーキテクチャ}
205
+
\label{sec:architecture}
206
+
207
+
\acos{} は4つの層で構成される：最小化Linuxカーネル、LZ4圧縮initramfs、PID~1として動作するCランタイム、インタラクティブプログラム（「ピース」）を実行するQuickJS JavaScriptエンジン。
208
+
209
+
\subsection{ブートチェーン}
210
+
211
+
システムはUEFIから起動し、ブートローダー不要。Linuxカーネル（6.14.2）はEFIスタブとしてコンパイルされる——カーネル\emph{が}ブートローダー。LZ4圧縮の埋め込みinitramfsを含むため、OS全体が1つのファイル：FAT32 EFIシステムパーティション上の \texttt{BOOTX64.EFI}。
212
+
213
+
\begin{enumerate}
214
+
\item UEFIファームウェアが \texttt{EFI/BOOT/BOOTX64.EFI}（89\,MB）をロード
215
+
\item カーネルがinitramfsをtmpfsに展開
216
+
\item \texttt{/init}（\texttt{/ac-native} へのシンボリックリンク）がPID~1として起動
217
+
\item \texttt{/proc}、\texttt{/sys}、\texttt{/dev}、\texttt{/tmp} をマウント
218
+
\item EFIパーティションを \texttt{/mnt} にマウントし、\texttt{config.json} を読み取り
219
+
\item DRMディスプレイを初期化、個人化されたブートスクリーンをレンダリング
220
+
\item ALSAオーディオを初期化、起動音を再生（E5$\rightarrow$B5）
221
+
\item 入力デバイスを初期化（キーボード、タッチパッド、タッチスクリーン）
222
+
\item WiFi自動接続（サイレント、ユーザー操作不要）
223
+
\item デフォルトピースをロードし、\texttt{boot()} を呼び出し、メインループに入る
224
+
\end{enumerate}
225
+
226
+
電源投入からインタラクティブピースまでの総起動時間：\textbf{7.3秒}。
227
+
228
+
\subsection{ランタイム}
229
+
230
+
Cランタイム（\texttt{ac-native}、14ソースファイル計11,943行）は従来のOSユーザースペース全体を置き換える。\texttt{systemd} なし、シェルなし、パッケージマネージャなし、ログインプロンプトなし。ランタイムが直接管理する：
231
+
232
+
\begin{itemize}
233
+
\item \textbf{ディスプレイ}：DRM/KMSモード設定、ダブルバッファリングソフトウェアフレームバッファ
234
+
\item \textbf{オーディオ}：192\,kHz ALSA PCM、32音ポリフォニックシンセサイザー、リバーブ付き
235
+
\item \textbf{入力}：evdevポーリングでキーボード、タッチパッド、タッチスクリーン、アナログキー
236
+
\item \textbf{WiFi}：wpa\_supplicant統合、自動接続、DHCP
237
+
\item \textbf{カメラ}：V4L2キャプチャ、YUYV変換、QRコードスキャン
238
+
\item \textbf{音声}：fliteによるテキスト読み上げ（男声・女声）
239
+
\item \textbf{ネットワーク}：TLS付きWebSocketクライアント、UDP、curl経由のHTTP
240
+
\end{itemize}
241
+
242
+
\subsection{ピース実行}
243
+
244
+
ピースはQuickJS~\citep{bellard2005quickjs}によって実行されるJavaScript ESモジュール（\texttt{.mjs}）である。ランタイムはC関数を「system」APIとしてJavaScriptに公開する——グラフィックスプリミティブ、オーディオ合成、入力イベント、ハードウェア情報、システム制御。ピースのライフサイクルはブラウザベースの \ac{} プラットフォーム~\citep{scudder2026ac}と一致する：\texttt{boot()}、\texttt{act()}、\texttt{sim()}、\texttt{paint()}、60\,fpsで実行。
245
+
246
+
\begin{lstlisting}[style=acjsstyle]
247
+
function boot({ system, screen }) {
248
+
system.tts(|\textcolor{jsstr}{"welcome"}|)
249
+
}
250
+
251
+
function paint({ wipe, ink, write, screen }) {
252
+
wipe(|\textcolor{jsnum}{20}|, |\textcolor{jsnum}{10}|, |\textcolor{jsnum}{40}|)
253
+
ink(|\textcolor{jsnum}{255}|)
254
+
write(|\textcolor{jsstr}{"hello"}|, { center: |\textcolor{jsstr}{"xy"}| })
255
+
}
256
+
257
+
export { boot, paint };
258
+
\end{lstlisting}
259
+
260
+
ピースは \texttt{system.jump("piece-name")} で再起動なしにホットスイッチできる。OSは11のピースを同梱し、半音階キーボード楽器、コマンドラインナビゲータ、システム管理パネル、Claude AIチャットクライアント、ターミナルエミュレータを含む。
261
+
262
+
\subsection{サイズバジェット}
263
+
264
+
\begin{table}[h]
265
+
\small
266
+
\centering
267
+
\begin{tabular}{lr}
268
+
\toprule
269
+
\textbf{コンポーネント} & \textbf{サイズ} \\
270
+
\midrule
271
+
Linuxカーネル（コンパイル済み） & $\sim$10\,MB \\
272
+
ac-nativeバイナリ & 1.2\,MB \\
273
+
QuickJSエンジン & 0.8\,MB \\
274
+
共有ライブラリ（libc、libdrm、ALSA、SSL、flite） & $\sim$45\,MB \\
275
+
WiFiファームウェア（iwlwifi） & 4.9\,MB \\
276
+
ピース、フォント、証明書 & $\sim$28\,MB \\
277
+
\midrule
278
+
Initramfs（非圧縮） & $\sim$201\,MB \\
279
+
Initramfs（LZ4圧縮） & $\sim$90\,MB \\
280
+
\textbf{最終イメージ（vmlinuz）} & \textbf{$\sim$89\,MB} \\
281
+
\bottomrule
282
+
\end{tabular}
283
+
\caption{システムサイズの内訳。}
284
+
\label{tab:size}
285
+
\end{table}
286
+
287
+
OS全体が一般的なブラウザダウンロードより小さい。過去15年間に製造されたどんなUSBドライブにも収まる。
288
+
289
+
% ============ 3. DEVICE-LEVEL PERSONALIZATION ============
290
+
291
+
\section{デバイスレベルの個人化}
292
+
\label{sec:personalization}
293
+
294
+
消費者向けOSはアイデンティティをアプリケーション層のアカウントに置く：Apple ID、Googleアカウント、Microsoftログイン。ユーザーがログインするまで、デバイス自体は汎用的である。\acos{} はこれを逆転させる：アイデンティティはブートパーティションの属性である。
295
+
296
+
\subsection{config.json}
297
+
298
+
EFIシステムパーティション上のJSONファイルがオーナーのアイデンティティを保存する：
299
+
300
+
\begin{lstlisting}[style=acjsstyle]
301
+
{
302
+
|\textcolor{jsstr}{"handle"}|: |\textcolor{jsstr}{"jeffrey"}|,
303
+
|\textcolor{jsstr}{"colors"}|: [|\textcolor{jsnum}{180}|, |\textcolor{jsnum}{72}|, |\textcolor{jsnum}{135}|],
304
+
|\textcolor{jsstr}{"tokens"}|: { |\textcolor{jsstr}{"claude"}|: |\textcolor{jsstr}{"..."}| }
305
+
}
306
+
\end{lstlisting}
307
+
308
+
このファイルはOSアップデートを超えて永続する。OTAプロセスはカーネルバイナリを置き換えるがEFIパーティションの残りは保持するためである。デバイスはソフトウェアが進化しても誰のものかを覚えている。
309
+
310
+
\subsection{挨拶としてのブート}
311
+
312
+
マシンの電源が入ると、ブートシーケンスがスプラッシュスクリーンにアニメーションレインボーテキストでオーナーのユーザー名をレンダリングする：「hi @jeffrey。」テキスト読み上げエンジンが挨拶を声に出す：「hi jeffrey。」シャットダウン時：「bye jeffrey。」コンピュータはソフトウェアスタックの最深層で\emph{あなたを知っている}——サービスにログインしたからではなく、あなたの名前がブートパーティションに書かれているから。
313
+
314
+
これはApple（購買とアカウントによるアイデンティティ）とOLPC（制度的配布によるアイデンティティ）の両方と根本的に異なるモデルである。ここではアイデンティティはフラッシュ行為を通じてデバイスに直接刻まれる。USBドライブを準備する人——教師、親、友人、またはユーザー自身——がオーナーの名前をマシンの意識の最初の瞬間に書き込む。
315
+
316
+
\subsection{ビルドアイデンティティ}
317
+
318
+
各OSビルドはgitコミットハッシュから派生したユニークな名前を獲得する：形容詞と動物の組み合わせ（例：``keen-egret''、``swift-otter''、``bright-phoenix''）。この名前は起動時に金色のテキストで表示され、TTSで読み上げられ、\texttt{system.hw.buildName} を通じてピースに公開される。マシンには\emph{2つの}アイデンティティがある：誰のものか、そしてどのバージョンを動かしているか。両方とも起動時に宣言される。
319
+
320
+
命名システムは73,000のユニークな組み合わせ（365種の動物 $\times$ 200の形容詞）を生成し、確定的である：同じコミットは常に同じ名前を生成する。ユーザーはビルド名に愛着を持つ。マシンはシリアル番号ではなく ``keen-egret'' である。
321
+
322
+
% ============ 4. THE SURPLUS HARDWARE THESIS ============
323
+
324
+
\section{余剰ハードウェアの論点}
325
+
\label{sec:surplus}
326
+
327
+
\subsection{OLPCの教訓}
328
+
329
+
OLPCはハードウェア先行のコンピューティング普及アプローチが複合的な課題に直面することを実証した~\citep{kraemer2009olpc}：カスタムハードウェア開発は予想以上のコスト、スケール化された製造には設計を制約する制度的協力が必要、修理/保守インフラはゼロから構築しなければならない。XOラップトップの100ドル目標は生産時に188ドルになった。Sugar OSは設計の革新性にもかかわらず、カスタムハードウェアを中心に開発者エコシステムを維持できなかった。
330
+
331
+
Raspberry Pi~\citep{raspberry2012}はコスト問題を部分的に解決した（35ドル）が、異なる摩擦を導入した：ユーザーはモニター、キーボード、マウス、SDカード、電源を用意しなければならず、アクセサリーがボードより高くつくことが多い。機能的なPiワークステーションの総コストは150--200ドルに近づく。
332
+
333
+
\subsection{素材としての余剰}
334
+
335
+
x86\_64ラップトップの余剰市場はまったく異なる方程式を提供する。退役したThinkPad X1 Carbon（2019--2021年モデル）は50--80ドルで販売され、以下を搭載する：
336
+
337
+
\begin{itemize}
338
+
\item 14インチ 1080pまたは2Kディスプレイ
339
+
\item 4--8コアIntelプロセッサ
340
+
\item 8--16\,GBメモリ
341
+
\item WiFi 6、Bluetooth
342
+
\item フルキーボードとタッチパッド
343
+
\item 6--10時間バッテリー
344
+
\item USB-C充電（汎用）
345
+
\end{itemize}
346
+
347
+
これらは完全で自己完結したコンピュータであり、USBドライブ1本でクリエイティブ楽器になる。余剰は企業の更新サイクルによって存在するのであり、ハードウェアの故障によるのではない。\acos{} を動かす2020年のThinkPadは同じマシンでWindows 11を動かすより速く起動し、スムーズに動作し、集中した体験を提供する。
348
+
349
+
\subsection{経済性}
350
+
351
+
\begin{table}[h]
352
+
\small
353
+
\centering
354
+
\begin{tabular}{lrr}
355
+
\toprule
356
+
\textbf{アプローチ} & \textbf{デバイスコスト} & \textbf{アクセサリー} \\
357
+
\midrule
358
+
OLPC XO-1 & \$188 & \$0 \\
359
+
Raspberry Pi 5 & \$35 & \$100--150 \\
360
+
Chromebook（新品） & \$200--300 & \$0 \\
361
+
iPad（教育価格） & \$299 & \$0--130 \\
362
+
余剰ThinkPad + AC OS & \$50--80 & \$0 \\
363
+
\bottomrule
364
+
\end{tabular}
365
+
\caption{コンピューティング普及アプローチのコスト比較。}
366
+
\label{tab:cost}
367
+
\end{table}
368
+
369
+
余剰アプローチは製造不要、サプライチェーン不要、最小注文数量不要。学校、コミュニティセンター、個人がローカルのリサイクル業者、オンラインマーケットプレイス、企業IT部門から1台ずつマシンを調達できる。各マシンは1分以内に個人化された \acos{} USBでフラッシュされる。
370
+
371
+
\subsection{Appleモデルへの反論}
372
+
373
+
Appleのパーソナルコンピューティングアプローチはデバイスアイデンティティを商業関係に結びつける。デバイスにあなたの名前が表示されるのは、Apple IDで購入したから。設定が永続するのはiCloudで同期されるから。クリエイティブツールが使えるのはサービスにサブスクリプションしたから。デバイスが個人的なのは\emph{購入された}から。
374
+
375
+
\acos{} はデバイスアイデンティティが購入ではなく刻印されうると提案する。50ドルの余剰ノートパソコンが起動画面に「hi @maria」と表示し、スプラッシュスクリーンに彼女の好きな色を映し、名前を声に出す——これは誰にも挨拶しない1,000ドルのMacBookより\emph{より個人的}である。個人化はより深い——アプリケーション層の下、デスクトップの下、ブートシーケンスの最初の瞬間に存在する——しかも設定ファイルを書く以外のコストはかからない。
376
+
377
+
これは高品質ハードウェアに反対する論証ではない。人とコンピュータの関係が購買、アカウント、サブスクリプションを介在させる必要はないという論証である。楽器があなたを知っているのは、誰か——おそらくあなた自身——が\emph{それに伝えた}からである。
378
+
379
+
% ============ 5. OTA UPDATES ============
380
+
381
+
\section{OTAアップデート}
382
+
\label{sec:ota}
383
+
384
+
分散コンピューティングプロジェクトの重要な課題はメンテナンスである。OLPCの展開は接続が限られた地域でソフトウェアアップデートに苦労した~\citep{warschauer2004technology}。Chromebookは強制的なクラウド接続で解決する。\acos{} は中間路線をとる：WiFi利用可能時に自動アップデートするが、デバイスはオフラインでも完全に使用可能。
385
+
386
+
\subsection{アップデートメカニズム}
387
+
388
+
\begin{enumerate}
389
+
\item WiFi接続後、OSが \texttt{/api/native/version} をチェック
390
+
\item 新しいビルドが存在すれば、新しいカーネルイメージ（約89\,MB）を進捗追跡付きでダウンロード
391
+
\item 新イメージがEFIパーティションに書き込まれ、\texttt{BOOTX64.EFI} を置換
392
+
\item バイト単位のSHA256検証で書き込みを確認
393
+
\item デバイスが新バージョンで再起動
394
+
\end{enumerate}
395
+
396
+
\texttt{config.json} ファイルはアップデートを超えて維持される——デバイスはオーナーのアイデンティティ、カラー、トークンを保持する。アップデートプロセスは電源断に対して堅牢化されている：コピー前にソースイメージを検証し、ファイルシステムをダブルsyncし、キャッシュアーティファクトを防ぐため新しくマウントされたパーティションに対して検証を行う。
397
+
398
+
\subsection{ITインフラ不要}
399
+
400
+
Google Admin Console、MDMプロファイル、組織のGoogle Workspaceアカウントを必要とするChromebook展開と異なり、\acos{} は管理インフラを一切必要としない。各デバイスは自律的。アップデートはデバイスが任意のWiFiネットワークに接続したときに伝播する。登録なし、デバイスフリート管理なし、デバイスごとのライセンスなし。運用コストはゼロ。
401
+
402
+
% ============ 6. RELATED WORK ============
403
+
404
+
\section{関連研究}
405
+
\label{sec:related}
406
+
407
+
\textbf{教育向けOSプロジェクト。} Sugar OS（OLPC）は単一目的の教育OSを先駆けたが、ハードウェア依存性に制約された。Endless OSは低スペックハードウェア向けにオフラインファーストのコンテンツを提供するが、従来のデスクトップメタファーを維持。PrimTuxとEdubuntuは教育向けにLinuxディストリビューションをカスタマイズするが、OS層自体を再構想していない。
408
+
409
+
\textbf{キオスクと単一目的システム。} デジタルサイネージOS（Screenly、Yodeck）は単一目的のLinuxデプロイメントがOTAアップデートで大規模にメンテナンス可能であることを実証。\acos{} はこの運用モデルをコンテンツ表示ではなくクリエイティブコンピューティングに適用。
410
+
411
+
\textbf{クリエイティブコンピューティングの普及。} Processing~\citep{reas2007processing} と Scratch~\citep{resnick2009scratch} はクリエイティブプログラミングの障壁を下げたが、その下に汎用OSを前提とする。Sonic Pi~\citep{aaron2016sonic} はRaspberry Pi上で動作するがRaspbianが必要。\acos{} はOS依存を完全に排除する——クリエイティブツール\emph{が}OSである。
412
+
413
+
\textbf{自律的ツール。} Illichの「自律的ツール」概念~\citep{illich1973tools}——専門知識を要求するのではなく個人の自律性を拡張するツール——は \acos{} の設計と共鳴する。デバイスはシステム管理不要、ITサポート不要、USBドライブを差し込む以上の技術知識不要。Papertの構成主義~\citep{papert1980mindstorms}はデフォルト体験としてコンテンツ消費デバイスではなくクリエイティブ楽器を選択する根拠となった。
414
+
415
+
\textbf{メディア理論。} ソフトウェアがコンピューティングの物質的現実を覆い隠すというKittlerの論点~\citep{kittler1995no}は \acos{} によって反転される：デスクトップ環境なし、ウィンドウマネージャなし、抽象層なし——コードとハードウェアの関係が可視になる。ブートスクリーンはDRMフレームバッファに直接レンダリングされる。オーディオ合成はALSA PCMバッファに直接書き込まれる。メディアがメッセージを形成するというMcLuhanの観察~\citep{mcluhan1964understanding}はここで文字通り適用される：OS\emph{が}楽器であり、その制約（一度に1つのピース、即時モードグラフィックス、直接オーディオ合成）がクリエイティブ出力を形成する。
416
+
417
+
% ============ 7. IMPLICATIONS ============
418
+
419
+
\section{含意と今後の研究}
420
+
\label{sec:implications}
421
+
422
+
\subsection{配布モデル}
423
+
424
+
余剰ハードウェアの論点は配布モデルを示唆する：組織が退役ノートパソコンをまとめて調達し（1台30--80ドル）、個人化された \acos{} USBをフラッシュし、配布する。デバイスは自動アップデートするクリエイティブ楽器として起動する。デバイスあたりのコストは既存のどのアプローチの一部であり、環境負荷はマイナス——マシンが電子廃棄物の流れから転用される。
425
+
426
+
30台のクリエイティブコンピューティング楽器の教室は1,500--2,400ドルのハードウェアとUSBドライブをフラッシュする人件費で整備できる。継続的サブスクリプションなし、ITサポート契約なし、ホスティングアカウントなし。
427
+
428
+
\subsection{デバイスとしての楽器}
429
+
430
+
デスクトップやブラウザではなく楽器（notepat、半音階キーボード）として起動する選択は意図的である。デバイスは消費者的意味での「コンピュータ」ではない——たまたまプログラム可能な楽器である。このフレーミングは \ac{} の「IDEではなく楽器」のデザイン哲学に由来し、ユーザーとマシンの関係を変える。デバイスを「使っている」のではなく、\emph{演奏している}のである。
431
+
432
+
\subsection{ケアとしてのメンテナンス}
433
+
434
+
Ukelesの「メンテナンスアート宣言」~\citep{ukeles1969manifesto}はメンテナンスを創造的行為として再フレーミングした。\acos{} のOTAシステムはこれを体現する：各アップデートに名前がつき（``keen-egret''が``swift-otter''に）、デバイスが新しいアイデンティティを宣言し、トランジションは目に見えないバックグラウンドプロセスではなく小さなイベントとなる。メンテナンスが可視化され、さらには祝福される。
435
+
436
+
\subsection{限界}
437
+
438
+
システムは現在x86\_64 UEFIマシンを対象としており、ARM ChromebookとBIOSのみの古いハードウェアは含まれない。WiFiサポートはIntel iwlwifiファームウェアに依存し、BroadcomとRealtekアダプタはまだ未対応。一度に1つのピースのモデルはマルチタスクを制限する。ソフトウェアラスタライザは60\,fpsでの2Dグラフィックスには十分だが、3Dレンダリングはアクセラレートできない。これらの制約はアーキテクチャ上の選択であり、永続的な限界ではない。
439
+
440
+
\subsection{今後の方向}
441
+
442
+
\begin{itemize}
443
+
\item \textbf{ARMサポート}：Chromebook（Mediatek/Qualcomm）対応で最大の余剰教育ハードウェアプールにアクセス
444
+
\item \textbf{メッシュネットワーク}：インターネットインフラ不要のピアツーピアピース共有とマルチプレイヤー
445
+
\item \textbf{ハードウェアGPU}：ベアメタルモデルを維持したままアクセラレートグラフィックス用のDRMレンダーノード
446
+
\item \textbf{マルチピース}：軽量マルチタスク用の分割画面またはタブ式ピースナビゲーション
447
+
\item \textbf{コミュニティフラッシュ}：参加者が一緒に余剰マシンをフラッシュし個人化するイベント
448
+
\end{itemize}
449
+
450
+
% ============ 8. CONCLUSION ============
451
+
452
+
\section{結論}
453
+
454
+
\acos{} は完全なクリエイティブコンピューティング体験が89\,MBに収まり、7.3秒で起動し、教科書1冊より安いハードウェアで動作することを実証する。カスタムハードウェアではなく余剰の商用ノートパソコンを対象とすることで、OLPCを制約した製造、配布、メンテナンスの課題を回避する。アイデンティティを商業アカウントではなくブートパーティションに置くことで、Appleよりも深くコストゼロの個人化モデルを提供する。
455
+
456
+
本システムはプロトタイプや概念実証ではない。物理ハードウェアにデプロイされ、OTAアップデートを受け、オーディオ合成、WiFiネットワーク、カメラ入力、テキスト読み上げを備えた機能完全なクリエイティブコンピューティングランタイムを動作させている。11,943行のCコードが従来のユーザースペース全体を置き換える。
457
+
458
+
\acos{} が提起する問いは技術的ではなく経済的・文化的である：毎年数百万台の機能する計算機が廃棄され、完全なクリエイティブOSが89\,MBで済む今、すべての人が個人のクリエイティブ楽器を持つことを阻んでいるのは何か？答えはハードウェアコストでも、ソフトウェアの複雑さでも、インフラの要件でもない。おそらく、まだ誰も試みていなかっただけである。
459
+
460
+
\vspace{0.5em}
461
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
462
+
463
+
% ============ REFERENCES ============
464
+
465
+
\bibliographystyle{plainnat}
466
+
\bibliography{references}
467
+
468
+
\end{document}
+13
-11
papers/arxiv-pieces/pieces-cards.tex
+13
-11
papers/arxiv-pieces/pieces-cards.tex
···
38
38
\thispagestyle{empty}
39
39
\vspace*{\fill}
40
40
\begin{center}
41
-
\includegraphics[height=8em]{pals}\par\vspace{0.3em}
42
-
{\acbold\fontsize{20pt}{24pt}\selectfont\color{acdark} Pieces Not Programs}\par
43
-
\vspace{0.3em}
44
-
{\fontsize{10pt}{12pt}\selectfont\color{acpink} The Piece as a Unit of Creative Cognition in \ac{}}\par
45
-
\vspace{0.8em}
46
-
{\normalsize\color{cyan!70!blue}\textbf{@jeffrey}}\par
41
+
\includegraphics[height=9em]{pals}\par\vspace{0.1em}
42
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} Pieces Not Programs}\par
43
+
\vspace{0.1em}
44
+
{\fontsize{9pt}{11pt}\selectfont\color{acpink} The Piece as a Unit of Creative Cognition in \ac{}}\par
45
+
\vspace{0.4em}
46
+
{\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par
47
47
{\small\color{acgray} Aesthetic.Computer}\par
48
48
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
49
-
\vspace{0.8em}
50
-
\rule{0.6\textwidth}{1pt}\par
51
49
\vspace{0.4em}
52
-
{\small\color{acpink!40}\textit{working draft --- not for citation}}\par
53
-
\vspace{0.3em}
54
-
{\footnotesize\color{acgray} March 2026}\par
50
+
\rule{0.5\textwidth}{0.5pt}\par
51
+
\vspace{0.15em}
52
+
\colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par
53
+
\vspace{0.1em}
54
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/2113ef735}{2113ef735}}\par
55
+
\vspace{0.1em}
56
+
{\footnotesize\color{acgray}\href{https://papers.aesthetic.computer/pieces-not-programs-26-arxiv-da-cards.pdf}{Dansk} · \href{https://papers.aesthetic.computer/pieces-not-programs-26-arxiv-es-cards.pdf}{Español} · \href{https://papers.aesthetic.computer/pieces-not-programs-26-arxiv-zh-cards.pdf}{{\accjk 中文}} · \href{https://papers.aesthetic.computer/pieces-not-programs-26-arxiv-ja-cards.pdf}{{\accjk 日本語}}}\par
55
57
\end{center}
56
58
\vspace*{\fill}
57
59
+265
papers/arxiv-pieces/pieces-ja.tex
+265
papers/arxiv-pieces/pieces-ja.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
\setmainfont{Latin Modern Roman}
11
+
\setsansfont{Latin Modern Sans}
12
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
13
+
\newfontfamily\acbold{ywft-processing-bold}[
14
+
Path=../../system/public/type/webfonts/,
15
+
Extension=.ttf
16
+
]
17
+
\newfontfamily\aclight{ywft-processing-light}[
18
+
Path=../../system/public/type/webfonts/,
19
+
Extension=.ttf
20
+
]
21
+
22
+
\usepackage{xeCJK}
23
+
\setCJKmainfont{Droid Sans Japanese}
24
+
\setCJKsansfont{Droid Sans Japanese}
25
+
\setCJKmonofont{Droid Sans Japanese}
26
+
27
+
% === PACKAGES ===
28
+
\usepackage{xcolor}
29
+
\usepackage{titlesec}
30
+
\usepackage{enumitem}
31
+
\usepackage{booktabs}
32
+
\usepackage{tabularx}
33
+
\usepackage{fancyhdr}
34
+
\usepackage{hyperref}
35
+
\usepackage{graphicx}
36
+
\usepackage{ragged2e}
37
+
\usepackage{microtype}
38
+
\usepackage{natbib}
39
+
\usepackage[colorspec=0.92]{draftwatermark}
40
+
41
+
% === COLORS ===
42
+
\definecolor{acpink}{RGB}{180,72,135}
43
+
\definecolor{acpurple}{RGB}{120,80,180}
44
+
\definecolor{acdark}{RGB}{64,56,74}
45
+
\definecolor{acgray}{RGB}{119,119,119}
46
+
\definecolor{draftcolor}{RGB}{180,72,135}
47
+
48
+
% === DRAFT WATERMARK ===
49
+
\DraftwatermarkOptions{
50
+
text=WORKING DRAFT,
51
+
fontsize=3cm,
52
+
color=draftcolor!18,
53
+
angle=45,
54
+
pos={0.5\paperwidth, 0.5\paperheight}
55
+
}
56
+
57
+
% === HYPERREF ===
58
+
\hypersetup{
59
+
colorlinks=true,
60
+
linkcolor=acpurple,
61
+
urlcolor=acpurple,
62
+
citecolor=acpurple,
63
+
pdfauthor={@jeffrey},
64
+
pdftitle={プログラムではなくピース},
65
+
}
66
+
67
+
% === SECTION FORMATTING ===
68
+
\titleformat{\section}
69
+
{\normalfont\bfseries\normalsize\uppercase}
70
+
{\thesection.}
71
+
{0.5em}
72
+
{}
73
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
74
+
75
+
\titleformat{\subsection}
76
+
{\normalfont\bfseries\small}
77
+
{\thesubsection}
78
+
{0.5em}
79
+
{}
80
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
81
+
82
+
% === HEADER/FOOTER ===
83
+
\pagestyle{fancy}
84
+
\fancyhf{}
85
+
\renewcommand{\headrulewidth}{0pt}
86
+
\fancyhead[C]{\footnotesize\color{draftcolor}\textit{作業草稿——引用不可}}
87
+
\fancyfoot[C]{\footnotesize\thepage}
88
+
89
+
% === LIST SETTINGS ===
90
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
91
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
92
+
93
+
% === COLUMN SEPARATION ===
94
+
\setlength{\columnsep}{1.8em}
95
+
96
+
% === PARAGRAPH SETTINGS ===
97
+
\setlength{\parindent}{1em}
98
+
\setlength{\parskip}{0.3em}
99
+
100
+
% Hyphenation for narrow two-column layout
101
+
\tolerance=800
102
+
\emergencystretch=1em
103
+
\hyphenpenalty=50
104
+
105
+
\newcommand{\acdot}{{\color{acpink}.}}
106
+
\newcommand{\ac}{\textsc{Aesthetic.Computer}}
107
+
108
+
\begin{document}
109
+
110
+
\twocolumn[{%
111
+
\begin{center}
112
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
113
+
{\acbold\fontsize{24pt}{28pt}\selectfont\color{acdark} プログラムではなくピース}\par
114
+
\vspace{0.2em}
115
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} \ac{} における創造的認知の単位としてのピース}\par
116
+
\vspace{0.6em}
117
+
{\normalsize @jeffrey}\par
118
+
{\small\color{acgray} Aesthetic.Computer}\par
119
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
120
+
\vspace{0.3em}
121
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
122
+
\vspace{0.6em}
123
+
\rule{\textwidth}{1.5pt}
124
+
\vspace{0.5em}
125
+
\end{center}
126
+
127
+
\begin{center}
128
+
{\small\color{draftcolor}\textbf{[ 作業草稿——引用不可 ]}}
129
+
\end{center}
130
+
\vspace{0.3em}
131
+
132
+
\begin{quote}
133
+
\small\noindent\textbf{要旨。}
134
+
\ac{} はそのインタラクティブプログラムを\emph{ピース}（pieces）と呼ぶ——スケッチでもパッチでもスクリプトでもアプリでもない。本論文は、この用語選択が装飾的なものではないことを論じる。それは音楽と視覚芸術から、創造的作品が機械の仕様書ではなく\emph{著者を持ち、演奏可能で、反復的に改良される成果物}であるという枠組みを導入する。私たちは計算の単位としてのピースの系譜をたどり、Processingスケッチ、Max/MSPパッチ、Unixプロセス、Smalltalkイメージ、Jupyterノートブックと比較する。次にACピースの実際の形態を検討する：単一ファイルでURL指定可能なプログラムであり、具身化されたエージェントの知覚-行動循環を模倣するライフサイクル（\texttt{boot}、\texttt{paint}、\texttt{act}、\texttt{sim}、\texttt{leave}）を持つ~\citep{varela1991embodied}。ピースという概念——プログラムという概念ではなく——を中心に命名しデザインすることで、著者・プラットフォーム・受け手の間に質的に異なる関係が生まれることを論じる：ソフトウェアが単にデプロイされるのではなく、実践されるという関係である。
135
+
\end{quote}
136
+
\vspace{0.5em}
137
+
}]
138
+
139
+
\section{序論}
140
+
141
+
Turingが1936年に計算を定義した際、彼は基本対象を「計算可能数」と呼び、「機械」によって生成されるものとした~\citep{turing1936computable}。\emph{プログラム}（program）という語——ギリシャ語の\emph{programma}（公告または書面通知）に由来する——は、この官僚的枠組みの自然な延長として計算の世界に入った。プログラムとは命令の集合であり、実行すべき計画である。プログラムは正しいか正しくないかである。コンパイルが通るか通らないかである。デプロイされるものであり、演奏されるものではない。
142
+
143
+
クリエイティブ・コンピューティングの歴史は、ある程度、この枠組みの緩やかな侵食である。Processingスケッチ~\citep{reas2007processing}は、プログラムを使い捨ての探索的なものに置き換えた。Max/MSPパッチ~\citep{puckette1988patcher}は、ソースファイルを生きたデータフローグラフに置き換えた。Scratch~\citep{resnick2009scratch}は、命令列をブロックの組み合わせに置き換えた。それぞれの改名は再設計でもあった：新しい単位の機能的余裕（アフォーダンス）は、誰が作り、どのくらいの時間がかかり、何をもって完成とするかについての新しい前提を持っていた。
144
+
145
+
\ac{} はそのプログラムを\emph{ピース}と呼ぶ~\citep{scudder2026ac}。本論文は、なぜそれが重要なのかを検討する。
146
+
147
+
\section{創造的単位の系譜}
148
+
149
+
\subsection{音楽作品}
150
+
151
+
音楽において、\emph{ピース}（piece）は完結した著者を持つ創作物であり、少なくとも二つの形態で存在する：楽譜（記号的仕様）と演奏（インスタンス化）。両者は同一ではない——演奏ごとに異なり、楽譜は解釈を必要とし、作品は時間とともに変奏を蓄積する。ピースは一回の演奏で汲み尽くされることはない。また社会的に位置づけられてもいる：ピースには名前、著者、初演、そしてカノンがある。教えられ、分析され、カバーされ、忘れられる。
152
+
153
+
この二重性——仕様と演奏、テクストと遂行——はプログラムという概念には欠けている。プログラムは通常そのソースコード（またはバイナリ）と同一視される。その「演奏」は付随的であり、重要なのは出力が正しいかどうかである。
154
+
155
+
\subsection{Processingスケッチ}
156
+
157
+
Processingスケッチ~\citep{reas2007processing}は意図的に芸術の語域を導入した。\emph{スケッチ}（sketch）という語は不完全さ、探索、反復を暗示する。スケッチはデプロイされない——共有され、その上に構築され、あるいは放棄される。Processing環境は、書く・実行する・エクスポートするを中心に組織されたIDEでこれを強化した——エンジニアリングよりも素描に近いサイクルである。
158
+
159
+
スケッチモデルには限界がある：スケッチはローカルファイルであり、URLではない。プラットフォームによる社会的な配布がない。ウィンドウを閉じるとライフサイクルが終了する。
160
+
161
+
\subsection{Max/MSPパッチ}
162
+
163
+
Maxの\emph{パッチ}（patch）~\citep{puckette1988patcher,puckette1996pure}は制御フロー列ではなくデータフローグラフである。パッチは空間的に構築され、書くのではなく接続によって作られる。本質的にパフォーマティブである：実行されていないMaxパッチには意味がなく、その振る舞いは流れるリアルタイムデータによって定義される。これによりパッチはプログラムよりも楽器に近くなる——実行されるのではなく、演奏される。
164
+
165
+
パッチは特定の意味で一時的でもある：パッチを閉じて再び開くと同じ構造が返るが、演奏状態は消失する。パッチは楽譜であり、実行中のインスタンスが演奏である。
166
+
167
+
\subsection{Unixプロセス}
168
+
169
+
Unix\emph{プロセス}（process）は異なる概念である：ソースコードでもバイナリでもなく、実行中のインスタンス——独自のアドレス空間、ファイルディスクリプタ、PIDを持つ実行中のプログラムである。プロセスは演奏であり、楽譜ではない。Unix哲学（一つの道具で一つのことを行い、パイプで組み合わせる）はプロセスを、著者を持つ作品ではなく、組み合わせ可能なプリミティブとして扱う。プロセスは芸術的意味での著者を持たない——管理的意味での所有者を持つだけである。
170
+
171
+
Unixモデルは強力かつ永続的だが、ピースの概念とは逆の方向を指している：著者性、反復、表現ではなく、正確性、組み合わせ可能性、システム管理に向かっている。
172
+
173
+
\subsection{SmalltalkイメージとJupyterノートブック}
174
+
175
+
Alan KayのSmalltalk~\citep{kay1977personal}は異なる単位を提案した：\emph{イメージ}（image）——すべてのオブジェクトとその状態の永続的で生きたスナップショットである。イメージはコンパイルすべきファイルではなく、住まうべき世界である。オブジェクトはメッセージを受け取り、環境は応答する。これはプログラムの概念よりもピースの概念に近いが、現代のオペレーティングシステムのファイル単位のパラダイムに抵抗したため、主流のクリエイティブプログラミングには移行しなかった。
176
+
177
+
Jupyterノートブックは興味深い中間位置を占める：ドキュメント（叙述）であると同時にプロセス（実行可能なセル）でもある。ノートブックはプログラムよりも散文に近いが、その単位はセルであり、全体ではない。
178
+
179
+
\section{ACピースとは何か}
180
+
181
+
\ac{} ピースは単一の\texttt{.mjs}または\texttt{.lisp}ファイルであり、ライフサイクル関数をエクスポートする：
182
+
183
+
\begin{itemize}
184
+
\item \texttt{boot} —— 初期化、ロード時に一度実行、
185
+
\item \texttt{paint} —— 描画、毎フレーム実行、
186
+
\item \texttt{act} —— イベント処理（入力、ネットワーク、時間）、
187
+
\item \texttt{sim} —— シミュレーションロジック、毎フレーム実行、
188
+
\item \texttt{leave} —— 終了時のクリーンアップ。
189
+
\end{itemize}
190
+
191
+
このライフサイクルは恣意的ではない。具身化された認知科学が記述する知覚-行動循環~\citep{varela1991embodied}に対応している：エージェントが環境を知覚し（\texttt{act}）、内部状態を更新し（\texttt{sim}）、出力を生成する（\texttt{paint}）。ピースは計算の仕様書ではない——それは持続的な認知プロセスの記述である。
192
+
193
+
\subsection{URLアドレス指定}
194
+
195
+
すべてのピースはURLでアドレス指定できる：\texttt{aesthetic.computer/piece-name}。これによりピースはファイルではなく記憶可能なパスとなる。URL名前空間がピース名前空間である。ユーザーがピースを発見する方法は、音楽作品を発見する方法と同じである——名前によって、参照によって、コレクションを閲覧することによって。これがACをIDEやサンドボックスと区別するものである：ピースは技術的である前に、まず社会的である。
196
+
197
+
\subsection{即時描画モデル}
198
+
199
+
\ac{} は即時モード（イミディエイトモード）グラフィックスを使用する：\texttt{paint}は毎フレーム呼び出され、画面はゼロから再構築される。保持されたシーングラフも、永続的なDOMも、オブジェクトモデルもない。これは認知的に重要である：ピースは時間と状態の純粋関数であり、累積的構造ではない。プログラマーは\emph{今何を描くか}で考え、\emph{何を変更するか}ではない。これは演奏中の音楽家の思考方法と一致する——「今どの音符を押さえているか」ではなく「次に何を弾くか」である。
200
+
201
+
\subsection{著者性と反復}
202
+
203
+
ピースには著者がいる。名前を付けて公開され、帰属が示され、\texttt{source}コマンドでフォークできる。ユーザーが\texttt{source piece-name}を実行すると、ピースのソースコードのコピーを取得し、新たな著者となる。これは音楽におけるカバーの概念である：既存の作品を取り上げ、自分のものにする。
204
+
205
+
反復のサイクル——書く、公開する、演奏する、観察する、修正する——はソフトウェアのデプロイよりも音楽制作やビジュアルアートの実践に近い。\citet{mcpherson2020idiomatic}は、コンピュータ音楽言語が特定のイディオムを容易にすることで美的結果をどう形作るかを記録した。ピースのライフサイクルは、反復的でパフォーマティブな開発を最小抵抗のパスにすることで、何が作られるかを形作る。
206
+
207
+
\section{認知的拡張としてのピース}
208
+
209
+
ClarkとChalmersは、外部ツールが確実に使用され、利用可能で、承認されている場合、認知プロセスはそのツールへと拡張しうると論じた~\citep{clark1998extended}。思考のために使われるノートブックは認知システムの一部であり、ノートブックの中身は記憶の中の事実と同様に「心の中」にある。
210
+
211
+
日常的に演奏されるピースは、まさにこの意味で認知的拡張となる。\texttt{notepat}~\citep{scudder2026notepat}は単にJeffreyが音を出すために使うツールではない——音楽的思考のための義肢である。\texttt{notepat}への401回のコミットはユーティリティへのバグフィックスではなく、認知器官の精緻化である。ピースはその著者とともに共進化する。
212
+
213
+
これは\citet{magnusson2010designing}が記述する楽器の認識論的次元である：楽器は「認識論的ツール」であり、演奏者が思考し表現できるものを形作る。デジタル楽器はアコースティック楽器と異なる——ソフトウェアであるからだ。そしてソフトウェアはそのユーザーによって変更できる。ツールがピースであり、その著者がその演奏者でもあるとき、楽器と作品の境界は消解する。
214
+
215
+
\subsection{名前付きパスとしてのニーモニック}
216
+
217
+
Normanのアフォーダンスの概念~\citep{norman1988design}は、オブジェクトがその可能な使用法をいかに示唆するかを記述する。URLアドレス指定可能なピースは、記憶と再訪のアフォーダンスを提供する：\texttt{notepat}という名前は単なる識別子ではなくニーモニック——実践へと戻るパスである。AC名前空間はニーモニックな風景である。\texttt{wrl}、\texttt{grid}、\texttt{clock}、\texttt{prompt}を知るユーザーは、可能な体験の地図を内面化している。これが音楽のカノンの働き方である：作品の名前は実践へのハンドルであり、単なるファイルのラベルではない。
218
+
219
+
\section{ピース vs.\ プログラム：比較}
220
+
221
+
\begin{table}[h]
222
+
\small
223
+
\centering
224
+
\begin{tabularx}{\columnwidth}{l X X}
225
+
\toprule
226
+
& \textbf{プログラム} & \textbf{ピース} \\
227
+
\midrule
228
+
評価の単位 & 正確性 & 表現 \\
229
+
主要ライフサイクル & コンパイル、実行、終了 & 起動、演奏、退出 \\
230
+
著者性 & 所有者（ユーザー/root） & アーティスト \\
231
+
社会的単位 & 実行可能バイナリ & 名前付きURL \\
232
+
反復モード & デバッグ、再デプロイ & 修正、再公開 \\
233
+
時間との関係 & 終了 & 継続 \\
234
+
フォークの比喩 & Fork（git） & カバー（音楽） \\
235
+
完成条件 & テスト通過 & 決してない（放棄されるのみ） \\
236
+
\bottomrule
237
+
\end{tabularx}
238
+
\caption{プログラム vs.\ ピース——創造的単位としての比較。}
239
+
\label{tab:comparison}
240
+
\end{table}
241
+
242
+
\section{プラットフォーム設計への影響}
243
+
244
+
ピースの概念は\ac{} に具体的なデザイン上の帰結をもたらす：
245
+
246
+
\begin{enumerate}
247
+
\item \textbf{一ファイル、一ピース。} プロジェクト構造もビルドシステムも、プラットフォームAPI以外の依存関係もない。ピースは自己完結している——音楽作品が自己完結しているように。
248
+
\item \textbf{プロンプトは楽器である。} ACコマンドプロンプトは、ピースをブラウズし、演奏し、公開するためのインターフェースである。GUIのように設定可能ではなく、キーボード配列のように記憶可能であるよう設計されている。
249
+
\item \textbf{公開は演奏である。} \texttt{publish}を実行することはデプロイ行為ではなく、創造行為である。ピースは即座に名前空間に入り、URLを持つ誰もが演奏できる。
250
+
\item \textbf{ブラウザはコンサートホールである。} ウェブブラウザ~\citep{wyse2013viability}は演奏空間である。すべてのデバイスに既に存在し、既に社会的である。ピースがブラウザで動作するのは技術的に最適だからではなく、現存する最もアクセスしやすい演奏会場だからである。
251
+
\item \textbf{ライブコーディングはリハーサルである。} モジュールローダーは保存時にピースをホットリロードする。これは開発者の利便性ではない——拍子の中で練習することに等しい：著者はピースが変化するのと同時にそれを演奏し、後からではない。
252
+
\end{enumerate}
253
+
254
+
\section{結論}
255
+
256
+
インタラクティブプログラムを\emph{ピース}と呼ぶことはデザイン宣言である：クリエイティブソフトウェアを考える正しい枠組みは、工学の枠組み（正確性、デプロイ、保守）ではなく芸術の枠組み（著者性、反復、演奏、実践）であると断言する。Processingスケッチは2001年に同様の宣言を行った。Maxのパッチは1988年に行った。ACのピースは2024年に、ブラウザの中で、URL名前空間とともに、再びそれを行う。
257
+
258
+
それぞれの再枠組み付けは異なるアフォーダンスをもたらす。ACにおけるピースの概念が際立たせるのは：インストール可能なアプリよりも記憶可能なURL、保持されたシーングラフよりも即時モード描画、イベントリスナーよりもライフサイクル関数、フォークよりもカバー。これらは単なる命名の選択ではない——\citet{magnusson2010designing}が論じるように、限定することによって可能にする制約である。
259
+
260
+
より深い宣言は、ピースの概念を中心にデザインされたソフトウェアが\emph{実践}をユーザーとプログラムの根本的な関係として扱うということである。インストールではなく、設定ではなく、デプロイではなく——実践。ピースとは、あなたが戻ってきて、精緻化し、演奏するものである。認知を拡張する~\citep{clark1998extended}のは、まさに学ぶのに十分なほど安定し、成長するのに十分なほど柔軟だからである。
261
+
262
+
\bibliographystyle{plainnat}
263
+
\bibliography{references}
264
+
265
+
\end{document}
+1
-1
papers/arxiv-plork/plork-cards.tex
+1
-1
papers/arxiv-plork/plork-cards.tex
···
86
86
\vspace{0.15em}
87
87
\colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par
88
88
\vspace{0.1em}
89
-
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/6fd9fced2}{6fd9fced2}}\par
89
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/2113ef735}{2113ef735}}\par
90
90
\vspace{0.1em}
91
91
{\footnotesize\color{acgray}\href{https://papers.aesthetic.computer/plorking-the-planet-26-arxiv-da-cards.pdf}{Dansk} · \href{https://papers.aesthetic.computer/plorking-the-planet-26-arxiv-es-cards.pdf}{Español} · \href{https://papers.aesthetic.computer/plorking-the-planet-26-arxiv-zh-cards.pdf}{{\accjk 中文}} · \href{https://papers.aesthetic.computer/plorking-the-planet-26-arxiv-ja-cards.pdf}{{\accjk 日本語}}}\par
92
92
\end{center}
+11
-9
papers/arxiv-score-analysis/score-analysis-cards.tex
+11
-9
papers/arxiv-score-analysis/score-analysis-cards.tex
···
38
38
\thispagestyle{empty}
39
39
\vspace*{\fill}
40
40
\begin{center}
41
-
\includegraphics[height=8em]{pals}\par\vspace{0.3em}
42
-
{\acbold\fontsize{20pt}{24pt}\selectfont\color{acdark} Reading the Score}\par
41
+
\includegraphics[height=9em]{pals}\par\vspace{0.1em}
42
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} Reading the Score}\par
43
+
\vspace{0.1em}
43
44
\vspace{0.3em}
44
-
\vspace{0.5em}
45
-
{\normalsize\color{cyan!70!blue}\textbf{@jeffrey}}\par
45
+
{\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par
46
46
{\small\color{acgray} Aesthetic.Computer}\par
47
47
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
48
-
\vspace{0.8em}
49
-
\rule{0.6\textwidth}{1pt}\par
50
48
\vspace{0.4em}
51
-
{\small\color{acpink!40}\textit{working draft --- not for citation}}\par
52
-
\vspace{0.3em}
53
-
{\footnotesize\color{acgray} March 2026}\par
49
+
\rule{0.5\textwidth}{0.5pt}\par
50
+
\vspace{0.15em}
51
+
\colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par
52
+
\vspace{0.1em}
53
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/2113ef735}{2113ef735}}\par
54
+
\vspace{0.1em}
55
+
{\footnotesize\color{acgray}\href{https://papers.aesthetic.computer/reading-the-score-26-arxiv-da-cards.pdf}{Dansk} · \href{https://papers.aesthetic.computer/reading-the-score-26-arxiv-es-cards.pdf}{Español} · \href{https://papers.aesthetic.computer/reading-the-score-26-arxiv-zh-cards.pdf}{{\accjk 中文}} · \href{https://papers.aesthetic.computer/reading-the-score-26-arxiv-ja-cards.pdf}{{\accjk 日本語}}}\par
54
56
\end{center}
55
57
\vspace*{\fill}
56
58
+261
papers/arxiv-score-analysis/score-analysis-ja.tex
+261
papers/arxiv-score-analysis/score-analysis-ja.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
% === GEOMETRY ===
5
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
6
+
7
+
% === FONTS ===
8
+
\usepackage{fontspec}
9
+
\usepackage{unicode-math}
10
+
\usepackage{xeCJK}
11
+
\setCJKmainfont{Droid Sans Japanese}
12
+
\setmainfont{Latin Modern Roman}
13
+
\setsansfont{Latin Modern Sans}
14
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
15
+
\newfontfamily\acbold{ywft-processing-bold}[
16
+
Path=../../system/public/type/webfonts/,
17
+
Extension=.ttf
18
+
]
19
+
\newfontfamily\aclight{ywft-processing-light}[
20
+
Path=../../system/public/type/webfonts/,
21
+
Extension=.ttf
22
+
]
23
+
24
+
% === PACKAGES ===
25
+
\usepackage{xcolor}
26
+
\usepackage{titlesec}
27
+
\usepackage{enumitem}
28
+
\usepackage{booktabs}
29
+
\usepackage{tabularx}
30
+
\usepackage{fancyhdr}
31
+
\usepackage{hyperref}
32
+
\usepackage{graphicx}
33
+
\usepackage{ragged2e}
34
+
\usepackage{microtype}
35
+
\usepackage{natbib}
36
+
\usepackage[colorspec=0.92]{draftwatermark}
37
+
38
+
% === COLORS ===
39
+
\definecolor{acpink}{RGB}{180,72,135}
40
+
\definecolor{acpurple}{RGB}{120,80,180}
41
+
\definecolor{acdark}{RGB}{64,56,74}
42
+
\definecolor{acgray}{RGB}{119,119,119}
43
+
\definecolor{draftcolor}{RGB}{180,72,135}
44
+
45
+
% === DRAFT WATERMARK ===
46
+
\DraftwatermarkOptions{
47
+
text=WORKING DRAFT,
48
+
fontsize=3cm,
49
+
color=draftcolor!18,
50
+
angle=45,
51
+
pos={0.5\paperwidth, 0.5\paperheight}
52
+
}
53
+
54
+
% === HYPERREF ===
55
+
\hypersetup{
56
+
colorlinks=true,
57
+
linkcolor=acpurple,
58
+
urlcolor=acpurple,
59
+
citecolor=acpurple,
60
+
pdfauthor={@jeffrey},
61
+
pdftitle={スコアを読む},
62
+
}
63
+
64
+
% === SECTION FORMATTING ===
65
+
\titleformat{\section}
66
+
{\normalfont\bfseries\normalsize\uppercase}
67
+
{\thesection.}
68
+
{0.5em}
69
+
{}
70
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
71
+
72
+
\titleformat{\subsection}
73
+
{\normalfont\bfseries\small}
74
+
{\thesubsection}
75
+
{0.5em}
76
+
{}
77
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
78
+
79
+
% === HEADER/FOOTER ===
80
+
\pagestyle{fancy}
81
+
\fancyhf{}
82
+
\renewcommand{\headrulewidth}{0pt}
83
+
\fancyhead[C]{\footnotesize\color{draftcolor}\textit{作業草稿 --- 引用不可}}
84
+
\fancyfoot[C]{\footnotesize\thepage}
85
+
86
+
% === LIST SETTINGS ===
87
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
88
+
\setlist[enumerate]{nosep, leftmargin=1.2em}
89
+
90
+
% === COLUMN SEPARATION ===
91
+
\setlength{\columnsep}{1.8em}
92
+
93
+
% === PARAGRAPH SETTINGS ===
94
+
\setlength{\parindent}{1em}
95
+
\setlength{\parskip}{0.3em}
96
+
97
+
% Hyphenation for narrow two-column layout
98
+
\tolerance=800
99
+
\emergencystretch=1em
100
+
\hyphenpenalty=50
101
+
102
+
\begin{document}
103
+
104
+
% === TITLE ===
105
+
\twocolumn[
106
+
\begin{center}
107
+
{\acbold\LARGE スコアを読む：SCORE.mdのガバナンス、インターフェース、\\および創作形式としての批判的分析\par}
108
+
\vspace{0.4em}
109
+
{\large @jeffrey}\\
110
+
{\small\color{acgray} ORCID: 0009-0007-4460-4913}\\
111
+
{\small\color{acgray} \url{https://aesthetic.computer}}
112
+
\vspace{0.3em}
113
+
114
+
\rule{0.6\textwidth}{0.5pt}
115
+
\vspace{0.3em}
116
+
117
+
\begin{minipage}{0.85\textwidth}
118
+
\small
119
+
\textbf{要旨。}
120
+
Aesthetic Computerプロジェクトは、そのREADMEをSCORE.mdという名前の文書に置き換えた。
121
+
本論文はこの改名が何をもたらしたか——そして何を未完のまま残したかを検証する。
122
+
プロジェクトのリサーチディスクから執筆された15本の論文に基づき、スコアをその自らの志と照合して読む：
123
+
ガバナンス文書として、技術リファレンスとして、創作形式として。スコアは組織的メタファーとしては成功しているが、
124
+
ドキュメントとしては苦戦していることが明らかになった——AIエージェント、新しいコントリビューター、プロジェクト自身の歴史、
125
+
そして著者の創作実践という複数の需要に引き裂かれて。現在のスコアにおける6つの緊張関係を特定し、
126
+
音楽的メタファーを真剣に受け止める改訂フレームワークを提案する：スコアは楽器の一覧ではなく、
127
+
演奏の仕方を伝えるべきである。
128
+
\end{minipage}
129
+
\vspace{1em}
130
+
\end{center}
131
+
]
132
+
133
+
\section{スコアとは何か？}
134
+
135
+
音楽において、スコアとは時間的事象を生成するための指示の集合である。事象そのものではなく——事象を再現可能にする文書である。スコアには何が重要かについての暗黙の理論が内包されている：どのパラメータを明示的に指定すべきか、どれを演奏者の判断に委ねるか。
136
+
137
+
Aesthetic Computerプロジェクトが2026年3月初旬にREADME.mdをSCORE.mdに改名した時、それはこのフレームワーク全体を導入した。この行為は意図的だった。プロジェクトは既にそのプログラムをアプリケーションではなく「ピース」として~\citep{scudder2026pieces}、そのインターフェースを楽器として~\citep{scudder2026notepat}、そのグラフィック記譜法（Whistlegraph）をバイラルなスコアとして~\citep{scudder2026whistlegraph}理解していた。ガバナンス文書の改名は一つの表明だった：これもまた、演奏されるべきものである。
138
+
139
+
しかしスコアには演奏者が必要である。本論文が提起する問いは：誰がSCORE.mdから演奏しているのか、そしてこの文書は本当に彼らの助けになっているのか？
140
+
141
+
\section{リサーチディスクとスコア}
142
+
143
+
Aesthetic Computerのリサーチディスクは現在17本の論文を含み、自動ビルド、4言語翻訳、実物配布用のカード形式を備えた論文工房で組織されている~\citep{scudder2026cards}。これらの論文を通読すると、相当な野心と内的一貫性を持つプロジェクトが浮かび上がる——しかし同時に、自己記述（スコア）が自己理解（論文）に追いついていないプロジェクトでもある。
144
+
145
+
論文はスコアが語っていない物語を語る。以下を考えてみよう：
146
+
147
+
\begin{itemize}
148
+
\item 「Pieces Not Programs」論文~\citep{scudder2026pieces}は、「ピース」という語が、作品が著者を持ち、演奏可能で、反復的に改良されるという音楽的フレームワークを導入すると論じる。スコアはピースに言及しているが、このフレームワークを説明することはない。
149
+
\item notepat論文~\citep{scudder2026notepat}は、一つのピースがプラットフォーム全体を存在へと引き込んだ5つのフィードバックループを記録する。スコアはnotepatを359のピースの一つとして挙げている。
150
+
\item 持続可能性論文~\citep{scudder2026sustainability}は、ツール制作と持続可能な資金との間に中央値8年のギャップがあり、ケーススタディが障害と死に至ることを確認する。スコアにはスポンサーバッジがある。
151
+
\item Native OS論文~\citep{scudder2026os}は、50ドルの中古x86\_64ラップトップがグローバルな創造的楽器の物質的基盤であると論じる。スコアにはビルドコマンドが列挙されている。
152
+
\item KidLisp Cards論文~\citep{scudder2026cards}は、プログラムの簡潔さが新しい出版形式——実行可能なスコアとしてのカード——を生み出したことを実証する。スコアにはカードについての記載がない。
153
+
\end{itemize}
154
+
155
+
いずれの場合も、論文はスコアが単にカタログ化しているものに意味を与える議論を展開している。スコアには事実はあるが、論証がない。
156
+
157
+
\section{6つの緊張関係}
158
+
159
+
スコアを論文と照合して読むと、改訂が対処すべき6つの緊張関係が浮き彫りになる。
160
+
161
+
\subsection{読者の混乱}
162
+
163
+
スコアはAIエージェントへのメッセージ（「If you find something interesting\ldots leave a breadcrumb」）で始まり、すぐに人間向けのガイダンス（「press the top left of the screen」）に切り替わる。「Front Door」セクションはエンドユーザー向け。「Back Door」セクションは開発者向け。「Ant Guidance」セクションは自動化エージェント向け。「Embodiments」セクションはこの三者の調和を試みる。
164
+
165
+
これは間違いではない——スコアは複数の演奏者に向けることができる。しかし音楽のスコアは演奏者のパートを一目で分かるようにしている。SCORE.mdは、どのセクションが自分向けかを読者自身に判断させる。指揮者スコアとバイオリンパートが別の文書であるのには十分な理由がある。
166
+
167
+
\subsection{カタログと論証}
168
+
169
+
スコアはカタログとして組織されている：アーキテクチャ、コマンド、エンドポイント、TODO、マーケットクエリ。有用なリファレンスではあるが、プロジェクトが\emph{なぜ}存在するのか、どのような原則がその発展を支配するのかについては何も伝えない。
170
+
171
+
論文群は少なくとも5つのコア議論を共同で展開している：
172
+
\begin{enumerate}
173
+
\item クリエイティブソフトウェアはツールではなく楽器としてデザインされるべきである~\citep{scudder2026goodiepal}。
174
+
\item 「ピース」はプログラムではなく、創造的認知の単位である~\citep{scudder2026pieces}。
175
+
\item 制約（言語設計において、フォームファクターにおいて）は制限的ではなく、生成的である~\citep{scudder2026kidlisp, scudder2026cards}。
176
+
\item 中古ハードウェア＋カスタムOS＝グローバルなアクセス~\citep{scudder2026os, scudder2026plork}。
177
+
\item クリエイティブツールには、その創造者を殺さない経済モデルが必要である~\citep{scudder2026sustainability}。
178
+
\end{enumerate}
179
+
180
+
これらの議論はどれもスコアに現れていない。SCORE.mdの初めての読者は、Aesthetic Computerが\emph{何であるか}（ピースとプロンプトといくつかのサーバーを持つランタイム）を知るが、\emph{なぜ}存在するのか、何を信じているのかは知ることができない。
181
+
182
+
\subsection{TODOの問題}
183
+
184
+
スコアには「AC Native Backlog」セクションがあり、完了したタスク（「Claude native binary」）と理想的な機能（「A/B kernel slots with auto-rollback」）が7項目混在している。これはプロジェクト管理のアーティファクトであり、スコアではない。戦略的方向ではなく戦術的状態を伝えている。
185
+
186
+
アント哲学（\texttt{ants/mindset-and-rules.md}）は投機的作業を明確に警告している：「IDLE is valid---wandering is the job, not failure。」しかしスコアのTODOはまさに投機的作業であり、プロジェクトの計画であるかのように提示されている。サブスコア（fedac/native/SCORE.md、papers/SCORE.md）はガイダンスとタスクリストを分離することで、この問題をより適切に処理している。
187
+
188
+
\subsection{Keepsマーケットブロック}
189
+
190
+
スコアは90行を使ってTezos/Objkt GraphQLクエリを示し、Keeps NFTマーケット統計をチェックしている。これはコントリビューター（著者）の運用ツールである。有用なリファレンスではあるが、スコアの後半を支配し、意図しないシグナルを発している：NFTマーケット監視がプロジェクトの中心的関心事であり、アーキテクチャや開発ワークフローと同等に重要であるという。
191
+
192
+
「Dead Ends」論文~\citep{scudder2026deadends}は、Tezos/Keepsを将来が不確かなマネタイゼーション実験として明確に分類している。スコアはそれを確立されたインフラとして提示している。
193
+
194
+
\subsection{欠けた声}
195
+
196
+
「Network Audit」論文~\citep{scudder2026audit}は、ACに2,811の登録ユーザー名があるが、KidLispを書いているのは2.1\%、ピースを公開しているのは0.7\%にすぎないことを明らかにしている。「Diversity」論文~\citep{scudder2026diversity}は、被引用著者の80\%が西洋の男性であることを認めている。「Sustainability」論文~\citep{scudder2026sustainability}は、支援のないツール制作の人的コストを記録している。
197
+
198
+
スコアはこれらの問題のいずれにも触れていない。採用データ（「2812 registered handles, 265 user-published pieces」）を、解釈すべきデータではなく成果として提示している。論文はスコアよりも正直である。
199
+
200
+
\subsection{サブスコアとメインスコア}
201
+
202
+
プロジェクトには現在6つのSCORE.mdファイルがある：ルート、papers、fedac、fedac/native、opinion、vault。サブスコアは一般的にメインスコアよりも優れた文書である。papersスコアは「Mill Mission」で始まり、\emph{なぜ}存在するかを説明する。nativeスコアは5つの検証可能な基準で「shipped」を定義する。vaultスコアはセキュリティ態勢をマッピングする。
203
+
204
+
一方、メインスコアはすべてになろうとしている：README、アーキテクチャ文書、開発者ガイド、運用マニュアル、NFTダッシュボード。サブスコアは具体的であるがゆえに成功している。メインスコアは包括的であるがゆえに苦戦している。
205
+
206
+
\section{スコアのメタファーを真剣に受け止める}
207
+
208
+
SCORE.mdがスコアだとすれば、それはどのようなスコアであるべきか？音楽のアナロジーはいくつかの属性を示唆する：
209
+
210
+
\textbf{スコアは始め方を教える。}現在のスコアの「Front Door」はエンドユーザーに対してこれを実現しているが、コントリビューターやエージェントに対しては実現していない。スコアを手に取った演奏者は知る必要がある：何の楽器を演奏するのか？どこから入るのか？テンポは何か？
211
+
212
+
\textbf{スコアにはパートがある。}異なる演奏者は異なるパートを読む。現在のスコアはすべてのパートを一つの文書に混在させている。サブスコアは実質的に抽出された個別のパートである。メインスコアは指揮者スコアであるべきだ：すべてのパートの合集ではなく、パートを指し示す概要。
213
+
214
+
\textbf{スコアは演奏実践を前提とする。}スコアの読み方と実行の仕方に関する慣行は、スコア自体には書かれていない。アント思考文書はAIエージェントに対してこの機能を果たしている。人間のコントリビューターに対する同等のものは存在しない。
215
+
216
+
\textbf{スコアは改訂できる。}スコアにはバージョンがある。現在のSCORE.mdには文書自体にバージョン履歴や変更ログがない。まるで常にこうだったかのように読めるが、実際には2週間前まではREADMEだった。
217
+
218
+
\textbf{スコアは演奏そのものではない。}スコアはプロジェクト全体を含もうとすべきではない。プロジェクトが演奏される際に必要な最小限の文書であるべきだ。それ以外のすべて——TODO、マーケットクエリ、運用ツール——はパートまたは付録に属する。
219
+
220
+
\section{論文が知っていてスコアが知らないこと}
221
+
222
+
17本すべての論文をスコアと照合して読んだとき、最も際立つ発見は、プロジェクトの自己理解が論文の中ではスコアの中よりもはるかに豊かであることだ。論文には以下が含まれている：
223
+
224
+
\begin{itemize}
225
+
\item 創造的認知の理論（知覚-行動循環としてのピース）
226
+
\item ツール制作の政治経済学（誰が支払い、誰が燃え尽き、誰が死ぬか）
227
+
\item デザイン哲学（楽器優先、制約は生成的、深さよりもフラット）
228
+
\item ハードウェアに関する物質的議論（グローバルな楽器としての中古ラップトップ）
229
+
\item 失敗の正直な監査（16の行き止まり、50\%の貢献率）
230
+
\item 具体的目標を持つ引用多様性へのコミットメント
231
+
\item 独自のミッションステートメントを持つ出版インフラ（工房）
232
+
\end{itemize}
233
+
234
+
スコアにはこれらのいずれも含まれていない。たまたまスコアと呼ばれている技術文書である。改訂は、真のスコアにすべきだ：プロジェクトのアーキテクチャだけでなく、その論証を載せた文書。
235
+
236
+
\section{改訂されたスコアに向けて}
237
+
238
+
改訂後のSCORE.mdは以下を行うべきである：
239
+
240
+
\begin{enumerate}
241
+
\item \textbf{「なぜ」から始める。}プロジェクトが何を信じ、なぜ存在するかを、論文群で展開された議論から引いて述べる。papers/SCORE.mdのmill missionはこの好例である。
242
+
\item \textbf{パートと指揮者スコアを分離する。}運用の詳細（Keepsクエリ、TODO、コマンドリファレンス）をサブスコアまたは付録に移す。メインスコアは5分で読めるべきである。
243
+
\item \textbf{読者を名指しする。}三種類の演奏者（エンドユーザー、人間のコントリビューター、AIエージェント）を明示的に対象とし、それぞれに明確なエントリーポイントを提供する。
244
+
\item \textbf{正直な数字を含める。}解釈付きの採用データを提示し、単なるバッジではなく。KidLisp制作率2.1\%は意味のある事実であり、スコアはそれが何を意味するかを述べるべきである。
245
+
\item \textbf{論文を参照する。}リサーチディスクは存在する。スコアはそれを無視するのではなく、プロジェクトの拡張された自己理解として指し示すべきである。
246
+
\item \textbf{自らの歴史を認める。}この文書が2026年3月までREADMEであったこと、そして改名自体が帰結を持つ創造的行為であることを述べる。
247
+
\item \textbf{より短くする。}現在のスコアは361行。自らを真剣に受け止めるスコアは、カード上の一つのピースの長さにより近くあるべきだ。
248
+
\end{enumerate}
249
+
250
+
\section{結論}
251
+
252
+
SCORE.mdはAesthetic Computerプロジェクトが必要とするものにとって良い名前である：プロジェクトを演奏可能にする文書。しかし現在のスコアはカタログであり、作品ではない。プロジェクトが何を含んでいるかを列挙するが、何を意味するかを論じていない。リサーチディスクの論文群——スコアと同じ数週間で書かれた——には、スコアに欠けている論証、正直な評価、創作のフレームワークが含まれている。
253
+
254
+
最も生産的な改訂は、スコアに内容を追加することではなく、削減することだろう——運用の詳細をサブスコアに移し、プロジェクトの実際の信念に置き換える。サブスコア（papers、native、vault）は既にこのアプローチを示している。メインスコアは自らのパートから学ぶべきである。
255
+
256
+
スコアはオーケストラの記述ではない。音楽を生み出すために必要な最小限の記譜である。SCORE.mdも同じ簡潔さを目指すべきだ。
257
+
258
+
\bibliographystyle{plainnat}
259
+
\bibliography{references}
260
+
261
+
\end{document}
+13
-11
papers/arxiv-sustainability/sustainability-cards.tex
+13
-11
papers/arxiv-sustainability/sustainability-cards.tex
···
38
38
\thispagestyle{empty}
39
39
\vspace*{\fill}
40
40
\begin{center}
41
-
\includegraphics[height=8em]{pals}\par\vspace{0.3em}
42
-
{\acbold\fontsize{20pt}{24pt}\selectfont\color{acdark} Who Pays for Creative Tools?}\par
43
-
\vspace{0.3em}
44
-
{\fontsize{10pt}{12pt}\selectfont\color{acpink} Funding, Burnout, and Survival in Open-Source Creative Computing}\par
45
-
\vspace{0.8em}
46
-
{\normalsize\color{cyan!70!blue}\textbf{@jeffrey}}\par
41
+
\includegraphics[height=9em]{pals}\par\vspace{0.1em}
42
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} Who Pays for Creative Tools?}\par
43
+
\vspace{0.1em}
44
+
{\fontsize{9pt}{11pt}\selectfont\color{acpink} Funding, Burnout, and Survival in Open-Source Creative Computing}\par
45
+
\vspace{0.4em}
46
+
{\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par
47
47
{\small\color{acgray} Aesthetic.Computer}\par
48
48
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
49
-
\vspace{0.8em}
50
-
\rule{0.6\textwidth}{1pt}\par
51
49
\vspace{0.4em}
52
-
{\small\color{acpink!40}\textit{working draft --- not for citation}}\par
53
-
\vspace{0.3em}
54
-
{\footnotesize\color{acgray} March 2026}\par
50
+
\rule{0.5\textwidth}{0.5pt}\par
51
+
\vspace{0.15em}
52
+
\colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par
53
+
\vspace{0.1em}
54
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/2113ef735}{2113ef735}}\par
55
+
\vspace{0.1em}
56
+
{\footnotesize\color{acgray}\href{https://papers.aesthetic.computer/who-pays-for-creative-tools-26-arxiv-da-cards.pdf}{Dansk} · \href{https://papers.aesthetic.computer/who-pays-for-creative-tools-26-arxiv-es-cards.pdf}{Español} · \href{https://papers.aesthetic.computer/who-pays-for-creative-tools-26-arxiv-zh-cards.pdf}{{\accjk 中文}} · \href{https://papers.aesthetic.computer/who-pays-for-creative-tools-26-arxiv-ja-cards.pdf}{{\accjk 日本語}}}\par
55
57
\end{center}
56
58
\vspace*{\fill}
57
59
+285
papers/arxiv-sustainability/sustainability-ja.tex
+285
papers/arxiv-sustainability/sustainability-ja.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
5
+
\usepackage{fontspec}
6
+
\usepackage{unicode-math}
7
+
\setmainfont{Latin Modern Roman}
8
+
\setsansfont{Latin Modern Sans}
9
+
\newfontfamily\acbold{ywft-processing-bold}[Path=../../system/public/type/webfonts/,Extension=.ttf]
10
+
\newfontfamily\aclight{ywft-processing-light}[Path=../../system/public/type/webfonts/,Extension=.ttf]
11
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
12
+
13
+
\usepackage{xeCJK}
14
+
\setCJKmainfont{Droid Sans Japanese}
15
+
\setCJKsansfont{Droid Sans Japanese}
16
+
\setCJKmonofont{Droid Sans Japanese}
17
+
18
+
\usepackage{xcolor}
19
+
\usepackage{titlesec}
20
+
\usepackage{enumitem}
21
+
\usepackage{booktabs}
22
+
\usepackage{tabularx}
23
+
\usepackage{fancyhdr}
24
+
\usepackage{hyperref}
25
+
\usepackage{graphicx}
26
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
27
+
\usepackage{ragged2e}
28
+
\usepackage{microtype}
29
+
\usepackage{natbib}
30
+
\usepackage[colorspec=0.92]{draftwatermark}
31
+
32
+
\definecolor{acpink}{RGB}{180,72,135}
33
+
\definecolor{acpurple}{RGB}{120,80,180}
34
+
\definecolor{acdark}{RGB}{64,56,74}
35
+
\definecolor{acgray}{RGB}{119,119,119}
36
+
\definecolor{draftcolor}{RGB}{180,72,135}
37
+
38
+
\DraftwatermarkOptions{text=WORKING DRAFT,fontsize=3cm,color=draftcolor!18,angle=45}
39
+
40
+
\hypersetup{colorlinks=true,linkcolor=acpurple,urlcolor=acpurple,citecolor=acpurple,
41
+
pdftitle={誰がクリエイティブツールの代金を払うのか？}}
42
+
43
+
\titleformat{\section}{\normalfont\bfseries\normalsize\uppercase}{\thesection.}{0.5em}{}
44
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
45
+
\titleformat{\subsection}{\normalfont\bfseries\small}{\thesubsection}{0.5em}{}
46
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
47
+
48
+
\pagestyle{fancy}\fancyhf{}
49
+
\renewcommand{\headrulewidth}{0pt}
50
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{作業草稿——引用不可}}
51
+
\fancyfoot[C]{\footnotesize\thepage}
52
+
53
+
\newcommand{\ac}{\textsc{Aesthetic.Computer}}
54
+
55
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
56
+
\setlength{\columnsep}{1.8em}
57
+
\setlength{\parindent}{1em}
58
+
\setlength{\parskip}{0.3em}
59
+
60
+
% Hyphenation for narrow two-column layout
61
+
\tolerance=800
62
+
\emergencystretch=1em
63
+
\hyphenpenalty=50
64
+
65
+
\begin{document}
66
+
67
+
\twocolumn[{%
68
+
\begin{center}
69
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
70
+
{\acbold\fontsize{22pt}{26pt}\selectfont\color{acdark} 誰がクリエイティブツールの代金を払うのか？}\par
71
+
\vspace{0.2em}
72
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} オープンソース・クリエイティブコンピューティングにおける資金、燃え尽き、そして生存}\par
73
+
\vspace{0.3em}
74
+
{\aclight\fontsize{9pt}{11pt}\selectfont\color{acgray} PerlからTempleOSからAesthetic Computerまで——28人のツール作者の比較研究}\par
75
+
\vspace{0.6em}
76
+
{\normalsize @jeffrey}\par
77
+
{\small\color{acgray} Aesthetic.Computer}\par
78
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
79
+
\vspace{0.3em}
80
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
81
+
\vspace{0.6em}
82
+
\rule{\textwidth}{1.5pt}
83
+
\vspace{0.5em}
84
+
\end{center}
85
+
86
+
\begin{center}
87
+
{\small\color{acpink}\textbf{[ 作業草稿——引用不可 ]}}
88
+
\end{center}
89
+
\vspace{0.3em}
90
+
91
+
\begin{quote}
92
+
\small\noindent\textbf{要旨。}
93
+
クリエイティブコンピューティングのツール——Processing、p5.js、Sonic Pi、Pure Data、Hydra、TidalCycles、openFrameworks、Scratchおよび同種のもの——は数百万人に使用されている。その創造者たちは通常、誰からも報酬を受けていないか、ツールとは無関係な要因を条件とする機関によって報酬を受けている。本論文は28人のオープンソース・クリエイティブツール作者の資金履歴を調査し、6つの持続可能性パターンを特定する：\emph{アカデミック補助金}（大学の給与が無報酬のツール作業を資金的に支える）、\emph{企業スポンサーシップ}（企業が利益の一致に対して支払う）、\emph{個人の犠牲}（貯蓄、退職金、健康）、\emph{コミュニティクラウドファンディング}（Patreon、Open Collective、Ko-fi）、\emph{棚ぼた}（NFT寄付のような予測不可能な一度きりの出来事）、そして\emph{パターンなし}（障害手当金、ホームレス、死）。ツール制作から最初の持続可能な資金までの中央値は8年であること、資金水準に関係なく燃え尽きが制作者に影響を与えること、そして最も広く使用されているツールが最も十分に資金を得ているわけではないことが明らかになった。これらの知見を、著者自身の\ac{}~\citep{scudder2026ac}構築経験——2,800人以上の登録ユーザー、93,000回以上のセッション、16,000以上のコミュニティ制作プログラムを持つプラットフォームを、この分野のすべての比較可能なツールが享受してきた機関の傘なしに5年間開発してきた経験——と照合する。クリエイティブコンピューティング分野の暗黙の補助金——大学から、配偶者から、貯蓄口座から、健康から——への依存は資金モデルではなく、資金モデルの不在であると論じる。
94
+
\end{quote}
95
+
\vspace{0.5em}
96
+
}]
97
+
98
+
\section{序論}
99
+
100
+
Lauren McCarthyは2013年にp5.jsを制作し、その後10年間、UCLAの教職の傍ら週に10〜20時間を無報酬でメンテナンスに費やした~\citep{mccarthy2023making}。Rich Hickeyは誰かが対価を払う前に2.5年分の退職貯蓄をClojureの構築に費やした~\citep{hickey2020history}。Samuel Aaronは2019年にCambridgeから解雇され、「100\%財務的生存に集中」せざるを得なくなり、Sonic Piの開発は「蝸牛の速度」に低下した~\citep{aaron2016sonic}。\_why the lucky stiff——Rubyで最も愛されたコントリビューターの一人——は身元を暴かれた後、デジタル上の全存在を削除し、彼の仕事に対して一銭も受け取ることはなかった。
101
+
102
+
Terry A. Davisは14.7年かけてTempleOSを構築した——カスタムプログラミング言語、コンパイラ、カーネル、エディタ、ゲームを含む完全な64ビットオペレーティングシステム——121,176行のコード、完全に一人で、社会保障障害手当金で資金を賄い、両親の家に住んでいた。2017年にその住居を失った後、彼はバンの中で暮らした。2018年8月11日、Oregon州The Dallesで列車に轢かれて死亡した。48歳だった。彼が構築したシステムはXerox AltoやPlan 9と比較された。その創造者はホームレスの状態で死んだ。
103
+
104
+
これらは周辺的なケースではない。オープンソース・クリエイティブツール開発の通常の状態である。ツールは機能する。その創造者たちは、しばしば機能しない。
105
+
106
+
本論文は、Larry Wallによる1987年のPerl制作から著者の進行中の\ac{}~\citep{scudder2026ac}開発まで、40年にわたる28人のクリエイティブツール作者を調査する。各作者について以下を特定する：誰が仕事に対して支払ったか、支払いは制作に対していつ開始されたか、制作者は何を犠牲にしたか、そして資金の取り決めが継続したかどうか。結果は持続可能性パターンの分類体系——およびその失敗の記録である。
107
+
108
+
\section{5つのパターン}
109
+
110
+
\subsection{アカデミック補助金}
111
+
112
+
クリエイティブコンピューティングツールの最も一般的な資金パターンは、実際には資金パターンではない：教育と研究に対して支払われる大学の給与であり、ツール開発は「サービス」や「創作実践」に分類される無報酬労働として行われる。
113
+
114
+
\begin{table}[h]
115
+
\small
116
+
\centering
117
+
\begin{tabularx}{\columnwidth}{Xlr}
118
+
\toprule
119
+
\textbf{制作者} & \textbf{機関} & \textbf{年数} \\
120
+
\midrule
121
+
Miller Puckette & UCSD & 30+ \\
122
+
Casey Reas & UCLA & 15+ \\
123
+
Lauren McCarthy & UCLA & 10+ \\
124
+
Ge Wang & Stanford & 17+ \\
125
+
Thor Magnusson & Sussex/Iceland & 20+ \\
126
+
Dan Shiffman & NYU ITP & 15+ \\
127
+
Olia Lialina & Merz Akademie & 25+ \\
128
+
Hernando Barrag\'an & U. de Los Andes & 20+ \\
129
+
John Maeda & MIT Media Lab & 12 \\
130
+
\bottomrule
131
+
\end{tabularx}
132
+
\caption{クリエイティブツール開発を資金的に支えるアカデミックポジション。}
133
+
\label{tab:academic}
134
+
\end{table}
135
+
136
+
補助金は実在するが隠されている。McCarthyの週10〜20時間の無報酬p5.jsメンテナンスが可能なのは、UCLAが彼女のその他の仕事に給与を支払っているからである。PucketteはMax/MSPの商業ライセンスの支配権を失った後にPure Dataを制作した；UCSDの教職が再構築を資金的に支えた。WangのChucKが存在するのは、Stanford CCRMAが研究のために支払っているからである。いずれの場合も、ツールはアカデミックキャリアの副産物であり、その目的ではなかった。
137
+
138
+
このパターンには重要な脆弱性がある：アカデミックポジションが終わると、ツールは飢える。Aaronの2019年のCambridgeからの解雇が最も明確なケースである——大学がサポートを撤回した後、Sonic Piの開発は崩壊した。MaedaのMIT離職は事実上Design By Numbersを殺した；Processingが生き延びたのは、彼の学生がそれを独立させたからにすぎない。
139
+
140
+
\subsection{企業スポンサーシップ}
141
+
142
+
ツールの存在から事業利益を得る企業が、制作者にメンテナンスの対価を支払う。
143
+
144
+
\begin{table}[h]
145
+
\small
146
+
\centering
147
+
\begin{tabularx}{\columnwidth}{Xlr}
148
+
\toprule
149
+
\textbf{制作者} & \textbf{スポンサー} & \textbf{期間} \\
150
+
\midrule
151
+
Larry Wall & O'Reilly & 7年 \\
152
+
Guido van Rossum & Google/Dropbox/MS & 20+年 \\
153
+
Matz & NaCl/Heroku & 28+年 \\
154
+
Evan Czaplicki & NoRedInk & 7+年 \\
155
+
\bottomrule
156
+
\end{tabularx}
157
+
\caption{企業スポンサーシップの取り決め。}
158
+
\label{tab:corporate}
159
+
\end{table}
160
+
161
+
Van Rossumの軌跡は調査中最も手厚い企業支援を受けている：CWI、CNRI、Google（50\%のPython時間）、Dropbox、Microsoft。各雇用者がPythonの仕事に対して支払った。しかし継続的な企業支援があっても、PEP 572をめぐるコミュニティの毒性が29年後にBDFL辞任に追い込んだ：「人々がソーシャルメディアに出て、本当に個人的に傷つくことを言った。」
162
+
163
+
WallのO'Reillyスポンサーシップは2002年頃に終了した。その後「公式には約5年間失業」し、胃の手術と長期の疾患の中でPerl 6の開発を続けた。スポンサーは去った；制作者は残った。
164
+
165
+
Czaplickiはスポンサーシップがなぜ十分でないかを最も明確に表現している。彼のStrange Loop講演~\citep{czaplicki2018hard, czaplicki2023economics}は、寄付ベースの資金調達の構造的な持続不可能性と、メンテナーの精力を消耗させる「なぜ単に……しないのか」という要求を記述している。彼は持続不可能な拡大よりもElmの成長を意図的に制限した。
166
+
167
+
\subsection{個人の犠牲}
168
+
169
+
機関が支払わない場合、制作者は自らの資源で支払う：貯蓄、健康、人間関係、将来の収入力。
170
+
171
+
HickeyはClojure構築に2.5年分の退職貯蓄を費やした。「抽象的なレベルで人々にアイデアを納得させることができなかったので、自分で実装を構築するしかなかった」からである。自己資金調達から持続可能なサポート（Cognitect、後にNubankが買収）までの間隔はおよそ8年だった。
172
+
173
+
Processingは\textbf{11年間}（2001〜2012）専用の資金がなかった。Processing Foundationは2012年に設立された——ボランティア労働ではもはやプロジェクトを維持できなくなったからである。最初の10年間、「コードの大部分は少数の人々が時間をボランティアで提供して書いたもので、フルタイムの有給開発者はいなかった。」
174
+
175
+
Bret Victorは二度の連続した資金崩壊を経験した——SAPがCDGから撤退し、続いてSam Altmanが「彼らがOaklandの改装されたビルに入居してわずか数ヶ月後に」HARCの資金を打ち切った。VictorのAppleでの貯蓄がこれらのギャップを埋めた可能性がある。Dynamiclandは最終的に501(c)(3)となったが、その軌跡は機関の裏切りによって定義されている。
176
+
177
+
\subsection{コミュニティクラウドファンディング}
178
+
179
+
Patreon、Open Collective、Ko-fi、およびそれに類するプラットフォームにより、ユーザーが制作者に直接資金を提供できる。金額は通常少額である。
180
+
181
+
AaronのSonic PiはPatreon寄付と有料講演で維持されている。Olivia JackのHydraはOpen Collectiveの寄付と200ドルのマイクロ助成金で運営されている。Alex McLeanのTidalCyclesは個人Ko-fiからOpen Collectiveへ移行した。ShiffmanはCoding Train YouTubeの収入とPatreonでNYUの給与を補っている。
182
+
183
+
パターンは明確である：クラウドファンディングは別の収入源の補完として機能する。調査したいずれのケースでも、主たる収入として制作者を維持することはできなかった。最もユーザー数の多いツール（Processing、p5.js、Scratch）がクラウドファンディングを最も多く受けているわけではない。
184
+
185
+
\subsection{棚ぼた}
186
+
187
+
2021年、Processing FoundationはProcessingとp5.jsを使用するジェネラティブアーティストからおよそ\textbf{1,000万ドル}のNFT/暗号通貨寄付を受けた。これはFoundationが過去9年間に受けた全資金の合計を上回った。初めてフルタイムの従業員を雇用することが可能になった。
188
+
189
+
この出来事は再現不可能で、予測不可能で、計画不可能である。20年の歴史を持つプロジェクトを一夜にして変えた。調査した他のクリエイティブツールで同様の棚ぼたを経験したものはない。これはパターンではない；幸運である。
190
+
191
+
\subsection{パターンなし}
192
+
193
+
一部の制作者にはまったく資金パターンがない——大学給与の暗黙の補助金さえも。障害手当金、貯蓄、あるいは何もなしで構築する。
194
+
195
+
Terry Davisは社会保障障害手当金（月額およそ750〜1,200ドル）でTempleOSを構築し、両親の家に住んでいた。2017年に住居を失った後、ファンたちが物資を送ったが、彼らの提供する住居は拒否した。YouTubeチャンネルは停止された；PayPalは他者にハッキングされた；少額の寄付さえ彼の手に届かなかった。死の直前まで公共図書館から投稿を続けた。プロジェクトはパブリックドメインである。彼はそれを無料で提供した。
196
+
197
+
Goodiepalの\emph{El Camino del Hardcore}~\citep{goodiepal2012elcamino}——灰色のボール紙に印刷された191ページの「ラディカル・コンピュータ・ミュージック」スコア——はこのパターンの労働条件を内部から記録している。テキストは王立デンマーク音楽院からの解雇、作品が「実現するまでに長い時間がかかった」こと、そして「自分自身の病んでいるかもしれない脳の中でのみ意味を持ちうる何かを創ることの」不安を記述している。スコアは「ひとつの可能な未来の代替知性」——まだ存在せず、決して対価を支払わないかもしれない聴衆——に向けられている。
198
+
199
+
「パターンなし」のカテゴリーは終末的状態である。大学の給与や企業スポンサーが構造を提供しない場合、制作者の身体がインフラとなる。身体が疾病、ホームレス状態、または死によって機能しなくなると、プロジェクトはパブリックドメインの孤児ソフトウェアとなるか、完全に消滅する。
200
+
201
+
\section{ギャップ}
202
+
203
+
ツール制作から最初の持続可能な資金源までの中央値：
204
+
205
+
\begin{table}[h]
206
+
\small
207
+
\centering
208
+
\begin{tabularx}{\columnwidth}{Xrr}
209
+
\toprule
210
+
\textbf{ツール} & \textbf{制作年} & \textbf{ギャップ（年）} \\
211
+
\midrule
212
+
Processing & 2001 & 11 \\
213
+
Clojure & 2005 & 8 \\
214
+
Perl & 1987 & 8 \\
215
+
Sonic Pi & 2012 & 7 \\
216
+
Ruby & 1993 & 4 \\
217
+
p5.js & 2013 & 10 \\
218
+
TidalCycles & 2009 & 12+ \\
219
+
Hydra & 2018 & ---（なし） \\
220
+
TempleOS & 2003 & ---（制作者2018年死去） \\
221
+
Aesthetic Computer & 2021 & 5+（進行中） \\
222
+
\bottomrule
223
+
\end{tabularx}
224
+
\caption{制作から最初の持続可能な資金までのギャップ。「---」は持続可能な資金が実現していないことを示す。}
225
+
\label{tab:gap}
226
+
\end{table}
227
+
228
+
中央値のギャップは\textbf{8年}である。この期間中、制作者は上記のパターンでツールを補助するか——あるいは中止する。
229
+
230
+
\section{抹消の問題}
231
+
232
+
Hernando Barrag\'anは2003年にIDIIで修士論文としてWiringを制作した~\citep{barragan2004wiring}。指導教員のMassimo Banziと同僚がWiringの設計をより安価なハードウェア向けに改変し、Arduinoを発表した。Arduinoは5,400万ドルを調達した。Wiringは何も受け取らなかった。何年もの間、Barrag\'anに対する公的な認知はなかった。2013年のOpen Hardware Summitで、Arduinoチームのメンバーがこう認めた——Wiringの「功績を認めることに関して、あまりうまくやれていなかった。」
233
+
234
+
これは最も深刻なケースだが、パターン——学生がツールを制作し、機関や指導教員が利益を得る——はクリエイティブコンピューティング全体に浸透している。MaedaのDesign By NumbersからProcessingを作ったのは彼の学生だった；MaedaはRISD学長になり、Processingの制作者たちは10年間資金のないまま過ごした。
235
+
236
+
抹消は常に意図的ではない。それは構造的である：機関的な権力を持つ者（教授、指導教員、企業スポンサー）は、権力を持たない者（学生、ポスドク、独立開発者）が制作したツールから価値を抽出する有利な立場にある。
237
+
238
+
\section{著者の立場}
239
+
240
+
\ac{} は2021年から開発中である~\citep{scudder2026ac}。著者がこのセクションを含めるのは、クリエイティブツールに関する学術論文において資金をめぐる沈黙が、ツールが純粋な知的努力から生まれるという神話を永続させているからである。
241
+
242
+
著者は2021年にテニュアトラックのアカデミックポジションを離れ、\ac{} とWhistlegraphプロジェクトのフルタイム開発に専念した。それ以降、\ac{} は機関的サポートなしに構築されてきた——大学も、企業も、財団もない。詳細な財務履歴は研究目的で要請に応じて提供可能である。
243
+
244
+
2つのコミュニティ駆動型の資金メカニズムが出現した。第一に、\texttt{give.aesthetic.computer}——ユーザーがプラットフォームインフラの維持のために寄付する直接寄付ページ。第二に、\texttt{aesthetic.direct}——志を同じくする投資家にAesthetic Computer（プラットフォーム背後の会社）の株式を提供するエクイティ投資ページ。少数の個人投資家がSAFE契約を通じて参加している（「booted-by」モデル、プラットフォームの起動シーケンスにちなむ命名）。いずれのメカニズムも機関レベルの資金を生み出しておらず、市場リターンや助成金サイクルではなく、プロジェクトに対する個人の信念に依存している。
245
+
246
+
本論文の他のすべてのツールは機関の傘の下で構築された。ProcessingにはMIT、後にUCLAがあった。p5.jsにはUCLAがあった。Sonic PiにはCambridgeがあった。ChucKにはStanfordがあった。Pure DataにはUCSDがあった。PerlでさえO'Reillyがあった。\ac{} にはこれらのいずれもない。比較は「資金ありのツール vs. 資金なしのツール」ではない。「機関内で構築されたツール vs. すべての機関の外で構築されたツール」である。
247
+
248
+
これが重要なのは、\ac{} がプロトタイプではないからだ。登録ユーザー基盤、数万のブートセッション、数千のKidLispプログラム、数百のユーザー公開ピースがある。著者の前のプロジェクトWhistlegraphは260万のTikTokフォロワーを獲得した。人々がプラットフォームのデザインの上に構築し、インスピレーションを得ている——プロンプトは楽器というメタファー、ピースモデル、ソーシャルプラットフォーム上のジェネラティブアートのアプローチ。プロジェクトは機関的認知（KADIST、SMKデンマーク国立美術館、ZKM、Rhizome）を得ており、毎日使用するコミュニティがある。
249
+
250
+
プラットフォームは実在する。ユーザーは実在する。資金は実在しない。
251
+
252
+
\section{何が機能しうるか}
253
+
254
+
Eghbalの\emph{Roads and Bridges}~\citep{eghbal2016roads}と\emph{Working in Public}~\citep{eghbal2020working}はオープンソースソフトウェアにおけるインフラ危機を広範に記録している。クリエイティブコンピューティングツールはこの危機の複合版に直面している：インフラであり（数百万人が使用）、アートであり（文化的には価値があるが商業的には無価値）、教育であり（教育法に不可欠だがそのような資格では資金を得られない）。
255
+
256
+
Czaplickiの農業メタファーは適切である：「豊年に蓄えて凶年を凌ぐ。」しかしクリエイティブツール作者に豊年はめったにない。Processing FoundationのNFT棚ぼたは一世代に一度の豊年である。ほとんどの制作者は凶年しか経験しない。
257
+
258
+
機能しうるパターン：
259
+
\begin{itemize}
260
+
\item \textbf{ソブリン・テック・ファンド}：ドイツのSovereign Tech Fundはp5.jsに45万ユーロを提供した。このモデル——政府がオープンソースインフラに資金提供——はクリエイティブツールに拡張可能である。
261
+
\item \textbf{労働者協同組合}：Ramsey Nasserの EMMA Technology Cooperative（ニューヨークの4人の協同組合）は、孤独に向き合うことと企業に雇われることの間の代替案を提供する。
262
+
\item \textbf{長期企業フェローシップ}：Matzの28年間のNaClフェローシップは調査中最も永続的な取り決めである。クリエイティブツールに依存する企業は同様の取り決めを提供できる。
263
+
\item \textbf{メンテナンス給付金}：Ukelesはメンテナンスが創造的行為であると論じた~\citep{ukeles1969manifesto}。新しいツールの構築だけでなく、既存のツールのメンテナンスに対する給付金は、最も一般的な失敗点に対処するだろう。
264
+
\item \textbf{正直な会計}：クリエイティブツールに関するすべての論文は、その開発がどのように資金提供されたかを述べるセクションを含むべきである。資金をめぐる沈黙は、ツールが純粋な知的努力から生まれるという神話を永続させ、それを可能にした物質的条件を覆い隠す。
265
+
\end{itemize}
266
+
267
+
\section{結論}
268
+
269
+
数百万人の学生、アーティスト、音楽家が使用するクリエイティブコンピューティングツールは、ほとんどの場合対価を受けていない人々によって構築され維持されている。その労働はそれを重視しない大学に補助され、利益が乖離しうる企業に補助され、枯渇する個人の貯蓄に補助され、悪化する健康に補助されている。この分野には資金モデルがない——対処戦略の寄せ集めがあるだけだ。
270
+
271
+
本論文はこの問題を解決しない。問題に名前を付ける。ここで調査した26人の制作者——WallからMcCarthyからPucketteから著者まで——は共通の条件を共有している：彼らは他の人々が必要とするツールを作り、その必要性に見合った補償を受けなかった。制作から資金までのギャップは年単位で測られる。その代価は燃え尽き、解雇、疾病、そして消失で測られる。
272
+
273
+
問題はクリエイティブツールに価値があるかどうかではない。明らかに価値がある。問題は、それを作る人々が続けられるかどうかである。一部の人々にとって、答えは否である。Davisは障害手当金で121,000行のオペレーティングシステムを構築した後、線路のそばで死んだ。\_whyは身元を暴かれた後すべてを削除し、一銭も受け取らなかった。AaronはCambridgeがサポートを撤回した後「財務的生存」に直面した。Van Rossumは29年間のコミュニティの虐待の後に辞任した。Wallは失業と手術の中でPerlの開発を続けた。Goodiepalは「間違ったタイプの友人を作った」ために王立学院から解雇された。
274
+
275
+
パターンは一貫している：広く使用されるすべてのクリエイティブコンピューティングツールは機関の傘の下で構築された——大学、企業、または財団——そしてツール自体のドキュメントがそのことを認めることは稀である。傘が取り除かれると、制作者が露出する。最初から傘がない場合、制作者の身体がインフラとなり、身体は故障する。
276
+
277
+
本論文の著者は5年目にあり、活発なユーザー基盤を持ち、機関的サポートはない。これは不満ではない；データポイントである。次のデータポイントは、この分野が資金モデルを発展させるか、それとも制作者の身体に依存し続けるかにかかっている。
278
+
279
+
\vspace{0.5em}
280
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
281
+
282
+
\bibliographystyle{plainnat}
283
+
\bibliography{references}
284
+
285
+
\end{document}
+18
-16
papers/arxiv-whistlegraph/whistlegraph-cards.tex
+18
-16
papers/arxiv-whistlegraph/whistlegraph-cards.tex
···
40
40
\thispagestyle{empty}
41
41
\vspace*{\fill}
42
42
\begin{center}
43
-
\includegraphics[height=8em]{pals}\par\vspace{0.3em}
44
-
{\acbold\fontsize{20pt}{24pt}\selectfont\color{acdark} Whistlegraph}\par
45
-
\vspace{0.3em}
46
-
{\fontsize{10pt}{12pt}\selectfont\color{acpink} Drawing, Singing, and the Graphic Score as Viral Form}\par
47
-
\vspace{0.8em}
48
-
{\normalsize\color{cyan!70!blue}\textbf{@jeffrey}}\par
43
+
\includegraphics[height=9em]{pals}\par\vspace{0.1em}
44
+
{\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} Whistlegraph}\par
45
+
\vspace{0.1em}
46
+
{\fontsize{9pt}{11pt}\selectfont\color{acpink} Drawing, Singing, and the Graphic Score as Viral Form}\par
47
+
\vspace{0.4em}
48
+
{\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par
49
49
{\small\color{acgray} Aesthetic.Computer}\par
50
50
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
51
-
\vspace{0.8em}
52
-
\rule{0.6\textwidth}{1pt}\par
53
51
\vspace{0.4em}
54
-
{\small\color{acpink!40}\textit{working draft --- not for citation}}\par
55
-
\vspace{0.3em}
56
-
{\footnotesize\color{acgray} March 2026}\par
52
+
\rule{0.5\textwidth}{0.5pt}\par
53
+
\vspace{0.15em}
54
+
\colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par
55
+
\vspace{0.1em}
56
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/2113ef735}{2113ef735}}\par
57
+
\vspace{0.1em}
58
+
{\footnotesize\color{acgray}\href{https://papers.aesthetic.computer/whistlegraph-26-arxiv-da-cards.pdf}{Dansk} · \href{https://papers.aesthetic.computer/whistlegraph-26-arxiv-es-cards.pdf}{Español} · \href{https://papers.aesthetic.computer/whistlegraph-26-arxiv-zh-cards.pdf}{{\accjk 中文}} · \href{https://papers.aesthetic.computer/whistlegraph-26-arxiv-ja-cards.pdf}{{\accjk 日本語}}}\par
57
59
\end{center}
58
60
\vspace*{\fill}
59
61
···
69
71
70
72
``I'm a butterfly. Flapping for you guys. It's just a costume. I put on in my room.'' A hand draws a butterfly on paper while a voice sings these words. Each wing is a line; each line is a lyric; the finished drawing is a score that anyone can perform by tracing the lines and singing the words. The video is 15 seconds long. It was posted on TikTok in early 2020. Millions of people watched it.
71
73
72
-
This is a whistlegraph: a memorizable hybrid of drawing, singing, and poetry in which every mark corresponds to a sung syllable, producing a graphic score that is simultaneously artwork, song, and instruction manual for its own reproduction~\citep{dirt2023whistlegraph}. The format was invented by the author in 2019, developed into a trio practice with Alex Freundlich and Camille Klein during the COVID-19 pandemic, scaled to 2.6 million TikTok followers, exhibited at the New Museum and on Feral File, and then---after the trio separated in November 2023---fed directly into the design of \ac{}.
74
+
This is a whistlegraph: a memorizable hybrid of drawing, singing, and poetry in which every mark corresponds to a sung syllable, producing a graphic score that is simultaneously artwork, song, and instruction manual for its own reproduction~\citep{dirt2023whistlegraph}. I invented it in 2019, developed it into a trio practice with Alex Freundlich and Camille Klein during the COVID-19 pandemic, scaled it to 2.6 million TikTok followers, exhibited it at the New Museum and on Feral File, and then---after the trio separated in November 2023---it fed directly into the design of \ac{}.
73
75
74
-
This paper is not a retrospective. It is documentation of a form that emerged from the intersection of several practices---Radical Digital Painting~\citep{scudder2017manifesto}, Goodiepal's Radical Computer Music~\citep{goodiepal2012elcamino}, constraint-based art, and short-form social video---and that continues to inform the author's current work. The whistlegraph is the bridge between the author's painting practice and the creative computing platform.
76
+
This paper is not a retrospective. It is documentation of a form that emerged from the intersection of several practices---Radical Digital Painting~\citep{scudder2017manifesto}, Goodiepal's Radical Computer Music~\citep{goodiepal2012elcamino}, constraint-based art, and short-form social video---and that continues to inform my work. The whistlegraph is the bridge between my painting practice and the creative computing platform.
75
77
76
78
\section{The Form}
77
79
···
99
101
100
102
\subsection{Radical Digital Painting}
101
103
102
-
The whistlegraph emerged from the author's Radical Digital Painting (RDP) practice, active since 2016~\citep{scudder2017manifesto}. RDP treated digital painting not as a supplement to traditional painting but as its next material ground: ``Painting is just a kind of picture message.'' Over 65 lecture-performances across the US and Europe---including a 2018 European tour with Goodiepal \& Pals and a presentation at the 35th Chaos Communication Congress~\citep{scudder2018rdp35c3}---developed a format in which painting, speaking, and performing were fused into a single act.
104
+
The whistlegraph emerged from my Radical Digital Painting (RDP) practice, active since 2016~\citep{scudder2017manifesto}. RDP treated digital painting not as a supplement to traditional painting but as its next material ground: ``Painting is just a kind of picture message.'' Over 65 lecture-performances across the US and Europe---including a 2018 European tour with Goodiepal \& Pals and a presentation at the 35th Chaos Communication Congress~\citep{scudder2018rdp35c3}---developed a format in which painting, speaking, and performing were fused into a single act.
103
105
104
106
The whistlegraph formalized what the RDP lectures did informally: synchronized the act of making with the act of narrating. Where an RDP lecture was improvised and unrepeatable, a whistlegraph was composed, memorizable, and reproducible. The shift from improvisation to composition---from lecture to score---was the key innovation.
105
107
106
108
\subsection{COVID-19 and the Trio}
107
109
108
-
In 2020, during the COVID-19 lockdown, the author formed a trio with Alex Freundlich and Camille Klein in a cabin in Ashland, Oregon. The pandemic eliminated the possibility of live performance and lecture tours. TikTok, which had exploded in popularity during lockdown, offered a platform for short-form video that matched the whistlegraph's natural duration.
110
+
In 2020, during the COVID-19 lockdown, I formed a trio with Alex Freundlich and Camille Klein in a cabin in Ashland, Oregon. The pandemic eliminated the possibility of live performance and lecture tours. TikTok, which had exploded in popularity during lockdown, offered a platform for short-form video that matched the whistlegraph's natural duration.
109
111
110
112
The trio posted musical drawing tutorials: a hand draws while a voice sings, the camera captures both, and the result is a 15-second video that teaches the viewer to reproduce the whistlegraph themselves. The format was natively suited to TikTok's duet and stitch features, which allowed viewers to perform alongside the original video. The whistlegraph was not just content to be consumed; it was a score to be performed.
111
113
···
161
163
162
164
\section{Separation and Continuation}
163
165
164
-
In November 2023, the trio separated due to a conflict in future goals. The author took sole access to the group's social media platforms, including the 2.6-million-follower TikTok account. The @whistlegraph handle now posts \ac{} content.
166
+
In November 2023, the trio separated due to a conflict in future goals. I took sole access to the group's social media platforms, including the 2.6-million-follower TikTok account. The @whistlegraph handle now posts \ac{} content.
165
167
166
168
The separation ended the trio but not the form. The whistlegraph's core properties---reproducibility, mark-melody correspondence, the graphic score as instruction manual---directly informed the design of \ac{}:
167
169
+228
papers/arxiv-whistlegraph/whistlegraph-ja.tex
+228
papers/arxiv-whistlegraph/whistlegraph-ja.tex
···
1
+
% !TEX program = xelatex
2
+
\documentclass[10pt,letterpaper,twocolumn]{article}
3
+
4
+
\usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry}
5
+
\usepackage{fontspec}
6
+
\usepackage{unicode-math}
7
+
\setmainfont{Latin Modern Roman}
8
+
\setsansfont{Latin Modern Sans}
9
+
\newfontfamily\acbold{ywft-processing-bold}[Path=../../system/public/type/webfonts/,Extension=.ttf]
10
+
\newfontfamily\aclight{ywft-processing-light}[Path=../../system/public/type/webfonts/,Extension=.ttf]
11
+
\setmonofont{Latin Modern Mono}[Scale=0.85]
12
+
13
+
\usepackage{xeCJK}
14
+
\setCJKmainfont{Droid Sans Japanese}
15
+
\setCJKsansfont{Droid Sans Japanese}
16
+
\setCJKmonofont{Droid Sans Japanese}
17
+
18
+
\usepackage{xcolor}
19
+
\usepackage{titlesec}
20
+
\usepackage{enumitem}
21
+
\usepackage{booktabs}
22
+
\usepackage{tabularx}
23
+
\usepackage{fancyhdr}
24
+
\usepackage{hyperref}
25
+
\usepackage{graphicx}
26
+
\graphicspath{{figures/}{../../papers/arxiv-ac/figures/}}
27
+
\usepackage{ragged2e}
28
+
\usepackage{microtype}
29
+
\usepackage{natbib}
30
+
\usepackage[colorspec=0.92]{draftwatermark}
31
+
32
+
\definecolor{acpink}{RGB}{180,72,135}
33
+
\definecolor{acpurple}{RGB}{120,80,180}
34
+
\definecolor{acdark}{RGB}{64,56,74}
35
+
\definecolor{acgray}{RGB}{119,119,119}
36
+
\definecolor{draftcolor}{RGB}{180,72,135}
37
+
38
+
\DraftwatermarkOptions{text=WORKING DRAFT,fontsize=3cm,color=draftcolor!18,angle=45}
39
+
40
+
\hypersetup{colorlinks=true,linkcolor=acpurple,urlcolor=acpurple,citecolor=acpurple,
41
+
pdftitle={Whistlegraph：ドローイング、歌唱、そしてバイラルな形式としてのグラフィックスコア}}
42
+
43
+
\titleformat{\section}{\normalfont\bfseries\normalsize\uppercase}{\thesection.}{0.5em}{}
44
+
\titlespacing{\section}{0pt}{1.2em}{0.3em}
45
+
\titleformat{\subsection}{\normalfont\bfseries\small}{\thesubsection}{0.5em}{}
46
+
\titlespacing{\subsection}{0pt}{0.8em}{0.2em}
47
+
48
+
\pagestyle{fancy}\fancyhf{}
49
+
\renewcommand{\headrulewidth}{0pt}
50
+
\fancyhead[C]{\footnotesize\color{acpink}\textit{作業草稿——引用不可}}
51
+
\fancyfoot[C]{\footnotesize\thepage}
52
+
53
+
\newcommand{\ac}{\textsc{Aesthetic.Computer}}
54
+
\newcommand{\wg}{\textsc{Whistlegraph}}
55
+
56
+
\setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em}
57
+
\setlength{\columnsep}{1.8em}
58
+
\setlength{\parindent}{1em}
59
+
\setlength{\parskip}{0.3em}
60
+
61
+
% Hyphenation for narrow two-column layout
62
+
\tolerance=800
63
+
\emergencystretch=1em
64
+
\hyphenpenalty=50
65
+
66
+
\begin{document}
67
+
68
+
\twocolumn[{%
69
+
\begin{center}
70
+
\includegraphics[height=4em]{pals}\par\vspace{0.5em}
71
+
{\acbold\fontsize{22pt}{26pt}\selectfont\color{acdark} Whistlegraph}\par
72
+
\vspace{0.2em}
73
+
{\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} ドローイング、歌唱、そしてバイラルな形式としてのグラフィックスコア}\par
74
+
\vspace{0.3em}
75
+
{\aclight\fontsize{9pt}{11pt}\selectfont\color{acgray} Ashlandの小屋から260万フォロワーを経てAesthetic Computerへ}\par
76
+
\vspace{0.6em}
77
+
{\normalsize @jeffrey}\par
78
+
{\small\color{acgray} Aesthetic.Computer}\par
79
+
{\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par
80
+
\vspace{0.3em}
81
+
{\small\color{acpurple} \url{https://aesthetic.computer}}\par
82
+
\vspace{0.6em}
83
+
\rule{\textwidth}{1.5pt}
84
+
\vspace{0.5em}
85
+
\end{center}
86
+
87
+
\begin{center}
88
+
{\small\color{acpink}\textbf{[ 作業草稿——引用不可 ]}}
89
+
\end{center}
90
+
\vspace{0.3em}
91
+
92
+
\begin{quote}
93
+
\small\noindent\textbf{要旨。}
94
+
Whistlegraphはドローイング、歌唱、詩の記憶可能な融合体である：各描線が歌われる詩の一行に対応し、同時にドローイングであり、歌であり、自身の複製説明書でもあるグラフィックスコアを生成する。この形式は2019年に著者によって発明され、COVID-19パンデミック中にOregon州Ashlandで三人組（@jeffrey、Alex Freundlich、Camille Klein）によって発展し、短尺動画の音楽ドローイングチュートリアルを通じてTikTokで260万フォロワーを獲得し、2023年11月の三人組解散に至った。本論文はwhistlegraphを形式として記録する：その構造、実験音楽におけるグラフィックスコアとの関係、ダンスとリップシンクのために設計されたプラットフォームでの予期せぬバイラル性、機関的受容（Rhizome/New Museum委嘱、Feral File展覧会、Schneider Museum設置、KADIST収蔵）、そして\ac{}~\citep{scudder2026ac}の直接的前身としての役割。Whistlegraphの力はその\emph{再現可能性}にあると論じる——線を一本引き、音符を一つ歌える人なら誰でも演奏できる——そしてアルゴリズムによるプロモーションではなくこの再現可能性がバイラルな拡散を説明する。Whistlegraphは自身の演奏方法を教えるスコアである。
95
+
\end{quote}
96
+
\vspace{0.5em}
97
+
}]
98
+
99
+
\section{序論}
100
+
101
+
「I'm a butterfly. Flapping for you guys. It's just a costume. I put on in my room.」一本の手が紙に蝶を描き、同時に声がこの歌詞を歌う。各翅が一本の線であり、各線が一行の歌詞であり、完成したドローイングは誰もが線をなぞり歌詞を歌うことで演奏できるスコアとなる。動画の長さは15秒。2020年初頭にTikTokに投稿された。数百万人が視聴した。
102
+
103
+
これがwhistlegraphである：ドローイング、歌唱、詩の記憶可能な融合体で、各筆触が歌われる一音節に対応し、アートワークであると同時に歌であり、自身の複製説明書でもあるグラフィックスコアを生成する~\citep{dirt2023whistlegraph}。この形式は2019年に著者によって発明され、COVID-19パンデミック中にAlex FreundlichとCamille Kleinとともに三人組の実践として発展し、TikTokで260万フォロワーに拡大し、New MuseumとFeral Fileで展示され、そして——2023年11月の三人組解散後——\ac{} のデザインに直接注入された。
104
+
105
+
本論文は回顧ではない。複数の実践の交差点から出現した形式の記録である——ラディカル・デジタル・ペインティング~\citep{scudder2017manifesto}、Goodiepalのラディカル・コンピュータ・ミュージック~\citep{goodiepal2012elcamino}、制約ベースのアート、そしてショートフォームのソーシャルビデオ——そしてこの形式は著者の現在の作業に影響を与え続けている。Whistlegraphは著者のドローイング実践とクリエイティブコンピューティングプラットフォームの間の橋渡しである。
106
+
107
+
\section{形式}
108
+
109
+
\subsection{構造}
110
+
111
+
Whistlegraphには同時進行する3つのレイヤーがある：
112
+
113
+
\begin{enumerate}
114
+
\item \textbf{視覚}：リアルタイムで描かれるドローイング。通常、紙にペンまたはマーカーで、あるいは黒板にチョークで。各筆触は意図的であり、音楽的要素に対応する。
115
+
\item \textbf{音楽}：歌われるメロディ。各音符がドローイングの筆触と整合する。メロディは一度か二度の視聴で覚えられるほど単純である。
116
+
\item \textbf{テキスト}：詩として機能する歌詞。歌詞は描写し、語り、指示する。覚えられるほど短い。
117
+
\end{enumerate}
118
+
119
+
完成したドローイングは\emph{グラフィックスコア}として機能する——パフォーマンスを再現するために必要なすべての情報をエンコードした視覚的文書。ドローイングを見てメロディを思い出せる人なら誰でもwhistlegraphを演奏できる。スコアは自身の演奏方法を教える。
120
+
121
+
この自己文書化という特性が、whistlegraphを実験音楽における他のグラフィックスコアから区別する~\citep{magnusson2010designing}。CageやCardewのグラフィックスコアは解釈を必要とする——演奏者は視覚的な印が音楽的に何を意味するかを決定しなければならない。Whistlegraphは解釈を必要としない。印と音の関係は一対一であり、オリジナルのパフォーマンスで確立され、録画に保存されている。スコアは即興演奏のプロンプトではない——ドローイングに偽装された精密な指示書である。
122
+
123
+
\subsection{長さと制約}
124
+
125
+
ほとんどのwhistlegraphは5〜30秒である。制約は意図的である：一度の視聴で記憶できるほど短く、子どもが再現できるほど単純で、完成したドローイングが独立した画像として満足できるほど完結していなければならない。これらの制約——簡潔さ、単純さ、完結性——がwhistlegraphの設計パラメータである。Kleeの教育的練習~\citep{klee1925pedagogical}やKandinskyの点-線-面分析~\citep{kandinsky1926point}を彷彿とさせるが、TikTokの15秒縦型動画というネイティブフォーマットに変換されている。
126
+
127
+
最長のwhistlegraph——「The Longest Whistlegraph Ever (so far)」、Rhizomeの委嘱~\citep{rhizome2022longest}——は約22分で、上端にベルが取り付けられた4×6フィートの黒板にチョークで演奏された。これは制約を証明する例外である：New Museumの観客は持続的な注意を維持した。なぜなら数百の15秒whistlegraphによって、この形式特有の印とメロディの融合を期待するよう訓練されていたからである。
128
+
129
+
\section{起源}
130
+
131
+
\subsection{ラディカル・デジタル・ペインティング}
132
+
133
+
Whistlegraphは、2016年以来著者が取り組んでいるラディカル・デジタル・ペインティング（RDP）の実践から出現した~\citep{scudder2017manifesto}。RDPはデジタルペインティングを伝統的ペインティングの補完ではなく次なる物質的基盤として扱う：「ペインティングは単なるピクチャーメッセージにすぎない。」アメリカとヨーロッパでの65回以上のレクチャーパフォーマンス——2018年のGoodiepal \& Palsとのヨーロッパツアーや第35回Chaos Communication Congressでのプレゼンテーション~\citep{scudder2018rdp35c3}を含む——が、ドローイング、ナレーション、パフォーマンスを一つの行為に融合する形式を発展させた。
134
+
135
+
WhistlegraphはRDPレクチャーが非公式に行っていたことを形式化した：創作行為と語りの行為の同期。RDPレクチャーは即興的で再現不可能だったが、whistlegraphは作曲され、記憶可能で、再現可能である。即興から作曲へ——レクチャーからスコアへ——が核心的なイノベーションである。
136
+
137
+
\subsection{COVID-19と三人組}
138
+
139
+
2020年、COVID-19のロックダウン中に、著者はOregon州Ashlandの小屋でAlex FreundlichとCamille Kleinとともに三人組を結成した。パンデミックはライブパフォーマンスとレクチャーツアーの可能性を排除した。TikTokはロックダウン中に人気が爆発し、whistlegraphの自然な長さに合致するショートフォーム動画のプラットフォームを提供した。
140
+
141
+
三人組は音楽ドローイングチュートリアルを投稿した：一本の手が描き、声が歌い、カメラが両方を同時に捉え、結果として観客にwhistlegraphの自己複製方法を教える15秒の動画が生まれた。このフォーマットはTikTokのデュエットやリミックス機能と自然に適合し、観客がオリジナル動画と一緒に演奏することを可能にした。Whistlegraphは単に消費されるコンテンツではなかった——演奏されるスコアだった。
142
+
143
+
\section{バイラルな拡散}
144
+
145
+
\subsection{成長}
146
+
147
+
@whistlegraph TikTokアカウントは2020年から2023年にかけてゼロから260万フォロワーに成長した。成長はオーガニックだった——有料プロモーションなし、アルゴリズム操作なし、トレンド便乗なし。バイラルのメカニズムは形式そのものだった：whistlegraphを学んだ視聴者はそれを演奏したくなり、彼らの演奏がこの形式を彼ら自身のオーディエンスに紹介した。
148
+
149
+
「I'm a Butterfly」——ミュージシャンbo enとのコラボレーション——は最初期のヒットの一つだった。そのメロディ（「I'm a butterfly / flapping for you guys / it's just a costume / I put on in my room」）とドローイング（四筆で描かれるシンプルな蝶）は、レコメンデーションではなく反復を通じて拡散するほど記憶に残るものだった。
150
+
151
+
\subsection{なぜTikTokで効果があったのか}
152
+
153
+
TikTokの主要コンテンツフォーマット——ダンスチャレンジ、リップシンク、コメディスキット——はwhistlegraphと一つの構造的特性を共有している：\emph{再現可能なパフォーマンス}であるということ。ダンスチャレンジは、視聴者が振り付けを学び自分のバージョンを投稿する時に成功する。Whistlegraphは同じバイラルメカニズムを持つドローイングチャレンジである：スコアを学び、演奏し、投稿する。
154
+
155
+
しかしwhistlegraphは他のTikTokフォーマットに欠けている要素を導入した：\emph{オリジナルの作曲}。ダンスチャレンジは既存の曲を使う。リップシンクは既存の音声を使う。Whistlegraphはそれ自身の歌であり、それ自身のドローイングであり、それ自身の使用説明書である。他のメディアからバイラル性を借りるのではなく、自身の構造からバイラル性を生成する。
156
+
157
+
これはPapertのコネクショニズム~\citep{papert1980mindstorms}である：whistlegraphは「マイクロワールド」であり、学習者は何かを構築することによって知識を構成する。観客はwhistlegraphを受動的に消費するのではない——能動的に複製し、そうすることで視覚的な印と音符の関係について何かを学ぶ。
158
+
159
+
\section{機関的受容}
160
+
161
+
\begin{table}[h]
162
+
\small
163
+
\centering
164
+
\begin{tabularx}{\columnwidth}{Xlr}
165
+
\toprule
166
+
\textbf{機関} & \textbf{作品} & \textbf{年} \\
167
+
\midrule
168
+
Rhizome / New Museum & 委嘱＋パフォーマンス & 2022 \\
169
+
Feral File & Ten Whistlegraphs（45エディション） & 2022 \\
170
+
Taipei Dangdai & NFT Launch Stage & 2022 \\
171
+
Schneider Museum (SOU) & 屋外インスタレーション & 2021 \\
172
+
KADIST (San Francisco) & RDP \#98 収蔵 & 2021 \\
173
+
SMK（デンマーク） & Ten Minute Painting & 2018 \\
174
+
Rhizome ArtBase & 永久収録 & 2022 \\
175
+
\bottomrule
176
+
\end{tabularx}
177
+
\caption{機関での展覧会と収蔵。}
178
+
\label{tab:institutions}
179
+
\end{table}
180
+
181
+
機関的軌跡はその速さで注目に値する：TikTokチュートリアルからRhizome/New Museum委嘱まで2年未満。Rhizome委嘱~\citep{rhizome2022longest}——New Museumと協力して展示されたFirst Lookシリーズの一環——にはチョークのライブパフォーマンス、22分4Kビデオ、IPFS上のトークンゲート付き原稿と録音、そしてQueensでの13〜18歳向けワークショップ（Deutsche Bank Americas Foundation助成）が含まれた。作品はRhizomeのArtBaseに収録され、TikTokネイティブのアート形式がOlia LialinaやJODIのネットアートと同じコレクションに並んだ。
182
+
183
+
Feral File展覧会~\citep{feralfile2022ten}——ERC-721トークンとしての10のwhistlegraph、各々にビデオパフォーマンス、グラフィックスコア、キュレーションされたTikTokセレクションが含まれる——は45エディション販売された。Taipei DangdaiではArt BlocksやOutlandとともに展示された。
184
+
185
+
60ページの小冊子がAsher Penn（\emph{Sex Magazine}）の編集で2023年6月に出版され、印刷部数は750部。三人組全員のインタビューとJacob Ciocci（Paper Rad）による「The Butterfly Effect / Rules Set You Free」と題された論考~\citep{ciocci2023butterfly}が収録され、whistlegraphをPaper Radのルールベース、コミュニティ生成アートの遺産と結びつけている。
186
+
187
+
\section{音楽}
188
+
189
+
三人組はストリーミングプラットフォームで音楽をリリースした：シングル（「Infinitely Falling, Pop Sounds」、「Whistlegraph Practice」、「What's Inside Your Heart?」）とスタジオアルバム\emph{Music 2 Whistlegraph 2}（2022年12月、Charlie Kamin-Allenプロデュース）。アルバムはwhistlegraphの形式をより長い楽曲に拡張しつつ、核心的原則を維持した：各音楽要素が視覚的な印に対応する。
190
+
191
+
音楽は副業ではない。Whistlegraphのもう半分である。音楽のないグラフィックスコアは絵画であり、グラフィックスコアのない音楽は歌である。両方が合わさってwhistlegraphとなる。ストリーミングリリースはTikTokとは独立して流通できる形式でこの融合を記録した。
192
+
193
+
\section{解散と継続}
194
+
195
+
2023年11月、将来の目標の衝突により三人組は解散した。著者はグループのソーシャルメディアプラットフォームへの単独アクセス権を得た。260万フォロワーのTikTokアカウントを含む。@whistlegraphユーザー名は現在\ac{} のコンテンツを投稿している。
196
+
197
+
解散は三人組を終わらせたが、形式を終わらせはしなかった。Whistlegraphの核心的特性——再現可能性、印-メロディ対応、使用説明書としてのグラフィックスコア——は\ac{} のデザインに直接影響した：
198
+
199
+
\begin{itemize}
200
+
\item \textbf{プロンプトは楽器}というメタファー（即興演奏を通じて発見される記憶可能なパス）はwhistlegraphの記憶可能なスコアを反映している。
201
+
\item \textbf{ピースモデル}（一つのコンテキストで実行される自己完結したプログラム）はwhistlegraphの自己完結したパフォーマンスを反映している。
202
+
\item \textbf{即時モードレンダラー}（毎フレームゼロから描画）はwhistlegraphの、ドローイングは静的なアーティファクトではなくリアルタイムで行われなければならないという主張を反映している。
203
+
\item \textbf{TikTokからプラットフォームへのパイプライン}——ソーシャルネットワーク上の260万フォロワーがクリエイティブコンピューティングプラットフォームに流入——は他のクリエイティブツールが試みたことのない配布モデルである。
204
+
\end{itemize}
205
+
206
+
Whistlegraphは\ac{} からの回り道ではない。ほとんどのクリエイティブコンピューティングツールが持たなかったオーディエンス構築フェーズである。ProcessingにはMITがあった；p5.jsにはUCLAがあった；Sonic PiにはCambridgeがあった。\ac{} には、ドローイングと音楽が同じものでありうることを知っている260万人がいた。
207
+
208
+
\section{インターフェースとしてのグラフィックスコア}
209
+
210
+
Whistlegraphは、一枚の絵がインターフェースになりうることを提案する——インターフェースの表現（ワイヤーフレームのような）ではなく、自身の実行命令をエンコードする\emph{機能的}インターフェースである。これが\ac{} のデザイン哲学との接点である：プロンプトは入力に応答することで使い方を教えるインターフェースである。ピースはインタラクションを通じてアフォーダンスを明らかにするインターフェースである。Whistlegraphはなぞることでメロディを明らかにするインターフェースである。
211
+
212
+
Eshunの「ソニックフィクション」~\citep{eshun1998more}——それが描写する現実を構築する音楽——はwhistlegraphに視覚的なアナロジーを持つ：それが描写するパフォーマンスを構築するドローイング。グラフィックスコアはwhistlegraph\emph{について}のドキュメントではない——それがwhistlegraph\emph{そのもの}であり、コードがプログラムについてのドキュメントではなくプログラムそのものであるのと同じように。
213
+
214
+
\section{結論}
215
+
216
+
WhistlegraphはTikTokで機能するはずのない形式だった。ダンスでもない。リップシンクでもない。コメディスキットでもない。一人の人間がゆっくりと描きながら静かに歌っているだけだ。260万フォロワーを獲得したのは、TikTokネイティブのフォーマットが提供しないものを提供したからだ：学べるスコア、描ける絵、歌える歌、そしてその三つを同時に行うための指示。
217
+
218
+
形式の機関的受容——Rhizome、New Museum、Feral File、KADIST、SMK——はwhistlegraphがアートとして認知されたことを確認する。TikTokでの受容はコンテンツとして認知されたことを確認する。\ac{} での継続はデザイン方法論として認知されたことを確認する。三つすべてであるのは、再現可能であるように設計されたからであり、再現可能性こそがアート（スコア）、コンテンツ（ビデオ）、インターフェースデザイン（プロンプト）を接続する特性だからである。
219
+
220
+
著者は「気ままに絵を描く楽しさを、自らのツール技術を前進させる苦しさと交換した」~\citep{scudder2019drawing}。Whistlegraphは絵を描くことがまだ楽しかった最後のプロジェクトである。それ以降のすべてはツールの構築である。
221
+
222
+
\vspace{0.5em}
223
+
\noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}
224
+
225
+
\bibliographystyle{plainnat}
226
+
\bibliography{references}
227
+
228
+
\end{document}
+25
-19
papers/cards-convert.mjs
+25
-19
papers/cards-convert.mjs
···
14
14
15
15
const PAPERS_DIR = new URL(".", import.meta.url).pathname;
16
16
17
+
const ALL_TRANSLATIONS = { da: "Dansk", es: "Español", zh: "中文", ja: "日本語" };
18
+
17
19
const PAPER_MAP = {
18
-
"arxiv-ac": { base: "ac", title: "\\acrandname{} '26", siteName: "aesthetic-computer-26-arxiv" },
19
-
"arxiv-api": { base: "api", title: "From \\texttt{setup()} to \\texttt{boot()}", siteName: "piece-api-26-arxiv" },
20
-
"arxiv-archaeology": { base: "archaeology", title: "Repository Archaeology", siteName: "repo-archaeology-26-arxiv" },
21
-
"arxiv-dead-ends": { base: "dead-ends", title: "Vestigial Features", siteName: "dead-ends-26-arxiv" },
22
-
"arxiv-diversity": { base: "diversity", title: "Citation Diversity Audit", siteName: "citation-diversity-audit-26" },
23
-
"arxiv-folk-songs": { base: "folk-songs", title: "Playable Folk Songs", siteName: "folk-songs-26-arxiv" },
24
-
"arxiv-goodiepal": { base: "goodiepal", title: "Radical Computer Art", siteName: "radical-computer-art-26-arxiv" },
25
-
"arxiv-kidlisp": { base: "kidlisp", title: "Kid{\\color{acpurple}Lisp} '26", siteName: "kidlisp-26-arxiv" },
26
-
"arxiv-kidlisp-reference": { base: "kidlisp-reference", title: "KidLisp Language Reference", siteName: "kidlisp-reference-26-arxiv" },
27
-
"arxiv-network-audit": { base: "network-audit", title: "Network Audit", siteName: "network-audit-26-arxiv" },
28
-
"arxiv-notepat": { base: "notepat", title: "notepat{\\color{acpurple}.}{\\color{acpink}com}", siteName: "notepat-26-arxiv" },
29
-
"arxiv-os": { base: "os", title: "AC Native OS '26", siteName: "ac-native-os-26-arxiv" },
30
-
"arxiv-pieces": { base: "pieces", title: "Pieces Not Programs", siteName: "pieces-not-programs-26-arxiv" },
31
-
"arxiv-plork": { base: "plork", title: "PLOrk'ing the Planet", siteName: "plorking-the-planet-26-arxiv", translations: { da: "Dansk", es: "Español", zh: "中文", ja: "日本語" } },
32
-
"arxiv-sustainability": { base: "sustainability", title: "Who Pays for Creative Tools?", siteName: "who-pays-for-creative-tools-26-arxiv" },
33
-
"arxiv-whistlegraph": { base: "whistlegraph", title: "Whistlegraph", siteName: "whistlegraph-26-arxiv" },
34
-
"arxiv-complex": { base: "complex", title: "Sucking on the Complex", siteName: "sucking-on-the-complex-26-arxiv" },
35
-
"arxiv-kidlisp-cards": { base: "kidlisp-cards", title: "Kid{\\color{acpurple}Lisp} Cards", siteName: "kidlisp-cards-26-arxiv" },
36
-
"arxiv-score-analysis": { base: "score-analysis", title: "Reading the Score", siteName: "reading-the-score-26-arxiv" },
20
+
"arxiv-ac": { base: "ac", title: "\\acrandname{} '26", siteName: "aesthetic-computer-26-arxiv", translations: ALL_TRANSLATIONS },
21
+
"arxiv-api": { base: "api", title: "From \\texttt{setup()} to \\texttt{boot()}", siteName: "piece-api-26-arxiv", translations: ALL_TRANSLATIONS },
22
+
"arxiv-archaeology": { base: "archaeology", title: "Repository Archaeology", siteName: "repo-archaeology-26-arxiv", translations: ALL_TRANSLATIONS },
23
+
"arxiv-dead-ends": { base: "dead-ends", title: "Vestigial Features", siteName: "dead-ends-26-arxiv", translations: ALL_TRANSLATIONS },
24
+
"arxiv-diversity": { base: "diversity", title: "Citation Diversity Audit", siteName: "citation-diversity-audit-26", translations: ALL_TRANSLATIONS },
25
+
"arxiv-folk-songs": { base: "folk-songs", title: "Playable Folk Songs", siteName: "folk-songs-26-arxiv", translations: ALL_TRANSLATIONS },
26
+
"arxiv-goodiepal": { base: "goodiepal", title: "Radical Computer Art", siteName: "radical-computer-art-26-arxiv", translations: ALL_TRANSLATIONS },
27
+
"arxiv-kidlisp": { base: "kidlisp", title: "Kid{\\color{acpurple}Lisp} '26", siteName: "kidlisp-26-arxiv", translations: ALL_TRANSLATIONS },
28
+
"arxiv-kidlisp-reference": { base: "kidlisp-reference", title: "KidLisp Language Reference", siteName: "kidlisp-reference-26-arxiv", translations: ALL_TRANSLATIONS },
29
+
"arxiv-network-audit": { base: "network-audit", title: "Network Audit", siteName: "network-audit-26-arxiv", translations: ALL_TRANSLATIONS },
30
+
"arxiv-notepat": { base: "notepat", title: "notepat{\\color{acpurple}.}{\\color{acpink}com}", siteName: "notepat-26-arxiv", translations: ALL_TRANSLATIONS },
31
+
"arxiv-os": { base: "os", title: "AC Native OS '26", siteName: "ac-native-os-26-arxiv", translations: ALL_TRANSLATIONS },
32
+
"arxiv-pieces": { base: "pieces", title: "Pieces Not Programs", siteName: "pieces-not-programs-26-arxiv", translations: ALL_TRANSLATIONS },
33
+
"arxiv-plork": { base: "plork", title: "PLOrk'ing the Planet", siteName: "plorking-the-planet-26-arxiv", translations: ALL_TRANSLATIONS },
34
+
"arxiv-sustainability": { base: "sustainability", title: "Who Pays for Creative Tools?", siteName: "who-pays-for-creative-tools-26-arxiv", translations: ALL_TRANSLATIONS },
35
+
"arxiv-whistlegraph": { base: "whistlegraph", title: "Whistlegraph", siteName: "whistlegraph-26-arxiv", translations: ALL_TRANSLATIONS },
36
+
"arxiv-complex": { base: "complex", title: "Sucking on the Complex", siteName: "sucking-on-the-complex-26-arxiv", translations: ALL_TRANSLATIONS },
37
+
"arxiv-kidlisp-cards": { base: "kidlisp-cards", title: "Kid{\\color{acpurple}Lisp} Cards", siteName: "kidlisp-cards-26-arxiv", translations: ALL_TRANSLATIONS },
38
+
"arxiv-score-analysis": { base: "score-analysis", title: "Reading the Score", siteName: "reading-the-score-26-arxiv", translations: ALL_TRANSLATIONS },
39
+
"arxiv-calarts": { base: "calarts", title: "CalArts, Callouts, and Papers", siteName: "calarts-callouts-papers-26-arxiv", translations: ALL_TRANSLATIONS },
40
+
"arxiv-futures": { base: "futures", title: "Five Years from Now", siteName: "five-years-from-now-26-arxiv", translations: ALL_TRANSLATIONS },
41
+
"arxiv-identity": { base: "identity", title: "Handle Identity on the AT Protocol", siteName: "handle-identity-atproto-26-arxiv", translations: ALL_TRANSLATIONS },
42
+
"arxiv-open-schools": { base: "open-schools", title: "Get Closed Source Out of Schools", siteName: "open-schools-26-arxiv", translations: ALL_TRANSLATIONS },
37
43
};
38
44
39
45
function extractFromTex(content) {
+6
-2
papers/metadata.json
+6
-2
papers/metadata.json
···
76
76
"revisions": 1
77
77
},
78
78
"arxiv-futures": {
79
+
"created": "2026-03-20",
80
+
"revisions": 1
81
+
},
82
+
"arxiv-identity": {
79
83
"created": "2026-03-21",
80
84
"revisions": 1
81
85
},
82
-
"arxiv-futures": {
83
-
"created": "2026-03-20",
86
+
"arxiv-open-schools": {
87
+
"created": "2026-03-21",
84
88
"revisions": 1
85
89
}
86
90
}
+32
-2
papers/papermill.mjs
+32
-2
papers/papermill.mjs
···
26
26
PAPERS_DIR,
27
27
"../system/public/papers.aesthetic.computer",
28
28
);
29
-
const LANGS = ["da", "es", "zh"];
30
-
const LANG_NAMES = { da: "Danish", es: "Spanish", zh: "Chinese" };
29
+
const LANGS = ["da", "es", "zh", "ja"];
30
+
const LANG_NAMES = { da: "Danish", es: "Spanish", zh: "Chinese", ja: "Japanese" };
31
31
32
32
// Map paper dir name to output PDF base name (matching existing site naming)
33
33
const PAPER_MAP = {
···
115
115
base: "plork",
116
116
siteName: "plorking-the-planet-26-arxiv",
117
117
paperId: "plork",
118
+
},
119
+
"arxiv-calarts": {
120
+
base: "calarts",
121
+
siteName: "calarts-callouts-papers-26-arxiv",
122
+
paperId: "calarts",
123
+
},
124
+
"arxiv-futures": {
125
+
base: "futures",
126
+
siteName: "five-years-from-now-26-arxiv",
127
+
paperId: "futures",
128
+
},
129
+
"arxiv-identity": {
130
+
base: "identity",
131
+
siteName: "handle-identity-atproto-26-arxiv",
132
+
paperId: "identity",
133
+
},
134
+
"arxiv-open-schools": {
135
+
base: "open-schools",
136
+
siteName: "open-schools-26-arxiv",
137
+
paperId: "open-schools",
138
+
},
139
+
"arxiv-kidlisp-cards": {
140
+
base: "kidlisp-cards",
141
+
siteName: "kidlisp-cards-26-arxiv",
142
+
paperId: "kidlisp-cards",
143
+
},
144
+
"arxiv-score-analysis": {
145
+
base: "score-analysis",
146
+
siteName: "reading-the-score-26-arxiv",
147
+
paperId: "score-analysis",
118
148
},
119
149
};
120
150