会議の相手の声を自前で拾う仕組みは、技術的には作れると分かったが、結局作らなかった。調査を進めてGOの判断まで出たあと、改めて必要性を問い直して見送りに至った。
今回は、その着想から見送りまでの経緯を振り返る。
この記事でわかること
- 会議の相手の声を自前で拾う仕組みは技術的には作れたが結局作らなかった実情（2026年9月時点の記録）
- そもそも何を目指していたか
- 技術調査でGOと判断した内容
- 改めて必要性を問い直して見送った経緯
技術的には作れたが結局作らなかった
実現できるかと、実際に作るべきかは、別の話だった。 技術検証ではGOまで進んだが、最終的には作らない判断に落ち着いた。次の章から、順を追って振り返る。
そもそもは何を目指していたのか
着想の出発点は、ある機能の物足りなさだった。整理すると2つある。
純正機能はマイク経由の音声しか拾えない制約があった
標準機能では、対面での会話しか十分に拾えなかった。純正の音声入力機能は、グラス側かスマホ側のマイクを使う仕様だった。オンライン会議のように画面の向こうから聞こえてくる音声までは対応していなかった。
通話アプリの音声を直接取り込む方法を探した
そこで、画面の向こうから聞こえてくる声そのものを拾えないか調べることにした。オンライン会議の相手の声をそのまま拾えれば、対面と同じように表示や記録に使えるはずだと考えた。
技術調査でGOと判断した
実際に調べてみると、実現できる見込みが立った。確認できたのは2点だ。
ScreenCaptureKitならドライバなしで取得できると分かった
専用のドライバを入れなくても、システム標準の仕組みだけで実現できると分かった。OS標準のフレームワーク「ScreenCaptureKit」を使えば、画面と音声の収録許可を与えるだけでシステム音声を取得できる。サードパーティのドライバを追加する必要はなかった。
負荷も軽く通話への影響もないことまで確認した
処理の重さや通話への影響も、あわせて確認できた。CPU負荷はごくわずかで、通話アプリ側が気づく様子もない。対象アプリの音声だけを狙って取得でき、マイクやほかの音が混ざることもなかった。
ここまで確認できたところで、着手のゴーサインが出た。
改めて必要性を問い直した
ゴーサインを出したあと、いったん立ち止まって考え直す場面があった。その過程で、当初は見えていなかった視点が出てきた。
類似の商用ツールもリアルタイム表示は避けていた
同じ領域の商用ツールを見ても、共通する設計判断があった。いずれも通話中にその場で表示するのではなく、通話が終わったあとにまとめて要約を出す作りになっている。専業のツールでも、その場で見せる方式はあえて避けられているようだった。
通話後の記録は既存の仕組みで既にカバーされていた
加えて、似たような目的はほかの手段でも満たされていた。オンライン会議はもともと画面を見ている状態のため、追加で表示する価値も薄い。通話後の文字起こし自体も、既存の自動処理の仕組みでカバーされていた。
最終的に作らないと判断した
いくつかの材料が重なり、着手しない方向に決まった。 既にある仕組みと役割が重なる新しい基盤を、わざわざ二重に持つ意味は薄いと考えた。
似たように調べた末に見送った機能はほかにもある。いらなかった機能まとめ。
GOしたあとでも要否を問い直す姿勢は仕事の判断にも役立つ
判断を一度下したあとも、もう一段見直す余地を残しておくと役に立つ。 技術的に実現できることと、実際に取り組む価値があることは別の軸で判断したほうがいい。途中で立ち止まって問い直す進め方は、業務の意思決定にもそのまま活きる。
この余地を、MOCO Worksのサービスでも意識してつくっている。
参考・出典情報
（本記事は社内技術ドキュメントによる裏取り起点のため、外部出典なし）