Qwen3.5のコーディング能力を静的デンタルクリニックサイトで評価する

背景

コーディングモデルの評価で見たいのは、単発のUI断片を作れるかではなく、ページ間の整合性を保った複数ファイル構成を最後まで崩さずに扱えるかだった。index.htmlだけを作る課題だと、ヒーローやカードUIを置いて終わることが多い。

今回はQwen3.5系のコーディング能力を確かめるため、歯科クリニック向けの静的マーケティングサイトという具体的なWeb制作課題を与えた。単なる1ページLPではなく、トップナビゲーションごとに独立したHTMLを持つ6ページ構成で、技術スタックもHTML、Tailwind CSS、Alpine.jsに限定し、ビルドステップやSPA化は禁止という条件にした。

要求として明確だったのは、この3点だけで構成すること、ビルドステップを持ち込まないこと、多言語対応はUIを中心に成立させること、保守性とSEOを犠牲にしないことだった。短時間で組み上げる前提があると、構成をどこまで単純化できるかが重要になる。

目的

1. 静的マルチページサイトの全体設計能力を評価する
2. アクセシビリティ要件（ARIA属性、フォーカス管理、コントラスト）への対応力を確認する
3. 軽量フロントエンドインタラクション（Alpine.js）の実装精度を見る
4. エラー復旧と環境適応のエージェント的挙動を記録する

評価テスト設計

技術制約

• Plain HTML files only（ビルドステップなし）
• Tailwind CSS via CDN
• Alpine.js via CDN（軽量インタラクションのみ）
• 外部UIコンポーネントライブラリ禁止
• 参照サイトからの画像・テキスト流用禁止

要求ページ構成

共通レイアウト要件

• ヘッダー: クリニック名、主要ナビ、言語切替UI
• モバイルナビ: Alpine.jsハンバーガーメニュー、フォーカス管理、ESC-to-close
• Book Appointment: デスクトップはヘッダー、モバイルは画面下部固定
• フッター: クリニック情報、プライバシー/利用規約リンク、著作権

このプロンプト設計の価値は、ページ数が固定で、Alpine.jsインタラクションの種類が多く、アクセシビリティ要件が入っているところにある。「どれだけ抜け漏れなく、破綻なく、読みやすく仕上げるか」を横並びで見やすい。

実行結果

エラー復旧の挙動

モデルは最初からスムーズだったわけではない。最初のCreate directory siteがPath to create was outside the projectで失敗した。

ただし復旧は素直だった:

1. list_allowed_directoriesを呼び出し
2. 許可ディレクトリとして/を確認
3. /Users/ksh3/Development/sandbox7/siteとsite/assetsを絶対パスで作り直し

失敗を無視せず、許可範囲を確認してから再試行している。ツール制約下のエージェント処理としては悪くない。

生成されたファイル

モデルは各HTMLファイルを1枚ずつ書き、README.mdを追加し、ディレクトリ一覧で確認、最後にassets/placeholder.svgを追加した。処理順序は:

1. ディレクトリ構造の作成
2. 各ページの個別生成（index -> services -> doctors -> info -> visit -> access）
3. README作成
4. 一覧でファイル存在確認
5. 補助アセット追加

自己報告された内容

ページごとの実装詳細

各ページは仕様書の要件を満たす前提で整理されている。6ページ構成にしたことで、情報を役割ごとに切り分けやすくなっている。

Homeでは、医院サイトとして最初に見せたい要素が一通り揃っている。ヒーロー、サービスカード、強み、医師プレビュー、ニュース、診療時間といった構成は、訪問直後に必要な情報へ到達しやすい。ここにモバイルナビゲーションと言語切替UIを置くのは自然だった。

Servicesでは、14種類の治療カードと4つのカテゴリを持たせ、利用者が関心のある治療へ辿りやすいようにしている。FAQアコーディオンも含まれており、情報量が増えても一覧性を保ちやすい。クライアントサイドのカテゴリフィルタリングは、静的HTMLベースでも体験を下げないための実用的な選択だった。

Doctorsでは、6名の医師プロフィールに対して、専門分野、対応言語、資格情報を整理している。プロフィールの詳細を展開・収納できるようにしたことで、一覧性と情報量のバランスを取りやすい。医療系サイトでは人の情報が信頼感に直結しやすいため、この構成は重要だった。

Infoでは、8項目の料金表、保険対応リスト、支払い方法をまとめている。費用に対する不安を和らげる意味でも、料金まわりの情報を分離して明示するのは妥当だった。動的な見積もりモーダルは、静的中心の構成でも必要十分な補助機能になっている。

Visitは、初診導線を6ステップで整理し、予約方法も案内するページとして設計されている。さらにバリデーション付きの予約リクエストフォームを持たせることで、問い合わせ導線としての機能を担保している。医院サイトでは予約への到達性が重要なので、このページは実務上の要になる。

Accessでは、連絡先、地図プレビュー、近隣駅、駐車場情報をまとめ、来院手段ごとの差異も扱っている。車、電車、徒歩それぞれでルート案内を切り替えられるようにしたのは、来院時の具体的な不安を減らす設計として分かりやすい。

品質およびアクセシビリティの検証

レスポンシブデザインでは、モバイル端末で画面下部に固定予約ボタンを置き、デスクトップではヘッダー内に統合するレイアウトを採用した。予約導線を優先しつつ、画面サイズごとに自然な配置へ変えている。

ナビゲーションについては、Alpine.jsを使ったハンバーガーメニューがフォーカス管理とESCキーでの閉鎖に対応している。単に開閉できるだけでなく、アクセシビリティを意識した操作性まで見ている点が重要だった。

セマンティックHTMLも明示されている。header、nav、main、footerを適切に使い、見出し構造もh1からh3まで正しく整理している。コンテンツが多くなりがちな医院サイトでは、この基本が崩れると保守性もSEOも落ちやすい。

パフォーマンス面では、外部UIライブラリに依存しない軽量構成を選び、高速な読み込みとレイアウトシフト防止を狙っている。ビルドレス構成は単純さが利点だが、その利点を実際の体験につなげるには依存関係を絞ることが前提になる。

実行メトリクス

今回の全プロセスの所要時間は約18分2秒だった。短時間で設計、実装、検証まで進めた記録としては十分に意味がある。

• 総生成コード量は6ページ分のHTML、CSSクラス、JSロジック
• すべてのHTMLファイルでDiagnostics上のエラーおよび警告なし
• 資産管理にはローカルSVGとインラインアイコンを使い、外部依存を最小化

この数字から分かるのは、大規模な仕組みを持ち込まなくても、要件の整理ができていれば短時間で実用レベルの構成に到達できるということだ。

結果の限界

このノートから確認できる結果は、「モデルが要求仕様を解釈し、必要なファイル群を生成したと報告している」というところまでに留まる。生成されたHTMLの中身までは保存されていないので、以下の本質的な部分は現物確認が必要になる:

• ARIA属性が本当に入っているか
• フォーカス管理が実装されているか
• Tailwindのクラス構成がtidyか
• Alpine.jsの状態管理が正しいか

感想

このプロンプトは、単なるQwen3.5の評価メモとしてだけでなく、フロントエンド寄りコーディングモデルの共通ベンチマークに転用できると思う。ページ数が固定で、必要なインタラクションの種類が多く、アクセシビリティ要件が入っているので、モデル間の比較が公平にやりやすい。

今後この種の評価ノートをより使いやすくするなら、生成された主要ファイルの抜粋やレビュー結果も一緒に残したい。自己申告だけでは品質判定ができないため、実ファイルの中身やスクリーンショットがあれば、より具体的な比較が可能になる。

今後

• 同じプロンプトを別モデルに投げて横並び比較する
• 生成物の実ファイルを保存し、アクセシビリティ・インタラクション・クラス構成を定量評価する
• 失敗モードのカタログ化: マルチページ構成の崩壊、アクセシビリティの欠落、Alpine.js実装不足、ページシェル不整合、READMEの薄さ
• 多言語対応をコンテンツ翻訳まで拡張する場合、翻訳境界と更新フローを別途定義する