はじめに

今朝の早朝、私は自分のソロプロジェクトである LOGOMANCY の Steam ストアページをついに「公開」しました。

LOGOMANCY は、タイピング、物理パズル、そして魔法を組み合わせた言葉遊びです。スイカゲームが Mojipittan（日本の言葉作りのクラシック）と出会うようなイメージを想像してください。あなたは言葉を入力し、文字ブロックが物理演算で落下し、有効な単語を作ると呪文が発動して盤面をクリアします。

初期の概念から公開された Steam ページまで、正確に 10日 かかりました。その期間内に、グラフィックス、サウンドを手掛け、トレーラーに十分な機能を備えた縦断スライスを作り上げました。秘密のソース？ Spec-Driven Development (SDD) サイクルを、私が作成したツール specre が支えています。

この投稿では、SDD—特に Godot Engine と AI エージェントと組み合わせた場合—がソロゲーム開発をいかに強力にするかを共有したいと思います。

specre on GitHub (Tutorial Included)

What is Spec-Driven Development (SDD)?

If TDD (Test-Driven Development) is about writing tests first to ensure code behaves correctly, SDD (Spec-Driven Development) is the "upper layer." It’s about writing the specification first to clarify what you are building before a single line of logic exists.

Standard design docs often become massive, monolithic files in Google Docs or Confluence that start "rotting" the moment they are written. As implementation progresses, the spec and the code drift apart until the documentation is useless.

SDD solves this by managing specifications in the same lifecycle as your code.

specre: An Atomic Specification Format

specre is a lightweight toolkit designed for SDD. It’s built on five core pillars:

1. Atomic Granularity (One File, One Behavior)
   In specre, one Markdown file describes exactly one behavior. Not a "feature" like "Game Over," but a specific behavior: "When letters connected to the floor exceed the deadline, trigger Game Over and display the UI." This granularity is what makes collaboration with AI agents actually work.

2. Context Window Optimization
   LLM context windows are finite. Passing a 50-page design doc wastes tokens and confuses the agent. Because specre is atomic, the AI only needs to read the spec for the specific behavior it’s currently implementing.

3. Living Specs
   Each card tracks its status (draft → in-development → stable → deprecated) and a last_verified date. This makes "spec rot" visible and actionable.

4. Process Agnostic
   It’s a format convention, not a rigid workflow. It works whether you use TDD, BDD, or just "vibe-based" coding.

5. Tool Agnostic
   It’s just Markdown with YAML Front-matter. No proprietary IDE or SaaS required. Use Git, use your favorite editor, and stay in the flow.

The SDD Cycle in LOGOMANCY

To give you a better idea, here is a simplified version of a real specre card from the project:

---
id: "01KKZD4XXEH1M3AAGKSKZRV23Q"
name: "Display New Record during Game Over if the score is a high score"
status: "stable"
last_verified: "2026-03-18"
---

## Related Files
- `logomancy_godot/src/stage/game_over_score_display.gd`
- `logomancy_godot/tests/unit/stage/test_game_over_score_display.gd`

## Feature Overview
After the score count-up finishes on the Game Over screen:
1. "HIGH SCORE: 000000" slides in from the bottom.
2. If the final score exceeds the previous high score, a "NEW RECORD!" label fades in, centered below the high score.

## Design Intent
By clearly showing the player they’ve improved, we increase the sense of growth and the motivation to "try just one more time."

## Scenarios
### Happy Path: High score update
1. Final score > saved high score.
2. High score is saved to disk.
3. HIGH SCORE line appears with the new value.
4. "NEW RECORD!" text fades in.
...

Two key takeaways here:

• The Subject-Predicate Title: The filename is the behavior.
• The "Intent" Field: This explains the value for the player. If you let an AI write this, it often makes excuses about library limitations. Keeping the "Intent" focused on player value ensures the implementation remains "contractually" sound.

The 4-Phase Workflow

I used Claude Code with a custom SDD workflow:

• Analysis: Search existing cards to understand adjacent behaviors.
• Spec Creation: Write the new behavior as a specre card.
  • Checkpoint: Human reviews the spec.
• Test-First Implementation: Write tests based on the scenarios, then implement the code.
• Maintenance: Update status to stable and commit.

The beauty of this is that the human only needs to review the spec. If the spec is right, the AI can handle the heavy lifting of implementation and testing.

Why Godot is the Perfect Match for SDD

I’ve found that the specre × SDD cycle is particularly effective with Godot Engine for three reasons:

1. GDScript Readability
   GDScript’s Python-like syntax is incredibly concise. When an AI generates code from a specre card, it doesn't waste the context window on C++ boilerplate. You get pure behavior.

2. Scene Tree & Responsibility Segregation
   Godot’s Node system encourages separating concerns. A script like game_over_score_display.gd has exactly one job, which maps 1:1 to a single specre card.

注: GDScriptは動的ですが、仕様から派生したテストのスイートを持つことは、大規模なリファクタリングに必要な安全網を提供します。

10日間のスプリントからの教訓

「プロジェクトマップ」効果
specreカードをドメインごとに分類することで、プロジェクト構造が見えるようになります:

• letter/（9枚のカード）: 入力、字間、辞書検証。
• stage/（20枚以上のカード）: ゲームループ、物理演算、レベルの進行。
• magic/（8枚のカード）: 元素効果、引力ロジック。
• ...など。

ディレクトリ内のカード数は、ゲームのどこに複雑さが潜んでいるかを正確に教えてくれます。

スペックのコストを下げる

specre の README は次のとおり：「仕様をできるだけ小さく、書くのも安価にして、スキップする理由をなくそう。」

従来のドキュメントは「高価」だから失敗します。仕様を書くのに1–2分かかる場合（AIがドラフトを作ってくれる場合）、仕様を書く方が、考え抜かなかった機能をデバッグするより速いです。

結論

10日でSteam対応状態に到達することは、「詰め込み」ではなく、意図の明確さに関するものでした。

1. Atomic Specs = AIにとっての明確な指示。
2. Automated Workflow = 「次は何をするか」という精神的負担を減らす。
3. Spec Review > Code Review = 人間の開発者の意思決定処理能力を高める。

このゲームに興味がある方は、Steamのページを確認してウィッシュリストに追加してください！

著者について

私はピクセルアートと効率的なシステムを愛するデザイナー／デベロッパーです。私の進捗を追い、私のピクセルアニメーションを見るには Bluesky をご覧ください。