gluonfield/enchanted とは何ですか？

Enchanted は、自前の Ollama サーバーに接続して Llama 2 や Mistral をチャット形式で使うための Swift 製アプリだ。README が示す構成と制約を読み、導入判断に必要な材料を並べる。

gluonfield/enchanted は商用利用できますか？

できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。

gluonfield/enchanted は今もメンテナンスされていますか？

されています。最後のコミットは 70 日前です。

gluonfield/enchanted はどのプログラミング言語で書かれていますか？

主に Swift です（GitHub の言語統計による）。

Enchanted レビュー: Ollama 用 iOS/macOS クライアントの構成と制約

ひと目でわかる

これは何？: Enchanted は、自前の Ollama サーバーに接続して Llama 2 や Mistral をチャット形式で使うための Swift 製アプリだ。README が示す構成と制約を読み、導入判断に必要な材料を並べる。
誰に向いている？: 自前の Ollama サーバーをすでに運用していて、iPhone や Mac から同じモデルにチャット UI で触りたい人には向く。逆に、Ollama を立てる予定がない人、モデルの管理やサーバー運用までアプリに任せたい人には向かない。
商用利用できる？: できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
今もメンテナンスされている？: されています。最後のコミットは 70 日前です。
何の言語で書かれている？: 主に Swift です（GitHub の言語統計による）。

回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

Hysen Labs 編集部 · 2026年9月10日 · gluonfield/enchanted

Enchanted が埋めるのはサーバーとアプリの間の隙間

Ollama を導入すると、モデルの取得と推論はローカルの HTTP API で扱えるようになる。だが API を叩くだけでは、会話の履歴を保つ、Markdown を読める形で表示する、画像を添えて送る、といった作業はすべて利用者側の負担になる。Enchanted はこの部分を担うクライアントだ。README は「essentially ChatGPT app UI that connects to your private models」と表現しており、対象は Llama 2、Mistral、Vicuna、Starling などの自前ホストモデル。つまりモデルを動かす側ではなく、動かしたモデルに日常的に触るための入口を作るプロジェクトである。想定読者は、すでに Ollama を動かしていて、iOS 系デバイスから同じモデルにアクセスしたい人だ。App Store 版が配布されており、README は「You will need to run your own Ollama server to use the app」と明記している。サーバーを用意しない限り、このアプリ単体では何も動かない。

会話は端末に残り、推論はサーバーに投げられる

データの流れは単純だ。アプリ側で入力したプロンプトは設定したサーバーエンドポイントへ送られ、応答が返る。README の機能一覧には「Conversation history is stored on your device」とあり、会話履歴は端末側に保持される。同時に「Conversation history included in the API calls」とも書かれているので、履歴はローカルに保存されるだけでなく、文脈としてサーバーへ送信される。この二点は分けて理解しておく必要がある。端末に残るからといって、履歴がサーバーに渡らないわけではない。自前サーバーならその送信先は自分自身の管理下だが、後述の ngrok 構成を取る場合は経路が外部に出る。機能面では、システムプロンプトの指定、メッセージ内容の編集、別モデルでの再送信、会話単位および全件の削除、音声入力、読み上げ、画像添付、Markdown 表示が挙げられている。macOS では Ctrl+⌘+K の Spotlight 風パネルが用意されている。README は「All features work offline」とも書くが、これはアプリ側の機能がネットワークなしで成立するという意味で、推論には当然サーバーへの到達が必要だ。

Ollama を公開するか、ngrok で通すか

起動手順は README で二つの場合に分かれている。ひとつは Ollama サーバーを公開アクセス可能な状態で運用している場合。App Store から Enchanted を入手し、アプリ設定でサーバーエンドポイントを指定すれば終わりとされている。もうひとつは Ollama を自分のコンピュータで動かしている場合で、こちらは手順が多い。まず Ollama サーバーを起動しモデルを取得する。次に ngrok を導入し、次のコマンドで転送する。

ngrok http 11434 --host-header="localhost:11434"

表示される Forwarding URL は https://b377-82-132-216-51.ngrok-free.app のような形式で、README はこれを一時的な URL と説明している。その URL をアプリ設定のサーバーエンドポイントに入れる。要求バージョンは README に「Enchanted requires Ollama v0.1.14 or later」とある。設定画面の具体的なキー名は README には記載がないため、この記事では触れない。バージョン要件と接続先の指定方法だけが、素材から確認できる範囲だ。

ngrok 前提の構成は、私的なモデルという触れ込みと噛み合わない

README は Enchanted の目的を「unfiltered, secure, private」な体験と書いている。だが Case 2 の手順は、ローカルの 11434 番を ngrok で外部に晒し、その一時 URL をアプリに入れるというものだ。URL を知る者はそのエンドポイントに到達できる。ngrok の無料枠では URL が起動ごとに変わる点も、README が「temporary URL」と断っているとおりで、固定運用には向かない。ここは設計上の割り切りだと見てよい。私的なモデルを使いたい動機と、モバイルから到達させるための公開という要求は本質的に衝突する。VPN や LAN 内接続で済ませる方法は README には示されていない。したがって、外部公開を避けたい環境では、このアプリの標準手順をそのままなぞるのは適切でない。もう一点、履歴が API 呼び出しに含まれる仕様は、公開経路と組み合わせると送信内容の範囲が広がる。会話の全文が毎回その経路を通る。

後継の Jaz が README の冒頭で告知されている

見落としやすいが重要な記述がある。README の最初の本文行は「Jaz is the new iteration of this project」で、gluonfield/jaz へのリンクが置かれている。これは Enchanted が今後この形で伸び続けるとは限らないというシグナルだ。リリース履歴もこれを裏づける。v1.6.7 と v1.7.0 が 2024 年 5 月に集中しているのに対し、次の v1.8.2 は 2026 年 6 月で、その間およそ 2 年の空白がある。活発に更新され続けているプロジェクトというより、後継へ移る前の安定版という性格が強い。既存機能は README に列挙された範囲で動くとしても、新機能の追加や不具合修正がどちらに投じられるかは、この記述からは判断できない。採用を検討するなら、Enchanted と Jaz のどちらを土台にするかを最初に決めるべきで、両方を見ながら様子を見る進め方は保守対象を二重にする。

同じ Ollama でも、ターミナルとデスクトップでは役割が違う

比較対象として分かりやすいのは、Ollama 自体が提供するコマンドラインと、Open WebUI のようなブラウザベースのフロントエンドだ。Ollama の CLI はモデルの取得と単発の推論には十分だが、会話履歴の保持や Markdown の整形表示、画像添付といった UI 側の責務を持たない。Enchanted はそこを補う。Open WebUI は同じくブラウザから Ollama に接続するフロントエンドで、違いは配布形態と到達経路にある。Enchanted は App Store から入るネイティブアプリで、iOS、macOS、visionOS にまたがり、音声入力や読み上げ、Spotlight パネルのような OS 統合を持つ。Open WebUI はブラウザが動く環境なら OS を選ばない代わりに、ネイティブの音声機能や OS ショートカットは持たない。どちらが優れているという話ではなく、ネイティブ統合を取るか、OS 非依存の到達性を取るかの選択だ。なお Open WebUI の詳細な仕様はこの素材には含まれていないため、ここでは一般的な位置づけの対比にとどめる。

Apache-2.0 と、保守コストの見積もり

ライセンスは Apache-2.0。ソースは Swift で公開されており、フォークして自前でビルドする道は残っている。ただし App Store 版を使う場合、アプリ本体の更新は配布側のリリースに依存する。v1.7.0 から v1.8.2 まで約 2 年空いている事実を踏まえると、更新頻度を前提にした運用計画は立てにくい。保守コストとして実際に効いてくるのは、アプリ側よりサーバー側だ。Ollama のバージョンは v0.1.14 以降が要求され、モデルを追加すればディスクとメモリを消費する。ngrok を使う構成なら、トンネルの起動と URL の再設定がアプリを使うたびに発生しうる。これは地味だが継続的な手間になる。ライセンス上は Apache-2.0 の条件に従う必要があるが、具体的な義務の解釈は利用形態によって変わるため、ここで法的な判断は示さない。自前ビルドするなら Xcode と Swift の環境が前提になる。

導入前に確かめる三つのこと

第一に、Ollama が v0.1.14 以降であること。第二に、11434 番への到達方法をどうするか。公開せずに済む経路が自分の環境にあるなら、ngrok の手順は飛ばせる。第三に、Enchanted と Jaz のどちらを追うか。この三点が決まらないまま入れると、後から構成を作り直すことになる。向いているのは、すでに Ollama を運用していて、iPhone や Mac、Vision Pro から同じモデルに手早く触りたい人だ。Markdown 表示や画像添付、読み上げといったネイティブ機能を重視するなら、このアプリの守備範囲は広い。向かないのは、Ollama をまだ立てていない人、モデル管理までアプリに任せたい人、外部公開を避けたいのに LAN 内接続の手段を README から得たい人。後者に該当するなら、到達経路を自分で設計したうえで使うか、別の手段を選ぶことになる。

編集部の結論

自前の Ollama サーバーをすでに運用していて、iPhone や Mac から同じモデルにチャット UI で触りたい人には向く。逆に、Ollama を立てる予定がない人、モデルの管理やサーバー運用までアプリに任せたい人には向かない。導入前に確認すべきは、README が要求する Ollama v0.1.14 以降を満たしているか、そして ngrok で 11434 番を外部公開する構成を自分のネットワーク方針で許容できるか。加えて、README 冒頭の一文どおり Jaz が後継として告知されているため、長く Enchanted 側に手を入れる前提で採用するかどうかを先に決めておきたい。

公式情報源

コミュニティノート