AIが今どこで詰まっているのか、画面に出すまで｜NOVA開発記録 第4回

ただの塗装屋が作る音声AI「NOVA」開発記録 第4回｜状態を別のモニタへ出すまで

本業は塗装屋です。現場の仕事の合間と、仕事終わりの時間でNOVAを作っています。専門の開発者ではないので、動かなかったところはそのまま書きます。

▶ NEXTpaintのTikTokプロフィールを見る

前回、NOVAの録音が30秒近く終わらない問題と、NOVAが自分の声を拾って自分と会話し始める問題を直した。しきい値を決め、マイク側の自動処理を切り、状態ごとにマイクの扱いを固定した。音としては安定した。

ただ、直したあとに残った問題がある。動いているのか止まっているのか、外から分からない。

拍手をする。返事が返るまで数秒ある。この数秒のあいだ、NOVAが録音しているのか、文字起こしに投げているのか、考えているのか、それとも落ちているのか、こちらには何も分からない。返事が来なかったとき、どこで止まったのかを確かめる手段が「もう一度やってみる」しかなかった。

これは地味に効く。うまくいかないとき、原因が「聞こえていない」なのか「考えている途中」なのか「そもそも死んでいる」なのかで、やることが全部違う。それが区別できないまま、同じ操作を何度も繰り返していた。

しかもこの時点で、NOVA本体は自分の状態を8種類に分けてすでに持っていた。しかもそれを nova_state.json というファイルへ、状態名と説明文と更新時刻つきで書き出していた。

standby → wake → clap_detected → listening → thinking → speaking → follow_up → error。

内部には8段階ある。記録もされている。なのに外に出ているのは音声だけだった。8段階が1段階まで潰れて聞こえていた。情報は最初からあって、届いていなかっただけだった。

だから画面を作った。

目的をはっきりさせておくと、「かっこいい画面が欲しい」ではない。決めた条件は3つだけだった。1つ、8つの状態が、文字を読まずに区別できること。2つ、画面を見るために正面の作業を隠さないこと。3つ、画面が落ちてもNOVA本体は動き続けること。

3つ目が一番重要だった。画面はあくまで表示であって、NOVAの動作条件にしてはいけない。監視のために作ったものが原因で本体が止まるのでは、順序が逆になる。

作ったのはPythonのtkinterで動く1枚のウィンドウ。名前は NOVA Control Center。中央にコアを置き、その周りに8つの機能ノードを円形に並べた。背景は白。大きさは 1920×1080 固定。

ここまでは、正直そんなに難しくない。

難しかったのは、この画面を「作業の邪魔にならない場所」に出すことだった。NOVAを使う場所はPCの正面ではない。手を動かしながら声で指示を出す。だから画面は正面ではなく、別のモニタに出しっぱなしにしておきたかった。ところが、これが素直に動かなかった。

やったこと自体は普通で、tkinterで全画面にする指定を有効にして、目的のモニタいっぱいに出すつもりだった。ところが開くのは、何度やっても正面のモニタだった。ウィンドウの位置を指定しても、画面を指定しても、結果は同じ。この時点で私は「座標の計算を間違えている」と思っていて、そこを何度直しても変わらなかった。

二日ほど同じところで詰まって、最後に効いたのは座標でも設定でもなく、ウィンドウの扱い方そのものを変える一行だった。座標が違っていたのではなく、そもそも間違っていたのは、