サブスク課金を捨てる訳。Macローカルの買い切りAIアプリとMCP対応が選ばれる理由

SNS運用を自動化しませんか？

ThreadPostなら、投稿作成・画像生成・スケジュール管理まで全てAIにお任せ。

無料で始める

クラウドに声を送り続けることへの違和感

20MB。買い切り。アカウント登録不要。

これがMac向けAI議事録アプリの新しい選択肢として登場したスペックだ。

一方、競合のクラウド型AIノートアプリは評価額15億ドルをつけている。

この数字の差が、今のAIアプリ開発の二極化をそのまま表している。

クラウドに依存してスケールを取るか、ローカルで完結させてプライバシーとシンプルさを取るか。

1人開発者が選ぶ戦略が、どちらなのかを考える。

ローカルAIノートアプリ「Talat」が示したアーキテクチャの選択

評価額15億ドルのクラウド型AIノートアプリが存在する市場に、イングランドのヨークシャー在住の開発者が1本のMacアプリをぶつけた。

自らをコンピューターオタクと称する開発者のNick Payneと、長年の友人で元同僚のMike Franklinによる共同開発だ。

名前はTalat。サイズは20MB。

価格はプレリリース版で49ドル、1.0リリース時には99ドルの買い切りだ。

サブスクなし。アカウント登録なし。アナリティクスデータの送信もなし。

継続的な費用も一切かからない。

この開発者がもともと興味を持っていたのは、競合アプリがシステムオーディオをどうやってMac上で録音しているかという技術的な謎だった。

当時はビデオを録画せずにシステムオーディオだけを録音する標準的な回避策が存在した。

調べていくうちに「Core Audio Taps」という比較的新しくドキュメントの少ないApple APIにたどり着いた。

それを扱いやすくするために、オープンソースのオーディオライブラリ「AudioTee」を自作した。

少しずつツールキットを組み立てていたが、単なるクールな技術デモ以上の製品にはならなかった。

最新のホスト型文字起こしモデルは信じられないほど素晴らしい。

自分の話した言葉がほぼリアルタイムで画面に展開されるのを見るのは、直感的にクールな体験だ。

しかし、そのトレードオフとして自分のデータだけでなく、実際の声というオーディオデータを提供する必要があることが常に気になっていた。

転機になったのは「FluidAudio」というSwiftフレームワークとの出会いだ。

Appleデバイス上で完全ローカルかつ低遅延のオーディオAIを可能にする。

Apple SiliconのNeural Engine上で、小型で高速な文字起こしモデルを直接動かすことができる。

これにより「音声データがMacの外に出ない」という設計が現実的になった。

Talatの主な機能はこうだ。

Zoom・Teams・Meet等のミーティングアプリのマイク音声をリアルタイムで文字起こし
話者の自動割り当てと手動での再割り当て
ノート記入・編集・削除・文字起こしセグメントの分割機能
Qwen3-4B-4bit等の軽量ローカルLLMによる要約生成
重要なポイント、決定事項、アクションアイテムの抽出
ノート、文字起こし、要約の検索機能

クラウド型の競合との最大の違いは「音声データと文字起こしデータが一切外部サーバーに送られない」点だ。

クラウド型は音声をサーバーに送って処理するため、精度は高いが「自分の声を他社のサーバーに渡している」という事実がある。

さらにTalatは、ユーザーに設定の自由度とデータ連携の選択肢を提供している。

要約モデルはデフォルトのQwen3-4B-4bitだけでなく、NvidiaのParakeetの2つのバリアントやOllamaにも対応している。

Obsidianへの自動エクスポートや、ミーティング終了時にデータを押し出すWebhookも可能だ。

外部データソースにオンデマンドで接続するためのMCP（Model Context Protocol）サーバーにも対応している。

将来的には、GoogleカレンダーやNotionなどの他のアプリとの統合も追加される予定だ。

M1以降のMacユーザーは、購入前に10時間の録音を無料で試すことができる。

しんたろー：
「自分の声を他社のサーバーに渡している」という感覚、使い始めるまで意外と気にしない。
でもこれが企業のミーティング録音だったら、法務が黙ってない案件になる。
ローカル処理というだけで、エンタープライズ向けのセールストークが一本できあがる。
ちなみに自分の声の録音を聞き返すと、滑舌の悪さに絶望してそっとアプリを閉じる。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

「SaaS is Dead」論とプラグイン化の現実

もう一つの軸として、SaaS自体の存在意義の変化がある。

「SaaS is Dead」という言葉をよく目にするようになった。

Claude CodeのようなAIエージェントの急速な普及により、SaaSの存在意義そのものが揺らいでいるという議論だ。

個人利用レベルの使い捨てツールや簡単な社内ツールであれば、Claude Codeに頼めば数分で作れる。

もはや何種類ものSaaSを使いこなす必要はない。

普段から使い慣れたAIに雑に日本語で命じるだけで事足りる。

ユーザー数課金型のSaaSでは、AI活用によって人間側の必要作業員が減少する。

顧客企業あたりの契約シート数が減るという構造だ。

追加機能への課金も、AIが代替してしまえば不要になる。

仮に顧客が解約しなくても売上が落ちるという構造的なミスマッチが発生する。

例えば、1日30〜40件の日記が書かれる「MydayAI」という零細日記サービスがある。

日記というのは「続けること」自体が最大のハードルだ。

わざわざブラウザを開いて、画面をポチポチ操作して、テキストを入力するという体験は、AIエージェントへの依頼と比較すると面倒だ。

小難しい操作手順など考えずとも雑にお願いすれば大体柔軟にやってくれる体験と比べると、SaaSが陳腐に感じてしまう。

個人の日記帳レベルであれば、ユーザーがAIエージェントにUIを作成させ、ローカルにテキストファイルとして蓄積させることも可能だ。

ユーザーはわざわざSaaSを使う必要があるのかという疑問が生まれる。

これはシンプルな日記サービスに限った話ではない。

CRMやプロジェクト管理ツールなどの複雑で大規模なSaaSであっても同じだ。

AIがデータ入力を自動化したり、レポートを自律生成したりするようになる。

「人間がUIをポチポチ操作する」部分の価値は確実に薄れていく。

多くのSaaS事業者は細かいチャーンレートを血眼で追っている。

一方で「このサービス、根本的にAIで置換可能では？」という疑問には正面から向き合えずにいる。

ここまで読んだあなたに

今なら無料で全機能をお試しいただけます。設定後は完全放置でプロ品質の投稿を毎日生成。

無料で始める

人間が操作するSaaSからAIが操作するSaaSへ

例えば勤怠管理ツールなら、従来は人間が毎日タイムカードを押す必要があった。

AI時代には、PCの起動ログ等からAIが自律的に出勤を検知し、Slackで「この時間で打刻しておきました」と通知する。

「人間が能動的にSaaSを操作する」から「AIがSaaSを操作して人間に確認を求める」への構造的なシフトだ。

以前から、各種業務ツールを使いこなすのは人間にとっては面倒なものだった。

SaaS事業者側は「弊社のツールは使いやすい」とアピールし、無理やりに社内に自社SaaSを浸透させる努力をしてきた。

しかし今や「SaaSを使うのは人間にとって負担」という事実が自由に主張できる空気感に変化してきている。

この流れの中で、MCP（Model Context Protocol）の存在感が増している。

AIエージェントがSaaSを操作するための標準的なインターフェースとして機能する。

ユーザーが個別にAIにツールを作らせる世界ではない。

ユーザーが手元のAIに既存のSaaSを操作するよう命じる世界が実現する。

AIがどれだけ強力になっても、何でもかんでもゼロから作らせるのは合理的ではない。

使い捨てツール以外のものをAIで作成して実際に使い続けるのはそれなりに難しい。

SaaS事業者がMCPサーバーを実装することで、自社アプリがAIエージェントの「プラグイン」として機能するようになる。

AIはもはやSaaSのUIではなく、ネットにおけるブラウザのような基盤的存在になる。

これまでSaaS事業者は「ユーザーがブラウザを持っている」ことを前提にサービスを開発してきた。

これと同じで、強力なLLMはプロバイダーが作ってくれる前提で、それらのAIから使いやすいサービスを作っていく。

基盤LLMプロバイダーは大多数のSaaSへの入口を握ることになる。

現在SaaSと呼ばれているサービス群は、いつの間にか単なるAIのプラグインへと姿を変える。

これはクラウド化の波と非常に似ている。

AWS・GCP・Azureの寡占と利用料金の低下のように、複数のビッグテックが競争する限りディストピア的な状況にはなりにくい。

MydayAIもMCPサーバーとしての機能を付与した。

これにより、毎日24時にカレンダーやメールの履歴を参照させて自動で日記を書かせるという使い方が可能になる。

生き残るSaaSの条件は「AIから操作されやすいか」になりつつある。

API呼び出し回数課金、データ保存量課金、成果連動型課金など、AIエージェント時代にフィットする課金体系への移行が求められる。

しんたろー：
ThreadPostもそうで、「人間がブラウザで開いて投稿する」だけじゃなく、「Claude CodeからMCP経由で自動投稿・分析できる」設計が気になっている。
UIを磨くより先に「AIが叩けるAPI」を整備するほうが、今後の利用動線として機能する。
自分のプロダクトを見直すと、やることが山積みで頭を抱えている。