Djangoとゼロのフロントエンドフレームワークで、マルチプレイヤーゲームを完成させたプロジェクトがある。Christian Ledermann氏が公開した「Buzzword Bingo」は、カンファレンスや会議で飛び交うバズワードをビンゴ形式で記録するWebアプリだ。ゲームの内容よりも、その開発プロセスそのものが技術的に注目に値する。
このプロジェクトで採用された手法が「仕様駆動開発（Spec-Driven Development）」だ。コードを直接書くのではなく、システムが何をすべきかを記述した仕様書を先に作り、AIエージェント（ここではClaude）にその仕様を実装させる。著者はSpeckitというツールを使って仕様を管理し、「コードを書く前に仕様を固める」サイクルを徹底した。仕様は3つに分割されており、プロジェクト骨格の構築、バックエンド実装、フロントエンド実装という順序で進んでいる。
骨格の立ち上げには「scaf」というツールを使った。scafはKubernetesマニフェスト、Terraform構成、CIパイプライン、Pythonツールチェーンをまとめて生成するプロジェクト初期化ツールだ。本来なら最初の数時間を費やすインフラ配線を省略し、AIとの仕様駆動実験そのものに集中できる環境を最初から整えられた点が大きい。
JavaScriptフレームワーク不使用という選択とHTMXの役割
フロントエンド観点で最も興味深いのは、ReactもVueも使わず、HTMXだけでインタラクティブなマルチプレイヤーゲームを実現した点だ。HTMX（ハイパーテキスト拡張マークアップ）は、HTML属性にAJAXの挙動を直接記述できるライブラリで、JavaScriptをほぼ書かずに非同期通信を実現する。
HTMXのインタラクションモデルは単純だ。ユーザーがビンゴのマスをクリックするとPOSTリクエストが送られ、サーバーが更新済みのHTMLフラグメント（HTMLの断片）を返し、ページの該当部分だけを差し替える。クライアント側に状態を持たないため、Reduxのような状態管理ライブラリは不要になる。以下のようなHTMX属性を使うだけで実現できる。
<button hx-post="/board/mark/" hx-target="#cell-42" hx-swap="outerHTML">
AI
</button>この設計はサーバーサイドレンダリング中心のDjangoと相性がよく、Djangoテンプレートエンジンがそのままフラグメントのレンダリングを担う。WebSocketやServer-Sent Eventsを使わずとも、マルチプレイヤーのリアルタイム性をある程度再現できる構成だ。
ケイパビリティURLという認証レス設計
もう一つ注目すべき設計がケイパビリティURL（Capability URL）だ。これは「URLを知っていること自体がアクセス権限の証明になる」という考え方で実装された認可（アクセス制御）の仕組みだ。各ビンゴボードには固有のUUIDが割り当てられ、/board/5b97b663-1f2f-4e54-8d2f-f45f3272f870/ という形のURLを持つ者だけがそのボードにアクセスできる。
この方式はW3CのFinding: Good Practicesでも言及されており、一時的なアクセス共有やパスワードレスの招待リンクなどで実際に使われている。ユーザーアカウント、セッション管理、JWTトークン検証といった認証基盤を一切持たなくてよくなるため、軽量なゲームアプリとしては合理的なトレードオフだ。
Python型システムを3つの型チェッカーで多重検証する
バックエンドの実装面では、Pythonの型安全性を極限まで高める試みが行われている。著者はty、zuban、pyreflyという3つの型チェッカーを並列稼働させた。これらはいずれも静的型検査（実行前にコードの型不整合を検出する仕組み）のツールであり、それぞれ異なる解析エンジンを持つ。
なぜ1つではなく3つ使うのか。型チェッカーによって検出できる問題の種類に差があるため、複数を組み合わせるとより広いカバレッジが得られる。これをruffの厳格な設定と組み合わせてpre-commitフック（コミット前に自動実行されるチェック）として走らせ、CIに到達する前に問題を潰す構成にしている。
Claude（AIエージェント）に対しては次のような指示が有効だったと著者は述べている。
Prefer precise, narrow types (Enum, NewType, TypedDict, dataclasses with Final or Literal fields)
over Any, untyped dict or list, or stringly-typed values.
Illegal states should be unrepresentable in the type system rather than guarded at runtime.「実行時のガードより型システムで不正な状態を表現不可能にする」という方針だ。いくつかの例を見せた後、Claudeが自律的により表現力の高い型アノテーションを生成するようになったという報告は、AIエージェントへのコンテキスト付与がいかに重要かを示している。
この実験から読み取れる設計の方向性
このプロジェクトが示すのは、次のような組み合わせが現実的に機能するという証左だ。
- HTMXによるJavaScriptフレームワーク不使用のインタラクティブUI
- ケイパビリティURLを用いた認証不要の軽量アクセス制御
- 複数型チェッカーの並走による高カバレッジな型安全性
- 仕様書を起点にAIエージェントに実装させる仕様駆動アプローチ
HTMXの採用は「すべてのUIにSPAが必要か」という問いへの一つの回答でもある。React等のクライアントサイドフレームワークはJavaScriptバンドルサイズ、ハイドレーション（サーバーレンダリング結果をクライアントでJSが引き継ぐ処理）、状態管理の複雑さをもたらす。インタラクションの複雑度が低いアプリではHTMXの方がシンプルな構成を保てる。日本の開発現場でも、Railsや既存のDjango/LaravelプロジェクトにHTMXを部分的に導入して段階的に動的UIを足す事例が増えている。
AIエージェントに良い型付きコードを書かせるには、型の方針をプロンプトや仕様に明示的に盛り込む必要があるという知見は、これからAI駆動開発を設計する際の具体的な手がかりになる。