AIノートテイカーはなぜ会議の途中で録音を止めるのか

7月2日、GeekByeは会議の録音を勝手に終了しました。データベースの行がすべてを物語っています。ended_reason = 'idle'、継続時間519秒、トランスクリプトエントリ99件 — 最後の1件が書き込まれたのは、アプリが「誰もいない」と判断する2秒前でした。

相手の参加者は説明の真っ最中でした。トランスクリプトの最終行は、文字どおり文の断片です: "...executes it or turns it on or so—"。

初めてではありませんでした。その前の晩にも、別のセッションが同じ形で終了していました。2つの会議が、私たち自身の信頼性機能によって殺されたのです。これはその診断と、GeekBye v2.0.9で出荷された修正の記録 — そして同じリリースで修正した、もう一つのより恐ろしいバグの話です。

あなたの声しか聞こえない、善意のタイマー

アイドル自動クローズには、ちゃんとした理由があります。録音を一晩中回しっぱなしにして忘れる人がいますし、開きっぱなしの会議タブは音声を延々と垂れ流し続けます。そこでGeekByeは非アクティブ状態を監視します。有声のアクティビティが60秒間ないと、小さな "Still recording?"(まだ録音中ですか?)プロンプトを表示し、その30秒後、応答がなければセッションを終了します — すべてを保存した上で、丁寧に。

欠陥は一語にありました: 有声(voiced)。アクティビティの時計は持続的なマイクのエネルギーだけをカウントしていたのです。これは意図的な設計判断で、愚かなものではありません — システム音声の生のエネルギーをカウントすると、ミュート中でも音が鳴っているタブが死んだセッションを永遠に生かし続けてしまい、それこそがこの機能が防ぐために存在する失敗そのものだからです。主に聞き役に回る会議は、会議ウィンドウ検出でカバーされるはずでした。

ただし、会議検出はすべての会議を見つけられるわけではありません。ブラウザのタブ、珍しいクライアント、視聴中のプレゼンテーション — これらは検出されません。そして検出されていない会議で90秒間聞き役に回ると — 誰かがDatabricksのパイプラインを説明している間なら、完全に普通のことです — あなたはアイドルの時計から見て、空っぽの部屋と区別がつかなくなるのです。

殺されたセッションのタイムラインを確認してみましょう。こちらのマイクからの最後のトランスクリプトは、終了の68秒前でした。それから相手が話す60秒(完璧に文字起こしされたのに、時計には無視された)、気づかれなかったプロンプト、30秒のカウントダウン、そしてキル — 相手の最後の言葉の2秒後でした。

修正: トランスクリプトは生存の証明

修正内容は、振り返ると恥ずかしくなるほど単純です。届いたトランスクリプトこそ、セッションがアイドルではないことの最強の証拠である。 誰が話したかは関係ありません。音声モデルがたった今、言葉を認識した — それこそが会議そのものなのです。

そこでv2.0.9は、どちら側からのものであれ、トランスクリプトが到着するたびにアクティビティの時計にスタンプを押します。システム音声の生のエネルギーは今でもカウントされません — 音楽も、保留音も、空調のうなりも、死んだセッションを不死にはできませんし、録音のハードキャップは今もすべての最終防衛線として機能します。認識された発話だけがセッションを生かし続ける。これがまさに正しい境界線です。

コードレビューから得た、伝える価値のあるディテールを一つ。修正の最初のバージョンは、話者帰属パスの内側で時計にスタンプを押していました — このパスは、一部のトランスクリプトが正当にスキップし得るものです。レビューは、将来の変更が、まさに重要なトランスクリプト(相手側の発話)についてこのバグを静かに再発させかねないことを見抜きました。スタンプは今では無条件で、あらゆる分岐より前に置かれ、誰かがそれを動かせば失敗するテストが付いています。

同じリリースが、もっと恐ろしいものを修正した

これらの修正をテストしている最中に、別のバグを身をもって踏み抜きました。インターフェースプロセスのクラッシュが、デスクトップ全体をクリック不能にしたのです。

GeekByeのオーバーレイは、画面を覆う透明で常に最前面のウィンドウです。デフォルトではクリックスルーで、パネルを使っているときだけインターフェースがインタラクティブに切り替えます。その切り替えはインターフェースプロセスから来ます — つまり、パネルを開いた状態でそのプロセスがクラッシュすると、不可視のウィンドウは、背後に生きたUIが何もないままインタラクティブモードに留まります。デスクトップへのクリックはすべて、死んだ不可視のペインに着弾する。唯一の脱出方法は、アプリの強制終了でした。

v2.0.9のクラッシュハンドラは、クリックスルーを即座に復元し、インターフェースをリロードします — クラッシュループが永遠に回らないよう、1分あたり3回のリロード上限付きです(上限を超えるとアプリはリロードを諦めますが、あなたのデスクトップは使える状態のまま。そこが肝心な部分です)。こちらもコードレビューが研ぎ澄ませました。リカバリはオーバーレイウィンドウに限定してスコープされています。クラッシュした通常のウィンドウ — たとえばアップデートダイアログ — にまで一律にクリックスルーを適用していたら、正反対のロックアウトを生んでいたからです。

この修正は、自分の手で乱暴に検証できます。GeekByeのパネルを開き、アクティビティモニタで "GeekBye Helper (Renderer)" プロセスを強制終了し、アプリが1秒以内にデスクトップを取り戻すのを見てください。

この一対のバグが教えてくれたこと

1. 「ユーザーはここにいるか?」の代理指標は、どれもどこかで失敗する。 マイクのエネルギーは聞き役で失敗する。ウィンドウ検出はブラウザで失敗する。認識されたトランスクリプトが失敗するのは...今のところ見つかっていません。代理指標ではなく、プロダクトそのものだからです。
2. レンダラー駆動のものには、すべてクラッシュ時のストーリーが必要。 死んだUIプロセスがOSレベルの状態(マウスキャプチャ、常に最前面、コンテンツ保護)を残し得るなら、リセットの責任はメインプロセスが持たなければなりません。
3. 自分たち自身が最もヘビーなユーザーであることは、バグ発見の戦略になる。 どちらのバグも、ほんの一握りの顧客が気づくより前に、実際の会議で私たちを直撃しました。数か月前に可観測性のために追加していた ended_reason カラムのおかげで、診断は推測ではなくデータベースクエリで済んだのです。

どちらの修正も、診断から公証済みリリースの出荷まで1日以内に到達し、それぞれリグレッションテスト付きのレビュー済みPRで運ばれました。GeekBye v2をお使いなら、v2.0.9以降、自動アップデートですでに適用されています。

このリリースの物語の続きは、同シリーズのAI文字起こしはなぜ専門用語を聞き間違えるのか(v2.0.11)、信頼性の土台となった悪いWi-FiでAIノートテイカーが止まる理由、そしてオーバーレイがあなたのクリックを奪わずに画面共有中に不可視のままでいる仕組みをご覧ください。