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

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

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」を整備するほうが、今後の利用動線として機能する。
自分のプロダクトを見直すと、やることが山積みで頭を抱えている。

1人開発者が知る実務への影響

ローカルAIアプリが成立するための条件は揃ってきている。

Apple Siliconの普及により、Neural Engineの性能が軽量モデルの実用的な推論速度を実現した。

Qwen3-4B-4bit等のモデルが、特定タスクで実用水準に到達している。

FluidAudio等のフレームワーク整備により、ローカルオーディオAIの実装コストが大幅に下がった。

ただし、ローカルAIアプリが向いているユースケースは限られる。

文字起こし・要約・テキスト変換等の単一タスク、プライバシー要件が高いデータ処理には向いている。

最新情報へのアクセスが必要なタスク、複数ユーザーのデータを横断する分析には向いていない。

クラウドLLM依存でトークン課金基盤を構築するか、ローカルLLMで課金設計ごとスキップするかはユースケース次第だ。

「人間用UI」と「AI用インターフェース」の両方を設計する時代が来ている。

自社SaaSにMCPサーバーを実装することで、Claude Code等のAIエージェントから直接操作できるようになる。

「MCPサーバーを後から追加できる設計になっているか」は、新規プロジェクトの設計段階で確認する。

技術的には、MCPサーバーの公開は既存のAPI開発とそこまで大きく変わらない。

MCPサーバー向けのOAuth認証を追加すれば、多くのサービスがすぐに対応できる。

「SaaS is Dead」と嘆く前に、まずはAIエージェントとの接点を1つ作ってみる。

しんたろー：
課金基盤の実装は1人開発で一番しんどい部分のひとつだ。
継続課金だけでも覚えることが多いのに、トークン計量まで乗ってくると設計が一気に複雑になる。
ローカルAI買い切りという選択肢は、その複雑さをまるごとスキップできる点で、ニッチなユースケースでは本当に強い。

---

よくある質問

Q1. ローカルAIアプリはクラウド型と比べて精度はどうですか？

ローカルで動く軽量モデル（Qwen3-4B-4bit等）は、クラウドの大規模モデルと比べると、複雑な推論や長文要約の精度で劣るケースがある。

これは事実だ。

ただし、文字起こしという単一タスクに絞った場合、FluidAudioやApple Neural Engineの組み合わせで実用的な精度と低遅延を実現できる。

「全タスクで最高精度」ではなく「特定タスクで十分な精度＋プライバシー＋買い切り」というトレードオフを選ぶかどうかの話だ。

企業のミーティング録音のように「音声データを外に出せない」要件がある場合、精度のトレードオフを受け入れてでもローカル処理を選ぶ判断が合理的になる。

---

Q2. 「SaaS is Dead」論で売上が落ちる構造とは何ですか？

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

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

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

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

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

---

Q3. MCPに対応するメリットは何ですか？

MCP（Model Context Protocol）は、AIエージェントが外部ツールを操作するための標準インターフェースだ。

今後ユーザーは「複数のSaaSを個別に開いて操作する」ではなく「手元のAIエージェントに指示して各ツールを操作させる」という行動パターンに移行していく。

Claude Code等のAIエージェントが普及するほど、この傾向は加速する。

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

UIを経由しない新しい利用動線が生まれ、AI時代の「ブラウザ」のような基盤的存在としてのAIエージェントから、自社サービスが呼び出されるようになる。

これはユーザー獲得の新しいチャネルでもある。

---

まとめ

20MB・買い切り・ローカル処理という選択は、技術的な制約からではなく、設計思想として選ばれた。

クラウドLLM依存でトークン課金基盤を構築するか、ローカルLLMで課金設計ごとスキップするか。

どちらが正解かはユースケース次第だが、「Apple Siliconがあればローカル処理が現実的」という事実は、1人開発者の選択肢を確実に広げている。

そして、どちらのアーキテクチャを選んでも「MCPサーバーを後から追加できる設計か」は今から考えておく。

👉 ThreadPostでSNS運用を自動化する