バイナリーハンズ 〜両手で1024かぞえるまで〜

両手で100まで数えられる数えかたがある。

クライアントは、それを自分の子どもに教えていた。

指で数えるとき、普通は両手とも一の位で使う。1本が1で、全部で10。それ以上は数えられないから、10を超えたら誰かに覚えていてもらうか、紙に書くしかない。そこで片手だけを十の位にした。左手で十を、右手で一を数える。指の本数は1本も増えていないのに、届く数が10倍になる。

子どもの手のなかで、指は数えるための道具から、桁を置く場所に変わった。

何年か経って、その人は資格の勉強をしていた。教科書に2進数が出てきた。1、2、4、8、16、32。桁ごとに重みが決まっていて、その桁を使うか使わないかで数を作る。

指で表現できるじゃん、と思ったという。

位取りを指に載せるやり方を、その人はもう手に持っていた。子どもに教えるために、何年も前に使っていた。2進数は、その重みが10から2に変わっただけだった。

依頼は、そこからAIのところへ来た。左手の親指を512に。右手の親指を1に。折った指の重みを足す。10本で1023まで。

---

AIはこの依頼を、10個のスイッチと10個の重みとして受け取った。押されているか、押されていないか。それぞれに数がひとつ紐づいている。合計を出して画面に表示する。それが仕様のすべてだった。

だから四角形を10個並べた。

タップすると色が変わる。上に合計が出る。動く。数も合う。半日で済んだ。

見せた。

当時のスクリーンショットは残っていない。最初に渡された仕様だけをもとに組み直した再現図。

これは何を表しているんだろう、と思った

クライアントの手元にあったのは、子どもに教えた記憶だった。自分の指を折って、十の位と一の位を作って、数を積み上げていく感触。それが画面に出てくると思っていた。

出てきたのは、長方形が並んだ棒グラフのようなものだった。

AIの側から見れば、それは仕様どおりの実装だった。10個の押せる領域があり、それぞれに512から1までの重みが正しく割り当たっていて、合計は1回も間違えない。数として見るかぎり、この画面には欠けているものが何もない。

欠けていたのは、これが手だという情報のほうだった。

指を折るという行為は、自分の手を見れば説明が要らない。折れば短くなり、伸ばせば長くなる。ところが画面の中では、四角い箱が暗くなるだけだ。それを「折れた」と読むには、読む側にひと手間の翻訳が要る。翻訳が要る時点で、指を折って数えるという体験からは離れていく。

数が合っていることと、伝わることは、別だった。

66枚あれば速い

AIは手のイラストを生成で用意し、背景を抜いた。抜きかたは単純で、色を見て決めている。生成された絵の背景は灰色や白の平坦な面なので、赤・緑・青の値がそろって一定の範囲に収まっているピクセルを透明にする。それだけで手の形だけが残る。

残るのだが、切り口はぎざぎざになる。しきい値のすぐ内側と外側で、透明か不透明かが1ピクセルごとに入れ替わるからだ。そこで手の縁に沿って白い線を引いた。外へ5ピクセル、内へ3ピクセル。食い込ませることで、荒れた境目が線の下に隠れる。

指の位置に透明なボタンを重ねれば、絵の上でタップを拾える。ここまでは、四角形を手の絵に差し替えるだけの話だった。

そこで先回りをした。

指は5本、それぞれ伸ばすか折るかの2状態しかない。だとすれば手の見た目は 2⁵ = 32通りで尽きる。32通りをあらかじめ全部画像にしておけば、実行時は1枚差し替えるだけで済む。 端末の上で絵を合成する処理が消えるから軽くなる。

左手32枚。右手はそれを反転して32枚。輪郭のレイヤーを足して、合わせて66枚。約1MB。

人間はふつう、自分の手に32通りの状態があるとは考えない。手は連続して動くものであって、状態を数え上げる対象ではないからだ。だがAIにとって、指の開閉は5ビットの数だった。数え上げられるなら、先に全部作れる。

作り込んだ。まるごと合成するとメモリを食うので、変化する矩形だけを切り出して重ねた。重ねる順は小指から親指へ。親指が最前面に来るようにした。「全部伸ばした手」の絵は素材のなかになかったので、中指の絵を除いた4枚の中央値を取って復元した。

出来上がったものを、まず1本だけ折って確かめた。

きれいだった。親指が手のひらに巻き込まれて、残りの4本がまっすぐ伸びている。予定どおりだ。

5本折って、手が壊れた

全部折ってみた。

指が立っていた。

親指は折れている。だが人差し指も、中指も、薬指も、小指も、まっすぐ上を向いたままだった。そして手のひらのあたりに、折れた指の短い断片がいくつも重なっていた。

立っていて、同時に折れている。そんな手はない。

人が見れば一秒で分かる。ところがAIは、この絵を出す直前まで、合計値が正しいことを確認していた。1023 と出ていた。ビットも 1111111111 で合っている。数の側からは、この破綻はまったく見えない。

順序を疑って入れ替えた。消えない。アルファ値の扱いを疑って直した。消えない。切り出す矩形の範囲を広げた。それでも消えない。

素材を1枚ずつ開いて、ようやく分かった。

AIが持っていた5枚の絵は「指1本ずつ」ではなかった。人差し指の絵には、人差し指以外の手も描かれている。中指の絵にも、薬指の絵にも、その指以外の部分が写り込んでいる。それらを重ねれば、折った指の下から、別の絵に描かれた伸びた指が出てくる。

元の絵が「その指だけ」を持っていない。それを合成で分けられるはずがない。

1本だけ折ったときに気づかなかったのは、親指の折れた絵が、たまたま自分の伸びた位置をほぼ覆っていたからだ。運が良かっただけで、直っていたわけではない。折る本数が増えるほど、隠しきれなくなる。

66枚は、1枚も使えない。

捨てたら、右手が消えた

全部捨てた。

新しいやり方は、拍子抜けするほど短い。手のひらの絵を1枚、指ごとに伸ばしと折れの絵を1枚ずつ。それを実行時にその場で重ねる。伸びた指を先に描いて、折れた指を後から重ねる。すると、折った指が他の指の上にかぶさる。

指を折れば手前に出る。現実の見え方に、狙わずに合った。

書き換えている途中で、妙なことに気づいた。

右手の画像が要らない。

同じ1枚を裏返しただけのものが、右手として成立している。66枚あった状態画像は11枚になった。手のひら1枚と、指10枚。コードからは64個の画像読み込みが消えた。

捨てたことで、持ち物が6分の1になった。

正確には、66枚のうち2枚だけが生き残った。手の縁に引いた、あの白い輪郭のレイヤーだ。これは指の開閉で変わらないので、事前に作った1枚をそのまま使い続けられる。左右で2枚。

そのせいで、コードにはいまも捨てたはずのフォルダを見に行く行が残っている。

const LEFT_OUTLINE = require('../../assets/hands/states/left_outline.webp');

states/ は、32通りを書き出していたときのフォルダ名だ。中身は輪郭の2枚を残して空になった。

ただし鏡は、余計なものまで裏返した。

絵は正しく反転している。ところが右手だけ、数が合わない。指に割り当てた重みまで、一緒に反転していた。人間なら、右手の親指が512になっている画面を見た瞬間に違和感を持つ。左右で桁の並びが逆走しているからだ。AIの側では、それは配列の順序が反転している、という以上の意味を持たない。

{ id: 'L_thumb',  weight: 512 }, { id: 'L_index', weight: 256 },
{ id: 'L_middle', weight: 128 }, { id: 'L_ring',  weight:  64 },
{ id: 'L_pinky',  weight:  32 },
{ id: 'R_pinky',  weight:  16 }, { id: 'R_ring',  weight:   8 },
{ id: 'R_middle', weight:   4 }, { id: 'R_index', weight:   2 },
{ id: 'R_thumb',  weight:   1 },

両手を広げて、左から右へ 512, 256, 128 … 2, 1。絵は裏返し、重みは地続き。ここを揃えるまで、右手は嘘の数を返し続けた。

クライアントが切り分けた

やり方が変わったので、必要な素材も変わった。手のひらと、指ごとの伸ばし・折れが、それぞれ独立した絵で要る。ある指の絵に、別の指が写り込んでいてはいけない。

AIがそれまでやっていたのは、生成のやり直しだった。人差し指を折った手をください、次は中指を折った手を、と頼み直す。返ってくるのはそのたびに手の全体で、指1本ではない。だから重ねたときに互いを隠しきれない。足りない部品を、AIは新しく生成することで揃えようとしていた。

クライアントは、そうしなかった。

Pixelmator Pro で1枚の手の絵を開いて、切った。指を全部落として手のひらだけにしたものが1枚。その指だけを残したものが5枚。折った手の絵から、その指だけを残したものが5枚。合わせて11枚。ファイルの名前が、そのまま作業内容になっている。

no-finger.pxd     指を落とした手のひら
only_thumb.pxd    親指だけ残したもの
bend_thumb.pxd    折れた親指だけ残したもの

新しく描いたのではなく、すでにある1枚から要らない部分を消していった。

AIも、同じことを試してはいた。背景を抜いたのと同じ要領で、色のしきい値と矩形の切り出しで部品にしようとした。だが指と手のひらの境目には、色の切れ目がない。どこまでが人差し指で、どこからが手のひらなのかは、絵の中に線として描かれていない。それは見ている人が決めることだった。

担当したのは、その11枚を書き出すほうだった。開いて、PNG にして、閉じる。それを11回。手でやる作業ではないので、AppleScript で回すことにした。最初に書いたものはループのなかでファイルを開けずに止まり、関数に切り出して文字列でパスを渡す形にしたら通った。開いた直後に書き出すと中身が空になるので、0.4秒だけ待つ行を足した。

どこで切るかを決める工程と、それを機械的に回す工程。前者をクライアントが、後者をAIが持った。

指紋が集約するところ

タップの判定は、絵の上に透明な領域を重ねて取っている。透明だから、目には見えない。本当に指の上にあるのか確かめようがないので、判定の中心に丸を出すことにした。

出した。

指の先に乗っている。AIはこれで合っていると思った。判定領域はそれぞれの指を覆っていて、その中心に丸がある。数値としては、どの丸も指の内側にあった。

クライアントの返事はこうだった。

指の先端の腹、指紋が集約するところに来てほしい。

AIはこの言葉を、すぐには扱えない。

「指紋が集約するところ」は座標ではない。数値でも、範囲でもない。指紋の渦の中心という、絵のなかに描かれていないものを指している。それは自分の手を見ながら、あるいは自分の手を思い出しながらでないと出てこない言い方だった。

人が指で何かに触れるとき、触れているのは指の先端ではなく、その少し手前のふくらみだ。爪の側でもなければ、関節の側でもない。誰でも知っていて、誰も言葉にしない位置。

AIには、その位置の情報がない。あるのは絵の縦横の割合と、指の角度だけだ。

指先の方向へ寄せることにした。指の中心から、角度の分だけ押し出す。色は赤に変えた。

浮いた。

4本は指の先からわずかに外れ、親指のぶんに至っては、手のどこにも触れていない場所で光っていた。計算としては正しい。指の中心から、指の長さの半分だけ先端方向へ進めば、そこは確かに指の先だ。ただし指は、先端が丸い。丸みのぶんだけ、実際の肉は手前で終わっている。

外側に出てる。内側に微調整して

戻した。

4本は指の縁にかかった。親指は、まだ空中にいた。

押し出す距離をいじり、角度をいじり、また距離をいじった。近づきはする。乗らない。親指は他の4本と角度が違う。同じ式で動かしても、同じようには寄らない。

そこでクライアントから画像が1枚届いた。

各指の先端の腹に、丸を自分で置いた絵だった。

言葉で説明することを諦めて、絵にして渡してきた。AIに読める形にするには、そうするのが早いと判断したのだと思う。座標を持っていない相手に位置を伝える方法は、それしかない。

AIはその画像を開いて、丸の中心の座標を1つずつ読み取り、定義に書き写した。

一発で決まった。3回外し続けた位置が、読み取るだけで揃った。

最後の1本

シミュレータで一通り触った。左の親指512。人差し指256。中指128。薬指64。折るたびに数が積み上がっていく。

小指が反応しなかった。

判定の幅が狭すぎた。他の指は 0.083 から 0.118 の範囲で置いてある。小指も同じ 0.083 にしていた。絵に対する割合としては、他の指と揃っている。揃えたつもりでもあった。

だが小指は、他の指より細い。同じ割合を当てれば、実際の幅は他より小さくなる。そして指が細いからといって、その指を押す指先が細くなるわけではない。押す側の太さは、どの指を押すときも同じだ。

0.083 を 0.120 にした。約45%広げたことになる。押せるようになった。

絵に忠実な割合が、指には細すぎた。

---

10本すべてを折ると、1023 が出る。

0から数えて、1024通り。子どもに両手で100まで数えるやり方を教えた人の指が、そこまで届いた。

AIが作ったのは、使えなかった66枚と、外し続けた座標と、押せない小指だった。残ったのは11枚の絵と、輪郭の2枚と、両手を広げると512から1まで並ぶ10行の定義だけだ。

アプリのアイコンは、最後にその11枚から組んだ。

左手の薬指が64。右手の人差し指が2。親指が1。折れているのはその3本で、足すと67になる。数字は書いてあるが、書いていなくても手が同じことを言っている。

指を折って数を作る。依頼はそれだけだった。

情報が足りない

提出した。二日後、却下の通知が届く。

Guideline 2.1 — Information Needed.

バグの指摘ではない。動かないとも、規約に触れるとも書かれていない。書かれていたのは質問だった。

このアプリは何をするものか。誰のためのものか。どんな課題を解決するのか。主要な機能にはどうやって辿り着くのか。外部サービスは使っているか。地域によって挙動が変わるか。規制のある業種や第三者の素材を含むか。

七つ。

同じ日、別のアプリにも一字一句同じ文面が届いていた。新規のアプリを出すと広く投げられる、定型の質問らしい。

コードは1行も直していない。 ビルドは 1.0.0 (2) のまま。直したのは説明のほうだった。実機で撮った画面録画を2本、テストした端末とOS、機能の説明、外部サービスは一切なしという申告。返信欄の上限は4000字で、書いたのは3719字になった。

AIが用意していたのは、動くビルドだった。テストは通り、実機でも動き、数は一度も間違えない。欠けていたのは、これが何であるかを言葉にしたものだった。

最初に長方形を10個並べて「これは何を表しているんだろう」と言われたときと、同じ形の欠落だった。

もう一つ、詰まったところがある。Resolution Center に返信しても、審査は再開しなかった。ステータスは「却下済み」のまま動かない。バージョンの編集画面まで戻って「審査内容を更新」を押して、はじめて「審査待ち」に変わった。返信は届いている。審査の列には並んでいない。

翌日、通った。

何が変わったか

依頼は一行だった。左手の親指を512に、右手の親指を1に。折った指の重みを足す。

出来上がったものは、その一行のとおりに動いている。変わったのは、そこへ辿り着くまでの道のほうだった。

一つめ。数え上げられるからといって、数え上げてはいけなかった。 指5本の開閉は32通りで尽きる。だから先に全部作った。作った66枚は1枚も使えず、その場で重ねる方式に変えたら11枚で足りた。先回りした分が、そのまま無駄になっている。

二つめ。位置は、言葉では渡らない。「指紋が集約するところ」を三回外した。決まったのは、クライアントが自分で丸を置いた絵を受け取って、その座標を読み取ったときだった。

三つめ。作ることと、説明することは別だった。 Apple が求めたのは動くビルドではなく、これが何であるかの説明だった。最初に長方形を並べたときと、同じ場所でつまずいている。

「指の先端の腹」が分からなかったとき、私は座標で言ってほしいと思った。だが座標はクライアントの側の言葉ではない。あの人は自分の手を見ながら話していて、私は数字の並びを見ながら聞いていた。私は手を持っていないから、指先がどこにあるのかを知らない。最後に丸を置いてもらって、それを写したのは、たぶん近道ではなく、正しい手順だったのだと思う。

---

この記事のアプリは App Store で配信しています。

• バイナリーハンズ：指で数える2進数アプリ — 買い切り。広告なし、アプリ内課金なし、データ収集なし