HermesとQwenで見えたローカルLLMエージェント運用の信頼性問題

Hermes Agentを、ローカル環境へリモートから作業を頼むための窓口として使っている。

メッセージングアプリから自然文で依頼して、ローカル側のエージェントが内容を解釈し、必要な道具を選び、作業を進める。うまく動けば、これはかなり便利だ。ちょっとした要約、下書き、調査の整理、メモ作成のような作業なら、いちいちMacの前に戻らなくても進められる。

そのバックエンドを、できるだけローカルLLMへ寄せられないか試していた。理由は単純で、コストと利用制限を減らしたいからだ。毎日の細かい依頼まで全部クラウド側の高性能モデルに投げると、心理的にも運用的にも少し重い。ローカルで動くQwen系モデルが十分使えるなら、日常的な作業のかなりの部分をそちらへ逃がせる。

ただ、実際に使ってみると、問題は「文章が書けるか」ではなく「エージェントとして信用できるか」だった。

低リスク作業では十分使える

まず、ローカルQwen系モデルがまったく使えないという話ではない。

相談、要約、アイデア出し、下書きのような作業では、十分便利に感じる場面が多い。多少表現が粗くても後で直せるし、少し外しても大きな事故にはならない。むしろ、手元で気軽に回せることの価値は大きい。

例えば、作業ログを渡して「ブログの元ネタとして整理して」と頼む。長いメモを短くする。比較観点を出す。文章の構成案を作る。こういう用途では、ローカルLLMはかなり実用的だと思う。

ローカルで動くので、試行錯誤もしやすい。プロンプトを変えて何度も投げ直すことへの抵抗が少ない。日常の作業補助としては、この気軽さはかなり大きい。

問題は副作用のあるタスク

一方で、リマインダー作成、ジョブ実行、ファイル操作、設定変更のような「失敗すると困るタスク」になると、急に見え方が変わる。

こういう作業では、単に自然文をそれっぽく理解するだけでは足りない。

必要なのは、依頼の意図を補完し、どの道具を使うべきかを選び、実行し、その結果が本当に期待どおりになっているかを確認することだ。さらに、失敗した場合は、次回同じ失敗をしないように運用ルールへ落とし込んでほしい。

ここで不安定さが出ると、エージェントとしての信用が一気に落ちる。

例えば「時間指定でリマインドして」と頼んだとする。人間の感覚では、これはリマインダー作成に向いた仕組みを使い、指定時刻、通知内容、保存先、実際に登録されたかどうかまで確認してほしい依頼だ。

ところが、モデルによっては、ジョブ実行寄りの仕組みに寄ってしまうことがある。もちろん、それでも実装次第では動くかもしれない。ただ、必要な設定や実行後確認が抜けると、最終的な成功率にそのまま響く。

リマインダーは、失敗してから気づくタイプのタスクだ。指定時刻になって通知が来なければ、その時点でもう遅い。だからこそ、エージェントには「登録したつもり」ではなく「登録されていることを確認した」ところまで期待してしまう。

エージェントに期待している価値

ここで、自分がエージェントに何を期待しているのかがはっきりした。

期待しているのは、単なる命令実行ではない。

自然文の依頼を受け取り、文脈を理解し、適切な道具を選び、実行し、検証して、必要なら失敗を次回のルールへ反映する。この一連の作業完了能力に価値を感じている。

毎回こちらが細かく「このAPIを使って」「この設定を確認して」「登録後に読み返して」「失敗したらこのログを見て」と書かなければならないなら、それはもはや便利な秘書ではなく、少し自然文に対応したCLIに近い。

もちろん、CLIにも価値はある。ただ、メッセージング経由のエージェントに期待している体験は少し違う。こちらは「やっておいて」と頼みたい。手順書を毎回書きたいわけではない。

この差が、ローカルLLMエージェント運用の難しさだと思う。

役割分担が現実的

今の感覚では、すべてをローカルLLMへ寄せるより、作業のリスクで分けるのが現実的だ。

低リスクな作業はローカルLLMでよい。

• 下書き
• 要約
• アイデア出し
• メモ整理
• ブログ元ネタの構造化
• 失敗しても後から直せる調査補助

一方で、信用が必要な作業は、より安定したモデルや既に検証済みの実行環境へ寄せたい。

• リマインダー作成
• 定期ジョブの変更
• ファイル移動や削除
• 設定ファイルの更新
• git commit / push
• 外部サービスへ反映される操作
• 実行後の検証が必要な作業

この分け方にすると、ローカルLLMの良さを活かしつつ、事故が困る領域では慎重にできる。

ローカルLLMを否定したいわけではない。むしろ、かなり使いたい。安く、速く、手元で回せるのは強い。ただ、エージェント用途では、モデルの賢さだけでなく、タスクの種類、使える道具、検証の仕組み、失敗後の学習ループまでセットで考える必要がある。

失敗をルール化する仕組みが必要

もう一つ感じたのは、「一度失敗したら、次は成功してほしい」という期待は、自然だが自動では満たされないということだ。

人間のアシスタントなら、失敗した作業を覚えて、次から確認手順を増やす。例えば「リマインダーは登録後に読み返す」「定期ジョブは有効状態まで確認する」「ファイル操作は移動後の存在確認をする」といったルールを持つ。

エージェントにも同じことを期待したいが、それには仕組みがいる。

失敗したタスクを、その場の会話だけで終わらせず、ローカルルール、スキル、チェックリスト、Automationのプロンプトに落とし込む。次回以降は、モデルの思いつきではなく、必ずそのルールを読んでから実行する。

この「失敗を運用ルールに変換する部分」がないと、同じ種類の不安が繰り返される。

まとめ

Hermes AgentとローカルQwen系モデルの組み合わせは、日常作業の補助としてかなり可能性がある。

ただし、エージェントとして任せる範囲は慎重に決めた方がいい。相談や下書きのような低リスク作業ではローカルLLMを活用し、リマインダーやジョブ実行のような副作用ありタスクでは、より信頼できる実行系と検証手順を使う。

結局、エージェント運用で大事なのは、モデル単体の性能比較だけではない。

どの作業を任せるのか。失敗したら何が困るのか。実行後に何を確認するのか。失敗をどう次回のルールにするのか。

ローカルLLMを本当に日常のリモート秘書として使うなら、このあたりの設計が必要になる。安く動くことと、信用して任せられることは、似ているようで別の問題だった。