LLM CLI v0.32 徹底解説 — 推論トレース・サーバーサイドツール・新ログスキーマ

LLM CLIとは、Simon Willison氏が開発しているオープンソースのコマンドラインツールで、OpenAIやAnthropic、Google、Ollamaで動くローカルモデルなど数十のLLMを、単一のllmコマンドで統一的に呼び出せるようにするものだ。プロンプトの実行、会話ログのSQLite保存、プラグインによるモデル追加、シェルパイプとの連携までを1つのCLIでこなす。

2026年8月4日にリリースされたv0.32は、開発者自身が「プロジェクト開始以来最大の後方互換アップデート」と位置づける大型版だ。標準エラー出力への推論トレース表示、OpenAI/Anthropicのサーバーサイドツール呼び出し、ログ保存の仕組みそのものを刷新する新SQLiteスキーマ、Python API向けのmessages=パラメータ導入という4本柱が中心で、既存のプロンプトやスクリプトはそのまま動く設計になっている。

- 数十のLLMプロバイダー（OpenAI、Anthropic、Google Gemini、Ollamaなどのローカルモデル）をプラグインで追加し、1つのコマンド体系で呼び出せる
- 実行したプロンプトと応答をすべてSQLiteデータベースに自動記録し、あとから検索・全文検索できる
- 画像・音声などのマルチモーダル入力をアタッチメントとして渡せる
- cat file | llm -s "..."のようにUnixパイプと組み合わせて、コードレビューや要約などのシェルワークフローに組み込める
- 対話モード（llm chat）とワンショット実行の両方に対応
- Pythonライブラリとしてもインポートでき、スクリプトやツールに組み込める

LLM CLIの中核にあるのは「プラグインでモデルを足していく」という設計思想だ。本体はモデルを1つも同梱せず、llm install llm-anthropicやllm install llm-ollamaのようにプラグインを追加することで対応プロバイダーが増えていく。これにより、新しいモデルファミリーが登場してもCLI本体を待たずにプラグイン単位で追従できる。0.32のリリースに合わせてllm-anthropicが0.26へ更新され、Anthropic側のサーバーサイドツールに対応したのも、この設計が効いた例といえる。

既存インストールをアップグレードする場合は、それぞれのパッケージマネージャのアップグレードコマンド（uv tool upgrade llmやpipx upgrade llmなど）を使う。0.32はログ保存の内部スキーマを刷新しているため、アップグレード前にllm logs backup logs-backup.dbを実行してログファイルのバックアップを取っておくことが推奨されている。

インストール直後、APIキーなしで使えるプロバイダーはないため、まずllm keys set openaiのようにキーを登録する。デフォルトモデルは0.32からGPT-5.6ファミリーの低コスト版「GPT-5.6 Luna」に変わったため、llm 'prompt'だけで最初の応答が返ってくる。

推論（reasoning）対応モデルを使うと、モデルの思考過程が標準エラー出力にストリーム表示されるようになった。標準出力（stdout）はプロンプトの最終応答だけが流れるクリーンな状態を保つため、llm '...' | jqのようにパイプで後続処理につなげても壊れない。推論トレースを表示したくない場合は-R/--hide-reasoningフラグで抑制できる。

OpenAIの推論系モデル（GPT-5系など）を使う際、内部的に呼び出すエンドポイントが/v1/responsesにデフォルトで切り替わった。これによりツール呼び出しをまたいだ推論の継続性が保たれ、マルチターンのツール利用シナリオで一貫した挙動が期待できる。

OpenAIのWebSearchやCodeInterpreterといったサーバーサイドで実行されるツールを、CLIから直接呼び出せるようになった。例えばllm --tool CodeInterpreter '...'のような形でコード実行をモデル側に委任できる。Anthropic向けプラグインllm-anthropicも0.26でWebSearch・WebFetch・CodeExecution・AnthropicMCPを追加しており、両陣営のサーバーサイドツールがLLM CLI経由で扱えるようになった。

会話履歴を記録するSQLiteログが、Gitのオブジェクトストアに近い「content-addressable」な方式に刷新された。同一内容のメッセージをハッシュで参照する形になり、重複した記録を避けつつ、モデルやツール名での絞り込みや全文検索がしやすくなっている。スキーマが変わるため、アップグレード前のllm logs backup logs-backup.dbによるバックアップが推奨されている。

- llm openai endpoint: 任意のOpenAI互換エンドポイントに対してログを残さずワンライナーで実行できる新コマンド。ローカルで立てた推論サーバーの動作確認に向く
- llm -m MODEL --options: 指定モデルが受け付けるオプションの一覧を表示
- llm prompt --json: 応答をJSON形式で受け取る
- -o service_tier fast/flex: OpenAIのサービスティアを指定するオプション

Pythonライブラリとして使う場合、model.prompt(messages=[...])のように会話履歴全体をmessages=パラメータで渡せるようになり、llm.user()・llm.assistant()・llm.system()といったヘルパー関数でメッセージを組み立てられる。応答側ではresponse.stream_events()で推論やテキストなど構造化されたイベントを逐次処理でき、response.to_dict()/from_dict()でシリアライズ、Response.log_to_db()で任意のタイミングでのログ保存が可能になった。またツール実装がllm.PauseChainを送出することで、人間の承認を待つために実行を一時停止し、あとから再開できる仕組みも入った。

「CLIからLLMを使う」ツールはLLM CLI以外にも複数存在する。それぞれ用途の重心が異なるため、目的に応じて使い分けるのが現実的だ。

要するに、Ollamaが「ローカルでモデルを動かす」ためのランタイムであるのに対し、LLM CLIは「動いているモデル（ローカルでもクラウドでも）をコマンドラインから統一的に呼び出し、履歴を残す」ための薄い共通レイヤーという位置づけになる。ローカルLLMのツール選定についてはOllama vs LM Studioの比較記事も参考にしてほしい。

特にログ管理の観点では、LLM CLIは他のCLIチャットツールと一線を画す。多くのツールが会話履歴をその場限りのターミナル出力として消費するのに対し、LLM CLIは実行したすべてのプロンプトと応答をSQLiteデータベースに構造化して蓄積する。0.32でこのログ機構がcontent-addressableな方式に刷新されたことで、モデルをまたいだ横断検索や、特定のツール呼び出しだけを抽出するといった運用が現実的になった。単発のプロンプト実行ツールというより、「LLM利用の記録基盤」として捉えたほうが実態に近い。

LLM CLIはクラウドAPI専用ではない。llm-ollamaプラグインを導入すれば、Ollamaでホストしているローカルモデルも同じllm -m モデル名 'プロンプト'という形式で呼び出せる。クラウドモデルとローカルモデルを同じログDB・同じコマンド体系で扱えるのが利点だ。0.32で追加されたllm openai endpointも、ローカルで立てたOpenAI互換の推論サーバー（vLLMやLM Studioのサーバー機能など）に対して、ログを残さずワンライナーで疎通確認したいときに使える。ローカル環境の構築やターミナル作業の効率化についてはHunkのターミナルdiffビューア記事も参照。

本記事は以下の一次情報をもとに執筆した。
- Simon Willison, "A new release of LLM" https://simonwillison.net/2026/Aug/4/new-release-of-llm/
- LLM Releases (GitHub) https://github.com/simonw/llm/releases
- LLM 公式ドキュメント https://llm.datasette.io/