Macのプライベート音声入力を見極める：録音から入力先まで、コピーの経路を追う

「音声を保存しません」と書かれていれば、プライベートな音声入力だと判断できるでしょうか。

まだ足りません。

Mailで三文の返信を音声入力するとします。取引先の名前、締切、まだ外へ出したくない考えが含まれている。完成した文章は返信欄へ入り、画面上の作業は終わります。しかし、その一文が通った場所には、画面から見えないコピーが生まれます。

録音はMacに残ったのか。文字起こし事業者は保持するのか。整形前と整形後の文章はサービスに保存されたのか。クリップボードには何が残り、最後に入力先アプリは何を保存するのか。

Macの音声入力を「プライベートかどうか」で比べるなら、製品の形容詞ではなく、この経路を追う必要があります。

TalkTalkTypeはクラウド文字起こしを使うため、処理中の音声はMacの外へ出ます。一方、TalkTalkTypeのサービスは、音声ファイル、未整形の文字起こし、整形後の文章を永続的なコンテンツ履歴として保存しません。クリップボード内容もMacの外へ送りません。ただし、アカウント、端末、利用量、監査、サポートなど、サービス運用に必要な記録は残ります。

「何も外へ出ない」と「内容を後から取り出せる形で残さない」は、別の設計です。

録音は、まずMac上に作られる

録音はネットワークへ送られる前に、Mac上で作られます。TalkTalkTypeは⌥Spaceを押している間、16kHzのモノラルWAVを生成し、アップロードに必要な時間だけ扱います。

Macアプリには、完了した下書きセッションを確認する短い作業履歴があります。最大50件について、元の文章、適用した修正、完成文、入力先、結果をメモリ内に保持します。ディスクには書き込まず、TalkTalkTypeを終了すると消えます。

ここで区別したいのは、一時的な作業状態と、後から検索できる履歴です。

作業中にデータが一切存在しなければ、文字起こしも再試行もできません。しかし、処理中に存在することと、録音ライブラリとして保存されることは同じではありません。TalkTalkTypeのMacアプリに短い作業記憶はありますが、端末間で同期される永続的な文字起こし履歴ではありません。

サービス側も、受信した音声バイトを独自のファイルストレージやデータベースへ書き込みません。送信や貼り付けを再試行する必要がある場合に限り、Macアプリが直近の音声を一時的に扱うことがあります。

プライバシー説明では、「処理のために存在する」と「後で取り出せる形で保存する」を分けて読む必要があります。

クラウド文字起こしでは、信頼する相手が一つ増える

TalkTalkTypeが音声を保存しなくても、音声認識はどこかで処理されます。現在の本番構成ではOpenAIを使用しています。

ここで信頼境界が一つ増えます。TalkTalkTypeのストレージと、文字起こしプロバイダーの処理基盤は別のシステムです。「当社は音声を保存しません」という説明だけでは、プロバイダーを含む全経路までは分かりません。

2026年7月28日時点で、OpenAIのAPIデータ管理方針は、顧客が明示的にオプトインしない限り、APIの入力と出力をモデル学習に使わないと説明しています。同じ資料では、音声文字起こしエンドポイントについて、通常の不正利用監視またはアプリケーション状態の保持を行わない条件が示されています。

確認すべきことは二つです。

TalkTalkTypeが自社のストレージへ何を書かないのか。外部プロバイダーが、受け取ったリクエストをどう扱うのか。

方針は変わり得ます。古い比較記事や画面のスクリーンショットではなく、利用する時点の一次資料で確かめる必要があります。

文字が戻ったあと、保存先は入力先へ移る

音声認識が文字列を返し、選んだモードによっては、その文章を読みやすい形へ整えてからMacへ戻します。

TalkTalkTypeは、未整形の文字起こしも完成文もD1へ保存しません。サーバー側に、後から検索できるdictation履歴はありません。

では、文章はどこに残るのでしょうか。

Mailの下書きへ入れればMailに残ります。Slackへ投稿すればSlackに残り、Notesへ入れればその文書に残ります。AIツールの入力欄へ送った文章は、そのツール側の処理と保存方針に従います。音声入力サービスが自社の保持を減らしても、受け取ったアプリの保存までは消せません。

クリップボードも独立した境界です。Pasteモードでは完成文を一時的にMacのクリップボードへ置き、貼り付け後に元の内容を復元します。Copyモードでは、手動で貼り付けるまで結果を残します。クリップボードの内容はTalkTalkTypeのサービスへ送られません。入力先へ届ける仕組みと権限は、Macのどのアプリでも使える音声入力で詳しく扱っています。

音声入力ツールの受け渡しが終わった場所から、入力先アプリの責任が始まります。

内容を保存しなくても、運用データは残る

文字起こし本文を保存しないサービスにも、アカウントと利用上限はあります。

TalkTalkTypeは、Googleサインインの識別情報、セッションのメタデータ、登録端末と失効状態、プランや購読状態、紹介記録、リリース情報を保存します。利用回数と週間音声時間を管理するため、処理時間、成功・失敗、プリセット、プロバイダー、遅延などの利用行も記録します。そこに発話内容は付けません。

サポートへ送った文章は、担当者が読んで回答するために保存されます。そのため案内では、音声ファイル、文字起こし本文、トークン、APIキー、Cookie、カード情報を送らないよう求めています。

「何も保存しない」より、実態は複雑です。

同じ利用者を認識し、Macを登録し、上限を数え、失敗を調べ、問い合わせへ返答するには、運用データが必要です。重要なのは、その記録が知らない間に発話内容の保管庫へ変わらないことです。現在のTalkTalkTypeは、コンテンツ履歴を運用データへ混ぜない設計になっています。

Macアプリのセッション情報と端末資格情報はmacOS Keychainに保存します。通常のUserDefaults、コールバックURL、ログへBearer tokenを置きません。サインアウトや認証失敗時には資格情報を削除します。

音声を外へ出せないなら、ローカル処理を選ぶ

ネットワーク送信そのものが許されない仕事では、比較は早く終わります。クラウド方式の保持期間を細かく比べても、最初の要件を満たしません。端末内で音声認識する製品を選ぶべきです。

ローカル処理では、モデルをMacへ置き、メモリ、計算資源、電力を使います。結果はモデルの大きさとMacの性能に左右されます。デスクトップでは負担が目立たなくても、ノートMacでは発熱や電池消費が気になる場合があります。条件差が大きいため、「ローカルは遅い」「クラウドは正確」と一括りにはできません。

TalkTalkTypeは逆の選択をしています。音声認識モデルをMac上で動かさず、録音をクラウドへ送り、その結果の周囲にサーバー側のコンテンツ履歴を作らない方式です。

どちらも、あらゆる意味で「完全にプライベート」ではありません。ローカル方式はネットワークへの露出を減らします。クラウド方式でも、サービス側の永続保持を減らすことはできます。

先に決めるべきなのは、自分が譲れない境界です。

プライバシーポリシーを、データ台帳として読む

盾のアイコンや「安心」という言葉を並べても、各データがどこへ行くかは分かりません。判断しやすいのは、一回の録音で生まれるデータを行ごとに並べる方法です。

各行について、保存目的と保持期間を探します。説明がないことは、「保存しない」という意味ではありません。録音一覧があれば保存の証拠になりますが、一覧がないだけでバックエンドにも存在しないとは証明できません。公開方針と実装が一致している必要があります。

TalkTalkTypeは現在の分担をPrivacyページで公開しています。アカウント、端末、利用量、紹介、リリース、監査、サポートの記録は保持します。音声バイト、文字起こし本文、整形済みテキスト、ログ内のBearer token、D1内の秘密情報、クリップボード内容は保持しません。

答えは、単純な「ローカル」でも「保存なし」でもありません。

音声はMacの外へ出て、設定されたプロバイダーが処理します。TalkTalkTypeは、そのリクエストをサーバー上の録音ライブラリや、永続的な文字起こし履歴へ変えません。

次に話す一文で、必要な境界を決める

買い物メモや気軽な返信と、ソースコード、健康情報、取引先の案件、認証情報を含む一文では、同じ判断になりません。

音声をネットワークへ送ること自体が許されないなら、端末内処理を選びます。クラウド文字起こしを受け入れられ、サービス側に発話内容を残さないことを重視するなら、TalkTalkTypeが候補になります。どのツールを使う場合でも、入力先へ保存すべきでない秘密は音声にしない方が安全です。

TalkTalkTypeをダウンロードすると、無料プランで週30回まで試せます。現在の利用上限とプラン提供状況は料金ページにあります。

プライバシーの判断は、ショートカットを押す前に始まります。

これから話す一文が作るコピーを順番に想像し、後から説明できる経路を選んでください。