bigkijimon

「ollamaにエージェント機能が入った」というリリースノートを見て、自分のMacでollama agentを叩いたらunknown command "agent"で撃たれた——という人向けの記事です。結論から言うと、うちのM1 Max 64GB本番機は今も Ollama 0.30.8 のままで、agent サブコマンドは存在しません。そしてそれは「更新し忘れた」のではなく、意図して上げていません。理由を実測とうちで実際に起きた事故から書きます。

本番機の実測 — バージョンは0.30.8、agentは無い

まず自分の手元で叩いた結果です。

$ ollama --version
ollama version is 0.30.8

Enter fullscreen mode Exit fullscreen mode

--helpのコマンド一覧にも agent は無く、serve / create / show / run / stop / pull / push / list / ps / cp / rm / launch までしかありません。実際に叩くとこうなります。

$ ollama agent
Error: unknown command "agent" for "ollama"

Enter fullscreen mode Exit fullscreen mode

リリースノートで謳われている機能が、自分の手元のバイナリには物理的に存在しない状態です。

リリースノートは何を約束しているか

Ollama公式のリリースノート本体はこの記事では開いていません（うちのブログ生成パイプラインは無人運転区間で外部Webを一切読まない設計にしています。理由は後述の「自律実行」の話と地続きです）。社内の別便が事前に検証・要約した一文だけを引用します。

v0.32.0（2026-07-11）で、ollamaを実行するとエージェントが起動し、コードを書いたりWeb検索をしたり実作業を委任できるようになった。

つまり「モデルを1回呼んで応答を受け取る」ツールから、「エージェントが自律的に複数ステップの作業を進める」ツールへと性格が変わったのが0.32系、という理解です。

Homebrewを見ても本番機のバージョンは分からない

「じゃあHomebrewで確認すればいいのでは」と思って叩いたのがこれです。

$ brew info ollama
==> ollama: stable 0.32.1 (bottled), HEAD
...
Not installed

Enter fullscreen mode Exit fullscreen mode

Homebrewのカタログ上のstable版はすでに0.32.1まで進んでいます。しかし「Not installed」——つまりこのMacはOllamaをHomebrewで入れていません。実体は/Applications/Ollama.app（Electronベースのメニューバーアプリ）で、/usr/local/bin/ollamaはそのアプリ内バイナリへのシンボリックリンクです。

$ defaults read /Applications/Ollama.app/Contents/Info.plist CFBundleShortVersionString
0.30.8

Enter fullscreen mode Exit fullscreen mode

アプリ本体のディレクトリ日時を見ると、最後に置き換わったのは2026-06-12。それ以降アップグレードしていません。「brewでバージョン確認」は、インストール経路が違うツールには効かないという、地味だが実際に踏む罠でした。

なぜ上げない判断をしたか（1）— 同じアプリの設定DBで7モデルが消えた前例

この判断は「新機能が怖いから様子見」という抽象的な慎重論ではありません。うちには2026-07-14に、同じOllama.appのアップデート絡みの作業で実際に事故った記録があります。

ollama listが突然1モデルしか返さなくなり、ディスク上のmanifestファイルは無傷なのに他の6モデルが見えなくなりました。真因はOllama.appの設定DB（~/Library/Application Support/Ollama/db.sqlite）のsettings.modelsカラムが、誤ってモデル階層の1サブフォルダを指すようになっていたことでした。厄介だったのは、このアプリ内設定がlaunchctl setenvや起動時plistのOLLAMA_MODELS環境変数より優先されるという点です。環境変数を直しても直らず、最終的にdb.sqliteを直接UPDATE文で書き換えて復旧しました。

つまり「バージョンやアプリの状態が変わると、設定の扱われ方そのものが変わって既存の環境を壊す」ケースが、このツール・このMacでは既に実物として起きています。0.32系は挙動が「応答を返すだけ」から「自律的に複数ステップ進める」へ変わる更新です。設定スキーマや内部状態の扱いが変わっていないという保証はどこにもありません。

なぜ上げない判断をしたか（2）— このMacは検証機ではなく共有本番機

もう1つの実測です。今この記事を書いている最中も、同じMacでこれが動いています。

$ ps aux | grep ollama
yuma  93913 ... llama-server --model .../qwen3-coder-next ... --port 55433 -np 1 --flash-attn on ...
yuma  1088  ... ollama serve
yuma  1076  ... Ollama hidden

Enter fullscreen mode Exit fullscreen mode

このMac（M1 Max 64GB）は「試しに新機能を触ってみる」ための隔離された検証機ではなく、社内でローカルQwenを本番運転している共有機です。GPUは物理1つしか無いため、画像/動画/音楽生成とLLM推論は同じVRAMを奪い合い、社内では生成コマンドを1つずつ直列に流す調停スクリプトを既に運用しています。長時間の動画・音楽生成中はOllama側が凍結され続けることも社内で把握済みです。

ここに「エージェントが自律的にWeb検索やコード実行を何ステップも積む」機能が乗ると、外側の直列調停スクリプトからは「1回の生成コマンドがどれだけの時間・どれだけの内部ステップを勝手に消費するか」が見えなくなります。1コマンド=1プロセスという単純な前提の上に組んである調停の外側で、エージェントが何をどれだけやるか分からない状態を、動いている共有機に無条件で持ち込みたくありませんでした。

上げる/上げないをどう判断するか

今回の判断から一般化できる、共有GPU機でツールをアップグレードするかどうかのチェックリストです。

  • まず自分の手元で叩く。リリースノートの主張とインストール経路（Homebrew/公式アプリ/手動ビルド）は別物。--versionと--helpを実際に叩いて現物を確認する。

  • 過去にそのツールで事故った記録があるか探す。設定ファイル・内部DB・環境変数の優先順位が変わるアップデートは、既存の壊れ方を再演する可能性がある。

  • その機体が検証機か本番機かを確認する。ps auxで今何が動いているかを見る。共有本番機なら、新機能の挙動を実機で試す前に切り分けが要る。

  • 新機能が既存の運用ポリシーと衝突しないか。自律的にWeb検索やコード実行を行うエージェント機能は、既存の承認フローや直列調停の前提を静かに壊しうる。

この4つのどれか1つでも答えが出ない間は、「保留」も正しい判断です。リリースノートの新機能は魅力的に書かれていますが、それと自分の本番機の現物との間には、実測しないと見えないドリフトがあります。