何が起きたか
Peter Gostev氏が2026年7月13日、「DOOMQL」という小さなオリジナルのDOOM風ゲームを公開しました。特徴は、SQLite（軽量なファイル型データベース）を単なるデータ保存先ではなく、ゲームエンジンそのものとして使っている点です。プレイヤーの移動、当たり判定、敵の挙動、戦闘、進行度、さらには画面に表示される1ピクセルごとのRGB値まで、すべてをSQLが計算します。
出発点は、氏いわく「あえて無茶な問い」でした。SQLiteをゲームがデータを保存する場所ではなく、ゲームエンジンにできないか、という問いです。中核となるのは、再帰CTE（共通テーブル式）を用いてSQLite内に完全なレイトレーサーを実装した、巨大な1本のSQLクエリです。
実体はPythonのターミナル用スクリプトで、リポジトリ（github.com/petergpt/doomql）をクローンし uv run host/doomql.py を実行すれば動きます。実行すると /tmp/doomql/.doomql/doomql.sqlite にSQLiteデータベースが作られ、データ探索ツール「Datasette」で中身を覗けます。
Datasetteの上でプレイ画面を再現する
面白いのはここからです。DatasetteのAppsプラグインは、SQLクエリを実行するHTML+JavaScriptの独自アプリをDatasette内で動かせます。氏はClaudeのチャット（Fable 5）に「frame_pixelsビュー（x, y, r, g, bカラム）を使って画面の現在状態を表示し、1秒ごとに更新するアプリを作って」というプロンプトを貼り付けるだけで、プレイ画面をブラウザに再現するアプリを生成しました。さらに「ミニマップを追加して」と追記し、機能を拡張しています。
つまり、ゲームの状態はすべてデータベースの行として存在し、画面はそのテーブルを1秒ごとに読み出して描画した結果にすぎない、という構造です。
なぜ面白いのか
これは「SQLでゲームを作れる」という奇抜な実験に見えて、実は宣言的なデータモデルと、AIによる即席ビューアー生成が組み合わさった好例です。ロジックがすべて宣言的なSQLとして1箇所に集約され、その状態を任意のツール（Datasette）から自由に観測・可視化できる。しかも可視化レイヤーは自然言語のプロンプト1つで生成される——この分業のかたちに示唆があります。
💼 事業会社視点：これは自社にどう効くか
「SQLでDOOM」は一見ネタですが、事業責任者が読み取るべきは2点です。第一に、状態をすべて宣言的なデータとして持たせると、可視化・デバッグ・監視ツールを後付けで自由に差し込める、という設計の効き目です。ロジックをコードに埋め込まず、DBの行として観測可能にしておくほど、運用や分析の自由度が上がります。SaaSや受託開発で「なぜこの状態になったか」を追えず苦しむ現場ほど、この発想は効きます。第二に、可視化レイヤーの生成コストが実質ゼロに近づいている点です。DatasetteのAppsとClaude（Fable 5）の組み合わせでは、プロンプト1文で社内データの閲覧アプリが立ち上がります。BIツールの導入や画面開発を待たず、事業部長が自分でダッシュボードを試作できる時代です。経営者は「まず整ったデータ層を持ち、ビューは都度AIで生成する」体制へ、社内データ活用の前提を切り替えるべきです。