自宅の GPU で動くローカルLLM に、こう頼んでみた。
「東京の港区で、イタリアン・寿司・焼肉・ラーメンの人気店をトップ3ずつ調べて、写真付きの特集ページを1枚作って」
調べるところから、口コミを読んで要点をまとめて、写真を集めて、HTML を書いて、最後にブラウザで開いて崩れていないか確認するところまで。全部ひとりでやらせた。
結論から言うと、できあがった。 しかも、途中で自分の間違いに気づいて直しながら。
できたページは、4ジャンル×3店の12枚のカードに、写真・食べログ評価・看板メニュー・高評価点・不満点・出典リンクが並ぶ1枚もの。ダークな配色でまとめられていて、正直そのまま公開できる出来だった。
使ったのは Qwen3.8:27B というオープンモデルと、Hermes というエージェントの組み合わせ。前に Qwen3.8-27B は賢さより粘り強さに振ったモデルという記事で「エージェント用途に全振りしてる」と書いたので、今回はその答え合わせでもある。
やらせたこと
Hermes Agent に Qwen3.8-27B をぶら下げて、こう投げた。
東京の港区で、イタリアン・寿司・焼肉・ラーメンの人気店をそれぞれトップ3ずつ選んで紹介する、HTMLページを1枚作ってほしい。
ネットの口コミを実際に見て、「なぜ人気なのか」が具体的に分かるようにして。高く評価されている理由と、逆に不満として挙がっている点、それと看板メニュー。写真も入れて、見て楽しいページにして。
写真は、店の公式サイトか公式SNSのもの、もしくはライセンスがはっきり分かる素材だけ使って。使った写真は、取得元URLとライセンスをページ内に明記して。口コミは本文をそのまま貼らずに、傾向を自分の言葉でまとめて。各店に、情報の出典URLも付けて。
できたら index.html に保存して、ブラウザで開いて表示が崩れていないか自分で確認してから終わりにして。
環境は M1 Max の macOS。作業はサンドボックス配下で完結させ、新しいツールのインストールは禁止。使えるのは curl と macOS 標準の sips、それと Python 標準ライブラリだけ。
実際に何が起きたか
まず数字から。
| 項目 | 実績 |
|---|---|
| 収集した生データ | 76ファイル / 19MB |
| ダウンロードした候補画像 | 77枚 / 29MB |
| 最終的に採用した画像 | 12点（採用率 16%） |
| 紹介した店舗 | 12店（4ジャンル × TOP3） |
ツールの呼び出し回数がこれ。
| ツール | 用途 | 回数 |
|---|---|---|
execute_code（Python） |
HTMLパース、JSON-LD抽出、画像URL抽出、集計 | 40回超 |
vision_analyze |
画像が料理写真かどうかの検証 | 40回超 |
terminal |
curl でのダウンロード、sips 変換 | 20回超 |
web_search |
公式サイト・公式SNSの特定 | 10回超 |
browser_exec |
JSレンダリング試行、完成ページの表示確認 | 複数回 |
合計で100回を優に超える。前の記事で「手数は多いけど一回ごとの判断は難しくない作業」と書いた、まさにそれが起きてる。
面白かったのは、自分で間違いに気づいた場面
数字より、こっちのほうが本題だと思う。
1. 集めた画像を自分で検品して弾いた
77枚集めて12枚しか使っていない。何をしていたかというと、ダウンロードした画像を1枚ずつ vision_analyze にかけて「これは料理写真か、店内写真か、テキストの告知画像か」を判定していた。
- 八面六秘の1枚目 → テキストの告知画像だったので弾いて、別URLから料理写真を取り直し
- FORNOの1枚目 → 店内写真だったので弾いて、スライド画像から完成した料理の写真に差し替え
「画像を取ってきて貼る」で終わらず、貼る前に中身を見て、違ったら取り直している。指示には「料理写真を選べ」とまでは書いていない。
2. ツールの制約に自分で回避策を作った
vision_analyze が WebP を安定して読めなかった。ここで止まらずに、macOS 標準の sips で PNG に変換してから検証を通している。新しいツールを入れるなという制約の中で、手元にあるもので迂回した。
3. 自分の作ったページを開いて、崩れを確認した
最後に browser_exec で file:// として自分の成果物を開き、
- JS で画像12枚の読み込み状態、横方向のオーバーフロー、カード数・セクション数を自動チェック
- スクリーンショットを撮って
vision_analyzeで目視確認
ここで scroll-behavior: smooth のせいでスクロール系の JS がタイムアウトした。これも自分で scrollBehavior='auto' に設定して解決している。
4. 素材が見つからないとき、嘘をつかずに代替した
ラーメンの2店で公式写真にたどり着けなかった。
- 入鹿TOKYO → 公式は ameblo のブログのみ。JSレンダリングで curl では画像URLが取れず、RSS も JS 依存で断念
- 天鳳 → 公式サイトも公式SNSも特定できず
この2店は自分で SVG のイラストを描いて代用し、ページ内に「公式写真が見つからなかったため」と明記した。適当な画像を拾ってきて誤魔化す、という逃げ方をしていない。ここは素直に良いと思った。
で、人間が止めるしかなかったところ
ここからが、この記事で一番書きたかったところ。
権利の判断だけ、きれいに外した
成果物のクレジット欄は、正直よくできている。全12店ぶんの取得元URL、©の権利表記、SVG代用の説明、「口コミは本文を引用せず傾向をまとめたもの」という注記、アクセス日まで書いてある。指示に忠実に動いた結果としては満点に近い。
ただし自分の指示は「ライセンスがはっきり分かる素材だけ使って」だった。
飲食店の公式サイトに載っている料理写真は、ほぼ例外なく All rights reserved で、ライセンスが明示された素材ではない。出典と©を書けば使える、という話ではない。ページには「店舗紹介の目的で引用しています」と書かれているが、それは引用の要件を満たしているかどうかとは別の話になる。
つまりこのエージェントは、「出典を明記する」は完璧にやったのに、「ライセンスが明確かどうかを判定する」はやっていない。前者は手続きで、後者は判断だからだと思う。
公開を前提にした仕上げもしていなかった
もうひとつ。貼られていた画像を自分で測ったら、トップの1枚が 3000×2000px・4.4MB のままだった。ローカルで開くぶんには気にならないが、Web に置くなら論外のサイズ。
公開用に自分で最適化したらこうなった。
| 最適化前 | 最適化後 | |
|---|---|---|
| 画像12点の合計 | 8,581KB | 855KB（-91%） |
| 最大の1枚 | 4,494KB | 104KB |
長辺1200pxに縮小してJPEG品質82で保存し直しただけ。エージェントは「表示が崩れていないか」は確認したが、「これを公開して大丈夫か」は見ていない。指示していないので当然ではある。
まとめ：どこまで任せて、どこで止めるか
やらせてみて、線がかなりはっきりした。
任せて回るもの
- 調べる、集める、パースする、集計する
- 集めたものを検品して、違ったら取り直す
- ツールの制約にぶつかったときの迂回
- 自分の成果物を開いて表示を確認する
- 素材が無いときに、無いと明記して代替する
人間が止めるもの
- 権利の判定（出典を書くことと、使っていいかの判断は別)
- 公開してよい品質か（ページ速度、画像サイズ）
- そもそも公開するか
前の記事で「Qwen3.8 に判断をさせない、答えが検証できる作業だけ投げる」と書いた。今回はその線がどこにあるかを、具体的に踏んで確かめた形になった。手続きは任せられる。判断は返ってこない。
逆に言えば、100回以上のツール呼び出しを最後まで走り切って、途中で画像を検品して取り直して、自分でスクショを撮って確認するところまでを、手元の27Bがやったということでもある。ここは素直にすごい。
次は同じ課題を Qwen3.6-27B に投げて、どこで崩れるかを見てみたい。「粘り強さ」に振ったという公式の主張が、世代差として本当に出るのかが確かめられるはず。
ページの下部には、エージェント自身が書いた作業プロセスの記録へのリンクまで自動で付いていた。
