EVO-X2を使ってローカルLLMまわりを中心に色々と遊んでいる昨今。
ここ数週間のうちにQwen3 Coderやgpt-ossがリリースされてローカルLLMを取り巻く状況は大きく変化している。
コーディング用途の視点でいうと、これまでの大きいモデルは推論が重くてエージェントだったりollama側だったり色々な箇所のタイムアウトにひっかかって（そうでなくても遅すぎて）とても実用にはならず、かといって小さいモデルはコーディング性能が低いどころかそもそもエージェントのフォーマットに沿ったやり取りができなくて動かないというようなジレンマがあった。
それが直近でリリースされたモデルなんかはMoEが絶大な効果を発揮していて、大きなモデル並みの柔軟性を備えつつもマシンのメモリ容量に収まって十分な動作速度が出たりする。
以前にVibe Codingの記事を書いたタイミングでは「使えないこともない」ぐらいの感触だったんだけど、僕個人の実感ベースでもQwen3-Coderなんかは今ではすっかり「十分実用に足る」「あれば助かる」ラインに入ってきたなーという印象を持っている。
そんなわけで前置きが長くなったけど、今回の記事では先日リリースしたアケコンのボタン配置図作成ツールの作成の流れと感想を書いてみようと思う。
アプリ作成時の流れ
1. Gemini Cliで雛形作成
初手からローカルLLMじゃなくて失礼・・・当時はgemini cliがリリースされて話題になっていたタイミングで試してみたかったのもあり、
- 仕事でも使っていて知見あるNuxt.jsで
- 概要ぐらいは知ってるcanvasを用いて
- アケコンのボタン配置図を表示するウェブアプリを作りたい
ぐらいの粒度でGeminiに指定してみた。
今回はローカルLLMの話をメインに置きたいので深くは触れないけど、簡単な要件入力でも結構それっぽいものができてびっくりしましたな。
この時点で機能のコアの部分はかなりできてたんだけど、
- 初手のボタンレイアウトは固定（コード内にベタ書き）
- UIフレームワークはBootstrap製で個人的にはあまり好みではない
等々と手を入れる余地はあるなーという感じ。
2. Qwen3-Coder使い始め、UIフレームワークをBulmaに変更させてみる
しばらくその粗いプロトタイプの状態で放置してたんだけど、先日リリースされたQwen3-Coderを試してみたら思った以上に使えそうだったんで、真面目に作り直してみようと思い立つ。
以前の段階ではローカルLLM×Clineでの作業感を「ダイヤルアップ時代のブラウジング」に例えていたけど、Qwen3-Coder:30bは「別のウィンドウを眺めてたら終わってる」「普通に座って待てる」水準の速度感で動いてくれるし、処理エラーになることもほとんど無く、だいぶ「ちゃんと使える」感じになった印象。
そんなわけで初手、試運転も兼ねてUIフレームワークを使い慣れたBulma（系のBuefy）に変更させてみる。
モジュールのインストール・アンインストールからnuxt.configの記述、各所のタグの書き換えと手作業でやろうと思うと非常に面倒くさいんだけど、これを自動でちゃんと置き換えてくれた。
一回の指示だとタグなんかは良い感じになったんだけど、スタイルシートの適用がうまく行ってない感じがあり、再度別に修正を指示してみたら直してくれた。
3. 各種デザイン面の変更
ページ全体のレイアウトだとかボタン入力フォームまわりのデザインだとか、あるいはモバイル端末で表示したときに良い感じになるような調整を個別に指示。
意図の解釈の幅にしろ切り戻しにしろ、この辺はできるだけ小さく具体的に指示した方が良さそうだ。
4. ボタン配置のjson化、複数の機種のレイアウト適用
「ベタ書きになっているボタン配置の変数をjsonファイルとして切り離して」あたりは上手くやってくれたんだけど、画面開いた時にデフォルトの配置を読み込んで画面に表示する部分はどうにも上手く実装してくれなかった。
実際はコンポーネントの描画順序を考えた処理にしなければいけないんだけど、そのあたりを自動では処理できず、口頭での指示にも限界があり、ここは手書きでの実装を要した。
結局のところ自然言語は「求める操作」を抽象的に表現した情報なわけで、特に入り組んだ箇所でそれで伝えきれない・抜け落ちる部分が大きい実装に関しては人間が対処した方が苦労がない。
5. 機種ごとのボタンレイアウトの充実
コントローラの機種ごとのデフォルトのボタンレイアウトはjsonファイルとして切り出していて、これを増やしていくことで選択肢を増強できる。
この追加作業はVibe Codingの恩恵がかなりあり、ベースを指定して差分を口頭で指示するみたいな形で面倒な作業をかなり簡略できた。
決まった変更処理を物量こなすようなものでは、かなり便利に使えそうな気がする。
6. その他リファクタリング
共通処理をvueから別ファイルに切り出すとか、そのあたりは自動でやらせるとちょっと怪しい。
本来/components以下に置いて各所から参照させたいはずが/public以下に置かれてしまったり、まとめられる処理をそのままにされたり、「確かに動きはするんだけど・・・」というものを作ってしまうので、このあたりはまだ人の判断力が必要そうだ。
7. その後の多言語対応とか共有URL機能追加とか
リリース後、思い立って言語切り替えやURLパラメータへの反映なんかを実装させてみた。
特に既存のテンプレート側のベタ書き記述を変数に置き換え別ファイルに切り出した言語ファイルに翻訳語彙を書き足し・・・みたいな地道な作業なんかは自動書き進めてくれてありがたみを感じる。
パス設定が変だったりと個別に手直しは要したものの、ほとんどの部分は自動で実装をこなしてくれた。
二・三日でこのあたりのダルい作業をやろうと思えた・実際に実装できてしまったあたりにVibe Codingの有用性を感じてほしい。
雑感
そんなわけで一通り作りきっての感触だが、先にも述べたように速度も作業しながら待てる程度にはなっているし、ほとんどエージェントの動作エラーに遭遇することもなく、ローカルLLMでも十分に実用に足る水準で動いてくれる印象は持てた。
（ちなみに途中でgpt-oss:120bも使ってみたが、速度的に遅くなるのとそこまでクオリティ差は感じられなかったので、コーディング作業に関してはQwen3-Coder:30bで良いかなって気がしてる）
指示から結果が大体想像できる程度ものだったり作業そのものは単純だけど人手でやると面倒な物量のものなんかをやらせることで作業効率の向上させることはできそうだ。
一方で現状ではAIまかせではどうしても厳しい領域はありそうで、ところどころで人間がつっこみをいれたり軌道修正しないと完成まで持っていくのは難しい感じはあって、作業者側が全く分からないコードを自動で開発させるような運用はできない気もした。
変な実装になったとき修正させようにも、それがまた見当違いな方向に実装を作ってしまい・・・というのも往々にあり、むしろ人間が作業した方がよっぽど効率は良いような部分というも存在しそうだ。
このへんはクラウドの有料のモデルを使ったところで物量による精度は上がろうともLLMの性質として無くしきれない気がするわけで、そういうAIの得意不得意の特性を見極めて上手く分業する術を学ぶというのが、これからのエンジニアの職能として求められてくるのかなーなんて思うところ。
なにはともあれ、EVO-X2は小さくはない出費ではあったけど、こういう変化の大きい時期に手元に動かせる環境を持っていることによって技術の進歩を体感できるのはらガジェットオタクとして僥倖ですな。
