誰が何を言ったか：MinuteAIが話者分離を「同梱」ではなく「ダウンロード」として提供する理由

文字起こしは議事録と同じではない

4人参加の1時間の会議を文字起こしすると、テキストの壁ができあがります。その中のどこかに、誰が何に合意したか、誰が誰も対応しなかった異議を唱えたか、誰がフォローアップの担当なのかという情報が埋まっていますが、どの行がどの話者の発言かがわからない限り、それは見えてきません。文字起こしを実際に使える議事録に変えるには、多くの文字起こしツールが後回しにしがちな帰属付けの工程が必要です。それが話者分離(スピーカーダイアライゼーション)——誰がいつ何を言ったかを特定する処理です。

以前、MinuteAIのオンデバイス文字起こしパイプラインと、ボットが会議に参加することのないChrome拡張機能について書きました。話者分離は、その結果できあがる文字起こしをただのテキストの塊から構造化されたものへと変える部分です。そして同時に、「とにかく全部オンデバイスで動かす」というMinuteAIのいつものパターンを崩しかけた部分でもあります。

オンデバイスで実現することの難しさ

MinuteAIがすでにCore ML経由で動かしているWhisperベースの文字起こしは、ネイティブのmacOS/iOSアプリに常駐させても扱いやすいモデルです。話者分離はまったく別物です。MinuteAIの話者分離はpyannote.audioという、このタスクにおいてほぼデファクトスタンダードとなっているオープンソースライブラリの上に構築されており、pyannote.audioはPyTorch上で動作します。どちらも、アプリバンドルにそのまま組み込める軽量なCoreMLモデルとして配布できるものではありません。Python、PyTorch、そしてscikit-learnやnetworkxを含むpyannote自身の依存関係ツリーだけで、展開後のサイズはおよそ743MBに達します。

これを全インストールに同梱してしまうと、話者分離を一度も有効にしないかもしれない大多数のMinuteAIユーザーにまで、数百MB単位の「税金」を課すことになります。だからMinuteAIはそれを同梱しません。話者分離は別個の、オプションのダウンロードとして提供されます。PyTorch 2.10とpyannote.audio 4.0.4があらかじめインストールされた自己完結型のPython 3.13ランタイムを、圧縮後約234MBに梱包し、ユーザーが設定画面で話者分離を有効にしたときだけGitHub Releasesの配布物から取得します。それ以外のユーザーのインストールサイズは、これまでとまったく変わりません。

ブリッジではなくサブプロセス

この仕組みを成立させているアーキテクチャは、Pythonランタイムをアプリ本体から意図的に距離を置いて扱っています。何らかのブリッジライブラリを介してPythonインタプリタをSwiftUIのバイナリに埋め込むのではなく、MinuteAIのSwiftコードはダウンロードしたランタイムをサブプロセスとして起動し、その境界越しにやり取りします。python-runtime-managerというコンポーネントがダウンロードとライフサイクルを管理し、サブプロセスランナーがどのPythonバイナリを呼び出すかを解決し、話者分離エンジンがそのサブプロセス経由でモデルを読み込み推論を実行します。話者分離が一度も有効化されなければ、この経路のコードはまったく実行されず、ランタイムがダウンロードされることもありません。これは、MinuteAIのコア文字起こしパイプラインにあるモデルマネージャーの設計思想——実際に必要になるまで何も常駐させない遅延読み込み——を、CoreMLモデルより一桁重い依存関係に適用したものです。

この分離には、話者分離ランタイムがアプリ本体とは独立にバージョン管理されるという意味もあります。MinuteAI自体のバージョン番号とは別のリリース履歴を持つため、アプリのリリースを強制することなくモデルとその依存関係を更新でき、逆にアプリは話者分離のスタックにまったく触れずにリリースできます。

帰属表示が実際に求めていること

話者分離を支えるモデル——pyannote/speaker-diarization-community-1——には、明記しておく価値のある独自のライセンス連鎖があります。これは注釈で片付けられるような話ではなく、実際のビルドプロセス上の制約です。このモデルはCC-BY-4.0で配布されており、原著者(Hervé Bredin氏らの研究チーム)への帰属表示が求められます。そもそもHugging Faceからこのモデルを取得するには、そのモデルの利用規約への同意に紐づいたアクセストークンが必要で、最終的な成果物が誰でもダウンロードできる公開リリースになるとしても、ランタイムをビルドするたびにこの手続きを完了させる必要があります。pyannote.audio自体はMITライセンス、Pythonランタイムの部分はPSFライセンスです——1つのダウンロードの中に、それぞれ異なる義務を持つ3つのライセンスが積み重なっているわけです。

エンジニアリング面も摩擦なく進んだわけではなく、それを取り繕わずに書いておく価値があります。pyannote 4.x系は出力APIを変更し、結果を直接Annotationとして返すのではなくDiarizeOutputというオブジェクトでラップするようになったため、既存の連携コードが動かなくなり、修正が必要になりました。またパイプライン全体が実際に音声を検出できているかを検証するには、合成音声のテストトーンではなく、macOS自体のテキスト読み上げ機能で生成した本物の音声を使う必要がありました——このモデルは合成音声を音声として確実には認識しないためです。細かな話ではありますが、こうしたディテールこそが、デモでは完成しているように見える話者分離機能と、実際に出荷できる話者分離機能とを分けるものです。

市場が実際にどこへ向かっているか

話者分離をサーバーから切り離すという判断は、孤立して起きているわけではありません。クラウドベースの多くの議事録作成ツールは、いまも予想どおりの場所——アップロードされた音声を受け取るのと同じインフラの内部——で話者分離を実行し、話者の埋め込みを計算して文字起こしと一緒に保存しています。しかし、その重心は明らかに動きつつあります。MinuteAIが依存しているのと同じpyannote.audioライブラリを基盤とする商用事業であるpyannote.aiは、Argmaxと提携し、自社の最も精度の高い話者分離モデルをオンデバイスで動かす取り組みを進めています。クラウド型の話者分離をAPIファーストのカテゴリーとして定義することに一役買った企業自身が、いま同じモデルをローカルで動かすことに投資しているのです。兆候はそれだけではありません。アップロードしてから処理するという常識に対する明確な差別化要因として、「完全ローカル」の話者分離を打ち出す会議ツールが増えつつあり、オンデバイスの話者分離をニッチな実験ではなく、プライバシー主導の独立したセグメントとして位置づけ始めています。

MinuteAIのダウンロード式ランタイムというアプローチは、オンデバイスアプリの他の部分のフットプリントにそのままでは収まらない重量級のML依存関係という、現実の制約に対する、時に不格好でもある具体的な回答です。しかし行き着く先は、そのセグメントが向かっている方向と同じです——録音された音声も、話者の情報も、それが録音されたデバイスから一切外に出ない、文字起こしも含めて。

ポートフォリオの中での位置づけ

文字起こしは「何が話されたか」を決めます。Chrome拡張機能は「ボットをその場に入れずにどう音声を取り込むか」を決めます。話者分離は「誰がそれを話したか」を決めます。3つの異なるエンジニアリング上の課題ですが、その根底にある譲れない条件は同じです——会話の内容も、その取り込み方も、誰が話していたかも、それが起きたデバイスの外に出る必要はない、ということです。

---

MinuteAIはApp StoreからmacOSおよびiOS向けに入手できます。詳しくはgetminute.appをご覧ください。特定のワークフローへの組み込み方についてご質問があれば、[email protected]までお気軽にどうぞ。