スペックマキシング: YAML仕様とACAIでAI精神病と戦う

Acai.shの最新ブログ記事「Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML」は、コンテキストウィンドウがいっぱいになったりセッションが切れたりしたときにAIエージェントが暴走する問題に取り組んでいます。著者は実用的なワークフローを共有しています。マークダウンだけでなく、YAMLで構造化された仕様を書き、エージェントがコード内で直接参照できる番号付き要件（例：AUTH-1、AUTH-2）を使用します。この方法は、Acceptance Criteria for AI（ACAI）と呼ばれ、サブエージェントが自動で要件に番号を付け、実装内で参照したことで、トレーサビリティが向上し、リグレッションが減少したことから生まれました。

この記事では、4段階のプロセスを説明しています。Specify（YAMLで要件を記述）、Ship（エージェントに実装させる）、Review（コードを仕様と照合）、Iterate（繰り返す）。著者は、以前はマークダウンの仕様（PRD、TRD、アーキテクチャドキュメント）をやりすぎて「AI精神病」に苦しんでいたことを認めています。つまり、製品を作るよりAIハーネスを作るのに時間を費やしていたのです。YAMLベースのアプローチは、より軽量で機械が処理しやすいことを意図しています。

重要な洞察：プレーンなREADME.mdとAGENTS.mdでも、エージェントの出力が大幅に改善されます。この記事は「ピーク・スロップ」は過ぎ去り、構造化された仕様が次の進化であると主張しています。コードスニペットがパターンを示しています：

# Requirements
AUTH-1: Accepts `Authorization: Bearer <token>` header
AUTH-2: Tokens are user-scoped, providing access to any of the user's resources
AUTH-3: Rejects with 401 Unauthorized

// AUTH-1
const authHeader = req.headers["authorization"];
// AUTH-2
const isAuthorized = verifyBearerToken(authHeader);
// AUTH-3
if (!isValid) return res.status(401).json({ error: "Unauthorized" });

また、代替案（GitHub SpecKit、OpenSpec、Kiro、Traycer.ai）をレビューし、acai.shを好まない理由（オーバーヘッド、形式の押し付けなど）も挙げています。これは、AIエージェントに絶えず修正を指示するループなしで信頼性の高いコードを出荷させたい開発者向けの実用的な見解です。

対象読者： AIコーディングエージェント（Claude、Copilotなど）を使用していて、コンテキスト制限にぶつかり、エージェントを軌道に乗せる軽量な仕様レイヤーを求める開発者。