Qwen3.5-397Bで静的サイトとDjango CMSを生成
Qwen3.5-397Bへ仕様書を渡し、6ページの静的サイトとDjango CMSを生成。受託開発・業務システム開発へのLLM利用と手修正を記録します。
生成した2つのシステム
Qwen3.5-397Bへ仕様書を渡し、2つの構成を生成しました。
- 歯科医院の静的サイト：HTML + Tailwind CSS + Alpine.jsの6ページを約18分で生成しました。
- Django CMS基盤：WordPressに近い8アプリ、20超モデル、Django設定をシングルターンで生成しました。
人間がSPECを書き、生成後にレビューと手修正を行いました。修正は比較的少なく、ファイル間の依存も保たれていました。397Bの規模が寄与したと考えています。
前提
実行環境
- GPU: NVIDIA RTX PRO 6000 Blackwell Max-Q (96GB VRAM)
- CPU: AMD EPYC 9175F (16C/32T, 512MB L3)
- Runtime: ik_llama-cuda ベースの Podman コンテナ
- 量子化: IQ4_KSS
- 主要引数:
--cpu-moe,--no-mmap,-fa on,-c 262144
運用上の制約
EPYC + 1GPUではDecodeが数 tok/sに下がります。対話より、シングルターンの構造生成や夜間バッチで使う方針です。
検証1: 歯科医院向け静的サイト（ワンショット生成）
要件
- 構成: index, services, doctors, info, visit, access の6ページ
- 技術制約: ビルドステップなし、Tailwind CSS (CDN)、Alpine.js (CDN)、外部UIライブラリ禁止
- 必須機能: モバイルハンバーガーメニュー（ESC/フォーカス管理）、カテゴリフィルタ、FAQアコーディオン、見積もりモーダル、フォームバリデーション
- 品質要件: セマンティックHTML5、ARIA属性、キーボードナビゲーション、レスポンシブ
実行結果
約18分で次を生成しました。
/siteと/assetsのディレクトリ- 共通ヘッダー・フッターとページごとのHTML
- セマンティックHTML5、フォーカス管理、ESC対応
- 起動方法と制限事項を記載したREADME.md
生成されたページの内訳
| ページ | 主要コンテンツ |
|---|---|
| index.html | ヒーロー、8サービスカード、6つの選ばれる理由、4医師プレビュー、ニュース、診療時間 |
| services.html | 16治療カード + Alpine.js カテゴリフィルタ（4カテゴリ）+ 6項目FAQアコーディオン |
| doctors.html | 6医師プロフィール + 展開式詳細（専門、言語、資格） |
| info.html | 料金表（8治療）+ モーダル見積もり、保険・支払い方法 |
| visit.html | 6ステップタイムライン、予約方法、バリデーション付きフォーム |
| access.html | 連絡先・診療時間、地図プレースホルダー、経路タブ（車/電車/徒歩） |
評価
マークアップとTailwindの使い方は一貫し、レスポンシブとアクセシビリティの要件も満たしていました。6ページを一度に生成でき、ビルドなしでブラウザ表示とデプロイが可能なプロトタイプになりました。
検証2: Django CMS 基盤（シングルターン生成）
要件
WordPressのコア概念をDjangoで再構築する技術仕様書（SPEC）を渡しました。
- Posts / Pages（公開状態、予約投稿、パスワード保護）
- Categories / Tags（階層型＋フラット型の統合分類）
- Comments、Media Library、Menus / Navigation
- ドラフト、予約公開、可視性制御
- リビジョン履歴
- PostgreSQL フレンドリーな設計（JSONField、インデックス、全文検索対応）
生成されたシステム構造
機能ごとにアプリと共通モデルを分けた構成でした。
共通抽象モデル（apps/core/models.py）
TimeStampedModel、SoftDeleteModel、PublishableModel で重複をまとめています。
8アプリアーキテクチャ:
| アプリ | 責務 |
|---|---|
| accounts | ユーザー・ロール管理 |
| core | サイト設定、マルチサイト拡張ポイント |
| content | 記事・固定ページ・リビジョンの中核 |
| taxonomy | カテゴリ（階層）＋タグ（フラット）の分類体系 |
| media | メディアライブラリ（SHA256重複排除、Alt/Caption管理） |
| comments | コメント機能 |
| navigation | メニュー・ナビゲーション |
| seo | SEOメタデータ管理 |
WP概念 → Django実装のマッピング
| WP Concept | Django Implementation | 実装された機能 |
|---|---|---|
| Post / Page | content.Post / Page | 公開状態、予約投稿、パスワード保護 |
| Taxonomy | taxonomy.Term | カテゴリ（階層）とタグ（フラット）の統合 |
| Post Meta | content.PostMeta | PostgreSQL JSONField による動的拡張 |
| Revision | content.Revision | スナップショット保存とロールバック |
| Media | media.MediaAsset | SHA256 重複排除、Alt/Caption 管理 |
ファイル間の整合性
17B級では SEOEntry と Post のOneToOne連携などで、名前や引数の不一致を経験していました。今回は apps/core/models.py の is_public などを apps/content/models.py のQuerySetで再利用し、少しの手修正で python manage.py makemigrations が通りました。
仕様書を整えてから生成する
速度と品質
生成は遅いものの、一度に出る構造の整合性は良好でした。今回は対話で修正を繰り返すより、SPECを整えて1回で渡す方法が合いました。
小規模モデルとの使い分け
- 17B級（Scout等）: 対話的なコーディング補助、リファクタリング、単体関数の生成
- 397B級（Qwen3.5）: 多ファイル・多モデルの構造生成、アーキテクチャレベルのコード生成
運用パターン
- 人間がSPECを書く（要件定義＋アーキテクチャ設計）
- 397Bモデルにシングルターンで投入
- 生成されたコードをレビュー・微修正
- デプロイ
受託開発で使う仕様書と同じく、要件と構成を先に明記し、生成コードを人間がレビューする流れです。ローカルの業務システム開発支援として、この使い方を考えています。
再現方法
歯科医院サイト
- Qwen3.5-397B（または同等のコーディングモデル）を起動
- 本記事の「検証1の要件」セクションの内容をプロンプトとして投入
- 生成された6つのHTMLファイルをブラウザで開いて確認
Django CMS 基盤
- WordPress→Django のマッピング仕様書を作成（Post/Page/Taxonomy/Media/Revision等の概念定義）
- プロジェクト構造、設計原則、非スコープを明記
- Qwen3.5-397Bにシングルターンで投入
python manage.py makemigrationsで整合性を確認- 不整合箇所を手修正