Qwen3.5-397B 自律コード生成検証：歯科医院サイトから Django CMS 基盤まで
400B級 MoE モデル Qwen3.5-397B を用いた2つのコード生成検証の記録。歯科医院向け6ページ静的サイト（HTML+Tailwind+Alpine.js）のワンショット生成と、WordPress ライクな Django CMS 基盤（8アプリ、20超モデル）のシングルターン生成。設計意図をSPECとして渡せば、実装はAIが組み上げる時代の実践データ。
結論
Qwen3.5-397B は「設計書を渡せばコードが出てくる」を現実に近づけている。 本記事では2つの検証を記録する。
- 歯科医院向け静的サイト — HTML + Tailwind CSS + Alpine.js で6ページをワンショット生成（約18分）
- WordPress ライクな Django CMS 基盤 — 8アプリ、20超モデル、Django設定一式をシングルターン生成
どちらも「人間がSPECを書き、AIが実装する」パターンで、生成後の手修正は比較的少なく済んだ。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 環境での397B推論はデコード速度が数 tok/s まで低下する。対話用途にはやや不向き。本モデルは「シングルターンでの構造生成」や「夜間バッチによる一斉コード生成」に特化して運用する。
検証1: 歯科医院向け静的サイト（ワンショット生成）
要件
- 構成: index, services, doctors, info, visit, access の6ページ
- 技術制約: ビルドステップなし、Tailwind CSS (CDN)、Alpine.js (CDN)、外部UIライブラリ禁止
- 必須機能: モバイルハンバーガーメニュー（ESC/フォーカス管理）、カテゴリフィルタ、FAQアコーディオン、見積もりモーダル、フォームバリデーション
- 品質要件: セマンティックHTML5、ARIA属性、キーボードナビゲーション、レスポンシブ
実行結果
LLMは以下のプロセスを約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、インデックス、全文検索対応）
生成されたシステム構造
AIは単にモデルを羅列せず、Djangoのベストプラクティスに基づいた関心の分離を徹底した。
共通抽象モデル (apps/core/models.py):
TimeStampedModel, SoftDeleteModel, PublishableModel 等の抽象基底クラスでDRY原則を物理レベルで遵守。
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 連携）でメソッド名や引数の不整合が多発する。
Qwen3.5-397B は、apps/core/models.py で定義したプロパティ（is_public 等）を apps/content/models.py の QuerySet 定義で正確に再利用した。python manage.py makemigrations が限定的な手修正で通るレベルの整合性を確認。
考察: 「プロンプト・アーキテクト」への移行
速度 vs 品質のトレードオフ
397Bモデルは遅い。だが一発で出るコードの整合性が高い。対話的なやり取りで修正を重ねるよりも、SPECを練り上げてシングルターンで投げる方が総合的な生産性は高い。
小規模モデルとの使い分け
- 17B級（Scout等）: 対話的なコーディング補助、リファクタリング、単体関数の生成
- 397B級（Qwen3.5）: 多ファイル・多モデルの構造生成、アーキテクチャレベルのコード生成
運用パターン
- 人間がSPECを書く（要件定義＋アーキテクチャ設計）
- 397Bモデルにシングルターンで投入
- 生成されたコードをレビュー・微修正
- デプロイ
この「設計書→AI実装→人間レビュー」のパイプラインが、loFT LLCが追求する「知能のオンプレミス化」の実用形態。
再現方法
歯科医院サイト
- Qwen3.5-397B（または同等のコーディングモデル）を起動
- 本記事の「検証1の要件」セクションの内容をプロンプトとして投入
- 生成された6つのHTMLファイルをブラウザで開いて確認
Django CMS 基盤
- WordPress→Django のマッピング仕様書を作成（Post/Page/Taxonomy/Media/Revision等の概念定義）
- プロジェクト構造、設計原則、非スコープを明記
- Qwen3.5-397Bにシングルターンで投入
python manage.py makemigrationsで整合性を確認- 不整合箇所を手修正