Conduit 評価: Open WebUI をモバイルで使うための Flutter クライアント

Open WebUI のモバイル対応が壊れる三つの場面

README は、Open WebUI がデスクトップでは優れている一方で、モバイルでは「端で壊れる」と述べている。具体的には、リバースプロキシ背後の認証、アプリがバックグラウンドに回ったときのストリーミング切断、スクリーンショットをプロンプトに取り込む操作、ホーム画面からのチャット開始の四つを挙げている。これらは Open WebUI 本体の欠陥というより、ブラウザ経由のモバイル利用が前提とされてきたことの帰結である。Conduit はこの隙間を埋めるために作られた Flutter アプリで、4.0 以降は Open WebUI サーバの有無にかかわらず動作すると README は説明している。対象読者は、自前の Open WebUI を持ち、スマートフォンから日常的にチャットしたい人である。

接続方式が五つに分かれている理由

初回起動時に接続方法を選ぶ。Open WebUI は自前サーバに接続し、チャット、フォルダ、ノート、チャンネル、Workspace、ツール、Web 検索、画像生成というフル機能を対象にする。Direct は OpenAI 互換、Ollama、OpenRouter に直接話しかける方式で、Open WebUI アカウントを必要としない。README によれば Chat Completions と Responses の両方、LM Studio、Azure 形式の API バージョン、ネイティブ Ollama、OpenRouter をカバーする。API キーは省略可能で、キーを要求しないローカルエンドポイントにも向く。加えて Apple On-Device、Apple Private Cloud Compute、Hermes の三つが用意されている。この分岐は、サーバ運用者と、サーバを持たずモデルだけを使いたい人を同じアプリで扱うための設計だと読める。

Direct 接続と Apple 系プロバイダの実際の制約

Direct 接続では、Open WebUI 側で既に設定済みの接続が自動的に引き継がれると README は述べている。キーとカスタムヘッダーはプラットフォームのセキュアストレージに保管される。Apple On-Device は iOS 限定の Direct プロバイダで、Apple の SystemLanguageModel を基盤とする。iOS 26 と Apple Intelligence が必要で、オフライン動作、ストリーミング、サンプリング制御、JSON スキーマ応答に対応し、コンテキストウィンドウは 4K とされる。ただし画像入力、reasoning 制御、ツール呼び出しは利用できない。Apple Private Cloud Compute も iOS 限定で、Foundation Models フレームワークを使い、iOS 27、Apple Intelligence の可用性、Apple の管理する PCC エンタイトルメントを要求する。画像入力、reasoning レベル、サンプリングと出力上限、JSON スキーマ応答、クォータとコンテキストのライブ表示、PCC のネットワーク障害時のオンデバイスフォールバックに対応するが、ツール呼び出しは有効ではない。ここは機能表をそのまま信じるのではなく、自分の端末と OS バージョンで何が使えるかを個別に確認する領域である。

WebView ではなく Flutter で描画するということ

README は、ネイティブの Flutter サーフェスであり、WebView をシェルで包んだものではないと明記している。具体的には、シンタックスハイライト付きのコードブロックとコピー・プレビュー、Mermaid 図のネイティブ描画、LaTeX と数式、展開可能な reasoning・ツール呼び出し・コード実行セクション、インライン引用とソースカード、フォローアップ候補、Chart.js の埋め込みが挙げられている。ストリーミングは WebSocket 経由のトークン単位で、応答が伸びている間もトランスクリプトの位置を保ち、固定したプロンプトはその場に留まり、長い会話でも UI が止まらないとされる。これらは実装の主張であり、筆者が実機で検証したものではない。ただし WebView ベースのクライアントと比べたとき、描画品質とスクロール安定性が設計上の争点になることは確かで、Conduit はそこに賭けている。

セットアップと設定の入口

配布経路は Google Play と App Store の両方で、README にストアバッジが置かれている。パッケージ名は Android が app.cogwheel.conduit、iOS の App Store ID は 6749840287 である。ソースからビルドする場合は docs/BUILDING.md が案内として示されている。初回起動時に接続方法を選び、後から他の方式を追加できる。追加のサインインは不要なものは飛ばせる。Direct 接続では API キーを入力するか、ローカルエンドポイントなら省略する。キーとカスタムヘッダーはプラットフォームのセキュアストレージに保存される。Hermes に接続する場合、Conduit はサーバが実際に報告した能力だけを公開すると README は述べている。つまり設定画面に出る項目はサーバ側の応答に依存する。

Hermes エージェントとスケジュール実行

Hermes は自前のエージェントサーバに接続する方式である。ツールが動く様子をライブで見られ、機微なステップは実行前に承認でき、スケジュールされたエージェントは夜間にも走らせられる。会話とスケジュールは専用のタブを持つ。ここで注目すべきは、承認フローが組み込まれている点だ。エージェントにツールを実行させる設計では、何をどこで止めるかが安全性の中心になる。Conduit はそれを UI の操作として前面に出している。ただし README には承認の粒度やタイムアウト、失敗時の挙動までは書かれていない。運用に組み込む前に、自分の Hermes サーバ側のポリシーと突き合わせて確認する必要がある。

データの所在と GPL-3.0 が意味するもの

README は、チャットはまず端末上にあり、メンテナが運用するバックエンドを経由するものは何もないと述べている。ノートはオートセーブ、ピン留め、AI によるタイトル生成、AI 強化、音声録音を備え、いずれもオフラインで利用できるとされる。プライバシーはこの構成の中心的な売りである。ライセンスは GPL-3.0 で、これはコピーレフトの条件下で配布されることを意味する。社内配布や改変を行う場合、ソース開示などの義務が生じうる。ここでは法的助言はできないので、配布形態が GPL-3.0 の条件に収まるかは法務に確認してほしい。少なくとも、プロプライエタリな社内アプリに組み込んで閉じて配る、という使い方は想定されていない。

どんなときに Conduit は間違った選択か

第一に、Open WebUI の Workspace にあるモデル、ナレッジ、プロンプト、ツール、スキルをサーバ側で集中管理し、権限で見せ分けたい組織。Conduit は権限のないセクションを表示しないと README にあり、管理の主体はあくまでサーバ側である。第二に、Apple Intelligence 非対応の端末や Android でオンデバイス推論を前提にしたい場合。Apple On-Device と Apple PCC はどちらも iOS 限定で、それぞれ iOS 26 と iOS 27 を要求する。第三に、ツール呼び出しを必須とするエージェント用途。Apple 系の二つのプロバイダではツール呼び出しが無効と明記されている。代替としては、Open WebUI 自体をモバイルブラウザで使う方法がある。違いは明確で、Conduit は認証、ストリーミング、画像取り込みをアプリ側で処理するのに対し、ブラウザ経由はサーバの Web UI とプロキシ設定にそのまま依存する。サーバ側の設定を変えずにモバイルだけ改善したいなら前者、UI の一貫性を優先するなら後者である。

編集部の結論

Open WebUI を自前で運用していて、モバイルからの認証やバックグラウンド時のストリーミング切断に困っているなら、Conduit は検討する価値がある。逆に Open WebUI の Workspace や権限管理をサーバ側で完結させたい管理者、あるいは Apple Intelligence 非対応端末でオンデバイス推論を前提にしたい場合は、Direct 接続だけでは機能が足りない可能性が高い。導入前に確認すべきは、自分のサーバがどの機能を公開しているか、そして GPL-3.0 の下で社内配布や改変を行う場合の義務をどう扱うかである。

公式情報源

1. cogwheel0/conduit on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases