ダイソーのデジタル時計をNTP同期時計に改造する（前編）

Last updated at 2026-10-13Posted at 2026-10-12

↑ こちらのホワイトを使用しました。ブラックも中身は同じだと思います。

ボタンは４つ

時刻の合わせ方は、次のとおり。

「M」ボタンを長押しし、「時」を設定します。
「時」が点滅、「△」または「▽」ボタンで設定します
「M」ボタンを押し、同じように「分」「年」「月」「日」を順番に設定します。
「分」→「年」→「月」→「日」が点滅、「△」または「▽」ボタンで設定します
「M」ボタンを押し、時刻設定をすべて確定します
- 設定時に△、▽ボタンを長押しすると数字が「早送り」または「早戻り」します
- 約20秒ボタン操作がない場合、通常表示に切り替わります

00秒にセットする機能は、用意されていないようです。
では、どのタイミングで00秒にセットされるのでしょうか？

考えられるのは、最後に「M」ボタンを押し、時刻設定を確定したタイミングです。
しかし、この時計は、そのタイミングではありませんでした。
色々なパターンで試行錯誤するも、どのタイミングで00秒にリセットされるのか、さっぱり分からないので、AIに助けてもらうことにしました。

^{00秒にリセットするタイミングが分からなければ、NTP同期して時刻を合わせることができませんので・・・。}

前編は、

00秒にリセットされるタイミングをつかむ
マイコンからこの時計のボタン操作する回路を組む

で、AIとの会話が中心です。

『マイコンから時計のボタンを操作するハードを作成』までジャンプする。

AIに頼る

取説をAIに読んでもらい、「00秒にセットされるタイミング」を調べる手順を考えてもらいました。

私の質問
00秒に合わせる方法が知りたい

AIの回答
（中略）

手順

電池投入から完了まで、ボタンを押すたびに秒を書き留めてください。
記録する操作の例は次のとおりです。
1. M長押し(設定モードに入る)
2. 時を変更(△ / ▽ を押すたび)
3. M(時 → 分へ進む)
4. 分を変更(△ / ▽ を押すたび)
5. M(分 → 年へ進む)
6. 年、月、日の各ステップの M
7. 最後の M(通常表示に戻る)
そのうえで、通常表示に戻った後、最初に表示が切り替わった秒を書いてください。
1回の設定に、10〜15か所の秒が並ぶはずです。切り替わりの秒と一致する操作があれば、それが起点です。

私の質問
何度やっても、どこが起点で00秒になるのか、さっぱり分かりません。
このPCにwebカメラを接続したら、あなたはこの時計の表示を直接認識することができるのでしょうか？

AIの回答
できます。ただし、リアルタイムで見張ってもらうのではなく、撮影した動画をあとから解析する形が現実的です。
（中略）
まず動画を撮って、ファイルの場所を教えてください。ffmpegが入っていなければ、こちらでインストール手順をご案内します。

私の質問
できれば時計のボタン操作もあなたにやってもらいたいのですが、リアルタイムで時計を見るのが難しいと無理ですかね？

AIの回答
無理です。理由は2つあります。

私は時計のボタンを押せません
- 物理的なボタンを押す手段がありません。
- 使えるのは、Mac の操作(ブラウザやシミュレータ、ターミナル)だけです。
- ボタンを押すロボットや、Mac につないだ Arduino・ESP32 のような機器があれば、話は別です。
リアルタイムに見ながらの判断も、精度が足りません
- 撮影 → 読み取り → 判断の1サイクルに数秒かかります。
- 「表示が切り替わった瞬間にボタンを押す」ような操作は、私には間に合いません。

現実的な分担

ボタン操作と撮影はあなたが行います。
- 動画の解析、つまりどの操作が起点になっているかの特定は、私が行います。

1回の撮影で、電池投入から設定完了まで、ボタン操作をすべて含めてもらえれば、起点はかなり絞れると思います。
（中略）
まず動画撮影から試すことをおすすめします。

私の質問
物理ボタンを押せないことは理解しています。esp32などのマイコンでボタンを押す操作を、シリアル経由で操作できるようにすれば可能でしょうか？

AIの回答
それなら可能です。私がシリアル経由でマイコンに指示を出し、マイコンがボタンを押す形にすれば、タイミングの管理はマイコン側でできます。

構成案

（中略）

この構成でできること

起点の特定が、全操作の自動化と精密な記録で確実になります。
起点が見つかったら、そのタイミングに合わせて自動で設定できます。たとえば、基準の時刻(NTP など)の 00 秒に合わせて、その操作を実行できます。

（中略）

私の質問
しかし、時計の表示をリアルタイムで認識できなければ、ボタン操作をお願いしても無意味では？

AIの回答
いいえ、無意味ではありません。リアルタイムで表示を認識する必要がないからです。

リアルタイムが必要ない理由

ボタンを押すタイミングは、マイコンがmillis()で正確に管理します。私が画面を見て判断する必要はありません。
私の役割は、「実験の設計」と「結果の解析」です。
1. 私が操作の手順(何秒後に何を押すか)を決めます。
2. マイコンが、その手順を正確なタイミングで実行し、ログを返します。
3. 表示が切り替わった時刻を、動画か光センサで記録します。
4. 私がログと突き合わせて、起点を特定します。
5. 次の手順を決めて、また実行します。
1回の実験ごとに数分かかっても問題ありません。

今までの手作業との違い

手作業だと、ボタンを押す秒と、基準時計を読む秒が、それぞれ1〜3秒ぶれていました。
マイコンなら、押すタイミングの誤差はミリ秒以下です。ぶれが消えるので、起点が見えるようになるはずです。

（中略）

マイコンから時計のボタンを操作するハードを作成

NTP同期時計に改造すると決めた時から、このハードは作成する必要があります。
まだ、00秒リセットのタイミングが分かっていませんが、AIに操作してもらうために、先にハードを作成します。

4つのボタンの仕組み

時計を分解して、4つのボタンがどうなっているのかを確認しました。

（一番左が「M」、2番目の＋が「△」、その右が「▽」ボタン）

各ボタンの上下を短絡させれば「押した」ということは明らかですが、テスターの導通モードでいくら調べても、どの箇所も「ピー」とは鳴りません。
^{ところどころハゲているのは、テスターリードを当てるために削った跡です。}

黒い配線はカーボン印刷のようで、抵抗値を測ると500Ω程度でつながっていることを確認しました。（テスターのメーカー・型番にも拠るが、概ね100Ωを超えると導通ブザーは鳴りません。）

4本の配線に、4つのボタンがリング状につながっています。

配線の整理

ネット	つながっている電極
A	M上側と −上側
B	M下側と SNZ下側
C	+上側と −下側
D	+下側と SNZ上側

各ボタンが、どのネットを短絡するかは、次のとおり。

ボタン	短絡するネット
M	A – B
+	C – D
−	A – C
SNZ	B – D

これが分かったので、配線が楽になります。

必要な接続点は4つだけ(A、B、C、D のそれぞれ1か所)
4つのボタンは、フォトMOSリレーを次のようにつなげば、すべて再現できる
- M： A と B の間
- +： C と D の間
- −： A と C の間
- SNZ： B と D の間
各ボタンの電極に個別に配線する必要はない

作成したハードが ↓これです。
（回路図の詳細は、後編で説明します）

ブレッドボードに刺せるESP32が手元になかったので、無印Picoに Micropython でプログラムを書きました。

電池を外す/はめる（時計リセット）の操作もできるように、電池の+配線の途中にもフォトMOSリレーを入れてあります。

シリアルからどのボタンを操作したのかが分かるように、各ボタンに対応したLEDを付けました。LEDは左から、Mボタン、+ボタン、-ボタン、SNZボタン、電源（遮断すると点灯）です。
また、手動でもボタンを押せるように、タクトスイッチも付けてあります。

『まとめ』までジャンプする。

AIに操作方法を教えて操作してもらった

私の質問
回路を組みました。
手元にesp32がなかったので、raspberry pi pico にmicropythonでプログラムを組みました。
テストは完了しています。
シリアルポートは "/dev/cu.usbmodem1201"
コマンドは次の通り（行末リターンが必要）

コマンド	ボタン	押す/離す
"M 1"	M	押す
"M 0"	M	離す
"U 1"	+	押す
"U 0"	+	離す
"D 1"	-	押す
"D 0"	-	離す
"P 0"	電池	電池切り離す
"P 1"	電池	電池戻す

長押しは、"M 1"、ウエイト、"M 0"と、コマンド送信側で制御する。
電池を切り離し、戻した時に、時計のリセットに2秒ほどかかるが、そのウエイトはコマンド送信側で制御する。

以上を理解できますか？
理解できたら、練習しましょう。

AIの回答
理解しました。Pico(MicroPython)がシリアルで受けるコマンドは、次のとおりです。

ボタンは、M / U / D に 1(押す)または 0(離す)を付けて、行末にリターンを付けます。
P 0 で電池を切り離し、P 1 で戻します。
長押しや、電池を戻した後の約2秒の待ちは、すべて私の側のスクリプトで制御します。

まず、Mac 側でポートと Python の環境を確認します。

＜何やら裏でコマンドを実行＞

ポートとpyserialが使えることを確認したので、制御用の小さなスクリプトを作り、まず影響の少ないMボタンの短押し操作(アラーム時刻表示への切替)を試します。

Mac から Pico への接続と、ボタンの操作ができました。

（中略）

練習の次の段階(提案)

M の長押し(2.5秒)で、設定モードに入れるか確認します。時が点滅すれば成功です。
電池の切り離しと復帰を試し、時計が初期化されて 12:00 になるかを確認します。
その後、「電池を戻した時刻 → 設定のどの操作で秒が0になるか」の実験に進みます。

時計の表示が期待どおりに動いたか教えてください。次は、M の長押しから試してよいですか?

私の質問
Mの長押しを試してください

＜何やらPythonスクリプトを実行している＞

AIの回答
M を約2.5秒押し続けて離しました。Pico からは、押す・離すの両方に ok! が返っています。

時計の表示はどうなりましたか?

「時」が点滅して、設定モードに入っていれば成功です。
何も変わらなければ、押している時間が足りないのかもしれません。その場合は、3〜4秒に延ばして、もう一度試します。

設定モードに入っていたら、次は △(U)で時を1つ進める操作を試して、時計が応答するかを確認しましょう。

私の質問
成功しています

AIの回答
次の順に、間を空けて実行します。

M の長押し(設定モードに入る)
3秒待つ
U を1回(時が +1)
3秒待つ
D を1回(時が −1、元に戻る)

＜何やらPythonスクリプトを実行している＞

実行しました。3つの操作とも、Pico から ok! が返っています。

時計では、次のように見えましたか?

M の長押しで、「時」が点滅した
U で、時が +1 になった
D で、時が −1 になって、元の時刻に戻った

どれかが期待どおりでなければ、教えてください。全部成功なら、次は電池の切り離しと復帰(P 0 と P 1)を試します。

私の質問
OKでした

AIの回答
電池の切り離し(P 0)と復帰(P 1)を試します。切り離しを1秒保ち、復帰後に2秒待ちます。時計が初期化されて、全点灯のあとに 12:00 になれば成功です。
＜何やらPythonスクリプトを実行＞

実行しました。Pico からは、どちらも ok! が返っています。

時計は、電池を切り離したとき消灯して、復帰のとき「ピッ」と鳴って全点灯し、12:00 に戻りましたか?

成功していれば、準備は完了です。次は、本題の「どの操作で秒が0になるか」の特定に進めます。
（中略）

私の質問
成功しています

AIの回答
ボタン操作と電池の制御が、すべて動くようになりました。

ここからの実験の流れ

Mac のスクリプトが、決まった時刻に操作を実行し、時刻をログに残します。時計の表示が切り替わった瞬間は、別の方法で記録して、ログと突き合わせます。

表示が切り替わる瞬間を記録する方法(どれか選んでください)

動画: スマホか Web カメラで、時計の表示と、Mac の画面(ミリ秒まで出るストップウォッチ)を一緒に映します。私が動画のフレームを解析します。手軽ですが、1回の実験ごとに動画のやり取りが必要です。
光センサ: Pico のアナログ入力に、フォトトランジスタか CdS セルをつないで、液晶の分の桁に当てます。切り替わりを Pico が検出して、時刻を自動で記録できます。実験を繰り返せて、いちばん精度が高いですが、部品と配線が増えます。
目視: 今までと同じく、あなたが基準時計と見比べます。精度は、1〜2秒の誤差が出ます。

最初の実験の案

Mac の時刻に合わせて、P 1(電池を戻す)を実行する。
何も操作せずに、約70秒放置して、12:00 → 12:01 の切り替わりを記録する。
その後、M の長押しなどの個別の操作を、順番に実行して、そのたびに切り替わりのタイミングが変わるか記録する。

動画で進めるなら、どの機器で撮影しますか(スマホ、Mac の内蔵カメラ、外付け Web カメラ)? また、Mac の画面に出すストップウォッチは、私がブラウザで用意します。

私の質問
外付けのwebカメラを準備します。
ストップウォッチを作成してください

＜ブラウザが開き、ミリ秒まで表示する時計が表示された＞

AIの回答
基準用の時計ページ clock.html を作って、Mac の既定のブラウザで開きました。

表示内容

黒い背景に、白い文字で、時:分:秒.ミリ秒を大きく表示します(例: 14:32:07.532)。
時刻は、Mac のシステム時計から取っています。スクリプトのログの time.time() と同じ時計なので、そのまま比較できます。
画面の下に、日付も小さく出しています。

撮影のときのお願い

ブラウザは全画面にして、文字がなるべく大きく映るようにしてください。
時計の本体と、この画面が、同じ画角に収まるように置いてください。
ブラウザの画面が見つからない場合は、Finder から clock.html を直接開いてください。

次の手順

時計とこの画面を一緒に映して、動画の撮影を始めてください。
撮影を始めたら教えてください。私が電池を戻す(P 1)ところから、実験のスクリプトを実行します。
撮影が終わったら、動画ファイルの場所を教えてください。

最初の実験は、「電池を戻して、約70秒何も触らず、12:00 から 12:01 に変わる瞬間を記録する」ものです。

私の質問

ｗebカメラを使っています。文字が大きすぎて画面に収まりません

AIの回答
文字が大きすぎて、カメラの画角から切れていますね。文字を小さくします。

文字の大きさを、画面幅の約半分(18vw → 9vw)にしました。ブラウザで再読み込み(⌘R)してください。

（中略）

調整できたら、撮影を始めてください。始めたら教えてもらえれば、電池を戻すところから実験を実行します。

私の質問

Quick Timeで録画します

AIの回答
画角は、ほぼ大丈夫です。基準の時計の「分:秒」は読み取れます。ただ、時計本体が左下で少し切れているので、できれば本体の表示全体と「AM」が入るように、カメラを少し左下に向けてください(基準の時計は、秒の桁が見えていれば十分です)。

実験のスクリプトを先に準備します。

実験1のスクリプト exp1.py を用意しました。

内容

5秒待つ(録画の頭出し用)
電池を切り離す(P 0)
2秒待つ
電池を戻す(P 1)
何も操作せずに、150秒放置する(分の切り替わりを2〜3回見るため)
各操作の時刻を、exp1_log.json に保存する

あなたにお願いすること

カメラの画角を調整する(時計の表示全体が入るように)。
QuickTime で録画を始める。
録画を始めたら、「開始」と教えてください。すぐにスクリプトを実行します。
約3分間、画角を動かさずにおきます。
スクリプトが終わったら、録画を止めて、動画の保存場所を教えてください。

準備ができたら、「開始」と教えてください。

＜カメラ画角は特に変更せず、Quick Timeで録画を開始した＞

私の質問
開始

（回路のLEDが光るので、なんらか操作していることは確認できる）

AIの回答
実験1のスクリプトが終わりました。記録した時刻は次のとおりです。

操作	Mac の時刻
P 0(電池を切り離す)	22:12:55.337
P 1(電池を戻す)	22:12:57.392
終了	22:15:29.450

録画を止めて、動画の保存場所を教えてください。受け取ったら、フレームを切り出して、時計の表示が 12:00 → 12:01 → 12:02 と切り替わる瞬間を、基準時計の時刻と一緒に読み取ります。

＜Quick Timeの録画を停止、名前を付けて保存＞

私の質問
/Users/nak435/Downloads/test1.mov

AIの回答
動画は 60fps で約187秒です。まず全体の画角を確認します。
＜何やらコマンドを実行＞

全体は読み取れます。時計は 12:20 → 12:00(電池復帰後)→ 12:01 → 12:02 と切り替わっています。切り替わりのフレームを、60fps で正確に特定します。

起動の3つのイベントは、動画の 24.7秒、27.1秒、29.0秒に検出されました。分の切り替わりは変化が小さいので、しきい値を下げて探します。

切り替わりは動画の約 88.0秒と 148.0秒にあり、ちょうど60秒間隔です。各フレームの基準時計を読み取るため、前後のフレームを並べます。

フレームから読み取ったデータを整理すると、「12:00→12:01」と「12:01→12:02」の切り替わりはいずれも基準時計の:58.65秒で発生しており、60.0秒間隔で安定していることが確認できました。次は音声データから起動時のピッ音のタイミングも調べます。

音声は、部屋の音が多く、起動時のピッ音を拾えなかったので、映像だけで判断しました。

実験1(電池を戻して、何も操作しない)の結果

項目	値
P 1(電池を戻すコマンド)の時刻	22:12:57.39
全点灯が映った時刻(動画)	22:12:57.8 前後
12:00 → 12:01 の切り替わり	22:13:58.65
12:01 → 12:02 の切り替わり	22:14:58.65

切り替わりの間隔は、ちょうど 60.0 秒です(精度は±0.05秒程度)。この時計の分の刻みは正確です。
切り替わりは、P 1 から約 61.3 秒後です(全点灯からでは約 60.9 秒後です)。電池を戻した後、約 1.3 秒たったところで、秒のカウントが始まっているように見えます。
つまり、電池を戻した時点で、秒の位相がほぼ決まります。何も操作しなければ、分の切り替わりは、「P 1 の時刻 + 約 61.3 秒」の位置になります。

（中略）

録画の自動化について

毎回 QuickTime で録画してファイルを渡してもらう方法は、繰り返しに向きません。
Mac から、ffmpeg で Web カメラを直接録画して、実験のスクリプトと同時に動かし、解析まで自動で行えます。ターミナルかこのアプリに、カメラのアクセス許可が必要になるかもしれません。

自動化で進めてよいですか? それとも、今までどおり QuickTime の録画で進めますか?

私の質問
自動で進めてください。ただし、時計の表示にバックライトが付いていないため、暗くて読み取れない可能性があります。それを先に確認してください。

AIの回答
まず、Web カメラの一覧を確認して、1枚撮ってみます。

暗さについて(先に確認できた分)

今回の動画(部屋の照明のみ、バックライトなし)では、時計の数字は、全フレームではっきり読み取れました。12:00 → 12:01 の切り替わりも、60fps のフレームで追えています。
今の照明と、カメラの位置・角度を変えなければ、暗くて読めない心配はなさそうです。夜間に実験するときは、照明を同じ明るさにしてください。

カメラの自動録画は、まだ動いていません

ffmpeg で、Web カメラ(EMEET SmartCam C960 2K)を直接録画しようとしたところ、2分以上応答がなくなりました。止めてあります。
原因として考えられるのは、次のどちらかです。

カメラのアクセス許可の確認ダイアログが、Mac の画面のどこかに出ていて、許可を待っている。「"Claude"(または "ターミナル")がカメラにアクセスしようとしています」という内容です。
QuickTime などの別のアプリが、カメラを使っている。

（中略）

その後、システム設定 → プライバシーとセキュリティ → カメラに「Terminal.app」を追加したことで、AIがffmpegのコマンドを実行できるようになりました。

AIは、その後、1時間以上にわたり、時計の操作を行なっています。
途中では、検証した動画から、その瞬間を切り出した画像を示しながら、「どういった状況」かを説明する場面もありました。

（下の画像は1分進んでしまった時）
『1分ズレが発生しており、秒の切り替わり位相はほぼ正確なものの表示分が+1になっています。原因を特定するため、最後のUシグナル直後の表示内容を確認します。』
『原因が判明しました。設定モードに入るまでの85秒の間に分が「00」から「01」へ進んでいたことが問題でした。電池の入れ直しを設定モード直前に行い、切り替わり時間を実測の60.17秒に修正します。』といった具合に。

実験を重ねた結果、ついに、00秒がリセットされるタイミングをつかみ、時刻を合わせる「手順」を確立してくれました。

AIの回答
秒の合わせ込みが成功しました。

動画で確認した結果です(基準時計はミリ秒表示のページ)。

時刻	時計の表示
23:27:59.66	11:27 PM
23:27:59.81	11:28 PM に切り替わり始め
23:28:00.03	11:28 PM(完全に切り替わった)

分の切り替わりが、基準時計の :00 の約 0.1〜0.2 秒前で、表示の分も合っています。

確定した手順

目標の分の境界 B を決める。
設定の約4秒前に、電池を入れ直す(12:00 AM、分は 00)。
M の長押しで設定モードに入り、時を U で合わせる。
M で分へ進み、U で、目標の1つ手前まで進める。
B の約 60.1 秒前に、U を1回押す。この瞬間に、秒が 0 に戻る。
20秒操作しないと、自動で通常表示に戻る。

残っていること

年・月・日は、まだ設定していません(電池を入れ直した直後の値のままです)。今回の検証には含めていません。
12時間表示です(24時間表示にするなら、通常表示で U を長押しします)。
精度は、おおむね ±0.2 秒です。このあとは、時計自体の月差(±60秒)が主な誤差になります。
Mac の時計が正確であることが前提です(ネットワーク時刻同期を使っているか、確認してください)。

（中略）

私の質問
今のテストは、電池を外すことでリセットするところから始めていますが、私がやりたいことは、マイコンでNTP同期して取得した正確な時刻を基準に、この時計の秒を00に合わせることです。
1日に1回それを実行して、常に誤差数百ミリ秒としたい。
この手順も確認してください

AIの回答
ご要望(マイコンで NTP 同期した正確な時刻を基準にして、1日1回、時計の秒を 00 に合わせる)に合わせて、電池を外さない手順を設計して、確認します。先ほどの手順は、電池の入れ直しで「12:00 AM・分は 00」という既知の状態を作るものでした。日次では使えません。

日次の手順(電池を外さない)

時計は、前回の同期から、時間とともに数秒ずれているだけです。分の値は、その瞬間の本当の分と同じ表示になっています(ずれは数秒なので、分の途中の「:40」あたりなら、表示は確実に正しい分です)。
本当の時刻で、分 m の :40 に M を長押しして、設定モードに入り、M で分の設定へ進みます。このとき、時計の分は「m」と分かっています。
分 m の :59.9(= 次の境界 B の 60.1 秒前)に、U を1回押します。表示が m+1 になり、秒が 0 に戻って、B ちょうどに m+2 へ切り替わります。
準備から最後の U までは、約15秒です(設定モードの20秒制限に収まります)。時は触りません。
ただし m = 59 だと、分が 59 → 00 に回り込んで、時を +1 する必要があります。この回は、次の分に延期します。

この手順を、電池を外さずに、実際に実行して確認します。

＜裏で実験を再開＞

AIの回答
実行完了、Mの長押しから最後のUまで16.5秒で20秒の制限内に収まりました。次に動画で分の切り替わりを確認します。

（時計を見ていたので、気付いていたことを指摘）

私の質問
これも1分ずれています

AIの回答
ご指摘を受けて、動画で確認します。基準時計の 23:40:00 の瞬間に、時計が何を表示しているかを見ます。
＜何やらコマンドを実行＞

録画ファイルは、まだ書き込み中でした(いまの時刻が 23:40:20 で、+30秒の先は未生成です)。範囲を縮めて、取り直します。
＜何やらコマンドを実行＞

原因が判明しました。前回の+1分のずれが修正前の時刻表示にすでに残っていたため、設計通りに+1を加えた結果ずれが継続していました。まず今回は分を変えずに秒だけ合わせる補正（Uの後にD）を行い、その後で通常手順（最後にU1回）を再検証します。
＜何やらコマンドを実行＞

補正の実行が終わりました。目標は、23:44:00 の切り替わりで、表示が 11:44 PM になることです(1分の誤差が消えること)。動画で確認します。
＜何やらコマンドを実行＞

補正は成功し、基準時計と表示が一致、秒も正確になりました。次はこの状態で日次の通常手順(最後にUを1回)を再度検証します。
＜何やらコマンドを実行＞

電池を外さない日次の手順で、分も秒も合うことを確認できました。

最後の検証では、時計は 23:46:30 と 23:46:57 に 11:46 PM を表示し、基準時計の 23:47:00 のほぼ直前に 11:47 PM へ切り替わりました。切り替わりは、0.1〜0.2秒以内の精度です。

手順

本当の時刻で、分 m の :05 に M を長押しして設定モードに入り、M で分の設定へ進みます。
分 m の :15、:27、:39、:51 に、U → D の組を押します。分は ±0 で、設定モードの20秒制限対策になり、時計自身の分の繰り上がりの位相を、境界から離す役もします。
分 m の :59.9 に U を1回押します。表示は m+1 になり、秒が 0 に戻って、60.1 秒後(本当の境界)に m+2 へ切り替わります。
20秒操作しないと、自動で通常表示に戻ります。

この検証で、前の2回(1分ずれ)の原因も確定しました

1回目は、最後の U が、時計自身の分の繰り上がりと重なって、+2 になりました。
2回目は、1回目の誤差(+1分)が残ったまま、手順が正しく動いたためです。私が設定前の表示を確認せずに、「正しい」と仮定していました。申し訳ありません。

（中略）

まとめ

私の質問
結局、この時計の秒が00にセットされるタイミングは何だったのでしょうか？

AIの回答
分の設定中に、△(+)または ▽(−)ボタンを押した瞬間です。
（中略）

私の質問
10/8 22:12:55 から 23:47:00 までの約1時間35分の間に行った、実験回数を教えてください。

AIの回答
スクリプトの実行回数は 21 回です。実験の条件の試行数では 24 試行です。

数え方の根拠(記録ファイルとログ)

runs/*.json が 19 個あります。
そのほかに、記録ファイルに残らなかった実行が 2 回あります。
合計は、19 + 2 = 21 回です。

試行数(条件を数える)

taptest は、1 回の実行の中で 3 通りの条件を試しました。taptest2 は、1 回の実行の中で 2 通りです。
21 回のうち、この 2 回を、それぞれ 3 試行と 2 試行に数えると、21 − 2 + 5 = 24 試行です。

以下は、最終の実験の様子です（AIが録画した画像から切り出しました）。

MボタンのLEDが画面からはみ出していて見えませんが、ピカッと光ったタイミングが AIがボタン操作した瞬間で、時計の表示が変化している様子が見てとれます。
PM 11:45:07ぐらいに、時刻合わせモードに入ります。

基準時計の PM 11:46:00 に合わせて、最後の △ボタンを操作して時刻合わせが完了。1分後、両方の時計がほぼ同時に PM 11:47:00 に進みます。

おまけ

会話の中に登場した、AIが作成した基準時計clock.htmlのコードです。

clock.html

<!doctype html>
<html lang="ja">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Reference Clock</title>
<style>
  html, body { margin: 0; height: 100%; background: #000; }
  body { display: flex; flex-direction: column; align-items: center; justify-content: center; }
  #t { font: 700 9vw/1 ui-monospace, Menlo, monospace; color: #fff; font-variant-numeric: tabular-nums; letter-spacing: 0; }
  #d { font: 3vw/1.4 ui-monospace, Menlo, monospace; color: #888; margin-top: 2vw; }
</style>
</head>
<body>
<div id="t">--:--:--.---</div>
<div id="d"></div>
<script>
  const t = document.getElementById("t");
  const d = document.getElementById("d");
  const p = (n, w = 2) => String(n).padStart(w, "0");
  function tick() {
    const n = new Date();
    t.textContent = `${p(n.getHours())}:${p(n.getMinutes())}:${p(n.getSeconds())}.${p(n.getMilliseconds(), 3)}`;
    d.textContent = `${n.getFullYear()}-${p(n.getMonth() + 1)}-${p(n.getDate())}`;
    requestAnimationFrame(tick);
  }
  tick();
</script>
</body>
</html>

次回は、NTP同期時計に改造します。

以上

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up