軽やかに

コンピュータ科学の言葉で言えば、軽さは見た目の優雅さではなく、遷移コストの低さである。状態Aから状態Bへ移るとき、必要な計算量・メモリ・待ち時間が少なければ、システムは軽く振る舞う。物語の身体描写でも似たことが起きる。着地までのステップ数が少なく、余分な抵抗の記述がなければ、読者は動作を軽いと感じる。副詞はそのコスト表示のラベルになる。中身のアルゴリズムを決めるのは、前後の動詞と障害物の有無である。ラベルだけ貼って中身が重いと、UIで高速と書いておきながら画面が固まるのと同じ違和が残る。語形そのものも、この分担を映している。軽いの語幹に様態の接尾辞やかが付いた軽やかは、程度を測る軽くとは仕事が違う。軽くは量の目盛りを、軽やかには遷移の質を記述する。か・る・く の三拍に対して、か・る・や・か・に は五拍。二拍ぶん長い形が、量ではなく様子を運んでいる。

全文検索やUIのレスポンスでも、軽いは主観だが、背後には測定可能な指標がある。レイテンシ、フレームレート、キャッシュヒット率。創作では測定器はないが、文の長さと修飾の密度が近似指標になる。長い理由説明のあとにこの副詞を置くと、ラベルと実測が食い違う。立つ、渡る、笑うといった短い動詞の直前に置くと、コストの低さが文の形と一致する。型としては、障害を一文で提示し、次文で低コストな遷移を見せる二段構えが読みやすい。障害の種類を明示すると、軽さの対照が立つ。ぬかるみのあとの乾いた板、混雑のあとの空いた通路——対照があると、副詞は説明を重ねなくても効く。

興味深いのは、軽さが情報の欠落としても実装される点だ。詳細を描かないこと自体が、摩擦の省略になる。靴音、呼吸、服の重さを書かないと、キャラは自動的に軽く動く。これは圧縮に近い。必要な特徴量だけ残し、他を落とす。落としすぎるとキャラが幽霊になり、残しすぎると重量級になる。どの特徴量を残すかが、作品の物理法則になる。編集距離の比喩で言えば、重い動作と軽い動作の差分は、障害語彙の有無数語で足りることも多い。差分を一文に閉じると、読者は前後を補完してくれる。

もう一つ、実装の側から見て示唆的なのが予算という考え方だ。毎秒六十枚の描画を保つなら、一枚に使える時間は十六ミリ秒ほどしかない。この予算を超えた処理は、どれほど正しくても引っかかりとして表面化する。文章にも似た予算がある。一つの動作に読者が割く注意の量は、場面の緊張度ごとにおおよそ決まっていて、予算内に収まれば軽く、超えれば手間取って見える。予算を守る方法は二つしかない。処理そのものを削るか、事前に済ませておくかである。必要なデータを先に手元へ置いておく先読みと同じで、鍵を開けておいた、荷物は先に降ろしてあったと一行前に書いておけば、当の動作は予算の内側に収まる。準備を前倒しした分だけ、本番の一行が軽くなる。

実務では、同一場面でこの副詞を連発しない方がよい。一度ラベルを貼ったら、あとは動詞の選択と文の短さで軽さを維持する。システムが最適化されたあとにログへ fast と何度も書く必要がないのと同じだ。読者は最初の遷移でコスト感を学習し、以降はパターンを外挿する。外挿を裏切るとき——突然つまずく、息が上がる——にだけ、重さの語彙を足す。軽さは常時表示のステータスではなく、差分として効くフラグである。フラグを立てる回数を減らすほど、その一回の遷移は記憶に残る。