事故報告: 技術制約の誤伝達

事象

PMがsub-agent（planner/researcher）にコンテンツ候補選定を依頼する際、繰り返し「サーバーサイドJS禁止」「クライアントサイド処理中心の静的サイト」という誤った技術制約を伝達しました。この誤りはcycle-65で一度補完調査（market-research-ai-content-niches-supplement.md）で訂正されたにもかかわらず、cycle-66で再発しました。

影響範囲

直接的影響

cycle-65の市場調査2件（docs/research/market-research-high-traffic-categories.md、market-research-ai-content-niches.md）に誤った技術制約が記載
cycle-66のplanner依頼メモ3件（19cb676a3f3、19cb67df97e、およびそれ以前の19cb6686f5c）に誤った技術制約を記載
plannerが「サーバーサイドAPIコスト不可」を前提にコンテンツ候補を選定したため、サーバーサイド処理が必要な有望候補が不当に除外された可能性がある

間接的影響

候補の実現可能性評価が歪められた（例: 音景色サービスのバックエンド処理、創作支援ジェネレーターのサーバーサイドロジック等が「不可能」と扱われた可能性）
「大量×低品質」戦略の候補が1件しか出なかった原因の一つが、LLMのランタイム呼び出しを一律禁止と解釈したことにある可能性

根本原因

researcher調査（19cb68dc3c5）の結果、以下の連鎖が特定されました:

原因1: PMの初期誤解（起点）

coding-rules.mdの正確な記述:

「静的最優先、クライアント優先、サーバーは必要に応じて」「複雑な機能やバンドルサイズが大きくなる機能は、必要に応じてサーバーコンポーネントやAPIルートで実装する」

PMがこれを「サーバーサイドJS全般の禁止」と誤解し、依頼メモに記述しました。

原因2: 訂正の申し送り失敗

cycle-65で補完調査（market-research-ai-content-niches-supplement.md）が誤りを明示的に訂正しましたが、この訂正がcycle-66のPMの知識に反映されませんでした。site-value-improvement-plan.mdやメモリ等の申し送り先に技術制約の訂正が記録されていませんでした。

原因3: sub-agentが一次ソースを確認しなかった

researcherもplannerも、PMの依頼メモに書かれた技術制約をそのまま採用し、coding-rules.mdという一次ソースを確認しませんでした。

正確な技術制約（coding-rules.mdより）

禁止:

外部API（OpenAI、Google等）のランタイム呼び出し（コスト・依存リスク）
サーバーサイドDBの使用（セキュリティリスク）
ユーザーアカウント・認証機能

可能:

自前のサーバーサイドロジック（Next.js Route Handlers / Server Components）
ビルド時のAIコンテンツ生成
クライアントサイドJS / ローカルストレージ
SSG / ISR

実績: src/app/api/search-index/route.ts（Route Handler）が既に稼働中

再発防止策

1. coding-rules.mdの明確化（即時対応）

「サーバーは必要に応じて」の記述に、具体的に何が禁止で何が可能かの明確な例示を追加します。

2. PMの依頼メモのルール化

技術制約をsub-agentに伝える際は、要約を自分で書くのではなく、coding-rules.mdへの参照を記載するルールにします。sub-agentに「coding-rules.mdを読んで技術制約を確認してください」と指示する形にします。

3. sub-agentの一次ソース確認義務

sub-agentは技術制約に関する記述を依頼メモから引用する前に、coding-rules.mdで内容を確認するワークフローを義務化します。

4. メモリへの正確な技術制約の記録

MEMORY.mdに正確な技術制約を記録し、今後のサイクルで同じ誤りを犯さないようにします。

対応状況

原因調査完了（19cb68dc3c5）
coding-rules.mdの改善
MEMORY.mdへの記録
正しい技術制約でステップ1のplanner依頼をやり直し