何が起きたか
コマンドラインからLLMを扱うツール「LLM」向けのプラグイン、llm-anthropicがバージョン0.26をリリースしました。本体であるLLM 0.32の機能を前提とした更新で、依存関係もllm>=0.32に引き上げられています。
追加されたモデルはclaude-fable-5、claude-sonnet-5、claude-opus-5の3つ（issue #75、#76）。あわせてWebSearch、WebFetch、CodeExecution、AnthropicMCPがサーバーサイドツールとして実装され、LLMの-Tインターフェース、あるいはPythonのtools=から呼び出せるようになりました。これに伴い、以前の-o web_search*系オプションは-T WebSearchに置き換わる形で削除されています（issue #79）。
なぜ重要か——「オプション」から「ツール」への構造変化
注目すべきは機能追加そのものより、インターフェースの整理の方向性です。Web検索という個別機能が、モデル固有のオプション（-o）ではなく、汎用のツール指定（-T）に移されました。これは、Web検索もコード実行もMCP接続も「モデルに渡せるツールのひとつ」として同じ棚に並べる、という設計判断です。
利用者から見れば、ツールを差し替えても呼び出し方の作法が変わらない。プラグイン側から見れば、新しいサーバーサイド機能が増えても既存の文法を壊さずに追加できる。個別最適なフラグが増殖してCLIが読めなくなる、という典型的な劣化を避ける動きと読めます。
推論プロセスが「見える」ことの意味
LLM 0.32への追随により、推論（reasoning）、ツール呼び出し、ツール実行結果、サーバーサイドツールの結果が、すべて型付きイベントとしてストリーミングされるようになりました。llm CLIでのプロンプト実行時には、推論内容が標準エラー出力に表示されます。抑制したい場合は-R／--hide-reasoningを渡すと、応答とログの両方から推論が除かれます。
標準出力ではなく標準エラーに出す、という選択が実務的です。llm ... > result.txtのようなパイプ処理では推論が混ざらず、ターミナルで対話しているときだけ思考過程が見える。自動化と観察を両立させる設計です。
Extended thinkingの整理とClaude 5の既定挙動
拡張思考の設定はthinkingとthinking_effortの2つに集約されました。effortはlow、medium、high、xhigh、maxの5段階です。従来のthinking_budget、thinking_display、thinking_adaptiveは削除されています（issue #80）。
重要なのは既定値の変更です。Claude 5系のモデルは既定で思考します。Sonnet 5とOpus 5は-o thinking 0で思考を無効化できますが、Fable 5は常に思考する仕様です。トークン数を直接指定するthinking_budgetが消え、抽象度の高い5段階の指定に変わったことは、推論量の細かなチューニングをアプリケーション側からモデル側へ委ねる方向を示しています。
💼 事業会社視点：これは自社にどう効くか
直近で効くのは破壊的変更への対応です。-o web_search*とthinking_budget／thinking_display／thinking_adaptiveが削除されたため、llm-anthropicをバッチやCIに組み込んでいる受託開発会社・SaaS事業者は、0.26への更新でスクリプトが動かなくなる可能性があります。バージョンを固定しているなら移行計画を、していないなら今すぐ棚卸しを指示すべきです。
中期で効くのはコスト設計です。Claude 5系が既定で思考し、Fable 5は無効化できない以上、「同じプロンプトを投げれば同じ費用」という前提は崩れます。ECの商品説明生成やカスタマーサポートの一次回答のような大量・定型の処理では、Sonnet 5／Opus 5に-o thinking 0を明示するか、thinking_effortをlowに寄せるかを、案件単位で決める必要があります。逆に契約書レビューや与信判断のような少量・高難度の処理では、xhighやmaxを使い切る判断が合理的です。推論の強さが、事業責任者が握るべきコストレバーになったと捉えるべきです。
もう一点、推論が標準エラーに出るようになったことは、AI利用のガバナンス上の材料になります。日本企業でよく問題になる「なぜこの出力になったのか説明できない」に対し、-Rで落とすか記録するかを組織として決める——その判断を今のうちに情シスとリスク管理部門に振っておくのが賢明です。