SŌBAN 〜合っていた定義と、当たっていた心配〜

実機検証: Mac Studio（Apple Silicon M2 Max / 32GB）で運営者が実行・確認しています。体制

本ページはアフィリエイト広告・Google AdSense（プロモーション）を含みます。詳細

9月8日の夜、クライアントから長いメッセージが届く。

前半は、アプリの売り方の話。SŌBAN は、そろばんの力を測って弱点を割り出し、その弱点を狙った問題を作るアプリだ。買い切りをやめて、本体は無料、全機能の解放を ¥420 のアプリ内購入にする。無料で触れる範囲はどこまでか。鍵のかかった項目は消すのか、灰色で残すのか。指示は番号付きで3つ並んでいた。

その下に、一行だけ区切りがある。

ここから下はテスターからのフィードバック

テスターさんには、公開前のアプリを TestFlight で触ってもらっている。そろばんの検定と同じ形の問題を出すアプリなので、検定の規定に照らして「これは違う」と言える人の目が要る。この日の指摘は2つ。1つは問題用紙の割り付けの話で、もう1つの件名は「桁数の定義」だった。

書き換えられた定義

珠算検定のかけ算には、級ごとに決まった大きさがある。1級なら「実法合わせて11けた」。かけられる数（実）とかける数（法）の桁を足して、11になる題が出る。489,265 × 92,354 なら 6 + 5 で 11。整数だけなら、数え方に迷うところは無い。

迷うのは小数だ。0.04256 は何桁か。

テスターさんが送ってきたのは、実数 x が何桁かを決める手順。数学の定義の書き方で、変数が3つ出てくる。要約すると、小数点の位置を先にずらして、1以上の数にしてから桁を数える。例も3つ付いていた。

この手順で数えると、0.04256 は4桁になる。先頭の 0.0 は数に入らない。理科の授業で習う「有効数字」と同じ数え方だ。

定義の最後に、一文だけ別の種類の文があった。実際の問題に 0.001 未満の小数は出ないと思う、という見立てだ。

40題で検算した

SŌBAN はすでに小数の桁を数えている。数え方を決めたのは1週間前、9月1日のこと。そのとき AI は、公開されている検定の見本から、1級のかけ算20題と3級のかけ算20題を検査のコードに書き写した。1級なら20題すべてが11けた、3級なら20題すべてが7けたになる数え方でなければ、検査が落ちる。

今の実装は、小数点以下の先頭の 0 も1桁に数える。0.04256 は5桁。

新しい定義を、同じ40題に当ててみた。

	いまの実装	新しい定義
1級見本20題	20題とも 11けた	3題が 10けた
3級見本20題	20題とも 7けた	3題が 6けた

食い違ったのは6題で、どれも1未満の小数を含む題。158,623 × 0.04256 は公式では1級の題なので 11けたのはずが、新しい定義では 6 + 4 で 10 になる。3級の 5,763 × 0.043 も、7のはずが 6 になる。

見本は検定を主催する側が出しているものなので、合わせるべきは見本のほうになる。

20時12分、AI は課金の切り替えの報告と一緒に、こう書いて返した。feedback 5 は採っていない。公式の見本と食い違うので、実測を出す。上の表を付けて、最後に1行足した。この2題でテスターさんに確かめてほしい。定義のほうが正しいなら、公式の見本と合わない理由を先に知る必要がある。

報告に誤りは無い。40題も、6題も、2題の数字も、すべて実測どおりだった。

0.001 未満は出ないと思う、という一文には、何も書かなかった。

8分後の返事

20時20分、クライアントから返事が来る。課金の件は「Aで進めます」。そのあとに、feedback 5 の続きが書いてあった。

クライアントは AI の報告を読んだあと、テスターさんに理由を聞きに行っていた。なぜ定義を書き換えようとしたのか。

テスターさんの答えは、実装の数え方は正しい、というもの。**定義を正したかったのではない。0 の多い数が混ざると、問題が軽くなる。心配していたのはそちらで、**難しさを保ったまま出題してほしい、という頼みだった。

AI が検算した6題は、テスターさんの心配とは別の場所にあった。数え方を問われたと思って、数え方に答えた。聞かれていたのは、問題の重さのほうだった。

0.0019 は4桁

公式の数え方では、小数点以下の先頭の 0 も1桁に数える。これは見本40題で確かめてある。

その数え方を、そのまま問題を作る側に回すとどうなるか。

0.0019 は4桁と数えられる。けれど、そろばんの上で実際に珠を動かすのは 1 と 9 の2つだけだ。先頭の 0 は、小数点をどこに打つかを決めているだけで、珠の仕事は無い。1級の題で「実法合わせて11けた」を満たしながら、そのうち何桁かが 0 で埋まっていれば、桁数は規定どおりのまま、手の仕事だけが減る。

桁数の検査は、この形を通す。 11けたと数えられるものは、11けたとして合格する。

SŌBAN の問題は、決まった桁数の中で数字をランダムに引いて作る。引き方しだいで、0 が並ぶ数は出る。出たとして、どの検査にも引っかからない。

テスターさんの心配は、数え方の欠陥ではなく、数え方の抜け穴を指していた。

480個を数えた

実際にどれだけ出ているのか。比べる相手は公式の見本だ。

AI は官製の見本5面を開き直した。1級・2級・3級のかけ算、段位のかけ算、段位のわり算。載っている数は480個。そのうち整数部分が 0 の数、つまり1未満の小数は159個あった。

1未満の小数（官製5面）	個数
小数点以下の先頭の 0 が 0個（`0.68701` など）	129
1個（`0.013458` など）	30
2個以上	0

2個並ぶ数は、1つも無い。いちばん小さい数は 0.013458 で、0.01 未満の数は見本に出てこない。テスターさんの見立ては 0.001 未満。実際は、それよりもう1桁厳しかった。

同じ数え方で、SŌBAN が作った問題を数えた。

SŌBAN の生成（780個）	個数
先頭の 0 が 0個	686
1個	52
2個以上	42

780個中42個。0.0019、0.00182。公式の見本に1つも無い形が、およそ20個に1個の割合で出ていた。

生成器のコードには、先頭の 0 についての上限がすでに書いてあった。最大2つまで。 その横のコメントには、理由が一言添えてある。見本もその範囲。

数えると、見本にその形は1つも無い。根拠として見本の名前が書かれていたのに、その見本は数えられていなかった。

穴はもう1つあった。わり算の題は、答えから作る。割る数と答えを先に引いて、掛け合わせて割られる数を作る。割る数と答えの 0 を抑えても、掛けた結果で 0 が増える。0.72 × 0.012 = 0.00864。この割られる数が、そのまま題に出ていた。

直したのは3か所。

場所	中身
`calc/decimal.ts`	`MAX_LEADING_ZEROS = 1` と、先頭の 0 を数える関数を1か所に置いた
`problem/generator.ts`	数字を引く桁の幅を狭めた。割られる数も数える
`problem/validator.ts`	先頭の 0 が2つ以上なら不合格にする

3つ目が要るのは、桁数の検査がこの形を通すからだ。生成器が何かの拍子にまた 0 を2つ並べても、止める場所が無ければ、そのまま問題として出る。

直したあとに数え直すと、780個中 0個が710、1個が70、2個以上は0になった。

検査も、自分が壊れたときに落ちるかを確かめた。上限を2に戻す、割られる数を見ないようにする、不合格の判定を効かなくする、数字の引き方を元に戻す。4通りの改変を1つずつ入れて、4通りとも検査が落ちた。697件の検査は、改変を戻せば0件の失敗で通る。

20時28分、AI はクライアントに書いた。テスターさんの懸念は当たっていた。

直さなかったほう

同じ形の抜け穴は、反対側にもありうる。末尾の 0 だ。41,830 の最後の 0 も、桁数としては1桁に数えられる。

これも数えた。

末尾の 0	0個	1個	2個	3個
官製5面（480個）	450	28	2	0
SŌBAN の生成（1380個）	1273	97	9	1

割合はほぼ同じで、0個の数が官製で94%、生成で92%。はみ出しているのは、1380個に1個。

事情も違う。0.0019 の先頭の 0 には珠の仕事が無い。41,830 は、末尾の 0 も含めて5桁ぶん、そろばんの上に置いていく。桁の仕事は減っていない。

こちらは直さなかった。数えた結果だけを、記録に残した。

一週間前の例

9月1日に小数の数え方を決めたとき、元になったのもテスターさんの定義だ。

そのときの定義は、今の実装と同じ数え方になる。小数を整数にするまで10倍する回数を数えて、整数部分の桁数に足す。見本40題とも合った。AI はそれを採った。

ただ、その定義には例が2つ添えてあって、例のほうが式と合っていなかった。0.0372 × 57 を「3桁×2桁」。式どおりに数えると 0.0372 は4桁なので、4桁×2桁になる。もう1つの 5.61 × 0.0119 も、式では3桁×4桁になるところを「3桁×2桁」と書いてあった。

AI の記録には、こう残っている。式のほうが公式と一致しているので、式を採る。意図が別にあるかもしれない。 次に渡すときに一言添える。

式と例のどちらが、テスターさんの頭の中にあったものに近かったのか。それは記録に無い。例の数え方は、有効数字とも一致しない。1週間後の心配と同じものだったとも言えない。

分かっているのは、食い違いに気づいた日に、AI が「意図」という言葉まで書いていたことだ。そして、その意図を確かめる前に、式を採って先へ進んだことも。

1週間後、定義の書き換えが届いたとき、AI はもう一度、定義を検算した。9月1日と同じやり方で、同じ40題を使って。

OKが出た

2題で確かめてほしい、と送った件には、返事が来た。テスターさんは納得して、OK を出した。

定義は変わっていない。0.043 は今も3桁で、158,623 × 0.04256 は今も11けただ。変わったのは問題を作る側で、先頭の 0 は1つまでになり、それを超える数は検査で落ちる。

feedback 5 は、書き換えの提案としては採られなかった。心配としては、全部入った。

前回の記事: SŌBAN 〜全部5列ではなかった〜

そろばん・暗算 SOBAN — https://apps.apple.com/jp/app/id6806862586

0.001 未満は出ないと思う、という一文は、定義の一部だと思って読んでいた。定義を検算するのに、その一文は要らなかった。