Hermes × Qwen3.8-27B だけで東京ゲームショウ2026の3Dマップを作った｜実装は全部ローカル、クラウドは診断3回

先に結論だけ

東京ゲームショウ2026の会場を3Dで歩けるサイトを作った。出展社の一覧ページと、幕張メッセの1Fを実際に歩き回れるページの2本。

• 一覧ページ（出展社・団体 1,328／プレスリリース 248件）
• 3Dマップ（859スポット・PCはWASD、スマホはジョイスティック）

作ったのは手元のPCで動くAIで、実装は1行もクラウドに書かせていない。使ったのは RTX3090 を1枚積んだPCと、そこで動く Qwen3.8-27B。エージェントは Hermes Agent。

• 調査から実装まで、工程が全部つながった。プレスリリースの収集、出展社情報の取得、会場データからの座標取得と解析、データの保存、一覧ページと3Dマップのコーディング。ここまでローカルで完結した
• クラウドのAI（Claude Code）が入ったのは3回だけ。どれも実装ではなく、詰まったときの診断と計画のレビュー
• この分け方が今回の発見。手を動かすのは全部ローカル、判断に迷ったところだけ外に出す。クラウド側のトークンはほとんど減らないのに、この規模のものが形になった
• 指示はスマホのTelegramから出した。3Dマップをスマホで開いて、おかしいところを写真に撮って送る。人間が指示を出していた時間は、合計しても2時間ないと思う
• いちばん効いたのは、残量を気にしなくてよかったこと。1日の上限も週の上限もない。やり直しの回数を数えずに済むのが、速度より効いた

これは何の実験なのか

先に立場をはっきりさせておく。

これはローカルAIのベンチマークとして、東京ゲームショウ2026を3Dで擬似体験できるサービスを作らせてみたもの。出展内容やブース位置などの正確性については公式サイトを確認してほしい。あくまで Hermes Agent と Qwen3.8-27B を組み合わせてサービスが作れるかどうかの実験。

公式の案内ではないし、公式の代わりになるものでもない。測っているのはAIの側で、題材としてTGSを借りている。実在するイベントの公開データを扱って、締切のある本番のサイトとして出す。デモではなく本番にしたのは、そうしないと「どこまでできるか」が測れないから。

使っているもの

細かい話に入る前に、この3つが何なのかを短く。

• Hermes Agent ── 手元のPCで動かすAIエージェント。ファイルを読み、コードを書き、コマンドを実行する。ゴールを渡すと、失敗してやり直しながら最後まで進める
• Qwen3.8-27B ── Alibaba製の無料のAIモデル。手元のGPUで動く。公式のベンチマークでは、PC操作やエージェント用途のスコアがフロンティアモデルに並ぶ（別記事で構成と実測を書いた）
• Three.js ── ブラウザで3Dを描く定番のライブラリ。HTML1枚で動いて、スマホでも軽い

前提の数字。GPUは RTX3090（VRAM 24GB）を1枚。量子化は4bit（UD-IQ4_XS）、文脈長は262,144トークン。クラウドAPIの費用はゼロで、かかったのは電気代と、詰まった3回ぶんのClaudeのトークンだけ。

かかった時間（正確に測ってはいない）。一覧ページは調査とHTML作成で2時間ほど。3Dマップも数時間。ただしブースの正面がどちらを向いているかにこだわり始めてから、1日くらい溶けた。そのあいだ人間が指示を出していた時間は、合計しても2時間ないと思う。

何ができるサイトなのか

一覧ページは、出展社・団体 1,328件。公式サイトのブース情報 1,286件に、PR TIMES から集めたプレスリリース 248件を紐付けてある。プレスリリースがある企業は93社。

コーナー別（一般展示279／インディーゲーム284／ビジネスソリューション133／ビジネスミーティングエリア251／ゲームアカデミー68／ゲーミングハードウェア53 ほか）で絞り込めて、キーワード・ブース番号・出典・並び順を切り替えられる。

3Dマップは幕張メッセ1F、859スポット。PCはWASDとマウスドラッグ、スマホは左下のジョイスティックと右側ドラッグで歩く。「飛行」を有効にすると壁をすり抜けて上下に動けて、「俯瞰」で真上から会場全体が見える。

プレスリリースがある企業は、実際のブースの位置にその内容が立っている。会場を歩いていくと、そのブースの前でプレスリリースの画像と説明が読める。一覧で探すのではなく、歩いて見つける形になっている。

配信サイズは 3dmap.html が63KB、データが2.4MB、Three.js が594KB。バナー画像は個別配信。

指示はスマホのTelegramから出した

作業机に張り付いていたわけではない。Hermes Agent が動いているPCと、スマホのTelegramを繋いである。やりとりは全部チャットで進めた。

直し方の相談はだいたいこの形になる。スマホで3Dマップを開いて、おかしいところを写真に撮って送る。

• ブースからプレスリリースの画像がはみ出している
• プレスリリースの画像と企業名のカードが重なって読めない → 「天井の高さはあるから、カードを上に持ち上げたらどうか」
• 企業名のカードとプレスリリースの画像を、会場のメイン通りに向けて置いてほしい

3つ目が面白かった。「メイン通りに向けてほしい」と言っても、そもそもAIがメイン通りをどこだと思っているかが分からない。そこで、認識しているメイン通りを線として描かせた。描かれた線を見て「真っ直ぐ2本のはずが曲がっている、しかも2本が合流している」と分かったので、そこを直した。

言葉で説明しにくいものは、絵にして出させると早い。3Dの不具合は特にそうで、「壁が浮いている」「カードが被っている」は文章にすると長くなるのに、写真1枚だと一発で伝わる。逆にAI側の認識も、線として描かせれば目で確認できる。

今回の発見は「役割分担」のほう

作れたこと自体より、どう分けたかのほうが再現性があると思っている。

工程を並べるとこうなる。

①②の「調べてファイルに残す」部分は、調査エージェントの作り方を書いた記事と同じ仕組み。

「調べる」と「書く」の間にある、③④の「解析して数字で確かめる」が入っているのが今回の肝。Web調査ができるAIも、コードを書けるAIも珍しくない。バイナリを直接読んで構造を推定し、それが正しいか数値で検証してから実装に入る、という流れが1本でつながるかどうかが分かれ目だった。

クラウド側の使い方も書いておく。実装を全部投げる使い方と比べると、消費するトークンは桁が違う。診断を頼むときに渡すのは、詰まっている箇所の状況と数字だけ。返ってくるのも判断だけで、コードは戻ってこない。

速さより、残量を気にしないで済むことのほうが効いた

これは数字にならない話だけど、今回いちばん体感が変わったところなので書いておく。

RTX3090 1枚で動く27Bのモデルなので、クラウドの大きいモデルと比べたら1回の応答は遅いかもしれない。それでも作業が進んだのは、回数を数えなくてよかったからだと思っている。

クラウドのAIには1日の上限や週の上限がある。重い作業ほど「あと何回投げられるか」を頭の片隅で数えながら進めることになるし、やり直しが増えそうな作業は最初から避ける判断をしてしまう。

ローカルは電気代しかかからないので、何度やり直しても減るものがない。ブースの正面判定を6段階もやり直せたのは、これがあったからだと思う。途中で「この試行に上限を1回使う価値があるか」を考えていたら、たぶん3段階目あたりで妥協していた。

速度の差より、止まらないことのほうが効く場面がある。これが今回いちばん精神的に楽だった部分。

ここから先は、実際に作った記録

ここまでが何を作ったかと、どう分けたか。以降は実作業の記録で、詰まった話とやり直した話が並ぶ。同じことをやる予定がないなら、ここで読むのをやめても足りる。

クラウドが入った3回

① 「957個の構造体＝コーナー区画」という誤認

会場データを取ってきたローカル側は、計画にこう書いていた。

1F/2F/3Fの床ポリゴン（歩行可能域）＋957の構造体（コーナー区画・化粧室・フードコート等、名前付きポリゴン）

マップデータを直接読むと違った。

• 957個のうち917個が面積600m²未満。中央値は10m²
• 1Fのスポット663件を重ねると、595件がちょうど1個の中に収まる
• 各ポリゴンが height（1.0mが730個、約2.0mが146個）と色38種を持っていた

実体はブース1つ1つの足元のポリゴンだった。しかも押し出す高さと色まで最初から配られていた。

誤認の理由は「名前を見て、面積を見なかった」こと。195個のポリゴンが全部「一般展示」というコーナー名で名付けられていたので、1個の大きな区画だと判断していた。人間もやる読み違いだと思う。

これが直ったことで、ブースは「低い壁で囲む」のではなくポリゴンごとに箱として押し出せるようになった。PDFの図面から面積を起こす作業が丸ごと不要になっている。

② 検証の通過条件がなかった

計画の最後が「スマホ実機で性能検証」だけで、何をもって合格とするかが書かれていなかった。数字で4つ置いた。

• 生成した3D世界を真上から描いて、公式の図面に重ねてずれがないこと
• スポットとポリゴンの結合件数を毎回出力し、どこにも属さないスポットが13件を超えたら止める
• 4G相当の回線で起動3秒以内、中級スマホで30fps
• 1階と2階の移動が実際に動くこと

③ 「画像があるブースだけカードが消える」

公開直前、画像が表示されるはずのブースだけ、社名カードごと表示が消える現象が出た。

ローカル側の仮説は「canvas の汚染では」。方向は合っていた。実測で確定させた。

画像の読み込みは1件も失敗していない。壊れるのは、読み込んだ画像をGPUのテクスチャに上げる瞬間だった。ブラウザはローカルファイルとして開いた画像を全部「別のサイトのもの」として扱うので、同じフォルダに置いた画像でも汚染される。

ここで一度、間違った方向に修正しかけている。「canvas に描かずに画像をそのままテクスチャにすれば回避できる」と考えて書き換えたが、隔離テストで、汚染していない真っ赤なcanvasすら描画されないことが分かって仮説が崩れた。ローカルファイルとして開いている限り、canvas を経由するかどうかに関係なくテクスチャ化そのものが止まる。

結論は書き換えを全部戻して、サーバー経由で配信する。これが「公開版はサーバー配信で動かす」理由になっている。

いちばん長くかかったのは、地味な判定だった

プレスリリースを表示する壁を、ブースの「正面」に立てる。この正面の判定が何度も壊れた。

1. 最小Y側を正面にする（固定角度）→ 斜めの通路に面したブースで壁が浮く
2. 歩ける面積が広い側を正面にする→ ブースの内部も歩けるので、隣のブースを通路と誤認する
3. 歩ける深さで選ぶ→ ブースの内部を8mまで突き抜ける
4. ブースの占有グリッドを作り、外に出したレイが別のブースに入ったら止める→ ここでやっと正しい通路側を向いた
5. それでも建物の外壁側を正面に選ぶブースがあった → 床ポリゴンの内側かどうかで「会場の外＝背面」を除外
6. どの方向も60m開通していて区別できないブースが残った → 会場を南北に貫くメイン通り2本への向きに、ボーナスとペナルティを足した

このメイン通りの引き方でもう一段ある。最初は点をつないだ折れ線で通りを表現していたが、「真っ直ぐ2本引けばいいはずが曲がっている、しかも2本が合流している」という指摘が入った。折れ線をやめて、信頼できる基準点に最小二乗で1本の直線をフィッティングし、端まで伸ばす方式に変えた。2本が交差しないこと（交点は会場の外）も数値で確認している。

3Dの見た目を作る作業の大半は、見た目ではなくこういう判定だった。

他に踏んだもの

• 移動方向が左右逆だった。右キーで後ろに進む。移動ループの右方向ベクトルの符号ミス
• カードをタップすると別のブースが選ばれる。レイの方向が上書きされていたのと、浮いているカードが判定の対象外だった。画面上の矩形で判定する方式に切り替えた
• メイン通りの帯が見えない。回転→移動→拡大の順にしていたので、拡大が移動量まで倍にして頂点が会場の外に飛んでいた。拡大→回転→移動に直した。同じバグがブースの照明にも入っていた
• 大型ブースで社名カードが画像を隠す。横にずらす→上に載せる→入口の隅、の3段階で逃がすようにした
• スマホでボタンが途中で折り返されて切れる。390×844を強制して確認しながら直した

検証のやり方は毎回同じにした

作っては壊すので、確認の手順を固定してある。

• 構文：スクリプト部分を抜き出して構文チェックにかける
• 数値：壁の数、正面判定の結果、箱の中心座標、メッシュの範囲をJavaScriptから読む
• 見た目：スクリーンショットを撮ってAIに投げ、「文字が裏返っていないか」「カードが壁を隠していないか」を判定させる

見た目の確認まで自動化したのが効いた。3Dは数値が合っていても見た目が壊れる。逆に、見た目が合っていても座標が飛んでいることがある。両方を毎回見る形にしてから、やり直しの回数が減った。

記録が残っていないこと

正直に書いておく。

• 総作業時間は測っていない。9/4にプレスリリース収集とサイト構築、9/11〜12に3Dマップ、という粒度までしか分からない
• 正面判定のやり直し回数も数えていない。段階が6つあったことはログから確認できる
• スマホ実機のfpsは、後から手元で見た値しかない。4G回線の俯瞰表示で60fps、歩いているときで55fps。計測として取ったものではなく、画面に出ている数字を見ただけ

まとめ

• 調査・解析・実装まで、手を動かす工程は全部ローカルで通った。RTX3090が1枚あればここまで来る
• クラウドは詰まったときの診断だけで足りた。3回。実装は1行も書かせていない
• 効いているのはモデルの賢さだけではない。262Kの文脈と、失敗してやり直しながら長時間ひとりで進み続ける粘りのほうが効いている
• いちばん時間がかかったのは3Dの見た目ではなく、正面をどう決めるかという判定だった。ここは何を作っても同じだと思う

会期は2026年9月17日から21日。会期中は実物が動いているので、触ってみるのが早い。

• 出展社一覧
• 3Dマップ（幕張メッセ1Fを歩く）

繰り返しになるが、これはローカルAIのベンチマークとして作ったもので、公式の案内ではない。出展内容やブース位置の正確性は公式サイトを確認してほしい。

Qwen3.8-27B × Hermes Agent シリーズ

RTX3090を1枚だけ持っている状態で、手元のAIをどこまで実用にできるかを順に試した記録。

1. ① 機材を選ぶ ── ローカルLLMはMacとGPUどっちで動かす？
2. ② エンジンを選ぶ ── 推論エンジンはどれを選ぶ？ llama.cpp・EXL3・vLLMを実測
3. ③ 構成を詰める ── RTX3090単体でHermes Agentを回す最良の構成
4. ④ 性格を知る ── Qwen3.8-27Bにサブエージェントを任せたらどうなるか
5. ⑤ 調べさせる ── Qwen3.8-27B × Hermes Agent で調査エージェントを作った
6. ⑥ 丸ごと任せる ── 「港区のうまい店を調べて特集ページ作って」と頼んだら
7. ⑦ サービスを作らせる ── 東京ゲームショウ2026を3Dで歩けるようにした　← いまここ