想定読了時間: 25分（detailsを展開する場合 35分）
対象読者: B2B SaaSの要件定義に関わるエンジニア・PM。前作の8ステップを知っていると理解が深まるが、未読でも本記事単独で読み進められる。
先に全体像だけ掴みたい場合は、TL;DR → 「3つの新概念」 → 「チェックリスト」 → 「次アクション」だけ読めば十分です。
前作: 「要望」「要求」「要件」は別物――役割別観測点を同じ座標系に変換するSaaS要件定義8ステップ地図
TL;DR
- AIでコードが書ける時代だからこそ、「何を作るか」を定義するプロセスの重要性は上がっている。抽象化の歴史に照らせば、要件定義はエンジニアの仕事の中で上に移動する。
- バイブコーディング（曖昧な指示でAIに作らせ、気に入るまで繰り返す）は探索には使えますが、チーム開発・保守・監査には耐えません。仕様駆動開発（SDD）はその解として台頭しましたが、Thoughtworks Radar Vol.33（2025-11）では「Assess」止まり――期待と現実にギャップがあります。
- 2025年末から2026年にかけて輪郭が明確になった3つの概念が、要件定義プロセスの位置づけを変える:
- Context Engineering: 仕様書を「AIエージェントの文脈」として設計する
- Harness Engineering: 要件定義プロセスそのものを「AIを制御するハーネス（手綱）」として構築する
- Humans on the Loop: 人間は1行ずつコードを確認する存在（in the loop）から、制御構造を設計する存在（on the loop）へ
- 前作の8ステップ（要望→要求→要件の変換地図: 問題/機会の定義→利害関係者の特定→要望収集→要求整理→プロダクト要件→機能＋非機能→曖昧語排除→合意形成→バックログ化）は、そのままAI時代の「ハーネス」として機能します。ただし「仕様書がエージェントの文脈になる」という設計観点と、SDDの限界を理解した上で使う必要があります。
はじめに: バイブコーディングの罠
2024年からAIコーディングツールが急速に普及し、「AIに指示すればコードが出る」時代が日常になりました。その中で生まれたのがバイブコーディング（Vibe Coding）――曖昧な指示を出してAIに作らせ、気に入らなければフィードバックし、繰り返す手法です。
プロトタイプや個人開発では有効ですが、チーム開発に持ち込むと根本問題が表面化します。
| 問題 | 具体 |
|---|---|
| 字義通りのペアプロ相手（Literal-minded pair programmer） | AIは「文字通りに」解釈する。曖昧な指示→曖昧な結果 |
| コンテキストの揮発 | セッション間で仕様が消える。昨日のAIは今日の文脈を知らない |
| チーム一貫性の崩壊 | 各人がバラバラにAIへ指示→コードベースの設計思想が散逸 |
| 保守・監査に耐えない | 「なぜこう作ったか」の根拠がプロンプト履歴にしかない |
この問題への反応として「仕様を先に書き、それを基にAIに開発させる」アプローチSDD（仕様駆動開発） が台頭しました。
ここで「仕様」という語に注意が必要です。「仕様」は立場によって指す範囲が異なります。事業側は「やりたいこと」を仕様と呼び、開発側は「実装の設計書」を仕様と呼び、QAは「テストの基準」を仕様と呼ぶことがあります。前作で整理した「要望→要求→要件」の変換地図に照らせば、SDDが扱う「仕様（Spec）」は主に要件レベル（前作Step4〜7: プロダクト要件・機能/非機能・SRS・受入条件）に相当します。要望や要求をそのままSpecとして渡しても、AIは適切に解釈できません。上流の変換プロセスを経て要件化された成果物がSpecになる、という位置づけです。
しかし、SDDも万能ではありません。Thoughtworks Technology Radar Vol.33（2025-11）はSDDを「Assess」に配置し、以下の懸念を挙げています。
"Are we making something worse in the attempt of making it better? (Verschlimmbesserung)"
――Birgitta Boeckeler, Thoughtworks
| 懸念 | 詳細 |
|---|---|
| ワンサイズ問題 | 小さなバグ修正にSDDは大げさ（Kiroで小バグ→4 User Story / 16 AC生成の事例） |
| レビュー過負荷 | 大量のMarkdownファイルが生成され、「コードレビューより仕様レビューの方が辛い」 |
| 制御の錯覚 | 入念に仕様を書いてもエージェントが指示を無視する場合がある |
| MDD回帰リスク | 過去のモデル駆動開発（MDD）も「仕様からコード生成」を目指したが定着しなかった |
つまり、「バイブコーディングがダメだから仕様を書こう」だけでは不十分で、仕様をどう設計し、どう制御構造に組み込むかまで踏み込む必要があります。本記事はその構造を整理します。
「コードを書く作業が自動化される→上流も不要」という飛躍が一部で語られますが、実態は逆です。AIが自動化するのはHOW（実装） であり、WHAT（何を・なぜ作るか） は依然として人間の判断領域です。HOWの自動化が進むほど、WHATを定義する力の希少性と価値は上がる。この点は次のセクションで歴史的に確認します。
変化の本質: 要件定義は「消える」のではなく「上に移動する」
抽象化の歴史
プログラミングの歴史は、抽象度が上がるたびに「何を書くか」が変化する連続です。
| 時代 | 抽象度 | 何を書くか |
|---|---|---|
| 機械語〜アセンブリ | 最低 | HOW（CPU命令） |
| 高級言語〜OOP | 中 | HOW（処理手順） |
| 宣言型（SQL / HTML） | 高 | WHAT（欲しい結果） |
| AI x SDD（2024〜） | 最高 | WHAT（意図・仕様） |
GitHub 元CEO Thomas Dohmke は GitHub Universe 2024 の基調講演で、コードそのものよりも「意図（Intent）」が開発の中心になると述べました。コードではなく意図（Intent）がソース・オブ・トゥルースになる――この認識はAI開発コミュニティで広く共有されるフレーズとなり、OpenAIやThoughtworksなど複数の組織でも仕様記述スキルの希少性が指摘されています（注: Dohmke基調講演動画からのコミュニティ要約表現。書き起こしの一次ソースは公開されていない）。
HOWの自動化が進むほど、WHATの定義（=要件定義）の価値が上がる。要件定義はエンジニアの仕事の中で上に移動する。
SDDの三段階: Spec-first / Spec-anchored / Spec-as-source
Birgitta Boeckeler（Thoughtworks, 2025-10）はSDDを三段階に分類しました。
"Spec-driven development means writing a 'spec' before writing code with AI. The spec becomes the source of truth for the human and the AI."
| レベル | 名称 | 概要 | 仕様の寿命 |
|---|---|---|---|
| 1 | Spec-first | 仕様を先に書き、AI開発に使う | タスク完了で破棄可 |
| 2 | Spec-anchored | 仕様をタスク完了後も維持し、保守・進化に使い続ける | フィーチャーの寿命 |
| 3 | Spec-as-source | 仕様が唯一のソース。人間はコードを直接触らない | プロダクトの寿命 |
レベルが上がるほど仕様の維持コストが増し、ツール・プロセスの成熟が必要になります。現時点でほとんどのチームはLevel 1（Spec-first）が現実的なスタート地点です。
MDDからの教訓
モデル駆動開発（MDD）も「仕様からコード生成」を目指し、広く定着しなかった歴史があります。SDDとの決定的な違いは:
| 項目 | MDD | SDD |
|---|---|---|
| 入力形式 | 独自DSL（UML等） | 自然言語 + 構造化Markdown |
| コード生成 | 決定論的（テンプレート変換） | 確率的（LLM推論） |
| 学習コスト | DSL習得が重い | 自然言語で書けるが、良い仕様の書き方は別のスキル |
LLMは非決定性と引き換えにDSLの制約を除去しました。しかし、「仕様を書けば正しいコードが出る」という期待はMDDと同じ構造であり、確率で考えるべきだという点は忘れてはなりません。
SDDツールの現在地（2026年3月時点）
Birgitta Boeckeler（Thoughtworks）が"Understanding Spec-Driven-Development"で比較分析した3ツールを取り上げます。選定理由は、SDDの三段階（Spec-first / Spec-anchored / Spec-as-source）をそれぞれ代表し、かつアーキテクチャ（OSS CLI / 専用IDE / フレームワーク）が異なるため、SDDの設計空間を俯瞰できるからです。
ツール比較
| 項目 | GitHub Spec Kit | AWS Kiro | Tessl |
|---|---|---|---|
| 形態 | OSS CLI（Python） | 専用IDE + CLI | CLI + MCPサーバー |
| Stars/規模 | 85k+ stars（2026年4月時点） | -- | Public |
| SDDレベル | Spec-first（Spec-anchored志向） | Spec-first | Spec-anchored（Spec-as-source探索中） |
| ワークフロー | Constitution → Specify → Plan → Tasks → Implement | Requirements-First / Design-First |
tessl document → tessl build
|
| 要件記法 | 自然言語Markdown | EARS記法（受入条件・シナリオではGiven/When/Thenを併用） | 自然言語 |
| 成果物 | SPECIFICATION.md / PLAN.md / tasks/ | requirements.md → design.md → tasks.md | Spec → Code（1:1マッピング） |
| AI対応 | 28+（Claude Code, Copilot, Cursor, Gemini CLI, Kiro CLI等） | 専用AI（IDE内蔵） | 独自AI |
| エコシステム | Community Extensions 40+（Jira/ADO連携、V-Model、MAQA等） | Agent Hooks / Steering | 双方向同期 |
| 特記 | Presets（テンプレ/コマンドのカスタマイズ） | Autopilotモード | コードに // GENERATED FROM SPEC - DO NOT EDIT
|
※ Claude CodeはSpec Kitのサポート対象AI（28+のうちの1つ）だが、
/batchbundled skillにより独自のSpec-first相当ワークフロー（CLAUDE.md→コード分解→並列実装）も内蔵している。本記事ではSDDツールとしてではなく、Context Engineering・Harness Engineeringの実装基盤として扱う（後述）。
GitHub Spec Kit
3ツール中でエコシステムの成熟度が際立っています。ワークフローの5段階（Constitution → Specify → Plan → Tasks → Implement）は、前作の8ステップのStep0〜8に対応する構造（Constitutionがプロジェクト原則=Step0〜1に相当）です。Community Extensionsが40以上あり、Jira/Azure DevOps連携やマルチエージェントQA（MAQA）など、実務統合が進んでいます。
AWS Kiro
requirements.md にEARS記法（WHEN [条件] THE SYSTEM SHALL [振る舞い]）をネイティブ採用した主要IDEです。受入条件やシナリオ記述ではGiven/When/Thenも併用します。2つのワークフロー:
- Requirements-First: 要求から始め、設計→タスクへ展開
- Design-First: コンポーネント設計から始め、要件を逆生成
Agent Hooks（ファイル保存イベント等でAIエージェントが自動実行）により、テスト生成やドキュメント更新が自動化されます。
Tessl
Boeckelerが2025-10に評価した時点ではSDDのLevel 3（Spec-as-source）を探索するFrameworkとしてprivate betaでした（「exploring the spec-as-source level」と表現）。仕様が唯一のソースであり、コードは仕様から自動生成されます。tessl document --code で既存コードから仕様を逆生成できるため、既存プロジェクトへの導入パスがあります。ただし、1 spec = 1 code file の1:1マッピング制約があり、複雑なシステムへの適用は未検証です。
2026年4月時点の状況: Tesslはその後、「エージェントスキルとコンテキストのパッケージマネージャー」（Registry）へとプロダクトの重心を移しています。Registryは評価済みスキルの配布・検索・バージョン管理を提供し、Context Engineeringのインフラ層として機能します。Framework（Spec-as-source）の探索は継続していますが、現在の主軸はRegistry側にあります。
批判的評価: SDDの「思ったより難しい」ところ
| 失敗パターン | 原因 | 対策 |
|---|---|---|
| 仕様が抽象的すぎる | WHATしか書いていない | Acceptance Criteriaを必須化 |
| 仕様とコードが乖離 | コード修正後に仕様更新を忘れる | CI/CDで同期チェック（Spec Sync拡張等） |
| 仕様が長すぎてAIが理解できない | 1ファイル肥大化 | 1ファイル500行以内で分割 |
| チームが仕様を書かない | 面倒くさい | AIに初稿生成させる |
| 過度に詳細な仕様 | HowをWhatと混同 | WHATに集中、HOWはAIへ |
| 小タスクにSDDを適用 | ワークフローの過剰適用 | 問題サイズに応じたワークフロー選択 |
最後の「問題サイズに応じたワークフロー選択」が特に重要です。SDDはすべてのタスクに適用すべきものではありません。バグ修正や小さなリファクタリングにまで仕様ファーストを強制すると、プロセスのオーバーヘッドが開発速度を殺します。
SDDの適用判断基準（目安）
| 問題サイズ | 推奨アプローチ | 理由 |
|---|---|---|
| バグ修正・設定変更 | 直接修正 + テスト | 仕様化のコスト > 修正コスト |
| 小機能追加（1-2日） | 軽量Spec（Acceptance Criteria + 制約のみ） | 最小限の文脈共有で十分 |
| 中規模フィーチャー（1-2週） | Spec-first（Spec Kit / Kiro） | SDD本来の適用範囲 |
| 大規模プロジェクト（1ヶ月+） | Spec-anchored + Context Engineering | 仕様の寿命が長い。保守フェーズまで見据える |
AIで変わるプロセス: 既存8ステップとの対応
前作の8ステップ（要望→要求→要件の変換地図）のうち、AIによって特に変化するStepを整理します。全Stepの基本構造は前作を参照してください。
以下に8ステップの全体像と、本記事での扱いを示します。
| Step | 名称 | 変換フェーズ | AI影響度 | 本記事での扱い |
|---|---|---|---|---|
| 0 | 問題/機会の定義 | 要望 | 低 | Context Engineering（常時文脈）で後述 |
| 1 | 利害関係者の特定・事業目的 | 要望 | 低 | 同上 |
| 2 | ステークホルダー要求の収集 | 要望→要求 | 高 | Elicitronフレームワーク（本セクション） |
| 3 | 要求の整理・構造化 | 要求 | 中 | AI初稿生成で加速（個別解説は省略） |
| 4〜5 | プロダクト要件 + 機能/非機能 | 要求→要件 | 高 | 仕様書 = エージェントの文脈（本セクション） |
| 6 | 曖昧語排除（SRS粒度） | 要件 | 高 | EARS記法（本セクション） |
| 7 | 受入条件・合意形成 | 要件 | 中 | EARS→Gherkin連鎖でStep6内に統合 |
| 8 | バックログ化 | 実行 | 高 | SDDツールとの接続（本セクション） |
Step2: ステークホルダー要求の収集――Elicitronフレームワーク
問題: ユーザーインタビューのコスト（時間・人員）と、多様な視点の欠如。
Elicitron（2024年、arXiv:2404.16045）は、LLMで多様なユーザーペルソナを自動生成し、仮想インタビューで潜在ニーズを抽出するフレームワーク。
- LLMで多様なユーザーペルソナを生成（典型・非典型の両方）
- 製品体験をシミュレーション（Action / Observation / Challenge）
- 仮想ユーザーにインタビューを実施
- Chain of Thinkingで潜在ニーズを判定・抽出
成果: 3条件すべてで従来のEmpathic Lead Userインタビュー（ベースライン）より多くの潜在ニーズを抽出。特に手動ELUエージェント条件（Condition 3）は統計的に有意な差（p < 0.05）を示しました。コストは実験全体で約$2.4 USD（GPT-4-Turbo使用）であり、従来の対面インタビューと比較してコスト面の優位性が顕著です。
限界（B2B SaaS文脈で重要）:
- B2Bでは「実在の現場ユーザー・業務制約・法規制」が支配的。仮想ペルソナは実務の文脈を完全には代替できない
- 最終的な要求選定・優先順位付けには専門家の介在が必須
- LLM出力品質と初期コンテキスト設定に大きく依存
ペルソナの妥当性をどう検証するか: 自動生成されたペルソナが現実のユーザー像と合致しているかは、以下の手順で検証できます。
- 既存ユーザーデータとの照合: CRMやサポート問い合わせ履歴から実在ユーザーの属性・行動パターンを抽出し、生成ペルソナとのカバレッジを比較する
- 実インタビューとのクロスバリデーション: 生成ペルソナから抽出されたニーズと、少数の実ユーザーインタビュー結果を突き合わせ、一致度と見落としを測定する
- ドメイン専門家レビュー: B2B文脈では、業務知識を持つ専門家がペルソナの業務制約・法規制の反映度を判定する
生成ペルソナは「仮説」であり、実データによる検証なしに要件の根拠とすべきではありません。
実務への示唆: Elicitronは Step2の「網羅性チェック」として使うのが現実的です。実在ユーザーへのインタビューを置き換えるのではなく、「見落としている視点がないか」を検証する補助ツールとして位置づけます。
Step4〜5: 仕様書の設計――「エージェントの文脈」としての仕様
SDDツール（Spec Kit / Kiro）が生成する仕様書（SPECIFICATION.md / requirements.md）は、前作のStep4（プロダクト要件）〜Step5（機能/非機能）に相当します。
ここでの最大の認識変化は:
仕様書は「人間のためのドキュメント」であると同時に「AIエージェントのコンテキスト」として設計すべき
従来の仕様書は人間が読んで理解することを想定していました。AI時代の仕様書は、それに加えてAIが効率よく参照・解釈できる構造が求められます。具体的には:
- 1ファイルの粒度管理: 筆者の運用目安として500行以内に分割（LLMのコンテキスト窓と注意力の制約による実務ヒューリスティック）。分割の単位は「1フィーチャー」または「1ユースケース」を基本とし、フィーチャーが大きい場合はサブドメイン（例: 検索機能の中の「フィルタ条件」「結果表示」「エクスポート」）で切る。横断的な関心事（認証・監査ログ・エラーハンドリング等）は常時文脈（Memory Bank）側に分離する
- 明示的な前提条件: 暗黙知を書き出す（AIは「読んでいないことは知らない」）
- 検証可能な表現: 曖昧語を排除し、条件/振る舞い/閾値を明記（前作Step6の原則がそのまま適用される）
この「仕様書 = エージェントの文脈」という設計観点は、後述のContext Engineeringで体系的に扱います。
Step6: 検証可能な要件へ――EARS記法
EARS（Easy Approach to Requirements Syntax） は2009年にAlistair Mavin（Rolls-Royce）が提唱した要件の構造化記法。航空宇宙・自動車で採用実績があり、AWS KiroがEARS記法をネイティブ採用したことで、構造化要件記法への実務上の注目度が高まっています。
5つのパターン
EARS記法は英語の構文テンプレートとして設計されたため、以下のパターンは原文のまま示す。
# 常時適用（Ubiquitous）
The system shall <response>.
# イベント駆動（Event-Driven）--- 頻出
When <trigger>, the system shall <response>.
# 状態駆動（State-Driven）
While <state>, the system shall <response>.
# 望ましくない事象対応（Unwanted Behaviour）
If <condition>, the system shall <response>.
# オプション機能（Optional Feature）
Where <feature> is enabled, the system shall <response>.
EARS記法の価値: 前作Step6「曖昧語排除」の代替フォーマット
前作のStep6で「曖昧語を排除し、条件/振る舞い/閾値を明記」と書きましたが、EARS記法はその構造化テンプレートとして機能します。
B2B SaaS文脈でのEARSサンプル（取引履歴の検索）
前作で使った「取引履歴の確認」ドメインで、EARS記法のサンプルを示す。
前作の要件（自然言語）:
条件: 管理画面〈取引履歴〉にて期間デフォルト「直近30日・最大1万件」で検索した場合、(1) UIをブロックしない（ローディング表示・キャンセル可能）、(2) 失敗時はユーザーが次の行動を取れる（リトライ/エラー原因の表示）
EARS記法に変換:
# イベント駆動
REQ-HIST-001: When the administrator initiates a transaction history search
with the default period (last 30 days, max 10,000 records),
the system shall display a loading indicator and provide a cancel option
without blocking the UI.
# 望ましくない事象対応
REQ-HIST-002: If the transaction history search fails or times out,
the system shall display the error cause and provide a retry option
so that the user can take the next action.
# 常時適用
REQ-HIST-003: The system shall emit search_latency_ms, search_error_count,
and search_timeout_count metrics for every transaction history search execution.
EARS → Gherkin → テスト自動生成の三層連鎖
EARS記法の真の価値は、要件→テストの自動化パイプラインを構築できる点にあります。
| レイヤ | ツール | LLMの役割 |
|---|---|---|
| 要求層（Requirements） | SRS / User Story / EARS | 自然文→EARS形式への整形・補完 |
| シナリオ層（Specification） | Gherkin / BDD（Given-When-Then） | EARS→Gherkinシナリオの変換 |
| 実行層（Execution） | Cucumber + Playwright MCP | Gherkin→テストコード生成・ブラウザ自動実行 |
EARS → Gherkin変換の具体例
EARS:
REQ-HIST-001: When the administrator initiates a transaction history search
with the default period (last 30 days, max 10,000 records),
the system shall display a loading indicator and provide a cancel option
without blocking the UI.
Gherkin（AI生成 → 人間レビュー）:
Feature: Transaction History Search
As an administrator
I want to search transaction history with default parameters
So that I can review recent transactions for month-end closing
Scenario: Search with default period shows loading state
Given the administrator is on the transaction history page
When the administrator clicks the search button with default period "last 30 days"
Then the system should display a loading indicator
And the search cancel button should be enabled
And the UI should remain responsive (not blocked)
Scenario: Search results within threshold
Given the administrator initiated a search with default parameters
When the search completes successfully
Then the results should be displayed
And the metric "search_latency_ms" should be recorded
この変換はLLMが高精度で実行でき、人間はレビューに集中できます。
Step8: バックログ化――SDDツールとの接続
前作のStep8（バックログ化）は、SDDツールのワークフロー後半と直結します。
| 前作のStep | Spec Kit | Kiro |
|---|---|---|
| Step4: プロダクト要件 | SPECIFICATION.md | requirements.md |
| Step5〜6: 機能/非機能 + SRS | SPECIFICATION.md（詳細） | requirements.md + design.md |
| Step7: 受け入れ条件 | ACをSPECIFICATION.md内に記述 | requirements.md内のEARS要件 + 受入条件 |
| Step8: バックログ化 | PLAN.md → tasks/ | tasks.md |
Spec Kitの場合、tasks/ ディレクトリに生成された各タスクファイルが実行単位になり、AIエージェントが並列実装可能な形に分解されます。
3つの新概念と要件定義プロセスの接続
2025年末から2026年にかけて輪郭が明確になった3つの概念は、SDDの「仕様を書いてAIに作らせる」という素朴な理解を超え、要件定義プロセスそのものの位置づけを変えます。
各概念の関係: Context Engineering が文脈（素材）を設計し、Harness Engineering がその文脈を含む制御構造（Guides + Sensors）を構築し、Humans on the Loop がそのハーネス自体を設計・改善する存在として位置づけられます。
Context Engineering: 仕様書をAIの文脈として設計する
出典: Birgitta Boeckeler "Context Engineering for Coding Agents" (2026-02-05, martinfowler.com)、Thoughtworks Radar Vol.33
"Context engineering is curating what the model sees so that you get a better result."
――Bharani Subramaniam, Thoughtworks
核心: AIエージェントの成否は「文脈の質」で決まる
Birgitta Boeckeler（前掲 "Context Engineering for Coding Agents"）は、文脈の設計がエージェントの成否を左右すると論じています:
"An agent's effectiveness goes down when it gets too much context, and too much context is a cost factor as well."
――Birgitta Boeckeler
AIエージェントに「良い仕様を渡せば良いコードが出る」は半分正しいのですが、仕様だけでは文脈の全体を構成できません。エージェントが必要とする文脈は、以下のように構造化されます。
| 文脈の種類 | 内容 | 寿命 | 具体例 |
|---|---|---|---|
| 常時文脈（Memory Bank） | プロジェクト全体の規約・原則・アーキテクチャ判断 | プロジェクトの寿命 | CLAUDE.md / .github/copilot-instructions.md / rules |
| タスク文脈（Spec） | 特定フィーチャーの仕様・要件・受入条件 | フィーチャーの寿命 | SPECIFICATION.md / requirements.md |
| セッション文脈 | 現在の作業状態・直前の判断・エラー情報 | セッションの寿命 | 会話履歴 / Auto Memory |
要件定義プロセスへの示唆
前作の8ステップで生成される成果物は、Context Engineeringの観点では以下のように位置づけられます:
| 前作のStep | 文脈の種類 | 設計上の注意 |
|---|---|---|
| Step0〜1: 問題/機会・事業目的 | 常時文脈 | プロジェクト全体で参照される。Memory Bankに配置 |
| Step2〜4: 要求・業務フロー・Outcome | タスク文脈 | フィーチャー単位で管理。1ファイル500行以内 |
| Step5: 機能＋非機能（品質） | 常時文脈 | 全フィーチャーに共通する制約。ルールファイルに配置 |
| Step6〜7: SRS・受入条件 | タスク文脈 | EARS記法など機械可読な形式で記述 |
| Step8: バックログ | セッション文脈 | 個別タスクの実行時に参照 |
重要: 常時文脈（Memory Bank）とタスク文脈（Spec）を分離して管理する設計が有効です。混在すると:
- 常時文脈が肥大化→コスト増 + AIの注意散漫
- タスク文脈に常時文脈が混入→フィーチャー完了時にどこまで破棄してよいか不明
コンテキスト量の管理
多すぎるコンテキストは逆効果になります。LLMは入力が長くなるほど中間部分への注意が低下します（"Lost in the Middle" 問題）。
実務のガイドライン（2026年4月時点の目安。ツール側の上限は頻繁に変更されるため、各ツールの最新ドキュメントを確認すること）:
- 常時文脈: できるだけ簡潔に保つ。ルールファイルは段階的に育てる（Boeckeler: "build context like rules files up gradually"）
- タスク文脈: 1ファイル500行以内に分割
- 不要な文脈は渡さない: 「念のため」で全仕様を渡すのは逆効果。コンテキスト窓が大きくなっても、注意力の低下とコスト増の問題は残る
Harness Engineering: 要件定義プロセスをハーネスとして構築する
出典: Ryan Lopopolo (OpenAI) "Harness engineering: leveraging Codex in an agent-first world" (2026-02-11)、Birgitta Boeckeler "Harness engineering for coding agent users" (2026-04-02, martinfowler.com; 初版メモ 2026-02-17)、Mitchell Hashimoto "My AI Adoption Journey" (2026-02-05)
OpenAIチームが「手動コード一切なし」の制約で5か月間開発し、100万行超のプロダクトを構築した実践報告から生まれた概念です。
"When the agent struggles, we treat it as a signal: identify what is missing --- tools, guardrails, documentation --- and feed it back into the repository."
――Ryan Lopopolo, OpenAI
AIを「仕様で制御する」だけでは不十分
SDDの素朴な理解は「良い仕様を書けばAIが正しいコードを出す」というものです。しかし実践では、仕様だけでAIを制御できません。ハーネス（手綱）――決定論的ガードレール + LLMベース施策 + 文脈工学の組み合わせ――で制御します。
ハーネスの構成要素
Boeckelerは、ハーネスを**Guides（フィードフォワード制御）とSensors（フィードバック制御）の2軸で整理し、それぞれにComputational（決定論的）とInferential（LLM推論）**の実行タイプがあるとしています。また、ハーネスが規制する対象を3カテゴリに分類しています。
| 制御の方向 | Computational（決定論的） | Inferential（LLM推論） |
|---|---|---|
| Guides（フィードフォワード） | LSP、CLI、スクリプト、コードmod | ルールファイル、スキル、参照ドキュメント |
| Sensors（フィードバック） | 静的解析、リンター、構造テスト、カバレッジ | レビューエージェント、LLM-as-judge |
| 規制カテゴリ | 対象 | 要件定義との対応 |
|---|---|---|
| Maintainability harness | コード品質・保守性（重複、複雑度、スタイル） | コーディング規約の自動化 |
| Architecture fitness harness | アーキテクチャ特性（性能、観測性、セキュリティ） | 非機能チェック（Step5）の自動化 |
| Behaviour harness | 機能的な振る舞いの正しさ | 受入条件（Step7）の検証 |
Boeckelerはこれを「サイバネティクスの調速装置（cybernetic governor）」になぞらえています。フィードフォワードだけ（エージェントが同じミスを繰り返す）でもフィードバックだけ（ルールはあるが効果を検証しない）でも不十分で、両方を組み合わせることでエージェントの出力品質の確率を上げます。
前作の8ステップ = ハーネスそのもの
前作の8ステップは、ハーネスの観点では以下のように機能します:
| ハーネスの機能 | 8ステップでの対応 | 自動化の可能性 |
|---|---|---|
| 文脈形成 | Step0〜4（問題定義→プロダクト要件） | 一部（Elicitronによる要求収集、AI初稿生成） |
| 決定論的ガードレール | Step5（非機能チェック） | 高い（リンター、構造テスト、CI/CDチェック） |
| 品質ゲート | Step6〜7（SRS粒度 + 受入条件） | 中程度（EARS記法→Gherkin→テスト自動生成） |
| 実行制御 | Step8（バックログ化→並列タスク実行） | 高い（Spec Kit MAQA拡張等） |
特にStep5の非機能チェック（監査ログ/権限/データ/SLO）は、決定論的なガードレールとして自動化する価値が高いです:
- PRごとに「監査ログの対象イベントが定義されているか」を自動チェック
- データ保持/削除ポリシーへの準拠をCIで検証
- セキュリティ要件（OWASP ASVS等）を構造テストで担保
ハーネスの3類型（Claude Codeでの実装例）
Claude Code は、Context / Harness / Loop の設計を考えるうえで参考になる機能群（CLAUDE.md、auto memory、hooks、skills、agent teams、Agent SDK）を備えており、ハーネスの具体的な設計パターンを理解する材料になります。
| 類型 | 仕組み | 決定性 | 用途例 |
|---|---|---|---|
| 決定論的ガードレール | ファイル保護ルール、自動フォーマット、SQLブロック | 決定論的 |
.env編集ブロック、Prettier自動実行、監査ログ |
| LLM品質ゲート | LLM（軽量モデル）による判定 | 確率的 | タスク完了判定（「全要件が実装されたか？」） |
| エージェント検証 | ツール使用可能なエージェントによる検証 | 確率的 | テスト実行後の停止許可判定、コードベース整合性検証 |
この3類型の組み合わせが重要です。決定論的ガードレールだけでは柔軟性が不足し、LLMだけでは信頼性が不足します。
Humans on the Loop: 要件定義は「Howループの設計」
出典: Kief Morris "Humans and Agents in Software Engineering Loops" (2026-03-04, martinfowler.com)
3つのモデル
| モデル | 人間の位置 | 要件定義の視点 |
|---|---|---|
| Humans outside the loop | Whyループのみ | バイブコーディング。目的だけ伝える |
| Humans in the loop | Why + Howループ | 人間がコード1行ずつ確認。ボトルネック |
| Humans on the loop | Howループの設計者 | ハーネスを構築・改善し、エージェントに実行させる |
「on the loop」の意味: 人間はコードを1行ずつ確認する存在（in the loop）から、制御構造（ハーネス）を設計・改善する存在に移行します。
前作の8ステップは、この文脈ではHowループのハーネスとして機能します:
- 8ステップが「変換の品質」を保証する制御構造
- エージェントは8ステップの成果物（仕様・受入条件）に基づいて実装を実行
- 人間は8ステップのプロセス自体を改善する（メタ要件定義）
Agentic Flywheel: 継続的改善
発展形として、エージェント自身がハーネスの改善提案を行うサイクル:
- エージェントが要件の不備を検出（例: 「この仕様には例外ケースの記述がない」）
- ハーネス改善を提案（例: 「Step3のチェックリストに例外パターンXを追加すべき」）
- 人間が判断し、ハーネス（チェックリスト/テンプレート/ルール）を更新
- 次回以降の要件定義プロセスの品質が向上
低リスクの改善（ドキュメントの不整合修正等）は自動適用、高リスクの改善（チェックリスト項目の追加等）は人間が判断、という棲み分けが現実的です。
変わらないもの: B2B SaaSの非機能は後付けできない
前作のStep5（非機能チェック）で強調した原則は、AI時代でも変わりません。むしろ重要性が増しています。
AIに「任せられない」判断領域
前作Step5の非機能チェック項目のうち、特にAIとの分担が明確になる代表5領域を示します（観測性・運用・アクセシビリティを含む全項目は前作を参照）。
| 非機能の領域 | AIに任せられる部分 | 人間の判断が必要な部分 |
|---|---|---|
| 監査ログ | ログ出力コードの生成 | 何を・誰が・いつ・どの粒度で残すかの設計判断 |
| 権限（RBAC等） | 権限チェックのコード生成 | **役割設計と例外（代理・退職・委任）**の業務判断 |
| データ保持/削除 | 削除処理のコード生成 | 保持期間・論理/物理の選択・リージョンの法規・契約判断 |
| SLO/SLA | メトリクス計測コードの生成 | 何をSLIにし、どの目標値にするかのビジネス判断 |
| プライバシ/規制 | マスキング処理のコード生成 | 取り扱い区分・同意設計・監査要件の法務判断 |
ハーネスで自動化できる部分と、できない部分の境界
ハーネス（決定論的ガードレール）で自動化できるのは、判断基準が既に確定しているチェック:
- 「監査ログのイベント定義があるか」（有無の確認）→ 自動化可能
- 「監査ログで何を記録すべきか」（設計判断）→ 人間が必要
前作Step5のチェックリストは、上記の「自動化可能なチェック」をCIに組み込むソースとして使えます。判断基準が曖昧なもの（「監査要件を満たしているか」）は、LLM品質ゲートで補助しつつ人間が最終判断します。
チェックリスト（AI時代版）
前作の実務チェックリストに、AI時代の観点を追加します。
基本（前作と共通）
- いま扱っているのは要望か、要求か、要件か？
- needは1文で言えるか？
- 制約と条件が分離されているか？
- 検証可能か？（受入条件と検証方法が紐づくか）
- SaaS特有の非機能が抜けていないか？（権限/監査/データ保持/削除/SLO等）
- 要件・受け入れ条件・意思決定の一次情報が、関係者に見える（参照できる）形になっているか？
AI時代の追加観点
- 仕様書はバージョン管理されているか？（Git管理。エージェントが参照する文脈は追跡可能であるべき）
- EARS形式またはGherkin形式で検証可能か？（機械可読な要件 → テスト自動生成への接続）
- AIへの指示（仕様）とコードの同期チェックがCI/CDに入っているか？（仕様-コード乖離の自動検出）
- Memory Bank（常時文脈）とSpec（タスク文脈）が分離されているか？（コンテキスト設計）
- 決定論的ガードレール（リンター/構造テスト）が設定されているか？（ハーネスの基盤）
- SDDのワークフローが問題サイズに合っているか？（バグ修正に4 User Storyは過剰）
このやり方が通用しないケース（批判的視点）
前作の「通用しないケース」に加え、SDD/Context Engineering/Harness Engineeringに固有の限界を示します。
SDDが過剰になる場面
- 探索的プロトタイプ: 何を作るか自体が不確実な局面では、仕様化コスト > 学習速度。バイブコーディングで素早く検証し、方向が定まってから仕様化する方が効率的
- 小タスク: バグ修正・設定変更にSpec-firstを強制すると、プロセスのオーバーヘッドが開発速度を殺す。問題サイズに応じたワークフロー選択が必要
- 1人開発: チーム間の認識齟齬が存在しない場合、SDDの価値は半減する（ただし仕様の永続化による将来の保守性向上は残る）
重厚仕様 + ビッグバンリリースへの回帰リスク
SDDは構造的にウォーターフォール的アンチパターンに陥りやすい:
- 「仕様を完璧にしてから実装」→ 仕様作成に時間がかかる
- 仕様レビューに時間がかかる（「コードレビューより辛い」）
- 実装開始が遅れる → リリースが遅れる
対策: SDDの段階的適用（Spec-firstから始め、仕様の維持コストが見合う場面でのみSpec-anchoredへ移行）と、仕様のインクリメンタルな洗練（一度で完璧を目指さない）。
コンテキスト工学の「制御の錯覚」
Boeckelerは以下のように警告しています（趣旨要約）:
sometimes people talk about these features with phrases like "ensure it does X", or "prevent hallucinations". But as long as LLMs are involved, we can never be certain of anything, we still need to think in probabilities.
――Birgitta Boeckeler, "Context Engineering for Coding Agents" (2026-02-05)
入念にコンテキストを設計しても、LLMが期待通りに振る舞う保証はありません。コンテキスト工学は確率を上げる技術であり、決定論的な保証ではありません。
実務での心構え:
- 決定論的に守れるもの（リンター/構造テスト/CIチェック）はハーネスのガードレールで担保
- LLMの出力は常にレビュー対象。「AIが書いた = 正しい」と仮定しない
- エージェントが失敗したとき、それは「ハーネスに何が足りないか」のシグナルとして扱う
前作の「通用しないケース」もそのまま適用される
前作で書いた以下のケースは、AI時代でも変わりません:
- 仮説A: 手戻りの主因が要件ではなく、依存関係/アーキ/チーム構造にある場合
- 仮説B: 手戻りの主因が意思決定の遅さ（権限/優先順位/合意形成）にある場合
- 仮説C: 不確実性が高い局面で、仕様の厳密化よりプロトタイプ/実験が支配的に効く場合
AI時代特有の追加仮説:
- 仮説D: SDDの導入コスト（ツール学習 + プロセス変更）が、チームの現在の成熟度に対して高すぎる場合、改善よりも混乱が増える
- 仮説E: コンテキスト工学に投資しても、そもそもの要件が曖昧（Step0〜2が不十分）なら、AIの出力品質は上がらない（Garbage In, Garbage Out）
- 仮説F（bitter lesson仮説）: Thoughtworks Radar Vol.33は、手作業で詳細ルールを作るやり方はスケールしない可能性を示唆しています（趣旨: "We may be relearning a bitter lesson --- that handcrafting detailed rules for AI ultimately doesn't scale."）。本稿ではこれをbitter lesson仮説として読みます: モデルの知能が急速に向上する中、人間が手作業で仕様やルールを精緻化するアプローチは、長期的にはモデル自体の推論能力に委ねる方向に収束する可能性がある。SDD/Harness Engineeringへの投資が「次のモデルで不要になるルール作り」に終わるリスクは、常に意識すべきです
次アクション（行動への橋渡し）
読了後に試せるステップを、導入の容易さ順に示します。
-
前作のチェックリスト + 本記事のAI時代チェックリストを併用する: いま議論している仕様が「要望/要求/要件」のどれかを判別し、かつ「AIのコンテキストとして機能するか」を問う
-
Step5の非機能チェックリストをCIの"手動チェック"として運用する: PR作成時に「監査ログ/権限/データ/SLO」の4項目を確認するだけでも、後付けリスクは下がる
-
仕様書をGit管理する: 既にGoogle Docs等で書いている仕様をMarkdown化し、コードと同じリポジトリで管理する。バージョン管理 + レビュー + 差分追跡が入る
-
1つのフィーチャーでEARS記法を試す: 前作Step6の「曖昧語→検証可能」の変換を、EARS記法で書き直してみる
まとめ
AIでコードが書ける時代だからこそ、「何を作るか」を定義する仕事の重要性は増しています。抽象化の歴史に照らせば、要件定義はエンジニアの仕事の中で上に移動します。
3つの新概念は、その移動先を構造的に示しています:
| 概念 | 要件定義への意味 |
|---|---|
| Context Engineering | 仕様書を「AIエージェントの文脈」として設計する。Memory Bank / Specの分離、粒度管理 |
| Harness Engineering | 要件定義プロセスを「AIを制御するハーネス」として構築する。決定論的ガードレール + LLM品質ゲートの組み合わせ |
| Humans on the Loop | 人間はコードを確認する存在から、制御構造（ハーネス）を設計・改善する存在へ移行する |
前作の8ステップ（要望→要求→要件の変換地図）は、そのままHowループのハーネスとして機能します。SDDツールは8ステップの後半（Step4〜8）を加速しますが、上流（Step0〜3: 何を・なぜ作るか）は依然として人間の判断領域であり、ハーネスで完全に自動化することはできません。
ただし、SDDにもバイブコーディングとは逆方向の罠があります。仕様の過剰化、レビュー過負荷、ビッグバンリリースへの回帰。問題サイズに応じたワークフロー選択と、「確率で考える」姿勢が、AI時代の要件定義には必要です。
前作が「要件定義の地図」だとすれば、本記事は「その地図をAIエージェントと一緒に使うための取扱説明書」です。両方を組み合わせて、現場で試してみてください。
参考リンク
基盤（前作と共通）
- ISO/IEC/IEEE 29148:2018（Terms and definitions）
- OWASP ASVS（セキュリティ要求の標準化）
- Google SRE Book - Service Level Objectives
- DORA Research
SDD / ツール
- GitHub Spec Kit --- v0.5.0、85k+ stars（2026年4月時点）。Community Extensions 40+
- AWS Kiro --- Feature Specs / EARS notation / Given-When-Then AC / Agent Hooks / Steering
- Tessl --- Public。Registry（エージェントスキル/コンテキストのパッケージマネージャー）が現在の主軸。Framework（Spec-as-source）は探索継続中
- Birgitta Boeckeler, "Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl" (2025-10-15, martinfowler.com) --- SDDの三段階分類、3ツール比較、MDD回帰リスクの指摘
- Thoughtworks Technology Radar Vol.33 (2025-11) --- SDD = Assess、Context Engineering
Context / Harness / Loop
- Birgitta Boeckeler, "Context Engineering for Coding Agents" (2026-02-05, martinfowler.com)
- Birgitta Boeckeler, "Harness engineering for coding agent users" (2026-04-02, martinfowler.com; 初版メモ 2026-02-17)
- Ryan Lopopolo (OpenAI), "Harness engineering: leveraging Codex in an agent-first world" (2026-02-11)
- Kief Morris, "Humans and Agents in Software Engineering Loops" (2026-03-04, martinfowler.com)
- Mitchell Hashimoto, "My AI Adoption Journey" (2026-02-05)
Intent / AI開発の転換
- Thomas Dohmke (GitHub 元CEO), GitHub Universe 2024 Keynote (2024) --- 「Intentが新たなソース・オブ・トゥルース」（注: 基調講演動画からの趣旨要約）
EARS / 要求工学
- Alistair Mavin et al., "Easy Approach to Requirements Syntax (EARS)", RE'09 (2009) --- 航空宇宙/自動車で採用実績
- テスト自動生成の新時代: EARS記法とBDD(振る舞い駆動開発)とLLMと (Qiita, 2025-12) --- 三層モデル（EARS → Gherkin → テスト）の整理
AI x 要求抽出
- Mohammadmehdi Ataei et al., "Elicitron: An LLM Agent-Based Simulation Framework for Design Requirements Elicitation" (arXiv:2404.16045, 2024)
Claude Code（Context / Harness / Loopの実装例）
- Anthropic Claude Code Documentation (2026) --- CLAUDE.md / auto memory / hooks / skills / agent teams / Agent SDK
Discussion