音声で話しかけるとAIが屋外活動のプランを立ててくれるアプリ「TouchGrass」が、Hacktoberfestのオープンソースチャレンジで公開されました。
このアプリ自体はスマホ依存を減らす小さなツールですが、設計面では見落とせない判断が含まれています。クラウドAI APIを一切使わず、ローカル実行の言語モデルを中核に据えた構成です。クラウドAPIへの依存をどこまで減らせるか、可用性やコストの設計判断を考えたいエンジニアにとって、具体的な比較材料になります。
本記事では、TouchGrassのアーキテクチャを題材に、ローカル推論とクラウドAPIのどちらを選ぶべきかを整理します。あわせて、自分のプロジェクトに同じ判断基準を当てはめる方法も示します。
TouchGrassの処理フローと技術構成
TouchGrassの処理フローは「話す→文字起こし→プラン生成→音声化→外出」という5段階です。
音声からテキストへの変換には、ElevenLabs Scribe（音声認識サービス）を使っています。ここはクラウドAPIです。
一方、プラン生成を担うのは、Ollama（ローカル環境でLLMを動かすためのランタイム）経由で動くQwenという open-weight モデル（重みが公開され手元で実行できるモデル）です。利用可能な時間・活動の好み・難易度・環境・興味・求める体験といった入力から、具体的な屋外プランを組み立てます。
生成されたプランは、再びElevenLabsで音声ブリーフィングに変換され、ユーザーに読み上げられます。音声認識と音声合成はクラウド、推論（考える部分）だけはローカルという役割分担です。
さらに、Ollamaが利用できない場合には、決定論的な（入力が同じなら必ず同じ結果を返す）オフラインプランナーにフォールバックする設計も組み込まれています。AIが使えない状況でも最低限の機能を維持する、可用性を意識した構成です。
なぜ「推論だけローカル」という分離が効くのか
クラウドAPIだけで構成する場合、アーキテクチャは単純に「ユーザー→クラウドAPI→レスポンス」という1本の依存線になります。
この構成の弱点は非機能要件の観点からはっきりしています。まず可用性です。クラウドAPI側の障害やレート制限が、そのままアプリ全体の障害に直結します。
次にコストです。リクエスト数に比例して課金が増える従量課金モデルは、利用者が増えるほど限界費用が重くのしかかります。
さらにベンダーロックインの問題もあります。特定のAPI仕様やモデルの挙動に強く依存すると、提供元の仕様変更や値上げ、サービス終了の影響をまともに受けます。
TouchGrassが採用したのは「推論層だけをローカルに切り出す」という部分最適化です。音声認識・音声合成はElevenLabsというクラウドサービスの強みを素直に使い、差し替えコストが高くなりがちな「頭脳」の部分だけをOllama経由のオープンモデルに置き換えています。
この判断は、全部を自前化するか全部をクラウドに任せるかという二択ではありません。コンポーネントごとに「クラウドに置く理由があるか」を個別に評価し、依存先を分散させる設計判断です。
クラウド推論とローカル推論、トレードオフの整理
どちらが優れているという話ではなく、非機能要件ごとに得手不得手があります。整理すると次のようになります。
| 観点 | クラウドAPI推論 | ローカル推論(Ollama等) |
|---|---|---|
| 可用性 | 提供元の障害・制限に影響される | ネットワーク非依存で動作継続可能 |
| コスト特性 | リクエスト数に比例した従量課金 | 初期の計算資源投資が中心、限界費用は低い |
| セキュリティ・データ扱い | 入力データが外部に送信される | データを手元の環境にとどめやすい |
| モデル差し替え | 提供元の仕様に縛られる | 環境変数の変更などで切り替え可能 |
TouchGrassのREADMEでは、OLLAMA_MODEL という環境変数を変えるだけでモデルを差し替えられる点が明示されています。これはアーキテクチャ上の技術的負債を抑える工夫として評価できます。
モデル選定をアプリケーションコードに埋め込まず、設定値として外出しすることで、将来より性能の良いオープンモデルが登場したときの移行コストを低く保てます。特定モデルのプロンプト仕様に強く依存したコードを書いてしまうと、モデル差し替えのたびにロジックの書き直しが発生し、これが技術的負債として蓄積します。
同様の判断は、日本の開発現場でもすでに意識されています。社内文書を扱うRAG(検索拡張生成)基盤で、機密情報を外部APIに送らない要件からローカルLLMを選ぶケースや、オンプレミス環境でのAI活用を検討する企業の事例は珍しくありません。クラウドAPIのレスポンス精度とローカル実行の統制のどちらを優先するかは、プロジェクトの要件次第で変わります。
自分のプロジェクトで何を確認すればよいか
既存または新規のAI機能を持つシステムで、同じ判断軸を適用するなら、次の点を確認すると良さそうです。
- 可用性要件の明文化: クラウドAPIの障害時にサービス全体が止まって良いか、それとも劣化運転(フォールバック)が必須かを事前に合意する
- データ送信先の棚卸し: どのコンポーネントが外部APIにどんなデータを送っているか、現状の構成図で確認する
- コスト試算の前提: 想定リクエスト数でクラウドAPIの従量課金とローカル推論用のGPU/CPUコストを比較する
- モデル・プロバイダ依存の箇所: プロンプトやレスポンス形式が特定モデルの挙動に強く依存していないかコードを点検する
- フォールバック経路の有無: AI呼び出しが失敗した場合に、決定論的な代替処理が用意されているか確認する
Ollamaは ollama list コマンドで現在ローカルにダウンロード済みのモデル一覧を確認できます。
ollama list
ollama run qwen2.5:7b手元で試す場合は、まず軽量なモデルで動作確認し、応答速度とハードウェア要件(メモリ・GPU VRAM)を見てから本番構成を検討するのが現実的です。TouchGrassのようにフォールバック設計を併用すれば、ローカル推論が使えない環境でも機能を落としてサービスを継続できます。
まとめ
TouchGrassの構成は、音声認識・音声合成はクラウド、推論はローカルという部分最適化の一例です。
全部をクラウドAPIに任せるか、全部を自前化するかの二択ではなく、非機能要件ごとにコンポーネントを分離して依存先を選ぶという判断プロセスが参考になります。
手始めに、自分のシステム構成図でAI呼び出し箇所を洗い出し、可用性・コスト・データ送信先・モデル依存度の4点を棚卸ししてみると、どこにローカル化の余地があるか見えてきます。
フォールバック経路の有無も忘れずに点検しておくと、障害時の挙動まで含めた設計判断ができるようになります。