Kelivo: Flutter製マルチプラットフォームLLMチャットクライアントの実用性を読む
A Flutter LLM Chat Client. Support Mobile & Desktop.
ひと目でわかる
- これは何？
- Android、iOS、HarmonyOS、Windows、macOS、Linuxを単一のDartコードベースで覆うLLMチャットクライアント。MCPと15種の検索バックエンドを抱え込む一方、AGPL-3.0という配布条件が導入判断を左右する。
- 誰に向いている？
- Kelivoが向くのは、複数のLLMプロバイダをひとつのUIで扱いたい個人ユーザーと、AGPL-3.0の条件下でクライアントをそのまま使うことに抵抗がないチームだ。逆に、自社アプリへ組み込んで再配布する計画がある場合、あるいはMCPツール呼び出しの精度を業務要件にする場合は、採用前に条件を精査する必要がある。
- 商用利用できる？
- 厳しい条件付きでできます。AGPL-3.0 はネットワーク型コピーレフトのライセンスで、改変版をホスティングサービスなどとしてネットワーク越しに利用させる場合、その利用者にソースコードを同じライセンスで提供する必要があります。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Dart です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
単一のDartコードベースで6プラットフォームを覆うという設計判断
Kelivoが解こうとしている問題は、LLMとの対話環境がプロバイダごと、OSごとに分断されていることだ。READMEの機能一覧にはOpenAI、Google Gemini、Anthropicなど主要プロバイダへの対応が挙げられ、プラットフォーム対応の節ではAndroid、iOS、Harmony、Windows、macOS、Linuxの6つにチェックが付いている。HarmonyOS向けはkelivo-ohosという別リポジトリに切り出されている点は注目に値する。本体のmasterブランチがすべてのターゲットを同一ビルド系で扱っているわけではなく、OpenHarmony系は派生リポジトリ側で保守する構造だ。
想定読者は、スマートフォンとデスクトップの両方で同じ会話履歴とアシスタント設定を使いたい個人開発者や研究者である。READMEにはQRコード共有によるプロバイダ設定のエクスポート・インポートと、チャット履歴のバックアップ・復元が記載されており、端末をまたぐ運用が想定されていることが読み取れる。企業の社内チャット基盤として設計された形跡はない。
MCPとWeb検索をクライアント側に抱え込む構成
Kelivoの機能上の重心は、モデルそのものではなくクライアント側のツール層にある。READMEはModel Context Protocol（MCP）対応と、組み込みのMCP Fetchツールを挙げている。検索バックエンドとしてBing、DuckDuckGo、Exa、Tavily、Zhipu、LinkUp、Brave、Metaso、SearXNG、Ollama、Jina、Perplexity、Bocha、Serper、Grokの15種が列挙されている。
ここから読み取れるデータフローはこうだ。ユーザーの入力がプロバイダのAPIへ送られ、モデルがツール呼び出しを要求すると、Kelivoが該当するMCPツールまたは検索バックエンドを実行し、結果を会話コンテキストへ戻す。検索プロバイダの選択とMCPサーバの登録はクライアント側の設定に依存する。つまり検索品質やツール呼び出しの成否は、Kelivo本体のコードではなく、どのバックエンドを設定したかで決まる部分が大きい。READMEには各バックエンドの評価や推奨順位は書かれていない。
もう一点、カスタムHTTPリクエストヘッダとボディの指定が可能とされている。これは標準対応していないプロバイダや社内プロキシを挟む構成を想定した機能だが、具体的な記述例はREADMEには載っていない。
導入までの手順と、READMEが示す配布チャネル
入手経路は3つに分かれる。iOS向けはApp Storeのバッジリンク（apps.apple.com/us/app/kelivo/id6752122930）、ベータ版はTestFlight（testflight.apple.com/join/erbGGykR）、そしてGitHub Releasesの最新版ページである。Androidやデスクトップ向けの配布はReleases経由が主になる。
ソースからビルドする場合、言語はDartでフレームワークはFlutterなので、一般的なFlutterのビルド手順に従うことになる。ただしREADMEにはビルドコマンドそのものは記載されていない。リポジトリの構成やpubspec.yamlの内容は提供資料からは確認できないため、依存パッケージやFlutter SDKのバージョン要件は各自でリポジトリを確認する必要がある。
設定面でREADMEから確実に読み取れるキーは限られる。プロバイダ設定はQRコードでエクスポート・インポートでき、チャット履歴はバックアップ・復元に対応する。Androidにはバックグラウンド生成を継続する任意設定がある。プロンプト変数としてモデル名や時刻などの動的変数が使えるとされている。フォントはシステムフォント、ローカル読み込み、Google Fontsのオンデマンド取得の3通りが挙げられている。
AGPL-3.0であることが意味する配布上の境界
KelivoはAGPL-3.0でライセンスされている。GPL系の通常の条件に加えて、ネットワーク越しに利用させる場合にもソース提供の義務が及ぶ点がAGPLの特徴であり、これはSaaS的な使い方をする開発者にとって無視できない。
個人が自分の端末で使う分には、この条件はほぼ問題にならない。しかしKelivoをフォークして自社サービスに組み込み、ユーザーにネットワーク経由で提供する場合、改変部分のソース開示が求められる可能性が高い。クライアントアプリの見た目を変えて再配布するだけでも、AGPLの条件に沿った扱いが必要になる。
ここで注意したいのは、Kelivoが依存するプロバイダAPIやMCPサーバ、検索バックエンドにはそれぞれ別の利用規約とライセンスがあるという点だ。Kelivo本体がAGPL-3.0だからといって、接続先のサービスの条件が緩和されるわけではない。ライセンスの解釈は法的判断を伴うため、商用利用の前に専門家へ確認するのが妥当である。
UIの出自と、それが示す保守体制の性格
READMEの謝辞には、RikkaHubプロジェクトのUIデザインに着想を得たこと、Kelivoのインターフェース設計がRikkaHubの設計に大きく影響を受けていることが明記されている。これは機能の独自性を測るうえで重要な情報だ。Kelivoの差別化要素はUIそのものではなく、MCPや検索バックエンドの接続層、プラットフォーム対応の広さにあると読むべきである。
リリースの刻み方も特徴的だ。提供された情報ではv1.2.4（2026-08-25）、v1.2.5（2026-08-31）、v1.2.6（2026-09-06）と、およそ1週間間隔でパッチ版が続いている。活発な更新は歓迎すべき面もあるが、逆に言えばAPIや設定の挙動が短期間で変わりうるということでもある。業務で固定バージョンを使いたい場合は、リリースノートを追って破壊的変更の有無を確認する作業が発生する。
なお、READMEにはスポンサーとしてsiliconflow.cn、随想AI中转、MaruCodeの3社が掲載されている。スポンサー企業のAPI中継サービスが併記されている構成は、プロバイダ選択の判断に影響しうる点として認識しておきたい。
向かないケース: サーバ運用と検証済みツール呼び出し
Kelivoが適さない用途は明確に2つある。第一に、ヘッドレスなサーバサイドのバッチ処理だ。KelivoはFlutter製のクライアントであり、READMEの機能一覧もUI操作を前提とした項目（ダークモード、Material You、マークダウンレンダリング、音声/TTS）で占められている。複数ユーザーの会話をサーバで集中管理する仕組みや、APIとしての公開は記載されていない。
第二に、ツール呼び出しの信頼性を業務要件とする使い方だ。READMEはMCP対応と15種の検索バックエンドを列挙するが、各バックエンドの応答品質、レート制限、失敗時の挙動については何も述べていない。検索結果の精度が成果物の品質を左右する用途では、どのバックエンドを選ぶか、失敗時にモデルがどう振る舞うかを自分で検証する必要がある。READMEの記述だけでは判断材料にならない。
加えて、HarmonyOS対応がkelivo-ohosという別リポジトリに分かれている以上、OpenHarmony系の端末を主要ターゲットにする場合、本体のmasterブランチとは更新タイミングがずれる可能性を前提に置くべきだ。
比較対象としてのRikkaHubと、LobeChat系クライアントの違い
Kelivoを評価する際に最も直接的な比較対象は、謝辞で言及されているRikkaHubである。READMEの記述に従えば、KelivoのUIはRikkaHubから強い影響を受けている。したがって両者の違いはUIの使い勝手ではなく、KelivoがMCPツール連携と15種の検索バックエンド、そしてHarmonyOSを含む6プラットフォーム対応を前面に出している点にある。UIの元ネタが同じである以上、乗り換えの判断材料はツール層の充実度とプラットフォーム網羅性に絞られる。
もうひとつの比較軸は、ブラウザベースのチャットUIを自前でホストするタイプのツールとの違いだ。こちらはサーバにデプロイして複数ユーザーで共有する設計が一般的で、会話データはサーバ側に集約される。Kelivoは逆で、データは端末側に置かれ、バックアップとQRコード共有という形で端末間を持ち運ぶ。プライバシー面ではクライアント型が有利だが、チーム全員で同じ会話ログを参照するといった使い方はできない。どちらが優れているという話ではなく、会話データを誰が保持するかという設計思想の差である。
編集部の結論
Kelivoが向くのは、複数のLLMプロバイダをひとつのUIで扱いたい個人ユーザーと、AGPL-3.0の条件下でクライアントをそのまま使うことに抵抗がないチームだ。逆に、自社アプリへ組み込んで再配布する計画がある場合、あるいはMCPツール呼び出しの精度を業務要件にする場合は、採用前に条件を精査する必要がある。最初に確認すべきは、リポジトリのLICENSEファイルと、利用予定のプロバイダがKelivoのカスタムリクエスト機能で実際に接続できるかどうかの2点である。
コミュニティノート