Claude CodeをGX10のQwenにつないで、Opus 4.7と同じ電卓アプリを作らせてみた

Claude CodeのLLM接続先を、GX10上で動いているローカルQwenに差し替えられるようになった。

これだけでも面白いのだが、実際に使えるかどうかは別の話だ。モデル名が gx10-qwen として返ってくることと、Claude Codeのツールループでアプリを作れることは同じではない。

そこで、同じような題材をOpus 4.7とGX10 Qwenの両方に投げてみた。題材はかなり単純にした。

SwiftとSwiftUIで、簡単なiOS電卓アプリを作る。

結論から書くと、Opus 4.7は数分でXcodeGenプロジェクト作成、ビルド、Simulator起動、見た目として成立するUIまで到達した。GX10 QwenもビルドとSimulator起動までは到達した。ただし、そこまでのツールループは長く、最終UIはボタン幅と配置が崩れていた。

今回の話は、単純なモデルベンチマークではない。1回のプロンプト、1回の実験で見えた実務上の差だ。

何を比べたか

比較したのは、Claude Codeの中で動くLLMだけだ。

• Opus 4.7
• GX10上のローカルQwen、Claude Code上では gx10-qwen

作業内容は、どちらも「SwiftUIで簡単なiOS電卓アプリを作る」。XcodeGenが使える環境で、最終的にはiPhone 16 Simulatorで起動するところまで見た。

大事なのは、どちらも最終的にビルドは通ったことだ。Qwen側も、Swiftの構文で即座に破綻したわけではない。

ただ、ビルド成功とアプリとして成立していることは違う。

Opus 4.7は退屈なほど素直に進んだ

Opus 4.7の流れはかなり素直だった。

最初にツールを確認し、XcodeGenベースのiOSプロジェクトを作り、project.yml、CalculatorApp.swift、ContentView.swift を書く。その後、Xcodeプロジェクトを生成してビルドまで進めた。

作られたUIは、iOS標準の計算機を強く意識したものだった。黒背景、大きな表示、丸いボタン、右列のオレンジ色の演算子。凝った設計ではないが、見た目としては電卓に見える。

ここで注意点もある。Opus 4.7はSimulator起動までは進めたが、最後の自動タップ検証は完了しなかった。手元の環境では simctl io tap が使えず、画面上で実際に 12 + 8 = まで自動検証するところは省略された。

つまり、Opus側も完全なE2Eテストまで通したわけではない。それでも、最終スクリーンショットを見る限り、少なくとも「触れそうな電卓」として成立している。

GX10 Qwenも作れるが、ループは長い

GX10 Qwen側は、最初から少し不安定だった。

モデル確認では gx10-qwen として動いていることは分かった。ただ、アプリ生成に入ると、質問の意図を取りこぼしたり、日本語、英語、韓国語のような断片が混ざったりした。

それでも、最終的にソースファイルは作った。

面白いのは、Qwenのほうが見た目には設計らしい分割をしていたことだ。CalculatorApp.swift、CalculatorLogic.swift、CalculatorView.swift に分け、計算ロジックとビューを別ファイルにしていた。

ただし、最初の時点では実行可能なXcodeプロジェクトにはなっていなかった。Simulatorで起動してほしいと頼むと、Qwenは「直接Simulatorで実行することはできない」と答え、Xcodeプロジェクトを作る必要があると説明した。

この時点では、コード生成としては進んでいるが、アプリ生成の作業としてはまだ途中だった。

そこで、XcodeGenを使ってよいのでSimulatorで起動するところまで進めてほしい、と明示した。ここからQwenはXcodeGenの設定、Info.plist、deployment targetまわりを何度か修正しながら、最終的にはビルド成功まで到達した。

ここは評価したい。ローカルQwenでも、Claude Codeのツールループ自体は回る。ファイルを書き、エラーを見て、設定を直し、ビルドを通すところまでは行ける。

ただし、完成ではなかった。

最終UIは崩れていた

GX10 Qwen版も、最終的にはiPhone 16 Simulatorにインストールされ、起動した。

しかし、画面はこうなった。

ボタンが縦長の細いpillになり、通常の電卓グリッドとして成立していない。下段の0ボタンだけが横に伸び、右下のボタンも画面外に切れ気味になっている。

これは「ビルドが失敗した」話ではない。むしろ逆だ。ビルドは成功し、アプリも起動している。そのうえで、ユーザーが見る画面が壊れていた。

この差はかなり重要だと思う。

コーディングエージェントを評価するとき、BUILD SUCCEEDED は大事なチェックポイントだ。しかし、UIアプリではそれだけでは足りない。最後のスクリーンショットが、実質的なテスト結果になることがある。

Qwenは失敗なのか

今回のQwenを単に失敗と切るのは、少し違うと思っている。

Qwenは、ローカルLLMとしてClaude Codeの中に入り、ファイルを書き、XcodeGenを使い、ビルドエラーを直し、Simulator起動まで到達した。これは十分に面白い。

ただし、完成でもない。

今回見えた弱点は、Swift構文そのものよりも、ツールループの安定性、指示の保持、UIレイアウトの判断、最後の画面確認だった。

ローカルLLMの価値は「常に最強」ではなく、「自分の手元で何度でも回せる」ことにある。GX10 Qwenは、安く、プライベートに、繰り返し試せる。だからこそ、次のようなガードレールを足す価値がある。

• 最初からXcodeGenプロジェクトを作るように指示する
• ビルドだけでなく、Simulatorスクリーンショットの確認を必須にする
• SwiftUIでは「4列グリッドとして全ボタンを等幅にする」など、レイアウト制約を明示する
• 生成後に別モデル、または人間がレビューする

次に見るべきもの

今回の1本目では、実験の流れと最終スクリーンショットの差を見た。

では、Qwenの画面はなぜ崩れたのか。これはソースコードを読むとかなりはっきり分かる。

Opusは素朴な単一ファイル構成だったが、ボタンを横方向に広げる制約を外していなかった。一方でQwenは、ロジックとビューを分け、@Observable まで使っていたのに、通常ボタンの幅制約が壊れていた。

次の記事では、同じ電卓アプリのソースを読み、Opus 4.7とGX10 Qwenの差がどこに出ていたのかをコードレベルで見る。