何が変わったか
LLM 0.34の新機能は一点に絞られています。llm logs --usageが出力するMarkdownに、応答にかかった時間がミリ秒単位の数値と人間が読みやすい表記の両方で含まれるようになりました。あわせてllm logs --shortにもduration_msというフィールドが加わっています。この変更は#1653として管理されています。
それ以外は、複数の外部コントリビューターによるバグ修正と、waveplate氏が寄せたllm logsのパフォーマンス改善です。リリースノートからはllm-openrouter 0.7.1にも案内が出ています。機能追加としては地味な部類ですが、意味合いは小さくありません。
なぜ「実行時間の記録」が効くのか
LLMは、コマンドラインからさまざまなモデルを呼び出し、その履歴をローカルのログに蓄積するツールです。これまでもトークン使用量は--usageで確認できましたが、そこに欠けていたのが「どれだけ待たされたか」でした。
生成AIを業務に組み込むとき、評価軸は大きく三つあります。出力品質、コスト（トークン量）、そしてレイテンシです。このうちレイテンシは、体感品質を決めるにもかかわらず、後回しにされがちな指標です。チャットUIなら数秒の遅延は許容されても、バッチ処理で数千件を回す用途、あるいは社内システムの応答経路に組み込む用途では、1リクエストあたりの秒数がそのまま処理能力とインフラ費用に直結します。
duration_msがログの標準フィールドになったということは、トークン量とレイテンシを同じログから、同じ粒度で比較できるようになったということです。「モデルAはトークン単価が安いが3倍遅い」といった比較が、専用の計測コードを書かずに手元で取れる。ここが実務上の変化点です。
点をつなぐ：ログが評価基盤になる
注目すべきは、同じリリースにllm logsのパフォーマンス改善が含まれていることです。ログ機能に速度改善が必要になるのは、ログが「たまに覗くもの」ではなく「大量に蓄積し、繰り返し集計するもの」になっている証拠です。
つまりこのツールの重心が、単発のプロンプト実行から、蓄積された実行履歴の分析へと移りつつある。新フィールドの追加と閲覧性能の改善が同時に来たことは、その方向性を示しています。モデル選定を勘や評判ではなく、自分たちのプロンプトと自分たちのデータで測った数字で決める——その土台がコマンドライン一本の中に整いつつあります。
💼 事業会社視点：これは自社にどう効くか
受託開発・SIerにとって：AI機能の見積もりで最も揉めるのが「レスポンスが遅い」というクレームです。duration_msが標準で記録されるなら、提案段階で複数モデルの実測レイテンシ分布を取り、SLAの数値根拠として提示できます。「体感が遅い」を「95パーセンタイルで何ミリ秒」に変換できるかどうかで、瑕疵担保の議論の質は変わります。
SaaS事業者にとって：AI機能の粗利はトークン単価だけでは決まりません。同時接続あたりの処理時間が長ければワーカー数が増え、インフラ費用が膨らみます。レイテンシとトークン量を同一ログで突き合わせられるようになった以上、「単価×トークン」だけの原価計算は見直す価値があります。
EC・事業会社の責任者にとって：商品説明生成やレビュー要約のような大量バッチ処理では、1件あたり数百ミリ秒の差が総処理時間で数時間の差になります。
打ち手はシンプルです。技術部門に対し、自社の代表的なプロンプト20〜30本で複数モデルのレイテンシとトークン量を実測し、一枚の表にして出すよう指示してください。ベンダー資料の数字ではなく自社データで測る。LLM 0.34は、その計測を専用ツールなしで始められる状態にしたリリースです。