oterm を導入前に読む: Ollama と pydantic-ai を端末に持ち込む client の輪郭
the terminal client for LLMs
ひと目でわかる
- これは何？
- oterm は Ollama を含む pydantic-ai 対応プロバイダを端末から操作する Python 製 TUI クライアントだ。設定ファイルと extras の構造を確認し、MCP 設定の破壊的変更をどう扱うかを判断するための材料を整理する。
- 誰に向いている？
- oterm は、Ollama をローカルで動かしながら複数プロバイダを同じ端末 UI で切り替えたい開発者、および Claude Desktop 互換の mcpServers 設定をそのまま持ち込みたい利用者に向く。一方、GUI で画像や添付を多用する用途、Python 3.10 以前の環境、MCP 設定を旧スキーマのまま固定しているチームには向かない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 14 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
oterm が埋める位置: モデル選択のたびに端末を離れない
Ollama をローカルで動かしていると、モデルの切り替え、プロンプトの再送、出力のコピーという作業がシェルと別のアプリの間で往復しがちになる。oterm はこの往復を端末内に閉じ込めるために作られた TUI クライアントで、README の冒頭では「The terminal client for Ollama, OpenAI, Anthropic, and any pydantic-ai-supported provider」と説明されている。対象は、ローカル推論を常用しつつ、OpenAI や Anthropic の API も同じ操作感で試したい開発者だ。Ollama 専用だった頃の名残はあるが、現在は pydantic-ai を経由して複数プロバイダを扱う構成に変わっている。SSH 先のマシンで動かす用途を想定している点も、GUI クライアントとの差になる。
pydantic-ai を経由するプロバイダ解決の仕組み
oterm 自身が各社 API の差異を吸収しているわけではない。README によれば、プロバイダの対応は pydantic-ai に委ねられており、OpenAI、Anthropic、Google (AI / Vertex)、Groq、Mistral、Cohere、AWS Bedrock、DeepSeek、Cerebras、Grok、Hugging Face、そして OpenAI 互換のエンドポイント (vLLM、LM Studio、llama.cpp、OpenRouter、LiteLLM など)、Ollama が列挙されている。README の記述では、該当する API キーを設定すると新しいチャットのドロップダウンにそのプロバイダが現れる。つまりプロバイダの追加は oterm のコード変更ではなく、環境変数と pydantic-ai 側の対応状況に依存する。OpenAI 互換エンドポイントが含まれるため、自前の推論サーバを立てている場合も同じ経路で接続できる。
uvx で試す: extras と Python バージョンの線引き
基本の導入は README の1行に集約されている。uvx oterm を実行すれば、仮想環境を明示的に作らずに起動できる。読み上げ機能を使う場合は uvx "oterm[speak]" と extras を指定する。README はこの extras が Python 3.11 以上を必要とすると明記しており、基本インストール側には影響しないとしている。読み上げは piper を通じて応答をストリーミングしながら GLaDOS ボイスで読む仕組みで、extras が存在する場合にのみ機能が現れる。つまり Python 3.10 環境でも基本機能は動くが、speak は使えない。設定や使い方の詳細は README から oterm Documentation へ委ねられており、この記事の範囲では各設定キーの網羅的な一覧は確認できない。
mcpServers の破壊的変更が既存設定に与える影響
最も注意が必要なのは MCP まわりの変更だ。README は mcpServers 設定ブロックが pydantic-ai の標準スキーマを採用し、Claude Desktop や Cursor と互換になったと説明している。同時にこれを breaking と明示し、移行の詳細は docs/mcp を参照するよう促している。つまり旧バージョンで使っていた mcpServers の書き方はそのままでは通らない可能性が高く、アップグレード時に設定ファイルの書き換えが発生する。互換スキーマを採用した利点は、他ツール向けに書いた MCP サーバ定義を流用できる点にあるが、その代償として既存ユーザーには一度きりの移行作業が生じる。バージョンを固定して運用している場合は、上げる前に docs/mcp の記述と手元の設定を突き合わせる必要がある。
ストリーミングと表示まわりの設計判断
UI 側の変更も実装の性格を表している。README によれば、Markdown はトークンごとに再描画するのではなく、差分が届くたびに更新される方式へ変わった。長い応答が伸びるほど端末が重くなる問題への対処であり、応答速度そのものではなく描画コストを下げる変更だ。表示面では、枠線を排したアクセント中心のレイアウト、入力量に応じて伸びるプロンプト、[Image #N] というインラインの添付トークン、折りたたみ可能な thinking セクション、スピナーの代わりにトークン使用量を常時表示するフッターが挙げられている。ここから読み取れるのは、装飾よりも状態の可視性を優先する設計方針である。ただし画像添付の対応範囲や thinking の表示条件は README の記述だけでは判断できない。
向かない場面と、MCP クライアントとの役割の違い
oterm は端末で完結することを前提にしているため、画像や添付を視覚的に扱う作業や、複数ウィンドウを並べて比較する使い方には向かない。また Python 3.10 以前の環境では speak が使えず、extras 前提の機能を当てにした運用はできない。代替として挙げられるのは Claude Desktop や Cursor のような GUI の MCP クライアントだ。両者は mcpServers のスキーマを共有するが、提供する体験は異なる。GUI 側は設定ファイルの編集やツール呼び出しの確認を画面で行える一方、oterm は同じ設定を端末から扱い、モデルの切り替えとプロンプト入力をシェル上で完結させる。SSH 越しの作業や、キーボードだけで操作を閉じたい場合には oterm の形式が合う。逆に、MCP サーバの挙動を視覚的にデバッグしたいなら GUI 側の方が確認しやすい。
MIT ライセンスと更新コストの見積もり
ライセンスは MIT と明記されており、改変や再配布を含む利用が可能な条項として広く知られる類型である。ただし具体的な義務や同梱表記の要否は配布形態によって変わるため、法務判断はここでは扱わない。更新コストの面では、直近のリリースが 0.24.0 (2026-09-02)、0.23.1 (2026-08-06)、0.23.0 (2026-07-31) と約1か月間隔で並んでおり、マイナー番号が上がる頻度は低くない。README が breaking と明示した変更が実際に含まれているため、バージョンを上げるたびに設定ファイル、特に mcpServers ブロックと extras の指定を確認する運用が現実的だ。依存の中心が pydantic-ai である以上、その側のプロバイダ対応の変化も間接的に影響する。
編集部の結論
oterm は、Ollama をローカルで動かしながら複数プロバイダを同じ端末 UI で切り替えたい開発者、および Claude Desktop 互換の mcpServers 設定をそのまま持ち込みたい利用者に向く。一方、GUI で画像や添付を多用する用途、Python 3.10 以前の環境、MCP 設定を旧スキーマのまま固定しているチームには向かない。導入前に確認すべきは、利用中の pydantic-ai が対応するプロバイダ名と、手元の mcpServers ブロックが新スキーマに移行済みかどうかの2点である。
コミュニティノート