Qwen3.8-27B × Hermes Agent で調査エージェントを作る｜同じモデルのまま1時間48分→1時間5分にした実測【2026年8月】

PR｜この記事にはアフィリエイト広告を含みます。

自宅のRTX 3090で動かしている Qwen3.8-27B（Alibabaが公開している27B規模のオープンなモデル）に、Hermes Agent を被せて「ウェブ調査エージェント」を作った話。

お題は「日本の展望台8か所を公式サイトから調べて、比較HTMLを作る」。同じお題を何度か走らせて、そのうち最後まで走りきった2回を比べた。

実際に出てきた成果物がこれ。

写真も貼るし、列見出しをクリックすると並べ替わるし、「屋外エリアがある施設だけ表示」の絞り込みまで付けてきた。ここまでは最初の1回目から出せていた。

1回目は 1時間48分かかった。5回目までに 1時間5分まで縮んだ。モデルは一度も変えてない。変えたのはエージェント側の作りだけ。

で、いちばん効いたのは、たった1点だった。

先に結論だけ

• Webページの中身を、会話にそのまま入れない。取ってきた本文を丸ごと会話に載せると、KV（AIが会話を覚えておくためのメモリ）がすぐ埋まって落ちる。取ったものはいったんファイルに保存して、grep（キーワードで該当行だけを抜き出すコマンド）で必要な行だけ読ませる。これでKVがかなり節約できる
• ゴールの器を、いちばん最初に作らせる。調査を全部終えてから成果物を書かせると、その前にメモリが埋まって会話が勝手に圧縮され、出てくるものの質が落ちる。先に「何を埋めれば完成なのか」を1つのファイルに定義させて、作業しながら穴を埋めさせるルールにしたらうまくいった
• 細かい指示は、そのままだと読まれない。Hermes は標準のツール定義を読むだけで約6,000〜7,000トークン使う。そこにA4で2ページぶんの指示書を足しても、「このスキルを使って」みたいな細かいルールは通らない。Superpowers というプラグインを入れたら、作業に入るまでの時間は伸びたけど、進め方を先に考えるようになってやり直しが減った
• HTTP 429 は「回数超過」とはかぎらない。User-Agent（アクセス元の名乗り）を直したら、4/8失敗が8/8成功・15秒になった
• Qwen3.8-27B の品質自体は、最初から高かった。公表されていない数字をでっち上げる幻覚は0件。問題だったのは効率だけ

何を組んだのか

Hermes Agent は NousResearch が出してるエージェント。MITライセンスで、スキル・MCP（外部ツールをAIに繋ぐための共通規格）・ブラウザ操作・ターミナルが最初から入ってる。ローカルのモデルをそのまま繋げられるので、「自宅のGPUで動くエージェント」を作るならかなり手数が少ない。

お題の「展望台8か所」は自分で作った評価タスクで、公式サイトにしか載ってない数字（営業時間・料金・高さ）を取ってこないと埋まらないようにしてある。あと公表されていない項目を4つ混ぜてある。ここを「わからない」と正直に書けるかどうかを見たかった。

結果

どちらも8か所ぜんぶ埋めて完走している。違うのは43分。あとブラウザをVLMで見に行く作業が増えたこと。JSが多いページで特に効率良かったみたい。Claude DesktopのClaude in Chromeに似てるね。

ツールの使われ方を見ると差がはっきり出ていて、1回目は検索を1回も使わずに terminal を81回叩いていた。URLを手探りで当てにいっていたということ。2回目は terminal が30回まで減った。

そしてここが大事なんだけど、品質のほうは最初から高かった。仕込んだトラップ4問はほぼ全問正解で、「公表されていない数字をそれっぽくでっち上げる」幻覚は2回とも0件。わからないものは unknown と正直に書いてきた。

つまり27Bのローカルモデルでも、調査の中身はもう十分こなせる。潰すべきなのは効率だけだった。

いちばんの発見：Webページの中身を会話に入れない

ここが今回いちばん効いたところ。

エージェントは会話の履歴を KV（会話を覚えておくためのメモリ）に持っている。ここには上限があって、埋まると古い部分が切り捨てられるか、勝手に要約されて中身が薄くなる。そうなると同じページを取り直したり、さっき決めたことを忘れたりする。

完走した回は、terminal から curl でページを取ってきて、いったんファイルに保存していた。そして必要なところだけ読ませていた。

578万文字を取得 → 会話に載せたのは 18,771文字だけ → 完走

一方、Hermes の web_extract（ページ本文をそのまま返すツール）を使った回はこうなった。取ってきた本文が丸ごと会話に入る。

5ページ読んだだけで 80,045文字が会話へ（会話全体の65%）
まだ全体の1割しか埋まっていないのに 51,555トークンを消費 → 破綻

※トークン＝AIが文章を数える単位。日本語だとおおむね1文字が1〜2トークンくらい。

同じ情報を取っても、ファイル経由なら会話の消費が24分の1で済む。KVに上限がある以上、ここが完走と破綻を分ける。

やることは単純で、エージェントに「読ませる」んじゃなくて「置かせる」。置いたあと、grep（キーワードで該当行だけ抜き出すコマンド）で必要な行だけ拾わせる。これだけで体感がまるごと変わった。

MCP経由が特に危なかった。

crawl4ai （ブラウザ内容をテキストのマークダウン形式で取得するツール）を MCP 経由で呼ぶと、応答が丸ごと会話に入る。実際に測るとこうなった。

「ページのタイトルを取ってきて」と頼んだだけで最大 10,000文字が返ってくる。html も cleaned_html も media も links も全部入ってるから。ファイルを保存して必要な内容を検索で取り出せば 64文字で済む。同じことをやってるのに。

MCPは繋ぐのが本当に簡単なんだけど、簡単すぎて本文に全部ぶち込むみたいな動作になってしまって、解決方法あるのかもだけど。自分の場合は、Claudeに頼んでHermesのツールとしてCrawl4Aiは全てテキスト保存後に検索して取得というツールにした。MCP万能だと思ってたので、認識が変わった。

ゴールの器を、いちばん最初に作らせる

別の回で、こういう症状が出た。

「事実確認がほぼ完了しました。残り数点を確認します」
「残りのギャップを1回のバッチで埋めます」
「事実がほぼ確定しました。最後の確認をします」
「事実関係の最終確定のため、残りの確認点をまとめます」

「ほぼ完了」が延々と続いて終わらない。取得済みのファイルを40回も読み返して、残作業を数え直していた。

原因は、成果物を最後に書く手順にしていたこと。

調査を全部終えてから成果物をまとめさせると、その頃にはKVが埋まっていて、会話が勝手に圧縮されている。いちばん質がほしい最後の工程で、いちばん記憶が薄くなっている。しかも「あと何が残っているか」が会話の中にしかないので、毎回ファイルを読み返して数え直すことになる。

対策は、着手した直後に「何を埋めれば完成なのか」を定義したファイルを先に作らせること。全項目が空（null）の器を用意して、調べながらそこを埋めさせる。自分の場合は task.json を最初に作らせて、それを更新させるルールにしたらうまくいった。

# 手順1（最重要）：全項目が空（null）の task.json を先に作る
python3 - <<'EOF' > task.json
print(json.dumps({"items":[{"id":i, **{k:None for k in keys}} for i in ids]}))
EOF

# 残りの確認は「空欄を数える」だけ。取得済みファイルを読み返さない
python3 -c "import json;d=json.load(open('task.json'));\
print([(x['id'],k) for x in d['items'] for k,v in x.items() if v is None])"

これを入れた回では、ファイルの読み返しが 40回 → 0回になった。

エージェントの記憶を会話に持たせないで、ファイルに持たせる。さっきの「取得物をファイルに置く」と同じ話で、結局これが軸なんだと思う。

細かい指示は、そのままだと読まれない

ここがいちばん堪えた。

そもそもの前提として、Hermes は標準のツール定義を読み込むだけで約6,000〜7,000トークン使う。エージェントは起動した時点で、もうそれなりの量を抱えている。

そこにA4で2ページぶんくらいの指示書を足して業務の進め方を説明しても、「このスキルを使ってほしい」みたいな細かいルールは通らない。

理由のひとつがこれ。Hermes のスキルは、最初に読み込まれるのは名前と説明1行だけで、本文は skill_view（スキルの中身を開くコマンド）を呼んで初めて読まれる。

5回書き直したのに、skill_view が実際に呼ばれたのは5回中1回だけだった。つまり自分が書いたスキルは、ほぼ1文字も届いていなかった。

しかもタスクの指示に書いた番号付き手順のほうが、スキルより強い。タスク側に「5番目に成果物を書け」と書いてあったので、スキルに「最初に作れ」と書いても無視されていた。

解決したのは Superpowers だった

obra/superpowers（2026年8月24日時点で27万star超・MIT）というプラグイン。

これは pre_llm_call フック（AIを呼び出す直前に割り込む仕組み）を使って、毎回の呼び出しの前に指示を強制的に差し込む。skill_view を呼ばせる必要がない。

注入される文言がなかなか強い。

If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill.

さらに「スキル確認を飛ばす言い訳」を13パターン先回りして潰してある。

「これは単純な質問だから」→ 質問もタスクである。スキルを確認せよ
「先に文脈が必要だ」    → スキル確認は明確化の質問より前である

入れたあと、モデルの思考が目に見えて変わった。

efficient-web-research — 環境固有で非常に関連する → 読む
brainstorming — 適用外（創造的作業ではなく、定義済みタスク）
writing-plans — タスクに既に計画がある。不要

心配していた「ブレストの質問をし始めて止まる」も、モデル自身が理由をつけて却下した。ここは素直に感心した。

体感としては、作業に入るまでの時間は伸びる。すぐ手を動かさなくなるので、最初は遅くなったように見える。ただ進め方を先に考えるようになったぶん、やり直しが減った。デフォルトのHermes × Qwenは、とにかくすぐ作業に入ってしまうので、そこが変わったのは大きい。

ただし注意点がある。Hermes のプラグインスキャンで 212件の警告が出てブロックされる（CRITICAL persistence が72件など）。中身を見るとドキュメントの文章を拾った誤検知が大半なんだけど、そもそも「エージェントの初期指示を書き換える」ことが目的のフレームワークなので、スキャナの判定が的外れとも言い切れない。導入するかどうかは自分で判断してほしい。

最終的な構成

最後の「unknownは加点」は地味に効く。わからないものをわからないと書けるほうが、埋めようとして粘るより速いし正確。そこを評価する設計にしておくと、モデルが無駄に粘らなくなる。

この構成を組むなら、何が要るか

推論側：VRAM 24GB が下限

27Bクラスを4bitで動かすので、VRAM 24GBは要る。16GBだと載らないので、そこは最初から外していい。

自分の場合RTX 3090を使ってるが、Amazonで60万円近い転売価格になっていて、正価では実質もう買えない。今から新しく組むなら、VRAM 32GBのRTX 5090を積んだ完成品のほうがRTX3090世代と比べても２−３倍ぐらいの効率化にもなるのでお金に余裕があれば良い投資かと。。。RTX3090ならQwen3.8:27BはPrefill 800-1000, MTPを使って生成速度は50-70tok/s出るので快適。

Macの場合

GPUほど早くもないけど、最新のMacなら不満が一番ないかも。自分は M1 Max なのでQwen3.8:27Bとかを動かすとプリフィル150ぐらい, 生成14-18tok/sとかだけど。最新のM4、M5世代ならかなり早いみたいですね。Qwen3.6:35B-A3BとかMOEモデルだったら130tok/sとかでるらしい。。。

「1台で完結させたい」場合。GPU機を別に置かず、Mac側でモデルも動かすなら、ユニファイドメモリの量がそのまま効いてくる。なので最低48GB-64GB欲しいところかな。

14インチを基準にしていいと思う。16インチにすると画面が大きくなるぶん値段が上がるだけで、動かす速さは変わらない。持ち歩くなら14インチのほうが素直。

ここ、表を見て「48GBより64GBのほうが安いの？」と思うかもしれないので補足しておく。Amazonに並んでいるのは AppleCare+ 3年と2TB SSD が最初から付いた構成で、Apple公式の¥879,800は本体だけの値段。中身が違うので、そのまま引き算しないでほしい。

もうひとつ。32GBという選択肢は、M5（無印）と M5 Pro の15コアCPU版にしかない。この2つは帯域が153GB/s と 307GB/s で、M5 Max の460〜614GB/s とはだいぶ差がつく。メモリの量が足りても帯域が細いと生成が遅くなるので、1台で完結させたいならM5 Max以上を見たほうがいいと思う。

64GB以上はApple公式のCTO（注文時カスタマイズ）でしか選べない。Amazonの吊るしには出てこないので、そこは公式で組むことになる。エージェントを1台で回すつもりなら、自分なら14インチのM5 Maxで64GBを選ぶ。

ついでに、あると効くもの

本体の話ばかりになったので、安いほうも書いておく。どちらもこの構成を組むと確実に足りなくなるところ。

MacとGPU、そもそもどっちを選ぶかは前に書いたので、機材からの人はこっちを先に読んでもらうと早い。

ローカルLLMはMacとGPUどっちで動かす？｜MacBook Pro M1 Max・RTX3090の実測で選ぶ【2026年8月版】

Macでモデルを動かす場合の落とし穴（公式のMLX版から画像処理が抜けている件）はこっち。

MacのMLX版で画像が読めない原因｜公式変換でvisionが落ちていた話と、自分で量子化して1.6倍にした実測

当サイトはAmazonアソシエイト・プログラムの参加者です。適格販売により収入を得ています。

まとめ

• 同じモデル・同じお題で 1時間48分 → 1時間5分。効いたのはモデル選定じゃなくて運用設計
• Webページの中身を会話に入れない。ファイルに置いて、grepで必要な行だけ拾う。KVの消費が24分の1になる
• MCPは万能じゃない。受け取る側が応答の量を制御できないので、大量のテキストを返すサービスとは相性が悪い
• ゴールの器を最初に作らせる。成果物を最後に書かせると、いちばん質がほしい工程でKVが枯れている
• 細かい指示は読まれない。通したいなら、呼び出しの直前に割り込んで差し込むしかない
• 429を見たらUAを疑う。待っても直らない失敗がある
• 27Bのローカルモデルでも、調査の中身はもう十分こなせる。幻覚は0件だった

数値はいずれも 2026年8月23〜24日に自宅環境で計測した単発（n=1）の実測で、統計的に均した値ではない。Chrome の承認ダイアログまわりは、回避策をこちらで検証しきれていないので未確立として書いている。GitHubのstar数は2026年8月24日時点。ソフトウェアの挙動はバージョンで変わるので、判断の前に自分の環境で確認してほしい。