「作文」を卒業し、AIと同期する「実行可能な設計図（Seed）」を定義する
はじめに：仕様書は「コードの種（Seed）」であり「SSOT」である
2026年、仕様書作成は「人間が読むための作文」という役割を終えました。
現在の仕様書に期待されるのは、CursorやWindsurf、あるいは自律型エージェントが迷いなく実装を完了させ、同時にシステムの整合性を動的に監視できる 「機械可読な高精度パラメータ（SSOT：単一の信頼できる情報源）」 としての品質です。
長文脈モデルの抱擁力に甘え、無秩序な情報を流し込む「コンテキストの暴力」は、AIによる合意の幻覚（Consensus Hallucination）を招きます。
本記事では、LRS（機械可読仕様）、Gitベースのステート管理、Context ETL、そして防御的Agentic Workflowを軸とした、2026年における最新にして最強の規律を解説します。
ベストプラクティス1：Context ETLと「論理の重力（Gravity）」の制御
素材をそのまま放り込むのはアンチパターンです。
2026年の現場では、Dify等を用いた情報の「剪定」と「衝突解決ポリシー」の明示が必須です。
1. Dify「Question Classifier」による文脈の階層化
フロントに入力を以下の階層に自動分類する機能（Classifier）を置きます。
不足があれば、その場でAIがユーザーに聞き返すロジックを実装します。
- Level 1: Core Requirements (事実/制約): DB定義、セキュリティ制約、API仕様。
- Level 2: Supplementary Info (意図/参考): ユーザーインタビュー、Vibe、過去の経緯。
2. Weighted Priority & Conflict Resolution Policy（紛争解決）
「セキュリティ制約」と「パフォーマンス要件」が物理的に衝突した場合、AIはもっともらしい妥協案を捏造します。
- 設計の規律： 「衝突が発生した場合は勝手に解決せず、Conflict Reportを出力して人間の介入を待て。AIに判断を委ねるな、ポリシーを執行させよ」と明文化します。
3. 情報の鮮度管理（Metadata Weighting & TTL）
メタデータに「日付」を付与して最新情報を重み付けします。
また、経営判断や流動的な要件には TTL（Time To Live） を設定し、定期的に古い情報をナレッジベースからパージする運用を徹底します。
ベストプラクティス2：LRSの強制と「形式的な不変条件（Invariants）」
人間が読むMarkdownを生成するだけでは不十分です。
仕様書はコーディングエージェントへの「精密な入力パラメータ」でなければなりません。
1. LLM-Readable Spec (LRS) の絶対要件
LLM-Readable Spec（LLM可読仕様書）とは、人間だけでなく、大規模言語モデル（LLM）が効率的に理解・解釈し、コード生成や設計レビューを自動化しやすいように設計されたドキュメント形式です。
API定義やデータモデルの出力において、曖昧さを許さない 「OpenAPI 3.1形式」または「Protobuf」の厳格なスキーマ定義を強制します。
これがCursor等のコーディングAIが直接読み込み、ボイラープレートを一撃で生成するための唯一のフォーマットとなります。
2. 検証を越えた「形式的な不変条件（Invariants）」の抽出
システムが常に真であるべき性質を、論理式としてAIに定義させます。
- 不変条件の例: $Stock \ge Reserved$ （在庫数は常に予約数以上でなければならない）
3. IaCノードによる物理的コード変換
抽出した不変条件やLRSを、n8nのCodeノードを使って 「Zodスキーマ（TypeScript）」や「CHECK制約（SQL）」として自動生成 し、Gitの特定ディレクトリへ配置するまでが「Executable Design」の真骨頂です。
ベストプラクティス3：防御的Agentic WorkflowとGitベースの双方向同期
シングルプロンプトによる一発生成は論理の飛躍を招きます。
役割を分けたエージェントに「批判的対話」をさせ、そのプロセスをGitという確固たるインフラで統制します。
1. Git-based Spec Management と Diff-Centric Review
Git-based Spec Management（Gitベースの仕様管理）とは、仕様書（スペック）をコードと同様にGitリポジトリで管理し、バージョン管理やレビューのプロセスに組み込む手法です。
特に近年、GitHubがリリースした Spec Kit の登場により、AIを活用した「仕様駆動開発（Spec-Driven Development）」としての注目が高まっています。
Diff-Centric Review（差分中心のレビュー）とは、仕様やコードの「変更点（Diff）」そのものに焦点を当て、その妥当性を検証するレビュー手法です。
Gitベースの仕様管理（Spec Management）においては、ドキュメント全体を読み直すのではなく、「何がどう変わったか」という履歴の差分をベースに議論を進めることで、レビューの効率と精度を劇的に向上させます。
仕様のドリフト（乖離）を物理的に防ぐため、仕様書はWikiではなくGitリポジトリで管理します。
AIが仕様を更新する際は必ずPull Request（PR）を作成させ、人間は「Diff（変更差分）」とその「変更意図」のみを確認する運用フローを徹底します。
2. 役割の完全分離とバックプロパゲーション（逆伝播）
バックプロパゲーション（誤差逆伝播法）は、ニューラルネットワークの学習において「予測と正解のズレ（誤差）を最小にするために、各パラメーターをどう修正すべきか」を計算するアルゴリズムです。
- Agent A (PM): ビジネス要件からドラフトを作成。
- Agent B (Engineer): LRSや既存スキーマとの矛盾を突き、実装の穴を埋める。
- Agent C (Feedback): 実装フェーズで判明した物理的な不可能を仕様レビュー・ループに自動で差し戻し（Back-prop）、SSOTを更新する。
3. 無限ループ防止（サーキットブレーカー）と神託(最終確定した重要な生成結果)のADR保存
Architecture Decision Record (ADR) とは、ソフトウェア開発において下された 「重要な設計上の意思決定」とその背景、理由、結果を簡潔に記録するドキュメント です。
単に「何を決めたか」だけでなく、「なぜその選択をしたのか」「どのような代替案を検討し、なぜそれらを却下したのか」といったコンテキストを残すことに重点を置いています。これにより、数年後に新しいメンバーが加わった際や、技術選定を再検討する際に「当時の状況」を正確に把握でき、同じ議論の繰り返しを防ぐことができます。
AI同士をループさせると無限に再試行を繰り返すリスクがあります。
- サーキットブレーカー: 再試行回数が3回を超えたら、強制的に「Conflict Report」を生成して人間にSlack通知し、プロセスを停止します。
- Human-Oracle と ADR生成: 人間が査読して神託（Oracle）を下し承認ボタンを押した際、そこまでの対話ログをAIに要約させ、「ADR（Architecture Decision Record）」としてMarkdown形式でGitに自動コミットさせます。
ベストプラクティス4：FinOpsとしてのコスト管理
全ての仕様書にこの重厚なフローを適用すると、トークン消費量で破綻します。
機能の重要度に応じて「規律の強度」を使い分けるのが実務におけるFinOpsの鉄則です。
| ティア対象機能 | ワークフロー強度 |
|---|---|
|
Tier 1 (Core) 決済、認証、認可、基幹ロジック |
3役フルループ ＋ Human-Oracle ＋ LRS/不変条件の形式検証 |
|
Tier 2 (High) 新機能、外部API連携、複雑なUI |
2役ループ ＋ LRSの自動バリデーション |
|
Tier 3 (Normal) 文言変更、既存画面の微調整 |
1パス・Diffレビューのみ |
2026年式：分離型「実行可能プロンプト」集
これらの規律をAIに強制するための、統合版メタ・プロンプトです。
1. 【ドラフト生成】PMエージェント用
あなたは経験豊富なシニアPMです。インプット情報を「Core」と「Supplementary」に分類し、仕様書ドラフトを作成してください。
紛争解決ポリシー: セキュリティ \> パフォーマンス \> ユーザビリティ。
衝突時は勝手に解決せず「Conflict Report」を出力し、処理を中断せよ。
**[制約事項] API仕様は必ずOpenAPI 3.1形式（YAML）のコードブロックとして出力し、LLM-Readableな状態を保つこと。**
2. 【攻撃的レビュー】エンジニアエージェント用
あなたはリードエンジニアです。提示されたLRS（OpenAPI 3.1）およびドラフトに対し、既存の共通スキーマとの矛盾、PII（個人情報）露出リスク、技術的負債を徹底的に批判してください。
実装不能な箇所は具体的な制限事項と共に「Feedbackエージェント」へ差し戻しを要求せよ。
**[Git制約] 出力する修正案は、変更の意図を明確にした「Conventional Commits」形式のコミットメッセージを必ず先頭に付与すること。**
3. 【検証・不変条件定義】QAエージェント用
あなたはQAシニアエンジニアです。仕様から、システムが常に維持すべき「形式的な不変条件（Invariants）」を論理式で抽出してください。
AC（受け入れ条件）がそのままテストコード（Jest/Cypress）およびZodスキーマに変換可能か検証し、変換可能なデータフォーマット（JSON）として出力せよ。
おわりに
2026年において、仕様書を書く能力とは、「AIエージェントにバグのないコードを書かせるための『高精度な設計図（LRS）』をオーケストレートし、Gitを通じて状態を統制する能力」 のことです。
プロンプトの「言い回し」に悩む時間は終わり、これからは文脈のデータパイプラインをどう設計し、AI同士の馴れ合いを防ぐガードレールをどこに置くかがエンジニアの主戦場となります。
仕様書を「コードの種」に変え、真の自律型高速開発を実現しましょう。
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
AI駆動開発（Vibe Coding）とn8nを活用した業務資産化・シャドーITの解体を専門としています。